Configuração de firewall é o conjunto de políticas, regras e procedimentos que determinam qual tráfego de rede é permitido ou bloqueado em um perímetro ou segmento de rede. Quando implementada corretamente — seguindo frameworks como NIST SP 800-41r1 e CIS Benchmarks for Network Devices — a configuração de firewall é a principal linha de defesa contra acesso não autorizado, exfiltração de dados e propagação lateral de ameaças dentro de uma infraestrutura corporativa.

O que é configuração de firewall e por que ela importa

Um firewall é um dispositivo ou software que inspeciona e filtra tráfego de rede entre segmentos com diferentes níveis de confiança. A configuração de firewall vai muito além de simplesmente bloquear portas: envolve a definição de política de segurança, segmentação de rede em zonas, controle de fluxo bidirecional (inbound e outbound), logging forense e integração com processos de resposta a incidentes.

Segundo o relatório Verizon DBIR, mais de 70% dos incidentes de violação de dados envolvem tráfego de rede que poderia ter sido bloqueado por controles de firewall adequadamente configurados. Organizações sem egress filtering, por exemplo, permitem que ransomware e trojans bancários estabeleçam canais de comando e controle (C2) para exfiltrar dados durante semanas ou meses sem detecção.

Política default-deny: o princípio fundamental

A base de qualquer configuração de firewall segura é a política default-deny (também chamada de implicit deny all). Nessa abordagem, todo o tráfego é bloqueado por padrão e apenas fluxos explicitamente aprovados são liberados. O contrário — default-permit — é um antipadrão que expõe serviços não intencionais sempre que um novo servidor ou aplicação é provisionado.

O CIS Benchmark for Cisco IOS e o NIST SP 800-41r1 definem default-deny como requisito de nível 1, ou seja, aplicável a qualquer organização independentemente de porte. Na prática, isso significa que a última regra do ruleset deve ser sempre:

  • deny ip any any log — bloqueia qualquer tráfego não matchado pelas regras anteriores e registra o evento para análise forense.

Regras permissivas devem ser o menor escopo possível: IP de origem específico, IP de destino específico, porta de destino específica e protocolo. Nunca use any em mais de uma dimensão simultaneamente.

Ordem de processamento das regras

Firewalls processam regras na ordem sequencial e param na primeira correspondência (first-match semantics). A ordem errada cria shadow rules — regras que nunca são alcançadas porque uma regra mais genérica acima já capturou o tráfego. A ordem recomendada pelo framework NIST é:

  1. Gerenciamento: permitir acesso SSH/HTTPS ao firewall somente de IPs administrativos (out-of-band management).
  2. Estados estabelecidos: permitir pacotes de retorno de conexões já estabelecidas (ESTABLISHED, RELATED) — reduz drasticamente o número de regras necessárias.
  3. Serviços específicos por zona: regras com menor escopo primeiro, maior escopo depois.
  4. Bloqueios explícitos: listas negras de IPs/ASNs maliciosos via threat intelligence feeds.
  5. Deny-all com log: regra final obrigatória.

Use ferramentas de rule analysis (como Tufin, AlgoSec ou recursos nativos de NGFW) para identificar regras em sombra, regras não utilizadas há mais de 90 dias e regras duplicadas.

Segmentação de rede e zonas de segurança

Uma das práticas mais eficazes para limitar o raio de impacto de um comprometimento é a segmentação em zonas. Cada zona representa um nível de confiança e os firewalls controlam o fluxo inter-zona:

Zona Descrição Nível de Confiança Exemplos de Ativos
Internet (Untrusted) Rede pública externa Zero —
DMZ Serviços com acesso público controlado Baixo Web servers, APIs públicas, mail relay
LAN corporativa Rede de usuários internos Médio Estações de trabalho, impressoras, VoIP
Servidores de aplicação Sistemas de negócio internos Médio-alto ERP, CRM, intranet
Banco de dados Dados estruturados críticos Alto PostgreSQL, Oracle, MySQL, MongoDB
Gerenciamento (OOB) Acesso administrativo a infraestrutura Alto Bastion hosts, consoles IPMI/iDRAC
Backup e recuperação Armazenamento offline/nearline Alto Tape libraries, NAS de backup

A comunicação entre a LAN e o banco de dados, por exemplo, deve passar obrigatoriamente pelo firewall e ser restrita às portas exatas dos servidores de aplicação autorizados. Nunca permita acesso direto de estações de usuário à zona de banco de dados.

Firewall stateful vs. stateless

