Auditd Done Right: Building Enterprise-Grade Linux Audit Telemetry

Linux auditd is one of the most powerful, and most misunderstood telemetry mechanisms available in enterprise environments.

Too often, it’s deployed as a compliance checkbox, configured with overly broad rules, and then quietly blamed for performance issues or unusable noise. In reality, auditd sits at a unique position in the Linux stack. It observes system behavior at the syscall level, before userspace abstractions hide important context. When engineered correctly, it can provide deterministic, high-fidelity visibility that complements EDRs, SIEMs, and traditional logging. When engineered poorly, it becomes a liability.

This post is not a beginner’s guide, nor a copy-paste rule dump. It’s a practical, experience-driven walkthrough of how to build enterprise-grade Linux audit telemetry. from understanding how auditd actually works, through rule engineering and fleet-wide deployment, to structuring and enriching audit logs using Laurel so they are usable at scale.

Threat detection deserves its own deep dive. Here, the focus is on the foundation: getting auditd right.

How auditd actually works

Auditd relies on two main components: the kernel audit subsystem and the audit daemon (auditd).

Kernel audit subsystem

• Integrated into the Linux kernel, it monitors system calls according to configured audit rules.
• When a syscall matches a rule, the kernel generates an audit record, which includes metadata such as process IDs, user IDs, syscall arguments, timestamps, and other contextual data.
• This subsystem is responsible for event generation, ensuring deterministic, kernel-level logging of matched system activity.

Audit daemon (auditd)

• Runs in user-space and manages interaction with the kernel audit subsystem.
• Handles configuration management: reading audit rules, validating syntax, and delivering them to the kernel for enforcement.
• Collects audit events from the kernel and writes them to disk.
• Provides log management features such as rotation, buffering, and crash-safe persistence.
• Supports a plugin system that allows additional components to process or enrich audit events in real time. Plugins read events through auditd via netlink sockets and can transform, filter, or forward them. This adds an extra layer of design, as plugins like Laurel integrate at this level to restructure, enrich, and normalize audit logs without modifying the core daemon.

Auditd Rule Engineering

Proper auditd rule engineering is essential for reliable, high-fidelity Linux telemetry in enterprise environments. It’s not enough to deploy auditd, the quality and structure of your rules determine how actionable and maintainable your logs will be.

Rule Types

Auditd rules are defined using three main types:

Syscall rules (-a, -S)

Track specific system calls such as execve, open, connect

File watches (-w)

Monitor files or directories for read, write, execute, or attribute changes, e.g watching /etc/shadow for writes.

Control rules (-e, -b, -f, -D,...)

Configure audit system or kernel audit subsystem behavior such as setting backlog limit, defining auditd failure mode, set immutable mode and more.

Recommended auditd configurations

For enterprise deployments, it’s best to start with a baseline and then fine-tune rules according to your environment, applications, and compliance needs. Here are two widely respected configurations to consider:

1. Florian Roth's configuration
2. auditd configuration mapped to MITRE

Tip: Always test baseline configurations in a staging environment first. Fine-tune syscall filters, and watched files to balance audit coverage with system performance. These baselines are foundations to build your enterprise-grade audit policy.

Deep Dive Into Rules

The following rules are selected to showcase different auditd rules features

1. Process execution via execve

-a exit,always -F arch=b64 -S execve -k exec

This is a basic syscall rule evaluated at syscall exit. exit,always ensures the event is logged after execution completes, allowing access to return values and final context. arch=b64 restricts the rule to the 64-bit syscall ABI. On systems where 32-bit execution is enabled, syscalls may arrive via both 32-bit and 64-bit paths. Being explicit avoids ambiguity and unintended duplication. execve is the syscall used for program execution, making this a fundamental rule for understanding how auditd captures process activity. The -k flag assigns a key to the rule, which is included in the generated event.

2. File integrity monitoring using watches

-w /etc/passwd -p wa -k passwd_changes

This rule watches the file /etc/passwd for changes. The -w flag specifies the path to monitor, and -p wa sets the permissions to watch for: w for write operations and a for attribute changes. When any matching action occurs, auditd generates an event and tags it with the key passwd_changes (-k). Internally, auditd translates this file watch into the relevant syscalls, so it still relies entirely on syscall monitoring to detect modifications.

3. Unauthorized critical file access by logged-in users

-a exit,always -F arch=b64 -S open,openat -F auid!=-1 -F exit=-EPERM -k critical_access_denied

This rule logs attempts to access files that were denied due to insufficient permissions (exit=-EPERM) on 64-bit systems (arch=b64) for processes tied to a login session (auid!=-1). Multiple syscalls (open and openat) are combined to capture different access methods.

Deploying Auditd

In enterprise environments, manually deploying and configuring auditd across dozens or hundreds of hosts quickly becomes unmanageable. Using a solution like Ansible can automate the process: installing auditd, deploying baseline rule sets to /etc/audit/rules.d/, validating syntax, and restarting the service. This approach guarantees consistency and reproducibility across all systems, reduces human error, and allows teams to quickly roll out updates or new rules. With this automation in place, integrating additional components like the Laurel plugin becomes straightforward, since all hosts share the same baseline configuration.

1. My ansible role
2. another version of auditd with laurel ansible role

Auditd Laurel Integration

Auditd provides a plugin system that allows user-space components to process audit events in real time. Plugins communicate with the audit daemon via netlink sockets, consuming the events generated by the kernel audit subsystem and managed by auditd. This design adds flexibility: instead of modifying the core daemon, additional components can filter, restructure, enrich, or forward events for downstream processing.

One practical example is the Laurel plugin, which reads audit events directly through auditd and outputs them in a structured JSON format. Laurel can enrich events with additional metadata, normalize field names, and make them immediately usable for SIEMs or custom analytics pipelines. The configuration and installation are straightforward, you can read more about it in the official repository. Using plugins like Laurel in an enterprise environment has clear benefits. It enables automated event enrichment, reduces the burden of parsing raw audit logs, and ensures consistent telemetry for security monitoring and compliance. Combined with well-designed audit rules and automated deployment, plugin integration completes the foundation for scalable, maintainable, enterprise-grade Linux audit telemetry.

Auditd Tips & Tricks

• AUID vs UID: The Audit User ID (auid) represents the original login session. Unlike the UID, which can change with sudo or other privilege escalations, the auid remains consistent, making it ideal for tracking real user activity.
• Forwarding events: While auditd and Laurel handle event collection and enrichment, rsyslog complements them perfectly for forwarding structured audit events to a SIEM or central log collector.
• Controlling noise: Certain event types, like AVC (SELinux) messages, can generate excessive noise. These can be silenced or filtered in the configuration to reduce log clutter without losing important audit data.
• Protecting audit configuration: Critical rules and configuration can be made immutable. Use the --loginuid-immutable control rule for reliable session tracking, and -e 2 to protect the auditd configuration itself from modification.
• Event correlation: Auditd often generates multiple records for a single action. The msg field, containing timestamp and ID, is used by plugins like Laurel to correlate them into a single logical event.
• Performance tuning: For background processes where you don’t care about every action, using filters like auid!=-1 can significantly reduce logging overhead and improve performance.
• Data-driven fine-tuning: Analyze audit statistics to identify files or paths that generate the most events. Consider excluding high-volume, low-value files from main rule sets to reduce noise and improve efficiency.