Slowloris

How Slowloris Works

Slowloris is an application-layer denial-of-service technique that aims to keep server-side connections tied up for as long as possible while transmitting data very slowly. It is effective because many web servers and gateways allocate connection handling resources before a request is complete, so a small amount of traffic can consume disproportionate capacity.

The technique does not rely on high bandwidth or packet floods. Instead, it exploits the way some services manage concurrent connections and request timeouts, which makes it especially relevant to HTTP services and other networked applications that depend on limited worker pools, socket tables, or similar per-connection resources.

Why Slowloris Is Effective

Slowloris works best where a service assumes requests will either complete quickly or time out cleanly. By deliberately withholding full request completion, the attacker creates a resource pinning effect, each open connection remains useful to the attacker but costly to the target.

This makes the technique attractive against environments that have many exposed endpoints but modest connection capacity, such as reverse proxies, load balancers, application gateways, and older web stacks. The service may still appear reachable, yet real users experience long waits, failed logins, or stalled page loads because the available concurrency has been consumed.

Its danger is not only outage, but also deceptive degradation. Operators may see low traffic volume and underestimate the attack, even while legitimate requests are being denied because the server has run out of usable connection slots.

What Organisations Should Check

Exposure starts with knowing which systems accept untrusted client connections and how those systems enforce idle, header, and request-completion timeouts. Internet-facing web servers, API gateways, and middleware that terminate client sessions deserve the closest review because they are the most common choke points for this technique.

Capacity settings matter as much as patching. If one reverse proxy or gateway sits in front of many applications, a connection-exhaustion problem there can create a broad service impact that looks larger than the original target. This is why the operational question is not just whether the application is vulnerable, but whether the deployment path concentrates all client traffic through a small number of front doors.

A practical review should include vendor guidance for the specific server or proxy in use, since timeout handling, keep-alive behavior, and connection accounting vary across products. For wider hardening patterns, the DDoS Protection Guide covers the broader defensive model that Slowloris fits into.

Mitigation and Detection

Defence usually combines protocol tuning, traffic controls, and resilient front-end design. Shorter header and request timeouts, per-client connection limits, reverse proxies, load balancers, and rate limiting can all reduce the chance that a small number of slow connections monopolise service resources.

Detection should focus on abnormal connection longevity, incomplete requests, and rising concurrency with unusually low throughput. The useful signal is often a mismatch, many open sessions, little completed work, and no corresponding rise in normal business traffic. That pattern helps distinguish Slowloris from ordinary spikes in demand.

Post-incident review should also check whether the service recovered cleanly after the slow connections were dropped. If users remained unable to connect after the attack stopped, the issue may have exposed a deeper capacity, timeout, or proxy-configuration weakness rather than a one-off event.

Why It Matters for Service Availability

Slowloris is important because it shows that availability failures do not require large-scale traffic floods. A low-volume, resource-holding attack can still disrupt web services, authentication portals, admin consoles, and any application that depends on a finite pool of client-facing connections.

For practitioners, the key lesson is that connection management is part of availability design. If timeout policy, concurrency limits, and front-end buffering are weak, a service can be taken down by behavior that looks small in packet terms but large in operational effect.

Related resources from NHI Mgmt Group

• How do attackers use Slowloris?
• How can security teams detect Slowloris?
• What mitigations reduce the risk of Slowloris attacks?
• How can organisations defend against a Slowloris attack?