Ein Ansatz ist sicherlich, die IP des Angreifers zu sperren. Also im Prinzip die Funktionsweise des Tools fail2ban.

Ich habe ein kleines Script gebastelt, welches den Apache-Errorlog auf Einträge durchsucht, die auf einen Angriff mit Slowloris hindeuten und dann die entsprechenden IP-Adressen per iptables sperrt. Um den Angreifer nicht ewig zu sperren, sollte der Apache-Errorlog natürlich relativ häufig rotieren.

Beide Dateien habe ich auf dem Gopher zugänglich gemacht. Die Firewall-Regeln müssen ggf. angepasst werden (Flush beachten).

Auf einer Debian Standard-Installation muss lediglich die Perl-Erweiterung IO::Socket::SSL installiert werden, um das Perl-Script auszuführen.

Einmal aufgerufen, sendet Slowloris permanent unvollständige HTTP-Requests an das "Ziel". Ein Apache-Prozess wartet nach dem Empfang eines unvollständigen Requests auf die Vervollständigung durch den Client. Das führt dazu, dass der Apache das (konfigurierbaren) Maximum seiner Kindprozesse ausführt und so innerhalb kürzester Zeit keine wirklichen HTTP-Requests anderer Clients mehr beantworten kann.

Währenddessen sind andere Dienste – selbst andere Apache-Instanzen – auf der gleichen Maschine weiterhin erreichbar. Zumal der Angriff mit Slowloris lediglich eine Bandbreite von <1 Kbyte/Sek. benötigt.

Eine Firewall bietet für diese Art der Angriffe i.d.R. keinen Schutz, da die TCP-Verbindung korrekt zustande kommt. Der Angriff beginnt also auf Protkollebene.

Auch scheint kein Workaround für die Apache-Konfiguration zu existieren. Hier fällt mir auch lediglich das Experimentieren mit der Konfiguration des Moduls mpm_prefork ein. Allerdings stößt ja jeder Server irgendwann an seine physikalischen Grenzen.

Neben dem Apache sollen noch weitere Web- und Proxyserver betroffen sein. Populäre Ausnahmen sind architekturbedingt aber lighttpd und IIS.