Dr. Oliver Matula 27. Juni 2017

Denial of Service-Angriffe – Reichen Ihre Schutzmaßnahmen?

Volumenbasierte Angriffe sind die am häufigsten beobachteten DoS-Angriffe. © Informatik Aktuell — © Informatik Aktuell

Durch eine Reihe von Distributed Denial of Service-(DDoS)-Angriffen mit außergewöhnlich hohen Bandbreiten hat das Mirai-Botnetz in letzter Zeit für Schlagzeilen gesorgt. Unter anderem war die Webseite des Journalisten Brian Krebs von einem Angriff mit einer maximalen Bandbreite von ungefähr 620 Gbps betroffen [1] oder anders ausgedrückt entspricht dies der Bandbreite von 6200 regulären DSL-Anschlüssen mit je 100 Mbps. Bei diesem Angriff waren hauptsächlich Geräte des Internet of Things (IoT) wie digitale Videorecorder oder Überwachungskameras beteiligt, die zuvor durch unterschiedliche Schwachstellen mit der Mirai-Software kompromittiert worden waren. Letztendlich konnte der Angriff jedoch durch externe Schutzmaßnahmen abgewendet werden [2].

Volumenbasierte DoS-Angriffe wie der oben genannte werden typischerweise von mehreren Angriffssystemen aus durchgeführt, um eine größere Auslastung der Bandbreite zu ermöglichen. Sie tragen daher das Attribut Distributed, um auf die verteilten Systeme hinzuweisen. Es gibt aber auch DoS-Angriffe, die Schwachstellen in Protokollen oder Applikationen ausnutzen und nicht auf einer Auslastung der Bandbreite basieren. Diese Angriffe können häufig schon von einem einzigen Angriffssystem effizient durchgeführt werden. Da volumenbasierte Angriffe jedoch die am häufigsten beobachteten DoS-Angriffe sind [3], soll im Folgenden speziell auf diese Angriffsart eingegangen werden.

Abwehr von DDoS-Angriffen

Abb.1: Anzahl der registrierten Angriffe mit 100 Gbps über die Jahre 2013-2016 im Rahmen des Arbor WISR 2016. Quelle: Arbor Networks

Für Unternehmen lassen sich aus DDoS-Angriffen wie dem zuvor beschriebenen zwei wichtige Schlüsse ziehen:

DDoS-Angriffe können außerordentlich hohe Bandbreiten erreichen, welche typische Internetanbindungen von Unternehmen im Bereich von 1–10 Gbps bei weitem übersteigen können. Dieses Bild wird ebenfalls durch Arbors Worldwide Infrastructure Security Report (WISR) von 2016 [3] bestätigt. Laut diesem Bericht steigt die Anzahl der Angriffe mit Bandbreiten über 100 Gbps kontinuierlich an (s. Abb.1).
Es lässt sich folgern, dass effektive Schutzmaßnahmen gegen volumenbasierte DDoS-Angriffe existieren. Für deren Umsetzung gibt es eine Reihe von unterschiedlichen Ansätzen. Ein gängiger Ansatz ist die Nutzung einer On Premise-Lösung im Zusammenspiel mit einem cloudbasierten Scrubbing Center. Hierbei ist die On Premise-Lösung oftmals eine dedizierte Hardware Appliance [4], die meist direkt nach den Border Gateway Routern des Unternehmens eingesetzt wird und sowohl zur Erkennung als auch zur Abwehr von (D)DoS-Angriffen dient.

Effektiven Schutz bieten diese On Premise-Appliances jedoch nur gegen protokoll- und applikationsbasierte DoS-Angriffe. Vor volumenbasierten DDoS-Angriffen, die die Bandbreite der Internetanbindung übersteigen, kann eine solche Appliance allein nicht schützen. Die Datenpakete eines solchen Angriffs lasten die Internetanbindung schon aus, bevor die Pakete überhaupt die Appliance erreichen.

Zur Abwehr von volumenbasierten Angriffen werden daher Scrubbing Center eingesetzt. Teilweise werden Scrubbing Center-Dienste direkt durch den jeweiligen Internet Service Provider (ISP) angeboten, jedoch gibt es auch darauf spezialisierte Unternehmen. Im Falle der Detektion eines volumenbasierten Angriffs (z. B. durch die On Premise-Appliance) auf die Internetanbindung eines Unternehmens werden Maßnahmen eingeleitet, um jeglichen Netzwerkverkehr zuerst über das Scrubbing Center zu routen, bevor er zum eigentlichen Ziel weitergeleitet wird.

