Configurare il firewall con UFW su Debian 10 e 11

Su Debian 10 e 11 UFW è il modo più semplice per gestire un firewall host-based senza dover scrivere regole nftables a mano. Il punto non è “attivarlo e basta”: il punto è farlo in modo controllato, con una policy chiara, senza interrompere SSH e senza lasciare porte aperte per abitudine. In produzione, il firewall serve a ridurre la superficie esposta, non a sostituire segmentazione di rete, hardening dei servizi o controllo degli accessi.

Su Debian 10 il backend sottostante è spesso iptables; su Debian 11 la stack predefinita tende a passare a nftables, ma UFW continua a presentare la stessa interfaccia amministrativa. Questo è utile perché la procedura operativa resta quasi identica, ma cambia il contesto: se hai già regole gestite altrove, devi capire chi sta davvero programmando il filtro pacchetti. UFW non deve convivere alla cieca con altri firewall manager.

Quando UFW ha senso e quando no

UFW ha senso quando vuoi una policy leggibile, versionabile e veloce da mantenere su host singoli o piccoli gruppi di server. È adatto a web server, VPS, nodi applicativi, ambienti di test e macchine con esposizione limitata. È meno adatto se gestisci regole complesse con routing avanzato, policy per VRF, NAT articolato o un’infrastruttura dove il firewall host è solo un pezzo di una catena più ampia già governata da automazione e compliance.

La regola pratica è semplice: se devi aprire 2–10 porte con logica lineare, UFW va bene. Se devi modellare decine di flussi con eccezioni dinamiche, meglio lavorare direttamente su nftables o su uno strato di orchestrazione che generi regole in modo coerente.

Verificare lo stato prima di toccare nulla

Prima di abilitare o modificare un firewall, devi sapere tre cose: quale servizio ti mantiene l’accesso remoto, quali porte sono già in ascolto e se altri strumenti stanno già gestendo il filtro. Questo evita il classico errore: attivare UFW su un server raggiungibile solo via SSH e ritrovarsi esclusi.

sudo ss -tulpn
sudo ufw status verbose
sudo systemctl status ufw

Il primo comando ti mostra le porte in ascolto e i processi associati. Il secondo ti dice se UFW è attivo, quale policy ha e quali regole sono già presenti. Il terzo verifica il servizio systemd. Se ufw status verbose restituisce Status: inactive, non significa che il server sia esposto senza difese in assoluto: significa solo che UFW non sta filtrando. Potrebbero esserci nftables, iptables legacy, security group cloud o un firewall a monte.

Installazione su Debian 10 e 11

Su entrambe le versioni l’installazione è lineare. Il pacchetto porta con sé anche il supporto per l’integrazione con systemd e il comando ufw. Se lavori in ambiente minimale, conviene installarlo da repository ufficiali Debian, non da sorgenti esterne.

sudo apt update
sudo apt install ufw

Dopo l’installazione, controlla che il comando sia disponibile e che il backend non sia in conflitto con altri strumenti. Se usi container, ricordati che UFW agisce sull’host, non all’interno del namespace del container, salvo casi particolari di rete host. Questo è un dettaglio che molti dimenticano e che genera false aspettative: aprire una porta nel container non basta se il nodo host la blocca.

Definire la policy di default senza fare danni

La configurazione sensata parte quasi sempre da una politica restrittiva in ingresso e permissiva in uscita. In altre parole: blocchi tutto ciò che entra, lasci uscire il traffico del server, poi apri solo i servizi necessari. Questa scelta riduce l’esposizione accidentale e rende più visibili eventuali aperture non autorizzate.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Se il server svolge ruoli particolari, la policy di uscita può essere più restrittiva, ma non farlo per abitudine. Limitare l’egress senza una mappa dei flussi applicativi produce più problemi che benefici e rende complicato il troubleshooting. In pratica: prima osservi, poi limiti.

Aprire SSH prima di attivare UFW

Il punto più delicato è l’accesso remoto. Se stai amministrando via SSH, la regola va inserita prima dell’attivazione del firewall. Su Debian, il profilo predefinito è spesso OpenSSH, ma è meglio verificare i profili disponibili sul sistema.

sudo ufw app list
sudo ufw allow OpenSSH

Se la tua installazione usa una porta SSH non standard, sostituisci il profilo con una regola esplicita. Esempio: se SSH ascolta su 2222, apri quella porta prima di attivare il firewall.

