Types of DDoS Attacks and How to Stop Them

What a DDoS Attack Actually Is

A distributed denial-of-service (DDoS) attack tries to make your site, API, or game server unavailable by overwhelming it from many sources at once — often tens of thousands of compromised devices in a botnet. Because the traffic comes from everywhere, you can't just block one IP and move on.

The useful way to think about DDoS is by which layer it targets. The OSI model gives you a clean mental map: Layer 3 (network) and Layer 4 (transport) attacks try to saturate your bandwidth or exhaust connection state, while Layer 7 (application) attacks mimic real users to exhaust CPU, memory, or database capacity. The three families below map directly onto this — and each one needs a different defense.

Volumetric Attacks (Layer 3/4): Flooding the Pipe

Volumetric attacks are the brute-force category. The goal is simple: send more traffic than your link can carry, so legitimate packets never get through. They're measured in bits per second (bps), and modern floods are enormous — the largest recorded attacks now exceed several terabits per second, while a single unprotected server might have only a 1–10 Gbps uplink. You don't need a record-breaker to go down; 5–10 Gbps is enough to saturate most origins.

The most common technique is reflection and amplification. An attacker spoofs your IP address and sends small queries to misconfigured public servers — DNS, NTP, memcached — which reply with much larger responses aimed at you. A memcached amplification factor can exceed 50,000x, turning a trickle into a flood.

• Common types: UDP floods, ICMP floods, DNS/NTP/memcached amplification, reflection attacks.
• Goal: saturate bandwidth so nothing legitimate gets through.
• Stopped by: upstream scrubbing with terabits of capacity — you cannot filter a 1 Tbps flood on a 10 Gbps link.

Protocol Attacks (Layer 3/4): Exhausting Connection State

Protocol attacks don't aim for raw bandwidth — they abuse how networking protocols track state. The classic is the SYN flood: the attacker opens thousands of TCP handshakes per second but never completes them, filling your connection table until real users can't connect. These are measured in packets per second (pps) rather than bps, and a few hundred thousand pps can exhaust a firewall or load balancer even though the bandwidth looks modest.

Other variants include ACK floods, fragmented-packet attacks, and Ping of Death-style malformed traffic. The damage often lands on the in-between devices — firewalls, load balancers, and the OS network stack — not just the application.

• Common types: SYN floods, ACK floods, fragmented packet attacks, Ping of Death.
• Goal: exhaust connection tables and stateful devices (firewalls, load balancers).
• Stopped by: SYN cookies, rate limiting, and stateless filtering at the network edge before traffic reaches your stack.

Application-Layer Attacks (Layer 7): Looking Like Real Users

Layer 7 attacks are the sneakiest and often the hardest to stop. Instead of flooding bandwidth, they send seemingly legitimate requests to expensive endpoints — a login form, a search query, an add-to-cart action — at high volume. Each request looks valid, but it forces a database query or heavy computation, so even a few thousand requests per second can topple a server that easily handles a terabit of dumb UDP.

Examples include HTTP floods, Slowloris (which holds connections open by trickling partial requests), and targeted hits on cache-busting URLs. Because the traffic mimics human behavior, simple bandwidth metrics look normal while your app falls over. This is where a web application firewall (WAF), bot fingerprinting, and behavioral rate limiting earn their keep.

• Common types: HTTP/HTTPS floods, Slowloris, cache-busting and API abuse.
• Goal: exhaust CPU, memory, or database — not bandwidth.
• Stopped by: a Layer 7 WAF, bot detection, request rate limiting, and challenge-response (JS/CAPTCHA) for suspicious clients.

How to Actually Stop Them: A Layered Defense

No single tool covers all three families, so defense is layered. The non-negotiable foundation is upstream scrubbing: your traffic is routed through Anycast scrubbing centers with terabits of capacity, where malicious packets are dropped close to their source and only clean traffic reaches your origin. Volumetric and protocol attacks are filtered there; nothing you install on a single box can fight a flood larger than your own uplink.

On top of that, add an application-layer WAF and rate limiting to catch Layer 7 abuse, keep a CDN in front to cache and absorb spikes, and make sure mitigation is always-on rather than triggered manually — the difference between sub-10-second filtering and a human noticing the alert is the difference between a blip and an outage.

A few baseline habits matter too: never expose origin IPs publicly, harden against amplification by disabling unused UDP services, and rehearse your incident response so you're not improvising at 2 a.m.

• Layer 3/4 (volumetric + protocol): upstream Anycast scrubbing with multi-Tbps headroom.
• Layer 7 (application): WAF, bot filtering, and behavioral rate limiting.
• Always-on, automatic mitigation beats manual triggers — aim for sub-10-second response.
• Hide your origin IP and put a CDN in front to absorb spikes.

Get DDoS Protection That Covers All Three Layers

The honest takeaway: you can mitigate small Layer 7 attacks yourself with a WAF and good rate limits, but you cannot self-host your way out of a multi-hundred-gigabit volumetric flood. That requires scrubbing capacity that lives upstream of your server — which is exactly what a dedicated provider gives you.

NordicVentures runs always-on DDoS protection across Stockholm, Frankfurt, and Ashburn with multi-Tbps Anycast scrubbing spanning Layers 3, 4, and 7, sub-10-second mitigation backed by a 99.99% uptime SLA, and real engineers watching 24/7. You can onboard via BGP, GRE tunnel, or reverse proxy and protect your existing host — no re-platforming required. If you'd rather not find out the hard way which type of attack hits you first, see /ddos-protection to get covered.