Listen to this Post
Introduction:
The Slowloris denial-of-service attack represents a fundamental shift in how cyber adversaries think about resource exhaustion. Unlike volumetric DDoS attacks that rely on brute bandwidth to overwhelm network pipes, Slowloris operates with surgical precision at the application layer—opening thousands of connections, sending partial HTTP requests, and keeping them artificially alive until the server’s connection pool is completely depleted. This “low and slow” approach allows a single machine with minimal bandwidth to render even well-provisioned web servers inaccessible to legitimate users, making it one of the most deceptively dangerous tools in an attacker’s arsenal.
Learning Objectives:
- Understand the technical mechanics of Slowloris attacks and how they exploit HTTP protocol behavior to exhaust server resources.
- Master multi-layered mitigation strategies across Apache, Nginx, HAProxy, and cloud-based WAF solutions.
- Develop skills to detect, monitor, and respond to low-and-slow DDoS attacks using real-world commands and configurations.
You Should Know:
- The Anatomy of a Slowloris Attack – How Partial Headers Paralyze Your Server
Slowloris, first introduced in 2009 by security researcher Robert “RSnake” Hansen, was originally a 36 KB Perl script that proved capable of disabling major web servers. The attack exploits a fundamental characteristic of the HTTP protocol: the ability for clients to split requests into multiple packets or sessions.
Under normal conditions, a web client opens a TCP connection, sends a complete HTTP request, receives a response, and the connection is closed or reused. The server maintains a finite thread pool—each thread handles one connection at a time. Slowloris disrupts this by sending only partial HTTP headers, deliberately omitting the final empty line that signals the end of the header section.
The attack unfolds in four distinct steps:
- Connection Flood: The attacker opens multiple connections to the target server by sending partial HTTP request headers.
- Thread Allocation: The server allocates a thread for each incoming request, expecting the connection to complete.
- Connection Maintenance: To prevent timeouts, the attacker periodically sends additional partial headers (e.g., `X-a: b\r\n` every 15 seconds), essentially saying, “I’m still here, just slow—please wait for me”.
- Resource Exhaustion: Once all available threads are occupied, the server cannot respond to legitimate requests, resulting in denial-of-service.
What makes Slowloris particularly insidious is its stealth. Since log files cannot be written until a request is completed, Slowloris can immobilize a server for extended periods without generating a single log entry to raise red flags.
2. Apache Hardening – Deploying mod_reqtimeout and mod_qos
For Apache-based web servers, two modules provide robust protection against Slowloris: `mod_reqtimeout` and mod_qos. Unlike the older and unmaintained mod_evasive, `mod_qos` is actively developed and offers advanced traffic handling capabilities.
mod_reqtimeout sets timeouts for reading client request headers and bodies, ensuring that slow clients cannot hold connections indefinitely. Add the following configuration to your Apache include editor:
<IfModule mod_reqtimeout.c> Wait up to 20 seconds for header data RequestReadTimeout header=20-40,minrate=500 RequestReadTimeout body=20,minrate=500 </IfModule>
This configuration waits up to 20 seconds for header data, allowing an additional 1 second per 1000 bytes received, up to a maximum of 40 seconds.
mod_qos implements quality-of-service controls that limit connections per client, data transfer rates, and request prioritization. Installation requires compiling from source:
For EA3 (EasyApache 3) mkdir -p /usr/local/apache/custom-modules cd /usr/local/apache/custom-modules curl -L https://sourceforge.net/projects/mod-qos/files/mod_qos-11.56.tar.gz/download -o mod_qos-11.56.tar.gz tar -xzf mod_qos-11.56.tar.gz /usr/local/apache/bin/apxs -aic mod_qos-11.56/apache2/mod_qos.c /usr/local/cpanel/bin/apache_conf_distiller --update /scripts/rebuildhttpdconf service httpd restart
Key directives to add to your Apache configuration:
<IfModule mod_qos.c> Maximum number of concurrent connections per IP QS_SrvMaxConnPerIP 50 Minimum data rate (bytes per second) required from client QS_MinSrvDataRate 150 200 Maximum number of requests per second from a single IP QS_LimitRequestRate 50 </IfModule>
These settings ensure that a single client cannot monopolize server resources.
- Nginx Protection – Connection Limits and Timeout Tuning
Default Nginx configurations are vulnerable to Slowloris because the scarce resource is the maximum number of simultaneous worker connections. To harden Nginx, implement the following protections:
Limit concurrent connections per IP using the `limit_conn` module:
http {
Define shared memory zone for connection tracking
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
server {
Allow maximum 50 concurrent connections from a single IP
limit_conn conn_limit_per_ip 50;
limit_conn_status 503;
Reduce keep-alive timeout to prevent long-lived idle connections
keepalive_timeout 15s;
keepalive_requests 100;
Set client header and body timeouts
client_header_timeout 5s;
client_body_timeout 10s;
send_timeout 10s;
}
}
Limit request rates to prevent slow request flooding:
http {
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;
server {
limit_req zone=req_limit_per_ip burst=20 nodelay;
}
}
Buffer size limits also help—set `client_body_buffer_size 16k` and `client_header_buffer_size 4k` to prevent buffer exhaustion attacks.
- HAProxy as a Frontline Shield – Timeout-Based Protection
Deploying a reverse proxy like HAProxy in front of your web servers provides an effective defense layer. HAProxy can wait for a complete HTTP request before forwarding it to the backend, effectively absorbing Slowloris traffic before it reaches your origin servers.
defaults mode http maxconn 19500 timeout client 60s timeout server 60s timeout queue 60s timeout connect 4s timeout http-request 5s Critical: client must send complete request within 5s option httpclose option abortonclose balance roundrobin retries 2 frontend public bind :80 default_backend apache backend apache server srv 192.168.1.1:80 maxconn 248
The `timeout http-request 5s` directive is the cornerstone—it gives a client exactly 5 seconds to send a complete HTTP request. If the request remains incomplete, HAProxy closes the connection with an error, preventing resource exhaustion on the backend.
5. Cloudflare WAF and CDN – Enterprise-Grade Protection
For organizations leveraging Cloudflare, the platform provides built-in protection against Slowloris attacks. Cloudflare buffers incoming requests before forwarding anything to the origin server. As a result, “low and slow” attack traffic never reaches the intended target.
Key configuration steps:
- Enable Proxy (Orange Cloud) for your DNS records to route traffic through Cloudflare.
- Configure Request Body Buffering to ensure complete requests before origin forwarding.
- Deploy WAF Managed Rulesets which include heuristics for detecting partial HTTP requests and abnormal connection patterns.
- Implement Rate Limiting rules to block IPs exhibiting slow-request behavior.
Cloudflare’s autonomous detection systems identify and mitigate attacks within approximately 3 seconds using traffic profiling and machine learning.
- Detection and Monitoring – Spotting the Invisible Threat
Detecting Slowloris attacks requires behavioral insight rather than signature-based approaches. Monitor for:
- Connection duration anomalies: Numerous connections lasting longer than normal
- Incomplete HTTP requests: Partial headers without termination
- Abnormally low data rates: Connections transmitting at extremely slow speeds
- High connection counts: Unusual spikes in concurrent connections from single IPs
Use the following Linux commands to identify potential Slowloris activity:
Check current connections and their states
netstat -ant | grep :80 | wc -l
Identify connections in CLOSE_WAIT or TIME_WAIT states
ss -ant | grep -E 'CLOSE-WAIT|TIME-WAIT' | wc -l
Monitor connection rates per IP
netstat -1tu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -1r
Track Apache status for thread usage
apache2ctl status
For Nginx, monitor active connections
curl -s http://localhost/nginx_status | grep "Active connections"
Intrusion detection systems often miss Slowloris attacks because traffic patterns closely resemble legitimate user behavior. Continuous monitoring and traffic profiling are essential for early detection.
7. Network-Level Defense – iptables and Fail2Ban
For additional protection at the network layer, iptables can limit connection rates per IP:
Limit new connections to 10 per second from a single IP iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT Rate-limit SYN packets to prevent connection flooding iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
Fail2Ban can be configured to monitor logs and automatically block IPs exhibiting Slowloris behavior:
[bash] enabled = true filter = slowloris logpath = /var/log/apache2/access.log maxretry = 20 findtime = 60 bantime = 3600 action = iptables-multiport[name=slowloris, port="http,https", protocol=tcp]
What Undercode Say:
- Slowloris is not about bandwidth—it’s about connection exhaustion. A single attacker with a laptop and a Python script can take down an Apache server using just a few hundred connections, while volumetric attacks require botnets and massive infrastructure.
-
The most effective defense is layered mitigation: combine server-level timeouts (Apache mod_reqtimeout, Nginx client_timeout), reverse proxy buffering (HAProxy, Cloudflare), and network-layer rate limiting (iptables, Fail2Ban) for comprehensive protection.
-
Detection is the hardest part—traditional IDS/IPS and log monitoring often fail because Slowloris traffic looks legitimate and leaves minimal traces. Organizations must implement behavioral analytics and real-time connection profiling to catch these attacks early.
-
Apache 1.x and 2.x are particularly vulnerable by default, making proper configuration of mod_reqtimeout or mod_qos non-1egotiable for any production Apache deployment.
Prediction:
-
+1 As more organizations adopt cloud-based WAF and CDN services, Slowloris attacks will increasingly be absorbed at the edge rather than reaching origin servers. Cloud providers will continue enhancing their low-and-slow detection heuristics, making these attacks less effective against well-protected targets.
-
+1 The security community will develop more sophisticated detection tools leveraging machine learning to identify subtle behavioral patterns associated with Slowloris, shifting the advantage toward defenders.
-
-1 Attackers are adapting—modern Slowloris variants now distribute requests across globally diverse botnet IPs and multithread TCP connections per source, making IP-based rate limiting less effective.
-
-1 The rise of HTTP/2 and HTTP/3 introduces new attack surfaces for slow-rate DoS attacks, as connection multiplexing and stream prioritization create novel resource-exhaustion vectors that existing mitigation tools may not fully address.
-
-1 Many organizations still expose origin server IPs through misconfiguration, allowing attackers to bypass WAF protections entirely and target backend servers directly. This operational gap will continue to be exploited.
▶️ Related Video (76% Match):
https://www.youtube.com/watch?v=8ycxyjkb3lU
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Cybersecurity Ddos – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
