Run Imunify360 alongside CSF without double-blocking

CSF and Imunify360 both watch logs and both ban IPs. Out of the box, they trip over each other — the same WordPress brute-force attempt triggers a CSF ban via LF_MODSEC and an Imunify grey-list entry, with different durations, and your customers end up unable to predict when an IP will actually be unblocked.

The rule is simple: let Imunify360 own everything at the application layer, and leave CSF doing what it does well — packet-level rate limits, SYN flood protection, and country blocks.

What's actually overlapping

CSF's LFD (login failure daemon) tails a list of logs for failed-auth patterns. Each pattern has a counter (LF_MODSEC, LF_CXS, LF_DIRECTADMIN, LF_SSHD, etc.). When the counter exceeds the threshold, LFD adds the IP to iptables for LF_TRIGGER seconds.

Imunify360 watches the same applications via its own agents and pushes blocks through its grey-list. For the application-layer triggers, you end up with both products reacting to the same event:

For everything in the right-hand column, Imunify's signal is better — it has fleet-wide reputation data behind it, and the block duration adapts to attacker behaviour. Leaving the left-hand column enabled produces the double-ban problem.

The minimum csf.conf changes

Edit /etc/csf/csf.conf and set these to 0:

LF_MODSEC = "0"
LF_CXS = "0"
LF_DIRECTADMIN = "0"
LF_POP3D = "0"
LF_SMTPAUTH = "0"
LF_SSHD = "0"
LF_HTACCESS = "0"

LF_DIRECTADMIN is only relevant if you're on DirectAdmin — leave it alone on cPanel boxes. Otherwise, all of these now defer to Imunify360.

Reload csf:

csf -r

And restart the Imunify agent so it picks up that it's now the sole arbiter:

imunify360-agent restart

What to do with ModSecurity itself

Imunify ships its own ModSecurity ruleset (Comodo). Disable the OWASP CRS if it's also enabled — running both produces the same double-flagging pattern at the WAF layer, covered in tune the Imunify360 WAF.

Set the engine mode based on where you are in the deployment:

• DetectionOnly during the first 7-14 days. Imunify logs hits without blocking, so you can review false positives in Incidents before they start hitting customers.
• On once tuning is done.

In WHM: ModSecurity Tools → Configuration → SecRuleEngine. Or in /etc/apache2/conf.d/modsec/modsec2.cpanel.conf:

SecRuleEngine On

Verify the integration is clean

Hit the server with a deliberately bad request and watch which product blocks:

curl -A "' OR 1=1 --" https://example.com/?id=1
tail -F /var/log/imunify360/console.log /var/log/lfd.log

You should see the request in Imunify's log and nothing in lfd.log. If both fire, recheck the csf.conf settings — a managed-config tool (cPanel WHM scripts, configserver's UI) may have overridden your edits.

A common gotcha — country blocking

CC_DENY in CSF is the cheapest way to drop traffic from countries you don't serve, and it operates at the iptables level before Imunify ever sees the packet. Keep it. The two products complement each other when CSF handles the geographic cut and Imunify handles everything that gets past it.

Don't try to replicate country blocking inside Imunify's grey-list — its block list isn't sized for entire countries and you'll just balloon the iptables ruleset.

Logs to keep an eye on

tail -F /var/log/lfd.log              # csf actions
tail -F /var/log/imunify360/console.log
tail -F /var/log/imunify360/firewall.log
imunify360-agent incidents list --last 1h

A clean state shows csf adding network-layer blocks (rate limits, port scans) and Imunify handling everything from the application layer up. If lfd.log is logging *Blocked in iptables* entries for ModSecurity, dovecot, or wp-login, the LF_* settings above didn't get applied — recheck.

Next steps

• Quiet the WAF after the cutover: tune the Imunify360 WAF.
• Fresh install? install Imunify360 on cPanel.
• Buy or renew: Imunify360 license.