Laboratório de Troubleshooting: Design a WAF Deployment
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de segurança configurou o Azure Web Application Firewall (WAF) em modo Prevention sobre um Azure Application Gateway v2 para proteger uma API REST interna. O ambiente usa regras gerenciadas do conjunto OWASP CRS 3.2 sem customizações. O Application Gateway está em uma subnet dedicada com NSG associado.
Após a ativação do WAF, os desenvolvedores reportam que requisições legítimas de um cliente de integração estão sendo bloqueadas. O time de operações coleta o seguinte log:
{
"resourceId": "/SUBSCRIPTIONS/.../APPLICATIONGATEWAYS/APIGW-PROD",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw-prod_1",
"clientIp": "10.50.1.22",
"requestUri": "/api/v2/payload",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.2",
"ruleId": "942100",
"message": "SQL Injection Attack Detected via libinjection",
"action": "Blocked",
"site": "Global",
"details": {
"matchVariableName": "args",
"matchVariableValue": "SELECT=value&filter=active"
}
}
}
O time verifica que o cliente envia parâmetros de query string com nomes como SELECT e filter, que são termos comuns da API deles. O NSG da subnet do Application Gateway permite tráfego nas portas 80 e 443 de qualquer origem. O SKU do Application Gateway é WAF_v2. O WAF foi ativado há 48 horas e nenhuma regra de exclusão foi configurada.
Qual é a causa raiz do problema?
A) O NSG associado à subnet do Application Gateway está bloqueando o tráfego de retorno da API backend, causando falsos positivos no log do WAF.
B) O conjunto de regras OWASP CRS 3.2 está interpretando os nomes dos parâmetros de query string da API como padrões de injeção SQL, e nenhuma exclusão foi configurada para proteger esses campos específicos.
C) O WAF em modo Prevention com SKU WAF_v2 não suporta inspeção de query strings em requisições para APIs REST, exigindo downgrade para o SKU Standard_v2.
D) O ruleId 942100 foi ativado incorretamente durante a configuração do WAF e precisa ser removido do conjunto de regras gerenciadas para restaurar o funcionamento normal.
Cenário 2 — Impacto Colateral
Uma organização opera um Azure Front Door Premium com WAF habilitado em modo Detection para monitorar uma aplicação web pública. Após uma análise de segurança, o time de operações decide migrar o WAF para o modo Prevention com o objetivo de bloquear ataques ativos identificados nos logs.
A mudança é aplicada com sucesso e confirmada no portal. Nos primeiros 30 minutos após a alteração, o helpdesk recebe reclamações de usuários legítimos reportando erros HTTP 403 em funcionalidades específicas da aplicação, incluindo o módulo de busca avançada e o formulário de upload de documentos.
O time confirma que não houve nenhuma alteração nas regras gerenciadas nem nas regras customizadas durante a transição. A aplicação não foi modificada.
Qual consequência secundária essa mudança de modo causou?
A) A mudança para o modo Prevention desativou automaticamente os logs de diagnóstico do WAF, impedindo a visibilidade sobre os bloqueios ativos.
B) Requisições que antes geravam apenas alertas em modo Detection passaram a ser bloqueadas em modo Prevention, expondo falsos positivos preexistentes que nunca haviam sido tratados.
C) O Azure Front Door Premium reprocessou o cache de todas as requisições anteriores ao aplicar o novo modo, descartando sessões ativas e forçando reautenticação dos usuários.
D) A habilitação do modo Prevention em WAF associado ao Azure Front Door Premium requer reinicialização do perfil, o que causou indisponibilidade temporária durante a propagação da configuração.
Cenário 3 — Causa Raiz
Um arquiteto implantou uma política WAF global no Azure Front Door Premium para proteger múltiplas origens distribuídas em diferentes regiões. A política está em modo Prevention com regras gerenciadas do conjunto Microsoft_DefaultRuleSet 2.1 e duas regras customizadas de bloqueio por geolocalização.
Após a implantação, o time de QA reporta que requisições originadas de determinados países que deveriam ser bloqueados pelas regras de geolocalização continuam chegando às origens sem bloqueio. O arquiteto verifica a configuração e observa o seguinte:
Custom Rules:
Rule Name: BlockGeoRegion
Priority: 200
Action: Block
Match Condition: RemoteAddr GeoMatch [CN, RU, KP]
Managed Rules:
RuleSet: Microsoft_DefaultRuleSet 2.1
Status: Enabled
WAF Policy Association:
Profile: FrontDoor-Premium-Prod
Domain: app.contoso.com (Enabled)
Domain: api.contoso.com (Not associated)
O arquiteto também menciona que a política foi criada na região East US e que o Front Door Premium usa pontos de presença globais. O time de monitoramento confirma que os logs do WAF mostram as requisições bloqueadas corretamente para app.contoso.com, mas não há registros de bloqueio para api.contoso.com.
Qual é a causa raiz do problema?
A) Políticas WAF criadas na região East US não são replicadas automaticamente para pontos de presença fora da América do Norte, exigindo criação de políticas regionais separadas.
B) O conjunto de regras Microsoft_DefaultRuleSet 2.1 sobrescreve regras customizadas de geolocalização com prioridade acima de 100, exigindo reconfiguração da prioridade da regra BlockGeoRegion.
C) O domínio api.contoso.com não está associado à política WAF, portanto o tráfego destinado a esse endpoint não é inspecionado nem filtrado pelas regras configuradas.
D) Regras customizadas de geolocalização no Azure Front Door Premium requerem que o WAF esteja associado a um endpoint de roteamento específico, não a um perfil global, para que o bloqueio funcione por domínio.
Cenário 4 — Decisão de Ação
O time de segurança identificou que uma regra gerenciada específica do conjunto OWASP CRS 3.2, o ruleId 931130, está gerando falsos positivos em um endpoint crítico de upload de arquivos de uma aplicação em produção no Application Gateway WAF v2. O WAF está em modo Prevention e o endpoint afetado processa contratos jurídicos em formato PDF enviados por parceiros externos.
A causa foi confirmada: o nome do campo de formulário usado pelo sistema legado de parceiros contém um padrão que dispara a regra 931130 (Remote File Inclusion). Modificar o sistema legado dos parceiros não é viável no curto prazo. O ambiente está em produção e qualquer interrupção tem impacto contratual direto.
Qual é a ação correta a tomar neste momento?
A) Desabilitar globalmente o ruleId 931130 na política WAF para eliminar os falsos positivos imediatamente, mantendo todas as demais regras ativas.
B) Configurar uma exclusão de regra WAF que exclua o campo de formulário específico da avaliação do ruleId 931130, preservando a proteção da regra para todos os demais campos e endpoints.
C) Migrar o WAF para o modo Detection temporariamente, registrar todas as requisições dos parceiros para análise e retornar ao modo Prevention após confirmar o padrão exato do falso positivo.
D) Criar uma regra customizada com ação Allow e prioridade mais alta que bloqueie a avaliação do tráfego dos parceiros antes que ele alcance as regras gerenciadas, liberando o endpoint de upload completamente para os IPs dos parceiros.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A causa raiz é que os nomes dos parâmetros de query string da API, especificamente SELECT e filter, correspondem a padrões que o motor de detecção do OWASP CRS 3.2 associa a tentativas de injeção SQL. O ruleId 942100 utiliza a biblioteca libinjection para detectar padrões de SQL injection em variáveis de requisição, incluindo argumentos de query string. Como a API usa convenções de nomenclatura que coincidem com palavras reservadas SQL, o WAF interpreta as requisições como maliciosas.
A pista definitiva no enunciado está na combinação de três elementos: o ruleId 942100 com a mensagem "SQL Injection Attack Detected via libinjection", a variável de match args, e o valor SELECT=value&filter=active. O log mostra com precisão que são os nomes dos parâmetros, não os valores, que disparam a regra.
A informação irrelevante é a configuração do NSG. O log confirma que a requisição chegou ao WAF e foi processada, o que descarta qualquer hipótese de bloqueio de rede antes do WAF. O NSG não tem relação com o falso positivo.
O principal erro de raciocínio dos distratores é direcionar o diagnóstico para a infraestrutura (NSG em A) ou para limitações de produto inexistentes (C), em vez de focar na evidência direta do log. A alternativa D é o distrator mais perigoso: desabilitar o ruleId 942100 inteiramente removeria proteção contra SQL injection de toda a aplicação, quando a solução correta é configurar uma exclusão cirúrgica apenas para os campos e endpoints afetados.
Gabarito — Cenário 2
Resposta: B
O impacto colateral real é a exposição de falsos positivos que existiam antes da mudança de modo mas nunca haviam sido tratados. Em modo Detection, o WAF avalia todas as requisições, registra as que correspondem às regras, mas não bloqueia nenhuma. Em modo Prevention, as mesmas regras passam a bloquear ativamente. Se falsos positivos existiam no modo Detection sem tratamento, eles se tornam bloqueios reais imediatamente após a transição.
O cenário confirma isso ao indicar que nenhuma regra foi alterada e que a aplicação não foi modificada. Os erros 403 nas funcionalidades de busca avançada e upload de documentos são exatamente o perfil de endpoints que costumam gerar falsos positivos em regras de SQL injection e File Upload do CRS, respectivamente.
O distrator mais perigoso é D, porque descreve um comportamento que não existe: a mudança de modo no WAF do Azure Front Door Premium não causa reinicialização do perfil nem indisponibilidade. Agir com base em D levaria o time a abrir um chamado de suporte sobre um comportamento inexistente, perdendo tempo enquanto os usuários continuam bloqueados.
A consequência prática deste cenário é que a transição de Detection para Prevention deve sempre ser precedida por um período de análise e tratamento de falsos positivos identificados nos logs de Detection.
Gabarito — Cenário 3
Resposta: C
A causa raiz é que o domínio api.contoso.com não está associado à política WAF. No Azure Front Door Premium, uma política WAF deve ser associada explicitamente a cada domínio ou endpoint que se deseja proteger. A associação não é automática para todos os domínios do perfil. O próprio output de configuração no enunciado mostra claramente: api.contoso.com (Not associated).
A pista definitiva é a ausência de registros de bloqueio no WAF para api.contoso.com, enquanto os bloqueios para app.contoso.com funcionam corretamente. Isso elimina qualquer hipótese de problema na regra em si ou no conjunto de regras gerenciadas, já que ambos os domínios usariam a mesma política se ela estivesse associada.
A informação irrelevante é a menção à região East US onde a política foi criada. Políticas WAF associadas ao Azure Front Door são globais por natureza e não têm escopo regional. A região de criação não afeta a cobertura ou a propagação da política.
O distrator mais perigoso é A, porque a premissa de que políticas criadas em uma região específica não se propagam globalmente é falsa para o Front Door, mas plausível para quem confunde com serviços regionais. Agir com base em A levaria à criação desnecessária de políticas duplicadas, aumentando complexidade operacional sem resolver o problema real.
Gabarito — Cenário 4
Resposta: B
A ação correta é configurar uma exclusão de regra WAF que remova o campo de formulário específico da avaliação do ruleId 931130. O mecanismo de exclusão do WAF permite definir com precisão qual variável de requisição (nome do campo, cabeçalho, cookie) deve ser excluída da avaliação de uma regra ou conjunto de regras específico, sem afetar a proteção das demais requisições.
O contexto de restrição determinante é a produção ativa com impacto contratual. A alternativa A desabilita globalmente o ruleId 931130, o que remove proteção contra Remote File Inclusion de toda a aplicação, não apenas do campo problemático. A alternativa C migra para Detection temporariamente, o que é contraproducente: a causa já foi confirmada e a mudança de modo expõe toda a aplicação enquanto o diagnóstico adicional não agrega valor.
A alternativa D é tecnicamente plausível e frequentemente usada, mas apresenta um risco específico neste cenário: criar uma regra Allow por IP para todos os parceiros externos libera o endpoint de upload completamente para esses IPs, incluindo proteção contra outras ameaças além do ruleId 931130. A exclusão de regra é cirúrgica e mantém todas as demais proteções ativas para o mesmo tráfego.
A exclusão bem configurada especifica: o campo de formulário exato, o operador de correspondência, e o escopo restrito ao ruleId 931130, o que preserva o princípio de menor privilégio na configuração do WAF.
Árvore de Troubleshooting: Design a WAF Deployment
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz da árvore) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o WAF está bloqueando tráfego legítimo ou deixando de inspecionar tráfego esperado. A primeira bifurcação verifica se há registros nos logs, o que imediatamente separa problemas de associação de política de problemas de configuração de regras. Siga as perguntas respondendo apenas com o que pode ser verificado diretamente no portal, nos logs de diagnóstico ou na configuração da política, sem presumir a causa. Cada ramificação elimina uma classe de hipótese até que você chegue a uma causa específica com a ação correspondente.