What to Do When Your VPS Is Under DDoS: Emergency Triage, Mitigation & Edge Shielding

What to Do When Your VPS Is Under DDoS: Emergency Triage, Mitigation & Edge Shielding

Executive Summary: Anatomy of a VPS DDoS Emergency

Nothing causes more panic for an IT administrator or business owner than a sudden Distributed Denial of Service (DDoS) attack. Within seconds:

• CPU & Load Average Explosion: Server load averages surge from 0.8 to 85.0+, freezing SSH terminals and rendering console commands unresponsive.
• Bandwidth Interface Saturation: Upstream gigabit network ports fill to 100% capacity, dropping legitimate incoming packets.
• Web Server Stalls: Nginx and Apache process tables saturate, spewing 502 Bad Gateway, 504 Gateway Timeout, and Error 521 / 522 errors to real customers.
• Hosting Provider Threat of Null-Routing: If the attack exceeds provider volumetric thresholds, cloud providers (Hetzner, OVH, DigitalOcean, Linode) will automatically blackhole ("null-route") your server's IP address, completely severing your infrastructure from the global internet for 24 hours.

When your Linux VPS is under active attack, you cannot afford to waste time searching online forums. You need an immediate, deterministic incident triage protocol.

This emergency manual provides a step-by-step sysadmin guide: from rapid terminal diagnosis and kernel SYN cookie enforcement to local iptables rate-limiting, Nginx query drops, and emergency Cloudflare edge shielding.

================================================================================
          ACTIVE DDOS EMERGENCY INCIDENT RESPONSE PROTOCOL
================================================================================

                           [ Active DDoS Flood Detected ]
                                         |
                                         v
   +---------------------------------------------------------------------------+
   | Phase 1: Rapid Command-Line Triage (Identify Attack Layer & Origin IPs)   |
   | - Distinguish Layer 4 (SYN/UDP Flood) vs Layer 7 (HTTP POST/GET Flood)    |
   | - Commands: ss -ant, netstat -ntu, awk frequency sorting                  |
   +---------------------------------------------------------------------------+
                                         |
              +--------------------------+--------------------------+
              | (Layer 4 Volumetric Flood)                          | (Layer 7 HTTP Flood)
              v                                                     v
   +---------------------------------------+   +---------------------------------------+
   | Kernel-Level Mitigation               |   | Web Server & Nginx Mitigation         |
   | - Enable TCP SYN Cookies (sysctl)     |   | - Return 444 (No Response) on query  |
   | - Drop rogue subnets via iptables     |   | - Enforce Nginx limit_req memory zones|
   | - Blackhole high-frequency attackers  |   | - Block unauthenticated POST payloads |
   +---------------------------------------+   +---------------------------------------+
                                         |                          |
                                         +------------+-------------+
                                                      |
                                                      v
   +---------------------------------------------------------------------------+
   | Phase 3: Immediate Edge Shielding (Shift Load off VPS to Anycast Edge)    |
   | - Route DNS through Cloudflare Anycast Proxy ("Orange Cloud")             |
   | - Activate Cloudflare "Under Attack Mode" (Cryptographic Proof-of-Work)   |
   | - Cloak Origin IP: Lock UFW/Firewalld to accept ONLY Cloudflare IP ranges |
   +---------------------------------------------------------------------------+

1. Phase 1: Rapid Command-Line Incident Triage

Before applying defensive rules, you must identify whether the attack is Layer 4 (Transport layer: SYN floods, UDP amplification) or Layer 7 (Application layer: HTTP floods, search crawler abuse).

Step 1.1: Identify Active TCP Connection States

Run this one-liner to tally connections by state across your network stack:

ss -ant | awk '{print $1}' | sort | uniq -c | sort -n

Interpreting the Output:

• High SYN-RECV (> 500): You are under an active SYN Flood (Layer 4 attack). Attackers are sending forged TCP handshakes to exhaust your connection table without completing the three-way handshake.
• High ESTAB (> 1,000): You are facing a Layer 7 HTTP Flood or Slowloris attack. Attackers have established legitimate connections and are bombarding Nginx with HTTP requests.
• High TIME-WAIT (> 5,000): Your server has closed thousands of short-lived connections, consuming ephemeral ports.

