Linux auditd i 2026: Din Guide til Systemrevision, Trusseldetektion og Compliance

Introduktion

Hvis du arbejder med Linux-servere, kender du sikkert følelsen: du vil gerne have styr på sikkerheden, men du kan ikke beskytte noget, du ikke kan se. Og det er præcis dér, auditd — Linux Audit Framework — kommer ind i billedet. Det er et kernenært overvågningssystem, der registrerer systemkald, filadgang, loginforsøg og administrative handlinger helt nede på operativsystemniveau.

I 2026 har vi allerede passeret 600 Linux-kernerelaterede CVE'er alene i første kvartal. Proaktiv overvågning er ikke længere noget, man kan vælge fra — det er simpelthen en nødvendighed. Uanset om du kører en enkelt server eller et helt datacenter, leverer auditd de rå data, som værktøjer som Wazuh, OSSEC og Elastic SIEM bygger deres trusseldetektion ovenpå.

Denne guide dækker det hele: installation, arkitektur, avancerede revisionsregler, compliance-krav, loganalyse med ausearch og aureport, ydelsestuning og SIEM-integration. Alle eksempler er testet på Ubuntu 24.04 LTS og RHEL 9 med kerne 6.x.

Så lad os komme i gang.

Hvad er Linux Audit Framework?

Linux Audit Framework er kort sagt et kernebaseret revisionssystem. Det opfanger systemkald og genererer revisionsregistreringer ud fra regler, du selv definerer. I modsætning til applikationsniveauets logning hægter auditd sig direkte ind i kernen og opfanger hændelser, før de kan manipuleres af brugerrumsprocesser. Det gør det til et solidt fundament for sikkerhedsovervågning og compliance.

Arkitektur og komponenter

Systemet har to hoveddele: kernekomponenten og brugerrumsværktøjerne. Her er de vigtigste:

• Kerne-audit-undersystemet: Opfanger systemkald og filtrerer dem gennem tre filtre — user, task og exit. Hændelser, der matcher, sendes videre til audit-dæmonen.
• auditd-dæmonen: Modtager hændelser fra kernen og skriver dem til logfiler (typisk /var/log/audit/audit.log).
• auditctl: Kommandolinjeværktøj til dynamisk styring af revisionsregler — det bruger du mest i hverdagen.
• ausearch: Søgeværktøj til at finde specifikke hændelser i revisionsloggen.
• aureport: Rapporteringsværktøj der laver oversigter og sammenfatninger. Rigtig nyttigt til hurtige overblik.
• augenrules: Kompilerer regelfiler fra /etc/audit/rules.d/ til den endelige /etc/audit/audit.rules.
• audispd (audit event dispatcher): Videresender revisionshændelser til eksterne systemer i realtid.

Hvorfor er auditd vigtigt?

Helt ærligt — auditd leverer kapaciteter, som ingen andre Linux-logningssystemer kommer i nærheden af:

• Kerneniveauovervågning: Registrerer hændelser på det dybeste niveau, før brugerrumsprocesser kan nå at manipulere noget.
• Compliance: Opfylder krav fra PCI DSS (krav 10.2), HIPAA, SOC 2, NIST 800-53 og ISO 27001.
• Uigenkaldelighed: Revisionsregistreringer kan ikke slettes af de processer, der genererede dem. Det er ret vigtigt under et angreb.
• Fleksible regler: Du har granulær kontrol over præcis, hvad der overvåges.
• Integration: Fungerer som datakilde for Wazuh, Elastic Security, Splunk og andre SIEM-systemer.

Installation og grundlæggende konfiguration

Installation på Ubuntu/Debian

sudo apt update
sudo apt install auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

Installation på RHEL/CentOS/AlmaLinux

På RHEL-baserede distributioner er auditd som regel allerede installeret. Hvis det mod forventning mangler:

sudo dnf install audit audit-libs
sudo systemctl enable auditd
sudo systemctl start auditd

Bekræft installation og status

# Tjek at auditd kører
sudo systemctl status auditd

# Vis antal aktive regler og kø-status
sudo auditctl -s

# Output eksempel:
# enabled 1
# failure 1
# pid 1234
# rate_limit 0
# backlog_limit 8192
# lost 0
# backlog 0
# backlog_wait_time 60000

