À mesure que nous transférons en ligne toujours plus d’aspects de notre vie quotidienne, les cyberattaquants redoublent eux aussi d’efforts pour dégrader le niveau de service fourni par les applications dont nous dépendons. Leurs motivations sont multiples : se venger, influencer le cours de l’action des entreprises touchées ou encore créer un écran de fumée afin de détourner l’attention des équipes de sécurité pendant une violation de données.
Dans un précédent article de blog, nous expliquons comment, par le passé, les équipes de sécurité devaient sans cesse développer de nouvelles défenses contre les attaques volumétriques par déni de service (DoS) et par déni de service distribué (DDoS) au niveau du réseau et du transport (couches 3 et 4), qui saturent la bande passante disponible des serveurs en les inondant de demandes de connexion TCP/UDP. Les attaquants ont désormais ajouté un nouvel outil à leur arsenal : les attaques DoS et DDoS qui utilisent des requêtes HTTP ou des appels d’API pour épuiser les ressources au niveau applicatif (couche 7).
Les protections DoS traditionnelles contre les attaques réseau et volumétriques ne sont pas efficaces contre les attaques de couche 7, car, au niveau applicatif, les requêtes malveillantes ressemblent souvent aux requêtes légitimes. En outre, les attaques HTTP de couche 7 peuvent causer des dommages avec un débit et un volume de requêtes bien inférieurs à ceux des attaques au niveau du réseau. La protection DoS de couche 7 doit être plus sensible pour répondre à un tout nouvel ensemble d’exigences :
- Distinguer les attaques des schémas de trafic habituels
- Évaluation de l’état des serveurs sous charge
- Déterminer quand une attaque a commencé et si elle est terminée
- Atténuer les attaques sans affecter les utilisateurs légitimes
- Déterminer si les changements de comportement de l’application sont dus à une attaque ou à des mises à jour de ses fonctionnalités
- Résister à une attaque prolongée sans perte d’efficacité de la détection
NGINX App Protect contre les attaques par déni de service (DoS) répond à tous ces défis afin d’assurer une protection contre les attaques zero-day qui soit rationalisée, facile à mettre en œuvre et dotée d’une configuration adaptative et automatisée des politiques.
Comment NGINX App Protect DoS s’adapte pour bloquer automatiquement les attaques
NGINX App Protect DoS utilise un processus en plusieurs étapes pour détecter et atténuer les attaques DoS de couche 7 :
- Capturer le comportement habituel dans un modèle statistique du site
- Vérifier l’état du service
- Détecter une anomalie
- Identifier les acteurs malveillants et les schémas de requêtes
- Atténuez l’attaque grâce à une défense multicouche
Capturer le comportement typique dans un modèle statistique de site
La première étape du processus consiste à observer le comportement des utilisateurs et de l’application pendant une période où nous savons que le site ne subit aucune attaque, afin de créer un modèle statistique du site qui établit une référence des comportements habituels. NGINX App Protect DoS suit 320 métriques relatives aux utilisateurs et à l’application afin de fournir une vue complète du déploiement de votre application. Il met également à jour dynamiquement le modèle statistique du site à mesure qu’il observe le trafic. Vous n’avez ainsi plus besoin d’ajuster manuellement les seuils du système, tout en ayant la garantie que NGINX App Protect DoS tient compte des changements de comportement du trafic qui surviennent inévitablement au fil du temps.
Une catégorie de métriques suivies concerne les caractéristiques des requêtes HTTP : la méthode HTTP, la valeur de l’en-tête User-Agent et d’autres comme celles présentées dans le graphique.

Vérification de l’état du service
De nombreux outils d’atténuation des attaques DoS de couche 7 s’intéressent uniquement aux schémas de trafic des clients. Pour améliorer la détection des attaques, vous pouvez également configurer NGINX App Protect DoS afin qu’il vérifie activement l’état du service. Il surveille plusieurs indicateurs de performance du serveur, tels que le temps de réponse et la proportion de requêtes abandonnées. La dégradation de ces indicateurs signale qu’une application est « sous pression », peut-être en raison d’une attaque. Le suivi des indicateurs du serveur présente un autre avantage : une fois que NGINX App Protect DoS a déterminé qu’une attaque est en cours, le schéma des réponses aux contrôles d’état permet d’identifier le moment où l’attaque a commencé.
Détection d’une anomalie
Lorsque NGINX App Protect DoS détermine qu’une attaque est en cours – en se fondant sur les écarts par rapport au modèle statistique du site et sur les changements dans la réponse du serveur (si cette option est configurée) –, il cesse de mettre à jour le modèle statistique du site et analyse plutôt les différences entre les valeurs actuelles des métriques et les valeurs de référence établies. Ces différences indiquent probablement une anomalie globale.
Identification des acteurs malveillants et des modèles de requêtes
NGINX App Protect DoS lance ensuite deux procédures qui s’exécutent en parallèle :
- Analyse du comportement de chaque utilisateur afin de déterminer qui a créé l’anomalie ou y a contribué. NGINX App Protect considère initialement tous les utilisateurs comme suspects et analyse leur comportement. Il est peu probable que chaque utilisateur soit un attaquant, mais l’évaluation du comportement de chacun permet à NGINX App Protect d’établir un profil statistique indiquant qui a contribué ou non à l’attaque. Les acteurs malveillants détectés sont identifiés à l’aide de leur adresse IP ou de l’en-tête «
X-Forwarded-For» de leurs requêtes. - Génération d’une liste de règles décrivant le trafic d’attaque sans bloquer les utilisateurs légitimes – des signatures en temps réel pour se protéger contre les attaques zero-day. Les signatures générées lors d’attaques précédentes peuvent être réutilisées. Les signatures générées identifient les attributs HTTP associés à l’attaque, comme dans cet exemple :
http.request.method eq GET and http.user_agent contains Chrome and http.uri_parameters eq 6 and http.accept_header_exists eq false and
http.headers_count eq 7Atténuer l’attaque grâce à une défense multicouche
L’objectif principal de la défense contre une attaque de couche 7 est de la détecter avant qu’elle ne puisse causer le moindre dommage.
Comme illustré dans le schéma suivant, vous pouvez configurer une stratégie d’atténuation prudente ou standard. Dans les deux cas, la première couche de défense consiste à bloquer les requêtes provenant des acteurs malveillants qui ont été identifiés à l’étape précédente par leur adresse IP et l’en-tête « X-Forwarded-For ». La couche de défense suivante bloque les requêtes qui correspondent aux signatures générées à l’étape précédente.
Enfin, si vous avez configuré une stratégie d’atténuation standard et que NGINX App Protect DoS constate que les deux premières couches de défense sont insuffisantes, il applique une limitation globale du débit pendant une courte période.

Réduire les faux positifs lors de l’atténuation des attaques
Lorsque NGINX App Protect DoS applique une limitation globale du débit, il est possible que les requêtes d’utilisateurs légitimes soient bloquées, ce qui constitue un faux positif. NGINX App Protect DoS peut réduire les faux positifs en s’appuyant sur le fait qu’une attaque DoS classique est lancée à l’aide de scripts exécutés par un contrôleur de botnet (un logiciel malveillant installé sur des ordinateurs infectés), et non directement par des humains. Contrairement aux navigateurs Web, bon nombre de ces scripts simples ne peuvent pas gérer correctement une redirection HTTP, et encore moins exécuter du code JavaScript. Ces différences de capacités entre les scripts et les navigateurs permettent à NGINX App Protect DoS de déterminer lequel des deux génère le trafic suspect.
Ainsi, au lieu de limiter le débit des requêtes provenant de tous les clients, NGINX App Protect DoS envoie d’abord une redirection HTTP, puis un extrait de code JavaScript à exécuter. Les bots utilisant des scripts ne peuvent pas répondre correctement, contrairement aux navigateurs. NGINX App Protect DoS peut ainsi bloquer le trafic provenant de scripts tout en autorisant celui des navigateurs.
Nous sommes conscients que certains utilisateurs hésitent à s’appuyer sur l’apprentissage adaptatif en raison du risque élevé de faux positifs, mais nous avons constaté qu’il s’agit du moyen le plus efficace d’atténuer les attaques DoS de couche 7. NGINX App Protect DoS réduit les faux positifs en combinant plusieurs approches : analyse du comportement des utilisateurs, vérification de l’état des services et mesure de l’efficacité des techniques d’atténuation. Ensemble, ces trois approches offrent une visibilité et une protection complètes, sans qu’il soit nécessaire de modifier manuellement la configuration en réponse aux attaques.

Pourquoi une protection contre les attaques DoS de couche 7 si je dispose déjà d’un WAF ?
Vous vous demandez peut-être pourquoi vous avez besoin d’une protection contre les attaques DoS de couche 7 si votre WAF vous protège déjà contre les bots. S’il est vrai que les attaques DDoS de couche 7 sont généralement lancées par des bots, leur objectif diffère de celui des autres activités automatisées. Les bots cherchent généralement à récupérer des informations sans perturber le service, alors que l’interruption du service est précisément le but des attaques DoS et DDoS de couche 7.
Une autre différence réside dans le fait que les outils anti-bots standard tentent de distinguer les « bons bots » des « mauvais bots », une tâche complexe qui nécessite généralement une supervision humaine afin d’éviter les faux positifs. NGINX App Protect DoS, en revanche, ne se préoccupe pas de savoir si le trafic est généré par des bots ou par un autre mécanisme : il s’attache à distinguer les attaquants des utilisateurs légitimes en fonction de leur comportement. Comme NGINX App Protect DoS n’utilise des techniques anti-bots que lorsqu’il a déterminé que les bots participent à une attaque DoS de couche 7, il génère nettement moins de faux positifs que les logiciels anti-bots standard. En outre, les méthodes d’atténuation de NGINX App Protect DoS utilisent efficacement les ressources du processeur, ce qui lui permet de continuer à protéger vos applications pendant toute la durée d’une attaque DoS de couche 7.
Conclusion
NGINX App Protect DoS suit plus de 320 métriques liées au comportement des utilisateurs et des applications, afin d’établir un modèle statistique multifactoriel offrant la protection la plus précise possible. Ses algorithmes uniques réduisent considérablement les faux positifs. Grâce à ces fonctionnalités, NGINX App Protect DoS peut atténuer les attaques DoS fortement distribuées, dans lesquelles chaque requête malveillante semble parfaitement légitime et où un attaquant isolé peut même générer moins de trafic qu’un utilisateur légitime moyen. Grâce à sa technologie adaptative, NGINX App Protect DoS protège les infrastructures modernes non seulement contre les attaques actuelles, mais aussi contre celles qui apparaîtront à l’avenir.
Pour en savoir plus sur la mise en place d’une protection contre les attaques DoS, consultez notre présentation de la solution. Consultez également ces articles de blog connexes :
- Protéger les applications contre les attaques modernes et complexes
- NGINX App Protect Denial of Service bloque les attaques DoS au niveau applicatif
Essayez NGINX App Protect DoS par vous-même : commencez un essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.
À propos de l’auteur
Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.