<div dir="ltr">hhh well Damian, Ok, I guess a free service has some costs :) <div><br></div><div>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. <br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>-- <br><div>Amir Herzberg<br></div><div><br></div><div>Comcast professor of Security Innovations, University of Connecticut</div><div><br>Homepage: <a href="https://sites.google.com/site/amirherzberg/home" target="_blank">https://sites.google.com/site/amirherzberg/home</a></div><div><br></div><div>Foundations of Cyber-Security (part I: applied crypto, part II: network-security): </div><div><a href="https://www.researchgate.net/project/Foundations-of-Cyber-Security" target="_blank">https://www.researchgate.net/project/Foundations-of-Cyber-Security</a></div><br></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 11:21 PM Damian Menscher <<a href="mailto:damian@google.com">damian@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Amir: you're exactly correct -- but since you asked, here's their answer from the last time I suggested they respond with RSTs: <a href="https://seclists.org/nanog/2020/Jan/612" target="_blank">https://seclists.org/nanog/2020/Jan/612</a><div><br></div><div>Damian</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 5:36 PM Amir Herzberg <<a href="mailto:amir.lists@gmail.com" target="_blank">amir.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If I read your description correctly: <div><br></div><div>- Attacker sends spoofed TCP SYN from your IP address(es) and different src ports, to some TCP servers (e.g. port 80)</div><div>- TCP servers respond with SYN/ACK  ; many servers resend the SYN/ACK hence amplification . </div><div>- *** your system does not respond ***</div><div>- 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. </div><div><br></div><div>Anyway, is this the case? </div><div><br></div><div>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? </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>I may be wrong - sorry if so - and would appreciate, in any case, if you can confirm or clarify, thanks. </div><div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div>-- <br><div>Amir Herzberg<br></div><div><br></div><div>Comcast professor of Security Innovations, University of Connecticut</div><div><br>Homepage: <a href="https://sites.google.com/site/amirherzberg/home" target="_blank">https://sites.google.com/site/amirherzberg/home</a></div><div><br></div><div>Foundations of Cyber-Security (part I: applied crypto, part II: network-security): </div><div><a href="https://www.researchgate.net/project/Foundations-of-Cyber-Security" target="_blank">https://www.researchgate.net/project/Foundations-of-Cyber-Security</a></div><br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 5:23 PM Octolus Development <<a href="mailto:admin@octolus.net" target="_blank">admin@octolus.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_-3724020310122188147gmail-m_2488618760763277550gmail-m_-296644685190055026gmail-m_8044366582873623009__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">A very old attack method called TCP-AMP ( <a href="https://pastebin.com/jYhWdgHn" target="_blank">https://pastebin.com/jYhWdgHn</a> ) has been getting really popular recently. <div></div><div><br></div><div>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".</div><div><br></div><div>Example of the reports we're getting:</div><div><div>tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV)</div><div>tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV)</div></div><div><br></div><div>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.</div><div><br></div><div>Anyone else had any problems with these kind of attacks?</div><div><br></div><div>The attack basically works like this;</div><div>- The attacker scans the internet for TCP Services, i.e port 80.</div><div>- 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.</div><div>... Which ends up with hundreds of request to these services, reporting us for "port flood".</div><div><br></div><div><br></div></div></blockquote></div>
</blockquote></div>
</blockquote></div>