A TCP FIN flood is a protocol-based DDoS attack that sends large volumes of TCP segments with the FIN (finish) flag set toward a target, forcing the receiving stack and any stateful firewalls in the path to process connection-termination logic for sessions that frequently do not exist. Because FIN packets trigger teardown state transitions and connection-tracking table updates, sustained FIN floods can churn firewall and conntrack tables even without completing a real handshake first.
TL;DR: TCP uses the FIN flag to signal an orderly close of one direction of a connection, moving the session through teardown states (FIN_WAIT, CLOSE_WAIT, TIME_WAIT) before removing it from tracking tables. A FIN flood sends high volumes of FIN packets, usually with spoofed source addresses, for connections that either never existed or that the attacker is trying to prematurely close. Stateful devices must look up connection state for every FIN packet, and tables can churn or fill under volume. Mitigation relies on stateful validation of FIN packets against tracked sessions, connection-table tuning, rate limiting, and edge-based TCP termination.
Last updated: 2026-08-27
How a TCP FIN Flood Works
The role of FIN in TCP connection teardown
TCP connections close through a four-step exchange defined in RFC 793 and RFC 9293:
Normal TCP close sequence:Client → Server: FIN (client has no more data to send)Server → Client: ACK (acknowledges client's FIN)Server → Client: FIN (server has no more data to send)Client → Server: ACK (acknowledges server's FIN)[Connection fully closed after both sides FIN and ACK]Each FIN transitions the connection through intermediate states — FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, LAST_ACK, TIME_WAIT — before the entry is finally removed from the connection table. TIME_WAIT specifically holds state for a defined interval (commonly twice the maximum segment lifetime) to handle delayed or duplicate packets safely.
How the flood exploits teardown processing
An attacker sends a continuous stream of FIN packets, commonly with spoofed source IP addresses and often targeting port/connection tuples that do not correspond to any real session:
Normal traffic:Client ──FIN──▶ Server [Server looks up matching connection, processes teardown]
FIN flood:Bot (spoofed IP: 203.0.113.1) ──FIN──▶ Server [state lookup: no match, or forced teardown]Bot (spoofed IP: 203.0.113.2) ──FIN──▶ Server [state lookup: no match, or forced teardown]Bot (spoofed IP: 203.0.113.3) ──FIN──▶ Server [state lookup: no match, or forced teardown]... [millions more per second]
Result: Conntrack/firewall state table entries churn or fill; CPU spent on lookups rises; legitimate teardown may be delayedThe attack has two distinct effects depending on whether the targeted connection exists:
- Against non-existent connections: Every FIN packet still requires the receiving stack or an inline stateful firewall to perform a lookup against tracked connections. At sufficient volume, this consumes CPU and, on devices that create provisional table entries for unmatched segments, can churn the connection table itself.
- Against existing connections: If an attacker can guess or observe sequence numbers for an active session (more feasible on off-path or on-path attackers, or in networks with weak sequence number randomization), a spoofed FIN can prematurely terminate a legitimate connection, disrupting the application layer without necessarily generating large traffic volumes.
Why FIN floods are effective against middleboxes
Stateful firewalls, load balancers, and intrusion prevention systems must track TCP state to enforce policy correctly. Unlike a simple packet filter, these devices maintain their own connection tables independent of the origin server’s kernel. A FIN flood forces every one of these intermediate devices to perform state lookups and table updates, which means the bottleneck can appear on infrastructure well before it appears on the origin server itself.
TCP FIN Flood vs. Related Flag-Based Floods
| Attack | Flags used | Connection required | Primary effect | Typical exhausted resource |
|---|---|---|---|---|
| TCP FIN Flood | FIN | No (more damaging if yes) | Teardown state churn, premature session close | Conntrack/session-table entries, CPU |
| TCP RESET Flood | RST | No (session-hijack variant needs yes) | Immediate connection termination without teardown handshake | Conntrack entries, active sessions |
| TCP ACK-PSH Flood | ACK, PSH | No (more damaging if yes) | Buffer-handling and lookup CPU cost | CPU, application buffers |
| SYN Flood | SYN | No | Half-open connection memory exhaustion | Kernel connection table |
Detection Signals and Telemetry
# Socket states — FIN-related states should be a small, predictable fractionss -ti state fin-wait-1 state fin-wait-2 state closing state last-ack state time-wait
# TCP counters — check for anomalous teardown-related countersnstat -az | grep -i tcp
# Netfilter conntrack: look for entries stuck in FIN-related statesconntrack -L -p tcp --state FIN_WAITcat /proc/sys/net/netfilter/nf_conntrack_count
# iptables counters on rules tracking FIN-only or FIN-without-prior-SYN packetsiptables -L -v -n
# Short capture window to inspect FIN flag ratio versus total TCP traffic (avoid on high-PPS attacks)tcpdump -i eth0 -c 20000 'tcp[tcpflags] & tcp-fin != 0' -nn| Indicator | Normal traffic | During FIN flood |
|---|---|---|
| FIN packets/second | Proportional to session close rate | Sharp, sustained increase |
| FIN packets with no matching session | Near zero | High and sustained |
| conntrack entries in FIN/TIME_WAIT states | Small, bounded fraction | Disproportionate growth |
| Source IP diversity on FIN traffic | Consistent with real client base | High, often randomized or spoofed |
| Premature session termination reports (application layer) | Rare | Correlated spikes during attack window |
Mitigation Techniques
| Technique | How it works | Effectiveness |
|---|---|---|
| Stateful FIN validation | Drop FIN packets that do not correspond to a tracked, active session | High for non-spoofed and simple spoofed floods |
| Sequence number randomization | Makes it far harder to forge a FIN that matches an active session’s expected sequence number | High against session-hijack-style FIN abuse |
| Rate limiting per source | Cap FIN packets per source IP per second | Medium — limited against distributed, spoofed sources |
| Connection-table tuning | Adjust TIME_WAIT duration and table size to absorb bursts without exhausting memory | Medium — delays but does not resolve large-scale saturation |
| Edge TCP termination | Terminate and manage TCP sessions at a distributed network before traffic reaches origin | Very high |
| BCP38 / uRPF at upstream providers | Reduce spoofed source addresses entering transit | High as a systemic, longer-term control |
Sequence number validation matters specifically for FIN floods aimed at hijacking or prematurely closing active sessions: a receiving stack should only honor a FIN whose sequence number falls within the current receive window for that connection, which sharply limits blind (off-path, spoofed) FIN injection.
Common Mistakes
| Mistake | Impact | Correct approach |
|---|---|---|
| Assuming FIN floods only affect the origin server | Intermediate stateful devices (firewalls, load balancers) often saturate first | Monitor connection-table health on every stateful device in the path, not just the origin |
| Treating all FIN traffic as equally suspicious | Legitimate connection churn (short-lived HTTP/API connections) also generates FIN traffic | Baseline normal FIN rate per service before setting anomaly thresholds |
| Ignoring sequence number validation | Makes premature session termination easier for attackers | Enforce strict sequence number window checks before honoring FIN |
| Relying only on connection-table size increases | Delays saturation but does not address the underlying churn | Combine table tuning with rate limiting and upstream or edge filtering |
| Not correlating FIN flood with application-layer session drops | Missed detection of session-hijack-style FIN abuse | Correlate network-layer FIN anomalies with application session termination logs |
How to Implement on Azion
Azion manages TCP connection lifecycle at the network edge, changing where FIN flood traffic is absorbed and validated:
- DDoS Protection provides always-on detection and mitigation for protocol floods, including anomalous FIN traffic patterns, before they reach the origin.
- Network Shield applies programmable network-layer rules to block sources associated with flood traffic based on IP, CIDR, and ASN.
- Firewall enables custom rules for connection-state validation and rate-based filtering.
- WAAP combines network and application-layer protections for environments facing blended attacks.
Because Azion terminates and tracks TCP sessions at distributed points of presence, FIN packets that do not match an edge-validated session are handled before they can churn origin-side connection tables.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is a SYN Flood Attack?
- What Is DDoS Protection and Mitigation?
- Azion DDoS Protection
Frequently Asked Questions
What is a TCP FIN flood attack? A TCP FIN flood sends large volumes of TCP segments with the FIN flag set toward a target, often for connections that do not exist or with spoofed source addresses. Each FIN forces a connection-state lookup and potential teardown processing, which can churn firewall and conntrack tables at sufficient volume.
How is a FIN flood different from a RESET flood? FIN signals an orderly close and moves a connection through multiple teardown states (FIN_WAIT, TIME_WAIT, and others) before removal. RST forces immediate, abrupt termination without the multi-step teardown handshake. FIN floods primarily churn state-machine transitions and table entries over time; RST floods terminate sessions instantly on receipt.
Can a FIN flood target an existing, active connection? Yes. If an attacker can forge a FIN with a sequence number that falls within a connection’s current receive window, the receiving stack may honor it as legitimate, prematurely closing an active session. This requires knowledge or prediction of sequence numbers, which strong sequence number randomization makes substantially harder.
Does a FIN flood require IP spoofing? No, but spoofing is common because it complicates source-based blocking and, for floods against non-existent connections, has no functional downside for the attacker. Non-spoofed FIN floods from a botnet with real IPs are also possible and are mitigated with rate limiting per source.
How does a FIN flood differ from a SYN flood? SYN flood targets connection establishment, exhausting kernel memory with half-open connections. FIN flood targets connection teardown, exhausting CPU and connection-table capacity on state lookups and teardown transitions. SYN cookies address SYN flood but have no effect on FIN flood.
Why do stateful firewalls struggle with FIN floods? Stateful firewalls maintain their own connection-tracking tables independent of the origin server. Every FIN packet requires a lookup against that table, and at sufficient volume the firewall’s own table and CPU can become the bottleneck before the origin server is affected at all.
What is TIME_WAIT and why does it matter for FIN flood analysis? TIME_WAIT is the state a connection enters after both sides have exchanged FIN and ACK, held for a defined interval to safely handle delayed or duplicate packets. A disproportionate spike in TIME_WAIT or other FIN-related states relative to real traffic is a strong signal of FIN flood activity.
Can rate limiting alone stop a FIN flood? Rate limiting per source IP is effective against non-spoofed floods from a limited set of sources. Against highly distributed or spoofed FIN floods, per-IP rate limiting has limited effect because each packet may appear to originate from a different, often single-use, source address.
Does increasing the connection table size fix FIN flood exposure? It delays saturation but does not resolve the underlying issue. A sufficiently large flood will eventually saturate any table size increase. Table tuning is a containment measure that should be combined with rate limiting, sequence number validation, and upstream or edge-based filtering.
How does edge-based TCP termination help against FIN floods? When a distributed network completes and manages TCP sessions on behalf of the origin, only sessions validated at the edge are forwarded. Spoofed or out-of-session FIN packets are absorbed and processed by the edge network’s infrastructure, which is built to handle this state load, rather than by the origin’s connection table.
Sources:
- IETF. “Transmission Control Protocol.” RFC 793. 1981.
- IETF. “Transmission Control Protocol (TCP).” RFC 9293. 2022.
- IETF. “Defending Against Sequence Number Attacks.” RFC 6528. 2012.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
- CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”