Enabling ModSecurity with the OWASP Core Rule Set on cPanel: A Practical Guide

What you need to know first

ModSecurity, when paired with the OWASP Core Rule Set (CRS), can block SQL injection, XSS, and other common attacks on your cPanel server. The tricky part is not enabling it—it's enabling it without blocking legitimate traffic. This guide walks through the configuration, shows a worked example, and explains how to avoid the mistakes that cause false positives and downtime.

How ModSecurity fits into cPanel

ModSecurity is a web application firewall (WAF) that integrates with Apache. On cPanel, you can enable it per-domain or server-wide through WHM. The OWASP CRS is a set of rules maintained by the OWASP project that detects attack patterns in HTTP requests. When ModSecurity is active, it inspects requests against these rules and takes action: logging, blocking, or modifying traffic.

The key decision is whether to run rules in audit mode (log but don't block) or enforcement mode (block malicious requests). Starting in audit mode lets you see what would be blocked without disrupting users. Once you're confident the rules are accurate, you switch to enforcement.

Enable ModSecurity in WHM

Log into WHM as root. Navigate to WHM > Plugins > ModSecurity. You'll see a list of domains. Select the domain you want to protect, then choose the rule set—typically OWASP ModSecurity Core Rule Set. Click Save. ModSecurity is now active for that domain, but the rules are not yet enforced. cPanel writes the configuration to /etc/apache2/conf.d/modsec2.user.conf and stores rule files under /etc/modsecurity/.

To verify ModSecurity is loaded, run this on the server as root:

apachectl -M | grep modsecurity

You should see modsecurity2_module in the output. If the module is not listed, check that ModSecurity is installed via EasyApache or your package manager, then restart Apache:

systemctl restart httpd

Configure rules in audit mode

By default, ModSecurity logs rule violations to /var/log/apache2/modsec_audit.log. To make rules enforce blocks, you need to edit the configuration. Edit /etc/apache2/conf.d/modsec2.user.conf and set the default action:

SecRuleEngine On
SecRuleEngine DetectionOnly

Change DetectionOnly to On to enforce rules. Save the file, then restart Apache:

systemctl restart httpd

Test with a simple request that should trigger a rule (e.g., a URL with ' OR '1'='1). Check the audit log:

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

If the rule fired, you'll see the request logged with the rule ID and action taken. If nothing appears, verify ModSecurity is loaded and the rule set is enabled for that domain.

Common mistakes and how to avoid them

Forgetting to restart Apache. Rule changes do not take effect until you restart Apache. Always run systemctl restart httpd after editing ModSecurity configuration.

Enabling rules without testing in audit mode. If you skip audit mode and go straight to enforcement, you risk blocking legitimate users. Always run in audit mode for at least a few days to see what rules fire on your traffic.

Mismatched PHP/Apache versions. ModSecurity rules may fail if your Apache or PHP version is incompatible with the rule set. Check that your rule set is compatible with your Apache version. The OWASP CRS documentation lists supported versions. If you upgrade Apache, verify your rules still work.

Not keeping rules updated. The OWASP CRS is updated regularly. If you don't apply updates, you may miss protection against new attack patterns. Set a reminder to check for CRS updates monthly.

Performance and tuning

ModSecurity adds latency to every request. On high-traffic sites, this can be significant. If you notice slowdowns, consider these steps:

• Disable rules that fire frequently but are false positives.
• Use SecRuleEngine DetectionOnly for rules that are too aggressive.
• Increase SecRuleEngine to On only after tuning.

To disable a rule, edit /etc/apache2/conf.d/modsec2.user.conf and add:

SecRuleRemoveById 12345

Replace 12345 with the rule ID from the audit log. Restart Apache to apply.

Limitations and verification

ModSecurity is not a substitute for secure coding practices. It cannot fix vulnerabilities in your application. Always patch and update your software. To verify ModSecurity is working, check the audit log after making test requests. If you see no entries, confirm the rule set is enabled for the domain and that ModSecurity is loaded in Apache. If rules are firing too often, review the log for false positives and disable the problematic rules.