1. No category

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
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.
10
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.
11
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.
12
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
13
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.
14
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.
15
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,
16
2.
3.
4.
5.
6.
7.
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.
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.
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.
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.
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.
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.
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.
17
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
18
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
19
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.
20
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
21
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
22
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).
23
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)
24
•
•
•
•
•
•
•
•
•
•
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.
25
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.
26
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.
27
•
•
•
•
•
•
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:
28
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.
29
•
•
•
•
•
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]:
30
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.
31
•
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.
32
•
•
•
•
•
•
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.
33
•
•
•
•
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.
34
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.
2.
3.
4.
5.
Grupos.
Niveles de seguridad.
Contextos.
Vistas en las MIB.
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
35
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.
36
•
•
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.
37
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.
38
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
Bloques básicos para construir otros
octetstring
tipos más complejos de objetos.
null
object identifier
Para construir tablas
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]:
39
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.
40
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
41
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.
42
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.
43
•
•
•
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
44
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:
45
•
•
•
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
ObjectSyntax)
::=
“SYNTAX”
type
(TYPE
“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
46
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.mib2.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
47
instaladas."
STATUS mandatory
DESCRIPTION
"Dice la versión de actualización de las
definiciones de virus que tiene
::= { 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
48
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
49
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.
50
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
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.
55
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
56
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:
57
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
58
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.
59
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
60
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
61
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
62
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
63
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)
64
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:
65
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
66
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.
67
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.
68
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
69
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).
70
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).
Adaptador
Adaptador
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
71
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
72
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
73
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:
74
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
75
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
76
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.
77
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
78
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.
79
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
80
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.
81
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.
82
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.
83
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
84
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.
2.
3.
4.
Porcentaje de utilización de CPU por parte de los agentes
Utilización de la red de una herramienta comercial de gestión
Prueba de funcionalidad de la aplicación: desempeño y funcionalidad
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
sistema operativo
b. Máquina 2 (subred 2): oscila entre 0% y 3%, según mediciones
sistema operativo
2. Firewall (Linux Mandrake 10):
a. Máquina 1 (subred 1): utilización de 6%, según mediciones
sistema operativo
b. Máquina 2 (subred 2): utilización de 9%, según mediciones
sistema operativo
85
del
del
del
del
Figura 27. Diagrama de la red de prueba utilizada
86
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.
87
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
88
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.
Prueba
1
2
3
4
5
6
Máquina 1
Máquina 2
Log
BD
%
Prueba
Log
BD
863
436
50.5
1
84
68
865
438
50.6
2
95
72
858
589
68.6
3
83
74
870
606
69.6
4
87
76
861
857
99.5
5
91
88
867
863
99.5
6
93
91
Tabla 9. Porcentaje de notificación de eventos en el log
%
80.9
75.8
89.1
87.3
96.7
97.8
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
89
(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
90
(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
91
(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
92
(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.
93
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.
94
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.
95
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.
96
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.
97
Figura 36. Estructura de un mensaje SNMPv3
98
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
99
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.
100
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
http://www.sans.org/rr/whitepapers/basics/444.php
Newbies,
disponible
en:
[14] GIAC Security Essentials Certifications (GSEC) Practical Assignment,
disponible en: http://www.sans.org/rr/whitepapers/basics/1071.php
101
[15] Protecting the Network without Breaking the Bank, disponible en:
http://www.sans.org/rr/whitepapers/firewalls/809.php
[16]
Security
in
PracticeReducing
the
http://www.sans.org/rr/whitepapers/bestprac/1106.php
[17]
Threats
to
Enterprise
http://www.securitydocs.com/library/3211
Effort,
Security,
disponible
disponible
en:
en:
[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
http://www.ietf.org/rfc/rfc3164.txt
BSD
102
syslog
Protocol,
disponible
en:
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
103
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
104
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.
105
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:
106
* 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.
107
*
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.
108
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: [email protected]"
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
agente
consola
OBJECT IDENTIFIER ::= { enterprises 1 }
OBJECT IDENTIFIER ::= { modSegSNMP 1 }
OBJECT IDENTIFIER ::= { modSegSNMP 2 }
END
KERIO-MIB DEFINITIONS ::= BEGIN
IMPORTS
DisplayString FROM RFC1213-MIB
MODULE-IDENTITY, OBJECT-TYPE, enterprises
agente FROM APPLICATION-MIB;
FROM SNMPv2-SMI
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: [email protected]"
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 }
109
kerio
OBJECT IDENTIFIER ::= { agente 1 }
kDate OBJECT-TYPE
SYNTAX
MAX-ACCESS
STATUS
DESCRIPTION
"La fecha
::= { kerio 1 }
OCTET STRING
read-only
current
del registro en el log de la aplicación."
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
MAX-ACCESS
STATUS
DESCRIPTION
"El nombre
::= { kerio 3 }
OCTET STRING
read-only
current
del equipo en donde se está ejecutando la aplicación."
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
110
"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
111
ANEXO 3: IMPLEMENTACIÓN DE UNA MIB
#include
#include
#include
#include
#include
static
static
static
static
static
static
static
static
static
static
<net-snmp/net-snmp-config.h>
<net-snmp/net-snmp-includes.h>
<net-snmp/agent/net-snmp-agent-includes.h>
"kerio.h"
"kerioLogAnalyzer.h"
char *data_kDate="";
char *data_kTime="";
char *data_kHost="";
char *data_kActionTaken="";
char *data_kRemoteAddress="";
char *data_kMessage="";
char *data_kDirection="";
char *data_kClassification="";
char *data_kPriority="";
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;
112
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
));
113
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 );
114
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;
}
115
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;
}
116
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);
117
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
size_t
objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 };
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
size_t
objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 };
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));
118
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
size_t
objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 };
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,
119
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));
120
send_v2trap( var_list );
snmp_free_varbind( var_list );
return SNMP_ERR_NOERROR;
}
121
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
122
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.
123
(a) área de máquinas
(b) área de incidentes de seguridad
(c) área de eventos
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
124
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.
125
Datos del
evento
Navegar entre
eventos
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.
126
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.
127
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.
128
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.
129
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
130
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
131
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.
132
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.
133
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).
134
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.
135
Selección
de fecha
Figura 19
136
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.
137
Figura 21
138
Figura 22
139
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
140
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:
141
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
142
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
143
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).
144
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.
145
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
146
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
ConfigurationParametersManager
-CONFIGURATION_FILE:String
-parameters:Map
-ConfigurationParametersManager
+getParameter:String
-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
Figura 24
147
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.
148
AddUser
JDialog
-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
About
JDialog
-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
+AddUser
-jbInit:void
-jButton2_actionPerformed:v
-jButton1_actionPerformed:v
JDialog
TrapOptions
-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
EditUser
JDialog
-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
JDialog
EventData
-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
MouseMotionListen
consoleTest
-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
send
+sendThread
JDialog
LabelSubred
-jLabel1:JLabel
-jTextField1:JTextField
-jButton1:JButton
-jButton2:JButton
-jTextPane1:JTextPane
-ct:consoleTest
listen
+listenThread
+ListenTrap
+LabelSubred
-jbInit:void
-jButton2_actionPerformed:
-jButton1_actionPerformed:
-StopInsertLabelThread
labelName:String
insertLabel:boolean
JFrame
Login
-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
+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
Figura 26
149
SplashScreen
+SplashScree
+main:void