Wie erkennt LiveShield einen DDoS-Angriff?

LiveShield erkennt einen DDoS-Angriff, indem es in Echtzeit konkrete Verkehrsschwellenwerte berechnet, nämlich Pakete pro Sekunde und Bandbreite, und zwar getrennt für jedes analysierte Protokoll, getrennt für einzelne IP-Adressen und getrennt für ganze Subnetze. Es handelt sich nicht um einen undurchsichtigen „Blackbox“-Mechanismus, der allgemein als „künstliche Intelligenz“ beschrieben wird, sondern um einen Satz offen konfigurierbarer Parameter, die der Betreiber einstellt und auf die Eigenschaften seines eigenen Netzes abstimmt.

Diese Unterscheidung hat praktische, nicht nur marketingbezogene Bedeutung: Ein Betreiber, der genau weiß, was das System misst und anhand welcher Kriterien es entscheidet, kann sein Verhalten vorhersagen, es auf das eigene Netz abstimmen und nachvollziehen, warum eine bestimmte Regel ausgelöst wurde. Bei einem System, das nur mit dem Schlagwort „KI“ beschrieben wird, ist das nicht möglich.

Das System berechnet Schwellenwerte getrennt für jedes von mehr als einem Dutzend analysierter Protokolle und Verkehrstypen, darunter: gesamter IP-Verkehr, TCP, UDP, TCP-SYN-Verkehr (Verbindungsaufbau), ICMP, IP-Fragmentierung (IPFRAG), kleine UDP-Pakete (SMALL_UDP) sowie typische Amplification-Vektoren, die bei Angriffen über DNS, NTP, SSDP, CHARGEN, SNMP, CLDAP oder Memcached genutzt werden. Für ein einzelnes Präfix hält das System den vollständigen Satz dieser Schwellenwerte sowohl auf Ebene der einzelnen IP-Adresse als auch auf Ebene des gesamten Subnetzes vor.

Die Trennung der Schwellenwerte pro Protokoll wirkt sich unmittelbar auf die Präzision der Reaktion aus: Statt einer allgemeinen Regel „zu viel Verkehr zu dieser Adresse“ erkennt das System, dass gerade der Schwellenwert für UDP-Amplification-Verkehr oder für IP-Fragmente überschritten wurde, und reagiert mit einer Regel, die auf den konkreten Angriffsvektor zugeschnitten ist, statt den gesamten Verkehr zu dieser Adresse zu blockieren.

LiveShield analysiert den Verkehr gleichzeitig auf Ebene einzelner IP-Adressen und ganzer Subnetze, weil ein Angriff auf eine einzelne Adresse und ein auf viele Adressen gleichzeitig verteilter Angriff (Carpet Bombing) unterschiedliche Erkennungsansätze erfordern.

Die Erkennung pro IP funktioniert bei einem klassischen Angriff auf ein einzelnes Ziel: Der Schwellenwert wird auf einer Adresse deutlich überschritten, und die Regel kann bis auf eine einzelne Adresse (Maske /32) heruntergehen. Ein auf viele Adressen gleichzeitig verteilter Angriff ist dagegen per Definition darauf ausgelegt, die pro IP berechneten Schwellenwerte zu umgehen: Jede einzelne Adresse erhält ein relativ kleines Verkehrsvolumen, das nicht ausreicht, um den Schwellenwert zu überschreiten, obwohl die Summe des Verkehrs auf das gesamte Subnetz bereits ein Angriff ist. Deshalb müssen die Schwellenwerte pro Subnetz separat und unabhängig von den Schwellenwerten pro IP konfiguriert werden. Das eine ersetzt das andere nicht.

Erkennt das System ein Muster, das auf einen auf viele Adressen verteilten Angriff hindeutet, werden ausschließlich die Regeln pro Subnetz ausgelöst, und das System sucht automatisch die größtmögliche Maske, die die angegriffenen Adressen möglichst präzise abdeckt. Der Mechanismus versucht zunächst die engstmögliche Maske (z. B. /32). Funktioniert das nicht, wie es bei echtem Carpet Bombing typisch ist, bei dem der Angriff tatsächlich viele verschiedene Adressen umfasst, erweitert das System die Regel schrittweise, z. B. auf /29, /28 bis hin zum gesamten angegriffenen Subnetz, je nachdem, wie breit die angegriffenen Adressen gestreut sind.

Dieser Mechanismus dient zugleich als Schutz vor einer Überlastung des Erkennungssystems selbst: Ohne Aggregation zu breiteren Regeln müsste ein Angriff auf Hunderte oder Tausende Adressen gleichzeitig ebenso viele separate /32-Regeln erzeugen, was sowohl das System als auch die Regeltabellen auf den Edge-Routern belasten würde.

