Cripto de Disco y Backups: VeraCrypt, LUKS y Estrategia 3-2-1 Resiliente

Perder una maquina cifrada es molesto. Perder el backup cifrado de la maquina cifrada es el fin del proyecto. La diferencia entre los dos escenarios suele ser una hoja de calculo de dos columnas: donde esta la clave hoy y quien ya probo restaurar a partir de ella. En Basilisk OffSec corremos ejercicios trimestrales de wipe-and-restore en nuestras estaciones de investigacion, y casi cada iteracion revela un detalle olvidado: header LUKS sin backup, passphrase divergente entre boveda y boveda, snapshot de Restic apuntando a un bucket ya rotado. Cifrado de disco y backup no son temas separados; son el mismo engranaje girando en sentidos opuestos.

Para Linux, LUKS2 con Argon2id sigue siendo la opcion estandar en 2026. Usa `cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 /dev/nvme0n1p3` para un coste de KDF agresivo en hardware moderno, y nunca olvides `cryptsetup luksHeaderBackup` hacia un archivo de 16 MiB guardado en otro medio fisico. Ese archivo es lo que separa un disco cifrado utilizable de un ladrillo aleatorio si el sector cero de la particion se corrompe. Lo combinamos con TPM2 sellado via `systemd-cryptenroll` para boot sin contrasena en estaciones confiables, manteniendo un slot de recovery con passphrase Diceware de 6 palabras. Mas sobre esta logica de defensa en capas en Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion.

VeraCrypt entra cuando necesitamos containers portatiles o plausible deniability. Un archivo `.hc` de 50 GiB con volumen oculto sigue siendo la forma mas discreta de llevar evidencia de un engagement por el aeropuerto, siempre que entiendas que plausible deniability solo funciona si la contraparte acepta la premisa. Para discos enteros en Windows preferimos BitLocker con clave en TPM mas PIN, y VeraCrypt solo para particiones secundarias o pendrives compartidos entre Linux y Windows. Documentamos el trade-off de cada eleccion en nuestro proceso de OPSEC personal, conectado en OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal y en la eleccion de sistema operativo discutida en Tails, Whonix o Qubes OS: Cual Elegir para Cada Escenario de OPSEC.

La estrategia 3-2-1 clasica dice tres copias, dos medios distintos, una offsite. En 2026 trabajamos con 3-2-1-1-0: la cuarta copia es immutable (S3 Object Lock o Backblaze B2 con hold), y el cero significa cero errores en la ultima verificacion. Nuestro pipeline usa Restic con repositorio cifrado AES-256, snapshots diarios hacia un NAS Synology en el rack, replicacion semanal hacia un HDD USB que vive en una caja fuerte fuera de la oficina, y replicacion mensual hacia Backblaze B2 con retencion de 7 anos y Object Lock governance. La clave Restic se genera con 256 bits de entropia, dividida via SLIP39 en 3 de 5 shards y distribuida entre caja fisica, hardware wallet y abogado de confianza, proceso parecido al de Cripto Personal: Hardware Wallets, Passphrase y Backup Resistente a Coaccion.

Cifrar no basta: backup no probado no existe. Cada primer viernes del mes derribamos una VM de investigacion, la recreamos desde cero a partir del snapshot mas reciente de Restic y cronometramos el tiempo hasta tener el entorno usable. RTO objetivo: 90 minutos para una estacion de pentest con herramientas customizadas. Para validar integridad corremos `restic check --read-data-subset=10%` semanalmente y `restic check --read-data` completo cada trimestre. Los logs van a nuestro Elastic interno y se correlacionan con reglas Sigma simples, idea que detallamos en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion. Si una verificacion falla, abrimos incidente igual que abririamos para un IOC en produccion.

Cuidado con los anti-patrones que vemos seguido en consultorias: backup del header LUKS guardado dentro del propio disco cifrado; clave de Restic en texto plano en `~/.config`; snapshot Time Machine apuntando a un NAS sin cifrado at-rest; replicacion a Google Drive personal creyendo que cuenta como offsite. Cada uno ya fue postmortem real en algun cliente. La regla de oro es: si no puedes dibujar en el pizarron la cadena completa de claves desde el plaintext hasta el medio mas frio, y describir quien tiene acceso fisico a cada eslabon, tu modelo de amenaza esta filtrando.

Para cerrar con algo accionable: reserva dos horas este fin de semana, haz `cryptsetup luksHeaderBackup` de cada disco cifrado que mantengas, genera una nueva passphrase Diceware y guarda el header en un pendrive cifrado en otra direccion. Despues corre una restauracion de prueba de tu backup mas reciente en una VM desechable y mide cuanto tardo. Si no pudiste restaurar o tardaste mas de dos horas, no tienes backup, tienes esperanza. Higiene de cripto y backup es exactamente el tipo de trabajo silencioso que decide si un incidente termina como anecdota graciosa en la retrospectiva o como demanda laboral.