Mit Scraper-Bots spielen

 (herman.bearblog.dev)
4 Punkte von GN⁺ 2025-11-17 | 1 Kommentare | Auf WhatsApp teilen
  • Behandelt das Problem von Scraper-Bots, die öffentliche Websites exzessiv anfragen und dadurch wie ein DDoS wirken, und stellt einen experimentellen Ansatz vor, der dies ausnutzt, um ihre Zeit zu verschwenden
  • Ein Markov-Ketten-basierter Textgenerator wurde erstellt, um gefälschte Daten zu erzeugen, die wie .php-Dateien aussehen, damit bösartige Bots sie herunterladen
  • Anschließend wurde ein statischer Content-Server aufgebaut, der zufällig Absätze aus dem Roman Frankenstein ausliefert und über eine Linkstruktur so gestaltet ist, dass sich Crawler explosionsartig ausbreiten
  • Auf allen Seiten wurden noindex, nofollow-Attribute und ein Request-Zähler ergänzt, damit normale Suchmaschinen ausgeschlossen und nur Bots erfasst werden, die Regeln missachten
  • Die Versuchsergebnisse waren interessant, doch wegen des Risikos von False Positives bei Googlebot wird das System nicht im produktiven Einsatz verwendet, sondern als Lern- und Experimentierprojekt beibehalten

Das Problem mit Scraper-Bots und die Idee für eine Gegenmaßnahme

  • Scraper verursachen unbeabsichtigt eine Belastung auf DDoS-Niveau für kleine Websites
  • Einige Betreiber fragten nach Schutzmaßnahmen, doch dieser Artikel konzentriert sich auf „Gegenangriff statt Verteidigung“
  • Nachdem der Autor gesehen hatte, wie ein anderer Entwickler mit Markov-Ketten unendliche Fake-Daten erzeugte, um Bots zu täuschen, begann er selbst zu experimentieren

Markov-Ketten-basierter Generator für gefälschte PHP-Dateien

  • In Rust wurde ein Markov-Ketten-Lerner implementiert, der auf Basis beliebiger Textdaten realistisch wirkende Inhalte erzeugt
  • Für bösartige Bots, die auf anfällige Pfade wie .env, .aws oder .php zielen, werden bedeutungslose, aber echt aussehende PHP-Dateien ausgeliefert
  • Die Dateigröße wurde von 2 KB auf bis zu 10 MB erhöht, um Ressourcenverschwendung bei Bots zu provozieren
  • Die Beispielausgabe sieht aus wie plausibler gefälschter PHP-Code mit gemischten WordPress-Funktionsnamen und Kommentaren
  • Das Ziel ist, Zeit und Ressourcen der Bots zu verschwenden und Angreifer bei der Suche nach echten Schwachstellen aufzuhalten

Effizienz und Experimente mit statischer Datenauslieferung

  • Als auf einem VPS Dateien mit mehr als 1 MB ausgeliefert wurden, kam es zu höherer Antwortlatenz und zusätzlicher Serverlast
  • Um das zu lösen, wurde ein „Garbage Server“ als statische Website gebaut
    • Der vollständige Roman Frankenstein wird in den Speicher geladen, und pro Request werden vier zufällige Absätze zurückgegeben
    • Am Ende jeder Seite werden fünf Links hinzugefügt, um eine explosive Ausbreitung des Crawlings (Faktor 5) auszulösen
  • Das Ergebnis ist unter https://herm.app/babbler/ zu sehen

Design-Details und Betriebsweise

  • Der ausgewählte Roman ist Public Domain und wurde verwendet, weil daran zur Halloween-Zeit gearbeitet wurde und weil Ähnlichkeiten zwischen AI und Frankenstein gesehen wurden
  • Alle Seiten erhalten das Attribut noindex,nofollow, damit nur Bots erfasst werden, die Regeln missachten
  • Am Ende jeder Seite wird ein Zähler für die Anzahl der Requests angezeigt; bei einer speicherbasierten Auslieferung wird er nach Deployment zurückgesetzt
  • Es gibt auch einen separaten Server für .php-Requests, der zufällig echte PHP-Dateien aus dem Speicher ausliefert
  • Das Projekt wird mit dem Satz „Garbage for the garbage king!“ zusammengefasst

