What Is a Connection Flood Attack? | Exhausting Established-Connection Limits

A connection flood attack is a denial-of-service technique that opens and holds a very large number of fully-established TCP or application-layer connections to a target, exhausting the finite concurrent-connection or session-table capacity of load balancers, firewalls, or application servers rather than exploiting a specific protocol handshake weakness. Once the connection limit is reached, new legitimate clients are refused service even though the attack traffic itself may look completely valid.

TL;DR: Connection floods complete the full TCP (and often TLS and application) handshake on every connection, then keep the connections open — idle or with minimal activity — until the target’s concurrent-connection ceiling is exhausted. This differs fundamentally from a SYN flood, which never completes the handshake and exhausts a half-open connection queue instead. Connection floods target the fixed-size session tables of firewalls, the max_connections-style limits of load balancers, and the worker/thread pools of application servers. Mitigation combines per-IP connection caps, faster idle-connection reaping, horizontal capacity scaling, and edge-layer connection termination that absorbs concurrency before it reaches the origin.

Last updated: 2026-08-27

Why “fully established” is the key distinction

Every piece of infrastructure that processes TCP traffic — firewalls, load balancers, reverse proxies, and application servers — maintains some form of connection or session table: a finite data structure tracking the state of every active connection it is aware of. That table has a hard capacity ceiling, whether expressed as a firewall’s maximum concurrent sessions, a load balancer’s max_connections setting, or an application server’s thread or worker pool size.

A connection flood attack’s defining characteristic is that it does not try to exploit an incomplete or malformed handshake. Instead, it completes the handshake normally — TCP’s three-way handshake, and often the TLS handshake and even a valid application-layer request — and then simply keeps a very large number of these fully legitimate-looking connections open simultaneously. The attack traffic passes any check that only validates protocol correctness; the compromise is purely one of scale and concurrency.

Connection flood sequence (per connection, repeated at massive scale):

Attacker → Target: TCP SYN
Target → Attacker: TCP SYN-ACK
Attacker → Target: TCP ACK                    ← handshake fully completes
[Connection enters ESTABLISHED state, occupies a session-table entry]
Attacker: sends minimal or no further data, or issues occasional keepalives
[Connection remains ESTABLISHED indefinitely, or until an idle timeout]

Repeat across thousands to millions of source connections
(often via botnet, to spread source IPs and connection count)

Result: session table / connection-count ceiling reached
Target: refuses new connections or a keeps a full backlog queue,
        because it can no longer track additional legitimate sessions

Connection Flood vs. SYN Flood

Connection floods and SYN floods are often conflated because both exhaust a finite table by opening many connections, but the state each attack leaves those connections in — and therefore the defense required — is fundamentally different.

In practice, a SYN flood attacks the front door before anyone is let in; a connection flood lets everyone in the front door and then never leaves, until there’s no room for anyone else. See What Is a SYN Flood Attack? for the half-open handshake mechanism in detail.

Connection floods also differ from low-and-slow attacks like Slowloris: Slowloris deliberately keeps connections in an incomplete application-layer state (partial headers) to occupy a thread cheaply, while a connection flood’s connections are typically complete and valid at the application layer too — the attack relies on raw connection count rather than protocol-level ambiguity.

Which infrastructure components are exhausted

Connection floods can target the connection ceiling at several different layers of the stack, and the specific bottleneck determines which mitigation is relevant.

A connection flood aimed at a load balancer can exhaust its global connection ceiling without ever putting meaningful load on the application servers behind it. Conversely, a flood that gets past the load balancer can still exhaust a thread-per-connection application server’s much smaller pool even if the load balancer itself has plenty of headroom — which is why capacity has to be evaluated at every layer, not just the one facing the internet.

Detection signals and telemetry

Connection floods are visible primarily through connection-count and concurrency metrics rather than through malformed traffic or unusual request content.

# Total ESTABLISHED connections — compare against historical baseline
ss -o state established | wc -l

# Concurrent connections grouped by source IP — a flood from a modest
# botnet often shows a handful of source IPs with disproportionately
# high connection counts each
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# File descriptor usage for the serving process
lsof -p <pid> | wc -l

# Load balancer / reverse proxy: current vs. max configured connections
nginx -T | grep worker_connections

The combination of high concurrent connection count with disproportionately low request throughput is the clearest signature of a connection flood, distinguishing it from a legitimate traffic surge where connection count and request volume rise together.

Mitigation techniques

1. Per-IP concurrent connection limits

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 50;
limit_conn_status 429;

Capping how many concurrent connections a single source can hold directly limits how much of the connection table any one attacker (or compromised botnet node) can consume, without necessarily affecting normal users who rarely hold dozens of simultaneous connections open.

2. Aggressive idle-connection timeouts

keepalive_timeout 15s;

# Linux kernel: reduce time before an idle TCP connection is
# considered dead and its resources reclaimed
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 4

Shorter idle timeouts reduce how long an attacker’s connections can occupy table space without sending meaningful traffic, forcing them to either send real data (raising their cost and visibility) or reconnect (which per-IP limits can then catch).

3. Horizontal capacity and connection-table sizing

Increasing the connection ceiling — larger firewall state tables, higher max_connections on load balancers, more application server workers or an event-driven architecture — raises the bar an attacker must clear, though it is a scaling response rather than a structural fix, since a sufficiently large botnet can still exceed any fixed capacity increase.

