Respuesta a ransomware en ZFS: el playbook de snapshots que te salva

Cómo se manifiesta el ransomware en ZFS (y qué no lo es)

El ransomware no es una sola cosa. En almacenamiento, típicamente cae en uno de estos grupos:

• Ransomware que cifra archivos: recorre un árbol de ficheros y reescribe archivos (o escribe nuevas copias cifradas y luego borra los originales). En ZFS esto suele verse como escrituras aleatorias y gran churn de metadatos.
• Comportamiento de wiper: borra, trunca, sobrescribe. Mismo efecto: el dataset en vivo queda hecho basura.
• Atacante con credenciales: el peor tipo. No necesitan malware sofisticado. Inician sesión como tú (o como tu automatización) y ejecutan comandos destructivos: borrar snapshots, destruir datasets, matar replicación.
• Compromiso del hipervisor/VM: cifra dentro del guest. Tu ZFS ve grandes escrituras a zvols o imágenes VM, no archivos individuales.
• Compromiso del objetivo de backups: el atacante afecta al sistema que guarda tus “backups” y los cifra también. Si tu caja ZFS es el target de backup y es escribible desde el entorno infectado, felicitaciones: construiste un self-own de alto rendimiento.

Los snapshots de ZFS ayudan sobre todo con los dos primeros. Ayudan con el tercero solo si la eliminación de snapshots está restringida y la replicación tiene una brecha de seguridad. Si los atacantes pueden borrar snapshots y copias replicadas, tus snapshots son solo una historia reconfortante que te cuentas a ti mismo.

Una cita para mantener en la cabeza cuando las cosas se ponen ruidosas: La esperanza no es una estrategia. — idea parafraseada que a menudo se atribuye al liderazgo de operaciones. El punto se mantiene aunque la atribución sea imprecisa: la esperanza no pasa auditorías ni restaura datos.

Semántica de snapshots: por qué esto funciona

Los snapshots de ZFS son vistas puntuales de un dataset. Son baratos porque ZFS es copy-on-write: las escrituras nuevas asignan bloques nuevos; los bloques existentes referenciados por un snapshot se mantienen. Esta es la ventaja principal: el ransomware puede reescribir el dataset en vivo todo lo que quiera; tu snapshot sigue apuntando a los bloques antiguos.

Dos salvedades: los snapshots no son magia y no son inmutables por defecto. Si un atacante (o una herramienta de automatización mal configurada) puede ejecutar zfs destroy pool/ds@snap, tus “backups inmutables” se convierten en “una curiosidad histórica”. También: los snapshots preservan estados corruptos pero consistentes. Si el ransomware cifra tus archivos de forma limpia, los snapshots conservan la vista previa del cifrado, pero solo si tienes un snapshot anterior al inicio del cifrado.

Decisiones del modelo de amenaza que importan

• Asume que las credenciales están comprometidas hasta que se demuestre lo contrario. Tu host de restauración no debe confiar en el host infectado.
• Prefiere restaurar en otro lugar en vez de revertir in situ para sistemas críticos cuando puedas permitirlo. Te da forense y reduce el riesgo de reinfección.
• La replicación es tu “brecha aérea” solo si no es continuamente escribible y borrable desde el mismo plano de control.

Hechos e historia que cambian tu respuesta

Estos no son trivialidades. Son las pequeñas verdades que determinan si tu recuperación será una vuelta victoriosa o un post-mortem.

1. Los snapshots de ZFS llegaron temprano y siguieron siendo curiosamente infrautilizados. Sun introdujo ZFS a mediados de los 2000 con snapshots como característica de primera clase, mucho antes de que “ransomware” fuera una palabra de junta directiva.
2. Copy-on-write es a la vez superpoder y trampa de rendimiento. Hace que los snapshots sean baratos, pero las reescrituras aleatorias sostenidas (hola ransomware) pueden fragmentar el espacio libre y castigar la latencia.
3. Eliminar snapshots puede ser costoso. Destruir snapshots grandes y antiguos puede desencadenar mucho trabajo en mapas de espacio y I/O, lo cual importa en medio de un incidente cuando intentas restaurar rápido.
4. El “send/receive” de ZFS puede ser una máquina del tiempo forense. Puedes replicar estado incremental y reconstruir líneas temporales, no solo restaurar datos.
5. Los operadores de ransomware pasaron a la doble extorsión. Incidentes modernos a menudo implican robo de datos más cifrado. Los snapshots arreglan el cifrado; no deshacen la exfiltración.
6. Los atacantes aprendieron a atacar backups. La última década los empujó a borrar shadow copies, VSS snapshots, catálogos de backup—y sí, snapshots de ZFS si pueden alcanzarlos.
7. Existen políticas de snapshots inmutables, pero son elecciones operativas. En algunas plataformas puedes configurar holds, permisos delegados o dominios administrativos separados. Nada es automático; todo requiere disciplina.
8. El cifrado puede ayudar y perjudicar. El cifrado nativo de ZFS evita el robo de disco en bruto y puede limitar algo de la forense, pero no detiene ransomware que se ejecuta como un usuario que puede leer/escribir archivos.
9. Las restauraciones rápidas requieren planificación de espacio libre. El mejor snapshot del mundo no sirve si no puedes montarlo, clonarlo o recibirlo porque tu pool está al 95% y enojado.

