Die Bandbreite ist das Hauptproblem
Das Hauptproblem bei DDoS Angriffen ist, dass sehr schnell die maximale Bandbreite des Ziel-Providers ausgeschöpft wird. Viele Hosting-Anbieter in der Schweiz verfügen (Stand 2013) über 10 Gigabit/s Anbindungen an die Upstream Provider. Ein starker DDoS Angriff kann aber schnell mal 50-300 Gigabit/s umfassen, womit man innert Minuten K.O. ist.
Massive CDN- und Analyse Infrastruktur
Nun kann man dies abfedern, indem man Content Delivery Networks einsetzt (darüber habe ich schon in einem früheren Artikel zu Web Performance Steigerung berichtet). Ein CDN verfügt über mehrere Standorte weltweit und hat die Fähigkeit, Routing mittels Anycast zu betreiben. Das bedeutet, dass wenn ein Benutzer auf die IP-Adresse unseres Servers zugreifen will, er stattdessen auf den nächstgelegenen CDN-Node geleitet wird. Ein Benutzer aus Washington wird also auf den CDN-Node in Washington geleitet, während ein Nutzer aus Stockholm auf den CDN-Node in Irland geleitet wird, usw. Im Falle eines DDoS Angriffes auf die IP-Adresse unseres Servers, wird der "verteilte" (distributed) Angriff also auf unsere CDN-Nodes "verteilt". Damit wird erstens die Gesamtbandbreite des Angriffes auf die Nodes aufgeteilt, und zweitens ist bis zu diesem Zeitpunkt unser Server vom Angriff noch nicht betroffen.
Diese Nodes nennt man "Scrubbing Facilities". Diese haben hohe Anforderungen an Durchsatz und Rechenpower, um die immensen Datenströme analysieren und Angriffe erkennen zu können. In der Regel verfügen Nodes seriöser Anbieter im Minimum über 100 Gigabit/s Anbindungen an ihre Backbone Provider.
Gängigste Methode: Proxy-Schutz
Hierbei verwenden wir für unsere Domain den DNS Server des DDoS-Mitigation-Anbieters. Dieser schaltet dann den DNS Record für unsere Domain so auf, dass dieser nicht mehr auf unseren Webhost zeigt, sondern auf die Scrubbing Facility. Damit ist die öffentliche IP-Adresse unseres Webhost nicht mehr bekannt. Ruft jemand nun unsere Domain auf, so wird er auf die nächst gelegene Scrubbing Facility geleitet. Ist mit dem Traffic alles okay, wird dieser auf unseren Webhost weitergeleitet - und zwar transparent - sprich der User merkt nichts von der Sache. Ebenfalls wird unser Webhost dann wieder über den Proxy antworten.
Entdeckt nun eine all dieser Scrubbing Facilities einen ungewöhnlichen Anstieg der Anfragen, so wird das gemeinsame Muster in Echtzeit analysiert und ein System von Blockierlisten aktiviert, welche die "bösen" Anfragen bereits schon in der Scrubbing Facility unterbindet. So gelangt nur noch weitgehend gereinigter Traffic auf unseren Webhost. Je nach dem wie weit angelegt ein solcher Angriff ist, werden die Blockierlisten weltweit auf allen Nodes in Echtzeit aktiviert, oder die Behandlung findet nur auf dem betroffenen Node statt.
Gibt es False Positives?
Nun kann man sich überlegen, was denn passiert, wenn eine legitime Anfrage blockiert wird. Hier ist grundsätzlich dazu zu sagen, dass die Blockierlisten erst dann erstellt, aktiviert und nachgeführt werden, wenn ein offensichtlicher Angriff im Gange ist. Dies ist relativ einfach bemerkbar, da der Traffic in einem solchen Moment extrem zunimmt. Das heisst, in Zeiten des "Friedens" wird der Traffic recht unrestriktiv an den Zielhost weitergeleitet, und wenn ein ungewöhnlicher Anstieg des Traffics zu beobachten ist, fangen die Mechanismen an zu greifen.
Während eines laufenden Angriffes, könnte es nun natürlich passieren, dass ein regulärer Besucher fälschlicherweise ausgefiltert wird. Dies wäre aber genau nicht das Ziel eines wirksamen DDoS Schutzes, denn man möchte ja die "Guten" durchlassen und die "Bösen" weg haben. Wie funktioniert das nun?
On the Fly Challenge Response Verfahren
Zur Zeit des Angriffes wird unserer Website automatisch eine Landingpage mit Javascript-Loader vorgeschaltet. Dies funktioniert, da der Traffic ja über den Scrubbing Proxy geht. Dieser Loader beinhaltet ein kleines Stück Javascript Code, in welchem der Browser eine rechenintensive Operation vornehmen muss, welche einige Sekunden dauert (Challenge). Erst wenn die Operation erfolgreich war und das Ergebnis (Response) korrekt ist, wird der Besucher an die richtige Website weitergeleitet und ein kryptographisch gesichertes Cookie gesetzt, in welchem drin steht, dass der User nun legitimiert ist und der Loader nicht jedesmal neu angezeigt werden muss.
Da bei grossangelegten Angriffen keine Webbrowser, sondern Scripts verwendet werden, ist eine solche Challenge-Response Berechnung durch die Angreifer gar nicht erst möglich. Man kann sich das Ganze als eine Art Captcha vorstellen, welches der Mensch aber nicht ausfüllen muss.
Dieses Verfahren kommt wie erwähnt in der Regel erst dann zum Einsatz, wenn ein Angriff im Gange ist. Ansonsten wären Besucher der Website darüber irritiert, dass sie jedesmal 5 Sekunden warten müssen beim ersten Zugriff auf die Website. Ich bin allerdings auch schon auf Websites im Finanz- und Aviatiksektor gestossen, welche dieses Verfahren standartmässig jedesmal anwenden (manchmal auch versteckt hinter einem Lade-Banner, usw).
Einrichtung und Aufwand
Der Vorteil an dieser Methode ist, dass sie sehr schnell umgesetzt ist. Seitens Webmaster gilt es lediglich den DNS Record anzupassen - oder wie heute bei kommerziellen Lösungen üblich, gleich den DNS Server des entsprechenden Anbieters für die Domain beim Registrar zu hinterlegen. Die Domain ist damit nach kurzer Zeit geschützt. Diese Methode eignet sich daher auch dann, wenn man bereits unter Angriff steht. Allerdings ist es nach Einrichtung des Schutzes dann nötig, sofort die IP zu wechseln, damit diese öffentlich nicht mehr bekannt ist. Tut man dies nicht, wirkt der Schutz nur sehr langsam (Stichwort TTL der Domain Records). Allerdings muss man sich dann auch bewusst sein, dass während einer gewissen Zeit die Website nicht erreichbar sein wird.
Daher ist es generell sowieso besser, einen DDoS Schutz proaktiv einzurichten, und nicht erst, wenn ein Angriff bereits am Laufen ist.
Und die Kosten?
Die Kosten eines DDoS Schutzes hängen oft von der entsprechend benötigten Bandbreite ab. Dabei findet man auf dem Markt verschiedene Modelle:
- Limitierung nach Angriffsbandbreite
- Limitierung nach gesäuberter Bandbreite
- Limitierung nach gesamten Datenübertragungsvolumen
- Limitierung nach gesäubertem Traffic
- Total Pakete pro Sekunde
- Unlimitiert
Auf Angebote, welche eine tiefe Limite auf die "Attack Bandwidth" setzen (1Gbit/s und daraunter), sollte man nicht eingehen. Damit würde man bewusst nur einen Schutz für kleine Angriffe einkaufen. Da man zudem nie im Voraus weiss, wie gross ein Angriff sein wird, gerät man hier während eines Angriffes schnell in Not mehr Geld auszugeben.
Eine genaue Zahl für einen wirksamen DDoS Schutz pauschal zu nennen ist nicht möglich. In der Regel wird man für einen wirksamen DDoS Schutz für eine Website nach oben erwähntem Proxy Verfahren zwischen 200 und 1000 US-Dollar im Monat berappen müssen. Grenzen nach oben findet man keine.
Empfohlene Anbieter
Es gibt sehr viele Anbieter, mit einer Google-Suche nach "DDoS Protection" wird man schnell fündig. Damit ihr euch aber von Anfang an zurecht findet, anbei einige vernünftige Anbieter:
- Prolexic
Seriöser und führender Anbieter auf dem Markt, enorme Infrastruktur, allerdings oberes Preissegment. Bietet viele weitere sicherheitsrelevante Filterungen an - CloudFlare
Sehr seriöser Anbieter, bietet auch einen Free-Plan an (allerdings ohne DDoS Schutz, dafür mit weiteren Sicherheitsmechanismen) - Black Lotus
Klar führend, interessant ist hier das Kombi-Angebot mit dedizierten Servern; sozusagen alles aus einer Hand. - BlockDos
Junges kanadisches Unternehmen, welche vor allem auf grössere Kunden ausgerichtet ist. - KoDDos
Für grössere Projekte nicht empfehlenswert, aber für kleinere Sites sicher eine interessante Lösung. Interessant auch hier die Kombi-Angebote mit Hosting und VPS, sowie anonymen Hosting
Und weiter?
Dieser Artikel ist einer aus meiner Artikelserie über Large-Scale-Websicherheit. In einem der nächsten Artikel werde ich über DDoS Schutz mittels Private-Cloud Verbindungen und GRE-Tunnels zu Scrubbing Facilities berichten. Stay tuned! PS: Rechts in der Sidebar Mail-Adresse eintragen für neue Artikel!
Keine Kommentare:
Kommentar veröffentlichen