Denial of service

Not every attack wants your data. Some only want your service to stop. Remember the three goals in the first level: confidentiality, integrity, availability. A denial of service (DoS) attack goes after the last one. If customers cannot load the checkout page, it does not matter that the data is encrypted and correct.

Every service has a limit

A web server is a process (earlier lesson) that does work for each request: it accepts a connection, reads bytes, maybe queries a database, writes a response. That work consumes finite things:

• Bandwidth: how much data the connection can carry.
• CPU time: how much computing it can do per second.
• Memory: what it must hold for each open request.
• Connections or worker slots: how many things it can handle at once.

Normal use stays well within those limits. A DoS attack pushes one of them to the ceiling, and once it is full, new legitimate requests queue or fail. Nothing was broken into. The service simply ran out of something.

A shop with ten checkout lanes is a good picture. A crowd of a thousand people who join the queue and buy nothing blocks real customers without stealing a thing.

Two families

Volumetric floods send a huge amount of traffic to fill the pipe. They need brute strength, which is why attackers use many machines. A distributed attack, or DDoS, comes from thousands of sources, often a botnet of compromised devices, so there is no single address to block.

Cheap-request attacks exploit asymmetry: a request that costs the attacker almost nothing but costs the server a great deal. Examples include a search that triggers a heavy database scan, a request that makes the server open a slow connection and hold it, or an input that makes a function take far longer than expected. The attacker needs far less traffic because every message is expensive for you.

The second family is a design problem as much as a security one. Any endpoint where small input leads to large work is a candidate.

Real case: HTTP/2 Rapid Reset

Modern browsers speak HTTP/2, which carries many requests at once, called streams, over a single connection. To protect servers, the protocol limits how many streams may be open at the same time. That limit is the safety cap.

The record describes it plainly: request cancellation can reset many streams quickly, exploited in the wild in August through October 2023, rated 7.5 and listed under CWE-400, uncontrolled resource consumption. Here is the mechanism in plain steps.

1. The client opens a stream, which is a request, and the server starts working on it.
2. The client immediately sends a reset, which cancels it. A cancelled stream no longer counts against the open-stream limit.
3. The client opens another, and cancels that too, and so on, thousands of times a second.

The cap counts open streams, but the server had already begun processing each request before it was cancelled. So a single connection could force a stream of work, and the cap that was supposed to bound it did not. The fault is a classic one: a limit measured on the wrong thing. It was a flaw in the protocol's design as much as in any one product, which is why so many HTTP/2 servers and proxies needed fixes. It is on CISA's list of known exploited vulnerabilities, with the mitigation advice in the record.

Defences, in layers

No single control stops all denial of service, so defenders stack several:

Rate limits deserve one caution. A limit per IP address can be dodged by a botnet, and can block many real people behind one shared address. Limits per account or per API key are stricter but only work for authenticated traffic.

How AI changes this

Attackers. Floods need machines, not intelligence, so AI adds little to the volume. Where it may help is finding cheap-request weaknesses: probing an application to learn which input is most expensive. That is the same discovery speed-up we see elsewhere, not a new class of attack.

Defenders. Telling a flash crowd from an attack, and drafting the right filter, are pattern tasks where assisted analysis helps, as long as a human confirms before blocking real customers.

Agents as a new actor. Two things are new. First, AI services are expensive per request, so they are natural cheap-request targets, and the cost can land as money. Our dictionary calls it denial of wallet. Second, self-hosted model servers have ordinary availability bugs: our post on two vLLM denial-of-service CVEs describes requests that can crash a multimodal server, which means an agent that depends on that endpoint stops working. The advice is the same as above: restrict who can reach it, set limits, and patch.

An agent can also cause an accidental denial of service by itself. A script it writes may loop and hammer an API or a database with thousands of calls. Rate limits protect you from your own tools, not only from attackers.

Try it

This simulates a rate limiter in plain Python. Nothing touches a network.

Save as limiter.py in a scratch folder:

import time

class TokenBucket:
    """Allows `rate` requests per second, with bursts up to `burst`."""
    def __init__(self, rate, burst):
        self.rate, self.burst = rate, burst
        self.tokens, self.last = burst, time.monotonic()

    def allow(self):
        now = time.monotonic()
        self.tokens = min(self.burst, self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

bucket = TokenBucket(rate=5, burst=10)
allowed = sum(bucket.allow() for _ in range(1000))
print("allowed", allowed, "of 1000 in an instant burst")
time.sleep(1)
print("after one second, allowed:", sum(bucket.allow() for _ in range(1000)))

Run it. A burst of 1000 requests gets about 10 through, and a second later about 5 more. Change rate and burst and predict the output before running. Delete the file afterwards.

Check yourself

Next

You can now keep a network small, keep it patched and keep it up. The next lesson is about seeing: detection and logging, and how to notice an attack while it is happening.