Reagiert LiveShield innerhalb von 1 Sekunde auf einen DDoS-Angriff?

LiveShield erkennt einen DDoS-Angriff und rollt die erste Filterregel praktisch sofort aus: In einem kontrollierten Test mit einem Live-Angriff erkannte das System die Bedrohung und installierte die erste Regel in derselben Sekunde, in der der Angriff startete. Das ist das Ergebnis einer Architektur, die auf einer Echtzeit-Verkehrsanalyse im Arbeitsspeicher beruht, ohne Datenbank auf dem kritischen Erkennungspfad.

Beim DDoS-Schutz wirkt sich die Zeit unmittelbar auf die Folgen eines Angriffs aus: Je länger Erkennung und Aktivierung der Filterung dauern, desto länger erreicht der Angriffsverkehr die Infrastruktur des Kunden und belastet Leitungen, Router und Edge-Geräte. Deshalb stützen wir uns nicht allein auf die Aussage „wir reagieren blitzschnell“, sondern zeigen einen realen Test an einem vergleichbaren Angriff, der parallel mit einer anderen, verbreiteten Marktlösung durchgeführt wurde.

Am 21. November wurde ein Test mit einem Live-Angriff mit den Parametern 700 kpps / 6,5 Gb/s durchgeführt, der sich aus drei gleichzeitigen Vektoren zusammensetzte: IP-Fragmentierung (IP Fragments), DNS-Amplification und UDP-Flood. Der Verkehr wurde parallel von LiveShield und von einer anderen, in der Branche weit verbreiteten Anti-DDoS-Lösung analysiert, auf derselben Infrastruktur und im selben Moment des Angriffs. So ließ sich die Reaktionszeit beider Systeme auf identischen Verkehr direkt vergleichen.

Der Test umfasste bewusst einen Multivektor-Angriff und keinen einzelnen, einfachen Flood. In der Praxis beschränken sich DDoS-Angriffe selten auf eine Verkehrsart, daher liefert die Prüfung, wie ein System mit mehreren sich überlagernden Mustern gleichzeitig zurechtkommt, ein glaubwürdigeres Bild.

LiveShield erkannte den Angriff und rollte die erste Filterregel (für DNS-Verkehr) in derselben Sekunde aus. Die verglichene Lösung erkannte den Angriff mit 4 Sekunden Verzögerung gegenüber LiveShield, und ihre erste Filterregel (ebenfalls für DNS-Verkehr) wurde mit 18 Sekunden Verzögerung gegenüber dem Zeitpunkt ausgerollt, zu dem LiveShield diesen Verkehr bereits filterte.

Beim zweiten Angriffsvektor (IP-Fragmentierung) betrug der Unterschied 8 Sekunden zugunsten von LiveShield. Den dritten Vektor (UDP auf einen bestimmten Zielport) behandelte LiveShield mit einer weiteren, separaten Regel. Die verglichene Lösung hat diese Regel, obwohl sie für dieses Verkehrsmuster konfiguriert war, während des Tests überhaupt nicht ausgerollt.

Einige Dutzend Sekunden Unterschied beim Ausrollen der ersten Filterregel mögen wie ein kleiner Spielraum wirken, doch bei einem Angriff im Bereich mehrerer Gigabit pro Sekunde sind das einige Dutzend bis einige Hundert Gigabyte Verkehr, die in dieser Zeit ungehindert die Infrastruktur des Kunden erreichen, statt am Netzrand herausgefiltert zu werden. Für Geräte mit begrenzten Ressourcen, etwa BRAS oder Edge-Router der unteren Klasse, entscheiden gerade diese ersten Sekunden des Angriffs darüber, ob das Gerät überlastet wird, bevor der Schutz tatsächlich greift.

Noch wichtiger ist der Fall der dritten Regel aus dem Test: eine Situation, in der ein System eine Regel korrekt konfiguriert hat, sie aber dennoch während eines realen Angriffs nicht ausrollt. Das zeigt, dass die bloße angegebene Funktionalität (das System „unterstützt“ einen bestimmten Angriffstyp) nicht dasselbe ist wie die bestätigte, praktische Funktion unter Last bei Live-Verkehr.

Der Unterschied in der Reaktionszeit ergibt sich unmittelbar aus der Architektur der Datenverarbeitung. LiveShield analysiert den Verkehr Paket für Paket im Arbeitsspeicher, und die Kommunikation zwischen dem Analysemodul und dem Modul, das die Regeln erzeugt, läuft über ein dediziertes, schnelles, TCP-basiertes Protokoll, das speziell auf minimale Latenz ausgelegt ist. Die meisten für die Erkennungszeit kritischen Operationen laufen nicht über die Datenbank. Sie dient der Speicherung historischer Daten und Statistiken, nicht der Entscheidungsfindung über die laufende Filterung.

Lösungen, die die Logik von Erkennung und Filterung stärker auf Datenbankabfragen stützen, führen naturgemäß in jeder Phase zusätzliche Verzögerung ein, von der Erkennung der Anomalie über die Klassifizierung bis zur Erzeugung und zum Versand der Regel. Bei einem einzelnen Angriff mag ein Unterschied von einigen bis einigen Dutzend Sekunden gering erscheinen, doch er wächst mit der Größe und der Zahl gleichzeitiger Vorfälle im Netz.

In einem kontrollierten Test mit einem Multivektor-Angriff mit den Parametern 700 kpps / 6,5 Gb/s (IP Fragments, DNS-Amplification, UDP-Flood) erkannte LiveShield den Angriff und rollte die erste Filterregel in derselben Sekunde aus, in der der Angriff startete. Bei den weiteren Angriffsvektoren war es der verglichenen Marktlösung um einige bis einige Dutzend Sekunden voraus, und eine der Regeln rollte das konkurrierende System trotz korrekter Konfiguration überhaupt nicht aus. Das ist das Ergebnis einer Architektur, die auf Verkehrsanalyse im Arbeitsspeicher und einer auf minimale Reaktionszeit ausgelegten Kommunikation zwischen den Modulen beruht, und nicht bloß eine behauptete Geschwindigkeit.

Wie schnell erkennt LiveShield einen DDoS-Angriff? In Tests mit Live-Verkehr erkannte LiveShield den Angriff und rollte die erste Filterregel in derselben Sekunde aus, in der der Angriff begann, dank Echtzeit-Verkehrsanalyse im Arbeitsspeicher, ohne Datenbank auf dem kritischen Erkennungspfad.

Welche Parameter hatte der im Vergleichstest verwendete Angriff? Der Test wurde mit einem Angriff der Intensität 700 kpps und 6,5 Gb/s durchgeführt, bestehend aus drei gleichzeitigen Vektoren: IP-Fragmentierung, DNS-Amplification und UDP-Flood.

Reagieren alle Anti-DDoS-Systeme in ähnlicher Zeit? Nein. Im durchgeführten Test erkannte die verglichene Marktlösung denselben Angriff mit einer Verzögerung von einigen Sekunden gegenüber LiveShield und rollte eine der konfigurierten Filterregeln während des Angriffs überhaupt nicht aus.