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

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

O Firewall de Aplicações 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 DDoS podem visar tanto a camada de rede (L3/L4) como a camada de aplicação (L7). O Azure DDoS Protection defende-o contra ataques volumétricos em grandes camadas de rede. O WAF do Azure, a operar na camada 7, protege aplicações web contra ataques DDoS L7, como inundações HTTP. Em conjunto, estas defesas impedem que os atacantes cheguem à sua aplicação e afetem a sua disponibilidade e desempenho.

Os ataques na camada de aplicação são baratos de lançar e difíceis de distinguir do tráfego legítimo: cada pedido parece válido por si só, e só a taxa agregada, a distribuição e a combinação de clientes revelam o ataque. A defesa eficaz de nível 7 depende, portanto, menos de um único controlo e mais de uma configuração em camadas que já está em funcionamento antes do início do ataque.

Escolhe as tuas camadas de defesa

Use o modelo seguinte ao planear proteção DDoS L7. Cada camada apanha tráfego que a camada acima não apanha.

Lista de verificação de configuração base

Completa estes passos antes de seres atacado. Ajuste-os para se adequarem aos requisitos da sua candidatura.

1. Deploye Azure WAF com Azure Front Door Premium ou Application Gateway WAF v2 para proteger contra ataques à camada de aplicação L7.
2. Mude a política WAF para modo de prevenção. Uma política em modo de deteção regista apenas e não bloqueia o tráfego. Verifique e ajuste primeiro a política contra tráfego de produção para reduzir falsos positivos, depois ative a prevenção.
3. Atribui o conjunto de regras HTTP DDoS (disponível tanto no Azure Front Door Premium como no Application Gateway WAF v2) para que a mitigação automática seja aprender a tua linha base de tráfego antes de precisares disso.
4. Ative o conjunto de regras gerido pelo Bot Manager para identificar e agir contra bots conhecidos como mau.
5. Configure pelo menos uma regra de limite de taxa genérica (ver Limitação de taxa).
6. Aumenta o número de instâncias de origem para haver capacidade suficiente e define o Application Gateway para escalar automaticamente sem impor um número máximo de instâncias baixo.
7. Ativa o cache no Azure Front Door para que o tráfego de picos repentinos seja absorvido na borda em vez de na tua origem.
8. Cobre a sua exposição L3/L4, que varia consoante a plataforma. Veja A proteção DDoS da plataforma varia consoante a plataforma. Bloqueie a sua origem para que aceite apenas tráfego do Azure Front Door ou do Application Gateway.
9. Ativa o registo de diagnóstico para Log Analytics e cria as consultas em Analisar WAF e acede aos registosantes de um incidente.

A proteção DDoS da plataforma varia consoante a plataforma

As 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 local.

O Azure Front Door tem proteção DDoS de plataforma por defeito. O Azure Front Door é um serviço de borda distribuído globalmente, e a sua borda está protegida pela proteção DDoS da infraestrutura do Azure, sem custos adicionais e sem configuração. O tráfego termina na borda da Porta Frontal em vez de num endereço IP que possui, por isso não há nenhum IP público teu para um atacante atacar em L3/L4. Essa proteção é inerente à plataforma, por isso não compra nem ativa nada para a aceder.

O Application Gateway necessita de proteção de rede Azure DDoS. 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 ao nível da infraestrutura do Azure protege a própria plataforma Azure, mas não fornece mitigação ajustada por recurso, telemetria ou relatórios de ataque para esse IP. Para proteger o IP público do gateway contra ataques volumétricos L3/L4, ative a Proteção de Rede DDoS Azure na rede virtual que o contém. Este é um serviço pago, comprado separadamente.

Consequências práticas quando escolhe ou projeta uma implementação:

• Se estiveres atrás do Azure Front Door, faz um orçamento para os controlos L7; a proteção de bordas L3/L4 já está lá.
• Se estiveres a usar o Application Gateway e não tiveres ativado o DDoS Network Protection, as tuas regras WAF podem ser perfeitamente ajustadas e ainda assim ser ultrapassadas por um ataque volumétrico ao IP público do gateway. Ativa-o.
• Em qualquer dos casos, os IPs públicos de origem que expões ainda precisam de Proteção de Rede DDoS do Azure, mais bloqueio para que só o serviço WAF os possa alcançar. Uma frente protegida em frente a uma origem não protegida e acessível publicamente não está protegida.

Para mais informações, consulte a visão geral da Proteção DDoS do Azure e Proteja o 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é-visualização)

Controlos estáticos como filtros IP, geo-filtros e limites fixos de taxa muitas vezes não conseguem acompanhar botnets distribuídos: os limiares são suposições, estão sempre ativados, e tens de os reajustar à medida que 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, deteta e defende com uma configuração mínima do utilizador. Está disponível em pré-visualização tanto no Azure Front Door Premium como no Application Gateway WAF v2. Uma vez atribuído, faz uma base contínua de tráfego normal e, quando surges indicam um ataque, bloqueia seletivamente os clientes infratores sem necessidade de ajuste de emergência.

O design é o mesmo em ambas as plataformas nos aspetos que mais importam:

• Dois limiares, avaliados em conjunto. O conjunto de regras aprende tanto um limiar global (por perfil Front Door, ou por gateway de aplicação) como limiares individuais baseados em IP. Os limiares baseados em IP só são aplicados depois de o limiar global ser ultrapassado. Este design impede que o conjunto de regras atue sobre picos provenientes de alguns endereços IP, a menos que realmente empurrem o tráfego total para além do normal.
• Definido por recurso. Os limiares são aprendidos ao nível global dos recursos. Se atribuir uma política WAF com o conjunto de regras a múltiplos perfis Front Door ou múltiplos gateways, o serviço calcula limiares separadamente para cada um.
• Sensibilidade. Cada regra oferece três níveis de sensibilidade. Sensibilidade mais elevada aplica um limiar mais baixo; uma sensibilidade mais baixa aplica um limiar mais elevado. Médio é a definiçã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 contorna todas as outras inspeções WAF, mas não contorna o conjunto de regras HTTP DDoS.
• Contornar o conjunto de regras para tráfego de confiança. Uma regra personalizada com uma ação Permitir não ajuda aqui – contorna todos os outros conjuntos de regras, mas não o conjunto de regras HTTP DDoS. Usa exceções WAF em vez disso, que podes atribuir a uma regra específica, grupo de regras ou a um conjunto inteiro de regras geridas, incluindo o conjunto de regras HTTP DDoS. Veja Isentar tráfego confiável com exceções.
• Requer trânsito sustentado. O conjunto de regras só pode funcionar quando aprender linhas de base fiáveis. Se um recurso não receber tráfego suficiente durante a fase de aprendizagem, o conjunto de regras não irá detetar nem proteger até que o faça. Consulte a tabela da plataforma para o requisito específico.

Diferenças de plataforma

Regras do conjunto de regras

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

A caixa de penalização

Ambas as plataformas mitigam através de uma caixa de penalização. Quando o tráfego de um cliente ultrapassa o limiar para uma das regras do conjunto de regras, esse endereço IP do cliente é colocado na caixa de penalização e bloqueado pelo WAF durante a duração da caixa de penalização, que é de 15 minutos no Application Gateway. Quando o período termina, o endereço IP recupera o acesso a menos que volte a ultrapassar o limiar, o que o devolve à caixa de penalização.

Este design é importante para a forma como lês a tua telemetria: apenas a regra inicial atingida é registada. Pedidos bloqueados adicionais enquanto o endereço IP já está na caixa de penalização não são registados no Front Door, por isso as contagens baseadas em registos subestimam o número de pedidos bloqueados. No Application Gateway, use a métrica de blocos da caixa de penalização para o número real de blocos e o tamanho da caixa de penalização para quantos endereços IP estão atualmente penalizados.

