Audit Prelude Logout Tracking

Audit Prelude Logout Tracking

[Dan Gruhn]

I''m working on an X86_64  RHEL 5.2 system and for NISPOM Chapt. 8 I'm 
looking to modify the audisp-prelude plugin so that I can get logout 
events displayed.

I see the information in the audit.log as USER_END and have done a small 
mod in the handle_event routine in audisp-prelude.c so that it looks for 
AUDIT_USER_END but I've run across the following things:

1) sshd goes through a login/logout cycle ending in USER_END and all is 
good.
node=node01 type=USER_END msg=audit(1234979707.894:203): user pid=7422 
uid=0 auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 
msg='PAM: session close acct="root" : exe="/usr/sbin/sshd" 
(hostname=master, addr=10.1.4.100, terminal=ssh res=success)'



2) gdm-binary goes through the same login/logout cycle, but on the 
USER_END audit message it is missing some information, in particular the 
source hostname:
node=master type=USER_END msg=audit(1234988646.589:364): user pid=6868 
uid=0 auid=0 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='PAM: 
session close acct="root" : exe="/usr/sbin/gdm-binary" (hostname=?, 
addr=?, terminal=:0 res=success)'

3) When crond runs, it goes through a similar cycle (but without the 
USER_LOGIN step) ending with USER_END
node=master type=USER_END msg=audit(1234989001.710:371): user pid=9517 
uid=0 auid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: 
session close acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, 
terminal=cron res=success)'

I want to ignore the crond operations and be able to fill in the 
information from gdm-binary.  Has any one done this prelude logout 
tracking before or have any ideas how I can proceed.

As always, a pointer to more information is quite acceptable.

Dan

Re: Audit Prelude Logout Tracking

[LC Bruzenak]

On Wed, 2009-02-18 at 16:58 -0500, Dan Gruhn wrote:
> I''m working on an X86_64  RHEL 5.2 system and for NISPOM Chapt. 8 I'm 
> looking to modify the audisp-prelude plugin so that I can get logout 
> events displayed.
> 
> I see the information in the audit.log as USER_END and have done a small 
> mod in the handle_event routine in audisp-prelude.c so that it looks for 
> AUDIT_USER_END but I've run across the following things:
> 
> 1) sshd goes through a login/logout cycle ending in USER_END and all is 
> good.
> node=node01 type=USER_END msg=audit(1234979707.894:203): user pid=7422 
> uid=0 auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 
> msg='PAM: session close acct="root" : exe="/usr/sbin/sshd" 
> (hostname=master, addr=10.1.4.100, terminal=ssh res=success)'
> 
> 
> 
> 2) gdm-binary goes through the same login/logout cycle, but on the 
> USER_END audit message it is missing some information, in particular the 
> source hostname:
> node=master type=USER_END msg=audit(1234988646.589:364): user pid=6868 
> uid=0 auid=0 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='PAM: 
> session close acct="root" : exe="/usr/sbin/gdm-binary" (hostname=?, 
> addr=?, terminal=:0 res=success)'
> 
> 3) When crond runs, it goes through a similar cycle (but without the 
> USER_LOGIN step) ending with USER_END
> node=master type=USER_END msg=audit(1234989001.710:371): user pid=9517 
> uid=0 auid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='PAM: 
> session close acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, 
> terminal=cron res=success)'
> 
> I want to ignore the crond operations and be able to fill in the 
> information from gdm-binary.  Has any one done this prelude logout 
> tracking before or have any ideas how I can proceed.
> 
> As always, a pointer to more information is quite acceptable.
> 
> Dan
> 

Dan,

As I myself eventually learned, the hostname/addr info is only for
remote access information. The gdm process doesn't get that filled in,
nor does crond.

As for the logouts being sent to prelude, I preferred that as well but
no one (except me) felt that a logout was security-worthy in the context
of IDS events IIRC. I wanted them somewhat for the same reason - because
then it told a complete story. Also I believe there is a need due to
screenlocks - if someone else can login while your screen is locked then
there isn't a trace back to when they logged out. I haven't looked at
that for a while though; not sure it it is still possible.

I myself patch the audisp-prelude.c code so I can catch some application
events there and send to prelude as well.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: Audit Prelude Logout Tracking

[LC Bruzenak]

On Wed, 2009-02-18 at 16:44 -0600, LC Bruzenak wrote:
> On Wed, 2009-02-18 at 16:58 -0500, Dan Gruhn wrote:
> > I''m working on an X86_64  RHEL 5.2 system and for NISPOM Chapt. 8 I'm 
> > looking to modify the audisp-prelude plugin so that I can get logout 
> > events displayed.
> > 
> > I see the information in the audit.log as USER_END and have done a small 
> > mod in the handle_event routine in audisp-prelude.c so that it looks for 
> > AUDIT_USER_END but I've run across the following things:
> > 
> > 1) sshd goes through a login/logout cycle ending in USER_END and all is 
> > good.
> > node=node01 type=USER_END msg=audit(1234979707.894:203): user pid=7422 
> > uid=0 auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 
> > msg='PAM: session close acct="root" : exe="/usr/sbin/sshd" 
> > (hostname=master, addr=10.1.4.100, terminal=ssh res=success)'
> > 
> > 

Dan,

The other question I had was, I suppose you see the AUDIT_USER_LOGIN
event type which triggers the prelude event (in audisp-prelude.c). I
would think that the matching AUDIT_USER_LOGOUT would be what you want
right?

Can you find these events with ausearch like this?:

# ausearch -ts today -i -m USER_LOGIN
...and...
#ausearch -ts today -i -m USER_LOGOUT


LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: Audit Prelude Logout Tracking

[Dan Gruhn]

LC Bruzenak wrote:
> On Wed, 2009-02-18 at 16:44 -0600, LC Bruzenak wrote:
>   
>> On Wed, 2009-02-18 at 16:58 -0500, Dan Gruhn wrote:
>>     
>>> I''m working on an X86_64  RHEL 5.2 system and for NISPOM Chapt. 8 I'm 
>>> looking to modify the audisp-prelude plugin so that I can get logout 
>>> events displayed.
>>>
>>> I see the information in the audit.log as USER_END and have done a small 
>>> mod in the handle_event routine in audisp-prelude.c so that it looks for 
>>> AUDIT_USER_END but I've run across the following things:
>>>
>>> 1) sshd goes through a login/logout cycle ending in USER_END and all is 
>>> good.
>>> node=node01 type=USER_END msg=audit(1234979707.894:203): user pid=7422 
>>> uid=0 auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c1023 
>>> msg='PAM: session close acct="root" : exe="/usr/sbin/sshd" 
>>> (hostname=master, addr=10.1.4.100, terminal=ssh res=success)'
>>>
>>>
>>>       
>
> Dan,
>
> The other question I had was, I suppose you see the AUDIT_USER_LOGIN
> event type which triggers the prelude event (in audisp-prelude.c). I
> would think that the matching AUDIT_USER_LOGOUT would be what you want
> right?
>
> Can you find these events with ausearch like this?:
>
> # ausearch -ts today -i -m USER_LOGIN
> ...and...
> #ausearch -ts today -i -m USER_LOGOUT
>
>
> LCB
>
>   
LCB,

Thanks for the tip on the hostname/addr info is only for remote access 
information.

 Although this seemed like the right place to look, I don't see 
USER_LOGOUT events in my audit logs, this is why I mentioned the 
USER_END events.  Do you remember USER_LOGOUT working back when you 
tried before?

I am interested in the patches that you make to audisp-prelude.c.  Do 
you think they might be useful to me in my NISPOM quest?  If so, are 
they patches from 1.7.11 and could you send me a copy?

Thanks,

Dan

Re: Audit Prelude Logout Tracking

[Steve Grubb]

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.

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.

One thing to note, preikka/prelude is an IDS system. Not all audit events are 
IDS events. Only a handful really qualify as Intrusion Detection worthy. So, 
you really can't use prewikka as an audit log browser.

-Steve

Re: Audit Prelude Logout Tracking

[LC Bruzenak]

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?

> 
> 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.
Don't the kernel oopses do the same thing?

I have seen neither of these two events in the last several months
(thankfully). But I've seen many a login...

> 
> One thing to note, preikka/prelude is an IDS system. Not all audit events are 
> IDS events. Only a handful really qualify as Intrusion Detection worthy. So, 
> you really can't use prewikka as an audit log browser.

Agreed. It is (at least in my CONOPS) an early warning system. But the
people who are watching prelude events will not go digging through audit
data unless an alert triggers it. That or a security breach needing
investigation. Possibly fast login/logout pairs matter. Also at some
sites a logout each day is required by policy and a prelude check over
the LAN with a clicky-click interface is easy. An ssh in from a windows
machine by an occasional user, who doesn't remember the command or know
a forward slash from a backslash, to run a command is unlikely to be a
hit. Since the audit-viewer is not network-capable, we need more info in
the prelude listings.

As I've said before, if logouts are not IDS events why are logins?
Personally I'd prefer both. I will probably patch my audisp to include
them. The time taken to do that would be less than answering the "Why
are there no matching logouts?" for each site at which we
field...especially since I don't have a good answer. Although I
personally hold Steve in high regard, "Because Steve says so" probably
won't fly that great. :)

Dan, as Steve says, aulast provides the analysis. 
However, either I read it wrong or it ignores root:

[root@audit ~]# aulast
issm     tty1         ?                Tue Feb 17 05:35   gone - no
logout
issm     tty1         ?                Tue Feb 17 05:55   gone - no
logout
issm     tty1         ?                Tue Feb 17 06:22   gone - no
logout
issm     tty1         ?                Wed Feb 18 10:16 - 17:19  (07:02)
issm     pts/1        192.168.31.40    Thu Feb 19 02:36 - 02:36  (00:00)
[root@audit ~]# who
root     pts/0        2009-02-19 02:36 (192.168.31.40)

Also aureport has good metrics you can maybe put to use.
At some point I'd like to see the audit-viewer be made network-capable
(preferably the info be browser-accessed) and include these tools
visually.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: 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

Re: Audit Prelude Logout Tracking

[LC Bruzenak]

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

Re: Audit Prelude Logout Tracking

[LC Bruzenak]

On Thu, 2009-02-19 at 09:26 -0500, Dan Gruhn wrote:
> 
> LC Bruzenak wrote:
> > On Wed, 2009-02-18 at 16:44 -0600, LC Bruzenak wrote:
> >   
> LCB,
> 
> Thanks for the tip on the hostname/addr info is only for remote access 
> information.
> 
>  Although this seemed like the right place to look, I don't see 
> USER_LOGOUT events in my audit logs, this is why I mentioned the 
> USER_END events.  Do you remember USER_LOGOUT working back when you 
> tried before?

I thought that is what I saw previously, but it isn't there now. 
Only login/logout on the console gives these messages. 
I need to go back through some old email - I thought Steve patched this
a while back.

> 
> I am interested in the patches that you make to audisp-prelude.c.  Do 
> you think they might be useful to me in my NISPOM quest?  If so, are 
> they patches from 1.7.11 and could you send me a copy?

I'll gladly send you a copy off-list - the changes are specific to what
I'm doing. Basically I had to sub-format the user text in order to key
off what I wanted to send to prelude. 

You may need to incorporate something similar...unless of course between
us we can provide a non-intrusive patch Steve would accept which would
accommodate user-designated IDS events! :)

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com