Back to tutorials
Tutorial

cPanel IP Whitelisting Tutorial (2026): Lock Down WHM, cPanel & Webmail Access by Country and Trusted Networks

cPanel IP whitelisting tutorial (2026) to restrict WHM, cPanel & webmail by IP and country using CSF, cPHulk, and firewall rules.

By Anurag Singh
Updated on Jun 24, 2026
Category: Tutorial
Share article
cPanel IP Whitelisting Tutorial (2026): Lock Down WHM, cPanel & Webmail Access by Country and Trusted Networks

Most cPanel compromises don’t start with an exotic exploit. They start with exposed login surfaces: WHM (2087), cPanel (2083), and webmail (2096).

If your admin team only signs in from a few offices, VPN ranges, or known countries, you can shrink that attack surface fast. This cPanel IP whitelisting tutorial walks through a practical, reversible lockdown using CSF/LFD, cPHulk allowlists, and validation steps. The process is designed to avoid stranding you outside your own server.

The goal is simple: let trusted networks in, block everything else, and keep a recovery path. You should not need to beg for console access after one bad edit.

What you’ll build (and what you won’t)

  • Allowed access to WHM/cPanel/webmail from specific IPs, CIDRs, or a VPN subnet.
  • Optional country restrictions (useful for regional teams) with a clear warning about accuracy.
  • Layered controls: firewall allowlist + cPHulk allowlist + service-specific checks.
  • Rollback plan you can execute quickly if you lock yourself out.

This isn’t a generic hardening checklist. It’s a focused access-control change you can verify immediately.

Afterward, you should see fewer login hits in logs, fewer brute-force attempts reaching cPanel services, and a smaller blast radius if credentials leak.

Prerequisites and safe defaults

Before you change firewall rules, make sure you have a stable way back in.

  • A cPanel server (typically AlmaLinux/Rocky/CloudLinux) with root or sudo access.
  • Console/KVM access or a provider rescue path. If you don’t have one, be conservative.
  • Your current public IP (and any other admin IPs) written down.
  • CSF installed (common on cPanel servers). If you’re unsure, you’ll check in a minute.

If you’re choosing hosting for a security-sensitive cPanel deployment, start with a VPS where you control networking and firewall policy. A managed VPS hosting plan from HostMyCode is a good fit when you want cPanel-level control without owning every patch and security chore yourself.

Step 1: Inventory your cPanel ports and confirm what’s exposed

cPanel services often end up reachable on both IPv4 and IPv6. Start by checking what the server is actually listening on.

sudo ss -lntp | egrep ':(2083|2087|2096|2078|2080|80|443)\b'

Quick reference for the most relevant ports:

  • 2087 WHM over HTTPS
  • 2083 cPanel over HTTPS
  • 2096 Webmail over HTTPS
  • 2078 WebDisk over HTTPS (often unused; consider restricting too)
  • 2080 cPanel over HTTP (typically redirect; still a surface)

Then confirm what’s reachable from outside your network. From your workstation:

curl -kI https://YOUR_SERVER_IP:2087
curl -kI https://YOUR_SERVER_IP:2083
curl -kI https://YOUR_SERVER_IP:2096

Step 2: Decide your access model (IP-only vs. IP + VPN vs. country allowlist)

Choose the simplest model you can live with day-to-day. The best control is the one your team will actually follow.

  • Best: admin access only via VPN subnet (one allowlist entry).
  • Good: allow office IPs + a small set of named staff IPs.
  • Risky: country allowlisting. Geo-IP can be wrong, and legitimate travel triggers lockouts.

If you need remote access to internal services without opening ports, pair this tutorial with SSH tunnel setup guide. It helps you keep admin panels off the public internet where possible.

Step 3: Confirm CSF is installed (and install if needed)

Most cPanel servers run ConfigServer Security & Firewall (CSF). Verify it’s present:

sudo csf -v

If you see a version, you’re set.

If not, install CSF using ConfigServer’s installer (only from their official source) or your control panel’s recommended method. On production systems, skip random third-party scripts.

If you’re starting on a fresh VPS and want a clean baseline, provision on a HostMyCode VPS. You’ll get root access, predictable networking, and console recovery if a rule goes sideways.

Step 4: Add your trusted IPs to the CSF allowlist (the non-negotiable safety step)

Do this before you block anything. Add your admin IPs first to avoid self-inflicted lockouts during reloads and edits.

Edit:

sudo nano /etc/csf/csf.allow

Add entries like these (one per line). Use CIDR where possible:

# Office
203.0.113.10

