zurück zur Übersicht

(Distributed) Denial of Service – wenn massenhaft Pakete an die Türe klopfen

Morgens halb 10 in Deutschland. Nein, diesmal nicht abends, wie dem aufmerksamen Leser der Cubespotter Artikelreihen sicherlich sofort auffällt. Digitale Poststelle des Unternehmens. Ein neues Paket ist angekommen. Na ja, nicht nur eines. Vielleicht auch zwei. Oder vielleicht auch… 176479646416402164714. Pro Minute. Kein Wunder, dass sich die armen Mitarbeiter bei dieser hohen Anzahl richtig ins Zeug legen müssen und die imaginären Schweißperlen der kleinen Kerlchen im Kabel nur so herumspritzen. Aber irgendwann heißt es: Genug ist einfach genug!!! Der erste Mitarbeiter steht kurz vor dem Zusammenbruch und streikt. Motiviert von der Entschlossenheit ihres Kollegen und gehetzt von dem nicht enden wollenden Strom neuer Pakete folgen die restlichen Mitarbeiter der Paketannahme und werfen sinnbildlich ebenfalls das Handtuch. Das Fließband steht, die benötigten Informationen können nicht mehr verarbeitet werden.

Also was tun, wenn sich die eigene digitale Poststelle im Streik (will sagen: Denial of Service (DoS)-Zustand) befindet und die Mitarbeiter einfach keine Kraft mehr besitzen, der Flut Herr zu werden? Und woher kommen eigentlich diese unzähligen, nicht mehr zu bewältigenden Pakete (wenn schon nicht als Retouré von einer vor Glück schreienden Kundin eines Online-Händlers? Oder als weiteres Versandobjekt eines Verkaufsgiganten, dessen Name sich an einer der griechischen Mythologie entsprungenen, für den Kampf gerüsteten Dame, anlehnt?)?

Denial of Service – der Albtraum jedes Unternehmens… und jeder Privatperson

Stellen Sie sich folgendes Szenario vor: Sie kommen morgens ganz entspannt zur Arbeit. Der Webserver, mit welchem die Kunden kommunizieren und die täglichen Bestellungen abgewickelt werden, läuft wie immer hervorragend und im Hintergrund hört man Dagobert Ducks Registrierkasse stetig klingeln. Doch plötzlich wird die Last des Servers immer größer. Die Lüfter der Klimaanlage im Serverraum springen an. Manche Bestellungen können nicht mehr abgewickelt werden. Die Last steigt und steigt, bis alle Ressourcen aufgebraucht sind und der Streik der Postmännchen beginnt – was einen Totalausfall des Geschäftsmodells bedeuten kann. Dieser Zustand entsteht beispielsweise aus einer nicht mehr prozessierbaren Anzahl an Datenpaketen, die durch einen DoS Angriff auf den Webserver geschossen werden. Eine Denial of Service Attacke definiert sich als ein Angriff auf die Verfügbarkeit von Netzwerkdiensten, z.B. Web-Server oder Internet-Services mit dem Ziel, die Erbringung des Services zu beeinträchtigen oder gar komplett zu sabotieren. Diese Pakete können von einer einzelnen oder (eher verbreitet) mehreren Quellen (Distributed Denial of Service, DDoS) stammen. Die folgende Abbildung stellt einen DDos Angriff graphisch dar:

 

Abbildung 1 – Abstraktes Prinzip eines DDos Angriffes (DDoS Survival Handbook, S.8)

 

Ein Angreifer steuert über einen Controller, z.B. einen C&C Server, mehrere Geräte, um den Angriff durchzuführen. Diese Geräte können Zombies in einem Botnet sein von und ohne Wissen des tatsächlichen Eigentümers diese Angriffe in Form von unzähligen Server Requests ausführen (an dieser Stelle möchte ich meinen geschätzten Lesern den Artikel Sind Sie schon ein Bot? von Kollegen Stephan Haslbeck ans Herz legen). Doch welche verschiedenen Angriffstypen von DoS-Attacken gibt es eigentlich? Was steckt technisch hinter dieser Bezeichnung?

