PRT.3 - Proteção Web e WAF

Nota do grupo PRT (Defesa em Profundidade) do Framework CTH, derivada do capítulo 7, seção 7.3 (PRT.3.1 a PRT.3.5), do PDF de referência.
O WAF é a camada que filtra ataques a aplicações web antes que alcancem o código e, ao mesmo tempo, uma das fontes mais produtivas de inteligência tática sobre atacantes.
A nota cobre modos de operação, OWASP CRS, virtual patching, uso dos logs como telemetria de detecção e integração com SOC, SOAR e CTI.

1. Contexto e Posicionamento no Framework CTH

Aplicações web públicas recebem um volume contínuo de ataques automatizados, incluindo bots de varredura, exploração de vulnerabilidades conhecidas do OWASP Top 10 e campanhas direcionadas contra frameworks específicos. Sem uma camada de filtragem dedicada, esse volume chega integralmente à aplicação e aos logs, saturando a capacidade de detecção do SOC com ruído repetitivo. O WAF atua como filtro de aplicação na borda, bloqueando ou marcando requisições conforme regras e reduzindo o volume de ataques que precisam ser analisados individualmente.

No Framework CTH, PRT.3 cumpre um papel duplo que complementa o DAT.3. Como proteção, reduz a superfície efetiva das aplicações, aplicando o OWASP Core Rule Set como baseline e virtual patching em janelas de vulnerabilidade. Como sensor, produz logs de alta densidade sobre quem ataca, com qual payload, qual user agent e qual padrão de varredura, dados que alimentam a CTI, os bloqueios preventivos e a engenharia de detecção. Um WAF cujos logs ninguém lê entrega apenas metade do valor previsto no controle.

2. Papel do WAF na Defesa em Profundidade de Aplicações

O WAF não substitui desenvolvimento seguro, e é importante evitar essa expectativa desde o desenho do controle. Vulnerabilidades de lógica de negócio, falhas de autorização e credenciais fracas permanecem fora do alcance de regras genéricas de filtragem. O papel correto do WAF é eliminar o ruído de fundo de exploração automatizada, comprar tempo nas janelas entre descoberta e correção de vulnerabilidades e registrar detalhadamente tudo que tenta atravessar a borda da aplicação.

Posicionado como proxy reverso, o WAF encerra o TLS do cliente e aplica suas regras sobre o conteúdo decifrado, podendo combinar funções de segurança de borda no mesmo ponto de controle. Rate limiting contra força bruta, validação de headers, proteção contra DDoS de camada 7 e remoção de métodos HTTP desnecessários, como TRACE e PUT, quando não utilizados pela aplicação, são exigências de PRT.3.2 que convivem naturalmente com a filtragem de payloads. Essa consolidação simplifica a operação, mas também concentra risco no ponto de borda, o que exige atenção à disponibilidade e à atualização do próprio WAF.

A arquitetura de implantação varia conforme o ecossistema da organização e influencia o custo, a velocidade de atualização das regras e o controle sobre os logs, conforme a comparação abaixo.

Em ambientes com múltiplos modelos, vale padronizar o esquema de log exportado para o SIEM, de modo que correlações e hunts funcionem igualmente sobre qualquer borda. A governança de regras e exceções também deve ser unificada, evitando que cada modelo de implantação desenvolva disciplina própria.

3. Modos de Operação e Implantação Progressiva

A decisão entre detecção com logging e bloqueio não é binária nem permanente, e sim um percurso maturado por aplicação. A tabela compara os modos e orienta quando usar cada um.

A estratégia de implantação progressiva recomendada pelo Framework segue uma sequência simples e verificável. O PRT.3.1 fixa o parâmetro de referência: operação em detecção por 2 a 4 semanas com análise de falsos positivos antes da transição para prevenção.

1. Implantar o WAF em frente a todas as aplicações web públicas no modo detecção, com OWASP CRS habilitado e logs completos encaminhados ao SIEM.
2. Durante o período de aprendizado, classificar os eventos por regra, por aplicação e por criticidade, identificando falsos positivos reais e ataques legítimos detectados.
3. Ajustar exceções com escopo mínimo por aplicação, preferindo suprimir regras específicas em rotas específicas a desativar categorias inteiras.
4. Migrar para bloqueio por camadas, começando pelas categorias de maior confiança, como payloads de SQLi e path traversal, e mantendo categorias sensíveis em detecção por mais tempo.
5. Estabelecer rotina permanente de revisão: toda nova versão de aplicação e todo novo conjunto de regras passa por ciclo curto de detecção antes de bloquear.

O sucesso desse percurso é medido, não percebido: taxa de falsos positivos por aplicação, volume de requisições bloqueadas por categoria e tempo entre ativação de regra e ajuste de exceção são métricas mínimas de governança.

