Ankündigung von NGINX Plus R25

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 25 (R25) bekannt zu geben. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Software-Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.

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

• Zusätzliche, erweiterte Anwendungsfälle für JSON Web Token – NGINX Plus R25 baut auf der Unterstützung für verschlüsselte JSON Web Tokens (JWE) auf, die in NGINX Plus R24 eingeführt wurde.
• Detailliertere Berichterstattung über HTTP-Antwortcodes – Die NGINX Plus-API zählt HTTP-Antwortcodes jetzt einzeln und aggregiert nach Klasse. Möglicherweise müssen Sie die Speicherzuweisung erhöhen (siehe „Zuweisen von ausreichend Speicher zur Vermeidung von Startfehlern“ ).
• Dynamisches Laden von SSL/TLS-Clientzertifikaten für Proxyverbindungen – Sie können Variablen verwenden, um die Zertifikate für mTLS-Verbindungen zwischen NGINX Plus und Backend-Servern dynamisch auszuwählen.
• Verstärkte Sicherheit für die Verarbeitung von HTTP-Anfragen – NGINX Plus führt mehrere zusätzliche Prüfungen der HTTP-Anfragen durch, um Ihre Anwendungen vor potenziellen Angriffen zu schützen.
• Persistenz des Integritätsprüfungsstatus über Neuladungen für TCP/UDP-Anwendungen hinweg – Die Ergebnisse obligatorischer Integritätsprüfungen von TCP/UDP-Servern können jetzt über Neuladungen der Konfiguration hinweg bestehen bleiben.
• Verbesserungen am NGINX JavaScript-Modul – Die Kompatibilität mit JavaScript ES6 wurde gestärkt.

Wichtige Verhaltensänderungen

Erhöhter Speicherbedarf für Upstreamzonen

Wie im Abschnitt „Genauere Berichterstattung über HTTP-Antwortcodes“ ausführlich beschrieben, ermöglicht NGINX Plus R25 die Zählung einzelner Statuscodes sowie die Gesamtzählung pro Klasse. Wenn NGINX Plus als Reverse-Proxy oder Load Balancer konfiguriert ist, müssen Sie möglicherweise die Größe der gemeinsam genutzten Speicherzone erhöhen, die zur Überwachung der Upstream-„Peers“ (Backend-Server) verwendet wird, wenn mehr als 20 Peers vorhanden sind.

NGINX Plus R25 startet nicht, wenn gemeinsam genutzte Speicherzonen nicht ausreichend bereitgestellt sind, was zu fehlgeschlagenen Upgrades führt. Vor dem Upgrade ist es wichtig, die Speicherauslastung jeder Upstream-Zone zu überprüfen. Anweisungen zum Überprüfen und Anpassen der Speicherzuweisung finden Sie unter Zuweisen von ausreichend Speicher, um Startfehler zu vermeiden .

Änderungen an der NGINX Plus Repo-Organisation und dem Installationsverfahren

Bei der Veröffentlichung von NGINX Plus R24 wurden die Paket-Repositorys für die gesamte NGINX-Software neu organisiert, was zu Änderungen am Installationsverfahren von NGINX Plus führte.

Wenn Sie NGINX Plus installieren oder aktualisieren, wird der Paketmanager des Betriebssystems ( apt , yum oder gleichwertig) mit dem Software-Repository für NGINX Plus konfiguriert. Auf vorhandenen Systemen, die für die Verwendung des alten Repo konfiguriert sind (auf denen NGINX Plus R23 oder früher ausgeführt wird), müssen Sie den Paketmanager aktualisieren, um auf das neue Repo zu verweisen. Anweisungen finden Sie in der F5-Wissensdatenbank .

Wenn Sie eine Erstinstallation von NGINX Plus R25 durchführen, finden Sie weitere Informationen unter Installieren von NGINX Plus im NGINX Plus-Administratorhandbuch .

Notiz: Sie müssen das neue Software-Repository verwenden. Das alte Repo wird nicht mehr aktualisiert und kann bei zukünftigen Installationen und Upgrades Fehler verursachen.

Veraltetes Cookie-Flag-Modul

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

Änderungen an der Plattformunterstützung

• Neue 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+); Wechsel 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 veraltet sind und deren Entfernung in NGINX Plus R26 vorgesehen ist:
  • Alpine Linux 3.11

Neue Features im Detail

Weitere Anwendungsfälle und Funktionen für JSON Web Token

NGINX Plus R24 führte erstmals Unterstützung für verschlüsselte JSON Web Tokens (JWE) ein und erweiterte damit eine der beliebtesten Methoden der Client-Authentifizierung um Datenvertraulichkeit. NGINX Plus R25 baut auf dieser Fähigkeit auf und führt Unterstützung für zusätzliche und erweiterte Authentifizierungsanwendungsfälle ein, die dazu beitragen, die Sicherheit der JWT-basierten Authentifizierung sowohl für signierte (JWS) als auch für verschlüsselte (JWE) Anwendungsfälle zu verbessern. Die Verbesserungen verringern das Risiko des Verlusts personenbezogener Daten (PII) und bieten mehr Flexibilität. Die neuen JWT-Funktionen und Verbesserungen für NGINX Plus umfassen:

• 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-Webschlüssel aus mehreren Quellen
• Zusätzliche benutzerdefinierte JWT-Validierungsregeln

Variable für entschlüsselten JWE-Chiffretext

JWTs sind eine weit verbreitete und vertrauenswürdige Methode zur zustandslosen Authentifizierung von HTTP-Anfragen (d. h. tokenbasierte Authentifizierung). Durch die Übertragung von Endbenutzerattributen in der Tokennutzlast tragen JWTs dazu bei, Anforderungen sicherer zu machen. Sicherheitsforscher und DevSecOps-Praktiker sind sich jedoch einig, dass das Risiko, das durch die Speicherung unverschlüsselter PII auf Webclients entsteht, ein dringendes Problem darstellt. Daher wurde der JSON Web Encryption-Standard (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 Datenintegrität und Vertraulichkeit für den gesamten Anspruchssatz. Durch die Kodierung von PII im verschlüsselten Token wird das Risiko von Datenlecks bei der Verwendung von JWTs erheblich reduziert.

NGINX Plus R25 baut auf der anfänglichen JWE-Unterstützung mit einer neuen Variable, $jwt_payload , auf, die es NGINX Plus ermöglicht, JWE und Geheimtext zu entschlüsseln und dann während der Verarbeitung der HTTP-Anfrage auf den Klartext zuzugreifen. Diese neue Funktionalität kann zum Implementieren erweiterter Zugriffskontrollrichtlinien und Anforderungsrouting-Entscheidungen verwendet werden und ermöglicht es Benutzern, NGINX Plus als JWE-Entschlüsselungsschicht für Backend-Anwendungen einzusetzen.

Unterstützung für verschachtelte JWTs

JWE-Token schützen PII wirksam, wobei der Geheimtext dazu dient, die Vertraulichkeit auch über CDNs und andere TLS-terminierende Proxys hinweg zu wahren. Allerdings ist die Verschlüsselung ein zweischneidiges Schwert, da JWEs die Anwendungsumgebung komplexer machen können. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, verschachtelte JWTs zu verwenden.

Verschachtelte JWTs betten JWS als Geheimtext eines JWE ein. NGINX Plus R25 ermöglicht verschachtelte JWTs als Methode zur Authentifizierung von HTTP-Anfragen, indem es sowohl JWS als auch JWE gleichzeitig unterstützt. In einem Vorgang kann NGINX Plus nun den Geheimtext im JWE entschlüsseln, den resultierenden Klartext als JWS validieren und die Angaben „exp“ (Ablaufzeit) und „nbf“ (nicht vorher) im beigefügten Token verwenden, um die Gültigkeit zu überprüfen. Dadurch kann eine vorhandene JWS-Umgebung mit Nutzlastverschlüsselung aktualisiert werden, indem sie in ein JWE eingebettet wird.

Der folgende Konfigurationsausschnitt veranschaulicht den Vorgang. Der neue verschachtelte Parameter der Direktive auth_jwt_type weist NGINX Plus an, sowohl die JWE-Entschlüsselung als auch die JWS-Validierung durchzuführen. Es wirkt sich auch darauf aus, wie die Variablen für JWT-Header und JWT-Ansprüche ausgewertet werden:

• Die Direktive „auth_jwt_header_set“ arbeitet mit den äußeren JWE-Headern.
• Die Direktive auth_jwt_claim_set arbeitet mit den verschachtelten JWS-Ansprüchen.
• $jwt_header_name - Variablen enthalten die äußeren JWE-Header-Eigenschaften.
• Die Variablen $ jwt_claim_name enthalten die verschachtelten JWS-Ansprüche.

Mit der folgenden Konfiguration erstellt und sendet NGINX Plus zusätzliche HTTP-Anforderungsheader 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 mit der ursprünglichen Anforderung per Proxy übermittelt. Dies bedeutet, dass Anwendungen die JWE-basierte Authentifizierung einfach durch die Verwendung von HTTP-Headern nutzen können, ohne dass kryptografischer Code oder Bibliotheken implementiert werden müssen.

Für Benutzer, die in Zero‑Trust‑Architekturen arbeiten, ermöglicht die folgende Konfiguration der Backend‑Anwendung, das JWS‑Token zu validieren, wie es in der Variable $jwt_payload erfasst ist. Die Variable enthält die entschlüsselte Klartextversion des JWE-Chiffretextes. Wenn ein verschachteltes JWT vorhanden ist, kann das JWS als Trägertoken an die Back-End-Anwendung übergeben werden.

Im Wesentlichen optimieren verschachtelte JWTs Vorgänge und verbessern die Anwendungssicherheit, indem sie NGINX Plus ermöglichen, sichere Token gleichzeitig zu entschlüsseln und zu validieren, während gleichzeitig der mit „regulärem JWT“ signierte Token für Back-End-Anwendungen analysiert oder als Proxy verwendet wird.

Asymmetrische Verschlüsselung für JWE

NGINX Plus R24 führte Unterstützung für die symmetrische Verschlüsselung von Token mit dem AES-Standard ein. NGINX Plus R25 fügt Unterstützung für asymmetrische Verschlüsselung bei Verwendung von RSA-Schlüsselpaaren hinzu. Bei der asymmetrischen Kryptografie werden zur Ver- und Entschlüsselung unterschiedliche Schlüssel (öffentlich und privat) verwendet, die durch den RSA-Algorithmus (Rivest–Shamir–Adleman) mathematisch miteinander verknüpft sind. Dabei handelt es sich um den gleichen Mechanismus, der für die SSL/TLS-Verschlüsselung des HTTPS-Verkehrs zwischen Client und Server verwendet wird.

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

Die folgende Konfiguration zeigt, dass zum Implementieren asymmetrischer Verschlüsselung für JWE lediglich die Angabe der JSON Web Key (JWK)-Datei erforderlich ist, die die privaten (Unwrap-) RSA-Schlüssel als Parameter für die Direktive „auth_jwt_key_file“ enthält (die Direktive „auth_jwt_key_request“ kann ebenfalls verwendet werden).

Multi-Source-JWK-Unterstützung

Die Nutzung verschachtelter JWTs bedeutet, dass die zugehörigen JWKs wahrscheinlich aus mehr als einer Quelle stammen. NGINX Plus R25 unterstützt mehrere auth_jwt_key_file- und auth_jwt_key_request -Direktiven im gleichen Kontext. NGINX Plus lädt Schlüssel aus allen angegebenen Quellen und sucht im kombinierten Schlüsselsatz nach dem passenden Verifizierungsschlüssel – äußerst nützlich bei der Arbeit mit einem JWS, das von einem externen Identitätsanbieter ausgestellt wurde und in einem JWE verschachtelt ist, bei dem die Verschlüsselung durch einen separaten Prozess erfolgte.

Diese Funktion verleiht NGINX Plus bei der Bereitstellung als API-Gateway noch mehr Flexibilität, Sicherheit und Leistung.

Benutzerdefinierte JWT-Validierungsregeln

Wenn NGINX Plus als API-Gateway eingesetzt wird, ist es üblich, JWT-Ansprüche zu prüfen, um eine feinkörnige Zugriffskontrolle zu implementieren. Dies kann zu komplexen Konfigurationen führen. In früheren Versionen von NGINX Plus konnten Sie „if“ -Konfigurationsblöcke zum Auswerten von JWT-Ansprüchen verwenden, dieser Ansatz war jedoch etwas eingeschränkt und funktionierte nicht für verschlüsselte Token.

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 Direktive „auth_jwt_require“ fügt dem JWT-Validierungsprozess einen optionalen, anpassbaren Schritt hinzu. Es akzeptiert eine durch Leerzeichen getrennte Liste von Zeichenfolgen, die alle nicht leer und nicht gleich sein dürfen0 (Null), damit die JWT-Validierung erfolgreich ist. Dies verleiht dem JWT-Validierungsprozess enorme Flexibilität.

Der JWT-Standard schreibt nicht vor, welche Ansprüche obligatorisch sind. Sie können daher „auth_jwt_require“ verwenden, um die entsprechenden Ansprüche für jede Umgebung aufzulisten.

Die folgende Konfiguration stellt sicher, dass sowohl die exp- als auch die sub -Ansprüche in jedem Token vorhanden sind.

Sie können komplexere Anwendungsfälle konfigurieren, indem Sie Map- Blöcke oder den Schlüssel-Wert-Speicher von NGINX Plus verwenden, um Boolesche Werte an die Direktive „auth_jwt_require“ zu übergeben. Sie können das NGINX JavaScript-Modul auch verwenden, um umfangreiche Authentifizierungslösungen wie zertifikatsgebundene Zugriffstoken für gegenseitiges TLS (mTLS) (definiert in RFC 8705 ) zu implementieren.

Die folgende Konfiguration führt sowohl die Client-Zertifikatauthentifizierung (mTLS) als auch die JWT-Validierung durch. Die Direktive „auth_jwt_require“ in Zeile 14 fordert die Auswertung der Variable „$thumbprint_match“ . Die JWT-Validierung ist nur erfolgreich, wenn sie einen Wert ungleich Null aufweist. Diese Variable wird durch Ausführen der in Zeile 2 aufgerufenen JavaScript-Funktion ausgewertet.

Hier ist der Code für die Validierungsfunktion , die in Zeile 2 des vorherigen Snippets aufgerufen wurde:

Detailliertere Berichterstattung über HTTP-Antwortcodes

Überwachung und Sichtbarkeit sind Eckpfeiler der Anwendungsleistung, Verfügbarkeit und Sicherheit. HTTP-Antwortcodes sind eine der wichtigsten Quellen für Einblicke in die Anwendungsintegrität. Die NGINX Plus-API verfolgt HTTP-Antwortcodes sowohl für Interaktionen zwischen NGINX und Clients als auch zwischen NGINX und Upstream-Servern. Die Anzahl wird auf den entsprechenden Registerkarten des Dashboards zur Live-Aktivitätsüberwachung von NGINX Plus angezeigt.

Frühere Versionen der NGINX Plus API aggregierten die Anzahl der HTTP-Antwortcodes nach Klasse ( 2xx , 4xx usw.). Nun werden Codes auch einzeln gezählt ( 200,404 ,503 , usw.). Dadurch erhalten Sie einen tieferen Einblick in das, was genau mit einer Anwendung passiert. Sie können zwischen Fehlern unterscheiden, die sehr unterschiedliche Ursachen haben, wie z. B. Spitzen bei fehlgeschlagenen Authentifizierungen (403 ) und fehlender Inhalt (404 ). Informationen zum Konfigurieren der Metrikerfassung finden Sie im NGINX Plus-Administratorhandbuch .

Die neueste Version der NGINX Plus API ( Version 7 ), die mit NGINX Plus R25 veröffentlicht wurde, enthält ein Codeobjekt innerhalb des Antwortobjekts , um das Zählen einzelner HTTP-Antwortcodes zu ermöglichen. Aggregierte Antworten sind weiterhin verfügbar und frühere Versionen der NGINX Plus-API – die das Codeobjekt nicht enthalten – können weiterhin mit NGINX Plus R25 verwendet werden. Hier ist ein Beispiel für den neuen Satz von Kennzahlen:

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "wird verarbeitet": 31, "Anfragen": 63192, "Antworten": { "1xx": 0, "2xx": 54368, "3xx": 8454, „4xx“: 330, "5xx": 9, "Codes": { "200": 54368, "302": 8454, "401": 30, "404": 200, "429": 100, "503": 9 }, "gesamt": 63161 }, "verworfen": 0, "empfangen": 693436, "gesendet": 13843478 }

