Audit Prelude Logout Tracking

[Steve Grubb]

On Thursday 19 February 2009 10:24:58 am LC Bruzenak wrote:
> On Thu, 2009-02-19 at 09:36 -0500, Steve Grubb wrote:
> > On Thursday 19 February 2009 09:26:28 am Dan Gruhn wrote:
> > > Although this seemed like the right place to look, I don't see
> > > USER_LOGOUT events in my audit logs,
> >
> > They are not used. I decided later that it was not needed for analysis.
> > When you login, there is always a session open event (user_start). This
> > is associated with a user_login event. So, when you see the session
> > closed event (user_end), the logout has occurred.
>
> So for IDS events we have only console logins, not logouts, and no ssh
> events?

yes, we have login events for IDS, because you could have failed logins or 
logins under an account you thought was deactivated. The logout doesn't have 
any security checks or permissions that have to be granted. I think the time 
accounting aspect is best left to other utilities designed for that.


> > 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?


> Don't the kernel oopses do the same thing?

Nope. When the kernel oopses, everything halts.


> Since the audit-viewer is not network-capable, we need more info in
> the prelude listings.

The audit viewer should work against aggregate logs.


> 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.


> 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.

-Steve