Alle kleinen Tools aufbieten, um Bots zu blockieren

 (lambdacreate.com)
4 Punkte von GN⁺ 2025-06-02 | 1 Kommentare | Auf WhatsApp teilen
  • Durch das wahllose Crawling und Scraping großer AI-/Suchunternehmen werden private Server und Dienste massiv beeinträchtigt; Ressourcenverbrauch und Instabilität der Services treten fortlaufend auf
  • Nach der Erkennung ungewöhnlichen Traffics mit Monitoring auf Basis von Zabbix und Loki wurden mit Log-Analyse-Tools (lnav, goaccess) und SQL-basierten Abfragen Angreifermuster, IPs und User Agents detailliert untersucht
  • In der Nginx-Konfiguration wurde schrittweise ein Abwehrsystem aufgebaut, darunter 403-Sperren auf Basis von User Agents, Rate Limiting und die Anbindung an Fail2Ban, wodurch Hunderte bösartiger IPs blockiert und die Serverstabilität wiederhergestellt wurden
  • Das Hauptproblem waren Bots, die versuchten, komplette Gitea-Repositories massenhaft als Tarball herunterzuladen; der Traffic stammte zunehmend nicht von einfachen Inhaltskonsumenten, sondern diente der AI-Datensammlung bzw. dem Modelltraining
  • Langfristig wird über Ausnahmen für legitime Dienste (z. B. archive.org) nachgedacht sowie über eine Strategie, die Sichtbarkeit in Suchmaschinen beibehält, sich aber gegen die AI-„Enshittification“ stellt

Einleitung: Bot-Traffic prasselt auf meinen kleinen Server ein

  • In letzter Zeit ist auf dem privat betriebenen lambdacreate-Blog und mehreren weiteren Diensten plötzlich eine große Menge unbekannten Traffics aufgelaufen
  • Legitime Dienste wie Archive.org sind willkommen, doch das wahllose Daten-Crawling großer Unternehmen wie Amazon, Facebook und OpenAI schadet der Website
  • Mit der steigenden Nachfrage nach Datensammlung für AI-Modelltraining und Ähnliches verschärft sich dieses Phänomen weiter
  • Statt echter Leserinnen und Leser (Menschen) hatte der Betreiber vor allem mit massenhaftem Bot-Traffic zu kämpfen

Bestätigung des Problems: Diagnose des Traffic-Anstiegs mit Monitoring-Tools

  • Mithilfe von Monitoring-Tools wie Zabbix und Loki wurde der Ressourcenverbrauch des Servers analysiert
  • Auf der Gitea-Instanz nahm das Datenvolumen pro Tag um 20–30 GB zu, begleitet von verschiedenen CPU- und Speicherwarnungen
  • Die Nginx-Traffic-Analyse zeigte einen Anstieg vom Monatsdurchschnitt von 8 req/s auf kurzfristig über 20 req/s
  • Der Traffic war insgesamt nicht riesig, lag aber fast 10-mal über dem Normalniveau und führte zu Ressourcenerschöpfung

Analyse der Ursache: Tiefgehende Auswertung der Logdateien

  • Mit lnav und goaccess wurden die Nginx-Access-Logs per SQL analysiert
    • Muster bei Besucher-IP, User Agent, Referrer usw. wurden identifiziert
  • Das Ergebnis: Der Traffic kam nicht von einem bestimmten Dienst oder einer Community, sondern bestand aus massivem Crawling aus bestimmten IP-Bereichen
  • In den User Agents fanden sich zahlreiche explizite oder gefälschte Angaben wie Amazonbot, OpenAI, Applebot, Facebook
  • Da die tatsächliche Nutzung des Dienstes dadurch beeinträchtigt wurde, entstand die Notwendigkeit einer strikteren Sperrstrategie

Lösung: Kombination mehrerer Verteidigungsebenen mit Nginx, Fail2Ban und mehr

  • Mit Nginx map wurden schädliche User Agents sofort mit 403 beantwortet und zusätzlich Rate Limits eingeführt
  • Auch bei neuen oder noch nicht erkannten Bots wurde durch die Begrenzung der Anfragefrequenz die Serverlast minimiert
  • Auf Basis der 403-Logs wurden mit goaccess und lnav neue schädliche IPs und User Agents erkannt
  • Mit dem automatisierten Security-Tool Fail2Ban wurden IPs mit übermäßig vielen 403-Antworten für 24 Stunden automatisch gesperrt
    • Mehr als 735 automatische Bans wurden verzeichnet
  • Die tatsächliche Ressourcennutzung normalisierte sich in erheblichem Maß
  • Künftig sollen Ausnahmeregeln für legitime Dienste wie archive.org gelten; Suchmaschinen-Indexierung bleibt erlaubt, aber wahlloses Crawling für AI-Training soll weiterhin blockiert werden

