Mehr Sicherheit für Apache-Webserver mit ModSecurity

Dieses Tutorial erklärt die Installation und die grundlegende Konfiguration von ModSecurity auf einem Gentoo-System.

ModSecurity ist ein Apachemodul welches als Web-Applikations-Firewall(WAF) dient. Es operiert auf der Ebene des HTTP-Protokolls und kann zum Überwachen von Traffic, zur Einbruchserkennung und zum Blocken von verdächtigen Requests verwendet werden. Da sich ModSecurity vor jeglicher Webanwendung befindet wird das System durch eine weitere Sicherheitsebene ergänzt. Diese Ebene ist unabhängig von den Anwendungen die dahinter laufen. Es ist ideal zum Erhöhen der Sicherheit auf Systemen mit potentiell gefährlichen Webanwendungen, z.B. PHP-Foren. Es ist nicht notwendig diese Anwendungen umzukonfigurieren oder überhaupt Zugriff darauf zu haben.

Um ein kleines Beispiel zu machen: Du lässt ein Forum laufen und durch einen Bug in der Forumssoftware oder Skriptsprache kann ein Angreifer eine Remoteshell öffnen, indem er Code über eine speziell preparierte URL einschleust. Was mod_security nun tut ist einmal, dass es diese verdächtige URL erkennt und zweitens, dass es den Aufruf blockt. Das Ergebnis ist, dass der Request des Hackers zurückgewiesen wird und der Server trotz des Bugs für diese Art von Angriff gesichert bleibt.

ModSecurity ist ein regelbasierendes System. Damit das obige Beispiel funktioniert ist es erforderlich, dass eine entsprechende Regel existiert, die diesen Angriff erkennt. Man kann aktuelle Regelsätze von der Homepage von ModSecurity herunterladen. Diese verhindern die meisten üblichen Angriffe und stellen gleichzeitig keine Gefahr für die Performance des zu schützenden Systems dar.

Der Setup von mod_security ist extrem einfach und kann innerhalb weniger Minuten durchgeführt werden. Das Resultat jedoch ist dramatisch. Laut Dokumentation von ModSecurity werden mehr als 70% aller Angriffe inzwischen über die Ebene der Webanwendungen durchgeführt. Genau auf dieser Ebene aber wird man von mod_security geschützt.

ModSecurity hat eine Menge Features und ist sehr flexibel. Man kann eigene Regeln schreiben oder existierende abändern. Es ist möglich bestimmte IP-Adressen oder URLs auf eine Whitelist zu setzen, sodass sie von mod_security garnicht behandelt werden. Es können auch einzelne Regeln übersprungen werden usw.

Es ist klar, dass ein solches System Auswirkungen auf die Performance des Servers hat hinsichtlich load und Speicherverbrauch. Zumindest am Anfang sollte man diese Werte genau im Auge behalten.

Ok, let's go.

Zuerst ist sicherzustellen, dass libxml2 installiert ist. Das Apache-Modul mod_unique_id muss auf dem System present sein, entweder als shared oder static in /etc/apache2/apache2-builtin-mods. Liegt es als shared vor, muss eine entsprechende LoadModule-Zeile dafür in der httpd.conf vorkommen.

Installation des Apache-Moduls mod_security

emerge mod_security

Das Paket enthält einen Defaultregelsatz. Es ist jedoch besser diesen zu entfernen und wie oben erwähnt den aktuellen Regelsatz von ModSecurity herunterzuladen. Auf http://www.modsecurity.org/download/direct.html findet man den Link für den aktuellste Regelsatz.

