no logging of successful events?

no logging of successful events?

[Brian LaMere]

with the following auditd.conf and audit.rules, we generate MASSIVE logs
very quickly.  I don't care about successful audit events; I'm not
required to log them, and there's no way I could have the space for a
year's worth anyway.  So...why is it that "LIST_RULES: exit,always
success!=0 syscall=open" doesn't disregard the successful calls?  I can
still see them if I do an aureport.

The logs are simply too massive to keep; if I set the max_log_file to
much higher than 50 with 99 logs, an aureport takes eons.
Unfortunately, it needs to be that high to save even a day's worth of
logs when they're running certain programs.  Any suggestions?

----------------------
log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 3
flush = INCREMENTAL
freq = 20
num_logs = 50
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 20 
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
--------------------------
LIST_RULES: exit,always success!=0 syscall=open
LIST_RULES: exit,always syscall=rmdir,unlink
LIST_RULES: exit,always syscall=acct,swapon,reboot
LIST_RULES: exit,always syscall=setrlimit,settimeofday,setdomainname
LIST_RULES: exit,always syscall=sched_setparam,sched_setscheduler
LIST_RULES: exit,always syscall=chmod,fchmod,chown,fchown
LIST_RULES: exit,always syscall=lchown
LIST_RULES: exit,always watch=/etc/auditd.conf perm=rwxa
LIST_RULES: exit,always watch=/etc/audit.rules perm=rwxa
------------------------------------------

Re: no logging of successful events?

[Steve Grubb]

On Monday 18 August 2008 15:09:34 Brian LaMere wrote:
> So...why is it that "LIST_RULES: exit,always success!=0 syscall=open"
> doesn't disregard the successful calls? 

Because that means log the successful calls. If you only want the unsuccessful 
calls, I'd suggest success = 0. Its easy to confuse the success field with 
exits codes which return 0 for success. This question pops up every now and 
again.  :)

-Steve

Re: no logging of successful events?

[Eric Paris]

On Mon, 2008-08-18 at 15:18 -0400, Steve Grubb wrote:
> On Monday 18 August 2008 15:09:34 Brian LaMere wrote:
> > So...why is it that "LIST_RULES: exit,always success!=0 syscall=open"
> > doesn't disregard the successful calls? 
> 
> Because that means log the successful calls. If you only want the unsuccessful 
> calls, I'd suggest success = 0. Its easy to confuse the success field with 
> exits codes which return 0 for success. This question pops up every now and 
> again.  :)

Isn't that why man auditctl talks about success=no and success=yes?  So you don't have to remember?

Re: no logging of successful events?

[Brian LaMere]

was using a slightly older manpage, which doesn't include that helpful
clarification :)

Brian

On Mon, 2008-08-18 at 15:25 -0400, Eric Paris wrote:
> On Mon, 2008-08-18 at 15:18 -0400, Steve Grubb wrote:
> > On Monday 18 August 2008 15:09:34 Brian LaMere wrote:
> > > So...why is it that "LIST_RULES: exit,always success!=0 syscall=open"
> > > doesn't disregard the successful calls? 
> > 
> > Because that means log the successful calls. If you only want the unsuccessful 
> > calls, I'd suggest success = 0. Its easy to confuse the success field with 
> > exits codes which return 0 for success. This question pops up every now and 
> > again.  :)
> 
> Isn't that why man auditctl talks about success=no and success=yes?  So you don't have to remember?
> 

Re: no logging of successful events?

[Eric Paris]

On Mon, 2008-08-18 at 12:49 -0700, Brian LaMere wrote:
> was using a slightly older manpage, which doesn't include that helpful
> clarification :)
> 
> Brian
> 
> On Mon, 2008-08-18 at 15:25 -0400, Eric Paris wrote:
> > On Mon, 2008-08-18 at 15:18 -0400, Steve Grubb wrote:
> > > On Monday 18 August 2008 15:09:34 Brian LaMere wrote:
> > > > So...why is it that "LIST_RULES: exit,always success!=0 syscall=open"
> > > > doesn't disregard the successful calls? 
> > > 
> > > Because that means log the successful calls. If you only want the unsuccessful 
> > > calls, I'd suggest success = 0. Its easy to confuse the success field with 
> > > exits codes which return 0 for success. This question pops up every now and 
> > > again.  :)
> > 
> > Isn't that why man auditctl talks about success=no and success=yes?  So you don't have to remember?

Actually sgrubb tells me that the =yes and =no is actually bug in the
man page  :(

You should add it to auditctl steve   :)

-Eric

Re: no logging of successful events?

[Brian LaMere]

(boo for me not hitting reply-all before)

Fair enough, was just basing from the man page which says:

"       To see unsuccessful open call's:

       auditctl -a exit,always -S open -F success!=0"

So am I just not understanding the man page well?   Clearly I'll have to
take your word for it, you being the maintainer for RH and all, but it
might be the man page itself causing the confusion for lots of people.
Note that I actually got the line from the DoD requirements, which give
that line - if that line isn't present, then they determine that "the
audit system is not configured to audit failed attempts to access files
and programs."

If you're curious, the linux audit requirements in the DoD are publicly
available at
http://iase.disa.mil/stigs/checklist/unix_checklist_v5r1-13_20080715.ZIP

