auditd Linux: Complete Audit Gids (2026)

Q: Wat is het verschil tussen auditd en syslog?

Syslog en journald verzamelen applicatieve berichten die programma's vrijwillig schrijven. auditd registreert kernel-niveau gebeurtenissen (system calls, bestandstoegang en SELinux-beslissingen) die niet door de applicatie zelf onderdrukt kunnen worden. Voor compliance heb je beide nodig, maar alleen auditd levert het onveranderlijke, kernel-gegarandeerde audit-trail dat PCI DSS en HIPAA eisen.

Q: Hoe verschilt auditd van Falco of Tetragon?

auditd is een passieve recorder via netlink. Falco en Tetragon zijn actieve runtime-detectie -engines op eBPF: ze kunnen acties blokkeren (kill, signaal) op basis van policies. Voor compliance kies je auditd; voor preventie eBPF; voor diepe Linux-security combineer je beide.

Bijgewerkt: 17 juni 2026

auditd is de userspace-daemon van het Linux Audit Framework die kernel-audit-gebeurtenissen vastlegt in /var/log/audit/audit.log, en zo een onveranderlijk forensisch spoor biedt van system calls, bestandstoegang, gebruikersacties en SELinux-beslissingen. Het is een verplichte component voor PCI DSS 4.0, HIPAA en CIS Benchmark-compliance op Linux. In deze gids leg ik uit hoe je auditd 3.1.x op moderne distributies installeert, hoe je audit-regels schrijft die niet je hele disk vullen, en hoe je de logs doorstuurt naar een SIEM zoals Wazuh.

Eerlijk gezegd, ik heb auditd jaren onderschat. Tijdens een PCI-audit vorig jaar bleek het stille verschil te maken tussen "compliant" en "we moeten dit opnieuw doen". Sindsdien is het de eerste daemon die ik op een nieuwe server activeer.

