Protégez vos applications gRPC contre les attaques DoS graves avec NGINX App Protect DoS

Au cours des deux dernières années, la demande des clients en biens et services a souligné à quel point il est essentiel pour les organisations de pouvoir évoluer facilement et innover plus rapidement, ce qui a conduit nombre d’entre elles à accélérer leur transition d’une architecture monolithique vers une architecture cloud native. Selon le récent rapport de F5, État de la stratégie applicative 2021, le nombre d’organisations modernisant leurs applications a augmenté de 133 % au cours de la seule année écoulée. 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. S’il est possible de simplement migrer une application monolithique existante telle quelle, cette approche n’offre aucun avantage en matière de coûts ou de flexibilité. Pour tirer pleinement parti du modèle distribué offert par les services de cloud computing, la meilleure solution consiste à adopter une approche modulaire : place aux microservices.

Les microservices constituent une approche architecturale qui permet aux développeurs de concevoir une application sous la forme d’un ensemble de services applicatifs légers, structurellement indépendants les uns des autres et de la plateforme sous-jacente. Chaque microservice s’exécute en tant que processus distinct et communique avec les autres services au moyen d’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 davantage d’avantages en matière de performances, de coûts, d’évolutivité et de capacité à innover rapidement.

Les développeurs cherchent constamment des moyens de gagner en efficacité et d’accélérer le déploiement des applications. Les API permettent aux logiciels de communiquer entre eux et fournissent les composants de base nécessaires au développement. Pour demander des données aux serveurs à l’aide du protocole HTTP, les développeurs web utilisaient à l’origine le protocole SOAP, qui transmet les détails de la requête dans un document XML. Cependant, les documents XML ont tendance à être volumineux, nécessitent d’importantes ressources supplémentaires et sont longs à développer.

Depuis, de nombreux développeurs se sont tournés vers REST, un style architectural et un ensemble de principes permettant de créer des API web sans état et fiables. Une API web qui respecte ces principes est dite RESTful. Les API web RESTful s’appuient généralement sur des méthodes HTTP pour accéder aux ressources au moyen de paramètres encodés dans l’URL et utilisent le format JSON ou XML pour transmettre les données. Grâce aux API RESTful, les applications sont plus rapides à développer et nécessitent moins de ressources.

Les avancées technologiques offrent de nouvelles possibilités pour faire progresser la conception d’applications. En 2015, Google a développé Google Remote Procedure Call (gRPC), un framework RPC open source moderne pouvant fonctionner dans n’importe quel environnement. Alors que REST repose sur le protocole HTTP 1.1 et utilise un modèle de communication requête-réponse, gRPC utilise HTTP/2 pour le transport et un modèle de communication client-réponse, mis en œuvre à l’aide de tampons de protocole (protobuf), qui servent de langage de description d’interface (IDL) pour décrire les services et les données. Protobuf sert à sérialiser les données structurées et est conçu pour offrir simplicité et performances. gRPC est environ 7 fois plus rapide que REST pour la réception de données et 10 fois plus rapide pour leur envoi, grâce à l’efficacité de protobuf et à l’utilisation de HTTP/2. gRPC permet également la communication en continu et traite plusieurs requêtes simultanément.

Les développeurs considèrent la création de microservices avec gRPC comme une alternative intéressante à l’utilisation d’API RESTful en raison de sa faible latence, de sa prise en charge de plusieurs langages, de sa représentation compacte des données et de la diffusion en temps réel. Ces caractéristiques le rendent particulièrement adapté aux communications entre microservices ainsi qu’aux réseaux à faible consommation d’énergie et à faible bande passante. La popularité de gRPC s’est accrue, car il facilite la création rapide et efficace de nouveaux services, avec une fiabilité et une évolutivité accrues, tout en garantissant l’indépendance vis-à-vis des langages, tant pour les clients que pour les serveurs.

Bien que la nature ouverte du protocole gRPC présente plusieurs avantages, la norme n’offre aucune protection contre les répercussions qu’une attaque par déni de service (DoS) peut avoir sur une application. Une application gRPC reste exposée aux mêmes types d’attaques DoS qu’une application traditionnelle.

Pourquoi il est difficile d’identifier une attaque DoS sur une application gRPC

Si les microservices et les conteneurs offrent aux développeurs davantage de liberté et d’autonomie pour proposer rapidement de nouvelles fonctionnalités aux clients, ils créent également de nouvelles vulnérabilités et possibilités d’exploitation. Parmi les cyberattaques qui gagnent en popularité figurent les attaques par déni de service (DoS), qui sont à l’origine, ces dernières années, d’un nombre croissant de vulnérabilités et expositions courantes (CVE), dont beaucoup sont dues à une mauvaise gestion des requêtes gRPC. Les attaques DoS de couche 7 visant les applications et les API ont augmenté de 20 % ces dernières années, tandis que l’ampleur et la gravité de leur impact ont progressé de près de 200 %.

