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 [email protected] -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
