cPanel gives you three different ways to block an IP address, and they aren’t interchangeable. The IP Blocker in cPanel blocks access to your websites only. CSF blocks at the server firewall, before traffic reaches any service — but it requires WHM, so it’s for VPS and dedicated servers. And cPHulk blocks login attempts specifically, and often blocks people automatically without anyone asking it to.
Which one you need depends on what you’re trying to stop. And if you landed here because you got blocked rather than because you want to block someone, skip to the last section — that’s the more common situation, and the fix is different.
| Block a visitor from your site | IP Blocker in cPanel — available on any plan |
| Block traffic at the server level | CSF in WHM — needs VPS or dedicated |
| Stop brute-force login attempts | cPHulk in WHM — usually already running |
| You got blocked yourself | See the unblocking section below |
Table of Contents
The three tools, and why the difference matters
They operate at different points in the request, which is exactly why choosing wrong produces “I blocked it but it still works”.
| Tool | Blocks what | Where | Needs |
|---|---|---|---|
| IP Blocker | Access to your websites, via .htaccess | Web server level — traffic still reaches the server | cPanel access. Any plan |
| CSF | Everything — web, mail, FTP, SSH | Firewall level, before any service | WHM root. VPS or dedicated |
| cPHulk | Login attempts after repeated failures | Authentication level, automatically | WHM. Usually enabled by default |
The practical distinction: the IP Blocker stops someone from seeing your site. CSF stops them from reaching your server at all — including your mail server and SSH. If someone is scraping your content, the IP Blocker is enough. If someone is hammering your SSH port, only CSF helps.
Blocking an IP with the cPanel IP Blocker
Available on any plan, including shared hosting, and the right tool when the problem is website traffic.
- Log into cPanel —
https://yourdomain.com/cpanelor port 2083. Our guide on cPanel ports covers the access addresses. - Under Security, open IP Blocker.
- Enter what you want to block in the field. It accepts several formats:
| Format | Example |
|---|---|
| Single IP | 192.0.2.15 |
| Range | 192.0.2.1-192.0.2.50 |
| CIDR | 192.0.2.0/24 |
| Implied range | 192.0.2. — blocks the whole final octet |
| Domain | example.com — cPanel resolves it to an IP |
- Click Add. The rule takes effect immediately.
What it actually does: writes deny rules into your .htaccess file. That’s worth knowing for two reasons — you can inspect or edit them directly, and a plugin or process that rewrites your .htaccess can wipe them out without warning.
Blocking by domain has a catch: cPanel resolves the domain to an IP at the moment you add it. If that IP changes later, the block stops matching. For anything that needs to stay blocked, use the IP.
Blocking an IP with CSF
CSF (ConfigServer Security & Firewall) sits in front of everything. It’s a graphical front end for iptables, distributed as a WHM plugin, and it’s the standard on cPanel servers — but it needs root access, so it’s for VPS and dedicated servers only.
Through WHM:
- Log into WHM as root.
- Go to Plugins → ConfigServer Security & Firewall.
- Scroll to csf – Quick Actions.
- In Quick Deny, enter the IP and — importantly — a comment explaining why.
- Click Quick Deny.
- Click Restart csf + lfd to apply.
Through the command line, which is faster if you have SSH:
# Block an IP permanently
csf -d 192.0.2.15 "Brute force on SSH"
# Allow an IP permanently
csf -a 203.0.113.10 "Office IP"
# Search for an IP in the rules
csf -g 192.0.2.15
# Temporary block, 3600 seconds
csf -td 192.0.2.15 3600 "Temporary"
# Remove a block
csf -dr 192.0.2.15
Blocks go into /etc/csf/csf.deny, allows into /etc/csf/csf.allow.
Always write the reason. Six months from now, an unexplained IP in csf.deny is a mystery nobody wants to resolve — and the safe assumption (“probably important”) means it stays forever.
LFD: the part that blocks automatically
CSF ships with LFD (Login Failure Daemon), which watches logs for failed SSH, FTP, IMAP, POP3 and web authentication attempts, and blocks IPs automatically once they cross a threshold.
This is doing most of the work on a typical server, and it’s why you’ll find IPs in csf.deny that nobody added manually. A common configuration blocks permanently after five failed logins within an hour.
It’s also why legitimate users get blocked. A colleague who mistypes their email password on their phone five times, with the phone retrying automatically, can trigger it.
Blocking by country
CSF supports country-level blocking through CC_DENY in the firewall configuration, using two-letter country codes.
Use this sparingly. It’s a blunt instrument: it blocks legitimate visitors and search engine crawlers from those countries too, and the GeoIP lookups add processing overhead on every connection. It’s rarely the right answer outside of very specific abuse patterns.
cPHulk: the one blocking people you didn’t ask about
cPHulk is cPanel’s own brute-force protection, enabled by default on most servers, and it blocks login attempts to cPanel, WHM, webmail, FTP and SSH.
It’s a frequent source of “I can’t log in and I don’t know why” — because it works silently and its block list is separate from CSF’s. Someone who mistyped their password a few times is locked out, and looking in CSF shows nothing.
It’s in WHM → Security Center → cPHulk Brute Force Protection, with its own History Reports listing blocked IPs and a whitelist tab.
Add your office and home IPs to the allow lists of both CSF and cPHulk before you start configuring blocks. Locking yourself out of your own server is the most common self-inflicted incident in this area, and recovering means either console access through your provider’s panel or a support ticket. Two minutes of prevention avoids an afternoon of it.
When blocking IPs is the wrong answer
Worth saying, because the tutorials never do: blocking individual IPs is reactive and rarely scales.
Attackers rotate addresses. Blocking one IP from a botnet accomplishes very little — the next request comes from a different one, and you end up maintaining a list that grows forever.
For brute force, rate limiting beats blocking. LFD and cPHulk already do this automatically, and better than manual rules.
For bots and scrapers, a WAF is the right layer. ModSecurity or Cloudflare handle patterns rather than addresses.
And blocking ranges catches real users. Blocking an entire ISP because one customer misbehaved blocks everyone on that ISP.
Where blocking genuinely helps: a specific, persistent source that isn’t rotating; stopping an attack in progress while you fix the underlying problem; and restricting access to sensitive areas — which is the strongest use, and the reverse of blocking.
The better pattern: allow instead of deny
Rather than blocking bad addresses, restrict the sensitive parts to known good ones.
Limiting WHM and cPanel access to your office and VPN IPs is more effective than any deny list, because it removes the login interface from public view entirely. Our guide on cPanel ports covers which ports to restrict.
This is not theoretical. In 2026, a cPanel authentication bypass was used to compromise around 44,000 servers, and the interim official workaround was to firewall off the panel ports until a patch shipped — our coverage of that incident has the details. Servers that already restricted those ports by IP were not reachable for the exploit.
If you’re the one who got blocked
The more common reason people search this topic. The symptom is distinctive: everything fails from one location and works fine from another — often looking like a network problem when it isn’t.
Confirm it’s a block, not a network issue. Try the site on mobile data. If it works there and not on your usual connection, your IP is blocked.
Then check all three lists — this is where most people give up, because they check one and conclude the IP isn’t blocked:
- CSF: WHM → ConfigServer Security & Firewall → Firewall Deny IPs, or
csf -g YOUR-IP
- cPHulk: WHM → Security Center → cPHulk → History Reports
- IP Blocker: cPanel → IP Blocker, in the account itself
On shared hosting, you have none of this — contact your host with your IP address (from any “what is my IP” service) and the approximate time it stopped working.
Then find out why, or it recurs. Usually it’s an email client configured with an old password retrying in the background, a script polling with wrong credentials, or someone on the same office connection failing logins repeatedly.
On Copahost shared hosting, CSF and cPHulk are already tuned — and if you get blocked, support unblocks you rather than explaining where the setting is. On a VPS you get root access and full control, with a managed option if you’d rather not configure the firewall yourself.
See hosting plansFrequently asked questions
How do I block an IP address in cPanel?
Open cPanel, go to the Security section and click IP Blocker. Enter the IP, range, CIDR block or domain, then click Add. This writes deny rules into your .htaccess and blocks access to your websites — though the traffic still reaches the server, since the block happens at the web server level.
What is CSF in cPanel?
CSF (ConfigServer Security & Firewall) is a firewall plugin for cPanel servers, providing a graphical interface for iptables in WHM. It blocks traffic at the network level, before it reaches any service, and includes LFD, which automatically blocks IPs after repeated failed logins. It requires root access, so it’s available on VPS and dedicated servers rather than shared hosting.
What’s the difference between cPanel IP Blocker and CSF?
The IP Blocker only blocks access to your websites, through .htaccess rules, and works on any plan. CSF blocks at the server firewall, covering every service — web, mail, FTP, SSH — and requires WHM root access. If someone is scraping your site, the IP Blocker is enough. If they’re attacking SSH or your mail server, only CSF stops them.
Why was my IP blocked from my own server?
Usually LFD or cPHulk blocked it automatically after repeated failed logins. The most common trigger is an email client still configured with an old password, retrying in the background until the threshold is crossed. Check the CSF deny list and cPHulk’s history report, since the two are separate.
How do I unblock an IP in CSF?
In WHM, go to ConfigServer Security & Firewall and use Quick Unblock, then restart csf and lfd. From the command line, use csf -dr followed by the IP. Also check cPHulk separately, since an IP can be blocked in both places at once.
Can I block an entire country in cPanel?
Yes, through CSF’s CC_DENY setting, using two-letter country codes. It’s worth using sparingly: it blocks legitimate visitors and search engine crawlers from those countries, and the GeoIP lookups add overhead to every connection.
Does blocking IPs actually stop attacks?
Only partly. Determined attackers rotate addresses, so blocking individual IPs is reactive and doesn’t scale. Automatic rate limiting through LFD and cPHulk handles brute force better, and a WAF handles bots by pattern rather than address. Blocking works best against a specific persistent source, or as a stopgap while you fix the underlying issue.
Can I block IPs on shared hosting?
Yes, but only through the cPanel IP Blocker, which covers access to your websites. Server-level tools like CSF and cPHulk require root access to WHM, which shared plans don’t include. If you need something blocked at the firewall level, your host has to do it.
Conclusion
Three tools, three layers: the IP Blocker keeps someone off your websites, CSF keeps them off the server entirely, and cPHulk stops login attempts — usually without being asked. Pick by what you’re trying to stop, whitelist your own address before you start, and always record why a block exists. But the more durable move is the inverse of blocking: restricting the panel and SSH to addresses you trust removes the target rather than reacting to whoever finds it, which is exactly what protected the servers that weren’t caught by the 2026 cPanel exploit.
