En este capítulo se describe en detalle el modelo más aceptado para la detección de intrusiones. Tiene tres funciones principales, la fase de recogida de datos (fuentes de información), la fase de análisis, y la fase de respuesta. En líneas generales, para que la detección de intrusiones pueda obtener buenos resultados, debe llevar a cabo un proceso de recopilación de información, que posteriormente deberá someter a diversas técnicas de análisis, y en función de los datos obtenidos tendrá que dar algún tipo de respuesta.

3.1 Fuentes de información

Como se comentó en el capítulo anterior, la detección de intrusiones se puede clasificar según las fuentes de información que utiliza. Aquí se estudiaran los casos pertenecientes a la recopilación de datos basados en máquina, en red, y en fuentes externas como sistemas de seguridad físicos. Explicados en ese orden, se tratan las capas de menor a mayor nivel de abstracción.

Ninguno de los sistemas de detección de intrusiones en particular es mejor que los otros. La elección de una detección de intrusiones basada en máquina, red o cualquier otra, depende de las necesidades particulares. A veces basta con instalar un detector en algunos tramos de red, mientras que en otras ocasiones es necesario incrementar la seguridad recogiendo datos de las máquinas.

3.1.1 Fuentes de información basadas en máquina

Este tipo de fuentes de información consisten principalmente en registros de auditoría de sistemas operativos (registros generados por mecanismos del sistema operativo), y los registros de sistema (ficheros generados por el sistema y aplicaciones, generalmente ficheros de texto generados línea a línea). Los monitores basados en múltiples "hosts" utilizan las mismas fuentes, por lo que los apartados a continuación también son aplicables a estos.

3.1.1.1 Registros de auditoría

El primer elemento de importancia en sistemas de detección basados en máquina son los registros de auditoría. Estos registros son una colección de información sobre las actividades del sistema, creados cronológicamente y dispuestos en un conjunto de ficheros de auditoría. Estos registros son originados por los usuarios y los procesos y comandos que estos invocan. Muchos de los registros de auditoría fueron creados originalmente para cumplir los requisitos del Programa de Evaluación de Productos Fiables (TCSEC), una iniciativa del gobierno estadounidense. El TCSEC, también conocido como Libro Naranja, define las características requeridas por los sistemas operativos de uso comercial y las aplicaciones de software que contuvieran o procesaran información clasificada. [1]

Por aquel entonces, el Libro Naranja presentaba un problema, ya que presentaba extensos requerimientos de auditoría, pero no las directrices para su utilización. Listaba una gran cantidad sucesos que debían ser registrados, pero posteriormente no explicaba la forma de seleccionarlos. Tampoco explicaba de qué modo o con qué estructura debían ser almacenados los registros de auditoría. Por lo tanto, los fabricantes crearon numerosas y variadas soluciones para cumplir los requerimientos de auditoría de la clase C2(1). Los desarrolladores de detección de intrusiones que se familiarizaban con los registros de auditoría de un sistema operativo no comprendían los registros generados por otro sistema, que podía estar cumpliendo los mismos requerimientos.

Los fabricantes utilizaron al menos dos soluciones en sus sistemas de auditoría. Una creaba registros "autónomos", que no necesitaban de otros registros para su interpretación. La eliminaba información redundante en los registros almacenando la información de un evento en registros múltiples.

Los sistemas de detección de intrusiones hacen un uso importante de la información contenida en los registros de auditoría. Desgraciadamente, gran parte de los sistemas operativos comerciales existentes no cumplen con los requisitos de auditoría necesarios, a pesar de la documentación que hay sobre el tema. Esto dificulta la labor a los desarrolladores de detección de intrusiones. Algunos han sugerido que para una detección de intrusiones basada en máquina sea efectiva es necesario añadir funcionalidades al núcleo del sistema para que genere la información de auditoría necesaria. Esto provoca costes en el rendimiento del sistema, y costes asociados al mantenimiento de las alteraciones de los sistemas operativos. [2]

