Ankündigung von NGINX Plus R25

Zach WestallSenior Product Marketing Manager

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 25 (R25) bekannt zu geben. Basierend auf NGINX Open Source ist NGINX Plus die einzige All-in-One-Softwarelösung, die Webserver, Load Balancer, Reverse Proxy, Content-Cache und API-Gateway vereint.

Zu den neuen Funktionen in NGINX Plus R25 gehören:

• Zusätzliche, komplexere Anwendungsfälle für JSON Web Tokens – NGINX Plus R25 baut auf der mit NGINX Plus R24 eingeführten Unterstützung für verschlüsselte JSON Web Tokens (JWE) auf.
• Detailliertere Berichterstattung zu HTTP-Antwortcodes – Die NGINX Plus-API zählt HTTP-Antwortcodes jetzt sowohl einzeln als auch zusammengefasst nach Klasse. Möglicherweise müssen Sie die Speicherzuweisung erhöhen; siehe Ausreichend Speicher zuweisen, um Startfehler zu vermeiden.
• Dynamisches Laden von SSL/TLS-Clientzertifikaten für Proxy-Verbindungen – Mithilfe von Variablen können Sie die Zertifikate für mTLS-Verbindungen zwischen NGINX Plus und Backend-Servern dynamisch auswählen.
• Erhöhte Sicherheit bei der Verarbeitung von HTTP-Anfragen – NGINX Plus führt mehrere zusätzliche Prüfungen von HTTP-Anfragen durch, um Ihre Anwendungen vor potenziellen Angriffen zu schützen.
• Beibehaltung des Status von Systemdiagnosen bei Konfigurationsneuladungen für TCP/UDP-Anwendungen – Die Ergebnisse obligatorischer Systemdiagnosen für TCP/UDP-Server bleiben nun auch nach dem Neuladen der Konfiguration erhalten.
• Verbesserungen am NGINX-JavaScript-Modul – Die Kompatibilität mit JavaScript ES6 wurde verbessert.

Wichtige Verhaltensänderungen

Erhöhter Speicherbedarf für Upstream-Zonen

Wie ausführlich unter Detailliertere Berichterstattung zu HTTP-Antwortcodes beschrieben, stellt NGINX Plus R25 sowohl Zählwerte für einzelne Statuscodes als auch aggregierte Zählwerte pro Klasse bereit. Wenn NGINX Plus als Reverse-Proxy oder Load-Balancer konfiguriert ist, müssen Sie möglicherweise die Größe der Shared-Memory-Zone erhöhen, die zur Überwachung von Upstream-„Peers“ (Backend-Servern) verwendet wird, sofern mehr als 20 Peers vorhanden sind.

NGINX Plus R25 startet nicht, wenn den Shared-Memory-Zonen zu wenig Speicher zugewiesen wurde, wodurch Upgrades fehlschlagen. Vor dem Upgrade muss unbedingt die Speicherauslastung jeder Upstream-Zone überprüft werden. Anweisungen zum Überprüfen und Anpassen der Speicherzuweisung finden Sie unter „Ausreichend Speicher zuweisen, um Startfehler zu vermeiden“.

Änderungen an der Repository-Struktur und am Installationsverfahren von NGINX Plus

Mit der Veröffentlichung von NGINX Plus R24 wurden die Paket-Repositorys für sämtliche NGINX-Software neu organisiert, wodurch sich das Installationsverfahren für NGINX Plus änderte.

Wenn Sie NGINX Plus installieren oder aktualisieren, wird der Paketmanager des Betriebssystems (apt, yum oder ein vergleichbarer Paketmanager) mit dem Software-Repository für NGINX Plus konfiguriert. Auf bestehenden Systemen, die für die Verwendung des alten Repositorys konfiguriert sind (auf denen NGINX Plus R23 oder eine frühere Version ausgeführt wird), müssen Sie den Paketmanager so aktualisieren, dass er auf das neue Repository verweist. Eine Anleitung finden Sie in der F5-Wissensdatenbank.

Wenn Sie NGINX Plus R25 erstmalig installieren, lesen Sie Installing NGINX Plus im NGINX Plus-Administratorhandbuch.

