nftables

1. Contexto histórico e normativo

O nftables foi apresentado no Linux 3.13 (2014) pelo próprio projeto netfilter como evolução oficial do iptables. Ele não é uma ferramenta concorrente, mas a reescrita do subsistema de filtragem para resolver limitações arquiteturais acumuladas ao longo de duas décadas. As principais motivações foram: unificar IPv4, IPv6, ARP e bridge em uma única sintaxe; eliminar a duplicação de código entre iptables, ip6tables, arptables e ebtables; e permitir atualização atômica de rulesets, evitando janelas de inconsistência.

Embora o iptables continue amplamente usado, o nftables é o padrão recomendado para novas implantações. Distribuições modernas como Debian (a partir da versão 10) e Red Hat/CentOS (a partir da versão 8) já usam o backend nftables por baixo do comando iptables (via iptables-nft). Para ISPs que estão construindo novos servidores ou migrando infraestrutura, adotar nftables nativamente é o caminho mais alinhado com o futuro do projeto.

2. Arquitetura e diferenças para iptables

O nftables mantém o mesmo modelo de hooks no kernel (prerouting, input, forward, output, postrouting), mas substitui as múltiplas tabelas fixas do iptables por uma hierarquia flexível: o administrador cria tabelas e chains conforme a necessidade.

• Sintaxe unificada — uma única linguagem para IPv4, IPv6, ARP e bridge.
• Expressões avançadas nativas — concatenação, maps, vetores, operações bitwise.
• Atualização atômica — o ruleset é substituído como um todo, sem estados intermediários.
• Melhor desempenho — menos overhead de kernel para rulesets grandes.

3. Instalação

apt update
apt install nftables

systemctl enable nftables
nft --version

Em distribuições que já usam iptables-nft como backend, instalar o pacote nftables dá acesso à sintaxe nativa (nft) para configuração direta.

4. Conceitos — table, chain, rule

No nftables, tabelas e chains são criadas pelo administrador — não há estruturas pré-definidas. A família inet permite que uma mesma tabela/chain processe IPv4 e IPv6 simultaneamente.

# Criar tabela (família: ip, ip6, inet, arp, bridge, netdev)
nft add table inet filter

# Criar chain com hook e política padrão
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Adicionar regra
nft add rule inet filter input tcp dport 22 ip saddr 10.10.0.0/24 accept

5. Ruleset real — servidor RADIUS/NOC

O mesmo cenário do exemplo iptables, agora em arquivo declarativo (/etc/nftables.conf):

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept

        udp dport 1812 ip saddr 10.0.0.0/24 accept
        udp dport 1813 ip saddr 10.0.0.0/24 accept
        udp dport 3799 ip saddr 10.0.0.0/24 accept

        tcp dport 2200 ip saddr 10.10.0.0/24 accept

        log prefix "NFT-DROP: " level info
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

# Aplicar
nft -f /etc/nftables.conf

6. Sets — substituindo o ipset

No iptables, listas grandes de IPs exigiam o ipset como ferramenta separada. No nftables, sets são nativos e podem ser atualizados dinamicamente:

table inet filter {
    set bloqueados {
        type ipv4_addr
        flags interval
        elements = { 198.51.100.0/24, 203.0.113.5 }
    }

    chain input {
        ip saddr @bloqueados drop
    }
}

# Adicionar IP dinamicamente (ex.: integração com honeypot)
nft add element inet filter bloqueados { 192.0.2.99 }

Útil para automação: scripts de detecção (ex.: honeypot) podem adicionar IPs atacantes ao set sem reiniciar o ruleset.

7. Migrando de iptables

# Traduzir regra individual
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Saída: nft add rule ip filter INPUT tcp dport 22 counter accept

# Traduzir ruleset completo
iptables-restore-translate -f /etc/iptables/rules.v4 > /etc/nftables-migrado.conf

A tradução automática é ponto de partida — sempre revisar o resultado antes de aplicar em produção.

8. Substituição atômica de ruleset

nft -f arquivo.conf aplica o ruleset inteiro de forma atômica — ou todas as regras novas entram, ou nada muda. Elimina a janela de inconsistência do iptables clássico, onde regras eram aplicadas sequencialmente.

9. Verificação e persistência

# Listar ruleset ativo
nft list ruleset

# Validar sintaxe sem aplicar
nft -c -f /etc/nftables.conf

# Persistência — /etc/nftables.conf carregado pelo systemd no boot
systemctl is-enabled nftables

10. Monitoramento e métricas

Os contadores de regras podem ser consultados e integrados a ferramentas como Zabbix ou PRTG. Exemplo de health check:

#!/bin/bash
# check_nftables.sh
if nft list ruleset | grep -q "policy drop"; then
  echo "OK: firewall ativo"
  exit 0
else
  echo "CRITICAL: firewall sem política de drop"
  exit 2
fi

11. Dimensionamento e performance

O nftables é altamente eficiente — um ruleset com dezenas de milhares de regras pode ser processado com impacto mínimo em hardware modesto (2 vCPUs). Sets nativos reduzem drasticamente o custo de lookup em listas grandes, comparado ao iptables com ipset externo.

12. Backup e recuperação

O backup do firewall é simples e deve ser incluído na estratégia de backup 3‑2‑1‑1‑0:

• Arquivo — /etc/nftables.conf (regras completas).
• Restauração — recriar o arquivo e executar nft -f /etc/nftables.conf.
• Automatize com restic ou Borg.

13. Comparativo com iptables

14. Troubleshooting

15. Glossário

16. Referências

• Projeto netfilter/nftables — documentação oficial (wiki.nftables.org, netfilter.org).
• Páginas relacionadas: iptables, pfSense.

Conteúdo técnico independente, baseado em conhecimento consolidado e estável da ferramenta. Nenhum trecho é cópia literal de fonte de terceiro.