NGINX : « engine x », serveur web et proxy inverse
Infrastructure
NGINX : prononcé « engine x », serveur web, proxy inverse et répartiteur de charge libre, créé par Igor Sysoev. « Le portier placé devant l'application, qui décide qui entre, à quel rythme et par quelle porte », par analogie avec le videur de boîte de nuit, qui ne sait pas danser mais protège très bien ceux qui le savent.
Origine : Écrit pour tenir un grand nombre de connexions simultanées avec peu de mémoire, grâce à un modèle événementiel, il est publié pour la première fois en 2004. La société qui le développait a été rachetée par F5 en 2019 ; des dérivés comme freenginx ou Angie sont nés de désaccords ultérieurs, preuve qu'un logiciel libre réussi finit toujours par avoir des héritiers en procès d'intention.
Limitation de débit : Les directives limit_req_zone et limit_req appliquent un seau percé par clé (souvent l'adresse IP du client) : au-delà du débit autorisé, les requêtes sont retardées ou rejetées avant d'atteindre l'application. La clé n'a de sens que si NGINX voit la vraie adresse du client ; derrière un CDN ou un autre proxy, le module realip doit n'accepter l'en-tête X-Forwarded-For que des relais de confiance.
Rôles courants : Terminaison TLS, mise en cache, répartition de charge, filtrage par en-tête ou par chemin, et service de fichiers statiques. Ce n'est pas un WAF par défaut : il ne lit pas le contenu des requêtes pour y chercher des attaques sans module dédié.
Ce qui arrive si on s'en passe
Un NGINX posé devant une application sans limitation de débit laisse passer chaque requête coûteuse jusqu'à la base de données, et une poignée de clients suffit à l'épuiser. À l'inverse, une limitation appuyée sur un en-tête X-Forwarded-For accepté de n'importe qui se contourne en changeant cet en-tête à chaque requête, ou se retourne contre tous les clients si la clé devient l'adresse du proxy amont. Enfin, un fichier de configuration copié d'un forum avec des en-têtes de sécurité oubliés et un chemin d'alias mal terminé suffit à exposer des fichiers qui n'auraient jamais dû être servis. Le portier existe ; encore faut-il lui donner la liste des invités.
Explication de la marmotte
Quand on visite un site, on ne parle souvent pas directement au programme qui fabrique les pages, mais à un intermédiaire placé devant lui. NGINX est l'un des logiciels les plus utilisés pour jouer ce rôle. Il peut répartir les visiteurs entre plusieurs serveurs, chiffrer les connexions et refuser ceux qui envoient trop de demandes en trop peu de temps. Bien réglé, il protège l'application contre la surcharge ; mal réglé, il laisse tout passer.
Où ce terme est utilisé
- Contourner un contrôle proxy par confusion de chemin (5 occurrences)
- Migrer TLS legacy sans casser les clients anciens (3 occurrences)
- OCSP stapling pour vérifier la révocation TLS (3 occurrences)
- Comment prévenir une attaque Host header injection (2 occurrences)
- Défendre un DDoS volumétrique et applicatif (2 occurrences)
- Intégrer la cryptographie post-quantique dans TLS (2 occurrences)
- Mettre en place un rate limiting anti-DDoS L7 (2 occurrences)
- Attaque cache deception CDN et contre-mesures (1 occurrence)
- Attaque MIME sniffing par fichier téléversé (1 occurrence)
- Choisir ECDSA, EdDSA ou RSA pour un certificat TLS (1 occurrence)