As boas práticas de regras de firewall vão muito além de simplesmente bloquear tráfego malicioso - trata-se de escrever regras precisas o suficiente para barrar atacantes sem derrubar os serviços que o seu time usa no dia a dia. A maioria das configurações incorretas segue padrões previsíveis: regras amplas demais, tráfego de saída completamente descontrolado ou políticas de permissão total que eram "temporárias" e nunca foram revisadas. Este guia aborda os erros reais que sysadmins e desenvolvedores cometem, e as configurações padrão mais inteligentes que devem substituí-los.
Índice
Regras de Entrada e Saída Explicadas
Todo firewall avalia o tráfego em duas direções, e tratar as duas como uma única preocupação é onde muitas equipes erram.
Regras de entrada controlam o tráfego que chega ao seu servidor ou rede vindo de fora. Quando alguém se conecta ao seu servidor web na porta 80 ou 443, isso é tráfego de entrada. Quando um atacante sonda a porta 22 em busca de um login SSH, isso também é tráfego de entrada. Suas regras de entrada determinam se essas conexões são permitidas ou não.
Regras de saída controlam o tráfego que sai do seu servidor. Um servidor comprometido se comunicando com um host de comando e controle, um aplicativo mal configurado vazando dados para um endpoint externo, ou um container baixando pacotes de um registry inesperado - tudo isso é tráfego de saída. A maioria das equipes configura a entrada com cuidado e deixa a saída completamente aberta, o que é um erro grave.
Em ambientes de nuvem como os Security Groups da AWS, as regras de entrada e saída são configuradas separadamente. No Linux com
iptables
ou
nftables
, elas correspondem às chains INPUT e OUTPUT. No Windows Firewall, estão literalmente rotuladas como "Regras de Entrada" e "Regras de Saída" na interface gráfica. O conceito é universal - a implementação varia conforme a plataforma.
Erros Comuns de Configuração de Firewall
1. Permitir 0.0.0.0/0 em Portas Sensíveis
Esse é o padrão mais perigoso em configuração de firewall. Permitir que toda a internet acesse portas como as listadas abaixo é uma receita para o desastre:
| Porta | Serviço | Risco com 0.0.0.0/0 |
|---|---|---|
| 22 | SSH | Ataques de força bruta, credential stuffing, exploração de vulnerabilidades do SSH |
| 3306 | MySQL | Tentativas de acesso direto ao banco de dados, SQL injection em nível de rede, exfiltração de dados |
| 5432 | PostgreSQL | Mesmo risco do MySQL - portas de banco de dados públicas são varridas constantemente por ferramentas automatizadas |
| 27017 | MongoDB | Historicamente responsável por vazamentos massivos de dados quando deixado aberto sem autenticação |
| 3389 | RDP | Vetor de entrega de ransomware, força bruta, exploits no estilo BlueKeep |
O caso do MongoDB merece destaque especial. Dezenas de milhares de bancos de dados foram apagados e mantidos como reféns entre 2017 e 2019 porque instâncias do MongoDB estavam publicamente acessíveis sem nenhuma autenticação. O verificador de blacklist de IP é um lembrete útil de que o monitoramento de exposição é essencial - porque "ninguém vai encontrar isso" não é uma estratégia de segurança.
2. Ignorar o Tráfego de Saída (Egress)
Deixar o tráfego de saída completamente irrestrito significa que um host comprometido pode se comunicar livremente com a infraestrutura do atacante, exfiltrar dados ou participar de uma botnet. Um servidor executando um aplicativo web não tem nenhum motivo legítimo para iniciar conexões de saída para IPs arbitrários em portas arbitrárias. Restringir o egress apenas ao que é necessário - seu resolver de DNS, seu repositório de pacotes, seus endpoints de API - limita drasticamente o que um atacante pode fazer mesmo depois de obter acesso.
3. Erros na Ordem das Regras
Considere esta configuração de iptables:
# BAD: This allow-all rule fires first
-A INPUT -j ACCEPT
-A INPUT -s 203.0.113.0/24 -p tcp --dport 22 -j DROPA regra DROP para SSH daquela sub-rede é completamente inútil porque todos os pacotes atingem a regra ACCEPT primeiro. A correção é colocar as regras específicas antes das gerais, e colocar a negação padrão no final.
4. Intervalos de Portas Excessivamente Amplos
Regras como "permitir TCP 1024-65535 de entrada" são comuns em configurações legadas e praticamente inúteis como controle de segurança. Se o seu aplicativo usa a porta 8080, escreva uma regra para a porta 8080. Se você precisa de um intervalo para FTP passivo, documente exatamente qual intervalo o seu servidor está configurado para usar e restrinja a esse. Intervalos amplos existem porque alguém não quis pesquisar a porta correta - não porque eram necessários.
5. Manter Regras de Permissão Total por Padrão
Provedores de nuvem frequentemente adotam regras permissivas por padrão durante o provisionamento. O security group padrão da AWS permite todo o tráfego de saída. Novas VMs do Azure recebem uma regra de entrada "AllowAzureLoadBalancerInBound" que é aceitável, mas a regra de saída padrão permite tudo. Esses padrões são pensados para facilitar o início rápido, não para produção. No momento em que você mover uma carga de trabalho para produção, revise e restrinja cada regra padrão.
6. Sem Logging nas Regras de Negação
Um firewall que descarta tráfego silenciosamente não te diz nada. Sem logging nas suas regras de negação, você não consegue distinguir entre um atacante sondando suas portas e um serviço legítimo mal configurado. Ative o logging pelo menos nas suas regras de negação padrão para ter uma linha de base do que está sendo bloqueado.
Configurações Padrão Mais Inteligentes que Funcionam de Verdade
A estrutura de política de segurança de rede a seguir funciona na maioria dos ambientes e oferece um ponto de partida sólido para ajustar, em vez de uma bagunça permissiva que você precisa limpar depois.
Regras de Entrada
- Padrão: NEGAR toda entrada. Comece sem nada permitido e abra explicitamente apenas o que for necessário.
- Porta 80 (HTTP) e 443 (HTTPS): Permitir de 0.0.0.0/0 somente se for um servidor web público. Se for apenas interno, restrinja ao seu intervalo de IPs internos.
- Porta 22 (SSH): Permitir SOMENTE de endereços IP específicos ou blocos CIDR - o IP do seu escritório, o nó de saída da sua VPN, o seu bastion host. Nunca de 0.0.0.0/0.
- Porta 3389 (RDP): Igual ao SSH - apenas IPs específicos, ou melhor ainda, coloque atrás de uma VPN e não exponha à internet de forma alguma.
- Porta 3306 (MySQL) e 5432 (PostgreSQL): Permitir apenas dos IPs privados dos seus servidores de aplicação. Essas portas nunca devem ser acessíveis pela internet pública.
- ICMP (ping): Permitir de intervalos confiáveis para diagnóstico. Bloqueá-lo completamente torna a resolução de problemas dolorosa sem nenhum benefício de segurança significativo.
Regras de Saída
- Porta 53 (DNS): Permitir apenas para os seus resolvers de DNS designados (por exemplo, o resolver interno da sua VPC ou um IP específico como 1.1.1.1).
- Porta 80 e 443: Permitir para destinos conhecidos - seus repositórios de pacotes, suas APIs, seu CDN. Se você conseguir enumerá-los, faça isso.
- Porta 25 (SMTP): Bloquear SMTP de saída a menos que este servidor seja explicitamente um servidor de e-mail. Servidores comprometidos enviando spam são um indicador comum de violação.
- Todo o resto: NEGAR por padrão.
Aqui está um exemplo mínimo de iptables aplicando essa abordagem para um servidor web:
# Flush existing rules
iptables -F
# Default policies: deny all inbound and outbound
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Allow established/related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Inbound: HTTP and HTTPS from anywhere (public web server)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Inbound: SSH only from your office IP
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.50 -j ACCEPT
# Outbound: DNS to internal resolver
iptables -A OUTPUT -p udp --dport 53 -d 10.0.0.2 -j ACCEPT
# Outbound: HTTPS for package updates
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
# Log dropped inbound packets
iptables -A INPUT -j LOG --log-prefix "DROPPED-IN: " --log-level 4Para entender melhor como o filtro de portas funciona no nível do protocolo, a especificação TCP na RFC 793 explica exatamente o que acontece durante o estabelecimento de conexão - que é o que o seu firewall está interceptando ao avaliar regras contra pacotes de entrada.
Regras Separadas para Dev, Staging e Prod
Um dos hábitos mais subestimados de configuração de firewall é tratar cada ambiente como distinto, com seu próprio conjunto de regras. Usar o mesmo security group ou a mesma política de firewall em dev e prod é como portas de debug "temporárias" acabam expostas em produção.
Uma forma prática de estruturar isso:
- Dev: Entrada mais permissiva a partir do intervalo de IPs da sua equipe. Portas 8080, 8443 e outras portas de desenvolvimento abertas. Portas de banco de dados acessíveis a partir das máquinas dos desenvolvedores. Logging opcional.
- Staging: Espelhe as regras de prod o máximo possível. O objetivo é detectar problemas relacionados ao firewall antes que cheguem à produção. Adicione acesso para os IPs da sua equipe de QA.
- Prod: Regras mais rígidas. Sem portas de debug. Sem acesso direto ao banco de dados de fora da sub-rede privada. Todas as regras de negação com logging ativo. SSH restrito a um bastion host ou VPN apenas.
Marque suas regras de firewall com o ambiente ao qual pertencem. Na AWS, use tags de recurso nos security groups. No Terraform ou outras ferramentas de IaC, use conjuntos de regras orientados por variáveis para que as regras de dev e prod compartilhem a mesma estrutura, mas com valores diferentes. Isso torna a auditoria muito mais fácil.
Você também pode usar nossa ferramenta de ping para verificar rapidamente se um host em um determinado ambiente está acessível no nível de rede antes de partir para verificações específicas de porta.
Verifique o que Está Realmente Exposto
Escrever regras de firewall é apenas metade do trabalho. A outra metade é confirmar que o que você pretendia bloquear está realmente bloqueado, e o que você pretendia permitir está realmente acessível. É aqui que muitas equipes pulam uma etapa e entregam sistemas mal configurados.
Após aplicar qualquer alteração na sua configuração de firewall, execute uma verificação de porta externa a partir de fora da sua rede. Isso simula o que um atacante veria - não o que o seu monitoramento interno acredita estar exposto.
O que verificar após cada alteração no firewall:
- Porta 22 (SSH): Deve aparecer como FECHADA ou TIMEOUT para qualquer IP que não esteja na sua lista de permissões.
- Porta 3306 (MySQL) e 5432 (PostgreSQL): Nunca devem aparecer como ABERTAS na internet pública.
- Porta 3389 (RDP): Deve estar FECHADA ou TIMEOUT, a menos que você a tenha exposto deliberadamente com restrições de IP.
- Porta 80 e 443: Devem estar ABERTAS em servidores web públicos.
- Portas de aplicação personalizadas: Verifique se correspondem à sua intenção - abertas onde necessário, fechadas em todos os outros lugares.
Você também pode usar nossa ferramenta de consulta DNS para confirmar que o hostname que você está testando resolve para o IP esperado antes de executar verificações de porta - útil quando lida com ambientes onde os registros DNS e os IPs reais dos servidores nem sempre coincidem.
Veja exatamente quais portas estão expostas após aplicar suas regras de firewall
Use nosso verificador de portas gratuito para testar se SSH (22), RDP (3389), MySQL (3306), PostgreSQL (5432) e outras portas sensíveis estão realmente abertas ou fechadas externamente - para confirmar que suas boas práticas de firewall estão funcionando como esperado, não apenas escritas corretamente.
Verifique Suas Portas Abertas →
Os Security Groups da AWS são essencialmente firewalls stateful vinculados a instâncias EC2 ou outros recursos. Eles funcionam com o mesmo princípio de regras de entrada e saída, mas são stateful por padrão - ou seja, se você permitir tráfego de entrada na porta 443, o tráfego de resposta é automaticamente permitido na saída sem uma regra separada. Firewalls stateless tradicionais como o iptables exigem regras explícitas em ambas as direções para cada conexão, a menos que você use rastreamento de conexão (conntrack). Os Security Groups também não suportam regras de negação - você só pode permitir tráfego, e tudo que não for explicitamente permitido é negado.
Bloquear ICMP completamente geralmente causa mais problemas do que resolve. O ping é usado para diagnósticos legítimos, e o ICMP também carrega mensagens de Path MTU Discovery que afetam o desempenho do TCP. Uma abordagem melhor é permitir ICMP de intervalos de IPs confiáveis (sua equipe, seu sistema de monitoramento) e bloqueá-lo de 0.0.0.0/0. Isso mantém seu servidor fora dos scanners casuais da internet enquanto preserva a capacidade de diagnóstico. Bloquear ICMP não esconde de forma significativa um servidor de atacantes determinados - varreduras TCP SYN funcionam perfeitamente sem respostas de ping.
Antes de aplicar qualquer regra de restrição de SSH, verifique se você tem um método de acesso alternativo - acesso ao console da nuvem (AWS EC2 Instance Connect, GCP Cloud Shell, Azure Serial Console), um console físico ou uma interface de gerenciamento out-of-band. Em seguida, adicione sua regra de permissão de IP específico para a porta 22 antes de aplicar a negação padrão. Teste a nova regra em uma sessão de terminal separada antes de fechar a conexão atual. Se o seu IP for dinâmico, considere usar uma VPN com um IP de saída estático em vez de permitir diretamente o IP da sua casa.
MySQL (3306) e PostgreSQL (5432) são varridos constantemente por ferramentas automatizadas em busca de bancos de dados expostos. Mesmo com senhas fortes, a exposição pública cria uma superfície de ataque desnecessária - bypasses de autenticação, vulnerabilidades zero-day e força bruta de credenciais tornam-se vetores de ataque viáveis. Os bancos de dados devem ser acessíveis apenas pelos IPs privados dos seus servidores de aplicação, nunca pela internet pública. Se você precisar de acesso remoto ao banco de dados para administração, roteie por uma VPN ou tunnel SSH em vez de abrir a porta do banco de dados publicamente.
No mínimo, audite as regras de firewall trimestralmente e após cada mudança significativa de infraestrutura - novos serviços implantados, saída de membros da equipe (as permissões de IP deles devem ser removidas), mudanças de arquitetura ou incidentes de segurança. Ferramentas automatizadas podem ajudar: o AWS Config pode sinalizar alterações em security groups, e ferramentas como a detecção de drift de estado do Terraform identificam alterações manuais não autorizadas. Também execute uma verificação de porta externa após cada auditoria para verificar se as regras correspondem à realidade. Regras que parecem corretas em um arquivo de configuração nem sempre se comportam como esperado após interações complexas entre elas.
Em ambientes Kubernetes e de containers, as network policies substituem as regras de firewall tradicionais para o tráfego leste-oeste (entre serviços). Os recursos NetworkPolicy do Kubernetes permitem definir quais pods podem se comunicar com quais, em quais portas. Para o tráfego norte-sul (externo ao cluster), aplicam-se os security groups do load balancer do provedor de nuvem ou as regras do ingress controller. O princípio fundamental é o mesmo: negar por padrão, permitir explicitamente. Ferramentas como Calico ou Cilium oferecem aplicação de políticas de rede mais granular do que a implementação padrão do Kubernetes.