Weisen Sie ausreichend Speicher zu, um Startfehler zu vermeiden

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

NGINX Plus R25 startet nicht, wenn die Upstream-Zonen nicht ausreichend bereitgestellt sind, was zu fehlgeschlagenen Upgrades führt.

Hier ist eine typische Konfiguration der gemeinsam genutzten Speicherzone für eine Upstream-Gruppe:

Bevor Sie auf NGINX Plus R25 aktualisieren, müssen Sie unbedingt die Speicherauslastung der vorhandenen Upstream-Zonen überprüfen. Stellen Sie dazu sicher, dass die NGINX Plus-API aktiviert ist, bevor Sie eine dieser Methoden verwenden:

• Überprüfen Sie die Registerkarte „HTTP-Upstreams“ des Dashboards zur Liveaktivitätsüberwachung, wie in diesem Beispiel von demo.nginx.com , wo die Auslastung 54 % beträgt:

  

• Verwenden Sie die NGINX Plus-API direkt vom Host aus, indem Sie den folgenden Befehl ausführen. Erste:

  • Installieren Sie bei Bedarf das Dienstprogramm jq
  • Legen Sie die API- Variable auf den Speicherort fest, an dem die API- Direktive aktiviert ist.

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

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

Dynamisches Laden von SSL/TLS-Client-Zertifikaten für Proxying

