Aplicação (camada 7) Proteção DDoS

Aplica-se a: ✔️ Application Gateway V2 ✔️ Front Door Premium

Firewall de Aplicativo Web do Azure (WAF) inclui vários mecanismos de defesa que ajudam a prevenir ataques de negação de serviço distribuída (DDoS). Os ataques de DDoS podem atingir a camada de rede (L3/L4) e a camada de aplicativo (L7). A Proteção contra DDoS do Azure protege você contra grandes ataques volumétricos na camada de rede. Azure WAF, operando na camada 7, protege aplicativos Web contra ataques de DDoS L7, como inundações HTTP. Juntas, essas defesas impedem que atacantes acessem sua aplicação e afetem sua disponibilidade e desempenho.

Ataques na camada de aplicação são baratos de lançar e difíceis de distinguir do tráfego legítimo: cada requisição parece válida por si só, e só a taxa agregada, distribuição e combinação de clientes revelam o ataque. A defesa efetiva do L7, portanto, depende menos de um único controle e mais de uma configuração em camadas que já está em funcionamento antes do início do ataque.

Escolha suas camadas de defesa

Use o modelo a seguir ao planejar proteção DDoS L7. Cada camada captura tráfego, a camada acima dela não captura.

Checklist de configuração básica

Complete esses passos antes de ser atacado. Ajuste-os para atender aos requisitos da sua inscrição.

1. Deploye Azure WAF com Azure Front Door Premium ou Application Gateway WAF v2 para proteger contra ataques na camada de aplicação L7.
2. Mude a política de WAF para o modo de prevenção. Uma política no modo de detecção registra apenas e não bloqueia o tráfego. Verifique e ajuste a política contra tráfego de produção primeiro para reduzir falsos positivos, depois ative a prevenção.
3. Atribua o conjunto de regras HTTP DDoS (disponível tanto no Azure Front Door Premium quanto no Application Gateway WAF v2) para que a mitigação automatizada seja aprender sua linha de tráfego antes de precisar.
4. Ative o conjunto de regras gerenciado pelo Bot Manager para identificar e agir contra bots conhecidos como mal.
5. Configure pelo menos uma regra de limite de taxa genérica (veja Limitação de taxa).
6. Aumente a quantidade de instâncias de origem para que haja capacidade suficiente e configure o Application Gateway para escalar automaticamente sem impor um número máximo de instâncias baixo.
7. Ative o cache no Azure Front Door para que o tráfego de picos repentinos seja absorvido na borda em vez de na sua origem.
8. Cubra sua exposição L3/L4, que varia conforme a plataforma. Veja A proteção DDoS da plataforma varia de plataforma para plataforma. Bloqueie sua origem para que ela aceite apenas tráfego do Azure Front Door ou do Application Gateway.
9. Ative o logging de diagnóstico no Log Analytics e construa as consultas no Analyze WAF e acesse logsantes de um incidente.

A proteção contra DDoS da plataforma varia de plataforma para plataforma

Defesas L7 só importam se os endereços IP públicos subjacentes sobreviverem a um ataque volumétrico, e as duas plataformas WAF do Azure não começarem do mesmo lugar.

Azure Front Door tem proteção DDoS de plataforma por padrão. Azure Front Door é um serviço de borda distribuído globalmente, e sua borda é protegida pela proteção DDoS da infraestrutura do Azure, sem custo adicional e sem configuração. O tráfego termina na borda da Porta Principal em vez de em um endereço IP que você possui, então não há um IP público seu para um atacante mirar em L3/L4. Essa proteção é inerente à plataforma, então você não compra ou habilita nada para obtê-la.

O Application Gateway precisa de Proteção de Rede DDoS do Azure. Um gateway de aplicação é um recurso regional com um endereço IP público na sua própria rede virtual. A proteção padrão em nível de infraestrutura do Azure protege a própria plataforma Azure, mas não oferece mitigação ajustada por recurso, telemetria ou relatórios de ataque para aquele IP. Para proteger o IP público do gateway contra ataques volumétricos L3/L4, ative a Proteção de Rede DDoS do Azure na rede virtual que a contém. Este é um serviço pago, comprado separadamente.

