DDoS Schutz über BGP Netzwerkankündigungen

In zwei vorangegangenen Artikeln habe ich die Funktionsweise von DDoS Angriffen beschrieben, und wie man DDoS Angriffe auf einfache Art abwehrt. Heute beschreibe ich, wie man eine ganze Infrastruktur zuverlässig und umfassend vor DDoS Angriffen schützt.

Disclaimer: In diesem Artikel geht es um ein äusserst technisches Thema, ich werde dies jedoch mit einfachen Beispielen aus dem Strassenverkehr erklären.

Proxy Schutz - limitierte Sicherheit

Den Proxy-Schutz habe ich in einem früheren Artikel beschrieben. Es ist eine gute Lösung, wenn man einzelne Domänen schützen will, und dabei auch nur einzelne Dienste wie zum Beispiel Web. Das Problem hierbei ist jedoch, dass wenn ein Angreifer merkt, dass nur einzelne Dienste geschützt sind, andere hingegen nicht, er den Angriff dann auf einen nicht geschützten Service lancieren könnte. Technisch ausgedrückt das einfachste Beispiel ist z.B. ein DNS-Reflection Angriff, oder eine simple Bandbreiten Auslastung mittels ICMP.

In der Regel ist es bei Infrastrukturen jedoch so, dass man einzelne Services auf einzelnen Hosts laufen lässt - so dass ein Host nur wenig Angriffsfläche bietet - eben zum Beispiel nur HTTP (Web). In solchen Fällen kann ein Proxy-Schutz durchaus genügend sein. Wird die Infrastruktur grösser und setzt man Lösungen für den Lastenausgleich (Cluster) ein, muss allerdings eine Lösung gefunden werden, um ein ganzes Subnetz zu schützen.

Schutz ganzer Subnetze mittels BGP

BGP steht für Border-Gateway-Protocol, und ist ein Routing-Protokoll. Und nun etwas einfacher erklärt: Das Internet ist vergleichbar mit einem Strassennetz, und die Strassenbeschilderungen mit den Ortschaftsnamen sind die Routinghinweise für die Autofahrer. Die Strassenschilder im Verkehr sind "statisch" montiert, daher kann man daran nicht viel verändern. Ist eine Strasse überlastet, zeigen die Schilder nicht automatisch einen alternativen Weg an.

Das BGP ist hingegen ein dynamisches Routing-Protokoll. Fällt eine Verbindung aus, werden die Strassenschilder automatisch angepasst, und der Verkehr kann über eine andere Achse fliessen. Die Achse ist allenfalls etwas ungünstiger und länger, aber die Autofahrer kommen so wenigstens noch an. Genau so funktioniert BGP.

Wenn nun eine Infrastruktur angegriffen wird, so kann der Betreiber der Infrastruktur eine BGP-Ankündigung aussenden, welche allen grossen Verkehrsknoten im Internet meldet, dass der Traffic nun woanders durch geleitet werden soll. Die Strassenschilder zeigen nun in die Richtung eines DDoS Abwehr Anbieters. Solche Anbieter verfügen oft über Bandbreiten zwischen 0.5-2 Terabit, und können grosses Verkehrsaufkommen ohne Probleme bewältigen und nötigenfalls abweisen (=vernichten).

Der Schutz greift in dem Moment, wenn die BGP Ankündigungen seitens DDoS Schutz Anbieters seinerseits an seine Upstream Carrier kommuniziert wurde. Dies ist ein Prozess, der wenige Sekunden dauert. Jeder Anbieter hat zudem eigene ausgeklügelte Algorithmen, die eingehende Angriffe erkennt und die entsprechende Aktivierung proaktiv vornehmen kann.

Zulassen von legitimem Traffic

Nun soll aber legitimer Verkehr trotzdem zu unserer Website gelangen. Wie wird das nun sichergestellt? Nun, der Traffic wird beim DDoS Anbieter nicht einfach vernichtet, sondern er wird analysiert und nur die "bösen" Pakete werden abgewiesen (eine Art Strassensperre). Bei einem DDoS Angriff macht das etwa 99.9% des Traffics aus, der vernichtet wird. Die restlichen "guten" 0.1 Prozent werden dann wieder an uns zurückgesendet.

Da nun aber unsere Strassenschilder umgestellt sind, kann Traffic so gar nie mehr zu uns durchkommen und landet in einer Schleife automatisch wieder beim DDoS Anbieter. Deswegen ist es nötig, auf den Strassen eine eigene Spur zu haben (wie eine Busspur), welche aber nur privat verwendet werden darf (und mit einem Zaun entsprechend geschützt ist). Wir brauchen auf dieser Spur auch keine Strassenschilder, da es keine Möglichkeiten gibt, eine Abzweigung zu nehmen. Allerdings braucht diese Privatspur Platz. Die Spur führt jedoch direkt zu uns. In der Fachsprache spricht man hier von einem VPN.

