What Is a TCP RESET Flood Attack?

A TCP RESET flood (or RST flood) is a protocol-based attack that sends large volumes of TCP segments with the RST (reset) flag set toward a target, either to exhaust connection-tracking resources on a target system or, when aimed at a specific active session with a valid sequence number, to abruptly terminate that session outright. Unlike FIN, RST closes a connection immediately without a teardown handshake, making it useful to attackers both as a denial-of-service volume technique and as a precision session-termination technique.

TL;DR: TCP RST packets terminate a connection immediately, without the multi-step exchange required by FIN. A RESET flood exploits this in two distinct ways: as a volumetric denial-of-service technique that forces stateful devices to process and track large numbers of RST packets against non-existent or targeted connections, and as a session-hijacking technique that injects a single, correctly-sequenced spoofed RST into an active session to terminate it. The first form pressures CPU and connection tables; the second disrupts specific sessions such as BGP peerings or long-lived API connections. Mitigation includes sequence number validation, stateful RST filtering, rate limiting, and edge-based TCP termination.

Last updated: 2026-08-27

How a TCP RESET Flood Works

The role of RST in the TCP state machine

The RST flag, defined in RFC 793 and RFC 9293, signals an abrupt, non-negotiated connection termination. Unlike the FIN-based close sequence, which requires both sides to exchange FIN and ACK, a single valid RST immediately tears down a connection on receipt:

Normal RST usage (legitimate):
Client → Server: SYN to closed port
Server → Client: RST (no listener on this port)
[No connection is created]

Normal RST usage (error condition):
Established connection encounters a protocol violation or abrupt close
One side → Other side: RST
[Connection immediately destroyed on both ends]

A RST is considered valid by the receiving stack if its sequence number falls within the current receive window for that connection (or, in some conservative implementations, matches exactly). This validation check is the fulcrum both attack forms below try to exploit or route around.

Form 1: RST flood as a denial-of-service technique

An attacker sends a continuous stream of RST packets, typically with spoofed source IP addresses, toward a target:

Normal traffic:
Client ──RST──▶ Server   [Server looks up matching connection, terminates if valid]

RST flood (DoS form):
Bot (spoofed IP: 198.51.100.10) ──RST──▶ Server  [state lookup: no match]
Bot (spoofed IP: 198.51.100.11) ──RST──▶ Server  [state lookup: no match]
Bot (spoofed IP: 198.51.100.12) ──RST──▶ Server  [state lookup: no match]
... [millions more per second]

Result: CPU spent on lookups rises; conntrack/firewall table entries churn;
        any RST that does match a real session terminates it immediately

Every RST packet, matched or not, forces a connection-state lookup on the receiving stack or any inline stateful firewall. At sufficient volume, this consumes CPU and pressures connection-tracking tables in the same way as ACK or FIN floods, but with the added risk that any packet that does happen to match an active, low-traffic connection terminates it instantly and without possibility of graceful recovery at the transport layer.

Form 2: RST flood as session hijacking / targeted termination

A more surgical use of RST does not rely on volume at all. If an attacker can determine or predict the four-tuple (source IP, source port, destination IP, destination port) and a valid sequence number for an active TCP session, a single spoofed RST packet can terminate that specific connection:

