Cifrar un disco VPS con LUKS

El cifrado no es un ajuste de privacidad de propósito general. Responde exactamente a una pregunta: ¿puede alguien leer estos bloques sin la clave? Todo lo demás —quién sabe que se alquiló el servidor, si el tráfico es atribuible a alguien, si un tribunal puede obligar a algo— pertenece a otro ámbito.

En un VPS, LUKS defiende de forma significativa frente a:

• Hardware dado de baja o averiado. Las unidades NVMe se sustituyen. El borrado seguro de un dispositivo averiado no siempre es posible: a veces está tan muerto que el controlador ya no acepta comandos, y aun así sale del rack.
• Una imagen fuera de línea. Un volumen copiado con el servidor apagado —durante una incautación, una migración, un error— es texto cifrado y sigue siendo texto cifrado.
• Copias de seguridad e instantáneas que viajan. Todo lo que sale de la máquina sale cifrado si se toma desde la capa de bloques que queda fuera de control del usuario, y debería cifrarse del lado del cliente si se toma desde una capa superior.
• Bloques residuales. Al destruir un servidor, los extents subyacentes acaban reutilizándose. El cifrado convierte esos restos en ruido en lugar de datos.

Lo que no hace es defender frente a una máquina en funcionamiento. Mientras el servidor está encendido, la clave maestra reside en la memoria del kernel, y cualquiera capaz de volcar esa memoria lee el disco sin importar la frase de contraseña. En infraestructura alquilada, eso significa el operador del hipervisor. Lo decimos en nuestro aviso de privacidad y lo repetimos aquí: ninguna función de cifrado de disco de ningún proveedor cambia esto, incluida la nuestra, y cualquier proveedor que afirme lo contrario está describiendo marketing, no criptografía.

Antes de tocar una terminal, conviene elegir el modelo. Difieren enormemente en el esfuerzo que requieren, y la mayoría de los casos necesita el primero.

1. Un volumen de datos cifrado. El sistema arranca con normalidad y sin cifrar; un único árbol de directorios —un maildir, una base de datos, un archivo— vive dentro de un contenedor LUKS que se abre a mano después de cada arranque. Diez minutos de trabajo, sin modo de rescate, sin riesgo de quedar fuera del sistema. Si lo que importa es un conjunto de datos concreto y no la máquina entera, aquí se puede parar: se obtiene la mayor parte del beneficio con casi ninguna de las fragilidades. Este es el patrón que recomendamos en la página del servidor de correo anónimo.

2. Un volumen raíz cifrado con desbloqueo remoto. Todo excepto /boot está cifrado, y cada arranque se detiene en el initramfs hasta conectarse por SSH y proporcionar la frase de contraseña. Este es el modelo que construye el resto de esta guía. Cuesta una hora la primera vez y un comando SSH por cada reinicio, y es el único modelo en el que los registros, la caché de paquetes, el historial de shell y el swap también quedan cubiertos: los lugares a los que se filtran datos sin que nadie lo haya decidido así.

3. Una raíz cifrada que se desbloquea sola contra un servidor de claves propio. Igual que el modelo 2, pero Clevis obtiene el material de desbloqueo de un servidor Tang situado en una máquina en otra jurisdicción, de modo que los reinicios quedan desatendidos. La contrapartida es precisa y merece entenderse: el servidor ahora puede descifrarse a sí mismo mientras el servidor de claves lo permita, lo que significa que el secreto se ha desplazado, no eliminado, pero a cambio se gana un interruptor de corte remoto. Se trata más adelante.

Muchos proveedores anuncian el “cifrado en reposo” como una simple casilla que se marca. Merece la pena precisar qué suele significar esa frase, porque detrás de ella se esconden dos cosas muy distintas.

El cifrado con una clave que guarda el proveedor protege frente a una unidad robada y nada más. Si el proveedor puede arrancar el servidor sin pedir nada a nadie, el proveedor puede descifrar el servidor sin pedir nada a nadie, y lo mismo puede hacer cualquiera que tenga poder para obligar al proveedor. Es un control real contra el robo y puramente decorativo frente a un proceso legal.

