Protection DDoS contre l’application (couche 7)

S’applique à : ✔️ Application Gateway v2 ✔️ Front Door Premium

Azure Web Application Firewall (WAF) comprend plusieurs mécanismes de défense qui aident à prévenir les attaques par déni de service distribué (DDoS). Les attaques DDoS peuvent cibler la couche réseau (L3/L4) et la couche d’application (L7). Azure DDoS Protection vous protège contre les attaques volumétriques de grande ampleur au niveau de la couche réseau. Azure WAF, fonctionnant au niveau de la couche 7, protège les applications web contre les attaques DDoS L7 telles que les inondations HTTP. Ensemble, ces défenses empêchent les attaquants d’atteindre votre application et d’affecter sa disponibilité et ses performances.

Les attaques au niveau application sont peu coûteuses à lancer et difficiles à distinguer du trafic légitime : chaque requête semble valide en soi, et seuls le taux agrégé, la distribution et la composition des clients révèlent l’attaque. La défense efficace de niveau 7 repose donc moins sur un contrôle unique que sur une configuration en couches déjà en place avant le début de l’attaque.

Choisissez vos couches de défense

Utilisez le modèle suivant lorsque vous planifiez la protection DDoS L7. Chaque couche intercepte le trafic que la couche située au-dessus n’intercepte pas.

Couche Qu’est-ce que cela fait ? Où la configurer
Protection DDoS de plateforme Absorbe les attaques volumétriques L3/L4 sur la périphérie Azure et sur vos IP publiques d’origine Intégrée par défaut dans Azure Front Door ; nécessite Azure DDoS Network Protection pour les adresses IP publiques de la passerelle d’application et les adresses IP publiques d’origine
Atténuation automatisée de la couche 7 Apprend votre circulation habituelle et régule les clients délicats lors d’une surtension, sans réglage d’urgence Ensemble de règles HTTP DDoS (aperçu) sur Azure Front Door Premium et Application Gateway WAF v2
Vérification du client Sépare les humains et les clients légitimes du trafic d’attaque automatisé avant de bloquer Ensemble de règles Bot Manager, défi JavaScript, CAPTCHA
Limitation de débit de données Limite le nombre de requêtes qu’un client, une géographie ou un point de terminaison peut envoyer Règles personnalisées de limitation du débit sur Front Door et Application Gateway
Règles personnalisées ciblées Bloque une signature d’attaque connue lors d’un incident Faire correspondre des règles personnalisées (géo, IP, ASN, empreinte du client, en-tête, URI)
Protection de l’origine Empêche le trafic malveillant d’atteindre vos ressources de calcul Mise en cache, verrouillage de l’origine, mise à l’échelle automatique

Liste de contrôle de configuration de base

Terminez ces étapes avant d’être attaqué. Ajustez-les pour correspondre aux exigences de votre demande.

  1. Déploiez Azure WAF avec Azure Front Door Premium ou Application Gateway WAF v2 pour vous protéger contre les attaques de la couche application L7.
  2. Passez la politique WAF en mode prévention. Une politique en mode détection ne loge que le trafic et ne bloque pas. Vérifiez et ajustez d’abord la politique contre le trafic de production pour réduire les faux positifs, puis activez la prévention.
  3. Affectez le jeu de règles HTTP DDoS (disponible dans Azure Front Door Premium et Application Gateway WAF v2) afin que l’atténuation automatisée apprenne le niveau de référence de votre trafic avant que vous n’en ayez besoin.
  4. Activez le jeu de règles géré de Bot Manager pour identifier les bots malveillants connus et prendre des mesures contre eux.
  5. Configurez au moins une règle fourre-tout sur la limite de taux (voir Limitation de débit).
  6. Augmentez votre nombre d’instances d’origine pour qu’il y ait suffisamment de capacité disponible, et configurez Application Gateway pour qu’elle puisse s’autoscaler sans imposer un faible nombre maximal d’instances.
  7. Activez la mise en cache sur Azure Front Door pour que les pics de trafic soudains soient absorbés au bord plutôt qu’à votre point de départ.
  8. Couvrez votre exposition L3/L4, qui varie selon la plateforme. Voir : La protection DDoS de la plateforme varie selon la plateforme. Verrouillez votre origine pour qu’elle n’accepte que le trafic d’Azure Front Door ou d’Application Gateway.
  9. Activez la journalisation de diagnostic vers Log Analytics, et créez les requêtes dans Analyser WAF et accédez aux journauxavant un incident.