rm /etc/apache2/modules.d/mod_security/*
cd /etc/apache2/modules.d/mod_security/
wget http://www.modsecurity.org/download/modsecurity-core-rules_[VERSION].tar.gz
tar xfvzp modsecurity-core-rules_[VERSION].tar.gz

Damit mod_security vom Apache überhaupt geladen/verwendet wird muss "-D SECURITY" beim Parameter APACHE2_OPTS ergänzt werden:

vi /etc/conf.d/apache2

Sobald der Apache neu gestartet wird ist mod_security aktiv.

Es folgt die Konfigurationsdatei des Apachemodules. Hier braucht man in der Regel nichts ändern.

vi /etc/apache2/modules.d/99_mod_security.conf

Dies ist die eigentliche Konfigurationsdatei von mod_security. Sie sollte man genau studieren und anpassen. Dazu später mehr.

vi /etc/apache2/modules.d/mod_security/modsecurity_crs_10_config.conf

Alle Regeln befinden sich im selben Verzeichnis. In diesem Tutorial werden wir aber keine Änderungen an bestehenden Regeln vornehmen.

/etc/apache2/modules.d/mod_security/

Die Installation ist nun abgeschlossen. Es wird Zeit für die kurze Grundkonfiguration. Die folgende Datei sollte, wie oben erwähnt, studiert werden. Für den Moment machen wir nur ein paar wenige Änderungen.

vi /etc/apache2/modules.d/mod_security/modsecurity_crs_10_config.conf

Für die Testphase ist es äußerst wichtig sicherzustellen, dass keine normalen Besucher geblockt werden! Dazu muss SecRuleEngine von "On" auf "DetectionOnly" gesetzt werden. Da es unter Garantie am Anfang unbeabsichtigte Treffer auf normale Aufrufe gibt (false positives) sollte dieser Parameter auf jeden Fall geändert werden!

SecRuleEngine DetectionOnly

Anschließend setzen wir den gewünschten Pfad zur Logdatei.

SecDebugLog /var/log/apache2/modsec_debug.log
SecAuditLog /var/log/apache2/modsec_audit.log

Für den Fall, dass du sehr lange Webseiten mit viel Inhalt hast, kann es sein, dass der folgende Defaulteintrag die Darstellung dieser Seiten verhindert.

SecResponseBodyLimit 524288

Man kann den Wert einfach erhöhen oder das Scannen des HTTP body in der Antwort ganz abschalten. (Dies bedeutet jedoch, dass ausgehende Daten nicht mehr überwacht werden. Wenn zum Beispiel durch ein Loch sicherheitsrelevante Daten abgerufen werden können, wie Creditkartendaten oder Passwörter, würde dies nicht mehr erkannt.)

SecResponseBodyAccess Off

Nun aktivieren wir mod_security.

/etc/init.d/apache2 restart

Da mod_security zur Zeit nur loggt und nichts sperrt sollte mit der Webseite alles unverändert bleiben. Trotzdem ist es ratsam dies zu kontrollieren.

Wenn nun ein verdächtiger Request auf den Server abgesetzt wird kann man eine detaillierte Verfolgung des Aufrufs in der Logdatei /var/log/apache2/modsec_audit.log verfolgen. Die Logdatei hat mehrere Bereiche pro Request. Jeder dieser Bereiche beginnt mit einem Code, der am Ende einen Großbuchstaben hat.

--ce603818-A--
...
--ce603818-F--
...
--ce603818-Z--

Dies bedeutet, dass alle Informationen zwischen --ce603818-A-- and --ce603818-Z-- zum selben Request gehören.

Nehmen wir als Beispiel den hypothetischen Aufruf von http://yourdomain/test.php?a=wget. Dieser wird wegen dem Shellkommando wget in der URL geblockt. Die Regel 950907 greift hier. In den Logs erscheinen folgende Informationen:

Message: Access denied with code 501 (phase 2). Pattern match "bwgetb" at ARGS:input. [id "950907"]
[msg "System Command Injection. Matched signature <wget>"] [severity "CRITICAL"]

Es ist wichtig auch die normalen Apache-Fehler-Logs zu prüfen. Manche Fehler die durch mod_security verursacht werden erscheinen hier. Ein Beispiel:

[Wed Nov 28 06:32:27 2007] [error] SecServerSignature: original signature too short.
Please set ServerTokens to Full.

Dieser Fehler kann behoben werden indem man "ServerTokens Full" in der httpd.conf ergänzt.

Es ist unabdingbar den Aufruf jeder URL zu prüfen und in den Logs nachzuschauen, um sicherzustellen das keine Regel bei einem normalen Aufruf greift. Sollte das doch der Fall sein kann die entsprechende Regel geändert werden. Eine Anleitung dazu findet sich bei den Links am Ende des Artikels. Eine andere Möglichkeit ist die Regel(n) in der Apachekonfiguration zu deaktivieren. Das folgende Beispiel schaltet die Regeln 950910 und 950013 für das Skript /private/test.pl ab. Dazu können die Zeilen einfach innerhalb des entsprechenden vhost-Kontextes eingetragen werden.

<LocationMatch "/private/test.pl">
SecRuleRemoveById 950910 950013
</LocationMatch>

Nach einiger Zeit ist mod_security so angepasst, dass keine Fehler mehr auftreten und keine normalen Besucher geblockt werden. Dann ist es Zeit in den Production-Mode umzuschalten:

SecRuleEngine On
SecDebugLogLevel 0

Letztlich ist alles nur eine Frage des Tunings der Regeln und der Konfiguration. Die Installation ist in wenigen Minuten abgeschlossen. Die Konfiguration auf einem großen System mit unzähligen Webanwendungen kann jedoch einige Zeit in Anspruch nehmen.

ModSecurity ist wirklich eine hervorragende Software! Einfach zu verwenden und trotzdem mit einem hohen Sicherheitsfaktor.

Links:

ModSecurity FAQ
ModSecurity Documentation
Core rules project page
Handling False Positives and Creating Custom Rules
Open Web Application Security Project

Härtung von Apache-Webservern
IDS/IPS-Systeme mit Snort