Statische DDoS-Schwellenwerte können den realen Traffic nicht verstehen — sie können einen Kampagnen-Spike und einen Angriff identisch behandeln.
Der häufigste Fehler beim traditionellen DDoS-Schutz ist die Anwendung desselben festen Schwellenwerts auf jeden Service. Eine einfache Regel wie "Blockieren über 100 Anfragen pro Sekunde" reagiert für einen Niedrig-Traffic-Service möglicherweise zu langsam und erzeugt bei einer E-Commerce-Site während einer Kampagne falsche Blockierungen. Jede Anwendung hat ihr eigenes normales Traffic-Volumen, ihre eigene Pfadverteilung, ihr eigenes Client-Profil und ihr eigenes Verbindungsverhalten.
L7-DDoS-Angriffe kommen nicht immer mit hoher Paketanzahl oder hoher Anfragerate. Slowloris-ähnliche Angriffe — niedrige Rate, aber viele offene Verbindungen — sowie SSL-Verbindungs-Floods, steigende Fehlerraten, Bot-Verhalten und auf bestimmten Endpoints konzentrierte Last können alle die klassische Rate-Limit-Logik überwinden. Entscheidungen aus einem einzelnen Zähler zu treffen ist daher nicht ausreichend.
Ein weiteres Problem ist, dass Schutzaktionen oft einheitlich sind. Wenn jede verdächtige Anfrage sofort verworfen wird, werden legitime Benutzer beeinträchtigt; wenn in jedem Fall ein CAPTCHA angezeigt wird, verschlechtert sich die Benutzererfahrung. Stilles Verwerfen ist in einigen Szenarien korrekt, Redirect in anderen, eine Informationsseite in wieder anderen, und ein selbst gehostetes CAPTCHA in anderen.
Der richtige Ansatz ist, pro-Service-Traffic-Verhalten zu erlernen, L4- und L7-Signale gemeinsam auszuwerten und die Aktion basierend auf Bedingungen zu wählen. Whitelist-Regeln, Pfadverhalten, Verbindungsanzahl, Anfragerate, Bot-Score und IP-Reputation sollten alle in derselben Entscheidungspipeline beteiligt sein.
TR7 Adaptives DDoS-Lernen liefert dieses Modell: Es überwacht den Service-Traffic, konvertiert erlerntes Verhalten in Richtlinienempfehlungen und wendet mit Operator-Genehmigung kontrollierte Schutzaktionen an.
Unser Ansatz
TR7 wendet DDoS-Entscheidungen durch Zähler-Sammlung, kombinierte Bedingungen, erlernte Basislinien und ein abgestuftes Aktionsmodell an.
Stick-Table-Monitoring sammelt L4- und L7-Zähler
TR7 verfolgt Verbindungs-, Anfrage-, Fehler- und SSL-Verhalten mit globalen und pro-Tracking-Schlüssel-Zählern. Diese Werte bilden die Kernsignale für pro-Service-DDoS-Bedingungen.
Kombinierte Bedingungen werten den Traffic-Kontext statt eines einzelnen Zählers aus
`ddosCond` lässt mehrere ACL-Bedingungen mit AND-, OR- und NOT-Logik kombinieren. Entscheidungen können daher nicht nur auf der Anfragerate, sondern auch auf SSL-Verbindungsanzahl, Fehlerrate, Bot-Score, IP-Reputation oder Pfadverhalten basieren.
Smart Learning hilft dabei, das normale Traffic-Profil zu ermitteln
Service-, Pfad- und Anfrageverhalten werden aus historischem Traffic und Log-Daten analysiert. Erlernte Werte werden dem Operator als Empfehlungen präsentiert und werden nach Genehmigung zu einer durchsetzbaren Richtlinie.
Ein abgestuftes Aktionsmodell reagiert proportional auf den Angriff
TR7 unterstützt Deny-, Redirect-, showContent- und showCaptcha-Aktionen. Je nach Service-Sensibilität kann der Operator stilles Verwerfen, Redirect, eine benutzerdefinierte Antwortseite oder ein selbst gehostetes CAPTCHA wählen.
Fähigkeiten
Adaptives DDoS-Lernen kombiniert pro-Service-Traffic-Signale mit erlerntem Verhalten, um präziseren L4/L7-Schutz zu liefern.
Ein globales DDoS-Flag erzeugt ein gemeinsames Zustandssignal über alle Dienste hinweg
TR7 verwendet ein Flag-Modell, das den DDoS-Status auf globaler Ebene markieren kann. Wenn ein Service oder eine Tracking-Bedingung einen Angriffszustand auslöst, können diese Informationen als Signal in anderen Schutzentscheidungen verwendet werden. DDoS wird daher als Teil des systemweiten Verhaltens behandelt, nicht nur als isoliertes Anfrageereignis. Betriebsteams erhalten während eines Vorfalls eine klarere Sicht auf den allgemeinen Schutzmodus.
Ein pro-Anfrage-DDoS-Flag wendet Aktionen nur auf den relevanten Flow an
Neben dem globalen Signal ist auch ein pro-Anfrage-DDoS-Flag verfügbar. Ob eine Anfrage von einer DDoS-Bedingung erfasst wurde, kann auf Transaktionsebene bestimmt werden. Die Aktion wird daher nur auf den relevanten Flow angewendet — es ist nicht notwendig, den gesamten Traffic unnötig in denselben Bucket einzuordnen. Feinkörniges Verhalten reduziert das Risiko falsch positiver Ergebnisse.
Mehrere Tracking-Schlüssel überwachen L4- und L7-Signale gemeinsam
TR7 kann verschiedene Schlüssel wie HTTP-Anfragerate, HTTP-Fehlerrate, Verbindungsrate, aktive Verbindungsanzahl und SSL-Verbindungsanzahl verfolgen. L7-Verhalten ist für HTTP-Dienste prominent; verbindungsbasierte Signale führen bei TCP-Diensten. Diese Unterscheidung ermöglicht die Auswahl des richtigen DDoS-Indikators für jeden Service-Typ, sodass Entscheidungen auf dem passenden Signal-Set und nicht auf einem einzelnen Zähler basieren.
Ein dynamisches Tracking-Fenster passt das Angriffserken nungsintervall pro Service an
Ein kürzeres Tracking-Fenster erfasst schnelle Angriffsbursts schneller; ein längeres Fenster macht langsames, anhaltendes Verhalten sichtbar. TR7 macht diese Dauer pro Service-Bedarf konfigurierbar. Kurze Standard-Fenster eignen sich für einen schnellen Start, aber die Produktionsrichtlinie sollte dem Service-Profil entsprechend geformt werden. Diese Flexibilität hilft, plötzliche Kampagnen-Traffic-Spikes von langsamem DDoS-Verhalten zu unterscheiden.
Whitelist-Bedingungen schließen vertrauenswürdige Traffic-Quellen von Schutzaktionen aus
`ddosWhitelistCond` kann bestimmte IPs, ASNs, Pfade oder vertrauenswürdige Traffic-Quellen von DDoS-Aktionen befreien. Dies ist besonders wichtig für Suchmaschinen-Bots, Unternehmensintegrationen, Monitoring-Systeme oder Partner-API-Traffic. Die Whitelist muss keine statische Liste sein; sie kann mit Bedingungslogik für feinere Kontrolle geschrieben werden. Geschäftskritische Flows bleiben auch dann zugänglich, wenn der Schutz aggressiver wird.
Vier Aktionstypen liefern differenzierte Reaktionen basierend auf der Angriffsschwere
TR7 unterstützt Deny-, Redirect-, showContent- und showCaptcha-Aktionen. Deny ist der aggressivste stille Drop-Ansatz; Redirect verschiebt Traffic an einen anderen Ort; showContent gibt eine benutzerdefinierte Seite mit einem bestimmten Status-Code zurück; showCaptcha initiiert die Benutzerverifizierung. Diese Vielfalt bedeutet, dass nicht jeder Angriff mit demselben Kraftniveau begegnet wird. Der Operator wählt die richtige Reaktion basierend auf Service-Wert und Falsch-Positiv-Risiko.
Mehrsprachige Challenge-Seiten bewahren die Benutzererfahrung
TR7 kann mehrsprachige Verifizierungsseiten in DDoS-Challenge-Szenarien bereitstellen. Diese Seiten präsentieren den Kontrollfluss für Benutzer ohne Abhängigkeit von einem externen Drittanbieter-Dienst. Der selbst gehostete Challenge-Ansatz ist in Sektoren mit Datenschutz- und Compliance-Sensibilität ein Vorteil. Anstatt einfach einen Fehler anzuzeigen, erhalten Benutzer eine kontrollierte Verifizierungserfahrung.
Smart Learning erzeugt Basislinie-Empfehlungen aus Pfad- und Service-Verhalten
TR7 kann aus historischen Log- und Traffic-Daten ein pro-Service-Normalprofil ableiten. Erwarteter Traffic pro Pfad, typische Fehlerrate oder Lastverhalten können dem Operator als Empfehlungen präsentiert werden. Der Operator prüft und genehmigt diese, um sie in DDoS-Bedingungen umzuwandeln. Dieser Ansatz erleichtert es, Richtlinien aus beobachtetem realen Traffic zu erstellen, anstatt Schwellenwerte blind zu schreiben.
Bot-Score liefert ein zusätzliches Risikosignal in der DDoS-Entscheidungspipeline
Bot-Schutz-Scores können als Hilfssignale in DDoS-Entscheidungen verwendet werden. Faktoren wie Rechenzentrumsip, Tor-Exit, schlechte IP-Reputation, User-Agent-Analyse, Header-Fingerabdruck und TLS-Fingerabdruck können alle den Risiko-Score beeinflussen. Wenn der Bot-Score einen konfigurierten Schwellenwert überschreitet, können Deny-, Redirect- oder Captcha-Aktionen ausgelöst werden. DDoS-Schutz schaut daher nicht nur auf Volumen, sondern auch auf Client-Qualität.
IP-Reputationskategorien trennen verdächtige Quellen schneller
TR7 kann 13 IP-Reputationskategorien als Entscheidungssignale verwenden: offener Proxy, schlechter Bot, Brute Force, Webanwendungsangriff, SQL injection, Hacking, DDoS-Angriff, ausgebeuteter Host, Port-Scan, Web-Spam, E-Mail-Spam, Blog-Spam und VPN-IP. Diese Kategorien müssen für sich allein nicht definitiv sein — sie tragen innerhalb einer kombinierten Bedingung zusätzliches Risikogewicht bei. Bekannte schlechte Quellen werden daher schneller vom normalen Benutzer-Traffic getrennt, was die Schutzrichtlinie kontextbewusster macht.
L4- und L7-Lernempfehlungen werden mit Operator-Genehmigung angewendet
TR7 kann pro-Service-Empfehlungen aus Signalen wie Verbindungsrate, aktiven Verbindungen, Anfragerate, Fehlerrate und Pfadverhalten ableiten. Diese Empfehlungen werden vom Operator geprüft, anstatt blind angewendet zu werden. Genehmigte Werte werden in DDoS-Bedingungen und Aktionsrichtlinien umgewandelt. Dieses Modell hält die Automatisierung unter Kontrolle — Lernen, menschliche Genehmigung und durchsetzbare Richtlinie arbeiten zusammen.
DDoS-Modus kann für die Incident Response manuell ausgelöst werden
Das Betriebsteam kann den DDoS-Status auch während eines Angriffs manuell aktivieren. Dies ist nützlich, um schnelle Schutzmaßnahmen zu ergreifen, ohne auf das automatische Lernen oder das Auslösen von Bedingungen warten zu müssen. Der manuelle Modus bietet eine temporäre Verteidigungsschicht besonders während des Incident-Response-Prozesses. Nach dem Vorfall identifizierte Bedingungen können in permanente Richtlinien formalisiert werden.
Operative Tiefe
Adaptiver DDoS-Schutz wird zusammen mit Schwellenwerten, Bedingungs-Komposition, Aktionsauswahl, Whitelist-Regeln, Bot-Score und Challenge-Verhalten betrieben.
Bot-Schutz-Schwellenwert
Wenn der Bot-Schutz-Score einen konfigurierten Schwellenwert erreicht, können Aktionen wie Deny, Redirect oder CAPTCHA ausgelöst werden. Dieser Schwellenwert muss sorgfältig basierend auf der Service-Sensibilität angewendet werden. Ihn zusammen mit Anfrageverhalten und Whitelist-Bedingungen auszuwerten — anstatt sich allein auf den Bot-Score zu verlassen — liefert zuverlässigere Ergebnisse.
Globale Tracking-Tabelle
Das globale DDoS-Tracking-Modell kann einen Zähler für den Single-System-Zustand pflegen. Diese Struktur hilft, den systemweiten Angriffszustand neben pro-Service-Bedingungen zu verstehen. Während eines Vorfalls überwachen Betriebsteams nicht nur eine einzelne Anfrage, sondern auch das aggregierte Verhaltens-Signal.
Aktions-Selektor-Verhalten
Wenn das DDoS-Flag aktiv ist, wird die ausgewählte Schutzaktion angewendet. Deny bietet stilles Verwerfen; Redirect führt Weiterleitung durch; showContent serviert benutzerdefinierten Inhalt; showCaptcha initiiert den Challenge-Fluss. Die Aktionsauswahl sollte entsprechend Service-Wert, Benutzererfahrung und Angriffsschwere getroffen werden.
Anpassbarer Inhalt
Bei der showContent-Aktion sind Status-Code, Content-Type und Inhaltsprofil alle anpassbar. Dies ermöglicht es, Benutzern die eigene Botschaft der Organisation anstelle eines generischen Fehlers anzuzeigen. Die Funktion ist wertvoll für Wartungsfenster, Vorfall-Kommunikation und Compliance-Messaging.
Selbst gehostetes CAPTCHA
Die showCaptcha-Aktion kann TR7s eigenes CAPTCHA-Modul aufrufen, wodurch die Abhängigkeit von einem externen Drittanbieter-Verifizierungsdienst reduziert wird. Dieser Ansatz liefert einen kontrollierteren Verifizierungsfluss für Organisationen mit Datenschutz- und regulatorischer Sensibilität.
Kombinierte Bedingungsstruktur
Mehrere Signale können innerhalb von `ddosCond` mit AND-, OR- und NOT-Logik kombiniert werden. Beispielsweise kann eine hohe Anfragerate zusammen mit einer spezifischen Pfadkonzentration und einer IP-Reputationskategorie ausgewertet werden, anstatt isoliert. Dies reduziert falsch positive Ergebnisse und ermöglicht gleichzeitig gezieltere Aktionen.
Wann es eingesetzt wird
E-Commerce-Traffic während Kampagnenzeiträumen schützen
E-Commerce-Teams können pro-Service-DDoS-Bedingungen verwenden, um einen Traffic-Anstieg während einer Kampagne von einem echten Angriff zu trennen. Vertrauenswürdige Crawler oder Partnerquellen werden auf die Whitelist gesetzt, während anomales Pfad- und Anfrageverhalten auf Schutzaktionen abgebildet wird.
L7-Angriffe auf Banking-Login-Endpoints abschwächen
Banking-Anwendungen können gemeinsam HTTP-Anfragerate, SSL-Verbindungsanzahl und Fehlerrate bei Login-Traffic überwachen. Wenn Schwellenwerte überschritten werden, werden Redirect-, CAPTCHA- oder Deny-Aktionen gemäß Service-Richtlinie angewendet.
Selbst gehostete Challenge-Nutzung bei Behördenportalen
Öffentliche Portale können ihre eigenen TR7-Challenge-Seiten verwenden, ohne Daten an einen externen Verifizierungsdienst zu senden. Mehrsprachiger Inhalt hält den Benutzer-Verifizierungsfluss unter institutioneller Kontrolle.
Slowloris-ähnliche Low-Rate-Angriffe erkennen
Angriffe, die trotz niedriger Anfragerate eine hohe Anzahl offener Verbindungen erzeugen, können durch Verbindungsanzahl- und Dauerverhalten überwacht werden. TR7 macht verbindungserschöpfende langsame Angriffsmuster sichtbar — nicht nur hochvolumige PPS-Floods.
Häufig gestellte Fragen
Warum reichen statische Rate-Limit-Regeln allein nicht aus?
Wie funktioniert ddosCond und welche Signale kann es kombinieren?
Was empfiehlt Smart Learning und welche Rolle hat der Operator?
Welche DDoS-Aktionen werden unterstützt und wann sollte jede bevorzugt werden?
Warum ist selbst gehostetes CAPTCHA wichtig?
Wie funktionieren Whitelist-Bedingungen?
Pro-Service-DDoS-Schutz in Aktion erleben
Durchlaufen Sie Basislinie-Lernen, kombinierte Bedingungen und das abgestufte Aktionsmodell auf Ihren eigenen Diensten.