Come leggere i log di accesso di un server

Ogni volta che qualcuno visita un sito, il server scrive una riga in un file di registro: il log di accesso. Sono migliaia di righe al giorno, quasi tutte noiose, ma contengono la storia di tutto ciò che è successo, compresi i tentativi di intrusione. Saper leggere un log è la competenza di base di chi lavora nel blue team.

Anatomia di una riga

I server web più diffusi usano il «formato combinato». Una riga tipica, con un indirizzo inventato, è questa:

203.0.113.50 - - [05/Oct/2026:10:41:02 +0000] "POST /login HTTP/1.1" 401 512 "-" "Mozilla/5.0"

• 203.0.113.50: l'indirizzo IP di chi ha fatto la richiesta.
• [05/Oct/2026:10:41:02 +0000]: data, ora e fuso orario.
• "POST /login HTTP/1.1": il metodo (POST invia dati), la risorsa richiesta e la versione del protocollo.
• 401: il codice di risposta. 2xx = riuscito, 3xx = reindirizzamento, 401/403 = accesso negato, 404 = non trovato, 5xx = errore del server.
• 512: i byte inviati in risposta.
• L'ultimo campo è lo user agent, cioè il programma che ha fatto la richiesta. Si può falsificare, ma dice comunque molto.

I segnali che qualcosa non va

• Molti 401 o 403 dallo stesso indirizzo sulla pagina di login: tentativi di indovinare le password.
• Raffiche di 404 su percorsi come /admin, /backup, /.git: qualcuno sta cercando pagine dimenticate.
• Richieste a ritmo non umano: decine al secondo da un solo indirizzo.
• Un 200 dopo una lunga serie di errori: il tentativo potrebbe essere riuscito.
• Orari insoliti o paesi mai visti per un account che di solito accede da un solo posto.
• Picchi di errori 5xx, che possono indicare un attacco al servizio o un'applicazione in difficoltà.

Un esempio concreto: chi sta insistendo?

Con pochi comandi di shell puoi trasformare migliaia di righe in una risposta. Qui conti le richieste fallite sulla pagina di login per ogni indirizzo:

$ grep '"POST /login' access.log | grep ' 401 ' | awk '{print $1}' | sort | uniq -c | sort -nr | head -3
    318 203.0.113.50
     12 198.51.100.7
      2 192.0.2.20

Un indirizzo con 318 errori contro i 12 e i 2 degli altri è un candidato evidente: ha provato centinaia di password. Il passo successivo è verificare nel log se, dopo gli errori, ci sia stato un accesso riuscito (200 o un reindirizzamento) da quello stesso indirizzo, e in caso affermativo trattare l'account come compromesso.

Come ci si difende: dai log alla risposta

• Centralizza i log su un sistema separato (SIEM): se chi attacca entra nel server, non può cancellare le sue tracce.
• Imposta allarmi per le soglie ragionevoli: troppi login falliti, un accesso da un paese insolito, un picco di 404.
• Limita e blocca: rate limiting e blocco temporaneo degli indirizzi che superano la soglia, come descritto nella guida al brute force.
• Tieni gli orologi sincronizzati (NTP): per ricostruire una cronologia servono timestamp coerenti fra tutti i sistemi.
• Conserva abbastanza storia: molte intrusioni si scoprono dopo settimane. Decidi per quanto tempo tenere i log, rispettando privacy e normativa.
• Proteggi i log stessi: permessi in sola scrittura per le applicazioni, e attenzione a non scrivervi mai password o dati personali non necessari.

Dopo i primi esercizi diventa un'abitudine: filtrare, contare, ordinare e chiedersi «è normale?». I laboratori del percorso Blue Team di PurpleDuel ti fanno ricostruire proprio questo tipo di storia dai log di un sistema simulato.