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

Un laptop robado en el tren, un disco incautado, un ransomware que cifra todos los recursos de red a las 03:12: tres escenarios, una pregunta. Puede alguien llegar a tus datos, y puedes tu mismo recuperarlos tras una perdida total? La cripto de disco y una estrategia de backup 3-2-1 resiliente son dos caras de la misma moneda: confidencialidad contra el robo, disponibilidad contra la perdida. Este post muestra en concreto como cifrar con LUKS y VeraCrypt, como gestionar las llaves de verdad, y como construir backups para que ni un ladron ni un ransomware ni tu propio error te arruinen.

Primero el modelo de amenaza

Cifrar sin modelo de amenaza es teatro cripto. El cifrado de disco completo protege datos at rest: hardware robado o incautado en estado apagado. No protege el sistema en ejecucion donde la llave vive en RAM, ni contra malware con root, ni contra un ataque cold-boot en un equipo desbloqueado, ni contra coaccion cuando alguien te fuerza la passphrase. Define entonces con claridad contra quien te defiendes, tal como lo derivamos en OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal. El modelo dicta la eleccion: alcanza LUKS estandar, necesitas volumenes ocultos, necesitas aislamiento estricto como en Tails, Whonix o Qubes OS: Cual Elegir para Cada Escenario de OPSEC.

Montar LUKS en Linux como corresponde

En Linux, LUKS2 es el estandar. En la creacion, lo que importa es la derivacion de llave: cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id /dev/nvme0n1p3. Argon2id es memory-hard y frena el brute force masivamente, a diferencia del viejo PBKDF2. Verifica con cryptsetup luksDump que argon2id y un costo de memoria sensato esten realmente activos. LUKS ofrece ocho keyslots: usa uno para la passphrase, uno para un keyfile en una caja fuerte, uno como recovery de emergencia que guardas offline. Rota slots comprometidos con luksKillSlot. Para servidores, combina LUKS con higiene de boot y menor privilegio como en Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion, si no el disco cifrado protege un sistema en ejecucion lleno de agujeros.

VeraCrypt, volumenes ocultos y negacion plausible

VeraCrypt brilla multiplataforma (Windows, macOS, Linux) y con contenedores en vez de particiones enteras. Un contenedor .hc es un archivo montado como volumen cifrado, ideal para datasets sensibles y portables. La funcion estrella es el volumen oculto: dentro de un volumen externo vive un segundo cuya existencia no se puede probar criptograficamente. Bajo coaccion revelas la passphrase del volumen externo, con datos senuelo plausibles, mientras el volumen oculto queda invisible. Es poderoso pero fragil: si escribes demasiado en el volumen externo, sobrescribes el oculto. VeraCrypt ademas es deliberadamente lento en la derivacion (alto conteo de iteraciones), lo que encarece el brute force. Elige una passphrase larga y de alta entropia, porque ningun conteo de iteraciones salva un password debil.

Gestion de llaves que aguanta

La llave es la verdadera superficie de ataque, no el algoritmo. Una passphrase de seis palabras Diceware aleatorias le gana a cualquier password ingenioso pero corto. Separa conocimiento y posesion: passphrase en la cabeza mas un keyfile en una YubiKey o un stick offline. Para desbloqueo desatendido de servidores, amarra la llave a un TPM con politica PCR de modo que el disco solo arranque si la cadena de medicion del firmware no cambio; Clevis y systemd-cryptenroll lo automatizan. Guarda una recovery key fisicamente separada y offline. La misma mentalidad resistente a coaccion, incluidos mecanismos de duress, la profundizamos en Cripto Personal: Hardware Wallets, Passphrase y Backup Resistente a Coaccion. Recuerda: una llave perdida sin recovery significa perdida de datos garantizada, una llave filtrada significa compromiso garantizado.

La regla 3-2-1 y su extension

La regla 3-2-1 es el corazon de toda estrategia resiliente: tres copias de tus datos, en dos tipos de medio distintos, con una fuera del sitio. En concreto: los datos vivos, un backup local en otro disco o un NAS, y una copia geograficamente separada en un destino cloud u offsite cifrado. La extension moderna es 3-2-1-1-0: el uno extra es una copia offline o inmutable, el cero es cero errores en restauraciones verificadas. Esa unica copia offline es justo la diferencia entre sobrevivir y hundirse cuando el ransomware cifra todo disco alcanzable. Un backup que el ransomware tambien puede cifrar no es un backup, es un segundo rehen.

Cifrar backups con restic y borg

El software de backup debe cifrar del lado del cliente antes de que los datos salgan del equipo. restic y BorgBackup hacen exactamente eso: deduplicacion mas cifrado, de modo que el destino (S3, un servidor ajeno, un disco externo) solo ve cifrado. Con restic creas un repo con restic init, respaldas con restic backup /datos y prunes con una politica de retencion como --keep-daily 7 --keep-weekly 4 --keep-monthly 12. La llave del repo nunca se sube al proveedor, lo que es decisivo cuando el destino offsite no es confiable. Borg ofrece lo mismo con borg init --encryption=repokey-blake2. Ambos te dejan tratar el destino de backup como potencialmente hostil, el unico default sano para copias offsite.

Backups inmutables y offline contra ransomware

La pregunta decisiva con ransomware es: puede el host comprometido destruir sus propios backups? Si la respuesta es si, no tienes ninguno. Haz al menos una copia inmutable o fisicamente offline. En la nube usas S3 Object Lock en modo compliance o inmutabilidad de Backblaze B2, de modo que ni credenciales robadas pueden borrar objetos antes de que expire la ventana de retencion. Localmente, rota dos discos externos con uno siempre en el armario, fisicamente desconectado. Suma repos append-only (restic sobre un rest-server con --append-only) para que un cliente comprometido pueda escribir pero no borrar. Detecta borrados masivos inusuales u olas de cifrado temprano con deteccion al estilo de Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion.

Pruebas de restore, o no tienes backup

Un backup que nunca fue restaurado es una esperanza, no un backup. Agenda drills de restore regulares: restaura un archivo al azar, luego una carpeta entera, luego un sistema completo en una VM y compara hashes. Con restic verificas la integridad del repo via restic check --read-data-subset=10% y ensayas el restore real con restic restore latest --target /restore-test. Documenta el tiempo de restauracion (RTO) y la maxima perdida de datos tolerable (RPO) para que nadie adivine en un evento real. El cero de 3-2-1-1-0 significa exactamente esto: cero errores en una restauracion verificada. Sin esa prueba descubres el backup roto justo la noche en que lo necesitas.

Errores comunes

Cinco trampas aparecen una y otra vez. Primera: passphrase debil sobre cripto fuerte, lo que anula todo el esfuerzo. Segunda: la llave vive al lado de los datos, como un keyfile en la misma particion sin cifrar. Tercera: backups en el mismo limite de confianza, de modo que un atacante con acceso los borra tambien. Cuarta: restores nunca probados que fallan en un evento real por un password olvidado o un repo corrupto. Quinta: llenar sin cuidado el volumen externo de VeraCrypt y sobrescribir el oculto. Cada una de estas trampas convierte una estrategia aparentemente segura en una ilusion. La buena noticia: las cinco se evitan con disciplina y no con tecnologia cara.

Checklist practico

Primero: LUKS2 con argon2id, verificado via luksDump. Segundo: passphrase de al menos seis palabras Diceware, separada de un keyfile que poseas. Tercero: datos sensibles de transporte en contenedores VeraCrypt, con volumen oculto cuando la coaccion es un riesgo. Cuarto: honra 3-2-1, extendido a 3-2-1-1-0 con una copia offline o inmutable. Quinto: cifra backups del lado del cliente con restic o borg, trata el destino como hostil. Sexto: Object Lock o append-only contra ransomware. Septimo: define una politica de retencion y prunea. Octavo: un drill de restore mensual con comparacion de hashes, RTO y RPO documentados. Noveno: guarda la recovery key offline y fisicamente separada. Vive estos nueve y sobrevives robo, incautacion y ransomware por igual.

FAQ

Alcanza con el cifrado de disco completo? No. Solo protege datos at rest. Un sistema en ejecucion y desbloqueado, malware con root, o un laptop abierto con la llave en RAM no estan cubiertos. Combina cripto de disco con hardening del sistema, un auto-lock corto, y backups cifrados y separados.

Backup en la nube o copia offsite propia? Ambos son legitimos mientras cifres del lado del cliente y la llave nunca llegue al proveedor. La nube te da geo-separacion facil e inmutabilidad via Object Lock; un disco externo rotado en otro edificio te da control total. Lo ideal es combinar ambos.

Conclusion

La cripto de disco y los backups resuelven dos problemas distintos e igual de importantes: nadie lee tus datos, y nunca los pierdes. LUKS2 con argon2id y VeraCrypt con volumenes ocultos cubren la confidencialidad; una estrategia 3-2-1-1-0 vivida con honestidad, con cifrado del lado del cliente y al menos una copia inmutable offline, cubre la disponibilidad. Takeaway practico: cifra el primer disco hoy, monta el primer repo restic con destino offsite hoy, y haz la primera prueba de restore real esta semana. La seguridad que nunca ensayaste es solo un rumor sobre tu propia resiliencia.