Pular para o conteúdo principal

Laboratório de Troubleshooting: Configure rule sets for WAF on Azure Front Door

Cenários de Diagnóstico​

Cenário 1 — Causa Raiz​

Uma equipe configurou um WAF Policy associado a um Azure Front Door Premium para proteger uma aplicação de e-commerce. O WAF está em modo Prevention com o managed rule set Microsoft_DefaultRuleSet_2.1 ativado. Nenhuma regra customizada foi adicionada.

Após a implantação, a equipe de testes reporta que requisições de um scanner de vulnerabilidades interno estão sendo bloqueadas, o que era esperado. Porém, um conjunto de usuários legítimos na Alemanha também começa a relatar bloqueios esporádicos ao tentar acessar a página de checkout. Os logs mostram:

{
  "category": "FrontDoorWebApplicationFirewallLog",
  "properties": {
    "clientIP": "85.214.132.117",
    "requestUri": "/checkout?promo=SAVE10&ref=email_campaign_march",
    "ruleName": "Microsoft_DefaultRuleSet-2.1-LFI-930110",
    "action": "Block",
    "details": {
      "message": "Path Traversal Attack (/../)",
      "data": "SAVE10/../"
    }
  }
}

Informações adicionais:

  • O Front Door Premium foi implantado há três semanas sem incidentes
  • A equipe de marketing lançou uma campanha promocional na semana anterior com códigos de cupom gerados automaticamente
  • O certificado do domínio customizado foi renovado dois dias antes dos bloqueios começarem
  • O parâmetro ref da URL é rastreamento de campanha de e-mail e nunca é processado pelo backend
  • Não há exclusões de regra no WAF Policy

Qual é a causa raiz do problema?

A) A renovação do certificado do domínio customizado alterou a forma como o Front Door inspeciona parâmetros de URL, gerando falsos positivos na regra de LFI.

B) O código de cupom gerado automaticamente pela equipe de marketing contém a sequência /../ que corresponde ao padrão de Path Traversal detectado pela regra LFI-930110, gerando falsos positivos para usuários com esse cupom.

C) O parâmetro ref de rastreamento de campanha de e-mail está sendo interpretado pelo WAF como um vetor de injeção, causando os bloqueios esporádicos.

D) O managed rule set Microsoft_DefaultRuleSet_2.1 possui sensibilidade elevada para IPs europeus após atualização automática realizada na semana anterior.

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

Um administrador reporta que, após migrar um WAF Policy de Azure Front Door Classic para Azure Front Door Premium, algumas requisições que antes passavam livremente agora são bloqueadas em produção. O WAF está em modo Prevention com o managed rule set Microsoft_DefaultRuleSet_2.1 e um conjunto de regras customizadas migradas manualmente.

Os passos de investigação disponíveis são:

  1. Comparar as regras customizadas migradas com as originais para verificar se prioridades, condições e ações foram preservadas corretamente.
  2. Verificar nos logs do WAF quais regras específicas estão gerando os bloqueios e se são do managed rule set ou das regras customizadas.
  3. Confirmar que o WAF Policy está associado corretamente ao perfil do Front Door Premium e não a outro recurso.
  4. Verificar se o managed rule set Microsoft_DefaultRuleSet_2.1 possui regras equivalentes às que estavam ativas no Front Door Classic e se o comportamento padrão mudou entre versões.
  5. Analisar os logs do Front Door para confirmar que o tráfego está chegando ao Front Door antes de ser avaliado pelo WAF.

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

A) 3 → 5 → 2 → 4 → 1

B) 5 → 3 → 2 → 1 → 4

C) 2 → 1 → 4 → 3 → 5

D) 3 → 2 → 4 → 1 → 5

Cenário 3 — Causa Raiz​

Uma empresa configurou um WAF Policy no Azure Front Door Premium com as seguintes regras customizadas para proteger uma API interna:

Regra 1 — Prioridade 5
  Nome: AllowInternalMonitoring
  Tipo: MatchRule
  Condição: IPMatch — 10.0.0.0/8
  Ação: Allow

Regra 2 — Prioridade 20
  Nome: BlockScanners
  Tipo: MatchRule
  Condição: RequestHeader "User-Agent" contém "Nmap" OR "Nikto" OR "sqlmap"
  Ação: Block

Regra 3 — Prioridade 30
  Nome: RateLimitAPI
  Tipo: RateLimitRule
  Condição: RequestUri começa com "/api/"
  Limite: 100 requisições por minuto por IP
  Ação: Block

O managed rule set Microsoft_DefaultRuleSet_2.1 também está ativo.

A equipe de monitoramento interno reporta que suas ferramentas de health check, executadas a partir do range 10.0.0.0/8, estão sendo bloqueadas intermitentemente. Os logs indicam que o bloqueio é gerado pela regra RateLimitAPI. A ferramenta de health check faz 150 requisições por minuto para /api/health.

Informações adicionais:

  • A ferramenta de health check foi configurada há seis meses sem alterações
  • O time de segurança atualizou a lista de User-Agents bloqueados na semana anterior
  • O range 10.0.0.0/8 foi confirmado como correto para toda a rede interna
  • O Front Door Premium está na versão mais recente

Qual é a causa raiz do problema?

A) A atualização da lista de User-Agents bloqueados na semana anterior incluiu inadvertidamente o User-Agent da ferramenta de health check, causando os bloqueios pela regra BlockScanners.

B) A regra AllowInternalMonitoring com ação Allow interrompe a avaliação das demais regras customizadas, mas não impede a aplicação do managed rule set, que está bloqueando o health check.

C) A regra RateLimitAPI com prioridade 30 é avaliada para IPs do range 10.0.0.0/8 porque a ação Allow da regra de prioridade 5 não interrompe a avaliação de regras customizadas do tipo RateLimitRule em versões recentes do Front Door Premium.

D) A ferramenta de health check excede o limite de 100 requisições por minuto configurado na regra RateLimitAPI, e a regra AllowInternalMonitoring com ação Allow interrompe a avaliação apenas das regras do managed rule set, não das demais regras customizadas.

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

A equipe identificou que o managed rule set Microsoft_DefaultRuleSet_2.1 está bloqueando requisições de uma aplicação parceira que envia payloads JSON com campos cujos nomes contêm colchetes, como filter[status] e filter[date]. A regra MS-ThreatIntel-WebShells-99005 está sendo acionada para esses campos.

A causa foi confirmada: o padrão de nomenclatura com colchetes nos campos JSON corresponde a uma assinatura de detecção de WebShell no rule set.

Contexto e restrições:

  • O ambiente é de produção com SLA acordado com o parceiro
  • A aplicação parceira não pode ser modificada para alterar o formato dos campos
  • A equipe possui permissão de escrita na WAF Policy
  • Existe um processo de change management que exige aprovação para alterações em managed rule sets, com prazo mínimo de 48 horas
  • O impacto está ocorrendo há 6 horas e o parceiro está monitorando a situação
  • Desabilitar o managed rule set completo violaria requisitos de conformidade da empresa

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

A) Desabilitar o managed rule set Microsoft_DefaultRuleSet_2.1 temporariamente para restaurar a integração com o parceiro enquanto o processo de change management é iniciado.

B) Iniciar imediatamente o processo de change management para aprovar a criação de uma exclusão de regra específica para a regra MS-ThreatIntel-WebShells-99005 aplicada aos campos filter[status] e filter[date], e comunicar o parceiro sobre o prazo estimado de resolução.

C) Criar uma regra customizada com prioridade mais alta que o managed rule set para permitir explicitamente requisições do IP do parceiro, contornando o bloqueio sem alterar o managed rule set.

D) Mudar o WAF Policy para modo Detection imediatamente para restaurar o funcionamento da integração e iniciar o processo de change management em paralelo.

Gabarito e Explicações​

Gabarito — Cenário 1​

Resposta: B

O log é a pista central e decisiva. O campo data do log mostra explicitamente SAVE10/../, indicando que o WAF concatenou o valor do parâmetro promo com outros elementos da URL e identificou a sequência /../ como um padrão de Path Traversal. O code de cupom SAVE10 contém a sequência que, ao ser processada pela regra LFI-930110, corresponde ao padrão de ataque. O início dos bloqueios coincide com o lançamento da campanha de marketing, o que confirma a correlação temporal.

A informação sobre a renovação do certificado é irrelevante. O WAF no Front Door Premium opera na camada de aplicação após a terminação TLS; mudanças de certificado não afetam a lógica de inspeção de parâmetros de URL.

O distrator mais perigoso é o C, pois direciona a atenção para o parâmetro ref, que é mencionado no enunciado e está visível na URL. Porém, o log mostra claramente que o dado problemático está no parâmetro promo, não no ref. Investigar o parâmetro errado levaria a uma exclusão de regra incorreta que não resolveria o bloqueio.

Gabarito — Cenário 2​

Resposta: A

A sequência correta é 3 → 5 → 2 → 4 → 1.

O diagnóstico deve começar confirmando que o WAF Policy está associado ao recurso correto (passo 3), pois uma associação incorreta após a migração explicaria comportamentos inesperados sem necessidade de investigar regras. Em seguida, confirmar que o tráfego está chegando ao Front Door (passo 5) valida a camada de transporte antes de investigar o WAF. Com isso confirmado, os logs do WAF (passo 2) indicam se o bloqueio vem do managed rule set ou das regras customizadas, direcionando a investigação. Se o bloqueio vier do managed rule set, comparar versões e comportamentos padrão (passo 4) é o próximo passo lógico. Só por último faz sentido comparar as regras customizadas migradas (passo 1), pois o contexto anterior já terá delimitado se esse é o caminho relevante.

O distrator C começa diretamente pela análise de logs, sem verificar primeiro se a associação e o roteamento estão corretos. Logs de WAF só fazem sentido depois de confirmar que o tráfego está chegando ao recurso certo.

Gabarito — Cenário 3​

Resposta: D

No Azure Front Door WAF, quando uma regra customizada do tipo MatchRule tem ação Allow, ela interrompe a avaliação das demais regras do mesmo tipo MatchRule e impede a avaliação do managed rule set. Porém, regras do tipo RateLimitRule são avaliadas de forma independente e não são interrompidas pela ação Allow de uma MatchRule. Portanto, mesmo que a ferramenta de health check seja permitida pela regra AllowInternalMonitoring, a regra RateLimitAPI ainda é avaliada e bloqueia as 150 requisições por minuto que excedem o limite de 100.

A pista está nos tipos de regra: a regra de Allow é do tipo MatchRule e a regra de rate limit é do tipo RateLimitRule. Esses dois tipos têm comportamentos distintos na cadeia de avaliação.

A informação sobre a atualização da lista de User-Agents é irrelevante. O log indica que o bloqueio vem da regra RateLimitAPI, não da regra BlockScanners, e o User-Agent da ferramenta de health check não foi mencionado como scanner.

O distrator mais perigoso é o C, pois contém a afirmação tecnicamente correta de que RateLimitRule é avaliada independentemente, mas atribui isso a "versões recentes do Front Door Premium", sugerindo que se trata de uma mudança de comportamento recente. Isso induz o leitor a procurar uma nota de release ou uma atualização como causa, em vez de entender o comportamento fundamental dos tipos de regra.

Gabarito — Cenário 4​

Resposta: B

O contexto apresenta três restrições que eliminam as demais alternativas: o processo de change management com prazo mínimo de 48 horas, a proibição de desabilitar o managed rule set completo por conformidade, e a impossibilidade de modificar a aplicação parceira. A única ação que respeita todas as restrições é iniciar imediatamente o processo correto (exclusão de regra específica) dentro do canal de aprovação formal e comunicar o parceiro sobre o prazo.

O distrator A viola diretamente o requisito de conformidade que proíbe desabilitar o managed rule set completo.

O distrator C parece uma solução criativa, mas uma regra customizada de Allow para o IP do parceiro com prioridade alta contornaria não apenas a regra problemática, mas todo o managed rule set para esse IP, o que também pode violar requisitos de conformidade e cria uma superfície de ataque não gerenciada se o IP do parceiro for comprometido.

O distrator D muda o WAF inteiro para Detection, removendo proteção de todas as regras para toda a aplicação, o que é desproporcional ao problema e pode igualmente violar requisitos de conformidade.

Árvore de Troubleshooting: Configuração de Rule Sets para WAF no Azure Front Door​

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

Legenda de cores:

CorTipo de nó
Azul escuroSintoma inicial (ponto de entrada)
Azul médioPergunta diagnóstica
VermelhoCausa identificada
VerdeAção recomendada ou resolução
LaranjaValidação ou verificação intermediária

Diante de um problema real com rule sets do WAF no Azure Front Door, comece pelo nó raiz e responda cada pergunta com base no que é diretamente verificável: associação do WAF Policy, presença de logs, tipo de regra que gerou o bloqueio e configuração de exclusões ou prioridades. Os nós laranja de validação sinalizam momentos em que é necessário coletar informação adicional dos logs antes de continuar. Siga o caminho até o nó vermelho de causa identificada e aplique a ação verde correspondente. Se a ação não resolver completamente, retorne ao nó de validação anterior e explore o caminho alternativo restante.