cPanel has two tools that block visitors by address, and both are more limited than they look. Knowing what they cannot do is more useful than knowing how to configure them, because the situations people reach for them in are usually not the situations they help with.
IP Blocker
Under Security, IP Blocker refuses requests from an address or a range. The visitor gets a 403.
Enter a single address, a range, or a CIDR block. It takes effect immediately and is stored in your .htaccess.
What it is genuinely useful for
One persistent nuisance. A specific address scraping your site or repeatedly submitting a form. Blocking it works because there is one of them.
Restricting an admin path to your own office address, which is a real hardening measure if your address is static.
A short-term measure while you fix the actual problem.
What it does not do
Stop attacks generally. Automated attacks come from thousands of addresses and rotate constantly. Blocking them individually is a treadmill, and by the time you have added ten the attacker is on a different set.
Reduce server load meaningfully. The request still arrives and is still processed far enough for the rule to evaluate it. A 403 is cheaper than a full page render, but it is not free, and a blocked address hammering you still costs.
Survive shared addresses. Mobile networks and corporate offices put many people behind one address. Blocking one abusive user can block a hundred legitimate ones, and you will not hear from the ninety-nine who simply left.
If the problem is automated login attempts, attempt limiting and two-factor solve it properly and blocking does not. There is more in securing WordPress.
Leech Protection
A narrower tool with one specific purpose: a password-protected directory where a user has shared their credentials, so many people are logging in with one account.
It counts logins per user in a period and, when the threshold is exceeded, suspends or redirects that account. You can be notified.
This applies to directories protected by cPanel's own directory privacy, not to logins inside an application. It does nothing about a shared WordPress password, which is a common misunderstanding.
When leech protection applies
Membership content behind directory protection, where one paying subscriber's credentials have been posted somewhere.
That is a real scenario and this is the right tool for it. For almost anything else it is not relevant, and the reason it is worth writing about is so you can rule it out quickly.
Both live in .htaccess
Which has two consequences worth knowing.
A long block list makes the file long, and it is evaluated on every request. A few dozen entries is unremarkable; hundreds is worth reconsidering.
And if you edit .htaccess by hand as well, be careful not to remove rules the panel added. The panel will then disagree with the file about what is blocked.
Take a copy before editing it manually. A syntax error there produces a 500 across the whole site.
What to do instead, usually
Work out what the traffic actually is before blocking it. The access log shows what is being requested and by whom. For reading it, see viewing website statistics.
A search engine crawling too enthusiastically is managed with crawl settings, not a block. Automated login attempts are managed with attempt limits. A single abusive address is the case where blocking is right.
If the volume is genuinely large and sustained, that is a support ticket, blocking at the server or network level is more effective than anything you can do in .htaccess, and it is not a reseller or account-level operation.
Blocking by name barely works, because the name is a string the client chooses. How to Stop Bots and Scrapers from Consuming Resources explains what does.
Blocking by address ages badly
A block list feels permanent and the addresses in it are not.
Residential connections change address regularly, mobile networks share one address across very large numbers of users, and business connections get reassigned. A block added two years ago is now either blocking somebody unrelated or protecting nothing.
grep -c 'deny from' ~/public_html/.htaccess 2>/dev/null
grep 'deny from' ~/public_html/.htaccess 2>/dev/null | awk '{print $3}' | head -10
Read the list occasionally and remove what you cannot justify. The specific risk with a shared mobile address is that one blocked visitor becomes thousands of blocked visitors, and none of them can tell you.
Blocking a whole country is the extreme version of this. It is occasionally the right answer and it should be a deliberate decision with a review date, not a rule added during a bad afternoon.
Read what the rules are actually doing
Both features write into a configuration file, and that file accumulates entries from several sources.
grep -nE 'deny|allow|Require|RewriteCond' ~/public_html/.htaccess | head -20
awk '$9 == 403 {print $1}' ~/logs/example.com | sort | uniq -c | sort -rn | head
The second command shows who is actually being refused. A large count from a single address is the rule working. A wide spread of addresses each refused once suggests the rule is broader than intended.
Check whether anything legitimate appears there. Search engine crawlers being refused is a costly mistake that produces no error anybody notices, and it shows up in this list before it shows up in traffic.
Prefer a control that expires by itself
The trouble with a manual block list is that adding is easy and removing never happens.
An automated tool that bans an address for a period and then releases it solves the ageing problem entirely, because nothing is permanent unless the behaviour continues.
fail2ban-client status 2>/dev/null | tail -5 fail2ban-client status sshd 2>/dev/null | grep -i banned
Use the manual list for the small number of cases that genuinely need to be permanent, and let something with a timer handle the rest. Setting up fail2ban covers the automated version.