<div dir="ltr"><div>The number of TCP syn-ack amplifiers is large. It may suffice to allow clogging a provider or IX, using low load per amplifier, as described. Such low load is likely to be undetected by most operators, and even when detected (e.g. by Jim), only few (e.g. Mike) will have sufficient motivation to block it - esp. considering that there blocking it would often be non-trivial, in Mike's case, the amplifiers were DNS servers and sounds like he simply blocked packets to unallowed networks (good practice for DNS anyway - although I wonder why not block the incoming requests instead). Notice that one annoying aspect of these attacks is that tcp congestion control isn't relevant. </div><div><br></div><div>The current packets could be part of a research experiment about this threat, or the instrumentation part of preparing such attack. I would not rule out research, since it isn't trivial to know if the attack can be really viable to clog a provider or IX; in fact finding this out in an ethical way appears a non-trivial challenge, I'll give it some thought (ideas welcome). Also I wonder what would be good _defenses_ against such attack. Of course one way would be to prevent spoofed-IP packets, but that goal has proved quite difficult...</div><div></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="color:rgb(136,136,136)">-- </span><div style="color:rgb(136,136,136);font-size:12.8px">Amir Herzberg<br></div><div style="color:rgb(136,136,136);font-size:12.8px">Comcast professor for security innovation</div><div style="color:rgb(136,136,136);font-size:12.8px">Dept. of Computer Science and Engineering, University of Connecticut</div><br class="gmail-Apple-interchange-newline"></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 17, 2019 at 11:03 PM Mike <<a href="mailto:mike-nanog@tiedyenetworks.com">mike-nanog@tiedyenetworks.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">On 8/16/19 3:04 PM, Jim Shankland wrote:<br>
> Greetings,<br>
><br>
> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood<br>
> attacks ostensibly originating from 3 NL-based IP blocks:<br>
> <a href="http://88.208.0.0/18" rel="noreferrer" target="_blank">88.208.0.0/18</a> , <a href="http://5.11.80.0/21" rel="noreferrer" target="_blank">5.11.80.0/21</a>, and <a href="http://78.140.128.0/18" rel="noreferrer" target="_blank">78.140.128.0/18</a> ("ostensibly"<br>
> because ... syn flood, and BCP 38 not yet fully adopted).<br>
><br>
> Why is this syn flood different from all other syn floods? Well ...<br>
><br>
> 1. Rate seems too slow to do any actual damage (is anybody really<br>
> bothered by a few bad SYN packets per second per service, at this<br>
> point?); but<br>
><br>
> 2. IPs/port combinations with actual open services are being targeted<br>
> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs<br>
> with those services running), implying somebody checked for open<br>
> services first;<br>
><br>
> 3. I'm seeing this in at least 2 locations, to addresses in different,<br>
> completely unrelated ASes, implying it may be pretty widespread.<br>
><br>
> Is anybody else seeing the same thing? Any thoughts on what's going<br>
> on? Or should I just be ignoring this and getting on with the weekend?<br>
><br>
> Jim<br>
><br>
><br>
><br>
><br>
<br>
I am seeing this against my recursive revolvers - one syn in, and many<br>
syn-ack's back with no connection obviously. Low rate to be sure, but<br>
what was surprising to me was that my revolvers (PowerDNS) definitely<br>
have an allowed-networks ACL which specifies my permitted client<br>
addresses, and I thought this would effectively filter any inbound<br>
queries. But it looks like this ACL is applied only AFTER connection<br>
setup. Maybe I have been blind this entire time thinking I wouldn't<br>
respond to any packets sent to my resolver from non-allowed-networks<br>
addresses. But anyways just a good data-point for anyone else to check<br>
your revolvers too and consider the TCP case may behave as mine do. I<br>
fixed it by implementing a revised iptables firewall which definitely<br>
corrects the issue and drops outright all packets to<br>
non-allowed-networks addresses, thank you ipset...<br>
<br>
Mike-<br>
<br>
</blockquote></div>