Seite 3: Und Action!

Inhaltsverzeichnis

Die einfachen Filterregeln von mod_security haben das Format SecFilter AUSDRUCK [AKTION] und werden folgendermaßen interpretiert: Wenn der angegebene Suchausdruck (genau genommen ein regulärer Ausdruck) auf eine ein- oder ausgehende HTTP-Anfrage zutrifft, wird die angegebene Aktion ausgeführt. Ist keine Aktion explizit angegeben, wird die durch die Konfigurationsoption SecFilterDefaultAction spezifizierte Aktion durchgeführt.

Und Action!

Die möglichen Aktionen, von denen sich für eine Filterregel auch mehrere durch Komma getrennt angeben lassen, sind in vier Klassen eingeteilt:

• Primäre Aktionen bestimmen direkt, wie die Bearbeitung einer Anfrage fortgesetzt werden soll. allow beispielsweise reicht die Anfrage ohne weitere Prüfungen unverändert zum Webserver-Prozess durch und pass fährt mit der folgenden Filterregel fort. deny hingegen verwirft sie vollständig. Mit redirect:URL ist eine Umleitung zu der angegebenen URL möglich. Jede Filterregel benötigt eine solche Primäraktion.
• Des weiteren kann man beliebig viele sekundäre Aktionen angeben. log beispielsweise nimmt einen entsprechenden Log-Eintrag vor, wenn die Regel zutrifft und mit exec:PROGRAMMNAME lassen sich externe Programme oder Skripte starten.
• Fluss-Aktionen beeinflussen die Reihenfolge, in der die Filterregeln abgearbeitet werden. chain entspricht der logischen Verknüpfung "und" mit der darauf folgenden Regel. Mit skipnext:N ist es möglich, die folgenden N Regeln zu überspringen.
• Parameter sind keine wirklichen Aktionen, nehmen jedoch Einfluss darauf. Ein wichtiger Parameter in obigem Beispiel ist status:403, der die entprechende Serverantwort bei der Aktion deny steuert.
  

Eine vollständige Liste aller Aktionen und Parameter befindet sich in der Dokumentation auf der mod_security-Homepage [1].

Verfeinerung

Bei genauerer Betrachtung erweist sich die Arbeit mit SecFilter schnell als zu ungenau. Es werden stets die vollständige Anfrage sowie die gesamten bei POST-Zugriffen übertragenen Daten durchsucht. Dies führt in der Regel zu schwer vorhersehbaren False-Positives und sollte nur sehr bedacht eingesetzt werden. Wesentlich feinere Abfragen lassen sich mit SecFilterSelective erzielen, welches vor dem eigentlichen Suchmuster noch eine oder mehrere durch das Pipe-Symbol | getrennte Ortsangaben benötigt, auf die die Suche eingeschränkt werden soll. Ersetzt man in obiger Minimalkonfiguration die Filterregel durch folgenden Block aus Beispiel-Regeln, rückt mod_security nach einem Apache-Reload ab von dem ungenauen Schrotschussverfahren:

SecFilterSelective ARGS "wget\x20"
 SecFilterSelective ARGS "<[[:space:]]*script"
 SecFilterSelective ARG_highlight "%27"
 SecFilterSelective ARG_username "^admin$" chain
 SecFilterSelective REMOTE_ADDR "!^192.168.0.2$"

In der ersten Filterregel ist zusätzlich zum einfachen Suchmuster als Ort ARGS angegeben. Das Suchmuster wird dadurch lediglich auf die Variablen-Argumente der Anfrage losgelassen, und zwar sowohl auf die Argumente hinter der URL als auch auf Argumente, die in einem eventuellen POST-Request übermittelt werden.

Der in der zweiten Filterregel angegebene reguläre Ausdruck schlägt bei vielen gängigen Cross-Site-Skripting-Angriffen an, die in der Regel darauf angewiesen sind, Script-Tags in HTTP-Anfragen einzubetten.

Die dritte Filterregel ist speziell auf HTTP-Requests des phpBB-Wurms Santy.A ausgelegt. Dieser versuchte durch geschickt platzierte Hochkommata (%27 entspricht dem Zeichen ') in der Variablen highlight, eine kritische Lücke in dem Forensystem zur Ausführung von beliebigem Schad-Code auszunutzen.

Die vierte Filterregel liefert ein Beispiel für eine Verkettung mit der folgenden Regel durch chain: Das Forensystem phpBB übergibt den Benutzernamen in der POST-Variablen username. Somit trifft der angegebene reguläre Ausdruck auf Login-Versuche eines Administrators namens "admin" zu. In diesem Fall kommt die folgende Filterregel zur Ausführung, die den Zugriff verweigert, wenn der anfragende Rechner nicht die IP-Adresse 192.168.0.2 besitzt. Kurz gefasst, beschränken die beiden letzten Regeln einen Admin-Login für phpBB auf besagte IP-Adresse.

mod_security kennt viele weitere Suchorte. Beispielsweise ist es möglich, den Namen einer der bekannten CGI-Variablen wie REMOTE_ADDR anzugeben, um deren Wert zu überprüfen. Spezielle Orte wie COOKIE_NAMES oder HEADERS schränken die Suche auf Namen von Cookies beziehungsweise auf den Header der HTTP-Anfrage ein. Die vollständige Liste der unterstützend Suchorte ist auf der mod_security-Homepage [1] dokumentiert.