Am 1. September 2026 wurde CrowdSec 1.8 veröffentlicht – und im Open-Source WAF, das man mit einem helm install auf seinem Server installiert, kamen gleich zwei Dinge auf einmal: Browser-Fingerprinting und Proof-of-Work. Bisher wurde die PoW-Wand in freier Wildbahn hauptsächlich auf Git-Foren und in Archiven von Mailinglisten angetroffen. Jetzt könnte eine solche Schicht auf jeder Website mit fünfhundert Besuchern pro Tag auftauchen.
Wir klären, was genau sich geändert hat, warum die Erkennung in Richtung „bezahle mit der CPU“ gegangen ist und – das Wichtigste – warum der Hash in dieser Konstruktion das kleinste Problem darstellt.
Was passiert ist: PoW ist von Git-Foren auf normale Websites heruntergekommen
CrowdSec ist ein selbstgehostetes System: Der Agent liest die Protokolle, der WAF steht vor der Anwendung, die „Bounce-Server“ blockieren. Im Release 1.8 hat das Team einen Mechanismus in den WAF integriert, der nicht die Frage beantwortet „Ist diese IP schlecht?“, sondern die Frage „Ist das überhaupt ein Browser mit einem Menschen oder ein Bot, der sich als solcher ausgibt?“. Die Antwort wird aus dem Fingerabdruck (Browsermerkmale und TLS-Signatur) und Proof-of-Work – einer Rechenaufgabe, die der Client lösen muss, bevor das Backend die Anfrage sieht – gesammelt.
Die Motivation der Autoren wird ohne Diplomatie formuliert: Der durchschnittliche Bot des Jahres 2026 kommt mit echtem Chrome, konsistentem TLS-Fingerabdruck, residenter IP – und hat mehr Geduld als der diensthabende Ingenieur. Diese Anerkennung seitens der Erkennung ist mehr wert als jede Analyse: residente Adressen und sauberes TLS sind kein unterscheidendes Merkmal mehr. Da Bots sich durch IP-Reputation und Handshake nicht mehr von Menschen unterscheiden, sucht der Schutz nach einem Merkmal, das für den Browser günstig und für den Maschinenpark teuer ist.
Parallel tauchte an denselben Tagen auf Hacker News POWBlock auf – „Proof-of-Work Mikrodienst für jeden Server“. Ein Release könnte man als Zufall abtun, zwei unabhängige Signale innerhalb einer Woche – das ist bereits eine Richtung.
Wie die PoW-Wand am Beispiel von Anubis funktioniert
Das Musterbeispiel des Genres ist Anubis: ein Reverse-Proxy in Go unter der MIT-Lizenz, das von Xe Iaso unter der Marke Techaro seit Januar 2025 entwickelt wird. Die Idee stammt direkt aus dem Hashcash von Adam Back aus dem Jahr 1997: Der Client probiert Werte aus, bis SHA-256 einen Hash mit der gewünschten Anzahl führender Nullen liefert. Gelöst – erhält man einen signierten JWT-Cookie (techaro.lol-anubis-auth) und temporären Zugang. Nicht gelöst – das Backend erfährt nichts von dir.
Die Schwierigkeit wird vom Administrator festgelegt. Standardmäßig fordert Anubis alles heraus, was wie ein Browser aussieht – also alles, was in der User-Agent-Zeile Mozilla enthält. Was jeder Schwierigkeitsgrad kostet, zeigen die Messungen:
- Schwierigkeit 1 – weniger als 100 ms.
- Schwierigkeit 4 (Standard) – etwa 1,35 s auf einem Intel Core Ultra 7 165H, das sind ungefähr 87.600 Hashes pro Sekunde im Browser.
- Schwierigkeit 8 – etwa 11 s.
- Schwierigkeit 10 – etwa 114 s.
Der Unterschied zwischen dem vierten und zehnten Niveau beträgt etwa das 84-fache. Die Liste der Implementierenden sieht beeindruckend aus: das Archiv der Linux-Kernel-Mailingliste und der Git-Server des Kernels, sourcehut, FFmpeg, GitLab-Projekt GNOME, Wine, sourceware.org, FreeCAD, ScummVM, Enlightenment, UNESCO. An der Duke University hat ein Pilotprojekt im Juni 2025 mehr als 4 Millionen unerwünschte HTTP-Anfragen pro Tag blockiert – etwa 90 % des Mülltraffics – und innerhalb einer Woche beschwerten sich 12 Personen über Probleme.
Diese Wände sind nicht aus Bosheit entstanden. Bei Read the Docs hat ein einziger Crawler 73 TB in einem Monat heruntergeladen; nach der Blockierung fiel der tägliche Traffic von 800 GB auf 200 GB, was eine Einsparung von etwa 1500 Dollar pro Monat bedeutet. Drew DeVault beschrieb, dass der Kampf gegen Crawler ihm zwischen 20 und 100 Prozent einzelner Wochen gekostet hat. Vor dem Hintergrund eines Anstiegs des automatisierten Traffics um 23,51 % im Jahr 2025 und einem fast dreifachen Anstieg des AI-Traffics innerhalb eines Jahres haben Administratoren begonnen, das zu nutzen, was schnell funktioniert.
Wendung: Gegen industrielles Parsen funktioniert PoW fast nicht
Und jetzt der unangenehme Teil, der selten in Pressemitteilungen erwähnt wird. Proof-of-Work basiert auf der Asymmetrie „günstig zu überprüfen, teuer zu lösen“. Im Web ist diese Asymmetrie nicht in die richtige Richtung ausgelegt.
Ein ehrlicher Besucher betrachtet Hashes als langsamen JavaScript im Browser. Derjenige, der Daten abgreift, sieht sie als nativen Code. Tavis Ormandy hat einen Solver in 25 Zeilen C geschrieben: Eine Aufgabe der Schwierigkeit 5 wird in etwa 0,017 Sekunden gelöst – das ist etwa 200 Mal schneller als das browserseitige SubtleCrypto. Auf der GPU ist der Unterschied noch größer, etwa hundertfach und mehr. Das Ergebnis der Arithmetik ist einfach: Für einen großen Anbieter kostet das Umgehen aller Anubis-Websites nahezu nichts.
Das ist keine Theorie. Codeberg berichtete bereits im August 2025, dass viele Scraper-Bots gelernt haben, die Herausforderungen von Anubis zu lösen. Die Wand ist dabei nicht nutzlos geworden – mehrere Monate hat sie die Mehrheit blockiert – aber als Barriere für diejenigen, die bereit sind, einen Abend in einen nativen Solver zu investieren, hält sie nicht stand.
Wie gewohnt zahlt der lebende Benutzer die Rechnung. Schwierigkeit 5 bedeutet etwa 2 Sekunden auf einem neuen MacBook, Dutzende Sekunden auf einem alten Laptop und bis zu zwei Minuten auf einem Telefon. Bei GitLab GNOME wurde ein Fall von einer halben Stunde Verzögerung in Firefox festgestellt – ein Ausreißer, aber aufschlussreich. Hinzu kommen strenge Ausnahmen: Standardmäßig erfordert Anubis JavaScript, weshalb RSS-Reader, curl, wget und Lynx einfach ausfallen. Das Projekt behebt dies – in Version 1.20.0 wurde ein Weg ohne JS über Meta-Refresh eingeführt – aber in 1.22.0 kam Proof of React, das im Gegenteil die Anforderungen an den Browser erhöhte.
Es ist auch wichtig, die Stabilität des Projekts zu beachten: Etwa die Hälfte des Codes wird von einer Person committet, und unter den 80+ Mitwirkenden hat nur ein anderer Entwickler mehr als ein Dutzend Commits. Außerdem ist in Anubis der kostenpflichtige Dienst Thoth für GeoIP- und BGP-Filterung integriert – das heißt, das Open-Source-Projekt hat einen kommerziellen Nachbarn.
Wo PoW wirklich beißt: Die kommerzielle Version funktioniert anders
Hier versteckt sich die Hauptverwirrung. Kasada, hCaptcha und Cloudflare Turnstile verwenden ebenfalls Proof-of-Work – aber ganz anders als Anubis.
Bei Anubis ist das Puzzle und ist die Wand: JS ausgeführt, Hash berechnet – bestanden. Ein Signal, eine Barriere. Bei kommerziellen Systemen funktioniert PoW als Zertifizierung. Bei Kasada dauert die Aufgabe ein paar Millisekunden – so wenig, dass sie als Barriere sinnlos ist. Der Sinn liegt woanders: Um sie zu lösen, muss der Client eine obfuskiertes virtuelle Maschine durchlaufen, innerhalb derer die echte Erkennung stattfindet. Berechnest du den Hash, ohne alles andere auszuführen, erhältst du nichts. hCaptcha legt PoW über das Urteil zu Bildern, wodurch die Rechenkosten für verdächtige Kunden erhöht werden, Turnstile betrachtet PoW als ein Signal unter vielen Umgebungsprüfungen.
Der Unterschied ist grundlegend. Die offene Wand wird von einem billigen nativen Solver gebrochen. Die kommerzielle wird nicht durch den Hash, sondern durch die Notwendigkeit, den obfuskierten Code eines anderen ehrlich auszuführen und sich nicht in der Umgebung zu verraten – und das ist teuer, weil die Obfuskation regelmäßig rotiert. CrowdSec 1.8 ist genau deshalb interessant, weil es diese Logik (Fingerprinting neben PoW) in die selbstgehostete Welt bringt, wo zuvor maximal eine Ratenbegrenzung pro IP galt.
Was das in der Praxis ändert
Wenn Sie Daten legal sammeln – Preise überwachen, Ihre Marke im Auge behalten, Forschung betreiben – sind die Schlussfolgerungen ziemlich konkret.
- Das Problem liegt nicht im Hash, sondern in der Browserschicht. Der Hash wird nativ in Millisekunden berechnet. Fingerprinting, obfuskiertes VM und korrektes Umfeld werden nicht berechnet. Praktische Verschiebung: Wo früher ein HTTP-Client ausreichte, wird jetzt eine echte Browser-Engine benötigt. Das ist teurer in Bezug auf CPU und Speicher, und man muss sofort darauf planen.
- Die Wirtschaft verlagert sich von Traffic auf Zeit und Prozessor. Früher wurde die Kosten in IP und Gigabyte berechnet. Jetzt kommen Sekunden pro Seite und Kernbelastung hinzu. Man muss nicht den Preis pro Gigabyte messen, sondern die Kosten für einen erfolgreichen Eintrag – bei einer PoW-Wand weichen diese beiden Metriken besonders stark voneinander ab.
- Die Sitzung wird zu einem Vermögenswert. Anubis gibt einen JWT-Cookie für eine bestimmte Zeit aus. Wenn Sie die IP nach jeder Anfrage ändern, zahlen Sie die PoW-Steuer erneut auf jeder Seite. Sticky Sessions auf residential Proxys bieten hier keinen Gewinn in „Anonymität“, sondern direkt in Berechnungen: Eine Lösung der Aufgabe amortisiert sich über Dutzende von Seiten. Aggressive Rotation wird in der PoW-Welt von einer guten Praxis zu einem Überverbrauch.
- Der Solver ersetzt nicht das Verhalten. Genau die gleiche Logik, nach der Solver von Captchas die Frage nicht mehr lösen: Sie lösen die sichtbare Aufgabe, aber das Urteil wird auf unsichtbaren Signalen um sie herum gefällt.
- Reduzieren Sie die Frequenz – das ist billiger als jede Wand. Die PoW-Welle entstand aus Geschichten wie 73 TB in einem Monat von einem Crawler. Cache, bedingte Anfragen, ein angemessener Intervall und Respekt vor robots.txt bringen Sie vom Radar, bevor die Herausforderung aktiviert wird. Günstige Rechenzentrumsadressen plus headless mit maximaler Frequenz – das ist genau das Profil, für das Wände aufgestellt werden.
Fazit
CrowdSec 1.8 ist nicht das „Ende des Scrapings“, und Anubis ist es auch nicht geworden: Ein nativer Solver schließt die Aufgabe der Schwierigkeit 5 in 0,017 Sekunden ab, während ein lebender Mensch auf einem alten Telefon bis zu zwei Minuten wartet. Die echte Neuigkeit liegt woanders. Erstens hat die Erkennung laut anerkannt, dass residente IPs und sauberes TLS nichts mehr beweisen. Zweitens ist die Schicht „beweise, dass du ein Browser bist“ keine Privilegie mehr für große Plattformen mit einem Budget für Kasada und ist in den Open-Source-Bereich übergegangen, der auf normalen Websites installiert wird.
Man sollte sich nicht auf einen Kampf mit Hashes vorbereiten, sondern darauf, dass das billige Schema „viele IPs plus schneller HTTP-Client“ bei immer kleineren Zielen ausfallen wird. Gewinnt die entgegengesetzte Konfiguration: weniger Anfragen, echter Browser, lange Sitzungen und qualitativ hochwertige Adressen, wo ein zuverlässiger Durchgang benötigt wird und nicht tausend billige Versuche.