Ahora, paso por paso, intentaremos instalar la aplicación The Coroners Toolkit, que nos servirá para recoger la información sobre el sistema de ficheros y analizarla. La herramienta no es un ejecutable que realiza todas las tareas, sino es una colección de utilidades diseñadas para efectuar una tarea determinada, siendo importante entender el funcionamiento de cada una de ellas para poder entender la función del toolkit en su totalidad.
* El primer paso es de desempaquetar el archivo tct-1.09.tar.gz y copiarlo al directorio /usr/local/tct-1.09, luego debemos leer detenidamente el fichero de instrucciones de instalación INSTALL.
La instalación de la aplicación debe ser realizada en una partición donde haya mucho espacio ya que algunas aplicaciones suelen generar una cantidad grande de información de salida por ejemplo unrm y lazarus.
* Ahora reconfiguremos los scripts utilizando perl reconfig, ya que TCT utiliza
rutas completas.
* Limpiamos bien la distribución con un make clean; make all.
* Leemos documentación del directorio docs/ para conocer los detalles
de funcionamiento del Toolkit.
# ls -l docs total 34 -rw-r--r-- 1 root root 8572 Mar 28 12:41 README -rw-r--r-- 1 root root 7162 Mar 28 12:39 grave-robber.README -rw-r--r-- 1 root root 13944 Jan 16 13:34 lazarus.README -rw-r--r-- 1 root root 2830 Mar 27 15:07 mac.README
* Montamos la partición que debemos analizar en modo solo lectura y nodev, bajo algún punto de montura.
# mount -r /dev/hdd2 /mnt
* Suponiendo que siendo root arrancamos la aplicación grave-robber para que empiece a analizar el sistema de ficheros y procesos y guardar los datos de los inodes en el fichero data/activalink.com/base y data/activalink.com/base.S (binarios sUID), el estado del sistema en el directorio data/activalink.com/command_out/ etc...
# bin/grave-robber -m /mnt
Grave-robber, inicialmente realizará un análisis de todas las carpetas que están en el $PATH y a continuación empezará a analizar la partición montada /mnt. El análisis suele tardar bastante tiempo, según el tamaño de la partición que queremos analizar. Aparte de los inodes se guarda el estado general del sistema, es decir el output de las herramientas de monitorización del sistema como ps, top, w etc.
* Una vez terminado el trabajo del grave-robber, copiamos los ficheros passwd y group del sistema comprometido al directorio tct-1.09/ para que los tengamos a mano ya que en breve estaremos analizándolos. Para que se pueda distinguirlos luego renombramos estos ficheros passwd.victim o utilicemos el nombre del host comprometido.
* Ejecutamos luego la utilidad mactime especificando una fecha anterior del compromiso (consideremos que la actividad del intruso ha acabado hoy, pero no vamos a especificar hora). Necesitaremos pasar los resultados de ejecución de mactime a un fichero para que luego se pueda examinar su contenido con tranquilidad:
# bin/mactime -p passwd.victim -g group.victim /mnt 06/01/2000 > victim.mactime
En la utilidad mactime hubo un bug en las versiones anteriores que hacía que la aplicación no funcione correctamente si se utilizaba la opción -p. Entonces hacíamos un "work around", incorporando temporalmente el contenido del fichero /etc/passwd de la máquina víctima coincidir con él de nuestro sistema. En la versión actual este bug está solucionado.
* Hacemos una copia del fichero antes de empezar el análisis:
# cp victim.mactime victim.mactime.evidence
* Entonces podemos empezar analizando el fichero victim.mactime.evidence. Usando el editor de texto favorito, empecemos a revisarlo y marcar la actividad sospechosa. Sugiero que pongamos los tags [MARK] para que luego con grep podamos localizar nuestros apuntes.
. . . Feb 13 2000 01:10:50 50148 mca -rwxr-xr-x root root /x/dev/. Feb 13 2000 01:10:52 564 m.c -rw-r--r-- root root /x/etc/profile Feb 13 2000 01:11:00 5 mac -rw-r--r-- root root /x/lib/sp 18110 .a. -rw-r--r-- root root /x/lib/tp [MARK] Feb 13 2000 01:12:08 0 ..c -rw-r--r-- root root /x/dev/ttyag 25 ..c -rwxr-xr-x root root /x/dev/ttyfg 23 ..c -rwxr-xr-x root root /x/dev/ttypg 373176 ..c -rws--x--x root root /x/lib/... 8268 ..c -rwxr-xr-x root root /x/lib/go 20164 ..c -rwsr-xr-x root root /x/usr/bin/xcat 183780 ..c -rwxr-xr-x root root /x/usr/sbin/find Feb 13 2000 01:30:00 8268 .a. -rwxr-xr-x root root /x/lib/go Feb 14 2000 10:42:03 1166856 .a. -rw-r--r-- root root /x/var/log/boot.log [MARK] Feb 14 2000 10:45:35 18110 m.c -rw-r--r-- root root /x/lib/tp Feb 14 2000 10:57:42 2998 m.c -rw-r--r-- root root /x/etc/inetd.conf~ Feb 14 2000 11:01:47 168 .a. -rw-rw-r-- root root /x/root/.saves-1380-dragon~ Feb 14 2000 11:18:38 160 m.c -rw-r--r-- root root /x/etc/hosts.allow.old Feb 14 2000 11:18:55 347 m.c -rw-r--r-- root root /x/etc/hosts.deny.old Feb 14 2000 11:19:08 8 m.c -rw-r--r-- root root /x/etc/hosts.deny Feb 14 2000 11:22:53 168 m.c -rw-rw-r-- root root /x/root/.saves-1380-dragon~ Feb 14 2000 11:30:30 2998 .a. -rw-r--r-- root root /x/etc/inetd.conf~ [MARK] Feb 14 2000 11:31:25 20164 .a. -rwsr-xr-x root root /x/usr/bin/xcat Feb 14 2000 11:34:10 868 m.c -rwxr-xr-x root root /x/etc/rc.d/rc.local . . .
* Después de repasar todo el listado de cambios históricos, puede que tengamos alguna pista para seguir o puede que no. En el peor de los casos debemos modificar la fecha especificada y cambiarla a la anterior del compromiso, intentándolo de nuevo, o mirar más detenidamente. Durante el examen del documento se prohibe distraerse ya que la concentración es muy importante en este momento.
* Otra opción es recuperar ficheros borrados con el la utilidad unrm y luego examinarlos con el programa strings. Las dos utilidades unrm y lazarus generan muchísima información y debemos tener bastante espacio libre en la partición. Podemos determinar la cantidad de espacio en disco duro que necesitamos, calculando de forma aproximada a partir del informe de df.
# df /mnt Filesystem 1k-blocks Used Available Use% Mounted on /dev/hdb2 3028881 1604551 1267697 56% /mnt
En nuestro ejemplo df muestra que tenemos 1267697 bloques sin ocupar, que significa que unrm puede llegar a generar aproximadamente 1.2 Gb de información. Encontremos una partición libre y almacenemos allí el dump (Importante: en el ejemplo utilizo el punto de montura del sistema comprometido y no del sistema de análisis):
# bin/unrm /dev/hdb2 > /data/victim.hda2.unrm
* Pero si disponemos de más espacio (más de 1.2Gb) y mucho más tiempo para practicar con lazarus que procesará el espacio libre en el disco duro y intentará recuperar ficheros por sus tipos. lazarus genera una salida en formato HTML, que nos va a dar la oportunidad de verla a través del navegador.
[Subir]