- AI-Scraper-Traffic belastet Kosten und Stabilität öffentlicher Wikis; ohne Gegenmaßnahmen kann er etwa 10-mal mehr Rechenressourcen verbrauchen als die gesamte menschliche Aktivität zusammen
- Bots tarnen ihre Header nicht mehr nur mit identifizierbaren User-Agents wie GPTBot, sondern geben sich als aktuelles Chrome aus und umgehen Sperren über Residential Proxies mit täglich bis zu 1 Million rotierenden IPs
- Wikis stellen weit mehr URLs bereit als nur Artikel, darunter alte Versionen, Bearbeitungsansichten und Spezialseiten; naives Crawling umgeht Caches und kann 50- bis 100-mal teurer sein als normale Anfragen
- Cloudflare Challenge, Anubis, manuelle Firewall-Regeln und Erkennung auf Basis von menschlichen Verhaltenssignalen helfen, verursachen aber auch False Positives, Wartungsaufwand und Reibung für Leser
- Extreme Sperrmaßnahmen wie Login-Zwang oder globale Challenges können neue Beiträge verringern; nötig sind öffentliche Diskussionen unter Betreibern und API-Zugänge, die die Anreize für Bot-Sammlung verändern
Die Belastung von Wikis durch AI-Scraper
- Bot-Scraping für LLM-Trainingsdaten nimmt in beispiellosem Ausmaß zu und erschüttert die Kostenstruktur und Stabilität öffentlicher Websites: Das Thema wurde auch in FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline? und Smart TV web crawler AI behandelt
- Weird Gloop hostet große Gaming-Wikis wie Minecraft Wiki, OSRS Wiki und League Wiki und verbringt in den letzten drei Jahren zunehmend mehr Zeit mit der Abwehr von Bot-Traffic
- Ohne laufende Gegenmaßnahmen können Bots etwa 10-mal mehr Rechenressourcen verbrauchen als der gesamte übrige Traffic zusammen, einschließlich zig Millionen menschlicher Pageviews und zehntausender Bearbeitungen pro Tag
- Auch die Wikimedia Foundation veröffentlichte einen Beitrag über die Auswirkungen von Crawlern auf den Betrieb; große Wiki-Farmen hatten Ausfälle in unterschiedlichem Ausmaß, und einige kleine unabhängige Wikis gingen komplett offline
- Schätzungsweise waren in diesem Jahr etwa 95 % der Serverprobleme im Wiki-Ökosystem auf schlechte Scraper zurückzuführen
Scraper, die wie Menschen aussehen wollen
- Die „offiziellen“ Bots großer AI-Unternehmen wie GPTBot, ClaudeBot und PerplexityBot haben robots.txt zwar nicht immer eingehalten, lassen sich aber normalerweise über den User-Agent-String erkennen und daher relativ einfach über Cloudflares AI-Bot-Blockierung oder nginx sperren
- Seit Webmaster begonnen haben, AI-Scraper anhand des User-Agents zu blockieren, haben Bots einen starken Anreiz, sich als menschlicher Traffic zu tarnen
- Der Großteil des AI-Scraper-Traffics, der Wikis in letzter Zeit erreicht, sendet Header, die wie aktuelles Google Chrome aussehen, und baut Anfragen sehr ausgefeilt auf
- Die früher klaren Signale für „Bot oder echter Mensch“ sind verschwunden, was das Blockieren erschwert
Zig Millionen IPs und Umgehung per Proxy
- Vor 2023 kamen 95 % des problematischen Scrapings von einzelnen IP-Adressen oder kleinen Rechenzentrums-Subnetzen, sodass Sperren auf Basis von IP oder ISP-Merkmalen meist wirksam waren
- Mit Residential Proxies lassen sich Scraping-Anfragen allein mit einer Kreditkarte über Netzwerke aus Millionen von IP-Adressen waschen
- Wikis sehen teils Scraper-Läufe mit 1 Million IPs pro Tag, die wie legitime Anfragen von Residential-ISPs wie Comcast, AT&T oder Charter wirken
- Die betroffenen Kunden wissen wahrscheinlich nicht, dass ihre IP als Exit-Node eines Residential Proxy genutzt wird
- Manche Angreifer missbrauchen facebookexternalhit-Link-Vorschauen oder Google Translate, damit Anfragen aussehen, als kämen sie von Google- oder Facebook-Servern, und verschleiern so die eigentliche Herkunft
- In manchen Fällen waren 99,99 % der Anfragen über das Google-Translate-URL-Tool missbräuchlich, sodass es zeitweise auf allen Wikis kaputtgemacht werden musste
Besonders teures Crawling „dummer URLs“ bei Wikis
- Viele AI-Scraper wählen URLs, indem sie die Wiki-Startseite besuchen, dann allen Links auf dieser Seite folgen und anschließend wieder allen Links auf den Folgeseiten
- Obwohl robots.txt und Sitemaps klar zeigen, welche URLs für Scraping wertvoll sind, scheint das oft ignoriert zu werden
- Das OSRS Wiki hat etwa 40.000 Artikel, und diese URLs enthalten den Großteil der nützlichen Informationen der Seite
- Rechnet man aber alte Versionen, Bearbeitungsansichten und Spezialseiten hinzu, gibt es mindestens 1 Milliarde erkundbare URLs
- Dieses naive Crawling endet nie und verbraucht offenbar viele Ressourcen für URLs, die als LLM-Trainingsdaten kaum nützlich sind
- Solche merkwürdigen Anfragen umgehen Cache-Schichten wie den MediaWiki parser cache, den echte Benutzeranfragen nutzen, und treiben so die Betriebskosten hoch
- Cache-Treffer sind normalerweise in unter 20 Millisekunden verarbeitet, während Anfragen wie alte Diffs oft 1–2 Sekunden brauchen
- Oberflächenmetriken wie „8 Millionen Bot-Anfragen pro Tag“ oder „Bots nutzen 65 % der Bandbreite“ unterschätzen das Problem
- Der eigentliche Flaschenhals ist meist CPU-Kapazität, und Bot-Anfragen mit seltsamen Query-Parametern sind bei den Verarbeitungskosten oft 50- bis 100-mal teurer als normale Requests
Traffic-Spitzen, die in Durchschnittswerten unsichtbar bleiben
- Die monatlichen Bot-Anfragen liegen bei rund 250 Millionen, im Schnitt also etwa 100 Requests pro Sekunde, aber das ist nur ein Langzeitdurchschnitt
- Scraper schicken häufig für kurze Zeiträume mehr als 1.000 Requests pro Sekunde und sind damit von klassischen DDoS-Angriffen kaum zu unterscheiden
- Selbst wenn Bots langfristig nur etwa 50 % der gesamten CPU-Nutzung ausmachen, verursachen bösartige Traffic-Spitzen etwa 95 % der Verlangsamungen und Ausfälle von Wikis
Eine Struktur, bei der schwer erkennbar ist, wer dahintersteckt
- Obwohl der Traffic als „AI-Scraper“ bezeichnet wird, ist schwer festzustellen, wer tatsächlich verantwortlich ist oder wofür die Wikidaten verwendet werden, weil sich alle als Google Chrome tarnen
- Mögliche Akteure reichen von Datenbrokern über redundante Sammlungen von Frontier Labs bis zu unabhängigen Projekten mit Zugang zu Residential Proxies
- Auch wie niedrig die Einstiegshürden inzwischen wirklich sind, ist unklar
- Wenn es bessere Wege gäbe, würde man die tatsächlichen Sammler gern direkt kontaktieren, um weniger ineffiziente Methoden zu finden
Was bisher wirksam war
-
Cloudflare Challenge und Anubis
- Websites hinter eine Cloudflare Challenge oder Werkzeuge wie Anubis zu stellen, ist im letzten Jahr im Internet weit verbreitet worden
- Bis zu einem gewissen Grad wirkt das, aber es gibt Phasen, in denen manche Bots die Challenges konstant bestehen
- Zwischen Cloudflare und Bot-Entwicklern scheint ein unsichtbares Wettrüsten stattzufinden; Cloudflare gewinnt etwa 90 % der Zeit, aber die restlichen 10 % sind operativ schmerzhaft
- Echte Leser mögen es nicht, vor dem Erreichen eines Wikis erst eine Challenge zu sehen
- Um die meisten Menschen nicht zu beeinträchtigen, braucht es gute heuristische Regeln dafür, welcher Traffic überhaupt mit einer Challenge belegt werden soll, aber gerade die zuverlässige Erkennung automatisierten Traffics ist schwierig
-
Manuelle Firewall-Regeln
- Die meisten Betreiber haben manuelle Firewall-Regeln, die auf ihre eigene Infrastruktur und frühere Angriffe zugeschnitten sind
- Solche Filter basieren meist auf bestimmten User-Agent-Strings, IP-Gruppen oder ASNs
- Weird Gloop erledigt das meiste auf Ebene von Cloudflare/CDN, andere Wikis setzen dagegen auf nginx oder den Webserver selbst
- Inzwischen reichen User-Agent und IP oft nicht mehr aus; betrachtet werden müssen komplexere Anfragemerkmale wie HTTP-Version, Header, TLS-Cipher oder mit ja4 verbundene Hashes
-
Nach Dingen suchen, die „Menschen tun, Bots aber nicht“
- Ein nützlicher Ansatz ist, kollektive Verhaltensmuster von Menschen zu finden, die Bots nicht zeigen
- In MediaWiki-basierten Wikis erzeugen echte Browser-Nutzer beim Verwenden des Wikis mehrere Typen von HTTP-Anfragen, die Bots meist nicht erzeugen
- Wenn ein per Headern, ja4-Hash usw. abgrenzbarer Traffic-Block viele Artikel besucht, aber keine typischen „menschlichen“ Requests erzeugt, ist das ein starkes Signal dafür, auf diesen Traffic eine Challenge anzuwenden
- Der Blick auf fehlende menschliche Verhaltensanfragen im Bot-Traffic ist sehr wirkungsvoll
- Es wurde begonnen, ein System zu bauen, das durch Analyse des „fehlenden“ Traffics automatisch entscheidungsbaumartige Heuristiken vorschlägt, welche Requests gechallengt werden sollten
- In Tests schien das fast alle Scraper gut zu erkennen, aber welche False Positives bei Menschen mit ungewöhnlichen Surfgewohnheiten entstehen könnten, etwa NoScript-Nutzern, Screenreader-Nutzern oder Leuten mit unerwarteten Geräten, ist noch unklar
- Auch der Aufbau und dauerhafte Betrieb einer eigenen ML-/Datenanalyse-Infrastruktur bleibt belastend
-
Exotischere Erkennungsmethoden
- Es gab erfolgreiche Fälle, in denen TCP/TLS-Timing-Abweichungen genutzt wurden, um Residential Proxies zu identifizieren
- Es gibt auch Firmen, die Echtzeit-Datenbanken von Residential-Proxy-IPs verkaufen
- Allerdings werden die meisten Residential Proxies gleichzeitig auch von echten Menschen genutzt, weshalb unklar ist, wie gut sich das als praktikables Blockiersignal eignet
- Akteure wie Cloudflare oder große Cloud-Anbieter mit Paketdaten auf Netzwerkebene aus riesigen Traffic-Mengen scheinen grundsätzlich in der Lage zu sein, in großem Maßstab gute Heuristiken zu entwickeln
- Trotzdem ist noch kein Betreiber bekannt, der von den Heuristiken kommerzieller Produkte wirklich beeindruckt war, einschließlich kommerzieller Bot-Erkennungslösungen mit jährlichen Kosten im sechsstelligen Bereich
Schlechte extreme Optionen für Leser
- Die „nukleare Option“ gegen AI-Scraper ist für echte Nutzer deutlich zerstörerischer
- Eine verbreitete Methode ist, für Seiten mit potenziell hohen Erzeugungskosten einen Login zu verlangen
- Fandom hat vor einigen Monaten eine solche Maßnahme auf alle Wikis angewendet
- Eine andere Methode ist, sämtlichen Traffic mit einer Cloudflare Challenge zu belegen
- Aus Sicht von Webmastern ist das nachvollziehbar, aber für die langfristige Gesundheit von Wikis und Communities schlecht
- Eine zentrale Lehre aus 16 Jahren Wiki-Community-Aufbau ist, dass der beste Weg, neue Mitwirkende zu gewinnen, im Abbau von Reibung liegt
- Bearbeiten muss einfacher werden, die interne Wiki-Struktur leichter erkundbar, und die Einstiegshürde zwischen Lesern und Editoren muss sinken
- Extreme Anti-Bot-Techniken schaffen neue Reibung und führen zu vorhersehbaren Ergebnissen
- Nachdem Fandom für über 95 % der Leser ohne Konto die „internen Seiten“ versteckt hatte, gingen die Beiträge neuer Nutzer auf Fandom insgesamt offenbar um etwa 40 % zurück
- Es ist schwer, diesen Trade-off für lohnenswert zu halten
Der Weg nach vorn
- Weird Gloop hostet weiterhin Wikis und hilft auch weiterhin Wikis, die Fandom verlassen wollen
- Langfristig könnten „AI Overviews“ die Pipeline zerstören, über die Wiki-Leser zu Wiki-Beitragenden werden, aber das bleibt hier ein separates Problem
- Einige Bekannte meinen, die Bot-Welle könnte für Weird Gloop sogar vorteilhaft sein, doch wenn Menschen nicht mehr leicht Wikis hosten können, wird das Internet schlechter
- Ein Szenario, in dem stabiles Wiki-Hosting On-Call-Rotationen, ML-Ingenieure und Enterprise-Produkte voraussetzt, wäre sehr schlechte Nachricht für unabhängige Wiki-Communities
- Das Wettrüsten zwischen Bot-Betreibern und Webmastern dürfte weitergehen, bis kluge Wege gefunden werden, die strukturellen Anreize des Scrapings zu verändern
- Cloudflares neue crawling API könnte die Lage verändern, wenn es für Bots einfacher wird, eine API zu nutzen, statt eigene Systeme zu bauen, die robots.txt ignorieren und Probleme verursachen
- Es wäre besser, wenn Scraping gar nicht erst stattfände, aber das bereits Geschehene lässt sich nur schwer rückgängig machen
Bedarf an öffentlicher Diskussion und Zusammenarbeit
- Tausende Betreiber betreiben jeweils ihre eigenen Websites und suchen nach klügeren Techniken, um mit Bots umzugehen
- In privaten Gesprächen mit anderen Systemadministratoren gab es konkrete und gute Ideen, und es dürfte auch in Slack, Discord und kleinen Gruppen viele Diskussionen geben
- Es braucht mehr öffentliche Diskussionen über die konkreten Details des realen Betriebs
- Viele Systemadministratoren wissen nicht ausreichend, dass ihre Probleme fast identisch mit denen anderer Betreiber sind
- Nicht alle wollen ihre eigenen Abwehrmethoden offenlegen, und es gibt auch die Sorge, durch Öffentlichkeit einen Vorsprung zu verlieren
- Trotzdem lohnt es sich vermutlich, dieses Risiko einer sinkenden Wirksamkeit mancher Taktiken einzugehen, wenn dadurch mehr Menschen gemeinsam nachdenken
- Systemadministratoren, die AI-Scraper behandeln, sollten in den für sie passenden Räumen teilen, was tatsächlich funktioniert hat
- Firmen, die Produkte zur Lösung des Bot-Problems verkaufen, sollten mehr Fallstudien mit realen Daten zu Precision und Recall unter nicht künstlichen Bedingungen veröffentlichen
- Für Menschen, die Kaufentscheidungen treffen, zählen nicht Checkboxen, sondern echte Ergebnisse
- Wer ein Wiki oder eine unabhängige Website betreibt und über Bot-Erkennung sprechen möchte, kann sich per E-Mail oder Discord-Nachricht melden
2 Kommentare
Im Grunde bekommt auch GeekNews extrem viele Crawler-Besuche, deshalb führen wir verschiedene Methoden ein, um sie zu blockieren und die Kosten zu optimieren. Die chinesischen AI-Bots crawlen wirklich in einem enorm ernsten Ausmaß.
Allerdings ist es auch ein Problem, dass beim Blockieren auf der CDN-Seite wiederum Kosten entstehen.
Lobste.rs-Kommentare
Ich habe versucht, die Schwächen von Anubis mit einer Proof-of-Wait-Challenge zu ergänzen, und das war ziemlich effektiv.
Im Grunde wird der Filter deaktiviert, solange die globale Request-Rate unter einem Schwellenwert liegt; wird er überschritten, muss der Nutzer N Sekunden warten, bevor er fortfahren kann.
Danach wird ein an diese IP gebundener Token ausgestellt, der bis zum Ablauf nur eine kleine Anzahl von Requests erlaubt, und auch der Token selbst ist rate-limitiert.
Wenn weiterhin erfolgreiche Requests eingehen, wird die Wartezeit schrittweise länger.
Das war ziemlich erfolgreich, degradiert sanft, damit mobile Geräte nicht übermäßig benachteiligt werden, und funktioniert auch ohne JavaScript.
So etwas gehört wohl in eine viel niedrigere Schicht, etwa in TLS oder sogar in den IP-Stack des Betriebssystems.
Über Proof-of-Wait habe ich noch nicht tief nachgedacht, aber wirkt Warten auf legitime Nutzer nicht viel schlechter als auf automatisierte Scraper? Menschen nervt Warten, Scraper können den Token einfach speichern und nach N Sekunden zurückkommen.
Bei Proof-of-Work bin ich auch ambivalent, aber immerhin erzeugt es für Scraper echte Kosten, die mit dem Umfang skalieren.
Proof-of-Wait könnte auch Leute mit Bedenken gegenüber Proof-of-Work beruhigen.
Für bestimmte Spezialseiten funktioniert es auch ziemlich gut, sie nur für Clients zugänglich zu machen, die sich einmal eingeloggt haben und das entsprechende Cookie gesetzt haben; sonst wird der Zugriff verweigert.
Da die meisten Crawler auf Spezialseiten zielen, wenn sie ein Wiki abgrasen, kann man diese auf eingeloggte Nutzer beschränken.
In dieser Konfiguration erlaubt das Wiki keine Benutzererstellung.
<If "%{REQUEST_URI} =~ m#^/wiki/index.php(?:/.)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )">
ErrorDocument 403 "Access denied, please login."
Require all denied
</If>
Dadurch ist die Last auf unserem System stark gesunken. Davor gab es oft Peaks, bei denen das Wiki durch aggressives Crawling der Spezialseiten praktisch unbenutzbar wurde.
Darüber hinaus blockieren wir bekannte User-Agents von AI-Crawlern direkt mit 403 und sperren auch bestimmte IP-Bereiche wie Alibaba oder Amazon Cloud.
Interessanterweise haben sie das bemerkt. Als wir das Durchforsten von Seiten über die Diff-Ansicht eingeschränkt haben, haben sie dasselbe über die MobileDiff-Ansicht versucht.
Das ging ein paarmal hin und her, aber seit einigen Monaten läuft es mit dieser Methode problemlos.
Wenn man per User-Agent blockiert, versucht der Crawler es erneut mit einem User-Agent, der wie ein Mensch aussieht, und tastet die Seite weiter ab.
Wenn er erkennt, dass der User-Agent der Auslöser für die Blockierung ist, wechselt er in den Höllenmodus, wird viel schwerer identifizierbar und hämmert auf die Seite ein, bis sie stirbt.
Das Blockieren von IP-Bereichen hilft auch, reicht aber nicht aus und erwischt nicht alle, weil über mobile Malware-Proxys gecrawlt wird.
Wenn man sie gar nicht blockiert, bleiben sie meist relativ zahm.
Darum ist der Trick nicht, zu blockieren, sondern sie mit billig erzeugten Müll-Daten zu füttern, ohne den Höllenmodus auszulösen; ich nutze dafür https://iocaine.madhouse-project.org/.
Dann muss MediaWiki die Antworten allerdings selbst ausliefern, während Apache dabei eben auch Vorteile hat.
Nebenbei: Weird Gloop ist ein großartiger Dienst. Die Qualität der dort betriebenen Wikis ist sehr hoch, und von Fans erstellte Inhalte von der furchtbaren Plattform von Fandom wegzuholen, ist gut für die Welt.
Gergely Nagy, alias algernon und Entwickler von iocaine, beschäftigt sich schon seit einiger Zeit mit diesem Problem und hat wahrscheinlich nützliche Einsichten für Weird Gloop.
Ich sage das nur ungern, aber der Vorschlag, auf menschliches Verhalten hin zu optimieren, wird einem später wahrscheinlich auf die Füße fallen.
Die Bots werden anfangen, auch alle statischen Assets einer Seite anzufordern, in der Annahme, dass das Teil des Verhaltens ist, mit dem Menschen identifiziert werden.
Interessantes Spiel, Professor Falken.
Wenn ein Scraper solche Seiten erreicht, indem er normale
<a href=...>-Links rekursiv verfolgt, könnte man teure, nicht cachebare Seiten wie Versionsunterschiede vielleicht sanft umlenken, indem man sie nur noch per<form method="POST" action=...>-Submit erreichbar macht.Man blockiert nichts, und im Grunde profitiert sogar der Scraper davon, weil er dann nicht mehr fast unendlich viele redundante Informationen rekursiv verschlingt.
Normale Nutzer würden den Unterschied womöglich kaum bemerken, und gemessen am Aufwand könnte das ganz wirksam sein. Für anonyme Nutzer wäre das vielleicht besser als Anubis.
Das beruht allerdings auf der Annahme, dass Scraper keine HTTP-Formulare mit
method="POST"absenden.Wenn das im Allgemeinen nicht stimmt, hätten wir vermutlich längst Schlagzeilen gesehen, dass AI-Scraper massenhaft anonyme Edits einreichen und Wikipedia-Inhalte in zufälligen Müll verwandeln.
Ich frage mich, ob Bots auch
<form method="GET">abschicken würden. Das würde besser mit Caching harmonieren und vom Crawler trotzdem zusätzliche Logik verlangen.95 % des Traffics auf meinem kleinen Blog kommen von LLM-Scrapern aus Singapur und China.
Seit Jahren passiert das, und trotzdem hat niemand eine einzelne IP eines kleinen ISP zurückverfolgt, dort angerufen oder ist hingefahren, um höflich zu fragen, ob man sich den Computer des Nutzers ansehen darf? Hat wirklich niemand herausgefunden, welche Software da tatsächlich crawlt?
Wenn Betreiber von Websites nicht einmal das leisten können, will ich mich ehrlich gesagt nicht weiter darum kümmern. Sie bekommen Bots, weil sie sich krampfhaft vor echtem, schmutzigem Kontakt zwischen Menschen drücken.
Und Bots, die auf Residential-Botnets laufen, haben selbstverständlich oft genug Rechenleistung, um CAPTCHA oder Anubis zu bestehen.
Serverseitig kann man dauerhaft nicht gewinnen. Der Nutzer dieses Computers erzeugt ja auch legitimen Traffic.
Also muss man zu diesen IPs hingehen, sofern man nicht auf Remote Attestation aus ist.
Selbst wenn man die ganz praktischen Probleme wie Spritkosten für eine Weltreise ausblendet, wird das zu einem gewaltigen Travelling-Salesman-Problem.
Die Vorstellung, man müsse wegen ein paar Bots das ganze Wochenende irgendwohin fahren, damit sie sich gegenüber dem Sysadmin etwas höflicher verhalten, ist schon lächerlich genug — besonders wenn die meisten von großen oder ausländischen ISPs kommen.
Man fragt sich fast, was du geraucht hast.
Welche Software heute crawlt? Jemand bittet einen Chatbot darum, „bau mir etwas, das das hier scraped“, und dann wird jeder Scraper einzeln erzeugt.
Sonst gibst du einfach nur abstrakt dem ganzen Universum die Schuld.
Ich würde darauf wetten, dass den meisten Providern völlig egal ist, ob ihre IPs zum Scraping irgendeiner Website benutzt werden.
Und ich würde ebenso darauf wetten, dass sie dir niemals die zu einer IP gehörende Adresse nennen würden.
Deutlich besser funktioniert es, den ASN-Traffic bestimmter Anbieter wie Alibaba oder AWS pauschal zu verwerfen.
Das ist nicht immer eine mögliche Option. Bei einem Blog mit Atom-Feed könnte man damit zum Beispiel auch Feed-Reader aussperren.
Aber in vielen Fällen kann man so 80 % des Müll-Traffics loswerden.
Weiß jemand, warum dieses Verhalten überhaupt auftritt? Mich würde besonders interessieren, warum es zu Spitzen kommt.
Ob das stimmt, weiß ich nicht, aber zumindest klingt es plausibel.
Ohne ein besseres Verständnis der Infrastruktur ist das schwer zu sagen. Es könnte auch an Grenzen bei Command and Control liegen.
Wenn das Botnet eigentlich für DDoS gebaut wurde, fehlt ihm strukturell womöglich die Fähigkeit zu feingranularer Steuerung.