Um conjunto mínimo de regras nftables para um único servidor

Objetivo

Expor apenas as portas que o servidor deve atender, tanto em IPv4 quanto em IPv6, num conjunto de regras que cabe numa tela e pode ser recarregado com segurança.

Pré-requisitos

Acesso root, o binário nft e a lista das portas que o host atende.

Passos

1. Escreva /etc/nftables.conf seguindo a estrutura do exemplo de servidor da wiki do nftables: flush ruleset e, em seguida, uma única table inet filter, de modo que um só conjunto de regras cubra as duas famílias de endereços.
2. Defina chain input { type filter hook input priority 0; policy drop; ... } e, nesta ordem: ct state vmap { established : accept, related : accept, invalid : drop }, iifname lo accept, meta l4proto { icmp, ipv6-icmp } accept (o ICMPv6 transporta o neighbour discovery; bloqueá-lo quebra o IPv6, por isso o exemplo da wiki aceita pelo menos os tipos nd-*) e, por fim, tcp dport { 22, 80, 443 } accept.
3. Adicione chain forward { type filter hook forward priority 0; policy drop; } somente se o host não fizer roteamento nem executar contêineres: o nft(8) afirma que um pacote só é aceito se nenhuma base chain o descartar, portanto uma chain forward com descarte também bloqueia o tráfego de bridge de um runtime de contêineres. Deixe output sem definição, o que equivale a aceitar.
4. Durante a depuração, termine a chain input com log prefix "nft-drop " counter drop.
5. Valide a sintaxe sem aplicar: nft -c -f /etc/nftables.conf.
6. Arme um rollback antes de carregar: systemd-run --on-active=120 nft flush ruleset agenda um flush para daqui a dois minutos (--on-active está documentado em systemd-run(1)). Carregue com nft -f /etc/nftables.conf, confirme que uma nova sessão SSH funciona e, depois, pare o timer transitório cujo nome de unidade o systemd-run exibiu.
7. Inspecione o estado ativo com nft list ruleset; o nft(8) afirma que essa saída pode ser usada como entrada para nft -f, de modo que também serve de backup.
8. Habilite o serviço nftables da distribuição para que o arquivo seja carregado na inicialização.

Resultado esperado

nft list ruleset mostra exatamente as chains pretendidas; uma varredura de portas vinda de fora mostra apenas as portas listadas; uma recarga com nft -f troca o conjunto de regras antigo pelo novo numa única operação (a "atomic rule replacement" da wiki), portanto não há nenhum instante sem regras, e as conexões existentes continuam correspondendo a ct state established.

Limites e base de verificação

O conjunto de regras não sabe qual processo escuta numa porta. Os runtimes de contêineres inserem suas próprias tabelas e prioridades; com rede em bridge, o tráfego para portas publicadas de contêineres costuma ser traduzido e encaminhado, em vez de entregue localmente, e por isso contorna esta chain input e passa pelo hook forward. Consulte a documentação de firewall do runtime antes de adicionar regras de forward e não misture o iptables legado com o nft. A sintaxe segue a wiki e o manual citados; não se afirma nenhuma medição de vazão ou de segurança.

Rollback para o conjunto de regras anterior, não para o vazio

Um flush ruleset agendado deixa o host sem nenhuma regra e remove tabelas das quais outros programas dependem. Salve primeiro o estado atual e arme, em vez disso, uma restauração:

nft list ruleset > /root/nft-before.conf
systemd-run --on-active=120 nft -f /root/nft-before.conf
nft -f /etc/nftables.conf

Confirme uma nova sessão SSH e, depois, pare o timer transitório. Pelo mesmo motivo, evite flush ruleset no arquivo de configuração em hosts que executam um runtime de contêineres: ele apaga as tabelas ip nat e ip filter do runtime, e as portas publicadas deixam de funcionar até que o runtime seja reiniciado. Faça flush apenas da sua própria tabela (table inet filter {} seguido de flush table inet filter), o que continua sendo atômico para essa tabela.