Laboratório de Troubleshooting: Configure Detection or Prevention Mode
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa implantou um Application Gateway com WAF v2 na frente de uma aplicação web de e-commerce. O WAF foi configurado há duas semanas pelo time de segurança. O time de desenvolvimento reporta que clientes legítimos estão recebendo respostas HTTP 403 ao tentar acessar páginas de checkout que contêm parâmetros de formulário com campos como order_id e product_description.
O administrador consulta os logs do WAF e encontra as seguintes entradas:
{
"ruleId": "942100",
"ruleGroup": "SQLI",
"message": "SQL Injection Attack Detected via libinjection",
"action": "Blocked",
"matchedData": "product_description=SELECT",
"requestUri": "/checkout/submit",
"policyMode": "Prevention"
}
Informações adicionais coletadas:
- O ruleset configurado é o OWASP CRS 3.2
- O Application Gateway foi provisionado há 45 dias
- O time de infraestrutura atualizou o certificado TLS do Application Gateway na semana passada
- Os clientes afetados estão em diferentes regiões geográficas
- O campo
product_descriptionaceita texto livre onde usuários podem digitar nomes de produtos
Qual é a causa raiz do problema observado?
A. O certificado TLS foi renovado recentemente e o WAF está em estado de re-inicialização, causando bloqueios incorretos de requisições legítimas.
B. O WAF está em modo Prevention e uma regra OWASP está gerando um falso positivo ao interpretar o conteúdo legítimo do campo product_description como injeção SQL.
C. O ruleset OWASP CRS 3.2 é incompatível com aplicações de e-commerce e deve ser substituído pelo CRS 3.1 para evitar bloqueios em campos de formulário.
D. Os clientes estão em diferentes regiões geográficas e o WAF está aplicando geo-bloqueio automático baseado em localização para regiões não autorizadas.
Cenário 2 — Impacto Colateral
O time de segurança de uma empresa decide migrar o WAF do Application Gateway do modo Detection para o modo Prevention em ambiente de produção. A migração é executada imediatamente após a decisão, sem nenhuma etapa preparatória adicional. O resultado imediato é que o WAF passa a bloquear ativamente as requisições que antes apenas registrava.
Qual consequência secundária essa ação pode causar?
A. O Application Gateway passa a consumir significativamente mais CPU após a mudança para Prevention, podendo causar degradação de desempenho para todas as requisições, independentemente de serem bloqueadas ou não.
B. Falsos positivos que existiam silenciosamente no modo Detection, e que nunca foram revisados e ajustados, passam a bloquear requisições legítimas de usuários reais em produção.
C. As regras OWASP do WAF são automaticamente desativadas durante a transição entre modos, criando uma janela de exposição sem proteção enquanto o novo modo é sincronizado.
D. O modo Prevention desativa automaticamente os logs de diagnóstico do WAF, impedindo que a equipe de segurança visualize os bloqueios que estão ocorrendo após a migração.
Cenário 3 — Causa Raiz
Uma equipe de segurança configurou um WAF em modo Detection no Application Gateway para monitorar o tráfego de uma API REST interna antes de ativar o bloqueio. Após uma semana de operação, o time revisa os logs esperando encontrar alertas de ameaças reais. O administrador executa a seguinte consulta no Log Analytics:
AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated > ago(7d)
| project TimeGenerated, hostname_s, requestUri_s, action_s, ruleId_s, Message
| order by TimeGenerated desc
O resultado retornado é:
No results found for the specified time range.
O administrador confirma que o Application Gateway está recebendo tráfego real, pois os logs de acesso mostram centenas de requisições por hora. O WAF Policy está no estado Enabled e associado ao Application Gateway. O workspace do Log Analytics foi criado há dois meses.
Informações adicionais:
- O Application Gateway está no SKU Standard_v2
- A região do recurso é Brazil South
- O time de redes atualizou as regras de NSG do Application Gateway subnet há três dias
Qual é a causa raiz do problema observado?
A. O SKU Standard_v2 do Application Gateway não suporta WAF e os logs de firewall nunca serão gerados independentemente da configuração.
B. As configurações de diagnóstico do Application Gateway não incluem a categoria ApplicationGatewayFirewallLog como destino para o Log Analytics Workspace, portanto os logs de WAF nunca estão sendo enviados.
C. As regras de NSG da subnet do Application Gateway foram atualizadas recentemente e estão bloqueando a comunicação entre o Application Gateway e o Log Analytics Workspace.
D. O Log Analytics Workspace foi criado há dois meses e atingiu o limite de retenção padrão, descartando automaticamente os logs dos últimos 7 dias.
Cenário 4 — Decisão de Ação
O time de segurança identificou que o WAF em modo Detection está gerando um volume muito alto de falsos positivos em uma aplicação web de gestão financeira. Após revisar os logs, o analista identifica que a regra 942440 do grupo SQLI está disparando em campos legítimos que contêm expressões matemáticas como valor_total = base + juros. A aplicação é crítica e processa transações em tempo real durante 24 horas por dia.
A causa está identificada: a regra 942440 gera falsos positivos para o padrão de dados legítimos da aplicação. O contexto adicional é:
- O WAF ainda está em modo Detection e nunca foi colocado em Prevention
- O time de negócios tem urgência para ativar o modo Prevention por exigência de conformidade
- A aplicação não tem ambiente de staging equivalente para testes de WAF
- O time de segurança tem acesso completo à WAF Policy no portal do Azure
Qual é a ação correta a tomar neste momento?
A. Ativar imediatamente o modo Prevention na WAF Policy, pois o time já identificou o falso positivo e pode corrigir a regra após a ativação se necessário.
B. Criar uma exclusão de regra na WAF Policy para a regra 942440 aplicada ao campo específico que gera o falso positivo, validar nos logs em modo Detection que o falso positivo foi eliminado, e só então migrar para o modo Prevention.
C. Desativar o grupo de regras SQLI completo na WAF Policy para eliminar todos os falsos positivos relacionados a SQL antes de ativar o modo Prevention.
D. Substituir o ruleset OWASP CRS atual por uma versão anterior que não contenha a regra 942440, garantindo que a aplicação não seja afetada antes de ativar o Prevention.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O log é conclusivo: a ação registrada é Blocked, o modo é Prevention, a regra disparada é 942100 do grupo SQLI, e o dado correspondido é product_description=SELECT. O WAF interpretou o conteúdo textual legítimo do campo de descrição de produto como uma tentativa de injeção SQL porque o texto digitado pelo usuário contém a palavra SELECT, comum em nomes de produtos ou descrições em português e inglês. Isso é um falso positivo clássico: o WAF está funcionando corretamente conforme sua configuração, mas a regra está sendo aplicada a um campo que aceita texto livre com conteúdo não controlado.
A pista confirmatória está em dois detalhes do log: matchedData: product_description=SELECT e no fato de que os clientes afetados são legítimos acessando a página de checkout.
Informação irrelevante: A atualização do certificado TLS não tem relação alguma com o comportamento de inspeção de payloads do WAF. O certificado é relevante para a camada de transporte, não para a análise de conteúdo da camada 7.
O erro de raciocínio central nos distratores é desviar o diagnóstico para componentes que foram alterados recentemente (certificado TLS) ou para afirmações falsas sobre incompatibilidade de versões do CRS. O distrator mais perigoso é o A, pois leva o administrador a investigar e potencialmente alterar configurações de TLS que estão completamente fora do escopo do problema.
Gabarito — Cenário 2
Resposta: B
Quando o WAF opera em modo Detection, ele registra todas as requisições que disparariam regras, mas não as bloqueia. Esse é precisamente o propósito do modo Detection: permitir que a equipe revise e ajuste as regras antes de ativar o bloqueio. Se os logs acumulados durante o período em Detection nunca foram revisados e os falsos positivos nunca foram tratados com exclusões ou ajustes, todos eles se tornarão bloqueios reais no momento em que o modo Prevention for ativado. Usuários legítimos que antes eram apenas "monitorados" passam a receber respostas 403 sem aviso.
A alternativa A é falsa: a diferença de consumo de CPU entre os modos não é significativa a ponto de causar degradação, pois a inspeção ocorre em ambos os modos. A alternativa C é falsa: não há janela sem proteção durante a transição; o WAF continua inspecionando em ambos os modos. A alternativa D é falsa: a mudança de modo não desativa os logs de diagnóstico, que continuam funcionando normalmente em Prevention.
O impacto da alternativa B é o mais silencioso e o mais comum na prática: equipes que ativam Prevention sem revisar os logs de Detection frequentemente causam incidentes de disponibilidade autoprovocados.
Gabarito — Cenário 3
Resposta: B
O Application Gateway envia logs de diagnóstico para o Log Analytics apenas quando uma configuração de diagnóstico está explicitamente criada e inclui cada categoria de log desejada como destino. O fato de o WAF Policy estar habilitado e associado ao gateway não significa que os logs de firewall estão sendo encaminhados. A categoria ApplicationGatewayFirewallLog é separada das categorias de acesso e performance, e precisa ser selecionada individualmente na configuração de diagnóstico. Sem essa configuração, os logs de WAF são descartados silenciosamente.
A pista confirmatória está no contraste entre a ausência de resultados na query de firewall e a presença de logs de acesso confirmando tráfego real. Se o gateway recebe tráfego e gera logs de acesso, a ausência de logs de WAF aponta para um problema de configuração de diagnóstico, não de funcionamento do WAF.
Informações irrelevantes: A região Brazil South, a atualização de NSG da subnet e a data de criação do workspace não afetam a geração ou o encaminhamento de logs de diagnóstico. Os NSGs da subnet do Application Gateway controlam tráfego de rede, não a telemetria de diagnóstico enviada ao Log Analytics.
O distrator mais perigoso é o C, que leva o administrador a modificar regras de NSG que controlam tráfego de produção, podendo interromper o funcionamento do Application Gateway, quando o problema está inteiramente na configuração de diagnóstico.
Gabarito — Cenário 4
Resposta: B
A ação correta é criar uma exclusão de regra cirúrgica para a regra 942440 aplicada ao campo específico que gera o falso positivo, validar nos logs em modo Detection que o falso positivo foi eliminado, e só então migrar para Prevention. Essa abordagem elimina o risco identificado de forma precisa, mantém todas as outras proteções intactas, e usa o modo Detection como ambiente de validação antes da ativação do bloqueio.
A alternativa A ignora um princípio fundamental: nunca ativar Prevention sem antes tratar os falsos positivos conhecidos, pois o resultado será bloqueio imediato de transações financeiras legítimas em uma aplicação crítica sem staging. A alternativa C é excessiva e perigosa: desativar o grupo SQLI inteiro elimina toda a proteção contra injeção SQL da aplicação para resolver um falso positivo de uma única regra em um único campo. A alternativa D é inviável na prática e introduz risco de regressão de segurança ao usar uma versão anterior do ruleset que pode ter vulnerabilidades não corrigidas.
O erro central nas alternativas A, C e D é a desproporcionalidade da ação em relação ao problema identificado. A exclusão de regra existe exatamente para resolver falsos positivos de forma cirúrgica sem comprometer a postura geral de segurança.
Árvore de Troubleshooting: Configure Detection or Prevention Mode
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. O primeiro passo é sempre confirmar que a WAF Policy está habilitada e associada ao recurso correto, pois sem isso nenhuma inspeção ocorre. Em seguida, verifique se os logs estão chegando ao Log Analytics verificando as configurações de diagnóstico. Com os logs disponíveis, o caminho se divide conforme o sintoma: bloqueios em tráfego legítimo apontam para falsos positivos que exigem exclusões de regra cirúrgicas; ausência de bloqueios em modo Prevention após migração de Detection aponta para falsos positivos não tratados previamente. Cada caminho termina em uma ação precisa e proporcional ao problema identificado.