Ensemble de règles HTTP DDoS dans Azure Front Door WAF

S’applique à : ✔️ Front Door Premium

Les attaques par inondation au niveau HTTP restent le facteur le plus fréquent des incidents de disponibilité des applications, et les contrôles statiques tels que les filtres IP et géo ou les limites de débit fixes ne peuvent souvent pas suivre le rythme des botnets distribués. Le système de règles HTTP DDoS est le modèle automatisé de protection de couche 7 d'Azure Web Application Firewall (WAF) qui apprend, détecte et défend avec une configuration utilisateur minimale. Une fois assigné, le système de règles établit en continu une base de référence pour chaque profil Azure Front Door et, lorsque les pics de trafic indiquent une attaque, atténue sélectivement le trafic malveillant sans qu’aucun réglage d’urgence ne soit nécessaire.

Fonctionnement de l’ensemble de règles HTTP DDoS

Une fois que le jeu de règles HTTP DDoS est appliqué à une politique attachée à un profil Azure Front Door Premium, les niveaux de référence du trafic sont calculés à l’aide d’une fenêtre glissante. Pour les profils ayant reçu du trafic pendant au moins 50 % des sept derniers jours, l’ensemble de règles calcule des valeurs de référence et commence à détecter les pics dans un délai de 24 à 36 heures. Si le profil Front Door n’a pas reçu suffisamment de trafic (moins de 50% des sept derniers jours), le système de règles ne détectera ni ne mitigera les attaques tant qu’il n’y aura pas suffisamment de trafic pour établir des bases fiables.

Les seuils de demande sont appris au niveau du profil global. Si une stratégie WAF unique configurée avec l’ensemble de règles HTTP DDoS est affectée à plusieurs profils Azure Front Door, les seuils de trafic sont calculés séparément pour chaque profil auquel la stratégie est attachée.

Le jeu de règles utilise une conception en deux étapes. Il apprend un seuil global de profil, ainsi que des seuils plus étroits pour les adresses IP individuelles des clients et, avec les règles géographiques, pour chaque pays/région. Tant que le seuil de profil pour les requêtes n’est pas dépassé, les seuils les plus étroits ne sont pas appliqués. Cette approche empêche l’ensemble de règles d’intervenir en cas de pics de trafic provenant de quelques clients, sauf si ceux-ci entraînent un dépassement du seuil par le taux total de requêtes pour l’ensemble du profil.

Chaque règle dans l’ensemble de règles HTTP DDoS offre trois niveaux de confidentialité, chacun correspondant à un seuil différent. Un paramètre de sensibilité plus élevé applique un seuil inférieur pour cette règle, tandis qu’un paramètre de sensibilité inférieur applique un seuil plus élevé. La valeur par défaut et recommandée est la sensibilité moyenne.

Lorsque vous assignez le jeu de règles, ses règles sont activées avec l’action Log et une sensibilité moyenne par défaut. Examinez les logs, puis réglez l’action de chaque règle pour qu’elle corresponde à votre application.

Le jeu de règles HTTP DDoS est le premier ensemble de règles évalué par le WAF Azure, même avant les règles personnalisées.

Important

Toute règle personnalisée configurée avec l’action Allow ne contournera pas le jeu de règles DDoS HTTP, mais contournera toutes les autres inspections WAF. Pour exempter le trafic de confiance de l’ensemble de règles DDoS HTTP, utilisez des exceptions.

Zone de pénalité

Une fois le seuil de profil franchi, toute adresse IP client dépassant son seuil pour la règle 500100 ou 500110 est placée dans une boîte de pénalité. Tant que l’adresse IP est dans la penalty box, le WAF applique l’action configurée par la règle à ses requêtes. Lorsque la période de la boîte de pénalité se termine, l’adresse IP est à nouveau évaluée normalement, et elle revient dans la boîte de pénalité si elle dépasse à nouveau son seuil.

Règles de configuration

