Ankündigung von NGINX Plus R10

Owen GarrettSenior Director, Produktmanagement

[Redaktion – Das NGINX ModSecurity WAF-Modul für NGINX Plus wurde zum 1. April 2022 offiziell aus dem Verkauf genommen und erreicht am 31. März 2024 sein Lebensende. Weitere Informationen finden Sie unter F5 NGINX ModSecurity WAF erreicht das Lebensende<.htmla> in unserem Blog.]

Wir freuen uns, NGINX Plus Release 10 (R10), unsere bislang bedeutendste Version, ankündigen zu können. NGINX Plus erweitert NGINX Open Source um fortschrittliche Funktionen und preisgekrönten Support und bietet Kunden damit eine umfassende Lösung für die Anwendungsbereitstellung. Mit diesem Release stellen wir zahlreiche neue Funktionen bereit, die die Sicherheit und Performance der über NGINX Plus bereitgestellten Anwendungen erheblich verbessern. Hinzu kommen weitere Funktionen für eine optimierte Netzwerkintegration sowie für die skriptbasierte Anpassung von NGINX Plus.

[Redaktion – Weitere Informationen zu wichtigen neuen Funktionen in NGINX Plus R10 finden Sie in diesen weiterführenden Ressourcen:

• API-Clients mit JWT und NGINX Plus authentifizieren
• NGINX Plus R10 nutzt die Leistungsfähigkeit von IBM POWER
• Benutzerauthentifizierung für bestehende Anwendungen mit OpenID Connect und NGINX Plus
• Verwendung des NGINX-JavaScript-Moduls zur schrittweisen Migration von Clients auf einen neuen Server
• IP-Transparenz und Direct Server Return mit NGINX und NGINX Plus als transparentem Proxy
• Was ist neu in NGINX Plus R10? (Webinar auf Abruf)

]

NGINX Plus R10 enthält die erste Version unserer Web Application Firewall (WAF), die auf ModSecurity basiert und vollständig von NGINX, Inc. unterstützt wird. Angriffe auf Webanwendungen haben im vergangenen Jahr um 50 % zugenommen und DDoS-Angriffe haben sich mehr als verdoppelt, so Akamai. Inzwischen besteht für jede Anwendung die Gefahr, angegriffen zu werden. Die NGINX ModSecurity WAF schützt Webanwendungen vor böswilligen Nutzern und bietet Kunden ein vielseitiges Tool, mit dem sie ihre Anwendungen und Daten schützen können.

NGINX ModSecurity WAF blockiert Eindringlinge

NGINX ModSecurity WAF basiert auf der neuen Software ModSecurity 3 und wird nativ in NGINX Plus ausgeführt. Die Lösung ist gegen Aufpreis über unser Repository für dynamische Module erhältlich, wird von NGINX, Inc. unterstützt und wurde umfassend mit NGINX Plus getestet. Wir arbeiten mit Trustwave zusammen und werden weiterhin getestete Updates bereitstellen, wenn wir Funktionen hinzufügen, die Leistung verbessern und etwaige Probleme beheben.

Zwei weitere neue Funktionen verbessern die Sicherheitsfunktionen von NGINX Plus zusätzlich:

• JSON Web Tokens – Viele unserer Kunden nutzen NGINX Plus als API-Gateway und haben uns um eine einheitliche, standardisierte Möglichkeit gebeten, den Zugriff auf APIs auf der NGINX Plus-Ebene zu authentifizieren. Um diesem Bedarf gerecht zu werden, unterstützen wir ab dieser Version die Authentifizierung mit JSON Web Tokens (JWTs). NGINX Plus kann nun ein JWT validieren, bevor Clients Zugriff auf APIs erhalten. Mit dieser Funktion können Anwendungsadministratoren den Zugriff auf ihre APIs mithilfe eines offenen Standards absichern und vermeiden so die Abhängigkeit von einem proprietären Standard. Die native JWT-Unterstützung reduziert zudem die Komplexität für Anwendungsadministratoren, indem Authentifizierungsvorgänge – etwa die Validierung von OAuth 2.0-konformen OpenID Connect-Tokens – von den Anwendungsservern auf NGINX Plus verlagert werden.
• „Dual-Stack“-Unterstützung für ECC- und RSA-Zertifikate – Mit NGINX Plus R10 können Sie SSL/TLS-Dienste sowohl mit RSA- als auch mit ECC-Zertifikaten bereitstellen. NGINX Plus wählt anhand der Fähigkeiten des jeweiligen Clients das optimale Zertifikat aus. So können moderne Clients die schnelleren ECC-Zertifikate nutzen, während ältere Clients, die ausschließlich RSA unterstützen, weiterhin unterstützt werden. ECC-Zertifikate können bis zu dreimal schneller sein als RSA-Zertifikate mit vergleichbarer Sicherheitsstärke. Dadurch sind mehr SSL/TLS-Verbindungen pro Server und schnellere SSL/TLS-Handshakes möglich.

Zusätzlich zu den Sicherheitsfunktionen bietet NGINX Plus R10 Folgendes:

• Unterstützung für transparente Proxys – Obwohl viele moderne HTTP-Anwendungen so konfiguriert werden können, dass sie einen X-Forwarded-For-Header verwenden, greifen einige ältere Anwendungen und andere TCP- oder UDP-Dienste für Protokollierungs-, Sicherheits- oder Authentifizierungszwecke auf die Quell-IP-Adresse der Transaktion zurück. NGINX Plus kann nun die Quell-IP-Adresse und den Quellport von HTTP-Verbindungen sowie von TCP-Verbindungen und UDP-Datagrammen, die an Upstream-Server weitergeleitet werden, vortäuschen. Dies ermöglicht IP-Transparenz. Bei dieser Konfiguration sendet NGINX Plus Pakete mit der IP-Adresse des entfernten Clients, sodass der Upstream-Server die Pakete als von dieser Adresse stammend erkennt und nicht von einer lokalen IP-Adresse auf dem NGINX Plus-Server. Mit dieser Funktion kann außerdem Direct Server Return für UDP-basierte Protokolle aktiviert werden.
• Unterstützung für das NGINX JavaScript-Modul – Das NGINX JavaScript-Modul ist die Konfigurations- und Steuerungssprache der nächsten Generation für NGINX und NGINX Plus. Es ermöglicht Benutzern eine umfassende und präzise Kontrolle darüber, wie ihre Anwendungen bereitgestellt und geschützt werden. In dieser Vorabversion bietet das NGINX JavaScript-Modul mehr Kontrolle über den HTTP-, TCP- und UDP-Datenverkehr, indem es Antworten generiert und präzise Entscheidungen trifft, um Anfragen an die optimalen Server weiterzuleiten.

• Weitere Verbesserungen beim TCP- und UDP-Load-Balancing – Erweiterungen des Stream-Moduls unterstützen nun zusätzliche NGINX-Variablen, Berechnungen mithilfe der map-Direktive, A/B-Tests mit der split_clients-Direktive, Geo- und GeoIP-Operationen sowie selektives Routing (Variablenparameter für die proxy_pass-Direktive). Mit diesen Erweiterungen können Sie anspruchsvollere Richtlinien für das TCP- und UDP-Load-Balancing erstellen, die auf der NGINX-Konfigurationssprache und der neuen NGINX-JavaScript-Integration basieren.

NGINX Plus R10 im Detail

NGINX ModSecurity Web Application Firewall

Das wichtigste neue Feature in NGINX Plus R10 ist die erste Version unserer WAF, die auf der bekannten und bewährten ModSecurity-Technologie basiert. Seit der ersten Open-Source-Veröffentlichung im Jahr 2002 trägt ModSecurity dazu bei, einige der weltweit größten Webangebote vor böswilligen Benutzern zu schützen. Die Technologie wird häufig als „Schweizer Taschenmesser®“ der Sicherheit bezeichnet. NGINX ModSecurity WAF ist eine kostenpflichtige Zusatzoption und wird Abonnenten über unser Repository für dynamische Module bereitgestellt.

NGINX ModSecurity WAF ist eine unverzichtbare Lösung zum Schutz geschäftskritischer Anwendungen. Sie bietet eine kostengünstige Alternative zu unflexiblen und teuren Hardware-Appliances, wie sie etwa von F5, Citrix und Imperva angeboten werden, und übertrifft dank der Flexibilität einer Softwarelösung zugleich deren Funktionsumfang. NGINX ModSecurity WAF kann in jeder Umgebung bereitgestellt werden – auf lokalen Servern sowie in öffentlichen, privaten und hybriden Clouds.

NGINX ModSecurity WAF trägt zum Schutz vor DDoS-Angriffen bei

Eine WAF basiert auf einer Datenbank mit „Regeln“, die bösartige Verhaltensweisen definieren, welche blockiert und/oder protokolliert werden sollen. Das OWASP ModSecurity Core Rule Set (CRS) ist eines der am häufigsten mit ModSecurity verwendeten Regelwerke. NGINX ModSecurity WAF nutzt das OWASP CRS, um ein breites Spektrum an Angriffen auf Anwendungen zu erkennen und zu blockieren, und bietet unter anderem folgende Funktionen:

• Schutz vor Angriffen auf Layer 7 – Schützen Sie Ihre Anwendungen vor einer Vielzahl von Angriffen, darunter HTTP-Verstöße, SQL-Injection-, XSS-, RFI- und LFI-Angriffe und weitere.
• DDoS-Abwehr – Sorgen Sie für eine kontinuierliche Verfügbarkeit, indem Sie die Auswirkungen ausgefeilter DDoS-Angriffe auf Anwendungsebene und von Botnetzen abwehren und reduzieren.
• Echtzeit-Sperrlisten – Blockieren Sie bekannte böswillige Benutzer automatisch, indem Sie Datenverkehr von IP-Adressen abweisen, die aufgrund ihrer Reputation als böswillig bekannt sind.
• PCI-DSS-6.6-Konformität – Erfüllen Sie jetzt die Anforderungen von PCI-DSS 6.6 für sichere Online-Transaktionen.
• Audit-Protokollierung – Reagieren Sie mithilfe der Informationen in detaillierten Protokollen schneller auf Angriffe und anderen ungewöhnlichen Anwendungsdatenverkehr.

Zusätzliche Regelsätze sind auch von verschiedenen Anbietern erhältlich, beispielsweise von TrustWave, und werden zu unterschiedlichen Preisen angeboten. Darüber hinaus können Sie mit der leistungsstarken Regelsprache von ModSecurity eigene benutzerdefinierte Regeln erstellen, die die von Ihnen verwendeten Regelsätze ergänzen.

Support für NGINX ModSecurity WAF wird direkt von NGINX, Inc. bereitgestellt. Unser Supportteam hilft Ihnen bei der Installation und Konfiguration sowie bei der Behebung von Problemen mit der WAF und dem OWASP Core Rule Set.

NGINX ModSecurity WAF ist als dynamisches Modul im NGINX Plus-Repository verfügbar und kann mit den üblichen Paketverwaltungswerkzeugen installiert werden. Die folgenden Befehle gelten für Debian-basierte Betriebssysteme:

# apt-get update# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurity

Beachten Sie, dass nur Abonnenten, die das NGINX ModSecurity WAF-Modul erworben haben, sowie Abonnenten und Testnutzer, die Zugriff angefordert haben, das Paket nginx-plus-module-modsecurity herunterladen können.

Um das NGINX ModSecurity WAF-Modul zu laden, fügen Sie die Direktive „load_module“ in den „main“-Kontext auf oberster Ebene der NGINX Plus-Konfigurationsdatei ein:

Codebeispiel wird geladen…

Um NGINX ModSecurity WAF mit NGINX Plus zu aktivieren, fügen Sie die Direktive „modsecurity“ zusammen mit der Direktive „modsecurity_rules_file“ ein, um den Regelsatz anzugeben:

Codebeispiel wird geladen…

Laden Sie anschließend die NGINX Plus-Konfiguration neu:

# nginx -t && nginx -s reload

Native JWT-Unterstützung für OAuth 2.0 und OpenID Connect

Dank der nativen Unterstützung des Authentifizierungsstandards JSON Web Token (JWT) erleichtert NGINX Plus R10 die Integration anspruchsvoller Authentifizierungslösungen in Ihre Anwendungen und APIs.

JWT-Token (ausgesprochen „Dschott“), die in RFC 7519 definiert sind, bilden das zugrunde liegende Datenformat für Benutzerinformationen im OpenID Connect-Standard, der die standardisierte Identitätsschicht auf dem OAuth-2.0-Protokoll darstellt. Auch Betreiber von APIs und Microservices setzen aufgrund seiner Einfachheit und Flexibilität zunehmend auf den JWT-Standard.

[Redaktion – Informationen zu Anwendungsfällen, die die native JWT-Unterstützung nutzen, finden Sie in diesen Blogbeiträgen:

• API-Clients mit JWT und NGINX Plus authentifizieren

• Authentifizierung von Benutzern für bestehende Anwendungen mit OpenID Connect und NGINX Plus

]

NGINX Plus validiert das JWT, bevor Clients Zugriff erhalten

Als Reverse-Proxy und Load-Balancer wird NGINX Plus den Anwendungen vorgeschaltet und ist damit ideal positioniert, um die Anwendungsentwicklung zu vereinfachen, indem es die Validierung des in jeder HTTP-Anfrage übermittelten JWT übernimmt. Dies bietet zwei Vorteile. Erstens kann NGINX Plus verhindern, dass nicht authentifizierte, fehlerhafte und bösartige Anfragen die Anwendung erreichen, und schützt sie so vor dem Aufwand und den Risiken, die mit der Verarbeitung solcher Anfragen verbunden sind.

Der zweite Vorteil besteht darin, dass NGINX Plus auf alle Felder im validierten JWT (nach der Signaturprüfung) zugreifen und die Leistungsfähigkeit und Flexibilität seiner Konfigurationssyntax nutzen kann, um anspruchsvolle Authentifizierungslösungen sowohl für Microservices als auch für APIs bereitzustellen:

• Ein typischer Anwendungsfall für Microservices besteht darin, NGINX Plus das JWT validieren und die Identität des authentifizierten Benutzers als HTTP-Header an die Backend-Anwendung übermitteln zu lassen. Dadurch entfällt die Notwendigkeit, dieselbe Authentifizierungsfunktionalität in jedem Microservice immer wieder neu zu implementieren.
• Für APIs kann NGINX Plus den Zugriff tatsächlich benutzerbezogen begrenzen, anstatt sich auf die ungenaue Zuordnung von IP-Adressen zu Endbenutzern zu verlassen.

Der folgende Ausschnitt aus einer beispielhaften NGINX Plus-Konfiguration zeigt, wie sich eine Website mithilfe von JWTs schützen lässt.

Die Direktive „auth_jwt“ weist NGINX Plus an, Benutzer, die Anfragen an eine Domain senden, mithilfe von JWT zu authentifizieren, in diesem Fall „myrealm“. Die Direktive „auth_jwt_key_file“ gibt an, welcher JSON Web Key (JWK) zur Validierung der Tokensignatur verwendet werden soll. Er erfüllt eine ähnliche Funktion wie der öffentliche Schlüssel bei der SSL/TLS-Verschlüsselung. NGINX Plus muss auf den Speicherort der Datei zugreifen können.

Während NGINX Plus das Token validiert und analysiert, erstellt es automatisch NGINX-Variablen für die „Claims“ im JWT, die damit verknüpfte Entitäten darstellen (beispielsweise den Aussteller, den Benutzer, für den es ausgestellt wurde, und den vorgesehenen Empfänger). Die Variablennamen beginnen alle mit $jwt_claim_. Anschließend können Sie mit der Direktive add_header festlegen, dass NGINX Plus einen Claim in Form eines HTTP-Headers, dessen Wert dem Wert der Variablen $jwt_claim_ entspricht, an die Backend-Server weitergibt. In unserem Beispiel übergibt NGINX Plus die Benutzeridentität in der Variablen $jwt_claim_sub an die Backend-Anwendung. Diese entspricht der Benutzer-ID (dem Claim sub) im JWT.

Codebeispiel wird geladen…

Mit NGINX Plus R8 haben wir eine Technologievorschau für die OAuth2-Unterstützung veröffentlicht. Bei der Implementierung in NGINX Plus R10 haben wir das Feedback unserer Kunden berücksichtigt, um eine produktionsreife Lösung bereitzustellen, die die wichtigsten Anwendungsfälle in der komplexen Welt der Authentifizierung von Benutzern und Computern abdeckt.

„Dual-Stack“-Unterstützung für RSA- und ECC-Zertifikate

Es gibt inzwischen viele gute Gründe, den gesamten Anwendungsdatenverkehr mit SSL/TLS zu verschlüsseln. Google belohnt mit SSL/TLS verschlüsselte Websites mit höheren Platzierungen in den Suchergebnissen. Darüber hinaus schreiben moderne Webstandards wie HTTP/2 die SSL/TLS-Verschlüsselung für alle Websites vor.

Mit NGINX Plus R10 können Sie SSL/TLS-Dienste sowohl mit RSA- als auch mit ECC-Zertifikaten bereitstellen. In unseren Tests waren ECC-Zertifikate bis zu dreimal schneller als RSA-Zertifikate mit vergleichbarer Sicherheitsstärke. Dies ermöglicht mehr SSL/TLS-Verbindungen pro Server und schnellere SSL/TLS-Handshakes. NGINX Plus wählt anhand der Fähigkeiten des jeweiligen Clients das optimale Zertifikat aus. So können moderne Clients die schnelleren ECC-Zertifikate verwenden, während ältere Clients, die ausschließlich RSA unterstützen, weiterhin unterstützt werden.

Um sowohl RSA- als auch ECC-Zertifikate zu unterstützen, fügen Sie in der Konfiguration eines virtuellen Servers einfach für jeden Zertifikatstyp jeweils ein Paar der Direktiven „ssl_certificate“ und „ssl_certificate_key“ ein, wie im folgenden Beispiel gezeigt.

Codebeispiel wird geladen…

Transparenter Proxy

Wir erweitern NGINX Plus kontinuierlich um neue Funktionen wie TCP- und UDP-Lastverteilung, um ein breiteres Spektrum an Anwendungen und Bereitstellungsmodellen zu unterstützen. Mit NGINX Plus R10 haben wir eine transparente Proxy-Funktion eingeführt, mit der NGINX Plus Pakete unter Verwendung einer beliebigen Quell-IP-Adresse und eines beliebigen Quellports an Upstream-Server senden kann. Dies ermöglicht Konfigurationen wie IP-Transparenz und Direct Server Return.

IP-Transparenz ist eine Konfiguration, bei der der Load Balancer (NGINX Plus) die IP-Adresse des entfernten Clients als Quell-IP-Adresse für Pakete verwendet, die er an Upstream-Server sendet. Dadurch sehen die Upstream-Server die Pakete so, als stammten sie von der IP-Adresse des entfernten Clients und nicht von einer lokalen IP-Adresse des Load Balancers. Dies ist von Bedeutung, wenn Anwendungen die Quell-IP-Adresse für Protokollierung, Sicherheit, Ratenbegrenzung oder Authentifizierung heranziehen.

IP-Transparenz ist außerdem ein grundlegender Baustein für eine Netzwerk-Lastverteilungstechnik namens „Direct Server Return“ (DSR). NGINX Plus kann DSR für UDP-basierte Protokolle (jedoch nicht für TCP oder HTTP) durchführen, sodass die Antwortpakete den Load Balancer vollständig umgehen und direkt an den Remote-Client gesendet werden können.

Im DSR-Modus antwortet der Backend-Server direkt dem Client.

IP-Transparenz und DSR werden mit dem neuen Parameter „transparent“ für die Direktiven proxy_bind, fastcgi_bind, memcached_bind, scgi_bind und uwsgi_bind konfiguriert. Das folgende Beispiel zeigt, wie DSR für ein DNS-Backend eingerichtet wird. Die Direktive proxy_responses gibt an, dass NGINX Plus keine Serverantworten empfangen muss (null ist der geeignete Wert für DSR).

Codebeispiel wird geladen…

Beachten Sie, dass passive Systemdiagnosen bei aktiviertem DSR nicht wirksam sind, da NGINX Plus dabei überprüft, ob der Server eine Antwort an den Client gesendet hat. Die Konfiguration aktiver anwendungsbezogener Systemdiagnosen ist für eine DSR-Konfiguration zwingend erforderlich. Ein Beispiel finden Sie in unserer ausführlichen Anleitung zur Konfiguration solcher Systemdiagnosen für DNS-Server mit Lastverteilung.

Konfigurationen für IP-Transparenz und DSR sind komplex und stellen zusätzliche Anforderungen an das Routing und das Umschreiben von Paketen, die über den Funktionsumfang der NGINX-Plus-Software hinausgehen. Eine vollständige Anleitung finden Sie unter „IP-Transparenz und Direct Server Return mit NGINX und NGINX Plus als transparentem Proxy“ in unserem Blog.

Das NGINX-JavaScript-Modul für HTTP-, TCP- und UDP-basierte Anwendungen

[Redaktion – Das NGINX-JavaScript-Modul hieß früher nginScript. Das Modul wurde mit NGINX Plus R12 (und NGINX 1.11.10) allgemein verfügbar.

Ausführliche Erläuterungen zu weiteren Anwendungsfällen des NGINX-JavaScript-Moduls finden Sie unter „Anwendungsfälle für das NGINX-JavaScript-Modul“.

Der Code in diesem Abschnitt wurde aktualisiert und verwendet nun die js_import-Direktive, welche die js_include-Direktive ab NGINX Plus R23 ersetzt. Weitere Informationen finden Sie in der Referenzdokumentation zum NGINX JavaScript-Modul – im Abschnitt Beispielkonfiguration wird die korrekte Syntax für NGINX-Konfigurations- und JavaScript-Dateien gezeigt.]

NGINX Plus R10 enthält eine Vorabversion unserer neuen Konfigurationssprache NGINX JavaScript. Sie verfügt noch nicht über den vollständigen Funktionsumfang, und wir freuen uns über jedes Feedback zum bisherigen Entwicklungsstand. Mit NGINX JavaScript können Sie JavaScript-Code verwenden, um komplexe und benutzerdefinierte Aktionen für HTTP-, TCP- und UDP-Datenverkehr auszuführen. Damit steht Ihnen eine leistungsstarke neue Möglichkeit zur Verfügung, die Bereitstellung und Absicherung Ihrer Anwendungen zu steuern. Mit NGINX JavaScript können Sie:

• Schreiben Sie „serverlose“ Funktionen mithilfe der leistungsstarken Programmiersprache JavaScript direkt in NGINX Plus
• API-Daten formatieren, bearbeiten und transformieren
• Einfache TCP-Dienste bereitstellen, beispielsweise einen Zeitserver
• Verwenden Sie JavaScript, um NGINX-Variablen festzulegen, benutzerdefinierte Entscheidungen zur Lastverteilung zu treffen, Cache-Schlüssel zu erstellen und vieles mehr

Die Vorabversion von NGINX JavaScript ist in unserem Repository für dynamische Module verfügbar. Sie können sie mit den üblichen Paketverwaltungstools installieren. Die folgenden Befehle gelten für Debian-basierte Betriebssysteme:

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njs

Um die NGINX-JavaScript-Module für HTTP und TCP/UDP zu laden, fügen Sie die Direktive „load_module“ in den übergeordneten „main“-Kontext der NGINX-Plus-Konfigurationsdatei ein:

Codebeispiel wird geladen…

Laden Sie anschließend die NGINX Plus-Konfiguration neu, um die NGINX-JavaScript-Module zu laden:

# nginx -t && nginx -s reload

Benutzer von NGINX Open Source können NGINX JavaScript aus unserem Open-Source-Code-Repository beziehen.

JavaScript-Code wird nicht direkt in die NGINX Plus-Konfiguration eingebunden. Stattdessen wird er mit der Direktive „js_import“ eingelesen. In diesem Beispiel wird der JavaScript-Code für eine einfache „serverlose“ Funktion aus „/etc/nginx/conf.d/functions.js“ eingelesen. Die Direktive „js_content“ weist NGINX Plus an, die JavaScript-Funktion aufzurufen und die Ergebnisse an den Client zurückzugeben.

Codebeispiel wird geladen…

Der JavaScript-Code in /etc/nginx/conf.d/functions.js füllt eine Zeichenfolge mit einem angegebenen Zeichensatz auf:

Codebeispiel wird geladen…

Zusätzliche Funktionen

NGINX Plus R10 bietet eine Reihe zusätzlicher Verbesserungen, die Sie bei der reibungslosen Bereitstellung von Anwendungen unterstützen, darunter:

• Der im Stream-Modul implementierte TCP/UDP-Lastenausgleich bietet nun eine größere Funktionsgleichheit mit dem HTTP-Lastenausgleich. Zu den neu unterstützten Modulen gehören Split Clients für A/B-Tests, GeoIP zum Ausführen von Aktionen basierend auf dem geografischen Standort der Clients und Geo zum Definieren von Variablen anhand der IP-Adresse. Weitere Informationen stehen über zusätzliche NGINX-Variablen zur Verfügung. Außerdem können Sie Routing-Entscheidungen treffen, indem Sie eine Variable als Parameter für die proxy_pass-Direktive verwenden.
• Ein häufiges Problem bei Anwendungen mit hohem Datenverkehr ist die Erschöpfung ephemerer Ports, bei der keine neuen Verbindungen zu Upstream-Servern hergestellt werden können, weil dem Betriebssystem keine verfügbaren Portnummern mehr zur Verfügung stehen. Um dieses Problem zu beheben, verwendet NGINX Plus nun, sofern verfügbar, die Socket-Option IP_BIND_ADDRESS_NO_PORT. Diese Option ermöglicht die Wiederverwendung von Quellports für ausgehende Verbindungen zu Upstream-Servern, sofern das standardmäßige „4-Tupel“ (Quell-IP-Adresse, Ziel-IP-Adresse, Quellport, Zielport) eindeutig ist. Sie ist auf Systemen mit Linux-Kernel ab Version 4.2 und glibc ab Version 2.22 verfügbar.
• NGINX Plus generiert die neue Variable $request_id automatisch für jede neue HTTP-Anfrage und weist der Anfrage damit effektiv eine eindeutige „Transaktions-ID“ zu. Dies erleichtert die Anwendungsverfolgung und erweitert Protokollanalysetools um APM-Funktionen. Die Transaktions-ID wird an Backend-Anwendungen und Microservices weitergeleitet, sodass alle Teile des Systems für jede Transaktion eine einheitliche Kennung protokollieren können.
• Die Direktiven „proxy_request_buffering“, „fastcgi_request_buffering“, „scgi_request_buffering“ und „uwsgi_request_buffering“ funktionieren jetzt mit HTTP/2 und können zum Aktivieren bzw. Deaktivieren der Anfragepufferung verwendet werden.
• Die neue http2_body_preread_size-Direktive ermöglicht es HTTP/2-Clients, sofort mit dem Senden des Anfragetexts zu beginnen. Die Direktive legt die Größe des Puffers fest, der verwendet wird, bevor NGINX Plus mit dem Lesen des Client-Anfragetexts beginnt.

