Ratenkontrolle gegen Credential-Stuffing und Brute-Force

Der Angriff, der wie normaler Verkehr aussieht

Credential-Stuffing ist der unauffälligste Angriff, den ein Login-Formular kennt. Kein Exploit, keine Injektion — nur Millionen echter Benutzername-Passwort-Paare aus früheren Leaks, geduldig gegen Ihre Anmeldung durchprobiert. Jede einzelne Anfrage sieht legitim aus, weil sie es technisch ist: ein wohlgeformter POST an den richtigen Endpunkt. Erst in der Masse und im Muster wird der Angriff sichtbar. Genau deshalb ist Ratenkontrolle hier keine Randfunktion, sondern die eigentliche Verteidigung.

Und genau deshalb ist sie schwer richtig zu bauen: Zu grob, und Sie sperren an einem Montagmorgen die halbe Belegschaft aus, die sich gleichzeitig einloggt. Zu lax, und die Stuffing-Farm läuft ungebremst durch.

Warum eine einzelne Zählregel nicht reicht

„100 Anfragen pro Minute pro IP“ klingt nach einer Lösung und ist keine. Angreifer verteilen sich heute über tausende Wohn-IP-Adressen; jede einzelne bleibt unter jeder plausiblen Schwelle, während die Summe Ihren Login flutet. Umgekehrt sitzen legitime Nutzer hinter geteilten NATs, Firmen-Gateways und Mobilfunk-Carrier-IPs — eine harte IP-Schwelle bestraft sie für die Netzarchitektur ihres Anbieters.

Tragfähige Ratenkontrolle zählt deshalb auf mehreren Dimensionen zugleich: pro Mandant, pro Route und pro Quelle — und sie unterscheidet den Endpunkt. Ein Login verträgt ein anderes Budget als eine öffentliche Produktseite, und ein Passwort-Reset ein noch strengeres. Diese Trennung ist kein Detail; sie ist der Unterschied zwischen „Angriff gebremst“ und „eigene Nutzer verärgert“.

Schnell zählen, ohne die Anfrage zu verlangsamen

Ratenkontrolle darf keine Latenz kosten, sonst wird der Schutz selbst zum Engpass. An der Edge läuft die Zählung deshalb in einer festen Reihenfolge: erst ein Shared-Memory-Zähler direkt im Worker — im Nanosekundenbereich, ohne Netzwerk —, dann ein verteilter Zähler dahinter, der die Sicht über mehrere Knoten hinweg zusammenführt. Die Anwendung selbst wird nie befragt, um eine Rate zu prüfen; sie erfährt vom Angriff gar nicht erst. Diese Filterung bleibt in unserem Design-Budget von ≤5 ms — wie wir das messen, steht in der Latenz-Methodik.

Brute-Force: dieselbe Mechanik, engeres Budget

Klassisches Brute-Force — dasselbe Konto, viele Passwörter — ist die konzentrierte Variante desselben Problems. Hier greift die Ratenkontrolle enger und kombiniert sich mit der Challenge-Leiter: Wiederholte Fehlversuche gegen ein Konto lösen erst einen Proof-of-Work aus, der einen Browser kaum bremst, ein Skript aber spürbar verteuert, und bei anhaltendem Verdacht ein CAPTCHA. Der legitime Nutzer, der sich zweimal vertippt, bemerkt davon nichts; die Farm, die zehntausend Versuche pro Minute fährt, läuft in eine Wand aus wachsenden Kosten. Wie diese Stufen aufeinander aufbauen, steht im Beitrag zur Challenge-Leiter.

Belegbar statt nur wirksam

Für einen deutschen Betreiber endet die Anforderung nicht beim Blocken. Jede Drossel- und Challenge-Entscheidung landet in einem unveränderlichen, nur-anfügenden Audit-Log: welche Quelle, welche Route, welche Schwelle überschritten, welche Stufe ausgelöst. Wenn nach einem Vorfall die Frage kommt, ob personenbezogene Zugangsdaten kompromittiert wurden, ist dieser Log der belastbare Zeitstrahl. Die gesamte Verarbeitung bleibt auf EU-Edge-Nodes (Hetzner, OVH, Scaleway) — Datensouveränität und DSGVO-Konformität als Architekturvorgabe, nicht als nachträglicher Schalter.

Ehrlich über die Grenzen

Ratenkontrolle stoppt den Missbrauch Ihres Logins; sie ersetzt keine starke Passwort-Policy und keine Zwei-Faktor-Authentifizierung. Wenn ein einziges korrektes Credential-Paar durchkommt, weil das Passwort tatsächlich stimmt, hat die Firewall ihren Job getan — der Rest liegt bei Ihrer Anmeldelogik. Was wir liefern, ist die ökonomische Umkehrung: Massen-Durchprobieren wird teuer genug, dass es sich gegen Ihre Domain nicht mehr lohnt.

Wenn Ihr Login gerade sturmreif geschossen wird, hilft unsere Seite Under Attack sofort — ansonsten nennen Sie uns Ihre Domain.

Sehen Sie es auf Ihrer eigenen Domain

Wir binden frühe Partner persönlich an. Nennen Sie uns Ihre Domain — den Rest übernehmen wir.

Für Early Access bewerben