syn flood attacks from NL-based netblocks

Damian Menscher damian at google.com
Mon Aug 19 04:37:32 UTC 2019


On Sun, Aug 18, 2019 at 6:42 AM Amir Herzberg <amir.lists at gmail.com> wrote:

> 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...
>

The high packet rate (millions of packets/second) and broad targeting
(several /24s, not just a handful of machines) make it clear this was an
actual attack, not an experiment or reconnaissance.  (There are also other
clear signals, such as the timing of the attacks, source(s) originating the
spoofed packets, etc.)

Most kernels will return 3-5 SYN-ACK packets for an incoming SYN, so it's
not particularly interesting for attackers or defenders.  While a long-term
mitigation could be to limit ourselves to a single SYN-ACK (via
/proc/sys/net/ipv4/tcp_synack_retries) it's somewhat pointless to worry
about a small amplification factor -- an attacker could attack directly...
or use UDP to get a massive bandwidth (or even significant packet)
amplification.  A counter-argument presented in the paper "Hell of a
Handshake: Abusing TCP for Reflective Amplification DDoS Attacks" is that
several broken TCP stacks that will provide a much greater amplification
factor.

I disagree that preventing spoofed packets is difficult -- it's trivial for
transit providers to use their netflow to identify the true source(s) of
spoofed attacks, and then apply filters on their problematic customers (who
refuse to apply egress filters themselves).  If transit providers can't be
bothered to be proactive about this, law enforcement can serve them with
legal process to identify the problem customers, who might then be held
responsible for the attacks they're facilitating.  I commented on this
approach in my talk at NANOG 76.

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190818/35bc2b24/attachment.html>


More information about the NANOG mailing list