Sécurisez vos applications gRPC contre les attaques DoS graves avec NGINX App Protect DoS

La demande des clients en biens et services au cours des deux dernières années a souligné à quel point il est crucial pour les organisations d’évoluer facilement et d’innover plus rapidement, ce qui a conduit nombre d’entre elles à accélérer le passage d’une architecture monolithique à une architecture cloud native. Selon le récent rapport F5, The State of Application Strategy 2021 , le nombre d'organisations modernisant applications a augmenté de 133 % au cours de la seule année dernière. Les applications compatibles avec le cloud sont conçues pour être modulaires, distribuées, déployées et gérées de manière automatisée. Bien qu'il soit possible de simplement soulever et déplacer une application monolithique existante, cela n'apporte aucun avantage en termes de coûts ou de flexibilité. La meilleure façon de bénéficier du modèle distribué offert par les services de cloud computing est de penser de manière modulaire : c’est là qu’interviennent les microservices .

Les microservices sont une approche architecturale qui permet aux développeurs de créer une application sous la forme d'un ensemble de services application légers, structurellement indépendants les uns des autres et de la plate-forme sous-jacente. Chaque microservice s’exécute comme un processus unique et communique avec d’autres services via des API bien définies et standardisées. Chaque service peut être développé et déployé par une petite équipe indépendante. Cette flexibilité offre aux organisations de plus grands avantages en termes de performances, de coûts, d’évolutivité et de capacité à innover rapidement.

Les développeurs sont toujours à la recherche de moyens d’augmenter l’efficacité et d’accélérer le déploiement des application . Les API permettent la communication entre logiciels et fournissent les éléments de base du développement. Pour demander des données aux serveurs via HTTP , les développeurs Web utilisaient à l'origine SOAP , qui envoie les détails de la demande dans un document XML . Cependant, les documents XML ont tendance à être volumineux, nécessitent une charge importante et prennent beaucoup de temps à développer.

De nombreux développeurs sont depuis passés à REST , un style architectural et un ensemble de directives pour la création d'API Web fiables et sans état. Une API Web qui obéit à ces directives est appelée RESTful. Les API Web RESTful sont généralement basées sur des méthodes HTTP pour accéder aux ressources via des paramètres codés par URL et utilisent JSON ou XML pour transmettre des données. Grâce à l’utilisation d’API RESTful, les applications sont plus rapides à développer et entraînent moins de frais généraux.

Les progrès technologiques offrent de nouvelles opportunités pour faire progresser la conception des application . En 2015, Google a développé Google Remote Procedure Call ( gRPC ) en tant que framework RPC open source moderne qui peut fonctionner dans n'importe quel environnement. Alors que REST est basé sur le protocole HTTP 1.1 et utilise un modèle de communication demande-réponse, gRPC utilise HTTP/2 pour le transport et un modèle de communication client-réponse, implémenté dans des tampons de protocole (protobuf) comme langage de description d'interface (IDL) utilisé pour décrire les services et les données. Protobuf est utilisé pour sérialiser des données structurées et est conçu pour la simplicité et les performances. gRPC est environ 7 fois plus rapide que REST lors de la réception de données et 10 fois plus rapide lors de l'envoi de données, en raison de l'efficacité de protobuf et de l'utilisation de HTTP/2. gRPC permet également la communication en streaming et traite plusieurs requêtes simultanément.

Les développeurs trouvent que la création de microservices avec gRPC est une alternative intéressante à l'utilisation d'API RESTful en raison de sa faible latence, de la prise en charge de plusieurs langues, de la représentation compacte des données et du streaming en temps réel, qui le rendent particulièrement adapté à la communication entre microservices et sur des réseaux à faible consommation d'énergie et à faible bande passante. gRPC a gagné en popularité car il facilite la création rapide et efficace de nouveaux services, avec une plus grande fiabilité et évolutivité, et avec une indépendance linguistique pour les clients et les serveurs.

Bien que la nature ouverte du protocole gRPC offre plusieurs avantages positifs, la norme n'offre aucune protection contre l'impact qu'une attaque DoS peut avoir sur une application. Une application gRPC peut toujours souffrir des mêmes types d’attaques DoS qu’une application traditionnelle.

Pourquoi identifier une attaque DoS sur une application gRPC est difficile

Si les microservices et les conteneurs offrent aux développeurs plus de liberté et d’autonomie pour proposer rapidement de nouvelles fonctionnalités aux clients, ils introduisent également de nouvelles vulnérabilités et opportunités d’exploitation. Un type de cyberattaque qui a gagné en popularité est celui des attaques par déni de service (DoS) , qui ont été responsables ces dernières années d’un nombre croissant de vulnérabilités et d’expositions courantes (CVE), dont beaucoup sont causées par une mauvaise gestion des requêtes gRPC. Les attaques DoS de couche 7 sur les applications et les API ont augmenté de 20 % ces dernières années, tandis que l'ampleur et la gravité de l'impact ont augmenté de près de 200 %.

