Ankündigung von NGINX Plus R29

Prabhat Dixit

Michael Vernik

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 29 (R29) 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 und verbesserten Funktionen in NGINX Plus R29 gehören:

• Unterstützung für das MQTT-Protokoll– Message Queuing Telemetry Transport (MQTT) ist ein schlankes Protokoll für die Kommunikation zwischen Geräten im Internet der Dinge (IoT). NGINX Plus R29 unterstützt das MQTT-Protokoll mit den Modulen Preread und Filter, die mehrere neue Direktiven und Variablen zur Verwaltung und Absicherung des MQTT-Datenverkehrs bereitstellen.
• SAML-Unterstützung für Authentifizierung und Autorisierung – Security Assertion Markup Language (SAML) ist ein bewährtes Protokoll, das Single Sign-on (SSO) für Webanwendungen ermöglicht. NGINX Plus kann jetzt als SAML-Dienstanbieter (SP) konfiguriert werden, um Benutzer über einen SAML-Identitätsanbieter (IdP) zu authentifizieren.
• Natives OpenTelemetry – OpenTelemetry (OTel) ist ein Framework, das Telemetriedaten (Traces, Metriken und Protokolle) aus entfernten Quellen herstellerunabhängig generiert, erfasst und exportiert. Das neue dynamische NGINX-OTel-Modul bietet eine leistungsstarke OTel-Implementierung für das Tracing von HTTP-Anfragen in NGINX Plus.
• Experimentelle QUIC+HTTP/3-Pakete – Vorschaupakete von NGINX Plus R29 mit QUIC+HTTP/3 sind jetzt verfügbar. Die QUIC-Pakete für NGINX Plus R29 unterstützen HttpContext sowie eine Reihe neuer Direktiven zur Verwaltung von QUIC-Verbindungen und HTTP/3-Datenverkehr.

Wichtige Verhaltensänderungen

Hinweis: Wenn Sie ein Upgrade von einer anderen Version als NGINX Plus R28 durchführen, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den früheren Ankündigungsblogs für alle Versionen zwischen Ihrer aktuellen Version und dieser Version.

Änderungen am Paket-Repository

Das alte Paket-Repository plus-pkgs.nginx.com wird mit der Veröffentlichung von NGINX Plus R29 mit sofortiger Wirkung außer Betrieb genommen. Dieses Repository wurde seit NGINX Plus R25 nicht mehr aktualisiert. Es wird Ihnen daher dringend empfohlen, das Paket-Repository pkgs.nginx.com zu verwenden, das mit NGINX Plus R24 eingeführt wurde.

Änderungen bei der Plattformunterstützung

Neu unterstützte Betriebssysteme:

• Amazon Linux 2023

Ältere Betriebssysteme entfernt:

• Alpine 3.13, dessen Lebenszyklus (EOL) am 1. November 2022 endete

Ältere Betriebssysteme, die als veraltet eingestuft wurden und deren Unterstützung in NGINX Plus R30 eingestellt werden soll:

• Ubuntu 18.04, dessen Support im Juni 2023 endet
• Alpine 3.14, dessen Support im Mai 2023 endet

Anpassung an die Ankündigung zum Supportende von ModSecurity

Im Einklang mit der Ankündigung zum Supportende von ModSecurity wird mit NGINX Plus R29 die Unterstützung für ModSecurity-Pakete eingestellt. Wenn Sie NGINX Plus-Kunde sind und ModSecurity-Pakete verwenden, können Sie sich in Kürze für ein Austauschprogramm zwischen ModSecurity und NGINX App Protect anmelden. Weitere Einzelheiten hierzu werden in Kürze bekannt gegeben. Für weitere Informationen können Sie sich an Ihre Kontaktperson bei F5 wenden.

Neue Funktionen im Detail

Unterstützung für das MQTT-Protokoll

MQTT (Message Queuing Telemetry Transport) ist ein beliebtes und schlankes Publish-Subscribe-Messaging-Protokoll, das sich ideal eignet, um IoT-Geräte und Anwendungen (Clients) über das Internet miteinander zu verbinden. Es ermöglicht Clients, Nachrichten zu einem bestimmten Topic zu veröffentlichen und andere Topics zu abonnieren. Abonnierende Clients erhalten alle Nachrichten, die in dem jeweiligen Topic veröffentlicht werden. Dies ermöglicht einen effizienten und fehlertoleranten Datenaustausch zwischen zahlreichen Geräten und Diensten.

