Need help with understanding auditd rules

Need help with understanding auditd rules

[Michael C Mc Quaid]

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

Good Morning,

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.

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, 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.

Thanks in advance for your help.

Mike McQuaid.

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

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

Re: Need help with understanding auditd rules

[Steve Grubb]

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