From e28b413ed609e88d34675d26dd6ae3c2edffc74f Mon Sep 17 00:00:00 2001 From: admManuel Date: Sat, 20 Sep 2025 19:49:15 +0000 Subject: [PATCH] Add owasp.md --- owasp.md | 220 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 220 insertions(+) create mode 100644 owasp.md diff --git a/owasp.md b/owasp.md new file mode 100644 index 0000000..ed38976 --- /dev/null +++ b/owasp.md @@ -0,0 +1,220 @@ +# OWASP CRS Exclusion Rules - Deutsche Dokumentation + +## Überblick + +Diese Dokumentation erklärt die OWASP Core Rule Set (CRS) Exclusion Rules Konfigurationsdatei `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf`. Diese Datei ermöglicht es, lokale Ausnahmen für deine Website zu definieren. + +## Zweck der Datei + +Die `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf` dient dazu: +- **Lokale Ausnahmen** für deine spezifische Website zu definieren +- **Bestimmte Transaktionen** von der Inspektion auszuschließen +- **Angewandte Regeln zu modifizieren** ohne die Original-CRS-Regeln direkt zu ändern + +## Wichtige Konzepte + +### Warum `.example` Erweiterung? + +Dateien mit `.example` Erweiterung sind für benutzerdefinierte Konfigurationen gedacht: +- Umbenennung zu `.conf` erforderlich für Aktivierung +- **Vorteil**: Updates überschreiben keine benutzerdefinierten Konfigurationen +- **Empfehlung**: Niemals Original-CRS-Regeln direkt modifizieren + +### Zwei Konfigurationsdateien + +| Datei | Zweck | Ladezeit | +|-------|-------|----------| +| `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS` | Regeln vor CRS-Verarbeitung | **ERSTE** | +| `RESPONSE-999-EXCLUSION-RULES-AFTER-CRS` | Regeln nach CRS-Verarbeitung | **LETZTE** | + +## ModSecurity Kontexte + +### Startup-Kontext +- Direktiven werden beim Start verarbeitet +- Regeln müssen **NACH** den zu modifizierenden Regeln platziert werden +- Für `SecRuleRemoveById` und ähnliche Direktiven + +### Per-Transaction-Kontext +- Regeln werden während der Transaktion verarbeitet +- `ctl`-Aktionen werden in der Reihenfolge der Regelplatzierung ausgeführt +- `ctl`-Aktionen müssen **VOR** den zu beeinflussenden Regeln stehen + +## Platzierungsregeln + +### In REQUEST-900-EXCLUSION-RULES-BEFORE-CRS platzieren: +``` +ctl:ruleEngine +ctl:ruleRemoveById +ctl:ruleRemoveByMsg +ctl:ruleRemoveByTag +ctl:ruleRemoveTargetById +ctl:ruleRemoveTargetByMsg +ctl:ruleRemoveTargetByTag +``` + +### In RESPONSE-999-EXCLUSION-RULES-AFTER-CRS platzieren: +``` +SecRuleRemoveById +SecRuleRemoveByMsg +SecRuleRemoveByTag +SecRuleUpdateActionById +SecRuleUpdateTargetById +SecRuleUpdateTargetByMsg +SecRuleUpdateTargetByTag +``` + +## Praktische Beispiele + +### 1. Autorisierte Clients ausschließen + +**Zweck**: Vulnerability Scanner von der Inspektion ausschließen + +```apache +# ASV-Netzwerk vollständig ausschließen (keine Blockierung oder Protokollierung) +SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \ + "id:1000,\ + phase:1,\ + pass,\ + nolog,\ + ctl:ruleEngine=Off" +``` + +**Erklärung**: +- Deaktiviert die komplette Rule Engine für IP 192.168.1.100 +- Nützlich für autorisierte Vulnerability Scanner +- Keine Logs, keine Blockierungen für diese IP + +### 2. Spezifische Parameter ausschließen + +**Zweck**: Password-Parameter von SQL-Injection-Regel ausschließen + +```apache +# SQL Injection Regel 942100 für password-Parameter ausschließen +SecRule REQUEST_URI "@beginsWith /index.php" \ + "id:1001,\ + phase:1,\ + pass,\ + nolog,\ + ctl:ruleRemoveTargetById=942100;ARGS:password" +``` + +**Erklärung**: +- Nur für URLs die mit `/index.php` beginnen +- Entfernt `ARGS:password` Parameter von Regel 942100 +- Verhindert False Positives bei Login-Formularen + +### 3. Parameter nach Angriffs-Tags ausschließen + +**Zweck**: Password-Feld von allen SQL-Injection-Regeln ausschließen + +```apache +# Alle SQL-Injection-Regeln für pwd-Parameter ausschließen +SecRule REQUEST_FILENAME "@endsWith /wp-login.php" \ + "id:1002,\ + phase:2,\ + pass,\ + nolog,\ + ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:pwd" +``` + +**Erklärung**: +- Gilt nur für WordPress Login-Seite +- Entfernt `ARGS:pwd` von allen Regeln mit Tag `attack-sqli` +- Effektive Methode für häufige False Positives + +### 4. Parameter von allen CRS-Regeln ausschließen + +**Zweck**: Komplette Ausnahme für bestimmte Parameter + +```apache +# Password-Parameter von ALLEN CRS-Regeln ausschließen +SecRule REQUEST_FILENAME "@endsWith /wp-login.php" \ + "id:1003,\ + phase:2,\ + pass,\ + nolog,\ + ctl:ruleRemoveTargetByTag=OWASP_CRS;ARGS:pwd" +``` + +**Erklärung**: +- Verwendet das universelle `OWASP_CRS` Tag +- Betrifft **NICHT** benutzerdefinierte Regeln +- Maximale Ausnahme für kritische Parameter + +### 5. Regel-Bereiche ausschließen + +**Zweck**: Ganze Kategorien von Regeln deaktivieren + +```apache +# Alle SQLi und XSS Regeln für Admin-Bereich deaktivieren +SecRule REQUEST_FILENAME "@beginsWith /admin" \ + "id:1004,\ + phase:2,\ + pass,\ + nolog,\ + ctl:ruleRemoveById=941000-942999" +``` + +**Wichtiger Hinweis**: +- ModSecurity v3 unterstützt **KEINE** Regel-Bereiche in `ruleRemoveById` +- Als Workaround `ruleRemoveByTag` verwenden +- Feature ist für v3.1 geplant + +### 6. Monitoring-Tools zulassen + +**Zweck**: Health Checker und Monitoring ausschließen + +```apache +# AWS Load Balancer Health Checker zulassen +SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8" \ + "id:1005,\ + phase:1,\ + pass,\ + nolog,\ + chain" + SecRule REQUEST_METHOD "@pm GET HEAD" "chain" + SecRule REQUEST_HEADERS:User-Agent "@pm ELB-HealthChecker" \ + "ctl:ruleRemoveById=911100,\ + ctl:ruleRemoveById=913100,\ + ctl:ruleRemoveById=920280,\ + ctl:ruleRemoveById=920350,\ + ctl:ruleRemoveByTag=attack-disclosure" +``` + +**Ausgeschlossene Regeln**: +- **911100**: Erlaubte HTTP-Methoden +- **913100**: Scanner-Erkennung +- **920280**: Fehlender/leerer Host Header +- **920350**: IP-Adresse im Host Header +- **attack-disclosure**: Alle Data Leakage Regeln + +## Best Practices + +### 1. Granulare Ausnahmen bevorzugen +- Verwende spezifische Regel-IDs statt breite Tags +- Beschränke Ausnahmen auf notwendige URIs/Parameter + +### 2. Dokumentation +- Kommentiere alle Ausnahmen ausführlich +- Erkläre den Grund für jede Ausnahme +- Füge Datum und Verantwortlichen hinzu + +### 3. Testing +- Teste Ausnahmen in einer Staging-Umgebung +- Verwende ModSecurity im Detection-Only Modus zum Testen +- Überprüfe Logs auf unerwartete Effekte + +### 4. Regelmäßige Überprüfung +- Überprüfe Ausnahmen bei CRS-Updates +- Entferne obsolete Ausnahmen +- Dokumentiere Änderungen + +## Zusätzliche Ressourcen + +- **Plugin Registry**: [github.com/coreruleset/plugin-registry](https://github.com/coreruleset/plugin-registry) +- **CRS Dokumentation**: Offizielle OWASP CRS Docs +- **ModSecurity Handbuch**: Detaillierte Konfigurationsreferenz + +## Fazit + +Die `REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf` ist ein mächtiges Werkzeug für die Feinabstimmung deiner WAF-Konfiguration. Durch sorgfältige Anwendung dieser Ausnahmeregeln kannst du False Positives reduzieren, ohne die Sicherheit zu kompromittieren. \ No newline at end of file