4. OWASP CRS e Virtual Patching

O OWASP Core Rule Set organiza as detecções em categorias numeradas que facilitam a governança por classe de ataque. Conhecer as categorias permite ajustar políticas com precisão e conversar com desenvolvedores em termos concretos durante a análise de falsos positivos.

Virtual patching é a prática de criar regras específicas que neutralizam uma vulnerabilidade conhecida na borda enquanto o patch de aplicação não é entregue. Ele é essencial para CVEs exploradas ativamente em aplicações expostas, especialmente em frameworks de terceiros cuja correção depende de fornecedor. O exemplo abaixo ilustra uma regra ModSecurity de neutralização de payloads JNDI durante o período crítico da vulnerabilidade de Log4Shell, com identificação própria e log obrigatório.

# Virtual patching ilustrativo para lookup JNDI em payloads (referencia CVE-2021-44228)
SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (?i)\$\{(?:jndi|lower|upper|env)" \
  "id:1000101,phase:2,deny,status:403,log,\
  msg:'Virtual patch - tentativa de JNDI lookup em payload',tag:'virtual-patching'"

Regras de virtual patching devem ter prazo e dono. Cada regra nasce associada a uma CVE, a um plano de correção definitiva e a uma data de revisão, e o repositório de regras precisa refletir esse vínculo para que o WAF não acumule filtros sem propósito. A CTI encurta o ciclo, pois relatórios de campanha chegam com payloads e rotas de exploração que podem virar regras em horas.

5. WAF como Fonte de CTI e Bloqueio Preventivo

Os logs do WAF são um dos maiores produtores internos de inteligência tática disponíveis. Deles se extraem IPs e redes atacantes, user agents de ferramentas de varredura, payloads reais usados contra a organização, rotas mais visadas e cadência de campanhas. Esses dados têm valor duplo: melhoram a detecção reativa no SOC e alimentam bloqueios preventivos em outras bordas, como firewalls de saída, gateways de e-mail e outros WAFs de regiões diferentes.

O fluxo de fechamento com o SOAR segue um padrão simples e auditável.

1. O WAF encaminha eventos bloqueados e detectados ao SIEM, já enriquecidos com geolocalização e ASN.
2. Regras de agregação identificam fontes que ultrapassam limiares de ataques por janela de tempo, como cinquenta eventos por hora em categorias de exploração.
3. O SOAR consulta a plataforma de CTI para contexto adicional e verifica se o IP pertence a CDN, provedor de nuvem ou lista de permissão de negócio.
4. Fontes confirmadas como maliciosas são enviadas a bloqueio preventivo com prazo de expiração, motivo e dono, e a decisão é registrada para auditoria.
5. Bloqueios são revisados periodicamente, e fontes de CDN exigem estratégia diferenciada, baseada em bot management e reputação de sessão em vez de IP.

A cautela operacional é imprescindível: bloquear por IP sem verificação quebra usuários legítimos atrás de proxies compartilhados e de provedores móveis. Indicadores extraídos do próprio WAF devem ser classificados com confiança e validade, seguindo a disciplina de gestão de indicadores do CTI.5, e o feedback de bloqueios indevidos precisa voltar ao ajuste das regras de agregação. A tabela resume os indicadores mais valiosos que saem dos logs do WAF e a precaução de uso de cada um.

6. Logs do WAF como Telemetria de Detecção (DAT.3)

Além da proteção, o log do WAF é uma das fontes principais do DAT.3, a coleta de logs de aplicações web. O conteúdo mínimo que deve ser encaminhado ao SIEM inclui timestamp, IP do cliente, método, URI completa, user agent, código de resposta, regra disparada, categoria CRS, ação aplicada e, quando possível, trecho do payload que casou com a regra. A consulta abaixo exemplifica agregação de campanhas de ataque por fonte e rota, requisito do PRT.3.4.

// KQL ilustrativo sobre logs de WAF no SIEM
WafLog
| where TimeGenerated > ago(24h) and Action_s in ("Block","AnomalyScoring")
| summarize Ataques=count(), Rotas=make_list(Details_uri_s), Regras=make_set(RuleName_s)
  by ClientIP_s, bin(TimeGenerated, 1h)
| where Ataques > 20
| order by Ataques desc

Correlações que combinam o WAF com o restante do ecossistema elevam bastante a qualidade das detecções. Eventos do WAF cruzados com logs de acesso da aplicação revelam requisições que passaram pelo WAF e causaram erros 500 em sequência, padrão de exploração em teste. Cruzados com telemetria de rede do PRT.2, revelam infraestrutura que varre múltiplas aplicações. Cruzados com o EDR, conectam tentativas de exploração web a execução de processo no servidor, fechando a cadeia de um ataque real. A tabela resume casos de correlação de alto valor para implementar como regras permanentes no SIEM.

7. Limitações Técnicas do WAF

O WAF protege apenas o tráfego que passa por ele. Acessos diretos ao servidor de origem por IP histórico, DNS exposto ou serviço não declarado contornam completamente a camada, e verificações periódicas de exposição, apoiadas por EASM, são necessárias para garantir que a origem não esteja acessível sem passar pelo WAF. A terminação de TLS no WAF, por sua vez, concentra a chave de descriptografia no ponto de borda e cria um trecho interno sem inspeção até a aplicação, o que exige cifragem no trecho interno e monitoração de rede nesse segmento.

Payloads legítimos complexos são a segunda limitação prática. APIs modernas transportam JSON aninhado, base64 assinado e campos livremente formatados, e regras genéricas tendem a gerar falso positivo em requisições perfeitamente válidas. A resposta é tratar API como caso específico, com políticas por rota, validação de esquema e regras dedicadas, em vez de aplicar o mesmo perfil de CRS de um site institucional. Por fim, técnicas de bypass, como codificação múltipla, fragmentação de parâmetros e abuso de diferenças de parsing entre WAF e aplicação, reduzem a eficácia das regras ao longo do tempo, o que reforça a necessidade de testes periódicos e de atualização do conjunto de regras.

No nível avançado de PRT.3.5, a limitação por IP é progressivamente substituída por gestão de bots, com desafios seletivos, fingerprinting de navegador e análise comportamental de sessão. Essa camada distingue automação legítima, como robôs de busca e monitoramento de parceiros, de varredura maliciosa, permitindo proteger rotas sensíveis como login, recuperação de senha e upload sem penalizar tráfego válido. Políticas diferenciadas por tipo de endpoint e por estado de autenticação do usuário completam o modelo, mantendo a experiência legítima intacta enquanto elevam o custo do adversário.

8. Salvaguardas por Nível de Maturidade

As salvaguardas de PRT.3 seguem os três níveis cumulativos do Framework, conforme a tabela consolidada abaixo.

A verificação periódica deve incluir testes controlados de ataque web contra ambiente de pré-produção ou janela autorizada, medindo se regras esperadas bloqueiam. Métricas úteis são a proporção de aplicações públicas cobertas, a taxa de falsos positivos confirmados por mês e o tempo médio entre publicação de CVE relevante e regra de virtual patching ativa.

9. Erros Comuns e Pontos de Atenção

O erro mais grave é ativar o WAF em modo bloqueio direto em produção, sem período de detecção nem tuning. O resultado é a quebra de funcionalidades legítimas, a perda de credibilidade do controle e a pressão organizacional para desligá-lo. O percurso progressivo da seção 3 existe justamente para evitar esse ciclo destrutivo, e cada transição de regra para bloqueio deve ser tratada como mudança com reversão planejada.

O segundo erro estrutural é ninguém ler os logs. Um WAF sem integração com SIEM, sem regras de correlação e sem revisão periódica se torna apenas um filtro cego, incapaz de contribuir para CTI, hunting e resposta a incidente. Completam a lista de falhas recorrentes os itens abaixo.

• Exceções amplas criadas para silenciar falsos positivos, como desativar categorias inteiras de regras para uma aplicação inteira.
• WAF implantado apenas na aplicação principal, deixando aplicações secundárias e APIs expostas sem cobertura.
• Bloqueio permanente de IPs sem expiração nem revisão, acumulando falsos positivos históricos.
• Regras de virtual patching sem vínculo com CVE e sem prazo, virando dívida técnica invisível.
• Ausência de testes de bypass e de atualização do CRS, permitindo que técnicas conhecidas de evasão permaneçam eficazes.
• Expectativa de que o WAF corrija vulnerabilidades de aplicação, reduzindo a pressão sobre o ciclo de desenvolvimento seguro.

10. Integração com Outros Controles do Framework CTH

PRT.3 conversa diretamente com o DAT.3, que formaliza a coleta dos logs de aplicação web, e com o DAT.4, que define a ingestão central no SIEM. Os indicadores extraídos dos logs alimentam o CTI.5 e o CTI.8, e retornam como bloqueios preventivos pela automação do AUT.1 e do AUT.5. Na resposta a incidentes, os logs do WAF são frequentemente a primeira evidência de exploração de aplicação pública, suportando o IR.2 na triagem e no escopo.

No eixo de detecção personalizada, regras específicas para uploads e webshells do PRT.3.3 compartilham repositório e disciplina com o PRT.5, e o SIM.4 valida IOCs e payloads de campanha web executando testes controlados contra a borda. As métricas de eficácia, como cobertura de aplicações e tempo de virtual patching, alimentam o MET.x e sustentam as decisões de investimento do GOV, fechando o ciclo entre proteção de aplicação, inteligência e governança.