Mein Git-Server wurde durch Amazons AI-Crawler instabil

 (xeiaso.net)
1 Punkte von GN⁺ 2025-01-19 | 1 Kommentare | Auf WhatsApp teilen
  • Der öffentliche Gitea-Server git.xeserv.us wurde durch AmazonBot-Anfragen instabil; der Betreiber bat das AmazonBot-Team, die Domain auf die Blockliste zu setzen
  • Obwohl in robots.txt alle Bots mit Disallow: / blockiert wurden, gingen weiterhin Anfragen ein, sodass der Betrieb eines öffentlichen Git-Servers möglicherweise ganz aufgegeben werden muss
  • AI-Crawler erschweren das Blockieren, indem sie den User-Agent ändern oder Residential-IP-Proxys verwenden
  • In nginx ingress wurde blockiert, indem für den User-Agent Amazon der Status 418 zurückgegeben wurde; die Anfragen liefen jedoch von anderen IPs weiter, und etwa 10 % hatten nicht einmal den User-Agent amazonbot
  • Am Ende wurde der Gitea-Server wieder hinter ein VPN verschoben, und mit Anubis entstand ein Reverse Proxy, der vor Anfragen einen Proof-of-Work-Check durchführt

AmazonBot-Anfragen und die Grenzen von robots.txt

  • Der Betreiber bat die AmazonBot-Betreiber, git.xeserv.us zur Liste blockierter Domains hinzuzufügen
  • Für das Crawlen des Git-Servers sollten sie Kontakt aufnehmen, damit sie die Kosten für Hardware-Upgrades tragen können, die zur Bewältigung der übermäßigen Ressourcennutzung nötig sind
  • Eine robots.txt, die alle Bots blockiert, war bereits eingerichtet, reichte aber nicht aus, um tatsächliche Anfragen zu stoppen
User-agent: *
Disallow: /
  • Außerdem wurden Gründe zusammengefasst, warum das Blockieren von AI-Crawler-Bots schwierig ist
    • Bots lügen
    • Sie ändern den User-Agent
    • Sie verwenden Residential-IP-Adressen als Proxys
    • Sie nutzen auch weitere Methoden

Blockierung in nginx ingress und Veröffentlichung von Anubis

  • Am 2025-01-17 um 17:50 UTC wurde per nginx-ingress-Konfiguration eine User-Agent-Blockierung hinzugefügt
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • Auch nach dieser Einstellung stellte der Bot weiterhin bei jeder Anfrage von einer anderen IP aus Requests, und etwa 10 % der Anfragen enthielten keinen amazonbot-User-Agent
  • Am 2025-01-18 um 19:00 UTC wurde der Gitea-Server wieder hinter ein VPN verschoben
  • Danach begann die Entwicklung eines Reverse Proxys, der vor dem Gitea-Server einen Proof of Work prüft, bevor Anfragen zugelassen werden
  • Am 2025-01-18 um 23:50 UTC war dieser Proxy unter dem Namen Anubis auf https://git.xeserv.us/ verfügbar
  • Mit Stand 2025-03-26 um 14:27 UTC ist Anubis ein eigenständiges Projekt mit Dokumentationswebsite

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-19
Meinungen auf Hacker News

  • Jetzt ist es Zeit, ein Anwaltsschreiben zu schicken. Wenn man sich die Richtlinien zur Strafverfolgung nach dem Computer Fraud and Abuse Act ansieht, betrachtet das US-Justizministerium den Zugriff auf öffentliche Server in der Regel nicht als „unbefugten Zugriff“, sofern es sich nicht um einen offensichtlichen Angriff handelt. Dort steht aber auch, dass er ab dem Zeitpunkt als unbefugt gilt, an dem der Rechteinhaber anschließend eine klare schriftliche Aufforderung zur Unterlassung sendet und der Beklagte diese erhält und versteht.
    Also sollte man einen Anwalt ein klares „Cease and Desist“-Schreiben aufsetzen lassen und es Amazon auf dem vom Anwalt empfohlenen Weg zustellen, etwa per Einschreiben oder durch einen Zustellungsbeauftragten. Vermutlich sollte man beides tun und zusätzlich eine E-Mail schicken.
    Danach kann man sehen, ob Amazon aufhört; falls nicht, kann man Strafanzeige erstatten. Dann wird Amazon die Sache auch ernst nehmen.
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • „Sehen, ob Amazon aufhört“ passt nur, wenn diese Anfragen tatsächlich von Amazon kommen. Angesichts der Details im Beitrag – rotierende User-Agents, private Residential-IPs und ein Verhalten, das robots.txt offenbar nicht auswertet – wirkt das eher unwahrscheinlich.
      Der Amazon-Bot sollte aus bekannten Amazon-IP-Bereichen kommen und robots.txt respektieren. Ein Amazon-Engineer hat das in einem anderen Kommentar ebenfalls bestätigt: https://news.ycombinator.com/item?id=42751729
      Wenn nur der User-Agent-String „AmazonBot“ zu Amazon passt, IP-Bereiche und Verhalten aber nicht, ist ein Anwaltsschreiben an Amazon ungefähr so sinnvoll, wie Geld zu verbrennen.
    • Ehrlich gesagt ist es schon peinlich genug, damit auf der Hacker-News-Startseite gelandet zu sein, sodass vermutlich jemand aus der Abteilung für gesunden Menschenverstand meine höfliche E-Mail „Bitte nicht meinen Git-Server scrapen“ liest und antwortet. Wenn bis nächsten Dienstag keine Antwort kommt, lasse ich einen Anwalt ein formelles Unterlassungsschreiben aufsetzen.
    • Brauchen wir inzwischen ein Gesetz, das besagt: „Robots müssen robots.txt respektieren“?
    • Ich frage mich, was hier mit Zustellungsbeauftragter (process server) genau gemeint ist.

  • Mir gefällt die Lösung in diesem Kommentar: https://news.ycombinator.com/item?id=42727510
    Man setzt irgendwo auf der Website einen Link, den ein Mensch niemals besuchen würde, verbietet ihn in robots.txt und blockiert jede IP für 24 Stunden, die diesen Link aufruft. Da OpenAI-Crawler offenbar insbesondere Wildcards ignorieren, legt man ihn entsprechend unter eine Wildcard.

    • Ich hatte schon mit Bot-Aktivität über breite Adressbereiche zu tun und habe unter der Bedingung, dass etwas als Bot bestätigt war, eine ähnliche Methode genutzt: die IP 24 Stunden blockieren.
      Aber es waren so viele betreffende IPs, dass es auf den Traffic kaum Auswirkungen hatte.
      Ich empfehle, sich die empfangenen Header sehr genau anzusehen. varnishlog ist dafür ziemlich gut; wenn man lange genug hinschaut, findet man Merkmale, die alle Requests gemeinsam haben. Zum Beispiel ungewöhnliche Kombinationen aus gemeldeter Sprache und geografischem Standort oder dieselbe veraltete Browser-Version.
    • Web-Crawler sind wirklich zum Verzweifeln. Vor etwa acht Jahren ging bei meinem damaligen Arbeitgeber ein Server für Fahrzeugbilder in die Knie. Der fragliche Crawler griff auf Links zu Fahrzeugbildern zu, die wir aufgrund unseres Geschäfts hatten, und durch die perfekte Kombination ungünstiger Umstände – die Bilder existierten tatsächlich nicht – wurde der Image-Server für Statusberichte praktisch geDoSt.
      Noch schlimmer: Im Error-Handler gab es einen Bug, sodass der Serverprozess bei diesem Zustand neu gestartet wurde; dabei wurde auch noch eine Cache-Implementierung ungültig gemacht, die „für .NET 2.0 eigentlich ziemlich ordentlich“ war.
      Ich erinnere mich, dass wir danach anfingen, als Schutzmaßnahme Canary-Techniken einzubauen. Ein paar einfache Canaries waren immer noch billiger als zusätzliche Webserver. Natürlich haben wir auch das Cache-Problem behoben und außerdem eingebaut, dass der Dienst „schreit“, wenn zu viele schlechte Requests eingehen.
    • Als ich einen Crawler für meine Suchmaschine baute, stellte ich fest, dass es kaum Crawler-Libraries gibt, die wirklich zur Realität passen. Am Ende steckte ich ziemlich viel Aufwand in eine eigene Implementierung, die sogar Amazons und Googles recht komplex verschachtelte robots-Dateien und die angeforderten Cooldown-Zeiten einhält.
      Ironischerweise konnten die Crawler genau dieser Unternehmen ihre selbst erstellten Manifeste nicht parsen.

  • Wir sehen dasselbe Verhalten bei allen AI- und SEO-Bots und können das bestätigen. Sie halten sich gerade so an robots.txt und sind schwer zu blockieren. Beim Crawlen kommen sie spamartig herein, treiben die Last stark hoch und legen viele Server unserer Kunden lahm.
    Wenn AI-Crawler Zugriff wollen, müssen sie sich benehmen oder bezahlen. Andernfalls wird das Ergebnis eine nahezu allgemeine Blockade sein.

    • Die Lösung ist ein globaler Tarpit. Das ergibt auch unabhängig von AI-Crawlern Sinn. Als ich so etwas früher einmal implementieren musste, habe ich halbmanuell Access-Logs geparst und per iptables für IPs, die im Schnitt mehr als X Requests pro Sekunde auf /api machten, -j TARPIT gesetzt.
      Wie man das in der Cloud umsetzen würde, weiß ich nicht genau. Dort habe ich es bisher noch nicht gebraucht.
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • Ich verstehe nicht, wie diese „nahezu allgemeine Blockade“ funktionieren soll. Ist nicht genau das Schwierige daran das Problem? Wenn es möglich wäre, hätte man es doch längst gemacht.
    • Ich frage mich, was es bedeutet, robots.txt „gerade so“ einzuhalten. Ist das nicht binär? Heißt das, dass manche Direktiven befolgt und andere ignoriert werden?
    • Gibt es keine Möglichkeit, dass Websites diese Daten als große ZIP-Datei an AI-Bots verkaufen? Das wäre wohl besser, als ständig DDoS ausgesetzt zu sein.
      Oder sie sollten wenigstens aus Höflichkeit nachts oder zu Zeiten mit geringer Auslastung scrapen.
    • Was bringt Blockieren? Bis dahin haben sie den Content doch schon komplett gescrapt.

  • Ich gehe nicht davon aus, dass das wirklich Amazon ist. Der Autor sieht Anfragen, bei denen Residential IPs rotiert und auch die User-Agent-Strings geändert werden.
    Sich als Crawler eines großen Unternehmens auszugeben, ist eine gängige Technik von Leuten, die nicht auffallen wollen. Dass die Requests von Residential IPs kommen, ist ein deutliches Warnsignal, dass hier etwas anderes passiert.

    • Ich arbeite bei Amazon, bin aber nicht direkt für Web-Crawling zuständig.
      Nach den Informationen, die ich intern prüfen konnte, ist es sehr unwahrscheinlich, dass das tatsächlich Amazon ist. Amazonbot muss robots.txt beachten und immer von IP-Adressen kommen, die Amazon gehören. Das Prüfverfahren steht hier: https://developer.amazon.com/en/amazonbot
      Ich habe es intern weitergegeben, um zu prüfen, ob irgendein seltsames internes Team, von dem ich nichts weiß, so etwas macht. Der Autor sollte diesen Traffic aber besser als bösartig einstufen und davon ausgehen, dass der User-Agent gefälscht wird.
    • So etwas wird kommerziell als Service angeboten[1]. Wegen irgendeiner eingebundenen Library werden Hunderte Millionen Netzwerke quasi als Backdoor genutzt und zu Crawlern/Scrapern gemacht; mit weit gefassten Formulierungen irgendwo in den Nutzungsbedingungen wird es scheinbar legalisiert, Nutzer zu Erfüllungsgehilfen für Aktivitäten zwischen legal und illegal zu machen.
      [1] https://brightdata.com/proxy-types/residential-proxies
    • Bei Unternehmen, die heutzutage aggressiv crawlen, kann man kaum sicher sein, dass sie Proxy-Netzwerke nicht einsetzen.

  • Ich hatte kürzlich dasselbe Problem. Meine Forgejo-Instanz fing an, die CPU meines Homeservers zu 100 % auszulasten, weil Claude und die AI-Freunde von Meta und Google praktisch unendlich viele Links mit hoher Geschwindigkeit bombardierten.
    Mit robots.txt und einer User-Agent-basierten Blockliste in Caddy konnte ich es etwas eindämmen, aber ich weiß nicht, wie lange das funktioniert.
    Wo ist eigentlich die Etikette beim Scraping geblieben?

    • Wegen des Geldes. AI-Unternehmen haben einen finanziellen Anreiz, so viele Daten wie möglich so schnell wie möglich von überallher zu holen, wo sie sie bekommen können. Im Moment haben sie auch so viel Geld zum Verbrennen, dass sie kaum effizient sein müssen.
    • Wenn mehrere Unternehmen signalisiert bekommen, dass das Overton-Fenster dafür, was AI zumindest vorerst fressen darf, extrem weit ist, werden sie so viel wie möglich mitnehmen wollen, bevor die Regulierung anzuziehen versucht.
      Das größere Risiko ist, dass eines dieser Unternehmen, sogar eines, das sich „Open“ nennt, aus wirtschaftlicher oder nationaler Sicherheitsperspektive eine Größe erreicht, bei der es als „too big to fail“ gilt.
    • Es ist dasselbe passiert wie mit Höflichkeit in allen anderen Kontexten. Höflichkeit existierte nur in Kontexten, in denen es sich nicht lohnte, sie zu ignorieren. Sobald diese Voraussetzung verschwindet, wird sie sofort fallen gelassen.
    • Kann jemand eine brauchbare robots.txt oder eine User-Agent-Liste teilen, mit der man AI-Crawler blockieren kann?
    • Wann wird der letzte Mensch auf Hacker News begreifen, dass Meta, OpenAI und alle Big-Tech-Unternehmen uns am Ende für schnelles Geld allen schaden werden?
      Facebook ist berüchtigt dafür, es leicht gemacht zu haben, Freundeslisten von MySpace zu scrapen, und nachdem sie selbst groß geworden waren, haben sie dasselbe Verhalten auf ihrer eigenen Site verboten.
      Bitte wacht endlich auf.

  • Bist du sicher, dass das kein als Amazon getarnter DDoS ist?
    Dass die Anfragen von Residential IPs kommen, ist wirklich verdächtig.
    Das Motiv für so einen DDoS könnte sein, kleine Sites lahmzulegen und es so aussehen zu lassen, als sei Amazon verantwortlich, um Amazon ins Visier zu nehmen.
    Wenn es tatsächlich Amazon wäre, wäre der Ausgangspunkt, alle von ihnen veröffentlichten IP-Ranges zu blockieren. Allerdings klingt es so, als kämen Requests auch von außerhalb dieser Ranges.

    • Man sollte sich Websites wie grass dot io ansehen. Ich verlinke nicht direkt, weil ich ihnen keinen Traffic geben will.
      Solche Dienste bezahlen Nutzer für ihre Bandbreite und verkaufen sie an Dritte weiter, weshalb viel Bot-Traffic so aussieht, als käme er von Residential IPs.

  • Meine Site Pinboard wird ebenfalls von mutmaßlichen AI-Crawlern verprügelt. Im Sommer fing es mit IPs aus China und Singapur an, aber inzwischen kann ich nicht einmal mehr IP-Ranges blockieren und muss mich auf CAPTCHAs verlassen.
    Das Traffic-Niveau reicht aus, um die Site sofort zu töten, und ich habe nicht einmal interessanten Text zum Trainieren, nur Links.
    Ich frage mich, wie der Autor des Originalposts herausgefunden hat, dass ein Amazon-Crawler die Ursache ist. Ich hätte auch gern jemanden, dem ich die Schuld geben kann.

  • Die beste Methode, dagegen anzukämpfen, ist vielleicht nicht Blockieren. Blockieren schadet Amazon oder irgendeinem anderen Unternehmen überhaupt nicht.
    Was wäre stattdessen, wenn man den Bots Inhalte füttern könnte, die offensichtlich schädlich oder korrumpierend sind?
    Wenn das in größerem Maßstab passiert und Amazon die vergifteten Daten entdeckt, müssten sie Geld ausgeben, um sie schnell zu entfernen, und versuchen, die Bots daran zu hindern, solche Daten zu fressen.
    Das größte Problem ist natürlich, dass niemand so etwas auf seiner eigenen Site haben will.

    • Die Idee, ihnen „schädliche Inhalte“ zu füttern, missversteht völlig den Umfang des Fehlverhaltens der AI-Unternehmen.
      Diese Scraper fressen bereits ohne Zögern CSAM und ähnlich Grauenhaftes. Einige der kenianischen Data-Tagging-Subunternehmer von OpenAI haben genau deswegen aufgehört. Das war ein Time-Artikel von 2023.
      AI-Unternehmen interessieren sich derzeit nicht für Datenqualität, sondern nur für Menge. Die einzige Möglichkeit, ihnen zu schaden, ist, ihnen 0 Byte zu geben.
      Für ein Zehntel dessen, was Sam Altman abgenickt hat, würde ein normaler Mensch sofort ins Gefängnis gehen.
    • Für diesen Zweck habe ich dieses Tarpit empfohlen gesehen. Wenn eine Site gecrawlt wird, erzeugt es endlose Verzeichnisverschachtelungen und endlosen Müllinhalt, damit Bots stundenlang darin feststecken.
      https://zadzmo.org/code/nepenthes/
    • Wenn mit schädlichen Inhalten unzutreffende Inhalte gemeint sind, gibt es in einem anderen Kommentar in diesem Thread jemanden, der genau so etwas macht: https://marcusb.org/hacks/quixotic.html
    • Milliardenschwere Unternehmen brechen ständig ungestraft das Gesetz; warum sollte ich dafür verantwortlich sein, gegen den Wind zu pinkeln?

  • Es wäre eine nette Geste, wenn Amazon einem ein paar AWS-Credits geben würde, um die von Amazon und anderen Bots verursachten Mehrkosten für ausgehenden Traffic auszugleichen. Trotzdem wird das vermutlich durch die Werbeeinnahmen dieses Artikels wieder hereinkommen. Wenn man den Adblocker ausschaltet, geht die Rechnung auf.

  • Vor der Sperrung über Nginx entfielen Bytespider auf 59 % und Amazonbot auf 21 %; zusammen machten sie damit 80 % des gesamten Traffics unseres Git-Servers aus
    ClaudeBot verursachte innerhalb eines Monats mehr Traffic auf Redmine als in den fünf Jahren vor ClaudeBot zusammen