Das NGINX Plus Extras-Paket ist veraltet

Wie bereits von uns vorab angekündigt wurde, ist R10 nach der Veröffentlichung von NGINX Plus R9 die letzte Version, die das NGINX Plus Extras-Paket enthält.

Wir empfehlen Ihnen dringend, Ihre Installations- und Konfigurationsverfahren jetzt so anzupassen, dass Sie das Paket nginx-plus verwenden und die tatsächlich benötigten Module aus dem Paket nginx-plus-extras dynamisch laden. Ab NGINX Plus R11 ist dies die einzige Möglichkeit, Module zu verwenden, die nicht in das Paket nginx-plus integriert sind.

Führen Sie die folgenden Schritte aus, um zum nginx-plus-Paket und zu dynamischen Modulen zu wechseln:

1. Entfernen Sie das Paket nginx-plus-extras und installieren Sie nginx-plus sowie die gewünschten dynamischen Module. Für Debian-basierte Systeme lauten die entsprechenden Befehle:

# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name

1. Fügen Sie im Hauptkontext (auf oberster Ebene) in /etc/nginx/nginx.conf für jedes dynamisch geladene Modul eine load_module-Direktive hinzu:

   Codebeispiel wird geladen…

2. Prüfen Sie die neue Konfiguration auf syntaktische Gültigkeit und laden Sie sie neu:

# nginx -t && nginx -s reload

NGINX Plus upgraden oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf Release 10 durchzuführen. Damit erhalten Sie zahlreiche Fehlerbehebungen und Verbesserungen. Außerdem können wir Sie so besser unterstützen, falls Sie ein Support-Ticket erstellen müssen. Anweisungen zur Installation und zum Upgrade finden Sie im NGINX Plus-Kundenportal.

HINWEIS: NGINX Plus R10 ist die letzte Version, die das Paket nginx-plus-extras enthält. Siehe „Das NGINX Plus Extras-Paket ist veraltet“ oben.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zur Webbeschleunigung, Lastverteilung und Anwendungsbereitstellung oder als vollständig unterstützten Webserver mit erweiterten APIs für Monitoring und Management zu testen. Sie können noch heute kostenlos mit einer 30‑tägigen Testversion beginnen und sich selbst davon überzeugen, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.

Weitere Informationen zu NGINX Plus R10

Weitere Informationen zu den wichtigsten neuen Funktionen in NGINX Plus R10 finden Sie in den folgenden weiterführenden Ressourcen:

• Authentifizieren von API-Clients mit JWT und NGINX Plus
• NGINX Plus R10 nutzt IBM POWER
• Authentifizierung von Benutzern für bestehende Anwendungen mit OpenID Connect und NGINX Plus
• Verwenden des NGINX-JavaScript-Moduls zur schrittweisen Migration von Clients auf einen neuen Server
• IP-Transparenz und Direct Server Return mit NGINX und NGINX Plus als transparentem Proxy
• Was ist neu in NGINX Plus R10? (Webinar auf Abruf)

[Der Verkauf von NGINX ModSecurity WAF wurde zum 1. April 2022 offiziell eingestellt. Zum 31. März 2024 erreicht das Produkt das Ende seines Lebenszyklus. Weitere Informationen finden Sie im Beitrag „F5 NGINX ModSecurity WAF erreicht das Ende seines Lebenszyklus“ in unserem Blog.]

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett