1. Motivação
Um firewall não serve apenas para bloquear acessos: ele organiza o caminho que cada pacote percorre. Funciona como o “controle de fronteira” da rede, definindo o que pode entrar, o que pode sair, o que só pode atravessar e o que deve ser descartado imediatamente.
Entender essa lógica é essencial para projetar ambientes seguros e previsíveis, especialmente quando você precisa isolar serviços, publicar aplicações ou segmentar usuários.
2. Fluxo do kernel (diagrama)
O firewall segue a ordem interna do Netfilter, que define onde e como cada pacote é tratado:
PREROUTING → INPUT → FORWARD → OUTPUT → POSTROUTING
- PREROUTING: antes do kernel decidir o destino; onde ocorre DNAT.
- INPUT: pacotes cujo destino final é o próprio host.
- FORWARD: pacotes que só estão passando pelo host (roteador).
- OUTPUT: pacotes originados localmente.
- POSTROUTING: depois do roteamento; onde ocorre SNAT/MASQUERADE.
3. Conceitos
Firewalls modernos são stateful — eles acompanham o estado de cada conexão, evitando que você escreva regras inutilmente repetitivas. O conntrack mantém uma tabela com o estado atual de cada fluxo, e as regras podem filtrar com base nela.
Os principais estados são:
- NEW: Pacote que inicia uma conexão nova.
- ESTABLISHED: Pacote pertencente a uma conexão já estabelecida.
- RELATED: Fluxos auxiliares, como conexões de dados no FTP ou ICMP gerado por outra sessão.
- INVALID: Pacotes sem contexto válido (checksum errado, sem associação).
- UNTRACKED: Pacotes deliberadamente excluídos do mecanismo de estado.
Esses poucos estados já permitem construir políticas robustas, reduzindo o risco de bloquear respostas legítimas.
4. Regras essenciais
A política recomendada consiste em adotar uma postura restritiva por padrão (default-deny), permitindo apenas o tráfego declarado como necessário. As regras de exceção devem incluir o tratamento adequado para fluxos estabelecidos e relacionados, garantindo que respostas legítimas circulem sem interrupções.
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Essa base funciona em servidores, roteadores e appliances dedicados: elimina ruído, traz clareza e reduz a superfície de ataque.
5. Implementando DMZ, LAN e convidados
Antes de escrever regras, é essencial entender o papel de cada rede:
LAN interna
Rede de confiança maior, onde ficam hosts corporativos e serviços não expostos. Normalmente, só ela acessa a DMZ ou Internet com menos restrições.Rede de convidados
Segmento isolado para dispositivos não confiáveis — visitantes, IoT, equipamentos pessoais. Essa rede deve alcançar apenas a Internet, nunca a LAN.-
DMZ (zona desmilitarizada)
Segmento intermediário criado para hospedar serviços que precisam ser acessados de fora, mas que não devem expor a rede interna caso sejam comprometidos.
A DMZ não é “meio LAN, meio Internet” — é uma rede própria, projetada com regras específicas:- Entrada da Internet → acesso estritamente filtrado
- Acesso da LAN → permitido apenas ao serviço necessário (ex.: SSH restrito aos admins)
- Saída da DMZ → limitada; servidores comprometidos não devem alcançar a LAN
Em termos práticos, se você tem servidores web e de e-mail públicos, eles vão para a DMZ. A LAN nunca confia cegamente neles. A rede de convidados, menos ainda.
Regras típicas:
# Internet → DMZ (somente portas públicas)
iptables -A FORWARD -i eth_wan -o eth_dmz -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i eth_wan -o eth_dmz -p tcp --dport 443 -j ACCEPT
# DMZ → LAN (geralmente bloqueado)
iptables -A FORWARD -i eth_dmz -o eth_lan -j DROP
# LAN → DMZ (administração controlada)
iptables -A FORWARD -i eth_lan -o eth_dmz -p tcp --dport 22 -j ACCEPT
# Convidados → Internet (permitido)
iptables -A FORWARD -i eth_guest -o eth_wan -j ACCEPT
# Convidados → LAN/DMZ (bloqueado)
iptables -A FORWARD -i eth_guest -o eth_lan -j DROP
iptables -A FORWARD -i eth_guest -o eth_dmz -j DROP
A ideia é simples: cada rede tem um “perímetro” com intenções diferentes, e o firewall é quem materializa essas intenções.
6. Logging
Logs ajudam a depurar políticas complexas, mas devem ser usados com cuidado para evitar spam:
iptables -A INPUT -j LOG --log-prefix "FIREWALL_DROP: "
É útil adicionar essa regra em pontos estratégicos: logo antes do DROP final, ou na chain que filtra tráfego crítico.
7. Testes
As ferramentas de diagnóstico dão mais contexto do que as regras em si:
nmap entre redes
Mostra portas expostas, rotas funcionando e filtragem consistente. Se algo aparece “filtered”, talvez o firewall esteja bloqueando silenciosamente.tcpdump
Revela se o pacote chega na interface certa, o que muitas vezes resolve dúvidas antes mesmo de olhar o firewall.
tcpdump -i eth_dmz host 10.10.0.10ajuda a confirmar se o tráfego está entrando e saindo pelo caminho planejado.
8. Erros comuns
Alguns clássicos:
Regras na chain errada: Tentar filtrar pacotes destinados a outro host na chain INPUT, quando deveria ser FORWARD.
Ordem incorreta: Uma regra muito permissiva acima do bloqueio anula toda a camada de segurança.
Falta de rota de retorno: Pacote entra, mas não consegue voltar — o firewall parece o culpado, mas o problema está no roteamento.
Log excessivo: Um LOG mal colocado cria um fluxo infinito de mensagens, tornando o servidor lento e mascarando problemas reais.
Saber identificar esses padrões economiza horas em diagnósticos.
9. Conclusão
Um firewall eficiente não é uma lista interminável de regras, mas um conjunto de decisões claras sobre como cada rede deve se comportar. Entender o fluxo do kernel, o papel das chains e a lógica stateful são os pilares para montar políticas consistentes — da simples proteção de um servidor pessoal até o isolamento de uma DMZ inteira. Organizando as regras com propósito, você constrói redes mais seguras, previsíveis e fáceis de manter.
Top comments (0)