Blog

Docker & Fail2Ban: Come Blindare Nginx Proxy Manager e Proteggere WordPress

Posted by

14 Aprile 2026 On 14 Aprile 2026

Se gestisci la tua infrastruttura web tramite Docker e Nginx Proxy Manager (NPM), ti sarai accorto che la sicurezza perimetrale non è scontata. Spesso, installare Fail2Ban sull’host Ubuntu non basta: i log sono isolati nei volumi e le regole di rete di Docker tendono a “scavalcare” il firewall standard (iptables).

Recentemente ho affrontato un attacco brute-force e una scansione aggressiva da parte di bot (come Bytespider). In questo articolo vi mostro come configurare Fail2Ban per leggere i log direttamente dai volumi Docker e agire sulla catena corretta per bloccare le minacce.

Il Problema: Il “Velo” di Docker

In un ambiente Dockerizzato, Fail2Ban è spesso “cieco” per tre motivi:

Log Isolati: I log di accesso di NPM sono scritti dentro i volumi (es. proxy-host-X_access.log) e non nei percorsi standard di sistema.
Firewall Bypass: Docker crea regole iptables prioritarie. Se banni un IP nella catena standard (INPUT), Docker potrebbe comunque inoltrare quel traffico al container.
Soft 404: WordPress spesso risponde con un codice 200 OK anche per pagine non trovate, rendendo difficile per i filtri standard rilevare le scansioni.

La Soluzione: Configurazione Passo-Passo

1. Identificare i Log

Il primo passo è mappare dove NPM salva i log sul disco host. Solitamente si trovano in:

/var/lib/docker/volumes/proxy-manager_npm_data/_data/logs/

2. Creare un Filtro Personalizzato

Dobbiamo istruire Fail2Ban su cosa cercare. Abbiamo creato un filtro in /etc/fail2ban/filter.d/npm-4xx.conf che intercetta errori 404, 403 e tentativi di login (POST) sospetti:

Ini, TOML

[Definition]
failregex = ^\[.*\] - (301|403|404|444|429|499) .* - .* \[Client <HOST>\]
            ^\[.*\] - 200 200 - POST .* "/wp-login.php" \[Client <HOST>\]

3. Configurare la Jail (La “Gabbia”)

In /etc/fail2ban/jail.local, abbiamo configurato la jail per agire sulla catena DOCKER-USER, l’unica che garantisce il blocco del traffico verso i container:

Ini, TOML

[npm-4xx]
enabled = true
filter = npm-4xx
logpath = /var/lib/docker/volumes/proxy-manager_npm_data/_data/logs/proxy-host-*_access.log
backend = polling
maxretry = 10
findtime = 60
bantime = 86400
action = iptables-allports[chain="DOCKER-USER"]

Risultati e Test

Abbiamo validato la configurazione iniettando righe di log simulate. Il risultato è stato immediato: Fail2Ban ha rilevato l’attacco e ha applicato il ban a livello di Kernel.

I log attuali mostrano che il sistema è ora resiliente: i bot aggressivi ricevono un 403 Forbidden e, se insistono, vengono murati fuori dal server per 24 ore prima ancora di toccare WordPress.

Legenda dei Comandi Usati

Ecco i comandi fondamentali utilizzati durante la messa in sicurezza del server:

Comando	Descrizione
`docker inspect [container]`	Usato per trovare il percorso reale dei volumi Docker sul disco host.
`tail -f [path_log]`	Visualizza in tempo reale le richieste che arrivano ai siti.
`fail2ban-client status npm-4xx`	Mostra lo stato della protezione e l’elenco degli IP attualmente bannati.
`fail2ban-regex [log] [filtro]`	Testa se la regola del filtro funziona correttamente sul file di log indicato.
`fail2ban-client set [jail] unbanip [IP]`	Il comando per “liberare” un IP (indispensabile in caso di auto-ban).
`iptables -L DOCKER-USER -n -v`	Verifica le regole attive nel firewall specifiche per il traffico Docker.
`systemctl restart fail2ban`	Riavvia il servizio per applicare tutte le nuove configurazioni.