Laboratório de Troubleshooting: Implement a WAF Policy

Cenários de Diagnóstico

Cenário 1 — Causa Raiz

Uma empresa implantou um Azure Front Door Premium com uma WAF Policy associada para proteger uma aplicação web global. O time de segurança configurou a policy com o ruleset Microsoft_DefaultRuleSet_2.1 e a associou ao endpoint do Front Door. Após a implantação, o time de desenvolvimento reporta que a aplicação funciona normalmente a partir de acessos internos, mas clientes externos em múltiplos países recebem respostas HTTP 403 de forma intermitente.

O analista consulta os logs e encontra:

{
  "category": "FrontdoorWebApplicationFirewallLog",
  "properties": {
    "clientIP": "189.28.14.5",
    "requestUri": "/api/v2/search?q=<script>alert(1)</script>",
    "action": "Block",
    "ruleName": "Microsoft_DefaultRuleSet-2.1-XSS-942110",
    "policyMode": "Prevention",
    "trackingReference": "0H3MK2...",
    "host": "app.contoso.com"
  }
}

Informações adicionais:

• A WAF Policy foi criada no modo Prevention desde o início, sem período prévio em Detection
• O Front Door Premium foi provisionado há 10 dias
• O certificado TLS customizado foi importado do Key Vault há 5 dias
• Acessos internos usam IPs da faixa 10.0.0.0/8 que estão em uma lista de exclusão configurada na policy
• O time de redes atualizou as origens do Front Door na semana passada

Qual é a causa raiz do problema observado?

A. O certificado TLS customizado importado do Key Vault há 5 dias está causando falhas de handshake TLS para clientes externos, resultando em respostas 403.

B. A WAF Policy foi implantada diretamente em modo Prevention sem período de validação em Detection, e requisições de clientes externos que contêm padrões detectados como XSS estão sendo bloqueadas, incluindo potencialmente falsos positivos não identificados previamente.

C. A atualização das origens do Front Door na semana passada causou uma dessincronização entre a WAF Policy e os novos backends, fazendo com que requisições externas sejam rejeitadas.

D. A lista de exclusão configurada para IPs internos 10.0.0.0/8 está aplicando uma lógica invertida e bloqueando todos os IPs fora dessa faixa, incluindo clientes externos legítimos.

---

Cenário 2 — Sequência de Diagnóstico

Um administrador recebe o chamado: uma WAF Policy associada a um Application Gateway v2 não está bloqueando requisições maliciosas conhecidas, mesmo estando no modo Prevention. O ruleset configurado é OWASP CRS 3.2. O administrador precisa diagnosticar por que a proteção não está funcionando.

Os passos disponíveis para a investigação são:

• (P) Verificar nos logs ApplicationGatewayFirewallLog se as requisições maliciosas aparecem como Detected ou Blocked ou se não aparecem nos logs
• (Q) Confirmar que a WAF Policy está no estado Enabled e associada ao listener correto do Application Gateway
• (R) Verificar se o modo da WAF Policy está definido como Prevention e não como Detection
• (S) Confirmar que as configurações de diagnóstico do Application Gateway incluem a categoria ApplicationGatewayFirewallLog enviando para o Log Analytics
• (T) Testar com uma requisição de teste contendo payload OWASP conhecido, como um scanner Nikto simulado, e observar o comportamento

Qual é a sequência correta de investigação?

A. T → P → Q → R → S

B. Q → R → S → T → P

C. S → Q → T → P → R

D. R → Q → P → T → S

---

Cenário 3 — Causa Raiz

O time de segurança de uma empresa migrou a WAF Policy de um Application Gateway da versão de política Classic para uma política do tipo WAF Policy Resource (recurso independente) para ganhar flexibilidade no gerenciamento. Após a migração, o administrador confirma que a nova WAF Policy Resource está no modo Prevention com o ruleset OWASP CRS 3.2 configurado corretamente.

Dois dias após a migração, o time de desenvolvimento reporta que os custom rules que bloqueavam IPs de um range específico de um concorrente deixaram de funcionar. Requisições originadas do IP 198.51.100.0/24 que antes eram bloqueadas agora chegam à aplicação normalmente.

O administrador verifica a nova WAF Policy Resource e confirma:

WAF Policy: waf-policy-prod
Modo: Prevention
Ruleset: OWASP_CRS 3.2
Estado: Enabled
Associacao: Application Gateway - appgw-prod (HTTP Listener: listener-https)

Custom Rules:
  (nenhuma custom rule configurada)

Informações adicionais:

• A WAF Policy Resource foi criada a partir do zero durante a migração
• O Application Gateway está no SKU WAF_v2
• A política Classic anterior foi desassociada e está marcada para exclusão
• O time de infraestrutura atualizou as tags de billing dos recursos na semana passada

Qual é a causa raiz do problema observado?

A. A atualização das tags de billing na semana passada causou um reset nas configurações de segurança da WAF Policy Resource, removendo as custom rules automaticamente.

B. O SKU WAF_v2 do Application Gateway não suporta custom rules em WAF Policy Resources e requer que as regras de bloqueio por IP sejam configuradas como regras de rede no NSG da subnet.

C. As custom rules que existiam na política Classic não foram recriadas na nova WAF Policy Resource durante a migração, resultando na ausência das regras de bloqueio por IP.

D. A WAF Policy Resource só aplica custom rules quando o ruleset OWASP está desabilitado, e a presença do CRS 3.2 ativo está suprimindo a avaliação das custom rules.

---

Cenário 4 — Decisão de Ação

O time de segurança identificou que a WAF Policy associada ao Azure Front Door de uma aplicação de saúde está em modo Detection há quatro meses. Durante esse período, os logs acumularam dados suficientes e a análise mostra que existem três regras do ruleset Microsoft_DefaultRuleSet_2.1 que geram falsos positivos recorrentes para endpoints legítimos da aplicação:

• Regra 942200 disparando no endpoint /api/patient/search por conta de parâmetros de busca médica
• Regra 931130 disparando no endpoint /api/documents/upload por conta de nomes de arquivos com extensões específicas
• Regra 920350 disparando em todos os endpoints por conta do formato do header Host usado pelo cliente mobile

A aplicação processa dados de saúde e o requisito de conformidade exige ativação do modo Prevention. O time de segurança tem acesso completo à WAF Policy.

Qual é a ação correta a tomar neste momento?

A. Ativar o modo Prevention imediatamente, pois quatro meses de dados em Detection são suficientes para confirmar que o ambiente está pronto, e os falsos positivos podem ser tratados com exclusões após a ativação.

B. Criar exclusões de regra específicas para cada uma das três regras nos endpoints e parâmetros exatos onde os falsos positivos ocorrem, validar nos logs em modo Detection que os falsos positivos foram eliminados, e só então ativar o modo Prevention.

C. Desativar as três regras identificadas como fontes de falsos positivos na WAF Policy antes de ativar o modo Prevention, garantindo que nenhum bloqueio legítimo ocorra após a transição.

D. Substituir o ruleset Microsoft_DefaultRuleSet_2.1 pelo ruleset DRS 1.0 que possui menos regras e menor chance de gerar falsos positivos antes de ativar o Prevention.

---

Gabarito e Explicações

Gabarito — Cenário 1

Resposta: B

O log confirma que o bloqueio está ocorrendo pela regra XSS-942110 do ruleset Microsoft_DefaultRuleSet_2.1, com action: Block e policyMode: Prevention. A causa raiz é que a WAF Policy foi colocada diretamente em modo Prevention sem nenhum período de operação em Detection, o que significa que falsos positivos nunca foram identificados e tratados antes de o bloqueio ser ativado. Requisições de clientes externos que contêm padrões interpretados como XSS, incluindo potencialmente conteúdo legítimo, estão sendo bloqueadas.

A pista confirmatória central está no enunciado: "A WAF Policy foi criada no modo Prevention desde o início, sem período prévio em Detection." Isso é o indicador direto de que o processo correto de validação foi pulado.

Informações irrelevantes: O certificado TLS importado do Key Vault afeta a camada de transporte, não a inspeção de payload do WAF. A atualização das origens do Front Door afeta o roteamento de backend, não a aplicação de regras da WAF Policy. Ambos os detalhes foram inseridos para desviar o diagnóstico.

O distrator mais perigoso é o D, que leva o administrador a investigar e potencialmente modificar a lista de exclusão de IPs internos, uma configuração de segurança sensível, quando o problema está na ausência de validação prévia das regras em modo Detection.

---

Gabarito — Cenário 2

Resposta: B

A sequência correta é Q → R → S → T → P:

