this post was submitted on 04 Aug 2023
4 points (54.0% liked)

Cybersecurity

5650 readers
85 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

Notable mention to [email protected]

founded 1 year ago
MODERATORS
 

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:

  1. 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.
  2. Establish 3+ clearnet hosts evenly spaced geographically on VPSs. 2.1. Configure DNS to load-balance the clearnet traffic.
  3. 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)
  4. 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?)
  5. 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 @[email protected]!). (do fedi servers tend to support this or is hacking needed?)
  6. Temporarily defederate from all nodes to focus just on local users being able to access local content. (not sure if this makes sense)
  7. Take the web client offline and direct users to use a 3rd party app during attacks, assuming this significantly lightens the workload.
  8. 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?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 6 points 1 year ago (1 children)

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

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

Dynamic IPs change on average every few days

The users who would be most impacted by an attack are the ones who are right in the middle of a conversation. Having a conversation interrupted is worse than being unable to check for new news or start a new conversation. So I think using the IPs for ~2—3 days of firewall masking would give users a chance to wrap up the conversations they’re involved in. As well as give users a chance to quickly grab their archives (to the extent that the server can handle it).

(edit) Why not combine this with tar-pitting? Unknown IPs could be tar-pitted until they login, at which point their new IP becomes known.