===== Fehlgeschlagene Anmeldungen in der Oracle DB überwachen ===== **Angelegt am August 2013, aktalisiert auf 12c April 2018** **Problem:** In einer Datenbank ist immer wieder der SYSTEM-Account gelockt. Folgender Oracle-Mechanismus schlägt dabei zu, im "default" Profile wurde der Wert für **failed_login_attempts** auf 10 (default) gesetzt. Einstellung abfragen: select * from dba_profiles where resource_name like 'FAILED%'; PROFILE RESOURCE_NAME RESOURCE_TYPE LIMIT -------- ------- -------------- ----- DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10 ---- ==== Zähler "lcount" in der Tabelle sys.user$==== Wie weiß die DB überhaupt, wie oft sich jemand falsch angemeldet hat? Bei jeder Falschanmeldung wird der Zähler lcount in der Tabelle sys.user$ um 1 hochgezählt. Wenn er die 10 erreicht, wird der Account gesperrt. Wenn sich zwischendurch der DBA mit dem richtigen Paßwort anmeldet, wird der Zähler wieder auf 0 zurückgesetzt SYSTEM@sql> select lcount from sys.user$ where name = 'SYSTEM'; LCOUNT --------- 0 1. Schritt: Falsch-Anmeldung in einer zweiten session SYSTEM@sql> / LCOUNT --------- 1 2. Schritt: noch eine Falsch-Anmeldung SYSTEM@sql> / LCOUNT --------- 2 3. Schritt: Richtig-Anmeldung => SYSTEM@sql> / LCOUNT --------- 0 Überlegung: Wenn sich ein Skript mit dem falschen PW anmeldet und DBA immer wieder mit dem richtigen PW die DB prüft, dann wird der Zähler immer wieder auf 0 gesetzt. ---- ==== Überwachung für die failed_logins einschalten ==== Der Anwender erhält bei einer falschen Anmeldungen einen "ORA-01017: invalid username/password; logon denied" oder einen "ORA-28000: the account is locked". === Audit einschalten== -- check if auditing is enabled show parameter audit_trail -- if not enable alter system set audit_trail = 'DB' scope = spfile; shutdown immediate startup Audition für fehlgeschlagene Anmeldungen aktiveren: audit session whenever not successful; => Danach stehen nach einem erfolglosen login die Einträge in **sys.aud$** ACHTUNG:\\ Die Daten liegen im SYSTEM-tablespace und können diesen überlaufen lassen!\\ => siehe auch => [[dba:aud_table_umzug|Audit Tabelle umziehen]] \\ select userid, userhost, terminal, comment$text, spare1, ntimestamp# from sys.aud$ where ( returncode=1017 or returncode=28000); -------------------------- SYSTEM MYNET\NO32998 NO32998 Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.27.2.36)(PORT=3862)) SCOTT 28.01.08 17:35:23,062526 Es wird auch protokolliert, wenn sich ein User mit einem nicht vorhandenen Account anmeldet. In der Spalte userid steht der Username, mit dem ein Versuch durchgeführt wurde. Audit Trail abfragen mit: select os_username , username , terminal , userhost , returncode , count(*) from dba_audit_trail where ( returncode=1017 OR returncode=28000) and timestamp > sysdate-1 group by os_username,username,terminal,userhost,returncode / ---- ==== Auditing ausschalten: ==== SYSTEM@sql> noaudit session whenever not successful; NOAUDIT wurde erfolgreich ausgeführt. Die Einträge in sys.aud$ bleiben erhalten. ---- ==== Wo sieht man, ob und was geaudited wird? ==== Die eingeschalteten Audit-Options stehen in folgenden Views: * dba_stmt_audit_opts * dba_priv_audit_opts * dba_obj_audit_opts Wenn kein audit eingeschaltet ist, geben die o.g. view no rows zurück. Eine Liste der möglichen Audit-Options findet man in sys.audit_actions. In unserem Beispiel: SYSTEM@sql> select * from dba_stmt_audit_opts; USER_NAME PROXY_NAME AUDIT_OPTION SUCCESS FAILURE ------------------------------ ---------------------------------------------------------------------- ---------- ---------- CREATE SESSION NOT SET BY ACCESS ---- ==== Quellen ==== * audit failed login attempts: s.a. **Metalink Note:352389.1** * Danke an Frau Monika Kern für die gute Zusammenarbeit