On Mon, Nov 16, 2009 at 9:59 AM, Steve Grubb <[email protected]> wrote: > On Friday 13 November 2009 08:14:22 pm LC Bruzenak wrote: >> Thinking about the client network connection timeout... >> >> I am wondering if this is a serious enough condition to warrant >> inserting an audit event in addition to the syslog. > > If you have 1000 machines and the switch dies, you will have 4000 events when > everything reconnects. The server will record its own events and the clients > will record duplicate copies from their end. The audit trail has not been lost > or anything bad happened. I think this is more of a systems management issue > than security.
And for most systems I agree. For me, if a switch fails and I get 4000 events that is acceptable. Actually, on my systems, if a switch dies the clients will all start shutting down. Then after it is fixed, and they reboot, they will resend their events the way you suggested - by grabbing all of them from the estimated network send error time and push them into audisp-remote (BTW works great; thanks!). > >> For me it is, because sending a termination event from the client is >> both difficult and unreliable, and I am supposed to provide client >> (sender) startup/shutdown data. > > You should have daemon start/end events at the aggregator. Are they not > getting there? Also, the aggregator should have matching connect/disconnect > events. > I am not getting the DAEMON_END events. In an orderly shutdown, the network shuts down before the audit daemon does. In a catastrophic or otherwise unintended termination, obviously there it would be of benefit. Thx, LCB. -- LC (Lenny) Bruzenak -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
