Add owasp.md
This commit is contained in:
220
owasp.md
Normal file
220
owasp.md
Normal file
@@ -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.
|
||||||
Reference in New Issue
Block a user