Distributed denial-of-service attacks do not always send malicious traffic directly from the attacker’s infrastructure to the intended victim.
Attackers can abuse third-party servers, network appliances, and middleboxes to generate traffic toward a target. This allows them to hide the true source of the attack while distributing malicious traffic across a large number of legitimate IP addresses.
One attack method that uses this technique is known as a TCP reflection attack.
What Is a TCP Reflection Attack?
In a TCP reflection attack, the attacker sends TCP packets using a spoofed source IP address. Instead of using their own IP address, the attacker places the victim’s IP address in the source field of each packet.
Third-party systems receive these packets and send their responses to the victim. As a result, the victim receives large volumes of TCP responses for connections it never initiated.
How Does a TCP Reflection Attack Work?
A standard TCP connection is established through a three-way handshake:
-
The client sends a
SYNpacket to the server. -
The server responds with a
SYN-ACKpacket. -
The client sends an
ACKpacket to complete the connection.
During a TCP reflection attack, the attacker sends SYN packets
to a large number of public TCP services while spoofing the victim’s IP
address as the source.
The receiving servers believe that the victim initiated the connection.
They therefore send their SYN-ACK responses directly to the
victim.
Attack flow:
Attacker → Spoofed SYN packets → Third-party TCP servers → SYN-ACK responses → Victim
Because the victim never initiated these connections, the incoming responses do not correspond to legitimate TCP sessions.
When thousands of reflectors generate responses simultaneously, the resulting traffic can consume network capacity, overwhelm routers and firewalls, or place significant pressure on the operating system’s networking stack.
Some systems may also retransmit their SYN-ACK packets several
times when they do not receive the expected final ACK. These
retransmissions can increase the packet rate and extend the duration of the
attack.
Are TCP Reflection and TCP Amplification the Same?
Not every TCP reflection attack provides significant bandwidth amplification.
In a traditional SYN-ACK reflection attack, the attacker’s
SYN packet and the reflector’s SYN-ACK response
are usually similar in size.
The effectiveness of this attack primarily comes from:
- Using a large number of reflector systems
- Triggering repeated SYN-ACK retransmissions
- Generating an extremely high packet-per-second rate
- Distributing traffic across many legitimate source addresses
- Spreading the attack across an entire subnet
There is also a more advanced technique known as TCP middlebox reflection.
Middleboxes can include:
- Firewalls
- Intrusion detection and prevention systems
- Content filtering gateways
- Transparent proxies
- Censorship systems
- Other network security appliances
Some incorrectly implemented middleboxes may generate large block pages, warning messages, or other responses after receiving specially crafted TCP packets.
In these situations, a relatively small spoofed packet can trigger a much larger response. This creates actual traffic amplification in addition to reflection.
TCP Reflection Attack vs. SYN Flood
TCP reflection attacks and SYN floods both abuse TCP behavior, but they operate differently.
SYN Flood
In a SYN flood attack, the attacker sends large numbers of
SYN packets directly to the target server.
The target may allocate resources for each incomplete connection, eventually exhausting its connection backlog, memory, or processing capacity.
TCP Reflection
In a TCP reflection attack, the victim normally receives TCP response packets from third-party systems.
These packets may include:
SYN-ACKpacketsACKpacketsRSTpackets- TCP packets containing application data
- Responses generated by middleboxes
The main distinction is the direction of the traffic:
- In a SYN flood, the victim receives connection requests.
- In a TCP reflection attack, the victim receives responses to connections it never initiated.
Because the packet direction, TCP flags, and connection states are different, each attack requires a different detection and mitigation strategy.
Why Are TCP Reflection Attacks Dangerous?
TCP reflection attacks can be difficult to mitigate because the traffic does not appear to come directly from the attacker.
Packets may originate from real servers, network appliances, or publicly accessible services. Blocking traffic solely according to source IP addresses is therefore rarely an effective long-term solution.
High Packet Rates
TCP reflection attacks can reach extremely high packet-per-second rates even when individual packets are relatively small.
A high-PPS attack can overload:
- Router forwarding capacity
- Firewall processing capacity
- Network interface queues
- Connection tracking systems
- Operating system networking stacks
- CPU resources on the protected server
In these attacks, the packet rate can be more damaging than the total bandwidth value.
Distributed and Legitimate-Looking Sources
The incoming packets may originate from thousands of unrelated and legitimate systems.
This makes basic source-based access control lists ineffective and increases the risk of blocking legitimate traffic.
SYN-ACK Retransmissions
Some TCP implementations retransmit unanswered SYN-ACK packets
multiple times.
Because the victim never initiated the connection, it does not complete the TCP handshake. The reflector may continue sending responses, increasing the volume and duration of the attack.
Connection Tracking Exhaustion
Traditional stateful firewalls may attempt to inspect or track every incoming TCP packet.
During a high-rate attack, this can consume connection tracking table capacity, memory, and CPU resources before the packets reach the protected application.
Carpet Bombing
Attackers may distribute traffic across many IP addresses inside the same protected prefix instead of targeting a single server.
For example, rather than directing 20 million packets per second toward one
IP address, the attacker may spread the traffic across hundreds of addresses
within a /24 subnet.
The traffic directed at each individual IP may appear to remain below local detection thresholds, while the combined attack still saturates the customer’s connection or overwhelms shared infrastructure.
This technique is commonly known as carpet bombing.
How Does NorthShield Mitigate TCP Reflection Attacks?
NorthShield does not identify TCP reflection attacks using only static packet-per-second limits or source IP blocklists.
The NorthShield mitigation infrastructure analyzes the TCP state, packet direction, TCP flags, destination service, packet size, source distribution, and normal traffic profile of the protected network.
This makes it possible to distinguish reflected attack traffic from legitimate TCP communication.
1. Real-Time TCP Flag and Traffic Analysis
NorthShield continuously analyzes traffic characteristics such as:
- Unexpected
SYN-ACKpackets -
ACKorRSTpackets that do not match expected connection behavior - Invalid or unusual TCP flag combinations
- Abnormal source port distributions
- Sudden changes in packet rate
- Repeated TCP retransmission patterns
- Traffic distributed across multiple destination IP addresses
- Deviations from the protected service’s normal traffic profile
This allows NorthShield to classify traffic according to its behavior rather than relying only on the source IP address.
Because reflection traffic can originate from legitimate systems, behavioral analysis is essential for accurate mitigation.
2. Connection-Aware Validation
NorthShield evaluates whether incoming TCP packets are associated with expected and legitimate connection states.
For example, an unexpected SYN-ACK packet sent toward a public
service may indicate reflection traffic. However, blocking every inbound
SYN-ACK packet would not be correct.
A protected server may initiate legitimate outbound connections and receive
valid SYN-ACK responses.
NorthShield therefore applies policies according to:
- The customer’s routing architecture
- The direction of protected traffic
- The services running on the protected network
- Expected connection behavior
- Whether routing is symmetric or asymmetric
- Customer-specific filtering requirements
This prevents legitimate outbound connections from being disrupted while allowing invalid reflected traffic to be removed.
3. XDP/eBPF-Based Early Packet Filtering
Once traffic has been classified as malicious, NorthShield can drop it at the XDP/eBPF layer before it reaches higher layers of the Linux networking stack.
XDP provides a high-performance packet-processing point close to the network interface driver.
Packets receiving an XDP_DROP decision are discarded before
they reach components such as:
- The Linux TCP/IP stack
- Connection tracking
- Socket processing
- Userspace applications
- The protected service
This early-drop architecture significantly reduces unnecessary CPU, memory, and connection tracking usage during high-PPS attacks.
Instead of allowing every reflected packet to pass through the full operating system network stack, NorthShield processes and drops malicious traffic as early as possible.
4. Stateful and Direction-Aware Filtering
NorthShield’s mitigation logic considers the expected direction and state of TCP connections.
The system can identify situations where:
- A server receives responses for connections it never initiated
- TCP packets do not match an established or expected flow
- Large numbers of systems send similar responses to the same destination
- The same attack signature is distributed across multiple destination addresses
- TCP flags are inconsistent with the protected service’s role
This is particularly important in asymmetric routing environments, where incoming and outgoing traffic may follow different network paths.
NorthShield supports both symmetric and asymmetric routing architectures and applies filtering policies according to the customer’s deployment model.
5. SYN Proxy and TCP Handshake Validation
For suitable services, NorthShield can require clients to complete the TCP handshake before their connection is forwarded to the origin server.
An attacker using a spoofed source IP address cannot normally receive the
SYN-ACK response and therefore cannot correctly complete the
handshake.
This makes TCP handshake validation effective against spoofed TCP attacks.
SYN Proxy is particularly useful for direct SYN floods, but it can also be used as part of a broader TCP protection strategy against mixed attacks involving reflection, spoofing, and invalid connection states.
The feature can be enabled according to the customer’s application requirements and routing architecture.
6. Prefix-Wide Carpet Bombing Detection
NorthShield does not monitor each protected IP address in isolation.
Traffic behavior can also be analyzed across the entire protected prefix. This allows the platform to identify attacks that distribute traffic across multiple addresses in an attempt to remain below per-IP thresholds.
NorthShield can correlate:
- Aggregate packet rate across the subnet
- Shared TCP flag patterns
- Common source port behavior
- Similar packet sizes
- Sudden traffic increases across multiple destinations
- Repeated traffic signatures affecting the entire prefix
Once a distributed attack pattern is identified, mitigation policies can be applied across the affected network without relying on a single destination IP threshold.
7. Filtering Before Traffic Reaches the Origin
Attack traffic is removed at NorthShield filtering locations before clean traffic is delivered to the customer’s infrastructure.
Depending on the deployment requirements, clean traffic can be delivered through:
- GRE tunnels
- IPIP tunnels
- BGP routing
- Direct network connectivity
- Symmetric routing
- Asymmetric routing
This helps prevent reflected traffic from consuming resources on the customer’s servers, routers, firewalls, and application infrastructure.
Can a WAF Stop a TCP Reflection Attack?
A traditional Web Application Firewall is not sufficient by itself to stop a TCP reflection attack.
A WAF primarily analyzes Layer 7 protocols such as HTTP and HTTPS. It is designed to detect threats such as:
- Malicious HTTP requests
- Application-layer floods
- SQL injection
- Cross-site scripting
- Automated bot activity
- Abuse of application endpoints
TCP reflection attacks generally occur at Layer 3 or Layer 4.
The attack may saturate the internet connection or overload the router and firewall before any valid HTTP request is created. In many cases, the malicious packet never reaches the application layer at all.
For this reason, TCP reflection attacks must be mitigated at the network and transport layers, preferably before the traffic reaches the protected origin.
NorthShield combines Layer 3 and Layer 4 mitigation with optional application-specific filters for attacks that reach higher protocol layers.
Conclusion
TCP reflection attacks abuse source IP spoofing and the normal response behavior of third-party systems to direct unwanted TCP traffic toward a victim.
Although traditional SYN-ACK reflection may not always provide significant bandwidth amplification, it can still generate extremely high packet rates through large reflector sets and repeated retransmissions.
Incorrectly implemented middleboxes can also generate much larger responses, turning TCP reflection into a true amplification attack.
These attacks become especially disruptive when they involve:
- High packet-per-second rates
- Thousands of distributed reflectors
- SYN-ACK retransmissions
- Invalid TCP connection states
- Connection tracking exhaustion
- Prefix-wide carpet bombing
NorthShield mitigates TCP reflection attacks using real-time traffic analysis, connection-aware validation, prefix-wide anomaly detection, SYN Proxy capabilities, and high-performance XDP/eBPF filtering.
Malicious packets are identified and dropped before they reach the protected origin, while legitimate traffic continues to be delivered according to the customer’s routing and deployment requirements.
Protect Your Network with NorthShield
NorthShield provides high-performance DDoS protection for hosting providers, game servers, enterprises, data centers, and internet service providers.
Learn more about our network protection services at northshield.network.

