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 o tráfego que 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. Aplique 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 aprenda a linha de base do seu tráfego antes que você precise dela.
4. Ative o conjunto de regras gerenciado do Bot Manager para identificar e agir contra bots maliciosos conhecidos.
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 os logs de diagnóstico no Log Analytics e crie as consultas em Analisar o WAF e os logs de acessoantes de um incidente.

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

As defesas de L7 só fazem diferença se os endereços IP públicos subjacentes sobreviverem a um ataque volumétrico, e as duas plataformas de WAF do Azure não partem do mesmo ponto.

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. Um front-end protegido à frente de um servidor de origem desprotegido e acessível publicamente não está protegido.

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 estabelece continuamente uma linha de base do tráfego normal e, quando picos indicam um ataque, bloqueia seletivamente os clientes ofensores sem exigir ajustes emergenciais.

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.
• Com escopo por recurso. Os limiares são aprendidos no nível global dos recursos. Se você atribuir uma política de WAF com o conjunto de regras a vários perfis do Front Door ou a vários gateways, o serviço calculará os limites separadamente para cada perfil ou gateway.
• 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. Em vez disso, use exceções do WAF, que você pode limitar a uma regra específica, a um grupo de regras ou a um conjunto de regras gerenciado inteiro, incluindo o conjunto de regras de 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. Consulte a tabela da plataforma para ver 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 base de tráfego e pode ser configurada 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 Gateway de Aplicativo, use a métrica 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 a ação Block para o conjunto de regras de DDoS HTTP, e a métrica do WAF Managed Rule Match é incrementada.

• Front Door: use a métrica Contagem de solicitações do Firewall de Aplicativo Web filtrada por nome da regra para contar bloqueios, e a métrica Firewall do Aplicativo Web HTTPDDoSRuleset Is Active, que informa 1 assim que o aprendizado for concluído e o conjunto de regras estiver pronto para atuar sobre o tráfego que exceder os limites aprendidos.
• Gateway de Aplicativo: cada solicitaçã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 a:

• 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 da solicitação, correspondente a Igual a, 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 em vez de dispensar todo o conjunto de regras. Uma exceção ampla oferece a um invasor uma forma documentada de contornar 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 qualquer pessoa que a encontre.
• Revise-os de acordo com 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.
• As exceções exigem o mecanismo WAF de próxima geração e a versão DRS 2.1 ou mais recente do conjunto de regras gerenciadas.

Use a ferramenta certa para cada tarefa: exclusões ignoram a inspeção de um elemento de uma solicitação (um cookie ou cabeçalho ruidoso), sem deixar de inspecionar o restante; exceções ignoram regras ou conjuntos de regras específicos para solicitações correspondentes; uma regra personalizada de Allow ignora tudo, exceto o conjunto de regras de HTTP DDoS.

Solicite verificação antes de bloquear

O bloqueio é uma medida drástica em um ataque L7: o tráfego malicioso frequentemente vem de endereços IP e regiões geográficas que também incluem usuários reais. Os desafios de verificação permitem distinguir o tráfego automatizado do tráfego humano sem os danos colaterais de um bloqueio direto, e representam a principal mudança na forma como o Azure WAF lida com ataques de inundação na camada 7, em comparação com uma estratégia de limitação de taxa baseada apenas em bloqueio.

• 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 ao seu backend e não contam para o limite 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 diante das rotas da API. Use a limitação de taxa e as regras de correspondência lá em vez disso.
• 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 de JavaScript é reaplicado quando o endereço IP de um cliente muda e em requisições entre origens (CORS).
• No Application Gateway, o desafio de JavaScript está em versão prévia e não tem suporte para regras personalizadas de limite de taxa. O Application Gateway for Containers WAF não oferece suporte a 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 a cada endereço IP do socket, que é o endereço do cliente que abre a conexão TCP com o Azure Front Door e pode ser um proxy, e não necessariamente o usuário final.
• Os limiares são avaliados ao longo de uma janela fixa de um ou cinco minutos. Uma vez que o limite é excedido, o Azure Front Door bloqueia todo o tráfego que corresponde à regra durante o restante da janela. Use a janela de cinco minutos para mitigação de ataques de inundação HTTP: um atacante bloqueado no primeiro minuto continua 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.
• As regras de limitação de taxa oferecem suporte apenas às ações Log e Block; Allow não tem suporte.
• Aplique uma regra a todo o tráfego correspondendo a um cabeçalho Host com comprimento superior a 0, pois toda solicitação válida para o Azure Front Door tem esse cabeçalho.

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.

• Os limiares não são aplicados com exatidão, portanto não use limitação de taxa para controle granular do tráfego. Use para mitigar taxas anômalas e manter a disponibilidade. Tenha cautela especial com regras de correspondência ampla que usam GeoLocation ou None; um limite mal escolhido pode causar interrupções curtas frequentes no 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 região geográfica transformam 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:

• Application Gateway WAF v2 - use GroupByVariable: GeoLocation (ou GeoLocationXFFHeader atrás de uma CDN ou proxy) para que todo o tráfego de uma mesma região geográfica compartilhe o mesmo contador, e crie uma regra de limitação de taxa por nível com seu próprio limiar. Como isso afeta todos os clientes nessa área geográfica, dimensione esses limites de forma conservadora e valide-os primeiro na ação Log: uma regra geográfica com correspondência ampla configurada incorretamente pode causar interrupções curtas e frequentes no tráfego legítimo.
• Azure Front Door - os contadores são por endereço IP de soquete, então crie as camadas com condições de correspondência geográfica: uma regra de limitação de taxa por camada, aplicada aos países relevantes, cada regra com seu próprio limite. Cada cliente em uma região de cauda longa passa a ter um teto muito mais baixo do que o dos clientes em seus mercados principais, sem que o comportamento de um cliente afete os demais.

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

• Ordene as regras da mais específica para a menos específica: as regras do mercado primário com prioridade mais alta (valor numérico mais baixo), depois as do mercado secundário, depois as de cauda longa, com a regra global abrangente como sua regra de limite de taxa de menor prioridade.
• Prefira 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 valor limite com base no seu próprio tráfego

Use a consulta a seguir de análise de logs para dimensionar a regra catch-all. 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 limiar acima do 99º percentil do tráfego em períodos normais, não no valor máximo. O valor máximo geralmente é um crawler ou um cliente mal configurado, e dimensionar com base nele faz com que a regra fique permissiva demais para ajudar a atenuar 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 da correspondência de strings, as regras personalizadas do Azure Front Door WAF podem corresponder a:

• 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 de AS (ASN): Mitigue ataques de inundação originados de um provedor de hospedagem ou de uma rede de trânsito IP da qual seus usuários legítimos não se originam, sem precisar enumerar faixas de IP.
• Impressão digital do cliente (JA4): Correspondência com a impressão digital JA4, um hash derivado do handshake TLS do cliente e de suas características HTTP. Como as ferramentas de ataque e os clientes de botnet produzem uma impressão digital consistente independentemente do endereço IP a partir do qual enviam o tráfego, o JA4 é uma das assinaturas mais duráveis disponíveis em um ataque distribuído: alternar entre milhares de endereços IP de origem não muda a impressão digital, e bloquear ou aplicar limitação de taxa com base nela derruba a botnet inteira com uma única regra. Verifique a impressão digital nos seus logs de período de operação normal antes de aplicá-la. 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. Primeiro, implante a ação Log, confirme que a impressão digital aparece somente no tráfego de ataque e, em seguida, alterne para Bloquear ou para uma regra de limitação de taxa.
• Combine o JA4 com outras condições para atenuação cirúrgica durante um incidente. Por exemplo, aplique limitação de taxa em vez de bloquear uma fingerprint JA4 específica e um ASN de onde você não atende usuários, ou uma fingerprint JA4 específica e um URI de requisiçã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 correspondência Permitir para tráfego legítimo conhecido a fim de reduzir falsos positivos e atribua a elas uma prioridade maior (valor numérico menor) do que suas regras de bloqueio e limitação de taxa. Lembre-se de que uma regra de Permitir ignora outras verificações do WAF, mas não ignora o conjunto de regras de DDoS HTTP.
• A avaliação das regras é interrompida por 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. As respostas em cache absorvem os picos de volume na borda da rede e reduzem a taxa de solicitações que chega ao seu servidor de origem, o que muitas vezes representa a diferença entre um desempenho degradado e uma indisponibilidade.
• Dimensione as origens com margem de capacidade. 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 o WAF e os logs de acesso em busca de uma mudança repentina na taxa de solicitações, na quantidade de IPs de clientes, na distribuição geográfica, na distribuição de agentes de usuário e nas URIs solicitadas.
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 correspondências das regras de limite de taxa.
3. Compare a composição geográfica com sua linha de base. O fato de um país que normalmente contribui com uma pequena parcela do tráfego passar subitamente a dominá-lo é um sinal rápido de ataque com alto grau de confiança. Também informa qual nível das regras de limitação de taxa você deve tornar mais restritivo 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 a origem protegida enquanto você faz os ajustes: verifique se o cache está ativado, confirme a restrição de acesso à origem e escale horizontalmente.
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 geradores de tráfego e principais agentes de usuário durante o período do ataque (Azure Front Door mostrado; substitua ApplicationGatewayAccessLog por Gateway de Aplicativo):

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
• Configuração do WAF: Azure Front Door | Application 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