Lo primero me gustaría pedir disculpas por las inconveniencias producidas por el tiempo en el que Fuji ha estado de baja. Es una pena, sobre todo, por la gente que había iniciado Blogs, y que debido al tiempo de inactividad lo han ido dejando! LO SIENTO!!!!
El motivo por el que Fuji fue hackedo fue el cambio temporal de la password de administrador a “1234”. El motivo del cambio fue debido a la vaquería de introducir la antigua password real durante múltiples ocasiones en breves periodos de tiempo. En ese momento en particular, yo (miggs, administrador del servidor) y un amigo estábamos montando un servidor Proxy (Squid) con el fin se conseguir Internet gratis en la residencia (aquí en Australia cobran por Mb, lo cual me parece tercermundista). El hecho de cambiar la password no tiene excusa, pero en el momento parecía lo mas rápido y eficiente. Dicho periodo de pruebas nos llevo un par de días. Durante los cuales alguien ejecuto un “dictionary attack” sobre el puerto 22 (ssh), consiguiendo privilegios de admin (”1234″ es una de las contraseñas que siempre se prueban en este tipo de ataques). Una vez dentro, el script en cuestión descargo e instalo un par de rootkits dejando a Fuji en estado zombi.
Afortunadamente, dicho ataque reseteaba algunos parámetros del sistema, haciéndolo funcionar de una manera sospechosa. Un análisis inicial a los logs de acceso delataba el intento de alguien de intentar acceder al servidor vía ssh probando suerte con las passwords mas comunes…, hasta que dio con la password correcta.
Una vez descubierta la procedencia, lo siguiente que había que descubrir es que había hecho. Afortunadamente, el ataque no borro el rastro en los logs y conseguimos recuperar la secuencia de comandos que se habían ejecutado, (ahora no los tengo a mano pero si os interesa los puedo publicar). Básicamente el ataque consistía en descargar una serie de archivos de una ftp en geocities y ejecutarlos. Una vez ejecutados el scrpit se desconectaba dejando al ordenador en estado zombi.
Una vez averiguado que el éxito del ataque había sido mera casualidad, y no un ataque “directo”, procedimos a analizar el ordenador en busca de rootkits a lo cual obtuvimos múltiples positivos. Ante dicha evidencia no quedaba otra alternativa que formatear el equipo. Así que hicimos un backup y apagamos el equipo (Aun guardo una copia del equipo infectado por si el FBI se presenta en mi casa)
Desgraciadamente, el no encontrarme físicamente en el mismo país que el servidor, el cual esta en mi casa (Madrid), y yo estoy en Australia, complico las tareas de restauración. Además para complicar todavía más el tema en esa época yo iniciaba los finales.
Durante el periodo en el que el servidor estuvo de baja, Chris; amigo, administrador de la red del colegio, y actual coordinador del grupo de usuarios de Linux de Canberra, me comento la posibilidad de usar algún tipo de sistema de virtualización con el que en caso de perder el control sobre el sistema, pudiera hacerme con el control del equipo (vamos, usar VMWare, pero el linux).
Siguiendo sus recomendaciones me decante por Xen. Odio decirlo así, pero es la única manera de que mucha gente se entere. Xen es como VMWare pero en Open Source y para Linux. Xen es la leche, además de que todo se configura por consola, hacerlo funcionar es relativamente sencillo. En Howtoforge hay tutórales muy majos.
Bueno, después de un par de días de pruebas en mi ordenador personal, donde conseguí hacerme con las nociones básicas de cómo funciona y como configurarlo, decidí que era el momento de pasarlo a producción.
Llego el momento, contacte con mi padre y acordamos cuando podía llamarle para iniciar el proceso de restauración, la verdad es que le estoy muy agradecido por todas las horas que ha estado colgado al teléfono ayudándome a solucionar el problema (GRACIAS PAPA!).
Una vez instalado el “sistema base”, (gracias ubuntu por funcionar tan bien!). La instalación de Xen no fue complicada gracias a este tutorial. Lo que ya no fue tan sencillo fue la restauración del resto del sistema; datos de usuario, configuraciones, scripts, BBDD. Pero bueno, mirando el lado positivo, gracias a ello hoy entiendo mucho mejor la importancia y uso del concepto de usuario y grupo, así como los permisos de ficheros
Un mes después del ataque todo estaba listo de nuevo. A día de hoy, si algo similar volviese a pasar la restauración del sistema tardaría como máximo unas horas.
Me gustaría de nuevo disculparme a los todos los afectados por el problema, en especial CDC, Game.
Por ultimo, agradecer a Chris y a mi padre todo el apoyo y horas que han dedicado al proyecto desinteresadamente. GRACIAS! También como resaltar que este incidente no ha hecho más que educarme en temas de seguridad y restauración de sistemas, así como aumentar todavía más mis ganas motivación de seguir adelante con este proyecto.
Miggs
Moraleja: NO JUGAR CON EQUIPOS EN PRODUCCION!
