Dans ce tutoriel, nous allons voir comment configurer l'authentification HTTP basique sur un serveur Web Nginx pour protéger l'accès à un site par mot de passe. Cet accès peut s'appliquer seulement à une page ou à un dossier spécifiques, ce qui me semble intéressant pour protéger l'accès à une interface d'administration d'un site, tout en laissant la partie publique accessible sans mot de passe.
Si vous avez besoin de mettre en place le serveur Nginx, suivez ce tutoriel : Installer Nginx
II. Protection par mot de passe avec Nginx
Pour ajouter cette authentification, nous allons reprendre la méthode du fichier ".htpasswd". Cela nécessite d'installer le paquet apache2-utils, bien que l'on soit avec un serveur Nginx. Cela n'installe pas Apache en lui-même, seulement quelques outils dont htpasswd.
Mettez à jour le cache des paquets et installez apache2-utils :
Une fois que c'est fait, nous allons créer un fichier qui va contenir un identifiant et un mot de passe. Ce fichier sera stocké dans "/etc/nginx/", se nomme ".htpasswd" et l'on va ajouter l'utilisateur "florian". Ce qui donne :
sudo htpasswd -c /etc/nginx/.htpasswd florian
Il faudra indiquer, deux fois, le mot de passe de l'utilisateur (ce compte n'a aucun lien avec le compte local de Linux).
Remarque : pour des raisons de sécurité, il est important que le fichier .htpasswd ne soit pas créé au sein du répertoire du site Internet directement. De cette façon, il n'est pas accessible aux clients qui visitent votre site Web, mais le serveur Nginx peut y accéder.
On peut considérer que le fichier .htpasswd est une "petite base de données" de comptes utilisateurs dans un fichier à plat. Si l'on regarde le contenu du fichier, on peut voir que le mot de passe n'est pas en clair.
sudo cat /etc/nginx/.htpasswd
Si l'on se réfère à la documentation, on sait que l'on utilise l'algorithme MD5 pour calculer le hash du mot de passe, car la chaîne commence par "$apr1$". Voici ce qui est précisé dans la documentation : " "$apr1$" + le résultat d'un algorithme spécifique à Apache utilisant un condensé MD5 réitéré (1000 fois) de combinaisons variées du mot de passe et d'une source d'entropie sur 32 bits."
Pour créer des comptes supplémentaires et les ajouter au même fichier sans l'écraser, voici la syntaxe à utiliser (exemple pour créer le compte itconnect) :
sudo htpasswd /etc/nginx/.htpasswd itconnect
Maintenant, nous allons configurer notre site sous Nginx pour qu'il prenne en charge l'authentification et notre fichier .htpasswd.
Commençons par ouvrir le fichier de configuration du site :
L'option "auth_basic" sert à définir le message qui s'affichera au sein de la fenêtre d'authentification, tandis que l'option "auth_basic_user_file" sert à spécifier le chemin vers le fichier .htpasswd.
Pour appliquer l'authentification sur toutes les pages du site, on doit utiliser un bloc "location / { }" pour matcher avec toutes les URL de notre site. Ce qui donne :
Une fois le fichier édité, il suffit de sauvegarder les modifications et de redémarrer Nginx :
sudo systemctl restart nginx
Dernière étape : tester que notre configuration bien. On se rend tout simplement sur notre site, et là une fenêtre d'authentification apparaît ! On doit se connecter avec un compte présent dans le fichier .htpasswd pour accéder au site, sinon on obtiendra une erreur : 401 Authorization Required.
Enfin, si l'on veut que cette restriction s'applique seulement sur l'interface d'administration du site, il faut adapter la directive "location". Si l'interface d'administration est accessible en indiquant "/admin/" dans l'URL, par exemple "https://www.it-connect.tech/admin/", il faut ajouter ce bloc dans le fichier :
Dans ce tutoriel, nous allons voir comment configurer Nginx pour cacher le numéro de version dans le header HTTP ou sur les pages d'erreurs générées par le serveur Web.
Lorsque l'on configure un serveur Web, que ce soit avec Nginx ou Apache, l'applicatif se montre un peu trop bavard dans sa configuration par défaut. Si l'on regarde les en-têtes HTTP (Header HTTP) ou que l'on génère une page d'erreur, on peut facilement obtenir le numéro de version du serveur Nginx. Une information importante si l'on se place dans la peau d'un attaquant : le numéro de version peut permettre de savoir si le serveur est à jour ou non, et s'il n'est pas à jour, cela permet de rechercher d'éventuelles failles de sécurité associée à la version installée.
Le numéro de version est récupérable avec une simple requête CURL ou en générant une erreur sur le site Web avec un navigateur. Par exemple :
Je pars du principe que votre serveur Nginx est déjà en place. Si besoin, référez-vous à ce tutoriel : Installation de Nginx
II. Nginx et la directive server_tokens
Tout va se jouer dans le fichier de configuration de Nginx, que je vous propose de modifier avec votre éditeur de texte préféré. Pour ma part, ce sera avec nano, ce qui donne :
sudo nano /etc/nginx/nginx.conf
Pour ne plus afficher la version de Nginx, il faut ajouter la directive server_tokens au sein du bloc "http{ }". Cette directive devra avoir la valeur "off". En fait, soit vous l'ajoutez vous-même, soit vous décommentez la ligne existante et prête à l'emploi (en retirant le caractère "#") :
server_tokens off;
En image, cela donne :
Pour afficher de nouveau le numéro de version, il suffit de commenter la ligne ou d'indiquer "on" comme valeur. Une fois que la modification est effectuée : sauvegardez et fermez le fichier.
Redémarrez le service Nginx :
sudo systemctl restart nginx
Ensuite, rendez-vous dans votre navigateur et accédez à une page qui génère une erreur. Et là, vous verrez que c'est simplement précisé "nginx" mais que le numéro de version n'est plus spécifique : c'est top !
Grâce à cette modification, on peut savoir que le serveur est sous Nginx mais on ne connaît pas le numéro de version.
Dans ce tutoriel, nous allons voir comment configurer son site en HTTPS avec un certificat SSL gratuit Let's Encrypt en utilisant un serveur Web Nginx.
Mettre en place un site Internet sur un serveur Web et le rendre accessible en HTTP, c'est bien, mais c'est insuffisant : pour un site en production, il est fortement recommandé d'utiliser un certificat SSL et le protocole HTTPS pour sécuriser les connexions. D'autant plus qu'avec Let's Encrypt, on peut obtenir un certificat gratuitement en quelques minutes.
Je pars du principe que votre serveur Nginx est déjà en place avec un site accessible en HTTP. Pour ma part, il s'agit du site www.it-connect.tech et je vais reprendre comme point de départ, la configuration du précédent tutoriel sur l'installation de Nginx.
II. Installation de Certbot pour Nginx
Commençons par mettre à jour le cache des paquets et à installer les deux paquets (et leurs dépendances) nécessaires à l'utilisation de Certbot sous Debian, avec un serveur Web Nginx. Pour rappel, Certbot est un outil qui sert à effectuer des demandes de certificat Let's Encrypt.
III. Let's Encrypt : demander un certificat SSL pour Nginx
Certbot étant installé sur notre machine, nous allons effectuer une demande de certificat. Pour cela, on va spécifier que l'on utilise un serveur Web sous Nginx (--nginx) et on précise aussi le nom du domaine (-d www.it-connect.tech). Voici la commande complète :
sudo certbot --nginx -d www.it-connect.tech
Le processus est relativement rapide, je vous invite à saisir votre adresse e-mail lorsque ce sera demandé (Enter email address) : un e-mail sera envoyé à cette adresse dans le cas où le certificat ne parvient pas à se renouveler automatiquement et qu'il arrive à expiration. C'est toujours bon à prendre comme information...!
Certbot - Générer un certificat SSL via Let's Encrypt pour Nginx
Il vous sera demandé si vous souhaitez rediriger automatiquement le trafic HTTP vers HTTPS : ce qui me semble une bonne idée. Dans ce cas, indiquez "2" et appuyez sur entrée. On peut voir également les chemins vers le certificat et la clé privée associée.
Si tout se passe bien, vous avez le droit à un joli "Congratulations !". Dans ce cas, le certificat est déjà installé sur votre site Web car Certbot s'est occupé de configurer le bloc Server correspondant. La classe, n'est-ce pas ?
Allons-voir quelles sont les modifications apportées par Certbot dans le fichier de configuration de notre site...
sudo cat /etc/nginx/sites-enabled/it-connect.tech
Voici le contenu du fichier avec les modifications principales en jaune :
Intégration du certificat Let's Encrypt dans la configuration de Nginx
Concrètement, Certbot a déclaré le port 443 comme port d'écoute, ce qui correspond au HTTPS, à la fois pour toutes les adresses IPv4 du serveur, mais aussi toutes les adresses IPv6.
listen [::]::443 ssl ipv6only=on;
listen 443 ssl;
Il a également ajouté les chemins vers le certificat SSL (ssl_certificate) et la clé privée (ssl_certificate_key) obtenus suite à la génération du certificat Let's Encrypt.
ssl_certificate /etc/letsencrypt/live/www.it-connect.tech/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.it-connect.tech/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
Le fichier de configuration options-ssl-nginx.conf (include...) est chargé également et il contient les paramètres SSL/TLS, notamment les protocoles actifs.
Comme nous avons demandé à rediriger les flux HTTP vers HTTP, le fichier de configuration contient une règle de redirection au niveau du groupe Server pour la partie HTTP (listen 80). En gros, si l'on accède à l'adresse www.it-connect.tech ($host = www.it-connect.tech), il y a une redirection de type 301 (c'est-à-dire permanente) qui est déclenchée vers la même adresse, mais en HTTPS://.
if ($host = www.it-connect.tech) {
return 301 https://$host$request_uri;
} # managed by Certbot
Note : ces différentes options seraient à intégrer dans le fichier manuellement dans le cas où l'on utilise un autre certificat que Let's Encrypt, où il faut réaliser l'intégration soi-même.
Maintenant que l'on en sait un peu plus sur les modifications apportées par Certbot, il est temps de tester : est-ce que l'accès HTTPS sur notre site fonctionne bien ?
IV. Vérifier le certificat SSL
Rendez-vous sur le site ! Non pas en HTTPS directement, mais en HTTP, ce sera l'occasion de vérifier que la redirection HTTP vers HTTPS fonctionne bien, tant qu'à faire !
Ensuite, un beau cadenas devrait s'afficher pour nous indiquer que la connexion est sécurisée. Si l'on regarde le détail du certificat, on peut voir qu'il est émis par Let's Encrypt. C'est tout bon !
V. HTTPS : renouvellement automatique du certificat SSL
Je ne l'ai pas encore précisé, mais un certificat Let's Encrypt a une durée de validité assez courte : 90 jours. Néanmoins, il ne faudra pas le renouveler manuellement tous les 90 jours puisque Certbot va s'en occuper, tout seul comme un grand. Il a déjà fait le nécessaire sur notre machine en créant une tâche planifiée (cron).
Il suffit de regarder le contenu du fichier suivant pour se rassurer :
sudo nano /etc/cron.d/certbot
La tâche planifiée va s'exécuter de façon à renouveler le certificat avant qu'il expire.
Tâche planifiée pour renouveler le certificat SSL
Si vous souhaitez réaliser un essai, vous pouvez exécuter un "--dry-run" pour faire une simulation de renouvellement. Tout simplement, voici la commande à exécuter :
sudo certbot renew --dry-run
Vous devriez obtenir une sortie similaire à celle-ci :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/www.it-connect.tech/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Le message "Congratulations, all renewals succeeded." est rassurant puisqu'il indique que le certificat aurait été renouvelé correctement si cela avait été nécessaire. Maintenant, la tâche planifiée va s'occuper de gérer cette opération à notre place. En cas de soucis, souvenez-vous qu'un e-mail sera envoyé sur l'adresse précisée lors de la création du certificat.
Voilà, votre site Web sous Nginx bénéficie d'un certificat SSL Let's Encrypt et il est accessible en HTTPS.
Dans ce tutoriel, nous allons voir comment mettre en place un serveur Web Nginx sur Debian 10, dans le but d'héberger un site Web qui s'appuie sur PHP.
Nginx, que l'on prononce Engine-X, est un logiciel open source qui permet de monter un serveur web, mais également un reverse proxy pour mettre en cache des éléments et assurer la répartition de charge entre plusieurs serveurs Web.
À la différence d'Apache, Nginx est pensé pour les sites à très fort trafic : il est d'ailleurs connu et reconnu pour être un logiciel très performant. Dans de nombreux cas, il n'est pas utilisé en tant que serveur Web directement, mais plutôt en tant que reverse proxy pour gérer les connexions des clients en frontal.
Pour ma part, je vais utiliser une machine sous Debian 10 pour mettre en place le serveur Nginx.
Débutez avec Nginx grâce à ce tutoriel vidéo (installation, création d'un site, intégration de PHP, mise en place d'un certificat SSL, etc.).
II. Installer Nginx
Commençons par installer le paquet Nginx, mais avant cela mettons à jour le cache de paquets sur notre machine :
sudo apt update -y
Ensuite, on passe à l'installation du paquet Nginx, ce qui est très simple puisqu'il est disponible dans les dépôts officiels.
sudo apt install nginx -y
Lorsque l'installation est effectuée, on peut regarder quelle version est installée à l'aide de la commande suivante (similaire à celle d'Apache ou d'autres paquets) :
sudo nginx -v
Suite à l'installation, le serveur Nginx est déjà démarré, on peut le vérifier avec la commande ci-dessous. Cela permettra de voir qu'il est bien actif.
sudo systemctl status nginx
Pour que notre serveur Web Nginx démarre automatiquement lorsque la machine Linux démarre ou redémarre, on doit exécuter la commande suivante :
sudo systemctl enable nginx
Dès à présent, on peut accéder à la page par défaut du serveur Web à partir d'un navigateur. Si votre machine où est installé Nginx dispose d'une interface graphique, on peut y accéder en local :
http://127.0.0.1
À partir d'une machine distante, utilisez l'adresse IP de votre serveur Web plutôt que l'adresse de loopback (127.0.0.1). Voici la page qui doit s'afficher :
Le contenu de cette page Web correspond au fichier suivant :
/var/www/html/index.nginx-debian.html
En fait, le site par défaut de Nginx est déclaré dans le fichier de configuration suivant :
/etc/nginx/sites-enabled/default
La racine de ce site est :
/var/www/html
On peut le vérifier grâce à la directive suivante :
root /var/www/html;
Avant de continuer, prenez connaissance des informations suivantes :
Le fichier de configuration global de Nginx est :
/etc/nginx/nginx.conf
Le dossier qui contient les fichiers de configuration des sites disponibles est :
/etc/nginx/sites-available/
Le dossier qui contient les fichiers de configuration des sites actifs est :
/etc/nginx/sites-enabled/
Lorsque l'on crée la configuration d'un nouveau site, on crée le fichier dans "sites-available" et ensuite lorsque le site est prêt à être activé, on crée un lien symbolique vers "sites-enabled". Cela tombe bien, nous allons créer notre premier site Web dans Nginx : l'occasion de voir ce mécanisme, identique à Apache.
III. Créer un premier site dans Nginx
Nous allons déclarer un nouveau site sur notre serveur Web Nginx. Pour ma part, ce sera le site "it-connect.tech", accessible également avec "www.it-connect.tech". Il sera stocké à l'emplacement suivant : /var/www/it-connect.tech.
Commençons par créer le dossier qui va accueillir notre site Web :
sudo mkdir /var/www/it-connect.tech
Ensuite, on va déclarer l'utilisateur www-data comme propriétaire de ce dossier. Il s'agit de l'utilisateur par défaut de Nginx (correspondant à la propriété "user www-data" du fichier nginx.conf).
Ensuite, c'est le moment de créer notre fichier "index.html" : cela correspond à la page d'accueil de notre site Web.
sudo nano /var/www/it-connect.tech/index.html
Dans ce fichier, insérez le code suivant :
<html>
<head></head>
<body>
<h1>Bienvenue sur IT-Connect !</h1>
</body>
</html>
Enregistrez et fermez le fichier. Il est temps maintenant de créer le fichier de configuration de notre site Internet. Dans le dossier "sites-available", on va créer le fichier "it-connect.tech" : grâce à ce nom, il sera facilement identifiable.
Voici quelques consignes à appliquer quand vous éditez ce fichier, mais aussi pour bien le comprendre :
Respectez l'indentation (espace au début des lignes) pour avoir un fichier de configuration lisible facilement
Les lignes de type "commentaires" commencent par le caractère "#"
Les lignes qui se terminent par ";" correspondent à des directives, c'est-à-dire des options de configuration
Le bloc "Server" permet de déclarer un hôte virtuel et à l'intérieur on déclare sa configuration
Maintenant, je vais vous expliquer la signification des différentes directives de la configuration que l'on vient de créer.
listen 80;
listen [::]:80;
La directive "listen" : la première ligne permet d'indiquer que le serveur Nginx écoute sur toutes ses adresses IPv4, sur le port 80, ce qui correspond au protocole HTTP. La seconde ligne est similaire, mais pour toutes les adresses IPv6 du serveur, toujours sur le port 80.
Pour que le serveur Web écoute seulement sur une adresse IP spécifique du serveur Linux, on pourrait utiliser :
listen 192.168.100.100:80;
En admettant que 192.168.100.100 soit l'adresse IP du serveur Linux.
root /var/www/it-connect.tech;
La directive "root" permet de déclarer la racine du site Internet : en toute logique, on précise la racine que l'on a créée précédemment et où se situe la page index.html.
index index.html;
D'ailleurs, c'est la directive "index" qui permet d'indiquer le nom (ou les noms) des pages par défaut du site. Si l'on définit "index.html", lorsque l'on accède à la racine du site, le serveur Web va chercher à nous présenter le contenu de la page index.html.
server_name it-connect.tech www.it-connect.tech;
La directive "server_name" sert à déclarer le nom de domaine, ou les noms de domaine, concerné par ce bloc "Server". On peut également utiliser une adresse IP. En l'occurrence dans cet exemple, on souhaite que Nginx traite les requêtes qui arrivent sur it-connect.tech et www.it-connect.tech.
location / {
try_files $uri $uri/ =404;
}
Intéressons-nous au dernier bloc de notre fichier de configuration. La directive "location" permet d'indiquer un chemin relatif dans l'URL. En indiquant "/", on cible toutes les requêtes puisqu'une requête commence toujours par "/" après le nom de domaine pour spécifier le chemin vers une page.
Enfin, grâce à la directive "try_files" suivie de $uri et $uri/, nous allons chercher à vérifier l'existence du fichier ou du dossier (d'où le "/") passé en paramètre dans l'URL. La variable $uri reprend automatiquement l'URL saisie par le client qui accède au site. En fait, la règle "try_files $uri $uri/ =404;" permet de retourner une erreur 404 (page introuvable) au client s'il essaie d'accéder à un fichier ou un dossier qui n'existe pas.
Maintenant que vous en savez plus sur la configuration que nous venons de créer, vous pouvez passer à la suite !
Pour que notre site soit actif et la configuration chargée par Nginx, nous devons créer un lien symbolique : rappelez-vous de l'intérêt du dossier "sites-enabled". Pour créer un lien symbolique et renvoyer "/etc/nginx/sites-enabled/it-connect.tech" vers "/etc/nginx/sites-available/it-connect.tech", voici la commande :
On pourrait copier-coller le fichier d'un dossier vers l'autre, mais cela ne serait pas pratique. Grâce à ce lien symbolique, on a qu'un seul fichier à gérer.
Avant de redémarrer le service Nginx, je vous invite à vérifier la syntaxe de la configuration :
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful
C'est tout bon, on peut redémarrer le service Nginx :
sudo systemctl restart nginx
On peut aussi arrêter Nginx et le démarrer, en deux temps :
Je n'ai pas abordé la notion d'enregistrement DNS, mais on part du principe que c'est déjà fait de votre côté. Si vous souhaitez tester sans agir sur les enregistrements DNS, vous pouvez modifier le fichier hosts de votre machine Windows ou Linux.
Par exemple, si vous avez une interface graphique sur votre machine Nginx (ce qui sera peut-être le cas sur un lab), vous pouvez modifier le fichier "/etc/hosts" et ajouter la ligne suivante :
0.0.0.0 it-connect.tech www.it-connect.tech
Si vous utilisez une machine distante, remplacez "0.0.0.0" par l'adresse IP de votre machine Linux.
Les fichiers de logs, c'est-à-dire les journaux de Nginx, sont stockés à l'emplacement suivant :
Passons à l'étape suivante pour que Nginx prenne en charge les scripts PHP.
IV. Ajouter PHP à Nginx
Pour utiliser PHP avec un serveur web Nginx, il est obligatoire d'installer PHP-FPM (PHP FastCGI Process Manager) : Nginx lui transférera les requêtes PHP pour qu'elles soient traitées.
Si l'on installe le paquet "php-fpm" de Debian 10, nous allons récupérer la version 7.3, ce qui n'est pas top. Il vaut mieux récupérer une version plus récente, par exemple PHP-FPM 7.4.X. Pour cela, nous devons agir sur les dépôts de notre machine. Exécutez les commandes suivantes pour ajouter notre nouveau dépôt PPA :
sudo apt-get update
On récupère la clé GPG du dépôt que l'on va ajouter :
En complément, et selon ce que vous souhaitez faire sur votre serveur Web Nginx, pensez à installer les extensions PHP qui vont bien (pour MySQL, par exemple).
Nous devons modifier la configuration de notre site :
Le bout de configuration suivant doit être ajouté au sein du groupe "Server", à la suite du bloc "location" déclaré précédemment :
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
}
Ce qui donne :
Grâce à la directive "location ~ \.php$", on peut agir sur le traitement de tous les fichiers PHP. Ce qui est fort intéressant puisque l'on va pouvoir préciser le fichier de configuration (fastcgi-php.conf) et le chemin vers le socket lié à PHP-FPM, c'est-à-dire le chemin vers php7.4-fpm.sock. Si vous utilisez une version différente de PHP-FPM, le chemin devra être adapté.
Lorsque la configuration est prête, enregistrez le fichier et redémarrez le service Nginx. Avant cela, pensez à vérifier qu'il n'y a pas d'erreur de syntaxe :
sudo nginx -t
sudo systemctl restart nginx
V. Vérifier le bon fonctionnement de PHP avec Nginx
Notre serveur Nginx doit être en mesure de gérer l'exécution des scripts PHP. Nous allons le vérifier. Je vous invite à créer un fichier "info.php" à la racine de notre site Web :
sudo nano /var/www/it-connect.tech/info.php
Dans ce fichier, ajoutez le contenu ci-dessous. Pour rappel, la fonction phpinfo() permet d'obtenir un état détaillé de PHP sur un serveur Web.
<?php
phpinfo();
?>
Enregistrez le fichier et tentez d'accéder à la page info.php avec un navigateur. Normalement, vous devez obtenir une page similaire à celle ci-dessous. On peut voir que PHP fonctionne et que j'utilise bien PHP 7.4.
PHP sur un serveur web Nginx
Voilà ! Votre serveur Web sous Nginx est prêt à être utilisé !
FreshRSS 