Aktivér audit ved opstart (kerneparameter)

For at sikre at alle processer — også dem der starter før auditd-dæmonen — markeres som auditerbare, skal du tilføje kerneparameteren audit=1. Det er en lille ting, men den gør en stor forskel:

# Rediger GRUB-konfigurationen
sudo nano /etc/default/grub

# Tilføj audit=1 til GRUB_CMDLINE_LINUX:
# GRUB_CMDLINE_LINUX="audit=1 audit_backlog_limit=8192"

# Opdater GRUB
sudo update-grub    # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL

Hovedkonfigurationsfil: auditd.conf

Den primære konfigurationsfil er /etc/audit/auditd.conf. Her er de vigtigste parametre, du bør kende:

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

Læg særligt mærke til log_format = ENRICHED. Den indstilling sørger for at inkludere opløste brugernavne og gruppenavne direkte i loggen, og det gør analyse markant lettere i praksis.

Revisionsregler: Filsystem, Systemkald og Kontrol

Regler er hjertet af auditd. De bestemmer præcis, hvad der bliver overvåget. Der findes tre kategorier, og det er værd at forstå dem alle.

1. Kontrolregler

Kontrolregler styrer selve audit-systemets opførsel:

# Sæt backlog-bufferen til 8192 (standard er kun 320)
-b 8192

# Sæt fejltilstand: 0=silent, 1=printk, 2=panic
-f 1

# Gør reglerne uforanderlige efter indlæsning (kræver genstart for ændring)
-e 2

Flaget -e 2 er særligt vigtigt i produktionsmiljøer. Det forhindrer, at en kompromitteret proces kan deaktivere auditing under et angreb. Når det flag er sat, kræves der en fuld genstart for at ændre reglerne.

2. Filvagt-regler (File Watch Rules)

Filvagt-regler overvåger adgang til specifikke filer og mapper. Syntaksen er -w sti -p tilladelser -k nøgle, hvor tilladelserne er:

• r — læseadgang
• w — skriveadgang
• x — udførelsesadgang
• a — attributændring

Her er et solidt sæt filvagt-regler, som de fleste servere bør have:

# /etc/audit/rules.d/30-identity.rules
# Overvåg ændringer i bruger- og gruppeadministration
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# Overvåg SSH-konfiguration
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d -p wa -k sshd_config

# Overvåg PAM-konfiguration
-w /etc/pam.d/ -p wa -k pam_config

# Overvåg sudoers
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Overvåg cron
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

# Overvåg systemd-services
-w /etc/systemd/system/ -p wa -k systemd
-w /usr/lib/systemd/system/ -p wa -k systemd

3. Systemkaldsregler (Syscall Rules)

Systemkaldsregler er de mest avancerede. De opfanger kald direkte til kernen og er utroligt kraftfulde — men har også højere ydelsesomkostninger (mere om det senere). Syntaksen ser sådan ud:

-a action,list -F arch=b64 -S syscall_name -F feltfilter -k nøgle

En vigtig detalje: på 64-bit systemer, der også kan køre 32-bit binærfiler, skal du oprette to regler — én for arch=b64 og én for arch=b32. Det er nemt at glemme, men det kan betyde blinde vinkler i din overvågning.

# /etc/audit/rules.d/40-syscall.rules

# Overvåg al programudførelse (execve)
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

# Privilegieeskalering — setuid/setgid
-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation

# Indlæsning/fjernelse af kernemoduler
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel_modules
-a always,exit -F arch=b32 -S init_module -S finit_module -S delete_module -k kernel_modules

# Tidsmanipulation (vigtig for compliance)
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_change
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S clock_settime -k time_change

# Sletning af filer af ikke-root brugere
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k file_deletion
-a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k file_deletion

# Netværksforbindelser (socket-oprettelse)
-a always,exit -F arch=b64 -S socket -S connect -S accept -k network_connection
-a always,exit -F arch=b32 -S socket -S connect -S accept -k network_connection

Et godt tip: kombiner relaterede systemkald i én regel med flere -S-flag. Kernen evaluerer færre regler, og det giver mærkbart bedre ydelse.

Indlæsning af regler

# Kompiler og indlæs alle regelfiler fra /etc/audit/rules.d/
sudo augenrules --load