Angriff auf Netzwerkressourcen

Das Prinzip einer DoS-Attacke bleibt generell immer dasselbe: Möglichst viele Netzwerkressourcen zu verbrauchen, um den Server oder das System an die Leistungsgrenze zu bringen und einen Ausfall zu verursachen. Dazu können mehrere Techniken zum Einsatz kommen:

Floods (Volumetric Attacks)

  • UDP-Flood: Das User Datagram Protocol ist ein verbindungsloses Protokoll, welches keinen Handshake Prozess für eine Session zwischen zwei Geräten benötigt, um eine Verbindung herzustellen. Für eine UDP-Flood werden keine expliziten Schwachstellen ausgenutzt, sondern das normale Netzwerkverhalten missbraucht. Eine extrem hohe Anzahl an UDP-Paketen wird an die unterschiedlichsten Ports des Zielsystems gesendet. Dem angegriffenen Server ist es nicht möglich, alle Anfragen zu bearbeiten und er verbraucht alle vorhandenen Ressourcen um mit ICMP „Destination Unreachable“ Paketen zu antworten. Dieses Paket bestätigt eigentlich nur, dass keine Applikation auf dem Zielport lauscht.
  • ICMP-Flood: Das Internet Control Message Protocol ist ein ebenfalls verbindungsloses Protokoll, welches normalerweise für IP Operations, sowie Diagnose und Fehlersuche verwendet wird. Dabei wird dasselbe Prinzip wie bei der UDP-Flood angewandt. Es wird eine Unmenge an ICMP-Paketen an das Zielsystem geleitet, welches durch das Prozessieren der Pakete und Beantworten der Anfragen überfordert ist und folglich den Service nicht weiter erbringen kann.
  • TCP SYN-Flood: Während des TCP Handshakes wird durch die Übereinkunft zweier Systeme eine Verbindung hergestellt. Während eines TCP SYN, oder vereinfacht SYN-Flood Angriffes, wird vom angreifenden Client (mit z.B. einer gefälschten IP Adresse) durch TCP-Requests mit dem SYN-Flag eine valide Anfrage für Ressourcen imitiert. Um jede dieser SYN Anfragen prozessieren zu können, werden explizit Ressourcen in Form von Threads und den zugewiesenen Buffern auf dem Zielsystem reserviert und somit die angefragte Verbindung vorbereitet.  Das Zielsystem antwortet mit einem SYN ACK-Paket, jedoch wird vom Client kein ACK-Paket zurückgesendet. Daher hält der Server die Verbindung für eine bestimmte Zeit aufrecht und sendet weitere SYN ACK-Pakete an denselben Client, bevor die Verbindung wieder geschlossen wird. Bei einer entsprechend hohen Anzahl an SYN –Requests ist es dem Server nicht möglich, die aktiven Verbindungen schnell genug zu terminieren, bevor neue Anfragen für weitere Verbindungsaufbauten angekommen sind. Als Ergebnis wird ein DoS Zustand herbeigeführt. Die folgende Abbildung stellt die TCP SYN-Flood schematisch dar:

Abbildung 2 – Darstellung der TCP SYN-Flood Methodik (DDoS Survival Handbook, S.30)

 

  • HTTP-Flood: Diese Methode ist die am weitesten verbreitete Technik, um Applikationen zu sabotieren. Eine nicht mehr prozessierbare Anzahl an HTTP GET/POST Requests wird an den Webserver gesendet. Legitime Anfragen können somit nicht mehr bearbeitet werden. Die folgende Abbildung stellt einen HTTP-Flood Angriff dar:

Abbildung 3 – Darstellung der HTTP-Flood Methodik (DDoS Survival Handbook, S.34)

 

  • DNS-Flood: DNS-Flooding entspricht demselben Prinzip aller Flood Angriffe, jedoch über das DNS Protokoll.

Weitere Beispiele für Flood-Angriffe sind die TCP RST-Attack oder TCP PSH+ACK-Flood.

Low and Slow Attacks

Im Gegensatz zu Flood-Angriffen wird bei diesem Konzept kein hohes Traffic-Volumen benötigt. Es werden Designfehler und -schwachstellen mit sehr geringem, aber schadhaftem Traffic ausgenutzt. Ein einzelnes Angriffssystem ist für diese Technik oft ausreichend. Diese Angriffe zielen meistens auf Applikationen ab und sind sehr schwer durch die normale Traffic-Rate zu erkennen. Ein TCP-Handshake ist bereits vollzogen und eine Verbindung wurde bereits geöffnet, daher ist diese Methode nur schwer als DoS-Angriff zu detektieren.

  • Slow HTTP GET Request: Das Prinzip für diesen Angriff beruht auf einer Vielzahl von offenen Verbindungen, wodurch keine Ressourcen für legitime Anfragen mehr zur Verfügung stehen. Der Angreifer sendet unvollständige HTTP GET Requests an den Server, welcher einen Thread für jede Verbindung öffnet und auf weitere Daten wartet. Währenddessen werden weitere HTTP Header Daten in langsamen Intervallen gesendet, um die Verbindung offen zu halten. Die Anzahl der aktiven Verbindung übersteigt schlussendlich den limitierten Platz im Connection Table und der Server baut keine weiteren Verbindung mehr auf, was in einem DoS-Status resultiert.
  • Slow HTTP POST Request: In diesem Fall werden HTTP POST Requests über bereitgestellte Web-Formulare an den Web Server gesendet. Diese Requests werden nicht wie normal in einem möglichst schnellen Zeitraum gesendet, sondern werden zerstückelt, Byte per Byte, in großen und regelmäßigen Zeitintervallen übertragen. Die aktive Verbindung bleibt bestehen, da der Server auf die vollständige Übertragung der Daten warten muss. Dieser Vorgang wird mehrfach wiederholt, bis das Zielsystem keine weiteren Requests prozessieren kann und in einen DoS-Status übergeht.

Weitere Techniken der ‚Low and Slow‘-Methodik sind als ‚Regular Expression DoS‘ und als ‚Hash Collisions DoS attacks‘ bekannt. Des Weiteren können diese Methoden mit Amplification-Techniken kombiniert werden, um die Wirksamkeit zu steigern und die vom Angreifer erwünschten Auswirkungen mit sehr hoher Wahrscheinlichkeit sicherzustellen. Beispiele für Amplification-Angriffe sind die Smurf Attack (ICMP Amplification) oder die Fraggle Attack (UDP Amplification). Ebenfalls beliebt sind das DNS-Protokoll sowie das NTP für einen Amplification-Angriff.

Neue Tricks für den Klassiker

Eine neuartige Technik eines DDos Angriffes wurde erst kürzlich von Security Researcher des Unternehmens Imperva entdeckt. Dabei werden Schwachstellen des Universal Plug and Play (UPnP) Protokolls ausgenutzt. Dieses Protokoll wird meistens im LAN verwendet. Router, Drucker, Client-Systeme etc. können sich über dieses Protokoll auffinden (UDP Port 1900) und über einen TCP Port anschließend miteinander kommunizieren. Jedoch bringt das Protokol eine Reihe bekannter Schwachstellen mit sich. Die Standardeinstellungen ermöglichen es externen Angreifern eine Verbindung herzustellen, da kein Authentifizierungsmechanismus vorhanden ist. Zusätzlich sind einige Code Execution-Schwachstellen vorhanden. Normalerweise können DDoS Angriffe nach der Identifizierung bestimmter Ports geblockt werden. Durch das allgemeine Design des UPnP Protokolls ist es Angreifern problemlos möglich, den verwendeten Port zu verschleiern. Folglich ist diese Attacke schwer abzuwehren. Den kompletten Proof-of-Concept dieser neuartigen Methode mit ausführlichen Details finden Sie hier.

(D)DoS-Angriffe auf dem Vormarsch

Denial of Service Angriffe schienen durch die Gründung des Hacktivismus durch spezielle Tools wie Low/High Orbit Ion Cannon wieder in Mode gekommen zu sein. Mittlerweile rasen diese Angriffsvolumina von Rekord zu Rekord. Niemand bleibt verschont. Auch Privatpersonen werden neben den Unternehmenswebseiten angegriffen. Das aus IoT-Devices bestehende Botnetz Mirai, welches die Geräte über Telnet und Standardpasswörter kompromittierte, zwang 2016 selbst professionelle Anbieter von DDoS-Protection-Lösungen, in diesem Fall Akamai, in die Knie. Dieses Novum geschah durch einen Angriff mit einem Traffic von 620 Gigabit pro Sekunde auf den Blog des Journalisten Brian Krebs. Dieses Szenario war erst der Anfang einer sehr beunruhigenden Entwicklung. Im selben Jahr wurde der französische Hoster OVH mit DDoS-Attacken mit Rekordwerten von bis zu 1,1 Terabit die Sekunde überzogen. Auch das Entwickler-Portal GitHub wurde Anfang dieses Jahres mit einer Last von 1,3 Terabit pro Sekunde torpediert.

Durch die steigende Vernetzung des Alltags mit IoT-Devices und der offensichtlichen Tatsache, dass bei diesen Geräten Kosten durch fehlende Security-Mechanismen gespart werden, ist es absehbar, dass diese Rekorde problemlos in naher Zukunft übertroffen werden.

Na dann: Feuer frei!

 


Quellen/Links:

https://www.heise.de/security/meldung/Akamai-kapituliert-vor-DDoS-Angriff-auf-Security-Blogger-3330281.html

https://www.wired.com/story/github-ddos-memcached/

https://www.heise.de/security/meldung/Rekord-DDoS-Attacke-mit-1-1-Terabit-pro-Sekunde-gesichtet-3336494.html

https://www.imperva.com/blog/2018/05/new-ddos-attack-method-demands-a-fresh-approach-to-amplification-assault-mitigation/

https://blogs.msdn.microsoft.com/larryosterman/2007/10/16/larry-and-the-ping-of-death/

Radware – DDoS Survival Handbook

Bild: ©GettyImages/Gearstd

Schreibe einen Kommentar

Wir nehmen Datenschutz ernst! Deshalb informieren wir Sie, was mit Ihren Daten geschieht:

  • Daten aus Formularen und Webseiten-Tracking können von uns zur Analyse gespeichert werden
  • Die Daten können zur Optimierung der Webseite ausgewertet werden. Das ermöglicht es uns, besser zu verstehen, wo das Interesse unserer Besucher liegt. Wir benutzen primär Hubspot für dieses Tracking (mehr dazu finden Sie in der Erklärung auf unserer Datenschutzseite, siehe unten)
  • Wir geben Ihre Daten nicht an Dritte weiter. Im Rahmen von Veranstaltungen, an denen Sie teilnehmen möchten, kann es nötig sein, dass Ihre Daten an Vertragspartner übermittelt werden.
  • Sie haben jederzeit ein Recht auf die Herausgabe, Berichtigung oder Löschung persönlicher Daten.
  • Sie können Ihre Einwilligung, mit uns in Kontakt zu treten, jederzeit mit sofortiger Wirkung widerrufen.

Weitere Details dazu, was wir mit den Daten tun und nicht tun finden Sie auf unserer Datenschutzseite, oder schreiben Sie mich bei Fragen direkt an!

Felix Möckel
Data Protection Officer