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 capte le trafic, la couche au-dessus ne capte 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é par défaut sur Azure Front Door ; nécessite la protection réseau DDoS Azure pour les IP publiques de la passerelle d’application et les IP publiques d’origine
Atténuation automatisée de la L7 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 limite de taux sur la porte d’entrée et la passerelle d’application
Règles personnalisées ciblées Bloque une signature d’attaque connue lors d’un incident Correspondre aux règles personnalisées (géo, IP, ASN, empreinte client, en-tête, URI)
Protection de l’origine Cela empêche le trafic d’attaque d’atteindre votre calcul Mise en cache, verrouillage de l’origine, auto-scale

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. Assignez le système de règles HTTP DDoS (disponible sur Azure Front Door Premium et Application Gateway WAF v2) afin que l’atténuation automatisée soit apprendre votre base de trafic avant d’en avoir besoin.
  4. Activez le système de règles géré par Bot Manager pour identifier et agir sur les bots connus comme mauvais fonctionnels.
  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 les commandes L7 ; la protection des bords L3/L4 est déjà là.
  • 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 assigné, il établit continuellement une base de départ du trafic normal et, lorsque des surtensions indiquent une attaque, bloque sélectivement les clients incriminés sans qu’aucun réglage d’urgence ne soit nécessaire.

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

  • Deux seuils, évalués ensemble. Le jeu de règles apprend à la fois un seuil global (par profil Front Door ou par passerelle applicative) et des seuils individuels basés sur l’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.
  • Évalué par 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.
  • Contourner le système 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. Voir Trafic de confiance exempté avec 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 bases sont calculées sur une fenêtre mobile ; La détection commence dans les 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 en infraction sont placées dans une boîte de pénalité et bloquées pendant la durée de la boîte 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 boîte de pénalité, Blocages de la boîte 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 des références sur tout le trafic sur le profil Front Door ou la passerelle d’application à laquelle la politique est rattaché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.

La boîte 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é.

Ce design est important pour la façon dont vous lisez votre télémétrie : seule la règle initiale est enregistrée. Les demandes bloquées supplémentaires alors que l’adresse IP est déjà dans la boîte de pénalité ne sont pas enregistrées sur Front Door, donc les comptes basés sur les journaux sous-estiment 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 une action Block pour le jeu de règles HTTP DDoS et les incréments de la métrique WAF Managed Rule Match .

  • Front Door : utilisez la métrique Web Application Firewall Request Count filtrée par nom de règle pour compter les blocs, et la métrique Web Application Firewall HTTPDDoSRuleset Is Active, qui rapporte 1 une fois l’apprentissage terminé et le système de règles prêt à agir sur le trafic dépassant 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 sur :

  • 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
  • Demande le nom et la valeur de l’en-tête, correspondant à Égal, Commence avec, Termine avec, 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.
  • Sources exemptées, pas 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.
  • Examinez-les selon un planning. 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.

Défie avant de bloquer

Le blocage est un instrument contondant lors d’une attaque L7 : le trafic d’attaque arrive fréquemment depuis des adresses IP et des géographies qui transportent également de réels utilisateurs. 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 réédité lorsque l’adresse IP d’un client change et pour les requêtes cross-origin (CORS).
  • Sur Application Gateway, le défi JavaScript est en aperçu et n’est pas pris en charge par les règles personnalisées à limite de vitesse. 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 s’approchent également 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 limite de taux ne supportent que les actions de journal et de blocage ; Le permis n’est pas pris en charge.
  • Appliquez une règle à tout le trafic en faisant correspondre sur un Host en-tête de longueur supérieure à 0, car chaque requête valide à Azure Front Door en a une.

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 seconde fenêtre, le trafic jusqu’au seuil est autorisé, produisant un effet de limitation plutôt qu’une panne totale pour les clients correspondants.

  • 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 seul compteur partagé pour un motif étroitement correspondant, comme une page de connexion ou une liste d’agents utilisateurs 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 sur cinq auditeurs maintient cinq jeux 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é. Faites preuve de prudence particulière avec des règles de correspondance large qui utilisent GeoLocation ou None; un seuil mal choisi peut provoquer des coupures courtes fréquentes pour le trafic réel.

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 ont un profil géographique fortement biaisé en temps de paix – une poignée de pays ou de régions produisent presque tout le trafic légitime, et le reste produit un filet. 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 filet 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. Parce qu’une violation agit contre chaque client dans cette région, mesurez ces seuils de manière conservatrice et validez-les d’abord dans l’action Journal : une règle géologique de correspondance large mal configurée peut provoquer de courtes coupures fréquentes pour le trafic légitime.
  • Azure Front Door - les compteurs sont par adresse IP de socket, donc construisez les niveaux avec des conditions de géo-correspondance : une règle de limite de taux par niveau, appariée selon les pays concernés, chacun avec 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 du plus spécifique au moins : règles du marché primaire à priorité plus élevée (valeur numérique plus faible), puis secondaire, puis longue queue, avec la règle globale de fourre-tout comme limite de priorité minimale.
  • Je préfère une action de défi plutôt qu’un bloc pour les géographies à longue queue. 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.
  • Remesurez après les lancements marketing, les expansions régionales et les grands événements produits. Une configuration géographique n’est aussi bonne que la base de la taille à partir de laquelle elle a été dimensionnée.
  • 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 déterminer la règle générale. 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. Le maximum est généralement un crawler ou un client mal configuré, et la taille de celui-ci rend la règle trop généreuse pour aider lors d’une 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 l’appariement de chaînes, les règles personnalisées WAF d’Azure Front Door peuvent faire correspondre 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 avec vos journaux de paix avant de l’appliquer. 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éploie d’abord l’action Journal , confirme que l’empreinte digitale n’apparaît que dans le trafic d’attaque, puis passe à Bloc ou à une règle de limite 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.
  • Contraintes de service et de taille sur les 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 en cache absorbent le volume maximal au bord et réduisent le taux de requête qui atteint votre point d’origine, ce qui fait souvent la différence entre une performance dégradée et une panne.
  • L’échelle commence avec la marge de jeu. 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. Sur Application Gateway, vérifiez également la taille de la case de pénalité et les métriques de blocs de la boîte de pénalité , car seul le premier bloc par adresse IP apparaît dans les journaux. Examinez les règles de la limite de taux.
  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. Défier plutôt que bloquer là où la circulation est mélangée. 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 Journal si le motif correspond aussi aux utilisateurs réels.
  7. Gardez l’origine protégée pendant que vous réglez : vérifiez que la cache est activée, confirmez le verrouillage de l’origine, puis réduisez l’échelle.
  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