Fazit: Die Stärke kombinierter Tools und die Notwendigkeit von Sicherheit für private Dienste

  • Durch diese mehrschichtige Verteidigungsstrategie konnten der reibungslose Betrieb des privaten Blogs und die Erreichbarkeit der Dienste wiederhergestellt werden
  • Es zeigte sich, dass der Einsatz vieler kleiner Systemverwaltungs- und Automatisierungstools für die Sicherheit privater Server wirksam ist
  • In einer Umgebung, in der durch die wachsende Nachfrage nach AI-Training sogar private Server wahllos gecrawlt werden, sind aktive Blockierung und automatisiertes Management unverzichtbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-02
Hacker-News-Kommentar

  • Mir fällt oft auf, dass viele skrupellose Crawler einfach große Suchmaschinen nachahmen. Manche sagen zwar, man solle sich nicht von der User-Agent-Angabe täuschen lassen, aber meine bevorzugte Methode ist, in robots.txt verdächtige Hinweise einzubauen, etwa eine gzip bomb, und Crawler, die darauf anspringen, ab der nächsten Anfrage zu blockieren. Mit Caddy lässt sich das einfach umsetzen, und so erwischt man vor allem die schlimmsten Regelverletzer. Ich will das Verhalten solcher Bots nicht entschuldigen, aber wenn ein paar davon schon eine Website lahmlegen, ist das auch ein Beleg dafür, dass die Seite gegenüber böswilligen Angreifern wirklich verwundbar ist.

    • Der letzte Kommentar bringt es für mich wirklich auf den Punkt. Vielleicht gehöre ich einfach zu einer anderen Generation, aber ich verstehe nicht, warum Leute heute so besessen davon sind, möglichst wenig Ressourcen zu verbrauchen. Das wirkt auf mich so, als würden Großeltern ein Drama darum machen, LED-Lampen auszuschalten, oder 24 km fahren, um 5 Cent Sprit zu sparen. 20 Requests pro Sekunde sind wirklich nichts, selbst wenn die Inhalte dynamisch generiert werden — wobei ich mich frage, warum überhaupt, wenn man in derselben Zeit viel besser Caching aufsetzen könnte. Solche "fuck the bots"-Texte sind im Moment zwar in Mode, aber das Thema ist nun wirklich nicht neu. Es gibt deutlich produktivere Wege, damit umzugehen, ohne Zeit zu verschwenden.

    • Ich würde gern mehr darüber hören, wie man mit robots.txt eine gzip bomb einsetzt. Soweit ich weiß, ignorieren die meisten AIs robots.txt ohnehin. Deshalb frage ich mich, ob man am Ende nicht nur ein paar naive Crawler erwischt. Ich bin nicht grundsätzlich dagegen, sondern möchte einfach mehr darüber erfahren, wie man so etwas umsetzt, ohne den Guten zu schaden.

    • Ich betreibe eines der größten Wikis in meinem Bereich, und es ist nahezu unmöglich, die anderen im Entwicklerteam davon zu überzeugen, eine gzip bomb zu verwenden. Sie beharren darauf, dass diese Methode zu riskant sei und sich nicht lohne — mit einer Haltung im Sinne von „wegen EU-Regeln lieber nicht“. Ich frage mich, ob das wirklich irgendwo auf öffentlichen Websites eingesetzt wird.

  • In letzter Zeit respektieren Bots die Datei robots.txt überhaupt nicht mehr, und das macht mich wirklich wütend. Ich finde die Leute, die so etwas gebaut haben, extrem egoistisch. Wenn jemand solche Bots baut, soll er sich selbst darum kümmern.

    • Wenn man Fallen in die robots-Datei einbaut, also eine Art Honeypot, hilft das immerhin dabei, Bots herauszufiltern, die zwar nicht alles komplett ignorieren, aber absichtlich Ärger machen wollen.

    • Dasselbe könnte man auch Leuten sagen, die Chatbots, Suchmaschinen oder Preisvergleichstools benutzen. Genau solche Nutzer sind wirtschaftlich gesehen eigentlich die Haupttreiber hinter diesen Scrapern.

  • Ich verstehe zwar, dass der Autor gesagt hat, er kümmere sich inzwischen nicht mehr darum, aber ich habe gesehen, dass auf der Liste gesperrter IPs Google, ripe.net und Semrush stehen. Andere Unternehmen lasse ich mal außen vor, aber Google würde ich wirklich nicht blockieren. Wenn man seine Website bekannt machen will, sehe ich auch keinen Grund, Semrush oder ripe.net zu sperren. Selbst wenn meine Inhalte von AIs oder anderen seltsamen Akteuren gescrapt werden, sollte man meiner Meinung nach von Anfang an damit rechnen, dass eine öffentliche Website bis zu einem gewissen Grad genutzt wird. Das ist sonst, als würde man das Schild eines Motels ausschalten und trotzdem Gäste einladen.

    • Semrush hat über lange Zeit auf mehreren Ebenen wirklich massiv genervt, so sehr, dass ich seit acht Jahren sogar besondere Hinweise in meiner robots.txt hinterlasse. Am Ende musste ich sogar die Rechtsabteilung einschalten, um sie endlich etwas zu beruhigen. Aus meiner Sicht hat es keinen Wert, einem „SEO“-Unternehmen zu erlauben, die Seite rabiat leerzusaugen und dabei echte Besucher zu verdrängen. Die Konkurrenten von Semrush waren genauso schlimm. Auch die heutigen AI-Scraper sind so unerquicklich, dass ich wiederholt formelle Beschwerdeschreiben an große Investoren und PR-Abteilungen schicken musste. Technisch wie rechtlich habe ich auf verschiedenste Weise gerade noch einen halbwegs normalen Zustand wiederhergestellt.

    • Das eigentliche Problem ist, dass Bots in großem Umfang Traffic und damit Bandbreite, Speicher, CPU und Festplattenressourcen belegen. Darauf wird auch in der Einleitung als inakzeptabel schlechtes Benehmen hingewiesen. Ich sehe keinen Grund, solchen Traffic auch noch freiwillig an Scraper zu liefern. Google betreibt ebenfalls AI-Scraper, daher ist es gut möglich, dass genau deshalb etwas von dort auf der Sperrliste gelandet ist.

    • Es gibt auch echte bösartige Bots, die sich als Google ausgeben. Früher hat Google vergleichsweise höflich gescrapt, aber wenn der Autor den benötigten Traffic ohnehin schon bekommt, egal ob er Google blockiert oder nicht, gibt es für ihn keinen Grund, sich darum zu kümmern.

    • Ich frage mich, ob die Leute in den letzten zehn Jahren wirklich noch nicht mitbekommen haben, dass man Google nicht benutzen sollte — besonders jetzt, wo Google mit AI unabhängige Websites zensiert. Hier ist auch direkt der relevante Kommentar verlinkt. Inzwischen ist Google meiner Ansicht nach eher ein Risiko als ein Vorteil.

  • Wegen der Bots werden meine Server-Logdateien so groß, dass ich auf meinen Servern das Logging inzwischen ganz abgeschaltet habe. Die Bots kratzen hartnäckig APIs, Formulare und sogar Bereiche der Website ab, die man eigentlich nur per Klick erreichen kann. Anthropic, OpenAI, Facebook und andere scrapen meine Seiten weiterhin.

    • Wenn es um APIs geht, die nur per Klick erreichbar sind: Wie greifen Bots dann darauf zu?

    • Ich würde darüber mit diesen APIs gern mehr erfahren. Ich möchte klarer verstehen, ob damit Teile der UI gemeint sind oder Bereiche, die eigentlich nur Menschen benutzen, oder ob es wirklich gar keinen anderen Zugangsweg gibt. In letzter Zeit ahmen AI-Agenten das Verhalten echter Nutzer nach, sodass es fast unmöglich geworden ist, Menschen und Bots zu unterscheiden.

  • Ich fand es eigentlich gut, dass AI-Crawler-Bots den Header User-Agent ehrlich ausfüllen, aber ich bin etwas überrascht, dass sie offenbar so viel Traffic verursachen. Die meisten Websites brauchen solche Daten doch gar nicht so häufig, und trotzdem ist das Verkehrsaufkommen enorm. Bei einem Entwicklerblog verstehe ich das umso weniger.

    • Die meisten AI-Crawler halten sich an robots.txt, aber es gab auch Fälle, in denen sie nach einer Sperre oder Blockierung sofort auf einen Browser-User-Agent gewechselt haben und dann von Wohn-IP-Adressen aus erneut zu crawlen versuchten. Da es allerdings sehr viele Fälschungen gibt, die sich als OpenAI, Amazon oder Facebook ausgeben, sollte man bei der genauen Einordnung vorsichtig sein.

  • Ich bin der Entwickler von tirreno. Unsere Plattform ist zwar für live eingeloggte Nutzer optimiert, lässt sich aber auch wirksam für Bot-Erkennung und -Blockierung einsetzen. Wir anonymisieren IPs, indem wir das letzte Oktett durch ein Sternchen (*) ersetzen und so dieselbe Subnetzgruppe als ein gemeinsames Konto behandeln. Für Verkehrsauffälligkeiten wie 500/404-Fehler, Brute-Force-Loginversuche oder Rechenzentrums-IPs kann man automatisch Blacklists erzeugen lassen. Über die Blacklist-API von tirreno lässt sich unerwünschter Traffic auf eine Fehlerseite umleiten. Es gibt auch ein Monitoring-Dashboard, das beim Verwalten und beim Vermeiden von False Positives hilft.
    tirreno Github, Admin-Demo

    • Viele ISPs setzen inzwischen auf CGNAT, sodass eine einzelne IP Hunderte reale Nutzer repräsentieren kann. Mich würde interessieren, wie ihr damit umgeht.

    • Ich entwickle ebenfalls Bot-Blockierung auf Basis veröffentlichter IP-Bereiche. Ideen zur Verbesserung sind jederzeit willkommen.

    • Durch das Ersetzen des letzten IP-Oktetts werde ich mit Nachbarn zu einem einzigen Nutzer zusammengefasst, die mit meinen tatsächlichen Daten überhaupt nichts zu tun haben. Auch False Positives durch Rechenzentrums-IPs sind nicht zu unterschätzen. Wenn tatsächlich nichts blockiert ist, muss ich mich am Ende trotzdem irgendwie durch 87 Ampeln klicken, um durchzukommen. Es wirkt letztlich so, als diene das vor allem dazu, behaupten zu können, man sammle meine personenbezogenen Daten nicht ohne Zustimmung — selbst während man Schritte einbaut, um False Positives zu umgehen. Bitte sorgt unbedingt für eine Feedback-Struktur, durch die Kunden sofort merken, dass ihnen dadurch tatsächlich zahlende Nutzer verloren gehen.

  • Ich frage mich schon länger, ob nicht eine Art „page knocking“ möglich wäre — also Zugriff nach dem Muster, dass man Seiten in einer bestimmten Reihenfolge aufrufen muss, um Zugang zu bekommen. Beispielsweise müsste man zuerst eine bestimmte private URL aufrufen, bevor die übrigen Seiten statt 404 wieder normal ausgeliefert werden.

    • Eine solche Architektur passt nicht zu Fällen, in denen normale Nutzer ein Projekt direkt über Suchmaschinen finden und sofort ohne Kontoerstellung oder zusätzliche Authentifizierung loslegen können sollen.

    • Was die Nutzbarkeit angeht, würde das selbst bei guter Gestaltung zwangsläufig unbequem werden. Schon mit Lesezeichen oder beim Versenden eines Links an Freunde würde man wahrscheinlich ständig nur auf 404 stoßen.

  • Mein kleiner Server läuft eigentlich stabil, deshalb hatte ich mir den Status von fail2ban zuletzt gar nicht mehr angesehen.
    Vergleich der Befehlsausgabe:

    sshd-ddos:      0
