Suchen

Prefork-Fehlkonfiguration 95 Prozent aller Webserver anfällig für DoS

Autor / Redakteur: Tim Schughart* / Stephan Augsten

Ein Großteil der Webserver lässt sich mit wenig Aufwand in die Knie zwingen. Für den Administrator sieht es aus, als sei der Server einem DDoS (Distributed Denial of Service) zum Opfer gefallen. Dabei könnte ein einfacher Wechsel auf ein anderes Multi Processing Module schnell Abhilfe schaffen.

Firmen zum Thema

Ein Großteil der Webserver lässt sich momentan mit Anfragen von nur einem PC vom Netz nehmen.
Ein Großteil der Webserver lässt sich momentan mit Anfragen von nur einem PC vom Netz nehmen.
(Bild: Archiv)

Ein Großteil der Webseiten ist anfällig für einen scheinbaren DDoS-Angriff. Durch die Modifikation einer „HTTP Slow Post“-Attacke und der lokalen Simulation eines Botnets gelang es dem Autor zusammen mit dem unabhängigen Sicherheitsexperten Steffen Mauer, gängige Webserver mit Anfragen zu überfluten, so dass diese nicht mehr erreichbar sind.

Netstat-Ausgabe mit unkenntlich gemachten IPs.
Netstat-Ausgabe mit unkenntlich gemachten IPs.
(Bild: ProSec Networks)
Der Exploit schickt dabei HTTP-Post-Anfragen an den Webserver und hält die Verbindungen offen. Es werden so viele Anfragen generiert, bis die Verbindungen des Webservers aufgebraucht sind und dieser keine neuen mehr zulässt.

Mithilfe der lokalen Botnetz-Simulation werden gängige Schutzmechanismen umgangen. Der Angriff lässt sich somit für das Opfer nicht von einer DDoS-Attacke unterscheiden. Aus Sicherheitsgründen werden an dieser Stelle aber keine weiteren Details genannt.

Das Problem besteht in der historischen Arbeitsweise der Webserver. In der Standardeinstellung nutzt z. B. der Apache Webserver das Multi Processing Module (MPM) „Prefork“. Dieses erstellt für jede Verbindung einen neuen Kindprozess (Child Process). In der Standardkonfiguration erlaubt der Webserver nur 150 aktive Verbindungen (Debian Wheezy, Apache Version 2.2.22).

Aufgrund des Forkings ist der Arbeitsspeicherverbrauch enorm hoch und treibt gängige Hardware schnell an Ihre Grenzen. Unter dem Kasten ein Auszug aus der Standardkonfiguration des Prefork-MPM:

<IfModule mpm_prefork_module>

MaxServers

StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxClients 150

MaxRequestsPerChild 0

</IfModule>

Erschwerend kommt hinzu, dass Apache von Haus aus keine Möglichkeit bietet, in der Konfiguration die parallelen Verbindungen zu beschränken. Der Angriff ist hauptsächlich auf Netzwerkebene zu erkennen, Apache selbst gibt im Standard Loglevel lediglich einen Eintrag mit: „Too many open connections“ aus. Die Status-Website von Apache lässt sich nicht mehr abfragen – der Administrator tappt im Dunkeln.

Ergänzendes zum Thema
Über ProSec Networks

ProSec Networks bietet professionelle und individuelle Penetrationtests an. Zudem unterstützt das Unternehmen bei der Durchführung von IT-Sicherheitskonzepten sowie deren Planung. Weitere Details finden Interessierte auf der Webseite von ProSec Networks.

Das Prefork-Problem in den Griff bekommen

Einen einfachen aber wirksamen Schutz bietet das Modul „mod_qos“. Hier können verbindungsspezifische Einstellungen und Einschränkungen vorgenommen werden. Das Modul schränkt unter anderem die maximal erlaubten Anfragen pro Client ein und bietet somit einen erhöhten Schutz.

Hier ein Auszug der Konfigurationsdatei:

## QoS Settings

<IfModule mod_qos.c>

# handles connections from up to 100000 different IPs

QS_ClientEntries 100000

# will allow only 25 connections per IP

QS_SrvMaxConnPerIP 25

# maximum number of active TCP connections is limited to 256

MaxClients 256

# disables keep-alive when 70% of the TCP connections are occupied:

QS_SrvMaxConnClose 70%

# minimum request/response speed (deny slow clients blocking the server, ie. slowloris keeping connections open without requesting anything):

QS_SrvMinDataRate 100 1200

# and limit request header and body (carefull, that limits uploads and post requests too):

# LimitRequestFields 30

# QS_LimitRequestBody 102400

</IfModule>

Sofern die Möglichkeit besteht, sollte man einen Wechsel auf das MPM „Worker“ in Betracht ziehen. Dieses Modul bietet den Vorteil der Thread-orientierten Arbeitsweise. Aufgrund dessen verarbeitet die gleiche Hardware deutlich mehr Verbindungen, so dass der Angreifer deutlich mehr Ressourcen aufwenden muss.

Kombiniert man die beiden Mechanismen, so benötigt man für einen erfolgreichen Angriff eine Vielzahl von physikalischen Rechnern und etliche Gigabit an Bandbreite und ist somit deutlich besser geschützt. Einen 100-prozentigen Schutz gibt es allerdings nicht.

Die Attacke hat ein solches Ausmaß, weil Administratoren potenzielle Angriffe dieser Art völlig vernachlässigen. Als wir die Webseiten von großen Konzernen testeten, mussten wir feststellen, dass die meisten Webseiten anfällig für die Attacke waren.

Zum Umgehen von Intrusion-Detection- und -Prevention-Systemen (IDS/IPS) wurden zusätzliche Techniken verwendet, die aus Sicherheitsgründen nicht genannt werden. Ein reines Blocken auf Basis der IP, des verwendeten User Agent o.ä. lässt sich leicht umgehen und ist daher unzureichend.

Die gängigsten Webserver im Überblick.
Die gängigsten Webserver im Überblick.
(Bild: W3Techs.com / ProSec Networks)
Zu bemängeln ist unter anderem, dass die bekannten Webserver wie Apache, Nginx, HTTPD und IIS in ihrer Standardkonfiguration keinen Schutz gegen Attacken dieser Art mitliefern. Hier muss der Administrator des Webservers selbst aktiv werden und die nötigen Module implementieren. Die Webserver Nutzungs-Statistik zeigt eindrucksvoll die Tragweite.

Grundsätzlich geht dieses Problem jedoch weit über Webserver hinaus, da jeder TCP-Dienst ein potentielles Angriffsziel darstellt und für die meisten anderen Dienste keine entsprechenden Sicherheitseinstellungen vorhanden sind. Erfolgreich ließ sich die Attacke schon auf den SMTP Daemon Postfix und OpenSSH ausweiten.

Ergänzendes zum Thema
Danksagung des Autors

Ein besonderer Dank geht an Steffen Mauer, der ProSec Networks zu jeder Zeit tatkräftig mit außerordentlicher Fachkompetenz unterstützt hat. Zudem möchte ich mich bei Svenja Kranz und Khanh-Qouc Pham bedanken, die mir jederzeit zur Seite gestanden haben.

* Tim Schughart ist Geschäftsführer von ProSec Networks.

(ID:43171759)