Como recuperar de regras ufw quebradas

Voltar a aceder primeiro

Se o ufw bloqueou o acesso ao seu VPS, a forma de voltar a entrar é utilizar a consola do fornecedor ou o modo de recuperação, porque não existe uma correção baseada em SSH depois de a regra de bloqueio estar ativa. O kernel descarta o seu pacote antes de o sshd o receber. Por isso, não há nada a que possa ligar-se nem nada que possa corrigir pela rede. Abra a consola no painel de controlo do fornecedor, inicie sessão nessa linha de comandos e execute um comando.

sudo ufw disable

Deverá ver Firewall stopped and disabled on system startup. As novas ligações SSH funcionam novamente ao fim de um ou dois segundos. Nada do que configurou é perdido: disable remove as regras do kernel e escreve ENABLED=no em /etc/ufw/ufw.conf, enquanto as suas regras permanecem no disco em /etc/ufw/user.rules, à espera do próximo ufw enable.

Não reinicie o sistema esperando que isso resolva o problema. O ufw inicia automaticamente no arranque, por isso ENABLED=yes faz com que o mesmo conjunto de regras seja carregado novamente antes de a rede estar ativa. Reiniciar não altera nada num bloqueio causado pelo ufw.

O console precisa de uma palavra-passe que pode não ter

O console web (VNC ou serial) é um teclado ligado à máquina. Não é um caminho de rede, por isso nenhuma regra de firewall o pode bloquear. No entanto, precisa de um início de sessão local. É aqui que as configurações que permitem apenas chaves falham: se nunca definiu uma palavra-passe para o seu utilizador sudo e o início de sessão de root estiver bloqueado, o console mostra uma linha de comandos à qual não consegue responder. Defina essa palavra-passe agora, enquanto ainda tem SSH: sudo passwd yourname. A maioria dos painéis também permite repor a palavra-passe de root, o que normalmente obriga a reiniciar o servidor.

Se o console não puder ser utilizado, arranque o sistema de recuperação do fornecedor. Este sistema executa um sistema operativo separado com o seu disco desmontado, para que possa desativar o ufw a partir do exterior.

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

Execute primeiro lsblk, porque a partição root nem sempre é /dev/vda1. Reinicie no sistema normal. O ufw continuará desativado até o ativar manualmente.

A sequência mínima de recuperação

Siga esta ordem. Os primeiros quatro passos são seguros. O passo seguinte não é.

1. sudo ufw disable para descarregar as regras e recuperar o acesso.
2. sudo ufw show added para mostrar as regras adicionadas, sob a forma dos comandos que as adicionaram. Isto funciona enquanto o ufw está inativo, ao contrário de ufw status.
3. sudo sshd -T | grep -i '^port' para confirmar em que porta o sshd está realmente a escutar. O comando mostra port 22, exceto se essa porta tiver sido alterada.
4. sudo ufw allow 22/tcp, usando a sua porta real, para que a próxima ativação não repita o bloqueio de acesso.
5. sudo ufw enable, agendando primeiro uma reversão. Essa instrução aparece mais abaixo nesta página.

O que o reset do ufw realmente faz

ufw reset é o último recurso, não o primeiro passo. Desativa o firewall, faz uma cópia de segurança de cada ficheiro de regras e repõe os valores predefinidos para bloquear as ligações de entrada e permitir as ligações de saída. Apresenta uma linha de cópia de segurança por ficheiro:

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

Depois de um reset, não existem regras de permissão. Por isso, execute-o a partir da consola, e não através de SSH, e adicione a regra de SSH antes de voltar a ativar o firewall. Essas cópias de segurança são ficheiros de texto simples. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 mostra quais eram as regras antigas. É assim que pode reconstruir um conjunto de regras que não pretendia eliminar.

Onde o ufw mantém as regras

Ler os ficheiros é mais fiável do que tentar lembrar-se da configuração. Cinco caminhos contêm todo o estado:

• /etc/ufw/user.rules e /etc/ufw/user6.rules: as regras que adicionou, pela ordem em que são avaliadas.
• /etc/ufw/before.rules e /etc/ufw/after.rules, além das variantes 6: a estrutura que o ufw coloca à volta das suas regras, incluindo a aceitação de ligações estabelecidas e as regras de loopback.
• /etc/default/ufw: as políticas predefinidas e o interruptor IPV6.
• /etc/ufw/ufw.conf: ENABLED e o nível de log.
• /var/log/ufw.log: o que foi bloqueado depois de ativar o log.

O ufw grava uma cópia com data e hora de um ficheiro antes de o reescrever. Por isso, ls /etc/ufw/ fica preenchido com nomes como user.rules.20260813_101500. Esse é o histórico para desfazer alterações. Vale a pena consultá-lo antes de começar a reverter configurações.

Para ver o que está carregado no kernel, em vez do que está no disco, use sudo ufw show raw, ou sudo iptables -S e sudo ip6tables -S. No Ubuntu 22.04 e 24.04, esses comandos usam as versões baseadas em nft. Por isso, sudo nft list ruleset apresenta as mesmas regras com a sintaxe mais recente.

Por que ativar o ufw encerrou a minha sessão SSH?

A política de entrada predefinida é deny. Ativar o ufw sem uma regra para a porta SSH bloqueia todas as novas ligações. O ufw avisa sobre isto: Command may disrupt existing ssh connections. Proceed with operation (y|n)? Responder a y sem uma regra allow para SSH configurada é a causa mais comum de todos os problemas descritos nesta página.

A parte confusa é o atraso. /etc/ufw/before.rules aceita pacotes no estado ESTABLISHED,RELATED antes de aplicar as suas próprias regras, por isso a sessão usada para executar o comando continua a funcionar normalmente. O bloqueio só aparece na ligação seguinte, que pode ocorrer horas mais tarde. Nessa altura, a alteração da firewall já não parece estar relacionada. Abra sempre uma segunda sessão SSH e confirme que funciona antes de fechar a primeira.

Por que apt e o DNS deixaram de funcionar depois de uma alteração na política?

sudo ufw default deny outgoing bloqueia as consultas DNS (domain name system) de saída e o tráfego HTTP de saída. Por isso, a resolução de nomes deixa de funcionar e as atualizações de pacotes param. apt update informa Temporary failure resolving 'archive.ubuntu.com'. O SSH de entrada continua a funcionar porque as respostas correspondentes estão no estado ESTABLISHED e passam pelas regras do framework. Isso faz o firewall parecer inocente, embora seja a causa.

Se quiser uma política de negação de tráfego de saída, permita o que a máquina realmente precisa:

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

Sem a última regra, o relógio fica atrasado. Um relógio incorreto impede a validação dos certificados TLS (transport layer security), e curl começa a falhar por causa das datas, não das portas. Esse sintoma aparece vários dias depois da alteração. Por isso, a negação de tráfego de saída é uma política para máquinas que você monitoriza, não para uma máquina configurada uma única vez.

Por que a minha regra do ufw nunca corresponde?

O ufw avalia as regras do utilizador pela ordem definida e para na primeira correspondência. Uma deny adicionada depois de uma allow abrangente nunca é aplicada, porque a regra de permissão já decidiu o destino do pacote. Apresente a ordem com números e insira a regra na posição necessária.

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 apresenta as regras que seriam gravadas e não altera nada. Essa é a forma segura de consultar uma regra antes de a ativar.

Existe outra armadilha nos perfis de aplicação. sudo ufw allow OpenSSH utiliza o perfil em /etc/ufw/applications.d/openssh-server, e esse perfil corresponde à porta 22. Se o sshd escutar na porta 2222, a regra abre uma porta que não está a ser utilizada e pode bloquear o acesso ao servidor, embora o conjunto de regras pareça correto. Depois de alterar a porta, utilize o número da porta. O resto da sintaxe está explicado em os fundamentos da firewall ufw para um VPS.

