auditd svarer på spørsmål som først oppstår i etterkant: hvem endret denne filen, når ble denne brukeren opprettet, hvorfra ble denne prosessen startet. Ingen andre verktøy svarer på dem — i applikasjonsloggene finnes ikke de opplysningene, og kommandohistorikken redigeres av den som etterlot den.

Vanskeligheten er at det å installere pakken alene ikke gir noe. Standardregler finnes praktisk talt ikke, loggen skrives men er tom av innhold, og det oppdages i verst tenkelige øyeblikk: når opplysningene trengs og ikke finnes.

Installasjon

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

En egenhet: i enkelte versjoner startes ikke auditd på nytt med systemctl restart — tjenesten styres av en egen kommando. Reglene lastes inn på nytt slik:

sudo augenrules --load
sudo auditctl -l

Den andre kommandoen viser hva som faktisk er lastet inn. Det er den man skal stole på, ikke innholdet i filene.

Regelsettet

Regler legges i /etc/audit/rules.d/ som en egen fil. Nedenfor følger et minimalt sett som lønner seg: det svarer på de fleste spørsmål ved en hendelse og fyller ikke disken.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Brukere og rettigheter
-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-tilgang
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

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

## Kjernemoduler
-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

## Bruk av 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 som overvåkes, -p wa betyr reaksjon på skriving og attributtendring, -p x på kjøring, og -k er nøkkelen du senere søker på. Nettopp nøklene er den store bekvemmeligheten: uten dem blir søket i loggen en gjennomgang av en gigabyte tekst.

Hva som ikke finnes i settet og hvorfor

Veiledninger foreslår ofte å registrere alle execve-kall — altså hver oppstart av hvert program. Fristelsen er forståelig: et fullstendig bilde av alle handlinger. I praksis gir det på en driftsserver hundrevis av megabyte i døgnet, spiser en merkbar del av prosessoren og fører til at loggen må beskjæres før den trengs. Kreves det detaljnivået, slå det på punktvis — for én bruker eller under en undersøkelse.

Det samme gjelder å overvåke nettstedets katalog: dit skrives det uavbrutt, og regelen gjør loggen til en strøm av meningsløse hendelser.

Lesing

Søk på nøkkel, med numeriske id-er oversatt til navn:

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

Flagget -i er nødvendig for lesbarheten: uten det ser du tall i stedet for brukernavn og systemkall. -ts begrenser perioden (today, recent eller en bestemt dato).

Sammenstilling for en periode:

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

I en hendelsesoppføring er tre felt interessante: auid — id-en til brukeren som startet økten, uid — identiteten handlingen ble utført under, og exe — programmet som utførte den. Forskjellen mellom auid og uid er svaret på spørsmålet «hvem ble egentlig root»: uid=0 med en bestemt persons auid peker entydig ut den ansvarlige, uansett hvem vedkommende utga seg for å være under økten.

Disken

Størrelsesinnstillingene finnes 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ærlig på disk_full_action. I enkelte oppsett er standardverdien å stanse systemet når disken er full — en oppførsel som er rimelig på maskiner med revisjonskrav og helt malplassert på en webserver. Den verdien må kontrolleres før disken fylles.

Modusen med uforanderlige regler

Linjen -e 2 sist i regelfilen forbyr endringer av reglene fram til omstart — også for den som har skaffet seg root. Det hever loggens verdi merkbart: en angriper kan ikke slå av overvåkingen uten å starte maskinen på nytt, og en omstart er i seg selv merkbar.

Baksiden er åpenbar: du kan heller ikke endre dine egne regler uten omstart. Det er verdt å slå på når settet har stabilisert seg og du har levd med det i en måned.

Hvorfor dette på en vanlig server

auditd forebygger ingenting. Verdien viser seg nøyaktig én gang — når hendelsesforløpet skal rekonstrueres og opplysningene enten finnes eller ikke finnes. De lar seg ikke samle inn i etterkant, og derfor legger man opp regelsettet på forhånd og lar det siden være.

Et praktisk tegn på at settet er riktig: regellisten er ikke tom, loggen vokser ikke ukontrollert, og hendelser med nøklene identity og privileges dukker opp sjelden og lar seg alle forklare. Hvordan det ser ut på én side, viser demonstrasjonen nedenfor.