DDoS protection for cPanel
and WHM servers: beyond CSF

Back to Blog

The CSF Myth: Why It Cannot Protect You From DDoS

ConfigServer Security & Firewall is installed on nearly every cPanel server in production. It is a solid host-based firewall that wraps iptables with a WHM interface, adds login failure detection, and provides connection tracking. But CSF was never designed to be a DDoS mitigation tool. Understanding this distinction is critical.

CSF operates as a local firewall. It processes packets after they have already arrived at your server's network interface. When a volumetric DDoS attack sends 5 Gbps of UDP amplification traffic to your server, CSF can drop those packets at the iptables level, but the traffic has already consumed your network port capacity. Your server's 1 Gbps uplink is saturated before CSF even evaluates a single packet. The pipe is full. Dropping packets on the host does nothing when the packets already filled the pipe getting there.

The SYNFLOOD option in CSF enables net.ipv4.tcp_syncookies and adds some basic SYN rate limiting. This helps with small-scale SYN floods from a handful of IPs, but a distributed SYN flood from 50,000 sources at 2 million packets per second will overwhelm the kernel's packet processing capacity long before CSF's rules take effect. The server becomes unresponsive not because of missing firewall rules, but because the CPU is saturated processing interrupt requests from the NIC.

CSF's connection tracking (CT_LIMIT) limits simultaneous connections per IP. This is useful for slow HTTP attacks, but sophisticated attackers rotate source IPs constantly. With a botnet of 10,000 nodes each holding 5 connections, you have 50,000 active connections from 10,000 unique IPs, all under the per-IP limit. CSF sees nothing unusual.

cPanel's Unique Attack Surface

A standard cPanel server exposes significantly more attack surface than a minimal Linux web server. Every additional listening port is another target for volumetric or application-layer attacks.

Port 2087: WHM Administrative Interface

WHM listens on port 2087 over HTTPS by default and is accessible from any IP unless you have restricted it. The WHM login page renders a full HTML interface with CSS, JavaScript, and image assets. An attacker does not need valid credentials to force the server to render this page thousands of times per second. Each request consumes CPU on the cPanel process that handles WHM, and because WHM runs as root-level processes through cpsrvd, excessive load here affects the entire server.

Port 2083: cPanel User Interface

The cPanel user login on port 2083 has the same problem. It is publicly accessible and renders a full interface on every request. Brute force protection (cPHulk) handles login attempts, but a flood of requests to the login page itself is an application-layer attack that cPHulk does not address.

Webmail on Port 2096

Webmail interfaces (Roundcube, Horde) are resource-heavy applications. A flood of requests to port 2096 forces the server to initialize PHP sessions, connect to IMAP, and render complex UIs. Even 200 concurrent requests can bring webmail to its knees on a busy shared hosting server.

cPanel API Endpoints

The UAPI and WHM API endpoints are accessible over ports 2083 and 2087 respectively. Authenticated API calls consume significantly more resources than static page loads because they execute backend operations. If an attacker compromises even one cPanel account's credentials, they can hammer API endpoints to cause denial of service for the entire server.

Other Exposed Services

• Port 53 (DNS): cPanel servers running BIND or PowerDNS are targets for DNS amplification and query floods
• Port 25/465/587 (Mail): Exim on cPanel servers processes every SMTP connection, making mail ports a target for connection exhaustion
• Port 21 (FTP): Pure-FTPD or ProFTPD connection floods
• Ports 80/443 (Web): Standard HTTP floods targeting hosted websites, WordPress xmlrpc.php, wp-login.php

Why mod_evasive Falls Short

Many cPanel hardening guides recommend installing mod_evasive for Apache as a DDoS countermeasure. mod_evasive tracks request rates per IP and returns 403 responses when thresholds are exceeded. The problems with this approach are fundamental.

First, mod_evasive only protects Apache. It does nothing for attacks targeting cPanel ports, mail, DNS, or FTP. Second, it operates at the application layer inside Apache, meaning every request still goes through Apache's connection handling, SSL negotiation (for HTTPS), and worker thread allocation before mod_evasive decides to block it. The damage is done by the time mod_evasive acts. Third, returning a 403 response to every blocked request still consumes outbound bandwidth and worker threads. Under a flood, you want to drop packets silently, not respond to them.

