BLOG | NGINX

Annonce de NGINX Plus R25

NGINX-Partie-de-F5-horiz-black-type-RGB
Vignette de Zach Westall
Zach Westall
Publié le 28 septembre 2021

Nous sommes heureux d'annoncer la disponibilité de NGINX Plus Release 25 (R25) . Basé sur NGINX Open Source, NGINX Plus est le seul serveur Web logiciel tout-en-un , équilibreur de charge, proxy inverse, cache de contenu et passerelle API.

Les nouvelles fonctionnalités de NGINX Plus R25 incluent :

Changements importants dans le comportement

Besoin accru en mémoire pour les zones en amont

Comme décrit en détail dans Rapports plus granulaires sur les codes de réponse HTTP , NGINX Plus R25 fournit des décomptes de codes d'état individuels ainsi que des décomptes agrégés par classe. Lorsque NGINX Plus est configuré comme proxy inverse ou équilibreur de charge, vous devrez peut-être augmenter la taille de la zone de mémoire partagée utilisée pour surveiller les « homologues » en amont (serveurs principaux), s'il y a plus de 20 homologues.

NGINX Plus R25 ne démarre pas si les zones de mémoire partagée sont sous-provisionnées, ce qui entraîne l'échec des mises à niveau. Avant la mise à niveau, il est important de vérifier l’utilisation de la mémoire de chaque zone en amont. Pour obtenir des instructions sur la vérification et le réglage de l'allocation de mémoire, consultez Allouer une mémoire suffisante pour éviter les échecs de démarrage .

Modifications apportées à l'organisation et à la procédure d'installation du référentiel NGINX Plus

Lors de la sortie de NGINX Plus R24 , les référentiels de packages pour tous les logiciels NGINX ont été réorganisés, ce qui a entraîné des modifications dans la procédure d'installation de NGINX Plus.

Lorsque vous installez ou mettez à niveau NGINX Plus, le gestionnaire de packages du système d'exploitation ( apt , yum ou équivalent) est configuré avec le référentiel de logiciels pour NGINX Plus. Sur les systèmes existants configurés pour utiliser l'ancien référentiel (ceux exécutant NGINX Plus R23 ou une version antérieure), vous devez mettre à jour le gestionnaire de packages pour faire référence au nouveau référentiel. Consultez les instructions dans la base de connaissances F5 .

Si vous effectuez une installation initiale de NGINX Plus R25 , consultez Installation de NGINX Plus dans le Guide d'administration de NGINX Plus .

Note: Vous devez utiliser le nouveau référentiel de logiciels. L'ancien dépôt ne sera plus mis à jour et peut provoquer des erreurs lors des futures installations et mises à niveau.

Module Cookie-Flag obsolète

Comme annoncé lors de la sortie de NGINX Plus R23 , le module tiers Cookie-Flag est obsolète et sera supprimé du référentiel de modules dynamiques dans NGINX Plus R26 . La directive set_cookie_flag définie dans ce module est remplacée par la directive proxy_cookie_flags intégrée. Nous vous recommandons de remplacer toutes les directives set_cookie_flag dans votre configuration par les directives proxy_cookie_flags dès que possible.

Modifications apportées à la prise en charge de la plateforme

  • Nouveaux systèmes d’exploitation pris en charge :
    • Debian 11 (x86_64, aarch64)
    • Alpine Linux 3.14 (x86_64, aarch64)
  • Anciens systèmes d’exploitation supprimés :
    • Alpine Linux 3.10 ; la version la plus ancienne prise en charge est 3.11
    • Amazon Linux 1 (2018.03+) ; passage à Amazon Linux 2 LTS
    • FreeBSD 11.4+ ; la version la plus ancienne prise en charge est 12.1+
    • Ubuntu 16.04 LTS ; la version la plus ancienne prise en charge est 18.04 LTS
  • Les anciens systèmes d'exploitation sont obsolètes et leur suppression est prévue dans NGINX Plus R26 :
    • Alpine Linux 3.11

Nouvelles fonctionnalités en détail

Cas d'utilisation et fonctionnalités supplémentaires du jeton Web JSON

NGINX Plus R24 a introduit la prise en charge initiale des jetons Web JSON cryptés (JWE), étendant l'une des méthodes les plus populaires d'authentification client avec la confidentialité des données. NGINX Plus R25 s’appuie sur cette capacité et introduit la prise en charge de cas d’utilisation d’authentification supplémentaires et plus avancés qui contribuent à améliorer la sécurité de l’authentification basée sur JWT pour les cas d’utilisation signés (JWS) et chiffrés (JWE). Ces améliorations réduisent à la fois le risque de fuite d’informations personnelles identifiables (PII) et offrent davantage de flexibilité. Les nouvelles fonctionnalités et améliorations JWT pour NGINX Plus incluent :

Variable pour le texte chiffré JWE décrypté

Les JWT sont une méthode largement utilisée et fiable pour l’authentification sans état des requêtes HTTP (c’est-à-dire l’authentification basée sur des jetons). En transmettant les attributs de l’utilisateur final dans la charge utile du jeton, les JWT contribuent à rendre les requêtes plus sécurisées. Cependant, les chercheurs en sécurité et les praticiens DevSecOps conviennent que le risque présenté par le stockage de PII non chiffrés sur les clients Web est une préoccupation urgente – d'où le développement de la norme de chiffrement Web JSON (RFC 7516) , qui fournit des lignes directrices pour la mise en œuvre de jetons chiffrés.

NGINX Plus R24 a introduit la prise en charge de JWE, garantissant l'intégrité et la confidentialité des données pour l'ensemble des revendications. Le codage des PII dans le jeton crypté réduit considérablement le risque de fuites de données lors de l'utilisation de JWT.

NGINX Plus R25 s'appuie sur la prise en charge initiale de JWE avec une nouvelle variable, $jwt_payload , qui permet à NGINX Plus de décrypter le JWE et le texte chiffré, puis d'accéder au texte en clair pendant le traitement de la requête HTTP. Cette nouvelle fonctionnalité peut être utilisée pour mettre en œuvre des politiques de contrôle d’accès avancées et des décisions de routage des demandes, ainsi que pour permettre aux utilisateurs de déployer NGINX Plus en tant que couche de déchiffrement JWE pour les applications back-end.

Prise en charge des JWT imbriqués

Les jetons JWE sont efficaces pour protéger les informations personnelles identifiables, le texte chiffré servant à préserver la confidentialité même sur les CDN et autres proxys de terminaison TLS. Mais le chiffrement est une arme à double tranchant, car les JWE peuvent introduire de la complexité dans l’environnement applicatif. Une façon de résoudre ce problème est d’utiliser des JWT imbriqués.

Diagramme montrant la structure d'un JWT imbriqué
Anatomie d'un JWT imbriqué

Les JWT imbriqués intègrent JWS comme texte chiffré d'un JWE. NGINX Plus R25 permet d'utiliser des JWT imbriqués comme méthode d'authentification des requêtes HTTP en prenant en charge simultanément JWS et JWE. En une seule opération, NGINX Plus peut désormais déchiffrer le texte chiffré dans le JWE, valider le texte en clair résultant en tant que JWS et utiliser les revendications exp (délai d'expiration) et nbf (pas avant) dans le jeton inclus pour vérifier qu'il est valide. Cela permet de mettre à niveau un environnement JWS existant avec un cryptage de charge utile en l'encapsulant dans un JWE.

L'extrait de configuration suivant illustre le processus. Le nouveau paramètre imbriqué de la directive auth_jwt_type indique à NGINX Plus d'effectuer à la fois le décryptage JWE et la validation JWS. Cela affecte également la manière dont les variables des en-têtes JWT et des revendications JWT sont évaluées :

 

Avec la configuration suivante, NGINX Plus construit et envoie des en-têtes de requête HTTP supplémentaires à l'application backend. L'algorithme de chiffrement de l'en-tête JWE (la variable $jwt_header_enc ) et la revendication de sujet JWT de la charge utile JWS (la variable $jwt_claim_sub ) sont proxy avec la demande d'origine. Cela signifie que les applications peuvent exploiter l’authentification basée sur JWE simplement en consommant des en-têtes HTTP, sans avoir besoin d’implémenter du code cryptographique ou des bibliothèques.

 

Pour les utilisateurs opérant dans des architectures Zero Trust, la configuration suivante permet à l’application back-end de valider le jeton JWS tel que capturé dans la variable $jwt_payload . La variable contient la version en texte clair déchiffrée du texte chiffré JWE. S'il existe un JWT imbriqué, le JWS peut être transmis à l'application backend en tant que jeton porteur.

 

Essentiellement, les JWT imbriqués rationalisent les opérations et améliorent la sécurité des applications en permettant à NGINX Plus de décrypter et de valider simultanément les jetons sécurisés, tout en analysant ou en proxy le jeton signé « JWT normal » pour les applications back-end.

Cryptage asymétrique pour JWE

NGINX Plus R24 a introduit la prise en charge du cryptage symétrique des jetons à l'aide de la norme AES. NGINX Plus R25 ajoute la prise en charge du cryptage asymétrique lors de l'utilisation de paires de clés RSA. La cryptographie asymétrique utilise différentes clés (publiques et privées) pour le chiffrement et le déchiffrement qui sont mathématiquement liées entre elles avec l' algorithme RSA (Rivest–Shamir–Adleman) , le même mécanisme utilisé pour le chiffrement SSL/TLS du trafic HTTPS entre le client et le serveur.

NGINX Plus R25 prend en charge RSA avec Optimal Asymmetric Encryption Padding (OEAP) comme algorithme de gestion de clés, sans configuration explicite requise côté NGINX Plus. Les valeurs prises en charge pour l'en-tête JWS alg (algorithme) sont RSA-OAEP , RSA-OAEP-256 , RSA-OAEP-384 et RSA-OAEP-512 .

La configuration suivante montre comment tout ce qui est nécessaire pour implémenter le chiffrement asymétrique pour JWE est de spécifier le fichier JSON Web Key (JWK) qui contient les clés privées RSA (unwrap) comme paramètre de la directive auth_jwt_key_file (la directive auth_jwt_key_request peut également être utilisée).

 

Prise en charge JWK multi-sources

L'exploitation de JWT imbriqués signifie que les JWK associés sont susceptibles de provenir de plusieurs sources. NGINX Plus R25 prend en charge plusieurs directives auth_jwt_key_file et auth_jwt_key_request dans le même contexte. NGINX Plus charge les clés de toutes les sources spécifiées et recherche la clé de vérification correspondante parmi l'ensemble combiné de clés, ce qui est extrêmement utile lorsque vous travaillez avec un JWS émis par un fournisseur d'identité externe et imbriqué dans un JWE, où le cryptage a été effectué par un processus séparé.

Cette fonctionnalité ajoute davantage de flexibilité, de sécurité et de puissance à NGINX Plus déployé en tant que passerelle API.

Règles de validation JWT personnalisées

Lorsque NGINX Plus est déployé en tant que passerelle API, il est courant d’inspecter les revendications JWT pour mettre en œuvre un contrôle d’accès précis. Cela peut conduire à des configurations complexes. Dans les versions précédentes de NGINX Plus, vous pouviez utiliser des blocs de configuration pour évaluer les revendications JWT, mais cette approche était quelque peu limitée et ne fonctionnait pas pour les jetons chiffrés.

NGINX Plus R25 résout cette limitation en fournissant un moyen natif d'effectuer des vérifications supplémentaires sur le jeton pendant le processus de validation JWT. La directive auth_jwt_require ajoute une étape facultative et personnalisable au processus de validation JWT. Il accepte une liste de chaînes séparées par des espaces, qui doivent toutes être non vides et différentes de0 (zéro) pour que la validation JWT réussisse. Cela ajoute une grande flexibilité au processus de validation JWT.

La norme JWT ne prescrit pas quelles revendications sont obligatoires, vous pouvez donc utiliser auth_jwt_require pour répertorier les revendications appropriées pour chaque environnement.

La configuration suivante garantit que les revendications exp et sub sont présentes dans chaque jeton.

 

Vous pouvez configurer des cas d’utilisation plus complexes en utilisant des blocs de carte ou le magasin de valeurs clés NGINX Plus pour transmettre des valeurs booléennes à la directive auth_jwt_require . Vous pouvez également utiliser le module JavaScript NGINX pour implémenter des solutions d’authentification riches telles que les jetons d’accès liés au certificat client TLS mutuel (mTLS) (définis dans la RFC 8705 ).

La configuration suivante effectue à la fois l’authentification du certificat client (mTLS) et la validation JWT. La directive auth_jwt_require de la ligne 14 appelle l’évaluation de la variable $thumbprint_match , et la validation JWT réussit uniquement si elle a une valeur différente de zéro. Cette variable est évaluée en exécutant la fonction JavaScript invoquée à la ligne 2.

 

Voici le code de la fonction de validation invoquée à la ligne 2 de l'extrait précédent :

 

Rapports plus détaillés sur les codes de réponse HTTP

La surveillance et la visibilité sont les pierres angulaires des performances, de la disponibilité et de la sécurité des applications. Les codes de réponse HTTP sont l’une des sources d’informations les plus cruciales sur la santé des applications. L' API NGINX Plus suit les codes de réponse HTTP à la fois pour les interactions entre NGINX et les clients, et entre NGINX et les serveurs en amont ; les comptes sont signalés dans les onglets correspondants du tableau de bord de surveillance des activités en direct de NGINX Plus.

Les versions précédentes de l' API NGINX Plus regroupaient le nombre de codes de réponse HTTP par classe ( 2xx , 4xx , etc.). Désormais, les codes sont également comptés individuellement ( 200,404 ,503 , etc.). Cela vous donne un aperçu plus approfondi de ce qui se passe exactement avec une application, en distinguant les erreurs qui ont des causes très différentes, telles que les pics d'authentifications échouées (403 ) et le contenu manquant (404 ). Pour plus d'informations sur la configuration de la collecte de métriques, consultez le Guide d'administration NGINX Plus .

La dernière version de l' API NGINX Plus ( version 7 ), publiée avec NGINX Plus R25 , inclut un objet codes dans l'objet réponses pour permettre le comptage des codes de réponse HTTP individuels. Les réponses agrégées sont toujours disponibles et les versions précédentes de l' API NGINX Plus , qui n'incluent pas l'objet codes , peuvent toujours être utilisées avec NGINX Plus R25 . Voici un exemple du nouvel ensemble de mesures :

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "traitement": 31, « demandes » : 63192, "réponses": { "1xx": 0, « 2xx » : 54368, « 3xx » : 8454, « 4xx » : 330, « 5xx » : 9, "codes": { "200": 54368, « 302 » : 8454, « 401 » : 30, « 404 » : 200, « 429 » : 100, « 503 » : 9 }, "totale": 63161 }, "rejeté": 0, "reçu" : 693436, « envoyé » : 13843478 }

Allouer suffisamment de mémoire pour éviter les échecs de démarrage

Remarque importante : Lorsque NGINX Plus est configuré comme proxy inverse ou équilibreur de charge, le comptage des codes individuels augmente l'utilisation de la mémoire dans la zone de mémoire partagée pour chaque groupe en amont. S'il y a plus de 20 homologues dans le groupe en amont , vous devrez peut-être augmenter la taille de la mémoire, comme configuré avec la directive zone .

NGINX Plus R25 ne démarre pas si les zones en amont sont sous-provisionnées, ce qui entraîne l'échec des mises à niveau.

Voici une configuration typique de la zone de mémoire partagée pour un groupe en amont :

 

Avant de procéder à la mise à niveau vers NGINX Plus R25 , il est important de vérifier l’utilisation de la mémoire pour les zones en amont existantes. Pour ce faire, assurez-vous que l’ API NGINX Plus est activée avant d’utiliser l’une de ces méthodes :

  • Vérifiez l'onglet HTTP Upstreams du tableau de bord de surveillance des activités en direct, comme dans cet exemple de demo.nginx.com , où l'utilisation est de 54 % :

  • Utilisez l’ API NGINX Plus directement depuis l’hôte en exécutant la commande suivante. D'abord:

    • Installez l' utilitaire jq si nécessaire
    • Définissez la variable API sur l’emplacement où la directive API est activée
    $ API=http://localhost:8080/api; pour i dans `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; faire echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% utilisé"'; terminé

Si l'utilisation actuelle est supérieure à 40 % (comme dans la capture d'écran), augmentez le deuxième paramètre (taille) de la directive de zone d'au moins 2,5x. Par exemple, nous recommandons d’augmenter de 64 k à 160 k dans l’extrait de configuration ci-dessus.

Chargement de certificat client SSL/TLS dynamique pour le proxy

Le protocole TLS mutuel (mTLS) est une pratique d’authentification courante qui implique la vérification de l’identité du client et du serveur. Avec NGINX Plus, vous pouvez définir les serveurs d’un groupe en amont de manière dynamique et avec des variables. Cela implique que vous devrez peut-être également pouvoir sélectionner dynamiquement le certificat TLS utilisé par NGINX Plus pour se vérifier auprès de ces serveurs en amont.

NGINX Plus R25 étend les directives de configuration utilisées pour mTLS à un serveur backend, pour accepter une variable représentant le certificat. La variable peut faire référence à l'un ou l'autre de ces éléments :

  • Un fichier sur le disque
  • Données brutes au format PEM, préfixées par data :

Cela permet à NGINX Plus de sélectionner un certificat et une clé privée de manière dynamique, ce qui est utile pour les environnements d'application modernes soumis à des changements constants. Vous pouvez stocker le certificat et la clé privée dans le magasin de clés-valeurs NGINX Plus , ce qui améliore la sécurité car la clé privée est stockée en mémoire plutôt que sur le disque. Un autre cas d’utilisation est la rotation automatisée des certificats, où vous utilisez un appel API pour mettre à jour les certificats dans le magasin clé-valeur.

Dans la configuration suivante, NGINX Plus achemine les requêtes vers différents groupes en amont en fonction du nom d’hôte. La connexion proxy est établie à l'aide de mTLS et le certificat client approprié pour chaque connexion en amont est sélectionné de manière dynamique.

 

Les directives suivantes prennent en charge le chargement dynamique de certificats pour mTLS avec des serveurs en amont :

Sécurité renforcée pour le traitement des requêtes HTTP

L’un des principes fondamentaux de la philosophie NGINX est l’amélioration continue, notamment en matière de sécurité. Nous utilisons toutes les ressources disponibles, y compris la collaboration avec les chercheurs en sécurité, l’intégration des technologies de sécurité de pointe de F5 dans nos produits et les efforts de développement interne.

À titre d’exemple, NGINX Plus R25 effectue plusieurs vérifications supplémentaires sur les requêtes HTTP pour protéger vos applications contre des attaques potentielles, telles que la contrebande de requêtes . Il renvoie une erreur pour ces conditions :

  • Une requête HTTP/1.0 inclut l'en-tête Transfer-Encoding
  • Les en-têtes Transfer-Encoding et Content-Length sont tous deux présents
  • Il y a des espaces ou des caractères de contrôle dans la ligne de demande ou dans n'importe quel nom d'en-tête
  • Il y a des espaces ou des caractères de contrôle dans l'en-tête de l'hôte
  • La méthode CONNECT est utilisée

De plus, les caractères suivants sont désormais toujours échappés dans un URI proxy : " , < , > , \ , ^ , ` , { , | , } .

Veuillez noter que ces modifications constituent des améliorations de sécurité proactives et ne sont pas apportées en réponse à une vulnérabilité connue.

Persistance du statut de contrôle de santé obligatoire lors du rechargement pour les applications TCP/UDP

NGINX Plus utilise des contrôles de santé obligatoires pour garantir que les nouveaux serveurs ajoutés aux groupes en amont sont testés et sains avant que les demandes des clients ne leur soient transmises par proxy. Dans NGINX Plus R23 et les versions antérieures, les serveurs en amont étaient considérés comme non sains après un rechargement de configuration, quel que soit leur état avant le rechargement. Par conséquent, NGINX Plus n’envoyait pas de requêtes à un serveur tant que le premier contrôle obligatoire n’était pas passé.

NGINX Plus R24 a introduit la persistance facultative de l'état de contrôle de santé obligatoire lors des rechargements, pour les applications HTTP. Si le dernier contrôle d’intégrité obligatoire avant un rechargement a réussi, NGINX Plus peut envoyer des requêtes à un serveur immédiatement plutôt que de devoir attendre qu’un contrôle d’intégrité obligatoire après rechargement réussisse.

NGINX Plus R25 étend cette fonctionnalité aux applications TCP/UDP (dans le contexte du flux ). Pour HTTP, ajoutez le paramètre persistent à la directive health_check avec le paramètre obligatoire .

 

Améliorations apportées au module JavaScript NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.6.2 avec plusieurs corrections de bugs et quelques améliorations fonctionnelles qui renforcent la compatibilité avec JavaScript ES6 .

Déclaration de variable avec les mots-clés let et const

NGINX JavaScript prend désormais en charge la déclaration de variables à portée limitée à l'aide des mots-clés let et const . Les versions précédentes de NGINX Plus et njs prenaient en charge uniquement le mot-clé var pour la déclaration et l'attribution de variables. Cela ne prévoyait pas de variables limitées à la portée d'une instruction de bloc particulière, qui sont nécessaires pour gérer la complexité qui survient souvent lorsque différents projets, langages de programmation et équipes d'ingénierie collaborent sur des bases de code ou des bibliothèques partagées.

JavaScript ES6 fournit les mots-clés let et const pour définir des variables à portée limitée :

  • les variables let sont limitées à la portée d'une instruction de bloc ou d'une expression sur laquelle elle est utilisée. En revanche, le mot-clé var déclare une variable globalement ou localement sur une fonction entière, quelle que soit la portée du bloc.
  • Les variables const ont une portée de bloc, tout comme les variables déclarées à l’aide du mot-clé let . La valeur d’une constante ne peut pas être modifiée par réaffectation et ne peut pas être redéclarée.

Prise en charge de toutes les méthodes de construction de promesses

Avec l'ajout des méthodes constructeur Promise.all() , Promise.allSettled() , Promise.any() et Promise.race() , njs prend désormais en charge l'ensemble complet des méthodes constructeur définies dans la norme JavaScript ES6.

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R25 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer dès aujourd'hui avec un essai gratuit de 30 jours .

Lire plus d'articles de blog sur F5 NGINX ›

« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."