Conjunto de regras HTTP DDoS no Azure Front Door WAF

Aplica-se a: ✔️ Front Door Premium

Inundações na camada HTTP continuam sendo o fator mais frequente de incidentes de disponibilidade de aplicações, e controles estáticos como filtros IP e geo ou limites fixos de taxa frequentemente não conseguem acompanhar botnets distribuídos. O conjunto de regras HTTP DDoS é o modelo automatizado de proteção da camada 7 do Firewall de Aplicativo Web do Azure (WAF) que aprende, detecta e defende com configuração mínima do usuário. Uma vez atribuído, o conjunto de regras estabelece continuamente uma linha de base do tráfego normal para cada perfil do Azure Front Door e, quando picos indicam um ataque, mitiga seletivamente o tráfego malicioso sem necessidade de ajuste de emergência.

Como funciona o conjunto de regras de DDoS HTTP

Uma vez que o conjunto de regras HTTP DDoS é aplicado a uma política anexada a um perfil Azure Front Door Premium, as linhas de base de tráfego são calculadas usando uma janela móvel. Para perfis que receberam tráfego por pelo menos 50% dos últimos sete dias, o conjunto de regras calcula linhas de base e começa a detectar picos em 24 a 36 horas. Se o perfil Front Door não recebeu tráfego suficiente (menos de 50% dos últimos sete dias), o conjunto de regras não detectará nem mitigará ataques até que haja tráfego suficiente para estabelecer bases confiáveis.

Os limites de solicitação são aprendidos no nível global do perfil. Se uma única política de WAF configurada com o conjunto de regras de DDoS HTTP for atribuída a vários perfis do Azure Front Door, os limites de tráfego serão computados separadamente para cada perfil ao qual a política está anexada.

O conjunto de regras utiliza um design em duas etapas. Ele aprende um limiar global de perfil, além de limiares mais estreitos para endereços IP individuais de clientes e, com as regras geográficas, para cada país/região. Até que o limite de perfil para requisições seja ultrapassado, os limites mais restritos não são aplicados. Essa abordagem impede que o conjunto de regras atue sobre picos de tráfego de poucos clientes, a menos que eles façam com que a taxa total de solicitações em todo o perfil ultrapasse esse limite.

Cada regra no conjunto de regras de DDoS HTTP oferece três níveis de confidencialidade, cada um correspondente a um limite diferente. Uma configuração de confidencialidade mais alta aplica um limite inferior para essa regra, enquanto uma configuração de confidencialidade inferior aplica um limite mais alto. A sensibilidade média é a configuração padrão e recomendada.

Quando você atribui o conjunto de regras, suas regras são ativadas com a ação Log e sensibilidade média por padrão. Revise os logs e então defina a ação de cada regra para se adequar à sua aplicação.

O conjunto de regras de DDoS HTTP é o primeiro conjunto de regras avaliado pelo WAF do Azure, mesmo antes das regras personalizadas.

Importante

Qualquer regra personalizada configurada com a ação Permitir não vai contornar o conjunto de regras HTTP DDoS, mas vai contornar todas as outras inspeções WAF. Para isentar tráfego confiável do conjunto de regras HTTP DDoS, use exceções.

A área de penalidade

Uma vez que o limite do perfil é ultrapassado, qualquer endereço IP do cliente que exceda seu limite para a regra 500100 ou 500110 é colocado em penalty box. Enquanto o endereço IP está na penalty box, o WAF aplica a ação configurada da regra às suas solicitações. Quando o período da caixa de penalidade termina, o endereço IP é avaliado normalmente novamente, e ele retorna à caixa de penalidade se ultrapassar seu limite novamente.

Regras do conjunto de regras

O conjunto de regras HTTP DDoS aparece como Microsoft_HTTPDDoSRuleSet_1.0 nas regras gerenciadas da sua política WAF e possui quatro regras. Cada regra mantém linhas de base de tráfego separadas para o tráfego que corresponde aos seus critérios, e cada uma é configurável com sua própria sensibilidade e ação.

ID da regra Regra O que ele define como linha de base Status
500100 Anomalia detectada devido à alta taxa de solicitações de clientes Solicitações de cada endereço IP de cliente Geralmente disponível
500110 Supostos bots enviando alta taxa de solicitações Solicitações de endereços IP que a Microsoft Threat Intelligence classifica como bots Geralmente disponível
500310 Anomalia detectada devido à alta taxa de solicitações de geolocalizações de origem de alto volume Solicitações de cada país/região de alto volume Preview
500320 Anomalia detectada devido à alta taxa de solicitações de geolocalizações de origem de baixo volume Solicitações combinadas de cada outro país/região Preview

Regra 500100: Anomalia detectada devido à alta taxa de solicitações de clientes: Esta regra rastreia e estabelece uma linha de base para todo o tráfego no perfil ao qual uma política está associada. Quando um cliente excede o limite estabelecido, a ação configurada correspondente é disparada.

Regra 500110: Bots suspeitos enviando alta taxa de solicitações: Essa regra permite que você defina diferentes níveis de sensibilidade com base no tráfego classificado como bots pela Microsoft Threat Intelligence. Para bots suspeitos, o limite padrão é mais rigoroso do que o limite padrão para todos os outros endereços IP. Os bots classificados como de alto risco são bloqueados imediatamente por essa regra quando o limite global do perfil é violado.

As regras 500310 e 500320 são as regras geográficas, descritas na próxima seção.

Regras geográficas (visualização prévia)

Importante

