Re: [hackers] [quark] Apply (D)DoS-Hardening || Laslo Hunhold

From: Laslo Hunhold <dev_AT_frign.de>
Date: Sat, 6 Feb 2021 18:15:58 +0100

On Sat, 6 Feb 2021 11:28:20 +0100
Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:

Dear Hiltjo,

> I don't think this is the right approach for reliability sake.
>
> Is all this added complexity worth it compared to the previous
> non-OS-specific code (pre-kqueue)?

yes, it is! The forking model has been dead since the early 2010's
because you can easily kill a forking-server with the attacks I
mentioned in the commit with very little effort or resources (a laptop
can easily do that alone). Admittedly the forking-approach has its
upsides, but you hit the limits quickly and they're unsolvable in this
context, unless you deploy some IPC-mechanism or something, but for
such cases, you would have an IPC-broadcast, which is inefficient in
itself, and many stale processes clogging up memory for long-time
connections.

Quark has no timeouts on sockets and doesn't care if you take 5 years
to fulfill an HTTP-request. As long as connection-slots are free, you
can occupy them with your long-term-download or really slow
satellite-internet while you're on a Safari in Africa, because it makes
no difference in terms of memory usage. With a forking model you
usually have timeouts (like 30 seconds), which can be easily reached
with a satellite connection (to just give one contrived example). :P

> Have you even tested the kqueue code? Last time it did not even
> compile.

Yes, it now works on OpenBSD and the queue-code is trivial to amend
with a poll-backend for any POSIX-system, but kqueue+epoll pretty much
covers Linux+BSD well. I'll do more in-depth testing though before
tagging the first release.

> This DDoS-hardening does not protect against a botnet attack anyway.

That's mostly true if you talk about large-scale-attacks, but it can
sustain attacks as long as the number of bots in the botnet does not
exceed the number of slots per thread (and at those numbers you would
need a "professional" DDoS-protection anyway). However, botnets are a
different matter and here it's more about protecting against
script-kiddies and even small groups running LOIC or something else on
the target.

Quark can fulfil around 20k requests/second or around 16GBit/s of pure
throughput, which means that in an attack scenario, you will probably
saturate anything before it way earlier before you saturate quark (I
didn't even ramp up the number of threads/slots. It'd be interesting to
see how much quark can handle on a 64c/128t Threadripper system if you
really give it hell).

> Very basic attacks can be worked around with firewall/pf rules.

The "attacks" mentioned here are higher on the OSI-layer. If you really
attack the server with a botnet with homogenously-distributed
slowloris-connections (e.g. 5 connections each), your firewall won't
care, but your server will be DoS'ed anyway.

Every solution has its limits, though, and I understand what you mean,
and I won't claim to be an expert in this field.

> The quark pre-FRIGN-era was much simpler and more readable.

Everyone can throw together a forking static webserver, but non-trivial
details almost always remain unadressed. My goal with this project is to
see how far you can go with no memory allocations at runtime. Quark is
the only webserver that does this and it makes it really simple to
reason about from a resource-perspective (e.g. when you run a webserver
on a Raspberry Pi or in other really constrained or dependable
environments).

HTTP is a mostly elegant protocol, but it has its edge-cases, and
quark, I think, abstracts it in a suckless way that you can just launch
and forget about it. The "quark pre-FRIGN-era" was indeed simpler (the
forking model has way less initialization-overhead), but had some
issues and was a bit quirky in some places, not to forget about the
aforementioned issues and the impossibility of a constant memory map.

With best regards

Laslo
Received on Sat Feb 06 2021 - 18:15:58 CET