ModSecurity Core Rule Sets und Eigene Regeln

ModSecurity ist eine plattformübergreifende Open-Source-WAF-Engine (Web Application Firewall) für Apache, IIS und NGINX, entwickelt von SpiderLabs (Trustwave). Sie bietet eine ereignisbasierte Programmiersprache zum Schutz vor Webangriffen, HTTP-Überwachung, Protokollierung und Echtzeitanalyse.

Funktionsweise

ModSecurity ist nur die Engine. Um Angriffe zu erkennen und zu blockieren, benötigt sie Regeln. Diese beschreiben:

Was in Anfragen geprüft wird
Welche Aktion bei einem Regelverstoß erfolgt

Regeln werden in *Rulesets* gruppiert, um eine breite Abdeckung sicherzustellen. Ab Version 3 können Regeln auch andere Regeln beeinflussen.

Core Rule Set (CRS)

Das OWASP CRS enthält generische Regeln gegen gängige Angriffsformen – inklusive der OWASP Top Ten – mit möglichst wenigen Fehlalarmen. Es eignet sich als Basisschutz für die meisten Webanwendungen.

Benutzerdefinierte Regeln

Änderungen am CRS vermeiden – erschwert spätere Updates.
Eigene Regeln in separaten Dateien pflegen.
Eigene Regeln dienen zur Erkennung spezifischer Angriffe oder zum Ausschluss von False Positives.

Regel-IDs

Jede Regel benötigt eine eindeutige ID. Eigene Regeln sollten ausschließlich im lokalen Bereich liegen:

ID-Bereich	Verwendung
1–99.999	Lokaler Gebrauch (interne Regeln, nicht verteilen)
100.000–199.999	Oracle
200.000–299.999	Comodo
300.000–399.999	gotroot.com
400.000–419.999	Reserviert (frei)
420.000–429.999	ScallyWhack
430.000–439.999	Flameeyes
440.000–599.999	Reserviert (frei)
600.000–699.999	Akamai
700.000–799.999	Ivan Ristic
900.000–999.999	OWASP Core Rule Set Projekt
1.000.000–1.009.999	Redhat Security Team
1.010.000–1.999.999	Reserviert (frei)
2.000.000–2.999.999	SpiderLabs / Trustwave
3.000.000–3.999.999	Akamai
4.000.000–4.099.999	AviNetworks
4.100.000–4.199.999	Fastly
4.200.000 und mehr	Reserviert (frei)

Regel-Syntax

Jede Regel beginnt mit dem Schlüsselwort `SecRule` und besteht aus:

**Variablen** – Welche Teile der Anfrage untersucht werden
**Operatoren** – Wann eine Regel zutrifft
**Transformationen** – Wie Eingaben normalisiert werden
**Aktionen** – Was bei Regelübereinstimmung geschieht

Beispielstruktur:

SecRule VARIABLEN "OPERATOR" "TRANSFORMATIONEN,AKTIONEN"

Wichtige Variablen

Variable	Bedeutung
ARGS	Alle Argumente inkl. POST-Daten
ARGS_GET	Nur GET-Parameter
ARGS_POST	Nur POST-Body-Daten
FILES	Hochgeladene Dateinamen
FULL_REQUEST	Gesamte HTTP-Anfrage
QUERY_STRING	Nur Query-Teil der URL (raw)
REQUEST_BODY	Unverarbeiteter Body der Anfrage
REQUEST_HEADERS	Alle oder spezifische Header
REQUEST_METHOD	HTTP-Methode (GET, POST, etc.)
REQUEST_URI	Pfad inkl. Query (/index.php?p=1)

Operatoren

Operatoren beginnen mit `@` und beschreiben, wie geprüft wird – z. B.:

`@rx` – Regulärer Ausdruck
`@streq` – String-Vergleich
`@contains`, `@pm`, etc.

Transformationen

Transformationsfunktionen verändern (eine Kopie) der Daten vor dem Abgleich:

`t:none`
`t:urlDecode`
`t:lowercase`
`t:compressWhitespace`

Aktionen

Kategorie	Beschreibung
Disruptive	block, deny, allow – beeinflussen Transaktionsverlauf
Non-disruptive	z. B. Variablen setzen (setvar), aber keine Blockierung
Flow	Regelsteuerung: skip, skipAfter
Meta-data	Informationen: id, rev, severity, msg
Data	Enthalten Werte für andere Aktionen (z. B. status)

Beispiel: einfache Regel

SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"

Erklärung:

`REQUEST_URI`: überprüft URI der Anfrage
`@streq /index.php`: prüft auf exakten Match
`t:lowercase`: wandelt URI in Kleinbuchstaben um
`deny`: blockiert Anfrage

Beispiel: CRS-Regel

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)union.*?select.*?from" \
"id:942270,\
phase:2,\
block,\
capture,\
t:none,t:urlDecodeUni,\
msg:'Looking for basic sql injection. Common attack string for mysql, oracle and others',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-sqli',\
tag:'paranoia-level/1',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/248/66',\
tag:'PCI/6.5.2',\
ver:'OWASP_CRS/3.3.0',\
severity:'CRITICAL',\
setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

Regex-Operator

Beispiel:

@rx (?i)union.*?select.*?from

Dieser Ausdruck sucht nach den SQL-Schlüsselwörtern `UNION`, `SELECT` und `FROM` – typischerweise ein Anzeichen für SQL Injection.

Weiterführende Infos

ModSecurity Referenz: https://github.com/SpiderLabs/ModSecurity/wiki
CRS Projekt: https://coreruleset.org

Modsecurity

Inhaltsverzeichnis