auditd

auditd is the userspace daemon for the Linux kernel’s audit subsystem. Rules specify which syscalls, file accesses, or events to record, and the kernel generates events that auditd writes to disk.

The distinction from ordinary logging is the point. Application logs record what the application chose to record — a compromised or misbehaving process logs whatever it wants, including nothing. The kernel audit subsystem records what actually happened at the syscall boundary, and a process cannot decline to be audited. That is the property that makes it forensically useful: the trail survives the compromise of the thing that produced it.

What it is good for

• File integrity watches. A rule on /etc/passwd or /etc/sudoers records every access with the process, user, and command. Configuration files changing without a corresponding change ticket is exactly the anomaly worth catching.
• Privilege escalation. Watching setuid and related calls records who became root and how.
• Compliance. Many frameworks require a tamper-evident audit trail, and this is usually how that requirement is satisfied on Linux.
• Explaining SELinux denials. SELinux denials land in the audit log, and ausearch and audit2why read them. This is the most common everyday use.

The problem with it

Volume. Broad rules generate enormous quantities of events. Auditing every file access on a busy system produces gigabytes per day, imposes measurable syscall overhead, and — worst — creates a haystack. An audit log nobody can search is not evidence.

The discipline is to audit narrowly and deliberately. A small number of rules covering genuinely sensitive objects produces a log that can be read. The temptation is to enable comprehensive auditing because it feels thorough, and comprehensive auditing reliably produces less usable information than a targeted rule set.

Disk-full behaviour deserves a decision rather than a default. auditd can be configured to halt the system when it cannot write audit records — appropriate where the audit trail is a compliance requirement, and a self-inflicted outage otherwise. Whichever is right, it should be chosen knowingly.

Records should be shipped off-host, through rsyslog to a central collector or into Wazuh. An audit log stored only on the machine it describes can be deleted by whoever compromises that machine, which defeats the purpose.

See also: SELinux, rsyslog, Wazuh, osquery for the query-based alternative, and Linux administration in datacenters.