AW: failed connection attempts in listner.log file
Date: Fri, 28 Jan 2022 17:43:56 +0100 (CET)
Message-ID: <1643388236181.7992289.73175c68a4872512980064aa39d1790fd8cc6759_at_spica.telekom.de>
indeed the purge process is not set up so that these queries return 00600 error in our UAT database:
select * from unified_audit_trail order by event_timestamp;
and
select * from unified_audit_trail where event_timestamp like '26-JAN%';
this one is working:
select * from unified_audit_trail
Thanks for the link.
Best regards
Ahmed
-----Original-Nachricht-----
Betreff: Re: failed connection attempts in listner.log file
Datum: 2022-01-28T17:30:11+0100
Von: "Powell, Mark" <mark.powell2_at_dxc.com>
An: "list, oracle" <oracle-l_at_freelists.org>
And if the Unified Audit trail is configured you should probably set up the
purge process.
<https://blog.dbi-services.com/purging-unified-audit-trail-in-12cr1/>
Purging Unified Audit Trail in 12cR1 - Blog dbi services
<https://blog.dbi-services.com/purging-unified-audit-trail-in-12cr1/>
By Franck Pachot . When you want to empty a table you have two methods: delete and truncate. If, for any reason (see previous post) the Unified Audit Trail has become too big, you cannot directly delete or truncate the table. You must call the dbms_audit_mgmt.clean_audit_trail. But then you want to know if it will do slow deletes or quick truncates. Let’s trace it. I have filled my Unified ...
blog.dbi-services.com
Mark Powell
Database Administration
(313) 592-5148
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: Friday, January 28, 2022 3:14 AM
To: list, oracle <oracle-l_at_freelists.org> Subject: AW: failed connection attempts in listner.log file
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://clicktime.symantec.com/32LrQhdDKgxdTw45KFdyC2M6xn?u=https%3A%2F%2Fsupport.oracle.com%2Fepmos%2Ffaces%2FDocumentDisplay%3F_afrLoop%3D391811005170797%26id%3D2063340.1%26_adf.ctrl-state%3Du78nmxlxc_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-lReceived on Fri Jan 28 2022 - 17:43:56 CET