Problem

One of you server’s disks has developed a fault and needs replacing. Tossing the old disk into the trash risks exposing potentially sensitive data.

One solution is to give that disk to a commercial shredder. These companies will offer to physically destroy the disk, rendering it’s content unrecoverable (they usually literally shred the disk into thousands of tiny shards). This solution is typically okay providing you a) completely trust that the company will 100% certainly destroy the disk, and b) you’re happy paying the associated fees.

Being the paranoid type, even if I generally believe (a) I prefer to be certain no sensitive data leaves my control.

Solution

Good whole disk encryption. With you disk always encrypted even handing it to an external shredding service becomes stress free; if they truly shred the disk then you’re done, if they nefariously copy of hand that disk to bad actors, you’re still pretty secure (unless you’re up against state level opposition determined to access your data, but frankly it’s much easier to get into your systems using other means that spending huge amounts of resource decrypting well encrypted disks).

So, how to proceed?

The simplest solution on Linux is to use LUKS and DMCrypt block device encryption typically offered when installing the operating system.

I won’t detail the steps here as they’re fairly simple; choose ‘encrypt disk’ option during installation, this will encrypt the disk with a password of your choosing (make is a high entropy password, save this in your password manager).

Cool, My Disk is Safe but When I Reboot I have to Enter My Password. That Sucks!

This can be an issue when you cannot be physically present at the server’s console during a reboot (like a remote reboot at 3 a.m. :) ) or if the server reboots itself (e.g. during a maintenance cycle update).

To avoid this issue we provide a key file held on, for example, a USB memory stick we leave inserted into the server (I hope it’s obvious why the key file cannot be held on the drive itself!)

Now, when the server reboots the LUKS system will interrogate the key file and, assuming a match is made, the disk’s master key will be made available and the boot sequence can continue as normal. If the key file is not present (the USB is removed) then a prompt for the password will appear (this also provides a fail-safe against USB loss—so remember your password!).

Discussion

The disk encryption offered during installation will encrypt your primary partition (so not really whole disk, but sufficiently so for our purposes). Two other partitions are typically created during installation (assuming your doing a simple default install); swap and boot.

The swap partition has the potential to leak information. My preferred solution to this is to not have a swap partition (this means not using the default install on most Linux installers, but this is hardly a difficult partitioning change to grok). This is typically not a problem providing you do not run your server near to it’s memory limits. Other advantages to running without swap include:

1. Consistent server performance; this can be important for some applications (e.g. high performance database clusters).

2. Reduces damage to SSD; SSD are not suited to high read/write cycles and relying on swap regularly will eventually cause serious wear on your SSD, best to avoid this. (Often Cloud service providers will not allow, or at least ‘discourage’, swap for this very reason.)

The boot partition has little risk of data leak. It is a small and standardised means to bootstrap the kernel. You should never have any sensitive information in your boot partition. You might be thinking, but does this not open up the boot partition to being altered? Yes. And No. Sure, it could be altered but then any partition on the running system, regardless of its encryption status, can be modified by a suitably privileged user. To protect your boot partition you need to employ more sophisticated methods than simple encryption.

Is There an Overhead to Whole Disk Encryption?

Short answer, yes, of course. Longer answer, yes, but I’ll wager than in all but the most demanding IO bound circumstances you will not notice and effect.