Slowloris Attack
Slowloris is a low-bandwidth DDoS attack that exhausts a server's connection pool by opening multiple connections and keeping them alive indefinitely. In its classic form, it sends partial HTTP headers that are never completed. A variant targets the TLS handshake, initiating SSL/TLS negotiations but sending ClientHello or handshake fragments extremely slowly, forcing the server to hold open expensive TLS state for each stalled connection. Both techniques starve the server of available connections using minimal bandwidth — often from a single machine.
How Slowloris Attack Works
Slowloris exploits the way servers handle concurrent connections at multiple layers. Most web servers allocate a thread or worker for each incoming connection and hold it open until the request is complete. The classic variant abuses this by never completing the HTTP request. A TLS-layer variant targets the SSL/TLS handshake: the attacker initiates a TLS negotiation but sends handshake messages (ClientHello, key exchange) extremely slowly or in tiny fragments. The server must allocate memory for the TLS session state and cryptographic context while waiting for the handshake to complete — and TLS state is significantly more expensive than a plain TCP connection. Both approaches keep connections occupied indefinitely with minimal bandwidth.
Open many concurrent connections
The attacker opens hundreds or thousands of TCP connections to the target web server. Each connection initiates a valid HTTP request with proper headers, appearing as a normal client beginning to load a page.
Send partial HTTP headers
Instead of completing the HTTP request (which ends with a blank line \r\n\r\n), the attacker sends only partial headers. The server keeps the connection open, waiting for the rest of the request to arrive before processing it.
Periodically send keep-alive data
Before the server's connection timeout expires, the attacker sends an additional incomplete header line (e.g., 'X-a: b\r\n') to reset the timeout timer. This tiny amount of data — just a few bytes — is enough to keep the connection alive indefinitely.
TLS handshake variant: stall the encryption negotiation
When targeting HTTPS servers, the attacker can apply the same slow technique at the TLS layer. After completing the TCP handshake, it initiates a TLS negotiation but sends ClientHello or subsequent handshake messages in tiny fragments with long pauses between them. The server must allocate memory for asymmetric cryptographic context, session buffers, and cipher state for each pending handshake — far more expensive than a plain HTTP connection — while waiting for the negotiation to complete.
Exhaust the server's connection pool
As the attacker accumulates hundreds of stalled connections (at the HTTP layer, the TLS layer, or both), the server's maximum concurrent connection limit is reached. New legitimate users attempting to connect receive timeouts or connection refused errors, effectively taking the service offline.
Real-World Examples
Iranian election protests
Slowloris gained widespread attention when it was used against Iranian government websites during the contested 2009 presidential election. Activists used the tool to disrupt government propaganda sites from personal computers, demonstrating that a single machine could take down a web server.
Hacktivist campaigns against financial institutions
Slowloris variants were used as part of Operation Ababil, a series of DDoS attacks against major US banks including Bank of America and JPMorgan Chase. The slow-rate attack components were combined with volumetric floods to overwhelm both network and application layers simultaneously.
Apache server vulnerability disclosures
Security researchers continued to demonstrate that unprotected Apache HTTP Server installations remain vulnerable to Slowloris by default, as Apache allocates a thread per connection. Testing showed that as few as 300 concurrent connections from a single laptop could make a default Apache server unresponsive.
Impact & Risk Assessment
Slowloris is particularly dangerous because it requires minimal resources from the attacker — a single machine with a standard internet connection can take down an unprotected web server. The attack causes complete service unavailability for legitimate users without triggering traditional volumetric DDoS detection. Because bandwidth usage is extremely low, network-level monitoring and rate limiting based on traffic volume are ineffective. Affected organizations experience prolonged downtime, customer frustration, and potential revenue loss, especially for businesses dependent on web availability.
How to Detect Slowloris Attack
Monitor the number of concurrent connections per IP address — Slowloris generates an abnormally high number of open but idle connections from few source IPs. Track connection duration and flag connections that remain open without completing an HTTP request for extended periods. Analyze the rate of completed vs. incomplete requests — a healthy server completes most requests quickly, while a Slowloris attack shows many stalled connections. Watch for patterns of periodic small data packets (keep-alive headers) without full request completion. Monitor server thread/worker utilization approaching maximum capacity.
How to Prevent Slowloris Attack
Configure aggressive connection timeouts to close idle or slow connections quickly (e.g., reduce Apache's Timeout and RequestReadTimeout directives). Set limits on the maximum number of concurrent connections from a single IP address. Use a reverse proxy or load balancer (like Nginx or HAProxy) that buffers complete requests before forwarding them to the backend — this architecture is inherently resistant to Slowloris because the proxy handles incomplete requests without consuming backend resources. Deploy a WAF with slow-rate attack detection that identifies and blocks clients sending abnormally slow partial requests. Switch from thread-per-connection servers (Apache prefork) to event-driven architectures (Nginx, Node.js) that handle thousands of connections with minimal resource allocation per connection.
Code Examples
# Enable mod_reqtimeout (loaded by default in Apache 2.4+)
LoadModule reqtimeout_module modules/mod_reqtimeout.so
# Set strict timeouts for receiving request headers and body
# Header: 10 seconds initial, +1 second for each 500 bytes, max 30 seconds
# Body: 20 seconds initial, +1 second for each 500 bytes, max 60 seconds
RequestReadTimeout header=10-30,MinRate=500 body=20-60,MinRate=500
# Limit maximum concurrent connections per IP
# Requires mod_limitipconn or use iptables:
# iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
http {
# Close connections with no activity quickly
client_header_timeout 10s;
client_body_timeout 10s;
send_timeout 10s;
keepalive_timeout 15s;
# Limit concurrent connections per IP
limit_conn_zone $binary_remote_addr zone=addr:10m;
server {
listen 80;
# Max 30 concurrent connections per IP
limit_conn addr 30;
location / {
# Nginx buffers the complete request before forwarding
# to the backend, protecting it from slow clients
proxy_pass http://backend;
proxy_buffering on;
}
}
}
PowerWAF automatically blocks Slowloris Attack at the edge.
Deploy in minutes. No code changes required. Free plan available.
Free plan spots are limited