Re: Need help with understanding auditd rules
On Friday, August 28, 2015 07:31:18 AM Michael C Mc Quaid wrote:
I don't know if this is an appropriate use of this group email,
but after
days and days of trying, we are not able to fix the auditing problem we are
having, and we're desperate for help.
We need to audit our system to meet new security standards, which we have
been able to do via the audit.rules file on our RHEL 5&6 nodes. However,
we also have to run the hp-health packages on our systems to remotely
monitor our systems with HP Insight Manager. When we run the hp-health
processes, our auditd logs go from ~1000 entries to ~35,000 entries (every
10min), which is causing a problem in moving our audit logs to our storage
system.
So...what's causing it?
ausearch --start today -k --raw | aureport --key --summary
aureport --start today --syscall --summary
aureport --start today --file --summary
We have set up rules to "never" audit the hp-health
processes themselves,
but this does not fix the problem. It only reduces the amount of entries
by ~10,000. It seems that the hp-ilo module loaded in the kernel is
running system "checks" at a very rapid pace and is reporting them to the
hp-snmp-agent processes (which are the ones we have set up never audit
rules for). We don't know how to set up a rule to eliminate the monitoring
of these ilo activities (which are a combination
chmods/touches/opens/execves/etc.), while continuing to monitor these
syscalls for the rest of the system.
Are you aware of anyone else who has run into this problem,
Yes, there are people that flood their system with events.
or is there a thread on your web-page we can look at (we looked, but
could
not find anything). We are looking for a way to set up a rule to not monitor
any of the Insight Manager activity but still maintain the capability to
monitor all of our other syscalls.
Normally, the security rules are intended to be about what people do rather
than daemons. The difference between people and daemons is people have an auid
= 500 and a daemon has an auid of -1. People have a session id > 0
and
daemons have -1. You might be able to fix your rules to not care about what
daemons do. For example, if you currently have:
-a always,exit -S open
you might change it to
-a always,exit -S open -F auid>=500 -F auid!=-1
The kernel uses unsigned numbers. This causes -1 to become 4294967295 which
is greater than 500.
-Steve