What Is a RUDY Attack?

A RUDY attack is a low and slow denial of service technique that opens a normal HTTP POST request, declares a large body in the Content-Length header, then delivers that body one byte at a time. Every unfinished request holds a server worker hostage, so a few hundred connections can flatten a web application while bandwidth graphs stay perfectly calm. That stealth is the entire design. This guide covers how the attack works at the protocol level, why volume-based defenses miss it, what it looks like in your logs, and which controls actually stop it. The first surprise is how little traffic it takes.

Key Takeaways

• RUDY, short for R U Dead Yet?, is an application-layer denial-of-service attack that abuses slow HTTP POST bodies rather than traffic volume.
• The attacker sends valid headers with an inflated Content-Length value, then trickles the body at roughly one byte every ten seconds.
• Each open request occupies a worker or thread, so connection pools fill long before bandwidth or CPU shows any strain.
• Thread-per-connection servers such as Apache with the prefork MPM fail fastest, since the default worker ceiling sits at 256.
• Volume-based DDoS defenses rarely trigger, because packet rates, request rates, and byte counts all look ordinary.
• Reliable mitigation combines request read timeouts, full request buffering at a proxy, per-client connection caps, and body-rate inspection.
• Slow HTTP weaknesses are testable, so measure your own timeout behavior in staging before an attacker measures it for you.

How a RUDY Attack Drains a Web Server’s Connection Pool

A RUDY attack works by exploiting a rule the HTTP specification requires servers to follow: when a client announces a request body, the server waits for that body to arrive. The attacker never breaks the protocol. It simply takes an absurdly long time to finish a request that looks entirely valid.

The sequence is short and repeatable. An attacking client finds a POST endpoint, usually a login form, a search box, a contact form, or a file upload path. It sends a complete and well-formed set of headers, including a Content-Length value in the millions. The server accepts the request, reserves a worker to read the body, and waits. Then the trickle starts, and only a DDoS protection service that judges requests by how long they hold a resource will treat any of it as hostile.

1. Open a TCP connection and complete the TLS handshake like any browser would.
2. Send full, valid POST headers with a Content-Length value far larger than the real payload.
3. Send the body in single-byte fragments, spaced around ten seconds apart with random jitter.
4. Repeat across hundreds of parallel sessions until the connection pool has no free slot left.

Public documentation of the tool notes that the byte intervals are deliberately irregular so the pattern does not look mechanical. That single detail defeats naive detection rules built on fixed timing.

Scale matters less than you would expect. Apache running the prefork MPM defaults to 256 simultaneous workers, and PHP-FPM pools are often configured with far fewer child processes than that. A single laptop on a home connection can occupy every one of those slots, which is why this attack is classified as denial of service rather than distributed denial of service. The same blind spot shows up across DDoS mitigation techniques that measure requests per second instead of request duration.

So if the traffic looks legitimate and the volume stays low, what exactly is supposed to raise the alarm?

Why RUDY Traffic Slips Past Volume-Based Defenses

RUDY evades most perimeter controls because every individual signal it produces falls inside normal ranges. The handshake is clean, the headers are valid, the request rate per client is tiny, and the total data transferred over an hour might be a few kilobytes.

A Layer 4 DDoS shield inspects connection setup and packet behavior, and it sees a completed three-way handshake followed by a well-behaved session. Nothing about that pattern resembles a flood. Rate limiters keyed to requests per second stay quiet too, since the attacker sends a handful of requests and then holds them rather than hammering the endpoint.

Logging makes the gap worse. Most web servers write an access log entry when a request completes, so a request held open for twenty minutes produces no log line for twenty minutes. Your dashboards can look healthy while the worker pool is already full.

You might be thinking that HTTPS or a modern event-driven server removes the risk. Encryption changes nothing here, because the attack rides inside a legitimate session. Event-driven servers such as nginx do absorb far more idle connections, yes, but the application tier behind them still has a finite pool, and any endpoint that streams the body straight through to an app server inherits the same exposure. MITRE catalogs this behavior under HTTP DoS, alongside other patterns that succeed with very few packets.

The next question is how RUDY differs from the slow attacks and floods your team probably already models.

RUDY vs Slowloris and Flood-Based Attacks

