From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: audit-1.7.16 released Date: Mon, 16 Nov 2009 17:52:24 -0600 Message-ID: References: <200910171155.43836.sgrubb@redhat.com> <200910301056.20700.sgrubb@redhat.com> <1258161262.5355.214.camel@lcb> <200911161059.05503.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <200911161059.05503.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit List-Id: linux-audit@redhat.com On Mon, Nov 16, 2009 at 9:59 AM, Steve Grubb 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