4. Distinguish idle floods from legitimate concurrency with behavioral rules

A WAF or application-layer control can flag connections that remain open significantly longer than the median for a given endpoint, or that show near-zero request activity relative to their connection duration, and apply stricter limits or challenges to that subset rather than to all traffic.

5. Terminate connections at a distributed edge layer

Placing a distributed network in front of the origin means a connection flood’s raw concurrency is absorbed across many edge locations and a large aggregate connection capacity, rather than concentrated against a single origin’s finite session table. Only connections the edge forwards — typically a much smaller, filtered set — reach the origin’s own connection pool.

Common mistakes

How to Implement on Azion

Azion’s edge network terminates connections ahead of the origin, which changes where a connection flood’s raw concurrency actually lands.

• Firewall can apply per-IP and aggregate concurrent connection limits before traffic reaches origin infrastructure
• Network Shield can help filter and rate-limit connection attempts at the network layer, depending on configured Network Lists and rules
• DDoS Protection provides always-on detection aimed at connection-based exhaustion patterns, including large-scale concurrent connection floods
• Load Balancer can help distribute accepted connections and shield the origin’s own connection pool from directly facing attack concurrency
• WAAP combines these controls for teams that want WAF, DDoS protection, and related defenses layered together

Because Azion’s distributed network holds a substantially larger aggregate connection capacity than a typical single origin, and forwards to origin only the traffic that clears edge-side filtering, a connection flood’s concurrency is generally absorbed across the edge rather than concentrated against the origin’s session table.

Related Resources

• What Is a SYN Flood Attack?
• Low and Slow Attacks
• What Is a DDoS Attack?
• What Is an HTTP Flood Attack?
• Azion DDoS Protection
• Azion Network Shield

Frequently Asked Questions

What is a connection flood attack? A connection flood attack opens and holds a very large number of fully-established connections to a target, exhausting the finite concurrent-connection capacity of firewalls, load balancers, or application servers. Unlike attacks that exploit an incomplete handshake, every connection in a connection flood is typically valid and fully established.

How is a connection flood different from a SYN flood? A SYN flood never completes the TCP handshake — it leaves connections in a half-open state to exhaust a backlog queue, and is often mitigated with SYN cookies. A connection flood fully completes the handshake and keeps real, established connections open to exhaust the session table or connection pool. SYN cookies and half-open-state defenses have no effect on a connection flood because the handshake has already finished.

Does a connection flood require IP spoofing? Generally no. Because connections must be fully established to consume session-table space in this attack, the source typically needs to complete a real handshake, which spoofed source IPs cannot reliably do. Connection floods are more commonly executed via botnets using real, distinct IP addresses.

What infrastructure components can a connection flood exhaust? Any component maintaining a finite connection or session table: stateful firewalls, load balancers with a configured max_connections, reverse proxies limited by settings like worker_connections, thread-per-connection application servers, and even operating system file descriptor limits.

How do you detect a connection flood in progress? Look for a sustained, elevated count of ESTABLISHED connections that is disproportionate to actual request throughput, often concentrated on a subset of source IPs holding an unusually high number of concurrent connections each. Tools like ss -o state established and per-IP connection breakdowns are the primary diagnostic commands.

Can rate limiting requests per second stop a connection flood? Not directly. Request-rate limiting caps how many requests a source can send, but a connection flood’s connections may send few or no requests at all — the attack’s leverage is holding the connection itself open, not the request volume flowing through it. Concurrent connection limits (per IP and in aggregate) are the more directly applicable control.

Do idle connections without any data still count against connection limits? Yes. Most connection and session tables count any established connection regardless of activity level. An idle connection with no data flowing still occupies a table entry until it is closed or an idle timeout reclaims it, which is exactly the mechanic a connection flood relies on.

Is increasing max_connections or the connection table size an effective fix? It raises the bar an attacker needs to clear, and can help against smaller-scale floods, but it is a capacity increase rather than a structural defense. A sufficiently large botnet can still exceed most single-origin capacity increases, so capacity tuning should be paired with per-source limiting and edge-layer absorption rather than used alone.

Can a connection flood happen over TLS/HTTPS? Yes, and it can be more resource-intensive for the target than a plaintext connection flood, because each connection may also involve a TLS handshake and negotiated session state, which itself consumes CPU and memory beyond the base TCP session-table entry.

How does a connection flood relate to low-and-slow attacks like Slowloris? Both exhaust a finite server resource by holding many connections open, but a connection flood typically relies on raw connection count with the application layer often behaving normally, while Slowloris specifically keeps connections in an incomplete application-layer state (partial HTTP headers) to occupy a thread with even fewer connections. See Low and Slow Attacks for the broader category these techniques belong to.

What’s the fastest way to tell a connection flood apart from a legitimate traffic spike? Compare connection count growth against request throughput growth. In a legitimate spike, both rise together as real users make requests. In a connection flood, connection count rises sharply while request throughput stays flat or grows far more slowly, because most of the connections are idle or near-idle.

Sources

• IETF. “Transmission Control Protocol.” RFC 793.
• IETF. “Requirements for Internet Hosts — Communication Layers.” RFC 1122 (connection state handling).
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• CISA. “Understanding Denial-of-Service Attacks.”
• nginx. “Module ngx_http_limit_conn_module.” Official Documentation.