Quit letting your auditd rules log the kitchen sink

Technical Briefing | 11/7/2026

I’ve lost count of how many times I’ve walked into a new environment only to find the disk screaming for mercy because auditd is logging every single execve syscall made by a busy web server. It is a common trap. You try to satisfy a compliance checklist, you drop in a few broad rules, and suddenly your system performance is tanking while your logs are flooded with irrelevant noise.

Why your syscall filters are actually killing you

The kernel isn’t the problem here; it’s how you are asking it to look for things. If you just add a rule for an entire directory, auditd has to track every single event that touches those files, whether it matters to your security posture or not. That creates a massive bottleneck. You need to focus on specific actions on sensitive files instead of watching the entire filesystem dance.

auditctl -a always,exit -F arch=b64 -S openat -F dir=/etc/shadow -k shadow-access

• Filter by architecture to stop tracking 32-bit noise on 64-bit systems
• Use -F success=1 if you only care about successful unauthorized attempts
• Group your rules by action and apply a meaningful key for grepability

Don’t just reload the service and walk away. Once you add these rules, watch your audit log tail for ten minutes. If you see the same pid hammering the logs with different syscalls, you aren’t auditing, you are just performing a self-inflicted denial of service attack. Go back, refine the filters, and kill the noise before the system starts dropping events because the queue overflowed.

If you end up with a high-volume system, consider moving the audit logs to a dedicated high-speed partition or a remote collector early on. Even the cleanest rulesets grow over time, and you don’t want to find out during a production outage that your disk filled up because of your security logging config.