Anatomie eines DDoS-Angriffs - Teil 5: Application Layer Attacken

DDoS-Angriff auf die Applikation

Seite: 2/3

Firmen zum Thema

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.

(ID:42285739)