Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitigating a DDoS on Mastodon

coffee-and-dreams.uk

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Mitigating a DDoS on Mastodon

#41

Post by generalpass »

pjc50 wrote: post #39

Decentralisation fans take note: despite wanting to remain independent, the only effective solution was in this case to re-insert a giant global intermediary (Cloudflare) and block all the anonymous unaccountable Tor users. If a decentralised system is to stay decentralised, it needs to consider spammy bad actors.

How come private contract clauses can't be initiated to protect from malicious actors?

What if I own a server and connect it to an ISP under an agreement where the ISP is accountable for clearly malicious behavior coming from its connection (regardless of origin)?

Then, that ISP requires the same agreement from me, and everyone connecting to that ISP, and on down the chain.

Wouldn't we all be very active in policing bad actors in the networks we manage?

Re: Mitigating a DDoS on Mastodon

#42

Post by somehnguy »

koroshitekure wrote: post #32
buro9 wrote: post #23

Earlier quoted context omitted.

Cloudflare EM for DDoS Protection here. If a customer wants to hide their IP then the best way to do it: 1. Onboard onto Cloudflare 2. Audit your app and ensure you aren't leaking your IP (are you sending email directly? making web calls directly? - make adjustments to use APIs of other providers, i.e. send emails via Sendgrid API, etc) 3. Change your IP (it was previously public knowledge in your DNS records) At thi…

hey, OP here I'm no longer on keybase, deleted it a few days ago - but I'm more than happy to share what I found if you want pretty sure it's nothing groundbreaking though other contact methods are listed on my profile (edit: by OP I mean article author)

Nobody cares if you're on keybase my dude, share what ya got here instead of behind private messages

Re: Mitigating a DDoS on Mastodon

#43

Post by gargron »

dredmorbius wrote: post #26
rehasu wrote: post #8

Is a federated system like Mastodon not setup in a way that users have access lists and if one server is down they simply connect to the next? I would expect to just limit the access to my server in a way that no illegal content is added to its storage and I don't have to pay horrendous fees for the network traffic and then just let the DDOS happen. At some point it needs to stop since the DDOSer will find nicer targ…

As others have noted: accounts are instance-bound. Other Fediverse protocols -- I believe either Friendica or ... I think Hubzilla? -- have some level of account portability. There's a fairly long-standing request for Mastodon to support this. For now, you can have accounts on other instances forwarded to your primary. While you can export and import your own follows, followers of your account won't automatically red…

> While you can export and import your own follows, followers of your account won't automatically redirect to the new home.

This information is outdated since October 11, 2019. You can move followers from one account to another in Mastodon 3.0.

Re: Mitigating a DDoS on Mastodon

#44

Post by dredmorbius »

gargron wrote: post #43
dredmorbius wrote: post #26

Earlier quoted context omitted.

As others have noted: accounts are instance-bound. Other Fediverse protocols -- I believe either Friendica or ... I think Hubzilla? -- have some level of account portability. There's a fairly long-standing request for Mastodon to support this. For now, you can have accounts on other instances forwarded to your primary. While you can export and import your own follows, followers of your account won't automatically red…

> While you can export and import your own follows, followers of your account won't automatically redirect to the new home. This information is outdated since October 11, 2019. You can move followers from one account to another in Mastodon 3.0.

TIL, thanks!

(For others: Gargron is Mastodon's creator.)

Re: Mitigating a DDoS on Mastodon

#45

Post by pjc50 »

generalpass wrote: post #41
pjc50 wrote: post #39

Decentralisation fans take note: despite wanting to remain independent, the only effective solution was in this case to re-insert a giant global intermediary (Cloudflare) and block all the anonymous unaccountable Tor users. If a decentralised system is to stay decentralised, it needs to consider spammy bad actors.

How come private contract clauses can't be initiated to protect from malicious actors? What if I own a server and connect it to an ISP under an agreement where the ISP is accountable for clearly malicious behavior coming from its connection (regardless of origin)? Then, that ISP requires the same agreement from me, and everyone connecting to that ISP, and on down the chain. Wouldn't we all be very active in policing…

Probably worth thinking through why this isn't done already: firstly it's a lot of work, and secondly the cross-network accountability is very short on choices. After a certain point you have to decide whether you want to cut off a majority of the internet or put up with it.

It also requires de-anonymisation (so you can identify who the bad actor actually is!) - you wouldn't be allowed a Tor exit node on this network, for example.

Re: Mitigating a DDoS on Mastodon

#46

Post by pjc50 »

lifty wrote: post #40
pjc50 wrote: post #39

Decentralisation fans take note: despite wanting to remain independent, the only effective solution was in this case to re-insert a giant global intermediary (Cloudflare) and block all the anonymous unaccountable Tor users. If a decentralised system is to stay decentralised, it needs to consider spammy bad actors.

That's true, Cloudflare has mastered the art of DDoS mitigation and they have developed some amazing tools [1] to achieve that, and fortunately they are sharing some of this knowledge. With the advent of eBPF, I reckon that this kind of tooling will become more accessible and easy to deploy for people that do self-hosting. I also hope that DDoS mitigations based on web of trust or other type of cryptographic identity…

Their main form of mitigation is sheer size. On a smaller ISP you can just get your entire uplink saturated by the attack. Even if you correctly drop 100% of the attack packets that reach you, your system is still unusable.

Re: Mitigating a DDoS on Mastodon

#47

Post by bananocurrency »

jgrahamc wrote: post #28
aeyes wrote: post #25

> Cloudflare logs really suck for non-enterprise customers. Clouflare logs also suck for enterprise customers

In what way do they suck? We have incredibly detailed logs available to our customers. https://developers.cloudflare.com/logs/about/

I want to write a bunch of code just to see decent logs. Thanks for passing the work to me.

Re: Mitigating a DDoS on Mastodon

#48

Post by Analemma_ »

generalpass wrote: post #41
pjc50 wrote: post #39

Decentralisation fans take note: despite wanting to remain independent, the only effective solution was in this case to re-insert a giant global intermediary (Cloudflare) and block all the anonymous unaccountable Tor users. If a decentralised system is to stay decentralised, it needs to consider spammy bad actors.

How come private contract clauses can't be initiated to protect from malicious actors? What if I own a server and connect it to an ISP under an agreement where the ISP is accountable for clearly malicious behavior coming from its connection (regardless of origin)? Then, that ISP requires the same agreement from me, and everyone connecting to that ISP, and on down the chain. Wouldn't we all be very active in policing…

1) This doesn't deal with botnets and other compromised devices. Would you want your ISP to terminate your service if you (or worse, your roommate) got a virus?

2) This would require ISPs to do even more invasive monitoring of all traffic to be in compliance. They'd essentially have to DPI everything, or even break TLS between you and your destination, to know if your traffic was malicious. No thank you.

3) Many ISPs simply don't care. A lot of malicious traffic comes from countries where ISPs will just look the other way for a bit of cash. I suppose we could come up with a system that depeers bad ISPs, but this would have tons of collateral damage to innocents as well as reintroducing the exact centralization we're trying to avoid (where's the "master list" of bad ISPs to depeer?)

Whatever the solution to bad actors online is, it isn't ISPs.

Re: Mitigating a DDoS on Mastodon

#49

Post by 904baf11 »

generalpass wrote: post #41
pjc50 wrote: post #39

Decentralisation fans take note: despite wanting to remain independent, the only effective solution was in this case to re-insert a giant global intermediary (Cloudflare) and block all the anonymous unaccountable Tor users. If a decentralised system is to stay decentralised, it needs to consider spammy bad actors.

How come private contract clauses can't be initiated to protect from malicious actors? What if I own a server and connect it to an ISP under an agreement where the ISP is accountable for clearly malicious behavior coming from its connection (regardless of origin)? Then, that ISP requires the same agreement from me, and everyone connecting to that ISP, and on down the chain. Wouldn't we all be very active in policing…

This would not actually stop anything, just create a bunch of lawsuits.

Re: Mitigating a DDoS on Mastodon

#50

Post by TrueDuality »

koroshitekure wrote: post #16
iampims wrote: post #15

Earlier quoted context omitted.

To avoid leaking IPs, you can use cloudflared tunnel. It might get pricy if you move a lot of bytes, but it’ll isolate you from IP leaking issues.

oh, i found out where the leak was it's right at the end of the article - the attacker was abusing the "create a preview card of any posted URL" feature - he'd post a link, wait for pleroma to go and grab the url to preview it, then narrow down which one was mine based on user agent i added an upstream proxy and anonymised the user agent, so even if he were to do that, the most he'd find was my proxy box

Did you consider using Tor to make those kind of outbound requests? I've done that in that past for a similar situation to avoid leaking IPs, there is a latency overhead but it solved my issue pretty quickly. There were some sites that were blocking Tor exits but the vast majority were successful (enough that when the feature failed it didn't really matter).
Post reply on HN