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! 🤷🏻♂️
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.
If you’re getting rid of a (rusty) drive and it leaves your hands with the cool magnets and shiny frisbees still inside, you’re doing something wrong.
Dude just use a hammer
Yes of course, with dm-crypt (luks), very little as AES-NI is incredibly fast.
Do you insert the key/password manually every time (it’s a server, so not so many times, but could happen) you boot the server?
https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/
As mentioned in another comment I haven’t quite gotten it working but it should be possible to do this via SSH
Nope. This isn’t part of my threat model.
I don’t have sensitive data and stealing a drive would be inconvenient for a thief.
You don’t have sensitive data? Would you mind expanding on that a bit for me? Just curious how you like, live, and stuff.
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’m surprized as well, like I guess I would understand if it’s a no log DNS server but, what else wouldn’t have sensitive information.
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.
No,
There is all the backup of all my family pictures in the drives.
If something happens to me I want to make due that they will have access to it.
I keep my drives encrypted with a key currently hosted in my router hoping they wouldn’t steal that. I’m thinking of actually putting it to cloud so I can disable it remotely.
It was quite a ride to make everything work and I made a blog post explaining it so I remember what I did.
https://nowicki.io/self-hosting-lvm-raid1-with-key-over-ftp/
Interesting, thanks!
How do you even encrypt a server so that it doesn’t require human intervention every time it goes down/restarts?
Isn’t that what a TPM could be used for?
i dunno is it? how to set that up?
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”.
This answer here covers it quite nice imo.
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.
I was actually using my own user account instead of root, but now that you mention it… I’m not sure how that would even work so yeah that makes sense.
I did rebuild the initramfs after every change but did not manually copy the key file anywhere other than etc.
Will check out the link tomorrow. Thanks a lot for sharing!
Edit: tried again with root and it worked flawlessly :D
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.
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.
Files could be decrypted by the end user. The OS itself could remain unencrypted.
TPM, but it’s a pain in the ass and breaks a lot. The new version of Ubuntu should handle it better, but if you’re not on Ubuntu, that won’t help you.
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
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.
Use Clevis either with TPM or Tang (remote server) https://github.com/latchset/clevis
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.
Have you tried secure-erasing a disk?
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.
Have you tried secure-erasing a disk?
Once /dev/urandom is enough. Who cares if a state actor could theoretically recover your media library in an expensive lab.
Even that takes a while.
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.
You take the disk out, drill once through it (use a metal bit).
Done.
Takes a couple minutes.
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.
In an enterprise setting, it’s probably a bit of a hassle with everything having to follow some kind of process…
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.
Takes me about 2 seconds with a 5lb steel mallet.
Bold of you to assume sysadmins can wield a 5lb mallet. (I’m not completely sure what that is in real world weight, 2 ½ kg?).
Always, if nothing else it makes “wiping” them securely easier.
I use full disk encryption for every server (and other computers).
Encrypting your data drives is a must for everyone imho. Encrypting the OS is a must for me🤷♂️
My PC weighs 80+ lbs, live 8km from town, surrounded by farm land and there are only 3,400 in town and I live 30 min from a city of 40,000 and 40 min from another city of 70,000 and my internet is 20/10 mbps
What’s your point?
I think he is saying that his physical attack surface is very small since he is remote, so maybe he doesn’t bother?
Either way, encrypting drives is simply always good if you ever resell the computer or upgrade drives.
FreeAin’t no one stealing my shit, even via internet to upload 40tb would take 1 year 5 days at max speed in actuality it would be 1 year 8 months… Fuck I miss my 1.5G fibre connection…
I used to until I realized that I’ve got bigger threats to worry about.
And like someone else mentioned, if I have to do data recovery for some unknown reason I want to make sure the data’s not encrypted.
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?
Recovering data from a corrupted, encrypted drive is way trickier than from a simply corrupted drive, I imagine.
Why? What would be the problem?
P.s. Why did you link to the Anti Commercial-AI license?
Why? What would be the problem?
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 dorecovery /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.
I encrypt devices that are portable. If someone raids my house I have bigger fish to fry.
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! 😁).
It’s a relatively low performance hit and it benefits me when having to replace a failing/old disk. I can just toss the drive without having to erase the data first, that is as long as the key is a secure length.
Yes.
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.
No. If someone gets to my server that’ll be the least of my worries.
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!
The XZ vulnerability was stopped in its tracks and did not really affect the majority of systems.
I also have a hard time believing local file encryption can be that effective. All they need to do is capture your keystrokes.
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.
That’s why I use most of the services via Wireguard (except Nextcloud that is behind Cloudflare and MQTTs that’s completely exposed)