Hinweis: Sie müssen das neue Software-Repository verwenden. Das alte Repository wird nicht mehr aktualisiert und kann bei zukünftigen Installationen und Upgrades zu Fehlern führen.

Veraltetes Cookie-Flag-Modul

Wie bei der Veröffentlichung von NGINX Plus R23 angekündigt, ist das Cookie-Flag-Modul eines Drittanbieters veraltet und wird in NGINX Plus R26 aus dem Repository für dynamische Module entfernt. Die in diesem Modul definierte Direktive set_cookie_flag wird durch die integrierte Direktive proxy_cookie_flags ersetzt. Wir empfehlen, alle set_cookie_flag-Direktiven in Ihrer Konfiguration so bald wie möglich durch proxy_cookie_flags-Direktiven zu ersetzen.

Änderungen bei der Plattformunterstützung

• Neu unterstützte Betriebssysteme:
  • Debian 11 (x86_64, aarch64)
  • Alpine Linux 3.14 (x86_64, aarch64)
• Ältere Betriebssysteme entfernt:
  • Alpine Linux 3.10; älteste unterstützte Version ist 3.11
  • Amazon Linux 1 (2018.03+); wechseln Sie zu Amazon Linux 2 LTS
  • FreeBSD 11.4+; älteste unterstützte Version ist 12.1+
  • Ubuntu 16.04 LTS; älteste unterstützte Version ist 18.04 LTS
• Ältere Betriebssysteme, die als veraltet eingestuft wurden und deren Unterstützung in NGINX Plus R26 eingestellt werden soll:
  • Alpine Linux 3.11

Neue Funktionen im Detail

Zusätzliche Anwendungsfälle und Funktionen für JSON Web Tokens

NGINX Plus R24 führte eine erste Unterstützung ein für verschlüsselte JSON Web Tokens (JWE) und ergänzte damit eine der beliebtesten Methoden zur Clientauthentifizierung um die Vertraulichkeit von Daten. NGINX Plus R25 baut auf dieser Funktion auf und unterstützt zusätzliche und komplexere Authentifizierungsszenarien, die die Sicherheit der JWT-basierten Authentifizierung sowohl bei signierten (JWS) als auch bei verschlüsselten (JWE) Anwendungsfällen verbessern. Die Erweiterungen verringern das Risiko, dass personenbezogene Daten (PII) offengelegt werden, und bieten zugleich mehr Flexibilität. Zu den neuen JWT-Funktionen und Erweiterungen für NGINX Plus gehören:

• Eine neue Variable für entschlüsselten JWE-Chiffretext
• Unterstützung für verschachtelte JWTs
• Asymmetrische Verschlüsselung für JWE
• Unterstützung für JSON Web Keys aus mehreren Quellen
• Zusätzliche benutzerdefinierte JWT-Validierungsregeln

Variable für entschlüsselten JWE-Chiffretext

JWTs sind eine weitverbreitete und bewährte Methode zur zustandslosen Authentifizierung von HTTP-Anfragen (also zur tokenbasierten Authentifizierung). Durch die Übertragung von Endbenutzerattributen in der Token-Nutzlast tragen JWTs dazu bei, Anfragen sicherer zu machen. Sicherheitsforscher und DevSecOps-Fachleute sind sich jedoch einig, dass das Speichern unverschlüsselter personenbezogener Daten auf Webclients ein dringendes Risiko darstellt – daher wurde der Standard JSON Web Encryption (RFC 7516) entwickelt, der Richtlinien für die Implementierung verschlüsselter Token bereitstellt.

NGINX Plus R24 führte die Unterstützung für JWE ein und gewährleistet damit die Datenintegrität und Vertraulichkeit des gesamten Anspruchssatzes. Die Kodierung personenbezogener Daten (PII) im verschlüsselten Token verringert das Risiko von Datenlecks bei der Verwendung von JWTs erheblich.

