Ejemplo de actuación

Veamos con más detenimiento algunos de estos pasos, teniendo en cuanta que se debería documentar cada una de las actuaciones que se van realizando en el equipo de forma que se pueda averiguar que comandos se han ejecutado para localizar los ficheros, donde se encontraban, etc.[1]

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, 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 ficheros.

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 Muchos 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 esta Tripwire se pueden emplear otras técnicas para verificar la integridad de los ficheros, como:

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 [3] Es conveniente examinar los ficheros de configuración y ficheros en cuantas de usuarios:

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:

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 una institución afiliada a RedIRIS , Universidades y centros de I+D , se pueden enviar los ficheros para su análisis en Rediris. Para ello , empaquetar todos los ficheros y enviarlos a IRIS-CERT, en caso de que los ficheros muy grandes se puede emplear el servidor de ftp anónimo de RedIRIS para dejar ahí los ficheros.

Este análisis sirve para intentar averiguar desde donde se produjo el ataque, que vulnerabilidad empleo para acceder al equipo, que acciones realizó en el equipo, etc.

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 RedIRIS se solicita que se envié notificación de todos los incidentes de seguridad "sufridos" por equipos de las organizaciones afiliadas, de forma que se pueda tener una visión global de los ataques que se están produciendo.

El procedimiento general de actuación de IRIS-CERT es intentar contactar con los responsables de las organizaciones origen del ataque, para avisarles de que hay un equipo que ha podido ser atacado. Sin embargo si el correo nos llega como copia (CC) procesamos el incidente para fines estadísticos, aunque no avisamos individualmente a la organización atacada.

Notas

[1]

Se puede emplear el comando script para ir generando un fichero con todos los programas que se ven ejecutando.

[2]

Este es uno de los motivos por los cuales siempre que sea posible se debe realizar la instalación de los programas mediante el sistema de paquetes del sistema operativo, de forma que se tenga información fiable sobre los programas instalados en el equipo.

[3]

Consultar la lnota de prensa del 19 de Mayo del 2001

[4]

Por ejemplo, el comando vi con setuid de root, podría permitir la edición de ficheros, pero además al salir a un shell con ":!" este se ejecutaría como root.