1. Confirmar que a WAF Policy está habilitada e associada ao listener correto (Q) é o pré-requisito absoluto. Se a policy não estiver associada, nenhuma inspeção ocorre e todos os outros passos são irrelevantes.
2. Verificar se o modo está em Prevention e não em Detection (R) é o segundo passo, pois em Detection o comportamento correto é não bloquear, o que explicaria o sintoma sem indicar defeito.
3. Confirmar que os logs de firewall estão sendo enviados ao Log Analytics (S) é necessário antes de executar testes, pois sem isso não há como observar o resultado nos logs.
4. Executar um teste controlado com payload conhecido (T) gera evidência observável.
5. Analisar os logs resultantes (P) fecha o diagnóstico com base em evidência concreta.

A alternativa A começa com o teste antes de validar se a policy está associada e se os logs funcionam, o que pode gerar testes sem resultado observável. A alternativa C começa pela configuração de diagnóstico, pulando a verificação de associação da policy. A alternativa D verifica o modo antes da associação, o que é logicamente correto mas inverte a prioridade.

---

Gabarito — Cenário 3

Resposta: C

A seção de custom rules da nova WAF Policy Resource está vazia: (nenhuma custom rule configurada). Quando uma WAF Policy Resource é criada do zero durante uma migração, ela contém apenas o que foi explicitamente configurado nela. As custom rules da política Classic anterior não são migradas automaticamente para a nova WAF Policy Resource. O administrador precisaria recriá-las manualmente ou via script. Como as custom rules de bloqueio por IP não foram recriadas, o tráfego do range 198.51.100.0/24 não encontra nenhuma regra que o bloqueie e passa normalmente.

A pista confirmatória está em dois elementos combinados: o campo Custom Rules: (nenhuma custom rule configurada) na nova policy e a informação de que ela "foi criada a partir do zero durante a migração."

Informação irrelevante: A atualização de tags de billing não afeta configurações funcionais de WAF. Tags são metadados de organização e faturamento sem impacto no comportamento das políticas.

O distrator mais perigoso é o B, pois leva o administrador a concluir erroneamente que custom rules não são suportadas no SKU WAF_v2 com WAF Policy Resources, quando na realidade são totalmente suportadas. Agir com base nessa conclusão levaria a uma busca por soluções alternativas desnecessárias, como regras de NSG, perdendo tempo enquanto a solução correta é simplesmente recriar as custom rules na nova policy.

---

Gabarito — Cenário 4

Resposta: B

A ação correta é criar exclusões de regra específicas e cirúrgicas para cada falso positivo identificado, validar que os falsos positivos foram eliminados nos logs ainda em modo Detection, e só então ativar o modo Prevention. Essa abordagem usa o modo Detection como ambiente de validação para as exclusões antes de ativar o bloqueio, garantindo que a transição para Prevention não cause bloqueios de requisições legítimas em uma aplicação de saúde crítica.

A alternativa A comete o mesmo erro do Cenário 1: ativar Prevention antes de tratar os falsos positivos conhecidos, com a agravante de que aqui os falsos positivos já foram identificados e documentados, tornando ainda mais injustificável ignorá-los. A alternativa C é desproporcional: desativar regras inteiras remove proteção contra ameaças reais para resolver falsos positivos que ocorrem apenas em endpoints e parâmetros específicos. A exclusão de regra cirúrgica é sempre preferível à desativação da regra. A alternativa D introduz risco de regressão de segurança ao substituir um ruleset mais completo por um mais simples sem análise do impacto na postura de segurança da aplicação.

O princípio central aqui é a proporcionalidade da ação corretiva: exclusões cirúrgicas preservam a proteção geral enquanto eliminam especificamente os falsos positivos documentados.

---

Árvore de Troubleshooting: Implement a WAF Policy

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Legenda de cores:

Cor	Tipo de nó
Azul escuro	Sintoma inicial (raiz)
Azul	Pergunta diagnóstica
Vermelho	Causa identificada
Verde	Ação recomendada ou resolução
Laranja	Validação ou verificação intermediária

Para usar a árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente. Os dois primeiros passos são sempre verificar se a WAF Policy está habilitada e se está associada ao recurso correto, pois sem essas condições nenhuma proteção ocorre. Em seguida, confirme o modo: Detection registra mas não bloqueia, e esse é o comportamento esperado. Com o modo Prevention confirmado, divida o diagnóstico conforme o sintoma: bloqueio de tráfego legítimo aponta para falsos positivos que exigem exclusões cirúrgicas; ausência de bloqueio de ameaças aponta para custom rules ausentes ou logs não configurados. Cada caminho termina em uma ação proporcional e precisa.