Tudásbázis

cPHulk Brute Force Protection is the cPanel feature that automatically blocks IP addresses making repeated failed logins. It's the first line of defense against credential-guessing attacks — the most common type of attack against any hosting account. This article explains what cPHulk does, how it's configured by default on ipxcore servers, and how to tune it for your situation.

What cPHulk protects

• cPanel and WHM logins — the front door
• SSH/SFTP logins — if password auth is enabled
• FTP logins — though we recommend you don't use FTP at all
• Webmail logins (Roundcube, Horde)
• POP3 and IMAP logins — for email clients
• SMTP authenticated logins — for outbound mail

cPHulk does NOT protect:

• Logins to applications running on your account (WordPress wp-admin, Joomla admin, custom apps) — those need their own protection (Wordfence, Solid Security, etc.)
• Form submissions or contact forms
• API endpoints exposed by your applications

Default settings on ipxcore

cPHulk runs by default on every ipxcore server with these settings:

• IP-based threshold: 4 failures within 5 minutes triggers a 15-minute block
• Username-based threshold: 15 failures within 5 minutes triggers a 15-minute block on attempts to that account
• Permanent ban after 30 failures within 1 hour — the IP is added to the long-term blocklist
• Notifications sent to the server administrator on heavy attack patterns

These defaults catch most automated attacks while rarely tripping legitimate users (a person fat-fingering their password three times never hits the threshold).

If you've been blocked by cPHulk

If you can't log in and your password is correct, you may be cPHulk-blocked. Symptoms: login attempts succeed (right username/password) but cPanel returns "Login attempt failed" anyway, or doesn't respond at all.

1. Note your current IP address from api.ipify.org (do this from a different network if possible — mobile hotspot, friend's WiFi).
2. From that other network, log in to your client area.
3. Go to the CSF firewall manager.
4. Find the entry for the cPanel service and unblock or whitelist your IP.

This same flow handles both CSF and cPHulk blocks — the firewall manager addresses both layers.

Customizing cPHulk (reseller accounts)

Resellers don't have direct WHM access to cPHulk settings (that's root-only). However, you can:

• Whitelist specific IP addresses for your own admin access — open a ticket with the IP and we'll add it.
• Request a higher threshold if your customer base has unusual login patterns — we can adjust per-server.
• Request that specific IPs be permanently banned beyond cPHulk's automatic decisions.

Reading the cPHulk log

If you have SSH access on a dedicated server, the cPHulk log lives at /usr/local/cpanel/logs/login_log. Each line shows username, IP, success/fail, and the service. To find recent failures:

$ grep FAILED /usr/local/cpanel/logs/login_log | tail -20

For shared and reseller accounts, this log isn't accessible. Use cPanel's Errors log under Metrics instead — it shows blocked-login activity at the per-account level.

cPHulk vs CSF: how they overlap

ipxcore servers run both cPHulk and CSF. They're complementary:

• cPHulk watches application-level authentication (cPanel, WHM, mail). It knows whether a login was successful or not.
• CSF watches network-level activity (port scans, connection rates, known-bad IPs). It doesn't inherently understand authentication failures.
• Together they cover most attack patterns. CSF blocks the "spray a million IPs at port 22" attacks; cPHulk blocks the "guess one user's password 1000 times" attacks.

The big picture: layered defense

cPHulk alone isn't enough. Real-world hosting account compromises happen through:

1. Reused passwords — leaked from another breach. cPHulk doesn't see this attack — it's just "one successful login from a new IP." Solution: 2FA.
2. Vulnerable applications — outdated WordPress plugins, etc. cPHulk doesn't see this. Solution: keep applications updated and use application-level security tools.
3. Weak passwords on application admins — admin / password123. cPHulk doesn't see attempts on WordPress admin. Solution: strong passwords on every layer.
4. Phishing — attacker tricks the user into entering credentials on a fake site. cPHulk doesn't help. Solution: 2FA again.

cPHulk is necessary but not sufficient. Use it alongside 2FA, application updates, strong passwords, and SSH keys. Each layer catches what the others miss.