Anatomie eines DDoS-Angriffs - Teil 5: Application Layer Attacken DDoS-Angriff auf die Applikation

Autor / Redakteur: Jim Öqvist, Check Point / Peter Schmitz

Application Layer Attacken sind inzwischen die häufigte Form der DDoS-Angriffe. Unterschieden wird zwischen „appliaction flood“ und „low and slow“ Angriffen. Eines der bekanntesten DDoS-Tools ist die Low Orbit Ion Canon (LOIC), die gern von Anonymous-Unterstützern eingesetzt wird.

Firmen zum Thema

Mit einfachen Tools und Bots lassen sich leicht Tausende von Anfragen z.B. an Shopsysteme schicken und diese so für normale Nutzer lahmlegen. Bei der Abwehr muss man darauf achten, dass man legitime Kunden nicht versehentlich aussperrt.
Mit einfachen Tools und Bots lassen sich leicht Tausende von Anfragen z.B. an Shopsysteme schicken und diese so für normale Nutzer lahmlegen. Bei der Abwehr muss man darauf achten, dass man legitime Kunden nicht versehentlich aussperrt.
(Bild: Markus Haack - Fotolia.com)

Bei den Attacken auf einzelne Anwendungen oder Server werden zwei verschiedene Varianten unterschieden, eine mit einer Flut von Anfragen mit einem großen Umfang an den Application Layer gegen einen speziellen Server und eine mit kleinen und langsamen Anfragen.

Diese Arten von Attacken werden normalerweise mit einem Netzwerk von Bots ausgeführt, da sie eine komplett legitime TCP Session öffnen müssen und nicht gespoofed werden können. Hier lassen sich mit Bots auch wesentlich größere Effekte erzielen.

Diese Bots sind normalerweise an einen IRC Channel angebunden, über den der Angreifer die Bots kontrollieren und die Attacke koordiniert starten kann, indem er Chat-Einträge an den Channel schreibt, die von den Bots als Kommandos empfangen werden.

Application Flood

Der Angreifer befiehlt seinen Bots über IRC, eine HTTP-Verbindung zu dem anvisierten Webserver zu öffnen. Oder aber bei einer Kampagne von beispielsweise einer Gruppe von Hacktivisten, fragen diese ihre Unterstützter, ob diese ihnen über einen speziellen IRC Channel folgen. In diesem Channel weist der Anführer der Gruppe diese Unterstützer an ein gewisses Ziel zu einer gewissen Zeit mit Anfragen zu überfluten, um die Attacke zu koordinieren.

Diese Bots oder Unterstützer fangen dann damit an, den Webserver mit HTTP Anfragen zu überfluten, indem sie beispielsweise bestimmte Seiten mit großem Ladevolumen aufrufen. Der Webserver versucht, alle Anfragen zu bedienen, aber da es sich um zu viele von ihnen handelt, werden die Ressourcen des Webservers wie CPU-Kapazitäten überlastet. Die legitimen Anfragen werden dann nicht mehr beantwortet, weil die Webserver nicht so viele Anfragen bearbeiten können.

Diese Attacken sind einerseits sehr anspruchsvoll, aber andererseits sehr einfach auszuführen. Sie sind in der Lage traditionelle Sicherheitslösungen wie Firewalls, IPS oder Application Control zu umgehen. Der Grund dafür ist, dass sie aus der Perspektive dieser Sicherheitslösungen als legitime Anfragen aussehen. Die Anfrage ist dann eine normale HTTP-Anfrage auf beispielsweise Port 80, so dass die Firewall diesen zulässt. Auch der Inhalt ist komplett legitim, so dass die Application Control diesen erlaubt und die Daten keinen gefährlichen Code enthalten.

Auch in diesem Fall wird IPS diesen nicht triggern. Der Unterschied liegt beim Verhalten. Ein normaler User wird eine Verbindung öffnen und ein paar Seiten herunterladen sowie vielleicht auf einen anderen Link klicken. Ein Bot wird eine Menge von Verbindungen öffnen, um eine Menge von Webseiten herunterzuladen und dies zur selben Zeit vielfach tut. Wie bereits zuvor erwähnt, diese anspruchsvollen Attacken sind sehr einfach auszuführen, jeder kann eine Low Orbit Ion Canon von Sourgeforce herunterladen und eine HTTP-Anfragenflut an ein gewisses Ziel senden.