La protection DDoS de la plateforme varie selon la plateforme

Les défenses L7 ne comptent que si les adresses IP publiques sous-jacentes survivent à une attaque volumétrique, et que les deux plateformes WAF Azure ne partent pas du même endroit.

Azure Front Door dispose par défaut d’une protection DDoS de plateforme. Azure Front Door est un service de bord distribué mondialement, et son périphérie est protégée par la protection DDoS de l'infrastructure d'Azure sans frais supplémentaires et sans configuration. Le trafic se termine au bord de la porte d’entrée plutôt qu’à une adresse IP que vous possédez, donc il n’y a pas d’IP publique à cibler par un attaquant en L3/L4. Cette protection est inhérente à la plateforme, donc vous n’achetez ni n’activez quoi que ce soit pour l’obtenir.

Application Gateway nécessite une protection réseau DDoS Azure. Une passerelle d’application est une ressource régionale possédant une adresse IP publique dans votre propre réseau virtuel. La protection par défaut au niveau de l'infrastructure d'Azure protège la plateforme Azure elle-même, mais elle ne fournit pas d'atténuation optimisée par ressource, de télémétrie ou de rapport d'attaque pour cette IP. Pour protéger l'IP publique de la passerelle contre les attaques volumétriques L3/L4, activez la protection réseau DDoS Azure sur le réseau virtuel qui la contient. Il s’agit d’un service payant, acheté séparément.

Conséquences pratiques lors du choix ou de la conception d’un déploiement :

  • Si vous êtes derrière Azure Front Door, prévoyez des contrôles L7 ; la protection périmétrique L3/L4 est déjà en place.
  • Si vous utilisez Application Gateway et que vous n’avez pas activé la protection réseau DDoS, vos règles WAF peuvent être parfaitement réglées et être contournées par une attaque volumétrique sur l’IP publique de la passerelle. Activez-le.
  • Dans tous les cas, les IP publiques d’origine que vous exposez nécessitent toujours une protection réseau DDoS Azure, plus un verrouillage pour que seul le service WAF puisse les atteindre. Une interface protégée devant une origine non protégée et accessible au public ne l’est pas.

Pour plus d’informations, consultez la présentation de la protection DDoS Azure et Protégez votre passerelle d’application avec la protection réseau DDoS Azure.

Protection automatisée avec le système de règles HTTP DDoS (aperçu)

Les contrôles statiques tels que les filtres IP, les géofiltres et les limites de fréquence fixes ne suivent souvent pas le rythme des botnets distribués : les seuils sont des suppositions, ils sont toujours activés, et il faut les réajuster au fur et à mesure que les schémas de trafic évoluent. Le système de règles HTTP DDoS est le premier modèle automatisé de protection de couche 7 d'Azure WAF qui apprend, détecte et défend avec une configuration utilisateur minimale. Il est disponible en aperçu à la fois sur Azure Front Door Premium et Application Gateway WAF v2. Une fois attribué, il établit en continu une référence au trafic normal et, lorsque des pics indiquent une attaque, bloque sélectivement les clients à l’origine de celle-ci sans nécessiter de réglage d’urgence.

