MODELO DE GESTIN DE SEGURIDAD CON SOPORTE A SNMP

NICOLS BOTERO ARANA

Proyecto de grado presentado para optar el ttulo de Ingeniero de Sistemas


Director: Ingeniero Edgar Enrique Ruiz Garca





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 Magnfico:
Padre Gerardo Remolina Vargas S.J.


Decano Acadmico Facultad de Ingeniera:
Ingeniero Francisco Javier Rebolledo Muoz


Decano del Medio Universitario Facultad de Ingeniera:
Padre Jos Sarmiento Nova S.J.


Director Carrera de Ingeniera de Sistemas:
Ingeniera Hilda Cristina Chaparro Lpez


Director Departamento de Ingeniera de Sistemas:
Ingeniero Germn Alberto Chavarro Flrez



Nota de Aceptacin
______________________________________________________
______________________________________________________
______________________________________________________



________________________________________
Director del Proyecto



________________________________________

Jurado



________________________________________

Jurado




JUNIO DEL 2005

Artculo 23 de la Resolucin No. 1 de Junio de 1946
La Universidad no se hace responsable de los conceptos emitidos por sus
alumnos en sus proyectos de grado.
Slo velar porque no se publique nada contrario al dogma y la moral catlica y
porque no contengan ataques o polmicas 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 Ingeniera 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 gua, de compaero, 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 cariosa, lo ayudan a
uno a seguir adelante sin importar lo que venga.

Muchas gracias a mi novia que estuvo presente durante mi ltimo ao 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 ms bsicos de mi formacin 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 enseado todo aquello que necesit en el descubrimiento
del saber.

Al director de mi tesis le agradezco toda su paciencia en aquellos momentos donde
ms se necesitaba, por haberme guiado en todo este proceso y haberme brindado un
ambiente de confianza y bienestar para el desarrollo de esta investigacin.

TABLA DE CONTENIDO


GLOSARIO ................................................................................................................ 10
1 INTRODUCCIN.............................................................................................. 12
2 PLANTEAMIENTO DE LA INVESTIGACIN.............................................. 15
2.1 OBJETIVO GENERAL.............................................................................. 15
2.2 OBJETIVOS ESPECFICOS...................................................................... 15
2.3 REQUISITOS PARA EL DESARROLLO DEL PROYECTO.................. 15
3 METODOLOGA............................................................................................... 16
3.1 DESARROLLO METODOLGICO DE LA INVESTIGACIN............ 16
4 MARCO TERICO............................................................................................ 18
4.1 ADMINISTRACIN DE SEGURIDAD ................................................... 18
4.2 ADMINISTRACIN DE RED .................................................................. 18
4.3 DOCUMENTACIN SOBRE SNMP........................................................ 19
4.3.1 Protocolo de administracin simple (SNMP) ..................................... 19
4.3.1.1 Componentes de SNMP.................................................................. 20
4.3.1.2 Representacin de la informacin................................................... 21
4.3.1.3 Operaciones (comandos) del protocolo........................................... 22
4.3.1.4 Estructura de la PDU....................................................................... 24
4.3.2 Protocolo de administracin simple versin 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 Parmetros 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 Administracin 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 Comparacin entre seguridad de SNMPv1 y SNMPv3...................... 37
4.4 DOCUMENTACIN DE MIB .................................................................. 38
4.4.1 Generalidades de MIB......................................................................... 38
4.4.2 La estructura de administracin de la informacin............................. 38
4.4.3 Interaccin con la MIB........................................................................ 39
4.4.4 Notacin 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 Identificacin de objetos ................................................................. 46
4.4.4.4 Ejemplo de la MIB de prueba ......................................................... 47
5 DESARROLLO DEL PROYECTO ................................................................... 49
5.1 SELECCIN DE PROGRAMAS A UTILIZAR....................................... 50

5.1.1 Programa Net-SNMP.......................................................................... 55
5.1.1.1 Pruebas de concepto........................................................................ 55
5.1.2 Seleccin de herramientas de seguridad ............................................. 57
5.1.3 Seleccin de motor de base de datos................................................... 62
5.1.4 Anlisis 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 Construccin 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 grfico................................................ 81
5.2.3.1.2 Subsistema de control de incidentes de seguridad.................... 81
5.2.3.1.3 Subsistema de recepcin de mensajes SNMP........................... 82
5.2.3.1.4 Subsistema de envo de mensaje SNMP................................... 82
5.2.3.2 Modelo entidad-relacin 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 DESCRIPCIN 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: TRMINOS DE LICENCIAMIENTO.................................................. 103
ANEXO 2: ESTRUCTURA DE UNA MIB............................................................. 109
ANEXO 3: IMPLEMENTACIN DE UNA MIB................................................... 112
ANEXO 4: MANUAL DEL USUARIO................................................................... 122
ANEXO 5: INSTALACIN DEL PROGRAMA NET-SNMP ............................... 140
ANEXO 6: MANUAL DE INSTALACIN............................................................ 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. Relacin 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. Implementacin 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-relacin......................................................................... 83
Figura 27. Diagrama de la red de prueba utilizada ..................................................... 86
Figura 28. Utilizacin de la red en la subred 1 ........................................................... 87
Figura 29. Utilizacin de la red en la subred 1 ........................................................... 88
Figura 30. Utilizacin de la red................................................................................... 90
Figura 31. Utilizacin de la red................................................................................... 91
Figura 32. Utilizacin de la red................................................................................... 92
Figura 33. Utilizacin de la red................................................................................... 93
Figura 34. Trfico normal de la red ............................................................................ 94
Figura 35. Grficas del envo de un gran nmero 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 aplicacin.................................. 58
Tabla 2. Caractersticas analizadas de los Anti-Spyware ............................................ 59
Tabla 3. Caractersticas analizadas de los antivirus.................................................... 60
Tabla 4. Caractersticas analizadas de los firewalls.................................................... 60
Tabla 5. Caractersticas analizadas de los IDS............................................................ 60
Tabla 6. Criterios de seleccin de herramientas.......................................................... 61
Tabla 7. Resultados de aplicar criterios a herramientas.............................................. 62
Tabla 8. Orden de las herramientas segn su peso...................................................... 62
Tabla 9. Porcentaje de notificacin de eventos en el log............................................ 89






























10
GLOSARIO

1. SNMP (Simple Network Managment Protocol): usado para administrar la
configuracin de dispositivos de red desde una estacin de trabajo [5].
2. MIB (Management Information Base): es una coleccin de informacin 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 nmeros 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 mquina 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. Autenticacin: el proceso de determinar que una entidad es quien o lo que
dice ser [5].
10. Control de acceso y autorizacin: 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 informacin deben, en todo momento, estar
disponibles.
13. Confidencialidad: que la informacin slo sea vista por los entes involucrados
en la comunicacin y que un tercero no pueda ingresar.
14. No repudio: que algn ente que haya participado en la comunicacin no pueda
negar su participacin en ella.
15. Auditabilidad: la herramienta guarda algn 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 MIBs.
18. NMS (Network Management Station): estacin de red encargada de gestionar
varios dispositivos de red.
19. PDU (Protocol Data Unit): define la estructura de la informacin que va a ser
enviada por la red.
11
20. USM (User-based Security Model): modelo de seguridad utilizado por
SNMPv3 para administrar el envo de mensajes SNMPv3.
21. VACM (View-based Access Control Model): modelo de control de acceso que
permite administrar quien tiene acceso a que informacin en la MIB.
12

1 INTRODUCCIN

Hoy en da en las empresas ha comenzado a ser de suma importancia el manejo que
se le da a la informacin y la forma como es utilizada la red. Debido a esto, son
muchas las funciones que desempea un administrador de red: entre ellas debe velar
por la gestin de la red y por la seguridad de esta. Estas dos actividades han tenido un
gran desarrollo tanto terico como prctico. Tanto para la seguridad como para la
gestin 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 gestin de red y la seguridad.
Normalmente cada una de ellas debe ser administrada desde el entorno visual que
ofrecen para interactuar. Por esta razn, 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 gestin de red es muy importante y debido a la alta sistematizacin en
las empresas, se ha tornado crtica la necesidad de saber que est pasando con los
equipos de la red. A grandes rasgos, la gestin de red es el hecho de anticiparse a
fallos en la red y de detectar su posible impacto en la prestacin de un servicio a los
usuarios [1]. La esencia de la gestin de redes se puede definir como Gestin es
todo y, especialmente, es proactividad, caracterstica que desgraciadamente no es
fcil encontrar en las herramientas que ofrece el mercado. Es esencial conocer no slo
los fallos que se pueden estar produciendo en la red en un momento determinado,
sino poder anticiparte a los mismos, estar preparado y saber cmo reaccionar en caso
de que se produzcan [1].

En forma general lo que pretende la gestin de red es minimizar los riesgos frente a
una posible falla, minimizar el costo asociado con las operaciones al evitar que
suceda algn tipo de problema y mantener la red en funcionamiento brindando los
servicios sin ningn problema. Las herramientas de gestin 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 gestin de red son [3]:
descubrir automticamente la topologa de la red, brindar herramientas de
diagnstico, monitorizacin de la red, gestin de MIBs, entre otras. Normalmente
estos sistemas que utilizan SNMP consisten de [3]: agente, consola de gestin de red
y MIB.

13
Uno de los elementos ms importantes en los sistemas de gestin 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 ningn mtodo de seguridad, como si lo hace la
versin tres. Debido a esta falencia de seguridad, se puede proporcionar gran cantidad
de informacin a un atacante sobre la configuracin 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 informacin este segura del ambiente
externo e interno de una organizacin. Sus objetivos bsicos son autenticacin,
control de acceso y autorizacin, 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 deteccin de intrusos (IDS),
antivirus, firewalls, polticas 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 va SNMP hacia una consola de gestin. Estas alertas son solo
informativas y solo sirven para el monitoreo o la consolidacin 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 trfico mediante el uso de reglas. Los IDS permiten
detectar ataques segn anlisis de trfico y pueden utilizar como forma de deteccin
firmas (patrn preestablecido) o autnomos (a partir de la caracterizacin del trfico
detectan desviaciones). Los antivirus permiten escanear los archivos y los correos en
busca de virus, gusanos, troyanos, entre otros, que pueden causar daos en las
mquina, archivos o en la red en general. Los sistemas operativos permiten manejar
seguridad a nivel de usuario, polticas de acceso y uso de los recursos, permiten
configurar protocolos, puertos, parches, etc. Todas estas herramientas generan ciertos
14
tipos de alertas visuales o notificaciones va correo, pero primordialmente generan
logs.

Un aspecto importante es que muchas de estas aplicaciones generan algn tipo de log,
en donde se va guardando la informacin de eventos durante su ejecucin. 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 aplicacin,
seguridad y sistema generados por este sistema operativo. Por ejemplo, permite saber
cuando alguien inicia sesin, cuando una aplicacin 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
gestin 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 slo podran 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 gestin de red para poder integrar los dos mundos mediante dicha consola. De esta
forma se logra tener la administracin de la red en una sola aplicacin que puede
funcionar con distintos productos del mercado. Por esta razn el proyecto puede ser
de inters para las Mipymes y grandes empresas. Es necesario aclarar que el proyecto
se centra en el uso de herramientas gratuitas debido al fcil acceso que se tiene a
estas.

Con la investigacin 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 administracin y monitorizacin 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
comunicacin, 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
gestin de red para monitorear la seguridad de la red.
15

2 PLANTEAMIENTO DE LA INVESTIGACIN

2.1 OBJETIVO GENERAL

Crear un modelo de gestin de seguridad de red que por medio de mdulos permita
monitorear herramientas de seguridad. Este brindar soporte a SNMP, para la futura
integracin con herramientas de gestin.

2.2 OBJETIVOS ESPECFICOS

Apropiarse del conocimiento del funcionamiento de SNMP y de las MIB.
Seleccin de un protocolo seguro para la comunicacin.
Seleccin de herramientas de seguridad a utilizar para validar el modelo.
Diseo y documentacin del modelo de los adaptadores.
Implementacin de los adaptadores para que monitoreen las herramientas de
seguridad seleccionadas.
Diseo e implementacin de la consola de seguridad con soporte a SNMP.

2.3 REQUISITOS PARA EL DESARROLLO DEL PROYECTO

Utilizacin de herramientas de seguridad gratuitas.
Herramientas que generen logs de texto legibles.
Estos logs deben contener la mayor cantidad de informacin acerca de un
evento de seguridad.
Utilizar el protocolo SNMP.
Tratar de mantener variedad en los sistemas operativos soportados por las
herramientas de seguridad.
En la medida de lo posible tratar que se pueda interactuar de alguna manera
con la herramienta.
16

3 METODOLOGA

La principal metodologa de investigacin que se utilizar en el proyecto se basa en el
mtodo cientfico. Se iniciar con un mtodo de exploracin, que ayudar a conocer
la informacin pertinente acerca del proyecto. Luego, se utilizar una metodologa
experimental, donde se proceder a validar el conocimiento adquirido. El cual se
describe a continuacin.

Primero que todo, se debe encontrar el problema a darle solucin con el presente
proyecto. Luego, se realizar una documentacin profunda sobre el funcionamiento
de SNMP y de las MIBs. El proceso de desarrollo se realizar utilizando el
paradigma de programacin orientada a objetos. La documentacin 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 documentacin para luego pasar a la implementacin. Este proceso
iterativo se compone de las siguientes fases: iniciacin, elaboracin, construccin y
transicin.

En la fase de iniciacin se va a realizar una documentacin profunda de los dos temas
mencionados que se refleja en el marco terico de este documento, para luego poder
proceder a realizar la definicin de requerimientos del proyecto. En la fase de
elaboracin se van a realizar ciertos documentos de definicin y documentacin de
cada una de las partes del proyecto. En este punto se incluyen las definiciones de la
respectiva arquitectura. En la fase de construccin se irn implementando cada uno de
los componentes, de tal forma que se pueda producir un producto funcional. En la
transicin se irn realizando pruebas para cada uno de los componentes y as poder
validar que no haya errores en el producto final. Finalmente, se realizar una
integracin de las partes desarrolladas para armar el producto final. Debido a la forma
y estructura del proyecto, el diseo y la documentacin se van a realizar casi
simultneamente.

3.1 DESARROLLO METODOLGICO DE LA INVESTIGACIN

Para el proceso de desarrollo de la investigacin fue necesario el cumplimiento de las
siguientes actividades:

1. Investigacin del estado del arte y verificacin de productos o investigaciones
similares. En esta actividad lo que se pretende es explorar si existe algo
similar a la investigacin propuesta y determinar lo que plantean dichos
estudios as como su funcionamiento. A partir de esto se puede darle un marco
a la investigacin, definir el alcance, definir objetivos de la investigacin,
17
determinar en que se va a distinguir frente a lo existente en el mercado.
Permite analizar que productos hay desarrollados y si alguno de ellos sirve
para el desarrollo esta.
2. Definicin del marco terico: en donde se define la teora necesaria para
realizar la investigacin. Para esto fue necesario aprender sobre el protocolo
SNMP y sobre la MIB, elementos fundamentales para el desarrollo de la
investigacin. Esta actividad permite crear uno de los pilares tericos en
donde se va a construir el modelo y su implementacin.
3. Seleccin de programas a utilizar: especifica la seleccin de herramientas de
seguridad para validar el modelo, el motor de bases de datos y la
implementacin 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 implementacin de ste. De esta
forma se puede demostrar o no la validez del modelo de seguridad propuesto y
mostrar su viabilidad.
4. Definicin 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 ms importantes ya que es donde se va a definir
la arquitectura del modelo. Aqu se definirn los componentes, el
funcionamiento, la comunicacin y la interoperabilidad entre cada uno de los
elementos definidos en ella.
5. Definicin y ejecucin de las pruebas: actividad en donde se realizarn las
pruebas y las mediciones necesarias. Las pruebas nos permiten determinar de
una manera cuantitativa el funcionamiento de la aplicacin desarrollada. Por
esta razn es muy importante definir claramente lo que se desea probar y
medir, y as, determinar la viabilidad de la implementacin del modelo. Se
realizarn mediciones a nivel de la red y de la aplicacin para determinar su
funcionamiento y el impacto que podra tener en una red.
6. Realizacin de conclusiones: esta actividad permite mencionar todos los
hallazgos encontrados durante el desarrollo de la investigacin. Se mencionan
hechos como la viabilidad del modelo, resaltar aspectos importantes de ste,
entre otros.
7. Definicin de la continuidad de la investigacin: comnmente una
investigacin no abarca todos los caminos necesarios para que sea completa.
Es por esta razn que se resaltan trabajos futuros que se pueden desarrollar a
partir del modelo propuesto. Aspectos que no se consideraron en la definicin
del alcance y de los objetivos y que pueden brindarle al modelo una riqueza
mayor, sin olvidar que los trabajos pueden ser trabajos de investigacin.
18

4 MARCO TERICO

4.1 ADMINISTRACIN DE SEGURIDAD

La administracin de seguridad es un proceso mediante el cual se administran,
definen y actualizan las polticas de seguridad para proteger los recursos ms valiosos
de la red y que a diferencia de la administracin 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 desempea una funcin primordial en
una arquitectura de proteccin de profundidad y en especial generan alarmas de una
manera independiente y sin ninguna administracin centralizada que las coordine.
Esta es una de las razones por al cual el proceso de anlisis forense debe ser largo y
se debe inspeccionar cada uno de estos elementos tanto hardware como software.

