WAF (Web Application Firewall): regras, tuning e proteção na camada 7
Um WAF (Web Application Firewall) é o controle de segurança posicionado entre a internet e a sua aplicação web, operando na camada 7 do modelo OSI para inspecionar, filtrar e bloquear tráfego HTTP e HTTPS malicioso antes que ele alcance o código da aplicação. Ao contrário de firewalls de rede convencionais, que filtram pacotes por endereço IP e porta, o WAF entende o protocolo HTTP — cabeçalhos, parâmetros, cookies, corpo de requisição — e pode identificar padrões de ataque sofisticados que transitam em requisições aparentemente legítimas.
O que é um WAF e onde ele atua
O WAF pode ser implantado em três posições arquiteturais: como appliance de rede (hardware inline), como módulo de servidor web (ModSecurity para Apache/Nginx, IIS) ou como serviço de borda em nuvem (Cloudflare WAF, AWS WAF, Akamai Kona). Em todos os casos, o tráfego passa pelo WAF antes de chegar à aplicação; requisições que correspondam a padrões de ataque são bloqueadas, registradas ou redirecionadas para análise.
A atuação na camada 7 permite ao WAF analisar o contexto completo de uma transação HTTP. Uma requisição com o parâmetro id=1 OR 1=1-- em uma URL pode parecer inócua para um firewall de pacotes, mas um WAF com regras para SQL Injection identificará o padrão e bloqueará antes que ele chegue ao banco de dados. O mesmo princípio se aplica a vetores como Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), inclusão de arquivos remotos (RFI) e injeção de comandos.
Modos de operação: modelo negativo vs. modelo positivo
Dois modelos fundamentais guiam a lógica de decisão de um WAF:
Modelo negativo (denylist/assinaturas): o WAF mantém um catálogo de padrões de ataque conhecidos. Qualquer requisição que corresponda a um padrão é bloqueada; o restante é permitido. É o modelo padrão do OWASP Core Rule Set e da maioria dos WAFs gerenciados. A vantagem é a facilidade de operação; a desvantagem é que ataques zero-day ou variantes ofuscadas não catalogadas podem passar.
Modelo positivo (allowlist/perfil de aplicação): o WAF define explicitamente o comportamento legítimo esperado — quais endpoints existem, quais métodos aceitam, quais parâmetros são válidos e qual é o formato dos valores. Qualquer desvio desse perfil é bloqueado. Oferece proteção mais robusta contra ataques desconhecidos, mas exige mapeamento inicial detalhado da aplicação e manutenção contínua quando a aplicação evolui.
Na prática, a maioria das implementações maduras combina os dois modelos: assinaturas do CRS como base e regras positivas customizadas para endpoints críticos como autenticação, pagamento e upload de arquivos.
OWASP Core Rule Set (CRS)
O OWASP CRS é o conjunto de regras open source mais amplamente adotado para WAFs. Compatível nativamente com ModSecurity e sua reimplementação em Go (Coraza), o CRS é mantido pela OWASP Foundation e recebe atualizações contínuas conforme novos vetores de ataque são catalogados.
O CRS utiliza um sistema de pontuação de anomalias: cada regra que uma requisição dispara adiciona pontos a um contador. Quando o total ultrapassa um limiar configurável (padrão: 5 pontos para requisições de entrada), a requisição é bloqueada. Esse design evita falsos positivos causados por uma única assinatura ambígua e permite graduar a sensibilidade da proteção.
O CRS também implementa paranoia levels de 1 a 4. No nível 1, apenas regras de alta confiança e baixo risco de falso positivo estão ativas — ideal para início de implantação. No nível 4, todas as regras estão ativas, incluindo as mais sensíveis para aplicações de alta criticidade, como sistemas financeiros e de saúde. A recomendação é iniciar no nível 1 e elevar gradualmente após análise de falsos positivos.
Proteção contra o OWASP Top 10
O WAF é o controle de borda mais direto para mitigar as categorias de risco do OWASP Top 10 que se manifestam via HTTP:
- A03 — Injection (SQLi, LDAP, OS Command): regras detectam sequências de metacaracteres SQL (
UNION SELECT,OR 1=1, comentários--e/**/), chamadas de sistema e manipulação de diretórios. - A02 — Falhas Criptográficas / Exposição de Dados: o WAF não criptografa, mas pode bloquear respostas que contenham padrões de dados sensíveis (números de cartão, CPF) via inspeção de resposta.
- A07 — Cross-Site Scripting (XSS): regras identificam tags HTML injetadas (
<script>,onerror=,javascript:) em parâmetros de entrada. - A10 — Server-Side Request Forgery (SSRF): regras detectam tentativas de forçar a aplicação a realizar requisições para endereços internos (169.254.169.254 do IMDS da AWS, 127.0.0.1, faixas RFC 1918).
- A01 — Controle de Acesso Quebrado (parcial): path traversal (
../,..%2F) e tentativas de acesso a endpoints administrativos são cobertos por regras do CRS.
É fundamental registrar que o WAF não cobre categorias como falhas de lógica de negócio, controle de acesso baseado em contexto de usuário (IDOR, BOLA) e autenticação defeituosa — que exigem testes de penetração e revisão de código.
Tuning: reduzindo falsos positivos sem abrir brechas
O maior desafio operacional de um WAF não é a implantação inicial, mas o tuning contínuo para equilibrar proteção e disponibilidade. Falsos positivos bloqueiam usuários e operações legítimas; ajustes excessivamente permissivos criam brechas. A tabela a seguir resume as principais decisões de tuning:
| Situação | Abordagem correta | O que evitar |
|---|---|---|
| Editor de texto rico envia HTML no corpo | Exceção por URI + parâmetro específico | Desativar regra XSS globalmente |
| API recebe JSON com campos binários/Base64 | Exceção por URI + Content-Type | Desativar verificação de corpo globalmente |
| Upload de arquivo legítimo dispara regra de path traversal | Exceção por URI de upload + rule_id específico | Reduzir paranoia level para todo o site |
| Scanner interno de vulnerabilidades dispara regras | Allowlist por IP de origem do scanner | Desativar modo de bloqueio durante scans |
| Alto volume de bloqueios em endpoint público | Investigar se é ataque real antes de criar exceção | Criar exceção sem análise dos logs |
O processo recomendado pelo OWASP para tuning segue a sequência: detectar → analisar → excepcionar cirurgicamente → bloquear → monitorar. Nunca pule a fase de detecção em produção.
Rate limiting, anti-bot e mitigação de DDoS na borda
WAFs modernos de borda incorporam capacidades além da inspeção de payload HTTP:
Rate limiting: limita o número de requisições por IP, por sessão ou por endpoint em uma janela de tempo. Fundamental para mitigar credential stuffing em endpoints de login, enumeração de contas e abuso de APIs públicas. Regras eficazes são específicas por endpoint — limites em /api/auth/login devem ser mais restritivos do que em páginas estáticas.
Desafios de bot (CAPTCHA/JavaScript challenge): para tráfego suspeito que não deve ser bloqueado imediatamente, WAFs de borda como o Cloudflare oferecem desafios interativos que distinguem navegadores humanos de automação. Essa camada é eficaz contra scrapers, bots de inventário e ferramentas de ataque automatizado.
Mitigação de DDoS Layer 7: ataques de volumetria na camada de aplicação (HTTP flood, Slowloris, ataques a endpoints computacionalmente caros) são detectados por análise de padrão de tráfego e bloqueados na borda, antes de consumir recursos do servidor de origem. Provedores como Cloudflare e AWS Shield Advanced oferecem capacidade de absorção de dezenas de Tbps.
Fingerprinting de TLS e comportamento de cliente: técnicas como JA3 (fingerprint de handshake TLS) e análise de ordem de cabeçalhos HTTP/2 permitem identificar ferramentas de ataque mesmo quando operam com IPs distintos, complementando a análise baseada em assinatura de payload.
WAF gerenciado vs. self-managed
A escolha entre solução gerenciada e self-managed depende da capacidade operacional da organização e do nível de controle exigido:
WAFs gerenciados (Cloudflare WAF, AWS WAF, Imperva): implantação via DNS (proxy reverso de borda) ou integração nativa com load balancer. Regras atualizadas pelo provedor sem intervenção operacional. Dashboards unificados de log e alertas. Custo proporcional ao volume de tráfego ou ao número de regras. A desvantagem principal é a menor granularidade de customização e a dependência do roadmap do fornecedor para novas proteções.
Self-managed (ModSecurity + OWASP CRS, Coraza): controle total sobre regras, logs e exceções. Suporte a implantação on-premises ou em ambientes sem acesso a provedores de borda. Exige equipe capacitada para manutenção, aplicação de patches do CRS e resposta a novos vetores. O Coraza, implementação Go do CRS compatível com Caddy e Envoy, tem ganho adoção em arquiteturas de microsserviços e service mesh.
A abordagem mais adotada por organizações com requisitos de segurança elevados é o modelo híbrido: WAF de borda gerenciado para proteção volumétrica e cobertura global, complementado por inspeção adicional no nível do servidor de aplicação para endpoints críticos com regras altamente customizadas.
Checklist de tuning para implantação segura
- Mapear todos os endpoints públicos antes de ativar qualquer regra
- Iniciar com OWASP CRS paranoia level 1, modo detecção
- Coletar baseline de 14 dias de tráfego real em produção
- Criar exceções apenas por URI + parâmetro + rule_id, nunca globalmente
- Ativar rate limiting em endpoints de autenticação e recuperação de senha
- Subir paranoia level gradualmente (1→2) apenas em endpoints críticos
- Promover para modo de bloqueio por grupo de endpoints, com janela de monitoramento de 48h
- Estabelecer ciclo mensal de revisão: atualizar CRS, revisar exceções, validar cobertura
- Documentar cada exceção com justificativa, data e responsável
- Integrar logs do WAF ao SIEM para correlação com outros eventos de segurança
Limitações: o que o WAF não resolve
Um WAF é um controle de compensação, não uma solução completa de segurança de aplicação. As seguintes classes de vulnerabilidades estão fora do alcance de qualquer WAF:
- Falhas de lógica de negócio: um atacante que manipula o fluxo de compra para aplicar descontos indevidos emite requisições HTTP estruturalmente válidas, indistinguíveis do tráfego legítimo para o WAF.
- Controle de acesso falho (IDOR/BOLA): acessar o recurso de outro usuário via ID previsível na URL não dispara nenhuma assinatura de ataque conhecida.
- Autenticação e gerenciamento de sessão defeituosos: tokens JWT sem validação adequada, sessões não expiradas e reutilização de credenciais não são detectáveis na camada de payload HTTP.
- Vulnerabilidades em componentes de terceiros: bibliotecas com CVEs conhecidos executando no servidor não são protegidas pelo WAF se o vetor de exploração usar parâmetros HTTP legítimos.
O NIST SP 800-95 e o OWASP Application Security Verification Standard (ASVS) são explícitos: WAF deve ser parte de uma estratégia de defesa em profundidade que inclua modelagem de ameaças no design, revisão de código seguro, testes de penetração periódicos e gestão contínua de vulnerabilidades.
Referências
- OWASP Core Rule Set — coreruleset.org
- OWASP ModSecurity Core Rule Set Documentation — owasp.org/www-project-modsecurity-core-rule-set
- NIST SP 800-95: Guide to Secure Web Services
- OWASP Application Security Verification Standard (ASVS) v4.0
- OWASP Top 10 2021 — owasp.org/Top10
- Coraza WAF — coraza.io
Perguntas frequentes
O que diferencia um WAF de um firewall de rede tradicional?
Um firewall de rede opera nas camadas 3 e 4 do modelo OSI — filtra pacotes por endereço IP, porta e protocolo. Um WAF atua na camada 7 (aplicação), inspecionando o conteúdo HTTP/HTTPS: cabeçalhos, parâmetros de URL, corpo da requisição e cookies. Isso permite detectar e bloquear ataques como SQL Injection, Cross-Site Scripting e inclusão de arquivos remotos, que transitam em requisições HTTP aparentemente válidas e passam despercebidos por firewalls de rede convencionais.
O que é o OWASP Core Rule Set (CRS) e por que ele é o padrão do mercado?
O OWASP Core Rule Set (CRS) é um conjunto de regras genéricas de detecção de ataques mantido pela OWASP Foundation e compatível com o engine ModSecurity. Ele cobre as principais categorias do OWASP Top 10 — SQLi, XSS, SSRF, inclusão de arquivos, injeção de comandos — usando um sistema de pontuação de anomalias (paranoia levels 1 a 4). Por ser open source, auditado publicamente e atualizado continuamente, tornou-se a referência de fato tanto em implementações self-managed quanto como base de WAFs gerenciados comerciais.
Qual é a diferença entre o modelo de segurança negativo e o positivo em WAF?
No modelo negativo (denylist), o WAF bloqueia padrões conhecidos de ataque — é o modo padrão do OWASP CRS. No modelo positivo (allowlist), somente requisições que correspondam a um perfil explicitamente aprovado de comportamento legítimo são aceitas; tudo o mais é bloqueado. O modelo positivo oferece proteção mais robusta contra ataques zero-day, mas exige maior esforço de mapeamento e manutenção das regras de comportamento esperado da aplicação.
Como reduzir falsos positivos sem comprometer a proteção do WAF?
O processo correto envolve quatro etapas: iniciar no modo de detecção (log-only) por no mínimo duas semanas coletando todas as requisições bloqueadas; analisar os logs para identificar padrões legítimos que disparam regras; criar exceções cirúrgicas por URI, parâmetro ou par URI+rule_id, nunca desativando regras globalmente; e promover para modo de bloqueio por etapas, monitorando taxas de erro 403/406 nas primeiras 48 horas. Revisões periódicas do CRS a cada nova versão e ajuste do paranoia level por conjunto de endpoints são práticas complementares.
WAF gerenciado (Cloudflare, AWS WAF) ou self-managed (ModSecurity/Coraza)?
WAFs gerenciados oferecem atualização automática de regras, integração nativa com a rede de borda do provedor e operação simplificada, mas impõem dependência de fornecedor e menor granularidade de customização. Soluções self-managed como ModSecurity ou Coraza dão controle total sobre regras, logs e tuning, mas exigem capacidade operacional interna para manutenção. Para a maioria das organizações, a abordagem híbrida — WAF gerenciado na borda com regras customizadas para endpoints críticos — equilibra cobertura e controle.
WAF substitui código seguro e testes de segurança na aplicação?
Não. Um WAF é um controle de compensação na camada de borda, não um substituto para desenvolvimento seguro. Vulnerabilidades como lógica de negócio quebrada, controle de acesso falho (IDOR, BOLA), autenticação defeituosa e exposição excessiva de dados raramente produzem assinaturas detectáveis por WAF. O NIST SP 800-95 e o OWASP ASVS são explícitos: WAF deve compor uma estratégia de defesa em profundidade que inclua modelagem de ameaças, revisão de código, testes de penetração e gestão de vulnerabilidades.
Gestão de WAF e segurança de borda com a Decripte
A Decripte gerencia WAF e segurança de borda para organizações de todos os portes — do MEI ao Enterprise com mais de 100.000 colaboradores. Nossa equipe opera implantações de Cloudflare WAF, AWS WAF e ModSecurity/Coraza, conduz o ciclo completo de tuning (baseline → exceções → bloqueio → revisão) e integra alertas do WAF ao centro de operações de segurança. Se sua aplicação está exposta à internet sem proteção de camada 7 adequada, ou se você precisa revisar e afinar um WAF já implantado, conheça nossos planos ou comece gratuitamente com o plano de Gestão de Ameaças.