PDF de programación - Incidentes de seguridad en equipos Linux

Incidentes de seguridad en

equipos Linux

Francisco Jesús Monserrat Coll
Centro de Comunicaciones del CSIC RedIRIS

[email protected]

A pesar de la seguridad que pueden ofrecer los sistemas operativos Unix
y Linux, sigue aumentando significativamente el número de equipos con
estos sistemas operativos que son atacados con éxito de forma remota,
consiguiendo el atacante acceder como administrador al equipo.

Esta situación se ha visto agravada esta año con la reaparición de los
programas gusano para equipos Unix, que consiguen acceso
automáticamente a los equipos vulnerables, dejando algunas veces
puertas abiertas para posteriores accesos.

1. Introducción

Con el aumento de popularidad de los sistemas Unix para plataformas Intel, y sobre
todo de Linux en sus distintas distribuciones, el número de incidentes de seguridad en
los que son atacados este tipo de sistemas ha aumentado considerablemente en los
ultimos tiempos.1

En la mayoría de las ocasiones los atacantes no realizan un ataque diriguido hacia un
servidor concreto, sino que van buscando equipos vulnerables ante determinado
conjunto, limitado, de vulnerabilidades hasta que encuentran un equipo vulnerable, que
es atacado.

Una vez que el atacante ha obtenido acceso al sistema suele instalar y modificar varios
ficheros del equipo para ocultar su presencia. Muchas veces la forma más segura de

1

Incidentes de seguridad en equipos Linux

solucionar el problema es reinstalar el sistema operativo y datos desde una copia de
seguridad anterior a la fecha en la que se produjo el ataque.

Este año han aparecido diversos programas y scripts de ataque que combinados
formaban un gusano, es decir un programa que buscaba y atacaba automáticamente
otros equipos replicándose sin requerir ninguna interacción con el usuario.

Así a finales del año pasado y principio de este año aparecerieron diversos Gusanos,
Ramen (http://www.cert.org/incident_notes/IN-2001-01.html)o Li0n
(http://www.cert.org/incident_notes/IN-2001-03.html), para equipos Linux y
sadmin/IIS (http://www.cert.org/advisories/CA-2001-11.html) que infectaba a equipos
Solaris y atacaba simultaneamente servidores IIS de Microsoft.

Estos gusanos empleaban vulnerabilidades conocidas y solucionadas bastante antes de
la aparición del gusano, pero al no haber sido actualizado el equipo víctima se producía
un ataque exitoso. Una de las ventajas de los gusanos es que es posible analizar cuales
son las acciones que ejecutan en el sistema, por lo que si no ha habido accesos
posteriores al equipo y se conoce exactamente qué gusano ha sido el causante del
ataque es posible solucionar el problema con más rapidez que en el caso de un ataque
“manual”.

Dado que estos gusanos son un caso específico de los incidentes de seguridad, se
tratarán indistintamente al resto de accesos no autorizados a los equipos.

Hay que indicar que los procedimientos mencionados a continuación están pensados
para situaciones en las que se requiere que los equipos atacados vuelvan a funcionar
rápidamente y en los que no ha habido un perjuicio serio.

En caso de que sea más conveniente una investigación judicial del ataque lo más
conveniente sería acudir a los servicios jurídicos de la organización y contactar con las
autoridades, ya que la manipulación del sistema pueda invalidar las posibles pruebas
existentes en el equipo.

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 Administrador, suelen seguir el siguiente patrón de comportamiento:

1. El atacante realiza un barrido de puertos (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

2

Incidentes de seguridad en equipos Linux

desbordamiento de buffer en el servidor de FTPwuftp, el servidor bind de DNS o
en el proceso rpc.statd.

Estos fallos de seguridad son anunciados en diversas listas de seguridad de
proposito general, como Bugtraq (http://securityfocus.com/archive/1)

La mayoría de los vendedores de distribuciones Linux disponen de listas de
anuncios, donde indican las actualizaciones por motivos de seguridad, de los
programas que componen su distribución.

En algunas listas de seguridad, aparecen incluso programas que demuestran esta
vulnerabilidad y que pueden ser empleados por los atacantes, estos programas se
suelen denominar “exploits”.

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 fichero
/etc/inetd.conf para lanzar una shell en un puerto dado. El método puede
variar, aunque el objetivo del ataque suele ser siempre el mismo, obtener un acceso
a una sesión interactiva o “shell remoto” en el equipo desde el cual proseguir el
ataque.

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

Estos rootkit han ido evolucionando, siendo cada vez más complejos. Existen
módulos del kernel que permiten ocultar diversos procesos, de forma que el
atacante pueda ocultar su acceso sin modificar los binarios instalados en el equipo.

4. El atacante instalará y/o compilará algunas herramientas de ataque, para escanear
y atacar otros equipos y redes empleando la maquina recién atacada como puente.

Esta situación se reproduce 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, 3 los pasos a seguir suelen ser también siempre los mismos y es lo que se

3

conoce como “recuperación” ante un incidentes de seguridad.

Incidentes de seguridad en equipos Linux

3. Recuperación ante incidentes de seguridad
Una vez que el administrador ha sido apercibido del problema, en lineas generales los
pasos a seguir serian:

1. Desconexión de la red o apagado del equipo, para evitar que el atacante pueda
seguir accediendo al equipo, impidiendo que recupere la información que haya
podido obtener sobre otras redes o intente borrar sus huellas, o inutilice (borrado o
formateo) el equipo atacado.

Dado que el apagado del equipo pude provocar la perdida de información sobre el
ataque (procesos que se están ejecutando, sesiones abiertas, etc.) muchas veces es
preferible el filtrado completo/desconexión del equipo de la red, para así proceder
al análisis de estos datos.

No sólo esto, el sistema puede haber sido modificado para que un apagado no
esperado (o una desconexión de la red) borre todo el sistema de forma completa

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

La copia debe hacerse siempre que sea posible empleando binarios compilados
estáticamente en otro equipo “fiable”, para evitar que se empleen programas
modificados por el atacante.

Estos datos se pueden enviar a los responsables de seguridad de la organización
para que procedan a su análisis si el administrador no puede realizarlos.

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

Incidentes de seguridad en equipos Linux

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

En la actualidad los ataques son “aleatorios” ya que éstos 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.

Suele ser conveniente además contactar con los responsables de la red desde donde
se produjo el ataque, ya que muchas veces se trata de equipos “trampolín”, si estos
equipos son “limpiados” se consigue que la red sea “un equipo” más segura.

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

4.1. Copia de los datos

Aunque existan copias de seguridad del equip