Mit NGINX Plus Sicherheitslücken schnell und einfach schließen

Hier bei NGINX sind wir stolz darauf, dass buchstäblich Millionen von Organisationen auf der ganzen Welt beim Betrieb ihrer Websites und App-Delivery-Infrastruktur auf unsere Software vertrauen. Angesichts der großen Abhängigkeit unserer Benutzer von NGINX überrascht es uns, wenn sie zugeben, dass sie sich kaum Gedanken darüber gemacht haben, wie wichtig es ist, eine aktuelle Version zu verwenden, die Korrekturen für die Sicherheitslücken enthält, die im heutigen Internet so häufig vorkommen – beispielsweise Common Vulnerabilities and Exposures (CVEs).

Natürlich genügt es nicht, nur über den Schutz vor Sicherheitsbedrohungen nachzudenken – Sie müssen klar definierte Prozesse implementieren, um Schwachstellen aufzuspüren und Schutzmaßnahmen bereitzustellen, sobald diese verfügbar werden. Man unterschätzt leicht den Aufwand und die Zeit, die dafür erforderlich sind, wenn man, wie bei Open-Source-Software, alles selbst machen muss. Tatsächlich ist der schnelle und einfache Schutz vor Sicherheitsbedrohungen ein oft übersehener Vorteil kommerziell unterstützter Software wie NGINX Plus.

In diesem Blog untersuchen wir die Herausforderungen beim Schutz von Open-Source-Software und erklären, wie CVEs und andere Sicherheitsbedrohungen mit NGINX Plus viel schneller und einfacher eingedämmt werden können.

Umgang mit Schwachstellen in Open Source-Software

Auch wenn Entwickler gerne glauben, dass sie perfekten Code schreiben, ist keine Software frei von Fehlern. Entwickler hoffen, dass die meisten Fehler im Rahmen eines strengen Qualitätssicherungsprozesses während der Entwicklung erkannt werden und nur wenige während der normalen Nutzung der App während ihrer Lebensdauer auftauchen. Im schlimmsten Fall werden Fehler von böswilligen Benutzern mit bösen Absichten entdeckt.

Wenn Sie Ihren Anwendungsstapel aus mehreren Open Source-Tools, Programmiersprachen und Plattformen erstellen, verschärfen sich die Folgen von Fehlern erheblich. Sie müssen jede Komponente einzeln überprüfen, um sicherzustellen, dass sie fehlerfrei ist. Wenn in Open-Source-Software Fehler entdeckt werden, ist es wichtig, eine definierte Richtlinie für die Validierung, Prüfung und (sofern möglich) Behebung dieser Fehler zu haben.

Ihre Richtlinie für Open-Source-Software muss mindestens drei Prozesse umfassen:

1. Regelmäßige Überprüfung und Prüfung
2. Schwachstellen aufspüren und intern melden
3. Zeitnahe Behebung von Schwachstellen

Eine Sicherheitslücke melden

Wenn eine Sicherheitslücke entdeckt wird, gibt es eine standardmäßige Abfolge von Ereignissen für die Offenlegung. Der erste Schritt besteht darin, dem Autor oder Anbieter der Software einen ausführlichen Bericht zu übermitteln. Der Melder und der Autor entscheiden gemeinsam, wie und wann die Sicherheitslücke offengelegt wird. Dies geschieht normalerweise in Form eines Eintrags in der CVE-Datenbank ( Common Vulnerabilities and Exposures ). Der Autor hat üblicherweise 90 Tage Zeit, das Problem vor der Offenlegung zu lösen, es ist jedoch möglich, mehr Zeit auszuhandeln.

NGINX und CVEs

Als Anbieter von Open-Source-Software und Verkäufer kommerzieller Software beteiligt sich NGINX aktiv am Melde- und Behebungsprozess für CVEs und andere Schwachstellen, die NGINX Open Source und NGINX Plus sowie seine anderen kommerziellen Produkte betreffen – zu denen zum Zeitpunkt der Erstellung dieses Artikels NGINX Controller [jetzt F5 NGINX Management Suite ] , NGINX App Protect und NGINX Ingress Controller gehören – und an kostenlosen und Open-Source-Angeboten, zu denen NGINX Service Mesh , NGINX Unit und NGINX Amplify gehören.

Benutzer von NGINX Open Source profitieren von der Tatsache, dass NGINX Plus darauf basiert, da wir uns zu Support- und Prozessstandards auf Unternehmensebene für NGINX Plus-Kunden verpflichtet haben. Zu diesen Standards gehören Service Level Agreements (SLAs) mit unseren Kunden, die Fehlerbehebungs- und Testverfahren vorschreiben, denen Patches sowohl für die Kernsoftware als auch für Abhängigkeiten und unterstützte Module entsprechen müssen. Die SLAs unterstützen Kunden bei der Einhaltung von Vorschriften und minimieren das Risiko der Ausnutzung von Sicherheitslücken.

