La copia de seguridad olvidada en su servidor que cualquiera puede descargar

Tener una copia de seguridad es bueno. El problema empieza cuando está en el sitio equivocado.

La historia suele ser esta. Un desarrollador traslada su web a otro proveedor de alojamiento o hace cambios de cierta envergadura. Por si acaso, empaqueta todo el sitio en backup.zip, exporta la base de datos a database.sql y deja los dos archivos en la carpeta de la web para tenerlos a mano. El trabajo se termina, la web funciona y los archivos se quedan. Un año después nadie recuerda que existen.

Pero la carpeta de la web es pública. Cualquiera que conozca la dirección, o que la adivine, puede descargar con un navegador normal todo lo que haya en ella.

Lo que suele quedarse olvidado

Los hallazgos más frecuentes se parecen a estos:

• archivos comprimidos con todo el sitio, como backup.zip, site.tar.gz o www-2023.zip,
• volcados de la base de datos: dump.sql, database.sql, db_backup.sql,
• copias del archivo de configuración: wp-config.php.bak, wp-config.php.old, config.php~,
• versiones antiguas completas del sitio en carpetas llamadas old/, test/ o backup/,
• archivos comprimidos e instaladores que dejan los plugins de migración de sitios.

El más peligroso suele ser el más pequeño: una copia del archivo de configuración. El servidor ejecuta el wp-config.php original como un programa, así que nadie desde fuera puede leer su contenido. Pero para el servidor wp-config.php.bak es un simple archivo de texto, y lo entrega entero, con el nombre de la base de datos, el usuario y la contraseña.

Un volcado de la base de datos, en cambio, contiene todo lo que han recogido su tienda o sus formularios: nombres, direcciones, teléfonos, historial de pedidos, cuentas de usuario. Y una carpeta old/ contiene a menudo una copia completa y funcional del sitio de hace años, con plugins que nadie actualiza. Su web principal puede estar bien cuidada y aun así sufrir una intrusión a través de la olvidada que tiene al lado.

Por qué los bots los buscan

Nadie necesita saber que usted en concreto tiene una copia en su servidor. Hay escáneres automáticos recorriendo internet, y en cada sitio al que llegan prueban una lista de nombres habituales: /backup.zip, /site.zip, /dump.sql, /wp-config.php.bak, /.env. Es barato y rápido, así que lo hacen constantemente.

Si pide a su proveedor de alojamiento los registros de acceso del sitio, casi con seguridad verá esos intentos. En una web ordenada todos terminan en un 404, es decir, el archivo no existe. En una web con una copia olvidada, uno de ellos termina en un 200 y una descarga.

La segunda vía es Google. Si el listado de directorios está activado, al visitar sudominio.com/backup/ aparece una simple lista de archivos con el encabezado «Index of /backup». Páginas así acaban a veces en los resultados de búsqueda, y entonces cualquiera puede encontrarlas sin adivinar nada.

Lo que puede comprobar usted mismo, sin acceso al servidor

Algunas cosas llevan cinco minutos:

1. Busque en Google site:sudominio.com intitle:"index of". Si no hay resultados, es buena señal.
2. Escriba en el navegador algunas direcciones, como sudominio.com/backup.zip, sudominio.com/database.sql o sudominio.com/old/. Si empieza una descarga o ve una lista de archivos en lugar de una página de error, ya tiene la respuesta.
3. Analice el sitio con un escáner como ShieldWave, que prueba desde fuera los mismos nombres habituales que prueban los bots. La diferencia es que los resultados le llegan a usted.

Adivinar tiene un límite, eso sí. Hay cientos de nombres posibles y un desarrollador pudo llamar al archivo de cualquier manera. La única respuesta fiable la da alguien que mire los archivos en el servidor.

Cómo pedir la comprobación a su desarrollador o a su proveedor de alojamiento

No necesita los detalles técnicos. Basta un mensaje breve que pida cuatro cosas:

• comprobar que en la carpeta pública de la web (normalmente se llama public_html, www o httpdocs) no hay archivos .zip, .tar.gz, .sql, .bak u .old, ni carpetas como old, backup o test,
• mover fuera de la carpeta pública, o borrar, lo que encuentren,
• desactivar el listado de directorios si está activado,
• revisar los registros del servidor para ver si alguien descargó esos archivos.

El último punto es importante. Si alguien descargó una copia del archivo de configuración, no basta con borrarla. Hay que cambiar la contraseña de la base de datos, porque puede que alguien ya la tenga apuntada.

Si el archivo descargado contenía datos de clientes, se trata de una violación de la seguridad de los datos personales. Según el artículo 33 del RGPD, dispone entonces de 72 horas desde que tenga constancia de ella para notificarla a la autoridad de protección de datos, salvo que sea improbable que la violación suponga un riesgo para las personas afectadas. Aunque no la notifique, debe dejarla documentada.

Dónde deben estar las copias de seguridad

Una buena copia de seguridad cumple unas pocas condiciones sencillas:

• está fuera de la carpeta pública de la web, y a ser posible en otro servidor o en un servicio de almacenamiento aparte,
• se hace sola, de forma programada, y no cuando alguien se acuerda,
• se conservan varias versiones anteriores, porque una infección a menudo se descubre semanas después,
• alguien ha probado al menos una vez a restaurar el sitio a partir de ella.

Cuidado con los plugins de copias de seguridad de WordPress. Algunos guardan por defecto los archivos dentro de la carpeta de la web, por ejemplo en algún lugar de wp-content, y los protegen con un archivo .htaccess. Esa protección funciona en servidores Apache y LiteSpeed, pero un servidor nginx no lee ese archivo en absoluto. Lo más sencillo es configurar el plugin para que envíe las copias a otro lugar y no guarde una copia local.

Los administradores de sistemas hablan de la regla 3-2-1: tres copias de los datos, en dos tipos de soporte distintos, y una de ellas fuera de las instalaciones. A la web de una pequeña empresa le basta una versión más ligera: la copia que hace el proveedor de alojamiento más otra que se envía automáticamente a otro lugar. Nunca, eso sí, a una carpeta que cualquiera pueda abrir en un navegador.

Si solo va a hacer una pregunta a quien se ocupa de su web, que sea esta: ¿dónde están nuestras copias de seguridad y quién, aparte de nosotros, puede descargarlas?