How to defend against slow attacks on servers

Slow attacks are low-and-slow strikes. They use extremely slow HTTP or TCP traffic to exhaust server resources while staying under normal thresholds. These attacks mimic legitimate traffic, evade volume-based alerts, and can take a service offline with minimal bandwidth. A brute-force attack guesses credentials at high speed, and a volumetric DDoS attack floods the pipe with sheer volume. A slow attack does neither, which is why it slips past many defenses.

You will learn how to identify, detect, and defend against slow attacks with practical, implementable measures.

Slow attacks explained

A slow attack is a ddos attack that uses extremely slow HTTP or TCP traffic instead of volume. The attacker opens many connections and then sends data at a crawl. Each connection looks legitimate, so your defenses treat it as a normal visitor. The goal is to maximize server load until the site is running slowly or stops responding altogether.

Common slow attack types

Slowloris holds many connections open by sending partial HTTP headers at a trickle. The server waits for each request to finish, and its connection pool fills up. Slow POST sends the request body one byte at a time, so the server keeps the request alive for a long period. Slow Read works in reverse: the client advertises a tiny receive window and reads the response slowly, which ties up server buffers.

You can identify these attacks by their shared pattern. Each one keeps connections open far longer than a real user would. None of them needs a high volume of traffic to succeed.

Signs of a slow attack

Watch for hung connections that never complete. A rising count of concurrent connections is another strong signal, especially when request completion rates stay flat. You may also see degraded response times while bandwidth usage remains low. That combination separates a slow attack from a mass traffic attack, which pushes a huge volume of traffic at your servers and shows up clearly in network graphs.

A volumetric ddos floods the link with traffic. A slow attack does the opposite, and that is why it is harder to detect. Your monitoring must track connection duration and request completion, not just raw traffic. When you see the site slowing down while your bandwidth charts look normal, treat it as a possible low-and-slow strike and investigate the connection table.

Detect and block brute-force attacks and slow threats

A brute-force attack differs from a slow attack in method and speed. The brute-force attack tries many credentials quickly, while the attacker holds connections open. Both a brute-force attack and a slow attack benefit from the same monitoring discipline: watch connection behavior and request rates, not just volume.

Metrics that reveal slow attacks

Four metrics expose a low-and-slow strike. Connection duration shows how long each session stays open; legitimate users finish requests in seconds, while attack connections linger. Concurrent connections reveal pool exhaustion, especially when the count climbs and request completion stays flat. Request completion rate measures how many requests actually finish; a falling rate with stable traffic points to stalled requests. Minimum incoming data rate catches clients that send bytes at a crawl. A brute-force attack shows up differently: many short connections and a burst of failed logins. You still catch a brute-force attack with the same dashboard.

Track these metrics per source. A single IP with a large number of accesses and long connection times deserves scrutiny. Compare each source against your normal baseline, and flag outliers for review. A brute-force attack from one IP looks like a spike in failed logins. Set your baseline over a full week, because request patterns shift between weekday and weekend. A connection that lasts longer than your slowest legitimate request is a candidate for review. Log the source, the duration, and the bytes received for each flagged session.

Detection tools and threshold rules

Threshold-based rules turn these metrics into alerts. Set a maximum connection duration, a cap on concurrent connections, and a floor on incoming data rate. Bot mitigation threshold rules apply the same logic to request patterns. Modern anti-DDoS services specialize in application-layer low-and-slow detection, and they can spot the pattern before your origin feels the strain. A brute-force attack triggers a different rule: too many failed logins from one source in a short window. Start with conservative thresholds and tighten them as you learn your normal range. A rule that fires on every long download will drown your team in false positives. Pair each threshold with a clear response: alert, throttle, or drop.

When a brute force attack is detected, you must act on the source. Review server access logs to confirm the pattern. Then block the IP addresses of the sources behind the attack. You can block that IP address at the firewall or the load balancer. Record the hacker’s IP address for later analysis. A high volume of traffic is easy to see; a slow attack is not, so let your thresholds do the watching. A brute-force attack leaves a clear trail in those logs.

To detect and block brute force attacks and slow threats together, correlate connection metrics with authentication failures. The brute-force pattern is loud in authentication logs. A slow attack leaves long-lived connections. Both patterns belong in the same dashboard. Tune your brute-force rules separately from slow-attack rules, and keep your servers patched and monitored. Review the rules each quarter, because application changes and new features shift your baseline. Run a tabletop exercise with your team so everyone knows the response steps.

How to defend against slow attacks

Rate limiting, connection limits, timeouts, and minimum data rates form the practical core of any plan to defend against slow attacks. Each control targets a different part of the problem, and together they close the gaps that let a slow client hold resources hostage.

Rate limiting and connection limits

Rate limiting restricts the number of requests a server can handle in a given window. You cap how many connections or requests one source may open, and you drop the excess. This control mitigates ddos attack traffic that relies on volume, and it also constrains a slow attacker who tries to open thousands of parallel sessions. Set the limit per source address, not just globally, so one noisy client cannot consume the whole allowance.

Connection limits work alongside rate limiting. You define a maximum number of concurrent connections per source and a maximum for the server overall. When a client exceeds either cap, you refuse new connections until the count drops. A slow attack depends on filling that pool, so a firm cap removes the attacker’s main lever. You should also upgrade server availability where budget allows. More memory and better connection handling let your servers maintain a larger number of concurrent connections for legitimate users without collapsing under a slow flood.

Timeouts and minimum data rates

