Il pannello non modifica la configurazione di Falco — mostra solo lo snippet e i comandi che Lei applica sul server via SSH.
# /etc/falco/rules.d/local-tuning.yaml - rule: <NOME ESATTO DELLA REGOLA dall'elenco sopra> condition: and not fd.name = /path/to/exclude append: true
sudo nano /etc/falco/rules.d/local-tuning.yaml sudo falco --validate /etc/falco/rules.d/local-tuning.yaml sudo systemctl restart falco 2>/dev/null || sudo systemctl restart falco-modern-bpf
Usi il nome esatto della regola. Se nell'elenco è mostrato il testo del messaggio anziché il nome, abiliti l'output JSON in falco.yaml (json_output: true): così il pannello riceverà i nomi esatti delle regole.
Falco viene di solito presentato come uno strumento per Kubernetes, e quasi tutto ciò che se ne scrive presuppone un cluster. Funziona benissimo anche su un comune server Linux, dove osserva le chiamate di sistema e solleva un alert quando un processo fa qualcosa che non gli compete: aprire una shell dal server web, scrivere in una directory di binari di sistema, leggere file sensibili, aprire una connessione in uscita inattesa.
Questa pagina mostra gli alert con la loro priorità, la regola scattata e il processo con la riga di comando che c’è dietro. È proprio quest’ultimo dettaglio a distinguere Falco dagli strumenti basati sui log: riferisce che cosa un processo ha davvero fatto, non ciò che un servizio ha scelto di scriverne.
Il set di regole predefinito è scritto pensando ai container e sarà rumoroso su un server nudo finché non lo si mette a punto. Gestori di pacchetti, job di backup e script di cron fanno scattare regolarmente regole pensate per intercettare intrusi. Mettete in conto un’ora o due per silenziare comportamenti legittimi prima che l’output diventi utilizzabile: un flusso di alert che nessuno legge equivale a nessun alert.