TCP-AMP DDoS Attack - Fake abuse reports problem

Fri Feb 21 08:39:24 UTC 2020

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

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.
-- 
Amir Herzberg

Comcast professor of Security Innovations, University of Connecticut

Homepage: https://sites.google.com/site/amirherzberg/home

Foundations of Cyber-Security (part I: applied crypto, part II:
network-security):
https://www.researchgate.net/project/Foundations-of-Cyber-Security

On Thu, Feb 20, 2020 at 11:21 PM Damian Menscher <damian at google.com> wrote:

> Amir: you're exactly correct -- but since you asked, here's their answer
> from the last time I suggested they respond with RSTs:
> https://seclists.org/nanog/2020/Jan/612
>
> Damian
>
> On Thu, Feb 20, 2020 at 5:36 PM Amir Herzberg <amir.lists at gmail.com>
> wrote:
>
>> 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.
>>
>> --
>> Amir Herzberg
>>
>> Comcast professor of Security Innovations, University of Connecticut
>>
>> Homepage: https://sites.google.com/site/amirherzberg/home
>>
>> Foundations of Cyber-Security (part I: applied crypto, part II:
>> network-security):
>> https://www.researchgate.net/project/Foundations-of-Cyber-Security
>>
>>
>>
>> On Thu, Feb 20, 2020 at 5:23 PM Octolus Development <admin at octolus.net>
>> wrote:
>>
>>> A very old attack method called TCP-AMP ( https://pastebin.com/jYhWdgHn )
>>> 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".
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200221/78ee867a/attachment.html>