LUKS Disk Encryption in Practice: Linux Full-Disk Encryption Configuration Guide

LUKS is the Linux standard disk-encryption spec. Full ops path: cryptsetup install, encrypted partition create, auto-mount, backup and recovery. Put a disk-encryption barrier around sensitive server data.

Use Cases

LUKS (Linux Unified Key Setup) disk encryption fits these cases: first, **physical servers and colo**—if the box is stolen or a disk is pulled, the encrypted volume cannot be read; second, **cloud instance data disks**—encrypt partitions that hold databases, backups, logs, and other sensitive data; third, **compliance**—MLPS, GDPR, and similar regimes require encryption at rest. LUKS encrypts the entire block device. The filesystem above it is fully transparent. Applications need no changes.

Prerequisites

• Linux distro (Debian/Ubuntu here; CentOS commands are essentially the same)
• root or sudo
• Dedicated disk or partition to encrypt (prefer a whole new disk, e.g. /dev/sdb)
• Important data already backed up: encryption wipes the target device

Internals

LUKS is a disk-encryption spec on the dm-crypt kernel module. It uses a **key slot** mechanism: the device header holds 8 key slots; each slot can store one key; any valid slot unlocks the device. The volume key is derived from the passphrase via PBKDF2. Device-level encryption uses AES-256-XTS and similar. Versus raw dm-crypt, LUKS provides a standard header, cross-tool compatibility, multiple passphrases, passphrase changes, and key backup. Production default.

Procedure

Step 1: Install cryptsetup

# Debian/Ubuntu
sudo apt update && sudo apt install -y cryptsetup

# CentOS/RHEL
sudo yum install -y cryptsetup

# Check version
cryptsetup --version

Step 2: LUKS-format the disk

# Example: /dev/sdb. LUKS format wipes the disk. Confirm the device name.
sudo cryptsetup luksFormat /dev/sdb

# Specify cipher and key size (AES-256-XTS recommended)
sudo cryptsetup luksFormat /dev/sdb --cipher aes-xts-plain64 --key-size 256

When prompted, type uppercase `YES` twice to confirm, then set the unlock passphrase. Passphrase strength is the security floor. Use 16+ mixed characters. Wrong device name means unrecoverable data loss.

Step 3: Unlock and create a filesystem

# Unlock the encrypted device, map as /dev/mapper/sdb_crypt
sudo cryptsetup luksOpen /dev/sdb sdb_crypt

# Inspect the mapped device
ls -l /dev/mapper/sdb_crypt

# Create an ext4 filesystem
sudo mkfs.ext4 /dev/mapper/sdb_crypt

`luksOpen` prompts for the unlock passphrase. On success it creates the mapped device `sdb_crypt` under `/dev/mapper/`. Reads and writes to that mapper device are transparently encrypted/decrypted.

Step 4: Mount and verify

# Create mount point and mount
sudo mkdir -p /mnt/encrypted
sudo mount /dev/mapper/sdb_crypt /mnt/encrypted

# Verify mount
df -h | grep encrypted

# Read/write test
sudo dd if=/dev/urandom of=/mnt/encrypted/test.bin bs=1M count=100
sudo sha256sum /mnt/encrypted/test.bin

Step 5: Unlock at boot

Production usually needs auto-mount at boot. Create a key file and add it to a key slot:

# Generate key file (mode must be 0400)
sudo dd if=/dev/urandom of=/etc/luks-keys/sdb.key bs=512 count=8
sudo chmod 0400 /etc/luks-keys/sdb.key

# Add the key file to a LUKS key slot
sudo cryptsetup luksAddKey /dev/sdb /etc/luks-keys/sdb.key

Configure auto-unlock and mount. Edit `/etc/crypttab`:

# /etc/crypttab contents
sdb_crypt /dev/sdb /etc/luks-keys/sdb.key luks

Edit `/etc/fstab` and add the mount:

# /etc/fstab contents (mapper device, not /dev/sdb)
/dev/mapper/sdb_crypt /mnt/encrypted ext4 defaults 0 2

Update initramfs so it takes effect:

sudo update-initramfs -u

Note: if the key file lives on the same host as the disk, protection is only as strong as the host. High-security setups put the key file in TPM or a remote KMS.

Step 6: Back up the LUKS header

A damaged LUKS header permanently bricks unlock. Back it up:

# Back up header (only a few MB)
sudo cryptsetup luksHeaderBackup /dev/sdb --header-backup-file /backup/sdb-luks-header.bin

# Restore header
sudo cryptsetup luksHeaderRestore /dev/sdb --header-backup-file /backup/sdb-luks-header.bin

Verification

Confirm encryption is actually on:

• `cryptsetup luksDump /dev/sdb` — inspect key-slot state and cipher. Confirm `PBKDF2` and `AES-XTS` are correct
• After reboot, confirm `/mnt/encrypted` auto-mounts. `mount | grep encrypted` should show `/dev/mapper/sdb_crypt`
• Test a clean lock with `cryptsetup luksClose sdb_crypt`. While locked, `/dev/mapper/sdb_crypt` must disappear

FAQ

Q1: Forgot the LUKS unlock passphrase?

If another key slot still has a valid passphrase or key file, `luksOpen` then `luksChangeKey` to reset the slot. If every slot is lost, the data is gone. That is why you back up the LUKS header and keep a second key for important data. Store the admin key file offline.

Q2: How much performance do you lose after encryption?

Modern CPUs have AES-NI. Under AES-256-XTS, overhead is typically under 5%. Most workloads will not notice. If the CPU is old and lacks AES-NI, you can pick a lighter cipher than `aes-xts-plain64`, but security drops. Not recommended.

Q3: Can you move an encrypted disk to another server?

Yes. LUKS is hardware-agnostic. Install cryptsetup on the new host, `luksOpen`, mount, read. On migrate, import the key slot (or `luksAddKey` again) and confirm the kernel supports the cipher. If auto-unlock fails because initramfs was not updated, rerun `update-initramfs -u`.

Summary

LUKS disk encryption is the standard Linux encryption-at-rest path. Core flow: format, unlock, mkfs, mount, auto-unlock, header backup. Production checklist: back up data before encrypting; keep passphrase and key file in different places; take periodic offline LUKS header backups. Disk encryption does not replace access control. Combine with firewall, file permissions, and audit logs for defense in depth.