syn flood attacks from NL-based netblocks
ximaera at gmail.com
Mon Aug 19 11:14:54 UTC 2019
On Mon, Aug 19, 2019 at 7:39 AM Damian Menscher via NANOG
<nanog at nanog.org> wrote:
> Most kernels will return 3-5 SYN-ACK packets for an incoming
> SYN, so it's not particularly interesting for attackers or defenders.
Well, producing 1000 Gbps as opposed to 200 Gbps is still pretty
impressive, isn't it?
More on that later, b/c the point here aren't even jiggabits,
> it's somewhat pointless to worry about a small amplification
> factor -- an attacker could [..] use UDP to get a massive
> bandwidth (or even significant packet) amplification.
Most of the resources hosted by a typical hosting company are
essentially Web sites.
Unless you are really really dependant on QUIC (and, unless we're all
really unlucky and recent initiatives to get rid of TCP/TLS fallback
in HTTP/3 would gain support), as a Web hosting company, you can use
whatever you want to get rid of UDP completely very quickly, and that
won't harm your business a lot.
Dealing with TCP flags is a different story:
- Your ability to handle them with the likes of RFC 5575 depend on
what particular sort of equipment is deployed in your network;
- To make matters worse, for a huge portion of customers the ability
to connect to an external service/API gateway/Web site via TCP is
crucial. A simple example is Google which cannot survive for long if
Googlebot keeps being unable to operate. Think also OAuth,
Skyscanner, credit scoring systems, insurance companies, etc.;
- To ensure proper handling of spoofed SYN/ACKs while still
maintaining a possibility to connect to an external service you, as a
hosting company under an attack, would have to track all of the
outgoing SYNs to match them against received SYN/ACKs later.
This is where the "1kGbps-vs-200Gbps" argument becomes important, b/c
every existing free connection state tracking solution doesn't scale
beyond 200 Gbps at best given the best hardware money can buy given a
single machine, and no existing solution is able to share its state
across multiple machines.
[there are proprietary products doing that though, we have one, but
proprietary solutions are always a different kind of story]
More information about the NANOG