Eine zusätzliche Schwierigkeit bei NGINX Open Source besteht darin, dass viele Technologien von Drittanbietern es nutzen und in ihre Produkte einbetten. Die Anbieter dieser Technologien verfügen über eigene Prozesse zum Offenlegen und Patchen von Software-Schwachstellen, wenn diese entdeckt werden. Wie wir im nächsten Abschnitt erläutern, gibt es manchmal eine recht erhebliche Verzögerung zwischen unserer Veröffentlichung eines Patches für NGINX Open Source und der Veröffentlichung eines entsprechenden Patches für Technologien von Drittanbietern.

So schützt NGINX Plus Abonnenten vor Sicherheitslücken

In der Einleitung haben wir erwähnt, dass ein oft übersehener Vorteil von NGINX Plus darin besteht, dass unsere Kunden sich schneller und einfacher vor Schwachstellen schützen können. Die Behebung von Schwachstellen in Open-Source-Software kann viel zeitaufwändiger – und damit teurer – sein, als viele denken.

In den folgenden Abschnitten erläutern wir fünf konkrete Möglichkeiten, wie Sie Schwachstellen für NGINX Plus-Abonnenten schneller und einfacher beheben können.

NGINX informiert NGINX Plus-Abonnenten proaktiv über Patches

Wenn wir einen Sicherheitspatch für NGINX Open Source und NGINX Plus veröffentlichen, informieren wir NGINX Plus-Kunden proaktiv per E-Mail darüber. Wir veröffentlichen auch ein Blog, in dem wir die Verfügbarkeit der meisten Patches ankündigen, wir haben jedoch keine Möglichkeit, NGINX Open Source-Benutzer direkt zu erreichen. Dadurch entsteht für sie die Belastung, CVEs und andere Schwachstellendatenbanken zu überwachen und regelmäßig unseren Blog zu lesen.

F5 SIRT bietet angegriffenen NGINX Plus-Abonnenten Echtzeithilfe

Wenn F5-Kunden, einschließlich NGINX Plus-Abonnenten, Opfer von Angriffen werden, ist das F5 Security Incident Response Team (SIRT) zur Stelle, um in Echtzeit Hilfe zu leisten. Das SIRT arbeitet schnell, um Angriffe wirksam abzuwehren und Ihren Betrieb wieder aufzunehmen. Sie arbeiten auch nach dem Ende des Angriffs weiter mit Ihnen zusammen. Sie „blicken über den gemeldeten Vorfall hinaus, um den Gesamtschaden für Ihr Unternehmen zu verringern und zukünftige Bedrohungen zu verstehen, vorherzusehen und abzuwehren“.

NGINX App Protect verbessert den Anwendungsschutz

NGINX App Protect ist eine Web Application Firewall (WAF) der Unternehmensklasse, die auf der 20-jährigen Sicherheitserfahrung von F5 basiert und als dynamisches NGINX Plus-Modul bereitgestellt wird. Es verstärkt die Layer-7-Sicherheit von NGINX Plus mit anwendungsspezifischem Schutz vor noch mehr CVEs in Ihren Back-End-Anwendungsservern. NGINX und F5 verpflichten sich, Signaturen im Zusammenhang mit bestimmten Angriffskampagnen bereitzustellen. Das Ergebnis? NGINX App Protect befreit NGINX Plus-Abonnenten von der Erstellung eigener Signaturen und dem Umgang mit zahlreichen Fehlalarmen.

NGINX Plus unterstützt JWT-basierte und OpenID Connect-Authentifizierung

Auch wenn keine spezifischen Sicherheitslücken vorliegen, die Patches erfordern, helfen ausgefeilte Authentifizierungsprotokolle dabei, böswilligen Akteuren den Zugriff auf Ihre Anwendungen und Infrastruktur zu verwehren. Zusätzlich zu den in NGINX Open Source verfügbaren Methoden unterstützt NGINX Plus die Authentifizierung basierend auf JSON Web Token (JWT) und OpenID Connect sowohl für Web- als auch für API- Clients.

NGINX Plus-Abonnenten erhalten Patches sofort

Wie unter „Melden einer Sicherheitslücke“ beschrieben, werden wir normalerweise benachrichtigt, wenn eine Sicherheitslücke die NGINX-Software betrifft, bevor sie öffentlich als CVE bekannt gegeben wird. Durch die Vorwarnung sind wir in der Lage, vor der öffentlichen Bekanntgabe einen Patch vorzubereiten, den wir im Allgemeinen am Tag der Bekanntgabe (in manchen Fällen auch innerhalb weniger Tage) veröffentlichen. Der Fix steht NGINX Plus-Kunden in Form gepatchter Binärdateien zur Verfügung. Es steht Benutzern von NGINX Open Source in Form eines korrigierten Quellcodes und gepatchter Binärdateien für unterstützte Betriebssysteme zur Verfügung. Wie oben erwähnt, haben wir jedoch keine Möglichkeit, Benutzer von NGINX Open Source direkt zu informieren.

