Web-Application-Firewall (ModSecurity & OWASP CRS) unter Virtualmin für Vereins-Websites richtig einrichten

Vereins-Websites sind oft ein beliebtes Ziel für Angreifer: Sie enthalten sensible Mitgliederdaten, bieten oft Formulare und manchmal sogar eine Nextcloud-Instanz für den internen Austausch. Eine Web-Application-Firewall (WAF) wie ModSecurity mit dem OWASP Core Rule Set (CRS) kann solchen Angriffen effektiv vorbeugen. Doch die Konfiguration unter Virtualmin will wohlüberlegt sein, damit legitime Funktionen wie DSGVO-konforme Mitgliederformulare oder die Nextcloud-Synchronisation nicht gestört werden.

Warum eine WAF für Vereins-Websites sinnvoll ist

Vereins-Websites verwalten häufig personenbezogene Daten und bieten Angriffsflächen wie Kontaktformulare, Login-Bereiche oder Cloud-Dienste. SQL-Injection, Cross-Site-Scripting (XSS) und Brute-Force-Angriffe gehören zu den häufigsten Bedrohungen. Eine WAF filtert bösartige Anfragen bereits auf Webserver-Ebene, bevor sie die Anwendung erreichen. ModSecurity ist der De-facto-Standard und lässt sich unter Virtualmin komfortabel aktivieren.

ModSecurity und OWASP CRS unter Virtualmin installieren

Virtualmin bietet eine integrierte Unterstützung für ModSecurity. Je nach Betriebssystem kannst du es über das Paketmanagement installieren. Für Debian/Ubuntu:

apt install libapache2-mod-security2

Für CentOS/RHEL:

yum install mod_security

Anschließend aktivierst du das Modul und lädst das OWASP Core Rule Set herunter. Unter Virtualmin kannst du die Konfiguration bequem über die Oberfläche unter Serverkonfiguration → Webanwendungs-Firewall vornehmen. Alternativ bearbeitest du die Dateien manuell.

Grundkonfiguration: ModSecurity im DetectionOnly-Modus starten

Bevor du Regeln scharf schaltest, solltest du ModSecurity zunächst im DetectionOnly-Modus betreiben. So werden Angriffe nur protokolliert, aber nicht blockiert. Das verhindert, dass legitime Vereinsfunktionen versehentlich gestört werden. In der Datei /etc/modsecurity/modsecurity.conf setzt du:

SecRuleEngine DetectionOnly

Nach einer Testphase kannst du auf On umstellen.

OWASP Core Rule Set einbinden und anpassen

Das CRS bietet einen umfassenden Schutz, ist aber sehr streng. Für Vereins-Websites empfehlen sich folgende Anpassungen:

• Paranoia-Level: Starte mit PL1 (Standard). Höhere Level blockieren mehr, erzeugen aber auch mehr False Positives.
• Ausnahmen definieren: Bestimmte Parameter, die oft fälschlich als Angriff erkannt werden (z. B. bei Mitgliederformularen), kannst du gezielt freigeben.
• Nextcloud-Ausnahmen: Die Synchronisation von Nextcloud nutzt spezielle Header und Parameter, die das CRS als verdächtig einstufen kann. Füge Ausnahmen für die Nextcloud-Endpunkte hinzu.

Beispiel: Ausnahme für ein DSGVO-konformes Mitgliederformular

Angenommen, dein Formular sendet ein Feld nachricht, das HTML enthalten darf. Dann könntest du folgende Regel in eine eigene Konfigurationsdatei schreiben:

SecRuleUpdateTargetById 942100 "!ARGS:nachricht"

Oder du deaktivierst bestimmte Regeln für den Pfad /mitgliederformular:

SecRule REQUEST_URI "@beginsWith /mitgliederformular" "id:1000,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:nachricht"

So bleibt der Schutz für andere Bereiche erhalten, während das Formular weiterhin funktioniert.

Nextcloud-Synchronisation nicht blockieren

Nextcloud verwendet oft lange URLs mit vielen Parametern. Das CRS könnte dies als SQL-Injection oder XSS interpretieren. Füge daher Ausnahmen für die Nextcloud-Instanz hinzu. Eine pauschale Freigabe des Pfades /nextcloud ist möglich, sollte aber wohlüberlegt sein:

SecRule REQUEST_URI "@beginsWith /nextcloud" "id:1001,phase:1,pass,nolog,ctl:ruleEngine=Off"

Besser ist es, nur bestimmte Regeln zu deaktivieren, die häufig False Positives auslösen. Teste die Synchronisation nach jeder Änderung gründlich.

Brute-Force-Angriffe blockieren

Neben ModSecurity solltest du auch Fail2ban einsetzen, um Brute-Force-Angriffe auf Login-Seiten zu stoppen. Virtualmin bringt Fail2ban oft schon mit. Konfiguriere es so, dass es bei zu vielen fehlgeschlagenen Login-Versuchen die IP sperrt. ModSecurity kann ebenfalls Brute-Force erkennen, jedoch ist Fail2ban für diesen Zweck oft effizienter.

Regelmäßige Überprüfung und Log-Analyse

Überwache die ModSecurity-Logs (z. B. /var/log/modsec_audit.log) regelmäßig. So erkennst du False Positives und kannst die Regeln weiter verfeinern. Virtualmin bietet hierfür eine komfortable Log-Ansicht. Achte auch auf die Performance: Eine zu strikte WAF kann die Ladezeiten erhöhen.

Fazit: Sicherheit und Funktionalität in Einklang bringen

Mit ModSecurity und dem OWASP CRS schützt du deine Vereins-Website effektiv vor gängigen Angriffen. Wichtig ist eine sorgfältige Konfiguration, die legitime Anwendungen wie Mitgliederformulare oder Nextcloud nicht beeinträchtigt. Teste Änderungen immer im DetectionOnly-Modus und definiere gezielte Ausnahmen. So bleibt deine Website sicher und DSGVO-konform.

Für ein sicheres Hosting deiner Vereins-Website empfehlen wir unsere Webhosting-Pakete und Domains. Bei Fragen steht dir unser Support gerne zur Verfügung.