Por que as regras IPv4 não explicam o que vejo?

Porque metade do tráfego não usa IPv4. O Ubuntu inclui IPV6=yes em /etc/default/ufw, e o ufw mantém depois um conjunto de regras IPv6 paralelo em /etc/ufw/user6.rules. Uma regra escrita com um endereço IPv4, como ufw allow from 203.0.113.10 to any port 22, não cria nenhuma regra IPv6. Se o seu VPS tiver um registo AAAA, o cliente preferir IPv6 e a ligação exceder o tempo limite, enquanto ufw status mostrar uma regra que parece correta, teste a diferença com ssh -4 user@host e ssh -6 user@host. Se o primeiro funcionar e o segundo não, a falha está no conjunto de regras IPv6.

O caso inverso é pior para a segurança. Com IPV6=no, o ufw não gere ip6tables, pelo que a política IPv6 permanece com o valor predefinido ACCEPT do kernel. Uma porta que considera fechada responde no respetivo endereço IPv6, e nenhum comando do ufw a mencionará. Verifique com sudo ip6tables -S e ss -tlnp, e leia como o ufw gere as portas IPv6 para obter a explicação completa.

Por que uma porta do Docker está aberta quando o ufw a bloqueia?

O Docker publica uma porta escrevendo regras DNAT (tradução de endereços de rede de destino) na tabela nat e inserindo a sua própria cadeia em FORWARD. As regras do ufw ficam no caminho INPUT. O tráfego destinado a um contentor é encaminhado, em vez de ser entregue ao host, por isso nunca chega à cadeia onde está a regra de bloqueio. docker run -p 5432:5432 fica acessível a partir da Internet com o ufw ativo e a bloquear tudo.

sudo iptables -t nat -S DOCKER

A correção mais simples é publicar a porta na interface de loopback: -p 127.0.0.1:5432:5432 associa o lado do host a 127.0.0.1, e nenhum sistema externo consegue alcançá-la, independentemente da configuração do ufw. Publicação de portas do Docker contornando o ufw aborda os casos em que o serviço precisa de ser público.

Agende o rollback antes de aplicar a regra

Este é o hábito que torna o trabalho com firewalls recuperável. Antes de qualquer alteração de risco, agende a reversão. Se a alteração bloquear o seu acesso, a máquina recupera automaticamente em cinco minutos e não precisa de abrir a consola.

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

systemd apresenta Running timer as unit: ufw-rollback.timer. Agora faça a alteração. Se ainda conseguir abrir uma nova sessão SSH depois disso, cancele o rollback:

sudo systemctl stop ufw-rollback.timer

Se não conseguir abrir essa sessão, aguarde. O ufw é desativado automaticamente e a próxima tentativa estabelece a ligação. O truque clássico shutdown -r +5 não funciona com o ufw, porque o ufw carrega novamente o mesmo conjunto de regras durante o arranque.

Mantenha uma segunda forma de acesso

• Inicie sessão uma vez no painel do provedor, antes de precisar dele, e confirme que a palavra-passe funciona. Uma consola que nunca testou não é uma cópia de segurança.
• Mantenha um segundo utilizador sudo com a sua própria chave, para que um ficheiro authorized_keys danificado não elimine o seu acesso.
• Verifique se o provedor executa uma firewall de rede no painel, separada do ufw. Ela bloqueia as mesmas portas, e o ufw status nunca fará referência a ela.
• Não faça de ufw allow from <your home address> a sua única regra SSH se esse endereço for dinâmico. O provedor altera-o durante a noite, e ficará sem acesso.

A altura mais económica para fazer tudo isto é num servidor novo, juntamente com as restantes tarefas de configuração em os primeiros dez minutos num VPS novo.

Recusado ou expirado indica qual camada falhou

Connection refused significa que um pacote chegou ao servidor e que algo enviou um reset TCP de volta. O caminho de rede está correto, portanto o sshd está parado ou está a escutar noutra porta. Raramente um firewall é a causa, porque o ufw descarta por predefinição em vez de rejeitar.

