Most DDoS attacks are about volume — overwhelming a target with more traffic than it can handle. Slowloris is the opposite, and that is what makes it elegant and dangerous. Written by the researcher RSnake in 2009, it needs no botnet and almost no bandwidth. A single laptop on an ordinary connection can take an unprotected Apache server completely offline, not by shouting louder but by holding the door open and refusing to leave.
How the Attack Works
A web server can only handle so many simultaneous connections. Slowloris opens as many connections to the target as it can and sends partial HTTP request headers — then, just often enough to avoid a timeout, it sends one more header line, but never finishes the request. The server keeps every one of those connections open, waiting politely for a request that will never complete. Apache's default worker pool (often around 256 concurrent connections) fills up with these half-open requests, and once it is full, real visitors are simply refused.
Why It Is So Hard to Detect
Every individual Slowloris connection is legitimate. It completes a real TCP handshake and sends real, valid HTTP headers — just slowly. There is no spoofing, no flood, no amplification, and the total bandwidth is trivial. Network-level DDoS detection, which watches for traffic spikes, sees nothing unusual. The only way to spot Slowloris is behavioural: noticing that an abnormal number of connections are sitting in the same half-finished state for far too long.
Low and slow beats big and loud
Slowloris proves that you do not need volume to cause an outage — you need to exhaust a limited resource. Here the resource is connection slots, not bandwidth, which is why bandwidth-based defences miss it entirely.
How to Defend Against It
- Prefer event-driven servers: nginx and HAProxy handle many idle connections far better than Apache's worker model.
- Set aggressive header timeouts — close any connection that has not completed its request headers within a few seconds.
- Limit the maximum number of concurrent connections per source IP.
- Put a reverse proxy in front of the origin that terminates HTTP at the edge, so slow connections pile up against the proxy's connection limits — which are designed for exactly this — and never reach your server.
Where Akarguard Fits
Because Akarguard terminates HTTP at its reverse-proxy edge, a Slowloris attack exhausts connection slots on the proxy, not on your origin — and the proxy's connection handling and per-IP limits are built to absorb exactly this kind of low-and-slow abuse. Your origin only ever receives complete, forwarded requests, so its worker pool never fills with half-open connections. Combined with per-IP connection limits you set from the panel, the attack that could take down a lone Apache box becomes a non-event behind the edge.