Bad Bots blocken oder nicht?

[GrumpyCat]

Starr aufgrund von IPs/ASNs oder User Agent blocken ist doch Unsinn. Ersteres sagt nichts aus bzw. blockt auch viele legitime Zugriffe, zweiteres ist so, als würde man alle Einbrecher ins Haus lassen, die auf die Frage "Bist du ein Einbrecher?" mit "Nein" antworten.

Was noch ganz gut geht, IP-Blocking per Honeypot (geht mit fail2ban relativ simpel) oder einfach sonstwie verhaltensbasiert (z.B. bei einem Forum "mehr als 60 unterschiedliche Threads pro Minute abgerufen => IP für 24h blocken"). Aber da sind die Admins erfahrungsgemäß schnell mit den Regeln überfordert...

 

[Mirlo]

Starr aufgrund von IPs/ASNs ... blocken ist doch Unsinn.

Macht Matomo mittlerweile auch: https://github.com/matomo-org/plugin-TrackingSpamPrevention/blob/5.x-dev/Configuration.php

Es ist sehr effektiv. Es gab aber auch schon einen False-positive: https://github.com/matomo-org/plugin-TrackingSpamPrevention/issues/165

Es ist also durchaus sensibel und sollte nicht für jeden Fall genutzt werden, sondern nur wenn eindeutig. Außer man will auch solche Bots blocken. Es ist auf jeden Fall effektiver als über CIDR-Listen zu blocken. Anders gesehen: Wenn die Firmen nicht-erkennbare Bots betreiben oder deren Betreiben zulassen: Pech gehabt - Alle Firmen-IPs verzockt. Wenn es eine Firmenwebsite ist, ist das Risiko einzuschätzen.

Es ist davon auszugehen, dass Anubis und Cloudflare das auch so machen.

Was noch ganz gut geht, IP-Blocking per Honeypot

Das ist auch eine effektive Methode um Bots aufzuspüren. Bei mir sind es unter anderem Domainnamen mit Hyphen, die als nicht-canonical in Verwendung sind. Also canonical sind die Domainnamen ohne Hyphen. Aber auch das ist keine pauschale Lösung. Es muss jedesmal überprüft werden, und wenn ein Bot, dann über Headers Rules, UserAgent Patterns oder ASN Name blocken.

Starr aufgrund von IPs/ASNs oder User Agent blocken ist doch Unsinn.

So gesehen ja, denn es muss jedesmal exakt abgewogen werden, ob über diese Methoden geblockt wird, bzw. werden kann. Das trifft nicht immer zu. Zudem kommt es nur selten vor, dass per kompletten UserAgent mittels equal Rule (==) geblockt werden kann. Meist sind es Keywords und/oder Muster in UserAgents sowie Headers.

Bei ASN-Blocking muss u. a. aufgepasst werden, dass keine VPN-User geblockt werden.

Rate Limit
Das ist eine verlockende Methode. Bei mindestens einer meiner Websites kommt dies jedoch nicht in Frage. Da dürfen User sehr schnell durchklicken. Bisheriger Rekord: 5 Page-Requests in 1 Second. Das sind dann aber meist keine fresh requests, sondern via Browser/Android-Navigation Back-Button. Dabei wird der Content aus dem Cache geladen und der Server registriert nur einen Request, was immens schneller ist als fresh Requests mit content load.
Um bei der Website ein Rate Limit einzubauen, müssten die Requests in eine Datenbank gespeichert und mittels dieser nach Mustern ((fresh_request === true) && (recurring_visit === false) && (last_visit_time < current_visit_time)) geblockt werden. Das ist zu aufwendig.

Gesetz
Der Counterpart von einem Gesetz zur Pflicht Bots erkenntlich zu machen wäre, dass Nicht-Bots sich erkenntlich machen und Bots diese Methode nicht verwenden dürfen. Aber auch das ist keine optimale Lösung.

 

[GrumpyCat]

Macht Matomo mittlerweile auch

Klar machen viele Produkte unsinniges Zeugs, schon alleine weil die Leute danach fragen.

Es ist sehr effektiv. Es gab aber auch schon einen False-positive

Wenn jemand z.B. seinen eigenen VPN-Server bei AWS betreiben will, wieso sollte ich ihn davon abhalten?
Oder frag mal Freifunk-Leute, was die von IP-Blocking halten.

Es ist davon auszugehen, dass Anubis und Cloudflare das auch so machen.

Das sind beides aus unterschiedlichen Gründen Schrottlösungen. Zu Anubis habe ich oben schon einen Link gepostet; Cloudflare ist eine proprietäre nervige unberechenbare viele Sachen kaputtmachende "Lösung", die schon nur als CDN fraglich ist (z.B. ist Akamai als Alternative älter, größer, weniger nervig).

Rate Limit
Das ist eine verlockende Methode. Bei mindestens einer meiner Websites kommt dies jedoch nicht in Frage. Da dürfen User sehr schnell durchklicken. Bisheriger Rekord: 5 Page-Requests in 1 Second.

Ich schrieb "Admins schnell mit den Regeln überfordert" und "Mehr als 60 Threads in 60 Sekunden". Regeln pro Request (allgemein) oder pro Sekunde aufzustellen macht keinen Sinn. Ist aber offensichtlich zu komplex.

U.a. deswegen auch mein Hinweis von vorher, das alles das eigentlich in die jeweilige Website-Software eingebaut werden müsste; auch nur die weiß auch (sicher), ob der Request z.B. von einem authentifizierten Benutzer kommt oder nicht.

 

[Mirlo]

Wenn jemand z.B. seinen eigenen VPN-Server bei AWS betreiben will, wieso sollte ich ihn davon abhalten?

Das wäre dann der Bot-War. Wenn AWS das Betreiben von nicht erkennbaren Bots erlaubt, dann hat AWS Pech gehabt und ist blacklistet, komplett. Die User suchen sich dann einen anderen Anbieter. Einfach mal die Machtverhältnisse umkehren. Bei Firmen-Websites ist das nicht ratsam. Bei vielen anderen schon.

Ist aber offensichtlich zu komplex.

Ja, ist es. Es müssten alle Requests/Visits in einer Datenbank gespeichert werden, die dann fürs Filtern verwendet werden kann. Sehr aufwendig. Zumal das auch nur einen Teil der Bots blockt.

das alles das eigentlich in die jeweilige Website-Software eingebaut werden müsste; auch nur die weiß auch (sicher), ob der Request z.B. von einem authentifizierten Benutzer kommt oder nicht.

Was heißt hier "authentifizierter Benutzer"? Bisher geht es hauptsächlich darum Bots zu erkennen und nicht darum Humans zu erkennen. Wenn ein Human wie ein Bot wirkt, dann Kollateralschaden. Wenn ein Bot wie ein Human wirkt, dann Lücke.

Das läuft dann auf das bereits erwähnte "Beschleunigen" der Sache hinaus, dass dadurch Bot-Betreiber immer mehr darum bemüht werden ihre Bots wie Humans wirken zu lassen. In diesem War werden massenweise IP CIDR-Blöcke per ASN Firmennamen komplett blacklistet und sind verloren.

Anders sieht es aus bei Cloud-Anbieter, die von starken Firmen genutzt werden, wie Akamai von Apple für das iCloud Private Relay (ähnlich VPN). Die können nicht blacklistet werden, weil dann alle Apple-Nutzer geblockt werden.

Bei reinen VPN-Anbietern, die keine Bots und erst recht keine nicht-erkennbaren Bots betreiben, besteht kein Anlass zum Blocken.

Es ist zudem zu beachten, dass wenn rein per PHP geblockt wird, nur der Website-Content geblockt wird. Alles andere, wie Image Requests, wird dabei nicht geblockt, insoweit (direct view) nicht per .htaccess geblockt ([F] = Forbidden). Geblockt werden allerdings auch Requests von nicht existierenden URLs, wenn eine eigene 404 Page besteht und das Blocken darin inkludiert ist. Damit werden dann auch Security-Bots geblockt, die das Internet auf Websites mit Schwachstellen durch-crawlen. Die zB alle Domains mit Wordpress-Urls requesten, auch wenn keines installiert ist.

Bei diesem komplett Blocken wird nicht zwischen Human und Bot, sondern zwischen Human / Good Bot und Bad Bot unterschieden. Bisher ist die Lösung dafür so, dass zuerst alle Bots geblockt und anschließend nur die Good Bots durchgelassen werden. Das kann auch als Bypass gestaltet werden.

 

[GrumpyCat]

Es müssten alle Requests/Visits in einer Datenbank gespeichert werden, die dann fürs Filtern verwendet werden kann.

Nö, wozu? fail2ban schaut in die Logdateien und fertig. Kennst Du fail2ban nicht? Nicht dass das eine schöne oder wirklich ausgereifte Lösung wäre, aber es funktioniert.

Was heißt hier "authentifizierter Benutzer"? Bisher geht es hauptsächlich darum Bots zu erkennen und nicht darum Humans zu erkennen.

Ist doch Unsinn. Wenn Dir Deine Benutzer was wert sind, müssen die 100%ig immer durchkommen, also gewhitelisted werden.
Und Bots können, solange der Server noch Kapazitäten hat, einfach durchgelassen werden. Hab ich ein paar Postings vorher beschrieben.
Das ganze Geraffel/Gehacke mit ASNs und Proof of Work (Anubis etc.) kann man sich dann sparen; beides bringt auch schlicht wenig, wenn's jemand ernst meint.

Bei reinen VPN-Anbietern, die keine Bots und erst recht keine nicht-erkennbaren Bots betreiben, besteht kein Anlass zum Blocken.

Weil kein VPN-Kunde jemals Crawler betreibt oder wie?