NGINX veröffentlicht die 25 Version von NGINX Plus unter dem Namen Release 25 (R25). Basierend auf NGINX Open Source ist NGINX Plus der einzige All-in-One- Software-Webserver, Load Balancer, Reverse-Proxy, Content-Cache und API-Gateway.
Wichtige Info an Kunden von NGINX App Protect
Das neue Update R25 von NGINX ist nicht abwärtskompatibel mit NGINX App Protect 3.5 (der aktuellelen Version). Um Fehler beim Upgrade zu vermeiden, ist das NGINX Plus R25 Paket derzeit nicht im NGINX Plus-Software-Repository verfügbar. Kunden mit einem NGINX App Potect-Abonnement, die NGINX Plus R25 (ohne App Protect) beziehen möchten, können dies über MyF5 tun. NGINX App Protect 3.6 bietet Unterstützung für NGINX Plus R25. Geplant ist dies für den 13. Oktober 2021.
Zu den neuen Funktionen von R25 gehören
Zusätzliche, erweiterte Anwendungsfälle für JSON Web Token
Das NGINX Plus Release 24 bietet erstmals Unterstützung für verschlüsselte Web-Tokens und erweitert damit eine der beliebtesten Methoden der Client-Authentifizierung um die Vertraulichkeit der Daten zu sichern. 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 als auch für verschlüsselte Anwendungsfälle zu verbessern. Die Erweiterungen verringern das Risiko, dass personenbezogene Daten preisgegeben werden und bieten mehr Flexibilität.
Zu den neuen JWT-Funktionen für NGINX Plus gehören:
- Eine neue Variable für entschlüsselten JWE-Chrifftretext
- Unterstützung für verschachtelte JWTs
- Asymmetrische Verschlüsselung für JWE
- Unterstützung für JSON-Web-Schlüssel aus mehreren Quellen
- Zusätzliche benutzerdefinierte JWT-Validierungsregeln
Detaillierteres Reporting von HTTP-Antwortcodes
Überwachung und Transparenz sind die Eckpfeiler von Anwendungsleistung, Verfügbarkeit und Sicherheit. HTTP-Antwortcodes sind eine der wichtigsten Quellen, die Aufschluss über den Zustand von Anwendungen geben. Die NGINX Plus API verfolgt HTTP-Antwortcodes sowohl für Interaktionen zwischen NGINX und Clients als auch zwischen NGINX und Upstream-Servern; die Zählungen werden auf den entsprechenden Registerkarten des NGINX Plus Live-Aktivitätsüberwachungs-Dashboards angezeigt.
In früheren Versionen der NGINX Plus API wurden die HTTP-Antwortcodes nach Klassen (2xx, 4xx usw.) zusammengefasst. Jetzt werden die Codes auch einzeln gezählt (200, 404, 503, usw.). Dadurch erhält der Nutzer einen genaueren Einblick in die Vorgänge bei einer Anwendung und kann zwischen Fehlern mit sehr unterschiedlichen Ursachen unterscheiden, wie z. B. Spitzen bei fehlgeschlagenen Authentifizierungen (403) und fehlenden Inhalten (404).
Die neueste Version der NGINX Plus API (Version 7), die mit NGINX Plus R25 veröffentlicht wurde, enthält ein Code-Objekt innerhalb des Response-Objekts, das die Zählung einzelner HTTP-Antwortcodes ermöglicht. Aggregierte Antworten sind nach wie vor verfügbar, und frühere Versionen der NGINX Plus API – die das Codes-Objekt nicht enthalten – können weiterhin mit NGINX Plus R25 verwendet werden. Hier ein Beispiel für den neuen Satz an Metriken:
$ 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
}
HINWEIS: Wenn NGINX Plus als Reverse-Proxy oder Load Balancer konfiguriert ist, erhöht die Zählung der einzelnen Codes die Speicherauslastung in der gemeinsamen Speicherzone für jede Upstream-Gruppe. Wenn sich mehr als 20 Peers in der Upstream-Gruppe befinden, muss möglicherweise die Speichergröße erhöht werden, wie mit der Zonenanweisung konfiguriert.
NGINX Plus R25 startet nicht, wenn Upstream-Zonen unterversorgt sind, was zu fehlgeschlagenen Upgrades führt.
Hier ist eine typische Konfiguration der gemeinsamen Speicherzone für eine Upstream-Gruppe:
upstream my_backend {
zone my_backend 64k; # Memory size may need to be increased
server 10.0.0.1:8080;
# ...
}
Vor dem Upgrade auf NGINX Plus R25 ist es wichtig, dass die Speicherauslastung für bestehende Upstream-Zonen überprüft wird. Dazu muss sichergestellt werden, dass die NGINX Plus-API aktiviert ist, bevor eine der folgenden Methoden verwendet wird.
Es sollte eine Überprüfung der Registerkarte HTTP-Upstreams des Dashboards zur Überwachung der Live-Aktivitäten erfolgen, wie in diesem Beispiel von demo.nginx.com, wo die Auslastung 54 % beträgt:
Die Verwendung der NGINX Plus API sollte direkt vom Host aus erfolgen, indem folgender Befehl ausgeführt wird.
- Installation des jq-Dienstprogramm, falls erforderlich.
- Setzen der API-Variable auf den Ort, an dem die api-Direktive aktiviert ist.
$ 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
Dynamisches Laden von SSL/TLS-Client-Zertifikaten für Proxy-Verbindungen
Mutual TLS (mTLS) ist eine gängige Authentifizierungsmethode, bei der die Identität von Client und Server überprüft wird. Mit NGINX Plus können die Server in einer Upstream-Gruppe dynamisch und mit Variablen definiert werden. Das bedeutet, dass auch der Nutzer möglicherweise in der Lage sein muss, das TLS-Zertifikat dynamisch auszuwählen, das von NGINX Plus verwendet wird, um sich gegenüber diesen Upstream-Servern zu verifizieren.
NGINX Plus R25 erweitert die für mTLS verwendeten Konfigurationsrichtlinien auf einen Backend-Server, um eine Variable zu akzeptieren, die das Zertifikat darstellt. Die Variable kann auf einen der folgenden Punkte 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 – nützlich für moderne Anwendungsumgebungen, die ständigen Änderungen unterworfen sind. Das Zertifikat und der private Schlüssel können im NGINX Plus-Schlüsselwertspeicher gespeichert werden, was die Sicherheit erhöht, da der private Schlüssel im Speicher und nicht auf der Festplatte gespeichert wird. Ein weiterer Anwendungsfall ist die automatische Zertifikatsrotation, bei der ein API-Aufruf verwendt wird, um Zertifikate im Key-Value-Store zu aktualisieren.
In der folgenden Konfiguration leitet NGINX Plus Anfragen auf der Grundlage des Hostnamens an verschiedene Upstream-Gruppen weiter. Die Proxy-Verbindung wird über mTLS hergestellt, und das entsprechende Client-Zertifikat für jeden Upstream wird dynamisch ausgewählt.
map $host $upstream {
foo.example.com upstream_a;
bar.example.com upstream_b;
default upstream_x;
}
server {
listen 80;
proxy_ssl_certificate /etc/ssl/$upstream.crt;
proxy_ssl_certificate_key /etc/ssl/$upstream.key;
location / {
proxy_pass https://$upstream;
}
}
Erhöhte Sicherheit bei der Verarbeitung von HTTP-Anfragen
Einer der wichtigsten Grundsätze der NGINX-Philosophie ist die kontinuierliche Verbesserung, insbesondere im Bereich der Sicherheit. NGINX nutzt alle verfügbaren Ressourcen, einschließlich der Zusammenarbeit mit Sicherheitsforschern, der Integration der branchenführenden Sicherheitstechnologien von F5 in ihren Produkten und der internen Entwicklungsarbeit.
Als Beispiel für Letzteres führt NGINX Plus R25 mehrere zusätzliche Überprüfungen von HTTP-Anfragen durch, um Anwendungen vor potenziellen Angriffen, wie z. B. Request Smuggling, zu schützen. Bei diesen Bedingungen wird ein Fehler zurückgegeben:
- Eine HTTP/1.0-Anfrage enthält den Transfer-Encoding-Header
- Die Header “Transfer-Encoding” und “Content-Length” sind beide vorhanden
- Leer- oder Steuerzeichen in der Anforderungszeile oder einem Headernamen
- Der Host-Header enthält Leer- oder Steuerzeichen
- Die Methode CONNECT wird verwendet.
Darüber hinaus werden die folgenden Zeichen in einem Proxy-URI jetzt immer umgangen: “, <, >, \, ^, `, {, |, }. Zu beachten ist, dass es sich bei diesen Änderungen um proaktive Sicherheitsverbesserungen handelt, die nicht als Reaktion auf eine bekannte Sicherheitslücke vorgenommen wurden.
Beibehaltung des Status von Gesundheitsprüfungen bei TCP/UDP-Anwendungen über mehrere Ladevorgänge hinweg
NGINX Plus verwendet obligatorische Prüfungen, um sicherzustellen, dass neue, zu Upstream-Gruppen hinzugefügte Server getestet und funktionsfähig sind, bevor Client-Anfragen an sie weitergeleitet werden. In NGINX Plus R23 und früheren Versionen wurden Upstream-Server nach einem Konfigurations-Reload als ungesund eingestuft, unabhängig von ihrem Status vor dem Reload. Infolgedessen sendete NGINX Plus keine Anfragen an einen Server, bevor die erste obligatorische Prüfung bestanden war.
NGINX Plus R24 führte eine optionale Persistenz des Status der obligatorischen Prüfung über Reloads hinweg für HTTP-Anwendungen ein. Wenn der letzte obligatorische Check vor einem Reload erfolgreich war, kann NGINX Plus Anfragen sofort an einen Server senden, anstatt auf den Erfolg eines obligatorischen Checks nach dem Reload warten zu müssen.
NGINX Plus R25 erweitert diese Funktionalität auf TCP/UDP-Anwendungen (im Stream-Kontext). Wie bei HTTP fügen Sie der health_check-Direktive den persistent-Parameter zusammen mit dem mandatory-Parameter hinzu.
stream {
upstream backend {
zone backend 64k;
resolver 10.0.0.53;
server time.example.com:37 resolve;
}
server {
listen 37;
proxy_pass backend;
health_check mandatory persistent;
}
}
Verbesserung am NGINX JavaScript-Modul
Das NGINX JavaScript-Modul (njs) wurde auf die Version 0.6.2 aktualisiert, die mehrere Fehlerkorrekturen und einige funktionale Erweiterungen enthält, die die Kompatibilität mit JavaScript ES6 verbessern.
Variablendeklaration mit den Schlüsselwörtern let und const
NGINX JavaScript unterstützt jetzt die Deklaration von scoped-Variablen mit den Schlüsselwörtern let und const. Frühere Versionen von NGINX Plus und njs unterstützten nur das Schlüsselwort var für die Deklaration und Zuweisung von Variablen. Diese sind notwendig, um die Komplexität zu bewältigen, die oft entsteht, wenn verschiedene Projekte, Programmiersprachen und Entwicklungsteams an gemeinsamen Codebases oder Bibliotheken zusammenarbeiten.
JavaScript ES6 bietet die let– und const-Schlüsselwörter zur Definition von scoped-Variablen:
- let–Variablen sind auf den Bereich einer Blockanweisung oder eines Ausdrucks beschränkt, in dem sie verwendet werden. Im Gegensatz dazu deklariert das var-Schlüsselwort eine Variable global oder lokal für eine ganze Funktion, unabhängig vom Blockbereich.
- const-Variablen sind ähnlich wie Variablen, die mit dem let-Schlüsselwort deklariert werden, auf einen Block beschränkt. Der Wert einer Konstante kann nicht durch Neuzuweisung geändert werden, und sie kann nicht neu deklariert werden.
Unterstützung für alle Promise-Konstruktormethoden
Mit der Hinzufügung der Konstruktormethoden Promise.all(), Promise.allSettled(), Promise.any() und Promise.race() unterstützt njs nun den kompletten Satz der im JavaScript ES6-Standard definierten Konstruktormethoden.
Weitere, ausführlichere Informationen zu den Neuerungen sowie deren genaue Funktionsweise im Release 25 finden sich im offiziellen Blogbeitrag zur Veröffentlichung.