Ankündigung von NGINX Plus R24

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 24 (R24) 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 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 zur Vertraulichkeit und Datenintegrität sensibler Informationen, wenn diese in Webbrowsern und anderen Clients gespeichert werden.
• Ein wichtiger Meilenstein in der Entwicklung des NGINX JavaScript-Moduls – Neue Funktionen – insbesondere die Antwortfilterung für HTTP-Header und -Texte sowie die Unterstützung HTTP-basierter Authentifizierungsdienste für TCP/UDP-Verbindungen und -Sitzungen – erschließen eine Reihe leistungsstarker neuer Anwendungsfälle.
• Integration mit F5 Device ID+ – Diese hochpräzise Gerätekennung in Echtzeit weist jedem Gerät, das Ihre Site besucht, eine eindeutige Kennung zu. Dies ermöglicht einen stärkeren Schutz vor bekannten böswilligen Akteuren und ein individuelleres Benutzererlebnis für wiederkehrende Besucher.

Abgerundet wird die Version durch die optionale Persistenz der Ergebnisse obligatorischer Integritätsprüfungen und dynamischer Werte für Cookie-Flags über Konfigurationsneuladungen hinweg.

Wichtige Verhaltensänderungen

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 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. Siehe auch Dynamische Cookie-Flags .

Änderungen an 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 veraltet sind und deren Entfernung in NGINX Plus R25 geplant ist :
  • Alpine Linux 3.10
  • Amazon Linux 1 (2018.03+)
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2 hängt von OpenSSL 1.1 ab

Das NGINX Plus-Paket für Amazon Linux 2 basiert jetzt auf OpenSSL 1.1 , das TLS 1.3 ermöglicht und die Sicherheit auf zahlreiche andere Arten stärkt. Stellen Sie beim Upgrade von Amazon Linux 2-Systemen auf NGINX Plus R24 sicher, dass andere Software, die OpenSSL auf dem System verwendet, weiterhin ordnungsgemäß mit OpenSSL 1.1 funktioniert.

Änderungen am NGINX Plus-Installationsverfahren

Wir haben die NGINX Plus-Paket-Repositories neu organisiert, mit den daraus resultierenden Änderungen am Installationsverfahren.

Die Änderung der Repository-Organisation spiegelt die Erweiterung unseres Produktportfolios und des Ökosystems von Produkten wider, die von NGINX Plus abhängen. Insbesondere für NGINX Plus ersetzt das Repo pkgs.nginx.com/plus das alte Repo plus-pkgs.nginx.com .

Wenn Sie NGINX Plus installieren und 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 Repository plus-pkgs.nginx.com konfiguriert sind, müssen Sie den Paketmanager aktualisieren, sodass er auf pkgs.nginx.com/plus verweist (plus das letzte Pfadelement, das das Betriebssystem angibt).

Anweisungen zum Upgrade eines vorhandenen Systems auf NGINX Plus R24 finden Sie in der F5 Knowledge Base . Aktualisierte Anweisungen zur Erstinstallation finden Sie unter „Installieren von NGINX Plus“ im NGINX Plus-Administratorhandbuch.

Konsolidierung von HTTP-Verbindungsbehandlungsanweisungen

Da der HTTP/3-Standard kurz vor der Fertigstellung steht und die Nutzung von HTTP/2 zunimmt, haben wir die Konfiguration langlebiger Verbindungen vereinfacht. In NGINX Plus R24 und höher funktionieren Konfigurationsanweisungen, die zuvor nur für HTTP/1.1 galten, auch für HTTP/2. Sie müssen nicht mehr unterschiedliche Anweisungen für dieselbe Funktionalität verwenden, nur weil die Protokollversion unterschiedlich ist.

Aggressiverer Verbindungsabschluss

In NGINX Plus R23 und höher funktionieren die Anweisungen lingering_close , lingering_time und lingering_timeout sowohl für HTTP/2 als auch für HTTP/1.1. Durch die Konfiguration einer effizienteren Handhabung von HTTP/2-Verbindungen mit diesen Anweisungen werden die gesamten HTTP/2-Funktionen von NGINX Plus verbessert.

NGINX Plus R24 ändert die Wirkung dieser Anweisungen in wichtiger Weise und beseitigt einen potenziellen Fehler: Wenn der Pool freier Worker-Verbindungen erschöpft ist, beginnt NGINX Plus nicht nur mit dem Schließen von Keepalive-Verbindungen, sondern auch von Verbindungen im Lingering-Close-Modus.

Geänderter Schweregrad für protokollierte Änderungen des Gesundheitszustands

NGINX schreibt einen Eintrag in das Fehlerprotokoll, wenn sich der Integritätsstatus eines Upstream-Servers ändert – ein wichtiges Tool zur Überwachung und Analyse der allgemeinen Integrität Ihrer Infrastruktur. Der Schweregrad, bei dem Statusänderungen protokolliert werden, hat sich sowohl für HTTP- als auch für TCP/UDP-( Stream- )Upstreamserver geändert:

• Der Wechsel von „gesund“ zu „ungesund“ wird auf der Warnebene protokolliert (war „Info “).
• Der Wechsel von „ungesund“ zu „gesund“ wird auf der Benachrichtigungsebene protokolliert (war „Info“ ).

Neue Features im Detail

Verschlüsselte JSON-Web-Token

Die Verwendung von JSON Web Tokens ( JWTs ) nimmt weiterhin zu. Zuvor unterstützte NGINX Plus signierte Token (den in RFC 7515 definierten JSON Web Signature-Standard [JWS]), die die Datenintegrität für die im Token codierten Ansprüche gewährleisten. JWS gewährleistet jedoch keine Vertraulichkeit für Ansprüche – sie können von jeder Komponente gelesen werden, die Zugriff auf das Token hat. TLS/SSL verringert die Gefährdung durch Token während der Übertragung, aber in Webbrowsern und anderen Clients gespeicherte Token sind weiterhin gefährdet.

NGINX Plus R24 führt Unterstützung für verschlüsselte Token ein (der JSON Web Encryption-Standard [JWE], definiert in RFC 7516 ), die sowohl Vertraulichkeit als auch Datenintegrität für den gesamten Anspruchssatz gewährleisten. Sensible oder persönlich identifizierbare Informationen (PII) können jetzt in JWTs codiert werden, ohne dass die Gefahr besteht, dass diese Daten durch unsichere Clients verloren gehen.

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. Die neue Direktive auth_jwt_type konfiguriert die JWT-Verschlüsselung.

Sie definieren den Verschlüsselungs- (oder Signatur-)Algorithmus und die Schlüsselverwendung in der JWT-Schlüsseldatei, die durch die Direktive auth_jwt_key_file benannt wird. NGINX Plus R24 und höher unterstützt die folgenden Verschlüsselungsmethoden.

Wichtiger Reifegradmeilenstein für das NGINX JavaScript-Modul

NGINX Plus R24 markiert einen wichtigen Meilenstein in der Entwicklung des NGINX JavaScript-Moduls (njs), das jetzt0.5.3 . Es gibt zwei wichtige Verbesserungen, die es Ihnen ermöglichen, NGINX Plus mit benutzerdefinierten Lösungen für eine Vielzahl von Anwendungsfällen zu erweitern:

• Antwortfilterung für Header und Text von HTTP-Antworten
• Ein eingebetteter HTTP-Client , der verwendet werden kann, um HTTP-Anfragen während der HTTP- oder TCP/UDP-Verarbeitung zu stellen

Wenn Sie mit dem NGINX-JavaScript-Modul 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 Anwendungsfälle für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter Anwendungsfälle für das NGINX-JavaScript-Modul . ]

Antwortfilterung

Eine der leistungsstärksten Funktionen von NGINX Plus bei der Bereitstellung als API-Gateway oder Reverse-Proxy ist die Antwortfilterung . Dabei werden Antworten von Upstream-Servern abgefangen und Zeichenfolgen im Antworttext, in den Headern oder in beiden auf der Grundlage von regulären Ausdrücken ersetzt. Für Datenverkehr, der nicht mit dem NGINX-JavaScript-Modul manipuliert wird, wird die Antwortfilterung im Substitutionsmodul implementiert.

NGINX Plus R24 führt eine separate Implementierung der Antwortfilterung innerhalb des NGINX JavaScript-Moduls ein, mit zwei Anweisungen, die es Ihnen ermöglichen, die Leistungsfähigkeit von JavaScript zu nutzen, um Antworttexte und -header zu analysieren und zu ändern. JavaScript erweitert die Möglichkeiten zur Überprüfung und Manipulation weit über die einfache Zeichenfolgenersetzung auf der Grundlage regulärer Ausdrücke hinaus und ermöglicht eine noch leistungsfähigere Antwortfilterung als mit dem Substitutionsmodul.

Filtern von Antworttexten mit der js_body_filter- Direktive

Mit der Direktive js_body_filter können Sie JavaScript verwenden, um den Hauptteil der Antwort von einem Proxyserver zu prüfen und zu ändern. Zu den Anwendungsfällen gehören:

• Mit regulären Ausdrücken nach komplexen Mustern suchen
• Datenformat umwandeln
• Einfügen dynamischer Inhalte in Antworten

In diesem Beispiel durchsuchen wir die Antworten nach allem, was wie ein AWS-Zugriffsschlüssel aussieht, und ersetzen alle derartigen Vorkommen durch einen ausgeblendeten Wert.

Um diesen Code auszuführen, müssen wir einfach auf die Funktion maskAwsKeys im entsprechenden Standortblock verweisen.

Filtern von Antwortheadern mit der Direktive js_header_filter

Mit der Direktive js_header_filter können Sie den Inhalt von Antwortheadern untersuchen – oder sogar abfangen und ändern. Stellen Sie sich einen Backend-Server vor, der eine Reihe von Set-Cookie -Headern ausgibt, die vertrauliche Informationen enthalten, aber für den ordnungsgemäßen Betrieb unerlässlich sind. NGINX Plus kann die Antwort abfangen, die Set-Cookie -Header lesen und sie im Schlüssel-Wert-Speicher speichern. Ein Ersatz- Set-Cookie- Header kann als Referenz auf den Schlüssel-Wert-Speicher erstellt und in die ursprüngliche Antwort eingefügt werden.

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

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

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

Nutzung von HTTP-Diensten für TCP/UDP mit einem einfachen HTTP-Client

Der primäre Anwendungsfall für ein API-Gateway ist die Kontrolle des Zugriffs auf bestimmte Ressourcen. NGINX Plus unterstützt einen Satz leistungsstarker Authentifizierungs- und Zugriffskontrollfunktionen auf Ebene 7 für HTTP-Anfragen, moderne API-Implementierungen nutzen jedoch auch TCP/UDP als zugrunde liegendes Protokoll, was neue Herausforderungen bei der Authentifizierung mit sich bringt.

Mit der integrierten NGINX JavaScript-Funktion ngx.fetch können Sie jetzt einen einfachen HTTP-Client im Kontext einer TCP/UDP-Verbindung instanziieren. Dies ermöglicht die Verwendung von HTTP-basierten Authentifizierungsdiensten für die Zugriffskontrolle im Stream- Kontext, beispielsweise das Aufrufen eines lokalen OpenPolicy Agent-Daemons beim Proxying einer Datenbankverbindung.

Dieses Beispiel demonstriert die Verwendung eines lokalen HTTP-Authentifizierungsdienstes auf Port 8085 zur Authentifizierung jeder neuen Verbindung. Die Direktive js_access und die Funktion ngx.fetch implementieren zusammen eine Funktionalität im neu instanziierten HTTP-Kontext, die der Client-Autorisierung basierend auf dem Ergebnis einer Unteranforderung ähnelt (wie von der Direktive auth_request für reguläre HTTP-Anforderungen implementiert). Basierend auf dem im Response -Objekt verfügbaren HTTP-Statuscode wird die Verbindung zur Backend-Datenbank zugelassen ( s.allow ) oder abgelehnt ( s.deny ).

Notiz: Die Funktion ngx.fetch funktioniert mit dem NGINX JavaScript HTTP-Modul sowie dem NGINX JavaScript Stream-Modul, weist jedoch im Vergleich zum r.subrequest- Objekt im HTTP-Modul erhebliche Einschränkungen auf. Für die meisten HTTP-Anwendungsfälle wird r.subrequest bevorzugt, da es Unterstützung für TLS-Verbindungen, Caching und alle Funktionen des Proxy-Moduls bietet.

Andere njs-Verbesserungen

Wenn eine NGINX-Variable mit der Direktive „set [ HTTP ][ Stream ]“ oder „js_set [ HTTP ][ Stream ]“ definiert ist, kann der Wert überschrieben werden, wenn bei der Anforderungsverarbeitung eine Umleitung auftritt. Mit der neuen Direktive js_var [ HTTP ][ Stream ] kann eine Variable durch eine JavaScript-Funktion ausgewertet werden und ihr Wert bleibt auch bei Weiterleitungen erhalten.

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

Die neue Eigenschaft „s.status“ des Stream-Sitzungsobjekts bietet Zugriff auf den Gesamtsitzungsstatus (mögliche Werte finden Sie unter „$status“ ).

Integration mit F5 Device ID+

F5 Device ID+ ist ein hochpräziser Gerätebezeichner in Echtzeit, der erweiterte Signalerfassung und bewährte Algorithmen des maschinellen Lernens nutzt, um jedem Gerät, das Ihre Site besucht, eine eindeutige Kennung zuzuweisen. Die Bereitstellung ist einfach und bietet sofortige Vorteile für Ihre Teams für Sicherheit, Netzwerke, Betrugsbekämpfung und digitale Technologien. Noch nie war es so einfach, die einzelnen Geräte zu verstehen, die Ihre Anwendungen besuchen.

