Hace unos días un compañero de profesión me llamaba todo tenso para contarme cómo a una semana de la entrega de una página a un cliente, el que en ese momento les estaba desarrollando la web les estaba dando muchísimos problemas.
El hombre estaba de los nervios, ya que a fin de cuentas el proyecto era para uno de sus clientes principales. Y de no salir, pues lo normal es que se cayera, con todo lo que ello conllevaba.
La idea era tener una alternativa en caso de que en efecto las negociaciones no salieran. Me comentó la situación, y le avisé que justo ese fin de semana estaba de viaje, por lo que en caso de necesitar con urgencia heredar el proyecto quizás se lo tuviera que pasar a otra persona de confianza.
No estábamos aún en esa tesitura, pero en la noche del domingo, ya por Madrid, podría hacerme cargo sin problemas. Así que quedamos en que me iría contando cómo evolucionaba el tema.
Y el tema, como supongo habrás deducido por el título de esta entrada, evolucionó mal.
El domingo, dos días después de la conversación, este trabajador ya no estaba en el equipo. Pero antes de irse había decidido eliminar todo el trabajo hecho hasta el momento. Es decir, adiós servidor, adiós base de datos, adiós creatividades.
Que oye, como le comenté era un putadón, pero aún a malas podíamos empezarlo de cero con todo el conocimiento de los últimos meses de trabajo. De todas formas quería primero revisar cómo estaba el servidor, por si se podía recuperar algo.
Es aquí a donde quería llegar.
¿Qué hacer cuando somos conscientes de que hemos tenido un acceso potencialmente dañino?
El primer paso en el momento en el que queremos recuperar contenido que se ha borrado de un servidor (sea inconsciente o conscientemente) es, por supuesto, asegurarnos de que el causante no pueda volver a acceder.
Y eso compete a varios potenciales accesos. A saber:
- Cuenta de acceso al servidor: Por razones obvias habrá que cambiar la contraseña.
- Email asociado a la cuenta de acceso al servidor: No siempre puede haber quedado expuesto, pero es bueno revisar si en efecto en algún momento ese trabajador estuvo dentro.
- Email y cuenta de la web/servicios utilizados: En este caso, y como decía, todo había sido eliminado, así que por ahora no había problema en este sentido.
- Bases de datos: Si hay alguna creada y si puede haber sido expuesta. No era el caso por la misma razón que antes.
- Cuentas FTP/SSH: Es muy habitual que la gente que trabajamos con servidores nos creemos una cuenta para acceder mediante FTP o SSH al servidor. En este caso sí había aún una cuenta de este trabajador que por supuesto borramos.
Las copias de seguridad son nuestras amigas
No me cansaré de decirlo. El contar con un timing de copias de seguridad periódico y claro nos puede salvar la vida. Y en el caso de mi compañero, fue así.
El extrabajador había borrado todo el proyecto del cliente, pero el servidor, alojado en una empresa de hosting barato (ES), contaba afortunadamente con un sistema de backup diario en uso. Backup que además incluía archivos y bases de datos.
El fin de semana mi compañero intentó activarlas (no tiene perfil técnico), pero al ver yo el domingo de noche que la web seguía inoperativa, me puse manos a la obra. Una hora más tarde la web ya estaba disponible tal cual había quedado la última vez.
Ahora tocaba, nuevamente, revisar los permisos/cuentas creadas. Cambié incluso la de la base de datos por evitar problemas futuros. Y al ponerme con el WordPress se dio una situación que me ha parecido lo suficientemente interesante como para escribir esta pieza.
¿Cómo acceder a un WordPress sin tener acceso al correo ni conocer la contraseña?
En el caso que nos compete, estábamos delante de una web que había sido creada con el correo del cliente final (ergo, no tenemos acceso al mismo sin molestarle), y cuyo usuario/contraseña administrador había sido creado por el ex-trabajador.
Revisando la base de datos podemos conocer el usuario. Pero la contraseña en WordPress, y afortunadamente en la mayoría de CMS, se guarda cifrada.
Probé a descifrarla (sabía que era MD5) mediante un servicio online, pero por el propio formato de MD5 no fue posible.
Y aquí viene lo bueno.
Podemos en efecto intentar recuperar la contraseña desde el administrador de WordPress (o el CMS que utilicemos), pero para ello tendríamos que avisar al cliente de que nos reenviara el correo que le iba a llegar. Y recuerdo que estábamos a domingo por la noche.
Sin embargo, es posible cambiar la pass directamente desde MySQL (o el proveedor de base de datos que utilicemos), editando la fila de la tabla WP-USER (o el nombre de la tabla de usuarios en el CMS que utilicemos) para que tenga el usuario que queramos, y la contraseña cifrada con la función que deseemos (en el caso de WP, es MD5).
Nosotros escribimos la contraseña que queramos, que ya se encarga MySQL de hacer la conversión y grabarla en la BD de forma cifrada.
Seguramente para los sysadmin que estéis leyendo esto os parecerá una soberana tontería. Algo obvio, de hecho.
Pero es que no es la primera vez que alguien me pregunta cómo recuperar acceso a su web sin tener el correo (lo típico de que esa web la creaste en su día con un correo que ya ni recuerdas o que ya no usas). Si tienes acceso al servidor, tienes la capacidad de recuperar el acceso a todo, aunque en algunos casos, como es acceder a un servicio instalado dentro del servidor, la forma de llegar a ello sea algo más enrevesada.
Y ya de paso, sobra decir que por el medio me he encontrado bastantes más problemas que los que he comentado por aquí. Sin ir más lejos, la copia de seguridad en efecto recuperó todo el contenido, pero la base de datos estaba corrupta, teniendo que a mano solventar los errores que daba.
Una tarde/noche de trabajo para dejarlo todo perfecto, y que al menos mi compañero de cara al cliente pudiera explicarle la situación con final feliz (hemos tenido este problema pero ya está solucionado), y manteniendo, de paso, el proyecto.
Ains, qué difícil a veces es esto de las relaciones profesionales… :).
________
¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?
Revisa mi setup de trabajo, viaje y juego (ES).
Y si el contenido que realizo te sirve para estar actualizado en tu día a día, piensa si te merece la pena entrar en el Club Negocios Seguros y aprovecharte de todo el contenido exclusivo que publico para los miembros.
Interesante solución, desconocía que se podía hacer así.
Otra opción sería cambiar el campo user_email de la misma tabla y poner uno al que tengamos acceso, una vez solicitado el cambio de contraseña y generado la nueva volvemos a poner el email que había en el campo indicado y como si no hubiera pasado nada.
También. Muy cierto Daniel.
¡Gracias por la sugerencia!
Saludos.
Hola algo parecido me a sucedido a pesar que soy informático el inconveniente que se me presenta es que en esta área mis conocimientos son bajos y se que la falla presentada es vaga.
Tendrías una forma de ayudarme.
Claro Apache. Respóndeme al mail que te va a llegar con esta respuesta y lo hablamos con más calma.