Exadata – OS Audit Logging

Linux has the ability to audit OS system calls and operations on directories and files, and Exadata actually comes with a default configuration to do just that.

The functionality is provided by the auditd service, and there are a couple of configuration files –


The first configuration file has your high level configuration – where the log files go, how often they’re rotated (auditd rotates it’s own logs and doesn’t use logrotate – more on this in a separate blog later).

The second configuration file determines what operations are audited. In a fresh Oracle Linux 5.9 installation, this file is basically empty. On Exadata though there is an out-of-the-box rule configuration supplied and audits operations such as

Modifications to user access related files –

System calls to change the server time –

Modifications to files such as /etc/hosts, /etc/sysconfig/network –

System calls to chown, chown etc –

Unauthorised access to files –

…and much more

You then have a few tools that you can use to parse the /etc/audit/audit.log files.

In the example below, I ssh to the server as “mwalden” then “su – root” before making changes to /etc/hosts with vi –

Now what I love is that Linux actually tracks the original user login even after switching user, so I can never prevent my “original” username being logged against operations that I run as root after “su’ing”. You can see in the image above that I’ve highlighted the auid and uid items which shows that “mwalden” is the real person who modified /etc/hosts, but he did it as the “root” user. This is great news because it gives another good reason to follow best practice of using individually named accounts for OS access, even if the user then just switches straight up to the root user.

In case you’re wondering, I used the following command to show the auditing on /etc/hosts –

The -i parameter tells it to resolve numeric identifiers such as the user ids to their name.

Unfortunately, the out-of-the-box configuration does have a few problems. Take a look at my current log rotations –

You’ll notice that is is filling all 4 available log files in the space of about an hour, and audit records older than that are being purged. A log inspection shows up a lot of this (click the image for a clearer look) –

You’ll notice I’ve highlighted two items of particular interest. The first shows this –

And the second shows this –

We can actually mark up entries in our audit.rules file with a certain “key” and this key makes it into the audit log. This allows us to track an audit log entry back to the associated rule. So obviously in this case, the OEM 12c agent is creating and deleting a lot of temporary files which are pending upload to OMS and this is triggering our default “audit all file deletions” rule –

I’ve come up with a solution to this, by excluding that particular path from the deletion rule –

I’m still awaiting “blessing” from Oracle Support that they’re happy with that, but it seems to work. Note one important point though – the Exadata out-of-the-box audit configuration includes the following option –

So on Exadata, we need a reboot in order to make that rule change.

Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: