Way too many logs!

Way too many logs!

[Jeremy Leonard]

Here are the rules I'm using:

 -D 
-b 8096 
-a exit,always -S open -F success=0 -k RULE1 
-a exit,always -S unlink -S rmdir -k RULE2 
-w /etc/auditd.conf -k RULE3 
-w /etc/audit.rules -k RULE4 
-a exit,always -S acct -S reboot -S swapon -k RULE5 
-a exit,always -S settimeofday -S setrlimit -S setdomainname -k RULE6 
-a exit,always -S sched_setparam -S sched_setscheduler -k RULE7 
-a exit,always -S chmod -S fchmod -S chown -S fchown -k RULE8 
-a exit,always -S lchown -k RULE9


Here is the output of aureport: 

Summary Report ====================== 
Range of time: 04/25/08 16:37:44.116 - 04/25/08 16:47:29.266 
Number of changes in configuration: 22 
Number of changes to accounts, groups, or roles: 0 
Number of logins: 0 Number of failed logins: 0 
Number of users: 2 Number of terminals: 4 Number of host names: 2 
Number of executables: 33 Number of files: 693 
Number of AVC denials: 0 Number of MAC events: 0 
Number of failed syscalls: 4052 
Number of anomaly events: 0 
Number of responses to anomaly events: 0 
Number of crypto events: 0 
Number of process IDs: 1428 
Number of events: 1444530 


This is 475mb in ten minutes! 

Here is how the rule hits add up: 

RULE1: 4052 
RULE2: 601 
RULE3: 9 
RULE4: 1 
RULE5: 0 
RULE6: 40 
RULE7: 1438239 
RULE8: 1503 
RULE9: 0 

Here is one of the log entries I have so many of. 

type=SYSCALL msg=audit(04/25/08 16:37:48.568:194518) : arch=i386 syscall=_newselect per=400000 success=yes exit=0 a0=13 a1=f692e220 a2=0 a3=0 items=0 ppid=1 pid=4012 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) comm=savd exe=/opt/sophos-av/engine/_/savd.0 subj=unconstrained key="RULE7" 

How can I exclude this so it doesn't get logged? 

The rules I have above are required by the government. DIACAP STIG

Thanks!

Re: Way too many logs!

[Steve Grubb]

On Friday 09 May 2008 16:20:44 Jeremy Leonard wrote:
> How can I exclude this so it doesn't get logged?
>
> The rules I have above are required by the government. DIACAP STIG

Do you need to log all changes to the scheduler? Or just the changes caused by 
users? If the latter, you can cut back your events like this:

-a exit,always -S sched_setparam -S sched_setscheduler -F auid>=500 -k RULE7


-Steve

Re: Way too many logs!

[Steve Grubb]

On Friday 09 May 2008 16:43:38 Steve Grubb wrote:
> > The rules I have above are required by the government. DIACAP STIG
>
> Do you need to log all changes to the scheduler? Or just the changes caused
> by users? If the latter, you can cut back your events like this:
>
> -a exit,always -S sched_setparam -S sched_setscheduler -F auid>=500 -k
> RULE7


I should mention the above rule is probably not correct. It better to state it
this way:

a exit,always -F arch=b32 -S sched_setparam -S sched_setscheduler -F auid>=500 -F auid!=4294967295 -k RULE7
a exit,always -F arch=b64 -S sched_setparam -S sched_setscheduler -F auid>=500 -F auid!=4294967295 -k RULE7

The reason why is that you also have to check for the unset auid and set
a rule for each arch if its a bi-arch system (x86_64).

-Steve

Re: Way too many logs!

[Valdis.Kletnieks]

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

On Fri, 09 May 2008 16:20:44 EDT, Jeremy Leonard said:
> -a exit,always -S sched_setparam -S sched_setscheduler -k RULE7 

> type=SYSCALL msg=audit(04/25/08 16:37:48.568:194518) : arch=i386 syscall=_newselect 

OK, I'll bite - why is a select() syscall tripping sched_setparam or sched_setschdeduler?

Or more importantly - are those two cutting audit events for the wrong reasons?

(In other words, should the kernel be doing the "trim it to only user-initiated
changes" that Steve Grubb suggested 'uid>500' as a workaround?

[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

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

Re: Way too many logs!

[Steve Grubb]

On Friday 09 May 2008 17:29:04 Valdis.Kletnieks@vt.edu wrote:
> On Fri, 09 May 2008 16:20:44 EDT, Jeremy Leonard said:
> > -a exit,always -S sched_setparam -S sched_setscheduler -k RULE7
> >
> > type=SYSCALL msg=audit(04/25/08 16:37:48.568:194518) : arch=i386
> > syscall=_newselect
>
> OK, I'll bite - why is a select() syscall tripping sched_setparam or
> sched_setschdeduler?

This record has a personality bit set unlike most events I ever see:

"arch=i386 syscall=_newselect per=400000"

I don't know if that is affecting the syscalls or not. Assuming it doesn't, 
_newselect only occurs on ppc as far as I know. Its syscall 142. On x86_64, 
sched_setparam is syscall 142. Not sure if that is the connection or not. But 
something is wrong in this audit event. :)  Also notice that the subject is 
unconstrained, so they must be running some special SE Linux policy or have a 
very unique kernel.

> Or more importantly - are those two cutting audit events for the wrong
> reasons?

Yeah, could be. I think I'd also want to audit the setting of the personality 
as that could be an attempt at masking the real actions of the user. Most 
systems never do this. If you have a system doing it, you might want to keep 
an eye on that.

-Steve

RE: Way too many logs!

[troy.s.curtis]

I don't typically monitor this list too closely which is why this is so
late but I might have a rule to help you trim things down.  This has so
far passed muster for NISPOM, but I'm not too familiar with DIACAP STIG
(yet, it's coming I think!).

Once you get your RULE7 trimmed down you may run into an excessive
number of unsuccessful open calls.  Especially if your systems are used
for any kind of develop (like mine).  The reason is that as your shell
searches through the path looking for an executable you get lots of
failures due to it not existing in various places.  I think you may not
run into too many issues with an actual shell because they typically
cache the locations, but running something like Make hits them all the
time. 

Anyway, to cut down on those and be able to defend it you can exclude
failures due to non-existence:

-a exit,always -S open -F success=0 -f exit!=-2

It looks like maybe you can use the actual errno here, but maybe not on
my old version?  But I'm using the above rule on a RHEL 4 box
successfully.  It pretty much single handedly took our logs from
unmanageable (not to mention a MAJOR performance hit for compiles) to
usable.  

Troy Curtis, Jr.

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Jeremy Leonard
Sent: Friday, May 09, 2008 3:21 PM
To: linux-audit@redhat.com
Subject: Way too many logs!

Here are the rules I'm using:

 -D 
-b 8096 
-a exit,always -S open -F success=0 -k RULE1 
-a exit,always -S unlink -S rmdir -k RULE2 
-w /etc/auditd.conf -k RULE3 
-w /etc/audit.rules -k RULE4 
-a exit,always -S acct -S reboot -S swapon -k RULE5 
-a exit,always -S settimeofday -S setrlimit -S setdomainname -k RULE6 
-a exit,always -S sched_setparam -S sched_setscheduler -k RULE7 
-a exit,always -S chmod -S fchmod -S chown -S fchown -k RULE8 
-a exit,always -S lchown -k RULE9


Here is the output of aureport: 

Summary Report ====================== 
Range of time: 04/25/08 16:37:44.116 - 04/25/08 16:47:29.266 
Number of changes in configuration: 22 
Number of changes to accounts, groups, or roles: 0 
Number of logins: 0 Number of failed logins: 0 
Number of users: 2 Number of terminals: 4 Number of host names: 2 
Number of executables: 33 Number of files: 693 
Number of AVC denials: 0 Number of MAC events: 0 
Number of failed syscalls: 4052 
Number of anomaly events: 0 
Number of responses to anomaly events: 0 
Number of crypto events: 0 
Number of process IDs: 1428 
Number of events: 1444530 


This is 475mb in ten minutes! 

Here is how the rule hits add up: 

RULE1: 4052 
RULE2: 601 
RULE3: 9 
RULE4: 1 
RULE5: 0 
RULE6: 40 
RULE7: 1438239 
RULE8: 1503 
RULE9: 0 

Here is one of the log entries I have so many of. 

type=SYSCALL msg=audit(04/25/08 16:37:48.568:194518) : arch=i386
syscall=_newselect per=400000 success=yes exit=0 a0=13 a1=f692e220 a2=0
a3=0 items=0 ppid=1 pid=4012 auid=unknown(4294967295) uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none)
comm=savd exe=/opt/sophos-av/engine/_/savd.0 subj=unconstrained
key="RULE7" 

How can I exclude this so it doesn't get logged? 

The rules I have above are required by the government. DIACAP STIG

Thanks!



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit