FlowSpec vs. RTBH: Wie LiveShield Nebenwirkungen bei der Mitigation minimiert

RTBH (Remotely Triggered Black Hole) blockiert den gesamten Verkehr, der an eine bestimmte IP-Adresse gerichtet ist, einschließlich des legitimen Verkehrs. Das ist der grundlegende Unterschied zu FlowSpec, das ausschließlich Pakete filtert, die zu einer konkreten Angriffssignatur passen. LiveShield minimiert diese Nebenwirkung, indem es FlowSpec priorisiert und RTBH erst als Notfallmechanismus auslöst, wenn die präzise Filterung nicht mehr ausreicht, und nicht als erste und einzige Reaktion auf jeden Angriff.

Diese Unterscheidung wirkt sich unmittelbar auf die Servicequalität während eines Angriffs aus: Eine falsch konfigurierte Mitigation kann dem Kunden mehr Schaden zufügen als der Angriff selbst, indem sie ihm den Zugang zu genau dem Dienst abschneidet, den sie schützen sollte.

FlowSpec erlaubt es, eine Filterregel anhand konkreter Verkehrsmerkmale zu definieren, etwa Zieladresse, Protokoll, Quell- oder Zielport, TCP-Flags oder Paketgröße, und sie direkt im Hardware-Forwarding-Path des Edge-Routers zu installieren. Der Router verwirft ausschließlich Pakete, die zu dieser Signatur passen, und der gesamte übrige Verkehr zu dieser Adresse läuft ungestört weiter.

RTBH funktioniert völlig anders: Es kündigt die gesamte Route zu einer IP-Adresse (meist /32) als Blackhole an, sodass der Router alles verwirft, was an diese Adresse gerichtet ist, also Angriffsverkehr, aber auch legitimen Verkehr zur selben Adresse. Es gibt keine Selektion auf Paketebene, sondern eine vollständige Abschaltung des Ziels.

Daraus ergibt sich eine einfache Regel: Wo sich FlowSpec einsetzen lässt, leidet der übrige Verkehr des Kunden nicht. RTBH ist die letzte Lösung, die dann greift, wenn FlowSpec nicht mehr ausreicht, und kein standardmäßiger erster Schritt.

Filterregeln (FlowSpec) und Blackholing-Regeln (RTBH) werden unabhängig voneinander auf Basis separat konfigurierter Schwellenwerte für dasselbe Präfix geprüft. Wird der Schwellenwert der Filterregel zuerst überschritten, aktiviert das System FlowSpec. Gleichzeitig und parallel wird der Blackholing-Schwellenwert geprüft, und solange der Verkehr ihn nicht überschreitet, wird RTBH nicht ausgelöst.

In der Praxis bedeutet das: Sind die Blackholing-Schwellenwerte höher als die Filter-Schwellenwerte, was die empfohlene Konfiguration ist, übernimmt FlowSpec die Mitigation als Erstes, und RTBH schaltet sich erst zu, wenn der Verkehr trotz FlowSpec-Filterung weiter wächst und sich der Grenze nähert, ab der die Sättigung der Leitung droht. Ein typisches Konfigurationsmuster sieht so aus: lokale FlowSpec-Filterung bis zum Erreichen einer kritischen Verkehrsmenge, und erst oberhalb dieses Niveaus RTBH als Absicherung gegen die Sättigung der Anbindung an die Außenwelt.

Die empfohlene Praxis bei der Konfiguration des Blackholing-Schwellenwerts besteht darin, im Profil ausschließlich die Kontrolle auf IP-Adressebene zu belassen (ohne Aufteilung nach Protokollen) und den Schwellenwert nahe an der maximalen Verkehrsmenge zu setzen, die die jeweilige Anbindung tatsächlich aufnehmen kann, und nicht nahe bei null. So schützt RTBH tatsächlich vor der Sättigung der Ports, statt bei jedem kleinen Angriff auszulösen, den FlowSpec ohnehin bewältigt hätte.

Das System bewertet Filterregeln auf dieselbe Weise, wie ein Router Routen beim Routing bewertet: Ein spezifischeres Präfix hat höhere Priorität als ein allgemeines. Dadurch lässt sich für eine einzelne, kritische Adresse (z. B. einen Dienstserver) innerhalb eines größeren Subnetzes eine separate /32-Regel mit anderen Schwellenwerten konfigurieren als für die Regel, die das gesamte Subnetz abdeckt, und die spezifischere Regel wird zuerst angewendet.

