Dieser Blogbeitrag befasst sich mit einer kürzlich entdeckten Schwachstelle im Zusammenhang mit dem HTTP/2-Protokoll. Unter bestimmten Bedingungen kann diese Schwachstelle ausgenutzt werden, um einen Denial-of-Service-Angriff auf NGINX Open Source, NGINX Plus und verwandte Produkte durchzuführen, die den serverseitigen Teil der HTTP/2-Spezifikation implementieren. Um Ihre Systeme vor diesem Angriff zu schützen, empfehlen wir, Ihre NGINX-Konfiguration umgehend zu aktualisieren.
Das Problem mit dem Zurücksetzen von HTTP/2-Streams
Nachdem eine Verbindung zu einem Server hergestellt wurde, ermöglicht das HTTP/2-Protokoll Clients, mehrere Streams für den Datenaustausch gleichzeitig zu starten. Anders als bei früheren Versionen des Protokolls bietet HTTP/2 eine Möglichkeit, den Stream abzubrechen, wenn ein Endnutzer die Seite verlässt oder den Datenaustausch aus einem anderen Grund beendet. Dazu sendet es einen RST_STREAM-Frame an den Server und verhindert so, dass dieser unnötige Arbeit ausführt.
Die Schwachstelle wird ausgenutzt, indem über eine bestehende Verbindung eine große Anzahl von HTTP/2-Streams initiiert und schnell wieder abgebrochen wird. Dadurch wird die maximale Anzahl gleichzeitiger Streams des Servers umgangen. Dies ist möglich, weil eingehende Streams schneller zurückgesetzt werden, als nachfolgende Streams eintreffen. So kann der Client den Server überlasten, ohne dass der konfigurierte Schwellenwert jemals erreicht wird.
Auswirkungen auf NGINX
Aus Gründen der Leistung und des Ressourcenverbrauchs begrenzt NGINX die Anzahl gleichzeitiger Streams standardmäßig auf 128 (siehe http2_max_concurrent_streams). Um Netzwerk- und Serverleistung optimal auszubalancieren, ermöglicht NGINX dem Client außerdem standardmäßig, HTTP-Verbindungen mithilfe von HTTP-Keepalive für bis zu 1000 Anfragen aufrechtzuerhalten (siehe keepalive_requests).
Durch die Verwendung des standardmäßigen Keepalive-Limits verhindert NGINX diese Art von Angriff. Wenn zusätzliche Verbindungen erstellt werden, um dieses Limit zu umgehen, können böswillige Akteure mit gängigen Überwachungs- und Warnwerkzeugen für Schicht 4 erkannt werden.
Wenn NGINX jedoch mit einem Keepalive-Wert konfiguriert ist, der deutlich über der standardmäßigen und empfohlenen Einstellung liegt, kann der Angriff die Systemressourcen erschöpfen. Wird ein Stream zurückgesetzt, schreibt das HTTP/2-Protokoll vor, dass anschließend keine weiteren Daten über diesen Stream an den Client zurückgegeben werden. In der Regel verursacht das Zurücksetzen lediglich einen vernachlässigbaren Server-Overhead in Form von Aufgaben, die den Abbruch ordnungsgemäß verarbeiten. Durch das Umgehen des Stream-Grenzwerts von NGINX kann ein Client diesen Overhead jedoch ausnutzen und verstärken, indem er in kurzer Folge Tausende von Streams initiiert. Dadurch steigt die CPU-Auslastung des Servers sprunghaft an, sodass legitimen Clients der Dienst verweigert wird.
Denial-of-Service durch den Aufbau von HTTP/2-Streams mit anschließender Beendigung der Streams bei ungewöhnlich hohen Keepalive-Grenzwerten.
Maßnahmen zur Verringerung der Angriffsfläche
Als voll ausgestatteter Server und Proxy stellt NGINX Administratoren leistungsstarke Werkzeuge zur Abwehr von Denial-of-Service-Angriffen bereit. Um diese Funktionen nutzen und die Angriffsfläche des Servers minimieren zu können, müssen die folgenden Änderungen an den NGINX-Konfigurationsdateien vorgenommen werden:
- keepalive_requests sollte auf der Standardeinstellung von 1000 Anfragen belassen werden
- http2_max_concurrent_streams sollte auf der Standardeinstellung von 128 Streams belassen werden
Wir empfehlen außerdem, diese Sicherheitsmaßnahmen als Best Practice hinzuzufügen:
- limit_conn begrenzt die Anzahl der zulässigen Verbindungen eines einzelnen Clients. Diese Direktive sollte mit einer angemessenen Einstellung hinzugefügt werden, die Anwendungsleistung und Sicherheit ausgewogen berücksichtigt.
- limit_req begrenzt die Anzahl der Anfragen, die innerhalb eines bestimmten Zeitraums von einem einzelnen Client verarbeitet werden. Diese Direktive sollte mit einer angemessenen Einstellung hinzugefügt werden, die ein ausgewogenes Verhältnis zwischen Anwendungsleistung und Sicherheit gewährleistet.
Wie wir darauf reagieren
Wir haben verschiedene Strategien zur Risikominderung erprobt, um besser zu verstehen, wie sich dieser Angriff auf unser breites Spektrum an Kunden und Benutzern auswirken könnte. Unsere Untersuchungen haben zwar bestätigt, dass NGINX bereits über alle erforderlichen Werkzeuge verfügt, um den Angriff abzuwehren, dennoch wollten wir zusätzliche Maßnahmen ergreifen, damit auch Benutzer, die NGINX über die empfohlenen Vorgaben hinaus konfigurieren müssen, dies tun können.
Unsere Untersuchung hat eine Methode zur Verbesserung der Ausfallsicherheit von Servern gegenüber verschiedenen Formen von Flood-Angriffen ergeben, die theoretisch über das HTTP/2-Protokoll möglich sind. Daher haben wir einen Patch veröffentlicht, der die Systemstabilität unter diesen Bedingungen erhöht. Zum Schutz vor solchen Bedrohungen empfehlen wir Benutzern von NGINX Open Source, die Binärdateien auf Grundlage der neuesten Codebasis neu zu erstellen, und Kunden von NGINX Plus, umgehend auf die neuesten Pakete (R29p1 oder R30p1) zu aktualisieren.
So funktioniert der Patch
Um Flooding-Angriffe auf NGINX frühzeitig zu erkennen, begrenzt der Patch die Anzahl neuer Streams, die innerhalb einer Ereignisschleife initiiert werden können. Dieses Limit entspricht dem Doppelten des Werts, der mit der Direktive „http2_max_concurrent_streams“ konfiguriert wurde. Das Limit gilt auch dann, wenn der maximale Schwellenwert nie erreicht wird, etwa wenn Streams unmittelbar nach dem Senden der Anfrage zurückgesetzt werden (wie bei diesem Angriff).
Betroffene Produkte
Diese Sicherheitslücke betrifft das NGINX-HTTP/2-Modul (ngx_http_v2_module). Informationen dazu, ob Ihr spezifisches NGINX- oder F5-Produkt betroffen sein könnte, finden Sie unter: https://my.f5.com/manage/s/article/K000137106.
Weitere Informationen zu CVE-2023-44487 – HTTP/2 Rapid Reset Attack finden Sie unter: https://www.cve.org/CVERecord?id=CVE-2023-44487
Danksagungen
Wir möchten Cloudflare, Amazon und Google für ihren Beitrag zur Entdeckung dieser Schwachstelle sowie für ihre Zusammenarbeit bei deren Identifizierung und Behebung danken.
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.