Il problema dei crawler che raccolgono testo per addestrare modelli AI si è trasformato per molti gestori di infrastrutture in una tassa permanente: consumo costante di risorse per produrre output utile solo a un modello. Il caso più dettagliato arriva da git.kernel.org, il servizio che serve i repository del kernel Linux: come racconta Konstantin Ryabitsev nel post Creepy Crawlies, 14-16 dei 90 core dei cinque nodi del servizio sono in ogni istante occupati a una cosa sola, trasformare commit git in pagine HTML per gli scraper.
In sintesi: non è un attacco DoS ma un drenaggio continuo di capacità. Puoi capire perché la storia del kernel attira i crawler, come è evoluta la corsa tra difese e bot e quali risultati hanno dato le contromisure; non puoi contare su una soluzione definitiva. Vediamo il contesto, la cronologia e i numeri.
Informazioni preliminari
git.kernel.org è l'interfaccia web, basata su cgit, con cui si consultano i repository del kernel Linux: cronologia dei commit, patch, plain render, diff tra commit arbitrari. L'autore del post, Konstantin Ryabitsev, fa parte delle persone che gestiscono l'infrastruttura di kernel.org e scrive a nome del servizio.
Per leggere non servono prerequisiti; se gestisci tu stesso servizi web, la familiarità con i log di accesso, fail2ban e robots.txt aiuta a collocare le contromisure descritte. Due definizioni utili:
- AI crawler: bot che navigano le pagine per raccogliere testo da usare come dati di addestramento. Nella descrizione della fonte non rispettano
robots.txte camuffano il proprio user-agent. - Anubis: proxy che, prima di servire una pagina, chiede al browser di risolvere un piccolo puzzle computazionale (proof-of-work).
Cosa è possibile: comprendere le dinamiche del fenomeno e replicare in parte le contromisure. Cosa non è possibile: dalla fonte non emerge alcuna soluzione risolutiva; l'autore stesso annuncia la rimozione di funzionalità per gli accessi anonimi.
Perché la storia di Linux è una miniera d'oro per l'addestramento
Lo sviluppo del kernel avviene in pubblico: repository clonabili e archivi di discussione consultabili in tempo reale. Per chi addestra un modello linguistico è un patrimonio doppio: i dati sono subito disponibili e sono filtrabili per garantire contenuto prodotto prima dell'era dei modelli generativi.
Il punto non è marginale: secondo l'autore, addestrare un modello su contenuti generati da modelli equivale a una "malattia da prioni digitale". Una fonte certamente pre-AI, come l'intera storia dei commit del kernel, vale quindi oro.
L'ironia è che su kernel.org quasi tutto è pensato per essere clonato: i repository, ma anche gli archivi della mailing list LKML, che puoi clonare per intero. Il modo efficiente di usare quei dati esiste ed è un git clone seguito dall'analisi locale della cronologia. I crawler non lo usano.
Il problema: miliardi di URL validi generati da cgit
La scelta più inefficiente, per usare le parole dell'autore, è renderizzare ogni commit come pagina HTML e poi fare il parsing del risultato. I numeri spiegano la portata del carico:
linux.gitcontiene circa 1,48 milioni di commit al momento della scrittura del post.- Su git.kernel.org esistono circa 922 fork di quel repository. Per il backend sono economici: la maggior parte degli oggetti è condivisa. Per uno scraper diventano miliardi di URL validi che restituiscono 922 copie degli stessi commit — ed è esattamente ciò che gli scraper stanno facendo.
- cgit espone anche patch, plain render e diff tra commit arbitrari: per un solo fork il numero di URL generabili diventa, come scherza l'autore, "1,2 metric bajillion".
Il risultato è ciò che Ryabitsev definisce una "radiazione di fondo" di carico: non un picco isolato, ma un consumo permanente di CPU per produrre pagine destinate a finire in un modello.
L'escalation delle contromisure
La cronologia del post è anche una lezione su cosa accade quando l'avversario ha risorse virtualmente illimitate.
Primo round: ban per user-agent, IP e ASN
All'inizio fail2ban bastava: i bot si dichiaravano nello user-agent. Poi hanno cominciato a fingere di essere browser comuni. Il comportamento, però, li tradiva comunque: un IP che richiede ogni commit di un fork abbandonato da otto anni non è un utente di Chrome su Windows. Quando i bot si sono distribuiti su intere subnet e su provider cloud, il passo successivo è stato bannare ASN interi (Google Compute è quello citato), accettando falsi positivi occasionali, come istanze legittime che automatizzano il controllo dei link nei commit.
Secondo round: IP residenziali e mobile
La risposta dei crawler è stata cambiare rete: milioni di IP residenziali o mobile, con user-agent da browser moderno, che fanno 4-5 richieste e spariscono. Bannarli è inutile, spiega l'autore: quando capisci che sono bot sono già andati, e il firewall si gonfia di regole per IP che non torneranno mai. Gli sciami arrivano a ondate, colpiscono fino a far cadere il sistema, passano al bersaglio successivo e tornano al recupero. La fonte inquadra il fenomeno come un business — la "monetizzazione via SDK proxy" — al punto che, secondo Ryabitsev, probabilmente lo fanno anche le TV connesse.
Terzo round: Anubis e il proof-of-work
La contromisura successiva inverte l'economia dell'attacco: far pagare ai bot un costo computazionale. Con Anubis, il browser deve calcolare quale stringa, combinata con il proprio IP e un segreto fornito dal server, produce un hash sha256 con un certo numero di zeri iniziali. Con difficoltà 4 l'effetto fu immediato: i bot rinunciavano e passavano a bersagli più facili, e per alcuni mesi fu pace. Quando hanno imparato a risolverla, la soglia è salita a 5 — qualche secondo di calcolo su un telefono, che tra l'altro si scalda — e ha retto ancora qualche mese. Oggi i bot risolvono anche la 5.
I numeri di oggi e cosa puoi fare concretamente
I dati correnti citati nel post: circa 6 milioni di richieste al giorno che chiedono commit casuali; il 66% viene respinto al volo dal challenge Anubis, il 33% risolve il calcolo e arriva al sito. Non è possibile dire con certezza quante di queste siano umane, ma con "assunzioni generose" il traffico legittimo è circa il 2% del totale. Sul piano della CPU: su 90 core complessivi, 14-16 lavorano in continuazione per gli scraper, in media il 20% della capacità — con picchi ben oltre la media, perché gli attacchi arrivano a ondate.
Curiosamente, il servizio resta reattivo. Ciò che di solito manda giù git.kernel.org non sono gli scraper ma i sistemi CI mal progettati, per esempio chi fa shallow clone di stable.git da venti nodi contemporaneamente. Il consiglio dell'autore a chi fa CI è netto: niente shallow clone massicci, e se servono operazioni pesanti, allestite un mirror vostro.
Cosa puoi fare:
- Se ti serve la storia del kernel, clona il repository e lavora in locale: è il metodo che i gestori preferiscono di gran lunga.
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gitti dà l'intera cronologia senza generare un solo rendering HTML. - Se gestisci un servizio pubblico, sappi che fail2ban, i ban ASN e Anubis funzionano, in quest'ordine, per periodi sempre più brevi; dalla fonte non emerge un'alternativa più duratura.
- Se accedi anonimamente a kernel.org, aspettati che qualche funzionalità scompaia: la riduzione delle superfici crawlabili è dichiarata e in corso.
Limiti, errori comuni e prospettive
Errori comuni da evitare: bannare IP residenziali dopo il fatto (inutile e costoso in regole di firewall); fidarsi di robots.txt con avversari che lo ignorano; dare per umano un traffico con user-agent da browser; per chi fa CI, lanciare shallow clone intensivi da molti nodi in parallelo.
Limiti di ciò che sappiamo: la stima del 2% di traffico umano si basa su assunzioni dichiarate generose e non è certa; dall'esterno non è verificabile quante delle richieste che superano Anubis siano umane; sui committenti dei proxy residenziali la fonte non ha certezze, si limita a descrivere il modello di business.
Sulle prospettive l'autore non promette nulla. Le strade indicate sono due e nessuna dipende da kernel.org: o la domanda di addestramento cala — mentre le aziende che offrono modelli AI custom, nota, spuntano ogni giorno — o chi consuma questi dati smette di farlo nel modo più inefficiente possibile. Nel frattempo il piano operativo è ridurre le superfici: meno URL generabili, gate sulle azioni costose, meno funzionalità per chi non si autentica. Per il dibattito, la segnalazione su Hacker News ha raccolto 394 punti al momento della rilevazione.
Lascia un commento