Siguiente: Implementación real de un
Subir: Sistemas de detección de
Anterior: Detección de anomalías
Índice General
Dentro de la clasificación de los sistemas de detección de intrusos en
base a su forma de actuar, la segunda gran familia de modelos es la formada por
los basados en la detección de usos indebidos. Este esquema se basa en
especificar de una forma más o menos formal las potenciales intrusiones que
amenazan a un sistema y simplemente esperar a que alguna de ellas ocurra; para
conseguirlo existen cuatro grandes aproximaciones ([Ko96]): los
sistemas expertos, los análisis de transición entre estados, las reglas de
comparación y emparejamiento de patrones (pattern matching) y la
detección basada en modelos.
Los primeros sistemas de detección de usos indebidos, como NIDES
([L+92]), se basaban en los sistemas expertos para realizar su trabajo;
en ellos las intrusiones se codifican como reglas de la base de conocimiento
del sistema experto, de la forma genérica if-then (if CONDICIÓN then ACCIÓN). Cada una de estas reglas
puede detectar eventos únicos o secuencias de eventos que denotan una
potencial intrusión, y se basan en el análisis - generalmente en tiempo
real - de los registros de auditoría proporcionados por cualquier sistema
Unix: esta es una de las principales ventajas de los sistemas expertos, el hecho
de que el mecanismo de registro dentro de Unix venga proporcionado `de serie',
ya que de esta forma el sistema de detección trabaja siempre por encima del
espacio del sistema operativo, algo que facilita enormemente su integración
dentro de diferentes clones de Unix.
Podemos pensar en un caso real que nos ayude a comprender el funcionamiento de
los sistemas expertos a la hora de detectar intrusiones; el típico
ejemplo es la detección de un mismo usuario conectado simultáneamente desde
dos direcciones diferentes. Cada vez que un usuario se autentica correctamente
en el sistema, cualquier Unix genera una línea de registro que se guarda
en el fichero de log correspondiente; así, al conectar a un servidor
Linux Slackware vía SSH, se registra el evento de esta forma:
May 27 03:08:27 rosita sshd[5562]: User toni, coming from anita, authenticated.
Al leer este registro, un sistema experto comprobaría si el usuario toni ya tiene una sesión abierta desde una máquina diferente de anita; si esta condición se cumple (recordemos la forma genérica de las
reglas del sistema experto, if-then) se realizaría la acción
definida en la regla correspondiente, por norma generar una alarma dirigida al
responsable de seguridad del sistema.
La segunda implementación de los sistemas de detección de usos indebidos
era la basada en los análisis de transición entre estados ([PK92]);
bajo este esquema, una intrusión se puede contemplar como una secuencia de
eventos que conducen al atacante desde un conjunto de estados inicial a un
estado determinado, representando este último una violación
consumada de nuestra seguridad. Cada uno de esos estados no es más que una
imagen de diferentes parámetros del sistema en un momento determinado, siendo
el estado inicial el inmediatamente posterior al inicio de la intrusión, y el
último de ellos el resultante de la completitud del ataque; la idea es que
si conseguimos identificar los estados intermedios entre ambos, seremos capaces
de detener la intrusión antes de que se haga efectiva.
Sin duda el sistema de detección basado en el análisis de transición
entre estados más conocido es USTAT ([Ilg92]), basado en STAT ([Por92]). Este modelo fué desarrollado inicialmente sobre
SunOS 4.1.1 (en la actualidad está portado a Solaris 2), y utiliza los
registros de auditoría generados por el C2 Basic Security
Module de este operativo. En USTAT, estos registros del C2-BSM son
transformados a otros de la forma S, A, O, representando cada uno
de ellos un evento de la forma `el sujeto S realiza la acción A sobre el
objeto O'; a su vez, cada elemento de la terna anterior está formado por
diferentes campos que permiten identificar unívocamente el evento
representado. El sistema de detección utiliza además una base de datos -
realmente, se trata de simples ficheros planos - formada principalmente por
dos tablas, una donde se almacenan las descripciones de los diferentes estados
(SDT, State Description Table) y otra en la que se almacenan las
transiciones entre estados que denotan un potencial ataque (SAT, Signature
Action Table). Cuando USTAT registre una sucesión determinada de
eventos que representen un ataque entrará en juego el motor de decisiones, que
emprenderá la acción que se le haya especificado (desde un simple mensaje
en consola informando de la situación hasta acciones de respuesta automática
capaces de interferir en tiempo real con la intrusión).
La tercera implementación que habíamos comentado era la basada en el
uso de reglas de comparación y emparejamiento de patrones o pattern
matching ([SG91], [KS94c]); en ella, el
detector se basa en la premisa de que el sistema llega a un estado comprometido
cuando recibe como entrada el patrón de la intrusión, sin importar el
estado en que se encuentre en ese momento. Dicho de otra forma, simplemente
especificando patrones que denoten intentos de intrusión el sistema puede
ser capaz de detectar los ataques que sufre, sin importar el estado inicial en
que esté cuando se produzca dicha detección, lo cual suele representar una
ventaja con respecto a otros modelos de los que hemos comentado.
Actualmente muchos de los sistemas de detección de intrusos más conocidos
(por poner un ejemplo, podemos citar a SNORT o RealSecure) están
basados en el pattern matching. Utilizando una base de datos de patrones
que denotan ataques, estos programas se dedican a examinar todo el tráfico
que ven en su segmento de red y a comparar ciertas propiedades de cada trama
observada con las registradas en su base de datos como potenciales ataques; si
alguna de las tramas empareja con un patrón sospechoso, automáticamente se
genera una alarma en el registro del sistema. En el punto 18.8.2
hablaremos con más detalle del funcionamiento de SNORT, uno de los
sistemas de detección de intrusos basados en red más utilizado en entornos
con requisitos de seguridad media.
Por último, tenemos que hablar de los sistemas de detección de intrusos
basados en modelos ([GL91]); se trata de una aproximación
conceptualmente muy similar a la basada en la transición entre estados, en el
sentido que contempla los ataques como un conjunto de estados y objetivos, pero
ahora se representa a los mismos como escenarios en lugar de hacerlo como
transiciones entre estados. En este caso se combina la
detección de usos indebidos con una deducción o un razonamiento que
concluye la existencia o inexistencia de una intrusión; para ello, el sistema
utiliza una base de datos de escenarios de ataques, cada uno de los cuales
está formado por una secuencia de eventos que conforman el ataque. En cada
momento existe un subconjunto de esos escenarios, denominado de escenarios
activos, que representa los ataques que se pueden estar presentando en el
entorno; un proceso denominado anticipador analiza los registros de
auditoría generados por el sistema y obtiene los eventos a verificar en
dichos registros para determinar si la intrusión se está o no produciendo
(realmente, al ser esos registros dependientes de cada sistema Unix, el
anticipador pasa su información a otro proceso denominado planner, que
los traduce al formato de auditoría utilizado en cada sistema). El
anticipador también actualiza constantemente el conjunto de escenarios
activos, de manera que este estará siempre formado por los
escenarios que representan ataques posibles en un determinado momento y no por
la base de datos completa.
Hasta hace poco tiempo no existían sistemas de detección de intrusos
basados en modelos funcionando en sistemas reales ([Kum95]), por lo que
era difícil determinar aspectos como su eficiencia a la hora de detectar
ataques. En 1998 se presentó NSTAT ([Kem98]), una extensión de
USTAT (del cual hemos hablado antes) a entornos distribuidos y redes de
computadores, y en el que se combina el análisis de transición entre
estados con la detección de intrusos basada en modelos. A pesar de todo, este
modelo es el menos utilizado a la hora de detectar ataques y efectuar respuestas
automáticas ante los mismos, especialmente si lo comparamos con los basados en
la comparación y emparejamiento de patrones.
Los IDSes basados en la detección de usos indebidos son en principio más
robustos que los basados en la detección de anomalías: al conocer la
forma de los ataques, es teóricamente extraño que generen falsos positivos
(a no ser que se trate de un evento autorizado pero muy similar al patrón de
un ataque); es necesario recalcar el matiz `teóricamente', porque como
veremos más adelante, la generación de falsos positivos es un problema a la
hora de implantar cualquier sistema de detección. No obstante, en este mismo
hecho radica su debilidad: sólo son
capaces de detectar lo que conocen, de forma que si alguien nos lanza un ataque
desconocido para el IDS éste no nos notificará ningún problema; como ya
dijimos, es algo similar a los programas antivirus, y de igual manera que cada
cierto tiempo es conveniente (en MS-DOS y derivados) actualizar la versión
del antivirus usado, también es conveniente mantener al día la base de
datos de los IDSes basados en detección de usos indebidos. Aún así,
seremos vulnerables a nuevos ataques.
Otro grave problema de los IDSes basados en la detección de usos indebidos
es la incapacidad para detectar patrones de ataque convenientemente camuflados.
Volviendo al ejemplo de los antivirus, pensemos en un antivirus que base su
funcionamiento en la búsqueda de cadenas virales: lo que básicamente hará
ese programa será buscar cadenas de código hexadecimal pertenecientes a
determinados virus en cada uno de los archivos a analizar, de forma que si
encuentra alguna de esas cadenas el software asumirá que el fichero
está contaminado. Y de la misma forma que un virus puede ocultar su presencia
simplemente cifrando esas cadenas (por ejemplo de forma semialeatoria utilizando
eventos del sistema, como el reloj), un atacante puede evitar al sistema de
detección de intrusos sin más que insertar espacios en blanco o rotaciones
de bits en ciertos patrones del ataque; aunque algunos IDSes son capaces
de identificar estas transformaciones en un patrón, otros muchos no lo hacen.
Siguiente: Implementación real de un
Subir: Sistemas de detección de
Anterior: Detección de anomalías
Índice General
2003-08-08