Modsecurity
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