DDoS Attacks Explained: Common Forms and How to Protect Against Them

Answer first: no single layer stops a DDoS

A distributed denial-of-service attack is an attempt to exhaust a resource you depend on — your bandwidth, your server's connection table, or your application's capacity to answer requests — using traffic from many sources at once. The single most useful thing to understand is that different attack forms exhaust different resources, and a defence that works against one family does nothing against another:

• Volumetric attacks fill your network pipe. Once your uplink is saturated, nothing you configure on the server matters — the traffic has to be absorbed or dropped upstream, by your hosting provider's mitigation or a scrubbing service.
• Protocol (state-exhaustion) attacks fill connection-tracking tables on servers, firewalls, and load balancers. These are fought with SYN cookies, sensible timeouts, and rate limits — partly on-host, partly at the edge.
• Application-layer attacks exhaust your application itself with requests that look legitimate. These need Layer 7 defences: caching, rate limiting, a WAF or CDN, and application hardening.

Effective protection is therefore layered: provider-level scrubbing for volume, edge and kernel settings for state, and application-level controls for Layer 7 — plus a firewall baseline that shrinks your attack surface in the first place. The rest of this article walks each family in detail, then assembles the layers into a practical defence.

The three families of DDoS attack

Security vendors classify DDoS attacks a dozen different ways, but nearly everything you'll meet in practice falls into three families, distinguished by the resource they exhaust.

Volumetric attacks: filling the pipe

The goal is brute force: send more traffic than your link can carry. The commonest form is a plain UDP flood — meaningless datagrams at line rate — which Cloudflare's telemetry put at the top of the network-layer vector list in late 2025, growing 231% quarter-over-quarter.

The more interesting variant is the reflection/amplification attack. The attacker sends small requests to open internet services (DNS resolvers, NTP servers, exposed memcached instances) with the source address spoofed to be your server. The services then "reply" to you — and for the right request, the reply is vastly larger than the query. The canonical amplification factors from CISA's UDP-based amplification advisory show why attackers love this technique:

With memcached, one megabit of attacker upstream can become tens of gigabits arriving at your address. Reflection attacks are also why the traffic you capture during an attack often comes from port 53, 123, 389, or 11211 — the reflectors are legitimate servers answering what they believe are your queries. (Our companion guide on analysing a DDoS attack with Wireshark shows how to identify these signatures in a capture.)

A newer volumetric pattern worth knowing is carpet bombing: instead of concentrating on one IP, the attacker sprays moderate volumes across an entire subnet or across thousands of destination ports, staying under per-IP detection thresholds while still saturating aggregate capacity. NETSCOUT counted 750–830 carpet-bombing attacks per day in the second half of 2025.

How big can volumetric attacks get? The public record has escalated at a startling pace: from 3.8 Tbps in late 2024, through a 7.3 Tbps attack in June 2025, to a 31.4 Tbps, 14.1-billion-packets-per-second attack in December 2025 — driven by Mirai-descended IoT botnets (Aisuru and its offshoots) built from compromised routers, cameras, and Android TV boxes. Those are records against the largest mitigation networks on earth, not typical events — but even an unremarkable multi-gigabit flood exceeds the uplink of most single servers, which is the point of the next section's "upstream first" rule.

Protocol attacks: exhausting connection state

Rather than raw bandwidth, these attacks target the state tables that servers, firewalls, and load balancers keep for every connection.

The classic is the SYN flood. TCP's handshake makes the server allocate state when a SYN arrives, while it waits for the final ACK that never comes. Enough half-open connections and the listen queue is full: legitimate clients can't connect even though bandwidth and CPU are fine. SYN floods remain a top-three network-layer vector in Cloudflare's data decades after they were first described — they're cheap, effective, and easy to generate with spoofed sources.

The standard defence, SYN cookies, encodes the connection state into the sequence number of the SYN-ACK itself, so the server allocates nothing until the handshake completes. Linux enables them by default (net.ipv4.tcp_syncookies = 1) and they should stay on for any internet-facing server.

Relatives in this family include ACK/RST floods (garbage packets that force conntrack lookups), fragmentation attacks (incomplete fragments that tie up reassembly buffers), and connection floods that complete handshakes and then sit idle to occupy slots. Note that a stateful firewall — including the conntrack-based rules on your own server — is itself a state table an attacker can aim at, which is one reason firewall rules for high-exposure servers deliberately avoid tracking certain traffic. Our default firewall rules guide covers where that trade-off sits.

Application-layer attacks: legitimate-looking requests

