Stopping Brute-Force Attacks on cPanel Servers: cPHulk, Firewalls and the CSF Situation
How to stop password-guessing attacks on cPanel & WHM with cPHulk and the right firewall, plus an accurate update on ConfigServer CSF after the 2025 shutdown and cPanel's maintained fork.
Every internet-facing cPanel server receives a steady stream of automated password guesses against SSH, WHM, cPanel, webmail, email and FTP. The built-in defense is cPHulk Brute Force Protection in WHM: turn it on, whitelist your own IPs, keep IP-based protection and one-day blocks enabled, and let it block repeat offenders at the firewall. Pair it with a packet firewall that exposes only the ports you use. If you rely on ConfigServer Security & Firewall (CSF), know that its original developer shut down on August 31, 2025; cPanel now maintains a fork for security and stability fixes, and eligible servers should be on that version. Here is how to put the pieces together.
What brute-force attacks target on a cPanel server
Attackers try common and leaked passwords against any login they can reach:
- SSH (port 22 by default)
- WHM (2087) and cPanel (2083)
- Webmail (2096) and mail logins over IMAP, POP3 and SMTP
- FTP
- Web applications such as WordPress login pages, which run over normal HTTPS and are handled differently (see below)
Even unsuccessful attacks waste resources and fill logs. Successful ones lead to spam from hijacked mailboxes, defaced sites or full server compromise.
Layer 1: cPHulk Brute Force Protection
cPHulk is included with cPanel & WHM. According to cPanel's documentation it monitors cPanel, WHM, mail (Dovecot and Exim), Pure-FTPd and SSH.
Turn it on safely
- Open WHM » Security Center » cPHulk Brute Force Protection and set the toggle to On.
- Go straight to Whitelist Management and add the IP addresses your administrators use. cPHulk shows a warning with an Add to Whitelist button if your current address is missing. cPanel strongly recommends this to avoid locking yourself out.
The settings that matter
| Setting | cPanel default | What it does |
|---|---|---|
| Maximum Failures by Account | 15 | Locks the account name after repeated failures within the protection period |
| Brute Force Protection Period | 5 minutes | Window used to count account failures |
| Maximum Failures per IP Address | 5 | Blocks the source IP after repeated failures |
| Maximum Failures per IP Address before the IP Address is Blocked for One Day | 30 | Longer block for persistent sources |
| Block IP addresses at the firewall level if they trigger a one-day block | Selected | Adds a firewall rule so the IP cannot reach any service |
| Duration for Retaining Failed Logins | 360 minutes | How long failures are remembered |
The defaults are a reasonable start. Two adjustments to consider:
- Enable Block IP addresses at the firewall level if they trigger brute force protection so short blocks also apply at the firewall, not just at login.
- Leave Allow username protection to lock the "root" user unchecked unless you have console access; otherwise an attacker could lock root out on purpose.
Notifications and reports
Under Notifications, consider alerts for root logins from IP addresses that are not whitelisted. Use History Reports (Failed Logins, Blocked Users, Blocked IP Addresses and One-day Blocks) to spot patterns, and Remove Block when a real user locks themselves out.
Country rules, with care
Countries Management lets you whitelist or blacklist countries using MaxMind GeoLite2 data. Blocking regions where you have no staff or clients can cut noise, but remember that travelers and VPN users exist, and attackers also use servers inside the US.
What cPHulk does not stop
cPanel notes that cPHulk does not affect public key authentication or API tokens. That is good (you can still get in with a key), and it also means tokens must be scoped and kept secret. cPHulk also does not protect web application logins such as WordPress.

