Der Kern dieser Arbeit besteht aus einer Case Study in Form eines lokalen Netzwerks, in dem ein Mirai-Botnetz mit IP-Kameras konfiguriert wird. Hierbei wird das Netzwerk mit Wireshark untersucht und das Ergebnis hinsichtlich der Umsetzung und Schwierigkeiten zusammengefasst. Im Vorfeld dieser Untersuchung werden die benötigten Grundlagen zu DDoS-Attacken, die zum Einsatz kommenden Kommunikationsprotokolle und die Definition des Internet der Dinge beschrieben. Die Thesis endet mit einem abrundenden Fazit, welches sich mit den zuvor aufgestellten Thesen und den neu erlangten Erkenntnissen auseinandersetzt.
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
1.1 Zielsetzung
1.2 Aufbau der Arbeit
2 Grundlagen
2.1 Charakteristik einer DDoS-Attacke
2.2 Kommunikationsprotokolle
2.2.1 OSI-und TCP/IP-Modell
2.2.2 Internet Protocol (IP)
2.2.3 Transmission Control Protocol (TCP)
2.2.4 TCP 3-Wege Handshake
2.2.5 User Datagram Protocol (UDP)
2.2.6 Internet Control Message Protocol (ICMP)
2.3 Aufbau und Architektur von DDoS-Attacken
2.3.1 Agent-Handler Model
2.3.2 Internet Relay Chat Model
2.4 DDoS-Angriffstypen
2.4.1 Schichten-Spezifische DDoS-Attacken
2.4.2 Direkte und reflektierende DDoS-Attacken
2.4.3 Direkte und indirekte DDoS-Attacken
2.4.4 Volumenabhängige DDoS-Attacken
2.4.5 Übertragungsratenabhängige DDoS-Attacken
2.5 Internet der Dinge (IoT) und DDoS
2.6 Nennenswerte DDoS-Attacken in der Vergangenheit
2.7 Maßnahmen gegen DDoS-Attacken
3 Grundlagen zu Mirai (Malware)
3.1 Mirai-Attacken in der Vergangenheit
3.2 Analyse des Quellcodes
4 Case Study - Mirai Botnetz
4.1 Netzwerktopologie der Testumgebung
4.2 Analyse der verwendeten IoT-Geräte
4.2.1 Port-Analyse der IP-Kameras
4.2.2 Zugriff per HTTP
4.2.3 Zugriff per Telnet
4.2.4 Architektur und Betriebssystem
4.2.5 Sicherheitsaspekte
4.3 Konfiguration des DNS/DHCP-Servers
4.4 Konfiguration des Mirai Servers
4.4.1 Konfiguration apache2 und tftp
4.4.2 Konfiguration Mirai-CNC
4.4.2.1 Update und Installation der benötigten Pakete
4.4.2.2 Installation und Konfiguration des Cross-Compilers .
4.4.2.3 Herunterladen der Mirai-Source-Dateien
4.4.2.4 MySQL-Datenbank erstellen und User anlegen
4.4.2.5 Source-Files anpassen
4.4.2.6 Mirai Source kompilieren (Debug)
4.4.2.7 Mirai Source kompilieren (Release)
4.4.2.8 Webserver konfigurieren
4.4.2.9 FTP-Server konfigurieren
4.4.3 Konfiguration Mirai-Loader
4.5 Inbetriebname des Mirai-CNC und Mirai-ScanListener
4.5.1 Mirai-CNC
4.5.2 Mirai-Scanlistener
4.6 Kompromittierung der IP-Kameras mit dem Mirai-Loader
4.7 Analyse der Mirai-DDoS-Attacken
4.7.1 UDP-Flood
4.7.2 SYN-Flood
4.7.3 ACK-Flood
4.7.4 TCP-Stomp-Flood
4.7.5 UDP-Flood (plain)
4.7.6 Valve Gameserver-Flood
4.7.7 DNS-Flood
4.7.8 GREIP-Flood
4.7.9 GREETH-Flood
4.7.10 HTTP-Flood
4.8 Schwierigkeiten und Probleme
4.9 Hack me, if you can!
4.10 Ergebnis der Case Study
5 Fazit
Literaturverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
1 Verteilung der DDoS-Attacken nach Typen im dritten und vierten Quartal 2016
2 Darstellung des OSI- und TCP/IP-Modells
3 Darstellung des IP-Headers
4 Darstellung des TCP-Headers
5 Darstellung des 3-Wege-Handshakes
6 Darstellung des UDP-Headers
7 Darstellung des Agent-Handler-Modells
8 Darstellung des IRC-Modells
9 Darstellung direkte DDoS-Attacken
10 Darstellung reflektierende DDoS-Attacken
11 Prognose der vernetzten IoT-Geräte pro Person
12 Anstieg der DDoS-Angriffsstärke von 2004-2015
13 Mirai Big-Picture
14 Netzwerktopologie des Testaufbaus
15 nmap-Scan der IP-Kameras
16 Webinterface-Login per HTTP (IPCAM2)
17 Zugriff per Telnet (IPCAM1)
18 Download und Installation des Cross-Compilers
19 Mirai-Verzeichnisstruktur
20 SQL-Befehle zum Anlegen der DB und Tabellen
21 Anpassungen in der/mirai/cnc/main.go
22 Anpassungen in der /mirai/bot/table.c
23 Anpassungen in der /mirai/bot/resolve.c
24 Shellskript für das Downloaden der Schadsoftware per HTTP
25 Shellskript für das Downloaden der Schadsoftware per FTP
26 Anpassungen in der /loader/src/main.c
27 Anpassungen in der /dlr/main.c
28 Zugriff auf die CNC-Administrationsoberfläche
29 Loader-Login auf IPCAM1 via Telnet
30 Lookup der laufenden Prozesse der Kamera
31 Installation der Schadsoftware
32 Netzwerkscan nach neuen Opfern - IPCAM1
33 Zur Verfügung stehende Mirai-Attacken
34 Initiierung der UPD-Flood Attack über die CNC-Adminoberfläche
35 Wireshark-Screenshot des UDP-Flood Netzwerkverkehrs
36 Initiierung der SYN-Flood Attacke über die CNC-Adminoberfläche
37 Wireshark-Screenshot des SYN-Flood Netzwerkverkehrs
38 Initiierung der ACK-Flood Attacke über die CNC-Adminoberfläche
39 Wireshark-Screenshot des ACK-Flood Netzwerkverkehrs
40 Initiierung der TCP-Stomp-Attacke über die CNC-Adminoberfläche
41 Initiierung der UDP-Flood (plain) Attack über die CNC-Adminoberfläche
42 Wireshark-Screenshot des UDP-Flood (plain) Netzwerkverkehrs
43 Initiierung der UDP-Flood (vse) Attack über die CNC-Adminoberfläche
44 Wireshark-Screenshot des UDP-Flood (vse) Netzwerkverkehrs
45 Initiierung der DNS-Flood Attacke über die CNC-Adminoberfläche
46 Wireshark-Screenshot des DNS-Flood Netzwerkverkehrs
47 Initiierung der GREIP-Attacke über die CNC-Adminoberfläche
48 Wireshark-Screenshot des GREIP Netzwerkverkehrs
49 Initiierung der GREETH-Attacke über die CNC-Adminoberfläche
50 Wireshark-Screenshot des GREETH Netzwerkverkehrs
51 Initiierung der HTTP-Flood Attacke über die CNC-Adminoberfläche
52 Wireshark-Screenshot des Http-Flood Netzwerkverkehrs
Tabellenverzeichnis
1 DNS- und DHCP-Konfiguration
1 Einleitung
Im letzten Quartal des Jahres 2016 ging das Thema „DDoS-Attacken“ durch die Fachpresse und sorgte in der Öffentlichkeit und insbesondere bei Global Playern wie Netflix, Google und Dyn für Unruhe[1]. Die Problematik von DDoS-Angriffen ist zwar seit vielen Jahren ein bekanntes Problem und stellt Sicherheitsforscher vor große Herausforderungen. In Zeiten, in denen immer mehr Kühlschränke, Babyphone und Überwachungskameras über das Internet kommunizieren können, öffnen sich neue Angriffsziele für Hacker, die nur schwierig zu bekämpfen sind. Mangelndes Sicherheitsbewusstsein beim Endverbraucher, schlecht programmierte Software, ausbleibende Update-Mechanismen, fehlende Sicherheitskonzepte und nicht änderbare Passwörter haben aufgezeigt, dass so genannte „Internet of Things“-Geräte ein dankbares Angriffsziel für Kriminelle darstellen. So kam es, dass im 4. Quartal 2016 ein Botnetz Namens Mirai (Japanisch für Zukunft) auf sich aufmerksam machte[2]. Der Name des Botnetz ist vermutlich auf die Anime-TV-Serie „Mirai Nikki“ zurückzuführen, die laut der Homepage „krebsonsecu- rity.com“ offensichtlich mit dem Autor in Verbindung steht[3]. Mirai legte seinen Fokus darauf, tausende IoT-Geräte zu kompromittieren und in ein Botnetz aufzunehmen. Daraus resultierten DDoS-Angriffe mit stärken > 1Tb/s, die den DNS-Anbieter Dyn am 21.10.2016 an der Ostküste der USA trafen. Kunden wie z.B. Netflix, Amazon und Google konnten dadurch zeitweise ihre Angebote nicht online anbieten. Am 30.09.2016 veröffentlichte der Autor von Mirai zudem den Source-Code und eine Anleitung auf der Internetseite des Hackerforums „hackforums.net“. Grund hierfür waren seine erfolgreichen Tests und die Tatsache, dass er genug Geld damit verdient hatte. Viele Nachahmer missbrauchten diese Programme fortan und sorgten zusätzlich für Probleme im Internet. Die aktuelle Brisanz dieses Themas ist der Grund, dass sich diese Bachelorarbeit mit dem Thema „Moderne DDoS-Attacken“ auf das Mirai-Botnetz und die Analyse der dabei verwendeten IoT-Geräte konzentriert.
1.1 Zielsetzung
Die zentrale These dieser Abschlussarbeit ist die Annahme, dass es für einen ambitionierten Informatiker möglich ist, ein Mirai-Botnetz in einer Case Study aufzubauen und DDoS-Attacken durchzuführen. Mit Hilfe dieser Untersuchung soll die Funktionsweise des Mirai-Botnetzes, die Sicherheitsaspekte von IoT-Geräten und Maßnahmen gegen DDoS-Angriffe erörtert werden.
1.2 Aufbau der Arbeit
Der Kern dieser Arbeit besteht aus einer Case Study in Form eines lokalen Netzwerks, in dem ein Mirai-Botnetz mit IP-Kameras konfiguriert wird. Hierbei wird das Netzwerk mir Wireshark untersucht und das Ergebnis hinsichtlich der Umsetzung und Schwierigkeiten zusammengefasst4. Im Vorfeld dieser Untersuchung werden die benötigten Grundlagen zu DDoS-Attacken, die zum Einsatz kommenden Kommunikationsprotokolle und die Definition des Internet der Dinge beschrieben. Die Thesis endet mit einem abrundenden Fazit, welches sich mit den zuvor aufgestellten Thesen und den neu erlangten Erkenntnissen auseinandersetzt.
2 Grundlagen
In diesem Kapitel wird der Fokus zunächst auf die Charakteristik eines DDoS-Angriffs gelegt. Nachfolgend werden die am häufigsten für DDoS-Angriffe verwendeten Kommunikationsprotokolle anhand des OSI- und TCP/IP-Modells beschrieben. Zu diesen Protokollen gehören das Internet Protocol (IP), das Transmission Control Protocol (TCP), das User Datagram Protocol (UDP) und das Internet Control Message Protocol (ICMP). Des Weiteren erläutert der Autor den Aufbau und verschiedene Architekturen von DDoS- Attacken, gefolgt von der Definition verschiedener Angriffstypen, die je nach Motivation des Angreifers Verwendung finden. Abschließend folgt eine Übersicht von nennenswerten DDoS-Angriffen in der Vergangenheit und die Betrachtung von Gegenmaßnahmen. Die in diesem Kapitel erörterten Hintergrundinformationen dienen als Grundlagen für die folgend beschriebene Case Study.
2.1 Charakteristik einer DDoS-Attacke
DDoS ist eine koordinierte Attacke, die für ihren Angriff eine große Anzahl an kompromittierten Computern verwendet. Zu Beginn untersucht der Hacker mehrere Netzwerke nach potentiell verwundbaren Maschinen. Ziel ist es, Malware aufzuspielen und die Hosts aus der Ferne zu kontrollieren[4]. An einem späteren Zeitpunkt gibt der Angreifer seinen infizierten Maschinen ohne deren Kenntnis den Befehl, Pakete an ein bestimmtes Angriffsziel zu senden. Die Angriffsziele befinden sich im Regelfall in einem anderen Netzwerk als die kompromittierten Hosts. Abhängig von der Intensität des Angriffs kann der Angreifer durch eine solche Attacke großen Schaden im Netzwerk seiner Opfer anrichten. Ist es dem Angreifer im Vorfeld gelungen, eine Vielzahl von Maschinen zu kompromittieren und fernzusteuern, kann er ein Netzwerk oder einen Webserver in kürzester Zeit lahm legen. Exemplarisch für solche Angriffe steht zum Beispiel SYN-Flood, Smurf oder Fraggle[5]. Abbildung 1 gibt Auskunft über die am meisten verwendeten AttackenArten. Dabei fällt auf, dass TCP, SYN, HTTP, GET, UDP, und ICMP-Flooding am häufigsten verwendet werden. DDoS-Attacken sind sehr gefährlich und können Netzwerke in kürzester Zeit lahm legen. Im Allgemeinen baut der Angreifer ein Netzwerk aus kompromittierten Hosts auf, um DDoS-Attacken auszuführen und sicherheitsrelevante Infor mationen zu erlangen. Ursachen, warum es zu DDoS-Attacken kommt, sind unter anderem die hohe gegenseitige Abhängigkeit in der Internetsicherheit und die bestehende Limitierung von Internetressourcen. Des weiteren verwendet das Internet sehr einfache Routing-Prinzipien. Ein Schiefstand im Design und der Geschwindigkeit zwischen Core- und Edgenetzwerken ist dadurch alltäglich gegeben. Zusätzlich ist das Netzwerkmanagement oftmals schlecht durchdacht. Unter anderem sind es diese Gegebenheiten, die es Angreifern möglich machen, DDoS-Attacken in der vorhanden Internet-Infrastruktur durchzuführen. Angriffsziele sind Router, Links, Firewalls und Abwehrsysteme, Netzwerkinfrastrukturen, Betriebssysteme und Anwendungen der Opfer sowie bestehende Kommunikationsverbindungen[6].
Abbildung 1: Verteilung der DDoS-Attacken nach Typen dritten und vierten Quartal 2016
2.2 Kommunikationsprotokolle
Hacker nutzen erfolgreich die existierenden Internet-Kommunikationsprotokolle, um DDoS-Attacken durchzuführen. Demnach ist es wichtig, auf deren fundamentalen Eigenschaften und Konzepte einzugehen, um die Denkweise der Hacker zu verstehen. Bei der Kommunikation zwischen Internetanwendungen und Geräten kommen verschiedene Internetprotokolle zum Einsatz. Diese Thesis beschränkt sich auf die Betrachtung der weitverbreiteten Protokolle TCP, UDP, und ICMP, die laut Analysen und Statistiken sehr oft für DDoS-Attacken verwendet werden[7].
2.2.1 OSI- und TCP/IP-Modell
Schon in den 70-ziger Jahren wurde von der ISO das OSI-Modell entwickelt9. Dadurch wurden die einzelnen Kommunikationssysteme in Form eines Schichtenmodels charakterisiert und standardisiert. Das veröffentlichte OSI-Schichtenmodell ist in 7 Schichten aufgeteilt. Die Schichten bestehen aus Protokollen und Diensten. Die physikalische Schicht (1) definiert die physischen Eigenschaften der Übertragungswege. Die Sicherungsschicht (2) sorgt für die zuverlässige Übertragung der Daten über physische Verbindungen. Die Netzwerkschicht (3) verwaltet die Verbindungen zwischen Rechnern im Netz für höhere Schichten. Die Transportschicht (4) garantiert die fehlerfreie Datenübertragung durch Fehlererkennung und -korrektur. Die Kommunikationsschicht (5) verwaltet die Verbindungen zwischen den Anwendungen. Die Darstellungsschicht (6) standardisiert das Format der Daten auf dem Netz und die Anwendungsschicht (7) besteht aus den Anwendungen, mit denen man das Netz nutzen kann.
Abbildung in dieser Leseprobe nicht enthalten
Quelle: In Anlehnung an: tcp-ip-info.de (2004) Abbildung 2: Darstellung des OSI- und TCP/IP-Modells
Zusätzlich dazu wurde außerdem ein weiteres Modell veröffentlicht. Das TCP/IPKommunikationsmodell besteht im Gegensatz zum vorher beschriebenen OSI- Referenzmodell aus vier Schichten. Schicht eins und zwei sowie Schicht fünf bis sieben wurden beim TCP/IP-Kommunikationsmodell in einer Schicht zusammengefasst. Die Netzwerkzugangsschicht (1) regelt den Zugriff auf das Übertragungsmedium und stellt die physikalische Adressierung bereit. Die Internetschicht (2) bietet Dienste zur Wegwahl (Routing) und der logischen, hierarchischen Adressierung an. Die Transportschicht (3) regelt den Verbindungsaufbau, das Verbindungsmanagement sowie den geregelten Verbindungsabbau. Die Anwendungsschicht (4) stellt Netzwerkdienste zur Verfügung und ist mit Schicht fünf bis sieben des OSI-Referenzmodells gleichzusetzen[8]. Wie in Abbildung 2 verdeutlicht, soll das TCP/IP-Kommunikationsmodell das OSI-Referenzmodell einfacher und verständlicher darstellen.
2.2.2 Internet Protocol (IP)
Das im RFC 791 festgehaltene Internetprotokoll ist ein weit verbreitetes Netzwerkprotokoll, welches einen paketvermittelnden, verbindungslosen Dienst zur Verfügung stellt. Der Empfang von Paketen wird dadurch am Zielsystem nicht bestätigt. Es ist ein sehr wichtiger Bestandteil der Netzwerkschicht im OSI sowie der Internetschicht im TCP/IP -Modell, wo TCP, UDP und ICMP-Nutzdaten als IP-Paket bzw. Datagramm übertragen werden[9]. Die maximale Größe dieser Pakete beträgt 64 kByte, wobei je nach Infrastruktur eine kleinere Paketgröße üblich ist[10]. IP-Pakete werden unabhängig voneinander zur gewünschten Zieladresse über mehrere Zwischenstationen geroutet. Die Reihenfolge, in denen die Pakete ihr Ziel erreichen, ist undefiniert verschieden[11]. Der Aufbau des IP-Pakets setzt sich aus einem Header und Nutzdaten zusammen. Der Header des Pakets ermöglicht das zielgerichtete Routing und beinhaltet alle benötigten Informationen zum Zustellen des Pakets. Aus Abbildung 3 kann der Aufbau des IP-Headers nachvollzogen werden.
Abbildung in dieser Leseprobe nicht enthalten
Quelle: In Anlehnung an: Tanenbaum (2010), Seite 439 Abbildung 3: Darstellung des IP-Headers
Die einzelnen Felder des IP-Headers, sind nachfolgend beschrieben14:
- Version:
Die Version des IP-Protokolls.
- Headerlänge:
Definiert die Länge des IP-Headers einschließlich optionaler Felder.
- Type of Service:
Genutzt für die Markierung von Paketen für die Zuordnung unterschiedlicher Grade von Quality-of-Service (QoS).
- Paketlänge:
Beschreibt die Länge des IP-Pakets einschließlich Daten.
- Identifikation:
Wird vom Fragmentierungsprozess genutzt. Alle Fragmente des Originalpakets haben dieselbe Identifikation.
- Flags:
Drei vom IP-Fragmentierungsprozess genutzte Bits.
- Fragment-Offset:
Eine Nummer, die den Hosts hilft, fragmentierte Pakete wieder zum Originalpaket zusammenzusetzen.
- Time to Live:
Ein Wert, der zur Verhinderung von Routing-Schleifen genutzt wird.
- Protokoll:
Identifiziert den Inhalt des Datenteils des IP-Pakets. Protokoll-Nr.
- Header-Prüfsumme:
Speichert einen Frame-Check-Sequence-(FCS-)Wert, mit dem festgestellt werden kann, ob es einen Bit-Fehler im IP-Header gibt.
- Quell-IP-Adresse:
Die 32-Bit-IP-Adresse des Paketsenders.
- Ziel-IP-Adresse:
Die 32-Bit-IP-Adresse des Paketempfängers.
- Optionen und Füllbits:
Das optionale Optionsfeld des IP-Headers enthält hauptsächlich Informationen zu Routing-, Debugging-, Statistik- und Sicherheitsfunktionen. Es ist immer in 32 Bit aufgeteilt und wird bei Bedarf mit Nullen aufgefüllt.
2.2.3 Transmission Control Protocol (TCP)
Das im RFC 793 definierte TCP verwendet die Netzwerkschicht, um mit Hilfe des IP Endpunkte zu erreichen[12]. Das TCP bildet eine Ende-zu-Ende Verbindung, die eine beidseitige Kommunikation zwischen zwei Endpunkten zulässt und den Austausch von Daten ermöglicht. TCP ist ein verbindungsorientiertes und durchaus zuverlässiges Protokoll, das bevor es Daten zwischen Anwendungen über das Netzwerk austauscht, eine erfolgreich aufgebaute Verbindung bereitstellt (siehe Kapitel TCP 3-Wege Handshake)[13]. Bekannte Applikationen hierfür sind zum Beispiel FTP, Telnet, SSH und HTTP. Aus Abbildung 4 geht der Aufbau des TCP-Header hervor.
Abbildung in dieser Leseprobe nicht enthalten
Quelle: In Anlehnung an: Tanenbaum (2010), Seite 557 Abbildung 4: Darstellung des TCP-Headers
Nachfolgend sind die Felder des TCP-Headers erläutert17:
- Quell-Port:
Die Port-Nummer auf der Senderseite.
- Ziel-Port:
Die Port-Nummer auf der Empfängerseite.
- Sequenznummer:
Die Sequenznummer des ersten Datenoktetts des TCP-Pakets oder die Initialisierungssequenznummer, falls das SYN-Flag gesetzt ist. Dient nach der Datenübertragung zur Sortierung der TCP-Segmente.
- Acknowledgment-Nummer:
Gibt die Sequenznummer an, die der Empfänger des TCP-Segments als Nächstes erwartet. Nur gültig mit gesetztem ACK-Flag.
- Headerlänge:
Die Länge des TCP-Headers in 32-Bit-Blöcken. Nutzdaten (die Payload) werden nicht mit gezählt.
- Reserviert:
Wird nicht verwendet und muss Null sein.
- Flags:
Zweistellige Variablen, die mögliche Zustände beschreiben, z. B. das URG- oder das ACK-Flag.
- Windows:
Die Anzahl der Datenoktette, beginnend bei dem durch das Acknowledgment-Feld indizierten Datenoktett, die der Sender des Pakets bereit ist zu empfangen.
- Prüfsumme:
Dient zur Erkennung von Übertragungsfehlern.
- Urgent-Pointer:
Gibt zusammen mit der Sequenznummer die genaue Position der Urgent-Daten im Datenstrom an. Nur gültig mit gesetztem URG-Flag.
- Optionen und Füllbits:
Dieses Feld beinhaltet optionale Informationen. Um die 32-Bit-Grenze einzuhalten wird das Options-Feld mit Nullen aufgefüllt.
- Daten:
Die Nutzdaten.
2.2.4 TCP 3-Wege Handshake
Der TCP-Verbindungsaufbau erfolgt nach einem festgelegten Schema über einen so genannten 3-Wege Handshake (siehe Abb. 5)18. Zuerst schickt der Client eine Verbindungsanforderung mit gesetztem SYN-Flag (synchronize) und Sequenznummer x für die gewünschte Anwendung an den Server. Die Sequenznummer ist hierbei wichtig, um eine vollständige Übertragung in der richtigen Reihenfolge sicherzustellen. Der Client signalisiert dem Server, dass er eine Verbindung zu ihm aufbauen möchte. Nachdem der Client den Verbindungswunsch initiiert hat, antwortet der Server mit einem SYN/ACKPaket, indem das SYN und ACK-Flag (acknowledge) im TCP-Header gesetzt und die Acknowledgement-Nummer = x+1 ist, dass eine Verbindung aufgebaut werden kann.
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Entnommen aus: wikimedia.org (2010) Abbildung 5: Darstellung des 3-Wege-Handshakes
Zusätzlich übermittelt der Server die Startsequenznummer y, die unabhängig vom Host zufällig gewählt wird. Darauf antwortet der Client wiederum mit einem eigenen ACK-
Paket, mit der Acknowledge-Nummer y+1 und der Sequenznummer x+1, um den Empfang des SYN/ACK-Pakets des Servers zu bestätigen. Danach ist die Verbindung aufgebaut und man kann ihnen nicht mehr ansehen, wer Client oder Server ist[14]. Viele DDoS- Attacken verwenden TCP-Header Flags (RST, SYN, PSH), um einen Buffer-Over-Flow beim Empfänger (Angriffsziel) herbeizuführen. Dies wird durch die Initiierung von halboffenen Verbindungen oder Resets herbeigeführt und bringt die serverseitigen Applikation zum Absturz.
2.2.5 User Datagram Protocol (UDP)
Das User Datagram Protocol ist im Gegensatz zu TCP ein verbindungsloses Protokoll, welches im RFC 768 definiert ist[15]. Der Vorteil von UDP gegenüber TCP liegt im vergleichbar geringerem Protokoll-Overhead. Dadurch ist UDP auch schneller, bietet aber keinerlei Zuverlässigkeitsmaßnahmen. Dies bedeutet, dass die Daten ungesichert, ohne die Bestätigung über den Erhalt der Daten des Empfängers, versendet werden. Gehen Daten dabei unterwegs verloren, müssen sich Protokolle anderer Schichten darum bemühen, die Daten erneut zu erhalten[16]. Typische Einsatzgebiete für UDP sind zum Beispiel Audio- und Videostreamingdienste sowie VoIP und Videokonferenzen. Der UDP-Header ist wie folgt aufgebaut (siehe Abbildung 6).
Abbildung in dieser Leseprobe nicht enthalten
Quelle: In Anlehnung an: Tanenbaum (2010), Seite 542 Abbildung 6: Darstellung des UDP-Headers
Die nachfolgende Aufzählung gibt Aufschluss über die einzelnen Felder des UDP- Headers[17]:
- Quell-Port:
Die Port-Nummer auf der Senderseite.
- Ziel-Port:
Die Port-Nummer auf der Empfängerseite.
- Länge:
In diesem Feld wird angegeben, wie lang das gesamte UDP-Paket ist.
- Prüfsumme:
Über dieses Feld wird kontrolliert, ob das UDP-Paket fehlerfrei übertragen wurde.
- Daten:
Die Nutzdaten.
2.2.6 Internet Control Message Protocol (ICMP)
Das im RFC 792 definierte Internet Control Message Protocol ist ein fester Bestandteil von IP und Teil der Internet-Schicht. ICMP ist für die Übermittlung von Nachrichten zuständig, die Kontoll-, Fehlermeldungs- und Informationsfunktionen übernehmen. Die folgenden Aufgaben werden vom ICMP durchgeführt[18].
- Flusssteuerung:
Treffen Datenpakete zu schnell bei einem Zielhost ein, führt es dazu, dass diese nicht korrekt verarbeitet werden können. Der Host sendet daraufhin eine ICMP- Source-Quench-Meldung an den Absender zurück. Es fordert den Absender auf, den Versand von Paketen vorübergehend einzustellen.
- Erkennung unerreichbarer Ziele:
Sollte ein Ziel nicht erreichbar sein, sendet das System, welches das Problem erkannt hat, eine Destination-Unreachable-Meldung an die Paketquelle.
- Umleitung von Routen:
Um einem Host mitzuteilen, dass er einen anderes Gateway verwenden soll, schickt das ursprünglich verwendete Gateway eine ICMP-Redirect-Meldung an diesen.
- Prüfung entfernter Rechner:
Mit Hilfe einer Echo-Meldung kann ein Host überprüfen, ob das IP bei einem entfernten System aktiv und funktionsfähig ist. Das entfernte System antwortet auf die Echo-Meldungen, indem es die Nachrichten an den Absender zurückschickt. Der Kommandozeilen Befehl # ping setzt auf dieses Verfahren.
2.3 Aufbau und Architektur von DDoS-Attacken
Mit Hilfe einer Client-Server Architektur und dem Missbrauch einer Vielzahl unwissend kompromittierten Computern, die als Angriffsplattform dienen, ist es Tätern sehr einfach möglich, die Effektivität und Durchschlagskraft von DoS-Attacken immens zu erhöhen. Generell richtet eine DDoS-Attacke im Gegensatz zu DoS-Attacken einen höheren Schaden an. Diese muss dagegen aber im Vorfeld besser geplant und vorbereitet werden[19]. Ein Hacker, der eine DDoS-Attacke planen und durchführen möchte, folgt im Normalfall den folgenden vier Schritten: (1) Zunächst scannt der Angreifer das gesamte Netzwerk, um potentiell kompromittierbare Hosts zu finden. (2) Im nächsten Schritt werden die verwundbaren Hosts kompromittiert und (3) daraufhin mit einer Malware oder Backdoorpro- gramm infiziert. (4) Im letzten Schritt verwendet er die kompromittierten Hosts, um sein Ziel anzugreifen[20].
2.3.1 Agent-Handler Model
Das Agent-Handler Modell teilt sich in Clients-, Handler- und Agentsstufen auf. Der Angreifer infiziert eine Vielzahl von anfälligen Geräten und installiert versteckte Programme. Dies geschieht entweder manuell oder mit Hilfe von selbst-installierenden Trojanern[21]. Handler sind versteckte Programme auf infizierten Geräten, die von den Clients kontrolliert werden. Der DDoS-Angreifer kommuniziert über die Clients mit den Händlern, um die Anzahl der vorhandenen Agents Zombies festzustellen und DDoS-Attacken durchzuführen[22].
Die Architektur des Agent-Handler-Modells und die Kommunikation untereinander kann aus Abbildung 7 entnommen werden.
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Entnommen aus: Dhruba Kumar Bhattacharyya und Kalita (2016), Seite 29 Abbildung 7: Darstellung des Agent-Handler-Modells
2.3.2 Internet Relay Chat Model
Beim IRC-Modell findet die Kommunikation, anders als beim Agent-Handler-Modell, über einen IRC-Chanel und nicht über die Handler statt (siehe Abbildung 8 ). IRC (Internet Relay Chat) wird normalerweise als Diskussionsplattform und zum Meinungsaustausch zwischen Usern verwendet. Beim Austausch über IRC wird eine eins-zu-eins Verbindung zwischen den Chattern aufgebaut[23]. Der Angreifer verwendet IRC, um seinen Standort von Erkennungssystemen zu verstecken. IRC-Ports sind oftmals geöffnet und können deshalb verwendet werden, um mit den Agents zu kommunizieren und DDoS- Angriffe durchzuführen[24].
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Entnommen aus: Dhruba Kumar Bhattacharyya und Kalita (2016), Seite 29 Abbildung 8: Darstellung des IRC-Modells
2.4 DDoS-Angriffstypen
Die folgende Spezifikation von DDOS-Attacken richtet sich auf die Betrachtung des OSI- Schichtenmodells, die Art und Weise Attacken auszuführen sowie das entstehende Datenvolumen und die verwendeten Übertragungsraten während der Angriffsdurchführung30.
2.4.1 Schichten-Spezifische DDoS-Attacken
Schichten-Spezifische DDoS-Attacken lassen sich in Anwendungsschicht oder Transport- und Netzwerkschicht ausgerichtete Attacken kategorisieren. Bei einer OSI-Schicht-7 Attacke verwendet der Angreifer u.a. das HTTP-bzw. HTTPS-Netzwerkprotokoll, um Datenmengen an sein Opfer zu übertragen. Der Angreifer versucht CPU intensiven Traffic an ein ausgesuchtes Opfer zu senden. Dies führt dazu, dass es den Server bis zum Zusammenbrechen überlastet. Das generierte Datenvolumen, welches bei diese Art von Angriff benötigt wird, um einen Server in die Knie zu zwingen, fällt im Vergleich zu Schicht 3 und 4 gerichteten Attacken geringer aus. Der während einer Schicht-7-Attacke herbeigeführte Traffic ist von normalem Traffic nur sehr schwer zu unterscheiden und macht es vorhandenen Abwehrsystemen nicht leicht diesen zu erkennen[25].
Bei Angriffen auf die Netzwerk- und Transportschicht richtet der Angreifer seine Attacken auf die Ressourcen seines Angriffsziels wie z.B. die Bandbreite zwischen Verbindungen, die den Netzwerkverkehr des Opfers transportieren, oder auf den Arbeitsspeicher von Routern, Switchen und Firewalls, um diesen zu überlasten. Um dies zu erreichen, muss der Angreifer eine sehr hohes Datenvolumen, in der Größenordnung von mehreren MBps oder GBps auf Schicht 3 und 4, an das Opfer senden. Als Netzwerkprotokoll kommen hierbei ICMP, UDP und TCP zum Einsatz. Die bekanntesten DDoS-Attacken dieser Angriffsart sind TCP-SYN-Flood, ICMP Echo, UDP-Flooding, DNS-Amplification und NTP[26].
2.4.2 Direkte und reflektierende DDoS-Attacken
Bei einer DDoS-Attacke sind es nicht zwingend die kompromittierten Zombies (Ein an das Internet angeschlossener Computer oder Gerät, das durch Schadsoftware unwissend von Hackern gesteuert und kontrolliert wird), welche Traffic an das gewünschte Ziel senden. Server, auf denen UDP basierende Dienste laufen, werden oftmals von Angreifern dazu missbraucht, massive DDoS-Attacken durchzuführen. Gänzlich lassen sich DDoS- Attacken in direkte und reflektierende aufteilen[27]. Eine direkte DDoS-Attacke zielt darauf ab, dass der Angreifer seine Zombies direkt verwendet, um verschiedene DDoS-Attacken auszuführen und Traffic beim Angriffsziel zu generieren (siehe Abbildung 9)[28].
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Entnommen aus: Dhruba Kumar Bhattacharyya und Kalita (2016), Seite 30 Abbildung 9: Darstellung direkte DDoS-Attacken
Im Vergleich dazu werden bei reflektierenden Attacken unterschiedliche Zwischenknoten dazu missbraucht, DDoS-Attacken auszuführen. Der Angreifer sendet bei diesem Attackentyp Anfragen mit der gespooften IP-Adresse seines Angriffsziels an einen Server, dem sogenannten Reflektor. Daraus resultiert, dass der Reflektor nicht dem eigentlichen Angreifer, sondern der manipulierten IP-Adresse des eigentlichen Angriffsziel antwortet (siehe Abbildung 10). Die Nachrichtengröße der Antwortmesssage misst dabei ein größeres Datenvolumen als die ursprünglich abgegebene Nachricht des Angreifers an den Reflektor. Diese Attackentypen nennt man auch Amplifikationsattacke. DNS-Amplification und NTP sind Beispiele für diese Art von Attacken35.
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Entnommen aus: Dhruba Kumar Bhattacharyya und Kalita (2016), Seite 31 Abbildung 10: Darstellung reflektierende DDoS-Attacken
2.4.3 Direkte und indirekte DDoS-Attacken
Eine direkte DDoS-Attacke richtet den Traffic, initiiert durch den Angreifer und ausgehend von den Zombies, direkt an das Angriffsziel. Anstatt das Opfer direkt anzugeben, werden bei indirekten Attacken die Verbindungen und wichtige Dienste, die für die korrekte Funktionsweise des Opfers von Nöten sind, attackiert. Link-Flooding, wie z.B. crossfire oder coremelt, sind Beispiele für indirekte Attacken[29].
2.4.4 Volumenabhängige DDoS-Attacken
DDoS-Attacken lassen sich zudem in Abhängigkeit zu ihrer Volumengröße klassifizieren. In einer Low-Rate-Attacke erzeugt der Angreifer niedrigen Traffic, der hinsichtlich seiner Größenordnung in das Raster des erlaubten und definierten Traffic-Profils des Opfers passt. Das Ziel des Angreifers ist es, die CPU-Ressourcen mit gezielt hohen CPU-lastigen Anfragen lahm zu legen. Im Gegensatz zu einer Attacke mit geringem Traffic ist das Ziel eines High-Rate Angriffs ein möglichst hohes Datenvolumen an das Opfer zu übertragen. Diese Vorgehensweise zählt zu den weitverbreitesten Angriffsarten[30].
2.4.5 Übertragungsratenabhängige DDoS-Attacken
Zusätzlich zu den bereits erwähnten Attackentypen können diese auch in Bezug auf ihre Angriffsartencharakteristik kategorisiert werden. Hinsichtlich der Angriffsrate ergeben sich hierbei folgende Kategorien[31].
- Konstante Angriffsrate:
Attacken dieser Kategorie erreichen sehr schnell das Maximum ihrer Angriffsrate. Sobald der Angreifer seinen Zombies mitgeteilt hat, ein Opfer anzugreifen, senden diese ihrer maximale Datenmenge in einer konstanten Angriffsrate.
- Ansteigende Angriffsrate:
Anstatt direkt mit der vollen Angriffskraft zuzuschlagen werden bei Attacken, die sich in dieser Kategorie wiederfinden, die Intensität der Angriffsrate langsam
[...]
[1] Vgl. akamai.com (2016), Seite 1.
[2] Vgl. malwaretech.com (2016).
[3] Vgl. Krebs (2016d).
[4] Vgl. Douligeris und Mitrokotsa (2003), Seite 192-192.
[5] Vgl. Dhruba Kumar Bhattacharyya und Kalita (2016), Seite 3-4.
[6] Vgl. Dhruba Kumar Bhattacharyya und Kalita (2016), Seite 4-5.
[7] Vgl. Khalimonenko et al. (2017).
[8] Vgl. Jarzyna (2013), Seite 29-32.
[9] Vgl. Mandl etal. (2010), Seite 99.
[10] Vgl. Zisler (2014), Seite 115.
[11] Vgl. Ernst etal. (2015), Seite 290.
[12] Vgl. Tanenbaum (2010), Seite 552.
[13] Vgl. Mandl etal. (2010), Seite 197.
[14] Vgl. Zisler (2014), Seite 206-207.
[15] Vgl. Mandl etal. (2010), Seite 226; Vgl. Zisler (2014), Seite 210.
[16] Vgl. Tanenbaum (2010), Seite 541-542.
[17] Vgl. Schnabel (2017).
[18] Vgl. Mandl etal. (2010), Seite 147-148.
[19] Vgl. Mirkovic und Reiher (2004), Seite 39-42.
[20] Vgl. M. H. Bhuyan etal. (2013), Seite 3.
[21] Vgl. Sridhar (2011), Seite 5.
[22] Vgl. Mirkovic und Reiher (2004), Seite 39.
[23] Vgl. Mutton (2004), Seite gehe21-22.
[24] Vgl. Kalt (2000).
[25] Vgl. Das et al. (2010), Seite 28-33.
[26] Vgl. Abliz (2011), Seite 8-9.
[27] Vgl. Monowar H Bhuyan, D. Bhattacharyya et al. (2015), Seite 1-3.
[28] Vgl. Monowar H Bhuyan, Dhruba Kumar Bhattacharyya etal. (2014), Seite 80-81.
[29] Vgl. Studer und Perrig (2009), Seite 37.
[30] Vgl. Monowar H Bhuyan, D. Bhattacharyya et al. (2015), Seite 1-2.
[31] Vgl. Mirkovic, Prier et al. (2002), Seite 317-318.
- Citation du texte
- Christian Rehbein (Auteur), 2017, Moderne DDoS-Attacken, Munich, GRIN Verlag, https://www.grin.com/document/372379
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.