Ankündigung von NGINX Plus R24

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 24 (R24) 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 R24 gehören:

• Verschlüsselte JSON Web Tokens – Aufbauend auf der Unterstützung für signierte JSON Web Tokens (JWTs) in früheren Versionen unterstützt NGINX Plus jetzt verschlüsselte JWTs, um die Vertraulichkeit und Datenintegrität sensibler Informationen bei der Speicherung in Webbrowsern und anderen Clients zu gewährleisten.
• Ein wichtiger Meilenstein in der Entwicklung des NGINX JavaScript Module – Neue Funktionen – insbesondere die Antwortfilterung sowohl für HTTP-Header als auch für Antworttexte sowie die Unterstützung HTTP-basierter Authentifizierungsdienste für TCP/UDP-Verbindungen und -Sitzungen – ermöglichen eine Reihe leistungsstarker neuer Anwendungsfälle.
• Integration mit F5 Device ID+ – Diese hochpräzise Gerätekennung weist jedem Gerät, das Ihre Website besucht, in Echtzeit eine eindeutige Kennung zu. Dies ermöglicht einen besseren Schutz vor bekannten böswilligen Akteuren und personalisierte Benutzererlebnisse für wiederkehrende Besucher.

Abgerundet wird das Release durch die optionale Beibehaltung der Ergebnisse obligatorischer Integritätsprüfungen über Konfigurationsneuladungen hinweg sowie durch dynamische Werte für Cookie-Flags.

Wichtige Verhaltensänderungen

Veraltetes Cookie-Flag-Modul

Wie angekündigt wurde das Drittanbieter-Modul Cookie-Flag mit der Veröffentlichung von NGINX Plus R23 als veraltet eingestuft 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 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. Siehe auch Dynamische Cookie-Flags.

Änderungen bei der Plattformunterstützung

• Neue unterstützte Betriebssysteme:
  • Alpine Linux 3.13 (aarch64, amd64)
  • CentOS 7.4+ (aarch64, zusätzlich zu x86_64 und ppc64le)
  • FreeBSD 13 (amd64)
  • SLES 15 SP2
• Ältere Betriebssysteme entfernt:
  • Debian 9 wird nicht mehr unterstützt; die älteste unterstützte Version ist 10
• Ältere Betriebssysteme, die als veraltet eingestuft wurden und deren Unterstützung in NGINX Plus R25 eingestellt werden soll:
  • Alpine Linux 3.10
  • Amazon Linux 1 (2018.03+)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2 ist von OpenSSL 1.1 abhängig

Das NGINX Plus-Paket für Amazon Linux 2 ist jetzt von OpenSSL 1.1 abhängig, wodurch TLS 1.3 aktiviert und die Sicherheit auf zahlreiche weitere Arten verbessert wird. Stellen Sie beim Upgrade von Amazon Linux 2-Systemen auf NGINX Plus R24 sicher, dass andere Software auf dem System, die OpenSSL verwendet, weiterhin ordnungsgemäß mit OpenSSL 1.1 funktioniert.

Änderungen am Installationsverfahren für NGINX Plus

Wir haben die Paket-Repositorys für NGINX Plus neu organisiert. Dadurch hat sich das Installationsverfahren geändert.

Die Änderung der Repository-Struktur spiegelt die Erweiterung unseres Produktportfolios und des Ökosystems der von NGINX Plus abhängigen Produkte wider. Speziell für NGINX Plus ersetzt das Repository pkgs.nginx.com/plus das alte Repository plus-pkgs.nginx.com.

Wenn Sie NGINX Plus installieren oder aktualisieren, wird der Paketmanager des Betriebssystems (apt, yum oder ein vergleichbares Tool) für die Verwendung des Software-Repositorys für NGINX Plus konfiguriert. Auf bestehenden Systemen, die für die Verwendung des Repositorys plus-pkgs.nginx.com konfiguriert sind, müssen Sie den Paketmanager so aktualisieren, dass er auf pkgs.nginx.com/plus verweist (zuzüglich des abschließenden Pfadelements, das das Betriebssystem angibt).

Anweisungen zum Upgrade eines bestehenden Systems auf NGINX Plus R24 finden Sie in der F5 Knowledge Base. Aktualisierte Anweisungen zur Erstinstallation finden Sie unter „Installing NGINX Plus“ im NGINX Plus Admin Guide.

Konsolidierung der Direktiven zur Handhabung von HTTP-Verbindungen

Da sich der HTTP/3-Standard der Fertigstellung nähert und HTTP/2 zunehmend genutzt wird, haben wir die Konfiguration langlebiger Verbindungen vereinfacht. Ab NGINX Plus R24 funktionieren Konfigurationsanweisungen, die zuvor nur für HTTP/1.1 galten, auch für HTTP/2. Sie müssen nicht mehr allein aufgrund unterschiedlicher Protokollversionen verschiedene Anweisungen für dieselbe Funktionalität verwenden.

Veraltete Direktive Ersatzdirektivehttp2_idle_timeout keepalive_timeouthttp2_max_field_size
http2_max_header_size large_client_header_buffershttp2_max_requests keepalive_requestshttp2_recv_timeout client_header_timeout

Aggressiveres Schließen von Verbindungen

In NGINX Plus R23 und höher funktionieren die Direktiven „lingering_close“, „lingering_time“ und „lingering_timeout“ sowohl für HTTP/2 als auch für HTTP/1.1. Eine effizientere Verarbeitung von HTTP/2-Verbindungen mithilfe dieser Direktiven verbessert die HTTP/2-Funktionalität von NGINX Plus insgesamt.

NGINX Plus R24 ändert die Wirkung dieser Direktiven in einem wichtigen Punkt und beseitigt einen potenziellen Fehler: Wenn der Pool freier Worker-Verbindungen erschöpft ist, beginnt NGINX Plus nicht nur Keepalive-Verbindungen zu schließen, sondern auch Verbindungen im Lingering-Close-Modus.

Geänderte Schweregradstufe für protokollierte Änderungen des Integritätsstatus

NGINX schreibt einen Eintrag in das Fehlerprotokoll wenn sich der Integritätsstatus eines Upstream-Servers ändert – ein wichtiges Werkzeug zur Überwachung und Analyse des Gesamtzustands Ihrer Infrastruktur. Die Prioritätsstufe, mit der Statusänderungen protokolliert werden, wurde sowohl für HTTP- als auch für TCP/UDP-Upstream-Server (stream) geändert:

• Der Wechsel von „healthy“ zu „unhealthy“ wird mit der Protokollierungsstufe „warn“ protokolliert (zuvor „info“).
• Der Wechsel von „unhealthy“ zu „healthy“ wird auf der Protokollierungsstufe „notice“ erfasst (zuvor „info“).

Neue Funktionen im Detail

Verschlüsselte JSON Web Tokens

Die Verwendung von JSON Web Tokens (JWTs) nimmt weiter zu. Bisher unterstützte NGINX Plus signierte Tokens (den in RFC 7515 definierten JSON-Web-Signature-Standard [JWS]), die die Datenintegrität der im Token codierten Claims gewährleisten. JWS schützt die Claims jedoch nicht vor unbefugtem Zugriff – sie können von jeder Komponente gelesen werden, die Zugriff auf das Token hat. TLS/SSL verringert das Risiko einer Offenlegung bei der Übertragung von Tokens, doch in Webbrowsern und anderen Clients gespeicherte Tokens sind weiterhin ungeschützt.

NGINX Plus R24 führt die Unterstützung für verschlüsselte Token ein (den in RFC 7516 definierten JSON-Web-Encryption-Standard [JWE]), die sowohl die Vertraulichkeit als auch die Datenintegrität des gesamten Anspruchssatzes gewährleisten. Sensible oder personenbezogene Daten (PII) können nun in JWTs codiert werden, ohne dass die Gefahr besteht, dass diese Daten durch unsichere Clients offengelegt werden.

NGINX Plus R24 und höher unterstützt sowohl signierte als auch verschlüsselte JWTs. Signierte Token sind die Standardeinstellung und erfordern keine explizite Konfiguration. Mit der neuen Direktive „auth_jwt_type“ wird die JWT-Verschlüsselung konfiguriert.

Codebeispiel wird geladen…

Den Verschlüsselungs- (oder Signatur-)Algorithmus und die Schlüsselverwendung legen Sie in der JWT-Schlüsseldatei fest, die mit der Direktive „auth_jwt_key_file“ angegeben wird. NGINX Plus ab R24 unterstützt die folgenden Verschlüsselungsmethoden.

JWE-Schlüsselverwaltungsalgorithmen

• A128KW, A192KW, A256KW

• A128GCMKW, A192GCMKW, A256GCMKW

• dir – Konfiguriert die direkte Verwendung eines gemeinsamen symmetrischen Schlüssels als Schlüssel zur Inhaltsverschlüsselung

JWE-Inhaltsverschlüsselungsalgorithmen

