Installare e configurare UFW su Debian 11 e 10

Su Debian 11 e 10, UFW ha senso quando vuoi una gestione pulita del firewall senza scrivere ogni regola a mano con nftables o iptables. Non sostituisce il modello di sicurezza dell’host, ma ti mette rapidamente in una posizione più ragionevole: politica di default restrittiva, porte esplicite, log essenziali e meno errori operativi.

La regola pratica è semplice: prima osservi quali servizi devono restare esposti, poi applichi le policy, infine verifichi da fuori macchina che nulla di critico si sia chiuso per errore. Su una macchina remota, il primo servizio da proteggere è sempre SSH: se sbagli qui, il rollback non è teorico, è obbligatorio.

UFW su Debian 11 e 10: cosa cambia davvero

Debian 10 e Debian 11 usano entrambe una base moderna e UFW si integra bene con il sottosistema firewall del kernel. La differenza operativa che conta è minima: il flusso di lavoro è praticamente identico. Cambiano più spesso il contesto del server e la versione dei servizi esposti che non UFW in sé.

UFW è un frontend: traduce regole leggibili in regole firewall effettive. Questo è comodo, ma non va dimenticato. Se trovi un comportamento inatteso, la verifica non si ferma a UFW: controlla anche lo stato del backend, il servizio attivo e l’ordine delle regole applicate.

Installazione pulita e verifica del pacchetto

La base è banale, ma conviene farla in modo controllato. Su una macchina già in produzione, prima verifica che SSH sia raggiungibile e che tu abbia accesso console o out-of-band se lavori da remoto.

Installa UFW con i pacchetti standard:

sudo apt update
sudo apt install ufw

Controlla che il pacchetto sia presente e che il binario risponda:

ufw --version
apt-cache policy ufw

L’output atteso è una versione installata e una candidate coerente con la release Debian in uso. Se il pacchetto non si installa, il problema non è UFW ma la connettività verso i repository, il mirror o la configurazione di APT.

Prima regola: non tagliare SSH

La sequenza sicura, su un host remoto, è sempre la stessa: autorizzi SSH prima di attivare il firewall. Se usi una porta standard, la regola è immediata; se usi una porta custom, devi dichiararla esplicitamente.

sudo ufw allow OpenSSH

Se il demone ascolta su una porta diversa, ad esempio 2222, usa la porta reale:

sudo ufw allow 2222/tcp

Verifica il servizio in ascolto prima di applicare la regola, così eviti di aprire una porta che non serve o di dimenticare quella giusta:

ss -tlnp | grep sshd

Se il comando non mostra nulla, non stai lavorando sul servizio che credi o SSH non è attivo. In quel caso fermati e chiudi il gap prima di procedere.

Policy di default: bloccare in ingresso, consentire in uscita

La configurazione più comune e sensata per un server esposto è negare tutto l’ingresso e lasciare libero l’output. È un’impostazione semplice, ma ha un effetto netto sulla superficie d’attacco.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Con queste policy, il server non accetta nuove connessioni in ingresso se non esplicitamente autorizzate. L’uscita resta libera, quindi aggiornamenti, query verso servizi esterni e chiamate applicative non vengono bloccati di default.

Se il tuo host ha requisiti particolari, ad esempio proxy inverso, mail server o servizi che devono parlare verso altri nodi su porte specifiche, la policy di uscita può essere irrigidita, ma solo dopo aver mappato il traffico reale. Farlo a occhi chiusi è un modo rapido per rompere aggiornamenti e integrazioni.

Abilitare UFW senza perdere l’accesso

Il momento delicato è l’attivazione. Prima controlla le regole correnti, poi abilita il firewall. UFW chiede conferma proprio perché un errore qui può isolarti dalla macchina.

sudo ufw status verbose
sudo ufw enable

Se vuoi evitare sorprese, fai un check immediato dopo l’attivazione:

sudo ufw status numbered

L’output deve mostrare lo stato active, le policy di default e le regole che hai autorizzato. Se SSH non compare, la prima verifica non è “riavviare tutto”, ma aprire una seconda sessione e testare la connessione prima di toccare altro.

Regole tipiche per web server, DNS e servizi comuni

Una volta impostata la base, apri solo ciò che serve davvero. Per un web server classico, le porte 80 e 443 sono le più frequenti. Per un server DNS autoritativo o ricorsivo, la situazione cambia e va valutata caso per caso: aprire 53 senza contesto può essere corretto oppure totalmente sbagliato.

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

Se ospiti un servizio SSH su porta non standard, un pannello admin o un endpoint applicativo interno, non usare aperture generiche. Meglio limitare per indirizzo sorgente quando possibile:

sudo ufw allow from 192.0.2.10 to any port 22 proto tcp

Questo approccio riduce l’esposizione inutile. È particolarmente utile per accessi amministrativi, interfacce di management e servizi che non devono essere raggiungibili dal mondo intero.

Limitare invece di aprire: utile contro brute force e rumore

Per SSH, UFW offre una modalità limit che riduce l’impatto di tentativi ripetuti. Non è una protezione completa contro un attacco serio, ma è una barriera sensata contro il rumore di base e i tentativi automatizzati più banali.

sudo ufw limit OpenSSH