# Bekræft at reglerne er aktive
sudo auditctl -l

# VIGTIGT: Brug ALDRIG systemctl restart auditd
# Brug i stedet:
sudo service auditd reload

Den her er vigtig at huske: brug aldrig systemctl restart auditd. Det kan forårsage tab af revisionshændelser. Brug altid service auditd reload i stedet — det genindlæser reglerne uden at stoppe dæmonen.

Compliance-regelværk: PCI DSS, CIS og STIG

En af de ting, jeg synes er mest praktisk ved auditd, er de forudbyggede regelværk til compliance-standarder. Du finder dem typisk under /usr/share/doc/auditd/examples/ eller /usr/share/audit/, og de kan kopieres direkte til /etc/audit/rules.d/.

Tilgængelige regelværk

• CIS Benchmark (cis.rules): Implementerer Center for Internet Security's anbefalinger for Linux-hærdning.
• PCI DSS (30-pci-dss-v31.rules): Dækker krav 10.2.x — overvågning af kortholderdata, privilegerede handlinger og revisionslog-adgang.
• STIG (stig.rules): Defense Information Systems Agency's Security Technical Implementation Guides.
• NISPOM (nispom.rules): National Industrial Security Program Operating Manual-krav.
• OSPP (ospp-v42.rules): Protection Profile for General Purpose Operating Systems.

Eksempel: Aktivering af PCI DSS-regler

# Find de tilgængelige regelværk
find /usr/share -name "*.rules" -path "*/audit/*" 2>/dev/null

# Kopier PCI DSS-regelværket
sudo cp /usr/share/audit/sample-rules/30-pci-dss-v31.rules /etc/audit/rules.d/

# Indlæs reglerne
sudo augenrules --load

# Bekræft antal aktive regler
sudo auditctl -l | wc -l

PCI DSS krav 10.2 — hvad dækkes der?

PCI DSS krav 10.2 kræver overvågning af en række specifikke hændelser. Her er oversigten:

• 10.2.1: Individuel brugeradgang til kortholderdata
• 10.2.2: Handlinger udført af brugere med root/admin-privilegier
• 10.2.3: Adgang til alle revisionsspor
• 10.2.4: Ugyldige loginforsøg
• 10.2.5: Brug af autentificeringsmekanismer
• 10.2.6: Initialisering af revisionslogge
• 10.2.7: Oprettelse og sletning af systemniveauobjekter

Alle disse kan opfyldes direkte med auditd-regler. Det sparer en del hovedpine ved compliance-audits.

Loganalyse med ausearch og aureport

At indsamle data er kun halvdelen af opgaven. Den virkelige værdi ligger i at kunne analysere og finde mønstre. Her kommer ausearch og aureport ind — og de er faktisk ret kraftfulde, når man først har vænnet sig til dem.

ausearch — målrettet søgning

Brug ausearch, når du ved nogenlunde, hvad du leder efter:

# Søg efter alle login-forsøg
sudo ausearch -m USER_LOGIN -i

# Søg efter mislykkede login-forsøg
sudo ausearch -m USER_LOGIN -sv no -i

# Søg efter en specifik brugers aktivitet (UID 1001)
sudo ausearch -ua 1001 -i

# Søg efter ændringer i /etc/passwd
sudo ausearch -f /etc/passwd -i

# Søg efter hændelser med en specifik nøgle
sudo ausearch -k identity -ts today -i

# Søg inden for et tidsinterval
sudo ausearch -k sudoers -ts this-week -i

# Søg efter kernemodul-indlæsning
sudo ausearch -k kernel_modules -ts this-month -i

# Nyttige tidskvalifikatorer:
# -ts now, recent (sidste 10 min), today, yesterday,
#    this-week, this-month, this-year

Flaget -i (interpret) er guld værd. Det oversætter hex-kodede felter, UID'er og systemkaldsnumre til læsbare navne, så du slipper for at sidde og slå ting op manuelt.

aureport — oversigtsrapporter

Når du har brug for et hurtigt overblik i stedet for specifikke hændelser, er aureport dit værktøj:

# Samlet oversigt over alle revisionshændelser
sudo aureport --summary

# Autentificeringsrapport
sudo aureport --auth

# Kun mislykkede autentificeringsforsøg
sudo aureport --auth --failed

