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

Chez NGINX, nous sommes fiers que des millions d'organisations à travers le monde fassent confiance à notre logiciel pour alimenter leurs sites Web et leur infrastructure de diffusion d'applications. Étant donné l'importance de la dépendance de nos utilisateurs à l'égard de NGINX, nous sommes surpris lorsqu'ils admettent qu'ils n'ont pas vraiment réfléchi à l'importance d'exécuter une version à jour contenant des correctifs pour les vulnérabilités de sécurité - telles que les vulnérabilités et expositions courantes (CVE) - qui sont devenues si courantes sur l'Internet d'aujourd'hui.

Bien sûr, il ne suffit pas de penser à se protéger contre les menaces de sécurité : vous devez mettre en place des processus clairs pour suivre les vulnérabilités et appliquer les protections dès leur disponibilité. Vous sous-estimez facilement le temps et l’énergie nécessaires lorsque tout dépend de vous, comme c’est le cas avec les logiciels libres. En fait, protéger rapidement et facilement vos systèmes contre les menaces de sécurité constitue un avantage souvent négligé des logiciels commerciaux comme NGINX Plus.

Dans ce blog, nous analysons les défis liés à la protection des logiciels libres et montrons comment NGINX Plus accélère significativement l’atténuation des CVE et autres menaces de sécurité.

Gérer les vulnérabilités dans les logiciels libres

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

Les bugs causent bien plus de dégâts quand votre pile applicative combine plusieurs outils open source, langages de programmation et plateformes. Vous devez examiner chaque composant individuellement pour vous assurer qu’il est exempt de bugs. Lorsqu’un bug est détecté dans un logiciel libre, il est crucial d’adopter une politique claire pour le valider, le tester et, si possible, le corriger.

Votre politique pour le logiciel libre doit comprendre au moins trois processus :

1. Examens et tests réguliers
2. Suivi des vulnérabilités et signalement en interne
3. Remédier aux vulnérabilités en temps opportun

Signaler une vulnérabilité

Lorsqu'une vulnérabilité de sécurité est découverte, il existe une séquence standard d'événements pour la divulguer. La première étape consiste à soumettre un rapport détaillé à l’auteur ou au fournisseur du logiciel. Le rapporteur et l'auteur décident ensemble comment et quand divulguer la vulnérabilité, généralement sous la forme d'un enregistrement dans la base de données Common Vulnerabilities and Exposures (CVE). Par convention, l'auteur dispose de 90 jours pour résoudre le problème avant divulgation, mais il est possible de négocier un délai plus long.

NGINX et CVE

En tant que fournisseur de logiciel libre et éditeur de logiciels commerciaux, NGINX s'engage activement dans le signalement et la correction des CVE et autres vulnérabilités affectant NGINX Open Source et NGINX Plus, ainsi que ses autres produits commerciaux – qui incluent, à ce jour, NGINX Controller [désormais F5 NGINX Management Suite], NGINX App Protect et NGINX Ingress Controller – ainsi que ses offres libres et open source, comprenant NGINX Service Mesh, NGINX Unit et NGINX Amplify.

Les utilisateurs de NGINX Open Source bénéficient du fait que NGINX Plus est basé sur celui-ci, car nous nous engageons à fournir un support de niveau entreprise et des normes de processus pour les clients NGINX Plus. Ces normes incluent des accords de niveau de service (SLA) avec nos clients qui dictent les procédures de correction de bogues et de test auxquelles les correctifs doivent se conformer, pour le logiciel principal, les dépendances et les modules pris en charge. Les SLA aident les clients à se conformer aux réglementations, minimisant ainsi le risque d’exposition aux exploits de vulnérabilité.

Un problème supplémentaire pour NGINX Open Source est que de nombreuses technologies tierces l’exploitent et l’intègrent dans leurs produits. Les fournisseurs de ces technologies disposent de leurs propres processus de divulgation et de correction des vulnérabilités logicielles lorsqu’elles sont découvertes. Comme nous le verrons dans la section suivante , il existe parfois un décalage assez important entre la publication d’un correctif pour NGINX Open Source et la publication d’un correctif correspondant pour les technologies tierces.

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

Dans l’introduction, nous avons indiqué qu’une force souvent sous-estimée de NGINX Plus est la rapidité et la simplicité avec lesquelles vous pouvez vous protéger des vulnérabilités. Corriger les vulnérabilités des logiciels libres demande souvent plus de temps – et donc coûte plus cher – que ce que la plupart imaginent.

Dans les sections suivantes, nous discutons de cinq manières spécifiques permettant de résoudre les vulnérabilités plus rapidement et plus facilement pour les abonnés NGINX Plus.

NGINX informe de manière proactive les abonnés NGINX Plus des correctifs

Lorsque nous publions un correctif de sécurité pour NGINX Open Source et NGINX Plus, nous en informons proactivement les clients NGINX Plus par e-mail. Nous publions également un blog annonçant la disponibilité de la plupart des correctifs, mais nous n'avons aucun moyen d'atteindre directement les utilisateurs de NGINX Open Source. Cela leur impose la responsabilité de surveiller les CVE et autres bases de données de vulnérabilités et de consulter régulièrement notre blog.

F5 SIRT fournit une aide en temps réel aux abonnés NGINX Plus attaqués