Targeted RST injection:
Attacker observes or predicts: 4-tuple + in-window sequence number of Session X
Attacker ──RST (spoofed as Session X endpoint)──▶ Target
[Target's stack validates sequence number falls in receive window]
[Session X terminates immediately]

This technique has a documented history against long-lived, predictable sessions such as BGP peering sessions between routers, where the endpoints, ports, and approximate sequence number ranges are more feasible to infer than for arbitrary short-lived connections. It has also been used historically for network-level censorship and connection disruption, where an on-path or on-network device injects RST packets to sever specific TCP flows without blocking at the IP layer.

The key difference from Form 1: session-hijack RST does not require high packet volume. A single correctly-sequenced packet is sufficient, which means volume-based detection alone will not catch it.

TCP RESET Flood vs. Related Flag-Based Floods

Detection Signals and Telemetry

Detecting the two forms requires different approaches: volume-based monitoring for the DoS form, and session-integrity monitoring for the hijack form.

# Socket and connection summary
ss -ti

# TCP counters — look for elevated reset-related counters
nstat -az | grep -i "reset\|rst\|tcpabort"

# Netfilter conntrack table state and growth
conntrack -L -p tcp | grep -c ESTABLISHED
cat /proc/sys/net/netfilter/nf_conntrack_count

# iptables counters on rules tracking RST without prior matching state
iptables -L -v -n

# Short capture window to inspect RST flag ratio versus total TCP traffic
tcpdump -i eth0 -c 20000 'tcp[tcpflags] & tcp-rst != 0' -nn

# For session-hijack detection: monitor unexpected session drops correlated with
# application/BGP logs rather than packet volume

Mitigation Techniques

TCP-AO (TCP Authentication Option, RFC 5925) and its predecessor TCP MD5 signature option are specifically relevant for protecting long-lived, high-value sessions like BGP peerings against targeted RST injection, since they make it computationally infeasible for an attacker to forge a valid RST without the shared secret.

Common Mistakes

How to Implement on Azion

Azion manages TCP session state at the network edge, which addresses both forms of RST flood differently:

• DDoS Protection provides always-on detection and mitigation for protocol floods, including anomalous RST volume, before traffic reaches 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.

For session-hijack-style RST injection against specific high-value sessions such as BGP peerings between your own infrastructure and upstream providers, session authentication (TCP-AO or TCP MD5) is a control implemented at the routing layer rather than at the Azion edge, and should be evaluated as a complementary measure alongside edge-based DDoS defenses.

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 RESET flood attack? A TCP RESET flood sends large volumes of TCP segments with the RST flag set toward a target. It exists in two forms: a volumetric denial-of-service technique that pressures connection tables and CPU, and a targeted session-hijacking technique that uses a single correctly-sequenced RST to terminate one specific active connection.

How is a RESET flood different from a FIN flood? FIN initiates an orderly, multi-step close that both sides must acknowledge. RST forces immediate, unilateral termination without any teardown handshake. A RESET flood in its DoS form churns connection tables similarly to a FIN flood, but any RST packet that matches a real session terminates it instantly rather than beginning a graceful close.

Can a single RST packet really terminate an active connection? Yes, if the packet’s sequence number falls within the receiving stack’s current window for that connection and the four-tuple (source IP, source port, destination IP, destination port) matches. This is the basis of the session-hijacking form of RST flood and does not require high packet volume.

Why are BGP sessions specifically vulnerable to RST injection? BGP peering sessions are long-lived and use predictable, often publicly known, IP addresses and ports, which narrows the guessing space for an attacker attempting to forge a valid RST. TCP-AO and TCP MD5 signature options exist specifically to authenticate these sessions and prevent unauthenticated RST injection.

How does a RESET flood differ from a SYN flood? SYN flood exhausts kernel memory during connection establishment by creating half-open connections. RESET flood in its DoS form exhausts CPU and connection-table capacity through repeated state lookups, and in its hijack form terminates a specific existing connection outright rather than exhausting a resource pool.

Does IP spoofing matter differently for the two RST flood forms? Yes. In the DoS form, spoofing helps distribute the attack across many apparent sources and avoid straightforward IP-based blocking. In the hijack form, spoofing is essential because the RST must appear to originate from one of the two legitimate endpoints of the targeted session.

Can rate limiting stop a session-hijack RST injection? No. Rate limiting is designed to catch high-volume traffic from a source. A session-hijack RST injection can succeed with a single well-formed packet, so it requires sequence number validation and, for critical sessions, cryptographic authentication rather than rate-based controls.

What is TCP-AO and how does it relate to RST flood defense? TCP-AO (TCP Authentication Option), defined in RFC 5925, cryptographically authenticates TCP segments using a shared key, replacing the older TCP MD5 signature option. It prevents an attacker without the shared key from forging a valid RST (or any other segment) for a protected session, directly addressing the session-hijack form of RST flood.

Is the DoS form of RST flood more dangerous than the hijack form? They are dangerous in different ways. The DoS form can degrade or disrupt service broadly by exhausting shared infrastructure like firewall state tables. The hijack form causes no broad resource exhaustion but can silently and repeatedly sever specific high-value connections, which may be harder to detect and attribute.

How does edge-based TCP termination help against RST floods? For the DoS form, a distributed network that terminates and manages TCP sessions absorbs the lookup and table-churn load before it reaches the origin. The hijack form targets specific sessions between two known endpoints and is generally addressed through session authentication at the routing or application layer rather than through edge traffic scrubbing.

Sources:

• IETF. “Transmission Control Protocol.” RFC 793. 1981.
• IETF. “Transmission Control Protocol (TCP).” RFC 9293. 2022.
• IETF. “The TCP Authentication Option.” RFC 5925. 2010.
• 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.”