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?
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(a)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