TCP-AMP DDoS Attack - Fake abuse reports problem

A very old attack method called TCP-AMP ( ) has been getting really popular recently.

I’ve been a victim of it multiple times on many of my IP’s and every time it happens - My IP’s end up getting blacklisted in major big databases. We also receive tons of abuse reports for “Port Scanning”.

Example of the reports we’re getting:

tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV)
tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV)

OVH are threatening to kick us off their network, because we are victims of this attack. And requesting us to do something about it, despite the fact that there is nothing you can do when you are being victim of an DDoS Attack.

Anyone else had any problems with these kind of attacks?

The attack basically works like this;

  • The attacker scans the internet for TCP Services, i.e port 80.
  • The attacker then sends spoofed requests from our IP to these TCP Services, which makes the remote service attempt to connect to us to initiate the handshake… This clearly fails.
    … Which ends up with hundreds of request to these services, reporting us for “port flood”.


Help saving precious resources by unsubscribing from the NANOG mailing list, or I will have to report the abuse.


Since OVH has been offering DDOS protection capable of soaking up hundreds of gigabits+ per second as a standard with all their services for a long time, I’m assuming this is a miscommunication / standard support response.

I would try to get in touch with the network team and include pcaps.



It doesn’t sound to be a real amplification… If it is, can anyone provide the amplification factor? 1x?

It sounds more like a TCP spoofing.


If I read your description correctly:

  • Attacker sends spoofed TCP SYN from your IP address(es) and different src ports, to some TCP servers (e.g. port 80)
  • TCP servers respond with SYN/ACK ; many servers resend the SYN/ACK hence amplification .
  • *** your system does not respond ***
  • Servers may think you’re doing SYN-Flood against them, since connection remains in SYN_RCVD, and hence complain. In fact, we don’t really know what is the goal of the attackers; they may in fact be trying to do SYN-Flood against these servers, and you’re just a secondary victim and not the even the target, that’s also possible.

Anyway, is this the case?

If it is… may I ask, do you (or why don’t you) respond to the unsolicited SYN/ACK with RST as per the RFC?

I suspect you don’t, maybe due to these packets being dropped by FW/NAT, that’s quite common. But as you should understand by now from my text, this (non-standard) behavior is NOT recommended. The problem may disappear if you reconfigure your FW/NAT (or host) to respond with RST to unsolicited SYN/ACK.

As I explained above, if my conjectures are true, then OVH as well as the remote servers may have a valid reason to consider you either as the attacker or as an (unknowning, perhaps) accomplice.

I may be wrong - sorry if so - and would appreciate, in any case, if you can confirm or clarify, thanks.

Some reading for you:


Amir: you’re exactly correct – but since you asked, here’s their answer from the last time I suggested they respond with RSTs:


hhh well Damian, Ok, I guess a free service has some costs :slight_smile:

More seriously, did you try to follow up and explain how dropping your RST packets may be exactly the reason for the attacker to abuse your IP space for the attack? Also, you may ask the provider of the victim to block SYN packets from your IP range (assuming the victim isn’t some service that your clients will want to access). If all fails… then all failed.

Good luck responding to such SYN/ACK, when you get 10+Gbps of them (real case happened while ago with colleague).
Sure those SYN/ACK are not from single location, and attackers might use whole /24 for SYN spoofing.

Yeah this type of attack is a pain in the ass to deal with.

Attacker is spoofing your IP addresses to millions of random web servers all over the Internet that see it as a typical SYN Flood those with automated reporting are likely blowing up OVH’s abuse@ making a pain for them as well.
However, OVH likely could easily check netflow or some other audit means to see your server didn’t actually send out SYN packets to these servers. They likely are able to confirm the influx of inbound SYN-ACK packets that can be up to six depending on the TCP/IP stack of the server.
The others are correct if you send out TCP Reset rejections you can tare down these bad states on the victim reflector’s side to avoid getting retry SYN-ACK’s.

At this point I would consider whatever IP that you have that’s getting attacked as burned, you’re best bet is to drop those affected subnets and get new ones and avoid getting them exposed to whoever is attacking you.

Spoofing issues has been the bane of any operator for years, till all the ASN’s are on board with proper anti spoofing, ddos abuse of spoofing will be on-going and always an issue.

It is spoofing, but it is also absolutely amplification. Look at the preso that Damien linked :

Hope that this doesn’t become one of the ‘services’ that you provide! :slight_smile:

I thought you said this on your blog? “We are the first VPN on the market to come up with a solution for this, and that’s why we are who we are. We’re keeping our method completely private for now.”

Did the method stop working? What was the method?

Since you are reselling OVH, you should ask them to block syn-ack spam. it should be trivial for them to block. I would be surprised if it wasn’t automatically detected already.

Short of bribing Sony, I don’t see how you can stop random honey pots from banning spoofed ips. There’s no technical solution for that.