Table of Contents
Overview
Auditd is the userspace component of the Linux Auditing System. It records detailed security relevant events, such as system calls, file access, and configuration changes, and writes them to structured log files. Unlike general system logs, audit logs aim to provide a tamper evident, traceable history of actions so that administrators and security teams can prove what happened and when.
On most modern distributions, auditd works closely with the kernel audit subsystem. The kernel generates events according to rules you define, and sends them to the audit daemon, which then formats and stores them. This separation lets you record very low level activity without having application programs modify their own logging.
Auditd logs are security evidence. Protect their integrity, confidentiality, and availability just like other critical security data.
Components and Architecture
The audit system has two main halves. In the kernel there is the audit framework, which hooks into system calls and security decisions. The kernel can record details such as which process performed which action, what user IDs and group IDs were involved, which file or network resource was touched, and whether an action was allowed or denied. The kernel emits these events according to configurable rules.
In user space, the primary process is auditd. It runs as a background daemon, receives events from the kernel over a netlink socket, then writes them to a log file, usually /var/log/audit/audit.log. If the log file grows too large or storage rules demand rotation, auxiliary tools handle that rotation and optional archival.
On top of the basic logging functions, there are helper utilities. auditctl communicates with the kernel to load, list, or remove rules and to adjust audit settings. aureport summarizes audit logs into reports. ausearch lets you query events using criteria such as user, event type, or time window. On some systems, higher level security frameworks read audit logs to feed alerting or compliance dashboards.
Installing and Enabling Auditd
On many server oriented distributions, auditd is installed by default. On desktop or minimal systems, it may not be present until you install it explicitly. The package name is typically auditd or audit. Once installed, systemd usually defines a unit called auditd.service which starts the daemon early in the boot process.
Enabling auditd at boot time is commonly done with a service enable command appropriate to your distribution. When enabled, auditd starts before most user services so that activity during boot is also subject to auditing. Some distributions also include default rule sets that load early via configuration files, so that basic events, such as attempts to modify critical system files, are recorded even before an administrator customizes the rules.
If the kernel audit subsystem is compiled in and not disabled, starting auditd automatically connects it to the kernel. If the kernel lacks audit support or if it is disabled by boot parameters, auditd either fails to start properly or operates in a limited way. For serious use, you must verify that kernel audit support is present and active.
Configuration Files and Basic Settings
Auditd uses configuration files in /etc/audit to control its behavior. The main configuration file is auditd.conf. This file defines practical aspects of logging such as the log file path, log rotation policy, maximum log file size, and what to do when disk space is low.
Typical settings specify the location of the primary log file, the number of rotated logs to keep, and whether to compress old logs. Other parameters determine how auditd behaves if it cannot write to disk, for example whether it should ignore the failure, stop writing, or trigger a system shutdown. These settings matter for both reliability and security, since losing events may weaken the value of the audit trail.
Audit rules themselves are not normally stored in auditd.conf. Instead, distributions often provide files such as /etc/audit/audit.rules or a directory like /etc/audit/rules.d/ that contain rule definitions. At startup, a helper merges and loads these rules into the kernel via auditctl. This separation keeps policy about what to log distinct from how to store it.
Always review auditd.conf so you know what happens when audit logs fill the disk. Misconfiguration can either silently drop critical events or cause unexpected system behavior.
Audit Rules and Policies
Audit rules describe what the kernel should watch. They can target system calls, files and directories, users and groups, or specific keys that label related rules. The rules are loaded into the kernel and immediately start influencing which events are generated.
There are several broad categories of rules. File watch rules monitor access or changes to particular files or directories, such as /etc/passwd or SSH configuration. System call rules record invocations of specific kernel calls, possibly combined with conditions on parameters or process attributes. Login and session related rules track events at the boundary of user access, such as successful and failed authentication attempts.
Rules can be labeled with keys, which are human readable tags attached to events. Keys help you filter and report on groups of related events later, for example all events associated with modification of system binaries or all events tied to configuration changes.
The effective audit policy emerges from the combination of these rules. You can design minimal, targeted policies for specific compliance requirements, or broad, high volume policies that record extensive detail. Broad policies offer more forensic depth but can create very large logs and performance overhead.
Auditing Files and System Calls
One of the most powerful uses of auditd is monitoring files and directories. When you watch a path, the kernel produces events each time a process performs a selected type of operation on that path. For example, you can record read, write, attribute change, or execute events for a directory that contains critical configuration. This is especially useful when you need to know exactly which user or process altered a security sensitive file.
System call auditing operates at a lower level. Instead of naming specific files, you describe which kernel operations to trace, such as open, unlink, or chmod. These rules may be conditioned on properties like process user ID, group ID, or whether the call succeeded or failed. The resulting events contain fields for the call name, arguments, return values, and identifying information about the process.
Because system call auditing can generate a large number of events, it is especially important to plan carefully. Targeted rules that apply only to particular users or when specific conditions hold help keep the event volume manageable. Unfocused rules that monitor all calls from all users on a busy system can quickly flood logs and impact performance.
Avoid blanket system call rules that apply to all users and all calls on production servers. They can severely increase log volume and degrade system performance.
Working with Audit Logs
Audit logs are usually stored in /var/log/audit/audit.log and rotated to additional files in the same directory when they reach size limits. Each line in an audit log is a record that begins with a type field, a timestamp, and an audit ID, followed by key-value pairs. The audit ID groups related records that together describe one logical event, for example a system call plus its associated path records.
To interpret these logs efficiently, you use specialized tools instead of reading them by hand. ausearch lets you search logs using fields such as username, time range, event ID, or rule key. It can reconstruct a logical event from the multiple records that share the same audit ID. aureport can then summarize matches into reports, such as all login failures in a time interval or all modifications of a monitored directory.
Because audit records are verbose and structured, they adapt well to forwarding into centralized log management systems. Many organizations configure auditd to send events to a remote collector, either directly, through an intermediate relay, or via general log forwarding tools. Remote storage improves resilience against local tampering because an attacker who compromises a host cannot easily erase offsite copies of its audit trail.
Reliability, Performance, and Fail Modes
Auditd introduces both reliability considerations and potential performance impacts. The kernel must deliver events as they occur, and the user space daemon must keep up with writing them. If the event backlog grows faster than auditd can process it, the kernel can enter one of several configured modes. It may start dropping events, or it may block audited system calls until the backlog shrinks. In strict configurations it may even trigger a kernel panic or shutdown to avoid running without an intact audit trail.
The behavior in such failure scenarios is controlled both by kernel audit settings and by auditd configuration parameters. For example, the maximum backlog size determines how many pending events the kernel will accept, and the failure mode decides whether to drop or block when this limit is reached. Disk space thresholds in auditd.conf determine what happens when the log partition is nearly full, such as stopping certain activities or generating warnings.
Performance overhead is usually modest when you audit a limited set of actions. It grows as you increase rule complexity and coverage. File and system call auditing on high traffic paths can add enough overhead to be noticeable. For that reason, production deployments often start with a baseline ruleset and then refine it through testing to balance coverage and system impact.
Typical Use Cases and Integration
Organizations use auditd in several recurring scenarios. One is regulatory compliance, where standards require detailed records of administrative actions, configuration changes, and access to sensitive data. Audit rules are crafted to meet the specific clauses of a regulation, and reports generated by aureport or external tools serve as evidence.
Another common use is incident investigation. When a security incident is suspected, investigators can query audit logs to reconstruct the sequence of actions taken by a compromised account or process. They can find which files were read or changed, which commands were executed, and how permissions evolved over time. The structured nature of audit records aids this reconstruction.
Auditd also integrates into broader security monitoring. Security information and event management systems and intrusion detection platforms often ingest audit logs, correlate them with other data sources, and generate alerts based on patterns that indicate misuse or compromise. In such environments, auditd is one of several sensors that provide visibility into the inner workings of Linux hosts.
Design audit rules with specific goals in mind, such as compliance controls or incident detection. Vague or overly broad rulesets often give you noise instead of actionable security information.
Summary
Auditd is the core user space tool for Linux kernel auditing. It receives events from the kernel according to defined rules, stores them in structured logs, and provides tools to search and report on those events. Its strengths lie in precise, low level visibility into system activity and in the ability to create evidence suitable for security investigations and compliance. At the same time, it demands careful configuration to manage performance, storage, and behavior under failure so that your audit trail remains both reliable and useful.