Requêtes GET suspectes dans les logs Nginx : triage, blocage et durcissement VPS

Quand un VPS est exposé sur Internet, les logs Nginx se remplissent vite de chemins improbables, de scans sur /wp-login.php, /.env, /phpmyadmin ou d’appels répétés sur des routes qui n’existent pas. Ce bruit n’est pas une surprise, mais il devient un vrai sujet d’exploitation quand il masque un début d’attaque, fait grimper la charge ou entraîne de mauvais blocages. L’objectif n’est donc pas de bannir tout ce qui bouge. Il faut d’abord lire correctement les signaux, qualifier le niveau de risque, puis mettre en place des protections graduées et maintenables.

Réponse rapide

Si vous observez des requêtes GET suspectes dans les logs Nginx, commencez par isoler les IP les plus bruyantes, les chemins ciblés et la fréquence des erreurs 404/403. Ensuite, appliquez un blocage progressif avec map, return 444, rate limiting et éventuellement Fail2ban. Enfin, durcissez le VPS en réduisant la surface exposée, en surveillant les journaux et en vérifiant que vos endpoints sensibles ne sont plus accessibles inutilement.

Contexte : pourquoi ce bruit apparaît presque toujours sur un VPS

Un serveur web public attire en permanence des robots opportunistes. Certains cherchent une faiblesse connue sur WordPress, d’autres testent des chemins d’administration génériques, d’autres encore essaient simplement de repérer la technologie derrière votre stack. Dans la pratique, un Nginx proprement configuré reçoit donc du trafic parasite même quand le site n’est pas particulièrement connu.

Le piège classique consiste à traiter tout ce bruit comme une urgence de sécurité. C’est contre-productif. Une vraie exploitation se repère plutôt par la répétition, la cohérence des chemins demandés, l’acharnement sur certains endpoints, la corrélation avec d’autres alertes et l’impact technique réel. Pour les petites équipes ops, la bonne approche ressemble à un runbook de triage, pas à une réaction émotionnelle.

Diagnostic : comment lire rapidement les logs sans se noyer

Le premier travail consiste à ramener les logs à une vue exploitable. On veut savoir qui frappe, sur quoi, à quel rythme et avec quel résultat HTTP. Commencez avec les accès Nginx, puis corrélez si besoin avec le journal système et vos métriques de charge.

awk 'print $1, $7, $9' /var/log/nginx/access.log | tail -n 200
awk 'status 403/404/444/499' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
grep -E 'wp-login|xmlrpc|phpmyadmin|\.env|boaform|vendor|cgi-bin' /var/log/nginx/access.log | tail -n 100
journalctl -u nginx --since '2 hours ago'

Ces commandes donnent déjà une image claire : les IP dominantes, les chemins sensibles visés et les codes retour générés. Si une même adresse enchaîne des dizaines de 404 sur des chemins connus d’exploitation, il s’agit très souvent d’un scan automatisé. Si les mêmes IP provoquent aussi des erreurs applicatives, une montée CPU ou des logs système anormaux, la priorité monte.

Pour des environnements plus structurés, centraliser les logs dans Loki, Elastic ou un SIEM simplifie énormément ce triage. Mais sur un petit VPS, une lecture locale bien faite reste souvent suffisante si elle s’accompagne d’une discipline simple : regarder les top IP, les top chemins, les top user-agents et l’évolution du volume sur une période courte.

Causes fréquentes derrière des requêtes GET suspectes

Les causes les plus courantes sont assez prévisibles. La première est le scan automatisé opportuniste : des robots essaient des routes standards en espérant trouver une interface mal protégée. La deuxième est le fingerprinting technologique : l’attaquant veut savoir si le serveur répond comme un WordPress, un Laravel, un phpMyAdmin ou une stack vulnérable. La troisième est le scraping agressif qui ne cherche pas une faille, mais surcharge l’infrastructure. Enfin, il y a les tests ciblés après divulgation d’une CVE ou après exposition d’un service sur Shodan.

