> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # Auditer et durcir nginx sur un VPS : la routine qui devance le prochain avis > Savoir ce que vous exécutez, réduire ce qui est exposé, et le vérifier en une commande. Une routine nginx bâtie sur ce qui est réellement exploité. Auditer et durcir nginx sur un VPS : connaître sa version, réduire la surface, vérifier *Publié le 12 août 2026* Deux débordements de tas sont apparus dans le moteur de script de nginx à quelques mois d'intervalle cette année, et le second a pris de court quantité de gens qui avaient déjà corrigé le premier. Ce n'est pas un échec de correction. C'est un échec d'inventaire : ne pas savoir précisément ce qu'on exécute, et où. Voici la routine qui règle ça. Une vingtaine de minutes la première fois, deux minutes par mois ensuite. ## 1. Savoir ce que vous exécutez réellement Le fait le plus utile, et le plus souvent faux. L'avis de votre gestionnaire de paquets n'est pas le binaire sur le disque, qui n'est pas le code en mémoire. ```bash theme={null} # Le binaire nginx -v # Ce que croit le gestionnaire de paquets apt list --installed 2>/dev/null | grep nginx || rpm -q nginx # Ce qui tourne vraiment, et depuis quand ps -eo pid,lstart,cmd | grep "[n]ginx: master" ``` Si la troisième commande montre un processus maître plus ancien que votre dernière mise à jour, vous avez installé un correctif sans jamais redémarrer. L'ancien binaire sert toujours le trafic. C'est l'écart le plus fréquent entre « corrigé » et « sûr ». `nginx -s reload` ne remplace pas le processus maître. Après une mise à jour de paquet, utilisez `systemctl restart nginx`. Le rechargement sert aux changements de configuration, pas de binaire. ## 2. Inventorier tous les nginx que vous avez oubliés Le nginx que vous corrigez est rarement le seul que vous exécutez. Les conteneurs épinglent leurs propres copies, et un tag épinglé ne bouge jamais tout seul. ```bash theme={null} # nginx dans les conteneurs en cours d'exécution docker ps --format '{{.Names}}' | while read -r c; do v=$(docker exec "$c" nginx -v 2>&1 | grep -o 'nginx/[0-9.]*' || true) [ -n "$v" ] && echo "$c: $v" done # Tags épinglés dans vos fichiers compose grep -rn "image:.*nginx" --include="*.yml" --include="*.yaml" . 2>/dev/null ``` Un `nginx:1.30.1` épinglé est figé jusqu'à reconstruction. Si vos fichiers compose épinglent des versions exactes, corriger devient un changement de code : cela relève de votre routine de déploiement, pas de votre routine serveur. ## 3. Réduire ce qui est exposé La plupart des avis nginx concernent un module ou une directive précise. Moins vous en utilisez, moins d'avis vous concernent. Commencez par voir ce que votre build embarque : ```bash theme={null} # Configuration de compilation complète, modules compris nginx -V 2>&1 | tr ' ' '\n' | grep -E "^--with|^--without" ``` Puis regardez ce que votre configuration sollicite réellement. Les deux débordements de tas de cette année vivaient tous deux dans le moteur de script — `map`, `rewrite` et captures de regex : ```bash theme={null} # Blocs map fondés sur une regex grep -rn "^\s*map\s" /etc/nginx/ -A 3 | grep -E "~\*?\s" # Règles rewrite et captures de regex grep -rnE "^\s*rewrite\s|\\\$[1-9]" /etc/nginx/ ``` Ce n'est pas une raison d'éviter `map` — c'est une bonne directive. C'est une raison de savoir en quelques secondes, plutôt qu'en un après-midi, si un avis qui la nomme vous concerne. ## 4. Cesser d'annoncer sa version nginx renvoie sa version exacte dans chaque en-tête de réponse et chaque page d'erreur, par défaut. Cela transforme n'importe quel scan en liste ciblée. ```nginx theme={null} # Dans le bloc http server_tokens off; ``` Ce n'est pas un contrôle de sécurité — cela ne corrige aucun bug. C'est un contrôle de coût : cela vous sort de l'ensemble trivialement énumérable, là où l'exploitation de masse fait ses courses. Vérifiez que c'est pris en compte : ```bash theme={null} curl -sI https://example.com | grep -i "^server:" # attendu : « Server: nginx » sans numéro de version ``` ## 5. Poser les en-têtes qui ne coûtent rien Quatre en-têtes, sans inconvénient pour l'immense majorité des sites : ```nginx theme={null} # Dans le bloc server add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; ``` `Strict-Transport-Security` est un engagement. Une fois qu'un navigateur l'a vu, il refuse le HTTP simple sur votre domaine pendant toute la durée du `max-age`. Ne l'ajoutez que si HTTPS fonctionne partout sur le domaine, sous-domaines compris, et commencez avec un `max-age` court en cas de doute. Le mot-clé `always` compte : sans lui, les en-têtes disparaissent des réponses d'erreur, précisément celles qu'un attaquant voit le plus. ## 6. Plafonner la taille et le débit des requêtes Les valeurs par défaut sont généreuses parce que nginx ne connaît pas votre application. Un point d'envoi qui accepte 1 Go quand votre plus gros fichier légitime pèse 5 Mo, c'est des munitions offertes. ```nginx theme={null} # Dans le bloc http client_max_body_size 10m; client_body_timeout 12s; client_header_timeout 12s; # Une zone de limitation modeste, appliquée là où c'est utile limit_req_zone $binary_remote_addr zone=basic:10m rate=10r/s; ``` ```nginx theme={null} # Dans le location concerné — un point de connexion, par exemple location /login { limit_req zone=basic burst=20 nodelay; } ``` Ajustez les chiffres à votre application plutôt que de les recopier. Ce qui compte, c'est qu'un chiffre existe. ## 7. Vérifier, puis en faire une routine Ne rechargez jamais sur une configuration non testée : ```bash theme={null} # Analyser et valider sans toucher au serveur en fonctionnement sudo nginx -t # Seulement si la commande précédente est passée sudo systemctl reload nginx ``` Puis réduisez tout l'audit à une commande à lancer chaque mois : ```bash theme={null} #!/usr/bin/env bash # nginx-audit.sh — à lancer chaque mois, ou après tout avis set -u echo "== version ==" nginx -v 2>&1 echo "== ancienneté du processus maître ==" ps -eo lstart,cmd | grep "[n]ginx: master" || echo "arrêté" echo "== validité de la configuration ==" nginx -t 2>&1 | tail -2 echo "== fuite de version ==" grep -rq "server_tokens off" /etc/nginx/ && echo "server_tokens off" || echo "ALERTE : version exposée" echo "== conteneurs ==" docker ps --format '{{.Names}}' 2>/dev/null | while read -r c; do v=$(docker exec "$c" nginx -v 2>&1 | grep -o 'nginx/[0-9.]*' || true) [ -n "$v" ] && echo "$c: $v" done ``` ```bash theme={null} chmod +x nginx-audit.sh && ./nginx-audit.sh ``` ## Ce que cela vous apporte vraiment Rien de tout cela n'empêchera le prochain débordement de tas dans le moteur de script. Aucune configuration ne le fera. Ce que cela apporte, c'est de pouvoir répondre en moins d'une minute à la seule question que pose réellement un avis : **la version que j'exécute est-elle dans la plage touchée, partout où je l'exécute ?** Les équipes qui savent y répondre corrigent en un après-midi. Les autres passent une semaine à le découvrir, et oublient généralement un conteneur. Deux habitudes portent l'essentiel : redémarrer après une mise à jour de paquet, et traiter les tags de conteneurs épinglés comme du code à mettre à jour. À lire aussi : notre avis sur les [deux débordements de tas de nginx](/fr/nginx-map-regex-cve-2026-42533) et le [guide de sécurité renforcée pour VPS](/fr/securite-renforcee-sur-un-vps-linux-conseils-et-outils-pour-proteger-vos-donnees-sensibles) pour la couche du dessous. Une question sur un serveur hébergé chez nous ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.