Cifra un VPS con LUKS

El cifrado de disco completo responde una pregunta y la responde por completo: ¿qué pasa cuando otra persona termina teniendo el disco mientras está apagado? En infraestructura alquilada eso no es hipotético. Los discos fallan y vuelven al proveedor. Los nodos se retiran y su almacenamiento se revende. Los volúmenes se clonan durante una investigación, o salen de un edificio en una caja.

• Cubierto. Un disco apagado, una imagen offline de tu volumen, una unidad devuelta en garantía, un nodo retirado, un archivo de snapshot copiado. En cada caso el atacante tiene el texto cifrado y una cabecera, y sin una frase de contraseña ahí termina la historia.
• No cubierto: una máquina en marcha. En el momento en que el volumen está abierto, la clave está en la memoria del kernel y el sistema de archivos queda a la vista de cualquier cosa con acceso root.
• No cubierto: tu tráfico. Los bytes que viajan por la red son problema de TLS y de WireGuard. LUKS nunca los ve.
• No cubierto: una cuenta root comprometida. Un intruso que ya está dentro lee tus archivos a través del mismo punto de montaje que tú. Para eso está el endurecimiento, y los dos controles no son intercambiables.

La lista es corta a propósito. El cifrado en reposo es un control barato y de alto valor con un alcance delimitado con precisión, y casi toda la decepción que la gente reporta con él viene de haber esperado calladamente que también cubriera las otras tres líneas.

Cuando tu volumen cifrado está abierto, la clave está en la RAM de la máquina invitada — y en cualquier VPS, en cualquier lugar, esa RAM vive en una máquina que el operador controla físicamente. Un hipervisor puede leer la memoria del invitado. Esto no es un fallo de LUKS, ni de KVM, ni de este proveedor en particular; es lo que significa alquilar un ordenador, y cualquier proveedor que te diga lo contrario está describiendo un producto que no existe.

Así que las cuentas son claras: el cifrado en reposo lleva el ataque offline a lo imposible y deja el ataque online exactamente donde estaba. Una unidad que sale del rack se vuelve inútil. Un servidor en marcha está tan expuesto como lo estaba ayer. Las dos mitades de esa frase son ciertas a la vez, y una guía que solo te cuenta la primera mitad no te está haciendo ningún favor.

Lo que mueve la segunda aguja es un conjunto distinto de controles, y se suman al cifrado en lugar de sustituirlo. No hay nada registrado que revelar, porque aquí el registro es sin KYC — un correo electrónico para la entrega de credenciales y nada más. El pago se liquida on-chain en lugar de a través de un banco. Y la jurisdicción en la que se encuentra la máquina decide qué órdenes judiciales tienen algún poder aquí. Nuestro desglose honesto de lo que oculta un VPS pagado en cripto repasa el resto, y la entrada sobre los Fourteen Eyes cubre el lado del intercambio de inteligencia. Leído como una capa entre varias, LUKS tiene un valor excelente. Leído como un escudo contra tu propio proveedor, es un malentendido.

Esto puede tomar dos formas, y la elección va de riesgo, no de fortaleza.

• Un volumen de datos cifrado. Un contenedor LUKS junto al sistema operativo. Todo lo que importa — bases de datos, correo, claves, subidas, copias de seguridad — vive dentro de él; el sistema operativo en sí queda sin cifrar. Diez minutos de trabajo, ningún riesgo de arranque y reversible en cualquier momento. Esto es lo que debería montar la mayoría de los lectores, y es lo que hacen los pasos de más abajo.
• Un sistema de archivos raíz cifrado. Todo queda dentro, incluidos los logs, las listas de paquetes y ese historial de la shell que habías olvidado. Estrictamente más fuerte, y realmente más difícil de aplicar en una máquina que ya está en marcha.

Vale la pena explicar el motivo de esa dificultad porque ningún tutorial lo hace nunca: no puedes cifrar un sistema de archivos que está montado en lectura-escritura ahora mismo y sirviendo tu propia sesión SSH. Los dos métodos reales — reducir y copiar, o cryptsetup reencrypt en el mismo sitio — necesitan la raíz desconectada. En una máquina con consola fuera de banda, arrancas un instalador y es rutinario. En un VPS sin consola, primero tienes que volcar el sistema en marcha a un disco RAM, y si algo de eso sale mal la máquina no vuelve y el único camino de recuperación es una reinstalación, que borra el disco.

Así que: monta hoy el volumen de datos, pon en él todo lo que importa, y trata la raíz cifrada como una decisión que se toma en el momento del despliegue, en una máquina que todavía no tiene nada que perder. La última sección cubre esa vía, incluyendo dropbear-initramfs para escribir la frase de contraseña por SSH durante el arranque.

No mucho, y eso es parte de por qué merece la pena hacerlo.

• Un plan. El cifrado no añade ningún requisito de RAM y casi ninguno de CPU. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) es suficiente; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) es el tamaño cómodo si la máquina también ejecuta un servicio de verdad. El único número que importa es el disco, porque tu volumen cifrado sale de ahí.
• Debian 12 o 13 de la biblioteca de plantillas, o Ubuntu LTS — los comandos de abajo tienen sabor Debian y los nombres de los paquetes cambian en otros sitios. El despliegue tarda alrededor de un minuto, y la virtualización KVM completa significa un kernel de verdad con los módulos dm-crypt presentes, no un contenedor tomado prestado de otro.
• Diez minutos de endurecimiento básico primero. El cifrado en una máquina que todavía acepta inicio de sesión con contraseña es una cerradura en una puerta sin marco.
• Una frase de contraseña que no hayas usado en ningún otro sitio, generada en lugar de inventada, y guardada en algún lugar que sobreviva a que pierdas esta máquina. No hay recuperación, ni restablecimiento, ni ticket de soporte que sirva de algo.
• Un lugar fuera de la máquina para guardar la copia de seguridad de la cabecera. Las snapshots semanales están incluidas en todos los planes, pero una snapshot de un volumen cifrado sigue estando cifrada — útil para revertir, inútil si la frase de contraseña ha desaparecido.

La ubicación no cambia nada de esto, así que elige según precio o jurisdicción: Ámsterdam, París, Bucarest y Sofía están al precio base, mientras que Zúrich, Reikiavik, Estocolmo y Kuala Lumpur llevan un multiplicador.

LUKS2 mantiene hasta 32 keyslots. Cada uno guarda una copia de la misma clave maestra, envuelta con una frase de contraseña distinta, por lo que puedes añadir una segunda frase de contraseña sin volver a cifrar nada:

cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1

Dos frases de contraseña desde el principio es lo correcto por defecto: una que uses, otra apuntada y guardada en otro sitio. Perder el único acceso a un volumen por una errata en un gestor de contraseñas es, con diferencia, la forma más común en que la gente pierde datos de LUKS, muy por delante de cualquier cosa que haga un adversario.

Ahora, la trampa. Una copia de seguridad de la cabecera hecha antes de rotar una frase de contraseña sigue abriendo el volumen con la frase de contraseña antigua. Los keyslots viven en la cabecera, así que una copia antigua de la cabecera es una copia antigua de los keyslots — la clave maestra de debajo nunca cambió. Si rotas porque una frase de contraseña puede haberse filtrado, tienes que destruir cada copia de la cabecera hecha antes de la rotación y tomar una nueva. De lo contrario, la rotación no ha logrado nada salvo hacerte sentir mejor.

Ese mismo hecho hace que las copias de la cabecera sean sensibles por derecho propio: ese archivo de 16 MB, junto con cualquier frase de contraseña que haya conocido alguna vez, basta para descifrar el volumen. Guárdala donde guardarías la frase de contraseña, no donde guardas tus snapshots.

cryptsetup benchmark te dice la verdad para tu vCPU concreta en unos quince segundos. En cualquier CPU con AES-NI — es decir, en cualquier procesador de servidor x86-64 de la última década — espera varios gigabytes por segundo con aes-xts, cómodamente más rápido que el NVMe que hay debajo. El sobrecoste práctico en cargas de trabajo reales es un porcentaje bajo de un solo dígito, y es de CPU, no de latencia.

Dos opciones de cryptsetup importan en almacenamiento rápido, y solo en almacenamiento rápido:

cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
  --allow-discards open /dev/disk/by-partlabel/secure secure

Los flags de workqueue evitan las colas internas de dm-crypt y entregan la E/S directamente al dispositivo. En un disco mecánico no cambian nada; en NVMe RAID10 eliminan un cuello de botella real con una cola de profundidad alta. Añádelos a la línea de opciones de crypttab como no-read-workqueue,no-write-workqueue para que sean permanentes.

