DDoS Low And Slow Attack

Low and slow attacks in context

A low and slow DDoS attack is an availability attack that uses relatively modest traffic to hold scarce server resources for a long time. Instead of sending an obvious flood, the attacker keeps connections, requests, or application tasks open in ways that consume worker slots, memory, file descriptors, database sessions, or other limited capacity.

The phrase is commonly associated with slow HTTP attacks, including Slowloris-style behaviour, but the broader idea applies wherever a small number of long-lived or expensive interactions can block legitimate users. A web server, reverse proxy, application framework, API gateway, or backend service may all have limits that are reasonable during normal traffic but fragile when many slow interactions accumulate.

Low and slow attacks are dangerous because they can look underwhelming on high-level dashboards. Bandwidth may be normal. Request counts may not spike dramatically. Yet users see timeouts because the application has run out of something more specific than bandwidth.

Why they are hard to spot

Many DDoS playbooks are built around sudden volume: more packets, more requests, more bytes, more sources. Low and slow attacks exploit the gaps in that view. They may involve fewer clients, slower request completion, long connection lifetimes, unusual header or body timing, or repeated access to routes that keep application work pending.

The symptoms can resemble ordinary performance problems. A deployment issue, slow database query, overloaded worker pool, misconfigured keepalive setting, broken client, or third-party dependency can all produce similar user complaints. Defenders should avoid jumping to conclusions. The task is to determine whether slow resource consumption is accidental, organic, or intentionally induced.

Another challenge is that the traffic may be mixed with legitimate users. Real users on poor networks can have slow connections. Mobile clients may pause or retry. Large uploads or streaming responses may be valid. Controls that punish every slow client can create accessibility and user-experience problems. The better approach is to combine timing signals with route sensitivity, session behaviour, request completeness, and service health.

Resources that get exhausted

Low and slow attacks often target connection and concurrency limits. If a server allows a fixed number of active connections or workers, holding many of them open can prevent new legitimate requests from being handled. In application stacks, the constrained resource might be a thread pool, process pool, event loop capacity, queue, database connection pool, cache lock, upload handler, or upstream socket.

Some routes are more sensitive than others. A static page served from cache may tolerate slow clients well. A dynamic search, report export, login flow, checkout step, or API endpoint that waits on backend work may have a higher cost. When many slow or incomplete interactions concentrate on those routes, the effect can be disproportionate to the apparent traffic size.

Resource exhaustion can also cascade. If frontend workers are held open, health checks may fail. If database connections are exhausted, unrelated routes can degrade. If queues fill, background tasks fall behind. If monitoring depends on the same saturated system, responders may lose visibility exactly when they need it.

Indicators to watch

Defender-relevant indicators include rising active connections without matching completed requests, long request durations, many partially completed requests, slow request body or response transfer patterns, increasing worker occupancy, connection pool saturation, queue growth, and timeouts at the application or proxy layer. Error rates may rise only after capacity is nearly exhausted, so early warning should include resource utilisation and duration metrics.

Log analysis should compare request start times, completion times, endpoints, response sizes, authentication state, and client characteristics. A small number of sources holding unusually many long-lived sessions may point to concentrated abuse. A larger distributed pattern with similar timing may point to coordinated automation. In both cases, route context matters. Slow behaviour against a high-cost dynamic endpoint is more suspicious than slow behaviour on a large download that users legitimately request.

Network and application teams should share evidence. Network teams may see connection lifetimes and source distribution. Application teams may see worker saturation, database waits, and route-level delays. Neither view alone is enough to understand the full incident.

Defensive concepts

Low and slow mitigation is usually about bounding resource use without blocking ordinary slow users. Useful concepts include sane connection and request timeouts, limits on incomplete requests, per-route concurrency controls, request body size limits, queue protection, bot and automation detection, cache strategy, origin shielding, and backpressure when downstream services are saturated.

Timeouts should be deliberate rather than arbitrary. If they are too loose, attackers can hold resources cheaply. If they are too aggressive, legitimate users on slower networks may be harmed. The right settings depend on the route and business function. Upload endpoints, checkout flows, admin tools, and public content should not all share the same assumptions.

Rate limiting can help, but request count alone may miss the issue. A client making few requests can still consume excessive time or concurrency. More useful controls consider active connections, request duration, incomplete request behaviour, endpoint cost, session posture, and historical norms. For authenticated services, account-level and token-level context may be more reliable than IP alone.

Architectural choices also matter. Caching public content, moving expensive work to controlled queues, isolating critical pools, and designing graceful degradation can reduce the blast radius. If one route becomes slow, it should not consume all resources needed for login, status, support, or administrative recovery.

Misconceptions

One misconception is that low and slow attacks are not serious because traffic volume is low. The attack is about scarce resource occupancy, not raw bandwidth.

Another misconception is that more origin capacity always solves the problem. More capacity can help, but it can also hide the issue until the next threshold is reached. Without resource limits and visibility, the same pattern may scale with the infrastructure.

A third misconception is that all slow clients are attackers. Real-world networks are messy. Defensive policy should focus on harmful patterns, route cost, repeated behaviour, and service impact rather than treating latency itself as proof of abuse.

Runbook and post-incident review

A low and slow runbook should identify the metrics that reveal resource occupancy: active connections, workers, request duration, incomplete requests, queues, database pools, and upstream wait times. It should also name the routes that can consume scarce resources and define who can adjust timeouts, concurrency, rate policy, caching, and application feature flags during an incident.

During response, teams should watch for both recovery and collateral damage. If a timeout change restores worker availability but breaks legitimate uploads or checkout, it may need route-specific tuning. If a block rule removes one source but the saturation continues, the attack may be distributed or the root cause may be internal.

After the incident, review which resources were exhausted first, whether alerts fired early, whether logs captured enough timing detail, and whether expensive routes can be redesigned or isolated. Low and slow resilience comes from understanding the application's resource model. Once teams know what can be held open, for how long, and at what cost, they can build controls that keep legitimate slow users served while denying abuse the ability to quietly occupy the service.