Linux auditd Configuration Guide: What Rules to Write for Security Monitoring and How to Forward Logs to Your SIEM
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most Linux security logging relies on syslog/journald, which captures what applications choose to log. An attacker with write access to /var/log or the ability to kill a process can interfere with application-level logging. auditd runs at the kernel level and cannot be suppressed by user-space processes (short of loading a kernel module). The configuration challenge is not enabling auditd -- it ships enabled on most enterprise Linux distributions -- but writing rules that produce security-relevant events without drowning in noise.
Core auditd Rule Categories for Security Monitoring
Create a file /etc/audit/rules.d/50-security-baseline.rules with these rule categories:
# --- Delete all existing rules and set buffer size ---
-D
-b 8192
--backlog_wait_time 60000
# --- Immutable: prevent rule modification without reboot (enable last) ---
# -e 2 # Uncomment after testing; makes rules immutable until reboot
# --- Privilege escalation binaries ---
# Alert when setuid/setgid binaries are executed
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k privilege_escalation
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=-1 -k privilege_escalation
# --- Sudo usage ---
-w /usr/bin/sudo -p x -k sudo_use
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/sudoers.d/ -p wa -k sudoers_change
# --- Sensitive file access ---
-w /etc/passwd -p wa -k identity_files
-w /etc/shadow -p wa -k identity_files
-w /etc/group -p wa -k identity_files
-w /etc/gshadow -p wa -k identity_files
-w /etc/security/opasswd -p wa -k identity_files
# --- SSH authorized keys changes ---
-a always,exit -F arch=b64 -S open,openat,truncate,creat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k access
-w /root/.ssh/ -p wa -k ssh_root_keys
# --- Cron modifications ---
-w /var/spool/cron/ -p wa -k cron_changes
-w /etc/cron.d/ -p wa -k cron_changes
-w /etc/cron.daily/ -p wa -k cron_changes
-w /etc/cron.hourly/ -p wa -k cron_changes
-w /etc/crontab -p wa -k cron_changes
-w /etc/at.allow -p wa -k cron_changes
-w /etc/at.deny -p wa -k cron_changes
# --- Systemd persistence ---
-w /etc/systemd/ -p wa -k systemd_changes
-w /usr/lib/systemd/ -p wa -k systemd_changes
# --- Network configuration changes ---
-a always,exit -F arch=b64 -S sethostname,setdomainname -k network_changes
-w /etc/hosts -p wa -k network_changes
-w /etc/network/ -p wa -k network_changes
-w /etc/sysconfig/network -p wa -k network_changes
# --- Kernel module loading ---
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,delete_module -k modules
# --- Time changes (Kerberos / log tampering) ---
-a always,exit -F arch=b64 -S adjtimex,settimeofday -k time_change
-w /etc/localtime -p wa -k time_change
Load the rules:
augenrules --load
# Verify loaded rule count
auditctl -l | wc -l
Process Execution Logging (Execve Auditing)
Logging all process execution on busy systems generates very high volume. Use targeted rules for high-risk binaries instead of auditing all execve calls:
# --- Reconnaissance tools used by attackers ---
-w /usr/bin/whoami -p x -k recon
-w /usr/bin/id -p x -k recon
-w /bin/hostname -p x -k recon
-w /usr/bin/uname -p x -k recon
-w /usr/bin/nmap -p x -k recon
-w /usr/bin/netstat -p x -k recon
-w /usr/bin/ss -p x -k recon
# --- Network utilities commonly abused for lateral movement ---
-w /usr/bin/curl -p x -k download_tools
-w /usr/bin/wget -p x -k download_tools
-w /usr/bin/scp -p x -k download_tools
-w /usr/bin/sftp -p x -k download_tools
# --- Privilege escalation tools ---
-w /usr/bin/passwd -p x -k passwd_change
-w /usr/bin/chpasswd -p x -k passwd_change
-w /usr/sbin/useradd -p x -k user_management
-w /usr/sbin/userdel -p x -k user_management
-w /usr/sbin/groupadd -p x -k user_management
-w /usr/sbin/visudo -p x -k sudoers_change
# --- Shell spawning from unusual parents ---
# (Catches web shell / SSTI / code injection spawning a shell)
-a always,exit -F arch=b64 -S execve -F exe=/bin/bash -F auid=33 -k webserver_shell
# uid 33 = www-data on Debian/Ubuntu; adjust for your distro
For environments that need comprehensive process execution logging, consider Sysdig, Falco, or Auditbeat (Elastic) as a higher-level abstraction over raw auditd syscall events.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Query Audit Logs with ausearch and aureport
ausearch -- filter audit log for specific events:
# Find all sudo executions in the last 24 hours
ausearch -k sudo_use --start today
# Find all shadow file reads/writes
ausearch -k identity_files
# Find all commands run by a specific user
ausearch -ua alice --start yesterday
# Find failed login attempts
ausearch -m USER_AUTH -sv no
# Find specific key and output in interpretable format
ausearch -k privilege_escalation -i | head -50
# -i flag interprets raw hex/uid values into readable strings
aureport -- summary reports:
# Authentication summary
aureport -au
# Shows: date, time, user, terminal, host, result for every auth event
# Executable summary (top programs run)
aureport -x --summary
# Account modification summary
aureport -m
# File access summary
aureport -f --summary
# Failed events in the last hour
aureport --start recent --failed
Real-time monitoring with auditwatch:
# Tail the audit log for specific key in real time
tail -f /var/log/audit/audit.log | grep 'key="privilege_escalation"'
# Or use audisp-plugins to pipe to a named pipe for custom processing
Forward auditd Logs to SIEM
Forward to Splunk via Universal Forwarder:
# /opt/splunkforwarder/etc/system/local/inputs.conf
[monitor:///var/log/audit/audit.log]
index = linux_audit
sourcetype = linux_audit
disabled = false
Splunk has a built-in linux_audit sourcetype that parses auditd format. Use the Splunk App for Unix and Linux for pre-built dashboards.
Forward to Elastic via Auditbeat:
# /etc/auditbeat/auditbeat.yml
auditbeat.modules:
- module: auditd
audit_rules: |
-w /etc/passwd -p wa -k identity
# Include your full rule set here
# OR reference your rules file:
audit_rule_files:
- /etc/audit/rules.d/*.rules
output.elasticsearch:
hosts: ["https://elasticsearch:9200"]
username: "auditbeat"
password: "${ELASTIC_PASSWORD}"
Avoid double-logging: If you deploy Auditbeat, it manages auditd directly and the native auditd daemon may conflict. Choose one: native auditd with log shipping via Filebeat, or Auditbeat managing the audit kernel subsystem directly. The Auditbeat approach provides better ECS (Elastic Common Schema) field mapping.
Log retention: /etc/audit/auditd.conf
max_log_file = 100
num_logs = 10
max_log_file_action = rotate
# Stores 10 x 100 MB = 1 GB of local audit logs before rotation
# Adjust based on your SIEM pipeline reliability
The bottom line
auditd is already installed and running on most enterprise Linux distributions -- the work is writing rules that produce signal without noise. Start with the identity files, sudoers changes, cron modifications, and privilege escalation syscall rules -- these cover the most common attacker persistence and privilege escalation techniques. Add the process execution rules for high-risk binaries. Ship logs to your SIEM via Filebeat or Auditbeat. Use aureport -au as your first command during any Linux incident investigation -- it shows the complete privilege use picture in seconds.
Frequently asked questions
Does auditd work on all Linux distributions?
Yes. auditd is the Linux Audit system and is part of the kernel audit subsystem, available on all Linux distributions. The daemon package name is typically 'auditd' (RHEL/CentOS/Ubuntu) or 'audit' (some Debian-based distros). It ships pre-installed and enabled on RHEL, CentOS, Rocky Linux, and AlmaLinux by default. On Ubuntu/Debian it is available but not always enabled by default -- install with 'apt install auditd' and enable with 'systemctl enable --now auditd'.
Can an attacker disable auditd to cover their tracks?
Partially. A user with root access can stop the auditd service (systemctl stop auditd) or delete log files. However, the audit subsystem is in the kernel -- even if the user-space daemon is stopped, the kernel continues recording audit events in its buffer (until the buffer fills). Additionally, once you ship audit logs to a SIEM in near real-time, deleting local log files does not erase the already-shipped events. For maximum tamper resistance, enable the immutable mode (-e 2 in your rules file) which prevents any modification to audit rules until the system reboots -- this prevents attackers from adding exclusion rules for their activity.
What is the performance impact of auditd on a busy server?
Low to moderate depending on rule scope. Identity file watches and sudoers monitoring generate minimal overhead -- these files are read infrequently. The highest-overhead rules are syscall auditing for execve (process execution) with broad filters, because every process launch triggers the rule. On a web server running hundreds of requests per second, auditing all execve calls from the web server UID adds measurable overhead. The targeted approach -- auditing execve only for specific binaries or UIDs -- maintains security coverage with acceptable performance. Start with file watches and specific binary watches, measure CPU impact, then expand syscall coverage based on your overhead budget.
Is auditd the same as Syslog or Journald?
No. Syslog and Journald are application-level logging systems -- they capture messages that applications choose to write to the logging API. auditd is a kernel-level audit system -- it captures system calls regardless of whether the application logs anything. For security monitoring, auditd is authoritative for events that applications might not log (reading a sensitive file, changing file permissions, a setuid binary being executed). A complete Linux logging stack uses both: auditd for kernel-level security events and syslog/journald for application-level operational events.
How do I forward auditd logs to a SIEM efficiently without overwhelming the network?
Use a log shipper (Filebeat with the auditd module, Fluentd, or rsyslog) to read from the auditd log file (/var/log/audit/audit.log) and forward events to your SIEM. Configure the shipper to batch events and use compression to reduce network overhead. For SIEM cost management, filter at the shipper layer: forward only the event types that matter for your detection use cases (execve, open on sensitive paths, attribute changes on /etc/passwd) and drop low-value events like network socket operations from web servers at high volume. Do not filter out authentication events, privilege changes, or file integrity events -- these are the primary value of auditd for security monitoring.
What are the most important auditd rules to detect common Linux attack techniques?
Critical auditd rules for security monitoring: watch for execve of known attack tools using path-based watches (`-w /usr/bin/nc -p x -k netcat`), monitor writes to /etc/passwd, /etc/shadow, and /etc/sudoers (`-w /etc/passwd -p wa -k passwd_changes`), audit all setuid/setgid executions (`-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid_exec`), watch for kernel module loading (`-w /sbin/insmod -p x -k modules` and `-w /sbin/modprobe -p x -k modules`), log all use of sudo and su (`-w /usr/bin/sudo -p x -k priv_esc`), and audit ptrace system calls used by debuggers and memory dumping tools (`-a always,exit -F arch=b64 -S ptrace -k ptrace`). The STIG for RHEL and Ubuntu and the CIS Linux Benchmarks both include recommended auditd rule sets that cover these categories with proper architecture-specific formatting for 32-bit and 64-bit system calls. Use augenrules to load rules dynamically rather than modifying auditd.rules directly.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.