Das Herzstück einer MQTT-Architektur ist ein Broker. Ein Broker ist ein Server, der Clients und die von ihnen abonnierten Topics erfasst, Nachrichten verarbeitet und diese an die entsprechenden Systeme weiterleitet. NGINX Plus R29 unterstützt MQTT 3.1.1 und MQTT 5.0. Er fungiert als Proxy zwischen Clients und Brokern, wodurch die Systemarchitektur vereinfacht, Aufgaben ausgelagert und Kosten gesenkt werden.

Der anfängliche MQTT-Funktionsumfang ermöglicht:

• Lastverteilung für MQTT-Broker
• Sitzungspersistenz (erneute Verbindung von Clients mit demselben Broker)
• TLS-Terminierung
• Clientzertifikatsauthentifizierung
• Parsen und Umschreiben von CONNECT-Nachrichten

Das MQTT-Protokoll definiert mehrere Nachrichtentypen, darunter CONNECT, PUBLISH und SUBSCRIBE. NGINX Plus R29 kann Teile von MQTT-CONNECT-Nachrichten aktiv analysieren und umschreiben. Dadurch werden Konfigurationsszenarien ermöglicht, die bisher nur mit benutzerdefinierten Skripten realisierbar waren.

Das Parsen und Umschreiben von MQTT-Nachrichten muss im Stream-Kontext einer NGINX-Konfigurationsdatei definiert werden und wird durch die Module ngx_stream_mqtt_preread_module
und ngx_stream_mqtt_filter_module ermöglicht.

MQTT-Beispiele

Durch Ändern der standardmäßigen Client-ID, die von einem MQTT-Gerät gesendet wird, kann NGINX vertrauliche Informationen wie die Seriennummer eines Geräts verbergen. In diesem ersten Beispiel wird die ID durch die IP-Adresse des Geräts ersetzt.

Hinweis: Es wird nicht empfohlen, die IP-Adresse eines Geräts in einer Produktionsumgebung als MQTT-Client-ID zu verwenden.

stream {      mqtt on;
      server {
          listen 1883;
          proxy_pass 10.0.0.8:1883;
          mqtt_set_connect clientid '$remote_addr';
      }
  }

Aufgrund der kurzlebigen Natur von MQTT-Clients können Sie sich beim Einrichten persistenter Sitzungen mit Brokers, auf die die Last verteilt wird, nicht einfach auf den Hostnamen oder die IP-Adresse eines Geräts verlassen. In diesem Beispiel dient die MQTT-Client-ID eines Geräts als Hash-Schlüssel, um Verbindungen zu einzelnen MQTT-Brokers in einem Cluster mit Lastverteilung aufrechtzuerhalten:

stream {      mqtt_preread on;
      upstream brokers{
          zone tcp_mem 64k;
          hash $mqtt_preread_clientid consistent;
          server 10.0.0.7:1883; # mqtt broker 1
          server 10.0.0.8:1883; # mqtt broker 2
          server 10.0.0.9:1883; # mqtt broker 3
      }
      server {
          listen 1883;
          proxy_pass brokers;
          proxy_connect_timeout 1s;
      }
  }

Nächste Schritte

Zukünftige Weiterentwicklungen von MQTT in NGINX Plus könnten das Parsen weiterer MQTT-Nachrichtentypen sowie eine tiefergehende Analyse der CONNECT-Nachricht umfassen, um Funktionen wie die folgenden zu ermöglichen:

• Zusätzliche Mechanismen zur Authentifizierung und Zugriffskontrolle
• Schutz von Brokern durch Ratenbegrenzung für „geschwätzige“ Clients
• Nachrichtentelemetrie und Verbindungsmetriken

Wir würden uns sehr über Ihr Feedback zu den Funktionen freuen, die Ihnen am wichtigsten sind. Teilen Sie uns Ihre Meinung in den Kommentaren mit.

SAML-Unterstützung für Authentifizierung und Autorisierung

SAML (Security Assertion Markup Language) ist ein offener Föderationsstandard, der es einem Identitätsanbieter (IdP) ermöglicht, Benutzer für den Zugriff auf eine Ressource zu authentifizieren (um sicherzustellen, dass der Endbenutzer tatsächlich die Person ist, für die er sich ausgibt) und diese Authentifizierungsinformationen zusammen mit den Zugriffsrechten des Benutzers für diese Ressource zur Autorisierung an einen Dienstanbieter (SP) zu übermitteln.

SAML hat sich seit Langem als sicheres Verfahren für den Austausch von Identitätsdaten bewährt und ist ein weitverbreitetes Protokoll für den Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen einem IdP und einem SP.

Zu den wichtigsten Gründen, warum sich Unternehmen und Behörden für SAML entscheiden, gehören:

• Effiziente Verwaltung einer großen Anzahl von Identitäten
• Verbesserte, konsistente und einheitliche Identitätssicherheit für Kunden und Mitarbeiter
• Verbesserte betriebliche Effizienz durch die Standardisierung von Identitätsmanagementprozessen
• Effiziente Erfüllung regulatorischer Anforderungen

SAML bietet außerdem mehrere Vorteile:

• Bessere Benutzererfahrung: Durch die SSO-Integration und die zentrale Überprüfung der Authentifizierung beim IdP ermöglicht SAML Benutzern, sich einmalig zu authentifizieren und damit auf alle verbundenen Dienste zuzugreifen. Dies verbessert die Benutzererfahrung und spart Zeit, da sich Benutzer nicht mehr mehrere Anmeldedaten für verschiedene Anwendungen merken müssen.
• Erhöhte Sicherheit: Abhängig von den Sicherheits- und Authentifizierungsrichtlinien Ihres Unternehmens können sich Benutzer über ein SSO-Authentifizierungsverfahren entweder an der SP-Schnittstelle (SP-initiiertes SSO) oder direkt an der IdP-Schnittstelle (IdP-initiiertes SSO) anmelden. Dadurch werden Sicherheitsrisiken durch potenziell schwache und/oder mehrfach verwendete Passwörter reduziert.
• Geringere Verwaltungskosten: SAML ermöglicht es Unternehmen, die Verantwortung für die Identitätsverwaltung an einen vertrauenswürdigen IdP auszulagern. Dadurch sinken die Kosten für die Pflege von Kontoinformationen und die damit verbundenen Aufwendungen.
• Standardisiertes Protokoll: SAML wurde nach dem Prinzip entwickelt, die Sicherheit so weit wie möglich von der Anwendungslogik zu entkoppeln. Es handelt sich um ein standardisiertes Protokoll, das von nahezu allen IdPs und Zugriffsverwaltungssystemen unterstützt wird. Es abstrahiert das Sicherheitsframework von Plattformarchitekturen und spezifischen Herstellerimplementierungen und ermöglicht dadurch robuste Sicherheit sowie eine zuverlässige Integration zwischen Systemen.

Die aktuelle Referenzimplementierung von SAML verwendet SAML 2.0 und basiert auf dem NGINX JavaScript (njs)-Framework. In dieser Implementierung fungiert NGINX Plus als SAML-SP und kann so an einer SSO-Konfiguration mit einem SAML-IdP teilnehmen. Die aktuelle Implementierung ist außerdem vom Schlüssel-Wert-Speicher abhängig. Dabei handelt es sich um eine bestehende Funktion von NGINX Plus, weshalb sie ohne zusätzliche Anpassungen nicht für NGINX Open Source geeignet ist.

Die SAML-Unterstützung in NGINX Plus ist als Referenzimplementierung auf GitHub verfügbar. Das GitHub-Repository enthält eine Beispielkonfiguration mit Anweisungen zur Installation, Konfiguration und Feinabstimmung für bestimmte Anwendungsfälle.

Natives OpenTelemetry

OpenTelemetry (OTel) ist eine Technologie und ein Standard zur Überwachung, Ablaufverfolgung, Fehlerbehebung und Optimierung von Anwendungen. OTel erfasst dazu Telemetriedaten aus verschiedenen Quellen, beispielsweise aus Proxys, Anwendungen oder anderen Diensten eines bereitgestellten Anwendungs-Stacks.

Als protokollfähiger Reverse-Proxy und Load Balancer ist NGINX ideal dafür geeignet, Telemetrieaufrufe zur Nachverfolgung von Anwendungsanfragen und -antworten zu initiieren. Zwar sind OTel-Module von Drittanbietern bereits seit einiger Zeit verfügbar, doch wir freuen uns, die native Unterstützung für OTel in NGINX Plus mit einem neuen dynamischen Modul bekannt geben zu können.

Das neue Modul „ngx_otel_module“ kann mithilfe des Pakets „installiert“ nginx-plus-module-otel werden und bietet gegenüber Modulen von Drittanbietern mehrere wesentliche Verbesserungen, darunter:

• Bessere Performance – Bei den meisten OTel-Implementierungen sinkt die Performance der Anfrageverarbeitung bei aktiviertem Tracing um bis zu 50 %. Unser neues natives Modul begrenzt diese Beeinträchtigung auf etwa 10–15 %.
• Einfache Bereitstellung – Die Telemetrieerfassung lässt sich direkt in den NGINX-Konfigurationsdateien einrichten und konfigurieren.
• Vollständig dynamisches variablenbasiertes Sampling – Die Möglichkeit, eine bestimmte Sitzung anhand eines Cookies/Tokens nachzuverfolgen und das Modul dynamisch über die NGINX Plus API und die Schlüssel-Wert-Speicher-Module zu steuern.

Weitere Informationen zum dynamischen OTel-Modul finden Sie in der NGINX-Dokumentation.

Beispiele für OTel-Tracing

Hier ist ein Beispiel für grundlegendes OTel-Tracing einer Anwendung, die direkt von NGINX bereitgestellt wird:

load_module modules/ngx_otel_module.so;  events {}
  http {
      otel_exporter {
          endpoint localhost:4317;
      }
   
      server {
          listen 127.0.0.1:8080;
          
          otel_trace on;
          otel_span_name app1;
      }
  }

Im nächsten Beispiel übernehmen wir Trace-Kontexte aus eingehenden Anfragen und zeichnen Spans nur dann auf, wenn ein übergeordneter Span erfasst wird. Außerdem geben wir Trace-Kontexte und Sampling-Entscheidungen an vorgelagerte Server weiter.

load_module modules/ngx_otel_module.so;  http {
      server {
          location / {
              otel_trace $otel_parent_sampled;
              otel_trace_context propagate;
              proxy_pass http://backend;
          }
      }
  }

In diesem verhältnisbasierten Beispiel wird das Tracing für einen bestimmten Prozentsatz des Datenverkehrs konfiguriert (in diesem Fall 10 %):

http {      # trace 10% of requests
      split_clients "$otel_trace_id" $ratio_sampler {
          10%     on;
          *       off;
      }
      # or we can trace 10% of user sessions
      split_clients "$cookie_sessionid" $session_sampler {
          10%     on;
          *       off;
      }
      server {
          location / {
              otel_trace $ratio_sampler;
              otel_trace_context inject;
              proxy_pass http://backend;
          }
      }
  }

In diesem API-gesteuerten Beispiel wird das Tracing aktiviert, indem der Schlüssel-Wert-Speicher über den Endpunkt /api bearbeitet wird:

http {      keyval "otel.trace" $trace_switch zone=name;
      server {
          location / {
              otel_trace $trace_switch;
              otel_trace_context inject;
              proxy_pass http://backend;
          }
          location /api {
              api write=on;
          } 
      }
  }

Experimentelle QUIC+HTTP/3-Pakete

Im Anschluss an unsere Ankündigung von binären Vorschaupaketen für NGINX Open Source freuen wir uns, experimentelle QUIC-Pakete für NGINX Plus R29 ankündigen zu können. Damit kann HTTP/3 mit NGINX Plus getestet und evaluiert werden.

Mit einem neuen zugrunde liegenden Protokoll-Stack bringt HTTP/3 UDP und QUIC in die Transportschicht. QUIC ist ein verschlüsseltes Transportprotokoll, das TCP durch Verbindungsmultiplexing und die Behebung von Problemen wie Head-of-Line-Blocking verbessern soll. Es implementiert eine Reihe von TCP-Funktionen aus HTTP/1.1 und HTTP/2 neu und erweitert sie, darunter Verbindungsaufbau, Überlastungssteuerung und zuverlässige Übertragung. Anders als bei HTTP/1.1 und HTTP/2, bei denen TLS eine separate Schicht bildet, ist TLS bei QUIC zudem ein integraler Bestandteil. Das bedeutet, dass HTTP/3-Nachrichten grundsätzlich sicher sind, da sie standardmäßig über eine verschlüsselte Verbindung gesendet werden.

Für sichere Kommunikation und kryptografische Funktionen greift NGINX Plus in der Regel auf OpenSSL zurück und nutzt dabei die mit den Betriebssystemen ausgelieferten SSL/TLS-Bibliotheken. Da die TLS-Schnittstellen von QUIC zum Zeitpunkt der Erstellung dieses Artikels jedoch nicht von OpenSSL unterstützt werden, sind Bibliotheken von Drittanbietern erforderlich, um die fehlende, für HTTP/3 benötigte TLS-Funktionalität bereitzustellen.

Um dieses Problem zu lösen, haben wir eine OpenSSL-Kompatibilitätsschicht für QUIC entwickelt, sodass TLS-Bibliotheken von Drittanbietern wie quictls, BoringSSL und LibreSSL nicht mehr erstellt und ausgeliefert werden müssen. Dadurch lässt sich die durchgängige QUIC+HTTP/3-Funktionalität in NGINX bereitstellen, ohne den Aufwand einer benutzerdefinierten TLS-Implementierung und ohne Abhängigkeit von den Zeitplänen und Roadmaps der Drittanbieterbibliotheken.

Hinweis: Die OpenSSL-Kompatibilitätsschicht ist in den experimentellen QUIC+HTTP/3-Paketen von NGINX Plus enthalten und erfordert OpenSSL 1.1.1 oder höher, um TLSv1.3 bereitzustellen (das vom QUIC-Protokoll vorausgesetzt wird). 0-RTT wird noch nicht unterstützt.

QUIC+HTTP/3-Beispielkonfiguration

Sehen wir uns eine Beispielkonfiguration für QUIC+HTTP/3 in NGINX Plus an:

http {      log_format quic '$remote_addr - $remote_user [$time_local]'
      '"$request" $status $body_bytes_sent '
      '"$http_referer" "$http_user_agent" "$http3"';
      access_log logs/access.log quic;
      server {
          # for better compatibility it's recommended
          # to use the same port for quic and https
          listen 8443 quic reuseport;
          listen 8443 ssl;
          ssl_certificate     certs/example.com.crt;
          ssl_certificate_key certs/example.com.key;
          location / {
              # required for browsers to direct them into quic port
              add_header Alt-Svc 'h3=":8443"; ma=86400';
          }
      }
  }

Ähnlich wie bei unserer Implementierung von HTTP/2 werden QUIC+HTTP/3-Verbindungen, wenn NGINX Plus als Proxy fungiert, auf der Clientseite hergestellt und beim Herstellen einer Verbindung zu Backend- und Upstream-Diensten in HTTP/1.1 umgewandelt.

Die experimentellen QUIC+HTTP/3-Pakete für NGINX Plus sind über ein separates Repository verfügbar, auf das mit vorhandenen Zertifikaten und Schlüsseln für NGINX Plus zugegriffen werden kann. Die Installation der experimentellen QUIC-Pakete ähnelt einer standardmäßigen NGINX Plus-Installation. Verwenden Sie unbedingt das QUIC-Repository, wie in den Installationsschritten hervorgehoben.

Weitere Informationen zur Konfiguration von NGINX für QUIC+HTTP/3 finden Sie unter „NGINX für QUIC+HTTP/3 konfigurieren“. Informationen zu allen neuen Direktiven und Variablen finden Sie im Abschnitt „Konfiguration“ der nginx-quic-README-Datei.

Nächste Schritte

In naher Zukunft planen wir, den QUIC+HTTP/3-Code in den Mainline-Branch von NGINX zu integrieren. Die neueste Mainline-Version von NGINX mit QUIC+HTTP/3-Unterstützung wird anschließend in eine der folgenden Versionen von NGINX Plus übernommen. Eine Ankündigung zur offiziellen Verfügbarkeit der QUIC+HTTP/3-Unterstützung in NGINX Plus ist im Laufe dieses Jahres zu erwarten.

Weitere Verbesserungen in NGINX Plus R29

Änderungen an OpenID Connect

Die Unterstützung für OpenID Connect (OIDC) wurde mit NGINX Plus R15 eingeführt und in nachfolgenden Versionen erheblich erweitert. NGINX Plus R29 erweitert OIDC um die folgenden Funktionen.

Unterstützung für Zugriffstoken

Zugriffstoken werden bei der tokenbasierten Authentifizierung verwendet, damit ein OIDC-Client im Namen des Benutzers auf eine geschützte Ressource zugreifen kann. NGINX Plus erhält ein Zugriffstoken, nachdem sich ein Benutzer erfolgreich authentifiziert und den Zugriff autorisiert hat, und speichert es anschließend im Schlüssel-Wert-Speicher. NGINX Plus kann dieses Token im HTTP-Autorisierungsheader als Bearer-Token bei jeder an die nachgelagerte Anwendung gesendeten Anfrage weitergeben.

Hinweis: NGINX Plus überprüft nicht bei jeder Anfrage die Gültigkeit des Zugriffstokens (wie beim ID-Token) und kann daher nicht feststellen, ob das Zugriffstoken bereits abgelaufen ist. Wenn die Gültigkeitsdauer des Zugriffstokens kürzer ist als die des ID-Tokens, müssen Sie die Direktive proxy_intercept_errors auf „on“ setzen. Dadurch werden 401 Unauthorized-Antworten abgefangen und an NGINX umgeleitet, sodass das Zugriffstoken aktualisiert wird.

Weitere Informationen zu OpenID Connect und zur Validierung von JSON Web Tokens (JWT) mit NGINX Plus finden Sie unter „Authentifizierung von Benutzern für bestehende Anwendungen mit OpenID Connect und NGINX Plus“.

Hinzugefügte Argumente im OIDC-Authentifizierungsendpunkt

Einige Identitätsanbieter wie Keycloak ermöglichen es, der Authentifizierungsanfrage zusätzliche Abfrageparameter hinzuzufügen, um weitere Funktionen zu aktivieren. Bei Keycloak kann beispielsweise durch Hinzufügen des Parameters kc_idp_hint zur Authentifizierungsanfrage ein standardmäßiger IdP angegeben werden. Im Rahmen dieser Erweiterung können Benutzer zusätzliche Argumente für den OIDC-Autorisierungsendpunkt angeben.

Erweiterte SSL-Zähler im Prometheus-njs-Modul

In NGINX Plus R28 haben wir Unterstützung für zusätzliche SSL-Zähler für Handshake-Fehler und Fehler bei der Zertifikatsvalidierung in den HTTP- und Stream-Modulen sowohl für clientseitige als auch für serverseitige Verbindungen hinzugefügt. Unser Prometheus-njs-Modul, das Metriken von NGINX Plus in ein Prometheus-konformes Format konvertiert, unterstützt nun diese Zähler.

Neue internal_redirect-Direktive

Die neue internal_redirect-Direktive und das zugehörige Modul ermöglichen interne Weiterleitungen nach der Überprüfung der Verarbeitungslimits für Anfragen, Verbindungen und Zugriffe.

Hier ist ein Beispiel für eine internal_redirect-Konfiguration:

http {      limit_req_zone $jwt_claim_sub zone=jwt_sub:10m rate=1r/s; 
       server {
          location / {
              auth_jwt "realm";
              auth_jwt_key_file key.jwk;
               internal_redirect @rate_limited;
          }
           location @rate_limited {
              internal;
              limit_req zone=jwt_sub burst=10;
              proxy_pass http://backend;
          }
      }
  }

Im obigen Beispiel wird die JWT-Authentifizierung im location-Block durchgeführt. Ist das Token gültig, wird die Anfrage an den internen Content-Handler @rate_limited weitergeleitet, wo basierend auf dem Wert des sub-Claims eine Begrenzung der Anfragerate angewendet wird. Dies geschieht im JWT, bevor die Anfrage an den Upstream-Dienst weitergeleitet wird.

Diese spezielle Konfiguration verhindert einen Denial-of-Service-Angriff (DoS), bei dem ein Angreifer eine Flut von Anfragen mit lesbaren JWTs sendet, in deren Feld „sub“ ein bestimmter Benutzer angegeben ist. Diese Anfragen würden die Authentifizierung nicht bestehen, aber dennoch auf das Ratenlimit angerechnet werden. Indem Sie das JWT authentifizieren, bevor Sie die Anfrage an den Content-Handler weiterleiten, stellen Sie sicher, dass nur gültige Anfragen auf das Ratenlimit angerechnet werden.

Von NGINX Open Source übernommene Änderungen

NGINX Plus R29 basiert auf NGINX Open Source 1.23.4 und übernimmt funktionale Änderungen und Fehlerbehebungen, die seit der Veröffentlichung von NGINX Plus R28 vorgenommen wurden (in NGINX 1.23.3 bis 1.23.4).

Änderungen

• Das TLSv1.3-Protokoll ist jetzt standardmäßig aktiviert und der Standardwert für diese Direktiven:
• ssl_protocols (HTTP, Stream, Mail)
• proxy_ssl_protocols (HTTP, Stream)
• grpc_ssl_protocols
• uwsgi_ssl_protocols
• zone_sync_ssl_protocols
• NGINX gibt jetzt eine Warnung aus, wenn Protokollparameter eines Listening-Sockets neu definiert werden.
• NGINX schließt Verbindungen nun verzögert, wenn der Client HTTP-Pipelining verwendet hat.
• Die Protokollierungsstufe für die SSL-Fehler „data length too long“, „length too short“, „bad legacy version“, „no shared signature algorithms“, „bad digest length“, „missing sigalgs extension“, „encrypted length too long“, „bad length“, „bad key update“, „mixed handshake and non-handshake data“, „ccs received early“, „data between ccs and finished“, „packet length too long“, „too many warn alerts“, „record too small“ und „got a fin before a ccs“ wurde von „crit“ auf „info“ herabgesetzt.

Funktionen

• Bytebereiche werden jetzt im ngx_http_gzip_static_module unterstützt.

Fehlerbehebungen

• Nicht funktionierende Portbereiche in der listen-Direktive wurden korrigiert.
• Es wurde ein Fehler behoben, durch den möglicherweise eine falsche Location zur Verarbeitung einer Anfrage ausgewählt wurde, wenn in der Konfiguration eine Präfix-Location mit mehr als 255 Zeichen verwendet wurde.
• Unterstützung für Nicht-ASCII-Zeichen in Dateinamen unter Windows hinzugefügt, die von ngx_http_autoindex_module, ngx_http_dav_module und der include-Direktive nicht unterstützt wurden.
• Ein Socket-Leck wurde behoben, das gelegentlich auftrat, wenn HTTP/2 und die error_page-Direktive verwendet wurden, um Fehler mit dem Code 400 umzuleiten.
• Fehlermeldungen bei der Protokollierung in syslog wurden korrigiert, da sie nicht darauf hinwiesen, dass die Fehler während der Protokollierung in syslog aufgetreten waren.
• Die Verarbeitung blockierter Leseereignisse von Clients in proxy -r wurde korrigiert.
• Ein Fehler wurde behoben, der gelegentlich beim Lesen des Headers des PROXY-Protokolls Version 2 mit einer großen Anzahl von TLVs auftrat.
• Ein Segmentierungsfehler wurde behoben, der gelegentlich in einem Worker-Prozess auftrat, wenn SSI zur Verarbeitung von Unteranfragen verwendet wurde, die von anderen Modulen erstellt wurden.
• Es wurde ein Problem behoben, durch das NGINX bei ungepuffertem Proxying möglicherweise die CPU stark auslastete, wenn SSL-Verbindungen zu Backends verwendet wurden.

Problemumgehungen

• zip-Filter konnte den vorab zugewiesenen Speicher nicht verwenden-Warnmeldungen wurden bei der Verwendung von zlib-ng in den Protokollen angezeigt.
• Wenn ein in der listen-Direktive verwendeter Hostname in mehrere Adressen aufgelöst wird, ignoriert NGINX nun doppelte Einträge unter diesen Adressen.

Eine vollständige Liste der neuen Funktionen, Änderungen, Fehlerbehebungen und Problemumgehungen, die aus diesen Releases übernommen wurden, finden Sie in der Datei „CHANGES“.

Änderungen am NGINX-JavaScript-Modul

NGINX Plus R29 enthält Änderungen aus den Versionen 0.7.9 bis 0.7.12 des NGINX-JavaScript-Moduls (njs). njs wurde um mehrere interessante Funktionen erweitert, darunter:

• Erweiterte Unterstützung für die Fetch API
• Erweiterte Web Crypto API
• Unterstützung für XML-Dokumente
• XML-Dokumentanalyse
• XMLNode-API zum Ändern von XML-Dokumenten
• Komprimierungsunterstützung für das Zlib-Modul

Eine vollständige Liste aller Funktionen, Änderungen und Fehlerbehebungen von njs Version 0.7.9 bis 0.7.12 finden Sie im njs-Änderungsprotokoll.

Erweiterte Unterstützung der Fetch API

Headers(), Request(), und Response()-Konstruktoren werden der Fetch API zusammen mit weiteren Verbesserungen hinzugefügt:

async function makeRequest(uri, headers) {      let h = new Headers(headers);
      h.delete("bar");
      h.append("foo", "xxx");
      let r = new Request(uri, {headers: h});
      return await ngx.fetch(r);
  }

