Boilerplates/owasp.md

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

# 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

# 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

# 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

# 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

# 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

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