Layer 7 attacks skip the plumbing and exhaust the application: HTTP request floods against expensive endpoints, cache-busting (randomised query strings that force every request through to origin), slowloris-style attacks that hold connections open by sending headers one byte at a time, and protocol-level tricks like HTTP/2 Rapid Reset (CVE-2023-44487), which abused stream cancellation to generate hundreds of millions of requests per second in 2023 before implementations added reset rate controls.

These are the hardest attacks to filter because each request is, individually, valid — the malice is in the volume and the distribution. Modern HTTP floods come predominantly from botnets and headless browsers that present plausible TLS fingerprints and user agents. Mitigation is correspondingly application-aware: aggressive caching so requests never reach origin, per-client and per-endpoint rate limits, a WAF or CDN that scores clients behaviourally, and making your expensive endpoints (search, login, report generation) cheap or gated.

How common is all this?

Common enough that you should treat it as an operational certainty rather than a tail risk. Cloudflare alone blocked 47.1 million DDoS attacks in 2025 — up 121% year-over-year — and NETSCOUT counted over 16 million attacks globally across the year, more than half of them multivector: combinations of the families above launched simultaneously.

Two statistics matter most for how you plan your defence:

• Attacks are short. 89% of network-layer attacks and 71% of HTTP attacks end within ten minutes; even the 31.4 Tbps record lasted 35 seconds. A mitigation that requires a human to notice the attack, open a ticket, and enable scrubbing will regularly finish deploying after the attack has ended. Always-on automated mitigation is the operative standard now, not on-demand scrubbing.
• Attacks are multivector. NETSCOUT found roughly 42% of attacks used two to five vectors. Defending one family and ignoring the others just tells the attacker which button to press.

The mitigation stack, layer by layer

Think of the defence as four layers, from the internet inward. Each layer stops what the layers below it cannot.

Layer 1: upstream mitigation (the only answer to volume)

The unavoidable physics: if the attack is bigger than your pipe, only someone upstream of your pipe can stop it. A server on a 10 Gbit/s port cannot firewall its way out of a 50 Gbit/s flood — the packets have already won by the time they reach the interface your rules run on.

Upstream defences work by having more capacity and better vantage than any single server:

• Anycast absorption and scrubbing — the approach used by large mitigation networks and DDoS-protected hosts: attack traffic is attracted to the nearest of many locations, spread thin, filtered, and only clean traffic is delivered. This is how the multi-terabit records were absorbed, autonomously and without human intervention.
• RTBH (remotely triggered blackhole) — a network-operator tool that drops all traffic to a target prefix at the network edge. It protects the rest of the network but completes the attacker's job for the blackholed host; modern practice treats it as a blunt first response, refined afterwards with BGP FlowSpec rules that match and drop only the attack signature (protocol, ports, packet size) instead of everything.

As a customer you don't operate these yourself — you choose a host or mitigation provider that does, and you confirm the protection is always-on rather than reactive. Given that nine in ten attacks are over within ten minutes, this distinction is most of the value.

Layer 2: edge filtering and rate limiting

Between the upstream scrubber and your application sit defences that cost you little and blunt the middle of the threat model:

• Network ACLs / edge firewall rules — if your server only serves HTTPS, traffic to UDP 11211 or TCP 23 has no business reaching it. Dropping non-service traffic before it touches your server's conntrack removes entire attack classes. A self-service network-edge firewall (which we provide on our dedicated servers) does this filtering on the network, upstream of your port.
• Rate limiting per source — caps on new connections per second per IP absorb the low end of connection floods and brute-force noise. Crude but effective against unsophisticated attacks; ineffective against widely distributed ones, which is fine — that's what layers 1 and 4 are for.

Layer 3: the host itself

On-host settings won't save you from a volumetric flood, but they decide how gracefully you survive everything smaller:

• SYN cookies on (Linux default — verify with sysctl net.ipv4.tcp_syncookies).
• A default-deny firewall baseline so only your actual services accept traffic — our sensible default firewall rules article gives a complete annotated ruleset, and if you're deciding which tooling to write it with, see iptables vs nftables.
• Conntrack sizing and timeouts — on busy servers, raise net.netfilter.nf_conntrack_max and shorten aggressive timeouts so garbage state expires quickly, or exempt your high-volume service ports from tracking entirely.
• No accidental reflectors. The flip side of the amplification table above: make sure your server isn't the one amplifying. Don't run an open resolver, disable NTP monlist (fixed in ntpd 4.2.7+, but check anything ancient), and never expose memcached on UDP to the internet.

Layer 4: application-layer defences