Le design est le même sur les deux plateformes dans les aspects qui comptent le plus :

  • Deux seuils, évalués ensemble. L’ensemble de règles apprend à la fois un seuil global (pour chaque profil Front Door ou pour chaque passerelle d’application) et des seuils individuels propres à chaque adresse IP. Les seuils basés sur la propriété intellectuelle ne sont appliqués qu’après que le seuil global a été dépassé. Cette conception empêche le système de règles d’agir sur des pics provenant de quelques adresses IP à moins qu’elles ne poussent réellement le trafic total au-delà de la norme.
  • Défini pour chaque ressource. Les seuils sont acquis au niveau des ressources mondiales. Si vous assignez une politique WAF avec l’ensemble de règles à plusieurs profils Front Door ou plusieurs passerelles, le service calcule séparément les seuils pour chacun.
  • Sensibilité. Chaque règle offre trois niveaux de sensibilité. Une sensibilité plus élevée applique un seuil plus bas ; une sensibilité plus faible applique un seuil plus élevé. Le mode moyen est le réglage par défaut et recommandé.
  • Ordre d’évaluation. Le WAF évalue d’abord le jeu de règles DDoS HTTP, même avant les règles personnalisées. Une règle personnalisée avec une action Allow contourne toutes les autres inspections WAF, mais elle ne contourne pas le système de règles HTTP DDoS.
  • Contournez l'ensemble de règles pour le trafic fiable. Une règle personnalisée avec une action Allow n’aide pas ici – elle contourne tous les autres ensembles de règles mais pas celui de DDoS HTTP. Utilisez plutôt des exceptions WAF , que vous pouvez regrouper dans une règle spécifique, un groupe de règles ou un ensemble de règles géré complet, y compris le système de règles HTTP DDoS. Consultez Exempter le trafic de confiance avec des exceptions.
  • Nécessite un trafic soutenu. Le système de règles ne peut agir qu’une fois qu’il a appris des bases fiables. Si une ressource ne reçoit pas assez de trafic pendant la phase d’apprentissage, le système de règles ne détectera ni ne protégera tant qu’elle ne le fera pas. Voir le tableau de la plateforme pour l’exigence spécifique.

Différences de plateforme

Caractéristique Azure Front Door Premium Application Gateway WAF v2
Phase d’apprentissage Les valeurs de référence sont calculées sur une période glissante ; la détection commence dans un délai de 24 à 36 heures pour les profils ayant reçu du trafic pendant au moins 50 % des sept derniers jours Les références sont apprises pendant au moins 24 heures ; Le système de règles ne détecte ni ne bloque qu’une fois la phase d’apprentissage de 24 heures terminée
Trafic insuffisant Si un profil a reçu du trafic pendant moins de 50% des sept derniers jours, le système de règles ne détectera ni ne bloquera pas tant qu’il n’y aura pas suffisamment de trafic pour des bases fiables Si la passerelle ne reçoit pas assez de trafic pendant la phase d’apprentissage de 24 heures pour établir des bases fiables, le système de règles ne détectera ni ne bloquera les attaques tant qu’il ne le fera pas
Mitigation Les adresses IP contrevenantes sont placées dans une zone de pénalité et bloquées pendant toute la durée de la pénalité Les adresses IP en infraction sont placées dans une boîte de pénalité et bloquées pendant 15 minutes
Identifiants de règles 500100 (taux de demande client), 500110 (bots suspectés) 500100 (taux de demande client), 500110 (bots suspectés)
Métriques supplémentaires Web Application Firewall HTTPDDoSRuleset est actif Taille de la zone de pénalité, Blocs de la zone de pénalité

Règles de configuration

Le jeu de règles contient actuellement deux règles. Chaque règle maintient ses propres lignes de référence de trafic et est configurable avec sa propre sensibilité et action :

Rule Description
500100 : Anomalie détectée à un taux élevé de requêtes clients Établit une base de référence pour l’ensemble du trafic du profil Front Door ou de la passerelle d’application auxquels la politique est associée. Lorsqu’un client dépasse le seuil appris, l’action configurée se déclenche et l’adresse IP en cause est placée dans la boîte de pénalité.
500110 : Bots présumés envoyant des taux élevés de requêtes Maintient des bases de référence séparées, généralement beaucoup plus strictes, pour le trafic classé comme bots par Microsoft Threat Intelligence. Les bots classés comme à haut risque sont immédiatement bloqués dès que le seuil global est franchi.

Zone de pénalité

Les deux plateformes atténuent via une boîte de pénalité. Lorsque le trafic d’un client dépasse le seuil d’une des règles de l’ensemble de règles, cette adresse IP client est placée dans la boîte de pénalité et bloquée par le WAF pendant la durée de la boîte de pénalité, qui est de 15 minutes sur la passerelle d’application. Lorsque la période se termine, l’adresse IP regagne l’accès sauf si elle dépasse à nouveau le seuil, ce qui la renvoie dans la boîte de pénalité.

Cette conception a des conséquences sur la manière dont vous interprétez vos données de télémétrie : seul le déclenchement initial de la règle est consigné. Les requêtes supplémentaires bloquées alors que l’adresse IP est déjà placée dans la « penalty box » ne sont pas consignées dans Front Door ; les décomptes basés sur les journaux sous-estiment donc le nombre de requêtes bloquées. Sur Application Gateway, utilisez la métrique des blocs de la boîte de pénalité pour le nombre réel de blocs et la taille de la boîte de pénalité pour le nombre d’adresses IP actuellement pénalisées.

