MODELO DE GESTIÓN DE SEGURIDAD CON SOPORTE A SNMP

NICOLÁS BOTERO ARANA

Proyecto de grado presentado para optar el título de Ingeniero de Sistemas

Director: Ingeniero Edgar Enrique Ruiz García

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

BOGOTA D.C.

JUNIO DEL 2005

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Rector Magnífico: Padre Gerardo Remolina Vargas S.J.

Decano Académico Facultad de Ingeniería: Ingeniero Francisco Javier Rebolledo Muñoz

Decano del Medio Universitario Facultad de Ingeniería: Padre José Sarmiento Nova S.J.

Director Carrera de Ingeniería de Sistemas: Ingeniera Hilda Cristina Chaparro López

Director Departamento de Ingeniería de Sistemas: Ingeniero Germán Alberto Chavarro Flórez

Nota de Aceptación

______________________________________________________

______________________________________________________

______________________________________________________

________________________________________

Director del Proyecto

________________________________________

Jurado

________________________________________

Jurado

JUNIO DEL 2005

Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado.

Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”

AGRADECIMIENTOS En primer lugar quiero agradecer a la Carrera de Ingeniería de Sistemas de la Pontifica Universidad Javeriana por haberme instruido y formado como Ingeniero y por haberme brindado el conocimiento que me ayudó a superar esta etapa de mi vida. Debo un especial reconocimiento a mis padres por haberme brindado esta gran oportunidad de estudio, por estar siempre conmigo en mis decisiones, en mis problemas y en todo momento que tuve la necesidad de ellos. Muchas gracias a mi hermano por haberme servido de guía, de compañero, pero sobre todo, de hermano, de alguien que siempre está al lado de uno. Muchas gracias a mi hermana por darme siempre esos empujoncitos de aliento, que de una forma muy cariñosa, lo ayudan a uno a seguir adelante sin importar lo que venga. Muchas gracias a mi novia que estuvo presente durante mi último año en la Universidad y que me apoyó en todo momento. A mis amigos de la Universidad y del colegio, amigos incondicionales que estuvieron presentes en mi vida desde los comienzos más básicos de mi formación y con los cuales comparto momentos fabulosos. En ellos pude encontrar siempre una mano amiga cuando era necesario. No hay que olvidar aquellas personas que me permitieron irme formando como Ingeniero y que me fueron brindando los pilares del conocimiento: mis profesores. Muchas gracias por haberme enseñado todo aquello que necesité en el descubrimiento del saber. Al director de mi tesis le agradezco toda su paciencia en aquellos momentos donde más se necesitaba, por haberme guiado en todo este proceso y haberme brindado un ambiente de confianza y bienestar para el desarrollo de esta investigación.

TABLA DE CONTENIDO GLOSARIO ................................................................................................................ 10 1 INTRODUCCIÓN .............................................................................................. 12 2 PLANTEAMIENTO DE LA INVESTIGACIÓN .............................................. 15

2.1 OBJETIVO GENERAL.............................................................................. 15 2.2 OBJETIVOS ESPECÍFICOS...................................................................... 15 2.3 REQUISITOS PARA EL DESARROLLO DEL PROYECTO.................. 15

3 METODOLOGÍA ............................................................................................... 16 3.1 DESARROLLO METODOLÓGICO DE LA INVESTIGACIÓN ............ 16

4 MARCO TEÓRICO............................................................................................ 18 4.1 ADMINISTRACIÓN DE SEGURIDAD ................................................... 18 4.2 ADMINISTRACIÓN DE RED .................................................................. 18 4.3 DOCUMENTACIÓN SOBRE SNMP........................................................ 19

4.3.1 Protocolo de administración simple (SNMP) ..................................... 19 4.3.1.1 Componentes de SNMP .................................................................. 20 4.3.1.2 Representación de la información................................................... 21 4.3.1.3 Operaciones (comandos) del protocolo........................................... 22 4.3.1.4 Estructura de la PDU....................................................................... 24

4.3.2 Protocolo de administración simple versión 3 (SNMPv3).................. 25 4.3.2.1 Arquitectura SNMPv3..................................................................... 26 4.3.2.2 Formato del mensaje ....................................................................... 29 4.3.2.3 Modelo de seguridad basado en usuarios (USM) ........................... 30

4.3.2.3.1 Parámetros de seguridad de USM............................................. 30 4.3.2.3.2 Motor SNMP autoritativo ......................................................... 31 4.3.2.3.3 El grupo MIB usmUser [10] ..................................................... 33 4.3.2.3.4 Descubrimiento de motores SNMP........................................... 34 4.3.2.3.5 Administración de llaves........................................................... 34

4.3.2.4 Modelo de control de acceso basado en vistas (VACM) ................ 35 4.3.2.4.1 Elementos del modelo VACM.................................................. 35 4.3.2.4.2 La MIB del VACM ................................................................... 36

4.3.3 Comparación entre seguridad de SNMPv1 y SNMPv3 ...................... 37 4.4 DOCUMENTACIÓN DE MIB .................................................................. 38

4.4.1 Generalidades de MIB......................................................................... 38 4.4.2 La estructura de administración de la información ............................. 38 4.4.3 Interacción con la MIB........................................................................ 39 4.4.4 Notación de sintaxis abstracta ASN.1................................................. 40

4.4.4.1 Conceptos ASN.1............................................................................ 42 4.4.4.2 Tipos abstractos de datos ................................................................ 43 4.4.4.3 Identificación de objetos ................................................................. 46 4.4.4.4 Ejemplo de la MIB de prueba ......................................................... 47

5 DESARROLLO DEL PROYECTO ................................................................... 49 5.1 SELECCIÓN DE PROGRAMAS A UTILIZAR ....................................... 50

5.1.1 Programa Net-SNMP .......................................................................... 55 5.1.1.1 Pruebas de concepto........................................................................ 55

5.1.2 Selección de herramientas de seguridad ............................................. 57 5.1.3 Selección de motor de base de datos................................................... 62 5.1.4 Análisis del protocolo syslog .............................................................. 63

5.2 ARQUITECTURA DEL MODELO PROPUESTO................................... 64 5.2.1 Arquitectura general............................................................................ 64 5.2.2 Arquitectura del adaptador.................................................................. 66

5.2.2.1 Adaptador........................................................................................ 67 5.2.2.1.1 Analizador de logs..................................................................... 67 5.2.2.1.2 Consideraciones sobre los logs ................................................. 69 5.2.2.1.3 Consideraciones sobre la MIB .................................................. 70 5.2.2.1.4 Construcción del adaptador....................................................... 72

5.2.3 Arquitectura de la consola de seguridad ............................................. 78 5.2.3.1 Consola de seguridad ...................................................................... 80

5.2.3.1.1 Subsistema de ambiente gráfico................................................ 81 5.2.3.1.2 Subsistema de control de incidentes de seguridad .................... 81 5.2.3.1.3 Subsistema de recepción de mensajes SNMP........................... 82 5.2.3.1.4 Subsistema de envío de mensaje SNMP ................................... 82

5.2.3.2 Modelo entidad-relación de la base de datos utilizada.................... 82 5.2.3.3 Diagrama de clases de la consola de seguridad .............................. 83

6 PRUEBAS........................................................................................................... 84 6.1 DESCRIPCIÓN DE LA PRUEBA ............................................................. 84 6.2 DESARROLLO DE LAS PRUEBAS ........................................................ 85 6.3 RESULTADOS DE LAS PRUEBAS......................................................... 94

7 CONCLUSIONES .............................................................................................. 96 8 CONTINUIDAD DEL PROYECTO.................................................................. 99

8.1 POSIBLES TRABAJOS FUTUROS.......................................................... 99 BIBLIOGRAFIA ...................................................................................................... 101 ANEXO 1: TÉRMINOS DE LICENCIAMIENTO.................................................. 103 ANEXO 2: ESTRUCTURA DE UNA MIB............................................................. 109 ANEXO 3: IMPLEMENTACIÓN DE UNA MIB ................................................... 112 ANEXO 4: MANUAL DEL USUARIO................................................................... 122 ANEXO 5: INSTALACIÓN DEL PROGRAMA NET-SNMP ............................... 140 ANEXO 6: MANUAL DE INSTALACIÓN............................................................ 145 ANEXO 7: CONTENIDO DEL CD......................................................................... 146 ANEXO 8: DIAGRAMA DE CLASES GENERAL................................................ 147

TABLA DE FIGURAS Figura 1. Transporte de un mensaje SNMP ................................................................ 19 Figura 2. Estructura general de la MIB....................................................................... 21 Figura 3. Intercambio de mensajes SNMP.................................................................. 23 Figura 4. Estructura de la PDU ................................................................................... 24 Figura 5. Diagrama de una entidad SNMP ................................................................. 27 Figura 6. Formato del mensaje SNMPv3.................................................................... 29 Figura 7. Formato del mensaje SNMPv3 con el campo msgSecurityParameters ...... 31 Figura 8. Forma de manejo de las llaves..................................................................... 32 Figura 9. Relación de componentes ASN.1 ................................................................ 41 Figura 10. Vista del árbol construido.......................................................................... 48 Figura 11. Arquitectura propuesta .............................................................................. 49 Figura 12. Get utilizando SNMPv2............................................................................. 51 Figura 13. Response del mensaje SNMPv2 ................................................................ 52 Figura 14. Get utilizando SNMPv3............................................................................. 53 Figura 15. Response del mensaje SNMPv3 ................................................................ 54 Figura 16. Prueba de concepto realizada..................................................................... 56 Figura 17. Funcionamiento de Syslog......................................................................... 63 Figura 18. Arquitectura general .................................................................................. 65 Figura 19. Arquitectura del adaptador ........................................................................ 66 Figura 20. Estructura de los logs................................................................................. 70 Figura 21. Implementación de la MIB para la herramienta ........................................ 71 Figura 22. Estructura general de la MIB para el modelo propuesto ........................... 72 Figura 23. Estructura en C para la herramienta Kerio ................................................ 73 Figura 24. Arquitectura de la consola de seguridad.................................................... 79 Figura 25. Subsistemas de la consola de seguridad .................................................... 80 Figura 26. Diagrama entidad-relación......................................................................... 83 Figura 27. Diagrama de la red de prueba utilizada ..................................................... 86 Figura 28. Utilización de la red en la subred 1 ........................................................... 87 Figura 29. Utilización de la red en la subred 1 ........................................................... 88 Figura 30. Utilización de la red................................................................................... 90 Figura 31. Utilización de la red................................................................................... 91 Figura 32. Utilización de la red................................................................................... 92 Figura 33. Utilización de la red................................................................................... 93 Figura 34. Tráfico normal de la red ............................................................................ 94 Figura 35. Gráficas del envío de un gran número de Traps a la consola.................... 94 Figura 36. Estructura de un mensaje SNMPv3 ........................................................... 98

LISTA DE TABLAS Tabla 1. Principios garantizados por cada grupo de aplicación .................................. 58 Tabla 2. Características analizadas de los Anti-Spyware ............................................ 59 Tabla 3. Características analizadas de los antivirus .................................................... 60 Tabla 4. Características analizadas de los firewalls .................................................... 60 Tabla 5. Características analizadas de los IDS............................................................ 60 Tabla 6. Criterios de selección de herramientas.......................................................... 61 Tabla 7. Resultados de aplicar criterios a herramientas.............................................. 62 Tabla 8. Orden de las herramientas según su peso...................................................... 62 Tabla 9. Porcentaje de notificación de eventos en el log ............................................ 89

10

GLOSARIO

1. SNMP (Simple Network Managment Protocol): usado para administrar la configuración de dispositivos de red desde una estación de trabajo [5].

2. MIB (Management Information Base): es una colección de información que esta ordenada en forma de árbol donde se registran las variables a monitorear con sus respectivos valores y permiten un tipo de interoperabilidad.

3. OID (Object ID): identifica de manera única cada objeto representado en la MIB y es una secuencia de números enteros no negativos separados por un punto.

4. IDS (Intrusion Detection System): es una herramienta que permite monitorear el comportamiento y el uso que se le da a los recursos en una máquina y detectar si alguien está haciendo algo indebido.

5. Firewall: un equipo que impone un conjunto de directivas de seguridad que restringen de forma severa el acceso al sistema y a los recursos [5].

6. ASN.1 (Abstract Syntax Notation 1): lenguaje utilizado para definir tipos de datos.

7. Agente SNMP: programa que permite a un dispositivo responder a solicitudes SNMP.

8. Solicitud SNMP: solicitudes enviadas o recibidas por una entidad administradora. Pueden ser Get, Set, Trap, etc.

9. Autenticación: el proceso de determinar que una entidad es quien o lo que dice ser [5].

10. Control de acceso y autorización: el proceso de determinar los recursos y servicios que puede usar una entidad [5].

11. Integridad: los datos reflejen la realidad y que correspondan con lo que debe ser y no ha sido modificadas indebidamente.

12. Disponibilidad: los servicios y la información deben, en todo momento, estar disponibles.

13. Confidencialidad: que la información sólo sea vista por los entes involucrados en la comunicación y que un tercero no pueda ingresar.

14. No repudio: que algún ente que haya participado en la comunicación no pueda negar su participación en ella.

15. Auditabilidad: la herramienta guarda algún tipo de registro de eventos que han sucedido en el tiempo.

16. BER (Basic Enconding Rules): un conjunto de reglas para traducir valores ASN.1 a un flujo de octetos para transmitir por la red.

17. SMI (Structure of Management Information): define agrupaciones, nombres, tipos de datos permitidos y la sintaxis para escribir MIB’s.

18. NMS (Network Management Station): estación de red encargada de gestionar varios dispositivos de red.

19. PDU (Protocol Data Unit): define la estructura de la información que va a ser enviada por la red.

11

20. USM (User-based Security Model): modelo de seguridad utilizado por SNMPv3 para administrar el envío de mensajes SNMPv3.

21. VACM (View-based Access Control Model): modelo de control de acceso que permite administrar quien tiene acceso a que información en la MIB.

12

1 INTRODUCCIÓN Hoy en día en las empresas ha comenzado a ser de suma importancia el manejo que se le da a la información y la forma como es utilizada la red. Debido a esto, son muchas las funciones que desempeña un administrador de red: entre ellas debe velar por la gestión de la red y por la seguridad de esta. Estas dos actividades han tenido un gran desarrollo tanto teórico como práctico. Tanto para la seguridad como para la gestión de red existen diversos programas en el mercado; algunos son libres y otros cuestan mucho dinero. El problema que tienen estas herramientas es que hacen su trabajo de manera que no se puede relacionar la gestión de red y la seguridad. Normalmente cada una de ellas debe ser administrada desde el entorno visual que ofrecen para interactuar. Por esta razón, un administrador de red debe estar constantemente manejando varias herramientas a la vez para poder monitorear lo que está sucediendo. Hasta el momento no se han encontrado herramientas que integren esta funcionalidad bajo un mismo programa. El mundo de la gestión de red es muy importante y debido a la alta sistematización en las empresas, se ha tornado crítica la necesidad de saber que está pasando con los equipos de la red. A grandes rasgos, la gestión de red es el hecho de anticiparse a fallos en la red y de detectar su posible impacto en la prestación de un servicio a los usuarios [1]. La esencia de la gestión de redes se puede definir como “… Gestión es todo y, especialmente, es proactividad, característica que desgraciadamente no es fácil encontrar en las herramientas que ofrece el mercado. Es esencial conocer no sólo los fallos que se pueden estar produciendo en la red en un momento determinado, sino poder anticiparte a los mismos, estar preparado y saber cómo reaccionar en caso de que se produzcan” [1]. En forma general lo que pretende la gestión de red es minimizar los riesgos frente a una posible falla, minimizar el costo asociado con las operaciones al evitar que suceda algún tipo de problema y mantener la red en funcionamiento brindando los servicios sin ningún problema. Las herramientas de gestión de red se pueden ver como un elemento de seguridad en la red, ya que permiten saber sobre el funcionamiento de los equipos y pueden ayudar a prever futuros problemas, en otras palabras fortalecen la disponibilidad de los servicios. Algunas de las funciones principales de un sistema de gestión de red son [3]: descubrir automáticamente la topología de la red, brindar herramientas de diagnóstico, monitorización de la red, gestión de MIB’s, entre otras. Normalmente estos sistemas que utilizan SNMP consisten de [3]: agente, consola de gestión de red y MIB.

13

Uno de los elementos más importantes en los sistemas de gestión de red son los protocolos que utilizan para monitorear los elementos de la red. Existen dos protocolos en el mercado para este fin: SNMP (Simple Network Management Protocol) y CMIP (Common Management Information Protocol). Ellos definen un monitor (NMS, Network Management Station) y varios elementos de red que tienen un agente en ellos, el cual va a reportar sucesos al monitor. Vale la pena mencionar que las primeras dos versiones del protocolo SNMP son muy inseguras, ya que no implementan ningún método de seguridad, como si lo hace la versión tres. Debido a esta falencia de seguridad, se puede proporcionar gran cantidad de información a un atacante sobre la configuración de los equipos y la red [4]. Por otro lado, tenemos el mundo de la seguridad. Es un mundo muy complejo, en el cual hay muchas variables y sucesos que hay que tener en cuenta. A grandes rasgos la seguridad pretende proteger y garantizar que la información este segura del ambiente externo e interno de una organización. Sus objetivos básicos son autenticación, control de acceso y autorización, integridad, disponibilidad, confidencialidad, no repudio y auditabilidad.

Para el mundo de seguridad hay diversas aplicaciones que pretenden proteger contra ciertos riesgos. Existen, por ejemplo, aplicaciones para la detección de intrusos (IDS), antivirus, firewalls, políticas en sistemas operativos, entre otros. Cada uno de estos programas pretende proteger o garantizar alguno de esos objetivos de seguridad mencionados. Otro problema encontrado es la independencia que existe entre cada una de estas aplicaciones, las cuales realizan muy bien sus funciones, pero lo hacen independientemente unas de otras. Hasta el momento no se han encontrado herramientas que integren funcionalidad de estas aplicaciones. Solo lo hacen algunas herramientas de manera centralizada para su producto, como por ejemplo, los antivirus. Existen algunas herramientas comerciales de seguridad como Netscreen IDP y los productos de Checkpoint que permiten configurar alertas de eventos de seguridad detectados vía SNMP hacia una consola de gestión. Estas alertas son solo informativas y solo sirven para el monitoreo o la consolidación de logs. Adicionalmente no soportan SNMPv3 y no brindan ninguna posibilidad de interactuar con las aplicaciones desde una consola central. Entre estas aplicaciones podemos encontrar firewalls personales y empresariales que sirven para bloquear y filtrar tráfico mediante el uso de reglas. Los IDS permiten detectar ataques según análisis de tráfico y pueden utilizar como forma de detección firmas (patrón preestablecido) o autónomos (a partir de la caracterización del tráfico detectan desviaciones). Los antivirus permiten escanear los archivos y los correos en busca de virus, gusanos, troyanos, entre otros, que pueden causar daños en las máquina, archivos o en la red en general. Los sistemas operativos permiten manejar seguridad a nivel de usuario, políticas de acceso y uso de los recursos, permiten configurar protocolos, puertos, parches, etc. Todas estas herramientas generan ciertos

14

tipos de alertas visuales o notificaciones vía correo, pero primordialmente generan logs. Un aspecto importante es que muchas de estas aplicaciones generan algún tipo de log, en donde se va guardando la información de eventos durante su ejecución. Algunas herramientas como por ejemplo GFI LANguard S.E.L.M. [6] se encargan de monitorear los logs de eventos de Windows y permite saber de manera centralizada lo que sucede con el sistema operativo, ya que analiza los eventos de aplicación, seguridad y sistema generados por este sistema operativo. Por ejemplo, permite saber cuando alguien inicia sesión, cuando una aplicación genera un error, etc. Pero no se encarga de integrar otras herramientas de seguridad. Hasta ahora no se ha encontrado evidencia alguna de una herramienta que integre la gestión de red y la seguridad de redes. En el mercado existen muchas aplicaciones para cada uno de estos mundos. Hay herramientas gratuitas, de costo medio y hasta de un costo muy elevado, a lo cual sólo podrían acceder empresas con mucho capital. Es importante resaltar que por el hecho que una herramienta sea gratuita, no significa que realice un trabajo deficiente. Es aquí donde el proyecto cobra valor, al permitir que se puedan integrar varias herramientas de seguridad, sin importar su costo, bajo una consola de seguridad las cuales van a ser monitoreadas por esta consola. Lo importante de estas herramientas de seguridad es que deben generar logs legibles, por ejemplo, logs en archivos de texto. Adicionalmente, se puede utilizar una herramienta de gestión de red para poder integrar los dos mundos mediante dicha consola. De esta forma se logra tener la administración de la red en una sola aplicación que puede funcionar con distintos productos del mercado. Por esta razón el proyecto puede ser de interés para las Mipymes y grandes empresas. Es necesario aclarar que el proyecto se centra en el uso de herramientas gratuitas debido al fácil acceso que se tiene a estas. Con la investigación se busca crear una conciencia en los desarrolladores de las aplicaciones de seguridad, para que incorporen en sus herramientas un agente SNMP y así lograr que la administración y monitorización de éstas se pueda hacer sin la necesidad de crear un adaptador para cada una de las herramientas. Como se ha mencionado anteriormente, se desea integrar algunas herramientas de seguridad bajo una herramienta que se encargará de monitorizar las alertas que estas generen. Esto será posible mediante tres elementos: un protocolo seguro de comunicación, ya que como estamos hablando de monitorear la seguridad, éste no debe ser un punto inseguro en la arquitectura; un adaptador, encargado de monitorear los programas en un equipo y por último, la consola de seguridad, que se va a encargar de procesar los reportes de los adaptadores. El proyecto pretende dejar abierta la posibilidad para que en el futuro, se pueda utilizar una herramienta de gestión de red para monitorear la seguridad de la red.

15

2 PLANTEAMIENTO DE LA INVESTIGACIÓN

2.1 OBJETIVO GENERAL Crear un modelo de gestión de seguridad de red que por medio de módulos permita monitorear herramientas de seguridad. Este brindará soporte a SNMP, para la futura integración con herramientas de gestión.

2.2 OBJETIVOS ESPECÍFICOS

• Apropiarse del conocimiento del funcionamiento de SNMP y de las MIB. • Selección de un protocolo seguro para la comunicación. • Selección de herramientas de seguridad a utilizar para validar el modelo. • Diseño y documentación del modelo de los adaptadores. • Implementación de los adaptadores para que monitoreen las herramientas de

seguridad seleccionadas. • Diseño e implementación de la consola de seguridad con soporte a SNMP.

2.3 REQUISITOS PARA EL DESARROLLO DEL PROYECTO

• Utilización de herramientas de seguridad gratuitas. • Herramientas que generen logs de texto legibles. • Estos logs deben contener la mayor cantidad de información acerca de un

evento de seguridad. • Utilizar el protocolo SNMP. • Tratar de mantener variedad en los sistemas operativos soportados por las

herramientas de seguridad. • En la medida de lo posible tratar que se pueda interactuar de alguna manera

con la herramienta.

16

3 METODOLOGÍA La principal metodología de investigación que se utilizará en el proyecto se basa en el método científico. Se iniciará con un método de exploración, que ayudará a conocer la información pertinente acerca del proyecto. Luego, se utilizará una metodología experimental, donde se procederá a validar el conocimiento adquirido. El cual se describe a continuación. Primero que todo, se debe encontrar el problema a darle solución con el presente proyecto. Luego, se realizará una documentación profunda sobre el funcionamiento de SNMP y de las MIB’s. El proceso de desarrollo se realizará utilizando el paradigma de programación orientada a objetos. La documentación será transversal a la etapa de desarrollo. Se utilizará un proceso de desarrollo iterativo, en donde se irá verificando o refinando actividades anteriores. Para el desarrollo se va a realizar una primera parte de documentación para luego pasar a la implementación. Este proceso iterativo se compone de las siguientes fases: iniciación, elaboración, construcción y transición. En la fase de iniciación se va a realizar una documentación profunda de los dos temas mencionados que se refleja en el marco teórico de este documento, para luego poder proceder a realizar la definición de requerimientos del proyecto. En la fase de elaboración se van a realizar ciertos documentos de definición y documentación de cada una de las partes del proyecto. En este punto se incluyen las definiciones de la respectiva arquitectura. En la fase de construcción se irán implementando cada uno de los componentes, de tal forma que se pueda producir un producto funcional. En la transición se irán realizando pruebas para cada uno de los componentes y así poder validar que no haya errores en el producto final. Finalmente, se realizará una integración de las partes desarrolladas para armar el producto final. Debido a la forma y estructura del proyecto, el diseño y la documentación se van a realizar casi simultáneamente.

3.1 DESARROLLO METODOLÓGICO DE LA INVESTIGACIÓN Para el proceso de desarrollo de la investigación fue necesario el cumplimiento de las siguientes actividades:

1. Investigación del estado del arte y verificación de productos o investigaciones similares. En esta actividad lo que se pretende es explorar si existe algo similar a la investigación propuesta y determinar lo que plantean dichos estudios así como su funcionamiento. A partir de esto se puede darle un marco a la investigación, definir el alcance, definir objetivos de la investigación,

17

determinar en que se va a distinguir frente a lo existente en el mercado. Permite analizar que productos hay desarrollados y si alguno de ellos sirve para el desarrollo esta.

2. Definición del marco teórico: en donde se define la teoría necesaria para realizar la investigación. Para esto fue necesario aprender sobre el protocolo SNMP y sobre la MIB, elementos fundamentales para el desarrollo de la investigación. Esta actividad permite crear uno de los pilares teóricos en donde se va a construir el modelo y su implementación.

3. Selección de programas a utilizar: especifica la selección de herramientas de seguridad para validar el modelo, el motor de bases de datos y la implementación del protocolo SNMP. Esta actividad es importante para determinar de que manera se van a seleccionar los programas a utilizar para validar el modelo y poder construir una implementación de éste. De esta forma se puede demostrar o no la validez del modelo de seguridad propuesto y mostrar su viabilidad.

4. Definición de la arquitectura del modelo propuesto: que se compone de las siguientes arquitecturas: general, del adaptador y de la consola de seguridad. Esta es una de las actividades más importantes ya que es donde se va a definir la arquitectura del modelo. Aquí se definirán los componentes, el funcionamiento, la comunicación y la interoperabilidad entre cada uno de los elementos definidos en ella.

5. Definición y ejecución de las pruebas: actividad en donde se realizarán las pruebas y las mediciones necesarias. Las pruebas nos permiten determinar de una manera cuantitativa el funcionamiento de la aplicación desarrollada. Por esta razón es muy importante definir claramente lo que se desea probar y medir, y así, determinar la viabilidad de la implementación del modelo. Se realizarán mediciones a nivel de la red y de la aplicación para determinar su funcionamiento y el impacto que podría tener en una red.

6. Realización de conclusiones: esta actividad permite mencionar todos los hallazgos encontrados durante el desarrollo de la investigación. Se mencionan hechos como la viabilidad del modelo, resaltar aspectos importantes de éste, entre otros.

7. Definición de la continuidad de la investigación: comúnmente una investigación no abarca todos los caminos necesarios para que sea completa. Es por esta razón que se resaltan trabajos futuros que se pueden desarrollar a partir del modelo propuesto. Aspectos que no se consideraron en la definición del alcance y de los objetivos y que pueden brindarle al modelo una riqueza mayor, sin olvidar que los trabajos pueden ser trabajos de investigación.

18

4 MARCO TEÓRICO

4.1 ADMINISTRACIÓN DE SEGURIDAD La administración de seguridad es un proceso mediante el cual se administran, definen y actualizan las políticas de seguridad para proteger los recursos más valiosos de la red y que a diferencia de la administración de red, no cuenta con protocolos que permitan integrar los diferentes componentes que hacen parte de una arquitectura de seguridad. Por otra parte podemos encontrar muchos programas y dispositivos de red que permiten definir una arquitectura de seguridad. Encontramos firewalls, enrutadores, IDS, switches, antivirus, sistemas operativos, proxies, entre muchos otros. Cada uno de ellos desempeña una función primordial en una arquitectura de protección de profundidad y en especial generan alarmas de una manera independiente y sin ninguna administración centralizada que las coordine. Esta es una de las razones por al cual el proceso de análisis forense debe ser largo y se debe inspeccionar cada uno de estos elementos tanto hardware como software.

4.2 ADMINISTRACIÓN DE RED La administración de red es el proceso mediante el cual podemos encontrar fallas en algún punto de la red, de manera centralizada y tomar alguna acción que lleve a la solución del problema. Es importante que la gestión de red sea proactiva, es decir, que se pueda anticipar a un fallo de la red y no esperar a su materialización para tomar una acción preventiva. Antes de abordar el tema, es de suma importancia mencionar algunos breves conceptos sobre la administración de red. Normalmente, cuando se desea monitorear la red de una empresa, se utiliza un sistema de administración de red, el cual está compuesto de los siguientes elementos: los nodos administrados, que es básicamente lo que nosotros deseamos monitorear (enrutadores, switches, estaciones de trabajo, etc.), que por medio de un agente presente en ellos se facilita su administración; la estación de administración de red (NMS), que es donde se ejecuta el monitor, quien va a comunicarse con los agentes para lograr la administración de la red; por último tenemos el protocolo que se va a encargar de la comunicación entre el agente y la NMS. Para fines de la administración, no es suficiente con sólo intercambiar la información de administración para poder monitorear el nodo. El protocolo, debe a su vez, proveer una arquitectura de administración que utilice los conceptos de autenticación y de

19

autorización (que es limitar el acceso a un elemento y verificar que no sea alguien no autorizado). Por otra parte, el nodo posee varias variables tanto de lectura como de escritura que le permiten almacenar información acerca de si mismo. Hasta el momento existen dos protocolos para la administración de red. Estos son: SNMP y CMIP (Common Management Information Protocol). Este documento se va a centrar en el protocolo SNMP.

4.3 DOCUMENTACIÓN SOBRE SNMP

4.3.1 Protocolo de administración simple (SNMP) SNMP se originó en la comunidad de Internet como medida para administrar redes TCP/IP. Como no todos los dispositivos en las redes fueron creados con una mentalidad que podrían llegar a ser administrados con SNMP, existen muchos dispositivos que no pueden ser administrados, per se, con SNMP. Para eso, existe un tipo especial de agente llamado agente proxy, que permite administrar este tipo de dispositivos. Básicamente actúa como un convertidor de protocolos, que traduce de SNMP al esquema propietario definido en el dispositivo. Este tipo de agente es útil para administrar dispositivos que son administrados por un esquema propietario y se desean incorporar al mundo SNMP. SNMP funciona con el protocolo de transporte UDP (Unreliable Datagram Protocol). Para mandar un mensaje, una entidad SNMP serializa un mensaje SNMP y lo envía como un datagrama UDP a la dirección de la entidad que recibe. Los agentes SNMP están escuchando por el puerto 161. Se puede ver la forma como sería el transporte de un mensaje SNMP en la Figura 1, donde se muestran los protocolos de cada capa involucrados en el proceso [9].

Figura 1. Transporte de un mensaje SNMP

20

4.3.1.1 Componentes de SNMP Se compone de tres partes indispensables para su funcionamiento: consola de administración (NMS), agente y MIB [7].

1. Agente: es un programa encontrado en un dispositivo de red, ya sea una estación, un switch o un router o cualquier dispositivo administrable mediante SNMP.

2. Consola de administración: es un programa encontrado en una estación de trabajo y tiene la habilidad de indagar los agentes utilizando SNMP.

3. MIB: es una base de datos de objetos administrados que son accesibles por el agente y manipulados vía SNMP para lograr la administración de la red.

Las responsabilidades más importantes de cada una de estas partes serían [7]:

1. Responsabilidades del agente: Posee una vista de la MIB que incluye la MIB estándar de Internet más otras extensiones1. En la MIB no se tiene porque implementar todos los grupos de variables definidas en la especificación de las MIB. Gracias a esto se puede simplificar significativamente la implementación de SNMP en dispositivos pequeños de una red (debido a que tienen limitación de memoria y procesamiento). Básicamente realiza dos funciones: inspeccionar las variables de la MIB (que implica consultar los valores de las variables) y alterar variables en la MIB (que implica cambiar los valores de las variables para lograr algún efecto en el dispositivo).

2. Responsabilidades de la consola de administración: Básicamente se encarga de ejecutar las aplicaciones que ayudan a analizar el funcionamiento de la red. Normalmente provee una interfaz gráfica que muestra un mapa de los agentes encontrados en la red.

3. La MIB:

Se encuentra dividida en cuatro áreas: a. Atributos del sistema b. Atributos privados c. Atributos experimentales d. Atributos de directorio

1 Se refiere con MIB estándar de Internet a la definición de la MIB-II del RFC 1213, una mejora de la MIB-I y que son estándar para todo el que pretenda implementar dicha funcionalidad. Por otro lado, se refiere a extensiones cuando hablamos de extensiones que se hacen a la definición estándar. Esto es, definiciones de nuevos objetos a monitorear que no están definidos en la MIB-II. Son extensiones para monitorear dispositivos de cada uno de los fabricantes y/o de todo aquel que desee desarrollar una MIB nueva.

21

Toda la documentación está escrita en ASN.1, que trata de ser un estándar frente a las documentaciones de SNMP. Hay dos versiones de la MIB:

• MIB I: la primera en crearse y tiene una limitada lista de objetos relacionadas con variables de ruteo de IP.

• MIB II: una versión más robusta a la anterior y extendió los objetos a una gran variedad de medios y dispositivos de red.

4.3.1.2 Representación de la información Cada objeto guardado en una MIB tiene un identificador que lo identifica de manera única. Este identificador es conocido como el identificador de objeto (OID) y es una secuencia de números enteros no negativos separados por un punto, que sale de un árbol estandarizado mundialmente, que se puede observar en la Figura 2. Como todos los árboles, éste se encuentra conformado por ramas y nodos. El nodo puede ser un entero positivo y una etiqueta. También pueden tener hijos, que a su vez, son nodos.

Figura 2. Estructura general de la MIB

La MIB está escrita utilizando la sintaxis ASN.1. Ésta es utilizada para describir las estructuras de datos que queremos definir para guardar la información de gestión. Luego de definir estas estructuras se debe definir la sintaxis de transferencia, para saber la forma en que van a ser transmitidos los datos en la red. A esto se le conoce como las reglas de codificación básicas (BER) [19]. Es la codificación utilizada para

22

transferir información escrita en ASN.1 a otras aplicaciones mediante una sintaxis que define y permite definir el formato de cómo se van a enviar los datos. En el ASN.1 se definen tres tipos de objetos [8]:

• Tipos (types): que define nuevas estructuras de datos y comienzan en mayúsculas

• Valores (values): que son variables de un tipo y son escritas en minúsculas • Macros: usados para cambiar la gramática y son escritas en mayúsculas

4.3.1.3 Operaciones (comandos) del protocolo En el protocolo de administración de red SNMP, se encuentran seis operaciones básicas (comandos): GetRequest, GetNextRequest, GetResponse, SetRequest, Trap [7] y GetBulkRequest. Es importante aclarar la diferencia que hay entre GetRequest y GetNextRequest, que aunque son similares, tienen una pequeña diferencia que es ampliamente necesaria y utilizada. El comando GetRequest se encarga de traer el valor de ciertos objetos especificados como parámetros, mientras que el comando GetNextRequest se encarga de traer el siguiente valor del objeto según el orden lexicográfico (ver más adelante). Con los comandos GetRequest, GetNextRequest y GetResponse se obtiene la siguiente secuencia de eventos: el agente inspecciona el valor de las variables que posee en la MIB, tras recibir un comando PDU (Protocol Data Unit), ya sea de GetRequest o GetNextRequest, provenientes de la consola de administración (NMS). Luego, el agente devuelve los datos que ha recolectado, tras el comando recibido, mediante el comando GetResponse. El comando SetRequest es usado por el agente para modificar variables de la MIB, luego de recibir un comando de SetRequest. Este comando tiene mucho poder en el mundo de la administración de red y si es usado de una manera indebida puede corromper los parámetros de configuración de los nodos administrados y hasta interrumpir los servicios de red. Por esta razón, es importante implementar mecanismos de encriptación y de autenticación. El quinto comando, Traps, es un comando especial que los agentes utilizan para mandar datos a la consola de administración, cuando ha sucedido un evento inusual, pero importante, que debe ser reportado sin solicitud. El sexto comando, GetBulkRequest, es utilizado cuando se solicita la transferencia de una gran cantidad de datos para, por ejemplo, traer tablas muy grandes que tienen muchos datos. Así se minimizan el número de solicitudes que tocaría realizar para

23

traer las filas de las tablas. Es muy parecido al comando GetNextRequest, solo que no solicita objeto por objeto, sino que puede solicitar una gran cantidad de una vez. En la Figura 3 se puede apreciar como es el proceso de intercambio de mensajes, o más bien, PDUs de SNMP para los comandos de Get, Set y Trap entre la consola administrador y el agente [10]:

Figura 3. Intercambio de mensajes SNMP

El agente responde a un comando GetRequest con un comando GetResponse, el cual contiene el mismo ID de petición, un campo dentro del formato de un mensaje SNMP que contiene una identificación única para cada mensaje de solicitud (Figura 3 (a)). El comando GetRequest si puede acceder a todas las variables solicitadas en el campo variable, entonces se puede generar una respuesta GetReponse en donde irían en el campo variable, una lista de las variables con su correspondiente valor. De forma similar funciona el comando GetNextRequest (Figura 3 (b)). La diferencia radica en que va a retornar la siguiente instancia de un objeto (en orden lexicográfico2). Por 2 Se refiere al siguiente objeto que le sigue al que están solicitando. Por ejemplo: si se hace un GetNextRequest para el objeto sysLocation.0 (1.3.6.1.2.1.1.6.0), se va a retornar el nombre y el valor del objeto sysServices.0 (1.3.6.1.2.1.1.7.0) con su respectivo valor. Otra nueva solicitud a este último objeto va a retornar el nombre y el valor de ifNumber.0 (1.3.6.1.2.1.2.1.0).

24

ejemplo [10], ante esta solicitud: GetRequest (udpInDatagrams.0, udpNoPorts.0, …), obtenemos como respuesta: GetResponse ((udpInDatagrams.0=100), (udpNoPorts.0=1), …). La operación SetRequest (Figura 3 (c)) es muy similar a GetRequest, pero la diferencia sustancial radica en que el fin de esta operación es el de escribir un valor y no el de leerlo. El agente, como se observa en el diagrama, responde con un GetResponse que contiene el mismo ID de identificación. Al igual que las anteriores es una operación atómica (o todas las variables o nada). En el campo variable coloca los datos que fueron modificados. Por ejemplo [10], ante la solicitud de modificación: SetRequest (ipRouteMetric.1.9.1.2.3=9), y la operación se realizó con éxito, se responde con: GetResponse (ipRouteMetric.1.9.1.2.3=9) el cual cambió la métrica de la entrada 9.1.2.3 de la tabla de ruteo a 9. Por último, tenemos la operación Trap (Figura 3 (d)), la cual no necesita del arribo de un mensaje para mandar los datos. A diferencia de los anteriores, esta operación es generada por el agente cuando en el dispositivo que monitorea sucede algo excepcional y que debe ser notificado al administrador.

4.3.1.4 Estructura de la PDU En la Figura 4 se puede ver la estructura de los formatos de los PDUs del protocolo [8]:

Figura 4. Estructura de la PDU

Es importante mencionar que significa cada uno de los campos mencionados anteriormente [10]:

• Versión: la versión de SNMP que se va a usar • Comunidad: relación que existe entre un agente y un grupo de aplicaciones

SNMP (un componente de una entidad SNMP)

25

• Tipo PDU: indica el tipo de la PDU que va en el mensaje, que puede ser algún tipo de Request (como GetRequest, GetNextRequest y SetRequest), un GetResponse o un Trap.

• Petición ID: usado para distinguir de entre otras solicitudes, cada solicitud con una identificación única

• Error-status: usado para indicar que ha sucedido una excepción mientras se procesaba una solicitud

• Error-índice: cuando el error-status es diferente a cero (no hubo error) puede proporcionar información adicional indicando que variable causó la excepción

• Campos variables: una lista de nombre de variables con sus correspondientes valores, normalmente contiene los datos solicitados por una operación Get o Trap

• Empresa: tipo de objeto que genera un Trap • Dirección agente: dirección del objeto generado del Trap • Trap genérico: tipo genérico del Trap • Trap específico: código específico del Trap • Time-stamp: tiempo transcurrido entre la última vez que se reinició el

dispositivo de red y la generación del Trap Vale la pena mencionar el término de comunidad, que bajo la mirada de SNMP, es la pareja de un agente SNMP y una(s) aplicación(es) SNMP (entidades SNMP que residen en las aplicaciones administradas). El nombre de la comunidad identifica un esquema de autenticación3. La serie de eventos para la autenticación es la siguiente:

1. La entidad SNMP manda a una entidad de autenticación: • Nombre de la comunidad • Los datos • La dirección del que manda

2. La entidad de autenticación que conoce el esquema de autenticación (que es lo

que puede o no hacer una comunidad, ya sea lectura y escritura o solo lectura), retorna una de las dos siguientes posibilidades: • Una instancia del tipo de dato y la identificación de la entidad que manda • Una excepción

4.3.2 Protocolo de administración simple versión 3 (SNMPv3) SNMPv3 se puede definir como:

3 En este caso el esquema de autenticación es muy sencillo. La aplicación SNMP, conoce las comunidades válidas que pueden operar en el agente. Si la solicitud proviene de una comunidad conocida, es aceptada. Según el tipo de comunidad se pueden hacer determinadas operaciones en la MIB.

26

SNMPv3 = SNMPv2 + (seguridad y administración) Fue diseñado para proteger contra las siguientes amenazas de seguridad, mediante el uso de algoritmos de autenticación y de encripción, como lo especifica el RFC 2574:

• Modificación de la información: una entidad podría alterar un mensaje generado por otra que esta autenticada y así lograr que haya una acción no autorizada en la entidad que recibe el mensaje. El problema aquí es que se podría modificar algún parámetro de configuración.

• Enmascaramiento (masquerade): operaciones no autorizadas para un usuario pueden ser intentadas asumiendo la identidad de otro usuario que posee autorización para la operación deseada.

• Reenvío de mensajes: como SNMP opera sobre un protocolo de transporte sin conexión, existe el riesgo que un mensaje SNMP sea almacenado por algún tercero y luego, reenviado o duplicado, para realizar operaciones de administración no autorizadas.

• Poca privacidad (disclosure): una entidad puede observar el intercambio de mensajes entre un agente y una consola de administración y así, aprender de los valores de los objetos.

Por otro lado, se definió que no estaba diseñado para prevenir estos tipos de ataques:

• Denegación de servicio (DoS): prevenir que haya intercambio de mensajes entre agente y consola de administración.

• Análisis de tráfico: un atacante puede observar los patrones de tráfico entre estas dos entidades.

4.3.2.1 Arquitectura SNMPv3 Como se define en [4] y en el RFC 2271, SNMP se compone de entidades, donde cada entidad implementa una parte de la funcionalidad de SNMP y así, puede actuar como un agente en el nodo o como un nodo administrador.

27

Figura 5. Diagrama de una entidad SNMP

En la Figura 5 se muestra el diagrama general de bloques de una entidad SNMPv3 [10]. Cada entidad incluye sólo un motor SNMP que implementa funciones para enviar y recibir mensajes SNMP, poder autenticar y encriptar mensajes y controlar el acceso. Estas funciones están a cargo de ciertos módulos que exponen estas funciones como servicios para que las puedan invocar o utilizar otras aplicaciones, de esta manera conformando lo que se conoce como una entidad SNMP. Como se ve en la Figura 5, tanto el motor como las aplicaciones, están definidas en módulos. Lo que permite tener una ventaja: el rol de cada entidad esta determinado por los módulos que implementa, permitiendo que sea mucho más sencillo modificar los módulos. Como se indica en [20], los componentes de una entidad SNMP son:

• Despachador: permite el soporte de distintas versiones de mensajes SNMP, es el encargado de aceptar y mandar las PDU’s, de pasarlas al subsistema de procesamiento de mensajes y mandar los mensajes por la red.

• Subsistema de procesamiento de mensajes: responsable por preparar mensajes para envío y extraer datos de mensajes recibidos.

• Subsistema de seguridad: provee los servicios de seguridad de autenticación y de encripción o privacidad para los mensajes que así lo necesiten.

28

• Subsistema de control de acceso: provee los servicios de autorización a recursos y define que aplicación tiene derecho y el tipo de acceso que tiene.

• Generador de comandos: inicializa las PDU’s de los mensajes y procesa la respuesta.

• Contestador de comandos: recibe las PDU’s destinadas a la entidad cuyo campo de contextEngineID es igual a la identificación del motor SNMP. Juego, realiza la operación adecuada y con ayudad del control de acceso, genera una respuesta adecuada.

• Originador de notificaciones: está continuamente monitoreando el sistema por eventos o condiciones particulares y de ser necesario, genera una operación de Trap. Para poder hacer esto, es necesario que tenga un mecanismo que le diga a donde mandar los mensajes, que versión y parámetros de seguridad utilizar.

• Receptor de notificaciones: escucha por mensajes de notificación (o Traps) y genera un mensaje de respuesta.

• Despachador proxy: se encarga del direccionamiento de mensajes SNMP. En SNMPv3, la entidad posee un snmpEngineID único. Por propósitos de control de acceso, cada entidad posee un número de contextos de información administrada. Cada uno de estos contextos, tiene su propio contextName, que es local a la entidad. Para que solo pueda existir un administrador de contextos, la entidad posee una única identificación, contextEngineID, que es el mismo que para el snmpEngineID. El snmpMessageProcessingModel determina el formato y la versión que va a tener el mensaje. El snmpSecurityModel determina el modelo de seguridad que va a ser utilizado. El snmpSecurityLevel, determina que servicios de seguridad son solicitados para una operación específica. Pude brindar una de las siguientes combinaciones: autenticación, autenticación y privacidad o ninguno de los dos. Términos importantes para tener en cuenta [10]:

• contextEngineID: identifica de manera única una entidad. • snmpEngineID: identifica de manera única el motor SNMP. • contextName: identifica un contexto particular dentro de un motor SNMP. • scopedPDU: es un bloque de datos que consiste de contextEngineID,

contextName y un PDU. Es enviado como parámetro al subsistema de seguridad.

• snmpSecurityModel: identificador único del modelo de seguridad del subsistema de seguridad.

• snmpMessageProcessingModel: identificador único del modelo de procesamiento del mensaje del subsistema de procesamiento del mensaje.

• snmpSecurityLevel: nivel de seguridad que especifica si un mensaje SNMP puede ser enviado o bajo que operaciones están siendo procesados, referente a la autenticación y privacidad. Los valores que puede tomar son:

29

noAuthnoPriv, authNoPriv y authPriv, donde cada uno puede proveer o no uno de los servicios de seguridad.

4.3.2.2 Formato del mensaje Al igual que en las dos versiones anteriores, se ha definido un formato de mensaje que va a ser intercambiado entre entidades SNMP. Cada mensaje contiene un encabezado y un PDU, como se observa en la Figura 6 [10].

Figura 6. Formato del mensaje SNMPv3

Los campos del formato anterior son:

• msgVersion: su valor está por default en SNMPv3. • msgID: identificador único usado entre dos entidades para coordinar mensajes

de solicitud y de respuesta. • msgMaxSize: tamaño máximo del mensaje que el remitente puede aceptar. • msgFlags: una cadena que contiene tres banderas: reportableFlag, privFlag y

authFlag.

30

• msgSecurityModel: un identificador que indica que modelo de seguridad fue usado por el remitente para preparar el mensaje. Esto le permite al receptor saber que modelo debe utilizar. Los valores pueden ser: 1 para SNMPv1, 2 para SNMPv2c y 3 para SNMPv3.

• msgSecurityParameters: cadena que contiene parámetros generados por el subsistema de seguridad en la entidad remitente y procesados por la entidad receptora.

• contextEngineID: identifica de manera única una entidad SNMP. Para mensajes provenientes, determina a que aplicación el scopedPDU va a ser enviado.

• contextName: identifica de manera única un contexto particular dentro del contexto del motor SNMP.

• datos: un PDU que debe ser de tipo SNMPv2.

4.3.2.3 Modelo de seguridad basado en usuarios (USM) El RFC 2274 define el USM para SNMPv3. La especificación contiene:

• Autenticación: provee integridad de datos y autenticación. Utiliza los algoritmos MD5 o SHA-1.

• Timeliness: protege contra retardos o reenvíos de mensajes. • Privacidad: protege contra la no privacidad del mensaje. Encripta el

contenido. Utiliza el algoritmo DES (el modo CBC, Cipher Block Chaining). • Formato de mensaje: define el formato del campo msgSecurityParameters. • Descubrimiento: define procedimientos mediante el cual un motor SNMP

obtiene la información de otro. • Administración de llaves: define el procedimiento para la generación,

actualización y uso de las llaves.

4.3.2.3.1 Parámetros de seguridad de USM El RFC 2274 define una estructura llamada UsmSecurityParameters, que especifica el formato interno del campo msgSecurityParameters en un mensaje SNMPv3, como se muestra en la Figura 7 [10]:

31

Figura 7. Formato del mensaje SNMPv3 con el campo msgSecurityParameters

4.3.2.3.2 Motor SNMP autoritativo Antes de explicar los campos del mensaje, es necesario aclarar un concepto muy utilizado por el modelo USM. Este es el motor SNMP autoritativo. En cualquier transmisión de un mensaje, una de las dos entidades involucradas en el proceso, ya sea el transmisor o el receptor, debe ser designada como el motor SNMP autoritativo. De acuerdo a las siguientes reglas:

• Cuando un mensaje SNMP contiene un payload que espera una respuesta (como por ejemplo, Get, GetNext o Set) el receptor de los mensajes es autoritativo.

32

• Cuando un mensaje SNMP contiene un payload que no espera respuesta (como por ejemplo, un Trap, un Response o un Report4) entonces el remitente del mensaje es autoritativo.

Designar una entidad como autoritativa o no, permite que ocurran dos cosas. La primera, que se pueda manejar el tiempo de validez de un mensaje (timeliness). Es vital para establecer la sincronización entre las dos entidades. Para esto, se maneja un reloj. Cuando una entidad autoritativa manda un mensaje a una entidad que no lo es, incluye en este el valor de su reloj. Así, cuando lo recibe la entidad no autoritativa, se utiliza ese valor para calcular el tiempo en el que va a estar la entidad autoritativa (el destino), ya que es necesario que ponga ese estimado cuando va a enviar el mensaje de respuesta. La segunda, el proceso de localización de llaves. Permite que un principal tenga las llaves de múltiples motores. Estas llaves son localizadas al motor autoritativo SNMP. De esta manera es responsable de una llave y no de muchas llaves distribuidas. Como se dice en el RFC 2574, para generar una llave localizada, Kul, (una llave secreta compartida entre un usuario y un motor SNMP autoritativo), se debe hacer lo siguiente: si el usuario utiliza una clave, ésta se convierte en una llave Ku usando MD5 o SHA. Para convertir esta llave en una llave localizada, Kul, es necesario anexar el snmpEngineID del motor SNMP autoritativo a la llave Ku y luego anexarle al resultado otra vez la llave Ku. De esta forma se envuelve el snmpEngineID entre dos copias de la llave Ku. Luego, se pasa una función de hash segura (que depende del algoritmo usado) y así se obtiene una llave localizada, Kul. Este proceso se resume en la Figura 8.

Figura 8. Forma de manejo de las llaves

Elementos de UsmSecurityParameters:

4 Forma en que se hace el descubrimiento de otros motores SNMP.

33

• msgAuthoritativeEngineID: el snmpEngineID de un motor SNMP autoritativo, involucrado en el intercambio de mensajes.

• msgAuthoritativeEngineBoots: el valor de snmpEngineBoots del motor SNMP autoritativo en el intercambio de mensajes, y corresponde al número de veces que el motor se ha reiniciado.

• msgAuthoritativeEngineTime: el valor snmpEngineTime del motor SNMP autoritativo involucrado en el intercambio de mensajes, representa el número de segundos desde que el motor SNMP incrementó snmpEngineBoots por última vez.

• msgUserName: el usuario a quien se le está intercambiando el mensaje. • msgAuthenticationParameters: es nulo si no se usa autenticación, de lo

contrario, es un código de autenticación de un mensaje HMAC. • msgPrivacyParameters: es nulo si no se usa privacidad, de lo contrario, es un

valor usado para formar el valor inicial en el algoritmo DES. Como SNMPv3 define el uso o no de autenticación y encripción, el motor SNMP requiere dos valores: una llave privada (privKey) y una llave de autenticación (authKey). Estos valores son atributos relevantes de cada usuario creado. Los valores de cada una de estas llaves no son accesibles vía SNMP.

4.3.2.3.3 El grupo MIB usmUser [10] Es una MIB que se encarga de mantener información sobre principales (entidades) locales y remotas. Contiene un objeto escalar llamado usmUserSpinLock (permite que generadores de comandos se coordinen para cambiar las llaves, como un método de garantizar la concurrencia) y una tabla usmUserTable, que tiene las siguientes columnas más importantes:

• usmUserEngineID: el identificador de un motor SNMP, que tiene el valor de snmpEngineID.

• usmUserName: el nombre del usuario que funciona como securityName. • usmUserSecurityName: el nombre del usuario de una forma independiente al

modelo de seguridad. Este valor y el anterior son iguales para que haya una relación de identidad.

• usmUserCloneFrom: se refiere a otra fila de esta tabla e indica el usuario del que fue clonado el nuevo usuario. Al ingresar un usuario nuevo se llenan los campos correspondientes y se pone una referencia al usuario del que se clonó (los parámetros de autenticación y privacidad son copiados del usuario original).

• usmUserAuthProtocol: identificador que indica si un mensaje enviado por la entidad, identificada por el usmUserEngineID es o no objeto de autenticación y además, especifica el protocolo a usar.

34

• usmUserAuthKeyChange: cuando es modificado, hace que la llave secreta de autenticación para enviar mensajes, sea modificada.

• usmUserPrivProtocol: identificador que indica si un mensaje enviado por la entidad, identificada por el usmUserEngineID, puede ser protegido por encripción o no, además indica el protocolo a utilizar.

• usmUserPrivKeyChange: cuando es modificado, causa que se cambie la llave secreta de encripción para enviar mensajes.

• usmUserPublic: valor que puede ser leído públicamente y que es escrito como parte del procedimiento de cambiar alguna de las llaves, para luego leerlo y ver si el cambio fue realizado.

4.3.2.3.4 Descubrimiento de motores SNMP USM requiere el uso de un proceso de descubrimiento para obtener suficiente información de otros motores SNMP, para poder llevar a cabo la comunicación. Para lograr esto, necesita conocer su snmpEngineID. Si el motor no es autoritativo, manda un mensaje de Request al motor del cual desea conocer los datos. La solicitud va con el campo securityLevel en noAuthnoPriv, el msgUserName con valor “initial” y el msgAuthoritativeEngineID como nulo. El motor autoritativo responde con un mensaje Report que contiene su snmpEngineID en el campo nulo. Si se requiere de una comunicación autenticada, el motor SNMP no autoritativo debe establecer una sincronización con el motor autoritativo. Para lograrlo, el motor no autoritativo manda un mensaje de Request con msgAuthoritativeEngineID con el valor del snmpEngineID y los valores de msgAuthoritativeEngineBoots y msgAuthoritativeEngineTime en cero. La respuesta va a ser un mensaje Report del motor autoritativo con los valores de snmpEngineBoots y snmpEngineTime en los respectivos campos con valor cero.

4.3.2.3.5 Administración de llaves Un requerimiento planteado en la creación del RFC para los servicios de autenticación y privacidad, es que para la comunicación entre un motor no autoritativo y uno autoritativo, se debe compartir una llave secreta de autenticación y una llave secreta de privacidad. Estas llaves permiten que un usuario en un motor no autoritativo, pueda emplear autenticación y privacidad en sistemas autoritativos remotos. Para mantener simple la administración de llaves, cada principal (una entidad a quien se le proveen servicios) es responsable por mantener una llave de autenticación y de encripción o privacidad. Estas llaves no son guardadas en una MIB y no son accesibles vía SNMP.

35

4.3.2.4 Modelo de control de acceso basado en vistas (VACM) El modelo VACM tiene dos importantes características [10]:

1. El VACM determina si el acceso a un objeto administrado, en una MIB local, por un principal es permitido o no.

2. El VACM hace uso de una MIB que controla las políticas de control de acceso para el agente

4.3.2.4.1 Elementos del modelo VACM El RFC 2575 define cinco elementos que componen el VACM:

1. Grupos. 2. Niveles de seguridad. 3. Contextos. 4. Vistas en las MIB. 5. Políticas de acceso.

Los grupos: se encuentran definidos como un conjunto de cero o más tuplas de tipo: <securityModel, securityName>. El securityName a un principal y los derechos de acceso para todos los principales en un grupo, y así todos en el grupo tienen los mismo accesos. Cada grupo tiene un nombre único (groupName) y así se pueden definir los derechos de acceso. El nivel de seguridad: los derechos de acceso para un grupo pueden definirse según el nivel de seguridad del mensaje en la solicitud. Por ejemplo, se puede permitir solo la lectura para un mensaje no autorizado, pero necesitar autenticación para escribir. Los contextos: un contexto MIB es un subconjunto de las instancias de los objetos de la MIB local. Permiten agregar objetos a una colección con diferentes políticas de acceso. El contexto se refiere a control de acceso. Una solicitud SNMP, identificada únicamente por un contextEngineID, puede mantener más de un contexto. Un objeto o una instancia de un objeto pueden estar en uno o más contextos. Cuando existen múltiples contextos, para poder identificar la instancia de un objeto, se deben identificar su contextName y contextEngineID. Las vistas MIB: algunas veces deseamos restringir el acceso de un grupo particular a un subgrupo de objetos de administración en el agente. Para poder hacer esto, el acceso al contexto se hace mediante la definición de vistas MIB. Esto saca provecho de que los objetos están organizados en forma de árbol. Por esto, asociado a cada

36

entrada en la tabla vacmAccessTable hay tres vistas: lectura, escritura y notificar acceso (representa el conjunto de instancias de objetos autorizados cuando mandan objetos en una notificación. Cada vista consiste en un conjunto de vistas de subárboles. Las políticas de acceso: el VACM permite que el motor SNMP sea configurado para impartir ciertos derechos de acceso. La determinación de acceso depende de [10]:

• El principal que hace la solicitud de acceso. El VACM permite que un agente pueda permitir diferentes privilegios de acceso a diferentes usuarios.

• El nivel de seguridad con la que se hizo la solicitud en un mensaje SNMP. • El modelo de seguridad usado para procesar el mensaje de solicitud. Por

ejemplo, se puede acceder a ciertos tipos si la solicitud viene a través de USM.

• El contexto de la MIB para la solicitud. • El tipo de acceso solicitado.

4.3.2.4.2 La MIB del VACM Contiene información de contextos locales, grupos, derechos de acceso y vistas MIB. Información sobre contextos locales:

La tabla vacmContextTable lista los contextos disponibles localmente. Esta información es usada por el generador de comandos para crear la tabla vacmAccessTable para poder controlar el acceso a los contextos. Un nombre de contexto vacío representa el contexto default. Estas dos tablas no se relacionan entre si.

Información sobre grupos:

La tabla vacmSecurityToGroupTable provee un groupName, dado un securityModel y un securityName. El nombre de grupo es usado para controlar el acceso de un grupo. La tabla es indexada por vacmSecurityModel y vacmSecurityName.

Información sobre derechos de acceso:

La tabla vacmAccessTable puede ser configurada para definir los derechos de acceso de los grupos. La tabla está compuesta por estos objetos:

• vacmAccessContextPrefix: puede ser el nombre de un contexto completo o el prefijo, según el valor de vacmAccessContextMatch.

• vacmAccessSecurityModel: identifica un modelo de seguridad. • vacmAccessSecurityLevel: el nivel mínimo de seguridad requerido

para tener acceso.

37

• vacmAccessContextMatch: el valor puede ser exacto (exact(1)), que significa que el nombre del contexto debe ser exacto; ó puede ser de prefijo (prefix(2)), entonces sólo debe haber concordancia entre el vacmAccessContextPrefix y el contextName. Es muy parecido al concepto de wildcards en Unix.

• vacmAccessWriteViewName: identifica la vista MIB para la cual se define el acceso. Indexa la tabla vacmViewTreeFamilyTable.

Información sobre vistas MIB:

La estructura de vacmMIBViews consiste de un objeto escalar, llamado vacmViewSpinLock (que permite que los generadores de comandos coordinen el uso de operaciones Set en la creación y modificación de vistas), y de una tabla vacmViewTreeFamilyTable, cuyas columnas son:

• vacmViewTreeFamilyViewName: el nombre asignado a un conjunto de filas que constituyen una vista.

• vacmViewTreeFamilySubtree: un identificador de objeto que especifica un subárbol.

• vacmViewTreeFamilyMask: la máscara que combinada con el vacmViewTreeFamilySubtree define una familia de subárboles.

• vacmViewTreeFamilyType: puede tomar uno de los valores siguientes: incluido (included(1)) o excluido (excluded(2)) e indica si el correspondiente subárbol de la familia, que está definido por los dos campos anteriores, está o no en la definición.

4.3.3 Comparación entre seguridad de SNMPv1 y SNMPv3 La seguridad en SNMPv1:

Tanto las estaciones administradas como las NMS, necesitan protegerse a si mismas y sus MIB’s de accesos no autorizados. SNMP, como se especifica en el RFC 1157, provee una muy simple manera de asegurarse: mediante el uso del concepto de comunidad. Una comunidad es la relación entre el agente y los administradores. Con la comunidad se define la autenticación y el control de acceso. Este concepto es local al dispositivo y se puede configurar una comunidad para cada combinación de autenticación y acceso. Por ejemplo, se puede definir una comunidad privada para lectura y escritura y una comunidad pública para sólo lectura. La comunidad es empleada como parámetro de comandos Get y Set. Se utiliza un esquema muy trivial de autenticación: la comunidad. La cual actúa como una clave compartida donde la solicitud recibida es procesada si el nombre de la comunidad de la solicitud concuerda con la comunidad definida en la entidad que recibe la solicitud.

38

De una manera muy sencilla, la comunidad, permite controlar el acceso a su MIB. Mediante el empleo de más de una comunidad, se puede proveer distintos tipos de acceso. Por estas razones es común que SNMPv1 se utilice más para monitoreo de dispositivos, que para control de los mismos, ya que el concepto de comunidad es muy inseguro y además viaja en texto plano por la red. Es un gran punto de inseguridad en una red, ya que es muy difícil saber a ciencia cierta quien es el que solicita la información.

La seguridad en SNMPv3:

Como se vio anteriormente, esta versión provee un mejor sistema de seguridad y mucho más robusto y confiable. Utiliza encripción convencional con DES y autenticación con MD5. Además utiliza un modelo de usuarios y de control de acceso, basado en vistas sobre la MIB actual. Esto permite que se pueda restringir el acceso a ciertas partes de la MIB.

4.4 DOCUMENTACIÓN DE MIB

4.4.1 Generalidades de MIB Este es un concepto que va muy unido al protocolo SNMP. Y que son de vital importancia para la arquitectura de su funcionamiento. Como ya se ha visto, las bases de información de gestión (MIB), son muy utilizadas por los agentes para poder monitorear un aparato específico. Las bases de información de gestión (MIB) son un conjunto de objetos gestionados de un recurso que se encuentra en la red para ofrecer algún tipo de interoperabilidad o funcionamiento en esta misma y el cual se desea gestionar. Dentro de la MIB, los objetos están organizados en grupos, según su función y la información que guarda. Los objetos en la MIB, se encuentran definidos formalmente y son administrados mediante el protocolo SNMP. En ella hay unos grupos estándares que todos conocen y con el tiempo se ha ido extendiendo según la aparición de nuevos aparatos gestionables con SNMP, que se conocen como extensiones de la MIB.

4.4.2 La estructura de administración de la información La SMI define como la información de administración es agrupada y nombrada, las operaciones permitidas, tipos de datos permitidos y la sintaxis para escribir las MIBs.

39

Especifica que cada objeto administrado debe tener un nombre (único, mediante el OID), una sintaxis (tipo de dato) y una codificación (como la información es serializada para la transmisión, comúnmente se usa BER). La SMI define la arquitectura general con la que se puede definir y construir una MIB. Especifica los tipos de datos que se pueden usar en la MIB y la forma en que los recursos en una MIB son representados e identificados. La MIB sólo puede guardar tipos de datos simple, conocidos como escalares. Por esta razón con SNMP solo se pueden consultar este tipo de datos. Para poder definir una MIB, es posible utilizar los siguientes tipos de datos:

• integer • octetstring • null • object identifier • sequence y sequence-of

En la lista no aparece el tipo enumerated, ya que éste se define como una lista de enteros de tipo integer. Hay que tener en cuenta que no se puede usar el valor cero (0), ya que este es usado para identificar instancias particulares de objetos y que debe haber normalmente un tipo adicional, llamado other, para cuando no se puede ninguno de los otros valores.

4.4.3 Interacción con la MIB Una NMS debe ser cargada con la información que va a monitorear, o sea, la estructura de la MIB privada. Normalmente un vendedor de dispositivos provee la MIB en un texto simple y en una descripción formal. Con la descripción formal, una NMS debe ser capaz de leer la MIB del disco, procesarla y pasarla para añadir los objetos a la lista de objetos administrados. Adicional a esta forma, la NMS puede utilizar un comando GetNextRequest para descubrir los objetos de una MIB del dispositivo. Esto se puede gracias al orden lexicográfico en que son representados los objetos en el árbol. Utilizando esta forma, tiene la ventaja de que descubre de una vez el valor del objeto. Existen dos formas de realizar la administración o gestión de la red: la primera, de forma pasiva (implica la recolección de datos de los equipos, únicamente de forma informativa, para ver que pasa con la red y los equipos) y la segunda, de forma activa (que usa las variables de la MIB que son de lectura y escritura, de tal forma que si un agente es instruido para modificar un valor, se pueda realizar una acción en el aparato). La comunidad OSI divide la administración de la red en cinco áreas funcionales [11]:

Bloques básicos para construir otros tipos más complejos de objetos.

Para construir tablas

40

1. Administración de la configuración: nombra todos los elementos en la red y

especifica su estado y características. 2. Administración del performance: determina la utilización de la red y de sus

elementos. Permite medir tiempos de respuesta, recursos utilizados, disponibilidad, etc.

3. Administración de errores: detecta, aísla y corrige problemas de red. 4. Administración de seguridad: controla el acceso y protege la información en

la red. 5. Contabilidad: mide el uso y el costo de los computadores basados en políticas

establecidas. Hasta este momento existen los siguientes tipos de MIB, cada uno con distinta funcionalidad:

• Los estándares: MIB I y MIB II (para una diferenciación entre las dos, ver más adelante)

• Las experimentales: grupos que se encuentran en fase de desarrollo • Las privadas: información específica de fabricantes de equipos para equipos

específicos

4.4.4 Notación de sintaxis abstracta ASN.1 ASN.1 es un lenguaje formal desarrollado y estandarizado por CCITT y la ISO. Es importante en la actualidad porque permite que se definan sintaxis sobre datos de aplicaciones. También, como sucede con SNMP, se utiliza para definir la estructura y la presentación de las PDU (Protocol Data Unit). El empleo de ASN.1 trae muchas ventajas a la hora de desarrollar una aplicación que la utilice. Trae beneficios como: estandarización (es un estándar internacional que soporta muchos protocolos y también elimina el problema de interoperabilidad), es algo que se escribe una vez y se puede usar por mucho tiempo (no hay que preocuparse por problemas de compatibilidad de versiones), es ampliamente divulgado y muy conocido. También es independiente del vendedor, de la plataforma y del leguaje de implementación. Terminología importante en ASN.1 [10]:

1. Sintaxis abstracta: describe la estructura general de los datos independiente de cualquier técnica de codificación para representarlos. Permite definir tipos y valores para los datos.

41

2. Tipo de dato: conjunto de nombres de valores. Pueden ser simples (especificados por medio de valores) o estructurados (especificados por medio de otros tipos).

3. Codificación: secuencia de octetos usada para representar los valores de los datos.

4. Reglas de codificación: especificación de un mapeo de una sintaxis a otra. Determina algorítmicamente como, para un conjunto de datos en una sintaxis, se hace para representar los valores en la otra sintaxis.

5. Sintaxis de transferencia: la forma como los datos son representados a nivel de bits cuando se van a transmitir de un lado a otro.

En la Figura 9 se puede observar como se relacionan estos conceptos [10]:

Figura 9. Relación de componentes ASN.1

En la Figura 9, se pueden identificar dos grandes componentes: el componente de transferencia de datos, que se preocupa por los mecanismos de la transferencia de datos entre entidades, y el componente de aplicación (en nuestro caso SNMP), encargado de transferir datos al usuario e interpreta lo que viene del componente de transferencia mediante las reglas de codificación. Debe existir un almacenamiento de algún tipo, en donde se va a guardar la definición de la estructura de los datos, que en nuestro caso van a ser las MIB’s (que son definidas con una sintaxis abstracta). Los componentes de aplicación se comunican entre si, por medio de una sintaxis abstracta. Se interesa por la vista de los datos que debe tener el usuario, ya sea un

42

archivo, una base de datos o simplemente en la pantalla. El usuario se preocupa por la semántica de los datos, básicamente, que lo que se va a enviar tenga coherencia y cumpla con ciertas reglas definidas. El protocolo describe las PDU’s mediante una sintaxis abstracta, similar a la notación Bacchus-Naur Form (BNF). Provee representación y revisión de la sintaxis de los datos. Mientras que los componentes de transferencia de datos se comunican por medio de una sintaxis de transferencia. Recibe los datos del componente de aplicación como una secuencia de octetos, que pueden ser ensamblados en la PDU correspondiente. Estos dos componentes se logran comunicar gracias a las reglas de codificación. Usando una sintaxis abstracta, se logran tener otros beneficios adicionales. Se tiene un buen uso de representaciones locales, ya que se logra tener una independencia de la implementación, del tipo de hardware y del tipo de representación interna de los datos. Ofrece un rehúso de esquemas de codificación, si se tiene unas reglas de codificación bien definidas, se puede referenciar por cualquier aplicación que use la misma sintaxis. También se puede tener una buena estructura del código, si se tiene una buena especificación de sintaxis abstracta y con ayuda de una herramienta, se puede generar el código respectivo. Gracias a la separación que tiene ASN.1 de la notación abstracta y la sintaxis de transferencia, se puede reutilizar el código. Con la ayuda de un “compilador” de ASN.1, cualquier definición en sintaxis abstracta puede ser mapeada a la estructura abstracta de datos de cualquier leguaje de programación. SNMP utiliza ASN.1, pero de una forma muy reducida y con muchas restricciones en los tipos que pueden ser utilizados.

4.4.4.1 Conceptos ASN.1 Convenciones lexicográficas: Las estructuras ASN.1, los tipos y los valores son expresados en una notación similar a la utilizada por leguajes de programación como C, C++ o Java. Se definen las siguientes convenciones [10]:

1. La distribución de las líneas no es importante. Puede haber múltiples espacios y líneas.

2. Los comentarios son delimitados por parejas de guiones (--). De esta forma: -- comentario – ó –comentario (toda la línea).

3. Nombres de valores y campos (identificadores) y nombres de tipos (referencias a tipos) consisten en letras mayúsculas o minúsculas, dígitos y guiones.

43

4. Los identificadores comienzan con una letra en minúscula. 5. Una referencia a tipo comienza con una letra en mayúscula. 6. Un tipo embebido (ya construido) consiste con todas las letras en mayúsculas.

Un tipo embebido es un tipo usado comúnmente para el cual se provee una notación estándar.

4.4.4.2 Tipos abstractos de datos ASN.1 es una notación para tipos de datos abstractos. Un tipo puede ser visto como una colección de valores. El número de valores que puede tomar es infinito. Los tipos se clasifican en cuatro categorías [10]:

• Simples: son tipos atómicos, sin componentes. Se define especificando directamente sus valores. Todos los otros tipos se construyen sobre tipos simples.

• Estructurados: un tipo estructurado tiene componentes. ASN.1 provee cuatro tipos, para construir tipos de datos complejos a partir de tipos simples. Estos son:

o SEQUENCE o SEQUENCE OF o SET o SET OF

Los primeros dos son usados para definir una lista ordenada de valores de uno o más tipos de datos. Mientras que los otros dos, son similares, pero el orden de los elementos no importa.

• Tagged: tipos derivados de otros tipos. • Otro (Other): incluye los tipos CHOICE y ANY.

Subtipos ASN.1 permite la definición de subtipos. Un subtipo, pertenece a un tipo padre. La idea del subtipo es restringir los valores que puede tomar y que son un subconjunto de los valores que define el padre. Esto se puede extender a más de un nivel. Hay seis formas para designar subtipos [10]:

• Un solo valor: es un subtipo que lista explícitamente todos los valores que un subtipo puede tomar.

• Subtipos contenidos: crea nuevos subtipos de subtipos ya existentes. El subtipo contenido debe llevar todos los valores del subtipo que contiene.

• Rango de valor: aplica solo a INTEGER y REAL. Es especificado mediante un valor mínimo y un valor máximo.

44

• Alfabeto permitido: solo puede ser aplicado a tipos con cadenas de caracteres. Este subtipo consiste de los valores que pueden ser construidos teniendo un subalfabeto, de uno más grande.

• Restricción de tamaño: limita el número de elementos en un tipo. Sólo puede ser aplicado a tipos definidos como cadenas.

• Subtipos internos: puede ser aplicado a SEQUENCE, SEQUENCE-OF, SET, SET-OF y CHOICE. Este incluye en su valor solo los valores que satisfacen una o más restricciones.

Cada uno de los objetos descritos en una MIB, se describen mediante la macro OBJECT-TYPE. Cada objeto especificado se puede descomponer en una serie de campos:

• Descriptor: nombre del objeto • Value: nombre del objeto en la forma de OID • Syntax: especifica el tipo de dato • Access: especifica el nivel de acceso • Status: muestra la vigencia de la definición del objeto • Description: texto que describe el significado del objeto

Mediante la macro OBJECT-TYPE se pueden definir tres tipos de objetos: tablas, filas y objetos terminales (hojas) [1]. Las tablas consisten en un conjunto de filas. La sintaxis de la tabla debe ser: “SEQUENCE OF <sequence>”. Normalmente se le pone como sufijo la palabra Table y a la secuencia se le pone el sufijo Entry. Por ejemplo, si la tabla se llama ifTable, la secuencia sería IfEntry. La cláusula ACCESS debe estar en not-accessible. El siguiente ejemplo muestra como se definiría la tabla de ifTable, que se refiere a las interfaces:

ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS mandatory ::= {interfaces 2}

Una fila consiste en un conjunto de columnas. Esta se debe consultar por sus columnas mediante un comando Get o GetNext. El nombre de la fila viene del nombre de la tabla, pero se cambia el sufijo Table por Entry. La cláusula SYNTAX debe ser la secuencia asociada a la tabla y el acceso debe ser not-accessible. El OID de la fila debe ser el mismo de la tabla, pero adicionándole el valor 1. La cláusula INDEX especifica las reglas para la construcción de instancias y es el nombre de la secuencia de un ítem de la secuencia. Sigamos definiendo las filas para el ejemplo anterior:

ifEntry OBJECT-TYPE

45

SYNTAX IfEntry ACCESS not-accessible STATUS mandatory INDEX {ifIndex} ::= {ifTable 1}

La secuencia es usada para especificar columnas en una fila (en otras palabras, es una secuencia de los campos que tendría la tabla). El nombre debe comenzar por mayúscula. La sintaxis general de una secuencia es la siguiente:

<seqItem> = <SequenceName> “::=” “SEQUENCE” “{“ <columnItem> <leafSyntax> {“,” <columnItem> <leafSyntax>}… “}”

Continuando con el ejemplo tenemos:

IfEntry ::= SEQUENCE { ifIndex INTEGER, ifDescr DisplayString, ifType INTEGER, ifMtu INTEGER, ifSpeed Gauge, ifPhysAddress PhysAddress, … }

Por último, los objetos terminales (hojas), son la agrupación de información más pequeña y se refiere a una variable específica. Continuando con el ejemplo:

ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface." ::= {ifEntry 2}

ASN.1 define tres tipos de objetos: tipos, valores y macros. Cada uno de estos se define de la siguiente manera:

46

• Tipo (type): NombreDelTipo ::= TYPE • Valor (value): nombreDelValor NombreDelTipo ::= VALUE • Macro: ver más adelante

También se tienen los siguientes tipos simples:

• INTEGER, tipo de dato que toma como valor un número entero, como por ejemplo:

Status ::= INTEGER {up(1), down(2), testing(3)} miStatus Status ::= up -- ó 1

• OCTET STRING: tipo de datos que toma cero o más octetos. Cada byte toma valores entre 0 y 255.

• OBJECT IDENTIFIER: tipo de dato que permite la identificación de objetos de gestión.

• NULL: tipo nulo. El SMI define la siguiente macro para los objetos que van a ser administrados:

OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= “SYNTAX” type (TYPE ObjectSyntax) “ACCESS” Access “STATUS” Status VALUE NOTATION ::= value (VALUE ObjectName) Access ::= “read-only” | “read-write” | “write-only” | “not-accessible” Status ::= “mandatory” | “optional” | “obsolete” END

4.4.4.3 Identificación de objetos Cuando se desee referir una instancia particular, se debe añadir un cero al final de la ruta, sea relativa o absoluta, de la siguiente manera: 1.3.6.1.2.1.1.1.0 ó sysDescr.0. Cada objeto definido tiene dos formas de identificarse en cuanto a la ruta y su posición en el árbol: una forma absoluta (en el cual se especifica el camino a un atributo desde la raíz del árbol, semejante a una ruta absoluta en los sistemas

47

operativos; siempre debe comenzar con un punto y debe especificar cada nodo por el que pasa) y otra forma relativa (que especifica el camino a algún atributo en el árbol, a partir de un nodo, muy parecido a una ruta relativa en los sistemas operativos). Un objeto específico se puede identificar de manera única mediante alguna de las siguientes tres formas:

1. Sólo números: se utiliza una secuencia de números enteros, separados por puntos. Por ejemplo: 2.1.1.1 que identifica el objeto sysDescr.

2. Sólo texto: se utiliza los nombres de los nodos, separados por puntos. Por ejemplo: mgmt.mib-2.system.sysContact que identifica el objeto sysContact.

3. Una combinación de los dos: se puede usar una combinación tanto de números como de texto, separados por puntos. Por ejemplo: mgmt.mib-2.1.sysContact que también identifica al objeto sysContact.

4.4.4.4 Ejemplo de la MIB de prueba TEST-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC1213-MIB; test OBJECT IDENTIFIER ::= { enterprises 1 } -- grupos en TEST tesis OBJECT IDENTIFIER ::= { test 1 } -- el grupo Tesis avDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Describe el tipo de antivirus que posee la máquina que se esta accediendo." ::= { tesis 1 } avUpdateVersion OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only

48

STATUS mandatory DESCRIPTION "Dice la versión de actualización de las definiciones de virus que tiene instaladas." ::= { tesis 2 } END Que nos generaría la siguiente estructura de árbol (como se ve en la Figura 10), donde sale lo que definimos bajo el nodo de private:

Figura 10. Vista del árbol construido

49

5 DESARROLLO DEL PROYECTO El desarrollo del proyecto se debe realizar en cuatro etapas muy importantes. La primera de ellas es la de documentarse sobre el funcionamiento tanto de SNMP como de la MIB. Luego, se debe definir el protocolo seguro que se va a utilizar en la comunicación entre el adaptador y la consola. A continuación se debe construir el adaptador que va a estar monitoreando los programas seleccionados en las máquinas. Por último, se debe elaborar la consola de seguridad que es en donde se va a ver reflejado lo que reportan los adaptadores. Este elemento debe soportar por un lado SNMP (para la comunicación con una consola de gestión) y por el otro el protocolo seleccionado para la comunicación con los adaptadores (SNMPv3). La arquitectura propuesta se puede observar en la Figura 11.

Figura 11. Arquitectura propuesta

Se busca que el adaptador esté constantemente monitoreando el log del programa en busca de alertas que esta haya generado en su ejecución. Las alertas encontradas las reporta a la consola de seguridad utilizando el protocolo seguro de comunicación. Como la consola tiene soporte a SNMP, un monitor SNMP podría comunicarse con esta y debido a que posee una MIB (que contiene las variables de seguridad), podría monitorear la consola de seguridad como si fuera un elemento de red como los otros. Es por esto que esta consola debe tener un agente SNMP para facilitar la comunicación hacia el monitor. Adicionalmente, la consola es capaz de generar alertas por otros medios, como por ejemplo hacia un correo. Si la alerta persiste y no se ha tomado ninguna acción sobre esta, es capaz de escalar el problema y de informarle a otra persona que se ha definido anteriormente en la estructura de la empresa. La idea del proyecto es dejar abierta la posibilidad que en un futuro se desarrolle o se utilice una herramienta de gestión de red para la integración con la consola de seguridad. Lo que se hizo es validar el modelo con un caso sencillo de

50

prueba de la comunicación con SNMP. Está fuera del alcance del proyecto la integración con una herramienta de gestión de red.

5.1 SELECCIÓN DE PROGRAMAS A UTILIZAR No se ha encontrado otra herramienta que pretenda integrar la gestión de red y la seguridad al nivel que nosotros lo necesitamos. Lo que se propone es muy particular: un modelo de seguridad que soporte SNMP, en especial, SNMPv3; es una herramienta integral, o sea, que permite integrar y monitorear muchas herramientas de seguridad, debido al uso de los adaptadores y hasta podría llegar a monitorear cualquier herramienta que genere logs de notificaciones del funcionamiento de la aplicación (que reflejen la acción que toma la herramienta frente a un suceso). Existen aplicaciones que generan notificaciones pero únicamente lo hacen sobre su plataforma (reportan lo que sucede en esa aplicación). Solo lo hacen algunas herramientas de manera centralizada para su producto, como por ejemplo, los antivirus, que utilizan programas instalados en los clientes pero administrados desde un servidor que tiene una consola robusta para soportar los clientes. Se utilizó como protocolo de comunicación SNMPv3, ya que no se pueden utilizar las versiones 1 y 2c por lo altamente inseguras y porque introducirían un punto inseguro en el modelo propuesto. SNMPv3 nos permite utilizar encripción y autenticación en los mensajes intercambiados ocultando el contenido y valores de los objetos. Además se encuentra estandarizado mundialmente. En la Figura 12 y 13 se observa el intercambio de mensajes utilizando SNMPv2. Ante una solicitud del valor de un objeto, mediante el comando Get, obtenemos el valor de dicho objeto. En las figuras se pueden observar claramente la comunidad utilizada, el comando, la versión del protocolo, el OID del objeto y su valor. En las Figuras 14 y 15 observamos el intercambio de mensajes utilizando SNMPv3. Ante un mensaje de tipo Get obtenemos el valor del objeto deseado. Se observan los campos de la versión utilizada, las tres banderas utilizadas y el contenido encriptado de la PDU.

51

Figura 12. Get utilizando SNMPv2

52

Figura 13. Response del mensaje SNMPv2

53

Figura 14. Get utilizando SNMPv3

54

Figura 15. Response del mensaje SNMPv3

55

5.1.1 Programa Net-SNMP Net-snmp es un programa que provee herramientas y librerías relacionadas al protocolo SNMP que incluye: un agente extensible, esto quiere decir que el agente básico que viene con el programa puede ser extendido a manejar otras MIB’s que uno puede desarrollar y estas pueden ser fácilmente introducidas al agente, por lo cual, éste puede monitorear lo que se le ha incorporado; una librería SNMP, provee una implementación del protocolo con la funcionalidad especificada en los RFC’s que definen el funcionamiento de SNMPv1, SNMPv2 y SNMPv3; herramientas para obtener y modificar información de agentes SNMP; herramientas para generar y manejar Traps; un “compilador” de MIB’s que se encarga de generar una plantilla de código en lenguaje C, y que implementa alguna de la funcionalidad final que tendría lo que uno está programando; entre otras. Los desarrolladores principales del proyecto son Dave Shield y Wes Hardaker. Utiliza un tipo de licencia BSD la cual nos indica que el uso, la copia, la modificación y la distribución del software y su documentación para cualquier propósito y sin ningún cargo, es permitido. Teniendo en cuenta que se debe poner el copyright adecuado y el permiso mencionado (especificados en el Anexo 1) y que deben aparecer en la documentación creada para la aplicación. No se permite que el nombre de ningún individuo ni institución sea usado con fines de publicidad o anuncio sin su previo permiso. Para información más detallada sobre el licenciamiento ver Anexo 1. El programa fue desarrollado y está dirigido a desarrolladores y administradores de sistemas con conocimiento en C para permitirles utilizar la arquitectura SNMP. Soporta los siguientes sistemas operativos: Microsoft Windows de 32-bit (95/98/NT/200/XP) y todos los POSIX5 (Linux/BSD/Sistemas operativos tipo Unix). El lenguaje de programación en el que está escrito el programa es en C y en Perl. Para ver información sobre la instalación del programa Net-SNMP referirse al Anexo 6.

5.1.1.1 Pruebas de concepto Se realizó para probar la validez y la forma de operación de las herramientas y librerías de Net-SNMP y así poder garantizar que efectivamente cumple con los requisitos para el desarrollo del proyecto. Esto permite mostrar la viabilidad de la 5 Portable Operating System Interface for uniX (POSIX): su objetivo es el de disminuir el proceso de desarrollo de software en distintas plataformas mediante el establecimiento de una guías para que sigan los distintos vendedores de sistemas operativos.

56

expansión de la aplicación para que monitoree nuevos objetos definidos. Se realizaron tres pruebas de concepto, que corresponden al desarrollo de las siguientes tres partes de la arquitectura de prueba: la consola, el agente y la MIB. En la Figura 16, podemos observar la arquitectura general de la prueba.

Figura 16. Prueba de concepto realizada

Se debió realizar una MIB con una variable de prueba para observar la versión de un antivirus, utilizando la notación ASN.1, de la siguiente manera: TEST-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString FROM RFC1213-MIB MODULE-IDENTITY, OBJECT-TYPE, enterprises FROM SNMPv2-SMI; tesis MODULE-IDENTITY LAST-UPDATED "0411050000Z" ORGANIZATION "Prueba de concepto" CONTACT-INFO "Nicolas" DESCRIPTION "Definición de la variable para la prueba de concepto." ::= { enterprises 1 } test OBJECT IDENTIFIER ::= { enterprises 1 } -- Grupos en TEST tesis OBJECT IDENTIFIER ::= { test 1 } -- El grupo Tesis

57

avVersion OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "La versión que tiene del antivirus." DEFVAL { 10 } ::= { tesis 1 } END Aquí se puede observar que se define el objeto avVersion, de tipo entero, con acceso de lectura y de escritura y valor inicial de 10. Luego de tener la definición de la MIB, se procede a “compilarla” con el programa que viene con la herramienta (llamado mib2c), el cual genera el código en C, que implementa esa funcionalidad. El código se debe modificar y especificarle el valor de los datos o el lugar de donde proviene el valor que va a utilizar la variable. En este caso particular no es necesario modificar el código. Luego, el código compilado, se debe incluir dentro del agente, para que este pueda monitorear el objeto definido. De esta forma se pueden hacer sobre la variable operaciones de lectura y de escritura. El agente solo inicializa la MIB que se definió y ninguna otra. Esto implica que una consulta a una variable del grupo system no se puede hacer, ya que el agente no inicializó dicha MIB. Se creó un agente personalizado que solo responde a peticiones de la variable definida. Esto permite seleccionar lo que se desea en el agente y así permitir que no use tantos recursos en cosas que no vamos a estar monitoreando. Por otro lado, la consola esta encargada de comunicarse con el agente con el protocolo SNMPv3. En la consola se maneja una sesión que es la encargada de llevar todos los parámetros de la configuración de SNMPv3. De esta manera se comunica utilizando autenticación (con MD5) y encripción (con DES). La consola puede consultar la variable que se le solicite. En este caso consulta la variable avVersion. Si trata de consultar un objeto que no ha sido definido en el agente, muestra un error diciendo que dicho objeto no está definido en el agente. Esto permite controlar lo que se desea que tenga el agente cargado. La prueba nos permitió probar que el programa Net-SNMP efectivamente sirve para lo que nosotros deseamos hacer. El programa permite extender el agente para que monitoree y guarde información de los logs y de esta manera poder desarrollar los adaptadores para que lean los logs y reporten a la consola de seguridad.

5.1.2 Selección de herramientas de seguridad Recordando que los principios de seguridad son:

58

1. Autenticación (la forma de determinar que una entidad es lo que dice ser). 2. Control de acceso y autorización (la forma de determinar los recursos y

servicios que puede utilizar la entidad). 3. Integridad (los datos reflejen la realidad y que correspondan con lo que

debe ser y no ha sido modificadas indebidamente). 4. Disponibilidad (los servicios y la información deben, en todo momento,

estar disponibles). 5. Confidencialidad (que la información sólo sea vista por los entes

involucrados en la comunicación y que un tercero no pueda ingresar). 6. No repudio (que algún ente que haya participado en la comunicación no

pueda negar su participación en ella). 7. Auditabilidad (la herramienta guarda algún tipo de registro de eventos que

han sucedido en el tiempo). A partir de la teoría se clasificaron las herramientas según grupos que pretenden proteger contra cierto problema de seguridad (clasificados en categorías genéricas) presente en las organizaciones. En estas clasificaciones se pueden agrupar la mayoría de las herramientas de seguridad [12] [13] [14] [15] [16] [17] [18]. Cada una de estas herramientas pretende fortalecer ciertos principios de seguridad como se ve en la Tabla 1. Se debe tener en cuenta la siguiente terminología utilizada:

• Spyware: es una palabra normalmente utilizada para software que soporta publicidad. Adicionalmente es una tecnología que ayuda a recolectar información de un individuo sin su consentimiento.

• Antivirus: es un programa que se encarga de escanear cualquier tipo de dispositivo de almacenamiento en busca de un virus conocido o potencial.

• Firewall: es un dispositivo o programa encargado de filtrar el acceso a una red. Permite definir lo que puede o no pasar a la red. Protege contra acceso no autorizado desde otra red.

• IDS: es un programa que se encarga de monitorear equipos en busca de indicios de un ataque o de búsqueda de una falla en la seguridad. Puede monitorear eventos en busca de algunos indicios.

Tabla 1. Principios garantizados por cada grupo de aplicación

59

Cada una de las categorías de programas se encarga de fortalecer ciertos principios de seguridad. Para muchos de los usuarios de computadores, los spyware son muy trabajosos de solucionar. Cuando el equipo posee un spyware instalado (normalmente es un programa en ejecución), se encuentra en peligro porque no se sabe exactamente como fue diseñado el programa. Podría abrir algún puerto y permitir el ingreso no autorizado, podría modificar o alterar datos en el equipo o hasta podría reportar cosas que hacemos o tenemos a otra persona. Los antivirus se encargan de buscar y eliminar virus de los equipos, que a su vez son programas hechos con intenciones no éticas. Protege un equipo de tal forma que no dañen su disponibilidad, ya que dependiendo del virus, podría afectar la disponibilidad de algún(os) servicio(s). Para un mayor nivel de protección encontramos los firewalls, que se encargan de filtrar acceso no autorizado y definen reglas de quien(es) pueden acceder a un determinado recurso que presta un servidor o hasta regular el acceso a una estación. Permite una forma de protección mayor para garantizar que las personas no puedan decir que no han hecho algo. Una forma más proactiva de estar protegido es mediante el uso de IDSs que permiten la detección temprana de ataques a equipos en la red. Así garantizamos prevenir que suceda algo en la red, que pueda perjudicar su normal funcionamiento. Por último, los sistemas operativos proveen cierto grado de protección contra estas características. Depende de la versión y el tipo de sistema operativo, se pueden controlar más o no estos principios. Se puede decir que ofrecen una primera capa de fortalecimiento de los principios. Es difícil proteger un sistema operativo que tiene muchas falencias de seguridad y por esto deben ser sistemas muy robustos y seguros. Estas aplicaciones que fortalecen los principios de seguridad tienen algo en común: la generación de logs como parte de su ejecución. Una de las características más importantes que debe tener el programa para que pueda ser monitoreado por el agente y por consiguiente por la consola de seguridad. Los programas que se analizan a continuación cumplen con alguno(s) de los criterios para el desarrollo del proyecto.

Tabla 2. Características analizadas de los Anti-Spyware

La Tabla 2 muestra las características presentes en tres programas Anti-Spyware. Se ven características como el sistema operativo que soportan (Windows o Linux), si se ejecuta como consola o con modo gráfico, si soporta logs binarios o de texto y por último si se pueden programar scans con los programas, para que así escaneen el sistema en busca de Spyware.

60

Tabla 3. Características analizadas de los antivirus

En la Tabla 3 se observar un listado de programas antivirus y algunas características interesantes para el proyecto. Se ven características como el sistema operativo que soportan (Windows o Linux), si se ejecuta como consola o con modo gráfico, si soporta logs binarios o de texto y por último si se pueden programar scans con los programas, para que así escaneen el sistema en busca de virus. La “s” en la gráfica indica que utiliza un servicio registrado en Windows.

Tabla 4. Características analizadas de los firewalls

Algunos programas de firewalls se muestran en la Tabla 4. Se puede observar un listado de las características de estos programas. Se ven características como el sistema operativo que soportan (Windows o Linux), si se ejecuta como consola o con modo gráfico, si soporta logs binarios o de texto y por último si están en continua ejecución, ya que estos programas protegen mientras el programa este en memoria. Puede ser interesante el firewall Kerio, que adicional a ser firewall tiene un IDS.

Tabla 5. Características analizadas de los IDS

61

En la Tabla 5 se observar algunos IDS. Se aprecia un listado de las características de estos programas. Se ven características como: el sistema operativo que soportan (Windows o Linux); si se ejecuta como consola o en modo gráfico; si soporta logs binarios o de texto; si tiene un sheduler incorporado para programar scans; si soporta más aplicaciones, que la herramienta se puede clasificar en más de una categoría ya que realiza otras funciones; la utilidad para el administrador de red, como le ayuda la herramienta de esa categoría a desempeñar su función y si le sirve para garantizar la seguridad en la red; la interacción por línea de comandos, que permite interactuar con la herramienta desde una consola de la línea de comandos para poder tomar una acción sobre ella y por último si están en continua ejecución, ya que estos programas protegen y alertan mientras el programa este en memoria y en ejecución. Puede ser interesante el firewall Kerio, que adicional a ser firewall tiene un IDS. Entendemos por manejan los con mucha información si la herramienta pone mucha información relevante al evento de seguridad detectado y da información sobre el evento.

Tabla 6. Criterios de selección de herramientas

En la Tabla 6 se puede observar unos criterios de selección con sus respectivos pesos, que serán utilizados como parte en la selección de las herramientas con las cuales se va a validar el modelo. Se utilizaron estos criterios porque son los que van de acuerdo a los intereses del proyecto por trabajar con herramientas gratuitas. Los pesos van de 1 (bajo) a 5 (alto). Luego de hacer un cruce de criterios y de herramientas a utilizar (Tabla 7), se obtuvieron los resultados que se muestran en la Tabla 8. En la Tabla 7, se observa los criterios utilizados en la evaluación y las herramientas a utilizar. Se calculó el peso total de cada aplicación, según los criterios establecidos. Vale la pena explicar un poco en que consiste la característica de soporte a más aplicaciones. Básicamente es que la herramienta no sólo se dedica a trabajar en la categoría a la cual pertenece sino que tiene otras características que le permiten estar en otra categoría. El criterio de la utilidad para un administrador de red se vio como lo que más le sirve para el desarrollo de su papel. Se piensa que si se tienen buenas políticas a nivel de IDS y de firewalls (que dan datos en tiempo real), se puede, en cierta, forma proteger contra los virus y spyware, ya que podría llegarse a filtrar ese

62

contenido. Tanto los antivirus como los anti-spyware pueden detectar las cosas un tiempo después y no sería tan crucial como con los otros.

Tabla 7. Resultados de aplicar criterios a herramientas

Tabla 8. Orden de las herramientas según su peso

El resultado de haberle puesto el peso a los criterios se observa en la Tabla 8. Según los criterios, vemos el orden de las herramientas según los pesos. Llaman la atención Kerio, IpTables y Avast!. En especial IpTables y Kerio. Las cuales son las herramientas que se utilizarán en el proyecto.

5.1.3 Selección de motor de base de datos Debido a las características del proyecto se ha pensado en utilizar como motor de bases de datos MySQL. Un motor que nos ofrece muy buenas características de desempeño, precio, confiabilidad, velocidad y escalabilidad. Es uno de los motores de bases de datos más populares utilizados. Una de las razones más importantes por las cuales se decidió utilizar este motor fue para mantener los costos del proyecto muy bajos, permitiendo su utilización por cualquier empresa sin importar su capacidad

63

económica. Vale la pena aclarar que cualquier motor de bases de datos puede ser utilizado en el modelo propuesto.

5.1.4 Análisis del protocolo syslog Con el fin de analizar otras posibilidades de comunicación y de no sesgarse a la utilización de solo unos recursos, se miró la posibilidad de utilizar el protocolo syslog como medio de manipulación de los logs. La idea es centralizar en un servidor todo el reporte de los logs y poner en este un agente SNMP que se encargaría de enviar mensajes a la consola de seguridad. De esta forma se crearía un adaptador para las herramientas y que reportara por medio del protocolo sucesos que encontrara en los logs. Esta idea debido al funcionamiento del protocolo, fue descartada, ya que no ofrece ningún tipo de seguridad. Lo interesante del protocolo es que muestra un formato de log que se debe seguir y que brinda información adecuada de algún evento. Syslog es un protocolo, definido en el RFC 3164, que permite que una máquina mande mensajes por una red IP a un servidor syslog como se muestra en la Figura 17. Permite que las herramientas puedan reportar sucesos por este medio al servidor, para que este se encargue de su procesamiento y de su almacenamiento. Los mensajes son transportados por el puerto UDP 514.

Figura 17. Funcionamiento de Syslog

La estructura que se define para los mensajes es: <Prioridad> Fecha Hora Equipo Aplicación: mensaje Tiene varios problemas de seguridad y es esto lo que puede traer problemas para nuestra arquitectura. Por el hecho de transportar los mensajes por un puerto UDP, no se garantiza que los mensajes sean entregados a su destinatario. Algo muy grave, ya que alguno de estos mensajes podría tener una gran importancia para la aplicación. A su vez, no puede garantizar el orden del recibo de los mensajes, tocaría diseñar algún método para lograr esto. Esto puede presentar problemas ya que se pierde tiempo y procesamiento tratando de averiguar el orden de los mensajes. Al no garantizar la entrega de los mensajes, estos se pueden perder y si el mensaje se pierde, se pierde y nunca será recibido ni nadie se enterará de que se perdió, ya que el servidor solo se encarga de recibir los mensajes y no de solicitarlos a las aplicaciones. Para los mensajes no se define ningún tipo de encripción ni de autenticación, algo que

64

podría ser un punto de inseguridad en la arquitectura propuesta. La falencia de estos aspectos de seguridad, permitiría que los mensajes fueran reenviados o duplicados, permitiendo que se recibieran datos erróneos o con intenciones maléficas. Adicional a todo esto, se tendría un punto de falla muy grande, ya que si por algún motivo el servidor perdiera su disponibilidad, la consola de seguridad se vería con problemas para poder monitorear las herramientas. Lo que si puede llegar a ser rescatable del protocolo es el formato del mensaje. La idea sería incorporar ese formato dentro de los logs que vaya a crear la consola de seguridad.

5.2 ARQUITECTURA DEL MODELO PROPUESTO

5.2.1 Arquitectura general En la Figura 18 se puede observar la arquitectura general de la solución planteada. Nos muestra un diagrama de capas con los respectivos componentes y la forma en que se comunican entre si. Antes de abordar la arquitectura propuesta es necesario aclarar unos términos de la arquitectura que son claves y deben quedar bien claros y entendidos para evitar cualquier confusión. En la arquitectura se mencionan los conceptos de adaptador, herramienta, consola de seguridad, incidentes de seguridad y eventos. El adaptador es el conjunto de agente SNMP y analizador de logs, que trabajan cooperativamente para lograr la funcionalidad deseada. Hay que aclarar la diferencia entre un agente SNMP proxy y un adaptador: el agente proxy está encargado de traducir del protocolo SNMP a un protocolo de administración propietario de un dispositivo, mientras que el adaptador traduce instrucciones de un ente no administrable, como son los logs, a SNMP. Por esta razón se habla de adaptador y no de agente SNMP Proxy. Se entiende por herramienta toda aplicación desarrollada con fines de garantizar la seguridad en la red sea un firewall, IDS, antivirus, etc. La consola de seguridad es el encargado de administrar de manera centralizada los adaptadores y de comunicarse con la consola de gestión. Los incidentes de seguridad y los eventos son la unidad básica de información utilizada por la consola de seguridad para guardar incidentes de seguridad en la base de datos. Se maneja un incidente por cada una de las máquinas para lograr de esta manera centralizar en un incidente todos los eventos reportados por el (los)

65

adaptador(es) de una máquina. A su vez un incidente de seguridad está compuesto por varios eventos, que son cada uno de los incidentes de seguridad reportados por los adaptadores y que contienen los datos detallados de lo que sucedió. Los eventos e incidentes tienen un procedimiento asociado que permite documentar como fue su solución. El procedimiento le permite documentar claramente lo que se hizo para solucionar el evento o el incidente, de esta forma se enriquece la base de datos con información que puede ser utilizada en un futuro y que también podría ayudar a solucionar otro evento de seguridad similar. Los incidentes y los eventos tienen asociado un estado, que indica si el evento o incidente ya fue solucionado o no, y además posee una fecha de cierre que le permite especificar la fecha de cierre del evento o incidente.

Figura 18. Arquitectura general

Se muestra un diagrama general de arquitectura y es necesario profundizar en la arquitectura del host y de la consola. El funcionamiento normal del modelo es:

1. El adaptador inicia su ejecución y manda un Trap informando que ya está monitoreando la herramienta.

2. La consola de seguridad recibe el Trap y registra el adaptador para que pueda ser monitoreado por la consola.

3. El adaptador cada minuto manda un Trap informando que está en ejecución y monitoreando la aplicación.

4. La consola de seguridad recibe estos mensajes que le indican que el adaptador aún está en ejecución.

5. Prepara las estadísticas para mandarle un Trap a la consola de gestión. En general frente a un suceso de seguridad sobre una máquina van a suceder los siguientes pasos:

66

1. La herramienta monitoreada detecta el ataque y genera las entradas correspondientes en el log.

2. El adaptador diseñado para monitorear la herramienta va a estar examinando el log y si encuentra un nuevo evento va a mandar un Trap a la consola de seguridad con la información necesaria.

3. La consola de seguridad recibe el Trap e indica que en esa máquina están ocurriendo sucesos de seguridad.

4. Guarda la información necesaria en la base de datos y prepara las estadísticas para mandar un Trap a la consola de gestión informándole el nombre de la máquina, la dirección IP, el número de incidentes de seguridad abiertos y el ID de cada uno de ellos.

5.2.2 Arquitectura del adaptador

Figura 19. Arquitectura del adaptador

Como se ve en la Figura 19, el adaptador está compuesto por dos componentes: un agente SNMP y un analizador de logs. El adaptador es el que va a permitir monitorear las herramientas de seguridad que no son capaces de reportar o generar mensajes SNMP. Este se encarga de reflejar la información y el estado que proviene del log, es decir, reporta lo que escribe la herramienta en el log. Los logs, dependiendo de la herramienta, se generan localmente y es el adaptador instalado en la máquina el que

67

se encarga de leer el log y de actualizar el estado de los objetos definidos en su(s) MIB(s). Lo interesante de algunas herramientas es que se pueden programar para ejecutarse en ciertos momentos, lo que puede solucionar el hecho de que sea el usuario quien genera la ejecución del programa. Otras herramientas están en constante ejecución monitoreando los eventos y modificando los logs. Es responsabilidad del adaptador notificar a la consola de seguridad, mediante una operación Trap, la ocurrencia de un evento. La consola es la encargada de tener la capacidad de determinar la gravedad del reporte. Previamente se debe analizar la estructura del log (que debe ser de tipo texto, según el criterio mencionado) y de ella sacar los campos relevantes que podrían ser importantes para la consola de seguridad y por ende para el administrador de red. Una vez analizada la estructura del log, se procede a realizar un analizador de logs específico para la aplicación y que esté en capacidad de leer el log. Para que el adaptador esté en la capacidad de monitorear los logs, se debe crear una MIB para esa herramienta, con los objetos definidos a partir de los campos relevantes del log.

5.2.2.1 Adaptador

5.2.2.1.1 Analizador de logs Es uno de los componentes vitales para la arquitectura propuesta, ya que es quien se encarga de ir al log y traer los datos para su transporte vía SNMP. Es difícil dar una arquitectura general para un analizador de logs, ya que su construcción está muy relacionada con la estructura misma del log. Lo que si se puede hacer es dar algunas pautas que se deben tener en cuenta cuando se planea construir un analizador de logs para determinada herramienta. Para el desarrollo del proyecto se desarrollaron dos adaptadores. Se recomienda que el analizador de logs sea un programa compuesto de un archivo .c y .h, ya que esto facilita su inclusión en el agente y su uso posterior dentro del código. Como en todos los .h, deben estar los prototipos de las funciones que se van a utilizar para acceder al log, para persistir y leer archivos temporales para el uso del adaptador y la estructura que va a representar los campos importantes del log. Por otro lado, el archivo .c contiene la implementación de las funciones, la lógica que se encarga de ejecutar esas tareas.

68

Es importante analizar la estructura del log y determinar los campos importantes del log, aquellos que nos brindan más información acerca del evento registrado en el log. Luego de haber analizado el log y de haber extraído los campos importantes, se procede a construir el .h y en especial la estructura que va a utilizarse para representar el log. Una vez creada la estructura que contendrá los campos del log, se puede proceder a implementar las funciones que se definieron en el .h. Para garantizar un mejor funcionamiento del adaptador, se recomienda tener en cuenta los siguientes puntos:

1. Como lo que se está leyendo es un archivo que puede llegar a tener miles de registros, es importante persistir mínimo a un archivo cuatro datos: el primero es un apuntador a la última línea que se leyó, para que de esta forma el adaptador pueda continuar leyendo el log desde donde quedó. Es importante tener este apuntador en el analizador porque permite controlar que cuando el contenido del log sea borrado, se pueda comenzar a leerlo desde el comienzo.

2. Segundo, se debe llevar un registro de la fecha y hora del último evento leído en el log. Aquí se encuentran los otros tres datos que nos interesa persistir a un archivo: el mes, el día y la hora del evento leído del log. Esto permite saber que el evento que vamos a procesar es antiguo o reciente comparado con el último que se leyó.

3. Como ya se ha mencionado, se deben persistir estos datos para que el adaptador en una ejecución posterior no termine reportando un evento que ocurrió hace días y sólo se enfoque en aquella parte del log que contiene eventos nuevos, que no han sido reportados.

4. Es importante definir bien cuales de los registros en el log van a ser reportados a la consola de seguridad. Estos requerimientos dependen del tipo de herramienta utilizada. Por ejemplo para un firewall se recomienda notificar a la consola de seguridad registros que hayan sido rechazados o denegados por la aplicación, ya que proveen mayor información sobre un posible ataque porque son reglas que el administrador ha definido para filtrar porque permiten bloquear puertas para un eventual ataque.

El analizador de logs construido posee dos funciones que se encargan de manejar el log. Existe una función, llamada void readFileK(), para leer el archivo de los datos que se persisten en el disco duro y que permite determinar el lugar en donde se leyó por última vez el log. La otra función utilizada, llamada kerioids *readAllK(), es la que se encarga de traer del log la siguiente línea que debe ser procesada y retorna la estructura con los datos correspondientes para que el agente SNMP actualice los valores de los objetos.

69

5.2.2.1.2 Consideraciones sobre los logs Con el fin de determinar la mejor forma de crear el modelo de seguridad, era necesario analizar cual arquitectura era la que más se adaptaba a nuestras necesidades y que pudiera brindar un mejor soporte y desempeño para futuras aplicaciones del modelo. Los criterios se piensan, no solo en el caso de estudio, sino a una escala mayor, como lo puede ser la implementación en una empresa. Estas consideraciones que se tuvieron en cuenta para la construcción del modelo, buscan favorecer el desempeño y confiabilidad de la aplicación. Ellas tienen relación con la forma de realizar el analizador de logs y la forma de realizar las MIB’s a partir de estos logs. Hay que tener en cuenta un factor que está siempre presente en las decisiones que vamos a tomar: la arquitectura de la herramienta que se va a utilizar para los agentes, el protocolo SNMPv3 (Net-SNMP) y el funcionamiento del protocolo SNMP. La consideración que se tuvo que tener en cuenta fue la de crear un analizador de logs genérico para los tipos de logs. Tras una larga investigación, se pudo determinar que no hay un estándar para los logs que manejen las aplicaciones. Es por esto que la estructura, el formato y el tipo de archivo quedan a disposición de los desarrolladores de las aplicaciones y es decisión de ellos escoger la mejor aproximación que les sirva. Esto complica mucho la unificación de los logs, ya que las empresas desarrolladoras crean los logs como un archivo de soporte para el funcionamiento solo de sus aplicaciones, sin pensar, en la tendencia que tiene hoy la tecnología de unificar el mundo de gestión y el de seguridad. Hecho que podría llegar a simplificar mucho el proceso de unificación planteado. Sería interesante la creación o mejoramiento de seguridad de protocolos, definidos en un RFC como en el caso de Syslog [21], que permitan el reporte estandarizado de mensajes para que los desarrolladores puedan utilizarlo en su estructura de los logs. En nuestro caso particular, como usuarios e integradores de estos dos mundos, era necesario analizar la posibilidad de crear un analizador de logs estándar. Se pensó que como algunos de los logs son archivos de texto, se podría tener la ayuda de un archivo que describe la estructura del log, para que el analizador estándar lo lea y pueda interpretar el log. El problema surge cuando vamos a ver a fondo los campos de los logs y se ve que al tratar de generalizarlos, hay diferencias sustanciales que podrían complicar tanto la construcción del analizador como del archivo de la estructura del log. Las herramientas que vamos a utilizar en el caso de estudio, son un vivo ejemplo de la falta de unificación en cuanto a la estructura de los logs. Tienen una estructura muy particular de los campos. En la Figura 20 se puede observar dos registros de los logs de estas dos aplicaciones. En la Figura 20 (a) se encuentra el formato del log de la herramienta Kerio y en la Figura 20 (b) está el de la herramienta IpTables. Se pueden observar sutilezas en el

70

registro de los campos de cada log. Por ejemplo, se puede ver el formato de la fecha del registro de la herramienta Kerio y compararla con el de IpTables; el registro de la MAC de IpTables, necesita de un tratamiento especial, ya que ahí se encuentran tanto la MAC de destino como la de origen. Es importante mencionar el hecho de que IpTables guarda sus registros en el log info del kernel. Por esta razón se encuentran no solo registros del programa, sino también del sistema operativo, para lo cual es necesario implementar un medio de filtrado de los registros para poder proceder a la extracción de los datos del registro de IpTables. Para esto, se utiliza el prefijo que se puede definir en las reglas del programa como filtrado de paquetes y que al decirle a la aplicación que escriba un registro en el log para determinada regla, se guardan los datos con el prefijo definido. En este caso se utiliza el prefijo: “Shorewall:all2all:REJECT:” como medio de filtrado de los registros. Esto también impide que se puedan generalizar los logs.

Figura 20. Estructura de los logs

5.2.2.1.3 Consideraciones sobre la MIB La consideración que se tuvo que tener en cuenta fue la de crear una MIB general para grupos de programas, esto es, una MIB para firewalls, otra para IDS, etc. El problema de utilizar una MIB para cada grupo viene cuando pensamos en el desempeño del modelo. Analizando la arquitectura propuesta se puede ver que el adaptador va a tener la implementación de la MIB de cada grupo dentro del código del agente. En el agente, más específicamente en el módulo de la MIB incorporada al agente, se define cada cuanto tiempo se va a llamar al analizador de logs. Por esta razón si se tiene un agente que va a monitorear más de una aplicación de un determinado grupo, ésta en un instante solo puede llamar a un analizador de logs. Esto quiere decir que si se van a monitorear, por ejemplo, 5 aplicaciones de un grupo el agente sólo puede monitorear una herramienta a la vez, ya que solo puede llamar a un analizador de logs a la vez y, además, solo tendría una instancia de cada objeto a monitorear, ver Figura 21 (a).

71

Este hecho puede afectar el tiempo de respuesta del agente, ya que en un instante sólo puede monitorear una herramienta. También tendría que implementar cierto algoritmo como puede ser “Round Robin”, para la selección del analizador de logs y la asignación del orden. Esto implica que el agente tardaría en monitorear una aplicación, lo que se demore el analizador de logs de cada una de las siguientes aplicaciones. Cabe notar que el analizador de logs va a leer un archivo, el cual puede ser tan pequeño como de unos cuantos KB o hasta de unos cuantos MB o más. Es por esto que ese tiempo de espera puede ser muy corto o tan largo como sea el tamaño del archivo. Aquí aparecería cierta demora en la monitorización de una determinada aplicación y se sacrificaría ese análisis en tiempo real. Elemento que se considera importantísimo en herramientas IDS, firewalls o antivirus. Lo mencionado anteriormente se puede solucionar implementando una MIB específica para cada herramienta a monitorear, para que de esta manera se incorpore esa MIB al agente y que esta se encargue de monitorear únicamente el log de esa herramienta, así, incrementando el tiempo de respuesta del agente para esa aplicación y también permitiendo que el análisis sea mucho mas cercano al tiempo de respuesta de la aplicación monitoreada, brindado resultados en vivo del estado de la aplicación, ver Figura 21 (b).

Figura 21. Implementación de la MIB para la herramienta

Para el caso de estudio se definió la estructura de árbol de las MIB’s a implementar (ver Figura 22). Como el caso de estudio es solo con fines de realizar una prueba de concepto, no se registró ni se solicitó una asignación de un número bajo la rama enterprises. El nodo principal de nuestro árbol es modSegSNMP (modelo de seguridad con soporte a SNMP). Debajo de esta hay otros dos nodos: agente y consola. Bajo la consola van a estar definidos los objetos que va a exponer a una

Adaptador Adaptador

72

herramienta de gestión y esta es la MIB que la herramienta de gestión va a conocer; bajo el agente van a estar las MIB’s de las herramientas que vamos a monitorear, para este caso, se encuentra un nodo kerio y otro ipTables. Debajo de estos, se van a encontrar los objetos que van a guardar los datos de los logs. Es aquí donde se reflejan los campos de los logs que son interesantes.

Figura 22. Estructura general de la MIB para el modelo propuesto

5.2.2.1.4 Construcción del adaptador Ahora es tiempo de definir y construir el analizador de logs para cada herramienta. Para esto es necesario ver la estructura del archivo y sus campos y decidir cuales pueden ser importantes para el administrador de red. Hay que preguntarse: ¿Cuáles campos brindan información pertinente sobre la seguridad? Luego de definir los

73

campos, se debe crear una estructura en C6 que va a contener variables en donde se van a reflejar los campos del archivo. Por ejemplo en la Figura 23 observamos una estructura (construida a partir de los campos importantes del log) para la herramienta Kerio.

Figura 23. Estructura en C para la herramienta Kerio

A partir de esa estructura, se procede a definir las hojas (objetos) a monitorear de cada aplicación. Para ver la definición de los objetos para una las dos herramientas referirse al Anexo 2. Se pueden añadir campos adicionales si se desea guardar datos adicionales. Para nuestro caso se define en ambas MIB’s un objeto xStateOfInterface (donde x puede ser k para Kerio o ip para IpTables) que permite tomar acciones sobre la interfaz de red del equipo. Para adicionar las MIB’s desarrolladas en el agente remitirse al Anexo 6. De esta forma se integra el módulo creado, según la MIB definida, al agente. Para que de esta forma el agente pueda mantener las instancias de las variables definidas (que son los objetos definidos en la MIB) y para que así pueda consultar y guardar los datos. En este punto ya se pueden hacer consultas a las variables definidas en el agente y dependiendo de los permisos, se pueden consultar y/o modificar los valores. Por ejemplo, se puede hacer esta consulta:

Entrando un poco más en la forma en que se extendió el agente es importante mencionar algunos aspectos relevantes del código. Para el caso de prueba se utilizó la herramienta mib2c para generar la plantilla del código a utilizar para poder extender

6 Lenguaje de programación C

74

el agente. En estos archivos aparecen funciones que vale la pena mencionar para que sirven. El archivo creado comienza con una función llamada:

void init_yy(void) //donde yy es el nombre del archivo generado por mib2c Esta función es la encargada de inicializar el módulo que queremos implementar. En este caso es para ipTables o kerio. Dentro de ella se van a definir las OID’s de cada objeto de manera estática y en formato de números, ya que se debe guardar durante la ejecución del agente estos valores para la consulta específica de las variables. También se encuentra la definición de las variables que van a estar encargadas de guardar los datos de las variables que vamos a solicitarle al analizador de logs. Una de las funciones más importantes es la que se encarga de registrar el objeto escalar y su handler o manejador, que es el que se encarga de administrar como vamos a manejar los datos de la variable. Por ejemplo se tiene que para poder manejar la variable y el dato del objeto ipDate, es necesario definir lo siguiente: netsnmp_register_scalar( netsnmp_create_handler_registration("ipDate", handle_ipDate, ipDate_oid, OID_LENGTH(ipDate_oid), HANDLER_CAN_RONLY )); La función encargada de registrar el objeto escalar es netsnmp_register_scalar que recibe como parámetro un apuntador a un netsnmp_handler_registration, que tiene el registro y apunta al handler o manejador para ese objeto. La función netsnmp_create_handler_registration es la encargada de crear y registrar el handler para ese objeto. Recibe el nombre del handler encargado de llamar a la función handle_ipDate para que atienda la solicitud SNMP, para el objeto ipDate_oid. La función OID_LENGTH calcula la longitud de dicho objeto. El último parámetro que en este caso es HANDLER_CAN_RONLY indica el nivel de acceso que se tiene, o sea si es de lectura o lectura y escritura. Ahora se va a ver en detalle la función handle_ipDate, encargada de atender solicitudes SNMP para el objeto ipDate. Su implementación es la siguiente: int handle_ipDate(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET:

75

snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,

(u_char *) data_ipDate, strlen(data_ipDate)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in

handle_ipDate\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } El switch sirve para identificar el tipo de solicitud proveniente. En este caso si es de tipo MODE_GET, se va a llamar a la función snmp_set_var_typed_value, que está encargada de manejar la obtención del valor del objeto solicitado. Recibe como parámetros la lista de variables solicitadas (requests->requestvb), el tipo de dato del objeto (ASN_OCTET_STR), un apuntador al dato del objeto y la longitud de los datos en bytes. De esta forma se puede consultar el valor del objeto. Otra función importante, un poco equivalente a la vista para registrar el objeto, es una función creada para registrar objetos de tipo enteros, como se ve a continuación: netsnmp_register_int_instance("ipStateOfInterface",

ipStateOfInterface_oid, OID_LENGTH(ipStateOfInterface_oid),

&data_ipStateOfInterface, handle_ipStateOfInterface);

La función netsnmp_register_int_instance recibe como parámetros el nombre del handler, el objeto (ipStateOfInterface_oid), su longitud, el valor que se va a registrar, y el handler que uno va a utilizar para manejar las solicitudes. Uno de las funciones básicas para la actualización de los datos del módulo es una función para registrar una alarma, para decirle al agente que cada cierto tiempo vaya por los datos. La función es la siguiente: snmp_alarm_register(1, SA_REPEAT, call_log_analyzer_iptables, NULL); La función snmp_alarm_register registra los callbacks que deben ocurrir cada determinado tiempo en el futuro. Recibe como parámetros cada cuantos segundos se debe llamar al callback, una bandera llamada SA_REPEAT que indica con cuanta frecuencia se debe llamar al callback, en este caso, el callback registrado se va a

76

repetir cada SA_REPEAT segundos, el callback que es un apuntador a SNMPAlarmCallback que es la función callback guardada y registrada para el uso cuando ocurra el tiempo, en nuestro caso va a ser call_log_analyzer_iptables, lo que quiere decir que cada que se cumpla el tiempo, se va a llamar al analizador de logs de una determinada herramienta y esta es la encargada de traer los nuevos datos del log, para que los guarde el módulo. Por último, recibe un apuntador que es usado por la función callback, pero en nuestro caso no se va a utilizar, por lo cual se manda como parámetro NULL. void call_log_analyzer_iptables(unsigned int clientreg, void *clientarg) { struct iptablesLog *data; int i=0; data=(struct iptablesLog *) calloc(1, sizeof(struct ptablesLog)); data->rdate=(struct CDate *) calloc(1, sizeof(struct CDate)); strcpy(data->computer,"a"); data=readAllIp(); if(strcmp(data->macdst,"")!=0) { strcpy(data_ipDate,data->rdate->date); strcpy(data_ipTime,data->rdate->time); strcpy(data_ipHost,data->computer); strcpy(data_ipIn,data->in); strcpy(data_ipOut,data->out); strcpy(data_ipMACDst,data->macdst); strcpy(data_ipMACSrc,data->macsrc); strcpy(data_ipSrcAddress,data->src); strcpy(data_ipDstAddress,data->dst); strcpy(data_ipPacketLength,data->len); strcpy(data_ipProtocol,data->proto); strcpy(data_ipSrcPort,data->spt); strcpy(data_ipDstPort,data->dpt); send_ipNotifyTrap_trap(); } } La función callback call_log_analyzer_iptables llama al analizador de logs y actualiza los datos que están actualmente en el módulo. Adicionalmente se manda un Trap con los datos recibidos mediante la función send_ipNotifyTrap_trap, que manda una Trap al lugar especificado en el archivo de configuración snmpd.conf en la parte donde dice trapsess, de esta forma: trapsess -v 3 -u nbatest -n "" -l authPriv -a MD5 -A nbaprueba -x DES -X nbaprueba -e 0x0102030406 localhost:162

77

Que especifica que se va a mandar un Trap, con los mismos datos que se usarían en un snmpget con versión tres. Solo que se especifica el equipo que lo va a recibir y por el puerto que lo recibe, que en este caso es el puerto default de 162. Para mandar el Trap desde el código se debe hacer lo siguiente: int send_ipNotifyTrap_trap( void ) { netsnmp_variable_list *var_list = NULL; oid ipNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,2,15,1 }; size_t ipNotifyTrap_oid_len = OID_LENGTH(ipNotifyTrap_oid); oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 }; size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap); oid ipDate_oid[] = { 1,3,6,1,4,1,1,1,2,1,0 }; size_t ipDate_oid_len = OID_LENGTH(ipDate_oid); snmp_varlist_add_variable(&var_list,

objid_snmptrap, objid_snmptrap_len, ASN_OBJECT_ID, (u_char *) ipNotifyTrap_oid,

ipNotifyTrap_oid_len * sizeof(oid));

snmp_varlist_add_variable(&var_list,

ipDate_oid, ipDate_oid_len, ASN_OCTET_STR,

data_ipDate, strlen(data_ipDate)); send_v2trap( var_list ); snmp_free_varbind( var_list ); return SNMP_ERR_NOERROR; } Se crea la lista que va a contener las variables y los datos. Se define el OID que identifica las Traps para la herramienta IpTables. Luego se define el OID de las Traps en general. Luego se definen los tamaños y los OID’s de las variables que va a contener el Trap, luego se asigna a la lista de variables el OID de las Traps en general y posteriormente con los objetos que queremos que contenga la Trap. Por último se manda la Trap que contiene una PDU de versión 2 y se libera la lista. La función snmp_varlist_add_variable adiciona la dupla (objeto, valor) a la lista de variables. Recibe como parámetros la lista de variables, el OID del objeto a adicionar, su longitud, el tipo de dato ASN que es el objeto, el valor del objeto y su longitud.

78

De la misma manera cuando el adaptador inicia su ejecución se manda una Trap informando que ese adaptador ha iniciado su ejecución y por tanto el monitoreo de la herramienta. Adicionalmente cada minuto se manda un Trap informando que el adaptador está “vivo”. Hay que mencionar que para que se tome una acción tras una solicitud, hay que definir en el handler de ese objeto la acción que se va a realizar, de la siguiente manera: int handle_ipStateOfInterface(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { if(reqinfo->mode==MODE_SET_ACTION) { if(data_ipStateOfInterface==0) { printf("Bring down interface"); } } return SNMP_ERR_NOERROR; } Aquí se verifica si el modo de la solicitud es MODE_SET_ACTION que indica que la solicitud es un snmpset al objeto y luego es necesario verificar si el valor de data_ipStateOfInterface es cero, en tal caso se debe bajar la interfaz de red.

5.2.3 Arquitectura de la consola de seguridad

79

Figura 24. Arquitectura de la consola de seguridad

La Figura 24 nos muestra los componentes generales de los que se compone la consola de seguridad. Ésta es la encargada de realizar acciones mediante la operación Set, sobre los adaptadores y también recibir Traps provenientes de ellos. Además muestra al usuario algunos datos relevantes de las herramientas que está monitoreando para que se informe sobre lo que está sucediendo en ellas. Otras funciones importantes que debe cumplir la consola de seguridad es la de notificar o generar alertas por otros medios que no sean mensajes SNMP como por ejemplo mensajes a un beeper o un celular. También debe ser capaz de escalar notificaciones de máquinas que están generando muchos problemas importantes y que no han sido atendidos oportunamente en la máquina. Adicionalmente, a la consola de seguridad se le deben informar las MIB’s de las herramientas que va a monitorear, con el fin de que pueda conocer los objetos por los cuales va a indagar en el host. También existe la posibilidad de que descubra estos objetos mediante unas operaciones GetNext o Walk (comando que trae en secuencia ciertos valores en orden lexicográfico) y así, no solo logra conocer el objeto, sino que conoce su valor. Como la consola de seguridad debe soportar SNMP, ésta incluye un agente SNMP para que pueda exponer objetos monitoreables a una consola de gestión. Al agente se le debe crear una MIB de aquellos objetos que deseamos exponer a la consola de gestión. Adicionalmente cuenta con un receptor de Traps que se encarga de recibir los Traps enviados desde los adaptadores para su posterior análisis y representación en la consola de seguridad.

80

La consola de seguridad utiliza una base de datos para guardar información referente a los incidentes de seguridad y eventos generados por los adaptadores y es ahí donde se guardan los datos reportados del log de la aplicación monitoreada. En la base de datos es donde se guardan las notificaciones recibidas por los adaptadores y es el repositorio de eventos que las herramientas de seguridad han escrito en sus logs. Desde este punto de vista vemos que en la base de datos se encuentra la información escrita en los logs de cada una de las herramientas, lo que permite ver desde la consola una consolidación de los logs para así poder simplificar el proceso de auditoría y análisis forense, procesos que necesitan de la verificación manual de los logs de las herramientas. Cada cierto tiempo la consola verifica si es necesario escalar un evento de seguridad que ya ha cumplido la vigencia para ser solucionado. De ser necesario manda un correo a la(s) persona(s) que están un nivel más arriba en el organigrama de la empresa.

5.2.3.1 Consola de seguridad La consola de seguridad, diseñada específicamente para los administradores de red u otra persona encargada de administrar el estado de la red, se encuentra compuesta de cuatro subsistemas que complementan la funcionalidad necesaria de la consola como se muestra en la Figura 25. Cada subsistema tiene determinadas tareas que permiten una buena independencia entre ellos y cada uno de ellos tiene una función específica.

Figura 25. Subsistemas de la consola de seguridad

81

5.2.3.1.1 Subsistema de ambiente gráfico Es el encargado de administrar la interfaz con el usuario y de responder a comandos del usuario al igual que mostrarle a él lo que ocurre en la aplicación. Aquí el usuario puede añadir o eliminar usuarios del sistema tanto para aquellos que acceden vía la consola o vía Web, editar parámetros de los Traps que entran y de los que salen. Adicionalmente puede interactuar con las máquinas y si lo desea las puede agrupar por subredes diferentes e insertar etiquetas que las identifiquen. Se muestra información del estado de las máquinas y si el usuario lo desea puede ver los incidentes de seguridad y eventos de la máquina deseada. Se encarga de permitir interactuar al usuario con los incidentes y eventos, permitiendo cambiar su estado, editar la fecha de cierre y agregar el procedimiento utilizado para solucionar el incidente y/o evento. Aquí se notifica en la pantalla del usuario el estado actual de cada una de las máquinas monitoreadas. Los estados manejados son: abierto, que indica que un incidente o evento se encuentra sin solución; cerrado, que indica la clausura y solución de un incidente o evento y por último, descartado, indicando que el incidente o evento no representa un evento de seguridad relevante. Cuando la máquina se encuentra arriba y se están recibiendo notificaciones de los agentes diciendo que están “vivos”, se muestran los botones en color azul (que indica que la máquina está viva); cuando los botones toman el color blanco quiere decir que no se han vuelto a recibir ningún tipo de notificación de ese agente; por último, cuando el botón está intermitente entre color azul y rojo, es porque se están recibiendo notificaciones del agente (que indica que la máquina está siendo atacada).

5.2.3.1.2 Subsistema de control de incidentes de seguridad Es la parte central de la arquitectura en donde se va a realizar todo el análisis y administración de los eventos, incidentes de seguridad, notificaciones y estadísticas necesarias para mantener al usuario informado. En este subsistema se procesan las notificaciones recibidas por el subsistema de recepción de mensajes SNMP. A partir de estas notificaciones se administran los incidentes y eventos para esa máquina. Cuando llega una notificación es necesario procesar su información y actualizar la base de datos con la información necesaria, calcular las estadísticas de las notificaciones recibidas, notificar al subsistema de ambiente gráfico que ha llegado un nuevo mensaje para que tome la medida adecuada, tomar la decisión si es necesario el envío de una notificación vía SMTP y por último, cada cierto tiempo preparar un mensaje para el subsistema de envío de mensajes SNMP.

82

5.2.3.1.3 Subsistema de recepción de mensajes SNMP Su función es la de estar constantemente escuchando notificaciones provenientes de los adaptadores para así notificarlas al subsistema de control de incidentes de seguridad. Al arribo de una notificación es necesario analizar el contenido del Trap y extraer la información relevante para el subsistema de control de incidentes de seguridad. Una vez analizada la información se debe armar el mensaje para notificárselo al subsistema de control de incidentes de seguridad y así enviarle la información necesaria para que sea procesada.

5.2.3.1.4 Subsistema de envío de mensaje SNMP Está encargado de mandar Traps informativas a una consola de gestión. Cada cierto tiempo, cuando así lo determine el subsistema de control de incidentes de seguridad, es necesario tomar la información estadística suministrada por ese subsistema y armar un Trap con esa información para que así sea enviada esta información a la consola de gestión, en donde se reportará que algo ha sucedido. Este subsistema hace uso del agente SNMP y de la MIB para poder exponer la información necesaria para una consola de gestión. Esta MIB fue diseñada para mostrar información que ha sido analizada y filtrada por la consola de seguridad, permitiendo que la consola de gestión vea solo estos datos porque no está dentro de su función la de monitorear y recibir información acerca de herramientas de seguridad. Por esta razón no se exponen los datos de las MIB de los adaptadores y también para evitar que la consola de gestión reciba notificaciones que la consola de seguridad ha recibido. Lo que quebrantaría un poco el modelo propuesto y la utilidad de la consola de seguridad, que es la encargada de administrar y gestionar las herramientas. Para los usuarios autorizados que desean conocer información acerca de los incidentes y/o eventos existe un ambiente Web por donde pueden acceder a dicha información y consultar el estado de los incidentes y/o eventos de las máquinas. Este ambiente es solamente informativo y no permite ningún tipo de interacción con la información presentada al usuario.

5.2.3.2 Modelo entidad-relación de la base de datos utilizada El diagrama de entidad-relación utilizado en la consola de seguridad se muestra en la Figura 26. Se puede observar que una máquina puede tener varios incidentes de seguridad (en caso que tenga uno o más vencidos) y que a su vez cada incidente puede tener varios eventos. La tabla usuario es utilizada para guardar los usuarios que van a acceder a la consola de seguridad y al ambiente Web. Por último la tabla datos del programa se utiliza para guardar datos relacionados con la ejecución de la consola.

83

Figura 26. Diagrama entidad-relación

5.2.3.3 Diagrama de clases de la consola de seguridad Referirse al Anexo 9 para los diagramas de clases.

84

6 PRUEBAS

6.1 DESCRIPCIÓN DE LA PRUEBA Una vez planteado el modelo de seguridad propuesto, es necesario realizar un protocolo de pruebas para poder validar el modelo y presentar un ambiente de prueba que lo muestre en ejecución. Por esta razón se construyó un ambiente de pruebas que trate de simular lo que puede ser una red corporativa, en donde se pretende que usen el modelo para fortalecer aún más sus niveles de seguridad y brindar una mejor y rápida respuesta ante incidentes en la red. Es necesario aclarar que cuando nos referimos a agente, no debe entenderse como un agente SNMP, sino como un agente de seguridad o adaptador, basado en SNMP para comunicarse. Referirse al Anexo 7 para la instalación de los componentes. La Figura 27 muestra la red utilizada para simular una red corporativa y en donde va a correr la implementación del modelo. Se puede apreciar que se utilizaron dos enrutadores cada uno conectado a una subred diferente. En cada subred hay un IDS y un firewall que pretenden mostrar varias herramientas de seguridad corriendo y como va a ser la alerta de los eventos en la consola de seguridad. Adicionalmente permite ser usada como un punto de referencia ya que podemos comparar el desempeño de la herramienta en ambas subredes y evitar que el resultado sea afectado de alguna manera por las configuraciones en los equipos y programas. En la red aparece una consola de gestión que fue utilizada para validar que efectivamente la consola de seguridad se puede comunicar con una consola de gestión, ya que debe brindar soporte a SNMP para la integración con una herramienta de gestión. Las redes cuentan tanto con sistemas operativos Windows como Linux. A continuación se ve la configuración que tienen los equipos:

• Marca: DELL • Procesador: Pentium 4 de 2.66 GHz • RAM: 256 MB a 333 MHz • Sistema operativo: Windows 2000 o Linux Mandrake 10 • Tarjeta de red: 10/100 Mbps

En la máquina del atacante se utilizó un programa llamado GFI LANguard Network Security Scanner, que se encarga de detectar vulnerabilidades en los equipos, provee información detallada de las máquinas y permite administrar los parches del sistema operativo y de los programas. Entre las pruebas de vulnerabilidades que hace, se encuentran las siguientes: escaneo e identificación de puertos, detección de parches instalados, detección de recursos compartidos, detección de usuarios y grupos no

85

utilizados, detección de vulnerabilidades CGI, detección de vulnerabilidades de RPC y de correo, entre muchas otras vulnerabilidades. Algunas de las detecciones que el enrutador impide que pasen son: descubrimiento de SNMP, escaneo de sesiones nulas, entre otros. Los switches utilizados son 3Com SuperStack 3 y los enrutadores son Cisco 2500 y 3600. Los concentradores utilizados fueron unos Cisco FastHub 400 series. Se realizaron las siguientes pruebas con el modelo planteado:

1. Porcentaje de utilización de CPU por parte de los agentes 2. Utilización de la red de una herramienta comercial de gestión 3. Prueba de funcionalidad de la aplicación: desempeño y funcionalidad 4. Medición de la carga de red de la forma siguiente (en ambas subredes):

a. Sin agentes ni consola de seguridad en ejecución b. Con agentes y consola de seguridad en ejecución, pero sin ataque c. Con agentes y consola de seguridad en ejecución, pero con ataque d. Sin agentes ni consola de seguridad, pero con ataque

5. Medición de la carga soportada por la consola de seguridad

6.2 DESARROLLO DE LAS PRUEBAS Luego de efectuar las mediciones necesarias se obtuvieron los siguientes resultados (las mediciones se realizaron cuatro veces para poder sacar estos resultados): 1) Porcentaje de utilización de CPU de los agentes:

1. IDS (Windows 2000): a. Máquina 1 (subred 1): oscila entre 0% y 2%, según mediciones del

sistema operativo b. Máquina 2 (subred 2): oscila entre 0% y 3%, según mediciones del

sistema operativo 2. Firewall (Linux Mandrake 10):

a. Máquina 1 (subred 1): utilización de 6%, según mediciones del sistema operativo

b. Máquina 2 (subred 2): utilización de 9%, según mediciones del sistema operativo

86

Figura 27. Diagrama de la red de prueba utilizada

87

Las mediciones de la utilización de CPU fueron obtenidas mediante el uso de herramientas incorporadas en los sistemas operativos. Se realizaron mediciones cada 30 segundos por in intervalo de 5 minutos. Es importante aclarar que los servicios que se estaban ejecutando en cada uno de los sistemas operativos de cada una de las máquinas, son los que vienen por defecto tras la instalación de cada uno de los sistemas operativos. Adicionalmente, en las máquinas de Windows 2000 se estaba ejecutando el IDS (Kerio) y el agente. Por otro lado, en las máquinas con Linux se estaba ejecutando Webmin, IpTables y el agente. 2) Utilización de la red de una herramienta comercial de gestión: Antes de entrar a este punto es importante mostrar la carga de la red sin ninguna herramienta de gestión ni de seguridad en ejecución. La Figura 28 muestra los resultados obtenidos con una duración de la medida de aproximadamente de 10 minutos (en la subred 1). Teniendo en cuenta la velocidad de la tarjeta de red de la máquina que realizó las mediciones en la subred 1 que es de 100 Mbps se puede calcular la utilización (el porcentaje del ancho de banda disponible utilizado). En este caso la utilización promedio es de 0.0005% aproximadamente.

Figura 28. Utilización de la red en la subred 1

Para esta prueba se utilizó una herramienta que provee la empresa AdventNet llamada SNMP Trap Stormer, la cual se puede configurar para mandar Traps cada cierto tiempo. Para que la herramienta se pueda comparar fácilmente con los agentes utilizados, se configuró para que mandara Traps cada minuto (tiempo en el cual el agente nuestro manda un Trap a la consola de seguridad diciendo que está vivo). La herramienta también permite configurar los objetos y sus valores (varbinds) que va a contener el Trap que, en este caso, se configuró de la misma forma en que lo mandaría el agente. En la Figura 29 se puede observar la carga en la red bajo la ejecución de la herramienta de gestión con una duración de la medida de aproximadamente de 10 minutos en la misma subred. En este caso la utilización promedio es de 0.0006% aproximadamente.

88

Figura 29. Utilización de la red en la subred 1

3) Prueba de funcionalidad de la aplicación: desempeño y funcionalidad Luego de un ataque se compararon los registros encontrados en el log de las herramientas generados por el ataque contra los eventos almacenados en la base de datos.

a. IDS (Windows 2000): a. Máquina 1: 5 entradas en el log y 5 eventos en la base de datos b. Máquina 2: 5 entradas en el log y 5 eventos en la base de datos

b. Firewall (Linux Mandrake 10): c. Máquina 1: 846 entradas en el log y 362 eventos en la base de datos d. Máquina 2: 84 entradas en el log y 66 eventos en la base de datos

Ambos IDS reportaron cinco eventos de cinco entradas en el log, lo que indica un 100% de reportes de eventos desde los IDS. Por otro lado, el firewall de la máquina 1 y de la máquina 2 reportaron el 42.8% y 78.6% de eventos respectivamente. Se realizaron pruebas adicionales para determinar la causa en la pérdida de eventos no notificados. Una de las causas que lo afecta es el tiempo de procesamiento y de notificación de los eventos, en primer lugar, la velocidad a la que funcionan los lenguajes de programación utilizados: C y Java, siendo el segundo un poco más lento por su velocidad de procesamiento. En segundo lugar, se observa que hubo más pérdidas de eventos notificados en las máquinas que debían mandar los Traps de una subred a otra, razón por la cual es muy importante el ancho de banda y la velocidad a la que se comunican los enrutadores. En la máquina 2 hay menos entradas en el log que en la máquina 1, debido a que el atacante está en otra subred y por consiguiente se filtran varios tipos de ataques en los enrutadores. En la Tabla 9 las pruebas 1 y 2 de las máquinas 1 y 2 se hicieron reportando por grupos de notificaciones de 100 eventos; las pruebas 3 y 4 de ambas máquinas se hicieron con grupos de a 50 eventos y, por último, las pruebas 5 y 6 se hicieron con grupos de 25 eventos. Estos resultados indican que el agente está enviando grupos de muchas notificaciones a la consola de seguridad y en cierta manera la satura impidiendo que procese todos los grupos de eventos recibidos. Bajando el número de eventos en cada grupo reportado, se logra aumentar la capacidad de la consola de seguridad de procesar y analizar las notificaciones recibidas. Adicionalmente se puede mejorar el envío de notificaciones

89

incluyendo algún tipo de “inteligencia” en el agente que pudiera decidir que notificar y que no y que decida lo que es relevante añadir al grupo de notificaciones.

Máquina 1 Máquina 2 Prueba Log BD % Prueba Log BD %

1 863 436 50.5 1 84 68 80.9 2 865 438 50.6 2 95 72 75.8 3 858 589 68.6 3 83 74 89.1 4 870 606 69.6 4 87 76 87.3 5 861 857 99.5 5 91 88 96.7 6 867 863 99.5 6 93 91 97.8

Tabla 9. Porcentaje de notificación de eventos en el log 4) Medición de la carga de red en estas condiciones (en ambas subredes):

a. Sin agentes ni consola de seguridad en ejecución:

Esta prueba se realizó para ver la utilización de la red en cada una de las subredes para tener un punto de comparación con las pruebas siguientes. En la Figura 30 (a) se puede ver la utilización en la subred 1, mientras que en la Figura 30 (b) se observa la utilización en la subred 2 con una duración de la medida de aproximadamente de 10 minutos. Teniendo en cuenta la velocidad de la tarjeta de red de la máquina que realizó las mediciones en la subred 2 que es de 10 Mbps se puede calcular la utilización (el porcentaje del ancho de banda disponible utilizado). En este caso la utilización promedio para la Figura 30 (a) es de 0.0005% aproximadamente y de 0.004% aproximadamente para la otra.

(a) – Subred 1

90

(b) – Subred 2

Figura 30. Utilización de la red b. Con agentes y consola de seguridad en ejecución, pero sin ataque:

En esta prueba se puede observar la utilización de la red, en ambas subredes, tanto de los agentes como de la consola de seguridad en ausencia de un ataque sobre los equipos. En la Figura 31 (a) se aprecia la utilización en la subred 1, mientras que en la Figura 31 (b) se observa la utilización en la subred 2 con una duración de la medida de aproximadamente de 10 minutos. La última gráfica tiene esos picos que indican la presencia de la consola de seguridad en esa subred, ya que cada uno de los picos muestra cuando llegan los Traps de los agentes. Cada agente, bajo ausencia de un ataque, manda un Trap cada minuto especificando que está en ejecución y por tanto monitoreando la herramienta. Es por esto que cada minuto un agente pone una carga adicional de aproximadamente 190 bytes en la red. Cada uno de los picos tiene una duración de aproximadamente 10 segundos. En la Figura 31 (c) podemos observar el tráfico generado en la subred 1, que a diferencia de la figura (a), fue medida utilizando un concentrador, para que no tuviéramos problemas en la medición debido a los dominios de colisión de un switch. En este caso la utilización promedio aproximada para la Figura 31 (a) es de 0.0005%, de 0.03% para la (b) y de 0.0009% para la (c).

(a) – Subred 1

91

(b) – Subred 2

(c) – Subred 1

Figura 31. Utilización de la red c. Con agentes y consola de seguridad en ejecución, pero con ataque:

El siguiente paso en las pruebas es probar el desempeño de la red bajo el efecto de un ataque sobre los equipos que están monitoreando los agentes, utilizando los switches. En la Figura 32 (a) se observa la utilización en la subred 1, mientras que en la Figura 32 (b) se muestra la utilización en la subred 2 con una duración de la medida de aproximadamente de 15 minutos. En este caso la utilización promedio aproximada durante la duración del ataque es para la Figura 32 (a) de 0.03% y de 1.5% para la gráfica (b). El ataque hacia todos los equipos tuvo una duración de dos minutos y treinta segundos aproximadamente. La Figura 32 (b) tiene una utilización del 1.5% ya que en la subred 2 se encuentra la consola de seguridad lo que genera en esa subred más tráfico que el de un ataque normal, debido a las notificaciones de los eventos por parte de los agentes en ambas subredes.

(a) – Subred 1

92

(b) – Subred 2

Figura 32. Utilización de la red

d. Sin agentes ni consola de seguridad, pero con ataque

Para poder determinar el tráfico adicional generado por la consola de seguridad, bajo un ataque, es necesario medir la carga generada por el mismo tipo de ataque que se hace sobre las máquinas con los agentes monitoreando, pero esta vez no van a estar corriendo los agentes para no generar el tráfico adicional. En la Figura 33 (a) se puede ver la utilización en la subred 1, mientras que en la Figura 33 (b) se observa la utilización en la subred 2, resultado que corresponde a una medición en la máquina donde se tomaron las medidas. La duración de la medida fue de aproximadamente de 10 minutos. La Figura 33 (c) muestra la utilización en la subred 2 utilizando un concentrador, lo que muestra un resultado de medida total de la subred. En este caso la utilización promedio aproximada durante el ataque para la Figura 33 (a) es de 0.05%, de 0.004% para la (b) y de 0.15% para la (c).

(a) – Subred 1

(b) – Subred 2

93

(c) – Subred 2

Figura 33. Utilización de la red 5) Medición de la carga soportada por la consola de seguridad: Esta prueba se realizó con el fin de determinar que tanta carga de información (en este caso los Traps generados por los adaptadores) es capaz de soportar la consola de seguridad hasta el punto de saturarse y dejar de funcionar correctamente. La finalidad de la prueba es poder determinar cuántos adaptadores o Traps es capaz de soportar, bajo el funcionamiento en el peor caso, que es cuando se está realizando un ataque sobre las distintas máquinas monitoreadas y por ende se genera un gran número de mensajes. Vale la pena aclarar que la prueba tiene factores adicionales que pueden afectar el umbral de mensajes que puede procesar la consola. Entre estos se encuentra que cada Trap que recibe la consola debe ser procesada y analizada por el subsistema de control de incidentes de seguridad y además debe ser almacenada la información en la base de datos. Otro factor que entra en consideración es la velocidad con la que se procesan las instrucciones de la aplicación dada la naturaleza de la herramienta de desarrollo seleccionada, en este caso JAVA. Para realizar la prueba se contó con una herramienta que genera Traps en ráfagas y tiempos definibles. La herramienta a utilizar se llama SNMP Trap Stormer de AdventNet. Permite configurar los Traps de la misma forma y con la misma información como si fueran envidos desde los adaptadores. Es importante mencionar que debido a la implementación de los adaptadores el máximo número de Traps que se pueden a enviar desde los adaptadores desarrollados es de 25 Traps por segundo. La prueba se realizó generando este tipo de tráfico desde una estación hacia la consola de seguridad. Se configuraron los Traps de la misma manera a como los enviaría un adaptador. La Figura 34 muestra el tráfico normal de la red.

94

Figura 34. Tráfico normal de la red

La prueba se realizó enviando a la consola de seguridad 2000 y 3000 Traps para ver si era capaz de soportar esta cantidad de mensajes. En el primer caso, la consola es capaz de procesar y almacenar en la base de datos la información de un total de 1855 mensajes que los recibió en un periodo de 80 segundos, dando como resultado una eficiencia del 92%. Para el último caso, se procesaron y almacenaron un total de 1872 mensajes durante 110 segundos, tiempo en el cual la aplicación dejó de responder. La Figura 35 muestra la carga que recibió la consola de seguridad antes de dejar de funcionar.

(a) 2000 Traps

(b) 3000 Traps

Figura 35. Gráficas del envío de un gran número de Traps a la consola

6.3 RESULTADOS DE LAS PRUEBAS Como se puede observar, la utilización de CPU de los agentes es considerablemente baja, lo cual no causa ninguna interferencia con el desempeño normal de la máquina, ya que no consume recursos significativos.

95

Por otro lado, la carga adicional generada sobre la red debido a la utilización de los agentes y de la consola de seguridad es baja. Cada agente pone aproximadamente 190 bytes en la red, en ausencia de un evento de seguridad, cada minuto para notificar que está “vivo”. Con solo los adaptadores y la consola de seguridad en ejecución se genera una utilización de menos de 0.001%. Que comparado con una herramienta de gestión comercial, que tiene una utilización de 0.0006%, es muy similar, lo que nos indica que la utilización de la red de la arquitectura desarrollada no es alta. La carga adicional generada durante un ataque en la red debido a la arquitectura es de aproximadamente un 10% debido a la notificación de eventos, carga que depende del tipo de ataque realizado y del número de máquinas atacadas. Comportamiento esperado durante un ataque. La última prueba realizada permitió determinar el máximo número de Traps que la consola de seguridad es capaz de recibir hasta dejar de funcionar. Según los resultados, es capaz de soportar hasta 2500 Traps aproximadamente recibidos en un periodo de 90 segundos. Un adaptador en el peor caso es capaz de generar hasta 25 mensajes en un segundo, por esta razón se puede decir que la consola soporta hasta 100 adaptadores aproximadamente. Para mejorar estos resultados puede ser necesaria la utilización de un balanceador de carga y de un procesamiento distribuido de la información que requiere la consola. Esto no quiere decir que se vayan a tener varias consolas, por el contrario se va a tener una sola y el procesamiento de la información recibida se va a hacer en forma distribuida. Permitiendo que de esta manera la consola de seguridad consolide toda esta información. Recordemos que este análisis es para el peor caso y se espera que solo suceda en condiciones extremas de ataques similares a DDoS, sin embargo no se podrían procesar más de 2500 Traps. En las pruebas realizadas se ve la importancia de utilizar switches con contraposición a los concentradores. La característica principal de los switches es la de separar las máquinas o subredes en dominios de colisión. La idea de los dominios de colisión es separar el tráfico entre cada uno de ellos. Es decir que en un dominio de colisión no se va a ver ningún tráfico proveniente de otros dominios, disminuyendo la cantidad de tráfico que va a estar fluyendo hacia otras máquinas o subredes. Caso que se ve perfectamente ilustrado en las Figuras 31 (a) y 33 (b) donde no se ve el tráfico que se genera en los otros dominios y es por esto que no se pudo medir y fue necesario la utilización de un concentrador. De aquí surge la importancia de utilizar los switches antes de los concentradores.

96

7 CONCLUSIONES El modelo de seguridad propuesto puede ser utilizado sin importar el costo de las herramientas de gestión de red (ya que soporta cualquier herramienta para la integración con la consola de seguridad), que soportan SNMP o de las herramientas de seguridad, que lo verdaderamente importante es que utilicen logs legibles para poder ser interpretados por los adaptadores. La unificación de la gestión de red y de seguridad es posible mediante la utilización del protocolo de aplicación SNMP, que, mediante la versión 3 se garantiza confidencialidad, autenticación, encripción e integridad en las notificaciones que hagan los agentes de seguridad. La Figura 36 muestra la respuesta de un mensaje SNMPv3 de tipo Get. Como se puede observar, todos los campos correspondientes al OID, valor y otros campos adicionales, se encuentran encriptados lo que garantiza la confidencialidad de las notificaciones que envían los agentes. Bajo este hecho se logra consolidar un modelo que permite plantear la integración de la gestión de red y de la seguridad de la red de una manera muy segura y que va a permitir facilitar la administración de los recursos de red, en ambos niveles, sean elementos de gestión o de seguridad. Los patrones de ataques identifican que un atacante normalmente accede una serie de máquinas hasta llegar a la víctima, en donde puede tratar de violentar el sistema mediante la explotación de alguna vulnerabilidad del sistema operativo o de alguna aplicación que se esté ejecutando en el equipo. En este caso es de suma importancia poder detectar de una manera centralizada el patrón que está siguiendo un atacante en nuestra red para ganar acceso a un equipo. Esto se puede realizar de una manera muy simple mirando los logs de cada una de las herramientas de seguridad y/o sistemas operativos de las máquinas o elementos de red utilizados, procedimiento arduo y que consume mucho tiempo del administrador de la red, tiempo que podría ser utilizado en otras actividades. Mediante la utilización de un modelo de seguridad como el propuesto, es posible hacer que el proceso de consolidación y auditoria de logs sea mucho más sencillo y a tiempo, ya que estamos centralizando en la consola de seguridad todas las notificaciones que se reciben de los adaptadores, o sea, de las herramientas que estamos monitoreando. Disminuyendo drásticamente el tiempo de respuesta ante un incidente distribuido en toda la red monitoreada. Adicionalmente se provee la utilización de procedimientos en los incidentes de seguridad y eventos que permiten detallar exactamente lo sucedido y la acción tomada para su solución. Se permite guardar un histórico de los hechos que han acontecido en la red, mediante los incidentes de cada una de las máquinas.

97

El uso de los incidentes y eventos le da al modelo una riqueza mayor. A partir de la secuencia de eventos se pueden construir herramientas que analicen esos datos y detecten en ellos nuevos patrones de ataques y hasta nuevas firmas que podrían llegar a servirle a un IDS. Los incidentes y eventos le trae a la empresa un valor agregado que le permite hacerle un seguimiento a los eventos y ver que fue lo que pasó, facilitando procesos de auditorías e inclusive procesos de análisis forense. Adicionalmente, los procedimientos para la solución de los eventos se pueden utilizar para la creación de documentos que pueden servirle a la empresa como capacitación, entrenamiento o documentación a los nuevos empleados. Se puede minimizar el tiempo de respuesta frente a un nuevo incidente, ya que se cuenta con una base de datos de incidentes anteriores que pueden confrontarse para llegar a la solución del nuevo incidente. Para que este modelo sea más efectivo los proveedores de las herramientas de seguridad deben poner en los logs la mayor cantidad de información de un evento para que su aporte sea aún más y permita notificar más información relevante de cada hecho. Con el fin de alcanzar este objetivo, es importante tender a una estandarización de los logs, de tal forma que todos los desarrolladores de herramientas de seguridad tiendan a utilizar este estándar y así facilitar la integración de las herramientas de seguridad. También deben proveer en el log un campo de procesado para poder identificar los registros en el log que fueron procesados por el agente y cuales no, para que se pueda garantizar que no se pierda ningún registro o ninguna notificación de un evento importante. Es bien importante que los desarrolladores de las herramientas de seguridad incluyan otros medios de notificación como por ejemplo vía correo, mandando un mensaje a un celular o una PDA, etc. adicionales a las alertas generadas en el entorno de ella misma o inclusive al log mismo, para notificar cualquier evento de seguridad detectado. Se recomienda adicionar a la aplicación desarrollada un agente SNMP que genere alertas vía este protocolo para que de esta forma se pueda integrar con mayor facilidad la gestión de red y de seguridad, seguramente, sin la necesidad de una consola de seguridad. Para lograr esto es necesario guiarse por algún estándar de manera que junto con los otros desarrolladores se cierre con mayor facilidad la brecha entre la gestión de red y seguridad.

98

Figura 36. Estructura de un mensaje SNMPv3

99

8 CONTINUIDAD DEL PROYECTO

8.1 POSIBLES TRABAJOS FUTUROS

1. Plantear un estándar para que la generación de logs se aplique a las herramientas, mediante la utilización de estándares como el de Syslog. Una idea puede ser la de utilizar el formato propuesto por Syslog y definir los campos importantes que pueden ir en el mensaje. Es importante mencionar los separadores de campos y los identificadores de campos, que permiten identificar el campo y su valor.

2. Plantear y crear nuestra arquitectura como una librería a incluir dentro de otro

desarrollo para que nuestra arquitectura sirva de plataforma para proyectos futuros y así puedan utilizarla independiente de nuestra implementación. De esta forma nuestra arquitectura puede ser una capa más en otra arquitectura.

3. Mediante la integración de los logs, poder hacerle un seguimiento cronológico

a un atacante que accede a una serie de máquinas hasta ingresar a su objetivo y determinar su patrón de ataque.

4. Poner un tipo de inteligencia en los agentes de seguridad para que puedan

tomar decisiones sobre lo que notifican y lo que no es necesario notificar de los logs de cada una de las herramientas de seguridad. De acuerdo a si es tráfico normal en la red o si es un rastro o una firma de un ataque.

5. A partir de los datos almacenados en la base de datos, se puede construir una

herramienta que analice estos datos y detecte patrones de ataques. Una herramienta que de alguna manera analice los incidentes de seguridad almacenados y sepa detectar lo que quieren decir. Esto debe ser un análisis con base en las herramientas de seguridad y debe ser capaz de tomar decisiones sobre lo que analiza.

6. Implementar un método de filtrado de mensajes en la consola de seguridad

para evitar que se guarden en los incidentes mensajes de tipos de tráficos similares a los ya existentes, para evitar que se vean eventos iguales y que la base de datos se sature de información duplicada, pero que quede registrado que ha habido eventos subsiguientes. Por ejemplo bajo un ataque DoS.

7. Crear una herramienta que haga el análisis de datos para determinar

estadísticas de ataques. Como por ejemplo la máquina que más ha sido

100

infectada con virus, los virus más abundantes en la red, tipos de ataques que ha recibido una máquina, usuarios más peligrosos, entre otras estadísticas.

8. Desarrollar un mecanismo para manejar la distribución de la carga en varios

puntos de procesamiento de la información que necesita la consola de seguridad. De esta forma se puede mejorar el rendimiento y el soporte de más adaptadores del modelo propuesto.

101

BIBLIOGRAFIA [1] “La proactividad: clave de la gestión de red”, disponible en: http://www.redestelecom.com/Actualidad/An%C3%A1lisis/Comunicaciones/Telefon%C3%ADa/20030731011 [2] Herráez, Mª Blanca. “Introducción a los sistemas de gestión de red”, disponible en: http://www.info-ab.uclm.es/asignaturas/42621/transpas/dmrTema1x1.pdf [3] Mª Blanca Herráez. “Herramientas de gestión de red”, disponible en: http://www.info-ab.uclm.es/asignaturas/42621/transpas/dmrTema6x2.pdf [4] Northcutt, Stephen. “Guía avanzada: Detección de intrusos”, 2ª edición, Madrid, 2001. [5] Zielger, Robert L. “Guía avanzada: Firewalls Linux”, 1ª edición, Madrid, 2000. [6] “GFI: Intrusion Detection software”, disponible en: http://www.gfi.com/lanselm/ [7] Terplan, Kornel. Communication Networks Management, Prentice Hall, New Jersey, 1992. [8] Baiba Marti, Antoni. Gestión de red, Edicions OPC, Universita Politècnica de Catalunya, España, 2001 [9] SNMP Tutorial Series: 5 Quick Steps to Understanding SNMP and its Role in Network Alarm Monitoring, tomado de http://www.dpstele.com/layers/l2/snmp_tutorials.html [10] Stallings, William. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3ª edición, Addison Wesley, 1999. [11] Perkins, David T. Understanding SNMP MIBs, 1993 [12] How to Eliminate Spyware to Protect Your Business, disponible en: http://ca.com/smb/howcani/eliminate_spyware.pdf [13] Information Security 101: Security for Newbies, disponible en: http://www.sans.org/rr/whitepapers/basics/444.php [14] GIAC Security Essentials Certifications (GSEC) Practical Assignment, disponible en: http://www.sans.org/rr/whitepapers/basics/1071.php

102

[15] Protecting the Network without Breaking the Bank, disponible en: http://www.sans.org/rr/whitepapers/firewalls/809.php [16] Security in Practice- Reducing the Effort, disponible en: http://www.sans.org/rr/whitepapers/bestprac/1106.php [17] Threats to Enterprise Security, disponible en: http://www.securitydocs.com/library/3211 [18] Spyware and Adware – Threats and Countermeasures, disponible en: http://www.finjan.com/company/whitepapers/Spyware_White_Paper.pdf [19] Especificado en la recomendación X.690 y X.691 de la ITU-T [20] RFC 2271 - An Architecture for Describing SNMP Management Frameworks, disponible en: http://www.ietf.org/rfc/rfc2271.txt [21] RFC 3164 - The BSD syslog Protocol, disponible en: http://www.ietf.org/rfc/rfc3164.txt

103

ANEXO 1: TÉRMINOS DE LICENCIAMIENTO Various copyrights apply to this package, listed in various separate parts below. Please make sure that you read all the parts. Up until 2001, the project was based at UC Davis, and the first part covers all code written during this time. From 2001 onwards, the project has been based at SourceForge, and Networks Associates Technology, Inc hold the copyright on behalf of the wider Net-SNMP community, covering all derivative work done since then. An additional copyright section has been added as Part 3 below also under a BSD license for the work contributed by Cambridge Broadband Ltd. to the project since 2001. An additional copyright section has been added as Part 4 below also under a BSD license for the work contributed by Sun Microsystems, Inc. to the project since 2003. Code has been contributed to this project by many people over the years it has been in development, and a full list of contributors can be found in the README file under the THANKS section. ---- Part 1: CMU/UCD copyright notice: (BSD like) ----- Copyright 1989, 1991, 1992 by Carnegie Mellon University Derivative Work - 1996, 1998-2000 Copyright 1996, 1998-2000 The Regents of the University of California All Rights Reserved Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU and The Regents of the University of California not be used in advertising or publicity pertaining to distribution of the software without specific written permission. CMU AND THE REGENTS OF THE UNIVERSITY OF CALIFORNIA DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL CMU OR

104

THE REGENTS OF THE UNIVERSITY OF CALIFORNIA BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM THE LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ---- Part 2: Networks Associates Technology, Inc copyright notice (BSD) ----- Copyright (c) 2001-2003, Networks Associates Technology, Inc All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the Networks Associates Technology, Inc nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF

105

ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ---- Part 3: Cambridge Broadband Ltd. copyright notice (BSD) ----- Portions of this code are copyright (c) 2001-2003, Cambridge Broadband Ltd. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * The name of Cambridge Broadband Ltd. may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ---- Part 4: Sun Microsystems, Inc. copyright notice (BSD) ----- Copyright © 2003 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. Use is subject to license terms below. This distribution may include materials developed by third parties.

106

Sun, Sun Microsystems, the Sun logo and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of the Sun Microsystems, Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ---- Part 5: Sparta, Inc copyright notice (BSD) ----- Copyright (c) 2003-2004, Sparta, Inc All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

107

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Sparta, Inc nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ---- Part 6: Cisco/BUPTNIC copyright notice (BSD) ----- Copyright (c) 2004, Cisco, Inc and Information Network Center of Beijing University of Posts and Telecommunications. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

108

* Neither the name of Cisco, Inc, Beijing University of Posts and Telecommunications, nor the names of their contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

109

ANEXO 2: ESTRUCTURA DE UNA MIB APPLICATION-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString FROM RFC1213-MIB MODULE-IDENTITY, OBJECT-TYPE, enterprises FROM SNMPv2-SMI; modSeg MODULE-IDENTITY LAST-UPDATED "0502031400Z" ORGANIZATION "Proyecto de Investigación" CONTACT-INFO " Nicolás Botero A. Director: Enrique Ruiz. Pontificia Universidad Javeriana Ingeniería de sistemas e-mail: nbotero@javeriana.edu.co" DESCRIPTION "Modulo MIB que contendra las MIB's de las herramientas a monitorear." REVISION "0502031400Z" DESCRIPTION "Definición de la estructura en el árbol." ::= { modSegSNMP 3 } modSegSNMP OBJECT IDENTIFIER ::= { enterprises 1 } agente OBJECT IDENTIFIER ::= { modSegSNMP 1 } consola OBJECT IDENTIFIER ::= { modSegSNMP 2 } END KERIO-MIB DEFINITIONS ::= BEGIN IMPORTS DisplayString FROM RFC1213-MIB MODULE-IDENTITY, OBJECT-TYPE, enterprises FROM SNMPv2-SMI agente FROM APPLICATION-MIB; modSeg MODULE-IDENTITY LAST-UPDATED "0502031400Z" ORGANIZATION "Proyecto de Investigación" CONTACT-INFO " Nicolás Botero A. Pontificia Universidad Javeriana Ingeniería de sistemas e-mail: nbotero@javeriana.edu.co" DESCRIPTION "Modulo MIB para monitorear el IDS de la aplicación Kerio." REVISION "0502031400Z" DESCRIPTION "Implementación de los objetos que se van a monitorear de la aplicación Kerio." ::= { enterprises 1 }

110

kerio OBJECT IDENTIFIER ::= { agente 1 } kDate OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "La fecha del registro en el log de la aplicación." ::= { kerio 1 } kTime OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "La hora del registro en el log de la aplicación." ::= { kerio 2 } kHost OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "El nombre del equipo en donde se está ejecutando la aplicación." ::= { kerio 3 } kActionTaken OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "La acción que tomó la aplicación cuando sucedió el evento registrado en el log." ::= { kerio 4 } kRemoteAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Dirección remota desde donde se originó el evento registrado en el log." ::= { kerio 5 } kMessage OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Mensaje que describe cual fue el evento ocurrido en la aplicación." ::= { kerio 6 } kDirection OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Dirección que tuvo el evento registrado en el log. Puede ser originada hacia el equipo o desde el equipo." ::= { kerio 7 } kClassification OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION

111

"La clasificación que le asignó la aplicación al evento ocurrido. Es el nombre bajo el que se clasificó el evento. Normalmente y según el tipo de ataque, se puede clasificar en determinadas categorías." ::= { kerio 8 } kPriority OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "La prioridad (importancia o relevancia) que le asignó la palicación al evento." ::= { kerio 9 } kStateOfInterface OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DEFVAL { 1 } DESCRIPTION "El estado en el que se encuentra la interface que conecta el equipo a la red. Arriba (1) y abajo (0)." ::= { kerio 10 } END

112

ANEXO 3: IMPLEMENTACIÓN DE UNA MIB #include <net-snmp/net-snmp-config.h> #include <net-snmp/net-snmp-includes.h> #include <net-snmp/agent/net-snmp-agent-includes.h> #include "kerio.h" #include "kerioLogAnalyzer.h" static char *data_kDate=""; static char *data_kTime=""; static char *data_kHost=""; static char *data_kActionTaken=""; static char *data_kRemoteAddress=""; static char *data_kMessage=""; static char *data_kDirection=""; static char *data_kClassification=""; static char *data_kPriority=""; static int data_kStateOfInterface=1; #define SYS_STRING_LEN 256 char version_descr1[SYS_STRING_LEN] = VERS_DESC; char sysName1[SYS_STRING_LEN] = SYS_NAME; void init_kerio(void) { static oid kDate_oid[] = { 1,3,6,1,4,1,1,1,1,1 }; static oid kTime_oid[] = { 1,3,6,1,4,1,1,1,1,2 }; static oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3 }; static oid kActionTaken_oid[] = { 1,3,6,1,4,1,1,1,1,4 }; static oid kRemoteAddress_oid[] = { 1,3,6,1,4,1,1,1,1,5 }; static oid kMessage_oid[] = { 1,3,6,1,4,1,1,1,1,6 }; static oid kDirection_oid[] = { 1,3,6,1,4,1,1,1,1,7 }; static oid kClassification_oid[] = { 1,3,6,1,4,1,1,1,1,8 }; static oid kPriority_oid[] = { 1,3,6,1,4,1,1,1,1,9 }; static oid kStateOfInterface_oid[] = { 1,3,6,1,4,1,1,1,1,10,0 }; data_kDate=(char *)malloc(sizeof(char *) + 1); data_kTime=(char *)malloc(sizeof(char *) + 1); data_kHost=(char *)malloc(sizeof(char *) + 1); data_kActionTaken=(char *)malloc(sizeof(char *) + 1); data_kRemoteAddress=(char *)malloc(sizeof(char *) + 1); data_kMessage=(char *)malloc(sizeof(char *) + 1); data_kDirection=(char *)malloc(sizeof(char *) + 1); data_kClassification=(char *)malloc(sizeof(char *) + 1); data_kPriority=(char *)malloc(sizeof(char *) + 1); readFileK(); #ifdef HAVE_UNAME struct utsname utsName; uname(&utsName); snprintf(version_descr1, sizeof(version_descr1), "%s %s %s %s %s", utsName.sysname, utsName.nodename, utsName.release, utsName.version, utsName.machine); version_descr1[ sizeof(version_descr1)-1 ] = 0; #else #if HAVE_EXECV struct extensible extmp; sprintf(extmp.command, "%s -a", UNAMEPROG); extmp.type = EXECPROC; extmp.next = NULL;

113

exec_command(&extmp); strncpy(version_descr1, extmp.output, sizeof(version_descr1)); version_descr1[sizeof(version_descr1) - 1] = 0; version_descr1[strlen(version_descr1) - 1] = 0; #else #endif #endif #ifdef HAVE_GETHOSTNAME gethostname(sysName1, sizeof(sysName1)); #else #ifdef HAVE_UNAME strncpy(sysName1, utsName.nodename, sizeof(sysName1)); #else #if HAVE_EXECV sprintf(extmp.command, "%s -n", UNAMEPROG); extmp.type = EXECPROC; extmp.next = NULL; exec_command(&extmp); strncpy(sysName1, extmp.output, sizeof(sysName1)); sysName1[strlen(sysName1) - 1] = 0; #else strcpy(sysName1, "unknown"); #endif /* HAVE_EXECV */ #endif /* HAVE_UNAME */ #endif /* HAVE_GETHOSTNAME */ strcpy(data_kHost,sysName1); DEBUGMSGTL(("kerio", "Initializing\n")); netsnmp_register_scalar( netsnmp_create_handler_registration("kDate", handle_kDate, kDate_oid, OID_LENGTH(kDate_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kTime", handle_kTime, kTime_oid, OID_LENGTH(kTime_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kHost", handle_kHost, kHost_oid, OID_LENGTH(kHost_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kActionTaken", handle_kActionTaken, kActionTaken_oid, OID_LENGTH(kActionTaken_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kRemoteAddress", handle_kRemoteAddress, kRemoteAddress_oid, OID_LENGTH(kRemoteAddress_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kMessage", handle_kMessage, kMessage_oid, OID_LENGTH(kMessage_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kDirection", handle_kDirection, kDirection_oid, OID_LENGTH(kDirection_oid), HANDLER_CAN_RONLY )); netsnmp_register_scalar( netsnmp_create_handler_registration("kClassification", handle_kClassification, kClassification_oid, OID_LENGTH(kClassification_oid), HANDLER_CAN_RONLY ));

114

netsnmp_register_scalar( netsnmp_create_handler_registration("kPriority", handle_kPriority, kPriority_oid, OID_LENGTH(kPriority_oid), HANDLER_CAN_RONLY )); netsnmp_register_int_instance("kStateOfInterface", kStateOfInterface_oid, OID_LENGTH(kStateOfInterface_oid), &data_kStateOfInterface, handle_kStateOfInterface); snmp_alarm_register(5, SA_REPEAT, call_log_analyzer_kerio, NULL ); snmp_alarm_register(60, SA_REPEAT, call_no_news_kerio, NULL ); snmp_alarm_register(1, 0, call_startup_kerio, NULL ); } int handle_kDate(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kDate, strlen(data_kDate)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kDate\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kTime(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kTime, strlen(data_kTime)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kTime\n", reqinfo->mode );

115

return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kHost(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kHost, strlen(data_kHost)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kHost\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kActionTaken(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kActionTaken, strlen(data_kActionTaken)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kActionTaken\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kRemoteAddress(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kRemoteAddress, strlen(data_kRemoteAddress)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kRemoteAddress\n", reqinfo->mode ); return SNMP_ERR_GENERR; }

116

return SNMP_ERR_NOERROR; } int handle_kMessage(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kMessage, strlen(data_kMessage)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kMessage\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kDirection(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kDirection, strlen(data_kDirection)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kDirection\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kClassification(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kClassification, strlen(data_kClassification)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kClassification\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; }

117

int handle_kPriority(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { switch(reqinfo->mode) { case MODE_GET: snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR, (u_char *) data_kPriority, strlen(data_kPriority)); break; default: snmp_log(LOG_ERR, "unknown mode (%d) in handle_kPriority\n", reqinfo->mode ); return SNMP_ERR_GENERR; } return SNMP_ERR_NOERROR; } int handle_kStateOfInterface(netsnmp_mib_handler *handler, netsnmp_handler_registration *reginfo, netsnmp_agent_request_info *reqinfo, netsnmp_request_info *requests) { if(reqinfo->mode==MODE_GET) { snmp_set_var_typed_value(requests->requestvb, ASN_INTEGER, (u_char *) &data_kStateOfInterface, sizeof(data_kStateOfInterface)); } if(reqinfo->mode==MODE_SET_ACTION) { if(data_kStateOfInterface==0) { printf("Bring down interface"); system("ipconfig /release"); } } return SNMP_ERR_NOERROR; } void call_log_analyzer_kerio(unsigned int clientreg, void *clientarg) { struct kerioIds *data; int i=0; data=(struct kerioIds *) calloc(1, sizeof(struct kerioIds)); data->rdate=(struct CDate *) calloc(1, sizeof(struct CDate)); strcpy(data->action,"a"); data=readAllK(); if(strcmp(data->action,"")!=0) { strcpy(data_kDate,data->rdate->date); strcpy(data_kTime,data->rdate->time); strcpy(data_kActionTaken,data->action); strcpy(data_kRemoteAddress,data->raddr); strcpy(data_kMessage,data->msg); strcpy(data_kDirection,data->direc); strcpy(data_kClassification,data->class1); data->priority[strlen(data->priority)-1]='\0'; strcpy(data_kPriority,data->priority);

118

send_kNotifyTrap_trap(); } } void call_no_news_kerio(unsigned int clientreg, void *clientarg) { char name[SYS_STRING_LEN] = SYS_NAME; char *tmp_kDate="99/Dec/9999"; netsnmp_variable_list *var_list = NULL; oid kNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,1,11,1 }; size_t kNotifyTrap_oid_len = OID_LENGTH(kNotifyTrap_oid); oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 }; size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap); oid kDate_oid[] = { 1,3,6,1,4,11,1,1,1,0 }; size_t kDate_oid_len = OID_LENGTH(kDate_oid); oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3,0 }; size_t kHost_oid_len = OID_LENGTH(kHost_oid); gethostname(name, sizeof(name)); snmp_varlist_add_variable(&var_list, objid_snmptrap, objid_snmptrap_len, ASN_OBJECT_ID, (u_char *) kNotifyTrap_oid, kNotifyTrap_oid_len * sizeof(oid)); snmp_varlist_add_variable(&var_list, kDate_oid, kDate_oid_len, ASN_OCTET_STR, tmp_kDate, strlen(tmp_kDate)); snmp_varlist_add_variable(&var_list, kHost_oid, kHost_oid_len, ASN_OCTET_STR, name, strlen(name)); send_v2trap( var_list ); snmp_free_varbind( var_list ); } void call_startup_kerio(unsigned int clientreg, void *clientarg) { char name[SYS_STRING_LEN] = SYS_NAME; char *tmp_kDate="STARTUP"; netsnmp_variable_list *var_list = NULL; oid kNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,1,11,1 }; size_t kNotifyTrap_oid_len = OID_LENGTH(kNotifyTrap_oid); oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 }; size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap); oid kDate_oid[] = { 1,3,6,1,4,11,1,1,1,0 }; size_t kDate_oid_len = OID_LENGTH(kDate_oid); oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3,0 }; size_t kHost_oid_len = OID_LENGTH(kHost_oid); gethostname(name, sizeof(name)); snmp_varlist_add_variable(&var_list, objid_snmptrap, objid_snmptrap_len, ASN_OBJECT_ID, (u_char *) kNotifyTrap_oid, kNotifyTrap_oid_len * sizeof(oid));

119

snmp_varlist_add_variable(&var_list, kDate_oid, kDate_oid_len, ASN_OCTET_STR, tmp_kDate, strlen(tmp_kDate)); snmp_varlist_add_variable(&var_list, kHost_oid, kHost_oid_len, ASN_OCTET_STR, name, strlen(name)); send_v2trap( var_list ); snmp_free_varbind( var_list ); } int send_kNotifyTrap_trap( void ) { char *name="Kerio Personal Firewall"; char *type="IDS"; char *version="4.1"; netsnmp_variable_list *var_list = NULL; oid kNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,1,11,1 }; size_t kNotifyTrap_oid_len = OID_LENGTH(kNotifyTrap_oid); oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 }; size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap); oid kDate_oid[] = { 1,3,6,1,4,11,1,1,1,0 }; size_t kDate_oid_len = OID_LENGTH(kDate_oid); oid kTime_oid[] = { 1,3,6,1,4,1,1,1,1,2,0 }; size_t kTime_oid_len = OID_LENGTH(kTime_oid); oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3,0 }; size_t kHost_oid_len = OID_LENGTH(kHost_oid); oid kActionTaken_oid[] = { 1,3,6,1,4,1,1,1,1,4,0 }; size_t kActionTaken_oid_len = OID_LENGTH(kActionTaken_oid); oid kRemoteAddress_oid[] = { 1,3,6,1,4,1,1,1,1,5,0 }; size_t kRemoteAddress_oid_len = OID_LENGTH(kRemoteAddress_oid); oid kMessage_oid[] = { 1,3,6,1,4,1,1,1,1,6,0 }; size_t kMessage_oid_len = OID_LENGTH(kMessage_oid); oid kDirection_oid[] = { 1,3,6,1,4,1,1,1,1,7,0 }; size_t kDirection_oid_len = OID_LENGTH(kDirection_oid); oid kClassification_oid[] = { 1,3,6,1,4,1,1,1,1,8,0 }; size_t kClassification_oid_len = OID_LENGTH(kClassification_oid); oid kPriority_oid[] = { 1,3,6,1,4,1,1,1,1,9,0 }; size_t kPriority_oid_len = OID_LENGTH(kPriority_oid); oid kStateOfInterface_oid[] = { 1,3,6,1,4,1,1,1,1,10,0 }; size_t kStateOfInterface_oid_len = OID_LENGTH(kStateOfInterface_oid); oid kToolName_oid[] = { 1,3,6,1,4,1,1,1,1,12,0 }; size_t kToolName_oid_len = OID_LENGTH(kToolName_oid); oid kToolType_oid[] = { 1,3,6,1,4,1,1,1,1,13,0 }; size_t kToolType_oid_len = OID_LENGTH(kToolType_oid); oid kToolVersion_oid[] = { 1,3,6,1,4,1,1,1,1,14,0 }; size_t kToolVersion_oid_len = OID_LENGTH(kToolVersion_oid); snmp_varlist_add_variable(&var_list, objid_snmptrap, objid_snmptrap_len,

120

ASN_OBJECT_ID, (u_char *) kNotifyTrap_oid, kNotifyTrap_oid_len * sizeof(oid)); snmp_varlist_add_variable(&var_list, kDate_oid, kDate_oid_len, ASN_OCTET_STR, data_kDate, strlen(data_kDate)); snmp_varlist_add_variable(&var_list, kTime_oid, kTime_oid_len, ASN_OCTET_STR, data_kTime, strlen(data_kTime)); snmp_varlist_add_variable(&var_list, kHost_oid, kHost_oid_len, ASN_OCTET_STR, data_kHost, strlen(data_kHost)); snmp_varlist_add_variable(&var_list, kToolName_oid, kToolName_oid_len, ASN_OCTET_STR, name, strlen(name)); snmp_varlist_add_variable(&var_list, kToolType_oid, kToolType_oid_len, ASN_OCTET_STR, type, strlen(type)); snmp_varlist_add_variable(&var_list, kToolVersion_oid, kToolVersion_oid_len, ASN_OCTET_STR, version, strlen(version)); snmp_varlist_add_variable(&var_list, kActionTaken_oid, kActionTaken_oid_len, ASN_OCTET_STR, data_kActionTaken, strlen(data_kActionTaken)); snmp_varlist_add_variable(&var_list, kRemoteAddress_oid, kRemoteAddress_oid_len, ASN_OCTET_STR, data_kRemoteAddress, strlen(data_kRemoteAddress)); snmp_varlist_add_variable(&var_list, kMessage_oid, kMessage_oid_len, ASN_OCTET_STR, data_kMessage, strlen(data_kMessage)); snmp_varlist_add_variable(&var_list, kDirection_oid, kDirection_oid_len, ASN_OCTET_STR, data_kDirection, strlen(data_kDirection)); snmp_varlist_add_variable(&var_list, kClassification_oid, kClassification_oid_len, ASN_OCTET_STR, data_kClassification, strlen(data_kClassification)); snmp_varlist_add_variable(&var_list, kPriority_oid, kPriority_oid_len, ASN_OCTET_STR, data_kPriority, strlen(data_kPriority)); snmp_varlist_add_variable(&var_list, kStateOfInterface_oid, kStateOfInterface_oid_len, ASN_INTEGER, (u_char *)&data_kStateOfInterface, sizeof(data_kStateOfInterface));

121

send_v2trap( var_list ); snmp_free_varbind( var_list ); return SNMP_ERR_NOERROR; }

122

ANEXO 4: MANUAL DEL USUARIO Referirse al Anexo 7 para la instalación de los adaptadores y la ejecución de la consola de seguridad. 1. CONSOLA DE SEGURIDAD La consola de seguridad no requiere de ningún proceso de instalación. Para ejecutar la consola de seguridad solo basta con hacer dos cosas: primero editar el archivo ConfigurationParameters.properties que se encuentra en la raíz de la carpeta <ruta>\consola en donde se debe colocar la dirección del servidor MySQL y del servidor SMTP; segundo ejecutar el archivo run.bat que sube la aplicación. Luego de ejecutar la aplicación aparece la imagen de la Figura 1 que indica que se está cargando la aplicación.

Figura 1

123

Una vez termina de cargarse la aplicación aparece la siguiente pantalla en donde el usuario debe validarse frente al sistema e ingresar su usuario y contraseña como lo indica la Figura 2.

Figura 2

Una vez ingresado el usuario y la contraseña, se procede a darle clic en el botón login. Proceso que permite ingresar a la aplicación y ver la pantalla principal del programa. Por defecto existe un usuario para ingresar a la aplicación, cuyo nombre de usuario es modseg y su contraseña es modseg.

124

Figura 3

En la Figura 3 se muestra la pantalla principal de la consola de seguridad. En el área (a) aparecen las máquinas que se están monitoreando (las cuales se pueden arrastrar y colocar en el sitio deseado, para agruparlas según la subred a la que pertenecen). Cuando se da clic a una de las máquinas se muestran los incidentes de seguridad activos, representados en el área (b) y si se hace clic a uno de los incidentes activos nos despliega en el área (c) los eventos asociados a ese incidente. Si se deja el cursor encima de la máquina se pude apreciar su dirección IP. Las máquinas aparecen en color azul si el adaptador de esa máquina está en ejecución y enviando mensajes correctamente. Si por algún motivo la consola de seguridad deja de recibir mensajes de ese adaptador la aplicación cambia la máquina a color blanco indicando que el adaptador no está reportando mensajes a la consola de seguridad. Cuando el adaptador de una máquina está detectando incidentes de seguridad y se encuentra enviando los Traps a la consola de seguridad, se va a observar que la máquina generando las notificaciones intermitirá entre rojo y azul. Una máquina que ha tenido sucesos de seguridad aparece en color naranja en la consola y una vez se hace clic en esa máquina cambia a color azul, proceso que indica que se han analizado los eventos, ya que ha habido nuevos eventos que se han recibido. En la Figura 4

(a) área de máquinas

(b) área de incidentes de seguridad

(c) área de eventos

125

aparecen dos máquinas siendo monitoreadas y una de ellas tiene un incidente abierto con un evento asociado.

Figura 4

Si se desean ver los detalles de uno de los eventos debemos hacer clic en la columna que dice datos del evento y se despliegan los datos como se muestra en la Figura 5.

126

Figura 5

La Figura 5, permite observar los datos específicos de un evento. Se puede ver el programa que lo originó, la acción tomada, entre otros campos adicionales. Se puede navegar entre los otros eventos de ese incidente mediante los botones siguiente y atrás o cerrar la ventana con su respectivo botón. En la lista de incidentes de seguridad y en la de eventos es posible cambiar los siguientes campos: fecha de cierre, procedimiento y estado. El campo estado sirve para indicar el estado en el que se encuentra el evento o incidente, que puede ser activo, cerrado o descartado (el primero indica que está abierto y el segundo que ha sido solucionado). El último estado sirve para informar que el administrador luego de haber analizado el incidente o el evento determinó que puede ser descartado ya que no corresponde a un incidente de seguridad. Cuando el estado se pone en cerrado se recomienda llenar la fecha de cierre y el procedimiento asociado a la solución de dicho evento o incidente.

Datos del evento

Navegar entre eventos

127

En la barra de menú aparecen tres categorías que corresponden a archivo, insertar y ayuda. En la barra de menú archivo podemos apreciar las opciones que se muestran en la Figura 6.

Figura 6

La primera permite editar los parámetros para enviar y recibir Traps v3.

Figura 7

En la Figura 7 se pueden editar los parámetros necesarios para recibir Traps y se puede editar el usuario, la clave MD5 y DES a utilizar y el puerto en el cual se van a escuchar los Traps que provienen de los adaptadores. En la Figura 8 se muestran los parámetros de los Traps que se van a enviar a una consola de gestión. Estos son el usuario, las claves MD5 y DES, la dirección IP de la máquina que tiene la consola de gestión y el puerto por el cual va a escuchar esa consola los Traps enviados por la consola de seguridad. Para cambiar los valores de cada uno de los Traps basta con modificar los campos necesarios y darle clic en ingresar.

128

Figura 8

La siguiente opción en el menú nos permite administrar los usuarios que van a acceder a la aplicación como se muestra en la Figura 9.

129

Figura 9

Para adicionar un usuario basta con llenar sus datos: nombre, apellido, login, contraseña, el rol (que puede ser un usuario o administrador), el cargo, la dirección de correo y por último el nivel que ocupa en la empresa (donde el nivel 1 corresponde al nivel más bajo que puede ocupar el empleado). El rol de “Usuario” está destinado únicamente a los usuarios que van a utilizar el programa vía Web, mientras que el “Administrador” es el usuario que va a ingresar a esta aplicación. Para ingresar el usuario basta con hacer clic en ingresar. También se puede editar la clave de un usuario ya creado como se muestra en la Figura 10, donde se presenta la opción de borrar el usuario seleccionado haciendo clic en el botón borrar o cambiar la clave de un usuario ingresando la nueva clave y haciendo clic en ingresar.

130

Figura 10

En el menú insertar, como se muestra en la Figura 11, se presenta la opción de insertar un texto en el área de máquinas para identificar y agrupar las máquinas gráficamente por subredes u otro criterio deseado.

Figura 11

131

Figura 12

La Figura 12 muestra la pantalla para ingresar la etiqueta. Para ingresarla basta con escribir el texto deseado y hacer clic en insertar, luego se debe hacer un clic en el área de las máquinas para que aparezca la etiqueta. Esta etiqueta se puede arrastrar y poner en el sitio deseado. De esta forma se pueden agrupar las máquinas como se muestra en la Figura 13. Adicionalmente si se hace clic derecho sobre una etiqueta aparece la opción de borrar la etiqueta deseada.

Figura 13

El menú ayuda, como se ve en la Figura 14, permite obtener información de contacto de la aplicación como se muestra en la Figura 15.

Figura 14

132

Figura 15

2. PÁGINA WEB Para aquellos usuarios que desean conocer información acerca de los incidentes de seguridad y/o eventos se les da la opción de ingresar a una página Web donde pueden consultar dicha información. Pueden ser los usuarios a los que les llega una notificación de la consola de seguridad, como un correo, informando que se ha vencido el plazo de solucionar un incidente. La primera página se encarga de validar al usuario frente al sistema como se observa en la Figura 16. El usuario solo va a ver información de los incidentes y eventos y no puede modificar ningún dato mostrado, labor delegada a los administradores de red.

133

Figura 16

Se deben llenar el login del usuario y su contraseña y luego hacer clic en el botón login para validar el usuario. Por defecto hay un usuario con login pruusu y contraseña 1234567. Una vez validado se presentan siguientes opciones: consultar todos los incidentes abiertos o cerrados, consultar incidentes por rango de fecha y obtener los detalles de un incidente como lo indica la Figura 17.

134

Figura 17

Al hacer clic en el botón “consultar todos los incidentes abiertos y cerrados” aparece una lista de los incidentes abiertos y cerrados de todas las máquinas almacenadas en la base de datos (ver Figura 18).

135

Figura 18

En la opción de consultar incidentes por rango de fecha, se pueden ver los incidentes en un rango de fecha seleccionando la fecha de inicio y de fin, opción que se permite haciendo clic en el calendario al lado derecho de cada fecha y seleccionando la fecha deseada según la Figura 19. Luego se hace clic en consultar para que aparezca una lista de incidentes de seguridad en ese rango de fechas como se muestra en la Figura 20.

136

Figura 19

Selección de fecha

137

Figura 20

Por último, en la opción de seleccionar los detalles de un incidente de seguridad se pueden consultar todos los eventos que corresponden a ese incidente, ingresando el ID del incidente (ver Figura 21). Para consultar los detalles se da clic en consultar y a continuación se despliegan los detalles del incidente indicado como se observa en la Figura 22.

138

Figura 21

139

Figura 22

140

ANEXO 5: INSTALACIÓN DEL PROGRAMA NET-SNMP Para instalar el programa en Windows (Win32): Antes de instalar el programa se debe tener “Active Perl” instalado para el funcionamiento de todos los scripts de Perl que necesita el programa. Descargar el ejecutable de la página ejecutarlo y seguir las instrucciones que se indican allí. El programa por default se instala en “c:\usr” y ahí se encuentran los archivos relacionados con el programa. En la carpeta “bin”, se encuentran los ejecutables del programa. El agente que proveen ellos, se puede registrar como un servicio (ver los archivos registeragent.bat y unregisteragent.bat para registrar y quitar el servicio). Es recomendable correr el siguiente comando para generar el archivo de configuración para el agente: “snmpconf -g basic_setup”, el cual guía para la configuración del agente. El archivo queda en la carpeta “c:\usr” y se debe copiar a la carpeta “c:\usr\etc\snmp”, luego se debe reiniciar el servicio para que lea el archivo. Este archivo (“snmpd.conf”), permite configurar el comportamiento del agente. Se puede definir comunidades de escritura y/o lectura, definir usuarios para SNMPv3, entre muchas otras opciones. Aquí vamos a ver las más básicas (se asume que el lector ya ha ejecutado el comando mencionado anteriormente y el archivo ya se encuentra en su ubicación). Configurar una comunidad: el archivo debe incluir al menos una de las dos líneas siguientes para crear una comunidad y poder hacer operaciones según el tipo de comunidad definido:

rwcommunity <comunidad> rocommunity <comunidad>

donde <comunidad> es el nombre de la comunidad que queremos definir para un acceso de lectura y escritura (rwcommunity) o de solo lectura (rocommunity). De esta forma el agente puede responder a un comando generado con SNMPv1 y SNMPv2, que utilizan el concepto de comunidad. Veamos un ejemplo:

Definimos una comunidad de lectura y escritura, llamada “privada”: rwcommunity privada Que nos permite consultar y modificar valores de los objetos monitoreados. Luego, ya podríamos hacer la siguiente consulta al agente (utilizando el programa “snmpget”): snmpget -v 2c -c privada localhost system.sysName.0 Que nos retorna el nombre del sistema que estamos solicitando. En este caso nos retorna el nombre del sistema “localhost”. Adicionalmente, aquí estamos utilizando SNMPv2 (especificado por el comando “-v 2c”); la comunidad “privada” (especificada por el comando “-c privada”) y estamos solicitando la variable sysName que pertenece al grupo “system” (especificado por el

141

parámetro “system.sysName.0”; recordemos que el “.0” se refiere a una instancia en particular).

Para que funcione con soporte a encripción, es necesario indicarle al agente que use encripción. Se debe instalar una distribución de OpenSSL en la ruta C:\OpenSSL. Se debe copiar la carpeta openssl (C:\OpenSSL\include) a la carpeta de VC++ (C:\Program Files\Microsoft Visual Studio\VC98\include). También se debe copiar la librería libeay32.lib (C:\OpenSSL\lib\VC) a la carpeta de VC++ (C:\Program Files\Microsoft Visual Studio\VC98\lib). Luego se debe editar el archivo de encabezado net-snmp-config.h (<instalación del código>\win32\net-snmp) y añadir la siguiente línea para indicarle que use OpenSSL: #define USE_OPENSSL 1. A continuación es necesario abrir VC++ y abrir el proyecto win32.dsw. Seleccionar en la barra de menú Proyecto-> Configuración. Se deben seleccionar todos los proyectos excepto libsnmp, libagent, libhelpers, libnetsnmptrapd y netsnmpmibs. Luego en la opción de Enlace, se debe adicionar la librería libeay32.lib en la parte que dice objetos/librerías módulos. Esto se debe hacer tanto para las versiones “Debug” como “Release”. A partir de aquí lo único que queda por hacer es compilar de nuevo todas las aplicaciones. Se debe hacer de la siguiente manera: abrir el proyecto win32.dsw, en la opción del menú “Build” seleccionar “Batch Build”. En la lista que aparece, seleccionar si se desea la versión “release” y/o “debug” de los proyectos. Por último hay que darle “ReBuild All”. Los archivos ejecutables quedan en la carpeta “Release” o “Debug”, dependiendo de lo que se haya seleccionado en la lista (<carpeta de código fuente>\win32\bin) los cuales deben ser copiados a la carpeta C:\usr. Por otro lado, para utilizar SNMPv3 se debe incluir en el archivo un usuario del cual se quiere clonar los otros usuarios, como se encuentra especificado en el RFC. En el archivo deben encontrarse las siguientes líneas (los comentarios se hacen con el carácter #):

# se crea el usuario “initial” para lectura y escritura rwuser initial # ponemos el nuevo usuario que vamos a crear para lectura y escritura rwuser nuevo_usuario # damos una configuración inicial al usuario “initial” que va a utilizar MD5 y DES createUser initial MD5 clave_usuario DES Así se crea el usuario “initial” y se define un nuevo_usuario(aún no creado totalmente), pero el cual debemos terminar de configurar de la siguiente manera:

142

snmpusm -v 3 -u initial -n "" -l authPriv -a MD5 -A clave_usuario –x DES -X clave_usuario -l authPriv localhost create nuevo_usuario initial Se utiliza el programa “snmpusm”. Se especifica que se va a trabajar con el protocolo SNMPv3 (usando “-v 3”); se va a usar el usuario “initial” como la base de clonación (el parámetro “-u initial”); el contexto default (usando el parámetro “-n ”” ”); el nivel de seguridad deseado, en este caso, autenticación y privacidad (utilizando el parámetro “-l authPriv”); se va a utilizar como algoritmo de autenticación MD5 (usando “-a MD5”) y se define la clave asociada (usando “-A clave_usuario”); se especifica el uso del algoritmo DES para encripción (con el parámetro “-x DES”) y su clave (usando “-X clave_usuario”); en el agente “localhost” y se va a crear el usuario nuevo_usuario clonado del usuario initial. Adicional a esto, se debe cambiar la clave, ya que el nuevo usuario tiene las claves del usuario base. Esto se hace de la siguiente manera: snmpusm -v 3 -u nuevo_usuario -n "" -l authPriv -a MD5 -A clave_usuario -x DES -X clave_usuario localhost passwd clave_usuario nuevaClave Esta vez, se utiliza el parámetro “passwd” para cambiar la clave y se debe digitar la clave anterior y luego la nueva clave. Ahora se puede hacer la consulta de un valor de un objeto, de esta manera: snmpget -v 3 -u nbatest -n "" -l authPriv -a MD5 -A nbaprueba -x DES -X nbaprueba localhost system.sysName.0 Especificando la versión, el usuario, los protocolos y las claves y el nombre de la variable que se va a utilizar.

Para instalarlo en Linux desde el código fuente, se debe hacer lo siguiente: Ejecutar los siguientes comandos:

• ./ configure --with-openssl Si se desea obtener información sobre los parámetros que recibe escribir: ./configure --help.

• make • make install (esto se debe hacer como root) • configurar el agente con el archivo snmpd.conf

El programa queda instalado en la ruta /usr/local. Para incluir las MIB’s desarrolladas en el agente: luego de haber definido el árbol y la ubicación de los nodos y hojas en el árbol, se procede a incluir las MIB’s dentro de

143

las MIB’s del programa a utilizar (Net-SNMP). Es necesario copiar los archivos a la carpeta C:\usr\share\snmp\mibs, junto con los otros archivos. Luego se debe reiniciar el agente (snmpd) para que lea las MIB’s. Se debe probar que el agente reconozca las MIB’s de la siguiente manera utilizando el comando snmptranslate y los parámetros –m (para decirle que utilice todas las MIB’s), -Tp (para que imprima en forma de árbol), -IR (para hacer un acceso aleatorio al árbol) y la parte del árbol a consultar, en este caso ipTables:

Y también se puede realizar la siguiente consulta con el mismo comando y los parámetros –Td (imprimir todos los detalles).

Luego se debe utilizar la herramienta mib2c, para compilar las MIB’s y para que así nos genere una plantilla en código C. Genera un archivo .c y uno .h. Esta plantilla se debe modificar para definir de donde vienen los datos y que hacer con esos datos. De

144

la siguiente manera con los parámetros –c (para indicar la plantilla a utilizar) y la MIB a compilar: para ver un ejemplo del archivo que genera ver el Anexo 3 (ya muestra las modificaciones que se le deben hacer al archivo)

Paso siguiente, hay que modificar el archivo mib_module_includes.h (<directorio código fuente>\win32) y añadirle una línea para que incluya los módulos creados:

#include "mibgroup/yy.h" (donde yy es en nombre del .h que generó mib2c) y modificar el archivo mib_module_inits.h (<directorio código fuente>\win32) y añadirle una línea para que inicialize el módulo: if (should_init("yy")) init_yy(); (donde yy es en nombre del .h que generó mib2c) Después se deben copiar estos dos archivos a la carpeta donde se descomprimió el código fuente de la aplicación. Por lo general se debe copiare a: <carpeta de código fuente>\agent\mibgroup. Luego abrir VC++ y abrir el proyecto win32.dsw (en la carpeta <carpeta de código fuente>\win32). En la barra de la mano izquierda sale una lista de proyectos y es necesario añadir los dos archivos al proyecto netsnmpmibs. Luego se deben compilar los proyectos libagent, libhelpers y libsnmp para luego poder compilar el agente con los nuevos módulos (compilar snmpd).

145

ANEXO 6: MANUAL DE INSTALACIÓN 1. Adaptadores En Windows se debe instalar el programa Net-SNMP y reemplazar la carpeta C:\usr por la carpeta <cd>\Windows\Adaptador\usr que se encuentra en el CD, para reemplazar el agente normal por el adaptador desarrollado y poner los archivos de configuración necesarios. Adicionalmente toca instalar OpenSSL para poder utilizar las librerías en el proceso de encripción. Luego se debe instalar Kerio para que el adaptador monitoree ese programa. En Linux es necesario descomprimir los archivos fuente del programa Net-SNMP, ubicado en la ruta <cd>/Linux/Net-SNMP/net-snmp-5.2.1.tar.gz, y copiar la carpeta <cd>/Linux/modsegsnmp a <ruta de archivo descomprimido>/agent/mibgroup luego proceder con la instalación normal ya descrita en el Anexo 6. Luego se deben copiar los archivos de configuración en la ruta <cd>/Linux/conf a la ruta /usr/local/share/snmp y las MIB’s en la ruta <cd>/Linux/mibs a la ruta /usr/local/share/snmp/mibs. Es necesario verificar que se tenga instalado IpTables en el equipo. 2. Consola de seguridad Debe estar instalado MySQL en un equipo y se debe correr el script de la base de datos ubicado en la ruta <cd>\Base de datos\backup_all.sql. Para este proceso es necesario ejecutar el programa mysql, ubicado en <ruta de instalación de Mysql>\bin\mysql, de esta forma: mysql -u root -p < backup_all.sql. A continuación se pide la contraseña del usuario root (indicada al instalar MySQL). Instalar el JDK de Java y luego copiar la carpeta de la consola a la carpeta deseada en el computador. Modificar los parámetros del archivo de configuración ConfigurationParameters.properties ubicado en la ruta <ruta carpeta consola>\Consola| para que quede con la dirección IP del servidor MySQL y SMTP. Para habilitar el ingreso vía Web es necesario instalar Tomcat en un equipo y copiar el archivo webUser.war ubicado en la carpeta <cd>\Consola\Webuser\Deploy\ a la carpeta <ruta donde está Tomcat>/webapps. Posteriormente se debe editar el archivo de configuración que se encuentra adentro del archivo webUser.war para poner la dirección IP del servidor de MySQL. Para hacer esto es necesario abrir el archivo con Winzip (seleccionar el archivo, darle clic derecho y seleccionar la opción abrir con y en la lista que aparece seleccionar Winzip). Luego aparece la pantalla del programa con la lista de los archivos contenidos en webUser.war. Editar el archivo ConfigurationParameters.properties.

146

ANEXO 7: CONTENIDO DEL CD La Figura 23 muestra la estructura de árbol del CD con sus respectivas carpetas y archivos. En la derecha se muestra una descripción de que es cada archivo o carpeta.

Figura 23

147

ANEXO 8: DIAGRAMA DE CLASES GENERAL La figura 24 muestra el diagrama de clases que permite el acceso a la base de datos. La clase DBAccess se encarga de acceder a la base de datos. Utiliza un patrón singleton ya que solo puede haber una instancia de acceso a la base de datos. Las clases ConfigurationParametersManager y PropertiesReader se encargan de leer el archivo de configuración ConfigurationParameters.properties.

DBAccess

-DRIVER_CLASS_NAME:String-URL:String-USER:String-PASSWORD:String-url:String-user:String-password:String-con:Connection-instance:DBAccess

-DBAccess+getInstance:DBAccess+getMachineIp:String+deleteComputerCasesClosed:Vector+changeHistoricValue:void+insertTrapData:void+insertTrapData:void+getTrapData:Vector+deleteUser:void+insertMachineData:void+getMachineData:Vector+modifyMachineData:void+getMachines:Vector+getAllMachines:Vector+insertCaseData:void+getCaseData:Vector+getActiveCaseData:Vector+getCaseDataDetails:Vector+getActiveCasesDate:Vector+getActiveCasesDate:Vector+modifyCaseData:void+insertEventData:void+insertEventData:void+getRecentIdCase:int+getEventDataDetails:Vector+modifyEventData:void+insertNewUser:void+getNextNotification:Vector+setNextNotification:void+getBasicNotification:Vector+modifyUserData:void+getUsers:Vector+getUserDetails:Vector+validateLogin:int+getInterfaceOID:String

PropertiesReader

+getProperties:Propert-getFile:InputStream

ConfigurationParametersManager

-CONFIGURATION_FILE:String-parameters:Map

-ConfigurationParametersManager+getParameter:String

Figura 24

148

El diagrama de clases para la gestión y administración de los incidentes de seguridad se muestra en la Figura 25. La clase ControlCasos se encarga del proceso de creación, gestión y administración de los incidentes y eventos utilizados por la consola de seguridad. Se apoya en la clase SendMail para mandar las notificaciones vía correo.

SendMail

+SendMail+send:void

ControlCasos

-SMTPhost:String-smtphost:String-maquinas:Vector-db:DBAccess-sm:SendMail-instance:ControlCasos-index:int-statistics:Vector-todayDate:String-ct:consoleTest

-ControlCasos+getInstance:ControlCaso+setConsoleTest:void+hasComputer:int+processTrap:void-hasActiveCase:boolean-getStatisticsData:void+getStatistics:Vector+bringDownInterface:boole

Figura 25

En la Figura 26 se observa el diagrama de la parte gráfica de la consola de seguridad. Al iniciar la consola se ejecuta la clase SplashScreen que se encarga de iniciar el programa. Luego se ejecuta la clase Login que se encarga de validar al usuario. La clase que administra todo el funcionamiento de la parte gráfica de la consola es consoleTest.

149

JDialogTrapOptions

-options:JTabbedPane-send:JPanel-receive:JPanel-buttons:JPanel-user:JLabel-passMD5:JLabel-passDES:JLabel-addr:JLabel-port:JLabel-userData:JTextField-passMD5Data:JPasswordFie-passDESData:JPasswordFie-addrData:JTextField-portData:JTextField-user1:JLabel-passMD51:JLabel-passDES1:JLabel-port1:JLabel-userData1:JTextField-passMD5Data1:JPasswordF-passDESData1:JPasswordF-portData1:JTextField-cancel:JButton-insert:JButton-db:DBAccess-ct:consoleTest

+TrapOptions-jbInit:void-insert_actionPerformed:void-cancel_actionPerformed:void

JDialogAbout

-jLabel1:JLabel-jLabel2:JLabel-jLabel3:JLabel-jLabel4:JLabel-jLabel5:JLabel-jLabel6:JLabel-jLabel7:JLabel-jLabel8:JLabel-jLabel9:JLabel-jSeparator1:JSeparator-jSeparator2:JSeparator-jLabel10:JLabel-jButton1:JButton

+About-jbInit:void-jButton1_actionPerformed:v

MouseMotionListenconsoleTest

-db:DBAccess-cc:ControlCasos-jMenuBar1:JMenuBar-jMenu1:JMenu-jMenu2:JMenu-jMenuItem1:JMenuItem-jMenuItem2:JMenuItem-jTabbedPane1:JTabbedPane-estado:JPanel-maquinas:JPanel-info:JPanel-vpane:JSplitPane-casePane:JScrollPane-eventPane:JScrollPane-caseStateColumn:TableColumn-eventStateColumn:TableColumn-states:JComboBox-activeCases:JTable-events:JTable-downInterface:JButton-caseModel:CustomTableModelCase-eventModel:CustomTableModelEven-caseColumn:Vector-eventColumn:Vector-caseData:Vector-eventData:Vector-comp:JButton-index:int-computer:Vector-jMenuItem3:JMenuItem-jMenuItem4:JMenuItem-au:AddUser-eu:EditUser-computerClicked:String-x:int-y:int-about:About-to:TrapOptions-jMenuItem5:JMenuItem-lt:listenThread-ltr:ListenTrap-st:sendThread-deltaX:int-deltaY:int-buttonMoved:String-ls:LabelSubred-labels:Vector-labelMoved:String-jMenu3:JMenu-jMenuItem6:JMenuItem-menu:JPopupMenu-item:JMenuItem-threads:HashMap

+consoleTest+updateTrapData:void+removeComputer:void+updateCaseRow:void+displayEvents:void+displayEventData:void+savePosition:void+updateEventRow:void-jbInit:void+addLabel:void+eraseLabel:void+addComputer:void+checkComputer:int+mouseDragged:void+mouseMoved:void+addButton:void+blinkComputer:void+computerActive:void+updateDividerLocation:void-button1_actionPerformed:void-downInterface_actionPerformed:void-comp_actionPerformed:void

-SendThread-CustomTableModelCase-CustomTableModelEvent-CheckActiveCasesCompThread-CheckDatesThread+RefreshToolTip-ComputerTimer-ChangeColor-BlinkThread

insertLabel:boolean trapData:Vector eventIndex:int nextEventData:String

JDialogAddUser

-jLabel1:JLabel-jLabel2:JLabel-jLabel3:JLabel-jLabel4:JLabel-jLabel5:JLabel-jLabel6:JLabel-jLabel7:JLabel-jLabel8:JLabel-jLabel9:JLabel-jLabel10:JLabel-name:JTextField-surname:JTextField-login:JTextField-pass:JPasswordField-passCheck:JPasswordField-role:JComboBox-position:JTextField-email:JTextField-level:JComboBox-jButton1:JButton-jButton2:JButton

+AddUser-jbInit:void-jButton2_actionPerformed:v-jButton1_actionPerformed:v

JFrameLogin

-jLabel3:JLabel-jLabel2:JLabel-jLabel1:JLabel-jLabel4:JLabel-jLabel5:JLabel-jPasswordField1:JPasswordF-jTextField1:JTextField-jButton1:JButton-jButton2:JButton-db:DBAccess-ct:consoleTest-instance:int

+Login-jbInit:void-jButton2_actionPerformed:vo-jButton1_actionPerformed:vo

JDialogEventData

-listEventDataPanel:JPanel-closeListEvent:JButton-nextListEvent:JButton-backListEvent:JButton-eventIndex:int-rowCount:int-x:int-y:int-data:String-parent:consoleTest

+EventData+drawElements:void-closeListEvent_actionPerformed:v-nextListEvent_actionPerformed:vo-backListEvent_actionPerformed:vo

send+sendThread

SplashScreen

+SplashScree+main:void

JDialogEditUser

-jButton2:JButton-jButton1:JButton-email:JTextField-position:JTextField-role:JComboBox-passCheck:JPasswordField-pass:JPasswordField-surname:JTextField-name:JTextField-jLabel10:JLabel-jLabel9:JLabel-jLabel8:JLabel-jLabel7:JLabel-jLabel6:JLabel-jLabel5:JLabel-jLabel4:JLabel-jLabel3:JLabel-jLabel2:JLabel-jLabel1:JLabel-level:JComboBox-login:JComboBox-db:DBAccess-jButton3:JButton

+EditUser-jbInit:void+updateUsers:void+getUserData:void-jButton2_actionPerformed:v-jButton1_actionPerformed:v-jButton3_actionPerformed:v

listen+listenThread+ListenTrap

JDialogLabelSubred

-jLabel1:JLabel-jTextField1:JTextField-jButton1:JButton-jButton2:JButton-jTextPane1:JTextPane-ct:consoleTest

+LabelSubred-jbInit:void-jButton2_actionPerformed:-jButton1_actionPerformed:

-StopInsertLabelThread

labelName:StringinsertLabel:boolean

Figura 26