DDoS Attacks Explained: Types, Detection and Defense (2026)

A DDoS attack (Distributed Denial of Service) makes a server, a service, or an entire network unavailable to legitimate users by overwhelming it with a flood of requests or traffic. The principle is simple, the effect drastic. When thousands of devices hit the same website at once, there is no capacity left for real visitors. The site stops loading, and users see, at best, an error such as "HTTP 503 Service Unavailable".

This article explains DDoS from the ground up and deliberately goes deeper than most overviews. You will learn not only which three attack classes exist, but also the exact amplification factors that volumetric attacks rely on (from DNS at 28 to 54 times up to Memcached at 10,000 to 51,000 times), how the novel HTTP/2 Rapid Reset mechanism (CVE-2023-44487) works at the protocol level, and how record attacks in 2024 and 2025 climbed all the way to 31.4 Tbps.

Above all, you get something almost no other primer provides: real, runnable defense code. We show rate limiting with nginx verbatim from the official documentation, SYN cookie and iptables configuration against protocol attacks, and a Snort detection rule straight from a CISA advisory. We close with a note on legality and the fact that operating or renting DDoS-for-hire services is a crime in most jurisdictions.

What is a DDoS attack?

A denial-of-service attack (DoS) aims to overload or disrupt a service so that it can no longer do its job. In terms of the classic security goals, it is a direct assault on availability, one of the three pillars of the CIA triad. A plain DoS attack comes from a single source and is therefore usually easy to block: you ban the one offending IP address, and it is over.

A distributed denial of service spreads that same load across hundreds or thousands of sources at once. The simplest defense no longer works, because there is no single IP left to block. The attacking systems are scattered around the world, and their traffic often looks, at first glance, like perfectly ordinary traffic.

Botnets, the attacker's infrastructure

The distributed sources almost always form a botnet: a network of malware-infected devices that an attacker controls remotely. A single hijacked device is called a bot or zombie. Poorly secured IoT devices are especially popular targets, such as routers, security cameras, network storage, and by now even smart TVs, because they are numerous, permanently online, and frequently ship with default passwords.

Anyone who does not want to run their own botnet can simply rent attack capacity. So-called booter or stresser services offer DDoS as a service, sometimes disguised as legitimate "load testing" tools. This drops the technical barrier to launching an attack to almost nothing.

Why attackers do it

The motivations are varied, ranging from financial to political:

• Extortion: attackers take a service down, or threaten to, and demand a ransom, often in cryptocurrency (ransom DDoS).
• Competitive sabotage: knocking a rival offline during a critical window, for instance the holiday shopping season.
• Ideology and hacktivism: politically motivated attacks against governments, agencies, or companies.
• Distraction: a loud DDoS attack ties up the security team while a quieter attack runs in parallel, such as data theft or ransomware.
• Vandalism and bragging rights: attacks with no concrete goal, often by inexperienced actors ("script kiddies") using rented booter services.

The three classes of DDoS attacks

The industry consensus, used consistently by Cloudflare, Imperva, Check Point, and others, is a classification into three classes based on the layers of the OSI model. Each class exhausts a different resource, which is exactly why a defense against one class does not automatically help against another. Amplification and reflection are not a separate fourth class here, but a technique used within volumetric and protocol attacks.

Volumetric attacks (Layer 3/4)

Volumetric attacks simply saturate the bandwidth between the target and the internet. They are the most common form and, measured in bits per second, the most spectacular. The server does not even have to be "beaten": clogging the pipe leading to it is enough.

• UDP flood: UDP is connectionless, with no handshake. The attacker sends large volumes of UDP packets to random ports. The server looks for a listening service on each port, finds none, and replies with a "destination unreachable" ICMP message. Both the lookup and the reply cost resources.
• ICMP flood (ping flood): the target is flooded with ICMP echo requests faster than it can answer them.
• DNS amplification and other amplification attacks: the most efficient way to cause large damage with little bandwidth of your own (see the next section).

Amplification and reflection: the numbers

