Cifrado de disco completo en VPS: LUKS y desbloqueo remoto

Qué puede ver realmente tu proveedor

Empecemos por la física antes que por la política, porque una política puede cambiar y la física no. En una máquina virtual, la imagen de disco vive en un hardware que otra persona montó en un rack. Si esa imagen no está cifrada, puede leerla cualquiera que termine teniendo el almacenamiento en sus manos: un operador con acceso al hipervisor, un técnico que sustituye un NVMe averiado en un par RAID-1, quien reciba finalmente esa unidad cuando se retire de servicio y —en el caso que en realidad le interesa a todo el mundo— cualquiera que se presente con una orden vinculante de un tribunal con jurisdicción sobre la máquina. Nada de esto requiere mala fe ni una puerta trasera. Un volumen sin cifrar es simplemente un archivo, y los archivos se pueden copiar.

La segunda capa es la memoria. Nuestros planes de VPS son de virtualización completa KVM, así que ejecutas tu propio kernel en lugar de compartir uno, pero el hipervisor sigue siendo el dueño de la RAM que te asigna, y cualquier hipervisor puede, técnicamente, inspeccionar una máquina invitada. La tercera capa es todo lo que nunca llega a tocar el disco: el tráfico que sale por tu interfaz de red, los metadatos que emite tu aplicación, el DNS que resuelves. En el lado de la cuenta retenemos muy poco, por diseño: un hash argon2id de la contraseña, tu saldo y su libro de movimientos, las especificaciones del pedido y los logs de acceso rotados a los 14 días, sin nombre, dirección, número de teléfono ni tarjeta en ninguna parte, tal como se detalla en la página de la política no-KYC. No retener nada sobre ti es una garantía distinta de ser incapaz de leer tu disco, y solo una de esas dos cosas depende únicamente de ti hacerla cumplir.

Qué arregla el cifrado de disco completo, y qué no

El cifrado de disco completo es un control para los datos en reposo. Cubre exactamente los escenarios anteriores en los que un volumen cambia de manos mientras la máquina está apagada o la copia se extrae fuera de línea: una unidad retirada de servicio o devuelta en RMA, un disco clonado en imagen, un volumen clonado desde la capa de almacenamiento, una instantánea en frío tomada sin que te enteres. En todos esos casos, un contenedor LUKS cifrado es un bloque opaco, y quien lo tenga en su poder necesita una frase de contraseña que solo existió jamás en tu cabeza o en tu portátil. Esa es una frontera real e infranqueable, y es la mejora individual más grande que la mayoría de la gente puede aplicar a un servidor alquilado.

Es igual de importante ser franco sobre la otra mitad. Un servidor en marcha tiene la clave en la RAM —eso es lo que permite que tus propios procesos lean el sistema de archivos—, así que el cifrado no hace nada contra un compromiso de root en caliente, un proceso hostil dentro de la máquina invitada, un volcado de memoria tomado con la máquina encendida, o un hipervisor que inspeccione esa memoria. No cifra lo que sale por el puerto de red, y no ayuda si tu aplicación escribe secretos en un log que luego envías a otra parte. Si tu modelo de amenazas excluye genuinamente la introspección del hipervisor, la respuesta honesta no es un cifrado mejor: es el hardware dedicado desde $66.00/mes, donde no hay ningún hipervisor por encima de ti. Para todo lo que quede por debajo de eso, el cifrado en reposo junto con un proveedor que retiene casi nada cubre los casos realistas —los términos que entran en juego aquí están definidos en el glosario.

¿Volumen de datos cifrado, o raíz cifrada?

Hay dos diseños y cada uno encaja en una situación distinta. El primero es un volumen de datos cifrado: el sistema operativo queda en claro y tú metes todo lo que importa —el estado de tu aplicación, tu base de datos, tu almacén de documentos, tus claves— dentro de un contenedor LUKS montado en la ruta que elijas. Se puede instalar en una máquina que ya está en producción, nunca bloquea un reinicio, y protege el material que de verdad interesaría a alguien. Lo que deja legible es la forma del sistema: tu lista de paquetes, tus unidades systemd, tus vhosts de nginx, tu historial de shell, tus logs.

El segundo es una raíz cifrada, donde todo excepto una pequeña partición de arranque queda dentro del contenedor. Nada de la máquina es legible cuando está apagada, que es el resultado que la mayoría imagina cuando dice que quiere un servidor cifrado. El precio se paga en cada arranque: un reinicio se detiene en seco en un prompt de frase de contraseña, en una consola que no puedes ver, hasta que le das una forma de pedírtela a distancia. Esa es la razón de ser de la siguiente sección. Como regla general: cifra la raíz cuando construyes una máquina desde cero y puedes probarla antes de que cargue con nada; cifra un volumen de datos cuando la máquina ya existe y el tiempo de inactividad sale caro. La conversión in situ de una raíz en marcha con cryptsetup reencrypt es posible en LUKS2, y no es algo que recomendaríamos hacer en un servidor de producción que no puedas reconstruir.

Desbloqueo remoto: un pequeño servidor SSH dentro del initramfs

El truco que hace viable una raíz cifrada en una máquina remota es dropbear-initramfs. El initramfs es el sistema en miniatura que el kernel descomprime antes de que exista la raíz real; como en un VPS KVM eres dueño del kernel, puedes meter dentro un demonio SSH muy pequeño. Al arrancar, la máquina levanta su interfaz de red, inicia ese demonio y espera. Te conectas, ejecutas un comando, la frase de contraseña desbloquea el contenedor, el arranque continúa hacia el sistema real y el pequeño demonio desaparece. Desde fuera parece un servidor que tarda treinta segundos más y necesita una acción deliberada para volver.

Casi todo el dolor lo causan dos detalles. El primero es que el servidor SSH del initramfs tiene su propia clave de host, distinta de la que presenta el sistema en marcha en la misma dirección, así que si lo dejas en el puerto 22 tu cliente rechazará la segunda conexión por discrepancia de clave de host cada vez, sin excepción. Dale un puerto aparte y un archivo known_hosts aparte y el problema desaparece. El segundo es el tiempo de espera: el demonio no debería quedarse ahí para siempre si estás durmiendo, pero tampoco debería rendirse antes de que puedas llegar a una terminal. Cinco minutos es un valor por defecto razonable. Restringe la clave para que no pueda hacer nada salvo desbloquear, y trata la dirección de ese proceso de escucha de arranque como algo que no publicas: el mismo instinto que recorre mantener tu nombre fuera de un servidor.

Slots de clave, cabeceras y el fallo con el que todo el mundo tropieza

Un contenedor LUKS2 no cifra tus datos con tu frase de contraseña. Cifra una clave maestra con tu frase de contraseña, guarda esa copia envuelta en un slot de clave dentro de la cabecera, y cifra el volumen con la clave maestra. Vale la pena interiorizar la consecuencia: hay varios slots, así que puedes inscribir una segunda frase de contraseña o un archivo de claves sin volver a cifrar ni un byte, y puedes revocar uno sin tocar los demás. La otra consecuencia es más afilada: la cabecera es los datos. Sobrescribe los primeros megabytes de ese volumen y todos los slots desaparecen a la vez, junto con cualquier posibilidad de recuperación. Respalda la cabecera, fuera de la máquina, en el momento en que crees el contenedor, y otra vez cada vez que añadas o quites una clave.

Luego está el modo de fallo que este proveedor deja inusualmente al desnudo. Aquí el registro es un nombre de usuario y una contraseña con ocho códigos de recuperación y ningún correo electrónico en ningún punto del proceso, precisamente para que no haya identidad que filtrar, lo que también significa que no existe ninguna vía de recuperación basada en identidad para nada, la tuya incluida. Nadie puede responder por ti, y nadie tiene una copia de tu frase de contraseña. Así que construye la máquina cifrada mientras todavía tengas una en funcionamiento, reiníciala de forma deliberada y desbloquéala en remoto antes de que cargue con datos, guarda la copia de seguridad de la cabecera y un segundo slot de clave en algún lugar al que sigas teniendo acceso después de perder tu portátil, y asegúrate de que tu plan de recuperación termine en redesplegar y restaurar desde una copia de seguridad en lugar de en que otra persona te teclee una frase de contraseña.

Las fugas en los márgenes: swap, instantáneas y copias de seguridad

Una raíz cifrada con una partición swap en claro es como poner un candado en la puerta y dejar la ventana abierta: el kernel paginará lo que sea, incluido material de clave, hacia ese swap. La solución es regenerar la clave del swap desde /dev/urandom en cada arranque, algo que no cuesta nada porque el swap nunca necesita sobrevivir a un reinicio. Dale el mismo tratamiento a /tmp con tmpfs donde puedas, desactiva la hibernación en un servidor, y piensa en discard antes de activarlo: pasar TRIM a la capa de almacenamiento es bueno para la unidad, pero filtra el patrón de qué bloques están en uso, lo cual es una divulgación pequeña pero real de cuán lleno está tu volumen y en qué zonas.

Las copias de seguridad merecen su propia reflexión, porque una copia de seguridad es una copia de tus datos en algún lugar al que no llega el cifrado que acabas de configurar. Nuestro complemento de copias de seguridad cifradas diarias guarda instantáneas fuera del host en los planes de VPS, y las instantáneas manuales —que residen en el mismo host— son una comodidad de reversión y no una copia de seguridad, como señalan las preguntas frecuentes. Si consideras que el proveedor entra dentro de tu modelo de amenazas, cifra en el lado del cliente antes de que nada salga de la máquina, con una clave que no esté almacenada en ella. Ese único hábito también hace portátil la vía de restauración: una copia de seguridad que solo tú puedes leer es una copia de seguridad que puedes restaurar en cualquier parte, incluido un plan de VPS distinto en una región distinta.

Dónde encaja el cifrado en un modelo de amenazas offshore

El cifrado es uno de tres controles que fallan de forma independiente, y precisamente por eso usar los tres no es paranoia, sino ingeniería ordinaria. El primero es lo que el proveedor sabe de ti: nada, cuando la cuenta es un nombre de usuario financiado por un saldo prepago en cripto desde $30.00, en cualquiera de 8 monedas y variantes de red que cubren 7 divisas, sin tarjeta ni documento en toda la cadena; ese es el tema de pagar el hosting de forma anónima. El segundo es qué ley se aplica, que la decide dónde está la máquina y no dónde estás tú, y se analiza región por región en qué ubicación offshore deberías elegir y desde el punto de vista legal en jurisdicciones de hosting offshore comparadas.

El tercero es qué queda legible en reposo, y ese depende solo de ti: ningún proveedor puede resolverlo en tu lugar, porque un proveedor que guarda tu clave no ha resuelto el problema que te preocupaba. Combínalos y cada uno cubre un fallo distinto: una fuga de identidad no expone el disco, una sorpresa jurisdiccional no entrega una frase de contraseña, y una unidad robada no dice tu nombre. Hay 6 regiones entre las que elegir en nuestras ubicaciones, con un VPS en línea en unos 15 min; en hardware dedicado, que se entrega en 2–12 h con credenciales IPMI, puedes ir todavía más lejos y arrancar tu propio instalador en lugar de confiar del todo en una imagen suministrada por el proveedor.

Rendimiento, y las máquinas que no vale la pena cifrar

La cuestión del rendimiento la resuelve sobre todo el hardware. Cada VPS de la flota corre sobre AMD EPYC 9354 con AES-NI, así que aes-xts-plain64 mueve datos a varios gigabytes por segundo y por núcleo, muy por encima de lo que cualquier carga de trabajo individual le pide a un array NVMe RAID-1. Ejecuta cryptsetup benchmark en tu propia máquina y confía en esos números en lugar de en una entrada de blog, incluida la nuestra. El sobrecoste que de verdad se puede medir aparece en la latencia y no en el throughput, y solo en cargas de trabajo que ya están limitadas por fsync: una base de datos relacional con muchas escrituras, un buzón de correo con mucho tráfico, una cola que confirma cada mensaje. Para un servidor web, un backend de aplicación, un extremo VPN o un almacén de archivos, el coste se redondea a cero.