4.2 ADMINISTRACIN DE RED

La administracin de red es el proceso mediante el cual podemos encontrar fallas en
algn punto de la red, de manera centralizada y tomar alguna accin que lleve a la
solucin del problema. Es importante que la gestin de red sea proactiva, es decir,
que se pueda anticipar a un fallo de la red y no esperar a su materializacin para
tomar una accin preventiva.

Antes de abordar el tema, es de suma importancia mencionar algunos breves
conceptos sobre la administracin de red. Normalmente, cuando se desea monitorear
la red de una empresa, se utiliza un sistema de administracin de red, el cual est
compuesto de los siguientes elementos: los nodos administrados, que es bsicamente
lo que nosotros deseamos monitorear (enrutadores, switches, estaciones de trabajo,
etc.), que por medio de un agente presente en ellos se facilita su administracin; la
estacin de administracin de red (NMS), que es donde se ejecuta el monitor, quien
va a comunicarse con los agentes para lograr la administracin de la red; por ltimo
tenemos el protocolo que se va a encargar de la comunicacin entre el agente y la
NMS.

Para fines de la administracin, no es suficiente con slo intercambiar la informacin
de administracin para poder monitorear el nodo. El protocolo, debe a su vez, proveer
una arquitectura de administracin que utilice los conceptos de autenticacin y de
19
autorizacin (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 informacin acerca de si mismo.

Hasta el momento existen dos protocolos para la administracin de red. Estos son:
SNMP y CMIP (Common Management Information Protocol). Este documento se va
a centrar en el protocolo SNMP.

4.3 DOCUMENTACIN SOBRE SNMP

4.3.1 Protocolo de administracin 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
podran 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.
Bsicamente acta 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 enva como un datagrama UDP a la direccin de la entidad que recibe. Los agentes
SNMP estn escuchando por el puerto 161.

Se puede ver la forma como sera el transporte de un mensaje SNMP en la Figura 1,
donde se muestran los protocolos de cada capa involucrados en el proceso [9].


Figura 1. Transporte de un mensaje SNMP

20
4.3.1.1 Componentes de SNMP

Se compone de tres partes indispensables para su funcionamiento: consola de
administracin (NMS), agente y MIB [7].

1. Agente: es un programa encontrado en un dispositivo de red, ya sea una
estacin, un switch o un router o cualquier dispositivo administrable mediante
SNMP.
2. Consola de administracin: es un programa encontrado en una estacin 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 va SNMP para lograr la administracin de la red.

Las responsabilidades ms importantes de cada una de estas partes seran [7]:

1. Responsabilidades del agente:
Posee una vista de la MIB que incluye la MIB estndar de Internet ms otras
extensiones
1
. En la MIB no se tiene porque implementar todos los grupos de
variables definidas en la especificacin de las MIB. Gracias a esto se puede
simplificar significativamente la implementacin de SNMP en dispositivos
pequeos de una red (debido a que tienen limitacin de memoria y
procesamiento). Bsicamente 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 algn efecto en el dispositivo).

2. Responsabilidades de la consola de administracin:
Bsicamente se encarga de ejecutar las aplicaciones que ayudan a analizar el
funcionamiento de la red. Normalmente provee una interfaz grfica 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 estndar de Internet a la definicin de la MIB-II del RFC 1213, una mejora de la
MIB-I y que son estndar para todo el que pretenda implementar dicha funcionalidad. Por otro lado, se
refiere a extensiones cuando hablamos de extensiones que se hacen a la definicin estndar. Esto es,
definiciones de nuevos objetos a monitorear que no estn definidos en la MIB-II. Son extensiones para
monitorear dispositivos de cada uno de los fabricantes y/o de todo aquel que desee desarrollar una
MIB nueva.
21
Toda la documentacin est escrita en ASN.1, que trata de ser un estndar
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 versin ms robusta a la anterior y extendi los objetos a
una gran variedad de medios y dispositivos de red.

4.3.1.2 Representacin de la informacin

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 nmeros 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. Tambin 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 informacin de gestin.
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 codificacin bsicas (BER) [19]. Es la codificacin utilizada para
22
transferir informacin escrita en ASN.1 a otras aplicaciones mediante una sintaxis
que define y permite definir el formato de cmo 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
maysculas
Valores (values): que son variables de un tipo y son escritas en minsculas
Macros: usados para cambiar la gramtica y son escritas en maysculas

4.3.1.3 Operaciones (comandos) del protocolo

En el protocolo de administracin de red SNMP, se encuentran seis operaciones
bsicas (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 pequea diferencia que es ampliamente necesaria y
utilizada. El comando GetRequest se encarga de traer el valor de ciertos objetos
especificados como parmetros, mientras que el comando GetNextRequest se encarga
de traer el siguiente valor del objeto segn el orden lexicogrfico (ver ms 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 administracin (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 administracin de red y si es usado de una manera indebida puede
corromper los parmetros de configuracin de los nodos administrados y hasta
interrumpir los servicios de red. Por esta razn, es importante implementar
mecanismos de encriptacin y de autenticacin.

El quinto comando, Traps, es un comando especial que los agentes utilizan para
mandar datos a la consola de administracin, 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 nmero de solicitudes que tocara realizar para
23
traer las filas de las tablas. Es muy parecido al comando GetNextRequest, solo que no
solicita objeto por objeto, sino que puede solicitar una gran cantidad de una vez.

En la Figura 3 se puede apreciar como es el proceso de intercambio de mensajes, o
ms 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 peticin, un campo dentro del formato de un mensaje SNMP
que contiene una identificacin 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 iran 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 lexicogrfico
2
). Por

2
Se refiere al siguiente objeto que le sigue al que estn solicitando. Por ejemplo: si se hace un
GetNextRequest para el objeto sysLocation.0 (1.3.6.1.2.1.1.6.0), se va a retornar el nombre y el valor
del objeto sysServices.0 (1.3.6.1.2.1.1.7.0) con su respectivo valor. Otra nueva solicitud a este ltimo
objeto va a retornar el nombre y el valor de ifNumber.0 (1.3.6.1.2.1.2.1.0).
24
ejemplo [10], ante esta solicitud: GetRequest (udpInDatagrams.0, udpNoPorts.0, ),
obtenemos como respuesta: GetResponse ((udpInDatagrams.0=100),
(udpNoPorts.0=1), ). La operacin SetRequest (Figura 3 (c)) es muy similar a
GetRequest, pero la diferencia sustancial radica en que el fin de esta operacin 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 identificacin. Al igual
que las anteriores es una operacin atmica (o todas las variables o nada). En el
campo variable coloca los datos que fueron modificados. Por ejemplo [10], ante la
solicitud de modificacin: SetRequest (ipRouteMetric.1.9.1.2.3=9), y la operacin se
realiz con xito, se responde con: GetResponse (ipRouteMetric.1.9.1.2.3=9) el cual
cambi la mtrica de la entrada 9.1.2.3 de la tabla de ruteo a 9. Por ltimo, tenemos la
operacin Trap (Figura 3 (d)), la cual no necesita del arribo de un mensaje para
mandar los datos. A diferencia de los anteriores, esta operacin 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]:

Versin: la versin de SNMP que se va a usar
Comunidad: relacin que existe entre un agente y un grupo de aplicaciones
SNMP (un componente de una entidad SNMP)
25
Tipo PDU: indica el tipo de la PDU que va en el mensaje, que puede ser algn
tipo de Request (como GetRequest, GetNextRequest y SetRequest), un
GetResponse o un Trap.
Peticin ID: usado para distinguir de entre otras solicitudes, cada solicitud con
una identificacin nica
Error-status: usado para indicar que ha sucedido una excepcin mientras se
procesaba una solicitud
Error-ndice: cuando el error-status es diferente a cero (no hubo error) puede
proporcionar informacin adicional indicando que variable caus la excepcin
Campos variables: una lista de nombre de variables con sus correspondientes
valores, normalmente contiene los datos solicitados por una operacin Get o
Trap
Empresa: tipo de objeto que genera un Trap
Direccin agente: direccin del objeto generado del Trap
Trap genrico: tipo genrico del Trap
Trap especfico: cdigo especfico del Trap
Time-stamp: tiempo transcurrido entre la ltima vez que se reinici el
dispositivo de red y la generacin del Trap

Vale la pena mencionar el trmino de comunidad, que bajo la mirada de SNMP, es la
pareja de un agente SNMP y una(s) aplicacin(es) SNMP (entidades SNMP que
residen en las aplicaciones administradas). El nombre de la comunidad identifica un
esquema de autenticacin
3
. La serie de eventos para la autenticacin es la siguiente:

1. La entidad SNMP manda a una entidad de autenticacin:
Nombre de la comunidad
Los datos
La direccin del que manda

2. La entidad de autenticacin que conoce el esquema de autenticacin (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 identificacin de la entidad que manda
Una excepcin
4.3.2 Protocolo de administracin simple versin 3 (SNMPv3)

SNMPv3 se puede definir como:


3
En este caso el esquema de autenticacin es muy sencillo. La aplicacin SNMP, conoce las
comunidades vlidas que pueden operar en el agente. Si la solicitud proviene de una comunidad
conocida, es aceptada. Segn el tipo de comunidad se pueden hacer determinadas operaciones en la
MIB.
26
SNMPv3 = SNMPv2 + (seguridad y administracin)

Fue diseado para proteger contra las siguientes amenazas de seguridad, mediante el
uso de algoritmos de autenticacin y de encripcin, como lo especifica el RFC 2574:

Modificacin de la informacin: una entidad podra alterar un mensaje
generado por otra que esta autenticada y as lograr que haya una accin no
autorizada en la entidad que recibe el mensaje. El problema aqu es que se
podra modificar algn parmetro de configuracin.
Enmascaramiento (masquerade): operaciones no autorizadas para un usuario
pueden ser intentadas asumiendo la identidad de otro usuario que posee
autorizacin para la operacin deseada.
Reenvo de mensajes: como SNMP opera sobre un protocolo de transporte sin
conexin, existe el riesgo que un mensaje SNMP sea almacenado por algn
tercero y luego, reenviado o duplicado, para realizar operaciones de
administracin no autorizadas.
Poca privacidad (disclosure): una entidad puede observar el intercambio de
mensajes entre un agente y una consola de administracin y as, aprender de
los valores de los objetos.

Por otro lado, se defini que no estaba diseado para prevenir estos tipos de ataques:

Denegacin de servicio (DoS): prevenir que haya intercambio de mensajes
entre agente y consola de administracin.
Anlisis de trfico: un atacante puede observar los patrones de trfico entre
estas dos entidades.

4.3.2.1 Arquitectura SNMPv3

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

27

Figura 5. Diagrama de una entidad SNMP

En la Figura 5 se muestra el diagrama general de bloques de una entidad SNMPv3
[10]. Cada entidad incluye slo un motor SNMP que implementa funciones para
enviar y recibir mensajes SNMP, poder autenticar y encriptar mensajes y controlar el
acceso. Estas funciones estn a cargo de ciertos mdulos 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, estn definidas en
mdulos. Lo que permite tener una ventaja: el rol de cada entidad esta determinado
por los mdulos que implementa, permitiendo que sea mucho ms sencillo modificar
los mdulos.

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 PDUs, 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 envo y extraer datos de mensajes recibidos.
Subsistema de seguridad: provee los servicios de seguridad de autenticacin y
de encripcin o privacidad para los mensajes que as lo necesiten.
28
Subsistema de control de acceso: provee los servicios de autorizacin a
recursos y define que aplicacin tiene derecho y el tipo de acceso que tiene.
Generador de comandos: inicializa las PDUs de los mensajes y procesa la
respuesta.
Contestador de comandos: recibe las PDUs destinadas a la entidad cuyo
campo de contextEngineID es igual a la identificacin del motor SNMP.
Juego, realiza la operacin 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 operacin de
Trap. Para poder hacer esto, es necesario que tenga un mecanismo que le diga
a donde mandar los mensajes, que versin y parmetros de seguridad utilizar.
Receptor de notificaciones: escucha por mensajes de notificacin (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 propsitos de control de
acceso, cada entidad posee un nmero de contextos de informacin 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
identificacin, contextEngineID, que es el mismo que para el snmpEngineID.

El snmpMessageProcessingModel determina el formato y la versin 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 operacin especfica. Pude brindar una de las siguientes combinaciones:
autenticacin, autenticacin y privacidad o ninguno de los dos.

Trminos 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 parmetro 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 estn siendo procesados, referente a
la autenticacin y privacidad. Los valores que puede tomar son:
29
noAuthnoPriv, authNoPriv y authPriv, donde cada uno puede proveer o no
uno de los servicios de seguridad.

4.3.2.2 Formato del mensaje

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


Figura 6. Formato del mensaje SNMPv3

Los campos del formato anterior son:

msgVersion: su valor est por default en SNMPv3.
msgID: identificador nico usado entre dos entidades para coordinar mensajes
de solicitud y de respuesta.
msgMaxSize: tamao mximo del mensaje que el remitente puede aceptar.
msgFlags: una cadena que contiene tres banderas: reportableFlag, privFlag y
authFlag.
30
msgSecurityModel: un identificador que indica que modelo de seguridad fue
usado por el remitente para preparar el mensaje. Esto le permite al receptor
saber que modelo debe utilizar. Los valores pueden ser: 1 para SNMPv1, 2
para SNMPv2c y 3 para SNMPv3.
msgSecurityParameters: cadena que contiene parmetros 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 aplicacin 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 especificacin contiene:

Autenticacin: provee integridad de datos y autenticacin. Utiliza los
algoritmos MD5 o SHA-1.
Timeliness: protege contra retardos o reenvos 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 informacin de otro.
Administracin de llaves: define el procedimiento para la generacin,
actualizacin y uso de las llaves.

4.3.2.3.1 Parmetros de seguridad de USM

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

31

Figura 7. Formato del mensaje SNMPv3 con el campo msgSecurityParameters

4.3.2.3.2 Motor SNMP autoritativo

Antes de explicar los campos del mensaje, es necesario aclarar un concepto muy
utilizado por el modelo USM. Este es el motor SNMP autoritativo.

En cualquier transmisin de un mensaje, una de las dos entidades involucradas en el
proceso, ya sea el transmisor o el receptor, debe ser designada como el motor SNMP
autoritativo. De acuerdo a las siguientes reglas:

Cuando un mensaje SNMP contiene un payload que espera una respuesta
(como por ejemplo, Get, GetNext o Set) el receptor de los mensajes es
autoritativo.
32
Cuando un mensaje SNMP contiene un payload que no espera respuesta
(como por ejemplo, un Trap, un Response o un Report
4
) 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 sincronizacin 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 localizacin de llaves. Permite que un
principal tenga las llaves de mltiples 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 funcin de hash segura (que depende
del algoritmo usado) y as se obtiene una llave localizada, Kul. Este proceso se
resume en la Figura 8.


Figura 8. Forma de manejo de las llaves

Elementos de UsmSecurityParameters:


4
Forma en que se hace el descubrimiento de otros motores SNMP.
33
msgAuthoritativeEngineID: el snmpEngineID de un motor SNMP autoritativo,
involucrado en el intercambio de mensajes.
msgAuthoritativeEngineBoots: el valor de snmpEngineBoots del motor SNMP
autoritativo en el intercambio de mensajes, y corresponde al nmero de veces
que el motor se ha reiniciado.
msgAuthoritativeEngineTime: el valor snmpEngineTime del motor SNMP
autoritativo involucrado en el intercambio de mensajes, representa el nmero
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 autenticacin, de lo
contrario, es un cdigo de autenticacin 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 autenticacin y encripcin, el motor SNMP
requiere dos valores: una llave privada (privKey) y una llave de autenticacin
(authKey). Estos valores son atributos relevantes de cada usuario creado. Los valores
de cada una de estas llaves no son accesibles va SNMP.

4.3.2.3.3 El grupo MIB usmUser [10]

Es una MIB que se encarga de mantener informacin 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 mtodo de
garantizar la concurrencia) y una tabla usmUserTable, que tiene las siguientes
columnas ms 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
relacin 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 parmetros de autenticacin 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 autenticacin
y adems, especifica el protocolo a usar.
34
usmUserAuthKeyChange: cuando es modificado, hace que la llave secreta de
autenticacin para enviar mensajes, sea modificada.
usmUserPrivProtocol: identificador que indica si un mensaje enviado por la
entidad, identificada por el usmUserEngineID, puede ser protegido por
encripcin o no, adems indica el protocolo a utilizar.
usmUserPrivKeyChange: cuando es modificado, causa que se cambie la llave
secreta de encripcin para enviar mensajes.
usmUserPublic: valor que puede ser ledo pblicamente 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
informacin de otros motores SNMP, para poder llevar a cabo la comunicacin. 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 comunicacin autenticada, el motor SNMP no autoritativo debe
establecer una sincronizacin 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 Administracin de llaves

Un requerimiento planteado en la creacin del RFC para los servicios de
autenticacin y privacidad, es que para la comunicacin entre un motor no
autoritativo y uno autoritativo, se debe compartir una llave secreta de autenticacin y
una llave secreta de privacidad. Estas llaves permiten que un usuario en un motor no
autoritativo, pueda emplear autenticacin y privacidad en sistemas autoritativos
remotos.

Para mantener simple la administracin de llaves, cada principal (una entidad a quien
se le proveen servicios) es responsable por mantener una llave de autenticacin y de
encripcin o privacidad. Estas llaves no son guardadas en una MIB y no son
accesibles va SNMP.
35

4.3.2.4 Modelo de control de acceso basado en vistas (VACM)

El modelo VACM tiene dos importantes caractersticas [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 polticas de control de
acceso para el agente

4.3.2.4.1 Elementos del modelo VACM

El RFC 2575 define cinco elementos que componen el VACM:

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

Los grupos: se encuentran definidos como un conjunto de cero o ms 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 segn el
nivel de seguridad del mensaje en la solicitud. Por ejemplo, se puede permitir solo la
lectura para un mensaje no autorizado, pero necesitar autenticacin 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 coleccin con diferentes polticas de
acceso. El contexto se refiere a control de acceso. Una solicitud SNMP, identificada
nicamente por un contextEngineID, puede mantener ms de un contexto. Un objeto
o una instancia de un objeto pueden estar en uno o ms contextos. Cuando existen
mltiples 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 administracin en el agente. Para poder hacer esto, el
acceso al contexto se hace mediante la definicin de vistas MIB. Esto saca provecho
de que los objetos estn organizados en forma de rbol. Por esto, asociado a cada
36
entrada en la tabla vacmAccessTable hay tres vistas: lectura, escritura y notificar
acceso (representa el conjunto de instancias de objetos autorizados cuando mandan
objetos en una notificacin. Cada vista consiste en un conjunto de vistas de
subrboles.

Las polticas de acceso: el VACM permite que el motor SNMP sea configurado para
impartir ciertos derechos de acceso. La determinacin 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 travs 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 informacin de contextos locales, grupos, derechos de acceso y vistas MIB.

Informacin sobre contextos locales:
La tabla vacmContextTable lista los contextos disponibles localmente. Esta
informacin es usada por el generador de comandos para crear la tabla
vacmAccessTable para poder controlar el acceso a los contextos. Un nombre
de contexto vaco representa el contexto default. Estas dos tablas no se
relacionan entre si.

Informacin 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.

Informacin 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, segn el valor de vacmAccessContextMatch.
vacmAccessSecurityModel: identifica un modelo de seguridad.
vacmAccessSecurityLevel: el nivel mnimo de seguridad requerido
para tener acceso.
37
vacmAccessContextMatch: el valor puede ser exacto (exact(1)), que
significa que el nombre del contexto debe ser exacto; puede ser de
prefijo (prefix(2)), entonces slo 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.

Informacin 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 creacin y modificacin 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 subrbol.
vacmViewTreeFamilyMask: la mscara que combinada con el
vacmViewTreeFamilySubtree define una familia de subrboles.
vacmViewTreeFamilyType: puede tomar uno de los valores siguientes:
incluido (included(1)) o excluido (excluded(2)) e indica si el
correspondiente subrbol de la familia, que est definido por los dos
campos anteriores, est o no en la definicin.

4.3.3 Comparacin entre seguridad de SNMPv1 y SNMPv3

La seguridad en SNMPv1:
Tanto las estaciones administradas como las NMS, necesitan protegerse a si
mismas y sus MIBs 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 relacin entre el agente y
los administradores. Con la comunidad se define la autenticacin y el control
de acceso. Este concepto es local al dispositivo y se puede configurar una
comunidad para cada combinacin de autenticacin y acceso. Por ejemplo, se
puede definir una comunidad privada para lectura y escritura y una comunidad
pblica para slo lectura. La comunidad es empleada como parmetro de
comandos Get y Set.

Se utiliza un esquema muy trivial de autenticacin: la comunidad. La cual
acta como una clave compartida donde la solicitud recibida es procesada si el
nombre de la comunidad de la solicitud concuerda con la comunidad definida
en la entidad que recibe la solicitud.
38

De una manera muy sencilla, la comunidad, permite controlar el acceso a su
MIB. Mediante el empleo de ms de una comunidad, se puede proveer
distintos tipos de acceso.

Por estas razones es comn que SNMPv1 se utilice ms para monitoreo de
dispositivos, que para control de los mismos, ya que el concepto de
comunidad es muy inseguro y adems viaja en texto plano por la red. Es un
gran punto de inseguridad en una red, ya que es muy difcil saber a ciencia
cierta quien es el que solicita la informacin.

La seguridad en SNMPv3:
Como se vio anteriormente, esta versin provee un mejor sistema de
seguridad y mucho ms robusto y confiable. Utiliza encripcin convencional
con DES y autenticacin con MD5. Adems 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 DOCUMENTACIN 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 informacin de gestin (MIB), son muy utilizadas por los agentes para poder
monitorear un aparato especfico.

Las bases de informacin de gestin (MIB) son un conjunto de objetos gestionados
de un recurso que se encuentra en la red para ofrecer algn tipo de interoperabilidad o
funcionamiento en esta misma y el cual se desea gestionar. Dentro de la MIB, los
objetos estn organizados en grupos, segn su funcin y la informacin que guarda.
Los objetos en la MIB, se encuentran definidos formalmente y son administrados
mediante el protocolo SNMP. En ella hay unos grupos estndares que todos conocen
y con el tiempo se ha ido extendiendo segn la aparicin de nuevos aparatos
gestionables con SNMP, que se conocen como extensiones de la MIB.

4.4.2 La estructura de administracin de la informacin

La SMI define como la informacin de administracin es agrupada y nombrada, las
operaciones permitidas, tipos de datos permitidos y la sintaxis para escribir las MIBs.
39
Especifica que cada objeto administrado debe tener un nombre (nico, mediante el
OID), una sintaxis (tipo de dato) y una codificacin (como la informacin es
serializada para la transmisin, comnmente 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 slo puede
guardar tipos de datos simple, conocidos como escalares. Por esta razn con SNMP
solo se pueden consultar este tipo de datos. Para poder definir una MIB, es posible
utilizar los siguientes tipos de datos:

integer
octetstring
null
object identifier
sequence y sequence-of

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

4.4.3 Interaccin con la MIB

Una NMS debe ser cargada con la informacin 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 descripcin formal. Con la descripcin formal, una
NMS debe ser capaz de leer la MIB del disco, procesarla y pasarla para aadir 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 lexicogrfico 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 administracin o gestin de la red: la primera, de
forma pasiva (implica la recoleccin 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 accin en el
aparato).

La comunidad OSI divide la administracin de la red en cinco reas funcionales [11]:
Bloques bsicos para construir otros
tipos ms complejos de objetos.
Para construir tablas
40

1. Administracin de la configuracin: nombra todos los elementos en la red y
especifica su estado y caractersticas.
2. Administracin del performance: determina la utilizacin de la red y de sus
elementos. Permite medir tiempos de respuesta, recursos utilizados,
disponibilidad, etc.
3. Administracin de errores: detecta, asla y corrige problemas de red.
4. Administracin de seguridad: controla el acceso y protege la informacin en
la red.
5. Contabilidad: mide el uso y el costo de los computadores basados en polticas
establecidas.

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

Los estndares: MIB I y MIB II (para una diferenciacin entre las dos, ver
ms adelante)
Las experimentales: grupos que se encuentran en fase de desarrollo
Las privadas: informacin especfica de fabricantes de equipos para equipos
especficos

4.4.4 Notacin 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. Tambin, como sucede con SNMP, se utiliza para definir la estructura y
la presentacin de las PDU (Protocol Data Unit).

El empleo de ASN.1 trae muchas ventajas a la hora de desarrollar una aplicacin que
la utilice. Trae beneficios como: estandarizacin (es un estndar internacional que
soporta muchos protocolos y tambin 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. Tambin es independiente del vendedor, de la plataforma
y del leguaje de implementacin.

Terminologa importante en ASN.1 [10]:

1. Sintaxis abstracta: describe la estructura general de los datos independiente de
cualquier tcnica de codificacin para representarlos. Permite definir tipos y
valores para los datos.
41
2. Tipo de dato: conjunto de nombres de valores. Pueden ser simples
(especificados por medio de valores) o estructurados (especificados por medio
de otros tipos).
3. Codificacin: secuencia de octetos usada para representar los valores de los
datos.
4. Reglas de codificacin: especificacin de un mapeo de una sintaxis a otra.
Determina algortmicamente 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. Relacin 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 aplicacin (en nuestro caso SNMP),
encargado de transferir datos al usuario e interpreta lo que viene del componente de
transferencia mediante las reglas de codificacin.

Debe existir un almacenamiento de algn tipo, en donde se va a guardar la definicin
de la estructura de los datos, que en nuestro caso van a ser las MIBs (que son
definidas con una sintaxis abstracta).

Los componentes de aplicacin se comunican entre si, por medio de una sintaxis
abstracta. Se interesa por la vista de los datos que debe tener el usuario, ya sea un
42
archivo, una base de datos o simplemente en la pantalla. El usuario se preocupa por la
semntica de los datos, bsicamente, que lo que se va a enviar tenga coherencia y
cumpla con ciertas reglas definidas. El protocolo describe las PDUs mediante una
sintaxis abstracta, similar a la notacin Bacchus-Naur Form (BNF). Provee
representacin y revisin 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 aplicacin como
una secuencia de octetos, que pueden ser ensamblados en la PDU correspondiente.
Estos dos componentes se logran comunicar gracias a las reglas de codificacin.

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 implementacin, del tipo de hardware y del tipo de representacin interna de los
datos. Ofrece un rehso de esquemas de codificacin, si se tiene unas reglas de
codificacin bien definidas, se puede referenciar por cualquier aplicacin que use la
misma sintaxis. Tambin se puede tener una buena estructura del cdigo, si se tiene
una buena especificacin de sintaxis abstracta y con ayuda de una herramienta, se
puede generar el cdigo respectivo.

Gracias a la separacin que tiene ASN.1 de la notacin abstracta y la sintaxis de
transferencia, se puede reutilizar el cdigo. Con la ayuda de un compilador de
ASN.1, cualquier definicin en sintaxis abstracta puede ser mapeada a la estructura
abstracta de datos de cualquier leguaje de programacin.

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 lexicogrficas:
Las estructuras ASN.1, los tipos y los valores son expresados en una notacin similar
a la utilizada por leguajes de programacin como C, C++ o Java.

Se definen las siguientes convenciones [10]:

1. La distribucin de las lneas no es importante. Puede haber mltiples espacios
y lneas.
2. Los comentarios son delimitados por parejas de guiones (--). De esta forma: --
comentario comentario (toda la lnea).
3. Nombres de valores y campos (identificadores) y nombres de tipos
(referencias a tipos) consisten en letras maysculas o minsculas, dgitos y
guiones.
43
4. Los identificadores comienzan con una letra en minscula.
5. Una referencia a tipo comienza con una letra en mayscula.
6. Un tipo embebido (ya construido) consiste con todas las letras en maysculas.
Un tipo embebido es un tipo usado comnmente para el cual se provee una
notacin estndar.
4.4.4.2 Tipos abstractos de datos

ASN.1 es una notacin para tipos de datos abstractos. Un tipo puede ser visto como
una coleccin de valores. El nmero de valores que puede tomar es infinito.

Los tipos se clasifican en cuatro categoras [10]:

Simples: son tipos atmicos, 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 ms 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 definicin 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 ms de un nivel.

Hay seis formas para designar subtipos [10]:

Un solo valor: es un subtipo que lista explcitamente 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 mnimo y un valor mximo.
44
Alfabeto permitido: solo puede ser aplicado a tipos con cadenas de caracteres.
Este subtipo consiste de los valores que pueden ser construidos teniendo un
subalfabeto, de uno ms grande.
Restriccin de tamao: limita el nmero de elementos en un tipo. Slo 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 ms 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 definicin 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 sera IfEntry. La clusula ACCESS debe estar
en not-accessible. El siguiente ejemplo muestra como se definira 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 clusula 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 adicionndole el valor 1. La clusula
INDEX especifica las reglas para la construccin de instancias y es el nombre de la
secuencia de un tem de la secuencia. Sigamos definiendo las filas para el ejemplo
anterior:

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

La secuencia es usada para especificar columnas en una fila (en otras palabras, es una
secuencia de los campos que tendra la tabla). El nombre debe comenzar por
mayscula. 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 agrupacin de informacin ms
pequea y se refiere a una variable especfica. Continuando con el ejemplo:

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

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

46
Tipo (type): NombreDelTipo ::= TYPE
Valor (value): nombreDelValor NombreDelTipo ::= VALUE
Macro: ver ms adelante

Tambin se tienen los siguientes tipos simples:

INTEGER, tipo de dato que toma como valor un nmero 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 ms octetos. Cada byte toma
valores entre 0 y 255.
OBJECT IDENTIFIER: tipo de dato que permite la identificacin de objetos
de gestin.
NULL: tipo nulo.

El SMI define la siguiente macro para los objetos que van a ser administrados:

OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= SYNTAX type (TYPE
ObjectSyntax)
ACCESS Access
STATUS Status
VALUE NOTATION ::= value (VALUE ObjectName)

Access ::= read-only
| read-write
| write-only
| not-accessible
Status ::= mandatory
| optional
| obsolete
END

4.4.4.3 Identificacin de objetos

Cuando se desee referir una instancia particular, se debe aadir 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
posicin en el rbol: una forma absoluta (en el cual se especifica el camino a un
atributo desde la raz del rbol, semejante a una ruta absoluta en los sistemas
47
operativos; siempre debe comenzar con un punto y debe especificar cada nodo por el
que pasa) y otra forma relativa (que especifica el camino a algn atributo en el rbol,
a partir de un nodo, muy parecido a una ruta relativa en los sistemas operativos).

Un objeto especfico se puede identificar de manera nica mediante alguna de las
siguientes tres formas:

1. Slo nmeros: se utiliza una secuencia de nmeros enteros, separados por
puntos. Por ejemplo: 2.1.1.1 que identifica el objeto sysDescr.
2. Slo 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 combinacin de los dos: se puede usar una combinacin tanto de
nmeros como de texto, separados por puntos. Por ejemplo: mgmt.mib-
2.1.sysContact que tambin 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
mquina que se esta accediendo."
::= { tesis 1 }

avUpdateVersion OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
48
STATUS mandatory
DESCRIPTION
"Dice la versin de actualizacin de las
definiciones de virus que tiene
instaladas."
::= { tesis 2 }

END

Que nos generara la siguiente estructura de rbol (como se ve en la Figura 10), donde
sale lo que definimos bajo el nodo de private:


Figura 10. Vista del rbol construido


49

5 DESARROLLO DEL PROYECTO

El desarrollo del proyecto se debe realizar en cuatro etapas muy importantes. La
primera de ellas es la de documentarse sobre el funcionamiento tanto de SNMP como
de la MIB. Luego, se debe definir el protocolo seguro que se va a utilizar en la
comunicacin entre el adaptador y la consola. A continuacin se debe construir el
adaptador que va a estar monitoreando los programas seleccionados en las mquinas.
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 comunicacin con una consola de gestin) y por el otro el protocolo
seleccionado para la comunicacin 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 ejecucin. Las alertas encontradas las
reporta a la consola de seguridad utilizando el protocolo seguro de comunicacin.
Como la consola tiene soporte a SNMP, un monitor SNMP podra comunicarse con
esta y debido a que posee una MIB (que contiene las variables de seguridad), podra
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
comunicacin 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 accin 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 gestin de red para la integracin con la
consola de seguridad. Lo que se hizo es validar el modelo con un caso sencillo de
50
prueba de la comunicacin con SNMP. Est fuera del alcance del proyecto la
integracin con una herramienta de gestin de red.

5.1 SELECCIN DE PROGRAMAS A UTILIZAR

No se ha encontrado otra herramienta que pretenda integrar la gestin 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 podra llegar a monitorear
cualquier herramienta que genere logs de notificaciones del funcionamiento de la
aplicacin (que reflejen la accin 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 aplicacin). 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 comunicacin SNMPv3, ya que no se pueden utilizar las
versiones 1 y 2c por lo altamente inseguras y porque introduciran un punto inseguro
en el modelo propuesto. SNMPv3 nos permite utilizar encripcin y autenticacin en
los mensajes intercambiados ocultando el contenido y valores de los objetos. Adems
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 versin 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 versin
utilizada, las tres banderas utilizadas y el contenido encriptado de la PDU.



51







Figura 12. Get utilizando SNMPv2









52







Figura 13. Response del mensaje SNMPv2








53




Figura 14. Get utilizando SNMPv3




54




Figura 15. Response del mensaje SNMPv3

55

5.1.1 Programa Net-SNMP

Net-snmp es un programa que provee herramientas y libreras relacionadas al
protocolo SNMP que incluye: un agente extensible, esto quiere decir que el agente
bsico que viene con el programa puede ser extendido a manejar otras MIBs que uno
puede desarrollar y estas pueden ser fcilmente introducidas al agente, por lo cual,
ste puede monitorear lo que se le ha incorporado; una librera SNMP, provee una
implementacin del protocolo con la funcionalidad especificada en los RFCs que
definen el funcionamiento de SNMPv1, SNMPv2 y SNMPv3; herramientas para
obtener y modificar informacin de agentes SNMP; herramientas para generar y
manejar Traps; un compilador de MIBs que se encarga de generar una plantilla de
cdigo en lenguaje C, y que implementa alguna de la funcionalidad final que tendra
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 modificacin
y la distribucin del software y su documentacin para cualquier propsito y sin
ningn 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 documentacin creada para la aplicacin. No se permite que el nombre
de ningn individuo ni institucin sea usado con fines de publicidad o anuncio sin su
previo permiso. Para informacin ms 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 POSIX
5
(Linux/BSD/Sistemas operativos tipo Unix).

El lenguaje de programacin en el que est escrito el programa es en C y en Perl.

Para ver informacin sobre la instalacin 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 operacin de las herramientas y
libreras 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 guas para que sigan
los distintos vendedores de sistemas operativos.
56
expansin de la aplicacin 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 versin de un
antivirus, utilizando la notacin 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
"Definicin de la variable para la prueba de
concepto."
::= { enterprises 1 }

test OBJECT IDENTIFIER ::= { enterprises 1 }

-- Grupos en TEST

tesis OBJECT IDENTIFIER ::= { test 1 }

-- El grupo Tesis
57

avVersion OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"La versin 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 definicin de la MIB,
se procede a compilarla con el programa que viene con la herramienta (llamado
mib2c), el cual genera el cdigo en C, que implementa esa funcionalidad. El cdigo
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
cdigo. Luego, el cdigo 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 sesin que es la encargada de llevar
todos los parmetros de la configuracin de SNMPv3. De esta manera se comunica
utilizando autenticacin (con MD5) y encripcin (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 informacin 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 Seleccin de herramientas de seguridad

Recordando que los principios de seguridad son:

58
1. Autenticacin (la forma de determinar que una entidad es lo que dice ser).
2. Control de acceso y autorizacin (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 informacin deben, en todo momento,
estar disponibles).
5. Confidencialidad (que la informacin slo sea vista por los entes
involucrados en la comunicacin y que un tercero no pueda ingresar).
6. No repudio (que algn ente que haya participado en la comunicacin no
pueda negar su participacin en ella).
7. Auditabilidad (la herramienta guarda algn tipo de registro de eventos que
han sucedido en el tiempo).

A partir de la teora se clasificaron las herramientas segn grupos que pretenden
proteger contra cierto problema de seguridad (clasificados en categoras genricas)
presente en las organizaciones. En estas clasificaciones se pueden agrupar la mayora
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 terminologa utilizada:

Spyware: es una palabra normalmente utilizada para software que soporta
publicidad. Adicionalmente es una tecnologa que ayuda a recolectar
informacin 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 bsqueda de una falla en la seguridad. Puede
monitorear eventos en busca de algunos indicios.


Tabla 1. Principios garantizados por cada grupo de aplicacin

59
Cada una de las categoras 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 ejecucin), se encuentra en peligro porque no se sabe exactamente
como fue diseado el programa. Podra abrir algn puerto y permitir el ingreso no
autorizado, podra modificar o alterar datos en el equipo o hasta podra 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 daen su disponibilidad, ya que dependiendo
del virus, podra afectar la disponibilidad de algn(os) servicio(s). Para un mayor
nivel de proteccin 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 estacin. Permite una forma de
proteccin mayor para garantizar que las personas no puedan decir que no han hecho
algo. Una forma ms proactiva de estar protegido es mediante el uso de IDSs que
permiten la deteccin 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 proteccin contra estas
caractersticas. Depende de la versin y el tipo de sistema operativo, se pueden
controlar ms o no estos principios. Se puede decir que ofrecen una primera capa de
fortalecimiento de los principios. Es difcil 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 comn: la
generacin de logs como parte de su ejecucin. Una de las caractersticas ms
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
continuacin cumplen con alguno(s) de los criterios para el desarrollo del proyecto.


Tabla 2. Caractersticas analizadas de los Anti-Spyware

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

60

Tabla 3. Caractersticas analizadas de los antivirus

En la Tabla 3 se observar un listado de programas antivirus y algunas caractersticas
interesantes para el proyecto. Se ven caractersticas como el sistema operativo que
soportan (Windows o Linux), si se ejecuta como consola o con modo grfico, 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 grfica
indica que utiliza un servicio registrado en Windows.


Tabla 4. Caractersticas analizadas de los firewalls

Algunos programas de firewalls se muestran en la Tabla 4. Se puede observar un
listado de las caractersticas de estos programas. Se ven caractersticas como el
sistema operativo que soportan (Windows o Linux), si se ejecuta como consola o con
modo grfico, si soporta logs binarios o de texto y por ltimo si estn en continua
ejecucin, 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. Caractersticas analizadas de los IDS

61
En la Tabla 5 se observar algunos IDS. Se aprecia un listado de las caractersticas de
estos programas. Se ven caractersticas como: el sistema operativo que soportan
(Windows o Linux); si se ejecuta como consola o en modo grfico; si soporta logs
binarios o de texto; si tiene un sheduler incorporado para programar scans; si soporta
ms aplicaciones, que la herramienta se puede clasificar en ms de una categora ya
que realiza otras funciones; la utilidad para el administrador de red, como le ayuda la
herramienta de esa categora a desempear su funcin y si le sirve para garantizar la
seguridad en la red; la interaccin por lnea de comandos, que permite interactuar con
la herramienta desde una consola de la lnea de comandos para poder tomar una
accin sobre ella y por ltimo si estn en continua ejecucin, ya que estos programas
protegen y alertan mientras el programa este en memoria y en ejecucin. Puede ser
interesante el firewall Kerio, que adicional a ser firewall tiene un IDS. Entendemos
por manejan los con mucha informacin si la herramienta pone mucha informacin
relevante al evento de seguridad detectado y da informacin sobre el evento.


Tabla 6. Criterios de seleccin de herramientas

En la Tabla 6 se puede observar unos criterios de seleccin con sus respectivos pesos,
que sern utilizados como parte en la seleccin 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 evaluacin y las herramientas a
utilizar. Se calcul el peso total de cada aplicacin, segn los criterios establecidos.
Vale la pena explicar un poco en que consiste la caracterstica de soporte a ms
aplicaciones. Bsicamente es que la herramienta no slo se dedica a trabajar en la
categora a la cual pertenece sino que tiene otras caractersticas que le permiten estar
en otra categora. El criterio de la utilidad para un administrador de red se vio como
lo que ms le sirve para el desarrollo de su papel. Se piensa que si se tienen buenas
polticas 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 podra llegarse a filtrar ese
62
contenido. Tanto los antivirus como los anti-spyware pueden detectar las cosas un
tiempo despus y no sera tan crucial como con los otros.

Tabla 7. Resultados de aplicar criterios a herramientas


Tabla 8. Orden de las herramientas segn su peso

El resultado de haberle puesto el peso a los criterios se observa en la Tabla 8. Segn
los criterios, vemos el orden de las herramientas segn los pesos. Llaman la atencin
Kerio, IpTables y Avast!. En especial IpTables y Kerio. Las cuales son las
herramientas que se utilizarn en el proyecto.

5.1.3 Seleccin de motor de base de datos

Debido a las caractersticas del proyecto se ha pensado en utilizar como motor de
bases de datos MySQL. Un motor que nos ofrece muy buenas caractersticas de
desempeo, precio, confiabilidad, velocidad y escalabilidad. Es uno de los motores de
bases de datos ms populares utilizados. Una de las razones ms importantes por las
cuales se decidi utilizar este motor fue para mantener los costos del proyecto muy
bajos, permitiendo su utilizacin por cualquier empresa sin importar su capacidad
63
econmica. Vale la pena aclarar que cualquier motor de bases de datos puede ser
utilizado en el modelo propuesto.

5.1.4 Anlisis del protocolo syslog

Con el fin de analizar otras posibilidades de comunicacin y de no sesgarse a la
utilizacin de solo unos recursos, se mir la posibilidad de utilizar el protocolo syslog
como medio de manipulacin 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 encargara de enviar
mensajes a la consola de seguridad. De esta forma se creara 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 ningn tipo de seguridad. Lo interesante del protocolo es que muestra un
formato de log que se debe seguir y que brinda informacin adecuada de algn
evento.

Syslog es un protocolo, definido en el RFC 3164, que permite que una mquina
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 Aplicacin: 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 podra tener una gran importancia para la aplicacin. A
su vez, no puede garantizar el orden del recibo de los mensajes, tocara disear algn
mtodo 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 ningn tipo de encripcin ni de autenticacin, algo que
64
podra ser un punto de inseguridad en la arquitectura propuesta. La falencia de estos
aspectos de seguridad, permitira que los mensajes fueran reenviados o duplicados,
permitiendo que se recibieran datos errneos o con intenciones malficas. Adicional a
todo esto, se tendra un punto de falla muy grande, ya que si por algn motivo el
servidor perdiera su disponibilidad, la consola de seguridad se vera con problemas
para poder monitorear las herramientas.

Lo que si puede llegar a ser rescatable del protocolo es el formato del mensaje. La
idea sera 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 solucin 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 trminos de la
arquitectura que son claves y deben quedar bien claros y entendidos para evitar
cualquier confusin.

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 administracin propietario de un
dispositivo, mientras que el adaptador traduce instrucciones de un ente no
administrable, como son los logs, a SNMP. Por esta razn se habla de adaptador y no
de agente SNMP Proxy. Se entiende por herramienta toda aplicacin 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 gestin.

Los incidentes de seguridad y los eventos son la unidad bsica de informacin
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 mquinas para lograr de esta
manera centralizar en un incidente todos los eventos reportados por el (los)
65
adaptador(es) de una mquina. 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
solucin. 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
informacin que puede ser utilizada en un futuro y que tambin podra 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
adems 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 ejecucin 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 ejecucin y
monitoreando la aplicacin.
4. La consola de seguridad recibe estos mensajes que le indican que el adaptador
an est en ejecucin.
5. Prepara las estadsticas para mandarle un Trap a la consola de gestin.

En general frente a un suceso de seguridad sobre una mquina van a suceder los
siguientes pasos:

66
1. La herramienta monitoreada detecta el ataque y genera las entradas
correspondientes en el log.
2. El adaptador diseado 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 informacin necesaria.
3. La consola de seguridad recibe el Trap e indica que en esa mquina estn
ocurriendo sucesos de seguridad.
4. Guarda la informacin necesaria en la base de datos y prepara las estadsticas
para mandar un Trap a la consola de gestin informndole el nombre de la
mquina, la direccin IP, el nmero 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 informacin 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 mquina el que
67
se encarga de leer el log y de actualizar el estado de los objetos definidos en su(s)
MIB(s).

Lo interesante de algunas herramientas es que se pueden programar para ejecutarse en
ciertos momentos, lo que puede solucionar el hecho de que sea el usuario quien
genera la ejecucin del programa. Otras herramientas estn en constante ejecucin
monitoreando los eventos y modificando los logs.

Es responsabilidad del adaptador notificar a la consola de seguridad, mediante una
operacin 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, segn el
criterio mencionado) y de ella sacar los campos relevantes que podran 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
especfico para la aplicacin 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 va SNMP. Es difcil dar una
arquitectura general para un analizador de logs, ya que su construccin 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 inclusin en el agente y su uso posterior dentro del cdigo.
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 implementacin de las funciones, la lgica que se encarga de
ejecutar esas tareas.

68
Es importante analizar la estructura del log y determinar los campos importantes del
log, aquellos que nos brindan ms informacin acerca del evento registrado en el log.
Luego de haber analizado el log y de haber extrado 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 mnimo a un archivo cuatro datos: el primero
es un apuntador a la ltima lnea 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 ledo
en el log. Aqu se encuentran los otros tres datos que nos interesa persistir a
un archivo: el mes, el da y la hora del evento ledo 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 ejecucin posterior no termine reportando un evento que
ocurri hace das y slo 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 aplicacin, ya que proveen mayor informacin 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 funcin, 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 funcin utilizada, llamada kerioids *readAllK(), es
la que se encarga de traer del log la siguiente lnea que debe ser procesada y retorna la
estructura con los datos correspondientes para que el agente SNMP actualice los
valores de los objetos.




69
5.2.2.1.2 Consideraciones sobre los logs

Con el fin de determinar la mejor forma de crear el modelo de seguridad, era
necesario analizar cual arquitectura era la que ms se adaptaba a nuestras necesidades
y que pudiera brindar un mejor soporte y desempeo 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 implementacin en una empresa.

Estas consideraciones que se tuvieron en cuenta para la construccin del modelo,
buscan favorecer el desempeo y confiabilidad de la aplicacin. Ellas tienen relacin
con la forma de realizar el analizador de logs y la forma de realizar las MIBs 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 consideracin que se tuvo que tener en cuenta fue la de crear un analizador de logs
genrico para los tipos de logs. Tras una larga investigacin, se pudo determinar que
no hay un estndar para los logs que manejen las aplicaciones. Es por esto que la
estructura, el formato y el tipo de archivo quedan a disposicin de los desarrolladores
de las aplicaciones y es decisin de ellos escoger la mejor aproximacin que les sirva.
Esto complica mucho la unificacin 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 tecnologa de unificar el
mundo de gestin y el de seguridad. Hecho que podra llegar a simplificar mucho el
proceso de unificacin planteado. Sera interesante la creacin 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 estndar. Se pens que
como algunos de los logs son archivos de texto, se podra tener la ayuda de un
archivo que describe la estructura del log, para que el analizador estndar 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
podran complicar tanto la construccin 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 unificacin en cuanto a la estructura de los logs. Tienen
una estructura muy particular de los campos.

En la Figura 20 se puede observar dos registros de los logs de estas dos aplicaciones.
En la Figura 20 (a) se encuentra el formato del log de la herramienta Kerio y en la
Figura 20 (b) est el de la herramienta IpTables. Se pueden observar sutilezas en el
70
registro de los campos de cada log. Por ejemplo, se puede ver el formato de la fecha
del registro de la herramienta Kerio y compararla con el de IpTables; el registro de la
MAC de IpTables, necesita de un tratamiento especial, ya que ah se encuentran tanto
la MAC de destino como la de origen. Es importante mencionar el hecho de que
IpTables guarda sus registros en el log info del kernel. Por esta razn se encuentran
no solo registros del programa, sino tambin del sistema operativo, para lo cual es
necesario implementar un medio de filtrado de los registros para poder proceder a la
extraccin 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 aplicacin 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 tambin
impide que se puedan generalizar los logs.


Figura 20. Estructura de los logs

5.2.2.1.3 Consideraciones sobre la MIB

La consideracin 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
desempeo del modelo. Analizando la arquitectura propuesta se puede ver que el
adaptador va a tener la implementacin de la MIB de cada grupo dentro del cdigo
del agente. En el agente, ms especficamente en el mdulo de la MIB incorporada al
agente, se define cada cuanto tiempo se va a llamar al analizador de logs. Por esta
razn si se tiene un agente que va a monitorear ms de una aplicacin 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 slo puede monitorear una herramienta a la vez, ya que solo puede llamar a
un analizador de logs a la vez y, adems, solo tendra una instancia de cada objeto a
monitorear, ver Figura 21 (a).
71

Este hecho puede afectar el tiempo de respuesta del agente, ya que en un instante slo
puede monitorear una herramienta. Tambin tendra que implementar cierto
algoritmo como puede ser Round Robin, para la seleccin del analizador de logs y
la asignacin del orden. Esto implica que el agente tardara en monitorear una
aplicacin, 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
pequeo como de unos cuantos KB o hasta de unos cuantos MB o ms. Es por esto
que ese tiempo de espera puede ser muy corto o tan largo como sea el tamao del
archivo. Aqu aparecera cierta demora en la monitorizacin de una determinada
aplicacin y se sacrificara ese anlisis en tiempo real. Elemento que se considera
importantsimo en herramientas IDS, firewalls o antivirus.

Lo mencionado anteriormente se puede solucionar implementando una MIB
especfica 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 aplicacin
y tambin permitiendo que el anlisis sea mucho mas cercano al tiempo de respuesta
de la aplicacin monitoreada, brindado resultados en vivo del estado de la aplicacin,
ver Figura 21 (b).


Figura 21. Implementacin de la MIB para la herramienta

Para el caso de estudio se defini la estructura de rbol de las MIBs 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 asignacin de un nmero bajo la rama
enterprises. El nodo principal de nuestro rbol es modSegSNMP (modelo de
seguridad con soporte a SNMP). Debajo de esta hay otros dos nodos: agente y
consola. Bajo la consola van a estar definidos los objetos que va a exponer a una
Adaptador Adaptador
72
herramienta de gestin y esta es la MIB que la herramienta de gestin va a conocer;
bajo el agente van a estar las MIBs 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 Construccin 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: Cules
campos brindan informacin pertinente sobre la seguridad? Luego de definir los
73
campos, se debe crear una estructura en C
6
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 aplicacin. Para ver la definicin de los objetos para una las dos herramientas
referirse al Anexo 2. Se pueden aadir campos adicionales si se desea guardar datos
adicionales. Para nuestro caso se define en ambas MIBs 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 MIBs desarrolladas en el agente remitirse al Anexo 6.

De esta forma se integra el mdulo creado, segn 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 ms en la forma en que se extendi el agente es importante
mencionar algunos aspectos relevantes del cdigo. Para el caso de prueba se utiliz la
herramienta mib2c para generar la plantilla del cdigo a utilizar para poder extender

6
Lenguaje de programacin C
74
el agente. En estos archivos aparecen funciones que vale la pena mencionar para que
sirven.

El archivo creado comienza con una funcin llamada:
void init_yy(void) //donde yy es el nombre del archivo generado por
mib2c
Esta funcin es la encargada de inicializar el mdulo que queremos implementar. En
este caso es para ipTables o kerio. Dentro de ella se van a definir las OIDs de cada
objeto de manera esttica y en formato de nmeros, ya que se debe guardar durante la
ejecucin del agente estos valores para la consulta especfica de las variables.
Tambin se encuentra la definicin 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 ms 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 funcin encargada de registrar el objeto escalar es netsnmp_register_scalar
que recibe como parmetro un apuntador a un netsnmp_handler_registration,
que tiene el registro y apunta al handler o manejador para ese objeto. La funcin
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
funcin handle_ipDate para que atienda la solicitud SNMP, para el objeto
ipDate_oid. La funcin OID_LENGTH calcula la longitud de dicho objeto. El ltimo
parmetro 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 funcin handle_ipDate, encargada de atender
solicitudes SNMP para el objeto ipDate. Su implementacin es la siguiente:

int
handle_ipDate(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
75
snmp_set_var_typed_value(requests->requestvb,
ASN_OCTET_STR,
(u_char *) data_ipDate,
strlen(data_ipDate));
break;


default:
snmp_log(LOG_ERR, "unknown mode (%d) in
handle_ipDate\n", reqinfo->mode );
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}

El switch sirve para identificar el tipo de solicitud proveniente. En este caso si es de
tipo MODE_GET, se va a llamar a la funcin snmp_set_var_typed_value, que est
encargada de manejar la obtencin del valor del objeto solicitado. Recibe como
parmetros 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 funcin importante, un poco equivalente a la vista para registrar el objeto, es una
funcin creada para registrar objetos de tipo enteros, como se ve a continuacin:

netsnmp_register_int_instance("ipStateOfInterface",
ipStateOfInterface_oid,
OID_LENGTH(ipStateOfInterface_oid),
&data_ipStateOfInterface,
handle_ipStateOfInterface);

La funcin netsnmp_register_int_instance recibe como parmetros 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 bsicas para la actualizacin de los datos del mdulo es una
funcin para registrar una alarma, para decirle al agente que cada cierto tiempo vaya
por los datos. La funcin es la siguiente:

snmp_alarm_register(1,
SA_REPEAT,
call_log_analyzer_iptables,
NULL);

La funcin snmp_alarm_register registra los callbacks que deben ocurrir cada
determinado tiempo en el futuro. Recibe como parmetros cada cuantos segundos se
debe llamar al callback, una bandera llamada SA_REPEAT que indica con cuanta
frecuencia se debe llamar al callback, en este caso, el callback registrado se va a
76
repetir cada SA_REPEAT segundos, el callback que es un apuntador a
SNMPAlarmCallback que es la funcin 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 mdulo. Por ltimo, recibe un apuntador que es usado
por la funcin callback, pero en nuestro caso no se va a utilizar, por lo cual se manda
como parmetro 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 funcin callback call_log_analyzer_iptables llama al analizador de logs y
actualiza los datos que estn actualmente en el mdulo. Adicionalmente se manda un
Trap con los datos recibidos mediante la funcin send_ipNotifyTrap_trap, que
manda una Trap al lugar especificado en el archivo de configuracin snmpd.conf en
la parte donde dice trapsess, de esta forma:

trapsess -v 3 -u nbatest -n "" -l authPriv -a MD5 -A nbaprueba -x
DES -X nbaprueba -e 0x0102030406 localhost:162

77
Que especifica que se va a mandar un Trap, con los mismos datos que se usaran en
un snmpget con versin 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 cdigo 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 tamaos y los OIDs 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 versin 2 y se libera la lista.

La funcin snmp_varlist_add_variable adiciona la dupla (objeto, valor) a la lista
de variables. Recibe como parmetros la lista de variables, el OID del objeto a
adicionar, su longitud, el tipo de dato ASN que es el objeto, el valor del objeto y su
longitud.

78
De la misma manera cuando el adaptador inicia su ejecucin se manda una Trap
informando que ese adaptador ha iniciado su ejecucin 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 accin tras una solicitud, hay que
definir en el handler de ese objeto la accin que se va a realizar, de la siguiente
manera:

int
handle_ipStateOfInterface(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
if(reqinfo->mode==MODE_SET_ACTION)
{
if(data_ipStateOfInterface==0)
{
printf("Bring down interface");
}
}

return SNMP_ERR_NOERROR;
}

Aqu se verifica si el modo de la solicitud es MODE_SET_ACTION que indica que la
solicitud es un snmpset al objeto y luego es necesario verificar si el valor de
data_ipStateOfInterface es cero, en tal caso se debe bajar la interfaz de red.

5.2.3 Arquitectura de la consola de seguridad

79

Figura 24. Arquitectura de la consola de seguridad

La Figura 24 nos muestra los componentes generales de los que se compone la
consola de seguridad. sta es la encargada de realizar acciones mediante la operacin
Set, sobre los adaptadores y tambin recibir Traps provenientes de ellos. Adems
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. Tambin debe ser capaz de escalar
notificaciones de mquinas que estn generando muchos problemas importantes y
que no han sido atendidos oportunamente en la mquina.

Adicionalmente, a la consola de seguridad se le deben informar las MIBs 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. Tambin existe la posibilidad de que descubra estos
objetos mediante unas operaciones GetNext o Walk (comando que trae en secuencia
ciertos valores en orden lexicogrfico) 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 gestin. Al agente se
le debe crear una MIB de aquellos objetos que deseamos exponer a la consola de
gestin. Adicionalmente cuenta con un receptor de Traps que se encarga de recibir
los Traps enviados desde los adaptadores para su posterior anlisis y representacin
en la consola de seguridad.
80

La consola de seguridad utiliza una base de datos para guardar informacin 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 aplicacin 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 informacin
escrita en los logs de cada una de las herramientas, lo que permite ver desde la
consola una consolidacin de los logs para as poder simplificar el proceso de
auditora y anlisis forense, procesos que necesitan de la verificacin 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 estn un nivel ms arriba en el
organigrama de la empresa.

5.2.3.1 Consola de seguridad

La consola de seguridad, diseada especficamente 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 funcin especfica.


Figura 25. Subsistemas de la consola de seguridad

81
5.2.3.1.1 Subsistema de ambiente grfico

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 aplicacin. Aqu el usuario
puede aadir o eliminar usuarios del sistema tanto para aquellos que acceden va la
consola o va Web, editar parmetros de los Traps que entran y de los que salen.
Adicionalmente puede interactuar con las mquinas y si lo desea las puede agrupar
por subredes diferentes e insertar etiquetas que las identifiquen. Se muestra
informacin del estado de las mquinas y si el usuario lo desea puede ver los
incidentes de seguridad y eventos de la mquina 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 mquinas monitoreadas. Los estados
manejados son: abierto, que indica que un incidente o evento se encuentra sin
solucin; cerrado, que indica la clausura y solucin de un incidente o evento y por
ltimo, descartado, indicando que el incidente o evento no representa un evento de
seguridad relevante. Cuando la mquina se encuentra arriba y se estn recibiendo
notificaciones de los agentes diciendo que estn vivos, se muestran los botones en
color azul (que indica que la mquina est viva); cuando los botones toman el color
blanco quiere decir que no se han vuelto a recibir ningn tipo de notificacin de ese
agente; por ltimo, cuando el botn est intermitente entre color azul y rojo, es
porque se estn recibiendo notificaciones del agente (que indica que la mquina 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 anlisis y
administracin de los eventos, incidentes de seguridad, notificaciones y estadsticas
necesarias para mantener al usuario informado. En este subsistema se procesan las
notificaciones recibidas por el subsistema de recepcin de mensajes SNMP. A partir
de estas notificaciones se administran los incidentes y eventos para esa mquina.
Cuando llega una notificacin es necesario procesar su informacin y actualizar la
base de datos con la informacin necesaria, calcular las estadsticas de las
notificaciones recibidas, notificar al subsistema de ambiente grfico que ha llegado
un nuevo mensaje para que tome la medida adecuada, tomar la decisin si es
necesario el envo de una notificacin va SMTP y por ltimo, cada cierto tiempo
preparar un mensaje para el subsistema de envo de mensajes SNMP.



82
5.2.3.1.3 Subsistema de recepcin de mensajes SNMP

Su funcin 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 notificacin es necesario analizar el contenido del Trap y
extraer la informacin relevante para el subsistema de control de incidentes de
seguridad. Una vez analizada la informacin se debe armar el mensaje para
notificrselo al subsistema de control de incidentes de seguridad y as enviarle la
informacin necesaria para que sea procesada.

5.2.3.1.4 Subsistema de envo de mensaje SNMP

Est encargado de mandar Traps informativas a una consola de gestin. Cada cierto
tiempo, cuando as lo determine el subsistema de control de incidentes de seguridad,
es necesario tomar la informacin estadstica suministrada por ese subsistema y armar
un Trap con esa informacin para que as sea enviada esta informacin a la consola
de gestin, en donde se reportar que algo ha sucedido. Este subsistema hace uso del
agente SNMP y de la MIB para poder exponer la informacin necesaria para una
consola de gestin. Esta MIB fue diseada para mostrar informacin que ha sido
analizada y filtrada por la consola de seguridad, permitiendo que la consola de
gestin vea solo estos datos porque no est dentro de su funcin la de monitorear y
recibir informacin acerca de herramientas de seguridad. Por esta razn no se
exponen los datos de las MIB de los adaptadores y tambin para evitar que la consola
de gestin reciba notificaciones que la consola de seguridad ha recibido. Lo que
quebrantara 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 informacin acerca de los
incidentes y/o eventos existe un ambiente Web por donde pueden acceder a dicha
informacin y consultar el estado de los incidentes y/o eventos de las mquinas. Este
ambiente es solamente informativo y no permite ningn tipo de interaccin con la
informacin presentada al usuario.

5.2.3.2 Modelo entidad-relacin de la base de datos utilizada

El diagrama de entidad-relacin utilizado en la consola de seguridad se muestra en la
Figura 26. Se puede observar que una mquina puede tener varios incidentes de
seguridad (en caso que tenga uno o ms 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 ejecucin de la
consola.
83


Figura 26. Diagrama entidad-relacin

5.2.3.3 Diagrama de clases de la consola de seguridad

Referirse al Anexo 9 para los diagramas de clases.
84

6 PRUEBAS

6.1 DESCRIPCIN 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 ejecucin. Por esta razn 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 an ms sus niveles de seguridad y brindar una mejor y
rpida 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 instalacin de los componentes.

La Figura 27 muestra la red utilizada para simular una red corporativa y en donde va
a correr la implementacin 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 desempeo 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 gestin que fue utilizada para validar que efectivamente la consola de
seguridad se puede comunicar con una consola de gestin, ya que debe brindar
soporte a SNMP para la integracin con una herramienta de gestin.

Las redes cuentan tanto con sistemas operativos Windows como Linux. A
continuacin se ve la configuracin 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 mquina del atacante se utiliz un programa llamado GFI LANguard Network
Security Scanner, que se encarga de detectar vulnerabilidades en los equipos, provee
informacin detallada de las mquinas 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 identificacin de puertos, deteccin de parches
instalados, deteccin de recursos compartidos, deteccin de usuarios y grupos no
85
utilizados, deteccin de vulnerabilidades CGI, deteccin de vulnerabilidades de RPC
y de correo, entre muchas otras vulnerabilidades. Algunas de las detecciones que el
enrutador impide que pasen son: descubrimiento de SNMP, escaneo de sesiones
nulas, entre otros.

Los switches utilizados son 3Com SuperStack 3 y los enrutadores son Cisco 2500 y
3600. Los concentradores utilizados fueron unos Cisco FastHub 400 series.

Se realizaron las siguientes pruebas con el modelo planteado:

1. Porcentaje de utilizacin de CPU por parte de los agentes
2. Utilizacin de la red de una herramienta comercial de gestin
3. Prueba de funcionalidad de la aplicacin: desempeo y funcionalidad
4. Medicin de la carga de red de la forma siguiente (en ambas subredes):
a. Sin agentes ni consola de seguridad en ejecucin
b. Con agentes y consola de seguridad en ejecucin, pero sin ataque
c. Con agentes y consola de seguridad en ejecucin, pero con ataque
d. Sin agentes ni consola de seguridad, pero con ataque
5. Medicin 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 utilizacin de CPU de los agentes:

1. IDS (Windows 2000):
a. Mquina 1 (subred 1): oscila entre 0% y 2%, segn mediciones del
sistema operativo
b. Mquina 2 (subred 2): oscila entre 0% y 3%, segn mediciones del
sistema operativo
2. Firewall (Linux Mandrake 10):
a. Mquina 1 (subred 1): utilizacin de 6%, segn mediciones del
sistema operativo
b. Mquina 2 (subred 2): utilizacin de 9%, segn mediciones del
sistema operativo
86



Figura 27. Diagrama de la red de prueba utilizada

87

Las mediciones de la utilizacin 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
mquinas, son los que vienen por defecto tras la instalacin de cada uno de los
sistemas operativos. Adicionalmente, en las mquinas de Windows 2000 se estaba
ejecutando el IDS (Kerio) y el agente. Por otro lado, en las mquinas con Linux se
estaba ejecutando Webmin, IpTables y el agente.

2) Utilizacin de la red de una herramienta comercial de gestin:

Antes de entrar a este punto es importante mostrar la carga de la red sin ninguna
herramienta de gestin ni de seguridad en ejecucin. La Figura 28 muestra los
resultados obtenidos con una duracin de la medida de aproximadamente de 10
minutos (en la subred 1). Teniendo en cuenta la velocidad de la tarjeta de red de la
mquina que realiz las mediciones en la subred 1 que es de 100 Mbps se puede
calcular la utilizacin (el porcentaje del ancho de banda disponible utilizado). En este
caso la utilizacin promedio es de 0.0005% aproximadamente.


Figura 28. Utilizacin 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 fcilmente 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 tambin 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
mandara el agente. En la Figura 29 se puede observar la carga en la red bajo la
ejecucin de la herramienta de gestin con una duracin de la medida de
aproximadamente de 10 minutos en la misma subred. En este caso la utilizacin
promedio es de 0.0006% aproximadamente.

88

Figura 29. Utilizacin de la red en la subred 1

3) Prueba de funcionalidad de la aplicacin: desempeo 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. Mquina 1: 5 entradas en el log y 5 eventos en la base de datos
b. Mquina 2: 5 entradas en el log y 5 eventos en la base de datos
b. Firewall (Linux Mandrake 10):
c. Mquina 1: 846 entradas en el log y 362 eventos en la base de datos
d. Mquina 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 mquina 1
y de la mquina 2 reportaron el 42.8% y 78.6% de eventos respectivamente.

Se realizaron pruebas adicionales para determinar la causa en la prdida de eventos
no notificados. Una de las causas que lo afecta es el tiempo de procesamiento y de
notificacin de los eventos, en primer lugar, la velocidad a la que funcionan los
lenguajes de programacin utilizados: C y Java, siendo el segundo un poco ms lento
por su velocidad de procesamiento. En segundo lugar, se observa que hubo ms
prdidas de eventos notificados en las mquinas que deban mandar los Traps de una
subred a otra, razn por la cual es muy importante el ancho de banda y la velocidad a
la que se comunican los enrutadores. En la mquina 2 hay menos entradas en el log
que en la mquina 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 mquinas 1 y 2 se hicieron reportando por grupos de notificaciones de 100
eventos; las pruebas 3 y 4 de ambas mquinas 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 nmero 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 envo de notificaciones
89
incluyendo algn tipo de inteligencia en el agente que pudiera decidir que notificar
y que no y que decida lo que es relevante aadir al grupo de notificaciones.

Mquina 1 Mquina 2
Prueba Log BD % Prueba Log BD %
1 863 436 50.5 1 84 68 80.9
2 865 438 50.6 2 95 72 75.8
3 858 589 68.6 3 83 74 89.1
4 870 606 69.6 4 87 76 87.3
5 861 857 99.5 5 91 88 96.7
6 867 863 99.5 6 93 91 97.8
Tabla 9. Porcentaje de notificacin de eventos en el log

4) Medicin de la carga de red en estas condiciones (en ambas subredes):

a. Sin agentes ni consola de seguridad en ejecucin:

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


(a) Subred 1

90

(b) Subred 2
Figura 30. Utilizacin de la red

b. Con agentes y consola de seguridad en ejecucin, pero sin ataque:

En esta prueba se puede observar la utilizacin 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 utilizacin en la subred 1, mientras que
en la Figura 31 (b) se observa la utilizacin en la subred 2 con una duracin de la
medida de aproximadamente de 10 minutos. La ltima grfica 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
ejecucin 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 duracin de aproximadamente 10 segundos. En la
Figura 31 (c) podemos observar el trfico generado en la subred 1, que a
diferencia de la figura (a), fue medida utilizando un concentrador, para que no
tuviramos problemas en la medicin debido a los dominios de colisin de un
switch. En este caso la utilizacin promedio aproximada para la Figura 31 (a) es
de 0.0005%, de 0.03% para la (b) y de 0.0009% para la (c).



(a) Subred 1

91

(b) Subred 2


(c) Subred 1
Figura 31. Utilizacin de la red

c. Con agentes y consola de seguridad en ejecucin, pero con ataque:

El siguiente paso en las pruebas es probar el desempeo de la red bajo el efecto de
un ataque sobre los equipos que estn monitoreando los agentes, utilizando los
switches. En la Figura 32 (a) se observa la utilizacin en la subred 1, mientras que
en la Figura 32 (b) se muestra la utilizacin en la subred 2 con una duracin de la
medida de aproximadamente de 15 minutos. En este caso la utilizacin promedio
aproximada durante la duracin del ataque es para la Figura 32 (a) de 0.03% y de
1.5% para la grfica (b). El ataque hacia todos los equipos tuvo una duracin de
dos minutos y treinta segundos aproximadamente. La Figura 32 (b) tiene una
utilizacin del 1.5% ya que en la subred 2 se encuentra la consola de seguridad lo
que genera en esa subred ms trfico que el de un ataque normal, debido a las
notificaciones de los eventos por parte de los agentes en ambas subredes.


(a) Subred 1

92

(b) Subred 2
Figura 32. Utilizacin de la red

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

Para poder determinar el trfico 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 mquinas con los agentes monitoreando, pero esta vez no
van a estar corriendo los agentes para no generar el trfico adicional. En la Figura
33 (a) se puede ver la utilizacin en la subred 1, mientras que en la Figura 33 (b)
se observa la utilizacin en la subred 2, resultado que corresponde a una medicin
en la mquina donde se tomaron las medidas. La duracin de la medida fue de
aproximadamente de 10 minutos. La Figura 33 (c) muestra la utilizacin en la
subred 2 utilizando un concentrador, lo que muestra un resultado de medida total
de la subred. En este caso la utilizacin promedio aproximada durante el ataque
para la Figura 33 (a) es de 0.05%, de 0.004% para la (b) y de 0.15% para la (c).


(a) Subred 1


(b) Subred 2

93

(c) Subred 2
Figura 33. Utilizacin de la red

5) Medicin de la carga soportada por la consola de seguridad:

Esta prueba se realiz con el fin de determinar que tanta carga de informacin (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 cuntos 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 mquinas monitoreadas y por ende se genera un gran nmero 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 adems debe ser almacenada la informacin en la
base de datos. Otro factor que entra en consideracin es la velocidad con la que se
procesan las instrucciones de la aplicacin 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 rfagas 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
informacin como si fueran envidos desde los adaptadores.

Es importante mencionar que debido a la implementacin de los adaptadores el
mximo nmero 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 trfico desde
una estacin hacia la consola de seguridad. Se configuraron los Traps de la misma
manera a como los enviara un adaptador.

La Figura 34 muestra el trfico normal de la red.

94

Figura 34. Trfico 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 informacin 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 aplicacin 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. Grficas del envo de un gran nmero de Traps a la consola

6.3 RESULTADOS DE LAS PRUEBAS

Como se puede observar, la utilizacin de CPU de los agentes es considerablemente
baja, lo cual no causa ninguna interferencia con el desempeo normal de la mquina,
ya que no consume recursos significativos.

95
Por otro lado, la carga adicional generada sobre la red debido a la utilizacin 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 ejecucin se
genera una utilizacin de menos de 0.001%. Que comparado con una herramienta de
gestin comercial, que tiene una utilizacin de 0.0006%, es muy similar, lo que nos
indica que la utilizacin 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 notificacin de eventos, carga que depende del
tipo de ataque realizado y del nmero de mquinas atacadas. Comportamiento
esperado durante un ataque.

La ltima prueba realizada permiti determinar el mximo nmero de Traps que la
consola de seguridad es capaz de recibir hasta dejar de funcionar. Segn 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 razn se puede decir que la consola soporta hasta
100 adaptadores aproximadamente. Para mejorar estos resultados puede ser necesaria
la utilizacin de un balanceador de carga y de un procesamiento distribuido de la
informacin 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 informacin
recibida se va a hacer en forma distribuida. Permitiendo que de esta manera la
consola de seguridad consolide toda esta informacin. Recordemos que este anlisis
es para el peor caso y se espera que solo suceda en condiciones extremas de ataques
similares a DDoS, sin embargo no se podran procesar ms de 2500 Traps.

En las pruebas realizadas se ve la importancia de utilizar switches con contraposicin
a los concentradores. La caracterstica principal de los switches es la de separar las
mquinas o subredes en dominios de colisin. La idea de los dominios de colisin es
separar el trfico entre cada uno de ellos. Es decir que en un dominio de colisin no
se va a ver ningn trfico proveniente de otros dominios, disminuyendo la cantidad
de trfico que va a estar fluyendo hacia otras mquinas o subredes. Caso que se ve
perfectamente ilustrado en las Figuras 31 (a) y 33 (b) donde no se ve el trfico que se
genera en los otros dominios y es por esto que no se pudo medir y fue necesario la
utilizacin de un concentrador. De aqu surge la importancia de utilizar los switches
antes de los concentradores.
96

7 CONCLUSIONES

El modelo de seguridad propuesto puede ser utilizado sin importar el costo de las
herramientas de gestin de red (ya que soporta cualquier herramienta para la
integracin 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 unificacin de la gestin de red y de seguridad es posible mediante la utilizacin
del protocolo de aplicacin SNMP, que, mediante la versin 3 se garantiza
confidencialidad, autenticacin, encripcin 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 envan los agentes.

Bajo este hecho se logra consolidar un modelo que permite plantear la integracin de
la gestin de red y de la seguridad de la red de una manera muy segura y que va a
permitir facilitar la administracin de los recursos de red, en ambos niveles, sean
elementos de gestin o de seguridad.

Los patrones de ataques identifican que un atacante normalmente accede una serie de
mquinas hasta llegar a la vctima, en donde puede tratar de violentar el sistema
mediante la explotacin de alguna vulnerabilidad del sistema operativo o de alguna
aplicacin que se est ejecutando en el equipo. En este caso es de suma importancia
poder detectar de una manera centralizada el patrn 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 mquinas o elementos de red utilizados, procedimiento arduo y que
consume mucho tiempo del administrador de la red, tiempo que podra ser utilizado
en otras actividades. Mediante la utilizacin de un modelo de seguridad como el
propuesto, es posible hacer que el proceso de consolidacin y auditoria de logs sea
mucho ms 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 drsticamente el tiempo de
respuesta ante un incidente distribuido en toda la red monitoreada.

Adicionalmente se provee la utilizacin de procedimientos en los incidentes de
seguridad y eventos que permiten detallar exactamente lo sucedido y la accin
tomada para su solucin. Se permite guardar un histrico de los hechos que han
acontecido en la red, mediante los incidentes de cada una de las mquinas.

97
El uso de los incidentes y eventos le da al modelo una riqueza mayor. A partir de la
secuencia de eventos se pueden construir herramientas que analicen esos datos y
detecten en ellos nuevos patrones de ataques y hasta nuevas firmas que podran 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 auditoras e inclusive procesos de anlisis forense.
Adicionalmente, los procedimientos para la solucin de los eventos se pueden utilizar
para la creacin de documentos que pueden servirle a la empresa como capacitacin,
entrenamiento o documentacin 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 solucin del nuevo incidente.

Para que este modelo sea ms efectivo los proveedores de las herramientas de
seguridad deben poner en los logs la mayor cantidad de informacin de un evento
para que su aporte sea an ms y permita notificar ms informacin relevante de cada
hecho. Con el fin de alcanzar este objetivo, es importante tender a una
estandarizacin de los logs, de tal forma que todos los desarrolladores de
herramientas de seguridad tiendan a utilizar este estndar y as facilitar la integracin
de las herramientas de seguridad. Tambin 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 ningn registro o
ninguna notificacin de un evento importante.

Es bien importante que los desarrolladores de las herramientas de seguridad incluyan
otros medios de notificacin como por ejemplo va 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 aplicacin desarrollada un agente SNMP que
genere alertas va este protocolo para que de esta forma se pueda integrar con mayor
facilidad la gestin de red y de seguridad, seguramente, sin la necesidad de una
consola de seguridad. Para lograr esto es necesario guiarse por algn estndar de
manera que junto con los otros desarrolladores se cierre con mayor facilidad la brecha
entre la gestin de red y seguridad.
98


Figura 36. Estructura de un mensaje SNMPv3
99

8 CONTINUIDAD DEL PROYECTO

8.1 POSIBLES TRABAJOS FUTUROS

1. Plantear un estndar para que la generacin de logs se aplique a las
herramientas, mediante la utilizacin de estndares 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 librera a incluir dentro de otro
desarrollo para que nuestra arquitectura sirva de plataforma para proyectos
futuros y as puedan utilizarla independiente de nuestra implementacin. De
esta forma nuestra arquitectura puede ser una capa ms en otra arquitectura.

3. Mediante la integracin de los logs, poder hacerle un seguimiento cronolgico
a un atacante que accede a una serie de mquinas hasta ingresar a su objetivo
y determinar su patrn 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
trfico 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 anlisis
con base en las herramientas de seguridad y debe ser capaz de tomar
decisiones sobre lo que analiza.

6. Implementar un mtodo de filtrado de mensajes en la consola de seguridad
para evitar que se guarden en los incidentes mensajes de tipos de trficos
similares a los ya existentes, para evitar que se vean eventos iguales y que la
base de datos se sature de informacin duplicada, pero que quede registrado
que ha habido eventos subsiguientes. Por ejemplo bajo un ataque DoS.

7. Crear una herramienta que haga el anlisis de datos para determinar
estadsticas de ataques. Como por ejemplo la mquina que ms ha sido
100
infectada con virus, los virus ms abundantes en la red, tipos de ataques que
ha recibido una mquina, usuarios ms peligrosos, entre otras estadsticas.

8. Desarrollar un mecanismo para manejar la distribucin de la carga en varios
puntos de procesamiento de la informacin que necesita la consola de
seguridad. De esta forma se puede mejorar el rendimiento y el soporte de ms
adaptadores del modelo propuesto.
101

BIBLIOGRAFIA

[1] La proactividad: clave de la gestin de red, disponible en:
http://www.redestelecom.com/Actualidad/An%C3%A1lisis/Comunicaciones/Telefon
%C3%ADa/20030731011

[2] Herrez, M Blanca. Introduccin a los sistemas de gestin de red, disponible
en: http://www.info-ab.uclm.es/asignaturas/42621/transpas/dmrTema1x1.pdf

[3] M Blanca Herrez. Herramientas de gestin de red, disponible en:
http://www.info-ab.uclm.es/asignaturas/42621/transpas/dmrTema6x2.pdf

[4] Northcutt, Stephen. Gua avanzada: Deteccin de intrusos, 2 edicin, Madrid,
2001.

[5] Zielger, Robert L. Gua avanzada: Firewalls Linux, 1 edicin, 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. Gestin de red, Edicions OPC, Universita Politcnica de
Catalunya, Espaa, 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 edicin,
Addison Wesley, 1999.

[11] Perkins, David T. Understanding SNMP MIBs, 1993

[12] How to Eliminate Spyware to Protect Your Business, disponible en:
http://ca.com/smb/howcani/eliminate_spyware.pdf

[13] Information Security 101: Security for Newbies, disponible en:
http://www.sans.org/rr/whitepapers/basics/444.php

[14] GIAC Security Essentials Certifications (GSEC) Practical Assignment,
disponible en: http://www.sans.org/rr/whitepapers/basics/1071.php
102

[15] Protecting the Network without Breaking the Bank, disponible en:
http://www.sans.org/rr/whitepapers/firewalls/809.php

[16] Security in Practice- Reducing the Effort, disponible en:
http://www.sans.org/rr/whitepapers/bestprac/1106.php

[17] Threats to Enterprise Security, disponible en:
http://www.securitydocs.com/library/3211

[18] Spyware and Adware Threats and Countermeasures, disponible en:
http://www.finjan.com/company/whitepapers/Spyware_White_Paper.pdf

[19] Especificado en la recomendacin X.690 y X.691 de la ITU-T

[20] RFC 2271 - An Architecture for Describing SNMP Management Frameworks,
disponible en: http://www.ietf.org/rfc/rfc2271.txt

[21] RFC 3164 - The BSD syslog Protocol, disponible en:
http://www.ietf.org/rfc/rfc3164.txt



103

ANEXO 1: TRMINOS DE LICENCIAMIENTO

Various copyrights apply to this package, listed in various separate
parts
below. Please make sure that you read all the parts. Up until
2001,
the project was based at UC Davis, and the first part covers all
code
written during this time. From 2001 onwards, the project has been
based at SourceForge, and Networks Associates Technology, Inc hold
the
copyright on behalf of the wider Net-SNMP community, covering all
derivative work done since then. An additional copyright section
has
been added as Part 3 below also under a BSD license for the work
contributed by Cambridge Broadband Ltd. to the project since 2001.
An additional copyright section has been added as Part 4 below also
under a BSD license for the work contributed by Sun Microsystems,
Inc.
to the project since 2003.

Code has been contributed to this project by many people over
the years it has been in development, and a full list of
contributors
can be found in the README file under the THANKS section.


---- Part 1: CMU/UCD copyright notice: (BSD like) -----


Copyright 1989, 1991, 1992 by Carnegie Mellon University

Derivative Work - 1996, 1998-2000
Copyright 1996, 1998-2000 The Regents of the University of
California

All Rights Reserved

Permission to use, copy, modify and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appears in all copies and
that both that copyright notice and this permission notice appear in
supporting documentation, and that the name of CMU and The Regents
of
the University of California not be used in advertising or publicity
pertaining to distribution of the software without specific written
permission.

CMU AND THE REGENTS OF THE UNIVERSITY OF CALIFORNIA DISCLAIM ALL
WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL CMU OR
104
THE REGENTS OF THE UNIVERSITY OF CALIFORNIA BE LIABLE FOR ANY
SPECIAL,
INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING
FROM THE LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.


---- Part 2: Networks Associates Technology, Inc copyright notice
(BSD) -----

Copyright (c) 2001-2003, Networks Associates Technology, Inc
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
notice,
this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the
documentation and/or other materials provided with the
distribution.

* Neither the name of the Networks Associates Technology, Inc nor
the
names of its contributors may be used to endorse or promote
products derived from this software without specific prior
written
permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS
IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF
105
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

---- Part 3: Cambridge Broadband Ltd. copyright notice (BSD) -----

Portions of this code are copyright (c) 2001-2003, Cambridge
Broadband Ltd.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
notice,
this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the
documentation and/or other materials provided with the
distribution.

* The name of Cambridge Broadband Ltd. may not be used to endorse
or
promote products derived from this software without specific
prior
written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER ``AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


---- Part 4: Sun Microsystems, Inc. copyright notice (BSD) -----

Copyright 2003 Sun Microsystems, Inc., 4150 Network Circle, Santa
Clara,
California 95054, U.S.A. All rights reserved.

Use is subject to license terms below.

This distribution may include materials developed by third parties.

106
Sun, Sun Microsystems, the Sun logo and Solaris are trademarks or
registered
trademarks of Sun Microsystems, Inc. in the U.S. and other
countries.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
notice,
this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the
documentation and/or other materials provided with the
distribution.

* Neither the name of the Sun Microsystems, Inc. nor the
names of its contributors may be used to endorse or promote
products derived from this software without specific prior
written
permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS
IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

---- Part 5: Sparta, Inc copyright notice (BSD) -----

Copyright (c) 2003-2004, Sparta, Inc
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

107
* Redistributions of source code must retain the above copyright
notice,
this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the
documentation and/or other materials provided with the
distribution.

* Neither the name of Sparta, Inc nor the names of its contributors
may
be used to endorse or promote products derived from this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS
IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

---- Part 6: Cisco/BUPTNIC copyright notice (BSD) -----

Copyright (c) 2004, Cisco, Inc and Information Network
Center of Beijing University of Posts and Telecommunications.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
notice,
this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the
documentation and/or other materials provided with the
distribution.
108

* Neither the name of Cisco, Inc, Beijing University of Posts and
Telecommunications, nor the names of their contributors may
be used to endorse or promote products derived from this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
``AS
IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

109

ANEXO 2: ESTRUCTURA DE UNA MIB

APPLICATION-MIB DEFINITIONS ::= BEGIN

IMPORTS
DisplayString FROM RFC1213-MIB
MODULE-IDENTITY, OBJECT-TYPE, enterprises FROM SNMPv2-SMI;

modSeg MODULE-IDENTITY
LAST-UPDATED "0502031400Z"
ORGANIZATION "Proyecto de Investigacin"
CONTACT-INFO
" Nicols Botero A.

Director: Enrique Ruiz.

Pontificia Universidad Javeriana
Ingeniera de sistemas

e-mail: nbotero@javeriana.edu.co"
DESCRIPTION
"Modulo MIB que contendra las MIB's de las herramientas a
monitorear."
REVISION "0502031400Z"
DESCRIPTION
"Definicin de la estructura en el rbol."
::= { modSegSNMP 3 }

modSegSNMP OBJECT IDENTIFIER ::= { enterprises 1 }

agente OBJECT IDENTIFIER ::= { modSegSNMP 1 }

consola OBJECT IDENTIFIER ::= { modSegSNMP 2 }

END



KERIO-MIB DEFINITIONS ::= BEGIN

IMPORTS
DisplayString FROM RFC1213-MIB
MODULE-IDENTITY, OBJECT-TYPE, enterprises FROM SNMPv2-SMI
agente FROM APPLICATION-MIB;

modSeg MODULE-IDENTITY
LAST-UPDATED "0502031400Z"
ORGANIZATION "Proyecto de Investigacin"
CONTACT-INFO
" Nicols Botero A.

Pontificia Universidad Javeriana
Ingeniera de sistemas

e-mail: nbotero@javeriana.edu.co"
DESCRIPTION
"Modulo MIB para monitorear el IDS de la aplicacin Kerio."
REVISION "0502031400Z"
DESCRIPTION
"Implementacin de los objetos que se van a monitorear de la
aplicacin Kerio."
::= { enterprises 1 }
110

kerio OBJECT IDENTIFIER ::= { agente 1 }


kDate OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"La fecha del registro en el log de la aplicacin."
::= { kerio 1 }

kTime OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"La hora del registro en el log de la aplicacin."
::= { kerio 2 }

kHost OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"El nombre del equipo en donde se est ejecutando la aplicacin."
::= { kerio 3 }

kActionTaken OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"La accin que tom la aplicacin cuando sucedi el evento registrado
en el log."
::= { kerio 4 }

kRemoteAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Direccin 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 aplicacin."
::= { kerio 6 }

kDirection OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Direccin que tuvo el evento registrado en el log. Puede ser originada
hacia el equipo o desde el equipo."
::= { kerio 7 }

kClassification OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
111
"La clasificacin que le asign la aplicacin al evento ocurrido. Es el
nombre bajo el que se clasific el evento. Normalmente
y segn el tipo de ataque, se puede clasificar en determinadas
categoras."
::= { kerio 8 }

kPriority OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"La prioridad (importancia o relevancia) que le asign la palicacin al
evento."
::= { kerio 9 }

kStateOfInterface OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DEFVAL { 1 }
DESCRIPTION
"El estado en el que se encuentra la interface que conecta el equipo a
la red. Arriba (1) y abajo (0)."
::= { kerio 10 }

END
112

ANEXO 3: IMPLEMENTACIN DE UNA MIB

#include <net-snmp/net-snmp-config.h>
#include <net-snmp/net-snmp-includes.h>
#include <net-snmp/agent/net-snmp-agent-includes.h>
#include "kerio.h"
#include "kerioLogAnalyzer.h"

static char *data_kDate="";
static char *data_kTime="";
static char *data_kHost="";
static char *data_kActionTaken="";
static char *data_kRemoteAddress="";
static char *data_kMessage="";
static char *data_kDirection="";
static char *data_kClassification="";
static char *data_kPriority="";
static int data_kStateOfInterface=1;

#define SYS_STRING_LEN 256
char version_descr1[SYS_STRING_LEN] = VERS_DESC;
char sysName1[SYS_STRING_LEN] = SYS_NAME;

void
init_kerio(void)
{
static oid kDate_oid[] = { 1,3,6,1,4,1,1,1,1,1 };
static oid kTime_oid[] = { 1,3,6,1,4,1,1,1,1,2 };
static oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3 };
static oid kActionTaken_oid[] = { 1,3,6,1,4,1,1,1,1,4 };
static oid kRemoteAddress_oid[] = { 1,3,6,1,4,1,1,1,1,5 };
static oid kMessage_oid[] = { 1,3,6,1,4,1,1,1,1,6 };
static oid kDirection_oid[] = { 1,3,6,1,4,1,1,1,1,7 };
static oid kClassification_oid[] = { 1,3,6,1,4,1,1,1,1,8 };
static oid kPriority_oid[] = { 1,3,6,1,4,1,1,1,1,9 };
static oid kStateOfInterface_oid[] = { 1,3,6,1,4,1,1,1,1,10,0 };

data_kDate=(char *)malloc(sizeof(char *) + 1);
data_kTime=(char *)malloc(sizeof(char *) + 1);
data_kHost=(char *)malloc(sizeof(char *) + 1);
data_kActionTaken=(char *)malloc(sizeof(char *) + 1);
data_kRemoteAddress=(char *)malloc(sizeof(char *) + 1);
data_kMessage=(char *)malloc(sizeof(char *) + 1);
data_kDirection=(char *)malloc(sizeof(char *) + 1);
data_kClassification=(char *)malloc(sizeof(char *) + 1);
data_kPriority=(char *)malloc(sizeof(char *) + 1);

readFileK();

#ifdef HAVE_UNAME
struct utsname utsName;
uname(&utsName);
snprintf(version_descr1, sizeof(version_descr1),
"%s %s %s %s %s", utsName.sysname,
utsName.nodename, utsName.release, utsName.version,
utsName.machine);
version_descr1[ sizeof(version_descr1)-1 ] = 0;
#else
#if HAVE_EXECV
struct extensible extmp;
sprintf(extmp.command, "%s -a", UNAMEPROG);
extmp.type = EXECPROC;
extmp.next = NULL;
113
exec_command(&extmp);
strncpy(version_descr1, extmp.output, sizeof(version_descr1));
version_descr1[sizeof(version_descr1) - 1] = 0;
version_descr1[strlen(version_descr1) - 1] = 0; #else
#endif
#endif
#ifdef HAVE_GETHOSTNAME
gethostname(sysName1, sizeof(sysName1));
#else
#ifdef HAVE_UNAME
strncpy(sysName1, utsName.nodename, sizeof(sysName1));
#else
#if HAVE_EXECV
sprintf(extmp.command, "%s -n", UNAMEPROG);
extmp.type = EXECPROC;
extmp.next = NULL;
exec_command(&extmp);
strncpy(sysName1, extmp.output, sizeof(sysName1));
sysName1[strlen(sysName1) - 1] = 0;
#else
strcpy(sysName1, "unknown");
#endif /* HAVE_EXECV */
#endif /* HAVE_UNAME */
#endif /* HAVE_GETHOSTNAME */
strcpy(data_kHost,sysName1);

DEBUGMSGTL(("kerio", "Initializing\n"));

netsnmp_register_scalar(
netsnmp_create_handler_registration("kDate", handle_kDate,
kDate_oid, OID_LENGTH(kDate_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kTime", handle_kTime,
kTime_oid, OID_LENGTH(kTime_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kHost", handle_kHost,
kHost_oid, OID_LENGTH(kHost_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kActionTaken", handle_kActionTaken,
kActionTaken_oid, OID_LENGTH(kActionTaken_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kRemoteAddress", handle_kRemoteAddress,
kRemoteAddress_oid, OID_LENGTH(kRemoteAddress_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kMessage", handle_kMessage,
kMessage_oid, OID_LENGTH(kMessage_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kDirection", handle_kDirection,
kDirection_oid, OID_LENGTH(kDirection_oid),
HANDLER_CAN_RONLY
));
netsnmp_register_scalar(
netsnmp_create_handler_registration("kClassification", handle_kClassification,
kClassification_oid, OID_LENGTH(kClassification_oid),
HANDLER_CAN_RONLY
));
114
netsnmp_register_scalar(
netsnmp_create_handler_registration("kPriority", handle_kPriority,
kPriority_oid, OID_LENGTH(kPriority_oid),
HANDLER_CAN_RONLY
));

netsnmp_register_int_instance("kStateOfInterface",
kStateOfInterface_oid,
OID_LENGTH(kStateOfInterface_oid),
&data_kStateOfInterface,
handle_kStateOfInterface);

snmp_alarm_register(5,
SA_REPEAT,
call_log_analyzer_kerio,
NULL
);

snmp_alarm_register(60,
SA_REPEAT,
call_no_news_kerio,
NULL
);

snmp_alarm_register(1,
0,
call_startup_kerio,
NULL
);
}

int
handle_kDate(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kDate,
strlen(data_kDate));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kDate\n", reqinfo->mode );
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kTime(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kTime,
strlen(data_kTime));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kTime\n", reqinfo->mode );
115
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kHost(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kHost,
strlen(data_kHost));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kHost\n", reqinfo->mode );
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kActionTaken(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kActionTaken,
strlen(data_kActionTaken));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kActionTaken\n", reqinfo-
>mode );
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kRemoteAddress(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kRemoteAddress,
strlen(data_kRemoteAddress));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kRemoteAddress\n", reqinfo-
>mode );
return SNMP_ERR_GENERR;
}

116
return SNMP_ERR_NOERROR;
}
int
handle_kMessage(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kMessage,
strlen(data_kMessage));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kMessage\n", reqinfo->mode
);
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kDirection(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kDirection,
strlen(data_kDirection));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kDirection\n", reqinfo-
>mode );
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kClassification(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kClassification,
strlen(data_kClassification));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kClassification\n",
reqinfo->mode );
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
117
int
handle_kPriority(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
switch(reqinfo->mode) {

case MODE_GET:
snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,
(u_char *) data_kPriority,
strlen(data_kPriority));
break;

default:
snmp_log(LOG_ERR, "unknown mode (%d) in handle_kPriority\n", reqinfo->mode
);
return SNMP_ERR_GENERR;
}

return SNMP_ERR_NOERROR;
}
int
handle_kStateOfInterface(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
netsnmp_request_info *requests)
{
if(reqinfo->mode==MODE_GET)
{
snmp_set_var_typed_value(requests->requestvb, ASN_INTEGER,
(u_char *) &data_kStateOfInterface,
sizeof(data_kStateOfInterface));
}

if(reqinfo->mode==MODE_SET_ACTION)
{
if(data_kStateOfInterface==0)
{
printf("Bring down interface");
system("ipconfig /release");
}
}

return SNMP_ERR_NOERROR;
}

void
call_log_analyzer_kerio(unsigned int clientreg, void *clientarg)
{
struct kerioIds *data;
int i=0;
data=(struct kerioIds *) calloc(1, sizeof(struct kerioIds));
data->rdate=(struct CDate *) calloc(1, sizeof(struct CDate));

strcpy(data->action,"a");
data=readAllK();
if(strcmp(data->action,"")!=0)
{
strcpy(data_kDate,data->rdate->date);
strcpy(data_kTime,data->rdate->time);
strcpy(data_kActionTaken,data->action);
strcpy(data_kRemoteAddress,data->raddr);
strcpy(data_kMessage,data->msg);
strcpy(data_kDirection,data->direc);
strcpy(data_kClassification,data->class1);
data->priority[strlen(data->priority)-1]='\0';
strcpy(data_kPriority,data->priority);
118
send_kNotifyTrap_trap();
}
}

void
call_no_news_kerio(unsigned int clientreg, void *clientarg)
{
char name[SYS_STRING_LEN] = SYS_NAME;
char *tmp_kDate="99/Dec/9999";
netsnmp_variable_list *var_list = NULL;
oid kNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,1,11,1 };
size_t kNotifyTrap_oid_len = OID_LENGTH(kNotifyTrap_oid);

oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 };
size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap);

