Bot e crawler che mangiano il server: come leggerli nei log e limitarli

Il comando da lanciare subito

Se il server è sotto sforzo e si sospetta un bot, la prima cosa da fare è contare le richieste per user agent nel log di accesso. Su un sistema con Nginx il percorso di default è logs/access.log, ma su Ubuntu e Debian si trova normalmente in /var/log/nginx/access.log, come indicato dalla documentazione ufficiale che spiega come l'access log sia situato per impostazione predefinita in logs/access.log, con il formato combined.

Per contare le richieste per indirizzo IP nell'ultima porzione di log:

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

Per contare per user agent (il campo dipende dal formato di log usato, nel formato combined lo user agent è l'ultimo campo tra virgolette):

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

Su cPanel i log grezzi per dominio si trovano nella cartella dei domlogs dell'account (percorso standard /usr/local/apache/domlogs/<utente>/<dominio>); su Plesk conviene passare dal pannello, sezione Siti web e domini > Log, perché il percorso fisico cambia a seconda della versione e della distribuzione scelta in fase di installazione. Chi non ha accesso diretto al filesystem può comunque scaricare il log dalla relativa sezione del pannello e lanciare lo stesso comando awk su un file locale.

Se in cima alla lista compare un indirizzo singolo con migliaia di richieste in pochi minuti, è quasi sempre un bot aggressivo o uno scraper, non traffico umano.

Le cause in ordine di frequenza

1. Crawler SEO o AI che indicizzano aggressivamente (Googlebot, Bingbot, GPTBot, Bytespider, ClaudeBot e simili), spesso con molte richieste in parallelo su URL con parametri diversi (filtri, paginazione, ricerca interna).
2. Scraper non dichiarati che falsificano lo user agent per sembrare un browser o un motore di ricerca noto, aggirando eventuali blocchi superficiali.
3. Bot cattivi che si spacciano per Googlebot nello user agent ma arrivano da reti che non appartengono a Google: è il caso più insidioso perché un blocco approssimativo basato solo sullo user agent non li ferma, e un blocco troppo aggressivo rischia di colpire anche il vero Googlebot.

Come distinguere un motore di ricerca vero da uno che si traveste

Lo user agent da solo non prova nulla: chiunque può scrivere "Googlebot" in una richiesta HTTP. Il metodo che Google stessa raccomanda nella propria documentazione per gli sviluppatori è la verifica incrociata DNS, in due passaggi.

Primo passaggio, lookup DNS inverso sull'indirizzo IP che compare nel log:

host 66.249.66.1

Se l'IP è davvero di Googlebot, il risultato deve essere un nome host che termina in googlebot.com, google.com o googleusercontent.com, secondo quanto riportato dalla documentazione Google che descrive come confermare se un nome di dominio è googlebot.com, google.com o googleusercontent.com dopo il lookup DNS inverso.

Secondo passaggio, lookup DNS diretto sul nome host ottenuto, per controllare che torni allo stesso IP di partenza:

host crawl-66-249-66-1.googlebot.com

Se il risultato non combacia con l'IP originale, o il primo lookup non restituisce affatto un nome in quei domini, la richiesta non è di Googlebot reale, indipendentemente da cosa dichiari lo User-Agent. Questa tecnica si chiama forward-confirmed reverse DNS ed è l'unico modo pubblicato da Google stessa per validare un suo crawler da riga di comando, senza bisogno di strumenti di terze parti.

Lo stesso principio vale per Bingbot (Microsoft pubblica i propri range IP) e per gli altri crawler dichiarati: se il nome host non torna a un dominio del gestore noto, è un impostore.

I tre modi di limitarli, in ordine di brutalità

1. Regole per i crawler (robots.txt)

È l'intervento più leggero e più educato: si chiede al crawler di rallentare o di non visitare certe sezioni. Va detto però che Google non supporta la direttiva crawl-delay: la documentazione ufficiale elenca i campi supportati da Google in robots.txt (user-agent, allow, disallow, sitemap) specificando che altri campi come crawl-delay non sono supportati. Quindi per Googlebot il crawl-delay in robots.txt è semplicemente ignorato: non serve a nulla scriverlo pensando di rallentare Google.

Funziona invece per altri crawler che lo rispettano (non tutti): un file robots.txt tipico per bloccare completamente l'accesso a un bot aggressivo e non prioritario è:

User-agent: Bytespider
Disallow: /

Questo blocca solo i bot che leggono e rispettano il file. Un bot malevolo o uno scraper che non segue le regole semplicemente lo ignora: per quelli serve il livello successivo.

2. Limite di frequenza sul server web (rate limiting)

Su Nginx il modulo ngx_http_limit_req_module permette di fissare un tetto di richieste al secondo per una data chiave, tipicamente l'indirizzo IP o lo user agent. Un esempio minimo, da inserire nel blocco http {}:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
 location / {
 limit_req zone=perip burst=20 nodelay;
 limit_req_status 429;
 }
}

Questo limita ogni singolo IP a 10 richieste al secondo, con un margine di 20 richieste in burst, restituendo codice 429 ("Too Many Requests") a chi supera la soglia.

Quando il traffico aggressivo arriva da un bot dichiarato ma distribuito su centinaia di IP diversi (capita con alcuni crawler di piattaforme pubblicitarie), limitare per IP non serve: bisogna raggruppare le richieste per user agent con una direttiva map, così tutte le richieste di quel bot condividono lo stesso contatore indipendentemente dall'IP di provenienza:

map $http_user_agent $limit_bot {
 default "";
 ~*GPTBot "gptbot";
}

limit_req_zone $limit_bot zone=gptbot:1m rate=10r/m;

location / {
 limit_req zone=gptbot burst=20;
 limit_req_status 429;
}

Su Apache l'equivalente è il modulo mod_ratelimit o, più spesso in ambienti cPanel/Plesk, una regola a livello di WAF (ModSecurity) o un limite imposto dal pannello stesso: conviene verificare nella documentazione del proprio pannello quale modulo è attivo prima di scrivere regole manuali, perché un conflitto tra due sistemi di rate limit può dare risultati imprevedibili.

3. Blocco totale

L'ultima risorsa, da usare solo quando i primi due livelli non bastano e l'IP è stato verificato come non appartenente a un crawler legittimo. Su Nginx, a livello di server o http:

deny 203.0.113.45;

Oppure per un intero blocco di rete:

deny 203.0.113.0/24;

Un blocco va sempre verificato dopo averlo applicato, lanciando una richiesta di prova dall'IP bloccato (o con curl --resolve da un altro host) e controllando che la risposta sia 403 o che la connessione cada, e non che il bot continui a passare perché la regola è in una posizione del file di configurazione che non viene letta per quella location.

Cosa non bloccare mai

Prima di bloccare un IP per nome di dominio ("sembra Googlebot"), va fatta sempre la verifica a due passaggi descritta sopra. Bloccare per errore il vero Googlebot, il vero Bingbot o altri crawler di motori di ricerca attivi significa smettere di essere indicizzati: il sito scompare gradualmente dai risultati di ricerca, con un danno che si vede settimane dopo, quando ormai è difficile da collegare alla causa. Nel dubbio, meglio applicare prima un rate limit morbido (burst alto, nodelay disattivato) piuttosto che un blocco secco, e osservare per un paio di giorni l'effetto sui log prima di stringere ulteriormente.

Se dopo aver applicato tutti e tre i livelli il carico resta alto, il problema potrebbe non essere il bot ma la generazione delle pagine stesse (query non ottimizzate, mancanza di cache): in quel caso vale la pena misurare il tempo di risposta del backend a monte del bot, perché è lì che si vede se è la pagina a essere lenta o il bot a essere troppo invadente.