syn flood attacks from NL-based netblocks

Sun Aug 18 15:48:08 UTC 2019

On 8/18/19 6:41 AM, Amir Herzberg wrote:
> 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...

I just shared this idea over on the powerdns list, but I do have an idea
that may be potentially a good mitigation strategy and for the exact
reason stated above; low load to individual end points may still, in
aggregate, overwhelm an IX or provider, so cutting off the SYN-ACK
traffic to those hosts which have not requested connections is good
internet hygiene...

My idea is to maintain a penaltybox for any client IP that initiated a
connection but did not complete, while also maintaining a whitelist of
'frequent fliers' who have previously completed their connections
successful. The penalty could simply be to drop traffic sourced from
those client ips that do not complete the handshake, for some
configurable timeout period. The whitelisting feature could give a pass
to good clients and allow these to bypass the penalty filtering, for a
longer timeout period (but of course, passing it along so other ACL's
can take effect). I'd say, perhaps, a 5 minute timeout would be
sufficient for a penalty, while 1 day or longer would be sufficient for
whitelisting. It would depend on your traffic of course, and definitely
you would want something efficient such as linux ipset as opposed to
individual iptables rules.

While looking around, I came across the SYNPROXY netfilter module.. it
appears to be very complete but missing the above functionality to avoid
responding to spoofed clients. I'm going to see about hacking up a proof
of concept. I'll post here if I come up with something to play with.

Mike-