Erweiterte Web Crypto API

Die Web Crypto API wurde um die Unterstützung des JSON-Web-Key-Formats (JWK) erweitert. importKey() akzeptiert nun Schlüssel im JWK-Format als Eingabe:

async function importSigningJWK(jwk) {     return await crypto.subtle.importKey('jwk', jwk,
                                          {name: "RSASSA-PKCS1-v1_5"},
                                          true, ['sign']);
  }

Mit njs 0.7.10 wurden außerdem die Methoden generateKey() und exportKey() hinzugefügt. Mit der Methode generateKey() können Sie einen neuen Schlüssel für symmetrische Algorithmen oder ein Schlüsselpaar für Public-Key-Algorithmen erzeugen. Die Methode exportKey() verwendet ein CryptoKey-Objekt als Eingabe und gibt den Schlüssel in einem externen, portablen Format zurück. Sie unterstützt das JWK-Format, um den Schlüssel als JSON-Objekt zu exportieren.

Weitere Informationen finden Sie unter „Web Crypto API“.

Unterstützung für XML-Dokumente

Das XML-Modul wurde in njs 0.7.10 hinzugefügt, um native Unterstützung für die Arbeit mit XML-Dokumenten bereitzustellen.

Parsen von XML-Dokumenten

Sie können nun eine Zeichenfolge oder einen Puffer als XML-Dokument parsen. Dabei wird ein XMLDoc-Wrapper-Objekt zurückgegeben, das das geparste XML-Dokument repräsentiert:

const xml = require("xml");  let data = `<note><to b="bar" a= "foo">Tove</to><from>Jani</from></note>`;
  let doc = xml.parse(data);
   
  console.log(doc.note.to.$text) /* 'Tove' */
  console.log(doc.note.to.$attr$b) /* 'bar' */
  console.log(doc.note.$tags[1].$text) /* 'Jani' */

XMLNode-API zum Ändern von XML-Dokumenten

Die XMLNode-API wurde in njs 0.7.11 hinzugefügt, um XML-Dokumente zu bearbeiten:

Const xml = require("xml");  let data = `<note><to b="bar" a="foo">Tove</to><from>Jani</from></note>`;
  let doc = xml.parse(data);
   
  doc.$root.to.$attr$b = 'bar2';
  doc.$root.to.setAttribute('c', 'baz');
  delete doc.$root.to.$attr$a;
   
  console.log(xml.serializeToString(doc.$root.to))
  /* '<to b="bar2" c="baz">Tove</to>' */
   
  doc.$root.to.removeAllAttributes();
  doc.$root.from.$text = 'Jani2';
   
  console.log(xml.serializeToString(doc))
  /* '<note><to>Tove</to><from>Jani2</from></note>' */
   
  doc.$root.to.$tags = [xml.parse(`<a/>`), xml.parse(`<b/>`)];
  doc.$root.to.addChild(xml.parse(`<a/>`));
  console.log(xml.serializeToString(doc.$root.to))
  /* '<to><a></a><b></b><a></a></to>' */
   
  doc.$root.to.removeChildren('a');
   
  console.log(xml.serializeToString(doc.$root.to))
  /* '<to><b></b></to>' */

Weitere Informationen zu allen XML-bezogenen Verbesserungen finden Sie in der XML-Dokumentation.

Unterstützung der Komprimierung mit dem Zlib-Modul

Das zlib-Modul wurde in njs 0.7.12 hinzugefügt und bietet Komprimierungsfunktionen mithilfe der Algorithmen „deflate“ und „inflate“.

Const zlib = require('zlib');  zlib.deflateRawSync('αβγ').toString('base64')
  /* "O7fx3KzzmwE=" */
   
  zlib.inflateRawSync(Buffer.from('O7fx3KzzmwE=', 'base64')).toString()
  /* "αβγ" */

Weitere Informationen zu zlib finden Sie in der zlib-Dokumentation.

NGINX Plus upgraden oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R29 durchzuführen. Neben all den großartigen neuen Funktionen erhalten Sie damit auch mehrere zusätzliche Fehlerbehebungen und Verbesserungen. Zudem kann NGINX Sie bei einer Supportanfrage besser unterstützen, wenn Sie eine aktuelle Version verwenden.

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 Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über die Autoren

Prabhat Dixit

Weitere Blogbeiträge von Prabhat Dixit

Michael Vernik

Weitere Blogbeiträge von Michael Vernik