PDF de programación - Sistemas de detección de intrusos

SISTEMAS DE DETECCI ÓN DE

INTRUSOS

Antonio Villalón Huerta

Mayo, 2005

Este documento se corresponde casi en su totalidad con el capítulo 18 de Seguridad en Unix y Redes v2.1, de

Antonio Villalón Huerta.

Índice General

1 Introducción

2 Clasificación de los IDSes

3 Requisitos de un IDS

4 IDSes basados en máquina

5 IDSes basados en red

6 Detección de anomalías

7 Detección de usos indebidos

8 Implantación real de un IDS

IDS en el cortafuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1
IDS en la red: snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2
8.3
IDS en la máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Estrategias de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 Ampliación del esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

3

4

5

7

10

12

14
15
16
21
24
26

1 Introducción

A pesar de que un enfoque clásico de la seguridad de un sistema informático siempre define como
principal defensa del mismo sus controles de acceso (desde una política implantada en un cortafue-
gos hasta unas listas de control de acceso en un router o en el propio sistema de ficheros de una
máquina), esta visión es extremadamente simplista si no tenemos en cuenta que en muchos casos
esos controles no pueden protegernos ante un ataque ([Lun90]). Por poner un ejemplo sencillo,
pensemos en un firewall donde hemos implantado una política que deje acceder al puerto 80 de
nuestros servidores web desde cualquier máquina de Internet; ese cortafuegos sólo comprobará si
el puerto destino de una trama es el que hemos decidido para el servicio http, pero seguramente
no tendrá en cuenta si ese tráfico representa o no un ataque o una violación de nuestra política de
seguridad: por ejemplo, no detendrá a un pirata que trate de acceder al archivo de contraseñas de
una máquina aprovechando un bug del servidor web. Desde un pirata informático externo a nuestra
organización a un usuario autorizado que intenta obtener privilegios que no le corresponden en un
sistema, nuestro entorno de trabajo no va a estar nunca a salvo de intrusiones.

Llamaremos intrusión a un conjunto de acciones que intentan comprometer la integridad, confi-
dencialidad o disponibilidad de un recurso ([HLMS90]); analizando esta definición, podemos darnos
cuenta de que una intrusión no tiene por qué consistir en un acceso no autorizado a una máquina:
también puede ser una negación de servicio. A los sistemas utilizados para detectar las intrusiones
o los intentos de intrusión se les denomina sistemas de detección de intrusiones (Intrusion De-
tection Systems, IDS) o, más habitualmente – y aunque no sea la traducción literal – sistemas de
detección de intrusos; cualquier mecanismo de seguridad con este propósito puede ser considera-
do un IDS, pero generalmente sólo se aplica esta denominación a los sistemas automáticos (software
o hardware): es decir, aunque un guardia de seguridad que vigila en la puerta de la sala de opera-
ciones pueda considerarse en principio como un sistema de detección de intrusos, como veremos a
continuación lo habitual (y lógico) es que a la hora de hablar de IDSes no se contemplen estos casos.

Una de las primeras cosas que deberíamos plantearnos a la hora de hablar de IDSes es si real-
mente necesitamos uno de ellos en nuestro entorno de trabajo; a fin de cuentas, debemos tener ya
un sistema de protección perimetral basado en cortafuegos, y por si nuestro firewall fallara, cada
sistema habría de estar configurado de una manera correcta, de forma que incluso sin cortafuegos
cualquier máquina pudiera seguirse considerando relativamente segura. La respuesta es, sin duda,
sí; debemos esperar que en cualquier momento alguien consiga romper la seguridad de nuestro
entorno informático, y por tanto hemos de ser capaces de detectar ese problema tan pronto como
sea posible (incluso antes de que se produzca, cuando el potencial atacante se limite a probar suerte
contra nuestras máquinas). Ningún sistema informático puede considerarse completamente seguro,
pero incluso aunque nadie consiga violar nuestras políticas de seguridad, los sistemas de detección
de intrusos se encargarán de mostrarnos todos los intentos de multitud de piratas para penetrar en
nuestro entorno, no dejándonos caer en ninguna falsa sensación de seguridad: si somos conscientes
de que a diario hay gente que trata de romper nuestros sistemas, no caeremos en la tentación de
pensar que nuestras máquinas están seguras porque nadie sabe de su existencia o porque no son
interesantes para un pirata.

Los sistemas de detección de intrusos no son precisamente nuevos: el primer trabajo sobre esta
materia ([And80]) data de 1980; no obstante, este es uno de los campos más en auge desde hace
ya unos años dentro de la seguridad informática. Y no es extraño:
la capacidad para detectar y
responder ante los intentos de ataque contra nuestros sistemas es realmente muy interesante. Du-
rante estos veinte años, cientos de investigadores de todo el mundo han desarrollado, con mayor o
menor éxito, sistemas de detección de todo tipo, desde simples procesadores de logs hasta comple-
jos sistemas distribuidos, especialmente vigentes con el auge de las redes de computadores en los
últimos años; una excelente perspectiva histórica de algunos de ellos puede encontrarse en [Lis95]
o [Axe98].

2 Clasificación de los IDSes

Generalmente existen dos grandes enfoques a la hora de clasificar a los sistemas de detección de
intrusos: o bien en función de qué sistemas vigilan, o bien en función de cómo lo hacen.

Si elegimos la primera de estas aproximaciones tenemos dos grupos de sistemas de detección de
intrusos: los que analizan actividades de una única máquina en busca de posibles ataques, y los que
lo hacen de una subred (generalmente, de un mismo dominio de colisión) aunque se emplazen en
uno sólo de los hosts de la misma. Esta última puntualización es importante: un IDS que detecta
actividades sospechosas en una red no tiene porqué (y de hecho en la mayor parte de casos no suele
ser así) ubicarse en todas las máquinas de esa red.

• IDSes basados en red.

Un IDS basado en red monitoriza los paquetes que circulan por nuestra red en busca de
elementos que denoten un ataque contra alguno de los sistemas ubicados en ella; el IDS puede
situarse en cualquiera de los hosts o en un elemento que analice todo el tráfico (como un HUB
o un enrutador). Esté donde esté, monitorizará diversas máquinas y no una sola: esta es la
principal diferencia con los sistemas de detección de intrusos basados en host.

• IDSes basados en máquina.

Mientras que los sistemas de detección de intrusos basados en red operan bajo todo un dominio
de colisión, los basados en máquina realizan su función protegiendo un único sistema; de una
forma similar – guardando las distancias, por supuesto – a como actúa un escudo antivirus
residente en MS-DOS, el IDS es un proceso que trabaja en background (o que despierta
periódicamente) buscando patrones que puedan denotar un intento de intrusión y alertando
o tomando las medidas oportunas en caso de que uno de estos intentos sea detectado.

Algunos autores ([Gra00]) dividen el segundo grupo, el de los sistemas de detección de intrusos
basados en máquina, en tres subcategorías:

• Verificadores de integridad del sistema (SIV).

Un verificador de integridad no es más que un mecanismo encargado de monitorizar archivos de
una máquina en busca de posibles modificaciones no autorizadas, por normal general backdoors
dejadas por un intruso (por ejemplo, una entrada adicional en el fichero de contraseñas o un
/bin/login que permite el acceso ante cierto nombre de usuario no registrado). El SIV más
conocido es sin duda Tripwire; la importancia de estos mecanismos es tal que en la actualidad
algunos sistemas Unix integran ‘de serie’ verificadores de integridad, como Solaris y su ASET
(Automated Security Enhancement Tools).

• Monitores de registros (LFM).

Estos sistemas monitorizan los archivos de log generados por los programas – generalmente
demonios de red – de una máquina en busca de patrones que puedan indicar un ataque o una
intrusión. Un ejemplo de monitor puede ser swatch, pero más habituales que él son los pe-
queños shellscripts que casi todos los administradores realizan para comprobar periódicamente
sus archivos de log en busca de entradas sospechosas (por ejemplo, conexiones rechazadas
en varios puertos provenientes de un determinado host, intentos de entrada remota como
root. . . ).

• Sistemas de decepción.

Los sistemas de decepción o tarros de miel (honeypots), como Deception Toolkit (DTK), son
mecanismos encargados de simular servicios con problemas de seguridad de forma que un
pirata piense que realmente el problema se puede aprovechar para acceder a un sistema,
cuando realmente se está aprovechando para registrar todas sus actividades. Se trata de un
mecanismo útil en muchas ocasiones – por ejemplo, para conseguir ‘entretener’ al atacante
mientras se tracea su conexión – pero que puede resultar peligroso: ¿qué sucede si el propio
sistema de decepción tiene un bug que desconocemos, y el atacante lo aprovecha para acceder
realmente a nuestra máquina?

Realmente esta división queda algo pobre, ya que cada día se avanza más en la construcción de
sistemas de detección de intrusos basados en host que no podrían englobarse en ninguna de las

subcategorías anteriores.

La segunda gran clasificación de los IDSes se realiza en función de cómo actúan estos sistemas;
actualmente existen dos grandes técnicas de detección de intrusos ([Sun96]): las basadas en la de-
tección de anomalías (anomaly detection) y las basadas en la detección de usos indebidos del sistema
(misuse detection). Aunque más tarde hablaremo