Monitorização durante a pré-visualização

Quando um endereço IP ultrapassa um limiar, uma entrada de registo é registada com uma ação de Bloco para o conjunto de regras HTTP DDoS e os incrementos da métrica WAF Managed Rule Match .

• Front Door: use a métrica de contagem de pedidos Firewall de Aplicações Web filtrada por nome de regra para contar blocos, e a métrica Firewall de Aplicações Web HTTPDDoSRuleset Is Active, que reporta 1 quando a aprendizagem está completa e o conjunto de regras está pronto para agir sobre o tráfego que ultrapassa os limites aprendidos.
• Gateway de Aplicação: cada pedido bloqueado subsequente de um endereço IP penalizado incrementa a métrica de Correspondência de Regras Geridas, e as métricas de tamanho da caixa de penalização e dos blocos da caixa de penalização rastreiam diretamente a caixa de penalização.

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

Sondas de saúde, monitorização sintética, testes de carga, integrações com parceiros e trabalhos internos em lote geram tráfego que parece uma inundação, mas não é. Historicamente, não há forma de os isentar do conjunto de regras DDoS, porque uma regra personalizada de Permitir contorna o conjunto de regras padrão, conjunto de regras core e proteção contra bots, mas deliberadamente não contorna o conjunto de regras HTTP DDoS.

Exceções WAF reduzem essa lacuna. Uma exceção contorna a inspeção WAF para pedidos que correspondam a atributos específicos, com âmbito para uma única regra, um grupo de regras ou um conjunto de regras gerido completo. Pode aplicar exceções ao conjunto de regras HTTP DDoS, bem como ao DRS, CRS e Proteção contra Bots.

Exceções correspondem em:

• Endereço IP remoto (Equals ou IP Match), que é a escolha habitual para isentar monitorização conhecida, testes de carga ou intervalos de fonte parceira do conjunto de regras DDoS
• Solicitar URI
• Peça nome e valor do cabeçalho, correspondido a Igual, Começa com, Termina com ou Contém

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

• Define o âmbito o mais restrito possível. Prefiro uma exceção por regra a isentar todo o conjunto de regras. Uma exceção ampla dá ao atacante um caminho documentado para contornar a sua mitigação automática. Se um gerador de carga só precisa de alívio da regra 500100, não o isenta também do 500110.
• Fontes isentas, não caminhos. Uma exceção baseada em IP para um harness de teste conhecido é limitada. Uma exceção baseada em URI num endpoint público é uma porta aberta para quem a encontrar.
• Revê-os num calendário. 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 pedido.
• Exceções exigem o motor WAF de próxima geração e o conjunto de regras gerido versão DRS 2.1 ou posterior.

Use a ferramenta certa para o trabalho: as exclusões saltam a inspeção de um elemento de um pedido (um cookie ou cabeçalho ruidoso) enquanto ainda inspecionam os restantes; as exceções saltam regras ou conjuntos de regras específicas para pedidos correspondentes; uma regra Allow personalizada contorna tudo, exceto o conjunto de regras HTTP DDoS.

Desafia antes de bloqueares

O bloqueio é um instrumento contundente durante um ataque L7: o tráfego de ataque chega frequentemente de endereços IP e geografias que também transportam utilizadores reais. Os desafios permitem separar a automação dos humanos sem os danos colaterais de um bloqueio direto, e são a maior mudança na forma 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 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 a avaliar as regras restantes; pedidos que falham são bloqueados. Use-o como o desafio padrão para tráfego web geral. Os pedidos para o endpoint de desafio não são encaminhados para o seu backend e não contam para limitação de taxa.
• O CAPTCHA é um desafio interativo que requer a participação do utilizador, melhor reservado para fluxos de alto valor como início de sessão, inscrição e checkout, onde o abuso automatizado é dispendioso e alguns segundos de fricção do utilizador são aceitáveis. A validade do cookie de desafio é configurável nas definições de política entre 5 e 1.440 minutos, com um padrão de 30 minutos. O CAPTCHA acarreta custos adicionais baseados no uso.

