Come recuperare da un ruleset ufw danneggiato

Rientrare per primi

Se ufw ti ha bloccato fuori dal tuo VPS, per rientrare devi usare la console del provider o la modalità di ripristino, perché dopo l'attivazione della regola di blocco non esiste una correzione basata su SSH. Il kernel scarta il pacchetto prima che sshd possa visualizzarlo, quindi non c'è alcun accesso a cui collegarsi né alcun problema da correggere tramite la rete. Apri la console nel pannello di controllo del provider, accedi dal prompt ed esegui un comando.

sudo ufw disable

Dovresti vedere Firewall stopped and disabled on system startup. Le nuove connessioni SSH funzionano di nuovo entro uno o due secondi. Non perdi nulla di ciò che hai configurato: disable scarica le regole dal kernel e scrive ENABLED=no in /etc/ufw/ufw.conf, mentre le regole restano salvate su disco in /etc/ufw/user.rules, in attesa del successivo ufw enable.

Non riavviare il server sperando di risolvere il problema. ufw si avvia automaticamente al boot, quindi ENABLED=yes carica di nuovo lo stesso set di regole prima che la rete sia disponibile. Un riavvio non modifica nulla quando ufw ha bloccato l'accesso.

La console richiede una password che potresti non avere

La console web (VNC o seriale) è una tastiera collegata alla macchina. Non usa la rete, quindi nessuna regola del firewall può bloccarla. Richiede però un accesso locale, ed è qui che le configurazioni con accesso basato solo su chiavi falliscono: se non hai mai impostato una password per il tuo utente sudo e l'accesso di root è bloccato, la console mostra un prompt a cui non puoi rispondere. Imposta subito la password, finché hai ancora SSH: sudo passwd yourname. La maggior parte dei pannelli consente anche di reimpostare la password di root; questa operazione normalmente forza un riavvio.

Se la console non è utilizzabile, avvia il sistema di ripristino del provider. Questo sistema esegue un sistema operativo separato con il disco non montato, quindi puoi disattivare ufw dall'esterno.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Esegui prima lsblk, perché la partizione root non è sempre /dev/vda1. Riavvia il sistema normale: ufw resterà disattivato finché non lo abiliterai manualmente.

La sequenza minima di ripristino

Procedere in questo ordine. I primi quattro passaggi sono sicuri. Il successivo non lo è.

1. sudo ufw disable per scaricare le regole e ripristinare l'accesso.
2. sudo ufw show added per visualizzare le regole aggiunte, sotto forma dei comandi che le hanno aggiunte. Funziona mentre ufw è inattivo, a differenza di ufw status.
3. sudo sshd -T | grep -i '^port' per confermare la porta su cui sshd è effettivamente in ascolto. Stampa port 22, a meno che non sia stata modificata.
4. sudo ufw allow 22/tcp, usando la porta effettiva, in modo che la successiva attivazione non causi nuovamente il blocco dell'accesso.
5. sudo ufw enable, dopo aver pianificato un rollback. La procedura è descritta più avanti in questa pagina.

Che cosa fa realmente ufw reset

ufw reset è l'ultima risorsa, non il primo intervento. Disabilita il firewall, crea una copia di backup di ogni file delle regole e ripristina i valori predefiniti per negare il traffico in ingresso e consentire quello in uscita. Stampa una riga di backup per ogni file:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Dopo un reset non sono presenti regole di autorizzazione. Esegui quindi il comando dalla console, non tramite SSH, e aggiungi la regola per SSH prima di riabilitare il firewall. Le copie di backup sono file di testo semplice. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 mostra quali erano le regole precedenti e consente di ricostruire un ruleset che non intendevi eliminare.

Dove ufw conserva le regole

Leggere i file è più affidabile che affidarsi alla memoria. Cinque percorsi contengono l'intero stato:

• /etc/ufw/user.rules e /etc/ufw/user6.rules: le regole aggiunte, nell'ordine in cui vengono valutate.
• /etc/ufw/before.rules e /etc/ufw/after.rules, incluse le varianti 6: il framework che ufw applica intorno alle regole, compresa l'accettazione delle connessioni già stabilite e le regole per il loopback.
• /etc/default/ufw: i criteri predefiniti e l'interruttore IPV6.
• /etc/ufw/ufw.conf: ENABLED e il livello di logging.
• /var/log/ufw.log: gli elementi bloccati, quando il logging è attivo.

Prima di riscrivere un file, ufw ne salva una copia con timestamp. Di conseguenza, ls /etc/ufw/ si riempie di nomi come user.rules.20260813_101500. Questa è la cronologia per annullare le modifiche. Conviene consultarla prima di ripristinare la configurazione.

Per vedere ciò che è caricato nel kernel anziché ciò che si trova su disco, usa sudo ufw show raw oppure sudo iptables -S e sudo ip6tables -S. In Ubuntu 22.04 e 24.04 questi comandi usano le versioni basate su nft. Di conseguenza, sudo nft list ruleset stampa le stesse regole con la sintassi più recente.

Perché l'attivazione di ufw ha interrotto la mia sessione SSH?

La policy predefinita per le connessioni in ingresso è deny. Se attivi ufw senza una regola per la porta SSH, blocchi tutte le nuove connessioni. ufw mostra un avviso: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Rispondere a y senza una regola allow per SSH è la causa più comune dei problemi descritti in questa pagina.

La parte fuorviante è il ritardo. /etc/ufw/before.rules accetta i pacchetti nello stato ESTABLISHED,RELATED prima di applicare le regole definite dall'utente, quindi la sessione da cui hai eseguito il comando continua a funzionare normalmente. Il blocco si verifica soltanto alla connessione successiva, anche dopo alcune ore; a quel punto la modifica al firewall non sembra più correlata. Apri sempre una seconda sessione SSH e verifica che funzioni prima di chiudere la prima.

Perché apt e il DNS hanno smesso di funzionare dopo una modifica della policy?

sudo ufw default deny outgoing blocca le query DNS (domain name system) in uscita e il traffico HTTP in uscita. La risoluzione dei nomi quindi non funziona più e gli aggiornamenti dei pacchetti si interrompono. apt update restituisce Temporary failure resolving 'archive.ubuntu.com'. SSH in ingresso continua a funzionare perché le relative risposte appartengono allo stato ESTABLISHED e attraversano le regole del framework. Il firewall sembra quindi estraneo al problema, ma ne è la causa.

Se vuoi una policy che neghi il traffico in uscita, abilita ciò di cui la macchina ha effettivamente bisogno:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Senza l'ultima regola, l'orologio perde precisione. Un orologio errato impedisce la convalida dei certificati TLS (transport layer security), quindi curl inizia a fallire per problemi relativi alle date e non alle porte. Il sintomo compare giorni dopo la modifica. Per questo motivo, negare il traffico in uscita è una policy adatta alle macchine che monitori, non a un sistema configurato una sola volta.

Perché la mia regola ufw non viene mai applicata?

ufw valuta le regole dell'utente nell'ordine definito e si ferma alla prima corrispondenza. Una deny aggiunta dopo una allow generale non viene mai applicata, perché la regola allow ha già determinato il trattamento del pacchetto. Visualizza l'ordine con i numeri, quindi inserisci la regola nella posizione necessaria.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp visualizza le regole che verrebbero scritte senza modificare nulla. È il metodo sicuro per leggere una regola prima di attivarla.

Un altro problema riguarda i profili delle applicazioni. sudo ufw allow OpenSSH usa il profilo in /etc/ufw/applications.d/openssh-server, che indica la porta 22. Se sshd è in ascolto sulla porta 2222, la regola apre una porta che nessun processo usa e può impedirti l'accesso, anche se il ruleset sembra corretto. Dopo aver spostato la porta, usa il relativo numero. Il resto della sintassi è descritto in le nozioni di base sul firewall ufw per un VPS.

Perché le regole IPv4 non spiegano ciò che vedo?

