Offline audit trail analysis

[Steve Grubb]

On Tuesday 11 September 2007 15:31:53 Todd, Charles wrote:
> Has anyone talked about sane ways to do offline analysis of Linux audit
> logs?  Presumably, this would be on another Linux system, but maybe not
> the same host, and probably not on the same release or with the same
> username/IP address access.  Conceptually, ausearch would save and
> optionally read a system's "configuration" to be saved for
> interpretation later.

ausearch uses getpw* and getgr* calls to resolve the uid & gid. Aside from 
that, I believe it is self contained. (I haven't dug too deep in answering 
this question.)


> My goal is central logging, but doing the reporting/analysis on the
> central host.  That way, I can see a user across the Enterprise (or at
> least in the Linux hosts), but with all the power of ausearch for
> refining the report.

That is in the works...

> Ideally, I would do an ausearch -ts <date> -te 
<date> --raw --config-to=<hostname.ausearch.config> and it would do
> things like saving the syscall lookup table,

This is actually inside libaudit for all arches.

> lookup users referenced in the reported audit trail, 

uid & gid are based on the host's /etc/nsswitch.conf settings. If file, then 
its the local passwd/group files. If not, you have a central uid database.

> and resolve IP addresses references in the reported audit trail.

Hmm. As long as systems don't get changed too much, this should be resolvable 
from anything that has DNS access.

> Maybe one config file could be written for each data type in an existing
> format (e.g. users in /etc/passwd format, hosts in /etc/hosts format, etc.). 
> I'm mainly after whether or not anyone has considered extending ausearch for
> this kind of processing?

Sort of. I am working towards central logging. Getting the new event 
dispatcher completed is the first step. But I haven't looked at storing user 
and gid away yet. The calls that I'm using don't really allow substituting a 
new passwd or group file. So, I'd have to change all that code. But if you 
have an enterprise setup, you shouldn't be deleting user IDs to keep from 
having a collision down the road.

> This way, an archive of raw logs could be kept along with the exact
> system configuration which allows offloading the audit trail analysis to
> a trusted location, rather than risk side effects from a rootkit.

Yep.

-Steve