Esté analizando el sistema con las herramientas forenses específicas o no se debe de seguir los mismos pasos básicos siempre para prepararse para el análisis completo del sistema.
* En algunos casos es necesario fotografiar el equipo afectado antes de mover cualquier detalle del mismo. Eso puede ser necesario como prueba del incidente en casos que posiblemente pueden acabar en una sala de juicio. En otros casos será necesario documentar los detalles de todos los componentes del sistema como valores ID de los dispositivos SCSI, por ejemplo y etc.
* Empezar haciendo apuntes detallados en el cuaderno. Teniendo bien detallados apuntes con la fecha y hora del inicio y fin de cualquier trabajo realizado será muy útil durante y al final del análisis. Es importante todos los hechos pertinentes al caso durante la preparación, recuperación y análisis de las pruebas sobre un ataque. Estas notas servirán como base para poder desarrollar un informe detallado de incidencia que se debe preparar una vez terminado el análisis. Este documento deberá servir como una prueba del incidente o compromiso. Siempre que se realiza cualquier apunte al cuaderno, el asistente debe tener completo conocimiento y entendimiento de lo que ha sido apuntado.
* Antes de apagar el sistema, será útil recoger algunos ejemplos de aquella información que posiblemente no ha sido cambiada por los intrusos, como la organización de sistema de ficheros de /etc/fstab, el nombre del host, su dirección IP del fichero /etc/hosts y información de algunos dispositivos desde los ficheros /var/log/dmesg o ficheros de log de sistema /var/log/messages. Esa información normalmente va a caber en un disco 1.44 de forma comprimida con tar.gz. Si no quiere o no puede extraer esa información en este paso, en los siguientes pasos eso será más dificil.
Ejemplo:
# cd / # tar -cvzf /dev/fd0 etc/hosts etc/fstab var/log/dmesg var/log/messages etc/hosts etc/fstab var/log/dmesg var/log/messages
* ¡Haga 3 imágenes del disco duro entero y trabaje con copias, y no con el original! En el peor caso que tenga que trabajar con el disco original correría el riesgo de hacer una pequeña equivocación que eliminaría las huellas de forma parcial o total. El original debe ser almacenado en una caja fuerte para estar totalmente seguros que el contenido del dispositivo no esté alterado o eliminado. Para ello generaríamos verificaciones de integridad MD5, las imprimiremos en etiquetas y éstas las pegaremos en el original y en las copias. La etiqueta del original debe contener la fecha y hora de extracción del disco del sistema comprometido, y la fecha y hora de almacenamiento del disco en la caja fuerte. Las etiquetas de las 3 copias deben tener letras de alfabeto griego (como ejemplo). A continuación están detalladas todas estas tareas:
a. El disco original debe ser conectado al controladora IDE sin utilizar y el sistema debe ser arrancada después. Se debe tener mucho cuidado para no dañar el disco en caso de conflictos master-slave en el controlador IDE, etc. Es por ello que, insistía anteriormente en tener 2 controladoras IDE para evitar este tipo de problemas; es decir que es muy conveniente tener un único disco duro conectado a la segunda interfaz IDE (si tiene conectado un CD-ROM en la segunda interfaz de IDE, se debe quitar de forma temporal).
Puede ser que sea necesario modificar las opciones de detección automática de la geometría de discos en los ajustes BIOS (Los pasos deben ser apuntados siempre para poder volver al estado anterior si se comete cualquier error).
b. Las particiones del disco duro deben ser identificadas con el programa fdisk. Nunca se debe utilizar fdisk en modo interactivo, ya que se arriesga que la tabla de particiones existente o las etiquetas se modifiquen (fdisk es un programa i386 GNU/Linux, modelado a partir de su equivalente de DOS).
Ejemplo: # fdisk -l /dev/hdd
Disk /dev/hdd: 255 heads, 63 sectors, 1575 cylinders Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System /dev/hdd1 * 1 869 6980211 b Win95 FAT32 /dev/hdd2 870 1022 1228972+ 83 Linux /dev/hdd3 1023 1035 104422+ 82 Linux swap /dev/hdd4 1036 1575 4337550 83 Linux
A partir de este listado podemos sacar una buena conclusión que la partición /dev/hdd2 era partición root, y /dev/hdd4 era algo parecido a /usr o /home. No puede decir cual de las dos es en este paso, pero se puede ver el fichero salvado /etc/fstab, o alternativamente montarla partición y examinar su contenido.
En caso de que hayamos hecho una imagen de la partición, debemos restaurarla para su estudio posterior.
c. Se generan los checksums de integridad de particiones con MD5 del disco original y sus imágenes para verificar si coinciden.
Nota: Asumimos que tenemos un dispositivo de cinta en /dev/st0 y el dispositivo "non-rewind" está en /dev/nst0. El tamaño del bloque, normalmente 512 bytes, puede que no sea el valor más eficaz para su dispositivo de cintas. Consulte la documentación de su dispositivo y determine el factor óptimo (frecuentemente entre 8198 y 32767).
Los siguientes ejemplos utilizarán el valor por defecto para evitar complicaciones.
El comando mt se utiliza para saltar volver atrás de un fichero para luego verificar su checksum MD5. Hay que estar seguro que se utiliza dispositivo "non-rewind" ya que a la hora de saltar de una imagen de fichero a otra podríamos sobrescribir información sobre la cinta y perder información. También hay que asegurarse que no hacemos ningún error con parámetros if= y of= - opciones del comando dd ya que podrá destruir información sobre el disco con facilidad. (Ver man mt y man dd, luego practique escribiendo/leyendo múltiples ficheros a/de la cinta antes de hacer cualquier acción con los datos importantes.)
Ejemplo: # date Mon Jun 19 12:00:22 PDT 2000
# md5sum /dev/hdd2 7b8af7b2224f0497da808414272e7af4 /dev/hdd2
# mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN
# dd if=/dev/hdd2 of=/dev/nst0 2457944+0 records in 2457944+0 records out
# mt bsf 1
# dd if=/dev/st0 | md5sum 2457944+0 records in 2457944+0 records out 7b8af7b2224f0497da808414272e7af4 -
# mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)). Soft error count since last status=0 General status bits on (81010000): EOF ONLINE IM_REP_EN
Marque la cinta y márquela con una etiqueta que contiene, nombre del sistema comprometido, particiones y correspondientes MD5, sus iniciales y la fecha.
A la hora de verificar los MD5 del disco y de la/s cintas si al menos un único byte ha sido modificado a la hora de realizar la duplicación o backup, el checksum no coincidirá. Eso puede estar causado por un sector dañado en el disco duro o en la cinta, puede que haya hecho una copia del sistema "vivo" (no montado read-only), o haya hecho la copia de una partición incorrecta.
Intente utilizar otra cinta. Pruebe también regenerar el MD5 checksum del disco/partición. Haga lo que haga no intente re-formatear, analizar, arreglar el disco original ya que todas esas acciones alterarán la información del disco.
Puede ser que necesite servicios de una empresa especializada en recuperación de datos que puede migrar en tiempo real los datos del disco y determinar que sector exactamente está dañado y arreglarlo de forma segura. Ojo, siempre que entrega una cinta/disco a las empresas de recuperación de datos, aseguren la información con una aseguradora por el valor aproximado de daños causados. Si es la cinta o el dispositivo de cinta que está fallando, pues se debe adquirir un dispositivo/cinta nuevo/a ya que no podrá seguir trabajando con hardware estropeado.
d. Si se está guardando más de una partición en la cinta, hay que asegurarse que se utiliza el dispositivo non-rewind para cada partición, entonces se usa mt rewind o simplemente se saca la cinta, lo que causará que se rebobine. Ahora es cuando debe habilitar la protección de escritura de la cinta ya que no queremos que de forma accidental se sobrescriba la información. Una vez que vuelva a meter la cinta en el dispositivo se debe comprobar que la protección contra escritura está funcionando correctamente utilizando el comando mt. El siguiente ejemplo muestra el estado de una cinta protegida contra escritura, posicionada en el punto BOT y el primer fichero está marcado como #0.
# mt status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)). Soft error count since last status=0 General status bits on (45010000): BOT WR_PROT ONLINE IM_REP_EN
Mientras que el siguiente ejemplo muestra el estado de una cinta sin protección contra escritura y el fin de 2º fichero en la cinta #1, lo que es también en este caso el fin de la cinta.
# mt fsf 1 /dev/tape: Input/output error
# mt status SCSI 2 tape drive: File number=1, block number=0, partition=0. Tape block size 512 bytes. Density code 0x13 (DDS (61000 bpi)). Soft error count since last status=0 General status bits on (89010000): EOF EOD ONLINE IM_REP_EN
e. Monte el sistema de ficheros root, pero no modifíquela de ninguna manera. Para hacerlo bien hay que montarla de modo solo lectura con opción "-r" o "-o ro". Tenemos que tener en cuenta que la pertenencia de ficheros se contará basándose en el fichero /etc/group del sistema de análisis y no del fichero group del sistema comprometido.
Ejemplo:
# mount -r /dev/hdd2 /mnt
# ls -lat /mnt total 73 drwxr-x--- 17 root root 1024 May 1 09:01 root drwxrwxrwt 6 root root 1024 May 1 04:03 tmp drwxr-xr-x 8 root root 34816 Apr 30 04:02 dev drwxr-xr-x 34 root root 3072 Apr 29 14:17 etc drwxr-xr-x 2 root root 2048 Apr 26 16:52 bin drwxr-xr-x 2 root root 1024 Apr 26 11:12 boot drwxr-xr-x 3 root root 3072 Apr 21 04:01 sbin drwxr-xr-x 4 root root 3072 Apr 21 03:56 lib drwxrwxr-x 2 root root 1024 Mar 3 13:27 cdrom drwxr-xr-x 2 root root 1024 Oct 9 1999 home drwxr-xr-x 2 root root 12288 Oct 9 1999 lost+found drwxr-xr-x 4 root root 1024 Oct 9 1998 mnt drwxr-xr-x 2 root root 1024 Oct 9 1999 proc drwxr-xr-x 20 root root 1024 Aug 2 1998 usr drwxr-xr-x 18 root root 1024 Aug 2 1998 var
Observando este listado podemos notar que efectivamente no nos hemos equivocado ya que esa partición es de hecho la partición root ya que contiene directorios "usr", "var", "proc", "bin", "root", "etc", etc... Vemos que el directorio "home" tiene 2 enlaces, y el directorio "usr" tiene 20 enlaces (ya que por las entradas de directorios "." y ".." el número mínimo de enlaces que llevan a un directorio son 2). Todavía no sabemos que es lo que exactamente contiene la partición /dev/hdd4. Parece que posiblemente contiene el contenido del /home y no del /usr ni tampoco /var por las mismas razones.
Por supuesto para salir de dudas podemos examinar el fichero /etc/fstab.
Ejemplo: # less /mnt/etc/fstab . . . /dev/hda1 /dosc msdos defaults 0 0 /dev/hda2 / ext2 defaults 1 1 /dev/hda4 /home ext2 defaults 1 2 /dev/hda3 swap swap defaults 0 0 /dev/cdrom /cdrom iso9660 noauto,user,ro 0 0 /dev/fd0 /floppy ext2 noauto,user,rw 0 0 none /proc proc defaults 0 0 none /dev/pts devpts mode=0622 0 0
Cabe tomar nota aquí que utilizamos el paginador less. Es para prevenir potencialmente insertados caracteres especiales que pueden modificar los ajustes del terminal en tty, si eso pasa el terminal es inutilizable para nosotros ya que no podemos ni leer ni escribir de forma legible. Si estuvo utilizando el programa script para logear la sesión, tendrá que salir y resetear el terminal, posiblemente olvidando de script y olvidando de los records anteriores. De todas maneras antes de salir intentaremos Ctrl+D para cerrar la sesión script.
Recuerde que si el disco era el único dispositivo IDE utilizado en el sistema, pueda posiblemente ser master en el primer controlador o /dev/hda. Por eso el fichero fstab los muestra de tal forma, y no como /dev/hdd como aparecen en nuestro sistema de análisis. Por lo tanto para que podamos montar la partición /home necesitamos utilizar /dev/hdd4.
Ejemplo: # umount /mnt # mount -r /dev/hdd4 /mnt # ls -lat /mnt total 21 drwx------ 47 user1 user1 3072 Apr 28 11:52 user1 drwx------ 10 user3 user3 1024 Dec 3 14:19 user3 drwx------ 4 user2 user2 1024 Oct 14 1999 user2 drwxr-xr-x 2 root root 12288 Oct 1 1999 lost+found drwxr-xr-x 2 root nobody 1024 Apr 15 1999 samba drwxr-xr-x 5 root root 1024 Apr 7 1999 httpd drwxr-xr-x 6 root root 1024 Mar 21 1999 ftp drwxr-xr-x 30 root root 1024 Aug 2 1998 local
Ahora podemos ver el contenido de la partición /home montado sobre /mnt. Vamos por ahora ignorar el contenido de la partición /home, ya que ningún fichero de sistema operativo se encuentra allí. En futuro podemos examinar su contenido para detectar algún indicio de back-door, como aplicaciones setuid/setgid, ficheros .rhosts, comandos añadidos a los ficheros de inicialización de shell (.cshrc, .bashrc, etc.) que pueden enviar una copia de fichero que contiene passwords a una dirección, borrar fichero, similares...
Ahora vamos a re-montar en solo lectura el sistema de ficheros root y empecemos a investigar.
Ejemplo: # umount /mnt # mount -r /dev/hdd2 /mnt
Primero, verifiquemos que es lo que contiene el fichero /etc/passwd para ver que UID/GIDs hay dentro. Este fichero debe ser copiado y utilizado con la aplicación mactime del suite de herramientas The Coroner's Toolkit [13]. La aplicación nos mostrará el mapeo correcto de UIDs y GIDs.
El fichero puede contener cuentas creadas por los intrusos como por ejemplo
aquí:
# less /mnt/etc/passwd . . . root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown z:x:0:0::/:/bin/bash halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail: news:x:9:13:news:/var/spool/news: uucp:x:10:14:uucp:/var/spool/uucp: operator:x:11:0:operator:/root: r00t:x:598:500:::/bin/bash games:x:12:100:games:/usr/games: y:x:900:100::/tmp:/bin/bash gopher:x:13:30:gopher:/usr/lib/gopher-data: ftp:x:14:50:FTP User:/home/ftp: nobody:x:99:99:Nobody:/: gdm:x:42:42::/home/gdm:/bin/bash xfs:x:100:233:X Font Server:/etc/X11/fs:/bin/false user1:x:500:500:User 1:/home/user1:/bin/tcsh user2:x:501:501:User 2:/home/user2:/bin/tcsh user3:x:502:502:User 3:/home/user3:/bin/tcsh named:x:25:25:Named:/var/named:/bin/false
En el ejemplo anterior podemos observar que hay cuentas que parecen totalmente fuera de lugar ya que tienen números UID elevados y sin orden aparente, por ejemplo "r00t", "y" (que por cierto tiene asignado como $HOME el directorio /tmp). Un fichero de passwd legítimo y creado por el sistema, normalmente sigue un patrón secuencial de asignación de UID's. Mientras aquí anotamos que las cuentas con UIDs de orden bajo como reciente mente añadidos "named" con UID 25 y "z" con UID 0 y GID 0 (lo mismo que root) son altamente sospechosos por su posición. Hemos tomado nota para volver luego y investigar más en detalle. Intente de forma opcional extraer las contraseñas de esos usuarios en formato cifrado y intentar ripearlos (hay muchas posibilidades de que los intrusos tengan la misma contraseña en la máquina atacada y en suya propia). También apunte algunas conclusiones a las que hemos llegado ahora:
1. Creación de cuentas es una acción frecuente, y creadas de tal manera como hemos visto anteriormente muestran un nivel de conocimientos bajo del intruso.
2. También podemos suponer que los intrusos ya han observado que el administrador no realiza verificaciones de seguridad rutinarias y no temen ser descubiertos.
3. Puede ser que sea un entretenimiento para los intrusos crear cuentas para que el administrador las encuentre, las elimine y asume que el sistema está seguro, mientras que hay múltiples puertas traseras instaladas que permiten compromiso root de la máquina.
4. Como normalmente las cuentas se crean de forma secuencial en el fichero /etc/passwd, puede que el administrador (o alguien más?!) haya instalado named en el sistema, de forma reciente (o el intruso haya instalado una versión de named vulnerable!?) .
Debe empezar a construir una línea de tiempo para anotar cuando han ocurrido los hechos, intentar trazar de forma inversa todos los acciones hasta el intento de entrada al sistema, y el punto de origen de entrada. Aprovechando todos los hechos acumulados al final podremos determinar el origen verdadero del atacante y los sistemas utilizados para atacar a la máquina.
En este momento nos encontramos en la fase de observación, ahora estamos tomando notas de lo que pasó, hemos verificado que tenemos el contenido de disco duro intacto, disponemos de tres copias del disco duro y las estamos estudiando en modo solo lectura.
Desde aquí el análisis puede ser continuado usando herramientas comunes de Unix y/o herramientas especialmente diseñados para análisis forense. También debemos utilizar toda nuestra experiencia anterior y el sentido común.
[Subir]