So lassen sich z. B. für normale Kunden aggressive, niedrige Schwellenwerte für an sie gerichteten TCP-SYN-Verkehr setzen (weil sie standardmäßig nicht viele solcher Pakete empfangen sollten), während man für Server, die von Natur aus viel SYN-Verkehr von vielen Clients gleichzeitig empfangen, höhere Schwellenwerte oder einen anderen Filtermechanismus belässt, um ihnen nicht den für sie normalen Verkehr abzuschneiden.

Dieser Mechanismus hat eine deutliche Einschränkung: Er funktioniert gut, wenn man eine einzelne Adresse innerhalb eines Angriffs auf das gesamte Subnetz gesondert behandeln möchte. Man kann dagegen nicht ohne Weiteres eine bestimmte Adresse von der Mitigation ausnehmen, wenn der Angriff das gesamte Subnetz betrifft und auf Subnetzebene bereits eine breite FlowSpec- oder RTBH-Regel wirkt. Es gibt keine Möglichkeit, eine noch spezifischere Route anzukündigen, die eine einzelne Adresse aus dieser Regel herausnimmt.

Collateral Damage beschränkt sich nicht auf den RTBH-Mechanismus: Ein falsch gewählter, zu niedriger Filterschwellenwert kann legitimen Verkehr abschneiden, obwohl das System technisch konfigurationsgemäß gearbeitet hat. Ein typisches Beispiel aus der Praxis: Ein aggressiver Schwellenwert für IP-Fragmentierung (IPFRAG), der zum Schutz vor Angriffen mit fragmentierten Paketen gesetzt wurde, kann beginnen, legitimen IPsec-Tunnelverkehr abzuschneiden. Das ESP-Protokoll fragmentiert sich bei größeren Paketen naturgemäß, sodass bei niedrigem Schwellenwert und einer Regel, die alle Fragmente zu einer Adresse blockiert, der gesamte VPN-Tunnel des Kunden ausfällt.

Das zeigt, warum die Abstimmung der Schwellenwerte ein Prozess und keine einmalige Handlung ist: Eine Konfiguration, die auf dem Papier sicher aussieht, kann in der Praxis ein konkretes, legitimes und für das jeweilige Netz spezifisches Verkehrsmuster blockieren. Deshalb zeichnet LiveShield für ausgelöste Regeln Paketmitschnitte (Packet Dumps) auf, mit denen sich im Nachhinein genau prüfen lässt, welcher Verkehr abgeschnitten wurde und ob die Regel wie beabsichtigt gewirkt hat.

Die Minimierung von Collateral Damage in LiveShield beruht auf drei zusammenwirkenden Mechanismen: der Priorität von FlowSpec vor RTBH (RTBH als Notfallabsicherung, nicht als erste Verteidigungslinie), der Priorität spezifischerer Präfixe vor allgemeinen (die Möglichkeit, für kritische Adressen innerhalb eines größeren Subnetzes andere Schwellenwerte festzulegen) sowie einer bewussten Abstimmung der Filterschwellenwerte, damit die Filterregeln selbst nicht zur Schadensquelle werden. Keiner dieser Mechanismen funktioniert vom ersten Tag an vollständig automatisch: Er erfordert die Konfiguration der Schwellenwerte passend zum konkreten Netz und eine spätere Beobachtung, doch genau diese Konfigurierbarkeit erlaubt es, die Nebenwirkungen der Mitigation auf ein Minimum zu begrenzen.

Arbeiten RTBH und FlowSpec in LiveShield gleichzeitig oder nacheinander? Filterregeln (FlowSpec) und Blackholing-Regeln (RTBH) werden unabhängig und parallel auf Basis separater Schwellenwerte geprüft. Ist der Blackholing-Schwellenwert höher als der Filterschwellenwert, reagiert in der Praxis zuerst FlowSpec, und RTBH schaltet sich erst zu, wenn der Verkehr trotz Filterung weiter wächst.

Lässt sich eine bestimmte IP-Adresse bei einem Angriff auf das gesamte Subnetz von der Mitigation ausnehmen? Nicht auf einfache Weise. Unter normalen Bedingungen lässt sich für eine einzelne Adresse eine separate, spezifischere Regel mit anderen Schwellenwerten konfigurieren. Betrifft der Angriff jedoch das gesamte Subnetz und wirkt bereits eine breite FlowSpec- oder RTBH-Regel auf dieses Subnetz, lässt sich keine noch spezifischere Route ankündigen, die eine einzelne Adresse davon ausnimmt.

Wie setzt man den Blackholing-Schwellenwert, damit er nicht bei jedem kleinen Angriff auslöst? Die empfohlene Praxis besteht darin, im Blackholing-Profil ausschließlich die Kontrolle auf IP-Adressebene zu belassen und den Schwellenwert nahe an der maximalen Verkehrsmenge zu setzen, die die Anbindung tatsächlich aufnehmen kann.