Eine IP zu begrenzen reicht nicht mehr aus, um modernen Missbrauch zu stoppen.
Traditionelles Rate Limiting wird üblicherweise als Anfragenzählung pro IP-Adresse angewendet. Dieses Modell ist einfach, aber NAT, Carrier-Netzwerke, gemeinsame Egress-Punkte und anonyme Gateways können legitime Benutzer und Missbrauchsquellen in denselben Bucket einordnen. Hoher Traffic von einer einzelnen IP ist nicht immer ein Angriff; gleichermaßen ist verteilter Traffic mit geringem Volumen nicht immer unschuldig.
Anwendungsverhalten ist nicht einheitlich. Ein kurzer Ausbruch von Asset-Anfragen während eines Seitenladens ist normal, aber dieselbe Rate auf einem Zahlungs-, Login- oder API-Endpoint kann auf Missbrauch hinweisen. Ein flaches "N Anfragen pro Minute"-Modell kann sowohl die Benutzererfahrung beeinträchtigen als auch echte Angriffe übersehen.
Credential Stuffing, Kontoaufzählung und Bot-Muster können nicht allein aus rohen Anfragenzählungen gelesen werden. Eine große Anzahl fehlgeschlagener Login-Versuche auf einem Authentifizierungs-Endpoint mag im Gesamttraffic niedrig erscheinen. Zähler, die nicht mit Benutzername, Sitzung, API-Key, benutzerdefiniertem Header oder Antwortverhalten korreliert werden, verlieren ihren Sicherheitskontext.
Ressourcenschutz ist ein separates Anliegen. Selbst wenn verteilte Clients Anfragen mit einer niedrigen pro-Client-Rate senden, kann die aggregierte Last einen Connection-Pool, eine Suchinfrastruktur oder eine Datei-Download-Kapazität eines Backends erschöpfen. Rate Limiting wird nicht nur benötigt, um einen Angreifer zu stoppen, sondern um Backend-Kapazität fair und kontrolliert zu verteilen.
TR7s Ansatz hebt Rate Limiting von einem stumpfen IP-basierten Schwellenwert zu einer kontrollierten Sicherheitsrichtlinie, die über Benutzer-, Endpoint-, Sitzungs-, API-Key-, Composite-Key- und Bandbreitendimensionen angewendet werden kann.
Unser Ansatz
TR7 implementiert Rate Limiting als mehrdimensionale WAAP-Kontrolle, die um Scope, Counter-Modell und Aktionsauswahl herum konzipiert ist, die zusammenarbeiten.
Sliding-Window-Modell verfolgt echtes Traffic-Verhalten
TR7 verfolgt Anfrage-, Verbindungs-, Fehler- und Bandbreitenraten innerhalb eines konfigurierbaren Zeitfensters. Verschiedene Fensterlängen ermöglichen die unabhängige Auswertung von kurzlebigen Spitzen und anhaltender hoher Last.
Der Limit-Key wird auf die Angriffsklasse abgestimmt
Verschiedene Scopes können mit IP, IP und User-Agent, Benutzername, API-Key, Cookie, Header oder Composite-Keys erstellt werden. Dies ermöglicht präziseres Erfassen von Missbrauch ohne legitime Benutzer hinter derselben IP zu bestrafen.
Das Aktionsmodell wird progressiv nach Schwere angewendet
Eine Richtlinie kann die Anfrage verweigern, eine temporäre Blockierung anwenden, zur CAPTCHA-Verifikation weiterleiten oder eine Bandbreitenkappe auferlegen. Nicht jeder Verstoß wird mit demselben Antwortniveau behandelt.
In-Process-Counter-Architektur hält die Latenz niedrig
Zähler werden innerhalb des Datenpfades gepflegt — zur Entscheidungszeit ist kein externer Datenbankaufruf erforderlich. Multi-Instance-Deployments werden durch Counter-Synchronisierung unterstützt, was eine konsistente Richtliniendurchsetzung in verteilten Setups ermöglicht.
Fähigkeiten
TR7 Rate Limiting deckt verschiedene Missbrauchsszenarien ab — von vorgefertigten Bot-Richtlinien bis zu benutzerdefinierten Composite-Keys — durch ein einziges Verwaltungsmodell.
Integrierte Rate-Limiting-Profile bieten einen produktionsbereiten Ausgangspunkt
TR7 wird mit vorgefertigten Richtlinien für gängige Bot- und Missbrauchsszenarien geliefert. Das `bot_rateLimit`-Profil kann HTTP 429 bei 300 Anfragen pro Minute pro IP zurückgeben. `bot_rateLimitStrict` kann nach 100 Anfragen pro Minute eine 5-minütige temporäre Blockierung anwenden. `bot_rateLimitCaptcha` kann nach 150 Anfragen pro Minute zu einem selbst gehosteten CAPTCHA-Fluss weiterleiten.
Ein weiches Limit und eine harte Obergrenze — die Reaktion ist ein Anstieg, keine Klippe
Jede Schutzfunktion hat zwei Schwellen. Das Überschreiten des weichen Limits löst eine abgestufte Reaktion aus — verzögern, prüfen, drosseln — und erst die harte Obergrenze verwirft Verkehr. Der Monitor-Modus berichtet beide getrennt, sodass Schwellen aus dem entstehen, was Ihr Verkehr tatsächlich getan hat, statt aus einer geschätzten Zahl. Eine einzige Schwelle erzwingt jedes Mal dieselbe Wahl: den Angriff durchlassen oder die eigenen Kunden mit ihm verwerfen.
Trigger-Typen trennen einfache Anfragen, fehlgeschlagene Logins und Risiko-Score
Der `requests`-Typ verfolgt die rohe Anfragerate. `failedAuthAttempts` behandelt fehlgeschlagene Authentifizierungsversuche mit einem dedizierten Zähler. `riskScore` kann Entscheidungen basierend auf einem Bot- oder Verhaltens-Score treffen. `static` wird für bedingungslose Kontrollen verwendet, wie z.B. obligatorisches CAPTCHA auf einem bestimmten Ablauf.
IP-, Benutzer- und Composite-Key-Scopes können zusammen verwendet werden
Der `global`-Scope überwacht die aggregierte Last über einen gesamten Service. Die `ip`-, `ip+ua`-, `username`- und `composite`-Scopes erstellen gezieltere Limits. Die Composite-Struktur kann einen benutzerdefinierten Header, Cookie, API-Key oder ein Feld aus dem Request-Body kombinieren, um einen benutzerdefinierten Counter-Key zu erzeugen. Diese Flexibilität ermöglicht es B2B-API- und Multi-Tenant-Anwendungen, echte Nutzungslimits genauer widerzuspiegeln.
Dieselbe Anfrage kann gleichzeitig gegen mehrere Rate-Richtlinien bewertet werden
Ein Service-Pool kann mehrere Rate-Limiting-Richtlinien gleichzeitig aktiv haben. Beispielsweise kann dieselbe Anfrage sowohl einer IP-bezogenen DDoS-Kappe als auch einem benutzerbezogenen Fair-Use-Limit unterliegen. Jede Richtlinie verfolgt ihren eigenen unabhängigen Zähler. Diese Struktur ermöglicht ein mehrschichtiges Schutzmodell anstelle eines einzelnen Schwellenwerts.
Die temporäre Block-Aktion hält den Key blockiert, auch nachdem die Rate sinkt
Wenn die `block`-Aktion ausgelöst wird, wird der betroffene Key für die konfigurierte Dauer in der Block-Tabelle gehalten. Dies verhindert, dass ein Angreifer einen kurzen Ausbruch erzeugt und dann nach dem Verlangsamen sofort zurückkehrt. Die `blockDuration` wird pro Richtlinie festgelegt. Dieses Modell bietet stärkere Kontrolle gegen intensive Bot-Wellen und wiederkehrende Missbrauchsquellen.
Selbst gehostetes CAPTCHA leitet verdächtigen Traffic zur Verifikation statt zu einer harten Blockierung
Die `captcha`-Aktion kann Traffic, der den Schwellenwert überschritten hat oder als riskant eingestuft wird, zu einem Verifikationsfluss weiterleiten, anstatt ihn vollständig abzuschneiden. Der Standardanbieter ist `tr7Standard`. Bei erfolgreicher Verifikation wird die Anfrage des Benutzers fortgesetzt. Dieser Ansatz bietet eine ausgewogenere Alternative zur Blockierung in Szenarien, in denen das Trennen echter Benutzer von Automatisierung die Priorität ist.
Die Bandwidth-Limit-Rule ermöglicht bedingtes Traffic-Shaping
TR7 kann neben Anfragenzählungen auch eingehende und ausgehende Bandbreitenraten verfolgen. Mit der `bwLimit`-Aktion kann Traffic, der einer bestimmten Bedingung entspricht, unter eine eigene Bandbreitenkappe gestellt werden. Dies ist nützlich für Datei-Download-Endpoints, Endpoints, die große Antworten erzeugen, oder hohen Datenverbrauch aus einer einzigen Quelle — das Backend verfügbar halten ohne es vollständig abzuschneiden.
AAM-Sitzungsvariablen ermöglichen per-Benutzer Rate Limiting
Informationen wie der Benutzername aus einer AAM-Sitzung können als Rate-Limiting-Key verwendet werden. Dies ermöglicht es, jedem Benutzer nach dem Login ein separates Fair-Use-Limit zuzuweisen. Kostenlose und kostenpflichtige Pläne, interne und externe Benutzergruppen oder verschiedene Rollenebenen können jeweils durch unterschiedliche Limits gesteuert werden. Dies bietet präzisere Kontrolle in API- und Portal-Szenarien, in denen IP-basierte Limits nicht ausreichen.
Operative Tiefe
Damit Rate-Limiting-Richtlinien wirksam sind, müssen Counter-Laufzeit, Tabellengröße, Cluster-Synchronisierung, Observability und Rollback-Verhalten alle mit operativer Klarheit verwaltet werden.
Adaptive Counter-Tabellengröße
Verschiedene Scopes arbeiten mit unterschiedlichen Tabellengrößen. Der globale Scope verwendet einen einzigen Key, während IP- und Composite-Scopes eine viel größere Anzahl von Einträgen halten können. Lange Keys wie IP kombiniert mit User-Agent können mehr Speicher verbrauchen, daher sollte die Scope-Auswahl gegen das erwartete Traffic-Profil getroffen werden.
Multi-Instance-Synchronisierung
Counter-Synchronisierung über Instanzen hinweg wird in Cluster-Deployments unterstützt. Instanzen, die denselben Richtlinien-Key teilen, können sich gegenseitig entdecken und Counter-Zustand austauschen. Dies macht es einem Angreifer schwerer, ein Limit zu umgehen, indem er in einer lastverteilten Umgebung zwischen Instanzen wechselt.
Counter-Kontinuität über Reloads hinweg
Stabiles Tabellen-Naming, das an die Richtlinienidentität gebunden ist, hilft, den Counter-Zustand über Reload-Zyklen hinweg zu bewahren. Wenn dieselbe Richtlinie unter demselben Namen fortgesetzt wird, werden Zähler nicht unnötigerweise zurückgesetzt. Dies reduziert das Risiko, dass während Wartungs- oder Konfigurationsaktualisierungen eine Sicherheitslücke entsteht.
Richtlinienvalidierungsschicht
Rate-Limiting-Richtlinien werden vor dem Deployen durch Schema-Validierung geprüft. Ungültige Scope-, Trigger-Typ- oder Aktionsdefinitionen können nicht in die Produktionskonfiguration eintreten. Diese Prüfung reduziert das Risiko, dass eine fehlkonfigurierte Sicherheitsregel den Live-Traffic stört.
Aktionsketten-Kompatibilität
Bot-Richtlinie, Konto-Lockout-Regeln und WAAP-Entscheidungen können alle gleichzeitig auf derselben Anfrage ausgeführt werden. Prioritätsreihenfolge und Match-Verhalten werden durch Konfiguration gesteuert. Rate Limiting arbeitet daher nicht isoliert, sondern als Teil der breiteren WAAP-Entscheidungspipeline.
Audit und Observability
Bei jedem Trigger können Regel-ID, Aktion, Key und Rateninformationen protokolliert werden. Diese Datensätze können für Vorfall-Analyse und Berichterstellung an ein SIEM weitergeleitet werden. Betriebsteams können die am häufigsten ausgelösten Keys, die verkehrsreichsten Endpoints und Blockierungstrends im Laufe der Zeit überwachen.
Anwendungsszenarien
Mehrschichtige per-Benutzer- und per-IP-Limits auf einem API-Gateway
Organisationen, die B2B-APIs anbieten, können gleichzeitig ein per-Benutzer-Plan-Limit und eine per-IP-Missbrauchskappe durchsetzen. TR7 führt eine benutzerbezogene Fair-Use-Richtlinie und eine IP-bezogene harte Kappe parallel aus.
Fehlversuch-Kontrolle auf einem Login-Endpoint
Eine hohe Anzahl fehlgeschlagener Zugangsdaten-Eingaben auf einem Authentifizierungsbildschirm kann ein Brute-Force-Indikator sein. TR7 kann Fehler mit einem kombinierten Benutzername- und IP-Key verfolgen und eskalierte Aktionen anwenden — zunächst CAPTCHA, dann eine temporäre Sperre.
Per-Endpoint-Schutz in einem E-Commerce-Ablauf
Ein kurzer Ausbruch von Anfragen auf Produktseiten kann normal sein, aber dasselbe Muster auf einem Zahlungsendpoint ist ein Risiko. TR7 kann Endpoint-Bedingungen und verschiedene Zeitfenster verwenden, um Checkout-Missbrauch zu begrenzen, ohne die Seiten-Lade-Erfahrung zu beeinträchtigen.
Bandbreitenkontrolle bei Datei-Download-Traffic
Eine einzelne Quelle kann durch Hochvolumen-Downloads die I/O-Kapazität eines Backends erschöpfen. TR7 verwendet die Bandwidth-Limit-Rule, um diesen Traffic bedingt zu deckeln und den Service für andere Benutzer verfügbar zu halten.
Häufig gestellte Fragen
Beeinflusst ein per-IP Rate Limit echte Benutzer hinter NAT oder gemeinsamem Egress?
Was ist der Unterschied zwischen der block-Aktion und der deny-Aktion?
Wie funktioniert die selbst gehostete CAPTCHA-Integration?
Kann mehr als eine Rate-Richtlinie auf denselben Endpoint angewendet werden?
Arbeitet die Bandwidth-Limit-Rule anders als Anfragenzählung?
Können verschiedene Instanzen in einem Cluster denselben Zähler teilen?
Rate Limiting auf den Kontext Ihrer Anwendung zuschneiden
Mehrschichtige Rate-Richtlinie über IP-, Benutzer-, API-Key- und Bandbreitendimensionen. Lassen Sie uns einen Live-Setup auf Ihren eigenen Services durchführen.