Surveillance pendant l’aperçu

Lorsqu’une adresse IP dépasse un seuil, une entrée de journal est enregistrée avec l’action Block pour le jeu de règles HTTP DDoS, et la métrique du WAF Managed Rule Match augmente.

  • Front Door: utilisez la métrique Web Application Firewall Request count, filtrée par nom de règle, pour compter les blocages, et la métrique Web Application Firewall HTTPDDoSRuleset Is Active, qui renvoie 1 une fois l’apprentissage terminé et le jeu de règles prêt à agir sur le trafic qui dépasse les seuils appris.
  • Passerelle d’application : chaque requête bloquée suivante provenant d’une adresse IP pénalisée augmente la métrique de correspondance de règles gérées, et les métriques de taille de la boîte de pénalité et des blocs de la boîte de pénalité suivent directement la boîte de pénalité.

Exonérer le trafic de confiance avec des exceptions

Les sondes de santé, la surveillance synthétique, les tests de charge, les intégrations partenaires et les tâches internes par lots génèrent tous un trafic qui ressemble à une inondation mais ne l’est pas. Historiquement, il n’y a aucun moyen de les exempter de l’ensemble de règles DDoS, car une règle Allow personnalisée contourne le jeu de règles par défaut, le jeu de règles de base et la protection des bots, mais évite délibérément de contourner le jeu de règles HTTP DDoS.

Les exceptions WAF comblent cet écart. Une exception contourne l’inspection WAF pour les requêtes correspondant à des attributs spécifiques, portant sur une seule règle, un groupe de règles ou un ensemble de règles géré complet. Vous pouvez appliquer des exceptions au système de règles HTTP DDoS ainsi qu’à DRS, CRS et la protection contre les bots.

Les exceptions correspondent à :

  • Adresse IP distante (Equals ou IP Match), qui est le choix habituel pour exempter les plages connues de surveillance, de test de chargement ou de source partenaire du système de règles DDoS
  • URI de demande
  • Nom et valeur de l’en-tête de requête, avec les critères Égale à, Commence par, Se termine par ou Contient

Conseils pour utiliser les exceptions avec le système de règles DDoS :

  • Limitez le champ d’action aussi étroitement que possible. Je préfère une exception par règle plutôt que d’exempter tout l’ensemble des règles. Une exception large donne à un attaquant un chemin documenté contournant votre mitigation automatisée. Si un générateur de charge n’a besoin que d’une exemption de la règle 500100, ne l’exemptez pas non plus de la règle 500110.
  • Exclure les sources, pas les chemins. Une exception basée sur IP pour un faisceau de test connu est bornée. Une exception basée sur un URI sur un endpoint public est une porte ouverte à quiconque la trouve.
  • Passez-les en revue régulièrement. Des exceptions ajoutées pour un test de charge unique pourraient encore être en vigueur un an plus tard.
  • Fais attention aux limites. Chaque politique WAF supporte jusqu’à 60 exceptions, et chaque Front Door en prend en charge 60 au total sur toutes les polices associées. Une seule exception peut contenir jusqu’à 600 adresses IP, 10 URI ou 10 en-têtes de requête.
  • Les exceptions nécessitent le moteur WAF de nouvelle génération et le système de règles géré DRS 2.1 ou ultérieur.

Utilisez l’outil adapté à la tâche : les exclusions sautent l’inspection d’un élément d’une requête (un cookie ou un en-tête bruyant) tout en inspectant le reste ; les exceptions sautent des règles ou ensembles de règles spécifiques pour les requêtes correspondantes ; une règle de Permis personnalisée contourne tout sauf le système de règles DDoS HTTP.

Important

Les exceptions WAF et le système de règles HTTP DDoS sont en version preview à la fois sur Azure Front Door et Application Gateway WAF v2. Consultez les conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure.

Demandez une vérification avant de bloquer