auditd bestaat uit de kernel-audit-subsystem, de auditd-daemon (audit-userspace 3.1.x), auditctl voor live regels en ausearch/aureport voor analyse.
Persistente regels horen in /etc/audit/rules.d/*.rules en worden gecompileerd door augenrules tot één geladen ruleset.
De officiële Neil Horman ruleset op GitHub levert kant-en-klare regelsets voor CIS, PCI DSS, STIG en NISPOM.
Audisp-plugins (sinds 3.0 in audit-userspace geïntegreerd) sturen events realtime door naar syslog, remote auditd of een SIEM.
Gebruik -k sleutelvelden bij elke regel. Zonder sleutels is forensisch zoeken in miljoenen events vrijwel onmogelijk.
Disk-bescherming via max_log_file_action, space_left_action en disk_full_action in auditd.conf voorkomt dat een vol filesysteem je server stopzet.

Wat is auditd op Linux?

auditd (Audit Daemon) is de userspace-tegenhanger van de Linux kernel audit-subsystem. Waar syslog en journald applicatieve berichten verzamelen, registreert auditd op kernelniveau elke gebeurtenis die je expliciet markeert: een execve() system call, een wijziging van /etc/passwd, een mislukte sudo-poging, of een SELinux AVC-denial. De logs zijn append-only en bevatten een precieze tijdsstempel, het PID, UID, AUID (login-UID) en de exacte argumenten. Precies wat een auditor of forensisch onderzoeker nodig heeft.

Het Linux Audit Framework werd in 2005 geïntroduceerd in kernel 2.6.6 onder leiding van Steve Grubb (Red Hat). De code wordt nog steeds actief onderhouden in de audit-userspace repository. De huidige stabiele release is 3.1.5; vanaf 3.0 is de afzonderlijke audisp-binary samengevoegd met auditd zelf, en draaien alle plugins nu als interne child-processen. Voor wie het verschil met andere observability-stacks zoekt: auditd is een compliance- en forensische tool, terwijl runtime-detectie projecten zoals Falco en Tetragon (zie onze gids over eBPF Runtime Dreigingsdetectie) op eBPF leunen voor low-latency policy enforcement.

Architectuur van het Linux Audit Framework

Het framework bestaat uit vier nauw samenwerkende lagen. Inzicht in deze opbouw helpt je later sneller te begrijpen waarom een regel niet matcht, of waarom er ineens een miljoen events per minuut binnenkomen.

1. Kernel audit-subsystem (kauditd)

De kernel-thread kauditd ontvangt audit-events van de kernel-syscall-hooks en SELinux/AppArmor LSM-haken. Events worden via een NETLINK_AUDIT-socket naar userspace gestuurd. Vóór auditd actief is, schrijft de kernel cruciale events naar de ringbuffer die je met dmesg kunt lezen.

2. De auditd-daemon

De systemd-unit auditd.service luistert op de netlink-socket, voegt host-context toe en schrijft de events sequentieel naar /var/log/audit/audit.log. De daemon roteert logs zelf. Gebruik dus géén logrotate voor audit-logs.

3. auditctl, augenrules en de regels-pipeline

Met auditctl beheer je de runtime-regels van de kernel. Persistente regels horen in /etc/audit/rules.d/ als losse .rules-bestanden; augenrules sorteert en bundelt deze tot /etc/audit/audit.rules, dat bij elke daemon-start ingeladen wordt.

4. Plugins (voorheen audisp)

Plugins lezen uit een dispatcher-pipe en sturen events door naar syslog, een remote auditd-server of een SIEM. Configuratie staat in /etc/audit/plugins.d/. De bekendste plugins zijn au-remote, syslog en third-party Wazuh- of Auditbeat-collectors.

auditd installeren en starten op Debian, Ubuntu en RHEL

Op vrijwel alle moderne distributies is auditd niet standaard geactiveerd, ook al is het pakket vaak geïnstalleerd. Begin met de installatie en start de daemon:

# Debian 12 / Ubuntu 24.04 LTS
sudo apt update
sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd

# RHEL 9 / Rocky Linux 9 / AlmaLinux 9
sudo dnf install -y audit
sudo systemctl enable --now auditd

# Versie en status controleren
auditctl -v
sudo systemctl status auditd --no-pager
sudo auditctl -s

De output van auditctl -s toont onder andere enabled (0 = uit, 1 = aan, 2 = aan en regels vergrendeld), de pid van de daemon, en de backlog. Een groeiende backlog wijst op een schrijfprobleem. Meer hierover in de sectie over performance-tuning.

Audit-regels schrijven met auditctl en augenrules

Audit-regels vallen in drie categorieën: control-rules (daemon-gedrag), filesystem-watches (bestanden en directories) en system call rules (syscalls per architectuur). Elk regelbestand in /etc/audit/rules.d/ wordt door augenrules --load samengevoegd. De volgorde wordt bepaald door de numerieke prefix (bijvoorbeeld 10-base-config.rules, 30-stig.rules, 99-finalize.rules).

Bestands-watches

# /etc/audit/rules.d/40-identity.rules
# Wijzigingen aan gebruikers- en groepsbestanden volgen
-w /etc/passwd       -p wa -k identity
-w /etc/shadow       -p wa -k identity
-w /etc/group        -p wa -k identity
-w /etc/sudoers      -p wa -k identity
-w /etc/sudoers.d/   -p wa -k identity

De -w-vorm is een afkorting voor een path-filter. -p wa staat voor write en attribute change; -k identity is de zoeksleutel waarmee je later in ausearch -k identity alle gerelateerde events terugvindt.

Syscall-regels

# /etc/audit/rules.d/50-privileged.rules
# Privileged command-uitvoering volgen (zowel 32- als 64-bit)
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k privileged_exec
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k privileged_exec

# Mislukte toegang tot bestanden
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access_denied
-a always,exit -F arch=b64 -S openat -F exit=-EPERM  -F auid>=1000 -F auid!=unset -k access_denied

Belangrijk: filter altijd op auid>=1000 en auid!=unset om de oneindige stroom van systeem-daemon-events buiten te sluiten. auid (audit login UID) blijft constant, ook na su of sudo. En dat is precies waarom auditd onmisbaar is voor accountability.

Regels laden en valideren

# Regels samenvoegen en activeren
sudo augenrules --load

# Actief geladen regels tonen
sudo auditctl -l

# Eventueel een specifieke regel verwijderen
sudo auditctl -W /etc/passwd

# Regels vergrendelen tot volgende reboot (sluiten van runtime-aanpassingen)
sudo auditctl -e 2

Compliance-rulesets: CIS, PCI DSS 4.0 en STIG

Je hoeft niet zelf het wiel uit te vinden. De upstream audit-userspace rules-directory bevat voorgeconfigureerde regelsets per compliance-norm. Voor de bredere context van de Linux-auditstack raad ik ook de Red Hat Security Hardening-documentatie aan, met name het hoofdstuk over auditing op RHEL 9.

30-stig.rules: DISA STIG voor Defense-omgevingen
30-pci-dss-v31.rules: Payment Card Industry DSS 4.0
30-nispom.rules: Industrial Security Manual (NISPOM 8-602a)
40-local.rules: sjabloon voor eigen aanpassingen

# Een upstream-ruleset overnemen (RHEL 9 voorbeeld)
sudo cp /usr/share/audit/sample-rules/30-stig.rules \
        /etc/audit/rules.d/
sudo augenrules --check
sudo augenrules --load

Voor diepere CIS Benchmark-controles raad ik aan dit te combineren met een geautomatiseerde scanner. Onze gids over Lynis en OpenSCAP beschrijft hoe je de gegenereerde audit-events kruisreferenseert met CIS- en NIST-controles voor een volledige audit-trail.

Audit-logs analyseren met ausearch en aureport

Pure tekstgrep op audit.log is een recept voor frustratie. De events bestaan uit meerdere regels (SYSCALL, EXECVE, PATH, CWD) die logisch bij elkaar horen. Gebruik in plaats daarvan de meegeleverde tools.

ausearch — gefilterd zoeken

# Alle events met sleutel "identity" van de laatste 24 uur
sudo ausearch -k identity --start recent -i

# Alle execve-syscalls van UID 1001 vandaag
sudo ausearch -ua 1001 -sc execve --start today -i

# Mislukte logins via SSH
sudo ausearch -m USER_LOGIN -sv no --start week-ago -i

# JSON-output voor verwerking in jq of een SIEM
sudo ausearch -k privileged_exec --start today --format text | \
  ausearch -k privileged_exec --start today --format csv

De -i vlag interpreteert UIDs, syscall-nummers en exit-codes naar leesbare namen. --format text|csv|raw bepaalt het uitvoerformaat; voor JSON gebruik je ausearch --format text | aureport --json.

aureport, voor samenvattingen

# Top 10 commando's
sudo aureport -x --summary | head

# Mislukte authenticaties per gebruiker
sudo aureport -au --failed --summary -i

# Alle anomalie-events (kernel-detectie zoals seccomp-kill)
sudo aureport -k --summary

auditd logs doorsturen naar een SIEM

Voor centrale forensische analyse moeten audit-events naar een SIEM. Drie veelgebruikte paden in 2026:

Aspect	au-remote plugin	syslog plugin	Wazuh / Auditbeat agent
Transport	TCP/TLS naar remote auditd	UDP/TCP naar lokale rsyslog	HTTPS naar SIEM-manager
Formaat	Native audit-records	Platgeslagen syslog-bericht	JSON met decoded velden
Reliability	At-least-once met queueing	Best-effort	Acked met disk-buffer
Compliance-fit	PCI DSS 10.5.4 ✓	Beperkt	Volledig met Wazuh-rules
Beheerlast	Hoog (mTLS-certificaten)	Laag	Middelmatig

Voorbeeld: syslog plugin

# /etc/audit/plugins.d/syslog.conf
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_LOCAL6
format = string

Configureer vervolgens rsyslog om local6.* door te sturen naar de centrale collector. Voor Wazuh: installeer de Wazuh-agent en activeer localfile met /var/log/audit/audit.log in ossec.conf. Onze Wazuh installatiegids behandelt de SIEM-zijde van deze pipeline.

Performance-tuning en disk-bescherming

Een slecht geconfigureerde audit-ruleset kan een productieserver echt verlammen. Stem /etc/audit/auditd.conf af op je workload:

# /etc/audit/auditd.conf — belangrijke parameters
log_file = /var/log/audit/audit.log
log_format = ENRICHED
log_group = adm
freq = 50
num_logs = 10
max_log_file = 100
max_log_file_action = ROTATE
space_left = 1024
space_left_action = SYSLOG
admin_space_left = 512
admin_space_left_action = SUSPEND
disk_full_action = SYSLOG
disk_error_action = SYSLOG
flush = INCREMENTAL_ASYNC

Stel flush = INCREMENTAL_ASYNC in op high-throughput servers om elke 50 events asynchroon te flushen. Stel max_log_file_action = ROTATE in plaats van KEEP_LOGS in om disk-uitputting te voorkomen. Voor zeer strenge omgevingen kies je admin_space_left_action = SINGLE: de server gaat naar single-user mode bij ruimtegebrek, wat data-verlies voorkomt maar uptime kost.

Veelvoorkomende problemen oplossen

"Audit daemon is not listening" bij boot

Controleer of audit=1 in /proc/cmdline staat. Zo niet, voeg het toe aan GRUB_CMDLINE_LINUX in /etc/default/grub en draai update-grub (Debian) of grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL).

Regels worden niet geladen

# Syntax checken zonder te laden
sudo augenrules --check

# Verbose laden voor foutmeldingen
sudo augenrules --load 2>&1 | less

Backlog vol, events verloren

Verhoog de buffer met auditctl -b 16384 en stel -f 1 in (printk-warning bij failure in plaats van panic). Voeg de waarden permanent toe aan 10-base-config.rules.

SELinux AVC-denials niet zichtbaar

Zorg dat dontaudit-regels niet je gewenste events onderdrukken. Met semodule -DB deactiveer je tijdelijk alle dontaudit-regels voor diagnose. Vergeet niet daarna semodule -B uit te voeren.

Veelgestelde vragen

Wat is het verschil tussen auditd en syslog?

Syslog en journald verzamelen applicatieve berichten die programma's vrijwillig schrijven. auditd registreert kernel-niveau gebeurtenissen (system calls, bestandstoegang en SELinux-beslissingen) die niet door de applicatie zelf onderdrukt kunnen worden. Voor compliance heb je beide nodig, maar alleen auditd levert het onveranderlijke, kernel-gegarandeerde audit-trail dat PCI DSS en HIPAA eisen.

Is auditd vereist voor PCI DSS 4.0 compliance?

PCI DSS 4.0 vereiste 10 verplicht audit-trails voor alle toegang tot kaarthouderdata en privileged commando's. Hoewel de standaard auditd niet bij naam noemt, is het de facto de enige Linux-tool die alle verplichte velden levert (gebruiker-id, type event, datum/tijd, succes/falen, oorsprong en getroffen resource). Een auditor accepteert zelden een alternatief zonder uitgebreide compensatiecontroles.

Kan auditd containers monitoren?

Ja, maar met caveats. auditd ziet alle syscalls van de host-kernel, inclusief die uit containers, omdat containers een gedeelde kernel hebben. Het probleem is correlatie: de PID in audit.log is de host-PID, niet de container-PID. Gebruik de contid audit-field (kernel 5.14+) of combineer met eBPF-tools zoals Tetragon voor container-bewustzijn.

Hoeveel disk-ruimte heeft auditd nodig?

Met een CIS- of STIG-ruleset reken je gemiddeld op 50 tot 200 MB per server per dag, afhankelijk van de workload. Een CI-runner die duizenden builds draait kan pieken naar 2 GB/dag. Plan minimaal 30 dagen lokale retentie (ongeveer 6 GB) plus centrale SIEM-retentie voor 1 jaar volgens compliance-eisen.

Hoe verschilt auditd van Falco of Tetragon?

auditd is een passieve recorder via netlink. Falco en Tetragon zijn actieve runtime-detectie-engines op eBPF: ze kunnen acties blokkeren (kill, signaal) op basis van policies. Voor compliance kies je auditd; voor preventie eBPF; voor diepe Linux-security combineer je beide.