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 entendu, il ne suffit pas de penser à se protéger contre les menaces de sécurité : il faut également mettre en œuvre des processus bien définis pour suivre les vulnérabilités et mettre en place des protections dès qu’elles sont disponibles. Il est facile de sous-estimer le temps et les efforts que cela peut prendre si vous devez tout faire vous-même, comme c’est le cas avec les logiciels open source. En effet, permettre de se protéger rapidement et facilement contre les menaces de sécurité est un avantage souvent négligé des logiciels pris en charge par le commerce comme NGINX Plus.

Dans ce blog, nous explorons les défis liés à la protection des logiciels open source et expliquons comment NGINX Plus permet d'atténuer beaucoup plus rapidement et plus 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 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 conséquences des bugs sont considérablement aggravées lorsque vous construisez votre pile d’applications à partir de plusieurs outils open source, langages de programmation et plateformes. Vous devez examiner chaque composant séparément pour valider qu’il est exempt de bogues. Lorsque des bugs sont découverts dans un logiciel open source, il est important d’avoir une politique définie pour les valider, les tester et (si possible) les corriger.

Votre politique en matière de logiciels open source doit inclure 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 logiciels open source et vendeur 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, incluent NGINX Controller [maintenant F5 NGINX Management Suite ] , NGINX App Protect et NGINX Ingress Controller - et les offres gratuites et open source, qui incluent 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 mentionné qu’un avantage souvent négligé de NGINX Plus est la façon dont il permet à nos clients de se protéger plus rapidement et plus facilement contre les vulnérabilités. Traiter les vulnérabilités des logiciels open source peut prendre beaucoup plus de temps – et donc coûter beaucoup plus cher – que beaucoup de gens ne le pensent.

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 décrit dans Signaler une vulnérabilité , lorsqu'une vulnérabilité affecte le logiciel NGINX, nous sommes généralement avertis avant qu'elle ne soit divulguée publiquement en tant que CVE. L'avertissement préalable nous permet de préparer un correctif avant la divulgation publique, et nous publions généralement le correctif le jour de la divulgation (ou dans quelques jours dans certains cas). Le correctif est disponible pour les clients NGINX Plus sous la forme de binaires corrigés. Il est disponible pour les utilisateurs de NGINX Open Source sous la forme de code source corrigé et de 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 exploitent ou intègrent NGINX Open Source peuvent ne pas avoir connaissance de la vulnérabilité avant sa divulgation. Même si c’est le cas, notre expérience montre que leurs correctifs peuvent être en retard de plusieurs mois par rapport au correctif NGINX. Cela est compréhensible, en particulier pour les logiciels open source qui sont souvent maintenus par des bénévoles, mais cela laisse votre infrastructure sans protection et sujette à l'exploitation par des pirates informatiques une fois la vulnérabilité divulguée publiquement.

À 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é n’est pas clair ou le fournisseur de logiciels ne considère pas qu’un correctif est nécessaire même s’il 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 qui gère l' ensemble de règles de base OWASP ModSecurity (CRS) a découvert que la manière dont ModSecurity v3 effectue la correspondance globale des 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 ). L'organisation qui gère ModSecurity elle-même, Trustwave, a contesté que ce comportement soit un problème de sécurité et a refusé de publier un correctif.

NGINX ModSecurity WAF est un module dynamique pour NGINX Plus construit sur ModSecurity v3. L'équipe NGINX a décidé que le comportement décrit dans CVE-2020-15598 avait suffisamment de potentiel pour provoquer une vulnérabilité DoS et nous avons donc publié un correctif en septembre 2020. Comme nous l'avons expliqué dans le blog annonçant le patch , les utilisateurs d'une version open source de ModSecurity (qui inclut les utilisateurs NGINX Open Source) doivent décider eux-mêmes s'ils souhaitent appliquer le patch de l'équipe OWASP CRS ou s'en tenir au logiciel non corrigé de Trustwave et éventuellement mettre en œuvre les modifications d'atténuation proposé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 .