Re: Audit Prelude Logout Tracking
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(a)magitekltd.com