20 de junio de 2026 · 3 min de lectura
Bastionado de infraestructuras de backup contra ransomware: lecciones de un laboratorio Zero Trust
Ransomware · Zero Trust · Proxmox · Blue Team
Los operadores de ransomware modernos no empiezan cifrando tus datos de producción. Empiezan buscando tus copias de seguridad — porque una víctima que puede restaurar en una hora no paga. MITRE ATT&CK cataloga esta técnica como T1490, Inhibit System Recovery, y hoy es procedimiento estándar: borrar las shadow copies, destruir los repositorios de backup y, después, cifrar.
Para mi tesis de máster construí la defensa y también el ataque. Esta nota resume las decisiones de arquitectura que sobrevivieron al contacto con un adversario simulado — y las que no.
El laboratorio
El entorno corre sobre hardware físico, es deliberadamente pequeño y totalmente reproducible:
- Proxmox VE como capa de virtualización para las cargas de producción
- Proxmox Backup Server (PBS) como destino de copias dedicado y físicamente separado
- pfSense imponiendo redes microsegmentadas entre ambos
- Un atacante escrito por mí que ejecuta comportamiento de ransomware destructivo, en modo wiper, contra las superficies de backup alcanzables
Construir el atacante yo mismo era una cuestión de honestidad: una defensa que nunca se ha probado contra un ataque concreto y bien entendido es una hipótesis, no un control.
Lo que de verdad importó
1. La inmutabilidad gana a los permisos. Los controles de acceso fallaron de formas interesantes; los datastores inmutables, no. Si la capa de almacenamiento se niega físicamente a borrar dentro de la ventana de retención, una credencial comprometida deja de ser una catástrofe.
2. El servidor de backup no debe confiar en el hipervisor. En el diseño ingenuo, las credenciales de PBS vivían en el host de PVE — así que poseer producción significaba poseer también la recuperación. Invertir la relación de confianza (tokens de API acotados, pull en lugar de push donde fue posible, cero credenciales administrativas compartidas) cerró el camino más dañino de todos.
3. La microsegmentación reduce el espacio de búsqueda. Con las reglas de pfSense reducidas exactamente a los flujos que PBS necesita, las opciones laterales del atacante quedaron en un puñado de puertos — todos instrumentados. Detectar es más fácil cuando el grafo permitido es tan pequeño que se puede razonar sobre él.
4. El RBAC solo ayuda si los roles son aburridos. Los roles amplios de "administrador de backups" recreaban el problema que debían resolver. El diseño final usa roles estrechos y de propósito único cuya unión — y no ninguno por separado — es necesaria para destruir datos.
5. El tiempo de recuperación es una propiedad de seguridad. Medí las rutas de restauración bajo condiciones de ataque hasta que el objetivo de tiempo de recuperación fue óptimo y aburridamente repetible. Un RTO sin probar es marketing.
La lección incómoda
El ataque simulado más eficaz no tocó ni una sola vulnerabilidad. Usó credenciales legítimas, APIs legítimas y endpoints de borrado legítimos — exactamente como hacen los operadores reales. Los controles que lo detuvieron fueron arquitectónicos (inmutabilidad, inversión de confianza, segmentación), no de firmas ni de parches. Las guías de hardening que terminan en "actualiza tus sistemas" no llegan a donde esta pelea ocurre de verdad.
La guía operativa completa de hardening de la tesis está en preparación para publicarse como open source. Si quieres hablar de los detalles antes, escríbeme.