Slowloris and Slow HTTP Attacks

What it exhausts

Concurrent connection slots. Not bandwidth, not packet rate, not CPU — just the finite number of connections a server will hold at once.

The attack works by starting a request and never finishing it: sending headers one at a time, or a body byte by byte, at whatever interval keeps the server waiting. Each connection costs the attacker almost nothing and costs the server a slot.

Variants

Slowloris sends request headers slowly and never completes them. Slow POST (sometimes R-U-Dead-Yet) declares a large body and sends it a byte at a time. Slow read requests a large response and reads it slowly, so the server holds the send buffer.

All three exploit the same property: the server is being patient, and patience is the vulnerability.

How it differs from similar attacks

An HTTP flood sends complete, expensive requests quickly. Slow HTTP sends cheap, incomplete requests slowly. They exhaust different resources — work versus concurrency — and a defence tuned for one will not see the other.

A SYN flood never completes the TCP handshake. Slow HTTP completes it, which means SYN-level defences pass this traffic straight through.

Observable telemetry

• Concurrent connection count high while request completion rate is very low.
• Connections in a reading-headers or reading-body state for far longer than normal.
• Very low bytes-per-connection, sustained.
• Few source addresses relative to connection count — this class does not need distribution.
• On Apache, worker processes in the R (reading request) state accumulating.

Common false positives

Genuinely slow clients exist: poor mobile connections, satellite links, large uploads from constrained networks. A timeout set aggressively enough to stop the attack instantly will also disconnect real users on bad links, which is a real trade rather than a hypothetical one.

Large legitimate uploads are the case most often broken by an over-tightened body timeout.

Mitigation by layer

Upstream — nothing to do. There is no volume to filter.

Reverse proxy — the structural answer. A proxy that buffers complete requests before forwarding absorbs the slow client entirely. nginx and HAProxy both do this, and HAProxy’s timeout http-request is specifically the control this class exists in the absence of.

Web server — request timeouts and per-source connection limits. Apache needs particular attention because its process-per-connection model makes concurrency scarce.

Application server — connector-level limits, covered per platform in the hardening section.

Operational pitfalls

Leaving the header timeout unset, which is the default in more configurations than anyone expects and is the entire exposure.

Setting timeouts from a blog post rather than from measurement. The right value depends on your clients’ real connection quality, which you can measure.

Forgetting the upload path. A body timeout that suits an API breaks a file upload.

Safe validation

Trivially testable against your own service: open connections and send headers slowly, then count how many it takes before new legitimate connections are refused. That number is your concurrency ceiling and it is worth knowing.

Measure the same thing again after adding the timeout, and separately confirm that a genuinely slow legitimate client — a large upload over a throttled link — still succeeds.