Administration Hosting IT Linux Website

Mit mod_rewrite den ApacheKiller Exploit entschärfen

Wie heise Security gestern vermeldet hat, gibt es ein Problem in aktuellen Apache2 Webservern der Version 2.2.x, welches bei GET-Requests mit mehreren “Byte-Ranges” auftritt und dazu genutzt werden kann, den RAM des angegriffenen Ziels überlaufen zu lassen, was zum Absturz des Webserver oder gar des ganzen Servers führen kann. Meine Beobachtungen sind, dass nicht jede Installation gleich anfällig ist.

Zwar wird bei einem Angriff mit dem Exploit-Code einiges an CPU-Leistung verbrannt, der RAM Verbrauch steigt um ein paar hunder MB, reicht aber auf den Systemen unter meiner Kontrolle nicht aus, diese aus dem Tritt zu bringen – zumindest nicht mit nur einem angreifenden Rechner und 1000+ Threads.

Schritte zum Dämpfen der Bedrohung sind entweder die Abschaltung des Byte-Ranges in der Config des Header Moduls, was aber neben dem kompletten Deaktivieren von “resumable Downloads” noch schwerwiegendere Folgen haben dürfte oder aber das Beschränken der Zahl der Range-Requests via mod_rewrite. Ich habe mich wie vermutlich die Meisten für die zweite Lösung entschieden.

Diese Instruktionen beziehen sich auf ein Server-System mit Debian Linux. Bei Verwendung einer anderen Distribution müssen ggf. Dateipfade angepasst werden.
Dazu muss in jedem VHost folgender Code eingefügt werden (z. B. nach der DocumentRoot-Direktive):

# Apache2 Range-Request Rewrite Fix
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]

Da ich wenig Lust habe, das in jeden VHost manuell einzufügen, lagere ich das in eine eigene Datei in /etc/apache2/conf.d/antiapachekiller aus und füge ein Include /etc/apache2/conf.d/antiapachekiller in jeden VHost nach dem DocumentRoot ein. Weil ich das bei ziemlich vielen Seiten machen muss, habe ich das mit diesem Skiptchen automatisiert. Dieses kann an beliebiger Stelle liegen, der Pfad mit den VHost-Definitionen ist fest eingebaut (und müsste bei Abweichungen angepasst werden), und ein Backup des Apache-Verzeichnisses vorher wird dringend empfohlen!

#!/bin/bash
cp -rvp /etc/apache2/sites-available/ /tmp/
cd /tmp/sites-available/
FILES=`ls *.conf`
for FILE in $FILES
do
echo $FILE
cat $FILE | perl -ne 'print $_; print \
"Include /etc/apache2/conf.d/antiapachekiller\n" \
if ($_ =~ /DocumentRoot/ )' > /etc/apache2/sites-available/$FILE
done

Selbst wenn kein eigenes Backup vorher angelegt wurde, liegen die Originaldateien nach der Anwendung des Skripts noch in /tmp/sites-available/
Danach sollten die VHosts zumindest noch stichprobenartig überprüft werden und dann der Indianer neu geladen werden (/etc/init.d/apache2 reload).

Autor

Seit Kindheitstagen ist der Computer sein Begleiter. Was mit Linux anfing, wurde 2005 ein/e Beruf/ung, die weit über den Arbeitsplatz hinausgeht. Durch stetige Weiterentwicklung fasste er auch im *BSD Segment Fuß und bietet mittlerweile professionelle Lösungen im Bereich Hosting, Networking und Infrastruktur an. Als Ausgleich beschäftigt er sich neben Computerspielen mit der Fotografie.

1 Kommentar Neuen Kommentar hinzufügen

  1. Gerade gestern ist der Byte-range DoS Fix für Debian für der lenny und squeeze erschienen. Mit anderen Distributionen wird es sich wohl ähnlich verhalten.

    The following packages are currently pending an upgrade:

    apache2.2-bin 2.2.16-6+squeeze2
    apache2.2-common 2.2.16-6+squeeze2
    apache2-mpm-prefork 2.2.16-6+squeeze2
    apache2-utils 2.2.16-6+squeeze2

    ========================================================================

    Package Details:

    Lese Changelogs…
    — Änderungen für apache2 (apache2.2-bin apache2.2-common apache2-mpm-prefork apache2-utils) —
    apache2 (2.2.16-6+squeeze2) squeeze-security; urgency=high

    * Fix CVE-2011-3192: DoS by high memory usage for a large number of
    overlapping ranges.

    — Stefan Fritsch Mon, 29 Aug 2011 20:23:01 +0200

    ========================================================================

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.