Cifrar un servidor root alquilado con LUKS

Contenedores LUKS, archivos loop, copias de la cabecera: cifrado para un servidor alquilado, sin mitos. Cortes de entrada desde $4.80/mes con el prepago anual.

Qué protege LUKS realmente (y qué no protegerá nunca)

La imaginación popular envuelve el cifrado alrededor de la máquina en marcha, como un blindaje. La realidad es más estrecha: LUKS cubre los estados que nadie está mirando. Un disco extraído durante una baja, una imagen archivada en almacenamiento frío, un montaje de rescate hecho mientras dormías: cada uno muestra solo texto cifrado sin tu frase de contraseña. Mientras tanto, el sistema arrancado, con las claves residentes en memoria, es totalmente transparente para quien tenga su root.

Mecánicamente hay un solo secreto maestro, envuelto de varias maneras. En el formateo se genera una clave de volumen aleatoria —512 bits con el cifrado aes-xts por defecto— y se sella dentro de los keyslots de la cabecera, una ranura por frase de contraseña, exactamente como especifica el proyecto cryptsetup. Al abrir se desenvuelve esa clave y se alimenta dm-crypt, que descifra los bloques al vuelo. Los bytes almacenados nunca cambian; lo que cambia es su legibilidad, y esa diferencia la tienes tú.

El envoltorio es inspeccionable. cryptsetup luksDump /dev/vdb imprime el cifrado, la geometría de la cabecera y una ranura por credencial: la prueba exacta de qué separa tus datos del mundo. Esa inspeccionabilidad corta en ambos sentidos: la cabecera es también el único punto de fallo irrecuperable, y por eso media página orbita a su alrededor. La fuerza de la frase de contraseña importa, pero la supervivencia de la cabecera importa más, y las dos copias de seguridad deben guardarse en lugares distintos.

El estado en marcha es donde la confianza se desborda. Una máquina arrancada debe mantener la clave desenvuelta en memoria o no descifra nada; la consecuencia: el root lee texto en claro, el operador del host lee texto en claro, y una fuga de memoria entrega la clave. Creer que un cifrado protege un servidor en funcionamiento es el error que esta página no deja de corregir: el cifrado responde por el almacenamiento en reposo, nunca por las sesiones en curso.

Reformulado como frontera: los discos extraídos, las imágenes archivadas y los montajes de rescate quedan dentro de la protección; el administrador del host en marcha queda fuera. Ser dueño del hardware pone a ese administrador bajo tu contrato. Alquilar una porción KVM añade un lugar más donde la clave reside —la ruta de arranque— y ese lugar merece una sección propia.

La ruta de arranque alquilada, descrita sin barniz

Una porción alquilada arranca con código ajeno: el hipervisor carga el kernel y un initramfs, y solo entonces se ejecuta algo tuyo. El cifrado con petición temprana funciona igualmente por esa ruta, pero fíjate en la implicación: tu frase de contraseña se introduce a través de una infraestructura que no administras, así que el secreto tocó el lado del host del arranque, aunque fuera un instante. Los modelos honestos cuentan ese contacto en vez de redondearlo a cero.

Dos diseños lo resuelven. Primero: dejar el volumen de arranque en claro y sellar dentro el conjunto sensible —un contenedor LUKS en un volumen adicional o en un archivo de imagen de disco— que se desbloquea por SSH tras cada reinicio con una clave que solo tú posees; los reinicios, entonces, te esperan a ti. Segundo: ser dueño del hierro, compilar tu propio initrd y mantener IPMI como consola de emergencia para cuando la petición de desbloqueo se porte mal.

Existe un camino intermedio: un initramfs que ejecuta un pequeño demonio SSH, al estilo dropbear, de modo que la frase de contraseña viaja por la red; y el RFC 4253 es la razón por la que ese canal merece confianza. Pero valora el precio con honestidad: el secreto sigue descansando después en la memoria del host, en silicio que no gobiernas. Vence al robo de discos; no vence a la plataforma.

El error es promediar las verdades: ver aparecer la petición de desbloqueo y concluir que el proveedor «no ve nada». Él entregó el gestor de arranque. Él aloja la memoria que guarda tu clave. Él puede hacer una imagen de la máquina que acabas de bloquear. Nada de eso vacía de valor el ejercicio: simplemente eleva al rango de opción honesta por defecto el diseño de contenedor, que mantiene al proveedor fuera de la ruta del secreto tras el arranque.

El diseño uno no exige heroicidades: un volumen adicional, una frase de contraseña, un ritual tras cada reinicio. La siguiente sección lo construye paso a paso, y la posterior lo reduce a un archivo de imagen de disco para máquinas con un solo disco. Ambas acaban en el mismo destino: una copia de la cabecera guardada muy lejos.

Diseño uno: un contenedor sellado junto al sistema operativo

La receta por defecto es deliberadamente aburrida. Deja el sistema operativo donde está; reúne el conjunto sensible —claves de firma, colas de correo, volcados de base de datos, cada .env que alguien juró que era temporal— en un segundo volumen que permanece cerrado hasta que llegas tú. Si ese conjunto cabe en la mitad de un NVMe de 80 GB, coge el plan de entrada a $6/mes de lista —$4.80/mes con el prepago de 12 meses— y quédate ahí.

Cuatro comandos hacen el trabajo. cryptsetup luksFormat /dev/vdb escribe la cabecera en el volumen en bruto; cryptsetup open /dev/vdb vault expone /dev/mapper/vault; mkfs.ext4 construye un sistema de archivos dentro; mount lo aparca donde prefieras. Copia los datos con rsync, verifica por muestreo y solo entonces retira los originales. Después, el volumen se lee como ruido para todo lo que carezca de tu frase de contraseña.

Vincula la apertura a una persona, nunca al arranque. El atajo tentador —una entrada en crypttab más un montaje en fstab— o se atasca en cada reinicio esperando una frase que ninguna consola puede aceptar, o se desenvuelve con material de clave almacenado sin cifrar en el mismo disco, lo cual es teatro de seguridad con pasos extra. O abres el volumen tú mismo cada vez, o dejas que una unidad espere tu entrada por un canal autenticado; crypttab(5) documenta las opciones, con noauto a la cabeza.

Los informes de incidentes remiten a dos tropiezos. Primero, el atajo de la clave en disco: degrada silenciosamente el contenedor a mero adorno. Segundo, la propia cabecera: un formateo descuidado o un script que roza los primeros megabytes, y una frase de contraseña perfectamente recordada no desbloquea nada, porque el registro de envoltura desapareció. Trata los primeros 16 MiB de ese dispositivo como estructurales, porque lo son.

Un volumen, una credencial, un ritual: la mayoría de los conjuntos sensibles no piden más. Las máquinas que no ofrecen segundo volumen reciben el mismo diseño plegado en un archivo que finge ser un disco, que es el asunto de la siguiente sección. La penalización de rendimiento allí es menor de lo que dice el rumor, y la ganancia de gestión es mayor.

Diseño dos: una imagen de disco que se comporta como un disco

¿Sin volumen adicional? Linux entregará un archivo ordinario al subsistema loop y dejará que LUKS lo trate como dispositivo de bloques. El conjunto sellado vive entonces dentro de un artefacto móvil: cópialo, envíalo, almacénalo en el extranjero: texto cifrado durante todo el trayecto. Para archivos de claves y colas, esta suele ser la forma más manejable que admite el cifrado, y media receta se traslada sin cambios desde el caso del volumen.

Secuencia: truncate -s 40G /srv/vault.img reserva espacio como archivo disperso, losetup -f --show lo adjunta e imprime el dispositivo loop elegido, y después el formateo y la apertura proceden exactamente igual que con un volumen — losetup(8) documenta las opciones implicadas. Desde el mount en adelante nada cambia: los mismos rituales, la misma disciplina de cabecera. El nombre también importa: mantén la imagen lejos de directorios volátiles, porque las aplicaciones que registran mucho llenarán con gusto el mismo sistema de archivos.

Las copias de seguridad se reducen a semántica de archivos. El trabajo nocturno se convierte en detener, copiar, arrancar —y la copia es texto cifrado, bienvenida en cualquier parte. Una instantánea de la plataforma tomada a mitad de sesión solo captura bloques sellados, porque la clave de envoltura nunca toca el disco. Esa herencia del diseño de LUKS es precisamente por lo que los contenedores en modo imagen prosperan en plataformas amigas de las instantáneas. Advertencia: la clave de conveniencia que reside en tu directorio personal no goza de la misma inmunidad, como explica una sección posterior.

Tres tropiezos causan la mayoría de los incidentes con imágenes. Tamaño: ls informa 40G mientras du -h muestra 2 GiB realmente asignados: planifica con du y no entren en pánico con ninguno. Transferencia: los archivadores sin --sparse inflan el archivo a su tamaño nominal en el destino. Readjunción: los reinicios descartan la asignación loop, así que los scripts deben redescubrir el dispositivo en lugar de codificar su número a fuego.

Dominada la variante de archivo, se disuelve en rutina, que es justo el momento en que la disciplina de cabecera empieza a erosionarse. Lee dos veces la siguiente sección: un contenedor cuya cabecera no tiene copia en otro sitio es un testamento firmado que nadie puede protolar, y nada más adelante en esta página puede revertir esa pérdida en concreto.

Dieciséis megabytes que lo deciden todo

Inversión de prioridades, dicha sin rodeos: el componente insustituible de un volumen sellado no son los datos; es la cabecera. La cabecera por defecto de LUKS2, de 16 MiB, lleva los keyslots que envuelven la clave del volumen; bórrala y la frase de contraseña correcta no desenvuelve absolutamente nada. Los bloques de datos sobreviven como ruido puro. Haz copia del envoltorio primero y del contenido segundo; el orden inverso no salva nada que te importe.

Un comando ejecuta el rescate: cryptsetup luksHeaderBackup con un archivo de destino, luego una suma de verificación, luego el traslado a otro hierro: otro disco, otro continente, cualquier lugar salvo el volumen del que se habla. Verifica tu copia apuntando luksDump contra ella; la distribución de keyslots impresa debe coincidir con la del dispositivo en vivo. Una copia no leída es folclore, y las FAQ del proyecto martillan justo ese punto.

Ensaya la recuperación mientras nada duele: un archivo de prueba, una cabecera nueva escrita sobre él, tu copia restaurada encima con luksHeaderRestore, y después confirmar que una apertura tiene éxito. Dos minutos compran la certeza de que los bytes que custodias son los bytes correctos. Atiende también a la regla de caducidad: los cambios de credencial reescriben los keyslots, así que cada edición de la frase de contraseña invalida las copias anteriores; vuelve a capturar la cabecera tras cada cambio que hagas.

Las restauraciones obsoletas son el asesino silencioso: volumen reconstruido hace meses, cabecera vieja reaplicada, frase aceptada… y el contenido se descodifica en basura, porque el envoltorio antiguo guarda la clave del volumen anterior mientras que los datos se escribieron con una nueva. Las versiones del envoltorio y de los datos deben corresponderse. Fecha cada copia, conserva las dos últimas y prohíbe las restauraciones automatizadas sin excepción.

La cabecera asegurada fuera de la máquina, el riesgo residual se reubica: en la memoria, en el procedimiento, en las personas que pueden alcanzar la máquina en marcha. La siguiente sección traza ese territorio del estado en vivo: qué expone un contenedor desbloqueado, qué copian de verdad las instantáneas y dónde se trazan las líneas honestas entre el almacenamiento que puedes perder y las sesiones que no.

RAM, instantáneas y dónde está de verdad la línea

Ejecuta el experimento de la instantánea en una máquina desbloqueada: la imagen captura solo bloques sellados, porque el descifrado ocurre durante las lecturas y el disco nunca almacena texto en claro. Suena a inmunidad hasta que aparece la clave de conveniencia: un archivo aparcado en /root/vault.key, con modo 600, viaja en la misma instantánea en claro. La fuerza de tu archivo pasa a equivaler a los bits de permiso de tu disco de arranque: adecuada, hasta el día en que de pronto no lo es.

El kernel retiene cada clave mapeada, y el root puede solicitarlas: dmsetup table --showkeys imprime en hexadecimal el secreto maestro de cada destino activo. No es una fuga: es un diseño. El descifrado exige residencia, y el root del kernel es soberanía sobre la máquina; la guía de dm-crypt del kernel lo dice sin ceremonia. Tu propio modelo de amenazas debería decir lo mismo con el mismo tono.

Traza dos columnas con honestidad. Cubierto siempre: el contenedor sellado en reposo, las instantáneas del estado sellado, los discos extraídos, las copias enviadas al extranjero. Nunca cubierto: las sesiones en vivo, las claves en memoria, la terminal donde se tecleó la frase. El cifrado responde una pregunta —qué pasa cuando el almacenamiento se va— y se niega rotundamente a responder otra: qué pasa cuando la máquina es requisada en marcha. Pregunta distinta, contramedidas distintas.

El instinto de portátil engaña en servidores. Suponer que el operador cuenta como «nadie» porque los volúmenes están sellados ignora tres capacidades: órdenes de instantánea, inspección de memoria, compromiso del host: cada una lee una máquina en marcha al margen del cifrado elegido. Sigue cifrando igualmente, porque los estados sellados dominan el calendario de un disco; solo deja de fingir que la plataforma queda fuera del modelo que escribiste.

Todo lo anterior asumía un arranque que no controlas. El metal lo invierte: el initrd es tuyo, la consola es tuya, la pregunta del encendido es tuya por plantear. Sigue el caso dedicado, y dura menos de lo esperado, porque las disciplinas duras —copias de cabecera en otro sitio, higiene de credenciales— ya son tuyas desde las secciones previas.

Ser dueño del arranque: el argumento del metal

Contra-intuitivo otra vez: el hierro desnudo simplifica el cifrado. Tú compilas el initrd, tú eres dueño del gestor de arranque, y la petición de frase de contraseña aparece en una consola bajo tu control: ningún proveedor cerca del trayecto del secreto. Cada advertencia de la ruta alquilada de las secciones anteriores simplemente caduca. Lo que queda es la disciplina que ya practicas: copias de cabecera en otro sitio, credenciales rotadas con deliberación, rutas de desbloqueo ensayadas.

Dos discos fuerzan una decisión temprana sobre el espejado. Sella cada uno —/dev/nvme0n1 y /dev/nvme1n1 con cabeceras separadas, idealmente frases separadas— y luego refleja el par mapeado con md como describe md(4). Un disco falla, el reemplazo resincroniza, y el superviviente nunca existió sin sellar según el calendario de nadie. Invertir las capas también funciona; elige con deliberación y documenta la recuperación antes de que llegue el día del fallo.

La consola remota es tu paracaídas. ipmitool sol activate entrega el prompt serie desde cualquier lugar; los medios virtuales de IPMI montan una imagen de rescate cuando el initrd se enfurruña. Ensaya el desbloqueo completo durante la primera semana: ciclo de energía, prompt por serie, credencial tecleada, volúmenes mapeados. Una ruta de desbloqueo nunca ejercitada es superstición vestida de runbook.

Cuando la cadena de arranque no debe contener a ningún tercero, alquila Forge a $49/mes de lista —$39.20/mes con prepago anual— y aplica estas mismas disciplinas a sus dos discos de 1 TB. Luego evita el error que arruina los montajes de metal: dejar el segundo disco en claro «para rescate» mientras el espejo replica fielmente tus secretos en el disco sin sellar. Ambas mitades selladas, o el espejo es la brecha.

Ahí está la escalera completa: contenedor en un volumen adicional, contenedor en una imagen de disco, espejo sellado en hierro propio. La sección de cierre ordena cada decisión en la secuencia en que realmente las encontrarás: aprovisionar, formatear, cablear, ensayar, con el comando de verificación adjunto a cada paso del camino. Leída como un solo instrumento, la escalera cambia conveniencia por superficie de ataque: cada peldaño niega el secreto a una parte más: primero el almacenamiento, luego la propia ruta de arranque.

El cifrado, en el orden en que se ejecuta

Elige la forma antes que cualquier otra cosa, porque cada paso posterior la hereda. Conjunto de secretos modesto en un solo disco: la variante de imagen de disco. Volumen adicional disponible o alquilable: la variante de volumen: el flash de ochenta gigabytes de una porción de entrada se divide netamente por la mitad. Cadena de arranque exigida libre de proveedores: metal, y salta directo al paso del initrd. Decide la forma y su historia de copias de seguridad en una sola sentada, porque migrar después un contenedor cargado reescribe tus scripts.

La construcción son cuatro comandos, iguales para archivo o volumen: luksFormat escribe el envoltorio, open lo mapea, mkfs.ext4 amuebla un sistema de archivos, mount lo presenta. Mueve los secretos con rsync, verifica por muestreo y retira entonces las fuentes, que se convierten en el pasivo en cuanto el contenedor existe. La verificación no necesita ser exhaustiva: un diff por muestreo y un volcado abierto cazan los errores de copia que de verdad ocurren.

Cablea el ritual para que los reinicios esperen solo a ti. Nada de valores por defecto en crypttab que tiren de material de clave desde el disco de arranque; nada de entradas en fstab que presuman un mapper desbloqueado. O desbloqueas personalmente por SSH tras cada reinicio, o ejecutas una unidad que espera tu entrada; y fuerza un reinicio mientras el contenido aún es prescindible, probando el ritual antes de que nada valioso dependa de él.

Captura la cabecera mientras todo va bien: comando de copia, suma de verificación, fuera de la máquina, con fecha. Ensaya una restauración sobre un archivo de prueba una vez; repítela tras cada cambio de credencial. Este hábito único decide si una cabecera dañada cuesta dos minutos o lo cuesta todo, y es el seguro más barato de toda esta página. Una divergencia de checksums entre copias es en sí mismo un hallazgo: investiga antes de fiarte de cualquiera.

Luego vive dentro de la frontera con honestidad: las imágenes de contenedores sellados viajan seguras; las imágenes tomadas en claro exponen el material de clave que descansara en /root; el sistema arrancado es transparente para su root al margen del cifrado. Donde la cadena de arranque deba excluir por completo a terceros, la misma escalera trepa al hierro: initrd tuyo, consola reservada para emergencias, desbloqueo ensayado en la primera semana. Ejecuta los pasos en secuencia y el hábito aguanta años.