Getting OSSEC To Parse Auditd

“Everyone wants a log
You're gonna love it, log
Come on and get your log
Everyone needs a log
log log log” – Ren and Stimpy

I use OSSEC pretty regularly on Linux and Windows servers. It is incredibly useful because of its ability to parse and correlate a large number of log formats, as well as granularly react to logs based on rules that, out of the box, encompass a large amount of what I consider useful information. This includes bruteforce password attempts, suspected malicious activity, and when configured in conjunction with iptables, host scanning attempts. This link defines what OSSEC is, but is a digression from the point of this blog, which is how to use OSSEC to parse auditd logs.

Although I appreciate OSSEC greatly, one feature I found that was lacking was the ability to parse the auditd daemon logs. Auditd provides more detailed information on which user and source IP address are attempting to access services. Since auditd gets information from PAM.D, it is more useful in correlating user names logging in with their source IPs for authentication attempts than some of the service specific logs, such as those created by SSHD. I needed a decoder to parse these logs so I could do that correlation of who is coming from where.

On a CentOS 5.5 server, I created the following decoder to pull information out of the /var/log/audit/audit.log created by the auditd service.

To decode auditd messages, with PAM enabled on the server:

1. In local_decoder.xml add:

<decoder name="auditd">
<prematch>type=\S+ msg=audit</prematch>
<regex offset="after_prematch">msg=</regex>
<regex>'PAM: \.+ acct="(\S+)" : exe="(\S+)" \(hostname=(\S+), addr=(\S+), terminal=(\S+) res=(\S+)\)'</regex>
<order>user, extra_data, srcip, dstip, id, status </order>
</decoder>

2. Create an auditd_rules.xml, add the following to obtain alerts on when Bob, for example, logged into the server:

<rule id="101113" level="7">
<decoded_as>auditd</decoded_as>
<user>^Bob</user>
<description>Auditd rule to notify when Bob logged in.</description>
</rule>

3. Add the audit_rules.xml to the ossec.conf in the rules to be used section.

Note that the extra_data will have the service which the authentication attempt was made by as its value, and the status will contain a success or fail, that rules can parse on, if the intent is to check for multiple failures.

It is my understanding that there is an interest on the part of others in the ability to parse these logs. I hope this information finds them well.
By Josh Lochner, Senior Risk Management Consultant