Détecter une activité malveillante dans les logs d'un serveur web

Un serveur web exposé sur Internet subit en permanence des requêtes automatisées. Avant de déployer des outils complexes, la première ligne de défense consiste à savoir lire et interpréter les journaux d'accès (access.log) et d'erreurs (error.log) de Nginx ou Apache.

Repérer les scans de vulnérabilités

Les bots de reconnaissance laissent une empreinte caractéristique : une succession rapide de codes HTTP 404 provenant d'une même adresse IP, ciblant des chemins sensibles comme /wp-login.php, /.env, /phpmyadmin ou /admin. Un User-Agent générique (python-requests, curl, Go-http-client) ou explicitement lié à un outil d'audit (nuclei, nikto, sqlmap) confirme généralement l'intention.

Identifier les injections SQL et XSS

Les tentatives d'exploitation applicative apparaissent directement dans les paramètres d'URL ou les corps de requêtes. Il faut rechercher des motifs encodés ou en clair tels que UNION SELECT, OR 1=1, <script>, ou encore des séquences de traversée de répertoire comme ../../../etc/passwd.

grep -E "(UNION|SELECT|\.\./|<script>)" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20

Détecter le bruteforce et automatiser la réponse

Surveillez les pics de requêtes POST vers vos points d'authentification (/login, /api/auth) accompagnés de codes 401 ou 403, ou d'une redirection 302 répétée vers la page de connexion.

Un log non analysé est une preuve qui dort : couplez vos journaux à Fail2ban ou CrowdSec pour transformer l'observation en blocage automatique.

Enfin, centralisez vos journaux vers un SIEM ou une pile Loki/ELK afin de conserver un historique intègre et exploitable en cas d'incident de sécurité.