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.
TR7 wendet DDoS-Entscheidungen durch Zähler-Sammlung, kombinierte Bedingungen, erlernte Basislinien und ein abgestuftes Aktionsmodell an.
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.
`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.
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.
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.
Adaptives DDoS-Lernen kombiniert pro-Service-Traffic-Signale mit erlerntem Verhalten, um präziseren L4/L7-Schutz zu liefern.
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.
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.
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 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.
`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.
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.
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.
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-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.
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.
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.
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.
Adaptiver DDoS-Schutz wird zusammen mit Schwellenwerten, Bedingungs-Komposition, Aktionsauswahl, Whitelist-Regeln, Bot-Score und Challenge-Verhalten betrieben.
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.
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.
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.
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.
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.
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.
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.
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.
Ö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.
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.
Durchlaufen Sie Basislinie-Lernen, kombinierte Bedingungen und das abgestufte Aktionsmodell auf Ihren eigenen Diensten.