Linux Kernel Audit Backlog Limit Exceeded: Troubleshooting and Fixes for CentOS Servers


2 views

The Linux kernel audit subsystem maintains a queue (backlog) for audit events when the auditd daemon isn't processing events fast enough. When this queue exceeds audit_backlog_limit (default 320), the system starts dropping events and logging warnings like:

kernel: audit: backlog limit exceeded
kernel: audit: audit_backlog=321 > audit_backlog_limit=320

The aureport output shows a pattern of authentication-related events dominating the audit log:

486  USER_ACCT
486  CRED_ACQ
486  USER_START
485  LOGIN

This typically indicates either:

  1. Excessive legitimate authentication attempts (e.g., automated processes)
  2. A possible brute force attack
  3. Misconfigured services generating redundant auth events

To temporarily stabilize the system while investigating:

# Increase backlog limit (survives reboot)
echo "audit_backlog_limit=1024" >> /etc/audit/audit.rules
service auditd restart

# Alternative temporary increase
sysctl -w net.unix.max_dgram_qlen=1024

1. Optimize Audit Rules

Review and streamline your audit rules in /etc/audit/audit.rules:

# Example focused rule set for security-critical events
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-a always,exit -F arch=b64 -S execve -k execution

2. Rate Limiting

Add rate limiting to auditd configuration:

# /etc/audit/auditd.conf
rate_limit = 1000 # Messages per second
burst_limit = 2000 # Burst capacity

3. Log Rotation and Management

Ensure proper log rotation in /etc/audit/auditd.conf:

max_log_file = 50 # MB
num_logs = 10 # Number of logs to retain
space_left = 100 # MB - triggers action
space_left_action = email
admin_space_left = 50 # MB - triggers immediate action

For persistent issues, use these investigative commands:

# Real-time monitoring of audit events
ausearch -i -m all | head -n 50

# Check for specific user login patterns
aureport -l -i --summary

# Generate timeline of events
aureport -t -i

Create a monitoring script to alert when backlog approaches limit:

#!/bin/bash

THRESHOLD=300
CURRENT=$(dmesg | grep "audit_backlog=" | tail -1 | awk -F= '{print $2}' | awk '{print $1}')

if [ "$CURRENT" -gt "$THRESHOLD" ]; then
    echo "WARNING: Audit backlog approaching limit - $CURRENT" | mail -s "Audit Backlog Alert" admin@example.com
fi

Combine with cron for regular checking:

*/5 * * * * /usr/local/bin/audit_backlog_monitor.sh

For high-traffic systems, consider:

# Increase kernel buffers (add to /etc/sysctl.conf)
net.core.netdev_max_backlog = 5000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Remember to apply changes with sysctl -p.


The audit: backlog limit exceeded message in /var/log/messages indicates your Linux audit subsystem is overwhelmed. This typically occurs when:

  • Audit events are generated faster than the daemon can process
  • The backlog buffer (default 320) is too small for your workload
  • There's excessive authentication activity (as shown in your aureport)

Your aureport output reveals a pattern of authentication events:

486  USER_ACCT
486  CRED_ACQ
486  USER_START
485  LOGIN
477  CRED_DISP
477  USER_END

This suggests repeated user logins/authentication attempts, possibly from:

  • Cron jobs using system accounts
  • Automated processes with frequent privilege changes
  • SSH brute force attempts (check /var/log/secure)

1. Increase backlog limit temporarily:

# Check current limits
auditctl -s | grep backlog

# Increase limit (valid until reboot)
auditctl -b 1024

2. Throttle audit events:

# Set rate limiting (10 messages/sec)
auditctl -r 10

Edit /etc/audit/audit.rules:

# Increase backlog buffer
-b 1024

# Enable rate limiting
-r 25

# Exclude noisy processes (example)
-a never,exclude -F msgtype=CWD
-a never,exclude -F msgtype=PROCTITLE

To identify the most frequent audit events:

# Show top 10 event types
ausearch --start today --raw | aureport --summary -i | head -n 10

# Monitor audit events in real-time
auditwatch -f /var/log/audit/audit.log

For persistent issues, consider:

  • Creating custom audit rules to filter noise
  • Setting up log rotation for audit logs
  • Monitoring auditd queue size with NRPE or similar

To exclude frequent cron-related events:

# Add to /etc/audit/rules.d/noise.rules
-a never,exclude -F subj_type=crond_t
-a never,exclude -F exe=/usr/sbin/crond