[sysadm1n]

> Since these DDoS attacks started we have worked with our system administrators and Internet Service Provider to mitigate the attacks

How do you mitigate such an attack though? I know Cloudflare can stop this, but how do you create your own bespoke 'DDOS mitigation' tool, and what does that look like?

[Koenvh]

This is one such an approach: https://www.concordia-h2020.eu/blog-post/setting-up-a-nation...

[0des]

You simply need bigger pipes to ingest more traffic than the attack can provide. It is presumed these days that packet analysis in some cases can require too much power costwise rather than scaling up the connection to swallow it.

[bombcar]

And the "further up the chain" you can move the mitigation, the easier that is. Mitigating on your box requires a huge pipe to your box, but if your provider can mitigate at their border router, well those are bigger and already have huge traffic to and through them.

And it's in their interest to talk to their providers and mitigate even further back if possible. And some mitigations are relatively easy (block all DNS traffic to this subnet, etc).

[ahmedalsudani]

Adding capacity, dropping suspect traffic.

[capableweb]

One way is to build your software on top of distributed/content-addressed P2P software (not Blockchain, but pure P2P). The angle of attack disappears completely then.

Otherwise, with centralized infrastructure, you identify the bad traffic and send it elsewhere, an instance that keeps connections open but delivers nothing and have a small amount of resource usage. Problem is that you still need to be able to handle the traffic, but at least you avoid hitting your main infrastructure.

[Mister_Snuggles]

> One way is to build your software on top of distributed/content-addressed P2P software (not Blockchain, but pure P2P). The angle of attack disappears completely then.

I can see how this works for some applications, but how would this work for SMTP and IMAP/JMAP?

[capableweb]

You can't force centralized/federated protocols into distributed protocols so you wouldn't.

[a1369209993]

> how would this work for SMTP

You can actually get this semi-transparently with a TOR-like system. (I'm not sure TOR itself actually implements all of this, and also TOR is perennially underprovisioned for political reasons, so this mostly won't work in practice.)

First, you need a distributed DNS mechanism to publish "example.com. 9999 IN MX 1 abcdefghijklmnop.onion". This is mostly static, so DDOS doesn't really work.

You then come up with a sequence of rendezvous servers, which we'll number starting from 1. (I think actual TOR just assumes a single (or few) rendezvous server is sufficient, but I'd need to go dig through the code to be sure.)

You then try (in sequence) servers 1,2+rand(2),4+rand(4),...,2^k+rand(2^k),... where rand(x) picks a random number in [0,x). (0: I'm not sure whether distinct rands should share lower bits; see below.) If a server is overloaded it just drops traffic on the floor.

The destination server then checks the rendezvous servers in sequence until it's gotten enough successes that any client would have tried one of the successful rendezvous servers in its random sequence ([0] above affects the distribution here).

Under heavy load, the destination server also sets a proof of work requirement (clientHello statisfies the standard hash-has-x-leading-zeros), which allows the rendezvous servers to drop most of the incoming traffic. Legitimate clients by definition are not spamming connections as fast as they can, so they can burn CPU to meet this requirement. DDOS clients can also burn CPU on this, but that reduces the rate at which they generate traffic.

The end result is volumetric attacks are spread over 2^k rendezvous servers, where k is dynamicly chosen such that they can handle the load[2], while for faux-legitimate attacks[1], DDOS will just push up the computational costs for legitimate clients without ever actually shutting down the target[3].

This works for anything TCP-like.

1: You can DDOS anything by just behaving like (absurdly many) legitmate clients, eg `while true;do wget http\://example.com/;done`.

2: If the rendezvous and destination servers are all similar, then the work per server scales as the square root of the attack volume. Or put the other way around, the amount of attack traffic this setup can absorb scales as the square of the traffic each server can handle.

3: So for faux-legitimate attacks, the attacker's goal is not to overwhelm the server, but to maximize the costs to legitimate clients trying to connect; the attacker will generate only (roughly) as much traffic as the destination can handle, with as large a proof-of-work as possible. Assuming the destination server normally runs around 50% load, the total work imposed on legitimate clients (distributed over all of them) will be about the same as the attacker's available CPU. If the destination server normally runs significantly below 50% load, the imposed work will be proportionately lower.

[baybal2]

P2P networks are on other hand very susceptible to spam attack.

You haven't seen Gnutella in its glory days.

[gonehome]

Urbit solves both of these issues in a clever way with how it handles identity on the network.

[theamk]

Doesn't urbit use the generic "pay to join" identities? I don't think it is a scalable solution for general applications.

[gonehome]

Only the initial identity is non-zero cost (and there are free IDs, but they're more likely to get banned for spam).

The point of the cost is that it's cheap but non-zero. It makes spam uneconomical, creates pseudonyms for accruing reputation and makes it trivial to moderate (IDs are permanent).

Applications built on the platform can take advantage of this ID system and none of them need to rebuild auth or handle networking across the web. This means application devs can just focus on their apps and distribution is trivial.

The modern web is a nightmare of complexity for people trying to build applications, you basically need to raise VC and have a SaaS in order to be able to hire the armies of people required to build anything.

[theamk]

But Urbit is "overlay OS" -- which means it still uses all the existing stuff (Linux, filesystems, UDP, TCP, HTTP, Javascript, web browsers for frontend) but adds a whole bunch more stuff on top of it [0]. So you are not reducing complexity, but increasing it.

And it's identity management is based to Ethereum, so maybe just attach "Sign-in with Ethereum" component to the Mastodon instance, and you get something with same featureset as Urbit, but somewhat simpler and vastly more supportable. And as an extra, you get nice features like multi-machine scaling and live encrypted backups.

[0] https://news.ycombinator.com/item?id=27268462

[miked85]

Urbit does have the added advantage that very few understand what it even is.