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! 🤷🏻♂️
My Music, Movies and Shows, I dont consider them private/sensitive, as they aren’t illegal to possess or even download in my country. I would even donate my filled but corrupted drive to a repair guy, he can have the media if he can repair it.
Plex data, pi hole, and home assistant don’t contain anything meaningful. No credentials are stored in a form that can be reused.
The most sensitive is immich, which I’m more concerned about backups than I am someone might steal my nudes. Their online anyway.
Email is hosted off-site and I still have physical files for a lot of my documents. If someone stole hdds out of my server, they’d get a lot of Linux isos, pictures of cars, porn, tons of versioned software and games installers, etc.
Maybe my definition of sensitive is different than yours though.
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.
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
Absolutely yes, I do enctypt my drives so I don’t have to ever do that again. This isn’t as critical for SSDs but it’s still a good idea. Even if you keep the key stored on the same system, securely deleting a tiny file is way easier than a whole disk.
And it has other benefits. For example a dying disk. You can just throw that out. I once tried to wipe such a disk and it’s a chore. It makes weird clicking noises and slows down to the point where it’d take years to overwrite it. Occasionally the SATA controller resets etc. And it won’t succeed at overwriting stuff. Sure I could go to the garage, get the power tools, put the hdd into a vise and delete everything with a combination of hammer and drill… But it’s much more convenient to have it encrypted and not care.
Sure. It’s just effort. I have to go fetch the power tools, fetch the drills, if I want to do it correctly also mount a vise or go fetch a piece of scrap wood and some clamps… After that clean up and remove the metal chips from my apartment…
At work I’d additionally need 3 training courses to be allowed to operate the drill press and visit the workshop. The whole process is going to take half a year. And it’ll still not be certified that the information is now gone.
Somehow they don’t trust the software developers with operating heavy machinery 😆
Anyways, I think we’re moving away from the topic… At work I didn’t encrypt harddisks anyways. They just put the servers into a special area in the datacenter that has a fence and a separate lock.
At home I just encrypt stuff so I don’t have to remember what I put where and handle things differently. Of course everything depends on the specific scenario and threat model. I have a bit of stuff archived on my server that isn’t around anymore, could be a copyright violation. I also have my complete life stored there, documents, finances, emails of a decade, pictures, backups for family members, passwords for emergency access to things. Admin stuff and logfiles that I’m required by law (GDPR…) not to share. I also used to travel a lot with my laptop in the backpack and that can get stolen. At some point a long time ago I decided to encrypt my harddisks and stop worrying. Since at least 10 years there isn’t any speed penalty anymore and it takes like 20 seconds to set it up on Linux…
But I can also see why not everyone wants to do it this way.
I’m still in the planning stage of my home network (we’re redoing the whole place so I’m doing a proper network) and TrueNas will be at the centre of it. So far, I’m not considering encryption (my laptops have /home encrypted though).
I’m not sure what the risk of a Disney raid on my server is. It could be a real thing, or not. It really depends on many things.
However, all in all, the lack of a proper solution for a quick server wipe beyond the usual thermite load, is problematic.
Why don’t you consider encrypting your NAS, if I might ask? Inconvenience on boot? Because that’s one inconvenience I currently live with… After a power outage I have to fetch a keyboard and type in the password, since the mainboard doesn’t have remote-management and I’ve never set up an automatic way to transfer/fetch the encryption key…
In truth, I’m going to have to deal with a shitload of new stuff. I’m going with a Dell or Supermicro server (as in rackable server) with between 8 and 16 disks, so I’m also going to have to deal with new hardware (I suppose everyone kind of has to, since they’re not running their usual software). And of course, I’m also doing HomeAssistant stuff on top of that, with all the Zigbee (or whatever other proper protocols I can stick on MTQQ) stuff, or else where would the fun be.
It’s a good thing I’ve been managing Unix stuff for decades (not that it makes me feel any better about juggling a dozen new things at the same time).
Oh wow. Seems you live somewhere where electricity is a bit more affordable. I have an super efficient enterprise mainboard with an old Xeon. I get by with the 6 SATA-Ports for home use. I mean now that we have 12TB drives… I bought lots of RAM an I’m running several VMs, containers, Home Assistant and all sorts of stuff on that machine.
TPM solves a sigthly different threat model: if you dispose the hd or if someone takes it out from your computer it is fully encrypted and safe. But if someone steals your whole server it can start and decrypt the drive. So you have to trust you have good passwords and protection for each service you run. depending on what you want to protect for this is either great solution or sub optimal
TPM is a good way, Mine is setup to have encryption of / via TPM with luks so it can boot no issues, then actual sensitive data like the /home/my user is encrypted using my password and the backup system + fileserver is standard luks with password.
This setup allows for unassisted boot up of main systems (such as SSH) which let’s you sign in to manually unlock more sensative drives.
I remember this blog post (I cannot find right now) where the person split the decryption password in two: half stored on the server itself and half on a different http server. And there was an init script which downloaded the second half to decrypt the drive. There is a small window of time between when you realize that the server is stolen and when you take off the other half of the password where an attacker could decrypt your data. But if you want to protect from random thieves this should be safe enough as long as the two servers are in different locations and not likely to be stolen toghether.
How do you even encrypt a server so that it doesn’t require human intervention every time it goes down/restarts?
The only time my Server goes down, is when i manually reboot it. So waiting a minute or two, to ssh into it and entering the passphrase is no inconvenience.
I’m too lazy to look up the details. But you can have a small ssh server running as part of initrd. I think it’s dropbear. I log into that and unlock the root drive from there.
Of course that necessitates an unencrypted /boot/.
Did it on Debian and it was relatively easy to set up.
I‘m in the process of setting up a new NAS with Debian and disk encryption, and this is exactly what I’m struggling with. I’ve tried multiple guides for Dropbear but every time I try to SSH into the server to unlock it, I get “Permission denied”.
I don’t reboot my server that often. But I think I use a dedicated port and key for it. I don’t use them anywhere else. Maybe the key has to be a specific format for Dropbear.
Important is that you update your initramfs with the command after you edited the dropbear initramfs config and or you copied the key over.
For the client it is important to define 2 different known hosts files since the same host will have 2 different host keys, 1 when encrypted with dropbear, and 1 when operational with (usually) sshd.
Also you need to use root when you connect to your server to unlock it. No other user will work with the default setup.
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.
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.
This shouldn’t even be a question lol. Even if you aren’t worried about theft, encryption has a nice bonus: you don’t have to worry about secure erasing your drives when you want to get rid of them. I mean, sure it’s not that big of a deal to wipe a drive, but sometimes you’re unable to do so - for instance, the drive could fail and you may not be able to do the wipe. So you end up getting rid of the drive as-is, but an opportunist could get a hold of that drive and attempt to repair it and recover your data. Or maybe the drive fails, but it’s still under warranty and you want to RMA it - with encryption on, you don’t have to worry about some random accessing your data.
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.
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.
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! 😁).
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
I have two WebDAV shares, one unencrypted and one encrypted. The unencrypted one is for things that need to be read by other services, like legally obtained movies and tv shows. The encrypted one is for porn, mostly (also stuff like tax documents, legal contracts, etc).
Good question. I don’t have a clue either. It doesn’t contain any personal information. (Unless it’s self-made.) Usually isn’t unique. And nobody cares as there’s an abundance of porn available everywhere on the internet.
Add comment