Laboratório de Troubleshooting: Configure rule sets for WAF on Application Gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe alertas de que uma aplicação web corporativa hospedada atrás de um Application Gateway WAF v2 começou a bloquear requisições de um sistema de monitoramento interno. O WAF opera em modo Prevention com o conjunto de regras OWASP CRS 3.2 habilitado integralmente.
O sistema de monitoramento envia requisições HTTP GET periódicas com um cabeçalho customizado de autenticação para verificar a disponibilidade da aplicação. O time coleta o seguinte log:
{
"resourceId": ".../APPLICATIONGATEWAYS/APPGW-CORP",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw-corp_0",
"clientIp": "172.16.10.5",
"requestUri": "/health/status",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.2",
"ruleId": "920300",
"message": "Request Missing an Accept Header",
"action": "Blocked",
"details": {
"matchVariableName": "REQUEST_HEADERS",
"matchVariableValue": ""
}
}
}
O time observa que o sistema de monitoramento foi configurado há seis meses e funcionava sem problemas. Há três dias, um engenheiro atualizou o conjunto de regras do WAF de OWASP CRS 3.1 para OWASP CRS 3.2 durante uma janela de manutenção. A subnet do Application Gateway tem um NSG que permite tráfego de entrada na porta 443 de qualquer origem interna. O IP 172.16.10.5 pertence à rede de gerenciamento e está liberado no NSG.
Qual é a causa raiz do problema?
A) O NSG da subnet do Application Gateway foi modificado durante a janela de manutenção e está bloqueando as requisições do sistema de monitoramento antes de chegarem ao WAF.
B) A atualização para OWASP CRS 3.2 introduziu ou ativou a regra 920300, que bloqueia requisições sem cabeçalho Accept, e o sistema de monitoramento não envia esse cabeçalho.
C) O sistema de monitoramento passou a enviar requisições com frequência maior do que o limite de rate limiting configurado no Application Gateway, causando os bloqueios.
D) O IP 172.16.10.5 foi adicionado à lista de exclusão do WAF durante a janela de manutenção, criando um conflito de avaliação que resulta em bloqueio.
Cenário 2 — Decisão de Ação
O time de segurança de uma empresa financeira identificou que o WAF em seu Application Gateway v2 está em modo Detection desde a implantação, realizada há quatro meses. Os logs acumulados mostram um volume alto de hits em regras do conjunto OWASP CRS 3.2, incluindo os seguintes ruleIds com frequência relevante:
ruleId: 942200 hits: 1.847 action: Detected uri: /api/accounts
ruleId: 941100 hits: 312 action: Detected uri: /portal/search
ruleId: 920350 hits: 28 action: Detected uri: /health/check
ruleId: 931130 hits: 9 action: Detected uri: /upload/documents
A análise indica que os hits nos ruleIds 942200 e 941100 são majoritariamente falsos positivos gerados por parâmetros legítimos da API e do portal. Os hits no ruleId 931130 correspondem a tentativas reais de Remote File Inclusion registradas nos últimos 15 dias. Os hits no ruleId 920350 correspondem a requisições do sistema de healthcheck interno que não envia o cabeçalho Host completo.
A liderança de segurança determinou que o WAF deve ser migrado para o modo Prevention dentro de 48 horas por exigência regulatória. Não há janela de manutenção disponível nas próximas 24 horas.
Qual é a ação correta a tomar neste momento?
A) Migrar imediatamente para o modo Prevention sem alterações nas regras, aceitando os falsos positivos como risco temporário até a próxima janela de manutenção.
B) Configurar exclusões de regra para os ruleIds 942200 e 941100 com escopo nos campos e endpoints afetados, configurar exclusão para o ruleId 920350 no endpoint de healthcheck, e então migrar para o modo Prevention dentro do prazo regulatório.
C) Desabilitar os ruleIds 942200, 941100 e 920350 globalmente na política WAF, manter o ruleId 931130 ativo, e migrar para o modo Prevention imediatamente.
D) Solicitar extensão do prazo regulatório para realizar a análise completa dos falsos positivos antes da migração, pois migrar sem tratar os falsos positivos representa risco operacional maior do que permanecer em Detection.
Cenário 3 — Causa Raiz
Um engenheiro configurou um conjunto de regras customizadas em um WAF do Application Gateway v2 para bloquear tráfego de um intervalo de IPs de um provedor de VPN identificado em relatórios de ameaça. A configuração foi aplicada e validada no portal. Após 24 horas, o time de segurança verifica que requisições originadas de IPs dentro do intervalo bloqueado ainda estão chegando à aplicação backend sem bloqueio.
O engenheiro revisa a configuração e encontra o seguinte:
Custom Rules:
Rule Name: BlockVPNRange
Priority: 150
Match Condition:
Variable: RemoteAddr
Operator: IPMatch
Values: ["198.51.100.0/24"]
Negation: false
Action: Block
Managed Rules:
RuleSet: OWASP CRS 3.2
Rule Group: REQUEST-911-METHOD-ENFORCEMENT
Rule 911100 - Override: Allow
WAF Mode: Prevention
O engenheiro também menciona que o Application Gateway usa WAF Policy associada em nível de Listener, não em nível de Gateway. Há dois listeners configurados: listener-public (porta 443) e listener-admin (porta 8443). A política com a regra customizada está associada apenas ao listener-public. O tráfego problemático está chegando pela porta 8443.
Qual é a causa raiz do problema?
A) A regra customizada BlockVPNRange tem prioridade 150, que é processada após as regras gerenciadas do conjunto OWASP CRS 3.2, e o override Allow na regra 911100 está liberando o tráfego antes que a regra customizada seja avaliada.
B) O intervalo 198.51.100.0/24 não é um CIDR válido para o operador IPMatch do WAF do Application Gateway, causando falha silenciosa na avaliação da regra.
C) A política WAF com a regra BlockVPNRange está associada apenas ao listener-public, portanto o tráfego que chega pelo listener-admin na porta 8443 não é avaliado por essa política.
D) Políticas WAF associadas em nível de Listener não suportam regras customizadas de bloqueio por IP, exigindo que a regra seja configurada em uma política associada em nível de Gateway.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte reporte às 09h14: usuários de um sistema ERP acessado via Application Gateway WAF v2 estão recebendo erros HTTP 403 intermitentes ao tentar salvar registros com campos de texto livre. O WAF está em modo Prevention com OWASP CRS 3.2. Alguns usuários conseguem salvar sem erro, outros não, mesmo preenchendo os mesmos campos.
Os passos de investigação disponíveis são:
- Verificar nos logs do WAF quais ruleIds estão sendo disparados e quais valores de campo correspondem aos hits, identificando o padrão do conteúdo bloqueado
- Confirmar se o erro 403 está sendo gerado pelo WAF ou por outra camada da aplicação, verificando se há entrada correspondente nos logs de firewall para cada erro reportado
- Verificar se há uma exclusão de regra configurada para o endpoint de salvamento que possa estar incompleta ou mal configurada
- Comparar o conteúdo enviado pelos usuários afetados com o conteúdo dos usuários não afetados para identificar o padrão diferenciador
- Confirmar com o time de desenvolvimento se houve atualização recente no frontend que alterou o formato ou a codificação dos dados enviados no formulário
Qual é a sequência correta de investigação?
A) 2 -> 1 -> 4 -> 3 -> 5
B) 1 -> 3 -> 2 -> 5 -> 4
C) 5 -> 2 -> 1 -> 4 -> 3
D) 3 -> 1 -> 4 -> 2 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A causa raiz é a atualização do conjunto de regras de OWASP CRS 3.1 para OWASP CRS 3.2, que introduziu comportamento diferente na regra 920300. O CRS 3.2 tornou obrigatório o cabeçalho Accept em requisições HTTP, e o sistema de monitoramento não inclui esse cabeçalho em suas requisições de healthcheck. O log confirma isso com precisão: o ruleId 920300 com a mensagem "Request Missing an Accept Header" e o matchVariableValue vazio indicando ausência do cabeçalho.
A pista cronológica decisiva é que o sistema funcionava há seis meses e os bloqueios começaram três dias após a atualização do conjunto de regras. Essa correlação temporal elimina qualquer hipótese de mudança no sistema de monitoramento ou no NSG.
A informação irrelevante é a descrição do NSG e do IP 172.16.10.5. O log mostra que a requisição chegou ao WAF e foi processada por uma regra do conjunto OWASP, o que prova que o NSG não está bloqueando o tráfego. A liberação do IP no NSG não tem relação com a avaliação das regras WAF.
O principal erro de raciocínio dos distratores é focar na infraestrutura de rede (A) ou em hipóteses de rate limiting (C) quando o log entrega diretamente a regra e o motivo do bloqueio. O distrator mais perigoso é A: agir com base nele levaria o engenheiro a modificar o NSG sem efeito algum, enquanto o bloqueio persiste e o sistema de monitoramento continua gerando alertas falsos de indisponibilidade.
Gabarito — Cenário 2
Resposta: B
A ação correta é configurar exclusões cirúrgicas para os falsos positivos confirmados nos ruleIds 942200, 941100 e 920350, e então migrar para o modo Prevention dentro do prazo de 48 horas. Essa abordagem atende à exigência regulatória sem introduzir bloqueios operacionais em produção.
O contexto de restrição determinante é duplo: prazo regulatório de 48 horas e ausência de janela de manutenção por 24 horas. A alternativa A migra imediatamente sem tratar falsos positivos, o que causaria bloqueio de 1.847 requisições legítimas por dia na API de contas e 312 no portal de busca, impacto operacional direto e inaceitável. A alternativa C desabilita os ruleIds globalmente, o que é mais destrutivo do que uma exclusão: remove proteção de SQL injection e XSS de toda a aplicação, não apenas dos campos afetados. A alternativa D é inviável porque a exigência regulatória não é negociável no enunciado.
O ponto crítico que diferencia B de C é a precisão do remédio: exclusões de regra preservam a proteção para todos os demais endpoints e campos, enquanto desabilitar o ruleId globalmente cria uma lacuna de segurança abrangente. O ruleId 931130, que corresponde a ataques reais confirmados, não deve ser tocado, e a alternativa B preserva exatamente esse comportamento.
Gabarito — Cenário 3
Resposta: C
A causa raiz é que a política WAF contendo a regra BlockVPNRange está associada exclusivamente ao listener-public na porta 443. O tráfego problemático chega pelo listener-admin na porta 8443, que não tem nenhuma política WAF associada. Sem associação de política, o tráfego nesse listener passa pelo Application Gateway sem inspeção WAF.
A pista definitiva está na combinação de dois elementos explícitos no enunciado: a associação da política em nível de Listener e o fato de o tráfego problemático chegar pela porta 8443. O próprio output de configuração mostra que apenas o listener-public está coberto.
A alternativa A é o distrator mais sofisticado e perigoso porque descreve um comportamento real do WAF: regras customizadas são processadas antes das regras gerenciadas quando têm prioridade numérica menor. No entanto, isso é irrelevante aqui porque o problema não é de ordem de avaliação, mas de ausência de avaliação. Agir com base em A levaria o engenheiro a reordenar prioridades de regras sem qualquer efeito, pois o listener-admin nunca aplica a política.
A alternativa D descreve uma limitação que não existe: políticas WAF associadas em nível de Listener suportam regras customizadas normalmente.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2 -> 1 -> 4 -> 3 -> 5.
O raciocínio de diagnóstico progressivo exige confirmar a origem do erro antes de investigar seu conteúdo.
Passo 2 vem primeiro porque erros 403 podem ser gerados pelo WAF, pela aplicação backend ou por outras camadas de segurança. Confirmar que o WAF é a fonte do erro é o pré-requisito para qualquer investigação de regra. Sem essa confirmação, todos os passos seguintes podem ser investigação no lugar errado.
Passo 1 vem em seguida para identificar quais ruleIds estão sendo disparados e quais valores de campo correspondem aos hits. Essa informação direciona todo o diagnóstico subsequente.
Passo 4 compara o conteúdo dos usuários afetados com os não afetados. Com o ruleId identificado e o padrão de conteúdo bloqueado em mãos, essa comparação confirma qual característica do input dispara a regra, o que é necessário para configurar uma exclusão precisa.
Passo 3 verifica se existe uma exclusão incompleta ou mal configurada. Esse passo só faz sentido após entender qual regra está disparando e qual conteúdo a aciona.
Passo 5 confirma com o time de desenvolvimento se houve mudança recente no frontend. Esse passo é o último porque depende de contexto externo ao WAF e só é necessário se os passos anteriores não identificarem um padrão claro no conteúdo ou se a exclusão não resolver o problema.
A alternativa C é o distrator mais atraente porque começa com a pergunta ao time de desenvolvimento, o que parece lógico em um ambiente com usuários afetados de forma intermitente. Porém, iniciar por uma consulta externa sem antes confirmar que o WAF é a fonte do erro pode consumir tempo significativo investigando uma mudança de frontend que pode não existir.
Árvore de Troubleshooting: Configure Rule Sets for WAF on Application Gateway
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 e responda a primeira pergunta verificando diretamente nos logs de diagnóstico do Application Gateway se há registros do WAF para a requisição afetada. Isso separa imediatamente os problemas de configuração de regras dos problemas de infraestrutura de rede ou backend. A partir da confirmação da origem do bloqueio, siga as ramificações respondendo apenas com o que é verificável no portal ou nos logs, sem presumir a causa, até alcançar o nó de causa identificada e a ação correta correspondente.