Layer 2: A packet firewall
cPHulk reacts to failures; a firewall reduces what attackers can reach in the first place.
Open only what you use
cPanel's firewall guide lists every port its services use and says plainly: only open ports for services that you use, and always maintain console access. It recommends nftables on AlmaLinux, Rocky Linux and CloudLinux, and iptables instead of ufw on Ubuntu.
Restrict admin ports by IP
If your team works from fixed IPs or a company VPN, limit SSH (22) and WHM (2087) to those addresses. On AlmaLinux, Rocky Linux and CloudLinux, WHM's Host Access Control writes port-based nft rules; on Ubuntu it uses /etc/hosts.allow and /etc/hosts.deny. Enter ACCEPT rules before DROP or REJECT rules. cPanel also notes that Host Access Control rules are ignored if another firewall application is installed on an nftables server, so use one tool, not two.
Use keys for SSH
Brute-forcing SSH passwords is pointless if passwords are off. Set up keys in Manage root's SSH Keys, test them, then disable passwords with SSH Password Authorization Tweak.
Where ConfigServer CSF stands today
For years, CSF (with its login failure daemon, lfd) was the default answer to "how do I firewall a cPanel server". The situation changed in 2025, and much of what circulates online is out of date. Here is what the sources support as of this writing:
| Date | What happened |
|---|---|
| August 31, 2025 | Way to the Web Ltd, the company behind ConfigServer, closed. Downloads, updates and support ended. Its commercial products (cxs, osm, MSFE) could no longer be installed; installed copies of the free scripts, including csf, kept running but stopped receiving updates from ConfigServer. |
| Before closing | CSF was released under the GNU GPLv3. |
| February 2026 | cPanel began publishing a public, GPLv3 fork of CSF focused on critical security and stability fixes, packaged as cpanel-csf for cPanel & WHM servers, and moved eligible servers to its update mirrors. Providers' notices cite February 18; cPanel's article cites February 25. |
According to cPanel's announcement as summarized by hosting providers, the automatic switch applied only to servers running CSF 14.00 through 15.00 that still used the original update source with AUTO_UPDATES enabled. Existing rules and configuration were kept. Servers outside those conditions, or with auto-updates off, were not switched.
What admins should do now
- Check your version. Run
csf -v. If the server still points at the old ConfigServer source, it is receiving no updates at all. - Move to the maintained version. The command cited from cPanel's announcement is
/scripts/autorepair cpanel_csf_install. Keep AUTO_UPDATES on afterward so security fixes arrive. - Expect maintenance, not new features. cPanel describes its scope as security and stability fixes. Plan configuration and troubleshooting as your own responsibility.
- Do not mix firewalls. cPanel's documentation states that CSF and APF do not function with firewalld; you must remove firewalld if you use them.
Alternatives if you do not want CSF
- cPHulk plus nftables (or iptables on Ubuntu) and Host Access Control. All built into or recommended by cPanel, with no third-party dependency.
- Community forks of CSF, such as the actively developed
Aetherinox/csf-firewallproject on GitHub. They are independent of cPanel, so evaluate who maintains them and how updates are delivered before relying on one. - Commercial security suites offered for cPanel servers. Compare what they cover, and make sure only one product manages the firewall.
For most small-business servers, cPHulk plus a tightly scoped nftables firewall, SSH keys and 2FA covers brute-force risk without adding another component to maintain.
Layer 3: Web application logins
WordPress and other app logins run over HTTPS, so cPHulk and packet firewalls do not see failed passwords there. Protect them with:
- ModSecurity with the OWASP Core Rule Set, plus rate limiting at a CDN or WAF in front of the site.
- 2FA for every administrator account in the application.
- Unique admin usernames and removal of unused accounts.
Brute-force defense checklist
- cPHulk enabled; admin IPs whitelisted; one-day firewall blocks on.
- Root lockout by username left off; root-login notifications on.
- Firewall exposes only needed ports; SSH and WHM limited by IP where practical.
- SSH key-only; 2FA for WHM and cPanel.
- CSF either removed or on cPanel's maintained
cpanel-csfwith auto-updates; never alongside firewalld. - Web app logins protected with a WAF and 2FA.
Get a professional review
Brute-force noise is constant, but a breach from it is avoidable. Max, our founder, is cPanel & WHM certified, and our team hardens and monitors cPanel servers for businesses across Miami-Dade and South Florida, with remote support nationwide. Request a free IT assessment and we will check your cPHulk, firewall and CSF setup with you.
Sources
- cPHulk Brute Force Protection – cPanel & WHM Documentation
- How to Configure Your Firewall for cPanel Services – cPanel Documentation
- Host Access Control – cPanel & WHM Documentation
- Will cPanel provide its own fork of CSF? – cPanel Support
- cpanel/cpanel-csf – cPanel's CSF fork on GitHub
- End of Life Notice: ConfigServer Software and Support Ending August 31, 2025 – EuroVPS
- Important Update About CSF – Easyspace


