Cet article de blog décrit plusieurs méthodes permettant de distribuer en toute sécurité les clés privées SSL utilisées par NGINX lors de l’hébergement de sites Web cryptés SSL. Il explique :
Pour de nombreux déploiements, l’approche standard est suffisante. Les deux approches les plus sophistiquées décrites dans cet article bloquent d’autres moyens par lesquels un attaquant peut obtenir des clés privées SSL. Nous examinerons également quelques autres techniques dans les prochains articles :
Les approches présentées dans cet article s’appliquent aux utilisateurs qui doivent gérer leurs propres clés et créer leur propre stratégie de distribution de clés sécurisée. Ils ne sont pas nécessaires pour les utilisateurs qui exécutent NGINX dans des environnements déjà intégrés à un magasin de secrets, tel que Kubernetes .
Cet article s'applique à la fois à NGINX Open Source et à NGINX Plus. Pour faciliter la lecture, nous ferons référence à NGINX tout au long du document.
Éditeur – Cet article est le premier d'une série sur la sécurisation des clés privées SSL dans NGINX. Voir également les autres articles de la série :
SSL/TLS est utilisé pour authentifier, crypter et vérifier l'intégrité des transactions réseau. Les sites Web s'authentifient à l'aide d'un certificat public signé par une autorité de certification (CA) et démontrent qu'ils sont propriétaires du certificat en effectuant des calculs à l'aide de la clé privée correspondante (qui doit être gardée secrète).
Si la clé privée est compromise (divulguée à une autre entité), il existe deux risques principaux.
Si la clé privée est compromise, votre seul recours est de contacter l'autorité de certification et de demander la révocation de votre certificat ; vous devez alors compter sur les clients pour vérifier et respecter le statut de révocation.
De plus, il est recommandé d'utiliser des certificats avec des délais d'expiration courts (par exemple, les certificats Let's Encrypt expirent après 90 jours). Peu de temps avant l’expiration d’un certificat, vous devez générer une nouvelle clé privée et obtenir un nouveau certificat auprès de l’autorité de certification. Cela réduit votre exposition dans le cas où la clé privée est compromise.
Quelles personnes et processus peuvent accéder aux clés privées SSL dans NGINX ?
Tout d’abord, tout utilisateur qui obtient un accès root
au serveur exécutant NGINX est capable de lire et d’utiliser toutes les ressources que NGINX lui-même utilise. Par exemple, il existe des méthodes connues pour extraire la clé privée SSL de la mémoire d'un processus en cours d'exécution.
Par conséquent, quelle que soit la manière dont la clé privée est stockée et distribuée, il n'est pas possible de protéger la clé privée d'un attaquant disposant de privilèges root
sur le serveur hôte.
Ensuite, tout utilisateur pouvant modifier et valider la configuration NGINX peut utiliser ce pouvoir de plusieurs manières : pour ouvrir l’accès proxy aux services internes, pour contourner les mesures d’authentification, etc. Il ou elle peut modifier la configuration NGINX pour obtenir un accès root
(ou équivalent) au serveur, bien que des outils comme SELinux et AppArmor aident à atténuer cette possibilité.
Par conséquent, il n’est généralement pas possible de protéger la clé privée d’un attaquant qui peut modifier et valider la configuration NGINX.
Heureusement, toute organisation compétente dispose de processus de sécurité solides pour empêcher un attaquant d’obtenir des privilèges root
ou de modifier la configuration NGINX.
Cependant, il existe deux autres manières par lesquelles un attaquant moins privilégié pourrait obtenir l'accès à la clé privée :
Les processus décrits dans ce document scellent ces deux méthodes d’attaque.
Nous commençons par examiner à quoi ressemble une configuration NGINX typique avec SSL/TLS :
serveur { écouter 443 ssl; nom_serveur a.dev0; certificat_ssl ssl/a.dev0.crt; clé_certificat_ssl ssl/a.dev0.key; emplacement / { retourner 200 "Bonjour du service A\n"; } }
Le certificat public SSL ( a.dev0.crt ) et la clé privée ( a.dev0.key ) sont stockés dans le système de fichiers, dans /etc/nginx/ssl/ . La clé privée n'est lue que par le processus maître NGINX, qui s'exécute généralement en tant que root
, vous pouvez donc définir les autorisations d'accès les plus strictes possibles :
root@web1:/etc/nginx/ssl# ls -l a.dev0.key -r-------- 1 root root 1766 15 août 16:32 a.dev0.key
La clé privée doit être disponible à tout moment ; le processus maître NGINX la lit à chaque démarrage du logiciel NGINX, lorsque la configuration est rechargée ou lorsqu'une vérification de syntaxe est effectuée ( nginx
-t
).
Pour plus d'informations sur la configuration de SSL/TLS, consultez le Guide d'administration NGINX Plus .
Comme indiqué ci-dessus, la clé privée SSL peut être lue par un attaquant qui obtient un accès root
au conteneur, à la machine virtuelle ou au serveur qui exécute le logiciel NGINX.
NGINX prend en charge les clés privées cryptées, à l'aide d'algorithmes sécurisés tels que AES256 :
root@web1:/etc/nginx/ssl# mv a.dev0.key a.dev0.key.plain root@web1:/etc/nginx/ssl# openssl rsa -aes256 -in a.dev0.key.plain -out a.dev0.key écriture de la clé RSA Entrez la phrase de passe PEM : secure password Vérification - Entrez à nouveau la phrase de passe PEM : secure password
Lorsque vous démarrez NGINX, ou rechargez ou testez la configuration NGINX, NGINX demande le mot de passe de déchiffrement de manière interactive :
root@web1:/etc/nginx# nginx -t Entrez la phrase de passe PEM : mot de passe sécurisé nginx : la syntaxe du fichier de configuration /etc/nginx/nginx.conf est correcte nginx : le test du fichier de configuration /etc/nginx/nginx.conf est réussi
La saisie interactive de mots de passe est peu pratique et difficile à automatiser, mais vous pouvez configurer NGINX pour utiliser une liste de mots de passe stockés dans un fichier séparé nommé par la directive ssl_password_file
. Lorsque NGINX doit lire une clé privée, il tente de déchiffrer la clé en utilisant tour à tour chacun des mots de passe du fichier. Si aucun des mots de passe n'est valide, NGINX refuse de démarrer.
fichier_mot_de_passe_ssl /var/lib/nginx/ssl_passwords.txt ;
Le fichier ssl_password_file
doit être distribué séparément de la configuration et être lisible uniquement par l'utilisateur root
. Vous pouvez le considérer comme un jeton d’autorisation placé sur des serveurs de confiance. NGINX ne peut décrypter les clés privées que lorsqu'il s'exécute sur un serveur avec le jeton d'autorisation.
Cette méthode réduit la surface d’attaque en rendant la configuration NGINX seule inutile pour un attaquant. L'attaquant doit également obtenir le contenu du fichier ssl_password_file
.
Si un attaquant parvient à accéder à la racine
du système de fichiers où le fichier ssl_password_file
est stocké (par exemple, à partir d'une sauvegarde ou via le système hôte), il peut lire le fichier et utiliser les mots de passe pour décrypter les clés privées SSL.
Vous pouvez réduire ce risque en stockant le fichier ssl_password_file
sur un disque RAM ou tmpfs . Ce stockage est généralement moins accessible à un attaquant externe (par exemple, il est effacé lorsque le serveur est redémarré) et peut être exclu des sauvegardes système. Vous devez vous assurer que le fichier de mot de passe est initialisé au démarrage du système.
Le processus ci-dessous décrit une manière plus sécurisée de distribuer des listes de mots de passe SSL, à partir d'un point de distribution central.
Chaque fois que NGINX doit décrypter une clé SSL, il interroge le point de distribution central et utilise les mots de passe sans jamais les stocker sur le disque local. Pour s'authentifier auprès du serveur de mots de passe central, l'instance NGINX utilise un jeton que vous pouvez révoquer à tout moment pour couper l'accès aux mots de passe.
Commencez par créer un point de distribution de mot de passe (PDP). Pour cette implémentation simple, nous utilisons un service HTTPS pour fournir la liste des mots de passe, authentifiés par nom d'utilisateur et mot de passe :
$ curl -u dev0:monmot de passe https://pdpserver.local/ssl_passwords.txt mot de passe1 mot de passe2 ...
Vous pouvez ensuite activer ou révoquer l’accès en ajoutant ou en supprimant des jetons d’authentification au niveau du PDP selon vos besoins. Vous pouvez implémenter le serveur de distribution de mots de passe à l'aide d'un serveur Web tel que NGINX et utiliser le type de jetons d'authentification approprié.
Ensuite, nous devons configurer NGINX pour récupérer les mots de passe du PDP. Nous commençons par créer un script shell appelé connector.sh avec le contenu suivant :
#!/bin/sh
# Utilisation : connector.sh
CONNECTEUR=$1
CREDS=$2
PDP_URL=$3
[ -e $CONNECTEUR ] && /bin/rm -f $CONNECTEUR
mkfifo $CONNECTEUR ; chmod 600 $CONNECTEUR
tant que vrai ; faire
curl -s -u $CREDS -k $PDP_URL -o $CONNECTEUR
terminé
Le script doit s'exécuter en tant que processus d'arrière-plan, appelé comme suit :
root@web1:~# ./connector.sh /var/run/nginx/ssl_passwords \dev0:monmot de passe https://pdpserver.local/ssl_passwords.txt &
Le connecteur se connecte au chemin local spécifié ( /var/run/nginx/ssl_passwords ) et vous utilisez la directive ssl_password_file
pour configurer NGINX afin d'accéder à ce chemin :
fichier_mot_de_passe_ssl /var/run/nginx/ssl_passwords;
Testez le connecteur en lisant le chemin du connecteur :
root@web1:~# cat /var/run/nginx/ssl_passwords mot de passe1 mot de passe2 ...
Vérifiez que NGINX peut lire le mot de passe et décrypter les clés SSL :
root@web1:~# nginx -t nginx : la syntaxe du fichier de configuration /etc/nginx/nginx.conf est correcte nginx : le test du fichier de configuration /etc/nginx/nginx.conf est réussi
Vous pouvez utiliser l’approche PDP centrale pour distribuer en toute sécurité toute ressource que NGINX lit normalement à partir du disque, par exemple des clés privées individuelles ou d’autres données sensibles.
Cette solution présente plusieurs avantages par rapport au stockage des mots de passe SSL sur disque :
Notez qu'un utilisateur ayant accès au système de fichiers peut potentiellement extraire les informations d'identification utilisées pour accéder au PDP. Il est important de révoquer ces informations d’identification lorsqu’elles ne sont plus nécessaires.
Il existe de nombreuses façons de protéger les clés privées SSL contre la divulgation, avec des niveaux de sécurité et de complexité croissants :
root
et ne puissent pas consulter la configuration NGINX.Les autres articles de cette série décrivent les étapes supplémentaires que vous pouvez suivre pour sécuriser les clés SSL :
Essayez NGINX Plus par vous-même – démarrez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation .
« 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."