cPanel WHM CGI DDoS Fix - defaultwebpage.cgi Security Patch

Attack Vector: defaultwebpage.cgi DDoS flood attacks

Attackers who discover your backend server IP can bypass Cloudflare protection and directly flood your cPanel's CGI scripts with HTTP requests. This attack:

• Bypasses Cloudflare Protection - Direct IP attacks don't route through CDN
• Requires No Special Tools - Simple HTTP flood, no complex bypass needed
• Causes Immediate Impact - Server load spikes rapidly, causing downtime
• Exploits Default Configuration - cPanel's defaultwebpage.cgi is accessible by default
• Works Against All cPanel Servers - Apache, LiteSpeed, and other web servers

⚠️ Why This Attack is Devastating

CloudLinux CPU Isolation Bypass:

On shared hosting servers running CloudLinux, each website is isolated with LVE (Lightweight Virtual Environment) limits. When a single site gets attacked, only that site's CPU/memory allocation is affected - other sites continue running normally.

However, defaultwebpage.cgi attacks bypass this protection entirely:

Normal Attack on User Site:
[Attacker] → example.com → LVE Container (user123)
                          ↓
                    Isolated CPU: 50%
                    Other sites: Unaffected ✅

defaultwebpage.cgi Attack:
[Attacker] → http://SERVER_IP/cgi-sys/defaultwebpage.cgi
                          ↓
                    Dedicated CPU: 100% 🔥
                    All sites affected ❌
                    Server crashes ❌

The Critical Difference:

• User site attack: CloudLinux LVE limits contain the damage
• defaultwebpage.cgi attack: Runs under Apache/root context, bypasses ALL CloudLinux isolation
• Result: Entire server becomes unusable, affecting all customers

This is why defaultwebpage.cgi floods are extremely dangerous on shared hosting environments - they defeat the entire purpose of CloudLinux resource isolation.

• Bypasses Cloudflare Protection - Direct IP attacks don't route through CDN
• Requires No Special Tools - Simple HTTP flood, no complex bypass needed
• Causes Immediate Impact - Server load spikes rapidly, causing downtime
• Exploits Default Configuration - cPanel's defaultwebpage.cgi is accessible by default
• Works Against All cPanel Servers - Apache, LiteSpeed, and other web servers

Real-World Attack Example

# Attacker discovers backend IP through DNS history, SSL certificates, or misconfiguration
# Then launches simple HTTP flood:

http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
# ... repeated thousands of times per second

# Result: Server load increases dramatically, legitimate traffic cannot be served

Why This Works:

• CGI scripts consume significant server resources per request
• Default cPanel configuration allows public access to these scripts
• Direct IP access bypasses all CDN/WAF protection layers
• No authentication or rate limiting on default CGI files

This guide provides the essential fix to close this vulnerability on both Apache and LiteSpeed web servers.

Table of Contents

• Critical Vulnerability Overview
• How Attackers Find Backend IPs
• Layer 7 DDoS Attack Methodology
• CGI Security Fixes
  • Apache Configuration
  • LiteSpeed Configuration
• Apache Configuration Files
• cPanel Access Protection
• Default VirtualHost Security
• Implementation Steps
• Testing & Verification
• Prevention Best Practices

---

How Attackers Find Backend IPs

Even with Cloudflare or similar CDN protection, attackers can discover your real server IP through:

1. DNS History & Subdomains

# Historical DNS records before Cloudflare was enabled
# Services like SecurityTrails, DNSDumpster reveal old A records

# Example:
mail.example.com → 203.0.113.50 (Real IP exposed)
ftp.example.com → 203.0.113.50 (Same server)
cpanel.example.com → 203.0.113.50 (Direct access)

2. cPanel/Webmail Redirect Exposure

# When users access cPanel or webmail through main domain:
https://example.com/cpanel
https://example.com/webmail
https://example.com:2083

# These requests often redirect and expose backend IP in:
# - Location headers
# - SSL certificate details during handshake
# - Referrer information
# - DNS lookups during redirect

# Example redirect chain:
example.com/cpanel → cpanel.example.com:2083 → 203.0.113.50:2083
# Real IP exposed in redirect process

3. SSL Certificate Scanning

# Services like Censys.io scan entire IPv4 range for SSL certificates
# If your SSL cert contains your domain, your IP is exposed

# Search: "example.com" on Censys.io
# Result: Server IP with your SSL certificate

4. Email Headers

# Emails sent from your server contain Received headers with real IP
Received: from mail.example.com (203.0.113.50)

5. MX Record Reconnaissance

# MX records often point to same server as web hosting
dig example.com MX +short
# Returns: mail.example.com

dig mail.example.com +short
# Returns: 203.0.113.50 (Real IP exposed)

6. Server-Status & Info Pages

# Misconfigured Apache status pages
http://YOUR_IP/server-status
http://YOUR_IP/server-info

7. Direct Port Scanning

# Open ports reveal server identity
nmap -sV YOUR_IP
# cPanel ports: 2082, 2083, 2086, 2087

---

Layer 7 DDoS Attack Methodology

Attack Flow

[Attacker] → [Discovers Real IP] → [Bypasses Cloudflare] → [Direct HTTP Flood]
                                                                     ↓
                                                        [CGI Script Processing]
                                                                     ↓
                                                    [Bypasses CloudLinux LVE Isolation]
                                                                     ↓
                                                        [Server-Wide CPU Overload]
                                                                     ↓
                                                        [All Sites Down - Complete Outage]

CloudLinux LVE Isolation Bypass - The Real Problem

What is CloudLinux LVE?

CloudLinux's Lightweight Virtual Environment (LVE) isolates each cPanel user account into separate resource containers:

Shared Hosting Server with CloudLinux:
┌─────────────────────────────────────┐
│  Server: 8 CPU cores, 32GB RAM     │
├─────────────────────────────────────┤
│  user1: 1 CPU, 2GB RAM (LVE)       │ ← Site 1
│  user2: 1 CPU, 2GB RAM (LVE)       │ ← Site 2
│  user3: 1 CPU, 2GB RAM (LVE)       │ ← Site 3
│  System: 5 CPU, 26GB RAM           │ ← Dedicated resources
└─────────────────────────────────────┘

Normal DDoS Attack - Contained:

# Attack on user1's website
http://site1.com/page.php

# LVE Container Limits:
CPU Usage (user1): 100% ← Maxed out
CPU Usage (user2): 5%   ← Normal
CPU Usage (user3): 3%   ← Normal
Server Load: 1.2        ← Stable

Result: Only site1.com affected, other sites continue normally

defaultwebpage.cgi Attack - Server-Wide Destruction:

# Attack on server's default CGI
http://SERVER_IP/cgi-sys/defaultwebpage.cgi

# System Resources (NO LVE ISOLATION):
CPU Usage (dedicated): 100% ← FULL SATURATION
CPU Usage (user1): Can't allocate
CPU Usage (user2): Can't allocate
CPU Usage (user3): Can't allocate
Server Load: 350+       ← CRITICAL OVERLOAD

Result: ALL websites down, SSH unresponsive, cPanel inaccessible

Why defaultwebpage.cgi Bypasses LVE

Technical Explanation:

1. System Context Execution:

   • defaultwebpage.cgi runs under Apache's main process
   • NOT assigned to any specific user's LVE container
   • Uses dedicated system CPU resources

2. Resource Allocation:

   • User sites: Isolated in LVE containers (limited CPU/RAM)
   • System CGI: Runs in privileged context with full server access
   • CloudLinux cannot limit system-level processes

3. Attack Impact:

   Regular site attack:
   /home/user1/public_html/index.php → LVE Container (user1) ✅
   
   CGI attack:
   /usr/local/cpanel/cgi-sys/defaultwebpage.cgi → System Context ❌
   

Real-World Attack Scenario

Before Attack - Healthy Server:

$ cat /proc/loadavg
0.85 0.92 0.88 2/450 12456

$ lvectl list
user1    50    512M    1024M    20    40    100
user2    35    256M    1024M    15    30    100
user3    28    128M    512M     10    25    100

# All users within LVE limits, server stable

During defaultwebpage.cgi Attack:

$ cat /proc/loadavg
347.92 298.45 156.23 450/450 32891  # CRITICAL

$ lvectl list
# Command hangs - system unresponsive

$ top
Tasks: 450 total, 450 running
%Cpu(s): 100.0 us, 0.0 sy, 0.0 ni, 0.0 id
KiB Mem: 32GB total, 31GB used
Load average: 350.12, 298.45, 156.23

PID    USER   %CPU  COMMAND
12456  nobody 98.2  /usr/local/cpanel/cgi-sys/defaultwebpage.cgi
12457  nobody 98.1  /usr/local/cpanel/cgi-sys/defaultwebpage.cgi
12458  nobody 97.9  /usr/local/cpanel/cgi-sys/defaultwebpage.cgi
# ... hundreds of CGI processes consuming all CPU

Impact on Shared Hosting:

Website 1 (user1): HTTP 503 - Service Unavailable
Website 2 (user2): HTTP 503 - Service Unavailable  
Website 3 (user3): HTTP 503 - Service Unavailable
cPanel Login: Timeout
WHM Access: Connection refused
SSH: Connection timeout
FTP: Connection refused

ALL services down due to CPU exhaustion

Why CGI Flood is Devastating

Normal Request:

GET /index.html HTTP/1.1
# Server: Serves static file (low resource usage)
# Response time: ~1-5ms

CGI Flood Request:

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1
# Server: Executes Perl/Python script
# Database queries, file system access
# Response time: ~50-200ms
# CPU usage: 10-50x higher than static files

Attack Amplification

# Single attacker with 1Gbps connection can send:
# ~100,000 requests per second to defaultwebpage.cgi

# Each request consumes:
# - CPU cycles for CGI execution
# - Memory for process spawning
# - File system I/O operations
# - Database connections (if used)

# Result with 100k req/sec:
# - Server load: 200-500+ (normal is <1.0)
# - Memory exhaustion
# - MaxClients/MaxRequestWorkers limit reached
# - Legitimate traffic cannot be served

Real Attack Logs Example

203.0.113.100 - - [09/Nov/2025:10:15:23] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 200
203.0.113.100 - - [09/Nov/2025:10:15:23] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 200
203.0.113.100 - - [09/Nov/2025:10:15:23] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 200
203.0.113.100 - - [09/Nov/2025:10:15:23] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 200
# ... repeated 100,000+ times per second

# Server response:
# Load average: 350.45 (critical overload)
# Apache: MaxClients reached, no free slots available
# SSH: Connection timeout
# Websites: Unable to establish database connection

Why Cloudflare Cannot Help

❌ Scenario: Direct IP Attack

[Attacker] → http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
             ↓
[Your Server Directly] ← Cloudflare never sees this traffic
             ↓
[Server Overload & Crash]

✅ Scenario: Domain-Based Traffic (Protected)

[Attacker] → http://example.com/cgi-sys/defaultwebpage.cgi
             ↓
[Cloudflare] → Filters, caches, rate limits
             ↓
[Your Server] ← Clean traffic only

The Fix: Block CGI access entirely, since it serves no legitimate purpose for production sites.

---

Testing & Verification

Verify the Fix is Working

After applying the configuration through WHM, test if defaultwebpage.cgi is blocked:

# Test from command line (should return 403)
curl -I http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi

# Expected output:
HTTP/1.1 403 Forbidden
Date: Sat, 09 Nov 2025 12:00:00 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1

Test Different Access Methods

# Test direct IP access
curl -I http://203.0.113.50/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

# Test via domain (should also be blocked)
curl -I http://example.com/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

# Test HTTPS
curl -I https://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

Check Server Status

# View current server load
uptime

# Expected after fix:
# load average: 0.85, 0.92, 0.88 (normal levels)

# Check Apache/LiteSpeed is running
systemctl status httpd

# For LiteSpeed:
/usr/local/lsws/bin/lswsctrl status

Monitor Access Logs

# Watch for blocked CGI requests in real-time
tail -f /usr/local/apache/logs/error_log | grep "defaultwebpage.cgi"

# Check how many attacks were blocked
grep "defaultwebpage.cgi" /usr/local/apache/logs/error_log | grep "403" | wc -l

Before and After Comparison

Before Fix:

$ curl -I http://203.0.113.50/cgi-sys/defaultwebpage.cgi
HTTP/1.1 200 OK
Content-Type: text/html
Server: Apache

# Attack succeeds, CGI executes, server load increases

After Fix:

$ curl -I http://203.0.113.50/cgi-sys/defaultwebpage.cgi
HTTP/1.1 403 Forbidden
Content-Type: text/html
Server: Apache

# Attack fails immediately, CGI never executes, server protected

Impact Metrics

Metric	Before Fix	After Fix
CGI Requests Processed	100,000/sec	0/sec
Server Load	350+	<1.0
CPU Usage	95-100%	5-15%
Response Time	Timeout	Normal
CloudLinux LVE Bypass	Yes	Not Applicable
Affected Websites	ALL sites	None
Customer Impact	100% outage	Normal operation

---

Implementation Steps

⚡ Single Fix Method - WHM Include Editor

This method works for both Apache and LiteSpeed web servers. You only need to apply this once through WHM GUI.

Step 1: Access WHM Include Editor

1. Login to WHM (Web Host Manager)
2. Navigate to Service Configuration → Apache Configuration
3. Click on Include Editor
4. Select Pre Main Include
5. Select All Versions (applies to all Apache/LiteSpeed versions)

Step 2: Add Security Configuration

In the text editor, add the following configuration:

# Block defaultwebpage.cgi - Prevents CGI DDoS attacks
<Files "defaultwebpage.cgi">
    Require all denied
</Files>

# Block cPanel access from direct IP
<Location /cpanel>
    Require all denied
</Location>

Step 3: Save and Rebuild

1. Click Update button
2. WHM will automatically rebuild Apache/LiteSpeed configuration
3. Restart web server:

# For Apache:
systemctl restart httpd

# For LiteSpeed:
/usr/local/lsws/bin/lswsctrl restart

Step 4: Verify Fix

Test if the fix is working:

# Test CGI block (should return 403 Forbidden)
curl -I http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi

# Expected output:
HTTP/1.1 403 Forbidden

---

Configuration Files Location

The configuration you added through WHM is stored in:

/etc/apache2/conf.d/includes/pre_main_global.conf

Or for some systems:

/usr/local/apache/conf/includes/pre_main_global.conf

Note: Never edit these files directly. Always use WHM Include Editor to ensure configurations persist after Apache rebuilds.

---

How This Fix Works

Direct 403 Response:

When an attacker tries to access defaultwebpage.cgi:

Request:  GET /cgi-sys/defaultwebpage.cgi
          ↓
Apache/LiteSpeed checks: <Files "defaultwebpage.cgi">
          ↓
Response: HTTP 403 Forbidden (immediately)
          ↓
NO CGI execution, NO CPU usage, NO server load

Benefits:

• ✅ Blocks CGI flood attacks instantly
• ✅ Returns 403 before CGI execution
• ✅ Zero CPU consumption from blocked requests
• ✅ Works on both Apache and LiteSpeed
• ✅ Survives cPanel/WHM updates and rebuilds
• ✅ Single configuration point through WHM GUI

---

Testing & Verification

Verify the Fix is Working

After applying the configuration through WHM, test if defaultwebpage.cgi is blocked:

# Test from command line (should return 403)
curl -I http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi

# Expected output:
HTTP/1.1 403 Forbidden
Date: Sat, 09 Nov 2025 12:00:00 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1

Test Different Access Methods

# Test direct IP access
curl -I http://203.0.113.50/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

# Test via domain (should also be blocked)
curl -I http://example.com/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

# Test HTTPS
curl -I https://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

Check Server Status

# View current server load
uptime

# Expected after fix:
# load average: 0.85, 0.92, 0.88 (normal levels)

# Check Apache/LiteSpeed is running
systemctl status httpd

# For LiteSpeed:
/usr/local/lsws/bin/lswsctrl status

Monitor Access Logs

# Watch for blocked CGI requests in real-time
tail -f /usr/local/apache/logs/error_log | grep "defaultwebpage.cgi"

# Check how many attacks were blocked
grep "defaultwebpage.cgi" /usr/local/apache/logs/error_log | grep "403" | wc -l

Before and After Comparison

Before Fix:

$ curl -I http://203.0.113.50/cgi-sys/defaultwebpage.cgi
HTTP/1.1 200 OK
Content-Type: text/html
Server: Apache

# Attack succeeds, CGI executes, server load increases

After Fix:

$ curl -I http://203.0.113.50/cgi-sys/defaultwebpage.cgi
HTTP/1.1 403 Forbidden
Content-Type: text/html
Server: Apache

# Attack fails immediately, CGI never executes, server protected

Impact Metrics

Metric	Before Fix	After Fix
CGI Requests Processed	100,000/sec	0/sec
Server Load	350+	<1.0
CPU Usage	95-100%	5-15%
Response Time	Timeout	Normal
CloudLinux LVE Bypass	Yes	Not Applicable
Affected Websites	ALL sites	None
Customer Impact	100% outage	Normal operation

---

Emergency DDoS Response

---

Advanced Configuration

IP Whitelist for cPanel

If you need to allow specific IPs to access cPanel:

<Location /cpanel>
    Require ip 203.0.113.0/24
    Require ip 198.51.100.50
    Require ip 192.0.2.100
</Location>

Rate Limiting with mod_evasive

Install and configure mod_evasive for additional DDoS protection:

# Install mod_evasive
yum install mod_evasive

# Configure in /etc/httpd/conf.d/mod_evasive.conf

<IfModule mod_evasive24.c>
    DOSHashTableSize 3097
    DOSPageCount 10
    DOSSiteCount 100
    DOSPageInterval 1
    DOSSiteInterval 1
    DOSBlockingPeriod 10
    DOSEmailNotify admin@yourdomain.com
    DOSLogDir /var/log/mod_evasive
</IfModule>

Custom Error Pages

Create custom error pages for denied requests:

<VirtualHost _default_:80>
    DocumentRoot /var/www/html
    ServerName default
    
    ErrorDocument 403 /custom-403.html
    
    <Location />
        Require all denied
    </Location>
</VirtualHost>

---

Troubleshooting

Issue: Legitimate Sites Not Accessible

Solution: Ensure your actual domain VirtualHosts are properly configured and come after the default VirtualHost in load order.

# Check VirtualHost order
httpd -S

# Verify domain VirtualHost configuration
grep -r "ServerName yourdomain.com" /etc/apache2/conf.d/

Issue: Configuration Not Taking Effect

Solution: Always rebuild and restart Apache after changes.

/scripts/rebuildhttpdconf
systemctl restart httpd

Issue: 500 Internal Server Error

Solution: Check Apache error logs and verify syntax.

tail -100 /var/log/apache2/error_log
apachectl configtest

---

Security Best Practices

1. Regular Updates: Keep cPanel and Apache updated

   /scripts/upcp
   yum update httpd mod_ssl
   

2. Log Monitoring: Regularly review logs for attack patterns

   grep "403\|404\|500" /var/log/apache2/*-access.log | less
   

3. Firewall Rules: Complement Apache rules with firewall configurations

   # Block suspicious IPs at firewall level
   csf -d SUSPICIOUS_IP "DDoS attempt"
   

4. SSL/TLS Configuration: Always use strong SSL/TLS settings

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite HIGH:!aNULL:!MD5
   

5. Regular Audits: Perform security audits regularly

   # Check for suspicious processes
   ps aux | grep httpd
   
   # Review open ports
   netstat -tulpn | grep :80\|:443
   

---

Maintenance Commands

# Reload Apache without downtime
systemctl reload httpd

# Check Apache processes
ps aux | grep httpd | wc -l

# View Apache resource usage
top -b -n 1 | grep httpd

# Clear Apache logs (if needed)
> /var/log/apache2/access_log
> /var/log/apache2/error_log

# Test configuration before applying
apachectl configtest && systemctl restart httpd

---

Emergency DDoS Response

If you're currently under CGI-based DDoS attack:

Immediate Actions:

# 1. Apply CGI fix
echo '<Files "defaultwebpage.cgi">' >> /etc/apache2/conf.d/includes/pre_main_global.conf
echo '    Require all denied' >> /etc/apache2/conf.d/includes/pre_main_global.conf
echo '</Files>' >> /etc/apache2/conf.d/includes/pre_main_global.conf

# 2. Restart web server
systemctl restart httpd

# 3. Check if attack stopped
curl -I http://YOUR_SERVER_IP/cgi-sys/defaultwebpage.cgi
# Expected: 403 Forbidden

Contact Hosting Provider:

If your hosting provider's servers don't have this fix applied, share this article with them. Server administrators must implement this configuration at the server level.

---

Conclusion

Critical cPanel WHM CGI DDoS Fix

The defaultwebpage.cgi vulnerability is a critical Layer 7 DDoS vector that affects all cPanel servers. This attack bypasses CloudLinux LVE isolation, making it especially devastating for shared hosting environments.

Why This Fix is Essential:

• Bypasses Cloudflare - Direct IP attacks circumvent CDN protection
• Bypasses CloudLinux LVE - Runs in system context, not user containers
• Affects ALL websites - Takes down entire server, not just one site
• Simple to execute - Basic HTTP flood, no sophisticated tools needed
• Works on Apache and LiteSpeed - Universal cPanel vulnerability

The CloudLinux Problem:

Shared hosting providers rely on CloudLinux LVE to isolate customer resources. When one site is attacked, only that site goes down. However, defaultwebpage.cgi attacks run in system context and bypass ALL LVE isolation, causing server-wide outages affecting hundreds of customers simultaneously.

Implementation:

<Files "defaultwebpage.cgi">
    Require all denied
</Files>

For Hosting Providers:

If your hosting provider's servers are vulnerable to defaultwebpage.cgi attacks, share this article with them. This is a server-level configuration that requires administrative access - customers cannot fix this themselves.

For Shared Hosting Customers:

If your site goes down along with hundreds of other sites on the same server during attacks, your hosting provider likely hasn't applied this fix. Share this article with their support team.

Key Points

✅ Server administrators must apply this fix
✅ Works on cPanel Apache and LiteSpeed servers
✅ Prevents CGI-based DDoS attacks
✅ Protects CloudLinux LVE isolation integrity
✅ Essential for shared hosting environments

When Under Attack

1. Apply CGI fix immediately
2. Block attacker IPs in firewall
3. Restart web server
4. Monitor server load recovery