- Fälle, in denen persönliche Server durch übermäßige Anfragen von AI-Scraping-Bots lahmgelegt werden
- Die Log-Analyse zeigte konzentrierte Zugriffsversuche aus dem in Singapur gehosteten IP-Bereich (47.79.*) von Alibaba(US) Technology
- Durch einen gefälschten User-Agent im Stil von
Mozilla/5.0 werden gängige Bot-Erkennungssysteme wirkungslos
- Die automatischen Blockiersysteme von Fail2ban und Nginx wurden überlastet, sodass der gesamte IP-Bereich manuell gesperrt werden musste
- Weil persönliche Serverbetreiber wiederholt angegriffen werden, geraten selbst gehostete Umgebungen unter Druck und werden in Richtung zentralisierter Plattformen gedrängt
Ursache des Serverausfalls und erste Reaktion
- Vor einigen Tagen wurde der kleine Server, der die Website hostete, durch einen Scraping-Bot-Angriff vorübergehend außer Betrieb gesetzt
- Ähnliche Angriffe hatte es auch früher schon gegeben, und die Einführung eines starken Abwehrwerkzeugs wie Anubis wird erwogen
- Durch die wiederholten Angriffe nehmen bei einzelnen Entwicklern Schaffensdrang und die Freude am Hobby ab
- Nachdem sich der Serverzugriff verzögert hatte, zeigte eine Prüfung mit dem Befehl
top, dass Gitea und Fail2ban fast die gesamte CPU belegten
- Selbst nach dem Beenden des Gitea-Prozesses sank die Last von Fail2ban nicht, und die Nginx-Access-Logs liefen über
Log-Analyse und Angriffsmuster
- In den Logs wurden zahlreiche HTTP-502-Anfragen aufgezeichnet, die auf den Pfad
/commit/ zielten
- In den Request-Headern wurden als normale Browser getarnte User-Agents wie
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) verwendet
- Die meisten Prüfwerkzeuge für User-Agents stuften dies als normalen Traffic ein und umgingen so die Erkennung
- Die Angriffs-IP-Adressen kamen nicht aus einer einzigen Quelle, sondern von mehreren Adressen, nutzten aber gemeinsam den Bereich
47.79.*
- Eine Abfrage bei
ipinfo.io ergab, dass dieser Bereich Alibaba(US) Technology Co., Ltd. gehört
- Auch in PhpBB-Foren und anderswo gibt es Berichte über Angriffe aus demselben IP-Bereich
Gegenmaßnahmen und ihre Grenzen
- Fail2ban analysierte die Nginx-Logs in Echtzeit und wendete Blockierregeln an, doch durch die explosionsartig anwachsenden Logs kam es zu Verarbeitungsverzögerungen
- Es wurde ein Skript ausgeführt, das IPs bei Zugriffen auf
/commit/ sofort blockieren sollte, doch es gab Geschwindigkeitsgrenzen
- Schließlich wurde per
iptables der gesamte Bereich 47.79.0.0/16 manuell blockiert
- Diese Reaktion ist nur eine Notlösung, und Angriffe aus neuen IP-Bereichen werden wahrscheinlich weitergehen
- Es wird erwogen, externe Schutzdienste wie Cloudflare oder fortgeschrittene Abwehrsysteme wie Anubis einzuführen
- Allerdings besteht Zurückhaltung, weil man keinen Umweg über US-Server mit Tracking-Funktionen möchte
Die Schwierigkeiten beim Betrieb persönlicher Server
- Es wird erwogen, die Gitea-Instanz zu Codeberg zu migrieren
- Persönliche Serverbetreiber neigen aufgrund wiederholter Angriffe dazu, Self-Hosting aufzugeben und auf zentralisierte Plattformen umzuziehen
- Dieser Trend führt zu einer Schwächung der Dezentralität und Autonomie des Internets
- Auch andere Blogger berichten von ähnlichen Angriffen, und das Problem breitet sich auf kleine Webbetreiber insgesamt aus
Weitere beobachtete auffällige Traffic-Muster
- Es wurden gefälschte Referer-Header entdeckt, die auf Domains großer Unternehmen wie
bioware.com, mcdonalds.com und microsoft.com verweisen
- Tatsächlich hatten diese Websites keine entsprechenden Links gesetzt, und es zeigte sich ein Anstieg von Traffic mit unklarem Zweck
- Selbst wenn sich die Angriffe wiederholen, wird der Wille bekundet, Self-Hosting nicht aufzugeben
- Am Ende des Beitrags wird mit dem Satz „Get Hostin’ Or Die Tryin’“ der Entschluss betont, autonome Server weiter zu betreiben
1 Kommentare
Hacker-News-Kommentare
Es fühlt sich so an, als wäre das Internet kein sicherer Ort mehr für Software-Hobbyentwickler
Ich betreibe seit etwa 2005 eigene Server, und ab dem Moment, in dem ein Server online geht, wird er immer angegriffen
Vor allem wenn man einen DNS-Namen vergibt oder ein TLS-Zertifikat verwendet, scheint sich das durch die Sichtbarkeit in Certificate-Transparency-Logs noch zu verschlimmern
Sobald man eine Website veröffentlicht, wird man mit bösartigem Traffic überschwemmt, und wenn man eine bestimmte Organisation verärgert, wirkt es fast so, als würde jemand dafür bezahlt, einen DDoS-Versuch zu starten
Crawler, Botnets, automatisierte Angriffe, wütende Leute — das erlebt man jedes Jahr
Ich habe verschiedene Hosting-Anbieter ausprobiert, aber das Ergebnis war ähnlich
Als ich WordPress nicht aktualisiert habe, wurde es innerhalb weniger Stunden mit SEO-Spam infiziert, und als ich Redis versehentlich nach außen offen hatte, wurde ein Botnet-RAT installiert
Trotzdem finde ich nicht, dass das bedeutet, das Internet sei „gefährlich“
Eher waren das Erfahrungen, die mir gezeigt haben, was ich lernen muss
Danach habe ich star-cert verwendet, damit es nicht in Zertifikats-Logs auftaucht, Basic Auth ergänzt, Backups gepflegt und vorsichtiger betrieben
Die eigentliche Gefahr ist meiner Meinung nach, wenn technisch unerfahrene Menschen irgendeine exe installieren und all ihre Informationen an Facebook oder TikTok abgeben
Die meisten Requests zielen auf WordPress-Schwachstellen, obwohl ich noch nie WordPress verwendet habe
Als ich die Logs zum ersten Mal gesehen habe, war ich schockiert, aber inzwischen nehme ich das einfach als Teil des Alltags hin
Beispiel: https://www.masswerk.at/wp-admin
Das war die Zeit, in der sich Tools verbreiteten, die IP-Bereiche scannten und Schwachstellen automatisch fanden
Ich vermisse das Web zwischen 1995 und 2008, als es noch Web Rings, Technorati und Fanseiten gab
Referenz: Script Kiddie Wiki
Früher habe ich zipbombs eingesetzt, um Bots zu blockieren, und das hatte Wirkung
Aber nachdem ich das auf HN gepostet hatte, strömten neue Bots herbei, und mein 6-Dollar-Server hielt das nicht mehr aus
100.000 Requests pro Tag mit Payloads von 1–10 MB auszuliefern, war unmöglich
Danach habe ich nur noch bestimmte Bots ins Visier genommen, ein Honeypot eingerichtet, IPs gesammelt und mit 403 geantwortet
Nach ein paar Monaten war der Traffic wieder auf normalem Niveau
Allerdings weiß ich nicht, wer die Zielkunden wären. Die meisten Self-Hosting-Nutzer haben nicht viel Geld
Auch mein cgit-Server wird seit einem Jahr ständig von Scrapern besucht
Allerdings sind es nur 2–3 Requests pro Minute, also ein ziemlich „höflicher“ Bot
Das Lustige ist, dass sich der gesamte von mir hochgeladene Code direkt upstream klonen lässt und trotzdem auf diese Weise abgegriffen wird
Wenn man die Logs ansieht, ist das wirklich eine sehr ineffiziente Automatisierung
Wenn man die Rate-Limiting-Funktion von Nginx direkt konfiguriert, lässt sich das einfacher lösen als mit Fail2ban
Referenz-Blog: https://blog.nginx.org/blog/rate-limiting-nginx
Bei öffentlichen Diensten wie Blogs ist das schwer anzuwenden, aber für persönliches Self-Hosting würde ich empfehlen, mTLS-Authentifizierung am Reverse Proxy zu konfigurieren
Requests ohne Zertifikat werden sofort blockiert, und nur meine Geräte können zugreifen
Wenn man es einmal eingerichtet hat, muss man sich danach kaum noch darum kümmern
Die Einrichtung ist einfach, und es funktioniert auch unter Android und iOS gut
Ich habe inzwischen alle Self-Hosting-Dienste so konfiguriert, dass sie nur innerhalb eines Wireguard-VPN erreichbar sind, und in der Firewall ist nur der Wireguard-Port offen
Anubis schlägt sich gut in diesem Katz-und-Maus-Spiel mit Bots
Aber nur Anbieter mit großen Traffic-Datensätzen wie Cloudflare können Blockierungen auf Basis von IP-Reputation wirklich gut umsetzen
Kleine Betreiber können oft nur ganze IP-Bereiche blockieren, was ineffizient ist
Es braucht eine Lösung wie Crowdsec, die Reputationsdaten teilt, bösartige IPs blockiert und einfache Challenges ohne JS anbietet
Wenn so ein Ansatz möglich wäre, könnten auch Hobbyentwickler wieder leichter Dienste betreiben
Auch meine Gitea-Instanz wurde kürzlich über verteilte IPs und ASNs gescrapt
Wenn dahinter finanzstarke AI-Unternehmen stehen, dürfte selbst Anubis sie kaum aufhalten
Deshalb denke ich über Scraper Poisoning nach — also darüber, statt Code nur noch Müll-Daten auszuliefern
Solche Dienste machen Scraping noch schwerer abzuwehren
Beliebte Dinge durchlaufen am Ende offenbar immer einen Zyklus, in dem sie in die Hände der Masse fallen und kaputtgehen
Deshalb fühlt es sich so an, als sei der einzige Ausweg, immer weiter in neue Bereiche zu ziehen
Nachdem ich DNS zu Cloudflare umgezogen habe, kommen ständig merkwürdige SYN-Pakete herein
Es gibt jede Sekunde Anfragen an Port 443 oder 22, aber nach dem SYN-ACK kommt keine Antwort mehr
Die meisten scheinen von VPS-Game-Server-Hostern aus Brasilien und ähnlichen Orten zu kommen
Deshalb schneide ich SYN-Pakete mit, mache RDAP-Lookups und blockiere dann die Subnetze dieser Organisationen komplett
Nur Google bleibt auf der Whitelist
DigitalOcean scheint eine der Hauptquellen für bösartigen Traffic zu sein
Der Netzwerk-Stack versucht erneut zu senden, wodurch der Traffic verstärkt beim Opfer landet
Oft wird die src IP gefälscht, daher würde ich empfehlen,
rp_filterauf strict zu setzenSo wie ein Stromversorger keine roten Glühbirnen verbietet, ist es nicht wünschenswert, dass Dienstanbieter den Traffic kontrollieren
Der Grund, warum ich diesem Beitrag zustimme, ist nicht, dass das Internet sicher wäre, sondern dass hier diese Realität dokumentiert wurde
Ich blockiere ebenfalls Alibaba /16 und den gesamten AWS-Bereich
Ich verwende ein Skript, das täglich per Cron RouteViews-Daten herunterlädt und sie in iptables anwendet
Beispielcode:
Ich wünschte, andere Clouds würden das ebenfalls so anbieten