Creepy Crawlies — Konstantin Ryabitsev
TL;DR: We besteden meer CPU-cycli aan het renderen van commits voor scrapers dan aan alle andere vormen van legitieme toegang, inclusief git-clones. Op elk willekeurig moment zijn er, verspreid over vijf geografisch gedistribueerde nodes, 14 CPU-cores die niets anders doen dan git-commits als HTML renderen.
Waarom git.kernel.org "interessant" is voor crawlers
De ontwikkeling van Linux gebeurt in het openbaar — van git-repositories die je kunt clonen tot discussiearchieven die je in realtime kunt volgen. Voor een groot taalmodel (LLM) is dit een goudmijn aan trainingsdata, omdat dit niet alleen direct beschikbaar is, maar ook gemakkelijk te filteren is om pure, pre-AI-inhoud te garanderen.
Het trainen van een LLM op inhoud die door een LLM is geproduceerd, veroorzaakt het digitale equivalent van een prionziekte. Wanneer een bron daarom gegarandeerd vrij is van LLM-inhoud, zoals de volledige geschiedenis van kernel-commits, is deze goud waard als trainingsbron.
De domste manier van dataverzameling
We maken bijna alles clonebaar. We moedigen mensen aan om de repositories en archieven te clonen, zodat we niet de enigen zijn die alles bezitten. Het is immers maar een git clone verwijderd van de volledige geschiedenis. Je kunt bijvoorbeeld de gehele LKML clonen en daar vervolgens mee doen wat je wilt; het is tot in de kleinste details opgebouwd uit git-repositories.
Je zou denken dat iets dat zich voordoet als "Kunstmatige Intelligentie" de meest efficiënte manier zou kiezen om onze data te gebruiken voor trainingsdoeleinden: de repositories clonen en elke commit doorlopen. Klaar.
Maar nee, er wordt gekozen voor de domst mogelijke methode: alles commit voor commit als HTML renderen en deze vervolgens parsen.
Op het moment van schrijven bevat linux.git ongeveer 1,48 miljoen commits. Daarnaast hebben we ongeveer 922 forks hiervan op git.kernel.org. Aan de backend is dit zeer efficiënt, omdat het in elke fork grotendeels om dezelfde objecten gaat. Tenzij je een scraper bent. In dat geval zijn er miljarden geldige URL's te scrapen, om vervolgens 922 duplicaten van dezelfde 1,48 miljoen commits te verkrijgen — en dat is precies wat de scrapers doen.
Bovendien gaat het niet alleen om de commits zelf. Je kunt ook vragen om patches, eenvoudige renders en diffs tussen willekeurige commits. cgit staat dit graag toe, wat perfect was in de tijd dat het internet bedoeld was voor mensen of crawlers die zich aan robots.txt hielden. Nu is het echter verschrikkelijk, omdat we voor één enkele fork van linux.git miljarden geldige URL's kunnen genereren.
Pogingen tot blokkering
In eerste instantie was de oplossing simpel: de logs doorzoeken, de IP-adressen van overduidelijke scraper-bots identificeren en deze via fail2ban blokkeren. In het begin was dit eenvoudig, omdat de bots via hun user-agent vriendelijk aangaven wie ze waren. Later werden ze slimmer en begonnen ze zich voor te doen als gewone browsers.
Daarna zijn we overgestapt op het blokkeren van IP-adressen. Het is immers makkelijk in te zien dat een IP-adres dat elke mogelijke commit in een acht jaar oude, verlaten fork van Linux probeert op te halen, niet echt een individuele Chrome-gebruiker op Windows is die koortsachtig op elke link klikt.
De bots begonnen vervolgens uit te waaieren over volledige subnets. Dit was nog steeds beheersbaar, want een IP-adres dat afkomstig is van Google Compute doet waarschijnlijk alleen maar alsof het een Firefox-gebruiker is. Het blokkeren van het gehele ASN was gerechtvaardigd, zelfs als dit af en toe een legitieme instantie raakte die probeerde links in commits te automatiseren.
De rol van consumentenapparaten
En toen werd het echt lelijk. Plotseling kwamen de crawlers van miljoenen willekeurige residentiële of mobiele IP-adressen, die zich allemaal voordeden als moderne browsers. Zo'n IP-adres maakte vier of vijf verzoeken en verscheen daarna nooit meer in de logs. Blokkeren had geen zin; tegen de tijd dat je wist dat het bots waren, waren ze al klaar met je. Je vergrootte alleen maar onnodig je firewall-regels met IP's die nooit meer terug zouden komen.
Ze daalden neer als zwermen sprinkhanen: hard en snel toeslaan tot het systeem bezweek, en dan doorgaan naar het volgende doel totdat het systeem hersteld was. Daarna keerden ze terug.
Dit gebeurt nog steeds — welkom in de wonderlijke wereld van "proxy SDK monetization". Het is een grote business, en de kans is groot dat jouw televisie hieraan meedoet.
De kosten verhogen
Toen dit ongeveer een jaar geleden een probleem werd, dachten we naïef dat er een manier was om het te stoppen. We wilden de bots een taak laten uitvoeren die de economie van de operatie volledig op zijn kop zou zetten, door ze CPU-cycli te laten verspillen aan zinloze berekeningen. Bijvoorbeeld: bereken welke string, in combinatie met hun eigen IP en een door ons verstrekt geheim, een sha256-som zou genereren met vier leidende nullen.
In andere woorden: we plaatsten Anubis voor alles.
Dit was onmiddellijk extreem effectief — de bots gaven het simpelweg op. Een paar maanden lang was er rust: bots werden aan de perimeter geblokkeerd en trokken verder naar makkelijkere doelen; de gebruikers waren mild geïrriteerd maar tolereerden het, en de Anubis-stack was eenvoudig overal uit te rollen.
Een paar maanden later waren de bots terug en losten ze moeilijkheidsgraad 4 op. We verhoogden de moeilijkheidsgraad naar 5. De legitieme gebruikers waren nu meer geïrriteerd, want moeilijkheidsgraad 5 duurt enkele seconden om op te lossen op een mobiel apparaat, waarbij de telefoon ongemakkelijk warm wordt. Toch was het effectief en kocht het ons nog enkele maanden rust.
Daarna begonnen de bots ook moeilijkheidsgraad 5 op te lossen.
De huidige situatie
Tegenwoordig ontvangt git.kernel.org ongeveer 6 miljoen dagelijkse verzoeken om willekeurige commits in te zien. Hiervan worden 66% direct afgewezen door de Anubis-challenge, maar 33% lost de rekensom nu op en bereikt de hoofdsite. Blijkbaar is wat we te bieden hebben het waard om een enorme hoeveelheid cycli aan de Anubis-challenge te besteden.
Het is onmogelijk om met zekerheid te zeggen welke van deze verzoeken van bots komen en welke van echte mensen — maar de kans is groot dat als er wordt gevraagd naar een oude commit in een willekeurige oude fork, dit geen echte ontwikkelaar is die zijn werk probeert te doen.
Uitgaande van royale aannames is slechts ongeveer 2% van het verkeer op git.kernel.org legitiem — de rest zijn scrapers.
Hoe erg is het?
Op dit moment zijn we nog niet volledig overweldigd; als je git.kernel.org bezoekt, is de site waarschijnlijk nog steeds vlot en responsief. Wat ons meestal platlegt zijn niet de scraper-bots, maar slecht ontworpen CI-systemen die iets stoms proberen te doen, zoals het gelijktijdig uitvoeren van shallow-clones van stable.git vanaf 20 verschillende nodes. (Shallow clones zijn verschrikkelijk. Draai je eigen mirror als je zoiets nasts wilt doen.)
Toch moet je weten dat van de in totaal 90 cores over vijf geografisch gedistribueerde nodes, er 14 tot 16 cores constant niets anders doen dan commits renderen voor scrapers. Gemiddeld is dat 20% van onze totale capaciteit — al komt dit in golven, waardoor de werkelijke grafiek veel grilliger is dan een vlakke lijn van 20%.
Conclusie
Het is onduidelijk waar dit heen gaat. Misschien knapt de AI-bubbel en zijn er plotseling veel minder entiteiten die hun modellen willen trainen. Alternatief worden ze misschien slimmer en stoppen ze met het consumeren van onze data op de domste manier mogelijk.
Wat ons betreft: we schakelen bepaalde functies uit om het aantal crawlbare URL's te verminderen en we plaatsen beperkingen op acties die voor ons duur zijn om uit te voeren. Houd rekening met het verlies van functionaliteit, althans bij anonieme toegang tot onze resources. Geloof me, we haten dit net zoveel als jullie, maar op dit punt is het een noodzaak.
Het ergste is dat er geen eenvoudige oplossingen zijn. Bedrijven die custom "AI"-modellen aanbieden, verschijnen dagelijks, allemaal hongerig naar trainingsdata. App-makers zoeken nog steeds naar manieren om winst te maken, dus ze zullen je huishoudelijke apparaten blijven omvormen tot aanvalsvectoren.
Dat gezegd hebbende, we beloven al onze data beschikbaar te blijven stellen voor download voor iedereen die daarom vraagt. Je zult alleen misschien door meer hoepels moeten springen om het te krijgen.
Sorry. (Een verplicht Canadees ding om te zeggen.)
Groetjes,