Am 14. April veröffentlichte Microsoft eine Sicherheitswarnung – die inzwischen unter CVE-2015-1635 geführt wird – zu einer Schwachstelle, die möglicherweise die Ausführung von Remotecode ermöglicht, wenn ein Angreifer eine speziell präparierte HTTP-Anfrage an ein betroffenes Windows-System sendet. Wenn Sie Ihre produktiven Windows-Server nicht sofort patchen können, können NGINX und NGINX Plus Sie vor Angriffen schützen.
Zum Zeitpunkt der Erstellung dieses Artikels wurden noch keine konkreten Details zu der Sicherheitslücke veröffentlicht. Berichten zufolge versuchen Angreifer jedoch, anfällige Systeme zu finden, indem sie HTTP-Anfragen mit sehr großen Range-Headern senden. Dies kann einen Pufferüberlauf auslösen und das Windows-System zum Absturz bringen.
Benutzern wird dringend empfohlen, den Patch von Microsoft anzuwenden, um diese Sicherheitslücke zu schließen. Wenn Sie den Patch jedoch nicht auf allen Ihren Produktionssystemen installieren können und NGINX oder NGINX Plus für den Lastenausgleich oder als Proxy für den Datenverkehr zu diesen Systemen verwenden, genügt eine einfache Konfigurationsänderung, um die speziellen Anfragen an anfällige Systeme abzufangen und zu korrigieren.
Aufklärungsverkehr erkennen und verarbeiten
Mattias Geniar hat den Angriffsverkehr analysiert und berichtet, dass HTTP-Anfragen mit einem großen Bytebereich im Range-Header den Absturz auslösen:
GET / HTTP/1.1rnHost: stuffrn
Range: bytes=0-18446744073709551615rn
rnDie einfachste Lösung besteht darin, mit der Direktive „proxy_set_header“ den Header „Range“ auf "" (die leere Zeichenfolge) zu setzen. Dadurch wird der Header praktisch gelöscht, bevor die HTTP-Anfrage an den Windows-Server weitergeleitet wird, der in der Direktive „proxy_pass“ angegeben ist:
server { listen 80;
location / {
proxy_set_header Range "";
proxy_pass http://windowsserver:80;
}
}Wenn Ihre Anwendung Bytebereichsanfragen unterstützen muss, können Sie die Direktive map verwenden, um jede Zeichenfolge, die einer großen Ganzzahl ähnelt, durch eine leere Zeichenfolge zu ersetzen, bevor Sie mit der Direktive proxy_set_header den Header Range festlegen:
map $http_range $saferange { "~d{10,}" ""; # if it matches a string of 10 or more integers, remove it
default $http_range;
}
server {
listen 80;
location / {
proxy_set_header Range $saferange;
proxy_pass http://windowsserver:80;
}
}Alternativ können Sie den HTTP-Code 444 zurückgeben, wenn der Wert im Range-Header einer großen Ganzzahl ähnelt. Der Code 444 weist NGINX und NGINX Plus an, die Clientverbindung sofort zu schließen, ohne etwas zurückzugeben.
server { listen 80;
if ($http_range ~ "d{9,}") {
return 444;
}
location / {
proxy_pass http://windowsserver:80;
}
}Schützen Sie sich und installieren Sie den Patch. Falls dies jedoch nicht sofort möglich ist, können NGINX und NGINX Plus dabei helfen, die potenzielle Sicherheitslücke vorübergehend zu schließen.
Wenn Sie NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns für eine Demo.
Über den Autor

Ä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.