Apache ModSecurity 2 + Fail2ban   Vor kurzem aktualisiert!

 in Anleitungen / Apache / Debian / Server / Sicherheit  verschlagwortet Apache / Fail2Ban / modsecurity / OWASP / Roundcube / WAF

Praxis-Setup, OWASP CRS und Absicherung von Webmail & Autoconfig

Webserver sind permanent automatisierten Angriffen ausgesetzt. Besonders Mail- und Verwaltungsdienste wie Roundcube oder E-Mail Autoconfig-Endpunkte werden häufig gezielt gescannt. Eine Kombination zur Absicherung unter Linux (Debian 12) besteht aus ModSecurity (Version 2) zusammen mit Fail2ban und dem OWASP Core Rule Set (CRS).

Dieser Beitrag beschreibt, wie die Komponenten zusammenspielen, wie Angriffe erkannt werden und beispielhaft wie man Anwendungen stabil betreibt, ohne False Positives zu erzeugen.

Architektur: Verschiedene Ebenen

Das Sicherheitskonzept basiert auf drei Ebenen:

1) ModSecurity (WAF – Web Application Firewall)

ModSecurity analysiert HTTP-Requests in Echtzeit und blockiert verdächtige Muster wie:

  • Path Traversal (../../etc/passwd)
  • SQL Injection (' OR 1=1)
  • Remote Code Execution Versuche
  • Exploit-Scans (z. B. pearcmd, index.php?lang=...)

2) OWASP Core Rule Set (CRS)

Das OWASP Core Rule Set ist ein umfangreicher Satz von Sicherheitsregeln, der typische Webangriffe erkennt.

Wichtige Regelgruppen:

  • 93xxxx → Path Traversal / LFI / RFI
  • 94xxxx → Command Injection / RCE
  • 95xxxx → SQL Injection
  • 96xxxx → Protocol Violations / HTTP anomalies

Die Regeln sind die Grundlage für automatisierte Sicherheitsentscheidungen.

3) Fail2ban (reaktive Sperre)

Fail2ban überwacht Logs und bannt IP-Adressen, die wiederholt Angriffsversuche durchführen.

Typische Logsignale

Ein typischer Angriff, wie er in Logs erscheint:

/index.php?lang=../../../../../../usr/local/lib/php/pearcmd

Oder:

Access denied with code 403 ... ModSecurity: [id "932100"] ...

Diese Einträge stammen meist von automatisierten Scannern.

Warum Fail2ban + ModSecurity sinnvoll ist

ModSecurity blockt bereits den Angriff – aber:

  • Angreifer kommen oft wieder
  • Bots rotieren IPs
  • Logs werden massiv geflutet

Fail2ban sorgt dafür, dass:

  • wiederkehrende Angreifer dauerhafter oder länger gesperrt werden
  • Log-Rauschen reduziert wird
  • und die CPU-Last sinkt

Fail2ban Setup für ModSecurity

Ein häufiger Fehler ist zu breites Matching (z. B. alle 403).

❌ schlecht:

Access denied with code [45]\d\d

führt zu False Positives

✅ besser: nur echte CRS Exploits

# /etc/fail2ban/filter.d/apache-modsecurity.conf

[Definition]

failregex = ModSecurity:.*\[id "(93|94|95)\d+"\].*Access denied.*<HOST>
ignoreregex =

Jail-Konfiguration

[apache-modsecurity]
enabled  = true
port     = http,https
filter   = apache-modsecurity
logpath  = /var/log/apache2/*error.log

maxretry = 2
findtime = 600
bantime  = 604800

Ergebnis:

  • echte Angreifer → Ban
  • normale Nutzer → keine Probleme

*error.log erfasst alle Error-Logs in dem Verzeichnis

Beispiel: Roundcube Webmail absichern

Webmail-Systeme wie Roundcube sind besonders sensibel, da sie viele dynamische Requests erzeugen.

Empfohlene Anpassungen:

<Directory /var/www/roundcube>
    <IfModule security2_module>
        ....
        SecRuleRemoveByTag "attack-xss"
        SecRuleRemoveByTag "attack-sqli"
    </IfModule>
</Directory>

Warum?

  • E-Mail Inhalte enthalten oft HTML
  • Kalender/Contacts nutzen JSON/XML
  • CRS kann sonst legitime Requests blockieren

Beispiel: Autoconfig / Autodiscover

Autoconfig-Dienste (Apple Mail, Outlook) senden strukturierte XML-Anfragen:

<Directory /var/www/autoconfig>
    <IfModule security2_module>
        ...
        SecRuleRemoveByTag "protocol-violation"
    </IfModule>
</Directory>

Zusätzlich typische Rewrite-Regeln:

RewriteRule ^autodiscover/autodiscover\.xml$ index.php [L]
RewriteRule ^mail/config-v1\.1\.xml$ index.php [L]

Ziel:

  • E-Mail-Clients sollen zuverlässig funktionieren
  • ohne Sicherheitsregeln komplett zu deaktivieren

ModSecurity testen

Angriff simulieren:

curl "https://example.com/?x=../../../../etc/passwd"

Erwartung:

  • HTTP 403
  • Eintrag im Audit Log
  • optional Fail2ban Trigger

Logs prüfen:

tail -f /var/log/apache2/modsec_audit.log

Best Practices

Logging optimieren

in /etc/modsecurity/modsecurity.con

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

CRS Paranoia Level

  • PL1 → Standard (empfohlen)
  • PL2 → strenger (mehr False Positives möglich)

Fail2ban Tuning

maxretry = 2
findtime = 600
bantime = 7d

Die Kombination aus:

  • ModSecurity
  • OWASP Core Rule Set
  • Fail2ban

ergibt eine robuste Sicherheitsarchitektur

Der Schlüssel liegt nicht im „maximalen Blockieren“, sondern im gezielten Erkennen echter Exploits (93–95xxx Regeln) und dem sauberen Umgang mit legitimen Anwendungen wie Roundcube oder Autoconfig.

Und man erreicht mit dem Setup

  • Schutz vor automatisierten Exploits
  • stabilere Dienste
  • reduzierte False Positives
  • automatisierte IP-Abwehr
  • eine besser skalierbare Sicherheits-Architektur