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 capta o tráfego que a camada acima dela não capta.

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 esteja a aprender o teu padrão de tráfego antes de ser necessária.
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. Ative a cache no Azure Front Door para que os picos súbitos de tráfego sejam absorvidos na periferia da rede em vez de na origem.
8. Proteja a sua exposição a 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 da plataforma contra DDoS por predefinição. 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 extremidade de rede do Front Door, em vez de num endereço IP que lhe pertença, pelo que não existe nenhum endereço IP público seu para um atacante visar nas camadas L3/L4. Essa proteção é inerente à plataforma, pelo que não precisa de comprar nem de ativar nada para beneficiar dela.

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, estabelece continuamente uma referência do tráfego normal e, quando picos 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 (para cada perfil do Front Door, ou para cada gateway de aplicações) como limiares individuais com base no 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 a múltiplos gateways, o serviço calcula os limiares separadamente para cada um deles.
• 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.
• Ignorar o conjunto de regras para tráfego fidedigno. 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 Gateway de Aplicação, utilize a métrica blocos da caixa de penalização para obter a contagem real de bloqueios e tamanho da caixa de penalização para saber quantos endereços IP estão atualmente penalizados.

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

Quando um endereço IP excede um limiar, é registada uma entrada no registo com a ação Block para o conjunto de regras HTTP DDoS, e a métrica WAF Managed Rule Match é incrementada.

• Front Door: utilize a métrica Firewall de Aplicações Web Request count, filtrada pelo nome da regra, para contar bloqueios, e a métrica Firewall de Aplicações Web HTTPDDoSRuleset Is Active, que indica 1 quando a aprendizagem estiver concluída e o conjunto de regras estiver pronto para atuar sobre o tráfego que ultrapasse os limiares 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.

As exceções correspondem a:

• 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:

• Delimite o âmbito tão restrito quanto 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.
• As exceções requerem o motor WAF de nova geração e a versão DRS 2.1 ou posterior do conjunto de regras gerido.

Utilize a ferramenta certa para cada tarefa: as exclusões ignoram a inspeção de um elemento de um pedido (um cookie ou cabeçalho problemático), continuando a inspecionar o restante pedido; as exceções ignoram regras ou conjuntos de regras específicos para pedidos que correspondam; uma regra personalizada de Permitir ignora tudo, exceto o conjunto de regras de DDoS HTTP.

Questiona antes de bloquear

O bloqueio é uma medida rudimentar num ataque L7: o tráfego de ataque chega frequentemente a partir de endereços IP e de regiões geográficas que também incluem utilizadores legítimos. Os mecanismos de desafio permitem separar o tráfego automatizado do tráfego humano sem os danos colaterais de um bloqueio total, e constituem a maior mudança na forma como o Azure WAF lida com ataques de inundação de camada 7, em comparação com uma estratégia de limitação de taxa baseada apenas em bloqueio.

• 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 ao endpoint de desafio não são encaminhados para o backend e não são contabilizados para efeitos de 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 de JavaScript é emitido novamente quando o endereço IP de um cliente muda e para pedidos entre origens (CORS).
• No Application Gateway, o desafio JavaScript está em pré-visualização e não é suportado para regras personalizadas de limite de taxa. O Application Gateway for Containers WAF não suporta tal.

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. Utilize a janela de cinco minutos para mitigação de floods HTTP: um atacante bloqueado no primeiro minuto continua bloqueado durante os 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 mais elevados também reforçam a aproximação do limiar configurado. Com limiares muito baixos (abaixo de cerca de 200 pedidos por minuto), alguns pedidos acima do limiar podem passar, porque os pedidos de um cliente podem chegar a servidores Front Door cujos contadores ainda não foram atualizados.
• As regras de limitação de taxa suportam apenas as ações Log e Block; Allow não é uma ação suportada.
• Aplique uma regra a todo o tráfego, fazendo a correspondência com um cabeçalho Host com um comprimento superior a 0, porque todos os pedidos válidos para o Azure Front Door têm 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 seu gateway está atrás de uma CDN ou proxy e o endereço IP real do cliente está em 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 com correspondência restrita, como uma página de início de sessão ou uma lista de agentes de utilizador suspeitos

