Should You Restrict WHM Ports with Host Access Control or a Firewall?

When an administrator logs into a cPanel & WHM server, one of the most common warnings in automated security audits or support tickets is that WHM administrative ports (typically TCP 2086 and 2087) are exposed to the entire internet. Many server owners head straight to the WHM interface, open the Host Access Control section, type in their office IP address, and assume the management interface is now sealed off from unauthorized traffic. While Host Access Control does prevent unauthorized clients from authenticating, relying on it alone leaves a subtle gap in server hardening. Understanding why requires looking at where network packets get inspected, what the server daemon has to process, and how network-level firewalls differ from application-level access lists.

The Symptom: Traffic Still Reaches cpsrvd

The typical situation starts with a support inquiry or an audit finding: an administrator restricted access to whostmgrd inside WHM Host Access Control, yet when checking server activity, the service daemon (cpsrvd) is still constantly answering handshakes, logging connection attempts, and consuming process table resources from random public IPs across the globe. To see what is actually happening when a client connects to port 2087, you can inspect the active listening sockets and connection states on the server via SSH:

BASH

ss -tulpn | grep -E ':(2086|2087)'

This read-only command lists which processes are listening on ports 2086 (unencrypted WHM) and 2087 (encrypted WHM). In a default installation, you will see cpsrvd bound to 0.0.0.0 or :::, meaning it accepts connections on all network interfaces. When a remote client initiates a TCP three-way handshake toward port 2087, the Linux kernel completes the handshake and passes the established socket to cpsrvd. Only after the socket is established does Host Access Control come into play. If the source IP does not match an allowed rule, the service rejects the request or closes the connection. The remote machine still engaged your web server, established a connection, initiated TLS negotiation in many cases, and forced the cPanel management daemon to consume memory and CPU cycles.

How Host Access Control Works Under the Hood

Host Access Control inside WHM historically links into TCP wrappers (/etc/hosts.allow and /etc/hosts.deny) or evaluates client IP addresses through internal service middleware before authentication. Its purpose is administrative authorization rather than perimeter defense. When an unauthorized IP contacts port 2087 with Host Access Control active:

The network interface accepts the initial SYN packet.
The Linux TCP stack sends a SYN-ACK and completes the handshake.
If connecting over HTTPS, TLS negotiation takes place, exchanging certificates and negotiating ciphers.
cpsrvd inspects the client IP against its access control tables.
If the IP is not permitted, the daemon terminates the session or serves an access denied page.

This behavior creates two distinct problems. First, any high-volume connection flood or scanning botnet will still consume connection slots in cpsrvd, potentially causing resource starvation for legitimate administrative tasks. Second, if a software bug or an authentication bypass vulnerability exists in the pre-authentication handling code of cpsrvd—such as in the HTTP parsing engine, the cookie handler, or the SSL termination layer—the attacker can exploit that flaw because their packets are still reaching the application. When evaluating server logs after an unexpected access spike, remember that web service logging can be misleading; understanding how logs record requests versus drops is covered in our guide on why HTTP 200 in access logs does not mean an exploit succeeded.

How a Network Firewall Differs

A network firewall—whether implemented via local packet filtering tools like iptables, nftables, or ConfigServer Security & Firewall (CSF), or upstream at the hypervisor or cloud provider layer—operates at the kernel or network interface level. When you restrict ports 2086 and 2087 using a firewall rule, the sequence changes completely:

A remote IP sends a SYN packet targeting port 2087.
The packet filter checks the incoming packet headers against its rule table before any application receives it.
If the source IP is not explicitly whitelisted, the kernel drops the packet immediately (or sends a TCP RST depending on your rule configuration).
cpsrvd never receives the packet, executes zero instructions, and performs no TLS handshake.

To check whether your local firewall is actively managing these ports or if they are wide open to the world, inspect your current filter chains. For example, on servers running CSF or raw iptables, you can check the filtering state with:

BASH

iptables -L INPUT -v -n | grep -E 'dpt:208(6|7)'

If this command yields no output, or if it shows a blanket ACCEPT policy without source IP restrictions (0.0.0.0/0), your server daemon is taking the full brunt of all incoming traffic on those ports.

Comparing the Two Layers

Neither tool is inherently useless; they serve different points in defense-in-depth.

Feature	Host Access Control	Network Firewall (Local or Cloud)
Layer of Operation	Application / Service layer (`cpsrvd`)	Network / Transport layer (Kernel or Edge)
Resource Overhead	High (completes TCP handshake and TLS)	Minimal (drops or rejects at packet arrival)
Zero-Day Exposure	Exposed if the bug is in pre-auth handling	Protected (packets never reach daemon)
Port Flexibility	Tied to predefined cPanel services	Any arbitrary port or protocol
Risk of Lockout	Moderate (can often be overridden via SSH)	High (requires out-of-band console if misconfigured)

Host Access Control is convenient because it is integrated directly into the WHM web interface, making it quick to grant access to a specific reseller or staff member without granting them root SSH access to edit system firewall files. However, it cannot shield the application stack from unauthenticated network probes or protocol-level vulnerabilities.

The Recommended Approach for Production Servers

The standard best practice among infrastructure engineers is to enforce perimeter filtering first and use application rules as a fallback. If you have a static IP or connect through an administrative VPN, remove ports 2086 and 2087 from your global incoming port list in your firewall configuration (such as TCP_IN in CSF). Instead, add explicit allow rules that bind those destination ports specifically to your trusted IP ranges. If your infrastructure lives behind a cloud provider security group or upstream hardware appliance, enforce this restriction at that outer perimeter. Host Access Control can remain configured as a secondary safeguard. If an administrative firewall rule is ever mistakenly widened during routine maintenance or server migration, Host Access Control acts as a secondary gate, stopping unknown IPs from immediately reaching login prompts. But it should never be your front line.