El ransomware moderno ya no cifra tu servidor en cuanto entra. Primero hace algo mucho más inteligente: busca tus copias de seguridad. Sabe que si te deja el histórico intacto, restaurarás y no pagarás. Así que la pregunta correcta no es si tienes copias, sino si tu propio servidor puede tocarlas.
Cómo trabaja un ataque real
El patrón se repite. El atacante entra por una credencial robada, una vulnerabilidad sin parchear o un correo con adjunto. Y entonces, en lugar de cifrar de inmediato, se queda semanas en silencio explorando la red: qué servidores hay, dónde están los datos importantes, y sobre todo dónde están las copias y con qué credenciales se accede a ellas.
Cuando decide actuar, el orden es siempre el mismo: primero destruye o cifra el histórico de copias, después cifra los datos en producción, y solo entonces te muestra la nota de rescate. Cuando te enteras, ya no tienes a dónde volver.
El fallo de diseño que casi todos tienen
Aquí está el punto que cambia todo. En la mayoría de instalaciones, el servidor de producción tiene credenciales para escribir en el almacén de copias, porque es él quien las envía. Suena razonable, y es exactamente la puerta.
Si el servidor puede escribir, borrar o sobrescribir en el destino, cualquier atacante que controle ese servidor hereda esa capacidad. No necesita descubrir nada más: ya tiene la llave, guardada en un fichero de configuración.
Los parches que no bastan
Cifrar las copias no resuelve esto: un atacante no necesita leerlas, le basta con borrarlas. Un segundo disco tampoco, si está montado en el mismo sistema. Y las copias en la nube con credenciales de escritura almacenadas en el servidor son igual de vulnerables que un disco local.
El modelo que sí funciona: invertir la dirección
La defensa es conceptualmente simple: que el servidor de copias vaya a buscar los datos, en lugar de que el servidor de producción los envíe.
Con ese cambio, las credenciales que existen son de solo lectura sobre tu origen, y viven en el sistema de copias, no en el servidor expuesto. Un atacante que controle tu producción puede destrozar el origen, pero no tiene ninguna ruta hacia el histórico: no tiene credenciales, y el cortafuegos impide que se abra una conexión en ese sentido.
Lo peor que puede pasar entonces es que pierdas los datos vivos, que es exactamente el escenario para el que existen las copias.
Las señales que delatan un ataque antes del rescate
Un buen sistema de copias es también un detector temprano, porque ve cosas que el administrador no mira a diario:
- La copia más reciente envejece. Si la última tiene más de 36 horas, algo dejó de funcionar y nadie se dio cuenta.
- Llegan cero bloques nuevos varios días. Los datos cifrados por un atacante cambian por completo, así que este síntoma suele indicar que la copia dejó de ejecutarse, no que no haya cambios.
- El espacio ocupado baja sin limpieza programada. Alguien está borrando histórico.
Los dos últimos son firmas clásicas de un ataque en curso, y un proveedor atento puede avisarte antes de que aparezca la nota de rescate.
Qué revisar en tu casa esta semana
Coge la configuración de tus copias y responde con honestidad: ¿tiene tu servidor de producción credenciales para modificar el destino de las copias? ¿Podría un proceso con permisos de administrador en ese servidor borrar el histórico? ¿Alguien vigila que las copias sigan llegando? ¿Cuándo restauraste algo por última vez?
Si alguna respuesta te incomoda, ya sabes por dónde empezar.
Nuestro diseño
En nuestras copias de seguridad la conexión la abrimos siempre nosotros, con credenciales de solo lectura sobre tu origen, y el cortafuegos deniega explícitamente cualquier conexión en sentido contrario. Además, la detección de fallo silencioso está incluida y vigila las tres señales de arriba. Todo dentro de dos centros de datos propios en Andorra.