Finde den Artikel in vielen Punkten widersprüchlich. Einerseits sagen sie, das Thema ist kompliziert und vertraue keinen einfachen Lösungen. Andererseits verkaufen sie genau das: binde unseren Service mit einer Zeile Code ein und Du bist 80% der Bots los. Oder es sei dumm, nur auf den user agent zu setzen. Die Liste, die sie veröffentlicht, ist… eine Liste von user agents
Für die Agents gäbe es sonst auch (u.a.) Dark Visitors. Ich hatte mich mal wesentlich nach dem eingangs erwähnten Artikel " How to Avoid High CPU Load and Block Hackers and Bad Bots Effectively" und hinterher aber noch eine Variante aus dem Thread dazu genommen.
Das Blocklist klingt vom Ansatz ähnlich wie Crowdsec (aber das überlassen wi jetzt mal dem neuen Kollegen, ob er das nutzen will ;)).
Wir hatten bei unserer Recherche-Infrastruktur gegen Mitte letzten Jahres auch Ueberlastspitzen, die punktuell leider auch zu einem kurzen Ausfall gefuehrt haben.
Wir setzen zwei Cluster aus je 4 dedizierten Servern ein, eines fuer die eigentlichen Anfragen und eines im Standby, um die naechste Aktualisierung durchzufuehren. Ist die Aktualisierung fertig, dann switchen die Cluster. Davor haengt als Lastverteiler und SSL-Endpunkt ein HaProxy, dessen Verteilung aus der Recherche-Infrastruktur gesteuert werden kann.
Daher haben wir ad hoc eine Loesung auf Basis von HaProxy konzipiert, mit der wir seither ganz gut gefahren sind. Generell arbeiten wir auch mit dynamischem Blocking von ganzen Netzbereichen, weil Analysen der Anfragen damals gezeigt haben, dass - wie in diesem Thread von anderen schon berichtet - pro IP jeweils an sich wenige Anfragen geschickt wurden, sich diese aber bezogen auf IP-Bereiche bestimmter ‚Organisationen‘ massiv haeuften.
Um die Recherche-Infrastruktur mit HAproxy zu schuetzen nutzen wir konkret dessen ‚stick-table‘-Feature.
Ueber dieses koennen in HaProxy Request- und Error-Raten nach verschiedenen Kriterien in Echtzeit protokolliert werden. Anhand dieser Raten versuchen wird dann regelbasiert „auffaelliges“ Verhalten zu identifizieren und zu blocken.
Hier einige Stichpunkte:
Verwendung einer stick-table zur Verfolgung der Request- und Error-Raten bezogen auf einzelne Subnetzbereiche
Verwendung einer stick-table zur temporaeren Speicherung (aktuell 6 Stunden) von Netzbereichen aus der ersten stick-table, die aufgrund hoher Request- und Error-Raten „auffaellig“ geworden sind.
Verwendung verschiedener Schwellwerte fuer Request- und Error-Raten, ab denen Eintraege aus der ersten stick-table als „auffaellig“ eingestuft werden. Dazu werden IP-Listen mit Ursprung in Deutschland sowie eine mit privilegierten IP-Bereichen gefuehrt, anhand derer verschiedene Schwellwerte gesetzt werden. Das sind
** Generell privilegierte IP-Subnetze
** Deutsche IP-Subnetze
** IP-Netze ausserhalb Deutschlands
Ist ein zugehoeriger Schwellwert erreicht, dann werden fuer die naechsten 6 Stunden weitere Anfragen aus diesen Netzbereichen mit HTTP 429 (Too many request) abgelehnt.
Mehrfach auffaellig gewordene IP-Subnetze werden
in einer Datei gesammelt, so dass Anfragen immer mit HTTP 403 abgelehnt werden
besonders boese ggf. direkt per ufw in der lokalen Firewall des Lastverteilers geblockt, so dass diese erst gar nicht mit haproxy in Kontakt treten und diesen belasten koennen
Einschlaegige unerwuenschte User-Agents, z.B. von AI Bots, werden ebenfalls in einer Datei gesammelt und Anfragen von ihnen immer mit HTTP 403 abgelehnt
Leider ist keine Loesung wirklich perfekt und es kann natuerlich auch nicht ausgeschlossen werden, dass overblocking stattfindet. Hier muss also letzlich abgewogen werden wieweit man gehen will und kann.
Falls sich jemand fuer die stick-tables interessiert, dann hier als Einstieg zwei Links
Hallo @flimm und Willkommen im Forum !
Hm, diese Datei mit den „besonders bösen Subnetzen“ könnte ich mir gut in der Firewall der Institution vorstellen, nicht nur in der lokalen Firewall. Diese IPs dürften ja auch allen anderen Diensten und Servern nur Ärger machen. Was hält euch davon ab? Und falls das doch Sinn machen würde, dann wohl auch für andere Institutionen. Ein regelmäßiger (z.B. täglicher) institutionsübergreifender Austausch dieser Listen wäre doch interessant, oder @phu ? (allein auf blocklist.de würde ich mich nicht verlassen wollen, bin da skeptisch, ob da nicht auch „gute“ IPs gemeldet werden. Ein Abgleich der Listen könnte „false hits“ aber sicherlich verringern.)
Die Bots kann man sicher eintragen (hab ich bei Fail2ban), aber wie der Artikel sagt, die wirklich fiesen sind jetzt die, die mit dutzenden IPs und minimal variierenden Agent-String stinknormaler Browser kommen.
Ich fürchte, bei der derzeitigen Verunsicherung und Ratlosigkeit der Sysadmins wird es vermehrt zu (zumindest zeitweise) Overblocking kommen oder das passiert bereits. Da wird „aus Notwehr“, bevor der Service gar nicht mehr erreichbar ist, Geo-IP-Blocking betrieben und ganze Länder und Kontinente geblockt. Oder Menschen, die Javascript deaktiviert haben oder Text-Browser benutzen, so wie das beim Einsatz von Anubis der Fall ist.
Many libraries are routinely blocking entire countries (nobody in china could possibly want books!) just to be able to serve a trickle of local requests.
Gerade vorhin auch (das erste mal) entnervt drei A-Netze geblockt…
Da unser Discovery komplett Off-Limit für Bots ist (also gemäß robots.txt), erwarten wir nur Menschen und das absolut überwiegend aus deutschsprachigen Ländern. Da könnte das so „billig“ reichen. Und es wäre kein totaler Geoblock, den wir keinesfalls wollen. Spannend dann, ob Bots so popelige Aufgaben tatsächlich lösen bzw. ob für so Seiten wie unsere da Energie investiert wird.
Da ein Log geschrieben wird, können Fehlversuche aber wiederum von Fail2ban gehandhabt werden.
Aber bin gespannt, was für Lösungen Wikimedia finden wird.
