Pawning your users to Cloudflare is not how you offer your users security; fedi admins must realize this.
Pawning your users to Cloudflare is not how you offer your users security; fedi admins must realize this.
I would love if just once an admin of a fedi host under #DDoS attack would have the integrity to say:
“We are under attack. But we will not surrender to Cloudflare & let that privacy-abusing tech giant get a front-row view of all your traffic (including passwords & DMs) while centralizing our decentralized community. We apologize for the downtime while we work on solving this problem in a way that uncompromisingly respects your privacy and does not harm your own security more than the attack itself.”
This is inspired by the recent move of #LemmyWorld joining Cloudflare’s walled garden to thwart a DDoS atk.
So of course the natural order of this thread is to discuss various Cloudflare-free solutions. Such as:
- Establish an onion site & redirect all Tor traffic toward the onion site. 1.1. Suggest that users try the onion site when the clearnet is down— and use it as an opportunity to give much needed growth to the Tor network.
- Establish 3+ clearnet hosts evenly spaced geographically on VPSs. 2.1. Configure DNS to load-balance the clearnet traffic.
- Set up tar-pitting to affect dodgy-appearing traffic. (yes I am doing some serious hand-waving here on this one… someone plz pin down the details of how to do this)
- You already know the IPs your users use (per fedi protocols), so why not use that info to configure the firewall during attacks? (can this be done without extra logging, just using pre-existing metadata?)
- Disable all avatar & graphics. Make the site text-only when a load threshold is exceeded. Graphic images are what accounts for all the heavy-lifting and they are the least important content (no offense @jerry@infosec.exchange!). (do fedi servers tend to support this or is hacking needed?)
- Temporarily defederate from all nodes to focus just on local users being able to access local content. (not sure if this makes sense)
- Take the web client offline and direct users to use a 3rd party app during attacks, assuming this significantly lightens the workload.
- Find another non-Cloudflared fedi instance that has a smaller population than your own node but which has the resources for growth, open registration, similar philosophies, and suggest to your users that they migrate to it. Most fedi admins have figured out how to operate without Cloudflare, so promote them.
^ This numbering does /not/ imply a sequence of steps. It’s just to give references to use in replies. Not all these moves are necessarily taken together.
What other incident response actions do not depend on Cloudflare?
Permanently Deleted
It's possible to set up a DNS redirection based DDoS protection service, even with coudflare while still providing user security. Cloudflare or any other provider can only see the content if they act as the SSL termination endpoint. Using techniques like syn-cookie mitigations and IP rate limiting can provide the same relief without the provider having access to the stream content. It's also possible to set up similar protections locally, but for any serious level of attack you're probabbly going to need exrernal assistance to handle a portion of it.
4 will not work due to dynamic IPs being standard nowadays, my IP for example gets changed by my ISP every few hours, or when my router restarts.
It’s a good point but incident response amid heavy attack does not require perfection. It would certainly be borderline useless over the long-term, but I think most “dynamic” IPs rarely change. Last time I paid attention, I think I had the same dynamic IP for over a year. I would also expect IPv6 to be even less dynamic.
Perhaps users who use DDNS from afraid.org (gratis) could be accommodated along these lines.
Dynamic IPs change on average every few days, long enough to hold out, but it also heavily depends on the type of connection you use.
DSL for example has much higher volatility than cable and fibre internet.
Also IPv6 does not matter for this, as IPv6 adresses get reassigned at the same frequency, and sometimes even more often in my experience
Out of your list, I would say that only load balancing would really make a difference, and only up to a certain point, depending on the number of hosts. It really takes time to introduce a meaningful DDOS prevention mechanism, as it may require both development and DevOps time to implement. Perhaps in the future, as Lemmy evolves, we will see less reliance on Cloudflare, but right now, we don't have many options. Lastly, you also have to consider the costs in terms of time and money.
Yup, there's a reason there aren't a ton of FOSS or small DDoS prevention/protection tools/services out there, and even large tech companies that may have the resources to develop their own rely on providers like Cloudflare instead. Also, to re-iterate another comment in this post, you don't necessarily need to allow cloudflare to see your encrypted traffic if you just want DDoS protection.
I'm starting to think some of y'all don't know what a walled garden is. just saw someone on mastodon refer to signal as a walled garden.
You don’t see the wall because you’re in the included group. Unlike Facebook, Cloudflare hides the wall from those they welcome into their garden. If you click on the screenshot on the OP, you can see what the barrier looks like to those of us who are in the excluded group.
Otherwise I hope you’re not viewing the world through a simplistic “good guys” / “bad guys” lens s.t. those you deem forces of good surely could not be a “walled garden”. The term serves well w.r.t. places where content is published. Restricted access venues: (Facebook, Cloudflare [with restricted access enabled], LinkedIn, Yelp, Quora,…) are not open access. They are walled gardens.
While #Signal is in fact technically a walled garden, it’s bizarre to bring it up simply because it’s a p2p platform with no public content to speak of. The term doesn’t really serve us well in a discussion of p2p private chat platforms. Although it’s important to recognize Signal:
- takes an extremely protectionist stance,
- deploys tactics to push Signal users into Google’s walled garden,
- threatens lawsuits against projects who attempt to use the same platform (#LibreSignal),
- excludes people without mobile phones,
- and is outspokenly hostile toward the idea of federations
See https://github.com/privacytools/privacytools.io/issues/779
The exclusivity of Signal’s design and decision making & careless marginalization of classes of people is comparable to that of orgs like Cloudflare & Microsoft.
A Cloudflare host can leave the walled garden, but steps are needed
It is possible to configure a CF host with unrestricted access, in which case you could argue those particular sites are not in the walled garden, but that’s relatively rare. And it still requires a hell of a lot of hand-waving on your part because CF algos still override the user settings in some instances.
The mitigation strategy depends on the type of attack but putting a decent firewall in front of an instance would probably go a long way in terms preventing DDOS attacks. RouterOS and I think even OpnSense can be configured to automatically detect and shut down certain types of attacks as long as your firewall hardware (or VM) is beefy enough. Back when I still did bank networking/cyber security we would drop a hefty ASA in front of the WAN. Those things would get hammered but would virtually never go down due to a DDOS attack.
Permanently Deleted