oid kDate_oid[] = { 1,3,6,1,4,11,1,1,1,0 };
size_t kDate_oid_len = OID_LENGTH(kDate_oid);

oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3,0 };
size_t kHost_oid_len = OID_LENGTH(kHost_oid);

gethostname(name, sizeof(name));

snmp_varlist_add_variable(&var_list,
objid_snmptrap, objid_snmptrap_len,
ASN_OBJECT_ID,
(u_char *) kNotifyTrap_oid, kNotifyTrap_oid_len * sizeof(oid));

snmp_varlist_add_variable(&var_list,
kDate_oid, kDate_oid_len,
ASN_OCTET_STR,
tmp_kDate, strlen(tmp_kDate));

snmp_varlist_add_variable(&var_list,
kHost_oid, kHost_oid_len,
ASN_OCTET_STR,
name, strlen(name));

send_v2trap( var_list );
snmp_free_varbind( var_list );
}

void
call_startup_kerio(unsigned int clientreg, void *clientarg)
{
char name[SYS_STRING_LEN] = SYS_NAME;
char *tmp_kDate="STARTUP";
netsnmp_variable_list *var_list = NULL;
oid kNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,1,11,1 };
size_t kNotifyTrap_oid_len = OID_LENGTH(kNotifyTrap_oid);

oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 };
size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap);

oid kDate_oid[] = { 1,3,6,1,4,11,1,1,1,0 };
size_t kDate_oid_len = OID_LENGTH(kDate_oid);

oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3,0 };
size_t kHost_oid_len = OID_LENGTH(kHost_oid);

gethostname(name, sizeof(name));

snmp_varlist_add_variable(&var_list,
objid_snmptrap, objid_snmptrap_len,
ASN_OBJECT_ID,
(u_char *) kNotifyTrap_oid, kNotifyTrap_oid_len * sizeof(oid));

119
snmp_varlist_add_variable(&var_list,
kDate_oid, kDate_oid_len,
ASN_OCTET_STR,
tmp_kDate, strlen(tmp_kDate));

snmp_varlist_add_variable(&var_list,
kHost_oid, kHost_oid_len,
ASN_OCTET_STR,
name, strlen(name));

send_v2trap( var_list );
snmp_free_varbind( var_list );
}

int
send_kNotifyTrap_trap( void )
{
char *name="Kerio Personal Firewall";
char *type="IDS";
char *version="4.1";
netsnmp_variable_list *var_list = NULL;
oid kNotifyTrap_oid[] = { 1,3,6,1,4,1,1,1,1,11,1 };
size_t kNotifyTrap_oid_len = OID_LENGTH(kNotifyTrap_oid);

oid objid_snmptrap[] = { 1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 };
size_t objid_snmptrap_len = OID_LENGTH(objid_snmptrap);

oid kDate_oid[] = { 1,3,6,1,4,11,1,1,1,0 };
size_t kDate_oid_len = OID_LENGTH(kDate_oid);

oid kTime_oid[] = { 1,3,6,1,4,1,1,1,1,2,0 };
size_t kTime_oid_len = OID_LENGTH(kTime_oid);

oid kHost_oid[] = { 1,3,6,1,4,1,1,1,1,3,0 };
size_t kHost_oid_len = OID_LENGTH(kHost_oid);

oid kActionTaken_oid[] = { 1,3,6,1,4,1,1,1,1,4,0 };
size_t kActionTaken_oid_len = OID_LENGTH(kActionTaken_oid);

oid kRemoteAddress_oid[] = { 1,3,6,1,4,1,1,1,1,5,0 };
size_t kRemoteAddress_oid_len = OID_LENGTH(kRemoteAddress_oid);

oid kMessage_oid[] = { 1,3,6,1,4,1,1,1,1,6,0 };
size_t kMessage_oid_len = OID_LENGTH(kMessage_oid);

oid kDirection_oid[] = { 1,3,6,1,4,1,1,1,1,7,0 };
size_t kDirection_oid_len = OID_LENGTH(kDirection_oid);

oid kClassification_oid[] = { 1,3,6,1,4,1,1,1,1,8,0 };
size_t kClassification_oid_len = OID_LENGTH(kClassification_oid);

oid kPriority_oid[] = { 1,3,6,1,4,1,1,1,1,9,0 };
size_t kPriority_oid_len = OID_LENGTH(kPriority_oid);

oid kStateOfInterface_oid[] = { 1,3,6,1,4,1,1,1,1,10,0 };
size_t kStateOfInterface_oid_len = OID_LENGTH(kStateOfInterface_oid);

oid kToolName_oid[] = { 1,3,6,1,4,1,1,1,1,12,0 };
size_t kToolName_oid_len = OID_LENGTH(kToolName_oid);

oid kToolType_oid[] = { 1,3,6,1,4,1,1,1,1,13,0 };
size_t kToolType_oid_len = OID_LENGTH(kToolType_oid);

oid kToolVersion_oid[] = { 1,3,6,1,4,1,1,1,1,14,0 };
size_t kToolVersion_oid_len = OID_LENGTH(kToolVersion_oid);

snmp_varlist_add_variable(&var_list,
objid_snmptrap, objid_snmptrap_len,
120
ASN_OBJECT_ID,
(u_char *) kNotifyTrap_oid, kNotifyTrap_oid_len * sizeof(oid));

snmp_varlist_add_variable(&var_list,
kDate_oid, kDate_oid_len,
ASN_OCTET_STR,
data_kDate, strlen(data_kDate));

snmp_varlist_add_variable(&var_list,
kTime_oid, kTime_oid_len,
ASN_OCTET_STR,
data_kTime, strlen(data_kTime));

snmp_varlist_add_variable(&var_list,
kHost_oid, kHost_oid_len,
ASN_OCTET_STR,
data_kHost, strlen(data_kHost));

snmp_varlist_add_variable(&var_list,
kToolName_oid, kToolName_oid_len,
ASN_OCTET_STR,
name, strlen(name));

snmp_varlist_add_variable(&var_list,
kToolType_oid, kToolType_oid_len,
ASN_OCTET_STR,
type, strlen(type));

snmp_varlist_add_variable(&var_list,
kToolVersion_oid, kToolVersion_oid_len,
ASN_OCTET_STR,
version, strlen(version));

snmp_varlist_add_variable(&var_list,
kActionTaken_oid, kActionTaken_oid_len,
ASN_OCTET_STR,
data_kActionTaken, strlen(data_kActionTaken));

snmp_varlist_add_variable(&var_list,
kRemoteAddress_oid, kRemoteAddress_oid_len,
ASN_OCTET_STR,
data_kRemoteAddress, strlen(data_kRemoteAddress));

snmp_varlist_add_variable(&var_list,
kMessage_oid, kMessage_oid_len,
ASN_OCTET_STR,
data_kMessage, strlen(data_kMessage));

snmp_varlist_add_variable(&var_list,
kDirection_oid, kDirection_oid_len,
ASN_OCTET_STR,
data_kDirection, strlen(data_kDirection));

snmp_varlist_add_variable(&var_list,
kClassification_oid, kClassification_oid_len,
ASN_OCTET_STR,
data_kClassification, strlen(data_kClassification));

snmp_varlist_add_variable(&var_list,
kPriority_oid, kPriority_oid_len,
ASN_OCTET_STR,
data_kPriority, strlen(data_kPriority));

snmp_varlist_add_variable(&var_list,
kStateOfInterface_oid, kStateOfInterface_oid_len,
ASN_INTEGER,
(u_char *)&data_kStateOfInterface, sizeof(data_kStateOfInterface));

121
send_v2trap( var_list );
snmp_free_varbind( var_list );

return SNMP_ERR_NOERROR;
}
122

ANEXO 4: MANUAL DEL USUARIO

Referirse al Anexo 7 para la instalacin de los adaptadores y la ejecucin de la
consola de seguridad.

1. CONSOLA DE SEGURIDAD

La consola de seguridad no requiere de ningn proceso de instalacin.

Para ejecutar la consola de seguridad solo basta con hacer dos cosas: primero editar el
archivo ConfigurationParameters.properties que se encuentra en la raz de la carpeta
<ruta>\consola en donde se debe colocar la direccin del servidor MySQL y del
servidor SMTP; segundo ejecutar el archivo run.bat que sube la aplicacin.

Luego de ejecutar la aplicacin aparece la imagen de la Figura 1 que indica que se
est cargando la aplicacin.


Figura 1

123
Una vez termina de cargarse la aplicacin aparece la siguiente pantalla en donde el
usuario debe validarse frente al sistema e ingresar su usuario y contrasea como lo
indica la Figura 2.


Figura 2

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

124

Figura 3

En la Figura 3 se muestra la pantalla principal de la consola de seguridad. En el rea
(a) aparecen las mquinas que se estn monitoreando (las cuales se pueden arrastrar y
colocar en el sitio deseado, para agruparlas segn la subred a la que pertenecen).
Cuando se da clic a una de las mquinas 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 mquina se pude apreciar su direccin IP. Las mquinas aparecen en
color azul si el adaptador de esa mquina est en ejecucin y enviando mensajes
correctamente. Si por algn motivo la consola de seguridad deja de recibir mensajes
de ese adaptador la aplicacin cambia la mquina a color blanco indicando que el
adaptador no est reportando mensajes a la consola de seguridad. Cuando el
adaptador de una mquina est detectando incidentes de seguridad y se encuentra
enviando los Traps a la consola de seguridad, se va a observar que la mquina
generando las notificaciones intermitir entre rojo y azul. Una mquina que ha tenido
sucesos de seguridad aparece en color naranja en la consola y una vez se hace clic en
esa mquina cambia a color azul, proceso que indica que se han analizado los
eventos, ya que ha habido nuevos eventos que se han recibido. En la Figura 4
(a) rea de mquinas
(b) rea de incidentes de seguridad
(c) rea de eventos
125
aparecen dos mquinas siendo monitoreadas y una de ellas tiene un incidente abierto
con un evento asociado.


