syn flood attacks from NL-based netblocks

Sun Aug 18 13:41:40 UTC 2019

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 at 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-
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190818/9f78bb0d/attachment.html>