Sécurité Essentielle de Nginx : Bonnes Pratiques et FAQ de Dépannage
FAQ pratiques sur la sécurité de Nginx couvrant HTTPS, l'exposition de fichiers, les en-têtes de proxy, les limites de débit et la revue des journaux.
Sécurité Essentielle de Nginx : Bonnes Pratiques et FAQ de Dépannage
La sécurité essentielle de Nginx n'est pas un seul paramètre ou un en-tête magique. C'est un ensemble de valeurs par défaut prudentes : HTTPS, accès restreint aux fichiers, comportement proxy sûr, exposition limitée et journaux qui vous aident à repérer les problèmes avant qu'ils ne s'aggravent.
Cette FAQ couvre les questions que les équipes posent généralement après avoir mis Nginx en ligne et réalisé que la configuration par défaut n'est qu'un point de départ.
Quels Sont les Premiers Paramètres de Sécurité de Nginx à Vérifier ?
Commencez par les bases qui réduisent l'exposition accidentelle. Ces paramètres vous protègent des erreurs courantes, pas des attaques avancées.
D'abord, désactivez les jetons de version :
server_tokens off;
Cela empêche Nginx d'afficher sa version dans les pages d'erreur et les en-têtes. Cela ne rend pas le serveur invisible, mais supprime les détails inutiles.
Ensuite, assurez-vous que votre racine de documents est correcte. Une erreur courante est de pointer root vers un répertoire de projet au lieu du répertoire de construction public. Cela peut exposer des fichiers source, des exemples d'environnement ou des actifs privés.
Pour un site statique, préférez quelque chose comme :
root /var/www/example.com/public;
pas :
root /var/www/example.com;
Troisièmement, bloquez les fichiers cachés à moins que votre application n'en ait vraiment besoin :
location ~ /\.(?!well-known) {
deny all;
}
Cela autorise les chemins .well-known utilisés par la validation des certificats tout en refusant des fichiers tels que .env, .git et .htpasswd.
Enfin, vérifiez les limites de téléchargement. Si votre site n'accepte pas de gros téléchargements, gardez client_max_body_size modeste. Cela réduit l'impact des requêtes volumineuses accidentelles.
Comment Nginx Devrait-il Gérer HTTPS ?
HTTPS devrait être le chemin normal pour les sites web publics et les API. Redirigez le HTTP simple vers HTTPS, utilisez des certificats valides et évitez les paramètres de protocole obsolètes.
Un bloc de serveur de redirection simple ressemble à ceci :
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
Le bloc de serveur HTTPS doit référencer vos fichiers de certificat et inclure des paramètres TLS modernes. De nombreuses équipes utilisent Certbot ou un équilibreur de charge géré pour gérer les certificats. Le point important est de maintenir le renouvellement automatisé et surveillé.
Les en-têtes de sécurité peuvent également aider les navigateurs à prendre des décisions plus sûres :
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;
Soyez prudent avec la Politique de Sécurité du Contenu. Elle est puissante, mais une politique stricte peut casser des scripts, des polices, des analyses ou du contenu intégré si vous l'appliquez sans test. Commencez en mode rapport uniquement lorsque c'est possible.
Pour un guide pratique sur HTTPS, voir sécuriser Nginx avec HTTPS.
Comment Sécuriser Nginx en Tant que Proxy Inverse ?
Lorsque Nginx proxy le trafic vers une application, vous devez préserver les bonnes informations de requête sans faire aveuglément confiance à l'entrée du client.
Les en-têtes proxy courants ressemblent à ceci :
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;
Ces en-têtes aident l'application en amont à comprendre la requête d'origine. Ils sont utiles pour la journalisation, les redirections, la limitation de débit et les vérifications de sécurité.
Si Nginx se trouve derrière un autre proxy ou équilibreur de charge de confiance, configurez soigneusement la gestion des adresses IP réelles. Ne faites confiance qu'aux adresses proxy connues :
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Ne faites pas confiance à X-Forwarded-For provenant d'Internet ouvert. Un client peut falsifier cet en-tête. Ne lui faites confiance que lorsque la requête provient de votre équilibreur de charge, CDN ou proxy interne.
Vous devriez également masquer les détails d'implémentation en amont. Si votre application renvoie des en-têtes spécifiques au framework dont vous n'avez pas besoin, supprimez-les au niveau du proxy ou de l'application.
Devrais-je Utiliser la Limitation de Débit ?
La limitation de débit est utile pour les pages de connexion, les points de terminaison de recherche, les API coûteuses et toute route que les attaquants peuvent abuser à moindre coût. Ce n'est pas un remplacement de la sécurité de l'application, mais cela peut ralentir les tentatives de force brute et le trafic bruyant.
Exemple :
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
server {
location /login {
limit_req zone=login burst=10 nodelay;
proxy_pass http://app_backend;
}
}
Cela crée une zone mémoire partagée indexée par l'adresse IP du client et limite les requêtes vers le chemin de connexion. Les valeurs exactes dépendent de vos utilisateurs. Un tableau de bord d'entreprise peut généralement tolérer des limites plus strictes qu'une application publique grand public sur les réseaux mobiles.
Testez soigneusement les limites de débit. Si votre site est derrière un proxy et que vous n'avez pas configuré la gestion des adresses IP réelles, chaque utilisateur peut sembler provenir de la même adresse. Cela peut bloquer le trafic légitime.
Pourquoi Vois-je Encore des Requêtes Suspectes ?
Les serveurs Nginx publics reçoivent constamment un bruit de fond : des scans de panneaux d'administration obsolètes, de fichiers PHP, de chemins WordPress et de fichiers d'environnement exposés. Voir ces requêtes dans les journaux ne signifie pas toujours que vous êtes compromis.
Ce qui compte, c'est la façon dont votre serveur répond. Une requête pour /wp-admin sur un site non-WordPress devrait renvoyer 404 ou 403. Une requête pour /.env ne devrait jamais renvoyer de secrets. Une requête avec un chemin étrange ne devrait pas être proxyfiée vers un service d'administration interne.
Consultez vos journaux d'accès pour :
- Des réponses 401 ou 403 répétées
- De nombreuses requêtes provenant d'une seule IP
- De gros corps de requête
- Des sondages de fichiers cachés
- Des user agents inhabituels
- Des pics de réponses 499, 502 ou 504
Pour un dépannage plus large, voir Erreurs courantes de Nginx.
Quand Demander de l'Aide en Sécurité
Faites appel à un ingénieur en sécurité ou à un consultant DevOps expérimenté lorsque Nginx protège des données clients, l'authentification, les flux de paiement, des API privées ou des outils d'administration internes. Vous devriez également demander de l'aide après toute violation suspectée, exposition de fichier inattendue ou trafic d'attaque répété affectant la disponibilité.
Une revue professionnelle en vaut la peine lorsque la configuration s'étend sur plusieurs couches, comme CDN, équilibreur de charge, Nginx, maillage de services et framework d'application. Un fichier Nginx sûr peut encore être affaibli par une mauvaise frontière de confiance ailleurs.
Sécurisez Nginx en supprimant l'exposition inutile, en forçant HTTPS, en gérant soigneusement les en-têtes proxy et en surveillant les journaux. Vous n'avez pas besoin d'une configuration énorme pour être plus sûr. Vous avez besoin de valeurs par défaut claires, de changements testés et d'une habitude de vérifier ce que votre serveur sert réellement.