Audisp is flooding /var/log/messages and trying to fix it

Latest response

I'm upgrading from syslog to rsyslog in order to clean up logging. I've noticed that Audispd was flooding /var/log/messages with the following:

2015-12-23T08:33:46.370297-06:00 ameda4aisrx0238 audisp-remote: queue is full - dropping event

Under /etc/audisp/audispd.conf, I've changed the overflow_action from SYSLOG to SUSPEND, since I don't see a STIG pertaining to it:

q_depth = 2048
overflow_action = SUSPEND
priority_boost = 8
max_restarts = 10
name_format = HOSTNAME
#name = mydomain

That seemed to fix it for about 1 minute and then it was back to what it was.

I've read that q_depth could be increased to handle this since the logging can't keep up. The man page doesn't have a recommendation for a size or a best practice, so I'm wondering what would be a good number to set it to or see what others have done to fix this.

thanks

I'm wondering what

CM
Log in to join the conversation

Responses

LL Community Member 37 points
27 April 2016 5:50 PM

We have faced the same issue. I have increased q_depth to 32768 and it still cannot cope.

Since you have switched to rsyslog, why not do your remote logging via rsyslog? It is far more robust than audisp. There is a quick HOWTO on the syslog wiki: http://wiki.rsyslog.com/index.php/Centralizing_the_audit_log

Note: If you use SELinux, you will need to allow syslog to access /var/log/audit.log

LL Community Member 37 points
28 April 2016 12:30 PM

Perhaps I should not have commented on this thread as my main concern was not audit messages in /var/log/messages (which could be easily ignored or directed to a separate log file using other directives in rsyslog.conf) but the apparent lack of robustness when using audisp to send audit records to a remote logging server. I never found a q_depth that stopped audisp from dropping audit records and am not convinced that the queue file is ever properly drained. (Once full, audisp never seemed to be able catch up.) In other words my main concern was dropped audit records which the rsyslog solution addressed.

CM Expert 1215 points
28 April 2016 1:37 PM

I also think part of the problem is the insane about of STIGs that have to get applied to /etc/auditd/audit.rules. After applying all of them, that is what overloads it.

Unfortunately the STIGs don't discuss on how to deal with the overloading of it.

I upgraded from syslog to rsyslog because syslog is going away, correct?

LL Community Member 37 points
28 April 2016 2:37 PM

We too are subject to meeting STIG requirements. In most cases rsyslog handled the volume of generated audit records just fine. There have been a few instances where we have had to back off slightly from the strict STIG requirements due to excessive system overhead but this is probably off topic for this thread ...