Mutual TLS (mTLS) ist ein gängiges Authentifizierungsverfahren, bei dem die Identität von Client und Server überprüft wird. Mit NGINX Plus können Sie die Server in einer Upstream-Gruppe dynamisch und mit Variablen definieren. Das bedeutet, dass Sie möglicherweise auch in der Lage sein müssen, das von NGINX Plus verwendete TLS-Zertifikat dynamisch auszuwählen, um sich gegenüber diesen Upstream-Servern zu verifizieren.

NGINX Plus R25 erweitert die für mTLS verwendeten Konfigurationsdirektiven auf einen Backend-Server, um eine Variable zu akzeptieren, die das Zertifikat darstellt. Die Variable kann sich auf eines der folgenden beziehen:

• 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 – nützlich für moderne Anwendungsumgebungen, die ständigen Änderungen unterliegen. 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 Speicher und nicht auf der Festplatte gespeichert wird. Ein weiterer Anwendungsfall ist die automatisierte Zertifikatsrotation, bei der Sie einen API-Aufruf verwenden, um Zertifikate im Schlüssel-Wert-Speicher zu aktualisieren.

In der folgenden Konfiguration leitet NGINX Plus Anfragen basierend auf dem Hostnamen an verschiedene Upstream-Gruppen weiter. Die Proxy-Verbindung wird mithilfe von mTLS hergestellt und das entsprechende Client-Zertifikat für jeden Upstream wird dynamisch ausgewählt.

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

• grpc_ssl_zertifikat
• grpc_ssl_zertifikatsschlüssel
• Proxy-SSL-Zertifikat
• Proxy-SSL-Zertifikatschlüssel
• uwsgi_ssl_zertifikat
• uwsgi_ssl_zertifikatsschlüssel

Verstärkte Sicherheit für die Verarbeitung von HTTP-Anfragen

Einer der Grundpfeiler 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 und interne Entwicklungsbemühungen.

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, wie etwa Anforderungsschmuggel , zu schützen. Unter diesen Bedingungen wird ein Fehler zurückgegeben:

• Eine HTTP/1.0-Anforderung enthält den Transfer-Encoding- Header
• Die Header „Transfer-Encoding“ und „Content-Length“ sind beide vorhanden
• Die Anforderungszeile oder ein Header-Name enthält Leerzeichen oder Steuerzeichen.
• Der Host- Header enthält Leerzeichen oder Steuerzeichen
• Die CONNECT -Methode wird verwendet

Darüber hinaus werden die folgenden Zeichen in einer Proxied-URI jetzt immer maskiert: " , < , > , \ , ^ , ` , { , | , } .

Bitte beachten Sie, dass es sich bei diesen Änderungen um proaktive Sicherheitsverbesserungen handelt und nicht um Reaktionen auf bekannte Sicherheitslücken.

Beibehaltung des obligatorischen Integritätsprüfungsstatus beim Neuladen für TCP/UDP-Anwendungen

NGINX Plus verwendet obligatorische Integritätsprüfungen, um sicherzustellen, dass neue Server, die zu Upstream-Gruppen hinzugefügt werden, getestet und fehlerfrei sind, bevor Clientanforderungen an sie weitergeleitet werden. In NGINX Plus R23 und früheren Versionen galten Upstream-Server nach einem Neuladen der Konfiguration als fehlerhaft, unabhängig von ihrem Status vor dem Neuladen. Dies hatte zur Folge, dass NGINX Plus keine Anfragen an einen Server schickte, bis die erste obligatorische Prüfung bestanden war.

NGINX Plus R24 führte für HTTP-Anwendungen die optionale Persistenz des obligatorischen Integritätsprüfstatus über Neuladevorgänge hinweg ein. Wenn die letzte obligatorische Integritätsprüfung vor einem Neuladen erfolgreich war, kann NGINX Plus sofort Anfragen an einen Server senden, anstatt auf den Erfolg einer obligatorischen Integritätsprüfung nach dem Neuladen warten zu müssen.

NGINX Plus R25 erweitert diese Funktionalität auf TCP/UDP-Anwendungen (innerhalb des Stream- Kontexts). Fügen Sie wie bei HTTP den persistenten Parameter zusammen mit dem obligatorischen Parameter zur Direktive health_check hinzu.

Verbesserungen am NGINX JavaScript-Modul

Das NGINX JavaScript-Modul (njs) wurde mit mehreren Fehlerbehebungen und einigen Funktionsverbesserungen, die die Kompatibilität mit JavaScript ES6 stärken, auf Version 0.6.2 aktualisiert.

Variablendeklaration mit den Schlüsselwörtern let und const

NGINX JavaScript unterstützt jetzt die Deklaration von Variablen mit Gültigkeitsbereich mit den Schlüsselwörtern let und const . Frühere Versionen von NGINX Plus und njs unterstützten nur das Schlüsselwort var zum Deklarieren und Zuweisen von Variablen. Dabei wurden keine Variablen berücksichtigt, die auf den Umfang einer bestimmten Blockanweisung beschränkt sind, die jedoch erforderlich sind, um die Komplexität zu bewältigen, die häufig entsteht, wenn verschiedene Projekte, Programmiersprachen und Entwicklungsteams an gemeinsamen Codebasen oder Bibliotheken zusammenarbeiten.

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

• Let -Variablen sind auf den Gültigkeitsbereich einer Blockanweisung oder eines Ausdrucks beschränkt, auf den sie angewendet werden. Im Gegensatz dazu deklariert das Schlüsselwort var eine Variable global oder lokal für eine ganze Funktion, unabhängig vom Blockbereich.
• Konstantenvariablen haben einen Blockbereich, ähnlich wie Variablen, die mit dem Schlüsselwort let deklariert werden. Der Wert einer Konstanten kann nicht durch Neuzuweisung geändert und nicht neu 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 jetzt den vollständigen Satz an Konstruktormethoden, die im JavaScript ES6-Standard definiert sind.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R25 zu aktualisieren. Sie erhalten außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.

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