AW: failed connection attempts in listner.log file

From: <ahmed.fikri_at_t-online.de>
Date: Fri, 28 Jan 2022 09:14:00 +0100 (CET)
Message-ID: <1643357640080.8000966.d53dbc643a122d2511d00c2624cd30d1e0fcfe59_at_spica.telekom.de>

Thanks Neil          

-----Original-Nachricht-----
Betreff: Re: failed connection attempts in listner.log file Datum: 2022-01-27T21:35:26+0100
Von: "Neil Chandler" <neil_chandler_at_hotmail.com> An: "list, oracle" <oracle-l_at_freelists.org>, "ahmed.fikri_at_t-online.de"
<ahmed.fikri_at_t-online.de>
     

I know you have a resolution but... if your database was created at 12+ (i.e. not upgraded from a lower release), then there are 2 Unified Audit policies enabled by default, one of which audits unsuccessful logon attempts.  

Check with: select * from audit_unified_enabled_policies order by policy_name;
You can access that data in the view UNIFIED_AUDIT_TRAIL: select * from unified_audit_trail order by event_timestamp;  

Others suggested using traditional audit methods, which is fine but I would advocate everyone to migrate to Unified Auditing if they are on 12.2+ for security, performance and manageability reasons. It's just better. [aside: if you are on 12.1 with unified audit policies enabled, you need to look at
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=391811005170797&id=2063340.1&_adf.ctrl-state=u78nmxlxc_52
<https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=391811005170797&id=2063340.1&_adf.ctrl-state=u78nmxlxc_52>
to apply the patch as it has serious performance issues]  

regards  

Neil.    

---

From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of ahmed.fikri_at_t-online.de <ahmed.fikri_at_t-online.de> Sent: 27 January 2022 16:39
To: list, oracle <oracle-l_at_freelists.org> Subject: AW: failed connection attempts in listner.log file  

Thanks you all,  

I managed to get the content of the dba_audit_trail table (UAT environment). Only successfully login are logged, but after checking the logs in the past I found entries for a job that connects to the db each 5 minutes. The db user get locked after (about) 50 minutes (default profile with 10 times attempts limit). And it was the culprit job, (someone has changed the pw). Nevertheless I was just curios and wanted to see if it was possible to solve the problem without the enabling audit trail. And thank you al: Nenad, Andy and Sayan l for having refreshing my knowledge about listener.  

However, I think there is no need to enable any extra auditing for no successful connections, one had only to compare the listener.log file with the the successful connections  

Best regards
Ahmed  



--
http://www.freelists.org/webpage/oracle-l

Received on Fri Jan 28 2022 - 09:14:00 CET