Rate-Limiting-Umgehungstechniken und Gegenmaßnahmen

1. Warum reines IP-basiertes Rate-Limiting an seine Grenzen stößt

Rate-Limiting zählt zu den ersten Maßnahmen, die Entwickler gegen Brute-Force-Angriffe, Scraping und API-Missbrauch einsetzen. Die klassische Umsetzung begrenzt die Anzahl Anfragen pro IP-Adresse und Zeitfenster, etwa hundert Requests pro Minute. Das funktioniert gut gegen einzelne, unkoordinierte Skripte, die naiv von einer einzigen Adresse aus senden, stößt aber schnell an Grenzen, sobald ein Angreifer über mehr als eine IP-Adresse verfügt oder gezielt versucht, die Zählung zu umgehen.

Das eigentliche Problem liegt in der Annahme, eine IP-Adresse entspreche zuverlässig einem einzelnen Nutzer oder Angreifer. In der Praxis teilen sich oft hunderte legitime Nutzer eine IP-Adresse hinter einem Firmen-NAT oder Mobilfunk-Gateway, während ein einzelner Angreifer über Cloud-Provider, Proxy-Netzwerke oder kompromittierte Endgeräte binnen Sekunden Dutzende neu Adressen erhalten kann. Ein wirksames Rate-Limiting-Konzept muss deshalb von Anfang an einplanen, dass IP-Adressen ein unzuverlässiges Identifikationsmerkmal sind, und zusätzliche Signale heranziehen.

2. IP-Rotation: Residentielle Proxys und Cloud-IP-Pools als Umgehungstechnik

Die einfachste Umgehungstechnik ist die IP-Rotation. Angreifer mieten bei kommerziellen Proxy-Anbietern Zugriff auf Pools mit tausenden residentiellen IP-Adressen, die von echten Heimanschlüssen stammen und deshalb kaum von normalem Nutzerverkehr zu unterscheiden sind. Jede Anfrage oder jede kleine Gruppe von Anfragen läuft über eine andere Adresse, sodass das klassische Zähler-Limit pro IP niemals erreicht wird, obwohl der Gesamtverkehr auf ein einzelnes Ziel gerichtet ist.

Cloud-Provider bieten eine günstigere, wenn auch leichter erkennbare Variante: Autoscaling-Gruppen mit rotierenden öffentlichen IP-Adressen aus bekannten Rechenzentrums-Bereichen. Diese lassen sich über IP-Reputationsdatenbanken und ASN-Listen leichter blockieren als residentielle Proxys, weil Rechenzentrums-IP-Bereiche öffentlich dokumentiert sind. Wer eingehenden Verkehr nach Herkunfts-ASN filtert und Rechenzentrums-Bereiche für sensible Endpunkte strenger begrenzt, entzieht dieser günstigeren Variante viel von ihrer Wirkung.

3. X-Forwarded-For und Co.: Wie Angreifer Identifikations-Header manipulieren

Viele Anwendungen ermitteln die Client-IP nicht aus der TCP-Verbindung selbst, sondern aus HTTP-Headern wie X-Forwarded-For oder X-Real-IP, weil sie hinter einem Load Balancer oder Reverse Proxy stehen. Diese Header werden vom Client gesetzt und lassen sich beliebig fälschen, solange die Anwendung nicht exakt konfiguriert, welchem vorgelagerten Proxy sie vertrauen darf. Ein Angreifer, der bei jeder Anfrage einen zufälligen Wert in X-Forwarded-For einträgt, erscheint der Anwendung gegenüber jedes Mal als neu IP-Adresse.

Die Gegenmaßnahme ist eine strikte Trust-Boundary: Nur der unmittelbar vorgelagerte, bekannte Reverse Proxy sollte den X-Forwarded-For-Header setzen dürfen, und die Anwendung darf ihn nur aus dieser einen vertrauenswürdigen Quelle übernehmen. Bei nginx als Einstiegspunkt lässt sich das über set_real_ip_from in Kombination mit real_ip_header sauber konfigurieren, sodass vom Client mitgesendete, gefälschte Header verworfen werden und nur der vom Proxy selbst ermittelte Wert zählt.

# nginx.conf: Nur echten vorgelagerten Proxys vertrauen
set_real_ip_from 10.0.0.0/8;      # internes Load-Balancer-Netz
set_real_ip_from 173.245.48.0/20; # z.B. CDN-Provider-Bereich
real_ip_header    X-Forwarded-For;
real_ip_recursive on;

# Erst NACH der real_ip-Konfiguration ist $binary_remote_addr vertrauenswürdig
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=60r/m;

server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

4. Verteilte Botnetze: Wenn Tausende Quellen einen Angriff koordinieren

Die konsequenteste Form der IP-Rotation sind Botnetze aus kompromittierten IoT-Geräten, gehackten Servern oder infizierten Endnutzer-PCs. Ein einzelnes Botnetz kann problemlos aus mehreren zehntausend Geräten bestehen, sodass selbst ein sehr niedriges Limit pro IP in Summe eine enorme Angriffslast erzeugt, ohne dass eine einzelne Quelle auffällig wird. Login-Formulare sind ein beliebtes Ziel, weil Credential-Stuffing-Angriffe genau von dieser Verteilung profitieren: Jede IP probiert nur wenige Kombinationen, das Gesamtsystem testet dennoch Millionen gestohlener Zugangsdaten durch.

Gegen echte Botnetze hilft reines Rate-Limiting allein nicht mehr, weil die Verteilung genau darauf ausgelegt ist, jedes Einzel-Limit zu unterlaufen. Wirksam sind globale Aggregations-Metriken, etwa die Gesamtzahl fehlgeschlagener Logins über alle Quellen hinweg pro betroffenem Nutzerkonto, kombiniert mit Verhaltenssignalen wie fehlenden browsertypischen Headern, ungewöhnlichen User-Agent-Mustern oder dem Fehlen von JavaScript-Ausführung, die ein Headless-Skript von einem echten Browser unterscheiden.

5. Slow-Rate-Angriffe: Unter der Erkennungsschwelle bleiben

Neben der Verteilung über viele Quellen nutzen erfahrene Angreifer auch die zeitliche Dimension aus. Statt einen Endpunkt in kurzer Zeit aggressiv anzugreifen, verteilen sie Anfragen über Stunden oder Tage und bleiben dabei bewusst unterhalb jeder Schwelle, die typische Rate-Limiting-Regeln auslösen würde. Ein Angreifer, der pro IP nur eine Anfrage alle zwei Minuten sendet, unterläuft praktisch jedes Standard-Limit, selbst wenn er dafür deutlich länger für denselben Gesamterfolg braucht.

Auch die Diversifizierung über mehrere Endpunkte gehört zu dieser Kategorie: Statt ausschließlich den Login-Endpunkt anzugreifen, verteilt sich der Verkehr zusätzlich auf Passwort-Reset, Registrierung oder API-Suchfunktionen, die jeweils eigene, oft großzügigere Limits besitzen. Ein zentrales Monitoring, das Anfragen pro Nutzerkonto oder Zielressource über mehrere Endpunkte hinweg aggregiert, deckt diese Muster deutlich zuverlässiger auf als isolierte Einzel-Limits.

6. Nutzerkonto statt IP: Robustere Identifikationsstrategien

Der wirksamste Hebel gegen IP-basierte Umgehung ist der Wechsel der primären Identifikationsebene. Statt ausschließlich nach IP-Adresse zu zählen, sollte ein Limit zusätzlich am Zielobjekt ansetzen, etwa dem Nutzerkonto, das angegriffen wird. Fünf fehlgeschlagene Login-Versuche für denselben Benutzernamen innerhalb von zehn Minuten lösen eine Sperre oder ein CAPTCHA aus, unabhängig davon, wie viele unterschiedliche IP-Adressen dahinterstecken, weil das eigentlich schützenswerte Gut das Konto ist, nicht die Netzwerkadresse.

Diese Strategie hat eigene Fallstricke: Wer ausschließlich auf Kontosperrung nach fehlgeschlagenen Versuchen setzt, öffnet die Tür für Denial-of-Service-Angriffe gegen einzelne Konten, bei denen ein Angreifer den Benutzernamen eines Opfers absichtlich mit Falscheingaben sperrt. Deshalb kombinieren robuste Implementierungen kontobezogene Limits mit progressiven Verzögerungen statt harten Sperren, etwa wachsenden Wartezeiten zwischen Versuchen, sowie zusätzlichen IP-basierten Limits als zweite, unabhängige Verteidigungslinie.

7. Mehrschichtiges Rate-Limiting: Edge, Anwendung und Endpunkt kombinieren

Die robusteste Architektur kombiniert mehrere Rate-Limiting-Ebenen, die unterschiedliche Angriffsmuster abdecken. Auf Edge-Ebene, etwa in einem CDN oder einer WAF, greifen grobe, aber sehr performante Limits gegen offensichtliche Massenangriffe, ohne dass jede Anfrage bis zur Anwendung durchdringen muss. Auf Anwendungsebene folgen feinere, kontextabhängige Limits, die Nutzerkonto, Session oder API-Schlüssel berücksichtigen und damit gezielter reagieren können als die grobe Edge-Filterung.

Endpunkt-spezifische Limits bilden die dritte Ebene: Ein Login-Formular verträgt naturgemäß ein deutlich strengeres Limit als eine öffentliche Produktsuche, und ein kostenintensiver API-Endpunkt, der eine Datenbankaggregation auslöst, braucht ein enger gefasstes Budget als ein einfacher, gecachter Lesezugriff. Erst das Zusammenspiel aller drei Ebenen macht es für Angreifer unwirtschaftlich, eine einzelne Ebene gezielt zu umgehen.

8. Adaptive Verfahren: Sliding Window, Token Bucket und Verhaltensanalyse

Feste Zeitfenster-Zähler, sogenannte Fixed-Window-Limits, haben einen bekannten Schwachpunkt an der Fenstergrenze: Ein Angreifer kann kurz vor Ablauf eines Minutenfensters das volle Limit ausschöpfen und direkt danach erneut, wodurch in Summe doppelt so viele Anfragen in kurzer Zeit möglich sind wie beabsichtigt. Sliding-Window-Algorithmen vermeiden dieses Problem, indem sie das Zeitfenster kontinuierlich mitgleiten lassen, statt an starren Grenzen zurückzusetzen.

Token-Bucket-Verfahren gehen noch einen Schritt weiter und erlauben kontrollierte Bursts, während sie die durchschnittliche Rate über Zeit strikt begrenzen. Ergänzend lohnt sich eine verhaltensbasierte Komponente, die Anomalien jenseits reiner Zählwerte erkennt, etwa untypische Zeitabstände zwischen Anfragen, fehlende Mausbewegungen bei formularbasierten Angriffen oder Anfragemuster, die exakt maschinell getaktet statt menschlich unregelmäßig wirken.

9. Monitoring, Alerting und die Grenzen jeder Rate-Limiting-Strategie

Kein Rate-Limiting-System ist vollständig und dauerhaft umgehungssicher, weil sich Angreifer laufend an neu Maßnahmen anpassen. Entscheidend ist deshalb kontinuierliches Monitoring, das ungewöhnliche Muster sichtbar macht, etwa einen plötzlichen Anstieg fehlgeschlagener Logins über viele verschiedene IP-Adressen hinweg, auch wenn jede einzelne Adresse unauffällig bleibt. Dashboards, die Anfragen pro Nutzerkonto statt nur pro IP visualisieren, decken koordinierte Angriffe oft früher auf als reine IP-Statistiken.

Alerting-Schwellen sollten so gesetzt sein, dass ungewöhnliche Häufungen automatisch Aufmerksamkeit erzeugen, bevor ein Angriff wirtschaftlichen Schaden anrichtet. Wichtig ist auch die regelmäßige Überprüfung, ob eingesetzte Limits noch zum aktuellen Bedrohungsbild passen: Ein Limit, das vor zwei Jahren gegen einfache Skript-Angriffe ausreichte, kann gegen professionell organisierte, verteilte Angriffe längst wirkungslos geworden sein.

10. Zusammenfassung

11. FAQ: Rate-Limiting-Umgehung: Das Wichtigste auf einen Blick