# Typical mod_evasive config that people think is "DDoS protection"
<IfModule mod_evasive24.c>
    DOSHashTableSize    3097
    DOSPageCount        5
    DOSSiteCount        100
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   60
</IfModule>

# This will block aggressive scrapers.
# It will NOT stop a real DDoS attack.

Practical Hardening: Reduce the Attack Surface

Before adding detection tools, reduce what attackers can target. These steps are specific to cPanel/WHM environments and should be applied to every production server.

Restrict WHM and cPanel Ports

There is rarely a reason for WHM (port 2087) to be accessible from every IP on the internet. Restrict it to your management IPs. In CSF, use the csf.allow file combined with port-specific rules:

# /etc/csf/csf.allow
# Only allow WHM access from your office/VPN
tcp|in|d=2087|s=198.51.100.0/24

# In csf.conf, remove 2087 from TCP_IN to block public access
# Change:
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2083,2087,2096"
# To:
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2083,2096"

# Then restart CSF
csf -r

With WHM removed from TCP_IN, only IPs listed in csf.allow with the port-specific rule can reach port 2087. This eliminates WHM as a public attack surface entirely.

Rate Limit cPanel Login and Webmail

cPHulk handles brute force detection for login attempts, but you should also rate limit connections to cPanel service ports at the firewall level. Add these to /etc/csf/csfpre.sh so they load before CSF's rules:

#!/bin/bash
# /etc/csf/csfpre.sh

# Rate limit new connections to cPanel login (port 2083)
iptables -A INPUT -p tcp --dport 2083 --syn -m connlimit --connlimit-above 10 --connlimit-mask 32 -j DROP

# Rate limit webmail connections (port 2096)
iptables -A INPUT -p tcp --dport 2096 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP

# Limit DNS query rate to prevent amplification abuse
iptables -A INPUT -p udp --dport 53 -m limit --limit 50/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP

Harden Exim Against Connection Floods

Exim on cPanel accepts connections on ports 25, 465, and 587. A connection flood against these ports creates thousands of Exim child processes. Add connection limits directly in Exim's configuration through WHM:

Navigate to WHM > Exim Configuration Manager > Advanced Editor and set:

smtp_accept_max = 100
smtp_accept_max_per_host = 10
smtp_accept_reserve = 10
smtp_connect_backlog = 20

These values prevent any single host from opening more than 10 simultaneous SMTP connections and cap total connections at 100. Adjust upward for high-volume mail servers, but the defaults protect against connection exhaustion.

Disable Unnecessary Services

# If you don't use FTP (use SFTP via SSH instead)
systemctl stop pure-ftpd && systemctl disable pure-ftpd
# Remove port 21 from CSF TCP_IN

# If you don't host DNS on this server
systemctl stop named && systemctl disable named
# Remove port 53 from CSF TCP_IN and UDP_IN

# Disable cPanel analytics/stats generators that consume CPU
whmapi1 set_tweaksetting key=skipanalog value=1
whmapi1 set_tweaksetting key=skipwebalizer value=1

Kernel-Level Hardening for cPanel Servers

cPanel's default kernel parameters are tuned for shared hosting workloads, not for attack resilience. Apply these sysctl settings to improve the server's ability to handle connection floods:

# /etc/sysctl.d/99-ddos-hardening.conf

# Enable SYN cookies (CSF may already set this)
net.ipv4.tcp_syncookies = 1

# Reduce SYN-ACK retries (default is 5, which holds half-open connections for ~180s)
net.ipv4.tcp_synack_retries = 2

# Increase SYN backlog
net.ipv4.tcp_max_syn_backlog = 65536

# Increase connection tracking table size (critical for cPanel with many accounts)
net.netfilter.nf_conntrack_max = 524288

# Reduce conntrack timeout for established connections
net.netfilter.nf_conntrack_tcp_timeout_established = 600

# Ignore ICMP broadcasts (prevent smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Enable reverse path filtering
net.ipv4.conf.all.rp_filter = 1

# Apply changes
# sysctl -p /etc/sysctl.d/99-ddos-hardening.conf

On cPanel servers with 200+ accounts, the default nf_conntrack_max of 65536 fills up during normal operations. If conntrack overflows, the kernel drops all new connections. This looks like a DDoS to your customers even when there is no attack happening. Increase it preemptively.

What Actually Stops DDoS Attacks on cPanel Servers

All the hardening above improves resilience, but it does not stop a real DDoS attack. A 10 Gbps UDP flood will still saturate your network port. A 500,000 PPS SYN flood will still overwhelm kernel processing. A sophisticated HTTP flood from 20,000 residential IPs will still exhaust Apache workers. You need two things that CSF cannot provide: upstream detection and automated mitigation.

Upstream Detection

Detection must happen by analyzing traffic patterns in real time, ideally at per-second granularity. You need to know that an attack is happening within seconds, not minutes. CSF's connection tracking updates every CT_INTERVAL seconds (default: 30), which means a flood can run for 30 seconds before CSF even checks. In 30 seconds, a 5 Gbps attack has delivered 18.75 GB of traffic to your saturated port.

Automated Mitigation Signaling

Once an attack is detected, mitigation needs to happen upstream of your server. This means signaling your hosting provider or upstream network to null-route attack traffic, activate a scrubbing center, or apply BGP-based filtering before traffic reaches your port. No software running on the cPanel server itself can do this because by the time traffic reaches the server, the damage is done.

Deploying Detection Alongside cPanel

A detection agent on a cPanel server needs to coexist with CSF, cPHulk, and all the other security layers without conflicts. Here is what a proper deployment looks like:

# Install the Flowtriq agent (runs as a systemd service)
pip install ftagent
ftagent init --server-id your-server-id --api-key your-key

# Verify it's running alongside CSF without conflicts
systemctl status ftagent
csf -r  # Restart CSF to confirm no rule conflicts

# Check that the agent is capturing traffic data
ftagent status

The agent captures packet metadata from the network interface, not from iptables. This means it sees all traffic regardless of CSF rules, including traffic that CSF allows, traffic that CSF drops, and traffic patterns that CSF does not track at all (like UDP amplification). It operates independently of CSF's rule chain, so there are no conflicts and no performance impact on firewall processing.

What the Agent Monitors That CSF Cannot

• Per-second packet rates by protocol: CSF checks connections at intervals; the agent tracks PPS continuously
• Bandwidth consumption trends: CSF has no concept of bandwidth; the agent tracks Mbps in real time
• UDP traffic patterns: CSF only tracks TCP connections via conntrack; UDP is stateless and invisible to CT_LIMIT
• Attack signature detection: Known amplification vectors (DNS, NTP, CLDAP, memcached) identified by packet characteristics
• Baseline deviation: The agent learns your server's normal traffic patterns and alerts on deviations, not just threshold breaches

A Complete cPanel DDoS Protection Checklist

Here is the full stack of what a properly protected cPanel server looks like, from outermost to innermost layer:

1. Upstream mitigation capability: Your hosting provider or a dedicated scrubbing service that can absorb volumetric attacks before they reach your port
2. Real-time detection agent: Per-second traffic monitoring with automated mitigation signaling to upstream providers
3. CSF with hardened configuration: Restricted management ports, SYNFLOOD enabled, CT_LIMIT configured, PORTFLOOD rules for key services
4. Kernel hardening: SYN cookies, increased conntrack limits, reduced timeouts, reverse path filtering
5. Service-level limits: Apache MaxRequestWorkers, Exim connection limits, PHP-FPM pool limits per cPanel account
6. Application-level protection: cPHulk for brute force, mod_security for WAF rules, rate limiting in .htaccess for specific endpoints
7. Attack surface reduction: Disabled unnecessary services, restricted management port access, removed unused software

Each layer handles a different class of threat. CSF handles host-based firewall rules and connection tracking. The detection agent handles volumetric and protocol-level attack detection. Upstream mitigation handles the actual absorption or diversion of attack traffic. No single layer is sufficient on its own.

If your current DDoS strategy for cPanel is "enable SYNFLOOD in CSF and install mod_evasive," you have a firewall and an application-layer rate limiter. You do not have DDoS detection. You do not have DDoS mitigation. The next time a real attack hits, CSF will log the traffic it drops while your server remains unreachable because the network pipe is full. The difference between that outcome and actually staying online is the detection and mitigation layers that most cPanel guides never mention.

Back to Blog

Related Articles