INFORME SISTEMA ITCG AGUSTIN JAIME NUÑEZ

INFORME SISTEMA ITCG AGUSTIN JAIME NUÑEZ

SUBSECRETARÍA DE EDUCACIÓN SUPERIOR
DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR
TECNOLÓGICA
INSTITUTO TECNOLÓGICO
DE CD.GUZMAN
INSTITUTO TECNOLÓGICO DE CD. GUZMAN
DIVISIÓN DE ESTUDIOS DE POSGRADO E IVESTIGACIÓN
TESIS
TEMA:
Sistema ITCG (Sistema Inteligente para el control
y monitoreo de los equipos y servicios de
cómputo y laboratorios de cómputo del CUCSur.)
QUE PARA OBTENER EL GRADO DE:
Maestro en Sistemas Computacionales
PRESENTA:
L.I. Agustín Jaime Núñez Rodríguez
DIRECTORA:
M.C. María Eugenia Puga Nathal
CD. GUZMAN JALISCO, MÉXICO, DICIEMBRE DE 2011
IIII
III
II
INDICE
Índice de figuras…………….……………………….……………….………………..
III
Índice de tablas……………………………………….……………………………….
Capitulo 1. INTRODUCCIÓN….…..…………………...…………………………....
1.1. Planteamiento del Problema……………………………………………….
1.2. Objetivos………………………………………………………………………..
1.2.1. Objetivo General…………………..……………………………………
1.2.2. Objetivos Específicos………..………………………………………..
1.3. Justificación……………………………………………………………………
1.4. Antecedentes…………………………………………………………..………
1.5. Hipótesis………………..……………………………………….……………..
1.6. Solución Propuesta……………………………………………….…………..
1.7. Características de Solución………………………………………………….
1.8. Narrativa de los Capítulos……………………………………………………
Capitulo 2. ESTADO DEL ARTE…………………………………………………….
2.1. BeSoft Monitor……………………………………….……………………….
2.1.1. Características de la Aplicación………………………………………
2.1.2. Instalación de BeSoft Monitor………………………………………..
2.2. Net Support School……………………………..………………………….
2.2.1. Características de Net Support School……………………………..
2.2.2. Instalación de Net Support School……………………………..……
2.3. LogMeln……………………..…………………………………………………
2.3.1. Características de LogMeln………………………………….………..
2.3.2. Instalación de LogMeln…………………………………………………
2.4. Remote………………………………………..………………………………..
2.4.1. Características de Remote……….……………………………….…..
2.4.2. Instalación de Remote…………………………………………………
2.5. Radmin Server……………………………….………………………………..
2.5.1. Características incluidas en la aplicación……………………………
2.5.2. Instalando Archivos de Radmin……..……………………................
2.6 Comparativa de BeSoft Monitor, Net Support School, LogMeln,
Remote-trial y Radmin Server con el Sistema ITCG..………..….....…….
Capitulo 3. MARCO TEÓRICO…………………….…………………………………
3.1. Sistemas Distribuidos………………………………………………………..
3.1.1. Conceptos Básicos…………………………………………………….
3.1.2. Protocolos……………………………..………………………………..
3.1.3. Arquitectura Cliente/Servidor………………………………………….
3.2. Tráfico de Red y Snort……………………………….……………………….
3.2.1. Conceptos Básicos de Tráfico de Red……………………………….
3.2.1.1. Paquete de Red…………………………………..…………….
3.2.1.2. Estructura de un Paquete…………………………….………..
3.2.1.3. Ejemplo de un Paquete IP……………………………………..
3.2.2. Snort…………………………..…………………………………………
3.2.2.1. Características de la Aplicación…………………….…….…..
3.2.2.2. Instalación y Configuración………………….……….………..
3.3. Sistema Operativo Fedora 6…………………………………………………
3.4. Modelos de Diseño y Desarrollo…………………………….……….……..
3.4.1. Modelo Entidad-Relación……………………………………….…….
3.4.2. Modelos de Ciclo de Vida………………………………………….….
3.4.3. Pruebas…………………………………………………………………
3.4.4. Sistema de Producción………………………………………………..
3.5. Herramientas de Diseño…………………………..…………………………
3.5.1. CSS (Cascading Style Sheets) Hoja de Estilo………………..….…
3.6.Herramientas de Desarrollo………………………………………………….
V
1
3
5
5
5
6
6
7
7
8
9
11
12
12
13
14
14
15
15
16
16
16
17
17
18
18
18
19
22
23
24
26
28
30
30
30
32
32
34
34
35
35
36
36
39
42
45
47
48
49
IV
III
3.6.1. Lenguaje PHP…………………………………………………………..
3.6.1.1. Descripción de PHP……………………………………………
3.6.1.2. Características de PHP………………………….…………….
3.6.2. Sistema de Gestión de Base de Datos MySQL…………………….
3.6.2.1. Descripción de MySQL…………….………………………….
3.6.3. Servidor Apache………………………………………………………..
3.6.3.1. Descripción el Servidor Apache……………..……………….
3.6.3.2. Características del Servidor Apache…………….…………..
3.6.3.3. Instalación y Configuración del Servidor Apache…….…….
3.6.4. Visual Basic………………………………………………….…….…....
3.6.4.1. Descripción de Visual Basic…………………………………..
3.6.4.2. Características de Visual Basic………………………………
3.6.4.3. Instalación y Configuración de Visual Basic………………..
3.6.5. Manejador de Bases de datos ODBC………….…………………….
Capitulo 4. DESARROLLO DEL PROYECTO….…………………………………..
4.1. Alcances del Sistema…………………………………………….…………
4.1.1. Beneficios……………………………………….………………………
4.1.2. Aplicación…………….…………………………………………………
4.2. Costo Beneficio……………….………………………………………………
4.3. Modelo de Desarrollo Incremental…………………………………………..
4.4. Análisis de Requerimientos…………………….……………………………
4.4.1. Enunciado del Problema………….…………………………………..
4.4.2. Requerimientos de Información………………………………………
4.4.3. Módulos Funcionales…………………………………………………..
4.5. Diseño………………………………………………………………………….
4.5.1. Diseño del Modelo Entidad-Relación………………………………....
4.5.1.1. Análisis de los Tipos de Entidad……………………...………
4.5.1.2. Análisis de los Tipos de Interrelación………………………..
4.5.2. Conversión a Tablas……………………..…………………………….
4.5.3. Diccionario de Datos……………..……………………………………
4.5.4. Diseño e implementación de la Interfaz de Usuario……….……….
4.5.5. Escenario de Uso………………………………………………………
4.5.6. Estructura de la Interfaz de Usuario……………………….…………
4.6. Código…………….……………………………………………………………
4.6.1. Desarrollo Módulo Servidor 1…………………………………………
4.6.2. Desarrollo Módulo Servidor 2…………………………………………
4.6.3. Desarrollo Módulo Cliente……………………………………………..
4.6.4. Ventanas de la Interfaz de Usuario……………………..……………
4.6.4.1. Préstamos de Equipo…………………………………………
4.6.4.2. Servicios………………………..……………………………….
4.6.4.3. Administración URL…………………………….……………..
4.6.4.4. Administración URL de Equipos……………………..………
4.6.4.5. Agregar Usuario……..…………………………………...…….
4.6.4.6. Modificar Usuario……………………………………………...
4.6.4.7. Historial………………………………………………………....
4.6.4.8. Configuración………….……………………………………….
4.6.4.9. Tráfico de Red……….…………………………………………
4.6.4.10. Reportes……………………………………………………….
4.6.4.11. Aplicar Alertas…………………………………………………
4.7. Pruebas………………………..……………………………………………….
Capitulo 5. PRUEBAS Y RESULTADOS………………………………………..….
5.1. Método de Prueba……………………………………………………………
5.2. Descripción de Prueba………….……………………………………………
5.3. Pruebas Fallidas………………..……………………………………………..
5.4. Resultados……………………………………………………………………..
50
50
51
52
52
52
53
53
53
53
54
54
55
55
56
57
57
58
58
60
64
64
66
66
68
68
69
71
76
78
81
81
85
87
88
94
95
97
97
98
99
99
100
100
101
102
102
103
104
105
106
107
110
111
114
V
II
Capitulo 6. CONCLUSIONES Y TRABAJO FUTURO...…………………………..
6.1 Conclusiones………………………..…………………………………………
6.2. Trabajos Futuros…………………………..………………………………….
Capitulo 7. REFERENCIAS……………..……………………………………………
7.1 Referencias Bibliográficas…………………….….………………………….
7.2 Referencias Electrónicas…………………………..…………………………
GLOSARIO…………………….……………………………………………….………
APENDICES…………………………………………………………………….……..
Apéndice A Manual de Usuario Administrador………….…………….……….
Apéndice B Manual de Usuario Interno…………….…………………………..
Apéndice C Manual de Instalación de Visual Basic 6……………….….……..
Apéndice D Manual de Instalación OBDC……………….……………………..
Apéndice E Manual de Instalación APPAServ…………………..……………..
ANEXO Manual de Snort……………………………………………..………………
117
118
121
122
123
123
126
133
134
146
151
161
166
173
ÍNDICE DE FIGURAS
Figura 3.1 Sistemas Distribuidos………………………………………….………….
Figura 3.2 Ejemplo Protocolo SMTP………………………………………...……….
Figura 3.3 Ejemplo Protocolo POP3…….………………………………….………..
Figura 3.4 Cliente Servidor……………………………….………………….………..
Figura 3.5 Ejemplo Paquete de Red………………………………………...……….
Figura 3.6 Ejemplo Paquete de Red IP……………………………………...………
Figura 3.7 Concepto del Modelo Entidad-Relación Extendido……………..……..
Figura 3.8 Ejemplo de un Sistema de Producción…………….………….………..
Figura 3.9 Ejemplo de Filtrado en un Sistema de Producción….…………….…..
Figura 3.10 Ejemplo de Hojas de Estilo………………………………………….…..
Figura 3.11 Ejemplo Código de Lenguaje PHP…..…………………………………
Figura 4.1 Modelo Incremental…………………………...…………………………..
Figura 4.2 Estructura de los Incrementos……………………………………………
Figura 4.3 Diagrama del Sistema ITCG…………………………………….………..
Figura 4.4 Módulos de Sistema ITCG………………………………….……….……
Figura 4.5 Entidad Usuario………………………………….…………….…………..
Figura 4.6 Entidad Equipo………………………………………………….…………
Figura 4.7 Entidad Laboratorio..……………………….…………………….……….
Figura 4.8 Entidad Carrera…………………………….…………………….………..
Figura 4.9 Entidad Servicios…………………………………………………….....…
Figura 4.10 Modelo Entidad-Relación del Proceso Préstamo de Equipos……….
Figura 4.11 Modelo Entidad-Relación del Proceso Préstamo de Servicios…..…
Figura 4.12 Modelo Entidad-Relación del Proceso de Historial de URL
Restringidas…………………….………...............................................
Figura 4.13 Diagrama de casos de uso del sistema ITCG…….…….……………
Figura 4.14 Conexión entre módulos…………………………………….………….
Figura 4.15 Módulo Servidor 1 del Sistema ITCG…………………….….…………
Figura 4.16 Formato Cabecera TCP………………………………….….…………..
Figura 4.17 Trama en Acid………………………………………………..…………..
Figura 4.18 Módulo Servidor 2 del Sistema ITCG…………………………………
Figura 4.19 Comunicación de Aplicación Cliente a Servidor……….……………..
Figura 4.20 Módulo Cliente del Sistema ITCG…………...…………………………
Figura 4.21 Ventana de Validación………..…………………………………………
Figura 4.22 Ventana de Préstamo de Equipos………….…………..………………
Figura 4.23 Ventana de Servicios……………..…………………...…………………
Figura 4.24 Ventana de Administración URL……………………………………….
Figura 4.25 Ventana de Administración URL de Equipos…………..……………..
Figura 4.26 Ventana Agregar Usuario……………………………………………….
24
27
28
29
31
32
37
45
47
48
51
61
63
67
68
69
70
70
70
70
71
73
74
82
84
89
90
91
95
96
96
97
98
98
99
99
100
III
VI
II
Figura 4.27 Ventana Modificar Usuario………………………………..…………….
Figura 4.28 Ventana de Aplicaciones No Permitidas……………………….………
Figura 4.29 Ventana Asignar Software a Equipos…………………..……………..
Figura 4.30 Ventana de Reportes de Alerta………………………………..……….
Figura 4.31 Ventana de Reportes de Accesos a Equipos por Mes…..…………..
Figura 4.32 Ventana de Reportes de Accesos………………..……...……………..
Figura 4.33 Ventanas de Filtro de Tráficos de Red…………………..…………….
Figura 5.1 Modelo de Generación de Pruebas……………………….…………….
Figura 5.2 Caso de Uso del Proceso de Validación de Usuario……..…….……..
Figura 5.3 Diagrama de Comportamiento….……………….………………………
Figura 5.4 Modelo de Datos de Prueba………………….………………………….
Figura 5.5 Interfaz de Validación………………………….…….……………………
Figura 5.6 Error de Conexión ODBC con el Servidor 2….……..………………….
Figura 5.7 Error Prueba de Bloqueo de Equipo………………….………………….
Figura 5.8 Error de Prueba de Reglas de Snort……….……………………..…….
Figura 5.9 Regla de Short…………………………………………………………….
Figura A.1 Acceso al Sistema de Información……………………………………..
Figura A.2 Validación de Usuario…………………………………………………….
Figura A.3 Vista Predeterminada del Sistema ITCG……………………………….
Figura A.4 Ventana de Préstamo de Equipos………………………………………
Figura A.5 Ventana de préstamo de Equipo con el calendario para elegir otra
fecha……………………………………………………………………….
Figura A.6 Préstamo de Servicios……………………………………………………
Figura A.7 Formulario de Reservación de Servicios………………………………..
Figura A.8 Administración de URL……………………………………………………
Figura A.9 Ejemplo de lista de URL………………………………………………….
Figura A.10 Administración URL de Equipos……………………………………….
Figura A.11 Agregar Usuario…………………………………………………………
Figura A.12 Menú desplegado con las opciones…………………………………..
Figura A.13 Aplicaciones no Permitidas…………………………………………….
Figura A.14 Opciones de la opción configuración en el menú……………………
Figura A.15 Alertas Frecuentes………………………………………………………
Figura A.16 Alertas del sistema………………………………………………………
Figura A.17 Reporte de Alertas……………………………………………………….
Figura A.18 Cerrar Sesión…………………………………………………………….
Figura B.1 Acceso al Sistema de Información………………………………………
Figura B.2 Validación de Usuario…………………………………………………….
Figura B.3 Vista Predeterminada del Sistema ITCG……………………………….
Figura B.4 Ventana de Préstamo de Equipos………………………………………
Figura B.5 Ventana de préstamo de Equipo con el calendario para elegir otra
fecha……………………………………………………………………….
Figura B.6 Préstamo de Servicios……………………………………………………
Figura B.7 Formulario de Reservación de Servicios……………………………….
Figura B.8 Cerrar Sesión………………………………………………………………
Figura C.1 Localizar el setup de instalación del programa………………………..
Figura C.2 Ventana del instalador Nex 1…………………………………………….
Figura C.3 Aceptar contrato de licencia……………………………………………..
Figura C.4 Insertar código de activación…………………………………………….
Figura C.5 Elegir modo de instalación……………………………………………….
Figura C.6 Ingresar la carpeta de destino de la aplicación………………………..
Figura C.7 Presionar continue………………………………………………………..
Figura C.8 Botón Ok……………………………………………………………………
Figura C.9 Botón Typical………………………………………………………………
Figura C.10 Ejecutándose instalación………………………………………………
Figura C.11 Finalizar instalación……………………………………………………..
101
101
102
103
103
104
104
107
107
108
108
109
112
113
114
114
135
135
136
136
137
137
138
138
139
140
140
141
141
142
144
144
145
145
147
147
148
148
149
149
150
150
152
153
153
154
154
155
156
156
157
157
158
VII
IV
II
Figura C.12 Verificar instalación……………………………………………………..
Figura C.13 Ventana de entrada Visual Basic………………………………………
Figura D.1 Icono de instalación………………………………………………………
Figura D.2 Botón Ejecutar……………………………………………………………..
Figura D.3 Ventana de Bienvenida…………………………………………………..
Figura D.4 Modo de instalación………………………………………………………
Figura D.5 Botón de instalación………………………………………………………
Figura D.6 Finalizar instalación……………………………………………………….
Figura E.1 Ejecutable APPServ……………………………………………………..
Figura E.2 Ventana de Bienvenida…………………………………………………..
Figura E.3 Aceptar el contrato de licencia…………………………………………...
Figura E.4 Elegir carpeta de destino…………………………………………………
Figura E.5 Aplicaciones a Instalar……………………………………………………
Figura E.6 Ingreso de correo y server………………………………………………..
Figura E.7 Introducir contraseña y nombre de usuario…………………………….
Figura E.8 Finalizar instalación……………………………………………………….
Figura E.9 Barra de direcciones………………………………………………………
Figura E.10 Ventana de APPServ……………………………………………………
159
160
162
163
163
164
164
165
167
168
168
169
169
170
170
171
171
172
ÍNDICE DE TABLAS
Tabla 2.1 Comparativa BeSoft Monitor, Net Support School, LogMeln,
Remote-trial y Radmin Server con el Sistema ITGC……..…………
Tabla 4.1 Costos Material……………………………………………………………..
Tabla 4.2 Costo en el Pago del Personal……………………………………..……
Tabla 4.3 Agregar Software Equipo…………………………………………………
Tabla 4.4 Carrera………………………………………………………...…………….
Tabla 4.5 Relación usuario y carrera..………………………………………..……..
Tabla 4.6 Equipo………..…………………………………………….………….……
Tabla 4.7 Fin semestre……………….………………………..…….……………….
Tabla 4.8 Firewall………………………………………………...…………...……….
Tabla 4.9 Inicio Semestre………..……………………………………………………
Tabla 4.10 Laboratorio………….……………………………………………………..
Tabla 4.11 Reservaciones………………………………………..…………………..
Tabla 4.12 Servicios……………………………………………..……………………
Tabla 4.13 Usuarios……………………………………………………………………
Tabla 4.14 Préstamos de Servicios……………………………………………..…..
Tabla 4.15 Historial URL´S Restringidas……………………………………………
Tabla 4.16 Historial Snort……………………………………………………………..
Tabla 4.17 Diccionario de Datos…………….………………………………………
Tabla 4.18 Validar Usuario…………………………………..……………...……….
Tabla 4.19 Prestar Equipo……………………………………………………………
Tabla 4.20 Dar de alta Laboratorio….……………………………………………...
Tabla 4.21 Agregar Equipo…………………………………………………...………
Tabla 4.22 Asignar Software…………………………………………………………
Tabla 4.23 Agregar Usuario…………………………………………………………..
Tabla 4.24 Imprimir Reportes………………………………….……………………..
Tabla 4.25 Estructura de Interfaz de Usuario del Módulo Servidor 2…………...
Tabla 5.1 Acciones del Sistema ITCG…………...………………………………….
Tabla 5.2 Pruebas Principales del Sistema ITCG…………………………………
Tabla A.1 Elección de Equipos y Laboratorio para visualizar las URL………….
Tabla A.2 Opciones detalladas de la opción Configuración………………………
20
59
59
76
76
76
76
76
76
76
77
77
77
77
77
77
77
78
82
83
83
83
83
84
84
85
109
110
139
143
VIII
V
II
CAPITULO 1
Introducción
1
En nuestros tiempos donde la tecnología ha ido avanzado a pasos agigantados, crece la
necesidad y la demanda de uso de equipos tecnológicos, surgiendo más necesidades de
desarrollar sistemas inteligentes que permitan controlar computadoras interconectadas
dentro o fuera de un laboratorio de cómputo o de un ámbito en general.
Al considerar las necesidades que surgen dentro de un laboratorio de cómputo de una
Universidad o cualquier dependencia que cuente con una red de computadoras; así
como, el gran impacto cultural del uso de los servicios que ofrece una red, se observa
que en algunos casos no se responde a la demanda y exigencia de los usuarios de una
red para el buen funcionamiento y máximo aprovechamiento.
Entonces gracias a los avances de la tecnología conformados entre el hardware y el
software, desde la programación hasta el diseño, existen aportaciones tecnológicas muy
importantes que permiten desarrollar sistemas dedicados específicamente a resolver las
necesidades de la problemáticas del mundo real.
En base a todas estas importantes aportaciones se ha diseñado un sistema distribuido
llamado: Sistema ITCG (“Sistema Inteligente para el control y monitoreo de los equipos y
servicios de cómputo y laboratorio de cómputo del CUCSUR”), el cual se ha desarrollado
enfocado al área de redes.
Donde su utilidad principalmente es específicamente hacia laboratorios de redes del
CUCSUR (Centro Universitario de la Costa Sur), el cual su aplicación más importante es
en el control y monitoreo del software contenido en los equipos de cómputo y de la red,
pero cabe señalar que la implementación del Sistema ITCG puede ser aplicado en
cualquier ámbito empresarial o de educación que cuente con una red de computadoras.
El Sistema ITCG fue estructuralmente desarrollado en tres módulos:
Módulo Servidor 1: Este módulo se encarga de hacer el monitoreo y filtrado de
una red LAN. El cual corre sobre el sistema operativo en su distribución Fedora 6
de Linux, en el cual se instaló y se hicieron configuraciones necesarias de la
herramienta Snort [ver Apéndice C] que es la encargada de hacer el monitoreo
del tráfico de la red que se está controlando, dicha herramienta almacena los
2
datos en una base de datos desarrollada en MySQL,
la cual permite la
compatibilidad con el Módulo Servidor 2, para que éste haga una conexión y
manipule los datos para ser visualizados. Ya que este servidor funge como
puente entre el servicio directo de Internet y el swicth principal de la red LAN, se
implementó el uso de iptables la cual proporciona servicio de Internet a los
equipos que están conectados en la red LAN.
Módulo Servidor 2: En este módulo se desarrolló una aplicación Web, la cual
permite administrar y configurar todos los parámetros considerados para cada
equipo, como por ejemplo la administración y control del software de los equipos
mediante la implementación y diseño de reglas de filtrado. Esta aplicación
también cuenta con una interfaz para el usuario final que requiere de un servicio
como reservación de equipo, aulas, proyectores; donde lo podrá hacer de
cualquier lugar del mundo con conexión a Internet. Dicho módulo fue desarrollado
con el lenguaje de programación PHP, HTML, CSS (Hojas de Estilo),
y se
generó una base de datos utilizando el manejador de MySQL en donde se
almacenan los datos enviados por el Módulo Cliente de los sucesos ocurridos en
el equipo, y los datos obtenidos del Módulo Servidor 1.
Módulo Cliente: Este módulo se desarrolló en Visual Basic 6 y el cual es instalado
en los equipos de la red LAN. Dentro de las funciones que realiza este módulo,
es analizar las aplicaciones usadas en lo equipos y para cada dato que obtiene,
hacer una conexión con el conector ODBC previamente configurado para
conectarse hacia la base de datos del Módulo Servidor 2, donde la información es
almacenada.
1.1 Planteamiento del Problema
Después de tomar en cuenta que el sistema es aplicable a cualquier laboratorio de
cómputo que se necesite monitorear, sin importar cual sea la topología de red que este
tenga, la idea inicial de implantar el Sistema ITCG nació después de observar el siguiente
planteamiento de un problema en una red.
El Centro Universitario de la Costa Sur (CUCSUR), realiza gran cantidad de actividades
de administración de forma manual por lo que requiere de un gran número de personal
administrativo, técnicos y prestadores de servicio social, para poder cubrir todas las
actividades que le asignan al Laboratorio del Centro de Cómputo del CUCSUR, por lo
3
que se decidió el desarrollar un sistema computarizado que permita agilizar las diversas
actividades que le requieren constantemente, así como reducir el número de material
humano en estas actividades que son sencillas y hasta el momento se llevan casi en el
60% de forma manual.
En el Laboratorio de Cómputo del Centro Universitario de la Costa Sur, el registro,
supervisión y la asignación de las computadoras personales y del equipo electrónico
como son, los proyectores, los pizarrones electrónicos (interactivo), computadoras
portátiles, así como el monitoreo y generación de estadísticas, lo realiza el personal que
ahí labora auxiliados de prestadores de servicio para poder realizar estas tareas que son
llevadas a cabo durante catorce (14) horas en el transcurso del día de lunes a sábado, y
por el momento estas actividades han sido realizadas de manera manual. Como por
ejemplo la solicitud de préstamo de equipos a los usuarios (docentes, administrativos,
alumnos y personas externas a la institución); la gran afluencia de los usuarios hacia el
laboratorio aunado con la forma de realizar el registro y la asignación de las
computadoras personales y del equipo electrónico, trae como consecuencia un exceso de
tiempo de espera y una gran incomodidad para los usuarios, además de un gasto de
material de papelería y movimientos de distintos recursos humanos por el exceso de
horas que se labora en el Centro de Cómputo del campus universitario.
Aunado a esta problemática, existe otra, en
la cual se encuentra involucrado el
responsable del laboratorio de cómputo de CUCSUR, ésta se da al momento de generar
los reportes semanales, mensuales y sobretodo los semestrales, para anexarlo a su
historial de actividades; motivo por el cual es necesario cerrar el laboratorio de cómputo
para realizar específicamente dichos controles en los reportes.
Contemplando la problemática antes presentada, se propuso el diseño y la realización de
un sistema inteligente que permita llevar a cabo el registro, asignación y supervisión de
las computadoras personales y del equipo electrónico, con la finalidad de reducir
significativamente la espera de los usuarios al solicitar los servicios de asignación y
registro, además de facilitar que se lleve acabo el control de los equipos y la supervisión
de las computadoras personales de forma automática mediante la configuración y
aplicación de filtros.
4
1.2 Objetivos
Los objetivos que se persiguieron con el desarrollo del Sistema ITCG son los siguientes:
1.2.1 Objetivo General
Diseñar e implementar un sistema autónomo e inteligente, basado en la toma de
decisiones, que permita llevar la administración y control de los equipos de cómputo del
laboratorio de cómputo del Centro Universitario de la Costa Sur (CUCSUR), para la
optimación de los recursos (software, hardware y económicos).
1.2.2 Objetivos Específicos
Para lograr el cumplimiento del objetivo general se realizaron los siguientes objetivos
específicos.
a) Controlar el sistema aplicando reglas y filtros, para la utilización de los
equipos de cómputo.
b) Monitorear en tiempo real mediante un cliente, todos los equipos que se
encuentren con fallas de sistema o falta de software dentro del laboratorio,
para su pronta restauración y correcto desempeño.
c) Controlar los tiempos de utilización de los equipos existentes con la
finalidad de llevar un historial, para las futuras proyecciones de compra de
los nuevos equipos en base a las necesidades propias del CUCSR.
d) Controlar utilizando procesos del sistema, el permiso de acceso a los
equipos de cómputo a los usuarios diversos.
e) Monitorear en tiempo real a los usuarios mediante procesos a necesidad
del administrador, los cuales controlarán el acceso permitido o no al
material académico, de lo contrario se realizarán las sanciones a un
usuario, dependiendo sus permisos establecidos apegados a las políticas
de utilización de los equipos correspondientes.
f)
Control de los usuarios que se encuentra utilizando un equipo de cómputo
en tiempo real (equipo, tiempo y software).
5
g) Generación de estadísticas múltiples de uso de equipos, horarios de
afluencia así como amonestaciones que los usuarios recaigan.
h) Monitorear el tráfico de la red, establecer reglas y verificarlas por medio de
las tramas obtenidas.
1.3 Justificación
El diseño e implementación del Sistema ITCG es necesario, ya que los retrasos en la
atención a los usuarios del centro de cómputo normalmente causan aglomeraciones,
molestias e inconformidades, aunque se han implementado diversas medidas para
contrarrestar y agilizar estos procesos de alguna manera son tantos los usuarios que aún
se sigue requiriendo de agilizar más la atención a los usuarios.
Además de que el servicio de Internet es ofrecido a todo el usuario que lo solicite para
sus propias necesidades, es necesario mantener dicho servicio ininterrumpidamente, por
lo que es conveniente buscar una prevención de buen uso de los equipos que ahí se
cuenta, mediante la generación de las propias reglas necesarias para dicho laboratorio,
por medio de un análisis de tráfico de tramas en la red monitorizada.
La ventaja de este sistema es que se puede implantar adaptándolo no sólo a centros
universitarios sino a todo tipo de compañías e instituciones las cuales tengan una
necesidad de administrar un cierto número de computadoras, equipos y software para su
funcionamiento, la supervisión, monitoreo en tiempo real de los sucesos que realiza el
usuario y administración de los servicios de cómputo donde surge una necesidad en la
implementación de diferentes controles y/o eventos que allí se susciten, los cuales
llevarán a tomar buenas decisiones en políticas establecidas para el manejo, adquisición
y operación de los equipos de cómputo, así como en el auxilio de la sistematización de
otros diversos procesos que se requieran por su naturaleza del servicio.
1.4 Antecedentes
Cabe destacar que en el laboratorio de cómputo de CUCSUR no hay antecedentes de
software aplicado a la administración de la red, todo se hace de manera manual en
6
formatos específicos; entonces los siguientes antecedentes fueron utilizados como apoyo
de referencia para el desarrollo del Sistema ITCG.
El primer antecedente inmediato que lleva un sistema de control similar al que se
propone, es el software empleado en el laboratorio de cómputo del Instituto Tecnológico
de Ciudad Guzmán Jalisco, el cual controla el préstamo del equipo de cómputo existente
en las salas del laboratorio, dicho préstamo se hace a través de un reservado de tiempo:
una hora si es alumno, y las horas que sean necesarias si se trata de la práctica de
alguna materia (maestro) o de un curso especial (maestro que impartirá dicho curso).
El segundo antecedente es el software llamado BeSoft Monitor, el cual controla las
políticas de utilización de equipos, así como el software en grupos o por horas
determinadas, de la misma manera lleva el control de software y hardware existente para
su historial.
1.5 Hipótesis
La hipótesis planteada en el desarrollo de este proyecto fue: “Si se diseña e implementa
un sistema inteligente para el monitoreo, control y administración de los equipos
de
cómputo y servicios del laboratorio de cómputo, se reducirá significativamente el tiempo
de espera de los usuarios en el registro y apartado de los equipos de cómputo, así como
el tomar buenas decisiones tales como compra de nuevo equipo de cómputo, software y
al igual para proyectar nuevos laboratorios con instalaciones adecuadas y pertinentes a
futuro”.
1.6 Solución Propuesta
El proceso que se pretende agilizar principalmente es el de permitir al usuario reservar
computadoras de forma automática, para los laboratorios que administra el Centro de
Cómputo, que consiste en que el usuario llegue a la recepción donde se lleva el control
de los equipos de cómputo, solicite un equipo con su credencial de usuario y ésta sea
leída por el escáner del sistema propuesto, el cual despliega todos los datos del
estudiante como son carrera, semestre, e historial y al mismo tiempo cuando el usuario
haya sido autorizado a usar un equipo, el sistema analiza el equipo en tiempo real, y de
7
forma autónoma tiene la capacidad de decidir si autoriza o no el uso de aplicaciones
permitidas a prioridad del administrador.
Desarrollando el sistema nacieron ideas llevadas a la práctica donde finalmente la
solución se dio cuando se desarrollaron dos módulos, compartidos en dos servidores,
donde en uno se implementó el sistema en el lenguaje de programación PHP, y en el otro
servidor se implementó el analizador de tráfico de la red, convirtiéndolo así en un puente
puesto entre la troncal de Internet y el router principal proveedor de la red. A su vez se
desarrollo una pequeña aplicación cliente, la cual se comunica con la base de datos
desarrollada en lenguaje MySQL para el manejo de base de dato, de tal manera que los
datos no autorizados, se bloquee para el usuario.
1.7 Características de Solución
Las situaciones propias de la administración de los laboratorios de cómputo traen consigo
que el personal dedique bastante tiempo en el reservado, realice las estadísticas
tomando como base los historiales de: equipos dañados, utilización de los equipos, la
supervisión física de las personas que hacen uso de los equipos prestados.
La implementación del Sistema ITCG al ser configurado con necesidades propias del
administrador mediante análisis previo, para realizar los controles y/o sanciones
pertinentes, para que éstos permitan la optimización de los recursos en base a los
procesos analizados, el mismo sistema propuesto, trae como consecuencia:
1. Cero errores de captura.
2. Reducción de tiempos en la asignación de equipos a usuarios.
3. Detección de los estados reales de los equipos de cómputo.
4. Control de utilización de los equipos con fines académicos.
5. Control de acceso al software asignado.
6. Reducción de tiempos en generación de estadísticas como son la utilización de
máquina por hora, por día, por máquina; de equipos en mantenimiento, préstamo
de equipos, cursos impartidos por semestre, asesorías impartidas.
7. Reducción de tiempo en el cual dedique el personal a cada uno de los diversos
controles.
8
8. Reducción de tiempos en los cuales se realiza la asignación de equipos.
9.
El buen uso de los equipos, ya que el sistema inteligente sólo permite usar lo
preestablecido optimizando los equipo y tiempo de buen uso.
10. Beneficio a todos los usuarios arrojando suficientes datos para tomar dediciones
futuras, en cuanto asignación de recursos y/o nuevos equipos según las
necesidades del propio laboratorio.
1.8 Narrativas de los Capítulos
A continuación se describen los temas restantes que conforman el informe de esta tesis:
Estado del Arte
En este capitulo se hace una comparativa del sistema desarrollado con respecto a
herramientas ya existentes como: BeSoft Monitor y Net Suport School.
Fundamentos Teóricos
Este capitulo va orientado dar a conocer los principales conceptos que fueron
necesarios para desarrollar el sistema ITCG, además de dar una descripción
general de las herramientas de software utilizado para el desarrollo del mismo.
Desarrollo del Proyecto
En este capitulo se explican puntos importantes tomados en cuenta para el diseño
y la implementación del sistema tales como: el proceso de desarrollo a partir de
la idea de un sistema que ofrezca mejor servicio, agilidad, eficiencia y rapidez, en
los procesos que se ofrecen, sobrellevando así al ahorro de contratación de
personal y el tiempo invertido, además del análisis de tráfico de red, lo que
complementa al sistema para tener un mejor rendimiento y funcionamiento de la
red sobre el cual trabaja.
Pruebas y Resultados
Este capitulo va orientado a presentar los registros de las pruebas y de los datos
arrojados durante el proceso de la realización del sistema.
Conclusiones y Trabajo Futuro
En este capitulo se dan a conocer las conclusiones del trabajo así como las
mejoras y adaptaciones que se le harán al sistema formando parte de lo que se
conoce como trabajo futuro.
9
Glosario
Aquí vienen las palabras que no son muy comunes que fueron utilizadas en este
material impreso junto con su significado.
Referencias
Aquí se da a conocer los lugares electrónicos y documentos de investigación que
se utilizaron como base para la elaboración de este sistema.
Apéndices
Aquí se incluyen los manuales de: Usuario Administrador, Manual del usuario
Interno y Externo.
Anexos
Aquí se incluyen los manuales de: Manual de VB 6, Manual de instalación de
Snort y manual de instalación de AppServ (Apache, PHP, MySQL y phpMyAdmin).
10
Capitulo 2
Estado del Arte
11
En el presente capitulo, se mencionan algunas aplicaciones similares al Sistema ITCG,
uno es BeSoft Monitor que es parecido al módulo de monitoreo de ITCG, otra aplicación
es Net Suport School cuya función es la de monitorear el uso del software de los equipos
de un aula, el cual ofrece características similares al Sistema ITCG en lo que respecta a
la sección de registro y visualización de aplicaciones restringidas según las reglas
definidas en la administración de el Snort, que sirve para proporcionar la buena
administración y eficiencia de los laboratorios. También se presenta las comparativas de
las aplicaciones que se mencionan en los siguientes puntos con el Sistema ITCG.
2.1 BeSoft Monitor
Es una herramienta especializada para monitorear, administrar con acceso remoto total
al equipo de computo dado de alta, permite entre otras operaciones, control remoto,
transferencia de archivos, Chat, inventario de hardware y software, restricción de
aplicaciones y análisis de la productividad. El sistema basa su operación en una red con
protocolo TCP/IP y puede funcionar perfectamente en redes LAN, WAN o INTERNET
[42].
2.1.1 Características de la Aplicación
BeSoft Monitor contempla, como característica propia de seguridad, el cifrado de las
comunicaciones en los siguientes puntos:
Los mensajes emitidos vía charla.
Los archivos transmitidos mediante transferencia de archivos.
El que estas transmisiones estén cifradas dificulta considerablemente que un agente
externo pueda leer su contenido, aún cuando haya sido capaz de interceptarlas. El
cifrado tiene las siguientes características:
Usa palabras de longitud (en Bytes) dinámica.
El algoritmo empleado es tecnología propietaria.
12
En un contexto en donde sean probables ataques por parte de hackers, se debe advertir
que esta herramienta fue diseñada como un sistema de monitoreo y soporte remoto.
2.1.2 Instalación de BeSoft Monitor
A continuación se indicarán unas recomendaciones para instalar BeSoft Monitor:
1. Uso sistemático de contraseñas de por lo menos 8 caracteres, que toman más
tiempo para ser descifradas mediante métodos de "fuerza bruta".
2. Uso de contraseñas aleatorias; no usar palabras de diccionario, términos
familiares al usuario o fechas de cumpleaños, que pueden ser fácilmente
"adivinadas".
3. Uso del Remoto Pro en las estaciones en donde se desee implantar mayor
seguridad, pues este tipo de sistema remoto permite el cambio periódico de
contraseñas.
4. En el caso del Remoto Pro, implantar el cambio sistemático y periódico de
contraseñas de los Remotos como política de seguridad.
5. Configurar inicialmente al Remoto Pro negando todos los derechos de conexión, y
habilitar sólo aquellos que son necesarios.
Siguiendo estos puntos básicos, se asegura que no hay puntos de acceso en lo que a
BeSoft Monitor concierne, por los cuales pueda acceder fácilmente un intruso potencial.
Sin embargo, en lo concerniente a seguridad en comunicaciones por Internet difícilmente
pueden ofrecerse garantías absolutas, y pueden existir en la red otras vías de acceso no
autorizado, por lo que la problemática específica de seguridad idealmente debe ser
abordada por un experto que ayude a reducir a un mínimo su riesgo [41]. A diferencia del
Sistema ITCG, el cual realiza el monitoreo y análisis para la toma de decisiones ya
establecidas en un conjunto de reglas de filtrado, para administrar que es lo que pasa en
la red LAN, en cuanto a la transferencia de paquetes se refiere, asegurando de esta
manera, que sólo información valida viaje a través de la misma, y con ello evitar en gran
escala los intrusos o ataques que pueden ocasionar desperfectos en el buen
funcionamiento de la misma, así como los equipos de cómputo, evitando el uso de
acciones no permitidas y controladas por dichos filtros de la aplicación que corre en
tiempo real.
13
2.2 Net Support School
Net Support School es el software de dirección de Aula (clases), tiene capacidad de
mostrar un monitor en la estación de trabajo de los estudiantes o ver hasta 16 monitores
en la máquina del Tutor simultáneamente. Un módulo de aplicación de exámenes que
pueden ser diseñados y entregados de forma personalizada a cada alumno, también
cuenta con módulos de control de aplicación remota para estar en contacto con el alumno
mientras se encuentra abierta la sesión de clase, asegurando que los estudiantes usan
sólo aplicaciones aprobadas en sus estaciones de trabajo y visitan sitios Web sólo
aprobados por el tutor de dicha clase, el cual haya establecido según las necesidades de
esa sesión [43].
2.2.1 Características de Net Support School
A continuación se presentan las características principales de Net Support School:
Temporizador de lección y planificadores, pre planean el alcance de la lección.
La conectividad: ninguna interrupción al Profesor cuando un Estudiante deja la
clase de sesión. Además, si un Estudiante deja incorrectamente una lección el
profesor hace que se conecte de nuevo.
Tiene un bloque simple de Acceso de Internet de la barra de herramientas: usado
el modo de cerrar y abrir, un profesor puede incapacitar rápidamente todo el
acceso en una acción desde cualquier área a los estudiantes.
El nuevo rasgo de Whiteboard: también permite que un profesor añada el
contenido antes de ponerlo a disposición al resto de la clase.
Esta herramienta dio la pauta de cómo poder implementar el Sistema ITCG, la opción de
estar monitoreando los equipos y aunado al censo ininterrumpido de lo que pasa en la
red analizando los paquetes que circulan por la LAN, y así mejorar esa limitante que el
software anteriormente descrito en el punto 2.1 no cuenta.
14
2.2.2 Instalación del Net Support School
Para llevara cabo la instalación de esta herramienta, se sigue el proceso que se muestra
a continuación:
1. Guardar en un directorio de la red los siguientes archivos:
a. Setup.exe
b. Nsm.ini
c. Nsm.lic
d. Client32.ini
2. Crear un archivo BAT con el código que se muestra a continuación:
Echo off net use y: \\test1\DEPLOYSHARE >nul rem Test1 es el servidor
donde están los archivos del punto 1.
3: Cd\Start /wait SETUP.EXE /s /v/qnnet use y: /delete >S
2.3 LogMeIn
Es un servicio basado en Web que ofrece acceso libre remoto móvil profesional tanto a
las computadoras personales (PC’s) ubicadas en el área de trabajo como en el hogar,
también ofrece un marco de trabajo de seguridad que incluye una encriptación SSL
extremo a extremo.
La aplicación está diseñada para que se pueda llevar en cualquier dispositivo de memoria
flash, ya sea una llave USB, un MP3 o cualquier otro, de modo que el usuario pueda
tenerla siempre consigo, y puede descargarse rápidamente desde la pagina Web de
LogMeIn [44].
15
2.3.1 Características de LogMeIn
A continuación se dan a conocer algunas características de la herramienta LogMeIn:
Control de las PC’s de forma remota en cuestión de segundos.
Transferencia de archivos con solo arrastrar.
Permite imprimir en la impresora local los archivos remotos.
Permite reunir en línea a usuarios en forma remota en instantes.
Permite escuchar el audio de forma remota.
Permite tareas de mantenimiento preventivo.
2.3.2 Instalación de LogMeIn
Para instalar la herramienta LogMeIn se siguen los pasos que a continuación se
presentan:
1. Solicitar una cuenta en la página Web de LogMeIn.
2. Se introduce en la página tomando en cuenta que sea en la PC que se desea
controlar remotamente.
3. Al presionar el botón de “add computer”, mostrará las opciones de instalación.
4. Se marca con un “check” la opción de “Install LogMeIn Free on this computer”,
y se descargará el programa.
Una vez descargada la aplicación, se procederá a instalarlo. Durante este proceso, se
pedirán datos como qué nombre tendrá la PC que se compartirá, una contraseña de
acceso, la versión de LogMeIn que correrá en el sistema (la Free) y finalmente, que
ingresen los datos que contendrá la cuenta.
2.4 Remote
Es una aplicación cliente servidor que permite monitorear los sitios Web por medio de un
servidor, haciendo un registro de todas las direcciones IP que son visitadas por el cliente
[45].
16
2.4.1 Características del Remote
A continuación se dan a conocer algunas características de la aplicación:
Transferencia de portapapeles.
Apagado Remoto.
Modo de la transferencia de 16 colores.
El comando "/stop" detiene todos los servidores Remote que se estén ejecutando
en la computadora.
Ventana "Cerrar Conexión".
Ventana de "conexión entrante" opcional.
"Tray-icon" opcional en el lado del servidor que visualiza las direcciones IP y lista
las conexiones en proceso. El icono cambia de color y emite un sonido cuando se
activa una conexión.
Herramienta de configuración que permite a los administradores inhabilitar
funciones y accesos a dicha configuración.
Puede enviar funciones de teclas al computador remoto como "Ctrl-Alt-Del".
Desconexión automática de las conexiones congeladas de la pantalla.
2.4.2 Instalación de Remote
Para instalar la herramienta Remote se siguen los pasos que a continuación se
presentan:
1.Instalar
Remote
Administrator
normalmente:
se
ejecuta
el
archivo
RADMIN22ES.EXE y se pulsa "Siguiente".
2.Presionar "Aceptar los términos de este contrato" y pulsar "Siguiente".
3.Pulsar "Siguiente".
4.En este punto se muestran dos opciones:
a) Instalar Remote Administrator Viewer: sirve para hacer control remoto a
tros equipos.
b) Instalar Remote Administrator Server: instala Remote Administrator para que
se pueda hacer control remoto a un equipo desde otro.
17
5.Especificar la ubicación del programa y presionar el botón "Comenzar".
6.Si ya quedo instalado Remote, se mostrará una ventana para introducir la
contraseña. Ésta será la que la aplicación pida cuando se desee hacer control
remoto a un equipo desde otro de la red local o de Internet.
7.Tras la instalación de Remote, se pedirá confirmación para reiniciar el equipo,
para lo cual se deberán cerrar todos los programas que se tengan abiertos y
reiniciar.
2.5 Radmin Server
Es el software de control remoto que combina control remoto, componentes de servicios,
ayuda de escritorio
y control de redes en un solo paquete integrado, que permite
disponer del kit de herramientas [46].
2.5.1 Características incluidas en la aplicación
Radmin ofrece una seria de características, las cuales se presentan a continuación:
Seguridad al trabajar.
Chat de voz y texto.
Fácil de usar (ya que implementa una interface clara, sencilla y fácil de entender).
Transferencia segura de archivos basada únicamente en: "Arrastrar y colocar" con
la característica "Copia Delta".
Mínimos requisitos de sistema (es decir funciona que es compatible con todas las
versiones de Windows).
Compatibilidad con múltiples conexiones con pantalla remota.
Soporte técnico gratuito por email.
Compatibilidad total de varias pantallas.
Directorio ilimitado para conexiones Radmin.
2.5.2 Instalando Archivos de Radmin
Los pasos que se muestran a continuación indican el proceso a seguir para la instalación
de esta herramienta:
18
Descomprimir los archivos de instalación.
Ejecutar radmin22.exe desde la distribución descomprimida.
Seguir las instrucciones de la instalación.
Después de la instalación, Radmin Server o Radmin Viewer (cliente) pueden ser
ejecutados desde el menú Inicio.
También se puede ejecutar las "Opciones para Remote Administrator Server”
desde el menú Inicio. "Opciones para Remote Administrator Server" permite
establecer el modo de inicio de Radmin Server, cambiar la contraseña para el
acceso de red a Radmin Server.
2.6 Comparativa de Besoft Monitor, Net Support School, LogMeIn,
Remote-trial y Radmin Server con el Sistema ITCG
En la tabla 2.1 se hace una comparativa de los sistemas antes mencionados con el
proyecto que se comenta en este informe. Es importante recalcar que las aplicaciones
mencionadas no los hace ni más ni menos a comparación del Sistema ITCG, ya que
cuentan con características que según su aplicación resuelven necesidades de
administración de control de una red. Lo que hace diferente el sistema inteligente
desarrollado en esta tesis, es que además de contar con un sistema de reservación de
equipos, también cuenta con un análisis de las tramas de la red; lo cual permite controlar
a la red de computadoras. El Sistema ITCG se considera completo, ya que cubre varias
necesidades (Por ejemplo: reservado de equipos de forma remota vía Internet por horas,
aplicación de reglas de bloqueo de equipos debido a uso no adecuado o permitido,
generación de estadísticas para la toma de decisiones, por mencionar algunas), donde
las soluciones de las mismas son reunidas en módulos adaptados de tal manera que
logran una integración para resolver y aportar servicios de un Laboratorio de Red.
19
Besoft
Monitor
Net
Support
School
1. Obtener inventario de los X
LogMeIn
Remote
Radmin
server
ITCG
X
X
X
X
X
X
equipos remotos.
2. Conocer inventario por equipo X
o programa.
3. Reportes y estadísticas.
X
4. Reportes exportables en Pdf.
X
5. Capacidad de mostrar en X
monitor
la
estación
X
X
X
X
de
trabajos de estudiantes.
6. Capacidad
de
restringir X
X
X
X
software no permitido.
X
7. Control de registros de equipo
(reservación
de
X
equipos)
remotamente vía internet.
X
8. Monitoreo de paquetes de
X
X
red.
X
9. Firewall.
10. Asistencia y monitoreo en el
X
X
X
X
uso compartido de archivos.
Tabla 2.1 Comparativa de Besoft Monitor, Net Support School, LogMeIn, Remote-trial y
Radmin Server con el Sistema ITCG
En referencia a la tabla 2.1, las aplicaciones tratadas, formaron parte de la investigación
para el desarrollo del Sistema ITCG, las cuales a continuación se describen:
1. Las características de BesofMonitor como: Monitoreo de la Red de Equipos,
Restricción de Aplicaciones, Reportes exportados a PDF, Firewall.
2. Las características de NetSuportSchool tomadas en cuenta para el Sistema ITCG
son: temporizador de sesión de clase, que en el caso del Sistema ITCG se refiere
20
a temporizar la reservación de los equipos, además tiene la capacidad de
restringir aplicaciones no deseadas y un Firewall.
3. LogMeIn cuenta con control de registro de equipos, y generador de estadísticas,
lo cual el Sistema ITCG también lo tiene.
4. Remote y Radmin Server monitorean los paquetes de una red que en
comparación con el Sistema ITCG representa a la herramienta Snort.
21
Capitulo 3
Marco Teórico
22
En este capitulo se mencionan conceptos y características de las aplicaciones y
herramientas que fueron utilizadas para la creación del Sistema ITCG. Además de
metodologías y conceptos para elaborar una base de datos. Entre las herramientas que
se utilizaron para desarrollar el Sistema ITCG están: Snort, una herramienta que ayuda al
análisis de la red, PHP lenguaje de programación que se utilizó para crear el Módulo
Servidor 2 del Sistema ITCG, MySQL lenguaje en el se que se basó para crear la base de
datos del sistema, Visual Basic se utilizó para crear el módulo cliente, lo cual es
compatible con MySQL, permitiendo así usar la aplicación ODBC que hace la
comunicación remota entre el Módulo Cliente y el Módulo Servidor 2.
Durante el desarrollo del Sistema ITCG se realizaron investigaciones importantes, donde
a continuación se presentan los temas más relevantes e importantes relacionados con el
Sistema ITCG.
3.1 Sistemas Distribuidos
Primeramente fue ubicar teóricamente al Sistema ITCG, ya que cumple con las
características de un Sistema Distribuido, en este tema se explica más a detalle, tomando
en cuenta las características, protocolos y Arquitectura.
En la computación desde sus inicios ha sufrido muchos cambios, desde las grandes
computadoras que permitían realizar tareas en forma limitada y de uso un tanto exclusivo
de organizaciones muy selectas, hasta las actuales computadoras ya sean personales o
portátiles que están cada vez más introducidos en el quehacer cotidiano de una persona.
Los mayores cambios se atribuyen principalmente a dos causas, que se dieron desde las
décadas de los setenta:
1. El desarrollo de los microprocesadores, que al aumentar en gran medida sus
capacidades, permitieron reducir en tamaño y costo a las computadoras, y
aumentar su acceso a más personas, ya que tanto aplicaciones multimedia como
aplicaciones remotas generan y consumen grandes cantidades de datos continuos
en tiempo real, lo cual lleva a realizar mas trabajo en menos tiempo.
2. El desarrollo de las redes de área local y de las comunicaciones que permitieron
conectar computadoras con posibilidad de transferencia de datos a alta velocidad,
23
tanto en el área de vídeo, voz y datos, Ya juegan un rol importante en el uso y
aplicaciones de la tecnología, ya que cada vez más las empresas y usuarios lo
demandan, para las interacciones dentro y fuera de su negocio, tales como
aplicaciones multimedia las cuales requieren de estructuras de Software,
Hardware y ancho de banda más adecuados.
Es en este contexto que aparece el concepto de "Sistemas Distribuidos" que se ha
popularizado tanto en la actualidad y que tiene como ámbito de estudio las redes como la
Internet, redes de teléfonos móviles, redes corporativas, redes de empresas, logrando
optimizar los recursos; reduciendo costos, ofreciendo un mejor servicio, buscar e
implementar nuevas formas de trabajo, ofrecer nuevos servicios y tener información más
oportuna y/o acertada [41].
3.1.1 Conceptos Básicos
Definición de sistema distribuido: "Sistemas cuyos componentes hardware y software,
que están en computadoras conectadas en red, se comunican y coordinan sus acciones
mediante el paso de mensajes, para el logro de un objetivo. Se establece la
comunicación mediante un protocolo prefijado por un esquema cliente-servidor". Ver
Figura 3.1.
Figura 3.1 Sistemas Distribuidos
Ventajas y Alcances:
Procesadores más poderosos y a menos costos.
Desarrollo de Estaciones con más capacidades
24
Las estaciones satisfacen las necesidades de los usuarios.
Uso de nuevas interfaces.
Avances en la Tecnología de Comunicaciones.
Disponibilidad de elementos de Comunicación.
Desarrollo de nuevas técnicas.
Compartición de Recursos.
Dispositivos (Hardware).
Programas (Software).
Eficiencia y Flexibilidad.
Respuesta Rápida.
Ejecución Concurrente de procesos (En varias computadoras).
Empleo de técnicas de procesamiento distribuido.
Disponibilidad y Confiabilidad.
Sistema poco propenso a fallas (Si un componente no afecta a la disponibilidad
del sistema).
Mayores servicios que elevan la funcionalidad (Monitoreo, Telecontrol, Correo
Eléctrico, Etc.).
Crecimiento Modular.
Es inherente al crecimiento.
Inclusión rápida de nuevos recursos.
Los recursos actuales no afectan.
Dentro de algunas características que tienen los sistemas distribuidos están:
Concurrencia: Esta característica de los sistemas distribuidos permite que los
recursos disponibles en la red puedan ser utilizados simultáneamente por los
usuarios y/o agentes que interactúan en la red.
25
Carencia de reloj global: Las coordinaciones para la transferencia de mensajes
entre los diferentes componentes para la realización de una tarea, no tienen una
temporización general, está más bien distribuida a los componentes.
Fallos independientes de los componentes: Cada componente del sistema
puede fallar independientemente, con lo cual los demás pueden continuar
ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad,
pues el sistema en su conjunto continua trabajando [48].
3.1.2 Protocolos
Definición: Es un conjunto bien conocido de reglas y formatos que se utilizan para la
comunicación entre procesos que realizan una determinada tarea. Se requieren dos
partes:
Especificación de la secuencia de mensajes que se han de intercambiar.
Especificación del formato de los datos en los mensajes.
Un protocolo permite que componentes heterogéneos de sistemas distribuidos puedan
desarrollarse independientemente, por medio de módulos de software o aplicaciones que
componen el protocolo, para que haya una comunicación transparente entre ambos
componentes. La mayoría de los protocolos especifican una o más de las siguientes
propiedades:
Detección de la conexión física sobre la que se realiza la conexión (cableada o sin
cables).
Pasos necesarios para empezar a comunicarse.
Negociación de las características de la conexión.
Cómo se inicia y como termina un mensaje.
Formato de los mensajes.
Qué hacer con los mensajes erróneos o corruptos (corrección de errores).
Cómo detectar la perdida inesperada de la conexión, y qué hacer en ese caso.
Terminación de la sesión de conexión.
Estrategias para asegurar la seguridad (autenticación, cifrado).
Ejemplos de protocolos usados en los sistemas distribuidos:
26
IP: Protocolo de Internet.- Protocolo de la capa de Red, que permite definir la
unidad básica de transferencia de datos y se encarga del direccionamiento de la
información, para que llegue a su destino en la red.
TCP: Protocolo de Control de Transmisión.- Protocolo de la capa de Transporte,
que permite dividir y ordenar la información a transportar en paquetes de menor
tamaño para su transporte y recepción.
HTTP: Protocolo de Transferencia de Hipertexto.- Protocolo de la capa de
aplicación, que permite el servicio de transferencia de páginas de hipertexto entre el
cliente Web y los servidores.
SMTP: Protocolo de Transferencia de Correo Simple.- Protocolo de la capa de
aplicación, que permite el envío de correo electrónico por la red [49]. Ver Figura 3.2.
Figura 3.2 Ejemplo Protocolo SMTP
POP3: Protocolo de Oficina de Correo.- Protocolo de la capa de aplicación, que
permite la gestión de correos en Internet, es decir, le permite a una estación de
trabajo recuperar los correos que están almacenados en el servidor. Ver Figura 3.3.
27
Figura 3.3 Ejemplo Protocolo POP3
3.1.3 Arquitectura Cliente/Servidor
Para el desarrollo de una aplicación distribuida, se puede optar por diversos diseños
arquitectónicos, entre los que se pueden mencionar, están los siguientes: basado en
tuberías, basado en capas, cliente – servidor, igual a igual (peer to peer), código móvil,
cómputo móvil y sistemas de agentes, siendo de todos estos el diseño cliente – servidor
el más utilizado, y dadas las necesidades del sistema que se desarrollo en esta tesis, se
optó por utilizar este modelo arquitectónico para el diseño y desarrollo del mismo. A
continuación se hace una descripción general de este modelo [47].
Definición: Sistema donde el cliente es una máquina (o porción de software, según sea
el caso) que solicita un determinado servicio y se denomina servidor a la máquina que lo
proporciona. Los servicios pueden ser:
Ejecución de un determinado programa.
Acceso a un determinado banco de información.
Acceso a un dispositivo de hardware.
28
Es un elemento primordial, la presencia de un medio físico de comunicación entre las
máquinas, y dependerá de la naturaleza de este medio la viabilidad del sistema. Ver
Figura 3.4.
Figura 3.4 Cliente Servidor
A continuación se presenta una lista de los servidores más comunes:
Servidores de archivos: Proporciona archivos para clientes. Si los archivos no
fueran tan grandes y los usuarios que comparten esos archivos no fueran muchos,
esto sería una gran opción de almacenamiento y procesamiento de archivos. El
cliente solicita los archivos y el servidor los ubica y se los envía.
Servidores de base de datos: Son los que almacenan gran cantidad de datos
estructurados, se diferencian de los de archivos pues la información que se envía
está ya resumida en la base de datos. Ejemplo: El Cliente hace una consulta, el
servidor recibe esa consulta (SQL) y extrae soló la información pertinente y envía
esa respuesta al cliente.
Servidores de Software de Grupo: El software de grupo es aquel, que permite
organizar el trabajo de un grupo. El servidor gestiona los datos que dan soporte a
estas tareas. Por ejemplo: almacenar las listas de correo electrónico. El Cliente
puede indicarle, que se ha terminado una tarea y el servidor se lo envía al resto del
grupo.
Servidores Web: Son los que guardan y proporcionan Páginas HTML. El cliente
desde un browser o link hace un llamado de la página y el servidor recibe el
mensaje y envía la página correspondiente.
29
Servidores de correo: Gestiona el envío y recepción de correo de un grupo de
usuarios (el servidor no necesita ser muy potente). El servidor solo debe utilizar un
protocolo de correo.
Servidor de objetos: Permite almacenar objetos que pueden ser activados a
distancia. Los clientes pueden ser capaces de activar los objetos que se encuentran
en el servidor.
Servidores de impresión: Gestionan las solicitudes de impresión de los clientes. El
cliente envía la solicitud de impresión, el servidor recibe la solicitud y la ubica en la
cola de impresión, ordena a la impresora que lleve a cabo las operaciones y luego
avisa a la computadora cliente que ya acabo su respectiva impresión.
Servidores de aplicación: Se dedica a una única aplicación. Es básicamente una
aplicación a la que pueden acceder los clientes.
3.2 Tráfico de Red y Snort
¿Por qué relacionar el tráfico de la Red con la herramienta Snort?
Porque el tráfico de la Red es un medio importante que se da entre los equipos de la
misma, y en el Sistema ITCG se busca optimizar el tráfico, y evitar problemas que no
permitan proporcionar un mejor servicio al usuario final. Snort entra justo para analizar la
red para actuar sobre el punto de evitar tales problemas que se pueden dar en el tráfico
de la red.
3.2.1 Conceptos Básicos de Tráfico de Red
Entonces para entender el funcionamiento del Sistema ITCG, es importante revisar
conceptos básicos de Red, como el paquete de red que es analizado para la toma de
decisiones según los parámetros que se establecen en las reglas de Snort.
3.2.1.1 Paquete de Red
Un paquete es una unidad de transporte de información en las redes de computadoras.
Cada uno de los bloques en que se divide, en el nivel de Red, la información a enviar. En
todo sistema de comunicaciones resulta interesante dividir la información a enviar en
bloques de un tamaño máximo conocido.
30
Esto simplifica el control de la comunicación, las comprobaciones de errores, la
gestión de los equipos de encaminamiento (routers), etc. Ver Figura 3.5.
Figura 3.5 Ejemplo Paquete de Red
La mayoría de los paquetes se dividen en tres partes:
Encabezado o Cabecera: La cabecera, o header, contiene instrucciones acerca
de los datos que el paquete lleva. Estas instrucciones pueden incluir:
o
Largo del paquete (algunas redes tiene paquetes de tamaño fijo, mientras
que otras confían este dato al encabezado).
o
Sincronización (un grupo de bits que indican el comienzo del paquete)
o
Número de paquete (el orden de mismo dentro de una secuencia de
paquetes).
o
Indicador de protocolo (en redes que transportan múltiples tipos de
información, el protocolo define que tipo de paquete está siendo
transmitido y por tanto cómo debe ser interpretado su cabecera y su
contenido).
o
Dirección de destino (hacia donde se dirige el paquete).
o
Dirección de origen (de donde viene el paquete).
Carga útil: También llamada cuerpo o datos del paquete. Éste es el contenido
real del paquete que está siendo entregado a su destino. Si el paquete es de
tamaño fijo, entonces los datos pueden ser rellenados con información en blanco
para darle al paquete el tamaño correcto. En tal caso el encabezado guardará
algún indicador que le permita saber donde acaban los datos y comienza el
relleno o padding [8].
31
3.2.1.2 Estructura de un paquete
Al igual que las tramas, los paquetes pueden estar formados por una cabecera, una parte
de datos y una cola. En la cabecera estarán los campos que pueda necesitar el protocolo
de nivel de red, en la cola, si la hubiere, se ubica normalmente algún mecanismo de
comprobación de errores.
Dependiendo de que sea una red de datagramas o de circuitos virtuales (CV), la
cabecera del paquete contendrá la dirección de las estaciones de origen y destino o el
identificador del CV. En las redes de datagramas no suele haber cola, porque no se
comprueban errores, quedando esta tarea para el nivel de transporte.
3.2.1.3 Ejemplo de un Paquete IP
La figura 3.6 muestra el proceso de cómo el paquete se ejecuta a través de la red,
siguiendo el orden de las instrucciones y procedimientos.
Figura 3.6 Ejemplo Paquete de Red IP
El protocolo de red IP sólo tiene cabecera, ya que no realiza ninguna comprobación sobre
el contenido del paquete. Sus campos se representan siempre alineados en múltiplos de
32 bits. Los campos son, por este orden:
Versión: 4 bits, actualmente se usa la versión 4, aunque ya está en
funcionamiento la versión 6. Este campo permite a los routers discriminar si
pueden tratar o no el paquete.
Longitud de cabecera (IHL): 4 bits, indica el número de palabras de 32 bits que
ocupa la cabecera. Esto es necesario porque la cabecera puede tener una
longitud variable.
32
Tipo de servicio: 6 bits (+2 bits que no se usan), en este campo se pensaba
recoger la prioridad del paquete y el tipo de servicio deseado, pero los routers no
hacen mucho caso de esto y en la práctica no se utiliza. Los tipos de servicios
posibles serían:
o
D: (Delay) Menor retardo, por ejemplo para audio o vídeo.
o
T: (Throughput) Mayor velocidad, por ejemplo para envío de archivos
grandes.
o
R: (Reliability) Mayor fiabilidad, para evitar en la medida de lo posible los
reenvíos.
Longitud del paquete: 16 bits, como esto lo incluye todo, el paquete más largo
que puede enviar IP es de 65535 bytes, pero la carga útil será menor, porque hay
que descontar lo que ocupa la propia cabecera.
Identificación: 16 bits, un número de serie del paquete, si un paquete se parte en
pedazos más pequeños por el camino (se fragmenta), cada uno de los fragmentos
llevará el mismo número de identificación.
Control de fragmentación: son 16 bits que se dividen en:
o
1 bit vacío: sobraba sitio.
o
1 bit DF: del ínglés dont't fragments. Si vale 1 le advierte al router que este
paquete no se corta.
o
1 bit MF: del inglés more fragments indica que éste es un fragmento de un
paquete más grande y que, además, no es el último fragmento.
o
Desplazamiento de fragmento: es la posición en la que empieza este
fragmento respecto del paquete original.
Tiempo de vida: 8 bits, en realidad se trata del número máximo de routers (o de
saltos) que el paquete puede atravesar antes de ser descartado. Como máximo
255 saltos.
Protocolo: 8 bits, este campo codifica el protocolo de nivel de transporte al que
va destinado este paquete. Está unificado para todo el mundo en números de
protocolos por la IANA (Internet Assigned Numbers Authority).
Checksum de la cabecera: 16 bits, aunque no se comprueben los datos, la
integridad de la cabecera sí es importante, por eso se comprueba.
Direcciones de origen y destino: 32 bits cada una. Son las dirección IP de la
estaciones de origen y destino.
33
Opciones: Esta parte puede estar presente o no, de estarlo su longitud máxima
es de 40 bytes [50].
3.2.2 Snort
Antes de explicar los conceptos de Snort, es importante recalcar que la herramienta Snort
es vital para el Sistema ITCG en general por que es el que analiza las tramas y almacena
los datos de las tramas en una base de datos, para su uso y manipulación en la toma de
decisiones.
Entonces Snort es un sniffer de paquetes y un detector de intrusos basado en red (se
monitoriza todo un dominio de colisión). Es un software muy flexible que ofrece
capacidades de almacenamiento de sus bitácoras tanto en archivos de texto como en
bases de datos abiertas como lo es MySQL. Implementa un motor de detección de
ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier
anomalía previamente definida[10]. Así mismo existen herramientas de terceros para
mostrar informes en tiempo real (ACID) o para convertirlo en un Sistema Detector y
Preventor de Intrusos [11].
3.2.2.1 Características de la Aplicación
Este IDS implementa un lenguaje de creación de reglas de forma flexible, potente y
sencilla. Durante su instalación provee de cientos de filtros o reglas para backdoor,
DDoS, finger, FTP, ataques Web, CGI, Nmap.
Puede funcionar como sniffer (se puede ver en consola y en tiempo real qué ocurre en la
red, ver todo el tráfico), registro de paquetes (permite guardar en un archivo los logs para
su posterior análisis, un análisis offline) o como un IDS normal (en este caso NIDS).
Cuando un paquete coincide con algún patrón establecido en las reglas de configuración,
se loguea. Así se sabe cuando, de donde y cómo se produjo el ataque.
Aún cuando tcpdump es considerada una herramienta de auditoría muy útil, no se
considera un verdadero IDS puesto que no analiza ni señala paquetes por anomalías.
tcpdump imprime toda la información de paquetes a la salida en pantalla o a un archivo
de registro sin ningún tipo de análisis. Un verdadero IDS analiza los paquetes, marca las
34
transmisiones que sean potencialmente maliciosas y las almacena en un registro
formateado, así, Snort utiliza la librería estándar libcap y tcpdump como registro de
paquetes en el fondo.
Snort está disponible bajo licencia GPL, es gratuito y funciona bajo plataformas Windows
y UNIX/Linux. Dispone de una gran cantidad de filtros o patrones ya predefinidos, así
como actualizaciones constantes ante casos de ataques, barridos o vulnerabilidades que
vayan siendo detectadas a través de los distintos boletines de seguridad.
La característica más apreciada de Snort, además de su funcionalidad, es su subsistema
flexible de firmas de ataques. Snort tiene una base de datos de ataques que se está
actualizando constantemente y a la cual se puede añadir o actualizar a través de la
Internet. Los usuarios pueden crear 'firmas' basadas en las características de los nuevos
ataques de red y enviarlas a la lista de correo de firmas de Snort, para que así todos los
usuarios de Snort se puedan beneficiar. Esta ética de comunidad y compartir ha
convertido a Snort en uno de los IDSes basados en red más populares, actualizados y
robustos.
3.2.2.2 Instalación y Configuración
En el anexo C, se incluye el manual de Snort, en el cual se muestra como se lleva a cabo
la instalación y configuración de Snort.
3.3 Sistema Operativo Fedora 6
Fedora se utilizó como base del sistema operativo para el Módulo Servidor 1 donde se
instaló la herramienta Snort, a continuación se presenta una reseña de Fedora.
Fedora, antes Fedora Core (Fedora Linux), es una distribución GNU/Linux desarrollada
por la comunidad Fedora y promovida por la compañía estadounidense Red Hat.
El objetivo del proyecto Fedora es conseguir un sistema operativo de propósito general y
basado exclusivamente en software libre con el apoyo de la comunidad Linux. Los
35
ingenieros de Red Hat continúan participando en la construcción y desarrollo de este
proyecto e invitan y fomentan la participación de miembros de la comunidad Linux.
Originalmente, Red Hat Linux fue desarrollado exclusivamente dentro de Red Hat, con la
sola realimentación de informes de usuarios que recuperaban fallos y contribuciones a los
paquetes de software incluidos; y no contribuciones a la distribución como tal. Esto
cambió el 22 de septiembre de 2003, cuando Red Hat Linux se derivó dando origen al
Proyecto Fedora que está orientado a la comunidad de usuarios y así mismo, sirve de
base para que Red Hat Enterprise Linux se desarrolle con más efectividad y adopte las
nuevas características que se añaden en el Proyecto Fedora [13].
3.4 Modelos de Diseño y Desarrollo
En el Sistema ITCG es importante establecer puntos de referencia de diseño de base de
datos, ciclos de vida y sus pruebas, además de un sistema de producción, que guiaron
para una mejor organización de desarrollo e implementación del Sistema ITCG, a
continuación se da a conocer la información necesaria para lograr dichos diseños.
3.4.1 Modelo Entidad-Relación
El modelo entidad-relación es el modelo conceptual más utilizado para el diseño de bases
de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está
formado por un conjunto de conceptos que permiten describir la realidad mediante un
conjunto de representaciones gráficas y lingüísticas.
Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación
y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las
jerarquías de generalización, en lo que se ha denominado modelo entidad-relación
extendido.
En la figura 3.7 se ilustran los elementos que intervienen en un modelo entidad-relación
los cuales se describen a continuación:
36
Figura 3.7 Conceptos del modelo entidad-relación extendido
Entidad
Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona,
concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes,
empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se
representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un
nombre de entidad sólo puede aparecer una vez en el esquema conceptual. Hay dos
tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya existencia
depende de la existencia de otra entidad. Una entidad fuerte es una entidad que no es
débil.
Relación (interrelación)
Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un
nombre que describe su función. Las relaciones se representan gráficamente mediante
rombos y su nombre aparece en el interior.
Las entidades que están involucradas en una determinada relación se denominan
entidades participantes. El número de participantes en una relación es lo que se
denomina grado de la relación. Por lo tanto, una relación en la que participan dos
37
entidades es una relación binaria; si son tres las entidades participantes, la relación es
ternaria.
Una relación recursiva es una relación donde la misma entidad participa más de una vez
en la relación con distintos papeles. El nombre de estos papeles es importante para
determinar la función de cada participación.
Cardinalidad
La cardinalidad con la que una entidad participa en una relación especifica el número
mínimo y máximo de correspondencias en las que puede tomar parte cada ocurrencia de
dicha entidad. La participación de una entidad en una relación es obligatoria (total) si la
existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una
ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial). Las
reglas que definen la cardinalidad de las relaciones son las reglas de negocio.
A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos
problemas, denominados trampas, suelen producirse a causa de una mala interpretación
en el significado de alguna relación, por lo que es importante comprobar que el esquema
conceptual carece de dichas trampas. En general, para encontrar las trampas, hay que
asegurarse de que se entiende completamente el significado de cada relación. Si no se
entienden las relaciones, se puede crear un esquema que no represente fielmente la
realidad.
Atributo
Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los
atributos representan las propiedades básicas de las entidades y de las relaciones. Toda
la información extensiva es portada por los atributos. Gráficamente, se representan
mediante elipses que cuelgan de las entidades o relaciones a las que pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio
define todos los valores posibles que puede tomar un atributo. Puede haber varios
atributos definidos sobre un mismo dominio.
38
Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que
tiene un solo componente, que no se puede dividir en partes más pequeñas que tengan
un significado propio. Un atributo compuesto es un atributo con varios componentes,
cada uno con un significado por sí mismo. Un grupo de atributos se representa mediante
un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a
su uso. Un atributo compuesto se representa gráficamente mediante un óvalo.
Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo
monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o
relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores para
cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se
les denomina multivaluados, y pueden tener un número máximo y un número mínimo de
valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de
valores que puede tomar para cada ocurrencia de la entidad o relación a la que
pertenece. El valor por omisión es (1,1).
Identificador
Un identificador de una entidad es un atributo o conjunto de atributos que determina de
modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir
con las condiciones siguientes:
No pueden existir dos ocurrencias de la entidad con el mismo valor del
identificador.
Si se omite cualquier atributo del identificador, la condición anterior deja de
cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores
alternativos [7L].
3.4.2 Modelos de Ciclo de Vida
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren
durante el desarrollo de software, intenta determinar el orden de las etapas involucradas
y los criterios de transición asociadas entre estas etapas. Un modelo de ciclo de vida del
software:
39
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definición de un detallado proceso de
desarrollo de software.
Así, los modelos por una parte suministran una guía para los ingenieros de software con
el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte
suministran un marco para la administración del desarrollo y el mantenimiento, en el
sentido en que permiten estimar recursos, definir puntos de control intermedios,
monitorear el avance. A continuación se presentan algunos modelos de ciclo de vida:
Modelo Cascada
Éste es el más básico de todos los modelos, y sirve como bloque de construcción para
los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de
software es muy simple; dice que el desarrollo de software puede ser a través de una
secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas y las
flechas muestran el flujo de información entre las fases. La flecha de avance muestra el
flujo normal. Las flechas hacia atrás representan la retroalimentación.
El modelo de ciclo de vida cascada, captura algunos principios básicos:
Planear un proyecto antes de embarcarse en él.
Definir el comportamiento externo deseado del sistema antes de diseñar su
arquitectura interna.
Documentar los resultados de cada actividad.
Diseñar un sistema antes de codificarlo.
Testear un sistema después de construirlo.
Una de las contribuciones más importantes del modelo cascada es para los
administradores, posibilitándoles avanzar en el desarrollo.
40
Modelo de Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes.
Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros
aspectos para niveles posteriores. El desarrollo incremental es el proceso de
construcción siempre incrementando subconjuntos de requerimientos del sistema.
Típicamente, un documento de requerimientos es escrito al capturar todos los
requerimientos para el sistema completo.
Cabe mencionar que el desarrollo incremental es 100% compatible con el modelo
cascada. El desarrollo incremental no demanda una forma específica de observar el
desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para
administrar cada esfuerzo de desarrollo.
El modelo de desarrollo incremental provee algunos beneficios significativos para los
proyectos:
Construir un sistema pequeño es siempre menos riesgoso que construir un
sistema grande.
Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, sólo la última iteración necesita ser
descartada.
Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento
del sistema) decrecen las probabilidades que esos requerimientos de usuarios
puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados
antes del comienzo del próximo incremento.
Modelo de Desarrollo Evolutivo
Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas
veces denominado como prototipado evolutivo) construye una serie de grandes versiones
sucesivas de un producto. Sin embargo, mientras que la aproximación incremental
41
presupone que el conjunto completo de requerimientos es conocido al comenzar, el
modelo evolutivo asume que los requerimientos no son completamente conocidos al
inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos
que son bien comprendidos son seleccionados para el primer incremento. Los
desarrolladores construyen una implementación parcial del sistema que recibe sólo estos
requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a
los
desarrolladores.
Basada
en
esta
retroalimentación,
la
especificación
de
requerimientos es actualizada, y una segunda versión del producto es desarrollada y
desplegada. El proceso se repite indefinidamente.
Este modelo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo
no demanda una forma específica de observar el desarrollo de algún incremento. Así, el
modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo.
Obviamente, el desarrollo incremental y evolutivo puede ser combinado también [44].
3.4.3 Pruebas
Los casos de prueba deben ser escritos con el detalle suficiente para que el probador
pueda empezar rápidamente a ejecutar pruebas y a encontrar defectos. Además, estos
reflejan trazabilidad con los casos de uso, las especificaciones suplementarias de
requerimientos y diseño del sistema, garantizando que los procedimientos de pruebas
sean compatibles con las necesidades de los usuarios/clientes.
Etapa de Pruebas
1. Objetivo de la Prueba
El propósito de esta actividad es identificar, describir y generar el los casos de
prueba, el modelo de pruebas correspondiente especificando cómo realizar los
casos de prueba.
42
2. Participantes
Diseñador de pruebas: Es responsable de la planificación, diseño,
implementación y evaluación de las pruebas. Esto conlleva generar el plan
de pruebas y modelo de pruebas, implementar los casos de prueba y
evaluar los resultados de las pruebas. Los diseñadores de prueba
realmente no llevan a cabo las pruebas, sino que se dedican a la
preparación y evaluación de las mismas.
Probador (Tester): Es responsable de desarrollar las pruebas de unidad,
integración y sistema, lo que incluye ejecutar las pruebas, evaluar su
ejecución, recuperar los errores y garantizar los resultados de las pruebas.
3. Descripción
Esta actividad permite estructurar y organizar bien las pruebas. El diseñador de
pruebas analiza los objetivos de las pruebas que se han planificado y desarrolla
los casos de prueba y el modelo de pruebas necesario para llevarlas a cabo. En el
diseño de las pruebas se transforman los casos de uso en casos de prueba de
aceptación y del sistema, y la realización de los casos de uso en casos de prueba
de unidad, integración y sistema.
Pruebas de unidad (prueba de equivalencia, prueba de valores límite, prueba del
camino, prueba basada en estados, prueba de polimorfismo). Los casos de
prueba de integración se utilizan para verificar que los productos de desarrollo
software interaccionan entre sí de la forma apropiada después de haber sido
integrados. La mayoría de los casos de prueba de integración pueden ser
derivados de las realizaciones de los casos de uso, ya que las realizaciones de
casos de uso describen cómo interaccionan las clases y los objetos.
Los diseñadores de pruebas deben crear un conjunto de casos de prueba que
hicieran posible alcanzar los objetivos establecidos en el plan de prueba con un
esfuerzo mínimo. Para poder hacer esto, los diseñadores de pruebas intentan
encontrar un conjunto de casos de prueba con un solapamiento mínimo, cada uno
de los cuales prueba un camino o escenario interesante a través de una
realización de casos de prueba.
43
Cuando los diseñadores de prueba crean los casos de prueba de integración
consideran como entrada primeramente los diagramas de interacción de las
realizaciones de los casos de uso. Los diseñadores de prueba buscan
combinaciones de entrada, salida y estado inicial de sistema que den lugar a
escenarios interesantes que empleen las clases que participan en los diagramas.
Más tarde, cuando se realiza la prueba de integración correspondiente, se toman
las interacciones actuales de los objetos del sistema; por ejemplo, creando trazas
de su ejecución o ejecutándola paso a paso. A continuación, se comparan las
interacciones actuales con el diagrama de interacciones, las cuales deberían ser
iguales; en otro caso se trata de un defecto.
Las pruebas de sistema se usan para probar que el sistema funciona
correctamente como un todo. Cada prueba se sistema prueba principalmente
combinaciones de casos de uso bajo condiciones diferentes. Estas condiciones
incluyen diferentes configuraciones hardware (procesadores, memoria principal,
discos duros, etc.), diferentes niveles de carga del sistema, diferentes número de
actores y diferentes tamaños de la base de datos. Cuando se desarrollan los
casos de prueba de sistema los diseñadores de pruebas deberían dar prioridad a
las combinaciones de los casos de uso que:
Se necesita que funcionen en paralelo.
Posiblemente funcionan en paralelo.
Posiblemente se influencian mutuamente si se ejecutan en paralelo.
Involucran varios procesadores.
Usan frecuentemente recursos del sistema, como procesos, procesadores,
bases de datos y software de comunicaciones, quizás en formas complejas
e impredecibles.
Pueden encontrarse, por tanto, muchos casos de prueba de sistema considerando los
casos de uso, especialmente considerando sus flujos de eventos y sus requerimientos
especiales (como los requerimientos de rendimiento) [45].
Es importante tomar en cuenta que en la etapa del desarrollo también se incluyen
métodos que ayudan a administrar actividades como el Modelo Incremental usado en el
Sistema ITCG, además se utilizó el método de modelos de entidad-relación para la
44
elaboración de las base de datos. Y referente a los métodos de prueba se optó por el
método de casos de uso y prueba y error.
3.4.4 Sistemas de Producción
El diseño
del módulo inteligente del Sistema ITCG, se basó en la utilización de un
sistema de producción, por lo que a continuación se dan a conocer los conceptos básicos
sobre éste.
Un sistema de producción consta de una base de hechos, una base de implicaciones
(llamadas producciones o reglas) y aparte un mecanismo de control (motor de inferencia),
donde se siguen una serie de pasos para resolver un problema como una cadena de
deducciones, como se ilustra en la figura 3.8.
Base de Hechos: Predicados o funciones que describen el problema concreto del
mundo real.
Base de Reglas: Reglas que describen los mecanismos de razonamiento que
permiten resolver problemas.
Figura 3.8 Ejemplo de un Sistema de Producción
45
El motor de inferencia consta de los siguientes pasos:
1. Obtener el conjunto de posibles reglas que se pueden combinar con algún hecho
de la base de hechos. Esta fase se denomina equiparación de reglas con
hechos. A las reglas emparejadas se les denomina reglas activas.
2. Seleccionar algún o algunos objetos de los equiparamientos obtenidos en el
paso anterior. Este paso se denomina resolución de conflictos.
3. Disparar los equiparamientos seleccionados en la fase y modificar la base de
hechos según dictan los consecuentes de las reglas activas disparadas.
El ciclo termina cuando en la base de hechos aparece el hecho que resuelve el problema.
Los sistemas de producción son una generalización del proceso de deducción lógica.
Una memoria de trabajo es en la que se almacenan los datos y resultados obtenidos,
como por ejemplo según el tipo de sistema de aplicación una memoria de trabajo sería
una base de datos. Los datos de la memoria de trabajo son los que permiten cumplir las
condiciones de las reglas y dispararlas (las reglas verifican la existencia de elementos en
la memoria de trabajo para disparar [9L].
Las acciones de las reglas: modifican, añaden o quitan elementos de la memoria de
trabajo (o producen efectos secundarios).
Propiedades de las reglas:
Modularidad: cada regla define un pequeño y relativamente independiente
segmento de conocimiento.
Incrementalidad: nuevas reglas pueden ser añadidas a la base de conocimiento
relativamente independiente de las demás.
Modificabilidad: como consecuencia de la modularidad, las reglas antiguas
pueden ser modificadas.
Transparencia: habilidad de explicar sus decisiones y soluciones.
Un Sistema de producción tiene:
Un conjunto de reglas (base de conocimiento).
46
Un intérprete de reglas o motor de inferencia (que decide que regla aplicar,
controla la actividad del sistema).
Una memoria de trabajo (que guarda los datos, metas, y resultados intermedios).
En la Figura 3.9 se muestra un ejemplo aplicado al Sistema ITCG con sistemas de
producción. El motor de inferencia correspondiente al Analizador de Red se encarga de
ejecutar acciones para resolver el problema:
Detecta (Filtro): Obtiene el conjunto de reglas para verificar si se ha generado un
conflicto.
Selecciona (Regla): Resolución de conflictos: selección de la instaciación aplicar.
Aplica: Aplicación de la Regla seleccionada.
Base de Hechos
Usuario(Interno x)
Usa_Internet(Usuario Interno x, Explorador)
Palabras_Clave(Jaime,Adonai,…)
Sanción(Usuario Inerno x, equipo x)
Motor de
Inferencia = Analizador de
Red (Snort)
Base de Reglas
If Usa_Internet(Usuario Interno x, Explorador) and
Palabras_Clave(Jaime,Adonai,…) then Sanción(Usuario Interno x, equipo x)
Figura 3.9 Ejemplo de Filtrado en un Sistema de Producción
3.5 Herramientas de Diseño
A continuación se hace una descripción de las diferentes herramientas de diseño y
desarrollo que fueron utilizados para la implementación del trabajo de tesis que se
describe en este reporte.
47
3.5.1 CSS (Cascading Style Sheets) Hojas de Estilo
Esta técnica de programación para diseñar un Sistema Web, se eligió porque que permite
separar del código y la interfaz, logrando un mejor mantenimiento tanto en el mismo
Diseño Gráfico como en el Desarrollo Funcional.
Las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un lenguaje formal
usado para definir la presentación de un documento estructurado escrito en HTML o XML
(y por extensión en XHTML).
El W3C (World Wide Web Consortium) es el encargado de formular la especificación de
las hojas de estilo que servirá de estándar para los agentes de usuario o navegadores.
Ver Figura 3.10.
Figura 3.10 Ejemplo Hojas de Estilo
La idea que se encuentra detrás del desarrollo de CSS es separar la estructura de un
documento de su presentación.
Por ejemplo, el elemento de HTML <H1> indica que un bloque de texto es un
encabezamiento y que es más importante que un bloque etiquetado como <H2>.
Versiones más antiguas de HTML permitían atributos extra dentro de la etiqueta abierta
para darle formato (como el color o el tamaño de fuente). No obstante, cada etiqueta
<H1> debía disponer de la información si se deseaba un diseño consistente para una
página, y además, una persona que lea esa página con un navegador pierde totalmente
el control sobre la visualización del texto.
48
Cuando se utiliza CSS, la etiqueta <H1> no debería proporcionar información sobre como
va a ser visualizado, solamente marca la estructura del documento. La información de
estilo separada en una hoja de estilo, especifica cómo se ha de mostrar <H1> : color,
fuente, alineación del texto, tamaño, y otras características no visuales como definir el
volumen de un sintetizador de voz.
La información de estilo puede ser adjuntada tanto como un documento separado o en el
mismo documento HTML. En éste último podrían definirse estilos generales en la
cabecera del documento o en cada etiqueta particular mediante el atributo "style".
Las ventajas de utilizar CSS (u otro lenguaje de estilo) son:
Control centralizado de la presentación de un sitio Web completo con lo que se
agiliza de forma considerable la actualización del mismo.
Los Navegadores permiten a los usuarios especificar su propia hoja de estilo local
que será aplicada a un sitio Web, con lo que aumenta considerablemente la
accesibilidad. Por ejemplo, personas con deficiencias visuales pueden configurar
su propia hoja de estilo para aumentar el tamaño del texto o remarcar más los
enlaces.
Una página puede disponer de diferentes hojas de estilo según el dispositivo que
la muestre o incluso a elección del usuario. Por ejemplo, para ser impresa,
mostrada en un dispositivo móvil, o ser "leída" por un sintetizador de voz.
El documento HTML en sí mismo es más claro de entender y se consigue reducir
considerablemente su tamaño.
Hay varias versiones: CSS1 y CSS2, con CSS3 en desarrollo por el World Wide Web
Consortium (W3C). Los navegadores modernos implementan CSS1 bastante bien,
aunque existen pequeñas diferencias de implementación según marcas y versiones de
los navegadores. CSS2, sin embargo, está sólo parcialmente implementado en los más
recientes [46].
3.6 Herramientas de Desarrollo
En las herramientas de desarrollo elegidas se encuentran PHP, MySQL, Servidor
Apache, Visual Basic, y ODBC. Estas herramientas permitieron desarrollar los Módulos
Servidor 2 y Cliente. La compatibilidad de sentencias de base de datos de MySQL con
49
PHP y Visual Basic, permitió hacer un puente de conexión de cliente a servidor, con
diferentes Sistema Operativos. Como por ejemplo, el cliente y el Servidor 2 corren sobre
Windows y el Servidor 1 en la plataforma Linux de Fedora. A continuación se explica
más detallado.
3.6.1 Lenguaje PHP
PHP se eligió para hacer el Módulo Servidor 2, debido a que es un lenguaje libre, y a sus
controles, que hacen que el Sistema ITCG cuente con un nivel de lenguaje estructurado
dentro de un Sistema Web.
PHP es un lenguaje de programación usado frecuentemente para la creación de
contenido para sitios Web con los cuales se puede programar las páginas HTML. PHP es
un acrónimo recursivo que significa "PHP (Hypertext Pre-processor)" (inicialmente PHP
Tools, o, Personal Home Page Tools), y se trata de un lenguaje interpretado usado para
la creación de aplicaciones para servidores, o creación de contenido dinámico para sitios
Web. Últimamente también para la creación de otro tipo de programas incluyendo
aplicaciones con interfaz gráfica usando las librerías GTK+.
3.6.1.1 Descripción de PHP
El fácil uso y la similitud con los lenguajes más comunes de programación estructurada,
como C y Perl, permiten a la mayoría de los programadores experimentados crear
aplicaciones complejas. También les permite involucrarse con aplicaciones de contenido
dinámico sin tener que aprender todo un nuevo grupo de funciones y prácticas.
Debido al diseño de PHP, también es posible crear aplicaciones con una interfaz gráfica
para el usuario (también llamada GUI), utilizando la extensión PHP-GTK. También puede
ser usado desde la línea de órdenes, de la misma manera como Perl o Python pueden
hacerlo, esta versión de PHP se llama PHP CLI (Command Line Interface) [51].
50
3.6.1.2 Características de PHP
Su interpretación y ejecución se da en el servidor Web, en el cual se encuentra
almacenado el script, y el cliente sólo recibe el resultado de la ejecución. Cuando el
cliente hace una petición al servidor para que le envíe una página Web, generada por un
script PHP, el servidor ejecuta el intérprete de PHP, el cual procesa el script solicitado
que generará el contenido de manera dinámica, pudiendo modificar el contenido a enviar,
y regresa el resultado al servidor, el cual se encarga de regresárselo al cliente. Además
es posible utilizar PHP para generar archivos PDF, Flash, así como imágenes en
diferentes formatos, entre otras cosas.
Permite la conexión a diferentes tipos de servidores de bases de datos tales como
MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite; lo cual
permite la creación de Aplicaciones Web muy robustas.
PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas
operativos tales como UNIX (y de ese tipo, como Linux), Windows y Mac OS X, y puede
interactuar con los servidores de Web más populares ya que existe en versión CGI,
módulo para Apache, e ISAPI.
El modelo PHP puede ser visto como una alternativa al sistema de Microsoft que utiliza
ASP.NET/C#/VB.NET, a ColdFusion de la compañía Macromedia, a JSP/Java de Sun
Microsystems, y al famoso CGI/Perl.
Aunque su creación y desarrollo se da en el ámbito de los sistemas libres, bajo la licencia
GNU, existe además un IDE comercial llamado Zend Optimizer. En la figura 3.11 se
ilustra un ejemplo de un documento codificado en lenguaje PHP.
Figura 3.11 Ejemplo Código en lenguaje PHP
51
3.6.2 Sistema de gestión de bases de datos MySQL
MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario.
MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual.
Por un lado lo ofrece bajo la licencia GNU GPL, pero, empresas que quieran incorporarlo
en productos privativos pueden comprar a la empresa una licencia que les permita ese
uso.
MySQL se utilizó para el Sistema ITCG, en el desarrollo de la base de datos,
principalmente se eligió esta tecnología por la amplia compatibilidad con otras
tecnologías.
3.6.2.1 Descripción de MySQL
Está desarrollado en su mayor parte en el lenguaje de programación ANSI C. Al contrario
de proyectos como el Servidor Apache, donde el software es desarrollado por una
comunidad pública, y el código está en poder del autor individual, MySQL está
patrocinado por una empresa privada, que tiene los derechos de autor de la mayor parte
del código. Esto es lo que posibilita el esquema de licenciamiento anteriormente
mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y
servicios. Para sus operaciones contratan trabajadores alrededor del mundo que
colaboran vía Internet. MySQL AB fue fundado por David Axmark, Allan Larsson, y
Michael Widenius [52].
3.6.3 Servidor Apache
El servidor HTTP Apache es un software (libre) servidor de código abierto para
plataformas Unix (BSD, GNU/Linux, etc.), Windows , Macintosh y otras, que implementa
el protocolo HTTP/1.1 1 y la noción de sitio virtual. Cuando comenzó su desarrollo en
1995 se basó inicialmente en código del popular NCSA HTTP 1.3, pero más tarde fue
reescrito por completo. Su nombre se debe a que originalmente Apache consistía
solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a
patchy server (un servidor "parcheado").
52
3.6.3.1 Descripción del Servidor Apache
El servidor Apache se desarrolla dentro del proyecto HTTP Server de la Apache Software
Foundation.
Apache presenta entre otras características mensajes de error altamente configurables,
bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta
de una interfaz gráfica que ayude en su configuración.
Apache tiene amplia aceptación en la red: Apache es el servidor HTTP más usado,
siendo el servidor HTTP del 70% de los sitios Web en el mundo y creciendo aún su cuota
de mercado (estadísticas históricas y de uso diario proporcionadas por Netcraft 2) [53].
3.6.3.2 Características del Servidor Apache
A continuación se mencionan algunas características del Servidor Apache:
Servidor Web
PHP -Soporta páginas dinámicas en PHP.
MySQL - Bases de Datos
PhpMyAdmin- Administrador de las bases de datos
Perl - Sistema de Scripts
3.6.3.3 Instalación y Configuración del Servidor Apache
En el anexo D, se da a conocer la información referente a la instalación y configuración
del servidor Apache.
3.6.4 Visual Basic
Visual Basic es un lenguaje de programación desarrollado por Alan Cooper para
Microsoft. El lenguaje de programación es un dialecto de BASIC, con importantes
añadidos. Su primera versión fue presentada en 1991 con la intención de simplificar la
programación utilizando un ambiente de desarrollo completamente gráfico que facilitara la
creación de interfaces gráficas y en cierta medida también la programación misma. En
53
Visual Basic se desarrollo el Módulo Cliente que es el que analiza y controla los equipos,
dicha aplicación envía información de los sucesos generados en los equipos y se
almacenan en la base de datos del Módulo Servidor 2.
3.6.4.1 Descripción de Visual Basic
Es un lenguaje de programación de fácil aprendizaje pensado tanto para programadores
principiantes como expertos, guiado por eventos, y centrado en un motor de formularios
que facilita el rápido desarrollo de aplicaciones gráficas. Su sintaxis, derivada del antiguo
BASIC, ha sido ampliada con el tiempo al agregarse las características típicas de los
lenguajes estructurados modernos. Se ha agregado una implementación limitada de la
programación orientada a objetos (los propios formularios y controles son objetos),
aunque sí admite el polimorfismo mediante el uso de los Interfaces, no admite la
herencia. No requiere de manejo de punteros y posee un manejo muy sencillo de
cadenas de caracteres.
Posee varias bibliotecas para manejo de bases de datos, pudiendo conectar con
cualquier base de datos a través de ODBC (Informix, DBase, Access, MySQL, SQL
Server, PostgreSQL ), el cual es utilizado principalmente para aplicaciones de gestión de
empresas, debido a la rapidez con la que se puede hacer un programa que utilice una
base de datos sencilla, además de la abundancia de programadores en este lenguaje[15].
3.6.4.2 Características de Visual Basic
El compilador de Microsoft genera ejecutables que requieren una librería DLL para que
funcionen, en algunos casos llamada MSVBVMxy.DLL (acrónimo de "MicroSoft Visual
Basic Virtual Machine x.y", siendo x.y la versión) y en otros VBRUNXXX.DLL ("Visual
Basic Runtime X.XX"), que provee todas las funciones implementadas en el lenguaje.
Además existen un gran número de bibliotecas (DLL) que facilitan el acceso a muchas
funciones del sistema operativo y la integración con otras aplicaciones. Sin embargo esto
sólo es una limitación en sistemas obsoletos, ya que las bibliotecas necesarias para
ejecutar programas en Visual Basic vienen de serie en todas las versiones de Windows
desde Windows 2000.
54
3.6.4.3 Instalación y Configuración de Visual Basic
En el anexo E, se presenta la forma de cómo realizar la instalación y configuración de
este lenguaje de programación.
3.6.5 Manejador de bases de datos ODBC
Open Data base Connectivity (ODBC) es un estándar de acceso a Bases de Datos
desarrollado por Microsoft Corporation, el objetivo de ODBC es hacer posible el acceder
a cualquier dato de cualquier aplicación, sin importar qué Sistema Gestor de Bases de
Datos (DBMS por sus siglas en inglés) almacene los datos, ODBC logra esto al insertar
una capa intermedia llamada manejador de Bases de Datos, entre la aplicación y el
DBMS, el propósito de esta capa es traducir las consultas de datos de la aplicación en
comandos que el DBMS entienda. Para que esto funcione tanto la aplicación como el
DBMS deben ser compatibles con ODBC, esto es que la aplicación debe ser capaz de
producir comandos ODBC y el DBMS debe ser capaz de responder a ellos.
Para conectarse a la base de datos se crea una DSN dentro del ODBC que define los
parámetros, ruta y características de la conexión según los datos que solicite el
fabricante.
55
Capitulo 4
Desarrollo del
Proyecto
56
En este capitulo se explican los procesos que se llevaron a cabo para el desarrollo del
Sistema ITCG, en este informe primero se expresan los alcances y
beneficios, su
aplicación y el análisis de costos. Para entonces definir un esquema de actividades,
diseñado de acuerdo a un modelo incremental, el cual marcó una pauta, en donde los
incrementos se dividen en analizar los requerimientos para elaborar un diseño y
desarrollar el código, llegando así a la implementación y pruebas hasta alcanzar una
versión final apta para los usuarios.
4.1 Alcances del Sistema
El sistema puede registrar procesos de reservación de equipos, de reglas de filtrado en
tiempo real (los periodos pueden ser configurables de acuerdo a las necesidades del
administrador).
El sistema contiene una base de datos en la cual se almacena los datos obtenidos por las
reservaciones, por el software usado en los equipos y por Snort después del análisis de
las tramas.
El sistema genera búsquedas y en ellas se puede visualizar todos los pormenores de los
usuarios, así como el total de anomalías generadas por máquina o faltas al reglamento
por el usuario. Todos estos datos pueden ser visualizados en históricos. Toda la
información generada puede ser impresa o almacenada en informes en formato PDF o
consultarla en el Sistema ITCG, tales como informe de acceso de equipos por mes,
informe de acceso de equipos por carrera, informe de sanciones. Ver Figura 4.25.
4.1.1 Beneficios
En el Sistema ITCG se puede ver la Información en tiempo real, tal como la consulta de
las alertas, las aplicaciones no permitidas, las reservaciones; lo que permite aplicar las
reglas establecidas en el momento de que suceden los hechos de forma autónoma.
Reduce el papeleo y optimiza la comunicación entre operación, supervisión y gerencia.
Elimina tiempos en la elaboración de reportes al generarlos en forma automática, así el
personal puede destinar más tiempo a sus actividades corrientes más primordiales.
57
4.1.2 Aplicación
La aplicación del Sistema ITCG es tan diversa ya que se diseñó para administrar y
controlar una red de computadoras, es decir, que con tan sólo contar con un centro de
cómputo (en escuelas, hoteles, cibercafés, y en diversas empresas) que necesite ser
administrado de forma inteligente podrá ser instalado el Sistema ITCG.
4.2. Costo Beneficio
Como se observa en la tabla 4.1, se hace un análisis de los elementos que se usaron
para la elaboración del Sistema ITCG, como ya se contaba el material no representó un
gasto en lo materiales.
CONCEPTO
Equipo
DESCRIPCIÓN
COSTO
BENEFICIO
2 Equipos portátiles
No aplica, ya se
Ya se cuenta con el mismo,
con características.
cuenta con éstas.
así que el beneficio será
superior a Pentium III
que sólo se requiere ser
1 Equipo.
implantado
para
Estacionario.
tiempos
y
2 Tarjetas de Red.
materiales como humanos.
ahorrar
recursos
1 Switch.
Infraestructura
Oficina o biblioteca,
No aplica, ya se
donde se pueda
cuenta
trabajar
espacio.
con
Ahorro del espacio.
el
adecuadamente, ya
que el desarrollo se
realizara en laptop.
Materiales
Software requerido
No
aplica
Apache, MySQL,
ninguno,
PHP, Visual Basic,
cuenta con ellos.
ya
en
Ahorro de la compra de los
se
mismos.
Photoshop.
Hardware:
Las instalaciones de
58
una LAN
segmentada.
Tabla 4.1 Costos Material
En cambio, al analizar las actividades que se pretende beneficiar, respectivamente en el
personal del Laboratorio de CUCSUR, se observa que está representando un gasto muy
potencial ver Tabla 4.2, tomando en cuenta que los laboratorios están en constante
crecimiento y actualización, se requerirá de más personal y por ende representará un
costo mayor.
COSTO DEL PERSONAL
CANTIDAD
PUESTO
NOMBRE
Ana Bertha Decena
1 Secretaria
Rodríguez
1 Soporte
Mario Alberto Flores Medina
1 Soporte
Arturo Quintero Rúelas
1 Soporte
Luis Alberto Ambriz López
Agustín Jaime Núñez
1 Administrador Rodríguez
1 Coordinador
Oscar Cárdenas Hernández
25 Apoyo
Prestador
5 Apoyo
Becario
MENSUL
TOTAL
1 año
4882
4882
4882
8308
4882
4882
4882
8308
58584
58584
58584
99696
8309
15156
4000
1414,8
MENSUAL
8309
15156
100000
7074
153493
99708
181872
1200000
84888
1841916
Tabla 4.2 Costo en el Pago del Personal
Como se observa en la tabla 4.2, el gasto mayor radica en el personal de apoyo, el cual
representa en mayor porcentaje el que se dedica al registro de los préstamos, y revisión
por cada laboratorio para la verificación del buen uso de los equipos. Tales actividades
potenciales que el Sistema ITCG realiza.
Entonces la factibilidad de la implementación del Sistema ITCG representara un ahorro
permitiendo tener el personal necesario para la administración del Sistema ITCG, ya que
el Sistema ITCG toma decisiones según los sucesos que ocurran en el uso de los
59
equipos, sin la necesidad de desplazarse por cada laboratorio para observar que las
actividades del usuario sean correctas de acuerdo al reglamento de los Laboratorios de
CUCSUR.
4.3 Modelo de Desarrollo Incremental
En el desarrollo del Sistema ITCG se requirió de un modelo representado en procesos y
avances para la creación del mismo, en este caso se baso el desarrollo en el Modelo
Incremental, lo cual permitió identificar cada uno de los elementos que componen al
Sistema ITCG.
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de
personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de
personas y en cada incremento de ser necesario añadir personal. Por otro lado los
incrementos se pueden planear para gestionar riesgos técnicos. El proyecto se adapto a
un modelo incremental estructurado en 4 incrementos, en la Figura 4.1 se presenta el
modelo sugerido:
Análisis
de
Requerimientos:
Documentos
para
usuarios,
analistas
y
desarrolladores.
Diseño: Documentos Programadores de Diseño de base de datos.
Código: Componentes de Software, Programas.
Implementación y Prueba: Ensamble de componentes, productos de software,
cambios o mejoras del software.
60
Figura 4.1 Modelo Incremental
Con base a las fases del modelo incremental se comprenden ciertas actividades que a
continuación se presentan:
Análisis de Requerimientos
o
Requerimientos de Información
o
Requerimientos Funcionales
Diseño
o
Diagrama Entidad-Relación
o
Conversión a base de datos
Código
o
Desarrollo Módulo Servidor 1
o
Desarrollo Módulo Servidor 2
o
Desarrollo Módulo Cliente
Implementación y Prueba
o
Pruebas
Descripción de resultados entre cada incremento, según el modelo de desarrollo
incremental (modular).
61
Fase 1 (Entrega 1)
Servidor 2- Control y configuración del sistema
Primero se desarrollo el sistema que administra todos los procesos y servicios del
Sistema ITCG, el cual pasó por un análisis de requerimientos, para obtener ciertos
parámetros que ayudaran a la estructuración del sistema en general, como tablas para la
base de datos y en si definir las celdas de cada tabla para almacenar todos los datos
necesarios para el sistema.
Diseñada la base de datos se implementó y se desarrolló la interfaz de administración,
donde se hicieron una serie de pruebas de funcionamiento.
Fase 2 (Entrega 2)
Cliente-Aplicación que controla los equipos cliente
El siguiente paso de desarrollo para el Sistema ITCG, fue idear como controlar a los
equipos que serán monitoreados. Se desarrolló una aplicación en visual Basic y OBDC
como conexión a la base de datos del Servidor 2. La aplicación monitorea en tiempo real
todos los procesos que se están utilizando en el equipo cliente, y si existe una aplicación
que no esté permitida, el cliente la registra en la base de datos y se bloquea
automáticamente.
Fase 3 (Entrega 3)
Servidor 1- Sistema de Filtrado de contenido y monitoreo de paquetes de Red
Después de haber diseñado el servidor de administración de procesos y servicios, el
cliente, se pensó en una herramienta que además permitiera monitorear los paquetes de
la red que funcionan bajo el Sistema ITCG, con el objetivo de brindar un sistema de
monitoreo más completo y tener más filtros de control y el usuario no ejecute y ni busque
información no permitida.
62
El sistema de monitoreo de paquetes de red, es montado sobre un servidor de Linux, el
cual permite configurar servicios de Internet. Se le configuró un sistema de monitoreo
llamado Snort, su función principal es leer todos los paquetes que viajan en la red, y si
hay reglas aplicadas entonces las guarda en una base de datos que a su vez se
comunica con la base de datos del servidor 2.
Está comunicación permite tomar medidas preventivas y si algún paquete contiene
información no permitida, automáticamente se hace la petición a la aplicación cliente y se
bloquea el equipo.
Cada módulo se explica más a detalle en los puntos 4.6.1, 4.6.2, 4.6.3 de este capítulo,
en los temas 4.4 Análisis de Requerimientos, 4.5 Diseño, 4.6 Código, 4.7 Pruebas; se
especificarán las actividades que se desarrollaron en el Modelo Incremental propuesto.
Los incrementos corresponden al resultado obtenido en cada una de las fases
(requerimientos, diseño, código, pruebas), en la Figura 4.2 se muestra como se define un
incremento, donde en el sistema ITCG en general, contiene los datos, y con base a ello
tiene entradas y salidas de los mismos, obteniendo resultados en las pruebas.
Donde después de la prueba se define si se desarrolla un incremento más o se ha
llegado a un resultado satisfactorio.
Figura 4.2 Estructura de los Incrementos
63
4.4 Análisis de Requerimientos
Para realizar un análisis de requerimientos en el sistema ITCG, es necesario primero
establecer la problemática real de un laboratorio de cómputo, ésta problemática se verá a
detalle en el punto 4.4.1, después de observar los detalles del problema entonces se
obtendrán los requerimientos de información que ayudarán a traducir el problema real en
un esquema conceptual que se detallarán en el punto 4.4.2, después de haber obtenido
los requerimientos de información, se diseñan en módulos funcionales, de tal manera que
se define la forma en que se conforma el Sistema ITCG para el funcionamiento y uso del
mismo.
4.4.1 Enunciado del Problema
Para iniciar el análisis de requerimientos primero se estableció el problema, que se
presenta a continuación: La Unidad de Cómputo del Centro Universitario de la Costa Sur
es la
encargada de los laboratorios de cómputo, es también la encargada de
proporcionar apoyo al desarrollo de la tecnología instruccional, al desarrollo de
programas académicos en red que requieran del sistema de telecomunicaciones, el
diseñar y adecuar los espacios donde se presten servicios de cómputo e informática así
como soporte informático a todo el campus universitario.
El personal que labora dentro de estas instalaciones está constituido por prestadores de
servicio social y el encargado de coordinar los trabajos que realizan los becarios y
prestadores de servicio social son:
Apoyar el desarrollo de programas de tecnología instruccional, como laboratorio
AVI (Aula de Video Interactivo), diseño gráfico, diseño Web.
Apoyar el desarrollo de programas académicos en red que requieran del sistema
de telecomunicaciones.
Promover y apoyar los programas de capacitación y el desarrollo de la cultura
informática y de la comunicación para la comunidad del Centro Universitario.
Asesorar a la comunidad del centro Universitario para la adquisición de equipos
de cómputo que mejor se adapten a las necesidades del solicitante y de apoyo a
los procesos de aprendizaje.
64
Asegurar el mantenimiento y uso adecuado de las instalaciones y equipo
dedicado a los sistemas de cómputo y telecomunicaciones educativo.
Revisar permanentemente las necesidades en materia de equipo de cómputo y
telecomunicaciones para asegurar su actualización.
Integrar las propuestas de requisición de software educativo de las diferentes
instancias del centro universitario para su adquisición.
Diseñar y adecuar los espacios donde se presten servicios de cómputo e
informática.
Configurar, instalar equipos de cómputo, servidores, cableado para redes de
datos y telefonía, administración del conmutador, reparación de equipo,
administración de software, asesoramiento a usuarios de acuerdo con las normas
y procedimientos que establezca la Coordinación General de Sistemas de
Información.
Apoyar los servicios administrativos y académicos del Centro Universitario, y
Aquellas que determine el Coordinador de Tecnologías para el Aprendizaje del
Centro Universitario.
Está Unidad se divide en dos áreas:
Área de Telecomunicaciones y Redes
La función de ésta es esencial, ya que sin los servidores o el mal funcionamiento
de ellos, muchos de los laboratorios quedarían sin servicios, así como información
importante se perdería o quedaría sin resguardo.
Se tiene 3 servidores (UNIX, WIN NT y NOVELL) con los cuales se da servicio de
correo electrónico, cuentas Unix, Windows y Novell. Se administran y se da
soporte a estos servidores. Se otorgan y administran las cuentas de cada servidor
como corresponda si es para buzón, o acceso al servidor para las aplicaciones ahí
instalada.
Área de soporte
Se resuelven problemas de hardware de los equipos reportados, así como
configuración de diversos programas, configuración de redes, actualizaciones de
equipos, además del mantenimiento preventivo y correctivo de los laboratorios de
cómputo.
65
Ya expuesto el problema, se analizó de tal manera que se logro extraer los datos más
importantes que se requirieron para el desarrollo del Sistema ITCG.
4.4.2 Requerimientos de Información
Para desarrollar el Sistema ITCG se observaron las actividades mencionadas en el punto
4.4.1 del Enunciado del Problema, y se registraron datos de acuerdo a las necesidades
de la unidad de cómputo. Los requerimientos de información son los siguientes:
Datos del Usuario: Código, Nombre, Carrera, Teléfono, Domicilio, Identificación
Datos de Servicios:
o
Computadoras: Serie, Nombre.
o
Aulas: Código, Nombre.
Datos de Reservación: Código, No. Computadora, No. de Aula, Nombre de
Usuario, Hora Inicio, Hora Final, Fecha.
4.4.3 Módulos Funcionales
Los requerimientos funcionales son la forma en que se van estructurar los módulos que
conforman al Sistema ITCG de manera generalizada, para obtener un panorama amplio
para desarrollar el Sistema ITCG.
En la Figura 4.3 se ilustra un esquema el cual, manera general da a conocer como se
compone el Sistema ITCG:
66
MÓDULOS
Servidor 1
Sistema de
OPCIONES/SERVICIOS
Servicio Internet.
Snort.
Filtrado y
Puente
monitoreo de
principal de Internet o
paquetes de
Red y el Router principal.
entre
servicio
Red.
Sistema ITCG
Servidor 2
Control y
Reservaciones.
Usuarios.
Configuración
Equipos.
del Sistema.
Reportes.
Reglas.
Cliente.
Aplicación que
controla los
ODBC.
equipos
clientes.
Figura 4.3 Diagrama del Sistema ITCG
El sistema cuenta con tres módulos funcionales donde cada uno se interconecta entre sí,
los cuales se presentaran a detalle en el desarrollo de cada uno de los módulos en el
tema 4.6, ver Figura 4.4.
Los Módulos son:
Módulo Servidor 1: Este módulo representa a un Servidor en Fedora donde
su función como puente entre la conexión a internet y el ruteador ayuda a
que todos los datos o tramas sean analizados y procesados por una
aplicación especializada llamada Snort.
Módulo Servidor 2: Este módulo representa un Servidor en Windows en el
cual se encuentra instalado un sistema de información tanto como para
usuarios de préstamo, como para usuario administrados de aplicaciones.
67
Módulo Cliente: Este módulo se desarrolló en Visual Basic que se instala
en el equipo de préstamos y permite controlar cada equipo que utilizaran
los usuarios.
Módulo 1
Módulo 2
Módulo 3
Figura 4.4 Módulos del Sistema ITCG
4.5. Diseño
Con base al modelo Incremental propuesto, en la etapa de diseño se describen las
actividades desarrolladas para el Sistema ITCG, donde tales actividades corresponden al
diseño del modelo Entidad-Relación, análisis de tipos de entidad, tipos de interrelación y
conversión a tablas.
4.5.1 Diseño del Modelo Entidad-Relación
A través del modelo de Entidad-Relación se analiza el problema del mundo real y se
captura por medio de diagramas obteniendo datos específicos de cada necesidad.
68
Con base a la fuente que se utilizó para el presente proyecto, el libro Diseño de Base de
Datos Problemas Resueltos [10L], es importante considerar que la forma de graficar los
modelos conceptuales son lo mismo que adopta el libro [pág. 2, 7, 8, 9]. De igual forma la
metodología de normalización fue adoptada para este proyecto [pág. 313].
A continuación se explican los puntos relacionados para llegar a obtener la base de
datos del Sistema.
4.5.1.1 Análisis de los tipos de entidad
Después de analizar el enunciado problema se obtuvieron los requerimientos de
información y se representan las siguientes entidades:
Entidad Usuario: Representa a un ser del mundo real, el cual es quien solicita
reservaciones de equipo (Figura 4.5).
Figura 4.5 Entidad Usuario
(Por espacio no se representan el total de atributos que acontinuación se nombran: Id Usuario,
Nombre, Código, Carrera, User, Pass, Privilegio, Domicilio, Teléfono, Organización, No
identificación, Identificación, Acceso, Descripción, Archivo1, Nombre1, Tamanio1, Tipo1, Ruta,
Fotoname, Restricciones, Restricciones_snort, Estatus)
Entidad Equipo: Representa a un objeto del mundo real, es la herramienta
utilizada en las reservaciones por el usuario (Figura 4.6).
69
Figura 4.6 Entidad Equipo
Entidad Laboratorio: Representa a un objeto del mundo real, tiene un conjunto de
equipos usados por los usuarios (Figura 4.7).
Figura 4.7 Entidad Laboratorio
Entidad Carrera: Representa a un objeto del mundo real, el cual es cursado por
los Alumnos identificados como parte de los usuarios (Figura 4.8).
Figura 4.8 Entidad Carrera
Entidad Servicios: Representa a objetos del mundo real, conformados por
proyectores, aulas de trabajo (Figura 4.9).
Figura 4.9 Entidad Servicios
70
4.5.1.2 Análisis de los tipos de Interrelación
Las entidades mencionadas en el tema anterior se encuentran relacionadas de la
siguiente manera en el diagrama Entidad-Relación que se presenta en la figura 4.10.
Reservación de Equipos: En la Figura 4.10 se muestra el diagrama de Entidad-Relación
donde se involucran las entidades Usuario, Equipo, Laboratorio y Carrera.
(1,M)
(M,1
)
(1,1)
Figura 4.10 Modelo Entidad-Relación del Proceso Préstamo de Equipos [10L].
En la interrelación Préstamo se define la actividad de préstamo de equipos, donde el
usuario hace reservación de un equipo, donde dicha relación adquiere atributos para el
registro del préstamo. El usuario a su vez está en relación con una carrera cuando se
trata de los alumnos. Y los laboratorios están relacionados con el equipo por que están
dentro de un laboratorio, dicho dato es importante para el proceso de registro de
préstamo de equipos.
Como se menciono anteriormente este modelo es una representación conceptual de un
problema real, entonces al momento de pasar al proceso de obtención de cardinalidades
entre entidades y la normalización (estos procesos se ejemplifican a continuación), se
obtienen más atributos en la misma relación para la facilitación de una consulta de la
relación de un préstamo usuario-equipo. Si se observa en el punto 4.5.2 de este
71
documento se observa el resultado de las tablas de base de datos, tomando en cuenta en
este caso en particular la reservación de equipos se puede ver que en la tabla 4.11, tiene
más atributos que permiten identificar la relación entre un usuario y el equipo para
préstamo.
Cardinalidad de Mapeo de Entidad-Relación Préstamo de Equipos.
Usuario
Préstamo
Préstamo
Equipo
Un Usuario puede reservar un equipo o diferentes equipos en una o varias veces y en
diferentes tiempos.
Un Equipo sólo puede ser reservado por un usuario, o puede ser reservado por varios
usuarios en diferentes tiempos.
Usuario
Carrera
Un Usuario puede cursar una carrera.
Equipo
Laboratorio
Un Equipo sólo pertenece a un Laboratorio.
Ejemplo de Normalización de Préstamo de Equipos [10L], [54]
Primero se obtienen los atributos de una tabla de registro real
1.
(id_reservación, fecha, hora_inicio,
hora_final, nombre_usuario, carrera,
nombre_equipo, nombre_laboratorio). Si se usará sólo está tabla habría
repetición de datos.
2.
Entonces aplicando la Primera Forma Normal se eliminan los grupos repetitivos y
se crean nuevas tablas asignándoles su clave primaria.
Usuario (id_usuario, nombre, codigo, nick, pass, prvilegio)
Carrera (id_carrera, nombre)
Equipo (id_equipo, nombre, serie, ip, estatus)
Laboratorio (id_laboratorio, nombre, responsable)
72
3.
Como se observa en las tablas no existe una relación entre ellas, y aplicando la
Segunda Forma Normal, se creará la relación necesaria para el registro de
préstamos de equipo creando una tabla nueva de relación.
Usuario (id_usuario, nombre, codigo, nick, pass, prvilegio, id_carrera)
Carrera (id_carrera, nombre)
Equipo (id_equipo, nombre, serie, ip, estatus, id_laboratorio)
Laboratorio (id_laboratorio, nombre, responsable)
Prestamo (id_reservacion, fecha,
hora_inicio,
hora_final,
tiempo, estatus,
id_usuario, id_equipo)
Préstamo de Servicios: En la Figura 4.11 se muestra el diagrama de Entidad-Relación
de las entidades Usuario y Servicios. Está interrelación de préstamo de servicios tiene un
funcionamiento similar al de préstamo de equipos, la diferencia entre estas
interrelaciones, es que está dedicado a los servicios que como tal no se les puede
instalar el módulo cliente, los servicios pueden ser préstamo de proyectores y de aulas de
trabajo.
Figura 4.11 Modelo Entidad-Relación del Proceso de Préstamo de Servicios
Cardinalidad de Mapeo de Entidad-Relación Préstamo de Equipos
Usuario
Préstamo
Préstamo
Servicios
Un Usuario puede reservar un servicio o más en una o varias veces y en diferentes
tiempos.
73
Un Servicio sólo puede ser reservado por un usuario, o puede ser reservado por varios
usuarios en diferentes tiempos.
Ejemplo de Normalización de Préstamo de Servicios [10L] [54]
Primero se obtienen los atributos de una tabla de registro real
1. (id_reservación,
fecha_inicio,
fecha_entrega,
nombre_usuario,
carrera,
nombre_servicio). Si se usará sólo está tabla habría repetición de datos.
2. Entonces aplicando la Primera Forma Normal se eliminan los grupos repetitivos y
se crean nuevas tablas asignándoles su clave primaria.
Usuario (id_usuario, nombre, codigo, nick, pass, prvilegio)
Carrera (id_carrera, nombre)
Servicio (id_servicio, nombre, serie, observaciones, estatus)
3. Como se observa en las tablas no existe una relación entre ellas, y aplicando la
Segunda Forma Normal, se creará la relación necesaria para el registro de
préstamos de equipo creando una tabla nueva de relación.
Usuario (id_usuario, nombre, codigo, nick, pass, prvilegio, id_carrera
Carrera (id_carrera, nombre)
Servicio (id_servicio, nombre, serie, observaciones, estatus)
Prestamo (id_reservacion, fecha_inicio, fecha_entrega, id_usuario, id_servicio)
Historial de URL’s Restringidas: En la Figura 4.12 se muestra el diagrama de EntidadRelación de las entidades Usuario y Equipo. La interrelación de URL Restringidas se
refiere al registro de URL no permitidas para los usuarios, entonces cuando el usuario
ejecuta una URL no permitida se almacena con los atributos Id-Historial, Fecha, Hora y
URL.
Figura 4.12 Modelo Entidad-Relación del Proceso de Historial de URL Restringidas
74
Cardinalidad de Mapeo de Entidad-Relación Préstamo de Equipos:
Usuario
UrlRestringida
UrlRestringida
Equipo
Un usuario puede ejecutar en un equipo una o más URL restringidas.
Un equipo puede ser ejecutada una o más URL restringidas por uno o más Usuarios en
diferentes tiempos.
Ejemplo de Normalización de Préstamo de Servicios [10L][54]
Primero se obtienen los atributos de una tabla de registro real
o
_url, fecha, hora, url, nombre_usuario, carrera, nombre_equipo). Si se
usará sólo está tabla habría repetición de datos.
o
onces aplicando la Primera Forma Normal se eliminan los grupos
repetitivos y se crean nuevas tablas asignándoles su clave primaria.
Usuario (id_usuario, nombre, codigo, nick, pass, prvilegio)
Carrera (id_carrera, nombre)
Equipo (id_equipo, nombre, serie, ip, estatus)
Laboratorio (id_laboratorio, nombre, responsable)
o
o se observa en las tablas no existe una relación entre ellas, y aplicando la
Segunda Forma Normal, se creará la relación necesaria para el registro de
préstamos de equipo creando una tabla nueva de relación.
Usuario (id_usuario, nombre, codigo, nick, pass, prvilegio, id_carrera)
Carrera (id_carrera, nombre)
Equipo (id_equipo, nombre, serie, ip, estatus, id_laboratorio)
Laboratorio (id_laboratorio, nombre, responsable )
Url_Restringidas (id_urlfecha, hora, url, idid_usuario, id_equipo)
La normalización de las tablas al final toma un camino subjetivo [54], ya que en la
marcha del desarrollo de programación del Sistema ITCG, surgieron cambios necesarios
en la tablas, que probablemente ya no cumplan con dicha normalización, pero que al final
funciona de manera robusta en la base de datos.
75
4.5.2 Conversión a Tablas
Ya diseñados los diagramas de Entidad-Relación y normalizado se hace la
conversión a las siguientes tablas (tablas de la 4.3 a la 4.16):
Id_agregar
Id_equipo Id_sofware Nombre_software Nombre_exe
Descripción_agregar Permiso
Tabla 4.3 Agregar Software Equipo
Id_carrera
Carrera
Tabla 4.4 Carrera
Id_cursa
Id_usuario
Id_carrera
Tabla 4.5 Relación usuario y carrera
Id_equipo Nombre_equipo Serie_equipo Estatus
Ip
Tabla 4.6 Equipo
Id_fin_s
Fecha
Tabla 4.7 Fin Semestre
Id
Id equipo
Nombre_firewall Descripción_firewall
Permiso
URL
Tabla 4.8 Firewall
Id_inicio_s
Fecha
Tabla 4.9 Inicio Semestre
76
Id_Lab
Nombre_laboratorio
Responsable
Tabla 4.10 Laboratorio
Id_reservacion
Id_Lab
Fecha_entrega Hora_inicio Hora_final
Id_equipo
Tiempo Id_carrera
Id_usuario
Estatus
Tabla 4.11 Reservaciones
Id_servicios
Nombre_servicio
Serie_servicio
Tabla 4.12 Servicios
Id_usuario
Nombre_usuario
Código
Nick
Pass
Privilegio
Tabla 4.13 Usuarios
Id_prestamo
estatus
Id_usuario
Fecha_entrega
Observaciones
Id_servicios
Fecha_prestamo
Tabla 4.14 Préstamo de Servicios
d_historial
Fecha_url_r
Hora
url
Id_equipo
Id_usuario
Tabla 4.15 Historial URL’s Restringidas
Id_snort Id_usuario Id_equipo
Fecha
Filtro
Descripción_Filtro
Payload Impr_Pant
Tabla 4.16 Historial Snort
77
4.5.3 Diccionario de Datos
En la tabla 4.17 se muestra el diccionario de datos de las tablas principales de la base de
datos utilizadas en el módulo de Servidor 2 del Sistema ITCG.
Nombre
Descripción
Dominio
Carrera
Nombre de la carrera.
Conjunto de cadenas válidas para
Carrera. Con una longitud de 255
caracteres.
Código
Código universitario de usuario.
Fecha
Fecha del fin de semestre.
Fecha_entrega
Fecha de entrega de la reservación Conjunto de cadenas válidas para
de equipo o de servicio.
Fecha. Con una longitud fija de 10
caracteres 'YYYY-MM-DD'.
Fecha_prestamo
Fecha de prestamo de equipo o de Conjunto de cadenas válidas para
servicio.
Fecha. Con una longitud fija de 10
caracteres 'YYYY-MM-DD'.
Fecha_url_r
Fecha de url restringida.
Conjunto de cadenas válidas para
Código. Con una longitud de 255
caracteres.
Descripción_agregar Descripción de agregar software de Conjunto de cadenas válidas para
equipo.
Descripción_Filtro.
Con
una
longitud
de
4.294.967.295
caracteres.
Descripción_Filtro
Descripción del filtro.
Conjunto de cadenas válidas para
Descripción_Filtro.
Con
una
longitud
de
4.294.967.295
caracteres.
Descripción_firewall Descripción de firewall
Conjunto de cadenas válidas para
Descripción_Filtro.
Con
una
longitud
de
4.294.967.295
caracteres.
Estatus
Bandera que indica el estado del Conjunto de cadenas válidas para
equipo o servicio (ocupado o Estatus. Con una longitud de 255
desocupado).
caracteres.
Conjunto de cadenas válidas para
Fecha. Con una longitud fija de 10
caracteres 'YYYY-MM-DD'.
Conjunto de cadenas válidas para
Fecha. Con una longitud fija de 10
caracteres 'YYYY-MM-DD'.
78
Filtro
Nombre del filtro para restricciones Conjunto de cadenas válidas para
en internet
Carrera. Con una longitud de 255
caracteres.
Hora
Hora exacta en que se ejecutó la Conjunto de cadenas válidas para
aplicación no permitida.
Hora. Con una longitud fija de 8
caracteres 'HH:MM: SS'.
Hora_final
Hora en que se finaliza
reservación de equipo.
Hora_inicio
Id_agregar
Id_software
Id_Lab
Id_carrera
Id_cursa
Id_equipo
Id_fin_s
Id_firewall
Id_historial
Id_inicio_s
Id_prestamo
Id_reservación
Id_servicios
la Conjunto de cadenas válidas para
Hora. Con una longitud fija de 8
caracteres 'HH:MM: SS'.
Hora en que va a utilizar el equipo Conjunto de cadenas válidas para
el usuario.
Hora. Con una longitud fija de 8
caracteres 'HH:MM: SS'.
Número identificador para agregar Valor numérico entero positivo
software de equipo
entre el rango de 00000000019999999999.
Número
de
identificador
del Valor numérico entero positivo
software de equipo.
entre el rango de 00000000019999999999.
Identificador del aula al que Valor numérico entero positivo
pertenece el equipo.
entre el rango de 00000000019999999999.
Identificador de la carrera al que Valor numérico entero positivo
pertenece el usuario.
entre el rango de 00000000019999999999.
Identificador de la relación entre Valor numérico entero positivo
carrera y usuario.
entre el rango de 00000000019999999999.
Número de identificador del equipo Valor numérico entero positivo
que tiene registrado el software.
entre el rango de 00000000019999999999.
Número identificador de fin de Valor numérico entero positivo
semestre.
entre el rango de 00000000019999999999.
Número identificador de firewall.
Valor numérico entero positivo
entre el rango de 00000000019999999999.
Número identificador de historial Valor numérico entero positivo
restringidas.
entre el rango de 00000000019999999999.
Número identificador de inicio de Valor numérico entero positivo
semestre.
entre el rango de 00000000019999999999.
Número identificador de préstamo Valor numérico entero positivo
de servicio.
entre el rango de 00000000019999999999.
Número
identificador
de Valor numérico entero positivo
reservación de equipo.
entre el rango de 00000000019999999999.
Número del identificador del Valor numérico entero positivo
servicio.
entre el rango de 0000000001-
79
9999999999.
Id_sofware
Id_snort
Id_usuario
Impr_Pant
Número del
Software.
identificador
del Valor numérico entero positivo
entre el rango de 00000000019999999999.
Número del identificador de historial Valor numérico entero positivo
de snort.
entre el rango de 00000000019999999999.
Número del identificador del Valor numérico entero positivo
usuario.
entre el rango de 00000000019999999999.
Impresión de pantalla del historial Formato de imagen en png.
de snort.
Ip
Número de IP del equipo.
Nick
Nombre
usuario.
Nombre_equipo
Nombre del ejecutable de la Conjunto de cadenas válidas para
aplicación en ejecución del equipo. Nombre. Con una longitud de 255
caracteres.
Nombre_exe
Nombre del proceso ejecutable en Conjunto de cadenas válidas para
el equipo.
Nombre_exe. Con una longitud de
255 caracteres.
Nombre_firewall
Nombre del firewall.
corto
significativo
Conjunto de cadenas válidas para
Ip. Con una longitud de 255
caracteres.
de Conjunto de cadenas válidas para
Nombre. Con una longitud de 255
caracteres.
Conjunto de cadenas válidas para
Nombre_exe. Con una longitud de
255 caracteres.
Nombre_Laboratorio Nombre del laboratorio.
Conjunto de cadenas válidas para
Nombre_exe. Con una longitud de
255 caracteres.
Nombre_servicio
Nombre del servicio.
Conjunto de cadenas válidas para
Servicio. Con una longitud de 255
caracteres.
Nombre_software
Nombre del software.
Conjunto de cadenas válidas para
Servicio. Con una longitud de 255
caracteres.
Nombre_usuario
Nombre del usuario.
Conjunto de cadenas válidas para
Servicio. Con una longitud de 255
caracteres.
Observaciones
Observaciones del servicio.
Conjunto de cadenas válidas para
Observaciones. Con una longitud
de 4.294.967.295 caracteres.
Pass
Password de usuario de acceso al Conjunto de cadenas válidas para
sistema.
Pass. Con una longitud de 255
caracteres.
Payload
Paquete
capturado
con
las Conjunto de cadenas válidas para
evidencias coincidentes al filtro o Archivo1. Con una longitud de
patrón.
4.294.967.295 caracteres.
80
Permiso
Privilegio
Responsable
Serie_equipo
Serie_servicio
Tiempo
url
Bandera para indicar si el software
está permitido ejecutarse en el
equipo (0 y 1).
Privilegio de usuario para el acceso
de
sistema
(Administrador,
usuario).
Responsable de laboratorio.
Valor numérico entero positivo
entre el rango de 01-99.
Conjunto de cadenas válidas para
Privilegio. Con una longitud de 255
caracteres.
Conjunto de cadenas válidas para
Responsable. Con una longitud de
255 caracteres.
Número de indentificación en el Conjunto de cadenas válidas para
modelo del equipo.
Responsable. Con una longitud de
255 caracteres.
Número de indentificación en el Conjunto de cadenas válidas para
modelo del servicio.
Responsable. Con una longitud de
255 caracteres.
Duración de la reservación de Conjunto de cadenas válidas para
equipo.
Hora. Con una longitud fija de 8
caracteres 'HH:MM: SS'.
URL completo.
Conjunto de cadenas válidas para
url. Con una longitud de 255
caracteres.
Tabla 4.17 Diccionario de Datos
4.5.4 Diseño e Implementación de la Interfaz de Usuario
Al analizar el problema del mundo real se obtuvieron datos que permitieron desarrollar
una base de datos, que por consecuencia ahora se tienen que reflejar por medio de una
interfaz, para el manejo y control del Sistema ITCG.
El diseño y desarrollo de las interfaces de usuario se llevaron a cabo con la aplicación de
diferentes programas y lenguajes de programación.
La interfaz de usuario del sistema para realización de reservaciones, y
configuraciones del sistema en general, se desarrolló con lenguaje de
programación de PHP, el diseño de páginas Web con hojas de estilo, y la base
de datos con MySQL.
La interfaz de cliente, se desarrollo con Visual Basic 6, dada a su compatibilidad
con base de datosMySQL.
Dichas interfaces se ilustraran en el punto 4.5.6.
81
4.5.5 Escenarios de Uso
En la figura 4.13, se ilustra el diagrama de casos de uso del Sistema ITCG, en el cual se
indica la funcionalidad o servicios que ofrece dicho sistema.
Prestar equipo
Dar de alta laboratorio
Agregar equipo
Asignar software
Agregar usuario
Imprimir reportes
< Include >
< Include >
< Include >
Validar usuario
< Include >
< Include >
< Include >
Figura 4. 13 Diagrama de casos de uso del sistema ITCG
Un escenario de uso es un conjunto de pasos para que el usuario realice una tarea. De la
tabla 4.18 a la 4.24 se presentarán los escenarios más importantes del Sistema ITCG, ya
que estos fueron pieza fundamental para el desarrollo del Sistema ITCG.
Escenario: Validar usuario
1. El usuario rellena los campos de nombre de usuario y
contraseña.
2. Si los datos son validos, ingresa a la ventana principal del
Sistema ITCG.
3. Si los datos no son correctos, regresa al estado de validación.
Tabla 4.18 Validar Usuario
82
Escenario: Prestar equipo
1. El usuario selecciona el laboratorio.
2. El usuario selecciona el equipo a reservar.
3. Rellena los datos: nombre de usuario, fecha y hora.
4. Presiona botón verificar.
5. Y si está disponible la hora y fecha deseada, presiona reservar.
Tabla 4.19 Prestar equipo
Escenario: Dar de alta laboratorio
1. El usuario rellena los datos: nombre de laboratorio y responsable.
2. Presiona botón guardar laboratorio.
Tabla 4.20 Dar de alta laboratorio
Escenario: Agregar Equipo
1. El usuario rellena los datos: nombre de laboratorio, nombre de
equipo, número de serie y estatus.
2. Presiona botón guardar equipo.
Tabla 4.21 Agregar Equipo
Escenario: Asignar Software
1. El usuario rellena los datos: laboratorio y nombre de equipo.
2. Seleccionar las aplicaciones de permiso o desmarcar si no tiene
permiso de alguna aplicación (después del relleno de datos
automáticamente se listarán las aplicaciones del equipo).
Tabla 4.22 Asignar Software
83
Escenario: Agregar Usuario
1. El usuario rellena los datos: nombre, código, privilegio, carrera,
usuario, contraseña, domicilio, teléfono, escuela, identificación,
No. de Identificación, acceso y foto.
2.
Presiona botón guardar usuario.
Tabla 4.23 Agregar Usuario
Escenario: Imprimir Reportes
3. El usuario selecciona el reporte que desea: acceso de equipos
por mes, accesos de equipos por carrera, sanciones.
4. Y se genera un reporte en formato PDF, donde tiene la opción de
imprimir.
Tabla 4.24 Imprimir Reportes
Conexión entre módulos
En la figura 4.14 Se puede observar que los 3 módulos que conforman el proyecto de
tesis (Snort, Sistema ITCG y Cliente), se conectan a una base de datos en común. El
módulo cliente se conecta a la base de datos por medio de una interface llamada OBDC
que permite un flujo de datos para poder restringir programas o contenido no permitidos.
El Sistema ITCG está dividido en dos partes, la primera es la sección donde sólo una
persona (Operador) puede administrar los permisos y la segunda sección es en donde el
usuario puede reservar equipos, laboratorios o servicios. A su vez el usuario tiene acceso
al sistema cliente que está en el equipo reservado, donde se le comunica el tiempo de
uso, y mensajes de permisos.
Figura 4.14 Conexión entre módulos
84
4.5.6 Estructura de la Interfaz de Usuario
Al diseñar los escenarios de uso, permitieron estructurar el diseño de las ventanas del
sistema ITCG que son las que ve el usuario.
Al ejecutar el sistema ITCG se abre una ventana principal, junto con un menú general,
que permite vincularse a cada ventana del sistema. En la Tabla 4.25 se muestra el
esquema de la estructura general de la interfaz de usuario.
Nombre de la Ventana
Propósito.
Ventana Validación
En está ventana se validará el usuario,
proporcionando su usuario y contraseña
en la misma.
Ventana Principal
Predeterminadamente se abrirá en la
ventana
principal,
el
proceso
de
Préstamo de Equipos, que a su vez por
medio del menú se podrá acceder a otra
ventana del sistema.
Ventana Préstamo de Equipos
En está ventana se accederá a los
laboratorios, para reservación de equipos
según su disponibilidad por hora y fecha.
Ventana Servicios
Se
tiene
acceso
a
los
servicios
disponibles, para su reservación.
Venta Administración URL
Está ventana tiene cierta vinculación en
la base de datos hacia el sistema cliente
hecho en Visual Basic,
programa
cliente
registra
el cual el
las
URL’s
visitadas en cierto equipo. Entonces en
está ventana se listan las URL’s del
equipo para su control y supervisión.
Ventana URL de Equipos
Su
propósito
es
registrar
URL’s
específicas y conocidas para el bloqueo
del uso de la URL en los equipos.
Ventana Agregar Usuario
Aquí es en donde se va a capturar los
85
datos necesarios para dar de alta a un
usuario.
Ventana Modificar Usuario
En está ventana se selecciona el Usuario
que se le modificarán datos.
Ventana Aplicaciones no Permitidas
En está ventana se podrá visualizar las
aplicaciones abiertas no permitidas, ya
sea por usuario, laboratorio o equipo.
Ventana Acciones URL no Permitidas
En está ventana se podrá visualizar las
URL’s navegadas no permitidas, ya sea
por usuario, laboratorio o equipo.
Ventana Historial URL
Aquí se visualizarán las URL’s usadas ya
sea por equipo, laboratorio o usuarios.
Ventana Agregar Laboratorio
En
está
ventana
se
captura
la
información necesaria para dar de alta un
laboratorio.
Ventana Modificar Laboratorio
Se selecciona el laboratorio que se desea
modificar.
Ventana Agregar Equipo
Se captura los datos de equipo para dar
de alta.
Ventana Modificar Equipo
Se selecciona el equipo para poder
modificar algún dato del mismo.
Ventana Asignar Software a Equipos
Se listan las aplicaciones registradas por
equipo, y se les asigna el permiso
deseado o necesario.
Ventana Agregar Carrera
Se introducen los datos de carrera nueva
para registrarla en la base de datos.
Ventana Modificar Carrera
Se selecciona la carrera a la cual se le
modificarán datos.
Ventana Agregar Servicios
Se capturan los datos necesarios para
agregar un servicio.
Ventana Modificar Servicios
Se selecciona el servicio para modificarle
los datos necesarios.
Venta Alertas Frecuentes IP’s
Se listaran las alertas de IP’s frecuentes,
obtenidas por el Servidor 1 analizador del
86
tráfico de la red.
Ventana Reporte de Alertas Gral
Se obtienen las alertas en un reporte en
glosario.
Ventana Alertas de Usuarios
Se listan las alertas generadas por
usuario.
Ventana Acceso de Equipos por Mes
Se imprime un reporte en PDF de los
equipos usados por mes.
Ventana Acceso de Equipos por Carrera
Se imprime un reporte en PDF de los
equipos usados por carrera.
Ventana de Acceso de Carreras
Se imprime un reporte en PDF de los
accesos por carrera.
Ventana Sanciones de Usuarios por Mes
Se imprime un reporte en PDF de las
sanciones registradas de usuarios por
mes.
Ventana Filtros de Tráfico de Red
Se
asignan
datos
necesarios
para
agregar alertas o filtros para tomar como
parámetros de análisis de tramas de la
red en el Servidor 1 analizador de red.
Tabla 4.25 Estructura de Interfaz de usuario del Módulo Servidor 2
Después de haber diseñado la base de datos, los escenarios de uso y las interfaces de
usuario, entonces procedió a la programación del Sistema ITCG donde se describirá en el
punto 4.6.
4.6 Código
En este punto de acuerdo al Modelo Incremental, las actividades de la fase de Código
son los módulos que se desarrollaron para el Sistema ITCG, creados con las tecnologías
de programación en PHP, Visual Basic, y con herramientas como Snort, ODBC.
Como se establecieron los Módulos Funcionales en el análisis de requerimientos en los
siguientes temas, se explica el proceso que se llevó acabo para el desarrollo en código.
87
4.6.1 Desarrollo Módulo Servidor 1
Consiste en hacer una función de puente y
monitoreo de la red, por tal motivo es
interconectado entre dos puntos importantes (eth0 y eth1): Internet y el Router (ver
Glosario), consiguiendo así rastrear y monitorear todo el tráfico de la red, ya que todas
las peticiones y respuestas hacia WAN-Internet (ver Glosario) pasarán por el Servidor
Las características del Servidor 1 son:
Su plataforma es Linux Fedora (ver Glosario), se eligió un sistema Linux porque
la aplicación Snort fue desarrollado especialmente bajo está plataforma, por lo
tanto en Windows no funcionan todas sus librerías.
Snort (ver Glosario) es una herramienta importante en el Sistema ITCG, ya que se
encarga de hacer el monitoreo de los paquetes de toda la red.
Snort es configurado en la red LAN que se quiere rastrear.
Para que Snort sea completo, se utilizan reglas o patrones definidos para buscar
en cada trama que pasa por las interfaces de red una coincidencia de información
con las reglas (ejemplo: Si se quiere buscar la palabra sexo, se agrega en las
reglas el patrón “sexo”, y cada paquete que pasa por la interfaz de red eth1, es
revisado por Snort en busca de coincidencias y concurrencias, al momento de
haber una coincidencia se toma la parte del paquete llamado “datapayload” donde
contiene la palabra “sexo” y es guardado en la base de datos con fecha y hora
exacta, así como el número de la dirección IP origen y destino, a esto se le llama
alerta. A continuación se agrega un ejemplo de una regla de Snort:
alerttcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
(msg:"Alerta de información Sexo"; content:"sexo"; nocase;)
En el protocolo tcp.
$EXTERNAL_NET= Internet.
$HOME_NET = Red LAN.
Msg: Mensaje que aparecerá cuando se ejecute la alerta.
Content: Patrón que se quiere buscar (sexo).
Nocase= Que busque un patrón sin tomar en cuenta mayúsculas y
minúsculas.
Servidor DHCP el cual se instaló en Fedora y se configuró para proporcionar
servicios de Internet por medio de unSwitch a un Host.
88
Snort tiene una base de datos en MySQL donde se guardan las tramas de
acuerdo a las reglas que se le asignan.
Contiene dos tarjetas de red, eth0 es la que se conecta hacia el servicio directo de
Internet, y eth1 es la que se conecta al Switch. Ver Figura 4.15.
Figura 4.15 Módulo Servidor 1 del Sistema ITCG
Para entender de manera más explicita la función de snort en el Servidor 1, a
continuación se presenta la Funcionalidad de Snort.
El modo monitor "monitor mode" es el modo en el que interfaces de red ethernet o WLAN
pueden escuchar el tráfico de red diferente al direccionado para dicha interfaz.
Snort es una aplicación que se apoya de las interfaces de red en modo monitor, donde es
posible leer el tráfico y analizar los paquetes por cada una de sus partes, los procesa en
tiempo real, obteniendo la información que se describe a continuación y que se ilustra en
la Figura 4.16:
89
Formato de la cabecera (header) del TCP
Figura 4.16 Formato Cabecera TCP
Puerto origen:(16 bits). Puerto de la máquina origen. Al igual que el puerto
destino es necesario para identificar la conexión actual.
Puerto destino:(16 bits). Puerto de la máquina destino.
Número de secuencia:(32 bits). Indica el número de secuencia del primer byte
que trasporta el segmento.
Número de acuse de recibo:(32 bits). Indica el número de secuencia del
siguiente byte que se espera recibir. Con este campo se indica al otro extremo de
la conexión que los bytes anteriores se han recibido correctamente.
Posición de los datos:(4 bits). Longitud de la cabecera medida en múltiplos de
32 bits (4 bytes). El valor mínimo de este campo es 5, que corresponde a un
segmento sin datos (20 bytes).
Reservado:(6 bits). bits reservados para un posible uso futuro.
Bits de código o indicadores:(6 bits). Los bits de código determinan el propósito
y contenido del segmento. A continuación se explica el significado de cada uno de
estos bits (mostrados de izquierda a derecha) si está a 1.
Ventana:(16 bits). Número de bytes que el emisor del segmento está dispuesto a
aceptar por parte del destino.
Suma de verificación:(24 bits). Suma de comprobación de errores del segmento
actual. Para su cálculo se utiliza una pseudo-cabecera que también incluye las
direcciones IP origen y destino.
90
Puntero de urgencia:(8 bits). Se utiliza cuando se están enviando datos urgentes
que tienen preferencia sobre todos los demás e indica el siguiente byte del campo
Datos que sigue a los datos urgentes. Esto le permite al destino identificar donde
terminan los datos urgentes. Nótese que un mismo segmento puede contener
tanto datos urgentes (al principio) como normales (después de los urgentes).
Opciones:(variable). Si está presente únicamente se define una opción: el
tamaño máximo de segmento que será aceptado.
Relleno: Se utiliza para que la longitud de la cabecera sea múltiplo de 32 bits.
Datos: Información que envía la aplicación.
Tomando en cuenta el diagrama y el significado de cada una de las partes de un
paquete, el campo de datos es la primer parte que lee Snort, donde analiza el contenido
de información y lo compara por medio de los patrones o palabras claves, y si coincide
una palabra clave dentro del contenido, se obtiene en tiempo real la cabecera y los datos
de la trama y se guarda en una base de datos (Ver Figura 4.17).
Figura 4.17 Trama en Acid
La información guardada en la base de datos como se visualiza en la Figura 4.16,
contiene todo el encabezado de un paquete, en el nivel META, se guarda la fecha exacta
con tiempo, el protocolo utilizado y el identificador único en base de datos, en el nivel IP,
se guardan la IP origen y destino con sus respectivas informaciones, en el nivel TCP
91
(aquí puede ser otro protocolo) se guarda toda la información del protocolo, y en el nivel
DATA, se guarda la información obtenida por Snort de acuerdo a un patrón o palabra
clave.
El Módulo cliente1 estando en ejecución obtiene y realiza las siguientes consultas.
1. $IP = Obtiene la IP del equipo.
2. $hora-exacta = Obtiene la fecha y hora exacta actual del Módulo Servidor 1.
3. $usuario = Obtiene el nombre de usuario que se encuentra utilizando el equipo.
4. $hora-acceso = Obtiene la fecha y hora exacta de acceso del usuario al equipo.
5. $hora-termino= Obtiene la fecha y hora exacta cuando termina la reservación del
equipo.
6. $paquetes-guardados = Detecta que existan paquetes guardados en el Módulo
Servidor 1.
7. Existiendo paquetes verifica el encabezado de cada paquete.
8. $hora-paquete = Obtiene el campo TIME del paquete capturado por Snort del
paquete.
9. $ip-origen = Obtiene el campo ip origen (sourceaddr) del paquete.
10. $ip_destino = Obtiene el campo ip destino (destaddr) del paquete.
11. $datapayload = Obtiene los datos del paquete.
12. $signature-name = Obtiene el nombre de la clasificación de la alerta del paquete
capturado por Snort (ejemplo: Pornografía, CHAT, etc…)
Si la $hora-exacta >= $hora-acceso, y
Si la $hora-exacta < $hora-termino, y
Si la $hora-paquete >= $hora-acceso, y
Si la $hora-paquete< $hora-termino, y
Al ejecutarse las condiciones y son verdaderas, se sabe que hay un paquete que coincide
a un paquete guardado en la base de datos ejecutado por un equipo. Entonces:
Si $IP = $ip_origen, o
Si $IP = $ip_destino
En caso de que resulte verdadero la condición de verificación de IP, el Módulo Cliente1
detecta que se a efectuado una operación no permitida, y es guardado en la base de
datos de ITCG, donde se guarda:
92
$IP
$usuario
$ip_origen
$ip_destino
$datapayload
$signature-name
En lo que concierne en redes de computadoras, existen diversas herramientas para
analizar el tráfico de una red, así como aplicar reglas de seguridad de una red.
Herramientas como Ethereal, aircrack, Snort entre otros, son los mejores analizadores de
tráfico que existe, se optó por Snortpor que es compatible con base de datos relacionales
(MySQL, postgresql), y hace posible generar alertas por medio de patrones que se
encuentre en un paquete y guardarlo en una base de datos.
Fue necesario incluir distintas plataformas operativas (Fedora(GNU/Linux) y Windows), y
así generar una interfaz propia para obtener los resultados de un sistema inteligente.
Para analizar el tráfico de red se utilizó sistema operativo con núcleo Linux, por la
robustez, y la facilidad de ejecutar aplicaciones en segundo plano, costos muy bajos,
facilidad de acceso al código fuente.
La herramienta de Snort fue desarrollado bajo la plataforma operativa de núcleo Linux,
por lo tanto fue necesario instalar y configurar un equipo con sistema operativo
FedoraCore 6, como servidor DHCP, con dos interfaces de red, (eth0) una para obtener
el Internet y (eth1) otra para proveer el servicio de Internet, operando como puente
(bridge) trasladando todo el tráfico generado por los equipos clientes.
Se utilizó el módulo Servidor 2 con sistema operativo Windows, para almacenar la
información de la base de datos generada por el Sistema ITCG y los paquetes
capturados por el MóduloServidor 1.
93
4.6.2 Desarrollo Módulo Servidor 2
Este módulo está implementado en la plataforma de Windows, se le instaló y configuró un
servidor Apache Appserv. El Sistema ITCG se desarrolló en PHP, MySQL y Hojas de
Estilo CSS. Su objetivo principal es la de Administrar los equipos en préstamo de forma
dinámica, de tal forma que el usuario puede reservar de forma remota un equipo.
A su vez existe un usuario administrador que se encarga de configurar y capturar los
datos necesarios como reglas de filtrado, registros de software, permisos de uso de
software, registros de URLS, reportes.
Características principales son:
Da de alta a tres diferentes tipos de Usuario:
o
Administrador: Acceso a todas las configuraciones del sistema.
o
Usuario Interno: Alumnos, Académicos y Profesores.
o
Usuario Externo: Visitantes.
Los usuarios internos y externos, tienes acceso sólo a reservaciones de
servicio.
Se pueden reservar equipos, y servicios de préstamo de laboratorio, y de
proyectores.
Registrar reglas para el filtrado de las tramas que se analizan en el
Servidor 1, la comunicación es por medio de sentencias de MySQL que
hacen la conexión remota a otra base de datos en la red, en este caso a la
base de datos de Snort.
Registro de equipos.
Registra software a equipos y asignar el permiso de uso.
Registrar URL’s específicas para denegar a uno o muchos equipos.
Genera reportes de uso de equipos por mes, por carrera y reportes de
sanciones. Ver Figura 4.18.
94
Figura 4.18 Módulo Servidor 2 del Sistema ITCG
Esencialmente existe varios tipos de datos enfocados a diferentes objetivos, los datos
que captura del usuario administrador son valores importantes que a la hora de que el
módulo cliente está operando se revisen los paquetes y sus parámetros lo cual se verifica
cuando alguien está infringiendo el uso de los equipos.
Y otros datos son los que permiten la reservación de equipos, laboratorios, donde de
acuerdo a un tiempo y fecha agendado en un calendario permite que el usuario que
utilizara el equipo sea desbloqueado al colocar su contraseña y esos mismos datos
bloquearan el equipo cuando el tiempo haya sido concluido.
4.6.3 Desarrollo Módulo Cliente
Se diseño en el lenguaje de programación Visual Basic (ver Glosario), su funcionalidad
principal es el monitoreo de las aplicaciones que se usan en una computadora, la
instalación está en un sólo paquete que contiene las librerías necesarias para funcionar
en la plataforma Windows. La aplicación cliente cuenta con la compatibilidad de bases de
datos MySQL, y para lograr la conexión del cliente al Servidor 1 se instala en la
computadora una herramienta que se llama ODBC ver Figura 4.19, a la cual en su
configuración se le registra el número de la dirección IP del servidor a conectarse, el
usuario y contraseña de la base de datos y el nombre de la base datos. Las
características de este módulo son:
95
La interacción con el usuario, es una ventana de validación, y si el usuario
es el correcto, entonces se visualiza una pequeña ventana, donde se
mostrarán datos como fotografía, nombre de usuario, el tiempo
transcurrido y un botón de cerrar sesión.
Cuando el usuario intenta abrir aplicaciones que no son permitidas usar en
dicha computadora, el sistema cliente envía un aviso que la aplicación no
es permitida, y a su vez envía está información a la base de datos del
Servidor 1.
El Administrador tomará la decisión de cuantos intentos de tolerancia se le
permitirá al usuario, y si el usuario rebasa estos intentos, entonces se le
bloquea el equipo volviendo a la ventana de validación, sólo el
Administrador puede desbloquear al usuario cambiando su opción de
privilegios. Ver Figura 4.20.
Aplicación
Admin
Aplicación
User
Servidor
BD
ODBC
Cliente
Figura 4.19 Comunicación de Aplicación Cliente a Servidor
Figura 4.20 Módulo Cliente del Sistema ITCG
96
Tanto los Módulos Servidor 1, Servidor 2 y Cliente conforman en conjunto la
característica inteligente, ya que cada uno maneja funciones inteligentes obteniendo
información de software como (Snort, ODBC, MySQL, etc.) que se comunican entre si,
para manipular y aplicar los filtros correspondientes, para integrar el Sistema ITCG en
general.
4.6.4 Ventanas de la Interfaz de Usuario
A continuación se presentan las ventanas principales del Sistema, donde se controla y se
configura todo el Sistema en General.
Al entrar a la página
del Sistema ITCG, la primera ventana que se abre es la de
validación de Usuario. Como se muestra en la Figura 4.21, el sistema solicita los datos
del Usuario: Nombre de Usuario y Contraseña.
Figura 4.21 Ventana de Validación
4.6.4.1 Préstamo de Equipos
Después de la validación se abre la Ventana Principal, donde se verá un menú general, y
la venta de Préstamo de Equipos.
En la Figura 4.22 se muestra el acceso inicial de la ventana de préstamo de equipos, en
donde al seleccionar un laboratorio se visualizarán los equipos para poder hacer la
reservación deseada.
97
Figura 4.22 Ventana de Préstamo de Equipos
4.6.4.2 Servicios
En la Figura 4.23 se observa la ventana de servicios, en donde se hacen las
reservaciones de los mismos, seleccionando el deseado, se dan los datos de la fecha y la
hora para la reservación.
Figura 4.23 Ventana de Servicios
98
4.6.4.3 Administración URL
En la Figura 4.24 se muestra la venta de administración de URL’s donde se puede elegir
por laboratorio y equipo, para visualizar las URL’s navegadas en el equipo.
Figura 4.24 Ventana de Administración URL
4.6.4.4 Administración URL de Equipos
En la Figura 4.25 se observa la ventana para asignar URL a equipos de un Laboratorio.
Figura 4.25 Ventana de Administración de URL de Equipos
99
4.6.4.5 Agregar Usuario
En la Figura 4.26 se muestra la ventana para agregar usuario, donde se llenarán los
datos correspondientes para darlo de alta.
Figura 4.26 Ventana Agregar Usuario
4.6.4.6 Modificar Usuario
En la Figura 4.27 se observa la ventana para modificar los datos de un usuario. Se
selecciona el usuario a modificar, se presentan sus datos, y se dan las facilidades para
modificar cualquiera de éstos.
100
Figura 4.27 Ventana Modificar Usuario
4.6.4.7 Historial
En el Historial se tienen las opciones de Aplicaciones no Permitidas, Acciones URL no
permitidas e Historial de URL. En la Figura 4.28 se ve la ventana de aplicaciones no
permitidas, que al seleccionar el usuario, laboratorio y equipo se listarán las aplicaciones
que el usuario ha abierto y que no son permitidas.
Figura 4.28 Ventana de Aplicaciones no Permitidas
101
4.6.4.8 Configuración
En las configuraciones se pueden hacer diferentes actividades como: asignar y modificar
laboratorios, equipos, carrera, servicios y asignar software. En la Figura 4.29 se observa
la ventana de Asignación de software a Equipos, que para ello se selecciona el
laboratorio y el equipo en la combo box, después automáticamente se despliegan los
paquetes de software que contiene el equipo. Para asignarle permiso de uso se
selecciona la casilla de verificación adecuada, que en caso contrario para quitarle el
permiso de uso se deselecciona el combo box que le corresponde.
Figura 4.29 Ventana Asignar Software a Equipos
4.6.4.9 Tráfico de Red
En tráfico de red, se puede acceder a Alertas Frecuentes y a Reportes de Alerta. Está
sección está ligada al módulo Servidor 1 de la base de datos de Snort, donde al acceder
a estas ventas se listan las alertas registradas por Snort. En la Figura 4.30 se muestra la
ventana de reporte de alertas arrojadas por la aplicación Snort.
102
Figura 4.30 Ventana de Reportes de Alerta
4.6.4.10 Reportes
Aquí se muestran diferentes tipos de reportes: Acceso de Equipos por Mes, Acceso de
Equipos por Carrera, Acceso de Carreras y Sanciones. En la Figura 4.31 se observa un
reporte en una gráfica de Accesos a Equipos por Mes.
Figura 4.31 Ventana de Reportes de Accesos a Equipos por Mes
En la Figura 4.31 se muestra la ventana de reporte de Accesos en formato PDF que se
abre al presionar el botón de ver accesos que se muestra en la Figura 4.32.
103
Figura 4.32 Ventana de Reporte de Accesos
4.6.4.11 Aplicar Alertas
En la ventana de Filtro de Tráfico de Red que se observa el la Figura 4.33, se puede
asignar reglas de Palabras, para el análisis de tramas en módulo Servidor 1 en Snort.
Figura 4.33 Ventana de Filtros de Tráfico de Red
104
4.7. Pruebas
En el modelo Incremental, las actividades que se realizaron para las pruebas se detallan
en el siguiente Capitulo de Pruebas y Resultados.
105
Capitulo 5
Pruebas y
Resultados
106
5.1 Métodos de Prueba
La fase de pruebas del sistema tiene como objetivo verificar el sistema para comprobar si
éste cumple con los requisitos. La técnica que se empleó para la especificación funcional
fue el modelo de casos de uso. Las principales ventajas de los casos de uso son que
ocultan los procesos internos del sistema, son rápidos de construir, fáciles de modificar y
entender. Las pruebas se pueden componer de varios elementos como: interacciones
entre el sistema y la prueba, valores de prueba y resultados esperados. En la Figura 5.1
se muestra el modelo de pruebas que se desarrollo para este proyecto en el cual se
presenta un esquema representativo para hacer pruebas al Sistema ITCG.
Figura 5.1 Modelo de Generación de Pruebas
Para explicar la figura 5.1, se desarrollaron ejemplos de los componentes del modelo de
pruebas, aplicado al proyecto del Sistema ITCG.
Casos de Uso: en la Figura 5.2 se presenta un ejemplo de caso de uso de la
verificación de usuario.
Figura 5.2 Caso de Uso del Proceso de Validación de Usuario
107
Requisitos de información: Se obtienen los datos relacionados con la acción de
verificación.
Nombre de usuario
Contraseña de Usuario
Conexión de base de datos
Comportamiento: En la Figura 5.3 se desarrolla un diagrama de flujo de las
acciones en una verificación.
NO
SI
Figura 5.3 Diagrama de Comportamiento
Datos de Prueba: En la Figura 5.4 se muestra los datos importantes que se
verifican.
Figura 5.4 Modelo de Datos de Prueba
108
Interfaz: En Figura 5.5 se especifica la manera en que interactúa, el usuario con la
ventana de verificación, la cual tiene conexión con la base de datos que contiene
la información del usuario, y en el caso de que los datos del usuario registrados
en la base de datos sean validos, el usuario accede al Sistema ITCG.
Figura 5.5 Interfaz de Validación
Interacción: Se detectan las acciones que se usan en la programación.
Instrucción
Descripción
<input type=”submit” name=”entrar”>
Representa al botón entrar, ocurriendo la
activación de envío de datos de un
formulario.
SELECT * FROM usuario WHERE
Indica la consulta a la base de datos para
user=$nombre_usuario and
la verificación de los datos del usuario.
pass=$contrasena
Tabla 5.1 Acciones del sistema ITCG
Acciones: Corresponde a las actividades
que se definen para resolver las
pruebas, como por ejemplo en la tabla 5.1 se visualizan las acciones registradas
en el proceso de prueba, que llevan a definir las actividades de prueba definidas
en la tabla 5.2.
109
5.2
Descripciones de las Pruebas
En la tabla 5.2 se muestra las pruebas más importantes del sistema ITCG.
Prueba
Solución
1. Probar conexión del Driver ODBC, No funcionó.
para MySQL con Windows,
con el La Solución: Generar un usuario de
usuario: root y la dirección IP: Server.
MySQL con nombre de Administrador y
contraseña:
ITCG,
y
modificando
propiedad con todos los privilegio, con la
opción de cualquier host.
2. Probar conexión de MySQL con Visual Funcionó con éxito. La conexión no
Basic.
requirió de más configuración.
3. Verificar que la aplicación cliente esté Funcionó con éxito.
guardando en la base de datos del
servidor ITCG, el software que se ejecuta
en el sistema.
4. Comparar si un software no permitido Funcionó con éxito.
en la base de datos, en los procesos del
cliente, y si éste se está ejecutado,
mandar
la
acción
de
mensaje
no
permitido y cerrar dicho software.
5. Las URL’s que se están mostrando en Funcionó con éxito.
el navegador, se estén guardando en la
tabla de Administración de URL´s de
ITCG.
6. Restringir URL´s guardadas en la base Funcionó con éxito.
de datos.
7. En las reglas de Snort en busca de
No funcionó
patrones en el paquete de red (Palabra Solución: Prueba No. 7
“Jaime”), con las palabras básicas msg,
content.
8.En las Reglas de Snort se busca el Funcionó con éxito.
paquete de red (Palabra “Jaime”, con las
110
opciones avanzadas: nocase, distance).
9. Reglas de Snort en busca de patrones Funcionó con éxito.
en el paquete de red (Chat).
10. Pruebas de Bloqueo de Equipo por Fallo en las consultas de aplicación
medio de las reglas de Snort.
cliente en la hora de las alertas.
Solución: Obtener la hora con el formato
de hora de MySQL.
11. Reasignación de Equipo a Usuario Funcionó con éxito.
diferente al sancionado.
12. No permitir abrir el administrador de Funcionó con éxito.
Tareas de Windows.
13. Configuración de las tarjetas de red, Se
en el servidor Fedora.
agregaron
configuraciones
enrutamiento de Internet al corta fuegos
iptables, y funcionó con éxito.
14. Configuración de asignación de IP por Funcionó con éxito.
medio de un servidor DNS a los equipos
clientes.
Tabla 5.2 Pruebas principales del sistema ITCG
5.3
Pruebas Fallidas
En relación con la tabla 5.2 se presentan algunas de las pruebas fallidas mas importantes
que se le dedicaron horas de análisis e investigación para resolverlas.
Prueba de Conexión: En el desarrollo del Módulo Cliente, uno de los errores más
significativos fue el de la conexión del Módulo Cliente con el Módulo Servidor 2 por medio
de la aplicación ODBC, esta aplicación se instala en el equipo cliente que forma parte de
la red monitoreada por el Sistema ITCG.
El error que se presentó fue que dicha conexión simplemente no se efectuaba, y tras
analizar e investigar se encontró que el nombre de usuario estaba mal empleado como se
muestra en la Figura 5.6, en el cual se observa que el nombre de usuario de la base de
datos del Módulo Servidor 2 es root y se verifico que este usuario no tenia los suficientes
permisos para lograr una buena conexión remota. Entonces la solución fue crear un
111
nuevo usuario en la base de datos del Módulo Servidor 2 con nombre de “Administrador”
en lugar de “root”, que el usuario Administrador tuviera todos los permisos de conexión.
Figura 5.6 Error de Conexión ODBC con el Servidor 2
Prueba de Bloqueo de Equipo: En las pruebas de bloqueo de equipo en base a las
reglas de Snort, cuando se ejecutaba el Módulo Cliente y al hacer la prueba escribiendo
palabras no permitidas en las reglas, resulto un fallo.
El problema era que al infringir con las palabras no permitidas se hacia el envío de la
hora de infracción con el formato de la hora del equipo cliente. Como no es compatible el
formato de hora del equipo cliente con el formato de hora de la base de datos MySQL
lograba que arrojara un error y se cerrara la aplicación como se muestra en la Figura 5.7.
La solución fue programar en el Módulo Cliente en Visual Basic un código que convierta
el formato de hora de el equipo cliente a el formato de hora de la base de datos MySQL
de el Módulo Servidor 2.
112
Figura 5.7 Error Prueba de Bloqueo de Equipo
Prueba de Reglas: Como las reglas son importantes en el filtrado de los paquetes, la
configuración de las mismas es vital que se hagan de manera correcta.
Cuando las reglas en la aplicación que realiza el análisis en tiempo real de Snort, no son
bien definidas y configuradas antes de ejecutarse, éste no las toma en cuenta, ya que se
debe seguir cierto patrón y formato para que sean evaluadas mientras se monitorea y/o
analiza el tráfico de paquetes en la red, no se efectúa el filtrado de paquetes de manera
correcta, ocasionando que no se registren las alertas de las reglas que se desee analizar
para compáralas, originando con ello que no se efectué el bloqueo pertinente en el
equipo cliente que se cometa la infracción.
Como se muestra en la Figura 5.8, la tabla de las alertas está vacía debido a que cuando
se hacia el uso de la palabra Jaime, no la reconocía y por lo tanto no se almacenaban en
ésta.
Para solucionar este problema, se recurrió a la investigación y al análisis de la base de
datos de Snort, y se descubrió que la solución consistía en que al crear las reglas se
tiene que agregar a la línea los comandos “nocase, distance” (ver Figura 5.9).
113
Figura 5.8 Error de prueba de Reglas de Snort
Figura 5.9 Regla de Snort
5.4 Resultados
Los resultados obtenidos durante el proceso fueron variantes, ya que principalmente se
eligió que tanto el sistema Web como la base de datos y el analizador de la red, estarían
en un mismo servidor y trabajando con el sistema operativo Windows. Dado a
la
incompatibilidad de Snort con el Sistema Operativo Windows, y la lentitud que se
provocaba en el Servidor por la saturación de información en las peticiones de el control
y a el análisis de los paquetes en la red, se decidió separar en dos partes el Servidor,
donde la base datos del sistema Web quedo en el Módulo Servidor 2 bajo el Sistema
Operativo de Windows, y el analizador de la red quedo en el Módulo Servidor 1, que se
configuró con el sistema Fedora de Linux y se instaló la herramienta Snort.
114
Con lo anterior, se logró mayor rapidez, y menos saturación de paquetes. Unas de los
principales inconvenientes encontrados, fue que la versión de Snort para Windows es
muy limitada, por tal razón se decidió usar la versión de Snort para Linux. También se
decidió ubicar el servidor de Linux como principal, y puente entre el servicio de Internet y
el resto de la red, con el motivo de analizar todo el paso de la red y de proveer servicio de
Internet al resto de la red como se explico en el Módulo Servidor 1 en el Capitulo 4.
Ya que se utilizó el Módulo Servidor 1 como puente entre el servicio troncal y el swicth
principal, se determino hacer eso de la herramienta de iptables que contiene el Sistema
Operativo Fedora para dar servicio de Internet a todos los equipos de la red.
Con las pruebas e implantaciones que se hicieron durante el desarrollo se fueron
obteniendo resultados satisfactorios, logrando los objetivos planteados en el Capitulo 1.
Tales resultados se describen a continuación:
Se implemento un Servidor nombrado Módulo Servidor 1 que permitió establecer
procesos
de conexión Internet y de Monitoreo de Red, obteniendo como
resultado el análisis y almacenamiento de los paquetes que recorren la Red.
Se implemento un segundo Servidor llamado Módulo Servidor 2, en donde se
instala un soporte PHP, para la instalación del Sistema de Información que
contendrá y manejará toda la información obtenida en el uso de los Equipos
Clientes y de la Red.
El usuario final de el Sistema ITCG, puede hacer reservaciones de equipos de el
Laboratorio de Cómputo de manera remota siempre y cuando exista una conexión
a Internet.
El Administrador del Sistema ITCG puede dar de alta y modificar usuarios,
equipos, software, reglas de filtrado y laboratorios.
El Sistema ITCG generan reportes de estadísticas en formato PDF tanto
reservaciones como de alertas, ya sea por carrera o por tiempo de un mes.
Se implementó un programa cliente llamado Módulo Cliente, en los equipos que
pertenecen a la Red que se está controlando y monitoreando.
El Módulo Cliente, registra los datos del equipo y de los usuarios que usan los
equipos en la base de datos del el Módulo Servidor 2 y con ello llevar un control
de usuarios validos.
115
El Módulo Cliente cuenta con un sistema de validación de cada reservación, para
no tener duplicidad en fechas y horas iguales en diferentes equipos, al hacer
efectiva su reservación.
Los Equipos Cliente se bloquean cuando el usuario ejecuta programas no
permitidos y cuando en el Módulo Servidor 1 se detectan alertas provocadas por
el mismo equipo que está en uso.
116
Capitulo 6
Conclusiones y
Trabajo Futuro
117
6.1. Conclusiones
Planteamiento de la Hipótesis
“Si se diseña e implementa un sistema inteligente para el monitoreo, control y
administración de los equipos
de cómputo y servicios del laboratorio de cómputo, se
reducirá significativamente el tiempo de espera de los usuarios en el registro y apartado
de los equipos de cómputo, así como el tomar buenas decisiones”.
La hipótesis planteada se comprobó verdadera y se considera una hipótesis puramente
confirmable [8L], ya que no se han presentado condiciones o sucesos que pruebe lo
contrario. Donde cumplió con los parámetros descritos, logrando así reducir los tiempos
de espera para la reservación de equipos de cómputo, obteniendo así un mejor control
y/o administración de los mismos por medio del sistema.
Los resultados obtenidos a través de la hipótesis, se confirma que es verdadera, ya que
cumple con los objetivos basados como parámetros, logrando así restar los tiempo de
espera de reservado de equipo, ya que se podrá hacer de manera remota desde
cualquier lugar con que se cuente conexión a Internet. Además de lograr que la red sea
más segura y de que el buen uso de los equipos en préstamo es monitoreado para así
que el sistema tome sus propias decisiones y bloquee un equipo y se sancione al usuario.
Haciendo énfasis de los objetivos a continuación se muestra una síntesis de los mismos:
En este momento se cuenta con dos servidores, uno basado en Windows como
Módulo Servidor 2, donde se encuentra el Sistema ITCG, el otro servidor como
Módulo Servidor 1 está basado en Linux Fedora donde está aplicada la
herramienta Snort, que ayudará a leer las tramas que viajan en la red y facilitará
la toma de decisiones por el al uso de los equipos, o por el ataque hacia ellos.
El programa cliente será instalado en cada equipo, el cual recogerá datos y
actividades de cada usuario que use el equipo, tal información es enviada a la
base de datos del Módulo Servidor 2.
Respecto Módulo Servidor 1 de Linux con Snort, funciona en multicast, para que
funcione a nivel masivo, lo cual requirió de tiempo de programación, ya que para
lograr que dejara de funcionar en unicast se le agrego al servidor una tarjeta de
red para conectarla con el servicio troncal, y la otra tarjeta de red para conectarla
con el swicth principal de la red, logrando con esto, que todo el tráfico de la red
118
pase por este servidor, permitiendo que la herramienta Snort analice todas las
tramas.
Como una mejora a considerar es que la funcionalidad del sistema, sea de toda
la red del campus de la Universidad de Guadalajara.
Algo que me deja este trabajo es que aprendí a manejar el lenguaje de programación
para desarrollo de aplicaciones de Windows, Visual Basic. En este lenguaje fue posible
desarrollar la aplicación cliente del Sistema ITCG, ya que se aprendió a manejar los
procesos en ejecución del equipo, capturar las URL obtenidas en el Explorer de Windows
y bloquear Equipos.
También fue posible establecer con esta herramienta la conexión a una base de datos
para el registro de todas las aplicaciones, otorgando permisos de ejecución, número de
repeticiones al realizar operaciones no permitidas, el bloqueo de equipo por medio de un
password y una contraseña guardada en una base de datos.
Además que para la obtención de tramas de tráfico en la red, aprendí a utilizar Fedora 6
desarrollado en sistemas GNU/Linux, en la que da la libertad de programar eventos
propios en busca de patrones contenidas en una trama, en modo de alertas, es
representado en el sistema ITCG por medio de una base de datos donde están
guardados los datos que compone una trama (Direcciones IP origen, destino y datos). Al
igual, la utilización de distintas plataformas para conformar un sistema, de las que se
utilizaron Windows y sistemas UNIX/LINUX Fedora 6.
Otra actividad desarrollada en esta aplicación, y que me dejo sorprendido durante el
desarrollo, es que se puede implementar nuevos módulos dependiendo las necesidades
de la aplicación sin salir de la administración y el control acorde de las tecnologías
existentes y en uso que el mercado ofrezca utilizando el análisis y la reingeniería del
software, para actualizar a una aplicación al día, según las necesidades en las que no se
enfrente.
Retomando todo lo que se ha plasmado en este informe a continuación en la tabla 6.1 se
muestra la manera en que se utilizaron las herramientas y aplicaciones de acuerdo a las
necesidades de cada módulo, adaptándolo de tal forma, que al unirse dieran el resultado
final: un sistema inteligente.
119
Fedora: El servidor se le fue instalado una versión Linux
Módulo Servidor 1
(Fedora), ya que la herramienta de Snort es más
completa para Linux.
A su vez Fedora brinda herramientas de administración
de red, lo cual permite administrar servicio de Internet a
la red, monitorearla y controlarla.
Snort: Es la herramienta encargada de analizar los
paquetes de la red, la cual cuenta con un sistema de
reglas, que al programarlas permiten tomar decisiones
preventivas, a su cual al ser monitoreada una trama, y
cumpla con los requisitos de dicha regla, entonces se
almacena
en
una
base
de
datos
de
MySQL
conectándose por medio de sentencias al Módulo
Servidor 2.
Apache Appserv: Este paquete se instaló en un
Módulo Servidor 2
sistema Windows, en el cual contiene un soporte para el
lenguaje de programación PHP y base de datos MYSQL.
PHP: Fue el lenguaje de programación que se utilizó
para crear el la administración de todo el sistema,
creando una interfaz gráfica con ayuda de HTML y
Hojas de estilo (CSS).
MySQL: Es el sistema de base de datos que se utilizó
para crear la base de datos del sistema, con el cual se
usan sentencias para conectarse a su vez con el Módulo
Servidor 1.
Visual Basic: Este lenguaje de programación se utilizó
Módulo Cliente
para crear el módulo cliente, el cual tendrá la función de
verificar cada acción realizada en el equipo en que se le
instale. Dichas actividades serán registradas, a través de
una conexión de la aplicación hacia una vía de
comunicación al Módulo Servidor 2 por medio de la
aplicación ODBC.
ODBC: Se instala en los equipos clientes, para que se
efectúe la comunicación entre el módulo cliente y el
módulo Servidor 2.
Tabla 6.1 Metodología
120
6.4. Trabajo Futuro
Como mejoras a futuro del Sistema ITCG se presentan a continuación:
Implementar una aplicación de Internet para celulares, donde el usuario pueda
reservar equipo o aulas desde su celular con conexión a Internet.
Diseñan un módulo de asignaciones de horarios de laboratorios de cómputo.
Ampliación a control de más de dos campus.
Inserción de más servicios relacionados con los laboratorios, ya sea un control y
registro de accesorios y componentes de cómputo.
Implementar una interfaz que permita comunicar al sistema aquellos usuarios que
cuenten con teléfono celular, para realizar la notificación de, cuando su tiempo de
espera de equipo o aula a expirado, o algún adeudo generado después de alguna
sanción, o cualquier aviso necesario del sistema hacia el usuario, por medio de
mensajes de 2 vías.
Incluir un módulo de control de clase para el profesor, donde pueda ver las
actividades que hacen sus alumnos, tanto de manera visual como textual.
Limitar y controlar el ancho de banda que usan los equipos, para garantizar mejor
velocidad y uso.
121
Capitulo 7
Referencias
122
7.1 Referencias bibliográficas
[1L] CEBALLOS, Fco. Javier. El lenguaje de Programación Java. Editorial
Alfaomega. Fecha de edición 2002.
[2L] HONNEYCUTT, Jerry. El registro de Microsoft Windows 2000. Editorial
Madrid Pearson Educación. Fecha de edición 2001.
[3L] MEYERS, Nathan. Edición Especial Programación Java en Linux.
Editorial Prentice Hall. Fecha de edición Pearson Education 2000.
[4L] RAYA, José, Luís. Aprenda Windows 2000 Server. Editorial
Alfaomega. Fecha de edición Julio 2001.
[5L] RAYA, José Luís. Como construir una Intranet con Windows 2000
Server. Editorial Alfaomega. Fecha de edición Junio 2001.
[6L] TORRES, José. Conceptos de Sistemas Operativos, teoría y práctica.
Editorial Trillas. Fecha de edición Agosto 2001.
[7L] NIETO, Diseño de bases de datos problemas resueltos. Editorial
Alfaomega. Fecha de edición Mayo 2001.
[8L] LOPEZ, Método e hipótesis científicos. Editorial Trillas. Fecha de
edición 3ra 1989, reimpresión 1995.
[9L] GIARRATANO, Joseph. Sistemas expertos, Principios y Programación.
Editorial Thomson. Fecha de edición 2001.
[10L] CASTAÑO, Miguel. Diseño de Base de Datos Relacionales.
7.2 Referencias electrónicas
[7] www.cucsur.udg.mx
[8] http://es.wikipedia.org/wiki/Paquete_de_red
[9] TCP/IP para Windows 2000 Server Autor: José Luís Raya y Cristina
Raya. Capitulo 1: Conceptos Generales de Redes Pág.11
[10]
http://www.rediris.es/cert/doc/unixsec/node26.html#SECTION07610000000
000000000
[11] http://www.maestrosdelweb.com/editorial/snort/
123
[12]
http://www.mygnet.net/codigos/mysql/graficacion/guardar_imprimir_una_im
agen en_mysql_desde_vb.2461
[13]
http://www.esdebian.org/staticpages/index.php/20041021030032927/print
[14]
http://www.ernestoperez.com/documentacion/instalacion_de_un_nids_snort
.html
[15]
http://www.mailxmail.com/curso/informatica/aplicacionesvisualbasic/capitulo
1.htm
[16] http://vbasic.astalaweb.com/API/1_API.asp
[17] http://www.telecable.es/personales/jrubi/index.htm?curso.htm
[18] http://www.programacion.net/codigo/VisualBasic/
[19] http://www.programacion.net/codigo/45/
[20] http://www.elguille.info/vb/VB_PRG.HTM#protpan
[21]
http://www.lawebdelprogramador.com/codigo/mostrar.php?id=93&texto=Vis
ual+Basic
[22] http://www.recursosvisualbasic.com.ar/
[23] http://vbasic.astalaweb.com/_inicio/Portada.asp
[24] http://www.programacion.net/direcciones/visualbasic/
[25] http://programatium.com/vb/faq/index.htm
[26] http://www.recursosvisualbasic.com.ar/htm/menu-principal/ocx-dllactivex-4.htm
[27] http://www.telecable.es/personales/jrubi/index.htm?vbesp.htm
[28] http://www.visual-basic.com.ar/links-es.htm
[29] http://moratiel.com/visualbasic.html
[30] http://www.distintiva.com/jose/sourcecode.html
[31] http://vbmaniaco.webcindario.com/
[32] http://www.winpcap.org/install/default.htm
124
[33] http://www.seguridad.unam.mx/doc/?ap=tutorial&id=155
[34] http://www.wilkinsonpc.com.co/free/articulos/procesos.html
[35] http://www.vbsiglo21.net/articulo1.html
[36]
http://www.gamarod.com.ar/trucos/cerrar_el_internet_explorer_desde_un_p
rograma_vb.asp
[37] http://www.recursosvisualbasic.com.ar/htm/menuprincipal/mis_utilidades.htm
[38] http://www.cssboulevar.com.ar/vb/subcategoria/?id=Varios
[39]
http://www.geocities.com/Athens/Agora/2353/programa/algo_vba/vbasic.ht
m
[40]
http://www.microsoft.com/spanish/msdn/articulos/archivo/140303/voices/od
c_tencodeconverts.asp
[41] http://www.monografias.com/trabajos16/sistemasdistribuidos/sistemas-distribuidos.shtml
[42] http://mx.geocities.com/pcvaqromx/monitor.htm
[43] http://www.netsupportschool.com/ES/index.asp
[44] http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf
[45] http://html.rincondelvago.com/metodos-de-prueba-caja-depandora.html
[46] http://es.wikipedia.org/wiki/CSS
[47] http://www.csi.map.es/csi/silice/Global71.html
[48] http://ditec.um.es/ssdd/tema1.pdf
[49] http://studies.ac.upc.edu/EPSC/FSD/FSD-Mensajes.pdf
[50] http://aurea.es/proyecto/analisis-trama-ip/
[51] http://geneura.ugr.es/~maribel/php/
[52] http://www.webestilo.com/mysql/intro.phtml
[53] http://www.desarrolloweb.com/articulos/1112.php
[54] http://www.evidalia.es/trucos/index_v2-279-29.html
125
Glosario
126
A
ADO: Mecanismos que usan los programas de computadoras para comunicarse con las
bases de datos.
Apache: Es un servidor Web.
ANSI: American National Standards Institute (Instituto de Estándares Nacional
Americano).
ANSI C: En redes de computadoras es el estándar publicado por el Instituto Nacional
Americano de Estándares (ANSI) para el lenguaje de programación C.
ACCESS: Es un enlace de redes de computadoras en ingeniería de software de
administración de base de datos.
ACID: Se denomina ACID a la propiedad de una base de datos para realizar
transacciones seguras.
B
BACKDOOR: Es la vulnerabilidad del sistema para que intrusos tengan la opción de
accesar al mismo para realizar cambios.
BROWSER: Es el programa cliente de un servidor Web, también conocido como
navegador o explorador.
C
CGI: Pequeños programas situados en un servidor Web para poder ser utilizados desde
las páginas Web que se hospeden en dicho servidor.
CSS: Son las hojas de estilo en cascada, lo cual aporta dinamicidad a la página Web que
fue diseñada bajo este esquema
D
DDoS: Ataque de Denegación de Servicio Distribuido. Es un tipo especial de DOS
consistente en la realización de un ataque conjunto y coordinado entre varios equipos
(que pueden ser cientos o miles) hacia un servidor víctima.
DOS: es una familia de sistemas operativos para Computadoras Personales (PC). El
nombre son las siglas de Disk Operating System (sistema operativo de disco). Fue
creado originalmente para computadoras de la familia IBM PC, que utilizaban los
procesadores Intel 8086/8088 de 16 bits.
127
DNS: Es un servicio de búsqueda de datos de uso general, distribuido y multiplicado. Su
utilidad principal es la búsqueda de direcciones IP de sistemas centrales llamados
servidores.
DSN: Representa todo lo relativo a una fuente de datos configurada por el usuario para
conectarse a una base de datos.
DBASE: Es el primer sistema manejador de archivos usado ampliamente para
microcomputadoras.
DHCP: Es un protocolo de red que permite a los nodos de una red IP obtener sus
parámetros de configuración automáticamente.
E
EXCEL: Es una aplicación para crear hojas de cálculo.
F
Fedora: Es un sistema operativo distribuido por Linux.
FILTRADO: Es un programa informático para procesar una corriente de datos.
FINGER: Programa que muestra información acerca de un usuario específico, o acerca
de todos los usuarios conectados a un sistema local o remoto. Habitualmente se muestra
el nombre y apellidos, hora de la última conexión, tiempo de conexión sin actividad, línea
de terminal y situación de éste.
FTP: Protocolo estándar en Internet para transferencia de archivos.
G
GNU: Conjunto de archivos desarrollados por la Free Software Fundation.
GTK: Es un grupo importante de bibliotecas o rutinas para desarrollar interfaces gráficas
de usuario.
GPL: Es una licencia que protege la creación y distribución de software libre.
128
H
HACKER: Es el neologismo utilizado para referirse a un experto en varias o alguna rama
técnica relacionada con la informática: programación, redes de computadoras, sistemas
operativos, hardware de red/voz.
HACKER: Persona que, gracias a sus grandes conocimientos informáticos, puede
introducirse sin permiso en la información que tengan otras computadoras o redes
informáticas de particulares, empresas o instituciones siempre y cuando estén
conectados a Internet.
Es el aspecto físico de equipos, telecomunicaciones y otros dispositivos de tecnologías
de la información Software.
HTML: Es el lenguaje de descripción de páginas habitual en Internet. Sigla HyperText
Markup Language (Lenguaje de Etiquetas de Hipertexto), es el lenguaje de marcado
predominante para la construcción de páginas Web.
I
IDE: Electrónica de unidad integrada que denota la interfaz estándar usada para conectar
fundamentalmente unidades de disco y CD-ROM a una computadora.
IDS: Es el nivel de logro respecto al grado de desarrollo.
ITCG: Sistema de inteligencia para el control y monitoreo de los equipos y servicios de
cómputo del CUCSUR.
IPTABLES: Es un framework disponible en el núcleo Linux que permite interceptar
Manipular paquetes de red.
IP: Es la unidad de información enviada entre sistemas, que proporciona un
servicio de entrega de paquetes básico.
INTERNET: es un método de interconexión descentralizada de redes de computadoras
implementado en un conjunto de protocolos denominado TCP/IP que garantiza que redes
físicas heterogéneas funcionen como una red lógica única.
ISAPI: Internet Server API. Es una API para el servidor Web.
INFORMIX: Es una familia de productos RDBMS de IBM.
L
LAN: Designa a una red de área local, conocida por sus siglas en inglés LAN (Local Área
Network).
129
Libpcap: Es una biblioteca para el lenguaje de programación C para los paquetes de una
red a recoger.
LINK: Conexión con otro documento Web por medio de la dirección URL.
LINUX: Es uno de los ejemplos más prominentes del software libre y del desarrollo
abierto, cuyo código fuente está disponible públicamente para que cualquier persona
pueda
usarlo
libremente,
estudiarlo,
redistribuirlo,
comercializarlo
y,
con
los
conocimientos informáticos adecuados para que puedan modificarlo.
Logs: Son los registros de las actividades de la red.
M
MySQL: Es un sistema de gestión de base de datos.
N
NCSA: Centro Nacional de Aplicaciones de Supercomputación.
NMAP: Es un programa open source que sirve para efectuar escaneos de puertos.
NIDS: Es el sistema de detección de intrusos en una Red.
O
Offline: Es una expresión en inglés que significa Fuera de Línea.
P
PDF: Es una extensión de documentos que pueden distribuirse electrónicamente y tiene
calidad de impresión. El cual necesita el programa adobe Reader para poder ser abierto.
PHP: Es un lenguaje de programación utilizado para la creación de contenidos dinámicos
para sitios Web.
POSTGRESQL: Es un motor de base de datos.
R
RED: Es una estructura con un patrón característico, lo cual se utiliza en diferentes
campos.
RED HAT: Es la compañía responsable de la creación y mantenimiento de una
distribución del sistema operativo GNU/Linux que lleva el mismo nombre: Red Hat
Enterprise Linux, y de otra más, Fedora.
130
Red Ip:
Router: Es una máquina que actúa como puerta para permitir el acceso a los recursos de
una red, independientemente de los protocolos o sistemas operativos de los usuarios.
RTF: Es un formato sencillo estandarizado con diversas incompatibilidades incluso entre
distintas aplicaciones de Microsoft y rara vez se usa para guardar documentación.
S
Script: Es un guión o conjunto de instrucciones que permiten la automatización de tareas
creando pequeñas utilidades.
SERVER: Una computadora o software que ofrece servicios a máquinas de cliente
distantes o las aplicaciones, como el suministro de contenidos de páginas (textos u otros
recursos) o el retorno de los resultados de consultas.
SNORT: Es un sniffer de paquetes y un detector de intrusos basado en red.
SNIFFER: Aplicación, generalmente programada en lenguaje C, que se introduce en un
sistema hackeado para interceptar información en tránsito, habitualmente con el fin de
averiguar contraseñas de usuarios
SQL: lenguaje de consulta estructurado.
Switch: Es un dispositivo electrónico de interconexión de redes de computadoras.
T
TCP/IP: Transmission Control Protocol/Internet Protocol, Protocolo de Control de
Transmisión/Protocolo Internet.
TCPdump: Es un herramienta en línea de comandos cuya utilidad principal es analizar el
tráfico que circula por la red.
U
UNICAST: Es un envío de información desde un único emisor a un único receptor.
URL: Es la cadena de caracteres con la cual se asigna dirección única a cada uno de los
recursos de información disponibles en Internet.
V
Visual Basic: Visual Basic es un lenguaje de programación desarrollado por Alan Cooper
para Microsoft.
131
W
WAN: (Wide Area Network) Explica funcionamiento básico de las interconexiones de las
redes y su forma de comunicación, petición- respuesta.
WEB: Es un dominio de Internet de nivel superior no oficial, que lleva propuesto desde
1995.
WHITEBOARD: Es un programa especial para trabajo en grupo que permite que varias
personas trabajen a la vez en un proyecto. Aunque las personas no estén físicamente en
un mismo lugar, pueden trabajar a la vez desde cualquier punto del planeta a través de
Internet.
132
Apéndices
133
Apéndice A. Manual de Usuario Administrador
Volumen
1
Sistema Inteligente para el Control y Monitoreo de los Equipos y Servicios de Cómputo del
Laboratorio de Cómputo del Centro Universitario de la Costa Sur
Guía de Usuario
Administrador
134
Paso
Entrar al Sistema
1
En la barra de direcciones del navegador de Internet, escribe
http://localhost/ITCG/index.php (Ver Figura A.1) si se está
accediendo desde el servidor donde está instalado el sistema.
También se puede acceder por medio de la dirección IP del Servidor que es
http://10.0.0.2, esta dirección puede ser referenciada desde el mismo servidor
(localmente) o desde los demás equipos que conforman la intranet. Y para acceder vía
remota por Internet dependerá del dominio asignado para el sistema.
Figura A.1 Acceso al Sistema de Información
Paso
Validación
Al entrar al sistema aparece un formulario de validación donde
debes introducir tú nombre de Usuario y Contraseña en el
recuadro de Validación (ver Figura A.2).
2
Figura A.2 Validación de Usuario
135
Reservar Equipos
Si el nombre de usuario y contraseña son correctos, entrarás
al sistema, como se muestra en la Figura A.3.
Paso
3
Figura A.3 Vista Predeterminada del Sistema ITCG
Automáticamente el Sistema abre el módulo de Préstamo de Equipos, en el cual en
primera instancia podrás elegir el laboratorio, al cual desees insertar una o varias
reservaciones de equipo.
Ya elegido el laboratorio pasarás a la siguiente vista que se muestra en la Figura A.4.
Donde se visualizarán los equipos registrados, y su estado ya sea ocupado o
desocupado en ese momento.
Figura A.4 Ventana de Préstamo de Equipos
Si deseas hacer una reservación independientemente del estado del equipo ocupado o
desocupado para otra hora o día, presiona el botón izquierdo del ratón (clic) en el icono
136
del equipo, y pasarás a un formulario donde te permitirá ver el tiempo libre del equipo
para reservar (ver Figura A.5).
Figura A.5 Ventana de préstamo de Equipo con el calendario para elegir otra fecha
Elige la fecha y la hora para reservar el equipo deseado, dando clic en “verificar”, esta
opción ayudará para saber si ya ha sido reservado, o está libre. Como este caso el
usuario es de tipo administrador, tienes como privilegio de reservar y cancelar los estados
de los equipos según la situación, ya sea reservar equipos de un laboratorio durante un
semestre para una clase o cancelar las reservaciones diversas que hayas realizado.
Paso
Servicios
En la Figura A.6 se muestra el módulo para reservar más
servicios como préstamo de laptop, proyectores, aulas, etc.
4
Figura A.6 Préstamo de Servicios
137
Se da un clic en el icono de servicios que se muestra en la Figura A.6, y se abre el
formulario que se muestra en la Figura A.7, donde podrás seleccionar la fecha del día
de préstamo de servicio siguiendo la misma técnica de reservación de equipo.
Figura A.7 Formulario de Reservación de Servicios
Paso
Administración URL
5
Este módulo consiste en la visualización de las URL registradas
por cada equipo de la red, donde directamente se podrá
denegar acceso a dicha página, tomando en cuenta que la URL
no permitida se quiere usar posteriormente. Para acceder a este módulo se elige la
opción del menú general que se llama “Administración de URL”, y se abrirá el formulario
que se muestra en la Figura A.8.
Figura A.8 Administración de URL
138
En la Tabla A.1 se visualizan los pasos para elegir un Laboratorio y un equipo
perteneciente al laboratorio escogido.
a) Se elige Laboratorio
b) Se elige Nombre de Equipo
Tabla A.1 Elección de Equipos y Laboratorio para visualizar las URL
Una vez hecho lo mostrado en la tabla A.1, se presentaran las URL registradas en la
base de datos usada en el equipo elegido como se ilustra en la Figura A.9.
Figura A.9 Ejemplo de lista de URL
Si se observa la Figura A.9, en la tabla se encuentra la columna llamada “descripción”, en
donde se muestran unas casillas de habilitación, cuando están activas significa que si
tienen permiso de utilización. Y si no tiene permiso se deshabilita la casilla
correspondiente a la URL no permitida y no se podrá utilizar en el equipo.
139
Administración URL de Equipos
Paso
Al elegir la opción de “Administración URL de Equipos” en el
menú principal, se abrirá la ventana que se muestra en la Figura
A.10, donde podrás agregar a la base de datos las URL no
permitidas, asignando ya sea a un laboratorio o a todos.
6
Figura A.10 Administración URL de Equipos
Una vez abierta la ventana, se elige el laboratorio, se escribe la URL, una descripción de
la URL, y se da clic en el botón Agregar URL.
Usuarios
Paso
Una vez que se elige el laboratorio, se selecciona la opción de
usuarios en el menú principal, dentro de ésta se podrá
agregar o modificar usuarios. En la Figura A.11 se muestra el
formulario para agregar un usuario.
7
Figura A.11 Agregar Usuario
140
Una vez abierto dicho formulario, se tienen que llenar los campos del mismo, en el rubro
de privilegio podrás escoger el tipo de usuario, ya sea interno, externo, o administrador.
Después de introducir los datos requeridos para dar de alta a un usuario, se da clic en
guardar.
Historial
En la opción historial que se encuentra en el menú principal, se
despliegan otras opciones como: aplicaciones no permitidas,
acciones URL no permitidas, historial URL (ver Figura A.12).
Paso
8
Figura A.12 Menú desplegado con las opciones
Aplicaciones no Permitidas: Al elegir el usuario, el laboratorio y el equipo, se visualizarán
las aplicaciones no permitidas que el usuario intentó usar (ver Figura A.13).
Figura A.13 Aplicaciones no Permitidas
141
Paso
Configuración
En la opción de configuración se despliegan otras opciones
como: agregar laboratorios, equipos, software, carrera y
servicios manualmente (ver Figura A.14).
9
Figura A.14 Opciones de la opción configuración en el menú
En la Tabla A.2 se muestran los formularios de cada una de las subopciones que se
encuentran en la opción de configuración.
Equipo
Laboratorios
Para agregar un laboratorio se
tienen que llenar lo campos de
nombre de Laboratorio y nombre de
Responsable y dar clic en Guardar
Laboratorio.
Para agregar un equipo se
tienen que llenar lo campos de
nombre de Laboratorio, nombre
de Equipo, número de Serie,
Estatus y dar clic en Guardar
Equipo.
142
Software
Para asignar un software a un equipo se referencia con el permiso de uso
de software, ya que el sistema automáticamente detecta las aplicaciones y
las almacena, entonces al desactivar la casilla de permiso en un software
se deniega el permiso de uso en el equipo elegido.
Carrera
Servicios
Para agregar una carrera se tiene
que llenar el campo de nombre de
Carrera y dar clic en Guardar Para agregar un servicio se tienen
Carrera.
que llenar lo campos de nombre de
Servicio, las observaciones del
servicio y dar clic en Guardar
Servicio.
Tabla A.2 Opciones detalladas de la opción Configuración
143
Paso
Tráfico de Red
En la sección de tráfico de red, podrás visualizar el tráfico de
alertas, donde además, verás el detalle de las alertas
tomando en cuenta la dirección de red IP origen y destino, y la
trama (ver Figura A.15).
10
Figura A.15 Alertas Frecuentes
Al dar Clic en el número de alertas, verás el detalle que se muestra en la Figura A.16:
Figura A.16 Detalle de Alerta
Figura A.16 Alertas del sistema
144
En el cual también se podrá visualizar un reporte de alertas como se muestra en la Figura
A.17:
Figura A.17 Reporte de Alertas
Cerrar Sesión
Paso
Esta opción ubicada en la última opción del menú, activándola
se cerrará la sesión de administrador y pasará
automáticamente a validación, ver Figura A.18.
11
Figura A.18 Cerrar Sesión
145
Apéndice B. Manual de Usuario Interno
Volumen
2
Sistema Inteligente para el Control y Monitoreo de los Equipos y Servicios de Cómputo del Laboratorio de Cómputo del
Centro Universitario de la Costa Sur
Guía de Usuario
Interno y Externo
146
Paso
Entrar al Sistema
1
En
la
barra
de
direcciones
del
navegador
de
Internet,
escribe
http://localhost/ITCG/index.php (Ver Figura B.1) si se está accediendo desde el servidor
donde está instalado el sistema. También se puede acceder por medio de la dirección IP
del Servidor que es http://10.0.0.2, esta dirección puede ser referenciada desde el mismo
servidor (localmente) o desde los demás equipos que conforman la intranet. Y para
acceder vía remota por Internet dependerá del dominio asignado para el sistema.
Figura B.1 Acceso al Sistema de Información
Paso
Validación
Al entrar al sistema aparece un formulario de validación donde
debes introducir tu nombre de Usuario y Contraseña en el
recuadro de Validación, ver Figura B.2.
2
Figura B.2 Validación de Usuario
147
Reservar Equipos
Paso
Si el nombre de usuario y contraseña son correctos, entrarás
al sistema, como se muestra en la Figura B.3.
3
Figura B.3 Vista Predeterminada del Sistema ITCG
Automáticamente el Sistema abre el módulo de Préstamo de Equipos, en el cual en
primera instancia podrás elegir el laboratorio, al cual desees insertar una o varias
reservaciones de equipo.
Ya elegido el laboratorio pasarás a la siguiente vista que se muestra en la Figura A.22.
Donde se visualizarán los equipos registrados, y su estado ya sea ocupado o
desocupado en ese momento.
Figura B.4 Ventana de Préstamo de Equipos
148
Si deseas hacer una reservación independientemente del estado del equipo ocupado o
desocupado para otra hora o día, da en el icono del equipo, y pasarás a un formulario
donde te permitirá ver el tiempo libre del equipo para reservar. Ver Figura B.5.
Figura B.5 Ventana de préstamo de Equipo con el calendario para elegir otra fecha
Elige, la fecha, y la hora para reservar el equipo deseado, dando clic en “verificar”, esta
opción te ayudará para saber si ya ha sido reservado, o está libre. Como este caso el
usuario es de tipo administrador, tienes como privilegio de reservar y cancelar los estados
de los equipos según la situación, ya sea reservar equipos de un laboratorio durante un
semestre para una clase.
Paso
Servicios
En la Figura B.6 se muestra el módulo, para reservar más
servicios, como préstamo de laptop, proyectores, aulas, etc.
4
Figura B.6 Préstamo de Servicios
149
Se da un clic en el icono de servicios que se muestra en la Figura B.6, y se abre el
formulario que se muestra en la Figura B.7 donde podrás seleccionar la fecha del
día de préstamo de servicio siguiendo la misma técnica de reservación de equipo.
Figura B.7 Formulario de Reservación de Servicios
Cerrar Sesión
Paso
Esta opción ubicada en la última opción del menú, activándola
se cerrará la sesión de usuario y pasará automáticamente a
validación ver Figura B.8.
5
Figura B.8 Cerrar Sesión
150
Apéndice C. Manual de Instalación de Visual Basic 6
Volumen
3
Visual Basic 6
Manual de Instalación
Visual Basic 6
151
Paso
1
Para instalar Visual Basic 6 se inserta el CD y se selecciona el ejecutable de la aplicación
(Como se muestra en la figura C.1).
Figura C.1 Localizar el setup de instalación del programa
Paso
2
Paso
Al aparecer la primera venta del instalador presionar el botón next y esperar a que
aparezca la ventana siguiente (Como se muestra en la figura C.2)
2
152
Figura C.2 Ventana del instalador Nex 1
Paso
3
Cuando aparezca la ventana seleccionar la opción I accept the agreement, y presionar el
botón Next (Como se muestra en la figura C.3).
Figura C.3 Aceptar contrato de licencia
153
Paso
4
Cuando aparezca la siguiente ventana insertar el código de activación ingresar nombre y
por último organización y presionar el botón Next (Como se muestra en la figura C.4).
Figura C.4 Insertar código de activación
Paso
5
En la siguiente ventana seleccionar la opción de Visual Basic 6.0 Profetional Edition y
presionar el botón Next (Como se muestra en la figura C.5).
Figura C.5 Elegir modo de instalación
154
Paso
6
Presionar el botón Next asegurándose de que la carpeta que se va a crear para la
aplicación va a quedar guardada en la unidad (C:) (Como se muestra en la figura C.6).
Figura C.6 Ingresar la carpeta de destino de la aplicación
Paso
7
En la siguiente ventana presionar el botón continue (Como se muestra en la figura C.7),
después aparecerá la ventana que se ilustra en la figura C.8, en donde deberá
presionarse el botón ok para que quede registrado el identificador del producto en
cuestión.
155
Figura C.7 Presionar continue
Figura C.8 Botón Ok
Paso
8
Seleccionar y presiona el botón la opción Typical, y esperar a que se ejecute la
instalación (Como se muestra en las figuras C.9 y C.10).
156
Figura C.9 Botón Typical
Figura C.10 Ejecutándose instalación
157
Paso
9
Para terminar con la instalación presionar en el botón Restart Windows (Como se
muestra en la figura C.11).
Figura C.11 Finalizar instalación
158
Paso
10
Por último, después de reiniciar la PC, para asegurarse de que Visual Basic 6 ha sido
correctamente instalado, buscar ahora la aplicación en el botón de inicio todos los
programas y una vez localizada la carpeta de Microsoft Visual Basic 6.0 y ejecutar el
programa (Como se muestra en la figura C.12)
Figura C.12 Verificar instalación
159
Paso
11
Una vez que la aplicación inicie Visual Basic 6 estará completa y correctamente instalado
(Como se muestra en la figura C. 13).
Figura C.13 Ventana de entrada Visual Basic
160
Apéndice D. Manual de Instalación OBDC
Volumen
4
Instalacion OBDC
Manual de
Instalación OBDC
161
Paso
1
Desde Internet descarga el instalador de ODBC que se encontrará en la siguiente
dirección electrónica: http://www.mysql.com/products/connector/odbc/.
Paso
2
Ejecutar el icono de instalación (Como se muestra en la figura D.1).
Figura D.1 Icono de instalación
162
Paso
3
33
En el sistema operativo aparecerá una
advertencia de seguridad, presionar el
botón ejecutar (como se muestra en la
figura D.2)
Paso
Figura D.2 Botón Ejecutar
4
En la Figura D.3 se muestra el inicio de
instalación, presionar el botón Next.
Figura D.3 Ventana de Bienvenida
163
Paso
5
En la Figura D.4 se muestra el tipo de
instalación, se recomienda elegir la
típica (Typical) y presionar el botón
Next.
Figura D.4 Modo de instalación
Paso
6
En la figura D.5 se muestra la información
del tipo de instalación, presionar el botón
Install.
Figura D.5 Botón de instalación
164
Paso
7
En la Figura D.6 se muestra la instalación finalizada, presionar el botón Finish para salir
de la instalación.
Figura D.6 Finalizar instalación
165
Apéndice E. Manual de Instalación APPAServ
Volumen
5
Instalacion APPServ
Manual de Instalación
APPServ
166
Paso
1
Para instalar Appserv primeramente se debe descargar el ejecutable “Appserv-win32” en
cualquiera
de
sus
versiones
de
la
siguiente
dirección
electrónica:
http://www.appservnetwork.com/.
Paso
2
Una vez que ha sido descargado el archivo, dar doble clic en el icono de APPServ
(Figura E.1) y esperar a que aparezca la ventana que se ilustra en la figura E.2 y
presionar el botón Next.
Figura E.1 Ejecutable APPServ
167
Figura E.2 Ventana de Bienvenida
Paso
3
Después aparece la ventana que se ilustra en la figura E.3, en la cual aparece la licencia
del producto bajo la leyenda License Agreement, presionar el botón I Agree.
Figura E.3 Aceptar el contrato de licencia
168
Paso
4
En la siguiente ventana presionar el botón Next (Ver Figura E.4).
Figura E.4 Elegir carpeta de destino
Paso
Presionar el botón Next en la siguiente ventana sin modificar las
casillas de selección (Ver Figura E.5).
5
Figura E.5 Aplicaciones a Instalar
169
Paso
En la siguiente ventana se escribe el nombre del Server (que en este
caso se pone “localhost”) y en la parte de abajo cualquier correo
electrónico que esté vigente y en uso, por último presionar el botón Next
(Ver Figura E.6).
6
Figura E.6 Ingreso de correo y server
Paso
Escribir una contraseña, después presionar el botón Next.
Esperar a que se ejecute la instalación (Ver Figura E7).
7
Figura E.7 Introducir contraseña y nombre de usuario
170
Paso
Al terminar la instalación presionar el botón finish (Ver figura E.8).
8
Figura E.8 Finalizar instalación
Paso
9
Después de haber terminado con la instalación, entrar al Internet Explorer y en la barra
de direccionamiento escribir: http://localhost/ y presionar el botón enter para entrar al
Appserv (Ver figura E.9).
Figura E.9 Barra de direcciones
171
Paso
Por último, cuando se presione el botón enter y aparezca esta página
(Ver Figura E.10), quiere decir que APPServ quedo correctamente
instalado.
10
Figura E.10 Ventana de APPServ
172
Anexo Manual Snort
El manual que se presenta a continuación, fue de gran apoyo para el tesista, ya que con
él se reforzaron los conceptos y el cómo tratar los datos que viajan por la red de datos. El
manual no fue modificado en lo más mínimo de su formato original, se respetaron
derechos de autor, y tal cual se incorporó al anexo presente.
173
Snort:
Análisis de la
herramienta
Visión práctica
Alumnos:
Miguel Ángel Rodríguez García
Miguel Ángel Orenes Fernández
Profesores:
Gabriel López Millán
Gregorio Martínez Pérez
1
Introducción..........................................................................................................................................3
1. ¿Qué es Snort?.................................................................................................................................. 4
2. Instalación y configuración de Snort................................................................................................ 5
2.1. Manejo de las reglas................................................................................................................. 6
3. Instalación y configuración de MySql............................................................................................12
4. Instalación y configuración de ACID............................................................................................. 14
5. Puesta en marcha de la herramienta............................................................................................... 22
6. Interpretación y manejo de los resultados, ejemplo práctico......................................................... 23
7. Ataques Remotos............................................................................................................................ 27
7.1. Escaneo de puertos..................................................................................................................27
7.2. Spoofing.................................................................................................................................. 29
7.3. Negociación de servicios........................................................................................................ 31
7.4. Interceptación..........................................................................................................................33
7.5. Ataques de aplicaciones.......................................................................................................... 34
7.5.1. Correo Electrónico.......................................................................................................... 34
7.5.2. Ataques vía web.............................................................................................................. 35
7.6 Ejemplo de ataque remotos (Nessus)....................................................................................... 36
8. Conclusión...................................................................................................................................... 42
2
Introducción
Para la realización de este trabajo hemos instalado la herramienta Snort sobre el sistema
operativo Windows.
El trabajo está partido en tres partes bien definidas. La primera el el capítulo 1, en el que
hemos querido dar una breve descripción de lo que es Snort, así como mostrar sus principales
utilidades. La segunda, consta de los capítulo del 2 al 6, y en ella se muestra la instalación de Snort,
MySql y ACID para un entorno Windows. El echo de decantarnos por realizar el trabajo sobre
Windows, es debido a que en la web se puede encontrar mucha literatura sobre los pormayores y
pormenores de la instalación de Snort para Linux, así como cursos de gestión de redes UNIX,
mientras que de windows no se encuentra gran cosa. Así pues hemos creído conveniente crear una
tutorial en el que se expliquen con detalle los cambios necesarios en ficheros de configuración, así
como los comandos a introducir en la consola.
Por último la tercera parte, consta del capítulo 7. En este capítulo mostramos los más
famosos ataques remotos que se pueden realizar a una máquina, metodologías que siguen, las
vulnerabilidades que aprovechan, y distintos métodos que podemos utilizar para evitarlos.
Todas las herramientas que se han utilizado son Software Libre, y se pueden descargar de
sus páginas web. Iremos dando las instrucciones de descarga, así como los sitios desde los que se
pueden descargar según vayan haciendo falta.
Creemos que toda la ayuda para comenzar a utilizar Snort queda bien plasmada en el
documento, no obstante, las web http://www.snort.org tiene una gran fuente de ayudas, foros, y
documentación que podrá servir de ayuda para los interesados en los IDS.
3
1. ¿Qué es Snort?
Snort es un sniffer de paquetes y un detector de intrusos basado en red (se monitoriza todo
un dominio de colisión). Es un software muy flexible que ofrece capacidades de almacenamiento de
sus bitácoras tanto en archivos de texto como en bases de datos abiertas como lo es MySQL.
Implementa un motor de detección de ataques y barrido de puertos que permite registrar,
alertar y responder ante cualquier anomalía previamente definida. Así mismo existen herramientas
de terceros para mostrar informes en tiempo real (ACID) o para convertirlo en un Sistema Detector
y Preventor de Intrusos.
Este IDS implementa un lenguaje de creación de reglas flexible, potente y sencillo. Durante
su instalación ya nos provee de cientos de filtros o reglas para backdoor, DDoS, finger, FTP,
ataques web, CGI, Nmap...
Puede funcionar como sniffer (podemos ver en consola y en tiempo real qué ocurre en
nuestra red, todo nuestro tráfico), registro de paquetes (permite guardar en un archivo los logs para
su posterior análisis, un análisis offline) o como un IDS normal (en este caso NIDS). Cuando un
paquete coincide con algún patrón establecido en las reglas de configuración, se logea. Así se sabe
cuando, de donde y cómo se produjo el ataque.
Snort está disponible bajo licencia GPL, gratuito y funciona bajo plataformas Windows y
UNIX/Linux. Dispone de una gran cantidad de filtros o patrones ya predefinidos, así como
actualizaciones constantes ante casos de ataques, barridos o vulnerabilidades que vayan siendo
detectadas a través de los distintos boletines de seguridad.
La característica más apreciada de Snort, además de su funcionalidad, es su subsistema
flexible de firmas de ataques. Snort tiene una base de datos de ataques que se está actualizando
constantemente y a la cual se puede añadir o actualizar a través de la Internet. Los usuarios pueden
crear 'firmas' basadas en las características de los nuevos ataques de red y enviarlas a la lista de
correo de firmas de Snort, para que así todos los usuarios de Snort se puedan beneficiar. Esta ética
de comunidad y compartir ha convertido a Snort en uno de los IDSes basados en red más populares,
actualizados y robustos.
Podemos señalar que Snort es una herramienta que a pleno funcionamiento consume
muchos recursos. Por este motivo, y debido al echo de que estamos monitorizando una sola
máquina, hemos decidido para este trabajo utilizar la base de datos de reglas que no necesita
registro por internet, si no que se crea en el mismo momento de la creación de la versión que
utilizaremos de Snort, con el fin de no cargar las máquinas de los compañeros que quieran instalar
Snort para probarlo en sus PCs. No obstante, se darán las directrices a seguir por si se desea instalar
el NIDS en un equipo para que monitorice con las mayores prestaciones su red, descargando las
reglas registrándose en http://www.snort.org.
2. Instalación y configuración de Snort
4
Para comenzar , necesitamos la herramienta WinCap3.1 descargable desde
http://www.winpcap.org/install/default.htm. Esta herramienta es básica para el funcionamiento de
Snort, debido a que es la librería de bajo nivel que utilizará Snort para el acceso a redes. Es para
Windows como la libCap utilizada en Linux.
Una vez instalado WinCap, debemos acceder a la web de Snort, http://www.snort.com y
descargarnos la versión de Snort para Windows desde http://www.snort.org/dl/binaries/win32/ y
pasamos a instalarlo. Lo único que hay que subrayar en el proceso de instalación, es que en un
momento dado nos preguntará el wizard que seleccionemos las opciones de configuración,
seleccionamos “I do not plan to log to a database, or I am planning to log to one of the
databases listed above” y presionamos next para continuar. A continuación nos pedirá que
seleccionemos los componentes de la instalación, los seleccionamos todos y hacemos click en
next. Cuando nos pida la ruta de instalación, dejamos la que sle por defecto C:\Snort y
presionamos next para finalizar la instalación.
Una vez que está instalado Snort, tenemos que proseguir con su configuración. Lo primero
que tenemos que hacer es acceder a la carpeta C:\Snort\etc en este directorio encontraremos un
fichero llamado snort.conf que es el fichero de configuración que utilizaremos para configurar
Snort. Accedemos al fichero con un editor de texto que no corrompa el formato original del archivo
(notepad o wordpad).
Entonces comenzamos la configuración:
1. Comenzamos con la configuración de la
red
Como podemos ver, en snort.conf, la red que aparece por
defecto var HOME_NET any
Lo que tenemos que hacer es modificar esta variable. La podemos modificar de tres
modos dependiendo de lo que queramos:
1. Una red C:
var HOME_NET 192.168.1.0/24
2. Host específico : var HOME_NET 192.168.1.3/32
3. Varios Host:
var HOME_NET
192.168.1.2/32,192.168.1.3/32,192.168.1.4/32
En nuestro caso lo que nos interesa es monitorizar un solo host, con lo que utlizamos el
segundo modo, en nuestro caso será:
var HOME_NET IpdelHost/32
La Ip del Host se puede obtener ejecutando en comando ipconfig en la consola.
2. Seguimos con la configuración de las reglas
Para este punto lo único que tenemos que hacer es descargarnos las reglas de la web de
Snort e incluirlas en el directorio c:\Snort\rules.
Como se observará en la web de Snort, hay tres conjuntos de reglas para
descargar, Subscribers , Registered y Unregistered. Para este tutorial
recomendamos descargar las Unregistered ya que cargarán menos el PC. Una
vez que lo finalicemos, si se desea dejar instalado Snort y utilizarlo como
servicio, es aconsejable registrarse para que podamos recibir las actualizaciones
que se van realizando de las reglas.
5
En snort.conf, casi al final aparecen una serie de sentencias con el siguiente formato:
nclude $RULE_PATH/name.rules
Se trata de las sentencias que inclyen las diferentes librerías de reglas. Las que tienen una
'#' delante son las que están comentadas, si queremos que se incluyan , solamente tenemos
que quitarle la almohadilla de delante.
Por ahora le quitamos la almohadilla a todas.
3. Finalizamos con unos retoques de acceso
Solamente nos queda por modificar lo
siguiente: Cambiar la línea donde aparece :
dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/
por:
dynamicpreprocessor directory c:\snort\lib\snort_dynamicpreprocessor
Y la línea que pone:
dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so
Por:
dynamicengine c:\snort\lib\snort_dynamicengine\sf_engine.dll
6
Una vez realizados estos cambios podemos probar Snort desde la línea de comandos.
Accedemos a la carpete c:\Snort\bin y este direcytorio escribimos :
C:\Snort\bin> snort -dev -c c:\Snort\etc\snort.conf -l C:\Snort\log -i2
Nos dará un error diciendo que no se encuentra el archivo spyware-put.rules. Comentamos
esa línea en el fichero de configuración y volvemos a ejecutar. Comenzaremos a ver el tráfico que
pasa por nuestro equipo. Si observamos el directorio C:\Snort\log, podemos ver como en el fichero
alert.ids se han ido almacenando las alertas que los ficheros de reglas tienen reconocidas como
tráfico del que deben de alertar.
Las opciones que le hemos pasado en la línea de comandos a Snort son:
-d : visualizar los campos de datos que pasan por la interface de red.
-e: snort nos mostrará información más detallada.
-v: Iniciamos snort en modo sniffer visualizando en pantalla las cabeceras de los paquetes
TCP/IP.
-c: archivo que utilizará snort como fichero de configuración.
-l: directorio donde guardar las alertas y logs.
-i: interfaz que monitorizaremos.
2.1. Manejo de las reglas
Las opciones que aquí se comentan para la creación de reglas, son solamente para
el comienzo de la utilización de Snort, puede encontrar toda la documentación
necesaria sobre reglas en la web http://www.snort.org/docs/writing_rules
La herramienta Snort utiliza un lenguaje simple para la definición de las reglas. La mayoría
de las reglas están escritas en una sola línea. Ahora pasamos a describir los pasos que tenemos que
dar para crear un fichero con reglas nuevas que queramos utilizar.
El primer paso será crear el fichero “.rules” ( lo llamaremos misReglas.rules), en el que
introduciremos nuestras reglas, en el directorio rules alojado en el directorio raíz de la
herramienta(c:\Snort\rules). Una vez creado nos vamos al fichero de configuración, en este tutorial
estamos utilizando snort.conf del directorio etc y después de la inclusión de los ficheros de reglas
que nos proporciona snort, introducimos una sentencia del tipo:
include <fichero de reglas>
Que en nuestro caso será:
include $RULE_PATH/misReglas.rules
Con esta sentencia, le estamos diciendo a snort que, cuando arranque, introduzca las reglas
del fichero misReglas.rules en su base de datos de reglas.
Lo que tenemos que hacer a continuación es acceder al fichero en el que se clasifican y se
priorizan las reglas, en el cual, introduciremos el nuevo tipo del conjunto de reglas que vamos a
crear, y le asignaremos prioridad. Este fichero se llama classification.config y se encuentra en la
carpeta etc, la misma que el fichero de configuración de Snort.
7
Como se puede observar, las diferentes clasificaciones de reglas siguen el siguiente patrón:
config <directiva>: name, descripción, prioridad
En nuestro caso crearemos una clasificación (directiva classification) de reglas que
llamaremos user-rules, cuya descripción será tráfico que nos interesa, y cuya prioridad será 5. Para
crearla, introducimos la siguiente línea en el fichero:
config classification: user-rules, Trafico que nos interesa, 5
También se podrán utilizar las clasificaciones ya creadas, solamente creamos en el ejemplo
una nueva clasificación para que se vea como se crearía.
Una vez que hemos realizado esto, solamente nos queda comenzar a crear las reglas que nos
interesan. Es importante comentar que para la creación de reglas medio decentes se necesita unos
pequeños conocimientos sobre protocolos, como pueden ser ICMP, TCP, ... debido a que a las
reglas se le pasan parámetros en si parte de opciones.
Vamos a crear una regla muy simple, que nos va a alertar de los ping que se realizan desde
una máquina de nuestra red hacia el exterior.
Comenzamos abriendo el fichero misReglas.rules que hemos creado anteriormente, y
comenzamos a introducir las reglas. Las reglas en Snort se componen de dos grande partes, la
cabecera y las opciones, teniendo las siguiente forma:
<cabecera> (<opciones>)
Cabeceras:
Las cabeceras siguen en siguiente formato:
<acción> <protocolo> <redFuente con máscara> <puerto> --> <redDestino con máscara>
<puerto>
–
La acción que vamos a crear es una acción del tipo alert.
–
El protocolo será icmp.
–
La red fuente será la variable $HOME_NET que modificamos en el fichero de
configuración anteriormente, que tiene incluida la máscara de red.
–
El puerto será any, refiriéndonos a todos los puertos.
–
Como red destino ponemos $EXTERNAL_NET.
–
Y como puerto any
No obstante, se podría poner una red concreta, y un puerto concreto o rango de
puertos. Para indicar un rango de puertos, utilizaremos el operador ':', Ej: 0:1023, puertos
del 0 al 1023; :300 , puerto menor o igual a 300; 500:, puerto mayor o igual que 500.
Una vez hecho esto, tenemos que pasar a rellenar las opciones.
Opciones:
Existe un gran número de opciones, solamente comentaremos las más importantes
para nuestro cometido:
–
msg: Escribe un mensaje de alerta.
–
itype: tipo icmp.
–
icode: código icmp.
8
–
flags: flags tcp (A, S, F, U, R y P)
–
sid: ID de la regla.
–
classtype: tipo de la regla, ( el tipo creado en el fichero classification.config)
–
content: buscan un patrón en el contenido de los datos del paquete.
–
rev: numero de revisión de la regla.
Una vez comentado esto, sabemos que opciones utilizaremos, serán msg, itype, icode, sid,
rev y classtype.
El código de un PING en el protocolo icmp es 0, y el tipo es 8, con lo cual el campo
icode tendrá el valor 0 y el itype el 8.
Para finalizar introducimos la regla en el fichero misReglas.rules. La regla será la
siguiente:
alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"PING que se lanza desde mi
máquina"; icode:0; itype:8; sid:10000;classtype:user-rules; rev:0;)
Ahora solamente tenemos que ejecutar Snort:
C:\Snort\bin> snort -dev -c c:\Snort\etc\snort.conf -l C:\Snort\log -i2
Realizamos un ping desde la línea de comandos a cualquier máquina, por ejemplo:
ping 155.54.1.1
Y en el fichero alert.ids podemos ver que se ha incluido el siguiente contenido:
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/05-18:46:31.958312 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.42 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6465 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:768 ECHO
[**] [1:408:5] ICMP Echo Reply [**]
[Classification: Misc activity] [Priority: 3]
01/05-18:46:31.961734 0:6:52:51:B0:1B -> 0:5:9A:3C:78:0 type:0x800 len:0x4A
155.54.1.1 -> 155.54.197.42 ICMP TTL:253 TOS:0x0 ID:53966 IpLen:20 DgmLen:60 DF Type:0
Code:0 ID:1024 Seq:768 ECHO REPLY
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/05-18:46:32.958729 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.42 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6549 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:1024 ECHO
[**] [1:408:5] ICMP Echo Reply [**]
[Classification: Misc activity] [Priority: 3]
9
01/05-18:46:32.961565 0:6:52:51:B0:1B -> 0:5:9A:3C:78:0 type:0x800 len:0x4A
155.54.1.1 -> 155.54.197.42 ICMP TTL:253 TOS:0x0 ID:53967 IpLen:20 DgmLen:60 DF Type:0
Code:0 ID:1024 Seq:1024 ECHO REPLY
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/05-18:46:33.959755 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.42 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6614 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:1280 ECHO
[**] [1:408:5] ICMP Echo Reply [**]
[Classification: Misc activity] [Priority: 3]
01/05-18:46:33.962559 0:6:52:51:B0:1B -> 0:5:9A:3C:78:0 type:0x800 len:0x4A
155.54.1.1 -> 155.54.197.42 ICMP TTL:253 TOS:0x0 ID:53968 IpLen:20 DgmLen:60 DF Type:0
Code:0 ID:1024 Seq:1280 ECHO REPLY
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/05-18:46:34.960773 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.42 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6679 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:1536 ECHO
[**] [1:408:5] ICMP Echo Reply [**]
[Classification: Misc activity] [Priority: 3]
01/05-18:46:34.965188 0:6:52:51:B0:1B -> 0:5:9A:3C:78:0 type:0x800 len:0x4A
155.54.1.1 -> 155.54.197.42 ICMP TTL:253 TOS:0x0 ID:53969 IpLen:20 DgmLen:60 DF
Type:0 Code:0 ID:1024 Seq:1536 ECHO REPLY
Como se puede observar, se han incluido las alertas de los ECHOs que nosotros hemos
lanzado, con el código que le hemos asignado, el número de revisión, el texto que hemos puesto
para que se imprimiera, el grupo de clasificación al que pertenece y su prioridad, seguido del
contenido de la cabecera del paquete. Además, se crea la alerta también de la respuesta al ECHO.
Supongamos que deseamos que no se crease la alerta de los ECHO REPLY, lo único que
tendríamos que hacer sería comentar la entrada en el fichero icmp-info.rules que se hace cargo de
crear la alerta de los ECHO REPLY:
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Echo Reply";
icode:0; itype:0; classtype:misc-activity; sid:408; rev:5;)
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/08-09:12:34.318655 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
10
155.54.197.245 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6786 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:3072 ECHO
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/08-09:12:35.319667 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.245 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6795 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:3328 ECHO
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/08-09:12:36.320685 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.245 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6804 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:3584 ECHO
[**] [1:10000:0] PING que se lanza desde mi máquina [**]
[Classification: Trafico que nos interesa] [Priority: 5]
01/08-09:12:37.320725 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x4A
155.54.197.245 -> 155.54.1.1 ICMP TTL:128 TOS:0x0 ID:6813 IpLen:20 DgmLen:60
Type:8 Code:0 ID:1024 Seq:3840 ECHO
Como se puede observar, a comentar la línea que porvoca las alarmas de los ECHO REPLY,
snort no almacena las alertas que se han producido de este tráfico.
Por otro lado, también se pueden crear reglas que tras su invocación hagan que otras reglas
sean activadas durante un periodo de tiempo. Esto se consigue mediante las siguientes claúsulas:
–
activate: Alerta y activa una regla declarada como dinámica (dynamic).
–
dynamic: cobra sentido cuando una regla declarada como activa (activate), la activa de
modo que pasa a formar parte de las reglas del registro.
El par activate/dynamic rules, le proporciona a Snort una capacidad con mucha potencia,
debido a que le capacita para que una regla esté activa a partir de un determinado momento, y que
vuelva a ser pasiva cuando haya recibido un número de paquetes que se le indica. Las reglas
activate se declaran exactamente igual que las alert, con la salvedad de que necesitan de una
opción adicional, la opción activates. Las reglas dynamic son en formato igual que las reglas de
registro, con la salvedad de que necesitan de dos opciones más, activated_by y count.
Por ejemplo, las siguientes sentencias:
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; \
content: "|E8C0FFFFFF|/bin"; activates: 1; \
msg: "IMAP buffer overflow!\";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;)
11
Estas reglas hará que cuando se detecte un overflow del búfer IMAP, se coleccionen los 50
siguientes paquetes que vienen desde una red exterior a la red que estamos vigilando por el puerto
143.
Existe la posibilidad de que una regla implemente respuestas ante la activación de una alerta,
la ejecución de estas respuestas hace que las conexiones que se interpreten ofensivas sean cerradas.
Las respuestas que nos podemos encontrar son las siguientes:
–
rst_snd : envía un paquete TCP-RST por el socket emisor.
–
rst_rcv : envía un paquete TCP-RST por el socket receptor.
–
rst_all : envía un paquete TCP-RST en ambas direcciones.
–
icmp_net : envía un ICMP_NET_UNREACH al emisor.
–
icmp_host: envía un ICMP_HOST_UNREACH al emisor.
–
icmp_port: envía ICMP_PORT_UNREACH al receptor .
–
icmp_all: send all above ICMP packets to the sender
Todas estas opciones pueden ser combinadas siguiendo el siguiente formato:
resp:<modificación_respuesta[, modificación_respuesta];>
alert udp any any -> 192.168.1.0/24 31 (resp: icmp_port,icmp_host; \
msg: "Hacker's Paradise access attempt";)
12
3. Instalación y configuración de MySql
Lo primero que tenemos que hacer es descargar el driver ODBC debido a los problemas de
compatibidad que se pueden encontrar,el nombre del archivo es mysql-connector-odbc-3.51.12win32,y se puede descargar desde http://dev.mysql.com/downloads/connector/odbc/3.51.html, Se
instala y proseguimos con la instalación de Mysql.
Descargamos la base de datos MySql de la página oficial de MySql, http://www.mysql.org,
se instala y pasamos a configurar tanto Snort como MySql para que se puedan utilizar y para que
ambos interactúen para poder trabajar juntos.
Una vez instalado MySql, tenemos que crear la base de datos sobre la que trabajará. Para
ello accedemos como root a la base de datos. Esto se hace desde la carpeta bin del directorio raíz de
MySql mediante el comando:
mysql -u root -p
Una vez hecho esto, nos pedirá la clave del root.
Acto seguido, una vez dentro de mysql, tenemos que crear la base de datos:
create database snort;
Ahora tenemos que crear las tablas con las que trabajará snort, para eso, se necesita un
fichero llamado create_mysql, para la realización de este tutorial, fue descargado de un comentario
del foro del sitio oficial de Snort, el comentario en cuestión está en http://www.snort.org/archive11-3647.html. Creamos el archivo create_mysql en la carpeta schemas contenida en el directrio raíz
de Snort.
Nosotros modificamos una línea del fichero de creación de la base de datos, debido
a que si no, sería imposible almacenar las alarmas que crea un escaneo de puertos,
ya que no pertenece a ninguna clase de reglas. La línea, es una de las pertenecientes
a la creación de la tabla signature(linea 38), modificada es la siguiente:
sig_class_id INT UNSIGNED NOT NULL,
por
sig_class_id INT UNSIGNED,
Una vez hecho esto, desde la línea de comandos ejecutamos:
mysql -u root -p -D snort < c:\Snort\schemas\create_mysql
Nos pedirá la clave del root, y ya están creadas las tabas necesarias. Ahora tenemos que
darle permisos al usuario con el que se modificará la base de datos snort de la siguiente manera
(dentro de mysql, habiendo accedido con el root):
grant insert,select,update,create,delete on snort.* to User@localhost identified by 'clave';
Salimos de mysql, y ahora accedemos con el usuario creado directamente a la base de datos
snort:
mysql -u User -D snort -p
13
Nos pedirá la clave, y accederemos. Una vez dentro, comprobamos que se han creado todas
las tablas mediante el comando
show tables;
Ahora tenemos que modificar el fichero snort.conf para que snort interactúe con mysql. Lo
único que tenemos que modificar es descomentar la línea
# output database: log, mysql, user=root password=test dbname=db host=localhost
Cambiándola por la siguiente:
output database: log, mysql, user=User password=PASSWD dbname=snort host=localhost
port=3306 sensor_name=snort_sensor
Una vez realizados estos cambios, lanzamos snort desde el directorio bin del fichero raíz de
snort, mediante el comando:
snort -dev -c c:\Snort\etc\snort.conf -l C:\Snort\log -i2
Realizamos alguna acción para que se creen alertas, y accedemos a la base de datos
snort y ejecutamos :
select * from event;
Y veremos todos los eventos que se han producido.
Una vez hecho esto, vemos como el acceso a los datos que nos genera Snort sigue siendo un
poco emborroso , ya que tenemos que estar accediendo desde la línea de comandos que en muchas
ocasiones se convierte en algo pesa de trabajar. Para paliar esto, contamos con una herramienta
llamada ACID que consta de unos ficheros php, y que solamente necesita para ejecutarse un
servidor que soporte php, tener php instalado, y una serie de herramientas que se comentaran.
14
4. Instalación y configuración de ACID
ACID es un sistema basado en web, creado con el lenguaje de programación PHP, con lo
que necesita de un servidor capaz de interpretar PP.
Como estamos instalando Snort en Windows, vamos a utilizar el servidor IIS que nos viene
en la distribución de Windows que tenemos instalada ( el tutorial se está realizando sobre Windows
Xp). No hay ningún problema en utilizar u Apache, o cualquier servidor que sepa interpretar código
PHP, solamente utilizamos este porque creemos que es interesante saber instalarlo, ya que durante
la carrera solamente hemos trabajado con servidores Apache y Apache Tomcat y no con IIS.
Para instalar IIS tenemos que acceder al Panel de control --> Agregar o quitar Programas -->
Agregar o Quitar Componentes de Windows. Nos aparecerá una ventana como esta:
Solamente tenemos que seleccionar Internet Information Services(IIS), y hacer click en siguiente.
Una vez instalado, probamos que está funcionando escribiendo en el Iexplorer( OJO!!!!!!!!!
solamente se puede acceder desde el Iexplorer, no lo intenteis desde otro navegador, Firefox, Opera
por que no os dejará acceder) la dirección localhost , y nos tiene que salir la siguiente ventana:
15
Una vez instalado el IIS, ya tenemos un servidor que nos interprete PHP.
Ahora debemos de instalar PHP. Para ello nos bajamos de www.php.net tanto el instalador
de PHP como el archivo .zip. Los dos archivos que tenemos que descargarnos deben ser de la
misma versión de PHP, ya que si no tendremos problemas y no podremos ejecutar ACID.
–
El zip lo podemos descargar de http://es.php.net/get/php-4.4.4-Win32.zip/from/a/mirror
–
y el ejecutable de http://es2.php.net/get/php-4.4.4-installer.exe/from/a/mirror
16
Instalamos PHP desde el instalador. En algún momento nos preguntará el instalador que a
que servidor queremos darle servicio, elegimos el IIS de la versión que hayamos instalado, en
nuestro caso fue Microsoft IIS 4 or higher. Una vez acabado esto, accedemos al directorio raíz de
PHP, supuestamente estará en c:\PHP. Mientras tanto abrimos el fichero php-4.4.4-Win32.zip y
extraemos el el directorio extensions en el directorio raíz de PHP de modo que quedará así:
Ahora pasamos a configurar el fichero php.ini que se encuentra en el directorio
C:\WINDOWS. Una vez en el lo editamos y modificamos una serie de variables, dejándolas como
quedan:
max_execution_time = 60
; Maximum execution time of each script, in seconds
error_reporting = E_ALL & ~E_NOTICE
extension_dir = c:\php\extensions
extension=php_gd2.dll
session.save_path= C:\WINDOWS\Temp; argument passed to save_handler
Echo esto solamente nos queda configurar ACID. Y para esto, antes de nada nos tenemos
que bajar dos ficheros:
17
–
adodb452 --> http://prdownloads.sourceforge.net/adodb/adodb452.zip?download
–
PHPlot --> http://sourceforge.net/project/showfiles.php?group_id=14653
Con estos archivos lo único que tenemos que hacer es descomprimirlos en el directorio raíz de
Snort.
Ahora si que llega el momento de instalar ACID. Lo único que tenemos que hacer es
descargar acid-0.9.6b23.tar de http://acidlab.sourceforge.net/, lo descomprimimos en el directorio
raíz del servidor web, que en nuestro caso, por haber instalado IIS, es C:\Inetpub\wwwroot, y
comenzamos a modificar unas líneas del fichero acid_conf.php:
$DBlib_path = "C:\Snort\adodb";
/* Alert DB connection parameters
* - $alert_dbname : MySQL database name of Snort alert DB
* - $alert_host : host on which the DB is stored
* - $alert_port : port on which to access the DB
* - $alert_user : login to the database with this user, usuario que tiene permisos para
conectarse a la base de datos de snort
* - $alert_password : password of the DB user, clave del usuario
*
* This information can be gleaned from the Snort database
* output plugin configuration.
*/
$alert_dbname = "snort";
$alert_host = "localhost";
$alert_port = "3306";
$alert_user = "USER";
$alert_password = "PASSWD";
ACID crea tablas adicionales para que el usuario pueda archivar alertas importantes. Se puede
indicar
otro usuario para acceder a ellas.
/* Archive DB connection parameters */
$archive_dbname = "snort_archive";
$archive_host = "localhost";
$archive_port = "";
$archive_user = "user_archive";
$archive_password = "123456";
Con esto ya tenemos instalado ACID, ahora para probarlo ponemos en el Iexplorer
http://localhost/acid/index.html, y nos aparecerá lo siguiente:
Warning: mysql_pconnect() [function.mysql-pconnect]: Client does not support authentication
protocol requested by server; consider upgrading MySQL client in
C:\Snort\adodb\drivers\adodb-mysql.inc.php on line 354
18
Error (p)connecting to DB : snort@localhost:3306
Check the DB connection variables in acid_conf.php
= $alert_dbname
: MySQL database name where the alerts are
=
=
=
=
:
:
:
:
stored
$alert_host
$alert_port
$alert_user
$alert_password
host where the database is stored
port where the database is stored
username into the database
password for the username
Database ERROR:Client does not support authentication protocol requested by server; consider
upgrading MySQL client
Este error se solventa accediendo a mysql como root y ejecutando los siguientes comandos:
mysql> UPDATE mysql.user SET Password = OLD_PASSWORD('newpwd')
-> WHERE Host = 'some_host' AND User = 'some_user';
mysql> FLUSH PRIVILEGES;
Ahora si hacemos un refresco en el browser, aparecerá:
19
Hacemos click en Setup page:
20
Click en Create ACID AG:
21
Hacemos click en Main Page y vemos como van las alertas registradas por Snort:
Ahora solamente nos queda explorar todas las ventajas que nos da ACID.
5. Puesta en marcha de la herramienta
Ahora lo único que tenemos que hacer es que snort sea un servicio del sistema de tal modo
que no tengamos necesidad de tener que estar lanzando snort cada vez que accedamos al ordenador.
Para esto, lo único que tenemos que hace es:
1- Instalarlo como servicio:
snort /SERVICE /INSTALL -dev -c c:\Snort\etc\snort.conf -l c:\Snort\log -i2
2- Lanzar el servicio:
net start snort
Con esto ya tenemos snort funcionando, interactuando con una base de datos mysql, y
además tenemos la ayuda de una herramienta que nos permite visualizar los datos de una manera
muy sencilla desde un navegador web.
6. Interpretación y manejo de los resultados, ejemplo práctico
22
Cuando comenzamos a trabajar con Snort podemos darnos cuenta de que muchas de las
alertas que se producen son falsas alertas. Por ejemplo, mientras la realización del tutorial he estado
hablando con un amigo por el Msn y resulta que cuando he terminado de instalar ACID, me salían
las siguientes alarmas:
Que sucede con esto, que Snort por defecto está creando muchas falsas alarmas. Al darnos
cuenta de esto, lo único que tenemos que hacer es comentar la regla que hace que salte dicha
alarma. Para ello primero paramos snort:
net stop snort
Comentamos las reglas que creemos que son innecesarias, en nuestro caso comentaremos
del fichero chat.rules:
#alert tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT MSN message";
flow:established; content:"MSG "; depth:4; content:"Content-Type|3A|"; nocase;
content:"text/plain"; distance:1; classtype:policy-violation; sid:540; rev:11;)
Ahora tendremos que volver a instalar el servicio para que las reglas modificadas queden en
el registro de reglas como que han sido modificadas:
snort /SERVICE /UNINSTALL
23
snort /SERVICE /INSTALL -dev -c c:\Snort\etc\snort.conf -l c:\Snort\log -i2
net start snort
Vuelvo a iniciar sesión y mantengo otra conversación vía aMsn con un amigo, y la única
alarma registrada a sido la que indica que hemos iniciado sesión : CHAT MSN login attempt, las
demás son anteriores a esta nueva conexión:
Supongamos que como administradores queremos aprovechar la potencia de Snort, para
poder apreciar si se produce algún ataque por el puerto del messenger, y que máquina(s) tenían
abierta una sesión en ese momento. Para ello, tenemos que registrar el momento en el que un equipo
realiza el logueo ( que ya nos lo da hecho Snort con la alerta CHAT MSN login attempt), y tenemos
que registrar momento en el que se realiza el logout. Para registrar el logout tenemos que crear una
regla que sea capaz de registrar el momento en el que se realiza.
Para ello tenemos que saber el contenido de un mensaje logout. Mirando en el alert.ids,
encontramos las siguientes tramas:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
01/10-12:08:01.703664 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x36
155.54.197.77:3172 -> 207.46.108.82:1863 TCP TTL:128 TOS:0x0 ID:10667 IpLen:20 DgmLen:40
DF
***A**** Seq: 0xC544D936 Ack: 0x63FF6B1A Win: 0x44E8 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
01/10-12:08:04.468543 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x3B
155.54.197.77:3172 -> 207.46.108.82:1863 TCP TTL:128 TOS:0x0 ID:10695 IpLen:20 DgmLen:45
DF
24
***AP*** Seq: 0xC544D936 Ack: 0x63FF6B1A Win: 0x44E8 TcpLen: 20
4F 55 54 0D 0A
OUT..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
01/10-12:08:04.469457 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x36
155.54.197.77:3172 -> 207.46.108.82:1863 TCP TTL:128 TOS:0x0 ID:10696 IpLen:20 DgmLen:40
DF
***A***F Seq: 0xC544D93B Ack: 0x63FF6B1A Win: 0x44E8 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
01/10-12:08:04.705276 0:6:52:51:B0:1B -> 0:5:9A:3C:78:0 type:0x800 len:0x36
207.46.108.82:1863 -> 155.54.197.77:3172 TCP TTL:110 TOS:0x0 ID:31933 IpLen:20 DgmLen:40
DF
***A***F Seq: 0x63FF6B1A Ack: 0xC544D93B Win: 0xFCEE TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
01/10-12:08:04.705321 0:5:9A:3C:78:0 -> 0:6:52:51:B0:1B type:0x800 len:0x36
155.54.197.77:3172 -> 207.46.108.82:1863 TCP TTL:128 TOS:0x0 ID:10697 IpLen:20 DgmLen:40
DF
***A**** Seq: 0xC544D93C Ack: 0x63FF6B1B Win: 0x44E8 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
01/10-12:08:04.705422 0:6:52:51:B0:1B -> 0:5:9A:3C:78:0 type:0x800 len:0x36
207.46.108.82:1863 -> 155.54.197.77:3172 TCP TTL:110 TOS:0x0 ID:32010 IpLen:20 DgmLen:40
DF
***A**** Seq: 0x63FF6B1B Ack: 0xC544D93C Win: 0xFCEE TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+
Como ya se comento, se necesitan nos conceptos avanzados de protocolos de redes para
entender como crear reglas que más o menos sean buenas, o que por lo menos registren lo que
deseamos.
Como se puede observar es una desconexión TCP a tres bandas ( thee hand shake) entre las
direcciones 155.54.197.77 ( la nuestra) y 207.46.108.82 ( la del servidor de messenger).
Con lo cual, tenemos que hacer una regla que se active ante la salida de una trama TCP con
contenido OUT con los bits A y P activos, y que vaya al puerto 1863, con lo que la regla sería:
alert tcp $HOME_NET any -> $EXTERNAL_NET 1863 (msg:"CHAT MSN logout";
25
flags:AP; content:"OUT"; depth:3;classtype:policy-violation; sid:10009; rev:2;)
Obsérvese que le asignamos la clase policy-violation que no hemos creado nosotros, como
en el apartado 2.1. Manejo de las reglas, la clase con la que se clasificará esta alarma. Esto lo
hemos hecho para que la alerta de esta regla sea almacenada con la misma clase con la que se
almacenan las demás reglas referentes a las de CHAT. Mirar chat.rules.
Esta regla que hemos introducido no nos identifica solamente los paquetes que vienen para
cerrar una sesión de messenger, si no que también nos alertará del tráfico generado cuando
cerramos una ventana. Esto nos servirá para saber cuantas conversaciones ha tenido un usuario, ya
que por defecto hay una regla que registra en el momento en el que realizar una conexión con un
contacto mediante la alarma CHAT MSN user search. Con lo tendremos:
1. Cuando inicia la sesión un usuario.
2. Número de conversaciones y tiempo de cada una
3. Final de la sesión.
Por ejemplo:
Se comenzó la sesión el 10-1-2007 a las 16:50:08 y se cerró el 10-1-2007 a las 16:51:10.
Los User Search ocurren cuado hacemos doble click sobre cualquier contacto. Los logout
solamente se crearan si se ha producido una conversación con el contacto con el que intentamos
26
hablar, es decir, pueden haber ocasiones en los que no aparezca el logout debido a que el tráfico no
se produce ya que no se había llegado a producir la conexión completa, el echo de que si que se
registren los user search en debida a que la regla se activa cuando buscamos al contacto, no cuando
se ha producido la conexión en sí.
7. Ataques Remotos
Un ataque remoto es cualquier ataque que se lanza desde un ordenador a otro cualquiera,
independientemente del lugar en el que se encuentren ambos. Puede ser que se encuentren en una
misma oficina, o que la distancia entre ambos sea muy grande.
En este apartado vamos a describir los siguientes ataques:
• Escaneos de puertos
• Spoofing
•
Negaciones de servicio
•
Interceptación
•
Ataques a aplicaciones
•
Correo electrónico
•
Ataques vía web
Para cada uno de los ataques vamos a describir sus características, modo en el que atacan a
los equipos, finalidades, vulnerabilidades que aprovechan, y posibles soluciones a los diferentes
ataques.
7.1. Escaneo de puertos
Una de las primeras actividades que un potencial (o no tan potencial) atacante realizará
contra su objetivo será sin duda un escaneo de puertos, un portscan; esto le permitirá obtener en
primer lugar información básica acerca de qué servicios estamos ofreciendo en nuestras máquinas y,
adicionalmente, otros detalles de nuestro entorno como qué sistema operativo tenemos instalados en
cada host o ciertas características de la arquitectura de nuestra red. Analizando qué puertos están
abiertos en un sistema, el atacante puede buscar agujeros en cada uno de los servicios ofrecidos:
cada puerto abierto en una máquina es una potencial puerta de entrada a la misma.
Comprobar el estado de un determinado puerto es a priori una tarea muy sencilla; incluso es
posible llevarla a cabo desde la línea de órdenes, usando una herramienta tan genérica como telnet.
Por lo general, nadie en su sano juicio usaría telnet para realizar un escaneo de puertos
masivo contra un sistema o contra toda una red; existen herramientas como strobe o nmap (la más
conocida) que pueden realizar esta tarea de una forma más o menos cómoda y automatizable.
Evidentemente, ninguno de estos programas se dedica a lanzar telnets contra los puertos de un
sistema: los escaneadores de puertos actuales implementan diferentes técnicas que permiten desde
detectar desde la versión del sistema operativo usado en la máquina atacada hasta pasar inadvertidos
ante diferentes sistemas de detección de intrusos.
Existen diferentes aproximaciones para clasificar los escaneos de puertos, tanto en función
de las técnicas seguidas en el ataque como en función de a qué sistemas o puertos concretos va
27
dirigido. Por ejemplo, se habla de un escaneo horizontal cuando el atacante busca la disponibilidad
de determinado servicio en diferentes máquinas de una red; por ejemplo, si el pirata dispone de un
exploit que aprovecha un fallo en la implementación de sendmail, es normal que trate de averiguar
qué máquinas aceptan peticiones SMTP en un determinado segmento para posteriormente atacar a
dichos sistemas. Si por contra el pirata sólo escanea puertos de una máquina, se denomina al ataque
28
escaneo vertical, y suele denotar el interés del atacante en ese host concreto; si comprueba todos
los puertos del sistema al escaneo se le denomina vanilla, mientras que si sólo lo hace contra
determinados puertos o rangos, se le denomina strobe (en referencia al programa del mismo
nombre). Si nos basamos en las técnicas utilizadas, podemos dividir los escaneos en tres grandes
familias: open, half-open y stealth; vamos a hablar con más detalle de cada una de ellas y de los
diferentes tipos escaneos que las forman.
Los escaneos open se basan en el establecimiento de una conexión TCP completa mediante
el conocido como protocolo de acuerdo de tres vías o three-way handshake, por lo que son muy
sencillos de detectar y detener. Utilizan la llamada connect(), el escaneador intenta establecer una
conexión con un puerto concreto del host atacado, y en función de la respuesta obtenida conoce su
estado: una técnica rápida, sencilla, fiable y que no necesita de ningún privilegio especial en la
máquina atacante.
La segunda técnica que hemos comentado es la de los escaneos half-open; en este caso, el
pirata finaliza la conexión antes de que se complete el protocolo de acuerdo de tres vías, lo que de
entrada dificulta - aunque no mucho - la detección del ataque por parte de algunos detectores de
intrusos muy simples (casi todos los actuales son capaces de detectarlos). Dentro de esta técnica se
encuentra el SYN Scanning: cuando el origen - atacante - recibe del destino - máquina escaneada los bits SYN+ACK, envía un bit RST (no es necesaria una nueva trama, ya que este bit se envía
automáticamente a nivel de núcleo) en lugar del ACK correspondiente a un three-way handshake
completo. Los escaneos SYN son fácilmente detectables y pueden ser bloqueados en cualquier
cortafuegos; existe una variable de esta técnica denominada dumb scanning en la que entra en juego
una tercera máquina denominada `tonta' (por el poco tráfico que emite y recibe), algo que puede
ayudar al pirata a camuflar su origen real. Sin embargo, el dumb scanning es más complicado que el
SYN scanning, por lo que se utiliza mucho menos en la vida real.
Finalmente, existe otra modelo de escaneo denominado stealth scanning. Por stealth
scanning se conoce a una familia de técnicas de escaneo que cumplen alguna de las siguientes
condiciones:
•
Eludir cortafuegos o listas de control de acceso.
•
No ser registradas por sistemas de detección de intrusos, ni orientados a red ni en el propio
host escaneado.
•
Simular tráfico normal y real para no levantar sospechas ante un analizador de red.
Una de las técnicas que encontramos dentro de la familia de los escaneos stealth es la
conocida como SYN+ACK. La idea es muy simple, y consiste en una violación del three-way
handshake: el atacante, en lugar de enviar en primer lugar una trama SYN, envía SYN+ACK. Si el
puerto está abierto simplemente se ignora, y si está cerrado sabe que no ha recibido previamente un
paquete SYN, por lo que lo considera un error y envía una trama RST para finalizar la conexión.
Los escaneos basados en este método se usan poco en la actualidad, debido al elevado
número de falsos positivos que pueden generar: sólo debemos pensar en los múltiples motivos aparte de un puerto abierto - que pueden existir para que un sistema no responda ante una petición
SYN+ACK: desde listas de control de accesos en los routers o cortafuegos hasta simples timeouts.
Otra técnica dentro de los escaneos stealth es el FIN scanning: en este caso, el atacante envía
a su objetivo una trama con el bit FIN activo, ante lo que este responde con un RST si el puerto está
cerrado, o simplemente no responde en caso de estar abierto; como en el caso de los escaneos
SYN+ACK este método puede proporcionar muchos falsos positivos, por lo que tampoco se utiliza
29
mucho hoy en día.
Se propone un método de escaneo algo más complejo: el ACK. El atacante envía una trama
con este bit activo, y si el puerto destino está abierto es muy posible que o bien el campo TTL del
paquete de vuelta sea menor que el del resto de las tramas RST recibidas, o que el tamaño de
ventana sea mayor que cero: como podemos ver, en este caso no basta con analizar el bit RST sino
también la cabecera IP del paquete respuesta. Este método es difícil de registrar por parte de los
detectores de intrusos, pero se basa en el código de red de BSD, por lo que es dependiente del
operativo escaneado.
Para finalizar con la familia de stealth scanning vamos a hablar de dos métodos opuestos
entre sí pero que se basan en una misma idea y proporcionan resultados similares: se trata de
XMAS y NULL. Los primeros, también denominados escaneos `árbol de navidad', se basan en
enviar al objetivo tramas con todos los bits TCP (URG, ACK, PST, RST, SYN y FIN) activos; si el
puerto está abierto el núcleo del sistema operativo eliminará la trama, ya que evidentemente la
considera una violación del three-way handshake, pero si está cerrado devolverá un RST al
atacante. Como antes, este método puede generar demasiados falsos positivos, y además sólo es
aplicable contra máquinas Unix debido a que está basado en el código de red de BSD.
Por contra, el método opuesto al XMAS se denomina NULL scanning, y evidentemente
consiste en enviar tramas con todos los bits TCP reseteados; el resultado es similar: no se devolverá
ningún resultado si el puerto está abierto, y se enviará un RST si está cerrado. Aunque en principio
este método sería aplicable a cualquier pila TCP/IP, la implementación - incorrecta - que de la
misma hacen algunos operativos (entre ellos HP/UX o IRIX) hace que en ocasiones se envien bits
RST también desde los puertos abiertos, lo que puede proporcionar demasiados falsos positivos.
Antes de acabar el punto, vamos a hablar de otra técnica de escaneo de puertos que no se
puede englobar en las tres clases de las que hemos hablado: se trata de los escaneos UDP, que al
contrario de todos los comentados hasta el momento utiliza este protocolo, y no TCP, para
determinar el estado de los puertos de una máquina. Al enviar un datagrama UDP a un puerto
abierto este no ofrece respuesta alguna, pero si está cerrado devuelve un mensaje de error ICMP:
ICMP/SMALL>_PORT/SMALL>_UNREACHABLE.
Evidentemente, estos ataques son muy sencillos de detectar y evitar tanto en un sistema de
detección de intrusos como en los núcleos de algunos Unices, y por si esto fuera poco debemos
recordar que UDP no es un protocolo orientado a conexión (como lo es TCP), por lo que la pérdida
de datagramas puede dar lugar a un elevado número de falsos positivos.
7.2. Spoofing
Por spoofing se conoce a la creación de tramas TCP/IP utilizando una dirección IP falseada;
la idea de este ataque es muy sencilla (no así la ejecución): desde su equipo, un pirata simula la
identidad de otra máquina de la red para conseguir acceso a recursos de un tercer sistema que ha
establecido algún tipo de confianza basada en el nombre o la dirección IP del host suplantado. Y
como los anillos de confianza basados en estas características tan fácilmente falsificables son aún
demasiado abundantes (no tenemos más que pensar en los comandos r-, los accesos NFS, o la
protección de servicios de red mediante TCP Wrapper), el spoofing sigue siendo en la actualidad un
ataque no trivial, pero factible contra cualquier tipo de organización.
Como hemos visto, en el spoofing entran en juego tres máquinas: un atacante, un atacado, y
30
un sistema suplantado que tiene cierta relación con el atacado; para que el pirata pueda conseguir su
objetivo necesita por un lado establecer una comunicación falseada con su objetivo, y por otro
evitar que el equipo suplantado interfiera en el ataque. Probablemente esto último no le sea muy
difícil de conseguir: a pesar de que existen múltiples formas de dejar fuera de juego al sistema
suplantado - al menos a los ojos del atacado - que no son triviales (modificar rutas de red, ubicar un
filtrado de paquetes entre ambos sistemas...), lo más fácil en la mayoría de ocasiones es
simplemente lanzar una negación de servicio contra el sistema en cuestión. Aunque en el punto
siguiente hablaremos con más detalle de estos ataques, no suele ser difícil `tumbar', o al menos
bloquear parcialmente, un sistema medio; si a pesar de todo el atacante no lo consigue, simplemente
puede esperar a que desconecten de la red a la máquina a la que desea suplantar (por ejemplo, por
cuestiones de puro mantenimiento).
El otro punto importante del ataque, la comunicación falseada entre dos equipos, no es tan
inmediato como el anterior y es donde reside la principal dificultad del spoofing. En un escenario
típico del ataque, un pirata envía una trama SYN a su objetivo indicando como dirección origen la
de esa tercera máquina que está fuera de servicio y que mantiene algún tipo de relación de
confianza con la atacada. El host objetivo responde con un SYN+ACK a la tercera máquina, que
simplemente lo ignorará por estar fuera de servicio (si no lo hiciera, la conexión se resetearía y el
ataque no sería posible), y el atacante enviará ahora una trama ACK a su objetivo, también con la
dirección origen de la tercera máquina. Para que la conexión llegue a establecerse, esta última trama
deberá enviarse con el número de secuencia adecuado; el pirata ha de predecir correctamente este
número: si no lo hace, la trama será descartada), y si lo consigue la conexión se establecerá y podrá
comenzar a enviar datos a su objetivo, generalmente para tratar de insertar una puerta trasera que
permita una conexión normal entre las dos máquinas.
Podemos comprobar que el spoofing no es inmediato; de entrada, el atacante ha de hacerse
una idea de cómo son generados e incrementados los números de secuencia TCP, y una vez que lo
sepa ha de conseguir `engañar' a su objetivo utilizando estos números para establecer la
comunicación; cuanto más robusta sea esta generación por parte del objetivo, más difícil lo tendrá el
pirata para realizar el ataque con éxito. Además, es necesario recordar que el spoofing es un ataque
ciego: el atacante no ve en ningún momento las respuestas que emite su objetivo, ya que estas van
dirigidas a la máquina que previamente ha sido deshabilitada, por lo que debe presuponer qué está
sucediendo en cada momento y responder de forma adecuada en base a esas suposiciones.
Para evitar ataques de spoofing exitosos contra nuestros sistemas podemos tomar diferentes
medidas preventivas; en primer lugar, parece evidente que una gran ayuda es reforzar la secuencia
de predicción de números de secuencia TCP. Otra medida sencilla es eliminar las relaciones de
confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones
basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar
nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.
Hasta ahora hemos hablado del ataque genérico contra un host denominado spoofing o, para
ser más exactos, IP Spoofing; existen otros ataques de falseamiento relacionados en mayor o menor
medida con este, entre los que destacan el DNS Spoofing, el ARP Spoofing y el Web Spoofing.
Para finalizar este punto, vamos a comentarlos brevemente e indicar algunas lecturas donde
se puede ampliar información sobre los mismos:
• DNS Spoofing
Este ataque hace referencia al falseamiento de una dirección IP ante una consulta de
resolución de nombre (esto es, resolver con una dirección falsa un cierto nombre DNS), o
viceversa (resolver con un nombre falso una cierta dirección IP). Esto se puede conseguir de
31
diferentes formas, desde modificando las entradas del servidor encargado de resolver una
cierta petición para falsear las relaciones dirección-nombre, hasta comprometiendo un
servidor que infecte la caché de otro (lo que se conoce como DNS Poisoning); incluso sin
acceso a un servidor DNS real, un atacante puede enviar datos falseados como respuesta a
una petición de su víctima sin más que averiguar los números de secuencia correctos.
•
ARP Spoofing
El ataque denominado ARP Spoofing hace referencia a la construcción de tramas de
solicitud y respuesta ARP falseadas, de forma que en una red local se puede forzar a una
determinada máquina a que envíe los paquetes a un host atacante en lugar de hacerlo a su
destino legítimo. La idea es sencilla, y los efectos del ataque pueden ser muy negativos:
desde negaciones de servicio hasta interceptación de datos, incluyendo algunos Man in the
Middle contra ciertos protocolos cifrados.
•
Web Spoofing
Este ataque permite a un pirata visualizar y modificar cualquier página web que su víctima
solicite a través de un navegador, incluyendo las conexiones seguras vía SSL. Para ello,
mediante código malicioso un atacante crea una ventana del navegador correspondiente, de
apariencia inofensiva, en la máquina de su víctima; a partir de ahí, enruta todas las páginas
dirigidas al equipo atacado - incluyendo las cargadas en nuevas ventanas del navegador - a
través de su propia máquina, donde son modificadas para que cualquier evento generado por
el cliente sea registrado (esto implica registrar cualquier dato introducido en un formulario,
cualquier click en un enlace, etc.).
7.3. Negociación de servicios
Las negaciones de servicio (conocidas como DoS, Denial of Service) son ataques dirigidos
contra un recurso informático (generalmente una máquina o una red, pero también podría tratarse de
una simple impresora o una terminal) con el objetivo de degradar total o parcialmente los servicios
prestados por ese recurso a sus usuarios legítimos; constituyen en muchos casos uno de los ataques
más sencillos y contundentes contra todo tipo de servicios, y en entornos donde la disponibilidad es
valorada por encima de otros parámetros de la seguridad global puede convertirse en un serio
problema, ya que un pirata puede interrumpir constantemente un servicio sin necesidad de grandes
conocimientos o recursos, utilizando simplemente sencillos programas y un módem y un PC
caseros.
Las negaciones de servicio más habituales suelen consistir en la inhabilitación total de un
determinado servicio o de un sistema completo, bien porque ha sido realmente bloqueado por el
atacante o bien porque está tan degradado que es incapaz de ofrecer un servicio a sus usuarios. En la
mayor parte de sistemas, un usuario con acceso shell no tendría muchas dificultades en causar una
negación de servicio que tirara abajo la máquina o la ralentizara enormemente; esto no tiene porqué
ser - y de hecho en muchos casos no lo es - un ataque intencionado, sino que puede deberse a un
simple error de programación. El problema real no es que usuarios legítimos de un entorno causen,
intencionada o inintencionadamente, negaciones de servicio: el mayor problema es que esas
negaciones sean causadas de forma remota por piratas ajenos por completo a nuestra organización,
capaces de tumbar un servidor de miles de euros con sencillos programas, sin dejar ningún rastro y
lo peor, sin ser muchas veces conscientes del daño que están haciendo.
Estos ataques remotos de negación de servicio son considerados negativos incluso por
muchos de los propios piratas - especialmente los más experimentados -, ya que realmente no
suelen demostrar nada positivo de quien los lanza (si es que algún ataque demuestra algo positivo
32
de alguien, lo cual sería muy discutible...): generalmente se trata de un script-kiddie ejecutando un
programa que ni ha hecho, ni entiende, ni será capaz de entender. En la mayor parte de los casos la
negación de servicio tiene éxito porque el objetivo utiliza versiones no actualizadas de demonios (si
se para un servicio concreto) o del propio núcleo del sistema operativo, si se detiene o degrada por
completo la máquina. Para evitar esto, la norma a seguir es evidente: mantener siempre actualizados
nuestros sistemas, tanto en lo referente al nivel de parcheado o versiones del núcleo, como en lo
referente a programas críticos encargados de ofrecer un determinado servicio (demonios, por norma
general: sendmail, httpd, pop3d...).
De un tiempo a esta parte - en concreto, desde 1999 - se ha popularizado mucho el término
“negación de servicio distribuida” (Distributed Denial of Service, DDoS): en este ataque un pirata
compromete en primer lugar un determinado número de máquinas y, en un determinado momento,
hace que todas ellas ataquen masiva y simultaneamente al objetivo u objetivos reales enviándoles
diferentes tipos de paquetes; por muy grandes que sean los recursos de la víctima, el gran número
de tramas que reciben hará que tarde o temprano dichos recursos sean incapaces de ofrecer un
servicio, con lo que el ataque habrá sido exitoso. Si en lugar de cientos o miles de equipos atacando
a la vez lo hiciera uno sólo las posibilidades de éxito serían casi inexistentes, pero es justamente el
elevado número de “pequeños” atacantes lo que hace muy difícil evitar este tipo de negaciones de
servicio.
Los ataques de negación de servicio distribuidos más habituales consisten en el envío de un
gran número de paquetes a un determinado objetivo por parte de múltiples hosts, lo que se conoce
como packet flooding (en función del tipo de paquetes utilizados se habla de ping flood, de SYN
flood...). Defenderse de este tipo de ataques es difícil: en primer lugar, uno piensa en bloquear de
alguna forma (probablemente en un cortafuegos o en un router) todo el tráfico proveniente de los
atacantes; pero ¿qué sucede cuando tenemos miles de ordenadores atacando desde un gran número
de redes diferentes? ¿Los bloqueamos uno a uno? Esto supondría un gran esfuerzo que difícilmente
ayudaría, ya que lo más probable es que en el tiempo que nos cueste bloquear el tráfico de una
determinada máquina, dos o tres nuevas nos comiencen a atacar. Entonces, ¿bloqueamos todo el
tráfico dirigido hacia el objetivo? Si hacemos esto, estamos justamente ayudando al atacante, ya que
somos nosotros mismos los que causamos una negación en el servicio a los usuarios legítimos de
nuestro sistema...
Como vemos, la defensa ante una negación de servicio distribuida no es inmediata; en
cualquier caso, podemos tomar ciertas medidas preventivas que nos ayudarán a limitar el alcance de
uno de estos ataques (y en general de las negaciones de servicio remotas, distribuidas o no). De
entrada, un correcto filtrado del tráfico dirigido a nuestras máquinas es vital para garantizar nuestra
seguridad: no hay que responder a pings externos a nuestra red, es necesario activar el antispoofing
en nuestros cortafuegos, etc. Establecer correctamente límites a la utilización de nuestros recursos,
como ya hemos visto, es también una importante medida preventiva; es posible limitar el ancho de
banda dedicado a una determinada aplicación o a un protocolo, de forma que las utilizaciones por
encima del margen son negadas. También podemos limitar los recursos del sistema (CPU, memoria,
disco...) que puede consumir en global una determinada aplicación servidora (por ejemplo, un
demonio sirviendo páginas web), además de restringir sus recursos por cliente simultáneo (en base,
por ejemplo, a la dirección origen de ese cliente).
A pesar de las dificultades con las que nos podemos encontrar a la hora de prevenir ataques
de negación de servicio, una serie de medidas sencillas pueden ayudarnos de forma relativa en esa
tarea; las negaciones de servicio son por desgracia cada día más frecuentes, y ninguna organización
está a salvo de las mismas. Especialmente en los ataques distribuidos, la seguridad de cualquier
33
usuario conectado a Internet (aunque sea con un sencillo PC y un módem) es un eslabón importante
en la seguridad global de la red, ya que esos usuarios se convierten muchas veces sin saberlo en
satélites que colaboran en un ataque masivo contra organizaciones de cualquier tipo.
7.4. Interceptación
En este apartado nos vamos a centrar en la interceptación lógica. Y sin duda, la interceptación
lógica de datos más conocida y extendida es el sniffing.
En las redes de difusión, cuando una máquina envía una trama a otra indica en un campo
reservado la dirección del host destino; todas las máquinas del dominio de colisión ven esa trama,
pero sólo su receptora legítima la captura y elimina de la red. Este es el funcionamiento normal de
TCP/IP; sin embargo, es necesario insistir en un aspecto: todas las máquinas ven la trama, y si no
leen todos sus campos es porque no “quieren”. Existe un modo de funcionamiento de las interfaces
de red denominado modo promiscuo, en el cual la tarjeta lee todas las tramas que circulan por la
red, tanto dirigidas a ella como a otras máquinas; el leerlas no implica el eliminarlas de la red, por
lo que el host destino legítimo la recibirá y eliminará sin notar nada extraño.
Para hacer funcionar un interfaz de red en modo promiscuo es necesario tener un control
total del sistema o, dicho de otra forma, ser root en la máquina; esto ayuda un poco en la defensa,
pero ni de lejos soluciona el problema que estamos planteando: no podemos permitir que cualquiera
que sea superusuario de un sistema pueda capturar todo el tráfico que pasa por el mismo
(incluyendo claves, correo electrónico, y cientos de datos privados). Por si esto fuera poco, en los
sistemas donde todos los usuarios tienen un control total de la máquina (por ejemplo, en toda la
familia Windows 9x) ni siquiera hace falta ese privilegio: cualquiera que se siente en un PC puede
ejecutar un sniffer y capturar todo el tráfico de la red.
Programas para `esnifar' tráfico hay para todos los gustos y colores: desde dsniff y su
familia, capaces hasta de capturar los correos electrónicos directamente en formato SMTP o cargar
de forma automática en un navegador las mismas páginas que visita la víctima del ataque, hasta el
arcaico snoop de Solaris, que vuelca paquetes en un formato por defecto casi ilegible, pasando por
los clásicos tcpdump o sniffit (que en algunas de sus versiones incluía el Touch of Dead, capaz de
cortar conexiones establecidas entre dos máquinas sin más que pulsar F5). Para evitar que
programas de este tipo capturen nuestra información existen diferentes aproximaciones más o
menos efectivas, como sustituir los HUBs de nuestra red por switches que aislan dominios de
colisión (¡ojo, esto dificulta el ataque pero no lo imposibilita!) o implantar redes privadas virtuales.
Pero sin ninguna duda la más barata y sencilla es el uso de protocolos cifrados siempre que
nos sea posible (que lo suele ser casi siempre); sustituir telnet y rlogin por SSH y FTP por scp o sftp
es muy sencillo, y nos proporciona un incremento de seguridad abismal en nuestro entorno.
Implantar SSL o túneles seguros quizás es algo más costoso - en tiempo solamente -, pero
también en la mayoría de ocasiones es algo que vale la pena hacer: en todo momento hemos de
tener presente que el sniffing es un peligro real, que no necesita de grandes medios y, lo que es
peor, indetectable en la mayor parte de casos; a pesar de que existen métodos para tratar de detectar
sistemas con un interfaz en modo promiscuo, no suelen ser todo lo efectivos que uno podría esperar,
ya que detectar una máquina en este estado no es ni de lejos inmediato.
Para finalizar este punto podemos reflexionar brevemente sobre la peligrosidad de los
ataques de interceptación; muchos de ellos necesitan privilegios de superusuario en al menos una
34
máquina, pero por lo demás son realmente sencillos. Sencillos y peligrosos: aunque se trate de
ataques pasivos, y aunque alguien pueda pensar que si el pirata ya es root no se puede atacar más al
sistema, permiten capturar datos relativos no sólo al sistema comprometido, sino a otras máquinas
que quizás aún no han sido atacadas y que posiblemente representan el objetivo real del pirata.
Evitar estos ataques pasa en primera instancia por no permitir que un pirata consiga
privilegios en un sistema - mejor si no consigue nada, pero esto no siempre es posible -, y en
segunda por lo que ya sabemos: cifrar cuanto más tráfico mejor.
7.5. Ataques de aplicaciones
7.5.1. Correo Electrónico
Desde hace muchos años los sistemas de correo electrónico de una organización han sido
para los piratas una fuente inagotable de puntos de entrada a la misma; lo más probable es que si le
preguntamos a cualquier administrador con algo de experiencia cuál ha sido el software que más
problemas de seguridad le ha causado nos responda sin dudarlo: sendmail, por supuesto. Y ya no
sólo sendmail y el protocolo SMTP, sino que también, con la popularización de POP3, los
servidores de este protocolo son un peligro potencial a tener en cuenta en cualquier entorno
informático donde se utilice el correo electrónico: es decir, en todos.
De entrada, un programa como sendmail - lo ponemos como ejemplo por ser el más popular,
pero podríamos hablar en los mismos términos de casi cualquier servidor SMTP - proporciona
demasiada información a un atacante que simplemente conecte a él:
Y no sólo se proporcionan datos útiles para un pirata como la versión del programa utilizada
o la fecha del sistema, sino que se llega incluso más lejos: tal y como se instalan por defecto,
muchos servidores SMTP (aparte de sendmail, algunos tan populares como Netscape Messaging
Server) informan incluso de la existencia o inexistencia de nombres de usuario y de datos sobre los
mismos.
Independientemente del programa que utilicemos como servidor de correo y su versión
concreta, con vulnerabilidades conocidas o no, otro gran problema de los sistemas de correo SMTP
es el relay: la posibilidad de que un atacante interno utilice nuestros servidores para enviar correo
electrónico a terceros, no relacionados con nuestra organización. Aunque en principio esto a
muchos les pueda parecer un mal menor, no lo es; de entrada, si nuestros servidores permiten el
relay estamos favoreciendo el SPAM en la red, el envío de e-mail no deseado con fines casi siempre
publicitarios, algo que evidentemente a nadie le hace gracia recibir. Además, el relay causa una
negación de servicio contra nuestros usuarios legítimos, tanto desde un punto de vista estrictamente
teórico - alguien consume nuestros recursos de forma no autorizada, degradando así el servicio
ofrecido a nuestros usuarios legítimos - como en la práctica: cuando un robot encuentra un servidor
SMTP en el que se permite el relay lo utiliza masivamente mientras puede, cargando enormemente
la máquina y entorpeciendo el funcionamiento normal de nuestros sistemas. Por si esto fuera poco,
si se incluye a nuestra organización en alguna `lista negra' de servidores que facilitan el SPAM se
causa un importante daño a nuestra imagen, e incluso ciertos dominios pueden llegar a negar todo el
correo proveniente de nuestros servidores.
Sólo existe una manera de evitar el relay: configurando correctamente todos nuestros
servidores de correo. Por supuesto, esto es completamente dependiente de los programas (sendmail,
iPlanet...) utilizados en nuestro entorno, por lo que es necesario consultar en la documentación
correspondiente la forma de habilitar filtros que eviten el relay; por Internet exiten incluso filtros
35
genéricos para los servidores más extendidos, por lo que nuestro trabajo no será excesivo ni
complicado.
Es muy importante para nosotros cuidar cualquier aspecto de la seguridad relativo a nuestros
sistemas de correo, ya que en la actualidad el correo electrónico constituye uno de los servicios
básicos de cualquier empresa; simplemente hemos de contar el número de e-mails que solemos
recibir al día para hacernos una idea del desastre que supondría un fallo en los sistemas encargados
de procesarlo.
7.5.2. Ataques vía web
Durante los últimos años los servidores web se han convertido en una excelente fuente de
diversión para piratas: cualquier empresa que se precie, desde las más pequeñas a las grandes
multinacionales, tiene una página web en las que al menos trata de vender su imagen corporativa. Si
hace unos años un pirata que quisiera atacar a una empresa (y no a todas, ya que muy pocas tenían
representación en la red) tenía que agenciarselas para obtener primero información de la misma y
después buscar errores de configuración más o menos comunes de sus sistemas (o esperar al
próximo bug de sendmail), hoy en día le basta con teclear el nombre de su objetivo en un navegador
y añadir la coletilla `.com' detrás del mismo para contactar con al menos una de sus máquinas: su
servidor web.
La mayor parte de estos ataques tiene éxito gracias a una configuración incorrecta del
servidor o a errores de diseño del mismo: si se trata de grandes empresas, los servidores web suelen
ser bastante complejos (alta disponiblidad, balanceo de carga, sistemas propietarios de actualización
de contenidos...) y difíciles de administrar correctamente, mientras que si la empresa es pequeña es
muy posible que haya elegido un servidor web simple en su instalación y administración pero en el
cual es casi imposible garantizar una mínima seguridad: sí, hablamos de Microsoft Internet
Information Server, un sistema que reconocidos expertos en seguridad han recomendado
públicamente no utilizar en entornos serios. Sea por el motivo que sea, la cuestión es que cada día
es más sencillo para un pirata ejecutar órdenes de forma remota en una máquina, o al menos
modificar contenidos de forma no autorizada, gracias a los servidores web que un sistema pueda
albergar.
Cualquier analizador de vulnerabilidades que podamos ejecutar contra nuestros sistemas
(NESSUS, ISS Security Scanner, NAI CyberCop Scanner...) es capaz de revelar información que
nos va a resultar útil a la hora de reforzar la seguridad de nuestros servidores web; incluso existen
analizadores que están diseñados para auditar únicamente este servicio, como whisker.
¿Cómo evitar estos problemas de seguridad de los que estamos hablando? Una medida
elemental es eliminar del servidor cualquier directorio o CGI de ejemplo que se instale por defecto;
aunque generalmente los directorios (documentación, ejemplos...) no son especialmente críticos, el
caso de los CGIs es bastante alarmante: muchos servidores incorporan programas que no son ni
siquiera necesarios para el correcto funcionamiento del software, y que en ciertos casos demasiados - abren enormes agujeros de seguridad, como el acceso al código fuente de algunos
archivos, la lectura de ficheros fuera del DocumentRoot, o incluso la ejecución remota de comandos
bajo la identidad del usuario con que se ejecuta el demonio servidor.
Otra medida de seguridad básica es deshabilitar el Directory Indexing que por defecto
muchos servidores incorporan: la capacidad de obtener el listado de un directorio cuando no existe
un fichero index.html o similar en el mismo; se trata de una medida extremadamente útil y sobre
todo sencilla de implantar, ya que en muchos casos un simple `chmod -r' sobre el directorio en
36
cuestión es suficiente para evitar este problema. A primera vista esta medida de protección nos
puede resultar curiosa: a fin de cuentas, a priori todo lo que haya bajo el Document Root del
servidor ha de ser público, ya que para eso se ubica ahí. Evidentemente la teoría es una cosa y la
práctica otra muy diferente: entre los ficheros de cualquier servidor no es extraño encontrar desde
archivos de log - por ejemplo, del cliente FTP que los usuarios suelen usar para actualizar
remotamente sus páginas, como WS/SMALL>_FTP.LOG - hasta paquetes TAR con el contenido
de subdirectorios completos. Por supuesto, la mejor defensa contra estos ataques es evitar de alguna
forma la presencia de estos archivos bajo el Document Root, pero en cualquier caso esto no es
siempre posible, y si un atacante sabe de su existencia puede descargarlos, obteniendo en muchos
casos información realmente útil para atacar al servidor (como el código de ficheros JSP, PHP,
ASP...o simplemente rutas absolutas en la máquina), y una excelente forma de saber que uno de
estos ficheros está ahí es justamente el Directory Indexing; por si esto no queda del todo claro, no
tenemos más que ir a un buscador cualquiera y buscar la cadena `Index of /admin', por poner un
ejemplo sencillo, para hacernos una idea de la peligrosidad de este error de configuración.
Además, en cualquier servidor web es muy importante el usuario bajo cuya identidad se
ejecuta el demonio httpd: ese usuario no debe ser nunca el root del sistema (evidente), pero tampoco
un usuario genérico como nobody; se ha de tratar siempre de un usuario dedicado y sin acceso real
al sistema. Por supuesto, las páginas HTML (los ficheros planos, para entendernos) nunca deben ser
de su propiedad, y mucho menos ese usuario ha de tener permiso de escritura sobre los mismos: con
un acceso de lectura (y ejecución, en caso de CGIs) es más que suficiente en la mayoría de los
casos. Hemos de tener en cuenta que si el usuario que ejecuta el servidor puede escribir en las
páginas web, y un pirata consigue - a través de cualquier tipo de error (configuración, diseño del
demonio...) - ejecutar órdenes bajo la identidad de dicho usuario, podrá modificar las páginas web
sin ningún problema (que no olvidemos, es lo que perseguirá la mayoría de atacantes de nuestro
servidor web).
Igual de importante que evitar estos problemas es detectar cuando alguien trata de
aprovecharlos intentando romper la seguridad de nuestros servidores; para conseguirlo no tenemos
más que aplicar las técnicas de detección de intrusos que veremos en el capítulo siguiente. Una
característica importante de los patrones de detección de ataques vía web es que no suelen generar
muchos falsos positivos, por lo que la configuración de la base de datos inicial es rápida y sencilla,
al menos en comparación con la detección de escaneos de puertos o la de tramas con alguna
característica especial en su cabecera.
7.6 Ejemplo de ataque remotos (Nessus)
Una vez explicado como manejar las reglas de Snort, como interpretarlas, y la necesidad de
que el administrador trabaje para que sus alertas sean las que necesite, vamos a pasar a realizar un
ataque remoto real mediante la herramienta Nessus.
El sitio oficial de Nessus es www.nessus.org. Nessus es un potente escáner de redes de
Software Libre. Consta de dos partes (cliente/servidor) que pueden estar instaladas en las misma
máquina por simplicidad. Se debe comentar que si el ataque se hace hacia localhost lo que se
consigue es auditar nuestra propia máquina. Cuando Nesuss finaliza el escaneo genera unos
informes muy útiles si se sabe aprovechar e interpretar la información obtenida.
Consiste en nessusd, el daemon Nessus, que realiza el escaneo en el sistema objetivo, y
37
nessus, el cliente (basado en consola o gráfico) que muestra el avance y reporte de los escaneos.
Desde consola nessus puede ser programado para hacer escaneos programados con cron.
En operación normal, nessus comienza escaneando los puertos con nmap o con su propio
escaneador de puertos para buscar puertos abiertos y después intentar varios exploits, es el nombre
con el que se identifica un programa informático malicioso, o parte del programa, que trata de
forzar alguna deficiencia o vulnerabilidad de otro programa (llamadas bugs). El fin puede ser la
destrucción o inhabilitación del sistema atacado, aunque normalmente se trata de violar las medidas
de seguridad para poder acceder al mismo de forma no autorizada y emplearlo en beneficio propio o
como origen de otros ataques a terceros, para atacarlo. Las pruebas de vulnerabilidad, disponibles
como una larga lista de plugins, son escritos en NASL (Nessus Attack Scripting Language,
Lenguaje de Scripting de Ataque Nessus por sus siglas en inglés), un lenguaje scripting optimizado
para interacciones personalizadas en redes.
Opcionalmente, los resultados del escaneo pueden ser exportados en reportes en varios
formatos, como texto plano, XML, HTML, y LaTeX. Los resultados también pueden ser guardados
en una base de conocimiento para referencia en futuros escaneos de vulnerabilidades.
Algunas de las pruebas de vulnerabilidades de Nessus pueden causar que los servicios o
sistemas operativos se corrompan y caigan. El usuario puede evitar esto desactivando "unsafe test"
(pruebas no seguras) antes de escanear
Descargamos Nessus y lo instalamos en una máquina diferente a la que tenemos Snort.
Nosotros instalamos Nessus en 155.54.197.186 y atacamos al equipo que tiene Snort, cuya IP es
155.54.197.77. Snort creará las alertas pertinentes, las capturas que realiza son las siguientes:
Se crean 1999 alertas creadas los el tráfico que Snort detecta como malicioso, lo que deja
totalmente plasmado todos los accesos que realiza el equipo atacante hacia el atacado.
38
Este ejemplo nos muestra como Snort nos permitirá realizar posteriormente un análisis
forense de los datos que hemos registrado sobre el escaneo de puertos, y los exploit realizados
posteriormente.
No obstante, una de las grandes capacidades que nos produce el uso de Nessus será el echo
de que si lo realizamos contra nuestra red o equipo, nos dará un informe detallado de todo lo que ha
realizado.
Pongamos un ejemplo:
1- Decimos que queremos realizar el scan sobre nuestro equipo.
39
2- Elejimos la configuración por defecto:
3- Le decimos que escanee desde nustro propio equipo:
40
- Estos son los datos recogidos:
Los datos se muestran el una página HTML, y nos dice la máquina escaneada, los puertos
abiertos detectados, ... Posteriormente comienza a explicar toda la información que ha podido
conseguir sobre la máquina escaneada.
Información que se consigue del puerto de MySql:
41
8. Conclusión
En este documento hemos querido dejar claro la utilidad de Snort, así como el trabajo que un
administrador deberá realizar para que solamente se muestren las alertas que él, como
administrador, considera que merecen la pena.
Por otro lado, también hemos querido mostrar, como la utilización de otras herramientas que
complementen Snort, como MySql y ACID harán que la tarea de análisis forense, para la toma de
decisiones sea menos costosa, así como facilitar un tutorial para la instalación de
Snort+MySql+ACID.
También hemos mostrado los típicos, que no todos, ataques remotos, de manera que puede
ser de utilidad el conocer los por menores de cada uno de ellos.
Y por último, hemos tratado de mostrar la utilidad de otra herramienta, Nessus, para la labor
del administrador, así como mostrar los resultados que se darían en el caso de que un ataque
remoto, en concreto un escaneo de puertos con su posterior exploit.
42