El cifrado con una clave que guarda el propio cliente es la versión que realmente importa, y por construcción impide el reinicio desatendido. Eso no es un defecto que haya que corregir con ingeniería: es la propiedad que hace el trabajo.

Nosotros ofrecemos únicamente la segunda opción, sin configurar, y dejamos que sea el cliente quien decida. Lo que sí conservamos es más limitado y está documentado: las contraseñas de root de los servidores se almacenan cifradas con AES-256-CBC a nivel de fila, no conservamos registros de flujo ni capturas de paquetes, y se publica periódicamente un canario de alerta legal firmado. Nada de eso sustituye a una clave propia: es la parte de la que sí se nos puede responsabilizar mientras tanto.

Los valores predeterminados son buenos. Merece la pena cambiar dos de ellos.

Cifrador. aes-xts-plain64 con una clave de 512 bits es el valor predeterminado y la respuesta correcta: los 512 bits son en realidad dos claves de 256 bits, así que esto es AES-256 en modo XTS, y todas las CPU que utilizamos tienen AES-NI. En una máquina sin aceleración AES sería preferible xchacha20,aes-adiantum-plain64, pero ese no es nuestro hardware, y probablemente tampoco el de la mayoría de los lectores.

Derivación de clave. LUKS2 usa Argon2id de forma predeterminada, que es deliberadamente exigente en memoria. cryptsetup evalúa la máquina en el momento del formateo y elige un coste de memoria a partir de la RAM que puede ver, y ahí está la trampa que provoca la mayoría de los informes de “mi servidor cifrado no arranca”: el initramfs dispone de menos memoria utilizable que el sistema en ejecución, y si el volumen se formateó en un entorno de rescate con más RAM de la que tiene el plan de destino, el desbloqueo puede fallar o ser interrumpido durante el arranque. Fíjelo explícitamente. Un GiB de memoria para Argon2 es un coste serio para un atacante y perfectamente asumible en un S1 con 4 GB:

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory se indica en KiB, así que 1048576 equivale a 1 GiB. Conviene comprobar después qué quedó realmente registrado en la cabecera con cryptsetup luksDump /dev/vda2: la sección de la ranura de clave muestra la memoria y el número de iteraciones que se usarán, y leerlo una vez sale más barato que un arranque fallido.

La frase de contraseña. Argon2 gana tiempo frente a una frase de contraseña débil, pero no la salva. Utilice una frase diceware de al menos seis palabras. Es el único secreto de todo el sistema, y ninguna función de derivación de clave compensa una mala elección.

Un arranque de Linux con una raíz cifrada tiene un problema del huevo y la gallina: el kernel y el initramfs deben cargarse antes de que nada pueda pedir una frase de contraseña, y ambos residen en el disco que se quiere desbloquear. La respuesta estándar es una pequeña partición /boot sin cifrar que contiene el kernel, el initramfs y el gestor de arranque. Todo lo demás va dentro de LUKS.

El initramfs se detiene entonces y pide la frase de contraseña. En un portátil, se escribe directamente. En un servidor a tres mil kilómetros de distancia, hace falta una de estas dos cosas:

• La consola. Todos los servidores del panel tienen una consola noVNC, y funciona, pero las pulsaciones de teclado atraviesan nuestra infraestructura, que es precisamente la parte que la clave debería excluir. Válido para una recuperación puntual, incorrecto como rutina.
• Un servidor SSH dentro del initramfs. dropbear-initramfs ocupa unos 200 KB, activa la red, escucha en el puerto que se elija, acepta una de las claves públicas configuradas y lleva directamente al aviso de desbloqueo. La frase de contraseña queda cifrada de extremo a extremo desde el portátil hasta el initramfs. Esta es la respuesta correcta.

Hay dos detalles que suelen sorprender. El Dropbear del initramfs tiene su propia clave de host, así que su huella digital difiere de la del demonio SSH habitual: eso es lo esperado, no un ataque de intermediario, y merece su propio archivo known_hosts en lugar del hábito de escribir yes sin más. Y el nombre de la interfaz debe ser el correcto: las NIC virtio en Debian 13 suelen aparecer como ens3 o enp1s0, no como eth0. Conviene comprobarlo con ip -br link antes de escribir la configuración, porque equivocarse significa un initramfs sin red y un viaje obligado a la consola.

Si la máquina debe volver a arrancar por sí sola —tras una actualización del kernel, un reinicio del host, un corte de energía—, escribir una frase de contraseña no es viable. Clevis vincula una ranura de clave de LUKS a una política externa, y Tang es un pequeño servidor de intercambio de claves que implementa la más simple y útil de esas políticas.

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

Durante el arranque, el initramfs realiza un intercambio McCallum-Relyea con Tang y recupera la clave sin que el servidor Tang llegue a conocerla ni a ver la frase de contraseña en ningún momento. Merece la pena precisar las propiedades de este esquema:

• El VPS se descifra a sí mismo solo mientras puede alcanzar a Tang. Si se apaga Tang, o se rotan sus claves, el siguiente arranque se detiene en seco. Eso es un auténtico interruptor de corte remoto: inusual y útil.
• Tang no debería estar expuesto a la internet pública. Conviene alcanzarlo a través de WireGuard o como servicio onion de Tor; la parte del túnel se cubre en la guía de WireGuard.
• Coloque Tang en una jurisdicción distinta de la de los datos. Nuestras páginas de jurisdicción existen precisamente para este tipo de separación.
• Mantenga una frase de contraseña en otra ranura de clave. Clevis es una capa de comodidad, no la única vía de entrada.

Conviene entender bien qué se ha construido: una máquina desatendida guarda su propia clave por delegación, de modo que un adversario que incaute el VPS mientras está en funcionamiento, o que pueda alcanzar el servidor Tang, obtiene los datos. Eso es un debilitamiento real frente a una frase de contraseña que solo existe en la mente de una persona. Conviene elegir este modelo cuando la disponibilidad importa más que el último grado de confidencialidad, y no por defecto.

Una raíz cifrada cubre la mayor parte de la superficie, pero hay algunas rutas que escriben fuera de ella o que sobreviven a ella.

• Swap. Cualquier cosa que esté en RAM puede paginarse a disco: claves, cuerpos de mensajes, búferes descifrados. Si el swap vive dentro del volumen cifrado como un archivo de intercambio, queda cubierto. Una partición de swap independiente no lo está, a menos que se añada a /etc/crypttab con una clave aleatoria que cambie en cada arranque: cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256. En un VPS, el archivo de intercambio es más sencillo y no hay ningún motivo para preferir la partición.
• /tmp. Móntelo como tmpfs (tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0) para que no llegue a tocar el disco en ningún momento. También es más rápido.
• Hibernación. Escribe toda la RAM, incluida la clave maestra, en el dispositivo de swap. No la active. Viene desactivada de forma predeterminada en nuestras imágenes.
• El /boot sin cifrar. Los núcleos, las imágenes de initramfs y la configuración de GRUB son legibles y, lo que es más importante, modificables por cualquiera con acceso fuera de línea al disco. LUKS aporta confidencialidad, no integridad del arranque. Si el modelo de amenazas incluye a alguien manipulando el gestor de arranque, el cifrado por sí solo no lo detectará: conviene registrar los hashes de /boot después de cada actualización del kernel y comprobarlos desde fuera, o asumir esa brecha de forma consciente.
• Instantáneas y volúmenes antiguos ya existentes. Cifrar hoy no hace nada por una imagen tomada ayer. Si el servidor llegó a funcionar sin cifrar con datos que importaban, hay que tratar esos datos como expuestos y rotar todo lo que derive de ellos.

La sobrecarga es lo bastante pequeña como para no ser determinante en la decisión, pero no es nula. Mida antes de especular:

cryptsetup benchmark

En nuestros nodos EPYC, aes-xts con una clave de 512 bits rinde en el orden de varios gigabytes por segundo y por núcleo, muy por encima de lo que un único volumen NVMe llegará a exigir. El coste que realmente se nota es la latencia y la CPU en escrituras aleatorias pequeñas, no el rendimiento agregado.

Hay dos parámetros de LUKS2 que importan en NVMe, donde las colas de trabajo de dm-crypt del kernel añaden latencia en lugar de eliminarla. Hay que fijarlos y hacer que queden guardados en la cabecera:

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

El tercer parámetro, --allow-discards, deja pasar TRIM hacia el dispositivo subyacente. Mantiene baja la amplificación de escritura a lo largo de la vida del volumen, a costa de revelar qué bloques están sin usar, lo cual filtra el tamaño y la forma aproximados de los datos a cualquiera que lea el dispositivo en bruto. Actívelo en un servidor de propósito general; déjelo desactivado si el mero hecho de que un volumen esté ocupado al 3 % ya es sensible. No existe una respuesta universalmente correcta, solo una decisión que conviene tomar de forma deliberada.

La cabecera de LUKS ocupa aproximadamente 16 MB al principio de la partición y contiene las copias cifradas de la clave maestra. Dañarla —un dd mal escrito, una herramienta de particionado que reescribe “amablemente” el inicio del dispositivo— hace desaparecer cada byte que hay detrás. No existe ningún servicio de recuperación. Nosotros tampoco tenemos una copia.

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

Dos cosas sobre esa copia de seguridad. Primero, es tan sensible como el propio disco: contiene ranuras de clave, así que una cabecera antigua restaurada después de cambiar la frase de contraseña aceptará sin problema la frase anterior. Consérvela con el mismo cuidado que la frase de contraseña, y destruya las copias obsoletas al rotarla. Segundo, LUKS2 ofrece 32 ranuras de clave: conviene usar al menos dos, dejando la de repuesto como una frase larga y aleatoria guardada en un lugar distinto de donde está la de uso diario. El fallo típico que esto evita es tan aburrido como frecuente: se rota la frase de contraseña, se escribe mal dos veces de forma idéntica, y el error se descubre en el siguiente arranque en lugar de en el siguiente inicio de sesión.

Conviene tener también una vía de vuelta. El modo de rescate arranca el servidor desde nuestra ISO con las claves SSH ya inyectadas y el volumen cifrado intacto, lo que permite ejecutar cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt y reparar un crypttab roto o un initramfs defectuoso sin perder los datos. Conviene probarlo una vez, deliberadamente, mientras todo funciona bien.

Lo más útil que puede hacer una guía como esta es marcar sus propios límites.

• No protege un servidor en funcionamiento. La clave maestra permanece en la memoria del kernel desde el desbloqueo hasta el apagado. El acceso a la memoria a nivel de hipervisor lo derrota. El cifrado de memoria —AMD SEV-SNP y equivalentes— es la única tecnología que cambia esto de forma sustancial, y hoy no la ofrecemos; un proveedor que afirme que su VM en ejecución es opaca a esto sin usar SEV está equivocado o mintiendo.
• No proporciona anonimato. Un disco cifrado en Zürich sigue teniendo una IP, un rastro de facturación y una sesión SSH que empezó en algún sitio. Ese es un problema distinto, y hemos descrito cómo suele salir mal en los errores que desanonimizan.
• No cambia lo que puede ordenar un tribunal. La jurisdicción rige la coacción; el cifrado rige la legibilidad. En algunas jurisdicciones se puede ordenar a una persona que revele personalmente una frase de contraseña. Nuestra guía sobre procesos legales explica qué acciones tomamos y cuáles no.
• No sobrevive a una frase de contraseña perdida. Es así por diseño, y merece la pena repetirlo, porque el ticket de soporte pidiendo ayuda para esto llega más o menos una vez al mes, y la respuesta es siempre la misma.
• No autentica la cadena de arranque. Confidencialidad no es lo mismo que integridad. /boot es legible y modificable fuera de línea.

Lo que sí hace es eliminar toda una categoría de exposición: todo lo que le ocurre a un disco cuando no está en funcionamiento, que es la mayor parte de lo que le ocurre a los discos. Eso ya vale la hora invertida. Combínelo con un registro sin KYC, el pago con Monero y una jurisdicción elegida a propósito, y cada capa cubre un fallo distinto. Ninguna de ellas las cubre todas.