Analisi dei log di Nginx: come riconoscere e bloccare le scansioni automatiche dei bot

Analisi dei log di Nginx: come riconoscere e bloccare le scansioni automatiche dei bot

Chiunque gestisca un server web esposto su Internet sa bene che, dopo pochi minuti dalla messa online, i file di log iniziano a riempirsi di richieste anomale. Bot automatizzati, script di scansione e crawler malevoli battono a tappeto gli indirizzi IP alla ricerca di configurazioni errate, file sensibili o punti d’accesso vulnerabili. Analizzare l’access.log di Nginx permette di osservare da vicino questo traffico invisibile, offrendo una panoramica concreta di come funzioni la ricognizione automatizzata sul web moderno.

Il rumore di fondo di Internet: cosa cercano i bot?

La maggior parte dei tentativi di accesso non è mirata a un sito specifico, ma rappresenta una scansione di massa guidata da script. Esaminando i log, le richieste si concentrano prevalentemente su due categorie di bersagli:

• File di configurazione e repository esposti: Richieste ricorrenti come /.env, /twilio/.env o /.git/config vengono lanciate alla ricerca di credenziali dimenticate, chiavi API o file di controllo di versione. Se un server è configurato male, questi file possono svelare dati critici in pochi secondi.
• Punti di accesso a CMS e pannelli di controllo: Tentativi ripetuti (sia in GET che in POST) verso percorsi standard come /wp-login.php fanno parte di campagne di forza bruta (brute-force) finalizzate a individuare la pagina di accesso di WordPress per testare combinazioni massive di username e password.

Analisi pratica: cosa dicono i log di Nginx

Per comprendere concretamente la natura di queste attività, basta osservare alcune righe estratte direttamente dall’access.log di un server in produzione. I log rivelano chiaramente le impronte digitali di questi scanner:

20.219.189.206 - - [13/Oct/2026:12:53:57 +0200] "GET /twilio/.env HTTP/1.1" 444 0 "-" "Mozilla/5.0..."
146.190.237.179 - - [13/Oct/2026:13:02:19 +0200] "GET /.git/config HTTP/1.1" 301 178 "-" "Mozilla/5.0..."
49.145.199.122 - - [13/Oct/2026:13:17:21 +0200] "GET /wp-login.php HTTP/1.1" 404 12420 "-" "Mozilla/5.0..."
162.241.203.107 - - [13/Oct/2026:13:43:13 +0200] "POST /wp-login.php HTTP/1.1" 404 14554 "-" "Mozilla/5.0..."

Analizzando i codici di risposta HTTP restituiti dal server, si nota l’efficacia delle difese applicate:

• Il codice 444 indica che Nginx ha troncato e chiuso immediatamente la connessione senza inviare alcuna risposta, bloccando alla radice i tentativi di probing sui file di configurazione sensibili.
• I codici 301 gestiscono i reindirizzamenti standard, mentre il codice 404 (Not Found) neutralizza i tentativi di accesso a endpoint amministrativi predefiniti (come /wp-login.php), i quali risultano inesistenti poiché protetti o ricollocati altrove, restituendo un vicolo cieco immediato agli script automatici.

Ispezionare i log dal terminale

Per verificare direttamente sul proprio server Ubuntu se siano in corso scansioni di bot o tentativi di intrusione, è possibile utilizzare alcuni comandi rapidi basati su strumenti standard come awk e grep.

Per estrarre l’elenco dei tentativi di accesso mirati a file sensibili e percorsi di login all’interno del file di log di Nginx, si può eseguire:

grep -iE '\.(env|git|bak|sql|zip)|phpmyadmin|wp-login' /var/log/nginx/access.log | tail -n 20

Se invece si desidera analizzare quali User-Agent o bot automatizzati stanno generando traffico verso il server, ordinandoli per frequenza, il comando seguente elabora il file di log filtrando i principali crawler:

awk -F\" '{print $6}' /var/log/nginx/access.log | sort | grep -iE 'bot|crawl|spider|slurp|seek|archiver' | uniq -c | sort -nr | head -n 20

Le contromisure a livello di server e applicativo

La sicurezza di un’infrastruttura non si basa sull’illusione di poter fermare le scansioni — che continueranno inevitabilmente ad arrivare —, ma sulla resilienza del sistema nel renderle inefficaci.

A livello di server web, l’utilizzo di codici di risposta mirati e regole di blocco impedisce agli scanner di raccogliere informazioni utili. Analogamente, la protezione dei CMS attraverso la modifica dei percorsi di autenticazione trasforma un attacco mirato in un’operazione a costo zero per il sistema: quando un bot invia una richiesta a un endpoint inesistente e riceve un errore immediato, l’azione si esaurisce all’istante senza consumare risorse di calcolo critiche.

Conclusioni

Monitorare periodicamente i log di accesso di Nginx non è soltanto un esercizio di manutenzione preventiva, ma un ottimo modo per comprendere le minacce che ogni giorno colpiscono l’infrastruttura di rete. Una configurazione solida, unita alla consapevolezza dei comportamenti dei bot, permette di mantenere il server tranquillo e sicuro, riducendo al minimo la superficie di attacco esposta.