From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: Audit Prelude Logout Tracking Date: Thu, 19 Feb 2009 13:49:06 -0600 Message-ID: <1235072946.11692.208.camel@homeserver> References: <499C848C.6020401@groupw.com> <200902190936.11184.sgrubb@redhat.com> <1235057098.11692.163.camel@homeserver> <200902191339.23110.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200902191339.23110.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@redhat.com List-Id: linux-audit@redhat.com On Thu, 2009-02-19 at 13:39 -0500, Steve Grubb wrote: > > > > However...what if gdm dies? What if the kernel oopses? You have no ending > > > marker. So, what I did recently was patch upstart so that it logs system > > > boot & shutdown events. This way you can tell when the system > > > malfunctioned. The logic for the analysis is in the aulast program, which > > > is in 1.7.11. However, you don't have a patched upstart daemon for RHEL5 > > > since it uses the older SysVinit package. > > > > If gdm dies I thought it would throw an anomaly event. > > Nope. X programs catch SIGSEGV and don't actually dump core. So, we don't get > any notification. But still, would you associate the anomaly event with the > logging out of a user? No - but that is hopefully an exception (no pun intended) and could be taken into account. With logout records, I'd notice the lack of such...and a gdm SIGSEGV might be worth looking into. Believe it or not, my end users might not report this. Hey - good idea! Maybe I could have some application crash on each logout so I could get an alert! :) > > Since the audit-viewer is not network-capable, we need more info in > > the prelude listings. > > The audit viewer should work against aggregate logs. On the aggregation machine it will. In my deployment, which I fully realize may not be representative of the rest of the world, the person(s) looking at the prelude stuff is doing so over a network. The actual machine is locked up in a server room maybe in another building. The computer this person uses daily is not Linux and cannot be modified to run an X server or any other way I know to remotely use the audit-viewer. Or maybe I miss the point. :) But their browser can access the prelude data, and as such can give them a warm fuzzy that there is overall "security healthiness" based on the info there. > > > As I've said before, if logouts are not IDS events why are logins? > > Because it requires the act of granting permission. Someone could be logging > in from a forbidden host, or a locked acct, or trying to guess the password. > If they get in, you have problems. > Agree with the above, but I thought that even non-locked accounts logging in from approved hosts under normal conditions generated a "INFO" alert. Why that then? > > > Dan, as Steve says, aulast provides the analysis. > > However, either I read it wrong or it ignores root: > > That was fixed in https://fedorahosted.org/audit/changeset/241 a couple weeks > ago. Awesome; thanks! LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com