nftables no Ubuntu Server: firewall Linux passo a passo
O nftables é o firewall padrão do kernel Linux no Ubuntu Server desde a versão 20.10 e no Debian desde o Buster: mesmo quem nunca digitou nft já está rodando esse framework por baixo, porque o comando iptables hoje é só uma camada de tradução chamada iptables-nft. Este guia monta um firewall funcional do zero — tabelas, chains, regras persistentes e sets nomeados — sem depender do pacote iptables-persistent.
Por que escrever direto em nftables
Rodar iptables num Ubuntu 22.04 ou 24.04 não é mais nativo: o kernel só entende nftables, e o binário iptables traduz cada regra antes de aplicar. Isso funciona, mas custa duas coisas — desempenho em rulesets grandes (a tradução acontece regra por regra) e clareza, porque um firewall complexo fica ilegível quando IPv4 e IPv6 precisam de tabelas duplicadas.
O nftables resolve os dois pontos. A família inet cobre IPv4 e IPv6 na mesma tabela, o ruleset compila para bytecode e roda mais rápido sob carga, e sets nomeados substituem uma regra por IP por uma lista só, que você atualiza sem recarregar o firewall inteiro.
Antes de começar
Este guia assume um Ubuntu Server 22.04+ com acesso root via SSH e, de preferência, acesso ao console (KVM, iDRAC, iLO ou similar) para o caso de uma regra errada travar a sessão. Se o servidor já roda ufw ou iptables-persistent, desative um dos dois antes de continuar — os três sistemas escrevem no mesmo ruleset do kernel, e deixá-los ativos ao mesmo tempo gera regras duplicadas ou que se anulam no boot.
nft --version sudo systemctl status nftables dpkg -l | grep -E 'iptables-persistent|ufw'
Passo a passo: montando o ruleset
1. Instalar o pacote e remover o que conflita
O pacote nftables já vem instalado em imagens recentes do Ubuntu Server, mas vale confirmar. Se o iptables-persistent estiver presente, ele reaplica regras antigas no boot e disputa com o nftables — melhor tirá-lo do caminho.
sudo apt update sudo apt install -y nftables sudo systemctl disable --now netfilter-persistent 2>/dev/null sudo apt purge -y iptables-persistent 2>/dev/null
2. Escrever o ruleset em /etc/nftables.conf
O serviço nftables.service do Ubuntu já está configurado para carregar esse arquivo no boot — diferente do iptables, que exigia um pacote à parte só para persistir regras. Um ponto de projeto que evita erro comum: comece com policy drop na chain de entrada e libere só o que precisa, em vez de policy accept com regras de bloqueio soltas por cima.
#!/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
ct state invalid drop
ip protocol icmp icmp type echo-request limit rate 5/second accept
ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 5/second accept
tcp dport 22 ct state new limit rate 10/minute accept
tcp dport { 80, 443 } accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
O porquê de cada linha importa mais do que decorá-la. ct state invalid drop descarta pacotes malformados que não são nem conexão nova nem parte de uma sessão válida — sem essa linha, alguns ataques de fragmentação passam pelo filtro. O rate limit em tcp dport 22 não substitui o Fail2Ban, mas segura boa parte da varredura automatizada de força bruta antes mesmo de ela chegar ao serviço SSH. A chain forward com policy drop só importa se o servidor rotear tráfego de outras máquinas (um gateway, por exemplo) — num host comum ela fica vazia e inofensiva.
3. Validar antes de aplicar
O nft tem um modo de checagem que valida a sintaxe sem tocar no ruleset ativo. Rodar isso antes de aplicar remotamente evita derrubar a própria sessão SSH por causa de um erro de digitação.
sudo nft -c -f /etc/nftables.conf
4. Aplicar e habilitar no boot
sudo nft -f /etc/nftables.conf sudo nft list ruleset sudo systemctl enable --now nftables
5. Testar de uma segunda sessão
Nunca valide um firewall só pela sessão SSH que você já tem aberta — se a regra de entrada estiver errada, ela pode não derrubar a conexão existente (que já está em established) e esconder o problema. Abra uma segunda conexão em paralelo antes de fechar a primeira.
ssh -o ConnectTimeout=5 usuario@servidor curl -m 5 http://servidor
Sets nomeados: liberando IPs sem duplicar regras
Em iptables, liberar SSH para uma lista de IPs de administração significa uma regra por endereço. Em nftables, um set nomeado guarda a lista inteira e a regra referencia o conjunto — atualizar a lista não exige recarregar o ruleset.
table inet filter {
set admin_ips {
type ipv4_addr
elements = { 203.0.113.10, 198.51.100.20 }
}
chain input {
ip saddr @admin_ips tcp dport 22 accept
}
}
Para adicionar um IP novo sem recarregar nada:
sudo nft add element inet filter admin_ips { 203.0.113.30 }
Persistência, backup e rollback seguro
Antes de qualquer mudança grande no ruleset em produção, salve o estado atual. Se algo sair errado, aplicar o backup de volta é mais rápido que reconstruir a regra na memória.
sudo nft list ruleset > /root/nftables-backup-$(date +%F).nft # para reverter: sudo nft -f /root/nftables-backup-2026-09-10.nft
Cuidado com flush ruleset isolado: ele zera o firewall inteiro e, se o comando seguinte falhar por qualquer motivo, o servidor fica sem filtro nenhum até a próxima aplicação. É por isso que o passo de validação com -c vem antes de aplicar, e por isso vale manter acesso por console em mudanças remotas.
Perguntas frequentes
O nftables substitui completamente o iptables?
No kernel, sim — desde o Ubuntu 20.10 não existe mais o módulo iptables original rodando em paralelo. O comando iptables continua funcionando porque foi reescrito para traduzir para nftables por baixo, mas regras escritas nos dois formatos não se somam automaticamente: escolha um.
Preciso desativar o UFW antes de usar nftables direto?
Sim. O UFW hoje gera regras nftables por baixo dos panos; rodar UFW e um /etc/nftables.conf próprio ao mesmo tempo cria dois conjuntos de regras competindo. Desative um dos dois com ufw disable antes de aplicar o ruleset manual.
O nftables funciona com Docker?
O Docker manipula o firewall diretamente para o NAT dos containers e espera encontrar as chains dele intactas. Uma chain forward com policy drop pode bloquear tráfego de container — nesse caso, libere a interface docker0 (ou a bridge equivalente) explicitamente em vez de mexer na policy padrão do Docker.
Como registrar em log os pacotes bloqueados sem lotar o disco?
Adicione uma regra de log com limite de taxa antes do drop implícito, por exemplo limit rate 5/minute log prefix "nft-drop: ". Sem o limit rate, uma varredura de portas enche o /var/log em minutos.
Esse firewall substitui o FortiGate ou pfSense da borda?
Não. O nftables filtra o tráfego do próprio host — é a segunda camada de defesa, depois do firewall de borda. Servidor exposto à internet deve ter os dois: o appliance filtrando a borda da rede e o nftables filtrando o host individual.
Conclusão
O ruleset acima cobre o caso comum — SSH, HTTP/HTTPS, ICMP limitado e tudo mais bloqueado por padrão — mas a estrutura de tabelas, chains e sets é o que vale levar para qualquer firewall mais específico depois. Comece validando com -c, teste de uma segunda sessão antes de fechar a primeira, e mantenha backup do ruleset anterior antes de qualquer mudança grande. É a mesma disciplina que já vale para qualquer firewall de borda — só que aplicada ao host.
