Entorno de implementación

El sistema fue desarrollado para correr sobre plataformas UNIX, en una máquina conectada a la red (LAN, WAN o Intranet) en la cual residen los sistemas a proteger. Para llevar a cabo su tarea sólo requiere que los equipos donde residen las fuentes de información soporten un protocolo de transferencia segura de información basado en TCP/IP. La existencia de una implementación de tal protocolo, aunque probable, nos resulta desconocida, sin embargo asumimos características muy similares a las de FTP con el agregado de que la información es encriptada antes de ser transferida.

Descripción informal del diseño

La función del sistema, básicamente, consiste en detectar en tiempo (casi) real, la presencia de atacantes en un sistema informático y tomar medidas para detener la intrusión.

El sistema funciona reuniendo información de auditoría de las fuentes que hayan sido indicadas por el administrador. Esta información es comparada con ciertos puntos límites establecidos durante la configuración y, en caso de que alguno de los datos recogidos exceda uno de éstos, se tomarán acciones en consecuencia. El diseño modular de las partes del sistema en contacto con los equipos a proteger hace que éste sea multiplataforma, es capaz de proteger máquinas que funcionen con diferentes sistemas operativos como Unix/Linux, Windows 98/NT, etc.

Los procesos de configuración y administración se realizan mediante una interfaz basada en tecnología Web/Java, pudiendo el administrador operarla tanto en forma local como remota. En la terminal local el estado del sistema, así como el acceso a las opciones de administración, están disponibles en todo momento. Mediante cualquier browser que soporte Java es posible acceder al estado y demás opciones tal como si se tratara de la interfaz local (de hecho ésta es también un browser sólo que no puede ser cerrado ni minimizado). Por medio de una conexión segura, luego de ingresar una clave, el administrador puede seleccionar los diferentes parámetros como fuentes de información, puntos límites y acciones a seguir (bloqueo de cuentas, envío de email a los administradores, etc.).

El IDS almacena el progreso de las intrusiones pasadas y las acciones tomadas por el sistema. Con esto es posible configurarlo para que detecte posible patrones de violación. Cada vez que se da un código de error el IDS comparará este con la informacion almacenada tratando de encontrar una concordancia. El fabricante provee paquetes de intrusiones ya definidas con las acciones a tomar en cada caso.

Según la clasificación de los sistemas de detección de intrusos dada en [K00], éstos se dividen, según la procedencia de la información de auditoría, en: basados en hosts y basados en redes. Además, dependiendo del modo en que detectan las intrusiones un IDS puede funcionar por detección de funcionamiento anómalo o por detección de signaturas. Brevemente, un IDS basado en hosts obtiene información de fuentes que se encuentran en cada uno de los equipos a proteger y toma decisiones sobre ese tipo de información. A diferencia de esto, los sistemas basados en redes obtienen información de los ruteadores de la misma y la utilizan para detectar ataques. En cuanto al otro aspecto, las detecciones de funcionamiento anómalo se basan en puntos límites y los rangos entre los mismos, mientras que las detecciones de signaturas comparan la actividad actual del sistema con actividades pasadas registradas en una base de datos.

De acuerdo a esto podemos decir que hemos diseñado un IDS basado en hosts que funciona detectando tanto funcionamiento anómalo como signaturas o lo que en nuestro desarrollo denominamos historia tipada de intrusiones. En la referencia citada se menciona que, si bien un IDS basado en hosts es más eficiente (en términos del número de intrusiones reales detectadas) que uno basado en redes, una desventaja es que parte del software debe ser instalada en cada una de las máquinas de la red a proteger. Cabe destacar que por la forma de obtención de la información que elegimos para nuestro sistema esto no es necesario. Los traductores acceden a las fuentes por medio de un protocolo standard y, ejecutando en el mismo equipo que el resto del IDS llevan a cabo la correspondiente traducción.

El diseño fue realizado siguiendo las líneas del estilo descipto en la sección Descripción del Estilo Arquitectónico. Por esto puede notarse una clara distinción entre tres partes del sistema: el administrador de eventos que lleva a cabo la manipulación de los eventos, el conjunto de repositorios que contienen la información con la cual trabaja el IDS conformado la porción pasiva del sistema y la parte activa o funcional que realiza las tareas esenciales. Hay además un módulo dónde se definen en forma centralizada los tipos utilizados por todo el sistema.
Justficamos la elección de un estilo mixto ya que no se espera que la parte pasiva del sistema, esto es, los repositores, modifique o extienda su funcionalidad. El hecho de ser entidades pasivas que sólo brindan acceso a los datos que guardan justifica esta observación. Haber optado por un estilo de invocación implícita puro hubiera requerido que todas las llamadas a procedimiento se den por medio del administrador de eventos, incluso las necesarias para obtener o modificar los valor de los campos en los repositorios. Esto ocasionaría una carga excesiva en el administrador de eventos llevando a una reducción importante en la eficiencia que consideramos innecesaria.

Comencemos describiendo el diseño del Administrador de Eventos. El módulo correspondiente se denomina ADM_EVENTOS y, si bien constituye el corazón del manejo de los eventos de todo el sistema, su diseño es propiamente orientado a objetos. El funcionamiento del módulo es como se describió en el estilo. Presenta los métodos de intefaz necesarios para que otros módulos anoten o borren procedimientos o listas de procedimientos en la tabla que oculta y los procedimientos a ser llamados para anunciar un evento. Lo que para los demás módulos es levantar un evento, para el administrador de eventos no es más que una llamada a los procedimientos que se encargan de buscar en la tabla el evento correspondiente, invocar los procedimientos asociados al mismo y, de ser necesario, retornar un valor al anunciante. En la descripción del estilo se encuentran las decisiones que tomamos para definir al mismo con una explicación detallada de cada una. Estas decisiones se reflejan en forma total en el diseño del Administrador de Eventos. En la guía de módulos es posible encontrar una descripción de cada una de las funciones que componen la interfaz.

Los repositorios, siguiendo el estilo descripto, se diseñaron orientados a objetos y son pasivos, o sea, no levantan eventos. Cada uno es un módulo lógico que contiene los submódulos que definen las líneas y tablas correspondientes, a excepción de FUENTES_DISPONIBLES y ACCIONES_DISPONIBLES que, debido a su sencillez, no contienen submódulos. Los módulos repositorios son:

La parte activa del sistema está formada por módulos que se comunican entre sí mediante eventos a través del administrador de eventos y acceden a los repositorios por medio de llamadas a procedimientos habituales. En este sector del sistema el estilo podría decirse puro en el sentido en que dos módulos activos no pueden comunicarse si no es por medio de eventos. Hay excepciones de este hecho ya que el procedimiento de inicialización del sistema invoca en forma directa los procedimientos de inicialización de algunos de los módulos activos. Esto se justifica ya que en caso de usar eventos, el mismo procedimiento de inicialización debería crear la asociación (binding) entre tales eventos y los procedimientos que se ejecuten para luego anunciar los eventos recien creados, todo determinado en tiempo de compilación, y como la invocación se utilizaría una única vez (la inicialización de esos módulos activos se da sólo al instalar el sistema), luego de anunciados los eventos sería neliminados del administrador. Todo esto tiene poco sentido ya que no ofrece mayor flexibilidad y demora el proceso de inicialización del sistema.

Los módulos, determinados según las funciones que cumplen, son:

Describimos ahora el funcionamiento del sistema desde la instalación:

Al instalar el sistema, la interfaz solicita al usuario los datos necesarios para configurar las generalidades del IDS (password, lugar de almacenamiento de la información, etc.) mediante el módulo GENERAL de CONFIGURACION. Una vez reunida la información necesaria se inicializa el sistema. Este procedimiento crea cada una de las tablas de los repositorios y llena las listas de fuentes y acciones disponibles. Además inicia al administrador de eventos e incluye en su tabla las asociaciones entre eventos y procedimientos determinadas en tiempo de compilación. También inicializa los módulos de AUDITORIA y PAQUETES. Finalmente se incia una función (que correrá mientras el sistema esté activo) encargada de asegurar que la información cumpla con los parámetros generales establecidos (por ejemplo el tiempo de vida de la información de auditoría).
Luego de este primer paso, el administrador debe seleccionar las fuentes a ser auditada. La interfaz presentará para esto una lista (obtenida de FUENTES_DISPONIBLES) de los tipos de fuente que puede elegir. Cada tipo de fuente puede ser instanciado más de una vez, por ejemplo, sería posible controlar los logins fallidos en varias computadoras a la vez. Al seleccionar una fuente la interfaz pedirá los parámetros necesarios para ubicar físicamente a la misma: IP de la máquina que la contiene, puerto donde funciona el protocolo de transferencia y path donde ubicar la fuente en el sistema de archivo (según sea necesario). Seguido, el administrador agrega los puntos límites para esa instancia de la fuente elegida y por cada uno las acciones a tomar en caso de que sea excedido. Las acciones son elegidas de una lista presentada por la interfaz proveniente de ACCIONES_DISPONIBLES, cada acción deberá ser configurada apropiadamente (por ejemplo, si se desea que el sistema envíe un e-mail, deberá especificarse el destinatario y el cuerpo del mensaje a enviar). Una vez reunida, toda esta información es brindada a PAQUETES, que realiza las operaciones necesarias para que el sistema comience a monitorear y auditar la información en la nueva fuente. Una descripción más detallada del procedimiento realizado para esto puede encontrarse en la guía de módulos, sección PAQUETES.
Al agregar una nueva fuente, esta tiene asociado un traductor capaz de convertir las información en la fuente a un formato normal con el cual el sistema puede trabajar. Desde el momente en que PAQUETES agrega la fuente, el traductor asociado estará monitoreando la misma para detectar y anunciar cualquien novedad. Cuando esto ocurre, el traductor agrega una línea en el repositorio INFO_A_AUDI y levanta un evento para informar de ello al resto del sistema. A esto responde el módulo AUDITOR, que recupera la información y determina si se ha excedido algún punto límite para esa instancia de la fuente, utilizando para ello la información de INFO_CONFI. En caso de que esto ocurra, anuncia un evento acompañado de los parámetros que identifican lo ocurrido. A esto reacciona TRADUCTOR_EVENTOS que, luego de determinar, a partir de la prioridad registrada para esa instancia de fuente en INFO_CONFI, si debe buscar una coincidencia entre las intrusiones pasadas, anuncia el evento correspondiente a partir de dicha decisión registrando el hecho en INFO_HISTO_SIN_PROC. El evento resultante estará asociado a una lista de reactores los cuales causarán el efecto esperado.
Eventualmente el administrador puede realizar tareas de mantenimiento del sistema las cuales son: tipar intrusiones; modificar, agregar o quitar instancias de fuentes; o extender la capacidad del sistema creando nuevas fuentes/traductores o acciones/reactores.
Para tipar historia, la interfaz presentará al usuario la información registrada como historia sin procesar, éste podrá entonces seleccionar aquellas entradas que considere pertenecientes a un mismo ataque, dar un nombre al mismo y a continuación seleccionar y configurar las acciones que el sistema deberá tomar en caso que se repita. Con esta informacion el módulo TIPIFICACION_HISTORIA se encarga de agregar una línea en el repositorio INFO_HISTO_TIPADA y lo necesario para reflejar el cambio en el sistema. Una descripción más detallada del procedimiento realizado para esto puede encontrarse en la guía de módulos, sección TIPIFICACION_HISTORIA.
El proceso de modificación, agregado o elimninación de paquetes es similar al descripto más arriba luego de la instalación del sistema.
Para extender las capacidades del sistema la interfaz pide al usuario los archivos que contienen el código del traductor (o reactor) a agregar, con esto genera nuevo módulo y agrega la entrada correspondiente en la tabla de fuentes (o acciones) disponibles, además de lo necesario para que es el sistema sea capaz de manejar el nuevo componente. Una descripción más detallada del procedimiento realizado para esto puede encontrarse en la guía de módulos, sección EXTENSION.

Argumentación de Pertenencia al Estilo

En la explicación precedente es fácil ver que el diseño pertenece al estilo descripto en la sección Descripción del Estilo Arquitectónico. Las decisiones tomadas que terminan de definir el estilo se basaron en las necesidades que surgieron para efectuar el diseño, en su mayoría centradas en el administrador de eventos. De hecho, las varias referencias al estilo que aparecen en la sección anterior reflejan claramente esto. También se respetó estrictamnete la restricción impuesta sobre la pertenencia de los módulos a los subestilos; esto es, todos los módulos de nuestro diseño pertenecen a uno y sólo uno de los subestilos que conforman al estilo mixto.

Ventajas de Tool Abstraction sobre OO

Las ventajas reflejadas en nuestro sistema, a partir de la utilización del estilo de Invocación Implícita (Tool Abstrction) en contraposición con la utilización de el estilo Orientado a Objetos (OO), radican fundamentalmente, en las posibilidades que el primero brinda para la extensión del sistema y la independencia total entre los módulos. En cuanto a la parte extensible del IDS, el estilo eligido provee la posibilidad de agregar y/o modificar relaciones entre los procedimientos de los distintos módulos, sin la necesidad de recompilar el sistema una vez hecha la adición. Esto es debido a que la esencia de agregar un relación entre dos procedimientos consiste, simplemente, en registrar una nueva línea en el administrador de eventos y no en la modificación interna de uno o varios módulos. Todo esto no es posible en el diseño OO ya que la interacción entre los procedimientos se da directamente por medio de sus interfaces y agregar o modificar las relaciones (esto es llamadas a procedimiento) requiere cambios en internos en los módulos afectados. Además, el hecho de que un módulo sólo se ocupa de realizar ciertas tareas ignorando la existencia de los otros y anunciando eventos al resto del sistema sin saber que efecto tiene esto, facilita no sólo las modificaciones en tiempo de ejecución, sino también el diseño de nuestro sistema, incluso con las características de dinamismo que este tiene.
Obviamente todo lo anterior se aplica a lo que llamamos parte activa del sistema, o sea, aquellos módulos que utilizan eventos para comunicarse entre sí. Como ya fue mencionado, la parte del sistema consistente en el conjunto de repositorios fue diseñada en el estilo OO por razones antes descriptas.

Referencias

[K00] Kent, S., On the trail of intrusion into information systems, IEEE Spectrum, 52-56, diciembre 2000.