Perché metà del traffico non usa IPv4. Ubuntu installa IPV6=yes in /etc/default/ufw e ufw mantiene quindi un ruleset v6 parallelo in /etc/ufw/user6.rules. Una regola scritta con un indirizzo IPv4, ad esempio ufw allow from 203.0.113.10 to any port 22, non crea alcuna regola v6. Se il VPS dispone di un record AAAA, il client preferisce IPv6 e la connessione va in timeout, mentre ufw status mostra una regola apparentemente corretta. Verifica la differenza con ssh -4 user@host e ssh -6 user@host. Se il primo comando funziona e il secondo no, il problema è nel ruleset v6.

Il caso inverso è peggiore per la sicurezza. Con IPV6=no, ufw non gestisce affatto ip6tables e la policy v6 resta sul valore predefinito del kernel, ACCEPT. Una porta che ritieni chiusa risponde sull'indirizzo IPv6 e nessun comando ufw la mostrerà mai. Verifica con sudo ip6tables -S e ss -tlnp e consulta come ufw gestisce le porte IPv6 per il quadro completo.

Perché una porta Docker è aperta quando ufw la nega?

Docker pubblica una porta scrivendo regole DNAT (destination network address translation) nella tabella nat e inserendo una propria chain in FORWARD. Le regole di ufw si trovano nel percorso INPUT. Il traffico diretto a un container viene inoltrato, invece di essere consegnato all'host, quindi non raggiunge la chain in cui si trova la regola di negazione. docker run -p 5432:5432 è raggiungibile da Internet anche con ufw attivo e configurato per negare tutto.

sudo iptables -t nat -S DOCKER

La soluzione più semplice consiste nel pubblicare la porta sull'interfaccia di loopback: -p 127.0.0.1:5432:5432 associa il lato host a 127.0.0.1 e nessuna connessione esterna può raggiungerlo, indipendentemente dalla configurazione di ufw. Pubblicazione delle porte Docker aggirando ufw descrive i casi in cui il servizio deve essere pubblico.

Pianifica il rollback prima di applicare la regola

Questa è l'abitudine che rende gestibile il lavoro sul firewall. Prima di ogni modifica rischiosa, pianifica il ripristino. Se la modifica ti esclude dal server, la macchina ripristina automaticamente la configurazione dopo cinque minuti e non devi mai aprire la console.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd stampa Running timer as unit: ufw-rollback.timer. Ora applica la modifica. Se riesci ancora ad aprire una nuova sessione SSH, annulla il rollback:

sudo systemctl stop ufw-rollback.timer

Se non riesci ad aprire la sessione, attendi. ufw si disattiva automaticamente e il tentativo successivo riesce a connettersi. Il classico trucco di shutdown -r +5 non è utile con ufw, perché ufw ricarica lo stesso ruleset all'avvio.

Mantieni una seconda modalità di accesso

• Accedi una volta alla console del provider, prima di averne bisogno, e verifica che la password funzioni. Una console che non hai mai testato non è una modalità di accesso di emergenza.
• Mantieni un secondo utente sudo con una propria chiave, così un file authorized_keys danneggiato non interrompe completamente l'accesso.
• Verifica se il provider gestisce un firewall di rete dal pannello, separato da ufw. Blocca le stesse porte e ufw status non ne farà mai menzione.
• Non rendere ufw allow from <your home address> l'unica regola SSH se quell'indirizzo è dinamico. Il provider lo cambia durante la notte e perdi l'accesso.

Il momento meno costoso per fare tutto questo è subito dopo la creazione del server, insieme alle altre attività di configurazione descritte nei primi dieci minuti su un nuovo VPS.

Rifiutato o scaduto indicano quale livello ha generato il problema

Connection refused indica che un pacchetto ha raggiunto il server e che un componente ha restituito un reset TCP. Il percorso di rete funziona, quindi sshd è arrestato oppure è in ascolto su una porta diversa. Un firewall è raramente la causa, perché ufw per impostazione predefinita elimina i pacchetti invece di rifiutarli.

