Atténuez rapidement et facilement les vulnérabilités de sécurité avec NGINX Plus

Laurent Pétroque

Chez NGINX, nous sommes fiers que des millions d’organisations à travers le monde fassent confiance à nos logiciels pour faire fonctionner leurs sites Web et leurs infrastructures de diffusion d’applications. Compte tenu de l’importance cruciale de NGINX pour nos utilisateurs, nous sommes surpris lorsqu’ils reconnaissent ne pas avoir vraiment réfléchi à la nécessité d’utiliser une version à jour intégrant des correctifs pour les failles de sécurité — telles que les vulnérabilités et expositions courantes (CVE) — devenues si fréquentes sur Internet aujourd’hui.

Bien entendu, il ne suffit pas de penser à se prémunir contre les menaces de sécurité : vous devez mettre en œuvre des processus clairement définis pour suivre les vulnérabilités et déployer des protections dès qu’elles sont disponibles. Il est facile de sous-estimer le temps et les efforts que cela peut demander lorsque vous devez tout gérer vous-même, comme c’est le cas avec les logiciels open source. En effet, la possibilité de se protéger rapidement et facilement contre les menaces de sécurité est un avantage souvent négligé des logiciels bénéficiant d’un support commercial, tels que NGINX Plus.

Dans cet article de blog, nous examinons les défis liés à la protection des logiciels open source et expliquons comment NGINX Plus permet d’atténuer beaucoup plus rapidement et facilement les CVE et autres menaces de sécurité.

Gestion des vulnérabilités dans les logiciels open source

Même si tous les développeurs aiment à penser qu’ils écrivent un code parfait, aucun logiciel n’est exempt de bugs. Ils espèrent que la plupart des bugs seront détectés au cours du développement, dans le cadre d’un processus rigoureux de contrôle qualité, et que seuls quelques-uns apparaîtront lors d’une utilisation normale tout au long du cycle de vie de l’application. Dans le pire des cas, les bugs sont découverts par des utilisateurs malveillants aux intentions malhonnêtes.

Les conséquences des bugs sont considérablement amplifiées lorsque votre pile applicative repose sur plusieurs outils open source, langages de programmation et plateformes. Vous devez examiner chaque composant séparément afin de vérifier qu’il est exempt de bugs. Lorsque des bugs sont découverts dans un logiciel open source, il est important de disposer d’une politique clairement définie pour les valider, les tester et, si possible, les corriger.

Votre politique relative aux logiciels open source doit inclure au moins trois processus :

1. Examen et tests réguliers
2. Suivi des vulnérabilités et signalement en interne
3. Corriger les vulnérabilités dans les meilleurs délais

Signaler une vulnérabilité

Lorsqu’une vulnérabilité de sécurité est découverte, sa divulgation suit une procédure standard. La première étape consiste à envoyer un rapport détaillé à l’auteur ou à l’éditeur du logiciel. La personne ayant signalé la vulnérabilité et l’auteur décident ensemble des modalités et de la date de sa divulgation, généralement sous la forme d’une entrée dans la base de données des « vulnérabilités et expositions courantes » (CVE). Par convention, l’auteur dispose de 90 jours pour corriger le problème avant sa divulgation, mais il est possible de négocier un délai supplémentaire.

NGINX et les CVE

En tant que fournisseur de logiciels open source et éditeur de logiciels commerciaux, NGINX participe activement au processus de signalement et de correction des CVE et autres vulnérabilités qui affectent NGINX Open Source et NGINX Plus, ainsi que ses autres produits commerciaux – qui, au moment de la rédaction, comprennent NGINX Controller [désormais F5 NGINX Management Suite], NGINX App Protect et NGINX Ingress Controller – et ses offres gratuites et open source, qui comprennent NGINX Service Mesh, NGINX Unit et NGINX Amplify.

Les utilisateurs de NGINX Open Source bénéficient du fait que NGINX Plus repose sur celui-ci, car nous nous engageons à respecter des normes de support et de processus de niveau entreprise pour les clients de NGINX Plus. Ces normes comprennent des accords de niveau de service (SLA) conclus avec nos clients, qui définissent les procédures de correction des bogues et de test auxquelles les correctifs doivent se conformer, tant pour le logiciel principal que pour les dépendances et les modules pris en charge. Les SLA aident les clients à se conformer aux réglementations, tout en réduisant au minimum le risque d’exposition à l’exploitation de vulnérabilités.

