Encrypting VPS with LUKS - is it possible and is it worth it? reddit / selfhosted ---------------------------------------------------------------------- cyph3rjo3 · 2023-09-30 13:19 So I've been learning a bit more about LUKS. I never bothered to encrypt my drives before, but have started doing so on my local machines. But when it comes to VPS's, is it possible to do this remotely and is it worth it? I was thinking of getting another VPS from my hosting provider Hetzner (shared vCPU). First, is it possible to encrypt it using LUKS? And does the shared vCPU come with any risks? They come with Debian 12 pre-installed. I have no clue how to set up LUKS remotely, and I find no tutorials about it. Any tips? And second of all (if it is possible), is it worth it? In this case Hetzner would be able to get into it anyways. And since the VPS is going to be on pretty much all year round, decrypted, would it even matter? I saw a thread on r/Linux a while ago talking about performance impact of using something like LUKS to encrypt your data. So if I'm paying for something and LUKS might drop its performance 30-50% as some users reported, it wouldn't make much sense. I'm not going to store anything super sensitive. Mainly just some order/customer information (I run e-commerce stores). ---------------------------------------------------------------------- chaplin2 · 2023-09-30 15:06 The problem is, in the basic setup, you can’t SSH into the VPS to enter the LUKS password. You need physical access and monitor. I’m aware that there are ways around it, but they require some work and may be fragile. Also, the VPS can’t automatically reboot, for example after unattended upgrades. ---------------------------------------------------------------------- chrillefkr · 2023-09-30 17:03 The way I see it is that LUKS only provides data at rest encryption, i.e. if the physical medium (HDD/SSD) would be stolen, data would be difficult to extract. Your VPS provider probably already encrypt all their disks. If you have sensitive data that shouldn't be physically stolen, and you don't trust your provider's own encryption, then you should host it elsewhere or by yourself. Your hosting provider are able to access your whole drive once you unlock it anyways. I see no security benefit here. I might be wrong though ---------------------------------------------------------------------- ev1z_ · 2023-09-30 19:24 It will prevent exploitation of the storage backend as everything is written encrypted. However, it's not worth the bother for two reasons: 1- You need an out of band console like VNC to actually boot the VPS. 2- RAM is in cleartext, meaning it doesn't bring added protection to things like Meltdown or Zenbleed, which is the actual most relevant threat in cloud. You need to be afraid of the other processes (understand: VPS'es) running alongside yours on the server, because they're more likely to be actively exploited than your VPS host. ---------------------------------------------------------------------- mladokopele · 2023-09-30 19:59 You can actually unlock your root or any other luks encrypted partition via ssh by loading tinyssh during boot: https://wiki.archlinux.org/title/Dm- crypt/Specialties#Remote_unlocking_of_root_(or_other)_partition The issue with the VPS provider however remains as some hypervisor OSes have the ability to take live snapshot of the running VM and clone it as such without actually booting (and having to unlock the encrypted drive) the OS. ---------------------------------------------------------------------- speculatrix · 2023-09-30 20:45 Not quite the answer you need but might still solve your problem. It's possible to use nbd to make a rented/ untrusted vm's raw disk accessible over a network connection. You make a VPN from a trusted machine to the untrusted one, add a LUKS layer on the trusted machine, then format and mount the remote drive. So Trusted os->LUKS-> nbdclient->wireguard->VM->nbdserver-> disk If the remote VM is compromised, the disk is garbage to the hosting company. There's no keys in the VM's ram to steal. ---------------------------------------------------------------------- ZaxLofful · 2023-10-01 01:21 This is the reasonable answer! ---------------------------------------------------------------------- dorynz · 2023-10-01 01:34 Have a look at Clevis and and tang server setup We use it to encrypt disks and then when booting has to come back to us via tang and https to get the keys to boot, if you used a rhel flavour you can could do a kickstart and stage 2 boot off a remote server just with kernel arguments and some boot files and reinstall onto luks ---------------------------------------------------------------------- bobsbuttplug · 2023-10-01 04:29 I've done this with a 5 dollar VPS that has VNC access and a recovery ISO boot option. https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear- ssh-keys-remotely-in-linux/ https://blog.kamens.us/2017/07/25/howto-converting-an-unencrypted- ubuntu-root-disk-to-encrypted/ This is a cleaned up version of my notes, you will need to really understand linux boot (been doing this shit since I was 8) Basically: * First you need to test ssh to the server, and VNC. Ensure you can boot the recovery. You'll need another server to bounce shit off of. * I had a 25g partition as / on this. I need to resize this so I can move shit around. **How to resize it** Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: Device        Start      End  Sectors Size Type /dev/vda1      2048     4095     2048   1M BIOS boot /dev/vda2      4096 50329087 50324992  24G Linux filesystem /dev/vda3  50329088 52426239  2097152   1G Linux swap **First boot to rescue** **Then e2fsck -f /dev/vda2** rescue # e2fsck -f /dev/vda2 e2fsck 1.43.4 (31-Jan-2017) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/vda2: 161363/1572864 files (0.5% non-contiguous), 1070470/6290624 blocks **Then resize2fs /dev/vda2 10G** rescue # resize2fs /dev/vda2 10G resize2fs 1.43.4 (31-Jan-2017) Resizing the filesystem on /dev/vda2 to 2621440 (4k) blocks. The filesystem on /dev/vda2 is now 2621440 (4k) blocks long. **Now knowing that the disk is in 512 byte blocks we need to resize it to fit** (50329087-4096)*512/4096 = 6,290,623.875 or 6290624 2621440*4096 = 10,737,418,240 bytes 10,737,418,240/512 = 20,971,520 512k blocks Add 4 more blocks to it 20,971,524 blocks is the new length 4096 + 20971524 = 20975616 last sector rescue # fdisk /dev/vda Welcome to fdisk (util-linux 2.29.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: Device        Start      End  Sectors Size Type /dev/vda1      2048     4095     2048   1M BIOS boot /dev/vda2      4096 50329087 50324992  24G Linux filesystem /dev/vda3  50329088 52426239  2097152   1G Linux swap Command (m for help): d Partition number (1-3, default 3): 2 Partition 2 has been deleted. Command (m for help): n Partition number (2,4-128, default 2): 2 First sector (4096-52428766, default 4096): 4096 Last sector, +sectors or +size{K,M,G,T,P} (4096-50329087, default 50329087): 20975616 Created a new partition 2 of type 'Linux filesystem' and of size 10 GiB. Partition #2 contains a ext4 signature. Do you want to remove the signature? [Y]es/[N]o: n Command (m for help): p Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: Device        Start      End  Sectors Size Type /dev/vda1      2048     4095     2048   1M BIOS boot /dev/vda2      4096 20975616 20971521  10G Linux filesystem /dev/vda3  50329088 52426239  2097152   1G Linux swap Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. rescue # mount /dev/vda2 /mnt rescue # cd /mnt rescue # ls bin   dev  home        initrd.img.old  lib64       media  opt   ro ot  sbin  srv  tmp  var      vmlinuz.old boot  etc  initrd.img  lib             lost+found  mnt    proc  ru n   snap  sys  usr  vmlinuz rescue # df -h Filesystem      Size  Used Avail Use% Mounted on udev            110M     0  110M   0% /dev tmpfs            25M  4.4M   20M  18% /run /dev/vdb1       1.1G  660M  375M  64% / tmpfs           121M     0  121M   0% /dev/shm tmpfs           5.0M     0  5.0M   0% /run/lock tmpfs           121M     0  121M   0% /sys/fs/cgroup tmpfs            25M     0   25M   0% /run/user/0 /dev/vda2       9.8G  3.7G  5.7G  40% /mnt **Delete the swap** **Copy the file via ssh to backup host** dd if=/dev/vda2 | gzip -1 - | ssh $host dd of=/home/vda2.img.gz **Ok, now we need to make a new partition layout** 1 - efi 2 - boot 3 - swap 4 - root +20979713 (including extra space for LUKS) export PAGER='/bin/more’ rescue # fdisk  /dev/vda Welcome to fdisk (util-linux 2.29.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: Device       Start      End  Sectors Size Type /dev/vda1     2048     4095     2048   1M BIOS boot /dev/vda2     4096  4198399  4194304   2G Linux filesystem /dev/vda3  4198400  8392703  4194304   2G Plan 9 partition /dev/vda4  8392704 29364223 20971520  10G Linux filesystem Command (m for help): t Partition number (1-4, default 4): 3 Hex code (type L to list all codes): 19 Changed type of partition 'Plan 9 partition' to 'Linux swap'. Command (m for help): p Disk /dev/vda: 25 GiB, 26843545600 bytes, 52428800 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: Device       Start      End  Sectors Size Type /dev/vda1     2048     4095     2048   1M BIOS boot /dev/vda2     4096  4198399  4194304   2G Linux filesystem /dev/vda3  4198400  8392703  4194304   2G Linux swap /dev/vda4  8392704 29364223 20971520  10G Linux filesystem Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. Add crypt setup to the rescue apt-get install cryptsetup **Now since we're on VNC, and it's unencrypted, use a temp passwd** rescue # cryptsetup luksFormat /dev/vda4 WARNING! ======== This will overwrite data on /dev/vda4 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: changeme Verify passphrase: changeme cryptsetup luksOpen /dev/vda4 rootencdev Enter passphrase for /dev/vda4: cryptsetup resize rootencdev **copy it all back to the server now** ssh $SERVER "dd if=vda2.img.gz " | gunzip -c | dd of=/dev/mapper/rootencdev status=progress apt-get install vim rsync **mnt/root/etc/crypttab** rootencdev      /dev/vda4       none    luks,discard **After this mount it** mkdir /mnt/root && mount /dev/mapper/rootencdev /mnt/root **make a fs on the new boot** rescue # mkfs.ext4 /dev/vda2 mv -T /mnt/root/boot /mnt/root/boot.orig mkdir /mnt/root/boot && mount /dev/vda2 /mnt/root/boot rsync -av /mnt/root/boot.orig/ /mnt/root/boot/ for dir in /sys /proc /dev; do mount --bind $dir /mnt/root$dir; done chroot /mnt/root /bin/bash sudo apt update sudo apt upgrade sudo apt install dropbear-initramfs cd /etc/dropbear-initramfs vim config DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s” RESCUE ip config on kernel cmdline : ip=$IPv4::$GW:$MASK::eth0:none #vim /etc/initramfs-tools/initramfs.conf IP=$IPv4::$GW:$MASK:$HOSTNAME sudo update-initramfs -u -v cp /root/.ssh/authorized_keys /etc/dropbear-initramfs/ update-initramfs -u -k all grub-install /dev/vda update-grub reboot **ssh in and unlock it.** ssh -p 2222 $IP cryptroot-unlock cryptsetup luksChangeKey /dev/vda4 Now add the crypto to the swap device vim /etc/crypttab # rootencdev      /dev/vda4       none    luks,discard swap    /dev/vda3       /dev/urandom    swap,cipher=aes-xts- plain64,size=256 root@$HOSTNAME:~# vim /etc/fstab /dev/mapper/swap swap swap defaults 0 0 ---------------------------------------------------------------------- cyph3rjo3 · 2023-10-01 09:31 Yeah that's what I was thinking. I guess it's just not worth the time to try get LUKS on a VPS. It doesn't make much sense. Thank you for your input! ---------------------------------------------------------------------- cyph3rjo3 · 2023-10-01 09:33 That's what I suspected. It doesn't seem like it's worth it to try get encryption to work. Thank you for your input. ---------------------------------------------------------------------- cyph3rjo3 · 2023-10-01 09:34 My mind just exploded reading this haha. I will probably not encrypt the VPS. It seems a bit complicated and most likely not even worth it in the end. Thnaks for your input ---------------------------------------------------------------------- cyph3rjo3 · 2023-10-01 09:38 Thank you for your input! At a first glance, it seems really advanced. And in the end, it might not be worth it? I don't know... For now I guess I will stick with no encryption, but will definitely try it out on some cheap extra test VPS on the side (no production data) in the case I screw it up completely haha. ---------------------------------------------------------------------- cyph3rjo3 · 2023-10-01 09:39 Yeah this seems like it's just far too advanced for me at this point and in the end it might not even be worth it. Thank you for your input! ---------------------------------------------------------------------- stinkyfatman2016 · 2023-10-01 10:55 Slightly related question, do any tools such as LUKS support quantum resistant cryptographic algorithms? ---------------------------------------------------------------------- zzzz0nk3d · 2023-10-01 11:43 \+1 for clevis + tang - i use this extensively at work and it runs without a hitch