In an amplified reflection attack (Distributed Reflective Denial of Service, DRDoS), the attacker abuses publicly reachable UDP servers as unwitting amplifiers. The trick relies on two properties of UDP: it is connectionless, and it does not verify the sender address. The attacker spoofs the source IP to the victim's address and sends a small query to an open server. That server replies with a much larger response, and it sends it to the victim rather than the attacker.

Just how large this lever is, is quantified by the CISA advisory TA14-017A through the Bandwidth Amplification Factor (BAF), the ratio of response size to request size. The following table is taken verbatim from that advisory (the BAF data itself comes from research by Christian Rossow):

Memcached tops the list so extremely because a single spoofed packet can trigger a response tens of thousands of times larger. An attacker with a modest uplink can thus generate a terabit-scale attack. This exact effect makes amplification attacks the weapon of choice for record-breaking figures.

Protocol attacks (Layer 3/4)

Protocol attacks do not saturate bandwidth; they exhaust the resources that servers, firewalls, and load balancers use to manage connections. That makes them dangerous without necessarily being "large": a server that comfortably handles 10 Gbps of legitimate traffic can be brought down by a SYN flood of just 500 Mbps.

• SYN flood: in a normal TCP handshake the client sends a SYN, the server replies with SYN-ACK and reserves memory, and the client confirms with ACK (the three-way handshake). In a SYN flood the attacker sends huge numbers of SYN packets but never the final ACK. The server keeps the connections half-open and waits until its connection table fills and no legitimate connections can be accepted.
• Ping of Death: oversized packets beyond the IPv4 limit of 65,535 bytes could cause buffer overflows during reassembly. This is largely fixed in modern systems.
• Smurf and Fraggle attacks: reflection via broadcast addresses, mostly neutralized today by disabling directed broadcasts on routers.

The classic countermeasure against SYN floods is SYN cookies: instead of reserving memory for each half-open connection, the server cryptographically encodes the connection state in the sequence number of the SYN-ACK. It has nothing to remember. Only when a valid ACK returns does it reconstruct the state from the cookie. The connection table never fills. We show how to enable this in the defense section.

Application layer attacks (Layer 7)

Layer 7 attacks are the most insidious, because their traffic looks entirely legitimate at the lower layers. They target neither bandwidth nor connection tables, but the expensive work an application does per request: a database query, rendering a page, a search operation. A single HTTP request can cost the server a multiple of what it costs the attacker.

• HTTP flood: seemingly normal GET or POST requests in large numbers, each triggering real processing. Because they look like legitimate traffic, network-only tools can barely tell them apart.
• Slowloris: the opposite of a flood. The attacker opens many connections and sends the HTTP headers deliberately very slowly and never completely. The server keeps each connection open and waits until its connection pool is exhausted, all with minimal bandwidth.
• HTTP/2 Rapid Reset: the most significant new Layer 7 mechanism in years, which we give its own section.

HTTP/2 Rapid Reset (CVE-2023-44487) in detail

Not a single one of the common DDoS overview articles explains this attack, even though it is the most serious new DDoS technique since 2023 and nearly tripled the previous record for requests per second. Reason enough to go deep here.

Why HTTP/2 makes the attack possible at all

HTTP/1.1 processes requests over a connection essentially serially: one request, one response, the next request. HTTP/2 introduces stream multiplexing: many concurrent streams run over a single TCP connection, each with its own stream ID. To protect itself against overload, the server announces a limit on concurrent streams, typically 100 per connection.

That very limit is what the attack defeats. HTTP/2 has an RST_STREAM frame that lets a client cancel a single stream immediately, entirely by design, for example when a user navigates away before a page finishes loading.

The mechanism

The attack combines the two into a simple, brutally efficient pattern: the client opens a stream (sends a HEADERS frame, that is the request) and cancels it in the same instant (sends RST_STREAM). As soon as the reset arrives, the stream counts as closed and no longer counts against the concurrency limit. The client can immediately open the next stream, without ever waiting for a response.

