Sicherheitslücken schnell und einfach mit NGINX Plus beheben

Laurent Pétroque

Wir bei NGINX sind stolz darauf, dass weltweit buchstäblich Millionen von Organisationen unserer Software vertrauen, um ihre Websites und ihre Infrastruktur für die Anwendungsbereitstellung zu betreiben. Angesichts der entscheidenden Bedeutung von NGINX für unsere Nutzer sind wir überrascht, wenn sie einräumen, dass sie sich bisher kaum Gedanken darüber gemacht haben, wie wichtig es ist, eine aktuelle Version einzusetzen, die Korrekturen für Sicherheitslücken enthält – etwa für Common Vulnerabilities and Exposures (CVEs), die im heutigen Internet so häufig auftreten.

Natürlich reicht es nicht aus, nur darüber nachzudenken, wie man sich vor Sicherheitsbedrohungen schützen kann. Sie müssen klar definierte Prozesse einführen, um Schwachstellen nachzuverfolgen und Schutzmaßnahmen zu ergreifen, sobald diese verfügbar sind. Der dafür erforderliche Zeit- und Arbeitsaufwand wird leicht unterschätzt, wenn Sie sich selbst um alles kümmern müssen, wie es bei Open-Source-Software der Fall ist. Tatsächlich ist die Möglichkeit, sich schnell und einfach vor Sicherheitsbedrohungen zu schützen, ein häufig übersehener Vorteil kommerziell unterstützter Software wie NGINX Plus.

In diesem Blogbeitrag beleuchten wir die Herausforderungen beim Schutz von Open-Source-Software und erklären, wie sich CVEs und andere Sicherheitsbedrohungen mit NGINX Plus wesentlich schneller und einfacher eindämmen lassen.

Umgang mit Schwachstellen in Open-Source-Software

Auch wenn alle Entwickler gerne glauben, perfekten Code zu schreiben, ist keine Software frei von Fehlern. Entwickler hoffen, dass die meisten Fehler im Rahmen eines strengen Qualitätssicherungsprozesses bereits während der Entwicklung erkannt werden und im Laufe der Lebensdauer der App bei normaler Nutzung nur wenige zutage treten. Im schlimmsten Fall werden Fehler von böswilligen Nutzern entdeckt, die damit unlautere Absichten verfolgen.

Die Auswirkungen von Fehlern verschärfen sich erheblich, wenn Sie Ihren Anwendungs-Stack aus mehreren Open-Source-Tools, Programmiersprachen und Plattformen zusammenstellen. Sie müssen jede Komponente einzeln überprüfen, um sicherzustellen, dass sie fehlerfrei ist. Wenn Fehler in Open-Source-Software entdeckt werden, ist es wichtig, über eine klar definierte Richtlinie für deren Validierung, Prüfung und – sofern möglich – Behebung zu verfügen.

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

1. Regelmäßige Überprüfung und Tests
2. Schwachstellen nachverfolgen und intern melden
3. Sicherheitslücken zeitnah beheben

Melden einer Sicherheitslücke

Wenn eine Sicherheitslücke entdeckt wird, gibt es ein standardisiertes Verfahren für ihre Offenlegung. Zunächst wird dem Autor oder Anbieter der Software ein detaillierter Bericht übermittelt. Die meldende Person und der Autor entscheiden gemeinsam, wie und wann die Sicherheitslücke offengelegt wird, üblicherweise in Form eines Eintrags in der Common Vulnerabilities and Exposures-Datenbank (CVE). Üblicherweise hat der Autor 90 Tage Zeit, das Problem vor der Offenlegung zu beheben. Es kann jedoch auch eine längere Frist vereinbart werden.

NGINX und CVEs

Als Anbieter von Open-Source-Software und kommerzieller Software beteiligt sich NGINX aktiv an der Meldung und Behebung von CVEs und anderen Sicherheitslücken, die NGINX Open Source und NGINX Plus sowie seine anderen kommerziellen Produkte betreffen – dazu gehören zum Zeitpunkt der Erstellung NGINX Controller [jetzt F5 NGINX Management Suite], NGINX App Protect und NGINX Ingress Controller – sowie kostenlose Open-Source-Angebote, darunter NGINX Service Mesh, NGINX Unit und NGINX Amplify.

