nanog mailing list archives
Re: syn flood attacks from NL-based netblocks
From: Damian Menscher via NANOG <nanog () nanog org>
Date: Sun, 18 Aug 2019 21:37:32 -0700
On Sun, Aug 18, 2019 at 6:42 AM Amir Herzberg <amir.lists () 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
Current thread:
- Re: syn flood attacks from NL-based netblocks, (continued)
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 17)
- Re: syn flood attacks from NL-based netblocks Damian Menscher via NANOG (Aug 17)
- Re: syn flood attacks from NL-based netblocks Amir Herzberg (Aug 17)
- Re: syn flood attacks from NL-based netblocks Damian Menscher via NANOG (Aug 17)
- Re: syn flood attacks from NL-based netblocks Amir Herzberg (Aug 17)
- Re: syn flood attacks from NL-based netblocks Amir Herzberg (Aug 17)
- Re: syn flood attacks from NL-based netblocks Jim Shankland (Aug 17)
- Re: syn flood attacks from NL-based netblocks Mike (Aug 17)
- Re: syn flood attacks from NL-based netblocks Amir Herzberg (Aug 18)
- Re: syn flood attacks from NL-based netblocks Mike (Aug 18)
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 19)
- Re: syn flood attacks from NL-based netblocks Damian Menscher via NANOG (Aug 18)
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 19)
- Re: syn flood attacks from NL-based netblocks Damian Menscher via NANOG (Aug 19)
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 19)
- Re: syn flood attacks from NL-based netblocks Valdis Klētnieks (Aug 19)
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 19)
- Re: syn flood attacks from NL-based netblocks Valdis Klētnieks (Aug 19)
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 19)
- Re: syn flood attacks from NL-based netblocks Amir Herzberg (Aug 18)
- Message not available
- Re: syn flood attacks from NL-based netblocks Töma Gavrichenkov (Aug 19)
- Re: syn flood attacks from NL-based netblocks Florian Brandstetter (Aug 20)