postfix:       583
dovecot:     9690
postfix-sasl: 4227
nginx-botsearch: 1421
nginx-http-auth: 0
postfix-botnet:  5425
sshd:         202157

Ich war etwas schockiert, als ich gesehen habe, dass mehr als 220.000 IPs blockiert sind.

  • Der Bot „DotBot/1.2“, den wir verfolgen, hat in den letzten zwei Wochen mehr als 220.000 Requests hinterlassen. Das Muster besteht darin, zufällig Dateinamen und Verzeichnisnamen auf dem Webserver anzufragen. Aus Neugier lasse ich ihn absichtlich ungebremst laufen, um zu sehen, wie weit er geht.

  • Ich frage mich, ob die zentralisierte Indexierung für AI oder Suchmaschinen nicht inzwischen auf ein Push- oder Einreichungsmodell umgestellt werden sollte. Wenn ich Inhalte nur dann selbst teile, wenn ich es möchte, würde das viele Scraping-Probleme deutlich reduzieren.

  • Als ich in den 90ern noch ein Kind war, bekam ich einmal einen Anruf von meinem ISP, dass mein Computer Teil eines Botnets sei und deshalb mein Internetzugang abgeschaltet werde. Vielleicht sollte man zu solchen Zeiten zurückkehren und einfach das gesamte ASN eines ISP blockieren, wenn er so ein Verhalten zulässt.

    • Residential Proxies werden nicht direkt von ISPs bereitgestellt. Sie entstehen vielmehr dadurch, dass Nutzer irgendwo auf der Welt absichtlich oder unwissentlich Malware installieren und damit ihren Rechner als Proxy zur Verfügung stellen. Vor Kurzem gab es dazu auch einen guten Artikel auf HN.

    • Ich habe eine Firewall-Regel eingerichtet, die jedes Mal einen Alarm auslöst, wenn ein bestimmtes Gerät in meinem Netzwerk versucht, ausgehend eine Verbindung zu Ports herzustellen, die mit Malware in Verbindung stehen. Die Portliste muss regelmäßig aktualisiert werden, weil sich die Ziele von Malware ständig ändern. Es ist nur eine kleine Maßnahme, aber eben eine weitere Verteidigungsschicht.