# VPN subnet
198.51.100.0/24

# Admin home IP
203.0.113.55

Reload CSF:

sudo csf -r

Step 5: Restrict WHM/cPanel/webmail ports with CSF (tight, explicit rules)

On a cPanel server, there are two sane ways to handle port restrictions:

  • Method A (recommended): deny the ports globally, then allow trusted IPs explicitly in csf.allow.
  • Method B: use csf.deny for broad blocks and per-port allow rules (harder to maintain).

Method A is easier to reason about. The model is: “these IPs can reach these ports; everyone else can’t.”

Edit CSF config:

sudo nano /etc/csf/csf.conf

Find and set inbound TCP ports. On many cPanel servers, these are already defined.

Keep truly public ports (80/443, mail if applicable). Then restrict the admin panel ports using CSF filtering. Don’t rely on redirects or assumptions about service behavior.

Because cPanel/CSF setups vary, the most reliable approach here is CSF’s Port/IP filtering feature in /etc/csf/csf.conf:

Look for these settings:

  • TCP_IN (ports to allow inbound)
  • TCP6_IN (IPv6 inbound ports)
  • TCP_OUT (outbound)

Do not remove 80/443 unless this server doesn’t host websites.

For the admin ports (2083/2087/2096), you have two practical options:

Option 1: Keep ports open, but enforce per-port IP allow rules via csf.pignore + csfpre.sh (nft/iptables)

This setup is the most predictable for “only these IPs can reach these ports.” You add explicit allow rules for trusted CIDRs, then drop everything else.

Create a CSF pre-hook:

sudo nano /etc/csf/csfpre.sh

Add rules (iptables example; many cPanel systems still use iptables compatibility even with nft). Replace the CIDRs with yours:

#!/bin/sh

# Allow trusted admin networks to WHM/cPanel/webmail
iptables -I INPUT -p tcp -s 198.51.100.0/24 --dport 2087 -j ACCEPT
iptables -I INPUT -p tcp -s 198.51.100.0/24 --dport 2083 -j ACCEPT
iptables -I INPUT -p tcp -s 198.51.100.0/24 --dport 2096 -j ACCEPT

iptables -I INPUT -p tcp -s 203.0.113.10 --dport 2087 -j ACCEPT
iptables -I INPUT -p tcp -s 203.0.113.10 --dport 2083 -j ACCEPT
iptables -I INPUT -p tcp -s 203.0.113.10 --dport 2096 -j ACCEPT

# Drop everyone else to those ports
iptables -I INPUT -p tcp --dport 2087 -j DROP
iptables -I INPUT -p tcp --dport 2083 -j DROP
iptables -I INPUT -p tcp --dport 2096 -j DROP

Make it executable:

sudo chmod 700 /etc/csf/csfpre.sh

Reload CSF to apply:

sudo csf -r

IPv6 note: if your server has IPv6, mirror the rules with ip6tables or disable panel access on IPv6. Attackers will use the path you forget to close.

Option 2: Move WHM/cPanel behind a VPN or private interface (best security, but changes workflow)

If you can route admin traffic through a VPN, you can bind the cPanel services to a private interface. That avoids public exposure entirely.

This depends on your network design. It’s usually easiest on a VPS/dedicated server you fully control.

Step 6: Add cPHulk allowlist entries (so your own logins don’t get throttled)

The firewall blocks unwanted traffic. cPHulk handles brute-force attempts that still reach the login layer.

If you’re restricting by IP, whitelist your admin networks here as well. That prevents maintenance work from triggering bans.

In WHM:

  1. Go to Security Center → cPHulk Brute Force Protection
  2. Open Whitelist Management
  3. Add your admin IPs or VPN CIDRs

From CLI (handy if the UI is unreachable), you can manage cPHulk with:

sudo /usr/local/cpanel/scripts/cphulkdwhitelist --add 203.0.113.10
sudo /usr/local/cpanel/scripts/cphulkdwhitelist --add 198.51.100.0/24
sudo /usr/local/cpanel/scripts/restartsrv_cphulkd

Step 7: Test safely (two sessions, one rollback)

Test like you expect something to go wrong. That mindset keeps you from getting locked out.

  • Keep one SSH session open as root (or sudo) while you test.
  • From a trusted IP, load WHM: https://server:2087.
  • From an untrusted network (a mobile hotspot works), confirm you can’t reach the ports.

If you lock yourself out but still have SSH, comment out the drop rules in /etc/csf/csfpre.sh and reload:

sudo csf -r

