Security

DDoS-Angriffe und wer davon profitiert

DDos-Angriffe: Schlimmer geht immer?
Keine Kommentare

Die DDoS-Angriffe werden immer vehementer, weil die Botnets dahinter immer größer werden und neue Angriffe ihre Schlagkraft vervielfachen. Wie lange das wohl so weitergeht? Und was kann man dagegen tun?

Betrachten wir einmal der Reihe nach die einzelnen Faktoren: Da sind zunächst die Botnets, die inzwischen für die meisten DDoS-Angriffe verwendet werden. Dann die verschiedenen Angriffe, mit denen sie versuchen, ihre Ziele lahmzulegen. Und zu guter Letzt die Möglichkeiten zur Abwehr dieser Angriffe – die inzwischen meist nur noch darin besteht, einen Dienstleister mit der Abwehr zu beauftragen. In Betracht kommen dazu entweder ein Content Delivery Network oder ein auf die Abwehr von DDoS-Angriffen spezialisierter Dienst.

Die Angreifer: Botnets

Anfangs wurden für DDoS-Angriffe kompromittierte Desktoprechner verwendet. Irgendwann merkten die Cyberkriminellen dann allerdings, dass sich auch die Geräte des IoT für diesen Zweck eignen. Richtig los ging es schließlich frei nach dem Motto „Schlimmer geht immer“ im Herbst 2016, als das Mirai-Botnet u. a. die Website des auf IT-Sicherheit spezialisierten Journalisten und Bloggers Brian Krebs, KrebsOnSecurity.com, lahmlegte. Die Hintergründe können Sie im Entwickler Magazin 1.2017 nachlesen, hier interessieren uns nur die Angriffe selbst. In Tabelle 1 sehen Sie diese im Überblick.

Datum Botnet Ziel Umfang Quelle
2016 unbekannt unbekannt/Akamai 363 Gbps Brian Krebs: „KrebsOnSecurity Hit With Record DDoS“
18.9.2016 Mirai OVH 735 Gbps
360 Gbps
442 Gbps
Octave Klaba: „Last days, we got lot of huge DDoS. Here, the list auf ‚bigger that 100Gbps‘ only. You can see the simulatenous DDoS are clos to 1Tbps!“
20.9.2016 Mirai www.krebsonsecurity.com 620 Gbps Brian Krebs: „KrebsOnSecurity Hit With Record DDoS“
20.9.2016 Mirai OVH 1.156 Gbps
901 Gbps
Octave Klaba: „we got 2 huge multi DDoS: 1156Gbps then 901Gbps“
20.9.2016 Mirai OVH 799 Gbps
615 Gbps
698 Gbps
587 Gbps
Octave Klaba: „Last days, we got lot of huge DDoS. Here, the list auf ‚bigger that 100Gbps‘ only. You can see the simulatenous DDoS are clos to 1Tbps!“
21.10.2016 Mirai (vermutlich anderes Botnet) Dyn DNS-Infrastruktur unbekannt Dyn Inc. Status: „DDoS Attack Against Dyn Managed DNS“

Scott Hilton: „Dyn Analysis Summary Of Friday October 21 Attack“

Tabelle 1: Einige DDoS-Angriffe durch Mirai im Überblick

20. September 2016: Der erste Angriff auf Brian Krebs

Am Abend des 20. September wurde www.krebsonsecurity.com das erste Mal Opfer eines DDoS-Angriffs durch das Mirai-Botnet. Die Website wurde vom Akamai vor solchen Angriffen geschützt, und der Angriff lief ins Leere, sodass es nicht zu größeren Ausfällen kam. Aber laut Akamai war der Angriff mit ca. 620 Gigabit Traffic pro Sekunde fast doppelt so groß wie der größte Angriff, den man selbst je zuvor beobachtet hatte (363 Gbps), und gehörte zu den größten Angriffen dieser Art, die das Internet bis dahin erlebt hatte. Was außerdem ungewöhnlich war: Bis dato wurden für DDoS-Angriffe meist Techniken genutzt, um den Traffic des Angreifers weiter zu verstärken (z. B. durch DNS Reflection, bei der die Antworten auf gefälschte DNS-Anfragen auf den angegriffenen Server geleitet werden). Dieser Angriff ging aber ausschließlich von einem sehr großen Botnet aus. Es wurde einfach eine große Anzahl von Anfragen an den Webserver geschickt, darunter SYN-, GET- und POST-Floods.