Step 1.2: Identify the Top Offending IP Addresses

Run this pipeline to extract the top 20 remote IP addresses consuming socket connections:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 20

Or using modern ss:

ss -tn state established '( sport = :80 or sport = :443 )' | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 20

Triage Insight: If a handful of individual IPs account for hundreds of connections each, you are dealing with an unsophisticated botnet or scraper that can be dropped instantly via local firewall rules. If thousands of distinct IPs each have only 1-2 connections, you are facing a distributed Layer 7 botnet requiring edge proxy shielding.

2. Phase 2: Mitigating Layer 4 SYN Floods at the Linux Kernel Tier

If you observed high SYN-RECV states, the Linux kernel is dropping legitimate packets because tcp_max_syn_backlog is saturated. Apply immediate kernel defense parameters:

Step 2.1: Activate TCP SYN Cookies Instantly

SYN Cookies allow the Linux kernel to encode connection state into the initial SYN-ACK sequence number rather than allocating state memory in the backlog queue:

# Enable SYN cookies in runtime without reboot
sudo sysctl -w net.ipv4.tcp_syncookies=1

# Increase queue backlog capacity
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sudo sysctl -w net.core.somaxconn=65535

# Reduce SYN-ACK retries to drop dead sockets faster
sudo sysctl -w net.ipv4.tcp_synack_retries=2
sudo sysctl -w net.ipv4.tcp_syn_retries=2

# Enable fast connection recycling
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.tcp_fin_timeout=15

3. Phase 3: Dropping Malicious IPs with iptables & ipset

Do not ban hundreds of individual IP addresses using standard iptables -A INPUT -s ... -j DROP, as linear iptables scanning causes high CPU interrupt overhead. Instead, use ipset which utilizes high-speed hash tables evaluated in $O(1)$ constant time.

Step 3.1: Install ipset and Create a Blocklist Table

sudo apt-get install -y ipset

# Create a high-performance hash set for malicious IPs
sudo ipset create ddos_blacklist hash:ip hashsize 4096 maxelem 1000000

# Attach the ipset to iptables at the very top of the INPUT chain
sudo iptables -I INPUT 1 -m set --match-set ddos_blacklist src -j DROP

Step 3.2: Rapidly Add Attacking IPs to the Blocklist

# Ban individual offending IP
sudo ipset add ddos_blacklist 198.51.100.24

# Automated script: Ban all IPs with more than 150 active connections
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | while read -r count ip; do
    if [ "$count" -gt 150 ] && [ "$ip" != "127.0.0.1" ] && [ -n "$ip" ]; then
        echo "Banning abusive IP: $ip (Connections: $count)"
        sudo ipset add ddos_blacklist "$ip" -exist
    fi
done

4. Phase 4: Mitigating Layer 7 HTTP Floods in Nginx

When attackers target dynamic URLs (such as WordPress search /?s=query, login forms /wp-login.php, or heavy catalog filters), each request spins up a PHP worker and executes expensive MySQL queries.

Step 4.1: Close Malicious Connections Instantly with HTTP 444

Nginx status code 444 instructs Nginx to immediately close the TCP connection and return zero bytes to the client, consuming virtually zero server memory and wasting the attacker's network bandwidth:

# /etc/nginx/conf.d/emergency_ddos_mitigation.conf

# 1. Drop requests with missing or empty User-Agent headers
if ($http_user_agent = "") {
    return 444;
}

# 2. Drop common automated exploit and stress tools
if ($http_user_agent ~* (Go-http-client|Python-urllib|curl|Wget|ApacheBench|wrk|Siege)) {
    return 444;
}

