Bad Bots blocken oder nicht?

[Mirlo]

Wie hast du deinen Botschutz konzipiert?

Kurz gesagt: individuell. Ich habe die Requests getrackt und in den Daten nach Mustern gesucht. Anfangs alle Daten von getallheaders() und Daten von $_SERVER sowie Date/Time, später dann nur noch ausgewählte Daten. Mit den Mustern habe ich dann Filter programmiert. Die bei mir bereits vorhandenen Filter fürs Tracking habe ich auf die Requests angewandt. Dazu gehören die IP-Listen der Big 5 Cloud-Anbieter, die diese selbst anbieten und die ich zu MMDB Files konvertiert habe, sowie ASN MMDB Files.

Zuletzt (bis Vorgestern) konnten somit viele Bad Bots vorm Crawlen/Scrapen gehindert werden, aber bei den schlimmeren der erste Request nicht, sondern nur die darauf folgenden, und das bisher ohne Verwendung einer Tracking-Database, mittels der Muster bei wiederkehrenden Requests erkannt werden können. Ein effektiver Erfolg ist also auch mit einfachen Mitteln, ohne Captcha und ohne POW und ohne Cookies möglich.

Mein Bad Bot Blocker basiert auf PHP. Die Requests bereits am Server-Eingang blocken ist bei Webhost nicht drin. Mittels .htaccess wäre ein Blocken auch möglich, aber ist zu umständlich. PHP taugt ganz gut dafür. Die Request an sich können so zwar nicht geblockt werden, aber der Zugriff auf den Content.

Hatten wir schon über Cloudflare und so Zeug gesprochen?

Ja. Es gibt wohl derzeit zwei Anbieter: Cloudflare (Pay) und Anubis (Free). Meine Ansage zu Anubis ist in #58 verlinkt.

Mit Formulardaten ... Das betrifft welches Angriffsszenario genau? Die Requests kommen auch mit Blocken per PHP am Server an und sind im HTTP Log und Access Log gespeichert. Wenn du wie bei mir den Content blockst, kommen sie an das Formular nicht ran.

Vorhersagen für die Zukunft, oder ein Bad Bot Blocker für alle Zeiten gibt es nicht. Siehe den ChangeLog bei Anubis. Da wurde der Core schon mehrmals angepasst. Also Bad Bot Blocker programmieren und Füße hoch ist nicht drin. Man muss stetig die Requests checken und nachbessern.

Zuviel an Details meines Bad Bot Blockers will ich nicht verraten, was aber auch den Umstand betrifft, dass er sehr individuell ist und exakt auf meine Websites angepasst wurde. Das kann nicht 1:1 auf alle Websites angewandt werden.

Wie schon gesagt: Tracke die Requests. Suche darin nach Mustern. Blocke per Muster.

Aber ... habe aktuell mit starkem Besucherrückgang zu tun und weiß noch nicht woran das liegt. Es könnte eventuell daran liegen - was nicht unwahrscheinlich ist - dass die Bad Bots komplett abgesprungen sind, weil sie in den letzten Tagen weiterhin massiv aktiv waren, aber 0 kb Content gesrapt haben. Es könnte sein, dass die verbliebene Besucherzahl alles Humans sind. Bei Experimenten vor über einem Jahr beim Thema "Tracking filtern" war die Besucherzahl auch massiv gesunken, aber diese waren zu fast 100 % alles Humans.

Das würde eventuell auch eine Vermutung matchen, die wiederum auch die Formular-Angriffe betreffen. Es gab die Vermutung, dass die Bad Bots das Matomo-Tracking bedienen, indem diese die fetch() Requests an Matomo senden. Ob das direkt oder über die Webpages gemacht wird, war nicht herauszufinden. Aber im Matomo Tracking gabs Visits, die nur aus einem getrackten Event bestanden, ohne das der Pageview getrackt wurde. Bei dir könnte es also sein, dass die Webpages mit den Formularen gar nicht aufgerufen werden, sondern die GET/POST direkt gesendet werden. Wie das zu vermeiden wäre weiß ich auch nicht. Eventuell alles auf JS DOM umprogrammieren, dass die Formulare nicht hardcoded, sondern mit JS generiert werden.

Ergänzung (29. August 2026)

Ein guter Einstieg ist, die Block-Regeln vom Matomo Plugin TrackingSpamPrevention im eigenen Blocking zu verwenden. Das verwendet auch die Cloud-IP Listen der Big 5 Clouds. Zudem verwendet es die ASN MMDB und blockt per ASN Organisation Name.
https://github.com/matomo-org/plugin-TrackingSpamPrevention/
→ Configuration.php (Liste der Namen).
Die wird stetig up to date gehalten.

 

[Janush]

Wie gesagt, mein Ziel ist ein anderes und lässt sich leichter erreichen als dein Ziel. Mein Content hängt hinter einer PayWall und die gilt es abzusichern.

Die Formulare werden natürlich mit Post-Requests direkt zugespammt. Aber die kommen nicht durch ... das sind die leichtesten Angriffe, die man abwehren kann. Captcha nicht geladen? Post Request abgelehnt. Und wenn sie sich am Captcha versuchen, steigt der Aufwand mit jedem mal an. Für echte Besucher ist das nicht spürbar.

Was mit noch nicht ganz klar ist, ist warum Spammer Newsletter Signups ins Visier nehmen. Da kann man keine Daten mitschicken ... nur sinlose E-Mail-Adressen reinballern.

Ich habe deinen Text mal von ner KI analysieren lassen, einfach weil ich nicht bei allen Punkten in der Materie stecke. Die hat deinen Ansatz gelobt, aber den offensichtlichsten Punkt nochmal genannt.

###
„Effektiver Erfolg auch mit einfachen Mitteln" stimmt für die heutige Bot-Population, nicht als Prinzip. Gegen Residential-Proxy-Netze mit headless Chrome hat der Ansatz keine Antwort: richtige ASNs, richtige Header-Reihenfolge, richtige TLS-Signatur. Das ist inzwischen billig zu mieten. Das Verfahren erkennt die faulen Scraper zuverlässig — und genau die richten den geringsten Schaden an.
###

Ich denke gegen sowas kommt man nicht an. Da bleibt dann nur noch ne PayWall.

Was Cloudflare angeht, kannst du es auch kostenlos nutzen. Zwar mit Einschränkungen, aber den KI Botschutz gibt es trotzdem schon in der kostenlosen Variante.

 

[Mirlo]

... am besten:

• programmieren eines eigenen PHP Trackings.
• die Tracking-Daten in einer sortierbaren Table visualisieren.
• manuelle Mustererkennung.
• programmieren einer eigenen Firewall mit Verwendung der Muster.
• stetiges prüfen des Trackings nach Mustern → Muster zur Firewall hinzufügen.

Das Tracking kann um ein JavaScript Event Tracking (API) erweitert werden.
Das Visualisieren der Tracking-Daten kann nach Belieben erweitert werden.

Von Cloudflare kommen tatsächlich Humans.

Ich muss mich derweil erst einmal daran gewöhnen, dass bei meinen Websites nur circa 50 % der Websitesbesucher tatsächlich Humans waren und nun sind. Also es waren wohl 50 % Bad Bots, die nun seit 2 Tagen weggefallen sind (... und der Traffic sinkt auch, nachdem er bereits um 80 % gesunken war). Wenn es die Möglichkeit gibt, dass die Bad Bots meine Websites in eine Blacklist aufgenommen haben, dann scheint dem so. Scheinbar, wie bei Anubis zu lesen ist, haben die Bad Bots Ressourcen-Probleme und müssen effizient sein. Sinnloses Crawlen und Scrapen können sie sich nicht leisten. Kostet scheinbar alles Geld.

Die 50 % weniger Websitesbesucher können 2 Ursachen haben, was die Sache uneindeutig macht.
1.) ein (neuer) Filter in der/meiner Firewall.
2.) Google Core Update.

1. trifft zu, da die Anzahl der Besucher der Anzahl entspricht, die es bei meinen Experimenten im Tracking filtern gab. Das war ähnlich aufgebaut, betraf aber nur das Tracking.

zu 2. hier: Google Core Update

 

[Mirlo]

Das Forum hier hat ein technisches Problem: Siehe Timestamp deines und meines letzten Beitrags (gleich). Ich habe ihn erst jetzt durch Zufall gesehen.

Ich habe deinen Text mal von ner KI analysieren lassen

"und genau die richten den geringsten Schaden an". Die Beobachtungen sagen etwas anderes dazu aus. Mit den einfachen Mitteln, mit denen ich begonnen habe, konnte der Traffic um 80 % reduziert werden. Zudem konnten Bad Bot Angriffe mittels Mustererkennung abgewehrt werden.

Ansonsten stimmt die Aussage: "Das ist inzwischen billig zu mieten. Das Verfahren erkennt die faulen Scraper zuverlässig". Die billigen Bad Bots sind einfach zu blocken. Die teuren weniger bis gar nicht. Aber die billigen sind die in der Überzahl. Die teuren sind nur wenige. Da sowieso nie alle Bad Bots geblockt werden können, kommt es drauf an, ob es einem genügt diese "manuell" im Tracking zu erkennen und mittels Kopfrechnen auszuschließen. Ein 100 % sauberes Tracking und Traffic ist verschwendete Zeit. Paretoprinzip.

Wenn du den Traffic bei dir trackst, wirst du beim Analysieren so einiges seltsames entdecken.

Cloudflare oder Anubis will ich vermeiden, weil es externer Kram ist. Solange ich die Sache auch mit eigener Firewall lösen kann, zumal bei sowas sowieso individuelle Lösungen effektiver sein sollen.

Im Bad Bot War hats mich nun selbst erwischt: Schreibfehler im Code bei einem der Filter. Daher 50 % weniger Besucher. Also Entwarnung diesbezüglich.

Im nächsten Schritt will ich einiges ausprobieren, experimentieren.

Wie schon im Thema zu Anubis erwähnt, bei dem es darum geht die Kosten der Bad Bots zu erhöhen, habe ich versucht mittels KI einen POW zu erstellen, der CPU und RAM Last erzeugt. Aber das ist gar nicht so einfach. Bisher habe ich noch kein funktionierendes Skript. Der Ansatz von Anubis ist, die Bad Bots zu verlangsamen, wodurch sie weniger scrappen, aber teurer in der Unterhaltung werden.

 

[Mirlo]

Rate Limiting für alle

rate-limiten

Rate Limiter schön und gut ... Ich habe mir jetzt auch einen programmiert, aber ... Rate Limiter machen nur Sinn, wenn die Besucher identifizierbar sind, zB über LogIn-Daten, oder wenn sie über einen längeren Zeitraum die selbe IP und UA benutzen. Abhilfe gegen die Bad Bots, die über Proxys auf IOT-Devices requesten und bei jedem Request eine andere IP und UA haben, bringt das nicht, außer ... wieder die grobe Methode.

Ich habe mir jetzt einen Rate Limiter programmiert, der pro Website (Domain) die Request Time logt sowie zugleich diese Logtime abfragt und mit der current Requesttime vergleicht. Dabei kann ein "Limit" eingestellt werden. 1 Sekunde bei Verwendung von PHP time(), oder bei Verwendung von PHP microtime() in Millisekunden sowie PHP hrtime() auch in Nanosekunden. Aber, das betrifft ALLE Requests gleichermaßen. Es wird also nur alle x Nano/Micro/Sekunden der Content ausgeliefert, ansonsten nicht. Dabei gibt es zudem einiges zu beachten. An dem Punkt ist eine Proof Of Work Challenge-Page sinnvoll, nein sogar erforderlich, die zwischengeschalten wird, aber ... aufwendig, sehr aufwendig, Anubis ... weil ansonsten per Angriff die Website per Rate Limiter lahm gelegt werden könnte.

 

[GrumpyCat]

@Mirlo Das ist so nginx rate limiting in schlecht? Nanosekunden im schnarchlangsamen PHP anzuschauen macht auch nicht gar so viel Sinn...?

 

[Mirlo]

Das ist so nginx rate limiting in schlecht?

In schlecht in was? Es soll also ein gutes geben, dass nicht erkennbare Bad Bots erkennt? Darauf hat die Welt gewartet! Aber behalts lieber für dich.

