Einspielergebnis

Wer auf den Quellcode angewiesen ist, befreit ihn zunächst von seiner Verpackung, wechselt in das Unterverzeichnis »apache2« und passt dort als erstes das »Makefile« an. Hinter »top_dir« gehört das Apache »ServerRoot« -Verzeichnis, unter Open Suse beispielsweise »/usr/share/apache2« . Es steht auch hinter der gleichnamigen Einstellung in der Konfigurationsdatei »http.conf« des Webservers.

Als nächstes ist im Makefile die Zuweisung

INCLUDES = -I /usr/include/libxml2

auf das Verzeichnis mit den Header-Dateien für die »libxml2« -Bibliothek anzupassen. In den meisten Fällen passt der vorbelegte Wert. Zusätzliche setzt ModSecurity die PCRE-Bibliothek voraus (Perl Compatible Regular Expressions). Ein »make« erstellt schließlich das Modul. Sobald der Kompilierungsvorgang abgeschlossen ist, stoppt man den Webserver und kopiert das neue Modul via »make install« in das Modulverzeichnis des Apache Servers. bschließend muss ModSecurity noch aktiviert werden. Dazu fügt der Admin in der Apache-Konfigurationsdatei »httpd.conf« die folgenden zwei Zeilen ein:

LoadFile /usr/lib/libxml2.so
LoadModule security2_module modules/mod_↩
security2.so

Open Suse geht hierbei eigene Wege. Welche Module der Apache-Server dort beim Systemstart lädt, bestimmt die Variable »APACHE_MODULES« in der Datei »/etc/sysconfig/apache2« . Letztere erweitert der Suse-Admin daher um ein »security2« .

Bevor der Web-Server wieder startet, muss für ModSecurity noch eine Konfigurationsdatei her. Sie gehört in das Verzeichnis mit den Webserver-Konfigurationsdateien und soll im Folgenden »modsecurity.conf« heißen. Die meisten Apache-Installationen bieten für solche zusätzlichen Konfigurationsdateien eigene Unterordner an, wie beispielsweise »/etc/apache2/conf.d/« unter Open Suse. Wichtiger als der Standort ist jedoch ihre korrekte Einbindung in die »http.conf« :

<IfModule security2_module>
    Include /Pfad/modsecurity.conf
</IfModule>

Minimalkonfiguration

Um die Funktionsfähigkeit des Moduls zu testen, genügen schon zwei Zeilen in der »modsecurity.conf« :

SecRuleEngine On
SecRule REQUEST_URI attack deny

Während die erste die Filterung aktiviert, weist die zweite »mod_security« an, alle Anfragen zu blocken, die eine Seite mit der Zeichenkette »attack« im URI anfordern. Um das zu prüfen, fährt man der Admin den Weserver wieder hoch und ruft eine entsprechende (fiktive) Seite auf, wie beispielsweise »http:// Meinserver /attack.html« . Anstelle eines »404 Not Found« -Fehlers liefert Apache jetzt eine »403 Forbidden« -Meldung. Noch auskunftsfreudiger ist das Apache »error_log« (unter Open Suse liegt die Datei in »/var/log/apache2« ). Dort hält ModSecurity fest, welche URI angefordert wurde und warum es den Zugriff darauf verweigerte:

[Sat Feb 09 17:48:26 2008] [error] [client ↩
127.0.0.1] ModSecurity: Access denied with ↩
code 403 (phase 2). Pattern match "attack" at↩
 REQUEST_URI. [hostname "localhost"] [uri ↩
 "/attack.html"] [unique id "edTJAn8AAAIAABQ4WaoAAAAA"]

Sobald ModSecurity seine Arbeit ordnungsgemäß verrichtet, geht es an die Feineinstellungen und die Formulierung passender Filterregeln. Dreh und Angelpunkt ist dabei wieder »modsecurity.conf« .