Annonce de NGINX Plus R17

[ Éditeur – Le module WAF NGINX ModSecurity pour NGINX Plus est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

Nous sommes heureux d'annoncer que NGINX Plus Release 17 (R17) est désormais disponible. NGINX Plus est le seul équilibreur de charge, cache de contenu, serveur Web et passerelle API tout-en-un. NGINX Plus est basé sur NGINX Open Source et inclut des fonctionnalités améliorées exclusives et un support primé.

La nouveauté de cette version est la prise en charge de TLS 1.3 , la dernière version du protocole responsable de tout le trafic sécurisé sur Internet. Cela fait plus de 10 ans que TLS 1.2 est sorti et beaucoup de choses ont changé depuis. De nombreuses vulnérabilités de sécurité ont été découvertes dans TLS 1.2, telles que FREAK, Heartbleed, POODLE et ROBOT. Bon nombre de ces vulnérabilités résultaient d’un trop grand nombre d’options de configuration non sécurisées dans TLS 1.2, qui laissaient les sites ouverts aux attaques.

TLS 1.3 est une addition par soustraction. De nombreux chiffrements non sécurisés ont été supprimés et l’échange de clés Diffie-Hellman est désormais obligatoire. Le résultat est un TLS allégé, plus rapide et plus sécurisé. Au moment de la rédaction de cet article, Alpine Linux 3.9, FreeBSD 12.0 et Ubuntu 18.10 prennent en charge TLS 1.3. Vous pouvez donc les utiliser avec NGINX Plus R17 pour TLS 1.3 dans votre environnement de production ; d'autres fournisseurs de systèmes d'exploitation prendront sans doute en charge TLS 1.3 dans les versions futures. Notez que F5 BIG-IP et d’autres équilibreurs de charge matériels ne prennent actuellement pas entièrement en charge TLS 1.3.

NGINX Plus R17 inclut également ces nouvelles fonctionnalités :

• Limitation de débit en deux étapes – La limitation de débit est l’une des fonctionnalités les plus populaires de NGINX Open Source et NGINX Plus. Il peut être utilisé pour atténuer les attaques DDoS et, en général, protéger les serveurs d'applications contre le fait d'être submergés par un trop grand nombre de requêtes. Le nouveau paramètre de délai aide la limitation du débit de NGINX Plus à mieux s'adapter aux modèles de demande de navigateur typiques. Les méthodes de retard et de rejet existantes peuvent désormais être combinées pour fournir une limitation de débit en deux étapes, selon laquelle les demandes excessives sont initialement retardées, puis finalement rejetées si la limite de débit est toujours dépassée.
• Configuration OpenID Connect plus simple – Dans NGINX Plus R15, nous avons introduit l’intégration OpenID Connect pour permettre à nos clients d’ajouter l’authentification unique (SSO) à leurs applications. Dans R17, nous avons simplifié la configuration pour récupérer automatiquement les clés Web JSON (JWK) auprès du fournisseur d'identité (IdP).
• NGINX Modsecurity WAF est 2 fois plus rapide – NGINX ModSecurity WAF, un module dynamique pour NGINX Plus basé sur ModSecurity v3, offre une protection robuste contre les attaques de couche 7. ModSecurity est activement développé et la dernière version de NGINX ModSecurity WAF offre des performances 2 fois meilleures et un certain nombre d'améliorations supplémentaires.

Les améliorations supplémentaires de NGINX Plus R17 incluent les keepalives TCP vers les réseaux en amont, la prise en charge SNI dans les environnements en cluster, et bien plus encore.

Changements importants dans le comportement

• NGINX Plus R13 a introduit la toute nouvelle API NGINX Plus pour la collecte de métriques et la reconfiguration dynamique des groupes en amont, remplaçant les API Status et Upstream Conf qui implémentaient auparavant ces fonctions. Comme annoncé à l'époque, les API obsolètes ont continué à être disponibles et prises en charge pendant une période significative, qui a pris fin avec NGINX Plus R16 . Si votre configuration inclut les directives status et/ou upstream_conf , vous devez les remplacer par la directive api dans le cadre de la mise à niveau vers R17.

  Pour obtenir des conseils et de l'aide sur la migration vers l' API NGINX Plus , veuillez consulter le guide de transition sur notre blog ou contacter notre équipe d'assistance.

• Nouveaux systèmes d’exploitation pris en charge :

  • Alpine Linux 3.8
  • Alpine Linux 3.9
  • FreeBSD 11.2
  • FreeBSD 12.0
  • Serveur SUSE Linux Enterprise 15
  • Ubuntu 18.10 (Cosmique)

• Anciens systèmes d’exploitation supprimés ou dont la suppression est prévue :

  • FreeBSD 10.4 et 11.1 ne sont plus pris en charge.
  • La prise en charge de CentOS/Oracle/RHEL 7.3 et versions antérieures sera interrompue dans NGINX Plus R18 .
  • La prise en charge d'Ubuntu 14.04 sera interrompue dans NGINX Plus R19 .

Nouvelles fonctionnalités en détail

TLS 1.3 : Addition par soustraction

Cela fait plus de 10 ans qu'une mise à jour majeure de TLS a été effectuée. TLS 1.2 a été défini en août 2008 dans la RFC 5246 , et Internet a considérablement changé depuis lors. TLS 1.3 a été ratifié en août 2018 sous la forme de RFC 8446 pour aider à résoudre de nombreux problèmes rencontrés dans TLS 1.2 et définir une plate-forme plus évolutive pour l'avenir.

Plus sécurisé

Au fil des années, de nombreuses vulnérabilités de sécurité dans TLS 1.2 ont été révélées, telles que FREAK , Heartbleed , POODLE et ROBOT . FREAK, par exemple, permet à un attaquant de rétrograder une connexion TLS pour utiliser un chiffrement d'exportation avec une longueur de clé de 40 bits, qui peut être forcé brutalement. TLS 1.3 supprime complètement les chiffrements d'exportation.

De nombreux problèmes survenus avec TLS 1.2 et les spécifications antérieures sont dus au grand nombre d’options configurables par l’utilisateur. Une mauvaise utilisation des options conduit souvent à des configurations non sécurisées qui pourraient être exploitées par des attaquants. TLS 1.3 supprime un certain nombre de ces options :

• AES-CBC
• Groupes Diffie-Hellman arbitraires
• Exporter des chiffrements
• DES/3DES
• MD5
• Rembourrage PKCS#1 v1.5
• RC4
• Transport de clé RSA (Diffie-Hellman est obligatoire)
• SHA‑1

Meilleures performances

Le transport de clé RSA est particulièrement remarquable dans la liste des suppressions. Ce mode a été utilisé principalement parce qu'il était plus rapide que Diffie-Hellman, qui nécessitait un aller-retour supplémentaire pour établir la connexion avec Perfect Forward Secrecy (PFS). Avec TLS 1.3, l'aller-retour supplémentaire n'est plus nécessaire. Avec moins d’options de configuration, il y a moins d’informations à échanger et la négociation Diffie-Hellman ne nécessite qu’un seul aller-retour (le diagramme montre également une requête GET après la négociation).

De plus, TLS 1.3 prend en charge la reprise de session , ce qui accélère l’établissement de la connexion en éliminant la surcharge liée à la répétition de la négociation TLS lorsqu’un client revient sur un site précédemment visité. Ceci est également appelé reprise 0-RTT (zéro temps aller-retour) , car aucun message de négociation ne doit faire l'aller-retour entre le client et le serveur pour la session reprise. La reprise de session est implémentée en créant un secret partagé pendant la session d'origine et en le stockant dans un ticket de session . Lorsque le client revient, il présente le ticket de session accompagné de sa demande, qui est chiffrée avec le secret partagé contenu dans le ticket.

L’utilisation de 0-RTT ouvre le risque d’une attaque par relecture comme illustré ci-dessous. Dans ce scénario, l’attaquant renvoie un paquet qui entraîne un changement d’état, comme une demande de transfert d’argent entre deux comptes bancaires.

Pour se protéger contre les attaques par relecture, le seul type de requête HTTP que les clients doivent envoyer dans les données 0-RTT (les données chiffrées avec le secret partagé) est GET . Les requêtes HTTP GET sont idempotentes par définition ( RFC 7231 ), donc les rejouer n'a aucun effet. Le chargement d'une page est généralement la première chose qu'un client fait lorsqu'il revisite un site, et la plupart des chargements de pages commencent par une requête GET , donc l'activation de la reprise de session accélère une grande partie des requêtes sur la plupart des sites Web. Toutefois, vous ne souhaiterez peut-être pas activer la reprise 0-RTT lors du déploiement de NGINX Plus en tant que passerelle API, car pour le trafic API, les sessions TLS reprises sont plus susceptibles de contenir des types de requêtes non idempotentes.

TLS 1.3 lui-même protège également contre les attaques par relecture en incluant des informations de synchronisation dans le ticket de session et la demande du client, ce qui permet au serveur de déterminer si la demande est arrivée du client assez rapidement après son envoi par le client. Un attaquant ne peut pas modifier les informations de synchronisation, donc si la demande a mis trop de temps à arriver, elle a probablement été rejouée.

Comment activer TLS 1.3 dans NGINX Plus

TLS 1.3 et 0-RTT ne sont pas activés par défaut.

Pour activer TLS 1.3, incluez le paramètre TLSv1.3 à la directive ssl_protocols . Nous vous recommandons d'inclure également TLSv1.2 car tous les navigateurs ne prennent pas en charge TLS 1.3 au moment de la rédaction (voir la section suivante). NGINX Plus utilise TLS 1.3 si le client le prend en charge et revient à TLS 1.2 dans le cas contraire.

Pour activer 0-RTT, définissez également la directive ssl_early_data sur on .

Cette configuration permet les deux fonctionnalités :

serveur { écouter 443 ssl; certificat_ssl /etc/ssl/my_site_cert.pem; clé_certificat_ssl /etc/ssl/my_site_key.pem; protocoles_ssl TLSv1.2 TLSv1.3 ; ssl_early_data activé ; # Activer 0-RTT (TLS 1.3) emplacement / { proxy_pass http://my_backend; } }

Plateformes prises en charge

Côté serveur, TLS 1.3 nécessite OpenSSL 1.1.1 ou une version ultérieure. Au moment de la rédaction de cet article, seuls Alpine Linux 3.9, FreeBSD 12.0 et Ubuntu 18.10 sont livrés avec OpenSSL 1.1.1.

Côté client, nous recommandons Chrome 70 ou Firefox 63. Ils prennent en charge la version finale de TLS 1.3, mais ne l'activent pas par défaut ; suivez ces instructions pour activer TLS 1.3 dans le navigateur . Au moment de la rédaction de cet article, d’autres navigateurs populaires (notamment Firefox pour Android et Safari pour iOS et Mac) ne prennent pas encore en charge TLS 1.3. Pour obtenir les dernières informations sur le statut, consultez Puis-je utiliser : TLS 1.3 .

Limitation de débit à deux niveaux

Auparavant, NGINX Plus pouvait imposer des limites au taux de requêtes de deux manières : en rejetant immédiatement les requêtes excessives ou en mettant en file d'attente les requêtes excessives jusqu'à ce qu'elles puissent être traitées conformément à la limite de taux définie. Avec NGINX Plus R17 , vous pouvez combiner les deux méthodes d'application pour une limitation de débit en deux étapes, selon laquelle les demandes excessives sont initialement retardées et finalement rejetées si la limite de débit est toujours dépassée.

Lors de l’application des limites de débit, il est essentiel de prendre en compte le comportement typique des clients légitimes. Par exemple, les navigateurs Web tentent généralement de télécharger plusieurs ressources simultanément. Il est donc raisonnable de voir une demande de contenu HTML, suivie rapidement de demandes de feuilles de style, de code JavaScript et d’images. Pour cette raison, nous souhaiterons peut-être autoriser une rafale de 10 à 20 requêtes rapides avant d'appliquer une limite de débit.

Avec NGINX Plus R17, vous pouvez désormais autoriser une rafale pour répondre au modèle de demande typique du navigateur Web, puis retarder les demandes excessives supplémentaires jusqu'à un point au-delà duquel les demandes excessives supplémentaires sont rejetées. La limitation de débit en deux étapes est activée avec le nouveau paramètre de délai de la directive limit_req .

Pour illustrer la limitation de débit en deux étapes, nous configurons ici NGINX Plus pour protéger un site Web en imposant une limite de débit de 5 requêtes par seconde ( rate=5r/s ). Le site Web contient généralement 4 à 6 ressources par page, et jamais plus de 12 ressources. La configuration permet des rafales allant jusqu'à 12 requêtes, dont les 8 premières sont traitées sans délai. Un délai est ajouté après 8 requêtes excessives pour respecter la limite de 5 r/s. Après 12 demandes excessives, toute demande supplémentaire est rejetée.

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

Le paramètre de délai définit le point auquel, dans la taille de la rafale, les demandes excessives sont limitées (retardées) pour se conformer à la limite de débit définie. Avec cette configuration en place, un client qui effectue un flux continu de requêtes à 8 r/s connaît le comportement suivant.

Les 8 premières requêtes (la valeur de delay ) sont proxyées par NGINX Plus sans délai. Les 4 requêtes suivantes ( burst - delay ) sont retardées afin que le débit défini de 5 r/s ne soit pas dépassé. Les 3 demandes suivantes sont rejetées car la taille totale de la rafale a été dépassée. Les demandes ultérieures sont retardées.

Notez que cette illustration est une description simplifiée du processus car elle ignore l’impact des demandes terminées sur le calcul du nombre de demandes excédentaires en cours de traitement. En réalité, chaque demande terminée ouvre un emplacement dans la file d'attente de retard pour une autre demande excessive afin de s'adapter à la taille de rafale configurée. Pour plus d’informations sur la mise en œuvre de la limitation de débit, consultez Limitation de débit avec NGINX et NGINX Plus sur notre blog.

Configuration simplifiée d'OpenID Connect

Lors de l'exécution de la validation JWT, NGINX Plus R17 peut désormais être configuré pour récupérer l'ensemble de clés Web JSON (JWK) à partir de l'emplacement distant (généralement un fournisseur d'identité ou IdP) spécifié par la nouvelle directive auth_jwt_key_request . La récupération automatique est particulièrement pratique lors de l'intégration avec un IdP qui fait tourner fréquemment les clés.

La plupart des IdP fournissent une URL fixe où l'ensemble actuel de clés peut être obtenu, en particulier s'ils prennent en charge OpenID Connect Discovery ; dans ce cas, l'URL des clés est définie par la valeur jwks_uri .

# Créer un répertoire pour mettre en cache les clés reçues de IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
listen 80; # Utiliser SSL/TLS en production

location / {
auth_jwt "closed site";
auth_jwt_key_request /_jwks_uri; # Les clés seront récupérées par sous-requête

proxy_pass http://my_backend;
}

location = /_jwks_uri {
internal;
proxy_cache jwk; # Mettre en cache les réponses
proxy_pass https://idp.example.com/oauth2/keys; # Obtenir les clés à partir d'ici
}
}