NGINX Plus R25 erweitert die ursprüngliche JWE-Unterstützung um eine neue Variable, $jwt_payload, mit der NGINX Plus das JWE und den Chiffretext entschlüsseln und anschließend bei der Verarbeitung der HTTP-Anfrage auf den Klartext zugreifen kann. Diese neue Funktionalität kann zur Implementierung erweiterter Richtlinien für die Zugriffskontrolle und Entscheidungen zur Anfrageweiterleitung verwendet werden. Außerdem können Benutzer NGINX Plus als JWE-Entschlüsselungsschicht für Backend-Anwendungen einsetzen.

Unterstützung für verschachtelte JWTs

JWE-Token schützen personenbezogene Daten wirksam, da der Chiffretext die Vertraulichkeit selbst bei der Übertragung über CDNs und andere Proxys mit TLS-Terminierung wahrt. Verschlüsselung ist jedoch ein zweischneidiges Schwert, da JWEs die Anwendungsumgebung komplexer machen können. Dieses Problem lässt sich durch den Einsatz verschachtelter JWTs lösen.

Aufbau eines verschachtelten JWT

Verschachtelte JWTs betten JWS als Chiffretext einer JWE ein. NGINX Plus R25 ermöglicht die Verwendung verschachtelter JWTs zur Authentifizierung von HTTP-Anfragen, indem JWS und JWE gleichzeitig unterstützt werden. NGINX Plus kann nun in einem einzigen Vorgang den Chiffretext in der JWE entschlüsseln, den daraus resultierenden Klartext als JWS validieren und anhand der Claims exp (Ablaufzeit) und nbf (nicht vor) im enthaltenen Token überprüfen, ob dieser gültig ist. Dadurch kann eine bestehende JWS-Umgebung um eine Nutzdatenverschlüsselung erweitert werden, indem sie in eine JWE eingebettet wird.

Der folgende Konfigurationsausschnitt veranschaulicht den Vorgang. Der neue Parameter „nested“ der Direktive „auth_jwt_type“ weist NGINX Plus an, sowohl die JWE-Entschlüsselung als auch die JWS-Validierung durchzuführen. Er wirkt sich außerdem darauf aus, wie die Variablen für JWT-Header und JWT-Claims ausgewertet werden:

• Die auth_jwt_header_set-Direktive verarbeitet die äußeren JWE-Header.
• Die auth_jwt_claim_set-Direktive verarbeitet die Ansprüche des verschachtelten JWS.
• $jwt_header_name-Variablen enthalten die Header-Eigenschaften der äußeren JWE.
• $jwt_claim_name-Variablen enthalten die Claims des verschachtelten JWS.

Codebeispiel wird geladen…

Mit der folgenden Konfiguration erstellt NGINX Plus zusätzliche HTTP-Anfrageheader und sendet sie an die Backend-Anwendung. Der Verschlüsselungsalgorithmus aus dem JWE-Header (die Variable $jwt_header_enc) und der JWT-Subjektanspruch aus der JWS-Nutzlast (die Variable $jwt_claim_sub) werden zusammen mit der ursprünglichen Anfrage weitergeleitet. Dadurch können Anwendungen die JWE-basierte Authentifizierung einfach durch Auswertung der HTTP-Header nutzen, ohne kryptografischen Code oder entsprechende Bibliotheken implementieren zu müssen.

Codebeispiel wird geladen…

Für Benutzer, die Zero-Trust-Architekturen einsetzen, ermöglicht die folgende Konfiguration der Backend-Anwendung, das JWS-Token zu validieren, das in der Variable $jwt_payload erfasst wurde. Die Variable enthält die entschlüsselte Klartextversion des JWE-Chiffretexts. Wenn ein verschachteltes JWT vorhanden ist, kann das JWS als Bearer-Token an die Backend-Anwendung übergeben werden.

Codebeispiel wird geladen…

Im Wesentlichen optimieren verschachtelte JWTs die Abläufe und verbessern die Anwendungssicherheit, da NGINX Plus sichere Token gleichzeitig entschlüsseln und validieren kann, während das signierte „reguläre JWT“-Token für Backend-Anwendungen geparst oder per Proxy weitergeleitet wird.

Asymmetrische Verschlüsselung für JWE

NGINX Plus R24 führte die Unterstützung für die symmetrische Verschlüsselung von Token nach dem AES-Standard ein. NGINX Plus R25 ergänzt die Unterstützung für asymmetrische Verschlüsselung mit RSA-Schlüsselpaaren. Bei der asymmetrischen Kryptografie werden für die Ver- und Entschlüsselung unterschiedliche Schlüssel (öffentlicher und privater Schlüssel) verwendet, die durch den RSA-Algorithmus (Rivest–Shamir–Adleman) mathematisch miteinander verknüpft sind. Derselbe Mechanismus wird auch für die SSL/TLS-Verschlüsselung des HTTPS-Datenverkehrs zwischen Client und Server verwendet.

NGINX Plus R25 unterstützt RSA mit Optimal Asymmetric Encryption Padding (OEAP) als Schlüsselverwaltungsalgorithmus, ohne dass aufseiten von NGINX Plus eine explizite Konfiguration erforderlich ist. Unterstützte Werte für den JWS-Header alg (Algorithmus) sind RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384 und RSA-OAEP-512.

Die folgende Konfiguration zeigt, dass zur Implementierung der asymmetrischen Verschlüsselung für JWE lediglich die JSON-Web-Key-Datei (JWK), die die privaten RSA-Schlüssel zum Entschlüsseln (Unwrapping) enthält, als Parameter für die Direktive auth_jwt_key_file angegeben werden muss (alternativ kann auch die Direktive auth_jwt_key_request verwendet werden).

Codebeispiel wird geladen…

Unterstützung für JWKs aus mehreren Quellen

Die Verwendung verschachtelter JWTs bedeutet, dass die zugehörigen JWKs wahrscheinlich aus mehreren Quellen stammen. NGINX Plus R25 unterstützt mehrere auth_jwt_key_file‑ und auth_jwt_key_request‑Direktiven im selben Kontext. NGINX Plus lädt Schlüssel aus allen angegebenen Quellen und sucht im zusammengeführten Schlüsselsatz nach dem passenden Verifizierungsschlüssel. Dies ist äußerst nützlich, wenn eine von einem externen Identitätsanbieter ausgestellte JWS in einer JWE verschachtelt ist, deren Verschlüsselung durch einen separaten Prozess erfolgte.

Diese Funktion verleiht NGINX Plus beim Einsatz als API-Gateway noch mehr Flexibilität, Sicherheit und Leistungsfähigkeit.

Benutzerdefinierte JWT-Validierungsregeln

Wenn NGINX Plus als API-Gateway eingesetzt wird, werden häufig JWT-Claims geprüft, um eine differenzierte Zugriffskontrolle zu implementieren. Dies kann zu komplexen Konfigurationen führen. In früheren Versionen von NGINX Plus konnten Sie if-Konfigurationsblöcke verwenden, um JWT-Claims auszuwerten. Dieser Ansatz war jedoch etwas eingeschränkt und funktionierte nicht bei verschlüsselten Tokens.

NGINX Plus R25 behebt diese Einschränkung, indem es eine native Möglichkeit bietet, während des JWT-Validierungsprozesses zusätzliche Prüfungen des Tokens durchzuführen. Die auth_jwt_require-Direktive fügt dem JWT-Validierungsprozess einen optionalen, anpassbaren Schritt hinzu. Sie akzeptiert eine durch Leerzeichen getrennte Liste von Zeichenfolgen, die alle nicht leer sein dürfen und nicht gleich 0 (null) sein dürfen, damit die JWT-Validierung erfolgreich ist. Dies verleiht dem JWT-Validierungsprozess enorme Flexibilität.

Der JWT-Standard schreibt nicht vor, welche Claims obligatorisch sind. Daher können Sie mit auth_jwt_require die für die jeweilige Umgebung geeigneten Claims auflisten.

Die folgende Konfiguration stellt sicher, dass sowohl der Anspruch exp als auch der Anspruch sub in jedem Token vorhanden sind.

Codebeispiel wird geladen…