For HTTP floods and their relatives: put a CDN or reverse proxy with caching in front of dynamic applications, rate-limit expensive endpoints separately from cheap ones, keep HTTP/2 implementations patched (Rapid Reset and its 2025 successor "MadeYouReset" are both blunted by updated servers), and design so that anonymous requests are cacheable by default. If you operate your own reverse proxy on a dedicated server, nginx's limit_req and limit_conn cover a surprising amount of ground.

Detecting an attack: the signals

Most attacks announce themselves as a sudden anomaly in exactly one resource. Worth watching (and alerting on):

• Bandwidth: inbound traffic pinned at your port speed is the volumetric signature. If your provider graphs traffic before and after mitigation, the difference is the attack.
• Packet rate: millions of small packets per second with modest bandwidth points at packet-rate attacks (SYN/ACK floods) rather than bandwidth attacks.
• Half-open connections: ss -s showing synrecv counts in the thousands is a SYN flood in progress.
• Application saturation with normal system load: worker pools full, response times spiking, but network and CPU unremarkable — the L7 signature.
• Source-port patterns: inbound floods from port 53/123/389/11211 mean you're receiving reflected traffic.

When you need to know precisely what you're being hit with — to write a FlowSpec-style filter or give your provider actionable detail — capture a sample and analyse it; that's the subject of our Wireshark DDoS analysis guide.

An incident-response runbook

When it happens, the order of operations matters more than heroics:

1. Confirm it's an attack, not an outage or a launch. Check whether the traffic is anomalous in kind (weird ports, spoofed-looking sources, one URL hammered) and not just in volume.
2. Identify the vector — from your provider's mitigation dashboard or a 30-second packet sample. Family determines response: volumetric → upstream; state → tune and rate-limit; L7 → cache and filter.
3. Engage the mitigation you already have. If your host's protection is always-on, verify it's engaging (traffic-scrubbed graphs); if anything is self-service — edge firewall rules, mitigation profiles — apply the rule that matches the vector.
4. Reduce your surface mid-attack. Temporarily drop non-essential listeners, enable aggressive caching, put expensive endpoints behind a challenge if you have a WAF.
5. Talk to your provider with specifics. "SYN flood, ~4 Mpps, spoofed sources, targeting 203.0.113.10:443" gets a useful response much faster than "we're under attack".
6. Afterwards, write down what worked. Attacks recur. The filter that stopped this one should be a saved profile, not a memory.

Frequently asked questions

Can a firewall on my server stop a DDoS attack?

It can stop some kinds and not others, and knowing which is the whole game. An on-host firewall effectively blunts small SYN floods, connection floods, and junk aimed at ports you don't serve. It cannot help with a volumetric attack that saturates your uplink — those packets have already crossed the wire your firewall sits behind, so the filtering must happen upstream, at your provider's edge or scrubbing layer.

What's the difference between DoS and DDoS?

A DoS attack comes from one source; the extra D is "distributed" — many sources at once, today typically an IoT botnet or a fleet of proxies. Distribution is what makes the attacks both large (a botnet of a million Android TV boxes generated the current 31.4 Tbps record) and hard to filter by source address, since there is no single address to block — mitigation has to match the attack's shape instead.

How long do DDoS attacks last?

Shorter than most people expect: roughly nine in ten network-layer attacks end within ten minutes, and even record-breaking attacks have lasted under a minute. That brevity is a feature for attackers — short bursts evade on-demand mitigation that takes minutes to engage — and it's why always-on protection has displaced "call us when it happens" scrubbing as best practice.

Do I need DDoS protection for a small site?

Yes, in the sense that you should choose infrastructure where protection is included rather than buying it as an emergency later. Small sites get attacked for unglamorous reasons — a disgruntled user with a $20 booter subscription, a competitor, or simply being a carpet-bombing bystander in the wrong subnet. Since attacks are cheap to launch and protection is now bundled by good hosts at no extra cost, the economics favour having it before you need it.

Deploying on Serverside

Every server on our network sits behind always-on DDoS mitigation — attacks are detected and scrubbed automatically at the network edge, which (as this article hopefully made clear) is the only place volumetric attacks can be stopped. On top of that, our dedicated servers include a self-service firewall at the network edge, so you can drop non-service traffic before it ever reaches your port, and self-service mitigation controls for tuning protection to your workload. Provisioning is sub-minute on our own ASN 55285 network.

For the on-host half of the defence, start with our default firewall rules for a Linux server, pick your tooling with iptables vs nftables, and learn to identify exactly what's hitting you with how to capture and analyse a DDoS attack in Wireshark. If you're setting up a fresh box, our Linux distribution guide covers the base OS decision.