AW: failed connection attempts in listner.log file

  • From: "ahmed.fikri@xxxxxxxxxxx" <ahmed.fikri@xxxxxxxxxxx>
  • To: "list, oracle" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 28 Jan 2022 09:14:00 +0100 (CET)

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@xxxxxxxxxxx>
An: "list, oracle" <oracle-l@xxxxxxxxxxxxx>, "ahmed.fikri@xxxxxxxxxxx" 
<ahmed.fikri@xxxxxxxxxxx>
 
 
 
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@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on 
behalf of ahmed.fikri@xxxxxxxxxxx <ahmed.fikri@xxxxxxxxxxx>
Sent: 27 January 2022 16:39
To: list, oracle <oracle-l@xxxxxxxxxxxxx>
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
 


Other related posts: