Il controllo di integrità risponde a una domanda a cui né un antivirus né un firewall rispondono: che cosa è cambiato su questo server dalla settimana scorsa? Un analizzatore basato su firme cerca il dannoso noto; AIDE non sa nulla di dannosità, sa che questo file ieri era diverso. Per individuare una porta di servizio aggiunta a un file esistente, è l’unico approccio che funziona.

AIDE si installa con due comandi. Configurarlo perché i suoi rapporti vengano letti è la parte difficile, ed è proprio ciò che di solito lo uccide: il primo rapporto arriva con diecimila righe, il secondo non lo apre nessuno, e un mese dopo il lavoro viene cancellato.

Installazione e prima base

sudo apt install aide aide-common
sudo aideinit

L’inizializzazione richiede da pochi minuti a mezz’ora: si calcolano le impronte di tutti i file. Il risultato viene messo accanto alla base di lavoro con il suffisso .new e va messo in servizio:

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Da lì in poi una verifica si lancia così:

sudo aide --check

Che cosa escludere perché il rapporto resti leggibile

Le impostazioni stanno in /etc/aide/aide.conf e nella cartella /etc/aide/aide.conf.d/. La configurazione Debian fornita controlla troppo, e la prima cosa da fare è togliere ciò che cambia da solo di continuo:

  • /var/log: cambia ogni secondo;
  • /var/lib per intero: database, stato dei pacchetti, stato dei servizi;
  • /var/cache, /tmp, /proc, /sys, /run;
  • le cartelle di caricamento e cache del sito: il loro contenuto lo cambiano i visitatori.

Ciò che invece vale la pena controllare con le impostazioni più severe è un elenco ristretto:

  • /bin, /sbin, /usr/bin, /usr/sbin: gli eseguibili di sistema;
  • /lib, /usr/lib: le librerie;
  • /etc: la configurazione;
  • /root/.ssh e le cartelle .ssh dei suoi utenti;
  • il codice del sito, ma senza le cartelle di caricamento e cache.

Il riferimento: un rapporto quotidiano ordinario deve stare in una schermata. Se è più lungo, le esclusioni sono insufficienti e smetterà di essere letto.

Dove tenere la base

Un punto essenziale che spesso sfugge. Se qualcun altro ha root, sostituire un file e aggiornare subito la base di AIDE non gli costa nulla, e la verifica successiva segnalerà che va tutto bene. Una base che sta sulla stessa macchina e con permesso di scrittura protegge solo dagli incidenti.

Un minimo ragionevole per un server unico:

  • copiare la base su un’altra macchina dopo ogni aggiornamento ed eseguire la verifica rimettendo al suo posto quella copia;
  • o almeno conservare a parte la somma di controllo della base e confrontarla prima della verifica:
sha256sum /var/lib/aide/aide.db

Anche una misura tanto semplice trasforma una sostituzione silenziosa in un evento visibile.

Aggiornare la base è un atto deliberato

Dopo modifiche legittime — un aggiornamento del sistema, una nuova versione del sito — la base si ricostruisce:

sudo aide --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Il momento conta. Corretto: leggere il rapporto, accertarsi che ogni modifica si spieghi, e solo allora aggiornare. Sbagliato e molto diffuso: lanciare aide --update a orario perché i rapporti risultino puliti. Nel secondo caso il sistema gira, i rapporti arrivano, e le modifiche vengono registrate come normali proprio nel momento in cui si verificano: il senso, quindi, è del tutto perduto.

Programmazione e carico

Il pacchetto aide-common installa da sé un lavoro quotidiano. La verifica carica disco e processore per alcuni minuti, quindi conviene eseguirla in un’ora tranquilla e con priorità abbassata:

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

Come leggere il rapporto

Tre sezioni: file aggiunti, rimossi e modificati. Per ogni modifica indica che cosa differisce esattamente: contenuto, permessi, proprietario, data.

A che cosa reagire per primo:

  • una modifica di qualsiasi file in /bin, /sbin, /usr/bin fuori da una finestra di aggiornamento;
  • file nuovi nelle cartelle di sistema;
  • modifiche a authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab e /etc/cron.d;
  • la comparsa di un file /etc/ld.so.preload: non compare mai da solo.

Cento file modificati subito dopo apt upgrade è normale, e l’ora del rapporto lo conferma. Tre file modificati in /usr/bin un mercoledì senza aggiornamenti è un motivo per fermarsi e guardare.

AIDE e debsums

Gli strumenti risolvono problemi vicini, ma il loro riferimento differisce. AIDE confronta con uno snapshot proprio, quindi vede modifiche in qualsiasi file, codice del sito compreso. debsums confronta con le somme di controllo dei pacchetti della distribuzione, quindi vede i file di sistema sostituiti senza alcuna preparazione, ma non sa nulla di ciò che lei ha installato fuori dai pacchetti. Tenerli entrambi è ragionevole; in pratica debsums viene di solito per primo, perché non richiede né configurazione né base.

Condividono anche una debolezza: il rapporto arriva per posta, e la posta si perde. Ciò che conta, quindi, non è che la verifica sia stata eseguita, ma che esista un luogo dove il suo ultimo risultato sia visibile. Come appare lo mostra la pagina dimostrativa qui sotto.