Simple safe encryption for a server?
Simple safe encryption for a server?
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)
You can actually unlock LUKS from another machine over SSH: https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/
I'm pretty happy with this solution
I saw this and thought "How is this even possible? No way you run an SSH server from initramfs…" Turns out that's exactly how you do it, I'll be trying this out thank you!
This is the way.
LUKS can use a TPM now.
Wait, how's this gonna help? If someone swipes the machine, they also have the TPM. TPM only helps against someone reading the disks on another machine. TPM is only useful to protect data during physical access if the rest of the firmware/software stack is impenetrable. In practical terms this would mean locked UEFI, disabled alternate boot device, Secure Boot, locked GRUB, and locked logins. In effect the security of the data is transferred from the knowledge of a passphrase to the knowledge of a login password, and the attack surface is expanded across multiple systems that all have to be secure and configured correctly to not allow access prior to OS login.
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.
I worte a guide last year on how I do network bound encryption - that is the disk will automatically decrypt at boot if it's connected to my home network, but not if the disk or machine is removed from my house. The advantage over the dropbear method is that you can set unattended upgrades to auto reboot your server whenever it installs security updates, and it'll come back up with no manual intervention from you.
Do encrypted backups with Borgbackup or similar. That means the server never sees the plaintext or the decryption keys. The encryption happens on the client. Since it's public-key encryption (separate keys for encryption and decryption), the client doesn't need the decryption key either, except when restoring. So your backup can be automated without secret keys.
Only useful if the backup machine isn't also used as a hot spare.
If you want simple you'll have to manually decrypt each time it needs doing.
If you want it to be "automatic" then your best bet is something network based. A "simple" would be to just have a script ssh's somewhere, pulls the decryption key, and then decrypts the disks. There's plenty of flaws with this though as while a threat actor couldn't swipe a single encrypted disk they could just log in as root, get your script, and pull the decryption key themselves.
The optimal solution would be to also encrypt the root partition but now you need to do network based decryption at boot which adds further complexity. I've previously used Clevis and Tang to do this.
I personally don'tencrypt my server root and only encrypt my data disks. Then ssh in on a reboot or power event and manually decrypt. It is the simplest and most secure option.
As mentioned elsewhere, the easiest method is to encrypt only the data drives. This way you can secure shell into the server upon restart and decrypt the data. I've been using this method for years now without issue.
I am not seeing any benefit over this solution https://lemmings.world/comment/10027984 , were even the root is encrypted. With dropbear installed on initramfs you can also just ssh into the server to unlock everything.
The dropbear method is more secure overall, and I plan to incorporate it as well when I find the time to wipe/reinstall my server, but it's arguably not as easy or simple, which is what OP requested.
I use a luks encrypted USB drive for automated backups. My backup script mounts and decrypts the drive automatically, using secret-tool to grab the encryption pass from my keyring. It then creates the snapshots, and automatically unmounts the drive after.
There might be better methods, but this one works well for me.
If someone can login as root on that machine, by for example rebooting in recovery mode, they can also run the script and access the drives. Or they can get the password from the keyring. A keyring that doesn't require a password to unlock or whose password is stored somewhere on the machine is equivalent to plain text storage. There's no obvious solution other than ensuring the system can't be rooted without a login, I'm just pointing the flaw out in case you feel it's more secure than it is.
In my case root partition is encrypted, and the keyring has to be unlocked every time you reboot.
Here’s my way of doing it. TLDR: LUKS with a encryption key hosted in my router
https://nowicki.io/self-hosting-lvm-raid1-with-key-over-ftp/
I think you can encrypt drives by using a key stored in the TPM, if you have one. See the Arch wiki for info.
Though I have heard the TPM is not as secure..
Take some time and really analyze your threat model. There are different solutions for each of them. For example, protecting against a friend swiping the drives may be as simple as LUKS on the drive and a USB key with the unlock keys. Another poster suggested leaving the backup computer wide open but encrypting the files that you back up with symmetric or asymmetric, based on your needs. If you're hiding it from the government, check your local laws. You may be guilty until proven innocent in which case you need "plausible deniability" of what's on the drive. That's a different solution. Are you dealing with a well funded nation-state adversary? Maybe keying in the password isn't such a bad idea.
I'm using LUKS with mandos on a raspberry PI. I back up to a Pi at a friend's house over TailScale where the disk is wide open, but Duplicity will encrypt the backup file. My threat model is a run of the mill thief swiping the computers and script kiddies hacking in.