Ejemplo de actuaci�n

Copia de los datos

Aunque existan copias de seguridad del equipo, es conveniente hacer una copia con la informaci�n que hay en el sistema cuando se detecta el ataque. Dependiendo de la situaci�n puede ser conveniente incluso hacer una "copia" de los procesos que se est�n ejecutando en ese momento en el equipo, espacio de intercambio (swap) conexiones activas, etc, sin embargo normalmente basta con realizar una copia, [2] a ser posible a bajo nivel, de los datos del sistema.

En equipos Unix se puede realizar una copia de las particiones del sistema de ficheros, empleando el comando dd, y volvar los contenidos a otra partici�n o fichero, sin embargo es preferible volver los contenidos a otro equipo empleando por ejemplo el programa Netcat

Lo m�s conveniente es arrancar el equipo desde un disquete de rescate, CDROM o cinta de instalaci�n y realizar la copia en modo monousuario, de forma que no se empleen los programas que est�n instalados en el equipo. Un ejemplo de esta cop�a ser�a:

victima# dd if=/dev/particion of = - | gzip -9 | nc equipo remoto -p 100

y en el equipo remoto hacer:

analisis$ nc -s -p 1000 > particion.dd.gz

Esta acci�n habr�a que repetirla con cada una de las particiones del equipo atacado, incluyendo la partici�n de SWAP.

Otra posibilidad es conectar los discos a un equipo y realizar la copia a bajo nivel, empleando discos duros de iguales caracter�sticas (mismo modelo ) y haciendo de nuevo una copia a bajo nivel con dd, aunque as� tenemos que apagar el equipo.

analisis# dd if=/dev/sda of=/dev/sdb 

En cualquier caso es conveniente realizar estas copias a bajo nivel para poder restaurar los datos en caso de que ocurra alg�n problema al analizar los ficheros, adem�s esto permitir� el an�lisis de los ficheros, buscando las fechas de modificaci�n de �stos.

An�lisis de la intrusi�n

La primera acci�n que hay que realizar es comprobar todos los programas y ficheros de configuraci�n instalados en el equipo.

En nuchos ataques lo primero que hace el atacante es modificar los programas y herramientas del sistema para ocultar su acceso, adem�s suelen modificar los ficheros de configuraci�n para crear nuevos usuarios, permitir accesos desde determinadas m�quinas, etc, de forma que puedan acceder de una forma m�s c�moda con posterioridad al equipo.

En caso de que el an�lisis se realize en el mismo disco hay que tener en cuenta que el atacante ha podido modificar algunos de los binarios y librer�as del sistema, por lo que conviene emplear, si es posible, comandos compilados estaticamente en otro equipo, o montar / copiar los comandos desde una m�quina de confianza, para evitar que los programas modificados por el atacante nos oculten la informaci�n del equipo.

En un caso ideal, el administrador del sistema deber�a disponer de una base de datos de integridad en un dispositivo de almacenamiento externo al equipo, para poder comprobar los ficheros empleando productos como Tripwire, AIDE, VipperDB, etc. que realizan una firma digital de los ficheros instalados en los equipos.

Aunque no se disponga de alguna de estas herramientas se pueden emplear otras t�cnicas para verificar la integridad de los ficheros, como:

• Comparar los binarios con los existentes con los de la instalaci�n original (cuando no est�n empaquetados) o con lo que hay en otro equipo con la misma revisi�n del sistema operativo y parches, empleando el comando "cmp". Algunos vendedores mantienen una lista de hash MD5 de los programas binarios que distribuyen, se puede emplear el comando md5sum para comprobar si la huella de los ficheros corresponde con la informaci�n del fabricante.