Connection timed out indica che non è tornata alcuna risposta. È il comportamento tipico di un pacchetto eliminato da ufw, da un firewall di rete del provider oppure causato da un indirizzo errato. Interpretare correttamente questi due errori evita un'ora di tentativi, mentre la differenza tra connessione rifiutata e connessione scaduta consente di analizzare i casi rimanenti.

Attiva il logging prima della modifica successiva

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

Un pacchetto bloccato appare in questo modo:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 con il proprio indirizzo in SRC= dimostra che a bloccare la connessione è ufw, non la rete e non sshd. In un'immagine minimale senza rsyslog non esiste /var/log/ufw.log e le stesse righe provengono da sudo journalctl -k | grep UFW. ufw limita la frequenza delle proprie regole di logging, quindi l'assenza di una riga non dimostra che un pacchetto sia stato consentito.

Se trovi regole che non hai mai aggiunto

Un ruleset modificato autonomamente non indica un problema del firewall. Qualcuno con accesso a root lo ha scritto. Esegui sudo grep ufw /var/log/auth.log per vedere quali comandi sudo sono stati eseguiti e con quale account, quindi usa last per controllare gli accessi nell'intervallo corrispondente a quel timestamp. Se gli account non corrispondono a persone che conosci, interrompi il troubleshooting del firewall e segui una checklist per un VPS compromesso. Riattivare un firewall su un server controllato da terzi nasconde soltanto il problema.

Riattiva il firewall

Dopo aver individuato la causa, riattiva ufw in modo da evitare che il blocco si ripeta. Consenti la porta SSH effettivamente utilizzata, pianifica il rollback, abilita ufw, quindi apri una nuova sessione SSH da un altro terminale e verifica che la connessione riesca. Chiudi la sessione corrente solo dopo che la nuova sessione è attiva. Lascia la registrazione attiva per un giorno, perché il log mostra molto più rapidamente ciò che hai dimenticato di consentire rispetto alla lettura di user.rules.

FAQ

ufw disable elimina le mie regole?

No. disable scarica il ruleset dal kernel e scrive ENABLED=no in /etc/ufw/ufw.conf. Le regole restano in /etc/ufw/user.rules e /etc/ufw/user6.rules, mentre sudo ufw show added le elenca quando il firewall è inattivo. ufw reset è il comando che le elimina e prima crea una copia di backup di ogni file, visualizzando una riga come Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Il riavvio del mio VPS annulla un blocco causato da ufw?

No. ufw viene avviato al boot tramite ENABLED=yes in /etc/ufw/ufw.conf, quindi le stesse regole vengono caricate prima che la rete sia disponibile e l'accesso viene nuovamente bloccato. Un riavvio è utile solo dopo aver disattivato ufw oppure dopo aver modificato quel file dalla rescue mode con il disco montato. Usa la console del provider ed esegui sudo ufw disable da lì.

Perché il mio container Docker è raggiungibile quando ufw nega la porta?

Docker scrive le proprie regole DNAT e FORWARD per ogni porta pubblicata. Il traffico viene inoltrato al container invece di essere consegnato all'host, quindi non passa mai attraverso la catena INPUT in cui si trova la regola deny di ufw. Pubblica sulla loopback con -p 127.0.0.1:5432:5432 quando la porta serve solo all'host e controlla ciò che Docker ha installato con sudo iptables -t nat -S DOCKER.

Non ho una password per la console e non dispongo della rescue mode. Quali opzioni ho?

Le opzioni rimanenti dipendono dal provider: un reset della password dal pannello di controllo, che di solito riavvia il server, oppure il collegamento del disco a un'altra istanza per poter modificare /etc/ufw/ufw.conf da lì. Chiedi supporto prima di ricreare il server, perché la ricreazione elimina i dati presenti. Dopo aver recuperato l'accesso, esegui sudo passwd yourname e prova una volta l'accesso alla console, così il prossimo blocco ti costerà due minuti.