A distributed denial-of-service (DDoS) attack tries to make a service unavailable by overwhelming it from many sources at once. Not all DDoS attacks are alike. Some flood your network link, some exhaust connection tables, and some look like normal web traffic. The type of attack determines where it has to be stopped, and whether anything on the server itself can help.

The three main categories

Category OSI layer Measured in Target
Volumetric L3/L4 Gbps / Tbps Bandwidth of the link
Protocol (state exhaustion) L3/L4 Packets per second Connection tables, firewalls, load balancers
Application (Layer 7) L7 Requests per second Web server, PHP, database

Volumetric attacks

The goal is to fill the pipe. If your server has a 1 Gbps port and the attack sends 20 Gbps, legitimate traffic can’t get through, whatever the server does.

  • UDP floods — huge volumes of UDP packets to random or specific ports.
  • Amplification / reflection — attackers send small requests with your IP spoofed as the source to open servers (DNS, NTP, Memcached, CLDAP, SSDP), which reply with much larger responses to you. Amplification factors range from tens to thousands of times.
  • ICMP floods.

Where to stop it: only upstream, at the provider’s network or a scrubbing service with more capacity than the attack. Firewall rules on the server are useless here, because the link is already saturated before packets reach your firewall.

Protocol attacks

These exhaust state in the server or network devices, often with moderate bandwidth but huge packet rates:

  • SYN flood — many TCP SYN packets, often from spoofed IPs, so half-open connections fill the backlog.
  • ACK / RST floods, fragmented packet attacks.
  • Connection exhaustion — opening and holding many full TCP connections.

Mitigation: partly on the server (SYN cookies, conntrack limits, kernel tuning), but large attacks overwhelm a single host’s CPU and network stack. Upstream filtering handles the big ones.

sysctl net.ipv4.tcp_syncookies          # should be 1

See sysctl tuning.

Application-layer (L7) attacks

These look like real users:

  • HTTP floods — many GET/POST requests, often to expensive pages (search, uncached pages, login, cart), from botnets or proxies.
  • Slowloris / slow POST — open many connections and send data very slowly, keeping server workers busy.
  • Cache-busting — random query strings so every request skips the cache.
  • API abuse — hammering costly endpoints.

Even a few hundred requests per second can bring down an uncached WordPress site, while the network is barely loaded.

Mitigation: much of this can be done on your side:

  • Caching — serve pages from a cache (Nginx FastCGI cache, CDN) so floods hit cheap paths. See Nginx FastCGI cache.
  • Rate limiting per IP in Nginx. See Nginx rate limiting.
  • Timeouts against slow attacks: Nginx’s event-driven design copes well. Keep client_body_timeout and client_header_timeout short.
  • Fail2Ban / CrowdSec for repeat offenders. See Fail2Ban for Nginx.
  • WAF / bot management (CDN-level) to challenge suspicious clients. See WAF explained.
  • A CDN in front hides the origin IP and absorbs much of the load.

Signs you’re under attack

vnstat -l -i eth0                                   # live bandwidth
ss -s                                               # connection counts
ss -tn state syn-recv | wc -l                       # half-open connections (SYN flood)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head    # top requesters
sudo dmesg | grep -i 'conntrack: table full'

The site is slow or unreachable, bandwidth or packet rates far exceed normal, there are thousands of SYN-RECV connections, or a few IPs (or many IPs hitting one URL) dominate the logs. See tcpdump.

What to do during an attack

  1. Identify the type: bandwidth (volumetric) vs connections vs requests.
  2. L7: enable stricter rate limits, turn on “under attack” mode at your CDN, block the worst offenders, and serve a cached or static page.
  3. Volumetric/protocol: contact your provider. This needs upstream filtering.
  4. Keep SSH reachable: firewall rules that allow your IP first, and the provider’s VNC console as a fallback.
  5. Afterwards, review: put a CDN in front, hide the origin IP, add caching, and consider dedicated DDoS protection.

DDoS protection at VPS.DO

DDoS protection is available as a paid add-on for dedicated servers in the USA, Hong Kong, Japan and Singapore, filtering attacks upstream before they reach the server. VPS plans don’t include DDoS protection. For sites that expect attacks, combine a VPS with a CDN/WAF in front, or choose a protected dedicated server. See USA dedicated servers and Hong Kong dedicated servers.

Quick reference

Attack Stop it where
UDP / amplification floods Upstream (provider scrubbing, CDN)
SYN flood SYN cookies on the server; upstream for large ones
HTTP flood Caching, rate limiting, CDN/WAF, bot challenges
Slowloris Nginx timeouts, connection limits
Cache-busting Normalise or ignore query strings in the cache key, rate limits

Related: Linux server hardening and Cloudflare with a VPS.

  • Security
  • Networking
  • DDoS