LiveShield bietet für einzelne Protokolle zwei Filtermodi: Prefiltering, das sich ausschließlich auf die Überschreitung eines Verkehrsschwellenwerts (Pakete pro Sekunde und/oder Bandbreite) stützt, ohne zusätzliche Analyse des Paketinhalts, sowie Advanced Filtering, das zusätzlich detailliertere Verkehrsmerkmale wie Zielports oder TCP-Flags analysiert, um eine engere, auf den konkreten Angriff zugeschnittene Regel zu erzeugen.

Die Wahl zwischen diesen Modi ist ein Kompromiss zwischen Präzision und Risiko: Prefiltering reagiert schneller und einfacher, kann bei unvorsichtig gewählten Schwellenwerten aber auch einen Teil des legitimen Verkehrs mit ähnlichen Merkmalen abschneiden. Advanced Filtering erlaubt eine genauere Eingrenzung der Regel, setzt aber voraus, dass die zusätzlichen Kriterien (z. B. ein bestimmter Port) tatsächlich zum Charakter des Verkehrs auf dem jeweiligen Adresstyp passen. In der Praxis bedeutet das, dass für verschiedene Adressgruppen im Netz (z. B. normale Kunden gegenüber Servern, die auf vielen Ports lauschen) unterschiedliche Filterprofile gewählt werden statt einer universellen Regel für das gesamte Netz.

Es gibt keinen universellen Satz von Schwellenwerten, der für jedes Netz passt, denn der Charakter des normalen Verkehrs unterscheidet sich deutlich zwischen verschiedenen Segmenten derselben Infrastruktur: Typisch ist anderer Verkehr auf Adresspools hinter NAT, anderer auf Adressen, die Kunden direkt zugewiesen sind, und wieder anderer auf Serveradressen, die von Natur aus großen, vielfältigen Verkehr von vielen Quellen gleichzeitig empfangen.

Deshalb umfasst die Einführung von LiveShield in der Praxis eine Phase der Beobachtung des Produktivverkehrs und der iterativen Abstimmung der Schwellenwerte auf das konkrete Netz, statt einer einmaligen Konfiguration, die als endgültig gilt. Das betrifft sowohl die Schwellenwerte pro Protokoll als auch den Schwellenwert für die Eskalation von FlowSpec zu RTBH (basierend auf dem Prozentsatz des Verkehrs, den das System herausfiltern konnte). Die Konfiguration steht dem Betreiber vollständig zur Verfügung und kann mit zunehmenden Daten aus dem realen Verkehr geändert werden, ohne Eingriff des Anbieters.

Die Angriffserkennung in LiveShield beruht auf einem offenen, konfigurierbaren Satz von Verkehrsschwellenwerten, die getrennt für jedes von mehr als einem Dutzend Protokollen und Angriffsvektoren berechnet werden, gleichzeitig auf Ebene einzelner IP-Adressen und ganzer Subnetze. Auf viele Adressen verteilte Angriffe werden durch einen separaten Aggregationsmechanismus erkannt, der automatisch die engste wirksame Subnetzmaske wählt, und den Detaillierungsgrad der Filterung (Prefiltering oder Advanced Filtering) wählt der Betreiber individuell passend zum Verkehrscharakter im jeweiligen Netzsegment. Genau diese Transparenz und Konfigurierbarkeit, nicht das allgemeine Schlagwort „künstliche Intelligenz“, sorgt in der Praxis für die Wirksamkeit und Vorhersagbarkeit des Systems.

Wie erkennt LiveShield einen Carpet-Bombing-Angriff? Deutet das Verkehrsmuster auf einen gleichzeitig auf viele Adressen verteilten Angriff hin, werden die Regeln pro Subnetz ausgelöst, und das System wählt automatisch die engstmögliche Subnetzmaske, die die angegriffenen Adressen abdeckt, und erweitert sie schrittweise, wenn eine engere Maske nicht ausreicht.

Worin unterscheidet sich Prefiltering von Advanced Filtering? Prefiltering reagiert ausschließlich auf die Überschreitung eines Verkehrsschwellenwerts, ohne zusätzliche Paketmerkmale zu analysieren. Advanced Filtering analysiert zusätzlich Details wie Zielport oder TCP-Flags, um eine engere, präzisere Filterregel zu erzeugen.

Müssen die Erkennungsschwellenwerte nach der Einführung manuell abgestimmt werden? Ja. Der Charakter des normalen Verkehrs unterscheidet sich zwischen Netzsegmenten (z. B. Adressen hinter NAT, Kundenadressen, Serveradressen), weshalb die Einführung eine Phase der Beobachtung und iterativen Abstimmung der Schwellenwerte auf die konkrete Infrastruktur umfasst.