auditd Baseline: Turning On the Linux Audit Trail You’ll Wish You Had After an Incident

The Linux audit trail is the record you never think about until an investigator asks who touched /etc/sudoers at 02:14, and the honest answer is that nothing was watching.

auditd is installed on almost every server I look at and configured on almost none of them. The daemon runs, the ruleset is empty, and the box produces nothing beyond whatever syslog happened to catch. Then something goes wrong — a compromised key, a rogue admin, an odd binary running as root — and the one thing that could have reconstructed the sequence was never turned on. This is a baseline that fixes that: a defensible ruleset covering privilege use, authentication and sensitive-file access, tagged so you can actually find things, and tuned so the log stays usable rather than ignored.

What a baseline has to cover

The temptation with auditd is to log everything, which produces a firehose nobody reads and a disk that fills by Tuesday. The opposite failure — logging nothing — is where most machines actually sit. A baseline is the middle: the small set of events that answer the questions an incident actually raises. Who gained root, and what did they run with it? Who modified the files that define trust — the password database, the sudoers policy, the SSH keys? Did an account’s identity change at runtime? Was the clock moved to muddy the timeline?

auditd gives you two primitives. A watch (-w) fires when a file or directory is touched in a given way. A syscall rule (-a) fires when a specific system call runs, optionally filtered by architecture, user or exit condition. The discipline is to write few of each, and to tag every one with a key so it is retrievable later.

The ruleset

On Ubuntu 24.04, install the daemon with apt install auditd, then drop this into /etc/audit/rules.d/50-baseline.rules. Files in rules.d are compiled by augenrules into the single ruleset the kernel loads, so you never edit the live rules by hand.

## /etc/audit/rules.d/50-baseline.rules
## Load with: augenrules --load

# Start from a clean slate and set a generous buffer
-D
-b 8192
--backlog_wait_time 60000
-f 1

# --- Identity and authentication files ---
-w /etc/passwd    -p wa -k identity
-w /etc/group     -p wa -k identity
-w /etc/shadow    -p wa -k identity
-w /etc/gshadow   -p wa -k identity
-w /etc/sudoers   -p wa -k priv_esc
-w /etc/sudoers.d/ -p wa -k priv_esc

# --- SSH trust ---
-w /root/.ssh/          -p wa -k ssh_keys
-w /etc/ssh/sshd_config -p wa -k sshd_config

# --- Anything run with root's effective UID by a real login ---
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k priv_exec
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k priv_exec

# --- Identity changes at runtime ---
-a always,exit -F arch=b64 -S setuid -S setgid -S setresuid -S setresgid -F auid>=1000 -F auid!=unset -k identity_change

# --- Clock tampering (a classic timeline-muddying move) ---
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_change

# Make the config immutable until the next reboot
-e 2

A few of those lines carry the weight. -p wa watches for writes and attribute changes, not reads — you do not want an event every time something opens /etc/passwd, which happens constantly. The auid>=1000 -F auid!=unset filter is the noise control that makes the execve rules survivable: auid is the audit login UID, stamped at login and inherited by every child process, so this captures commands traceable to a real human account and skips the churn of system daemons whose auid is unset. -e 2 makes the configuration immutable, so an attacker who gains root cannot quietly disable auditing without rebooting — which is itself a loud, logged event.

Load it and confirm:

sudo augenrules --load
sudo auditctl -l      # list active rules
sudo auditctl -s      # status: enabled, backlog, lost events

Watch the lost counter in auditctl -s over the first few days. If it climbs, the buffer is too small or the ruleset too broad; raise -b before you widen coverage.

Getting answers back out

The keys are the point. Every event above is tagged, so after an incident you query by intent rather than grepping raw records. ausearch retrieves and aureport summarises; the -i flag interprets numeric UIDs, syscalls and timestamps into something readable.

# Anyone who touched sudoers policy today, human-readable
ausearch -k priv_esc -ts today -i

# Every command run as root by a real login since boot
ausearch -k priv_exec -i

# Changes to the identity files in the last 10 minutes
ausearch -k identity -ts recent -i

# Authentication activity, summarised
aureport -au -i --summary

# Which executables fired the most events
aureport -x --summary -i

# Everything a specific audit login UID did today
ausearch -ua 1001 -ts today -i

-ts today means since midnight; -ts recent is the last ten minutes; you can also pass an explicit -ts 09/29/2026 08:00:00. Pair with -te for an end time to bracket an incident window. The habit worth building is running aureport -x --summary on a fresh machine once you know what normal looks like — the outliers are usually where the story is.

Keeping it honest over time

A baseline is a starting point, not a monument. Two things keep it alive. First, tune out demonstrable noise by adding narrow exclusions rather than deleting whole rules — if a backup agent floods priv_exec, exclude that binary by path, do not stop watching root execve. Second, ship the logs off the box. An audit trail that lives only on the machine it audits is gone the moment that machine is compromised or rebuilt; forward to a central collector so the record survives the incident it is meant to document. That is the same reasoning that makes a tamper-evident custody audit trail worth the engineering, and it is what turns host logs into evidence a supervisor will accept when the incident-reporting clock starts.

Treat this like any other control you can commit and review: version the rules file, put it through the same pre-commit and CI discipline as the rest of your infrastructure, and hold it to the same standard as the credentials it protects — the record of who used a privileged key is only as good as the log that captured it.

The whole exercise takes an afternoon. The alternative is discovering, at the worst possible moment, that the only witness to what happened on your server was never asked to watch.