8:53 a.m.
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
9:10 a.m.
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
10:32 a.m.
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
10:51 a.m.
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
6421
days inactive
6421
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Simmons Jr,Felix -
Steve Grubb