Configuração de Firewall Linux para servidor:
política default-deny, iptables UFW e Fail2ban

iptables e nftables são as ferramentas de firewall integradas no kernel Linux — extremamente poderosas mas com sintaxe complexa e propensa a erros. UFW (Uncomplicated Firewall) é uma interface simplificada sobre iptables e nftables, ideal para servidores Ubuntu e Debian onde a maioria das regras são diretas. ConfigServer Security & Firewall (CSF) é uma solução mais completa orientada para servidores de hosting: tem interface web, deteção de login failures, integração com cPanel/WHM e funcionalidades avançadas de bloqueio. Para um VPS simples com Nginx e WordPress, UFW chega. Para um servidor de hosting com múltiplas contas, CSF é o mais indicado.

Política default-deny significa que todo o tráfego de entrada é bloqueado por padrão, a menos que exista uma regra explícita que o permita. É o oposto de default-allow, onde tudo entra exceto o que está explicitamente bloqueado. Para qualquer servidor de produção, default-deny é o princípio correto: abrimos apenas as portas estritamente necessárias — 80 e 443 para web, SSH numa porta personalizada, portas de email se aplicável — e bloqueamos absolutamente todo o resto. Um servidor sem esta política tem centenas de portas abertas desnecessariamente, o que aumenta drasticamente a superfície de ataque.

O firewall estático é como um guarda permanente nas portas do servidor: bloqueia ou permite tráfego com base em regras fixas. Fail2ban é um guarda dinâmico que monitoriza os logs em tempo real e bloqueia automaticamente IPs que demonstram comportamento suspeito — múltiplas tentativas de login SSH falhadas, ataques de brute force ao WordPress, scans de portas repetidos. Sem Fail2ban, um IP malicioso pode tentar acesso indefinidamente mesmo com boas regras de firewall. Juntos, cobrem ameaças estáticas e dinâmicas de forma complementar.

Geo-blocking bloqueia todo o tráfego originado em determinados países com base em listas de IPs georreferenciados. Compensa implementar quando os logs mostram volumes anormalmente altos de tentativas de ataque vindas de países específicos e o serviço não tem utilizadores legítimos nessas regiões. Não é uma medida de segurança infalível — VPNs e proxies ultrapassam facilmente o geo-blocking — mas reduz significativamente o ruído de ataques automatizados, alivia os logs e diminui a carga sobre o Fail2ban. É uma medida de redução de superfície, não de segurança absoluta.

O SSH corre por padrão na porta 22, e essa porta é varrida constantemente por bots automáticos em busca de servidores acessíveis. Mudar para uma porta não padrão — como 22022 ou outra à escolha — não substitui uma boa política de segurança, mas elimina praticamente toda a atividade de scanning automatizado. O resultado imediato é visível nos logs: de centenas de tentativas por hora para praticamente zero. Combinado com autenticação por chave pública e Fail2ban, o risco de acesso não autorizado por SSH desce para níveis muito próximos de zero.

O impacto na performance de um firewall bem configurado é negligenciável em servidores modernos. A filtragem de pacotes no kernel Linux é extremamente eficiente. O único cenário onde a firewall pode afetar performance é com rulsets muito extensos (centenas de milhares de regras) ou com funcionalidades de Deep Packet Inspection ativas — o que está fora do âmbito de uma configuração standard. Para a esmagadora maioria dos servidores VPS e dedicados, a firewall não é um bottleneck.

Entregamos documentação completa de todas as regras aplicadas, com explicação do propósito de cada uma. Sempre que é adicionado um novo serviço ao servidor — um novo porto de aplicação, um serviço de monitorização, um acesso de terceiro — as regras precisam de ser atualizadas. Fazemos isso como parte do serviço de gestão ou em pedido avulso. Também fazemos revisões periódicas das regras para remover entradas desatualizadas e ajustar ao estado atual do servidor.