Cet article de blog porte sur une vulnérabilité récemment découverte liée au protocole HTTP/2. Dans certaines conditions, cette vulnérabilité peut être exploitée pour mener une attaque par déni de service contre NGINX Open Source, NGINX Plus et les produits associés qui implémentent la partie serveur de la spécification HTTP/2. Pour protéger vos systèmes contre cette attaque, nous vous recommandons de mettre immédiatement à jour votre configuration NGINX.
Le problème des réinitialisations de flux HTTP/2
Après l’établissement d’une connexion avec un serveur, le protocole HTTP/2 permet aux clients d’ouvrir des flux simultanés pour échanger des données. Contrairement aux versions précédentes du protocole, si un utilisateur décide de quitter la page ou d’interrompre l’échange de données pour toute autre raison, HTTP/2 permet d’annuler le flux. Pour ce faire, il envoie une trame RST_STREAM au serveur, lui évitant ainsi d’effectuer inutilement des opérations.
La vulnérabilité est exploitée en lançant puis en annulant rapidement un grand nombre de flux HTTP/2 sur une connexion établie, ce qui permet de contourner le nombre maximal de flux simultanés autorisé par le serveur. En effet, les flux entrants sont réinitialisés plus rapidement que les flux suivants n’arrivent, ce qui permet au client de surcharger le serveur sans jamais atteindre le seuil configuré.
Impact sur NGINX
Pour des raisons de performances et de consommation des ressources, NGINX limite par défaut le nombre de flux simultanés à 128 (voir « http2_max_concurrent_streams »). En outre, afin d’équilibrer au mieux les performances du réseau et du serveur, NGINX permet par défaut au client de maintenir les connexions HTTP ouvertes jusqu’à 1 000 requêtes grâce au mécanisme HTTP keep-alive (voir « keepalive_requests »).
En s’appuyant sur la limite par défaut des connexions persistantes, NGINX empêche ce type d’attaque. La création de connexions supplémentaires pour contourner cette limite permet de repérer les acteurs malveillants à l’aide des outils standard de surveillance et d’alerte de couche 4.
Toutefois, si NGINX est configuré avec une limite de connexions persistantes nettement supérieure à la valeur par défaut recommandée, l’attaque peut épuiser les ressources du système. Lorsqu’un flux est réinitialisé, le protocole HTTP/2 exige qu’aucune donnée ultérieure ne soit renvoyée au client sur ce flux. En règle générale, cette réinitialisation n’entraîne qu’une surcharge négligeable pour le serveur, sous la forme de tâches qui gèrent proprement l’annulation. Toutefois, en contournant la limite de flux de NGINX, un client peut exploiter cette surcharge et l’amplifier en ouvrant rapidement des milliers de flux. Cela provoque un pic d’utilisation du processeur du serveur, empêchant ainsi les clients légitimes d’accéder au service.
Déni de service par l’établissement de flux HTTP/2, suivi de l’annulation de ces flux avec des limites de maintien de connexion anormalement élevées.
Mesures pour réduire l’exposition aux attaques
En tant que serveur et proxy complet, NGINX fournit aux administrateurs des outils puissants pour atténuer les attaques par déni de service. Pour tirer parti de ces fonctionnalités, il est essentiel d’apporter les modifications suivantes aux fichiers de configuration de NGINX afin de réduire au minimum la surface d’attaque du serveur :
- keepalive_requests doit être conservé à sa valeur par défaut de 1 000 requêtes
- http2_max_concurrent_streams doit être conservé à sa valeur par défaut de 128 flux
Nous recommandons également d’ajouter ces mesures de sécurité conformément aux bonnes pratiques :
- limit_conn impose une limite au nombre de connexions autorisées depuis un même client. Cette directive doit être ajoutée avec un paramétrage raisonnable assurant un équilibre entre les performances de l’application et la sécurité.
- limit_req impose une limite au nombre de requêtes provenant d’un même client pouvant être traitées pendant une période donnée. Cette directive doit être ajoutée avec un paramétrage raisonnable assurant un équilibre entre les performances de l’application et la sécurité.
Notre réponse
Nous avons testé plusieurs stratégies d’atténuation qui nous ont permis de mieux comprendre l’impact potentiel de cette attaque sur notre large éventail de clients et d’utilisateurs. Bien que ces recherches aient confirmé que NGINX dispose déjà de tous les outils nécessaires pour éviter cette attaque, nous avons souhaité prendre des mesures supplémentaires afin que les utilisateurs qui doivent configurer NGINX au-delà des spécifications recommandées puissent le faire.
Notre enquête a permis de mettre au point une méthode visant à améliorer la résilience des serveurs face à diverses formes d’attaques par saturation théoriquement possibles via le protocole HTTP/2. Nous avons donc publié un correctif qui renforce la stabilité du système dans ces conditions. Pour se protéger contre de telles menaces, nous recommandons aux utilisateurs de NGINX Open Source de recompiler les fichiers binaires à partir de la dernière version du code source, et aux clients de NGINX Plus d’effectuer immédiatement la mise à jour vers les derniers paquets (R29p1 ou R30p1).
Fonctionnement du correctif
Afin de garantir la détection précoce des attaques par inondation visant NGINX, le correctif limite le nombre de nouveaux flux pouvant être introduits au cours d’une même boucle d’événements. Cette limite correspond au double de la valeur configurée à l’aide de la directive http2_max_concurrent_streams. Elle s’applique même si le seuil maximal n’est jamais atteint, par exemple lorsque les flux sont réinitialisés juste après l’envoi de la requête (comme dans le cas de cette attaque).
Produits concernés
Cette vulnérabilité affecte le module HTTP/2 de NGINX (ngx_http_v2_module). Pour savoir si votre produit NGINX ou F5 spécifique est susceptible d’être affecté, consultez la page suivante : https://my.f5.com/manage/s/article/K000137106.
Pour plus d’informations sur la CVE-2023-44487 – attaque par réinitialisation rapide HTTP/2, consultez : https://www.cve.org/CVERecord?id=CVE-2023-44487
Remerciements
Nous tenons à remercier Cloudflare, Amazon et Google pour leur contribution à la découverte de cette vulnérabilité, ainsi que pour leur collaboration afin de l’identifier et d’en atténuer les effets.
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.