Encryption

havoc

I'm looking to sprinkle some encryption on my VPS - just for good measure.

Found this article on LET but it's from 2016 and commenters did not have a high opinion of author's skill.

So just want to check what if that's still roughly state-of-the-art?

Not looking to defend against sophisticated attackers (RAM dump etc) and I'm fine with OS partition being unencrypted. Database / docker / home should be though.

A solution compatible with ansible deployment would be a bonus since that's the next thing I'm tackling.

tgl

use LUKS, works fine also for separate partitions, its supported by default so I do not see any point in using alternatives unless you want to reinvent the wheel

cryptsetup luksFormat /dev/porno2
cryptsetup luksOpen /dev/porno2
mount /dev/mapper/porno2 /mnt/porno2

dahartigan

LUKS is about as good as it gets, it's baked into Linux and I can recall no major breaches (weak passphrases don't count)

tetech

I use LUKS and pull the encryption key from a keyserver on boot via https. This way I do not have to manually intervene after a reboot, the password is not stored on the VM itself, and to revoke I delete the DB entry in the keyserver. Of course whoever controls the host can always do stuff with a running VM, but at least this means I effectively don't care what happens to the disk if they go belly-up.

mfs

@havoc said: some encryption on my VPS - just for good measure.

@havoc said: I'm fine with OS partition being unencrypted. Database / docker / home should be though

It seems to me you have to better figure out what's the attack surface you're trying to harden, against whom and for which purposes. Anything besides FDE is pretty moot since you're likely to have (potentially) sensitive data in other places of your OS.
Deploying "encryption at rest" inside a VM for $HOME and few other mount points seems almost a rhetorical exercise. Still a good exercise, nevertheless. I only hope you aren't lead to believe that encrypting your docker mountpoint will harden or protect your dockers

@tetech said: pull the encryption key from a keyserver

Did you explore clevis+tang? It works on Debian, too. it can use multiple kinds of pins.

tetech

mfs said: Did you explore clevis+tang? It works on Debian, too. it can use multiple kinds of pins.

No, I'm doing it differently.

havoc

@tetech said:
I use LUKS and pull the encryption key from a keyserver on boot via https.

That seems like the least painful solution. How do you make sure the keyserver isn't accessible from other sources? IP block?

Also requires a keyserver. Tempted to make the VPS from different providers act as key servers for each other & then just back up everything regularly in case something goes tits up.

mfs said: what's the attack surface you're trying to harden

Disk landing on landfill / provider deadpooling. Just trying to get away from straight plaintext basically, not really defending against a motivated attacker.

tetech

havoc said: That seems like the least painful solution. How do you make sure the keyserver isn't accessible from other sources? IP block?

1. iptables filters out everything not in my DNS zone files. 2. The requesting VPS passes a device key, key=$( curl -fs -H "X-LXC-Id: ${devicekey}" "${keyservapi}/getkey" ). 3. The keyserver returns a 403 if either the device key or IP address don't match.

Keyserver is one PHP file and a SQLite DB. Actually it does a bit more; the keyserver's response can instruct the VM to re-encrypt the partition with a new key it provides. I might also monitor the keyserver and reboot if the keyserver is unreachable for some time, but I haven't got an automatic failover on the keyserver yet.

mfs

@tetech said: I'm doing it differently.

I see. I used to fetch remote keys but it wasn't always possible, or convenient, to secure the transport layer as in Mandos and NBDE solves that.

@tetech said: . Actually it does a bit more; the keyserver's response can instruct the VM to re-encrypt the partition with a new key it provides

Straight after boot? As in, cycling keys after reboot?

@havoc said: Disk landing on landfill / provider deadpooling. Just trying to get away from straight plaintext basically

Well I'd consider to also include /var at least if / doesn't work for you.

tetech

mfs said: Straight after boot? As in, cycling keys after reboot?

I don't currently cycle keys automatically on boot. My scenario is a bit different. I have a partition with LXC containers which is what is encrypted.