The specific control is defined in PDI GEN002720.  They have several
mistakes in that section (the HPUX stuff is wrong too) so I wouldn't be
remotely surprised to find there is an issue with the linux section.

And I just noticed that my example audit rules don't have the -F...on
the systems where it is a problem, the -F is there.

On Mon, 2008-08-18 at 15:18 -0400, Steve Grubb wrote:
> On Monday 18 August 2008 15:09:34 Brian LaMere wrote:
> > So...why is it that "LIST_RULES: exit,always success!=0 syscall=open"
> > doesn't disregard the successful calls? 
> 
> Because that means log the successful calls. If you only want the unsuccessful 
> calls, I'd suggest success = 0. Its easy to confuse the success field with 
> exits codes which return 0 for success. This question pops up every now and 
> again.  :)
> 
> -Steve

Re: no logging of successful events?

[Steve Grubb]

On Monday 18 August 2008 15:39:01 Brian LaMere wrote:
> (boo for me not hitting reply-all before)
>
> Fair enough, was just basing from the man page which says:
>
> "       To see unsuccessful open call's:
>
>        auditctl -a exit,always -S open -F success!=0"

I think that was patched at some point. The current man page in svn is right. 
But I think I should touch it up a bit.


> Note that I actually got the line from the DoD requirements, which give
> that line - if that line isn't present, then they determine that "the
> audit system is not configured to audit failed attempts to access files
> and programs."

The recent versions of the audit system ships with a stig.rules file that give 
what I believe to be a correct rule set. What the official docs say to do is 
another thing. :)  Take a look at that file and see how I do the unauthorized 
file access.

HTH

-Steve

Re: no logging of successful events?

[Brian LaMere]

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

> The recent versions of the audit system ships with a stig.rules file
> that give 
> what I believe to be a correct rule set. What the official docs say to
> do is 
> another thing. :)  Take a look at that file and see how I do the
> unauthorized 
> file access.


Excellent!  I had simply changed to the following, in a minimalistic
approach:

----------------------------------------------------
-w /etc/auditd.conf
-w /etc/audit.rules
-a exit,always -S open -F success=0
-a exit,always -S rmdir -S unlink -S chmod -S fchmod -S chown -S fchown
-S lchown -F success!=0
-a exit,always -S settimeofday -S setrlimit -S setdomainname -S
sched_setparam -S sched_setscheduler -S acct -S reboot -S swapon
-------------------------------------------------

Was grouping by failed, successful, and both.  Did this due to reading
that every audit rule is tested for every syscall, which...yeah, makes
me want to group things.

That being said, stig.rules is extensive; any warning on what the
performance impact will be?

Also, when looking for the newer builds on your site
http://people.redhat.com/sgrubb/audit/ - I noticed "1.7 -> 1.8 Remote
logging and finishing up IDS/IPS plugin."  That would be wonderously
fabulous, and I look forward to it.   Any thoughts on whether it will be
pulled into RHEL5, or whether I'd have to wait until RHEL6?

Brian

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

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

Re: no logging of successful events?

[Steve Grubb]

On Monday 18 August 2008 16:43:19 Brian LaMere wrote:
> -w /etc/auditd.conf
> -w /etc/audit.rules
> -a exit,always -S open -F success=0

Note that openat is being used more and more for secure apps that need to 
ensure that a directory is not switched out during an operation.


> -a exit,always -S rmdir -S unlink -S chmod -S fchmod -S chown -S fchown
> -S lchown -F success!=0
> -a exit,always -S settimeofday -S setrlimit -S setdomainname -S
> sched_setparam -S sched_setscheduler -S acct -S reboot -S swapon
> -------------------------------------------------
>
> Was grouping by failed, successful, and both.  Did this due to reading
> that every audit rule is tested for every syscall, which...yeah, makes
> me want to group things.

Yes. You can do that. In the stig.rules file I add a key so that you can see 
exactly what part of the stig is being met whenever you encounter an event. 
And its also because sometimes it takes more than one rule to meet a 
requirement fully.


> That being said, stig.rules is extensive; any warning on what the
> performance impact will be?

No idea. If you have to meet the letter of the law...not a whole lot you can 
do but throw hardware at it. Depending on your situation, you may be able to 
do it with less rules. I wanted to illustrate as complete coverage as 
possible with a real life security target people have to meet. I don't have 
any feedback from disa as to whether or not they like it. :)


> Also, when looking for the newer builds on your site
> http://people.redhat.com/sgrubb/audit/ - I noticed "1.7 -> 1.8 Remote
> logging and finishing up IDS/IPS plugin."  That would be wonderously
> fabulous, and I look forward to it.   Any thoughts on whether it will be
> pulled into RHEL5, or whether I'd have to wait until RHEL6?

Remote logging should be in RHEL5.3/Fedora 10. IDS work is in Fedora 9.

-Steve

Re: no logging of successful events?

[Brian LaMere]

> possible with a real life security target people have to meet. I don't have 
> any feedback from disa as to whether or not they like it. :)

I have an "official" position (SYSIAO) that requires I interact with
those darn things constantly.  Plus, the errors in the guides actually
cause me significant problems during scanning, with false positives and
such (because they exist in the automated scan tools too).

So, I've begun looking into getting feedback to/from the drafters of the
UNIX Checklist; I'll let you know if anything comes of it.

Brian