Timeouts are your first line of defense against slow attacks. Configure a header timeout, a body timeout, and an idle timeout. Any connection that fails to send a complete request within the window gets closed. A Slowloris client that dribbles headers will hit the header timeout and lose its slot. A Slow POST client that sends the body one byte at a time will hit the body timeout. Keep these values tight enough to catch abuse but loose enough for real users on the links.

A minimum incoming data rate adds a second check. You define a floor, and the server drops any connection that sends bytes slower than that rate. This rule catches clients that stay just inside the timeout window by sending a trickle of data. Be careful here. Set the minimum too low and the rule never fires. Set it too high and you block legitimate users on poor connections or large uploads. Measure your normal traffic first, then pick a floor below the slowest real client you want to serve.

A minimum data rate that is too aggressive will block real users, and one that is too lenient will let a slow attacker through. Tune it against measured baselines, not guesswork.

Layer these controls. Rate limiting and connection caps stop the flood at the door. Timeouts and minimum data rates evict the clients that slip inside. Review the values as your traffic patterns change, and test each rule before you rely on it to defend against slow attacks in production.

Defend against Slowloris and Slow POST

Reverse proxy protection

A reverse proxy sits between the client and your origin server. It absorbs each incoming connection and waits for a complete HTTP request before it forwards anything upstream. A Slowloris client that dribbles headers never finishes that request, so the proxy holds the connection and your origin never sees it. The attacker wastes effort against the proxy instead of tying up your application workers.

This layer also gives you a single place to enforce connection caps and timeouts. You configure the limits once on the proxy, and every backend inherits the protection. Place the proxy in front of your web tier and route all public traffic through it. Then you can block suspicious sources at the edge before they reach the application.

Server configuration hardening

Protecting against slow HTTP attacks mainly requires correctly configuring certain server options. Set strict header and body timeouts, cap concurrent connections per source, and limit the request line and header size. Each option closes a gap that a slow client would otherwise exploit. Review the defaults that ship with your web server, because many of them tolerate long-lived connections by design.

Modern anti-DDoS services can handle low-and-slow application-layer attacks through specialized mechanisms. They profile request timing and connection behavior, then drop sessions that match the pattern. Use one alongside your own configuration when you need coverage you cannot build in-house. Test every change against a simulated slow attack before you rely on it to defend against slow attack traffic in production. Keep a record of each setting and the reason behind it, so your team can audit the configuration later.

Best practices for slow attack defense

Layered network and application defenses

No single control stops every slow client. Layer your defenses at both the network level and the application level. At the network level, you filter sources, cap connection rates, and drop malformed packets before they reach your web tier. At the application level, you enforce timeouts, minimum data rates, and request size limits. Each layer catches what the one below it misses.

This layering matters because a slow attack can shift shape. A client that passes your network filter may still stall inside an HTTP request. Your application rules then close that connection. Build the layers so each one stands alone, and document which control handles which threat. When one layer fails, the next still protects your servers.

Testing and tuning defenses

Tune every threshold to your normal traffic baseline. Measure connection durations, request completion rates, and data rates over a full week. Set your limits just outside the range your real users produce. Review those values on a regular schedule, because application changes and new features shift the baseline. A rule tuned last year may block real users today.

Test each configuration against a simulated slow attack before you rely on it in production. Run a controlled Slowloris or Slow POST test in a staging environment. Confirm that your timeouts fire, your connection caps hold, and your alerts trigger. Then verify that legitimate users still get through. A defense you have never tested is a guess.

A ddos attack that arrives slowly will not show up in volume charts. Your thresholds and your tests are the only warning you get.

Pair these practices with regular log reviews. You can detect a slow pattern early when you compare current connection behavior against your baseline. Keep your rules current, and your layered defenses will hold against a ddos attack that tries to slip in quietly.

Slow attacks stay low in volume and high in impact. Watch connection duration and request completion, not traffic. Layer timeouts, connection limits, minimum data rates, and rate limiting. A reverse proxy with tuned server options gives baseline protection. Tune thresholds to normal traffic and review them regularly. A brute-force attack runs fast. A brute-force attack floods logs. You can detect and block brute force attacks with common rules. Log each brute-force source. Block a brute-force IP. Review brute-force patterns closely. Track brute-force attempts daily. A brute-force attack rewards patience. Study each brute-force attack. A brute-force attack hides well. These are countermeasures even small sites can use. Audit your setup to defend against slow attack traffic.

FAQ

How quickly can a slow attack take a server down?

It depends on your connection pool size and your timeout settings. A slow attack fills available slots one connection at a time. Once the pool is full, legitimate users wait or get refused. Tight timeouts and connection caps slow the attacker’s progress considerably.

Can a firewall alone stop a low-and-slow strike?

A basic firewall filters by address and port, so it misses clients that look legitimate. You need application-layer controls too. Timeouts, minimum data rates, and a reverse proxy catch the slow pattern that a network filter lets through.

Does a brute-force attack look similar in my logs?

Not quite. A brute-force attempt produces many short connections and a burst of failed logins from one source. A slow attack produces few connections that linger. Both patterns belong on the same dashboard, but each needs its own threshold rule.

How often should I review my thresholds?

Review them on a regular schedule, and always after a major application change. New features shift your traffic baseline. A rule tuned to last year’s patterns may block real users today or miss a new attack shape.

Is a reverse proxy enough on its own?

A reverse proxy gives strong baseline protection, but treat it as one layer. Pair it with tuned server options, rate limiting, and monitoring. Test the whole stack against a simulated slow attack before you trust it in production.