Modsecurity: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
==ModSecurity Core Rule Sets und Eigene Regeln==
+
*[[Modsecurity Erklärung]]
 
+
*[[Nginx mit Modsecurity]]
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.
+
*[[Nginx mit Modsecurity Rocky]]
 
+
*[[Nginx mit Modsecurity Whitelists]]
==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
 

Aktuelle Version vom 23. August 2025, 17:34 Uhr