New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Best Full Disk Encryption Option For LowEnd Dedicated Server?
4pple5auc3
Member
in Help
What is the best full disk encryption option for a lowend dedicated server running Debian 12 or Ubuntu 22.04? LUKS?
Do you have any recommendations, best practices, guides, etc on this?
I read that dedicated servers are more secure than a VPS as a snapshot could easily be taken and from there someone could pull the decryption key from ram. Thoughts on this?
Comments
At one point in time there was TrueCrypt.
I think VeraCrypt forked from it but don't quote me on that.
Right now that seems like the best option available.
Yes - if you snapshot the VM's memory via the host node, there are known ways (with some reasonable trial and error) to get access to the decryption keys. Coupled with LUKS's header (even from the past), it makes it possible to decrypt the volume.
It's quite hard to get paranoid level security on (virtual) machines that you don't control physically.
If the limitations are acceptable, then you can do any of the following:
1. Boot unencrypted OS, and decrypt LUKS volume on demand/need.
2. Boot into dropbear (via initramfs) which waits for you to interactively decrypt entire OS (non-boot) volume.
3. Customize initramfs to "fetch" a decryption key via HTTPS (or similar), letting you control the key-distribution server to only allow it when you're really booting the VM/node.
4. Use clevis-tang (like 3)
5. Full scale encryption including boot partition requiring interactive decryption at boot - this implies IPMI or equivalent (like VNC/console) but then again, no guarantees on MITM-proof key entry since the infrastructure is not really controlled by you.
Don't let (2) fool you into a false sense of security - the initramfs is unencrypted and so can be tampered with to save the key as well.
tl;dr - there is no real guaranteed security in any of these setups. They are various levels of deterrence to prevent unintended leaks of data, tampering, stupidity (either user or provider) etc. If you don't physically control/own the node, don't bet on anything.
Even if you physically control your server you can still be mitm'ed on the network level at some point if you piss serious enough folks. And backups. Yes, and headache to keep backups also on paranoid level.
You can luks encrypt the OS and data and unlock on every restart with initramfs and remote SSH. I use it on a Kimsufi KS-LE-1 and does not have any negative impact on performance.
I'm thinking on a solution that calls an API endpoint or something other from initramfs and it can trigger my router to unlock the server over SSH but now it is only an idea.
tl;dr: Use TPM + LUKS if you are only afraid of the disk being used in a different system.
You can't really have "it boots automatically", "truly secure disk", "I have not owned the hardware from original unboxing to the present moment", and "the hardware is not under my direct control", all at once.
The absolute closest you will get is something like using TPM + LUKS (after clearing the TPM, of course!): https://github.com/vchatterji/tpm2-luks
Of course, there are dirt cheap pre-"owned" TPM modules out there. That is much of why Windows has such strict TPM requirements for Windows 11: they're eliminating most of the untrustworthy TPMs currently on the market.
However, the odds of a random provider having put a replacement TPM into the header are slim, since most people don't even use TPM even when they could easily do so. Especially at the low end.
And, in honesty, TPM + LUKS is probably easier than lots of LUKS approaches these days. It might just take a few wipe + reinstall cycles to get to where you want it.
The approach will thwart almost every attack type. The person trying to get the data will have to have enough clue to realize you're using LUKS + TPM in honesty. Especially if you make your startup output not list the letters "TPM" or "LUKS" at all and lock down your boot loader to not show your boot options and especially not allow modifying them.
Disk clones and moving the disk to other hardware will be useless. It will literally only boot in the original system. If you are uber-paranoid and compile your own EFI boot loader to do something like "boot the latest kernel on disk with static options that are not obviously exposed in the binary", you'll probably have thwarted most attackers up to the 3-letter-agency level (most likely best case is they'll have to try to brute force
rootwhich you should already have set as no-login, right?). And if they are your concern, you probably then have also bought yourself enough time to GTFO from wherever before they get the pieces put together to get that disk accessed.Best is kind of relative here as it won't get better than the encryption scheme being secure anyways. Remote unlocking will always have the same downsides/risks and so will combining it with virtualization. In general it's mostly about being aware of those gotchas and accepting that - as others said before - encryption on a machine one doesn't control physically will never be 100% secure.
It pains me to say it, but the only bulletproof solution besides hosting at home is AWS (Nitro on Graviton)
All of AMD and Intel’s attempts at encrypted memory or enclaves have holes, and FDE ain’t safe on its own
There was at one time, truecrypt went to court 10 or so years ago and wouldn't divulge keys. It was that strong FBI couldnt get in. Needless to say, I'm pretty sure they closed up after 🤔
Vera was shortly after.
@4pple5auc3 no one has said it, so let me be devils advocate here since we own a DC. I've had customers do this, then have a failed drive or can't remember password, then demand we hook up a monitor and get them back in or get files from it 🤦🏻♂️
Once you do this, you better have backups. No DC tech is gonna be able to get you back in or recover anything from it once you do it. Just stating the obvious to make sure you're well aware, as we have had customers do this in the past 😂
Well, i might be missing something but i don't see how this would seriously improve things anyways as you still have the unlock problem, right? As long as you don't have physical access to the box you can't really prevent the possibility of your key being logged one way or another, so what gives?
There's increased attack vector on VPS yes. It can be a hostile seller or simply bad actor breaking through walls like the Titanic. There's a handful of software everyone uses, matter of being victim of an exploit. With a VPS the likelihood is significantly larger as its just easier. It's still perfectly fine for storing encrypted data and never unlock it on the same vulnerable system. Things like not using NoVNC but rather SSH from your own installed ISO helps here. The entry level of key logging from software is peanuts, reading RAM is just hard work.
With a dedi your still stuck with an OS on closed-source hardware in 99% of the cases. Sellers are capable of using firmware that integrates with the OS, similar how VPS are vulnerable. It does get a little more complex but I doubt these things are being sold at large scale without tools that make their operation sustainable.
For the average use case something like TrueNAS is very convenient but costs $4 more in RAM but worth it. Keeping it simple and not overdoing it, is important here.
All tips you can get there, interesting website with useful content.
https://sizeof.cat/links/#disk-encryption
i would not use veracrypt. it should speak for itself, when different terror groups and cartels still use truecrypt 7.1a with certain encryption/hash methods
Time to resell bulletproof hosting at a 300% (min.) Markup, I guess
does veracrypt fulldiscencryption work on a kvm-vps?
If you never need to decrypt on the vps/dedicated server. Like in a remote backup situation. when you want the data you just send it back to a machine under your complete control. the keys never are loaded on the vps/dedicated server. Note that the dataset structure names are visible but not the data
zfs send -w tank/encrypted-fs@snap1 | ssh target1 zfs recv -f dst/fs1
-w, --raw
For encrypted datasets, send data exactly as it exists on disk. This allows backups
to be taken even if encryption keys are not currently loaded. The backup may then be
received on an untrusted machine since that machine will not have the encryption keys
to read the protected data or alter it without being detected. Upon being received,
the dataset will have the same encryption keys as it did on the send side, although
the keylocation property will be defaulted to prompt if not otherwise provided. For
unencrypted datasets, this flag will be equivalent to -Lec. Note that if you do not
use this flag for sending encrypted datasets, data will be sent unencrypted and may be
re-encrypted with a different encryption key on the receiving system, which will
disable the ability to do a raw send to that system for incrementals.
Think I'm just going to use this guide on a small dedicated box and realize that it can't be 100% perfect unless I have easy physical access to it. https://leduccc.medium.com/securing-your-digital-life-a-guide-to-creating-a-fully-encrypted-vps-572d2ea314d5
Do ARM servers handle encryption any differently? Do they offer any benefit to security like not being accessible via snapshot, ram, hypervisor, etc?
What about Secure Encrypted Virtualization (SEV)? Would this prevent key leaking in snapshot or ram? If so, any providers offering this?
Yea, very good marketing