Auditd: Monitoring and Auditing on Linux

Q: I added a rule in /etc/audit/rules.d/ but nothing is being audited, why?

The .rules files placed in /etc/audit/rules.d/ are not picked up on the fly: they must be compiled and loaded with sudo augenrules --load. Then confirm that the daemon is actually running with sudo systemctl status auditd, and that it is enabled at boot via sudo systemctl enable auditd. Without those two steps, your rule is just a text file with no effect.

Q: What do the -p wa and -k options mean in a rule like -w /etc/shadow -p wa -k shadow_changes?

-w declares the path to watch. -p filters the kinds of access: w for writes and a for attribute changes, hence the classic wa on a sensitive file such as /etc/shadow. -k attaches an arbitrary key to the generated events, here shadow_changes, which lets you extract them later in a single command with sudo ausearch -k shadow_changes.

Q: How do I quickly retrieve the events produced by one specific rule?

Always put an explicit -k key on every rule, then query it with sudo ausearch -k <key>. Without a key you are reduced to grepping a very dense /var/log/audit/audit.log. Other useful filters round out the search: sudo ausearch -sc execve -sv yes for successful execve calls, or sudo ausearch -ua 1001 for every event tied to a given user.

Q: What is the difference between ausearch and aureport?

ausearch extracts individual events matching precise criteria: key, syscall, user, success or failure. aureport does not return raw events but aggregated summaries: aureport -l for login attempts, aureport -s for an overall summary of events, aureport -au -i --failed for authentication failures. In practice you start from aureport to spot an anomaly, then drill down into the detail with ausearch.

Security

Difficulty: Advanced

3 min read 25/07/2026

Complete guide to installing and configuring auditd on a Linux system to monitor security events and generate detailed logs.

Back to tutorials

Key takeaways

auditd is the user-space half of the Linux audit system: the kernel produces the records, and the daemon writes them to /var/log/audit/audit.log.
Rules are dropped into /etc/audit/rules.d/ but only take effect after a sudo augenrules --load.
Two families of rules: file watches such as -w /etc/shadow -p wa -k shadow_changes, and syscall rules such as -a always,exit -F arch=b64 -S execve -F auid=1001 -k user_commands.
The -k key is not decoration: it is what lets you pull the events back later with ausearch -k <key>.
ausearch digs through raw events (-k, -sc, -sv, -ua) while aureport produces summaries (-l for logins, -s for an overview, -au -i --failed for authentication failures). Volume and rotation are tuned in /etc/audit/auditd.conf.

What is auditd?
The Linux audit daemon (auditd) is the user-space component of the Linux auditing system. It is responsible for writing the audit records generated by the kernel to disk. It is the fundamental tool for tracking security-relevant events on your system.

Why Use auditd?

Traceability: Know who did what, and when. Essential for forensic investigations.
Compliance: Helps meet the requirements of many security standards (PCI-DSS, HIPAA, etc.).
Intrusion detection: Enables the detection of abnormal activity, such as unauthorized access to critical files.

Prerequisites

Operating system: Any modern Linux distribution.
Privileges: Root access or sudo privileges.

Premium Content

This advanced tutorial is reserved for premium members.

9,90€ / month

All advanced tutorials
New content every week
Progress tracking
Cancel anytime

Written by

Morgann Riu

Cybersecurity and Linux administration expert. I share my knowledge through free tutorials and training to help system administrators and developers secure their infrastructures.

My profile LinkedIn GitHub

Frequently asked questions

I added a rule in /etc/audit/rules.d/ but nothing is being audited, why?

The .rules files placed in /etc/audit/rules.d/ are not picked up on the fly: they must be compiled and loaded with sudo augenrules --load. Then confirm that the daemon is actually running with sudo systemctl status auditd, and that it is enabled at boot via sudo systemctl enable auditd. Without those two steps, your rule is just a text file with no effect.

What do the -p wa and -k options mean in a rule like -w /etc/shadow -p wa -k shadow_changes?

-w declares the path to watch. -p filters the kinds of access: w for writes and a for attribute changes, hence the classic wa on a sensitive file such as /etc/shadow. -k attaches an arbitrary key to the generated events, here shadow_changes, which lets you extract them later in a single command with sudo ausearch -k shadow_changes.

How do I quickly retrieve the events produced by one specific rule?

Always put an explicit -k key on every rule, then query it with sudo ausearch -k <key>. Without a key you are reduced to grepping a very dense /var/log/audit/audit.log. Other useful filters round out the search: sudo ausearch -sc execve -sv yes for successful execve calls, or sudo ausearch -ua 1001 for every event tied to a given user.

What is the difference between ausearch and aureport?

ausearch extracts individual events matching precise criteria: key, syscall, user, success or failure. aureport does not return raw events but aggregated summaries: aureport -l for login attempts, aureport -s for an overall summary of events, aureport -au -i --failed for authentication failures. In practice you start from aureport to spot an anomaly, then drill down into the detail with ausearch.

audit.log is growing enormously, how do I keep the volume under control?

A verbose audit configuration, especially very broad syscall rules, generates a considerable amount of data. Start by narrowing the scope: a handful of well-targeted watches on critical files delivers more value than a blanket execve rule. Then set the file size, the rotation and the disk-space policy in /etc/audit/auditd.conf, before the partition hosting /var/log/audit/ fills up.

Share this tutorial

X LinkedIn WhatsApp

Did you enjoy this article?

Was this article helpful?

Thanks for your feedback!

Comments

Recommended for you

DevOps

In-depth article on the topic

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.