Should you encrypt your hard drive on a server

[Mun]

What are your thoughts on this topic. Considering you have to remote Into a server on restart to enter a password. However it does protect your data.


What about on KVM environments? Can the host still see your data?


Mun

 

[Aldryic C'boas]

What about on KVM environments? Can the host still see your data?

Yes.  You can just kill the VM, mount the LVM from the node, and go rooting around just like you could an OpenVZ.  We've had to do this a couple of times when a client FUBAR'd their install, but had data they absolutely had to recover.

 

[Mun]

Even with encryption enabled on the vm?

 

[perennate]

Even with encryption enabled on the vm?

Naturally no, but can still dump RAM and such. I think since storage encryption is so easy nowadays there's no reason that you shouldn't do it (except for data which needs high IO).

 

[Lanarchy]

How would someone go about encrypting all or part of their VPS? I would, personally, like a tutorial on this posted.

 

[twolf]

How would someone go about encrypting all or part of their VPS? I would, personally, like a tutorial on this posted.

For full disk encryption, I recently came across this nice tutorial:

http://blog.tincho.org/posts/Setting_up_my_server:_re-installing_on_an_encripted_LVM/

Written for a Dedi use case, but can be done on a KVM VPS as well.

 

[Mun]

How would someone go about encrypting all or part of their VPS? I would, personally, like a tutorial on this posted.

On Debian 7 install you can during the setup of the partition choose encrypted LVM.

Mun

 

[twolf]

A neat trick for the whole encrypted disk setup is to have Dropbear (or another SSH server) running in the initial RAM disk, waiting for you to connect manually and unlock the encrypted partition or even better have a script do that automagically. Way more comfortable than having to resort to VNC or other such methods.

 

[drmike]

A neat trick for the whole encrypted disk setup is to have Dropbear (or another SSH server) running in the initial RAM disk, waiting for you to connect manually and unlock the encrypted partition or even better have a script do that automagically. Way more comfortable than having to resort to VNC or other such methods.

Do you have a how-to document for accomplishing this?  Sounds very awesome and certainly tons of folks would benefit from such knowledge.

 

[twolf]

It's included in the tutorial I linked to a few posts above.

Debian is nice enough to just "do the right thing" when installing Dropbear on a system that already has a running OpenSSH server and uses encrypted volumes. If you don't provide your own SSH public key for login before installation, it will even create a new pair you.

The unlock script then simply sends the password over the key-authenticated SSH connection into a named pipe on the remote system, which will continue booting if the correct password was supplied. For added security, you can put the password in an encrypted file on your local system and have the unlock script decrypt on demand.

 

[jarland]

I'm starting a new business carrying letters by horse for people who value data privacy. Most of the cost will go to releasing identically dressed false mail carriers to throw off the NSA's tracking effectiveness. The postal service can sue me if they can get congress to let them open their pension funds.


I know, "cool story bro."

 

[acd]

Linux FDE in a vps doesn't protect you from a snooping host if your disk is unlocked (ie, running) and the VM has the keys in memory. qemu/kvm even supports connecting to a remote debugger from the kvm console. A quick scan for common kernel memory structures will probably net you any applicable keys. And that's the hard way; the easy way is modifying your initrd to load a custom kernel module. I think there's a topic on this forum about it from a few months ago where I mentioned this previously.

More of a hassle, sure, but in no way difficult. Maybe if you used FDE in conjunction with a TPM and a microkernel that enforced permissions in modules or you didn't allow loadable (and unloadable) modules it would be more resilient, but as is it's not so great. As usual, it's an added layer of security but not without flaws.

What it comes down to is on your VPS, you must trust your host not to pry.

 

[perennate]

Linux FDE in a vps doesn't protect you from a snooping host if your disk is unlocked (ie, running) and the VM has the keys in memory. qemu/kvm even supports connecting to a remote debugger from the kvm console. A quick scan for common kernel memory structures will probably net you any applicable keys. I think there's a topic on this forum about it from a few months ago. And that's the hard way; the easy way is modifying your initrd to load a custom kernel module.

More of a hassle, sure, but in no way difficult. Maybe if you used FDE in conjunction with a TPM and a microkernel that enforced permissions in modules or you didn't allow loadable (and unloadable) modules would it be more resilient, but as is it's not so great. As usual, it's an added layer of security but not without flaws.

What it comes down to is on your VPS, you must trust your host not to pry.

So, why not just email your host all your data then? The only good reason to not configure an encrypted disk is if you need decently high I/O (if you're using HDD, the difference in speed will not be that great although CPU usage would be higher).

 

[Mun]

Still it is some work instead of none.

 

[acd]

So, why not just email your host all your data then? The only good reason to not configure an encrypted disk is if you need decently high I/O (if you're using HDD, the difference in speed will not be that great although CPU usage would be higher).

That's a poor analogy because the data on the disk isn't passing through anything outside of your provider's control. If you mean a third party might remove the disks from the machine, sure, it protects against that. FDE in a running vps is not a challenge to someone with root on the host and a willingness to spend 10 minutes google searching.