Benutzer von NGINX Open Source profitieren davon, dass NGINX Plus darauf basiert, denn wir verpflichten uns gegenüber Kunden von NGINX Plus zu Support- und Prozessstandards auf Enterprise-Niveau. Zu diesen Standards gehören Service Level Agreements (SLAs) mit unseren Kunden, die Verfahren zur Fehlerbehebung und für Tests vorgeben, denen Patches entsprechen müssen – sowohl für die Kernsoftware als auch für Abhängigkeiten und unterstützte Module. Die SLAs helfen Kunden dabei, gesetzliche Vorschriften einzuhalten und das Risiko zu minimieren, dass Sicherheitslücken ausgenutzt werden.

Eine zusätzliche Herausforderung bei NGINX Open Source besteht darin, dass viele Technologien von Drittanbietern es nutzen und in ihre Produkte integrieren. Die Anbieter dieser Technologien verfügen über eigene Prozesse zur Offenlegung und Behebung von Softwareschwachstellen, sobald diese entdeckt werden. Wie wir im nächsten Abschnitt erläutern, vergeht zwischen unserer Veröffentlichung eines Patches für NGINX Open Source und der Veröffentlichung eines entsprechenden Patches für Technologien von Drittanbietern mitunter recht viel Zeit.

Wie NGINX Plus Abonnenten vor Sicherheitslücken schützt

In der Einleitung haben wir erwähnt, dass ein häufig übersehener Vorteil von NGINX Plus darin besteht, dass unsere Kunden sich damit schneller und einfacher vor Sicherheitslücken schützen können. Der Umgang mit Sicherheitslücken in Open-Source-Software kann wesentlich zeitaufwendiger – und damit kostspieliger – sein, als viele denken.

In den folgenden Abschnitten erläutern wir fünf konkrete Aspekte, die es Abonnenten von NGINX Plus ermöglichen, Sicherheitslücken schneller und einfacher zu beheben.

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. Außerdem veröffentlichen wir einen Blogbeitrag, in dem wir auf die Verfügbarkeit der meisten Patches hinweisen. Wir haben jedoch keine Möglichkeit, Benutzer von NGINX Open Source direkt zu erreichen. Daher müssen sie selbst CVEs und andere Schwachstellendatenbanken überwachen und regelmäßig unseren Blog lesen.

F5 SIRT bietet NGINX Plus-Abonnenten bei Angriffen Unterstützung in Echtzeit

Wenn F5-Kunden, darunter auch Abonnenten von NGINX Plus, Opfer von Angriffen werden, steht ihnen das F5 Security Incident Response Team (SIRT) in Echtzeit zur Seite. Das SIRT reagiert schnell, um Angriffe wirksam einzudämmen und den Betrieb wiederherzustellen. Auch nach dem Ende des Angriffs unterstützt das Team Sie weiterhin – es „blickt über den gemeldeten Vorfall hinaus, um den Gesamtschaden für Ihr Unternehmen zu begrenzen sowie zukünftige Bedrohungen zu verstehen, vorherzusehen und abzuwehren“.

NGINX App Protect verbessert den Anwendungsschutz

NGINX App Protect ist eine Web Application Firewall (WAF) der Enterprise-Klasse, die auf der 20-jährigen Sicherheitserfahrung von F5 basiert und als dynamisches Modul für NGINX Plus bereitgestellt wird. Sie erweitert die Layer-7-Sicherheit von NGINX Plus um anwendungsspezifischen Schutz vor noch mehr CVEs auf Ihren Backend-Anwendungsservern. NGINX und F5 stellen gezielt Signaturen für bestimmte Angriffskampagnen bereit. Das Ergebnis? NGINX App Protect erspart Abonnenten von NGINX Plus, eigene Signaturen zu erstellen und sich mit zahlreichen Fehlalarmen auseinanderzusetzen.

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

Auch wenn keine konkreten Schwachstellen vorliegen, die Patches erfordern, tragen ausgefeilte Authentifizierungsprotokolle dazu bei, unbefugte Zugriffe auf Ihre Anwendungen und Infrastruktur zu verhindern. Zusätzlich zu den in NGINX Open Source verfügbaren Methoden unterstützt NGINX Plus die Authentifizierung auf Basis von JSON Web Token (JWT) und OpenID Connect – sowohl für Web- als auch für API-Clients.

Abonnenten von NGINX Plus erhalten Patches sofort

Wie unter Melden einer Sicherheitslücke beschrieben, werden wir in der Regel benachrichtigt, bevor eine Sicherheitslücke, die NGINX-Software betrifft, öffentlich als CVE bekannt gegeben wird. Dank dieser Vorabinformation können wir bereits vor der öffentlichen Bekanntgabe einen Patch vorbereiten, den wir üblicherweise am Tag der Bekanntgabe veröffentlichen (in einigen Fällen auch innerhalb weniger Tage danach). NGINX Plus-Kunden erhalten die Fehlerbehebung in Form gepatchter Binärdateien. Für Benutzer von NGINX Open Source steht sie in Form von korrigiertem Quellcode und gepatchten 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.

