# Configurare Fail2ban per i server web

> Fail2ban per Nginx e Apache: attivare i jail adatti, testare filtri propri con fail2ban-regex, bloccare i recidivi ed evitare di escludere sé stessi.

Fonte: https://phpsos.de/it/blog/fail2ban-fuer-webserver/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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](https://phpsos.de/it/blog/automatisierte-massenscans/).

## 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:

```ini
# /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:

```ini
# /etc/fail2ban/filter.d/nginx-php-404.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST|HEAD) [^"]*\.php[^"]*" 404
ignoreregex =
```

```ini
# 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:

```bash
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:

1. **Autoesclusione:** gli indirizzi di ufficio, VPN e monitoraggio vanno in `ignoreip` prima che i jail diventino attivi.
2. **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](https://phpsos.de/it/ratgeber/brute-force-login-schutz/).
3. **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.
4. **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](https://phpsos.de/it/blog/firewall-fuer-webserver/).
5. **IPv6:** gli attacchi arrivano anche via IPv6. Verifichi se la Sua azione di blocco copre entrambi i protocolli.

> **Consiglio:**
> 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](https://phpsos.de/it/leistungen/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.

## Fonti

- [Fail2ban: jail.conf fornito](https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [OWASP Cheat Sheet](https://cheatsheetseries.owasp.org/)
