Pakete für jede Distribution

Wer das Paket für den Apache 2 nicht selbst übersetzen will, findet fertige Pakete für Debian, RHEL, Centos, Fedora, Free BSD, Gentoo und Windows. Voraussetzung für die manuelle Installation ist das Apache-Modul »mod_unique_id«, das nicht jede Distribution von Haus aus mitbringt. Der Admin bindet mit der Direktive »LoadModule security2_module modules/mod_security2.so« das Modul in die Konfigurationsdatei »httpd.conf« des Apache ein, wenn das nicht die Distribution selbst erledigt. Nach dem Neustart meldet der Webserver das Modul in seinem »error_log«.

Modsecurity kennt eine Fülle von Konfigurationsoptionen. Um seine Funktionsweise nachzuvollziehen, reicht aber bereits eine Grundkonfiguration. Die Option »SecRuleEngine« aktiviert den eigentlichen Filtermechanismus des Moduls und erlaubt Filterregeln abzuarbeiten. Mögliche Einstellungen sind neben »On« und »Off« noch »DetectionOnly«. Sie dient zur Beobachtung und sorgt dafür, dass das Modul nicht aktiv in eine Client-Server-Verbindung eingreift, selbst wenn einzelne Regeln so konfiguriert sind. Dies ist eine gute Einstellung, um das Modul und eigene Regeln zu testen.

Gerade am Anfang und zur Fehlersuche ist die Option »SecDebugLog« wichtig, da sie die Protokolldatei zur Fehlersuche festlegt, zum Beispiel mittels »SecDebugLog /var/log/httpd/modsec_debug.log«. Zusätzlich lässt sich mit dem Parameter »SecDebugLogLevel« die Detailfülle auf einer Skala von 0 bis 9 definieren, mit der das Modul die eigene Tätigkeit sowie die Verarbeitung der benutzerdefinierten Regeln kommentiert. Die Stufen 4 oder 5 eignen sich fürs Fine-Tuning oder zur Fehlersuche, im Produktivbetrieb stellt der Admin die Option wieder auf 0.

In fünf Stufen zur sicheren Anfrageverarbeitung

Der Parameter »SecDefaultAction« definiert das Standardverhalten von Modsecurity bei Anfragen, die auf eine vorhandene Filterregel zutreffen, für die der Systemverwalter aber keine eigene Aktion spezifiziert. Dazu erwartet die Option, dass der Anwender eine Verarbeitungsphase aus Tabelle 1 angibt, für die die Standardaktion gelten soll.

Modsecurity wendet Filterregeln in fünf verschiedenen Phasen der Verarbeitung und Beantwortung einer Clientanfrage an [4]. In der Praxis sind meist nur Phase 2, die Inhalte einer Clientanfrage filtert, also eingehende Daten, sowie Phase 4 relevant: Die kümmert sich um die Serverantwort, also um ausgehende Daten.

Zusätzlich legt der Admin mit der Option eine oder mehrere Aktionen fest, die die Software bei einem Match ergreift [5]. Um eingehende Clientanfragen in Phase 2 im Auditlog zu protokollieren und den versuchten Zugriff mit der HTTP-Fehlermeldung 403 ("Forbidden") zu unterbinden, notiert der Admin:

SecDefaultAction phase:2,log,auditlog,deny,status:403

Eine so negative Standardaktion wie Default Deny ist zwar sehr restriktiv, bietet aber größtmöglichen Schutz, wenn der Systemverwalter darüber hinaus geeignete Filter und Aktionen verfasst (siehe dazu den Leser-Aufruf im Kasten "Web-Experten gesucht!"). Dafür bietet die Software eine Reihe von vorgefertigten Alternativen an. Dazu zählen, Anfrageparameter umwandeln, externe Skripte etwa für einen Antiviren-Scan ausführen oder aber bösartige Anfragen weiterleiten. Letzteres dient dazu, die Angriffsversuche zu verstehen oder an einen Honeypot zu übergeben.

Die in Listing 1 vorgestellte Grundkonfiguration protokolliert außerdem den Inhalt eingegangener Anfragen sowie der gesendeten Antworten. Sie trägt die Informationen im erwähnten Auditlog ein. Die erste Direktive »SecAuditEngine« schaltet es ein. Die Option der zweiten Anweisung bestimmt, ob die Software die Einträge im Auditlog wie hier in einer Gesamtdatei (»Serial«) oder in jeweils einer Datei pro Transaktion speichert (»Concurrent«). Letzteres ist notwendig, wenn der Admin das Zusatzprodukt Modsecurity Console verwenden will: Die Software zum Steuern mehrerer Instanzen bietet Breach Security kostenlos an, wenn Anwender damit nicht mehr als drei Server überwachen.

01 SecRuleEngine On
02 SecAuditEngine On
03 SecAuditLogType Serial
04 SecAuditLog logs/audit.log
05 SecAuditLogParts ABCFHZ
06 SecDebugLog logs/debug.log
07 SecDebugLogLevel 5
08 SecRule REQUEST_URI "/etc/passwd"
09 SecDefaultAction phase:2,log,auditlog,deny,status:403

Die dritte Anweisung definiert den Speicherort des Auditlog relativ zum Installationspfad des Apache. Schließlich wählt die Anweisung »SecAuditLogParts« aus, welche Informationen Modsecurity im Auditlog protokolliert (siehe Tabelle 2). In diesem Fall sind das unter anderem Kopfteil und Inhalt der Anfrage sowie die Reaktion von Modsecurity. Das spätere Ergebnis zeigt Abbildung 1.

Abbildung 1: Sobald Modsecurity aktiv ist, loggt es – so detailliert wie in »SecAuditParts« angegeben – verdächtige Zugriffe, in diesem Fall eine SQL Injection.