Wenn es Probleme gibt, blockieren Sie auf IP-Ebene
(boston.conman.org)- Bei einer aktuellen Analyse des Web-Traffics wurde festgestellt, dass ein Webbot namens Thinkbot den meisten Traffic verursachte
- Der Bot ignoriert
robots.txt, und selbst seine Selbstbeschreibung ist äußerst nachlässig und läuft im Grunde auf „Wenn es Probleme gibt, blockieren Sie die IP“ hinaus - Innerhalb eines Monats nutzte er 74 verschiedene IPs, verteilt auf 41 Netzwerkblöcke
- Die Untersuchung ergab, dass all diese Netzwerkblöcke Tencent gehörten, was den Verdacht aufkommen ließ, ob dies mit einer möglichen Abwälzung der Kosten der Great Firewall zusammenhängt
- Letztlich wurden umfangreiche Blockierregeln hinzugefügt, die mehr als 470.000 IPs umfassen
Das Auftauchen von Thinkbot
- Bei der Analyse des Web-Traffics fiel auf, dass ein Webbot namens Thinkbot einen Spitzenanteil einnahm
- Die User-Agent-Zeichenkette war wie folgt auffallend nachlässig
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- Außer dem Hinweis „Wenn es in der Testphase Probleme gibt, blockieren Sie bitte die IP“ gab es nicht einmal eine Referenz-URL
- Das Crawling erfolgte, ohne die Datei
robots.txtin irgendeiner Weise zu respektieren - Selbst wenn man als Website-Betreiber den Bot blockieren wollte, nutzte er nicht nur eine einzelne IP, sondern 74 IP-Adressen
- Eine Rückverfolgung mit ASN-Abfrage zeigte, dass der Traffic aus 41 Netzwerkblöcken stammte
- Das bedeutet, dass eine einfache Sperre einer einzelnen IP zur Abwehr nicht ausreicht
Verbindung zu Tencent
- Diese 41 Netzwerkblöcke gehörten alle Tencent
- Der Autor vermutet, dass die chinesische Regierung dies dulden oder sogar fördern könnte und dass es als Versuch interpretiert werden kann, die Kosten der Great Firewall auf die Außenwelt abzuwälzen
- Innerhalb Chinas ist das Sammeln von Inhalten erlaubt, und selbst wenn es von außen blockiert wird, ist das aus Sicht der CCP kein Problem, während andere Länder und Websites, die eine Blockierung versuchen, die Last tragen müssen
Firewall-Sperrmaßnahmen
- Der Autor fügte die Tencent-Netzwerkblöcke direkt zu den badbots-Firewall-Regeln hinzu
- Beispiele:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19usw. - Insgesamt wurden gut 40 Netzwerkblöcke hinzugefügt; sie decken zwar nicht sämtliche Tencent-IP-Bereiche ab, umfassen aber mehr als 476.590 eindeutige IPs
Fazit und Metapher
- Der Autor beschreibt diese Situation als die Realität, dass man im Internet nichts Gutes mehr haben kann
- Es ist ein Beispiel, das über die bloße Abwehr von Bot-Traffic hinaus den allgemeinen Vertrauensverlust im Internet-Ökosystem und unvermeidliche defensive Reaktionen zeigt
6 Kommentare
Wenn es Probleme gibt, blockiert auf IP-Ebene
Tatsächlich ist die Bedrohung durch China in anderen Bereichen schon seit Langem Realität, und nun scheint China sogar den Fortbestand des gesamten Internet-Ökosystems insgesamt zu gefährden.
Das ist nicht einfach eine Aussage, die auf Ablehnung oder politischer Voreingenommenheit beruht; viele Menschen sollten erkennen, dass das tatsächlich Wirklichkeit wird.
Warum sind solche Vorfälle, wenn man genauer hinschaut, jedes Mal die CCP..
Wow … wirklich großartig …
Top..
Schon wieder China.
Hacker-News-Kommentare
Während ich einen Webcrawler entwickelt habe, habe ich versucht, ihn so freundlich wie möglich zu gestalten. Er prüfte
robots.txtstrikt, crawlete langsam, wies sich im User-Agent-String klar aus und nutzte nur eine einzige IP-Adresse. Trotzdem bin ich auf allerlei Anti-Bot-Tricks gestoßen, die sogar auf dierobots.txt-Datei selbst angewendet wurden. Kürzlich wurderobots.txtextrem langsam ausgeliefert, fast wie bei einem Slow-Loris-Angriff, sodass ich sie versehentlich als 404 behandelte und weiter crawlete. Nach dieser Erfahrung habe ich den Code so geändert, dass bei einem TimeoutDisallow /gilt. Ironischerweise landet man selbst dann beim Schreiben von Code zur Erkennung von Anti-Bot-Tools, wenn man sich eigentlich besonders regelkonform verhalten willDas fühlt sich an, als würde man die Türklingel verstecken, um Diebe abzuhalten
Wie bei Serveranwendungen kappe ich auch auf Client-Seite still die TCP-Verbindung, wenn sich die Gegenseite bösartig oder fehlerhaft verhält. Dann soll sie eine Weile Ressourcen verschwenden und selbst merken, was los ist
Ich denke, es ist gut möglich, dass das gar nicht absichtlich passiert. Bösartige Bots, die sich ohnehin nicht an
robots.txthalten, laden die Datei von vornherein gar nicht erst herunter, daher könnte es eher ein Versehen oder Inkompetenz als böse Absicht seinSanktionen, die nur diejenigen bestrafen, die sich an die Regeln halten wollen, wirken meiner Meinung nach eher kontraproduktiv
Ich schätze sehr, dass du dich ernsthaft bemühst, die Regeln einzuhalten. Einschränkungen bei
robots.txtkönnten ein Versehen sein, aber manche Crawler finden gerade überrobots.txtinteressantere Seiten, daher kann es helfen, genau das zu verlangsamen, um kurzfristig Probleme zu vermeiden. Am Ende blockiert und bremst diese Vorgehensweise Bots, und aus Sicht von Website-Betreibern ist der Schaden durch bösartige Bots so groß, dass sie oft gar nicht mehr groß zwischen ehrlichen und unehrlichen Bots unterscheidenIch frage mich, was Websites gemeinsam haben, die durch Bots wirklich massiv geschädigt werden. Ich habe jahrelang von zu Hause aus einen Webserver unter einer
.com-TLD betrieben, ranke für relevante Keywords bei Google recht weit oben und hatte weder auf dem Router noch auf dem Server besondere Bot-Sperren eingerichtet. Aus Neugier habe ich zwar einmal nur die Bot-Anfragen gezählt, aber meistens waren das nur Portscans oder Abrufe der Index-Seite, und dynamisch geladene Links wurden fast nie verfolgt. Weder zu Apache-2-Zeiten noch heute, wo ich mehrere Sites mit Axum betreibe, sehe ich nennenswerte Auswirkungen durch Bots. Ich frage mich, ob es vielleicht an Directory Listings liegt, und wäre an einer Erklärung interessiertIch habe das Gefühl, dass sich viele kluge Leute beim Thema Web-Scraping zu sehr daran festbeißen. Solange Bot-Aktivität die Website nicht tatsächlich stark belastet oder echte Probleme verursacht — Ausnahmen gibt es natürlich — ist das meiste nur ein sinnloses „Capture the Flag“-Spiel. Der Unterschied ist nur, dass niemand die Flagge des anderen findet und alle bloß Zeit verlieren. Der beste Umgang damit ist meiner Ansicht nach, schnelle und gut entworfene Webprodukte zu bauen, die auch dann robust bleiben, wenn sich schwer identifizierbare Teilnehmer ausbreiten und Last erzeugen. Realistisch gesehen verbessert dieser Ansatz auch die Zufriedenheit echter Nutzer erheblich
Meiner Erfahrung nach unterschätzt du vielleicht, wie gravierend das Problem sein kann. In meinem früheren Job war ich für die Anwendungs-Performance einer Web-App zuständig, und einige Nutzer waren blitzschnell unterwegs, während die meisten langsam waren. Bei der Analyse der Performance-Logs stellte sich heraus, dass 60 % aller Requests von bekannten Bots kamen, obskure Bots noch gar nicht eingerechnet. Einige Unternehmen haben den Dienst sogar mit DoS-Angriffen belegt, wodurch die Site zeitweise ausfiel. Das Problem ist, dass Bots fast immer nur gecachte Antworten abrufen, sodass echte Nutzerinteraktionen ständig aus dem LRU-Cache verdrängt werden. Manche Bots scrapen alle zuvor besuchten Seiten alle paar Minuten erneut, andere erhöhen den Durchsatz so lange, bis der Dienst spürbar langsamer wird. Manchmal führen sie sogar JavaScript aus und versuchen, Formulare abzusenden. Nur Googlebot verhält sich konsequent höflich. Gleichzeitig konzentrieren sich 40 % des tatsächlichen Traffics auf nur eine einzige URL, sodass durch Bots kaum irgendein Nutzen entsteht. Erst später wurde mir klar, dass viele dieser Bots zur Datensammlung früher AI-Unternehmen dienten
Ein Freund betreibt eine kleine öffentliche Gitea-Instanz, die nur von Freunden genutzt wird. Trotzdem bekommt sie stündlich Tausende Bot-Anfragen. Selbst wenn der Dienst dadurch nicht direkt beeinträchtigt wird, fühlt es sich zumindest wie Belästigung an
Ich bezahle einen Aufpreis für Daten, damit ich ein schnelles Webprodukt bereitstellen kann. Wenn ich solche Entitäten blockiere, ist das also keine Zeitverschwendung, sondern spart ganz real Bandbreite und Serverkosten. Echte Kunden erhalten dadurch dieselben Vorteile, ohne dass ihre Inhalte abgescrapt werden müssen. Ich verstehe die Logik nicht, nach der man sich dabei angeblich ausbeuten lässt
Ich würde es eher mit Whac-A-Mole als mit „Capture the Flag“ vergleichen. Nach meiner Erfahrung tauchen in Foren, die versuchen, „schlechte Bots“ zu identifizieren und zu blockieren, immer weitere Bots auf, und es nimmt kein Ende
Unter uns sind zwar viele kluge Leute, aber wir neigen auch dazu, uns übermäßig auf technische Probleme zu fixieren. Wenn man gar nichts tut, nagt es ständig an einem, und wenn man wenigstens blockiert, ist es etwas weniger frustrierend
Es überrascht mich immer wieder, wie viele Leute auf Hacker News
robots.txternst nehmen. Es ist wirklich beeindruckend, wie viele Menschen gute Absichten haben. Aberrobots.txtist keine praktische Lösung. Die Leute müssen erst wissen, dass esrobots.txtüberhaupt gibt, und dann auch noch Code zur Prüfung in ihre Crawler einbauen, was zusätzliche Komplexität schafft. Ich frage mich, ob es andere praktikable Lösungen gibt. Dinge wie „Micropayments“ oder „große Merkle-Trees zur Klarnamensverifikation“ werden seit Jahren diskutiert, sind aber nie wirklich umgesetzt wordenIch glaube kaum, dass es Bot-Entwickler gibt, die
robots.txtnicht kennen. Eher halten sich manche Leute für einen Sonderfall und glauben, ihr Projekt dürfe die Regeln ignorieren, die für alle anderen geltenrobots.txtist rechtlich nicht bindendIn unseren Logs sehen wir ähnliche Bot-Muster. Es ist ziemlich lästig, aber immerhin geben sie sich als Bots zu erkennen und verursachen nicht viel echten Traffic. Der Großteil des Traffics kommt von Bots, die sich als echte Browser ausgeben oder über verschiedene IPs aus Brasilien und Asien hereinkommen. Ich habe in der letzten Woche allerlei Versuche zur Bot-Abwehr unternommen und teile hier ein paar Erfahrungen, die vielleicht helfen.
Von Hunderten IPs kommen nur ein paar Requests pro Tag, aber alle tarnen sich mit echten UAs
Sie senden fast nie eine Referrer-URL, aber der Huawei-Cloud-Bot sendet manchmal eine Referrer-Angabe mit, dafür ist sein Traffic gering
Mein Hauptversuch war, URLs mit
id=in der Bandbreite auf 1 Kb/s zu begrenzen, in der Hoffnung, dass die Bots bei Verlangsamung aufgeben würden, aber es hat sie überhaupt nicht interessiert und sie haben einfach weiter angefragtSie haben sich sogar an Keep-Alive-Verbindungen angepasst, deshalb habe ich Keep-Alive unter
/cgit/komplett deaktiviert, aber auch dann belegen sie weiter alle VerbindungenMeine aktuelle Methode ist, URLs mit
id=nur dann zuzulassen, wenn einnotbot-Query-String vorhanden ist; fehlt ein Referrer, zeige ich eine 403-Meldung mit dem Hinweis, dass legitime Nutzer den Parameternotbothinzufügen sollen. Damit konnte ich die Last senken und die Verbindungen legitimer Nutzer verbessern, aber die Bots fragen trotzdem weiter an und kassieren einfach nur 403Im Ergebnis scheint es nur zwei Wege zu geben: sitespezifische ad-hoc-Methoden oder die Auslagerung an jemanden wie Cloudflare, der genug Ressourcen hat. Standardisierte Bot-Abwehr stößt an Grenzen, weil ressourcenstarke Akteure sie entweder problemlos umgehen oder die Kosten tragen können
Eine weitere Methode ist, seltene UA-Substrings wie
MSIE 3.0oderHP-UXvorab mit 403 zu blockieren. Danach sammelt man die 403-Logs und sperrt problematische ASNs separat, also wieder klassisches Whac-A-MoleIch verwende Software aus der Bernstein-
publicfile-Familie von djbwares. Zusätzlich habe ich statische GEMINI-UCSPI-SSL-Tools eingebaut und eine Idee aus der GEMINI-Spezifikation übernommen, nämlich Fragmente und Query-Parameter in Request-URLs komplett zu verbieten. Der Grund ist derselbe wie in GEMINI, lässt sich aber auch auf statische HTTP-Dienste anwenden. Um Query-Parameter serverseitig korrekt zu behandeln, müsste man in der Konfiguration mehrere sonderbare Dateinamen separat erzeugen, was praktisch kaum machbar ist. Dank dieser Idee erreichen Angriffsversuche auf CGI- oder PHP-Schwachstellen gar nicht erst das Dateisystem, sondern werden schon beim Zerlegen der Requests abgefangen. Betreibern statischer Sites würde ich empfehlen, wie bei GEMINI auch Query-Parameter vollständig zu blockieren. Natürlich nur dann nicht, wenn man in der Kategorie statischer Sites Query-Parameter tatsächlich sinnvoll nutzen willIrgendwann habe ich mich gefragt, ob ein Whitelisting von IP-Bereichen praktisch überhaupt machbar wäre. Ich stelle mir auch einen Community-Ansatz vor, ähnlich wie bei Adblock-Listen, die gemeinsam gepflegt werden
Leider nutzen gerade gut erzogene Bots eher stabile IPs, während böswillige Akteure jederzeit Residential Proxies einsetzen. Sperrt man Residential-Proxy-IP-Adressen, schadet das echten Nutzern, und böswillige Akteure wechseln einfach sofort woanders hin. Nach meiner Erfahrung mit tatsächlich Tausenden IPs reicht IP-basierte Information allein nicht aus; man braucht zusätzliche Signale
Die Firma hinter Pokémon Go hat das kurz nach dem Start ebenfalls versucht, um Scraping zu stoppen. Sie teilte IPs in drei Kategorien ein: Blacklist (
Google Cloud, AWS usw.), nicht vertrauenswürdige IPs (Residential) und Whitelist (normale IPv4 usw.). Anfangs fing das die wichtigsten Scraper ab, aber der größte Scraper umging das, indem er eine Farm aus Modem-Endgeräten betrieb. Das Ergebnis war, dass normale Nutzer ohne Karte das Spiel aufgaben, während Hardcore-Spieler ihre Scraper-Nutzung sogar kostenpflichtig ausweiteten. Am Ende stieg die Serverlast noch weiter. Ich halte das für eine von mehreren Fehlentscheidungen, die Pokémon Go getroffen hatViele US-Unternehmen setzen das bereits um. Wenn sie einem aber im Ausland nicht einmal die Möglichkeit geben, den Dienst zu kündigen, während sie weiter Geld abbuchen, ist das ziemlich fragwürdig
Whitelists und Blacklists müssen nicht strikt binär gewählt werden. Der meiste Traffic liegt in einer Grauzone. Wenn eine bestimmte IP auf einer Whitelist steht und dann Auffälligkeiten zeigt, muss man sie wieder entfernen, ankündigen, Benachrichtigungen versenden und die Behebung gegenseitig abstimmen — das ist in der Praxis extrem komplex. Effektiv funktionieren Whitelists nur zwischen Partnern mit Vertrauensverhältnis. Blacklists sind nützlich für problematische Adressen oder auch, um CIA, Russland, China oder Cloud-Anbieter zu sperren. Ein realistischer Ansatz ist, nur Hosts mit robuster Abuse-Abwehr — etwa interne Unternehmenssysteme — auf eine Whitelist zu setzen
Ich arbeite mit dem Open-Source-Projekt GoodBots an einer positiven Bot-Whitelist. PRs sind sehr willkommen
Ich verwende die Methode, bei allen Requests einen benutzerdefinierten Header zu verlangen und alles andere zu blockieren
Nach außen nutze ich einen Cloudflare-Proxy, intern setze ich Crowdsec und Modsecurity CRS vor Traefik ein. Nach etwas Feintuning zur Reduzierung von False Positives läuft das sehr stabil. Vorübergehend gesperrte und gemeldete IPs leite ich an Crowdsec weiter und poste die Logs in einen Discord-Kanal. Im Schnitt blockiere ich täglich einige Dutzend unterschiedliche IPs. Meinem Eindruck nach kommen Zugriffsversuche auf nicht öffentliche Ressourcen oder CVE-bezogene Angriffe deutlich häufiger von US-IP-Adressen als von chinesischen. Um das Crawlen öffentlicher Inhalte kümmere ich mich nicht, alles andere ist ohnehin nur über SSO oder im Intranet erreichbar. Effektiver als Ländersperren ist es, konkrete Exploit- oder Flooding-Versuche direkt zu blockieren
Ein Ansatz wie Crowdsec ist zwar attraktiv, aber den gesamten Traffic des Servers an ein profitorientiertes Unternehmen weiterzureichen, halte ich für ein großes Risiko
Wirklich ernsthafte Angriffsversuche werden letztlich wohl ohnehin schon an einer Stelle wie der Cloudflare WAF abgefangen
Viele Mehrfamilienhäuser können nur über einige wenige IP-Adressen nach außen gehen (siehe Carrier-grade NAT)
Mehr als die Hälfte meines Traffics stammt von Bing-, Claude- und Facebook-Bots. Sie tragen zwar nicht wesentlich zum eigentlichen Traffic bei, fressen aber Serverressourcen und sind ein Hauptgrund dafür, dass die Site langsamer wird, wenn AI, Microsoft und Facebook den gesunden Menschenverstand ignorieren. China und Ähnliches machen nur einen Teil des bösartigen Traffics aus; das eigentliche Problem sind US-Unternehmen, die
robots.txtoder DNS-Rate-Limits ignorieren