9 min readWHMCS
The ticket says the server is down. The customer can't log in to cPanel, their mail client keeps asking for the password, and FTP times out. From your desk everything works. Often the server's brute-force protection has blocked the customer's IP address, and on a cPanel & WHM server that means one of two systems: CSF with its login failure daemon (lfd), or cPanel's own cPHulk.
This guide is the hands-on part: how to tell which one holds the block, how to remove that block and nothing else, and how to find the device that will cause the next one. Why legitimate customers trip these protections in the first place, and why the usual shortcuts weaken the server, is covered in our earlier article on self-service unblocking. In short, both systems count failed logins per address and can block the address rather than the account. A phone or mail client still holding an old password can fail often enough to set them off without the customer noticing.
A note on which CSF you are running
Way to the Web, the company behind ConfigServer and CSF, closed on August 31, 2025, and released
CSF under the GPLv3. Since February 25, 2026,
cPanel has published its own fork, packaged as
cpanel-csf, which the fork's README says is intended for cPanel & WHM systems only. cPanel
maintains it for security and stability fixes and does not help with CSF configuration. The
commands below are taken from that fork's csf manual page, its /etc/csf/readme.txt and its
source. If your servers run a community fork instead, check csf -h on the server before relying
on any flag.
Start with the address the server sees
Ask the customer for their public IP address, not the one in their network settings; any "what is my IP" page will show it. If they can reach the site over mobile data but not from the office, that is a strong sign the block is on the office address.
cPHulk will not tell the customer it is involved. cPanel's documentation states that when cPHulk blocks an address or account, the login page shows only "The login is invalid." So a customer who insists their password is correct may be right.
Check CSF and lfd
csf -g searches the iptables and ip6tables rules for a match, and also reports any entry for that
address in CSF's allow, deny and temporary lists. We use 203.0.113.45 as the example address
throughout.
csf -g 203.0.113.45
Read the lines after the iptables output. A permanent block on the exact address appears as
csf.deny: followed by the line from /etc/csf/csf.deny; if the address falls inside a CIDR range
listed there, the line starts Permanent Blocks (csf.deny): instead. A temporary block appears as
Temporary Blocks: with the address, port, direction, the TTL the block was given and the comment
in parentheses. That TTL is the full length of the block, not the time left. To see how long each
temporary entry on the server has left, with its comment:
csf -t
The comment tells you who placed the block. A permanent block that lfd wrote has a comment
starting lfd: in csf.deny; a temporary one starts lfd -. Either way the service follows in
parentheses, such as (sshd) or (imapd), then the address and the number of failures "in the
last" so many seconds. A comment written by a person, or no comment at all, means a human
decision, and you should find out why before reversing it.
For the history behind the block, lfd logs its activity to /var/log/lfd.log:
grep 203.0.113.45 /var/log/lfd.log
Because csf -g searches the whole rule set, it can also show matches in chains CSF did not
create. cPHulk can write its own iptables rules (more on that below), and cPanel's documentation
clears them with iptables -F cphulk, so they sit in a chain named cphulk. A match there points
you to cPHulk, not CSF.
Remove a CSF block
Use the command that matches what csf -g found.
# Permanent block: remove from csf.deny and unblock
csf -dr 203.0.113.45
# Temporary block: remove from the temporary ban list only
csf -trd 203.0.113.45
csf -tr also exists; it removes the address from the temporary ban list or the temporary allow
list. -trd limits the removal to bans, which is what you want here. Run csf -g again
afterward to confirm nothing is left.
Before you remove anything, read the entry. CSF's readme describes "do not delete" in a
csf.deny comment as the way to stop CSF rotating that entry out when the file reaches its line
limit, so an entry carrying it is one an administrator chose to keep. csf.allow and csf.deny
can also hold CIDR ranges and advanced filters that name a protocol, direction and port. If the
address matched a range, or a filter whose comment does not start with lfd, someone wrote that
rule on purpose.
Expect the block to be permanent, even for what looked like a short lockout. In the csf.conf
shipped in cPanel's repository, each login failure trigger has a matching _PERM setting, and
the ones a customer's devices can trip (SSH, FTP, SMTP authentication, POP3, IMAP, cPanel and
password-protected directories) are all set to 1, which makes the block permanent. A value
above 1 makes the block temporary for that many seconds instead. Where a server is set up that
way, LF_PERMBLOCK, enabled in the same file, turns an address into a permanent block once it has
been temporarily blocked more than 4 times in 86400 seconds, and the comment then reads
(PERMBLOCK) instead of naming a service. Your servers may be configured differently, so trust
what csf -g reports over any default.
Check cPHulk
In WHM, go to Home » Security Center » cPHulk Brute Force Protection and open the History Reports tab. The Select a Report menu offers four reports:
- Failed Logins lists recent failures with the user, IP address and service.
- Blocked Users lists accounts locked by username-based protection.
- Blocked IP Addresses lists addresses blocked by IP-based protection.
- One-day Blocks lists addresses that reached the one-day threshold.
In the Blocked IP Addresses and One-day Blocks reports, the Remove Block button next to an address removes that block.
From the command line, three WHM API 1 functions list the failed logins, the brute-force blocks and the excessive brute-force blocks, each with the minutes left before it expires:
whmapi1 --output=jsonpretty get_cphulk_failed_logins
whmapi1 --output=jsonpretty get_cphulk_brutes
whmapi1 --output=jsonpretty get_cphulk_excessive_brutes
To unblock one address:
whmapi1 --output=jsonpretty flush_cphulk_login_history_for_ips ip='203.0.113.45'
cPanel documents this function as the way to unblock a specific address, and it also deletes
cPHulk's temporary iptables rules for that address. That matters when "Block IP addresses at the
firewall level if they trigger brute force protection" or "Block IP addresses at the firewall
level if they trigger a one-day block" is selected (the second is on by default), because an
iptables block overrides an address on cPHulk's whitelist. cPHulk writes its log to
/usr/local/cpanel/logs/cphulkd.log.
Two cPHulk details catch people out. First, a customer in the Blocked Users report has an account lock, not an IP block, so it applies whichever address they come from. cPHulk locks the account for one minute per allowed failure, 15 minutes at the default setting, and by default username-based protection only applies to requests from the local system. Second, cPHulk does not count repeated attempts with the same IP address, username and password within six hours as separate failures. One device retrying one stale password is therefore less likely to trip cPHulk than several devices or several different wrong passwords.
What not to do
Do not allowlist customer addresses wholesale. csf -a adds an address to
/etc/csf/csf.allow, which CSF's readme describes as addresses that should always be allowed
through the firewall. cPanel describes cPHulk's whitelist as addresses it always allows to log in,
though a firewall-level block still overrides it. Customer addresses change hands, and the entry
stays trusted after it does. CSF's readme recommends csf.allow for administrator and support
addresses, and cPanel recommends the cPHulk whitelist for your own address to avoid a root
lockout. If a customer needs a short window while they track down a device, CSF has a
temporary allow that expires on its own:
csf -ta 203.0.113.45 3600 Customer fixing saved mail password, ticket 12345
Leave IGNORE_ALLOW at 0 as well. The comment in csf.conf warns that turning it on would let
an infected machine on an allowed address attack the server while lfd ignores it.
Do not switch the protection off to clear one block. csf -x disables csf and lfd completely,
and csf -f flushes the firewall rules. Disabling cPHulk leaves its existing account locks in
place, so turning it off may not even unlock the customer.
Do not use the bulk commands for a single customer. csf -df removes every entry in
csf.deny, csf -tf flushes every temporary entry, and whmapi1 flush_cphulk_login_history
removes all of cPHulk's login history. Each of those also unblocks every attacker the server has
caught.
Do not raise thresholds because one customer keeps getting blocked. A higher failure count applies to every address, so it gives attackers more guesses on every account on the server to save one customer a few tickets.
Stop the block from coming back
Removing the block does nothing about the device that caused it. That phone or mail client is
still sending the old password and will trip the same trigger again. Where blocks are temporary,
LF_PERMBLOCK counts each repeat toward a permanent one.
The block already tells you where to look. The lfd comment names the service, and cPHulk's Failed
Logins report shows the username and the service. A mail service points to a mail client: a
phone, a tablet, an old laptop or a desktop client that still holds the previous password. An FTP
failure usually means a saved site in an FTP client or a backup tool. A cPanel or webmail failure
is often a password saved in a browser. For mail, the username in the report is the mailbox, which
is the detail the customer needs to find the right account in their settings. cPHulk lists any
username without @domain under the service system, whatever the person tried to log in to, so
a system row could be cPanel, WHM or SSH.
Tell the customer which service and account failed and ask them to update the saved password on every device that uses it, including ones that are switched off and will reconnect later. If they cannot find it straight away, the temporary allow above gives them a fixed window; once it expires, a block that returns means the device is still out there.
Letting customers clear their own blocks
If your customers reach you through WHMCS, the removal itself does not have to be a ticket. Firewall Unblocker is our free WHMCS addon that lets a client check the address they are connecting from against CSF/LFD and cPHulk on the servers behind their own services, see the reason for any block, and remove the ones your policy allows. Blocks your team placed on purpose, CIDR and port-specific rules and "do not delete" entries stay with support, and every check and removal goes into an audit log. It needs WHMCS 8.13 or 9.0 and cPanel & WHM, and the launch article explains the policy in detail.