Slowloris – neuer DoS Angriff auf Webserver

Die Abkürzung DoS bedeutet „Denial of Service“ – es handelt sich also um eine Attacke, die darauf abzielt, ein Ziel unerreichbar zu machen für echte Benutzer.

Robert Hansen hat ein neues Verfahren entwickelt, DoS Attacken auf Webserver (z.B. Apache) durchzuführen und dieses „Slowloris“ genannt. Er beschreibt es ausführlich auf seiner Homepage http://ha.ckers.org/slowloris/

Dabei wird nicht ein übliches Flooding, also eine Überhäufung des Webservers mit Anfragen, durchgeführt, sondern im Gegenteil ein recht langsamer Angriff, der durch ein absichtliches Verlangsamen und Hinauszögern korrekter gültiger Anfragen dafür sorgt, daß er nach und nach sämtliche Requestlimits des Webservers belegt.

Das Gefährliche dabei ist, daß diese Art von Angriff kaum bemerkbar ist – in den Logdateien des Webservers tauchen keine merkwürdigen Einträge auf, denn die werden ja erst geschrieben, wenn die Anfrage fertig bearbeitet ist, bzw. fehlerhaft abbricht. Beides passiert hier aber nicht, es sind ja gültige Anfragen. Seeeehr langsaaaame.

Die Resourcen des Servers werden auch nicht übermäßig beansprucht, so daß in Monitoring Tools wie Munin und Cacti kaum Auffälligkeiten zu beobachten sind. Der Server muß im Gegenteil immer weniger tun, er wartet ja darauf, daß die Requests endlich einmal korrekt zu Ende gebracht werden.

Prozessorientierte Webserver wie Apache, dhttpd, GoAhead WebServer und Squid sind übrigens anfälliger: Sie erzeugen pro Request einen Prozess auf dem Server und limitieren die Anzahl derselben, um einen anderen Angriff zu verhindern: Daß der Webserver durch zu viele Requests die Resourcen der Hardware (v.a. RAM Speicher und Prozessorzeit) aufbraucht.

Außerdem scheint es einen Seiteneffekt zu geben: Bei Webapplikationen taucht zusätzlich das Problem auf, daß die Datenbank, die dort im Normalfall verwendet wird, noch weniger gleichzeitige Verbindungen akzeptiert, als der Webserver. Diese gibt also zuerst auf. Damit wird der Angriff noch effektiver, erzeugt dann allerdings schneller Fehlermeldungen, die denselben leichter identifizierbar machen.

Die gute Nachricht ist außerdem: Der Angriff wird durch geeignete Auswahl von Reverse Proxies, Load Balancern u.ä. Strukturen verhindert, da diese Systeme eben meist nicht prozessorientert arbeiten – das ist allerdings nichts, was man normalerweise in kleinen Umgebungen vorfindet. Es dürfte also eine Menge gute Ziele da draußen geben!