cPHulk or CSF/LFD: Which Should Block SSH Brute-Force on a WHM Server?

Open the SSH log on almost any public WHM server and you will see failed root logins from addresses you have never heard of, around the clock. WHM ships with cPHulk, many admins also install CSF with its LFD daemon, and sooner or later someone asks whether one of them is redundant or whether they are getting in each other's way. The question usually becomes urgent on the day an admin locks themselves out and cannot tell which tool did it. The short answer is that the two tools block at different layers. cPHulk refuses the login. CSF/LFD refuses the connection. Once you know that, most of the confusion, and most lockout tickets, become easy to untangle.

Start with what the symptom tells you

When SSH stops working from a given IP, the way it fails already points at the layer responsible. A firewall block drops packets before sshd ever sees them, so the client hangs and eventually reports a connection timeout. An authentication-layer block lets the TCP connection through, sshd sends its banner, and then the login is rejected with Permission denied, even when the password or key is correct. Running SSH in verbose mode from the affected workstation makes this distinction obvious in a few seconds:

BASH

# Run from the machine that cannot log in
ssh -v -p 22 [email protected]

# If output stops around 'Connecting to ...' and then times out,
# packets are being dropped: look at the firewall (CSF/LFD).
# If you see 'Remote protocol version' and authentication methods
# being tried before 'Permission denied', the connection works
# and something is rejecting the login itself: look at cPHulk.

This is also the first thing worth asking a customer to try before anyone starts editing config files. "I can't SSH in" covers both cases, and they are fixed in different places. One caveat: cPHulk can optionally push offending IPs into the firewall as well. If that option is enabled, a cPHulk block can also look like a timeout. The logs in a later section settle it either way.

How LFD sees and blocks SSH attempts

LFD (Login Failure Daemon) is the half of CSF that watches log files. It reads the sshd log, which is /var/log/secure on RHEL-family systems such as AlmaLinux or CentOS and /var/log/auth.log on Debian and Ubuntu. It counts failed logins per source IP over a time window, and when an IP crosses the threshold, it tells CSF to add a firewall rule for that address. From then on, that IP cannot reach any port the rule covers. It is not limited to SSH. The relevant settings live in /etc/csf/csf.conf:

INI

# Illustrative values only; check the defaults in your own csf.conf
# Failed SSH logins from one IP before LFD blocks it
LF_SSHD = "5"
# "1" makes the block permanent; a number of seconds makes it temporary
LF_SSHD_PERM = "1"
# Window (seconds) in which failures are counted
LF_INTERVAL = "3600"
# Same idea for cPanel/WHM/webmail login failures
LF_CPANEL = "5"

Two properties of this design matter in practice. First, LFD only knows what sshd writes to the log. If you have already moved to key-only authentication, a bot trying passwords still produces log lines, but it has no realistic way in, so LFD is mostly reducing noise and load. Second, permanent blocks land in /etc/csf/csf.deny and temporary ones live in a separate temporary list. That is why an IP can be blocked even though it does not appear in csf.deny.

How cPHulk sees and blocks the same attempts

cPHulk is cPanel's brute-force protection service, run by the cphulkd daemon and configured in WHM under the Security Center. Instead of reading logs after the fact, it sits in the authentication path. cPanel, WHM, webmail and the mail services ask it about login attempts, and on a typical WHM server sshd consults it through PAM, the pluggable authentication system Linux uses to check credentials. When cPHulk decides an IP or a username has failed too often, it tells PAM or the cPanel service to refuse the login. That has a consequence people tend to miss. cPHulk tracks usernames as well as IPs. A botnet hammering root from thousands of addresses may never trip a per-IP limit, but it can trip the per-username limit, and then the real administrator gets refused too, even from a clean IP with the correct password. Using a firewall to block every attacking address would never produce this kind of lockout, because the admin's IP was never blocked. cPHulk's view of the world is also broader than SSH. It understands cPanel accounts, so it can protect webmail and cPanel logins in ways a generic log watcher only approximates.

Where the two overlap and where they collide

On a server running both, an SSH password attack against root is seen twice. cPHulk counts it through PAM, and LFD counts the same failures from the log. Whichever threshold is lower wins first. That alone is harmless. The friction comes from having two separate block lists and two separate whitelists:

Adding your office IP with csf -a stops CSF from blocking it, but it does nothing for cPHulk. If cPHulk has locked the username, you are still refused.
Whitelisting the IP in cPHulk keeps PAM from refusing it, but if LFD already put the IP in the firewall, the connection never arrives.
If cPHulk is set to add firewall-level blocks, those rules live alongside CSF's rules. A CSF restart rebuilds the ruleset and may clear rules that another tool added. Whether that happens depends on versions and configuration, so test it on your own server rather than assuming.

None of this means the tools are incompatible. It means every "unblock this IP" or "never block this IP" action has to be done in both places, and support staff need to know that.

Tracing a lockout to the tool that caused it

With the symptom from ssh -v in hand, confirm on the server, through console access, another whitelisted IP, or WHM if that still works:

BASH

# Is the IP present in any CSF rule, permanent or temporary?
csf -g 203.0.113.10

# Did LFD log a block for it?
grep '203.0.113.10' /var/log/lfd.log | tail -n 20

# Did cPHulk record failures or a block for it?
grep '203.0.113.10' /usr/local/cpanel/logs/cphulkd.log | tail -n 20

# What did sshd itself see? (use /var/log/auth.log on Debian/Ubuntu)
grep '203.0.113.10' /var/log/secure | tail -n 20

If csf -g shows a match and lfd.log has a matching block line, the firewall is your problem. If CSF is clean but cphulkd.log shows the IP or the username being blocked, cPHulk is refusing the login. You can also see this in WHM under cPHulk's history and blocked lists. A red herring worth ruling out: sshd lines saying Failed password for your IP do not prove a brute-force tool is involved. A mistyped password, an expired key, or PermitRootLogin set to disallow passwords all produce similar lines. If neither CSF nor cPHulk mentions the IP, the problem is in sshd's own configuration. To unblock, act in the tool that blocked. In CSF, csf -dr IP removes a permanent deny and csf -tr IP removes a temporary one. In cPHulk, use the WHM interface to clear the block. A command-line script, /usr/local/cpanel/scripts/cphulkdwhitelist, exists on many versions for whitelisting. Whitelisting changes security policy, so only add IPs you control and that are static. A whitelisted dynamic residential IP can end up assigned to someone else. After unblocking, verify from the original workstation with ssh -v again. You should reach the authentication stage and log in normally. Then check that the IP is gone from csf -g output.

Choosing a setup for your server

There is no universally correct answer, but a few rules of thumb hold up. Running both is common and reasonable on shared hosting servers. cPHulk covers the cPanel-aware services and catches distributed attacks against a single username. CSF/LFD handles network-level blocking and protects services cPHulk does not know about. The cost is the operational discipline described above: two whitelists, kept in sync, and support staff who check both. If you run both, the setting most likely to hurt you is cPHulk's username-based protection on root. Keep it, but make sure your admin IPs are whitelisted in cPHulk, or that you always have a non-password way in, such as console access or key-based SSH from a whitelisted address. If you only want one tool to own SSH, pick deliberately. Letting LFD own it gives you network-level blocks and one place to look for SSH problems, while cPHulk stays responsible for cPanel and mail logins. Letting cPHulk own everything keeps all policy inside WHM, but you lose CSF's broader firewall features. Whichever you choose, also check the maintenance status of the csf package you run, since its upstream situation has changed in recent years. More important than either tool is that neither one is your real SSH defense. Automated campaigns against TCP 22 are relentless. Once one gets in, it typically drops botnet agents or cryptominers. Key-only authentication, no password login for root, and restricting who can reach SSH and WHM at all do far more than any lockout threshold. The SSH hardening guide covers that side, and the WHM port restriction comparison explains how to keep administrative ports off the public internet. So when an SSH lockout lands on your desk, start with ssh -v. A timeout points at the firewall and CSF. A rejected login on a working connection points at cPHulk. Confirm in the matching log, then unblock and whitelist in that tool, and in the other one too if both are running. Treat both tools as noise reduction on top of key-based access, not as the thing that keeps attackers out.