Quando i robot prendono d’assalto una wiki: come abbiamo protetto Wikitrek dai bot AI

Il problema: la wiki era diventata lentissima

Da qualche mese, chi visitava Wikitrek si trovava davanti a pagine che impiegavano anche un minuto intero per caricarsi — quando si caricavano. Molti vedevano direttamente un messaggio di errore: “La connessione ha impiegato troppo tempo.”

Il server non era rotto. Stava semplicemente annegando sotto una valanga di richieste automatiche — migliaia al minuto — provenienti da bot di intelligenza artificiale che scansionavano il sito alla ricerca di testo da usare per addestrare i loro modelli.

Non era un attacco nel senso tradizionale del termine: nessuno voleva danneggiare Wikitrek. Semplicemente, questi programmi automatici non si curano del carico che generano sui server che visitano. Raccolgono dati, e basta.

Chi erano questi visitatori indesiderati?

Analizzando i log del server (una sorta di registro di tutte le visite ricevute), abbiamo scoperto un panorama impressionante:

• newsai/1.0 — uno scraper cinese che si spacciava per un browser normale, colpendo migliaia di pagine al giorno
• Amazonbot, Bytespider — bot di Amazon e ByteDance (la società dietro TikTok) che raccolgono dati per i loro sistemi AI
• MJ12bot, SemrushBot, AhrefsBot — strumenti SEO commerciali estremamente aggressivi
• meta-externalagent — il crawler di Facebook/Meta, responsabile da solo di oltre 100.000 richieste in una singola giornata
• Decine di altri bot anonimi provenienti da reti IPv6 cinesi

In totale, nelle giornate peggiori, il server riceveva quasi 900.000 richieste al giorno. Per un wiki di nicchia come Wikitrek, è come se uno stadio intero cercasse di entrare contemporaneamente da una porta singola.

Perché certi bot fanno così tanto danno?

MediaWiki — il software su cui gira Wikitrek, lo stesso di Wikipedia — ha alcune pagine speciali che sono computazionalmente molto costose. Per esempio:

• Speciale:ModificheCorrelate — mostra tutte le modifiche recenti collegate a una pagina
• Speciale:PuntanoQui — mostra tutte le pagine che puntano a una determinata voce

Ogni volta che qualcuno visita queste pagine, il server deve eseguire una query molto pesante sul database. Per un utente umano che ci capita una volta ogni tanto, non è un problema. Ma quando un bot le visita 500 volte al minuto, il database va in ginocchio — e con lui l’intero sito.

La soluzione: Anubis, il guardiano della wiki

Abbiamo installato Anubis, un software open source progettato esattamente per questo problema. Il nome è ispirato al dio egizio guardiano dei defunti — in questo caso, è il guardiano del nostro server.

Anubis si posiziona davanti al sito come un buttafuori digitale. Ogni visitatore — umano o robot — deve passare per lui prima di poter accedere al wiki.

🌐 Visitatore  →  🛡️ Anubis (controllo)  →  📖 Wiki

Il flusso del traffico con Anubis attivo

Come fa Anubis a distinguere un essere umano da un bot? Attraverso una prova di lavoro (proof of work): chiede al browser di risolvere un piccolo problema matematico. I browser normali lo risolvono in meno di un secondo tramite JavaScript, senza che l’utente se ne accorga. I bot — che di solito non eseguono JavaScript — non riescono a risolverlo e vengono bloccati.

Per i bot più pericolosi e conosciuti, Anubis non si preoccupa nemmeno di fare la sfida: li blocca direttamente, senza nemmeno rispondere.

Il problema dei bot “furbi”

Alcuni bot sono più sofisticati e riescono a superare la sfida di Anubis. Una volta ottenuto il permesso, lo conservano per sette giorni — e durante questo periodo possono fare quante richieste vogliono senza essere fermati di nuovo.

Per questo abbiamo adottato una strategia a più livelli:

1. Anubis blocca i bot noti prima ancora che raggiungano la wiki
2. Apache (il server web) controlla se chi arriva ha un cookie di sessione valido — cioè se si è autenticato come utente reale. Se non ce l’ha e sta cercando di accedere a una pagina costosa, riceve un rifiuto immediato senza nemmeno avviare il database
3. MediaWiki stesso reindirizza alla pagina di login chi cerca di accedere a queste pagine senza essere autenticato

In questo modo, anche un bot che fosse riuscito a superare tutti i controlli precedenti troverebbe davanti a sé solo un semplice messaggio “effettua il login” — nessuna query pesante sul database, nessun rallentamento per gli altri utenti.

La rotazione delle chiavi: azzerare i permessi accumulati

Quando ci rendevamo conto che troppi bot avevano accumulato permessi validi e stavano di nuovo rallentando il sito, avevamo un’arma segreta: la rotazione della chiave crittografica.

Anubis firma ogni permesso che concede con una chiave segreta. Cambiando quella chiave, tutti i permessi precedenti diventano istantaneamente invalidi — come se cambiassimo la serratura della porta. Tutti i visitatori, umani e bot, devono ricominciare da capo. Gli utenti umani risolvono la sfida in un secondo e riprendono a navigare; i bot restano fuori.

I risultati

Dopo alcune settimane di lavoro e perfezionamento della configurazione, i risultati sono stati notevoli:

• Il carico del server è sceso da picchi di 30-40 (un valore che indica uno stress estremo) a una media stabile di 1-2
• I tempi di caricamento delle pagine sono tornati a circa 1 secondo per le pagine già visitate di recente
• Anubis blocca mediamente oltre 100.000 richieste di bot al giorno
• Il server è rimasto stabile e accessibile senza interruzioni nelle ultime due settimane

Ma i bot AI possono ancora visitare Wikitrek?

Sì — e questa è stata una scelta deliberata. Non siamo contrari all’indicizzazione dei nostri contenuti da parte di sistemi AI, purché avvenga in modo rispettoso.

Per i bot che seguono le regole — come ClaudeBot di Anthropic, GPTBot di OpenAI e i principali motori di ricerca — abbiamo configurato il file robots.txt con una direttiva di Crawl-delay: possono visitare il sito, ma devono aspettare almeno 30 secondi tra una richiesta e l’altra. È come dire “sei il benvenuto, ma cammina, non correre.”

I bot che ignorano queste indicazioni, o che si spacciano per browser normali per eludere i controlli, vengono bloccati senza esitazione.

Una nota tecnica: cosa abbiamo imparato

Questa esperienza ci ha insegnato alcune cose importanti sulla gestione di un wiki pubblico nell’era dell’AI:

• I bot AI moderni sono molto più aggressivi dei tradizionali crawler dei motori di ricerca
• Un singolo dettaglio di configurazione sbagliato — nel nostro caso, una lettera maiuscola in un’intestazione HTTP — può causare rallentamenti gravissimi senza alcun messaggio di errore visibile
• La difesa efficace richiede più livelli: non basta un singolo strumento
• Le pagine “costose” di MediaWiki sono un tallone d’Achille specifico che vale la pena proteggere esplicitamente

Grazie

Un ringraziamento va agli sviluppatori di Anubis, uno strumento open source eccellente che ha reso possibile gran parte di questa soluzione.

Se gestite un wiki o un sito basato su MediaWiki e avete problemi simili, molte delle soluzioni descritte in questo articolo sono applicabili anche al vostro caso. Scriveteci pure.