Oracle to find the cause of IP Account Lock

 

In the ORACLE database, if not modified FAILED_LOGIN_ATTEMPTS, the default 10 attempts will lock the user after the failure. At this point then log database, will encounter ORA-28000: the account is locked

 

 

SQL> SELECT * 
  2  FROM DBA_PROFILES
  3  WHERE RESOURCE_NAME='FAILED_LOGIN_ATTEMPTS';
 
PROFILE                        RESOURCE_NAME                    RESOURCE LIMIT
------------------------------ -------------------------------- -------- -----
DEFAULT                        FAILED_LOGIN_ATTEMPTS            PASSWORD 10
MONITORING_PROFILE             FAILED_LOGIN_ATTEMPTS            PASSWORD UNLIMITED
 
SQL>

 

Then the database maintenance process, if the account is locked situation occurs, how is post hoc analysis that lead to the host or IP account is locked out? Different situations have different analysis methods, mainly to see whether to open the database auditing

 

 

Open the database audit

 

If you open the audit function, then the analysis is very simple and easy to locate. Because the audit function of the database will record the information into the database.

 

Check for open audits, mainly to see audit_sys_operations argument is TRUE.

 

SQL> show parameter audit
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      /u01/app/oracle/admin/gsp/adum
                                                 p
audit_sys_operations                 boolean     TRUE
audit_syslog_level                   string
audit_trail                          string      DB_EXTENDED
SQL> 

 

If you open the audit function, the following SQL statement can easily find the cause account lockout host (IP address of the host to find specific)

 

---- RETURNCODE = 1017 means the login failed to return ORA-01017: invalid username / password; logon denied error session information.

 If audit_trail = DB

SELECT USERNAME
       ,USERHOST
       ,TIMESTAMP
       ,RETURNCODE
FROM dba_audit_session
WHERE USERNAME='TEST'
    AND RETURNCODE='1017' 
ORDER BY TIMESTAMP DESC;

 

 If audit_trail = OS

grep 1017 $ORACLE_BASE/admin/$ORACLE_SID/adump/*2019053004*
orcl_ora_20432_20190530040340560268143795.aud:SESSIONID:[8] "33072208" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[4] "scott" USERHOST:[12] "app-01" ACTION:[3] "100" RETURNCODE:[4] "1017" COMMENT$TEXT:[98] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.4.15.148)(PORT=47646))" DBID:[10] "1865135537" 
orcl_ora_20434_20190530040337550602143795.aud:SESSIONID:[8] "33072205" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[4] "scott" USERHOST:[12] "app-01" ACTION:[3] "100" RETURNCODE:[4] "1017" COMMENT$TEXT:[98] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.4.15.148)(PORT=47643))" DBID:[10] "1865135537" 
orcl_ora_20436_20190530040338555761143795.aud:SESSIONID:[8] "33072209" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[4] "scott" USERHOST:[12] "app-01" ACTION:[3] "100" RETURNCODE:[4] "1017" COMMENT$TEXT:[98] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.4.15.148)(PORT=47642))" DBID:[10] "1865135537" 
orcl_ora_20438_20190530040343576957143795.aud:SESSIONID:[8] "33072206" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[4] "scott" USERHOST:[12] "app-01" ACTION:[3] "100" RETURNCODE:[4] "1017" COMMENT$TEXT:[98] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.4.15.148)(PORT=47641))" DBID:[10] "1865135537" 
orcl_ora_20440_20190530040337545737143795.aud:SESSIONID:[8] "33072207" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[4] "scott" USERHOST:[12] "app-01" ACTION:[3] "100" RETURNCODE:[4] "1017" COMMENT$TEXT:[98] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.4.15.148)(PORT=47640))" DBID:[10] "1865135537" 
orcl_ora_20442_20190530040337548685143795.aud:SESSIONID:[8] "33072210" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[4] "scott" USERHOST:[12] "app-01" ACTION:[3] "100" RETURNCODE:[4] "1017" COMMENT$TEXT:[98] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.4.15.148)(PORT=47639))" DBID:[10] "1865135537"

 

 

Database auditing Close

 

 If the database audit function is turned off, then the ability to locate, find the cause account lockout host or IP address? If this account is locked, appears, you can check dba_users trying to see at what point in time the account is locked. Note (some versions Bug, LOCK_DATE inaccurate happens.)

  

SQL> ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';
 Session altered.
SQL> SELECT username, account_status,lock_date, PROFILE 
  2  FROM dba_users WHERE username='TEST';
 
USERNAME          ACCOUNT_STATUS       LOCK_DATE         PROFILE
------------ ---------------------- ------------------- ----------
TEST              LOCKED(TIMED)     2018-06-16 23:49:14 DEFAULT
 
SQL> 

    

 

    Some online article categorically declared that can be analyzed by listening to log out which IP leading to the account is locked, but through hands-on lab analysis, found it impossible to locate the IP address of the account lockout caused by listening to the log file, for two reasons:

 

1, can not determine whether the login session ORA-01017 errors because listeners log ORA-01017 errors session information log on success and failure logon experience is the same by listening log. Indistinguishable!

 

2, even if the account lockout time can be positioned to the second, but a production environment, a large number of listeners log generation within one second, which is simply unable to locate a specific IP

 

3, failed login session may not be continuous. But it generated a period of time. By analyzing the log did not have the possibility to listen!

 

Log in or failure account lock Listener Log and Alert Log can you find relevant information.

But if you define database triggers in advance, so you can easily navigate to a specific IP, users provide a trigger, as follows:

 

CREATE OR REPLACE TRIGGER sys.logon_denied_to_alert
  AFTER servererror ON DATABASE
DECLARE
  message   VARCHAR2(168);
  ip        VARCHAR2(15);
  v_os_user VARCHAR2(80);
  v_module  VARCHAR2(50);
  v_action  VARCHAR2(50);
  v_pid     VARCHAR2(10);
  v_sid     NUMBER;
  v_program VARCHAR2(48);
  v_username VARCHAR2(32);
BEGIN
  IF (ora_is_servererror(1017)) THEN
    -- get ip FOR remote connections :
    IF upper(sys_context('userenv', 'network_protocol')) = 'TCP' THEN
      ip := sys_context('userenv', 'ip_address');
    END IF;
    SELECT sid INTO v_sid FROM sys.v_$mystat WHERE rownum < 2;
    SELECT p.spid, v.program
      INTO v_pid, v_program
      FROM v$process p, v$session v
     WHERE p.addr = v.paddr
       AND v.sid = v_sid;
    v_os_user := sys_context('userenv', 'os_user');
    v_username := sys_context('userenv','authenticated_identity');
    dbms_application_info.read_module(v_module, v_action);
    message := to_char(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') ||
               ' Password Erro: logon denied from ' || nvl(ip, 'localhost') || ' ' ||
               v_pid || ' User:' || v_os_user || ' with ' || v_program || '' ||
               v_module || ' ' || v_action||' dbuser:' || v_username;
    sys.dbms_system.ksdwrt(2, message);
  END IF;
END;
/

 

 

 

In the client using SQL * Plus test, analog input wrong password database

 

 

C:\Users>sqlplus test/1234@myvm
 
SQL * Plus: Release 11.2.0.1.0 Production on Sunday June 17 2018 00:35:21
 
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
 
ERROR:
ORA-01017: invalid username/password; logon denied

 

 

At this time, the flip-flop to capture the error, the error log will generate similar information such as the following in the alarm log:

 

 

Sun Jun 17 08:01:44 2018

2018-06-17 08:01:44 Password Erro: logon denied from 192.168.125.193 26639 User:KongLB with sqlplus.exe ��� sqlplus.exe  dbuser:test

 

Of course, if you can rewrite the trigger, capture the relevant information into the database related tables.

 

Transfer: https: //www.cnblogs.com/kerrycode/p/9191983.html

 

Guess you like

Origin www.cnblogs.com/plluoye/p/10951120.html