20. September 2016: DDoS-Angriff auf OVH

Ebenfalls am 20. September kam es zu einem DDoS-Angriff auf den französischen Webhoster OVH, der sogar den Angriff auf www.krebsonsecurity.com in den Schatten stellt: Es wurden insgesamt bis zu 1,1 Terabit pro Sekunde gemessen. OVH-Gründer Octave Klaba berichtete auf Twitter laufend über die Angriffe, die am 18. September begannen und über mehrere Tage liefen, mit dem Höhepunkt am 20. September (Tabelle 1 zeigt nur eine Auswahl). Die Angriffe scheinen vom gleichen Botnet ausgegangen zu sein, das auch für die Angriffe auf die Website von Brian Krebs verwendet wurde.

22. September 2016: Weitere Angriffe zwingen Akamai zur Aufgabe

Nachdem die DDoS-Angriffe auf die Website von Brian Krebs weiter zunahmen, gab Akamai am 22. September 2016 auf und stellte den Schutz ein. Was Brian Krebs Akamai aber nicht übelnahm, da diese seinen Server vier Jahre lange erfolgreich kostenlos geschützt hatten und die Abwehr der aktuellen Angriffe sehr teuer war.

25. September 2016: Google springt Krebs bei

Am 25. September 2016 war die Website von Brian Krebs wieder online, nun geschützt durch Googles „Project Shield“. Das ist ein kostenloses Programm von Google, um Journalisten und Nachrichtenwebsites vor DDoS-Angriffen zu schützen, mit denen unerwünschte Meinungen unterdrückt werden sollen.

28. September 2016: Der Source Code des Botnets wird veröffentlicht

Am 28. September 2016 wurde der Source Code für das für die Angriffe verwendete IoT-Botnet mit dem Namen „Mirai“ vom Benutzer „Anna-Senpai“ auf Hack Forums veröffentlicht. Inzwischen wird der Source Code auf GitHub gehostet, sodass Forscher ihn untersuchen können.

21. Oktober 2016: DDoS-Angriff auf Dyn

Am 21. Oktober 2016 kam es zu mehreren DDoS-Angriffen auf die Managed-DNS-Infrastruktur von Dyn. Durch die Angriffe waren die Nameserver von Dyn nicht erreichbar, sodass DNS-Anfragen nach von Dyn verwalteten Domainnamen fehlschlugen. Dadurch waren die Websites einiger großer Anbieter wie Amazon, GitHub, Netflix, PayPal, Reddit, Spotify und Twitter am 21. Oktober in Teilen der USA und Europas zeitweise nicht zu erreichen. Die Angriffe gingen zum größten Teil von einem Mirai-Botnet aus, jedoch ist nicht bekannt, von welchem genau, denn inzwischen gab es mehrere Botnets auf Basis des veröffentlichen Mirai Source Codes.

24. November 2016: Mirai-Botnet zu vermieten

Am 24. November 2016 berichtete BleepingComputer, dass Cyberkriminelle über XMPP/Jabber die Dienste eines Mirai-Botnet aus mindestens 400 000 kompromittierten IoT-Geräten zur Miete anboten. Die Geräte sollten mit einer verbesserten Mirai-Version infiziert sein.

28. März 2017: Mirai-Angriffe auf der Anwendungsschicht

Bisher erfolgten die DDoS-Angriffe i. A. auf der Netzwerkschicht. Am 28. März 2017 startete ein DDoS-Angriff auf ein von Imperva geschütztes US-College. Das Besondere an diesem Angriff:

  1. Er fand auf der Anwendungsschicht statt. Details dazu wurden leider nicht veröffentlicht, bekannt wurde lediglich, dass es sich um „more elaborate application layer attacks“ handelte.
  2. Er lief mit 54 Stunden deutlich länger als die meisten zuvor beobachteten DDoS-Angriffe auf der Anwendungsschicht (von denen neunzig Prozent unter sechs Stunden andauerten).

Verbrechen lohnt sich …

Seit der Veröffentlichung des Mirai Source Codes (siehe Zeitleiste) tauchen immer wieder verbesserte Versionen von Mirai auf. So etwa im August 2018. Zu diesem Zeitpunkt wurde eine Version veröffentlicht, die den Cross-Compiler Aboriginal Linux nutzt, um neue Opfer, sowohl bei der Architektur als auch den Betriebssystemen, zu erreichen. Außerdem wurden Teile des Mirai Source Codes in anderen IoT-Bots weiterverwertet, die dann auch andere Angriffe als DDoS-Attacken durchführen können. Sie können zum Beispiel mit den kompromittierten IoT-Geräten Kryptowährungen schöpfen oder die von den Benutzern geschöpften Währungen ins eigene Wallet umleiten. Das altbekannte Problem: Wenn irgendetwas erfolgreich ist, wird es sofort nachgemacht. Egal, ob es nun etwas Gutes oder etwas Schlechtes ist.

… fragt sich nur, für wen

In diesem Fall hätten sich die Nachahmer aber vorher einmal ansehen sollen, wie es den Mirai-Entwicklern nach den Angriffen und der Veröffentlichung des Source Codes ergangen war. Nachdem die Identität von „Anna-Senpai“ und zwei weiteren Mirai-Entwicklern aufgedeckt war, landeten sie vor einem US-Bezirksgericht in Alaska, wo sie sich schuldig bekannten. Sie wurden jeweils zu fünf Jahren Gefängnis auf Bewährung und 2 500 Sozialstunden sowie Entschädigungszahlungen in Höhe von 127 000 US-Dollar verurteilt. Außerdem haben sie bereits vor der Verhandlung freiwillig auf einen großen Teil der während der Ermittlungen beschlagnahmten Kryptowährung verzichtet. Teil des Urteils ist ebenfalls, dass sie ihre schon während der Ermittlungen begonnene Zusammenarbeit mit dem FBI und weiteren Strafverfolgungsbehörden fortsetzen müssen.

Insgesamt sind die drei damit aber noch billig weggekommen. Denn „Anna-Senpai“ wurde außerdem wegen eines Angriffs auf die Ruttgers University vor einem Bezirksgericht in New Jersey angeklagt, das Urteil dort kam ihn deutlich teurer zu stehen: Er wurde zu sechs Monaten Hausarrest verurteilt und muss außerdem 8,6 Millionen US-Dollar Entschädigung zahlen. Seine Partner dürften froh sein, dass für sie das Ganze mit dem Urteil in Alaska beendet war.

Auch Smartphone und Co. können DDoSen

Wie eingangs erwähnt, wechselten die Cyberkriminellen als Ausgangspunkt ihrer DDoS-Angriffe von Desktoprechnern zu IoT-Geräten. Aber auch Smartphones und andere Mobilgeräte eignen sich für DDoS-Angriffe, wie das Beispiel des WireX-Botnets zeigt. Dieses wurde im August 2017 für DDoS-Angriffe auf Content Delivery Networks (CDNs) und Content-Provider eingesetzt. Das Botnet bestand zum größten Teil aus Android-Geräten, auf denen bösartige Apps aus Googles Play Store liefen. Nachdem Google über diese ca. 300 bösartigen Apps informiert worden war, wurden sie zunächst aus dem Store und danach von den betroffenen Geräten gelöscht. Sie sehen also: DDoS-Angriffe können inzwischen von überall kommen.

Aber kommen wir von der Ausführung der Angriffe zu den eigentlichen Angriffen. Ein entsprechend großes Botnet kann einen normalen Webserver schon durch das Fluten mit ganz normalen HTTP Requests in Bedrängnis bringen, meist werden aber auch andere Angriffe gestartet.

Die Angriffe

Als typische Beispiele für DDoS-Angriffe können die in Mirai implementierten dienen. Diese sowie der Mirai Source Code wurden von einer Vielzahl von Forschern untersucht, z. B. von F5 und Imperva.

Flooding-Angriffe

Mirai kann Angriffe sowohl auf den Netzwerkschichten als auch auf der Anwendungsschicht ausführen. Auf den Netzwerkschichten kommen weitgehend die schon lange üblichen Flooding-Angriffe zum Einsatz, bei denen das Ziel mit bestimmten Paketen überflutet wird. Das führt letztlich zu seiner Überlastung, sodass reguläre Requests nicht mehr beantwortet werden können. Und auch auf der Anwendungsschicht kann, wie schon erwähnt, ein HTTP-Flooding-Angriff (GET-/POST-Flooding) erfolgreich sein, wenn das Botnet groß genug ist. Einige Beispiele für Flooding-Angriffe:

  • SYN Flooding: Das Ziel wird mit SYN-Paketen überflutet, für die der Server eine TCP-Verbindung reserviert und auf die er mit einem SYN/ACK-Paket antwortet. Der Angreifer antwortet auf die SYN/ACK-Pakete nicht, sodass der 3-Wege-Handshake von TCP nicht vollendet wird. Die dadurch erzeugten halboffenen TCP-Verbindungen belegen beim Ziel Ressourcen, sodass nach einiger Zeit keine weiteren Verbindungen mehr angenommen werden können.
  • UDP Flooding: Das Ziel wird mit User-Datagram-Protocol-(UDP-)Paketen an zufällige Ports überflutet, sodass der betroffene Server immer wieder nachsehen muss, welche Anwendung an diesem Port lauscht und, wenn keine gefunden wurde, mit einem ICMP-Destination-Unreachable-Paket antworten muss.
  • ICMP (Ping) Flooding: Das Ziel wird mit ICMP-Echo-Request-(Ping-)Paketen überflutet, die so schnell wie möglich und ohne auf eine Antwort zu warten geschickt werden. Dieser Angriff belastet sowohl ein- als auch ausgehende Bandweite, da der Server mit ICMP-Echo-Reply-Paketen antworten will. Eine Möglichkeit für ICMP-Flooding sind die sog. Smurf-Angriffe.
  • STOMP Flooding: STOMP (Simple Text-oriented Message Protocol) ist ein einfaches, textbasiertes Protokoll auf dem Application-Layer und dient der Kommunikation mit Message Brokern. Beim DDoS-Angriff öffnet der Angreifer mit STOMP einen authentifizierten TCP-Handshake mit der Zielanwendung und flutet das Ziel danach mit als STOMP Tcl Requests getarntem Datenmüll. Dadurch wird die Netzwerkverbindung überlastet und, falls das Ziel die STOMP-Daten parst, ggf. auch der Server.
  • DNS Flooding und DNS Amplification Attacks: Allgemein verschickt der Angreifer bei einer Amplification Attack eine Vielzahl von DNS-Anfragen mit der gefälschten Absenderadresse des Ziels so, dass die Antwort möglichst groß ausfällt. Mirai setzt jedoch die zwar schon zuvor beobachtete, aber wenig genutzte DNS-Water-Torture-Technik ein.
  • Außerdem gibt es auf der Netzwerkschicht noch die bisher noch nicht beobachteten Flooding-Angriffe mit GRE-Paketen.

Die DNS-Wasserfolter

Bei der DNS Water Torture lässt der Bot den rekursiven Nameserver seines ISPs die Hauptarbeit für den Angriff auf die autoritativen Nameserver des Angriffsziels machen. Der Bot sendet eine wohlgeformte DNS-Anfrage nach dem Domainnamen des Ziels zur Auflösung an den Nameserver seines ISPs. Eigentlich wäre die Namensauflösung kein Problem, die Domain existiert ja. Der Bot setzt vor den Domainnamen aber einen zufällig erzeugten Präfix, sodass der Nameserver des Angriffsziels die Adresse für z. B. qayxsw.name.example, cderfv.name.example, … nennen soll. Die Suche nach diesen nicht existierenden Namen dauert eine Weile, und die Menge der Anfragen führt dazu, dass der erste autoritative Nameserver nicht schnell genug antwortet. Die anfragenden Nameserver senden ihre Anfrage daher an den nächsten autoritativen Nameserver, der dann irgendwann ebenfalls überlastet ist und nicht rechtzeitig antwortet, sodass der nächste autoritative Nameserver an die Reihe kommt. So werden nach und nach alle autoritativen Nameserver überlastet, und legitime Anfragen können nicht mehr beantwortet werden: die Domain ist nicht mehr erreichbar. Dieser Angriff wird auch als DNS Cache Busting bezeichnet, da er nie aus dem Cache der rekursiven Nameserver beantwortet werden kann, sodass jede Anfrage an einen autoritativen Nameserver weitergeleitet werden muss, der dadurch irgendwann überlastet wird.

Das GRE Flooding

GRE (Generic Routing Encapsulation) ist ein Tunneling-Protokoll, das eine Vielzahl von Netzwerkprotokollen in virtuelle Punkt-zu-Punkt-Verbindungen kapseln kann. Übertragen werden die GRE-Pakete über UDP. Die Forscher von F5 vermuten, dass GRE verwendet wird, weil sich darüber große Payloads übertragen lassen, die beim Angriffsziel zusätzliche Arbeit verursachen.

Mirais Angriff auf der Anwendungsschicht

Zusätzlich zu diesen Angriffen ist in Mirai ein weiterer Angriff implementiert, der anfangs aber weder beobachtet wurde noch überhaupt vom Code aufgerufen werden konnte. Dieser „cfnull“ genannte Angriff erfolgt auf der Anwendungsschicht und ist vergleichbar einem GET-/POST Flooding, verwendet aber eine große POST Payload von 80 MB zufällig erzeugter alphabetischer Strings. Das würde beim angegriffenen Webserver große Mengen Ressourcen verbrauchen.

API Conference 2019

Oliver Drotbohm

REST Beyond the Obvious – API Design for Ever Evolving Systems

mit Oliver Drotbohm (Pivotal Software, Inc.)

Arne Limburg

API-Kompatibilität durch Consumer-Driven Contracts

mit Arne Limburg (OPEN KNOWLEDGE GmbH)

 

Cloudflare hat 2016 Angriffe beobachtet, die genau dem in Mirai implementierten Muster entsprachen. Dort geht man davon aus, dass der Angriff nicht von einem Mirai-Botnet ausging, da der veröffentlichte Source Code dazu gar nicht in der Lage sein dürfte. Die Ähnlichkeit mit dem cfnull-Angriff von Mirai ist aber extrem auffällig, die Größe der Payload sowie ihr Aufbau stimmen überein. Entweder gab es also damals schon eine Mirai-Version, in der der cfnull-Angriff verwendet werden konnte, oder der Angriff ging von einem der Vorgänger von Mirai aus.

„Anna-Senpai“ und seine Kollegen betrieben nämlich einen DDoS-Schutz für Minecraft-Server und nutzten Mirai und mehrere davor entwickelte DDoS-Bots u. a., um von der Konkurrenz geschützte Server lahmzulegen. Die Frage wäre dann, wieso die Entwickler diesen Angriff in Mirai nicht vollständig implementiert haben.

Februar 2018: Neuer Flooding-Angriff über Memcached

Ende Februar 2018 wurden Flooding-Angriffe beobachtet, die bisher nicht in the Wild bekannt waren: Memcached-Amplification- oder Memcrashed-Angriffe. Über das Konzept wurde erstmals 2017 auf der Konferenz PowerOfCommunity (POC) berichtet.

Memcached dient dazu, beliebige Daten im Speicher eines Systems abzulegen, um die Zugriffe auf diese Daten zu beschleunigen, da sie dann nicht mehr von Festplatten oder SSDs gelesen werden müssen. Memcached wird z. B. eingesetzt, um das Datenbank-Backend von dynamischen Webseiten zu beschleunigen. Beim Memcrashed-Angriff wird eine Anfrage an einen Memcached-Server gesendet, der auf Anfragen beliebiger Server antwortet. Die Antwort des Servers wird durch eine gefälschte Senderadresse auf das Ziel geleitet, das von den eintreffenden Datenmengen überlastet wird. Am 28. Februar wurde GitHub Opfer eines solchen Angriffs, bei dem bis zu 1,35 Terabit pro Sekunde auf die GitHub-Server einschlugen. Tools zur Durchführung solcher Angriffe wurden kurz zuvor im Internet veröffentlicht.

So weit, so schlecht. Kommen wir zu der Frage, wie man sich vor DDoS-Angriffen schützen kann.

Beide Seiten der Medaille schützen!

Dabei gilt es, das Problem von zwei Seiten zu betrachten: An erster Stelle wird meist die Abwehr von DDoS-Angriffen auf die eigenen Systeme stehen. Genauso wichtig, meist aber leichter zu erreichen, ist jedoch der Schutz der eigenen Systeme vor der Beteiligung an DDoS-Angriffen. Und das beschränkt sich nicht darauf, die Infektion mit Schadsoftware zu verhindern. Wenn Sie z. B. einen DNS-Server betreiben, sollten Sie dafür sorgen, dass der nicht für DNS-Reflection- oder DNS-Amplification-Angriffe missbraucht werden kann. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat im Juli 2018 aufgrund der Zunahme entsprechender Angriffe einige Schutzmaßnahmen vorgeschlagen: ISPs sollten an ihren Netzübergängen die Manipulation der Absenderadresse in UDP-Paketen (IP-Spoofing) verhindern, DNS Caching Resolver sollten nur Anfragen aus dem eigenen Netz entgegennehmen und nicht als „Open Resolver“ arbeiten, und alle DNS-Server sollten auf auffälliges Verhalten hin überwacht werden, um im Fall eines Angriffs zeitnah einschreiten zu können. Genauso gilt es, andere für einen Missbrauch anfällige Systeme zu schützen. So müssen Sie z. B. sicherstellen, dass der Memcached-Server nicht aus dem Internet erreichbar ist und/oder nur auf erwünschte Anfragen antwortet.

Schutz vor den DDoS-Angriffen

Und damit kommen wir zum Schutz vor DDoS-Angriffen. Dafür gibt es laut BSI drei Möglichkeiten:

  1. Betrieb einer DDoS Mitigation Appliance
  2. Content Delivery Networks
  3. DDoS Mitigation as a Service

Auf die Idee, dass man das auch selbst implementieren könnte, ist man wohl nicht gekommen. Allerdings hätte eine eigene Lösung die gleichen Nachteile wie der Betrieb einer DDoS Mitigation Appliance: Wenn der Angriff die Leitung zum eigenen Rechenzentrum überlastet, ist er erfolgreich, egal wie viel Mühe sich die DDoS-Lösung im RZ gibt. Etwas besser sieht es aus, wenn die Appliance beim Upstreamprovider steht. Die aktuellen Angriffe könnten aber auch dessen Anbindung in die Knie zwingen.

Früher, als die Botnets noch deutlich kleiner waren, hätte man vielleicht sagen können „Wir sind nicht so extrem wichtig, wir sind nicht so beliebt etc., uns greift man nicht mit der Gewalt eines großen Botnets an, und mit den kleinen kommen wir klar“. Heute gilt das nicht mehr, denn heute gibt es im Grunde nur noch große Botnets. Und die lassen sich zum Teil kinderleicht bedienen, „Crime as a Service“-Provider stellen entsprechende Dienste samt komfortabler Weboberfläche bereit. Da reicht es schon, dass jemandem die Kommasetzung in Ihrer aktuellen Pressemitteilung missfällt und er es Ihnen mal so richtig zeigen will. Schon hat er einen Angriff zusammengeklickt, ein paar Euros investiert, und Ihr Server schwenkt die weiße Fahne.

Content Delivery Networks verteilen die Daten auf mehrere Server an mehreren Standorten, die meist über die ganze Welt verteilt sind. Ihr primärer Einsatzzweck ist und war die schnelle Bereitstellung von Daten wie Software einschließlich Updates und Multimediadaten. Aber auch vor DDoS-Angriffen schützt diese Verteilung: Statt eines einzelnen Servers müssen mehrere an mehreren Standorten lahmgelegt werden – und die sind zusätzlich natürlich vor DDoS-Angriffen geschützt.

„DDoS Mitigation as a Service“-Provider leiten den eingehenden Netzwerkverkehr über eigene Server, auf denen unerwünschte Requests etc. ausgefiltert werden. Das BSI hat Kriterien für die Auswahl so eines Dienstleisters definiert, um den Betreibern kritischer Infrastrukturen die Auswahl zu erleichtern. Nach der Prüfung der vollständigen Dokumentation der bereitgestellten Dienste und mehrstündigen Fachinterviews hat das BSI die folgenden Dienstleister als geeignet empfohlen:

  • Akamai
  • Arbor Networks
  • Deutsche Telekom
  • Link11
  • Myra Security
  • Vodafone

Das BSI liefert auch Hilfestellungen bei der Prävention und Abwehr von DDoS-Angriffen. Hier interessieren natürlich besonders die Maßnahmen zur Abwehr eines laufenden Angriffs. Diese umfassen

  • das Härten des Servers (um die Angriffe, wenn möglich, ins Leere laufen zu lassen),
  • die Filterung nach Quell- und Zieladressen (wobei bei den Quelladressen schnell die ganze Welt im Filter landet, weil die Bots der IoT-Botnets weit verteilt sind),
  • die Filterung nach bestimmten Kriterien (z. B. nach für den Angriff typischen HTTP-Headern) und
  • die Nutzung einer DDoS-Mitigation Appliance oder der Dienste eines DDoS-Mitigation-as-a-Service-Providers.

Für ISPs gibt es außerdem noch eine separate Anleitung, wie Sie Ihre Netze und damit die Systeme Ihrer Kunden schützen können.

DDoS-Schutz im Einsatz

Wenn Sie wissen möchten, wie die Abwehr eines DDoS-Angriffs in the Wild abläuft: Damian Menscher, Security Reliability Engineer bei Google, hat auf der Sicherheitskonferenz Enigma 2017 über die Abwehr von DDoS-Angriffen berichtet und dabei als Beispiel die Abwehr der Angriffe auf die Website von Brian Krebs beschrieben. Berichte darüber gibt es u. a. bei Brian Krebs: „How Google Took on Mirai, KrebsOnSecurity“ und Dan Goodin: „How Google fought back against a crippling IoT-powered botnet and won“.

Nachdem Google entschieden hatte, den Schutz von www.krebsonsecurity.com zu übernehmen, stand man erst einmal vor organisatorischen Problemen: Eine der wichtigsten Voraussetzungen für die Aufnahme in Project Shield besteht darin, dass die Person, die den Schutz beantragt, beweist, dass sie die Kontrolle über die betreffende Website hat. Da www.krebsonsecurity.com zu dem Zeitpunkt aber offline war, konnte Brian Krebs diese Anforderung nicht erfüllen. Verschärft wurde das Problem dadurch, dass die DNS-Einträge für www.krebsonsecurity.com gesperrt waren, um Domain-Hijacking zu verhindern. Entsprechende Versuche hatte es immer wieder gegeben, nun hinderte der Schutz aber Brian Krebs daran zu beweisen, dass er die Kontrolle über die Einträge hat. Daher musste sein Hoster helfen, was dadurch erschwert wurde, dass die Übernahme an einem Wochenende erfolgen sollte. Letztendlich wurden alle Probleme aber gelöst, und die Website von Brian Krebs war unter dem Schutzschild von Google wieder online.

Angriffe en masse

Danach dauerte es noch vierzehn Minuten, bis die DDoS-Angriffe weitergingen. Los ging es mit einer Flut von 130 Millionen SYN-Paketen pro Sekunde, kombiniert mit 60 Millionen RESETS pro Sekunde. Das reicht aus, um viele Websites lahmzulegen, im Vergleich zu Googles Kapazitäten war es aber nicht der Rede wert.

Ungefähr eine Minute später wechselte der Angriff zu einer Flut von 250 000 HTTP-Querys pro Sekunde. Da die von rund 145 000 unterschiedlichen IP-Adressen kamen war klar, dass das Mirai-Botnet der Übeltäter war. Da die Load Balancer anfangs nicht richtig konfiguriert waren, bekamen die Server etwas zu tun, aber das Versehen wurde zügig korrigiert.

Eine Stunde nach dem Start hatten die Angriffe sich zu einer 40-Gbps-TCP-Flood, einem 140-Gbps-DNS-Amplification-Angriff und einer 4-Mbps-SYN-ACK-Flood gesteigert. Vier Stunden nach dem Start begann ein größerer Angriff mit mehr als 450 000 HTTP-Queries pro Sekunde von rund 175 000 unterschiedlichen IP-Adressen, der aber auch noch keine Gefahr für www.krebsonsecurity.com oder Googles Ressourcen zu dessen Schutz darstellte.

Die stärksten Angriffe wurden in den ersten beiden Wochen beobachtet, danach war aber noch lange nicht Schluss. Und die Angreifer probierten immer mal wieder andere Angriffe aus, z. B. einen über WordPress Pingbacks, bei denen eine große Zahl Server simultan Pingbacks an www.krebsonsecurity.com schickten, um den Server zu überlasten. Was fehlschlug, da Google die Angriffe durch den User-Agent-Header WordPress pingback erkennen und blockieren konnte. Außerdem gab es Cache-Busting-Angriffe, alle möglichen Flooding-Angriffe usw.

Große Websites, kleine Sorgen – kleine Websites, große Sorgen

Beim Schutz von www.krebsonsecurity.com mussten die Google-Techniker feststellen, dass es ziemlich schwierig ist, eine kleine Website zu schützen. Bei großen Websites wie Googles Diensten kommt es auf ein paar tausend zusätzliche Anfragen nicht an, aber Brian Krebs’ Server konnte nur rund zwanzig Anfragen pro Sekunde verarbeiten. Ein Angriff mit bis zu 450 000 Anfragen wird dann zum Problem – was soll damit passieren?

Eine Möglichkeit besteht darin, den bösartigen Traffic zu begrenzen, aber dazu muss er erst einmal erkannt werden. Positiv macht sich dabei bemerkbar, dass gutartige Anfragen aus dem Cache beantwortet werden können, was den Originalserver entlastet. Und selbst wenn der Originalserver ausfällt, können die regulären Anfragen weiterhin aus dem Cache beantwortet werden, sodass der Ausfall nicht sichtbar wird. Und das gilt nicht nur für DDoS-Angriffe, sondern auch bei ganz normalen Problemen wie z. B. einem Stromausfall beim Hoster des Originalservers oder einem Hardwarefehler in diesem Server.

Ein Problem ist jedoch das Debugging dieser Konfiguration aus einem Originalserver, der die Daten bereitstellt, und Googles Shield-Servern, die die Daten im Cache bereithalten. Nach drei Monaten problemlosen Betriebs meldeten die Benutzer Fehler. Googles Techniker prüften die Shield-Server und fanden keinen Fehler, und auch Brian Krebs konnte auf dem Originalserver keinen Fehler finden. Ursache des Problems waren Konfigurationsfehler nach der Integration zusätzlicher virtueller Server.

Fazit

Für Botnets gibt es eine Art „natürliche Grenze“: Irgendwann haben sie alle IT-Systeme infiziert, die sie infizieren können, und danach können sie nicht mehr weiterwachsen. Bei normalen IT-Systemen sinkt dazu noch die Zahl potenzieller Opfer, wenn die ausgenutzten Schwachstellen behoben werden. Bei den Geräten des IoT sieht es da anders aus, für die gibt es kaum Updates – und selbst wenn, werden sie wohl eher selten installiert. Die IoT-Botnets dürften uns also noch einige Zeit erhalten bleiben. Und wenn das IoT wie vorausgesagt immer weiter wächst, werden auch die IoT-Botnets weiter wachsen können. Keine besonders schönen Aussichten, oder? Die einzigen, die sich darüber freuen werden, sind die Anbieter von DDoS-Abwehrdiensten.

Übrigens: Die Angriffe auf die Website von Brian Krebs begannen, nachdem er über die Verbindungen zwischen DDoS-Angriffen und DDoS-Abwehr-Anbietern berichtete. Und auch die Mirai-Entwickler boten einen DDoS-Schutz an und legten über DDoS-Angriffe die von der Konkurrenz geschützten Server lahm. Toll, was?

Dann hoffen wir mal, dass die IoT-Geräte in Zukunft sicherer werden und den Botnets dadurch der Lebensraum ausgeht.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -