Ankündigung von NGINX Plus R22

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 22 (R22) ab sofort verfügbar ist. Basierend auf NGINX Open Source ist NGINX Plus die einzige All-in-One-Softwarelösung, die Load Balancer, Content-Cache, Webserver und API-Gateway vereint. Der Schwerpunkt dieses Releases liegt auf Monitoring und Authentifizierung, um die Granularität und Ausfallsicherheit Ihrer Anwendungen bei der Skalierung zu verbessern.

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

• Verbesserungen bei der Authentifizierung mit Clientzertifikaten – Die Überprüfung über das Online Certificate Status Protocol (OCSP) bietet eine zusätzliche Sicherheitsebene, indem bei gegenseitigem TLS geprüft wird, ob Zertifikate widerrufen wurden.
• OpenID-Connect-Unterstützung für mehrere IdPs – Mit NGINX Plus R15 haben wir die OpenID-Connect-Integration (OIDC) eingeführt, damit unsere Kunden ihre Anwendungen um Single Sign-on (SSO) erweitern können. Mit NGINX Plus R22 können Sie problemlos mehrere OIDC-Identitätsanbieter (IdPs) integrieren.
• Mehr Metriken im Dashboard zur Echtzeit-Aktivitätsüberwachung – Das Dashboard zeigt jetzt Metriken zur OIDC-Aktivität sowie Verlaufsdiagramme zur Begrenzung von Anfragen und Verbindungen an.
• Verbesserungen am NGINX-JavaScript-Modul – Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.4.1 aktualisiert und bietet mehrere Fehlerbehebungen sowie neue Funktionen, darunter das Importieren von JavaScript-Modulen und den Zugriff auf unverarbeitete Header-Objekte.

Wichtige Verhaltensänderungen

• Ältere Betriebssysteme werden nicht mehr unterstützt –
  • Alpine Linux 3.8 wird nicht mehr unterstützt
  • Wie für NGINX Plus R21<.htmla> angekündigt, ist NGINX Plus nicht mehr für 32-Bit-Plattformen (i386-Architektur) verfügbar

Neue Funktionen im Detail

OCSP-Validierung von Client-Zertifikaten

NGINX Plus unterstützt gegenseitiges TLS, bei dem Clientzertifikate sowohl zur Überprüfung der Identität des Clients, der die Verbindung herstellt, als auch zum Aufbau einer verschlüsselten Verbindung verwendet werden. Gegenseitiges TLS bietet ein hohes Maß an Sicherheit hinsichtlich der Identität des Clients, doch die Verwaltung widerrufener Zertifikate kann einen erheblichen administrativen Aufwand verursachen. Das Online Certificate Status Protocol (OCSP) löst dieses Problem, indem es den Status von Clientzertifikaten bei deren Vorlage überprüft.

Sie können NGINX Plus so konfigurieren, dass OCSP zur Überprüfung der Gültigkeit von X.509-Clientzertifikaten gemäß RFC 6960 verwendet wird.

Um die OCSP-Validierung von SSL-Clientzertifikaten zu aktivieren, fügen Sie die neue Direktive „ssl_ocsp“ zusammen mit der Direktive „ssl_verify_client“ ein, die die Zertifikatsüberprüfung aktiviert.

Codebeispiel wird geladen…

NGINX Plus sendet die OCSP-Anfrage an den im Clientzertifikat eingebetteten OCSP-URI, sofern Sie nicht mit der Direktive „ssl_ocsp_responder“ einen anderen URI definieren.

Um OCSP-Antworten in einer einzigen, von allen Worker-Prozessen gemeinsam genutzten Speicherzone zwischenzuspeichern, verwenden Sie die Direktive „ssl_ocsp_cache“, um den Namen und die Größe der Zone festzulegen. Antworten werden 1 Stunde lang zwischengespeichert, sofern der Wert „nextUpdate“ in der OCSP-Antwort keinen anderen Zeitraum angibt.

Das Ergebnis der Validierung des Clientzertifikats ist in der Variable „$ssl_client_verify“ verfügbar, einschließlich des Grundes für den OCSP-Fehler.

Der TLS-Handshake schlägt fehl, wenn das Clientzertifikat nicht vertrauenswürdig oder die OCSP-Antwort ungültig ist. Der Statuscode 495 (SSL-Zertifikatsfehler) wird zurückgegeben und im Fehlerprotokoll wird ein Eintrag mit dem Schweregrad error erstellt:

YYYY/MM/DD hh:mm:ss [error] 31222#0: *5 certificate status "revoked" in the OCSP response while requesting certificate status, responder: 127.0.0.1

OpenID-Connect-Verbesserungen

Unsere OpenID-Connect-Referenzimplementierung für NGINX Plus erweitert SSO auf neue und bestehende Anwendungen, um Komplexität und Kosten zu minimieren. Die Referenzimplementierung nutzt eine Kombination aus Funktionen von NGINX Plus und dem NGINX JavaScript-Modul (njs), um einen Codeaustausch mit dem Autorisierungsendpunkt durchzuführen und ein ID-Token vom IdP zu erhalten. Die ID-Token werden im Schlüssel-Wert-Speicher von NGINX Plus zwischengespeichert und ein opakes Sitzungstoken wird an den Client gesendet. Clients authentifizieren sich anschließend durch Vorlage eines gültigen Sitzungstokens, anhand dessen NGINX Plus das ID-Token überprüft, bevor der Zugriff auf Backend-Anwendungen gewährt wird.

Diese Version enthält zahlreiche Verbesserungen an der OIDC-Referenzimplementierung sowie zwei wesentliche Änderungen:

1. Die Konfiguration unterstützt jetzt mehrere IdPs, indem geeignete Eingabevariablen aus eingehenden Anfragen an mehrere map-Blöcke übergeben werden. Diese zusätzliche Flexibilität verringert die Notwendigkeit, den Code der OIDC-Referenzimplementierung zu ändern.
2. Der JavaScript-Code ist jetzt als Modul implementiert, sodass er zusammen mit anderen njs-Lösungen auf demselben Host verwendet werden kann, ohne dass der gesamte njs-Code in einer einzigen Datei verwaltet werden muss.

Hier ist eine Beispielkonfiguration:

Codebeispiel wird geladen…

Jeder map-Block lässt mehrere Werte zu, sodass mehrere IdPs und Authentifizierungsparameter (Client-Secret, JWK-Schlüsseldatei, Autorisierungsendpunkte) unterstützt werden können. Hier verwenden wir die Variable $host als Eingabeparameter, Sie können jedoch jede beliebige aus dem Anfrage-Header abgeleitete Variable angeben.

Die NGINX Plus API erfasst jetzt Aktivitäten im Zusammenhang mit OpenID-Connect-Anmeldungen, um die Überwachung und Fehlerbehebung zu erleichtern. Weitere Informationen zur OpenID-Connect-Referenzimplementierung finden Sie im GitHub-Repository.

Echtzeit-Dashboard-Diagramme zur Begrenzung von Anfrageraten und Verbindungen

DDoS-Angriffe und Brute-Force-Angriffe zum Erraten von Passwörtern stellen zwei ernsthafte Bedrohungen für Ihre Anwendungen dar. Mit einer Anfrageratenbegrenzung können Sie deren Auswirkungen eindämmen, indem NGINX Plus die Anzahl der Anfragen begrenzt, die jeder Client innerhalb eines bestimmten Zeitraums stellen kann.

NGINX Plus R20 führte die Echtzeitüberwachung der Anfragerate und der Verbindungenbegrenzung in der NGINX Plus API ein (an den Endpunkten /api/version/http/limit_reqs und /api/version/http/limit_conns). Die Informationen werden nun auf dem Live-Aktivitätsüberwachungs-Dashboard von NGINX Plus angezeigt, mit kumulierten Zählerständen in Tabellenform und mit Zeitstempeln versehenen Zählerständen in Diagrammform:

• Metriken zur Begrenzung der Anfragerate werden in der Tabelle „Limit Req“ auf der Registerkarte „HTTP Zones“ angezeigt
• Metriken zur Verbindungsbegrenzung werden in der Tabelle „Limit Conn“ auf der Registerkarte „TCP/UDP Zones“ angezeigt