Kleine und langsame Attacken (low & slow)

DDoS-Angriffe mittels Application Layer Attack sind einfach umsetzbar und extrem effektiv und daher äußerst beliebt.
DDoS-Angriffe mittels Application Layer Attack sind einfach umsetzbar und extrem effektiv und daher äußerst beliebt.
(Bild: Check Point Software Technologies)
Der Ansatzpunkt für diesen Angriff ist immer eine Schwachstelle im Application Layer 7 von der Anwendung, die der Hacker vorher herausgefunden hat. Weder die Größe der Anfrage, noch die Anzahl der Verbindungen ist besonders hoch.

Darüber hinaus ist es schwierig für einen Standard-Schutz gegen DoS und DDoS diesen Attackentyp zu erkennen, da diese keinen großen Umfang an Anfragen pro Sekunde generieren. Sie sind langsam und belasten mit einem nur kleinen Umfang die Ressourcen des Servers über eine relativ lange Zeit. Standard Lösungen gegen DoS und DDoS, die eine Standardanzahl an Triggern zur Verfügung haben, um HTTP Anfragen zu analysieren, werden diese Attacken nicht wahrnehmen und sie werden unter dem Radar dieser Schutzsysteme bleiben.

Ein Beispiel für eine kleine und langsame Attacke ist eine langsame HTTP GET Attacke. Hier nutzt ein Angreifer ein Tool wie slowloris, um eine HTTP-Verbindung mit dem Server aufzubauen und in dieser Verbindung ein HTTP GET-Kommando senden. In dem Befehl wird der letzte Zeilenumbruch (Character Return Line Feed (CRLF)) übergangen, so dass dieser Befehl nicht abgeschlossen wird.

Der Server wartet dann darauf, dass weitere Daten angefragt werden, und hält die HTTP-Verbindung offen. Nach vielleicht drei Sekunden wird der Angreifer eine neue Verbindung auf die gleiche Art öffnen. Immer mehr Verbindungen werden so nach und nach geöffnet, bis der Server nicht mehr alle Verbindungen bedienen kann und legitime Nutzer keinen Zugang mehr zu den angefragten Services bekommen.

Anwendungen schützen, ohne deren Schwachstellen zu kennen

Technisch: Die meisten traditionellen Sicherheitslösungen haben einen Schutz, der so aufgebaut ist, dass Administratoren kontrollieren können, wie viele Anfragen an den Server gestellt werden dürfen. Dieser ratenbasierte Schutz, wenn er richtig konfiguriert ist, wird aktiviert, wenn der Umfang an Anfragen die vorher eingestellte Menge überschreitet. Das Problem dabei ist, dass diese Lösungen sehr zeitintensiv manuell eingestellt werden müssen, außerdem werden sie legitime Anfragen blocken und unter gewissen Umständen eine große Anzahl von False Positives generieren.

Ein Beispiel verdeutlicht die Abwehr einer solchen Attacke. Eine Marketing-Abteilung in einem Reisebüro entscheidet sich dafür eine Marketing Kampagne zu kreieren, in der sie einen Preisnachlass für Flüge an einen bestimmten Ort anpreisen. Der Nachlass für diese Flüge wird 10 Euro sein und die Kampagne wird am Wochenende durchgeführt. Dann wird allen Nutzern mitgeteilt, dass die Preisnachlässe nur am Mittwoch zwischen 12 und 1 Uhr gegeben werden. Natürlich werden dann besonders viele Nutzer zu dieser Zeit den Online-Shop besuchen.

Wenn nun ein ratenbasierter Schutz eingesetzt wird, würde er eine unnatürliche Anzahl von Anfragen an den Server wahrnehmen und mit der Generierung von False Positives beginnen sowie alle legitimen Anfragen blocken. Die Kampagne wird ihr Ziel nicht erreichen, weil so viele der Nutzer nicht in der Lage wären, die Webseite aufzurufen und die Idee, damit die Nutzer auch auf andere Angebote aufmerksam zu machen, scheitern. Hier würde die Sicherheitslösung gegen den Online-Shop arbeiten, statt für ihn.

Um eine Application-basierte Überflutungsattacke abzuwehren, gibt es weitaus bessere Wege. Beispielsweise könnte man ein System nutzen, dass das Verhalten von Nutzeranfragen auf den verschiedenen Wegen zum Server automatisch und kontinuierlich erlernt. Ein solches System wird das Verhalten eines normalen Nutzers erlernen und kann dann zwischen den normalen Nutzern und den Angreifern unterscheiden.

Für die Umleitung wird keine ratenbasierte Einschränkung vorgenommen. Vielmehr kann das System eine Echtzeitsignatur erstellen, die nur zu Anfragen von verdächtigen IP-Adressen passt. Diese werden dann mit verschiedenen Methoden untersucht, um nur die identifizierten Angreifer herauszufiltern. Zur gleichen Zeit werden alle legitimen Nutzeranfragen zugelassen, ohne dass False Positives generiert oder legitime Anfragen geblockt werden. Ebenso wichtig ist es, dass Echtzeit-Signaturen flexibel und schnell angepasst werden können, um Veränderungen der DDoS-Attacke sofort wahrzunehmen.

Kleine und langsame Attacken, unterhalb des Radars von ratenbasierten Sicherheitslösungen

Diese Attacken zielen nicht auf Schwachstellen ab, die sich in der allgemeinen Schwachstellen- und Exploit-Datenbank CVE befinden. Es sind vielmehr Exploits von einer Schwachstelle in der Implementierung. Deshalb laufen Verteidigungsmaßnahmen ins Leere, wenn sie nur darauf setzen, das Verhalten von Nutzeranfragen an den Server zu analysieren.

Das Problem kann nur mit einem System gelöst werden, das granulare vordefinierte Filter aktivieren kann. Diese Filter müssen alle Vorgänge monitoren und entdecken, die versuchen, die bekannte Schwachstelle in der Implementierung zu nutzen. Das System wiederum braucht eine Engine, die es möglich macht nicht nur eine Datenbank von vordefinierten Filtern zu nutzen, sondern die auch in der Lage ist, einen eigenen Filter zu erstellen. Dieser wiederum muss im System angepasst werden können, um die Ausnutzung von neuen Schwachstellen in der Implementierung zu verhindern. Die Engine muss ebenfalls fähig sein, das beschriebene in einer Stresssituation durchzuführen, wenn eine große Anzahl an Anfragen eintrifft, ohne dabei Auswirkungen auf die Performance und den Durchsatz von legitimen Anfragen zu haben.

Organisatorisch: Mit Überflutungen von Anwendungen und kleinen und langsamen Attacken fertig zu werden, ist normalerweise eine Teamaufgabe, die verschiedene Gruppen von Mitarbeitern eines Unternehmens fordern. Die Netzwerktechniker haben in der Regel die Kontrolle über die Lösungen, die DDoS-Attacken umleiten können.

Die Web-Application-Techniker kennen das Verhalten der Anwendung und ob diese in irgendeiner Weise limitiert ist. Deswegen ist es wichtig, für diese beiden Gruppen zusammen in einem Team zu arbeiten, wenn das Unternehmen von einer Application basierten DDoS-Attacke angegriffen wird.

Außerdem ist sehr empfehlenswert, Pläne bereitzuhalten, um die Rohdatenpakete zu speichern und sie später einer forensischen Analyse zu unterziehen. Es sollte außerdem möglich sein, angepasste Filter während der Attacke zu erstellen. Um den Filter anzupassen, ist Erfahrung im Umgang mit DDoS-Attacken nötig und darüber hinaus wichtig dem ERT oder IRT (Emergency/Incident Response)-Team Zugang zu gewähren.

Wenn ein Unternehmen verschiedene Technologien evaluiert, ist es wichtig abzuklären, dass ERT oder IRT Teil der Lösung sind. Natürlich empfehlen sich auch hier Training, Simulation und die Formulierung einer Strategie und eines eventuellen Plans, um sicher zu stellen, dass alle IT-Mitarbeiter im Ernstfall wissen, wie sie ERT oder IRT kontaktieren können.

Jim Öqvist ist Security Engineer Europe bei der Check Point Technologies GmbH.

(ID:42285739)