Database Reference
In-Depth Information
Audit Trail as a Source of Evidential Metadata
All of the third-party tools suffer from cost, inconvenience, and separation from the thing that they are monitoring.
Thus Oracle's native audit trail has advantages over even agent-based monitoring tools. The big problem with native
auditing is that the SYS privilege can be used to turn it off. Two caveats to this are that mandatory audit ( LOGON/OFF
and SHUTDOWN/STARTUP by pwfile managed users) theoretically cannot be turned off. Also the aud_sys_operations
parameter requires a restart in order to change. This restart will be visible in the logs.
I published an article in 2010 on how it was possible to change aud_sys_operations without that action being
audited by overwriting the spfile from the DB, which you can read here:
http://www.oracleforensics.com/wordpress/index.php/2010/06/08/turning-off-sys-auditing-from-the-db-
without-that-fact-being-recorded/
The work at the previous URL was done in order to demonstrate the usefulness of the Sentrigo Hedgehog DB
monitoring tool. Audit bypass was extended by Laszlo Toth and also by David Litchfield by the use of oradebug. Oracle
comes with a built-in debugger named oradebug that all SYSDBAs can use remotely and locally to poke memory
addresses in the SGA directly, which enables both aud_sys_operations and mandatory audit to be turned off
nearly silently.
Firstly, if you have a memory agent, DB security monitoring tool like McAfee or AppSecInc, then that tool can
alert you to the use of oradebug. For large estates with only native tools, it is possible to infer potential use of oradebug
to turn off the audit trail. During my time monitoring syslog on production databases, especially on RAC systems, an
important observation was that SYS is a very busy account. Why? Because the Oracle software uses SYS under the
hood to perform various tasks, and the DBA team is also using the account. So the SYS audit trail is actually quite
similar to a heartbeat, and the most noticeable thing about a heartbeat is when it stops. So gaps in the SYS audit trail
on a RAC production system generally represent a restart or someone turning off the audit trail through oradebug.
We can detect authorized gaps in the audit trail by remotely collecting the server restart times with this query:
SQL> select startup_time from DBA_HIST_PDB_INSTANCE;
STARTUP_TIME
------------------------------------------------------------
26-AUG-13 16.20.37.000
04-SEP-13 03.26.20.000
04-SEP-13 04.25.09.000
04-SEP-13 19.47.27.000
If there are gaps in the audit trail that are “in addition” to the above restart times, then that may point to someone
turning off the audit trail through oradebug.
If the audit trail is quiet due to being a quiet server or in a QA environment, then you can set up a heartbeat, such
as a cron'd SYS logon, and log off every minute, which will punctuate the audit trail to let you know it is still turned on.
Another common method of auditing has been the logon trigger. In my experience, these can sometimes cause
reliability issues. Some of my colleagues have deployed triggers more extensively, and I am told that it is possible to
have two triggers firing on each other to protect each other from modification. I have not tested this. What I do know is
that it is possible for a trigger to lock out the SYSDBA user.
SYSDBA lockout is an interesting problem, which has been investigated by Tanel Poder at this blog:
http://blog.tanelpoder.com/2012/05/08/oradebug-hanganalyze-with-a-prelim-connection-and-error-can-
not-perform-hang-analysis-dump-without-a-process-state-object-and-a-session-state-object/
The answer for SYSDBA lockout is to log on using the -prelim option. This option enables oradebug usage, and
you can then fix the database enough to get back in again. The interesting thing with -prelim is that it will fire before
the trigger, so SYS can act without the trigger firing.
 
Search WWH ::




Custom Search