La differenza rispetto a una semplice allow è operativa: i burst di connessioni vengono penalizzati. Se stai usando fail2ban o un sistema simile, le due cose si completano; non si sostituiscono.

Per capire se la limitazione è coerente con il tuo uso reale, osserva i log di accesso SSH e la frequenza delle connessioni amministrative. Se fai automazione pesante o molte sessioni parallele da IP fissi, la limitazione può diventare fastidiosa e va valutata con criterio.

Logging: poco ma utile

Attivare i log di UFW ha senso se vuoi capire cosa viene bloccato e perché, ma non serve trasformare il server in una macchina che produce rumore inutile. Il livello low è spesso il punto di partenza corretto.

sudo ufw logging low

I log finiscono tipicamente in `journalctl` o in `/var/log/ufw.log`, a seconda della configurazione di sistema. La verifica rapida è questa:

sudo journalctl -u ufw --no-pager
sudo tail -n 50 /var/log/ufw.log

Se il file non esiste, non è automaticamente un problema: su alcune configurazioni il logging passa dal journal o da rsyslog. Il punto è vedere eventi coerenti con le regole, non inseguire per forza un path specifico.

Regole numerate, cancellazione selettiva e ordine

Quando le regole crescono, devi sapere cosa c’è davvero in lista. UFW mostra le regole numerate e questo evita di cancellare quella sbagliata.

sudo ufw status numbered

Per rimuovere una regola specifica, usa il numero mostrato in output:

sudo ufw delete 3

Prima di farlo, valuta il blast radius: una regola errata su una macchina con traffico live può interrompere accessi amministrativi, health check, replica o servizi pubblici. Se hai dubbi, esporta lo stato corrente e conserva una traccia del prima:

sudo ufw status numbered > /root/ufw-rules-before.txt

Profili applicativi: quando usarli e quando no

UFW può usare i profili applicativi definiti nei file sotto `/etc/ufw/applications.d/`. È comodo per servizi noti, perché ti evita di ricordare la porta esatta ogni volta. Ma il profilo è utile solo se corrisponde davvero al servizio in ascolto.

sudo ufw app list
sudo ufw app info OpenSSH

Se un profilo non esiste o non descrive il servizio corretto, non forzarlo. In ambienti misti, con servizi custom o containerizzati, è spesso più chiaro aprire la porta esplicita e documentarla vicino alla configurazione dell’applicazione.

Integrazione con IPv6: non lasciarla a metà

Un errore classico è configurare UFW pensando solo a IPv4 e dimenticare IPv6. Se il sistema ha connettività IPv6 e il servizio ascolta anche lì, la regola incompleta produce comportamenti incoerenti: da una rete il servizio sembra chiuso, da un’altra continua a rispondere.

Controlla il file `/etc/default/ufw` e verifica la presenza di `IPV6=yes` quando IPv6 è realmente in uso:

grep '^IPV6' /etc/default/ufw

Dopo eventuali modifiche a quel file, ricarica il firewall con attenzione. Se disattivi IPv6 senza capire l’impatto, puoi rompere servizi dual-stack o accessi amministrativi che passano proprio da lì.

Verifica esterna: il test che conta davvero

Non basta leggere “active” nello stato di UFW. Devi verificare la raggiungibilità dal punto di vista del client. Per un web server, il test minimo è una richiesta HTTP e HTTPS dal tuo host di controllo.

curl -I http://tuo-dominio.tld
curl -I https://tuo-dominio.tld

Per SSH, la prova è una connessione reale da una rete autorizzata. Se stai lavorando su un server remoto, mantieni aperta la sessione attuale finché la nuova non è confermata. È la forma più semplice di rollback pratico.

Se qualcosa non torna, distingui subito il livello del problema: DNS, rete, firewall, servizio in ascolto o applicazione. UFW può bloccare, ma non può risolvere un demone fermo o un certificato scaduto.

Problemi frequenti e lettura rapida dei sintomi

Se dopo l’attivazione perdi l’accesso SSH, la causa più probabile è una regola mancante o una porta sbagliata. Se il server web risponde in locale ma non dall’esterno, il firewall è un candidato forte, ma va confermato con `curl` dal client e con `ss -tlnp` sul server.

Se i log non mostrano nulla, non significa che UFW non funzioni: potrebbe non esserci traffico bloccato oppure il livello di logging è troppo basso. Se invece vedi blocchi su porte che pensavi aperte, controlla l’ordine delle regole e l’eventuale presenza di policy più restrittive.

Quando il traffico entra da IPv6 ma non da IPv4, o viceversa, il problema spesso è una configurazione incompleta del dual stack. In questi casi la verifica deve sempre includere entrambe le famiglie di indirizzi.

Disabilitare UFW in modo sicuro e rollback

Se devi annullare temporaneamente la configurazione, non improvvisare. La disattivazione è semplice, ma va fatta solo se hai una ragione valida e un modo per ripristinare subito le regole corrette.

sudo ufw disable

Il rollback più pulito è riattivare le regole salvate in precedenza. Se hai esportato lo stato o hai una documentazione delle porte aperte, puoi ricostruire rapidamente la baseline. In ambienti gestiti bene, la configurazione del firewall va trattata come codice o comunque come asset versionato.

Assunzione: la macchina è Debian 10 o 11, con accesso amministrativo locale o remoto e servizi già identificati prima della chiusura delle porte.