On Thu, 2008-08-14 at 18:16 -0400, DJ Delorie wrote: > > What I'm getting is that in addition to kernel-generated local events > > the auditd would also receive signals as well as tcp-based events from > > other sources. Would this be the way of implementing multi-source audit > > aggregation or is it something different? > > The net result is to aggregate audit logs from many systems onto one > central audit server. Remote audit messages have the new "node=" tag > on them so you know where they came from. > > I.e. you configure audisp-remote.conf like this: > > remote_server = 10.2.3.4 > port = 1237 > > And the central server (10.2.3.4 in this example) like this: > > tcp_listen_port = 1237 > > And then the client sends all audit messages to the server, where > they're logged to disk. > > This is similar to centralized syslog logging.
Maybe in theory...but a couple of differences matter a bit: 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. 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. > > The event loop change I linked to is a neccessary design change > prerequisite to this one, since the listener adds (potentially) many > descriptors which will need to be serviced. The loop now services > four types of events: local signals, local netlink, the listen socket > (for new connections), and client sockets (for incoming audit > messages). Thank you; I get it now. This is about to get interesting! :) 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. My one auditd machine gets very busy occasionally - I sometimes drop events (rather than abort for a development machine) even after ratcheting up my event queue to 8K. Often this is due to an error I've introduced with too-general rules, so this is also not definitive. Now the question is what happens if the network hiccups and I cannot send the events from a client? I could still write the events to the local disk, but them getting them onto the intended aggregator is now tricky right? Will the sender keep track of the last event sent and recover once the connection is restored? 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. OK, so - thanks again for the explanation and I look forward to testing this out soon! Thx, LCB. -- LC (Lenny) Bruzenak [EMAIL PROTECTED] -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
