syn flood attacks from NL-based netblocks

Töma Gavrichenkov ximaera at gmail.com
Mon Aug 19 11:14:54 UTC 2019


Peace,

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.[citation needed]

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]

--
Töma



More information about the NANOG mailing list