Dopo un incidente il registro degli accessi contiene tutto: cosa è stato chiesto, quando, da dove e cosa ha risposto il server. Il problema non è mai la scarsità di dati, ma un milione di righe di dati. Questi comandi li riducono.

Chi fa più richieste

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

Cosa hanno chiesto

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

Una scansione si riconosce a occhio in questo elenco: decine di percorsi, ciascuno richiesto una volta sola, quasi tutti con 404. Una persona che naviga non somiglia affatto a questo.

Cosa è RIUSCITO, che è poi la domanda vera

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 muro di 404 è rumore. Un 200 su un percorso che non riconosci è la riga davanti a cui fermarsi, soprattutto una POST verso un file in una cartella di caricamento.

Solo le richieste POST

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

Quando è successo

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

E la forma di un caricamento riuscito

sudo awk '$7 ~ /uploads/ && $9 == 200 {print}' /var/log/nginx/access.log | grep -i '\.php' | head
Copia i registri altrove prima di cominciare. La rotazione è attiva e un server carico può sovrascrivere le prove nel giro di un giorno, di solito poco prima che tu capisca cosa cercare.