A distinção entre filtragem stateful e stateless é crítica para escolher a tecnologia adequada ao ambiente:

  • Stateless (packet filter): avalia cada pacote individualmente com base em cabeçalhos (IP de origem/destino, porta, protocolo, flags TCP). Rápido e de baixo overhead, mas vulnerável a ataques de fragmentação de pacotes e spoofing de estados TCP. Usado em NACLs da AWS e em filtros de borda de alta velocidade (linha de 100 Gbps+).
  • Stateful (connection tracking): mantém tabela de estados de sessão e só permite pacotes que pertencem a conexões legítimas. Detecta ataques como SYN flood, session splicing e TCP sequence prediction. É o mínimo recomendado pelo NIST SP 800-41r1 para qualquer firewall perimetral corporativo.
  • NGFW (Next-Generation Firewall): inclui tudo do stateful mais DPI, App-ID, IPS embutido, inspeção TLS, filtro de URL e threat intelligence. Recomendado onde é necessário controle de aplicações SaaS, inspeção de tráfego cifrado ou políticas baseadas em identidade de usuário (integração com Active Directory via LDAP/Kerberos).

NGFW e inspeção de tráfego avançada

Firewalls de nova geração adicionam camadas de inteligência que firewalls tradicionais não possuem. As principais capacidades relevantes para configuração segura incluem:

  • App-ID: identifica a aplicação pelo comportamento do protocolo, não pela porta. Permite bloquear BitTorrent mesmo que ele use a porta 443, ou bloquear uploads ao Google Drive sem bloquear leituras.
  • SSL/TLS Inspection: descriptografa tráfego HTTPS para inspeção de malware e DLP. Requer implementação cuidadosa de PKI interna e gestão de exceções (categorias de saúde, financeiro, jurídico) para conformidade com LGPD.
  • IPS embutido: detecta e bloqueia exploração de vulnerabilidades conhecidas (CVEs) em tempo real, com base em assinaturas e análise comportamental. Reduz a janela de exposição entre publicação do CVE e aplicação do patch.
  • Threat Intelligence Feeds: bloqueio automático de IPs e domínios de C2 conhecidos com base em feeds como MISP, Palo Alto Unit 42 e Cisco Talos.

Egress filtering: o controle negligenciado

A maioria das organizações foca em regras de ingress (tráfego entrante) e negligencia o egress filtering (tráfego sainte). Esse erro permite que malware estabeleça canais de C2, que dados sejam exfiltrados via HTTP/S e que hosts comprometidos participem de ataques DDoS.

Um egress filtering eficaz inclui:

  • Forçar todo DNS interno a passar por resolvedores controlados (bloqueio de DNS over HTTPS externo não autorizado).
  • Bloquear conexões diretas de servidores de produção à internet — todo acesso externo deve passar por um proxy HTTP autenticado.
  • Restringir portas de saída a apenas as necessárias (80, 443, 587 para SMTP via relay autorizado).
  • Bloquear protocolos IRC, Tor (portas 9001/9050), BitTorrent e outros vetores de C2 conhecidos.
  • Implementar FQDN-based filtering em NGFWs para bloquear domínios DGA (Domain Generation Algorithm) dinamicamente.

Logging, monitoramento e retenção

Configuração de firewall sem logging adequado é ineficaz para fins de detecção e resposta. O NIST SP 800-92 (Guide to Computer Security Log Management) e o CIS Controls v8 — Control 8 (Audit Log Management) — estabelecem requisitos mínimos:

  • O que logar: pacotes bloqueados pela regra deny-all, conexões aceitas em regras críticas, mudanças de configuração, falhas de autenticação administrativa.
  • Formato: CEF (Common Event Format) ou syslog estruturado para integração com SIEM.
  • Retenção: mínimo de 12 meses (90 dias online + diferença em cold storage) para conformidade com LGPD e PCI DSS.
  • Alertas em tempo real: disparar alertas para conexões negadas em volumes anômalos (possível varredura de porta), conexões a geolocalidades inesperadas e tentativas de acesso administrativo fora do horário.

Logs de firewall são evidência forense primária em investigações de incidente. Sem eles, é impossível determinar o vetor inicial de um ataque.

Configuração de firewall em ambientes de nuvem

Em infraestruturas cloud-native, a configuração de firewall se distribui em múltiplas camadas com características distintas:

Controle AWS Azure GCP Tipo
Nível de instância Security Groups NSG Firewall Rules Stateful
Nível de sub-rede Network ACL NSG (sub-rede) Hierarchical Firewall Stateless
Inspeção centralizada AWS Network Firewall Azure Firewall Premium Cloud NGFW (Palo Alto) Stateful + DPI
Camada de aplicação AWS WAF Azure WAF Cloud Armor L7 / HTTP(S)

