Modsecurity - Versionsgeschichte

Thomas.will am 23. August 2025 um 17:34 Uhr

2025-08-23T17:34:54Z

Thomas.will: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*Modsecurity Erklärung“

2025-08-23T17:33:12Z

Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*Modsecurity Erklärung“

Thomas.will am 27. Juli 2025 um 07:29 Uhr

2025-07-27T07:29:06Z

Thomas.will am 27. Juli 2025 um 07:28 Uhr

2025-07-27T07:28:53Z

Änderungen zeigen

Thomas.will: /* Funktionsweise */

2025-07-27T07:26:22Z

Funktionsweise

Thomas.will am 27. Juli 2025 um 07:25 Uhr

2025-07-27T07:25:51Z

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, IIS…“

2025-07-27T07:25:34Z

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, IIS…“

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 *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:

{| class="wikitable"
! 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:

<pre>
SecRule VARIABLEN "OPERATOR" "TRANSFORMATIONEN,AKTIONEN"
</pre>

===Wichtige Variablen===

{| class="wikitable"
! 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===

{| class="wikitable"
! 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==

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

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==

<pre>
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}'"
</pre>

==Regex-Operator==

Beispiel:

<pre>
@rx (?i)union.*?select.*?from
</pre>

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

← Nächstältere Version		Version vom 23. August 2025, 17:34 Uhr
Zeile 1:		Zeile 1:
	*[[Modsecurity Erklärung]]		*[[Modsecurity Erklärung]]
		+	*[[Nginx mit Modsecurity]]
		+	*[[Nginx mit Modsecurity Rocky]]
		+	*[[Nginx mit Modsecurity Whitelists]]

← Nächstältere Version		Version vom 23. August 2025, 17:33 Uhr
Zeile 1:		Zeile 1:
−	~~==ModSecurity Core Rule Sets und Eigene Regeln==~~	+	*[[Modsecurity Erklärung]]
−
−	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

← Nächstältere Version		Version vom 27. Juli 2025, 07:29 Uhr
Zeile 1:		Zeile 1:
−	=ModSecurity Core Rule Sets und Eigene Regeln=	+	==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.		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.

← Nächstältere Version		Version vom 27. Juli 2025, 07:25 Uhr
Zeile 1:		Zeile 1:
−	=ModSecurity Core Rule Sets und Eigene Regeln=	+	==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.		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.

@@ Zeile 10: / Zeile 10: @@
 * 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.
+Regeln werden in '''Rulesets''' gruppiert, um eine breite Abdeckung sicherzustellen. Ab Version 3 können Regeln auch andere Regeln beeinflussen.
 ==Core Rule Set (CRS)==