ModSecurity and the OWASP Core Rule Set on cPanel: A Practical WAF Guide

A web application firewall (WAF) inspects every HTTP request before it reaches WordPress, a shopping cart or a custom PHP app, and blocks the ones that look like attacks. On a cPanel server the built-in option is ModSecurity with the OWASP Core Rule Set (CRS): install the Apache module in EasyApache 4, add the current CRS package, keep it enabled for every domain, watch the Hits List for false positives, and fix them with narrow, per-domain rule exclusions instead of switching the firewall off. This guide walks through each step using cPanel's current interfaces.

What ModSecurity and the CRS actually do

ModSecurity is the engine: an Apache module that can read requests and responses and act on rules. On its own it does nothing useful. The OWASP Core Rule Set is the free, community-maintained rule set that gives it its knowledge. According to the CRS project, it targets attack classes such as:

• SQL injection (SQLi) and cross-site scripting (XSS)
• Local and remote file inclusion (LFI/RFI)
• PHP and Java code injection, and Unix/Windows shell injection
• Server-side template injection, Shellshock and HTTPoxy
• Session fixation
• Scanner and bot detection
• Metadata and error leakage in responses

What it will not do

A WAF is a safety net, not a patch. It will not fix an outdated plugin, stop someone who logs in with a stolen password, or clean malware that is already on the server. Keep applications updated, use 2FA and keep backups; the WAF buys time and blocks the bulk of automated probing.

How CRS decides to block

CRS uses anomaly scoring. Each matching rule adds points to a request's score, and the request is blocked only when the total crosses a threshold. That design lets one weak signal pass while a request with several suspicious traits is stopped.

Step 1: Install ModSecurity and the rule set

1. In WHM » Software » EasyApache 4, customize your profile and make sure the mod_security2 Apache module is installed.
2. In the same EasyApache 4 profile, go to Additional Packages and install ea-modsec2-rules-owasp-crs. cPanel's documentation describes this package as the newer rule set that receives frequent updates.
3. Open WHM » Security Center » ModSecurity Vendors. If you still see the older OWASP ModSecurity Core Rule Set V3.0 vendor installed, note that cPanel says it is no longer updated; plan to move to the package.
4. Make sure Updates are on for the rule set you use, so new versions install during cPanel's regular update run.

Check the engine settings

In WHM » Security Center » ModSecurity Configuration, review two options:

• Rules Engine: process the rules (blocking), do not process them, or process them without executing disruptive actions. The last option is a detection-only mode, useful for a short trial on a busy server.
• Audit Log Level: cPanel recommends logging only noteworthy transactions. Logging everything can capture private data and fill disks quickly.

Step 2: Choose a paranoia level

CRS has four paranoia levels (PL), set in crs-setup.conf. Higher levels add more rules and catch more attacks, but also flag more legitimate traffic.

Level	CRS project's description	Typical fit
PL 1	Baseline security with a minimal need to tune away false positives	Any public site; the right start for most businesses
PL 2	Adequate when real user data is involved	Online stores, client portals
PL 3	Online banking level, with lots of false positives	High-value apps with someone to tune them
PL 4	Use at your own risk; expect many false positives	Rarely appropriate on shared hosting

Start at PL 1. The CRS documentation advises against running a high level in blocking mode without adequate tuning.

Step 3: Find false positives

A false positive is a legitimate request that a CRS rule matches in error, for example an editor saving a blog post that contains HTML, or a form field that looks like SQL. Typical symptoms are a 403 Forbidden page when saving content in WordPress, uploads failing, or a payment callback being rejected.

To trace one:

1. Open WHM » Security Center » ModSecurity Tools. The Hits List shows recent rule events, with the rule ID, the host and the request.
2. Match the time and URL the user reported. Note the Rule ID (for example, a 941xxx rule is in the XSS family, 942xxx is SQL injection).
3. Check the Apache error log for the full message if you need the exact argument that matched.

Step 4: Fix it narrowly, per domain

The worst fix is the most common one: turning ModSecurity off for the whole domain. cPanel's own documentation strongly recommends keeping ModSecurity enabled for all domains and disabling it only while troubleshooting. CRS adds that you should never edit its rule files directly, because updates overwrite your changes; use exclusions instead.

Option A: Remove one rule for one domain

cPanel lets you add Apache directives to a single virtual host with include files:

• /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain>/modsec.conf for HTTPS
• /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain>/modsec.conf for HTTP

Inside, wrap the exclusion so Apache still starts if the module is missing:

<IfModule mod_security2.c>
  SecRuleRemoveById 941160
</IfModule>

Then run /usr/local/cpanel/scripts/rebuildhttpdconf and /usr/local/cpanel/scripts/restartsrv_httpd. The rule stays active for every other site on the server.

Option B: Exclude one field, not the whole rule

Even better, keep the rule and stop it from inspecting only the field that causes trouble. CRS documents SecRuleUpdateTargetById for this, for example excluding a single form argument from one XSS rule. You can also scope an exclusion to a path, such as an admin URL, with a <LocationMatch> block in the same include file.

Option C: Server-wide changes

If a vendor rule misfires on every site, you can disable it from the Hits List by clicking the rule ID, or add custom rules under ModSecurity Tools » Rules List and click Deploy and Restart Apache. Use this sparingly; a rule removed server-wide is removed for every client.

Use the CRS application exclusions

The CRS project offers ready-made rule exclusions for popular applications such as WordPress and Drupal (packaged as plugins in CRS v4). Check whether one exists for your application before writing your own.

Step 5: Let site owners help, carefully

With the ModSecurity Domain Manager feature enabled in WHM » Packages » Feature Manager, cPanel users can switch ModSecurity on or off per domain in cPanel » Security » ModSecurity. That is convenient for troubleshooting, but it also means a frustrated user can leave a site unprotected. Review the setting periodically, or keep the feature for administrators only.

A short maintenance routine

1. Weekly: skim the Hits List for repeated hits on the same legitimate URL.
2. After every application update: test logins, forms, uploads and checkout.
3. Monthly: confirm rule-set updates are still installing.
4. Keep a short log of each exclusion, the reason and the date, so the next administrator knows why it exists.

Want it tuned for your sites?

A WAF that blocks your own customers gets switched off; one that is tuned stays on and quietly stops attacks. Max, our founder, is cPanel & WHM certified, and our team configures and tunes ModSecurity for businesses across Miami-Dade and South Florida. Request a free IT assessment and we will review your server's web protection with you.

Sources

• ModSecurity Vendors – cPanel & WHM Documentation
• ModSecurity Tools – cPanel & WHM Documentation
• ModSecurity for cPanel – cPanel & WHM Documentation
• Modify Apache Virtual Hosts with Include Files – cPanel Documentation
• OWASP CRS: False Positives and Tuning
• OWASP CRS: Paranoia Levels
• OWASP CRS Project