Cómo unas copias de seguridad antiguas estuvieron a punto de costarle la recuperación a una agencia

La mayoría de los propietarios de sitios WordPress tienen copias de seguridad. Casi ninguno tiene copias que haya probado de verdad. La diferencia se vuelve brutalmente visible en el peor momento posible: el día en que las necesita. Este artículo describe un caso real de un incidente reciente en una agencia de Sídney, donde la historia de las copias de seguridad estuvo a punto de convertir una recuperación difícil en un cuasi desastre, y lo que cambiamos para asegurarnos de que no vuelva a ocurrir.

El incidente

La agencia gestiona una cartera de sitios de pequeñas empresas clientes en un único hosting compartido. Uno de ellos, el propio sitio de la agencia, fue comprometido. Un ataque de encubrimiento (cloaking) de SEO había dejado en silencio archivos maliciosos en la raíz del documento, imitando los nombres reales de las páginas de WordPress con contenido controlado por el atacante. La limpieza en sí fue sencilla una vez identificado el punto de entrada. La parte más difícil fue decidir hasta dónde retroceder.

El análisis forense sugería que el atacante llevaba en el sitio al menos unas semanas antes del descubrimiento. Por precaución, el plan de recuperación exigía restaurar desde una copia de seguridad tomada antes de la fecha de entrada sospechada. Cuanto más limpia fuera la línea base previa al incidente, menor sería la probabilidad de que alguna puerta trasera sutil sobreviviera a la limpieza.

La primera sorpresa

El plugin de copias de seguridad se había instalado y configurado en el lanzamiento del sitio, dos años antes. El plan era copias diarias de la base de datos y copias completas semanales, ambas subidas a una cuenta de almacenamiento en la nube externa. Cuando el propietario de la agencia fue a recuperar una copia de seis semanas antes del incidente, la respuesta fue incómoda: la copia más reciente en el almacenamiento en la nube era de hacía doce meses.

El plugin de copias de seguridad llevaba fallando en silencio al menos el último año. La agencia no tenía ni idea. Las notificaciones sobre los fallos se estaban enviando a una dirección de correo que ya no se supervisaba. A nadie se le había ocurrido comprobar el almacenamiento de destino para confirmar que los archivos llegaban de verdad. El sistema llevaba roto en silencio mucho más tiempo que el propio incidente de seguridad.

La segunda sorpresa

La agencia recurrió al proveedor de hosting como alternativa. Muchos hosts gestionados conservan sus propias copias de seguridad, independientes de cualquier plugin. En este caso, la retención de copias del host era de 30 días. Se sospechaba que la brecha había comenzado unos 45 días antes del descubrimiento. Las copias del host estaban dentro de la ventana del compromiso, no antes de ella.

Cualquier copia que el host pudiera proporcionar tenía muchas probabilidades de contener los archivos del atacante. Restaurar desde ellas simplemente reiniciaría el reloj. No había ningún punto limpio previo al incidente al que restaurar.

La vía de recuperación que funcionó

Sin ninguna copia limpia, la recuperación tuvo que hacerse archivo por archivo. La instantánea forense del sitio actual se comparó con una descarga fresca del núcleo de WordPress, los archivos del tema se verificaron contra el control de versiones donde existía, los plugins se reinstalaron desde sus fuentes oficiales en lugar de reutilizarse del código comprometido, y la base de datos se depuró de patrones maliciosos conocidos sin revertirla.

Esto llevó varias veces más tiempo que una restauración simple. Cada paso tuvo que verificarse. El coste total fue considerable, y se perdieron varias mejoras del sitio porque el código de tema verificable más reciente procedía de una exportación de hacía meses en lugar del estado en vivo. La limpieza funcionó, pero el coste fue muy superior al que debería haber sido.

El nuevo esquema de copias de seguridad

Tras el incidente, la agencia adoptó un esquema de copias de seguridad que usamos en los sitios WordPress que gestionamos. Las características importan, así que conviene ser específicos.

Copias incrementales diarias tanto de archivos como de base de datos. Copias completas semanales. Todas las copias almacenadas fuera del sitio, en una cuenta de almacenamiento que no es accesible desde el propio sitio WordPress, de modo que un compromiso no pueda borrar las copias junto con el sitio en vivo.

La retención está configurada para que las copias sigan disponibles durante al menos 90 días. Esto proporciona una ventana limpia previa al incidente incluso para compromisos de combustión lenta.

Las notificaciones de alerta por copias fallidas van a una bandeja de entrada corporativa supervisada, no a un correo personal. Dos personas reciben las alertas, para que las vacaciones de una sola persona no puedan enmascarar un fallo.

Una prueba de restauración trimestral se ejecuta contra un entorno de staging. La copia se descarga, se restaura y se verifica contra el sitio en vivo. Si algo está roto, se arregla antes del siguiente trimestre.

Qué puedes hacer hoy

Si este caso te resulta incómodamente familiar, aquí tienes una breve lista de pasos que puedes recorrer esta semana. Cada uno lleva minutos.

Inicia sesión en el destino al que van tus copias de seguridad, sea cual sea. Confirma que el archivo más reciente es de hoy o de ayer. Confirma que los archivos han estado llegando de forma constante durante los últimos 90 días. Abre la dirección de correo que debería recibir las notificaciones de fallos de copia y confirma que sigue supervisada.

Elige la copia más reciente. Descárgala. Intenta restaurarla en un sitio de staging o en un entorno local. Asegúrate de que realmente funciona como copia de seguridad, no solo como archivo.

Comprueba la retención de copias de tu host. ¿Es la ventana de retención lo bastante larga para cubrir un compromiso lento? Si no, complétala con una solución externa de retención más larga.

El principio

Una copia de seguridad solo es real una vez que la has restaurado. Hasta entonces es una conjetura. El coste de probarla es pequeño. El coste de descubrirlo por las malas es lo bastante grande como para amenazar la propia recuperación. Trata la verificación de copias como parte de tu rutina, no como algo a lo que llegarías algún día.

¿Necesitas ayuda?

Si tu esquema de copias de seguridad de WordPress tiene lagunas, en Defyn podemos auditarlo, configurar copias externas fiables con la retención adecuada, ejecutar una prueba de restauración para verificar que funciona y asegurarnos de que las alertas lleguen a personas que las vean. Ponte en contacto y te daremos un esquema de copias en el que puedas confiar de verdad.