In mid-April, NSFOCUS discovered that one of its Cloud DDoS Protection Service customer in APAC region has encountered a TCP-middlebox-reflection attack which became popular throughout the world during past months after its first discourse in Aug, 2021.
The attack reached its peak at 7Gbps and lasted for several hours, after immediate reaction by NSFOCUS Managed Security Service, only around 20Mbps of egress traffic reached customer network after mitigation, or to say at least 97.2% of all the attacks are mitigated while only 2.8% of the total traffic left.
“Unsuccessful” TCP reflection amplification attack
In a typical distributed TCP reflection, attackers use instructions to control the behavior of botnet, including hacked IoT devices or other hosts.
The botnet generates a SYN packet with spoofed source IP (actually the victim’s IP address), and sends it to a TCP server (such as an HTTP server, FTP server, mail server, etc.) on the internet.
After the TCP server receives the forged SYN packet, it will send the corresponding SYN/ACK, ACK, RST and other packets to the victim’s IP address as written in the SYN packet.
This type of TCP reflection attack mainly uses the TCP handshake mechanism.
Identification of the attack will be difficult as the attack source is a legitimate TCP server.
From attacker’s view, the drawback is also significate – the amplification ratio is small as it mainly depends on the SYN /ACK packet retransmission. It means generate a sufficient volume TCP reflection is more difficult than other attack vectors. That is why TCP reflection amplification attack was not popular among the attackers in quite long time.
What is new in TCP-middlebox-reflection attack
On contrast to traditional TCP reflection, TCP-middlebox-reflection is quite dangerous due to its large amplification ratio which could reach 10,000 times and even more.
TCP-middlebox-reflection attack are targeting network equipment used for censorship purpose on internet-backbone by law enforcement agencies or devices in enterprise network used for content filtering (often used for monitors and controls improper content when enterprise employee’s accesses internet services). Those devices are logically working in the middle between client and server and that is how “middlebox” is named.
Some of these middlebox do not check TCP states during their monitoring work so they might trigger their policies and send a series of response to client to enforce the block action after receiving a fake TCP request generated by attacker. This response can be quite large comparing to the original request, so that attackers can generate mass volume of malicious traffic accordingly.
Suggestions for protecting your business
- During SYN packets with payload in reflection attacks, you can block such SYN SYN packets with payload.
- For other packets with payload (e.g. PSH+ACK) generated in attacks, TCP packets with source port 80 or 443 can be blocked. Note that this may influence your service which need to send out HTTP requests.
- Use Geo IP to block country/region where you will not have clients.
- NSFOCUS Anti-DDoS System (ADS) users may not need to do the above measurements, you could just active ACK check algorithm and the ADS will send challenges to check if the TCP session is legitimate. This could completely filter out malicious traffic.
- Try to apply a large-volume Cloud DDoS Mitigation service which allows you to keep your business continuity as the TCP-middlebox-reflection attack can be larger than traditional TCP reflection attack.
Ensure you will not be the “Middlebox”
If you are having a Middlebox (can be Firewall, Intrusion Prevention System, Secure Web Gateway, Data Loss Prevention or other gateways containing content filtering function), it might be targeted and became part botnet used for TCP-middlebox-reflection attack.
This will consume your internet bandwidth and performance of the middlebox, in the worst case this could further risk yourself under claims or even counter-attacks from the victim.
- Make sure your middlebox is deployed in your network with access to both inbound and outbound traffic, this makes it possible for middlebox to check the integrity of the TCP session and prevent itself from being abused.
- Let your middlebox ignore malicious TCP packets when do filtering, e.g. do not respond to SYN+HTTP requests.
- Keep your blocking message/page generated by middlebox simple and small, this can help to relieve the upstream bandwidth consumption when abused by the attacker.
- When your middlebox find the source IP does not respond to the block message, send an RST to disconnect and stop sending more.
- You may check with your Middlebox vendor to see if they are influenced and get relevant patch in the first minute when necessary.
