R U Dead Yet RUDY

RUDY in the slow-attack family

R U Dead Yet, commonly shortened to RUDY, is a named example of a low and slow application-layer denial-of-service technique. It is associated with HTTP requests that keep server-side resources occupied for an unusually long time, especially around forms or request bodies. This page discusses the risk from a defensive perspective only and does not describe how to run or reproduce the attack.

The important idea is resource occupancy. A high-volume DDoS attack tries to overwhelm a service with obvious traffic. A slow attack can create harm with far less visible volume by holding connections, workers, upload handlers, request parsers, or backend tasks open. If enough of those resources are occupied, legitimate users may wait, time out, or fail even while bandwidth and request-count dashboards look normal.

RUDY belongs in the same operational conversation as Slowloris-style attacks and other slow HTTP behaviours. The exact label matters less than the symptom: clients that appear to be doing something incomplete or very slow, while the server keeps reserving capacity for them.

Why application-layer cost matters

Web applications often treat an active request as a promise that useful work is underway. They may allocate a worker, keep a socket open, reserve memory, wait for a body to arrive, hold a request object, or prepare downstream work. Those choices are reasonable for real users, including people on slow mobile networks or customers uploading valid data. They become risky when many slow or incomplete interactions accumulate.

The most sensitive routes are usually the ones that accept input or trigger dynamic work. Contact forms, search, login, checkout, file upload, account management, and API endpoints can cost more than static content. A public content page served from cache may be cheap. A request that waits on application code, validation, database access, or third-party services may be expensive even before it fully completes.

This is why RUDY-style risk is not solved by bandwidth alone. The constrained resource is often concurrency, request duration, or application worker availability. More servers can help, but without sensible limits the same slow pattern can scale with the fleet.

Signals defenders should collect

Useful indicators include rising active connections, long request durations, many incomplete request bodies, increased worker occupancy, growing queues, upload handlers staying busy, connection pools filling, and a widening gap between started requests and completed responses. Error rates may rise only after the service is already close to exhaustion.

HTTP logs should be reviewed for endpoint concentration, request duration, bytes received, response status, authentication state, session behaviour, and whether the same sources or user agents repeatedly leave work incomplete. Network logs can add connection lifetime and source distribution. Application metrics can reveal the resource that is actually scarce.

The absence of a large request spike is not proof that no attack exists. A slow attack may produce fewer requests than normal peak traffic while still causing severe user impact. Conversely, slow clients are not automatically malicious. Real users may have weak connections, accessibility tools, large uploads, or interrupted mobile sessions. Defensive decisions should combine timing, route cost, repetition, and service impact rather than judging latency alone.

Controls that reduce slow-body risk

Defensive controls should bound how long and how cheaply a client can occupy scarce resources. Useful concepts include request and header timeouts, limits on incomplete request bodies, maximum body sizes appropriate to each route, connection limits, per-route concurrency controls, queue protection, and backpressure when downstream systems are saturated.

Route-specific policy is important. A newsletter signup form, file upload endpoint, checkout step, and public article should not all share the same assumptions. Routes that legitimately accept larger or slower submissions may need authentication, progressive validation, separate worker pools, or clearer limits. Routes that do not need request bodies should reject unexpected body behaviour early.

Caching and origin shielding can reduce pressure on dynamic infrastructure, but they are not complete controls for form and upload paths. Bot and automation detection can help identify repeated slow behaviour, especially when combined with session context, reputation signals, and expected user journeys. Rate limiting can also help, but request count alone may miss clients that make few requests while holding them open for a long time.

Evaluating resilience

Evaluation should start with the application resource model. Which endpoints hold workers while waiting for input? Which routes accept large bodies? Which systems have fixed concurrency pools? Which queues or database pools can be indirectly exhausted by incomplete or slow requests? Which dashboards show active work rather than only completed responses?

Safe testing should be authorised, scoped, monitored, and designed to validate controls without disrupting production. Teams can often learn a great deal from configuration review, staging tests, load-test reports, and timeout audits without attempting to recreate named attack behaviour against live public services.

Readiness also depends on ownership. During an incident, security teams may identify the pattern, platform teams may tune proxy settings, application teams may change route behaviour, and support teams may handle user communication. Those handoffs should be known before an outage.

Misconceptions

One misconception is that low bandwidth means low risk. RUDY-style pressure is about tying up server-side capacity, not filling the network pipe.

Another misconception is that generic rate limits are enough. A client can create harm through duration and incomplete work even with a low request count. Controls need to consider time, concurrency, route cost, and completion behaviour.

A third misconception is that all slow submissions are attacks. Some legitimate users are slow. Good policy should protect the service while preserving reasonable paths for real users, especially on critical business flows.

Response planning

A RUDY-oriented runbook should identify high-cost input routes, the metrics that reveal active and incomplete work, the safe emergency settings for timeouts and concurrency, and the people authorised to change them. It should also define how to watch for false positives, because overly aggressive controls can block real users filling forms, uploading documents, or completing checkout.

During response, focus on the first scarce resource. Is the bottleneck at the edge proxy, application worker pool, upload handling, database pool, queue, or a downstream service? Then apply controls as close to the pressure point as possible and verify both attack suppression and legitimate completion.

After the incident, review whether routes can fail faster, validate earlier, isolate expensive work, or expose better metrics. RUDY is a useful lesson because it forces teams to think beyond traffic volume. Availability depends on how long each request can reserve scarce capacity and whether the application can distinguish patient users from harmful slow automation.