Einleitung
Bei Denial of Service (DoS) handelt es sich um eine, hauptsächlich wirtschaftsschädigende Methode die eine jegliche erzuwungene Außerbetriebname eines Dienstes oder ausbleiben einer Leistung beschreibt. Dabei geht es inzwischen nicht mehr nur um einzelne Internetdienste sondern teilweise um ganze Netzwerke oder gar Rechenzentren. Denial of Service Angriffe auf diese Ziele sind die wohl bekanntesten und auch häufigsten. Das hat vorallem den Hintergrund, dass in dieser Zeit die globale Netzinfrastruktur soweit ausgebaut ist, dass man für einen effektiven Denial of Service Angriff keinen großen Aufwand betreiben muss. Fertige Tools die wie die Low Orbit Ion Cannon, Slowloris und diverse Botnetz-Builder machen Denial of Service so einfach wie nie.
Denial of Service bezieht sich nicht ausschließlich auf Internetdienste. Es gibt auch häufiger Fälle, bei denen Call-Center mit vielen Anrufen regelrecht bombadiert werden und so die möglichen führbaren Gespräche voll ausgeschöpft werden. Anrufer erhalten in dieser Zeit möglicherweise das Besetzt-Zeichen, welches natürlich nicht gerade die freundlichste Methode ist, einen Kunden abzuweisen.
Die meisten Denial of Service Angriffe gehen jedoch von Script-Kiddys aus. Jugendliche, manchmal auch Minderjährige, die ihre Limits testen wollen, sich am Leid Anderer erfreuen oder Aufmerksamkeit brauchen. Vielleicht auch Weltverbesserer, die unter dem Anonymous-Kollektiv versuchen mit Denial of Service die Welt zu verändern.
Jedoch hat Denial of Service auch einen kommerziellen Hintergrund. An den richtigen Stellen kann man Denial of Service Angriffe gegen Geld erwirken. Die meisten werden von Botnetzen mit tausenden von Rechnern ausgeführt. Das geht, nicht selten, von Firmen gegen andere Firmen um sich einen Vorteil auf dem Markt zu verschaffen. Solche Denial of Service Fälle landen allerdings nur sehr selten in dem Medien.
Methoden und Ursachen
Im Grunde sind die folgenden Denial of Service Methoden offensichtlich. Meistens kombiniert man Methoden um einen erfolgreichen Denial of Service zu erwirken oder die Wirkung weiter zu verbessern. Bei so mancher Angriffsmöglichkeit greift man sich an den Kopf und fragt, wie Das denn möglich sein kann. Aber alle Systeme sind nun mal von Menschen gebaut und Menschen machen nun mal Fehler. Oftmals sind Probleme für Außenstehende offensichtlich, aber der/die Entwickler hat/haben daran einfach nicht gedacht.
Konzept- und Planungsfehler
Konzept und Planungsfehler sind oft fataler, als man zunächst angenommen hat. Dabei geht es bei Internetdiensten oft um Netzwerkstrukturen. Mit einem Konzeptfehler selbst kann man oft nicht viel anfangen. Ein solcher Fehler dient nur als Hilfsmittel für einen erfolgreichen Denial of Service Angriff. Das Gefährliche an Konzeptfehlern ist, dass diese oft auch von Laien ausgenutzt werden können.
Beispiel: Eine Internetplatform verteilt über einen sog. Load-Balancer Last auf unterschiedliche Maschinen (Server). (Wir gehen davon aus, das die Rechenlast wesentlich höher als die Netzwerklast ist). Jegliche Anfragen müssen den Load-Balancer durchlaufen und werden so auf weitere Maschinen verteilt. Der Schwachpunkt ist hier ganz klar der Load-Balancer. Schafft es ein Angreifer mittels eines Denial of Service Angriffs den Load-Balancer außer Betrieb zu nehmen, ist der gesammte Dienst nicht mehr verfügbar.
Programmier- und Entwicklungsfehler
Programmierfehler beziehen sich auf einen bestimmten Dienst. In erster Linie geht es darum, mittels Denial of Service den Dienst zu verlangsamen, zu blockieren oder komplett abzuschalten. Dabei muss man zunächst den Dienst zu identifizieren. Möchte man einen Mailserver-Betreiber sabotieren, so greift man die Mailserver-Software an. Diese zu identifizieren ist kein Hexenwerk. Die meisten Mailserver verraten es auf Anfrage inklusive Versionsnummer. Geht es um eine Webplatform, wird man in den Meta-Tags fündig, manchmal auch am URL-Schema oder am Seitenlayout.
Um einen Programmierfehler zu finden, benötigt es entweder viel Glück oder viel Ahnung. Wer kein Glück hat, blättert wenig durch die CVE-List (http://cve.mitre.org) und sucht nach einer Denial of Service Lösung für den identifizierten Dienst. Im Übrigen kann man auch sog. Denial of Service Exploits in Form von 0-Days kaufen. Eine Anlaufstelle liefere ich an dieser Stelle nicht. Wer sucht, der findet!
Programmierfehler können sehr unterschiedlich sein. Der wohl bekannteste ist der klassische Buffer-Overflow. Man erzeugt durch fehlerhafte Daten einen Überlauf im Speicher. Dabei werden andere, möglicherweise wichtige Daten überschrieben und das Programm stürzt ab.
Direkt danach folgt das Memory-Leak: Verwendete, aber nicht mehr benötigte Resourcen werden nicht wieder freigegeben. Der Dienst verbraucht immer mehr Speicher, bis schließlich kein Speicher mehr verfügbar ist. Dies kann bei kleineren Diensten ein schleichender Prozess über mehrere Wochen sein. Besonders gefährlich ist hier, dass ein Dienst je nach Betriebssystem anderen Diensten auch Speicher entziehen kann. Unter Linux werden bei massiven Resourcenmangel andere Prozesse geschlossen. Windows stürzt dann auch gerne mal ab.
Es können aber auch Fehler in Algorithmen sein. "Speziell geformte Daten" können enormen Rechenaufwand verursachen oder in einer Endlosschleife enden (CVE-2013-3660, nicht unbedingt relevant, aber ein super Beispiel).
Beispiel: Die Gameserver-Software zu einem Autorennspiel einer französischen Firma weist ein Memory-Leak auf. Auf einem gut besuchten Server dauert es etwa 3 Stunden, bis die Software das Speicherlimit von 3GB erreicht hat und abstürzt. Durch viele Verbindungsversuche kann die Software schneller zum Absturz gebracht werden.
Schlechte Datenbanken zählen zu Konzeptions- und zu Entwicklungsfehlern. Eine schlecht gewählte Datenbankstruktur kann bei Suchvorgängen hohe Last verursachen. Zu viele Schlüssel und Beziehungen können sich auch negativ auf die Performance der Datenbank auswirken. Aber auch eine gute Datenbankstruktur kann bei vielen Datensätzen ernorme Rechenlast verursachen. Das beste Beispiel hier für sind Forensysteme. Jedes größere Forensystem erzwingt eine Wartezeit zwischen Suchvorgängen, um einer möglichen Überlastung und einem daraus resultierenden Denial of Service vorzubeugen.
Überlastung
Überlastungsangriffe sind die derzeit beliebtesten Denial of Service Angriffe. Man muss nur wenig über das Zielsystem wissen. Im schlechtesten Fall benötigt man nur etwas Geld. Es ist die Holzhammer-Methode unter den Denial of Service Angriffen. Man prügelt einfach solange auf das System ein, bis es in die Knie geht. Und das kann jeder.
Ein halbwegs intelligenter Denial of Service durch Überlastung resultiert oft aus einem Konzept- oder Programmierfehler. Das Beispiel des Konzeptfehlers lässt sich durch Überlastung realisieren.
Überlastungsangriffe werden in der Regel von sehr vielen verschiedenen Angreifern zur selben Zeit ausgeführt. In diesem Fall spricht man dann von Distributed Denial of Service.
Beispiel: Ein größeres Spieleforum meldet einen Denial of Service Angriff mittels Überlastung der Anbindung des Servers und schreibt sogar eine Belohnung für Hinweise auf den/die Täter aus.
SYN-Flood
Ein Denial of Service Angriff mittels SYN-Flood wird über das TCP-Protokoll ausgeführt. Der Verbindungsaufbau einer TCP-Verbindung wird auch als 3-Wege-Handshake bezeichnet. Der Client sendet dem Server ein Paket mit einer Verbindungsanfrage (SYN). Der Server antworted darauf hin mit einer Bestätigung (SYN,ACK) oder Ablehnung (RST). Der Client bestätigt diese Bestätigung (ACK). Nun können Client und Server Daten austauschen.
Der SYN-Flood nutzt eine Schwachstelle des Betriebssystems aus. Mit der Verbindungsanfrage (ACK) des Clients, speichert das Betriebsystem diese Verbindung in einer Tabelle. Lässt der Client die Bestätigung (ACK) weg, dann wartet das Betriebssystem prinzipell ewig auf dieses Paket. Der Eintrag in der Tabelle bleibt bestehen und verbraucht dort ein wenig Resourcen. Wiederholt man diesen Vorgang sehr oft, kann der Server irgendwann keine Verbindungen mehr aufnehmen, da keine Resourcen mehr zur Verfügung stehen.
Mit Hilfe des SYN-Cookie-Verfahrens werden SYN-Flood-Angriffe unwirksam. Der Großteil der Server im Netz hat SYN-Cookies aktiviert, daher sind Denial of Service Angriffe mittels SYN-Flood inzwischen eher eine seltenheit.
ICMP-Flood (Ping Flood)
Der ICMP-Flood zählt zu den ältesten aller Denial of Service Angriffen. Dabei werden innerhalb kürzester Zeit möglichst viele ICMP-Anfragen an das Ziel versendet, ohne auf eine Antwort zu warten.
Der Angriff zielt rein auf die Überlastung des Zielsystems ab. Da eine Überlastung der CPU im diesem Zeitalter eher schwierig ist, zielt man heute auf die Überlastung der Anbindung ab. Zu jeder ICMP-Anfrage antwortet der Server mit einem gleichgroßen ICMP-Antwort. Man benötigt also nur die Hälfte der verfügbaren Bandbreite mit ICMP-Anfragen zu belegen, die andere Hälfte wird von den ICMP-Antworten genutzt.
Ein solcher Denial of Service Angriff erscheint, zumindest in größerem Ausmaß, nicht besonders klug. Denn die ICMP-Antworten bekommt ja der Absender zugestellt. Man würde quasi zusätzlich sich selbst attackieren. Daher werden ICMP-Floods oft in Zusammenhang mit IP-Spoofing ausgeführt. Man versendet die ICMP-Anfrage mit der IP-Adresse eines anderen Systems als Quelladresse. Das hat den praktischen Effekt, dass dieser Server alle ICMP-Antworten zugestellt bekommt und so auch mit diesem Denial of Service Angriff zu arbeiten hat.
Ist dieser Effekt, also ein Denial of Service Angriff auf das zweite System durch die ICMP-Antworten, Ziel des Angriffs, so spricht man an dieser Stelle von einem Smurf-Angriff oder auch Smurfing.
ICMP-Floods haben heutzutage nur noch wenig Bedeutung. Es gibt deutlich effektivere Methoden.
Ping of Death
Der Ping of Death ist das Ergebniss einer fehlerhaften Implementierung des Internet Prokotolls (IP). Die vom Internet-Protokoll festgelegte Maximalgröße eines Paketes beträgt 65.535 Bytes (2¹²-1). Das dem Internet-Protokoll zugrundeliegende Ethernet-Protokoll legt jedoch eine maximale Größe (MTU) von 1.500 Bytes fest. Größere Pakete werden in kleinere Blöcke getrennt und auf dem Zielhost wieder zusammen gesetzt. Dieses Verfahren bezeichnet man als Fragmentierung.
Im Falle einer Fragmentierung, wird jedes Fragment mit einem Offset versehen, damit der Zielhost das Gesamtpaket wieder richtig zusammensetzen kann. Das Fragment-Offset steht im IP-Header und ist 13 Bit lang. Die größte mit 13 Bit darstellbare Zahl ist 2¹³ -1 = 8191. Die maximal Größe des Paketes beträgt allerdings 65.535 Bytes. Man könnte also garnicht alle Positionen im Offset abdecken. Daher wird der Wert des Offsets mit 8 multipliziert (Man spricht an dieser Stelle auch von einer "Einheit" von 8 Byte). Ein Offset von 3 würde also die Position 3 * 8 = 24 Byte ergeben.
Das daraus resultierende maximale Offset ist 65.528 Byte ( (2¹³ - 1) * 8 ). Die maximale Paketgröße eines IP-Paketes ist 65.535 Bytes. Das bedeutet im letzen Fragment dürfen nur 65535 - 65528 = 7 Byte übertragen werden. Man könnte jedoch noch mehr Daten in das Paket schreiben, denn es ist ja in diesem Paket noch Platz. Und genau diese Aktion löst den Ping of Death aus.
In sehr vielen Implementierungen dieses Protokolls hatte das Übertragen von mehr als 7 Byte im letzen Paket fatale Folgen. Für ein IP-Paket waren nur 65.535 Bytes Speicher reserviert. Das Zusammensetzen der Fragmente resultierte in einem Bufferoverflow und überschrieb nicht selten kritische Bereiche des Betriebssystems und führte so zum Absturz.
Smurfing
Smurfing beschreibt einen Vorgang, durch den ein Dienst durch einen Angreifer mit einer gespooften IP-Adresse dazu missbraucht wird, große Datenmengen an einen weiteren Host zu senden um letztendlich einen Denial of Service zu erwirken. Der klassische Smurfing-Angriff erfolgte über ICMP (Ping). Nahezu jeder Host antwortet auf eine ICMP-Anfrage. Im Falle einer gespooften IP-Adresse, sendet der Smurf-Host die Antwort natürlich an die gespoofte IP-Adresse. Für den Smurf-Host scheint die ICMP-Anfrage schließlich von dieser IP-Adresse zu stammen. Der Host hinter der gespooften IP-Adresse bekommt nun die ICMP-Antwort des Smurf-Hosts, und kann damit natürlich nichts anfangen.
Wiederholt man dieses Verfahren auf mit mehreren Smurf-Hosts, resultiert dies in einem anonymen Denial of Service Angriff.
Um so interessanter wird dieses Verfahren für Denial of Service, wenn die Antwort des Smurf-Hosts größer ist, als die gesendete Anfrage. In diesem Fall hat man einen Verstärkungsfaktor und kann mit weniger Aufwand mehr Bandbreite blockieren.
UDP-Flood
UDP ist ein verbindungsloses Protokoll. Anders als bei TCP gibt es keinen spezifizierten Verbindungsaufbau und auch keine Fehlerkorrektur. Diese Eigenschaften machen UDP zu einem sehr schnellen Protokoll. Deshalb setzt man UDP vorallem im Bereich der Echtzeitübertragung wie Medienstreaming und Internet-Telefonie ein. Aber auch andere zeitkritische Dienste wie DNS und NTP, sowie Dienste die auf Broadcast-Basis arbeiten und daher kein direktes Ziel kennen, aber trotzdem Daten übertragen müssen (Routing Informationen, Windows-Dateifreigabe, Gameserver-Announce im lokalen Netzwerk), nutzen UDP.
Empfangene UDP Daten werden direkt an das auf dem Zielport wartende Programm weiter gegeben, oder, falls es für diesen Port keine Anwendung gibt, mit einem ICMP-Paket (Destination unreachable) beantwortet.
Da es bei UDP keinen Verbindungsaufbau gibt, wird vom Protokoll auch nicht geprüft, ob die Quell-IP gespoofed ist, oder nicht. Diese Eigenschaft macht das Protokoll ideal für Smurf-Angriffe.
NTP / DNS - Reflection
Diese zwei auf UDP basierenden Protokolle sind zur Zeit sehr beliebt für Denial of Service Angriffe mittels Smurfing.
Das Network Time Protocol (NTP) dient zur Synchronisierung der Systemzeit zwischen verschiedenen Computersystemen. Dahinter arbeitet ein hierarchisch geordnetes Netzwerk von weltweit über 1000 Computersystemen, die jederzeit die genaue Uhrzeit liefern können.
Mit dem Befehl MONLIST liefert ein NTP-Server eine Liste der von diesem Server meistgenutzen NTP-Server um die eigene Systemzeit aktuell zu halten. Jeder Eintrag enthält Informationen für Quell und Ziel-Adresse sowie Version und Modus.
In diesem Fall ist die Antwort wesentlich größer als die Anfrage. Man kann mit Werten um Faktor 10 rechnen.
Das praktische an einer NTP-Reflection ist, dass das Netzwerk aus NTP Servern vollständig dokumentiert und öffentlich zugänglich ist. Ein Angreifer kann sich für die Smurf-Hosts seines Denial of Service Angriffs einfach an der Liste bedienen. Inzwischen ist laut Cloudflare bei sehr vielen NTP-Servern der MONLIST Befehl abgeschaltet worden. (http://blog.cloudflare.com/goo…-ntp-servers-closing-down).
Das Domain Name System (DNS) dient zur Namensauflösung im Web und ist heutzutage nicht mehr wegzudenken. Auch das Domain Name System ist hierarchisch aufgebaut. Zu jeder Domain gehören mehrere zuständige (Authoritative) Nameserver.
Beispiel 1: Wir lösen stagetwo.eu auf:
- Anfrage an root-servers.net (die höchste Instanz): Welche IP hat stagetwo.eu
- root-servers kennt die Antwort nicht und verweist auf die zuständigen Nameserver von (in diesem Fall) .eu
- Anfrage an einen der Nameserver von .eu
- Auch dieser Nameserver kennt die Antwort nicht und verweist auf die zuständigen Nameserver von (in diesem Fall) cloudflare
- Anfrage an einen der Nameserver von Cloudflare.
- Dieser Nameserver liefert schlussendlich die Antwort:
Beispiel 2: Wir versuchen stagetwo.eu über völlig fremden Nameserver (docks18.rzone.de - Nameserver von Strato.de) aufzulösen:
- Anfrage an docks18.rzone.de
- Der Nameserver antwortet mit einer Fehlermeldung
An der Domain unbeteiligte Nameserver können nicht antworten, denn diese Nameserver wissen ja garnichts über diese Domain. Ein unbeteiligter Nameserver müsste also erst Informationen über diese Domain rekursiv einholen, um diese dem Anfragenden zu liefern. Auf dem gezeigten Nameserver von Strato ist dieses rekursive Einholen von Informationen deaktiviert. Das sagt auch die Fehlermeldung aus.
Nameserver, die eine rekursive Auflösung unterstützen, nennt man Open Resolver. Die meisten Internet Provider bieten Open Resolver für die Nutzung durch ihre Kunden (das sind dann meist die DNS Server, an denen Zugriffe auf Webseiten zensiert werden). Es gibt auch Open Resolver Projekte, die einige "zensurfreie" DNS Server der Öffentlichkeit zu Verfügung stellen.
Ohne diese Open Resolver könnte das DNS-Konzept nicht funktionieren. Wenn jeder Nutzer den gezeigten Weg gehen würde um einen Namen aufzulösen, würde das die DNS-Serverstruktur vollkommen überlasten. Um diese Last zu verringern, speichert ein Open Resolver einen angefragten Namen für eine gewisse Zeit. Wie lange, kann man anhand der Antworten aus dem Beispiel entnehmen. Die Zahl hinter dem Namen ist die Anzahl in Sekunden, die dieser Eintrag gespeichert werden darf. Danach ist der Eintrag ungültig und muss erneut abgefragt werden.
Die Open Resolver spielen bei einer DNS-Reflection eine wichtige Rolle. Bei einer DNS Reflection stellt man eine Auflösungsanfrage mit gespoofter IP-Adresse an einen Open Resolver. Der Open Resolver schickt die Antwort an die gespoofte IP-Adresse. Je nach Größe der resultierenden Daten können hier Antworten generiert werden, die um den Faktor 40-60 größer sind als die Anfrage.
Ein gut organisierter Denial of Service Angriff durch eine dieser beiden Methoden hat verheerende Folgen. Für die NTP-Reflection stehen (standen) tausende von NTP-Servern bereit. Der Angriff kann so über tausende von Hosts breit gestreut werden und wird so schwieriger zu blockieren. Die DNS-Amplification ist nicht ganz so einfach zu realisieren, dafür noch viel verheerender. Mit einem Ausgangstraffic von 16-25 MBit/s kann mit wenigen Open Resolvern 1 GBit/s Traffic auf einen Host gesendet werden.
Slowloris
Slowloris wurde speziell für Denial of Service Angriffe auf Webserver entwickelt und zählt derzeit zu den effektivsten Denial of Service Angriffen. In den meisten Fällen kann ein einziger Angreifer einen ganzen Server problemlos blockieren. Der Angriff nutzt die Problematik eines Threaded-Server-Konzepts aus. Jede vom Webserver angenommene Verbindung wird in einem eigenen Thread bearbeitet. Zum Schutz vor Überlastung durch zu viele Verbindungen gibt es festgelegtes Limit an maximal offenen Verbindungen. Slowloris öffnet eine Verbindungen und tätigt darin unvollständige Anfragen an den Webserver. Der Webserver wartet nun auf die vervollständigung dieser Anfrage. Zu jeder Verbindung gehört natürlich auch ein Timeout. Dieser liegt im Falle von Apache bei unvollständigen Anfragen standardmäßig bei 300 Sekunden.
Damit der Denial of Service Angriff effektiv wird, öffnet Slowloris nicht nur eine Verbindung, sondern extrem viele. Der Webserver nimmt solange weitere Verbindungen an, bis das Limit der maximal offenen Verbindungen erreicht ist. Alle weiteren Verbindungen können nicht angenommen werden. Der Webserver ist nicht mehr erreichbar. Für den typischen Multimediarechner stellen wenige hundert Verbindungen kein Problem dar, weshalb ein s
Größere Webserver, die viele Verbindungen verwalten können, sind mit dieser Methode natürlich schwieriger zu attackieren. Aber man kann Slowloris natürlich auch von mehreren Rechnern zugleich ausführen.
Gegenmaßnamen / Minderung / Migrierung
Das Thema Denial of Service ist nach wie vor ein großes Thema. Einen Universalschutz gegen Denial of Service gibt es nicht. Und vollständig verhindern, kann man Denial of Service Angriffe auch nicht. Baut man eine Internetplatform auf, so muss man auch mit Denial of Service Angriffen rechnen. Die im Moment beliebteste und effektivste Lösung nennt sich Cloud. Diese Cloud-Dienste basieren meist auf Global-Anycast Netzwerken.
Informationen beziehen
Man sollte zu all seinen Softwarekomponenten stets über Updates und Sicherheitslücken informiert sein. Dazu gibt es zu fast jeder Software ein entsprechendes Newsletter oder eine Mailing-Liste. Bei bekanntwerden von Denial of Service und/oder Sicherheitsproblemen, gibt es in solchen Newslettern oft Informationen über die Ursache, und wie man sich schützen kann.
Ursache eliminieren
Wenn man sich die Frage stellt: "Wie kann ich diesen Denial of Service Angriff blockieren?", kommt man bei Smurf-Angriffen zwangsläufig zum Ergebniss kommen, dass die für den Denial of Service Angriff genutzen Server besser umkonfiguriert werden würden. Denn Smurf-Angriffe profitieren oftmals aus Konfigurationsfehlern Dritter.
Im Fall der NTP-Reflection kann der Serverbetreiber den MONLIST-Befehl deaktivieren. Im Fall der DNS-Reflection kann der Serverbetreiber die Anfragenrate limitieren. Vielleicht wollte der Serverbetreiber auch generell keinen Open-Resolver konfigurieren und kann die Recursion komplett abschalten.
Fragen kostet nichts, auch wenn man, leider viel zu oft, keine Antwort bekommt.
Konfiguration optimieren
Denial of Service Angriffe wie Slowloris zielen auf das eingestellte Verbindungslimit des Webservers ab. Die vom Angreifer aufgebauten Verbindungen lassen sich jedoch sehr einfach erkennen, sie kommen nämlich alle von der selben IP-Adresse. In den meisten Webservern kann man ein weiteres Verbindungslimit pro IP-Adresse festlegen. Dieses Limit sollte natürlich so gewählt werden, dass die Besucher der Webseite davon nichts mitbekommen. 5 -10 Verbindungen pro Seitenaufruf sollte man einplanen.
SYN-Cookies
SYN-Cookies ist die effektiveste Gegenmaßnahme gegen SYN-Flood Angriffe. Der Erfolg des SYN-Floods basiert auf dem Überlauf der Tabelle der offenen Verbindungen des Betriebssystems. Verwendet man SYN-Cookies, fällt diese Tabelle weg. Der Denial of Service Angriff ist nicht mehr effektiv.
Ein Teil des TCP-Standards legt fest, dass TCP-Pakete mit einer Sequenznummer gekennzeichnet werden. Dies garantiert, dass auf dem Zielhost die Pakete in der richtigen Reihenfolge verarbeitet werden können. Beim Verbindungsaufbau wird die sogenannte "Initiale Sequenznummer" von Server und Client ausgetauscht.
SYN: Der Client sendet seine initiale Sequenznummer S_client
SYN-ACK: Der Server bestätigt die Sequenznummer des Clients mit S_client + 1 und sendet S_server\\
ACK: Der Client bestätigt die Sequenznummer des Servers mit S_server + 1
Ursprünglich waren die initialien Sequenznummern rein zufällig gewählt. Diese Informationen mussten also für die Zeit des Verbindungsaufbaus zwischengespeichert werden. Das Erfolgskonzept von SYN-Cookies ist, dass die Sequenznummer vom Server berechnet werden kann. Die Sequenznummer hat eine Größe von 32 Bit und besteht mit aktivierten SYN-Cookies aus folgenden Komponenten:
- t Ein Zeitstempel, der logisch um 6 Bit nach rechts geshiftet wurde, um eine Zeitspanne von 2^6 (= 64) Sekunden für die Bestätigung der Sequenznummer zu gewährleisten. (5 Bit)
- m Die maximale Segmentgröße (MMS), also die maximale Anzahl an Bytes, die als Nutzdaten in einem TCP-Paket versendet werden können. (3 Bit)
- s Das Ergebniss einer kryptografischen Funktion über Server IP und Port sowie Client IP und Port und dem Zeitstempel t. Die zu verwendene kryptografische Funktion ist nicht spezifiziert und kann daher frei gewählt werden. Die einzige Vorraussetzung ist, dass die Funktion die noch verbleibenden 24 Bit ausfüllt.
Für die kryptografische Funktion könnte man sich des Problems der Faktorenzerlegung/Faktorisierung bedienen.
s = a * (b + Daten)
Wobei a und b ausreichend große Zahlen sind. a und b werden beim Start des Betriebssystems generiert und gespeichert. Im Falle eines Neustarts werden diese neu generiert.
Innerhalb der Zeitspanne von 2^6 Sekunden kann der Server die initiale Sequenznummer nachberechnen und so überprüfen, ob die Verbindungsanfrage des Clients gültig ist. Die ursprünglich problematische Tabelle ist komplett weggefallen.
Global Anycast Netzwerk
Einige große Netzwerke sind inzwischen als Anycast-Netzwerke strukturiert. Das System dahinter ist simpel. Man hat (möglichst) identische Hardware in verschiedenen Rechenzentren rund um dem Globus verteilt. All diese Systeme haben die selbe IP-Addresse. Dank dieser Struktur kann man nur schwer einen gezielten Denial of Service Angriff auf das System durchführen, die Datenpakete immer den kürzesten Weg nehmen und so unter den Rechenzentren aufgeteilt werden. Ein gezielter Denial of Service Angriff auf ein solches System ist sehr aufwendig, da der Angriff ortsbedingt möglicherweise zu einem anderen Rechenzentrum geroutet wird. Der Angreifer bräuchte also mehrere Systeme an einem bestimmten Ort um einen erfolgreichen Denial of Service Angriff auf eines der Systeme durchzuführen.
Sollte ein System in einem Rechenzentrum nicht mehr erreichbar sein, so ändert sich die Route und die verbleibenden Systeme bedienen die Anfragen bis das entsprechende System wieder verfügbar ist.
Ein solches Netzwerk zu errichten und zu betreuen verursacht ernorme Kosten. Man kann bei Dienstleistern seinen Datenverkehr durch ein solches Netzwerk routen. Man selbst benötigt dabei nur einen einzigen Server oder Webspace, der Datenverkehr wird durch den Dienstleister gefiltert.
Viele Administratoren, vorallem Administrationen von Foren und Blogs, wiegen sich hinter einem solchen Netzwerk in Sicherheit. Der Ursprungsserver hat jedoch auch eine IP-Addresse die, in der Regel, öffentlich erreichbar ist. Wird diese IP-Addresse bekannt, ist das Anycast-Netzwerk vollkommen nutzlos. Viele Administratoren konfigurieren ihre Dienste falsch, sodass diese auf Anfrage die IP-Adresse des Ursprungsservers bekanntgeben.
Firewall
Falls es (noch) kein Update für die fehlerhafte Software gibt, kann man gegen Denial of Service durch speziell geformte Daten auch mit einer Firewall vorgehen. Eine gute Firewall kann viele verschiedene Angriffe, nicht nur Denial of Service, erkennen und abfangen. Jenachdem wie viel Datenverkehr man erwartet, muss hierfür möglicherweise ein eigener Server oder sogar eine fertige Firewall-Lösung angeschafft werden.
Weiterlesen
Wenn dich das Thema Denial of Service interessiert, kannst du an diesen Stellen weitere Informationen finden:
- Grundlagen - finden sich im englischen Wikipedia. Das deutsche Wikipedia liefert oft nur sehr sehr schmale Infos
- Cloudflare Blog - Interessante Berichte zu aktuellen Denial of Service Angriffen. blog.cloudflare.com
- Sourcefire Chalk Talks - Denial of Service und Sicherheitsthemen. youtube.com
- Defcon Talks - auf Youtube; Nicht ausschließlich Denial of Service, aber auf jeden Fall einen Blick wert.
Kommentare