In breve: Fail2ban legge i file di log e blocca nel firewall gli indirizzi che compaiono troppo spesso entro un intervallo di tempo. Per Nginx e Apache fornisce jail già pronti come nginx-botsearch o apache-noscript; i filtri propri li testa con fail2ban-regex. Le impostazioni vanno in jail.local, i Suoi indirizzi in ignoreip, i recidivi li intercetta il jail recidive. Contro singoli attacchi mirati Fail2ban non aiuta, contro le scansioni di massa sì.
Quando i log sono pieni di scanner
Chi in questi giorni guarda i registri di accesso dei propri server web li trova spesso pieni di richieste a percorsi che non esistono affatto: vecchie interfacce di amministrazione, file di prova, vulnerabilità note di altri prodotti. In una situazione come PHP2Shell si aggiunge la ricerca mirata di server vulnerabili: Cloudflare e Patchstack hanno riferito di tentativi di attacco, Unit 42 ha contato più di 22,6 milioni di istanze esposte e potenzialmente vulnerabili.
Fail2ban è uno strumento collaudato contro questa massa. Legge i file di log, riconosce con i filtri le voci anomale e blocca l'indirizzo del mittente per un tempo stabilito nel firewall. Alleggerisce il server, riduce il rumore nei log e rende più faticoso il tentativo sistematico da una singola fonte.
Ciò che Fail2ban non può fare è altrettanto importante: una singola richiesta che sfrutta una falla non viene impedita. Contro PHP2Shell aiuta solo l'aggiornamento di PHP. Come si svolgono gli attacchi automatizzati lo descrive Scansioni di massa alla ricerca di PHP senza patch.
Fail2ban per Nginx e Apache: i jail forniti
Un jail collega un filtro a un file di log e a un'azione di blocco. Il jail.conf fornito contiene già jail per i server web. Per impostazione predefinita sono disattivati e vengono attivati singolarmente.
| Jail | Server web | Riconosce |
|---|---|---|
nginx-http-auth |
Nginx | accessi HTTP Basic falliti |
nginx-limit-req |
Nginx | richieste che superano il rate limit di Nginx |
nginx-botsearch |
Nginx | ricerca di percorsi tipici inesistenti |
nginx-bad-request |
Nginx | richieste errate |
apache-auth |
Apache | accessi falliti |
apache-badbots |
Apache | identificativi di bot dannosi noti |
apache-noscript |
Apache | chiamate a script inesistenti |
apache-overflows |
Apache | richieste troppo lunghe |
apache-botsearch |
Apache | ricerca di percorsi tipici inesistenti |
php-url-fopen |
entrambi | determinati schemi di tentativi di inclusione di URL |
recidive |
entrambi | indirizzi che Fail2ban ha bloccato ripetutamente |
I valori predefiniti della configurazione fornita sono piuttosto miti: blocco di 10 minuti dopo 5 riscontri in 10 minuti. Per i server web con molto traffico di scansione vale la pena di prevedere un blocco più lungo e un fattore crescente per le ripetizioni.
La configurazione di base in jail.local
Il jail.conf dice da sé di non dover essere modificato, perché gli aggiornamenti lo sostituiscono. I valori propri vanno in /etc/fail2ban/jail.local. L'esempio seguente per Nginx imposta valori predefiniti sensati e attiva i jail adatti:
# /etc/fail2ban/jail.local
[DEFAULT]
# Inserire i propri indirizzi fissi (sostituire l'indirizzo di esempio)
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
[nginx-http-auth]
enabled = true
[nginx-botsearch]
enabled = true
[recidive]
enabled = true
bantime = 1w
findtime = 1d
Per Apache attivi invece ad esempio apache-auth, apache-noscript e apache-botsearch. I percorsi dei log li fornisce Fail2ban per ogni distribuzione; se i Suoi percorsi differiscono, imposti logpath nel rispettivo jail. Se il Suo sistema legge i log solo tramite il journal, aiuta backend = systemd.
Un filtro proprio per richieste di massa a file PHP
Uno schema tipico nella situazione attuale è costituito da molte richieste in breve tempo a file PHP che non esistono. Un filtro proprio lo riconosce dal codice di stato 404. Descrive solo ciò che sta nel Suo log:
# /etc/fail2ban/filter.d/nginx-php-404.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST|HEAD) [^"]*\.php[^"]*" 404
ignoreregex =
# Integrazione in /etc/fail2ban/jail.local
[nginx-php-404]
enabled = true
port = http,https
filter = nginx-php-404
logpath = /var/log/nginx/access.log
maxretry = 20
findtime = 1m
bantime = 1h
Prima di attivare il filtro, lo verifichi sul log reale. Così vede quante righe colpisce e se ci sono accessi legittimi:
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-php-404.conf
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status nginx-php-404
# Sbloccare un indirizzo bloccato per errore
sudo fail2ban-client set nginx-php-404 unbanip 203.0.113.25
Scelga la soglia in modo generoso. Un crawler che elabora link obsoleti o un servizio di monitoraggio non deve finire nel blocco.
Le trappole più frequenti
Fail2ban si installa in fretta, ma si usa facilmente nel modo sbagliato. Questi punti andrebbero verificati prima dell'uso in produzione:
- Autoesclusione: gli indirizzi di ufficio, VPN e monitoraggio vanno in
ignoreipprima che i jail diventino attivi. - Servizi a monte: dietro CDN o load balancer Fail2ban, senza adattamenti, vede solo i loro indirizzi. Maggiori informazioni nella guida Proteggere i login di amministrazione dal brute force.
- Rotazione dei log: dopo il cambio del file di log, Fail2ban deve leggere il nuovo file. Dopo la prima rotazione verifichi se i jail continuano a contare riscontri.
- Interazione con il firewall: Fail2ban inserisce i blocchi nel firewall. Chi gestisce il proprio firewall con un ricaricamento completo del set di regole può cancellare tali voci. Come costruire il firewall stesso lo spiega Firewall per server web: aprire solo le porte necessarie.
- IPv6: gli attacchi arrivano anche via IPv6. Verifichi se la Sua azione di blocco copre entrambi i protocolli.
Analizzi regolarmente gli elenchi dei blocchi. Se si accumulano blocchi da determinate reti o su determinati percorsi, è un indizio di ricerca mirata e un motivo per esaminare più da vicino l'applicazione interessata.
Conclusione: uno strumento contro la massa, non contro tutto
Fail2ban si configura in fretta e toglie ai server web una parte del bombardamento continuo. I jail forniti coprono schemi tipici, i filtri propri si possono testare senza rischi su log reali con fail2ban-regex e il jail recidive fa sì che le fonti ostinate restino fuori più a lungo.
Non lo sopravvaluti. Fail2ban reagisce alla ripetizione, non al primo riscontro, e vede solo ciò che sta nei log. Contro una falla come PHP2Shell aiuta solo l'aggiornamento, contro attacchi distribuiti da molti indirizzi Fail2ban aiuta a malapena. Il suo valore si esprime come livello tra più: accanto a un firewall snello, a una configurazione rafforzata del server web, all'autenticazione a due fattori e a un monitoraggio che non si limiti a bloccare le anomalie, ma le segnali.
Come aiuta PHP SOS in concreto?
- Analizzare i log: esaminiamo quali schemi compaiono nei Suoi registri di accesso e scegliamo i jail adatti.
- Configurare e testare: configuriamo Fail2ban con filtri propri, testiamo ogni filtro su log reali e inseriamo come eccezione i Suoi indirizzi fissi.
- Chiarire l'interazione: CDN, load balancer, firewall e rotazione dei log li armonizziamo in modo che i blocchi colpiscano gli indirizzi giusti.
- Osservare: nell'ambito del Security Monitoring analizziamo in continuo blocchi e anomalie.
Domande frequenti
Fail2ban protegge da PHP2Shell?
No. Fail2ban reagisce solo dopo che un indirizzo è comparso più volte nei log. Un singolo attacco riuscito non viene così impedito. Fail2ban riduce però il carico degli scanner e rende più costosi i tentativi ripetuti dalla stessa fonte.
Perché non devo modificare direttamente jail.conf?
Il file viene sostituito con gli aggiornamenti dei pacchetti, e lo dice da sé. Le impostazioni proprie vanno in un jail.local o in file sotto jail.d. Lì sovrascrivono in modo mirato i valori predefiniti.
Che cos'è il jail recidive?
Un jail che analizza il registro di Fail2ban stesso. Chi viene bloccato ripetutamente riceve un blocco molto più lungo. Nella configurazione fornita è di una settimana.
Fail2ban funziona dietro Cloudflare o un load balancer?
Solo con configurazione aggiuntiva. Senza di essa nei log compare l'indirizzo del servizio a monte e un blocco colpirebbe tutti i visitatori. Il server web deve allora assumere il vero indirizzo del visitatore e i blocchi si impostano meglio sul servizio a monte.