Der Anbieter des Scrubbing Centers selbst stellt zum einen genug Bandbreite (meist im Bereich von mehreren Tbps) zur Verfügung, um typische Angriffsbandbreiten, die mittlerweile wie zuvor festgestellt bei mehreren 100 Gbps liegen können, handhaben zu können. Zum anderen werden die zum Angriff gehörenden Datenpakete basierend auf verschiedenen Parametern wie zum Beispiel der Reputation der IP-Adresse des Senders analysiert und gefiltert. Hierdurch sollen schlussendlich nur Datenpakete von legitimen Nutzern zu den Zieldatenzentren weitergeleitet werden.

Letztendlich verlässt man sich bei dem zuvor beschriebenen Ansatz auf die Wirksamkeit des Scrubbing Centers zur Abwehr von volumenbasierten Angriffen. Häufig werden zur Filterung innerhalb der Scrubbing Centers gleiche oder ähnliche Appliances eingesetzt, wie sie auch On Premise genutzt werden. Wesentlicher Unterschied ist jedoch, dass hier genug Bandbreite zur Verfügung steht. Die Konfiguration dieser Appliances wird häufig vom Betreiber des Scrubbing Centers durchgeführt und in den wenigsten Fällen vom Nutzer des Dienstes selbst.

Nach erfolgreicher Implementation einer Lösung gegen DDoS-Angriffe ist es daher sinnvoll, diese auch auf ihre Effektivität hin zu testen. Im Folgenden soll gezeigt werden, wie ein solcher Test in wenigen Schritten mit Hilfe der Amazon Web Services (AWS) Elastic Compute Cloud (EC2) [5] durchgeführt werden kann.

Evaluierung von DDoS-Schutzmaßnahmen mittels AWS EC2

AWS EC2 ist ein Cloud-Dienst zur flexiblen Erstellung und Konfiguration von virtuellen Server-Instanzen. Um mithilfe dieses Dienstes die Schutzmaßnahmen gegen volumenbasierte DDoS-Angriffe zu testen, wird eine Infrastruktur ähnlich der eines Botnetzes aufgesetzt und genutzt.

Es soll jedoch zuerst darauf hingewiesen werden, dass die Durchführung eines volumenbasierten DDoS-Angriffs in den meisten Ländern durch strenge Gesetze reguliert ist und mitunter strafbar sein kann. Eine juristische Überprüfung, ob ein solcher Test durchgeführt werden darf, ist im Voraus abzuklären. Ebenfalls sollten alle beteiligten Partner über den Test informiert werden. Dies beinhaltet die entsprechenden Personen im eigenen Unternehmen, den/die ISP(s), den Betreiber des Scrubbing Centers sowie Amazon selbst. Eine Anfrage an Amazon lässt sich unter [6] stellen.

Es wird im Weiteren davon ausgegangen, dass ein funktionierendes AWS EC2-Konto existiert, das für die Erstellung der Infrastruktur genutzt werden kann. Die folgenden Schritte beschreiben, wie man die Testinfrastruktur einrichtet und nutzt.

1. Schritt: Einrichtung einer AWS EC2-Instanz

Durch einen Klick auf Launch Instance lassen sich innerhalb des AWS EC2 Dashboard virtuelle Server-Instanzen einrichten. Hierbei kann zuvor noch in der oberen, rechten Ecke ausgewählt werden, innerhalb welches EC2-Datenzentrum die Instanzen gestartet werden. Die Wahl des Standortes hat unter anderem Auswirkungen auf die sich ergebenden Kosten (auf die später noch genauer eingegangen wird).

2. Schritt: Wahl des Betriebssystems der Instanz

Im nächsten Schritt kann das zugrundeliegende Betriebssystem der Instanz(en) ausgewählt werden. Hierbei werden unterschiedliche Linux- und Windows-Betriebssysteme angeboten. Für das Beispiel wird Ubuntu Server 16.04 LTS (HVM), SSD Volume Type ausgewählt.

3. Schritt: Wahl der Art der Instanz

Anschließend wird die Art der Instanz festgelegt. Hieraus ergibt sich unter anderem die Network Performance der Instanz. Amazon selbst macht keine genauen Angaben, wie die zur Verfügung stehende Bandbreite einer Instanz mit der Network Performance zusammenhängt. Bandbreiten-Tests müssen daher selbst durchgeführt werden.