Figura 4

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

126

Figura 5

La Figura 5, permite observar los datos especficos de un evento. Se puede ver el
programa que lo origin, la accin tomada, entre otros campos adicionales. Se puede
navegar entre los otros eventos de ese incidente mediante los botones siguiente y atrs
o cerrar la ventana con su respectivo botn.

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 solucin de
dicho evento o incidente.

Datos del
evento
Navegar entre
eventos
127
En la barra de men aparecen tres categoras 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 parmetros para enviar y recibir Traps v3.


Figura 7

En la Figura 7 se pueden editar los parmetros 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
parmetros de los Traps que se van a enviar a una consola de gestin. Estos son el
usuario, las claves MD5 y DES, la direccin IP de la mquina que tiene la consola de
gestin y el puerto por el cual va a escuchar esa consola los Traps enviados por la
consola de seguridad. Para cambiar los valores de cada uno de los Traps basta con
modificar los campos necesarios y darle clic en ingresar.

128

Figura 8

La siguiente opcin en el men nos permite administrar los usuarios que van a
acceder a la aplicacin como se muestra en la Figura 9.

129

Figura 9

Para adicionar un usuario basta con llenar sus datos: nombre, apellido, login,
contrasea, el rol (que puede ser un usuario o administrador), el cargo, la direccin de
correo y por ltimo el nivel que ocupa en la empresa (donde el nivel 1 corresponde al
nivel ms bajo que puede ocupar el empleado). El rol de Usuario est destinado
nicamente a los usuarios que van a utilizar el programa va Web, mientras que el
Administrador es el usuario que va a ingresar a esta aplicacin. Para ingresar el
usuario basta con hacer clic en ingresar.

