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

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

Este 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 intervindo remotamente.

Comece lendo o firewall carregado

O seguinte comando não altera nada. Ele exibe as tabelas, cadeias, regras e contadores eventuais atualmente presentes no kernel:

sudo nft list ruleset

Se a saída for longa, liste primeiro as tabelas e, em seguida, direcione-se para aquela 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 assumindo que o problema está resolvido.

Em uma tabela de filtragem, procure especialmente uma cadeia básica 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 encontrarem nenhuma regra accept serão rejeitados.

Para ver os identificadores de 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 normalmente usa input. Uma máquina que roteia tráfego para outro host pode bloquear o pacote em forward. Uma aplicação 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 ganha. 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 frequentemente se 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 endereço esperados. Um firewall aberto não torna disponível um serviço parado.

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

Uma rejeição pode permanecer fora da máquina: grupo de segurança em nuvem, roteador, redirecionamento NAT, VLAN, firewall corporativo ou serviço que se relaciona apenas com 127.0.0.1. De outro terminal, teste o porto com nc -vz endereço_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, portanto, não é 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 frequentemente explica o resultado.

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

Não deixe uma regra de rastreamento ou registro amplo 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 de outro terminal 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á retomado no reinício. Em Debian e Ubuntu, normalmente veja /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 passa pelo 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. Primeiro, identifique o gerenciador declarado pela sua máquina e releia as regras após seu recarregamento.

As regras adicionadas em linha de comando frequentemente desaparecem na próxima reinicialização ou no próximo recarregamento do serviço. Inversamente, modificar o arquivo persistente não muda nada enquanto ele não for carregado. Esta é precisamente a razão para 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 então a modificação em um arquivo temporário. nft -c verifica a sintaxe sem carregar as regras:

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

Esta verificação não prova que o novo ruleset permitirá a 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 interrupção ou regra errônea:
sudo nft -f /root/nftables-before-change.nft

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

Controles após a modificação

Relance 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 continuar inacessível.
Verifique o log do kernel com sudo journalctl -k -b se suas regras registrarem os pacotes rejeitados.
Após um reinício, verifique se o serviço nftables recarrega corretamente o arquivo persistente da sua distribuição.

Para casos simples, o artigo sobre UFW no Linux é 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, cadeias e a opção -c.