Planeie em torno das limitações de ambas as funcionalidades antes de as implementar:

• AJAX e chamadas API não são suportadas. Não coloques desafios à frente das rotas da API. Usa limites de taxa e regras de jogo aí em vez disso.
• Os desafios são concebidos para recursos HTML, não para imagens embutidas, CSS ou ficheiros JavaScript.
• No primeiro pedido que desencadeia um desafio, o corpo do POST está limitado a 64 KB no Azure Front Door e 128 KB no Application Gateway.
• Nenhuma das funcionalidades suporta o Internet Explorer; ambas 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 pedidos de origem cruzada (CORS).
• No Application Gateway, o desafio JavaScript está em pré-visualização 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 Velocidade

No mínimo, crie uma regra de limite de taxa que bloqueie uma elevada taxa de pedidos de qualquer cliente individual. Defina esta regra como a sua regra de limite de taxa de menor prioridade (valor numérico mais alto), para que regras de limite de taxa ou de correspondência mais específicas sejam avaliadas primeiro.

Azure Front Door

• Aplicam-se limites de taxa por endereço IP do socket, que é o endereço do cliente que abre a ligação TCP ao Azure Front Door e pode ser um proxy em vez do utilizador final.
• Os limiares são avaliados numa janela fixa de um ou cinco minutos. Uma vez ultrapassado o limiar, o Azure Front Door bloqueia todo o tráfego que corresponda à regra durante o restante da janela. Use a janela de cinco minutos para mitigação de inundações HTTP: um atacante bloqueado no primeiro minuto permanece bloqueado nos restantes quatro.
• Janelas maiores com o menor limiar aceitável são a configuração anti-DDoS mais eficaz. Janelas maiores e valores de limiar mais elevados também reforçam a aproximação do limiar configurado. A limiares muito baixos (abaixo de cerca de 200 pedidos por minuto), alguns pedidos acima desse limiar conseguem passar, porque pedidos de um cliente podem chegar a servidores Front Door cujos contadores ainda não foram atualizados.
• As regras de limite de taxa suportam apenas ações de Log e Block ; Permitir não é suportado.
• Aplique uma regra a todo o tráfego, correspondendo num Host cabeçalho com comprimento superior a 0, porque cada pedido válido ao Azure Front Door tem um.

Gateway de aplicativo WAF v2

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

• As regras requerem um GroupByUserSession, que controla como os pedidos são contados. Esta funcionalidade permite-lhe limitar a taxa por algo que não seja o IP do cliente:

  GroupByVariable	Use-o quando
  ClientAddr (predefinição)	Caso normal com contadores independentes por IP de origem
  ClientAddrXFFHeader	O teu gateway fica atrás de uma CDN ou proxy e o IP real do cliente está dentro X-Forwarded-For
  GeoLocation	Quer limitar o tráfego por país/região durante uma inundação geograficamente concentrada
  GeoLocationXFFHeader	Tal como acima, usando o endereço IP em X-Forwarded-For
  None	Um único contador partilhado para um padrão restrito, como uma página de início de sessão ou uma lista de agentes de utilizador suspeitos

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

• O Application Gateway conta os limiares de forma independente para cada endpoint a que a política está associada. Uma única política para cinco ouvintes mantém cinco conjuntos de contadores.

• Os limiares não são aplicados exatamente, por isso não uses limitação de taxa para controlo de tráfego detalhado. Use-o para mitigar taxas anómalas e manter a disponibilidade. Tenha especial cautela com regras de correspondência ampla que utilizem GeoLocation ou None; um limiar mal escolhido pode causar interrupções frequentes e curtas para tráfego legítimo.

Definir limiares conscientes da geografia