Tambin se puede editar la clave de un usuario ya creado como se muestra en la
Figura 10, donde se presenta la opcin de borrar el usuario seleccionado haciendo clic
en el botn borrar o cambiar la clave de un usuario ingresando la nueva clave y
haciendo clic en ingresar.

130

Figura 10

En el men insertar, como se muestra en la Figura 11, se presenta la opcin de
insertar un texto en el rea de mquinas para identificar y agrupar las mquinas
grficamente por subredes u otro criterio deseado.


Figura 11

131

Figura 12

La Figura 12 muestra la pantalla para ingresar la etiqueta. Para ingresarla basta con
escribir el texto deseado y hacer clic en insertar, luego se debe hacer un clic en el rea
de las mquinas para que aparezca la etiqueta. Esta etiqueta se puede arrastrar y poner
en el sitio deseado.

De esta forma se pueden agrupar las mquinas como se muestra en la Figura 13.
Adicionalmente si se hace clic derecho sobre una etiqueta aparece la opcin de borrar
la etiqueta deseada.


Figura 13

El men ayuda, como se ve en la Figura 14, permite obtener informacin de contacto
de la aplicacin como se muestra en la Figura 15.


Figura 14

132

Figura 15


2. PGINA WEB

Para aquellos usuarios que desean conocer informacin acerca de los incidentes de
seguridad y/o eventos se les da la opcin de ingresar a una pgina Web donde pueden
consultar dicha informacin. Pueden ser los usuarios a los que les llega una
notificacin de la consola de seguridad, como un correo, informando que se ha
vencido el plazo de solucionar un incidente. La primera pgina se encarga de validar
al usuario frente al sistema como se observa en la Figura 16. El usuario solo va a ver
informacin de los incidentes y eventos y no puede modificar ningn dato mostrado,
labor delegada a los administradores de red.

133

Figura 16

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

134

Figura 17

Al hacer clic en el botn consultar todos los incidentes abiertos y cerrados aparece
una lista de los incidentes abiertos y cerrados de todas las mquinas almacenadas en
la base de datos (ver Figura 18).

135

Figura 18

En la opcin 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, opcin que se permite
haciendo clic en el calendario al lado derecho de cada fecha y seleccionando la fecha
deseada segn la Figura 19. Luego se hace clic en consultar para que aparezca una
lista de incidentes de seguridad en ese rango de fechas como se muestra en la Figura
20.
136

Figura 19


Seleccin
de fecha
137

Figura 20

Por ltimo, en la opcin 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
continuacin se despliegan los detalles del incidente indicado como se observa en la
Figura 22.

138

Figura 21



139

Figura 22

140

ANEXO 5: INSTALACIN 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 pgina 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 configuracin para el agente: snmpconf -g basic_setup, el
cual gua para la configuracin 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
ms bsicas (se asume que el lector ya ha ejecutado el comando mencionado
anteriormente y el archivo ya se encuentra en su ubicacin).

Configurar una comunidad: el archivo debe incluir al menos una de las dos lneas
siguientes para crear una comunidad y poder hacer operaciones segn 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 podramos hacer la siguiente consulta al agente (utilizando el
programa snmpget):
snmpget -v 2c -c privada localhost system.sysName.0
Que nos retorna el nombre del sistema que estamos solicitando. En este caso
nos retorna el nombre del sistema localhost. Adicionalmente, aqu estamos
utilizando SNMPv2 (especificado por el comando -v 2c); la comunidad
privada (especificada por el comando -c privada) y estamos solicitando la
variable sysName que pertenece al grupo system (especificado por el
141
parmetro system.sysName.0; recordemos que el .0 se refiere a una
instancia en particular).

Para que funcione con soporte a encripcin, es necesario indicarle al agente que use
encripcin. Se debe instalar una distribucin 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). Tambin se debe copiar la
librera 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 (<instalacin del
cdigo>\win32\net-snmp) y aadir la siguiente lnea para indicarle que use OpenSSL:
#define USE_OPENSSL 1. A continuacin es necesario abrir VC++ y abrir el
proyecto win32.dsw. Seleccionar en la barra de men Proyecto-> Configuracin. Se
deben seleccionar todos los proyectos excepto libsnmp, libagent, libhelpers,
libnetsnmptrapd y netsnmpmibs. Luego en la opcin de Enlace, se debe adicionar la
librera libeay32.lib en la parte que dice objetos/libreras mdulos. 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
opcin del men Build seleccionar Batch Build. En la lista que aparece,
seleccionar si se desea la versin 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
cdigo 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 lneas (los comentarios se hacen con el
carcter #):

# 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 configuracin 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(an no creado
totalmente), pero el cual debemos terminar de configurar de la siguiente
manera:

142
snmpusm -v 3 -u initial -n "" -l authPriv -a MD5 -A clave_usuario x DES -X
clave_usuario -l authPriv localhost create nuevo_usuario initial

Se utiliza el programa snmpusm. Se especifica que se va a trabajar con el
protocolo SNMPv3 (usando -v 3); se va a usar el usuario initial como la
base de clonacin (el parmetro -u initial); el contexto default (usando el
parmetro -n ); el nivel de seguridad deseado, en este caso, autenticacin
y privacidad (utilizando el parmetro -l authPriv); se va a utilizar como
algoritmo de autenticacin MD5 (usando -a MD5) y se define la clave
asociada (usando -A clave_usuario); se especifica el uso del algoritmo DES
para encripcin (con el parmetro -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 parmetro 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 versin, el usuario, los protocolos y las claves y el nombre
de la variable que se va a utilizar.

Para instalarlo en Linux desde el cdigo fuente, se debe hacer lo siguiente:

Ejecutar los siguientes comandos:
./ configure --with-openssl
Si se desea obtener informacin sobre los parmetros 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 MIBs desarrolladas en el agente: luego de haber definido el rbol y la
ubicacin de los nodos y hojas en el rbol, se procede a incluir las MIBs dentro de
143
las MIBs 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 MIBs. Se debe probar que el agente reconozca las
MIBs de la siguiente manera utilizando el comando snmptranslate y los parmetros
m (para decirle que utilice todas las MIBs), -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 tambin se puede realizar la siguiente consulta con el mismo comando y los
parmetros Td (imprimir todos los detalles).



Luego se debe utilizar la herramienta mib2c, para compilar las MIBs y para que as
nos genere una plantilla en cdigo C. Genera un archivo .c y uno .h. Esta plantilla se
debe modificar para definir de donde vienen los datos y que hacer con esos datos. De
144
la siguiente manera con los parmetros 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
cdigo fuente>\win32) y aadirle una lnea para que incluya los mdulos creados:
#include "mibgroup/yy.h" (donde yy es en nombre del .h que gener mib2c)
y modificar el archivo mib_module_inits.h (<directorio cdigo fuente>\win32) y
aadirle una lnea para que inicialize el mdulo:
if (should_init("yy")) init_yy(); (donde yy es en nombre del .h que gener
mib2c)

Despus se deben copiar estos dos archivos a la carpeta donde se descomprimi el
cdigo fuente de la aplicacin. Por lo general se debe copiare a: <carpeta de cdigo
fuente>\agent\mibgroup. Luego abrir VC++ y abrir el proyecto win32.dsw (en la
carpeta <carpeta de cdigo fuente>\win32). En la barra de la mano izquierda sale una
lista de proyectos y es necesario aadir 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 mdulos (compilar snmpd).
145

ANEXO 6: MANUAL DE INSTALACIN

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
configuracin necesarios. Adicionalmente toca instalar OpenSSL para poder utilizar
las libreras en el proceso de encripcin. 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 instalacin normal ya descrita en el Anexo 6. Luego se deben copiar
los archivos de configuracin en la ruta <cd>/Linux/conf a la ruta
/usr/local/share/snmp y las MIBs 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 instalacin de
Mysql>\bin\mysql, de esta forma: mysql -u root -p < backup_all.sql. A continuacin
se pide la contrasea 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 parmetros del archivo de configuracin
ConfigurationParameters.properties ubicado en la ruta <ruta carpeta
consola>\Consola| para que quede con la direccin IP del servidor MySQL y SMTP.

Para habilitar el ingreso va 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 configuracin que se encuentra adentro del archivo webUser.war para poner la
direccin IP del servidor de MySQL. Para hacer esto es necesario abrir el archivo con
Winzip (seleccionar el archivo, darle clic derecho y seleccionar la opcin abrir con y
en la lista que aparece seleccionar Winzip). Luego aparece la pantalla del programa
con la lista de los archivos contenidos en webUser.war. Editar el archivo
ConfigurationParameters.properties.
146

ANEXO 7: CONTENIDO DEL CD

La Figura 23 muestra la estructura de rbol del CD con sus respectivas carpetas y
archivos. En la derecha se muestra una descripcin de que es cada archivo o carpeta.


Figura 23
147

ANEXO 8: DIAGRAMA DE CLASES GENERAL

La figura 24 muestra el diagrama de clases que permite el acceso a la base de datos.
La clase DBAccess se encarga de acceder a la base de datos. Utiliza un patrn
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 configuracin ConfigurationParameters.properties.

DBAccess
-DRIVER_CLASS_NAME:String
-URL:String
-USER:String
-PASSWORD:String
-url:String
-user:String
-password:String
-con:Connection
-instance:DBAccess
-DBAccess
+getInstance:DBAccess
+getMachineIp:String
+deleteComputerCasesClosed:Vector
+changeHistoricValue:void
+insertTrapData:void
+insertTrapData:void
+getTrapData:Vector
+deleteUser:void
+insertMachineData:void
+getMachineData:Vector
+modifyMachineData:void
+getMachines:Vector
+getAllMachines:Vector
+insertCaseData:void
+getCaseData:Vector
+getActiveCaseData:Vector
+getCaseDataDetails:Vector
+getActiveCasesDate:Vector
+getActiveCasesDate:Vector
+modifyCaseData:void
+insertEventData:void
+insertEventData:void
+getRecentIdCase:int
+getEventDataDetails:Vector
+modifyEventData:void
+insertNewUser:void
+getNextNotification:Vector
+setNextNotification:void
+getBasicNotification:Vector
+modifyUserData:void
+getUsers:Vector
+getUserDetails:Vector
+validateLogin:int
+getInterfaceOID:String
PropertiesReader
+getProperties:Propert
-getFile:InputStream
ConfigurationParametersManager
-CONFIGURATION_FILE:String
-parameters:Map
-ConfigurationParametersManager
+getParameter:String

Figura 24
148

El diagrama de clases para la gestin y administracin de los incidentes de seguridad
se muestra en la Figura 25. La clase ControlCasos se encarga del proceso de
creacin, gestin y administracin de los incidentes y eventos utilizados por la
consola de seguridad. Se apoya en la clase SendMail para mandar las notificaciones
va 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 grfica 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 grfica de la consola es
consoleTest.

149
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
JDialog
About
-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
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
+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
JDialog
AddUser
-jLabel1:JLabel
-jLabel2:JLabel
-jLabel3:JLabel
-jLabel4:JLabel
-jLabel5:JLabel
-jLabel6:JLabel
-jLabel7:JLabel
-jLabel8:JLabel
-jLabel9:JLabel
-jLabel10:JLabel
-name:JTextField
-surname:JTextField
-login:JTextField
-pass:JPasswordField
-passCheck:JPasswordField
-role:JComboBox
-position:JTextField
-email:JTextField
-level:JComboBox
-jButton1:JButton
-jButton2:JButton
+AddUser
-jbInit:void
-jButton2_actionPerformed:v
-jButton1_actionPerformed:v
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
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
send
+sendThread
SplashScreen
+SplashScree
+main:void
JDialog
EditUser
-jButton2:JButton
-jButton1:JButton
-email:JTextField
-position:JTextField
-role:JComboBox
-passCheck:JPasswordField
-pass:JPasswordField
-surname:JTextField
-name:JTextField
-jLabel10:JLabel
-jLabel9:JLabel
-jLabel8:JLabel
-jLabel7:JLabel
-jLabel6:JLabel
-jLabel5:JLabel
-jLabel4:JLabel
-jLabel3:JLabel
-jLabel2:JLabel
-jLabel1:JLabel
-level:JComboBox
-login:JComboBox
-db:DBAccess
-jButton3:JButton
+EditUser
-jbInit:void
+updateUsers:void
+getUserData:void
-jButton2_actionPerformed:v
-jButton1_actionPerformed:v
-jButton3_actionPerformed:v
listen
+listenThread
+ListenTrap
JDialog
LabelSubred
-jLabel1:JLabel
-jTextField1:JTextField
-jButton1:JButton
-jButton2:JButton
-jTextPane1:JTextPane
-ct:consoleTest
+LabelSubred
-jbInit:void
-jButton2_actionPerformed:
-jButton1_actionPerformed:
-StopInsertLabelThread
labelName:String
insertLabel:boolean

Figura 26