Consequências práticas ao escolher ou projetar uma implantação:

• Se você está atrás do Azure Front Door, orçamente para os controles L7; a proteção de borda L3/L4 já está lá.
• Se você está usando o Application Gateway e não ativou a Proteção de Rede DDoS, suas regras WAF podem ser perfeitamente ajustadas e ainda assim serem contornadas por um ataque volumétrico ao IP público do gateway. Habilite-a.
• Em qualquer caso, os IPs públicos de origem que você expõe ainda precisam de Proteção de Rede DDoS do Azure, além de bloqueio para que apenas o serviço WAF possa alcançá-los. Uma frente protegida em frente a uma origem não protegida e acessível publicamente não é protegida.

Para mais informações, veja a visão geral da Proteção DDoS do Azure e Proteja seu gateway de aplicação com a Proteção de Rede DDoS do Azure.

Proteção automatizada com o conjunto de regras HTTP DDoS (prévia)

Controles estáticos como filtros IP, geofiltros e limites fixos de taxa muitas vezes não acompanham botnets distribuídos: os limites são suposições, estão sempre ativados, e você precisa retinusá-los conforme os padrões de tráfego evoluem. O conjunto de regras HTTP DDoS é o primeiro modelo automatizado de proteção de camada 7 do Azure WAF que aprende, detecta e defende com configuração mínima do usuário. Está disponível em prévia tanto no Azure Front Door Premium quanto no Application Gateway WAF v2. Uma vez atribuído, ele faz uma base contínua no tráfego normal e, quando surtos indicam um ataque, bloqueia seletivamente clientes infratores sem necessidade de ajuste de emergência.

O design é o mesmo em ambas as plataformas nas maneiras que mais importam:

• Dois limiares, avaliados juntos. O conjunto de regras aprende tanto um limiar global (por perfil Front Door ou por gateway de aplicação) quanto limiares individuais baseados em IP. Os limites baseados em IP são aplicados apenas após a ultrapassagem do limite global. Esse design impede que o conjunto de regras atue sobre picos de poucos endereços IP, a menos que eles realmente ultrapassem o padrão de tráfego total.
• Escopado por recurso. Os limiares são aprendidos no nível global dos recursos. Se você atribuir uma política WAF com o conjunto de regras a múltiplos perfis de Porta Frontal ou múltiplos gateways, o serviço calcula limiares separadamente para cada um.
• Sensibilidade. Cada regra oferece três níveis de sensibilidade. Sensibilidade maior aplica um limiar mais baixo; Sensibilidade menor aplica um limiar mais alto. Médio é a configuração padrão e recomendada.
• Ordem de avaliação. O WAF avalia primeiro o conjunto de regras HTTP DDoS, mesmo antes das regras personalizadas. Uma regra personalizada com uma ação Permitir ignora todas as outras inspeções WAF, mas não contorna o conjunto de regras HTTP DDoS.
• Ignorando o conjunto de regras para tráfego confiável. Uma regra personalizada com uma ação Permitir não ajuda aqui – ela contorna todos os outros conjuntos de regras, mas não o conjunto de regras HTTP DDoS. Use exceções WAF , que você pode direcionar para uma regra específica, grupo de regras ou um conjunto de regras gerenciado, incluindo o conjunto de regras HTTP DDoS. Veja Isentar tráfego confiável com exceções.
• Requer tráfego contínuo. O conjunto de regras só pode agir quando aprender linhas de base confiáveis. Se um recurso não receber tráfego suficiente durante a fase de aprendizado, o conjunto de regras não detectará nem protegerá até que receba. Veja a tabela de plataforma para o requisito específico.

Diferenças de plataforma

Regras do conjunto de regras

O conjunto de regras atualmente contém duas regras. Cada regra mantém suas próprias linhas de tráfego e é configurável com sua própria sensibilidade e ação:

A área de penalidade

