3:58 p.m.
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
4:44 p.m.
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(a)magitekltd.com
5:25 p.m.
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(a)magitekltd.com
8:26 a.m.
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
8:36 a.m.
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
9:24 a.m.
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(a)magitekltd.com
12:39 p.m.
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
1:49 p.m.
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
8:45 a.m.
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(a)magitekltd.com
6136
days inactive
6137
days old
linux-audit@lists.linux-audit.osci.io
8 comments
3 participants
participants (3)
-
Dan Gruhn -
LC Bruzenak -
Steve Grubb