Embed Size (px)
Citation preview
Identificando Nuevas Funcionalidades
de Seguridad para Redes WLAN a través de los IPDS
T E S I S Que para obtener el grado de
Maestro en Ingeniería de Software
P r e s e n t a Faleg Alejandro Peralta Martínez
Director de Tesis:
Dr. Jezreel Mejía Miranda
Codirector:
Dra. Mirna Ariadna Muñoz Mata
Zacatecas, Zac. febrero del 2018
Zacatecas, Zac. Julio del 2017
Centro de Investigación en Matemáticas, A.C.
1
Abstract
For years, threads have evolved and adapted, identifying and detecting the abnormal traffic
within the organizations allows to prevent this is altered or in the worst case scenario
interrupted. New methods are used to compare the abnormal traffic based on the analysis of the
expected behavior through the usage of new generation devices. The Intrusion Detection
Systems (IDS) and Intrusion Prevention Systems (IPS) are physical or logical devices which
allow analyze the network traffic to identify possible malicious or anomalous packets. This
article will analyze the usage of these devices, their techniques and practical application.
Likewise, it will be analyzed the differences between IDS and IPS, advantages and
disadvantages and different ways how they work
Keywords: Intrusion Prevention Systems (IPS), Intrusion Detection Systems (IDS), Security,
Networks, Digital Defenses.
2
Resumen
Durante años las amenazas en las Tecnologías de la Información (TI) han evolucionado y se
han adaptado, la importancia de identificar y detectar el tráfico anormal dentro de las
organizaciones permite prevenir que esté se altere o en el peor de los casos se vea interrumpido.
En este contexto nuevos dispositivos son utilizados para comparar el tráfico anormal basado en
el análisis del comportamiento esperado mediante el uso de dispositivos de nueva generación.
Los Sistemas de Detección de Intrusos (IDS) y los Sistemas de Prevención de Intrusos (IPS),
permiten analizar el tráfico de red para identificar posibles paquetes maliciosos o anómalos.
Esta investigación analiza el uso de estos dispositivos, sus técnicas y aplicaciones, ventajas y
desventajas, y las diferentes formas en las que trabajan, con la finalidad de establecer el estado
del arte sobre alcance de la aplicación de los IDS/ IPS.
Palabras clave: Sistema de Prevención de Intrusos (IPS), Sistema de Detención de Intrusos
(IDS), Seguridad, Redes, Defensa Digital.
3
Oficio de Autorización de Impresión
4
Agradecimientos
A Dios
Por acompañarme en esta travesía, por la salud que me ha dado para lograr mis objetivos, su
infinita bondad, su amor, que, junto con su madre María, me han dado la fortaleza en los
momentos de debilidad, brindándome aprendizajes y experiencias a lo largo de mi corta vida.
A mi padre
Que han pesar de las diferencias que tenemos, su apoyo es incondicional, mostrándome el valor
para salir adelante, dándome un excelente ejemplo de vida.
A mi madre
Por apoyarme en todo momento, agradezco su paciencia, amor incondicional, los valores
inculcados, sus consejos, pero sobre todo por ser mi madre.
A mi hermana
Por ser una parte muy importante de mi vida, su esposo y en especial a mi sobrino por llenar
mi vida de alegrías y amor cuando más lo he necesitado.
A mi esposa y mi hija
Los cuales con sus detalles que me han brindado en este poco tiempo, fueron base fundamental
para lograr el objetivo; las líneas son pocas para agradecerles por su participación directa o
indirecta en la elaboración de mi tesis.
A mis maestros
El Dr. Jezreel Mejía Miranda y la Dra. Mirna Ariadna Muñoz Mata, por su apoyo, motivación
y tiempo brindado; A los distintos docentes dentro del CIMAT, gracias por las facilidades
brindadas para el desarrollo de mi tesis profesional.
Al Consejo Nacional de Ciencia y Tecnología (CONACYT)
Por el apoyo económico otorgado para la realización de los estudios de maestría y el desarrollo
del presente trabajo de tesis. De igual manera, agradezco al Centro de Investigación en
Matemáticas por los apoyos otorgados para estancias de investigación y participación en
congresos.
A mis familiares, amigos y compañeros
Por ser parte significativa de mi vida, por los buenos y malos momentos, vivencias, confianza,
apoyo y comprensión, las cuales nunca olvidare; gracias por su amistad. Por último, a mi perrita
coco, por ser mi compañera de líneas y brindarme su compañía incondicional.
Faleg.
5
Índice
Abstract.................................................................................................................................................. 1
Resumen ................................................................................................................................................. 2
Oficio de Autorización de Impresión .................................................................................................. 3
Agradecimientos .................................................................................................................................... 4
A Dios ..................................................................................................................................................... 4
Introducción ........................................................................................................................................ 12
Capítulo 1. Antecedentes ................................................................................................................ 14
1.1. Tecnologías de la Información y Comunicación .................................................................. 14
1.1.1. Ciberseguridad en México ............................................................................................ 16
1.1.2. Amenazas informáticas ................................................................................................. 16
1.1.2.1. Ataques informáticos ............................................................................................ 17
1.1.2.2. Los Piratas informáticos........................................................................................ 18
1.2. Modelo y/o estándares enfocados a la seguridad informática Objetivos .............................. 18
1.3. Gestión de Riesgos ................................................................................................................ 19
1.4. IDPS (Sistemas de Detención y Prevención de Intrusos) ..................................................... 20
1.4.1. Definiciones .................................................................................................................. 20
1.4.1. Clasificaciones .............................................................................................................. 21
1.4.1. Implementaciones ......................................................................................................... 22
1.4.1. Ventajas y Desventajas ................................................................................................. 23
1.4.1. Alertas ........................................................................................................................... 23
1.5. Planteamiento del problema .................................................................................................. 24
1.6. Hipótesis ............................................................................................................................... 24
1.7. Objetivos ............................................................................................................................... 25
1.7.1. Objetivo General ........................................................................................................... 25
1.7.2. Objetivos específicos .................................................................................................... 25
1.8. Justificación .......................................................................................................................... 25
Capítulo 2. Estado del arte ............................................................................................................. 27
2.1. Revisión Sistemática de la Literatura.................................................................................... 27
2.1.1. Planificación de la RLS ................................................................................................ 28
2.1.1.1. Identificación de la necesidad de la RLS .............................................................. 28
6
2.1.1.2. Preguntas de investigación .................................................................................... 28
2.1.1.3. Cadenas de búsqueda ............................................................................................ 29
2.1.1.4. Fuentes para la extracción de la información ........................................................ 29
2.1.1. Ejecución de la revisión sistemática ............................................................................. 30
2.1.1.1. Criterios de inclusión y exclusión ......................................................................... 30
2.1.1.1. Selección de estudios primarios ............................................................................ 31
2.1.1.1. Extracción de Datos .............................................................................................. 31
2.1.1. Reporte de Resultados ................................................................................................... 32
2.1.1.1. Alcance de la aplicación de los IDPS ................................................................... 32
2.2. Trabajos relacionados ........................................................................................................... 35
2.2.1. Comparativa de propuestas ........................................................................................... 37
Capítulo 3. Metodología para el desarrollo de la tesis ................................................................. 39
3.1. Ejecución de la metodología para el desarrollo de Tesis ...................................................... 40
Capítulo 4. Propuesta ..................................................................................................................... 42
4.1. Prerrequisitos ........................................................................................................................ 42
4.1.1. Snort .............................................................................................................................. 42
4.1.1. Elastic Stack (EKL) ...................................................................................................... 43
4.1.2. Filebeat (beats) .............................................................................................................. 43
4.1.1. Elastic Cloud ................................................................................................................. 45
4.1.1. HTTP/HTTPS ............................................................................................................... 45
4.1. Programación de Snort .......................................................................................................... 46
4.1. Desarrollo de la herramienta ................................................................................................. 49
4.1.1. Página de Bienvenida .................................................................................................... 49
4.1.1. Página de Acerca de ...................................................................................................... 50
4.1.1. Contacto ........................................................................................................................ 51
4.1.2. Inicio de Sesión ............................................................................................................. 51
4.1.3. Reglas ............................................................................................................................ 52
4.1.1. DashBoard..................................................................................................................... 53
4.1.2. Elastic Cloud ................................................................................................................. 54
4.1.3. Azure ............................................................................................................................. 55
Capítulo 5. Resultados .................................................................................................................... 57
5.1. Herramienta para identificación de vulnerabilidades de intrusión mediante el
establecimiento de reglas y análisis de logs por medio de la plataforma Elastic Stack. ................... 57
7
5.1. Estudio de Caso .................................................................................................................... 64
5.1.1. Diseño y planificación de los casos de estudio ............................................................. 65
5.1.1.1. Objetivo de los casos de estudio ........................................................................... 66
5.1.1.2. Objeto de estudio .................................................................................................. 66
5.1.1.3. Marco de referencia .............................................................................................. 66
5.1.1.4. Preguntas de investigación .................................................................................... 66
5.1.1.5. Métodos para la recogida de datos ........................................................................ 67
5.1.2. Preparación de la recogida de datos .............................................................................. 67
5.1.1. Recogida de datos ......................................................................................................... 68
5.1.1. Análisis de los datos recogidos ..................................................................................... 68
5.1.1. Reporte de resultados RED 01 ...................................................................................... 69
5.1.1. Reporte de resultados RED 02 ...................................................................................... 71
Capítulo 6. Conclusiones ................................................................................................................ 74
6.1. Conclusiones ......................................................................................................................... 74
6.2. Trabajo futuro ....................................................................................................................... 74
6.3. Logros académicos................................................................................................................ 75
6.3.1. Productos académicos ................................................................................................... 75
Referencias .......................................................................................................................................... 76
Anexos .................................................................................................................................................. 79
8
Índice de Figuras
Figura 1. Cambios Principales de las TIC a nivel Mundial, 2000 – 2015 ............................................ 14
Figura 2. Niveles de ciberseguridad, Índice Mundial de Ciberseguridad 2014. ................................... 15
Figura 3. Fases comunes de un ataque informático .............................................................................. 17
Figura 4. IDS/ IPS basados en red. ....................................................................................................... 21
Figura 5. IDS/IPS basados en host. ....................................................................................................... 22
Figura 6. Modo In-line. ......................................................................................................................... 22
Figura 7. Modo SPAN. ......................................................................................................................... 23
Figura 8. Alertas en los IDS / IPS. ........................................................................................................ 24
Figura 9. Selección de estudios primarios. ........................................................................................... 31
Figura 10. Estudios Primarios Seleccionados en la RSL. ..................................................................... 32
Figura 11. IDPS en modo de implementación In-Line. ........................................................................ 33
Figura 12. Metodología para el desarrollo de la tesis. .......................................................................... 39
Figura 13. Página principal de Snort. ................................................................................................... 43
Figura 14. Herramientas ofrecidas en la plataforma Elastic Stack. ...................................................... 44
Figura 15. Plataforma de servicios Azure. ........................................................................................... 44
Figura 16. Plataforma oficial de Elastic Stack. ..................................................................................... 45
Figura 17. HTTP vs HTTPS. ................................................................................................................ 46
Figura 18. Snort en modo de Ejecución IDS. ....................................................................................... 47
Figura 19. Snort en modo de ejecución registro. .................................................................................. 48
Figura 20. Snort en modo de ejecución sniffer. .................................................................................... 48
Figura 21. Página principal de SnortNet. .............................................................................................. 50
Figura 22. Página de Acerca de. ........................................................................................................... 50
Figura 23. Página de contacto de la aplicación. .................................................................................... 51
Figura 24. Vista de Inicio de sesión. ..................................................................................................... 52
Figura 25. Vista de Reglas SnortNet. .................................................................................................... 53
Figura 26. Vista DashBoard de SnortNet. ............................................................................................ 53
Figura 27. Elastic Cloud en su versión trial. ......................................................................................... 54
Figura 28. . Configuración de nuestro clúster Elastic Stack. ................................................................ 55
Figura 29. Datos de acceso a nuestro clúster Elastic Stack................................................................... 55
Figura 30. Información de cuenta Gratuita de Azure ............................................................................ 56
Figura 31. Panel principal de nuestros servicios hospedados en Azure. ............................................... 56
Figura 32. Pantalla principal de la aplicación SnortNet, en ella se detalla las reglas básicas para
creación de reglas. ................................................................................................................................. 59
Figura 33. Pantalla principal de creación de reglas de SnortNet. ......................................................... 59
Figura 34. Pantalla de inicio de ejecución de Snort. ............................................................................. 60
Figura 35. Pantalla de inicio de ejecución de FileBeat. ........................................................................ 60
Figura 36. Cluster de Elastic Search montado para nuestra aplicación. ............................................... 60
Figura 37. Plataforma Azure creada para nuestra aplicación SnortNet. ............................................... 61
Figura 38. . Reglas Locales agregadas a nuestro archivo local.rules. ................................................... 61
9
Figura 39. Reglas base obtenidas después del registro en la plataforma Snort. .................................... 61
Figura 40. Ejemplo de Log de Salida creado por Snort. ....................................................................... 62
Figura 41. Parámetros de configuración de la plataforma Elastic Stack. .............................................. 62
Figura 42. Dominio de la Plataforma Elastic Stack. ............................................................................. 62
Figura 43. Análisis de Logs mediante Kibana por medio de la plataforma Elastic Stack. ................... 63
Figura 44. Representación de Logs por Logs mediante Kibana por medio de la plataforma Elastic
Stack. .................................................................................................................................................... 64
Figura 45. Pasos para implementar un caso de estudio. ........................................................................ 65
Figura 46. Pasos para la recolección de datos ....................................................................................... 68
Figura 47. Muestra de datos obtenidos en nuestra red 01. .................................................................... 69
Figura 48. Flujo y descripción general de la buscada. .......................................................................... 70
Figura 49. Filtrado de Información por cabecera, datos relevantes del análisis. .................................. 71
Figura 50. Muestra de datos obtenidos en nuestra red 02. .................................................................... 71
Figura 51. Flujo y descripción general de la buscada. .......................................................................... 72
Figura 52. Filtrado de Información por cabecera, datos relevantes del análisis. .................................. 73
Figura 53. Arquitectura de Snort. ......................................................................................................... 85
Figura 54. Visor de Paquetes de Snort. ................................................................................................. 86
Figura 55. Preprocesador de Snort. ....................................................................................................... 86
Figura 56. Motor de Detección de snort. .............................................................................................. 87
Figura 57. Consola de administración EasyIDS ................................................................................... 89
Figura 58. Pantalla principal de instalación de EasyIDS. ..................................................................... 90
Figura 59. Pantalla de introducción de contraseña para el administrador. ............................................ 90
Figura 60. Instalación en proceso de la herramienta. ............................................................................ 91
Figura 61. Login de aplicación por medio de la consola. ..................................................................... 91
Figura 62. Acceso correcto a la aplicación. .......................................................................................... 92
Figura 63.Pantalla principal de administración de EasyIDS. ................................................................ 92
Figura 64. BASE muestra reportes de alertas, tráfico, sensores y otros datos interesantes de acuerdo a
la configuración que realizamos. .......................................................................................................... 93
Figura 65. Envió de mails, cambio de interface eths, y deshabilitar los Bogons (El filtrado de Bogons
es la práctica de filtrar direcciones IP falsas) ........................................................................................ 93
Figura 66. ntop despliega diferentes tipos de estadísticas por mencionar algunas: tráfico, Uso de la
Red, Host, entre otros. .......................................................................................................................... 94
Figura 67. Pantalla de gráficos de EasyIDS. ......................................................................................... 94
Figura 68. Pantalla de sistema de EasyIDS........................................................................................... 95
Figura 69. Pantalla de Alertas. .............................................................................................................. 95
Figura 70. Pantalla de configuración dentro de EasyIDS. .................................................................... 96
Figura 71. Del mismo modo pueden agregarse o retirarse configuraciones mediante scripts. ............. 96
Figura 72. Pantalla estatus de nuestro Sensor. ...................................................................................... 96
Figura 73. Pantalla de herramientas. ..................................................................................................... 97
Figura 74. División del modelo OSI en Capas. .................................................................................... 98
Figura 75. Modelo TCP/ IP y sus capas. ............................................................................................... 99
Figura 76. Comparación entre el Modelo OSI vs el modelo TCP/IP.................................................... 99
10
Figura 77. Ejemplo de artefacto IPDS de CISCO. .............................................................................. 101
Figura 78. Ejemplo de Dispositivo según la terminología de CISCO. ............................................... 102
Figura 79. IDPS en modo In-line. ....................................................................................................... 105
Figura 80. IDPS en Modo Passive. ..................................................................................................... 106
Figura 81. Pantalla principal para la administración del CISCO FireSIGHT. .................................... 109
Figura 82. Vista general del menú CISCO FireSIGHT. ..................................................................... 109
Figura 83. Pantalla de configuración de red. ...................................................................................... 111
Figura 84. Pantalla de Configuración de zona horaria. ....................................................................... 111
Figura 85. Pantalla de administración de dispositivos. ....................................................................... 112
Figura 86. Pantalla de descripción general de contratos y licencias dentro del sistema FireSIGHT .. 112
Figura 87. Pantalla para ingresar al menú Objetos. ............................................................................ 113
Figura 88. Lista del menú Objetos. ..................................................................................................... 113
Figura 89. Pantalla de manipulación de Objetos de Red. ................................................................... 114
Figura 90. Pantalla principal de las listas de inteligencia. .................................................................. 114
Figura 91. Pantalla para la manipulación de las listas de inteligencia. ............................................... 115
Figura 92. Frecuencia de Actualización. ............................................................................................. 115
Figura 93.Pantalla de agregación de Objetos. ..................................................................................... 116
Figura 94. Listas Estaticas IP para manipulación de Objetos. ............................................................ 116
Figura 95.Pantalla para agregación de objetos de puerto. ................................................................... 117
Figura 96. Pantalla para agregación de objetos de puerto por grupo. ................................................. 117
Figura 97. Pantalla de agregación de Objetos VLAN. ........................................................................ 118
Figura 98. Pantalla de agregación de Objetos VLAN por grupo. ....................................................... 118
Figura 99. Pantalla de agregación de objetos URL. ............................................................................ 119
Figura 100. Pantalla de agregación de objetos URL por grupos......................................................... 119
Figura 101. Pantalla para la agregación de filtrado de aplicaciones. .................................................. 120
Figura 102. Descripción del filtrado de aplicaciones. ......................................................................... 121
Figura 103. Pantalla de administración de variables. .......................................................................... 121
Figura 104. Pantalla de administración de listas de objetos. .............................................................. 122
Figura 105. Diferentes entradas existentes para la configuración de listas de archivos. .................... 123
Figura 106. Pantalla de administración de zonas de seguridad. .......................................................... 124
Figura 107. Pantalla de administración de la geolocalización. ........................................................... 124
Figura 108. Descripción en capas de las políticas IPS ........................................................................ 126
Figura 109. Pantalla para creación de políticas................................................................................... 127
Figura 110. Vista capas de políticas desde el editor. .......................................................................... 128
Figura 111.Vista reglas desde el inspector de políticas. ..................................................................... 129
Figura 112. Pantalla de Filtrado de políticas. ..................................................................................... 129
Figura 113. Pantalla de Recomendación de políticas FireSIGTH. ..................................................... 131
Figura 114. Pantalla de capa de políticas. ........................................................................................... 132
Figura 115. Pantalla de capa de Intrusión. .......................................................................................... 132
11
Índice de Tablas
Tabla 1. Diversificación de Piratas Informáticos. ................................................................................. 18
Tabla 2. Diferencias entre IDS / IPS ..................................................................................................... 21
Tabla 3. Ventajas de los IPS / IDS. ....................................................................................................... 23
Tabla 4. Selección de bibliotecas digitales. .......................................................................................... 30
Tabla 5. Criterios de inclusión y exclusión. .......................................................................................... 31
Tabla 6. Implementación de los dispositivos IDPS en los estudios obtenidos. .................................... 33
Tabla 7. Comparación de los dispositivos estudiados por funcionalidad. ............................................ 34
Tabla 8. Amenazas y los Ataques tratados por los IDPS. ..................................................................... 34
Tabla 9. Detalle de la información de los Estudios Primarios, la tabla no contiene los estudios EP1,
EP4, EP5, EP6, EP9 y EP10, ya que estos son estudios introductorios solo sirviendo para obtener el
conocimiento base de los dispositivos. ................................................................................................. 37
Tabla 10. Existen una gran cantidad de comandos que Snort utiliza, los más comunes se describen
dentro de la tabla a manera general. ...................................................................................................... 49
Tabla 11. Claves de planificación y diseño de un estudio de caso. ...................................................... 65
Tabla 12. Redes objeto de Estudio ........................................................................................................ 66
Tabla 13. Consideraciones de la observación. ...................................................................................... 67
Tabla 14. Descripción de las redes de trabajo. ...................................................................................... 69
Tabla 15. Reporte de resultados para la red 01. .................................................................................... 70
Tabla 16. Reporte de resultados para la red 02. .................................................................................... 72
Tabla 17. Productos académicos logrados. ........................................................................................... 75
Tabla 18. Nueva terminología asignada por CISCO a sus productos. ................................................ 101
Tabla 19. *Los 7115 y 7125 utilizan interfaces SFP y no admiten bypass; Estos están diseñados para
despliegues de firewall / conmutador donde no se desee bypass. ** Estos modelos son dispositivos
apilados. .............................................................................................................................................. 102
Tabla 20. Descripción general de los centros de defensa CISCO. ...................................................... 103
Tabla 21. Hay que tener en cuenta que bajo el nuevo modelo de ventas de Cisco, las licencias Protect
y Control normalmente se incluyen con cualquier venta de dispositivos. .......................................... 104
Tabla 22. Descripción del menú CISCO FireSIGHT. ........................................................................ 109
Tabla 23. Elementos centrados en el cuidado y la alimentación de FireSIGHT ................................. 110
Tabla 24. Credenciales por default del dispositivo. ............................................................................ 110
12
Introducción
En el ámbito de la Tecnologías de la Información (TI), las amenazas han evolucionado y se
han diversificado, en este contexto, el desarrollo y el gran crecimiento de las redes impulsaron
nuevas formas para compartir, transferir y distribuir información por medios digitales. Por lo
tanto, la importancia de identificar y detectar el tráfico malicioso permite prevenir
comportamientos anómalos dentro de las redes de diversos tipos.
Los Sistemas de Prevención y Detección de Intrusos (IDPS por sus siglas en inglés) son
dispositivos de próxima generación, que permiten analizar el tráfico en la red con la intención
de prevenir, identificar y detectar posibles paquetes maliciosos o anómalos [1].Por lo tanto, la
propuesta de esta investigación es analizar, probar y comparar un dispositivo IPDS Cisco
Sourcefire series 700 conectado al tráfico en una red WLAN dentro del Centro de Investigación
en Matemáticas Unidad Zacatecas, con la finalidad de obtener y detectar nuevas
funcionalidades para ser trasladados a un desarrollo de software libre, siendo sugeridos como
funciones de detección de vulnerabilidades mediante la generación de alertas al usuario final.
Los resultados esperados de esta línea de trabajo podrían sugerir funciones de seguridad
hacia las nuevas tendencias. La estructura general de la tesis se detalla a continuación:
Capítulo 1. Antecedentes.
En este capítulo se presenta el estado de los sistemas informáticos, así como, la
conceptualización de las amenazas informáticas, diversos mecanismos de prevención y
detección, los cuales permitirán a los sistemas informáticos conocer los intrusos o
amenazas dentro de la red (uno de estos dispositivos son los IPDS). Al Final se presenta
el planteamiento del problema, la hipótesis, objetivo general, objetivos específicos y la
justificación de este trabajo de tesis.
Capítulo 2. Estado del Arte.
En este capítulo se presenta el estado actual de la práctica acerca de los conceptos
principales que se aborda dentro de esta investigación, la obtención de la información se
llevó a cabo mediante una revisión sistemática para el análisis de los dispositivos IDS e
IPS, con el objetivo de obtener de obtener el estado del arte de estos dispositivos.
13
Capítulo 3. Metodología para el desarrollo de la tesis.
En este capítulo se presenta los recursos tecnológicos y los pasos para la propuesta de
trabajo, la propuesta de trabajo como tal para dotar de seguridad a los medios tecnológicos,
la selección de la metodología de análisis de amenazas, así como la propuesta de
implementación del marco de trabajo para un IDPS dentro de la organización.
Capítulo 4. Propuesta.
En este capítulo se presenta el estudio de caso IDPS dentro de una institución educativa,
con un análisis de amenazas realizado a través de una herramienta.
Capítulo 5. Resultados.
En este capítulo se presenta los resultados obtenidos del estudio de caso IDPS mostrando
el análisis de amenazas realizado a través de la herramienta, impacto y posibles
afectaciones como resultado de su utilización.
Capítulo 6. Conclusiones.
Por último, en este capítulo se presentan las conclusiones del estudio de caso de la
investigación, así como el trabajo futuro.
14
Capítulo 1. Antecedentes
En este capítulo se presentan los antecedentes, que contiene la definición de los conceptos
fundamentes a partir de los cuales se desarrolla la presente investigación, posteriormente se
presenta: el planteamiento del problema, los objetivos generales junto a los específicos y la
justificación.
1.1. Tecnologías de la Información y Comunicación
Hoy en día, los seres humanos dependemos cada vez más de la tecnología, nuestro estilo
de vida se ha visto invadido por ella, es este aspecto las organizaciones no han quedado exentas
de ello. En los últimos 15 años, ha aumentado el acceso y la utilización de las TIC
considerablemente, sobre todo en el uso de servicios de telefonía móvil e internet. De acuerdo
a ITU en su Informe sobre Medición de la Sociedad de la Información 2015[3], muestra que la
proporción de la población mundial cubierta por las redes móviles y celulares es ahora de más
del 95 % (Figura 1).
Figura 1. Cambios Principales de las TIC a nivel Mundial, 2000 – 2015
El acceso a las TIC favorece a las oportunidades económicas y sociales. De la misma manera
las personas no tan bien intencionadas, ven la tecnología como una plataforma para cometer
15
acciones ilícitas para obtener beneficios a costa de otros. Los daños por robo o pérdida de
información crecen junto con la dependencia tecnológica, la seguridad de la información cobra
importancia planteando la necesidad de disponer de profesionales en TI capaces de asegurar,
gestionar y mantener los sistemas antes las amenazas que se pudieran presentar.
En este contexto, los países del continente americano, en especial de América del Norte cuentan
con los niveles más elevados de protección en este sentido. A su vez esos niveles son mayores
en los países desarrollados que en los países en desarrollo (Figura 2).
Figura 2. Niveles de ciberseguridad, Índice Mundial de Ciberseguridad 2014.
La ciberseguridad o seguridad de la información da cabida a un creciente número de
elementos y con ello un número creciente de actividades en el que la seguridad de la
información resulta ser un factor crítico de las cuales destacan:
• Banca (Organizaciones financieras).
• Industria privada y pública.
• Instituciones públicas y privadas (Salud, Educación, Administración Estatal y local).
• Empresas de Servicios profesionales (TIC, inmobiliarias, proyectos de ingeniería,
etc.).
• Telecomunicaciones.
• Desarrollo de software.
Con el paso de los años las organizaciones han basado sus actividades de negocio en las
tecnologías de la información y comunicación, debido a esto, nace la necesidad de dotar tanto
a sus sistemas como a su infraestructura informática de políticas y medidas de protección para
garantizar el desarrollo y sustentabilidad de sus actividades de negocio.
16
América Latina se ha vuelto un objetivo cada vez más atractivo para el crimen informático.
La incidencia de ataques a nivel gubernamental, industrial, comercial o personal sigue al alza
en toda la región y para el 2017 se planteaban retos significativos en la materia.
De acuerdo con el periódico el universal, México ocupa el segundo puesto en ataques
cibernéticos en Latinoamérica, donde el sector más afectado es el manufacturero con un 27%
de ellos, en segundo el bancario y el financiero con un 21% cada uno de ellos [2].
Tan solo en el año de 2014, los bancos perdieron aproximadamente 94 millones de dólares
por fraudes en algún tipo de transacción en línea. Se estima que el 90% de los delitos en la web
no se denuncia y un 65% de personas que sufren algún tipo de robo de información no lo
denuncia.
1.1.1. Ciberseguridad en México
México en términos de ciberseguridad está lejos de los estándares mundiales, a nivel global
las estrategias de seguridad para las organizaciones son un requerimiento estándar para el 45%
de las empresas. En México solo un 19% de las organizaciones aplica este tipo de
reglamentaciones, aumentando la probabilidad de sufrir un ataque [CNN ,2014].
Según un estudio de la firma alemana GData, en nuestro país se producen 12 ataques
cibernéticos por cada segundo, de los cuales 60% van dirigidos contra organismos de gobierno,
provenientes de Estados Unidos y Rusia con el fin de obtener información relevante, siguiendo
los del sector privado y por último, las pequeñas y medianas empresas (PyMEs).
En el caso de las PyMEs, el principal objetivo de los atacantes no es el de robar
información o dinero, sino implementar (cómo implementarlos) los equipos y unirlos a una
bootnet, las cuales participan en ataques de negación de servicios (DDOs) [13].
Forbes México hace una lista de los posibles ataques cibernéticos que una persona u
organización podrían sufrir y que, ante esto, deben estar alerta para no sufrir ante esta situación
[Blue Coat Systems, 2015].
• Tráfico encriptado de malware (para evadir la detección).
• Ramsomware (software malicioso que bloquea el escritorio del usuario y exige el
pago de una suma de dinero).
• Software posiblemente no deseado (PUS al descargar aplicaciones gratuitas).
• Redes sociales amenazadas (Recopilación de información).
• Vulnerabilidad al código abierto.
• Software de espionaje o (espionageware software de vigilancia).
1.1.2. Amenazas informáticas
Los actos de vandalismo computacional significan una menor amenaza que una pobre
política de respaldos o un deficiente plan de contingencia.
17
En la actualidad, debido a la creciente afluencia de redes conectadas a internet se pueden
presentar diversos problemas, a continuación, se detallan algunos de los más importantes.
1.1.2.1. Ataques informáticos
Según el NYT (New York Times) un ataque informático es un intento organizado e
intencionado causada por una o más personas para causar daño o problemas a un sistema
informático o red [5]. Los ataques en grupo suelen ser hechos por bandas llamados "piratas
informáticos" que suelen atacar para causar daño, por buenas intenciones, por espionaje, para
ganar dinero, entre otras. Un ataque informático consiste en aprovechar alguna debilidad o falla
(vulnerabilidad) en el software, en el hardware e incluso en las personas que forman parte de
un ambiente informático; a fin de obtener un beneficio, causando un efecto negativo en la
seguridad del sistema, que repercute directamente en los activos de la organización.
La Figura 3 muestra las fases comunes por las que suele pasar un ataque informático al
momento de ser ejecutado.
Figura 3. Fases comunes de un ataque informático
a) Fase 1 - Reconocimiento: involucra la obtención de diversos tipos de información con
respecto a una o potencialmente una víctima entre las cuales pueden estar personas u
organización. Por lo general, durante esta fase se recurre a diferentes recursos de
Internet para recolectar datos del objetivo.
b) Fase 2 - Exploración: en esta segunda etapa se utiliza la información obtenida de la
víctima para estudiar el sistema víctima por él se realizará el ataque, en esta etapa se
obtienen direcciones IP, nombres de host, datos de autenticación, entre otros.
c) Fase 3 - Obtener acceso: en este punto se comienza a materializar el ataque a través de
la explotación de las vulnerabilidades y defectos del sistema descubiertos durante las
fases de reconocimiento y exploración.
d) Fase 4 - Mantener el acceso: una vez que el atacante ha conseguido acceder al sistema,
buscará implantar herramientas que le permitan volver a acceder en un futuro desde
cualquier otro lugar donde tenga acceso a Internet.
18
e) Fase 5 - Borrar huellas: una vez que el atacante ha logrado obtener y mantener el
acceso al sistema, intentará borrar todas las huellas que fue dejando durante la intrusión
para evitar ser detectado por el profesional de seguridad o los administradores de la red.
1.1.2.2. Los Piratas informáticos
De acuerdo con la RAE (Real Academia Española) un “hacker” es un pirata informático,
pero de acuerdo al autor Jeimy J Cano M [4], un hacker es un constructor de manuales de lo
“no documentado”, de la realidad inúmera en las soluciones de informática que aún no se
descubre. Es así que el término “hacker” no es sinónimo de criminal o delito, sino de una
persona que ve más allá de lo establecido por un manual. Es por ello, que en este trabajo no se
manejará el término “hacker” refiriéndose como criminal informático o pirata informático. De
acuerdo con Furnell [5], existen varios tipos de piratas informáticos, se clasificaciones de
acuerdo a las motivaciones que los mueven a actuar en situaciones particulares, esta
clasificación se aprecia en la Tabla 1.
Tabla 1. Diversificación de Piratas Informáticos.
Motivaciones Ciberterroristas Phreakers Script Kiddies Crackers Desarrollador
de Virus Atacante Interno
Reto X X X
Ego X X X
Espionaje X X X
Ideología X
Dinero X X X X
Venganza X X X X
Furnell menciona 5 perfiles: ciberterroristas, phreakers, script kiddies, crackers,
desarrollador de virus. Se agrega adicionalmente un nuevo perfil (Atacante interno) que son
todos aquellos empleados insatisfechos que tratan de hacer daño a la organización.
1.2. Modelo y/o estándares enfocados a la seguridad
informática Objetivos
Es elemental establecer y mantener acciones para poder llevar una adecuada
administración de la seguridad de la información, de esta manera, se deben cumplir con los
requerimientos de mayor importancia ara información:
• Integridad: Aseguramiento para que no se realicen modificaciones por personar no
autorizadas a los datos o procesos, del mismo modo, que no se realicen
modificaciones no autorizadas por personal autorizado a los datos o procesos; y
por último que los datos sean consistentes tanto interna como externamente.
19
• Disponibilidad: Aseguramiento de los accesos de manera confiable y de manera
oportuna a los datos o recursos para el personal apropiado.
• Confidencialidad: Prevenir el acceso no autorizado en forma intencional o no
intencional a la información. La falta de confidencialidad puede ocurrir mediante
la publicación intencional de información confidencial de la organización.
Dentro de las estrategias de Seguridad informática las organizaciones deben optar por
algún modelo o estándar de seguridad informática, entre las cuales destacan:
• COBIT (Control Objectives for Information and related Technologies): Marco
aceptado internacionalmente como buena práctica para el control de la información
y los riesgos que con ellos conllevan las TI; Su principal función es la gestión de
las tecnología TI de un manera conveniente para garantizar un éxito a los múltiples
recursos del entorno.
• ITIL (Information Technology Infrastructure Library): Conjunto de conceptos y
buenas practicas escritas por profesionales de TI para la gestión de servicios de
información, desarrollo y operaciones que se deben llevar a cabo para gestionar
adecuadamente los procesos.
• La series ISO (International Organization for Standardization) / IEC
(International Electro-technical Commission) 27000: Conjunto de estándares
desarrollados que proporcionan un marco de gestión de la seguridad de la
información utilizable por cualquier tipo de organización ya sea pública o privada
sin importar si su tamaño es grande o pequeño.
Existen otros estándares relacionados con la seguridad de la información, pero estos son
los de mayor transcendencia internacional [5].
1.3. Gestión de Riesgos
Dentro las estrategias de seguridad de la información una de las principales a considerar
es la Gestión de riesgos. Un proceso de gestión de riesgos puede actuar como punto de arranque
y puede adaptarse a las necesidades específicas de toda organización. El proceso de gestión de
riesgos implica identificar dónde una organización puede tener compromisos, las
consecuencias que implican esos compromisos y formas para reducir la probabilidad o
severidad de los compromisos [28]. Los conceptos claves dentro de la gestión de riesgos son
los siguientes:
• Activo: Son las cosas de la organización que se pretende proteger.
• Vulnerabilidades: Son formas en que los activos pueden ser comprometidos.
20
• Amenazas: Son la forma en que las vulnerabilidades pueden ser explotadas para
causar daños en el activo.
• Riesgos: Identifica y evalúa los riesgos. Se trata de una combinación de amenazas
que cuenta el activo con las vulnerabilidades encontradas en él.
• Tratamiento de riesgos: Existen varias maneras de manejar los riesgos, a
continuación, se describen las principales cuatro:
o La primera es evitar el riesgo mediante la eliminación de la vulnerabilidad o
amenaza.
o La segunda manera de manejar el riesgo es “mitigar” el riesgo reduciendo la
probabilidad de ocurrencia o el impacto cuando una amenaza se ve
materializada en un activo.
o La tercera forma es compartir el riesgo mediante la inclusión de un tercero,
como por ejemplo una compañía de seguros, que compensará a la
organización en caso de que se produzca el riesgo.
o La cuarta forma de manejar el riesgo es “retener” el riesgo, cuando la
organización simplemente acepta la posibilidad de que se pueda producir el
riesgo.
Existen metodologías enfocadas a la gestión de riesgos como por ejemplo OCTAVE [27],
EBIOS [28] y MAGERIT [29], estas metodologías no son análisis en el trabajo en cuestión.
1.4. IDPS (Sistemas de Detención y Prevención de Intrusos)
Dentro de la seguridad informática una de las principales preocupaciones es la prevención
de ataques a redes de computadoras. Existen diversos tipos de mecanismo de prevención y
detección, como por ejemplo el control de acceso, cifrado y autenticación, los cuales protegen
a los sistemas de intrusos o de posibles amenazas que pudieran aparecer en la red.
1.4.1. Definiciones
El termino IDPS se refiere a la herramienta de seguridad física (hardware) o lógica
(Software) encargada de monitorear el tráfico en la red, en busca de intentos de intrusión,
permitiendo establecer reglas para manejar acciones responsivas a los ataques detectados o
intrusiones realizadas, y así bloquear el tráfico en tiempo real o incluso eliminar estas
actividades sospechosas. El mejor ejemplo [1] para entender un IDPS es comparándolo en el
mundo real con una patrulla de policía, realizando actividades de vigilancia activa buscando
situaciones anormales, y en ciertos contextos operando como guardia de seguridad, permitiendo
o negando el acceso basado en credenciales, reglas predefinidas y políticas de seguridad,
trabajando en conjunto con la patrulla y cada uno proporcionando sus propios controles. A
21
continuación, en la Tabla 2, se presentan las diferencias más importantes entre un IPS y un IDS
[1] – [3].
Tabla 2. Diferencias entre IDS / IPS
IDS IPS
Solo previene los ataques, intrusiones o actividades
maliciosas en la red.
Detecta los ataques, intrusiones o actividades maliciosas en
la red. Genera alertas (No resuelve) de los ataques detectados o de
los ataques ya realizados.
Maneja acciones responsivas de los ataques detectados o
intrusiones.
Identifica a los intrusos. Monitorea en tiempo real los paquetes en la red.
Preserva los log en caso incidentes criminales. Genera alertas y puede eliminar las actividades sospechosas.
- Bloquear el tráfico en tiempo real.
- Detiene un taque en progreso.
1.4.1. Clasificaciones
Existen diversas formas de clasificación de un IDPS [1], [2], [5] – [8], las más relevantes
son:
• Basados en Red (NIDS and NIPS). - El mayor número está configurado de esta
manera, detectando, capturando, analizando e informando de los paquetes o ataques
que se producen en la red. (ver Figura. 4).
Figura 4. IDS/ IPS basados en red.
• Basados en Host (HIDPS). - Fue el primer tipo desarrollado, generalmente
instalados en puntos finales de la red, operando sobre la información recogida y
generada dentro de un ordenador, analizando con gran precisión procesos y usuarios
involucrados, mostrando resultados de ataques, accesos y procesos de cada host (ver
Figura. 5).
22
Figura 5. IDS/IPS basados en host.
1.4.1. Implementaciones
Dentro del modo de desplegar su funcionamiento se identifican 2 formas de
implementación:
• Modo en Línea (In-Line). – Utilizados directamente en el flujo de tráfico de la red, de
esta manera los paquetes son analizados detectando posibles ataques, previniendo
ataques incluso antes de que lleguen a su destino. Esta forma de operación permite que,
si por cualquier circunstancia el dispositivo falla, el tráfico que pasa por él será detenido
(ver Figura 6).
Figura 6. Modo In-line.
• Modo SPAN (Promiscuos / Passive Mode)- Aquí el dispositivo es colocado en medio
de la trayectoria del tráfico, previniendo que el primer paquete de un posible ataque
llegue a su objetivo final, generando alarmas y tomando acciones, sin embargo, en este
modo no puede modificar el tráfico a medida que viaja hacia el destino. De esta manera
si el dispositivo falla, el tráfico no es detenido en puntos finales de la red (ver Figura
7).
23
Figura 7. Modo SPAN.
1.4.1. Ventajas y Desventajas
Tanto los IPS como IDS son dispositivos que han ganado aceptación durante los últimos
años debido a que son pieza fundamental en la infraestructura de las organizaciones.
En la Tabla 3 muestra las ventajas y desventajas de los IDPS dependiendo de la forma en la
que se encuentre operando:
Tabla 3. Ventajas de los IPS / IDS.
IPDS Modo de Operación
IDS IPS
Ventajas
Analizan el tráfico de red para identificar posibles paquetes.
Protección preventiva antes de que ocurra el
ataque.
Son un mecanismo pasivo de detección, ya que su tarea fundamental es alertar pero no actuar.
Defensa tanto de Sistema Operativo, Puertos,
Tráfico de IP, códigos maliciosos e intrusos.
Se basa en detectar tráfico malicioso mediante firmas o anomalías.
Actúa bajo demanda según las alertas detectadas.
Tienen capacidades de firewall.
Desventajas
Falsos negativos (no todos los eventos que llegan a presentarse en la red son alertados).
Falsos positivos (Todos los eventos levantados como alertas pero que en realidad no se trataban de tráfico malicioso)
Falsos positivos Son Inmaduros.
Podría representar una auto-negación de servicio o
problema general con la red, pues de manera
automática, aplicaría las reglas en su firewall
interno para poder mitigar “el ataque”.
1.4.1. Alertas
La Figura 8 muestra los distintos tipos de alarmas desplegadas por los dispositivos
IDPS:
24
Figura 8. Alertas en los IDS / IPS.
1.5. Planteamiento del problema
El activo más importante dentro de cualquier organización es la información, un estudio de
la firma Symantec descubrió más de 430 millones de nuevas amenazas en 2015, 36% más en
relación al año anterior [5]. De acuerdo con CISCO para el año 2020 existirá más de 50 millones
de “Smart Objects” conectados en algún punto a la red, esto ha obligado a las organizaciones a
implementar nuevas políticas, dentro de las cuales Bring Your Own Device (BYOD) es una
tendencia cada vez más generalizada donde las organizaciones permiten a los trabajadores
llevar sus dispositivos personales para llevar a cabo tareas del trabajo y conectarse a la red y
recursos corporativos. Aunado a lo anterior, de acuerdo a Karpesky Lab la mayoría de los
ataques a móviles fueron registrados en Brasil, seguido por México y Colombia [5]. El robo o
fuga de información a través del correo electrónico es el rubro más vulnerable para las
empresas, con 19.2%, de acuerdo con un estudio de la consultora Deloitte México [36]. En
segundo lugar, está el robo de información vía dispositivos de memoria portátil y/o móviles,
con 13.6%, seguido del robo o pérdida de laptops, tabletas y celulares con 12.8%. CISCO
menciona que dentro de la seguridad de la información los Firewalls son las herramientas más
utilizadas por las organizaciones (65%), seguido por la prevención de pérdida de datos (56%)
y herramientas de autenticación (53%).
1.6. Hipótesis
La creación / desarrollo de una aplicación de manera nativa /web diseñada en un nuevo
enfoque para la detección y evaluación de vulnerabilidades de seguridad de nuestras reglas,
Verdaderos Positivos
•Ataques Verdaderos•Alarmas Generadas
Falso Positivo
•Sin Ataque•Alarmas Generadas
Verdaderos Negativos
•No Alarmas•Sin Ataque
Falsos Negativos
•Sin Alarmas•Con Ataques
25
puede disminuir de manera considerable los riesgos a través de una serie de actividades y
configuraciones seguridades tomadas u obtenidas de un IDPS CISCO SourceFire 700 e
implantadas en estos dispositivos. La implementación del enfoque propuesto ayudará a los
usuarios de las tecnologías de la información y la comunicación en la mejor comprensión de
los riesgos reales a los que están expuestos, facilitando la mitigación de vulnerabilidades de
seguridad.
1.7. Objetivos
El objetivo general y los objetivos específicos para el desarrollo del presente trabajo de
investigación se muestran a continuación:
1.7.1. Objetivo General
I. Analizar, Observar y Comparar IPDS de Software Libre (Snort, Bro, Suricata) vs IPDS
Licenciados (Cisco SourceFire 700).
1.7.2. Objetivos específicos
II. Implementar en una red desmilitarizada un IPDS CISCO Sourcefire 700 para análisis
de vulnerabilidades en las WLAN.
III. Analizar Eficientemente el tráfico para detectar y prevenir MAC (Malicious Access
Point).
IV. Trasladar funcionalidad de IPDS licenciado a módulos desarrollados con licencia
GNU.
V. Definir un esquema descentralizado y virtualizado sobre la nube para tener
funcionalidad es de manera independiente.
VI. Proponer el desarrollo de apps para dispositivos (Smartphones, IoT, Smart Cities, etc.)
por medio de alertas de seguridad al acceder a una WLAN.
VII. Proponer aplicaciones de manera nativas para dispositivos (Smartphones, IoT, Smart
Cities, etc.) de alertas de seguridad al acceder a una WLAN.
1.8. Justificación
La historia de IDPS Cisco Sourcefire es basada en Snort (el cual es un IDPS de software
libre), en el año 2013 cisco adquirió Sourcefire lo cuál le permitió incorporar en el año 2014 el
producto en su línea de negocio, con esto Cisco pone un nuevo estándar para la protección
26
avanzada de amenazas integrando el monitoreo en tiempo real, la automatización de la
seguridad inteligente y mejorando el performance permitiendo direccionar un ataque antes ,
durante y después de su ejecución, CISCO cuenta con más del 50% de mercado en el mundo
de las redes y de la ciberseguridad [1]-[3]. Esta solución ofrece una visión a los dispositivos
conectados en la red de forma inteligente, es altamente personalizable a las necesidades
específicas de los diferentes usuarios y su plataforma de gestión está llena de características y
la compresión de estas características es crucial para cumplir con la función de la prevención
de ataques.
27
Capítulo 2. Estado del arte
En este capítulo se presentan los resultados del método de la revisión sistemática de la literatura
cuyo objetivo es obtener el estado del arte respecto al alcance de la aplicación de los IDPS,
orientándose en tres aspectos principales: 1) marcos de trabajo, métodos y metodologías, 2)
como se están implementando en las diferentes áreas de TI, 3) diferencias existentes entre los
dispositivos IDS/IPS vs los Firewall y cómo estos son sustituidos por los dispositivos de nueva
generación (Next Generation Intrusion Prevention System / NGIPS). En la segunda parte del
capítulo se analizan los trabajos con mayor similitud al desarrollado en la presente
investigación. Este capítulo incluye también la selección de tecnología y la selección de la
metodología para el desarrollo de la herramienta.
2.1. Revisión Sistemática de la Literatura.
La Revisión Sistemática de la Literatura (Systematic Literature Review, por sus siglas en
inglés SLR) es un método en el cual identificamos, analizamos, evaluamos e interpretamos toda
la evidencia disponible relevante a un tema o pregunta de investigación (creado por
Kitchenham y Charters) [10]. El principal objetivo de llevarla a cabo es la obtención de la
información relevante de un tema específico mediante un método formal.
La SLR reduce la posibilidad de sesgo en las búsquedas de estudios, ya que es necesario
definir un protocolo que especifica los métodos utilizados para guiar la revisión sistemática
(Selleri Silva et al., 2015).
La revisión sistemática se constituye de tres fases principales: planificación de la revisión,
ejecución de la revisión, y reporte de resultados. A continuación, se detallan las actividades
realizadas en cada fase.
• Planificación de la revisión: Durante esta fase se enumeran los objetivos de
investigación y se define un protocolo de revisión. Dicho protocolo especifica la
28
pregunta central de la investigación y de los métodos que se utilizan para la ejecutar la
revisión.
• Ejecución de la revisión: Esta fase implica identificar los estudios primarios, selección
y evaluación de acuerdo con los criterios de inclusión y exclusión establecidos en el
protocolo de la revisión.
• Reporte de los resultados de la revisión: Durante esta fase los datos de los artículos
se pueden extraer y sintetizar.
2.1.1. Planificación de la RLS
La planificación es la primera fase de la RSL, comprende las siguientes actividades:
confirmar la necesidad de la revisión, especificar las preguntas de investigación, enumerar las
fuentes de datos para realizar las búsquedas y, formular las cadenas de búsqueda. La necesidad
de una RSL surge a través de los investigadores en el proceso por resumir toda la información
existente sobre algún tema de investigación de manera exhaustiva e imparcial. Esto con el fin
de obtener conclusiones más exactas sobre el tema, esto es posible a partir de estudios
individuales, o pueden llevarse a cabo otras actividades de investigación.
2.1.1.1. Identificación de la necesidad de la RLS
Se identificó la necesidad para realizar esta revisión debido a que el uso de los IDS es cada
vez más importante y se quiere conocer sus principales características y como estas ayudan a
prevenir los posibles ataques a través de nuestra red, sin embargo, estas características cuentan
con una amplia variedad de funcionalidades, las cuales no son de fácil acceso para los
administradores de red. Estos factores intervienen en el comportamiento y desempeño de un
equipo dentro y amplían las vulnerabilidades dentro la misma.
2.1.1.2. Preguntas de investigación
La especificación de las preguntas de investigación es la parte más importante de la revisión
sistemática, ya que estas identifican los estudios primarios, direccionan la extracción de los
datos, y marcan la manera en que estos deben ser sintetizados, de manera que las preguntas de
investigación puedan ser respondidas. De manera general se pueden identificar 5 aspectos clave
que guiaron esta revisión:
• Evaluar el efecto de tecnología (entendiendo por esto Hardware/Software) de los IDPS.
• Evaluar la frecuencia o velocidad de un factor de desarrollo del proyecto, tales como la
adopción de una tecnología IDPS de forma Lógica o la frecuencia o tasa de éxito o
fracaso del proyecto.
29
• La identificación de costos y factores de riesgo asociados con una tecnología IDPS.
• Identificar el impacto de las tecnologías en los modelos de fiabilidad, rendimiento y
costo.
• Analizar de la viabilidad de emplear tecnologías de desarrollo de software específico o
aplicaciones de software.
No obstante, esta clasificación no marca una pauta a seguir, depende principalmente del
interés de los investigadores identificando futuras actividades del alcance de la investigación.
A continuación, se presentan las preguntas de investigación:
• ¿Cuál es el alcance de la aplicación de los IDPS?
• ¿Cómo se están implementando en las diferentes áreas de las TI?
• ¿Cuál es la diferencia de los dispositivos IDPS vs Firewall, y cómo estos son sustituidos
por los dispositivos de nueva generación?
A partir de la definición de las preguntas de investigación, se definieron las palabras claves
de investigación las cuales son: 1) Seguridad, 2) Amenazas, 3) Sistema de Prevención de
Intrusos (IPS), 4) Sistema de Detención de Intrusos (IDS), 5) Redes, 6) Defensa digital.
2.1.1.3. Cadenas de búsqueda
La necesidad de encontrar los estudios primarios relacionados con las preguntas de
investigación es un factor que distingue a las revisiones sistemáticas de las revisiones
tradicionales. Se logra determinando y siguiendo una estrategia de búsqueda. Todo ello debería
hacerse con ayuda de las bibliotecas u otras personas con experiencia relevante. Las cadenas
de búsqueda son identificaciones de las RSL existentes donde se evalúan el volumen de los
estudios potencialmente relevantes, como la realización de búsquedas de ensayos utilizando
diferentes combinaciones de términos de búsqueda derivados de la pregunta de investigación,
artículos o consultas con expertos en la materia.
Ejemplos de ellas se muestra a continuación donde la combinación de los operadores lógicos
AND y OR, dando como resultado:
• Intrusion Prevention Systems (IPS) OR Intrusion Detection Systems (IDS);
• Intrusion Prevention Systems (IPS) OR Intrusion Detection Systems (IDS) AND
Security AND Networks AND Malware OR Threads.
2.1.1.4. Fuentes para la extracción de la información
Dentro de una investigación uno de los factores más importante es encontrar la mayor
cantidad de información referente al tema que se esté investigando, con el objetivo de sustentar
la investigación y obtener información que nos ayude a llevar a cabo la investigación.
30
En referencia a las fuentes para la extracción de la información existen dos grandes
categorías, las fuente formales y las fuentes informales, dentro de la fuente informales se
encuentran todas es página web que nos ofrecen información que únicamente es escrita por un
autor sin tener que pasar por un procesos de selección y corrección, mientras que en la fuentes
formales se encuentran todas las bibliotecas electrónicas, libros y páginas que de algunas forma
pasan por un proceso de revisión y corrección rígido. De manera general tiene dos funciones
principales:
• Definir el acceso a los repositorios de datos para obtener la información.
• Declarar las líneas base que usaran para la selección de fuentes de datos primarios y
secundarios.
En la actualidad se seleccionan fuentes formales constituidas por bibliotecas digitales, las
cuales contienen artículos relacionados a ciertas áreas de investigación, para el desarrollo de
esta tesis se seleccionaron aquellas consideradas importantes en el campo de la ingeniería de
software, entre las cuales sobresalen las siguientes fuentes que se muestra la tabla 4:
Tabla 4. Selección de bibliotecas digitales.
Fuente URL
ACM http://dl.acm.org/advsearch.cfm
EEE http://ieeexplore.ieee.org/search/advsearch.jsp?expression-
builder
SpringerLink http://www.sciencedirect.com/
otros recursos electrónicos oficiales (CISCO, SNORT…) Sitios Web Oficiales, Documentación oficial y libros.
2.1.1. Ejecución de la revisión sistemática
La segunda fase de la SLR es la ejecución de la revisión, en la cual se definen los criterios
de inclusión y exclusión para seleccionar los estudios primarios. Se muestra el proceso de
selección de estudios primarios y el número de estudios encontrados en cada paso del proceso.
Por último, se muestra la plantilla para extracción de datos de los estudios primarios.
2.1.1.1. Criterios de inclusión y exclusión
La Tabla 5, muestra los criterios de inclusión y de exclusión utilizados durante la durante la
RSL:
31
Tabla 5. Criterios de inclusión y exclusión.
Criterios de inclusión Criterios de exclusión
Estudios en idioma español e inglés. Estudios que no estén en los idiomas español e inglés.
Estudios dentro del periodo comprendido 2005 al 2017. Estudios que no estén dentro del periodo indicado.
Estudios con contengan en su título las palabras clave. Estudios que no contengan información relevante del
tema. Estudios que contengan información sobre el uso de
IPS / IDS. Sitios webs no oficiales
Estudios que sean de revistas indexadas, congresos internacionales y JRCS.
Información de las páginas web de sitios oficiales.
2.1.1.1. Selección de estudios primarios
La Figura 9 muestra la ejecución de los pasos descritos anteriormente para la obtención de
los artículos primarios.
Figura 9. Selección de estudios primarios.
2.1.1.1. Extracción de Datos
La clasificación de las áreas se llevó a cabo por medio de una plantilla en una hoja de cálculo
conteniendo los siguientes datos: fuente, título, autor, año, objetivo, introducción, definición,
tipos de dispositivos, amenazas, retos, tipo de ataque, y propuesta. La Tabla 6, muestra un
resumen de los Estudios Primarios (EP), resultado de la RSL. La siguiente sección muestra el
análisis de los resultados encontrados.
32
Figura 10. Estudios Primarios Seleccionados en la RSL.
2.1.1. Reporte de Resultados
En esta sección, el objetivo principal es responder las diversas preguntas de investigación,
el análisis de los resultados obtenidos permitió identificar las diversas áreas de interés que son
estudiadas, su clasificación y la forma en las que se están aplicando, (Dentro de la sección
trabajos relacionados, se encuentra con mayor detalle la implementación, áreas de
investigación, entorno, amenazas y tipos de ataques que se analizan en los Estudios Primarios
- EP).
2.1.1.1. Alcance de la aplicación de los IDPS
Para la clasificación de las áreas se diseñó una plantilla en una hoja de cálculo, conteniendo
los siguientes datos: fuente, título, autor, año, objetivo, introducción, definición, tipos de
dispositivos, preocupaciones (concerns), amenazas, retos, tipo de ataque, contramedida
(countermeasure) y propuesta. Después de la extracción se distribuyeron los estudios
primarios abarcando su clasificación y aplicación las cuales se pueden apreciar en la Tabla 6.
ID Nombre del Estudio
EP1 Difference Between Intrusion Detection System (IDS) and Intrusion Prevention System (IPS).
EP2 D_DIPS: An Intrusion Prevention System for Database Security. EP3 CIPS: Coordinated Intrusion Prevention System? EP4 Funciones y Configuración de la Detección de la Amenaza ASA. EP5 Intrusion Detection Systems with Snort.
EP6 A Design for Building an IPS Using Open Source Products. EP7 BSnort IPS. EP8 Intrusion Detection System in Cloud Computing Environment EP9 Towards effective Client-Server based Advent Intrusion Prevention system for WLAN. EP10 Guidelines for performing Systematic Literature Reviews in Software Engineering.
EP11 Benefits of the Virtualization Technologies with Intrusion Detection and Prevention Systems. EP12 Intrusion Detection System in Cloud Computing Environment. EP13 Wireless LAN Intrusion Detection and Prevention System for Malicious Access Point.
EP14 Virtual Inline-A Technique of Combining IDS and IPS Together in Response Intrusion. EP15 Network-Wide Deployment of Intrusion Detection and Prevention Systems. EP16 Study of Snort-Based IDS. EP17 Intrusion Detection Using Text Processing Techniques - A Recent survey. EP18 Flexible Network-based Intrusion Detection and Prevention System on Software-defined Networks.
EP19 rfc-editor.org_rfc_rfc3882 EP20 Towards Application with Vulnerabilities Signatures for IDS/IPS. EP21 Coping with Denial-of-Service Attacks on the IP Telephony System. EP22 Intrusion Detection System Modeling Based on Neural Networks and Fuzzy Logic. EP23 Comprehensive Analysis of Man in the Middle Attack and Propose Statistical Detection Approach
EP24 Automated Intrusion Response Decision Based on the Analytic Hierarchy Process. EP25 Effectiveness of Intrusion Prevention Systems (IPS) in Fast Networks. EP26 Evaluating the Effectiveness of an Intrusion Prevention – Honeypot. EP27 Wireless LAN IDS(WLIDS) for Malicious Access Point EP28 Performance Analysis of Intrusion Prevention System on Cyber Security for Voice Over Internet
33
Tabla 6. Implementación de los dispositivos IDPS en los estudios obtenidos.
Área Clasificación Aplicación
El análisis de tráfico
Analísis profundo de paquetes, Programación de Reglas,
Base de Datos y Análisis de Texto (EP3, EP21, EP23, EP25, EP26).
Dentro de las Base de Datos
(BD), Ficheros (LOGs) y Reglas de los IDPS.
Marcos de Trabajo
Tecnicas de Configuración fundamentales para
defenderse contra amenazas a gran escala, Arquitectura (EP3, EP21, EP23, EP25, EP26, EP7, EP14, EP16,
EP19).
Arquitectura de Redes, Configuración IDPS
Redes
Alámbricas e Inalámbricas, MAN, WLAN, Cloud,
Virtualización, enfoques a los problemas de seguridad,
técnicas de virtualización, configuración del IDPS (EP7, EP14, EP16, EP19, EP8, EP13, EP15, EP18, EP27, EP11,
EP12).
Redes LAN, MAN, WLAN,
LI-FI, Virtualización
Dentro de la Tabla 6, se observa de manera general que existen diversificaciones en la
implementación de los dispositivos IDPS en los estudios obtenidos a partir de la RSL,
contestando la primera pregunta de la investigación. Cabe resaltar que los estudios EP1, EP4,
EP5, EP6, EP9, EP10, fueron tomados como estudios introductorios para obtener el
conocimiento base de los dispositivos IDPS.
Por otro lado, de la misma manera se contesta la pregunta 2, además se observa dentro de la
extracción de conocimiento que el modo de implementación IN-LINE es el más utilizado, ya
que además de ofrecer las características que se ofrecen en el modo PASSIVE (EP1, EP2, EP5,
EP6, EP8, EP9, EP14, EP16, EP18, EP20, EP21, EP22, EP23, EP24, EP26), proporcionando
una protección adicional a los ataques de forma activa que es el permitir bloquear los ataques
en tiempo como la muestra la Figura 10.
Figura 11. IDPS en modo de implementación In-Line.
La Tabla 7 da un mejor detalle de la comparación de los dispositivos estudiados (Firewall vs
IPDS) basándonos en su funcionalidad obtenida en los estudios primarios EP1, EP3, EP5,
EP6, EP8, EP9, EP11, EP14, EP15, EP16, EP18, EP20, EP21, EP22, EP23, EP24, EP25,
EP26, EP28).
34
Tabla 7. Comparación de los dispositivos estudiados por funcionalidad.
Funcionalidad Firewall IPS IDS
Manejo de Reglas x x
Manejo de Puertos x x x
Filtrado de Datos HTTPS x
Filtrado URL x x x
Control de Aplicaciones Web x x
Prevención de Intrusos x x x
Mensajes de Alarma x x
Escaneo tráfico x x x
Cóntrol de Acceso x
Protección vs ataques DDoS x x
Naturaleza Activo x x
Naturaleza Pasiva x
Inspección de Paqetes x x
Asimismo, se puede observar que los dispositivos IDPS incluyen las funcionalidades (EP1,
EP3, EP5, EP6,EP8, EP9, EP11, EP14, EP15, EP16, EP18, EP20, EP21, EP22, EP23, EP24,
EP25, EP26, EP28 ) que se encuentra dentro de los firewall ( permitir y bloquear el tráfico por
las reglas de puerto / protocolo), agregando nuevas funcionalidades como las de observar el
contenido de los paquetes para determinar si un ataque está ocurriendo en tiempo real y de esta
manera tomar acciones de acuerdo a su modo de implementación (IN-LINE / PASSIVE). La
Tabla 8 muestra las amenazas y los ataques obtenidos en los estudios primarios no importando
el orden en el que aparecen:
Tabla 8. Amenazas y los Ataques tratados por los IDPS.
Amenazas Ataques
MALWARES (software que opera de una manera
maliciosa o indeseable). MITM (the Man in the Middle).
DENEGACIÓN DEL SERVICIO (Los ataques a
menudo realizan inundaciones y/o buscan fallas por
explotaciones).
DOS (ataques por inundación,) y su derivado DDOS (distribuidos).
TRATAMIENTO DE FIRMAS (minería de datos
para predicción de cualquier posibilidad de intrusión*).
EXPLOITS (fragmento de software, de datos o
secuencia de comandos para realizar acciones aprovechando una vulnerabilidad).
TÉCNICAS DE EXPLOTACIÓN (tráfico de red,
SO, software).
ATAQUES DE PENETRACIÓN (acceder a los recursos
del Sistema).
VULNERABILIDADES (Puntos débiles aprovechados por atacantes con la intención de
causar algun tipo de daño, pueden ser conocidas y no
conocidas).
En cuanto a tipo de amenazas para aprovechar debilidades en el software, hardware o incluso
en las personas para obtener algún beneficio (EP2, EP5, EP6, EP8, EP9, EP10, EP11, EP13,
EP14, EP16, EP17, EP20, EP21, EP22, EP23, EP24, EP26, EP27), encontramos los siguientes:
35
• VULNERABILIDADES (conocidas y no conocidas).
• MALWARES (software diseñado para operar de una manera maliciosa o indeseable.)
• DENEGACIÒN DEL SERVICIO (Los ataques a menudo realizan inundaciones y o
buscan fallas por explotaciones).
• TRATAMIENTO DE FIRMAS (se detectan generalmente mediante la minería de datos
con base de conocimientos ya pre configurado y la predicción de cualquier posibilidad
de intrusión “falsos positivos /falsos negativos”).
• TÉCNICAS DE EXPLORACIÓN (el atacante puede obtener información de topología,
tráfico de red, sistema operativo, software de servidor en ejecución, los números de
versión de software, etc.).
De la misma manera los tipos de ataques más analizados dentro de los estudios primarios
son:
• MITM (The Man in the Middle attack donde el atacante se inserta entre dos partes,
haciéndose pasar por las mismas y obteniendo información de ambas).
• DOS (los ataques por inundación causan que un servicio o recurso sea inaccesible a los
usuarios legítimos) y su derivado DDOS (La diferencia está en que este ataque es
distribuido)
• EXPLOITS (programa o técnica que explota una vulnerabilidad en otro software) así
como MALWARES (adware, backdoor, dialer, key logger, spyware, rootkit, Trojan,
URL injection, virus, worm).
• ATAQUES DE PENETRACIÓN (dan al atacante la posibilidad de acceder a los recursos
del sistema, privilegios o datos).
2.2. Trabajos relacionados
En esta sección se presentan los trabajos relacionados con la presente investigación, los
cuales se tomarán como base para la realización de la propuesta del presente trabajo de
investigación.
Los autores (Smith, Durkin, & Tan, 2006) en su trabajo A Design for Building an IPS
Using Open Source Products proponen un IPS (Sistema de Prevención de Intrusiones). En este
trabajo se describe el diseño para un IPS construido a partir de todos los productos de código
abierto y se basa en la investigación realizada en el Illinois.
Aunque la detección de la amenaza no sea un substituto para una solución dedicada
IDS/IPS. Los objetivos de este diseño eran desarrollar un sistema que monitoreara todo el
tráfico de la red del campus, registrara cualquier ocurrencia de paquetes que contengan firmas
de actividad maliciosa y protegería los servidores del campus de un ataque interno o externo
en tiempo real. Este diseño y su implementación exitosa han demostrado que se puede crear un
IPS efectivo sin incurrir en ninguna licencia de software o cuotas de mantenimiento.
36
El diseño descrito en este documento es adecuado para redes pequeñas y medianas y
proporcionará protección para hosts Linux que ejecuten IPTables, pero podría modificarse
fácilmente para adaptarse a implementaciones específicas. Además, el diseño puede escalar
para soportar entornos de red más complejos mediante la adición de sistemas IDS/IPS
distribuidos adicionales.
Por otra parte, los autores (Vanjale, Amne, & V.Patil, 2015) en su trabajo: Wireless LAN
Intrusion Detection and Prevention System for Malicious Access Point, consideran el problema
de los ataques "maliciosos" en redes de Área Local Inalámbricas (WLAN). Mientras que los
usuarios (especialmente los usuarios de teléfonos inteligentes) pueden acceder a conexiones
inalámbricas Wi-Fi públicas más fácilmente, se vuelven más vulnerables al fraude y al robo de
identidad, denominados ataques maliciosos.
Malicioso es un término para un punto de acceso inalámbrico Wi-Fi (Malicious Access
Point) que parece ser legítimo ofrecido en las instalaciones, pero en realidad ha sido creado por
un hacker para escuchar las comunicaciones inalámbricas entre los internautas. Un ataque
malicioso es esencialmente un phishing. Los autores proponen crear una la lista blanca que
contiene los clientes autorizados, comparando su dirección IP, SSID y la dirección MAC para
después descubrir la Puntos de Acceso (AP / Access Point) o clientes autorizados.
Los autores (Kumar, Mangathayaru, & V Narasimha, 2015) en su trabajo: Intrusion
Detection Using Text Processing Techniques - A Recent Survey, consideran el enfoque de
detección de intrusos mediante el procesamiento de texto, este tema ha sido uno de los más
importantes de investigación entre los investigadores que trabajan en el área de la red y la
información de seguridad. La contribución a la investigación es la construcción de un IDPS,
usando técnicas de minería de datos, con el fin de detectar amenazas. Monitoriza todo el tráfico
entrante y restringe la entrada de un intento no autorizado para proteger los recursos mediante
la aplicación de normas adecuadas.
Además, el enfoque propuesto se basa en el concepto de tratamiento de texto y el uso de
técnicas de minería de datos en la predicción y la clasificación de intrusión. La detección de
intrusiones se basa en las llamadas al sistema. Formalmente, tratan el algoritmo como una
función de las llamadas al sistema. En este enfoque para la detección de intrusiones, las
llamadas al sistema sirven como una fuente importante para la minería y la predicción de
cualquier posibilidad de intrusión. Cuando una aplicación se ejecuta, puede haber varias
llamadas al sistema que se inician en el fondo, estas llamadas al sistema son la base y el factor
decisivo para la detección de intrusos.
De acuerdo a los autores (An Le, Dinh,Hoa Le & V Cuong Tran, 2015) en su trabajo:
Flexible Network-based Intrusion Detection and Prevention System on Software-defined
Networks, consideran la creación de redes definidas por software (SDN) ya que estas ha
generado recientemente un considerable interés entre los investigadores como una arquitectura
37
de red de próxima generación que puede superar las limitaciones de la red tradicional, En este
trabajo, se propone un IDPS basado en red que dependen del enfoque SDN y llevan a cabo
algunos experimentos típicos para evaluar su desempeño contra la denegación de servicio y el
ataque de la sonda. El enfoque puede reducir el costo de hardware y software especializado
requerido en el tradicional IDPS mientras se mantiene el mismo rendimiento. También
exploraron algunas ventajas de la arquitectura SDN para minimizar el tráfico de sobrecarga
perjudicial y que la tarea del administrador de red sea más simple a través de un controlador
centralizado.
2.2.1. Comparativa de propuestas
A continuación, en la Tabla 9 se muestra una comparativa de las propuestas mostradas
anteriormente, incluyendo la problemática, la propuesta y los resultados.
Tabla 9. Detalle de la información de los Estudios Primarios, la tabla no contiene los estudios
EP1, EP4, EP5, EP6, EP9 y EP10, ya que estos son estudios introductorios solo sirviendo para
obtener el conocimiento base de los dispositivos.
EP Objetivo Aplicación / Áreas
Investigación Amenazas Ataques
EP2
Muestra un prototipo, diseño e implementación
de un Database intrusion prevention system
(D_DIPS).
Base de Datos.
Detectar, Autenticaciones no
deseadas, Control de Acesso
y Control de Inferencia.
Transacciones maliciosas.
EP3
Presentar el diseño e impleentación de un
Coordinated Intrusion Prevention System
(CIPS).
Seguridad de Redes a gran
escala.
Ataques convencionales,
Virus en Mails, Contenido
Malicioso.
Ataques dirigidos (DoS ,
DDoS), ataques FTP, Ataques
WEB
EP7
El objetivo de la investigación fue desarrollar
un diseño para un BSnort IPS (Better Snort) en
PyMES.
Seguridad de Redes
Ataques convencionales,
Virus en Mails, Contenido
Malicioso
Ataques dirigidos (DoS ,
DDoS)
EP8
Este trabajo se describe como parar los ataques
antes de que alcancen la infraestructura de red
interna atraves de un IDS basado en cliente-
servidor para WLAN.
Seguridad de las Redes
LAN, WLAN. Falsos Access Point.
Ataques Man in the Middle
(MITM)
EP11 Se centrará en el efecto de las tecnologías de
virtualización respecto IDPS.
Virtualización y Seguridad
en la Red.
Spam, Virus, Spyware,
Accesos no autorizados,
Cifrado.
Ataques dirigidos (DoS ,
DDoS).
EP12
Propone una arquitectura IDS que se despliega
entre cada usuario y el proveedor de servicio en
la nube.
Cloud Computing y
seguridad en la Red
DOS, DDOS, IP Spoofing y
ARP Spoofing
Ataques dirigidos (DoS ,
DDoS), IP Spoofing y ARP
Spoofing.
EP13
Consideran el problema de los ataques
"maliciosos" en redes de área local inalámbricas
(WLAN) usando un IPDS para detectar Access
Point Malicioso.
Seguridad de las Redes
LAN, WLAN. Falsos Access Point.
Ataques dirigidos (DoS ,
DDoS), Ataques Man in the
Middle (MITM), SYN y FIN
Attack.
EP14
Este artículo presenta una tecnica virtual inline
basada en la técnica the Man in the Middle
(MITM), combinando el NIDS/NIPS juntos en
la prestación de protección de onda a las redes.
Seguridad de las Redes
LAN, WAN, WLAN.
Falsos Access Point,
Ataques convencionales,
Virus en Mails, Contenido
Malicioso.
Ataques dirigidos (DoS ,
DDoS), Ataques Man in the
Middle (MITM), SYN y FIN
Attack.
EP15
En este artículo, exploramos un diseño
alternativo que aprovecha las oportunidades
espaciales y de red para distribuir las funciones
IDPS.
Seguridad de las Redes
LAN, WAN, WLAN,
Progamación Lineal,
Hardware.
Ataques convencionales,
Virus en Mails, Contenido
Malicioso.
Vulnerabilidades de software
que se está ejecutando,
Infraestructura.
EP16 Se centra en entender los IDPS Snort y Nmap. Seguridad de Redes.
Ataques convencionales,
Virus en Mails, Contenido
Malicioso.
Ataques dirigidos (DoS ,
DDoS)
38
Tabla 10.(Continuación) Detalle de la información de los Estudios Primarios, la tabla no
contiene los estudios EP1, EP4, EP5, EP6, EP9 y EP10, ya que estos son estudios introductorios
solo sirviendo para obtener el conocimiento base de los dispositivos.
EP Objetivo Aplicación / Áreas
Investigación Amenazas Ataques
EP17
Muestra un enfoque de IPS mediante el
procesamiento de textos y llamadas al sistema,
sirven como fuente para la minería de datos y la
previsibilidad de cualquier posibilidad de
intrusión.
Analísis de Texto, Lógica
difusa, Algoritmos
Genéticos, Firmas IDS,
Vistualización, Seguridad
de Red.
Llamadas al sistema, Spam,
Virus, Spyware, Accesos no
autorizados, Cifrado.
Ataques dirigidos (DoS ,
DDoS), ataques FTP, Ataques
WEB, Técnicas de
Exploración.
EP18
Se propone un IDPS basada en red que
dependen de enfoque redes definidas por
software (SDN) y llevamos a cabo algunos
experimentos típicos para evaluar su
desempeño
Seguridad de las Redes
LAN, WAN, WLAN
Ataques malicicioso o no
autorizado, paquetes
corruptos, código malicioso,
botnes, virus.
Ataques dirigidos (DoS,
DDoS), Tinforscan, Nmap
Mailbomb, SYN flood, Ping
of Death, Smurf, Teardrop,
Crashiis
EP19
En este documento se describe una técnica
operacional que utiliza comunidades BGP para
activar remotamente el black-holing de una red
de destino particular para bloquear ataques de
denegación de servicio.
Seguridad de las Redes
LAN, WAN, WLAN
Ataques dirigidos (DoS ,
DDoS).
Ataques dirigidos (DoS ,
DDoS),
EP20 Este trabajo se describen con firmas de
vulnerabilidad para los IDPS.
Seguridad de las Redes
LAN, WAN, WLAN
Vulnerabilidades conocidas
y no conocidas (Zero Day),
Falsos positivos, Falsos
Negativos.
Vulnerabilidades de software
que se está ejecutando
actualmente, Llamadas al
sistema (Virus, BOTNets)
EP21
Analisa y evalua las contramedidas utilizadas
para hacer frente a los DoS contra VoIP. Se
evalua esquemas IPDS en contra de un servidor
SIP.
Seguridad de las Redes y
Telefonia por Voz IP
(VoIP).
QoS,Protocolos y Ataques
dirigidos (DoS, DDoS).
Ataques dirigidos (DoS,
DDoS)
EP24
Presenta un mecanismo novedoso en la toma
automatizada de respuesta a intrusiones basada
en el proceso de jerarquía analítica (AHP)
utilizando un IDS.
Seguridad de las Redes
LAN, WLAN.
Decisiones complejas para
los Admin al Detectar trafico
malicicioso o no autorizado,
paquetes corruptos.
Ataques dirigidos (DoS,
DDoS),
EP25
En este trabajo presenta un diseño que incluye
métodos cuantitativos y cualitativos para
identificar áreas de mejora en los IDPS.
Seguridad de las Redes
LAN, WAN, WLAN, Fast
Networks.
Falsos Access Point, Ataques
convencionales, Virus en
Mails, Contenido Malicioso.
Ataques dirigidos (DoS ,
DDoS).
EP26
En este trabajo presenta una propuesta de
expansión a los actuales IPS que los combina
con los principios detrás de los honeypots para
reducir falsos positivos mientras captura tráfico
de ataque para mejorar las reglas de prevención.
Seguridad de las Redes
LAN, WLAN.
Falsos positivos, Falsos
Negativos,
Trafico WEB.
Tecnicas de Explotación
EP27
En este trabajo, considera que el problema de
los ataques "maliciosos" en redes WLAN
utilizando un IDS.
Seguridad de Redes.
Phishing, Falsos Access
Point, Accesos no
Autorizados. Ataques Man in the Middle
(MITM), SYN y FIN Attack.
EP28
Esta investigación evaluó la efectividad de la
seguridad cibernética del IPS para Voz sobre
Protocolo de Internet (VoIP) que se centra en la
defensa de Denegación de Ser- vice (DoS) que
proponen perturbar servidor que proporciona
los servicios de VoIP.
Seguridad de las Redes y
Telefonia por Voz IP
(VoIP).
QoS,Protocolos y Ataques
dirigidos (DoS, DDoS). Ataques dirigidos (DoS ,
DDoS), ataque de
multidifusión y unicast.
39
Capítulo 3. Metodología para el
desarrollo de la tesis
En este capítulo se describe la metodología utilizada para el desarrollo de la tesis. La Figura 12
muestra las tareas llevadas a cabo durante el desarrollo de la tesis y el orden en que se
implementaron.
Figura 12. Metodología para el desarrollo de la tesis.
Como se observan en la figura 12 se inició con la obtención del estado del arte sobre
los Sistemas de Detección y Prevención de Intrusos (IDPS), el cual fue obtenido mediante el
desarrollo de una revisión sistemática.
La siguiente tarea consistió en el análisis del funcionamiento y requerimientos de un
IDPS para su implementación, las cuales fueron identificadas como parte de los principales
resultados de la revisión sistemática, cabe recalcar que la mayoría de los trabajos basan sus
investigaciones en software libre y no comercial. Posteriormente se realizó una identificación
y revisión de los principales de trabajos relacionados.
1. Obtención del estado del arte sobre
los Sistemas de Detección y Prevención
de Intrusos (IDPS)
2. Análisis del funcionamiento y
requerimientos de un IDPS
3. Identificación y revisión de trabajos
relacionados
4. Definición de la propuesta para
Identificación de URL de un IDPS comercial a
Software Libre
5. Desarrollo de herramienta para
facilitar complementar un IDPS de software
libre
6. Validación de la propuesta y de la
herramienta mediante un caso de estudio.
40
A continuación, se definió la propuesta para identificación de URL de un IDPS
comercial a Software Libre a partir de las estrategias identificadas anteriormente.
Consecutivamente a la definición de la propuesta se diseñó y desarrollo una herramienta para
facilitar complementar un IDPS de software libre. Finalmente, se realiza una validación para
comprobar la viabilidad de la propuesta y de la herramienta mediante un caso de estudio.
3.1. Ejecución de la metodología para el desarrollo de Tesis
Establecimiento del estado del arte sobre los Sistemas de Detección y Prevención de
Intrusos (IDPS). Con el objetivo de obtener un panorama actual sobre el aligeramiento de
procesos se realiza una revisión sistemática de la literatura enfocada en tres aspectos
principales: 1) distribuciones, 2) instalaciones y 3) ataques y soluciones para estos mismos.
En el Capítulo 2, sección 2.1 se encuentra detallado el protocolo de la revisión sistemática
desarrollados y los resultados obtenidos.
Análisis del funcionamiento y requerimientos de un IDPS. Se realizó un análisis de los
manuales de Snort, conocimientos de reglas en Snort, Instalación de SO Linux y Windows
de software libre. El análisis completo se encuentra dentro del marco teórico del Capítulo
1, en la sección 1.1.3.
Identificación y revisión de trabajos relacionados. A partir de la revisión sistemática se
eligieron un conjunto de trabajos que muestran el funcionamiento y requerimientos de un
IDS (Sistema de Detección de Intrusiones). Se realiza un análisis de dichos trabajos
mediante una comparativa de las propuestas, y así mismo se examinan las características
cubiertas por los trabajos. El desarrollo de esta actividad se encuentra en el capítulo 2,
sección 2.2.
Definición de la propuesta para identificación de URLS de un IDPS comercial a
Software Libre. Analizar los registros detectados por el sistema IDPS Snort para establecer
y corregir problemas de seguridad, para obtener resultados del rendimiento de la operación
de la red. La definición y descripción de los pasos del método se encuentra en el Capítulo
4, secciones 4.1 y 4.2.
Desarrollo de la herramienta para facilitar el uso del método propuesto. A partir de la
propuesta del método para identificación de URLS de un IDPS comercial a Software Libre,
se desarrolló una herramienta que facilite su uso, la tecnología utilizada se describe en la
sección 2.3, mientras que la metodología de desarrollo se encuentra en la sección 2.4, ambas
secciones se encuentran dentro del Capítulo 2. El desarrollo de la herramienta se detalla en
el Capítulo 4, sección 4.4.
41
Validación de la propuesta en conjunto con su herramienta. Para validar la herramienta
y la propuesta del método se realizó un estudio de caso en del CIMAT Unidad Zacatecas.
El detalle de los casos de estudio se encuentra en el Capítulo 5, sección 5.2.
42
Capítulo 4. Propuesta
Este capítulo contiene la propuesta de marco de trabajo presentado en el capítulo anterior. El
objetivo se basa serie de ejercicios de laboratorio donde demostraremos varias técnicas para
escribir reglas de Snort, desde la sintaxis de reglas básicas hasta las reglas de escritura para
detectar tipos específicos de ataques. También examinaremos algunos enfoques básicos para el
análisis y la optimización del rendimiento de las reglas.
1. Gestor de Reglas Snort basado en Application Detection de CISCO SourceFire.
2. Análisis del desempeño de nuestras reglas ejecutadas
3. Mostrar un DashBoard (basado en el desempeño).
4. Mejorar el Procesamiento de nuestras reglas en tiempo real.
5. Encontrar patrones repetitivos dentro de esos datos a través de EKL.
Nota: como entregables tendremos el Código fuente desarrollado para el ejercicio, script de
objetos de base de datos, diagrama entidad relación de la base de datos (el diagrama puede ser
dibujado en lápiz).
4.1. Prerrequisitos
4.1.1. Snort
Como ya lo hemos mencionado, "Snort® es un sistema de prevención y detección de intrusión
de red de código abierto (IDS / IPS) desarrollado por Sourcefire. Combinando los beneficios
de la firma, el protocolo y la inspección basada en anomalías, Snort es la tecnología IDS / IPS
más ampliamente implementada en todo el mundo. Con millones de descargas y casi 400,000
usuarios registrados, Snort se ha convertido en el estándar de facto para IPS”. (Fuente
www.snort.org 2017). También se debe mencionar que Sourcefire fue adquirida por Cisco a
principios de octubre de 2013 (Figura 13).
El servidor de Snort es el encargado de procesar todo el tráfico de red en busca de posibles
eventos, encargándose también de almacenar la información guardándolas en logs los cuales
serán posteriormente procesados.
43
Figura 13. Página principal de Snort.
4.1.1. Elastic Stack (Elasticsearch, Logstash and Kiban
EKL)
Es un conjunto de herramientas principalmente compuesto por 3 aplicaciones (ElasticSearch,
Logstash y Kibana) y algunas otras extras, donde se destaca ElasticSearch, siendo un motor de
búsqueda (basada en Lucene) de texto completo, distribuido y con capacidad de multi-tenencia
con una interfaz web RESTful y con documentos JSON. Las cadenas de texto principalmente
son líneas de log, los cuales serán procesados. Cuenta con clientes oficiales de los principales
lenguajes de programación.
Logstash permite centralizar él envió de logs de forma que vamos a tener una instancia con
diferentes tipos de logs, realizando transformaciones de estos logs antes de realizar cualquier
otro tipoi de procesamiento.
Kibana de manera sencilla, podríamos definirlo como la interfaz gráfica mediante el cual
podemos ver la representación de eso datos de diferentes formas, facilitando la representación
de estos.
4.1.2. Filebeat (beats)
Siendo parte de un grupo de agentes denominados beats, es el agenté que nos permitirá enviar
los datos de nuestras instancias a un punto central, los cuales podrían ser Logstash o
ElasticSearch; es así que Filebeat te ayuda a simplificar las cosas al ofrecer una forma ligera de
reenviar y centralizar registros y archivos, La figura 14 muestra el conjunto de herramientas
ofrecido por Elastic Cloud.
44
Figura 14. Herramientas ofrecidas en la plataforma Elastic Stack.
Azure es una plataforma de servicios de cómputo y almacenamiento en la Nube basados en
tecnología Microsoft y Open Source (Linux), estos servicios están listos para usar a través de
una cuota por los servicios que usen. Con esta plataforma podemos implementar bases de datos,
aplicaciones web con la posibilidad de extender los recursos de TI en cualquier momento
(Figura 15).
Figura 15. Plataforma de servicios Azure.
45
4.1.1. Elastic Cloud
De la misma manera que Azure, Elastic Cloud es una plataforma oficial de ElasticSearch &
Kibana que permite implementar y administrar un clúster seguro que se ejecute en Amazon o
Google con las últimas versiones de ElasticSearch y Kibana. De la misma manera estos
servicios están listos para usar a través de una cuota por los servicios que usen como se puede
observar en la Figura 16.
Figura 16. Plataforma oficial de Elastic Stack.
4.1.1. HTTP/HTTPS
De la misma manera, actualmente para transferencia de datos de hipertexto, los dos protocolos
más utilizados son Hypertext Transfer Protocol (HTTP) y Hypertext Transfer Protocol Secure
(HTTPS), siendo el segundo la versión segura dado que encripta la información transferida
entre el servidor y la aplicación que consume datos (generalmente un Browser); de esta forma
se previene que personas ajenas tengan acceso a esta información interceptando la
comunicación. HTTPS utiliza a SSL o TLS como protocolo de encriptación. Estos dos
protocolos utilizan el cifrado asimétrico, el cual está compuesto por una llave pública y una
privada; la llave pública es necesaria para des encriptar información previamente encriptada
con la llave privada y viceversa. En el caso del protocolo HTTPS, la llave privada es
almacenada en el servidor y la pública es enviada al navegador o a la aplicación en específico
dentro del certificado SSL, estableciendo finalmente una conexión segura para el intercambio
de información (Figura 17).
46
Figura 17. HTTP vs HTTPS.
4.1. Programación de Snort
Snort puede funcionar esencialmente en tres modos diferentes.
• Modo NIDS (Network Intrussion Detection System). - Esta opción es la más
completa y la cual permite más configuraciones; en este modo podemos analizar el
tráfico de la red en busca de intrusiones a partir de nuestros patrones de búsquedas
los cuales están definidos en las reglas previamente configuradas. De este modo,
Snort nos dará informes de los accesos de intentos no permitidos a nuestro host,
escaneo de puertos, ataques, exploits, etc. Para que Snort se ejecute de este modo,
debemos pasar el parámetro –c al archivo de configuración: snort -c
c:\snort\etc\snort.conf -l c:\snort\log –i (Figura 18).
47
Figura 18. Snort en modo de Ejecución IDS.
• Modo Registro (Package Logger). - Al ejecutar snort en este modo, una gran
cantidad de información pasara a través de nuestra de pantalla, para lo cual
necesitamos guardar estos datos en algún medio para realizar un estudio posterior.
Este modo al igual que el modo sniffer escucha el tráfico dentro de nuestra red y lo
registra en un determinado directorio. Para iniciar snort en este modo debemos
utilizar el parámetro –l /Snort/log/ (Directorio de instalación de snort): snort -vde -l
c:\Snort\log –i (Figura 19).
48
Figura 19. Snort en modo de ejecución registro.
• Modo Sniffer. - Este modo permite escuchar el tráfico dentro de nuestra red, para luego
mostrarlo a través de nuestra pantalla. Una vez que ha finalizado el modo sniffer, las
estadísticas de tráfico de red son desplegadas. Para iniciar Snort en modo sniffer
ejecutamos el siguiente comando: snort –v. (Figura 20).
Figura 20. Snort en modo de ejecución sniffer.
• Modo Inline. - Este modo permite interactuar a snort con el firewall de forma que si
un ataque es detectado se pueda enviar un petición para cortar el tráfico dentro de la
49
red, para configurarlo de esta manera snort debe de estar en modo bridge y existir una
comunicación con las iptables pre configuradas.
Nota: Vamos a utilizar Snort en esta parte del laboratorio en modo IDS, y luego lo usaremos
como un registrador de paquetes.
Tabla 11. Existen una gran cantidad de comandos que Snort utiliza, los más comunes se
describen dentro de la tabla a manera general.
Parámetro Modo Descripción Ejemplo
-v Sniffer Ejecuta a snort en modo sniffere, muestra las cabeceras TCP, UDP, ICMP y la dirección IP. snort –v
-l Package logger En este modo especificamos donde snort guardaralos log generados. snort –l /snor/log
-c NIDS Utilizamos snort como modo de deteccion de intrusos. snort –v -c
-d package -
Sniffer -NIDS
Incluye las cabeceras TCP, UDP, ICMP snort -d
-e package -
Sniffer -NIDS
Incluye las cabeceras de capa de enlace snort –e
-b package -
Sniffer –NIDS
Indica el formato binario el cual es tambien conocido como TCPDump. De esta forma
snort corre mas rapido ya que no tiene que traducir la información a formato entendible por
los humanos.
snort -e
-L package -
Sniffer –NIDS
Sirve para especificar un log binario. snort –b –l /Archivo
-r package -
Sniffer –NIDS
Procesa un archivo de log grabado en modo binario. snort –dev –r archivo.log
-h package -
Sniffer –NIDS
Indicamos la dirección IP en la cual snort devera actuar snort –h IP
-i package -
Sniffer –NIDS
Indicamos la red de donde obtendremos los datos. snort –dev –i etch o
and / or /
not
package -
Sniffer –NIDS
Se utilizan para ignorar paquetes procedentes de una ip y funcionan con las expresiones
and, or o not
snort –vd not host ip
src net package -
Sniffer –NIDS
Utilizada para ingnorar el tráfico de la red origen indicada. snort –dv src net ip
dst /rtc port package -
Sniffer –NIDS
Ignora el tráfico de red que tenga el puerto indicado como destino u origen snort –vd –r not host ip
and src port puerto
4.1. Desarrollo de la herramienta
En este capítulo se describen los casos de estudio de la aplicación (la cual hemos llamado
SnortNet y que partir de este momento nombraremos de la misma manera), en ellos se muestra
su funcionamiento, las funcionalidades que brinda al usuario y la información de respuesta
obtenida. En esta sección, se describe las principales vistas que constituyen a las
funcionalidades de la aplicación.
4.1.1. Página de Bienvenida
Esta vista permite al usuario a groso modo darse una idea del objetivo de la aplicación,
además de describir los puntos principales del proyecto. Para acceder a esta vista solo hay
ingresar directamente a la URL de SnortNet. Como se observa en la Figura 21.
50
Figura 21. Página principal de SnortNet.
4.1.1. Página de Acerca de
Brinda al usuario un resumen completo conocer las tecnologías que se utilizaron para la
realización de la aplicación SnortNet, cabe recalcar que esta página es solo informativa. Para
acceder a esta vista el usuario tiene que seleccionar la opción Acerca de del menú principal
(Figura 22).
Figura 22. Página de Acerca de.
51
4.1.1. Contacto
Esta vista ofrece al usuario información relacionada con los involucrados en el proyecto, al
igual que las páginas anteriores la página de Contacto tiene que seleccionarse desde el menú,
opción Contacto como se observa en la Figura 23.
Figura 23. Página de contacto de la aplicación.
4.1.2. Inicio de Sesión
En la Figura 24 se observa la vista de inicio de sesión de la aplicación móvil SnortNet, sus
principales funcionalidades son:
• Inicio de Sesión. - Esta funcionalidad permite al usuario iniciar nuevas sesiones en la
aplicación. Para iniciar sesión, se activará un formulario como el mostrado donde se
tiene que el usuario y la contraseña. Si los datos son correctos se inicia sesión
normalmente accediendo a la aplicación;
• Consultar por el manual de ayuda o información de la aplicación.
52
Figura 24. Vista de Inicio de sesión.
4.1.3. Reglas
Esta es una de las principales funcionalidades del sistema, dado que muestra y crea nuestras
reglas locales generadas por la aplicación y que utilizara Snort de forma concisa y resumida.
Para acceder a esta vista, el usuario deberá haber iniciado sesión y acceder a la opción Reglas
en el menú principal. En la figura 25, se observa la información obtenida distribuida en
columnas, las principales columnas son Descripción de la regla, cabecera, opciones y uso de
preprocesador.
Esta y todas las vistas de información brindan al usuario las funcionalidades extras:
• Búsqueda de información por columnas, para ello seleccionar el nombre de la columna
en el spinner superior e ingresar la cadena de búsqueda.
• Ordenamiento de filas por columnas, al hacer clic en las cabeceras de tabla con letras,
se realizará un orden ascendente de la información en base a esa columna.
Otra funcionalidad con la cuenta la aplicación es que aplicar la regla directamente a nuestro
IDPS Snort.
53
Figura 25. Vista de Reglas SnortNet.
4.1.1. DashBoard
Esta es otra de las principales funcionalidades del sistema, dado que muestra las alertas
registradas por Snort de forma concisa y resumida ya que anteriormente fueron pre procesado
por EKL y guardada dentro de la BD. Para acceder a esta vista, el usuario debe seleccionar la
opción DashBoard en el menú principal. En la figura 26, se observa la información obtenida
distribuida en columnas, las principales columnas son nombre del ataque, fecha y clasificación
de ataque. Además de las funcionalidades extras que ya mencionamos anteriormente, esta
agrega una gráfica sencilla de las principales alertas generadas por Snort:
Figura 26. Vista DashBoard de SnortNet.
54
4.1.2. Elastic Cloud
Elastic Cloud es una plataforma concisa ya que establece la capacidad y el rendimiento de
cualquier servicio en la nube se puede expandir o contraer de acuerdo con los requisitos del
cliente y que esto puede modificarse automáticamente como consecuencia de algún evento
controlado por software o, en el peor de los casos, puede ser reconfigurado rápidamente por el
cliente equipo de administración de infraestructura.
Para efectos de este caso de estudio Elastic Cloud ofrece un servicio de alojamiento por 14 días,
la cual no requiere ingreso de tarjeta de crédito y ofrece los productos oficiales de ElasticSearch
y Kibana. La prueba de alojamiento (Figura 27) incluye lo siguiente:
• 4 GB de memoria.
• 96 GB de almacenamiento.
• Alta disponibilidad en dos zonas.
• Las últimas versiones de Kibana y ElasticSearch.
• Funciones de seguridad avanzadas como autenticación y control de acceso basado en
roles.
• Capacidades de alerta para activar notificaciones.
• Monitoreo para optimizar la salud de su clúster.
Figura 27. Elastic Cloud en su versión trial.
Las figuras 28 y 29 muestran la implementación de nuestro clúster, el cual previamente se ha
configurado.
55
Figura 28. . Configuración de nuestro clúster Elastic Stack.
Figura 29. Datos de acceso a nuestro clúster Elastic Stack.
4.1.3. Azure
Azure permite ofrece la creación de servicios en la nube tales como Máquinas Virtuales,
Manejo de Hospedajes, bases de datos SQL entre otros servicios, al mismo tiempo que
proporciona alta disponibilidad y rendimiento de red con balanceadores de carga. Azure en su
versión de prueba nos ofrece las siguientes características (Figuras 30 y 31):
• Crédito de MXN$3,900 para explorar servicios durante 30 días.
• 12 meses de servicios populares gratuitos.
• Más de 25 servicios sin caducidad gratis.
• 5 GB de File Storage LRS almacenamiento de archivos multiplataforma distribuido y
sencillo sin necesidad de hacer cambios en el código.
• Base de datos en Azure SQL Database con inteligencia integrada de hasta 250 GB.
56
• 750 Horas de máquinas virtuales con capacidad a petición en solo unos segundos.
Figura 30. Información de cuenta Gratuita de Azure
Figura 31. Panel principal de nuestros servicios hospedados en Azure.
57
Capítulo 5. Resultados
En este capítulo se presentan los resultados de la validación de la herramienta propuesta en esta
investigación, con el fin de mejorar el desempeño en la seguridad dentro de nuestra red. Este
capítulo consta de la descripción de la herramienta con el apoyo de algunas pantallas para
visualizar el modo de operación, así como el estudio de caso que se diseñó para validar la
identificación de los roles de trabajo mediante la herramienta
5.1. Herramienta para identificación de vulnerabilidades de
intrusión mediante el establecimiento de reglas y análisis de
logs por medio de la plataforma Elastic Stack.
A continuación, esta sección presenta las capturas de pantalla de la herramienta del entorno
virtual, para la identificación de las bitácoras (logs), las figuras se han organizado en cuatro
grupos: 1) inicio de aplicación, 2) creación de reglas, 3) configuración de la plataforma y 4)
prueba de la construcción realizada.
Dentro del grupo encontramos las figuras: Figura 32, Figura 33, Figura 34, Figura 35,
Figura 36 y Figura 37 que son la base del proyecto realizado en la primera versión de la
herramienta desarrollada, se presenta en la pantalla principal de la aplicación, la pantalla reglas,
la pantalla de inicio de snort, pantalla de inicio de filebeat, el clúster de Elastic Search y la
plataforma Azure para nuestra aplicación.
El grupo 2 está formado por las Figuras: Figura 38, Figura 39, y Figura 40; estas a su vez
representan la agregación de reglas locales. En las pantallas existen elementos previamente
creados, el objetivo es mostrar diversos valores para cumplir con el objetivo de agregación,
representación y el análisis, llevando a cabo las reacciones en cadena necesarias para el correcto
funcionamiento de la aplicación.
58
Las reglas creadas cuentan con propiedades que sirven de restricciones para su correcta
adición, los elementos son los siguientes: Acción, Protocolos involucrados, Direcciones IP de
origen y destino, Números de puerto, Dirección de la operación, Mensaje, Opciones de decisión
y sid de la regla.
Estos elementos complementaran la protección que nos brinda snort a través de la
obtención de las reglas pres configuradas dentro de su portal y las cuales son: Comunidad
(disponibles de forma gratuita para su descarga y creadas por la comunidad snort), Registrado
(disponibles una vez que nos hallas registrado en el portal de snort y completadas por el equipo
talos), y Suscripción (Además del registro dentro del portal, se realiza un cobro de manera
mensual ya que garantizan la actualización de reglas para las amenazas recientes que han sido
detectadas por el equipo talos.
El grupo 3 consta de las figuras: Figura 41 y Figura 42; las cuales muestran los parámetros
de configuración de nuestras plataformas hospedadas en la nube y que son la base del análisis
de nuestras bitácoras (log) creados por snort y que una vez agregada las actividades de
agregación y ejecución procede a realizar la construcción para realizar el análisis a través de
del conjunto de herramientas Elastic Stack.
Por último, el grupo 4 está compuesto por las figuras: Figura 42, Figura 43 y Figura 44.
La cuales prueban una prueba base para lograr el objetivo solicitado. Una vez finalizadas las
actividades de agregación y ejecución, procedemos con el análisis de los logs, este analizas se
realiza gracias a la participación de Elastic search y Kibana la cual añade la propiedad de
representación, consultas y almacenamiento que son una consecuencia de las reacciones en
cadena de los grupos anteriores.
59
Figura 32. Pantalla principal de la aplicación SnortNet, en ella se detalla las reglas básicas para
creación de reglas.
Figura 33. Pantalla principal de creación de reglas de SnortNet.
60
Figura 34. Pantalla de inicio de ejecución de Snort.
Figura 35. Pantalla de inicio de ejecución de FileBeat.
Figura 36. Cluster de Elastic Search montado para nuestra aplicación.
61
Figura 37. Plataforma Azure creada para nuestra aplicación SnortNet.
Figura 38. . Reglas Locales agregadas a nuestro archivo local.rules.
Figura 39. Reglas base obtenidas después del registro en la plataforma Snort.
62
Figura 40. Ejemplo de Log de Salida creado por Snort.
Figura 41. Parámetros de configuración de la plataforma Elastic Stack.
Figura 42. Dominio de la Plataforma Elastic Stack.
63
Figura 43. Análisis de Logs mediante Kibana por medio de la plataforma Elastic Stack.
64
Figura 44. Representación de Logs por Logs mediante Kibana por medio de la plataforma
Elastic Stack.
5.1. Estudio de Caso
Dentro de la ingeniería de software encontramos varios métodos empíricos, los cuales son:
1) experimentos controlados, 2) estudios de caso, 3) encuestas y 4) análisis postmortem
(Easterbrook, Singer, Storey, & Damian, 2002; Wohlin, Höst, & Henningsson, 2003).
De acuerdo a lo anterior, dentro de esta investigación se utilizó el método empírico del
“Estudio de Caso” debido a su naturaleza del estudio, el cual estudia y comprende cómo se
llevó a cabo la ejecución de la herramienta propuesta. A continuación, presentamos el
desarrollo del estudio de caso.
65
Un estudio de caso es un método empírico que investiga un fenómeno contemporáneo
dentro de su contexto real, especialmente cuando los límites entre el fenómeno y el contexto
no son claramente evidentes (Yin, 2002).
El estudio de caso es adecuado para muchos tipos de investigación en Ingeniería de
Software, debido a que los objetos de estudio son fenómenos contemporáneos que son difíciles
de estudiar de forma aislada. Los casos de estudio no generan los mismo resultados (como lo
hacen los experimentos controlados), pero proporcionan una comprensión más profunda de los
fenómenos que se estudian (Runeson & Höst, 2009).
La implementación de un estudio de caso consta de 5 pasos principales (Figura 45), los cuales se
muestran a continuación (Runeson & Höst, 2009):
Figura 45. Pasos para implementar un caso de estudio.
En las siguientes secciones se muestran las actividades desarrolladas para cada paso para
la implementación del estudio de caso.
5.1.1. Diseño y planificación de los casos de estudio
La planificación de un estudio de caso es crucial, el primer paso establece los puntos clave para el
éxito del estudio de caso, para que éste tenga éxito, el diseño y planificación de un estudio de caso
debe contener los siguientes elementos (Tabla 11):
Tabla 12. Claves de planificación y diseño de un estudio de caso.
Puntos claves de estudio de caso
Objetivo ¿Qué se quiere lograr?
El objeto de estudio ¿Qué es lo que se estudia?
Teoría Marco de referencia
Preguntas de investigación ¿Qué se quiere conocer?
Métodos para recolección de datos ¿Cómo recoger los datos?
A continuación, se muestra el diseño y planificación para los casos de estudio.
1. Diseñar el caso de estudio
2. Preparar la recogida
de datos
3. Recoger datos
4. Analizar los datos recogidos
5. Reportar los
resultados
66
5.1.1.1. Objetivo de los casos de estudio
Evaluar la viabilidad de la herramienta para el análisis del funcionamiento de reglas de snort
dentro de nuestra red, teniendo en cuenta las facilidades otorgadas por las herramientas EKL
facilitando el uso y representación de datos por medio de ella.
5.1.1.2. Objeto de estudio
El estudio de caso se centra el estudio se enfoca en el análisis de 2 redes de un numero diverso
de hosts, quienes usaran las herramientas para identificar el desempeño adecuado de cada red.
La Tabla 12 presenta las características de las redes, las cuales fueron objeto de estudio.
Tabla 13. Redes objeto de Estudio
Identificador Red de trabajo Numero de Hosts Caracteristicas
RED 01 CIMAT 10 Estudiantes del posgrado de Maestría en
Ingeniería de Software en el Centro de
Investigación en Matemáticas unidad Zacatecas. RED 02 TEMPORALES 23 Desarrolladores de .Net dentro de la
TEMPORALES AGS.
5.1.1.3. Marco de referencia
Una de las preocupaciones más importantes en la industria es la seguridad de datos (otro
término utilizado es seguridad de la información o seguridad informática), ya que es un aspecto
esencial de TI en organizaciones de cualquier tamaño y tipo, es decir, se trata de un aspecto
que tiene que ver con la protección de datos contra accesos no autorizados y para protegerlos
de una posible corrupción durante todo su ciclo de vida.
Asociado a lo anterior, Tendencias recientes han demostrado que los ataques están aumentando
en frecuencia y en gravedad. En los últimos años, empresas y organizaciones, han sido víctimas
de ataques y han tenido que pagar o correr el riesgo de perder datos importantes.
La herramienta para el análisis del funcionamiento de reglas de snort dentro de nuestra red
teniendo en cuenta tres bases estratégicas: (1) el análisis de tráfico de nuestra mediante snort
con la adición de reglas locales, (2) el uso de técnicas de análisis masivo o Big data para la
identificación de la factibilidad de las mismas y (3) la identificación de las mejores reglas dentro
de la organización.
5.1.1.4. Preguntas de investigación
P1. ¿El uso de reglas locales permite mejorar el desempeño de las alertas de nuestra red?
67
P2. ¿El uso de técnicas de análisis masivo o Big data facilita la identificación de trabajo
realizado por nuestras reglas locales?
P3. ¿La herramienta es eficiente, fácil de utilizar y, por lo tanto, facilita la implementación
del método?
5.1.1.5. Métodos para la recogida de datos
El método elegido para la recogida de datos es la observación no estructurada, debido a que el
investigador actúa como observador y se familiariza con el lugar para posteriormente volverse
participante activo, desarrollar un plan de muestreo de eventos y seleccionar las posiciones para
llevar a cabo recolección de información del ambiente, los participantes, sus actividades e
interacciones, la frecuencia y duración de los eventos.
5.1.2. Preparación de la recogida de datos
La obtención de datos se realizó en dos partes: dentro de la primera parte, se selecciona una
muestra de logs generado por la herramienta snort en base al total de host dentro de la red y se
observa los resultados sugeridos por la misma. En la segunda parte, dicha muestra es evaluada
mediante el uso de técnicas de análisis masivo por medio de las herramientas.
A continuación, la Tabla 13 muestra las actividades y consideraciones que con lleva el uso de
la observación.
Tabla 14. Consideraciones de la observación.
Actividades
A. comunicar el objetivo de la observación y las actividades a realizar, preservando el anonimato de los participantes.
B. Obtención de acceso y establecimiento de relaciones para la recogida de datos .
C. Numero de participantes ,edad, sexo y descripción del escenario para analisis de contexto.
D. Registro de notas de la actividad en el orden que ocurra separando los echos, hora, lugar y fecha.
E. las técnicas y herramientas sugeridas facilitan la implementación de prácticas en las organizaciones.
F. Acilidad de entendimiento de la muestra
G. Satisfacción de Uso.
H. Eficiencia de uso
68
5.1.1. Recogida de datos
Para la recogida de datos en los casos de estudio se sigue el siguiente proceso que se describe
en la Figura 46:
Figura 46. Pasos para la recolección de datos
1. Se realiza una reunión con los administradores de red en la cual se les explica brevemente
cómo funciona la herramienta con el apoyo de una presentación.
2. El encargado para la recogida de datos en relación a las preguntas de investigación,
determinar el lugar donde se va a realizar la observación, obtener permiso, seleccionar a las
personas clave y familiarizarse con el escenario.
3. Los hosts se registran las actividades en la herramienta. Una vez terminada la interacción
con la herramienta, se determinan los logs a utilizar.
4. se realiza el análisis de las actividades realizadas en el entorno virtual.
5. Por último, los hosts repitieron la misma actividad del paso 3, encuesta para evaluar su
desempeño.
5.1.1. Análisis de los datos recogidos
En esta sección se realiza un análisis de los datos recolectados durante la ejecución del estudio
de caso. La Tabla 15, presenta un resumen de las características de las redes en las que se
trabajó.
Instalación de la
herramieta
Primera Actividad de Monitoreo
Interacción de la
herramienta
Análisis de datos
Segunda Actividad de Monitoreo
69
Tabla 15. Descripción de las redes de trabajo.
Equipo Caracteristica Numero de Hosts Muestra Logs Experencia
RED 01 CIMAT 10 2 NO
RED 02 TEMPORALES 23 2 SI
5.1.1. Reporte de resultados RED 01
Esta sección presenta los resultados de la red 01, se muestran los resultados obtenidos en la
primera actividad en la construcción de logs. La Figura 47 se puede apreciar un log dentro de
la red CIMAT con un número reducido de Logs. El recuento de Líneas totales fueron 645
Líneas en un periodo de análisis promedio de 15 minutos.
Figura 47. Muestra de datos obtenidos en nuestra red 01.
En la Tabla 15 se puede observar que la fase 1 fue complicada para el análisis de tráfico de red,
debido al flujo de tráfico reducido y la apoca experiencia del administrador en la herramienta.
En Resumen, al concluir la actividad encontramos un total de 92 alertas en promedio, este
cálculo se obtiene gracias a que un mensaje de alerta esta detonado por 6 líneas de información,
a este hecho se le debe agregar un espacio en blanco que ayuda a separar cada alerta, facilitando
la lectura por humanos.
70
Tabla 16. Reporte de resultados para la red 01.
Descripción Recuento de Alertas por fase
RED 01 92
Recuento de lineas totales en log 645
Recuento de Alertas por fase 92
Tiempo de desarrollo 15 Minutos
Muestra de Log 2
Experencia previa No
La Figura 48 y 49, presentan una relación base de análisis realizados por las herramientas
Elastic Stack, antes y después de la interacción con la herramienta. Dos de los cambios más
importantes que se percibieron durante el desarrollo de las actividades fueron. 1) El flujo de la
red 01 en el entorno virtual demostró poco flujo dentro de la red. 2) el análisis de la herramienta
llevado por Kibana presenta pocos datos relevantes debido a la cantidad de logs generados
durante el análisis de red.
Figura 48. Flujo y descripción general de la buscada.
71
Figura 49. Filtrado de Información por cabecera, datos relevantes del análisis.
El análisis de los resultados respalda, que el uso de conjunto de las herramientas mejora el
desempeño en el análisis de alertas con base en la sugerencia del uso de EKL.
5.1.1. Reporte de resultados RED 02
En esta sección se presenta los resultados de la red 02, se muestran los resultados obtenidos en
la primera actividad en la construcción de logs. La Figura 50 se puede apreciar un log dentro
de la red Temporales con un número abundante de Logs. El recuento de Líneas totales fueron
2251 Líneas en un periodo de análisis promedio de 15 minutos.
Figura 50. Muestra de datos obtenidos en nuestra red 02.
72
En la Tabla 16 se puede observar que la fase 2 fue menos complicada para el análisis de tráfico
de red, debido al flujo de tráfico y la experiencia del administrador en la herramienta. En
Resumen, al concluir la actividad encontramos un total de 92 alertas en promedio, este cálculo
se obtiene gracias a que un mensaje de alerta esta detonado por 6 líneas de información, a este
hecho se le debe agregar un espacio en blanco que ayuda a separar cada alerta, facilitando la
lectura por humanos.
Tabla 17. Reporte de resultados para la red 02.
Descripción Recuento de Alertas por fase
RED 02 321
Recuento de lineas totales en log 2251
Recuento de Alertas por fase 321
Tiempo de desarrollo 15 Minutos
Muestra de Log 2
Experencia previa SI
La Figura 51 y Figura 52, presentan una relación base de análisis realizados por las
herramientas Elastic Stack, antes y después de la interacción con la herramienta. Dos de los
cambios más importantes que se percibieron durante el desarrollo de las actividades fueron. 1)
El flujo de la red 02 en el entorno virtual demostró un mayor flujo dentro de la red. 2) el análisis
de la herramienta llevado por Kibana presenta un mayor número de datos relevantes debido a
la cantidad de logs generados durante el análisis de red.
Figura 51. Flujo y descripción general de la buscada.
73
Figura 52. Filtrado de Información por cabecera, datos relevantes del análisis.
El segundo análisis de los resultados confirma el respaldo del uso en conjunto de las
herramientas mejora el desempeño en el análisis de alertas con base en la sugerencia del uso de
EKL.
74
Capítulo 6. Conclusiones
En este capítulo se presentan las conclusiones obtenidas. Además, se presenta el trabajo futuro
derivado de este tema de investigación y, por último, se abordan los productos académicos de
esta investigación.
6.1. Conclusiones
Con el presente trabajo de investigación utilizando un software en código abierto; se
obtuvieron avances sustanciales en el conocimiento acera del funcionamiento del IDS Snort,
como un sistema que detecta acciones de usuarios maliciosos, debido a los reportes obtenidos,
donde se observó la manera en cómo lanza los registros para lo cual se deja una propuesta para
que se pueda implementar teniendo en cuenta las facilidades otorgadas por las herramientas
EKL facilitando el uso y representación de datos por medio de ella y siendo aplicada en
diferentes áreas, incluyendo la ingeniería de software, donde han comenzado a originarse
propuestas en el desarrollo de productos y en la mejora de procesos de seguridad en las TI.
Las herramientas de software libre, nos permiten la implementación de una gran cantidad
de servicios sin necesidad de pagar licencias, pero se recomienda siempre dimensionar
correctamente el equipo de cómputo donde se implementarán estas soluciones basándonos en
la cantidad de usuarios y servicios que se vayan a implementar.
6.2. Trabajo futuro
Como trabajo futuro se plantea mejorar la funcionalidad de la herramienta del entorno virtual,
con las siguientes adecuaciones:
• Realizar la identificación de Snort para que trabaje de forma automática.
• Agregar elementos dentro de la creación de reglas que facilite aún más la
localización dentro del análisis realizado por EKL.
• Implementarlo para detección de un mayor número de nodos Snort.
75
6.3. Logros académicos
A continuación, se muestran los logros académicos obtenidos a partir de la presente
investigación.
6.3.1. Productos académicos
A continuación, en la Tabla 17 se muestran los productos académicos logrados durante el
desarrollo de esta investigación, se presenta un total de siete artículos aceptados y publicados
en revistas internacionales.
Tabla 18. Productos académicos logrados.
Referencia Producto Academico Tipo de producto Academico
(Mejia, & Peralta, 2016) Identificando Nuevas Funcionalidades de
Seguridad para Redes WLAN a través de los IPDS
Jezreel Mejía Miranda, Faleg A Peralta Martinez Centro de Investigación en Matemáticas
(CIMAT, A.C.)
Zacatecas, México [email protected]
Artículo Publicado
(Mejia, & Peralta, 2016) Identificando Nuevas Funcionalidades de
Seguridad Para Redes WLAN a través de los IPDS
Faleg A. Peralta, Jezreel Mejía
Centro de Investigación en Matemáticas (CIMAT, A.C.),
Monitoreo de Seguridad en la Red
Av. Universidad no. 222, 98068, Zacatecas, México
[email protected], [email protected]
Poster Presentado
(Mejia, & Peralta, 2017) Sistemas de Próxima Generación- Comparativa de Software Comercial y de Software Libre Basada
en la
Seguridad de los IDPS Jezreel Mejía Miranda, Faleg A Peralta Martinez
Centro de Investigación en Matemáticas
(CIMAT, A.C.) Zacatecas, México
Artículo Publicado
76
Referencias
[1] C. Study, A. S. Ashoor, and P. S. Gore, “Difference between Intrusion Detection
System (IDS) and Intrusion Prevention System (IPS),” vol. 2, no. 7, pp. 1–3, 2011.
[2] J. Dai and H. Miao, “D_DIPS: An intrusion prevention system for database security,”
Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes
Bioinformatics), vol. 3783 LNCS, pp. 481–490, 2005.
[3] H. Jin, Z. L. Yang, J. H. Sun, X. P. Tu, and Z. F. Han, “CIPS: Coordinated intrusion
prevention system,” Inf. Netw. Converg. Broadband Mob. Netw., vol. 3391, pp. 89–
98, 2005.
[4] L. Configuracion, R. Acciones, A. C. L. Amenaza, T. C. P. Analizar, C. Adaptive, S.
Appliance, F. Asa, M. Robertson, and C. Tac, “Funciones y configuración de la
detección de la amenaza ASA.”
[5] Intrusion Detection Systems with Snort Advanced IDS Techniques Using Snort ,
Apache , MySQL , PHP , and ACID B RUCE P ERENS ’ O PEN S OURCE S ERIES.
[6] I. P. S. Using and O. Source, “Interested in learning SANS Institute InfoSec Reading
Room A Design for Building an IPS Using Open Source In tu ho ll r igh.”
[7] D. dath Padmashani R, Shiju Sathyadevan, “BSnort IPS,” pp. 46–51, 2012.
[8] S. V Athawale and D. N. Chaudhari, “Towards effective Client-Server based Advent
Intrusion Prevention system for WLAN,” 2015.
[9] W. U. Ids, “Intrusion Detection and Prevention Systems,” pp. 225–243.
[10] S. E. Group, “Guidelines for performing Systematic Literature Reviews in Software
Engineering,” 2007.
77
[11] M. Çal, “Benefits of the Virtualization Technologies with Intrusion Detection and
Prevention Systems,” 2012.
[12] S. N. Dhage, B. B. Meshram, R. Rawat, S. Padawe, M. Paingaokar, and A. Misra,
“Intrusion Detection System in Cloud Computing Environment,” no. Icwet, pp. 235–
239, 2011.
[13] S. B. Vanjale and M. T. Scholar, “Wireless LAN Intrusion Detection and Prevention
System for Malicious Access Point,” pp. 2–5.
[14] Z. Wu, D. Xiao, H. Xu, X. Peng, and X. Zhuang, “Virtual Inline : A Technique of
Combining IDS and IPS Together in Response Intrusion,” 2009.
[15] V. Sekar, R. Krishnaswamy, A. Gupta, and M. K. Reiter, “Network-Wide Deployment
of Intrusion Detection and Prevention Systems.”.
[16] S. Chakrabarti, “Study of Snort-Based IDS,” no. Icwet, pp. 43–47, 2010.
[17] G. R. Kumar, “Intrusion Detection Using Text Processing Techniques - A Recent
Survey.”
[18] A. Le, H. Le, P. Dinh, and N. C. Tran, “Flexible Network-based Intrusion Detection
and Prevention System on Software-defined Networks,” 2015.
[19] RFC3882, http://www.rfc-editor.org/rfc/rfc3882.txt, 2008
[20] F. Yan, S. F. Tian, C. P. Mu, “Study and Design a Risk Based Automated Intrusion
Response System”, Network Security Technology and Application, Vol. 10, 2006, pp.
25-27.
[21] Top Layer Networks Inc., “How to Properly Evaluate Network Intrusion Prevention
Systems (IPS)”, http:// www.corero.com, 2005.
[22] Honeynet, Project, http://www.honeynet.org/, 2008.
[23] Neminath Hubballi and Vinoth Suryanarayanan. 2014. Review: False alarm
minimization techniques in signature-based intrusion detection systems: A survey.
Comput. Commun. 49 (August 2014), 1-17.
[24] H. Tang, H. Zhang, and X. Ma, “Proceedings of the International Conference on
Information Engineering and Applications (IEA) 2012,” Lect. Notes Electr. Eng.,
vol.218, no. VOL. 3, pp. 439–447, 2013.
[25] S. Acharya,M. Abliz, B.Mills, T. F. Znati, J.Wang, Z. Ge, and A. Greenberg.
OPTWALL: A Traffic-Aware Hierarchical Firewall Optimization. In Proc. NDSS,
2007.
78
[26] V. T. Lam,M.Mitzenmacher, and G. Varghese. Carousel: Scalable Logging for
Intrusion Prevention Systems. In Proc. NSDI, 2010.
[27] Sandeep Vanjale, Sandip Patil, Dr. P.B.Mane, “Wireless LAN Intrusion Detection
System (WLIDS) for Malicious Access Point:” Goa Conference IRAJ, and 13 July
2014.
[28] Cisco NetInvaders http://www.cisco.com/web/fw/tools/net_invaders/install.html, 2014.
79
Anexos
A. Creación de Reglas Snort
Como ya lo hemos visto las reglas de Snort son flexibles y potentes, estas se basan en una serie
de normas, la cuales nos servirán para poder crearlas a mano o en su defecto descárgalas de
internet, básicamente existe un sitio dedicado exclusivamente a la generación y obtención estos
ficheros; www.snort.org es la página oficial del Snort, en el podremos encontrar un conjunto
de reglas bastante complejo para la detección de tráfico indeseable dentro de la red.
En esta sección pretendemos entender la forma correcta de crear estas reglas, además de
conocer las guías que debemos seguir para su creación:
• Descripción de cada regla
• Cabecera
• Opciones
• Uso de preprocesadores.
A continuación, veremos la forma correcta de escritura de una regla Snort.
i. Forma de Escritura
La mayoría de las reglas de Snort están escritas en una sola línea ya que así era requerido
en las versiones anteriores, hoy en día, no es necesario, pero en caso de requerir más de una
línea se deberá usar el carácter de escape (\), como se muestra en el siguiente ejemplo:
• alert tcp any 110 -> (content: “filename=\”TOMOFONICA.TXT.vbs\””;\ nocase; msg: “Virus Telefonica”;)
ii. Forma de Escritura
80
La sección de la cabecera contiene la acción de la regla que desempeñara, específicamente
en ella encontramos el protocolo, IP, máscara de red, puerto origen, puerto destino y destino
del paquete o dirección de la operación. Ordenándolos quedarían de la siguiente manera:
• Acción
• Protocolos involucrados
• Direcciones IP de origen
• Direcciones IP de destino
• Números de puerto.
• Dirección de la operación.
iii. Opciones
Dentro de la sección opciones encontramos que contiene los mensajes y la información
necesaria para la toma de decisiones, la cuales son llevadas por parte de la alerta en forma de
opciones; esta sección debe ir entre paréntesis no importando cual se encuentre en primera
posición:
• Mensaje.
• Opciones de decisión.
• Sid.
iv. Jerarquización
Existen 3 tipos de variables que pueden ser definidas en Snort (var, portvar, ipvar); las
variables son simples sustituciones de valores, estas variables se definen en el archivo
etc/snort.conf:
• var RULES_PATH rules/
• portvar MY_PORTS [22,80,1024:1050]
• ipvar MY_NET [192.168.1.0/24,10.1.1.0/24]
Con lo cual una regla usando variables quedaría de la siguiente forma:
• alert tcp any any -> $MY_NET any (flags: S; msg “SYN Packet”;)
v. Acciones
Ya hemos revisado anteriormente la primera parte de la cabecera, la cual es la acción de la regla;
esta sección contiene información que define el quien, donde y que de un paquete. La acción de la
regla le indica a SNORT que maniobra debe realizar cuando detecte un paquete que coincida con el
criterio de la regla, las cuales pueden ser:
• Alert. - genera una alerta usando el método de seleccionado y lo almacena el log.
• Log. - archiva el log del paquete.
• Pass. - ignora el paquete.
• Activate. - activa la alerta y llama a una regla dinámica.
81
• Dynamic. - cuando es llamada por una regla activate se pone en funcionamiento.
Ejemplo:
• pass ip 10.x.x.0/22 any -> any any (content: “Open Port * 80”; msg: \ “Open Port 80.”; )
• alert tcp any 110 -> (content: “filename=\”TOMOFONICA.TXT.vbs\””; \ nocase; msg: “Virus Telefonica”;)
De la misma manera se pueden, se pueden definir los propios tipos de reglas y asociarlos a uno
o más conexiones con ellos, podemos usar los tipos de regla como acciones dentro de las reglas
de Snort; Veamos como ejemplo:
• RULE TYPE SUSPICIUS
• TYPE LOG OUTPUT
• LOG_TCPDUMP: SUSPICIUS.LOG
En este ejemplo se crea una regla log para el usuario SYSLOG dentro de una Base de Datos
MySQL;
• RULETYPE REBALERTOUTPUT ALERT_SYSLOG: LOG_AUTH LOG_ALERT OUTPUT DATABASE: LOG, MYSQL,
USER = SNORT DBNAME=SNORT HOST=LOCALHOST.
vi. Protocolos Dentro de una regla, el protocolo es el segundo campo, Snort puede trabajar con diferentes
protocolos, los cuales normalmente analizan comportamiento:
• SUSPICAZ_TCP
• UDP
• ICMP
• IP
Además, nuevos protocolos se han ido agregando, tal es el caso de: ARP, IGRP, GRE,
OSPF, RYP, IPX, entre otros.
vii. Direcciones IP
Complementado la escritura de la regla Snort, se incluye la dirección IP, cabe destacar que
algunas palabras clave pueden ser usadas dentro de la definición de la dirección. Cuando
realizamos la configuración de Snort, proporcionamos el CIRD Block el cual indica la máscara
net que debe ser aplicada a las direcciones de las reglas. Un CIRD MASCARA de 24 indica
una clase C, uno CIRD MASCARA 16 indica una clase B y un CIRD Mascara 4 indica una
dirección IP de una máquina. Veamos cómo ejemplo lo siguiente:
• CIRD /24 clase C para un rango de Dirección: 192.168.1.1 – 192.168.1.225
Se pueden hacer excepciones dentro de la lista de direcciones agregando el operador “!”; como
ejemplo tenemos una alerta de trafico de salidas de la red local, utilizando el operador descrito.
• ALERT TCP! 192.168.1.0/24 ANY-> 192.168.1.0/24 111 (CONTENT “l 00 01 86 a 51”; msg:” external mountd Access” ;)
82
Otra forma es especificar las listas de direcciones IP; para hacer esto la lista debe estar
encerrada en paréntesis, separa por comas y no deben incluir espacios entre las direcciones:
• ALERT TCP! (192.168.1.0/24) 10.1.1.ANY -> (192.168.1.0/24, 10.1.1.0/24) 111 (CONTENT:” l 00018625 l” ;) MSK:”
EXTERNAL MOUNTD ACCESS” ;)
viii. Numero de Puerto.
El número se puede incluir de diversas maneras, puede ser especificado o incluir rangos;
algunos de los puertos más utilizados son:
• 111 puerto mapa
• 23 para TELNET
• 80 para http.
Para agregar un rango de puertos se utiliza el operador “l” seguido de número máximo del
rango como se ve en el ejemplo:
• LOG UDP ANY ANY -> 192.168.1.0/24 l: 1024 LOG UDP.
El tráfico viene de algún lugar, a algún puerto de destino, recorriendo los puertos 1 a 1024;
• LOG TCP ANY :1024-> 192.168.1.0/24 500
Puertos privilegiados menor o igual a 1024, los cuales van a puertos mayores o iguales a 500;
ix. Análisis de Ejemplo de regla Snort.
El siguiente ejemplo muestra el análisis de una regla Snort, específicamente un escaneo NMAP
de tipo TCP Ping:
• alert tcp $EXTERNAL_NET any -> $HOME_NET any / (msg:” Escaneo ping con nmap”;flags:A;ack:0; /
reference:arachnids,28;classtype:attempted-recon; sid:628;/ rev:1;)
Veamos un análisis más a fondo de la regla y separemos cada parte de la cadena de texto en su
sección perteneciente; En primer lugar, encontramos dentro de la sección cabecera observamos
lo siguiente:
• Acción de la regla: alert
• Protocolo: tcp
• Dirección IP origen: $EXTERNAL_NET (toda la red)
• Puerto IP origen: any (cualquiera)
• Dirección IP destino: $HOME_NET (toda nuestra red)
• Puerto IP destino: any (cualquiera)
• Dirección de la operación: -> (puede ser ->, <-,)
En la segunda parte encontramos dentro de la sección opciones lo siguiente:
83
• Mensaje: msg
• Opciones: flags: A;ack:0; reference:arachnids..(1);
Donde:
i. flags:A Establece el contenido de los flags o banderas TCP, en este caso ACK
(puede tener varios valores y operadores que veremos más adelante).
ii. ack:0 Caso particular para valor ACK=0, es el valor que pone nmap para TCP
ping scan.
iii. reference: arachnids, 28 Referencia a un Advisory, alerta tipo Bugtrac, etc.
iv. classtype: attempted-recon Categoría de la alerta según unos niveles predefinidos
y prioridades (veremos más adelante las categorías).
v. sid: 628 Identificación única para esta regla Snort según unos tramos
determinados.
vi. rev: 1 Identificación de la revisión o versión de la regla.
Dentro del manual oficial de Snort, se encuentra el siguiente ejemplo, el cual mediante el acceso al
demonio de administración mountd de UNIX, tiene diversos problemas de desbordamiento de memoria
intermedia, que permiten a un atacante remoto obtener privilegios de administrador en los sistemas
vulnerables:
• alert tcp any any -> 192.168.1.0/24 111 (content:”|00 01 86 a5|”; msg: “mountd access”;)
La opción “content”, es una de las opciones más importantes dentro de Snort, ya que nos permite la
búsqueda de contenidos dentro del campo datos del paquete IP. Se puede añadir “nocase” para que la
búsqueda de los datos no sea sensible a las mayúsculas. Estos datos pueden estar en formato
hexadecimal, texto plano o binario.
x. Instalación.
Como ya hemos visto, la creación de reglas Snort puede realizarse mediante cualquier
procesador de texto plano, este archivo debe de guardarse con la extensión rule (Snort Rule).
Debemos crear un fichero que este personalizado para almacenar nuestras reglas creadas (lo
importante de este fichero de texto plano son las reglas, la marca # se utiliza como comentarios).
Estos ficheros creados con la extensión .rule se debe almacenar en el directorio raíz de Snort
(por defecto):
# (C) Copyright 2001,2002, Martin Roesch, Brian Caswell, et al. All rights reserved.
# $Id: virus.rules,v 1.16 2002/08/18 20:28:43 cazz Exp $
#———— VIRUS RULES ————
# NOTE: These rules are NOT being actively maintained.
# If you would like to MAINTAIN these rules, e-mail
alert tcp any 110 -> any any (msg:”Virus – Possible pif Worm”; content: “.pif”; nocase; sid:721; classtype:misc-activity; rev:3;)
84
B. Creación de Reglas Snort
Durante el año de 1998, una nueva tecnología de Detección de Intrusión fue desarrollada por
Martin Roesch, a la cual le puso el sobrenombre de “IDS de peso ligero” comparándolo con los
IDS (Sistemas de Detección de Intrusos) existentes en la época. A lo largo de los años Snort ha
adquirido madurez, destaca la diversidad tecnológica que brinda dentro de su configuración
estándar de IDS, la facilidad y la amplia comunidad las cuales dan mantenimiento a las reglas
de detección las hace más flexibles y exactas, haciendo de Snort una herramienta óptima para
la prevención de Intrusos.
i. Definición de Snort
Snort es un sistema de Detección de Intrusos para redes informáticas de código abierto, el cual
es capaz de analizar la ejecución del tráfico en tiempo real, así como de los registros de paquetes
en las direcciones IP de la red; entre sus funciones está el análisis de protocolos, contenido
búsqueda/acoplamiento, y puede ser usado para detectar una variedad de ataque de pruebas
como lo son las pruebas SMB, exploraciones de puerto, ataques CGI, etc. Así mismo, Snort
utiliza reglas flexibles para el descubrimiento de tráfico que pasa o recoge, un motor de
detección que utiliza una arquitectura plug-in modular.
Snort tiene la capacidad de realizar alertas en tiempo real, incorporando mecanismo de alerta
para syslog, por archivo específico de usuario, por socket UNIX, o mensajes WINPopUp para
los clientes Windows a través de SMB Samba.
Existen 3 formas de uso principales de Snort:
• Como herramienta de análisis de paquetes útil para la eliminación de errores de la red.
• Como succionador de paquetes TCP/UDP.
• Como un sistema completo, autoabastecido para la Detección de las Intrusiones de red.
ii. Arquitectura
El conocimiento de los componentes de Snort es de suma importancia, debido a que este utiliza
distintos conectores de software, para personalizar su implementación, y aunque Snort puede
desarrollar muchas tareas sencillas se hace indispensable el entender su arquitectura, ya que
tendremos una visión más clara de lo que realiza y la forma en como lo realiza. Básicamente
se encuentra conformada por cuatro componentes básicos:
• Decodificador de paquetes
• Preprocesador
• Motor de detección
• Subsistema de alerta y log
85
La Figura 53 nos da un mejor modelo de la arquitectura de Snort a gran escala de una forma
simple, podemos compararla con un clasificador de monedas mecánico, la toma de las monedas
(paquetes de la red que se está escuchando), enviándolas a través de un canal inclinado para
determinar si son monedas y como deben ser clasificadas (Pre procesadas), después ordena las
monedas de acuerdo a su tipo. Esto se realiza para el almacenamiento de monedas de diferente
tipo (el IDS detecta los paquetes que se van separando dependiendo del contenido y de su
riesgo), y finalmente el administrador toma la decisión de qué hacer con las monedas
(usarlas/almacenarlas) registrando la información obtenida.
Figura 53. Arquitectura de Snort.
iii. Visor de Paquetes
El decodificador o visor de paquetes permite a una aplicación o dispositivo físico escuchar de
formar disimulada el tráfico de la red, teniendo como objetivo la obtención de datos del exterior,
siendo los ojos del IDS dentro de la red; soportan una gran variedad de protocolos de enlace
bajo el esquema TCP/IP, tales como: Ethernet, ICMP, UDP, TCP, entre otros; siendo el
encargado de organizar los paquetes conforme van pasando por la pila de protocolos. En cada
subrutina, el codificar ordena de manera distinta los paquetes, formando una estructura de datos
86
basada en punteros por encima del tráfico real capturado. Esta estructura de datos será la que
guíe al motor de análisis para realizar posteriormente el análisis (Figura 54).
Figura 54. Visor de Paquetes de Snort.
iv. Preprocesador
El preprocesador toma por entradas los datos en bruto del entorno exterior al IDS, el IDS
verifica y compara contra ciertos plugins para pasarlos a un formato común que entiendan el
resto de los componentes, proporcionando los eventos al resto de los mismo; es decir cuando
algún paquete ya ha sido clasificado con algún tipo de conducta, pasa al motor de detección en
tiempo real; una de las características más importantes para los IDS es el preprocesador, debido
a que se pueden habilitar o deshabilitar plugins a criterio del administrador, o según convengan
a nuestras necesidades, conforme los vaya requiriendo en el nivel del preprocesador (Figura
55).
Figura 55. Preprocesador de Snort.
Paquetes
Preprocesador
Plug-indeCifradoHTTP
Habilitar/DeshabilitarPlug-In
MotordeDetención
87
v. Motor de Detección
El núcleo del IDS es su motor de detección, gracias a su inferencia, será capaz de discernir la
relevancia de los eventos recibidos; Además toma los datos que vienen del preprocesador y
debido a que Snort se basa en reglas, mantiene sus reglas de detección en una lista
bidimensional. A esta lista base se le denomina cabecera de cadena (Chain Header) y la que
deriva de esta se llama opción de cadena (chain Option). Cuando llega un paquete al motor,
este busca dentro de la cabecera, de izquierda a derecha la primera coincidencia, después
buscara en la opción de cadena, si el paquete cumple las opciones especificadas (en caso de
que aparezca alguna coincidencia) no seguirá buscando y tomara las acciones correspondientes;
en caso contrario buscara en el siguiente nodo de cabecera (Figura 56).
Figura 56. Motor de Detección de snort.
Como ya lo habíamos mencionado antes el motor de búsqueda permite la inserción de módulos
plug-in, extendiendo las capacidades que pueden utilizarse principalmente para:
I. Hacer búsquedas más complicadas dentro de los paquetes o flujos TCP cuando la
sintaxis de las reglas no lo permita (preprocesadores), y dentro de los más utilizados
son:
a. Escaneo de puertos.
b. Desfragmentador.
c. Reconstructor de Flujo TCP / Spade.
d. Detección de anomalías (muy primitivo).
II. Define los modos de alerta y logs no pertenecientes a Snort:
a. BD (MySql, Oracle)
b. SNMP traps.
c. CSV
d. XML.
Motordedetección Regla¿Existe
coincidencia?
RegistrodeAlerta(Sicoincide)
Descarta
SiNo
Paquetes
88
vi. Subsistema de Registro (Log) y alertas.
Después de que los paquetes pasaron por el motor de detección llegan al subsistema de Alertas
y Registros. Dentro de este subsistema existen 3 tipos de Log y cuatro de alerta. Estas pueden
ser activadas para almacenar y proporcionar un mayor rendimiento. Las opciones de registro
pueden ser activadas para almacenar paquetes en forma decodificada y entendible para el ser
humano; este permite un análisis rápido y el TCPDUMP es más fácil de almacenar y
proporciona un mayor rendimiento. Las alertas se pueden realizar en ficheros de texto mediante
dos formatos distintos: rápido y completo;
El componente de alertas en forma similar al motor de detección y al preprocesador utiliza
plug-in para enviar alertas al BD a través de protocolos de red. Snort dispone de un mecanismo
que optimiza considerablemente su rendimiento. Puesto que normalmente se requiere de un
sistema a back end potente (BD) para hacer correlaciones de ataques, las escrituras de las
bitácoras (logs) suelen ser bastante robustos, ya que, al ser un proceso monolítico, mientras
realiza la escritura en la BD no puede realizar otras tareas, como procesar el tráfico de entrada.
89
C. Análisis de Funcionalidades EasyIDS
EasyIDS es una distribución pre compilada basada en CentOS que permite instalar y
administrar fácilmente el sistema de detección de intrusos en Red Snort y analizar su
comportamiento a través del Frontend BASE. Esta distribución es libre y puede obtenerse de
su página oficial http://www.skynet-solutions.net/easyids/, Consta de una imagen ISO que
además de lo anteriormente comentado (SO CentOs), incorpora varias herramientas muy útiles,
como es el caso de los monitores de red, del sistema, nmap, entre otros. (Figura 57).
Figura 57. Consola de administración EasyIDS
i. Instalación
Debemos realizar los siguientes pasos para poder instalar EasyIDS:
1. Debemos obtener la Imagen ISO de la página oficial
http://sourceforge.net/projects/easyids/files/ .
2. Dentro de la maquina asignada a la instalación (ya sea de forma Virtual o Física) iniciar
el arranque desde la ISO, la Figura 58 muestra la pantalla de inicio, debemos pulsar
enter.
90
Figura 58. Pantalla principal de instalación de EasyIDS.
3. En la siguiente ventana debemos seleccionar el Idioma y la zona horaria del sistema,
para después pasar a la siguiente pantalla en la cual debemos introducir la contraseña
del administrador del sistema como se aprecia en la Figura 59.
Figura 59. Pantalla de introducción de contraseña para el administrador.
91
4. Una vez que hemos agregado la contraseña del administrador inicia el proceso de
instalación don se comprueban dependencias y se procede a la instalación del SO
(Figura 60).
Figura 60. Instalación en proceso de la herramienta.
5. Una vez que es finalidad la instalación, el sistema se reiniciara y una vez que vuelve a
iniciar aparcera el Shell del sistema como se muestra en la Figura 61. ahora ya podremos
comenzar a utilizar EasyIDS.
Figura 61. Login de aplicación por medio de la consola.
6. Para poder acceder al sistema debemos introducir la contraseña que previamente hemos
asignado en la instalación al administrador (Figura 62).
92
Figura 62. Acceso correcto a la aplicación.
7. Para acceder a la interfaz web de EasyIDS, debemos dirigirnos a un navegador y escribir
su dirección IP (depende de la configuración que hallamos realizado), una vez que
ingresemos el URL dentro del navegador se nos solicitara introducir el usuario y la
contraseña de acceso. Los valores por defecto para el acceso al sistema son:
usuario:admin, password: password; al ser la primera vez que accede al sistema, debe
aceptar los términos de la licencia y cambiar la contraseña por defecto para finalmente
mostrar la página de inicio de EasyIDS (Figura 63).
Figura 63.Pantalla principal de administración de EasyIDS.
93
i. Funcionalidades
Tal y como pudimos observar en la Figura 63 la página de inicio permite administrar
completamente EasyIDS a través de su interfaz web. Podemos encontrar las siguientes opciones
dentro del Menú de Administración:
• Analysis (Análisis). - Junto a Settings (configuraciones) es la sección más importante
de EasyIDS. Permite analizar el comportamiento de Snort a través de la interfaz BASE
como se muestra en la Figura 64 y así monitorear la actividad del sistema; Además,
también podemos observar las alertas generadas dentro del sistema (Figura 64), entre
otras opciones como la salida de las herramientas arpwatch (Figura 65), y ntop (Figura
66).
Figura 64. BASE muestra reportes de alertas, tráfico, sensores y otros datos interesantes de
acuerdo a la configuración que realizamos.
Figura 65. Envió de mails, cambio de interface eths, y deshabilitar los Bogons (El filtrado de
Bogons es la práctica de filtrar direcciones IP falsas)
94
Figura 66. ntop despliega diferentes tipos de estadísticas por mencionar algunas: tráfico, Uso de
la Red, Host, entre otros.
• Graphs (Gráficos). - En esta sección podemos observar los gráficos de rendimiento
relacionados con la red (Figura 67), del sistema (Figura 68) y de Snort (Figura 69).
Figura 67. Pantalla de gráficos de EasyIDS.
95
Figura 68. Pantalla de sistema de EasyIDS.
Figura 69. Pantalla de Alertas.
• Settings (Configuraciones). - Dentro de las opciones más importantes dentro de
EasyIDS están los Settings, ya que permiten establecer la configuración de los
elementos más importantes del sistema (arpwatch, barnyard, EasyIDS, stop, snort y
stunnel) Figura 70 y Figura 71.
96
Figura 70. Pantalla de configuración dentro de EasyIDS.
Figura 71. Del mismo modo pueden agregarse o retirarse configuraciones mediante scripts.
• Status (Estatus). - Permite comprobar el estado del sistema y de los servicios que se
están ejecutando en él, para tomar acciones correctivas y preventivas (figura 72).
Figura 72. Pantalla estatus de nuestro Sensor.
97
• Tools (Herramientas). - Para facilitar las tareas de administración, en la sección tools
puede encontrar la herramienta nmap para escanear equipos y logviwer para examinar
los archivos de registro del sistema (archivos logs). En la Figura 73, puede ver los
diferentes archivos de registro que puede examinar con logviewer.
Figura 73. Pantalla de herramientas.
• Thanks (Gracías). En esta sección se puede ver información de los proyectos que
integran EasyIDS (p.ej., snort, CentOS, BASE).
98
D. Análisis de Funcionalidades Cisco
Sourcefire
i. Modelo OSI
El modelo OSI (Open Systems Interconnection) es una norma universal lanzada en el año 1984
para protocolos de comunicación. Este modelo fue propuesto por el comité ISO este esquema
fue creado para unificar las incompatibilidades entre redes que se tenían en aquellos tiempos.
En la actualidad este esquema es más utilizado para la enseñanza de las redes, con el objetivo
de mostrar cómo pueden estructurarse los protocolos de comunicación. Este modelo consta de
7 capas: Capa física, Capa de enlace de datos, Capa de red, Capa de transporte, Capa de sesión,
Capa de presentación, Capa de aplicación (Figura 74).
Figura 74. División del modelo OSI en Capas.
ii. Modelo TCP/IP
El modelo TCP/IP (Trasmission Control Protocol / Internet Protocol) es un conjunto de
protocolos que permiten la comunicación entre ordenadores con el fin de intercambiar datos.
El nombre de este modelo fue dado debido a la unión de dos de sus protocolos más importantes;
TCP/IP es un conjunto de reglas de comunicación para internet basándose en brindar una
dirección IP a cada equipo para poder enrutar datos. En un principio este modelo fue creado
con fines militares, pero hoy en día es la base de las comunicaciones en la red de redes; consta
de 4 capas: Aplicación, Transporte, Internet, Acceso a la Red (Figura 75).
99
Figura 75. Modelo TCP/ IP y sus capas.
iii. Modelo TCP/IP
La Figura 76 nos permite comprender y tener una mejor visión de las capas, su funcionamiento
y principales diferencias de forma sencilla y a gran escala.
Figura 76. Comparación entre el Modelo OSI vs el modelo TCP/IP.
iv. Terminología
I. Firewall
Los firewalls tradicionales funcionan en las capas de red / transporte permitiendo o bloqueando
el tráfico basándose en criterios como una dirección IP y / o un puerto. Mucho más que un
enrutador con una lista de acceso, un firewall nos ofrece muchas más características avanzadas,
100
por ejemplo, la capacidad de garantizar que sólo los paquetes asociados con una conexión con
estado se les permiten pasar.
II. Sistema de prevención de intrusiones o sistema de
protección contra intrusiones (IPS / Intrusion
Prevention System or Intrusion Protection System)
Un IPS es un dispositivo insertado (entre otros componentes de la red) en una configuración en
línea. Esta colocación obliga a los paquetes a pasar a través del IPS, permitiéndole bloquear
cualquier tráfico considerado malintencionado. Un IPS es capaz de realizar una inspección de
paquetes profunda, lo que significa que examina la parte de los datos de los paquetes, no sólo
cabeceras de paquetes como lo hace el Firewall. Además, la mayoría de los sistemas IPS
utilizan reglas o firmas (que buscan condiciones específicas en los paquetes) para identificar el
comportamiento malicioso conocido. Cuando el tráfico que coincida con la firma llega, el IPS
puede generar una alerta, dejar caer el paquete ofensivo, o ambos.
III. IPS de próxima generación (NGIPS / Next-
Generation IPS)
Un dispositivo NGIPS proporciona todas las funciones IPS tradicionales, pero incluye
potencias adicionales, como la capacidad de permitir / bloquear el tráfico en función de la
aplicación específica o la información del usuario. Este nivel de control ampliado proporciona
más flexibilidad para restringir aplicaciones específicas, independientemente de su dirección
IP o puerto. Un NGIPS también le da control sobre exactamente quién puede o no puede
acceder a aplicaciones como su sitio favorito de redes sociales.
IV. Firewall de última generación (NGFW / Next-
Generation Firewall)
Este dispositivo ofrece todas las características habituales que un firewall clásico hace, pero
agrega las características de aplicación / control de usuario de un NGIPS en la mezcla,
armándolo con un cortafuego y NGIPS en un solo paquete.
V. Diferencias entre NGIPS y NGFW
Prácticamente hablando, la línea entre un NGIPS y un NGFW es bastante fina. La principal
diferencia es la capa de red en particular donde se ejecutan los dos dispositivos. NGIPS por lo
general funciona como un "golpe en el cable", es decir, los paquetes que entran en una interfaz
de un par de interfaz en línea siempre salen de la otra interfaz. El dispositivo no tiene
direcciones IP asignadas a las interfaces de detección y tampoco crea una tabla CAM de
direcciones MAC. Simplemente inspecciona paquetes en su camino. Alternativamente, el
101
NGFW desempeña el papel de un firewall tradicional y añade características NGIPS. Las
interfaces tienen direcciones IP asignadas y el dispositivo realiza el enrutamiento de tráfico de
Capa 3.
Tabla 19. Nueva terminología asignada por CISCO a sus productos.
Terminología
Anterior Nueva
Sourcefire CISCO
Sourcefire Defense Center FireSIGHT Management Center (FMC or FSMC)
Sensor Device
Defense Center (DC) FireSIGHT Management Center
Sourcefire 3D system FireSIGHT System
Sourcefire Managed Device Managed Device
VI. Appliance (Artefacto)
Es el término general utilizado para cualquiera de las máquinas físicas o virtuales que
componen el sistema FireSIGHT. Esto incluye el Centro de Defensa, así como los dispositivos
de detección (Figura 77).
Figura 77. Ejemplo de artefacto IPDS de CISCO.
VII. Device (Dispositivo)
Es un dispositivo de detección. Éstos contienen las interfaces de detección reales e inspeccionan
el tráfico de la red. Aunque el Centro de Defensa es un dispositivo, no es un dispositivo.
Algunos tipos de políticas, como el Control de acceso, Prevención de intrusiones y
descubrimiento de red, se aplican sólo a dispositivos (Figura 78).
102
Figura 78. Ejemplo de Dispositivo según la terminología de CISCO.
VIII. Throughput
Al volumen de trabajo o de información neto que fluye a través de un sistema, como puede ser
una red de computadoras. Es definido como la velocidad real de transporte de datos a través de
una red telemática, el cual normalmente se mide en Mbit/s y siempre será inferior al ancho de
banda o bandwidth. La Tabla 19 nos da una mejor idea acerca de la deficinión.
Tabla 20. *Los 7115 y 7125 utilizan interfaces SFP y no admiten bypass; Estos están diseñados
para despliegues de firewall / conmutador donde no se desee bypass. ** Estos modelos son
dispositivos apilados.
Dispositivos
Model IPS Throughput
Virtual 150–200Mbps per core
7010 50Mbps
7020 100Mbps
7030 250Mbps
7110 500Mbps
7115* 750Mbps
7120 1Gbps
7125* 1.25Gbps
8120 2Gbps
8130 4Gbps
8140 6Gbps
8250 10Gbps
8260** 20Gbps
8270** 30Gbps
8290** 40Gbps
8350 15Gbps
8360** 30Gbps
8370** 45Gbps
8390** 60Gbps
103
IX. Centro de Defensa
Aunque el Centro de Defensa es el corazón del Sistema FireSIGHT, no realiza la detección por
sí mismo. Piense en ello de esta manera: si considera que los dispositivos son las abejas obreras
en el sistema, el Centro de Defensa es la reina. Casi toda la configuración del dispositivo se
realiza desde aquí, y todo el registro de alertas y eventos de los dispositivos se envía a ella
también. Esto significa que mientras realiza operaciones normales de día a día, sólo necesita
iniciar sesión en la interfaz de usuario basada en la Web del Centro de Defensa. La Tabla 20
brinda un mejor detalle de los diversos centros de defensas.
Tabla 21. Descripción general de los centros de defensa CISCO.
Centro de
Defensa
Modelo Máximo de Dispositivos Host/Usuario IPS Eventos
(Almacenamiento)
DC750 10 2,000 30 Million
DC1500 35 50,000 50 Million
DC3500 150 300,000 150 Million
Virtual DC 25 50,000 10 Million
El sistema FireSIGHT tiene una serie de características de detección y análisis, y cada uno de
los modelos de dispositivos físicos es capaz de realizar cualquiera o todos ellos. Para habilitar
una característica específica, debe instalar la licencia adecuada en el Centro de Defensa; La
licencia se puede asignar a los dispositivos.
104
E. Licenciamiento
Cada tipo de licencia está disponible en una versión de suscripción y una versión perpetua. Las
licencias de suscripción son válidas para un período de tiempo determinado, y se pueden
comprar licencias de un solo año o de varios años. El período de licencia válido se codifica en
la clave de licencia. Una vez instalada, la clave de licencia habilitará la característica apropiada
entre las fechas de inicio y vencimiento (actualmente, las licencias de Malware y Filtrado de
URL pertenecen a esta categoría).
Una licencia perpetua no tiene fecha de inicio o finalización, y predeciblemente, una vez
instalada, esta licencia habilitará la característica apropiada indefinidamente.
• FireSIGHT. - Esta licencia se incluye con el Centro de Defensa y establece el límite
superior del número de hosts IP y usuarios que se pueden recopilar. El número de
licencias se fija en función del modelo DC y no se puede actualizar.
• Protect. - Esta es su licencia básica de nivel de entrada para un dispositivo que ha sido
asignado para convertirse en un NGIPS. Permite la detección / prevención de
intrusiones, el control de archivos y el filtrado de inteligencia de seguridad.
• Control. - La licencia de Control habilita las funciones NGFW, como el control de
usuarios y aplicaciones, así como interfaces conmutadas y enrutadas. Esta licencia
también se requiere para agrupar o apilar dispositivos compatibles.
• URL Filtering. -El filtrado de URL decreta permitir / bloquear sitios web basados en
su URL, categoría o reputación. La información como categoría y relevancia
empresarial se actualiza en el Centro de Defensa a través de una conexión en la nube.
• Advanced Malware Protection. - La Protección Avanzada contra Malware (AMP, por
sus siglas en inglés) proporciona análisis de búsqueda de malware basado en la nube y
análisis de sandbox, incluyendo trayectoria de archivos y seguimiento a través de la red.
• VPN. - La licencia VPN permite capacidades VPN de sitio a sitio entre dispositivos y
puede utilizarse para crear un túnel seguro en una ubicación de oficina remota sin tener
que instalar un hardware VPN separado.
Tabla 22. Hay que tener en cuenta que, bajo el nuevo modelo de ventas de Cisco, las licencias
Protect y Control normalmente se incluyen con cualquier venta de dispositivos.
Licenciamiento
Tipo de Licencia Requerimiento
Protect N/A
Control Protect
URL Filtering Protect
Malware Protect
VPN Protect, Control
105
F. Licenciamiento
i. In-line IPS
El primer diseño que vamos a cubrir es probablemente el más común. El dispositivo se instala
cerca del perímetro de la red utilizando un conjunto de interfaces en línea. Esto significa que
los paquetes pasan en una interfaz, son procesados por las distintas directivas y luego salen a
través de una segunda interfaz. En este tipo de diseño, el dispositivo actúa como el "bache en
el cable" mencionado anteriormente, lo que significa que los otros dispositivos de red no son
realmente conscientes de su presencia. Hay que recordar que las interfaces de detección no
tienen direcciones IP; El dispositivo no genera una tabla de memoria de direcciones de
contenido (CAM) para asignar direcciones MAC de host a puertos. Se podría esperar esto si el
dispositivo funciona en la capa 2 como un interruptor. Sin embargo, el bache en el cable es más
como una conexión de capa 1 (física) entre las dos interfaces en línea. Los dispositivos IPS en
línea se implementan a menudo dentro del firewall de Internet o en otros puntos estratégicos
de la red (Figura 79).
Figura 79. IDPS en modo In-line.
Por definición, un IPS no es un cortafuegos-no realiza inspecciones con estado y típicamente
no permite / bloquea tráfico basado en el puerto o la dirección IP. Básicamente existe para
inspeccionar el tráfico y buscar el mal, por lo que todavía necesita un cortafuego real. Esto se
debe a que los firewalls manejan las funciones críticas de filtrar los puertos y protocolos de red
que se permiten dentro o fuera de su red.
Otra razón para esta colocación es porque la inspección del cortafuego es menos compleja que
la inspección profunda del paquete de IPS, que se traduce en costo su por megabit protegido
debe ser menor para el firewall que para el IPS. Así que debemos ser prudentes y poner esta
cara detección en el interior donde realmente pertenece. Por último, hay que considerar el
Network Address Translation (NAT) o proxies web.
El IPS inspecciona el tráfico iniciado tanto desde dentro como fuera de la red. Muchas de las
reglas de salida están diseñadas para detectar los resultados de una infección de malware, pero
el problema es correlacionar el evento con un host específico.
Si el IPS está fuera del firewall NAT o del proxy web, sólo tendrá una IP de origen único para
todos los eventos que se dispararán por el tráfico de salida. Si tienes un proxy web, podrías
referenciar la hora del evento IPS con el registro de proxy web para vincularlo a una IP interna
106
específica, pero a menudo es un proceso engorroso. Y si se trata de traducción NAT, es probable
que no tenga una manera de vincular el evento de nuevo a una dirección IP interna original en
absoluto.
i. Passive IPS
Como ya hemos mencionado, en modo pasivo, el IPS recibe una copia de los paquetes de un
puerto de span del switch o de la red. Los paquetes que ingresan al IPS son inspeccionados y,
si se consideran malintencionados, se genera una alerta. Una ventaja de este diseño es que no
afectará el rendimiento de su red, pero la desventaja es que sólo puede notificar de los ataques,
no puede detenerlos (Figura 80).
Figura 80. IDPS en Modo Passive.
107
G. Sourcefire Intrusion Prevention
System Policies
Un dispositivo Cisco FireSIGHT puede implementarse como un enrutador, un conmutador o
un firewall. Desde una perspectiva de detección de intrusiones, el efecto es similar a un IPS en
línea. Los paquetes pasan a través de un conmutador virtual o enrutador y son inspeccionados
antes de poder salir. En el mundo real, el despliegue del sistema FireSIGHT como un enrutador
/ conmutador / cortafuegos es poco común debido a que los conmutadores y enrutadores
orientados por el objetivo tienen más funciones y son más rápidos y más baratos que usar
FireSIGHT.
i. Policies (Politicas)
Consideremos las políticas como "configuraciones guardadas en la base de datos del Centro de
Defensa". Estas configuraciones controlan todos los aspectos de la operación y detección del
sistema en los dispositivos administrados. Y sepa que, con cada nueva característica agregada
al sistema, hay por lo menos una política para manejar esa característica asociada con ella.
ii. IPS Policy (Politicas IPS)
Esta política controla la configuración para la detección IPS. Si alguna vez ha utilizado o
investigado el IPS de Snort de código abierto, encontrará que la mayoría de los parámetros de
la directiva IPS se correlacionan directamente con una entrada en el snort.conf. En esta política,
configura las reglas específicas de Snort que desea habilitar, ya sean bloquear o simplemente
alertar, así como una mirada de opciones avanzadas para preprocesadores y otras opciones de
Snort.
iii. Network Discovery Policy (Política descubrimiento de
redes IPS)
Podemos ver esta política como una simple y sencilla política de establecimiento y cancelación
que controla el alcance de la detección de host y usuario para todos los dispositivos.
iv. File Policy (Política de Archivos)
Esta política controla el protocolo de aplicación, la dirección de transferencia, los tipos de
archivo y las acciones para la detección de archivos y programas maliciosos. Con él, se
especifica que un tipo determinado de tráfico de transferencia de archivos se registrará, se
inspeccionará para detectar malware o incluso se bloqueará. Por ejemplo, digamos que
108
deseamos impedir que los servidores web de su DMZ carguen archivos ejecutables de
Microsoft a través de HTTP. Podemos hacer esto y más a través de la política de archivos.
v. NAT Policy (Política NAT)
Previsiblemente, esta política configura la Traducción de direcciones de red (NAT). Soporta IP
estático, dinámico o IP dinámico y las reglas de puerto.
vi. Correlation Policy (Política de Correlación)
Una política utilizada junto con reglas de correlación para hacer alertas basadas en varios
criterios de evento. Digamos que desea recibir un correo electrónico cuando se detecta un
suceso IPS en uno de sus servidores críticos. En primer lugar, crearíamos una regla de
correlación para identificar la alerta IPS basada en criterios como la dirección IP de destino,
después agregaríamos la regla a una directiva de correlación, que definiría la acción a realizar
cuando se desencadena la regla. En este caso, la acción sería enviarle un correo electrónico.
vii. System Policy (Política de Sistema)
Política de sistema Esto controla una variedad de configuraciones de dispositivo como firewall
local, sincronización de tiempo, etc. La política del sistema se aplica a todos los dispositivos,
lo que significa que el Centro de Defensa y todos los dispositivos. Gran parte del tiempo, se
utiliza una política de sistema única para todos los dispositivos de una organización.
viii. Health Policy (Política de Salud)
Esta política establece límites de advertencia y críticos para varios parámetros de salud, como
espacio de disco y uso de la CPU. También puede activar o desactivar varios controles de salud
como desee su corazón.
109
H. Administración Del Sistema
FireSIGHT
El método principal para administrar el sistema FireSIGHT es a través de la interfaz web. El
acceso a la línea de comandos generalmente se reserva para la solución de problemas. La
mayoría de las tareas de administración sólo se pueden realizar dentro de la interfaz web como
se observa en la Figura 81.
Figura 81. Pantalla principal para la administración del CISCO FireSIGHT.
El sistema de menú es bastante sencillo, con una barra de menú principal superior y submenús
a continuación. Pasando el ratón sobre el menú superior aparecerá cualquier elemento del
submenú (Tabla 22, Figura 82).
Tabla 23. Descripción del menú CISCO FireSIGHT.
Menú principal
Opción Descripción
Overview Visión general - Cuadros de mandos e
informes
Analysis Análisis - Ver / analizar todo tipo de
eventos
Policies Políticas - Configurar el comportamiento de detección
Devices Dispositivos - Gestión de dispositivos de
detección
Objects Objetos - Crear y administrar objetos utilizados en las políticas
FireAMP FireAMP - Administrar el Centro de
Defensa de detección de malware de la nube de conexión
Figura 82. Vista general del menú CISCO FireSIGHT.
110
El lado derecho del menú principal contiene elementos centrados en el cuidado y la
alimentación de FireSIGHT. Aquí es donde se hacen cosas como instalar licencias, descargar
actualizaciones, ver el estado de salud, programar trabajos y establecer las preferencias del
usuario (Tabla 23).
Tabla 24. Elementos centrados en el cuidado y la alimentación de FireSIGHT
Menú
Opción Descripción
Health Salud - Configurar y ver el estado de salud del sistema
System Sistema - Actualizaciones, licencias, programación, etc.
Help Ayuda - Obtenga ayuda
<username> <Username> - Desconectar, configurar las preferencias del
usuario
i. Métodos de Configuración alternativos
I. LCD Panel (Panel LCD)
Cada dispositivo incluye un panel frontal LCD y cuatro botones, que se utilizan para configurar
la IP de gestión. Hay que tener en cuenta que el uso del panel frontal requiere acceso físico,
pero no hay autenticación.
II. Keyboard/KVM
Otro método implica iniciar sesión en la consola. Primero, hay que conectar un teclado y un
monitor; A continuación, iniciaremos sesión con las credenciales predeterminadas de admin /
Sourcefire. El siguiente paso es ejecutar el script de configuración de red como root utilizando
la red de configuración de comandos. Este script utiliza una técnica de entrevista para solicitar
la información de configuración IP necesaria.
III. SSH
Este método final es útil si desea ejecutar el script de configuración de red, pero no tiene un
teclado / monitor. Cada dispositivo se envía desde la fábrica con una dirección IP
predeterminada asignada previamente a la interfaz de administración, esta dirección IP es
192.168.45.45. Sin teclado / monitor, puede conectar un ordenador portátil con un cliente SSH
directamente en el puerto de red de la interfaz de administración. Después de eso, debemos
configurar la computadora portátil con una dirección IP en la misma red y SSH al dispositivo,
la Tabla 24 brinda las credenciales básicas de acceso.
Tabla 25. Credenciales por default del dispositivo.
Credenciales de
Fabrica
Usuario Contraseña
Admin Sourcefre
111
I. Configuración del Centro de Defensa
FireSIGHT
La página de configuración del Centro de Defensa contiene las siguientes secciones.
• Cambiar contraseña. - Este es un campo obligatorio, debemos introducir una
contraseña y cambiar el valor predeterminado del dispositivo.
• Configuración de red. - Esta sección contiene la información de la IP ingresada a
través de la pantalla LCD o el script de configuración de red, pero también le permite
agregar más elementos como nombres de host y servidores DNS (Figura 83).
Figura 83. Pantalla de configuración de red.
• Configuración de hora. - Permite configurar la sincronización de tiempo desde una
fuente externa de protocolo de tiempo de red (NTP) o manualmente (Figura84).
Figura 84. Pantalla de Configuración de zona horaria.
112
• Importaciones periódicas de actualizaciones de reglas. - Permite configurar la
actualización de las reglas IPS de Cisco de forma recurrente.
• Actualizaciones periódicas de geolocalización. - Permite configurar la
actualización de la IP a la información de ubicación geográfica de Cisco de forma
recurrente.
• Copias de seguridad automatizadas. - Esta opción permite configurar copias de
seguridad de la base de datos de políticas y configuraciones locales.
• Configuración de licencia. - Le permite agregar claves de licencia de función.
• Registro de dispositivos. - Permite registrar dispositivos gestionados en el Centro
de defensa (Figura 85).
Figura 85. Pantalla de administración de dispositivos.
• Contrato de licencia de usuario final. -Aquí es donde lee y acepta el contrato de
licencia de software de Cisco (Este es un ajuste necesario).
Figura 86. Pantalla de descripción general de contratos y licencias dentro del sistema
FireSIGHT
113
J. Menú Objetos
Los objetos son configuraciones reutilizables que asocian un nombre con un valor como una
dirección IP o un número de puerto. Ellos convenientemente permiten hacer referencia a sus
nombres de fácil uso para que no tengamos que recordar los molestos detalles como el puerto
que un servicio particular utiliza. Los objetos también hacen mucho más fácil modificar un
valor que ya se ha utilizado en múltiples reglas o políticas. Todo lo que debemos hacer es
modificar el objeto y su valor será cambiado automáticamente donde quiera que se hace
referencia a través del sistema. Los objetos se ponen a menudo a utilizar en las reglas del control
del acceso (Figura 87 y Figura 88).
Figura 87. Pantalla para ingresar al menú Objetos.
Figura 88. Lista del menú Objetos.
i. Network Objects (Objetos de Red)
Son simplemente direcciones IP o bloques CIDR, pero un solo objeto puede contener realmente
más de una dirección o bloque. Es bastante común encontrar objetos de red que incluyan el
espacio de direcciones interno de una organización, como 10.0.0.0/8 o 172.16.0.0/12. Los
objetos individuales se pueden introducir como direcciones IP individuales o en bloques
mediante la notación CIDR. Predeciblemente, la función de agrupación le permite combinar
objetos individuales en grupos (Figura 89).
114
Figura 89. Pantalla de manipulación de Objetos de Red.
ii. Security Intelligence (Listas de Inteligencia de Seguridad)
La forma más fácil de recordar este tipo de objetos es pensar en "listas de IP". Las listas de
inteligencia de seguridad son realmente sólo listas de direcciones IP o bloques CIDR utilizados
en la política de control de acceso para la lista blanca o el tráfico de lista negra según la
dirección de origen o de destino. Al hacer clic en el enlace de Inteligencia de seguridad,
veremos que hay varios objetos ya configurados aquí: la lista negra global, la lista blanca global
y el feed de inteligencia de Sourcefire. La lista negra y la lista blanca son sólo aquellas listas
que tienen la intención de bloquear o permitir el tráfico basado en la dirección IP. De hecho,
por defecto, no hay nada en la lista en absoluto. Estas dos listas se rellenan a través de la vista
de análisis. Esto se puede hacer en cualquiera de las vistas de eventos, como eventos de
conexión, eventos IPS o cualquier vista de evento que contenga una dirección IP (Figura 90 y
Figura 91).
Figura 90. Pantalla principal de las listas de inteligencia.
115
Figura 91. Pantalla para la manipulación de las listas de inteligencia.
Otra opción que se muestras es para la frecuencia de actualización, cuyo valor predeterminado
es 2 horas, pero se puede establecer hasta 1 semana o desactivarse completamente. Este
intervalo de tiempo regula el intervalo en el que el Centro de Defensa buscará actualizaciones
del feed de Seguridad de Sourcefire. El feed de Inteligencia de Seguridad consta de varias listas
de direcciones IP y las direcciones que las pueblan son actores mal conocidos, como spammers,
servidores de botnet y los hosts conocidos por servir malware, entre otros (Figura 92).
Figura 92. Frecuencia de Actualización.
También es bueno saber que puede agregar sus propios objetos de Inteligencia de Seguridad.
Hay dos tipos de objetos personalizados de Inteligencia de seguridad que se pueden agregar,
siendo el primer tipo un feed. Básicamente, un feed de inteligencia funciona igual que el feed
de Sourcefire, excepto que la lista de IP de origen procede de la URL personalizada que ha
introducido en su lugar. Las opciones comunes incluyen los feeds de la lista negra en Internet
o en red local. El segundo tipo es una lista estática de direcciones IP. La dirección URL de la
fuente se dirige a un archivo de texto en un servidor web, que contiene direcciones IP (Figura
93).
116
Figura 93.Pantalla de agregación de Objetos.
Las listas de IP estática son el segundo tipo de objeto de inteligencia de seguridad personalizado
que puede agregar es una lista de direcciones IP estáticas (Figura 94), que se carga a través de
la interfaz de administración de objetos. Los requisitos para esta lista son los mismos que el
feed personalizado (debe ser un archivo de texto con un bloque IP o CIDR) El archivo de texto
en sí tiene una dirección IP por línea, con un tamaño de archivo máximo de 500 megabytes.
Hay un campo de URL MD5 debajo del campo URL de Feed que en realidad es otra URL que
apunta a la suma de comprobación MD5 del archivo. Esto proporciona una protección adicional
al impedir que alguien altere el archivo de URL de feed. El último elemento de este diálogo
permite seleccionar la frecuencia de actualización, que es muy similar a la frecuencia de
alimentación de Sourcefire por que pueden configurarse en los mismos intervalos de tiempo
(de 2 horas a 1 semana o deshabilitarlas completamente).
Figura 94. Listas Estaticas IP para manipulación de Objetos.
De los dos tipos de objetos personalizados, la alimentación es una forma mucho más flexible
de actualizar las listas de IP. El hecho de que el centro de Defensa envía automáticamente la
URL, elimina la lista actualizada y la envía a todos los dispositivos (es una solución de mucho
mantenimiento menor).
117
iii. Port Object (Puertos de Objetos)
Puertos o rangos de puertos de red. Los objetos de puerto son simplemente números de puerto
con nombres amistosos. Estos pueden ser puertos TCP o UDP o incluso un rango de puertos.
Al hacer clic en el enlace Objetos individuales, se muestran varios objetos de puerto pre
configurados. Todos los puertos bien conocidos se enumeran aquí (Figura 95 y Figura 96).
Figura 95.Pantalla para agregación de objetos de puerto.
Figura 96. Pantalla para agregación de objetos de puerto por grupo.
iv. VLAN tag
Números o rangos VLAN. Son simplemente una forma de dar un nombre amigable a un número
de ID de VLAN. Una vez más, las entradas de etiqueta VLAN pueden ser un solo número o un
intervalo de números con guiones, pero no puede introducir una lista de VLAN separada por
comas. Los grupos de etiquetas VLAN se pueden utilizar para combinar objetos al igual que
con los grupos de objetos de red y de puerto (Figura 97 y Figura 98).
118
Figura 97. Pantalla de agregación de Objetos VLAN.
Figura 98. Pantalla de agregación de Objetos VLAN por grupo.
v. URL
Es una URL real diseñada para coincidir con una URL específica dentro de una regla de control
de acceso. Los objetos URL se utilizan para identificar peticiones HTTP buscando la cadena
de texto en la petición. Es importante recordar que esto es realmente una coincidencia de
subcadena, lo que significa que este tipo de objeto coincidirá con cualquier URL que contenga
los caracteres en ella. Esto significa que si han creado un objeto de URL que contiene la cadena
ign.com con la idea de que coincida con esa URL específica, hay que tener en mente que
también coincidirá con verising.com hay que mantener este comportamiento en mente para que
no acabe bloqueando o permitiendo las direcciones URL equivocadas (No hay comodines, el
sistema simplemente coincidirá con cualquier URL que contenga todos los caracteres
introducidos). Y como con otros objetos, la idea es poder crear un nombre amigable para su
uso en una regla de control de acceso. Si deseamos crear un objeto individual, debemos (Figura
99 y Figura 100):
1. Debemos navegar hasta la pantalla Objetos haciendo clic en Objetos en el menú de
nivel superior.
2. Elegir los Objetos individuales bajo el encabezado URL de la izquierda.
3. Hacer clic en el botón Agregar URL en la parte superior derecha para mostrar el
cuadro de diálogo Objetos URL.
119
4. Asignar un nombre a su objeto y, a continuación, introducir un texto descriptivo en
el campo URL (No necesitamos la parte http: de la URL porque este objeto
coincidirá con cualquier URL que contiene el texto que ha introducido).
Figura 99. Pantalla de agregación de objetos URL.
Figura 100. Pantalla de agregación de objetos URL por grupos.
vi. Application Filters (Filtrado de Aplicaciones)
Estos objetos se configuran para que coincidan con un protocolo de aplicación específico como
HTTP o POP3. Y en este contexto en particular, la aplicación en particular incluye sitios
populares como Facebook y ESPN, que se identifican en base a los filtros que se envían con el
sistema FireSIGHT. Al escribir esto, FireSIGHT puede identificar más de 2.200 aplicaciones
(un número que crece con cada actualización del sistema) clasificada por riesgo y relevancia
comercial de muy bajo a muy alto. Estos se dividen más por tipo (protocolos de aplicación,
aplicaciones cliente y aplicaciones web) y aún más por categorías (como negocios,
colaboración, juegos, etc.). Puede utilizar estos filtros para permitir o bloquear aplicaciones
específicas mediante reglas de control de acceso. “La capacidad de identificar aplicaciones
basadas en su tráfico de red es realmente lo que hace que el Sistema FireSIGHT sea un
IPS o firewall de "Próxima Generación".
120
Podemos crear un filtro de aplicaciones que identifique el tráfico de alto riesgo y baja relevancia
empresarial y utilizarlo para bloquear aplicaciones designadas de cualquiera o todos los
usuarios de su red (Figura 101):
• A través de Riesgo podemos determinar la probabilidad de que una aplicación
específica se utilice para violar la política de seguridad de su empresa con
configuraciones que varían desde muy bajas a muy altas.
• La opción de relevancia empresarial permite determinar aplicaciones que se acceden
para recreación en lugar de las necesidades reales del negocio. También se puede
configurar de muy bajo a muy alto.
• La opción Tipo se refiere de manera previsible al tipo de aplicación con la que se
está tratando y le ofrece tres categorías:
➢ Protocolos de aplicación (comunicaciones entre hosts).
➢ Clientes (software que se ejecuta en un host).
➢ Aplicaciones Web (el contenido o la URL solicitada para el tráfico HTTP A
través de la categoría, se obtiene la clasificación general de una aplicación.
Debido a que las aplicaciones pueden pertenecer a más de una categoría,
estas tienen Tags, que le permiten obtener más información sobre la
aplicación en cuestión. Algunos buenos ejemplos de etiquetas de aplicación
son evasivas, ancho de banda alto y puertos abiertos).
Figura 101. Pantalla para la agregación de filtrado de aplicaciones.
Explicando un poco acerca de los sitios web cifrados SSL / TLS. Desde la perspectiva de la
red, el uso de SSL / TLS significa que no podemos ver el tráfico de la aplicación. Debido a que
el HTTP GET se produce después de que la sesión está encriptada, un IPS típico no puede ni
siquiera determinar la URL que se solicita. Sin embargo, notaremos que algunas aplicaciones
de detección son muy específicas. Un buen ejemplo es Facebook.
121
Si examinamos el número de aplicaciones que aparecen en este sitio son de más de una docena.
El desafío aquí es que, desde hace algún tiempo, todo el tráfico de Facebook ha sido cifrado
SSL, lo que significa que la identificación de estas aplicaciones es imposible sin utilizar algún
tipo de tecnología de descifrado. FireSIGHT puede inspeccionar el certificado SSL y buscar el
dominio de Facebook.com. Esto significa que puede identificar el sitio web de Facebook, pero
no las aplicaciones individuales de la lista. Así que tengamos en cuenta estas limitaciones
cuando estemos creando filtros de aplicaciones y no esperemos que el NGIPS haga milagros
(Figura 101).
Figura 102. Descripción del filtrado de aplicaciones.
vii. Variables SET (Variables)
Estos objetos se utilizan para configurar variables de Snort. Los conjuntos de variables son
objetos utilizados para configurar las variables de Snort que se encuentran en los encabezados
de reglas de Snort. Estos contienen, dirección IP e información de puerto que restringen la
operación de la regla.
Figura 103. Pantalla de administración de variables.
122
viii. File List (Lista de Archivos)
El objetivo principal es anular la disposición que la nube devuelve para un valor SHA-256
particular. Encontraremos dos elementos de lista de archivos ya presentes: la lista limpia y la
lista de detección personalizada, que son los dos únicos elementos permitidos en esta lista. No
podemos añadir nuestros propios objetos de lista de archivos.
Para entender las listas de archivos, retrocederemos y hablaremos de la detección de malware
de FireAMP. En primer lugar, AMP significa protección avanzada contra malware, y es una de
las características clave del sistema FireSIGHT. Recordemos que es una licencia de suscripción
separada que se debe comprar. Una vez hecho esto, podemos implementar una política de
archivos y utilizar los objetos de lista de archivos para personalizar la detección de software
malicioso. La detección de malware SHA-256 implica calcular el hash, enviarlo a la nube, y
luego recibir de vuelta una disposición de limpio, desconocido o malware. En el sistema
FireSIGHT, esto funciona por el dispositivo de recolección de un archivo a medida que pasa a
través de su interfaz de detección. Así que una vez que se ha recopilado todo el archivo, el
dispositivo calcula el hash SHA-256 y lo envía al Centro de Defensa. El Centro de Defensa
luego envía el hash a la nube y recibe una disposición.
El propósito de los objetos de la lista de archivos es anular este comportamiento predeterminado
del Centro de Defensa para valores SHA-256. La lista limpia contiene SHA-256 valores que
siempre se considerarán limpios, por lo que cuando el Centro de Defensa recibe uno de estos
hashes de un dispositivo, inmediatamente devolverá un veredicto de "limpio" sin comprobar
con la nube. La lista de detección personalizada funciona de la misma manera, pero los hashes
en esta lista siempre se consideran malware. Así es como un administrador anularía el
comportamiento de FireSIGHT para ciertos archivos (Figura 104).
Figura 104. Pantalla de administración de listas de objetos.
123
Existen 3 métodos para agregar entradas al archivo de listas (Figura 105):
• List of SHAs. - se presenta un botón Examinar, que permite cargar un archivo de
texto que contiene una lista de valores SHA-256, una línea de entrada. Incluso puede
introducir una descripción opcional, pero si no lo hacemos, se utilizará el nombre
del archivo. Este método es muy útil cuando se está cargando un gran número de
valores hash.
• Calculate SHA. - Otro camino a seguir es dejar que el Centro de Defensa calcule
el valor SHA de un solo archivo. Para ello, buscaremos un archivo que deseamos
agregar a la lista. El archivo se cargará en el Centro de Defensa, pero sólo para
calcular su valor SHA-256, no será almacenado en el Centro de Defensa. Podemos
introducir una descripción opcional, pero si no lo hacemos, se utilizará el nombre
de archivo.
• Enter SHA Value. - Podemos Ingresar el valor SHA calculado.
Figura 105. Diferentes entradas existentes para la configuración de listas de archivos.
ix. Security Zones (Zona Seguras)
En el sistema FireSIGHT, el término zonas tiene su propio significado especial. Es simplemente
el nombre dado a una interfaz física en un dispositivo. Cuando crea reglas de control de acceso,
una opción es aplicar sus reglas al tráfico basándose en su interfaz de entrada y / o salida.
También puede obtener información útil sobre el contexto de tráfico mediante la comprensión
de dónde entró y salió el tráfico de un dispositivo. Esto hace que podamos dar a las interfaces
de dispositivos de nombres amigables, pero es importante recordar que los cambios realizados
en las zonas de seguridad en cualquiera de las dos ubicaciones no tendrán efecto hasta que se
apliquen al dispositivo. Esto sólo se puede hacer desde la vista de administración del
dispositivo.
Existen varios tipos de zonas de seguridad (Figura 106), cada una de las cuales
corresponde a tipos de interfaz como inline, passive, switched y routted. Una sola zona puede
contener múltiples interfaces, pero cada interfaz debe ser del mismo tipo (no se pueden mezclar
interfaces en línea y pasivas dentro de una sola zona).
124
Figura 106. Pantalla de administración de zonas de seguridad.
x. Geolocation (Geolocalización)
Contienen países o continentes. Por ejemplo, podríamos crear un objeto denominado Países
Interesantes y añadirle varios países. Una vez más, esto se puede emplear en la política de
control de acceso para personalizar la inspección y permitir o bloquear el tráfico basado en el
país o la geografía (identifica el país o continente en el que utiliza una dirección IP específica).
Por supuesto, esto no se aplica al RFC 1918 direcciones, ya que se limita a routear espacio de
direcciones IP. La base de datos de geolocalización que asigna direcciones IP a las ubicaciones
se actualiza semanalmente en el Centro de Defensa y, al igual que ocurre con varios otros tipos
de objetos, este objeto se utiliza para dar un nombre descriptivo a una lista de ubicaciones para
facilitar las cosas a los seres humanos (Figura 107).
Figura 107. Pantalla de administración de la geolocalización.
125
K. Políticas IPS CISCO Sourcefire
Las políticas de IPS describen con precisión el tráfico sospechoso y / o malicioso que el sistema
debe vigilar, y también controlan cómo se trata el tráfico malo cuando se descubre. Estas reglas
se pueden establecer en Off u On y dirigir las acciones específicas que el sistema toma cuando
se produce una coincidencia con el tráfico malintencionado o sospechoso. También regulan las
acciones que se toman cuando ciertas direcciones IP o redes se encuentran involucradas. Las
reglas de Snort se proporcionan a través del equipo de seguridad de Cisco Talos, pero también
se pueden usar reglas definidas por el usuario. Hay más de 20.000 reglas integradas en el
sistema, por lo que es claramente importante en términos de gastos generales, permitir sólo las
reglas específicas pertinentes a su entorno.
i. Default (Predeterminadas)
Las directivas predeterminadas pueden encajar en muchos escenarios diferentes y son ideales
para cuando implemente el IPS por primera vez. Al aprovechar las directivas predeterminadas,
obtiene un nivel de seguridad preestablecido para el entorno, pero tengamos en cuenta que estas
directivas pueden configurarse para eliminar el tráfico si el dispositivo se implementa en línea.
El tráfico legítimo no debería tener problemas para pasar; Sólo se eliminan las cosas maliciosas.
Y no olvidemos que este atributo de política es configurable. Existen 4 políticas de punto de
partida:
1. No Rules Active. - Está disponible para cualquier persona que quiera un control estrecho
sobre lo que se habilita y deshabilita. Todas las reglas comienzan en el estado deshabilitado,
y nuevamente, debido al gran número de ellas, es aconsejable habilitar sólo aquellas que se
ajustarán estratégicamente a las necesidades de seguridad definidas.
2. Connectivity Over Security. - se basa en la velocidad y proporciona al motor de
inspección el rendimiento más rápido. Las reglas que están habilitadas aquí son destinadas
a defenderse de los ataques más insidiosos que posiblemente podrían afectar las redes
actuales. Estas poderosas reglas califican una puntuación de 10 puntos del Sistema de
Puntuación de Vulnerabilidad Común (CVSS) y no deben ser mayores que el año actual
más dos años antes.
3. Balanced Security and Connectivity. - funciona bien en términos de latencia y también
es una buena política de cobertura media. En general, tiene reglas habilitadas que tienen un
puntaje CVSS de 9 o más. La política de seguridad y conectividad equilibrada tiene reglas
habilitadas en varias categorías clave, como SQL-Injection y Exploit Kit.
4. Security Over Connectivity. - se considera la más estricta de las políticas predeterminadas.
Tendrá la mayoría de las reglas habilitadas con un número significativo de ellas fijadas para
caer. Cuando se implementa en línea, la acción de eliminación descartará realmente un
paquete malicioso para evitar que se produzca un ataque. Las reglas de esta política tienen
una calificación CVSS de 8 o más de este año o las tres anteriores y cumplen con los
126
requisitos de varias categorías adicionales (SQL-Injection, Exploit Kit y CNC Malware
para nombrar algunos).
ii. Capa de Políticas
A pesar de que podemos utilizar una de las políticas integradas Sourcefire, también podemos
ajustar las cosas un poco si lo deseamos. Podemos activar o desactivar las reglas, configurarlas
de modo que no se muestren, para alertar solo, y así sucesivamente, pero sabemos que, si
decidimos ir con una política predeterminada, no puedes cambiarlas. Entonces, ¿qué hacer si
sólo en su mayoría como una política por defecto? Debemos crear nuestra propia política
personalizada basada en ella y obtener exactamente lo que queremos en su lugar. Hacer esto
implica un concepto conocido como estratificación. Cuando creamos una política de IPS
personalizada, tenemos que conformarnos primero con lo que llamamos una capa base.
Figura 108. Descripción en capas de las políticas IPS
iii. Capa de Políticas
Para crear una nueva política IPS. Primero, dentro del Centro de Defensa, iremos a Políticas-
Intrusión-Política de intrusión y, a continuación, haga clic en Crear directiva. Primero
debatiremos qué acciones se pueden tomar contra el tráfico malicioso. Estas acciones dependen
de cómo se despliegue el dispositivo. Las dos acciones son:
• Eliminar y generar eventos (Drop And Generate Events): esta acción hace que
el IPS elimine el tráfico malicioso que coincida con una regla IPS. También enviará
un evento al Centro de Defensa. Los eventos (a veces llamados alertas) son lo que
los analistas ven en el Centro de Defensa.
• Generar eventos (alerta / Generate Events Alert): en algunos casos, es posible
que no desee eliminar el tráfico malicioso sospechoso. Esto puede ocurrir en
situaciones en las que está probando el IPS o algunas de las reglas se utilizan para
127
la auditoría en lugar de proteger. Generar Eventos hará que la alerta se dirija al
Centro de Defensa, pero no interrumpirá el tráfico.
La eliminación en Inline es una casilla de verificación que controla si las reglas IPS dejan
caer el tráfico. La idea es que el IPS salvará la red descartando archivos maliciosos:
• Si el dispositivo se despliega en línea y se activa la casilla
• La capacidad de caer definitivamente está ahí, pero el rescate de la red también
depende de las políticas individuales de IPS que se hayan puesto en marcha.
• Si se selecciona el cuadro Soltar cuando está en línea, pero el dispositivo no se
implementa en línea, el tráfico no se descartará.
• Si el dispositivo se implementa en línea y no se selecciona el cuadro Colocar cuando
está en línea, el tráfico no se descartará si hay un conjunto de reglas para eliminar y
generar eventos.
• Si el dispositivo se implementa de forma pasiva, la comprobación de la casilla Drop
When Inline no importará un bit.
• Si la casilla no está marcada y tienes reglas definidas para cancelar y generar
eventos, el tráfico que coinciden todavía se mostrará en la vista de análisis de
eventos, pero se marcará como se habrían dejado.
Figura 109. Pantalla para creación de políticas.
iv. Capa de Políticas
Al abrir el editor de políticas, se mostrará un panel de navegación a la izquierda y, a la derecha,
el panel de detalles, que ocupa la mayor parte de los inmuebles de la pantalla.
Esta es una lista de los elementos que encontrará en el panel de navegación:
• Información de política (Policy informatiòn): Muestra una pantalla de resumen
que muestra la configuración básica de la política. Éste es importante porque si
realiza algún cambio, debemos regresar aquí para confirmar los cambios (guardar)
o descartarlos. Entendamos que elegir Confirmar cambios aquí solo aplica los
128
cambios a la base de datos en el Centro de Defensa y realmente no empuja la
configuración al dispositivo administrado. Debemos de aplicar directamente la
política al dispositivo para empujar realmente la configuración.
• Reglas (rules): Muestra todas las reglas disponibles para la política.
• FireSIGHT Recomendaciones: FireSIGHT recomienda qué reglas se habilitarán
o desactivarán basándose en los datos recopilados en nuestra red a través de
FireSIGHT.
• Configuración avanzada (Advance Settings): Contiene preprocesador, registro y
configuración de rendimiento.
• Capas de políticas (Policy Layers): Permiten ampliar y ver las capas de políticas,
incluida la base capa y cualquier capa definida por el usuario.
Figura 110. Vista capas de políticas desde el editor.
v. Reglas
La sección de Reglas se subdivide aún más:
• Panel de filtro (Filter Panel): Es la columna vertical hacia el centro. Permite ver
reglas asociadas con categorías específicas, clasificaciones, prioridades o
actualizaciones de reglas. Si selecciona una opción del panel de filtros, aparecerá la
barra de filtros en la parte superior de la lista de reglas. Al hacer clic en las secciones,
se ampliará o se contraerán otras secciones.
• Filtro de barra (Filter Bar): Esto se encuentra en la parte superior de la interfaz.
Se utiliza para introducir manualmente los criterios de búsqueda para las reglas.
También tenemos la opción de rellenar la barra de filtros seleccionando elementos
del panel de filtro de reglas.
• Lista de reglas (Rules List): Esto constituye la parte principal de la pantalla.
Muestra todas las reglas basadas en los criterios especificados en la barra de filtros.
• Desplegado de políticas (policy Drop-Down): Ubicado debajo de la barra de filtros
y por encima de la lista de reglas. Esto permite examinar una capa específica de la
política IPS. La vista predeterminada muestra los valores acumulativos de todas las
capas.
129
• Show Details: Si tenemos una regla específica seleccionada en la lista de reglas,
veremos un Show.El botón Detalles aparece en la parte inferior de la interfaz. Al
hacer clic en esta opción, se mostrarán los detalles de esa regla, incluido el texto de
la regla en sí, la documentación, los gastos generales y los sitios web de referencia.
Figura 111.Vista reglas desde el inspector de políticas.
vi. Policity Recomendations (Recomendaciones de políticas)
El primer menú desplegable es Rule State (Estado de la regla), que le permite especificar uno
de los tres:
• Acciones. - Deshabilitar (desactivar la regla), Generar eventos (establecer la regla
para enviar eventos al FSM) o Eliminar y generar eventos (tenga el dispositivo
descartar los paquetes maliciosos). Recordemos que, si su dispositivo está en línea,
la posibilidad de eliminar el tráfico siempre que las reglas se establezcan para que
se eliminen y la directiva se establezca en Eliminar cuando está en línea.
• Filtrado de eventos. - Los ajustes de filtrado de eventos le permiten especificar si
desea disminuir la frecuencia de las alertas que ocurren en el Centro de Defensa.
Este ajuste no tiene impacto en las acciones de drop, solo afecta las alertas al Centro
de Defensa. Las opciones son ajustar los ajustes de umbral o la configuración de
supresión.
Figura 112. Pantalla de Filtrado de políticas.
130
• Hay tres tipos para elegir: Límite, Umbral y Ambos. Se debe seleccionar uno de ellos.
o Límite: permiten limitar el número de alertas basadas en la dirección IP de
origen o de destino, así como el número de alertas que desea activar si el evento
se produce dentro de un número seleccionado de segundos. Una vez que se
alcance ese límite, no se producirán nuevas alertas hasta que el período de
tiempo haya expirado. Por lo tanto, si deseamos limitar un evento a 10 alertas
cada 5 minutos, podemos utilizar esta opción.
o Umbral: permiten limitar el número de alertas basadas en la dirección IP de
origen o de destino, el número de eventos que deben producirse antes de generar
una Alerta, más el número de segundos asignados para buscar esos eventos. Por
ejemplo, supongamos que el recuento se estableció en 10 y los segundos en 60.
El resultado sería una alerta para cada 10 sucesos de ese evento en 60 segundos.
o Ambos: Una combinación que permite limitar el número de alertas basadas en
la dirección IP de origen o de destino. El recuento especifica el número de
eventos que deben observarse antes de que se genere una alerta. Una vez más,
el período de tiempo indica que no desea que otra alerta del mismo tipo se genere
dentro de ese intervalo. En otras palabras, podrías decirme solo si el evento x
ocurre 10 veces (Umbral) pero solo dímelo cada 5 minutos (Límite). Es muy
importante recordar que estos ajustes afectan sólo a las alertas y no tienen
ningún efecto en el procesamiento de tráfico real. Todavía es difícil ser
proactivo con estos porque nunca se sabe lo que obtendrá en su entorno
específico.
• Estado Dinámico. - permite al dispositivo cambiar dinámicamente el estado de la
regla desde su estado actual a cualquiera de los otros estados disponibles: Generar
eventos, Generar eventos y Desactivado. El estado cambia en función de la dirección
de origen o de destino, tal como se define en la lista desplegable Rastrear por. Otra
opción que puede aparecer en la lista desplegable "Rastrear por Regla”. Si se
especifica origen o destino, el campo Red debe rellenarse. Si se selecciona Rule en
el campo Track By, entonces el campo Network no aparece. El campo Rate permite
especificar que la regla debe disparar una cuenta determinada dentro de un número
dado de segundos. También hay un campo de tiempo de espera que restablece la
regla al estado anterior.
• Alerta. - Para activar o desactivar las alertas SNMP para una regla específica,
debemos utilizar el Diálogo de alerta, que también es útil para enviar datos a una
herramienta SIEM (Security Information and Event Management) o alguna otra
herramienta de alerta. Configuraremos el administrador SNMP en la configuración
avanzada. Las alertas SNMP son generadas por el dispositivo administrado.
• Comentarios. - También podemos agregar comentarios a las reglas individuales
que pueden ser visualizadas por los usuarios del Centro de Defensa y los analistas
que inspeccionan el tráfico.
131
• Política. - La lista desplegable Política de la extrema derecha del editor de políticas
ofrece una vista de las reglas basadas en estados establecidos dentro de las capas de
directiva individuales. La vista predeterminada es simplemente Política, pero
también podemos consultar Mis cambios, Recomendaciones de FireSIGHT si se
utilizan, y la directiva base. Los colores son indicadores importantes aquí; Por
defecto, todas las reglas aparecerán en blanco. Cuando se ven las capas individuales,
el color rosa indican que el estado de la regla ha sido modificado en una capa
superior. Una regla resaltada en amarillo significa que su estado se ajustó en una
capa inferior. Las reglas resaltadas en naranja son aquellas en las que has hecho clic.
vii. FireSIGTH Recomendations (Recomendaciones de
FireSIGTH)
Realmente hay una multitud masiva de reglas por todos lados, es un hecho que este enjambre
de opciones, puede hacer que averiguar lo que necesitamos para nuestro entorno particular sea
una experiencia abrumadora. Esta es la razón por la que es una gran idea comenzar con una de
las políticas predeterminadas y, a continuación, habilitar reglas que sean más específicas para
nuestro entorno. Otra herramienta muy útil para despejar el camino hacia opciones y políticas
sólidas es las Recomendaciones FireSIGHT. Estas recomendaciones dan un impulso al insertar
una capa de política entre la capa de directiva base y la capa Mis cambios.
Figura 113. Pantalla de Recomendación de políticas FireSIGTH.
viii. Policy Layer (Capa de Políticas)
La sección Capas de políticas (muestra todas las capas que se han Implementado en la política
actual. Por lo menos, veremos la capa base y la capa Mis cambios. Si agregamos otras capas,
como una capa de usuario adicional o la de Recomendaciones de FireSIGHT, veremos esas
acciones reflejadas aquí. También encontraremos un resumen de las capas individuales,
incluido el número de reglas en sus estados específicos dentro de este diálogo aparecerá un
triángulo amarillo si ha realizado cambios en la política en la sección Información de política
132
del panel de navegación. Esto indica que debemos guardar o descartar los cambios haciendo
clic en el botón Cambiar confirmación o en el botón Descartar cambios, respectivamente
(Figura 114).
Figura 114. Pantalla de capa de políticas.
Y sólo para recordar, el hecho de realizar cambios aquí no empujará la política al dispositivo,
sólo confirmará los cambios en la base de datos del Centro de Defensa. Debemos agregar la
directiva a una directiva de control de acceso para que pueda ser enviada al dispositivo.
ix. Intrusion Policy Repository (Capa de Políticas de
intrusión)
Después de confirmar los cambios, se abrirá el repositorio de políticas de intrusión y podremos
ver una lista de todas las políticas de intrusión que se hayan creado. A la derecha de cada
política, veremos iconos que le permitirán volver a aplicar la política, generar un informe y
exportar, editar o eliminar la directiva. El informe es ideal para fines de documentación. La
exportación creará un archivo binario que se puede importar a otros Centros de Defensa siempre
que estén ejecutando las mismas versiones.
Figura 115. Pantalla de capa de Intrusión.
![Paradojas Matemáticas [Proyecto de Investigación].pdf](https://img.pdfslide.net/doc/110x75/55cf9c82550346d033aa13f6/paradojas-matematicas-proyecto-de-investigacionpdf.jpg)
