Advanced Policy Firewall, APF, è uno dei nomi storici della sicurezza dei server Linux. Il vecchio articolo di SicurezzaReti risaliva al 2012, ma il progetto non è rimasto congelato lì: R-fx Networks lo ha aggiornato e la serie 2.x è tornata a essere un firewall management layer moderno per server Linux.
APF rimane basato su iptables/netfilter, ma oggi integra systemd, IPv6 dual-stack, Docker compatibility, ipset, GeoIP, temporary trust/deny con TTL, connection tracking limit e logging JSONL. Quindi ha ancora senso studiarlo, a patto di non applicare configurazioni del 2012 a una release del 2026.
Cosa fa APF e cosa non fa
APF non sostituisce Netfilter: costruisce e amministra le regole per noi. La sua architettura mantiene tre famiglie di controlli:
- policy statiche su porte, protocolli e indirizzi;
- policy stateful basate sullo stato delle connessioni;
- controlli di “sanity”, rate limiting e sistemi reattivi.
Il vantaggio principale è amministrativo: configurazione centrale, trust list, strumenti CLI, audit e sottosistemi già integrati.
Installazione
Usiamo la sorgente ufficiale del progetto:
apt update
apt install git iptables ipset conntrack
git clone https://github.com/rfxn/advanced-policy-firewall.git
cd advanced-policy-firewall
sudo ./install.shL’installazione usa normalmente /etc/apf e installa anche servizio systemd, man page, logrotate e cron necessari ai vari sottosistemi.
apf --version
systemctl status apf
man apfDEVEL_MODE: la cintura di sicurezza
Una delle funzioni più intelligenti di APF è DEVEL_MODE="1", attivo di default. Durante la prima configurazione APF svuota automaticamente le regole dopo alcuni minuti, così un errore non ci lascia tagliati fuori dal server per sempre.
grep '^DEVEL_MODE=' /etc/apf/conf.apf
apf -sPrima di disabilitare development mode verifichiamo SSH da una seconda sessione, i servizi pubblici e le allowlist amministrative. Solo dopo:
sed -i 's/DEVEL_MODE="1"/DEVEL_MODE="0"/' /etc/apf/conf.apf
apf -rPorte in ingresso e in uscita
Le variabili più importanti della policy globale sono:
# /etc/apf/conf.apf
IG_TCP_CPORTS="22,80,443"
IG_UDP_CPORTS="53"
# Egress filtering
EGF="1"
EG_TCP_CPORTS="53,80,443"
EG_UDP_CPORTS="53,123"I valori sono soltanto esempi. Un web server senza DNS autorevole probabilmente non deve esporre UDP/53; un mail server avrà esigenze differenti. La policy va costruita dai servizi realmente presenti, non copiando una lista generica.
IPv6
Se il server dispone di IPv6, ignorarlo nel firewall significa creare una seconda superficie d’attacco meno controllata. APF 2.x supporta policy dual-stack.
grep '^USE_IPV6=' /etc/apf/conf.apf
apf --infoDopo aver abilitato IPv6 verifichiamo esplicitamente anche le porte IPv6 dall’esterno, non soltanto quelle IPv4.
Trust e deny list
# autorizza un indirizzo
apf -a 192.0.2.10 "VPN amministrativa"
# blocca un indirizzo
apf -d 203.0.113.25 "scanner aggressivo"
# aggiorna le trust rules
apf -eI file locali sono /etc/apf/allow_hosts.rules e /etc/apf/deny_hosts.rules. Commentare le entry è importante: una whitelist senza una ragione documentata diventa presto impossibile da auditare.
Blocchi temporanei con TTL
La serie 2.x supporta temporary allow/deny. È il meccanismo adatto alle reazioni automatiche perché il blocco scade da solo.
# Temporary allow per un'ora
apf -ta 192.0.2.20 1h "manutenzione"
# Temporary deny per 30 minuti
apf -td 203.0.113.77 30m "tentativi ripetuti"Un sistema come Fail2Ban, BFD o un sensore custom può quindi applicare una reazione temporanea senza riempire per sempre la deny list.
Connection Tracking Limit
CT_LIMIT conta le connessioni per sorgente attraverso conntrack e può applicare un temporary deny quando un IP supera la soglia.
# /etc/apf/conf.apf
CT_LIMIT="300"
CT_BLOCK_TIME="1800"
CT_SKIP_TIME_WAIT="1"
# opzionale: limita il controllo ad alcune porte
CT_PORTS="80,443"Le soglie devono essere misurate sul traffico reale. Un reverse proxy, una CDN o un monitoraggio potrebbero generare molte connessioni legittime e vanno eventualmente inseriti in CT_SKIP.
apf --ct-status
apf --ct-scanGeoIP: usare prima la modalità audit
APF 2.x può costruire ipset per paesi e continenti. Il blocco geografico non è autenticazione e non va trattato come tale, ma può ridurre il rumore quando un servizio ha realmente un perimetro geografico ristretto.
Prima di bloccare usiamo CC_LOG_ONLY="1" per misurare l’impatto e aggiungiamo sempre gli IP amministrativi alla trust list.
# /etc/apf/cc_deny.rules
CN
RU
# conf.apf
CC_LOG_ONLY="1"
apf --cc-update
apf --cc
apf -rQuando siamo certi dell’effetto possiamo passare dal solo logging al blocco effettivo.
Logging e audit
tail -F /var/log/apf_log
tail -F /var/log/apf/audit.log
apf --info
apf --rules | lessaudit.log è in formato JSONL e permette di ricostruire mutazioni delle trust list, eventi di configurazione e stato del servizio senza dover interpretare soltanto il dump delle regole.
Validare e riavviare
apf --validate
apf --dump-config | less
apf -r
systemctl status apfDopo un cambio di policy testiamo il server sia dalla rete amministrativa sia da una sorgente esterna, verificando che siano raggiungibili soltanto i servizi previsti.
APF, Fail2Ban e RwF insieme
Non è necessario scegliere un solo strumento per ogni livello. APF può governare la policy host e le trust list; Fail2Ban/BFD possono interpretare i log di autenticazione; RwF può riconoscere richieste HTTP ostili. L’importante è che i componenti non si contraddicano e che esista un modo unico per capire chi ha bloccato cosa.
Il modello generale è descritto in Firewall proattivo: dal filtraggio statico alla risposta automatica.