On the server, however, the work is already in motion: read the request, forward it, load the backend. Cloudflare describes it as a malicious client sending "an enormous chain of requests and resets at the start of a connection", with the servers "eagerly reading them all and creating stress on the upstream servers". The officially announced limit of 100 concurrent streams becomes effectively meaningless, because every stream is released again at once.

In a Wireshark analysis of 1,000 malicious requests, Cloudflare showed just how compact this is: the first HEADERS frame was 26 bytes, each subsequent one only 9 bytes thanks to HPACK compression. A single network packet contained 525 requests, up to stream 1051, even though the server had only permitted 100 concurrent streams.

Why it is so dangerous

Classic Layer 7 floods need either many connections or have to wait for serial processing. Rapid Reset avoids both. A single connection generates thousands of requests per second. That is why, according to Cloudflare, a comparatively tiny botnet of only around 20,000 machines was enough to run a record attack, a fraction of what a volumetric attack of that scale would require.

Defense

• Patch: update server and proxy software as soon as vendor patches are available. CISA published the advisory on October 10, 2023, alongside the coordinated notices from Cloudflare, Google, AWS, NGINX, and Microsoft. The flaw had already been exploited in the wild from August through October 2023, before a patch was available.
• Monitor the RST_STREAM rate: close connections that reset an unusual number of streams immediately, without penalizing legitimate cancellations.
• Lower the concurrency limit: Cloudflare temporarily reduced the concurrent stream limit from 100 to 64 before raising it again for compatibility reasons.
• Jail repeat offenders: Cloudflare's "IP Jail" not only blocks a flagged IP from the attacked property but also forbids it from using HTTP/2 to any other domain on the platform for a while.

Record attacks: a documented timeline

Many figures circulate about record attacks, and they are frequently mixed up. So here are two separate timelines, each figure with its own date and context. Crucially, requests per second (rps) and bits per second (bps) measure two entirely different things and must not be compared.

Rapid Reset in numbers (2023, measured in rps)

When CVE-2023-44487 was disclosed in October 2023, several vendors published their own peak values for the same attack phenomenon, each measured on their own infrastructure. These are not conflicting claims about a single figure, but independent measurements:

• Cloudflare: 201 million rps (attack window August 25 to 29, 2023). At the time this was nearly triple the previous record of 71 million rps, generated by a botnet of only around 20,000 machines.
• Google: 398 million rps (peak over 2 minutes, spanning late August into September 2023). This is the highest primary-sourced Rapid Reset figure and exceeded Google's own previous record of 46 million rps by more than eightfold.
• AWS: around 155 million rps. This figure circulates widely as a third comparison value, but it explicitly does not appear in the official AWS Security Bulletin AWS-2023-011, which states no concrete rps figure. It should therefore be treated only as a secondary report, not as an official AWS statement.

Volumetric records (2024 to 2025, measured in bps)

In parallel, the purely volumetric records exploded. Cloudflare reported a new high three times in a row within roughly 14 months:

• 5.6 Tbps on October 29, 2024, lasting 80 seconds. A UDP DDoS against a Magic Transit customer (an East Asian internet provider), sourced from a Mirai variant of over 13,000 IoT devices.
• 7.3 Tbps in mid-May 2025, lasting 45 seconds. UDP floods made up 99.996% of the attack traffic; in total 37.4 terabytes were delivered in that brief three-quarters of a minute, spread across 122,145 source IPs from 161 countries.
• 31.4 Tbps on December 19, 2025, lasting only 35 seconds. The attack is attributed to the Aisuru-Kimwolf botnet, which according to Cloudflare consists mainly of malware-infected Android TV devices, an estimated 1 to 4 million infected hosts.

For context on the overall trend: Cloudflare counted 47.1 million DDoS attacks in 2025, up 121% from 2024. Notable is the extreme brevity of the record attacks, 35 to 80 seconds. Such short bursts are deliberately engineered to hit their target before a human-triggered alert can even take effect. That is precisely why effective defense needs always-on, automated detection rather than reactive manual work.

