Regeln festlegen

Nach diesen Vorbereitungen ergänzt der Admin seine Konfiguration durch die wichtigste Anweisung: »SecRule«. Sie definiert eine Filterregel und optional eine Aktion, die das Modul bei einer Übereinstimmung mit der Regel anstoßen soll. Notiert der Systemverwalter keine Aktion, führt das Tool die durch die Anweisung »SecDefaultAction« festgelegten Standardbefehl aus. Der Aufbau solcher Regeln folgt dem Muster:

SecRule Variable Operator [Aktion]

Die Anzahl der verfügbaren Variablen ist groß und umfasst auch alle Elemente einer Clientanfrage - sowohl bei »POST« als auch bei »GET« - sowie die wichtigsten Angaben zur Serverumgebung [6]. Zusätzlich darf der Anwender reguläre Ausdrücke verwenden. Um beispielsweise eine HTTP-Anfrage daraufhin zu untersuchen, ob der Client in ihr mittels der »GET«-Methode die Zeichenkette »/etc/passwd« anfragt, verfasst der Systemverwalter die Regel:

SecRule REQUEST_URI "/etc/passwd"

Trifft sie zu, löst Modsecurity die Standardaktion »deny« aus. Um per Filter auf einen Browsertyp zu prüfen, schreibt der Admin:

SecRule REQUEST_HEADERS:User-Agent "nikto"

Bei diesem Beispiel lehnt der Webserver Anfragen des Sicherheitsscanners Nikto ab [7]. Soll Modsecurity eine besondere Aktion für eine Regel auslösen, so lässt sich die Standardaktion überschreiben:

SecRule REQUEST_HEADERS:User-Agent "nikto" "phase:2,pass,msg:'Nikto-Scan geloggt'"

Diese Regel bedeutet, dass das Modul bei Anfragen des User-Agenten Nikto in einer Clientanfrage in Phase 2 die Nachricht »Nikto-Scan geloggt« in die Protokolldatei schreibt. Anschließend überschreibt die Regel die Standardaktion »drop« - definiert durch »SecDefaultAction« - durch die Aktion »pass«. Das lässt die Clientanfrage passieren. Um Modsecurity zu testen, fasst Listing 1 die vorgestellte Grundkonfiguration zusammen.

Den Ernstfall proben

Nach einem Neustart des Apache löst eine Anfrage wie »http://www.example.com/index.html?file=/etc/passwd« die Beispielregel aus Zeile 8 aus. Anschließend unterbindet die in Zeile 9 festgelegte Aktion die Anfrage. Der Client erhält einen HTTP-Error »403 Forbidden«. Zusätzlich schreibt Modsecurity wegen der Zeilen 3 bis 7 ein Protokoll der Transaktion ins Auditlog sowie eine detaillierte Übersicht über die Abarbeitung der Clientanfrage in das Debuglog. So findet der Admin in der Datei »error_log« des Apache dann einen Hinweis wie in Listing 2 auf das erfolgreiche Blockieren der Clientanfrage. Funktioniert Modsecurity wie erwartet, gilt es, Regeln zu ergänzen und der zu schützenden Webapplikation anzupassen.

01 LoadModule geoip_module modules/mod_geoip.so
02 LoadModule security2_module modules/mod_security2.so
03 GeoIPEnable On
04 GeoIPDBFile /usr/tmp/GeoLiteCity.dat
05 SecRuleEngine On
06 SecGeoLookupDb /usr/tmp/GeoLiteCity.dat
07 SecRule REMOTE_ADDR "@geoLookup" "chain,drop,msg:'Verbindungsversuch aus .CN!'"
08 SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"