# 3. Block malicious query string patterns
if ($query_string ~* (UNION\+SELECT|base64_|eval\(|<script|\.\./)) {
    return 444;
}

Step 4.2: Enforce Nginx Rate-Limiting Memory Zones

Define in-memory rate-limiting zones in /etc/nginx/nginx.conf:

# Inside http {} block
limit_req_zone $binary_remote_addr zone=search_limit:20m rate=5r/s;
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {
    # Limit maximum concurrent connections per IP
    limit_conn conn_limit 20;

    # Protect WordPress login from brute-force floods
    location = /wp-login.php {
        limit_req zone=login_limit burst=3 nodelay;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        include fastcgi_params;
    }

    # Protect dynamic search queries from flooding the database
    location / {
        if ($arg_s != "") {
            limit_req zone=search_limit burst=5 nodelay;
        }
        try_files $uri $uri/ /index.php?$args;
    }
}

Test and reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

5. Phase 5: Emergency Edge Shielding via Cloudflare

Local server mitigation has a hard physical ceiling: if the attack volume exceeds your VPS network card bandwidth (e.g. a 5 Gbps flood on a 1 Gbps port), local iptables cannot save you. You must shift the defensive perimeter to an Anycast Edge Network.

Step 5.1: Point DNS to Cloudflare Proxy ("Orange Cloud")

• Log in to your Cloudflare dashboard.
• Ensure the A record for your domain has the proxy status set to Proxied (Orange Cloud).
• Cloudflare's Anycast edge network absorbs the volumetric flood across hundreds of global datacenters.

Step 5.2: Activate "Under Attack Mode"

• In the Cloudflare domain overview, toggle Under Attack Mode to ON.
• This enforces a mandatory JavaScript cryptographic proof-of-work challenge across all incoming visitors. Automated botnet clients and headless curl scripts that cannot evaluate JavaScript are dropped at the edge.

Step 5.3: Strict Origin IP Cloaking (The Most Critical Step)

If attackers know your direct origin IP address, they will continue sending traffic directly to your VPS, completely bypassing Cloudflare.

Configure UFW to block all web traffic except packets coming directly from Cloudflare's IP ranges:

# Automated Cloudflare IP Lockdown
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    sudo ufw allow proto tcp from "$ip" to any port 80,443 comment 'Cloudflare IPv4'
done

for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
    sudo ufw allow proto tcp from "$ip" to any port 80,443 comment 'Cloudflare IPv6'
done

# Block direct access to web ports from all other IPs
sudo ufw default deny incoming
sudo ufw reload

Once applied, your VPS CPU load will drop from 100% down to under 5% within 30 seconds.

6. Operational Troubleshooting Matrix for DDoS Emergencies

| Symptom | Primary Attack Type | Command Line Confirmation | Immediate Remediation | | :--- | :--- | :--- | :--- | | High SYN-RECV states; server unresponsive | Layer 4 TCP SYN Flood | ss -ant \| grep SYN-RECV \| wc -l | Enable net.ipv4.tcp_syncookies=1 via sysctl. | | High ESTAB states; PHP-FPM saturated | Layer 7 HTTP GET/POST Flood | netstat -ntu \| grep :443 \| wc -l | Enable Nginx limit_req and deploy Cloudflare Under Attack Mode. | | Server completely unreachable via SSH | Bandwidth interface saturation (Provider throttling) | Access VPS via Hosting Web Console / VNC | Contact provider for temporary scrubbing or change origin IP. | | Bandwidth spikes on UDP ports | DNS / NTP Amplification Flood | iftop -i eth0 or nload | Drop incoming UDP via iptables: iptables -A INPUT -p udp -j DROP. | | Attack continues after enabling Cloudflare | Attackers querying direct origin IP address | tail -f /var/log/nginx/access.log | Lock down origin firewall (UFW) to accept ONLY Cloudflare IPs. |

Production Architectural Specifications & Benchmark Metrics

The table below contrasts emergency triage mitigation benchmarks before and after applying kernel packet filtering and edge shielding during active DDoS incidents:

| DDoS Attack Vector & Metric | Unshielded VPS Under Attack | Kernel XDP/eBPF + Edge Shield | Measured Mitigation Impact | | :--- | :--- | :--- | :--- | | SYN Flood Resilience (800k pps) | CPU 100% / Network interface lock | 0% CPU loss (Dropped at NIC driver) | 100% Server Availability Retention | | Layer 7 HTTP Request Floods | 502/504 Bad Gateway collapse | Rate-limited (429 dropped in RAM) | Zero Backend Resource Starvation | | DNS Amplification Absorption | Saturates 1Gbps uplink bandwidth | Absorbed at Cloudflare Anycast edge | 100% Uplink Congestion Relief | | Emergency Triage Time-to-Mitigate | 45 - 90 minutes downtime | Under 3 minutes automated cutover | 95% Rapid Recovery SLA | | False-Positive Legitimate Drop | High under crude IP bans | Zero (Managed Challenge verification) | 100% Genuine User Continuity |

Verified Anti-DDoS Kernel Directives & Edge Firewall Standards

The following sysctl directives and iptables rate limits protect Linux origins during active attack mitigation:

| Defense Parameter / Rule | Enforcement Layer | Recommended Value | Upstream Technical Reference | | :--- | :--- | :--- | :--- | | net.ipv4.tcp_syncookies | Linux Kernel Sysctl | 1 (Enforces cryptographic SYN cookies) | TCP SYN Flood Defense RFC 4987 | | net.ipv4.tcp_max_syn_backlog | Linux Kernel Sysctl | 65535 (Expands half-open queue) | Linux IP Sysctl Documentation | | iptables -A INPUT -p tcp --syn -m limit | Network Netfilter | --limit 25/s --limit-burst 50 | Netfilter iptables Manual | | Cloudflare Under Attack Mode | Edge Anycast CDN | Managed Challenge on suspicious traffic | Cloudflare DDoS Defense Specs | | fail2ban banaction = ufw | Host IDS Jail | bantime = 48h findtime = 10m | Fail2ban Security Architecture |

7. Recommended Next Steps & Related Security Guides

Maintain proactive edge defenses to ensure your infrastructure is immune to future attacks:

• Cloudflare Edge Security & WAF Masterclass: Deploy custom edge WAF rules, Bot Management, and rate limiting.
• The 2026 Linux Server Maintenance Playbook: Sysadmin practices for monitoring, kernel tuning, and automated security patching.
• High-Performance Nginx Tuning Masterclass: Tune Nginx worker connections and buffer memory for high concurrency.
• Automated Linux Server Health Monitoring & Prometheus Alerts: Set up instant Telegram/Slack alerts when server load spikes unexpectedly.

8. Frequently Asked Questions (FAQ)

Q1: What is the difference between a Layer 4 and Layer 7 DDoS attack?

Layer 4 attacks (SYN floods, UDP reflection) target the transport layer to saturate network bandwidth and exhaust operating system connection tables. Layer 7 attacks (HTTP floods, search scraping) mimic legitimate browser requests to target the application layer, exhausting web server and database CPU resources without requiring massive bandwidth.

Q2: Can Fail2ban mitigate large-scale DDoS attacks?

Fail2ban is designed for low-frequency attacks like SSH brute-forcing or credential stuffing. During a large-scale DDoS attack with tens of thousands of requests per second, Fail2ban's log parsing overhead can actually crash the server. For large floods, use kernel SYN cookies, ipset, and edge CDNs (Cloudflare).

Q3: What should I do if my hosting provider null-routes my server IP?

If your server IP is null-routed, your provider has temporarily severed it from the network to protect other customers in their datacenter. Contact support to request temporary console access, assign a new clean secondary IP address, point your Cloudflare DNS to the new IP, and lock down your firewall to Cloudflare before lifting the null route.

Q4: Does enabling "Under Attack Mode" hurt my SEO or block Googlebot?

Cloudflare maintains an authoritative list of verified search engine crawlers (Googlebot, Bingbot). Verified search bots bypass Under Attack Mode challenges automatically based on reverse DNS validation, ensuring your organic search rankings and crawlability are not harmed.

© 2026 WebCare Pro. Authored by Mir Alamin.