auditd svarer på spørgsmål, der først opstår bagefter: hvem ændrede denne fil, hvornår blev denne bruger oprettet, hvorfra blev denne proces startet. Ingen andre værktøjer svarer på dem — i applikationslogfilerne findes de oplysninger ikke, og kommandohistorikken redigeres af den, der efterlod den.

Vanskeligheden er, at det at installere pakken alene ikke giver noget. Standardregler findes praktisk talt ikke, logfilen skrives, men er tom af indhold, og det opdages i værst tænkelige øjeblik: når oplysningerne er nødvendige og ikke findes.

Installation

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

En særhed: i nogle versioner genstartes auditd ikke med systemctl restart — tjenesten styres af en egen kommando. Reglerne indlæses på ny sådan:

sudo augenrules --load
sudo auditctl -l

Den anden kommando viser, hvad der rent faktisk er indlæst. Det er den, man skal stole på, ikke indholdet af filerne.

Regelsættet

Regler lægges i /etc/audit/rules.d/ som en separat fil. Nedenfor følger et minimalt sæt, der betaler sig: det svarer på de fleste spørgsmål ved en hændelse og fylder ikke disken.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Brugere og rettigheder
-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 privileges
-w /etc/sudoers.d/ -p wa -k privileges

## SSH-adgang
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Planlagte job
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Kernemoduler
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## Brug af sudo og su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

Syntaksen er kort: -w er stien, der overvåges, -p wa betyder reaktion på skrivning og attributændring, -p x på kørsel, og -k er nøglen, du senere søger på. Netop nøglerne er den store bekvemmelighed: uden dem bliver søgningen i logfilen en gennemgang af en gigabyte tekst.

Hvad der ikke findes i sættet og hvorfor

Vejledninger foreslår ofte at registrere alle execve-kald — altså hver start af hvert program. Fristelsen er forståelig: et fuldstændigt billede af alle handlinger. I praksis giver det på en driftsserver hundredvis af megabyte i døgnet, æder en mærkbar del af processoren og fører til, at logfilen må beskæres, før den er nødvendig. Kræves det detaljeniveau, slå det til punktvis — for én bruger eller under en undersøgelse.

Det samme gælder at overvåge hjemmesidens mappe: dertil skrives der uafbrudt, og reglen gør logfilen til en strøm af meningsløse hændelser.

Læsning

Søgning på nøgle, med numeriske id'er oversat til navne:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

Flaget -i er nødvendigt for læsbarheden: uden det ser du tal i stedet for brugernavne og systemkald. -ts begrænser perioden (today, recent eller en bestemt dato).

Opsummering for en periode:

sudo aureport --summary -i
sudo aureport --auth -i --failed

I en hændelsespost er tre felter interessante: auid — id'et på den bruger, der startede sessionen, uid — den identitet, handlingen blev udført under, og exe — programmet, der udførte den. Forskellen mellem auid og uid er svaret på spørgsmålet »hvem blev egentlig root«: uid=0 med en bestemt persons auid udpeger entydigt den ansvarlige, uanset hvem vedkommende udgav sig for at være under sessionen.

Disken

Størrelsesindstillingerne findes i /etc/audit/auditd.conf:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Se særligt på disk_full_action. I nogle opsætninger er standardværdien at standse systemet, når disken er fuld — en adfærd, der er rimelig på maskiner med revisionskrav og helt malplaceret på en webserver. Den værdi skal kontrolleres, før disken fyldes.

Tilstanden med uforanderlige regler

Linjen -e 2 sidst i regelfilen forbyder ændringer af reglerne indtil genstart — også for den, der har skaffet sig root. Det hæver logfilens værdi mærkbart: en angriber kan ikke slå overvågningen fra uden at genstarte maskinen, og en genstart er i sig selv mærkbar.

Bagsiden er indlysende: du kan heller ikke ændre dine egne regler uden genstart. Det er værd at slå til, når sættet har stabiliseret sig, og du har levet med det i en måned.

Hvorfor dette på en almindelig server

auditd forebygger intet. Dets værdi viser sig præcis én gang — når hændelsesforløbet skal rekonstrueres, og oplysningerne enten findes eller ikke findes. De kan ikke indsamles bagudrettet, og derfor opretter man regelsættet på forhånd og lader det siden være.

Et praktisk tegn på, at sættet er rigtigt: regellisten er ikke tom, logfilen vokser ikke ukontrolleret, og hændelser med nøglerne identity og privileges dukker sjældent op og kan alle forklares. Hvordan det ser ud på én side, viser demonstrationen nedenfor.