auditd risponde alle domande che sorgono solo dopo il fatto: chi ha modificato questo file, quando è stato creato questo utente, da dove è stato avviato questo processo. Nessun altro strumento vi risponde: nei registri delle applicazioni quelle informazioni non ci sono, e la cronologia dei comandi la modifica chi l’ha lasciata.
La difficoltà è che installare il pacchetto, di per sé, non porta nulla. Regole predefinite praticamente non ce ne sono, il journal viene scritto ma è vuoto nella sostanza, e lo si scopre nel momento peggiore: quando i dati servono e non ci sono.
Installazione
sudo apt install auditd audispd-plugins
sudo systemctl status auditd
Una particolarità: su alcune versioni auditd non si riavvia con systemctl restart, il servizio si governa con un comando proprio. Le regole si rileggono così:
sudo augenrules --load
sudo auditctl -l
Il secondo comando mostra ciò che è realmente caricato. Creda a lui, non al contenuto dei file.
L’insieme di regole
Le regole si mettono in /etc/audit/rules.d/ come file a parte. Ecco un insieme minimo che si ripaga: risponde alla maggior parte delle domande di un incidente senza saturare il disco.
sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Utenti e privilegi
-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
## Accesso SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys
## Attività pianificate
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
## Moduli del kernel
-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
## Uso di sudo e su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load
La sintassi è breve: -w è un percorso da sorvegliare, -p wa significa reagire a scritture e cambi di attributi, -p x all’esecuzione, -k è la chiave con cui si cercherà poi. Quelle chiavi sono la comodità principale: senza di esse cercare nel journal diventa scorrere un gigabyte di testo.
Che cosa non c’è in quell’elenco e perché
Le guide propongono spesso di registrare tutte le chiamate execve, cioè ogni avvio di ogni programma. La tentazione si capisce: un quadro completo delle azioni. In pratica, su un server in produzione ciò produce centinaia di megabyte al giorno, consuma una quota apprezzabile del processore e porta a troncare il journal prima che serva. Se quel livello di dettaglio è necessario, lo attivi in modo mirato: per un utente, o per la durata di un’indagine.
Lo stesso vale per la sorveglianza della cartella del sito: lì si scrive di continuo, e la regola trasforma il journal in un fiume di eventi privi di senso.
La lettura
Ricerca per chiave, con gli identificatori numerici risolti in nomi:
sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today
L’opzione -i è indispensabile per la leggibilità: senza di essa otterrà numeri invece dei nomi di utenti e di chiamate di sistema. -ts limita il periodo (today, recent o una data precisa).
Un riepilogo per periodo:
sudo aureport --summary -i
sudo aureport --auth -i --failed
In un record di evento interessano tre campi: auid, l’identificatore dell’utente che ha aperto la sessione, uid, l’identità con cui l’azione è avvenuta, e exe, il programma che l’ha eseguita. La differenza fra auid e uid è la risposta a «chi esattamente è diventato root»: uid=0 con l’auid di una persona precisa indica il responsabile senza ambiguità, quale che sia l’identità che ha assunto dentro la sessione.
Il disco
Le impostazioni di volume stanno in /etc/audit/auditd.conf:
max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG
Guardi a parte disk_full_action. Alcune configurazioni prevedono di default l’arresto del sistema quando il disco si riempie: comportamento giustificato su macchine con obblighi di audit e del tutto fuori luogo su un server web. Verifichi quel valore prima che il disco si riempia.
La modalità a regole immutabili
La riga -e 2 alla fine del file delle regole vieta di modificarle fino al riavvio, anche a chi ha ottenuto root. Questo accresce nettamente il valore del journal: un intruso non può disattivare la sorveglianza senza riavviare la macchina, e un riavvio si nota da sé.
Il rovescio è evidente: nemmeno lei potrà cambiare le proprie regole senza riavviare. Lo attivi quando l’insieme si è assestato e ci ha convissuto un mese.
Perché su un server ordinario
auditd non impedisce nulla. Il suo valore si manifesta esattamente una volta: quando bisogna ricostruire la sequenza degli eventi, e i dati ci sono oppure no. Non si raccolgono a posteriori, per questo l’insieme di regole si predispone in anticipo e poi si lascia in pace.
Un segno pratico che la configurazione è giusta: l’elenco delle regole non è vuoto, il journal non cresce senza controllo, e gli eventi con le chiavi identity e privileges compaiono di rado e ciascuno si può spiegare. Come appare su una pagina lo mostra la dimostrazione qui sotto.