Après un incident, le journal d'accès contient tout : ce qui a été demandé, quand, d'où, et ce que le serveur a répondu. Le problème n'est jamais le manque de données, c'est un million de lignes. Ces commandes les réduisent.

Qui demande le plus

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Ce qu'il a demandé

sudo grep " 203.0.113.42 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Un scan saute aux yeux dans cette liste : des dizaines de chemins, chacun demandé une fois, la plupart en 404. Un humain qui navigue ne ressemble en rien à cela.

Ce qui a RÉUSSI, la vraie question

sudo awk '$9 ~ /^(200|301|302)$/ {print $1, $7}' /var/log/nginx/access.log \
  | grep -E 'wp-login|xmlrpc|/admin|\.php' | sort | uniq -c | sort -rn | head -20
Un mur de 404 n'est que du bruit. Un 200 sur un chemin que vous ne reconnaissez pas, voilà la ligne où s'arrêter — surtout un POST vers un fichier dans un répertoire d'envoi.

Les POST seulement

sudo awk '$6 ~ /POST/ {print $1, $7, $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Quand cela s'est produit

sudo grep "203.0.113.42" /var/log/nginx/access.log | awk -F'[\\[\\]]' '{print $2}' | cut -d: -f1-2 | uniq -c

Et l'allure d'un envoi réussi

sudo awk '$7 ~ /uploads/ && $9 == 200 {print}' /var/log/nginx/access.log | grep -i '\.php' | head
Copiez les journaux ailleurs avant de commencer. La rotation tourne, et un serveur chargé peut effacer les traces en une journée — en général juste avant que vous ne trouviez quoi chercher.