Risiken und Einschränkungen

  • Bei einem Einsatz in realen Services besteht für dieses System das Risiko von False Positives bei Suchmaschinen
    • Wenn Googlebot versehentlich falsche Endpunkte crawlt, könnte die Seite als Spam-Site eingestuft werden
    • Das kann zu schlechterer Sichtbarkeit in der Suche oder zu Warnhinweisen in Chrome führen
  • Daher wird es für suchmaschinenabhängige Websites nicht empfohlen und nur als Experiment betrieben
  • Der .php-Babbler ist kein HTML, daher hat Googlebot darauf keinen Einfluss; Ziel sind nur bösartige Bots

Abschluss und persönliches Fazit

  • Um bösartige Scraper anzulocken, wurden dem Blog versteckte Links (rel="nofollow") hinzugefügt
  • Wenn das Traffic-Limit des VPS überschritten wird, wird der Einsatz des Cloudflare-Caches erwogen
  • Über das Projekt wurden Markov-Ketten und die Funktionsweise von Bots gelernt; das Experiment war eine Mischung aus Spaß und Frust
  • Letztlich muss nicht jeder Versuch praktisch sein; manchmal reicht es auch, wenn es einfach Spaß macht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-17
Hacker-News-Kommentare

  • Auch wenn sich die Welt verändert, hat man am Ende wieder ähnliche Probleme
    Vor 10–15 Jahren habe ich bereits mit Social-Media-Monitoring-Diensten gekämpft. Große Marken haben sie dafür bezahlt, die Stimmung in Foren zu überwachen, und dabei haben sie ohne Erlaubnis meine kostenlose Community gescrapt und Serverlast verursacht.
    Selbst wenn ich ihre Bots blockiert habe, kamen sie mit anderen IPs und UAs zurück. Also habe ich einen Filter gebaut, der zufällig Markennamen in Beiträge einfügte und so ihre Datenqualität ruinierte. Nachdem ich diese Maßnahme aktiviert hatte, hörte das Scraping innerhalb von zwei Tagen vollständig auf.

    • Ich hatte eine ähnliche Erfahrung. Es gab Bots, die das Spendenformular meiner Website zum Testen von Kreditkarten missbraucht haben und mit wechselnden IPs immer weitergemacht haben. Statt zu blockieren, habe ich daher zufällig Erfolgs- oder Fehlermeldungen zurückgegeben. Dadurch wurden ihre Daten verfälscht, und nach ein paar Tagen haben sie aufgegeben.
    • Die Geschichte mit der Header-Analyse war wirklich nützlich. Auch auf meinem Fediverse-Server habe ich festgestellt, dass Bots mit einer alten Chrome-UA überhaupt keinen Accept-Language-Header mitsenden. Nachdem ich nginx so konfiguriert hatte, dass 403 zurückgegeben wird, begann der Traffic zurückzugehen.
    • Wie im Film The Imitation Game merkt die Gegenseite es sofort, wenn man auf jede Anfrage unmittelbar reagiert. Wenn man nur einen Teil der Requests verarbeitet oder zufällige Fehlercodes zurückgibt, wird Erkennung schwieriger und ihr Debugging deutlich aufwendiger.
    • Die meisten Bots können immer noch keine HTTP-Header-Sets korrekt imitieren. Auch 2025 filtere ich noch auf diese Weise, und die Bots entwickeln sich weiterhin nach denselben Mustern.
    • Ich frage mich, warum die Bots verschwunden sind, nachdem Firmennamen eingefügt wurden. Ich würde gern wissen, ob dabei das Datensignal verfälscht wurde, das sie beim Suchen nach Markenerwähnungen verwendet haben.

  • Diese Bots parsen PHP-Dateien nicht wirklich, sondern erstellen anhand ihrer Existenz einen Fingerprint zur Schwachstellenerkennung. Sie schauen nur auf den Response-Code und verwerfen das dann sofort.

    • Stimmt, in solchen Fällen sind Tools wie fail2ban oder crowdsec wirksamer. Als ich crowdsec ausprobiert habe, wurde mir klar, wie enorm viele Versuche zur Schwachstellensuche es selbst auf Servern mit wenig Traffic gibt.
    • Dann müsste es auch möglich sein, absichtlich gefälschte Schwachstellen offenzulegen, um Bots anzulocken. Zum Beispiel könnte man automatisierte Bots in einen Honeypot (Honeybot) ziehen und ihre internen Abläufe beobachten. Siehe: The Cuckoo’s Egg
    • Wenn LLM-Scraper solche Antworten als Trainingsdaten verwenden, könnte das Risiko von Data Poisoning noch größer werden. In neueren Papers heißt es ebenfalls, dass schon wenige Datenpunkte ein Modell ruinieren können.

  • Kürzlich habe ich von einem Tarpit für AI und Scraper gehört. Dabei wird die Verbindung nicht getrennt, sondern unendlich viele Daten werden extrem langsam weitergesendet. Das Tool Nepenthes klingt interessant, ich würde damit gern experimentieren.

  • Früher wurde man auf HN kritisiert, wenn man Scraper blockiert hat. Die Logik war: „Es ist egal, wie ich zugreife.“

    • Aber heute ist das anders. Der persönliche Zugriff eines Menschen und Massenanfragen von AI-Unternehmen auf DDoS-Niveau sind zwei völlig verschiedene Dinge. Letzteres ist eindeutig ein Verhalten, bei dem die Kosten auf andere abgewälzt werden.
    • Ich finde normales Scraping auch okay. Man muss nur eine UA angeben und robots.txt respektieren. Aber so wie jetzt mit Dutzenden Requests pro Sekunde und als Tarnung eine alte Chrome-Version auszugeben, ist völlig inakzeptabel.
    • Ich scrape einmal täglich Jobbörsen für ein akademisches Projekt. Das ist eine vernünftige Nutzung. Wer dagegen im Minutentakt Inhalte abzieht oder nach Schwachstellen sucht, ist ein ganz anderes Problem.
    • Am deprimierendsten ist, dass der Aufstieg von AI das ethische Bewusstsein selbst schwächt. Menschen, die früher Freiheit wichtig fanden, verlangen jetzt nach stärkerem Copyright oder der Abschaffung von Anonymität. Technologie macht Menschen schlechter.

  • Wenn man einen Apache-Server direkt verwaltet, kann man mit RewriteEngine PHP-Requests sofort blockieren

    RewriteEngine On
RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
RewriteCond %{QUERY_STRING} \.php [NC,OR]
RewriteCond %{THE_REQUEST} \.php [NC]
RewriteRule .* - [F,L]

    Auf meinem Server gibt es kein PHP, also sind solche Anfragen durchweg bösartig.

    • Unter nginx konfiguriere ich es ähnlich. Für PHP- oder ASPX-Requests gebe ich den HTTP-418-Status „I’m a teapot“ zurück 
      location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
error_page 418 /418.html;
      Das erleichtert das Filtern der Logs. Beispiel: FreeSolitaire.win/wp-login.php

  • Die meisten aggressiven Scraper zielen auf WordPress-Schwachstellen. Sie wollen nicht die PHP-Datei selbst, sondern deren Ausgabe. Solche Konfigurationen sind eher eine Art Honeypot, aber wenn der Bot nicht wie im Skript vorgesehen reagiert, zieht er einfach weiter.

    • Vermutlich suchen sie in der Ausgabe mit Regex nach Admin-Login-Mustern. Wenn nichts gefunden wird, überspringen sie es sofort. Anders gesagt: Eine einzelne Regex-Zeile ist viel effizienter, als eine gefälschte PHP-Datei mit 4 KB zu erzeugen.

  • Ich habe früher einmal die Zipbomb-Strategie auf HN gepostet, worauf der Traffic auf 100.000 Requests pro Tag explodiert ist. Mit einem VPS für 6 Dollar war das nicht zu stemmen. Heute setze ich nur gegen die aggressivsten Bots eine Zipbomb ein und gebe dem Rest 403 zurück. Die neue Strategie funktioniert gut, aber ich bin unsicher, ob ich sie wieder öffentlich machen sollte. Siehe: früherer Beitrag

  • Früher habe ich nur fail2ban verwendet, wollte aber etwas unterhaltsamere Abwehrmaßnahmen bauen
    In .htaccess leite ich verdächtige Pfade (/.git, /wp-login) auf decoy.php um und erzwinge den Download einer 10-GB-großen decoy.zip.
    decoy.php sieht aus wie die angeforderte sensible Datei, streamt in Wirklichkeit aber endlos gefälschte Logs und SQL-Daten, um den Bot festzuhalten.

  • Diese Bots scrapen keine PHP-Dateien, sondern suchen nach Framework-Schwachstellen. Wenn man unerwartete Antworten gibt, geben sie sofort auf und wechseln zum nächsten Ziel.

  • Manchmal denke ich darüber nach — könnte man sie mit den Ressourcen, die diese Bots verschwenden, nicht Kryptowährung minen lassen?

    • Dafür müsste man wohl die Ausführung von JavaScript auslösen, aber die meisten Bots dürften gegen solche Versuche bereits Gegenmaßnahmen eingebaut haben.