Fellow selfhoster, do you encrypt your drives where you put data to avoid privacy problems in case of theft? If yes, how? How much does that impact performances? I selfhost (amongst other services) NextCloud where I keep my pictures, medical staff, …in short, private stuff and I know that it’s pretty difficult that a thief would steal my server, buuut, you never know! 🤷🏻♂️
No. I run my servers on low quality shit and I expect them to break any time. Never had to perform a data recovery but if I need, I’ll thank myself I didn’t encrypt my pics
My home server has dropbear-initramfs installed so that after reboot I can access the LUKS decryption prompt over SSH. The one LUKS partition contains a btrfs filesystem with both rootfs and home as subvolumes. For all the other drives attached to that system, I use ZFS native encryption with a dataset that decrypts with a keyfile from that rootfs and I have backups of an encrypted copy of that keyfile.
I don’t think there’s a substantial performance impact but I’ve never bothered benchmarking.
I want to, but haven’t found the time to make a strategy on how to move over the data. It would take a bunch of shuffling as all drives are in use. The next problem is decrypting at boot and securely storing the decryption key - if I choose to use a decryption key at all. Maybe it’ll be a usb key that I have to plug into the server when starting it, or I have to setup decryption of the system over SSH, but that means automated restarts are… difficult.
I use separate disks for data storage and my OS. That way a headless system can boot and all the services like SSH can become available, and I can decrypt the data drives remotely.
When there’s an unexpected reboot I can still get into my system and decrypt remotely which is nice. I can also move the data storage disks to another system without too much hassle.
I did have to make sure some services were fault tolerant if an encrypted volume was unavailable when the OS booted. An example of this might be torrenting software, I needed to make sure the temporary storage was on an encrypted volume. The software had a sane fault mode when the final storage location was unavailable, but freaked out for some reason when the temp storage was missing.
Once set up the whole thing is pretty easy to manage.
I’m pretty sure I didn’t mess with systemd, though that would probably be the right way to handle it.
I was able to update a runtime config so if any storage wasn’t available it just halted the service. Then I created a short script I’d invoke manually which decrypted the luks drives and brought the dependent services up. I also added monitoring to alert me when the drives weren’t available for whatever reason.
Anyone who says yes is either a professional in a field already requiring it (is aware of how to do it and what it means), retired (has unlimited time to tinker), or is Edward Snowden. For the average person, you don’t need to encrypt your disks.
Well, since I’ve discovered that with AES-NI it doesn’t impact performances, I don’t see why not do it. I’ve had a look at a couple of guides and it doesn’t seem to be so difficult
Why? If you store the key in your password manager shouldn’t be a problem to mount the drive on another PC, decrypt it and save data. Or am I missing something?
On linux, you’re probably using LUKS. That has a header with the keys at the beginning of each encrypted volume. If those keys (or key if you only have one) is corrupted and you don’t have a backup of that, you’re fucked.
The next problem is that data recovery tools mostly don’t support decryption. They scan regions or the entire drive for recognizable things like partition headers, partition tables, file types, etc. if those are encrypted, well…
If you are able to decrypt a partition, then it might work as it will show up like any other device in /dev/mapper/ and you could do recovery /dev/mapper/HDD. However, I have no idea what data corruption does to encryption algorithms. If one part of what is being decrypted is faulty, what does that do to the entire thing?
This mostly comes from a lack of knowledge on my part. IIRC encryption depends on hashsums -> if you change what’s being decrypted/encrypted, the entire hashsum is incorrect and thus all the data shouldn’t be able to be decrypted. But I might be wrong - I’ll gladly be wrong on this.
On linux, you’re probably using LUKS. That has a header with the keys at the beginning of each encrypted volume. If those keys (or key if you only have one) is corrupted and you don’t have a backup of that, you’re fucked.
I got it, thanks! I will rely on SnapRaid form redundancy and on backups on multiple devices/locations.
The way you recover data from a totally dead drive is use a program that scans every byte and looks for structures in the data that look like files e.g. a jpeg will have a header followed by some blocks of content. In an encrypted drive everything looks like random data.
Even if you have the key, you can’t begin searching through the data until it’s decrypted, and the kind of error that makes it so your drive won’t mount normally is likely to get in the way of decrypting normally as well.
Yup and negligible. If I’m forced to contend with a windows environment bitlocker is utilized.
I also utilize a ram disk in a windows os. Imdisk in windows. I migrate temp files and logs into the ram disk. It saves on disk writes and increases privacy.
If pretty straightforward to encrypt if utilizing Linux right from install time.
As for my server I too utilize nextcloud. However, the nextcloud data is on a zfs dataset. This dataset is encrypted.
I did this by installing nextcloud from docker running within a proxmox container. That proxmox lxc container has the nextcloud dataset passed into it.
I did this by installing nextcloud from docker running within a proxmox container. That proxmox lxc container has the nextcloud dataset passed into it.
That’s almost what I’m doing (I’m using a VM in Proxmox where I install all my Docker containers). Right now I’m thinking about encrypt only the data volume (a NFS share from Proxmos host) since all the sensible data will be there.
If someone raids my house I have bigger fish to fry. Sure, but if it’s “free”, why not do it? My main worry was about performances, but since I’ve read that with AES-NI it doesn’t impact that much and since it seems not to be that complicated (let’s hope! 😁).
In addition to “encryption at rest”, also consider that your devices might be exploited over the internet, so attackers may be able to access the decrypted state that way. To guard against that, you may wish to encrypt certain documents with an additional password, even if they are sitting on an encrypted file system.
Recall that within a month, the widely SSH was exploited and a backdoor added to every machine. I had upgraded to that SSH version. I didn’t run an SSH server on that box, but it goes to show that even those who take precautions can end up exploited!
It’s defense in depth. If I encrypt a rarely used file, capturing my keystrokes will eventually work, but it might be weeks or months before I return to decrypt that file. In the meantime, I might have realized I was hacked and restore the system.
I encrypt about everything. Laptop, server, backups, external hdds that are just for me. (Only thing I don’t encrypt is a VPS. It’s hosted on somebody else’s hardware and they’d be able to break the encryption anyways if they wanted.)
I just put LUKS on it before formatting a filesystem. For the OS I use the good old approach with LUKS and a LVM inside.
I mean if you don’t encrypt the backups, the encrytion of the system is kind of meaningless, isn’t it?
Add comment