Re: Audit Prelude Logout Tracking

[LC Bruzenak <lenny@magitekltd.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