UFW è stato ideato perché un firewall si configurasse con tre comandi, e in questo riesce. Il problema è altrove: ufw status mostra intenzioni, non risultati. Una regola può figurare nell’elenco e non chiudere assolutamente nulla, per tre motivi diversi che sui server reali si presentano con regolarità.

Un avvio che non la chiude fuori

L’ordine dei comandi conta. Prima consentire SSH, poi attivare:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable prima di consentire SSH interrompe la sua stessa sessione, e poi resta solo la console del provider. Se il server è già configurato e non è sicuro, tenga aperta una seconda connessione: sopravvivrà a una modifica sbagliata.

Guardi lo stato dettagliato; quello breve nasconde la politica predefinita:

sudo ufw status verbose

Errore uno: la regola c’è e la porta è aperta al mondo

La riga più frequente nelle configurazioni altrui:

sudo ufw allow 3306

Così si apre MySQL «per potermi collegare da casa», e lo si apre a tutta internet. Le varianti corrette sono due, ed entrambe sono migliori:

sudo ufw allow from 203.0.113.25 to any port 3306

oppure, ancora più affidabile, non far uscire affatto il servizio: bind-address = 127.0.0.1 nella configurazione di MySQL e accesso esterno tramite un tunnel SSH. Il firewall è la seconda linea; la prima è che il servizio non ascolti su un indirizzo pubblico. Una regola di UFW può essere cancellata per errore, bind-address non cambia da solo.

Errore due: IPv6

Una regola del tipo ufw allow from 203.0.113.25 riguarda solo IPv4. Se il server ha un indirizzo IPv6 — e la maggior parte dei VPS ce l’ha, attivo — il servizio resta raggiungibile per quella via. Il provider ha assegnato l’indirizzo, lei non lo ricorda, lo scanner lo conosce.

Verifichi che il filtraggio v6 sia attivo (IPV6=yes in /etc/default/ufw) e che il servizio non ascolti su :: senza necessità:

ss -tulpn | grep ':::'

Le regole che indicano esplicitamente un indirizzo vanno scritte separatamente per ciascuna versione del protocollo.

Errore tre: Docker

Il più irritante. Docker pubblica le porte scrivendo le proprie regole nelle catene iptables prima di quelle in cui scrive UFW. Di conseguenza un container avviato con -p 5432:5432 è raggiungibile da internet anche se UFW mostra Status: active e una politica deny incoming. Il firewall non è rotto: semplicemente non arriva il suo turno.

Non si risolve in UFW ma nel modo in cui la porta viene pubblicata:

ports:
  - "127.0.0.1:5432:5432"

L’associazione all’indirizzo locale è la soluzione più semplice e affidabile. Verso l’esterno deve guardare solo ciò che serve davvero i visitatori: di norma le porte 80 e 443 di un proxy inverso.

L’ordine delle regole

UFW applica la prima regola che corrisponde e lì si ferma. Un divieto aggiunto dopo un permesso quindi non funzionerà: non lo si raggiunge mai. Guardi la numerazione e inserisca al posto giusto:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

Le regole si cancellano per numero, ma i numeri si spostano dopo ogni cancellazione: cancelli una alla volta e rilegga l’elenco ogni volta.

La verifica dall’esterno

I comandi locali mostrano ciò che è configurato. Ciò che ne è venuto fuori davvero si vede solo da un’altra macchina:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

Va bene qualsiasi altro server o il suo computer di casa. È l’unica verifica che non mente, e conviene farla dopo ogni riconfigurazione rilevante, soprattutto dopo aver installato qualcosa che «configura la rete da solo»: Docker, pannelli di gestione, VPN.

I registri

Di default UFW non scrive quasi nulla. Si attiva così:

sudo ufw logging low

Le voci finiscono in /var/log/ufw.log, ma solo se nel sistema c’è rsyslog. Su Debian 12 e Ubuntu 24.04 può mancare, e allora tutto va nel journal di systemd:

sudo journalctl -k | grep -i '\[UFW'

Un /var/log/ufw.log vuoto di per sé non significa nulla: guardi prima nel journal.

Che cosa aspettarsi da un firewall

UFW chiude ciò che non deve essere raggiungibile. Non esamina il contenuto delle richieste dirette a ciò che è aperto: la porta 443 è aperta a tutti, e ciò che arriva al sito arriva senza ostacoli. È il lavoro di altri strumenti: un WAF a livello applicativo, un IDS a livello di traffico. Il compito del firewall è più modesto e più importante: che l’elenco delle porte aperte coincida con ciò che lei crede al riguardo. Come appare quell’elenco insieme alle regole attive su una pagina lo mostra la dimostrazione qui sotto.