Seite 2: Feuersicher

Inhaltsverzeichnis

Feuersicher

Die Application-Level-Firewall mod_security integriert sich als Apache-Modul direkt in den weit verbreiteten Webserver. Dadurch braucht sie sich nicht mehr mit den komplizierten Eigenheiten von TCP-Paketen zu beschäftigen, sondern hat ungestörten Zugriff auf alle Komponenten des HTTP-Protokolls. In den verarbeiteten Verbindungen lässt sich so nicht nur nach IP-Adressen filtern, sondern auf ebenso einfache Weise etwa in Variablen-Parametern von PHP-Skripten, Cookie-Namen und Informationen in HTTP-Headern suchen. Beispielsweise den Admin-Zugang des Forensystems phpBB auf eine bestimmte IP-Adresse einzuschränken, wird so zum Kinderspiel, wie die folgenden Beispiele zeigen.

Der Hersteller ThinkingStone hat den Quellcode unter GPL veröffentlicht, weshalb mod_security bereits Teil der meisten Linux-Distributionen ist, die den Apache-Webserver mitbringen. ThinkingStone selbst bietet den Quellcode als tar.gz-Archiv an. Er lässt sich entweder als Dynamic Shared Object (DSO), was einem selbständigen Apache-Modul entspricht, oder als so genannte Inline-Installation kompilieren, bei der die Quellen von mod_security direkt in die Apache-Quellen integriert werden. Details zu diesem Vorgehen, das Anwendern mit Erfahrung bei der Quellcode-Kompilierung vor keinerlei Überraschungen stellt, sind in der vorzüglichen englischen Dokumentation auf der Website von mod_security zu finden.

Der Einfachheit halber konzentriert sich dieser Artikel auf die Konfiguration von mod_security mit Apache2 unter Debian-Linux. Viele Webserver im Internet und auch der c't-Debian-Server[1] bauen auf dieser immer häufiger anzutreffenden Kombination auf. Wer bereits einen eigenen Apache-Webserver betreibt, wird die hier erläuterten Schritte leicht auch auf Apache 1.3 und andere Betriebsysteme übertragen können.

Einrichtung einer Beispielkonfiguration

Mit Apache2 unter Debian genügt mit Root-Rechten ein einfaches

# apt-get install libapache2-mod-security
# a2enmod mod-security

um das Modul zu installieren und zu aktivieren. Eine simple Grundkonfiguration von mod_security mit einem Filterbeispiel sieht dann in der Datei /etc/apache2/conf.d/mod-security.conf wie folgt aus:

<IfModule mod_security.c>
 
 SecFilterEngine On
 
 # URL-Validierung aktivieren
 SecFilterCheckURLEncoding On
 
 # Unicode-Validierung aktivieren
 SecFilterCheckUnicodeEncoding On
 
 # HTTP-POST-Daten verarbeiten
 SecFilterScanPOST On
 
 # Standard-Aktion für zutreffende Filterregeln
 SecFilterDefaultAction "deny,log,status:403"
 
 # Filterregeln aus mod-security.d einbinden
 Include /etc/mod-security.d/[^.#]*
 
</IfModule>

Das abschließende Include-Statement bindet sämtliche Dateien im Verszeichnis /etc/mod-security.d/ in alphabetischer Reihenfolge ein, die nicht mit einem Punkt oder dem Kommentarzeichen # beginnen. Dadurch ist es möglich, die diversen Regelsätze übersichtlich in einzelnen Dateien zu Gruppieren und zu verwalten. Eine einfache Filterregel in der Datei /etc/mod-security.d/beispiel.conf könnte dann so aussehen:

# Einfacher Demo-Filter
IncludeSecFilter /bin/sh

Nach einem Neustart von Apache mit dem Befehl /etc/init.d/apache2 force-reload ist mod_security aktiv und der Webserver verarbeitet keine HTTP-Anfragen oder -Antworten mehr, die die Zeichenkette /bin/sh enthalten. Sobald das Suchmuster zutrifft, wird der Zugriff entsprechend der Anweisung SecFilterDefaultAction "deny,log,status:403" verweigert, der Vorfall im error.log von Apache protokolliert und dem vermeintlichen Einbrecher eine 403-Fehlermeldung präsentiert:

[Thu Jan 19 17:19:13 2006] [error] [client 127.0.0.1] mod_security: Access denied with code 403. Pattern match "/bin/sh" at THE_REQUEST [hostname "localhost"] [uri "/index.php?exec=/bin/sh%20/var/www/upload/x.sh"]