• A128CBC-HS256, A192CBC-HS384, A256CBC-HS512

• A128GCM, A192GCM, A256GCM

Wichtiger Meilenstein für den Reifegrad des NGINX-JavaScript-Moduls

NGINX Plus R24 markiert einen wichtigen Meilenstein in der Entwicklung des NGINX-JavaScript-Moduls (njs), das nun in Version 0.5.3 vorliegt. Zwei wichtige Verbesserungen ermöglichen es Ihnen, NGINX Plus mit maßgeschneiderten Lösungen für eine Vielzahl von Anwendungsfällen zu erweitern:

• Antwortfilterung sowohl für die Header als auch für die Nachrichtentexte von HTTP-Antworten
• Ein eingebetteter HTTP-Client, mit dem während der HTTP- oder TCP/UDP-Verarbeitung HTTP-Anfragen gestellt werden können

Wenn Sie mit dem NGINX-JavaScript-Modul noch nicht vertraut sind, lesen Sie bitte diese Einführung in unserem Blog<.htmla>.

[Die in diesem Abschnitt beschriebenen Anwendungsfälle sind nur einige der vielen Einsatzmöglichkeiten des NGINX JavaScript-Moduls. Eine vollständige Liste finden Sie unter „Anwendungsfälle für das NGINX JavaScript-Modul“.]

Antwortfilterung

Eine der leistungsstärksten Funktionen von NGINX Plus beim Einsatz als API-Gateway oder Reverse-Proxy ist die Antwortfilterung, bei der Antworten von Upstream-Servern abgefangen und Zeichenfolgen im Antworttext, in den Headern oder in beidem anhand regulärer Ausdrücke ersetzt werden. Für Datenverkehr, der nicht mit dem NGINX-JavaScript-Modul bearbeitet wird, erfolgt die Antwortfilterung im Substitution-Modul.

NGINX Plus R24 führt eine separate Implementierung der Antwortfilterung innerhalb des NGINX-JavaScript-Moduls ein. Zwei Direktiven ermöglichen es Ihnen, die Leistungsfähigkeit von JavaScript zur Analyse und Änderung von Antworttexten und -Headern zu nutzen. JavaScript erweitert die Möglichkeiten zur Überprüfung und Bearbeitung weit über die einfache, auf regulären Ausdrücken basierende Zeichenfolgenersetzung hinaus und ermöglicht so eine noch leistungsfähigere Antwortfilterung als mit dem Substitution-Modul.

Filtern von Antworttexten mit der js_body_filter-Direktive

Mit der Direktive „js_body_filter“ können Sie mithilfe von JavaScript den Textkörper der Antwort eines Proxy-Servers untersuchen und ändern. Zu den Anwendungsfällen gehören:

• Suche nach komplexen Mustern mit regulären Ausdrücken
• Datenformat umwandeln
• Dynamische Inhalte in Antworten einfügen

In diesem Beispiel durchsuchen wir Antworten nach Zeichenfolgen, die wie ein AWS-Zugriffsschlüssel aussehen, und ersetzen alle entsprechenden Vorkommen durch einen maskierten Wert.

Codebeispiel wird geladen…

Um diesen Code auszuführen, müssen wir lediglich innerhalb des entsprechenden maskAwsKeys-Blocks auf die Funktion location verweisen.

Codebeispiel wird geladen…

Filtern von Antwort-Headern mit der js_header_filter-Direktive

Mit der js_header_filter-Direktive können Sie den Inhalt von Antwort-Headern untersuchen oder sogar abfangen und ändern. Angenommen, ein Backend-Server gibt mehrere Set-Cookie-Header aus, die vertrauliche Informationen enthalten, aber für den ordnungsgemäßen Betrieb unerlässlich sind. NGINX Plus kann die Antwort abfangen, die Set-Cookie-Header auslesen und im Schlüssel-Wert-Speicher speichern. Ein Ersatz-Set-Cookie-Header kann als Verweis auf den Schlüssel-Wert-Speicher erstellt und in die ursprüngliche Antwort eingefügt werden.

Anfragefluss mit Darstellung der Interaktion von js_header_filter mit dem Schlüssel-Wert-Speicher

In den Zeilen 4–5 der NGINX Plus-Konfiguration definieren wir den Schlüssel-Wert-Speicher:

Codebeispiel wird geladen…

Anschließend ersetzen wir in den Zeilen 12–13 das Referenz-Cookie durch den Inhalt des Schlüssel-Wert-Speichers und fangen alle neuen Cookies mit unserem JavaScript-Code ab.

