El problema del abandono de una página web

Este blog lleva online poco más de tres años. En este tiempo tanto el blog, como su autor, aquí presente, han pasado por varias etapas de dedicación y abandono a lo largo de estos años.

Como todo en un principio, se toma con ganas de dedicarle unas cuantas horas, pero estas ganas se van desvaneciendo hasta que se llega a un equilibrio entre ganas y dejadez; pero no nos entretengamos más en tonterías.

Por motivos de estudios y trabajo, dejé de escribir en el blog de forma regular; podría decirse que lo abandoné al 75%, porque he seguido entrando todos los días para aprobar y responder comentarios, hacer copias de seguridad y mantener al día el software sobre el que corre. Aun así, y pese a este periodo abandono de más de un año, las visitas sólo decrecieron en un par de años de 500 diarias a 300 diarias y siendo constantemente enlazado desde otros medios.

Pero la dejadez no perdona, y parece que la gente se da cuenta. Esto hizo que el blog fuese atacado y crackeado debido a una mala configuración en los permisos de una carpeta (hoy en día sigue siendo el punto de mira de una serie de ataques por fuerza bruta). Esta pequeña incursión no autorizada es la que quiero comentaros hoy en este artículo.

La carpeta imágenes tenía los permisos 777 (aun no sé si este fue el descuido o la tardía actualización del software de este CMS), es decir, todo el mundo podía leer, escribir y ejecutar; primer gran error. Aun así, no tenía consciencia de esta debilidad hasta que me llegó una carta de una agencia de protección de datos diciendo que estaba infringiendo las leyes de Copy Right al alojar unos artículos de una universidad. Rápidamente borré estos ficheros (que se encontraban dentro de una carpeta wpbuzz) que yo no había subido y le cambié los permisos a las carpetas que estaban mal configuradas. Hasta aquí todo bien, no parecía más que un susto; pero aun así, subí de nuevo los ficheros del blog, cambié todas las contraseñas,… en fin,… todas esas cosas que se suelen recomendar cuando has sufrido un ataque de este estilo.

La gran sorpresa vino cuando dos días después vuelvo a recibir una carta en la que me notifican que vuelvo a tener estos archivos alojados. «Jo***» es lo primero que pienso. Me dedico a analizar meticulosamente los logs de acceso al servidor por todas las vias posibles: no había nada raro. ¿Qué podía estar pasando?

Tras un rato de darle vueltas al tema, llego a la conclusión que tiene que haber algo raro, algo que iba más allá de los ficheros que borré. Media hora después, empiezo a ver cosas raras en el sistema de ficheros. ¿qué hacían ficheros .tar en la carpeta de imágenes?, ¿funciones eval con códigos en hexa dentro de los fuentes de wordpress? Efectivamente, sospecha confirmada, esos archivos comprimidos tenían todos los archivos que violaban la propiedad intelectual y por los que me habían dado un toque. ¡Ficheros fuera!

Si estos ficheros se han descomprimido varias veces, es porque hay código que se ejecuta y que no pertenece al código original de WordPress. Tras investigar un rato encontré un código de php con mala pinta; tras borrar este archivo y unas cuantas imágenes que en teoría estaban corruptas y me dirigí al Fórum Impulsa 2012 con un portátil bajo el brazo por si acaso había que ponerse a trabajar para arreglar el problema.

Dos días después, vuelve a aparecer la maldita carpeta wpbuzz.

Sigo con la investigación por tierra mar y aire; esta vez toca analizar plugins y base de datos. En los plugins parece no haber nada raro, las carpetas tenían los permisos correctos y no había ningún archivo con código que fuese claramente sospechoso. En cuanto a la base de datos, se me volvió inabarcable el hecho de analizarla detenidamente, ya que con el trabajo no he podido dedicarle el tiempo que ello requería; estaba en un camino sin salida.

Tras darle unas cuantas vueltas decidí hacer lo que hago con el ordenador como mínimo una vez al año como tarea básica de mantenimiento: reinstalarlo todo de cero. Pero esto suponía otro problema, y es que si la backdoor estaba en la base de datos, el problema no se solucionaría y habría perdido una serie de horas que no podía permitirme el lujo de perder.

Finalmente, y tras unas horas de darle vueltas a la cabeza y probar varios programas de backup, decidí probar el que trae preinstalado WordPress y que nos permite exportar nuestro contenido en un XML con la finalidad de poder mover los artículos entre plataformas; estos datos, al fin, parecían estar limpios.

En conclusión:

• Hay que vigilar los permisos de las carpetas de nuestro servidor y configurarlas correctamente.
• Hay que mantener el software actualizado siempre.
• La solución estaba frente a mis narices y no me di cuenta por no ir primero a lo simple