JPEG fälschen

• Der Autor betreibt einen Generator für gefälschte Webseiten-Hierarchien namens Spigot und setzt aggressiven Web-Crawlern zufällig erzeugte Seiten vor
• Kürzlich stellte er fest, dass Bild-Crawler die Website gezielt nach JPG-Bildern absuchen
• Um die Bilderzeugung in Echtzeit mit minimalen CPU-Ressourcen zu bewältigen, schlägt er vor, nur die strukturierten Teile echter JPEG-Dateien als Vorlage zu verwenden und in die komprimierten Bereiche Zufallsdaten einzufügen
• Experimente zeigen, dass auf diese Weise erzeugte JPEGs trotz Fehlern in den meisten Bildbetrachtern angezeigt werden können und auch für Crawler ausreichend plausibel wirken
• Diese Methode verbraucht wenig Server-Ressourcen, belastet aber Crawler und wird auf etwa 60 % der Seiten von Spigot eingesetzt

---

Hintergrund zu Spigot und dem Fälschen von JPEGs

• Spigot erzeugt in Echtzeit gefälschte Web-Seitenhierarchien auf Basis von Markov-Ketten, um aggressiven Web-Crawlern bedeutungslose Daten zu liefern
• Einige Crawler nutzen zufällige Browser-Signaturen und IPs, um ihre Identität zu verschleiern; dabei wurde die mögliche illegale Zweckentfremdung von Geräten über Botnetze festgestellt
• Durch Traffic-Analyse wurde bestätigt, dass ein neuer Crawler namens "ImageSiftBot" gezielt Spigot-Seiten anfordert, um Bilder zu sammeln
• Ein zentrales Ziel von Spigot ist es, die CPU-Auslastung des Servers zu minimieren und effizient zu bleiben

Überlegungen zu einer günstigen Methode der Bilderzeugung

• Bilder dynamisch zu erzeugen ist wegen der Komprimierung CPU-intensiv, daher wird ein effizienter Ansatz benötigt
• Der Ausgangspunkt war, dass JPEG-Dateien aus der Dateistruktur (Größe, Farben usw.) und einem Bereich mit komprimierten Pixeldaten bestehen
• Aus mehreren JPEGs wurden nur die strukturierten Header-Informationen extrahiert, während der Pixeldatenbereich mit Zufallsdaten gefüllt wird
• So können Bilder spontan erzeugt werden, ohne sie jedes Mal neu zu komprimieren, was die Serverlast minimiert

JPEG-Dateistruktur und konkrete Implementierung

• JPEG-Dateien bestehen aus mehreren Chunks (mit Markern und Längenangaben)
• Header- und Metadaten bleiben erhalten, nur die Länge der komprimierten Pixeldaten wird vermerkt → in genau diesen Bereich werden Zufallsdaten eingefügt
• Bei Verwendung von 514 JPEG-Beispielen beträgt die Größe aller Header-Informationen und der nötigen strukturierten Daten nur etwa 500 KB, die Speicherlast ist also vernachlässigbar
• Codebeispiel: Die Bilderzeugung erfolgt, indem die Pixeldaten-Chunks jeder Vorlage mit Zufallswerten gefüllt werden

Ergebnisse im Praxiseinsatz und Open-Source-Veröffentlichung

• Tatsächliche Bildbetrachter können auch dann noch bis zu einem gewissen Grad Bilder anzeigen, wenn der Pixelbereich vollständig zufällig ist
• Web-Crawlern fällt es schwer, die Fehler zu erkennen, wodurch ihre Datensammlung teurer wird
• Bei JPEGs mit 1280x960 und einer Größe von 200–300 KB lassen sich rund 900 Bilder pro Sekunde erzeugen, Echtzeitverarbeitung ist also problemlos möglich
• Diese Methode wird auf 60 % aller Spigot-Seiten eingesetzt; mithilfe eines URL-basierten Zufalls-Seeds wird bei erneuten Anfragen dasselbe Bild zurückgegeben
• Hohe Anfragevolumina wurden unter anderem von ImageSiftBot, Meta, AmazonBot und GPTBot beobachtet
• Der Kernzweck ist, mit geringem Server-Ressourcenverbrauch Crawler zu belasten

Huffman-Codes und weitere Optimierung

• Die Pixeldaten von JPEGs verwenden Huffman-Kodierung, weshalb beim Einfügen vollständig zufälliger Daten in manchen Betrachtern Fehler auftreten können
• Durch eine einfache Bit-Masking-Technik (0x6D), die verhindert, dass drei oder mehr Einsen hintereinander auftreten, sinkt die Wahrscheinlichkeit fehlerhafter Huffman-Codes von 90 % auf unter 4 %
• Es wäre auch möglich, einen vollständig gültigen Huffman-Stream zu erzeugen, aber der Nutzen wäre im Verhältnis zu Server-Ressourcen und Entwicklungszeit gering

Fazit

• Spigots Methode zur Erzeugung gefälschter JPEGs spart mit überwältigender Effizienz Server-Ressourcen und stiftet zugleich Verwirrung und Ressourcenverschwendung bei Crawlern
• Der zugehörige Code umfasst weniger als 100 Zeilen und wurde auf GitHub veröffentlicht
• Eine einfache, aber kreative Methode zur Abwehr und Verteilung von Web-Traffic

[GN⁺]

Hacker-News-Kommentare

• Dass die Datei robots.txt den Zugriff von Robots auf den /spigot/-Baum blockiert, war zu erwarten, aber es wurde entdeckt, dass Spigot weiterhin erreichbar ist, wenn man einfach /spigot/ aus der URL entfernt; da der Namespace /~auj nicht per robots.txt blockiert ist, kann sogar ein wohlmeinender Crawler versehentlich auf diesen Pfad geraten und in einer Endlosschleife von Seiten hängen bleiben, was keine besonders angenehme Situation ist robots.txt-Referenzlink

  • Zuvor gab es einen Kommentar des Autors, in dem stand, dass keine separate robots.txt eingerichtet wurde; zur Begründung dieser radikalen Entscheidung sagte er, dass ihm die Vorstellung nicht gefällt, Website-Betreiber müssten absichtlich Einstellungen vornehmen, um DoS durch Crawler zu verhindern, und dass legitime Crawler ohnehin nicht dauerhaft mit mehr als 15 Anfragen pro Sekunde eine einzelne Website abgrasen sollten

  • Selbst beim Punkt, dass sogar wohlmeinende Crawler in eine Endlosschleife geraten können, besteht Skepsis darüber, welche Pflicht Website-Betreiber eigentlich haben sollen, gegenüber Leuten, die ihre Website scrapen, "freundlich" zu sein; es ist fraglich, ob das überhaupt nötig ist

• Wenn sich identifizieren lässt, dass ein Crawler robots.txt ignoriert, wirkt es effizienter, die Netzwerkverbindung einfach offen zu halten und brachliegen zu lassen, statt ihm "Müll"-Informationen zurückzugeben; es ist nicht ganz klar, warum es nötig sein sollte, einem Endpoint unbegrenzt Müll zu servieren

• Zur Störung von Scrapern für AI-Eingaben kam die Idee auf, jedem Bild eine gefälschte Bildunterschrift zu geben, zum Beispiel bei einem grünen Klecksbild "eine Katze spielt mit einem Katzenminzball" und bei einem blauen Bild "ein Rotkehlchen baut ein Nest"

  • Ein gut gebauter Scraper könnte das Bild selbst mit dem CLIP-Modell oder einem anderen Captioning-Modell analysieren und noch einmal überprüfen, ob Textbeschreibung und Bild tatsächlich zusammenpassen

• Der schlimmste Fall ist der von Meta (Facebook) betriebene Bot facebookexternalhit; in der offiziellen Dokumentation steht sogar, dass dieser Bot robots.txt ignoriert; Facebook begründet das mit der Erkennung bösartiger Links, aber in der Praxis reicht es, wenn ein böswilliger Nutzer immer wieder nur URLs zu teuren Endpoints bei Facebook einreicht, und Facebook übernimmt faktisch das Traffic-Bombardement, sodass die Website jeden Monat an mehreren Tagen mit mehr als 10 r/s Traffic überflutet wird

  • Allerdings ist fraglich, ob 10 r/s wirklich das Niveau eines "Traffic-Bombardements" erreicht; selbst auf einem einzelnen Server wäre das kaum sichtbar

• Beim Lesen über Spigot fiel Project Honeypot wieder ein; vor 20 Jahren war es ziemlich aufregend, jedes Mal E-Mails zu bekommen, dass die Skripte und gespendeten MX-Records dieses Projekts dabei geholfen hatten, E-Mail-Harvester auf meiner Website zu erwischen, etwa mit einer Nachricht, dass dank meines MX ein unbestätigter Spam-Absender (IP: 172.180.164.102) erkannt wurde

  • Das Honeypot-Skript ist zwar cool, wirkt heute aber ziemlich altmodisch; das Python-Skript lässt sich laut TOS nicht einmal anpassen, und standardmäßig werden nur CGI und Zope unterstützt, sodass jemand, der eine WSGI-App baut, wohl mit einem Wrapper arbeiten müsste

• Ein JPEG zu fälschen ist für die CPU deutlich weniger aufwendig, als ein korrektes zu erzeugen; außerdem kann der Vorgang selbst eine Art Fuzzing sein, das auf der Gegenseite Abstürze auslöst, falls dort Malware mit schlampiger JPEG-Dekodierung läuft

• Dass eingehender Traffic neuerdings von Tausenden privaten IPs kommt, muss nicht zwingend ein klassisches Botnet bedeuten; es könnte auch eine Form von "Proxyware" sein, bei der viele Menschen sich für "kostenlose VPNs" oder Tools zur "Erzeugung passiven Einkommens" anmelden und ihre Geräte dann als Exit-Nodes für den Traffic anderer Nutzer dienen, wodurch sie ohne ihr Wissen als Durchleitung für den Traffic von AI-Crawlern fungieren könnten, weiteres Referenzmaterial

  • Letztlich ist auch solche Proxyware eine Variante eines Botnets, dem Nutzer freiwillig beigetreten sind; da solche Leute kaum auf HN erfahren werden, dass ihre IP ein Problem ist, wäre es vielleicht sinnvoll, IPs auf eine Warnseite umzuleiten mit dem Hinweis "Du bist Teil eines Botnets", praktisch ist es aber am bequemsten, einfach alles zu blockieren

  • Auch so etwas fällt durchaus noch in die Kategorie Botnet

• Die Art, wie hier darüber gesprochen wird, Bots zufriedenzustellen, ist bemerkenswert; ein unterhaltsamer Artikel und ein interessantes Projekt

• Die Haltung "Ich hatte Mitleid mit den Bots, die sich mit ihrer Aufgabe abmühen, also habe ich überlegt, wie ich ihnen etwas Freude bereiten kann" wirkt wirklich frisch und amüsant; das hebt sich deutlich von Threads ab, die sonst voller Wut oder Beschwerden sind

  • Diese positive Haltung ist vermutlich auch dadurch möglich, dass man sich den Luxus leisten kann, schlechten Crawlern Schmerz und Müll zuzufügen

• Das Ergebnisbild unter diesem Link gefällt mir Bild ansehen, es wirkt wie eine Art Kunstwerk mit Botschaft

  • Wer das echte Spigot-Erlebnis möchte, kann in Firefox mit F12 > Network > No Throttling auf GPRS umstellen oder in Chromium unter F12 > Network > Custom profile ein 20kbps-Profil anlegen und so die Geschwindigkeit drosseln, um es realistischer zu erleben

  • Ob es dort wohl auch Inhalte zu Shakespeare gibt?