Ambas as plataformas mitigam por meio de uma caixa de penalidade. Quando o tráfego de um cliente ultrapassa o limite de uma das regras do conjunto de regras, esse endereço IP do cliente é colocado na caixa de penalidade e bloqueado pelo WAF durante a duração da caixa de penalidade, que é de 15 minutos no Application Gateway. Quando o período termina, o endereço IP recupera o acesso, a menos que ultrapasse novamente o limite, o que o retorna para a caixa de penalidade.

Esse design é importante para a forma como você lê sua telemetria: apenas o acerto inicial da regra é registrado. Solicitações bloqueadas adicionais enquanto o endereço IP já está na caixa de penalidade não são registradas no Front Door, então as contagens baseadas em logs subestimam o número de requisições bloqueadas. No Application Gateway, use a métrica de blocos da caixa de penalidade para a contagem real de blocos e o tamanho da caixa de penalidade para quantos endereços IP estão sendo penalizados atualmente.

Monitoramento durante a prévia

Quando um endereço IP ultrapassa um limite, uma entrada de log é registrada com uma ação Block para o conjunto de regras HTTP DDoS e os incrementos da métrica WAF Managed Rule Match .

• Porta Frontal: use a métrica de contagem de requisições Firewall de Aplicativo Web filtrada por nome de regra para contar blocos, e a métrica Web Application Firewall HTTPDDoSRuleset Is Active, que reporta 1 assim que o aprendizado é concluído e o conjunto de regras está pronto para agir sobre tráfego que ultrapassa os limites aprendidos.
• Gateway de Aplicação: cada requisição bloqueada subsequente de um endereço IP penalizado incrementa a métrica de Correspondência de Regras Gerenciadas, e as métricas de tamanho da caixa de penalidade e dos blocos da caixa de penalidade rastreiam diretamente a caixa de penalidade.

Isentar tráfego confiável com exceções

Sondas de saúde, monitoramento sintético, testes de carga, integrações com parceiros e trabalhos internos em lote geram tráfego que parece uma enxurrada, mas não é. Historicamente, não há como isentá-los do conjunto de regras DDoS, porque uma regra personalizada de Permitir contorna o conjunto padrão de regras, o conjunto de regras core e a proteção contra bots, mas deliberadamente não contorna o conjunto de regras HTTP DDoS.

Exceções do WAF fecham essa lacuna. Uma exceção contorna a inspeção WAF para solicitações que correspondem a atributos específicos, com escopo para uma única regra, um grupo de regras ou um conjunto de regras gerenciado inteiro. Você pode aplicar exceções ao conjunto de regras HTTP DDoS, assim como ao DRS, CRS e Proteção contra Bots.

Exceções correspondem em:

• Endereço IP remoto (Equals ou IP Match), que é a escolha usual para isentar monitoramento conhecido, testes de carga ou intervalos de origem parceira do conjunto de regras DDoS
• URI de solicitação
• Nome e valor do cabeçalho do pedido, combinado com Igual, Começa com, Termina com ou Contém

Orientações para usar exceções com o conjunto de regras DDoS:

• Limite o escopo o mais restrito possível. Prefira uma exceção por regra a isentar todo o conjunto de regras. Uma exceção ampla dá ao atacante um caminho documentado ao redor da sua mitigação automatizada. Se um gerador de carga só precisa de alívio da regra 500100, não o isenta também da 500110.
• Fontes isentas, não caminhos. Uma exceção baseada em IP para um chicote de teste conhecido é limitada. Uma exceção baseada em URI em um endpoint público é uma porta aberta para quem a encontrar.
• Revise eles em um cronograma. Exceções adicionadas para um teste de carga única podem ainda estar em vigor um ano depois.
• Cuidado com os limites. Cada política WAF suporta até 60 exceções, e cada Porta Principal suporta 60 no total em todas as políticas associadas. Uma única exceção pode conter até 600 endereços IP, 10 URIs ou 10 cabeçalhos de requisição.
• Exceções exigem o motor WAF de próxima geração e o conjunto de regras gerenciadas versão DRS 2.1 ou posterior.