Komplexere Anwendungsfälle können Sie mithilfe von map-Blöcken oder des Schlüssel-Wert-Speichers von NGINX Plus konfigurieren, um boolesche Werte an die Direktive auth_jwt_require zu übergeben. Sie können auch das NGINX-JavaScript-Modul verwenden, um umfassende Authentifizierungslösungen zu implementieren, beispielsweise an Clientzertifikate gebundene Zugriffstoken für gegenseitiges TLS (mTLS) (definiert in RFC 8705).

Die folgende Konfiguration führt sowohl eine Clientzertifikatsauthentifizierung (mTLS) als auch eine JWT-Validierung durch. Die Direktive „auth_jwt_require“ in Zeile 14 veranlasst die Auswertung der Variablen „$thumbprint_match“. Die JWT-Validierung ist nur erfolgreich, wenn diese einen Wert ungleich null aufweist. Die Variable wird durch Ausführen der in Zeile 2 aufgerufenen JavaScript-Funktion ausgewertet.

Codebeispiel wird geladen…

Hier ist der Code für die Funktion „validate“, die in Zeile 2 des vorherigen Codeausschnitts aufgerufen wird:

Codebeispiel wird geladen…

Detailliertere Berichterstattung zu HTTP-Antwortcodes

Monitoring und Transparenz sind Grundpfeiler für die Performance, Verfügbarkeit und Sicherheit von Anwendungen. HTTP-Antwortcodes gehören zu den wichtigsten Informationsquellen für den Zustand einer Anwendung. Die NGINX Plus API erfasst HTTP-Antwortcodes sowohl für die Kommunikation zwischen NGINX und Clients als auch zwischen NGINX und Upstream-Servern. Die jeweiligen Anzahlen werden auf den entsprechenden Registerkarten des NGINX Plus Dashboards zur Live-Aktivitätsüberwachung angezeigt.

In früheren Versionen der NGINX Plus API wurden die Anzahlen der HTTP-Antwortcodes nach Klassen zusammengefasst (2xx, 4xx usw.). Jetzt werden die Codes auch einzeln gezählt (200, 404, 503 usw.). Dadurch erhalten Sie einen genaueren Einblick in die Vorgänge innerhalb einer Anwendung und können zwischen Fehlern mit sehr unterschiedlichen Ursachen unterscheiden, etwa einem sprunghaften Anstieg fehlgeschlagener Authentifizierungen (403) und fehlenden Inhalten (404). Informationen zur Konfiguration der Metrikerfassung finden Sie im NGINX Plus Admin Guide.

Die neueste Version der NGINX Plus API (Version 7), die mit NGINX Plus R25 veröffentlicht wurde, enthält ein codes-Objekt innerhalb des responses-Objekts, mit dem einzelne HTTP-Antwortcodes gezählt werden können. Aggregierte Antworten sind weiterhin verfügbar, und frühere Versionen der NGINX Plus API, die kein codes-Objekt enthalten, können weiterhin mit NGINX Plus R25 verwendet werden. Hier ist ein Beispiel für den neuen Metriksatz:

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

Ausreichend Arbeitsspeicher zuweisen, um Startfehler zu vermeiden

Wichtiger Hinweis: Wenn NGINX Plus als Reverse-Proxy oder Load Balancer konfiguriert ist, erhöht die Zählung einzelner Codes die Speicherauslastung in der gemeinsam genutzten Speicherzone für jede Upstream-Gruppe. Wenn die Upstream-Gruppe mehr als 20 Peers enthält, müssen Sie möglicherweise die Speichergröße erhöhen, die mit der zone-Direktive konfiguriert wird.

NGINX Plus R25 startet nicht, wenn die Upstream-Zonen zu klein dimensioniert sind, wodurch Upgrades fehlschlagen.

Hier sehen Sie eine typische Konfiguration der Shared-Memory-Zone für eine Upstream-Gruppe:

Codebeispiel wird geladen…

Vor dem Upgrade auf NGINX Plus R25 sollten Sie unbedingt die Speicherauslastung der vorhandenen Upstream-Zonen überprüfen. Stellen Sie dazu sicher, dass die NGINX Plus API aktiviert ist bevor Sie eine der folgenden Methoden verwenden:

• Überprüfen Sie die Registerkarte „HTTP-Upstreams“ im Dashboard zur Live-Aktivitätsüberwachung, wie in diesem Beispiel von demo.nginx.com, in dem die Auslastung 54 % beträgt:
  
• Verwenden Sie die NGINX Plus API direkt auf dem Host, indem Sie den folgenden Befehl ausführen. Zunächst:

$ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; done

• Installieren Sie bei Bedarf das Dienstprogramm „jq“ if necessary
• Legen Sie die Variable „API“ auf den Speicherort fest, an dem die Direktive „api“ aktiviert ist.

Wenn die aktuelle Auslastung über 40 % liegt (wie im Screenshot), erhöhen Sie den zweiten Parameter (Größe) der zone-Direktive um mindestens das 2,5-Fache. Wir empfehlen beispielsweise, im obigen Konfigurationsausschnitt 64k auf 160k zu erhöhen.

Dynamisches Laden von SSL/TLS-Clientzertifikaten für Proxy-Verbindungen

Mutual TLS (mTLS) ist ein gängiges Authentifizierungsverfahren, bei dem die Identität sowohl des Clients als auch des Servers überprüft wird. Mit NGINX Plus können Sie die Server in einer Upstream-Gruppe dynamisch und mithilfe von Variablen definieren. Daher müssen Sie möglicherweise auch das TLS-Zertifikat, mit dem sich NGINX Plus gegenüber diesen Upstream-Servern authentifiziert, dynamisch auswählen können.

NGINX Plus R25 erweitert die für mTLS mit einem Backend-Server verwendeten Konfigurationsanweisungen, sodass sie eine Variable akzeptieren, die das Zertifikat repräsentiert. Die Variable kann auf eine der folgenden Optionen verweisen:

• Eine Datei auf der Festplatte
• Rohdaten im PEM-Format mit dem Präfix data:

Dadurch kann NGINX Plus ein Zertifikat und einen privaten Schlüssel dynamisch auswählen – ideal für moderne Anwendungsumgebungen, die sich ständig verändern. Sie können das Zertifikat und den privaten Schlüssel im Schlüssel-Wert-Speicher von NGINX Plus speichern. Dies erhöht die Sicherheit, da der private Schlüssel im Arbeitsspeicher statt auf der Festplatte gespeichert wird. Ein weiterer Anwendungsfall ist die automatisierte Zertifikatsrotation, bei der Sie Zertifikate über einen API-Aufruf im Schlüssel-Wert-Speicher aktualisieren.

In der folgenden Konfiguration leitet NGINX Plus Anfragen abhängig vom Hostnamen an verschiedene Upstream-Gruppen weiter. Die Proxy-Verbindung wird über mTLS hergestellt, wobei das passende Clientzertifikat für jeden Upstream dynamisch ausgewählt wird.

Codebeispiel wird geladen…

Die folgenden Direktiven unterstützen das dynamische Laden von Zertifikaten für mTLS mit Upstream-Servern:

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

Erhöhte Sicherheit bei der Verarbeitung von HTTP-Anfragen

Einer der zentralen Grundsätze der NGINX-Philosophie ist die kontinuierliche Verbesserung, insbesondere im Hinblick auf die Sicherheit. Wir nutzen alle verfügbaren Ressourcen, darunter die Zusammenarbeit mit Sicherheitsforschern, die Integration der branchenführenden Sicherheitstechnologien von F5 in unsere Produkte sowie interne Entwicklungsmaßnahmen.

Als Beispiel für Letzteres führt NGINX Plus R25 mehrere zusätzliche Prüfungen von HTTP-Anfragen durch, um Ihre Anwendungen vor potenziellen Angriffen zu schützen, beispielsweise vor Request Smuggling. Unter folgenden Bedingungen wird ein Fehler zurückgegeben:

• Eine HTTP/1.0-Anfrage enthält den Header „Transfer-Encoding“.
• Sowohl der Transfer-Encoding- als auch der Content-Length-Header ist vorhanden
• Die Anfragezeile oder ein Header-Name enthält Leer- oder Steuerzeichen
• Die Host-Kopfzeile enthält Leerzeichen oder Steuerzeichen.
• Die Methode „CONNECT“ wird verwendet

Darüber hinaus werden die folgenden Zeichen in einem über einen Proxy weitergeleiteten URI nun immer maskiert: ", <, >, \, ^, `, {, |, }.

Bitte beachten Sie, dass es sich bei diesen Änderungen um proaktive Sicherheitsverbesserungen handelt und sie nicht als Reaktion auf eine bekannte Sicherheitslücke vorgenommen wurden.

Beibehaltung des Status obligatorischer Integritätsprüfungen beim Neuladen von TCP-/UDP-Anwendungen

NGINX Plus verwendet obligatorische Integritätsprüfungen, um sicherzustellen, dass neue Server, die Upstream-Gruppen hinzugefügt werden, getestet und fehlerfrei sind, bevor Clientanfragen an sie weitergeleitet werden. In NGINX Plus R23 und früher wurden Upstream-Server nach dem Neuladen der Konfiguration unabhängig von ihrem Status vor dem Neuladen als fehlerhaft eingestuft. Daher leitete NGINX Plus erst dann Anfragen an einen Server weiter, nachdem die erste obligatorische Prüfung erfolgreich abgeschlossen worden war.

Mit NGINX Plus R24 wurde für HTTP-Anwendungen die optionale Beibehaltung des Status obligatorischer Integritätsprüfungen über Konfigurationsneuladungen hinweg eingeführt. Wenn die letzte obligatorische Integritätsprüfung vor einer Neuladung erfolgreich war, kann NGINX Plus Anfragen sofort an einen Server senden, anstatt auf den erfolgreichen Abschluss einer obligatorischen Integritätsprüfung nach der Neuladung warten zu müssen.

NGINX Plus R25 erweitert diese Funktionalität auf TCP/UDP-Anwendungen (im stream-Kontext). Fügen Sie wie bei HTTP der Direktive health_check neben dem Parameter mandatory auch den Parameter persistent hinzu.

Codebeispiel wird geladen…

Verbesserungen am NGINX-JavaScript-Modul

Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.6.2 aktualisiert und enthält mehrere Fehlerbehebungen sowie einige funktionale Verbesserungen, die die Kompatibilität mit JavaScript ES6 erhöhen.

Variablendeklaration mit den Schlüsselwörtern „let“ und „const“

NGINX JavaScript unterstützt jetzt die Deklaration von Variablen mit begrenztem Gültigkeitsbereich mithilfe der Schlüsselwörter let und const. Frühere Versionen von NGINX Plus und njs unterstützten zum Deklarieren und Zuweisen von Variablen nur das Schlüsselwort var. Damit konnten keine Variablen definiert werden, deren Gültigkeitsbereich auf eine bestimmte block-Anweisung beschränkt ist. Solche Variablen sind erforderlich, um die Komplexität zu bewältigen, die häufig entsteht, wenn verschiedene Projekte, Programmiersprachen und Entwicklungsteams gemeinsam an Codebasen oder Bibliotheken arbeiten.

JavaScript ES6 stellt die Schlüsselwörter let und const zum Definieren von Variablen mit begrenztem Gültigkeitsbereich bereit:

• let-Variablen sind auf den Gültigkeitsbereich einer block-Anweisung oder eines Ausdrucks beschränkt, in dem sie verwendet werden. Im Gegensatz dazu deklariert das Schlüsselwort var eine Variable global oder lokal für eine gesamte Funktion, unabhängig vom Block-Gültigkeitsbereich.
• const-Variablen haben wie mit dem Schlüsselwort let deklarierte Variablen einen Block-Gültigkeitsbereich. Der Wert einer Konstanten kann nicht durch eine erneute Zuweisung geändert und die Konstante nicht erneut deklariert werden.

Unterstützung für alle Promise-Konstruktormethoden

Durch die Ergänzung der Konstruktormethoden Promise.all(), Promise.allSettled(), Promise.any(), und Promise.race() unterstützt njs nun den vollständigen Satz der im JavaScript-ES6-Standard definierten Konstruktormethoden.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R25 durchzuführen. Dadurch erhalten Sie außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über den Autor

Zach WestallSenior Product Marketing Manager

Weitere Blogbeiträge von Zach Westall