Lorsque les clients F5, y compris les abonnés NGINX Plus, sont victimes d’attaques, l’ équipe de réponse aux incidents de sécurité (SIRT) F5 est là pour fournir une assistance en temps réel. Le SIRT agit rapidement pour atténuer efficacement les attaques et vous permettre de reprendre vos activités. Ils continuent de travailler avec vous même après l’arrêt de l’attaque – ils « regardent au-delà de l’incident signalé pour réduire le préjudice global causé à votre organisation, ainsi que pour comprendre, anticiper et dissuader les menaces futures ».

NGINX App Protect renforce la protection des applications

NGINX App Protect est un pare-feu d'application Web (WAF) de niveau entreprise, optimisé par les 20 années d'expérience en matière de sécurité de F5 et déployé en tant que module dynamique NGINX Plus. Il renforce la sécurité de couche 7 de NGINX Plus avec une protection spécifique aux applications contre encore plus de CVE dans vos serveurs d'applications back-end. NGINX et F5 s'engagent à fournir des signatures liées à des campagnes d'attaque spécifiques. Le résultat ? NGINX App Protect libère les abonnés NGINX Plus de la création de leurs propres signatures et de la gestion de plusieurs 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 des correctifs, des protocoles d’authentification sophistiqués aident à empêcher les mauvais acteurs d’accéder à vos applications et à votre infrastructure. En plus des méthodes disponibles dans NGINX Open Source, NGINX Plus prend en charge l'authentification basée sur JSON Web Token (JWT) et OpenID Connect , pour les clients Web et API .

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

Comme expliqué dans Signaler une vulnérabilité, lorsque le logiciel NGINX présente une vulnérabilité, nous recevons généralement la notification avant sa divulgation publique sous forme de CVE. Cette alerte préalable nous permet de préparer un correctif avant la divulgation publique, et nous publions en général ce correctif le jour même (ou dans les jours qui suivent, selon les cas). Les clients NGINX Plus bénéficient du correctif sous forme de fichiers binaires corrigés. Les utilisateurs de NGINX Open Source peuvent accéder au code source corrigé ainsi qu’aux binaires corrigés pour les systèmes d’exploitation supportés, mais comme mentionné, nous ne pouvons pas informer directement ces utilisateurs.

Les technologies tierces qui utilisent ou intègrent NGINX Open Source peuvent ne pas découvrir la vulnérabilité avant sa divulgation. Même lorsqu’elles la détectent, nous constatons que leurs correctifs arrivent souvent plusieurs mois après celui de NGINX. C’est compréhensible, surtout pour les logiciels libres souvent entretenus par des bénévoles. Néanmoins, cela expose votre infrastructure sans protection aux attaques dès que la vulnérabilité est rendue publique.

À titre d’exemple, deux CVE concernant des vulnérabilités avec 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 logiciel populaire OpenResty, qui s'appuie sur NGINX Open Source pour fournir certaines des fonctionnalités de NGINX Plus, a publié pour la première fois une version candidate intégrant ces correctifs le 3 mars 2019 , soit 4 mois après le correctif de NGINX. Les solutions construites sur OpenResty prennent généralement encore plus de temps pour corriger leur base de code.

Parfois, le statut d’une vulnérabilité reste flou, ou le fournisseur de logiciel estime qu’un correctif n’est pas nécessaire, même s’il représente un vecteur d’attaque potentiel. Une telle situation s’est produite en 2020 avec ModSecurity, le logiciel WAF open source le plus répandu. L’équipe qui maintient le OWASP ModSecurity Core Rule Set (CRS) a identifié que la manière dont ModSecurity v3 réalise la correspondance globale des expressions régulières peut engendrer ce que l’équipe OWASP CRS considère comme une vulnérabilité de type déni de service (CVE-2020-15598). L’organisation à l’origine de ModSecurity, Trustwave, a contesté que ce comportement constitue un problème de sécurité et a refusé d’émettre 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 CVE-2020-15598 présentait un risque réel de vulnérabilité DoS, c’est pourquoi nous avons publié un correctif en septembre 2020. Comme nous l’avons expliqué dans le blog annonçant ce correctif, les utilisateurs d’une version open source de ModSecurity (incluant ceux de NGINX Open Source) doivent eux-mêmes choisir s’ils appliquent la mise à jour proposée par l’équipe OWASP CRS ou s’ils préfèrent conserver la version non corrigée de Trustwave, en adoptant éventuellement les mesures d’atténuation recommandées par Trustwave.

[ Éditeur – NGINX ModSecurity WAF est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

Conclusion

Dans un environnement commercial de plus en plus concurrentiel, les équipes de développement de logiciels sont soumises à une pression constante pour fournir du code nouveau et mis à jour le plus rapidement possible afin de fournir les services les plus innovants. Dans le même temps, l’augmentation des attaques sophistiquées sur les infrastructures et les applications rend essentiel le suivi des vulnérabilités et leur atténuation le plus rapidement possible, une pratique fastidieuse et chronophage.

Un abonnement NGINX Plus décharge cette charge, permettant aux équipes d'application de se concentrer sur leur mission principale (fournir du code plus rapidement) tandis que l'organisation reste protégée contre les vulnérabilités de sécurité.

Essayez par vous-même toutes les fonctionnalités avancées de NGINX Plus – démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .