Auditd på Linux 2026: Skriva regler, tolka händelser och strömma till din SIEM

Uppdaterad: 4 september 2026

Auditd är Linux-kärnans revisionsdemon som fångar systemanropshändelser (execve, öppning av filer, moduler som laddas, mount, ptrace) och skriver dem till /var/log/audit/audit.log för forensik och SIEM-analys. Till skillnad från journald, som fångar applikationsloggar, arbetar auditd på syscall-nivå via kärnans audit-subsystem och kan användas för att uppfylla PCI-DSS 10.2, HIPAA §164.312(b) och CIS Benchmark 4.1. Den här guiden visar hur du skriver regler, tolkar händelser och strömmar dem till en central SIEM utan att förlora loggar vid omstart.

• Auditd hakar in i kärnans audit-subsystem och kan logga varje syscall. Falco och Tetragon (eBPF) är komplement, inte ersättare, när du behöver CIS/STIG-efterlevnad.
• Skriv regler i /etc/audit/rules.d/*.rules och kompilera dem med augenrules --load. Auditctl-flags som injiceras direkt överlever inte en omstart.
• Neo23x0/auditd är den de facto-standardiserade regeluppsättningen (MITRE ATT&CK-mappad) för produktion, med lämpliga undantag för att undvika 100% CPU-belastning.
• Skicka loggar via audisp-syslog eller audit_pipe till Vector eller rsyslog med disk-buffring på klienten. Annars tappar du händelser när SIEM:en är otillgänglig.
• Sätt disk_full_action = SUSPEND och övervaka backlog: en full auditkö kan blockera hela systemet om failure_flag är satt till 2 (panic).
• Använd nyckelord (-k) i varje regel så att ausearch -k och SIEM-korrelation fungerar utan att du parsar rå syscall-text.

Vad är auditd och hur skiljer det sig från journald?

Så, låt oss börja med grunderna. Auditd är användarrymdsdelen av Linux Audit Framework, kärnkomponenten som Linus Torvalds motvilligt slog in i 2.6.6 för att SELinux-utvecklarna på Red Hat skulle kunna uppfylla Common Criteria EAL4+. Kärnan skickar strukturerade händelser via en netlink-socket (NETLINK_AUDIT) till PID 1:s auditd-process, som i sin tur skriver dem till audit.log i det välkända type=SYSCALL msg=audit(...)-formatet. Journald läser däremot standardutmatning från systemd-enheter samt /dev/log-meddelanden. Helt annan trafik, helt annan användning.

Skillnaden spelar roll i praktiken. När PCI-DSS-revisorer frågar efter "audit trail för all root-aktivitet" räcker det inte att peka på journalctl _UID=0, eftersom ett angripargenererat program som skriver direkt till /dev/mem aldrig behöver anropa syslog. Auditd fångar däremot syscall-nivån och kan inte kringgås utan att man antingen laddar en kärnmodul eller hittar en 0-day i själva audit-subsystemet. Priset är mer verbose loggar och en icke-trivial regelinställning.

Det finns en integration: systemd-journald-audit.socket vidarebefordrar auditloggar in i journald så att journalctl -k --grep AUDIT fungerar. Ärligt talat rekommenderar jag att du stänger av den om du använder auditd på allvar. Dubbla loggkanaler skapar bara förvirring och fördubblar disk-IO.

Installera och starta auditd på Debian 12, RHEL 10 och Ubuntu 24.04

Paketet heter auditd på Debian/Ubuntu och audit på RHEL/Rocky/Alma. På alla moderna distributioner är kärnstödet redan aktiverat, kontrollera med grep CONFIG_AUDIT /boot/config-$(uname -r).

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

# RHEL 10 / Rocky Linux 10
sudo dnf install -y audit audit-libs
sudo systemctl enable --now auditd

# Kontrollera att kärnan pratar med demonen
sudo auditctl -s
# enabled 1
# failure 1
# pid 842
# rate_limit 0
# backlog_limit 8192
# lost 0
# backlog 0

Notera flaggan failure 1. Värdet styr vad kärnan gör när audit-kön är full: 0 = tyst, 1 = printk till dmesg, 2 = kernel panic. Använd aldrig 2 på en produktionsmaskin om du inte har mycket goda skäl. Jag såg en fintech-kund brick:a sitt betalningskluster på tre sekunder efter att ha satt det tillsammans med en dåligt tänkt -a always,exit -F arch=b64 -S execve-regel på en NGINX-front. Inte kul att hantera vid 03:00.

Det första du bör göra efter installation är att sätta local_events = yes, disk_full_action = SUSPEND och space_left_action = EMAIL i /etc/audit/auditd.conf. SUSPEND stoppar loggningen tillfälligt istället för att låta root-partitionen fyllas. Felmoden är att vissa syscalls kommer att blockera, men systemet överlever, vilket är precis vad du vill.

Skriva auditregler med auditctl och rules.d

Auditregler kommer i tre smaker: kontrollregler (globala inställningar), filsystemregler (watches på sökvägar) och syscall-regler (filter på systemanrop). Skriv aldrig regler med auditctl direkt i shellet på en produktionsserver, de överlever inte en omstart. Använd istället /etc/audit/rules.d/ och kör sudo augenrules --load för att kompilera dem till /etc/audit/audit.rules.

Här är en minimal produktionsprofil som fångar det som praktiskt taget varje compliance-ramverk (CIS, STIG, PCI-DSS, HIPAA) kräver:

# /etc/audit/rules.d/10-base.rules
# Rensa alla befintliga regler
-D

# Öka backlog för att undvika förluster vid syscall-burst
-b 16384

# Sätt failure-mode: 1 = logga till dmesg
-f 1

# --- Kontobearbetning: användare/gruppändringar ---
-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

# --- Autentiseringshändelser ---
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins
-w /var/log/tallylog -p wa -k logins

# --- Privilegierade kommandon ---
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k rootcmd

# --- Kärnmoduler ---
-a always,exit -F arch=b64 -S init_module,delete_module,finit_module -k modules

# --- Ändringar av tid ---
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time

# --- Låsning: gör reglerna oföränderliga tills omstart ---
-e 2

Ladda och verifiera:

sudo augenrules --load
sudo auditctl -l | head -20
sudo auditctl -s | grep -E 'enabled|backlog'

Raden -e 2 gör konfigurationen låst, inga fler regeländringar kan göras utan omstart. På känsliga hostar (bastion, HSM-proxy) är det värt besväret. På utvecklarmaskiner är det bara irriterande. Fältet -F auid!=unset filtrerar bort systemprocesser som körs innan en användare loggat in, vilket dramatiskt minskar bruset.

Tolka auditloggar med ausearch, aureport och auparse

Rå auditloggar är oläsliga. Varje händelse kan spänna över 5-10 rader med type=SYSCALL, type=EXECVE, type=CWD, type=PATH och type=PROCTITLE. Använd verktygen som följer med paketet:

# Alla händelser för ett nyckelord under senaste dygnet
sudo ausearch -k rootcmd --start yesterday --interpret

# Sammanfattning per användare
sudo aureport --user --summary -i

# Endast misslyckade authentiseringar
sudo aureport --auth --failed -i --start today

# Konvertera till JSON för vidarebefordran
sudo ausearch -k identity --start today --format json

Flaggan -i (interpret) översätter UID/GID till namn och syscall-nummer till läsbara namn. Använd den alltid vid manuell inspektion. Formatet --format json (nytt i audit-userspace 3.1, standard på RHEL 10 och Ubuntu 24.04) är det du vill mata in i en SIEM.

För programmatisk parsing i egna skript, använd auparse-biblioteket i Python (python3-auparse) eller Go. Att försöka regex:a rå audit.log är ett antimönster jag har sett i alldeles för många internlagda "SOC-verktyg". Fältordningen är inte garanterad, och nya kärnversioner kan lägga till fält utan förvarning. Har hänt mig också, en gång räckte.

STIG- och CIS-profiler: färdiga regeluppsättningar

Skriv inte alla dina auditregler från noll. De två referensuppsättningar som används i produktion är Neo23x0/auditd (Florian Roth, MITRE ATT&CK-mappad, ~470 regler) och DISA STIG-profilerna för RHEL 9/10 och Ubuntu 22.04/24.04. Neo23x0-uppsättningen är utgångspunkten för de flesta seriösa detection engineering-team.

# Hämta Neo23x0-uppsättningen och installera i rules.d
sudo curl -o /etc/audit/rules.d/audit.rules \
  https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules
sudo augenrules --load
sudo auditctl -l | wc -l
# 470

Räkna med att du behöver kommentera bort 10-20% av reglerna för din specifika arbetslast. MITRE_T1547_004_Winlogon_Helper_DLL är till exempel meningslös på Linux, och några av mount-reglerna genererar tusentals händelser per minut på Kubernetes-noder där kubelet ständigt monterar volymer. Se avsnittet om prestanda nedan.

Om du redan använder OpenSCAP för CIS-efterlevnad kan du generera en auditprofil direkt från benchmark:et:

sudo oscap xccdf generate fix \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --template urn:xccdf:fix:script:ansible \
  /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml > cis-audit.yml

Detta är förresten hur jag underhåller våra profiler för afrikanska ISP-miljöer där bandbreddsantaganden i standard-STIG:en inte alltid håller.

Skicka auditloggar till en SIEM med Vector eller rsyslog

Att bara skriva loggar lokalt är meningslöst om en angripare kan radera dem. Du behöver strömma händelserna av maskinen i realtid. Auditd stöder fyra huvudsakliga transportmekanismer:

1. audisp-syslog: dispatch-plugin som skickar via syslog(3) till lokal rsyslog/syslog-ng, som sedan vidarebefordrar över TLS.
2. audisp-remote: inbyggd TCP/TLS-klient (deprecated i 3.1, används inte längre i nya deployments).
3. audisp-af_unix: streamar över en Unix-socket till en modern loggagent som Vector eller Fluent Bit.
4. systemd-journald-audit: matar in i journald och låter systemd-journal-upload hantera resten.

Jag använder Vector i produktion eftersom det har inbyggd disk-buffring, gzip-komprimering och ett riktigt transformationsspråk (VRL). Här är en fungerande konfiguration:

# /etc/audit/plugins.d/af_unix.conf
active = yes
direction = out
path = /sbin/audisp-af_unix
type = always
args = 0640 /var/run/audispd_events
format = string

# /etc/vector/vector.yaml
sources:
  auditd:
    type: socket
    mode: unix
    path: /var/run/audispd_events
    socket_file_mode: 0640
    max_length: 102400

transforms:
  parse_audit:
    type: remap
    inputs: [auditd]
    source: |
      . = parse_key_value!(.message, field_delimiter: " ", key_value_delimiter: "=")
      .host = get_hostname!()
      .timestamp = now()

sinks:
  siem:
    type: elasticsearch
    inputs: [parse_audit]
    endpoints: ["https://siem.internal.example.com:9200"]
    api_version: v8
    tls:
      ca_file: /etc/ssl/certs/internal-ca.pem
    buffer:
      type: disk
      max_size: 268435456   # 256 MiB
      when_full: block

Nyckeldetaljerna: buffer.type: disk gör att Vector spillar över till /var/lib/vector/ när SIEM:en är otillgänglig, och when_full: block säkerställer att auditd själv sätter backpressure snarare än att Vector tappar händelser tyst. Utan detta är det trivialt för en angripare att fylla nätverkspipen med brus och få dina larm att försvinna. Jag råkade ut för exakt det scenariot under en tabletop-övning en gång, sen dess sätter jag alltid backpressure.

För teams som redan kör rsyslog (majoriteten av traditionella Debian-fleet:er) räcker det med omfwd över TLS till en central log server:

# /etc/rsyslog.d/60-audit.conf
module(load="imfile")
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="audit"
      Facility="local6"
      Severity="info")

action(type="omfwd"
       protocol="tcp"
       target="siem.internal.example.com"
       port="6514"
       StreamDriver="ossl"
       StreamDriverMode="1"
       StreamDriverAuthMode="x509/name"
       StreamDriverPermittedPeers="siem.internal.example.com"
       queue.type="LinkedList"
       queue.filename="audit_fwd"
       queue.maxdiskspace="1g"
       queue.saveonshutdown="on"
       action.resumeRetryCount="-1")

Här ligger den kritiska raden i queue.saveonshutdown="on". Utan den förlorar du hela kön vid en oplanerad omstart. Kombinera med eBPF-baserad runtime-övervakning via Falco eller Tetragon för att fånga händelser som auditd missar (in-memory-only, syscall-free operations).

Auditd vs eBPF: när Falco och Tetragon är bättre val

Frågan "ska jag byta ut auditd mot eBPF?" kommer upp i varje CKS-förberedelse jag håller. Kort svar: nej, de löser olika problem. Långt svar följer.

Egenskap	Auditd	Falco/Tetragon (eBPF)
Kärn-integration	audit-subsystemet (statiskt)	eBPF-program (dynamiskt)
Prestandaöverhuvud	3-15% CPU vid tunga regler	<1% CPU vanligtvis
Regelutbyte utan omstart	Nej (om -e 2 är satt)	Ja
PCI-DSS/CIS-erkännande	Referensverktyg	Ännu inte accepterat av alla revisorer
Fånga in-memory exploits	Begränsat	Ja (uprobes, kprobes)
Container-medvetenhet	Kräver namespace-mapping manuellt	Inbyggd (cgroup, pod, image)
Fungerar på gamla kärnor (<4.18)	Ja (2.6.6+)	Begränsat

I praktiken kör vi båda parallellt: auditd på värd-OS för compliance-bevis, Falco i en DaemonSet för runtime-detection i Kubernetes. Overheaden är hanterlig eftersom vi begränsar auditd-reglerna till compliance-minimum (~50 regler, inte 470) och låter Falco göra det tunga arbetet med threat detection. Se SELinux praktisk guide för RHEL 10 för hur auditd interagerar med SELinux AVC-loggarna, i praktiken är auditd transportkanalen för alla AVC-denials.

Prestandapåverkan och regler att undvika i produktion

Auditd har ett rykte om sig att vara tungt. Verkligheten: det är regelsetet, inte demonen, som är boven. En regel som -a always,exit -F arch=b64 -S open,openat matchar bokstavligen varje filöppning på systemet. På en genomsnittlig applikationsserver är det 50 000+ händelser per sekund. Kärnan spenderar sedan CPU på att formatera och kopiera händelserna till audit-kön, vilket översätts direkt till syscall-latens.

Regler att undvika på produktion utan hårt filtrering:

• -S open,openat,openat2 utan -F path= eller -F dir=-scoping
• -S read,write, stort sett aldrig användbart, alltid för brusigt
• Watches på /proc, /sys, /tmp, /var/lib/containerd
• Regler utan -F auid!=unset, fångar allt kernel- och init-brus

Mät alltid med auditctl -s före och efter regeländringar. Kolonnerna lost och backlog är kritiska: om lost ökar tappar du bevis, och om backlog ligger konsekvent nära backlog_limit är kärnan bakom och du står inför en soft-lockup. Öka -b till 32768 eller 65536 om du kör med tunga regelsetter.

Vanliga fällor och felsökningstips

Fem problem jag ser om och om igen:

1. Reglerna försvinner efter omstart. Du redigerade /etc/audit/audit.rules direkt istället för att lägga en fil i /etc/audit/rules.d/. Den förstnämnda skrivs över av augenrules vid varje boot. Klassisk fälla.
2. audit.log rullar över för snabbt. Justera max_log_file, num_logs och max_log_file_action i auditd.conf. På hostar med tunga regler använd max_log_file = 100 (MB) och num_logs = 20.
3. ausearch returnerar "no matches" trots att du ser händelser med tail. Klockan är sannolikt inte synkroniserad, ausearch --start today använder systemtid. Kör timedatectl och kontrollera att NTP är aktivt.
4. SELinux AVC-denials dyker inte upp. Det är för att type=USER_AVC-händelser filtreras separat. Använd ausearch -m AVC,USER_AVC,SELINUX_ERR.
5. Containers loggar med värdens auditd men saknar namespace-kontext. Aktivera audit_containers-fältet genom att köra auditctl --loginuid-immutable och använd containerd-plugin i din log-shipper för att berika händelserna.

För en helhetsbild av observability på Linux, kombinera auditd med journald-baserad applikationsloggning och nätverksflödesloggar. Se vår Zero Trust-arkitektur på Linux för hur logg- och identitetsdata knyts ihop i en modern arkitektur. Officiell referens för själva kärnsubsystemet finns i audit.rules(7) och en mer utförlig genomgång av auditregler i Red Hats hardening-guide.

Vanliga frågor

Vad är skillnaden mellan auditd och journald?

Auditd fångar syscalls från kärnans audit-subsystem och kan inte kringgås av användarrymdsprocesser. Journald samlar in applikationsloggar (stdout/stderr från systemd-enheter och syslog-meddelanden). Använd auditd för compliance och forensik, journald för applikationsdebug.

Var loggar auditd sina händelser?

Standardplatsen är /var/log/audit/audit.log, konfigurerad via log_file i /etc/audit/auditd.conf. Filen roteras automatiskt när den når max_log_file (standard 8 MB) och gamla loggar behålls enligt num_logs.

Är auditd fortfarande relevant med eBPF-baserade verktyg?

Ja, av två skäl: revisorer accepterar det som referensverktyg för PCI-DSS, HIPAA och CIS-benchmarks, och det fungerar på äldre kärnor där eBPF-verktyg som Falco eller Tetragon inte kan installeras. Kör båda parallellt, auditd för compliance, eBPF för avancerad threat detection.

Hur skickar jag auditloggar till Splunk eller Elasticsearch?

Använd Vector eller rsyslog som mellanled. Vector läser via audisp-af_unix-pluginet över en Unix-socket, parsar med VRL och skickar till Splunk HEC eller Elasticsearch med disk-buffring så att loggar överlever nätverksavbrott. rsyslog med omfwd/omhttp fungerar också på traditionella flottor.

Hur stor prestandaöverhuvud har auditd på ett produktionssystem?

Med en minimal CIS-baserad regeluppsättning (~50 regler): 1-3% CPU-overhead. Med Neo23x0-uppsättningen (~470 regler): 5-15% på syscall-intensiva arbetslaster som Kubernetes-noder eller databasservrar. Regler som matchar open/read/write utan sökvägsfiltrering är den vanligaste orsaken till ohanterlig belastning.