As regras geográficas no conjunto de regras HTTP DDoS, regras 500310 e 500320, estão atualmente em prévia. O restante do conjunto de regras de DDoS HTTP está em disponibilidade geral. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

Per-IP limiares funcionam bem contra ataques nos quais cada cliente envia um grande volume de requisições. Eles são menos eficazes contra ataques altamente distribuídos, nos quais uma botnet distribui seu tráfego por tantos endereços IP que cada um fica abaixo do seu próprio limite. As regras geográficas adicionam uma segunda camada de defesa que define uma linha de base para o tráfego por país/região em vez de por cliente.

Como funcionam as regras geo

A maioria dos aplicativos recebe a grande maioria de seu tráfego legítimo de um pequeno número de países ou regiões de alto volume. As regras geográficas usam esse padrão:

  • A Regra 500310 aprende um limite separado para cada país ou região de alto volume.
  • A Regra 500320 aprende um limite combinado para cada outro país ou região. As solicitações de todas essas fontes de baixo volume contam juntas para esse limiar único.

Por exemplo, suponha que a maior parte do tráfego de um perfil venha dos Estados Unidos, Austrália e França. A regra 500310 aprende um limite para cada um desses três, e a regra 500320 aprende um limite para o tráfego combinado de qualquer outro lugar. Durante um ataque, um aumento vindo dos Estados Unidos é medido em relação ao limiar dos EUA, enquanto um ataque disperso em muitos outros locais é medido em relação ao limiar combinado.

As regras geográficas seguem o mesmo design em duas etapas do restante do conjunto de regras: elas atuam somente após a taxa total de solicitações do perfil ultrapassar seu limiar aprendido. Quando isso acontece e a taxa de solicitação de um país ou região de alto volume ultrapassa seu limite, a regra 500310 aplica sua ação a solicitações daquele país ou região. Quando a taxa combinada de solicitações de cada outro país ou região ultrapassa seu limite, a regra 500320 aplica sua ação a solicitações de todas essas fontes de baixo volume.

Tenha em mente os seguintes comportamentos:

  • As regras geográficas aprendem suas linhas de base a partir de aproximadamente os últimos sete dias de tráfego e as recalculam periodicamente, para acompanhar as mudanças no seu tráfego ao longo do tempo.
  • Os limiares refletem seu pico de tráfego, e não a média, então os picos diários normais permanecem abaixo deles.
  • Solicitações de endereços IP que não são mapeadas para um país ou região são agrupadas como país ou região desconhecida (ZZ) e definidas como linha de base como qualquer outro país ou região.
  • Se um perfil não tem histórico de tráfego suficiente para aprender linhas de base confiáveis, as regras geográficas não tomam medidas para esse perfil.
  • As regras geográficas são avaliadas após a regra 500100. Clientes que excedem seus próprios limites por IP são tratados primeiro pela regra por IP, e as regras geográficas então atuam sobre o tráfego distribuído que permanece abaixo dos limites por IP.

Escolha ações e sensibilidade para as regras geo

Uma regra geográfica atua sobre o tráfego de um país ou região como um todo, não sobre clientes individuais. Quando uma regra geográfica corresponde, sua ação se aplica a usuários legítimos naquele país ou região, bem como ao tráfego de ataques. Planeje isso antes de mudar a ação padrão:

  • Comece com a ação Log. As regras geográficas são ativadas com a ação Log por padrão. Revise os registros nos períodos de tráfego normal e de picos antes de impô-las.
  • Prefira um desafio a um bloqueio. Um desafio JavaScript permite que navegadores legítimos passem, enquanto bloqueia a maioria dos clientes automatizados, o que limita o efeito sobre usuários reais no país ou região afetada.
  • Reduza a sensibilidade para picos regionais esperados. Se você espera um aumento legítimo de um país ou região específica, por exemplo, durante uma campanha regional ou lançamento de produto, reduza a sensibilidade da regra afetada antes do evento.

Isentar o tráfego confiável do conjunto de regras

Uma regra personalizada com uma ação Permitir não contorna o conjunto de regras HTTP DDoS. Para permitir que tráfego conhecido como legítimo, como sondas de saúde, monitoramento sintético, testes de carga ou integrações de parceiros, contorne o conjunto de regras, use exceções WAF. Você pode definir o escopo de uma exceção para uma regra específica no conjunto de regras HTTP DDoS ou para todo o conjunto de regras, e fazer correspondência com base no endereço IP remoto, no URI da solicitação ou em um cabeçalho da solicitação.

Mantenha as exceções de escopo o mais restritas possível. Por exemplo, se uma ferramenta de teste de carga só precisa de exceção à regra 500100, não a isente das outras regras do conjunto de regras.

Monitorando o conjunto de regras de DDoS HTTP

As seguintes opções de monitoramento estão disponíveis para o conjunto de regras HTTP DDoS:

  • Quando um endereço IP ultrapassa pela primeira vez um limite para a regra 500100 ou 500110, uma entrada de log é registrada para esse endereço IP com a ação da regra, e a métrica de correspondência de regras gerenciadas pelo WAF é incrementada.
  • Você pode monitorar correspondências de regras usando a métrica de contagem de requisições do Firewall de Aplicativo Web e filtrando por nome da regra. As correspondências da regra Geo são registradas sob os IDs de regras 500310 e 500320.
  • A métrica Firewall de Aplicativo Web HTTPDDoSRuleset Is Active tem um valor de 1 quando o conjunto de regras conclui o aprendizado e está pronto para agir sobre tráfego que ultrapasse os limites aprendidos.

Conteúdo relacionado

  • Última atualização em