How can security teams detect Slowloris?

What Slowloris Looks Like in Traffic and Server Telemetry

Slowloris is usually visible first as a pattern, not a signature. The server appears busy, but normal request throughput drops while connection counts climb and many sessions stay open without completing headers. That mismatch between rising concurrency and falling completed requests is the core detection clue, especially on web tiers that depend on a limited worker pool.

Look for partial HTTP sessions that remain open far longer than normal, repeated header fragments from the same source, and a growing backlog of requests waiting for workers. If latency increases at the same time as the server serves very few full responses, the issue is often connection hoarding rather than ordinary load.

How to Separate Slowloris From Legitimate Slow Clients

Not every slow connection is malicious. Mobile networks, large uploads, proxies, and poorly tuned clients can all create noisy outliers, so the practical test is whether the pattern is concentrated, sustained, and asymmetric. Slowloris tends to create many incomplete requests at once, often from a small set of sources or source ranges, while legitimate slowness usually produces fewer long-lived sessions and more completed work.

Correlation matters more than any single field. If open connections rise, request completion falls, header parsing stalls, and worker utilization stays high without a matching rise in useful output, you have a likely Slowloris condition. If your logs or flow data show repeated short bursts of partial headers rather than normal end-to-end transactions, treat that as a stronger signal than raw request rate alone.

For broader DDoS context, the DDoS Protection Guide is useful because Slowloris is one form of application-layer exhaustion, and the detection logic sits inside the wider pattern of service depletion.

Detection Signals That Are Worth Automating

Security teams get the best value from alerts that combine stateful and behavioural indicators. Single-threshold alerts on connection count or CPU are too crude, because Slowloris can exhaust workers before the host is obviously overloaded. Better detectors track the ratio of open to completed requests, header completion time, request queue depth, and the number of workers pinned to partial sessions over a rolling window.

At the infrastructure layer, watch for imbalance across web nodes, because a successful Slowloris attempt often creates a few saturated servers rather than an obvious platform-wide failure. At the application layer, compare current behaviour with known-good baselines for normal header timings, concurrent sessions, and request completion rates. The most useful alert is the one that tells an operator the service is consuming effort without producing responses.

Risk and Threat Considerations

Slowloris matters because it exploits a weakness in how many web servers allocate scarce connection-handling resources. An attacker does not need high bandwidth to cause disruption if the server keeps threads, workers, or request slots reserved for partial sessions instead of completed requests.

Failure mechanism: The attack keeps enough connections open, and just active enough, to prevent normal requests from reaching completion while consuming concurrency and worker capacity. That can make the service look alive in monitoring while users experience timeouts, failed logins, or partial outage.

Impact: The practical effect is application-layer denial of service, degraded availability, and noisy incident triage, especially where teams rely on generic host metrics instead of request-state telemetry. If the pattern is allowed to persist, it can also obscure other traffic anomalies by overwhelming the server’s ability to serve legitimate sessions.

Practitioner Guidance

What to verify: Confirm that your monitoring can distinguish open sockets from successfully completed HTTP requests. If you only watch CPU or bandwidth, you can miss the attack until the service is already user-visible impaired.

Decision rule: If the problem is a small number of abusive sources creating many stalled sessions, prefer rate limiting, connection timeout tuning, and request-header time limits before assuming you need a broad traffic block. If the issue is distributed across many sources, escalate to edge filtering and platform-level mitigation sooner.

What good looks like: The service should show stable request completion rates, bounded header wait times, and no sustained buildup of half-open or incomplete HTTP sessions during normal traffic peaks. When those metrics stay aligned, Slowloris-style depletion is much easier to spot early.

Practitioner takeaway: The key is to monitor request progress, not just request volume, because Slowloris succeeds by holding resources in an incomplete state long enough to starve legitimate users.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?