Le blocage est un outil grossier en cas d’attaque de couche 7 : le trafic d’attaque provient souvent de plages d’adresses IP et de zones géographiques qui comptent aussi des utilisateurs légitimes. Les défis permettent de séparer l'automatisation des humains sans subir les dommages collatéraux d'un blocage total, et ils représentent le plus grand changement dans la façon dont Azure WAF gère les inondations L7 par rapport à une stratégie de limitation de taux uniquement par blocs.

  • Le défi JavaScript est un défi invisible qui ne nécessite aucune interaction humaine. Si le navigateur calcule avec succès le défi, WAF valide le client comme non-bot et continue d’évaluer les règles restantes ; Les requêtes qui échouent sont bloquées. Utilisez-le comme défi par défaut pour le trafic web général. Les requêtes vers le point de terminaison de challenge ne sont pas transférées à votre backend et ne comptent pas pour la limitation de débit.
  • CAPTCHA est un défi interactif qui nécessite la participation des utilisateurs, mieux réservé aux flux à forte valeur ajoutée tels que la connexion, l’inscription et le paiement, où l’abus automatisé coûte cher et où quelques secondes de friction utilisateur sont acceptables. La validité du cookie de challenge est configurable dans les paramètres de politique entre 5 et 1 440 minutes, avec un délai par défaut de 30 minutes. Le CAPTCHA entraîne des frais supplémentaires basés sur l’utilisation.

Planifiez en fonction des limites des deux fonctionnalités avant de les déployer :

  • Les appels AJAX et API ne sont pas pris en charge. Ne posez pas de défis devant les routes API. Utilisez plutôt des règles de limitation de taux et de match.
  • Les défis sont conçus pour les ressources HTML, et non pour les images intégrées, le CSS ou les fichiers JavaScript.
  • Lors de la première requête qui déclenche un défi, le corps POST est limité à 64 Ko sur Azure Front Door et 128 Ko sur Application Gateway.
  • Aucune des deux fonctionnalités ne prend en charge Internet Explorer ; toutes deux prennent en charge les versions actuelles de Microsoft Edge, Chrome, Firefox et Safari.
  • Le défi JavaScript est relancé lorsque l’adresse IP du client change et pour les requêtes d’origine croisée (CORS).
  • Dans Application Gateway, le test JavaScript est en préversion et n’est pas pris en charge pour les règles personnalisées de limitation du débit. Application Gateway for Containers WAF ne le supporte pas.

Limitation de débit de données

Au minimum, créez une règle de limite de débit qui bloque un taux élevé de requêtes provenant d’un seul client. Définissez cette règle comme votre règle de limite de taux de priorité la plus basse (valeur numérique la plus élevée), afin que des règles de limite de taux ou de correspondance plus spécifiques soient évaluées en premier.

Azure Front Door - Service de passerelle réseau de Microsoft

  • Des limites de débit s’appliquent par adresse IP de socket, qui est l’adresse du client qui ouvre la connexion TCP vers Azure Front Door et qui pourrait être un proxy plutôt que l’utilisateur final.
  • Les seuils sont évalués sur une fenêtre fixe d’une ou de cinq minutes. Une fois le seuil franchi, Azure Front Door bloque tout trafic correspondant à la règle pour le reste de la fenêtre. Utilisez la fenêtre de cinq minutes pour la mitigation des inondations HTTP : un attaquant bloqué dans la première minute reste bloqué pendant les quatre minutes restantes.
  • Les fenêtres plus grandes avec le seuil acceptable le plus faible sont la configuration anti-DDoS la plus efficace. Des fenêtres plus grandes et des valeurs de seuil plus élevées imposent également un respect plus strict du seuil configuré. À des seuils très bas (sous environ 200 requêtes par minute), certaines requêtes au-dessus du seuil peuvent passer, car les requêtes d’un client peuvent arriver sur des serveurs Front Door dont les compteurs ne sont pas encore rafraîchis.
  • Les règles de limitation du débit ne prennent en charge que les actions Log et Block ; l’action Allow n’est pas prise en charge.
  • Appliquez une règle à l’ensemble du trafic en faisant correspondre un en-tête Host dont la longueur est supérieure à 0, car chaque requête valide adressée à Azure Front Door en comporte un.

