Thomas.will: Die Seite wurde neu angelegt: „ ==ModSecurity Core Rule Sets und Eigene Regeln== ModSecurity ist eine plattformübergreifende Open-Source-WAF-Engine (Web Application Firewall) für Apache,…“

2025-08-23T17:33:20Z

Die Seite wurde neu angelegt: „ ==ModSecurity Core Rule Sets und Eigene Regeln== ModSecurity ist eine plattformübergreifende Open-Source-WAF-Engine (Web Application Firewall) für Apache,…“

Neue Seite

==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 Gruppen – sogenannten '''Rulesets''' – organisiert. 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:

{| class="wikitable"
! ID-Bereich !! Verwendung
|-
| 1–99.999 || Reserviert für lokalen (internen) Gebrauch
|-
| 100.000–199.999 || Regeln von Oracle
|-
| 200.000–299.999 || Regeln von Comodo
|-
| 300.000–399.999 || Regeln von gotroot.com
|-
| 400.000–419.999 || Ungenutzt (zur Reservierung verfügbar)
|-
| 420.000–429.999 || Regeln von ScallyWhack
|-
| 430.000–439.999 || Regeln von Flameeyes
|-
| 440.000–599.999 || Ungenutzt (zur Reservierung verfügbar)
|-
| 600.000–699.999 || Regeln von Akamai
|-
| 700.000–799.999 || Regeln von Ivan Ristic
|-
| 900.000–999.999 || OWASP CRS
|-
| 1.000.000–1.009.999 || Redhat Security Team
|-
| 1.010.000–1.999.999 || Ungenutzt (zur Reservierung verfügbar)
|-
| 2.000.000–2.999.999 || SpiderLabs Research Team (Trustwave)
|-
| 3.000.000–3.999.999 || Regeln von Akamai
|-
| 4.000.000–4.099.999 || Regeln von AviNetworks
|-
| 4.100.000–4.199.999 || Regeln von Fastly
|-
| 4.200.000 und mehr || Ungenutzt (zur Reservierung verfügbar)
|}

==Regel-Syntax==

Jede Regel beginnt mit '''SecRule''' und besteht aus:

* '''Variablen''' – zu prüfende Teile der Anfrage
* '''Operatoren''' – Prüfbedingungen
* '''Transformationen''' – Normalisierung der Daten
* '''Aktionen''' – Reaktion bei Regelmatch

Darstellung:

SecRule VARIABLEN "OPERATOR" "TRANSFORMATIONEN,AKTIONEN"

===Wichtige Variablen===

{| class="wikitable"
! Variable !! Bedeutung
|-
| ARGS || Alle Argumente inkl. POST-Nutzlast
|-
| ARGS_GET || Nur GET-Parameter
|-
| ARGS_POST || Nur POST-Body
|-
| FILES || Original-Dateinamen bei multipart/form-data
|-
| FULL_REQUEST || Gesamte HTTP-Anfrage (Zeile, Header, Body)
|-
| QUERY_STRING || Query-Anteil der URL (roh)
|-
| REQUEST_BODY || Rohdaten des Anfrage-Body
|-
| REQUEST_HEADERS || Alle oder bestimmte Header
|-
| REQUEST_METHOD || HTTP-Methode (GET, POST, ...)
|-
| REQUEST_URI || Pfad inkl. Query-String (z. B. /index.php?p=1)
|}

===Operatoren===

Operatoren beginnen mit '''@''' und geben das Vergleichsmuster an:

* '''@rx''' – Regulärer Ausdruck
* '''@streq''' – Stringvergleich
* Weitere: @contains, @pm, ...

===Transformationen===

Transformationen normalisieren Daten vor dem Abgleich:

* '''t:none'''
* '''t:urlDecode'''
* '''t:lowercase'''
* '''t:compressWhitespace'''

===Aktionen===

{| class="wikitable"
! Kategorie !! Beschreibung
|-
| Disruptive || Aktionen mit Einfluss auf Transaktion (z. B. deny, allow)
|-
| Non-disruptive || z. B. Variablen setzen (hat keinen Einfluss auf Ablauf)
|-
| Flow || Steuerung des Regelablaufs (z. B. skip)
|-
| Meta-data || Metadaten wie id, msg, severity
|-
| Data || Parameter für andere Aktionen (z. B. status)
|}

==Beispiel: einfache Regel==

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

Erläuterung:

* '''REQUEST_URI''' – prüft Pfad der URL
* '''@streq /index.php''' – Stringvergleich auf Gleichheit
* '''t:lowercase''' – in Kleinbuchstaben konvertieren
* '''deny''' – blockiert die Anfrage

==Beispiel: komplexe 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}'"

Diese Regel prüft mit einem regulären Ausdruck auf das Vorkommen typischer SQL-Injection-Bestandteile ('''union''', '''select''', '''from''').

==Weitere Informationen==

* '''Referenzhandbuch''': https://github.com/SpiderLabs/ModSecurity/wiki
* '''CRS-Projekt''': https://coreruleset.org

Modsecurity Erklärung - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „ ==ModSecurity Core Rule Sets und Eigene Regeln== ModSecurity ist eine plattformübergreifende Open-Source-WAF-Engine (Web Application Firewall) für Apache,…“