sudo ufw allow 2222/tcp

Un approccio più prudente è limitare l’accesso SSH a una sorgente nota, per esempio l’IP dell’ufficio o della VPN. Questo riduce drasticamente la superficie esposta su Internet. UFW supporta questa logica in modo semplice.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Se lavori dietro un NAT o un jump host, verifica il vero indirizzo sorgente percepito dal server. Un errore comune è autorizzare l’IP del client finale invece dell’IP del bastion o del proxy di uscita.

Attivare UFW senza perdere la sessione

Quando la regola SSH è già presente, puoi abilitare UFW. Il comando richiede conferma interattiva proprio per evitare lockout accidentali. In produzione, il modo corretto è avere una sessione secondaria pronta o un accesso console out-of-band, soprattutto su VPS e server remoti.

sudo ufw enable

Dopo l’attivazione, lo stato deve mostrare il firewall attivo e le regole caricate. Il comando seguente è il controllo minimo da fare subito dopo.

sudo ufw status verbose

Un output sano mostra Status: active, la policy di default e le eccezioni ammesse. Se non vedi la tua regola SSH, fermati: non proseguire con ulteriori modifiche finché non hai confermato la raggiungibilità remota.

Aprire i servizi web senza sovraesporre il server

Per un web server classico, apri solo le porte necessarie. Se il nodo serve HTTP e HTTPS, le regole tipiche sono 80/tcp e 443/tcp. Se il server ospita solo un reverse proxy frontale, non aprire porte applicative interne verso Internet: quelle devono restare dietro rete privata o loopback.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Se l’host ospita anche un pannello di controllo, un database o una coda, la regola giusta non è “aprire la porta e sperare”. Devi definire l’accesso per sorgente, rete o interfaccia. Esempio: MySQL ascolta solo sulla rete interna o su localhost; esporlo all’esterno è quasi sempre una cattiva idea.

Regole per singolo IP o subnet

Per limitare una porta a una subnet fidata, usa la forma con from. È la scelta più pulita quando hai una VPN aziendale o un range di amministrazione stabile.

sudo ufw allow from 192.0.2.0/24 to any port 3306 proto tcp

Questo tipo di regola è molto più difendibile di un semplice allow 3306/tcp. Se qualcuno sbaglia un bind su MySQL o PostgreSQL, il firewall continua a contenere il danno.

Servizi applicativi e profili UFW

UFW permette di usare profili applicativi definiti in /etc/ufw/applications.d/. È utile quando vuoi dare un nome semantico a una regola, per esempio Nginx Full o OpenSSH. Il vantaggio non è estetico: è operatività. In una lista di regole, leggere un nome riconoscibile è più veloce che interpretare numeri di porta sparsi.

sudo ufw app list
sudo ufw app info "Nginx Full"

Se il profilo non esiste, puoi sempre usare la porta esplicita. Però, se gestisci più server uguali, conviene standardizzare i profili in modo che le regole siano comprensibili anche mesi dopo. La manutenzione reale inizia quando devi fare troubleshooting a freddo su un sistema che non hai toccato da tempo.

Logging: utile, ma non sempre a livello alto

Attivare il logging aiuta a capire cosa viene bloccato, ma non va usato come sostituto dell’osservabilità applicativa. Un livello troppo verboso genera rumore e può aumentare il volume dei log senza aggiungere informazione utile. In pratica: abilitalo, osserva, poi decidi il livello.

sudo ufw logging medium

I log di UFW finiscono tipicamente nel journal o in file come /var/log/ufw.log, a seconda della configurazione di rsyslog e della distribuzione. Cerca eventi di deny, soprattutto se una porta che dovrebbe essere esposta non risponde. Se il problema è un timeout, il log del firewall ti dice se il pacchetto è stato bloccato o se il problema è più a monte.

sudo tail -f /var/log/ufw.log

Controllare che le regole siano realmente applicate

Una regola presente in configurazione non è utile se non è stata applicata o se un altro layer la sovrascrive. Il controllo minimo deve includere stato, numerazione delle regole e test di connessione reale.

sudo ufw status numbered
sudo ss -tulpn | grep -E ':22|:80|:443'

Il primo comando ti permette anche di cancellare regole in modo preciso, usando il numero. Il secondo conferma che il servizio sta davvero ascoltando. È un punto spesso trascurato: aprire la porta sul firewall non fa comparire il servizio se il demone è fermo o bindato solo su localhost.

