Aparentemente pudimos resolver el problema de la siguiene manera.
- 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
)
--
MarioStorti - 08 Feb 2002
This topic: Main/Cimec > CrackAttackSolution
Topic revision: 08 Feb 2002, MarioStorti