RUDY and Slowloris are siblings that attack opposite halves of the same request. Slowloris drips headers and never finishes them. RUDY finishes the headers cleanly and then drips the body. Floods, by contrast, try to overwhelm capacity with sheer volume.

That distinction changes your defense. A SYN flood attack is stopped by connection-level controls such as SYN cookies and backlog tuning, and volumetric floods are absorbed by capacity and scrubbing. Neither approach helps against a client that behaves perfectly except for being slow.

Notice the pattern in the traffic volume row. Two of these attacks are defeated by more bandwidth and two are not. That is the practical reason slow attacks keep working against organizations that spent their budget on capacity alone.

Warning Signs of a Slow POST Attack in Your Logs

The clearest indicator of a RUDY attack is a saturated connection pool paired with almost no CPU load, no disk activity, and no bandwidth increase. A busy server that is not actually doing any work is doing something unusual.

Watch for this cluster of symptoms:

• Connection counts in the ESTABLISHED state climb steadily and never fall back.
• Worker or thread utilization sits at its configured ceiling while CPU idles below 10 percent.
• A small number of client addresses account for a large share of open sockets.
• Requests concentrate on one or two POST endpoints, often a form the site rarely receives traffic on.
• Apache begins emitting 408 responses once read timeouts finally expire.
• Time to first byte rises across the whole site, including static pages that normally return instantly.

An edge security platform that scores connection duration and body delivery rate, not just request counts, is what turns this cluster of symptoms into an alert. Without duration awareness, the attack stays invisible until users start complaining.

Detection buys you minutes. Configuration buys you immunity, so the controls below matter more than any dashboard.

How to Stop a RUDY Attack Before It Reaches Your Origin

Stopping RUDY comes down to a single principle: never let a client decide how long your server waits. Four layers apply that principle in different places, and using them together closes the gap that any one of them leaves open.

1. Terminate and buffer requests at a reverse proxy. When a proxy reads the entire body before forwarding anything upstream, the slow client ties up a cheap proxy connection instead of an expensive application worker.
2. Set aggressive request read timeouts at the origin. Apache ships mod_reqtimeout with a default of header=20-40,MinRate=500 body=20,MinRate=500, so the body allowance grows only when the client actually delivers data at a reasonable rate.
3. Apply rate limiting to concurrent connections per client address, not only to requests per second. Duration is the resource being consumed, so duration is what your limits must cover.
4. Deploy a web application firewall with rules that inspect body delivery behavior, flagging sessions whose Content-Length promises megabytes while the socket delivers single bytes.
5. Cap request body size on every endpoint that does not need large uploads, which makes an inflated Content-Length value fail immediately instead of reserving capacity.

“Usually, a server should have both header and body timeouts configured”

The nginx documentation is explicit about a nuance that catches teams out: client_body_timeout applies between two successive read operations, not to the transfer of the whole body. An attacker who sends one byte just inside every window resets that clock forever. Pairing the timeout with a body size cap and a per-client connection cap is what finally closes it.

Run slow HTTP tests against staging only. Opening hundreds of held connections against a production endpoint is an outage you caused yourself, not a security check.

Testing Your Stack for Slow HTTP Weaknesses

You can measure your exposure directly, because slow HTTP behavior is deterministic. Tools such as slowhttptest open a controlled set of slow POST sessions and report how long the target keeps serving other clients.

Run the test against a staging environment that mirrors production worker counts, proxy configuration, and timeout values. Record the number of connections needed to degrade service, then repeat after each hardening change so you hold evidence rather than assumptions. If staging survives 500 slow sessions and production runs half the workers, you have learned something important about production.

Final Thought on RUDY Attacks

RUDY is a reminder that availability attacks do not need scale. They need patience and a server willing to wait. The defense is not more bandwidth or a bigger instance; it is a firm limit on how long any single client may hold a resource, enforced at the edge and repeated at the origin.

Treat request duration as a first-class metric alongside request rate. Set timeouts deliberately, buffer bodies at a proxy, cap concurrent connections per client, and inspect body delivery behavior at the application layer. Those four controls cost very little to configure, and they remove an entire class of denial of service from your risk register.

Common Questions About RUDY Attacks