La pregunta más útil es qué máquinas no merecen esa pieza móvil de más. Una máquina que no guarda ningún estado privado no gana nada con el cifrado y sí un reinicio que no puede completarse de forma desatendida: un mirror estático público, un nodo de caché, un relé intermedio de Tor cuyo único secreto es una clave de identidad que podrías rotar en un minuto. Cifra donde haya algo que perder: la base de datos, el almacén de correo, el destino de las copias de seguridad, la máquina que termina tu túnel WireGuard y guarda sus claves privadas. Decide máquina por máquina, no por flota entera, y anota cuál es cuál: el operador dentro de seis meses eres tú, con menos contexto y durmiendo peor.

Paso a paso

1. 01

   Decide qué estás protegiendo, y elige el diseño

   Escribe la única frase que importa: qué archivos harían daño si una copia de este volumen saliera del edificio. Si la respuesta es una base de datos y un directorio de claves, un volumen de datos cifrado basta, y conservas los reinicios desatendidos. Si la respuesta es toda la máquina cuenta una historia que preferiría que no contara, construye una raíz cifrada y acepta que cada arranque te necesitará a ti. No empieces a teclear nada hasta que esa frase exista.

2. 02

   Despliega un VPS nuevo y endurécelo antes que nada

   Despliega desde el panel —un VPS está en línea en unos 15 min— y haz primero el trabajo aburrido, en una máquina limpia, mientras un error todavía no cuesta nada. SSH solo con clave, un firewall de denegación por defecto, actualizaciones de seguridad desatendidas, y cryptsetup instalado.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   Crea el contenedor LUKS2 y pon un sistema de archivos dentro

   Para un volumen de datos, un contenedor respaldado por archivo es la opción menos invasiva y se comporta igual que una partición. Dimensiónalo según lo que va a contener, no según el disco. Elige una frase de contraseña que puedas escribir de memoria bajo presión: esta no es una contraseña que vayas a pegar desde un gestor en una máquina que todavía no ha arrancado.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   Inscribe una segunda clave y respalda la cabecera fuera de la máquina

   Un solo slot de clave está a un mal día de distancia de la pérdida total. Añade una segunda frase de contraseña o un archivo de claves, vuelca la cabecera a un archivo, y copia ese archivo a algún lugar fuera del servidor: un volumen cifrado en tu portátil, o un almacenamiento fuera de línea. Repite el volcado cada vez que cambies un slot; una copia de seguridad de la cabecera desactualizada puede resucitar una clave que creías haber revocado.

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   Para una raíz cifrada, instala el demonio SSH del initramfs

   Solo es relevante si la raíz en sí está cifrada. Pon tu clave pública donde el initramfs vaya a encontrarla, mueve el proceso de escucha fuera del puerto 22 para que nunca choque con la clave de host real, levanta la interfaz con DHCP y reconstruye. Las rutas cambiaron en Debian 12: allí es /etc/dropbear/initramfs/, y en Debian 11 es /etc/dropbear-initramfs/.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   Reinicia a propósito, mientras la máquina sigue vacía

   Este es el paso que la gente se salta y luego lamenta. Reinicia de forma deliberada, antes de que haya datos, y desbloquea por red exactamente como lo harías a las tres de la madrugada. Mantén el proceso de escucha de arranque en su propio archivo known_hosts para que su clave de host nunca entre en conflicto con la real. Si no vuelve, has perdido una máquina de prueba en lugar de una de producción.

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   Cierra los flancos y anota el plan de recuperación

   Regenera la clave del swap desde /dev/urandom para que nada de lo paginado sobreviva a un reinicio, mantén la hibernación desactivada, y cifra las copias de seguridad en el lado del cliente antes de que salgan de la máquina. Después escribe el manual de recuperación: dónde vive la copia de seguridad de la cabecera, qué slot es cuál, y la vía de redespliegue y restauración que seguirás cuando desbloquear no sea una opción. Un plan que no has escrito es un plan que no tienes.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256