Drittanbietertechnologien, die NGINX Open Source nutzen oder einbetten, erfahren möglicherweise erst nach der Offenlegung von der Sicherheitslücke. Selbst wenn sie vorher davon erfahren, zeigt unsere Erfahrung, dass ihre Patches dem NGINX-Patch um mehrere Monate hinterherhinken können. Das ist verständlich, insbesondere bei Open-Source-Software, die häufig von Freiwilligen gepflegt wird. Allerdings bleibt Ihre Infrastruktur dadurch nach der öffentlichen Bekanntgabe der Sicherheitslücke ungeschützt und kann von Hackern ausgenutzt werden.

Beispielsweise wurden im Herbst 2018 zwei CVEs zu Sicherheitslücken in HTTP/2 entdeckt (CVE-2018-16843 und CVE-2018-16844). Als Reaktion darauf stellten wir Sicherheitspatches für NGINX Plus R16 und NGINX Open Source 1.15.6 bereit. Die beliebte Software OpenResty, die auf NGINX Open Source aufbaut und einen Teil der Funktionen von NGINX Plus bereitstellt, veröffentlichte erst am 3. März 2019 einen Release Candidate, der diese Patches enthielt – ganze vier Monate nach dem Patch von NGINX. Bei Lösungen, die auf OpenResty aufbauen, dauert es dann in der Regel noch länger, bis ihre Codebasis gepatcht wird.

Manchmal ist der Status einer Schwachstelle unklar oder der Softwareanbieter hält einen Patch nicht für erforderlich, selbst wenn die Schwachstelle einen potenziellen Angriffsvektor darstellt. Eine solche Situation trat 2020 bei ModSecurity auf, der am weitesten verbreiteten Open-Source-WAF-Software. Das Team, das das OWASP ModSecurity Core Rule Set (CRS) pflegt, stellte fest, dass die Art und Weise, wie ModSecurity v3 reguläre Ausdrücke global abgleicht, zu einer vom OWASP-CRS-Team als Denial-of-Service-Schwachstelle (CVE-2020-15598) eingestuften Sicherheitslücke führen kann. Trustwave, das Unternehmen, das ModSecurity selbst pflegt, bestritt, dass dieses Verhalten ein Sicherheitsproblem darstellt, und lehnte die Veröffentlichung eines Patches ab.

NGINX ModSecurity WAF ist ein dynamisches Modul für NGINX Plus, das auf ModSecurity v3 basiert. Das NGINX-Team kam zu dem Schluss, dass das in CVE-2020-15598 beschriebene Verhalten ein ausreichend großes Potenzial für eine DoS-Schwachstelle birgt, sodass wir im September 2020 einen Patch veröffentlichten. Wie wir im Blogbeitrag zur Ankündigung des Patches erläutert haben, müssen Benutzer eines Open-Source-Builds von ModSecurity (einschließlich der Benutzer von NGINX Open Source) selbst entscheiden, ob sie den Patch des OWASP-CRS-Teams anwenden oder weiterhin die ungepatchte Software von Trustwave verwenden und gegebenenfalls die von Trustwave vorgeschlagenen Maßnahmen zur Risikominderung umsetzen.

[Redaktion – Der Verkauf von NGINX ModSecurity WAF wurde zum 1. April 2022 offiziell eingestellt. Zum 31. März 2024 erreicht das Produkt das Ende seines Lebenszyklus. Weitere Informationen finden Sie im Beitrag F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> in unserem Blog.]

Fazit

In der heutigen, zunehmend wettbewerbsintensiven Geschäftswelt stehen Softwareteams unter dem Druck, neuen und aktualisierten Code so schnell wie möglich bereitzustellen, um besonders innovative Services anbieten zu können. Gleichzeitig macht die Zunahme ausgefeilter Angriffe auf Infrastrukturen und Anwendungen es unerlässlich, Schwachstellen zu verfolgen und so schnell wie möglich zu beheben – eine mühsame und zeitaufwendige Aufgabe.

Ein NGINX Plus-Abonnement nimmt ihnen diese Last ab, sodass sich Anwendungsteams auf ihre Hauptaufgabe konzentrieren können – Code schneller bereitzustellen –, während das Unternehmen weiterhin vor Sicherheitslücken geschützt bleibt.

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

Über den Autor

Laurent Pétroque

Weitere Blogbeiträge von Laurent Pétroque