Understanding DDoS Attacks and How to Protect Your Server

A DDoS attack floods a target with traffic from many sources at once, with the aim of exhausting bandwidth, connection state or application capacity until legitimate users cannot get through. Defence works in layers: network-level scrubbing absorbs the volume, the operating system absorbs connection floods, and the application absorbs request floods. No single layer covers all three.

The three kinds of attack, and what each exhausts

Layer	Typical form	What runs out	Where it must be stopped
Volumetric (L3/L4)	UDP flood, DNS/NTP/memcached amplification	Bandwidth on the link	Upstream, before it reaches you
Protocol (L4)	SYN flood, ACK flood, connection exhaustion	Connection tables, kernel state	Upstream and at the kernel
Application (L7)	HTTP flood, slowloris, expensive-endpoint abuse	Workers, database, CPU	At your proxy and application

The critical asymmetry is that a volumetric attack cannot be stopped by anything on your server. Once packets have traversed the link, the bandwidth is already spent — dropping them at the host costs you CPU on top of the bandwidth you already lost. This is why scrubbing has to be upstream, and why "I have a firewall" is not a DDoS answer. Our network applies DDoS protection in front of every VPS and dedicated server for that reason; see the firewall guide for what the host layer is genuinely good at.

Amplification: why small attacks become large ones

Amplification abuses UDP services that answer a small request with a large reply. The attacker spoofs your address as the source, sends a tiny query to thousands of open resolvers, and every one of them sends the much larger answer to you. A modest botnet turns into a very large flood without the attacker owning much bandwidth at all.

The defensive lesson runs both ways: make sure you are not the reflector. Never expose a recursive DNS resolver, an open NTP server, or an unauthenticated memcached instance to the internet. Bind them to 127.0.0.1 or restrict them by source.

Hardening the kernel against protocol floods

cat <<'EOF' | sudo tee /etc/sysctl.d/99-ddos.conf
# SYN flood mitigation
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2

# accept queue depth
net.core.somaxconn = 4096
net.core.netdev_max_backlog = 16384

# do not respond to broadcast pings; drop spoofed sources
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1

# reclaim dead connections faster
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
EOF
sudo sysctl --system

SYN cookies are the important line. With them enabled the kernel stops allocating state for half-open connections under flood conditions and instead encodes the connection information in the sequence number, so the backlog cannot be exhausted.

Absorbing application-layer floods

L7 attacks are the hardest to distinguish from real traffic, because each request is individually legitimate. The defence is rate limiting plus making expensive endpoints cheap.

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

server {
    limit_conn conns 20;
    client_body_timeout   10s;
    client_header_timeout 10s;
    send_timeout          10s;

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

The short timeouts defeat slowloris, which works by opening many connections and sending headers one byte at a time to hold workers open indefinitely. Nginx's event model already handles this far better than a thread-per-connection server does, but the timeouts close the gap entirely.

One caveat that catches people: if you sit behind a CDN, $binary_remote_addr is the CDN edge address and your rate limit applies to the entire edge as one client. Configure set_real_ip_from with the CDN's ranges and real_ip_header first — details in the reverse proxy guide.

Architecture choices that matter more than any setting

• Hide the origin. If your real IP is public, an attacker can bypass every proxy in front of it. Change the IP when you put a CDN in place, and firewall the origin to the CDN's ranges only.
• Cache aggressively. A request served from cache costs almost nothing. A flood against cached routes is survivable; a flood against a route that queries a database is not.
• Make expensive endpoints authenticated. Search, export, report generation and password reset are the endpoints attackers pick precisely because they cost you the most per request.
• Spread the failure domain. Several smaller instances across locations degrade under attack; one machine falls over. Hourly billing makes standing up extra capacity during an incident a practical response — see hourly VPS hosting.
• Have more headroom than you need. Bandwidth is the resource an attack consumes first. A 10 Gbps unmetered port absorbs floods that saturate a 1 Gbps link, and unmetered means an attack does not also generate an overage bill.

What to do during an attack

1. Confirm it is an attack. ss -s for connection counts, iftop or vnstat for bandwidth, web server logs for request patterns. A viral link and a flood look similar for the first five minutes.
2. Identify the layer. Bandwidth saturated with the application idle means volumetric. Application saturated with modest bandwidth means L7.
3. Tell your provider. Volumetric mitigation happens upstream and they can see the traffic you cannot.
4. Shed what you can. Tighten rate limits, serve a static cached page, temporarily geo-restrict if the sources are concentrated.
5. Keep logs. They are the only way to tune the response afterwards.

Frequently asked questions

Can a firewall stop a DDoS attack?

A host firewall stops protocol and application abuse it can identify. It cannot stop a volumetric attack, because the bandwidth is consumed before your server sees the packets. That mitigation has to happen upstream on the network.

Does DDoS protection slow down normal traffic?

Well-implemented scrubbing adds a small, fixed latency and is otherwise invisible. Aggressive rate limiting configured by you is far more likely to affect real users than the network layer is.

Are small sites targeted?

Routinely. Booter services make small attacks cheap, and game servers, forums and small e-commerce sites are common targets. Size of business is not a defence.

What is the difference between DoS and DDoS?

DoS comes from one source and can be blocked by blocking that source. DDoS comes from many, which is exactly what makes source-based blocking ineffective.

Getting the layers in place

Start with the host: a firewall, then general hardening, then caching and rate limits at the proxy. The network layer is ours: DDoS protection is applied in front of every VPS and dedicated server we run, on unmetered ports, so an attack does not turn into a bandwidth invoice.