• As regras de limitação de taxa exigem a versão mais recente do motor WAF (selecione o CRS 3.2 ou posterior para o conjunto de regras predefinido) e não são suportadas em nuvens com isolamento físico.

• 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 com exatidão, por isso não uses a limitação da taxa para controlo detalhado do tráfego. Use-o para mitigar taxas anómalas e manter a disponibilidade. Tenha especial cautela com regras de correspondência ampla que usem GeoLocation ou None; um limiar mal escolhido pode causar interrupções curtas e frequentes no 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 ultrapassagem afeta todos os clientes nessa região geográfica, defina estes limiares de forma conservadora e valide-os primeiro na ação Log: uma regra geográfica com correspondência ampla incorretamente configurada pode causar interrupções curtas frequentes no tráfego legítimo.
• Azure Front Door - os contadores são por endereço IP do socket, por isso crie os escalões com condições de correspondência geográfica: uma regra de limitação de taxa por escalão, aplicada aos países relevantes, cada regra 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 da mais específica para a menos específica: 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, sendo a regra global abrangente a regra de limitação de taxa com a 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 a partir do seu próprio tráfego

Utilize a seguinte consulta de Log Analytics para dimensionar a regra abrangente. 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 valor máximo é normalmente o de um crawler ou de um cliente mal configurado, e dimensionar com base nesse valor torna a regra demasiado permissiva 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 comparação de cadeias de caracteres, as regras personalizadas da WAF do Azure Front Door podem fazer correspondência com:

• 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 a partir do qual enviam, o JA4 é uma das assinaturas mais duradouras disponíveis durante um ataque distribuído: alternar entre milhares de endereços IP de origem não altera a impressão digital, e bloquear ou aplicar limitação de taxa com base nela neutraliza toda a botnet com uma única regra. Verifique a impressão digital em relação aos seus registos em tempo de paz antes de a aplicar. Navegadores populares e SDKs comuns partilham impressões digitais entre um número enorme de utilizadores legítimos, pelo que um bloqueio JA4 não validado pode ser extremamente abrangente. Implemente primeiro na ação Log, confirme que a impressão digital aparece apenas no tráfego de ataque e, em seguida, passe para Bloquear ou para uma regra de limitação 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.
• Etiqueta de serviço e restrições de tamanho nos componentes do pedido.

Duas práticas que importam durante um incidente:

• Crie regras de correspondência Permitir para tráfego legítimo conhecido, para reduzir falsos positivos, e atribua-lhes uma prioridade superior (valor numérico inferior) à das suas regras de bloqueio e de limitação de taxa. Lembre-se de que uma regra Allow ignora outras inspeções da WAF, mas não ignora o conjunto de regras de HTTP DDoS.
• 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 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 o armazenamento em cache no Azure Front Door. As respostas em cache absorvem os picos de volume na periferia da rede e reduzem a taxa de pedidos que chega ao seu servidor de origem, o que muitas vezes faz a diferença entre um desempenho degradado e uma indisponibilidade.
• Expanda as origens com margem de capacidade. 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. Veja o que já está a ser mitigado. 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. Rever correspondências de regras de limite de taxa.
3. Compara a composição geográfica com a tua base de referência. Um país que normalmente representa uma pequena parcela do tráfego e que, de repente, passa a dominá-lo é um sinal rápido e fiável de ataque. Também indica qual o nível das regras de limitação de taxa que deve tornar mais restritivas primeiro.
4. Aumentar a sensibilidade antes de escrever 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 de JavaScript às rotas HTML afetadas e o CAPTCHA aos 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. Mantenha a origem protegida enquanto afina: verifique se a cache está ativada, confirme a restrição de acesso à origem e escale horizontalmente.
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
• Lista de exceções do WAF: Azure Front Door WAF | Application Gateway WAF
• Limitação de taxa: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front Door | Application 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