I currently have a storage server with the following config.
Multiple raid6 volumes (mdadm) -> aggregated into a lvm volume group -> lvm volumes -> encrypted with luks1 -> (no partitioning) xfs file systems mounted and used by the os
I have the following criteria: I want to keep software raid (mdadm) with multiple raid sets, xfs, and lvm. I don’t mind using 2fa, but I don’t want to just store my secret keys on a dongle attached to my PC because that seems to defeat the point of encryption at rest.
My questions:
Is there a better way to encrypt my data at rest?
Is there a better layer at which to apply the encryption?
I’m mostly unhappy with luks1 over a whole lvm volume and looking for alternatives.
–
Thank you everyone for these great responses! I’ll be looking into these ideas :)
TPM & secure boot. Look into sbctl for secure boot if you’re not on something that uses the signed shim like ubuntu. I know some hate secure boot but storing the unlock key in tpm is at least much more secure than having the key sitting on a usb drive
Tang - network based unlock. If you have a separate raspberry pi or something you can set it up as a tang server. You’ll want that thing encrypted too, can set that up to require manual unlock so if someone boosts your servers the tang server never comes up, storage server won’t either
Or just manually unlock the server with a password every boot?
Encrypt the boot drive, and use dropbear ssh in initramfs to be able to unlock it over ssh during boot. Then set up your data drives however you want, and use a key file on your boot drive to unlock them, once you’ve unlocked it. All drives are encrypted when your machine is off, and you only need one password you can enter remotely to unlock the whole thing.
Also, when you update the kernel you have to rebuild the initramfs with sudo update-initramfs -k all -u, or it won’t be able to boot to the new kernel.
Have not looked through the setup steps of that link, but using FDE with luks and remote ssh unlock for years and have not had any problems.
Also, when you update the kernel you have to rebuild the initramfs with sudo update-initramfs -k all -u, or it won’t be able to boot to the new kernel.
Shouldn’t that be automatically handled by apt? I dont remember that i have setup a hook for that and i never rebuild my initramfs manually.
I was a bit surprised at it as well, but it doesn’t for me running Debian headless. If I reboot after a kernel update it’ll try to boot into the new kernel and fail waiting for the initramfs, but it’ll boot just fine into the previous kernel. Once I update the initramfs it works fine.
If you know what resources you used to set it up, I’d be curious to take a look and see if I missed something.
That’s basically the same as my writeup from when I did it. Except I also had a -k all on update-initramfs. Not sure about the switches, so I’ll look into them. Thanks.
You can layer them however you want, so you can slap luks on the physical drives, or the mdraid, or the individual LVM volumes as you do right now. If the entire setup is either locked or unlocked, luks between the raid and LVM PV makes sense. Having luks on the individual LVs have the advantage that you can have your data partially unlocked.
2FA is complicated. You can use a second factor like, you need to enter both a password and be in possession of the flash drive, but you can’t do it with the standard TOTP codes because you need the key to validate them in the first place.
One thing you can explore is TPM: the computer can detect if it’s been tampered with, and if all checks out, it will unwrap the key. You can add a password or flash drive as a second factor. There’s also the whole smartcard rabbit hole.
What exactly are you unsatisfied with? I think that’s a better starting point to advise on.
Second the key-password combo. It keeps the keys you have on the flash drive but adds a password component that thieves would need to figure out as well. Just make sure to pick a good password!
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).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
deleted by creator
TPM & secure boot. Look into sbctl for secure boot if you’re not on something that uses the signed shim like ubuntu. I know some hate secure boot but storing the unlock key in tpm is at least much more secure than having the key sitting on a usb drive
Tang - network based unlock. If you have a separate raspberry pi or something you can set it up as a tang server. You’ll want that thing encrypted too, can set that up to require manual unlock so if someone boosts your servers the tang server never comes up, storage server won’t either
Or just manually unlock the server with a password every boot?
That’s roughly my prioritized/preferred list
Encrypt the boot drive, and use dropbear ssh in initramfs to be able to unlock it over ssh during boot. Then set up your data drives however you want, and use a key file on your boot drive to unlock them, once you’ve unlocked it. All drives are encrypted when your machine is off, and you only need one password you can enter remotely to unlock the whole thing.
Here’s a good resource on how to do the initramfs part https://www.arminpech.de/2019/12/23/debian-unlock-luks-root-partition-remotely-by-ssh-using-dropbear/
Also, when you update the kernel you have to rebuild the initramfs with sudo update-initramfs -k all -u, or it won’t be able to boot to the new kernel.
I’ve found it to be a super reliable setup.
Have not looked through the setup steps of that link, but using FDE with luks and remote ssh unlock for years and have not had any problems.
Shouldn’t that be automatically handled by apt? I dont remember that i have setup a hook for that and i never rebuild my initramfs manually.
I was a bit surprised at it as well, but it doesn’t for me running Debian headless. If I reboot after a kernel update it’ll try to boot into the new kernel and fail waiting for the initramfs, but it’ll boot just fine into the previous kernel. Once I update the initramfs it works fine.
If you know what resources you used to set it up, I’d be curious to take a look and see if I missed something.
Steps are basically not more then this (Can not find the original blog i followed but this is the small write up i have made years ago)
For some reason i install busybox too in the personal write up. But i do not think it is necessary.
That’s basically the same as my writeup from when I did it. Except I also had a -k all on update-initramfs. Not sure about the switches, so I’ll look into them. Thanks.
You can layer them however you want, so you can slap luks on the physical drives, or the mdraid, or the individual LVM volumes as you do right now. If the entire setup is either locked or unlocked, luks between the raid and LVM PV makes sense. Having luks on the individual LVs have the advantage that you can have your data partially unlocked.
2FA is complicated. You can use a second factor like, you need to enter both a password and be in possession of the flash drive, but you can’t do it with the standard TOTP codes because you need the key to validate them in the first place.
One thing you can explore is TPM: the computer can detect if it’s been tampered with, and if all checks out, it will unwrap the key. You can add a password or flash drive as a second factor. There’s also the whole smartcard rabbit hole.
What exactly are you unsatisfied with? I think that’s a better starting point to advise on.
Second the key-password combo. It keeps the keys you have on the flash drive but adds a password component that thieves would need to figure out as well. Just make sure to pick a good password!
First off if I remember correctly there was some people complaining they lost everything with XFS so be careful.
Secondly, could you use a iSCI volume? It would limit it to your laptop only but you should be able to encrypt it all.
The other option is to encrypt some sort of file that holds your data.