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]
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.
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:
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 no exige que todos los paquetes incorporen la información de las huellas criptográficas MD5 de los ficheros, aunque gran parte de los paquetes Debian suelen tenerla incluida. El comando debsums -l -s permite comprobar la integridad de los paquetes que dispongan de este sistema de verificación.
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. [2]
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 [3] 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[4] 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.
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.
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.
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.
| [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. |