Boas práticas específicas para nuvem incluem: nunca expor o Security Group de banco de dados à internet (0.0.0.0/0), habilitar VPC Flow Logs obrigatoriamente, usar grupos de segurança em modo de referência cruzada (um SG referenciando outro em vez de CIDRs hardcoded) e revisar Security Hub / Defender for Cloud diariamente para findings de configuração incorreta.

Hardening do próprio dispositivo firewall

O firewall também é um ativo que precisa ser protegido. Os CIS Benchmarks para dispositivos de rede definem os seguintes controles obrigatórios:

  • Desativar todos os serviços e interfaces de gerenciamento não utilizados (HTTP, Telnet, SNMP v1/v2).
  • Usar SNMPv3 com autenticação SHA e criptografia AES, ou substituir por APIs REST sobre TLS 1.2+.
  • Habilitar autenticação multifator (MFA) para acesso administrativo ao console e à interface de gerenciamento.
  • Restringir o acesso de gerenciamento a uma rede de gerenciamento dedicada (OOB — Out-of-Band Management).
  • Sincronizar horário via NTP autenticado (para integridade dos logs).
  • Implementar controle de versão das configurações: todo backup deve ser gravado em repositório versionado (git ou similar) e comparado com o baseline aprovado.
  • Validar hashes dos firmwares antes de atualizações para prevenir supply chain attacks.

Gestão de mudanças no ruleset

Regras de firewall acumulam ao longo do tempo — fenômeno conhecido como firewall rule bloat. Organizações que nunca removem regras obsoletas acabam com centenas de entradas que ninguém sabe a finalidade, criando riscos ocultos.

Um processo de gestão de mudanças robusto inclui:

  • Ticket de solicitação: toda nova regra exige justificativa de negócio, responsável técnico e data de revisão.
  • Regras temporárias com TTL: regras para projetos ou testes devem ter data de expiração configurada no sistema de ticketing, com alerta automático.
  • Revisão semestral: auditoria de todo o ruleset para remover regras não utilizadas (detecção via hit count zerado por 90 dias ou mais).
  • Change Advisory Board (CAB): mudanças em regras de produção passam por aprovação formal, especialmente para zonas críticas como banco de dados e gerenciamento.
  • Teste em staging: ambientes críticos devem ter firewall de staging onde mudanças são validadas antes de produção.

Erros comuns de configuração e como evitá-los

  • Regra any/any sem justificativa: frequentemente criada para resolver um problema de conectividade rapidamente e nunca revisada. Use objetos específicos sempre.
  • RDP e SSH expostos à internet: portas 22, 3389 e 5900 nunca devem ser acessíveis de 0.0.0.0/0. Use VPN ou bastion host com MFA.
  • Zonas DMZ e interna na mesma sub-rede: anula o benefício da segmentação. Sempre use sub-redes e VLANs distintas.
  • Ausência de egress filtering: permite C2, exfiltração e participação em botnets.
  • Logging desabilitado em regras permissivas críticas: impossibilita análise forense post-incident.
  • Não inspecionar TLS: mais de 90% do tráfego de malware moderno usa HTTPS para C2 — sem SSL inspection, passa invisível.
  • Regras duplicadas e shadow rules: detectadas com análise de ruleset — ferramentas como Tufin Orchestration Suite ou análise manual com contadores de hits.

IDS/IPS integrado ao firewall

Sistemas de Detecção e Prevenção de Intrusão (IDS/IPS) complementam o firewall ao analisar o conteúdo dos pacotes em busca de assinaturas de ataques conhecidos e comportamentos anômalos. Em NGFWs modernos, o IPS é uma função inline que bloqueia ameaças em tempo real. A configuração recomendada inclui:

  • Habilitar perfis de proteção por zona: zonas críticas (DB, gerenciamento) com perfil máximo; DMZ com perfil balanceado.
  • Atualizar assinaturas diariamente de forma automatizada.
  • Colocar em modo prevent (bloqueio ativo) apenas após período de detect (monitoramento passivo) para calibrar falsos positivos.
  • Integrar alertas de IPS com o SIEM para correlação com outros eventos (ex.: IPS + tentativa de autenticação = indicador de comprometimento).

Referências normativas e técnicas

  • NIST SP 800-41r1: Guidelines on Firewalls and Firewall Policy — referência fundamental para política e arquitetura.
  • CIS Benchmarks for Network Devices: checklist de hardening para firewalls Cisco, Palo Alto, Check Point e outros.
  • OWASP Network Security Cheat Sheet: boas práticas de segmentação e filtragem de tráfego de aplicações web.
  • PCI DSS v4.0 — Requirement 1: controles de rede para ambientes de dados de cartão de pagamento, incluindo segmentação e revisão semestral de regras.
  • LGPD (Lei 13.709/2018) — Art. 46: obriga medidas técnicas e administrativas para proteção de dados pessoais, incluindo controles de rede.