Um limiar global único tem de ser suficientemente generoso para o país mais movimentado, o que o torna demasiado generoso em todos os outros lugares. A maioria das aplicações tem um perfil geográfico fortemente distorcido em tempos de paz – um punhado de países ou regiões produz quase todo o tráfego legítimo, e o resto produz apenas um pouco de tráfego. O tráfego de ataque raramente respeita essa distribuição. Dimensionar limiares por geografia transforma essa assimetria tanto num sinal de deteção como num controlo de mitigação.

Comece por medir a sua distribuição em tempo de paz ao longo de pelo menos uma semana completa, para que os efeitos dos dias úteis, fins de semana e fusos horários sejam representados:

• No Azure Front Door, divida a métrica de contagem de pedidos pela dimensão ClientCountry.

• No Log Analytics, derive o país a partir do endereço IP do cliente no registo 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
  

Depois, agrupe os resultados em níveis e defina um limiar para cada um:

A forma como implementas os níveis depende da plataforma:

• Application Gateway WAF v2 - usar GroupByVariable: GeoLocation (ou GeoLocationXFFHeader atrás de uma CDN ou proxy) para que todo o tráfego de uma única geografia partilhe um contador, e criar uma regra de limite de taxa por nível com o seu próprio limiar. Como uma violação atua contra todos os clientes nessa geografia, dimensione estes limiares de forma conservadora e valide-os primeiro em ação de registo: uma regra geológica de grande 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 de socket, por isso constrói 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 o seu próprio limiar. Cada cliente numa geografia de cauda longa obtém então um teto muito mais baixo do que os clientes nos seus mercados principais, sem que o comportamento de um cliente afete os outros.

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

• Ordene as regras de mais específicas para menores: regras do mercado primário com prioridade mais alta (valor numérico mais baixo), depois secundária, depois long-tail, com a regra global do limite de prioridade mais baixa.
• 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 conjunto, mas ainda assim contém utilizadores reais – viajantes, utilizadores 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 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 a contribuir subitamente com 40% é uma das formas mais rápidas de confirmar que está a ver um ataque e não um crescimento orgânico.

Escolha um limiar do seu próprio tráfego

Utilize a seguinte consulta Log Analytics para definir 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 limiares 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

Definir o limiar acima do 99.º percentil do tráfego em tempo de paz, não no máximo. O máximo é normalmente um crawler ou um cliente mal configurado, e o tamanho dele torna a regra demasiado generosa para ajudar durante um ataque.

Regras personalizadas para mitigação direcionada

Crie regras WAF personalizadas para bloquear ou limitar ataques HTTP e HTTPS que tenham assinaturas identificáveis, como um agente de utilizador específico, cabeçalho, cookie, padrão de cadeia de consulta, URI, ou uma combinação dessas. Para além da correspondência de strings, as regras personalizadas WAF do Azure Front Door podem corresponder em:

• Geolocalização: Bloqueie o tráfego fora da sua região de serviço ou redirecione-o para uma página estática.
• Endereços IP do cliente (CIDR) e restrições de IP listam endereços e intervalos que identificou como maliciosos.
• Número AS (ASN): Mitigar inundações provenientes de um provedor de alojamento ou rede de trânsito de onde os seus utilizadores legítimos não vêm, sem enumerar intervalos 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 elimina toda a botnet com uma regra. Verifica a impressão digital com os teus registos de tempo de paz antes de a aplicares. Navegadores populares e SDKs comuns partilham impressões digitais sobre um enorme número de utilizadores legítimos, pelo que um bloco JA4 não validado pode ser extremamente amplo. Implemente 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.
• Combinar JA4 com outras condições para mitigação cirúrgica durante um incidente. Por exemplo, limitar a taxa em vez de bloquear uma impressão digital específica do JA4 e um ASN que não serve aos utilizadores, ou uma impressão digital do JA4 e um URI de pedido.
• Restrições de etiquetas de serviço e tamanho nos componentes do pedido.

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ê-lhes uma prioridade mais alta (valor numérico inferior) do que as regras de limite de bloco e taxa. Lembre-se que uma regra de Permitir contorna outras inspeções 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 pode inserir um durante um ataque sem necessidade de renumerar.

As regras geridas não são direcionadas para a defesa DDoS, mas protegem contra outros ataques comuns e devem manter-se ativadas. Veja Regras Geridas (Azure Front Door) ou Regras Geridas (Application Gateway).

Proteger a origem

• Bloqueie o acesso a IPs públicos na origem e restrinja o tráfego de entrada para que apenas o Azure Front Door ou o Application Gateway possam aceder. Siga as orientações para garantir o tráfego para as origens do Azure Front Door.
• Certifique-se de que não existem endereços IP publicamente expostos na rede virtual do Gateway de Aplicação.
• Ativar a cache no Azure Front Door. As respostas em cache absorvem o volume máximo na borda e reduzem a taxa de pedidos que chega à sua origem, o que muitas vezes é a diferença entre desempenho degradado e uma falha.
• Origem da escala com headroom. Mitigações automáticas e manuais demoram tempo a ser ativadas; A capacidade extra cobre essa lacuna.

Responder a um ataque ativo

1. Confirma que é um ataque, não crescimento orgânico. Verifique o WAF e os registos de acesso para uma alteração súbita na taxa de pedidos, contagem de IPs do cliente, composição geográfica, distribuição de agentes de utilizador e URIs solicitados.
2. Vê o que já está a mitigar. Confirme que o conjunto de regras HTTP DDoS está ativo e reveja os seus blocos pelo nome da regra. No Application Gateway, verifique também o tamanho da caixa de penalização e as métricas de blocos da caixa de penalidade , pois apenas o primeiro bloco por endereço IP aparece nos registos. Revê as correspondências das regras do limite de taxas.
3. Compara a composição geográfica com a tua base de referência. Um país que normalmente contribui com uma pequena parte do tráfego que de repente o domina é um sinal de ataque rápido e de alta confiança. Também te diz qual as regras de limite de taxa que deves apertar primeiro.
4. Aumenta a sensibilidade antes de escreveres novas regras. Aumentar a sensibilidade do conjunto de regras HTTP DDoS ou baixar um limite de taxa existente é mais rápido e seguro do que criar uma nova regra sob pressão.
5. Desafiar em vez de bloquear onde o trânsito está misturado. Aplicar o desafio JavaScript às rotas HTML afetadas e 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 URI. Implemente-o primeiro em Log action se o padrão também corresponder a utilizadores reais.
7. Mantém o Origin protegido enquanto ajustas: verifica se o cache está ativo, confirma o bloqueio do Origin e escala o controlo.
8. Após o incidente, reajuste os seus limites de taxa em relação aos novos dados de tráfego e mantenha as regras de emergência que se mostraram corretas no modo Log, caso não queira que sejam aplicadas continuamente.

Analisar WAF e registos de acesso

Monitorize o tráfego usando os logs WAF do Azure para anomalias e utilize-os para identificar endereços IP suspeitos que enviam números invulgarmente elevados de pedidos, cadeias de agentes de utilizador invulgares ou padrões anómalos de cadeias de consulta.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Gateway de Aplicação do Azure

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Principais faladores e principais agentes de utilizador na janela de ataque (Azure Front Door mostrado; substituto ApplicationGatewayAccessLog do 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, consulte Azure WAF com Azure Front Door e Azure WAF com Gateway de Aplicação do Azure.

Conteúdo relacionado

• HTTP DDoS ruleset: Azure Front Door WAF | Application Gateway WAF
• WAF exceptions list: Azure Front Door WAF | Application Gateway WAF
• Limite de taxa: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front DoorApplication | Gateway
• Azure WAF JavaScript challenge
• Azure Front Door WAF CAPTCHA
• Proteção DDoS no Azure Front Door
• Arquiteturas de referência Azure DDoS Protection
• Visão geral da Proteção contra DDoS do Azure