Hi all,

As self-hosting is not just “home-hosting” I guess this post should also be on-topic here.

Beginning of the year, bleeping-computers published an interesting post on the biggest cybersecurity stories of 2023.

Item 13 is an interesing one. (see URL of this post). Summary in short A Danish cloud-provider gets hit by a ransomware attack, encrypting not only the clients data, but also the backups.

For a user, this means that a senario where, not only your VM becomes unusable (virtual disk-storage is encrypted), but also the daily backups you made to the cloud-provider S3-storage is useless, might be not as far-fetches then what your think.

So … conclussion ??? If you have VMs at a cloud-provider and do daily backups, it might be usefull to actually get your storage for these backups from a different provider then the one where your house your VMs.

Anybody any ideas or remarks on this?

(*) https://www.bleepingcomputer.com/news/security/the-biggest-cybersecurity-and-cyberattack-stories-of-2023/

10 points

haha

“the cloud” does not change the fact that if you data does not reside in 2 physical locations you do not have a backup.

so yes, standard practices that have existed… well, since the beginning, still apply.

permalink
report
reply
5 points

Well, the issue here is that your backup may be physically in a different location (which you can ask to host your S3 backup storage in a different datacenter then the VMs), if the servers themselfs on which the service (VMs or S3) is hosted is managed by the same technical entity, then a ransomware attack on that company can affect both services.

So, get S3 storage for your backups from a completely different company?

I just wonder to what degree this will impact the bandwidth-usage of your VM if -say- you do a complete backup of your every day to a host that will be comsidered as “of-premises”

permalink
report
parent
reply
3 points

yeah, you can use another cloud provider as backup… if you do it correctly.

personally, my disaster recovery plans dont include entire offsite VMs. i only care about data in a dr situation. so you send incremental daily backups offsite.

containers have made VMs even more irrelevant/ephemeral so focus on the data.

permalink
report
parent
reply
1 point

I assume “data” includes your container configuration files in this strategy?

permalink
report
parent
reply
2 points

if you backup your vm data to the same provider as you run your vm on you don’t have an ‘off-site’-backup, which is one criteria of the 3-2-1 backup rule.

permalink
report
parent
reply
13 points

Its just some elses computer. Said this since the beginning

permalink
report
reply
4 points

The issue is not cloud vs self-hosted. The question is “who has technical control over all the servers involved”. If you would home-host a server and have a backup of that a network of your friend, if your username / password pops up on a infostealer-website, you will be equaly in problem!

permalink
report
parent
reply
2 points

If you follow the 3-2-1 backup policyand unless it’s the end of the world you should be fine.

3 backups 2 different media types 1 off-site

If your worried about a cloud provider getting attacked then have 2 off-site.

permalink
report
parent
reply
2 points

@kristoff Multicloud deployments is a thing, but far from common practice, I believe.

permalink
report
reply
1 point

I will put “multicloud” on my wishlist.

Looking at it from a infosec point of view, cloud-providers are an ideal target. All the customers who have just lost all their data now complaining to the cloud-provider are the ideal pressure-mechanism to get the cloud-provider to pay out.

permalink
report
parent
reply
1 point

A data cloud backup loss should be fine, because it’s a backup. Just re-up your local backup to a new cloud/second physical location, that’s the whole point of two.

I don’t see a need to run two conccurent cloud backups.

permalink
report
reply
2 points

In this case, it is not you -as a customer- that gets hacked, but it was the cloud-company itself. The randomware-gang encrypted the disks on server level, which impacted all the customers on every server of the cloud-provider.

permalink
report
parent
reply
1 point

Yeah absolutely, but tonyou as an individual , it’s the same net effect of your cloud backup is lost. Just re-up your local backup to a different cloud provider.

permalink
report
parent
reply
10 points

I’m more worried about what’s going to happen to all the self-hosters out there whenever Cloudflare changes their policy on DNS or their beloved free tunnels. People trust those companies too much. I also did at some point, until I got burned by DynDNS.

permalink
report
reply
1 point

We start paying for static IPs. If cloudflare shuts down overnight, a lot of stuff stops working but no data is lost so we can get it back up with some work.

permalink
report
parent
reply
2 points

They’re just creating a situation where people forget how to do thing without a magic tunnel or whatever. We’ve seen this with other things, and a proof of this is the fact that you’re suggesting you’ll require a static IP while in fact you won’t.

permalink
report
parent
reply
1 point

Where I live, many ISPs tie public IPs to static IPs if they are using CG-NAT. But of course there are other options as well. My point was that the other options don’t disappear.

Though I do get the point that Cloudflare aren’t giving away something for nothing. The main reason to me is to get hobbiest using it so they start using it (on paid plans) in their work, or otherwise get people to upgrade to paid plans. However, the “give something away for free until they can’t live without it then force them to pay” model is pretty classic in tech by now.

permalink
report
parent
reply

Selfhosted

!selfhosted@lemmy.world

Create post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

Community stats

  • 4.9K

    Monthly active users

  • 3.5K

    Posts

  • 75K

    Comments