• Muchos sistemas Operativos disponen de un sistema de verificaci�n de los paquetes instalados, la base de datos se mantiene en el propio equipo (por lo que el atacante puede modificarla) pero de todas maneras puede ser empleada muchas veces para comprobar que ficheros se han modificado. Para algunos sistemas Operativos el comando ser�a:

  • RedHat Linux y otros linux basados en RPM : rpm -Va por ejemplo:

    victima$ rpm -Va | grep bin SM5....T /bin/ps S.5....T /usr/sbin/tcpd S.5....T /bin/netstat S.5....T /sbin/ifconfig

  • Debian El formato de paquetes empleado en Debian tambi�n incluye dentro de los todos los paquetes la informaci�n de las huellas MD5 de los ficheros. El comando debsums -l -s permite comprobar la integridad de los paquetes y ver que ficheros se han modificado.

  • Solaris y otros Unix con el comando pkgchk : pkgchk -v

• Hay que tener en cuenta que es habitual que algunos ficheros cambien de permisos o de contenido, por ejemplo al a�adir usuarios al fichero de password, algunas instalaciones cambian los formatos, etc. Sin embargo no suele ser habitual que el comando /bin/ls sea modificado. [3]

  La comprobaci�n de la base de datos local no es del todo fiable, ya que el atacante ha podido modificarla tras la intrusi�n, por lo que es conveniente mantener una copia de esta base de datos en un sistema aislado, aunque muchas veces no existe esta copia y se debe recurrir a la base de datos del sistema.

• Por ultimo caso se puede examinar los ficheros "sospechosos" y buscar cadenas que delaten que se trata de un troyano, aunque este m�todo no suele dar buenos resultados si no se conoce los ficheros originales.

El empleo de scripts de comprobaci�n de integridad autom�ticos, que cada cierto tiempo comprueben que los ficheros no han sido modificados, ya sea empleando el sistema de gesti�n de paquetes o alg�n programa de los comentados antes, permite muchas veces detectar cuando se ha producido un ataque, Esto sucedi� hace poco en un servidor de desarrollo del proyecto Apache [4] Es conveniente examinar los ficheros de configuraci�n y ficheros en cuantas de usuarios:

• /etc/passwdy /etc/shadow

• /etc/inetd.conf

• Programas del arranque rcX.d

• Procesos ejecutados en el crontab del administrador.

• comprobar que no existen ficheros .rhosts, .shosts, etc. que permitan accesos no deseados desde el exterior no deseados.

• hosts.allow y hosts.deny

• Ficheros con suid de root o de administrador nuevos, que puedan permitir a un usuario acceder r�pidamente a root[5] Se puede emplear el siguiente comando para listar los ficheros setuid/guid:

  victima # find / \( -perm 0040000 -o perm 0020000 \) -type f -print

• Buscar ficheros y directorios que empiecen por punto, pero que el contenido no sea el habitual. Los ficheros que empiezan por punto no suelen aparecer con el comando ls (salvo que se indique la opci�n "-l") y se suelen emplear para almacenar la configuraci�n de los programas en el directorio ra�z de cada usuario. Algunas veces los atacantes instalan los programas en un directorio home ocultando los programas en directorios que comienzan con punto.

• Buscar directorios y ficheros con caracteres de control y/o espacios: Igual que antes para ocultar la informaci�n, se crean directorios espacios o con nombre el car�cter de espacio, o " .." para as� ocultarlos ficheros.

• Buscar ficheros ASCII y ficheros en directorios como /dev/, /devices, etc. empleados muchas veces por los atacantes para instalar ah� los programas, logs de las herramientas de ataque, etc.

Hay que examinar tambi�n los ficheros de logs, ya que aunque los atacantes suelen borrarlos otras veces el borrado no es completo, por lo quedan rastros de la intrusi�n, es conveniente tener los logs de todos los equipos centralizados, empleando el syslog.

La informaci�n de los ficheros de logs depender� de como este configurado el syslog de cada equipo y de los rastros que haya borrado el atacante, se debe buscar informaci�n en:

• utmp, utmpx: Informaci�n sobre los usuarios que est�n conectados en un momento dado en un equipo, es un fichero binario, aunque se puede emplear el comando who para analizarlos. El fichero utmpx aparece en Solaris y otros Unix. Muchas veces los programas de rotaci�n de logs dejan una copia de estos ficheros con extensi�n ".1" o ".bak".

• wtmp ywtmpx: Informaci�n sobre los accesos con �xito al equipo, usuario que se conecta, protocolo que emplea, maquina origen de la conexi�n, etc. se puede emplear el comando last para examinarlo.

• messages, situado en /var/log o en /var/adm. contiene informaci�n diversa, dependiendo como se ha indicado antes de la configuraci�n del syslog.

• secure: En muchas distribuciones Linux el fichero /var/log/secure almacena todos los eventos de seguridad, conexiones realizadas al equipo, cambios de usuario (su, etc.). Buscar conexiones a servicios poco frecuentes, direcciones IP de conexi�n poco frecuentes y todo lo que se sale de lo habitual\footnote{Lo que implica que el administrador deber�a observar los logs de su equipo habitualmente ;-)}

• xferlog: Empleado por algunos servidores de ftp para registrar las transferencias de ficheros

• ficheros del servidor WWW: En los casos en los que el atacante ha realizado primero un escaneo de vulnerabilidades en el servidor WWW aparecen intentos de conexi�n a cgi que no est�n instalados.

• ficheros de historia .bash\_history, o similar en las cuentas del administrador y usuarios que se cree que han sido empleadas por el atacante.

Muchas veces aunque los atacantes suelen borrar los ficheros de logs, es posible emplear el Coroner's Toolkit, mencionado en la bibiliograf�a para recuperar la informaci�n contenida en el espacio ocupado por los ficheros borrados y despu�s an�lizar los resultados.

An�lisis de los datos

Cuando se produce un incidente de seguridad en un equipo es siempre conveniente realizar un an�lisis del equipo o equipos atacados, siguiendo los pasos que se han comentado anteriormente, para as� intentar averiguar desde donde se produjo el ataque, que vulnerabilidad empleo para acceder al equipo, que acciones realiz� en el equipo, nivel de destreza del atacante, etc.

De esta forma se debe intentar determinar los motivos por los que el ataque tuvo exito, de forma que se puedan tomar las medidas oportunas para que no se vulva a producir

Reinstalaci�n del equipo

Una vez que se ha determinado las causas del ataque se debe proceder a eliminar los rastros del ataque y configurar el equipo para que no se vuelvan a producir estos ataques. Si la versi�n del sistema operativo es algo antigua es un buen momento para instalar una versi�n mas actualizada del equipo. Igualmente si se disponen de copias de seguridad anteriores al ataque se puede restaurar las copias (aunque convendr�a comprobar si los ficheros de la copia de seguridad no han sido modificados). o proceder a reinstalar solamente los ficheros o paquetes modificados.

Una vez que se tiene el sistema operativo "limpio" proceder a instalar los parches de seguridad que hayan salido para esta versi�n del equipo, eliminar los servicios de red que no sean precisos, etc. Existen diversas guias de configuraci�n en este sentido.

Notificaci�n del ataque

Muchas veces los equipos atacados son empleados para lanzar ataques a otros sistemas, por lo que no necesariamente el equipo origen de un ataque es "culpable", muchas veces este equipo ha sido a su vez atacado y si se avisa al administrador se puede conseguir que este tambi�n corrija los problemas de seguridad que hay en este equipo.

Los atacantes muchas veces han realizado inicialmente un barrido buscando equipos vulnerables, por lo que una notificaci�n a los administradores de la red en la organizaci�n del ataque puede ayudar a descubrir problemas de seguridad a nivel global.

Este es uno de los motivos por los cuales desde los grupos de seguridad de diversos organismos, se solicita que se envi� notificaci�n de todos los incidentes de seguridad "sufridos" por los equipos, de forma que se pueda tener una visi�n global de los ataques que se est�n produciendo.

El procedimiento de actuaci�n, en general, de los grupos de seguridad es intentar contactar con los responsables de las organizaciones origen del ataque, para avisarles de que hay un equipo que ha podido ser atacado, de esta forma se intenta evitar que existan equipos "trampolin" empleados para atacar impunemente otros equipos.