Une attaque DoS consiste généralement à envoyer de grandes quantités de trafic apparemment légitime afin d’épuiser les ressources de l’application et de la rendre indisponible. Lors d’une attaque DoS classique, un acteur malveillant inonde un site Web ou une application d’un volume de trafic tel que les serveurs sont submergés par les requêtes, ce qui les ralentit, voire les fait tomber en panne. Les attaques DoS visent à ralentir ou à désactiver complètement des machines ou des réseaux, les rendant ainsi inaccessibles aux personnes qui en ont besoin. Tant que l’attaque n’est pas neutralisé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.

Nous observons de plus en plus d’attaques DoS qui utilisent des requêtes HTTP et HTTP/2 ou des appels d’API pour cibler la couche applicative (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 protéger les architectures applicatives modernes. Pourquoi les attaquants ont-ils délaissé les attaques volumétriques traditionnelles visant les couches réseau (couches 3 et 4) au profit des attaques de couche 7 ? Ils suivent la voie de la moindre résistance. Les ingénieurs en infrastructure ont consacré des années à mettre au point des mécanismes de défense efficaces contre les attaques de couches 3 et 4, qui sont donc plus faciles à bloquer et ont moins de chances d’aboutir. Le lancement de telles attaques est ainsi devenu plus coûteux, tant en argent qu’en temps, ce qui a poussé les attaquants à se tourner vers d’autres méthodes.

La détection des attaques DoS visant les applications gRPC est extrêmement difficile, en particulier dans les environnements modernes où la mise à l’échelle horizontale s’effectue automatiquement. Un service gRPC peut ne pas être conçu pour gérer un trafic à fort volume, ce qui en fait une cible facile à mettre hors service pour les attaquants. Les services gRPC sont également vulnérables aux attaques par inondation HTTP/2 menées à l’aide d’outils tels que h2load. En outre, les services gRPC peuvent facilement être pris pour cible lorsqu’un attaquant exploite les définitions de données correctement déclarées dans une spécification protobuf.

Un exemple courant d’utilisation abusive, bien qu’involontaire, d’un service gRPC se produit lorsqu’un bug dans un script entraîne l’envoi d’un nombre excessif de requêtes au service. Supposons, par exemple, qu’un script d’automatisation effectue un appel d’API lorsqu’une certaine condition se produit, ce qui, selon les concepteurs, devrait arriver toutes les deux secondes. Toutefois, en raison d’une erreur dans la définition de la condition, le script effectue l’appel toutes les deux millisecondes, imposant ainsi une charge inattendue au service gRPC backend.

Voici d’autres exemples d’attaques par déni de service (DoS) visant une application gRPC :

• L’insertion d’un champ malveillant dans un message gRPC peut entraîner une défaillance de l’application.
• Une attaque Slow POST envoie des requêtes partielles dans l’en-tête gRPC. Dans l’attente du reste de la requête, l’application ou le serveur maintient la connexion ouverte. Le pool de connexions simultanées risque alors d’être saturé, entraînant le rejet de nouvelles tentatives de connexion de la part des clients.
• Une attaque par saturation des paramètres HTTP/2 (CVE-2019-9515), au cours de laquelle l’attaquant envoie des trames SETTING vides au protocole gRPC, consomme les ressources de NGINX, qui ne peut alors plus traiter de nouvelles requêtes.

Exploitez toute 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 protection des applications contre les attaques DoS actuelles nécessite une approche moderne. Pour protéger des applications complexes et adaptatives, vous avez besoin d’une solution offrant une protection dynamique et extrêmement précise, fondée sur le comportement des utilisateurs et du site, qui allège la charge des équipes de sécurité tout en favorisant le développement rapide des applications et le maintien d’un avantage concurrentiel.

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

L’analyse comportementale est disponible à la fois pour les applications HTTP traditionnelles et pour les en-têtes des applications HTTP/2 modernes. NGINX App Protect DoS atténue les attaques en s’appuyant à la fois sur les signatures et sur l’identification des acteurs malveillants. Lors de la phase initiale d’atténuation par signature, NGINX App Protect DoS établit le profil des attributs associés aux comportements anormaux afin de créer des signatures dynamiques qui bloqueront ensuite les requêtes correspondant à ces comportements. Si l’attaque persiste, NGINX App Protect DoS passe à la phase d’atténuation ciblant les acteurs malveillants.

Grâce à la détection statistique des anomalies, NGINX App Protect DoS identifie efficacement les acteurs malveillants à partir de leur adresse IP source et de leurs empreintes TLS, ce qui lui permet de générer et de déployer des signatures dynamiques capables d’identifier et d’atténuer automatiquement ces schémas spécifiques de trafic d’attaque. Cette approche se distingue des solutions traditionnelles de protection contre les attaques DoS disponibles sur le marché, qui détectent le dépassement d’un seuil volumétrique. NGINX App Protect DoS peut bloquer des attaques dont les requêtes semblent parfaitement légitimes, même lorsque chaque attaquant génère 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 par déni de service (DoS) de type flood visant une application gRPC.

La figure 1 montre une application gRPC subissant une attaque par saturation DoS. Dans le contexte de gRPC, la métrique essentielle est le nombre de datagrammes par seconde (DPS), qui correspond au débit de messages par seconde. Sur cette image, la courbe jaune représente le processus d’apprentissage : lorsque la prédiction DPS de référence converge vers la valeur DPS entrant (en bleu), NGINX App Protect a appris à quoi ressemble le trafic « normal » de cette application. La forte hausse du DPS à 12:25:00 indique le début d’une attaque. La cloche d’alarme rouge indique le moment où NGINX App Protect DoS détermine avec certitude qu’une attaque est en cours et lance les phases d’atténuation.

Figure 1 : Une application gRPC subissant une attaque DoS

La figure 2 montre NGINX App Protect DoS en train de détecter un comportement anormal et de contrer une attaque par déni de service gRPC par inondation à 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 globale d’atténuation par limitation du débit. La courbe violette représente les redirections envoyées à des clients spécifiques lorsque leurs requêtes correspondent à une signature modélisant le comportement anormal. La courbe jaune représente les redirections envoyées à des acteurs malveillants spécifiques détectés et identifiés par leur adresse IP et leur empreinte TLS.

Figure 2 : NGINX App Protect DoS utilise une approche d’atténuation progressive pour contrer une attaque par inondation DoS gRPC

La figure 3 présente une signature dynamique créée par NGINX App Protect DoS, qui s’appuie sur l’apprentissage automatique et caractérise les attributs associés au comportement anormal de cette attaque par saturation gRPC. La signature bloque les requêtes correspondantes pendant la phase initiale d’atténuation par signature.

Figure 3 : Une signature dynamique

La figure 4 montre comment NGINX App Protect DoS passe d’une atténuation basée sur les signatures à une atténuation ciblant les acteurs malveillants lorsqu’une attaque persiste. En analysant le comportement des utilisateurs, NGINX App Protect DoS a identifié les acteurs malveillants à partir de l’adresse IP source et des empreintes TLS présentées ici. Au lieu d’examiner chaque requête à la recherche de signatures spécifiques indiquant un comportement anormal, le service est ici refusé à des attaquants précis. Cela permet de générer des signatures dynamiques qui identifient ces schémas d’attaque spécifiques et les atténuent automatiquement.

Figure 4 : NGINX App Protect DoS identifie les acteurs malveillants grâce à leur adresse IP et à leur empreinte TLS

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 dans les fichiers de définition proto de protobuf. Vous bénéficiez ainsi d’une solution de politique de sécurité sans intervention : vous n’avez pas besoin de vous appuyer sur 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 de pipelines CI/CD, ce qui permet d’aligner les équipes de sécurité et de développement grâce à l’automatisation de la protection et à l’adoption de la sécurité en tant que code, pour une intégration complète aux pipelines CI/CD. NGINX App Protect DoS garantit une sécurité cohérente en intégrant de manière transparente la protection à vos applications gRPC, afin qu’elles soient toujours protégées par les politiques de sécurité les plus récentes.

Si gRPC offre la rapidité et la flexibilité dont les développeurs ont besoin pour concevoir et déployer des applications modernes, la nature intrinsèquement ouverte de son framework le rend particulièrement vulnérable aux attaques DoS. Pour anticiper les attaques DoS sévères de couche 7, susceptibles d’entraîner une dégradation des performances, des interruptions d’applications et de sites web, des pertes de revenus ainsi qu’une atteinte à la fidélité des clients et à l’image de marque, vous avez besoin d’une solution de défense moderne. C’est pourquoi NGINX App Protect DoS est indispensable à vos applications gRPC modernes.

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

Pour en savoir plus, consultez notre livre blanc, « Sécuriser les applications modernes contre les attaques DoS de couche 7 ».

---