Use a ferramenta certa para o trabalho: exclusão pula a inspeção de um elemento de uma solicitação (um cookie ou cabeçalho barulhento) enquanto ainda inspeciona o restante; exceções pulam regras ou conjuntos de regras específicas para solicitações correspondentes; uma regra Permitir personalizada contorna tudo, exceto o conjunto de regras HTTP DDoS.

Desafie antes de bloquear

O bloqueio é um instrumento contundente durante um ataque L7: o tráfego de ataque frequentemente chega de endereços IP e geografias que também transportam usuários reais. Desafios permitem separar automação de humanos sem o dano colateral de um bloqueio total, e são a maior mudança em como o Azure WAF lida com inundações L7 em comparação com uma estratégia de limite de taxa só por blocos.

• O desafio do JavaScript é um desafio invisível que não requer interação humana. Se o navegador calcular o desafio com sucesso, o WAF valida o cliente como não-bot e continua avaliando as regras restantes; Solicitações que falham são bloqueadas. Use isso como o desafio padrão para tráfego web em geral. As requisições para o endpoint de desafio não são encaminhadas para o backend e não contam para limitação de taxa.
• CAPTCHA é um desafio interativo que requer participação do usuário, melhor reservado para fluxos de alto valor como login, cadastro e checkout, onde o abuso automatizado é caro e alguns segundos de atrito do usuário são permitidos. A validade do cookie de desafio pode ser configurada nas configurações de política entre 5 e 1.440 minutos, com padrão de 30 minutos. O CAPTCHA acarreta cobranças adicionais baseadas no uso.

Planeje em torno das limitações de ambos os recursos antes de implantá-los:

• Chamadas AJAX e API não são suportadas. Não coloque desafios na frente das rotas da API. Use limites de taxa e regras de match por lá.
• Desafios são projetados para recursos HTML, não para imagens embarcadas, CSS ou arquivos JavaScript.
• Na primeira solicitação que aciona um desafio, o corpo do POST é limitado a 64 KB no Azure Front Door e 128 KB no Application Gateway.
• Nenhum dos recursos suporta Internet Explorer; ambos suportam versões atuais do Microsoft Edge, Chrome, Firefox e Safari.
• O desafio JavaScript é reemitido quando o endereço IP de um cliente muda e para requisições de origem cruzada (CORS).
• No Application Gateway, o desafio do JavaScript está em prévia e não é suportado para regras personalizadas de limite de taxa. O Gateway de Aplicações para Containers WAF não suporta isso.

Limitação de taxa

No mínimo, crie uma regra de limite de taxa que bloqueie uma alta taxa de solicitações de qualquer único cliente. Defina essa regra como sua regra de limite de taxa de menor prioridade (valor numérico mais alto), para que regras de limite de taxa ou correspondência mais específicas sejam avaliadas primeiro.

Azure Front Door

• Os limites de taxa se aplicam por endereço IP de socket, que é o endereço do cliente que abre a conexão TCP para o Azure Front Door e pode ser um proxy, e não o usuário final.
• Os limiares são avaliados em uma janela fixa de um ou cinco minutos. Uma vez que o limiar é ultrapassado, o Azure Front Door bloqueia todo o tráfego que corresponda à regra pelo restante da janela. Use a janela de cinco minutos para mitigação de inundação HTTP: um atacante bloqueado no primeiro minuto permanece bloqueado nos quatro minutos restantes.
• Janelas maiores com o menor limiar aceitável são a configuração anti-DDoS mais eficaz. Janelas maiores e valores de limiar maiores também fazem com que o limiar seja mais próximo do configurado. Em limites muito baixos (abaixo de cerca de 200 solicitações por minuto), algumas solicitações acima desse limite podem ser aprovadas, porque solicitações de um cliente podem chegar a servidores Front Door cujos contadores ainda não foram atualizados.
• Regras de limite de taxa suportam apenas ações de Log e Bloco ; Permitir não é suportado.
• Aplique uma regra a todo tráfego fazendo correspondência em um Host cabeçalho com comprimento maior que 0, pois toda solicitação válida para o Azure Front Door tem uma.

Gateway de Aplicativo WAF v2

