Falco è noto come strumento per Kubernetes, e quasi tutte le guide che lo riguardano sono scritte per i cluster. Eppure non è legato ai cluster: sorveglia le chiamate di sistema, e su un server ordinario con un sito funziona esattamente allo stesso modo. Semplicemente, di quel caso non scrive quasi nessuno.

È utile là dove gli altri strumenti tacciono. Una web shell su un sito non viola alcun permesso, non produce accessi falliti e non corrisponde ad alcuna firma se è stata scritta a mano. Ma mostra un comportamento anomalo per un server web: il processo PHP-FPM avvia un interprete di comandi. È questo che Falco vede.

Che cosa nota

Eventi tipici su un server ordinario:

  • un interprete generato dal processo del server web o di PHP: segno praticamente inequivocabile di una web shell;
  • un programma avviato da /tmp, /dev/shm o /var/tmp;
  • file sensibili (/etc/shadow, chiavi private) letti da un processo che non c’entra nulla;
  • modifica di binari di sistema;
  • una connessione in uscita da un processo che non dovrebbe usare la rete.

Installazione

La scelta decisiva si fa all’installazione: come Falco ottiene le chiamate di sistema. La variante moderna si basa su eBPF e non richiede né la compilazione di un modulo del kernel né le intestazioni del kernel:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

Il modulo classico del kernel richiede le intestazioni e si ricompila dopo ogni aggiornamento del kernel: su un server dove gli aggiornamenti si installano da soli, è una fonte ricorrente di servizio morto. Se il kernel è abbastanza recente (5.8 e oltre), scelga eBPF e dimentichi il problema.

Per verificare che gli eventi arrivino davvero:

sudo systemctl status falco
sudo journalctl -u falco -n 50

Il rumore e come eliminarlo

È questo il lavoro vero. L’insieme di regole fornito punta ad ambienti con container, e su un server ordinario una parte considerevole o non è applicabile o scatta di continuo.

Le regole fornite (/etc/falco/falco_rules.yaml) non si modificano: il file viene sostituito all’aggiornamento. Le sue modifiche vanno in /etc/falco/falco_rules.local.yaml, e lì stesso si disattivano le regole superflue:

- rule: Terminal shell in container
  enabled: false

Che cosa di solito va sistemato su un server senza container:

  • tutte le regole sui container: senza container occupano solo spazio nel rapporto;
  • «Write below etc»: scatta a ogni installazione di pacchetto e a ogni sua modifica a un file di configurazione. Serve un’eccezione per apt, dpkg e unattended-upgrades, altrimenti gli eventi arrivano a fiumi;
  • «Read sensitive file untrusted»: scatta con agenti di monitoraggio, strumenti di backup e strumenti di audit come Lynis;
  • gli avvii da cartelle temporanee: eccezioni legittime esistono, come la compilazione di un’applicazione o un browser automatizzato che estrae un driver in una cartella temporanea. Quegli eventi sembrano inquietanti ma si spiegano, e conviene creare subito l’eccezione per il percorso preciso invece di ripensarci ogni volta.

L’ordine ragionevole è lo stesso di qualsiasi altro strumento di rilevamento: la prima settimana solo osservare e creare eccezioni, e solo dopo trattare un evento comparso come un segnale. La regola è semplice: se il rapporto contiene con regolarità eventi che lei non legge, non le serve a nulla.

Dove inviare gli eventi

L’uscita si configura in /etc/falco/falco.yaml: un file, il journal di sistema o il passaggio a un programma esterno. Per un server unico basta un file con rotazione successiva; non dimentichi la rotazione, il file degli eventi cresce come qualsiasi registro e di default non lo sorveglia nessuno.

Le priorità vanno usate per separare: gli eventi critici dove li vedrà subito, il resto nel journal generale da esaminare più tardi.

Falco e auditd non sono la stessa cosa

Entrambi sorvegliano le chiamate di sistema, ma con scopi diversi. auditd registra ciò che accade perché il quadro si possa ricostruire più tardi: non valuta nulla e non segnala nulla, tiene un journal. Falco applica regole nel momento dell’evento e dice «questo sembra sospetto»: dà un segnale invece di un record.

Tenerli entrambi è ragionevole: il journal per la ricostruzione, i segnali per la reazione. Se bisogna sceglierne uno, auditd è più utile su un server dove conta soprattutto ricostruire la sequenza degli eventi dopo un incidente; Falco là dove si vuole un segnale precoce su un miner in funzione o su una web shell.

Vale lo spazio su un server piccolo

La risposta onesta: non sempre. Falco elabora le chiamate di sistema e si fa sentire sul processore di una macchina carica. Se il server ospita un sito e non ha ancora né controllo di integrità né aggiornamenti automatici decenti, non è da lì che bisogna cominciare.

Il suo momento arriva più tardi, quando le basi sono a posto e resta la domanda su che cosa accada sul server che i registri non mostrano. Copre una classe di eventi meglio di tutte le altre messe insieme: un interprete avviato dal processo del server web. Come appaiono gli eventi suddivisi per priorità e per regola lo mostra la pagina dimostrativa qui sotto.