R U Dead Yet? (RUDY) is a slow HTTP denial-of-service attack that keeps many web server connections open for as long as possible. It sends headers and form data very slowly, tying up worker threads or connection slots until the server stops serving other users.
What R U Dead Yet? (RUDY) Means in Practice
R U Dead Yet? (RUDY) is a slow HTTP denial-of-service attack that holds web connections open by dribbling headers or form data slowly, exhausting worker threads or connection slots so legitimate users cannot get served.
The technique is effective because it targets how many web servers and reverse proxies manage concurrent requests, not just raw bandwidth. A small number of well-timed connections can create disproportionate queueing and starvation when the server waits on incomplete request bodies.
RUDY is often discussed alongside other application-layer denial-of-service techniques, but its defining trait is persistence at the protocol level. The attacker is not flooding the network, they are stretching the request lifecycle until the server runs out of capacity for normal traffic.
How RUDY Starves Web Servers
RUDY works by abusing long-lived HTTP request handling. If the application stack allocates a thread, process slot, or upstream connection for each partially completed request, those resources remain unavailable until the request finishes or times out.
This makes the attack especially relevant for environments with limited concurrency, expensive request parsing, or weak timeout discipline. Even when overall traffic volume looks modest, the server can become functionally unavailable because the available execution pool is pinned by incomplete connections.
Modern architectures can reduce the impact, but they do not eliminate the core issue. Load balancers, application gateways, and proxies still need sane limits on header time, body upload time, idle connection time, and per-client concurrency to avoid becoming part of the bottleneck.
Why Slow HTTP Attacks Are Hard to Notice
Slow HTTP attacks can blend into ordinary web activity because the traffic pattern does not always look obviously malicious. The malicious connection may appear quiet, while the real effect is hidden in resource occupancy, queue depth, and request latency.
That makes basic network counters an incomplete defense. Operators need visibility into open connections, in-flight requests, worker saturation, timeout events, and abnormal ratios between accepted requests and completed responses.
Detection also depends on understanding the normal behavior of the application. Long uploads, streaming endpoints, and slow clients can resemble abuse unless the environment has baselines for expected request duration and connection lifetimes.
Controlling Exposure to RUDY
Exposure is highest where the application layer holds scarce resources open for too long and where timeouts are permissive. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps directly to access, monitoring, configuration, and availability controls that support resilient service operation.
Organizations should review where request-processing limits actually sit: at the edge proxy, the web server, the application server, and any upstream service that keeps state for incomplete requests. If those limits are inconsistent, the weakest hop often becomes the easiest place to exhaust.
Compensating controls matter when application changes are slow. Connection caps, body-read deadlines, header parsing limits, rate limiting, and proxy buffering can all reduce the effectiveness of long-lived partial requests without changing the application itself.
Response and Recovery After a RUDY Event
When a RUDY attack is suspected, the operational question is not only whether the site is slow, but whether resource exhaustion is being driven by a small set of persistent connections. NIST Cybersecurity Framework 2.0 is a useful reference for organizing monitoring, response, and recovery around service availability.
Recovery usually means more than restarting a server. Teams may need to drop abusive connections, tune timeout thresholds, add edge enforcement, and verify that caches, gateways, and autoscaling policies are not masking the underlying saturation pattern.
After service is restored, review logs and connection telemetry for patterns that show whether the attack was sustained, distributed, or paired with other application-layer abuse. That review helps determine whether the next step is tuning, architectural hardening, or upstream mitigation.
Risk and Threat Considerations
RUDY is dangerous because it can create denial of service without high bandwidth or obvious volumetric spikes. The threat is especially effective against servers that tie up scarce worker capacity while waiting on incomplete requests, or that lack strict timeout and concurrency controls.
Failure mechanism: The attacker opens many connections and sends request data slowly enough that each connection stays active while consuming thread, process, or session capacity until legitimate users are crowded out.
Impact: The site degrades or becomes unavailable for normal traffic, even though upstream links may still look healthy and packet volume may not appear extreme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | RUDY is a DoS technique that consumes service capacity through long-lived requests. |
| SI-4 — System Monitoring | Detection depends on spotting abnormal connection longevity and worker saturation. | |
| Recommendation — Enforce DoS protections and connection limits to prevent slow-request resource exhaustion. Monitor in-flight requests and connection duration for slow-HTTP abuse patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find anomalies, indicators of compromise, and other potentially adverse events | RUDY is detected through anomalous service behavior and connection patterns. |
| PR.DS-4 — Data-at-rest is protected | No materially direct alignment exists. | |
| Recommendation — Monitor web-service behavior for anomalous long-lived connections and request stalls. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Edge and proxy limits are central to reducing exposure to slow HTTP attacks. |
| Recommendation — Harden and tune network-facing controls that enforce connection and timeout limits. | ||
Practitioner Guidance
What to watch for: Treat unusually high numbers of long-lived partial requests, rising worker saturation, and uneven completion times as operational warning signs. Those indicators are often more revealing than raw request rate during a slow HTTP event.
Governance implication: Ownership should be clear across the edge, web tier, and application tier, because the most effective mitigation usually depends on coordinated timeout, buffering, and connection-management decisions rather than a single control.
Related resources from NHI Mgmt Group
- How do security teams reduce the impact of dead drop infrastructure and multi-stage payload delivery in supply chain attacks?
- What breaks when organisations do not automate detection of dead code and unused components?
- What breaks when customer registration has too many fields or dead ends?
- Why do dead code and null pointer dereferences create so much operational risk in modern codebases?