Mit vielen kleinen Tools Bots blockieren

(lambdacreate.com)

4 Punkte von GN⁺ 2025-06-02 | Noch keine Kommentare. | Auf WhatsApp teilen

Gitea und das Blog auf einem privaten Server wurden von Scraping-Traffic überlastet, woraufhin Warnungen zu Festplatte, CPU und Arbeitsspeicher auftraten; der Betreiber kombinierte Log-Analyse, Nginx und Fail2Ban zur Abwehr
Laut Zabbix lag der Traffic deutlich über dem Normalniveau; im Monatsmittel verzeichnete Nginx 8 Anfragen pro Sekunde, in der schlimmsten Phase stieg der Wert auf 20+ Anfragen pro Sekunde
Ursache war kein einzelner Traffic-Peak von Reddit oder Hacker News, sondern eher verteiltes Scraping, bei dem mehrere IP-Blöcke URLs von www.lambdacreate.com und krei.lambdacreate.com abriefen
Nginx gab für bekannte bösartige User Agents 403 zurück und setzte Request-Limits pro IP um; Clients, die übermäßig viele 403-Antworten auslösten, wurden per Fail2Ban für 24 Stunden gesperrt
Zum Zeitpunkt der Erstellung war die Blockliste auf insgesamt 735 Bans angewachsen; insbesondere Anfragen, die für alle Commits öffentlicher Gitea-Repositories Tarballs erzeugen wollten, erhöhten die Serverlast

Scraping-Traffic setzt privaten Server unter Druck

Unerwünschter Bot-Traffic traf plötzlich den privaten Internetbereich und beeinträchtigte sogar Dienste, die für echte Leser erreichbar sein sollten
Dienste wie Archive.org, die Websites zum Zweck der Bewahrung indexieren, gelten als erlaubt; Amazon, Facebook, OpenAI und diverse zufällige Bots werden dagegen als Akteure eingeordnet, die Inhalte für eigene Zwecke verbrauchen
Die umfassende Sammlung von Internetdaten durch große Unternehmen und der Datenbedarf zum Training von KI-Modellen werden als Faktoren gesehen, die den Scraping-Druck weiter erhöhen
Dieser Traffic wird nicht als echte Nutzung von Lambdacreate betrachtet, sondern als Störfaktor, der den Zugang für menschliche Leser verschlechtert

Den ersten Hinweis auf das Problem lieferte Zabbix mit einer Warnung, dass die Festplatte für Container vollgelaufen sei
In einer LXD-basierten Umgebung wurde eine ZFS Sparse File erweitert und die Site kurz herunter- und wieder hochgefahren, doch die eigentliche Ursache blieb bestehen
Danach verbrauchte die Gitea-Instanz täglich die gesamte Festplatte und erzeugte pro Tag 20–30 GB an Daten
Zunächst wurde vermutet, dass Gitea die Bereinigung von Repository-Archiven nicht standardmäßig aktiviert, weshalb eine aggressive Bereinigung eingerichtet wurde
Bald folgten auch CPU- und Arbeitsspeicherwarnungen; in Gitea wurden git pull und git push schwierig, und auch der weechat-Client konnte die Verbindung nicht halten

Dank Out-of-band-Monitoring zum Vergleich früherer Metriken mit dem aktuellen Zustand ließ sich ein anormales Muster erkennen
Im Zabbix-Dashboard waren die wichtigsten Metriken die Anzahl der Nginx-Anfragen und Graphen zum Netzwerkdurchsatz
Über einen Monat betrachtet lag das durchschnittliche Nginx-Anfragevolumen bei etwa 8 Anfragen pro Sekunde
In der schlimmsten Phase gingen 20+ Anfragen pro Sekunde ein; für große Dienste ist das wenig, für einen privaten Server entsprach es jedoch dem Zehnfachen des Normalwerts und hatte entsprechend große Auswirkungen
Neben der reinen Zahl der Anfragen stiegen auch die Gitea-bezogene Festplatten- und CPU-Nutzung, was den Betriebsaufwand für den Server erhöhte

Um den Server lange genug am Leben zu halten und Logs prüfen zu können, wurden Container und Nginx kurz abgeschaltet und die Analyse gestartet
Eingesetzt wurden lnav und goaccess
lnav zeigt Logdateien in einer farbigen TUI an und bietet über gängige Logformate hinweg eine Abstraktionsschicht, sodass Logs per SQL-Abfrage untersucht werden können
In access.log standen folgende Fragen im Mittelpunkt
- Wie viele Besucher-IPs es insgesamt gibt
- Ob es Muster bei den IP-Adressen gibt
- Ob der Traffic von einem bestimmten Referrer kommt
- Welche User Agents verwendet werden
- Welche IPs mit welchen User Agents verbunden sind
Die Analyse ergab, dass es sich nicht um einen „hug of death“ von einem einzelnen Referrer handelte, sondern dass mehrere IP-Blöcke URLs auf der gesamten Site scrapten

Die erste Gegenmaßnahme bestand darin, in Nginx problematische User Agents aufzulisten und dafür 403 zurückzugeben
Die Beispielkonfiguration nutzt map $http_user_agent $badagent, um Agents wie AdsBot-Google, Amazonbot und Amazonbot/0.1 zu markieren
In der grundlegenden Nginx-Konfiguration werden die User-Agent-Regeln eingebunden und zusätzlich Rate Limits pro IP eingerichtet
Die Virtual-Host-Konfiguration enthält folgendes Verhalten
- Anwendung eines Request-Limits mit limit_req zone=krei burst=20 nodelay;
- Wenn $badagent wahr ist, Blockieren des Content-Zugriffs mit return 403;
Diese Methode hilft, Backend-Verarbeitung zu reduzieren; da der Server die HTTP-Anfragen aber dennoch annehmen und mit 403 beantworten muss, bleibt bei vielen gleichzeitigen Anfragen weiterhin Last bestehen

Nachdem sich 403-Logs angesammelt hatten, ließen sich mit lnav die eindeutigen IPs ermitteln, die 403 erhalten hatten
goaccess wurde genutzt, um frühere und aktuelle Logs gemeinsam zu analysieren und die Zahl der eingehenden Anfragen sowie die am häufigsten anvisierten Endpunkte zu prüfen
Zum tatsächlichen Schutz des Servers wurde Fail2Ban ergänzt
Die Fail2Ban-Regel ist eine einfache Variante, die IPs erfasst, die im Nginx Access Log übermäßig viele 403-Antworten auslösen
Die Sperrdauer wurde auf 86400 Sekunden, also 24 Stunden, gesetzt
Das Ergebnis von fail2ban-client status nginx-forbidden zum Zeitpunkt der Erstellung lautete wie folgt
- Aktuelle Fehlschläge: 13
- Fehlschläge insgesamt: 57135
- Aktuelle Sperren: 38
- Sperren insgesamt: 735

Letztlich konnten Leser wieder auf das Blog und die anderen Dienste von Lambdacreate zugreifen
In einer Situation, in der Robot-Traffic abgewehrt werden muss, ist es sogar schwierig, Blogbeiträge zu schreiben
Der problematische Traffic zielte nicht auf Blog-Scraping, sondern darauf, für jedes öffentliche Repository der Gitea-Instanz zu jedem Commit Tarballs zu erzeugen
Langfristig soll darüber nachgedacht werden, die Blockliste zu erweitern oder Ausnahmen für legitime Dienste wie Archive.org vorzusehen
Die Haltung ist, dass die Inhalte nicht aus Suchmaschinen verschwinden sollen, man sie aber auch nicht als Brennstoff für die KI-Verschlechterung des Internets bereitstellen möchte