Full-disk encryption on a server you do not control

Every hardening checklist closes with the same line, and ours does too: encrypt the volume. It is good advice that is almost never explained, so people either skip it or expect it to do things it cannot. On a machine sitting in a rack you have never seen, that gap is worth closing.

What it actually defends

Disk encryption protects data at rest, and at rest means something narrower than most people picture: the machine is powered off, or the storage has left the machine. Inside that window it is close to absolute.

• A disk seized while the server is down, or pulled from a rack after it has been.
• A drive that fails, gets swapped under warranty, and walks out of the building with your data still legible on it.
• A volume decommissioned and handed to the next customer before anyone remembers to wipe it properly.
• Provider snapshots of an encrypted volume, which are ciphertext and stay ciphertext wherever they get copied to.

What it does not defend

While the server runs, the key sits in memory, because that is the only way the filesystem can be read at all. Anyone who gets root on the running machine reads plaintext. So does anyone able to dump the memory of the virtual machine from the layer underneath it, and on rented hardware that layer belongs to the provider.

That is the honest limit of the technique, and no marketing page should be allowed to blur it. Encryption raises the cost of a cold disk enormously and does almost nothing about a warm one.

The shape that works on a rented machine

1. 01Encrypt before there is dataSet up LUKS on an empty volume. Converting a populated one is possible, but the earlier plaintext lingers in blocks nothing overwrites.
2. 02Leave the root filesystem alone if you canA LUKS container on a second volume, unlocked after boot, is far simpler to operate and covers the data that actually matters.
3. 03Keep the passphrase off the machineYou type it, or something elsewhere pipes it in over an authenticated channel. Nothing on the server should be capable of opening the server.
4. 04Cover swap and temporary filesA database page swapped out to a plaintext partition is still a database page. Encrypted swap and a covered temp directory close that leak.
5. 05Test the unlock path deliberatelyReboot on purpose, at a moment you chose, and confirm you can open the volume. Finding out during an incident is how people lose data they encrypted correctly.

Unlocking a machine you cannot walk up to

Encrypt the root filesystem and the machine halts at boot, waiting for a passphrase nobody is standing there to type. The usual answer on Linux is dropbear-initramfs, a very small SSH server running inside the early boot image: you connect to it, unlock the volume, and the boot resumes. It carries its own host key and its own authorised key, and it is the piece people forget to test.

A detached LUKS header is the other option worth knowing. The header carrying the key slots lives somewhere other than the disk it belongs to, so what remains on the server is a volume indistinguishable from random data. It is genuinely strong and genuinely unforgiving: lose the header and the contents are gone.

The trade you are making

An encrypted root means an unattended reboot leaves the service down until a human turns up. Kernel updates, host maintenance and power events all become manual. Some operators want precisely that; others find out during an outage nobody scheduled. Choose which failure you prefer while you are building it, not afterwards.

Performance is rarely the reason to hesitate. Any processor of the last decade does AES in hardware, and the overhead disappears into the noise for ordinary workloads.

Where we sit in this

We hold an email address and a coin balance, and if you encrypt a volume properly we do not hold the key to it either. That is deliberate, and the privacy page says so plainly: what a valid order can reach here is an address, a ledger and, at most, a block device we cannot open. Encryption is the part of that sentence you control, and the only part that does not require trusting us.

It travels, too. A volume whose contents were never exposed to the machine underneath makes leaving a provider in a hurry a calmer exercise than it usually is.

Published by NoDMCAVPS, an offshore host that files automated DMCA notices instead of forwarding them. What we still remove is listed in the acceptable use policy.