Application Gateway WAF v2

  • La limitation de taux utilise un algorithme de fenêtre glissante . Tout le trafic correspondant est supprimé lors de la première fenêtre où le seuil est franchi. À partir de la deuxième fenêtre, le trafic jusqu’au seuil est autorisé, ce qui produit un effet de bridage plutôt qu’une panne totale pour les clients concernés.

  • Les règles nécessitent une GroupByUserSession, qui contrôle la manière dont les requêtes sont comptabilisées. Cette fonctionnalité vous permet de limiter le débit par autre chose que l’IP du client :

    GroupByVariable Utilisez-le quand
    ClientAddr (valeur par défaut) Cas normal avec des compteurs indépendants par IP source
    ClientAddrXFFHeader Votre passerelle est placée derrière un CDN ou un proxy et l’IP réelle du client est disponible X-Forwarded-For
    GeoLocation Vous voulez limiter le trafic par pays ou région lors d’une inondation géographiquement concentrée
    GeoLocationXFFHeader Comme ci-dessus, en utilisant l’adresse IP dans X-Forwarded-For
    None Un compteur partagé unique pour un modèle correspondant à des critères précis, comme une page de connexion ou une liste d’agents utilisateur suspects

  • Les règles de limitation de taux nécessitent le dernier moteur WAF (sélectionnez CRS 3.2 ou ultérieur pour le jeu de règles par défaut) et ne sont pas prises en charge dans des nuages isolés.

  • La passerelle d’application compte indépendamment les seuils pour chaque terminau auquel la politique est attachée. Une seule politique appliquée à cinq écouteurs maintient cinq ensembles de compteurs.

  • Les seuils ne sont pas appliqués exactement, donc n’utilisez pas la limitation de débit pour un contrôle du trafic en détail. Utilisez-le pour atténuer les taux anormaux et maintenir la disponibilité. Soyez particulièrement prudent avec les règles à correspondance large qui utilisent GeoLocation ou None ; un seuil mal choisi peut provoquer de courtes interruptions fréquentes du trafic légitime.

Fixer des seuils géographiques

Un seuil mondial unique doit être suffisamment généreux pour votre pays le plus occupé, ce qui le rend bien trop généreux ailleurs. La plupart des applications présentent une répartition géographique très déséquilibrée en période de paix : une poignée de pays ou de régions génèrent la quasi-totalité du trafic légitime, tandis que le reste n’en génère qu’une faible quantité. Le trafic d’attaque respecte rarement cette distribution. Des seuils de taille par géographie transforment cette asymétrie à la fois en un signal de détection et en un contrôle d’atténuation.

Commencez par mesurer votre répartition en temps de paix sur au moins une semaine complète, afin que les effets des jours de semaine, du week-end et des fuseaux horaires soient représentés :

  • Sur Azure Front Door, divisez la métrique de comptage de requêtes par la dimension ClientCountry.

  • Dans Log Analytics, dérivez le pays à partir de l’adresse IP client dans le journal d’accès :

    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

Ensuite, regroupez les résultats en paliers et fixez un seuil pour chacun :

Niveau Répartition en temps de paix Traitement recommandé
Marchés principaux Les pays qui produisent la majeure partie de votre trafic Un seuil généreux par client, dimensionné à partir du p99 propre du pays pour que les utilisateurs réels ne soient jamais affectés
Marchés secondaires Un trafic significatif mais modeste Un seuil par client plus strict, mesuré à partir du p99 de ce pays plutôt que du niveau mondial
Géographies à longue queue Un faible volume de trafic légitime Seuil agressif, ou une action de défi au lieu d’un blocage
Des géographies que vous ne servez pas Pratiquement zéro Bloquez directement, ou redirigez vers une page statique

La façon dont vous implémentez les paliers dépend de la plateforme :

  • Application Gateway WAF v2 - utiliser GroupByVariable: GeoLocation (ou GeoLocationXFFHeader derrière un CDN ou proxy) afin que tout le trafic d’une même région partage un compteur, et créer une règle de limite de taux par niveau avec son propre seuil. Étant donné que le dépassement de ce seuil affecte tous les clients de cette zone géographique, définissez ces seuils de manière prudente et validez-les d’abord en mode journalisation : une règle géographique à correspondance étendue mal configurée peut provoquer de brèves interruptions fréquentes du trafic légitime.
  • Azure Front Door - les compteurs sont définis par adresse IP de socket ; créez donc plutôt les niveaux avec des conditions de correspondance géographique : une règle de limitation du débit par niveau, appliquée aux pays concernés, chacun ayant son propre seuil. Chaque client dans une région à longue traîne obtient alors un plafond bien plus bas que celui des clients de vos marchés principaux, sans que le comportement d’un client n’affecte les autres.

