NGINX App Protect Denial of Service bloque les attaques DoS au niveau applicatif

NGINX | 06 juillet 2021

Si la transformation numérique accélère le développement du potentiel des entreprises, elle élargit malheureusement aussi la surface d’attaque. Alors que les équipes de sécurité s’efforcent de s’adapter à l’élargissement de leur périmètre et à l’accroissement de leurs responsabilités, les attaquants en profitent et emploient des méthodes toujours plus sophistiquées pour exploiter les applications à des fins lucratives. Par rapport aux attaques par déni de service (DoS) traditionnelles au niveau du réseau, les attaques DoS au niveau applicatif (couche 7) connaissent une forte hausse, en grande partie parce qu’elles peuvent contourner les défenses traditionnelles, qui ne sont pas conçues pour les architectures applicatives modernes.

Du point de vue des attaquants, les attaques DoS de couche 7 présentent deux caractéristiques intéressantes : elles nécessitent très peu de ressources pour provoquer des perturbations importantes et sont difficiles à détecter. Générées à l’aide d’outils sophistiqués et de requêtes ciblées avec précision, ces attaques perturbent les serveurs d’applications et les API en les empêchant de traiter les requêtes légitimes. Lorsqu’un serveur est submergé par un nombre de requêtes supérieur à sa capacité de traitement, il rejette les requêtes légitimes, cesse de répondre, voire tombe en panne.

Les solutions traditionnelles d’atténuation des attaques DoS ne sont pas efficaces pour les applications modernes. Elles offrent une sécurité statique basée sur des règles et nécessitent une maintenance continue pour suivre le rythme des changements et des mises à jour dans le paysage applicatif moderne.

Présentation de NGINX App Protect DoS

NGINX App Protect Denial of Service (DoS) est un nouveau module dynamique léger pour NGINX Plus, conçu pour protéger les applications modernes contre les attaques DoS applicatives les plus sophistiquées. NGINX App Protect DoS atténue les attaques visant à perturber et à endommager les applications, garantissant ainsi la continuité des performances et de la génération de revenus, tout en préservant la fidélité des clients et l’image de marque dans un monde numérique hautement concurrentiel.

NGINX App Protect DoS peut être déployé à proximité des applications et des microservices sur n’importe quelle plateforme ou architecture et dans n’importe quel environnement, y compris les clusters Kubernetes. Il évolue horizontalement avec l’application et garantit en permanence une sécurité hautement efficace.

NGINX App Protect DoS en action

Cas d’usage de déploiement

NGINX App Protect DoS peut être déployé à différents emplacements afin de protéger les services applicatifs :

  • Périphérie – Équilibreurs de charge externes et proxys
  • Contrôleur d’entrée – Point d’entrée dans Kubernetes
  • Proxy par service – Couche de proxy pour les services internes
  • Proxy par pod – Proxy intégré au pod
  • Passerelle API – Point d’entrée vers les microservices

Types d’attaques atténuées

NGINX App Protect DoS offre une protection contre plusieurs types d’attaques sophistiquées :

  • GET et POST attaques par saturation – (HTTP et HTTPS) L’attaquant tente de submerger le serveur ou l’API avec un grand nombre de requêtes, l’empêchant ainsi de répondre aux utilisateurs légitimes.
  • Attaques « lentes » – (HTTP et HTTPS) Les attaques « lentes et à faible débit » monopolisent les ressources du serveur, qui ne peut alors plus traiter les requêtes des utilisateurs légitimes. Deux facteurs les rendent difficiles à contrer : il existe trois principaux types d’attaques lentes :
    • Contrairement aux attaques DDoS réseau, elles ne consomment pas beaucoup de bande passante, ce qui les rend difficiles à distinguer du trafic normal.
    • Leur lancement nécessite peu de ressources, si bien que des milliers de requêtes peuvent être envoyées depuis un seul ordinateur à l’aide d’outils d’automatisation sophistiqués.
    • Slowloris – L’attaquant se connecte au serveur et envoie lentement des en-têtes de requête partiels. Le serveur maintient la connexion ouverte dans l’attente du reste des en-têtes, épuisant ainsi le pool de connexions disponibles pour les utilisateurs légitimes.
    • Lecture lente – L’attaquant envoie une requête HTTP correctement formée, mais lit ensuite la réponse très lentement, voire pas du tout. Cela a pour effet cumulatif de mobiliser les ressources du serveur, empêchant ainsi le traitement des requêtes légitimes.
    • Attaque lente par requête « POST » – L’attaquant envoie au serveur des en-têtes HTTP POST légitimes, en indiquant correctement la taille du corps du message qui suivra. Il envoie ensuite le corps du message très lentement. Comme le message semble valide, le serveur maintient la connexion ouverte en attendant de recevoir le corps complet. Un grand nombre d’attaques lentes par requête « POST » épuisent le pool de connexions disponibles pour les utilisateurs légitimes.
  • Variantes distribuées des attaques précédentes – De toute évidence, le recours à plusieurs ordinateurs permet de lancer facilement un plus grand nombre d’attaques simultanées. En outre, le volume de trafic provenant de chaque ordinateur peut être relativement faible, ce qui le fait ressembler à celui d’un utilisateur ordinaire. Les ordinateurs peuvent également quitter le groupe participant à l’attaque, puis le rejoindre à nouveau, entraînant une variation constante de l’ensemble des adresses IP sources. Ces caractéristiques du trafic réduisent l’efficacité des techniques d’atténuation traditionnelles telles que la limitation du débit et le blocage géographique.
  • Attaque Challenge Collapsar/URI aléatoires – Lors d’une attaque Challenge Collapsar (CC), l’attaquant envoie fréquemment des requêtes qui semblent normales, à ceci près que les URI demandés nécessitent l’exécution d’algorithmes complexes, et donc chronophages, ou d’opérations de base de données susceptibles d’épuiser les ressources du serveur ciblé. L’attaquant peut également générer aléatoirement les URI et d’autres paramètres HTTP afin de contourner les outils de protection traditionnels tels que les règles statiques. NGINX App Protect DoS s’appuie plutôt sur des algorithmes avancés d’apprentissage automatique qui améliorent considérablement l’efficacité et réduisent les faux positifs.