Des directives de mise en cache supplémentaires peuvent être utilisées pour remplacer les en-têtes Expires et Cache-Control renvoyés par la sous-requête. L'utilisation de proxy_cache_use_stale permet à NGINX Plus de continuer à utiliser les clés mises en cache lorsque l'URL des clés n'est pas disponible.

Notre implémentation de référence OpenID Connect a été mise à jour pour inclure la prise en charge de auth_jwt_key_request et la configuration automatique pour les IdP qui prennent en charge OpenID Connect Discovery.

La prise en charge de JWT a également été étendue pour prendre en charge deux variantes de l' algorithme de signature numérique à courbe d'Edwards (EdDSA) : Ed448 et Ed25519. Notez qu'EdDSA nécessite OpenSSL 1.1.1 ou une version ultérieure, qui, au moment de la rédaction, n'est disponible que dans Ubuntu 18.10 et FreeBSD 12.0.

Note: La prise en charge d'OpenID Connect est exclusive à NGINX Plus.

WAF NGINX ModSecurity 2x plus rapide

Le module NGINX ModSecurity WAF pour NGINX Plus est notre version prise en charge du pare-feu d'application Web (WAF) open source ModSecurity utilisé par plus d'un million de sites. Nous travaillons activement avec l'équipe TrustWave SpiderLabs pour améliorer les performances de ModSecurity avec NGINX Plus, et sommes heureux d'annoncer que la dernière version est deux fois plus performante que les versions précédentes.

Cette version ajoute également la prise en charge de pdateActionById , ctl:requestBodyProcessor=URLENCODED et de l'action setenv .

La nouvelle version NGINX ModSecurity WAF est basée sur ModSecurity 3.0.3 ; pour plus de détails, consultez le blog TrustWave SpiderLabs .

Note: NGINX ModSecurity WAF est exclusif à NGINX Plus.

Autres nouvelles fonctionnalités de NGINX Plus R17

TCP Keepalives vers les flux en amont

La nouvelle directive proxy_socket_keepalive contrôle si les keepalives TCP sont activés entre NGINX Plus et le serveur proxy. Les keepalives TCP améliorent les performances des protocoles (tels que WebSocket) où il existe un périphérique réseau TCP avec état entre NGINX et le serveur proxy, avec des connexions de longue durée et souvent inactives. Sans les fonctions de keepalives TCP, ces périphériques risquent de fermer plus souvent les connexions TCP inactives, entraînant ainsi la surcharge nécessaire pour les rétablir à partir de zéro.

La directive est également disponible dans les modules FastCGI , gRPC , memcached , SCGI et uwsgi .

Délai d'expiration et limite de requête du Keepalive HTTP en amont

La nouvelle directive keepalive_timeout définit le temps d'inactivité maximal avant la fermeture d'une connexion HTTP keepalive entre NGINX Plus et le serveur proxy. De plus, la directive keepalive_requests définit le nombre maximal de requêtes qui peuvent être envoyées via une connexion keepalive (auquel cas elle est fermée et une nouvelle créée).

Taille de session UDP en amont finie

La nouvelle directive proxy_requests (module Stream) définit le nombre maximal de paquets UDP envoyés depuis NGINX Plus au serveur proxy avant qu'une nouvelle « session » UDP ne soit créée. Cela permet un équilibrage de charge plus uniforme des paquets UDP lorsqu'un seul client envoie un grand nombre de paquets UDP en peu de temps (ce qui peut se produire lorsqu'il existe un proxy en aval, par exemple).

Amélioration du partage d'état de cluster

Lorsque vous utilisez le partage d’état dans un cluster, vous pouvez désormais effectuer une vérification du nom du serveur, en utilisant SNI pour transmettre le nom du serveur lors de la connexion aux nœuds du cluster. Ceci est implémenté avec les directives zone_sync_ssl_name et zone_sync_ssl_server_name .

Note: Le clustering et le module zone_sync sont exclusifs à NGINX Plus

Mises à jour de l'écosystème NGINX Plus

Améliorations du contrôleur d'entrée

Le contrôleur d'entrée officiel NGINX pour Kubernetes a été mis à jour vers la version 1.4.0. Le journal des modifications répertorie tous les changements, correctifs et améliorations, et les plus notables sont mis en évidence sur notre blog :

• Prise en charge étendue de Prometheus
• Équilibrage de charge TCP/UDP
• L'algorithme d'équilibrage de charge aléatoire avec deux choix est le nouvel algorithme par défaut
• Annotations personnalisées

Pour en savoir plus sur le contrôleur d'entrée officiel NGINX pour Kubernetes, consultez notre site Web et le référentiel GitHub .

Améliorations du module JavaScript

NGINX Plus R17 inclut un certain nombre d'améliorations qui étendent la portée de la prise en charge du langage JavaScript :

• arguments objets
• Fractions non entières
• Méthodes de temps supplémentaires : console.time() et console.timeEnd()
• Les variables et les fonctions peuvent désormais être redéclarées

L'intégration avec le module NGINX Stream pour les applications TCP/UDP a été refactorisée pour utiliser diverses fonctions de retour, y compris une méthode send() pour modifier le trafic entrant. Le trafic de sortie est désormais disponible via un rappel.

L'ensemble complet des modifications peut être trouvé dans le journal des modifications du module JavaScript NGINX .

Mettre à niveau ou essayer NGINX Plus

NGINX Plus R17 inclut la prise en charge de TLS 1.3, qui est plus sécurisé et plus performant que TLS 1.2. Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers la version 17 et TLS 1.3 dès que possible. Vous bénéficierez également d'un certain nombre de correctifs et d'améliorations supplémentaires, et cela aidera NGINX, Inc. à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

Veuillez examiner attentivement les nouvelles fonctionnalités et les changements de comportement décrits dans cet article de blog avant de procéder à la mise à niveau.

Si vous n'avez pas essayé NGINX Plus ou NGINX ModSecurity WAF , nous vous encourageons à les 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 gratuitement dès aujourd’hui avec une évaluation gratuite de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.

[ Éditeur – NGINX ModSecurity WAF est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]