Vom Autor durchgeführte Bandbreiten-Tests für Instanzen der Art t2.medium ergaben, dass die Bandbreite stark vom ausgewählten Datenzentrum abhängt, jedoch üblicherweise im Bereich von 100 Mbps – 700 Mbps liegen.

Für das Beispiel wird mit Instanzen der Art t2.medium fortgefahren und auf Next: Configure Instance Details geklickt.

4. Schritt: Wahl der Anzahl der Instanzen

In diesem Schritt können eine Reihe von weiteren Parametern der Instanz(en) festgelegt werden. Für uns relevant ist hier der Parameter Number of Instances, welcher die Anzahl der zu startenden Instanzen angibt.

Die Anzahl der zu startenden Instanzen hängt für einen Test von zwei Werten ab: 1) die maximal benötigte Gesamtbandbreite und 2) die gewünschte Anzahl von unterschiedlichen öffentlichen IP-Adressen (jede Instanz erhält ihre eigene öffentliche IP-Adresse).

Die maximal benötigte Gesamtbandbreite ergibt sich aus der Bandbreite der eigenen Internetanbindung. Ist ein Unternehmen zum Beispiel mit einer (symmetrischen) Bandbreite von insgesamt 1 Gbps angebunden, müssen die Instanzen mindestens diese 1 Gbps bereitstellen können. Wie in Schritt 3 erwähnt, beträgt die minimale Bandbreite einer t2.medium-Instanz typischerweise 100 Mbps. Daher sind unter diesem Aspekt insgesamt 10 Instanzen ausreichend.

Wie oben angemerkt, spielt auch die gewünschte Gesamtanzahl von unterschiedlichen IP-Adressen eine Rolle zur Bestimmung der Anzahl von Instanzen. Häufig basieren Filtermechanismen eines Scrubbing Centers darauf, bestimmte Schwellwerte wie zum Beispiel genutzte Bandbreite oder Pakete pro Sekunde in Bezug auf Sender-IP-Adressen anzusetzen. Der Schwellwert für die Bandbreite wird meist aus der maximalen Bandbreite, die unter normalen Umständen pro IP-Adresse genutzt wird, ermittelt. Wird also normalerweise pro IP-Adresse eine Bandbreite von maximal 100 Mbps benötigt, dann sollte der Schwellwert über diesem Wert liegen. Ansonsten besteht die Gefahr, legitimen Netzwerkverkehr zu blocken.

Damit ein Test nicht direkt durch den Bandbreiten-Schwellwert gefiltert wird, muss somit sichergestellt werden, dass die Bandbreite pro Instanz unter diesem Schwellwert liegt. Für einen Schwellwert von 10 Mbps pro IP-Adresse und einer Anbindung von 1 Gbps werden also insgesamt mindestens 100 Instanzen gebraucht. Da die Anzahl der Instanzen ein zwar merkbarer, aber gegenüber anderen Positionen vernachlässigbarer Kostenfaktor ist, kann die Anzahl potentiell höher als benötigt gewählt werden. Hierbei ist jedoch zu erwähnen, dass zur Erstellung von mehr als 20 On Demand-Instanzen pro Datenzentrum zuvor ein spezieller Antrag gestellt werden muss [7].

Nachdem die Anzahl der Instanzen festgelegt worden ist, können diese über Review and Launch und dann Launch gestartet werden. Hierbei muss noch ein Schlüssel für den SSH-Zugang auf den Instanzen konfiguriert werden. Information hierzu finden sich unter [8].

5. Schritt: Einrichten von dsh für die Instanzen

Nachdem die Instanzen erzeugt worden sind, müssen diese für den Test vorbereitet werden. Dazu kann dsh (distributed ssh) genutzt werden, womit ein Befehl auf allen Instanzen gleichzeitig über SSH ausgeführt werden kann.

Zur Nutzung von dsh werden die öffentlichen IP-Adressen der Instanzen in einer Textdatei gesammelt. Typischerweise befindet sich der Ordner für diese Dateien auf einem Linux-System unter /etc/dsh/group.

Die IP-Adressen der Instanzen können über das EC2-Dashboard erhalten werden. Dies ist jedoch recht umständlich, so dass die AWS CLI hierfür besser geeignet ist. Mit dem folgenden Befehl lassen sich zum Beispiel die IP-Adressen aller Instanzen innerhalb der eu-west-1-Region in einem für dsh passenden Format erhalten:

aws ec2 --region "eu-west-1" describe-instances --query "Reservations[].Instances[].[PublicIpAddress]" --output=text > liste-mit-ip-adressen.txt

Zur Einrichtung der AWS CLI sei auf [9] verwiesen.

Es kann nötig sein, noch den Benutzernamen, mit dem auf die Instanzen per SSH zugegriffen werden soll, innerhalb der dsh group-Dateien im Format user@ip anzugeben. Der Standardbenutzername für die in diesem Beispiel erstellten Instanzen lautet ubuntu. Mit dem folgenden sed-Befehl kann eine modifizierte Liste erhalten werden:

sed -e 's/^/ubuntu@/' liste-mit-ip-adressen.txt > aws-list

Generell ist es auch möglich, zur Vorbereitung der Instanzen ein Base Image aus einer Instanz zu erzeugen, um dieses wiederum zur Erzeugung der weiteren Instanzen zu nutzen. Da dsh jedoch später auch zur Ausführung des Tests gebraucht wird, wurde hier auf diese Variante verzichtet.

Letztendlich kann ein Befehl über

dsh -g aws-liste -M -c 'Befehl'

ausgeführt werden. Hierbei ist Gruppenname der Dateiname der entsprechenden IP-Adressliste im /etc/dsh/group-Ordner und Befehl ist der auszuführende Befehl.

6. Schritt: Installation benötigter Programme

Im nächsten Schritt werden die für den DDoS-Test benötigten Programme auf den Instanzen installiert. Es werden zwei unterschiedliche Programme benötigt: ein Programm zur Erzeugung der Datenpakete und ein Programm zur Beschränkung der Bandbreite.

Die Programme zur Erzeugung von Datenpaketen bieten zwar häufig Möglichkeiten, die genutzte Bandbreite zu beschränken. Teilweise senden diese Programme aber dennoch mit der vollständig zur Verfügung stehenden Bandbreite. Um die Bandbreite daher zuverlässig einzuschränken, wird zusätzlich ein Traffic Shaper installiert.

Zur Erzeugung von Datenpaketen gibt es eine Vielzahl von Programmen. Hierfür können zum Beispiel hping3 [10] oder mausezahn [11] verwendet werden. Als Traffic Shaper kann wondershaper [12] eingesetzt werden. Hierbei ist wondershaper ein Wrapper-Skript für das Traffic Control-Programm tc. Die Pakete lassen sich auf den Instanzen folgendermaßen installieren:

dsh -g aws-liste -M -c 'sudo apt-get -y install hping3 mausezahn wondershaper'

Für dieses Beispiel soll im Folgenden hping3 zur Generierung von Datenpaketen genutzt werden. Insgesamt erlaubt hping3 eine feingranulare Konfiguration der Parameter der Datenpakete. Gibt es jedoch sehr spezielle Anforderungen an die Pakete, muss unter Umständen ein selbstgeschriebenes Programm genutzt werden. Hierbei ist zu beachten, dass aus Performance-Gründen möglichst maschinennah programmiert wird (zum Beispiel in C oder C++) und Raw Sockets verwendet werden.

7. Schritt: Durchführung des DDoS-Tests

Zur Durchführung des DDoS-Tests muss zunächst auf allen Instanzen die Bandbreite über wondershaper limitiert werden. Hierbei wird ein Limit der Upload-Rate (wie auch Download-Rate) eingestellt. Die gesamte zur Verfügung stehende Angriffsbandbreite ergibt sich dann aus der limitierten Upload-Rate und der Anzahl der genutzten Instanzen.

Der Befehl zur Limitierung auf 20 Mbps Upload-Bandbreite und 10 Mbps Download-Bandbreite pro Instanz lautet zum Beispiel (Raten werden in kbps angegeben):

dsh -g aws-liste -M -c ‘sudo wondershaper eth0 10000 20000’

Hierbei ist eth0 die zu nutzende Netzwerkkarte auf den Systemen. Es ist anzumerken, dass Schwankungen um den Wert der Upload-Rate von mehreren 10-100 kbps auftreten können.

Um nun eine einfache UDP Flood, das heißt eine Übertragung von vielen UDP-Paketen innerhalb kurzer Zeit auf eine Zieladresse zu starten, kann der folgende Befehl genutzt werden:

dsh -g aws-liste -M -c ‘sudo hping3 --udp -s 25000 -p 25000 --flood Ziel-IP-Adresse’

Hierbei wird über den Parameter s der Source-Port und über p der Destination-Port angegeben. Über das Flag --flood werden Pakete schnellstmöglich gesendet (ohne Anzeige der Antwort). Für weitere Nutzungsmöglichkeiten von hping3 wird auf [13] verwiesen.

Um den Angriff nach dem Start auch wieder zu stoppen, kann hping3 über killall terminiert werden:

dsh -g aws-liste -M -c ‘sudo kilall hping3’

Hierbei muss jedoch zuvor überprüft werden, ob sich die Systeme während der Durchführung eines volumenbasierten Angriffes noch über SSH ansprechen lassen (was normalerweise der Fall ist). Falls dieses Vorgehen nicht funktionieren sollte, gibt es noch die Möglichkeit, die Instanzen über die AWS-Management-Konsole vollständig herunterzufahren.

8. Schritt: Evaluierung der Schutzmaßnahmen

Das Setup der Infrastruktur ist hiermit abgeschlossen und erlaubt nun die Durchführung von simulierten, volumenbasierten (D)DoS-Tests zur Evaluation der vorhandenen Schutzmaßnahmen. Dafür sollten während des Angriffs alle Geräte, über die die Angriffspakete geroutet werden, wie zum Beispiel Router, Firewalls oder ein externes Scrubbing Center, auf ihr Verhalten hin überwacht werden. Dies kann zum Beispiel durch die Analyse geeigneter Logs stattfinden. Schlussendlich wird mittels dieses Test-Szenarios sichergestellt, dass Schwachstellen für (D)DoS-Angriffe effizient erkannt und behoben werden können.

Kosten

Zuletzt sollen noch die potentiellen Kosten eines solchen Tests diskutiert werden. Bei AWS EC2 setzen sich die Gesamtkosten aus insgesamt drei Kostenpunkten zusammen:

Laufzeit der Instanzen
Nutzung von Speicherplatz
Datentransfer von AWS EC2 zum Internet

Die einzelnen Kostenpunkte unterscheiden sich bei den verschiedenen AWS-Datenzentren und sind ebenfalls abhängig von der Art der gewählten Instanz. Hier sollen exemplarisch die Kosten für das Datenzentrum in Frankfurt für eine t2.medium-Instanz mit jeweils 8 GB EBS General Purpose SSD berechnet werden. Insgesamt soll der Preis für einen simulierten DDoS-Test mit 100 Instanzen berechnet werden, die eine Angriffsbandbreite von 2 Gbps über einen Zeitraum von 2 Stunden nutzen. Die hierfür anfallenden Kosten lassen sich über [14] ermitteln:

Laufzeit der Instanzen: $0.054 pro Stunde pro Instanz x 100 Instanzen x 2 Stunden = $10.8 

Nutzung von Speicherplatz: $0.119 pro GB pro Monat x 100 Instanzen x 8 GB x (2 Stunden)/(30 x 24 Stunden) = $0.26

Datentransfer von AWS EC2 zum Internet: $0.090 pro GB x (2 Gbps)/8 x (2 x 60 x 60) s = $162

Damit hat der Test insgesamt einen Preis von $173.06. Die Rechnung wurde jedoch nur für den eigentlichen Test durchgeführt. Zusätzliche Kosten können durch das Setup der Infrastruktur entstehen, während die Instanzen ebenfalls genutzt werden und Daten zum Internet hin transferiert werden. Außerdem wird der Speicherplatz pro Instanz auch abgerechnet, wenn die Instanzen nicht laufen. Zudem wurden keine Personalkosten auf Seiten der testdurchführenden und zu testenden Unternehmen (die nicht notwendigerweise dieselben sein müssen) aufgeführt. Insgesamt ergibt sich dennoch eine kosteneffiziente Methode zur Durchführung der simulierten (D)DoS-Tests.

Fazit

Mit Hilfe von Cloud-Diensten wie AWS EC2 lassen sich kostengünstig und in wenigen Schritten volumenbasierte (D)DoS-Angriffe simulieren. So lassen sich vorhandene Schutzmaßnahmen auf einfache Art und Weise evaluieren. Hierbei ist jedoch eine enge Kooperation mit allen beteiligten Partnern für die Planung und Organisation der Tests notwendig. Insbesondere muss mit den Betreibern von externen Scrubbing Centern der Umfang des Tests abgeklärt werden. Der so zu gewinnende, umfassende Einblick sowie der Nachweis der Wirksamkeit von Schutzmaßnahmen gegen (D)DoS-Angriffe sollte jedoch schlussendlich IT-(Sicherheits)-Verantwortlichen die verhältnismäßig geringen Aufwände und Kosten wert sein.

Quellen