Disabilitare, modificare e rimuovere regole in modo sicuro

Quando devi cambiare una regola, lavora con il minimo impatto. Se una regola è sbagliata, elimina solo quella e sostituiscila con la variante corretta. Evita di fare reset su sistemi remoti salvo che tu abbia console di emergenza e un piano di rollback già pronto.

sudo ufw status numbered
sudo ufw delete 3

Se devi disabilitare temporaneamente UFW per diagnosi, sappi cosa stai facendo: stai ampliando il blast radius del sistema esposto. In quel caso, il controllo accessi deve essere compensato da un’altra barriera, per esempio security group cloud, ACL di rete o accesso solo da VPN. La disattivazione completa è una misura diagnostica, non una soluzione.

sudo ufw disable

Dopo il test, riattiva il firewall e verifica che il set di regole sia tornato coerente. Se il server è in produzione, annota la finestra e il motivo della disattivazione: senza traccia operativa, il rischio è lasciare il sistema aperto più del necessario.

Integrazione con IPv6

Su Debian moderno IPv6 non va trattato come un optional decorativo. Se il server ha un indirizzo v6 raggiungibile, le regole devono essere coerenti anche lì. UFW può gestire IPv6, ma devi verificare che l’opzione sia abilitata nel file di configurazione.

grep '^IPV6=' /etc/default/ufw

Se trovi IPV6=yes, UFW applica regole anche a IPv6. Se è disabilitato e il server ha connettività v6, stai lasciando un varco laterale. Questo è uno dei problemi più sottovalutati: tutto sembra blindato in IPv4, poi il servizio resta esposto in IPv6.

UFW dietro cloud firewall, NAT o reverse proxy

In ambienti cloud, UFW non è l’unico filtro. Di solito ci sono security group, firewall del provider, NAT, load balancer e reverse proxy. La regola utile è questa: il traffico deve essere autorizzato in ogni punto della catena dove viene filtrato. Se il provider blocca tutto, UFW non vedrà nulla. Se UFW blocca, il traffico si fermerà comunque sull’host.

Quando un servizio non risponde, il debug corretto segue i layer: DNS, edge, origin, app, database, storage. UFW sta tra edge e origin, quindi se la porta è chiusa o filtrata devi vedere deny nel log o assenza di ascolto. Se invece il problema è applicativo, il firewall non c’entra e devi guardare i log del servizio.

Backup della configurazione e rollback

Prima di cambiare più regole insieme, esporta o copia la configurazione corrente. UFW salva la logica in file sotto /etc/ufw/, con i file principali in user.rules e user6.rules. Un backup semplice è spesso sufficiente per un rollback rapido.

sudo cp -a /etc/ufw /root/backup-ufw-$(date +%F)

Se qualcosa va storto, puoi ripristinare i file salvati e riavviare UFW. Il rollback va testato in una finestra controllata, non improvvisato al buio. Su sistemi remoti, la presenza di console seriale, IPMI o accesso provider è la differenza tra una modifica sicura e una potenziale esclusione.

sudo ufw disable
sudo cp -a /root/backup-ufw-2024-01-01/* /etc/ufw/
sudo ufw enable

Checklist operativa per Debian 10 e 11

La sequenza che funziona meglio in pratica è questa: osserva, apri SSH, imposta la policy, abilita UFW, apri i servizi necessari, verifica dall’esterno, poi rifinisci con regole per sorgente e logging. Saltare un passaggio non accelera davvero: sposta solo il problema più avanti.

1. Controlla porte in ascolto con ss -tulpn.
2. Verifica se UFW è già attivo con ufw status verbose.
3. Consenti SSH prima di abilitare il firewall.
4. Imposta deny incoming e allow outgoing.
5. Abilita UFW e conferma lo stato.
6. Apri solo le porte necessarie per i servizi esposti.
7. Limita per IP o subnet quando possibile.
8. Controlla anche IPv6 se il server lo usa.
9. Testa dall’esterno con curl, nc o una sessione SSH separata.
10. Salva backup prima di modifiche più ampie.

In sintesi operativa: UFW su Debian 10 e 11 è semplice da usare, ma richiede disciplina. Il suo valore non sta nel nascondere la complessità, sta nel renderla gestibile. Se lavori con un criterio di minimo privilegio, osservi i log e verifichi ogni cambio dall’esterno, il firewall diventa uno strumento affidabile invece che un rischio aggiuntivo.