Ankündigung von NGINX Plus R17

[ Anmerkung des Herausgebers – Der Verkauf des NGINX ModSecurity WAF- Moduls für NGINX Plus endete offiziell am 1. April 2022 , und mit Wirkung zum 31. März 2024 wird es nicht mehr unterstützt . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 17 (R17) jetzt verfügbar ist. NGINX Plus ist der einzige All-in-One-Load Balancer, Inhaltscache, Webserver und API-Gateway. NGINX Plus basiert auf NGINX Open Source und umfasst exklusive erweiterte Funktionen und preisgekrönten Support.

Neu in dieser Version ist die Unterstützung für TLS 1.3 , die neueste Version des Protokolls, das für den gesamten sicheren Datenverkehr im Internet verantwortlich ist. Seit der Veröffentlichung von TLS 1.2 sind über 10 Jahre vergangen und seitdem hat sich viel verändert. In TLS 1.2 wurden zahlreiche Sicherheitslücken gefunden, etwa FREAK, Heartbleed, POODLE und ROBOT. Viele dieser Schwachstellen waren das Ergebnis zu vieler unsicherer Konfigurationsoptionen in TLS 1.2, die Websites für Angriffe anfällig machten.

TLS 1.3 ist Addition durch Subtraktion. Viele unsichere Chiffren wurden entfernt und der Diffie-Hellman-Schlüsselaustausch ist jetzt obligatorisch. Das Ergebnis ist ein abgespecktes, schnelleres und sichereres TLS. Zum Zeitpunkt des Schreibens dieses Artikels unterstützen Alpine Linux 3.9, FreeBSD 12.0 und Ubuntu 18.10 TLS 1.3, sodass Sie sie mit NGINX Plus R17 für TLS 1.3 in Ihrer Produktionsumgebung verwenden können; andere Betriebssystemanbieter werden TLS 1.3 in zukünftigen Versionen zweifellos unterstützen. Beachten Sie, dass F5 BIG-IP und andere Hardware-Load Balancer TLS 1.3 derzeit nicht vollständig unterstützen.

NGINX Plus R17 enthält außerdem diese neuen Funktionen:

• Zweistufige Ratenbegrenzung – Die Ratenbegrenzung ist eine der beliebtesten Funktionen in NGINX Open Source und NGINX Plus. Es kann verwendet werden, um DDoS-Angriffe abzuschwächen und Anwendungsserver allgemein vor einer Überlastung durch zu viele Anfragen zu schützen. Der neue Verzögerungsparameter hilft der Ratenbegrenzung von NGINX Plus, typischen Browser-Anforderungsmustern besser gerecht zu werden. Die vorhandenen Methoden zur Verzögerungs- und Ablehnungserzwingung können jetzt kombiniert werden, um eine zweistufige Ratenbegrenzung bereitzustellen. Dabei werden übermäßige Anfragen zunächst verzögert und dann endgültig abgelehnt, wenn die Ratenbegrenzung weiterhin überschritten wird.
• Einfachere OpenID Connect-Konfiguration – In NGINX Plus R15 haben wir die OpenID Connect-Integration eingeführt, um unseren Kunden die Möglichkeit zu geben, ihren Anwendungen Single Sign-On (SSO) hinzuzufügen. In R17 haben wir die Konfiguration vereinfacht, um JSON Web Keys (JWKs) automatisch vom Identitätsanbieter (IdP) abzurufen.
• NGINX Modsecurity WAF ist 2x schneller – NGINX ModSecurity WAF, ein dynamisches Modul für NGINX Plus basierend auf ModSecurity v3, bietet robusten Schutz gegen Layer 7-Angriffe. ModSecurity wird aktiv weiterentwickelt und die neueste Version von NGINX ModSecurity WAF bietet eine doppelt so gute Leistung und eine Reihe weiterer Verbesserungen.

Zu den weiteren Verbesserungen in NGINX Plus R17 gehören TCP-Keepalives für Upstreams, SNI-Unterstützung in Clusterumgebungen und mehr.

Wichtige Verhaltensänderungen

• NGINX Plus R13 führte die brandneue NGINX Plus-API für die Metrikerfassung und dynamische Neukonfiguration von Upstream-Gruppen ein und ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor implementiert hatten. Wie damals angekündigt, blieben die veralteten APIs für einen beträchtlichen Zeitraum weiterhin verfügbar und wurden unterstützt, der mit NGINX Plus R16 endete. Wenn Ihre Konfiguration die Anweisungen „status“ und/oder „upstream_conf“ enthält, müssen Sie diese im Rahmen des Upgrades auf R17 durch die Anweisung „api“ ersetzen.

  Ratschläge und Hilfe zur Migration zur NGINX Plus API finden Sie im Übergangshandbuch in unserem Blog oder wenden Sie sich an unser Supportteam.

• Neue unterstützte Betriebssysteme:

  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10 (Kosmisch)

• Ältere Betriebssysteme, die entfernt wurden oder deren Entfernung geplant ist:

  • FreeBSD 10.4 und 11.1 werden nicht mehr unterstützt.
  • Der Support für CentOS/Oracle/RHEL 7.3 und früher wird in NGINX Plus R18 eingestellt.
  • Der Support für Ubuntu 14.04 wird in NGINX Plus R19 eingestellt.

Neue Features im Detail

TLS 1.3: Addition durch Subtraktion

Seit dem letzten größeren Update von TLS sind über 10 Jahre vergangen. TLS 1.2 wurde im August 2008 als RFC 5246 definiert und das Internet hat sich seitdem erheblich verändert. TLS 1.3 wurde im August 2018 als RFC 8446 ratifiziert, um viele der in TLS 1.2 festgestellten Probleme zu beheben und eine skalierbarere Plattform für die Zukunft zu schaffen.

Mehr Sicherheit

Im Laufe der Jahre wurden zahlreiche Sicherheitslücken in TLS 1.2 bekannt, wie etwa FREAK , Heartbleed , POODLE und ROBOT . Mit FREAK beispielsweise kann ein Angreifer eine TLS-Verbindung so herunterstufen, dass eine Export-Chiffre mit einer Schlüssellänge von 40 Bit verwendet wird, die mit roher Gewalt geknackt werden kann. TLS 1.3 entfernt Exportchiffren vollständig.

Viele der Probleme, die mit TLS 1.2 und früheren Spezifikationen aufgetreten sind, sind auf die große Zahl benutzerkonfigurierbarer Optionen zurückzuführen. Der Missbrauch von Optionen führte häufig zu unsicheren Konfigurationen, die von Angreifern ausgenutzt werden konnten. TLS 1.3 entfernt einige dieser Optionen:

• AES‑CBC
• Beliebige Diffie‑Hellman‑Gruppen
• Chiffren exportieren
• DES/3DES
• MD5
• PKCS#1 v1.5-Auffüllung
• RC4
• RSA-Schlüsseltransport (Diffie‑Hellman ist obligatorisch)
• SHA‑1

Bessere Leistung

In der Liste der Entfernungen fällt insbesondere der RSA-Schlüsseltransport auf. Dieser Modus wurde hauptsächlich verwendet, weil er schneller als Diffie-Hellman war, bei dem ein zusätzlicher Roundtrip zum Einrichten der Verbindung mit Perfect Forward Secrecy (PFS) erforderlich war. Mit TLS 1.3 ist der zusätzliche Roundtrip nicht mehr nötig. Bei weniger Konfigurationsoptionen müssen weniger Informationen ausgetauscht werden und der Diffie‑Hellman‑Handshake benötigt nur einen Roundtrip (das Diagramm zeigt auch eine GET‑ Anfrage im Anschluss an den Handshake).

Darüber hinaus unterstützt TLS 1.3 die Wiederaufnahme von Sitzungen , wodurch der Verbindungsaufbau beschleunigt wird, da der Aufwand für die Wiederholung des TLS-Handshakes entfällt, wenn ein Client zu einer zuvor besuchten Site zurückkehrt. Dies wird auch als 0‑RTT-Wiederaufnahme (Zero Round Trip Time) bezeichnet, da für die fortgesetzte Sitzung keine Handshake-Nachrichten zwischen Client und Server hin und her gesendet werden müssen. Die Wiederaufnahme der Sitzung wird implementiert, indem während der ursprünglichen Sitzung ein gemeinsames Geheimnis erstellt und in einem Sitzungsticket gespeichert wird. Wenn der Client zurückkehrt, präsentiert er das Sitzungsticket zusammen mit seiner Anfrage, die mit dem im Ticket enthaltenen gemeinsamen Geheimnis verschlüsselt ist.

Die Verwendung von 0-RTT birgt das Risiko eines Replay-Angriffs, wie unten dargestellt. In diesem Szenario sendet der Angreifer ein Paket erneut, das zu einer Statusänderung führt, beispielsweise eine Anforderung zur Überweisung von Geld zwischen zwei Bankkonten.

Zum Schutz vor Replay-Angriffen sollten Clients in den 0-RTT-Daten (den mit dem gemeinsamen Geheimnis verschlüsselten Daten) nur den HTTP-Anforderungstyp GET senden. HTTP- GET- Anfragen sind per Definition idempotent ( RFC 7231 ), ihre erneute Wiedergabe hat daher keine Auswirkungen. Das Laden einer Seite ist normalerweise das Erste, was ein Client tut, wenn er eine Site erneut besucht, und die meisten Seitenladevorgänge beginnen mit einer GET -Anfrage. Durch die Aktivierung der Sitzungswiederaufnahme wird daher ein großer Teil der Anfragen an die meisten Websites beschleunigt. Beim Einsatz von NGINX Plus als API-Gateway möchten Sie die 0-RTT-Wiederaufnahme möglicherweise nicht aktivieren, da bei wiederaufgenommenem API-Verkehr die Wahrscheinlichkeit höher ist, dass TLS-Sitzungen nicht-idempotente Anforderungstypen enthalten.

TLS 1.3 selbst schützt auch vor Replay-Angriffen, indem es Zeitinformationen in das Sitzungsticket und die Client-Anforderung einfügt, wodurch der Server feststellen kann, ob die Anforderung ausreichend bald nach dem Senden vom Client eingetroffen ist. Ein Angreifer kann die Zeitinformationen nicht ändern. Wenn die Anfrage also zu lange gebraucht hat, um anzukommen, wurde sie wahrscheinlich wiederholt.

So aktivieren Sie TLS 1.3 in NGINX Plus

TLS 1.3 und 0‑RTT sind standardmäßig nicht aktiviert.

Um TLS 1.3 zu aktivieren, fügen Sie der Direktive ssl_protocols den Parameter TLSv1.3 hinzu. Wir empfehlen, auch TLSv1.2 einzubinden, da zum Zeitpunkt des Schreibens nicht alle Browser TLS 1.3 unterstützen (siehe nächsten Abschnitt). NGINX Plus verwendet TLS 1.3, wenn der Client dies unterstützt, und greift andernfalls auf TLS 1.2 zurück.

Um 0‑RTT zu aktivieren, setzen Sie auch die Direktive ssl_early_data auf on .

Diese Konfiguration aktiviert beide Funktionen:

Server { listen 443 ssl; SSL-Zertifikat /etc/ssl/my_site_cert.pem; SSL-Zertifikatsschlüssel /etc/ssl/my_site_key.pem; SSL-Protokolle TLSv1.2 TLSv1.3 ; SSL-Early -Data ein ; # 0-RTT (TLS 1.3) aktivieren Standort / { Proxy-Passwort http://my_backend; } }

Unterstützte Plattformen

Auf der Serverseite erfordert TLS 1.3 OpenSSL 1.1.1 oder höher. Zum Zeitpunkt des Schreibens dieses Artikels werden nur Alpine Linux 3.9, FreeBSD 12.0 und Ubuntu 18.10 mit OpenSSL 1.1.1 ausgeliefert.

Auf der Clientseite empfehlen wir Chrome 70 oder Firefox 63. Sie unterstützen die endgültige Version von TLS 1.3, aktivieren diese jedoch nicht standardmäßig; befolgen Sie diese Anweisungen, um TLS 1.3 im Browser zu aktivieren . Zum Zeitpunkt des Schreibens dieses Artikels unterstützen andere beliebte Browser (darunter Firefox für Android und Safari für iOS und Mac) TLS 1.3 noch nicht. Die aktuellsten Statusinformationen finden Sie unter „Kann ich Folgendes verwenden?“: TLS 1.3 .

Zweistufige Ratenbegrenzung

Bisher konnte NGINX Plus Begrenzungen der Anforderungsrate auf zwei Arten erzwingen: durch sofortige Ablehnung übermäßiger Anforderungen oder durch Einreihen übermäßiger Anforderungen in eine Warteschlange, bis sie unter Einhaltung der definierten Ratenbegrenzung verarbeitet werden konnten. Mit NGINX Plus R17 können Sie beide Durchsetzungsmethoden für ein zweistufiges Rate Limiting kombinieren, wobei überzählige Anfragen zunächst verzögert und schließlich abgelehnt werden, wenn das Rate Limit weiterhin überschritten wird.

Bei der Anwendung von Ratenbegrenzungen muss unbedingt das typische Verhalten legitimer Clients berücksichtigt werden. Beispielsweise versuchen Webbrowser normalerweise, mehrere Ressourcen gleichzeitig herunterzuladen. Daher ist es sinnvoll, eine Anforderung für den HTML-Inhalt zu sehen, kurz gefolgt von Anforderungen für Stylesheets, JavaScript-Code und Bilder. Aus diesem Grund möchten wir möglicherweise eine Anzahl von 10 bis 20 schnellen Anfragen zulassen, bevor wir eine Ratenbegrenzung anwenden.

Mit NGINX Plus R17 können Sie jetzt einen Burst zulassen, um dem typischen Anforderungsmuster eines Webbrowsers gerecht zu werden, und dann zusätzliche, überzählige Anforderungen bis zu einem gewissen Punkt verzögern, ab dem zusätzliche, überzählige Anforderungen abgelehnt werden. Die zweistufige Ratenbegrenzung wird mit dem neuen Verzögerungsparameter der Direktive „limit_req“ aktiviert.

Um die zweistufige Ratenbegrenzung zu veranschaulichen, konfigurieren wir hier NGINX Plus so, dass eine Website durch die Festlegung einer Ratenbegrenzung von 5 Anfragen pro Sekunde ( Rate = 5 Anfragen pro Sekunde ) geschützt wird. Die Website enthält normalerweise 4–6 Ressourcen pro Seite und nie mehr als 12 Ressourcen. Die Konfiguration ermöglicht Bursts von bis zu 12 Anfragen, von denen die ersten 8 ohne Verzögerung verarbeitet werden. Um das Limit von 5 R/s durchzusetzen, wird nach 8 überzähligen Anfragen eine Verzögerung eingefügt. Nach 12 überzähligen Anfragen werden alle weiteren Anfragen abgelehnt.

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
Server {
listen 80;
Standort / {
limit_req zone=ip burst=12 delay=8;
proxy_pass http://website;
}
}

Der Verzögerungsparameter definiert den Punkt, an dem innerhalb der Burst-Größe übermäßige Anforderungen gedrosselt (verzögert) werden, um die definierte Ratenbegrenzung einzuhalten. Bei dieser Konfiguration tritt bei einem Client, der kontinuierlich Anfragen mit 8 R/s sendet, das folgende Verhalten auf.

Die ersten 8 Anfragen (der Verzögerungswert ) werden von NGINX Plus ohne Verzögerung weitergereicht. Die nächsten 4 Anfragen ( Burst - Delay ) werden verzögert, so dass die definierte Rate von 5 U/s nicht überschritten wird. Die nächsten 3 Anfragen werden abgelehnt, da die gesamte Burst-Größe überschritten wurde. Nachfolgende Anfragen werden verzögert.

Beachten Sie, dass diese Abbildung eine vereinfachte Beschreibung des Prozesses darstellt, da sie den Einfluss abgeschlossener Anfragen auf die Berechnung der Anzahl der verarbeiteten überzähligen Anfragen außer Acht lässt. Tatsächlich wird mit jeder abgeschlossenen Anfrage ein Platz in der Verzögerungswarteschlange für eine weitere überzählige Anfrage geöffnet, um in die konfigurierte Burst-Größe zu passen. Weitere Informationen zur Implementierung der Ratenbegrenzung finden Sie unter „Ratenbegrenzung mit NGINX und NGINX Plus“ in unserem Blog.

Einfachere OpenID Connect-Konfiguration

Bei der Durchführung der JWT-Validierung kann NGINX Plus R17 jetzt so konfiguriert werden, dass der Satz von JSON Web Keys (JWKs) vom Remote-Standort (normalerweise ein Identitätsanbieter oder IdP) abgerufen wird, der durch die neue Direktive „auth_jwt_key_request“ angegeben wird. Das automatische Abrufen ist besonders praktisch bei der Integration mit einem IdP, der Schlüssel häufig rotiert.

Die meisten IdPs stellen eine feste URL bereit, unter der der aktuelle Schlüsselsatz abgerufen werden kann, insbesondere wenn sie OpenID Connect Discovery unterstützen. In diesem Fall wird die URL zu den Schlüsseln durch den Wert jwks_uri definiert.

# Erstellen Sie ein Verzeichnis, um die von IdPproxy_cache_path /var/cache/nginx/jwk empfangenen Schlüssel zwischenzuspeichern levels=1 keys_zone=jwk:1m max_size=10m;

server {
listen 80; # Verwenden Sie SSL/TLS in der Produktion

location / {
auth_jwt "closed site";
auth_jwt_key_request /_jwks_uri; # Schlüssel werden per Subrequest abgerufen

proxy_pass http://my_backend;
}

location = /_jwks_uri {
internal;
proxy_cache jwk; # Antworten zwischenspeichern
proxy_pass https://idp.example.com/oauth2/keys; # Schlüssel von hier abrufen
}
}

Mit zusätzlichen Caching-Direktiven können die von der Unteranforderung zurückgegebenen Expires- und Cache-Control- Header überschrieben werden. Die Verwendung von proxy_cache_use_stale ermöglicht es NGINX Plus, weiterhin zwischengespeicherte Schlüssel zu verwenden, wenn die Schlüssel-URL nicht verfügbar ist.

Unsere OpenID Connect-Referenzimplementierung wurde aktualisiert und umfasst nun Unterstützung für auth_jwt_key_request und automatische Konfiguration für IdPs, die OpenID Connect Discovery unterstützen.

Die JWT-Unterstützung wurde außerdem erweitert, um zwei Varianten des Edwards-Curve Digital Signature Algorithm (EdDSA) zu unterstützen: Ed448 und Ed25519. Beachten Sie, dass EdDSA OpenSSL 1.1.1 oder höher erfordert, das zum Zeitpunkt des Schreibens nur in Ubuntu 18.10 und FreeBSD 12.0 verfügbar ist.

Notiz: OpenID Connect-Unterstützung ist exklusiv für NGINX Plus.

2x schnelleres NGINX ModSecurity WAF

Das NGINX ModSecurity WAF- Modul für NGINX Plus ist unser unterstützter Build der Open-Source-ModSecurity-Web-Application-Firewall (WAF), die von über einer Million Sites verwendet wird. Wir arbeiten aktiv mit dem Team von TrustWave SpiderLabs zusammen, um die Leistung von ModSecurity mit NGINX Plus zu verbessern, und freuen uns, mitteilen zu können, dass die neueste Version doppelt so gut funktioniert wie frühere Versionen.

Diese Version fügt auch Unterstützung für pdateActionById , ctl:requestBodyProcessor=URLENCODED und die Aktion setenv hinzu.

Der neue NGINX ModSecurity WAF-Build basiert auf ModSecurity 3.0.3; weitere Einzelheiten finden Sie im TrustWave SpiderLabs-Blog .

Notiz: NGINX ModSecurity WAF ist exklusiv für NGINX Plus.

Weitere neue Funktionen in NGINX Plus R17

TCP-Keepalives zu Upstreams

Die neue Direktive proxy_socket_keepalive steuert, ob TCP-Keepalives zwischen NGINX Plus und dem Proxy-Server aktiviert sind. TCP-Keepalives verbessern die Leistung für Protokolle (wie etwa WebSocket), bei denen sich zwischen NGINX und dem Proxy-Server ein zustandsbehaftetes TCP-Netzwerkgerät mit langlebigen und oft inaktiven Verbindungen befindet. Ohne TCP-Keepalives schließen solche Geräte inaktive TCP-Verbindungen möglicherweise häufiger, wodurch der Aufwand entsteht, sie von Grund auf neu aufzubauen.

Die Direktive ist auch in den Modulen FastCGI , gRPC , memcached , SCGI und uwsgi verfügbar.

Upstream-HTTP-Keepalive-Timeout und Anforderungsbegrenzung

Die neue Direktive „keepalive_timeout“ legt die maximale Leerlaufzeit fest, bevor eine HTTP-Keepalive-Verbindung zwischen NGINX Plus und dem Proxy-Server geschlossen wird. Darüber hinaus legt die Direktive „keepalive_requests“ die maximale Anzahl von Anfragen fest, die über eine Keepalive-Verbindung gesendet werden können (an diesem Punkt wird sie geschlossen und eine neue erstellt).

Begrenzte Upstream-UDP-Sitzungsgröße

Die neue Direktive „proxy_requests“ (Stream-Modul) legt die maximale Anzahl von UDP-Paketen fest, die von NGINX Plus an den Proxy-Server gesendet werden, bevor eine neue UDP-„Sitzung“ erstellt wird. Dies sorgt für eine gleichmäßigere Lastverteilung der UDP-Pakete, wenn ein einzelner Client in kurzer Zeit eine große Zahl an UDP-Paketen sendet (was beispielsweise passieren kann, wenn ein nachgeschalteter Proxy vorhanden ist).

Verbesserung der Cluster-Statusfreigabe

Wenn Sie die Statusfreigabe in einem Cluster verwenden, können Sie jetzt eine Servernamenüberprüfung durchführen, indem Sie SNI verwenden, um den Servernamen bei der Verbindung mit Clusterknoten zu übergeben. Dies wird mit den Anweisungen zone_sync_ssl_name und zone_sync_ssl_server_name implementiert.

Notiz: Clustering und das Modul zone_sync sind exklusiv für NGINX Plus

Updates für das NGINX Plus-Ökosystem

Verbesserungen am Ingress Controller

Der offizielle NGINX Ingress Controller für Kubernetes wurde auf Version 1.4.0 aktualisiert. Im Änderungsprotokoll sind alle Änderungen, Fehlerbehebungen und Verbesserungen aufgeführt. Die wichtigsten davon werden in unserem Blog hervorgehoben:

• Erweiterte Prometheus-Unterstützung
• TCP/UDP-Lastausgleich
• Der Lastenausgleichsalgorithmus „Random with Two Choices“ ist der neue Standard
• Benutzerdefinierte Anmerkungen

Lesen Sie mehr über den offiziellen NGINX Ingress Controller für Kubernetes auf unserer Website und im GitHub-Repo .

Erweiterungen des JavaScript-Moduls

NGINX Plus R17 enthält eine Reihe von Verbesserungen, die den Umfang der JavaScript-Sprachunterstützung erweitern:

• Argumente Objekte
• Nicht ganzzahlige Brüche
• Zusätzliche Zeitmethoden: console.time() und console.timeEnd()
• Variablen und Funktionen können nun neu deklariert werden

Die Integration mit dem NGINX Stream-Modul für TCP/UDP-Anwendungen wurde überarbeitet, um verschiedene Rückgabefunktionen zu verwenden, darunter eine send()- Methode zum Ändern des eingehenden Datenverkehrs. Ausgehender Datenverkehr ist jetzt über einen Rückruf verfügbar.

Alle Änderungen finden Sie im Änderungsprotokoll des NGINX JavaScript-Moduls .

Upgrade durchführen oder NGINX Plus testen

NGINX Plus R17 unterstützt TLS 1.3, das sicherer ist und eine bessere Leistung bietet als TLS 1.2. Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 17 und TLS 1.3 zu aktualisieren. Sie erhalten außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen und können NGINX, Inc. dabei unterstützen, Ihnen zu helfen, wenn Sie ein Support-Ticket erstellen müssen.

Bitte überprüfen Sie die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plus oder NGINX ModSecurity WAF noch nicht ausprobiert haben, empfehlen wir Ihnen, sie 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 kostenlos loslegen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.

[ Anmerkung des Herausgebers – Der Verkauf von NGINX ModSecurity WAF endete am 1. April 2022 offiziell, und der Lebenszyklus endet mit Wirkung zum 31. März 2024 . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]