Il controllo di integrità ha una proprietà scomoda: gli serve un riferimento preso da un sistema sicuramente pulito. Se il server gira da tre anni e la domanda su un’intrusione sorge solo oggi, per quel riferimento è già tardi: registrerebbe come normale ciò che c’è.

Su Debian e Ubuntu, però, il riferimento esiste già, e non è il suo: ogni pacchetto installato porta con sé le somme di controllo dei propri file. Il confronto non richiede né configurazione né snapshot preventivo e funziona su qualsiasi sistema in qualsiasi momento. Lo strumento si chiama debsums.

Uso

sudo apt install debsums
sudo debsums -c

L’opzione -c stampa solo i file che non corrispondono al riferimento. Senza di essa l’output è un rapporto riga per riga su ogni file del sistema, decine di migliaia di righe.

La verifica richiede alcuni minuti e carica il disco, quindi su un server in produzione conviene eseguirla con priorità abbassata:

sudo ionice -c3 nice -n19 debsums -c

Come leggere il risultato

Un output vuoto significa che tutti i file verificati corrispondono a ciò che ha installato la distribuzione. Un output non vuoto richiede analisi, e i ritrovamenti si dividono in due classi molto diverse.

File di configurazione sotto /etc. Modificarli è lavoro normale: ha modificato sshd_config, configurato nginx, aggiunto parametri del kernel. Quelle differenze sono attese. Perché non diano fastidio esiste una modalità a parte:

sudo debsums -e -c

-e verifica soltanto i file di configurazione: a volte utile per vedere l’elenco di tutto ciò che ha cambiato su questa macchina.

Eseguibili e librerie. Una differenza in /usr/bin, /usr/sbin, /bin o /usr/lib è proprio ciò per cui la verifica è stata lanciata. Cause legittime ce ne sono, ma poche: il file è stato modificato a mano durante un debug, è stata applicata una patch di terzi, il pacchetto era in aggiornamento durante la verifica. Se nulla di ciò calza, occorre indagare sul serio.

I bersagli classici di una sostituzione sono ls, ps, netstat, ss, find, sshd. Una versione sostituita nasconde nel proprio output le righe che contano, e tutte le sue verifiche successive smettono di dire la verità.

La copertura è incompleta, e va saputo

Un limite di cui di solito non si parla: non tutti i pacchetti forniscono somme di controllo. I file di quei pacchetti non vengono verificati affatto e non compariranno nel rapporto in nessuna circostanza. L’elenco si consulta così:

sudo debsums -l

Un rapporto pulito di debsums significa quindi «nella parte verificata va tutto bene» e non «il sistema non è stato modificato». Lo stesso vale per tutto ciò che è stato installato al di fuori del gestore di pacchetti: compilato dai sorgenti, scaricato come binario, messo da uno script del sito dello sviluppatore; di ciò debsums non sorveglia nulla per definizione, ed è proprio lì che serve AIDE.

Esecuzione periodica

Il pacchetto fornisce un lavoro già pronto, attivato in /etc/default/debsums:

CRON_CHECK=weekly

Una volta a settimana è una frequenza ragionevole: la verifica carica sensibilmente il disco e i file di sistema cambiano di rado fra un aggiornamento e l’altro. Eseguirla ogni giorno non aggiunge nulla oltre al carico.

Se un file è stato davvero sostituito

Il primo impulso è reinstallare il pacchetto e recuperare l’originale:

sudo apt install --reinstall coreutils

Il comando è giusto, ma non come prima mossa. Un binario di sistema sostituito significa che qualcuno ha avuto root, e ripristinare il file non risolve quel problema: distrugge soltanto le tracce. L’ordine dev’essere inverso: prima conservare una copia del file sospetto e la sua ora di modifica, guardare che cos’altro è cambiato nello stesso periodo, controllare i lavori di cron, le chiavi SSH e l’elenco degli utenti. Ripristinare solo dopo.

Ricordi anche i limiti del metodo: se il sistema è profondamente compromesso, debsums stesso e le librerie che usa possono essere stati sostituiti anch’essi. Una verifica dall’interno non può dare garanzie assolute: quello si fa avviando da un supporto esterno. Per il lavoro quotidiano, però, basta: la stragrande maggioranza degli attacchi è automatizzata e non ha quella raffinatezza.

Il suo posto nel quadro d’insieme

debsums è pregevole perché non richiede nulla e funziona subito, il che ne fa un punto di partenza comodo per un server di cui non conosce la storia. La sua debolezza è la copertura incompleta e l’ignoranza di tutto ciò che è installato fuori dai pacchetti. La coppia «debsums più AIDE» chiude entrambi i lati: il riferimento già pronto della distribuzione per i file di sistema e il suo snapshot per il resto.

Come sempre, la questione non è eseguirlo, ma avere davanti l’ultimo risultato con la sua data. Come appare lo mostra la dimostrazione qui sotto.