Annonce de NGINX Plus R17

Liam CrillyDirecteur senior de la gestion des produits

[Éditeur – Le module NGINX ModSecurity WAF pour NGINX Plus a officiellement cessé d’être commercialisé le 1er avril 2022 et arrivera en fin de vie le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF passe en fin de vie<.htmla> sur notre blog.]

Nous avons le plaisir d’annoncer que NGINX Plus version 17 (R17) est désormais disponible. NGINX Plus est la seule solution tout-en-un faisant office d’équilibreur de charge, de cache de contenu, de serveur web et de passerelle API. NGINX Plus repose sur NGINX Open Source et inclut des fonctionnalités avancées exclusives ainsi qu’un support primé.

Cette version introduit la prise en charge de TLS 1.3, la dernière version du protocole qui sécurise l’ensemble du trafic sur Internet. Plus de 10 ans se sont écoulés depuis la sortie de TLS 1.2, et beaucoup de choses ont changé depuis. De nombreuses vulnérabilités de sécurité ont été découvertes dans TLS 1.2, notamment FREAK, Heartbleed, POODLE et ROBOT. Beaucoup de ces vulnérabilités étaient dues à un trop grand nombre d’options de configuration non sécurisées dans TLS 1.2, qui exposaient les sites à des attaques.

TLS 1.3 fait plus avec moins. De nombreux algorithmes de chiffrement non sécurisés ont été supprimés et l’échange de clés Diffie-Hellman est désormais obligatoire. Il en résulte un protocole TLS allégé, plus rapide et plus sécurisé. À l’heure où nous écrivons ces lignes, 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 déployer TLS 1.3 dans votre environnement de production. D’autres éditeurs de systèmes d’exploitation prendront sans aucun doute en charge TLS 1.3 dans leurs prochaines versions. Notez que F5 BIG-IP et les autres répartiteurs de charge matériels ne prennent actuellement pas entièrement en charge TLS 1.3.

NGINX Plus R17 inclut également les nouvelles fonctionnalités suivantes :

• Limitation du débit en deux étapes – La limitation du débit est l’une des fonctionnalités les plus populaires de NGINX Open Source et de NGINX Plus. Elle permet d’atténuer les attaques DDoS et, plus généralement, d’éviter que les serveurs d’applications ne soient submergés par un trop grand nombre de requêtes. Le nouveau paramètre delay permet à la limitation du débit de NGINX Plus de mieux s’adapter aux schémas de requêtes habituels des navigateurs. Les méthodes existantes d’application par temporisation et par rejet peuvent désormais être combinées pour assurer une limitation du débit en deux étapes : les requêtes excédentaires sont d’abord retardées, puis finalement rejetées si la limite de débit est toujours dépassée.
• Configuration simplifiée d’OpenID Connect – Dans NGINX Plus R15, nous avons introduit l’intégration d’OpenID Connect afin de permettre à nos clients d’ajouter l’authentification unique (SSO) à leurs applications. Dans R17, nous avons simplifié la configuration afin de récupérer automatiquement les clés web JSON (JWK) auprès du fournisseur d’identité (IdP).
• Le WAF NGINX ModSecurity 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 fait l’objet d’un développement actif, et la dernière version de NGINX ModSecurity WAF offre des performances 2 fois supérieures ainsi que plusieurs améliorations supplémentaires.

Améliorations supplémentaires dans NGINX Plus R17 : connexions TCP persistantes vers les serveurs en amont, prise en charge de SNI dans les environnements en cluster, et bien plus encore.

Changements importants de comportement

• NGINX Plus R13 a introduit la toute nouvelle API NGINX Plus pour la collecte de métriques et la reconfiguration dynamique des groupes de serveurs en amont, remplaçant les API Status et Upstream Conf qui assuraient auparavant ces fonctions. Comme annoncé à l’époque, les API obsolètes sont restées disponibles et prises en charge pendant une période prolongée, qui a pris fin avec NGINX Plus R16. Si votre configuration comprend 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 concernant la migration vers l’API NGINX Plus, consultez le guide de transition sur notre blog ou contactez 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
  • SUSE Linux Enterprise Server 15
  • Ubuntu 18.10 (Cosmic)
• 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 des versions antérieures sera abandonnée dans NGINX Plus R18.
  • La prise en charge d’Ubuntu 14.04 sera abandonnée dans NGINX Plus R19.

Présentation détaillée des nouvelles fonctionnalités

TLS 1.3 : ajouter en supprimant

Cela fait plus de 10 ans que TLS n’a pas connu de mise à jour majeure. TLS 1.2 a été défini en août 2008 dans la norme RFC 5246, et Internet a considérablement évolué depuis. TLS 1.3 a été ratifié en août 2018 dans la norme RFC 8446 afin de résoudre bon nombre des problèmes rencontrés dans TLS 1.2 et d’établir une plateforme plus évolutive pour l’avenir.

Plus sécurisé

Au fil des ans, de nombreuses vulnérabilités de sécurité ont été découvertes dans TLS 1.2, notamment FREAK, Heartbleed, POODLE et ROBOT. FREAK, par exemple, permet à un attaquant de rétrograder une connexion TLS afin qu’elle utilise un algorithme de chiffrement d’exportation avec une clé de 40 bits, qui peut être cassée par force brute. TLS 1.3 supprime complètement les algorithmes de chiffrement d’exportation.

Bon nombre des problèmes rencontrés avec TLS 1.2 et les spécifications antérieures sont dus au grand nombre d’options configurables par l’utilisateur. Une mauvaise utilisation de ces options a souvent conduit à des configurations non sécurisées susceptibles d’être exploitées par des attaquants. TLS 1.3 supprime plusieurs de ces options :

• AES‑CBC
• Groupes Diffie-Hellman arbitraires
• Chiffrements d’exportation
• DES/3DES
• MD5
• Remplissage PKCS#1 v1.5
• RC4
• Transport de clé RSA (Diffie-Hellman est obligatoire)
• SHA‑1

De meilleures performances

Parmi les éléments supprimés, on notera le transport de clés RSA. Ce mode était principalement utilisé parce qu’il était plus rapide que Diffie-Hellman, qui nécessitait un aller-retour supplémentaire pour établir la connexion avec la confidentialité persistante (PFS). Avec TLS 1.3, cet aller-retour supplémentaire n’est plus nécessaire. Le nombre réduit d’options de configuration limite la quantité d’informations à échanger, et la négociation Diffie-Hellman s’effectue en un seul aller-retour (le schéma montre également une requête « GET » après la négociation).

TLS 1.3 améliore les performances en réduisant le nombre d’allers-retours nécessaires pour établir une connexion sécurisée

De plus, TLS 1.3 prend en charge la reprise de session, qui accélère l’établissement de la connexion en évitant de répéter la négociation TLS lorsqu’un client revient sur un site déjà visité. On parle également de reprise 0‑RTT (zéro aller-retour), car aucun message de négociation ne doit être échangé entre le client et le serveur pour reprendre la session. La reprise de session consiste à créer un secret partagé lors de la session initiale et à le stocker dans un ticket de session. Lorsque le client revient, il présente le ticket de session avec sa requête, laquelle est chiffrée à l’aide du secret partagé contenu dans le ticket.

TLS 1.3 permet la reprise rapide des sessions TLS

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

Une attaque par rejeu avec le 0-RTT

Pour se protéger contre les attaques par rejeu, 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). Leur rejeu n’a donc aucun effet. Le chargement d’une page est généralement la première opération effectuée par un client lorsqu’il revient sur un site, et la plupart des chargements de pages commencent par une requête GET. L’activation de la reprise de session accélère donc une grande partie des requêtes adressées à la plupart des sites web. Toutefois, il peut être préférable de ne pas activer la reprise 0‑RTT lors du déploiement de NGINX Plus en tant que passerelle d’API, car, pour le trafic d’API, les sessions TLS reprises sont plus susceptibles de contenir des types de requêtes non idempotentes.

TLS 1.3 offre également une protection contre les attaques par rejeu en incluant des informations temporelles dans le ticket de session et la requête du client, ce qui permet au serveur de déterminer si la requête lui est parvenue dans un délai raisonnable après son envoi par le client. Un attaquant ne peut pas modifier les informations temporelles. Par conséquent, si la requête a mis trop de temps à parvenir au serveur, 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, ajoutez 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 à l’heure où nous écrivons ces lignes (voir la section suivante). NGINX Plus utilise TLS 1.3 si le client le prend en charge et se rabat sinon sur TLS 1.2.

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

Cette configuration active les deux fonctionnalités :

server {    listen 443 ssl;
    ssl_certificate     /etc/ssl/my_site_cert.pem;
    ssl_certificate_key /etc/ssl/my_site_key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_early_data on; # Enable 0-RTT (TLS 1.3)

    location / {
        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. À l’heure où nous écrivons ces lignes, seuls Alpine Linux 3.9, FreeBSD 12.0 et Ubuntu 18.10 sont fournis avec OpenSSL 1.1.1.

Côté client, nous recommandons Chrome 70 ou Firefox 63. Ces navigateurs 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. À l’heure où nous écrivons ces lignes, les autres navigateurs populaires (notamment Firefox pour Android et Safari pour iOS et Mac) ne prennent pas encore en charge TLS 1.3. Pour connaître les dernières informations sur sa prise en charge, consultez Can I Use: TLS 1.3.

Limitation du débit en deux étapes

Auparavant, NGINX Plus pouvait appliquer des limites au débit des requêtes de deux manières : soit en rejetant immédiatement les requêtes excédentaires, soit en les plaçant dans une file d’attente jusqu’à ce qu’elles puissent être traitées conformément à la limite de débit définie. Avec NGINX Plus R17, vous pouvez combiner ces deux méthodes pour appliquer une limitation du débit en deux étapes : les requêtes excédentaires sont d’abord retardées, puis rejetées si la limite de débit est toujours dépassée.

Lors de l’application de limites de débit, il est essentiel de tenir compte du comportement habituel des clients légitimes. Par exemple, les navigateurs web tentent généralement de télécharger plusieurs ressources simultanément. Il est donc normal qu’une requête de contenu HTML soit rapidement suivie de requêtes de feuilles de style, de code JavaScript et d’images. C’est pourquoi il peut être judicieux d’autoriser une rafale de 10 à 20 requêtes rapprochées avant d’appliquer une limite de débit.

Avec NGINX Plus R17, vous pouvez désormais autoriser une rafale de requêtes afin de tenir compte du schéma de requêtes habituel des navigateurs web, puis retarder les requêtes excessives supplémentaires jusqu’à un certain seuil, au-delà duquel elles sont rejetées. La limitation du débit en deux étapes est activée grâce au nouveau paramètre « delay » de la directive « limit_req ».

Pour illustrer la limitation du débit en deux étapes, nous configurons ici NGINX Plus afin de protéger un site Web en imposant une limite de 5 requêtes par seconde (rate=5r/s). Le site Web comporte généralement 4 à 6 ressources par page, et jamais plus de 12. La configuration autorise des rafales allant jusqu’à 12 requêtes, dont les 8 premières sont traitées sans délai. Après 8 requêtes excédentaires, un délai est appliqué afin de faire respecter la limite de 5 requêtes par seconde. Au-delà de 12 requêtes excédentaires, toutes les requêtes supplémentaires sont rejetées.

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 « delay » définit le seuil à partir duquel, dans la limite de la rafale, les requêtes excédentaires sont ralenties (retardées) afin de respecter le débit maximal défini. Avec cette configuration, un client qui envoie un flux continu de requêtes à un débit de 8 requêtes/s observe le comportement suivant.

Illustration du comportement de limitation du débit avec rate=5r/s burst=12 delay=8

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

Notez que cette illustration est une description simplifiée du processus, car elle ne tient pas compte de l’incidence des requêtes terminées sur le calcul du nombre de requêtes excédentaires en cours de traitement. En réalité, chaque requête terminée libère une place dans la file d’attente, ce qui permet d’y insérer une autre requête excédentaire dans la limite de la taille de rafale configurée. Pour plus d’informations sur la mise en œuvre de la limitation du débit, consultez l’article « Limitation du débit avec NGINX et NGINX Plus » sur notre blog.

Configuration simplifiée d’OpenID Connect

Lors de la validation d’un JWT, NGINX Plus R17 peut désormais être configuré pour récupérer l’ensemble des clés Web JSON (JWK) depuis l’emplacement distant (généralement un fournisseur d’identité, ou IdP) indiqué 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 renouvelle fréquemment ses clés.

La plupart des fournisseurs d’identité proposent une URL fixe permettant d’obtenir le jeu de clés actuel, 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.

# Create a directory to cache the keys received from IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
    listen 80; # Use SSL/TLS in production

    location / {
        auth_jwt "closed site";
        auth_jwt_key_request /_jwks_uri; # Keys will be fetched by subrequest

        proxy_pass http://my_backend;
    }

    location = /_jwks_uri {
        internal;
        proxy_cache jwk; # Cache responses
        proxy_pass https://idp.example.com/oauth2/keys; # Obtain keys from here
    }
}

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 est indisponible.

Notre implémentation de référence d’OpenID Connect a été mise à jour afin de prendre en charge auth_jwt_key_request ainsi que la configuration automatique des fournisseurs d’identité prenant en charge la découverte OpenID Connect.

La prise en charge de JWT a également été étendue à deux variantes de l’algorithme de signature numérique sur courbes d’Edwards (EdDSA) : Ed448 et Ed25519. Notez qu’EdDSA nécessite OpenSSL 1.1.1 ou une version ultérieure, qui, à l’heure où nous écrivons ces lignes, n’est disponible que dans Ubuntu 18.10 et FreeBSD 12.0.

Remarque : la prise en charge d’OpenID Connect est réservée à NGINX Plus.

WAF NGINX ModSecurity 2 fois plus rapide

Le module NGINX ModSecurity WAF pour NGINX Plus est notre version prise en charge du pare-feu d’applications Web (WAF) open source ModSecurity, utilisé par plus d’un million de sites. Nous travaillons activement avec l’équipe TrustWave SpiderLabs afin d’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 précédentes.

Le WAF NGINX protège contre les attaques de couche 7

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

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

Remarque : NGINX ModSecurity WAF est exclusivement réservé à NGINX Plus.

Autres nouveautés de NGINX Plus R17

Connexions persistantes TCP vers les serveurs en amont

La nouvelle directive proxy_socket_keepalive détermine si les connexions persistantes TCP sont activées entre NGINX Plus et le serveur mandataire. Les connexions persistantes TCP améliorent les performances des protocoles (tels que WebSocket) lorsqu’un périphérique réseau TCP avec état se trouve entre NGINX et le serveur mandataire, et que les connexions sont de longue durée et souvent inactives. Sans connexions persistantes TCP, ces périphériques risquent de fermer plus fréquemment les connexions TCP inactives, ce qui entraîne le coût supplémentaire de leur rétablissement complet.

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

Délai d’expiration et nombre maximal de requêtes pour les connexions HTTP persistantes en amont

La nouvelle directive « keepalive_timeout » définit la durée maximale d’inactivité avant la fermeture d’une connexion HTTP persistante entre NGINX Plus et le serveur mandataire. En outre, la directive « keepalive_requests » définit le nombre maximal de requêtes pouvant être envoyées via une connexion persistante (après quoi celle-ci est fermée et une nouvelle connexion est créée).

Taille limitée des sessions UDP en amont

La nouvelle directive « proxy_requests » (module Stream) définit le nombre maximal de paquets UDP envoyés par NGINX Plus au serveur mandataire avant la création d’une nouvelle « session » UDP. Cela permet de répartir plus uniformément la charge des paquets UDP lorsqu’un même client en envoie un grand nombre sur une courte période (ce qui peut se produire, par exemple, en présence d’un proxy en aval).

Amélioration du partage de l’état du cluster

Lorsque vous utilisez le partage d’état dans un cluster, vous pouvez désormais vérifier le nom du serveur en utilisant SNI pour transmettre ce nom lors de la connexion aux nœuds du cluster. Cette fonctionnalité est mise en œuvre à l’aide des directives zone_sync_ssl_name et zone_sync_ssl_server_name.

Remarque : Le clustering et le module zone_sync sont réservés à NGINX Plus

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

Améliorations apportées à l’Ingress Controller

Le contrôleur Ingress NGINX officiel pour Kubernetes a été mis à jour vers la version 1.4.0. Le journal des modifications répertorie l’ensemble des changements, correctifs et améliorations, dont les plus notables sont présentés sur notre blog :

• Prise en charge étendue de Prometheus
• Équilibrage de charge TCP/UDP
• L’algorithme d’équilibrage de charge « Random with Two Choices » est désormais utilisé par défaut
• Annotations personnalisées

Pour en savoir plus sur le contrôleur Ingress NGINX officiel pour Kubernetes, consultez notre site web et le dépôt GitHub.

Améliorations du module JavaScript

NGINX Plus R17 comprend plusieurs améliorations qui étendent la prise en charge du langage JavaScript :

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

L’intégration au module NGINX Stream pour les applications TCP/UDP a été remaniée afin d’utiliser diverses fonctions de retour, notamment une méthode send() permettant de modifier le trafic entrant. Le trafic sortant est désormais accessible par l’intermédiaire d’une fonction de rappel.

La liste complète des modifications est disponible dans le journal des modifications du module JavaScript NGINX.

Mettez à niveau ou essayez NGINX Plus

NGINX Plus R17 prend en charge TLS 1.3, qui est plus sécurisé et plus performant que TLS 1.2. Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 17 et à TLS 1.3 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela permettra à NGINX, Inc. de mieux vous aider lorsque vous aurez besoin d’ouvrir 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 encore essayé NGINX Plus ou le WAF NGINX ModSecurity, nous vous invitons à les tester pour sécuriser vos applications, répartir la charge et mettre en place une passerelle API, ou encore pour les utiliser comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Commencez gratuitement dès aujourd’hui avec une évaluation gratuite de 30 jours. Découvrez par vous-même comment NGINX Plus peut vous aider à déployer vos applications et à les faire évoluer.

[Note de la rédaction – La commercialisation de NGINX ModSecurity WAF a officiellement pris fin le 1er avril 2022, et sa fin de vie prendra effet le 31 mars 2024. Pour en savoir plus, consultez l’article F5 NGINX ModSecurity WAF arrive en fin de vie<.htmla> sur notre blog.]

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly