DDoS Attacks Explained: What Runs Out First

A denial-of-service attack has no clever payload. Nothing is stolen. Often nothing is even exploited. The target keeps working perfectly for the traffic it can serve, and then more demand arrives than it has supply, and the supply runs out.

That framing is more useful than any list of attack names, because it tells you where to look. Something specific gives way first, and whatever gives way decides whether the answer lives in your server config, your provider's network, or somewhere you do not control at all.

What makes an attack distributed#

One machine sending too much traffic is a problem with a short solution: block the address. It is also self-limiting, because the attacker's own connection sets the ceiling on how much they can send.

Distributing the attack removes both limits. The traffic arrives from many sources, each sending an unremarkable amount, and no single address is worth blocking. Attackers get that spread in two ways. They compromise devices and run the attack from them, or they borrow uninvolved servers and get those servers to send the traffic for them.

The first route is the classic botnet, and the recruiting is usually less sophisticated than people assume. RFC 8576, the IETF's write-up of IoT security considerations, describes the well-known Mirai case in one sentence: the attack "was caused by things that had well-known or easy-to-guess passwords for configuration." Cameras, routers, and recorders shipped with defaults nobody changed, and a scanner found them at internet scale.

The scale that produces is worth stating concretely. When GitHub was hit in February 2018, its incident report describes traffic arriving from "over a thousand different autonomous systems (ASNs) across tens of thousands of unique endpoints." No firewall rule fits that shape.

Three things an attack can exhaust#

RFC 4732 surveys denial-of-service by mechanism and by the resource an attacker drains, rather than by brand name, and running through memory, CPU, connection limits, and routing capacity in turn. Three of those cover most of what you will meet.

• Bandwidth. The link filling up in front of your server. Packets are dropped upstream of you, so nothing configured on the machine itself changes the outcome.
• Connection state. Memory, sockets, and tracking tables. The server has CPU to spare and still cannot accept a new connection, because the bookkeeping for connections is full.
• Application work. Requests that are cheap to send and expensive to answer. A search query, a report, a page that hits the database several times.

Sorting an incident into one of those three tells you who can fix it. Only the second is really yours.

SYN floods and the half-open connection#

The state-exhaustion case has a canonical example, and RFC 4987 documents it in detail. Opening a TCP connection takes three messages: the client sends a SYN, the server replies SYN-ACK, the client confirms with an ACK. Our post on TCP vs UDP covers why TCP does this and UDP does not.

A SYN flood sends the first message and never sends the third. The server, having no way to know yet, does what the protocol requires: it remembers the half-open connection and waits. Each one costs a Transmission Control Block, a structure the RFC notes exceeded 1,300 bytes on Linux 2.6.10. Send enough and, in the RFC's words, "by keeping the backlog full of bogus half-opened connections, legitimate requests will be rejected."

The standard defence is elegant. SYN cookies, as RFC 4987 puts it, "go a step further and allocate no state at all for connections in SYN-RECEIVED." Rather than remembering the half-open connection, the server encodes what it would have stored into the sequence number it sends back, then rebuilds that state from the client's ACK if one ever arrives. No ACK, no cost.

It is a trade, not a free win. The RFC is direct that "commonly implemented schemes are incompatible with some TCP options," and describes squeezing the negotiated maximum segment size into two sequence-number bits representing four predefined values. That is why systems implementing SYN cookies typically leave them off by default, enabling them under high-stress conditions or by administrative action rather than running them always.

Reflection turns a small packet into a large one#

The bandwidth case usually involves neither the attacker's bandwidth nor their address. In a reflection attack, the attacker sends requests to public servers with the source address forged to the victim's, and every reply lands on the victim. The attacker never appears in the traffic the victim sees.

Amplification is the second half: pick services whose replies are much larger than the requests. UDP services with no handshake are the obvious candidates, since nothing verifies who asked. DNS on port 53, NTP on port 123, CLDAP on port 389, and memcached on port 11211 have all been abused this way. Our common ports cheat sheet covers what normally runs on each.

Even a 1983 protocol works. RFC 864 defines the Character Generator Protocol on port 19, where a UDP datagram gets back "a random number (between 0 and 512) of characters" and the sent data is ignored entirely. A near-empty packet in, up to half a kilobyte out.

Memcached showed how far that ratio can go. Cloudflare's analysis of the 2018 wave reported seeing "a 15 byte request result in a 750kB response (that's a 51,200x amplification)," which is roughly the ratio behind the GitHub incident: 1.35 Tbps at 126.9 million packets per second, sourced from memcached servers reachable over UDP. The uncomfortable detail is that memcached needed no bug for this. It listened on every interface with UDP enabled, by default, on servers that were never meant to face the internet.

Why source-address spoofing still works#

All of that depends on forging a source address, which the internet has had a documented answer to since 2000. RFC 2827, better known as BCP 38, asks networks to check what leaves them: "All providers of Internet connectivity are urged to implement filtering described in this document to prohibit attackers from using forged source addresses which do not reside within a range of legitimately advertised prefixes."

The mechanism is simple. A network knows which address ranges it is responsible for, so a packet claiming a source outside those ranges is provably lying and can be dropped where it originates. Our CIDR calculator expands any prefix into the exact address range it covers, which is the check a border router is doing.

Adoption is the problem. Filtering costs the network deploying it a little and benefits everyone else, and it is voluntary, so coverage has stayed partial for a quarter of a century. One unfiltered network is enough to launch from. BGP and internet routing covers how prefixes get announced in the first place.

Application-layer attacks are quiet#

Volumetric attacks are loud and easy to spot on a graph. Attacks on application work are the opposite: the requests are valid, the volume can look ordinary, and the only symptom is that the service is slow or down.

HTTP/2 Rapid Reset is the sharpest recent example. NVD describes CVE-2023-44487 as a case where "the HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023." Scored 7.5, high severity, and the campaign that used it produced request rates in the hundreds of millions per second.

Notice what was not the constraint. Bandwidth was fine. HTTP/2 multiplexing let a client open and immediately cancel streams faster than servers accounted for them, so a modest amount of traffic bought an enormous amount of server work. That is the general shape of application-layer attacks, and why rate limits by request count often miss them.

Reading the traffic afterwards#

Once an incident is over you are left with a log full of addresses, and it pays to be clear about what they mean. In a spoofed flood the source addresses are fiction. In a reflection attack they are real but they belong to the reflectors, which are victims of a sort themselves. In a botnet flood they are real and they belong to somebody's compromised camera.

What survives all three cases is the network each address sits in. Grouping by autonomous system turns thousands of unrelated addresses into a short list of operators, which is the level at which anything can actually be reported or blocked. Our ASN Explorer shows the organisation behind a number along with its announced prefixes, and what an ASN is explains why that grouping exists.

For the log itself, bulk IP lookup takes up to 100 addresses at once and returns geolocation and ASN for each, with CSV and JSON export for the pivot table you are probably about to build. IP reputation classifies a single address by infrastructure: our own datacenter and hosting ASN analysis plus Tor exit-node status, each signal labelled separately. It is honest about its scope, and worth repeating here. That is classification, not an abuse score, and none of it is mitigation. It tells you what you were hit by, after you were hit.

What actually reduces the damage#

Volumetric attacks are absorbed, not blocked, which means capacity in front of your origin. That is what a distributed edge network provides, and what a CDN is covers how the same architecture that speeds up delivery also spreads an attack across many locations instead of concentrating it on one.

Absorption only works if nobody can go around it. An origin address that leaks through old DNS records, certificate transparency entries, or a forgotten subdomain lets an attacker skip the protection entirely, so treat finding your own exposed origin as part of the work. For state exhaustion, know where your SYN cookie setting is before you need it. For application-layer pressure, rate-limit by cost rather than by request count, and cache what you can.

The last piece is the least technical. Know in advance who to call, because during an attack the useful decisions belong to your hosting provider or transit provider, and finding the right contact is not something to do at speed. Our response time checker sends HTTP probes to a host from whichever Cloudflare edge location handles the request, which gives you one outside vantage point on whether a service is still answering and how slowly.