How to Enable and Configure ModSecurity WAF on cPanel

ModSecurity is an open-source Web Application Firewall (WAF) module for Apache that inspects every HTTP request before it reaches your PHP application. It blocks SQL injection (SQLi), cross-site scripting (XSS), remote file inclusion (RFI), and hundreds of other OWASP Top 10 attack patterns in real time.

How ModSecurity Works

ModSecurity operates in two phases:

1. Request phase: inspects incoming GET/POST data, URL, headers, and cookies against a ruleset
2. Response phase: can also inspect outgoing responses to detect data leakage

When a request matches a rule, ModSecurity either logs it (detection mode) or blocks it with a 403 response (protection mode).

Step 1 — Enable ModSecurity in WHM

1. Log into WHM as root
2. Navigate to Security Center > ModSecurity Tools
3. Click On under the Vendor column — this enables ModSecurity globally for all Apache vhosts

Step 2 — Install the OWASP Core Rule Set (CRS)

WHM's ModSecurity Vendors tab lets you add rulesets. Add the OWASP CRS:

1. Go to ModSecurity Tools > Vendors
2. Click Add Vendor
3. Enter the URL: https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/v3.3/dev/crs-setup.conf.example
4. Or simply use WHM's built-in OWASP ModSecurity CRS option if available

Alternatively, install via CLI:

cd /usr/local/apache/conf
wget https://github.com/coreruleset/coreruleset/archive/v3.3.5.tar.gz
tar -xzf v3.3.5.tar.gz
cp coreruleset-3.3.5/crs-setup.conf.example coreruleset-3.3.5/crs-setup.conf

Step 3 — Start in Detection Mode

Never enable a WAF in blocking mode immediately. Start in DetectionOnly mode so you can review what would be blocked:

grep -i "SecRuleEngine" /usr/local/apache/conf/modsec2.conf

Set it to DetectionOnly first:

SecRuleEngine DetectionOnly

Step 4 — Monitor the Audit Log

tail -f /usr/local/apache/logs/modsec_audit.log

Look for false positives — legitimate requests being flagged. Common culprits are WordPress admin actions, form submissions with special characters, and plugin update checks.

Step 5 — Whitelist False Positives

Create a custom exception rule. For example, to disable rule 941100 for the WordPress admin:

SecRule REQUEST_URI "@beginsWith /wp-admin" \
  "id:1001,phase:1,nolog,allow,ctl:ruleRemoveById=941100"

Place custom rules in /usr/local/apache/conf/userdata/ so they survive cPanel rebuilds.

Step 6 — Switch to Protection Mode

After 48–72 hours of monitoring with no critical false positives, switch to blocking mode in WHM > ModSecurity Tools or by setting:

SecRuleEngine On

Conclusion

ModSecurity with OWASP CRS provides a strong baseline protection layer against automated web attacks. It's especially valuable for shared hosting where you can't vet every customer's code quality. For even stronger protection, consider pairing it with Imunify360, which includes an enhanced commercial ruleset on top of ModSecurity.