Le système de règles HTTP DDoS apparaît sous la forme Microsoft_HTTPDDoSRuleSet_1.0 dans les règles gérées de votre politique WAF et comporte quatre règles. Chaque règle conserve des valeurs de référence de trafic distinctes pour le trafic qui correspond à ses critères, et chacune peut être configurée avec sa propre sensibilité et sa propre action.

Identifiant de règle Rule Ce qu’il prend comme référence Status
500100 Anomalie détectée en raison d’un taux élevé de requêtes clientes Requêtes depuis chaque adresse IP client Généralement disponible
500110 Bots suspectés d’envoyer un grand nombre de requêtes Requêtes provenant d’adresses IP que Microsoft Threat Intelligence classe comme des bots Généralement disponible
500310 Anomalie détectée en raison d’un taux élevé de requêtes provenant de zones géographiques sources à fort volume Demandes provenant de chaque pays/région à fort volume Preview
500320 Anomalie détectée sur un taux élevé de requêtes provenant de géographies sources à faible volume Requêtes combinées provenant de tous les autres pays ou régions Preview

Règle 500100 : Anomalie détectée lors d’un taux élevé de requêtes clients : Cette règle suit et établit une base de référence pour tout le trafic sur le profil auquel une politique est attachée. Lorsqu’un client dépasse le seuil établi, l’action configurée correspondante est déclenchée.

Règle 500110 : Bots suspectés envoyant un taux élevé de requêtes : Cette règle vous permet de définir différents niveaux de sensibilité en fonction du trafic classé comme bots par le service de renseignement des menaces de Microsoft. Pour les bots suspects, le seuil par défaut est plus strict que le seuil par défaut pour toutes les autres adresses IP. Les bots classés comme à haut risque sont bloqués immédiatement par cette règle lorsque le seuil de profil global est enfreint.

Les règles 500310 et 500320 sont les règles géographiques, décrites dans la section suivante.

Règles géographiques (aperçu)

Important

Les règles géographiques de l’ensemble de règles HTTP DDoS, les règles 500310 et 500320, sont actuellement en aperçu. Le reste de l’ensemble de règles HTTP DDoS est généralement disponible. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.

Les seuils par IP fonctionnent bien contre les attaques dans lesquelles chaque client envoie un grand volume de requêtes. Ils sont moins efficaces contre des attaques très distribuées, dans lesquelles un botnet répartit son trafic sur tellement d’adresses IP que chacune reste en dessous de son propre seuil. Les règles géographiques ajoutent une deuxième couche de défense qui établit des valeurs de référence du trafic par pays ou région plutôt que par client.

Comment fonctionnent les règles géo

La plupart des applications reçoivent la grande majorité de leur trafic légitime provenant d’un petit nombre de pays ou régions à fort volume. Les règles géographiques utilisent ce modèle :

  • La règle 500310 définit un seuil distinct pour chaque pays ou région à fort volume.
  • La règle 500320 apprend un seuil combiné unique pour tous les autres pays ou régions. Les requêtes provenant de toutes ces sources à faible volume comptent ensemble pour ce seuil unique.

Par exemple, supposons que la majeure partie du trafic d'un profil provienne des États-Unis, de l'Australie et de la France. La règle 500310 apprend un seuil pour chacun de ces trois, et la règle 500320 apprend un seuil pour le trafic combiné provenant de partout ailleurs. Lors d’une attaque, un pic provenant des États-Unis est mesuré par rapport au seuil américain, tandis qu’une attaque dispersée sur de nombreux autres sites est mesurée par rapport au seuil combiné.

Les règles geo suivent le même design en deux étapes que le reste de l’ensemble : elles n’agissent qu’après que le taux global de demande du profil a dépassé son seuil appris. Lorsque cela se produit et que le taux de demande provenant d’un pays ou d’une région à fort volume dépasse son seuil, la règle 500310 applique son action aux demandes provenant de ce pays ou de cette région. Lorsque le taux combiné de demandes provenant de tous les autres pays ou régions dépasse son seuil, la règle 500320 applique son action aux demandes provenant de toutes ces sources à faible volume.

