Solange man als zweiten Parameter ebenfalls einen regulären Ausdruck verwendet, führt ModSecurity automatisch einen Mustervergleich durch. In den bisherigen Beispielen war dies immer eine einfache Textsuche, selbstverständlich sind aber auch beliebig komplexere Varianten möglich. Die folgende Regel stellt beispielsweise sicher, dass in der Anfrage keine Argumente enthalten waren:
SecRule &ARGS !^0$
Die Auswertung der regulären Ausdrücke übernimmt im Hintergrund die PCRE Bibliothek, die im wesentlichen alle unter Perl bekannten Konstrukte erlaubt.
Sobald man die Pfade der Mustererkennung verlässt, muss man den gewünschten Operator explizit mit angeben. Dies geschieht über einen Klammeraffen
»@
«
, dem der Name des Operators folgt. Beispielsweise stellt
SecRule ARGS "@validateUtf8Encoding"
sicher, dass die Anfrage die UTF-8 Zeichenkodierung nutzt. Für Zahlenspiele bietet ModSecurity die Vergleichsoperationen
»gt
«
(größer als),
»ge
«
(größer gleich),
»eq
«
(gleich),
»le
«
(kleiner gleich) und
»lt
«
(kleiner als). Damit testet beispielsweise:
SecRule &ARGS "@ge 3"
ob es in der Anfrage mehr als drei Parameter gibt. Besonders interessant ist auch der Operator
»inspectFile
«
, der ein externes Skript zu Rate zieht:
SecRule FILES_TMPNAMES "@inspectFile ↩/Pfad/zu/pruefe.pl"
Alle im Request gesendeten Dateien übergibt ModSecurity an das Perl-Skript
»pruefe.pl
«
, hinter dem beispielsweise ein Virenscanner stecken könnte. Dessen Exit-Code entscheidet darüber, ob die Regel letztendlich greift oder nicht. Für die Prüfung gegen eine Blacklist sorgt
»rbl
«
:
SecRule REMOTE_ADDR "@rbl meine.blacklist↩ .org"
Wer mag, darf auf die Kurzschreibweise bei den regulären Ausdrücken verzichten und den zugehörigen Operator
»rx
«
(für
»R
«
egular e
»X
«
pression) mitschreiben:
SecRule REQUEST_URI "@rx attack"
Wie die Beispiele zeigen, können Operatoren selbst weitere Parameter fordern. Damit durch die zusätzlichen Leerzeichen keine Verwirrung entsteht, ist das gesamte Gebilde durch Anführungszeichen zu begrenzen.
Neben der reinen Abweisung einer Anfrage, kennt ModSecurity noch viele weitere Aktionen. Diese sind so zahlreich, dass sie zur besseren Übersicht in folgende Gruppen aufgeteilt wurden:
Die derzeit gültige Standard-Aktion legt
»SecDefaultAction
«
fest. Da ModSecurity die Regeln nacheinander abarbeitet, darf man sie auch mittendrin wechseln. Auf diese Weise lassen sich Regelblöcke mit verschiedenen Standard-Aktionen schaffen.
Unterbrechende Aktionen beenden grundsätzlich die Verarbeitung einer Anfrage. Dazu gehört in erster Linie der bislang verwendete Standard
»deny
«
. Er stoppt die Transaktion und liefert eine Fehlermeldung zurück.
»drop
«
geht noch einen Schritt weiter und verwirft die Transaktion ohne jegliche Rückmeldung, was sich insbesondere bei Denial-of-Service Attacken (DoS) anbietet.
»redirect
«
und
»proxy
«
sorgen für eine Weiterleitung,
»proxy
«
führt dabei auf einen anderen Server:
SecRule ARGS attack "proxy:'http//Server'"
»pause
«
legt eine Anfrage für eine definierbare Zeit auf Eis und verlangsamt so die Transaktion.
Eine Regel darf durchaus mehrere Aktionen gleichzeitig auslösen. Dies ist besonders sinnvoll im Zusammenspiel mit den nicht-unterbrechenden Aktionen, wie beispielsweise
»log
«
und den Metadaten verarbeitenden, wie
»msg
«
:
SecRule REQUEST_URI "attack" "log,deny,↩ msg:'Das Wort attack trat auf'"
»log
«
teilt ModSecurity zunächst mit, dass die erfüllte Regel auf jeden Fall später im Protokoll auftauchen muss.
»deny
«
sorgt gleichzeitig für einen Abbruch der Verarbeitung. Abschließend wandert noch der Text in den Hochkomma hinter
»msg
«
ins Audit-Log.
Zu den nicht-unterbrechenden Aktionen zählt auch
»exec
«
, das ein externes Programm aufruft:
SecRule ARGS "virus" "setenv:SEARCH=↩ 'INTESIV',exec:'/usr/bin/virenscanner.pl'"
»setenv
«
setzt noch die aus CGI-Programmen bekannten Umgebungsvariable
»SEARCH
«
, die der dann aufgerufene
»virenscanner.pl
«
auswertet.
ModSecurity Core Rule Set Project
Montag, 08. August 2011 15:35:33