![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2026\/08\/trafficwelle1.avif\")
<\/a><\/figure>\n<\/div>\nCrawler sind nicht neu. Google und weitere Suchmaschinen rufen seit Jahrzehnten regelm\u00e4\u00dfig Webseiten auf, um dortigen Links zu folgen. Hinzu kommen diverse Bots f\u00fcr andere Zwecke. Neu war: Sie schienen in gro\u00dfem Stil echte Webbrowser fern zu steuern. Das l\u00e4dt automatisch zahlreiche Abh\u00e4ngigkeiten wie CSS, JavaScript, Bilder & Co, wodurch sich Anfragen und Datenverkehr erh\u00f6hen. Obwohl vieles davon f\u00fcr Bots uninteressant ist. Schlie\u00dflich werten sie prim\u00e4r den Inhalt aus, statt etwa dem per CSS festgelegten Aussehen der Seite.<\/p>\n
Vorerst entschied ich, das Ganze weiter zu beobachten – ohne aktives Blockieren oder andere Eingriffe. U-Labs liegt auf einem physischen Server, der f\u00fcr die \u00fcbliche Last erheblich \u00fcberdimensioniert ist. Negative Auswirkungen auf die dort betriebenen Projekte gab es zu diesem Zeitpunkt daher trotz der sp\u00fcrbar erh\u00f6hten Last keine. Ich machte mir Gedanken, wie zuk\u00fcnftig am sinnvollsten damit umgegangen werden sollte – und wie sich dies auf andere Seiten negativ auswirkt, die lediglich einen Webspace oder kleinen virtuellen Server zur Verf\u00fcgung haben.<\/p>\n
Pl\u00f6tzlich sind wir langsam & dann zeitweise offline<\/h2>\n
Doch nach kurzer Zeit wurden die Bots deutlich aggressiver: Statt 5-10x mehr Aufrufe registrierte ich pl\u00f6tzlich bis zu 198x mehr. Und das nicht etwa gleichm\u00e4\u00dfig \u00fcber den Tag verteilt – sondern mit starker Konzentration am Nachmittag sowie in den Abendstunden. Als akute Ma\u00dfnahme erh\u00f6hte ich die Zahl der PHP-Prozesse im Forum. Das verbesserte die l\u00e4ngeren Ladezeiten sowie vermied kurzzeitigen Timeouts. Es dauerte jedoch erneut nicht lange, bis die Anzahl der Anfragen 398x so hoch war, wie \u00fcblich – ein neuer Rekord, der den Prozessor auf 8 Kernen zu 100% auslastete. Das Forum wurde unbenutzbar.<\/p>\n
<\/a><\/figure>\n<\/div>\nDaher folgten striktere Limits pro IP. Damit war die Community zwar wieder nutzbar und die Auslastung sank erheblich. Dennoch war offensichtlich: Der Server bediente weitaus mehr automatisierter Bot-Anfragen, als echter Menschen. Alleine PHP bediente bis zu 16 Anfragen pro Sekunde – trotz Limits, die immer wieder von verschiedenen IPs \u00fcberschritten wurden.<\/p>\n
Die Bots werden immer mehr & aggressiver<\/h2>\n
Anfangs stammten die vielen Anfragen von einer noch relativ \u00fcberschaubaren Menge an IP-Adressen. Immer wieder kamen zwar neue hinzu, doch das Ganze war beherrschbar. Bis es einige Zeit sp\u00e4ter auf eine ganz neue Stufe eskalierte: Eine gro\u00dfe Welle von verschiedenen IP-Adressen rief zeitgleich mit wenig bis \u00fcberhaupt keiner Pause st\u00e4ndig neue URLs auf. Es waren derart viele, dass viele Anfragen gar nicht bis zum Nginx\/PHP-Container des Forums durchkamen. Stattdessen beanspruchte der Reverse Proxy teilweise die gesamten 8 Kerne (!) f\u00fcr die TLS-Terminierung. Damit war nicht mehr nur das Forum betroffen, sondern s\u00e4mtliche Webseiten auf dem Server.<\/p>\n
Um die Dimensionen zu verdeutlichen: Bei der k\u00fcrzlichen Spitze im August kamen in nur 10 Sekunden HTTPS-Anfragen von rund 11.700 verschiedenen IP-Adressen. Diese \u00f6ffneten zudem teils mehrere Verbindungen gleichzeitig: \u00dcber 22.500 TCP-SYNs auf Port 443. Das entspricht \u00fcber 2.260 Verbindungsversuchen pro Sekunde!<\/strong> Hier stie\u00df schlicht die Hardware an ihre Grenzen. Der Server ist daf\u00fcr \u00fcberhaupt nicht ausgelegt, da die Zahl der gleichzeitigen legitimen Anfragen weit darunter liegt.<\/p>\n Und das sollte noch nicht die Spitze gewesen sein. Sp\u00e4ter eskalierte der Traffic auf rund 41.000 SYNs innerhalb von 10s, somit knapp 4.100 Verbindungsversuche<\/strong> – jede Sekunde.<\/p>\n Bemerkenswert ist, dass dies kein generischer SYN-Flood war, um die Leitungskapazit\u00e4t oder andere begrenzte Ressourcen offensichtlich bewusst zu \u00fcberlasten. Dies kennt man als eine Form von DDoS-Angriffen, bei denen das Ziel alleine darin besteht. Blockierte ich allerdings testweise IPv4-Zugriffe auf Port 80 und 443 (also HTTP und HTTPS) auf Firewall-Ebene vollst\u00e4ndig, brach die Serverlast auf nahezu null ein. Nach dem Aufheben der Blockade war das System sofort wieder stark ausgelastet. IPv6 war dagegen nicht betroffen.<\/p>\n Beim Auswerten der Zugriffsprotokolle fiel zudem auf: Die Zugriffe wirkten alles andere als menschlich. Sie verteilten sich auff\u00e4llig gleichm\u00e4\u00dfig auf verschiedene Foren sowie deren Themen. Es ist \u00e4u\u00dferst unwahrscheinlich, dass echte Menschen das gesamte Forum in diesem Ausma\u00df systematisch „durch klicken“. Insbesondere nachdem nahezu alle IP-Adressen aus dem Ausland stammten, oft von weit entfernten L\u00e4ndern. <\/p>\n Einzelne F\u00e4lle m\u00f6gen hier noch realistisch erscheinen – etwa, weil jemand aus dem deutschsprachigen Raum dort Urlaub macht. Oder im Zweifel auch mal eine Geo-IP Zuordnung falsch ist. Insbesondere in Grenzn\u00e4he durchaus vorstellbar. Doch diese Dimensionen sind ein klarer Indikator f\u00fcr ferngesteuerte Bots, die systematisch Inhalte des Forums indexieren oder anderweitig verarbeiten.<\/p>\n Mit bis zu 380 Mbit\/s ist das Netzwerk zwar deutlich st\u00e4rker ausgelastet gewesen, als \u00fcblich. Doch noch l\u00e4ngst nicht am Limit f\u00fcr eine Gigabit-Verbindung. Der Flaschenhals war hierbei die CPU: Bei der anf\u00e4nglich noch „moderaten“ \u00dcberlastung von Rund 2.300 Verbindungen pro Sekunde belegte PHP mit ca 400% CPU-Last bereits die H\u00e4lfte der Kerne. Traefik kam direkt danach mit etwa 249%. Die konkrete Auslastung variierte mit der Zeit. Das Ergebnis blieb gleich: Der Prozessor ist mit 90-100% am Anschlag.<\/p>\n Als sich die Verbindungsversuche fast verdoppelten, \u00e4nderte sich die Verteilung. Nun lastete Traefik nahezu die gesamte CPU aus. Viele Anfragen kamen gar nicht mehr bis zum PHP-Backend, weil Traefik die TLS-Terminierung f\u00fcr mehrere tausend Verbindungen pro Sekunde durchf\u00fchren musste. Hier hat sich die Load auf bis zu 88 erh\u00f6ht.<\/p>\n Ich wollte m\u00f6glichst wenige echte Besucher f\u00e4lschlicherweise aussperren. Daher war mein erster Ansatz ein Skript, welches das Zugriffsprotokoll nach IPs mit auff\u00e4llig vielen Anfragen in kurzer Zeit durchsucht. Um diese von Leuten abzugrenzen, die sich schneller durch die Foren klicken, erfolgt zus\u00e4tzlich eine L\u00e4nderzuordnung per lokaler Geo-IP Datenbank. Darin ist Deutschland zusammen mit den umliegenden EU-L\u00e4ndern sowie den USA (wegen Google, OpenAI & Co.) ausgeschlossen.<\/p>\n Als anfangs nur wenige IPs den Server mit Anfragen fluteten, war das eine brauchbare \u00dcbergangsl\u00f6sung. Doch bei tausenden IPs hatte es keine Chance mehr: Viele IPs landeten aufgrund der \u00dcberlastung des Reverse Proxy erst verz\u00f6gert oder teils gar nicht mehr im Access-Log. Es muss ber\u00fccksichtigt werden, dass eine eingehende HTTPS-Verbindung neben der TLS-Terminierung eine weitere im Backend ausl\u00f6st.<\/p>\n Um dies greifbarer zu machen: Bei der Analyse eines Access-Logs stammten mehr als 168.700 Anfragen von rund 87.700 IP-Adressen. Im Schnitt f\u00fchrte jede IP gerade einmal 1,9 Anfragen durch. Auch Stichproben der tausenden SYNs zeigten: Selbst die h\u00e4ufigste IP hatte lediglich vier Treffer. Es handelt sich also um einen sehr verteilten Angriff, bei dem IP-Limits kaum etwas bewirken.<\/p>\n Besonders auff\u00e4llig ist die Analyse der Herkunft. Ich habe Geo-IP Abfragen auf Ausz\u00fcge der Access-Logs mit mehreren tausend Zeilen durchgef\u00fchrt: Zuvor kam die klare Mehrheit aus den USA – u.a. etwa von Servern, die Microsoft Azure geh\u00f6ren. Diese Konzentration ist verschwunden. Stattdessen verteilen sie sich quer \u00fcber den Globus: Indien, Vietnam, Kenia, Argentinien, Chile, Brasilien, Kolumbien, Irak und viele weitere.<\/p>\n Au\u00dferdem ist auff\u00e4llig, dass ein gro\u00dfer Teil davon mit hoher Wahrscheinlichkeit zu Internetanbietern f\u00fcr Privatkunden geh\u00f6rt. Aus einer Stichprobe von 25 IPs sind 19 wohl von privaten Endkunden. 5 geh\u00f6ren zu ISPs, bei denen die Nutzung unklar ist. Nur einer l\u00e4sst sich zweifelsfrei einem kommerziellen Hosting-Anbieter zuordnen. Derart viele private IPs aus L\u00e4ndern, die gar nicht zur Zielgruppe von U-Labs geh\u00f6ren, sind starke Indikatoren f\u00fcr eine Art von Residential-Proxies.<\/p>\n Zur\u00fcck zu meinem Problem, welches durch diese mutma\u00dflichen Proxies entstanden ist. Bei derartiger Masse konnte nur der umgekehrte Ansatz helfen – und zwar auf Firewall-Ebene: \u00dcber eine lokale Geo-IP Datenbank habe ich die Netze in der EU ermitteln k\u00f6nnen, um damit ein IP set zu bef\u00fcllen. Das ist eine Datenstruktur in Linux, die wahlweise das effiziente Speichern gr\u00f6\u00dferer Mengen von IP-Adressen, Subnetzen, Ports oder MAC-Adressen erm\u00f6glicht. Sie lassen sich mit iptables-Regeln verkn\u00fcpfen: Beispielsweise allen IPs im Set X den Zugriff auf Port 80\/443 erlauben oder verweigern.<\/p>\n Das ist wesentlich performanter, als unz\u00e4hlige einzelne Firewall-Regeln anzulegen. Dort m\u00fcsste jedes Datenpaket auf alle Regeln hin gepr\u00fcft werden – eine schlechte Idee. In meinen Tests haben selbst IP sets mit hunderttausenden IP-Adressen (beim anf\u00e4nglichen Sperren) die Leistung nicht sp\u00fcrbar beeintr\u00e4chtigt.<\/p>\n Der aktuelle Ansatz ist wesentlich einfacher und verzichtet auf Analysen der Zugriffsprotokolle. Allerdings hat er auch einen Nachteil: IPs mit falscher Zuordnung in der Geo-IP Datenbank werden abgewiesen. Das ist insbesondere mit \u00e4lteren LTS-Betriebssystemen ein Problem. Ubuntu 22.04 LTS von 2023 enth\u00e4lt das Das Problem l\u00e4sst sich deutlich reduzieren, in dem man die Datenbank aus dem Deb-Paket von Ubuntu 26.10 extrahiert und \u00fcber den Parameter -f \u00fcbergibt. Sie ist von Anfang August und damit derzeit erst gut zwei Wochen alt. Dennoch sind solche Zuordnungen nie 100% akkurat. Au\u00dferdem m\u00fcssen diese hinsichtlich \u00c4nderungen in der Zukunft aktuell gehalten werden.<\/p>\n Scraping<\/strong> bezeichnet das automatisierte Sammeln von Daten aus fremden Internetseiten: Eine Software besucht<\/em> daf\u00fcr Webseiten, oft massenhaft und speichert die gew\u00fcnschten Informationen in einer Datenbank. So funktionieren beispielsweise Preisvergleichsportale. Sie rufen die Produktseiten aller bekannten Shops auf, um den Preis sowie weitere Informationen (Versandkosten, Lagerstatus etc) zu ermitteln. Aus den gesammelten Daten entsteht das Ranking der g\u00fcnstigsten Anbieter.<\/p>\n Nicht immer werden Nutzer vorher gefragt, bevor andere ihren Internetanschluss als Residential-Proxy verwenden. Kriminelle nutzen Sicherheitsm\u00e4ngel, um alle m\u00f6glichen Ger\u00e4te als Proxy zu missbrauchen. Und das im gro\u00dfen Stil – man spricht von einem Botnetz. Solche gekaperten Systeme wurden fr\u00fcher haupts\u00e4chlich f\u00fcr DDoS-Angriffe missbraucht, um Webseiten lahm zu legen. Mittlerweile kommen sie zunehmend zur Umgehung von Scraping-Limits zum Einsatz.<\/p>\n Erst im Juni 2026 entdeckten Sicherheitsforscher ein solches Botnetz aus Millionen Smarten TVs. Etwa 1,35 Millionen IP-Adressen aus 223 L\u00e4ndercodes sammelten Daten von der Plattform „Arab Reporters for Investigative Journalism“. Auch im deutschsprachigen Raum ist das Problem l\u00e4ngst real – bei abuse.ch waren es 135.000 einzigartige IPs, die etwa 1.500 Anfragen pro Sekunde sendeten.1<\/a><\/sup><\/p>\n \u00dcblicherweise sind Sicherheitsm\u00e4ngel die Grundlage: Dadurch installieren Kriminelle unbemerkt die Software f\u00fcr einen Residential-Proxy (oder andere Schadsoftware). Ab diesem Zeitpunkt haben sie die Kontrolle \u00fcber ihr Ger\u00e4t endg\u00fcltig verloren. Doch mit LG & Samsung ergriffen zwei gro\u00dfe Hersteller lange keine Ma\u00dfnahmen zum Schutz ihrer Kunden.<\/p>\n Eine Analyse zeigte, wie gro\u00df das Problem ist: \u00dcber 42% der Erweiterungen in LGs webOS Store enthalten eine Bibliothek, wodurch die TVs zu Proxys werden. Bei Samsung (Tizen) sind es immerhin 26,5%.2<\/a><\/sup> Erst als diese Ergebnisse sich durch die Medien verbreiteten, k\u00fcndigte LG Gegenma\u00dfnahmen an.<\/p>\n Bei der L\u00f6sungsfindung hatte ich dar\u00fcber nachgedacht, „KI“-Crawler auf allen erdenklichen Wegen zu blockieren. Das klingt nach einer einfachen L\u00f6sung, ist jedoch deutlich schwieriger. \u00c4hnlich wie Suchmaschinen die robots.txt ber\u00fccksichtigen oder eben ignorieren k\u00f6nnen, gibt es keinen garantierten Ausschluss. Insbesondere bei bereits aggressiv auftretenden Crawlern ist wenig Kooperation zu erwarten. Sicherlich lie\u00dfe sich das entsch\u00e4rfen, indem bekannte IPs in der Firewall blockiert werden. Ebenso auff\u00e4llige mit vielen Anfragen in k\u00fcrzerer Zeit.<\/p>\n Doch das grundlegende Problem beginnt bereits ganz woanders: LLMs, allen voran ChatGPT, sind bereits die bislang am schnellsten wachsende Technologie der Geschichte. Trotz fehlendem Verst\u00e4ndnis und sehr hohen Fehlerquoten l\u00f6sen Chatbots die klassische Websuche zunehmend ab. F\u00fcr Seitenbetreiber ein gro\u00dfes Problem: Die Sprachmodelle bedienen sich fremder Inhalte, w\u00e4hrend die Klickraten dort bereits erheblich einbrechen. Damit versch\u00e4rft sich das Einnahmenproblem des \u00fcberwiegend von Werbung finanzierten Internets weiter, bislang ohne wirkliche L\u00f6sung.<\/p>\n Kleinere und mittlere Seitenbetreiber stehen damit de facto vor der Wahl: Entweder \u00fcberlassen sie „KI“-Modellen ihre Inhalte kostenfrei – daf\u00fcr bekommen sie noch weniger Aufrufe, als vorher. Tendenz sinkend. Oder man versucht, „KI“ auszuschlie\u00dfen. Noch schwieriger wird es, wenn selbst das Tolerieren solcher Bots auf erheblich \u00fcberdimensionierten Servern zum Ausfall f\u00fchrt.<\/p>\n Meine „Besucherzahlen“ sind um 3.058% gegen\u00fcber dem Vorjahr gestiegen – und das im August. Zeitgleich sind \u00fcber 15.000 Verbindungen parallel ge\u00f6ffnet. Doch das liegt nicht an pl\u00f6tzlich viral gegangenen Inhalten – sondern Bots, die massenhaft Besuche erzeugen. Das ist nicht grunds\u00e4tzlich neu. Doch verschiedene Faktoren haben die Lage 2026 derart eskalieren lassen, dass ein stark …<\/p>\n","protected":false},"author":5,"featured_media":17896,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"https:\/\/borncity.com\/blog\/2026\/06\/22\/popa-botnetz-kapert-smart-tvs-fuer-web-scraping\/<\/a>\",\"id\":\"14a5ebfd-09d3-4aea-9153-fbd0992ca95e\"},{\"content\":\"https:\/\/borncity.com\/blog\/2026\/08\/02\/lg-erlaubt-ads-auf-smart-tvs-zu-deaktivieren-teil-2\/<\/a>\",\"id\":\"5d44912d-d284-4395-ac95-e2a4a8741edf\"}]"},"categories":[1],"tags":[910],"class_list":["post-17824","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technik-news","tag-ki"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/17824","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=17824"}],"version-history":[{"count":32,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/17824\/revisions"}],"predecessor-version":[{"id":17895,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/17824\/revisions\/17895"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/17896"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=17824"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=17824"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=17824"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Verd\u00e4chtig: Nur HTTPS-Datenverkehr betroffen<\/h2>\n
Der Flaschenhals<\/h2>\n
Was nicht mehr half<\/h2>\n
<\/a>Nun greifen Residential-Proxies an?<\/h2>\n
Die neue Strategie<\/h2>\n
Doch es gibt Herausforderungen<\/h2>\n
geoip-database<\/code> Paket von Dezember 2019. In knapp 6 Jahren kann sich einiges \u00e4ndern. Beispielsweise die mobile IP meines Smartphones, welche dort im EU-Ausland zugewiesen war.<\/p>\nResidential-Proxies: Gezielter Missbrauch f\u00fcr („KI“-)Scraping<\/h2>\n
Wenn LG & Samsung ihre Kunden ans Messer liefern<\/h2>\n
In der Falle: Was kann getan werden?<\/h2>\n
Quellen<\/h2>\n
\n