Stop auditd from drowning your storage in useless event noise

Technical Briefing | 8/13/2026

You set up auditd because compliance told you to, or maybe because you actually want to know when someone touches your shadow file. Then you realized that logging every single system call turns your disk into a garbage dump and your IO latency into a disaster. I once had a production box drop off the grid because the audit log grew so fast it hit a block limit and caused a kernel panic. Most folks just install the default rules and pray, but that’s a one-way ticket to a broken system.

Why your default rules are lying to you

The default ruleset provided by most distributions is overly broad. It captures every file access, every success, and every syscall that happens to wander by. If your application does a lot of small reads or status checks, you are logging thousands of events per second for things you will never actually audit. You need to drop the noise and focus on what matters: unauthorized modification, privilege escalation, and configuration drift.

auditctl -D
auditctl -w /etc/passwd -p wa -k identity_changes
auditctl -w /etc/shadow -p wa -k identity_changes

• Delete the default ruleset immediately, it is usually designed for generic environments and not high-load servers
• Use -p wa to watch only for writes and attribute changes, ignoring simple reads that clutter logs
• Group related events with a -k key so your grep commands don’t turn into a nightmare of pipe redirection
• Always define an immutable rule at the end of your config to prevent unauthorized tampering with the audit rules themselves

Keeping the logs from eating your disk

If you are worried about the log size, look at your auditd.conf file. Specifically, set max_log_file to something manageable and ensure space_left_action is set to email or exec rather than just halting the machine. The goal is to be alerted when the logs are full, not to have the OS commit suicide just because a rogue process logged a thousand syscalls in a minute. Audit logs are supposed to give you visibility, not act as a denial of service vector against your own infrastructure.

Take twenty minutes to audit your audit rules this weekend. If you cannot explain why a specific line is in your ruleset, kill it. You’ll find that having a smaller, cleaner log file makes incident response significantly faster when the house is actually on fire.