How can organisations defend against a Slowloris attack?

How Slowloris Defense Actually Works

Slowloris is not a volume flood in the classic sense, it is a connection exhaustion tactic. The attacker keeps many HTTP sessions open by sending headers or request fragments very slowly, which ties up worker threads, file descriptors, or proxy resources. Defense therefore focuses on making “slow and incomplete” requests expensive for the attacker and cheap for the server.

The most effective controls are timeout discipline, connection limits, and front-end infrastructure that can absorb or terminate malformed sessions before they reach the origin. In practice, this means tuning request-header and request-body timeouts, limiting keep-alive abuse, and ensuring the web tier does not let one incomplete session monopolise capacity.

What To Tune First in Web and Reverse-Proxy Layers

The first place to look is the component that actually holds the connection open. If the web server, load balancer, or reverse proxy waits too long for headers, a Slowloris pattern can consume capacity without ever completing a valid request. Tightening those waits is usually the fastest and least disruptive hardening step.

Connection caps matter just as much as timeouts. Per-IP limits, per-virtual-host limits, and global concurrent-connection ceilings reduce the blast radius of a single source or botnet node. If your edge stack supports it, put the throttling and timeout logic at the front door rather than relying on the application server to discover the problem late.

Infrastructure choices also change the outcome. A CDN, reverse proxy, or scrubbing service can terminate abusive sessions closer to the attacker, while anycast and distributed front ends can spread the load so one site does not become the bottleneck. For broader DDoS planning, DDoS Protection Guide covers the same front-end controls in a wider mitigation runbook.

How to Spot Slow Connections Before They Become an Outage

Slowloris is most visible in the shape of the traffic, not the content. Look for many half-open or very long-lived HTTP sessions, repeated header stalls, low request completion rates, and a concentration of incomplete connections from the same source ranges, user agents, or access patterns. These signals often appear before user-facing errors start to spike.

Detection should be tied to resource exhaustion, because the real failure condition is not the slow request itself but the depletion of concurrency. If you see thread pools, connection tables, or proxy workers flattening while actual request throughput stays low, you are likely looking at an application-layer exhaustion pattern rather than a normal traffic surge.

For incident handling, keep an eye on whether the pressure is at the edge or at the origin. If the reverse proxy is absorbing the attack cleanly, the origin may look healthy even while the front door is at risk. That distinction matters when deciding whether to block sources, raise timeouts, or move traffic behind stronger front-end protection.

Risk and Threat Considerations

Slowloris is attractive because it exploits an assumption many web stacks still make: that clients will finish requests promptly. When that assumption is wrong, a relatively small number of slow sessions can consume disproportionately large amounts of server capacity and create a denial of service without high bandwidth.

Failure mechanism: The attacker holds connection state open just long enough to consume workers, sockets, or proxy slots, then repeats the pattern across many sessions or sources. If timeouts are lenient and connection limits are loose, the service can degrade even when normal request volume is modest.

Impact: Users experience stalled logins, failed page loads, or complete unavailability, and the service may be forced into emergency throttling or restart actions. In environments with shared front ends, the attack can also mask itself as ordinary latency until capacity is already exhausted.

Practitioner Guidance

What to prioritise: Start with the control that closes the longest-lived incomplete sessions, then verify that the proxy or load balancer enforces its own ceilings before traffic reaches the application tier. If only the origin is hardened, an attacker can often shift the pressure outward and keep the service unstable.

What to verify: Confirm the environment has separate timeout behaviour for headers, body uploads, and idle keep-alive connections, because a single generic timeout often leaves one of those paths too permissive. Also verify that monitoring can distinguish completed requests from stalled sessions, not just total request count.

Practitioner takeaway: Slowloris defense is mostly about refusing to keep expensive state for incomplete requests, so the best posture combines short time-to-complete rules with front-end capacity controls and clear visibility into stalled connections.

Related resources from NHI Mgmt Group

• How should organisations defend against attack-as-a-service identity fraud?
• What should organisations do first when they are trying to defend against common attack paths instead of only headline-grabbing threats?
• How can organisations defend against the Kaseya VSA attack?
• How can organisations defend against a SolarWinds-style supply chain attack?