L14. The Audit Framework: Writing auditd Rules

What Is the Linux Audit System?

The Linux Audit system is a kernel-level framework that records security-relevant events. Unlike application-level logging (which depends on each program writing its own logs), The kernel audit subsystem generates events and auditd writes them to disk. This means it can track:

• File access and modification (even by root)
• System call execution
• User authentication events
• Changes to system configuration files
• Network connection attempts

If someone modifies /etc/shadow or runs a suspicious command, auditd can record exactly who did it, when, and from which process.

Installing and Starting auditd

# Debian/Ubuntu
sudo apt install auditd audispd-plugins
# RHEL/CentOS (usually pre-installed)
sudo dnf install audit
# Start and enable the daemon
sudo systemctl enable --now auditd

Audit Rules: Two Types

Audit rules come in two categories:

1. File Watch Rules (-w)

File watch rules monitor access to specific files or directories. The -w syntax is supported but deprecated for performance reasons; prefer syscall-based path or directory rules for new deployments.

# Watch /etc/passwd for any changes (write or attribute change)
sudo auditctl -w /etc/passwd -p wa -k identity_changes
# Watch /etc/shadow for any access (read, write, execute, attribute)
sudo auditctl -w /etc/shadow -p rwxa -k shadow_access
# Watch the sudoers file for modifications
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes
# Watch a directory and all its contents
sudo auditctl -w /etc/ssh/ -p wa -k ssh_config_changes

The flags after -p specify which operations to watch:

The -k flag assigns a key (tag) to the rule, which makes searching audit logs much easier.

2. System Call Rules (-a)

Syscall rules are more granular. They watch for specific kernel system calls executed by specific users or processes.

# Example: execve for login UIDs >= 1000, excluding unset login UID
sudo auditctl -a always,exit -F arch=b64 -S execve -F 'auid>=1000' -F 'auid!=unset' -k user_commands
# Example: EACCES from open/openat on a 64-bit ABI; not every access failure
sudo auditctl -a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k access_denied
# Log changes to user/group management commands
sudo auditctl -w /usr/sbin/useradd -p x -k user_management
sudo auditctl -w /usr/sbin/userdel -p x -k user_management

Shell commands must quote comparison filters so > is not treated as output redirection. b64 targets a 64-bit syscall ABI; add tested b32 coverage if the host supports 32-bit applications. UID thresholds depend on local account policy. execve alone is not a record of shell built-ins or every possible execution path.

Prefer a path rule such as:

sudo auditctl -a always,exit -F arch=b64 -F path=/etc/passwd -F perm=wa -k identity_changes
sudo auditctl -l
sudo auditctl -s

Inspect lost-event and backlog counters; absence of a log entry is not proof that no action occurred.

Making Rules Persistent

Rules added with auditctl are lost on reboot. To make them permanent, add them to the audit rules file:

# Edit the persistent rules file
sudo nano /etc/audit/rules.d/custom.rules

Add rules in the same syntax (without the auditctl command prefix):

# /etc/audit/rules.d/custom.rules
# File watches
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p rwxa -k shadow_access
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/ssh/sshd_config -p wa -k ssh_config
# Syscall rules
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k user_commands

The persistent file uses bare filters, without shell quotes or the sudo auditctl prefix.

Load the new rules:

sudo augenrules --load

Querying Audit Logs with ausearch

Audit logs are stored in /var/log/audit/audit.log. The raw format is machine-readable but not human-friendly. Use ausearch to query them:

# Search by key
sudo ausearch -k identity_changes
# Search by key and time range
sudo ausearch -k shadow_access --start today
# Match real, effective, or login UID 1001
sudo ausearch -ua 1001
# Search for events related to a specific file
sudo ausearch -f /etc/passwd
# Search for failed operations
sudo ausearch --success no

Generating Reports with aureport

aureport summarizes audit data into readable reports:

# Summary of all audit events
sudo aureport --summary
# Report on authentication events
sudo aureport --auth
# Report on failed events
sudo aureport --failed
# Report on file access events
sudo aureport --file
# Report on executed commands
sudo aureport --executable

Monitoring Critical Files

At minimum, you should watch these files on every server:

Attackers frequently target these files to create backdoor accounts, modify passwords, grant sudo access, or establish persistence through cron jobs.

Performance Considerations

Audit rules consume kernel resources. Overly broad rules (like watching all file reads system-wide) can cause significant performance degradation. Best practices:

• Start with targeted file watches on critical files
• Use syscall rules sparingly and with filters (UID, arch)
• Monitor the audit log size and rotate it appropriately
• Test rules in a non-production environment first

References

• Linux manual: audit.rules(7)
• Linux manual: auditctl(8)
• Linux manual: ausearch(8)
• Linux manual: aureport(8)