Hi, I’m running a ubuntu based backup server. And was wondering if there’s a simple way to encrypt my drives in case they get swiped or something by a break in. But also in a way that the computer can be restarted and decrypt the drive without me needing to stick a key in everytime. Any ideas? It seems basic but I’m not an expert on all these newfangled encryption terminology, so would like something idiot proof (by idiot proof, not idiot enough to lose/forget the decryption key)
I read it as external drives, as someone “swiping the drives” without having stolen the whole ass computer kinda requires that?
I agree that if someone steals the whole computer, you’re pretty fucked unless you have a password entered somewhere in the chain to actually do the decryption, but I mean, they explicitly didn’t want that.
I’m not sure there’s a good way to encrypt a system that’ll boot with no interaction (and thus has to be able to decrypt itself with no input) and prevent access if it’s stolen.
This is one of those ‘software security doesn’t matter if you can’t guarantee physical security’ meta-problems, probably.
Yeah, you’re right, if it’s meant as disks-only, then TPM is the easy solution.
I think SSH unlocked LUKS at boot might be a decent compromise, with the SSH server at a different physical location.
I mean, TPM-locked machine with all the other parts configured correctly should be reasonably secure. It would boot without interaction and be available on the network. It would require a sophisticated and motivated actor to find a vulnerability in one of the systems in the boot chain to get in. That’s probably good enough for preventing data leaks from theft. But the user has to make sure the whole boot chain is configured securely.
Yeah, and the threat actor here is probably less ‘guy who knows Linux, LUKS, and how to bypass this’ and more ‘dude who wants to sell this for $5 on craigslist for more meth’, which pretty much means if the data is encrypted at rest and generally not accessible without logging in with a password they don’t have then it’s… probably fine?
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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).
I read it as external drives, as someone “swiping the drives” without having stolen the whole ass computer kinda requires that?
I agree that if someone steals the whole computer, you’re pretty fucked unless you have a password entered somewhere in the chain to actually do the decryption, but I mean, they explicitly didn’t want that.
I’m not sure there’s a good way to encrypt a system that’ll boot with no interaction (and thus has to be able to decrypt itself with no input) and prevent access if it’s stolen.
This is one of those ‘software security doesn’t matter if you can’t guarantee physical security’ meta-problems, probably.
Yeah, you’re right, if it’s meant as disks-only, then TPM is the easy solution.
I think SSH unlocked LUKS at boot might be a decent compromise, with the SSH server at a different physical location.
I mean, TPM-locked machine with all the other parts configured correctly should be reasonably secure. It would boot without interaction and be available on the network. It would require a sophisticated and motivated actor to find a vulnerability in one of the systems in the boot chain to get in. That’s probably good enough for preventing data leaks from theft. But the user has to make sure the whole boot chain is configured securely.
Yeah, and the threat actor here is probably less ‘guy who knows Linux, LUKS, and how to bypass this’ and more ‘dude who wants to sell this for $5 on craigslist for more meth’, which pretty much means if the data is encrypted at rest and generally not accessible without logging in with a password they don’t have then it’s… probably fine?