[LinuxBender]

In regards to fail2ban, assuming the attack was purely SMTP specific which it won't be even then blocking IP's would be futile. The DDoS-as-a-service farms have hundreds of thousands to millions of IP's under their control. Block one IP and ten more show up. One IP is not one attacker. Those farms have probes that can tell how effective their attack is. Some of them even have "proven work" that is reported back to the buyer to validate the effectiveness of their attack. You may want to research this one as it is a very big topic.

In reality however, a large portion of the attack won't even show up in logs. The attack will also contain depending on how much the attacker is willing to spend tens of millions or hundreds of millions of packets per second of TCP, UDP packets on random ports, no ports, random protocols, random sizes, random TTL's, random headers. That is a volumetric attack. Fail2ban and most network IDS/IDP's would not even see this attack. It would saturate the uplinks to the ISP before you even see anything. Your ISP will most likely null route you and encourage you to stop advertising your AS number.

In reference to scrubbing centers for individuals, that is not a thing unless you have unlimited funds. There are some VPS providers that can scrub tiny attacks. Linode, Vultr, OVH to name a few but they can only deal with tiny attacks. If you want to research this for your business, my suggestion would be to get on the NANOG mailing lists and discuss it with all the network engineers to find out which scrubbing services are currently most effective. This is a moving target and a very big investment. I am not a fan of any of the companies that provide these services, but that is only based on my limited experiences with them.

[rgrmrts]

Word, thanks for all the details! Yeah, I don't have any actual business use-cases outside of a personal interest in making my dedicated server reasonably protected.

[LinuxBender]

You're welcome! For your personal MX servers, the most cost effective solution I know of would be to have multiple domains and each domain have their own MX records and corresponding VM/server on its own unique provider to isolate them. Then ensure that people/businesses that are important to you know to contact you at 2+ email addresses/domains. If someone attacks one of your domains or MX servers, you can safely ignore the attack. These separate MX servers should be on different server/VPS providers in the event that the attack causes one of them to suspend your account. Your imap client can poll each of the servers/domains so that you get your emails.

[rawoke083600]

Would a decenterlized service architecture work better than an server-client arch ?

Im thinking like a lambda/faas platform where the computing endpoint is massively distributed ?

I guess there are (currently) no 'one final solution' but like traditional security a good solution consists of many many layers/rings of defences ? Can one(in theory) decenterlized all 7 of the osi model ?

Trying hard not to use the word (crypto/blockchain) here .

[toast0]

Function as a service isn't really what I'd call decentralized. It's centralized at the service provider. But, they mix your load in with everyone elses and they serve the load in many places (maybe geographically distributed is decentralized?).

But, voip.ms has points of presence all over and they were DDoSed effectively recently; distribution can often help, but it's not enough. If an attacker sends X gigabits of garbage at your San Jose PoP and disables it, your other PoPs will likely function, but if they send X/N gigabits at each of your N PoPs, that might be enough to disable all of them.

Using a large provider can help a lot though. Volumetric DDoS is 'solved' by having large pipes and discarding lots of traffic. And, where possible, getting upsteams to discard lots of traffic before it arrives on your network. Large providers have large pipes and good relations with their carriers. Smaller providers or DIY doesn't.

[LinuxBender]

Email is already designed to be decentralized. You can have a very large number of mail servers in any number of clouds behind multiple MX records, Anycast IP's, Load balancers, etc... The scale of distribution required to defend against these attacks is possible, but prohibitively expensive. Some VPS providers do support Anycast so in theory you could dynamically spin up tens of thousands of inbound MX nodes that would at least spool the emails. Anycast will allow you to have any number of MX servers appear as one IP address. Those nodes in turn then need to relay that to your centralized servers. This brings up more scalability issues as you could essentially DDoS yourself in this pattern. There may not be enough clouds to support this idea and the cost would give just about any CTO sticker shock or medical issues.

If you mean distributing the destination servers that people access that is basically the same pattern. One could in theory spin up cloud instances of the email httpd/smtpd servers but there are still diminishing returns. This also requires the clients to know how to route to the right clusters of servers. Not easy, but doable. Ultimately this is the same problem people run into with web servers hosted on AWS. You can spin up more instances but there are still network link bottlenecks going into each region. AWS and the like have partnerships with scrubbing centers. This model breaks down if the attacker is willing to spend more than $500. Most massive scale attacks cost less than $200 on the dark web. If the extortionists believe they can get more than say $1k, then they might be willing to spend enough to even take down some scrubbing centers. It can cost hundreds of millions to defend against a $200 attack.

The current email RFC's would not support something like crypto/blockchain. At that point you are basically inventing a new standard and adoption may take a very long time unless there is a compelling business advantage to it in my opinion.