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. 

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...
-- 
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut



On Sat, Aug 17, 2019 at 11:03 PM Mike <mike-nanog@tiedyenetworks.com> wrote:
On 8/16/19 3:04 PM, Jim Shankland wrote:
> Greetings,
>
> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
> attacks ostensibly originating from 3 NL-based IP blocks:
> 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly"
> because ... syn flood, and BCP 38 not yet fully adopted).
>
> Why is this syn flood different from all other syn floods? Well ...
>
> 1. Rate seems too slow to do any actual damage (is anybody really
> bothered by a few bad SYN packets per second per service, at this
> point?); but
>
> 2. IPs/port combinations with actual open services are being targeted
> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
> with those services running), implying somebody checked for open
> services first;
>
> 3. I'm seeing this in at least 2 locations, to addresses in different,
> completely unrelated ASes, implying it may be pretty widespread.
>
> Is anybody else seeing the same thing? Any thoughts on what's going
> on? Or should I just be ignoring this and getting on with the weekend?
>
> Jim
>
>
>
>

I am seeing this against my recursive revolvers - one syn in, and many
syn-ack's back with no connection obviously. Low rate to be sure, but
what was surprising to me was that my revolvers (PowerDNS) definitely
have an allowed-networks ACL which specifies my permitted client
addresses, and I thought this would effectively filter any inbound
queries. But it looks like this ACL is applied only AFTER connection
setup. Maybe I have been blind this entire time thinking I wouldn't
respond to any packets sent to my resolver from non-allowed-networks
addresses. But anyways just a good data-point for anyone else to check
your revolvers too and consider the TCP case may behave as mine do. I
fixed it by implementing a revised iptables firewall which definitely
corrects the issue and drops outright all packets to
non-allowed-networks addresses, thank you ipset...

Mike-