Codebeispiel wird geladen…

Der JavaScript-Code durchläuft jeden neuen Set-Cookie-Antwortheader und erstellt einen neuen Schlüssel-Wert-Eintrag, um ihn zu speichern.

Codebeispiel wird geladen…

HTTP-Dienste für TCP/UDP mit einem einfachen HTTP-Client nutzen

Der primäre Anwendungsfall für ein API-Gateway ist die Steuerung des Zugriffs auf bestimmte Ressourcen. NGINX Plus bietet leistungsstarke Authentifizierungs- und Zugriffskontrollfunktionen auf Layer 7 für HTTP-Anfragen. Moderne API-Implementierungen nutzen jedoch auch TCP/UDP als zugrunde liegendes Protokoll, wodurch neue Herausforderungen bei der Authentifizierung entstehen.

Mit der integrierten NGINX-JavaScript-Funktion ngx.fetch können Sie nun im Kontext einer TCP/UDP-Verbindung einen einfachen HTTP-Client instanziieren. Dadurch lassen sich HTTP-basierte Authentifizierungsdienste für die Zugriffskontrolle im stream-Kontext verwenden, beispielsweise indem beim Proxying einer Datenbankverbindung ein lokaler Open-Policy-Agent-Daemon aufgerufen wird.

Dieses Beispiel veranschaulicht die Verwendung eines lokalen HTTP-Authentifizierungsdienstes auf Port 8085, um jede neue Verbindung zu authentifizieren. Die js_access-Direktive und die ngx.fetch-Funktion implementieren gemeinsam im neu instanziierten HTTP-Kontext eine Funktionalität, die der Clientautorisierung auf Grundlage des Ergebnisses einer Unteranfrage ähnelt (wie sie durch die auth_request-Direktive für reguläre HTTP-Anfragen implementiert wird). Anhand des im Response-Objekt verfügbaren HTTP-Statuscodes wird die Verbindung zur Backend-Datenbank zugelassen (s.allow) oder abgelehnt (s.deny).

Codebeispiel wird geladen…

Codebeispiel wird geladen…

Hinweis: Die Funktion ngx.fetch funktioniert sowohl mit dem NGINX JavaScript HTTP-Modul als auch mit dem NGINX JavaScript Stream-Modul, weist jedoch im Vergleich zum Objekt r.subrequest im HTTP-Modul erhebliche Einschränkungen auf. Für die meisten HTTP-Anwendungsfälle wird r.subrequest bevorzugt, da es TLS-Verbindungen, Caching und sämtliche Funktionen des Proxy-Moduls unterstützt.

Weitere njs-Verbesserungen

Wenn eine NGINX-Variable mit der Direktive „set“ [HTTP][Stream] oder „js_set“ [HTTP][Stream] definiert wird, kann ihr Wert überschrieben werden, wenn bei der Verarbeitung der Anfrage eine Weiterleitung erfolgt. Mit der neuen Direktive „js_var“ [HTTP][Stream] kann eine Variable durch eine JavaScript-Funktion ausgewertet werden, wobei ihr Wert über Weiterleitungen hinweg erhalten bleibt.

Das neue njs.on-Objekt ermöglicht die Ausführung einer JavaScript-Funktion beim Beenden der virtuellen njs-Maschine. Dies kann beispielsweise verwendet werden, um am Ende einer TCP-Verbindung eine Funktion auszuführen.

Die neue Eigenschaft „s.status“ des Stream-Sitzungsobjekts ermöglicht den Zugriff auf den Gesamtstatus der Sitzung (mögliche Werte siehe „$status“).

Integration mit F5 Device ID+

F5 Device ID+ ist eine hochpräzise Gerätekennung, die in Echtzeit arbeitet und mithilfe fortschrittlicher Signalerfassung sowie bewährter Algorithmen für maschinelles Lernen jedem Gerät, das Ihre Website besucht, eine eindeutige Kennung zuweist. Die Bereitstellung ist unkompliziert und bietet Ihren Teams für Sicherheit, Netzwerke, Betrugsbekämpfung und digitale Lösungen sofortige Vorteile. Noch nie war es so einfach, die einzelnen Geräte zu identifizieren, die auf Ihre Anwendungen zugreifen.

Anweisungen zur Aktivierung von F5 Device ID+ auf Ihren NGINX Plus-Instanzen finden Sie unter „Betrug und Risiken mit F5 Device ID+ eindämmen“.

Vorteile der Verwendung von F5 Device ID+

