Come verifica i log per incitidente di Fail2Ban

Come verificare i log per un incidente di Fail2Ban

Quando Fail2Ban entra in gioco durante un incidente, la prima domanda non è “funziona?”, ma “cosa ha visto, cosa ha bloccato e perché”. I log sono il punto di partenza corretto perché raccontano la sequenza reale degli eventi: tentativi di login, regex che hanno matchato, azioni di ban e possibili errori di configurazione. Se un servizio risulta irraggiungibile, un accesso amministrativo viene bloccato o il server mostra traffico sospetto, i log di Fail2Ban permettono di capire se il blocco è legittimo oppure se c’è un falso positivo.

Questa guida ti aiuta a leggere i log in modo operativo, senza perdere tempo dietro a teoria inutile. L’obiettivo è semplice: identificare il jail coinvolto, vedere gli IP bannati, capire il motivo del ban e verificare se esistono errori che impediscono a Fail2Ban di lavorare correttamente.

1. Dove trovare i log di Fail2Ban

Il percorso dei log dipende dalla distribuzione e da come è stato installato il servizio. Nella maggior parte dei casi troverai informazioni utili in uno di questi punti:

• /var/log/fail2ban.log su molte installazioni Debian, Ubuntu e derivate.
• /var/log/messages o /var/log/secure su sistemi RHEL, AlmaLinux, Rocky Linux e CentOS, se il logging è integrato nel syslog di sistema.
• journalctl se il servizio scrive principalmente su systemd journal.

Se non sai da dove iniziare, il primo controllo è quasi sempre questo:

sudo ls -l /var/log/fail2ban.log /var/log/messages /var/log/secure 2>/dev/null

Esito atteso: almeno uno dei file esiste. Se non c’è, non significa che Fail2Ban non funzioni, ma che i log potrebbero finire nel journal o in un file diverso definito dalla configurazione.

2. Verifica immediata dello stato del servizio

Prima di leggere i log, conviene verificare che il servizio sia attivo. Se Fail2Ban non è in esecuzione, i log potrebbero fermarsi a un errore di avvio o a una modifica di configurazione non caricata.

sudo systemctl status fail2ban --no-pager

Esito atteso: stato active (running). Se vedi failed o inactive, il log va letto insieme alla causa di stop o di avvio fallito.

Su sistemi con systemd, puoi anche guardare gli ultimi messaggi del servizio:

sudo journalctl -u fail2ban -n 100 --no-pager

Questo comando è utile quando il file classico di log è vuoto o non presente. Cerca errori come regex non valide, jail non caricate, file di configurazione mancanti, backend non raggiungibile o problemi di permessi.

3. Leggere i log in tempo reale

Se stai gestendo un incidente in corso, il modo più efficace è osservare Fail2Ban mentre reagisce ai tentativi. In questo modo puoi associare in tempo reale un login fallito a un eventuale ban.

sudo tail -f /var/log/fail2ban.log

Se il file non esiste, sostituiscilo con il journal:

sudo journalctl -u fail2ban -f

Esito atteso: righe che mostrano la sequenza Found, Ban, Unban, oppure messaggi di errore. Un esempio tipico è simile a questo:

2026-03-30 10:12:14,001 fail2ban.filter [1234]: INFO [sshd] Found 203.0.113.45 - 2026-03-30 10:12:14
2026-03-30 10:12:16,450 fail2ban.actions [1234]: NOTICE [sshd] Ban 203.0.113.45

Queste due righe ti dicono che il jail sshd ha riconosciuto un tentativo sospetto e ha bloccato l’IP. Se il tuo problema è un accesso SSH negato, questa è la prova più importante da cercare.

4. Capire quali jail sono attivi

Un errore molto comune è cercare il problema nel log sbagliato. Fail2Ban divide le protezioni in jail: SSH, web server, posta, autenticazione web, pannelli hosting e altro. Prima devi sapere quale jail è coinvolto.

sudo fail2ban-client status

Esito atteso: elenco dei jail attivi. Per ogni jail sospetto, approfondisci con:

sudo fail2ban-client status sshd

Il risultato mostra almeno questi elementi utili:

• Numero di IP bannati.
• Elenco degli IP attualmente bloccati.
• File di log monitorati dal jail, se disponibili.

