Re: Suppress messages from /var/log/audit.log via audit.rules
On Thursday, September 29, 2011 11:51:00 AM Worsham, Michael wrote:
The messages being detected are from a VMware Tools install on a RHEL
5.x
platform, directly from the VMware Tools zip file. From what I can see
upon a bit of research, it seems that VMware Tools is looking for files
that don't exist nor are installed from the original zip package. Also, in
the past I tried the following rules as well to no effect:
-a exit,never -F arch=b32 -S fork -F success=0 -F
path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-ENOENT -a
exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools
-F subj_type=initrc_t -F exit=-ENOENT
This is the current rule set in its entirety:
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 15000
# Feel free to add below this line. See auditctl man page
# Exclude all cwd message types
-a exclude,always -F msgtype=CWD
You probably don't mean to suppress this., You may need it to reconstruct relative
paths.
## Suppress all VMware Tools messages
-a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F
subj_type=initrc_t -F exit=-2
-a exit,never -F arch=b64 -S fork -F success=0 -F
path=/usr/lib/vmware-tools -F
subj_type=initrc_t -F exit=-2
Is ENOENT a valid return code for fork? I can't see what this rule is supposed to do.
My guess is you at one time did not have 32 and 64 bit rules and were getting caught
by open and fork sharing the same syscall number on 64/32 API's. I would delete this
rule.
#-a exit,never -F arch=b32 -S fork -F success=0 -F
path=/usr/lib/vmware-tools -F
subj_type=initrc_t -F exit=4294967294
#-a exit,never -F arch=b64 -S fork -F success=0 -F
path=/usr/lib/vmware-tools -F
subj_type=initrc_t -F exit=4294967294
#GEN002720
-a always,exit -F arch=b32 -S open -F success=0
-a always,exit -F arch=b64 -S open -F success=0
This is the rule that is killing you. Why do you want failures for ENOENT? Or EEXIST,
EINTR, or many other meaningless errors? I would fix this rule to get failures that
return EPERM or EACCES. Those are the security relevant failures.
#GEN002740
-a always,exit -F arch=b32 -S unlink -S rmdir
-a always,exit -F arch=b64 -S unlink -S rmdir
This is also an overly aggressive rule that will get you all kinds of events that mean
nothing. I would rewrite this. You might look at:
https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules
To get some ideas about how to fine tune the rules you are using. For one, nothing is
using keys. You really want to add keys to all you rules so that you can see what
kinds of things are happening on you system like:
aureport --start today --key --summary
#GEN002760
-w /etc/auditd.conf
-w /etc/audit.rules
-w /etc/audit/auditd.conf
-w /etc/audit/audit.rules
-a always,exit -F arch=b32 -S stime -S acct -S reboot -S swapon -S
settimeofday -S setrlimit -S setdomainname -S sched_setparam -S
sched_setscheduler
-a always,exit -F arch=b64 -S acct -S reboot -S swapon -S settimeofday -S setrlimit
-S setdomainname -S sched_setparam -S sched_setscheduler
#GEN002820
-a always,exit -F arch=b32 -S chmod -S fchmod -S chown -S chown32 -S fchown
-S fchown32 -S lchown -S lchown32
-a always,exit -F arch=b64 -S chmod -S fchmod -S chown -S fchown -S lchown
Again way too aggressive rules and no keys to help analysis. I wrote an audit.rules
man page that describes some of the consideration you might want to make in writing
rules to conduct an investigation later.
-Steve