• Limitação de taxa utiliza um algoritmo de janela deslizante . Todo tráfego correspondente é descartado durante a primeira janela em que o limite é ultrapassado. A partir da segunda janela, o tráfego até o limite é permitido, produzindo um efeito de limitação em vez de uma queda total para clientes correspondentes.

• As regras exigem um GroupByUserSession, que controla como as requisições são contadas. Esse recurso permite limitar a taxa por algo diferente do IP do cliente:

  GrupoporVariável	Use-o quando
  ClientAddr (predefinição)	Caso normal com contadores independentes por IP de origem
  ClientAddrXFFHeader	Seu gateway fica atrás de uma CDN ou proxy e o IP real do cliente está em X-Forwarded-For
  GeoLocation	Você quer limitar o tráfego por país/região durante uma enchente geograficamente concentrada
  GeoLocationXFFHeader	Igual ao anterior, usando o endereço IP em X-Forwarded-For
  None	Um único contador compartilhado para um padrão restrito, como uma página de login ou uma lista de agentes de usuário suspeitos

• Regras de limite de taxa exigem o motor WAF mais recente (selecione CRS 3.2 ou posterior para o conjunto padrão de regras) e não são suportadas em nuvens isoladas.

• O Application Gateway conta os limiares independentemente para cada endpoint ao qual a política está conectada. Uma única política para cinco ouvintes mantém cinco conjuntos de contadores.

• Limites não são aplicados exatamente, então não use limitação de taxa para controle de tráfego detalhado. Use para mitigar taxas anômalas e manter a disponibilidade. Use cautela especial com regras de correspondência ampla que usem GeoLocation ou None; um limite mal escolhido pode causar interrupções frequentes e curtas para tráfego legítimo.

Defina limites conscientes da geografia

Um único limite global precisa ser generoso o suficiente para o país mais movimentado, o que o torna generoso demais em todos os outros lugares. A maioria das aplicações tem um perfil geográfico fortemente distorcido em tempos de paz – alguns poucos países ou regiões produzem quase todo o tráfego legítimo, e o restante produz um pouco de fluxo. O tráfego de ataque raramente respeita essa distribuição. Limiares de dimensionamento por geografia transforma essa assimetria tanto em um sinal de detecção quanto em um controle de mitigação.

Comece medindo sua distribuição em tempo de paz ao longo de pelo menos uma semana inteira, para que os efeitos de dias úteis, finais de semana e fusos horários sejam representados:

• No Azure Front Door, divida a métrica de contagem de requisições pela dimensão ClientCountry.

• No Log Analytics, derive o país a partir do endereço IP do cliente no log de acesso:

  AzureDiagnostics
  | where Category == "FrontdoorAccessLog"
  | where TimeGenerated > ago(7d)
  | extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
  | summarize Requests = count(), Clients = dcount(clientIp_s) by Country
  | extend ShareOfTraffic = round(100.0 * Requests / toscalar(
        AzureDiagnostics
        | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
        | count), 2)
  | order by Requests desc
  

Em seguida, agrupe os resultados em níveis e defina um limite para cada um:

Como você implementa os níveis depende da plataforma:

• WAF do Gateway de Aplicação v2 - use GroupByVariable: GeoLocation (ou GeoLocationXFFHeader atrás de uma CDN ou proxy) para que todo o tráfego de uma geografia compartilhe um contador, e crie uma regra de limite de taxa por nível com seu próprio limiar. Como uma violação atua contra todos os clientes nessa região, dimensione esses limites de forma conservadora e valide-os primeiro em ação de log: uma regra geológica de ampla correspondência incorretamente configurada pode causar interrupções frequentes e curtas para tráfego legítimo.
• Azure Front Door - os contadores são por endereço IP por socket, então construa os níveis com condições de geo-match: uma regra de limite de taxa por nível, combinada nos países relevantes, cada um com seu próprio limiar. Todo cliente em uma geografia de cauda longa então obtém um teto muito mais baixo do que os clientes em seus mercados principais, sem que o comportamento de um cliente afete os outros.

Algumas práticas que mantêm isso sustentável:

• Ordene as regras de mais específicas para menores: regras de mercado primário com prioridade maior (valor numérico menor), depois secundária, depois long-tail, com a regra global de acúmulo como sua limite de menor prioridade.
• Prefiro uma ação de desafio a um bloco para geografias de cauda longa. O tráfego de um país com pouco volume legítimo é suspeito no geral, mas ainda contém usuários reais – viajantes, usuários de VPN e funcionários remotos.
• Reavalie após lançamentos de marketing, expansões regionais e grandes eventos de produtos. Uma configuração consciente da geografia só é tão boa quanto a linha de base a partir da qual foi dimensionada.
• Fique atento ao sinal inverso durante um incidente: um país que normalmente contribui com 1% de tráfego contribuindo de repente com 40% é uma das formas mais rápidas de confirmar que você está vendo um ataque e não um crescimento orgânico.

Escolha um limiar do seu próprio tráfego

Use a seguinte consulta do Log Analytics para dimensionar a regra geral. Para Application Gateway, substitua FrontdoorAccessLog por ApplicationGatewayAccessLog.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

Para dimensionar os limites por geografia descritos anteriormente, adicione o país à mesma consulta:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

Defina o limite acima do percentil 99 do tráfego em tempo de paz, não no máximo. O máximo geralmente é um crawler ou um cliente mal configurado, e o tamanho dele deixa a regra muito generosa para ajudar durante um ataque.

Regras personalizadas para mitigação direcionada

Crie regras WAF personalizadas para bloquear ou limitar a taxa de ataques HTTP e HTTPS que tenham assinaturas identificáveis, como um agente de usuário específico, cabeçalho, cookie, padrão de string de consulta, URI ou uma combinação deles. Além do matching de strings, as regras personalizadas WAF do Azure Front Door podem combinar em:

• Geolocalização: Bloqueie o tráfego de fora da sua região de serviço ou redirecione-o para uma página estática.
• Endereço IP do cliente (CIDR) e listas de restrição de IP para endereços e intervalos que você identificou como maliciosos.
• Número AS (ASN): Mitigar inundações provenientes de um provedor de hospedagem ou rede de trânsito de onde seus usuários legítimos não vêm, sem enumerar faixas de IP.
• Impressão digital do cliente (JA4): Correspondência na impressão digital JA4, um hash derivado das características de handshake TLS e HTTP do cliente. Como as ferramentas de ataque e os clientes de botnet produzem uma impressão digital consistente independentemente do endereço IP de onde enviam, o JA4 é uma das assinaturas mais duráveis disponíveis durante um ataque distribuído: rodar entre milhares de endereços IP de origem não altera a impressão digital, e bloquear ou limitar a taxa nela elimina toda a botnet com uma regra. Verifique a impressão digital com seus registros de tempo de paz antes de aplicar a fiscalização. Navegadores populares e SDKs comuns compartilham impressões digitais em um número enorme de usuários legítimos, então um bloco JA4 não validado pode ser extremamente amplo. Implante primeiro a ação de Log , confirme que a impressão digital aparece apenas no tráfego de ataque, depois mude para Bloquear ou uma regra de limite de taxa.
• Combine o JA4 com outras condições para mitigação cirúrgica durante um incidente. Por exemplo, limite a taxa em vez de bloquear uma impressão digital específica do JA4 e um ASN que você não atende aos usuários, ou uma impressão digital do JA4 e um URI de solicitação.
• Restrições de etiquetas de serviço e tamanho nos componentes de requisição.

Duas práticas que importam durante um incidente:

• Crie regras de Permitir correspondência para tráfego legítimo conhecido para reduzir falsos positivos e dê a eles uma prioridade maior (valor numérico menor) do que suas regras de limite de bloco e taxa. Lembre-se de que uma regra de Permitir contorna outras inspeções de WAF, mas não contorna o conjunto de regras HTTP DDoS.
• A avaliação de regras para em qualquer ação, exceto Log, e os números de prioridade devem ser únicos. Reserve um bloco de números de baixa prioridade para regras de emergência, assim você pode inserir um durante um ataque sem renumerar.