Technisch funktioniert das sogar ziemlich ähnlich, dies wird über das GRE Protokoll (Generic Routing Encapsulation) aufgebaut. Somit wird der Verkehr also an den DDoS Anbieter gesendet, und guter Traffic wird mittels GRE an uns weitergeleitet. Die Antworten, die unsere Infrastruktur aufgrund der Anfragen versendet, gehen hingegen wieder auf normalem Wege (über unseren Provider) raus. Man spricht hier von einem asymmetrischen Routing: Die Anfragen kommen über GRE rein, die Antworten gehen über den normalen Verkehr wieder raus.

Nachteile der GRE Enkapsulierung

Einer der grössten Nachteile ist, dass für das GRE Protokoll die Pakete ein zweites Mal verpackt werden müssen. Entsprechend nimmt das Übertragungsvolumen pro Paket zu, es braucht Bandbreite auf der "Strasse" und die Übertragung dauert auch länger (höhere Latenz). Da der oben beschriebene GRE-Kanal virtuell ist, und damit nach wie vor übers Internet geht, ist nicht voraussehbar, wie hoch die Latenz tatsächlich sein wird. Bei Anwendungen, die eine hohe Bandbreite und niedrige Latenz voraussetzen, stösst diese Lösung definitiv an Grenzen.

Alternative zu GRE: Private Cloud Direktverbindungen

Damit man den Overhead der GRE Verbindung umgehen kann, muss zwischen der zu schützenden Infrastruktur und dem DDoS Anbieter eine Art "Strassentunnel" gebaut werden. Dieser wird nur privat zwischen Anbieter uns uns verwendet. Deshalb spricht man im Fach- und Marketing Jargon hier gerne von einer "Private Cloud". In diesen Tunnel werden nun die "guten" Autofahrer gesendet, damit sie auf geradem und direktem Wege zu uns ans Ziel gelangen, ohne eine Dritt-Infrastruktur zu belasten.

Technisch gesehen wird der DDoS Anbieter möglichst direkt mit der zu schützenden Infrastruktur verbunden. Idealerweise ist dies ein direktes Peering, so dass die beiden schlussendlich über Switchports direkt miteinander verbunden sind. Hierfür ist es nötig, dass der Anbieter in vielen grösseren Rechenzentren mit einem Anschluss vertreten ist - und dass die zu schützende Infrastruktur sich natürlich auch dort befindet. Wo dies nicht gegeben ist, wird die Infrastruktur direkt über Backbone Verbindungen angeschlossen, wobei ein besonderes Augenmerk auf Bandbreite und Latenz geworfen werden muss. Da der "gute" Traffic aber meist nicht allzu hohe Anforderungen an Bendbreite hat, stellt dies im Alltag sozusagen kein Problem dar.

Vergleich GRE und Private Cloud

Wer bis hierher aufmerksam gelesen hat, wird sich nun sagen, dass die direkten Verbindungen über eine private Cloud die beste Lösung wäre. Dem stimme ich aus einer technischen Sicht auch zu. Allerdings ist der Projektaufwand hierbei viel höher, und auch die Betriebskosten. Ein GRE Tunnel hingegen ist schnell mal aufgebaut, und muss in der Regel auch nicht gemanaged werden.

Daher entscheiden sich viele für eine GRE-basierende Lösung. Sobald jedoch hohe Bandbreiten über 1 Gigabit erforderlich werden, sollte man auf eine Direktverbindung setzen, denn sonst würde man die normalen Traffic Knoten unnötig belasten.

Weiter ist zu erwähnen, dass wenn man akut angegriffen wird, die private Cloud nicht schnell genug errichtet werden kann. Auch in diesen Fällen wird man sich also für die GRE-basierte Lösung entscheiden müssen.

Infrastrukturelle Anpassungen

Bei beiden Lösungen ist es nötig, dass ein eigener Internet-Edge mit dem BGP Protokoll betrieben wird. Grössere Provider betreiben ihren eigenen Edge, und können auch einzelne Subnetze routen. Zu diesem Stichwort ist es wichtig zu erwähnen, dass nur Subnetze geroutet werden können, als nicht einzelne IP-Adressen. Zudem muss ein solches Projekt vorab mit dem Provider abgesprochen werden, denn nicht jeder will, dass man in seine Infrastruktur eingreift. Dementsprechend findet man auf dem Markt bestimmte Provider, welche ihre DDoS Bereitschaft aktiv bewerben, oder sogar eigene Produkte anbieten - entweder als Reseller, oder als eigener DDoS Schutz Anbieter.

Kosten?

Viele DDoS Anbieter halten sich bezüglich der Kosten bei solchen Infrastruktur Lösungen bedeckt. Dies ist auch legitim, denn jedes Projekt hat wieder andere Anforderungen an Bandbreite und Traffic. Generell starten Enterprise-Lösungen wie oben beschrieben bei ca. 1'000 US$ monatlich, bei hohen Anforderungen an die Bandbreite bewegen sich die Preise im Feld von ca. 5'000$ monatlich.