Re: Offline audit trail analysis
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