A caveat on currency: the 31.4 Tbps figure is the most recent known record as of the research cutoff in early 2026. Since Cloudflare reported new highs in quick succession, this state of affairs can be superseded quickly.

The Mirai botnet as a case study

If a single botnet stands for the IoT DDoS era, it is Mirai. The peer-reviewed USENIX study "Understanding the Mirai Botnet" (2017) provides unusually precise numbers that go well beyond the usual "botnets exist" level.

Mirai is worm-like malware that hijacks poorly secured IoT devices. The sequence: Mirai first scans random IPv4 addresses with fast, stateless TCP SYN scans on the Telnet ports 23 and 2323. On a hit, it performs a brute-force login using combinations from a hard-coded list of 62 default credentials, exactly the factory combinations that router and camera vendors ship en masse. Its predecessor BASHLITE made do with 6 usernames and 14 passwords.

The growth dynamics were striking: within the first 10 minutes, 11,000 devices were infected, and after 20 hours already 64,500. The peak in late November 2016 reached around 600,000 simultaneously infected devices. In total, Mirai was linked to over 15,000 attacks.

Three incidents made Mirai famous:

• KrebsOnSecurity, September 21, 2016: an attack exceeding 600 Gbps, one of the largest documented at the time (this figure comes from Brian Krebs' own blog, cited by the USENIX study).
• Dyn, October 21, 2016: the attack on the DNS provider Dyn knocked numerous well-known websites offline, because their name resolution stopped working.
• Deutsche Telekom, November 26, 2016: a Mirai variant tried to hijack routers via the CPE WAN Management Protocol (TR-069/CWMP, port TCP/7547). Deutsche Telekom's Speedport routers were not actually vulnerable to the exploit, so the infection attempt failed, but the flood of malformed requests overwhelmed roughly 900,000 routers and knocked them offline as collateral damage. The perpetrator responsible was arrested in February 2017.

The lesson from Mirai is uncomfortably simple: the attack was only possible because millions of devices sat on the network with default passwords. Consistently changing factory credentials, applying firmware updates, and disabling unnecessary services would have starved the botnet of its foundation.

Detecting DDoS attacks

The sooner an attack is noticed, the sooner it can be contained. The following signs point to an ongoing DDoS attack, though any single one can also have a harmless cause.

• Unusual traffic spikes, especially when concentrated on a single endpoint, whereas legitimate traffic is normally broadly distributed.
• Geographic anomalies: a sudden surge from a region that usually supplies few users.
• Uniform request signatures: identical user agents, headers, or request patterns at scale, a hint of automated rather than organic traffic.
• CPU or memory maxed out without bandwidth being saturated, a typical sign of a Layer 7 attack.
• DNS resolution failures or a spike in "HTTP 503" responses.
• Slow or completely unreachable services with no obvious operational cause.

In practice this means: anyone without continuous monitoring and sensible per-endpoint thresholds often notices the attack only when customers complain. Logs should be correlated across the network, application, and CDN layers and streamed to a SIEM so that patterns surface early.

Defending against DDoS: concepts and runnable code

Effective defense is layered, because each attack class hits a different resource. We move from the conceptual building blocks to concrete, runnable configuration code. One important caveat up front: rate limiting on your own server helps against application layer floods, but not against large volumetric attacks. If the pipe to your data center is already saturated, your nginx never even gets a turn. Volumetric attacks therefore have to be caught further upstream, in the provider's network or at a scrubbing service.

The conceptual building blocks

• Anycast: the same IP address is announced at many geographically distributed locations. Attack traffic automatically spreads to the nearest data center, so no single location bears the full load. Cloudflare mitigated the 7.3 Tbps attack automatically across 477 data centers in 293 locations.
• Scrubbing centers: all traffic is routed through specialized cleaning centers that filter out malicious traffic and forward only legitimate traffic to the origin.
• CDN and origin concealment: a content delivery network caches static content at the edge and hides the real IP of the origin server, so it cannot be attacked directly.
• Blackhole routing: an emergency measure that routes all traffic to the attacked IP into a "black hole" (a null route) and discards it. It stops the attack but also locks out all legitimate users, so explicitly a last resort.
• BGP Flowspec and Remotely Triggered Blackhole (RTBH): allow filter rules or blackhole instructions to be distributed dynamically via BGP to upstream providers, ideally arranged with the ISP in advance.
• Ingress filtering per BCP 38 (RFC 2827): the foundational measure against spoofed source addresses. Network operators should only forward packets at their edges whose source address matches the address range they are actually responsible for. This eliminates spoofing, and with it the basis of reflection attacks, and significantly hampers obfuscation. The standard dates from 2000 and remains the central anti-spoofing recommendation, referenced even by the CISA amplification advisory.

Rate limiting with nginx (Layer 7)

Against HTTP floods, a rate limit per source IP is an effective and simple measure. The nginx module ngx_http_limit_req_module works on the "leaky bucket" principle. The following base configuration is taken verbatim from the official nginx documentation:

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

    ...

    server {

        ...

        location /search/ {
            limit_req zone=one burst=5;
        }
    }
}