​

  • Dissimulation derrière un NAT – L’attaquant utilise le chiffrement ou la traduction d’adresses réseau (NAT) pour échapper à la détection. Tenter de détecter les attaques en suivant uniquement l’adresse IP source est inefficace, car tous les utilisateurs du NAT sont alors considérés comme des attaquants, même si un seul utilisateur mène une attaque. NGINX App Protect DoS utilise la prise d’empreinte pour IPv4 afin de détecter avec précision les acteurs malveillants derrière un NAT. Comme la majeure partie du trafic est chiffrée à l’aide de SSL/TLS, il est possible d’étendre la clé qui identifie un acteur en passant de la seule adresse IP à la combinaison de l’adresse IP et de l’empreinte TLS (cette empreinte étant basée sur le message TLS Hello).
  • Attaques SSL/TLS ciblées – L’attaquant exploite le protocole de négociation SSL/TLS. Une méthode courante consiste à envoyer des données incohérentes au serveur SSL/TLS ciblé. Le traitement d’un message non valide est tout aussi coûteux en ressources que celui d’un message légitime, mais sans résultat utile. La plupart des pare-feu ne sont d’aucune aide dans ce cas, car ils ne peuvent pas distinguer les paquets de négociation SSL/TLS valides des paquets non valides, et la mise en œuvre du déchiffrement sur un pare-feu est trop coûteuse. NGINX App Protect DoS utilise un mécanisme de signatures SSL/TLS pour assurer une détection et une atténuation fondées sur les anomalies à partir du message CLIENT HELLO, qui n’est pas chiffré et qui est transmis au début du processus de négociation SSL/TLS, ce qui évite le coût élevé du déchiffrement. En outre, l’utilisation de signatures SSL/TLS conjointement avec un mécanisme de surveillance de l’état du serveur permet d’assurer la protection contre les attaques DoS et leur atténuation sans terminaison SSL/TLS.

Résumé

Les attaques DoS ciblent de plus en plus souvent les applications plutôt que le réseau. Comme bon nombre de ces attaques DoS de couche 7 ressemblent à du trafic légitime, les protections WAF traditionnelles ne peuvent pas les détecter efficacement.

De plus, les attaquants continuent d’exploiter de nouvelles technologies telles que l’apprentissage automatique et l’IA pour lancer des attaques DoS de couche 7, ce qui réduit l’efficacité des règles simples et des signatures statiques. Les mesures d’atténuation des attaques DoS de couche 7 doivent elles aussi évoluer, et NGINX App Protect DoS met en œuvre la technologie adéquate grâce à des défenses adaptatives et dynamiques.

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 :

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.


Partager

À propos de l’auteur

Yaniv Sazman
Yaniv SazmanResponsable senior de la gestion de produits

Autres articles de Yaniv Sazman

Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
NGINX | 13/10/2025

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 ?
NGINX | 03/11/2023

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
NGINX | 11/03/2020

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
NGINX | 11/06/2019

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
NGINX | 24/01/2017

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
NGINX | 19/05/2015

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.