Laboratório de Troubleshooting: Map requirements to features and capabilities of WAF
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de segurança configurou um Azure Web Application Firewall (WAF) em modo Prevention associado a um Azure Application Gateway v2. A aplicação protegida é um portal web corporativo acessível pela internet.
Após a ativação, usuários legítimos começaram a relatar que determinadas requisições são bloqueadas com resposta HTTP 403. A equipe revisou os logs e encontrou o seguinte:
{
"timeStamp": "2025-03-10T14:22:31Z",
"resourceId": "/subscriptions/.../applicationGateways/agw-prod",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_0",
"clientIp": "203.0.113.45",
"requestUri": "/api/search?q=1+1%3D1",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.2",
"ruleId": "942100",
"message": "SQL Injection Attack Detected via libinjection",
"action": "Blocked",
"hostname": "portal.contoso.com",
"transactionId": "abc123"
}
}
Detalhes adicionais fornecidos pela equipe:
- O WAF utiliza o CRS 3.2 sem customizações
- A aplicação usa autenticação via Microsoft Entra ID com tokens JWT
- O campo
qda URL é um campo de busca livre que aceita expressões matemáticas como entrada válida de usuário - O certificado TLS do Application Gateway foi renovado na semana anterior
- Não há exclusões de regra configuradas no WAF Policy
Qual é a causa raiz do problema?
A) O certificado TLS renovado alterou o comportamento de inspeção de payloads criptografados pelo WAF.
B) A autenticação via Microsoft Entra ID com tokens JWT gera cabeçalhos que conflitam com a regra 942100 do CRS.
C) O WAF em modo Prevention está bloqueando uma entrada válida de usuário que corresponde a um padrão de injeção SQL na regra 942100 do CRS, sem exclusão configurada para esse campo.
D) O CRS 3.2 possui um bug conhecido que bloqueia expressões matemáticas em parâmetros de URL independentemente do contexto.
Cenário 2 — Impacto Colateral
A equipe de segurança de uma empresa identificou que o WAF associado a um Azure Front Door Premium estava operando em modo Detection desde a implantação, sem nunca ter sido promovido para modo Prevention. A decisão foi tomada de promover o modo imediatamente para Prevention em produção, sem um período adicional de análise dos logs.
A promoção foi realizada com sucesso. No dia seguinte, o time de operações confirmou que nenhum ataque foi registrado nos logs de bloqueio.
Qual consequência secundária essa ação pode causar?
A) O Azure Front Door Premium entra automaticamente em modo de manutenção ao detectar a mudança de política WAF, gerando indisponibilidade temporária.
B) Requisições legítimas que historicamente correspondiam a regras do CRS e não foram investigadas durante o período em Detection podem passar a ser bloqueadas, causando falsos positivos em produção.
C) O WAF em modo Prevention desabilita automaticamente os logs de Detection, impedindo que a equipe continue monitorando tentativas de ataque não bloqueadas.
D) A mudança para Prevention invalida todas as exclusões de regra configuradas previamente, exigindo que sejam recriadas manualmente.
Cenário 3 — Causa Raiz
Uma empresa implantou um WAF Policy associado a um Azure Front Door Premium para proteger uma API REST. O requisito de segurança exige que requisições originadas de um conjunto específico de endereços IP de parceiros comerciais sejam sempre permitidas, independentemente das regras do CRS.
A equipe configurou o seguinte conjunto de regras customizadas na WAF Policy:
| Prioridade | Nome | Tipo | Condição | Ação |
|---|---|---|---|---|
| 10 | BlockHighRisk | MatchRule | GeoMatch: CN, RU, KP | Block |
| 50 | AllowPartners | MatchRule | IPMatch: 198.51.100.0/24 | Allow |
| 100 | DefaultDeny | MatchRule | RequestUri: / | Block |
Após a implantação, um parceiro reporta que suas requisições originadas de 198.51.100.15 estão sendo bloqueadas com resposta 403 antes de chegar à API. Os logs mostram que a regra BlockHighRisk está sendo acionada para essas requisições.
Informações adicionais:
- O Front Door Premium está configurado com WAF Policy no modo Prevention
- O parceiro confirmou que o endereço IP
198.51.100.15é um IP fixo corporativo - A equipe de redes verificou que não há NAT ou proxy entre o parceiro e o Front Door
- O domínio do parceiro foi registrado recentemente em um TLD diferente do habitual
Qual é a causa raiz do problema?
A) O domínio do parceiro registrado em um TLD diferente está sendo interpretado pelo WAF como origem suspeita, acionando a regra BlockHighRisk.
B) A condição GeoMatch da regra BlockHighRisk está classificando o IP 198.51.100.15 como pertencente a um dos países bloqueados, e como essa regra tem prioridade menor que AllowPartners, ela é avaliada primeiro e bloqueia a requisição.
C) O modo Prevention do WAF no Front Door Premium avalia todas as regras customizadas antes de aplicar qualquer ação de Allow, o que faz com que o Block da regra de menor número de prioridade prevaleça.
D) A regra AllowPartners com prioridade 50 é avaliada após a regra BlockHighRisk com prioridade 10, portanto a requisição do parceiro é bloqueada antes que a regra de permissão seja avaliada.
Cenário 4 — Decisão de Ação
A equipe de segurança identificou que o WAF Policy associado a um Application Gateway v2 está bloqueando requisições legítimas de um sistema de integração interno. A investigação confirmou que a regra 942450 do CRS está interpretando um campo de cabeçalho customizado do sistema como um padrão de SQL encoding.
Contexto e restrições:
- O ambiente é de produção com SLA de 99,9%
- O sistema de integração processa pedidos financeiros críticos e não pode ser modificado para alterar o formato do cabeçalho
- A janela de manutenção é sexta-feira à noite, mas o impacto já está ocorrendo desde segunda-feira
- A equipe possui permissão de escrita na WAF Policy
- Não há outro WAF Policy aplicado ao Application Gateway
- A mudança de modo para Detection resolveria o bloqueio, mas removeria a proteção de todas as outras regras
Qual é a ação correta a tomar neste momento?
A) Mudar o WAF Policy para modo Detection imediatamente para restaurar o funcionamento do sistema de integração enquanto uma solução definitiva é preparada.
B) Aguardar a janela de manutenção de sexta-feira para configurar uma exclusão de regra específica para a regra 942450 no cabeçalho afetado.
C) Configurar imediatamente uma exclusão de regra na WAF Policy para a regra 942450 aplicada ao cabeçalho customizado específico, sem alterar o modo do WAF nem desabilitar outras regras.
D) Desabilitar completamente o grupo de regras SQL Injection no CRS para eliminar falsos positivos relacionados a SQL encoding em toda a aplicação.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
O WAF em modo Prevention bloqueia requisições que correspondem a regras do CRS antes mesmo de qualquer lógica de aplicação ser executada. A regra 942100 detecta padrões de SQL Injection via libinjection, e a expressão 1+1%3D1 (que decodifica para 1+1=1) corresponde a esse padrão. Como não há exclusões de regra configuradas, a correspondência resulta em bloqueio imediato.
A pista central está na combinação de três elementos do enunciado: o WAF está em modo Prevention, não há exclusões configuradas, e o campo de busca aceita expressões matemáticas como entrada válida. Isso é um falso positivo clássico de WAF com CRS sem ajuste fino.
A informação sobre a renovação do certificado TLS é irrelevante. O WAF no Application Gateway inspeciona o tráfego após o término TLS, portanto mudanças no certificado não afetam as regras de inspeção de payload.
O distrator mais perigoso é o B, pois direciona a investigação para os tokens JWT do Microsoft Entra ID, um componente presente no ambiente mas sem relação causal com o bloqueio. Agir com base nisso levaria a uma investigação da camada de autenticação que não resolveria o problema.
Gabarito — Cenário 2
Resposta: B
O período em modo Detection serve exatamente para identificar quais requisições legítimas correspondem a regras do CRS antes de ativar o bloqueio. Quando essa análise não é realizada e o modo é promovido diretamente para Prevention, todas as correspondências que existiam silenciosamente passam a gerar bloqueios reais.
A pista está no enunciado: o WAF operou em Detection desde a implantação sem análise dos logs, e a promoção foi feita sem período adicional de revisão. A ausência de registros de bloqueio no dia seguinte não confirma que tudo está funcionando corretamente: pode indicar que tráfego legítimo está sendo bloqueado e os usuários ainda não reportaram.
O distrator C é tecnicamente falso: o modo Prevention não desabilita logs de Detection; ambos os tipos de log continuam disponíveis.
Gabarito — Cenário 3
Resposta: D
Em WAF Policies do Azure, as regras customizadas são avaliadas em ordem crescente de prioridade numérica. A regra com número menor é avaliada primeiro. A regra BlockHighRisk tem prioridade 10 e a regra AllowPartners tem prioridade 50. Quando o IP 198.51.100.15 corresponde à condição GeoMatch da regra de prioridade 10, a ação Block é aplicada imediatamente e a avaliação para. A regra de prioridade 50 nunca é alcançada.
A solução correta seria atribuir à regra AllowPartners uma prioridade numericamente menor que BlockHighRisk, por exemplo prioridade 5, para que ela seja avaliada antes.
A informação sobre o TLD diferente do domínio do parceiro é irrelevante. O WAF avalia GeoMatch com base no endereço IP de origem, não no domínio ou TLD da requisição.
O distrator B contém uma inversão sutil mas crítica: afirma que a regra BlockHighRisk tem prioridade menor que AllowPartners, o que é o oposto do que está na tabela. Leitores que não prestam atenção ao sentido do campo prioridade marcam esse distrator como correto.
Gabarito — Cenário 4
Resposta: C
A exclusão de regra no WAF Policy permite suprimir uma regra específica do CRS para um atributo específico da requisição, como um cabeçalho, parâmetro ou cookie, sem afetar nenhuma outra regra nem alterar o modo de operação do WAF. Essa é a ação cirúrgica correta diante de um falso positivo confirmado com causa identificada.
O contexto de restrições elimina as demais alternativas: a alternativa A remove proteção de todas as regras ao mudar para Detection, o que é desproporcional ao problema. A alternativa B ignora o impacto em produção que já dura dias e o SLA de 99,9%, tornando a espera pela janela de manutenção inaceitável. A alternativa D desabilita todo o grupo de regras de SQL Injection, expondo a aplicação a ataques reais de injeção SQL para resolver um problema restrito a uma única regra e um único cabeçalho.
O distrator mais perigoso é o A, pois resolve o sintoma imediatamente mas ao custo da proteção completa da aplicação em produção, o que pode ser mais danoso que o impacto original.
Árvore de Troubleshooting: WAF no Azure
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de um problema real com WAF, comece pelo nó raiz descrevendo o comportamento observado e responda cada pergunta com base no que é verificável diretamente: modo de operação do WAF, presença de logs, tipo de regra que gerou o bloqueio e configuração de exclusões ou regras customizadas. Cada ramificação estreita o diagnóstico até um nó vermelho de causa identificada, seguido da ação verde correspondente. Se a ação não resolver completamente, retorne ao último nó laranja de validação e explore o caminho alternativo.