Re: [PATCH] Add auditd listener and remote audit protocol
> This is similar to centralized syslog logging.
Maybe in theory...but a couple of differences matter a bit:
Right, I was just trying to get the basic idea across ;-)
1: Yesterday I saved 95MB of audit data. The past 3 days' syslog
is so
far under 3.5MB. I believe my audit data will grow more as my system
matures and gets tested. I don't know if those numbers are anywhere
close to representative or not though.
My machine is doing about 5M/day. Most of it is cron.
2: If I lose a portion of syslog data it doesn't hurt me too
much
usually; not the case if I rely on my audit data to be complete and
accurate.
Understood.
This is about to get interesting! :)
Let's hope so :-)
Not certain why I didn't get it the first time, but for some
reason I
had not considered sending the events into the auditd loop.
I was thinking of just aggregating the logfiles. Now it makes sense.
Note that it injects it *after* the plugins are called; the aggregator
will not pass along remote messages to its own plugins.
Now the question is what happens if the network hiccups and I cannot
send the events from a client?
The basis for passing failure modes from the plugins back up to auditd
is still up for discussion; in the patch those functions are empty.
In general, though, if the network hangs, eventually the queues fill
up and the usual queue-filled rules apply.
There are three likely failure modes:
* network timeout. Eventually, the queues (and pipes) fill up and
local panic sets in.
* network failure (aggregator reboots or restarts, usually) -
connection is closed or sync is lost, we know about it immediately.
Currently audispd-remote just exits when that happens.
* remote error - the aggregator has an error (disk full, etc) and
passes it back to the clients. The clients act on it, but currently
those functions are empty.
Of course, a full review of the failure modes and actions will be
needed at some point. Plus we have to decide if we want to feed the
status back to auditd and use its configuration, or have a separate
configuration in audisp-remote, for what to do about each error case.
Will the sender keep track of the last event sent and recover once
the connection is restored?
The event that gets the network error gets lost at the moment (and
every event after it), and the code currently doesn't have a "try
again" mechanism if it loses connectivity. Again, the whole "what do
we do when a problem happens" is still somewhat TBD.
Note that you can still log to the local disk *as well as* to the
remote aggregator.
I'm not disputing the approach, just trying to look down the
road
knowing problems I've experienced myself.
:-)
There are some definite benefits to this approach I see also - the
log files now are "blended" and you don't have to do any special
directory hierarchy to accommodate the other events, for one.
Well, you *could* based on the node= field, if you wanted to code it
that way. At least they're no longer on the machine being
attacked/saturated/whatever, if/when that happens.