Technologien von Drittanbietern, die NGINX Open Source nutzen oder einbetten, werden sich der Sicherheitslücke möglicherweise erst bei ihrer Bekanntgabe bewusst. Selbst wenn dies der Fall ist, können ihre Patches unserer Erfahrung nach mehrere Monate hinter dem NGINX-Patch zurückliegen. Dies ist verständlich, insbesondere bei Open-Source-Software, die oft von Freiwilligen gepflegt wird. Allerdings bleibt Ihre Infrastruktur dadurch ungeschützt und kann von Hackern ausgenutzt werden, wenn die Sicherheitslücke öffentlich bekannt wird.

Beispielsweise wurden im Herbst 2018 zwei CVEs über Schwachstellen in HTTP/2 entdeckt ( CVE-2018-16843 und CVE-2018-16844 ). Als Reaktion darauf haben wir Sicherheitspatches auf NGINX Plus R16 und NGINX Open Source 1.15.6 angewendet. Die beliebte OpenResty-Software, die auf NGINX Open Source aufbaut, um einige der Funktionen von NGINX Plus bereitzustellen, hat am 3. März 2019 erstmals einen Release Candidate veröffentlicht, der diese Patches enthielt – volle 4 Monate nach dem Patch von NGINX. Bei Lösungen, die auf OpenResty basieren, dauert es dann normalerweise noch länger, ihre Codebasis zu patchen.

Manchmal ist der Status einer Sicherheitslücke nicht klar oder der Softwareanbieter ist der Ansicht, dass ein Patch nicht erforderlich ist, auch wenn die Sicherheitslücke einen potenziellen Angriffsvektor darstellt. Eine solche Situation trat im Jahr 2020 mit ModSecurity auf, der am weitesten verbreiteten Open-Source-WAF-Software. Das Team, das das OWASP ModSecurity Core Rule Set (CRS) verwaltet, hat festgestellt, dass die Art und Weise, wie ModSecurity v3 einen globalen Abgleich von regulären Ausdrücken durchführt, zu einer Sicherheitslücke führen kann, die das OWASP CRS-Team als Denial-of-Service-Sicherheitslücke ( CVE-2020-15598 ) betrachtet. Die Organisation, die ModSecurity selbst verwaltet, Trustwave, bestritt, dass es sich bei dem Verhalten um ein Sicherheitsproblem handelt , und lehnte die Herausgabe eines Patches ab.

NGINX ModSecurity WAF ist ein dynamisches Modul für NGINX Plus, das auf ModSecurity v3 basiert. Das NGINX-Team entschied, dass das in CVE-2020-15598 beschriebene Verhalten genügend Potenzial hatte, eine DoS-Schwachstelle zu verursachen, und veröffentlichte daher im September 2020 einen Patch. Wie wir im Blog zur Ankündigung des Patches erklärt haben, müssen Benutzer eines Open-Source-ModSecurity-Builds (darunter auch Benutzer von NGINX Open Source) selbst entscheiden, ob sie den Patch vom OWASP CRS-Team anwenden oder bei der ungepatchten Software von Trustwave bleiben und möglicherweise die von Trustwave vorgeschlagenen mildernden Änderungen implementieren.

[ Anmerkung des Herausgebers – Der Verkauf von NGINX ModSecurity WAF endete am 1. April 2022 offiziell, und der Lebenszyklus endet mit Wirkung zum 31. März 2024 . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

Abschluss

In der heutigen, immer wettbewerbsintensiveren Geschäftswelt stehen Softwareteams unter dem Druck, neuen und aktualisierten Code so schnell wie möglich bereitzustellen, um die innovativsten Dienste anbieten zu können. Gleichzeitig ist es aufgrund der zunehmenden Zahl komplexer Angriffe auf Infrastrukturen und Anwendungen unerlässlich, Schwachstellen aufzuspüren und schnellstmöglich zu beheben – eine mühsame und zeitaufwändige Praxis.

Ein NGINX Plus-Abonnement nimmt Ihnen diese Last ab und ermöglicht es Anwendungsteams, sich auf ihre Hauptaufgabe zu konzentrieren – die schnellere Bereitstellung von Code –, während das Unternehmen vor Sicherheitslücken geschützt bleibt.

Probieren Sie alle erweiterten Funktionen von NGINX Plus selbst aus – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .