Un serveur web avec nginx

Module 7: Domaine, serveur web et https · Temps de lecture : 12 minutes

Objectif pédagogique: À l'issue de cette leçon, vous saurez installer nginx, configurer un site web et un reverse proxy avec un server block, tester et recharger une configuration en toute sécurité, et régler correctement les droits de votre webroot.

Notions clés: nginx, server block, sites-available et sites-enabled, conf.d, listen, server_name, root, index, try_files, default server, nginx -t, reload, reverse proxy, proxy_pass, Host, X-Forwarded-For, X-Forwarded-Proto, webroot, PHP-FPM

Ce que fait un serveur web

Un serveur web écoute sur le port 80 (http) et 443 (https), reçoit les requêtes des navigateurs et renvoie quelque chose: un fichier stocké sur le disque (un site statique), ou la réponse d'un programme qui tourne derrière lui (PHP, une application Node.js, un conteneur). Dans ce second cas, le serveur web s'appelle un reverse proxy: il se trouve en première ligne, gère le https et transmet la requête à l'application, qui n'écoute que sur 127.0.0.1.

Sous Linux, nginx et Apache sont les serveurs web les plus connus, et Caddy (leçon 7.4) est une alternative moderne qui gère elle-même les certificats. Cette leçon utilise nginx: il est présent dans toutes les distributions, consomme peu de mémoire et sert de référence dans de nombreux tutoriels.

Installation et premier coup d'œil

anna@web1:~$ sudo apt install nginx
anna@web1:~$ systemctl status nginx
anna@web1:~$ curl -I http://localhost
HTTP/1.1 200 OK
Server: nginx/1.26.3
Content-Type: text/html

(Le numéro de version est un exemple.) N'oubliez pas le pare-feu: les ports 80 et 443 doivent être ouverts (leçon 5.2). Si vous ouvrez maintenant http://192.0.2.10, vous voyez la page d'accueil de nginx.

La configuration se trouve dans /etc/nginx/:

sites-available et sites-enabled sont une habitude de Debian et Ubuntu: vous activez ou désactivez un site en créant ou en supprimant un lien, sans effacer le fichier.

Un premier site

Créez un dossier pour le site et une page de test:

anna@web1:~$ sudo mkdir -p /var/www/example.com
anna@web1:~$ echo '<h1>Het werkt</h1>' | sudo tee /var/www/example.com/index.html

Créez ensuite un server block: la description d'un site.

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

Voici comment le lire:

• listen 80; et listen [::]:80; font écouter nginx en IPv4 et en IPv6. Si vous oubliez la seconde ligne, votre enregistrement AAAA ne fonctionne pas (leçon 7.1).
• server_name indique pour quels noms ce bloc s'applique. À chaque requête, nginx regarde le nom demandé par le navigateur (l'en-tête Host) et choisit le bloc correspondant.
• root est le dossier contenant les fichiers, index le fichier affiché pour un dossier.
• try_files essaie le fichier demandé, puis un dossier, et renvoie sinon une erreur 404. Sans une telle ligne, une configuration erronée peut afficher plus que vous ne le souhaitez.
• Des journaux propres à chaque site facilitent beaucoup les recherches (leçon 6.2).

Activez le site, retirez le site par défaut, testez et rechargez:

anna@web1:~$ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
anna@web1:~$ sudo rm /etc/nginx/sites-enabled/default
anna@web1:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
anna@web1:~$ sudo systemctl reload nginx
anna@web1:~$ curl -I http://example.com
HTTP/1.1 200 OK

Prenez l'habitude de lancer nginx -t avant chaque reload. En cas d'erreur, la commande vous indique le fichier et la ligne concernés, et votre site en production reste intact. Si vous redémarrez sans tester, nginx ne démarre plus à cause de l'erreur et tous vos sites tombent (leçon 6.1).

Le default server: que reçoit un nom inconnu ?

Que se passe-t-il si quelqu'un interroge votre serveur avec un nom qui ne figure dans aucun server_name, ou tout simplement avec l'adresse IP ? nginx choisit alors le default server: le bloc qui porte default_server après listen, ou à défaut le premier bloc qu'il a rencontré. Sans y prêter attention, c'est donc l'un de vos vrais sites.

Il est plus propre de créer un bloc séparé qui refuse ces requêtes:

# /etc/nginx/sites-available/000-default
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

444 est un code particulier de nginx: la connexion est fermée sans réponse. Les scanners qui parcourent les adresses IP ne voient ainsi rien. Pour le https (port 443), un default server fonctionne un peu différemment, car il nécessite un certificat; nous y reviendrons dans la leçon 7.3.

nginx comme reverse proxy