Se non vedi il jail che ti aspetti, il problema potrebbe essere nella configurazione o nel caricamento della regola, non nel ban in sé.

5. Cercare nel log i ban e i tentativi falliti

Per analizzare un incidente, conviene filtrare i log con parole chiave specifiche. Le più utili sono Ban, Unban, Found, ERROR, WARNING e il nome del jail.

Esempio pratico:

sudo grep -Ei 'fail2ban|Ban |Unban |Found |ERROR|WARNING' /var/log/fail2ban.log

Esito atteso: una sequenza leggibile degli eventi principali. Se il file è molto grande, puoi restringere il periodo o il jail:

sudo grep -Ei 'sshd|Ban |Found ' /var/log/fail2ban.log

Per controllare un IP specifico, ad esempio un tuo indirizzo bannato per errore:

sudo grep -F '203.0.113.45' /var/log/fail2ban.log

Questo ti mostra quando è stato rilevato, quando è stato bannato e se è stato poi sbloccato. È il controllo più utile quando devi decidere se intervenire con un unban o con una modifica della whitelist.

6. Interpretare i messaggi più importanti

Nei log di Fail2Ban ci sono alcuni messaggi ricorrenti. Saperli interpretare velocemente evita errori di diagnosi.

• Found: la regex del filtro ha riconosciuto un tentativo sospetto nel log sorgente.
• Ban: l’IP è stato effettivamente bloccato dal jail.
• Unban: l’IP è stato rimosso dal blocco, spesso per scadenza del bantime o per intervento manuale.
• WARNING / ERROR: possibile problema di configurazione, path errato, backend non disponibile o filtro mal scritto.

Se vedi molti Found ma nessun Ban, controlla la logica del jail: potrebbe essere in modalità test, il bantime potrebbe essere molto corto oppure il backend non sta applicando l’azione.

Se vedi Ban ma poi il servizio continua a ricevere accessi, potresti avere una whitelist, un firewall esterno, un reverse proxy o una CDN che rende il ban meno efficace del previsto.

7. Verificare il motivo del ban da configurazione

Il log ti dice cosa è successo, ma la configurazione ti dice perché. Per capire la causa del ban, devi leggere i parametri del jail e del filtro coinvolto.

Controlla il jail attivo:

sudo fail2ban-client get sshd bantime
sudo fail2ban-client get sshd maxretry
sudo fail2ban-client get sshd findtime

Esito atteso: valori coerenti con la tua policy di sicurezza. Se maxretry è troppo basso, potresti bannare utenti legittimi troppo facilmente. Se bantime è troppo lungo, un falso positivo diventa un blocco pesante.

Per capire quale filtro sta generando il match, controlla i file in /etc/fail2ban/filter.d/ e le definizioni in /etc/fail2ban/jail.conf o meglio in /etc/fail2ban/jail.local e /etc/fail2ban/jail.d/. Prima di modificare qualsiasi cosa, fai un backup del file interessato.

sudo cp /etc/fail2ban/jail.local /etc/fail2ban/jail.local.$(date +%F_%H%M%S).bak

Se il tuo sistema usa un file diverso, adatta il percorso. Il backup è importante perché una modifica errata può disattivare il servizio o farlo caricare con regole sbagliate.

8. Controllare gli errori di configurazione nei log

Molti incidenti non dipendono da un ban corretto, ma da un errore di configurazione che impedisce a Fail2Ban di leggere i log giusti o di applicare il firewall.

Cerca messaggi come questi:

• file non trovato
• regex non valida
• backend non supportato
• impossibile avviare l’azione
• iptables, nftables o firewall-cmd non disponibili

Per una verifica rapida della configurazione, usa questo controllo:

sudo fail2ban-client -d

Esito atteso: output di debug senza errori bloccanti. Se compaiono errori di parsing o di percorso, la configurazione va corretta prima di considerare affidabili i ban.

Un altro controllo utile è il test del filtro contro un log reale, quando sospetti che il match non sia corretto. In quel caso, l’analisi del filtro specifico è più efficace del semplice controllo del servizio.

9. Verificare se l’IP è davvero bannato

Durante un incidente, non basta leggere il log: devi sapere se il blocco è presente a livello operativo. Il log può mostrare un ban avvenuto, ma se il firewall è stato resettato o l’azione è fallita, l’IP potrebbe non essere più bloccato.

Controlla il jail:

sudo fail2ban-client status sshd

Esito atteso: lista degli IP bannati nel campo Banned IP list. Se l’IP sospetto non compare, cerca nei log un eventuale Unban o un errore di applicazione dell’azione.

Se usi nftables o iptables, puoi anche incrociare la presenza della regola firewall con il log di Fail2Ban. Questo passaggio è utile quando il ban risulta nel journal ma il traffico continua comunque a passare.

10. Caso pratico: accesso SSH bloccato per errore

Uno degli scenari più frequenti è l’amministratore che si ritrova escluso dal server dopo diversi tentativi falliti. In questo caso la sequenza corretta è:

1. Controllare nei log se il tuo IP compare come Ban.
2. Verificare il jail sshd con fail2ban-client status sshd.
3. Controllare se il blocco è coerente con maxretry e findtime.
4. Se l’IP è tuo e il ban è un falso positivo, rimuoverlo solo dopo aver verificato che l’accesso sia sicuro.

Per sbloccare un IP, il comando tipico è:

sudo fail2ban-client set sshd unbanip 203.0.113.45

Usalo solo se sei certo che l’IP sia legittimo. Dopo l’unban, verifica subito che il log mostri il cambiamento e che l’accesso SSH torni disponibile.

11. Caso pratico: web server o pannello hosting

Se il problema riguarda un sito o un pannello di controllo, il jail coinvolto può essere diverso da sshd. Spesso trovi regole per Apache, Nginx, autenticazioni web, cPanel, Plesk o altri servizi esposti su HTTP/HTTPS.

In questo scenario, cerca nel log il nome del jail specifico e gli indirizzi IP che generano molti errori di login. Se il sito è in produzione, valuta anche se il blocco deriva da un crawler aggressivo, da un bot malevolo o da un plugin che produce falsi 403/401.

Controlli utili:

sudo fail2ban-client status
sudo fail2ban-client status apache-auth
sudo fail2ban-client status nginx-http-auth

Esito atteso: presenza del jail corretto e conteggio dei ban coerente con il traffico anomalo osservato. Se il jail non esiste, la protezione potrebbe non essere installata o potrebbe avere un nome diverso da quello che ti aspetti.

12. Buone pratiche durante l’analisi

Quando lavori sui log di Fail2Ban, segui un metodo semplice e ripetibile:

• Salva sempre una copia dei file di configurazione prima di cambiarli.
• Controlla prima i log, poi la configurazione, poi il firewall.
• Non disabilitare un jail per comodità senza aver capito il motivo del ban.
• Se un IP legittimo viene bannato spesso, valuta whitelist, soglie più alte o un filtro più preciso.
• Dopo ogni modifica, verifica subito lo stato del servizio e il contenuto del jail interessato.

Questo approccio riduce il rischio di lasciare il server scoperto o di rimuovere una protezione utile per inseguire un falso positivo isolato.

13. Checklist rapida per l’incidente

1. Verifica che Fail2Ban sia attivo con systemctl status fail2ban.
2. Leggi il log in tempo reale con tail -f o journalctl -f.
3. Individua il jail coinvolto con fail2ban-client status.
4. Controlla se l’IP è bannato davvero e se compare un Ban o un Unban.
5. Se trovi un errore, correggi prima configurazione e filtro, poi riavvia e verifica di nuovo.

14. Conclusione operativa

La lettura dei log di Fail2Ban non serve solo a vedere chi è stato bloccato. Serve a capire se il blocco è corretto, se il filtro sta funzionando, se il firewall sta applicando davvero la regola e se il server è protetto nel modo giusto. In un incidente, il valore vero sta nella sequenza: servizio attivo, jail corretto, log leggibili, ban verificato, eventuale rollback sicuro.

Se vuoi lavorare in modo affidabile, non fermarti al singolo messaggio “Ban”. Incrocia sempre il log, il jail e lo stato del firewall. È così che distingui una protezione utile da un falso allarme e che intervieni senza peggiorare la situazione.