DDoS Protection for VPS: How Attacks Work and How to Defend Your Server in 2025

By VPS.DO
June 20, 2026

A Distributed Denial of Service (DDoS) attack attempts to overwhelm your server with so much traffic that it cannot respond to legitimate users. VPS instances are frequent targets — whether because the server hosts a controversial website, runs a game server that attracts competitive animosity, operates a business that attracts malicious competitors, or simply because an attacker is scanning for easy targets. This guide explains how DDoS attacks work, what defenses exist at each layer, and how to build a protection stack that keeps your VPS online under attack.

How DDoS Attacks Work

Volumetric Attacks

Volumetric attacks flood your server’s network connection with traffic — UDP floods, ICMP floods, amplification attacks using DNS or NTP as reflectors. The goal is to saturate your server’s upstream bandwidth capacity. A 10 Gbps attack against a server on a 1 Gbps connection makes the server unreachable regardless of how well-configured the server software is. These attacks must be mitigated upstream — at the data center or CDN level — because by the time traffic reaches your server’s interface, the damage is already done.

Protocol Attacks (Layer 3/4)

Protocol attacks exploit weaknesses in TCP/IP: SYN floods that exhaust the server’s connection table by sending TCP SYN packets without completing the handshake, fragmented packet attacks that consume CPU on reassembly, and Smurf attacks that amplify traffic using ICMP broadcasting. These attacks target the network stack rather than application bandwidth.

Application-Layer Attacks (Layer 7)

Application-layer attacks send seemingly legitimate HTTP requests that are expensive to process — targeting search endpoints, login forms, database-heavy pages, or file download endpoints. A relatively small botnet of a few thousand bots sending 10 requests per second each can generate 10,000 requests per second — more than most unprotected VPS configurations can handle — while remaining under thresholds that trigger basic rate limiting.

Layer 1: Provider-Level DDoS Protection

The first line of defense must be upstream from your VPS — at the data center or transit provider level. Volumetric attacks that exceed your server’s bandwidth cannot be mitigated at the server level at all.

What to Look for in a VPS Provider

Null-routing vs. scrubbing: Basic providers null-route (blackhole) your IP during attacks — your server becomes completely unreachable. Better providers route traffic through scrubbing centers that filter malicious traffic while passing legitimate requests.
Protected bandwidth capacity: The threshold of attack traffic the provider can absorb. “5 Gbps DDoS protection” means attacks up to 5 Gbps are mitigated; larger attacks may still cause disruption.
Detection speed: How quickly the provider detects and begins mitigating an attack. Detection times of under 10 seconds are ideal; longer detection windows mean more downtime before mitigation activates.

Layer 2: CDN-Level Protection (Cloudflare)

Placing Cloudflare (or a similar CDN/WAF) in front of your VPS is one of the most effective and cost-efficient DDoS protection measures available. Cloudflare’s free tier includes:

Unlimited DDoS mitigation for HTTP/HTTPS traffic
Anycast network routing that absorbs traffic at edge locations worldwide before it reaches your origin
IP reputation filtering that blocks known malicious IPs automatically
Rate limiting and bot challenge capabilities (some features require paid tiers)

Configure Cloudflare Correctly

Cloudflare only protects traffic that flows through it. To prevent attackers from bypassing Cloudflare by connecting directly to your VPS IP:

Find Cloudflare’s IP ranges: cloudflare.com/ips
Configure your VPS firewall to only accept HTTP/HTTPS traffic from Cloudflare’s IP ranges

# Allow HTTP/HTTPS only from Cloudflare IPs (example — check for current ranges)
sudo ufw allow from 103.21.244.0/22 to any port 80
sudo ufw allow from 103.21.244.0/22 to any port 443
sudo ufw allow from 173.245.48.0/20 to any port 80
sudo ufw allow from 173.245.48.0/20 to any port 443
# ... add all Cloudflare IPv4 and IPv6 ranges
sudo ufw deny 80
sudo ufw deny 443

Automate this with Cloudflare’s API to keep rules current as their IP ranges change.

Enable Cloudflare Under Attack Mode

When under active attack, enable “Under Attack Mode” in Cloudflare’s dashboard. This presents a JavaScript challenge to all visitors — bots cannot complete it, legitimate browsers can. This alone stops most application-layer attacks immediately.

Layer 3: Linux Kernel-Level Protection