Connection timed out significa que não voltou nenhuma resposta. Essa é a assinatura de um descarte: ufw, um firewall de rede do fornecedor ou um endereço incorreto. Interpretar corretamente estes dois erros poupa uma hora de tentativas, e a diferença entre conexão recusada e expirada analisa os casos restantes.

Ative o registo antes da próxima alteração

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

Um pacote bloqueado aparece assim:

[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 com o seu próprio endereço em SRC= prova que é o ufw que está a bloquear o acesso, e não a rede nem o sshd. Numa imagem mínima sem rsyslog, não existe /var/log/ufw.log, e as mesmas linhas vêm de sudo journalctl -k | grep UFW. O ufw limita a frequência das próprias regras de registo, por isso a ausência de uma linha não prova que um pacote foi permitido.

Se encontrar regras que nunca adicionou

Um conjunto de regras que mudou sozinho não é um problema da firewall. Alguém com acesso root escreveu essas regras. Execute sudo grep ufw /var/log/auth.log para ver que comandos sudo foram executados e em que conta. Depois, execute last para consultar os logins ocorridos perto desse momento. Se as contas não corresponderem a ninguém que conheça, pare de depurar a firewall e siga uma lista de verificação para um VPS comprometido. Reativar uma firewall num sistema controlado por outra pessoa apenas oculta o problema.

Monte novamente

Depois de identificar a causa, ative novamente o ufw de uma forma que impeça a repetição do bloqueio. Permita a porta SSH efetiva, agende o rollback, ative o firewall e, em seguida, abra uma sessão SSH nova a partir de outro terminal para confirmar que a ligação funciona. Só depois de essa nova sessão estar estabelecida deve fechar a sessão em que está a trabalhar. Mantenha o registo ativo durante um dia, porque o log mostra o que se esqueceu de permitir muito mais rapidamente do que a leitura de user.rules.

FAQ

O ufw disable elimina as minhas regras?

Não. disable descarrega o conjunto de regras do kernel e grava ENABLED=no em /etc/ufw/ufw.conf. As suas regras permanecem em /etc/ufw/user.rules e /etc/ufw/user6.rules, e sudo ufw show added apresenta-as enquanto a firewall está inativa. ufw reset é o comando que as limpa e cria primeiro uma cópia de segurança de cada ficheiro, apresentando uma linha como Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Reiniciar o meu VPS desfaz um bloqueio causado pelo ufw?

Não. O ufw inicia no boot a partir de ENABLED=yes em /etc/ufw/ufw.conf. Por isso, as mesmas regras são carregadas antes de a rede arrancar e o acesso volta a ficar bloqueado. Reiniciar só ajuda depois de desligar o ufw ou depois de editar esse ficheiro a partir do rescue mode, com o disco montado. Use a consola do fornecedor e execute sudo ufw disable aí.

Porque é que o meu contentor Docker fica acessível quando o ufw bloqueia a porta?

O Docker escreve as suas próprias regras DNAT e FORWARD para cada porta publicada. Esse tráfego é encaminhado para o contentor, em vez de ser entregue ao host. Por isso, nunca passa pela cadeia INPUT, onde está a regra deny do ufw. Publique na interface de loopback com -p 127.0.0.1:5432:5432 quando a porta se destinar apenas ao host. Consulte o que o Docker instalou com sudo iptables -t nat -S DOCKER.

Não tenho a palavra-passe da consola nem rescue mode. Quais são as minhas opções?

As opções restantes dependem do fornecedor: repor a palavra-passe a partir do painel de controlo, o que normalmente reinicia o servidor, ou ligar o disco a outra instância para poder editar /etc/ufw/ufw.conf a partir daí. Contacte o suporte antes de reconstruir o servidor, porque a reconstrução destrói os dados nele armazenados. Depois de recuperar o acesso, execute sudo passwd yourname e teste uma vez o início de sessão na consola. Assim, o próximo bloqueio demora apenas dois minutos a resolver.