Types of DDoS Attacks: Volumetric, Protocol and Layer 7

Ask a network engineer for help during an outage and the first question will be about numbers: how many gigabits, how many packets per second, how many requests. “The site’s down” is not an answer they can act on. Knowing the types of DDoS attacks is less about theory and more about being able to describe what is happening in terms that tell the right person what to filter.

The three types of DDoS attacks at a glance

The usual split follows the network layers. Each type has its own unit of measurement, and the unit alone often tells you which one you are facing.

Attacks on DNS sit across these categories and get their own article: DNS DDoS attacks.

Volumetric attacks: when the pipe is full

A volumetric attack simply sends more data than your connection can carry. A server on a 1 Gbps port goes dark with a few gigabits of junk. The odd thing is how calm the server looks. CPU at five percent, memory fine, because the packets are stuck in the network before they ever arrive.

UDP floods

UDP has no handshake, so an attacker can throw packets at any port and the link still has to carry them. If nothing is listening, the host may even spend effort sending ICMP replies.

Reflection and amplification

Here the bots do not send traffic to you directly. They send small requests to open services on the internet, DNS resolvers or NTP servers for instance, with your IP forged as the sender. Those services reply to you, and because the replies are bigger than the requests, the traffic is multiplied. CISA’s alert TA14-017A lists bandwidth amplification factors of 28 to 54 for DNS and 556.9 for NTP. How that works, and how operators shut it down, is covered in DNS amplification attacks.

You can usually spot reflection by source port: piles of inbound UDP from port 53 (DNS), 123 (NTP) or 1900 (SSDP) that you never asked for.

Your own server cannot do anything about volumetric floods. Help comes from your host filtering in its network, a scrubbing service that reroutes and cleans your traffic, or a CDN whose anycast network spreads the load over many locations.

Protocol attacks: SYN floods and friends

Protocol attacks go after state rather than bandwidth. Every TCP connection starts with SYN, SYN-ACK, ACK. In a SYN flood the bots send only the first packet, often from spoofed addresses. The server allocates a slot for each half-open connection and waits. Once the backlog is full, legitimate visitors cannot get in.

Stateful firewalls and load balancers suffer the same way because they track every connection. On Linux the giveaway in the kernel log is nf_conntrack: table full, dropping packet.

Two quick checks:

ss -tan state syn-recv | wc -l
sysctl net.ipv4.tcp_syncookies

Thousands of half-open connections are a strong sign. SYN cookies (value 1) let the kernel answer without reserving backlog space and are on by default on most current distributions. At very high packet rates that is not enough, and the provider has to step in.

Layer 7 DDoS attacks: HTTP floods on the application

For anyone running a shop, a SaaS app or a busy blog, this is the category that matters most. The requests are complete and well-formed. Each one looks like a visitor. The damage comes from volume and from what they request.

Common patterns:

• Floods on expensive pages. Search, login, cart and filtered listings trigger database work. An uncached CMS page can cost far more server time than a static file.
• Cache busting. Random query strings like /?r=8k2j make every request miss the cache and hit the origin.
• Slow requests. Instead of many requests, clients hold connections open by sending headers or bodies extremely slowly, tying up web server workers.
• API abuse. Unthrottled endpoints, password reset or coupon validation for example, called at high frequency.

The link is fine; the CPU is pinned. This is the type you can fight yourself: page caching, rate limiting with nginx limit_req, sensible client_header_timeout and client_body_timeout values against slow clients, and a WAF in front. What that looks like with a CDN is in the guide to Cloudflare DDoS protection.

Which type is hitting you right now?

Match the symptoms:

The commands to confirm each case are in how to detect a DDoS attack. If you are not yet sure it is an attack at all, read DDoS or traffic spike first.

What the classification means for your response

My rule of thumb: below layer 7 is your provider’s fight, layer 7 is yours or your CDN’s. When you call your host, quote the unit that fits. “40,000 sockets in SYN_RECV and a full conntrack table since 14:02 UTC” gets you a filter rule faster than “everything is broken”.

One gap shows up in a lot of plans. A CDN cannot help if nobody can resolve your domain because the name servers are down. Use a registrar where you set name servers yourself and can enable DNSSEC. At betadomain that is the default for name server management and domain security, you can look up a new project name with the domain availability check, and every extension’s fixed yearly price is on the pricing page. Next, read through the DDoS attack response checklist so you have it before you need it.