Nginx est un serveur Web très sécurisé et fiable, même avec une configuration par défaut. Cependant, il existe de nombreuses façons de sécuriser davantage Nginx.
Dans cet article, nous allons utiliser des logiciels open source exclusivement en essayant de suivre certaines approches de renforcement du serveur Web et normes de sécurité populaires. En particulier, nous parlerons de la prévention de la divulgation d’informations, de l’imposition du chiffrement, de la réalisation d’audits et de la limitation des accès.
Conditions préalables
Avant de suivre ce didacticiel, assurez-vous de remplir les conditions préalables suivantes:
-
Ubuntu 14.04 Droplet (pour plus de détails, reportez-vous à la section (https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 de Configuration initiale du serveur avec Ubuntu 14.04)
-
Serveur Web Nginx installé et configuré comme expliqué dans Comment installer Nginx sur Ubuntu 14.04 LTS
-
Un domaine ou un sous-domaine enregistré pointait vers l’adresse IP de Droplet. Vous en aurez besoin pour tester les paramètres SSL. Pour plus d’informations, consultez cet article à l’adresse Comment pointer vers les serveurs de noms DigitalOcean à partir du domaine commun Registraires.
-
Utilisateur sudo non root (consultez Initial Initial Server Setup avec Ubuntu 14.04 pour plus de détails)
Sauf indication contraire, toutes les commandes nécessitant des privilèges root dans ce tutoriel doivent être exécutées en tant qu’utilisateur non root avec des privilèges sudo.
Étape 1 - Mise à jour de tous les logiciels
La mise à jour de votre logiciel vers la dernière version constitue une excellente première étape pour la sécurisation de l’ensemble du système, pas seulement de Nginx.
Avertissement: avant de mettre à jour tous les packages sur votre système, assurez-vous de déterminer si cela posera ou non des problèmes avec tout ce qui est exécuté sur votre système, à l’exception de Nginx. Il est judicieux d’effectuer une sauvegarde de l’intégralité du système avant d’effectuer une opération qui affecte autant de packages à la fois. Vous pouvez revenir à la sauvegarde si des problèmes surviennent après la mise à jour de tous les packages. Pour mettre à jour la liste des packages du référentiel, puis tous les packages actuellement installés et gérés avec + apt-get + sur votre serveur Ubuntu, exécutez les commandes suivantes:
sudo apt-get update && sudo apt-get upgradeAlternativement, vous pouvez simplement mettre à niveau Nginx vers la dernière version du référentiel Ubuntu. Ceci mettra à jour le paquet Nginx et toutes les dépendances nécessaires:
sudo apt-get upgrade nginxÉtape 2 - Prévention de la divulgation d’informations
Pour commencer à renforcer votre serveur Web Nginx, commençons par limiter les informations qu’il divulgue. Des informations précieuses sont divulguées à tous les niveaux, des en-têtes du serveur HTTP au rapport d’erreur d’application.
Commençons donc par les en-têtes HTTP. Par défaut, Nginx affiche son nom et sa version dans les en-têtes HTTP. Vous pouvez vérifier cette information avec + curl + comme ceci:
curl -I http://localhostLa sortie devrait ressembler à:
Output of curl -I http://localhostHTTP/1.1 200 OK
...Comme vous pouvez le constater, la version de Nginx et le nom du système d’exploitation apparaissent dans la sortie ci-dessus. Ce n’est pas nécessairement un problème grave, mais bien une partie du puzzle qu’un attaquant tentera de résoudre pour compromettre votre serveur Nginx. C’est pourquoi nous allons cacher ces informations en ouvrant le fichier de configuration principal de Nginx + / etc / nginx / nginx.conf + avec nano comme ceci:
sudo nano /etc/nginx/nginx.confEnsuite, dans la partie de configuration + http +, ajoutez la ligne + server_tokens off; + comme ceci:
/etc/nginx/nginx.conf
http {
##
# Basic Settings
##
...Après cela, enregistrez et quittez le fichier, puis rechargez Nginx pour que la modification soit prise en compte:
sudo service nginx reloadMaintenant, si vous essayez à nouveau la même commande curl:
curl -I http://localhostVous verrez moins d’informations:
Output of curl -I http://localhostHTTP/1.1 200 OK
...La sortie ci-dessus indique uniquement qu’il s’agit d’un serveur Nginx. Vous pouvez vous demander si vous pouvez également supprimer cela. Malheureusement, cela n’est pas facile à réaliser car il n’ya pas d’option de configuration pour cela. Au lieu de cela, vous devrez recompiler Nginx à partir de la source, ce qui ne vaut pas la peine.
Outre l’en-tête + Server, il existe un autre en-tête avec des informations sensibles -` + X-Powered-By`. Cet en-tête indique généralement la version de PHP, Tomcat ou tout moteur côté serveur derrière Nginx. Si vous utilisez Nginx avec PHP, le résultat de + curl + ressemblera à ceci:
Output of curl -I http://localhost on nginx with phpHTTP/1.1 200 OK
Server: nginx
...
...L’en-tête + X-Powered-By + ci-dessus montre que le serveur est Ubuntu 14 sous PHP version 5.5.9. Il est très important de cacher ces informations à l’en-tête + X-Powered-By. Vous ne pouvez pas faire cela dans Nginx, mais vous devriez plutôt trouver l’option correspondante dans le moteur de gestion. Par exemple, dans le cas de PHP, vous devez définir l’option + expose_php = Off + dans le fichier de configuration principal + php.ini +. Par défaut, cette option est définie sur + On +.
La prochaine étape consiste à modifier les pages d’erreur 4xx (côté client), dont les informations pourraient être utilisées par un attaquant. Généralement, ce sont les pages d’erreur + Unauthorized 401 + et + Forbidden 403 +. Sauf si vous corrigez un problème, il n’est généralement pas nécessaire de montrer ces erreurs aux visiteurs habituels. Si vous avez besoin de connaître ces erreurs, vous pourrez toujours les trouver dans le journal des erreurs Nginx (+ / var / log / nginx / error.log +).
Pour modifier ces deux pages d’erreur, ouvrez le fichier de configuration de votre bloc serveur, par exemple celui par défaut:
sudo nano /etc/nginx/sites-enabled/defaultDans la partie de configuration du serveur principal + serveur +, spécifiez:
/ etc / nginx / sites-enabled / default
server {
...
...Après avoir enregistré les modifications dans le fichier, veillez à recharger Nginx pour qu’il prenne effet avec la commande:
sudo service nginx reloadLes conseils ci-dessus vous donnent l’idée d’empêcher la divulgation d’informations - affichez le moins possible de contenu Web non essentiel. Vous devez masquer les informations de service et de débogage non seulement dans Nginx, mais également dans les moteurs de traitement (PHP, Tomcat, etc.) et, bien entendu, dans les applications Web.
Étape 2 - Configuration de SSL
L’exécution du protocole sécurisé HTTPS avec SSL sur Nginx est indispensable pour tout site traitant des informations sensibles telles que les informations d’identification des utilisateurs, les données privées, etc. SSL est le seul moyen de s’assurer que les informations qu’ils reçoivent et envoient sont protégées, quels que soient leur emplacement et leur connexion Internet.
L’article Comment créer un certificat SSL sur Nginx pour Ubuntu 14.04 explique comment configurer facilement un SSL gratuit avec la configuration HTTPS par défaut. Bien que cet article soit un bon début, il ne protégera pas efficacement vos données. De nos jours, les paramètres et les algorithmes SSL par défaut ne sont pas assez puissants pour empêcher un attaquant de déchiffrer votre trafic.
C’est pourquoi nous allons configurer un certificat SSL pour Nginx avec des algorithmes et des paramètres de cryptage plus puissants. Cela assurera un niveau de protection supérieur pour vos données et votre service HTTPS sera conforme aux normes et pratiques de sécurité les plus strictes.
Commençons par créer un répertoire pour nos certificats SSL avec la commande:
sudo mkdir /etc/nginx/ssl/Pour notre SSL, nous aurons besoin d’un certificat avec un algorithme de signature forte, SHA256. À des fins de test ou dans des environnements hors production, vous pouvez utiliser un certificat auto-signé et ignorer les avertissements SSL. Créons-en un avec la commande:
sudo openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crtCette commande vous posera quelques questions simples sur les détails de votre site et de votre entreprise. Après cela, il créera une clé cryptée RSA de 2048 bits dans le fichier + / etc / nginx / ssl / nginx.key + et un certificat SHA256 dans le fichier + / etc / nginx / ssl / nginx.crt +.
Ensuite, vous devrez générer des paramètres plus puissants, d’une longueur de 4096 bits, DH parameters. Préparez-vous à attendre un certain temps, en fonction de votre Droplet, cela peut prendre jusqu’à 30 minutes. Exécutez la commande:
sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096Vous pouvez maintenant configurer la partie SSL de votre bloc serveur. Par exemple, configurons le bloc serveur par défaut. Ouvrez son fichier de configuration pour le modifier avec nano:
sudo nano /etc/nginx/sites-enabled/defaultDans ce fichier, éditez la partie de configuration du serveur en ajoutant la partie SSL après la directive + nom_serveur + comme ceci:
/ etc / nginx / sites-enabled / default
server {
...
server_name localhost;
...Voici quelles instructions nous avons spécifiées avec les directives ci-dessus:
-
+ listen +- active l’écouteur SSL sur le port 443, c.-à-d. le port HTTPS. -
+ ssl_protocols +- active uniquement ces trois protocoles actuellement considérés comme sécurisés -+ TLSv1 TLSv1.1 TLSv1.2 +. -
+ ssl_ciphers +- active uniquement ces chiffrements SSL sécurisés:+ EECDH + AESGCM: EDH + AESGCM: AES256 + EECDH: AES256 + EDH + -
+ ssl_prefer_server_ciphers +- assurez-vous que le client respecte les préférences de chiffrement du serveur. -
+ ssl_dhparam +- utilise les paramètres DH personnalisés et puissants que nous avons générés précédemment. -
+ ssl_certificate +- utilise notre certificat SSL auto-signé. Assurez-vous de le changer si vous utilisez un autre certificat. -
+ ssl_certificate_key +- utilise notre clé privée SSL, que nous avons précédemment générée.
Pour que les paramètres ci-dessus prennent effet, vous devrez recharger à nouveau nginx avec la commande:
sudo service nginx reloadPour tester votre nouvelle configuration SSL, il est préférable d’utiliser un outil externe tel que celui fourni par SSL Labs. Là, vous devriez ignorer l’avertissement que le SSL n’est pas approuvé. Ceci est naturel car il s’agit d’un certificat auto-signé. Notez que ce site testera uniquement les sites avec un nom de domaine enregistré. Vous ne pouvez pas tester la connexion SSL uniquement avec l’adresse IP de votre Droplet.
Le résultat global devrait être «T» comme pour «Test», mais il s’agit essentiellement d’un A (le plus élevé possible) et il devrait indiquer " Si les problèmes de confiance sont ignorés: A " comme ceci:
image: https: //assets.digitalocean.com/articles/nginx_security_1404/ssltest.png [Vérification SSL]
Plus tard, vous voudrez probablement supprimer l’avertissement SSL et faire en sorte que le test SSL soit un «A» propre. Une option consiste à utiliser * Let’s Encrypt * comme décrit dans l’article https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14- 04 [Comment sécuriser Nginx avec Let’s Encrypt sur Ubuntu 14.04]. Il est gratuit, vous permet de spécifier une taille de clé RSA allant jusqu’à 4096 et ne vous avertit pas de l’auto-signature. Sinon, vous pouvez choisir l’un des fournisseurs de SSL commerciaux. Lorsque vous en choisissez un, assurez-vous d’opter pour un certificat SHA256.
Étape 3 - Restreindre l’accès par IP
L’authentification par mot de passe n’est pas toujours suffisante pour assurer la sécurité des zones sensibles de votre site, telles que les panneaux de contrôle, le phpmyadmin, etc. Parfois, des attaquants exploitent des mots de passe faibles ou des vulnérabilités logicielles dans de telles zones pour obtenir un accès non autorisé. C’est pourquoi il est vivement recommandé d’ajouter des restrictions supplémentaires d’IP, à condition que vous puissiez déterminer les adresses IP d’utilisateurs légitimes.
Par exemple, si vous avez un site WordPress et que sa zone d’administration se trouve à «+ / wp-admin / », vous devez en limiter l’accès uniquement à votre adresse IP ou aux adresses IP de tous les administrateurs. Pour cela, ouvrez le bloc de serveur correspondant - le bloc de serveur par défaut pour Nginx est ` / etc / nginx / sites-enabled / default +`:
sudo nano /etc/nginx/sites-enabled/defaultDans la partie de configuration + server +, ajoutez:
/ etc / nginx / sites-enabled / default
server {
...
location /wp-admin/ {
allow /24;
allow /24;
deny all;
}
...
...Dans ce qui précède, veillez à remplacer + 192.168.1.1 + et + 10.0.0.1 + par vos adresses IP. De même, vous pouvez autoriser l’accès à d’autres adresses IP ou même à des réseaux en modifiant le masque de réseau (+ / 24 +).
Pour que ces paramètres prennent effet, vous devrez recharger à nouveau Nginx avec la commande:
sudo service nginx reloadMaintenant, si vous essayez d’accéder à la partie + / wp-admin / + de votre site avec un navigateur en dehors des plages d’adresses IP autorisées, vous obtiendrez une erreur. Cette erreur sera 403 interdite (à moins que vous n’ayez modifié cette erreur en 404 non trouvée comme expliqué précédemment). En même temps, vous verrez le vrai code d’erreur dans le journal des erreurs avec la commande:
sudo tail /var/log/nginx/error.logL’erreur + accès interdit + apparaîtra comme ceci:
Output of sudo tail -f /var/log/nginx/error.log...
2016/01/02 04:16:12 [error] 4767#0: *13 by rule, client: X.X.X.X, server: localhost, request: "GET /wp-admin/ HTTP/1.1", host: "Y.Y.Y.Y"
...L’application de plusieurs approches de la sécurité, telles que la modification de la page d’erreur et la restriction de l’accès par IP, montre l’effet cumulatif du renforcement de Nginx. Selon l’exemple, au lieu de la page d’administration WordPress habituelle, les attaquants et les outils automatisés qu’ils utilisent verront une page 404 non trouvée. Ceci est déroutant et peut les décourager d’essayer d’autres approches pour compromettre votre WordPress.
[[step-4-- performing-a-security-audit]] === Étape 4 - Réalisation d’un audit de sécurité
C’est toujours une bonne idée d’avoir un contrôle de sécurité indépendant de votre propre opinion. À cette fin, vous pouvez utiliser un outil d’audit de sécurité qui recherche les vulnérabilités Web. Il existe de nombreux outils de ce type, y compris des outils commerciaux, et pour commencer, vous pouvez utiliser wapiti, qui est gratuit et à code source ouvert. Il se peut que certaines fonctionnalités des outils plus avancés ne soient pas disponibles dans Wapiti, mais cela vous donnera une idée de ce qu’est l’audit de sécurité.
Vous pouvez installer wapiti sur Ubuntu via apt:
sudo apt-get install wapitiPuis commencez à scanner votre site avec wapiti avec la commande:
wapiti http:// -n 10 -b folderAssurez-vous de remplacer + example.org + par le nom de votre site. Nous avons donné deux arguments supplémentaires à la commande. Le premier + -n 10 + limite le nombre d’URL ayant le même modèle à 10 afin d’éviter les boucles sans fin. Le deuxième argument + -b folder + définit la portée de l’analyse uniquement sur le domaine donné.
Une fois l’analyse terminée, vous aurez les résultats dans un répertoire appelé + Rapport_Grandonné + dans le répertoire à partir duquel vous avez exécuté l’analyse. Pour une meilleure visualisation, téléchargez ce répertoire sur votre ordinateur local et ouvrez le fichier + index.html avec un navigateur Web.
Dans le rapport, vous verrez les vulnérabilités classées en 10 catégories différentes: Injection SQL, Injection SQL aveugle, Gestion de fichiers, Sondage intersite, CRLF, Exécution de commandes, Consommation de ressources, Contournement de Htaccess, Fichier de sauvegarde et Fichier potentiellement dangereux.
Idéalement, votre rapport devrait ressembler à ceci sans qu’aucune vulnérabilité ne soit détectée:
image: https: //assets.digitalocean.com/articles/nginx_security_1404/wapiti_report.png [Rapport Wapiti]
S’il existe des vulnérabilités, vous pouvez développer la partie correspondante de l’analyse pour plus d’informations.
Assurez-vous d’exécuter ces analyses fréquemment et avec différents outils pour assurer un audit le plus complet et approfondi de votre site Web et de Nginx.
[[step-5-- taking-additional-security-measures]] === Étape 5 - Prendre des mesures de sécurité supplémentaires
Certains sujets concernant la sécurité de Nginx ne sont pas abordés dans cet article car il existe déjà un excellent article à ce sujet. Veuillez vous familiariser avec les suivants:
Naxsi est un pare-feu d’application Web pour Nginx. Il vous protège des vulnérabilités Web connues et inconnues en utilisant une compilation de signatures malveillantes.
Vous devez savoir que Naxsi est un logiciel complexe et que sa mise au point prend du temps et des efforts. Heureusement, il existe des configurations disponibles pour la plupart des applications Web les plus courantes que vous pouvez personnaliser davantage si nécessaire.
Fail2ban est un excellent outil pour faire passer la sécurité Web à un niveau supérieur et protéger de manière proactive votre serveur nginx. Jusqu’à présent, nous avons empêché les utilisateurs de trouver certaines informations et d’accéder à des parties de notre site. Avec fail2ban, vous pouvez bloquer davantage les attaquants pendant certaines périodes au cours desquelles ils détectent une activité malveillante.
La surveillance est essentielle à la sécurité, et Monit est un excellent outil à cet effet avec un support efficace pour Nginx. Les journaux Web affichent non seulement des traces d’activités malveillantes, mais également des pics de charge du processeur et d’utilisation de la mémoire.
Dans cet article, portez une attention particulière à l’étape 5 - Surveiller les journaux pour détecter les erreurs et les mots-clés. Là, vous pouvez configurer l’envoi d’alertes personnalisées lors d’événements de sécurité, par exemple lorsqu’un utilisateur accède ou tente d’accéder à des parties sensibles de votre / vos site (s).
Avoir un pare-feu est très important pour la sécurité de votre nginx et de votre droplet dans son ensemble. Assurez-vous que vous ajoutez le port https (tcp 443) aux connexions entrantes autorisées en plus du port standard http (tcp 80).
Un vérificateur d’intégrité des fichiers et des répertoires, tel que AIDE, alerte en cas de modification des fichiers et des répertoires. Ceci est particulièrement utile pour les fichiers Web car vous devez être conscient du fait que des parties de votre site changent et que de nouveaux fichiers / répertoires sont ajoutés. Pour en savoir plus sur AIDE, vous pouvez commencer avec l’article.
L’article ci-dessus est un peu dépassé et n’est pas spécifiquement écrit pour Ubuntu. Cependant, vous devriez pouvoir facilement l’adapter et l’appliquer également pour Ubuntu 14.04. Lorsque vous configurez AIDE, ou un autre outil similaire, veillez à exclure de la surveillance les journaux Web et les fichiers temporaires tels que le cache Web.
Conclusion
Après avoir lu cet article, vous devriez avoir davantage confiance en la sécurité de Nginx. Assurez-vous simplement de rechercher un équilibre entre fonctionnalité et sécurité afin de vous assurer que votre environnement Web fonctionne comme prévu, mais qu’il est sécurisé. N’oubliez pas non plus que la sécurisation de Nginx est une tâche continue qui nécessite des mises à jour, des reconfigurations, des analyses, etc. régulières.