If you lose SSH too, you’ll need console access. That’s a major reason many admins prefer VPS or dedicated servers with provider console tooling.

If you need help moving safely during security changes and cutovers, HostMyCode customers can use HostMyCode migrations.

Step 8: Optional country blocking (only if you understand the trade-offs)

Country rules can cut background noise, but they’re blunt tools. They also break legitimate travel, roaming carriers, and some corporate egress networks.

If you still want this, CSF supports country blocking via ccodes. First enable it in CSF (if not already), then deny countries:

sudo nano /etc/csf/csf.conf

Set:

CC_DENY = "CN,RU,KP"

Reload:

sudo csf -r

Then explicitly allow your admin networks in /etc/csf/csf.allow as you already did.

Allowlist usually wins over deny logic, but don’t rely on theory. Test from the networks you actually use.

Step 9: Log checks that prove it’s working

After the change, you should see fewer hits reaching cpsrvd (the cPanel service daemon). You should also see more rejected connections at the firewall layer.

Check:

  • /usr/local/cpanel/logs/access_log (cPanel/WHM access)
  • /var/log/lfd.log (CSF/LFD blocks)
  • /usr/local/cpanel/logs/cphulkd.log (cPHulk activity)

Useful commands:

sudo tail -n 50 /var/log/lfd.log
sudo tail -n 50 /usr/local/cpanel/logs/access_log
sudo grep -E '2083|2087|2096' /usr/local/cpanel/logs/access_log | tail -n 25

If you want earlier warning, add lightweight monitoring and alerts. Pair this with server monitoring setup guide with Netdata so connection spikes and load changes don’t surprise you.

Step 10: Common pitfalls (and how to avoid them)

  • Forgetting IPv6: you block IPv4 and attackers walk in via IPv6. Either add ip6tables rules or disable panel access on IPv6.
  • Dynamic IP admins: if staff IPs change daily, use a VPN. Don’t keep expanding allowlists until the firewall becomes meaningless.
  • Blocking yourself during AutoSSL renewals: generally unrelated, but lockouts can interrupt troubleshooting. Keep SSH and console access available.
  • CDN/WAF confusion: a CDN does not sit in front of WHM/cPanel ports. Don’t assume it protects admin ports.

If your issue isn’t access control but certificate renewals failing, follow the dedicated steps in SSL renewal troubleshooting tutorial.

Hardening checklist (printable)

  • Allowlist admin IPs/CIDRs in /etc/csf/csf.allow
  • Implement per-port allow + drop rules for 2087/2083/2096 (and optionally 2078/2080)
  • Mirror restrictions for IPv6 or disable IPv6 panel exposure
  • Whitelist admin networks in cPHulk
  • Verify from trusted and untrusted networks
  • Confirm log evidence: cpsrvd hits down, firewall drops up
  • Document rollback steps and keep console access available

Summary: the fastest way to reduce cPanel login risk

Restricting WHM, cPanel, and webmail by IP is one of the highest-signal changes you can make on a hosting server. It’s easy to verify and easy to undo.

It also keeps most random internet traffic away from your login endpoints. Once it’s in place, logs get quieter and real problems stand out.

If you want a server where you can apply these controls confidently (with reliable networking and recovery options), start with a HostMyCode VPS or choose managed VPS hosting if you’d rather have an expert team handle the operational edges.

Locking down WHM/cPanel access goes smoother when you have stable IPs, straightforward firewall tooling, and a real recovery path. HostMyCode’s VPS plans give you full root control, and managed VPS hosting adds hands-on help for security changes like allowlisting and quick rollbacks.

FAQ

Will IP allowlisting break cPanel AutoSSL or website visitors?

No, not if you only restrict ports like 2083/2087/2096. Your public websites typically run on 80/443, which should remain open.

Can I restrict WHM but keep webmail public?

You can, but it’s rarely a good trade. Webmail logins are targeted too. If clients need webmail from anywhere, consider moving them to authenticated SMTP/IMAP apps and restricting webmail to trusted networks.

What if my admin IP changes frequently?

Use a VPN and allowlist the VPN subnet. If you keep adding changing IPs, you’ll eventually re-open the attack surface.

Do I need both CSF allowlisting and cPHulk allowlisting?

Yes. CSF controls network reachability; cPHulk controls login throttling/blocks. Using both reduces risk and helps you avoid accidental admin bans during maintenance.

How do I recover if I lock myself out of WHM?

If SSH still works, remove or comment the drop rules in /etc/csf/csfpre.sh and run csf -r. If SSH is also blocked, you’ll need console access from your provider.