• Recuperamos todo el filesystem / de un archivo tar que teniamos. Este tar era del 31/8 y todavia le faltaban algunas cosas para llegar al estado actual, fundamentalmente el cambio de los IP de 10.0.0.1 a 10.20.70.10x

• Reinstalamos ton rpm todos los paquetes que reportaban binarios modificados en /bin, /sbin, /usr/bin, /usr/sbin y otros...

• Verificamos con rpm -Va que no hubiera ningun binario infectado. Algunos binarios de samba y de pvm no los pudimos recuperar ni desinstalar los paquetes asi que directamente borramos los binarios.

• En este punto teniamos al cluster en un estado equivalente al 31/8. Para recuperar el estado actual con el minimo esfuerzo recuperamos los directorios /etc y /root de los craqkeados verificando que no hubiera ningun binario adentro. Haciendo un diff detectamos que el /etc/rc.ed/rc.sysinit habia sido tocado y lanzaba una especie de daemon /usr/sbin/xntps Buscando en los newsgroups encontramos que esto habia sido reportado en comp.os.linux security (ver CompOsLinuxSecurityPosting). Borramos las lineas agregadas al /etc/rc.ed/rc.sysinit y el archivo /usr/sbin/xntps Buscando los archivos de la misma fecha que el xntps detectamos que el /usr/sbin/lsof tambien era un crack. Notar que estos archivos habian sido reportados en el posting.

Conclusiones

• Es importante guardar siempre copias del /etc y del /root (el adcn, crea_nodos, y setup_template ) que contienen la mayor cantidad de informacion relativa al cluster. Pensamos que, ante cualquier eventualidad, si uno tiene una copia de estos directorios, basta con instalarlos sobre una instalacion de Linux mas o menos compatible para recuperar la funcionalidad del cluster.

• Proponemos escribir un script que guarde la informacion reportada por rpm -Va y reporte cambios al administrador (nombre probable: rpm_cop )