Configure the Linux network stack to resist SYN floods and other protocol attacks:

sudo nano /etc/sysctl.d/99-ddos-protection.conf

# SYN flood protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_max_syn_backlog = 2048

# Increase connection tracking table
net.netfilter.nf_conntrack_max = 1000000
net.netfilter.nf_conntrack_tcp_timeout_established = 600

# Prevent IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests (Smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ignore bogus ICMP error responses
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Reduce TIME_WAIT connections accumulation
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Increase port range for outbound connections
net.ipv4.ip_local_port_range = 1024 65535

sudo sysctl -p /etc/sysctl.d/99-ddos-protection.conf

Layer 4: iptables Rate Limiting

iptables can limit connection rates at the kernel level — faster and more efficient than application-level rate limiting:

sudo nano /usr/local/bin/iptables-ddos.sh

#!/bin/bash

# Flush existing rules
iptables -F
iptables -X

# Default policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow SSH (rate limited to prevent brute force)
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS with connection rate limiting
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 \
  --connlimit-mask 32 -j REJECT
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 50 \
  --connlimit-mask 32 -j REJECT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# Limit new connection rate (SYN flood mitigation)
iptables -A INPUT -p tcp --syn -m limit --limit 100/second --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Drop invalid packets
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# ICMP rate limiting
iptables -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT
iptables -A INPUT -p icmp -j DROP

sudo chmod +x /usr/local/bin/iptables-ddos.sh
sudo bash /usr/local/bin/iptables-ddos.sh

# Make rules persistent
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

Layer 5: Nginx-Level Rate Limiting

For application-layer attacks that bypass iptables (legitimate-looking HTTP requests), Nginx provides request rate limiting:

sudo nano /etc/nginx/nginx.conf

Add to the http block:

limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

Apply in your server block:

server {
    limit_conn conn_limit 20;  # Max 20 concurrent connections per IP

    location / {
        limit_req zone=general burst=20 nodelay;
        limit_req_status 429;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
        limit_req_status 429;
    }

    location /login {
        limit_req zone=login burst=5 nodelay;
        limit_req_status 429;
    }
}

Layer 6: Fail2ban for Attack Pattern Detection

sudo nano /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log
findtime = 600
bantime = 7200
maxretry = 10

[nginx-http-auth]
enabled = true
maxretry = 5
bantime = 3600

sudo nano /etc/fail2ban/filter.d/nginx-req-limit.conf

[Definition]
failregex = limiting requests, excess:.* by zone.*client: 
ignoreregex =

sudo systemctl restart fail2ban

Monitoring During an Attack

When you suspect an attack is underway, these commands help identify what is happening:

# View active connection counts per IP
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Watch incoming packet rates
watch -n 1 'iptables -nvL INPUT | head -20'

# View Nginx 429 rate (rate limit hits)
tail -f /var/log/nginx/access.log | grep " 429 "

# Check currently banned IPs
sudo fail2ban-client status nginx-req-limit

Recovery Plan After an Attack

Identify attack type from server logs (volumetric vs protocol vs application layer)
Enable Cloudflare Under Attack Mode immediately if using Cloudflare
Contact your VPS provider to engage upstream DDoS mitigation if traffic is saturating your bandwidth
Block persistent attacking IP ranges with iptables using ipset for efficient mass-banning
After the attack subsides, review logs to identify attack patterns and adjust rate limits
Document the attack type, duration, and effective mitigations for future reference

Getting Started

VPS.DO includes basic DDoS protection at the network level on all USA VPS plans and Hong Kong VPS plans. Pairing provider-level protection with the Cloudflare CDN layer and the server-level hardening in this guide creates a defense-in-depth stack that protects against the vast majority of common DDoS attack types.

Conclusion

Effective DDoS protection is layered — no single mitigation handles all attack types. Provider-level protection addresses volumetric attacks that exceed your server’s bandwidth. Cloudflare handles application-layer attacks and provides massive scale for HTTP flood mitigation. Kernel-level sysctl tuning resists SYN floods. iptables rate limiting handles connection floods. Nginx rate limiting and Fail2ban address application-layer abuse patterns. Implement all layers for comprehensive protection, and monitor your server during quiet periods so you have a baseline for comparison when an attack occurs.

DDoS Protection for VPS: How Attacks Work and How to Defend Your Server in 2025