• Anwendungssicherheit erhöhen – Verbessern Sie Ihre Analyse zur Erkennung und Abwehr von Angriffen durch eine präzise Geräteidentifizierung. Erkennen Sie wiederkehrende Geräte, die von Ihren Sicherheitssystemen bereits als verdächtig eingestuft wurden.
• Traffic-Management optimieren – Integrieren Sie eine eindeutige Gerätekennung in die Routing-Logik, um den Netzwerkverkehr besser zu steuern und zu optimieren. Identifizieren Sie Geräte selbst dann, wenn böswillige Akteure Daten der Schicht 7 manipulieren.
• Betrug und Risiken eindämmen – Überwachen Sie das Kundenverhalten bei Vorgängen wie der Erstellung neuer Konten, der Benutzerauthentifizierung, dem Bezahlvorgang im E-Commerce und Finanztransaktionen, um ungewöhnliche Muster zu erkennen, die unter anderem auf Identitätsdiebstahl hindeuten könnten.
• Online-Erlebnisse personalisieren und beschleunigen – Ermöglichen Sie bekannten wiederkehrenden Benutzern und Geräten eine reibungslose Anmeldung, Kaufabwicklung und Authentifizierung. A/B-Tests von F5 zeigen, dass der Abbau sicherheitsbedingter Hürden den Umsatz steigert. Die Geräteidentifizierung ist daher ein wichtiger Bestandteil jeder Strategie zur Verringerung solcher Hürden.

So funktioniert F5 Device ID+

Wenn ein Benutzer Ihre Website besucht, erfasst F5 Device ID+ mithilfe von JavaScript Informationen über den Browser, das Betriebssystem und die Hardware des Geräts sowie die Netzwerkkonfiguration. Diese Merkmale fließen in den F5 Device ID+ Service ein, der auf den branchenweit anerkannten KI- und Machine-Learning-Funktionen von F5 Shape basiert. Die Daten werden in Echtzeit verarbeitet und dem Gerät wird eine eindeutige Kennung zugewiesen, sofern es sich nicht bereits um ein bekanntes Gerät handelt. Bei wiederkehrenden Geräten können Verhalten, Aktionen und andere Eigenschaften erfasst, erlernt und analysiert werden, um Betrug zu reduzieren und bekannten vertrauenswürdigen Benutzern ein reibungsloses Nutzungserlebnis zu bieten.

Weitere Verbesserungen in NGINX Plus R24

Der Status obligatorischer Integritätsprüfungen kann über Konfigurationsneuladungen hinweg beibehalten werden

Obligatorische Integritätsprüfungen werden verwendet, um den langsamen Start von Upstream-Servern zu ermöglichen, die über die NGINX Plus API oder mittels DNS-Auflösung hinzugefügt werden. Sie stellen sicher, dass neue Knoten zunächst einer Integritätsprüfung unterzogen und anschließend langsam hochgefahren werden, sobald sie für den Empfang von Datenverkehr bereit sind.

Bisher wurden Upstream-Server nach dem Neuladen der Konfiguration unabhängig von ihrem Status vor dem Neuladen als fehlerhaft eingestuft. Daher nahmen die Server erst dann Clientanfragen an, nachdem die erste obligatorische Integritätsprüfung erfolgreich abgeschlossen worden war.

Mit NGINX Plus R24 können Sie obligatorische HTTP-Integritätsprüfungen als persistent kennzeichnen, sodass ihr vorheriger Status beim Neuladen der Konfiguration beibehalten wird. Fügen Sie der Direktive persistent zusätzlich zum Parameter health_check den Parameter mandatory hinzu.

Codebeispiel wird geladen…

Dynamische Cookie-Flags

In der vorherigen Version von NGINX Plus haben wir die Direktive „proxy_cookie_flags“ als native Methode zum Festlegen von Cookie-Flags eingeführt. NGINX Plus R24 erweitert diese Funktion um dynamische Werte für Cookie-Flags. Dadurch können bestimmte Cookie-Flags über NGINX-Variablen gesteuert werden.

Hinweis: Die proxy_cookie_flags-Direktive ersetzt das Cookie-Flag-Modul, das in NGINX Plus R26 entfernt wird. Siehe Veraltetes Cookie-Flag-Modul.

In diesem Beispiel wird eine map verwendet, um das Cookie-Flag Secure zu aktivieren, wenn das Schema https anstelle von http verwendet.

Codebeispiel wird geladen…

Führen Sie ein Upgrade durch oder testen Sie NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R24 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 APIs für Überwachung und Verwaltung. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion loslegen.

---