Auditd and Watches

Auditd and Watches

[Simmons Jr,Felix]

[-- Attachment #1.1: Type: text/plain, Size: 3871 bytes --]

All,

This is my first post to the list so...be gentle ;) Anyway, I'm trying
to get some monitoring going where I plan on using auditd to monitor
changes to files I deem important. Currently I have a watch on one file
(called important_file), I've given a key so I can find events related
to my one important file. Below is my watch:

[root@XXXX-22 ~]# auditctl -l
No rules
AUDIT_WATCH_LIST: dev=104:2, path=/var/tmp/important_test,
filterkey=test-file, perms=wa, valid=0

I've got no rules in my audit.rules (except -D and the -b 256 default).

My question is this (about time eh?) even though the only rule I have in
my rules is a single watch on a file, I'm getting all sorts of other
events in my /var/log/audit/audit.log. A lot of it are don't care items
at this phase and would only aid in growing my log files. Is there
something I'm missing that can turn off the additional chatter in the
logs? Below are some examples:

type=USER_ACCT msg=audit(05/24/2007 08:44:27.341:8311) : user pid=5633
uid=root auid=unknown(4294967295) msg='PAM accounting:
user=scrubbeduserid exe="/usr/sbin/sshd"
(hostname=cnu448f4g2.edwardjones.com, addr=XXX.XXX.XXX.146, terminal=ssh
result=Success)'
----
type=LOGIN msg=audit(05/24/2007 08:44:27.368:8312) : login pid=5640
uid=root old auid=unknown(4294967295) new auid=scrubbeduserid
----
type=USER_START msg=audit(05/24/2007 08:44:27.370:8313) : user pid=5640
uid=root auid=scrubbeduserid msg='PAM session open: user=scrubbeduserid
exe="/usr/sbin/sshd" (hostname=cnu448f4g2.edwardjones.com,
addr=XXX.XXX.XXX.146, terminal=ssh result=Success)'
----
type=CRED_REFR msg=audit(05/24/2007 08:44:27.373:8314) : user pid=5640
uid=root auid=scrubbeduserid msg='PAM setcred: user=scrubbeduserid
exe="/usr/sbin/sshd" (hostname=cnu448f4g2.edwardjones.com,
addr=XXX.XXX.XXX.146, terminal=ssh result=Success)'
----
type=USER_LOGIN msg=audit(05/24/2007 08:44:27.382:8315) : user pid=5633
uid=root auid=unknown(4294967295) msg='uid=7532: exe="/usr/sbin/sshd"
(hostname=cnu448f4g2.edwardjones.com, addr=XXX.XXX.XXX.146,
terminal=/dev/pts/1 res=success)'
----
type=USER_AUTH msg=audit(05/24/2007 08:44:37.379:8316) : user pid=5698
uid=scrubbeduserid auid=scrubbeduserid msg='PAM authentication:
user=scrubbeduserid exe="/usr/local/bin/priv-escalator"
(hostname=nldg-22.appl.devjones.com, addr=XXX.XXX.XXX.186,
terminal=/dev/pts/1 result=Success)'
----
type=USER_ACCT msg=audit(05/24/2007 08:44:37.384:8317) : user pid=5698
uid=scrubbeduserid auid=scrubbeduserid msg='PAM accounting:
user=scrubbeduserid exe="/usr/local/bin/priv-escalator"
(hostname=nldg-22.appl.devjones.com, addr=XXX.XXX.XXX.186,
terminal=/dev/pts/1 result=Success)'
----
type=USER_AUTH msg=audit(05/24/2007 08:44:41.884:8318) : user pid=5728
uid=root auid=unknown(4294967295) msg='PAM authentication: user=root
exe="/bin/su" (hostname=?, addr=?, terminal=pts/3 result=Success)'
----
type=USER_ACCT msg=audit(05/24/2007 08:44:41.889:8319) : user pid=5728
uid=root auid=unknown(4294967295) msg='PAM accounting: user=root
exe="/bin/su" (hostname=?, addr=?, terminal=pts/3 result=Success)'
----
type=USER_START msg=audit(05/24/2007 08:44:41.890:8320) : user pid=5728
uid=root auid=unknown(4294967295) msg='PAM session open: user=root
exe="/bin/su" (hostname=?, addr=?, terminal=pts/3 result=Success)'
----
type=CRED_ACQ msg=audit(05/24/2007 08:44:41.890:8321) : user pid=5728
uid=root auid=unknown(4294967295) msg='PAM setcred: user=root
exe="/bin/su" (hostname=?, addr=?, terminal=pts/3 result=Success)'

Basically I'm trying to chunk the logs down so my host based ids can
snag the events and alert accordingly. I'm pretty new to linux auditd
and I'm coming from the Solaris BSM Audit school of thought. Steve if
you're reading this, thanks for your time and effort keeping linux
auditd going.

-Felix

[-- Attachment #1.2: Type: text/html, Size: 5473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Auditd and Watches

[Steve Grubb]

On Thursday 24 May 2007 09:53, Simmons Jr,Felix wrote:
> [root@XXXX-22 ~]# auditctl -l
> No rules
> AUDIT_WATCH_LIST: dev=104:2, path=/var/tmp/important_test,
> filterkey=test-file, perms=wa, valid=0

This seems slightly odd output. What kernel and audit package are you using?

> My question is this (about time eh?) even though the only rule I have in
> my rules is a single watch on a file, I'm getting all sorts of other
> events in my /var/log/audit/audit.log. A lot of it are don't care items
> at this phase and would only aid in growing my log files. Is there
> something I'm missing that can turn off the additional chatter in the
> logs?

Yes if you are using 2.6.16 and later kernels.

/usr/include/libaudit.h has this table:

 * 1000 - 1099 are for commanding the audit system
 * 1100 - 1199 user space trusted application messages
 * 1200 - 1299 messages internal to the audit daemon
 * 1300 - 1399 audit event messages
 * 1400 - 1499 kernel SE Linux use
 * 1500 - 1599 AppArmor events
 * 1600 - 1699 kernel crypto events
 * 1700 - 1799 kernel anomaly records
 * 1800 - 1999 future kernel use (maybe integrity labels and related events)
 * 2001 - 2099 unused (kernel)
 * 2100 - 2199 user space anomaly records
 * 2200 - 2299 user space actions taken in response to anomalies
 * 2300 - 2399 user space generated LSPP events
 * 2400 - 2499 user space crypto events
 * 2500 - 2999 future user space (maybe integrity labels and related events)

So, you could do:

-a exclude,always -F msgtype>=1100 -F msgtype<=1299
-a exclude,always -F msgtype>=1400 -F msgtype<=2999

Although I recommend widening the choices to allow SE Linux AVC's through. And 
note that if you try to type this at a command prompt, you will need quotes 
around "msgtype>=1100" since <> are something the shell will interpret.

> Basically I'm trying to chunk the logs down so my host based ids can
> snag the events and alert accordingly.

Yes, I am working on a IDS/IPS system, too. But it doesn't use the logs, 
rather it uses the realtime interface so it can react in realtime. I made a 
presentation about it at the Red Hat Summit a couple weeks ago and put my 
presentation here:

http://people.redhat.com/sgrubb/audit/summit07_audit_ids.odp

To some extent that is what's driving development and requirements for the 
audit event dispatcher and the audit parsing library.

-Steve

RE: Auditd and Watches

[Simmons Jr,Felix]

On Thursday 24 May 2007 09:53, Simmons Jr,Felix wrote:
>> [root@XXXX-22 ~]# auditctl -l
>> No rules
>> AUDIT_WATCH_LIST: dev=104:2, path=/var/tmp/important_test, 
>> filterkey=test-file, perms=wa, valid=0

>This seems slightly odd output. What kernel and audit package are you
using? 
audit-1.0.14-1.EL4 (I know it's a little old but its what we already
rolled out in our distro from redhat).
As far as kernel - 2.6.9-42.0.10.Elsmp  (I'm on 64-bit architecture).

>Yes, I am working on a IDS/IPS system, too. But it doesn't use the
logs, rather it uses the realtime interface so it can react in realtime.
I made a 
>presentation about it at the Red Hat Summit a couple weeks ago and put
my presentation here:

Thanks again, I'll give your recommendation a try. So I take it by
reacting realtime as the event is processed by auditd and the event
dispatcher it eliminates the potential for an event to be missed due to
buffering or some other reason for the event not making it to the
audit.log quick enough. Interesting, that then almost makes it so the
audit.log can be rotated out a lot quicker and the true important events
stored in the ids system. 

That's kind of what we do with solaris, with bsm the logs pull so much
data that they grow very quick, with our ids we have the logs rotate out
once they reach 40 megs and the old log is removed while the ids agent
then watches the new file. Any key events are pulled to the ids database
and retained. 

Thanks,

Felix Simmons
Edward Jones
IS System Security Team
(314) 515-1295




-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Thursday, May 24, 2007 9:10 AM
To: linux-audit@redhat.com
Cc: Simmons Jr,Felix
Subject: Re: Auditd and Watches

On Thursday 24 May 2007 09:53, Simmons Jr,Felix wrote:
> [root@XXXX-22 ~]# auditctl -l
> No rules
> AUDIT_WATCH_LIST: dev=104:2, path=/var/tmp/important_test, 
> filterkey=test-file, perms=wa, valid=0

This seems slightly odd output. What kernel and audit package are you
using?

> My question is this (about time eh?) even though the only rule I have 
> in my rules is a single watch on a file, I'm getting all sorts of 
> other events in my /var/log/audit/audit.log. A lot of it are don't 
> care items at this phase and would only aid in growing my log files. 
> Is there something I'm missing that can turn off the additional 
> chatter in the logs?

Yes if you are using 2.6.16 and later kernels.

/usr/include/libaudit.h has this table:

 * 1000 - 1099 are for commanding the audit system
 * 1100 - 1199 user space trusted application messages
 * 1200 - 1299 messages internal to the audit daemon
 * 1300 - 1399 audit event messages
 * 1400 - 1499 kernel SE Linux use
 * 1500 - 1599 AppArmor events
 * 1600 - 1699 kernel crypto events
 * 1700 - 1799 kernel anomaly records
 * 1800 - 1999 future kernel use (maybe integrity labels and related
events)
 * 2001 - 2099 unused (kernel)
 * 2100 - 2199 user space anomaly records
 * 2200 - 2299 user space actions taken in response to anomalies
 * 2300 - 2399 user space generated LSPP events
 * 2400 - 2499 user space crypto events
 * 2500 - 2999 future user space (maybe integrity labels and related
events)

So, you could do:

-a exclude,always -F msgtype>=1100 -F msgtype<=1299 -a exclude,always -F
msgtype>=1400 -F msgtype<=2999

Although I recommend widening the choices to allow SE Linux AVC's
through. And note that if you try to type this at a command prompt, you
will need quotes around "msgtype>=1100" since <> are something the shell
will interpret.

> Basically I'm trying to chunk the logs down so my host based ids can 
> snag the events and alert accordingly.

Yes, I am working on a IDS/IPS system, too. But it doesn't use the logs,
rather it uses the realtime interface so it can react in realtime. I
made a presentation about it at the Red Hat Summit a couple weeks ago
and put my presentation here:

http://people.redhat.com/sgrubb/audit/summit07_audit_ids.odp

To some extent that is what's driving development and requirements for
the audit event dispatcher and the audit parsing library.

-Steve

Re: Auditd and Watches

[Steve Grubb]

On Thursday 24 May 2007 11:32, Simmons Jr,Felix wrote:
> >> AUDIT_WATCH_LIST: dev=104:2, path=/var/tmp/important_test,
> >> filterkey=test-file, perms=wa, valid=0
> >
> >This seems slightly odd output. What kernel and audit package are you
>> using?
>
> audit-1.0.14-1.EL4 (I know it's a little old but its what we already
> rolled out in our distro from redhat).
> As far as kernel - 2.6.9-42.0.10.Elsmp  (I'm on 64-bit architecture).

OK, I guess its been a while since I saw what came out of the RHEL4 rule 
listing.

> >Yes, I am working on a IDS/IPS system, too. But it doesn't use the
>
> logs, rather it uses the realtime interface so it can react in realtime.
> I made a
>
> >presentation about it at the Red Hat Summit a couple weeks ago and put
> > my presentation here:
>
> Thanks again, I'll give your recommendation a try.

Regarding RHEL4, the audit-1.0.15 package has the realtime interface. It does 
not have an event dispatcher yet, but it will use the one we settle on for 
RHEL5.1. In the meantime, there is a program, skeleton.c in the audit package 
that you can use to write your own event collector.

Also, the rules I gave you to exclude audit events do not work on the RHEL4 
kernel. So, writing a program to process only interesting events would be 
your best option on RHEL4 and then disregard the logs altogether.

> So I take it by reacting realtime as the event is processed by auditd and
> the event dispatcher it eliminates the potential for an event to be missed
> due to buffering or some other reason for the event not making it to the
> audit.log quick enough. 

I suppose, but there is very little memory allocating done in the audit 
daemon. What I consider the most important feature of the realtime interface 
is that it allows you to write a program to get the events as they occur and 
do something with them. You do not have to write a cron job which would be 
slow to react or do something like tail which doesn't work when the logs get 
rotated.

> Interesting, that then almost makes it so the audit.log can be rotated out a
> lot quicker and the true important events stored in the ids system.

Sure. You can also tell the audit daemon not to log anything to disk if you 
really trust the realtime path, too.

-Steve