Dipl.-Inform. Carsten Eilers

Prinzipiell wurden für einen DDoS-Angriff lange Zeit dieselben Verfahren wie für einen "einfachen" DoS-Angriff verwendet. Nur dass der Angriff nicht direkt vom Rechner des Angreifers ausgeführt wurde, sondern von einer Vielzahl DDoS-Daemons, die der Angreifer zuvor eingerichtet hat. Meist wurde zwischen Angreifer und DDoS-Daemon ein weiteres System eingesetzt, das dann die Steuerung der Daemons übernimmt.

DDoS am Beispiel von Trinoo

Ein Trinoo-Netzwerk besteht aus einem oder mehreren Mastern, die jeder eine große Anzahl von Daemons kontrollieren, siehe Abbildung 1. Sowohl Master als auch Daemon müssen unter Ausnutzung vorhandener Schwachstellen in fremde Systeme eingeschleust werden. Ist dies gelungen, kann der Angreifer jederzeit Verbindung mit dem oder den Master(n) aufnehmen und den Angriff gegen einen Server oder ein Netz starten. Der oder die Master kontaktieren daraufhin die Daemons, die den eigentlichen DoS-Angriff durchführen.

Abb. 1: Trinoo-Netzwerk (Klick für großes Bild in neuem Fenster/Tab)

Die Kommunikation zwischen dem Angreifer und den Mastern erfolgte typischerweise über TCP-Port 27665, die zwischen Master und Daemon über UDP-Port 27444 bzw. zwischen Daemon und Master über UDP-Port 31335. Die jeweiligen Zugänge sind durch ein Passwort geschützt.

DDoS durch Botnets

Eine weitere Möglichkeit zur Steuerung und Durchführung von DDoS-Angriffen sind Botnets. Dabei handelte es sich ursprünglich um eine Vielzahl so genannter IRC-Bots, die über IRC (Internet Relay Chat) gesteuert wurden. Inzwischen erfolgt die Steuerung über alle möglichen Kanäle, einschließlich Twitter etc..

Auch aktuell kommen noch Botnets zum Einsatz, nur dass die Bots inzwischen aus den Geräten des IoT stammen. Aber dazu komme ich in der nächsten Folge.

DDoS durch DNS Amplification Attacks

Der nächste Schritt bei den DDoS-Angriffen waren DNS Amplification Attacks. Vereinfacht wird dabei eine Vielzahl von DNS-Anfragen mit der gefälschten Senderadresse des Opfers abgeschickt, die jede zu einer möglichst großen Antwort führen.

Die maximale Größe eines DNS-Response-Pakets war ursprünglich 512 Bytes. Eine typische DNS-Anfrage von 60 Bytes konnte also zu einer maximal 512 Byte großen Antwort führen, was einem Verstärkungsfaktor von 8,5 entspricht.

Durch Erweiterungen des Protokolls wurde eine Vergrößerung der DNS-Antworten notwendig (siehe RFC 2671, Extension Mechanisms for DNS (EDNS0)), sodass der Absender der DNS-Anfrage nun einen ausreichend großen Puffer reservieren und dessen Größe dem befragten Nameserver mitteilen kann. Wird eine Puffergröße von 4.000 Bytes verwendet, führt eine DNS-Anfrage von 60 Bytes nun zu einer um mehr als das 60-fache verstärkten Antwort.

Der Angreifer benötigt für seinen Angriff nur einen gültigen Domain-Namen, zu dessen DNS-Einträgen ein großer Text-Record gehört, und eine DNS-Anfrage mit gefälschter Senderadresse.

Wie beim DNS-Spoofing kann der Angreifer einen eigenen Nameserver verwenden. Diesen konfiguriert er entsprechend RFC 2671 bzw. dessen Nachfolgers RFC 6891 so, dass u.a. ein großer Text-Record vorhanden ist. Ein hoher Timeout-Wert sorgt dafür, dass die Daten von den für den Angriff ausgenutzten Nameservern lange gecached werden.

Der Angreifer konstruiert dann eine DNS-Anfrage nach allen DNS-Einträgen zu seiner Domain, gibt einen großen Puffer an und verwendet als Senderadresse die des gewünschten Opfers. Diese gefälschte DNS-Anfrage wird an eine Reihe von Nameservern, die rekursive Anfragen von beliebigen Clients entgegennehmen (sog. Open Resolver), gesendet. Für das Senden der Anfragen kann z.B. ein Botnet verwendet werden. Die Nameserver beantworten die Anfragen und senden ihre Antwort an die gefälschte Senderadresse, wodurch es beim Opfer zum DoS durch Überflutung kommt, siehe Abbildung 2.

Abb. 2: DNS Amplification Attack (Klick für großes Bild in neuem Fenster/Tab)

Gegenmaßnahmen

Sich vor (D)DoS-Angriffen zu schützen ist extrem schwierig, da keine Maßnahme vor einer vollständigen Auslastung der Bandbreite schützen kann. Um z.B. DNS Amplification Attacks grundsätzlich zu verhindern, müssten alle als Open Resolver dienenden Nameserver umkonfiguriert werden, sodass sie nur noch Anfragen aus ihrem eigenen Netz entgegennehmen. Das ist aber gar nicht möglich, da viele Open Resolver mit Absicht (und aus guten Grund, nämlich der Verhinderung von Zensur) offen sind.

Trotzdem (oder gerade deswegen) sollten die eigenen Systeme so sicher wie möglich konfiguriert werden. Im Fall der Nameserver bedeutet das z.B., sofern möglich Rekursion zu deaktivieren oder rekursive Anfragen nur aus dem eigenen Netz entgegenzunehmen. Ein nicht-rekursiver Nameserver ist auch nicht anfällig für Cache-Poisoning.

In der nächsten Folge geht es um aktuelle DDoS-Angriffe.

Carsten Eilers