Setting Up Web Application Firewall (ModSecurity & OWASP CRS) Correctly Under Virtualmin for Association Websites

Association websites are often a popular target for attackers: they contain sensitive member data, often offer forms, and sometimes even a Nextcloud instance for internal exchange. A web application firewall (WAF) like ModSecurity with the OWASP Core Rule Set (CRS) can effectively prevent such attacks. However, the configuration under Virtualmin must be well thought out so that legitimate functions such as GDPR-compliant member forms or Nextcloud synchronization are not disrupted.

Why a WAF Makes Sense for Association Websites

Association websites frequently manage personal data and offer attack surfaces such as contact forms, login areas, or cloud services. SQL injection, cross-site scripting (XSS), and brute-force attacks are among the most common threats. A WAF filters malicious requests at the web server level before they reach the application. ModSecurity is the de facto standard and can be conveniently activated under Virtualmin.

Installing ModSecurity and OWASP CRS Under Virtualmin

Virtualmin offers integrated support for ModSecurity. Depending on the operating system, you can install it via the package manager. For Debian/Ubuntu:

apt install libapache2-mod-security2

For CentOS/RHEL:

yum install mod_security

Then activate the module and download the OWASP Core Rule Set. Under Virtualmin, you can conveniently make the configuration via the interface under Server Configuration → Web Application Firewall. Alternatively, you can edit the files manually.

Basic Configuration: Start ModSecurity in DetectionOnly Mode

Before you enable rules, you should first run ModSecurity in DetectionOnly mode. This way, attacks are only logged but not blocked. This prevents legitimate association functions from being accidentally disrupted. In the file /etc/modsecurity/modsecurity.conf, set:

SecRuleEngine DetectionOnly

After a test phase, you can switch to On.

Integrating and Customizing the OWASP Core Rule Set

The CRS offers comprehensive protection but is very strict. For association websites, the following adjustments are recommended:

• Paranoia Level: Start with PL1 (default). Higher levels block more but also generate more false positives.
• Define exceptions: You can specifically allow certain parameters that are often falsely detected as attacks (e.g., in member forms).
• Nextcloud exceptions: Nextcloud synchronization uses special headers and parameters that the CRS may classify as suspicious. Add exceptions for the Nextcloud endpoints.

Example: Exception for a GDPR-Compliant Member Form

Suppose your form sends a field nachricht that may contain HTML. Then you could write the following rule in a separate configuration file:

SecRuleUpdateTargetById 942100 "!ARGS:nachricht"

Or you disable certain rules for the path /mitgliederformular:

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

This way, protection for other areas is maintained while the form continues to work.

Do Not Block Nextcloud Synchronization

Nextcloud often uses long URLs with many parameters. The CRS could interpret this as SQL injection or XSS. Therefore, add exceptions for the Nextcloud instance. A blanket allowance of the path /nextcloud is possible but should be well considered:

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

It is better to disable only certain rules that frequently trigger false positives. Test synchronization thoroughly after each change.

Blocking Brute-Force Attacks

In addition to ModSecurity, you should also use Fail2ban to stop brute-force attacks on login pages. Virtualmin often already includes Fail2ban. Configure it to block the IP after too many failed login attempts. ModSecurity can also detect brute force, but Fail2ban is often more efficient for this purpose.

Regular Review and Log Analysis

Monitor the ModSecurity logs (e.g., /var/log/modsec_audit.log) regularly. This way, you can identify false positives and further refine the rules. Virtualmin offers a convenient log view for this. Also pay attention to performance: a WAF that is too strict can increase load times.

Conclusion: Balancing Security and Functionality

With ModSecurity and the OWASP CRS, you effectively protect your association website from common attacks. What matters is careful configuration that does not affect legitimate applications such as member forms or Nextcloud. Always test changes in DetectionOnly mode and define targeted exceptions. This keeps your website secure and GDPR-compliant.

For secure hosting of your association website, we recommend our web hosting packages and domains. If you have any questions, our support is happy to help.