--- title: "What to Do When Your VPS Is Under DDoS: Emergency Triage, Mitigation & Edge Shielding" description: "Actionable emergency step-by-step guide for sysadmins when a Linux VPS is under active Layer 4 or Layer 7 DDoS attack, covering real-time traffic analysis, iptables, and edge proxy shielding." canonical: "https://webcarespro.com/blog/post/vps-under-ddos-emergency-mitigation-guide" author: "Mir Alamin" date: "August 16, 2026, 08:30 AM" date_modified: "August 16, 2026, 08:30 AM" last_updated: "2026-09-16" category: "Security" tags: ["VPS Under DDoS","Linux Server Maintenance Freelancer","DDoS Mitigation","Server Troubleshooting","Iptables","Security"] --- # 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: ```bash 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: ```bash netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 20 ``` Or using modern `ss`: ```bash 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: ```bash # 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 ```bash 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 ```bash # 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: ```nginx # /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\(|