Modsecurity: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 5: Zeile 5:
 
==Funktionsweise==
 
==Funktionsweise==
  
−
ModSecurity ist nur die Engine. Um Angriffe zu erkennen und zu blockieren, benötigt sie Regeln. Diese beschreiben:
+
ModSecurity ist nur die Engine. Um Angriffe zu erkennen und zu blockieren, benötigt sie '''Regeln'''. Diese beschreiben:
  
 
* Was in Anfragen geprüft wird
 
* Was in Anfragen geprüft wird
 
* Welche Aktion bei einem Regelverstoß erfolgt
 
* 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 Gruppen – sogenannten '''Rulesets''' – organisiert. Ab Version 3 können Regeln auch andere Regeln beeinflussen.
  
 
==Core Rule Set (CRS)==
 
==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.
+
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==
 
==Benutzerdefinierte Regeln==
Zeile 29: Zeile 29:
 
! ID-Bereich !! Verwendung
 
! ID-Bereich !! Verwendung
 
|-
 
|-
−
| 1–99.999 || Lokaler Gebrauch (interne Regeln, nicht verteilen)
+
| 1–99.999 || Reserviert für lokalen (internen) Gebrauch
 
|-
 
|-
−
| 100.000–199.999 || Oracle
+
| 100.000–199.999 || Regeln von Oracle
 
|-
 
|-
−
| 200.000–299.999 || Comodo
+
| 200.000–299.999 || Regeln von Comodo
 
|-
 
|-
−
| 300.000–399.999 || gotroot.com
+
| 300.000–399.999 || Regeln von gotroot.com
 
|-
 
|-
−
| 400.000–419.999 || Reserviert (frei)
+
| 400.000–419.999 || Ungenutzt (zur Reservierung verfügbar)
 
|-
 
|-
−
| 420.000–429.999 || ScallyWhack
+
| 420.000–429.999 || Regeln von ScallyWhack
 
|-
 
|-
−
| 430.000–439.999 || Flameeyes
+
| 430.000–439.999 || Regeln von Flameeyes
 
|-
 
|-
−
| 440.000–599.999 || Reserviert (frei)
+
| 440.000–599.999 || Ungenutzt (zur Reservierung verfügbar)
 
|-
 
|-
−
| 600.000–699.999 || Akamai
+
| 600.000–699.999 || Regeln von Akamai
 
|-
 
|-
−
| 700.000–799.999 || Ivan Ristic
+
| 700.000–799.999 || Regeln von Ivan Ristic
 
|-
 
|-
−
| 900.000–999.999 || OWASP Core Rule Set Projekt
+
| 900.000–999.999 || OWASP CRS
 
|-
 
|-
 
| 1.000.000–1.009.999 || Redhat Security Team
 
| 1.000.000–1.009.999 || Redhat Security Team
 
|-
 
|-
−
| 1.010.000–1.999.999 || Reserviert (frei)
+
| 1.010.000–1.999.999 || Ungenutzt (zur Reservierung verfügbar)
 
|-
 
|-
−
| 2.000.000–2.999.999 || SpiderLabs / Trustwave
+
| 2.000.000–2.999.999 || SpiderLabs Research Team (Trustwave)
 
|-
 
|-
−
| 3.000.000–3.999.999 || Akamai
+
| 3.000.000–3.999.999 || Regeln von Akamai
 
|-
 
|-
−
| 4.000.000–4.099.999 || AviNetworks
+
| 4.000.000–4.099.999 || Regeln von AviNetworks
 
|-
 
|-
−
| 4.100.000–4.199.999 || Fastly
+
| 4.100.000–4.199.999 || Regeln von Fastly
 
|-
 
|-
−
| 4.200.000 und mehr || Reserviert (frei)
+
| 4.200.000 und mehr || Ungenutzt (zur Reservierung verfügbar)
 
|}
 
|}
  
 
==Regel-Syntax==
 
==Regel-Syntax==
  
−
Jede Regel beginnt mit dem Schlüsselwort `SecRule` und besteht aus:
+
Jede Regel beginnt mit '''SecRule''' und besteht aus:
  
−
* **Variablen** – Welche Teile der Anfrage untersucht werden
+
* '''Variablen''' – zu prüfende Teile der Anfrage
−
* **Operatoren** – Wann eine Regel zutrifft
+
* '''Operatoren''' – Prüfbedingungen
−
* **Transformationen** – Wie Eingaben normalisiert werden
+
* '''Transformationen''' – Normalisierung der Daten
−
* **Aktionen** – Was bei Regelübereinstimmung geschieht
+
* '''Aktionen''' – Reaktion bei Regelmatch
  
−
Beispielstruktur:
+
Darstellung:
  
−
<pre>
+
  SecRule VARIABLEN "OPERATOR" "TRANSFORMATIONEN,AKTIONEN"
−
SecRule VARIABLEN "OPERATOR" "TRANSFORMATIONEN,AKTIONEN"
 
−
</pre>
 
  
 
===Wichtige Variablen===
 
===Wichtige Variablen===
Zeile 86: Zeile 84:
 
! Variable !! Bedeutung
 
! Variable !! Bedeutung
 
|-
 
|-
−
| ARGS || Alle Argumente inkl. POST-Daten
+
| ARGS || Alle Argumente inkl. POST-Nutzlast
 
|-
 
|-
 
| ARGS_GET || Nur GET-Parameter
 
| ARGS_GET || Nur GET-Parameter
 
|-
 
|-
−
| ARGS_POST || Nur POST-Body-Daten
+
| ARGS_POST || Nur POST-Body
 
|-
 
|-
−
| FILES || Hochgeladene Dateinamen
+
| FILES || Original-Dateinamen bei multipart/form-data
 
|-
 
|-
−
| FULL_REQUEST || Gesamte HTTP-Anfrage
+
| FULL_REQUEST || Gesamte HTTP-Anfrage (Zeile, Header, Body)
 
|-
 
|-
−
| QUERY_STRING || Nur Query-Teil der URL (raw)
+
| QUERY_STRING || Query-Anteil der URL (roh)
 
|-
 
|-
−
| REQUEST_BODY || Unverarbeiteter Body der Anfrage
+
| REQUEST_BODY || Rohdaten des Anfrage-Body
 
|-
 
|-
−
| REQUEST_HEADERS || Alle oder spezifische Header
+
| REQUEST_HEADERS || Alle oder bestimmte Header
 
|-
 
|-
−
| REQUEST_METHOD || HTTP-Methode (GET, POST, etc.)
+
| REQUEST_METHOD || HTTP-Methode (GET, POST, ...)
 
|-
 
|-
−
| REQUEST_URI || Pfad inkl. Query (/index.php?p=1)
+
| REQUEST_URI || Pfad inkl. Query-String (z. B. /index.php?p=1)
 
|}
 
|}
  
 
===Operatoren===
 
===Operatoren===
  
−
Operatoren beginnen mit `@` und beschreiben, wie geprüft wird – z. B.:
+
Operatoren beginnen mit '''@''' und geben das Vergleichsmuster an:
  
−
* `@rx` – Regulärer Ausdruck
+
* '''@rx''' – Regulärer Ausdruck
−
* `@streq` – String-Vergleich
+
* '''@streq''' – Stringvergleich
−
* `@contains`, `@pm`, etc.
+
* Weitere: @contains, @pm, ...
  
 
===Transformationen===
 
===Transformationen===
  
−
Transformationsfunktionen verändern (eine Kopie) der Daten vor dem Abgleich:
+
Transformationen normalisieren Daten vor dem Abgleich:
  
−
* `t:none`
+
* '''t:none'''
−
* `t:urlDecode`
+
* '''t:urlDecode'''
−
* `t:lowercase`
+
* '''t:lowercase'''
−
* `t:compressWhitespace`
+
* '''t:compressWhitespace'''
  
 
===Aktionen===
 
===Aktionen===
Zeile 129: Zeile 127:
 
! Kategorie !! Beschreibung
 
! Kategorie !! Beschreibung
 
|-
 
|-
−
| Disruptive || block, deny, allow – beeinflussen Transaktionsverlauf
+
| Disruptive || Aktionen mit Einfluss auf Transaktion (z. B. deny, allow)
 
|-
 
|-
−
| Non-disruptive || z. B. Variablen setzen (setvar), aber keine Blockierung
+
| Non-disruptive || z. B. Variablen setzen (hat keinen Einfluss auf Ablauf)
 
|-
 
|-
−
| Flow || Regelsteuerung: skip, skipAfter
+
| Flow || Steuerung des Regelablaufs (z. B. skip)
 
|-
 
|-
−
| Meta-data || Informationen: id, rev, severity, msg
+
| Meta-data || Metadaten wie id, msg, severity
 
|-
 
|-
−
| Data || Enthalten Werte für andere Aktionen (z. B. status)
+
| Data || Parameter für andere Aktionen (z. B. status)
 
|}
 
|}
  
 
==Beispiel: einfache Regel==
 
==Beispiel: einfache Regel==
  
−
<pre>
+
  SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"
−
SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"
 
−
</pre>
 
  
−
Erklärung:
+
Erläuterung:
  
−
* `REQUEST_URI`: überprüft URI der Anfrage
+
* '''REQUEST_URI''' – prüft Pfad der URL
−
* `@streq /index.php`: prüft auf exakten Match
+
* '''@streq /index.php''' – Stringvergleich auf Gleichheit
−
* `t:lowercase`: wandelt URI in Kleinbuchstaben um
+
* '''t:lowercase''' – in Kleinbuchstaben konvertieren
−
* `deny`: blockiert Anfrage
+
* '''deny''' – blockiert die Anfrage
  
−
==Beispiel: CRS-Regel==
+
==Beispiel: komplexe CRS-Regel==
  
−
<pre>
+
  SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)union.*?select.*?from" \
−
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx (?i)union.*?select.*?from" \
+
  "id:942270,\
−
"id:942270,\
+
  phase:2,\
−
phase:2,\
+
  block,\
−
block,\
+
  capture,\
−
capture,\
+
  t:none,t:urlDecodeUni,\
−
t:none,t:urlDecodeUni,\
+
  msg:'Looking for basic sql injection. Common attack string for mysql, oracle and others',\
−
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}',\
−
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
+
  tag:'application-multi',\
−
tag:'application-multi',\
+
  tag:'language-multi',\
−
tag:'language-multi',\
+
  tag:'platform-multi',\
−
tag:'platform-multi',\
+
  tag:'attack-sqli',\
−
tag:'attack-sqli',\
+
  tag:'paranoia-level/1',\
−
tag:'paranoia-level/1',\
+
  tag:'OWASP_CRS',\
−
tag:'OWASP_CRS',\
+
  tag:'capec/1000/152/248/66',\
−
tag:'capec/1000/152/248/66',\
+
  tag:'PCI/6.5.2',\
−
tag:'PCI/6.5.2',\
+
  ver:'OWASP_CRS/3.3.0',\
−
ver:'OWASP_CRS/3.3.0',\
+
  severity:'CRITICAL',\
−
severity:'CRITICAL',\
+
  setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
−
setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
+
  setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
−
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
 
−
</pre>
 
  
−
==Regex-Operator==
+
Diese Regel prüft mit einem regulären Ausdruck auf das Vorkommen typischer SQL-Injection-Bestandteile ('''union''', '''select''', '''from''').
  
−
Beispiel:
+
==Weitere Informationen==
  
−
<pre>
+
* '''Referenzhandbuch''': https://github.com/SpiderLabs/ModSecurity/wiki
−
@rx (?i)union.*?select.*?from
+
* '''CRS-Projekt''': https://coreruleset.org
−
</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
 

Aktuelle Version vom 27. Juli 2025, 07:29 Uhr

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:

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

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

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

Abgerufen von „http://wiki.ixheim.de/index.php?title=Modsecurity&oldid=64022“