Desktop

Anubis Firewall pro/contra

Mirlo

Lieutenant
Registriert
Feb. 2025
Beiträge
557
Hallo,

beim Thema Bad Bot Blocking ist die Anubis Firewall big im Gespräch. Da ich seit einiger Zeit am Bad Bot Blocking interessiert bin, habe ich mich mal über Anubis informiert. Hier meine Infos, Pros und Contras.

https://anubis.techaro.lol/
https://github.com/techaroHQ/anubis

Anubis schaltet ein Proof-Of-Work (POW) bei jedem Request ein, der vom Client (Browser) und Server erfolgreich erledigt werden muss, damit der requestete Content ausgeliefert wird. Wobei ich mir noch unsicher bin, ob der POW bei jedem Request eingeschalten wird. Zudem ist mir bisher auch unbekannt, ob weitere Filterregeln in Anubis inkludiert sind, wie zB den User Agent und die Browser Header auswerten.

Pro:
  • für Webmaster, die gerne Lieferservice-Fraß konsumieren als selbst was zu machen. (wie WordPress User)
  • kein Captcha.
  • die Software wird stetig up to date gehalten, was auch Anpassungen am POW und so weiter inkludiert.
  • kostenlos.

Contra:
  • im Client muss JavaScript aktiviert sein. (purer HTML Zugriff auf Websites ist nicht oder doch möglich?)
  • es wird ein Cookie gesetzt.
  • scheinbar wird Anubis bei jedem Request eingeschalten.

JavaScript required und Cookie setting sprechen bei mir gegen eine Nutzung von Anubis. Meine Websites sollen auch ohne JavaScript nutzbar sein, insoweit keine Webtools, die JavaScript benötigen. Zudem sind meine Websites seit dem Cookie-Consent-Zwang alle cookieless.

Meine Erfahrungen im Bot Blocking zeigen, dass nicht jeder Request ein POW benötigt. Es geht eher um Mustererkennung bei den Requests. Wird ein Muster gematcht, dann blocken. Doch so einfach ist es nicht. Es ist besser eine "alternative" Methode als Zugang zum Content anzubieten, die vornehmlich nur von Humans ausgeführt werden kann, was keinen Captcha oder ähnlich meint.

Was wäre ein Krieg (Bot War) ohne Angriffe? Auf meinen Websites habe ich nun schon mehrere verschiedene erlebt. Die neuesten Bad Bots haben JavaScript und nutzen scheinbar zudem AdBlocker und blocken JS-Tracker, was nicht alle machen/haben. Dadurch sind sie von Webmastern im Tracking nicht sichtbar, aber weiterhin im Traffic und Access Log. Den von ihnen erzeugten Traffic und Access Log entry würden sie vermutlich auch gerne invisiblen, damit sie vollkommen unsichbar aggieren können, aber das haben sie nicht drauf, (noch nicht?). Vollkommen invisible Bots würde bedeuten, dass sie die Server hacken, um an den Content zu kommen, was einige schon machen.

Alles was über die Bad Bots berichtet wird stimmt. Es sind sehr viele und werden stetig mehr. Sie nutzen IPs von ISPs (Internet Service Providern) [angeblich indem sie IoT Devices verwenden, wie über Apps oder Proxies in den Devices von Usern]. Sie wechseln die IP bei jedem Request. Sie nutzen moderne/aktuelle Browser mit JavaScript und blocken JS-Tracking.

Es gibt einen Unterschied bei den Bad Bots. Dieser ist vermutlich an deren Preis auszumachen. Die billigen können kein JavaScript und nutzen keine IP-Switcher, sowie auch keine UserAgent-Switcher. Da der Referer vom Browser generiert wird, kann dieser sowie alle Browser Header gefälscht werden.

Das Blocken von IPs / CIDRs / ASNs sowie Mustern in Browser Header und User Agent sowie Referer und Request-Url bringt nur bei billigen Bots Abhilfe, aber ist weiterhin hilfreich, da somit nicht alle Bad Bots mit den selben Mitteln geblockt werden.

Bisher haben auch die neuesten und besten Bad Bot Browser Schwachstellen, die zum Blocken genutzt werden können. Da habe ich aber aktuell keine Lust diese preiszugeben.

Unangenehm ist immer die Mühe, die Bad Bot Requests aus den Tracking-Logs zu löschen. REGEX ♥ hilft.

Meine offene Frage zu Anubis ist, ob Anubis alle Requests gleich behandelt, oder ob es zwischen billigen und modernen Bad Bots unterscheidet?

Ich habe mal probiert den Anubis POW für eine standalone Verwendung aus dem Repository heraus zu extrahieren, mittels ChatGPT. Es ist wohl nicht ohne weiteres möglich und hat Schwachstellen. Getestet habe ich es noch nicht.

Der Anubis POW führt Berechnungen im Browser und auf dem Server durch. Beide werden so behandelt, dass das eine das andere nicht beeinflussen kann. Wie, ist mir nur schematisch bekannt. Vielleicht weiß hier einer mehr darüber.

Was sind deine Pros und Contras zu Anubis? Würdest du es nutzen oder nutzt du es bereits?
 
Ich bin froh das es Anubis gibt, blockt bei mir zuverlässig zu 99% bösartige Bots/Scraper. Es gab Zeiten da wurde der Webserver regelrecht mit Bots/Scraper Anfragen bombardiert, schlimmer wie bei einem DDoS Angriff.

Javascript ist notwendig da sonst kein Challenge ausgeführt werden kann. Man kann aber selbst Ausnahmen definieren. Wenn kein Javascript im Browser aktiviert ist kommt dann in der jeweiligen Sprache folgendes Fenster:

anubis.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Mirlo
Und das passt in Deine anderen Bad Bots-Threads nicht rein, weil .. ? [es hat nebenbei nichts mit Programmieren zu tun]
 
Helge01 schrieb:
Javascript ist notwendig da sonst kein Challenge ausgeführt werden kann.
Das ist eine meiner Fragen, ob das POW (Challenge) bei jedem Request vorgeschalten wird, abgesehen von selbstdefinierten Ausnahmen? Meine Erfahrungen sind, dass es nur bei gewissen Bad Bots notwendig ist, aber nicht bei allen. Daher auch meine Frage, ob Anubis zwischen den Bad Bots unterscheidet?

Oder anders gesagt: JavaScript ist ein guter Blocker für Bad Bots ohne JS-Browser, aber das soll nicht dazu führen, dass Websites nur noch mit aktiviertem JavaScript erreichbar sind. Das Anubis POW sollte nur bei Bad Bots mit JS-Browsern vorgeschalten werden, bzw. sollte für Humans eine alternative Methode für den Zugang zum Content bereitgestellt werden.
 
Zuletzt bearbeitet:
Mirlo schrieb:
Das ist eine meiner Fragen, ob das POW (Challenge) bei jedem Request vorgeschalten wird
Würde bei jedem Request passieren wenn von Anubis kein Cookie gesetzt wird. Die Gültigkeit des Cookie kann man konfigurieren, standardmäßig sind es 7 Tage. In dieser Zeit ist für den Browser dann kein Challange mehr notwendig.

Mirlo schrieb:
das soll nicht dazu führen, dass Websites nur noch mit aktiviertem JavaScript erreichbar sind.
Das ist zur Zeit aber notwendig, ohne gibt es keinen Zugriff. Eine Javascript freie Version soll es ja irgendwann mal geben (steht ja auch in den Bild von mir).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Mirlo
Helge01 schrieb:
Die Gültigkeit des Cookie kann man konfigurieren
Danke für die Info. Also wäre eventuell eine Nutzung von Anubis ohne Cookies möglich, nur wird dann der Anubis POW bei jedem Request durchgeführt. Das bedeutet mehr Serverlast.
Ergänzung ()

Helge01 schrieb:
Das ist zur Zeit aber notwendig, ohne gibt es keinen Zugriff.
Ja, leider, bei mir nun auch, aber nicht bei allen Bad Bots, sondern nur bei speziellen.

Da für die Bad Bots Zeit ein relevanter Faktor ist, überlege ich den Content verzögert auszuliefern. Zuerst nur eine kleine Vorschau und nach einiger Zeit den gesamten Content. Dann würden diese Bad Bots nicht mehr bekommen, als Search Engines indexieren. Aber dabei ist das Bouncing der Humans zu beachten, die während dieser Zeit bei Laune gehalten werden müssen.
 
Zuletzt bearbeitet:
Mirlo schrieb:
Also wäre eventuell eine Nutzung von Anubis ohne Cookies möglich, nur wird dann der Anubis POW bei jedem Request durchgeführt.
So ist es.

Ich habe die Cookie Nutzung von Anubis einfach in die Datenschutzseite mit aufgeführt. Da es ein technisch notwendiges Cookie ist, benötigt man eigentlich auch kein Cookie Banner.

Das bedeutet mehr Serverlast.
Für den Server gibt es kaum merklich mehr Last, aber für den Client. Das könnte sich bei mobilen Geräten auf den Akkuverbrauch auswirken.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Mirlo
Helge01 schrieb:
Da es ein technisch notwendiges Cookie ist
Hmmmm, OK, diese Sache wieder, stimmt ... Aber es könnte auch behauptet werden, dass dadurch Identifizierung möglich ist. Also Cookie-Time maximal Browser-Session oder 1 Stunde. Bin kein Freund von Cookies. Da steht sich mal wieder Datenschutz und Contentschutz kritisch gegenüber. Die "technische Notwendigkeit" bezöge sich wenn dann nur auf die Schonung der Serverlast. Denn rein theoretisch könnte auch pro Request ein POW durchgeführt werden. Der Webmaster muss also entscheiden: Serverlast oder kein Visit. Der User muss entscheiden können: Cookieless oder Content. Also doch Cookie Consent Banner, bzw. wenn strict, dann: kein Cookie, kein Content. Mit Hinweis: Cookie schützt die Umwelt (Server).
Ergänzung ()

Helge01 schrieb:
Für den Server gibt es kaum merklich mehr Last, aber für den Client. Das könnte sich bei mobilen Geräten auf den Akkuverbrauch auswirken.
Ah, wichtige Info! Danke. Also liegt die Entscheidung nochmals etwas anders.
 
Zurück
Oben