Un firewall tradizionale risponde a una domanda relativamente semplice: questo pacchetto può passare oppure no? Le regole vengono definite dall’amministratore e rimangono valide finché qualcuno non le modifica. È il modello corretto per descrivere la normale policy di rete, ma non basta sempre a reagire a un comportamento ostile che emerge soltanto osservando una sequenza di eventi.
Un firewall “proattivo”, nel senso pratico del termine, aggiunge quindi un secondo livello: oltre alla policy statica esistono componenti che osservano ciò che accade e possono modificare temporaneamente l’enforcement. Un IP che fallisce cinquanta autenticazioni SSH, un client che richiede file sensibili via HTTP o una sorgente che supera una soglia di connessioni possono essere bloccati senza attendere l’intervento manuale dell’amministratore.
Statico, stateful e reattivo non sono sinonimi
Conviene distinguere tre concetti che spesso finiscono nello stesso calderone:
- policy statica: porte, reti e protocolli ammessi o vietati;
- stateful filtering: il firewall conosce lo stato delle connessioni e distingue traffico nuovo, stabilito, correlato o non valido;
- risposta reattiva: un evento osservato da firewall, log parser o applicazione modifica temporaneamente la policy verso una sorgente.
Il secondo livello non rende automaticamente il firewall “intelligente”; evita soprattutto di dover scrivere regole simmetriche e statiche per ogni pacchetto di risposta. Il terzo livello, invece, introduce davvero una forma di automazione.
Detection ed enforcement devono restare separati
Una delle scelte architetturali più importanti è non dare a ogni sensore privilegi illimitati sul firewall. Il componente che rileva l’evento dovrebbe produrre una decisione semplice e verificabile; un livello separato applica il blocco.
evento
|
+-- auth.log / journald ------> Fail2Ban o BFD
|
+-- Apache / reverse proxy ---> RwF
|
+-- conntrack / firewall -----> APF CT_LIMIT
|
v
ban temporaneo
|
v
iptables / nftablesQuesto disaccoppiamento rende più semplice capire perché un indirizzo sia stato bloccato e permette di applicare timeout, allowlist e rollback in modo uniforme.
APF: policy di firewall e blocchi dinamici
Advanced Policy Firewall nasce proprio per semplificare la gestione di un firewall Linux orientato ai server. La versione attuale mantiene il modello iptables/netfilter ma aggiunge trust list, blocchi temporanei, GeoIP, connection tracking limit, ipset, logging strutturato e compatibilità con systemd e ambienti moderni.
APF è utile quando vogliamo che la policy principale, le allow/deny list e alcune reazioni automatiche appartengano allo stesso sistema amministrativo. La guida completa è Advanced Policy Firewall (APF) su Linux.
Fail2Ban e BFD: reagire ai log
Fail2Ban e strumenti come BFD osservano invece i log. Non sanno intrinsecamente cosa sia una connessione SSH fallita: riconoscono pattern prodotti dal servizio e, superata una soglia, invocano un’azione di ban.
È un modello potente perché il servizio possiede informazioni che il firewall non vede. Un SYN verso la porta 22 è soltanto traffico TCP; cinque autenticazioni fallite per utenti inesistenti hanno un significato applicativo molto più preciso.
# esempio di verifica Fail2Ban
fail2ban-client status
fail2ban-client status sshd
journalctl -u fail2ban --since "-30 min"Reactive Web Firewall: la stessa idea applicata a HTTP
Il nostro Reactive Web Firewall applica lo stesso principio al reverse proxy. Apache riconosce un pattern HTTP ad alta confidenza, risponde con 403 e invia un evento a un helper che inserisce l’IP in un set nftables con timeout.
La differenza rispetto a un semplice WAF è che il blocco successivo avviene prima che le nuove richieste raggiungano Apache.
Ban temporaneo prima del ban permanente
Un sistema automatico può sbagliare. Per questo la reazione normale dovrebbe essere temporanea e proporzionata. I set nftables con timeout, le temporary deny list di APF e i bantime di Fail2Ban sono esempi dello stesso principio.
Un ban permanente dovrebbe richiedere una confidenza molto maggiore oppure un’escalation basata su recidiva. Altrimenti una falsa rilevazione diventa un incidente auto-inflitto.
Allowlist: necessaria ma pericolosa
Monitoraggio, reverse proxy, CDN, resolver e sistemi amministrativi possono aver bisogno di eccezioni. L’allowlist deve però essere la più stretta possibile. Autorizzare “tutta Cloudflare”, “tutta la LAN” o un intero provider senza una ragione precisa crea un canale che aggira le protezioni proprio per le sorgenti più potenti.
Rate limiting e connection limiting
Non tutto ciò che è eccessivo è un attacco. Un crawler legittimo o un’applicazione mal configurata possono produrre troppe connessioni. Prima di bloccare definitivamente conviene spesso limitare il tasso o il numero di connessioni concorrenti.
# osservare conntrack
conntrack -L 2>/dev/null | head
conntrack -C
# socket e connessioni
ss -s
ss -tn state established | headAPF 2.x include anche CT_LIMIT, che conta le connessioni per sorgente e può applicare temporary deny quando una soglia viene superata.
Loggare una decisione, non soltanto il pacchetto
Una difesa automatica deve poter spiegare le proprie decisioni. “IP 203.0.113.5 bannato” è molto meno utile di “bannato per 30 minuti perché 12 autenticazioni SSH fallite in 60 secondi” oppure “match RwF sulla richiesta /.git/config”.
Questo collega il firewall direttamente all’Incident Response: detection, enforcement e logging devono permettere di ricostruire l’evento dopo che è successo.
Una buona architettura reattiva
- parte da una policy firewall restrittiva ma leggibile;
- usa sensori specifici per il livello osservato;
- applica ban con timeout per default;
- mantiene allowlist esplicite e documentate;
- registra motivo, sorgente, durata e componente che ha deciso il blocco;
- prevede sempre una procedura di verifica e sblocco;
- non considera il ban automatico un sostituto del patching.
Il risultato non è un firewall “che pensa da solo”. È un insieme di componenti che reagiscono velocemente a segnali specifici, mantenendo però decisioni comprensibili e reversibili.