Une difficulté supplémentaire pour NGINX Open Source tient au fait que de nombreuses technologies tierces l’utilisent et l’intègrent à leurs produits. Les fournisseurs de ces technologies disposent de leurs propres processus pour divulguer et corriger les vulnérabilités logicielles lorsqu’elles sont découvertes. Comme nous l’expliquons dans la section suivante, il s’écoule parfois un délai assez important entre la publication d’un correctif pour NGINX Open Source et celle d’un correctif correspondant pour les technologies tierces.

Comment NGINX Plus protège ses abonnés contre les vulnérabilités

Dans l’introduction, nous avons indiqué que l’un des avantages souvent négligés de NGINX Plus est qu’il permet à nos clients de se protéger plus rapidement et plus facilement contre les vulnérabilités. La gestion des vulnérabilités dans les logiciels open source peut prendre beaucoup plus de temps — et donc coûter plus cher — qu’on ne le pense généralement.

Dans les sections suivantes, nous présentons cinq raisons précises pour lesquelles la résolution des vulnérabilités est plus rapide et plus facile pour les abonnés à NGINX Plus.

NGINX informe de manière proactive les abonnés à NGINX Plus de la disponibilité de correctifs

Lorsque nous publions un correctif de sécurité pour NGINX Open Source et NGINX Plus, nous en informons de manière proactive les clients de NGINX Plus par e-mail. Nous publions également un article de blog annonçant la disponibilité de la plupart des correctifs, mais nous n’avons aucun moyen de contacter directement les utilisateurs de NGINX Open Source. Il leur incombe donc de surveiller les CVE et les autres bases de données de vulnérabilités, ainsi que de consulter régulièrement notre blog.

Le SIRT de F5 fournit une assistance en temps réel aux abonnés NGINX Plus victimes d’une attaque

Lorsque des clients de F5, notamment des abonnés à NGINX Plus, sont victimes d’attaques, la F5 Security Incident Response Team (SIRT) leur fournit une assistance en temps réel. La SIRT intervient rapidement pour atténuer efficacement les attaques et rétablir vos activités. Elle continue à travailler avec vous même après la fin de l’attaque afin d’« aller au-delà de l’incident signalé pour réduire les dommages globaux causés à votre organisation, mais aussi comprendre, anticiper et prévenir les menaces futures ».

NGINX App Protect renforce la protection des applications

NGINX App Protect est un pare-feu d’applications web (WAF) de niveau professionnel, qui s’appuie sur les 20 ans d’expérience de F5 en matière de sécurité et se déploie sous la forme d’un module dynamique NGINX Plus. Il renforce la sécurité de couche 7 de NGINX Plus grâce à une protection propre aux applications contre un nombre encore plus important de CVE affectant vos serveurs d’applications backend. NGINX et F5 s’engagent à fournir des signatures associées à des campagnes d’attaque spécifiques. Résultat : NGINX App Protect évite aux abonnés NGINX Plus d’avoir à créer leurs propres signatures et à gérer de nombreux faux positifs.

NGINX Plus prend en charge l’authentification basée sur JWT et OpenID Connect

Même en l’absence de vulnérabilités spécifiques nécessitant l’application de correctifs, des protocoles d’authentification sophistiqués contribuent à empêcher les acteurs malveillants d’accéder à vos applications et à votre infrastructure. Outre les méthodes disponibles dans NGINX Open Source, NGINX Plus prend en charge l’authentification basée sur les jetons Web JSON (JWT) et OpenID Connect, aussi bien pour les clients web que pour les clients d’API.

Les abonnés à NGINX Plus reçoivent immédiatement les correctifs

