Laboratório de Troubleshooting: Activate and monitor distributed denial-of-service (DDoS) protection
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de segurança de uma empresa reporta que, durante um teste de carga autorizado realizado por uma empresa terceira, o tráfego legítimo de usuários reais começou a ser descartado pelo Azure enquanto o teste ainda estava em andamento. O ambiente utiliza o DDoS Network Protection vinculado à rede virtual principal.
O IP público afetado é o pip-appgw-prod, associado a um Application Gateway. A equipe verificou que o plano do DDoS está ativo e que a assinatura não apresenta alertas de quota. Os logs do Application Gateway mostram conexões sendo rejeitadas a partir do minuto 14 do teste.
Saída do Azure Monitor para o IP pip-appgw-prod durante o incidente:
MetricName : PacketsDroppedDDoS
TimeGrain : PT1M
Average : 18400
Unit : Count
MetricName : IfUnderDDoSAttack
TimeGrain : PT1M
Average : 1
Unit : Count
MetricName : PacketsForwardedDDoS
TimeGrain : PT1M
Average : 210
Unit : Count
A equipe também confirma que o WAF do Application Gateway está em modo de detecção, não de prevenção, e que nenhuma regra customizada foi adicionada ao WAF nessa semana.
Qual é a causa raiz do descarte de tráfego legítimo observado?
A) O WAF do Application Gateway em modo de detecção interferiu na inspeção de pacotes do DDoS, gerando descarte incorreto.
B) O DDoS Network Protection ativou a mitigação porque o perfil de tráfego do teste ultrapassou os limites aprendidos para aquele IP, e nenhuma política de DDoS customizada foi configurada para ajustar esses limites.
C) O plano do DDoS está vinculado à rede virtual, mas o Application Gateway opera em uma sub-rede delegada que não herda a proteção do plano, causando comportamento imprevisível.
D) O teste de carga utilizou IPs de origem repetidos, o que ativou uma regra de rate limiting interna do Azure que opera independentemente do plano DDoS.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o plano do DDoS Network Protection associado à rede virtual vnet-prod-eastus foi excluído acidentalmente por um operador que confundiu o recurso com um plano de teste. A exclusão ocorreu há 40 minutos. A aplicação exposta por IPs públicos nessa VNet está em produção e recebe tráfego real.
O time verifica que:
- Não há outro plano de DDoS disponível na assinatura
- A assinatura possui permissão de Contributor no resource group de rede
- Um alerta de segurança foi aberto no canal do time com criticidade alta
- O time de on-call possui acesso ao portal do Azure e ao Azure CLI
- A janela de manutenção programada começa em 6 horas
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção para recriar o plano com as configurações corretas e evitar mudanças em produção fora do processo aprovado.
B) Criar imediatamente um novo plano do DDoS Network Protection e associá-lo à vnet-prod-eastus, restaurando a cobertura o mais rápido possível.
C) Habilitar o DDoS IP Protection em cada IP público individualmente como medida temporária enquanto o processo formal de recriação do plano é iniciado.
D) Escalar para o time de arquitetura antes de qualquer ação, pois a recriação do plano sem revisão pode aplicar configurações incorretas de política.
Cenário 3 — Causa Raiz
Um analista de segurança configurou um alerta no Azure Monitor para notificar o time quando um ataque DDoS for detectado em qualquer IP público da assinatura. Após duas semanas, nenhum alerta foi disparado, mesmo durante um período em que o fornecedor de testes de resiliência reportou que havia enviado tráfego volumétrico ao ambiente por 20 minutos.
O analista apresenta a configuração do alerta:
Tipo de recurso : Assinatura (subscription-level alert)
Sinal : Under DDoS attack
Condição : Maior que 0
Agregação : Média
Período : 5 minutos
Escopo do alerta : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
A assinatura possui dois IPs públicos protegidos por um plano do DDoS Network Protection ativo. A equipe confirma que os IPs públicos estão corretamente associados à VNet vinculada ao plano. O Log Analytics Workspace da assinatura registrou eventos de mitigação no período do teste.
Qual é a causa raiz da ausência de alertas?
A) A agregação Média diluiu o valor da métrica binária abaixo do limiar de 0, impedindo o disparo do alerta.
B) Alertas baseados na métrica Under DDoS attack exigem que o escopo seja definido no nível do recurso de IP público individual, não no nível da assinatura.
C) O período de avaliação de 5 minutos é insuficiente para métricas de DDoS, que exigem no mínimo 15 minutos para acumular dados de mitigação.
D) O Log Analytics Workspace registrou os eventos, o que indica que o Diagnostic Settings interceptou os dados antes que o Azure Monitor pudesse processá-los para alertas.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O IP público pip-api-backend parou de responder a requisições externas. Não há manutenção programada. O recurso aparece como saudável no portal."
O engenheiro tem acesso ao portal do Azure, ao Azure Monitor e ao Azure CLI. Abaixo estão os passos de investigação disponíveis, apresentados fora de ordem:
- Passo P: Verificar as métricas
PacketsDroppedDDoSeIfUnderDDoSAttackno Azure Monitor para o IPpip-api-backend - Passo Q: Confirmar se o IP público está associado a uma VNet vinculada a um plano do DDoS Network Protection ativo
- Passo R: Verificar se o NSG associado à sub-rede ou NIC do recurso contém regras de negação recentes
- Passo S: Verificar os logs de diagnóstico do plano do DDoS para identificar vetores de ataque registrados
- Passo T: Confirmar se o recurso de destino (backend da API) está operacional verificando sua integridade internamente
Qual sequência de diagnóstico é a mais adequada para este cenário?
A) T, R, Q, P, S
B) Q, P, S, R, T
C) R, T, Q, P, S
D) P, Q, T, S, R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A métrica IfUnderDDoSAttack com valor 1 confirma que o Azure detectou e ativou a mitigação DDoS para o IP pip-appgw-prod. O alto volume de PacketsDroppedDDoS em relação ao baixíssimo PacketsForwardedDDoS indica que a mitigação estava filtrando agressivamente o tráfego de entrada.
A causa raiz é que o DDoS Network Protection aprende o perfil de tráfego de cada IP ao longo do tempo e estabelece limites adaptativos de mitigação. Um teste de carga que gera volume acima do baseline aprendido é indistinguível de um ataque volumétrico real para o sistema, especialmente quando nenhuma política de DDoS customizada foi criada para aquele IP com limites ajustados ao seu perfil de uso intensivo.
A informação sobre o WAF em modo de detecção é propositalmente irrelevante: o WAF em modo de detecção não descarta tráfego, apenas registra. Esse detalhe existe para desviar o diagnóstico para a alternativa A.
A alternativa C representa um equívoco sobre o escopo de proteção: o DDoS Network Protection cobre todos os IPs públicos de recursos implantados em sub-redes da VNet vinculada, independentemente de delegação. A alternativa D descreve um mecanismo que não existe como descrito no Azure DDoS.
O distrator mais perigoso é o C: agir com base nessa crença levaria o engenheiro a tentar "corrigir" a associação da proteção, desperdiçando tempo enquanto a causa real permanece sem tratamento.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e declarada no enunciado: o plano foi excluído e a VNet está sem proteção DDoS ativa há 40 minutos. Cada minuto adicional sem o plano representa exposição real de um ambiente de produção.
A ação correta é criar imediatamente um novo plano do DDoS Network Protection e vinculá-lo à vnet-prod-eastus. A permissão de Contributor no resource group de rede é suficiente para criar e associar o plano. Não há restrição técnica nem de permissão que impeça essa ação.
A alternativa A é o distrator mais perigoso: aguardar 6 horas uma janela de manutenção quando o ambiente de produção está desprotegido é uma decisão que inverte a prioridade entre processo e risco operacional real. Janelas de manutenção são para mudanças planejadas, não para restaurar controles de segurança removidos acidentalmente.
A alternativa C seria aceitável como complemento, mas o DDoS IP Protection exige configuração por IP individual, tem menor cobertura de recursos e não é a abordagem mais eficiente quando o objetivo é restaurar o estado anterior.
A alternativa D introduz uma dependência desnecessária: a recriação de um plano DDoS é uma operação bem definida que não exige aprovação arquitetural de emergência, especialmente quando o estado desejado já é conhecido.
Gabarito — Cenário 3
Resposta: B
A métrica Under DDoS attack é emitida no nível do recurso de IP público individual, não no nível da assinatura. O Azure Monitor não agrega automaticamente métricas de recursos individuais quando o escopo do alerta é definido na assinatura sem uso de métricas de nível de assinatura. O resultado é que o alerta nunca encontra dados para avaliar e permanece silencioso.
A pista no enunciado é a combinação de dois fatos: o Log Analytics registrou eventos de mitigação (confirmando que o ataque foi detectado e a proteção funcionou) e nenhum alerta disparou. Isso elimina qualquer hipótese de falha na proteção e direciona o diagnóstico para a configuração do alerta em si.
A alternativa A é um distrator técnico sofisticado: embora a agregação Média em métricas binárias possa de fato diluir valores em janelas longas, isso não é a causa raiz aqui. Com 20 minutos de ataque e janela de 5 minutos, a média ainda seria 1 durante o evento. O problema é anterior: o escopo impede que os dados cheguem ao alerta.
A alternativa C é falsa: não existe restrição de período mínimo de 15 minutos para métricas DDoS. A alternativa D descreve um comportamento que não existe: o Diagnostic Settings e o Azure Monitor operam de forma independente e não competem pelos dados.
Gabarito — Cenário 4
Resposta: A
A sequência correta é T, R, Q, P, S, que segue a lógica de diagnóstico progressivo do mais simples para o mais específico:
T confirma se o problema está no recurso em si ou na camada de rede, evitando investigar proteção DDoS quando a causa pode ser uma falha interna da aplicação.
R verifica regras de NSG, que são a causa mais comum e imediata de tráfego bloqueado em ambientes Azure. São verificáveis em segundos e não exigem análise de métricas.
Q confirma se o IP está coberto pelo plano DDoS antes de interpretar qualquer métrica relacionada. Sem essa confirmação, as métricas de DDoS podem estar ausentes ou sem significado.
P analisa as métricas DDoS com contexto já estabelecido pelos passos anteriores, permitindo interpretar corretamente se há mitigação ativa.
S é o passo mais custoso em tempo e é útil apenas se os passos anteriores confirmarem que o DDoS está mitigando tráfego; nesse ponto, os logs de diagnóstico revelam os vetores e ajudam a decidir a resposta.
A alternativa B inicia pela verificação do plano antes de saber se o recurso está operacional, o que pode levar o engenheiro a investigar proteção DDoS quando a causa real é uma falha interna. A alternativa D começa diretamente pelas métricas sem contexto, o que é ineficiente e pode gerar conclusões precipitadas.
Árvore de Troubleshooting: Activate and monitor distributed denial-of-service (DDoS) protection
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta com base no que você pode verificar diretamente no ambiente. Siga o caminho que corresponde ao estado observado, sim ou não, até alcançar um nó de causa identificada. A partir da causa, a ação recomendada associada indica o próximo passo operacional. Nós de validação intermediária indicam momentos onde é necessário coletar dados antes de continuar o diagnóstico.