Recuperacion ante ataques

Contents

Introducci�n

En anteriores grupos de trabajo se han ido tratando diversos aspectos relacionados con la gesti�n de incidentes de seguridad¹ y este suele ser uno de los puntos m�s comentados en casi todos las reuniones. Para estas jornadas hemos preparado un peque�o documento donde se comentan los pasos a seguir para que un administrador de una m�quina atacada pueda recopilar la informaci�n del ataque para su posterior an�lisis.

Lo primero hay que hay que indicar es que los procedimientos que se mencionan a continuaci�n est�n pensados para situaciones en las que se requiere que los equipos atacados vuelvan a funcionar adecuadamente. En caso de que se considere m�s oportuno una investigaci�n legal del incidente lo m�s conveniente ser�a acudir a los servicios jur�dicos de la organizaci�n y contactar con las autoridades.

Por otro lado se har� una breve descripci�n del conjunto de utilidades ``Colonel Toolkit'' que se puede emplear en algunos casos para intentar averiguar que es lo que ha hecho un atacante en un equipo.

Un incidente de seguridad t�pico

Gran parte de los ataques que acaban con el acceso por parte del atacante a un equipo con permisos de root, suelen seguir el siguiente patr�n de comportamiento:

1.: El atacante realiza un escaneo buscando equipos vulnerables que est�n ejecutando un servidor con alg�n fallo de seguridad conocido y que se ha comentado ampliamente en listas de seguridad, por ejemplo los fallos de desbordamiento de buffer en el servidor de FTP wuftp o del proceso rpc.statd.
2.: El atacante emplea un exploit contra el equipo, consiguendo instalar una puerta de acceso en el sistema, muchas veces el exploit genera directamente un interprete de comandos con privilegios de root, o a�ade una linea en el /etc/inetd.conf para lanzar una shell en un puerto dado.
3.: El atacante instala o compila un ``rootkit'', conjunto de programas de nombre y comportamiento similar al de comandos del sistema operativo, que sin embargo no muestran informaci�n sobre determinados estados del sistema²
4.: El atacante instalar� y/o compilara algunas herramientas de ataque, para escanear y atacar otros equipos y redes empleando la maquina reci�n atacada como puente.

Esta situaci�n se produce hasta que alguien detecta un comportamiento an�malo en el equipo, algunas veces esta detecci�n se realiza por el propio administrador del equipo debido a una carga de procesamiento anormal, accesos extra�os, etc. pero en la mayor�a de los caso la detecci�n del equipo atacado se produce desde el exterior: Llega un correo a la organizaci�n indicando que el equipo en cuesti�n esta escaneando o ha sido empleado para atacar otros sistemas y al contactar con el administrador del equipo se descubre que la maquina ha sido a su vez atacada.

Sin entrar en el grave problema que es la ausencia de administraci�n y actualizaci�n de estos equipo, los pasos a seguir suelen ser tambi�n siempre los mismos y es lo que se conoce como ``recuperaci�n ante un incidentes de seguridad.

Recuperaci�n ante incidentes de seguridad

Una vez que el administrador ha sido apercibido del problema los pasos que se deben hacer son:

1.: Desconexi�n de la red o apagado del equipo, para evitar que el atacante pueda seguir accediendo al equipo, evitando que recupera la informaci�n que haya podido obtener sobre otras redes o intente borrar sus huellas, o inutilice (borrado o formateo) el equipo atacado.
2.: Realizar una copia de seguridad a bajo nivel. Siempre que sea posible es conveniente realizar una copia de los datos del equipo a bajo nivel, de forma que se tenga la informaci�n completa del estado del sistema cuando se detecto el ataque. Si es posible el an�lisis posterior de los datos se deber�a realizar sobre la copia (con el equipo apagado/desconectado).
3.: Averiguar, examinando los datos disponibles toda la informaci�n posible sobre el ataque: vulnerabilidad empleada por el atacante, logs que muestren los ataques, escaneos y conexiones del atacante, programas instalados, logs y datos que las herramientas que el atacante ha instalado, etc. Estos datos deben ser despu�s analizados para poder avisar a otros equipos que se han podido ver involucrados.
4.: Proceder a restaurar el equipo. Volver a configurar el equipo, reinstalando el Sistema Operativo si es preciso, y aplicando los parches y configuraciones adecuadas para evitar que el ataque se vuelva a producir. En caso de existan cuentas de usuarios en el equipo es conveniente que se avise a todos los usuarios y que estos cambien sus cuentas, ya que el atacante puede haberse copiado el fichero de claves y proceder despu�s en su equipo a buscar claves d�biles para volver a entrar.
5.: Avisar a los responsables de los equipos atacados o fuente del ataque, as� mismo notificar toda la informaci�n a los responsables de la organizaci�n (servicio de inform�tica, centro de calculo, etc.) para que ellos se pongan en contacto. En la actualidad los ataques son ``aleatorios'' ya que los ataques se producen buscando equipos que presenten una determinada vulnerabilidad, por lo tanto el atacante puede haber conseguido entrar en otros equipos situados en la misma red.

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 realizandoen el equipo de forma que se pueda averiguar que comandos se han ejecutado para localizar los ficheros, donde se encontraban, etc.

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 Netcathttp://dondeesta.