limit_req_zone creates a shared memory zone named one (10 MB) in the http context and limits requests to one per second per IP address. The key $binary_remote_addr is deliberately preferred over $remote_addr, because the binary form always occupies just 4 bytes (IPv4) or 16 bytes (IPv6), keeping the memory footprint exactly predictable. burst=5 allows short spikes of up to five additional requests, which are processed with a delay; anything beyond that is rejected with status code 503.

If you want spikes passed through immediately with no delay, add nodelay:

limit_req zone=one burst=5 nodelay;

In practice you often stack several zones, for instance a strict per-IP limit and a more generous per-server-name limit:

limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s;
limit_req_zone $server_name zone=perserver:10m rate=10r/s;

server {
    ...
    limit_req zone=perip burst=5 nodelay;
    limit_req zone=perserver burst=10;
}

SYN cookies and iptables (Layer 3/4)

Against SYN floods, first enable SYN cookies on Linux. The kernel then encodes the connection state in the sequence number instead of reserving memory for each half-open connection:

# Enable immediately
sysctl -w net.ipv4.tcp_syncookies=1

# Persist in /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
sysctl -p

You can additionally rate-limit new SYN packets with iptables. The following rule pair accepts, on average, one new SYN per second with a short buffer of three and drops the rest:

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Tune the values to your legitimate load, since limits that are too strict will lock out real users. For high-traffic services, per-IP limits with the hashlimit module are the better choice.

Detecting amplification traffic with Snort

Reflection attacks can be spotted, among other ways, by the arrival of large UDP responses without a matching prior outbound request (stateless UDP traffic). The CISA advisory TA14-017A includes a Snort rule example that alerts on exactly this case. It is reproduced here closely following that advisory and, per the advisory, must be adapted to your own environment with a whitelist of known services:

var HOME_NET [10.10.10.20]

preprocessor stream5_global: track_ip yes, track_tcp yes, track_udp yes, track_icmp no, max_tcp 262144, max_udp 131072
preprocessor stream5_ip: timeout 180
preprocessor stream5_tcp: policy first, use_static_footprint_sizes
preprocessor stream5_udp: timeout 180, ignore_any_rules

alert udp HOME_NET 1024: -> any any (msg:"UDP Session start"; flowbits:set,logged_in; flowbits:noalert; sid: 1001;)
alert udp any any -> HOME_NET 1024: (msg:"UDP Stateless"; flowbits:isnotset,logged_in; sid: 1002)

The logic: the first rule tags a UDP session originating from inside (HOME_NET) with a flowbit. The second rule fires when a UDP response arrives from outside to a high port in your network without that flowbit being set, that is, without a preceding outbound request of your own.

Immediate actions during an attack

When an attack is underway, a structured approach matters more than frantic one-off moves. A proven sequence:

1. Activate a crisis team: IT, security leads, management, and communications coordinate the response. Document affected systems and suspicious IP addresses cleanly; this helps later with analysis and possible prosecution.
2. Contact your provider and upstream: ISPs and scrubbing services can filter malicious traffic at the network level before it reaches your systems. Keep emergency contacts at hand before the incident happens.
3. Harden your servers: limit connections per IP, enable SYN cookies, restrict traffic to necessary ports (such as 80 and 443), and selectively blackhole obviously malicious sources.
4. Analyze the attack pattern: firewalls and mitigation systems can filter precisely based on recurring patterns in HTTP headers.
5. Bring in external specialists: if internal capacity is not enough, certified incident response providers should assist.

Preventively: inventory critical services, write emergency plans and runbooks per attack type, segment the network, monitor continuously, and keep specialized DDoS protection in place before you need it.

A note on legality

Note: the following is a general orientation, not legal advice. The precise legal assessment of any specific case rests with courts and prosecutors and depends on the circumstances.

DDoS attacks are a criminal offense in most jurisdictions, and so is renting or operating booter and stresser services. In the United States, unauthorized attacks are typically prosecuted under the Computer Fraud and Abuse Act (CFAA); in the United Kingdom, under the Computer Misuse Act; and in Germany, as computer sabotage under Section 303b of the Criminal Code (StGB). The specific statute, thresholds, and penalties differ by country, so the exact framing here should be verified against the law applicable to your case.

Booter and stresser services are not a legal gray area, despite marketing themselves as "stress testing" tools. According to secondary reports, law enforcement has repeatedly taken down such platforms and identified their users through the international "Operation PowerOFF". That figure comes from secondary sources rather than an official primary release, so the exact numbers should be treated with caution.

Frequently asked questions about DDoS attacks

What is the difference between DoS and DDoS?

A DoS attack comes from a single source and can usually be stopped by blocking that source. A DDoS attack spreads the load across many sources (a botnet), so simple IP blocking is no longer enough.

Can a DDoS attack be prevented entirely?

It cannot be prevented completely, but it can be mitigated effectively. A combination of anycast, scrubbing, CDN, rate limiting, and a prepared incident response substantially reduces both the likelihood and the impact.

Is a firewall enough against DDoS?

No. A classic firewall filters known malicious patterns but is of little use against large volumetric attacks (which saturate the pipe already) and against Layer 7 attacks disguised as legitimate. That requires specialized, preferably upstream, mitigation.

Are short attacks harmless?

No, quite the opposite. The most recent record attacks lasted only 35 to 80 seconds. Such short bursts are deliberately designed to strike before a manual response can react. That is exactly why always-on, automated defense is decisive.

Is it illegal to launch a DDoS attack?

Yes. Launching an unauthorized DDoS attack is a criminal offense in most jurisdictions, and so is renting or operating booter and stresser services. In the United States it is typically prosecuted under the Computer Fraud and Abuse Act (CFAA), in the United Kingdom under the Computer Misuse Act, and in Germany as computer sabotage under Section 303b of the Criminal Code (StGB). This is a general orientation and not legal advice, and the exact statute and penalties depend on the country and the circumstances.

Conclusion

DDoS attacks are no longer a fringe phenomenon but an everyday, industrialized tool, with tens of millions of incidents per year and records that outdo each other every few months. To understand them, you have to keep the three classes apart: volumetric attacks saturate bandwidth (with amplification factors up to 51,000 times for Memcached), protocol attacks exhaust connection tables, and Layer 7 attacks hit the expensive work of the application. The HTTP/2 Rapid Reset attack shows how abusing a single protocol detail can break new records with just 20,000 bots.

The good news: defense is mature. Ingress filtering per BCP 38 takes away the basis of reflection attacks, SYN cookies neutralize SYN floods, rate limiting throttles HTTP floods, and anycast with scrubbing spreads even terabit attacks across hundreds of locations. The key is to have these building blocks prepared and automated before the attack arrives, because modern short bursts are over before a human can react.