Voici quelques pratiques qui permettent de maintenir cela :

  • Classez les règles de la plus spécifique à la moins spécifique : d’abord les règles du marché principal, avec une priorité plus élevée (valeur numérique plus faible), puis les règles du marché secondaire, puis les règles de longue traîne, la règle globale fourre-tout constituant votre règle de limitation du débit de priorité la plus basse.
  • Privilégiez une action de défi à un bloc pour les géographies étendues. Le trafic en provenance d’un pays à faible volume légitime est globalement suspect mais contient tout de même de vrais utilisateurs – voyageurs, utilisateurs de VPN et employés à distance.
  • Mesurez à nouveau après les lancements de campagnes marketing, les expansions régionales et les événements majeurs liés au produit. Une configuration tenant compte de la géographie n’est valable que dans la mesure où la référence sur laquelle son dimensionnement est fondé l’est aussi.
  • Surveillez le signal inverse lors d’un incident : un pays qui contribue normalement à 1% de trafic contribuant soudainement à 40% est l’un des moyens les plus rapides de confirmer que vous assistez à une attaque plutôt qu’à une croissance organique.

Choisissez un seuil parmi votre propre trafic

Utilisez la requête Log Analytics suivante pour dimensionner la règle fourre-tout. Pour Application Gateway, remplacez FrontdoorAccessLog par ApplicationGatewayAccessLog.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

Pour mesurer les seuils par géographie décrits précédemment, ajoutez le pays à la même requête :

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

Fixez le seuil au-dessus du 99e percentile du trafic en temps de paix, pas au maximum. La valeur maximale provient généralement d’un robot d’indexation ou d’un client mal configuré, et se baser sur elle rend la règle trop permissive pour être utile en cas d’attaque.

Règles personnalisées pour une atténuation ciblée

Créer des règles WAF personnalisées pour bloquer ou limiter le débit des attaques HTTP et HTTPS ayant des signatures identifiables, telles qu’un agent utilisateur spécifique, un en-tête, un cookie, un motif de chaîne de requête, un URI, ou une combinaison de ces derniers. Au-delà de la correspondance de chaînes de caractères, les règles personnalisées du WAF d’Azure Front Door peuvent également porter sur :

  • Géolocalisation : Bloquez le trafic en dehors de votre région de service, ou redirigez-le vers une page statique.
  • Les adresses IP du client (CIDR) et les listes de restriction IP pour les adresses et plages que vous avez identifiées comme malveillantes.
  • Numéro AS (ASN) : Réduire les inondations provenant d’un fournisseur d’hébergement ou d’un réseau de transit dont vos utilisateurs légitimes ne proviennent pas, sans énumérer les plages d’IP.
  • Empreinte client (JA4) : Correspondance sur l’empreinte JA4, un hachage dérivé des caractéristiques de handshake TLS et HTTP du client. Parce que les outils d’attaque et les clients botnet produisent une empreinte digitale cohérente quelle que soit l’adresse IP d’où ils envoient, JA4 est l’une des signatures les plus durables disponibles lors d’une attaque distribuée : la rotation entre des milliers d’adresses IP sources ne modifie pas l’empreinte digitale, et le blocage ou la limitation de vitesse de celui-ci élimine tout le botnet avec une seule règle. Vérifiez l’empreinte digitale par rapport à vos journaux d'activité de la période d’observation avant de la mettre en application. Les navigateurs populaires et les SDK courants partagent des empreintes digitales auprès d’un nombre énorme d’utilisateurs légitimes, donc un bloc JA4 non validé peut être extrêmement large. Déployez d’abord l’action Journalisation, confirmez que l’empreinte n’apparaît que dans le trafic d’attaque, puis passez au blocage ou à une règle de limitation de débit.
  • Combinez JA4 avec d’autres conditions pour atténuer chirurgicalement lors d’un incident. Par exemple, limiter le débit plutôt que de bloquer une empreinte JA4 spécifique et un ASN que vous ne servez pas aux utilisateurs, ou une empreinte JA4 et une URI de requête.
  • Balise de service et contraintes de taille des composants de requête.

Deux pratiques qui comptent lors d’un incident :

  • Créez des règles d’autorisation de correspondance pour le trafic légitime connu afin de réduire les faux positifs, et donnez-leur une priorité plus élevée (valeur numérique inférieure) que vos règles de blocage et de limite de débit. N’oubliez pas qu’une règle Allow contourne d’autres inspections WAF mais ne contourne pas le système de règles DDoS HTTP.
  • L’évaluation des règles s’arrête sur toute action sauf Log, et les numéros de priorité doivent être uniques. Réservez un bloc de numéros de faible priorité pour les règles d’urgence afin de pouvoir en insérer un pendant une attaque sans renumérotation.

Les règles gérées ne visent pas la défense DDoS, mais elles protègent contre d’autres attaques courantes et devraient rester activées. Voir Règles gérées (Azure Front Door) ou Règles gérées (Application Gateway).

Protéger l’origine

  • Verrouillez l’accès aux IP publiques sur l’origine et restreignez le trafic entrant afin que seuls Azure Front Door ou Application Gateway puissent y accéder. Suivez les conseils pour sécuriser le trafic vers les origines d’Azure Front Door.
  • Assurez-vous qu’aucune adresse IP publique n’est exposée dans le réseau virtuel de la passerelle d’application.
  • Activez la mise en cache sur Azure Front Door. Les réponses mises en cache absorbent les pics de trafic en périphérie du réseau et réduisent le taux de requêtes qui atteint votre serveur d’origine, ce qui fait souvent la différence entre des performances dégradées et une panne.
  • Faites évoluer vos origines avec une marge. Les mesures automatisées et manuelles prennent du temps à être mises en place ; La capacité disponible comble cet écart.

Réagir à une attaque active

  1. Confirmez que c’est une attaque, pas une croissance organique. Vérifiez les WAF et les journaux d’accès pour détecter un changement soudain du taux de requête, du nombre d’IP des clients, de la répartition géographique, de la distribution des agents utilisateurs et des URI demandés.
  2. Vérifiez ce qui atténue déjà. Confirmez que le système de règles DDoS HTTP est actif et examinez ses blocs par nom de règle. Dans Application Gateway, vérifiez également les métriques Penalty box size et Penalty box blocks, car seul le premier bloc par adresse IP apparaît dans les journaux. Vérifiez les correspondances des règles de limitation de débit.
  3. Compare la composition géographique à ta base de référence. Un pays qui contribue normalement à une petite part du trafic et le domine soudainement est un signal d’attaque rapide et à haute confiance. Il vous indique aussi quel niveau de règles de limite de taux resserrer en premier.
  4. Augmentez la sensibilité avant d’écrire de nouvelles règles. Augmenter la sensibilité aux règles HTTP DDoS ou abaisser un seuil de limite de débit existant est plus rapide et plus sûr que d’élaborer une nouvelle règle sous pression.
  5. Soumettre à une vérification plutôt que bloquer lorsque le trafic est mixte. Appliquez JavaScript challenge aux routes HTML affectées, et CAPTCHA aux flux sensibles.
  6. Écrivez une règle ciblée seulement une fois que vous avez identifié une signature durable : ASN, empreinte du client, combinaison d’en-tête, géographie ou motif URI. Déployez-le d’abord dans l’action de journalisation si le modèle correspond aussi à des utilisateurs réels.
  7. Gardez l’origine protégée pendant le réglage : vérifiez que le cache est activé, confirmez le verrouillage de l’origine, puis procédez à un scale-out.
  8. Après l’incident, redéfinissez vos seuils de limite de taux par rapport aux nouvelles données de trafic et gardez les règles d’urgence qui se sont avérées exactes en mode Journal si vous ne souhaitez pas qu’elles soient appliquées en continu.

Analyser les WAF et les journaux d’accès

Surveillez le trafic à l’aide des journaux WAF Azure pour détecter les anomalies, et utilisez-les pour identifier les adresses IP suspectes qui envoient un nombre exceptionnellement élevé de requêtes, des chaînes d’agents utilisateur inhabituelles ou des schémas de chaînes de requêtes anormales.

Porte d’entrée azur

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Meilleurs intervenants et meilleurs agents utilisateurs sur la fenêtre d’attaque (Azure Front Door montré ; substitut ApplicationGatewayAccessLog à 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

Pour plus d’informations, voir Azure WAF avec Azure Front Door et Azure WAF avec Azure Application Gateway.

Contenu connexe

  • Last updated on