Linux auditd basics: what it records and where to start

auditd is the user space part of the Linux Auditing System. It receives audit events from the kernel and writes them to disk. You decide what gets recorded by loading audit rules. Start with a small rule set aimed at privileged activity and changes to sensitive files, then forward the output off the host.

The pieces

The auditd manual page describes the daemon as responsible for writing audit records to disk, with its settings read from /etc/audit/auditd.conf. A few related tools:

• auditctl configures the audit system and loads rules.
• augenrules compiles the rule files under /etc/audit/rules.d/ into /etc/audit/audit.rules. At startup, rules from audit.rules are loaded into the kernel.
• ausearch and aureport read and summarize the log.
• audisp-remote lets auditd receive events from other audit daemons, which supports central collection.

The daemon responds to signals: reload configuration, rotate logs, or shut down.

What to audit first

Good first rules, expressed in plain words:

1. Changes to identity files. Account and group databases, sudo configuration, SSH configuration.
2. Privileged command use. Execution of tools that change privileges or accounts.
3. Changes to the audit configuration itself. Attackers who gain root often try to blind you.
4. Kernel module loading.
5. Time changes. Altered clocks wreck timelines. See log timestamps.
6. Failed access to sensitive files.

The manual page does not describe rule syntax, so use your distribution's documentation and a reviewed baseline rather than inventing rules from memory. Many teams adopt a published community or benchmark rule set and trim it.

Volume and performance

An overly broad ruleset generates enormous logs and can affect performance. Watching every system call on a busy server is not a good starting point. Add rules in small steps, measure the event rate, and keep a rule only if it answers a question you will ask.

Protect the output

• Forward events off the host quickly, since local logs are the first thing an intruder edits. See protecting log integrity.
• Make the audit configuration immutable at boot where your distribution supports it, so changes require a restart that is itself noticed.
• Restrict read access to the audit log.
• Rotate with enough space that a full disk does not stop auditing silently, and alert if it does.

Make it searchable

Raw audit records are dense key value text spread over several lines per event. Parse them in the collector and map the important fields into your common schema: who, what, outcome, time.

Containers and cloud hosts

Host audit rules see container processes, but container context such as pod names is not in the kernel event by default, so enrich later. On managed platforms where you cannot reach the host, rely on the provider's audit logs and the platform control plane audit trail instead.

Quick check

Sources

• auditd(8) manual page

Last reviewed: 19 October 2026.