Die Filterregeln beschreiben, in welcher Situation ModSecurity welche Maßnahmen ergreift. Jede Regel ist gleichen aufgebaut:
SecRule Variablen Operator Aktionen
Daran hält sich selbstverständlich auch die eingangs verwendete Testregel:
SecRule REQUEST_URI attack deny
Bei der Auswertung einer Regel bestimmt das Modul zunächst den Wert der Variablen, die festlegen, was das Modul prüfen soll. Die Variable
»REQUEST_URI
«
enthält beispielsweise die URL der HTTP-Anfrage. Welche Variablen ModSecurity sonst noch unterstützt, verrät die extrem lange Liste in der mitgelieferten Dokumentation
[3]
. Bei einer leeren Variable greift die Regel übrigens grundsätzlich nicht.
Im nächsten Schritt wendet ModSecurity auf diesen Wert den Operator an. Er bestimmt folglich, wie der Wert zu prüfen ist. Beispielsweise könnte er nach der Zeichenkette
»attack
«
fahnden. Wenn der Operator eine Übereinstimmung feststellt, führt das Modul die Aktion aus. Fehlt letztere, so zieht ModSecurity die für diese Situation festgelegte Standard-Aktion heran. Ohne weitere Eingriffe bedeutet dies ein Abblocken mit dem bekannten 403-Fehler.
Einige Variablen sind Collections, speichern also selbst wieder mehrere Variablen. Beispielsweise enthält
»ARGS
«
die Werte aller HTTP-Parameter der jeweiligen Anfrage. Ein
SecRule ARGS attack
prüft alle Parameter durch. Enthält auch nur einer von ihnen die Zeichenkette
»attack
«
, stoppt ModSecurity die Verarbeitung. Die Anzahl der in einer Collection enthaltenen Variablen liefert ein vorangestelltes
»&
«
:
SecRule &ARGS 2
Diese Regel greift, wenn die Anfrage genau zwei Argumente enthält. Mit Hilfe logischer Operatoren lassen sich mehrere Regeln zu einer zusammenfassen:
SecRule "REQUEST_URI|QUERY_STRING" attack
Dies blockt die Anfrage, sobald
»attack
«
entweder in
»REQUEST_URI
«
oder dem
»QUERY_STRING
«
auftaucht. Bei der Verkettung von Variablen erlaubt ModSecurity sogar den Einsatz von beliebig komplexen regulären Ausdrücken.
ModSecurity Core Rule Set Project
Montag, 08. August 2011 15:35:33