--allow-discards es la que tiene una contrapartida. Deja pasar TRIM hasta el NVMe, lo que mantiene el rendimiento de escritura con el tiempo — y también revela a quien tenga el disco apagado qué bloques están en uso y cuáles están libres. Es una fuga de información real, aunque modesta: expone aproximadamente cuán lleno está el volumen y puede insinuar la estructura del sistema de archivos. En un servidor de propósito general, acepta el rendimiento. Si el contenido del volumen es del tipo en el que su tamaño es sensible, deja los discards desactivados.

Si quieres tenerlo todo cifrado, hazlo en una máquina que todavía no tenga nada — despliega, convierte y luego construye. La conversión en sí es estándar: reduce el sistema de archivos raíz mientras está desconectado, crea un contenedor LUKS2 en el espacio liberado, copia el sistema con rsync -aHAX, apunta /etc/fstab y /etc/crypttab al dispositivo mapper, y luego update-initramfs -u -k all y reinstala GRUB. Lo que convierte esto en un problema propio de un VPS sin consola son las palabras mientras está desconectado: llegar hasta ahí sin consola significa primero volcar el sistema en marcha a una raíz en RAM, y ese es el paso que termina en una reinstalación cuando sale mal.

Lo que hace utilizable una raíz cifrada en una máquina remota es dropbear-initramfs — un servidor SSH de unos 200 KB incrustado en la imagen de arranque, escuchando mientras el kernel espera la frase de contraseña:

apt install dropbear-initramfs cryptsetup-initramfs

# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys

echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
  >> /etc/dropbear/initramfs/dropbear.conf

echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k all

Después haces ssh -p 2222 root@your-ip durante el arranque, y el comando forzado cryptroot-unlock pide la frase de contraseña. Hay tres cosas que vale la pena saber antes de confiar en esto. El initramfs tiene su propia clave de host, así que tu cliente avisará de una discrepancia en el puerto 2222 — eso es lo esperado, y la razón para darle un puerto dedicado. Esa clave de host y tu authorized_keys están en una partición de arranque sin cifrar, legible por cualquiera que tenga el disco, así que usa una clave de desbloqueo que no sirva para nada más. Y -s desactiva el inicio de sesión con contraseña en el initramfs, lo cual no es opcional.

El otro detalle que muerde en los planes pequeños es el mismo del paso tres, y aquí muerde con más fuerza. El initramfs se ejecuta antes de que la mayor parte de tu RAM esté disponible para nada cómodo, así que una cabecera formateada con un coste de memoria de Argon2id alto puede no llegar a desbloquearse en la misma máquina que la creó. Formatea con --pbkdf-memory limitado, y prueba el reinicio mientras todavía no tienes nada que perder.

Muy poco, que es justo la cuestión. Un volumen LUKS abierto es un dispositivo de bloques normal; fsck, rsync, df y tu herramienta de copias de seguridad se comportan exactamente igual que antes. Las actualizaciones del kernel no se ven afectadas porque dm-crypt está integrado en el árbol del kernel. Ampliar el volumen tras subir de plan son dos comandos — cryptsetup resize y después el redimensionado propio del sistema de archivos — y no necesita volver a cifrar nada.

Vale la pena adquirir tres hábitos. Ensaya el reinicio con regularidad, en lugar de descubrir a las tres de la madrugada que una frase de contraseña que nunca apuntaste es la única copia que existe. Mantén las copias de seguridad cifradas de forma independiente — restic o borg hacia un destino externo, que es un control separado del volumen y sobrevive a perder la máquina por completo; el complemento de copia de seguridad externa diaria cuesta $2.00/mo si prefieres no montarlo tú mismo. Y cierra el volumen antes de dejar de ocuparte de la máquina: ejecutar cryptsetup close secure antes de un apagado planeado, una migración o una reinstalación hace que la clave salga de la memoria antes de que el disco deje de ser tuyo.

En cuanto a la política, no hay nada que negociar. Tienes root completo en un invitado KVM y lo que hagas con la capa de bloques es asunto tuyo; cifrar tu propio volumen es administración de sistemas ordinaria, no un caso límite. La política de uso aceptable trata sobre la conducta — el suelo innegociable es nada de CSAM y nada de terrorismo — y no tiene nada que decir sobre dm-crypt. Lo que sí cambia el cifrado es la forma de un hipotético mal día: un volumen apagado que sale de este edificio es ruido, y eso vale tus diez minutos.