Si une application tourne sur 127.0.0.1:3000 (leçon 6.3) ou un conteneur sur 127.0.0.1:3001 (leçon 9.3), nginx l'expose vers l'extérieur:

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Les quatre lignes proxy_set_header sont importantes. Sans Host, l'application ne sait pas sous quel nom elle est consultée. Sans X-Forwarded-For, l'application voit chaque visite venir de 127.0.0.1 (le proxy) au lieu de l'adresse réelle du visiteur. Sans X-Forwarded-Proto, l'application pense que tout passe par http et crée parfois des liens ou des cookies en http, alors que votre site fonctionne en https. De nombreuses applications ont un réglage pour faire confiance à ces en-têtes («trusted proxy»); n'y indiquez que 127.0.0.1, sinon n'importe quel visiteur peut envoyer une fausse adresse.

Les applications qui utilisent des websockets (mises à jour en direct, comme Uptime Kuma) ont besoin de deux lignes supplémentaires: proxy_http_version 1.1; et la transmission de Upgrade et Connection. La documentation de l'application indique généralement lesquelles exactement.

Droits du webroot

Sous Debian et Ubuntu, nginx exécute ses processus de travail sous l'utilisateur www-data. Celui-ci doit pouvoir lire vos fichiers, mais ne doit pas pouvoir les modifier. Une bonne organisation (leçon 3.1):

anna@web1:~$ sudo chown -R anna:www-data /var/www/example.com
anna@web1:~$ sudo find /var/www/example.com -type d -exec chmod 750 {} \;
anna@web1:~$ sudo find /var/www/example.com -type f -exec chmod 640 {} \;

Vous (anna) gérez les fichiers, le groupe www-data peut lire, les autres n'ont aucun droit. Si le site doit écrire quelque part, par exemple dans un dossier d'envoi de fichiers, donnez les droits d'écriture à www-data uniquement sur ce dossier. Jamais chmod 777 (leçon 10.2). Si vous obtenez une erreur 403 Forbidden, consultez le journal d'erreurs du site: vous y trouverez permission denied avec le chemin.

Quelques autres bonnes habitudes:

• Aucun secret dans le webroot. Les sauvegardes (site.zip), les fichiers .env et les dossiers .git n'y ont pas leur place; s'ils y sont déposés par erreur, ils peuvent être téléchargés. Un filet de sécurité supplémentaire: location ~ /\. { deny all; } bloque tous les fichiers qui commencent par un point (sauf ce que vous autorisez explicitement, comme /.well-known/, voir les leçons 7.3 et 7.4).
• Masquer la version. server_tokens off; dans nginx.conf retire le numéro de version de l'en-tête Server et des pages d'erreur. Ce n'est pas une vraie protection, mais cela donne moins d'informations aux scanners.

PHP, en bref

Pour les sites PHP (comme WordPress), nginx communique avec PHP-FPM, un service distinct. Sous Debian, vous installez php-fpm et ajoutez dans le server block un bloc location ~ \.php$ avec include snippets/fastcgi-php.conf; et fastcgi_pass unix:/run/php/php8.4-fpm.sock; (le numéro de version varie selon la version de la distribution). La formation WordPress approfondit ce sujet.

Sous AlmaLinux et Rocky Linux

Il n'y a pas de sites-available: vous placez chaque site dans son propre fichier dans /etc/nginx/conf.d/<naam>.conf. nginx tourne sous l'utilisateur nginx au lieu de www-data, et le webroot par défaut est /usr/share/nginx/html. Par défaut, SELinux empêche nginx de se connecter à une application derrière proxy_pass; autorisez-le avec setsebool -P httpd_can_network_connect 1. Les fichiers situés hors des dossiers habituels ont besoin d'un label SELinux (semanage fcontext et restorecon).

Résumé

• nginx sert des fichiers ou, en tant que reverse proxy, transmet les requêtes à une application sur 127.0.0.1.
• Un server block par site dans sites-available, activé par un lien dans sites-enabled; écoutez sur 80 et sur [::]:80.
• Toujours nginx -t avant systemctl reload nginx.
• Un default server dédié avec return 444 évite qu'un nom inconnu ou l'adresse IP seule affiche l'un de vos sites.
• En reverse proxy, vous transmettez Host, X-Forwarded-For et X-Forwarded-Proto; le webroot est lisible par www-data, non modifiable, et ne contient aucun secret.

Quiz

Exercice

Exercice O7.2: Votre premier site. Installez nginx (ou utilisez Caddy de la leçon 7.4), créez un server block pour un domaine ou sous-domaine qui pointe vers votre serveur, avec listen pour IPv4 et IPv6, des journaux propres et un default server dédié. Testez avec nginx -t, rechargez, puis vérifiez avec curl -I en IPv4 et en IPv6. Réglez les droits du webroot comme dans la leçon. Remplissez la checklist et collez votre server block.

Pour aller plus loin

• Interdit (403) : vous n'avez pas l'autorisation d'accéder à / sur ce serveur
• Documentation nginx, How nginx processes a request (server_name et default server): https://nginx.org/en/docs/http/request_processing.html
• Documentation nginx, Beginner's Guide: https://nginx.org/en/docs/beginners_guide.html
• Documentation nginx, ngx_http_proxy_module: https://nginx.org/en/docs/http/ngx_http_proxy_module.html