No obstante, muchos desarrolladores prefieren utilizar los registros de auditoría frente otras fuentes de información por varias razones. Una de ellas es que la propia estructura del sistema operativo está diseñada para otorgar suficiente seguridad al sistema de auditoría, y los registros que este genera. Otro de los motivos que les llevan a esta decisión es que el sistema de auditoría trabaja a bajo nivel, por lo que ofrece mayor nivel de detalle que el que puede ofrecer otro mecanismo.

Sin embargo, es importante resaltar que obtener datos excesivamente detallados dificulta la diferenciación entre las actividades originadas directamente por usuarios y aquellas originadas por programas que han tomado la identidad de un usuario. Hay numerosos ataques que explotan la capacidad de los programas para asumir la identidad de un usuario que tiene mayores privilegios que el actual. Para detectar esta clase de ataques, la fuente de datos debe proporcionar suficiente información para permitir la diferenciación entre usuario y proceso.

3.1.1.2 Contenido de los registros de auditoría

Los eventos de sistema contienen información sobre la actividad del sistema como del objeto que la ha originado. Los sistemas operativos comerciales guardan eventos a nivel de núcleo (llamadas de sistema) y a nivel de usuario (eventos de aplicación). Para identificar a los procesos y a los usuarios, se proporciona información inequívoca sobre los procesos e identificadores de usuario (userID). A veces incluso se registra el userID original, y el userID adoptado por el proceso, si este ha cambiado.

A continuación se explicará la estructura del sistema de auditoría de dos sistemas operativos: Sun, el Basic Security Module (BSM) y Windows NT.

3.1.1.2.1 Solaris BSM

El Módulo de Seguridad Básico de Sun se ha diseñado para cumplir los requisitos del TCSEC C2.

La estructura del subsistema de auditoría de BSM consiste en un registro ("log") de auditoría, varios ficheros de auditoría, informes ("records") de auditoría, y testigos ("tokens") de auditoría.

Un registro de auditoría consiste en un conjunto de ficheros de auditoría, que a su vez están compuestos por varios informes de auditoría. Estos informes, como se verá más adelante, están formados por varios testigos de auditoría.

Figura 3‑1 - Estructura de los registros de auditoría BSM

Cada informe de auditoría se almacena en formato binario y describe cada evento ocurrido, e incluye información tal como quién hizo la acción, qué ficheros están involucrados, qué acción tuvo lugar y dónde y cómo sucedió. [3]

La Figura 3‑2 muestra el conjunto de testigos que constituyen un informe de auditoría.

Figura 3‑2 - Estructura de un informe ("record") de auditoría BSM

Hay eventos generados a nivel de núcleo ("kernel-level audit events") y a nivel de usuario ("user-level audit events"). La estructura de ambos es similar.

Para facilitar la labor de la auditoría, los eventos están organizados por clases ("audit classes"). Existen 32 clases de auditoría.

Para configurar la auditoría se utilizan indicadores de auditoría ("audit flags"), que permiten especificar qué clases eventos auditar.

El sistema operativo ofrece algunas herramientas para la gestión de los eventos de auditoría. De esta manera, se puede utilizar el comando praudit para traducir los historiales de auditoría almacenados en binario en un formato legible para el usuario. Por otra parte, auditreduce permite realizar filtrados de los eventos generados, a partir de parámetros como intervalos de tiempo, determinados identificadores de usuarios, o determinados eventos de sistema.

3.1.1.2.2 Windows NT/2000

Este sistema operativo genera tres tipos de eventos de sistema:

· Eventos de sistema operativo.

· Eventos de seguridad.

· Eventos de aplicación.

Los eventos de sistema son los que generan los componentes de Windows. Son sucesos relacionados con fallos de controladores u otros objetos de sistema, pérdida de datos, problemas con el registro, etc. Estos tipos de eventos son predeterminados por el sistema operativo.

Los eventos de aplicación son los generados por las diferentes aplicaciones del sistema. Por ejemplo, información asociada a una base de datos, un antivirus, o una operación de copia de seguridad. Estos eventos los definen los desarrolladores de software, y los "software toolkits" (conjuntos de herramientas "software") les ayudan en esta labor.

Los eventos de seguridad son los que tienen especial relevancia en materia de seguridad. Están diseñados a partir de las definiciones del TCSEC (clase C2). Estos eventos tienen que ver con accesos a objetos, inicios y cierres de sesión, cambio de políticas de sistema, etc. A diferencia de los otros tipos de sucesos, estos sólo pueden ser accedidos por administradores, y son los más importantes para los detectores de intrusiones.

Los registros de eventos de Windows están formados por historiales de eventos. Cada historial tiene una cabecera, seguida de una descripción y, a veces, datos adicionales. La cabecera tiene los siguientes campos. La mayoría son auto explicativos: Fecha, Hora, Nombre de Usuario, nombre de Máquina, ID de evento, Fuente (una aplicación, un servicio de sistema, un controlador), Tipo (indica la gravedad del evento: un error, un aviso, una información, éxito, fracaso), Categoría (utilizado principalmente en eventos de seguridad para indicar qué evento ha tenido éxito o fracaso).

Al igual que pasa con el sistema operativo Solaris de Sun, Windows NT proporciona varios elementos para hacer más llevadera la auditoría. Existen mecanismos de filtrado de sucesos. También es posible ordenarlos, ascendente o descendentemente, según los distintos elementos que componen cada evento. Se pueden definir parámetros tales como el tamaño del archivo del registro de eventos, y cómo se debe comportar el sistema en caso de llenarse, pudiéndose detenerse inmediatamente o sobrescribir los más antiguos.

Permission Components (Windows NT and Windows 2000)	Permission Types (Windows NT)
Permission Components (Windows NT and Windows 2000)	Read (R)	Write (W)	Execute (X)	Delete (D)	Change Permissions (P)	Take Ownership (O)
Traverse Folder / Execute File			•
List Folder / Read Data	•
Read Attributes	•		•
Read Extended Attributes	•
Create Files / Write Data		•
Create Folders / Append Data		•
Write Attributes		•
Write Extended Attributes		•
Delete Subfolders and Files
Delete				•
Read Permissions	•	•	•
Change Permissions					•
Take Ownership						•

Tabla 3‑1 - Permisos en Windows NT y Windows 2000

La Tabla 3‑1 muestra la relación entre los permisos básicos de Windows NT (lectura, escritura, ejecución, etc.) y los distintos componentes de permisos, indicados a la izquierda, formados a partir de combinaciones de aquellos.

Establecer una política de auditoría eficaz no es trivial. Aunque se podrían auditar todos los elementos del sistema, rara vez es la solución adecuada. Por una parte, tal medida tendría un importante impacto en el rendimiento del sistema. Además, de esta forma se generan muchos más eventos, que en muchos casos son irrelevantes o inútiles, enturbiando la claridad de los datos y sobrecargando la fase de análisis.

3.1.1.3 El problema de la reducción de auditoría

La reducción de auditoría, en anglosajón "audit reduction", tiene lugar cuando se pretende eliminar información redundante o no necesaria de los registros de auditoría.

Un dato clave para llevar a cabo la reducción de auditoría es el de introducir determinismo en procesos relativamente no deterministas. Es decir, si sabemos que un suceso A siempre suele venir seguido de otros elementos dados (U, V, W) bajo ciertas condiciones (R, S), podemos determinar el suceso: A ocurre bajo condiciones R, S seguido de U, V, W, al suceso A.

Desgraciadamente, el determinismo no siempre es aplicable. Especialmente en entornos multitarea. Por ejemplo, en UNIX de Sun, un simple comando de alto nivel, como ls, en una estación de trabajo puede generar más de mil historiales de auditoría. Si este comando se repite en unos segundos puede generar un número distinto de eventos, y en diferente orden.

Existen todo tipo de mecanismos para llevar a cabo reducciones de auditoría. Desde simples filtrados de eventos según la información de alguno de sus campos. Hasta elaborados modelos matemáticos, como el "Filtro Basado en Concordancia de Patrones" [4] o la "Detección de Intrusiones utilizando patrones de rastro de auditoría de longitud variable" [5].

También hay importantes reducciones de eventos eliminando los eventos generados por procesos fiables. Aquí, los procesos fiables son aquellos certificados como soporte para obtener seguridad.

3.1.1.4 Registro de Sistema

El registro de sistema ("system log") es otro elemento importante a la hora de recopilar información del sistema. Es un fichero en el que se guardan los eventos generados por el sistema. El sistema operativo UNIX cuenta con una variedad importante de registros de sistema, relacionados por un servicio común, denominado "syslog". Este servicio genera y actualiza los registros de eventos mediante el proceso syslogd.

La seguridad de los registros de sistema es uno de los puntos débiles frente a la de los de auditoría. En este sentido, los registros de sistema son menos fiables que los de auditoría. Hay varias razones por las que esto es así. Los registros de sistema son escritos por aplicaciones, más vulnerables que el subsistema de auditoría. Por otra parte, suelen almacenarse en directorios no protegidos del sistema, relativamente fáciles de localizar y alterar. Además, están escritos en texto en claro, y no en una forma más críptica como los registros de auditoría, que siempre ayuda más a detectar cambios.

No obstante, los registros de sistema aportan información muy útil a los programas de detección de intrusiones, y complementan a los datos provenientes de los registros de auditoría. Además, son más fáciles de revisar que los registros de auditoría de sistema.

Por otra parte, siempre es más conveniente utilizar varias fuentes de información que una sola. Así, se pueden detectar signos de intrusiones a través de las discrepancias encontradas.

Para solventar los problemas de seguridad inherentes a los registros de sistema se han desarrollado diferentes métodos. Spafford y Garfinkel propusieron uno que consistía en enviar los registros de un sistema a una máquina dedicada utilizando una conexión serie [6].

3.1.1.5 Registros de sistema comunes

Como ya se explicó, existen numerosos registros de sistema. Pero no todos sirven para detectar intrusos. Los programas de recopilación de información de seguridad seleccionan los más relevantes. Los sistemas operativos basados en UNIX los almacenan en los directorios:

/usr/adm Utilizado en las primeras versiones de UNIX.

/var/adm Utilizado en versiones más modernas de UNIX.

/var/log Utilizado en algunas versiones de Linux, BSD, FreeBSD.

A continuación se muestra una tabla con los registros más utilizados por los sistemas de detección de intrusiones. Además de estos registros, los desarrolladores pueden utilizar syslogd para escribir eventos, ampliando las posibilidades de detección de intrusiones a procesos de sistema no predeterminados:

Nombre de registro	Descripción
acct or pacct	Comandos ejecutados por todos los usuarios.
aculog	Llamadas de los módems.
lastlog	Última entrada con éxito y sin éxito en el sistema de cada usuario.
loginlog	Todos los intentos de acceso sin éxito.
messages	Mensajes de salida de la consola del sistema y otros generados desde el servicio syslog.
sulog	Uso del comando "su"
utmp[x]	Dentro de este o estos directorios está la información del usuario que está en el sistema.
utmpx	utmp extendido.
wtmp[x]	Contiene un listado de tiempos de cada entrada y salida de cada usuario.
wtmpx	wtmp extendido.
xferlog	Accessos mediante FTP.

Tabla 3‑2 - Registros relativos a seguridad en Solaris

3.1.1.6 Información de aplicaciones

Hasta ahora nos hemos centrado en el nivel de sistema como fuente de información para la detección de intrusiones. El nivel de sistema se supone el más robusto e inaccesible para todos salvo los más expertos. Sin embargo, los modelos de seguridad y de protección están en constante evolución, al mismo tiempo que los sistemas operativos.

Los profesionales del campo de la detección de intrusiones piensan que en el futuro, la mayoría de los datos de importancia procederán del nivel de aplicación. Uno de los ejemplos de esta realidad es el progresivo avance de los sistemas distribuidos y los sistemas orientados a objetos. En el sistema operativo Windows NT, muchos de los eventos generados por el nivel de registro de sistema operativo han migrado a almacenes de datos de aplicación. Además, casi todos los sistemas operativos comerciales soportan la entrada de registros de auditoría generados en el nivel de aplicación.

