Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: ✔️ Front Door Premium
As inundações na camada HTTP continuam a ser a causa mais frequente de incidentes de disponibilidade de aplicações, e controlos estáticos como filtros IP e geo ou limites fixos de taxa muitas vezes não conseguem acompanhar as botnets distribuídas. O conjunto de regras HTTP DDoS é o modelo automatizado de proteção de camada 7 do Firewall de Aplicações Web do Azure (WAF) que aprende, deteta e defende com uma configuração mínima do utilizador. Uma vez atribuído, o conjunto de regras estabelece continuamente a 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 infrator sem necessidade de ajuste de emergência.
Como funciona o conjunto de regras HTTP DDoS
Uma vez aplicado o conjunto de regras HTTP DDoS a uma política associada a um perfil Azure Front Door Premium, as linhas base de tráfego são calculadas usando uma janela móvel. Para perfis que receberam tráfego durante pelo menos 50% dos últimos sete dias, o conjunto de regras calcula linhas de base e começa a detetar picos dentro de 24 a 36 horas. Se o perfil Front Door não tiver recebido tráfego suficiente (menos de 50% do tráfego dos últimos sete dias), o conjunto de regras não irá detetar nem mitigar ataques até que haja tráfego suficiente para estabelecer bases fiáveis.
Os limites de pedidos são aprendidos ao nível do perfil global. Se uma única política WAF configurada com o conjunto de regras HTTP DDoS for atribuída a múltiplos perfis Azure Front Door, os limiares de tráfego são calculados separadamente para cada perfil ao qual a política está associada.
O conjunto de regras utiliza um design em duas etapas. O sistema aprende um limiar global de perfil, mais 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 limiar do perfil para pedidos seja ultrapassado, os limiares mais estreitos não são aplicados. Esta abordagem impede que o conjunto de regras atue sobre picos de tráfego de alguns clientes, a menos que façam com que a taxa total de pedidos em todo o perfil ultrapasse o limiar.
Cada regra no conjunto de regras HTTP DDoS oferece três níveis de sensibilidade, cada um correspondendo a um limiar diferente. Uma definição de sensibilidade mais alta aplica um limiar mais baixo para essa regra, enquanto uma definição de sensibilidade mais baixa aplica um limiar mais alto. A definição padrão e recomendada é sensibilidade média.
Quando atribuis o conjunto de regras, as suas regras estão ativadas com a ação Log e sensibilidade média por defeito. Revê os registos e depois define a ação de cada regra para se adequar à tua aplicação.
O conjunto de regras HTTP DDoS é o primeiro conjunto de regras avaliado pelo Azure WAF, mesmo antes das regras personalizadas.
Importante
Quaisquer regras personalizadas configuradas com a ação Permitir não ignoram o conjunto de regras HTTP DDoS, mas ignoram todas as outras inspeções WAF. Para isentar tráfego confiável do conjunto de regras HTTP DDoS, use exceções.
A caixa de penalização
Uma vez ultrapassado o limiar do perfil, qualquer endereço IP do cliente que exceda o seu limiar para a regra 500100 ou 500110 é colocado numa caixa de penalização. Enquanto o endereço IP está na penalty box, o WAF aplica a ação configurada da regra aos seus pedidos. Quando o período da caixa de penalização termina, o endereço IP é avaliado normalmente novamente, e regressa à caixa de penalização se ultrapassar novamente o seu limiar.
Regras do conjunto de regras
O conjunto de regras HTTP DDoS aparece como Microsoft_HTTPDDoSRuleSet_1.0 nas regras geridas da sua política WAF e tem 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 a sua própria sensibilidade e ação.
| ID da regra | Regra | O que serve de linha de base | Status |
|---|---|---|---|
| 500100 | Anomalia detetada devido à elevada taxa de pedidos de clientes | Solicitações de cada endereço IP do cliente | Disponível ao público em geral |
| 500110 | Bots suspeitos a enviar um elevado número de pedidos | Pedidos de endereços IP que a Microsoft Threat Intelligence classifica como bots | Disponível ao público em geral |
| 500310 | Anomalia detetada numa elevada taxa de solicitações provenientes de geos de origem de grande volume | Solicitações de cada país/região de grande volume | Preview |
| 500320 | Anomalia detetada devido a uma taxa elevada de solicitações provenientes de geos de origem de baixo volume | Pedidos combinados de todos os outros países/regiões | Preview |
Regra 500100: Anomalia detetada devido a uma elevada taxa de pedidos de clientes: Esta regra acompanha e estabelece uma linha de base para todo o tráfego no perfil ao qual uma política está associada. Quando um cliente ultrapassa o limiar estabelecido, a ação configurada correspondente é acionada.
Regra 500110: Bots suspeitos a enviar uma elevada taxa de pedidos: Esta regra permite definir diferentes níveis de sensibilidade com base no tráfego classificado como bots pela Microsoft Threat Intelligence. Para bots suspeitos, o limiar padrão é mais rigoroso do que o limiar padrão para todos os outros endereços IP. Bots classificados como de alto risco são imediatamente bloqueados por esta regra quando o limiar global de perfil é ultrapassado.
As regras 500310 e 500320 são as regras geográficas, descritas na secção seguinte.
Regras geográficas (pré-visualização)
Importante
As regras geográficas no conjunto de regras HTTP DDoS, regras 500310 e 500320, estão atualmente em pré-visualização. O restante conjunto de regras HTTP DDoS tem disponibilidade geral. Consulte os Termos de Utilização Complementares das Visualizações Prévias do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão em beta, em pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
Per-IP limiares funcionam bem contra ataques em que cada cliente envia um grande volume de pedidos. São menos eficazes contra ataques altamente distribuídos, em que uma botnet distribui o seu tráfego por tantos endereços IP que cada um fica abaixo do seu próprio limiar. As regras geográficas adicionam uma segunda camada de defesa que define uma linha de base do tráfego por país/região em vez de por cliente.
Como funcionam as regras geo
A maioria das aplicações recebe a grande maioria do 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 limiar separado para cada país ou região de grande volume.
- A Regra 500320 aprende um limiar combinado para cada outro país ou região. Os pedidos provenientes de todas estas fontes de baixo volume contam juntos para este limiar único.
Por exemplo, suponha que a maior parte do tráfego de um perfil vem dos Estados Unidos, Austrália e França. A regra 500310 aprende um limiar para cada um desses três, e a regra 500320 aprende um limiar para o tráfego combinado de todos os outros lugares. Durante um ataque, um pico vindo dos Estados Unidos é medido em relação ao limiar dos EUA, enquanto um ataque disperso por muitos outros locais é medido em relação ao limiar combinado.
As regras geográficas seguem o mesmo design em duas etapas que o resto do conjunto de regras: só atuam depois de a taxa global de pedidos do perfil ultrapassar o seu limiar aprendido. Quando isso acontece e a taxa de pedido de um país ou região de grande volume ultrapassa o seu limiar, a regra 500310 aplica a sua ação a pedidos desse país ou região. Quando a taxa combinada de pedidos de todos os outros países ou regiões ultrapassa o seu limiar, a regra 500320 aplica a sua ação a pedidos provenientes de todas essas fontes de baixo volume.
Tenha em mente os seguintes comportamentos:
- As regras geográficas aprendem as suas linhas de base a partir de aproximadamente os últimos sete dias de tráfego e recalculam-nas periodicamente, para acompanharem as alterações no seu tráfego ao longo do tempo.
- Os limiares refletem o seu pico de tráfego em vez da média, por isso os picos diários normais mantêm-se abaixo deles.
- Solicitações de endereços IP que não estão mapeados para um país ou região são agrupadas como país ou região Desconhecido (ZZ) e baselineadas como qualquer outro país ou região.
- Se um perfil não tiver histórico de tráfego suficiente para aprender referências fiáveis, as regras geográficas não tomam medidas para esse perfil.
- As regras geográficas são avaliadas após a regra 500100. Os clientes que excedem os seus próprios limiares por IP são tratados primeiro pela regra por IP, e as regras geográficas atuam então sobre o tráfego distribuído que se mantém abaixo dos limiares por IP.
Escolha ações e sensibilidade para as regras geo
Uma regra geográfica atua sobre o tráfego proveniente de um país ou região como um todo, não sobre clientes individuais. Quando uma regra geográfica corresponde, a sua ação aplica-se a utilizadores legítimos nesse país ou região, bem como a tráfego de ataque. Planeie nisso antes de alterar a ação predefinida:
- Começa com a ação Log. As regras geográficas estão ativadas com a ação Log por defeito. Revise os registos do tráfego normal e quaisquer picos antes de os impor.
- Prefira um desafio a um bloqueio. Um desafio JavaScript permite que navegadores legítimos passem enquanto bloqueia a maioria dos clientes scriptados, o que limita o efeito sobre utilizadores reais no país ou região afetada.
- Reduza a sensibilidade aos picos regionais esperados. Se esperar um aumento legítimo de um determinado país ou região, por exemplo durante uma campanha regional ou lançamento de produto, reduza a sensibilidade da regra afetada antes do evento.
Isentar o tráfego fidedigno 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, monitorização sintética, testes de carga ou integrações de parceiros, contorne o conjunto de regras, use exceções WAF. Pode limitar uma exceção a uma regra específica no conjunto de regras DDoS HTTP ou a todo o conjunto de regras, e corresponder ao endereço IP remoto, URI do pedido ou cabeçalho do pedido.
Restrinja as exceções ao máximo possível. Por exemplo, se uma ferramenta de teste de carga só precisar de alívio da regra 500100, não a isente das outras regras do conjunto de regras.
Monitorização do conjunto de regras HTTP DDoS
As seguintes opções de monitorização estão disponíveis para o conjunto de regras HTTP DDoS:
- Quando um endereço IP ultrapassa pela primeira vez um limiar para a regra 500100 ou 500110, é registada uma entrada de registo para esse endereço IP com a ação da regra, e a métrica Match da regra gerida do WAF é incrementada.
- Pode monitorizar correspondências de regras usando a métrica Firewall de Aplicações Web Request count e filtrando por nome de regra. As correspondências de regras Geo são registadas sob os IDs de regras 500310 e 500320.
- A métrica Firewall de Aplicações Web HTTPDDoSRuleset Is Active tem um valor de
1uma vez que o conjunto de regras concluiu a aprendizagem e está pronto para agir sobre o tráfego que ultrapasse os limiares aprendidos.