194
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 16 Sep 2023
194 points (96.2% liked)
Selfhosted
40383 readers
486 users here now
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Well with bare metal yes, but when your architecture is virtual, configuration rises in importance as the first line of defense. So it’s not just “yum —update” and reboot to remediate a vulnerability, there is more to it; the odds of a home lab admin keeping up with that seem remote to me.
Encryption is interesting, there really is no practical difference between cloud vs self hosted encryption offerings other than an emotional response.
Regarding security issues, it will depend on the provider but one wonders if those are real or imagined issues?
You'll have all the virtualization management functions in a separate, properly secured management VLAN with limited access. So the exposed attack surface (unless you're selling VM containers) is pretty much the same as on bare metal: Somebody would need to exploit application or OS issues, and then in a second stage break out of the virtualization. This has the potential to cause more damage than small applications on bare metal - and if you don't have fail over the impact of rebooting the underlying system after applying patches is more severe.
On the other hand, already for many years - and way before container stuff was mature - hardware was too powerful for just running a single application, so it was common to have lots of unrelated stuff there, which is a maintenance nightmare. Just having that split up into lots of containers probably brings more security enhancements than the risk of having to patch your container runtime.
Most of the encryption features advertised for cloud are marketing bullshit.
"Homomorphic encryption" as a concept just screams "side channel attacks" - and indeed as soon as a team properly looked at it they published a side channel paper.
For pretty much all the technologies advertised from both AMD and intel to solve the various problems of trying to make people trust untrustworthy infrastructure with their private keys sidechannel attacks or other vulnerabilities exist.
As soon as you upload a private key into a cloud system you lost control over it, no matter what their marketing department will tell you. Self hosted you can properly secure your keys in audited hardware storage, preventing key extraction.
Just look at the Microsoft certificate issue I've mentioned - data was compromised because of that, they tried to deny the claim, and it was only possible to show that the problem exists because some US agencies paid extra for receiving error logs. Microsofts solution to keep you calm? "Just pay extra as well so you can also audit our logs to see if we lose another key"
The azure breach is interesting in that it is vs MSFT SaaS. We’re talking produce, ready to eat meals are in the deli section!
The encryption tech in many cloud providers is typically superior to what you run at home to the point I don’t believe it is a common attack vector.
Overall, hardened containers are more secure vs bare metal as the attack vectors are radically diff.
A container should refuse to execute processes that have nothing to do with container function. For ex, there is no reason to have a super user in a container, and the underlying container host should never be accessible from the devices connecting to the containers that it hosts.
Bare metal is an emotional illusion of control esp with consumer devices between ISP gateway and bare metal.
It’s not that self hosted can’t run the same level of detect & reject cfg, it’s just that I would be surprised if it was. Securing self hosted internet facing home labs could almost be its own community and is definitely worth a discussion.
My point is that it is simpler imo to button up a virtual env and that includes a virtual network env (by defn, cloud hosting).
They rely on hardware functionality in Epyc or Xeon CPUs for their stuff - I have the same hardware at home, and don't use that functionality as it has massive problems. What I do have at home is smartcard based key storage for all my private keys - keys can't be extracted from there, and the only outside copy is a passphrase encrypted based64 printout on paper in a sealed envelope in a safe place. Cloud operators will tell you they can also do the equivalent - but they're lying about that.
And the homomorphic encryption thing they're trying to sell is just stupid.
Assuming you put the same single application on bare metal the attack vectors are pretty much the same - but anybody sensible stopped doing that over a decade ago as hardware became just too powerful to justify that. So I assume nowadays anything hosted at home involves some form of container runtime or virtualization (or if not whoever is running it should reconsider their life choices).
Just like the container thing above, pretty much any deployment nowadays (even just simple low powered systems coming close to the old bare metal days) will contain at least some level of virtual networking. Traditionally we were binding everything to either localhost or world, and then going from there - but nowadays even for a simple setup it's way more sensible to have only something like a nginx container with a public IP, and all services isolated in separate containers with various host only network bridges.
I like how you have a home smartcard. I can’t believe many do.
Why do you think cloud operators are lying?
Pretty much anyone should do. There's no excuse to at least keep your personal PGP keys in some USB dongle. I personally wouldn't recommend yubikey for various reasons, but there are a lot more options nowadays. Most of those vendors also now have HSM options which are reasonably priced and scale well enough for small hosting purposes.
I started a long time ago with empty smartcards and a custom card applet - back then it was quite complicated to find empty smartcards as a private customer. By now I've also switched to readily available modules.
One of the key concepts of the cloud is that your VMs are not tied to physical hardware. Which in turn means the key storage also isn't - which means extraction of keys is possible. Now they'll tell you some nonsense how they utilize cryptography to make it secure - but you can't beat "key extraction is not possible at all".
For the other bits I've mentioned a few times side channel attacks. Then there's AMDs encrypted memory (SEV) claiming to fully isolate VMs from each other, with multiple published attacks. And we have AMDs PSP and intels ME, both with multiple published attacks. I think there also was a published attack against the key storage I described above, but I don't remember the name.
I agree that our stuff is unlikely to be victim of an targeted attack in the cloud - but could be impacted by a targeted attack on something sharing bare metal with you. Or somebody just managed to perfect one of the currently possible attacks to run them larger scale for data collection - in all cases you're unlikely to be properly informed about the data loss.