# Login-rapport (menneskelæsbar)
sudo aureport --login --failed -i

# Filadgangsrapport
sudo aureport --file --summary

# Anomalidetektionsrapport
sudo aureport --anomaly

# Rapport over kørte kommandoer
sudo aureport --comm --summary

# Rapport over privilegieeskalering (sudo/su)
sudo aureport --auth -i -ts this-week

Kombination af ausearch og aureport til trusseljagt

Den virkelige kraft kommer, når du kombinerer de to. Pipe outputtet fra ausearch direkte ind i aureport:

# Find alle programmer der har tilgået /etc/shadow i dag
sudo ausearch -f /etc/shadow -ts today --raw | aureport --file --summary

# Detaljeret rapport over privilegerede handlinger denne uge
sudo ausearch -k privilege_escalation -ts this-week --raw | aureport --event -i

# Find specifik hændelse og få detaljeret rapport
sudo ausearch -a 12345 --raw | aureport -i

Automatiseret daglig sikkerhedsrapport

Noget jeg kan anbefale er at sætte en daglig rapport op som cron-job. Det tager fem minutter at konfigurere og sparer dig for manuelt arbejde hver dag:

#!/bin/bash
# /usr/local/bin/audit-daily-report.sh

REPORT_DATE=$(date -d "yesterday" +%m/%d/%Y)
REPORT_FILE="/var/log/audit/daily-report-$(date -d yesterday +%Y%m%d).txt"

{
    echo "=== DAGLIG REVISIONSRAPPORT: $REPORT_DATE ==="
    echo ""

    echo "--- Mislykkede login-forsøg ---"
    aureport --login --failed -i -ts "$REPORT_DATE" -te today

    echo ""
    echo "--- Privilegieeskalering ---"
    ausearch -k privilege_escalation -ts "$REPORT_DATE" -te today -i 2>/dev/null || echo "Ingen hændelser"

    echo ""
    echo "--- Ændringer i identitetsfiler ---"
    ausearch -k identity -ts "$REPORT_DATE" -te today -i 2>/dev/null || echo "Ingen hændelser"

    echo ""
    echo "--- Kernemodul-aktivitet ---"
    ausearch -k kernel_modules -ts "$REPORT_DATE" -te today -i 2>/dev/null || echo "Ingen hændelser"

    echo ""
    echo "--- Anomalier ---"
    aureport --anomaly -ts "$REPORT_DATE" -te today

    echo ""
    echo "--- Hændelsesstatistik ---"
    aureport --summary -ts "$REPORT_DATE" -te today
} > "$REPORT_FILE"

echo "Rapport gemt: $REPORT_FILE"

# Gør scriptet kørbart og tilføj det til cron
chmod +x /usr/local/bin/audit-daily-report.sh
echo "0 6 * * * root /usr/local/bin/audit-daily-report.sh" | sudo tee /etc/cron.d/audit-report

Ydelsestuning til produktionsservere

Det her er et område, mange overser. auditd evaluerer hver eneste regel mod hvert relevant systemkald for hver proces på systemet. Uden ordentlig tuning kan det føre til ydelsesforringelse — eller endnu værre, tab af revisionshændelser.

Backlog-buffer

Standardværdien for backlog_limit er 320. Det er alt for lavt til produktionsservere. Når bufferen løber fuld, får du den berømte audit: backlog limit exceeded-fejl.

# Tjek aktuel backlog-status
sudo auditctl -s
# Se efter: backlog (aktuel kø) og lost (tabte hændelser)

# Sæt backlog_limit til 8192 i reglerne
# /etc/audit/rules.d/10-base-config.rules
-b 8192

# Eller permanent via kerneparameter:
# GRUB_CMDLINE_LINUX="audit=1 audit_backlog_limit=8192"

Hvad angår hukommelse: en buffer på 8192 poster bruger cirka 70 MiB RAM, mens 15000 poster kræver omkring 128 MiB. Det er en rimelig pris for pålidelig auditing.

Optimering af regelrækkefølge

Regelrækkefølgen har overraskende stor indvirkning på ydelsen. Kernen evaluerer regler sekventielt, så tænk over rækkefølgen:

• Placér hyppigst matchende regler først — det reducerer antallet af evalueringer.
• Placér undtagelser (exclude-regler) tidligt — så kendte støjkilder filtreres fra med det samme.
• Alfabetisk sortering er IKKE optimalt — sorter efter frekvens og vigtighed i stedet.

# Eksempel: Ekskluder støjende processer tidligt
# /etc/audit/rules.d/01-excludes.rules
-a always,exclude -F msgtype=CWD
-a always,exclude -F msgtype=EOE
-a never,exit -F dir=/var/log/audit -k exclude_audit_logs
-a never,exit -F exe=/usr/sbin/auditd -k exclude_auditd
-a never,exit -F exe=/usr/bin/vmtoolsd -k exclude_vmtools

Backlog wait time

Fra Linux-kerne 3.14 kan du konfigurere backlog_wait_time. Den styrer, hvor længe kernen venter, når backlog-grænsen er nået. En værdi på 0 forhindrer, at audit blokerer systemet:

# Undgå at auditd blokerer systemet
--backlog_wait_time 0

Overvåg tabte hændelser

# Tjek om der tabes hændelser
sudo auditctl -s | grep -E "lost|backlog"

# Eksempel output:
# backlog_limit 8192
# lost 0          <-- skal altid være 0
# backlog 12      <-- aktuel kølængde

Hvis lost er større end 0, har du et problem. Enten skal du øge backlog_limit, eller du skal reducere antallet af regler.

Integration med SIEM og Wazuh

auditd er fantastisk som datakilde, men den virkelige kraft udfoldes, når du kombinerer det med et SIEM-system til realtidsalarmering og korrelation.

auditd + Wazuh

Wazuh kan integreres direkte med auditd via audispd-pluginet. Det giver realtidsovervågning med automatisk alarmering — og opsætningen er faktisk ret ligetil:

# Konfigurer audispd til at sende til Wazuh
# /etc/audit/plugins.d/af_unix.conf (Ubuntu) eller
# /etc/audisp/plugins.d/af_unix.conf (RHEL)

active = yes
direction = out
path = builtin_af_unix
type = builtin
args = 0640 /var/ossec/queue/sockets/audit
format = string

Med denne konfiguration modtager Wazuh alle revisionshændelser i realtid og kan køre sine egne detektionsregler oven på auditd-data.

auditd + Elastic Stack (ELK)

Til Elastic Stack bruger du Filebeat med auditd-modulet:

# /etc/filebeat/modules.d/auditd.yml
- module: auditd
  log:
    enabled: true
    var.paths:
      - /var/log/audit/audit.log*

Alternativt kan du bruge Auditbeat, som er Elastic's dedikerede audit-agent. Den kan faktisk erstatte auditd helt og sende data direkte til Elasticsearch — men det er en afvejning, da du mister den kernenære garanti, som auditd giver.

Centralisering af logge med rsyslog

Mange compliance-krav siger, at logge skal adskilles fra produktionsmiljøet. Her er en rsyslog-konfiguration til det:

# /etc/rsyslog.d/audit-forward.conf
# Videresend audit-logge til central log-server
module(load="imfile")
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="auditd"
      Severity="info"
      Facility="local6")

local6.* @@logserver.example.com:514

Praktisk eksempel: Komplet regelværk til en webserver

Lad os samle det hele. Her er et komplet auditd-regelværk til en produktionswebserver, der kombinerer sikkerhedsovervågning med compliance-krav. Du kan bruge det som udgangspunkt og tilpasse det til din egen infrastruktur:

# /etc/audit/rules.d/10-base-config.rules
# Basisopsætning
-D
-b 8192
-f 1
--backlog_wait_time 0

# /etc/audit/rules.d/20-excludes.rules
# Ekskluder støjende processer
-a always,exclude -F msgtype=CWD
-a never,exit -F exe=/usr/sbin/auditd
-a never,exit -F dir=/proc -k exclude_proc
-a never,exit -F dir=/sys -k exclude_sys

# /etc/audit/rules.d/30-identity.rules
# Bruger- og gruppeadministration
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# /etc/audit/rules.d/40-access.rules
# SSH og autentificering
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/pam.d/ -p wa -k pam_config
-w /var/log/faillog -p wa -k login_events
-w /var/log/lastlog -p wa -k login_events

# /etc/audit/rules.d/50-syscall.rules
# Programudførelse
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec

# Privilegieeskalering
-a always,exit -F arch=b64 -S setuid -S setgid -k priv_esc
-a always,exit -F arch=b32 -S setuid -S setgid -k priv_esc

# Kernemoduler
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel_modules
-a always,exit -F arch=b32 -S init_module -S finit_module -S delete_module -k kernel_modules

# /etc/audit/rules.d/60-webserver.rules
# Webserver-specifikke regler
-w /etc/nginx/ -p wa -k nginx_config
-w /etc/apache2/ -p wa -k apache_config
-w /var/www/ -p wa -k webroot_changes
-w /etc/letsencrypt/ -p wa -k tls_certs

# /etc/audit/rules.d/99-finalize.rules
# Lås reglerne (kræver genstart for ændring)
-e 2

Fejlfinding af almindelige problemer

Problem: "backlog limit exceeded"

# Diagnose
sudo auditctl -s
# Tjek backlog og lost værdier

# Løsning: Øg backlog_limit
sudo auditctl -b 16384

# Permanent: Tilføj til /etc/audit/rules.d/10-base-config.rules
-b 16384

Problem: auditd genererer for mange hændelser

# Find de mest støjende regler
sudo aureport --key --summary | head -20

# Identificer og ekskluder støjende processer
# Tilføj exclude-regler i 20-excludes.rules

Problem: Regler indlæses ikke

# Tjek for syntaksfejl
sudo augenrules --check

# Indlæs med verbose output
sudo augenrules --load
sudo auditctl -l

Ofte stillede spørgsmål

Hvad er forskellen mellem auditd og journald?

journald (systemd's logningssystem) indsamler logge fra services, kernen og brugerrum på applikationsniveau. auditd opererer dybere — direkte i kernen — og opfanger systemkald og filadgang, før brugerrumsprocesser kan manipulere dem. For compliance og sikkerhedsrevision er auditd det rigtige valg, fordi det giver uomgængelig, kernenær overvågning. De to systemer komplementerer hinanden, og du bør bruge begge.

Påvirker auditd serverens ydelse markant?

Det afhænger af dine regler. Filvagt-regler har minimal overhead, mens systemkaldsregler evalueres for hvert relevant systemkald på systemet. Med korrekt tuning — optimeret regelrækkefølge, exclude-regler for støjende processer og en passende backlog_limit — er ydelsespåvirkningen typisk under 5% på de fleste produktionsservere. Men test det selv: kør en benchmark før og efter regelindlæsning, så du kender den faktiske påvirkning i dit miljø.

Kan auditd erstatte Wazuh eller et SIEM-system?

Kort sagt: nej. auditd er en datakilde, ikke et fuldt SIEM. Det indsamler og lagrer revisionshændelser, men det har hverken alarmering, korrelation, dashboards eller automatiseret trusseldetektion. Værktøjer som Wazuh, Elastic Security og Splunk bruger auditd-data som input og tilføjer realtidsanalyse, regelbaseret alarmering og central logadministration. Tænk på auditd som fundamentet — dit SIEM er bygningen ovenpå.

Hvordan sikrer jeg, at audit-logge ikke kan manipuleres?

Der er flere strategier, du kan kombinere: (1) Brug -e 2 i dine regler for at gøre audit-konfigurationen uforanderlig — ændringer kræver genstart. (2) Send logge til en ekstern log-server via rsyslog eller audispd i realtid. Selv hvis en angriber kompromitterer serveren, er loggene allerede kopieret. (3) Brug separate filsystemrettigheder på /var/log/audit/, så kun root og audit-gruppen har adgang. (4) Overvej immutable-lagring til de videresendte logge.

Hvilke audit-regler er vigtigst at starte med?

Start med det, der giver mest værdi med mindst støj: (1) Identitetsfiler (/etc/passwd, /etc/shadow, /etc/group), (2) privilegieeskalering (/etc/sudoers, setuid/setgid-systemkald), (3) SSH-konfiguration, (4) kernemodul-indlæsning og (5) autentificeringshændelser. Disse dækker de mest kritiske angrebsvektorer og er krav i de fleste compliance-standarder. Udvid derfra baseret på dit specifikke trussellandskab og behov.