Dieser Post setzt ein bei der Veröffentlichung der Version 1.5.0 des Anti-DoS-Valves begonnenes Thema fort: Wie kann man seine Webserver gegen aggressive Webscraper und DDoS Angriffe schützen, die sich nicht mehr leicht über ihr Verhalten auf Ebene einzelner IP-Adressen identifizieren lassen, und die insbesondere durch den Einsatz von Residential Proxies von überall her kommen können?
In diesem Post geht es um die Idee solchen Akteuren einen Teil der Arbeit zurückzugeben, die sie unseren Servern und uns als Admins aufbürden, um so die Zugriffe unattraktiv zu machen oder sie zumindest stark auszubremsen. Spoiler: Ich habe diese Idee zunächst spannend gefunden, sie dann verworfen, erneut aufgenommen, und verwerfe sie jetzt wieder, und dabei spielt KI auch eine Rolle.
Zumindest für meinen konkreten Anwendungsfall werde ich diese Idee nicht mehr weiterverfolgen, aber ich schreibe meine Überlegungen hier auf, falls ich das vielleicht erneut revidiere. Als konkretes Beispiel habe ich dabei Anubis genutzt, eine Implementierung einer Proof of Work Schutzfunktion. Aber von Anfang an:
Die Idee: Kosten zurückgeben
Es gibt eine große Asymmetrie bei den Aufwänden, die wir als Webserverbetreibende haben unsere Inhalte sicher und verlässlich ins Netz auszuliefern, und den Aufwänden, die ein Angreifer – und das sind auch Webscraper für mich – damit hat nach unseren Inhalten zu fragen. Während wir komplexe Architekturen mit Webservern, Applikationsservern, Datenbanken, Loadbalancern etc. betreiben, reicht der Gegenseite ein einfaches Kommando wie
curl https://www.uni-bielefeld.de
aus, um die Inhalte abzugreifen. Natürlich ist es heute nicht mehr ganz so einfach. Wenn man das ganze Internet regelmäßig abernten möchte braucht man auch eine große Infrastruktur und Strategien, wie man zumindest simple Sperren umgehen kann. Trotzdem zeigen die Erfahrungen, dass die Asymmetrie geblieben ist und die Kosten und der Schaden durch solche Angriffe im wesentlichen bei uns Serverbetreibenden bleiben.
Wenn also ein Ausbremsen oder Blockieren mit Mitteln wie dem Anti-DoS-Valve nicht gelingt, kann man dann vielleicht die Kosten für die Zugriffe in einer Weise hochtreiben, die das Ganze für die Angreifer unattraktiv macht? Oder wenigstens um die Rachegelüste auszuleben, die man während solcher Angriffe entwickelt? Diese Konzepte sind als Proof of Work (PoW) Verfahren bekannt und darin steckt die Idee, dass die Angreifer mehr Rechenzeit investieren müssen.
Was sind Kosten? Und warum ist Zeit der bessere Faktor?
Ich möchte diesen Punkt bereits hier behandlen: Meist ist mit Kosten für die Angreifer der Aufwand in Rechenzeit gemeint, der pro Request aufzubringen ist. Statt eines schnellen curl-Aufrufs, der nur Millisekunden in Rechenzeit pro Zugriff benötigt, sollte am besten jeder Request spürbar Zeit brauchen. Warum spreche ich hier nun von Zeit an Stelle von Kosten? Weil sich Zeit letztlich als das relevantere Maß erweisen wird und das ist eines der Probleme am PoW Konzept, auch wenn die Idee zunächst schlüssig klingt:
Wie kann man Angreifer dazu zwingen mehr Zeit pro Request aufzuwenden? Leider ist es keine Lösung die Angreifer auf dem eigenen Servern zum Warten zu zwingen, in dem man sie z. B. in eine Warteschlange packt: Zu schnell werden die Angreifer alle Ressourcen belegt haben und man hat einen Totalausfall aus Sicht der regulären Nutzer*innen, die ja in der gleichen Warteschlage stecken. Und selbst wenn die Warteschlange unendlich groß ist: Da letztlich doch alle Requests durchgelassen werden leiden die eigentlichen Arbeitsserver doch wieder unter der Last. Denn nichts hindert die Crawler daran während dieser Wartezeit schon die nächsten 1.000 Requests abzusetzen.
Es braucht also einen Weg, wie die Arbeitslast auf die Seite der Crawler transportiert werden kann: Nur wenn dort die Rechenzeit verschwendet wird kann man zumindest grundsätzlich das Ziel erreichen, dass weniger Requests auf den eigenen Servern ankommen bzw. selbst wenn die Zahl nicht abnimmt man sie zumindest deutlich leichter abweisen kann. Tools wie Anubis sorgen daher dafür, dass der Crawler erst ein mathematisches Rätsel lösen muss, bevor sie weiterkommen, eben den Proof of Work. Leider müssen auch alle normalen Nutzer*innen einer so geschützten Webseite diesen Proof erbringen.
Designfrage: Wie oft verlangt man den PoW?
Bevor wir zu Details solcher Implementierungen kommen eine grundsätzliche Überlegung dazu, wie oft man den PoW verlangen könnte. Das sind die Optionen:
- Bei jedem Request: Eigentlich das, was man will, zumindest wenn man einen Server hätte, der ausschließlich von Scrapern besucht wird (aber warum sollte man so einen Server überhaupt noch betreiben?). In technischer Sicht hätte es den Vorteil einfach und konsistent zu sein und die Kosten für Scraper sind maximal und einfach skalierbar. Aber auch für alle anderen Nutzer*innen würde das gelten. Dieser Weg ist daher nicht gangbar, denn wofür optimieren wir die Ladezeiten unserer Webseiten so gut es nur geht, wenn wir dann wieder jedem Zugriff ausbremsen?
- Beim ersten Request und dann hin und wieder: Dieses Konzept ähnelt konzeptionell einem Loginsystem. Hier melde ich mich einmal an und bin dann für X Stunden / Tage angemeldet bzw. für Zugriffe freigeschaltet. Das ist es faktisch, was z. B. Anubis tut. Hier muss es für die folgenden Zugriffe aber ein Merkmal geben, welches der Webbrowser vorweisen kann um zu leben, dass er seinen PoW schon geleistet hat.
- Hier landet man dann bei Cookies, localStorage oder vielleicht sogar bei URL-Rewriting, ähnlich wie es Java Server machen für ein cookiesloses Sessiontracking. Die Validierung des Beweises, dass der PoW erbracht wurde, noch gültig ist und auch für den Client, der ihn einreicht, ausgestellt wurde muss schnell und effizient möglich sein, damit unsere Server dadurch nicht stark belastet werden.
- Wenn einem die Sichtbarkeit der eigenene Seite in Suchmaschinen wie Google wichtig ist entsteht hier ein Problem: Suchmaschinencrawler akzeptieren eher keine Cookies oder andere, persistente Merkmale und verhalten sich bei jedem Request wie eine neue Nutzerin. Man kommt hier schon in zusätzliche Komplexität durch ein ggf. notwendiges Whitelisting von gewollten Crawlern.
- Die wesentliche Stellschraube bei diesem Konzept ist die Frage wie oft man den PoW verlangt. Anubis hat hier einen Default vom 7 Tagen, was mir lang vorkommt, aber vielleicht gar keine Relevanz hat:
- Eine andere Stelleschraube ist die Frage ob und wie man einen PoW-Nachweis an den Client bindet, für den man ihn einmal ausgestellt hat. Ohne so eine Bindung könnte ein Scraper Netzwerk einen einmal erhaltenen Nachweis über alle seine Clients verteilen und ungebremst agieren. Anubis bindet hier per Default den Nachweis an die IP-Adresse, für die er erstmalig ausgestellt wurde. Das hört sich zunächst vernünftig an, tatsächlich haben wir in unserem Loginsystem auch eine kurze Phase, in der wir bestimmte Abläufe nur von einer identisch bleibenden IP-Adresse erlauben.
- Diese Funktion macht aber die Stellschraube der Lebensdauer des Nachweises nachzu irrelevant, denn heute bekommt man viel häufiger eine neue IP-Adresse zugewiesen, insbesondere wenn man mobil unterwegs ist. Auch Übergange ins Firmen-VPN oder das Uni WLAN sorgen für Adresswechsel und hier würde man doch wieder jedes Mal aufgefordert den PoW erneut zu leisten.
- Relevanz hat die Einstellung vielleicht bei den wenigen Netzanbietern, die alle ihre Kunden über einige wenige IP-Adressen ins Netz gehen lassen. Bei solchen Anbietern verliert die IP-Bindung des Nachweises ihre Schutzfunktion.
- Einmal und nie wieder: Der Vollständigkeit erwähnt sei auch noch die Option ein einziges Mal einen PoW zu verlangen und den Nachweis der Erbringung dann unbegrenzt zu akzeptieren. Das hätte Ähnlichkeit mit einem API-Token. Man könnte so ein Konzept vielleicht höchstens nutzen um seinen bekannten Nutzer*innen verbunden mit einem Login so einen Nachweis auszustellen, damit sie auch ohne Login nie wieder vom PoW behelligt werden.
Der mittlere Ansatz ist klar der realistische, aber er zeigt auch wie schnell das Thema kompliziert wird, wenn man versucht eine Balance zwischen der Blockade von Scrapern, der Offenheit für Suchmaschinen und der guten Webseiten Performance für normale Nutzer*innen zu finden. Ich halte das letztlich für nicht möglich:
Wem raubt man eigentlich die Zeit?
Ich habe Anubis, auf das mich ein Kollege aufmerksam gemacht hat, nicht gewählt um dieses Projekt und seine guten Absichten schlecht zu reden. Es ist ein Versuch ein Problem, welches alle Betreiber*innen von Webseiten haben, in einer Weise anzugehen, die einen nicht zwingt sich hinter den Schirm von großen Anbietern wie Cloudflare zu begeben. Trotzdem fand ich das Zitat von Tavis Ormandys Post von August 2025 zu Anubis sehr treffend:
So how do some useless SHA-256 operations prove you’re not a bot? The argument goes that this simply makes it too expensive to crawl your website.
This… makes no sense to me. Almost by definition, an AI vendor will have a datacenter full of compute capacity. It feels like this solution has the problem backwards, effectively only limiting access to those without resources or trying to conserve them.
Ormandy zeigt in seinem Post dann ein kleines C Programm, welches das damals in Anubis verwendete Challenge in Millisekunden lösen konnte und quasi keine Kosten verursachte in einer minimalen Cloudinfrastruktur. Gleichzeitig melden sich Nutzer*innen, deren schon etwas ältere Smartphones sie viele Sekunden darauf warten lassen, dass Anubis sie endlich durchlässt. Der Claim von Anubis die ‚Seelen‘ der Zugriffe zu wiegen, angelehnt an die ägyptische Mythologie, scheint hier die Schuldigen besser abschneiden zu lassen, als die Unschuldigen.
Das grundsätzliche Problem dabei ist: Proof of Work Verfahren haben keine verlässlichen Informationen über den anfragenden Client, der es ihnen erlauben würde die zu erbringende Arbeitslast anzupassen. Das ist ein Henne-und-Ei Problem: Wenn ich erkennen könnte, dass ein Zugriff von einem Headless Browser aus einer Cloudinfrastruktur oder von einem Smart-TV kommt und nicht von einem unserer Studieninteressierten, dann könnte ich diese Information ja auch direkt nutzen für eine Blockade. Habe ich diese Information aber nicht, so sorgt ein Verfahren wie Anubis nur dafür, dass die normalen Nutzer*innen genervt werden und mein Google Ranking vielleicht ins Bodenlose fällt.
Ich sehe keinen Weg ein PoW Verfahren einzuführen, welches auf der einen Seite wirklich Last von unseren Servern abhalten kann, aber auf der anderen Seite keine große Kollateralschäden verursacht.
Ein Versuch: Wie schnell kann eine KI Anubis überwinden?
Mich hat dann noch diese Frage interessiert: Anubis soll gegen Crawler helfen, die vermutlich für KI-Training Daten sammeln. Aber wie schnell lässt sich mit KI diese Sperre überwinden? Auch das beeinflusst die Kostenkalkulation eines Angreifers: Muss ich wirklich einen kompletten Headless Browser laufen lassen, damit der Anubis Code wie in einem normalen Webbrowser ausgeführt wird, oder kann ich – ähnlich wie es Ormandy gezeigt hat – einen deutlich performanteren Weg wählen? Ich habe in Antigravity ein neues Projekt mit diesem Prompt gegründet:
Ich möchte meine Webseite mit Anubis vor Crawlern schützen:
https://github.com/TecharoHQ/anubis
Aber ich habe zugleich interne Nutzungen meiner Seite, die per Script die Inhalte abrufen müssen. Hier brauche ich eine Lösung, die mir das notwendige proof-of-work Cookie über ein Script erzeugt und mir das Cookie für die Verarbeitung in meinem vorhandenen Script übergibt.
Bitte mache eine Analyse von Anubis und schlage mir eine Vorgehensweise vor. Meine Lieblingsprogrammiersprache wäre Java in einer möglich modernen Version, ich möchte in Script erhalten, dem ich die Adresse meines mit Anubis geschützen Servers geben kann und es soll ein Cookie ausgeben.
Ich möchte hier eine Testmöglichkeit haben, bitte erzeugte ein Verfahren, bei dem ein lokaler Server mit einer Anubis Instanz läuft, gegen die Du das Script testen kannst
Die Formulierung, dass es mir um einen eigenen Server geht habe ich gewählt um nicht an eventuellen Guardrails zu scheitern und das hier eingesetzte Claude Sonnet 4.6 Modell hat auch nicht gezuckt. Auch nicht, es ich es später Tests direkt mit der Anubis Homepage haben machen lassen. Um das Ergebnis vorweg zu nehmen: Es hat geklappt, der dabei generierte Code kann komplett hier als ZIP-Datei abgerufen werden.
Aber es hat zugegebenermaßen länger gedauert, als ich erwartet habe. Offenbar hat Anubis seit dem Post von Ormandy ein paar neue Optionen bekommen, hier eine Algorithmen-Übersicht aus der Analyse der KI, die sich auch in der README.md im ZIP findet:
| Algorithmus | Typ | Wartezeit | Berechnung | AntiAnubis |
|---|---|---|---|---|
| fast | SHA-256 PoW | keine | Brute-Force | ✅ |
| slow | SHA-256 PoW | keine | Brute-Force | ✅ |
| preact | SHA-256 | difficulty × 80 ms | 1× SHA256 | ✅ |
| metarefresh | HTTP-Redirect | difficulty × 800 ms | keine | ✅ |
| sha256 (WASM) | WASM PoW | keine | WASM | ❌ |
| argon2id (WASM) | WASM PoW | keine | WASM | ❌ |
| hashx (WASM) | WASM PoW | keine | WASM | ❌ |
Die WASM-Optionen sind eine ganz frische Entwicklung, die KI war in vertretbarer Zeit nicht in der Lage eine lokale Teststellung zu entwickeln. Da es zumindest heute auch Fallbacks gibt spielt dies bei der Überwindung der Sperre aber keine Rolle. Grundsätzlich ist die Idee spannend mit Argon2 ein Verfahren ins Spiel zu bringen, welches nicht nur rechenzeitintensiv ist, sondern auch definierbare Anforderungen an den Speicherbedarf ermöglicht.
Anubis hat auch ein paar weitere Trick gelernt, zum Beispiel wird geprüft ob ein Client Redirects folgt und es wird im ausgegebenen JWT eine Wartezeit festgelegt, bis der erste Zugriff erfolgen darf. Es hat die KI ein paar Runden gekostet um dies herauszufinden, aber es sind letztlich nur ein leicht überwindbare Stolpersteine, die nicht davor schützen, dass nach dieser Wartezeit die Requests mit Vollgas an den Server geschickt werden.
Aber am Ende lag dann ein Code vor, den ich auf https://anubis.techaro.lol/ richten konnte und der mir die Option gibt danach mit einem einfachen curl-Aufruf an die Inhalte zu kommen.
Aus meiner Sicht beeinflusst das die Kostenrechnung noch einmal deutlich: So lange ein Projekt wie Anubis eine gewisse Obskurität hat und scheiternde Zugriffe durch Crawler auf wenigen Seiten den Betreibern nicht groß auffallen liegt vielleicht ein Schutzeffekt vor. Inzwischen hat Anubis auf Github aber schon mehr als 22.000 Sterne.
Ein motivierter Betreiber einer Crawlerflotte, die schon ganz andere Sperren überwinden muss, wird sicher die Zeit / Tokens investieren einen Baustein zu ergänzen, der mit Anubis fertig wird. Wie man sieht ist das ganz leicht.
Schlussfazit
Es gibt Stimmen im Netz, die Werkzeuge wie Anubis als Sicherheitstheater abkanzeln, also als eine für die normalen Nutzer*innen gut sichtbare Funktion, die aber gegen die eigentlichen Angreifer keine relevante Wirkung entfaltet. Ich würde das nicht ganz so harsch ausdrücken, aber für mich überwiegen die Nachteile:
- Meine regulären Nutzer*innen, gerade auf leistungsschwächeren Geräten, verlieren viel von der Webseitenperformance, an der wir sonst so sehr arbeiten
- Wenn der PoW Nachweis an eine IP-Adresse gebunden wird, dann werden unserer Nutzer*innen vermutlich mehrmals am Tag den PoW erbringen müssen
- Es fügt noch eine Komponente ein in oft sowieso schon komplexer Infrastukturen, die gewartet werden muss und die Supportaufwände macht
- Sie erzwingt Javascript und Cookies bei allen Nutzer*innen, das ist nicht nur bei Anubis so. Auch wenn das Internet heute kaum noch ohne nutzbar ist – auch unser Loginsystem funktioniert nicht ohne Cookies – finde ich es weiterhin einen gewissen Wert Webinhalte in gewissem Umfang auch ohne verwenden zu können
- Es stellt ein Risiko dar beim Suchmaschinenranking, wenn man nicht eine regelmäßige Pflege von Zulassungslisten einsteigen will und den damit verbundenen Aufwand
Dem gegenüber steht ein bestenfalls unzuverlässiger Schutz, der sich trotz der nach und nach eingebauten Tricks immer wieder wird leicht umgehen lassen.