Une attaque DoS envoie généralement de grandes quantités de trafic qui semblent légitimes, pour épuiser les ressources de l’application et la rendre insensible. Lors d'une attaque DoS typique, un mauvais acteur inonde un site Web ou une application avec tellement de trafic que les serveurs sont submergés par toutes les requêtes, ce qui les fait bloquer ou même planter. Les attaques DoS sont conçues pour ralentir ou désactiver complètement les machines ou les réseaux, les rendant inaccessibles aux personnes qui en ont besoin. Tant que l’attaque n’est pas atténuée, les services qui dépendent de la machine ou du réseau – tels que les sites de commerce électronique, la messagerie électronique et les comptes en ligne – sont inutilisables.

De plus en plus, nous constatons de plus en plus d’attaques DoS utilisant des requêtes HTTP et HTTP/2 ou des appels API pour attaquer la couche application (couche 7), en grande partie parce que les attaques de couche 7 peuvent contourner les défenses traditionnelles qui ne sont pas conçues pour défendre les architectures application modernes. Pourquoi les attaquants sont-ils passés des attaques volumétriques traditionnelles au niveau des couches réseau (couches 3 et 4) aux attaques au niveau de la couche 7 ? Ils suivent le chemin de moindre résistance. Les ingénieurs en infrastructure ont passé des années à créer des mécanismes de défense efficaces contre les attaques de couche 3 et de couche 4, les rendant plus faciles à bloquer et moins susceptibles de réussir. Cela rend ces attaques plus coûteuses à lancer, en termes d’argent et de temps, et les attaquants sont donc passés à autre chose.

La détection des attaques DoS sur les applications gRPC est extrêmement difficile, en particulier dans les environnements modernes où la mise à l'échelle est effectuée automatiquement. Un service gRPC peut ne pas être conçu pour gérer un trafic à volume élevé, ce qui en fait une cible facile à éliminer pour les attaquants. Les services gRPC sont également vulnérables aux attaques par inondation HTTP/2 avec des outils tels que h2load . De plus, les services gRPC peuvent facilement être ciblés lorsque l’attaquant exploite des définitions de données correctement déclarées dans une spécification protobuf.

Une mauvaise utilisation typique, bien qu'involontaire, d'un service gRPC se produit lorsqu'un bogue dans un script l'amène à produire des requêtes excessives au service. Par exemple, supposons qu’un script d’automatisation émette un appel d’API lorsqu’une certaine condition se produit, ce que les concepteurs s’attendent à voir se produire toutes les deux secondes. Cependant, en raison d'une erreur dans la définition de la condition, le script émet l'appel toutes les deux millisecondes, créant une charge inattendue sur le service gRPC backend.

D'autres exemples d'attaques DoS sur une application gRPC incluent :

• L'insertion d'un champ malveillant dans un message gRPC peut entraîner l'échec de l' application .
• Une attaque POST lente envoie des requêtes partielles dans l'en-tête gRPC. Anticipant l'arrivée du reste de la requête, l' application ou le serveur maintient la connexion ouverte. Le pool de connexions simultanées peut devenir plein, ce qui entraîne le rejet de tentatives de connexion supplémentaires de la part des clients.
• Une inondation de paramètres HTTP/2 ( CVE-2019-9515 ) , dans laquelle l'attaquant envoie des trames SETTING vides au protocole gRPC, consomme des ressources NGINX, le rendant incapable de répondre à de nouvelles requêtes.

Exploitez la puissance de l'analyse dynamique du comportement des utilisateurs et des sites pour atténuer les attaques DoS gRPC avec NGINX App Protect DoS

La sécurisation des applications contre les attaques DoS d’aujourd’hui nécessite une approche moderne. Pour protéger des applications complexes et adaptatives, vous avez besoin d'une solution qui offre une protection dynamique et très précise basée sur le comportement des utilisateurs et du site et qui allège la charge des équipes de sécurité tout en prenant en charge le développement rapide des application et avantage compétitif.

F5 NGINX App Protect DoS est un module logiciel léger pour NGINX Plus, basé sur le WAF et la protection comportementale leaders du marché de F5. Conçu pour se défendre contre les attaques DoS de couche 7 les plus sophistiquées, NGINX App Protect DoS utilise des algorithmes uniques pour créer un modèle statistique dynamique qui fournit un apprentissage automatique adaptatif et une protection automatisée. Il mesure en permanence l’efficacité de l’atténuation et s’adapte aux changements de comportement des utilisateurs et du site et effectue des contrôles proactifs de l’état du serveur. Pour plus de détails, consultez Comment NGINX App Protect Denial of Service s'adapte à l'évolution du paysage des attaques sur notre blog.

L'analyse comportementale est fournie pour les applications HTTP traditionnelles et les en-têtes d'applications HTTP/2 modernes. NGINX App Protect DoS atténue les attaques basées à la fois sur les signatures et sur l'identification des mauvais acteurs. Dans la phase initiale d’atténuation des signatures, NGINX App Protect DoS profile les attributs associés à un comportement anormal pour créer des signatures dynamiques qui bloquent ensuite les requêtes correspondant à ce comportement à l’avenir. Si l’attaque persiste, NGINX App Protect DoS passe à la phase d’atténuation des acteurs malveillants.

Sur la base de la détection d'anomalies statistiques, NGINX App Protect DoS identifie avec succès les mauvais acteurs par adresse IP source et empreintes digitales TLS, lui permettant de générer et de déployer des signatures dynamiques qui identifient et atténuent automatiquement ces modèles spécifiques de trafic d'attaque. Cette approche est différente des solutions DoS traditionnelles du marché qui détectent lorsqu’un seuil volumétrique est dépassé. NGINX App Protect DoS peut bloquer les attaques où les demandes semblent tout à fait légitimes et chaque attaquant peut même générer moins de trafic que l'utilisateur légitime moyen.

Les tableaux de bord Kibana suivants montrent comment NGINX App Protect DoS détecte et atténue rapidement et automatiquement une attaque DoS Flood sur une application gRPC.

La figure 1 montre une application gRPC subissant une attaque DoS. Dans le contexte de gRPC, la mesure critique est le nombre de datagrammes par seconde (DPS), qui correspond au débit de messages par seconde. Dans cette image, la courbe jaune représente le processus d'apprentissage : lorsque la prédiction DPS de base converge vers la valeur DPS entrante (en bleu), NGINX App Protect a appris à quoi ressemble le trafic « normal » pour cette application . La forte augmentation du DPS à 12:25:00 indique le début d'une attaque. La sonnette d'alarme rouge indique le moment où NGINX App Protect DoS est sûr qu'une attaque est en cours et démarre les phases d'atténuation.

La figure 2 montre NGINX App Protect DoS en train de détecter un comportement anormal et de contrecarrer une attaque DoS par inondation gRPC à l'aide d'une approche d'atténuation progressive. Le pic rouge indique le nombre de redirections HTTP/2 envoyées à tous les clients pendant la phase d’atténuation du débit global. Le graphique violet représente les redirections envoyées à des clients spécifiques lorsque leurs demandes correspondent à une signature qui modélise le comportement anormal. Le graphique jaune représente les redirections envoyées à des acteurs malveillants détectés spécifiques identifiés par adresse IP et empreinte TLS.

La figure 3 montre une signature dynamique créée par NGINX App Protect DoS qui est alimentée par l'apprentissage automatique et qui présente les attributs associés au comportement anormal de cette attaque par inondation gRPC. La signature bloque les demandes qui lui correspondent pendant la phase initiale d’atténuation de la signature.

La figure 4 montre comment NGINX App Protect DoS passe d’une atténuation basée sur les signatures à une atténuation par les acteurs malveillants lorsqu’une attaque persiste. En analysant le comportement des utilisateurs, NGINX App Protect DoS a identifié les mauvais acteurs grâce à l'adresse IP source et aux empreintes digitales TLS présentées ici. Au lieu d’examiner chaque demande pour des signatures spécifiques indiquant un comportement anormal, le service est ici refusé à des attaquants spécifiques. Cela permet de générer des signatures dynamiques qui identifient ces modèles d’attaque spécifiques et les atténuent automatiquement.

Avec les API gRPC, vous utilisez l'interface gRPC pour définir la politique de sécurité dans le fichier de bibliothèque de types (IDL) et les fichiers de définition de proto pour le protobuf. Cela fournit une solution de politique de sécurité sans intervention : vous n'avez pas besoin de vous fier à la définition protobuf pour protéger le service gRPC contre les attaques. Les fichiers proto gRPC sont fréquemment utilisés dans le cadre des pipelines CI/CD , alignant les équipes de sécurité et de développement en automatisant la protection et en activant la sécurité en tant que code pour une intégration complète du pipeline CI/CD. NGINX App Protect DoS garantit une sécurité cohérente en intégrant de manière transparente la protection dans vos applications gRPC afin qu'elles soient toujours protégées par les politiques de sécurité les plus récentes et les plus à jour .

Bien que gRPC offre la vitesse et la flexibilité dont les développeurs ont besoin pour concevoir et déployer des applications modernes, la nature ouverte inhérente à son framework le rend très vulnérable aux attaques DoS. Pour garder une longueur d'avance sur les attaques DoS de couche 7 graves qui peuvent entraîner une dégradation des performances, des pannes application et de sites Web, des abandons de revenus et des dommages à la fidélité des clients et à la marque, vous avez besoin d'une défense moderne. C'est pourquoi NGINX App Protect DoS est essentiel pour vos applications gRPC modernes.

Pour essayer vous-même NGINX App Protect DoS avec NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .

Pour plus d'informations, consultez notre livre blanc, Sécuriser les applications modernes contre les attaques DoS de couche 7 .