3.1.1.6.1 Bases de datos

En las grandes organizaciones, cada vez con más frecuencia, la información se almacena y manipula mediante un sistema de gestión de bases de datos.

Uno de los aspectos más importantes de las bases de datos está relacionado con el volumen de información de auditoría que pueden generar. En algunos casos, se pueden producir "gigabytes" de datos de auditoría en cuestión de horas. Esto obliga, durante el diseño de sistemas de detección de intrusiones, a crear mecanismos de compresión para los datos, técnicas de reducción de auditoría, selección de grupos de eventos útiles descartando los no necesarios.

Los registros de las transacciones generadas por las bases de datos, al igual que los registros de sistema, no están tan protegidos como los eventos de auditoría. Pero ocurre que en las bases de datos se almacena información que los usuarios y las empresas desean proteger. Se están haciendo esfuerzos de desarrollo en este aspecto. Los sistemas de auditoría relacionados con la gestión de bases de datos son una fuente de información importante para los sistemas de detección de intrusiones. [7]

3.1.1.6.2 Servidores Web

Debido al enorme crecimiento experimentado en los últimos años del uso de estos servicios, los servidores Web son cada vez más utilizados. Muchos de estos servidores permiten la generación de valiosa información a nivel de aplicación, en forma de registros.

Aquí comentaré los formatos de los registros más estandarizados entre este tipo de aplicaciones.

Common Log Format (CLF)

Este formato fue utilizado originalmente por el servidor Web del NCSA (2), llegando a convertirse en el estándar a utilizar por los servidores Web en sus registros. La mayoría de las herramientas de análisis de registros lo soportan. Los registros CLF contienen casi toda la información necesaria para realizar estudios exhaustivos sobre la actividad de un servidor Web, cuya estructura se describe a continuación [8]:

Campo	Descripción	Ejemplos
máquina remota	Dirección IP o nombre DNS del cliente.	192.168.0.1, www.upm.es
rfc931	Identificación remota del cliente. No se aplica. "identd" es un servicio exclusivo de UNIX. La búsqueda de identidad consume mucho ancho de banda, y sobrecarga innecesariamente a los servidores. Raramente se utiliza. Si no existe se escribe un guión ("-").
Autenticación de usuario	Nombre de usuario del cliente.	diego, dggomez
Fecha y hora	Fecha y hora: formato [DD/MMM/AAAA:HH:MM:SS +-TZO].	[15/06/2003:23:23:00 +0100]
Petición	Línea de petición hecha por el cliente, entre comillas.	"GET /menu.html HTTP/1.0" "POST /form.cgi HTTP/1.0"
Estado [9]	NNN. Estado HTTP devuelto al cliente, "-" si no está disponible.	200, 406, 303
longitud	NNNNN. Número de bytes enviados al cliente, "-" si no está disponible.	1995, 573, 907, 2003

Tabla 3‑3 - Estructura de registros CLF

Un ejemplo válido de una entrada de registro CLF podría ser:

www.microsoft.com - - dggomez [10/07/2003:13:47:00 +0100] "GET /passw.txt HTTP/1.1" 200 1976

W3C Extended Log Format (ELF)

Consiste básicamente en el NSCA CLF más los campos agente de usuario ("user-agent") y URL de procedencia ("referrer URL information") sin comillas [10]. Quedando una estructura como la siguiente:

CLF user_agent referrer_URL

El siguiente registro, aunque en más de una línea por falta de espacio, podría ser un ejemplo válido de este formato:

www.euitt.upm.es - - dggomez [19/Mar/2003:21:14:55 -0200] "GET / HTTP/1.1" 200 1234 Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) http://www.euitt.upm.es/index.html

Definable Lof Format (DLF)

Este formato muy similar al ELF, pero al final de cada entrada de registro invierte los campos URL de procedencia y agente de usuario, dejándolos con o sin comillas, de la siguiente forma:

CLF "referrer_URL" "user_agent"

CLF referrer_URL user_agent

Un ejemplo de este formato, sería similar a:

138.100.52.100 - - dggomez [08/Apr/2003:16:02:20 +0100] "GET / HTTP/1.1" 200 5678 "http://www.euitt.upm.es/index.html" "Mozilla/4.05 (X11; I; IRIX64 6.4 IP30)"

Existen más formatos, como el "Binary Log Format" (BLF), muy similar al NCSA CLF pero más sintetizado, con menos campos.

La obtención de datos de aplicaciones presenta dos de los grandes retos de la detección de intrusiones a la hora de recoger información. Por un lado está el problema del tiempo. Es fundamental establecer un orden cronológico o incluir algún parámetro de tiempo en las entradas de los registros para que la información pueda ser analizada correctamente. Por otra parte tenemos el problema de la combinación de los diferentes registros, para que los usuarios puedan comprenderlos adecuadamente. El proceso de combinar varios flujos de datos para obtener otra cosa se denomina composición (posible mediante correlación previa). Cuando estos flujos sirven para crear otro de nivel de abstracción más alto, se utiliza el término de inteligencia artificial fusión. Estos dos términos son dos aspectos técnicos muy relevantes en la detección de intrusiones.

Un ejemplo de producto de detección de intrusiones basado en aplicación es Appshield, de la empresa Sanctum Inc. [11]

3.1.1.7 Información recogida de objetivos

Un monitor basado en objetivo ("target based") es muy similar a un monitor basado en máquina ("host based"). La monitorización basada en objetivo establece mecanismos para vigilar el estado de una serie de recursos valiosos del sistema, grabando periódicamente el estado de los objetos monitorizados. Estos estados se comparan con unas políticas de seguridad, registrando las posibles discrepancias.

Uno de los recursos más utilizados para la monitorización basada en objetivo es el de los verificadores de integridad. Estas herramientas se utilizan para complementar la labor de los detectores de intrusiones, monitorizando cambios en el estado de objetos de sistema, como ficheros importantes. Este enfoque es estático, no como los mecanismos de registro de auditoría o sistema, que son dinámicos. Para aclarar el concepto, se podría decir que un ejemplo estático, como la monitorización basada en objetivo, es una imagen, mientras que uno dinámico es como un vídeo. Una cámara fotográfica puede hacer imágenes a intervalos periódicos de tiempo, mientras que una cámara de vídeo, que es más cara, permite ver lo que pasa en tiempo real. Cada solución depende de las necesidades particulares. Algunas empresas no necesitan una alta velocidad de detección.

Un verificador de integridad genera una suma de comprobación ("checksum") de cada objeto de sistema y las almacena en un lugar protegido. Para fabricar la suma de comprobación se utiliza un algoritmo de resumen de mensaje ("message digest algorithm"), o función de resumen ("hash funtion"). Estos algoritmos se diseñan con dos propósitos. Primero, para que sean tan seguros que el hecho de obtener el mismo resultado utilizando dos entradas distintas sea prácticamente nulo. Y segundo, para que cualquier modificación en la entrada, por pequeña que sea, produzca una enorme diferencia en la salida.

Los monitores basados en objetivos son especialmente útiles en sistemas UNIX. La razón es que en estos sistemas operativos, cualquier objeto de interés (como conexiones de red, procesos o dispositivos) puede ser representado como un fichero. Estos objetos se representan por estructuras denominadas inodos ("inodes").

Campo	Bytes	Descripción
Mode	2	Tipo de fichero, bits de protección, "setuid", bits "setgid"
NLinks	2	Número de entradas de directorio apuntando a este inodo
Uid	2	UID del propietario del fichero
Gid	2	GID del propietario del fichero
Tamaño	4	Tamaño del fichero en "bytes"
Dirección	39	Dirección de los primero 10 bloques de disco, luego 3 bloques indirectos
Gen	1	Número de generación (Se incrementa con cada reutilización del inodo)
Atime	4	Hora en la que el inodo fue accedido por última vez
Mtime	4