auditd svarar på frågor som uppstår först efteråt: vem ändrade den här filen, när skapades den här användaren, varifrån startades den här processen. Inget annat verktyg svarar på dem — i applikationsloggarna finns inte de uppgifterna, och kommandohistoriken redigeras av den som lämnade den.

Svårigheten är att enbart installera paketet ger ingenting. Standardregler finns praktiskt taget inte, loggen skrivs men är tom till innehållet, och det upptäcks i värsta tänkbara ögonblick: när uppgifterna behövs och inte finns.

Installation

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

En egenhet: i vissa versioner startas auditd inte om med systemctl restart — tjänsten styrs av ett eget kommando. Reglerna läses in på nytt så här:

sudo augenrules --load
sudo auditctl -l

Det andra kommandot visar vad som faktiskt är inläst. Det ska man tro på, inte på filernas innehåll.

Regeluppsättningen

Regler läggs i /etc/audit/rules.d/ som en egen fil. Nedan följer en minimal uppsättning som lönar sig: den svarar på de flesta frågor vid en incident och fyller inte disken.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Användare och rättigheter
-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-åtkomst
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Schemalagda jobb
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Kärnmoduler
-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

## Användning av sudo och su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

Syntaxen är kort: -w är sökvägen som bevakas, -p wa betyder reaktion på skrivning och attributändring, -p x på körning, och -k är nyckeln du senare söker på. Just nycklarna är den stora bekvämligheten: utan dem blir sökandet i loggen en genomgång av en gigabyte text.

Vad som inte finns i uppsättningen och varför

Guider föreslår ofta att man registrerar alla execve-anrop — alltså varje start av varje program. Frestelsen är förståelig: en fullständig bild av alla handlingar. I praktiken ger det på en produktionsserver hundratals megabyte per dygn, äter en märkbar del av processorn och leder till att loggen måste beskäras innan den behövs. Krävs den detaljnivån, slå på den punktvis — för en användare eller under en utredning.

Detsamma gäller att bevaka sajtens katalog: dit skrivs det oavbrutet, och regeln förvandlar loggen till en ström av meningslösa händelser.

Läsning

Sökning på nyckel, med numeriska id översatta till namn:

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

Flaggan -i är nödvändig för läsbarheten: utan den ser du siffror i stället för användarnamn och systemanrop. -ts begränsar perioden (today, recent eller ett bestämt datum).

Sammanställning för en period:

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

I en händelsepost är tre fält intressanta: auid — id för den användare som startade sessionen, uid — identiteten handlingen utfördes under, och exe — programmet som utförde den. Skillnaden mellan auid och uid är svaret på frågan ”vem blev egentligen root”: uid=0 med en bestämd persons auid pekar entydigt ut den ansvariga, oavsett vem den utgav sig för att vara under sessionen.

Disken

Storleksinställningarna finns i /etc/audit/auditd.conf:

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

Titta särskilt på disk_full_action. I vissa uppsättningar är standardvärdet att stanna systemet när disken är full — ett beteende som är rimligt på maskiner med granskningskrav och helt malplacerat på en webbserver. Det värdet behöver kontrolleras innan disken fylls.

Läget med oföränderliga regler

Raden -e 2 sist i regelfilen förbjuder ändringar av reglerna fram till omstart — även för den som skaffat sig root. Det höjer loggens värde märkbart: en angripare kan inte stänga av bevakningen utan att starta om maskinen, och en omstart är i sig märkbar.

Baksidan är uppenbar: du kan inte heller ändra dina egna regler utan omstart. Det är värt att slå på när uppsättningen stabiliserats och du levt med den i en månad.

Varför detta på en vanlig server

auditd förebygger ingenting. Dess värde visar sig exakt en gång — när händelseförloppet ska rekonstrueras och uppgifterna antingen finns eller inte finns. De går inte att samla in i efterhand, och därför lägger man upp regeluppsättningen i förväg och låter den sedan vara.

Ett praktiskt tecken på att uppsättningen är riktig: regellistan är inte tom, loggen växer inte okontrollerat, och händelser med nycklarna identity och privileges dyker upp sällan och går alla att förklara. Hur det ser ut på en sida visar demonstrationen nedan.