Regras gerenciadas não são direcionadas para defesa contra DDoS, mas protegem contra outros ataques comuns e devem permanecer ativadas. Veja Regras Gerenciadas (Azure Front Door) ou Regras Gerenciadas (Application Gateway).

Proteja a origem

• Bloqueie o acesso aos IPs públicos na origem e restrinja o tráfego de entrada para que apenas o Azure Front Door ou o Application Gateway possam acessá-lo. Siga as orientações para garantir o tráfego para as origens do Azure Front Door.
• Certifique-se de que não haja endereços IP publicamente expostos na rede virtual do Gateway de Aplicação.
• Ative o cache no Azure Front Door. Respostas em cache absorvem o volume máximo na borda e reduzem a taxa de solicitação que chega à sua origem, o que geralmente é a diferença entre desempenho degradado e uma queda de energia.
• Origem da escala com headroom. Mitigações automatizadas e manuais levam tempo para serem ativadas; A capacidade sobrando cobre essa lacuna.

Responder a um ataque ativo

1. Confirme que é um ataque, não crescimento orgânico. Verifique os WAF e os logs de acesso para uma mudança repentina na taxa de requisição, contagem de IPs do cliente, mistura geográfica, distribuição de agentes de usuário e URIs solicitados.
2. Verifique o que já está atenuando. Confirme que o conjunto de regras HTTP DDoS está ativo e revise seus blocos pelo nome da regra. No Application Gateway, verifique também o tamanho da caixa de penalidade e as métricas de blocos da caixa de penalidade , já que apenas o primeiro bloco por endereço IP aparece nos logs. Revise as regras do limite de taxa.
3. Compare a composição geográfica com sua linha de base. Um país que normalmente contribui com uma pequena parcela do tráfego dominando de repente é um sinal de ataque rápido e de alta confiança. Também te diz qual nível de regras de limite de taxa deve apertar primeiro.
4. Aumente a sensibilidade antes de escrever novas regras. Aumentar a sensibilidade do conjunto de regras HTTP DDoS ou reduzir um limite de taxa existente é mais rápido e seguro do que criar uma nova regra sob pressão.
5. Desafie em vez de bloquear onde o tráfego está misturado. Aplique o desafio JavaScript às rotas HTML afetadas e o CAPTCHA a fluxos sensíveis.
6. Escreva uma regra direcionada apenas depois de identificar uma assinatura duradoura: ASN, impressão digital do cliente, combinação de cabeçalhos, geografia ou padrão de URI. Implemente primeiro no Log Action se o padrão também corresponder a usuários reais.
7. Mantenha o Origin protegido enquanto você ajusta: verifique se o cache está ativado, confirme o bloqueio de origem e escale o volume.
8. Após o incidente, reajuste seus limites de taxa em relação aos novos dados de tráfego e mantenha as regras de emergência que se mostraram precisas no modo Log, caso não queira que elas sejam aplicadas continuamente.

Analisar WAF e logs de acesso

Monitore o tráfego usando logs WAF do Azure para detectar anomalias e use-os para identificar endereços IP suspeitos que enviam números incomumente altos de solicitações, strings incomuns de agentes de usuário ou padrões anômalos de sequência de consulta.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Gateway de Aplicativo do Azure

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Principais faladores e principais agentes de usuário na janela de ataque (Azure Front Door mostrado; substituto ApplicationGatewayAccessLog para Application Gateway):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

Para mais informações, veja Azure WAF com Azure Front Door e Azure WAF com Gateway de Aplicativo do Azure.

Conteúdo relacionado

• Conjunto de regras HTTP DDoS: Azure Front Door WAF | Application Gateway WAF
• Lista de excepções WAF: Azure Front Door WAF | Application Gateway WAF
• Limitação de taxa: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front DoorApplication | Gateway
• Azure desafio do WAF JavaScript
• AZURE FRONT DOOR WAF CAPTCHA
• Proteção contra DDoS no Azure Front Door
• Arquiteturas de referência do Azure DDoS Protection
• Visão geral da Proteção contra DDoS do Azure