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