cPHulk vs CSF/LFD on cPanel — which to run and how they coexist

Every cPanel host runs into the same security question early on: cPanel ships cPHulk for brute-force protection, but every WebHostingTalk thread insists you also need CSF and LFD. Are they doing the same thing? Do they conflict? Do you actually need both?

Short answer: they solve different problems with about 20% overlap, and almost every production cPanel server should run both — with two config tweaks so they don't step on each other.

What each one is

cPHulk is the brute-force protection daemon bundled with WHM. It hooks directly into the cPanel authentication stack — cpsrvd, dovecot, pure-ftpd, Exim SMTP AUTH, and the PAM stack used by SSH — and tracks failed logins per IP and per user. When thresholds trip, it blocks the offender at the application layer and optionally adds an iptables drop too.

It does only brute-force protection. It is not a firewall.

CSF (ConfigServer Security & Firewall) is a host firewall front-end that configures iptables/nftables, plus a companion daemon called LFD (Login Failure Daemon) that tails log files. CSF handles inbound and outbound packet filtering, port-scan detection, SYN flood limits, country-level blocks, and a long list of secondary features (process tracking, suspicious-process scanning, account watching). LFD adds log-based intrusion detection — it can match patterns in /var/log/secure, /usr/local/cpanel/logs/login_log, web server logs, and mail logs, and ban on hits.

Where they overlap: both can ban IPs that fail to authenticate against SSH, cPanel/WHM, or mail. Everything else CSF/LFD does — port filtering, exploit scanning, file integrity checks, country blocking at the packet layer — cPHulk cannot touch.

Scope at a glance

Why most hosts run both

CSF without cPHulk leaves you with a smart packet filter but no cPanel-aware view of auth events. LFD can read the cPanel login log, but you lose cPHulk's per-user thresholds, the "one-day lock" cooldown behaviour, and the cPanel-aware unlock flow under WHM → Security Center → cPHulk Brute Force Protection.

cPHulk without CSF leaves the kernel firewall on its defaults — typically nothing — and gives an attacker the run of every port that isn't explicitly an auth target. Port scans, SMTP relay attempts, exploit-kit probes against random services on high ports: none of those touch cPHulk.

So the standard configuration is:

• cPHulk handles auth-level decisions — who counts as brute-forcing what, who gets locked out, when the lock expires.
• CSF/LFD handles the network layer — what's open, what's closed, what countries are denied, what processes are misbehaving.

The piece that needs care is the overlap zone where both tools can ban the same IP from the same auth-failure stream.

Where they fight

Three concrete failure modes when both are enabled with stock config:

1. Double-banned IPs

A real user fat-fingers their cPanel password five times. cPHulk locks the IP at the cPanel layer. LFD also sees the failures in /usr/local/cpanel/logs/login_log and adds an iptables drop rule. You unlock cPHulk under WHM → cPHulk → IP Manager, the user retries — and they still can't connect because CSF's iptables rule is still there. You have to remember to also run csf -dr <ip>.

The fix is to take the cPanel auth surface away from LFD and let cPHulk own it. Edit /etc/csf/csf.conf:

LF_CPANEL = "0"

Then reload: csf -r. cPHulk now owns cPanel, WHM, and Webmail auth events; LFD keeps SSH (LF_SSHD), FTP (LF_FTPD), IMAP/POP3 (LF_IMAPD, LF_POP3D), SMTP AUTH (LF_SMTPAUTH), and the exploit scanners.

2. Whitelist drift

Your office IP is whitelisted in cPHulk under "White/Black List Management" but not in CSF. Someone on the same /24 runs a port scan, LFD trips on it, and the entire office gets blocked.

Maintain a single source of truth. Add management IPs to /etc/csf/csf.allow first, then mirror them into cPHulk:

csf -a 203.0.113.10 "office uplink"
whmapi1 create_cphulk_record list_name=white ip=203.0.113.10

For larger fleets, write a wrapper script and call it from your provisioning system — cPHulk's whitelist file (/var/cpanel/cphulkd_db/ records) is not human-friendly and drifts easily if maintained by hand.

3. Locking yourself out

You SSH from a new IP, mistype your sudo password, LFD bans you in iptables. You try to log into WHM to unlock — CSF dropped the SYN packet before it reached cpsrvd, so the WHM port shows as closed. cPHulk hasn't even seen the auth attempt yet.

Always have an out-of-band recovery path ready before you go live:

# Via the host's serial/IPMI console
csf -dr <your-ip>
whmapi1 flush_cphulk_login_history

And whitelist your static management IPs in both tools as part of post-install setup — the cPHulk tuning guide covers the WHM side, and the CSF install walkthrough covers /etc/csf/csf.allow.

What about Imunify360?

Imunify360 replaces most of CSF/LFD for the security functions that matter on a shared host. Its firewall layer is essentially a CSF re-implementation with central threat intelligence, and its Proactive Defense catches PHP-level attacks that neither cPHulk nor CSF can see. Hosts running Imunify360 often drop CSF entirely and keep cPHulk for the cPanel-specific auth surface.

With Imunify360 the recommended stack becomes:

• cPHulk — cPanel-aware auth events
• Imunify360 — everything CSF/LFD did, plus malware scanning, the WAF, and graylisting

Imunify360 supports importing CSF allow/deny lists at install time, so the migration off CSF is straightforward — typically under 30 minutes on a server with a reasonable allow list.

Decision tree

Are you running Imunify360?
├─ Yes → cPHulk + Imunify360. Drop CSF.
└─ No  → cPHulk + CSF/LFD. Set LF_CPANEL=0 in csf.conf.
         Do you need outbound filtering, country blocks, or exploit scanning?
         ├─ Yes → CSF handles all three.
         └─ No  → Run CSF anyway for inbound filtering; it's free.

What about firewalld or ufw?

Don't. Both fight CSF for control of nftables/iptables, and the cPanel installer expects a plugin-aware firewall — which on RHEL-derived distros means CSF in 2026. The CSF install script stops and disables firewalld automatically; if you've added ufw rules separately on an Ubuntu cPanel host, remove them before running csf -e.

Verdict

Run both. cPHulk handles the cPanel-shaped auth surface, CSF/LFD handles the network and everything that isn't a cPanel login. Set LF_CPANEL=0 to remove the overlap, maintain a single whitelist source of truth, and keep an out-of-band unlock path ready.

If you've already bought Imunify360, drop CSF and keep cPHulk anyway — the cPanel-specific auth integration isn't something Imunify360 fully duplicates.

Next steps

• For a working cPHulk configuration that won't lock you out, see tuning cPHulk on WHM.
• For the CSF install and the dozen defaults to change before leaving TESTING mode, see installing ConfigServer CSF on cPanel.
• If you're considering Imunify360 as the CSF replacement, the coexistence guide covers the migration and the Imunify360 license page covers pricing.