Nftables no Linux, verifique as regras antes de abrir uma porta

Um porto parece fechado do lado de fora, então acabamos procurando do lado do aplicativo ou do roteador. Antes de modificar qualquer coisa, verifique as regras realmente carregadas pelo nftables. O arquivo /etc/nftables.conf pode ser diferente do estado ativo, e um firewall local por si só não explica todo o trajeto da rede.

Esse método permite ler o ruleset, identificar a cadeia que trata o tráfego de entrada e testar uma modificação sem perder uma sessão SSH. Mantenha uma segunda conexão aberta se você estiver intervenindo remotamente.

Comece lendo o firewall carregado

O seguinte comando não altera nada. Ele exibe as tabelas, as cadeias, as regras e os contadores eventualmente presentes no núcleo:

sudo nft list ruleset

Se a saída for longa, liste primeiro as tabelas e, em seguida, foque na que lhe interessa:

sudo nft list tables
sudo nft list table inet filter

A família inet pode conter regras IPv4 e IPv6. Uma tabela também pode pertencer a ip, ip6, bridge ou netdev. Não substitua uma regra IPv6 por uma regra IPv4 na suposição de que o problema está resolvido.

Em uma tabela de filtragem, procure principalmente uma cadeia base com type filter hook input. É ela que recebe o tráfego destinado à máquina. Sua linha policy drop significa que os pacotes que não encontram nenhuma regra accept serão rejeitados.

Para ver os identificadores das regras, úteis se você precisar remover uma regra específica mais tarde, adicione -a:

sudo nft -a list chain inet filter input

Não confunda input, forward e output. Um servidor que recebe uma conexão SSH geralmente utiliza input. Uma máquina que roteia tráfego para outro host pode bloquear o pacote em forward. Um aplicativo que sai para a Internet passa por output.

Verifique o porto e a ordem das regras

As regras de uma cadeia são avaliadas na ordem. Uma regra de rejeição colocada antes da autorização do porto vence. Procure o protocolo, o porto e o estado da conexão:

sudo nft list chain inet filter input
sudo ss -lntup

Para SSH, uma regra esperada geralmente parece com tcp dport 22 accept. O porto pode ser diferente se o daemon estiver escutando em outro lugar. A saída de ss -lntup permite verificar se um programa realmente está escutando no porto e no endereço esperados. Um firewall aberto não torna disponível um serviço parado.

Veja também as regras ct state established,related accept e a interface loopback iif lo accept. Elas evitam quebrar as respostas a conexões já estabelecidas e as trocas locais. Se o ruleset contiver contadores, compare-os antes e depois de um teste de conexão para saber qual regra vê o tráfego.

Uma recusa pode ficar fora da máquina: grupo de segurança em nuvem, roteador, redirecionamento NAT, VLAN, firewall empresarial ou serviço vinculado apenas a 127.0.0.1. A partir de outra máquina, teste o porto com nc -vz endereco_do_servidor 22 ou com seu cliente SSH. No servidor, verifique a escuta com ss antes de mexer no nftables.

Identifique a regra que realmente bloqueia

Uma cadeia pode chamar outra cadeia com jump ou goto. A autorização do porto não é, portanto, necessariamente visível na primeira cadeia exibida. Leia novamente as chamadas de cadeias, os conjuntos nomeados e as regras que possuem um prefixo de registro. Uma regra do tipo counter drop ou reject colocada antes do porto muitas vezes explica o resultado.

Você pode seguir um pacote identificado com nft monitor trace, mas esse comando produz muitos dados em uma máquina ativa. Reserve-o para uma curta janela de diagnóstico e filtre o tráfego por endereço ou por porto em uma regra temporária. Em seguida, remova essa regra com seu handle exibido por nft -a list ruleset.

Não deixe uma regra de rastreamento ou de registro ampla em um servidor exposto. Ela pode encher os logs ou adicionar ruído ao diagnóstico. Para um primeiro controle, os contadores da cadeia e um teste a partir de outra máquina muitas vezes são suficientes.

O ruleset ativo e o arquivo persistente podem divergir

nft list ruleset lê o estado ativo. Ele não diz qual serviço carregou as regras, nem qual arquivo será recuperado na reinicialização. No Debian e no Ubuntu, verifique normalmente /etc/nftables.conf e o estado do serviço:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

Em uma distribuição que usa firewalld, UFW, Docker ou uma ferramenta de hospedagem, vários componentes podem escrever regras. Não copie um ruleset visto em um tutorial para /etc/nftables.conf se outro serviço já o gerencia. Identifique primeiro o gerente declarado pela sua máquina e releia as regras após seu recarregamento.

As regras adicionadas pela linha de comando muitas vezes desaparecem na próxima reinicialização ou no próximo recarregamento do serviço. Inversamente, modificar o arquivo persistente não muda nada até que ele seja carregado. Essa é precisamente a razão de se controlar os dois lados antes de concluir que um porto está aberto.

Salve e teste antes de aplicar uma regra

Conserve o estado atual antes de qualquer gravação. O arquivo de backup deve permanecer legível apenas pelo administrador:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Prepare a modificação em um arquivo temporário. nft -c verifica a sintaxe sem carregar as regras:

sudo nft -c -f /etc/nftables.conf

Essa verificação não prova que o novo ruleset permitirá sua entrada. Mantenha uma segunda sessão SSH conectada, aplique o arquivo na primeira, e depois tente uma nova conexão a partir de outro terminal. Se você perder o acesso, a sessão de backup permite restaurar o backup:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# Em caso de corte ou regra incorreta:
sudo nft -f /root/nftables-before-change.nft

Evite flush ruleset executado sozinho em um servidor remoto. Ele remove todas as regras atuais antes de você ter confirmado o arquivo de substituição. Carregue um arquivo completo e verificado, e então verifique o ruleset ativo imediatamente após.

Verificações após a modificação

Reinicie sudo nft list ruleset e verifique se a tabela e a cadeia esperadas ainda estão presentes.
Teste o serviço a partir de outra máquina com o porto realmente utilizado.
Verifique sudo ss -lntup se o porto continua inacessível.
Verifique o log do núcleo com sudo journalctl -k -b se suas regras registram os pacotes rejeitados.
Após uma reinicialização, verifique se o serviço nftables recarrega corretamente o arquivo persistente da sua distribuição.

Para casos simples, o artigo sobre UFW no Linux ainda é mais adequado. Se você precisar diagnosticar a disponibilidade de um serviço antes de modificar o firewall, verifique também os portos abertos com ss. A documentação nft(8) detalha as famílias, as cadeias e a opção -c.