auditd

What auditd is and how the Linux Audit framework works

The Linux Audit framework has a kernel part and a userspace part. The kernel creates a record when an event matches a rule, and also for events built into the system, such as logins and uses of authentication. auditd is the daemon that writes these records to disk, by default to /var/log/audit/audit.log. auditctl loads rules into the kernel, while ausearch and aureport search and summarize the log. Daemon settings live in /etc/audit/auditd.conf (see auditd(8)).

The audit.rules(7) page names three kinds of rule: control rules that configure the system, file system rules (watches) and system call rules. Rules can match fields such as auid, the ID the user originally logged in with, which is how an action by root can be tied back to a login. Every rule can carry a key, a label of up to 31 bytes that you search for later. Planning keys in advance is the single most useful habit, because investigation depends on them.

Writing, loading and searching rules

Persistent rules go in files ending in .rules under /etc/audit/rules.d/. augenrules merges them into /etc/audit/audit.rules, and augenrules --load loads the result. The man pages mark the older -w watch form as deprecated for poor performance and recommend the syscall form with path, dir and perm fields:

# /etc/audit/rules.d/50-intrusion.rules
-a always,exit -F arch=b64 -F path=/etc/passwd -F perm=wa -k identity
-a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -k identity
-a always,exit -F arch=b64 -F dir=/etc/ssh -F perm=wa -k sshconfig
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k exec

Here perm=wa means write or attribute change. On a system that also runs 32-bit programs, add matching arch=b32 rules. Check what is loaded with auditctl -l and the kernel state with auditctl -s. Then investigate with ausearch(8) and aureport(8):

aureport --start this-week --key --summary
ausearch --start today -k identity -i

The first command lists which keys triggered most, and the second shows the matching events with numeric IDs translated to names.

Performance, limits and common mistakes

The auditctl(8) documentation is blunt: syscall rules are checked against every system call, so more rules cost more. Supply the arch field, combine syscalls into one rule, and avoid broad rules such as auditing every file open.

Check that auditing is actually on. On many systems a default -a never,task rule from 10-no-audit.rules makes every new process skip audit rules, so your rules never match, and the man page says to look for it in auditctl -l. Adding audit=1 to the kernel command line makes processes that start before auditd auditable.

max_log_file, max_log_file_action and num_logs in auditd.conf control size and rotation, and disk_full_action can halt the machine, so choose it deliberately. If the kernel backlog fills, the failure mode decides what happens (by default a kernel message, optionally a panic), and auditctl -s shows the backlog and lost events. A final -e 2 line locks the rules until reboot, which stops an intruder switching auditing off but also blocks your own changes. Root can still edit a local log file, so forward it elsewhere.

How auditd fits into monitoring and incident response

Most logs tell you that something happened. auditd tells you who did it and with what: which login ran a command, and which account touched /etc/passwd or an SSH configuration file. The audit.rules page states the purpose plainly, which is to let you investigate periodically or when an incident occurs. Like file integrity monitoring, it cannot see the past, so the rules must exist before the incident.

Use it alongside other sources. The journal holds service and authentication messages, and rsyslog can ship copies off the machine. The auditd manual also describes receiving events from other audit daemons through the audisp-remote plugin, so audit records can leave the host too. Read the monitoring guide for what deserves an alert, the sudo guide for the privilege model you are auditing, and the breach response guide for how audit records feed a timeline.

Related terms: journalctl, rsyslog, File integrity monitoring, Incident response, SIEM.