Dans le cas d’un VPS PME, les requêtes /wp-login.php, /xmlrpc.php, /.git/config ou /.env sont typiques du premier niveau. Ce sont surtout des tentatives à faible coût. À l’inverse, une séquence répétée sur des routes métier ou une insistance sur un endpoint d’admin interne montre un intérêt plus spécifique, donc un risque supérieur.

Solutions : triage, blocage et durcissement sans casser la prod

La bonne réponse se fait en couches. Première couche : fermer ou masquer ce qui n’a rien à faire sur un VPS public. Si vous n’utilisez pas WordPress, inutile de laisser répondre un chemin trompeur. Si vous n’avez pas d’interface d’admin publique, forcez une restriction réseau ou une authentification supplémentaire.

Deuxième couche : créer des réponses cohérentes côté Nginx. Pour certains chemins techniques que vous ne servirez jamais, un return 444 ou un deny all simple réduit le bruit et économise des ressources. Pour les pics de fréquence, le module limit_req de Nginx reste une mesure légère et efficace.

map request_uri bad_probe
  default 0
  env phpmyadmin wp-login xmlrpc => 1
server
  if bad_probe then return 444
  location / with limit_req and try_files

Troisième couche : automatiser le blocage sur motif avec Fail2ban. Ce n’est pas la seule voie, mais pour un VPS simple c’est souvent le meilleur ratio effort/résultat. Un filtre sur des 404/403 massifs vers des chemins connus, combiné à une jail courte puis plus longue en cas de récidive, donne de bons résultats. La documentation officielle de Fail2ban reste une base fiable, et vous pouvez compléter avec votre durcissement SSH existant ou un article comme ce guide Fail2ban/Ansible.

[nginx-bad-probes]
enabled  = true
port     = http,https
filter   = nginx-bad-probes
logpath  = /var/log/nginx/access.log
maxretry = 8
findtime = 600
bantime  = 3600
action   = iptables-multiport[name=nginx-bad-probes, port="http,https"]

Quatrième couche : travailler l’hygiène d’exploitation. Les logs doivent être conservés assez longtemps pour comprendre une séquence, mais pas au point d’exploser le disque. Les paquets Nginx et OpenSSL doivent être à jour. Les routes d’admin doivent être limitées. Les entêtes utiles, le TLS, la journalisation et la supervision doivent être revus ensemble. Sur ce point, un audit type Lynis sur serveur Linux aide à remettre les priorités dans le bon ordre.

Prévention : comment réduire durablement le bruit utilement

La prévention repose surtout sur la réduction de surface d’attaque. Retirez les endpoints inutiles, servez une application minimale, limitez les interfaces d’administration par IP ou VPN, et placez si besoin un service amont comme Cloudflare quand la volumétrie devient pénible. Pensez aussi au découplage : un front Nginx propre, une appli derrière, et aucune exposition accidentelle de fichiers de build ou de variables d’environnement.

Il faut également ritualiser la revue des logs. Une revue hebdomadaire de quinze minutes vaut mieux qu’une réaction dans la panique une fois par trimestre. Cherchez les nouvelles routes visées, les changements de user-agent, les IP récurrentes et les hausses de fréquence. C’est souvent là qu’on repère les dérives avant incident.

Checklist de réponse rapide

Erreurs courantes qui aggravent le problème

FAQ

Conclusion

Des requêtes GET suspectes dans les logs Nginx ne veulent pas dire que votre VPS est compromis, mais elles rappellent qu’Internet teste en permanence la moindre exposition. Avec un triage simple, des filtres Nginx bien choisis, un blocage automatisé et un durcissement progressif, vous passez d’une réaction au coup par coup à une défense exploitable par une petite équipe. C’est cette discipline qui fait la différence entre un serveur simplement exposé et un serveur réellement résilient.