Gardez à l’esprit les comportements suivants :

  • Les règles géographiques déterminent leurs valeurs de référence à partir d’environ sept jours de trafic antérieur et les recalculent périodiquement afin de suivre l’évolution de votre trafic au fil du temps.
  • Les seuils reflètent votre pic de trafic plutôt que votre moyenne, donc les pics quotidiens normaux restent en dessous.
  • Les requêtes provenant d’adresses IP qui ne sont associées à aucun pays ou région sont regroupées sous Pays ou région inconnu (ZZ) et une valeur de référence est établie pour elles comme pour tout autre pays ou région.
  • Si un profil ne dispose pas d’un historique de trafic suffisant pour établir des valeurs de référence fiables, les règles géographiques n’agissent pas sur ce profil.
  • Les règles géo sont évaluées après la règle 500100. Les clients qui dépassent leurs propres seuils par IP sont gérés en premier par la règle par IP, puis les règles géographiques agissent ensuite sur le trafic distribué qui reste en dessous des seuils par IP.

Choisissez les actions et la sensibilité pour les règles géographiques

Une règle géographique agit sur le trafic provenant d’un pays ou d’une région dans son ensemble, et non sur des clients individuels. Lorsqu’une règle géographique correspond, son action s’applique aux utilisateurs légitimes de ce pays ou région ainsi qu’au trafic d’attaque. Prévoyez cela avant de changer l’action par défaut :

  • Commencez par l’action Log. Les règles de géolocalisation sont activées avec l’action Journalisation par défaut. Examinez les journaux sur l’ensemble du trafic normal et lors des pics éventuels avant de les mettre en application.
  • Préférez une vérification à un blocage. Une vérification JavaScript permet aux navigateurs légitimes de passer tout en arrêtant la plupart des clients automatisés, ce qui limite l’effet sur les utilisateurs réels du pays ou de la région concernée.
  • Réduire la sensibilité aux pics régionaux attendus. Si vous attendez un pic légitime provenant d’un pays ou d’une région particulière, par exemple lors d’une campagne régionale ou d’un lancement de produit, réduisez la sensibilité de la règle concernée avant l’événement.

Exclure le trafic approuvé de l’ensemble de règles

Une règle personnalisée avec une action Permettre ne contourne pas le système de règles HTTP DDoS. Pour permettre au trafic de qualité connue tel que les sondes de santé, la surveillance synthétique, les tests de charge ou les intégrations partenaires de contourner le jeu de règles, utilisez des exceptions WAF. Vous pouvez définir une exception à une règle spécifique dans le jeu de règles HTTP DDoS ou à l’ensemble des règles, et la faire correspondre à l’adresse IP distante, à l’URI de requête ou à un en-tête de requête.

Limitez autant que possible la portée des exceptions. Par exemple, si un outil de test de charge n’a besoin que d’une atténuation de la règle 500100, ne l’exemptez pas des autres règles de l’ensemble de règles.

Surveillance de l’ensemble de règles HTTP DDoS

Les options de surveillance suivantes sont disponibles pour le jeu de règles HTTP DDoS :

  • Lorsqu’une adresse IP dépasse pour la première fois un seuil pour la règle 500100 ou 500110, une entrée de journal est enregistrée pour cette adresse IP avec l’action de la règle, et la métrique de correspondance de la règle gérée par WAF est incrémentée.
  • Vous pouvez surveiller les correspondances de règles en utilisant la métrique Web Application Firewall Request count et en filtrant par nom de règle. Les correspondances de règles géographiques sont enregistrées sous les identifiants de règles 500310 et 500320.
  • La métrique Web Application Firewall HTTPDDoSRuleset Is Active a une valeur de 1 une fois que le jeu de règles a terminé l’apprentissage et est prêt à agir sur le trafic qui dépasse les seuils appris.