# 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.