Bot- und Missbrauchsverkehr zeigt sich meist nicht als plötzlicher Ausbruch, sondern als langsames, kontinuierliches Verhalten. Eine IP kann 30–50 Anfragen pro Minute stellen; das allein ist keine Katastrophe, doch wenn es 10 Minuten lang anhält, kann es sich in Scraping-, Automatisierungs- oder Passwort-Probing-Verhalten verwandeln. Ein sofortiges Rate-Limit erfasst den zeitlich gestreckten Charakter dieses Verhaltens nicht immer korrekt.
WAAP-Signaturen lösen eine andere Frage: Passt diese Anfrage zu einem bekannten Angriffsmuster? Schädliche Inhaltsmuster wie SQL Injection, XSS oder Command Injection können erkannt werden. Doch legitim wirkendes, aber verkehrsintensives Scraping, Preis-Tracking, Account-Probing oder aggressive API-Nutzung kann signaturbasiertem Schutz entgehen.
Zwischen diesen beiden Ansätzen ist ein Modell der temporären Isolation erforderlich. Wenn eine bestimmte Quelle in den letzten N Minuten ein schwellenwertüberschreitendes Verhalten gezeigt hat, sollte sie für M Minuten in Quarantäne genommen werden, ohne dauerhaft gesperrt zu werden. Während dieser Zeit kann ihr Verkehr blockiert, auf eine Erklärungsseite geleitet oder in einen anderen Flow umgeleitet werden. Nach Ablauf der Frist wird die Quelle automatisch wieder freigegeben.
Für dieses Modell sind zwei separate Mechanismen erforderlich: das Überwachungsfenster, das das Verhalten misst, und das Quarantänefenster, das die Isolation umsetzt. Die Überwachung kann kurz, die Quarantäne länger gehalten werden; oder je nach Anwendungssensibilität umgekehrt. Auch die Aktion sollte nicht einheitlich sein: Für manche Quellen ist ein stiller Block, für andere eine Erklärungsseite, für wieder andere eine Umleitung die richtige Wahl.
Die TR7 Traffic-Quarantäne liefert dieses Modell: zwei separate Zeitfenster für Überwachung und Quarantäne, vier Schlüsseltypen, drei Aktionsarten, die Verwendbarkeit des Quarantänestatus als Bedingung in anderen Regeln sowie Live-Sichtbarkeit und manuelles Eingreifen über den vService-Bildschirm.
Die TR7 Traffic-Quarantäne vereint Verhaltensüberwachung und temporäre Isolation in derselben Policy-Engine.
In jeder Quarantäneregel werden Überwachungsfenster und Quarantänefenster getrennt definiert. Das Überwachungsfenster misst das Verhalten der Quelle; das Quarantänefenster bestimmt, wie lange die Aktion nach Überschreiten des Schwellenwerts andauert.
Die Quelle muss nicht nur als IP definiert werden. Mit den Optionen IP, IP+User-Agent, Host+IP und Host+IP+User-Agent wird in Szenarien mit mehreren Domains, NAT und Mandantenfähigkeit eine genauere Unterscheidung erreicht.
Während der Quarantäne kann der Verkehr blockiert, auf eine andere URL umgeleitet oder mit einer benutzerdefinierten Inhaltsseite beantwortet werden. So lässt sich für Angreiferverkehr ein stiller Block, für echte Nutzer eine erläuternde Meldung und für den Geschäftsablauf eine passende Umleitung anwenden.
Eine in Quarantäne genommene Quelle wird zu einem systemweit nutzbaren Statussignal. Andere Verkehrs-, Umleitungs- und Inhaltsregeln können dieses Signal als Bedingung nutzen, um zusammengesetzte Policies zu bilden.
Die Traffic-Quarantäne vereint Verhaltensüberwachung, temporäre Isolation und Betreiberkontrolle in einem einzigen Arbeitsmodell.
In jeder Regel werden Überwachungsdauer und Quarantänedauer unabhängig eingestellt. Innerhalb des Überwachungsfensters wird das Verhalten der Quelle gezählt; bei Überschreiten des Schwellenwerts wird die Quelle für die Dauer des Quarantänefensters in einer separaten Liste geführt. Nach Ablauf der Frist verfällt der Eintrag automatisch. Diese Struktur bietet eine kontrollierte, befristete Isolation statt eines dauerhaften Banns.
Die Option `ip` bietet klassische quell-IP-basierte Überwachung. `ipUa` unterscheidet verschiedene User-Agents hinter derselben IP. `hostIp` zählt das Verhalten derselben IP gegenüber verschiedenen Hosts in Umgebungen mit mehreren Domains separat. `hostIpUa` schließlich bietet in mandanten- und mehrclientfähigen Umgebungen die granularste Unterscheidung.
Der Betreiber kann einen Schwellenwert für die Anzahl der Anfragen innerhalb eines bestimmten Zeitfensters definieren. Regeln wie „mehr als 100 Anfragen in den letzten 10 Minuten" lösen eine verhaltensbasierte Quarantäne aus. Die Entscheidung beruht nicht auf einer einzelnen Anfrage, sondern auf dem Gesamtverhalten innerhalb des Fensters. Anders als beim Rate-Limiting ist dieser Ansatz beobachtungsbasiert.
Die Aktion `block` wird verwendet, um den Verkehr der Quelle in Quarantäne stillschweigend zu verwerfen. Bei Bot- und Automatisierungsverkehr ist dieses Verhalten oft wirksamer; der Angreifer erhält keine klare Anwendungsantwort. Diese Aktion eignet sich für risikoreiche Missbrauchsszenarien, in denen keine Erläuterung angezeigt werden muss. Die Auswirkung auf echte Nutzer lässt sich über den vService-Monitor verfolgen.
`showContent` gibt der Quelle in Quarantäne einen benutzerdefinierten HTTP-Statuscode und Inhalt zurück. Beispielsweise kann eine Seite angezeigt werden, die erklärt, dass die Quelle wegen zu vieler Anfragen vorübergehend gedrosselt wird. Dieses Modell verhält sich in Szenarien mit möglichem False-Positive-Risiko oder hoher Bedeutung der Nutzererfahrung sanfter als ein Block. Der Inhalt der Meldung kann an Support- und Markensprache der Organisation angepasst werden.
`redirect` wird verwendet, um die Quelle in Quarantäne auf eine andere URL umzuleiten. Ziel können eine CAPTCHA-Seite, ein Erklärungsportal, eine Abo-Upgrade-Seite oder eine Supportseite sein. So wird die Quarantäne nicht nur zum Blockieren, sondern auch zu einem Mittel, den Nutzer in den richtigen Geschäftsablauf zu führen. In Mandanten- und SaaS-Szenarien ist diese Option besonders wertvoll.
Dass eine Quelle in Quarantäne ist, kann als Bedingung in anderen Regeln verwendet werden. Quellen in Quarantäne können an einen anderen Backend umgeleitet werden, einen speziellen Header erhalten, eine benutzerdefinierte Inhaltsantwort sehen oder in den Geltungsbereich einer zweiten, strengeren Regel fallen. Diese Eigenschaft verwandelt eine einzelne Quarantäneregel in ein Signal, das systemweit Verhaltensänderungen auslöst. Es ist einer der wichtigsten Differenzierungspunkte von TR7.
Die Traffic-Quarantäne kann sowohl für HTTP- als auch für TCP-Services verwendet werden. Auf der HTTP-Seite wird das Verhalten pro Anfrage überwacht, auf der TCP-Seite wird auf Verbindungsebene entschieden. Das technische Ergebnis der Aktion kann je nach Protokoll variieren; das Grundmodell bleibt jedoch gleich: überwachen, die Quelle, die den Schwellenwert überschreitet, temporär isolieren und nach Ablauf der Frist wieder freigeben.
Im Live-Überwachungsbildschirm des vService werden die aktiven Quellen in Quarantäne aufgelistet. Der Betreiber kann sehen, welcher Schlüssel aufgrund welcher Regel und für welche Dauer in Quarantäne ist. Bei einem False Positive oder einem priorisierten Nutzer kann eine manuelle Freigabe erfolgen. Da abgelaufene Einträge automatisch bereinigt werden, ist ein manuelles Eingreifen nicht zwingend erforderlich.
Unter demselben vService können mehrere Quarantäneregeln zusammenarbeiten. Beispielsweise zeigt die erste Regel bei zu vielen Anfragen eine Warnseite an, während die zweite Regel die weiterhin aktive Quelle länger blockiert. Pro vService werden 5 parallele Quarantäneregeln unterstützt. Diese Struktur ermöglicht eine von sanft bis streng fortschreitende Missbrauchskontrolle.
Die Traffic-Quarantäne wird operativ zusammen mit Tabellen-Lebenszyklus, Cluster-Verhalten, Reload-Auswirkung, Überwachungsbildschirm und Audit-Einträgen verwaltet.
Jede Quarantäneregel nutzt zwei separate Live-Überwachungsbereiche für Überwachung und Quarantäne. Einträge werden zeitlich vorgehalten und nach Ablauf der TTL automatisch bereinigt. Mit jeder neuen Anfrage wird das Verhalten im Überwachungsfenster aktualisiert. Diese Struktur hält die Quarantäne als befristete Verhaltenskontrolle und nicht als dauerhaften Bann.
Bei jeder Anfrage wird zuerst die Schlüsselformel berechnet, dann der Überwachungswert aktualisiert und die Quarantänebedingung bewertet. Ist die Quelle bereits in Quarantäne, wird die definierte Aktion angewendet. Ist die Quelle nicht in Quarantäne, läuft der normale Verkehrsfluss weiter. Die Entscheidung erfolgt mit geringen Kosten im Datenpfad.
In Setups mit zwei Knoten können Quarantänetabellen so ausgelegt werden, dass sie lokal oder synchron arbeiten. Ist die Synchronisation nicht aktiv, baut der neue aktive Knoten nach einem Failover den Quarantäneverlauf von Grund auf neu auf. Bei aktiver Synchronisation kann der Quarantänestatus nach einem Failover erhalten bleiben. Diese Wahl sollte je nach operativem Bedarf und Setup-Modell getroffen werden.
Quarantänetabellen werden im Speicher gehalten und verhalten sich nicht wie eine dauerhafte Blacklist. Nach einem Soft-Reload oder einem Tabellen-Reset kann der aktive Quarantänestatus gelöscht werden. Das ist ein akzeptables Verhalten, denn die Quarantäne ist ein Mechanismus zur temporären Isolation. Wird eine langfristige Sperrung benötigt, sollte sie zusammen mit IP-Reputation-Feeds verwendet werden.
Im vService-Monitor sind die aktiven Quarantäneeinträge sichtbar, und der Betreiber kann eine bestimmte Quelle aus der Quarantäne entlassen. Dieser Vorgang löscht den Tabelleneintrag; die nächste Anfrage wird im normalen Fluss bewertet. Das ermöglicht ein schnelles Eingreifen bei VIP-Nutzern, False Positives oder Supportanfragen.
Ereignisse der Aufnahme in die und der Entlassung aus der Quarantäne können in Audit-Einträge geschrieben werden. Ist SIEM-Log-Streaming aktiviert, können die Ereignisse an einen externen Collector gesendet werden. Welcher Schlüssel aufgrund welcher Regel mit welcher Aktion und für welche Dauer in Quarantäne genommen wurde, lässt sich nachträglich untersuchen.
Die Anzahl der aktiven Schlüssel und der Schlüsseltyp beeinflussen den Speicherverbrauch. IP-basierte Schlüssel sind schlanker, zusammengesetzte Schlüssel wie Host+IP+User-Agent verbrauchen mehr Platz. Da pro vService 5 parallele Quarantäneregeln unterstützt werden, sollte die Kapazitätsplanung anhand des Verkehrsprofils erfolgen.
Eine E-Commerce-Site kann preis-scrapende Quellen mit dem Schlüssel `ipUa` überwachen. Eine IP+User-Agent-Kombination, die 100 Anfragen in 5 Minuten überschreitet, wird für 30 Minuten blockiert; verschiedene echte Nutzer hinter derselben IP können als separate Schlüssel bewertet werden.
Ein Banking-Portal kann wiederholte Versuche am Login-Endpoint nach IP oder IP+User-Agent überwachen. Bei Überschreiten des Schwellenwerts wird die Quelle für 60 Minuten auf eine erläuternde Seite geleitet, und dem echten Nutzer wird der Grund der temporären Einschränkung angezeigt.
Eine SaaS-Plattform mit mehreren Domains kann den Verkehr jedes Mandanten mit dem Schlüssel `hostIp` separat überwachen. Die aggressive Nutzung eines Mandanten kann einer Redirect- oder temporären Block-Aktion unterzogen werden, ohne den Verkehr anderer Mandanten zu beeinträchtigen.
Die erste Regel leitet eine Quelle, die zu viele Anfragen stellt, für 10 Minuten auf eine Warnseite. Erzeugt die Quelle während der Quarantäne weiterhin Verkehr, greift die zweite Regel und wendet einen 60-minütigen Block an. Dass der Quarantänestatus als Bedingung in anderen Regeln dient, macht dieses gestufte Modell möglich.
Verhaltensbasierte temporäre Isolation, zusammengesetzte Regelstruktur und Live-Betreibersichtbarkeit. Lassen Sie uns gemeinsam ansehen, wie es in Ihrer eigenen Umgebung funktioniert.