Nicht erkennbare Bad Bots sind nicht erkennbar. Da kannste dran herumfusseln wie du willst, sie bleiben nicht erkennbar. Sie sind wie Humans, die eventuell rein durch Zufall auf deine Website klicken und dort keinen weiteren Klick hinterlassen. Sie benutzen IOT-Devices, haben IPs von zivilen Internet-Providern, verwenden neueste Browser mit passenden User Agents. Sie sind wie Humans. Manchmal eben 4 verschiedene Humans in ein und der selben Sekunde (mit Microsekunden Unterschied). Wenn es tatsächlich 4 Humans sind, wie willst du sie erkennen? Sie müssten per Glaskugel-Lesen schon vor ihrem Request erkannt werden. Aber klar, du kennst ein bessers, sowieso, weil alles andere ist schlecht.

Deine Aussage zu Rate Limiting und der Langsamkeit von PHP disqualifiziert. Einfach mal einen Satz hingegrumpt ... schnarchlangweilig. Wie soll PHP Requests im Nanosekunden-Takt verhindern? Oh, darauf hat die Welt auch gewartet - endlich ein Mittel gegen DDOS, das Requests vor den Requests eliminiert. ELIMINIEREN!!! Na dann zeig mal her deine Wunderwaffen. ziemlich grumpy.

 

[Janush]

Da bin ich gerade dabei Fake-Eintragungen über ein Formular zu analysieren und was kommt zufällig dabei heraus ... bei der Analyse mit KI Hilfe ->

---

Noch auffälliger ist der User-Agent:
Mozilla/4.0 (compatible; MSIE 6.0; AOL 8.0;
Windows NT 5.1; .NET CLR 1.1.4322)
Ein echter IE6 auf Windows XP wäre für eine moderne HTTPS-/JavaScript-Seite heute praktisch absurd. Der User-Agent ist daher mit hoher Wahrscheinlichkeit nur vorgetäuscht.

---

Da brat mir doch einer nen Storch ... das habe ich doch irgendwo schonmal gelesen. Warum machen die sowas? Ist das irgendwie eine Art seine eigenen Seiten zu schützen? Eine Art Geheim-Code?

 

[Mirlo]

Ist das irgendwie eine Art seine eigenen Seiten zu schützen?

Wie meinst du das? Welche eigene Seite schützen? Meinst du mit Seite den Client/User oder Website?

So ein UA wie bei dir ist schon sehr selten. Das ist ein Glückstreffer. Da darfst du dich glücklich schätzen. Es könnte durchaus sein, dass es ein ans Internet angeschlossener XP-Rechner ist, der irgendwie am Laufen gehalten wird, aber eben Schwachstellen ohne Ende hat. Die werden wahrscheinlich von Bad Bots ausgenutzt, die über diesen Websites scrappen.

Wenn es ein Bad Bot Browser ist: Im Kapitalismus kannst du alles kaufen und verkaufen, also auch schrottige Bad Bots. Die Bad Bots unterscheiden sich nach ihrem Preis. Gegen die teuren bist du aufgeschmissen. Die billigen sind erkennbar und blockierbar.

Das Problem mit Fake-Formular-Angriffen ... habe die Tage mal kurz drüber nachgedacht, aber mir ist nichts eingefallen, außer wieder Anubis. Die gängigen Tricks mit hidden <input> Field hast du drin? Ansonsten weitere billige Tricks, um zumindest die billigen Bad Bots zu reduzieren. Erstelle mittels ImageMagick eine Grafik mit kleiner mathematischer Aufgabe. Das Ergebnis soll User in ein <input> schreiben. Das checkst du dann auf dem Server gegen. Oder per eigener API (fetch), und erst wenn gelöst, dann das Formular zum Absenden freigeben. Die teuren Bad Bots werden die Mathe-Aufgabe aus der Grafik lesen und lösen, aber die teuren Bad Bots sind wenige, bisher. Machs individuell, zB grobes Schachbrettmuster als Hintergrund, rotate, whatever, canvas?

 

[Janush]

Nee das war nur ein Beispiel ... offensichtlich existieren Listen für Random Fake-Useragents, welche in diversen Foren herumschwirren und in 2011 stehengeblieben sind. Witzigerweise hatten alle 211 Signups von heute einen solchen alten User-Agent. Also nicht genau den, aber genauso alt :-)

Wenn die den Useragent auf etwas modernes abändern, sind die nicht mehr zu erkennen.

Nach dem Singup kommt dann auch nochmal eine Botschutzseite von KlickTipp, welche offensichtlich einfach überwunden werden konnte. Wir bauen da jetzt Turnstile von Cloudflare ein und schauen mal, ob das was bringt.