Comme indiqué dans Signaler une vulnérabilité, lorsqu’une vulnérabilité affecte un logiciel NGINX, nous en sommes généralement informés avant qu’elle ne soit rendue publique sous la forme d’une CVE. Cette notification préalable nous permet de préparer un correctif avant la divulgation publique, et nous publions généralement ce correctif le jour de la divulgation (ou, dans certains cas, dans les quelques jours qui suivent). Le correctif est mis à la disposition des clients NGINX Plus sous la forme de fichiers binaires corrigés. Il est proposé aux utilisateurs de NGINX Open Source sous la forme d’un code source corrigé et de fichiers binaires corrigés pour les systèmes d’exploitation pris en charge, mais, comme indiqué ci-dessus, nous n’avons aucun moyen d’informer directement les utilisateurs de NGINX Open Source.

Les technologies tierces qui utilisent ou intègrent NGINX Open Source peuvent ne pas avoir connaissance de la vulnérabilité avant sa divulgation. Même si elles en sont informées, notre expérience montre que leurs correctifs peuvent être publiés plusieurs mois après celui de NGINX. Cela est compréhensible, en particulier pour les logiciels open source, souvent maintenus par des bénévoles, mais votre infrastructure reste alors sans protection et susceptible d’être exploitée par des pirates informatiques après la divulgation publique de la vulnérabilité.

À titre d’exemple, deux CVE concernant des vulnérabilités liées à HTTP/2 ont été découvertes à l’automne 2018 (CVE-2018-16843 et CVE-2018-16844). En réponse, nous avons appliqué des correctifs de sécurité à NGINX Plus R16 et à NGINX Open Source 1.15.6. Le populaire logiciel OpenResty, qui s’appuie sur NGINX Open Source pour fournir certaines des fonctionnalités de NGINX Plus, n’a publié une première version candidate intégrant ces correctifs que le 3 mars 2019, soit quatre mois entiers après le correctif de NGINX. Les solutions reposant sur OpenResty mettent ensuite généralement encore plus de temps à corriger leur base de code.

Il arrive que le statut d’une vulnérabilité ne soit pas clairement établi, ou que le fournisseur du logiciel estime qu’un correctif n’est pas nécessaire, même si elle constitue un vecteur d’attaque potentiel. Une telle situation s’est produite en 2020 avec ModSecurity, le logiciel WAF open source le plus utilisé. L’équipe chargée de la maintenance de l’ensemble de règles de base OWASP ModSecurity (CRS) a découvert que la manière dont ModSecurity v3 effectue la recherche globale de correspondances dans les expressions régulières peut entraîner ce que l’équipe OWASP CRS considère comme une vulnérabilité par déni de service (CVE-2020-15598). Trustwave, l’organisation chargée de la maintenance de ModSecurity, a contesté le fait que ce comportement constitue un problème de sécurité et a refusé de publier un correctif.

NGINX ModSecurity WAF est un module dynamique pour NGINX Plus basé sur ModSecurity v3. L’équipe NGINX a estimé que le comportement décrit dans la CVE-2020-15598 était suffisamment susceptible d’entraîner une vulnérabilité par déni de service (DoS) pour que nous publiions un correctif en septembre 2020. Comme nous l’avons expliqué dans le billet de blog annonçant le correctif, les utilisateurs d’une version open source de ModSecurity (notamment les utilisateurs de NGINX Open Source) doivent décider eux-mêmes s’ils souhaitent appliquer le correctif de l’équipe OWASP CRS ou conserver le logiciel non corrigé de Trustwave et éventuellement mettre en œuvre les mesures d’atténuation proposées par Trustwave.

[Éditeur – La commercialisation de NGINX ModSecurity WAF a officiellement pris fin le 1er avril 2022, et sa fin de vie prendra effet le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

Conclusion

Dans un environnement commercial toujours plus concurrentiel, les équipes logicielles sont soumises à une forte pression pour livrer du code nouveau et mis à jour aussi rapidement que possible afin de proposer les services les plus innovants. Parallèlement, la multiplication des attaques sophistiquées visant les infrastructures et les applications rend indispensable le suivi des vulnérabilités et leur atténuation dans les plus brefs délais, une tâche fastidieuse et chronophage.

Un abonnement NGINX Plus permet de se décharger de cette contrainte, afin que les équipes applicatives puissent se concentrer sur leur mission principale – livrer du code plus rapidement – tout en protégeant l’organisation contre les vulnérabilités de sécurité.

Découvrez par vous-même toutes les fonctionnalités avancées de NGINX Plus : commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Laurent Pétroque

Autres articles de Laurent Pétroque