Die Tabelle enthält für jede Zone, die durch eine limit_req_zone- oder limit_conn_zone-Direktive definiert ist, eine Zeile. Um das Diagramm anzuzeigen, klicken Sie auf das Diagrammsymbol am linken Ende der Zeile.

Das erweiterte Diagramm wird kontinuierlich aktualisiert und zeigt die Werte für jedes Zeitintervall als gestapeltes Flächendiagramm an. Sie können die angezeigten Informationen wie folgt anpassen:

• Wählen Sie den anzuzeigenden Zeitraum aus: 1 Minute, 5 Minuten oder 15 Minuten
• Bewegen Sie den Mauszeiger über das Diagramm, um die genauen Werte für einen bestimmten Zeitpunkt anzuzeigen.
• Bewegen Sie den Mauszeiger im Legendenbereich über einen Statistiktyp, um die entsprechende Statistik im Diagramm hervorzuheben.
• Klicken Sie im Legendenbereich auf einen Statistiktyp, um ihn ein- oder auszublenden.
• Ziehen Sie das Diagramm nach links oder rechts, um historische Daten anzuzeigen.

Beim standardmäßigen Aktualisierungsintervall des Dashboards von 1 Sekunde speichert jedes Diagramm historische Daten für etwa 30 Minuten. Wenn Sie das Aktualisierungsintervall des Dashboards erhöhen (also seltener aktualisieren), stehen mehr historische Daten zur Verfügung. Beachten Sie, dass die Dashboard-Diagramme nicht dauerhaft gespeichert werden und historische Daten verloren gehen, wenn Sie die Registerkarte verlassen oder neu laden.

Verbesserungen am NGINX-JavaScript-Modul

Das NGINX-JavaScript-Modul erweitert die Funktionalität von NGINX Plus und ermöglicht so eine Vielzahl von Anwendungsfällen, darunter eine präzisere Steuerung des Datenverkehrs, die anwendungsübergreifende Konsolidierung von JavaScript-Funktionen und die Abwehr von Sicherheitsbedrohungen. Das NGINX-JavaScript-Modul wurde auf Version 0.4.1 aktualisiert und umfasst folgende Funktionen:

• Die neue js_import-Direktive zum Importieren mehrerer Moduldateien, die Handler für Locations und Variablen implementieren
• Verbesserte Unterstützung für Header, einschließlich neuer Raw-Header-Objekte
• Sie können TypeScript-Definitionsdateien in Ihrem njs-Code verwenden
• Unterstützung für die Konvertierung externer Werte in native JavaScript-Objekte

Der folgende Code und die folgende Konfiguration veranschaulichen, wie das neue Objekt „r.rawHeadersIn“ verwendet werden kann, um bei jedem auftretenden Fehler den exakten Satz der vom Client gesendeten Header zu protokollieren. [Redaktion – Dies ist nur einer von vielen Anwendungsfällen für das NGINX-JavaScript-Modul. Eine vollständige Liste finden Sie unter „Anwendungsfälle für das NGINX-JavaScript-Modul“. ]

Codebeispiel wird geladen…

Codebeispiel wird geladen…

Hier ist ein Beispiel für einen Protokolleintrag zu einer 404-Antwort:

$ curl http://localhost/bogus
$ tail --lines=1 /var/log/nginx/access_json.log
{"response":{"timestamp":"YYYY-MM-DDThh:mm:ss+TZ_offset","status":404},"request":{"client":"127.0.0.1","uri":"/bogus","headers":[["Host","localhost:80"],["User-Agent","curl/7.64.1"],["Accept","*/*"]]}}

Verzögerung bei fehlgeschlagener Authentifizierung

Um Timing-Angriffe wie Brute-Force-Angriffe auf Passwörter und Credential Stuffing abzuwehren, können Sie NGINX Plus so konfigurieren, dass die Antwort bei fehlgeschlagener Authentifizierung verzögert wird. Die neue Direktive auth_delay legt die Verzögerung fest, die auf Authentifizierungsanfragen angewendet werden kann, die von den Modulen Auth Basic, Auth JWT und Auth Request verarbeitet werden.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R22 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 selbst 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. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.

Über den Autor

Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly