Slowloris: Low-Bandwidth DoS Tool in Python!!

What is Slowloris and why it matters​

Slowloris is a famous concept in web security - a low-bandwidth technique that can tie up server resources by holding many HTTP connections open and sending only tiny, periodic bytes to keep each connection alive. It targets the way some web servers manage threads or connection slots.

Why study it? Because understanding attack patterns helps you build resilient servers and diagnose hard-to-track availability issues. Learning the theory is valuable for sysadmins, web developers, and security students - but testing should always be legal, controlled, and isolated.

How the technique works (high-level)​

At a conceptual level, the technique works like this:

• The attacker opens many HTTP connections to a target server.
• For each connection, the attacker sends a valid but incomplete HTTP request (for example, a request line and some headers but not the final blank line that completes headers).
• Periodically, the attacker sends small header fragments (keep-alive headers) to avoid the server timing out the connection.
• The server holds those connections open waiting for the request to finish, consuming worker threads or file descriptors.
• If enough connections are held, legitimate clients can’t get served - the server appears slow or unavailable.

That’s the idea - but remember: describing the mechanism is for defense and education, not to perform attacks.

---

Legal, ethical, and safety rules​

Before doing any testing or experiments:

• Never test on systems you don’t own or don’t have explicit written permission to test. Unauthorized testing is illegal in many jurisdictions.
• Use an isolated lab environment or a cloud instance you control. Mark it clearly so others don’t mistake it for a production service.
• Use official load-testing tools and follow the provider’s rules if testing hosted resources.
• Keep logs and limit impact - treat tests like any other change (with planning and rollback).

Understanding attack techniques is fine; executing them against third-party servers without permission is not.

---

How defenders detect and recognize this behavior​

If you suspect a slow-connection style attack, look for signs like:

• A high number of established TCP connections in SYN/ESTABLISHED state.
• Many open HTTP connections with little or no data being transferred.
• Server metrics: spike in worker/thread usage, exhausted connection pools, or high load while CPU stays relatively low.
• Logs showing many incomplete requests with long durations.

Monitoring tools (Netstat, ss, server-status pages, APMs) and log correlation help identify patterns. Set alerts for unusual connection counts and long-lived requests.

---

Practical mitigation strategies​

You can harden servers against this class of attacks using multiple layers:

• Use a reverse proxy / load balancer (e.g., nginx, HAProxy, Cloudflare). These can handle many concurrent connections efficiently and can be tuned to drop malformed or long-idle connections.
• Limit request header time (modules like mod_reqtimeout for Apache). Configure short timeouts for reading headers and bodies.
• Tune worker model - prefer event-driven servers (nginx, Caddy) over thread-per-connection servers for large concurrency.
• Connection limits & per-IP caps - rate-limit or limit simultaneous connections per IP, but be cautious with NAT/proxy situations.
• Web application firewalls (WAFs) - can detect suspicious patterns and block them.
• Increase backlog and file descriptor limits only as a temporary measure - the long-term fix is protocol-level defense and filtering.

Combining several defenses gives the best protection.

Safe, legal load-testing alternatives​

If your goal is to validate capacity or see how your stack behaves under load, use standard, legitimate tools that are designed for testing:

• ApacheBench (ab) - basic HTTP benchmarking for small tests.
• wrk - flexible HTTP benchmarking tool for higher concurrency.
• locust - Python-based, programmer-friendly load testing with scenarios.
• Gatling - Scala-based testing with detailed reports.
• Cloud load-test services (some cloud providers offer controlled testing tools).

Always run tests from controlled clients, with a pre-approved window and off-peak time if testing production (and only if you have explicit approval).

---

Responsible example: making controlled HTTP requests in Python​

Below is a harmless example showing how to make a small number of HTTP requests responsibly with rate limiting. This is not an attack script - it uses delays and low concurrency, suitable for automated smoke tests or monitoring probes.

# Safe example: do a few HTTP GETs with polite delays (for monitoring/tests)
import requests
import time

URLS = [
    "https://example.local/test1",
    "https://example.local/test2",
]

def polite_check(urls, delay=2.0):
    """Perform sequential GETs with delays to avoid overloading target."""
    for url in urls:
        try:
            r = requests.get(url, timeout=10)
            print(f"{url} -> {r.status_code}, {len(r.content)} bytes")
        except requests.RequestException as e:
            print(f"{url} -> error: {e}")
        time.sleep(delay)

if __name__ == "__main__":
    polite_check(URLS, delay=2.5)  # adjust delay for your test policy

Use code like this only against systems you control, and tune delay and timeout so the checks remain friendly and safe. ️

How to test mitigation in a lab​

If you want to validate your mitigation settings:

1. Create an isolated test environment: a server instance and one or more client machines in a private network.
2. Configure the server like production (web server, reverse proxy, WAF).
3. Use legitimate load-testing tools (wrk, locust) to generate realistic traffic patterns (concurrent connections, normal request pace).
4. Measure server behavior: connection count, response times, thread usage, and logs.
5. Tune timeouts, proxy settings, and rate limits, then retest.

Document results and use metrics to set safe defaults in production.

---

Summary & key takeaways​

• Slow-connection attacks highlight how servers manage resources; understanding them helps you defend systems.
• Never run attack code against targets you don't own or lack permission for - it’s illegal and unethical.
• Defend with a layered approach: reverse proxy, timeouts, connection limits, and monitoring.
• Use legitimate load-testing tools in a controlled lab to validate defenses - and use polite, throttled scripts for monitoring.