PDF de programación - Recuperación ante ataques

1 INTRODUCCI ÓN
ÍNDICE GENERAL

Recuperación ante ataques

IRIS-CERT <certrediris.es>

14 de Noviembre de 2000

Otro documento, mezcla de varios para contar con toda la información en con-

junto sobre como buscar evidencias de que se ha sufrido un ataque.

Resumen

Índice General

1 Introducción

2 Un incidente de seguridad típico

3 Recuperación ante incidentes de seguridad

4 Copia de los datos

5 Análisis de la intrusión

6 Reinstalación del equipo

7 Notificación del ataque

8 Referencias y programas de utilidad

9 Versiones y colaboraciones

1 Introducción

1

3

3

4

5

8

9

9

10

En anteriores grupos de trabajo se han ido tratando diversos aspectos relacionados con
la gestión de incidentes de seguridad1 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

1Búsqueda de puntos de contacto, GGTT Oviedo 1999

IRIS-CERT

1

1 INTRODUCCI ÓN

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.

IRIS-CERT

2

3 RECUPERACI ÓN ANTE INCIDENTES DE SEGURIDAD

2 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 sistema2

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 actual-
izació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.

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

2Así 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

IRIS-CERT

3

4 COPIA DE LOS DATOS

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 her-
ramientas que el atacante ha instalado, etc. Estos datos deben ser después analiza-
dos 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 in-
formá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.

4 Copia de los datos

Aunque existan copias de seguridad del equipo, es conveniente hacer una copia con la in-
formació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,

IRIS-CERT

4

5 AN ÁLISIS DE LA INTRUSI ÓN

sin embargo es preferible volver los contenidos a otro equipo empleando por ejemplo el
programa Netcat3.

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.

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

3http://dondeesta

IRIS-CERT

5

5 AN ÁLISIS DE LA INTRUSI ÓN

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 se-
guridad4

Aunque n