Lo m�s conveniente es arrancar el equipo desde un 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. Algunos ejemplos de esta copia ser�an:

dd if=/dev/sda4 of = - | nc equipo remoto -p 100

y en el equipo remoto hacer:

nc -s -p 1000 > sda4

O bien enganchar 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.

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

NT no dispone de un procedimiento de backup a bajo nivel con las herramientas del sistema, aunque se puede emplear el procedimiento empleado para sistemas Unix, arrancar el equipo desde un disco de rescate o instalaci�n de Linux/Unix y proceder a realizar la copia de los dispositivos a bajo nivel.

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 posteridad al equipo.

Dado que los atacantes pueden modificar tambi�n los programas que vamos a comentar a continuaci�n es conveniente que no se empleen los programas instalados en el propio equipo atacado, sino versiones que se tengan compiladas est�ticamente y se acceda a ellas, El motivo de emplear ficheros compilados est�ticamente es debido a que no emplean llamadas a las librer�as del sistema, que pueden tambi�n ser modificadas por los atacantes. Por esa misma raz�n no es conveniente que se emplee el sistema operativo de la m�quina atacada, ya que hasta el propio sistema operativo puede ser modificado mediante m�dulos en varios sistemas Unix, para ocultar los procesos y ficheros a determinados comandos.

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 o un sistema antivirus en Windows, para m�s informaci�n sobre el tripwire, consultar las Recomendaciones de seguridadhttp://www.rediris.es/cert/doc/docurediris/recomendaciones/

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 md5sumftp://ftp.rediris.es/mirror/dfncert/tools/crypt/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''

Debian
falta por ver.

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

Es conveniente examinar los ficheros de configuraci�n y ficheros en cuantas de usuarios:

/etc/passwd y /etc/shadow
/etc/inetd.conf
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³ Se puede emplear el siguiente comando para listar los ficheros setuid/guid:
```
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 ocult�ndolo.
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 programas instalados 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 y wtmpx: 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 habituales y todo lo que se sale de lo habitual⁵
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.

Una vez que se disponne de todos los ficheros e informaci�n de los ficheros de logs es conveniente analizarla para intentar determinar el origen del ataque, averiguar como pudieron entrar en el equipo, si han tenido acceso a otros equipos, etc. Es conveniente empaquetar todos los ficheros, haciendo un ``tar'' de todos los ficheros y enviarlo con formulario de notificaci�n de incidenteshttp://www.rediris.es/cert/servicios/iris-cert/incidentes/formulario.txt⁶

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, una de ellas las recomendaciones de seguridadhttp://www.rediris.es/cert/doc/docrediris/recomendaciones/ que hemos comentado anteriormente.

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.

Referencias y programas de utilidad

Comentario: Esta puesto con una macro que habr� que redefinir en la plantilla de documentaci�n .

A.

Documentaci�n de seguridad

Recomendaciones de seguridad de RedIRIShttp://www.rediris.es/cert/docs/docrediris/recomendaciones/
Documentaci�n del CERT/CC (en Ingles)http://www.cert.org/tech_tips
Libro en Castellano de Seguridad en Redesponer url
Ultima versi�n de este documentoPoner URL

B.

Herramientas

Lsof, para ver analizar que ficheros emplea un procesoftp://ftp.rediris.es/mirror/dfncert/tools/admin/lsof/
Tripwireftp://ftp.rediris.es/mirror/coast/tools/unix/ Existen nuevas versiones con una licencia mas restrictiva en la Pagina Oficialhttp://www.tripwire.org
Colonel's Toolkithttp://www.fish.com(poner bienurl) herramienta realizada por Dan Farner y Wietse venema para el analisis de ataques.

Versiones y colaboraciones

Version inicial de este documento.

Footnotes

... seguridad ¹: B�squeda de puntos de contacto, GGTT Oviedo 1999
... sistema ²: As� la versi�n modificada del comando ``ls'' no listar� los ficheros creados por el intruso, ``ps'' no mostrara determinados procesos o ``netstat'' no mostrara las conexiones del atacante
... root ³: 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.
... syslog ⁴: consultar las recomendaciones de seguridad
... habitual ⁵: Lo que implica que el administrador deber�a observar los logs de su equipo habitualmente ;-)
... incidenteshttp://www.rediris.es/cert/servicios/iris-cert/incidentes/formulario.txt ⁶: En caso de que los ficheros muy grandes se puede emplear el servidor de ftp an�nimo de RedIRIS para dejar ah� los ficheros

IRIS-CERT
2000-11-27