Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / How to Use Linux Server Disk Encryption with LUKS
Transcript
- Lucas: You know, for all the time we spend talking about network security, firewall rules, and SSH hardening, there's this one gap that I think a lot of sysadmins quietly ignore until it's too late: disk encryption on the server itself. Luna: Right — because if someone gets physical access to the machine or walks off with the drives, all those fancy iptables rules don't do a thing. Lucas: Exactly. So today I want to walk through LUKS — Linux Unified Key Setup — the standard for full-disk encryption on Linux. And not just theory: I want to show a concrete setup for encrypting a secondary data drive on an Ubuntu Server 22.04 LTS machine. Luna: Okay, I like that. Why secondary drive and not the root filesystem? Lucas: Two reasons. First, encrypting root adds complexity with initramfs and remote unlock — doable, but we can cover that in a follow-up. Second, on many servers, the sensitive data lives on separate volumes: databases, application data, backups. So encrypting those is a high-impact, lower-friction starting point. Luna: Makes sense. So what do you actually need? I'm guessing cryptsetup and a kernel module? Lucas: Yeah, cryptsetup is the user-space tool, and the kernel module is dm-crypt. On Ubuntu they're both included by default, but you may want to install cryptsetup if it's not there: sudo apt install cryptsetup. After that, you need a block device — say, /dev/sdb — and you're ready to go. Luna: Hold on — before we encrypt, don't we need to consider wiping the drive? If it's not a fresh disk, there might be leftover data. Lucas: Great catch. For a truly clean start, you can overwrite the entire device with random data. That also makes it harder for an attacker to identify which sectors contain encrypted data versus unused space. I'd do: sudo dd if=/dev/urandom of=/dev/sdb bs=1M status=progress. That can take a while on large drives, but it's worth it. Luna: Right. And after that, we initialize the LUKS partition. Lucas: Yes. The command is: sudo cryptsetup luksFormat /dev/sdb. You'll be prompted for a passphrase — choose something strong, because this is your master key. This writes the LUKS header to the device, which includes encryption parameters like cipher, key size, and hash algorithm. Luna: What are the defaults? I've heard about aes xts these days. Lucas: The default cipher on modern cryptsetup is aes-xts-plain64, with a 512-bit key — that's actually two 256-bit keys: one for encryption, one for the XTS tweak. The hash is SHA-256. Those are solid for server use. You can customize them, but for most cases the defaults are fine. Luna: Okay, so after luksFormat, we have an encrypted container. How do we actually use it? Lucas: You open it with cryptsetup open, which maps it to a device mapper name. For example: sudo cryptsetup open /dev/sdb data_volume. This will ask for your passphrase, and then creates /dev/mapper/data_volume. That block device behaves like a regular unencrypted disk. Luna: So then we can create a filesystem on it and mount it normally. Lucas: Exactly. sudo mkfs.ext4 /dev/mapper/data_volume, then sudo mount /dev/mapper/data_volume /mnt/data. And you're done — all writes are encrypted on the fly. Luna: But what about automatic mounting at boot? You don't want to be typing a passphrase every time the server reboots. Lucas: Right, and that's where key management gets interesting. You have a few options. One is to store a keyfile on a separate encrypted root filesystem or on a removable USB drive. Another is to use a TPM — Trusted Platform Module — if your server hardware supports it. With a TPM, you can seal the decryption key to the system's firmware state, so only that specific machine with the same boot configuration can unlock the volume. Luna: I've heard of that approach — it's called tpm backed LUKS or something similar. How do you set it up? Lucas: There's a tool called systemd-cryptenroll that integrates with systemd. The command looks like: sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/sdb. This enrolls a tpm generated key into LUKS, alongside your existing passphrase. Then you can add a crypttab entry to auto-unlock at boot. Luna: That's neat. But what if you lose the TPM or the motherboard fails? Lucas: That's why you always keep a backup passphrase — the one you set during luksFormat. You can also add a keyfile stored in a safe place as a fallback. Never rely solely on one unlock method for production servers. Luna: And what about backing up the LUKS header? I've heard that if the header gets corrupted, the data is gone even if the passphrase is correct. Lucas: That's absolutely true. The LUKS header contains the encrypted master key and configuration. If it's overwritten or damaged, you can't recover the data. So backing up the header is critical. The command is: sudo cryptsetup luksHeaderBackup /dev/sdb --header backup file /path/to/header-backup.img. Store that backup securely — it's as sensitive as the encryption key itself. Luna: So you'd want to keep it in a separate physical location, maybe encrypted itself. Lucas: Exactly. And you should test restoring it in a lab environment before you ever need it in production. Now, one other thing people worry about is performance. Luna: Yeah, does encryption slow things down noticeably on modern server hardware? Lucas: With aes ni — the hardware acceleration built into most modern CPUs — the overhead is very small. For sequential reads and writes, we're talking single-digit percentage slowdowns. For random I/O, it's a bit more, but still manageable. I've seen benchmarks where 4K random write throughput drops maybe 10-15 percent. For most server workloads, that's acceptable. Luna: But what about database workloads? They're often I/O bound already. Lucas: Good question. For databases, you might want to consider filesystem-level encryption instead of block-level — LUKS sits below the filesystem, so the database engine doesn't know about it. But with aes ni, even database performance is usually fine. I'd recommend running your own benchmarks with your specific workload before deciding. Luna: Let's circle back to key management for a second. You mentioned keyfiles. How would that work in practice? Lucas: You create a keyfile — say, 256 random bytes — and add it as a LUKS key slot. Then you can place that keyfile on an encrypted root volume or NFS share that's unlocked earlier in the boot process. The crypttab entry would reference that keyfile path. The risk is that if someone gains access to that keyfile, they can unlock the volume — so you need to protect it with tight permissions, typically 0400 owned by root. Luna: And you can have multiple key slots for different scenarios, right? Lucas: Yes, LUKS2 supports up to 32 key slots. So you can have a passphrase for emergency recovery, a TPM slot for automatic boot, and a keyfile for remote unlock via SSH. It's flexible. Luna: That reminds me — what about remote servers in a colo or cloud? You can't exactly walk in and type a passphrase. Lucas: For remote servers, you often use a network-bound disk encryption approach. One method is to use a remote unlock service like Dropbear SSH in an initramfs. You can SSH in during early boot to provide the passphrase. Another is to use a keyfile stored on an encrypted volume that's itself unlocked via a separate process. But the cleanest solution is TPM, if your cloud provider supports it — some newer dedicated servers offer TPM 2.0. Luna: And if you're in a major cloud like AWS or Azure, do they offer something like that? Lucas: AWS Nitro instances have a built-in hardware security module that can provide key material. But that's a different ecosystem. For self-managed LUKS, you're typically on bare metal or a VM where you control the boot process. Luna: Okay, let's talk about a gotcha: what happens if you lose all keys? Is there any backdoor? Lucas: No backdoor. That's the whole point — encryption is only as strong as the key management. If you lose the passphrase and all keyfiles, the data is unrecoverable. So you need a solid backup plan for key material, separate from the data backup. Luna: And what about resizing an encrypted volume? That's something that comes up with growing databases. Lucas: LUKS supports online resizing. You first resize the underlying block device if it's a logical volume or partition, then run cryptsetup resize on the mapped device, and finally resize the filesystem. The exact steps depend on your filesystem, but it's doable. Luna: I think we've covered the core workflow. Let's step back: why should a sysadmin prioritize this over, say, another firewall rule? Lucas: Because disk encryption protects data at rest. If a server is stolen, decommissioned without proper wipe, or if drives are returned under RMA, encryption is your last line of defense. Firewalls don't help when someone has physical possession of the platters. Luna: And it's often a compliance requirement — PCI DSS, HIPAA, GDPR all expect encryption at rest. Lucas: Exactly. So it's not just paranoia; it's a standard practice. I'd argue every server that stores sensitive data should have LUKS on at least the data volumes. Luna: You know, we cover a lot of technical topics here, and one thing I appreciate is that we don't have ads breaking up the flow. It really helps keep the focus on the actual content. Lucas: Yeah, that's intentional. We deliberately don't run ads on these shows. If you want to support that choice and help us keep it that way, the link is buy me a coffee dot com slash fexingo. No pressure, just an option for those who find value in what we do. Luna: Absolutely. And that support goes directly into research and production time. Now, back to disk encryption — any final tips for someone setting this up for the first time? Lucas: Start on a test VM. Practice the full cycle: encrypt, open, create filesystem, mount, write data, unmount, close. Then practice recovery: restore header, open with backup passphrase. Get comfortable before you touch production data. And always keep multiple backup copies of your LUKS header and key material. Luna: Sound advice. And I'd add: document everything. I've seen too many servers where the only person who knew the passphrase left the company. Lucas: That's a classic disaster. So put it in a password manager or a physical safe — just make sure it's accessible when needed. Alright, that's a solid walkthrough for LUKS disk encryption on Linux servers. Luna: Next time maybe we tackle full root filesystem encryption with remote unlock. Lucas: That would be a great follow-up. Until then, keep your data encrypted and your keys safe.