Broma #1 (corta, relevante): El ransomware es la única carga de trabajo que hace que todos de repente aprecien la ingeniería de almacenamiento “aburrida”. Es como una auditoría sorpresa, pero con más profanidad.

La primera hora: contener, preservar, decidir

En la primera hora no estás “restaurando”. Estás comprando opciones.

1) Contener el radio de daño

Si el cifrado está en curso, cada minuto cuenta. Corta la ruta de escritura. Eso puede significar:

• Desconectar exportaciones SMB/NFS de la red.
• Detener servicios de aplicación que escriben en datasets afectados.
• Deshabilitar cuentas comprometidas o revocar tokens.
• Poner en cuarentena el host en el switch o firewall.

La contención vence a la astucia. Si no puedes detener las escrituras, no puedes confiar en la línea temporal.

2) Preservar evidencia sin ralentizar la recuperación hasta un colapso

Necesitas suficiente evidencia para responder “¿cómo entraron?” y “¿hasta dónde llegó?” sin convertir esto en una feria de ciencia forense. Punto medio práctico:

• Toma un snapshot nuevo de los datasets afectados inmediatamente (sí, incluso si los datos están malos). Estás congelando el estado actual para análisis posterior.
• Exporta logs (auth logs, SMB logs, logs de aplicaciones) fuera del host.
• Si replicas, pausa y copia el estado actual de replicación para revisión posterior; no sobrescribas buen historial.

3) Decide tu modo de recuperación

Tienes tres patrones principales:

• Rollback in situ: rápido, arriesgado. Bueno para comparticiones de archivos simples si confías en que el host está limpio y conoces el snapshot correcto.
• Clonar snapshot y servir el clone: más seguro. Puedes montar el clone en modo solo-lectura inicialmente, validar y luego cambiar.
• Restaurar a un sistema limpio en otro lugar: lo más seguro. Cuesta más tiempo y capacidad, pero reduce la reinfección y preserva el sistema comprometido para investigación.

Mi sesgo: para cualquier cosa que ejecute código (servidores CI, servidores de aplicación con volúmenes escribibles, datastores de VM), restaurar en otro lugar. Para shares de archivos “tontos” con buena higiene de identidad, los clones son un punto medio excelente.

Playbook de diagnóstico rápido (tría por cuello de botella)

Esta es la lista “¿qué verifico primero, segundo, tercero?” cuando todos te miran y necesitas dejar de adivinar.

Primero: ¿el atacante sigue escribiendo?

• Busca escrituras sostenidas y churn de ficheros en los datasets afectados.
• Confirma si clientes SMB/NFS siguen conectados y modificando datos activamente.
• Decisión: si las escrituras están en curso, aisla o detén servicios antes de cualquier otra cosa.

Segundo: ¿todavía tienes snapshots limpios?

• Lista snapshots recientes y verifica que tengas una línea temporal que abarque antes del supuesto inicio del cifrado.
• Revisa si snapshots fueron borrados recientemente (brechas inesperadas).
• Decisión: si el historial de snapshots falta, cambia inmediatamente a replicación/offsite u otros backups; no pierdas tiempo planeando un rollback que no puede ocurrir.

Tercero: ¿cuál es tu cuello de botella de restauración—CPU, disco, red o espacio?

• Espacio: uso del pool y fragmentación; si estás cerca del lleno, clones/receives pueden fallar.
• Disco: latencia alta, resilvering o errores; restaurar en un pool que falla es una tragedia lenta.
• Red: replicación o restauración a través de enlaces; mide throughput y pérdida de paquetes.
• CPU: cifrado/compresión puede limitar tasas de send/receive; verifica si estás limitado por CPU.
• Decisión: elige rollback vs clone vs restore-elsewhere según la restricción. Si el espacio es escaso, rollback puede ser la única opción; si el host es sospechoso, restaura en otro lugar aunque sea más lento.

Cuarto: valida limpieza sin reinfectar

• Monta snapshots/clones candidatos en solo-lectura primero.
• Busca patrones conocidos de nota de rescate, nuevas extensiones y ejecutables/scripts recientemente modificados en rutas compartidas.
• Decisión: elige el punto de restauración donde los datos de negocio estén íntegros y los artefactos maliciosos estén ausentes (o al menos entendidos).

Tareas prácticas: comandos, salidas, decisiones (12+)

Estos son los comandos que realmente ejecutas, con salidas realistas y qué hacer después. Los nombres de host y pool son ejemplos; mantén los tuyos consistentes. Se asume que el incidente involucra el pool tank con datasets tank/share y tank/vm.

Tarea 1: confirmar salud del pool (no restaures sobre una plataforma en llamas)

cr0x@server:~$ zpool status -x
all pools are healthy

Qué significa: No hay errores conocidos de dispositivos ni resilvering en progreso.

Decisión: Procede. Si ves DEGRADED, FAULTED o resilvering, planea restaurar en hardware distinto.

Tarea 2: comprobar capacidad del pool y riesgo de fragmentación

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,cap,health
NAME  SIZE  ALLOC   FREE  FRAG  CAP  HEALTH
tank  54.5T  41.8T  12.7T   41%  76%  ONLINE

Qué significa: 76% lleno, fragmentación moderada. No es ideal, pero no mortal.

Decisión: Clones y receives deberían funcionar. Si CAP es > 90%, espera fallos y prioriza rollback o añade capacidad primero.

Tarea 3: identificar qué datasets están siendo golpeados

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME        USED   AVAIL  REFER  MOUNTPOINT
tank        41.8T  11.9T   128K  /tank
tank/share   8.4T  11.9T   8.4T  /srv/share
tank/vm     31.2T  11.9T  31.2T  /srv/vm

Qué significa: tank/vm es enorme; si las VMs están afectadas, el tiempo de restauración se dominará ahí.

Decisión: Divide el incidente: los shares de archivos pueden recuperarse rápido; el datastore de VM puede necesitar un enfoque distinto (restaurar subconjuntos, priorizar VMs críticas).

Tarea 4: observar I/O en tiempo real para confirmar si el cifrado está activo

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        41.8T  12.7T    410   8120   32.1M  1.02G
  raidz2-0                  41.8T  12.7T    410   8120   32.1M  1.02G
    sda                         -      -     52   1015   4.0M  128M
    sdb                         -      -     51   1010   4.1M  127M
    sdc                         -      -     51   1012   4.0M  128M
    sdd                         -      -     51   1012   4.0M  128M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Escrituras sostenidas y fuertes. Si esto no es una ventana de carga conocida, asume cifrado activo o reescritura masiva.

Decisión: Contén: deshabilita shares, detén servicios, pon en cuarentena el host. No empieces rollback mientras las escrituras estén en curso.

Tarea 5: listar snapshots y detectar huecos

cr0x@server:~$ zfs list -t snapshot -o name,creation,used -s creation | tail -n 8
tank/share@auto-2025-12-26-0700  Fri Dec 26 07:00 2025   56M
tank/share@auto-2025-12-26-0800  Fri Dec 26 08:00 2025   60M
tank/share@auto-2025-12-26-0900  Fri Dec 26 09:00 2025   58M
tank/share@auto-2025-12-26-1000  Fri Dec 26 10:00 2025   62M
tank/share@auto-2025-12-26-1100  Fri Dec 26 11:00 2025   59M
tank/share@auto-2025-12-26-1200  Fri Dec 26 12:00 2025   61M
tank/share@auto-2025-12-26-1300  Fri Dec 26 13:00 2025   63M
tank/share@auto-2025-12-26-1400  Fri Dec 26 14:00 2025   65M

Qué significa: Existen snapshots horarios regulares hasta las 14:00. Buena señal.

Decisión: Identifica cuándo empezó el cifrado; elige el snapshot justo antes. Si hay un hueco (horas/días faltantes), sospecha eliminación de snapshots o automatización rota—cambia a replicación/offsite.

Tarea 6: tomar un snapshot “escena del crimen” ahora mismo

cr0x@server:~$ zfs snapshot -r tank/share@incident-2025-12-26T1425Z
cr0x@server:~$ zfs list -t snapshot -o name,creation | grep incident | tail -n 2
tank/share@incident-2025-12-26T1425Z  Fri Dec 26 14:25 2025

Qué significa: Congelaste el estado actual para análisis posterior.

Decisión: Guárdalo. No borres snapshots “malos” durante la respuesta al incidente; los querrás cuando seguridad/legal pregunte.

Tarea 7: comprobar holds en snapshots (y agregar uno cuando deba preservarse)

cr0x@server:~$ zfs holds tank/share@auto-2025-12-26-1200
NAME                          TAG   TIMESTAMP
tank/share@auto-2025-12-26-1200  -     -
cr0x@server:~$ zfs hold keep tank/share@auto-2025-12-26-1200
cr0x@server:~$ zfs holds tank/share@auto-2025-12-26-1200
NAME                          TAG   TIMESTAMP
tank/share@auto-2025-12-26-1200  keep  Fri Dec 26 14:28 2025

Qué significa: Un hold evita la eliminación accidental de ese snapshot hasta que se libere explícitamente.

Decisión: Pon holds en tus snapshots candidatos “último buen conocido” antes de empezar a manipular cualquier cosa.

Tarea 8: confirmar qué cambió recientemente (tría de alta señal)

cr0x@server:~$ zfs diff -H tank/share@auto-2025-12-26-1200 tank/share@auto-2025-12-26-1400 | head
M	/srv/share/finance/Q4.xlsx
M	/srv/share/finance/Q4.xlsx.locked
+	/srv/share/READ_ME_NOW.txt
M	/srv/share/projects/roadmap.docx
M	/srv/share/projects/roadmap.docx.locked

Qué significa: Estás viendo marcadores típicos de ransomware: nueva nota de rescate, archivos reescritos, nuevas extensiones.

Decisión: Elige un snapshot anterior a esos artefactos. Si los artefactos aparecen en muchos snapshots, el cifrado empezó antes de lo pensado.

Tarea 9: inspeccionar de forma segura un snapshot sin cambiar nada

cr0x@server:~$ ls -la /srv/share/.zfs/snapshot/auto-2025-12-26-1200 | head
total 12
drwxr-xr-x   9 root root    9 Dec 26 12:00 .
drwxr-xr-x  10 root root   10 Dec 26 14:00 ..
drwxr-xr-x  12 root root   12 Dec 20 09:10 finance
drwxr-xr-x  34 root root   34 Dec 24 17:03 projects

Qué significa: Los snapshots son visibles vía el directorio .zfs (si está habilitado y no oculto por la configuración de shares).

Decisión: Usa la navegación de snapshots para validación rápida. Si estás en una plataforma donde .zfs no está expuesto, monta un clone en su lugar.

Tarea 10: clonar un snapshot para validación en solo-lectura

cr0x@server:~$ zfs clone -o mountpoint=/mnt/restore_share -o readonly=on tank/share@auto-2025-12-26-1200 tank/share-restore
cr0x@server:~$ zfs get -o name,property,value readonly,mountpoint tank/share-restore
NAME              PROPERTY    VALUE
tank/share-restore  readonly    on
tank/share-restore  mountpoint  /mnt/restore_share

Qué significa: Ahora tienes un clone montado en modo solo-lectura para validación y escaneo.

Decisión: Valida contenido y revisa directorios críticos. Si está limpio, planea el corte: promover el clone o rsync de datos a un destino limpio.

Tarea 11: rollback in situ (solo cuando aceptes el riesgo)

cr0x@server:~$ zfs rollback -r tank/share@auto-2025-12-26-1200
cr0x@server:~$ zfs list -o name,used,refer,mountpoint tank/share
NAME        USED  REFER  MOUNTPOINT
tank/share  8.1T  8.1T  /srv/share

Qué significa: El estado del dataset se revierte a ese snapshot; -r revierte también descendientes.

Decisión: Úsalo solo cuando hayas cerrado la vía de compromiso del atacante y estés confiado en que seleccionaste el snapshot correcto. El rollback es rápido, pero descarta cambios más nuevos. Asegúrate de que el negocio acepte la ventana de pérdida de datos.

Tarea 12: identificar qué está reteniendo espacio (por qué “df” miente durante snapshots)

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbydataset,usedbychildren tank/share
NAME        USED  USEDSNAP  USEDDATA  USEDCHILD
tank/share  8.4T     1.1T     7.3T       0B

Qué significa: Los snapshots están fijando 1.1T de bloques. Eso no es “desperdicio”; es tu red de seguridad.

Decisión: No borres snapshots para “liberar espacio” en medio del incidente a menos que hayas verificado backups fuera de la caja y estés a punto de alcanzar una falla crítica.

Tarea 13: verificar estado de replicación (¿está offsite limpio y actual?)

cr0x@server:~$ zfs get -H -o value receive_resume_token tank/share
-
cr0x@server:~$ zfs list -t snapshot -o name -s creation -r tank/share | tail -n 3
tank/share@auto-2025-12-26-1200
tank/share@auto-2025-12-26-1300
tank/share@auto-2025-12-26-1400

Qué significa: No hay token de reanudación que indique receive interrumpido; la cadena de snapshots existe localmente.

Decisión: En tu target de replicación, confirma que tenga snapshots que predate la infección y que los permisos de eliminación estén restringidos. Si el target está “demasiado sincronizado”, podrías haber replicado datos cifrados también—busca puntos más antiguos.

Tarea 14: hacer un send/receive controlado a un nuevo dataset

cr0x@server:~$ zfs send -R tank/share@auto-2025-12-26-1200 | zfs receive -u tank/restored/share
cr0x@server:~$ zfs list -o name,mountpoint -r tank/restored
NAME                MOUNTPOINT
tank/restored        /tank/restored
tank/restored/share  /tank/restored/share

Qué significa: Restauraste una copia puntual en un árbol de datasets separado, sin sobrescribir el original.

Decisión: Prefiere esto cuando necesites separación limpia y tengas espacio. Luego puedes apuntar exportaciones al dataset restaurado después de validar.

Tarea 15: confirmar propiedades del dataset que impactan velocidad y corrección de recuperación

cr0x@server:~$ zfs get -o name,property,value compression,recordsize,atime,sync tank/share
NAME       PROPERTY     VALUE
tank/share compression  lz4
tank/share recordsize   1M
tank/share atime        off
tank/share sync         standard

Qué significa: Estas configuraciones afectan rendimiento y comportamiento de la carga. Para cargas tipo VM, recordsize y sync son especialmente relevantes.

Decisión: No cambies esto durante el incidente a menos que sepas exactamente por qué. “Ajustar en medio de una caída” es un pasatiempo para quienes disfrutan consecuencias sorpresa.

Tarea 16: comprobar riesgos del modelo de permisos (¿quién puede destruir snapshots?)

cr0x@server:~$ zfs allow tank/share
---- Permissions on tank/share ---------------------------------------
Local+Descendent permissions:
user backupsvc create,destroy,mount,snapshot,send,receive
user appsvc   mount

Qué significa: El usuario backupsvc puede destruir snapshots. Esa es una credencial de alto valor.

Decisión: En la fase de endurecimiento post-incidente, elimina destroy salvo que sea absolutamente necesario, y separa roles para creación de snapshots vs eliminación.

Estrategias de restauración: rollback, clonar y “restaurar en otro lado”

Estrategia A: rollback in situ (más rápido, con aristas cortantes)

El rollback es un mazo. También es un salvavidas cuando el negocio pierde y tienes un dataset bien entendido (como un file share) y cadence de snapshots fiable.

Úsalo cuando:

• Tengas alta confianza en que el vector de compromiso está contenido (credenciales rotadas, shares deshabilitados, malware eliminado).
• Puedas tolerar perder cambios desde el snapshot.
• El dataset no aloje rutas de ejecución de código que puedan reactivarse (por ejemplo, scripts compartidos ejecutados por servidores).

Evítalo cuando:

• Sospeches que el host aún está comprometido.
• El dataset es un datastore de VM o base de datos donde los rollbacks pueden chocar con expectativas de consistencia de la aplicación.
• Necesites forense del estado cifrado y no puedes permitir sobrescribir evidencia.

Estrategia B: clonar un snapshot y hacer cutover (más seguro, aún rápido)

Un clone te permite validar y servir datos limpios sin destruir el dataset actual. También puedes mantener el dataset “infectado” intacto para investigación. Operativamente, puedes cambiar mountpoints, exportaciones o shares SMB para apuntar al clone.

Cuidado: los clones consumen espacio a medida que divergen. Si sigues sirviendo el clone por semanas, se convierte en “producción” y el original en “aquello que eliminaremos algún día”. Ese día nunca llega y la capacidad del pool sube sin ruido. Planea la limpieza.

Estrategia C: restaurar en otro lugar (la opción adulta)

Restaura a un host/pool separado cuando no confíes en el sistema afectado. Esto es la opción por defecto para datastores de VM, bases de datos y cualquier cosa con automatización privilegiada ligada a ella.

Beneficios operativos:

• Plano de control limpio: nuevas claves SSH, credenciales nuevas, nuevas exportaciones.
• Riesgo de reinfección reducido: los atacantes suelen persistir en el entorno original.
• Trabajo en paralelo: un equipo restaura, otro hace forense en el host comprometido.

Costes:

• Capacidad y tiempo. Necesitas espacio para recibir y validar.
• El throughput de la red puede convertirse en cuello de botella.

Broma #2 (corta, relevante): Lo único más aterrador que restaurar desde backups es descubrir que tus backups estaban haciendo “danza interpretativa” en lugar de replicar.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: el incidente causado por una suposición equivocada

Una empresa mediana gestionaba un file share respaldado por ZFS para departamentos. Estaban orgullosos de sus snapshots horarios. El helpdesk podía restaurar archivos navegando .zfs/snapshot. Parecía moderno. También se basaba en una sola suposición: “Solo los admins pueden borrar snapshots”.

Durante un compromiso por phishing, el atacante aterrizó en un workstation Windows y luego obtuvo credenciales que casualmente pertenecían a una cuenta de servicio usada para “restores self-service”. Esa cuenta tenía mucho más poder del que el nombre sugería. Podía snapshotear, montar y—porque alguien no quería lidiar con scripts de retención fallando—destruir.

El atacante no necesitó conocimiento específico de ZFS. Encontró el historial de shell y scripts de automatización, luego ejecutó un puñado de comandos ZFS para borrar la cadena de snapshots antes de cifrar el share en vivo. El cifrado fue ruidoso; la eliminación de snapshots fue silenciosa.

La recuperación fue posible, pero no desde snapshots locales. El equipo tuvo que tirar de una copia offsite más antigua que se replicaba semanalmente (no por hora), rehidratar terabytes por un enlace limitado y luego responder la pregunta que nadie quiere: “Entonces, ¿qué perdimos?”

La solución fue simple y humillante: se separaron permisos delegados. La creación y replicación de snapshots se separó de la destrucción, y se usaron holds en los puntos diarios más recientes. También dejaron de exponer .zfs a usuarios y reemplazaron restores self-service por un flujo de trabajo controlado. El sistema se volvió un poco menos conveniente y dramáticamente más sobrevivible.

Mini-historia 2: la optimización que salió mal

Otro equipo alojaba imágenes VM en ZFS. Querían más rendimiento para la carga más ocupada y aplicaron una serie de ajustes agresivos: recordsize mayor, comportamiento sync relajado en algunos sitios y un calendario de snapshots reducido “para disminuir overhead”. Todo justificado con benchmarks y unos cuantos gráficos felices.

Luego el ransomware golpeó un jump host con acceso a la red de gestión de VM. El atacante no cifró archivos en el host ZFS; cifró dentro de los guests. El almacenamiento vio una tormenta de escrituras aleatorias en múltiples zvols grandes. El calendario de snapshots reducido dejó su último punto bueno para varias VMs críticas muchas horas atrás.

Los ajustes de rendimiento empeoraron la recuperación. Con menos snapshots, intentaron replicar imágenes grandes completas desde el último punto bueno. El enlace de red se volvió cuello de botella, y la sobrecarga de CPU por compresión/cifrado en el lado de send añadió más insulto. Las restauraciones fueron correctas, pero lo suficientemente lentas como para romper objetivos internos de recuperación.

El post-mortem no trató de ZFS siendo “lento”. Se trató de optimizar para el estado estable sin considerar el modo fallo. Reintrodujeron snapshots más frecuentes para datasets de VM, separaron “tuning de rendimiento” de “diseño de recuperación” y pusieron requisitos duros sobre puntos de restauración para sistemas tier-0. Los gráficos de steady-state mejoraron. Pero más importante: el próximo incidente terminaría con una restauración, no con una negociación.

Mini-historia 3: la práctica aburrida pero correcta que salvó el día

Una empresa regulada usaba ZFS para shares departamentales y un pequeño clúster analítico. Su política de snapshots era aburrida: snaps cada 15 minutos por 24h, horarios por hora por 7d, diarios por 1 mes. La replicación corría a un target offsite bajo un dominio administrativo distinto, con permisos de eliminación de snapshots no delegados a la producción.

Además hacían un drill de restauración trimestral. No un ejercicio de mesa. Una restauración real de un dataset representativo a un host limpio, con cronómetro y checklist. A los ingenieros les dolía como cuando odias usar hilo dental: sabes que es correcto, pero aún se siente acusatorio.

Cuando el ransomware llegó vía un workstation comprometido, el file share resultó dañado. Contuvieron el acceso rápidamente, luego clonaron el último snapshot bueno a un montaje de cuarentena y validaron la ausencia de artefactos de rescate. El corte tomó horas, no días.

La replicación offsite fue la heroína silenciosa. Incluso si el atacante hubiera conseguido borrar snapshots locales, el target offsite tenía puntos más antiguos protegidos por política y permisos. El informe del incidente siguió siendo doloroso, pero la recuperación fue procedimental. Sin improvisación, sin heroicas nocturnas, sin “creemos que tenemos todo”.

Lo que los salvó no fue genialidad. Fue negarse a tratar snapshots como una característica y, en cambio, tratarlos como un producto con requisitos: retención, protección y pruebas de restauración.

Endurecer snapshots para que la próxima vez sea aburrida

Cadencia de snapshots: ajústala a cómo actúa el ransomware

El ransomware a menudo corre rápido, pero no siempre. A veces cifra oportunistamente, a veces se desliza para evitar detección. Tu calendario de snapshots debe asumir que podrías notar esto horas después.

• Tier 0 (datos compartidos de negocio): 15-min para 24h, horario por 7d, diario por 30d es una línea base sensata.
• Datastores VM: snapshots frecuentes ayudan, pero no finjas que son consistentes a nivel de aplicación. Úsalos como puntos de restauración crash-consistent y combínalos con backups en el guest para bases de datos críticas.
• Directorios Home: alto churn; establece expectativas con retención para evitar explosión de espacio por snapshots.

Proteger snapshots de eliminación (aquí vive la gente adulta)

La defensa es sobre todo quién puede hacer qué. Los snapshots son vulnerables si los derechos de eliminación conviven en el mismo conjunto de credenciales que las operaciones diarias.

• Usa holds en snapshots “ancla” diarios/semanales, especialmente en targets de replicación.
• Divide privilegios: creación y replicación de snapshots son comunes; la destrucción debe ser rara y con control.
• Separa dominios administrativos: los targets de replicación no deberían aceptar logins interactivos de cuentas admin de producción si puedes evitarlo.
• Haz el target de backup aburrido y austero: paquetes mínimos, servicios mínimos, reglas de firewall estrictas, exportaciones en solo-lectura cuando sea posible.

Diseño de replicación: construye una “brecha por error” a propósito

Si replicás cada minuto y además propagás eliminaciones inmediatamente, construiste una tubería alta disponibilidad para desastres. Añade fricción deliberada:

• Retrasa acciones destructivas: la retención y eliminación de snapshots en el target debe ser independiente de la fuente.
• Mantén retenciones más largas offsite: el target es donde guardas el historial que esperas nunca necesitar.
• Considera replicación pull: el target inicia pulls desde la fuente, usando credenciales limitadas, en lugar de que la fuente haga push al target con derechos amplios.

Pruebas de restauración: deja de mentirte

Los snapshots no son backups a menos que puedas restaurarlos bajo estrés. Haz drills. Cronométralos. Verifica contenido. Documenta los pasos. Pon la checklist donde pueda encontrarse a las 3 a.m. alguien que no construyó el sistema.

Errores comunes: síntoma → causa raíz → solución

1) “Revertimos pero los usuarios siguen viendo archivos cifrados”

Síntoma: Después del rollback, algunos directorios aún contienen archivos .locked o notas de rescate.

Causa raíz: Revertiste el dataset equivocado (o el snapshot equivocado), o los usuarios están viendo una ruta de exportación diferente (namespace DFS, mapeo de share SMB, caché offline del cliente).

Solución: Confirma mountpoints del dataset y definiciones de shares; verifica la selección del snapshot con zfs diff. Limpia o invalida cachés de clientes donde aplique. Asegúrate de no haber restaurado solo un dataset hijo mientras el padre sigue infectado.

2) “Rollback falla con ‘dataset is busy’”

Síntoma: ZFS rechaza el rollback por montajes activos.

Causa raíz: Procesos tienen archivos abiertos, o el dataset está exportado vía NFS/SMB, o una jail/container lo está usando.

Solución: Detén servicios, desexporta shares y desmonta si es necesario. Usa clones/receive-elsewhere si no puedes detener todo de forma segura.

3) “No podemos clonar o recibir: sin espacio”

Síntoma: Clonar/receive falla; pool casi lleno.

Causa raíz: CAP alto o retención de snapshots fijando grandes cantidades de datos, más la amplificación de escritura del incidente.

Solución: Añade capacidad (mejor), migra datasets no críticos, o realiza rollback in situ (si es seguro). Evita borrar snapshots en masa durante I/O pico; pueden empeorar el rendimiento.

4) “El target de replicación también tiene datos cifrados”

Síntoma: Snapshots offsite incluyen artefactos de ransomware.

Causa raíz: La replicación corrió después de la infección; retención demasiado corta; eliminaciones propagadas; sin puntos ancla protegidos.

Solución: Mantén retención más larga en el target, usa holds, desacopla políticas de eliminación y considera replicación retrasada o pull-based. Durante el incidente, detén replicación inmediatamente para evitar sobrescribir buen historial.

5) “Las restauraciones son dolorosamente lentas”

Síntoma: Send/receive con throughput muy por debajo de lo esperado.

Causa raíz: Limitación por CPU (cifrado/compresión), cuello de botella de red, fragmentación del pool o cargas concurrentes (scrubs, resilvers, escrituras activas del ransomware).

Solución: Mide: revisa iostat, uso de CPU, throughput del enlace. Pausa tareas no esenciales. Restaura a un pool distinto si el original está sobrecargado o no saludable.

6) “Los snapshots se fueron, pero nadie admite haberlos borrado”

Síntoma: Cadena de snapshots faltante; logs poco claros.

Causa raíz: Automatización sobre-privilegiada o cuenta de servicio comprometida ejecutó comandos destructivos, o un script de retención falló en condiciones límite.

Solución: Audita permisos delegados y automatización. Controla la eliminación. Pon holds en anclas. Centraliza logs de acciones administrativas de ZFS y eventos de auth de forma inmutable y alertable.

7) “Restauramos y luego fuimos reinfectados”

Síntoma: El cifrado se reanuda después de la recuperación.

Causa raíz: Restauraste datos pero no la confianza. Credenciales comprometidas, malware persistente o shares expuestos permanecieron.

Solución: Rota credenciales antes del cutover, reconstruye hosts comprometidos y reintroduce acceso gradualmente. Trata la restauración como un cambio con controles, no como un botón mágico de deshacer.

Listas de verificación / plan paso a paso

Checklist de respuesta al incidente (vista storage/operador)

1. Contener: deshabilita exportaciones SMB/NFS o bloquéalas por firewall; detén apps con escrituras intensas; pon en cuarentena endpoints comprometidos.
2. Congelar: toma un snapshot @incident-* de los datasets afectados como evidencia.
3. Verificar salud: zpool status, capacidad, errores. Si el pool está unhealthy, planea restaurar en otro lugar.
4. Detener replicación: pausa jobs para no replicar estado cifrado sobre buen historial.
5. Encontrar último snapshot conocido bueno: usa zfs diff, revisa contenido, busca artefactos de rescate.
6. Protegerlo: aplica zfs hold a snapshots candidatos.
7. Elegir modo de recuperación: rollback, clonar y cutover, o restaurar en otro lugar.
8. Validar en cuarentena: monta clone solo-lectura; escanéalo; confirma que archivos críticos se abren correctamente.
9. Cortar: re-apunta shares/mounts; re-habilita acceso por etapas; monitoriza escrituras y logs de autenticación.
10. Endurecimiento post-restore: rota claves, ajusta zfs allow, aplica retención, protege el target.
11. Documentar línea temporal: horas de snapshots, punto de restauración elegido, ventana de pérdida de datos, acciones realizadas.
12. Ejecutar drill de restauración luego: sí, luego. Pero prográmalo antes de que todos lo olviden.

Checklist de cutover para recuperación basada en clones

1. Crea un clone del último snapshot conocido bueno, móntalo en solo-lectura.
2. Valida estructura de directorios, cheques de integridad en muestras críticas y ausencia de artefactos de ransomware.
3. Crea un clone escribible (o promueve el flujo) si necesitas servir datos activamente.
4. Actualiza exportaciones SMB/NFS para apuntar al mountpoint del clone (o intercambia mountpoints atómicamente donde sea factible).
5. Devuelve servicio a un grupo piloto pequeño primero.
6. Observa I/O, fallos de auth y patrones de creación de archivos nuevos por al menos un ciclo de negocio.
7. Solo entonces decide qué hacer con el dataset infectado: conservar para forense, archivar o destruir tras aprobaciones.

Checklist de endurecimiento post-incidente (resiliencia de snapshots)

1. Separa permisos delegados ZFS: quita destrucción de snapshots de cuentas rutinarias.
2. Pon holds en snapshots ancla (diarios/semanales) en el target de replicación.
3. Desacopla políticas de retención entre origen y target; no propagues eliminación ciegamente.
4. Centraliza logging de comandos administrativos y eventos de auth; alerta en destrucción de snapshots.
5. Reduce rutas de acceso escribible: shares con menor privilegio, redes administrativas separadas, MFA donde sea posible.
6. Programa pruebas de restauración y mide RTO/RPO con tamaños reales de datos.

Preguntas frecuentes

1) ¿Los snapshots de ZFS son “backups inmutables”?

No. Los snapshots son referencias puntuales duraderas, no inmutables por defecto. Si alguien puede ejecutar zfs destroy sobre ellos, son eliminables. Usa holds, separación de privilegios y replicación offsite bajo un dominio admin distinto si quieres inmovilidad práctica.

2) ¿Debería hacer rollback o clonar?

Clona cuando puedas; haz rollback cuando debas. Los clones preservan evidencia y te permiten validar antes del cutover. El rollback es más rápido y simple pero descarta cambios más nuevos y puede reintroducir riesgo si el host sigue comprometido.

3) ¿Cómo sé qué snapshot está limpio?

Usa una combinación: línea temporal del incidente (cuando iniciaron los síntomas), zfs diff entre snapshots y la inspección directa de un clone o árbol de snapshot en solo-lectura. Busca notas de rescate, nuevas extensiones y patrones de modificación masiva.

4) ¿Qué pasa si el ransomware cifró discos VM (zvols) en vez de archivos?

Puedes aún revertir o restaurar el dataset zvol, pero el punto de restauración debe ser anterior al cifrado. Espera movimiento de datos grande y validación más lenta. Para bases de datos críticas, combina restauraciones ZFS con recuperación a nivel de aplicación (logs de transacciones, backups consistentes).

5) ¿Activar cifrado ZFS detendrá el ransomware?

No. El cifrado de ZFS protege datos en reposo y puede reducir ciertos escenarios de robo, pero el ransomware ejecutándose con acceso legítimo todavía puede leer/escribir y cifrar tus archivos dentro del dataset.

6) ¿Pueden los atacantes borrar snapshots vía SMB/NFS?

No directamente mediante operaciones de archivos. Pero si comprometen credenciales que tienen acceso shell/API al host ZFS—o comprometen automatización que gestiona snapshots—pueden borrar snapshots usando comandos ZFS. Tu riesgo es identidad y privilegio, no el protocolo SMB en sí.

7) ¿Debería seguir exponiendo .zfs/snapshot para restores self-service?

Es conveniente y a menudo se abusa operativamente (la gente trata snapshots como una papelera). Si lo mantienes, restringe quién puede acceder y asegura que los privilegios de eliminación de snapshots estén muy controlados. Muchos entornos funcionan mejor con un flujo de restauración controlado.

8) ¿Por qué liberar espacio se volvió más difícil después del incidente?

Porque los snapshots fijan bloques. Después de reescrituras masivas, los datos “antiguos” limpios siguen referenciados por snapshots, y los datos “nuevos” cifrados consumen espacio adicional. Eso es esperado. La planificación de capacidad debe incluir margen para incidentes, no solo crecimiento en estado estable.

9) ¿Es seguro borrar el dataset cifrado después de restaurar?

Técnicamente sí, operativamente tal vez no. Obtén aprobaciones de seguridad/legal primero si el incidente requiere reportes. Si necesitas forense, conserva el estado cifrado (o un snapshot del mismo) aislado y con control de acceso.

10) ¿Cuál es la única mejor mejora si solo hacemos una cosa?

Protege snapshots offsite de eliminación por credenciales de producción comprometidas. Eso significa dominio administrativo separado, holds en anclas y retención que un atacante no pueda “limpiar”.

Próximos pasos que puedes hacer hoy

Cuando golpea ransomware, los snapshots de ZFS pueden convertir un evento que arruina carreras en un mal día con checklist. Pero solo si construiste el camino con anticipación: puntos de restauración limpios, historial protegido y una rutina de recuperación que no dependa de héroes.

Haz esto ahora:

1. Audita zfs allow en datasets críticos. Quita destrucción de snapshots de cuentas rutinarias y automatización que no lo necesite absolutamente.
2. Añade holds a snapshots ancla diarios/semanales en el target de replicación.
3. Escribe tu método de “selección del último buen conocido” (línea temporal + zfs diff + validación con clone solo-lectura).
4. Realiza un drill de restauración en un dataset representativo. Cronométralo. Captura los pasos. Arregla lo que te sorprenda.
5. Decide, por adelantado, cuándo harás rollback vs clonar vs restaurar en otro sitio. Durante un incidente es mal momento para inventar filosofía.

El ransomware es un problema de ingeniería con disfraz criminal. Resuélvelo con ingeniería: restricciones, separación de deberes y rutas de recuperación probadas.