Anweisungen zum Aktivieren von F5 Device ID+ auf Ihren NGINX Plus-Instanzen finden Sie unter Betrug und Risiken mit F5 Device ID+ mindern .

Vorteile der Verwendung von F5 Device ID+

• Stärken Sie die Anwendungssicherheit – Verbessern Sie Ihre Angriffserkennung und Abwehranalyse durch genaue Geräteidentifizierung. Erkennen Sie wiederkehrende Geräte, die Ihre Sicherheitssysteme bereits als verdächtig gekennzeichnet haben.
• Optimieren Sie das Verkehrsmanagement – Integrieren Sie eine eindeutige Gerätekennung in die Routing-Logik, um den Netzwerkverkehr besser zu verwalten und zu optimieren. Identifizieren Sie Geräte, selbst wenn böswillige Akteure Layer-7-Daten manipulieren.
• Minimieren Sie Betrug und Risiken – Überwachen Sie das Kundenverhalten bei Vorgängen wie der Erstellung neuer Konten, der Benutzerauthentifizierung, dem Bezahlvorgang im E-Commerce und Finanztransaktionen und erkennen Sie anomale Muster, die neben anderen Bedrohungen auf Identitätsdiebstahl hinweisen könnten.
• Personalisieren und beschleunigen Sie Online-Erlebnisse – Sorgen Sie für nahtlose Anmeldung, Kaufabwicklung und Authentifizierung für bekannte wiederkehrende Benutzer und Geräte. A/B-Tests von F5 zeigen, dass die Reduzierung von Sicherheitsproblemen den Umsatz steigert, und die Geräteidentifizierung ist ein wichtiges Element jeder Strategie zur Reibungsreduzierung.

So funktioniert F5 Device ID+

Wenn jeder Benutzer Ihre Website besucht, nutzt F5 Device ID+ JavaScript, um Informationen über den Browser, das Betriebssystem des Geräts, die Hardware und die Netzwerkkonfiguration zu sammeln. Diese Attribute fließen in den Dienst F5 Device ID+ ein, der auf den branchenweit anerkannten KI- und maschinellen Lernfunktionen 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 aufgezeichnet, erlernt und untersucht werden, um Betrugsversuche zu reduzieren und nachweislich guten Benutzern ein reibungsloses Erlebnis zu bieten.

Weitere Verbesserungen in NGINX Plus R24

Der Status obligatorischer Integritätsprüfungen kann auch nach erneutem Laden der Konfiguration bestehen bleiben

Obligatorische Integritätsprüfungen werden verwendet, um den langsamen Start von Upstream-Servern zu ermöglichen, die mithilfe der NGINX Plus-API oder durch DNS-Auflösung hinzugefügt werden. Sie stellen sicher, dass neue Knoten zuerst einer Integritätsprüfung unterzogen werden und dann langsam gestartet werden, sobald sie für den Empfang von Datenverkehr bereit sind.

Zuvor wurden Upstream-Server nach einem Neuladen der Konfiguration als fehlerhaft betrachtet, unabhängig von ihrem Status vor dem Neuladen. Dies hatte zur Folge, dass die Server keine Client-Anfragen akzeptierten, bis die erste obligatorische Prüfung abgeschlossen war.

Mit NGINX Plus R24 können Sie obligatorische HTTP-Integritätsprüfungen als persistent markieren, sodass ihr vorheriger Status beim Neuladen der Konfiguration gespeichert wird. Fügen Sie der Direktive health_check zusammen mit dem obligatorischen Parameter den persistenten Parameter hinzu.

Dynamische Cookie-Flags

In der vorherigen Version von NGINX Plus haben wir die Direktive proxy_cookie_flags als native Methode zum Setzen von Cookie-Flags eingeführt. NGINX Plus R24 erweitert diese Funktion, indem es dynamische Werte für Cookie-Flags aktiviert. Dadurch können bestimmte Cookie-Flags durch NGINX-Variablen gesteuert werden.

Notiz: Die Direktive proxy_cookie_flags macht das Cookie-Flag-Modul veraltet und wird in NGINX Plus R26 entfernt. Siehe Veraltetes Cookie-Flag-Modul .

In diesem Beispiel wird eine Zuordnung verwendet, um das Flag „Sicheres Cookie“ zu aktivieren, wenn das Schema https statt http ist.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R24 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.