Tune Imunify360 WAF to stop blocking legitimate traffic

Imunify360 ships with the Comodo WAF rules enabled by default, and on a shared cPanel server they will block a steady trickle of legitimate plugin and admin traffic — WooCommerce checkout webhooks, Elementor's editor, Yoast's bulk indexer. The fix is not "turn off the WAF". It is rule-level whitelisting plus removing the duplicate ruleset most servers accidentally end up with.

Find what's actually blocking

Don't guess. Pull the recent incidents from the same host:

imunify360-agent incidents list --plugin modsec --last 1h

Each row shows the rule ID, the request URL, and the client IP. The same view exists in the cPanel WHM UI under Imunify360 → Incidents, filtered by Plugin = "ModSecurity".

Cross-reference the rule ID against your ruleset (/etc/apache2/conf.d/modsec_vendor_configs/ for Comodo). The common offenders on cPanel hosts running WordPress:

• 214940 / 214950 — SQLi false positives on POST bodies containing URLs.
• 211190 — XSS heuristic that fires on Gutenberg block JSON.
• 220020 — file upload checks that catch legitimate WooCommerce product images.

Whitelist by rule ID

The cleanest fix for a known-good rule that produces noise is to disable the rule globally:

imunify360-agent rules disable 214940
imunify360-agent rules disable 211190

Use the rule-disable list rather than commenting out lines in /etc/apache2/conf.d/modsec_vendor_configs/ — those files get overwritten on the next ruleset update.

If you only want to disable a rule for one user, drop a per-user .htaccess override:

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

Whitelist by IP

For trusted partner IPs (payment gateways, CDN purge endpoints, monitoring), whitelist the IP at the Imunify level rather than at csf:

imunify360-agent ip-list local add 1.2.3.4 --comment "stripe webhook"

local is the Imunify whitelist; --comment shows up in the UI, so future you knows why it's there.

Use the whitelist files for bulk imports

For larger whitelists — your monitoring vendor's published IP range, an office VPN block — drop a file into /etc/imunify360/whitelist/:

cat > /etc/imunify360/whitelist/custom.txt <<'EOF'
# stripe webhook IPs, last updated 2026-05-01
3.18.12.63
3.130.192.231
13.235.14.237
13.235.122.149
EOF

imunify360-agent restart

One IP or CIDR per line. The directory is read on every restart, and the file persists across upgrades.

Disable the duplicate ruleset

The single biggest source of phantom blocks: the server is running both the Comodo WAF (Imunify default) and the OWASP CRS that someone enabled in EasyApache. Every request hits both rulesets, and the false-positive surface roughly doubles.

Check what's loaded:

apachectl -M | grep -i security
ls /etc/apache2/conf.d/modsec_vendor_configs/

If you see both comodo_apache/ and OWASP3/ (or crs/), pick one. For Imunify360 sites, the Comodo set is the supported choice — disable the OWASP CRS in WHM → ModSecurity Vendors.

Stop csf from double-blocking

CSF's LF_MODSEC trigger watches /var/log/apache2/error_log for ModSecurity hits and bans the source IP at the firewall level. With Imunify360 already handling IP-level blocks via its grey-list, LF_MODSEC is a duplicate trigger that produces inconsistent ban durations.

Edit /etc/csf/csf.conf:

LF_MODSEC = "0"

Then csf -r. The full csf coexistence story is in Imunify360 and CSF coexistence.

Verify the change

imunify360-agent incidents list --plugin modsec --last 5m

The incidents stream should drop to zero for the rules you disabled. If they still appear, the rule is being re-triggered from a vendor config file that overrides the disable list — usually a third-party mod_security2 vendor installed outside the Imunify-managed path.

Next steps

• See the full csf integration in Imunify360 and CSF coexistence.
• Submit upstream false positives so they're fixed for everyone: submit Imunify360 false positives.
• New install? Start with install Imunify360 on cPanel and buy a license.