Every server exposed to the internet receives continuous automated login attempts. cPHulk is cPanel's answer: it counts failures and blocks the source.
In WHM, Security Center → cPHulk Brute Force Protection. It should be enabled.
What it covers
Authentication handled by the panel: cPanel and WHM logins, webmail, mail collection over POP and IMAP, and SSH.
What it does not cover is application logins. A WordPress admin page being attacked is not something cPHulk sees, because those requests never touch panel authentication; they are ordinary web traffic to a PHP file. That needs its own protection, at the application or the web server, and assuming otherwise leaves the most commonly attacked door unwatched.
The settings that matter
Failures before a block, and the window they must occur in. The defaults are reasonable. Tightening them catches attacks sooner and locks out more real people, because a person who has forgotten a password produces exactly the pattern being detected.
How long a block lasts. Short blocks (fifteen minutes) stop automated attempts effectively, because the attacker's throughput collapses, and they release genuine users without a support ticket. Long blocks mostly generate support tickets.
Notifications. Worth enabling for blocks on the root account specifically. Everything else is noise; that one is worth seeing.
The two lists
The allow list exempts addresses. Put your office address on it, and any monitoring system that authenticates regularly.
Put your own address on it before you need to. The administrator locked out of their own server by their own protection is a common evening, and it is entirely avoidable.
The caveat: an allow-listed address is exempt from the protection. That is fine for a controlled office connection and not fine for a shared or public one.
The deny list blocks permanently. Useful for a persistent source, and not a strategy: attackers change addresses faster than you can add them.
Find the release screen first
The first time you use cPHulk in anger will not be an attack. It will be a customer who typed their password wrong four times and is now blocked, phoning you.
The blocked-list screen shows current blocks with the address and the account, and removing an entry releases it immediately. Knowing where that is turns a five-minute problem into a thirty-second one.
A block that will not go away
If a customer is repeatedly blocked within minutes of being released, they are not typing badly. Something is retrying with an old password, almost always a mail client on a phone that was never updated after a password change, checking every few minutes.
The fix is on their device, and releasing the block without finding it just schedules the next call. Ask what mail clients are configured, and on how many devices.
What it does not replace
cPHulk blocks repeated failures. It does nothing about a single correct login with a stolen password, which is what actually causes most account compromises.
The measures that address that are two-factor authentication and SSH keys instead of passwords: two-factor authentication in cPanel and managing SSH keys cover both.
Together they are the actual answer: cPHulk handles volume, and those handle the attempt that succeeds. The WHM security centre goes into what else sits in the same section.
Read the log rather than guessing
The blocked list shows what is blocked now. The history explains why, and it is where a pattern becomes visible.
grep -i cphulk /var/log/messages | tail -40 mysql -e "SELECT * FROM cphulkd.brutes ORDER BY LOGINTIME DESC LIMIT 20;" 2>/dev/null
Two patterns are worth distinguishing. Many failures against many usernames from one address is an attack, and blocking is working as intended. Many failures against one username from one address is usually a misconfigured client belonging to that user.
The second needs a conversation rather than a release, because releasing it simply restarts the cycle within minutes. Diagnosing a mail client that will not connect walks through finding the device.
The root account deserves separate treatment
Attempts against root are qualitatively different from attempts against a customer account, and the settings can reflect that.
A lower failure threshold and a longer block for root costs nothing. Nobody legitimately fails a root login repeatedly, and notifications on root blocks are the one alert in this system worth receiving every time.
Better still is not exposing that login to failed attempts at all: two-factor on the administrative account defeats the case this protection cannot cover, which is a single successful login with a stolen password. There is more in two-factor authentication in cPanel.
Blocks that arrive during ordinary work
Three legitimate activities trigger this protection regularly, and knowing them saves diagnosis.
A migration tool authenticating repeatedly while transferring an account. A monitoring system checking a login page. And a developer testing a script that authenticates in a loop.
All three look identical to an attack. The allow list is the answer for the first two, which are yours; the third is a conversation with whoever wrote the script, and a script that retries a failed authentication without a delay is a fault worth fixing regardless.
Where the database grows
The protection keeps its records in a database, and on a busy server the history accumulates.
It is not usually large enough to matter, and it is worth knowing where it is when investigating disk usage on the server rather than on an account. A table growing unexpectedly is a signal that the volume of attempts has changed.
cPanel expires old entries on a schedule. If that has stopped running, the table grows indefinitely, which is the same class of problem as any other scheduled cleanup that has quietly failed. Where server logs live goes over the rest of what accumulates.