Perguntas frequentes

Qual é a diferença entre firewall stateful e stateless?

Um firewall stateless avalia cada pacote de forma isolada, sem memória de conexões anteriores, aplicando regras com base exclusivamente em cabeçalhos (IP, porta, protocolo). Já o firewall stateful mantém uma tabela de estados de conexão (connection tracking table) e permite ou bloqueia pacotes com base no contexto da sessão estabelecida, o que reduz drasticamente falsos positivos e dificulta ataques de spoofing e session hijacking. Para a maioria dos ambientes corporativos, o stateful é o mínimo recomendado (NIST SP 800-41r1).

O que é a política default-deny e por que ela é obrigatória?

A política default-deny (ou 'implicit deny all') significa que qualquer tráfego não explicitamente permitido por uma regra é bloqueado. É o oposto do default-permit, onde tudo que não é proibido passa. O CIS Benchmark para firewalls exige default-deny como requisito fundamental: ela minimiza a superfície de ataque, força a revisão consciente de cada fluxo liberado e garante que novas portas ou serviços não fiquem expostos acidentalmente quando um servidor é provisionado. Sempre inclua a regra 'deny all / log' como última entrada no ruleset.

Como definir a ordem correta das regras de firewall?

Firewalls processam regras na ordem sequencial e param na primeira que corresponder ao pacote (first-match). A ordem recomendada é: (1) permitir tráfego de gerenciamento (SSH/HTTPS restrito a IPs administrativos), (2) permitir tráfego de retorno de conexões estabelecidas (estado ESTABLISHED/RELATED), (3) regras específicas de serviços permitidos (menor escopo possível), (4) regras de bloqueio explícito de fontes conhecidamente maliciosas, (5) regra final deny-all com log. Regras muito genéricas no topo mascaram regras específicas abaixo — use 'shadowing analysis' para detectar isso.

O que é um NGFW e quando ele é necessário?

Next-Generation Firewall (NGFW) é um firewall que, além de filtragem de pacotes e inspeção stateful, inclui DPI (Deep Packet Inspection), identificação de aplicação independente de porta (App-ID), prevenção de intrusão (IPS) embutida, inspeção de TLS/SSL, filtro de URL por categoria e integração com feeds de threat intelligence. É necessário em ambientes que precisam controlar aplicações SaaS (ex.: bloquear upload no Dropbox mas permitir download), inspecionar tráfego criptografado ou aplicar políticas baseadas em usuário/grupo (LDAP/AD). Exemplos de soluções NGFW: Palo Alto, Fortinet, Check Point, Cisco Firepower.

Como configurar firewall em ambientes de nuvem (AWS, Azure, GCP)?

Em nuvem pública, o controle de rede é feito em múltiplas camadas: (1) Security Groups (AWS/GCP) ou Network Security Groups (Azure) — stateful, operam no nível de interface de rede da instância; (2) Network ACLs (AWS) ou regras de firewall de VPC (GCP) — stateless, operam no nível de sub-rede; (3) Web Application Firewall (WAF) para tráfego HTTP/S; (4) firewall virtual de terceiros para inspeção centralizada de tráfego leste-oeste (inter-VPC). A regra de ouro: security groups com menor privilégio (0.0.0.0/0 apenas para portas 80/443 voltadas ao público), NACL como segunda camada de defesa, e logs de VPC Flow habilitados obrigatoriamente.

Quais são os erros mais comuns na configuração de firewall?

Os erros mais frequentes documentados em auditorias incluem: (1) regras 'any/any' sem justificativa — liberam todo tráfego entre zonas; (2) ausência de egress filtering — permite que malware estabeleça canais de comando e controle; (3) regras fantasma (shadow rules) — nunca matchadas porque sobrepostas por regras anteriores; (4) bases de regras com centenas de entradas sem revisão periódica (firewall rule bloat); (5) portas administrativas (22, 3389, 8443) acessíveis da internet sem MFA; (6) logging desabilitado ou sem retenção adequada; (7) zonas DMZ e produção na mesma sub-rede lógica. O CIS Benchmark recomenda revisão semestral do ruleset.

A Decripte implementa configuração e hardening de firewall para empresas de todos os portes — do MEI ao Enterprise com mais de 100.000 colaboradores — integrando política de segurança de rede, segmentação por zonas, gestão contínua de ruleset e monitoramento com SIEM. Conheça nosso plano de segurança de perímetro em decripte.com.br/planos.