Mendizale - Bizkaiko Foru Aldundia

Mendizale
15 de noviembre de 2006
Resumen
Ante la creciente magnitud del problema del aseguramiento de la Seguridad de la Información
en sistemas y redes de comunicaciones de todo tipo, los tradicionales mecanismos pasivos de
aislamiento y control de acceso se muestran insucientes para contener el extraordinariamente
ascendente número de ataques e intentos de int
rusión, bien indiscriminados, bien selectivos, que se producen en la actualidad.
De este modo, en dichas circunstancias, el área de conocimiento de la Detección de Intrusiones, caracterizada fundamentalmente por su comportamiento activo y por el uso de técnicas de
Inteligencia Articial más o menos ambiciosas y sosticadas, se muestra como una de las tecnologías de seguridad más prometedoras, a medio plazo. Así, es posible encontrar actualmente
soluciones comerciales de detección sólidas y de reconocido prestigio, las cuales, bien orientadas
a la monitorización de equipamientos especícos, bien orientadas a la supervisión de redes de
comunicación completas, abogan por la utilización de modelos de representación de conocimiento
e inferencia basados en el concepto de Sistema Experto, de encadenamiento de reglas.
De esta manera, por lo general, el conocimiento disponible en relación con ataques documentados contra dichos equipamientos o redes de comunicación, queda representado en forma
de reglas de producción, confeccionadas por el administrador humano. Dichos Sistemas de Detección de Usos Indebidos, se caracterizan por ser muy precisos en sus decisiones, amén de por
un habitual alto nivel de eciencia. Sin embargo, presentan una importante limitación: no son
capaces de responder ante lo que no conocen. O lo que es lo mismo, ante la posibilidad de que
un hipotético atacante pueda disponer del conocimiento del sistema de detección (cuestión realmente factible en la mayoría de casos), para a partir de él introducir ligeras modicaciones en
sus procedimientos de ataque que camuen sus acciones, o bien ante ataques completamente
novedosos, simplemente no hay respuesta.
Por ello, la comunidad cientíca estudia actualmente posibles soluciones a este inconveniente,
apareciendo el concepto de Detección de Anomalías como un elemento de análisis indispensable
a medio plazo, bien en forma de complemento al tradicional enfoque de detección de usos indebidos, patrones o rmas, o bien como superconjunto semántico de éste. Para ello, en general,
dicho enfoque de Detección de Anomalías, persigue el objetivo de ser capaz de proporcionar una
respuesta incluso ante situaciones de riesgo no conocidas de antemano, en base a la elaboración
del perl de comportamiento del sistema a monitorizar, y al cálculo de desviaciones de la actividad cotidiana con respecto a dicho perl. Así, toda desviación sucientemente signicativa será
considerada como una anomalía del sistema, y susceptible por tanto de ser noticada al operador humano en forma de señal de alarma, de manera que sea posible un análisis pormenorizado
de las causas de dicha alarma, o de procesarse automáticamente, en la línea del paradigma de
Prevención de Intrusiones.
De esta forma, con el objetivo de proporcionar una respuesta completa por parte del sistema de detección, tanto ante ataques conocidos como ante ataques no conocidos, la presente
tesis doctoral explora el camino de la unicación de los dos grandes paradigmas de Detección de
Intrusiones, mediante la utilización de modelos de representación de conocimiento e inferencia
de conclusiones basados en el concepto de Red Bayesiana, el cual contempla de manera intrínseca toda la potencia de representatividad de los tradicionales Sistemas Expertos basados en
reglas, amén de un amplio conjunto de poderosas capacidades adicionales, como son: inferencia explicativa de conclusiones, encadenamiento omnidireccional de relaciones de causalidad y/o
correlación, representación intrínseca de la magnitud temporal, aprendizaje estructural (o Data
Mining Bayesiano) a partir de los datos, aprendizaje paramétrico completo o secuencial a partir
de dichos datos, capacidad de adaptación del modelo de conocimiento a variaciones del sistema
observado, o posibilidad de obtención, mediante análisis de sensibilidades, de un esquema cualitativo y cuantitativo de la representatividad y grado de interdependencia de los parámetros que
componen el ámbito del problema. De este modo, a partir de los estudios y experimentaciones
llevadas a cabo en la presente tesis doctoral, se consigue un potente modelo de representación
de conocimiento a partir del cual se desarrolla un motor de razonamiento adaptativo capaz de
inferir conclusiones que contemplan, de un modo unicado y homogéneo en el tratamiento de los
diversos tipos de parámetros de detección, tanto conocimiento propio del paradigma de Detección
de Usos Indebidos, por un lado, como conocimiento característico del paradigma de Detección
de Anomalías, por otro.
Estos paradigmas se aplican en este proyecto al mundo de la tecnología móvil que se va a ir
introduciendo poco a poco a lo largo de esta memoria.
2
Índice general
1. Introducción
17
1.1. El papel de la detección de Intrusiones en la Sociedad de la Información . . . . .
2
1.2. El papel innovador de la Detección de Intrusiones para dispositivos móviles . . .
12
1.3. Conceptos Fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.1. Conceptos Fundamentales de la Seguridad de la Información . . . . . . . .
15
1.3.2. Conceptos de Detección de Intrusiones . . . . . . . . . . . . . . . . . . . .
18
1.3.3. Modelo general de funcionamiento . . . . . . . . . . . . . . . . . . . . . .
20
1.3.4. Características de los diferentes enfoques
. . . . . . . . . . . . . . . . . .
26
1.4. Retos por alcanzar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
1.4.1. Respuesta ante ataques no conocidos (Zero-Day Attacks) contra teléfonos
móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2. Aprendizaje Bayesiano no supervisado de perles de usuario
45
. . . . . . .
45
1.4.3. Unicación de modelos de detección de intrusiones . . . . . . . . . . . . .
46
1.4.4. Respuesta preventiva mediante intercepción de llamadas al sistema . . . .
47
1.4.5. Optimización de tasas de falsos positivos y falsos negativos . . . . . . . .
47
1.4.6. Superación de limitaciones arquitectónicas . . . . . . . . . . . . . . . . . .
47
1.4.7. Base de conocimiento estándar . . . . . . . . . . . . . . . . . . . . . . . .
48
1.4.8. Análisis de tráco de redes inalámbricas . . . . . . . . . . . . . . . . . . .
48
1.4.9. Reducción de requerimientos administrativos . . . . . . . . . . . . . . . .
48
1.4.10. Adaptación al comportamiento del sistema . . . . . . . . . . . . . . . . . .
49
1.4.11. Fortalecimiento del sistema de detección . . . . . . . . . . . . . . . . . . .
49
1.4.12. Reducción del consumo de recursos computacionales . . . . . . . . . . . .
50
1.5. Hipótesis fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
1.6. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
1.7. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
2. Entorno De Trabajo
57
2.1. Detección de Intrusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
2.1.1. Perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3
2.1.2. Modelo conceptual de Lundin . . . . . . . . . . . . . . . . . . . . . . . . .
59
2.1.3. Taxonomía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
2.2. Técnicas de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
2.2.1. Detección de Usos Indebidos . . . . . . . . . . . . . . . . . . . . . . . . . .
76
2.2.2. Detección de Anomalías . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
2.2.3. Modelo General de Denning . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.3. Implicaciones Arquitectónicas en el Análisis . . . . . . . . . . . . . . . . . . . . . 108
2.3.1. Detección basada en Agentes de Software . . . . . . . . . . . . . . . . . . 108
2.3.2. Detección basada en Grafos . . . . . . . . . . . . . . . . . . . . . . . . . . 110
2.3.3. Sistema Inmunológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
2.4. Técnicas de Análisis especícas para Host Intrusion Detection Systems (HIDS) . 111
2.4.1. Preámbulo: Ataques Mimicry en Sistemas de Detección de Intrusiones . . 112
2.4.2. Detección mediante Análisis Forense . . . . . . . . . . . . . . . . . . . . . 114
2.4.3. Detección basada en análisis estático o instrumentación binaria del sistema 116
2.4.4. Detección basada en rmas . . . . . . . . . . . . . . . . . . . . . . . . . . 119
2.4.5. Detección de ataques contra la lógica de las aplicaciones . . . . . . . . . . 121
2.4.6. Detección basada en Secuencias de Syscalls . . . . . . . . . . . . . . . . . 123
2.4.7. Detección basada en grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.4.8. Visualización e identicación del contexto de las intrusiones desde las trazas
de llamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
2.4.9. Modelación de llamadas al sistema mediante ventana deslizante . . . . . . 136
2.4.10. Modelado de trayectorias de syscalls mediante en análisis del código fuente 145
2.4.11. Solución de instrumentación mediante criptografía . . . . . . . . . . . . . 150
2.4.12. Solución mediante virtualización para terminales móviles . . . . . . . . . . 151
2.5. Modelos de redes probabilísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
2.5.1. Modelos de Redes Probabilísticas . . . . . . . . . . . . . . . . . . . . . . . 154
2.5.2. Aprendizaje Estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
2.5.3. Modelado de la información de estado [137] . . . . . . . . . . . . . . . . . 182
3. ESIDE-Mendizale Un Framework Bayesiano de detección de intrusiones
213
3.1. Análisis de riesgos y formalización . . . . . . . . . . . . . . . . . . . . . . . . . . 213
3.1.1. Posibles parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
3.1.2. Selección realizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
3.1.3. Futuros parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
3.2. Recogida de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
3.2.1. Recogida de información en sistemas GNU/Linux . . . . . . . . . . . . . . 230
3.2.2. Recogida de información en sistemas Windows Mobile. . . . . . . . . . . . 252
3.2.3. Recogida de información en sistemas Windows. . . . . . . . . . . . . . . . 258
3.2.4. Recogida de información en sistemas Symbian OS. . . . . . . . . . . . . . 270
4
3.3. Cuestiones arquitectónicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
3.3.1. Riesgo tecnológico, un problema en alza.
. . . . . . . . . . . . . . . . . . 280
3.3.2. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
3.3.3. Detección de intrusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
3.3.4. Introducción a DFSU
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
3.3.5. Estructura básica de DFSU . . . . . . . . . . . . . . . . . . . . . . . . . . 303
3.3.6. DFSU un programa polifacético . . . . . . . . . . . . . . . . . . . . . . . . 312
3.3.7. Componentes de DFSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
3.3.8. DFSU primeros pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
3.3.9. DFSU conguración y puesta en marcha de una instancia . . . . . . . . . 334
3.3.10. DFSU descripción de las interfaces . . . . . . . . . . . . . . . . . . . . . . 350
3.4. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
3.4.1. Modelo General Operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
3.4.2. Obtención de la Muestra Evidencial. . . . . . . . . . . . . . . . . . . . . . 357
3.4.3. Aprendizaje e Inferencia de Expertos Mendizale . . . . . . . . . . . . . . . 360
3.4.4. Proceso de Razonamiento en la Red Naive de Unicación de Conclusiones 367
3.5. Respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
3.5.1. Tipos de respuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
3.5.2. Respuesta implementada en ESIDE-Mendizale. . . . . . . . . . . . . . . . 373
3.6. Fortaleza
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
3.7. Cuestiones Operacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
3.8. Aspectos sociales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
4. Conclusiones y líneas de investigación futuras
379
4.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
4.2. Líneas de investigación futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
5
6
Índice de guras
1.1. Ratio de plataformas PC compatible infectadas en el mundo . . . . . . . . . . . .
2
1.2. Utilización de Internet por parte de empresas y organizaciones con sede en la UE
5
1.3. Utilización de Internet por parte de individuos particulares residentes en la UE .
5
1.4. Crecimiento del número de usuarios en el territorio español, en miles de usuarios
6
1.5. Evolución del comercio electrónico durante los últimos años (en Euros) . . . . . .
7
1.6. Evolución del comercio electrónico durante los últimos años (en número de transacciones) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.7. Evolución del número de incidentes de seguridad reportados anualmente por CERT/CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.8. Evolución del número de incidentes de seguridad reportados anualmente por FBI
y CSI en su Computer Crime and Security Survey
. . . . . . . . . . . . . . . . .
10
1.9. Relación entre el nivel de preparación del hacker y el grado de sosticación de sus
ataques, según estudios realizados por CERT/CC . . . . . . . . . . . . . . . . . .
11
1.10. Modelo General de Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.11. Taxonomía general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.1. Modelo conceptual de Lundin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
2.2. Taxonomía de Alessandri et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
2.3. Modelo general de Alessandri et al. . . . . . . . . . . . . . . . . . . . . . . . . . .
66
2.4. Taxonomía de Allen et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.5. Taxonomía de Bace y Mell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
2.6. Taxonomía de Axelsson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
2.7. Taxonomía de Debar, Dacier y Wespi . . . . . . . . . . . . . . . . . . . . . . . . .
69
2.8. Taxonomía revisada de Debar, Dacier y Wespi. . . . . . . . . . . . . . . . . . . .
70
2.9. Taxonomía de Lazarevic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
2.10. Taxonomía de Krügel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
2.11. Taxonomía de Indican CERT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
2.12. Arquitectura CIDF.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
2.13. Taxonomía ESIDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
2.14. Ubicación de hipótesis fundamentales . . . . . . . . . . . . . . . . . . . . . . . . .
75
7
2.15. Modelo general de Detección de Usos Indebidos. . . . . . . . . . . . . . . . . . . .
77
2.16. Batería de reglas de Snort para detección de Shellcodes . . . . . . . . . . . . . . .
78
2.17. Firma de Snort para detección de ataques contra Apache . . . . . . . . . . . . . .
78
2.18. Firma de Bro para detección de ataques contra Apache . . . . . . . . . . . . . . .
78
2.19. Batería de reglas de Dragon para detección de Shellcodes . . . . . . . . . . . . . .
79
2.20. Firma de NFR para detección del histórico ataque Land Attack . . . . . . . . . .
79
2.21. Regla de MIDAS para monitorización de cuentas de usuario privilegiadas . . . . .
81
2.22. Regla de MIDAs para análisis de horario inusual en el acceso a cuentas de usuario
81
2.23. Base de hechos de P-BEST/EMERALD para detección del histórico ataque TCP
SYN Flood. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
2.24. Batería de reglas de P-BEST/EMERALD para detección del histórico ataque TCP
SYN Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
2.25. Escenario de STAT para detección de ataques contra servidores IMAP . . . . . .
84
2.26. Especicación en lenguaje STATL de escenario de STAT para detección de ataque
contra servidores IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
2.27. Reglas de Snort para detección de ataques contra servidores IMAP . . . . . . . .
85
2.28. Red de Petri de IDIOT para validación del proceso de login . . . . . . . . . . . .
85
2.29. Modelo general de Detección de Anomalías
. . . . . . . . . . . . . . . . . . . . .
88
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
2.31. Árbol de reglas de Wisdom and Sense . . . . . . . . . . . . . . . . . . . . . . . .
95
2.32. Aplicación de redes neuronales a Detección de Intrusiones . . . . . . . . . . . . .
96
2.33. Firma ISL de NFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
2.34. Batería de reglas ISL de P-BEST/EMERALD . . . . . . . . . . . . . . . . . . . .
98
2.35. Firma ISL del MIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
2.36. Red Bayesiana trivial de modelado de actividad intrusiva . . . . . . . . . . . . . .
99
2.30. Batería de reglas de TIM
2.37. Algoritmo Genético general, en pseudocódigo . . . . . . . . . . . . . . . . . . . . 100
2.38. Clasicaciones convencional y difusa de un parámetro de detección . . . . . . . . 101
2.39. Clasicación de eventos basada en máquina de vector soporte . . . . . . . . . . . 102
2.40. Modelo General de Detección de Intrusiones de Denning . . . . . . . . . . . . . . 107
2.41. Modelo General de Detección de Intrusiones de Denning . . . . . . . . . . . . . . 109
2.42. Representación conceptual de GrIDS de una epidemia vírica . . . . . . . . . . . . 110
2.43. Grafo de dependencia que puede seguirse realizando operaciones de BackTracking 116
2.44. Ciclo de vida de una vulnerabilidad en software . . . . . . . . . . . . . . . . . . . 120
2.45. Grafo de llamadas que se producen desde código fuente. . . . . . . . . . . . . . . 124
2.46. Grafo de llamadas entre librerías . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
2.47. Arquitectura bayesiana del sistema de detección de anomalías para host propuesto
en [95] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
2.48. Código fuente y grafo de ejecución presentado en el paper [141] . . . . . . . . . . 130
8
2.49. Arquitectura de un sistema de detección de intrusiones sin (izq) y con (dch) un
módulo de identicación del contexto de intrusiones (ICI) . . . . . . . . . . . . . 131
2.50. Set de datos utilizados para el FSG . . . . . . . . . . . . . . . . . . . . . . . . . . 133
2.51. Ejemplo de FSG para diferentes procesos . . . . . . . . . . . . . . . . . . . . . . . 133
2.52. Número de Secuencias Anómalas Mínimas (MFS) no duplicadas en todos los set
de datos intrusivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.53. Secuencias Anómalas Mínimas (MFS) compartidas por la misma intrusión en el
mismo proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.54. Entropía condicional del modelo de ventana deslizante . . . . . . . . . . . . . . . 137
2.55. Entropía condicional para una ventana de tamaño n
. . . . . . . . . . . . . . . 137
2.56. Ejemplo de grafo de llamadas al sistema . . . . . . . . . . . . . . . . . . . . . . . 139
2.57. Un árbol de sujos para el ejemplo de la cadena A B C C A B B C C A A B C . 141
2.58. Árbol de sujos con punteros de sujos incluidos . . . . . . . . . . . . . . . . . . 141
2.59. Árbol nal resultante de la compresión de la gura anterior . . . . . . . . . . . . 142
2.60. Ejemplo de código y representación de representación NFA . . . . . . . . . . . . . 143
2.61. Ejemplos de implementación de IAM . . . . . . . . . . . . . . . . . . . . . . . . . 143
2.62. Ejemplo de recursividad y autómata generado. . . . . . . . . . . . . . . . . . . . 144
2.63. Ejemplo de recursividad indirecta y autómata generado. . . . . . . . . . . . . . . 144
2.64. Ejemplo de código y modelo HPDA . . . . . . . . . . . . . . . . . . . . . . . . . . 145
2.65. Ejemplo de un programa en C asociado a un modelo de grafo de llamadas (NFA)
y un modelo NDPDA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
2.66. Proceso de llamada a getuid utilizando el modelo VSL. . . . . . . . . . . . . . . . 148
2.67. Proceso de llamada getuid utilizando el modelo VPStatic. . . . . . . . . . . . . . 149
2.68. Instalación del programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
2.69. Comprobación de las syscalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
2.70. Imagen de la arquitectura de los nuevos procesadores para terminales de tercera
generación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
2.71. Comunicación VMM asimétricos . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
2.72. Comunicación dinámica inter-dominio . . . . . . . . . . . . . . . . . . . . . . . . 154
2.73. ID de los registros del procesador lógico virtual . . . . . . . . . . . . . . . . . . . 154
2.74. Esquema de la propagación en poliárboles . . . . . . . . . . . . . . . . . . . . . . 159
2.75. Ejemplo de red naive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
2.76. Ejemplo de sustración de nodos en red Naive . . . . . . . . . . . . . . . . . . . . 162
2.77. Ejemplo de adición de un nodo a una red Naive . . . . . . . . . . . . . . . . . . . 163
2.78. Red bayesiana de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
2.79. Trayectoria Del Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
2.80. Cadena de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
2.81. Cadena de Markov representada como red bayesiana . . . . . . . . . . . . . . . . 185
9
2.82. Tablas de probabilidad condicionada . . . . . . . . . . . . . . . . . . . . . . . . . 186
2.83. Cadena de Markov y la evolución de sus estados. . . . . . . . . . . . . . . . . . . 190
2.84. Ejemplo de PHMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
2.85. Ejemplo de IDHMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
2.86. Ejemplo de HHMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
2.87. Ejemplo de integración de cadenas interrelacionadas . . . . . . . . . . . . . . . . 192
2.88. Otra aproximación para la integración de cadenas interracionadas . . . . . . . . . 192
2.89. Complejidad del algoritmo Fordward . . . . . . . . . . . . . . . . . . . . . . . . . 195
2.90. Complejidad del algoritmo de Backward . . . . . . . . . . . . . . . . . . . . . . . 196
2.91. Cálculo del algoritmo de Viterbi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
3.1. Imagen del monitor de anomalías desarrollado por Teresa F.Lunt y R. Jagannathan.214
3.2. Arquitectura interna de los sistemas operativos . . . . . . . . . . . . . . . . . . . 218
3.3. Abstracción a dos niveles en sistemas Linux . . . . . . . . . . . . . . . . . . . . . 219
3.4. Formato IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
3.5. Formato TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
3.6. Formato UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
3.7. Formato ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
3.8. Esquema de la estructura del kernel
. . . . . . . . . . . . . . . . . . . . . . . . . 231
3.9. Proceso de llamada a una syscall . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
3.10. Ejemplo utilización del comando strace . . . . . . . . . . . . . . . . . . . . . . . . 234
3.11. Esquema de llamada a una interrupción mediante interrupción . . . . . . . . . . 240
3.12. Logo de SuSE, distribución alemana, respaldada por la empresa Novell . . . . . . 241
3.13. Logo del agente de snare para sistemas GNU/Linux . . . . . . . . . . . . . . . . . 242
3.14. Esquema del formato Portable Ejecutable . . . . . . . . . . . . . . . . . . . . . . 254
3.15. Esquema de llamadas para ejecutar una operación a nivel de kernel.
. . . . . . . 255
3.16. Esquema de la información contenida en la estructura KDataStruct . . . . . . . . 256
3.17. Detalle de interfaz de usuario del agente. . . . . . . . . . . . . . . . . . . . . . . . 257
3.18. Esquema de memoria de NT, y posible puntos de recolección de datos. . . . . . . 261
3.19. Ejemplo de modicación de memoria en el punto de inicio . . . . . . . . . . . . . 264
3.20. Esquema de funcionamiento de la librería strace . . . . . . . . . . . . . . . . . . . 266
3.21. Monitorización de syscalls de un proceso infectado con el virus Satir.994 utilizando
strace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
3.22. Interfaz de usuario del agente, menús generales. . . . . . . . . . . . . . . . . . . . 269
3.23. Menú de selección de syscalls hookeadas . . . . . . . . . . . . . . . . . . . . . . . 269
3.24. Simplicación de la arquitectura de Symbian OS . . . . . . . . . . . . . . . . . . 270
3.25. Formato interno de los cheros ejecutables y librerías para Symbian OS . . . . . 272
3.26. Modelo simplicado de la arquitectura de procesadores de un terminal Symbian OS272
3.27. Capas del núcleo de Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
10
3.28. Llamada ejecutiva al kernel de Symbian OS . . . . . . . . . . . . . . . . . . . . . 274
3.29. Código fuente en el que se realiza la llamada para reservar una porción de memoria275
3.30. Arquitectura de los drivers de dispositivo simplicada
. . . . . . . . . . . . . . . 277
3.31. Selección de hilos en ejecución a interceptar . . . . . . . . . . . . . . . . . . . . . 278
3.32. Volcado de la memoria y de las peticiones que se realizan a la librería . . . . . . . 279
3.33. Detalles de un hilo en ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
3.34. Run-Mode Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
3.35. Ecuación del riesgo tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
3.36. Seguridad Perimetral (Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
3.37. Etapas en el proceso de detección
3.38. Logotipo de Snort
. . . . . . . . . . . . . . . . . . . . . . . . . . 284
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
3.39. Cabecera IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
3.40. Denición de patrones de uso indebido . . . . . . . . . . . . . . . . . . . . . . . . 290
3.41. Esquema de funcionamiento; Modelo de usos indebidos . . . . . . . . . . . . . . . 291
3.42. Ataque según la losofía de detección de anomalías . . . . . . . . . . . . . . . . . 292
3.43. Esquema de funcionamiento de un modelo de detección de anomalías . . . . . . . 294
3.44. IPS integrado en una red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
3.45. Taxonomía de los sistemas de detección de intrusiones . . . . . . . . . . . . . . . 301
3.46. Arquitectura de tres capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3.47. Correlacionando HIDS y NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
3.48. Estructura de dos capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
3.49. Estructura de tres capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
3.50. Estructura con plugins distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . 310
3.51. Estructura de Heads jerárquicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
3.52. Estructura de herencia de los plugins . . . . . . . . . . . . . . . . . . . . . . . . . 317
3.53. Clase PlugSkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
3.54. Clase ExpertSkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
3.55. Deln opciones de conguración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
3.56. Deln cambiando el modo de funcionamiento . . . . . . . . . . . . . . . . . . . . 322
3.57. Deln mostrando el modo de funcionamiento actual . . . . . . . . . . . . . . . . . 323
3.58. Listado de modos de funcionamiento de Deln . . . . . . . . . . . . . . . . . . . . 323
3.59. Deln ejemplo de una alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
3.60. eForwarder opciones de conguración . . . . . . . . . . . . . . . . . . . . . . . . . 325
3.61. eForwarder listado de modos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
3.62. eForwarer mostrando el modo de funcionamiento actual . . . . . . . . . . . . . . 326
3.63. eForwarder cambiando el modo de funcionamiento . . . . . . . . . . . . . . . . . 326
3.64. Stats, ejemplo de estadisticas de sistema. . . . . . . . . . . . . . . . . . . . . . . . 327
3.65. Head con un tail y dos masters conectados . . . . . . . . . . . . . . . . . . . . . . 347
11
3.66. Plugins cargados en el Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
3.67. Plugins cargados en el Tail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
3.68. Visualización de las alertas en el Head . . . . . . . . . . . . . . . . . . . . . . . . 349
3.69. Pantalla principal servidor WebOs . . . . . . . . . . . . . . . . . . . . . . . . . . 350
3.70. Graco del sysload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
3.71. Pantalla de información gráca sobre el Tail . . . . . . . . . . . . . . . . . . . . . 352
3.72. Pantalla de inicio de la consola . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
3.73. Comandos de consola para webOs . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
3.74. Pantalla de ayuda de la consola . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
3.75. Comandos de consola ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
3.76. Aprendizaje de Parámetros de las llamadas al Sistema . . . . . . . . . . . . . . . 364
3.77. Aprendizaje de Parámetros de las llamadas al Sistema . . . . . . . . . . . . . . . 365
3.78. Aprendizaje de Parámetros de las llamadas al Sistema . . . . . . . . . . . . . . . 366
3.79. Ejemplo de envío de alerta de ataque al telefono móvil (Respuesta pasiva). . . . . 370
3.80. Problemática de la respuesta activa en sistemas NIDS . . . . . . . . . . . . . . . 372
3.81. Ejemplo de arquitectura del sistema, que asegura la fortaleza del sistema mediante
VPNs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
12
Índice de cuadros
1.1. Utilización de Internet en las diferentes regiones del globo . . . . . . . . . . . . .
3
1.2. Utilización de Internet en las diferentes regiones del globo . . . . . . . . . . . . .
4
1.3. Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMarketer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4. Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMarketer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5. Áreas de investigación sobre Detección de Intrusiones con mayor actividad . . . .
35
2.1. Líneas de Investigación sobre Detección de Intrusiones . . . . . . . . . . . . . . .
64
2.2. Relación entre retos de la Detección de Intrusiones y líneas de investigación . . .
65
2.3. Métricas utilizadas en el sistema IDES de Detección de Intrusiones basada en perles 92
2.4. Tabla de probabilidades de la gura . . . . . . . . . . . . . . . . . . . . . . . . . 185
2.5. Implementación del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
3.1. Tipo y valores posibles de cada parámetro . . . . . . . . . . . . . . . . . . . . . . 224
3.2. Tipos y posibles parámetros del protocolo TCP . . . . . . . . . . . . . . . . . . . 225
3.3. Tipos y posibles parámetros de UDP . . . . . . . . . . . . . . . . . . . . . . . . . 226
3.4. Tipos y posibles parámetros ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 227
3.5. Tipo y parámetros de bajo nivel de Snort . . . . . . . . . . . . . . . . . . . . . . 227
3.6. Tipo y parámetros de alto nivel de Snort . . . . . . . . . . . . . . . . . . . . . . . 228
3.7. Parámetros que proponen Mahoney y Chan[364]. . . . . . . . . . . . . . . . . . . 228
3.9. Parámetros de alto nivel de Marina Bykova . . . . . . . . . . . . . . . . . . . . . 229
3.8. Parámetros y tipos de Marina Bykova . . . . . . . . . . . . . . . . . . . . . . . . 229
3.10. Fichero de compilación compileAll.sh . . . . . . . . . . . . . . . . . . . . . . . . . 334
3.11. Fichero slaveconf.xml del Head y del Tail
. . . . . . . . . . . . . . . . . . . . . . 335
3.12. Fichero oaconf.xml del head y del tail . . . . . . . . . . . . . . . . . . . . . . . . 337
3.13. Fichero webos.xml del Head y del Tail . . . . . . . . . . . . . . . . . . . . . . . . 338
3.14. Fichero reload.sh del Syshooker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
3.15. Fichero mastercong.xml del Syshooker . . . . . . . . . . . . . . . . . . . . . . . 340
3.16. Fichero dfsumcon.cfg del Snort Modicado . . . . . . . . . . . . . . . . . . . . . 341
3.17. Fichero run.sh del Snort Modicado . . . . . . . . . . . . . . . . . . . . . . . . . 341
13
3.18. Ejemplo de conguración del chero dfsumcong.cfg del Snort Modicado . . . . 344
3.19. Ejemplo de conguración del chero run.sh en el Snort Modicado . . . . . . . . 344
3.20. Ejemplo de conguración del chero mastercong.xml en el Syshooker . . . . . . 344
3.21. Ejemplo de conguración del archivo slaveconf.xml en el Head . . . . . . . . . . . 345
3.22. Ejemplo de conguración del chero slaveconf.xml en el Tail . . . . . . . . . . . . 346
3.23. Listado de llamadas al sistema por el PID 2d82b0aa . . . . . . . . . . . . . . . . 362
3.24. Listado de parámetros para realizar una llamada write en GNU/Linux . . . . . . 363
3.25. Listado de llamadas al sistema por el PID 2d82b0aa (recordatorio) . . . . . . . . 365
14
Listings
2.1. Ejemplo de un ataque Mimicry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
2.2. Hola esto es una prueba aquí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.1. Prototipo de función VirtualAlloc de la API Win32. . . . . . . . . . . . . . . . . 220
3.2. Prototipo de la función malloc para sistemas linux provista por el API de glibc. . 220
3.3. Prototipo de syscalls write (código 4) y kill (código 37) de sistemas GNU/linux . 221
3.4. Prototipo de la función NTCreateFile del kernel de Windows . . . . . . . . . . . 221
3.5. Ejemplo de programa en ensamblador . . . . . . . . . . . . . . . . . . . . . . . . 232
3.6. Ejemplo de la mejora con lenguaje C . . . . . . . . . . . . . . . . . . . . . . . . . 233
3.7. Macro para llamar a syscall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
3.8. Contenido de unistd.h los números de las syscalls . . . . . . . . . . . . . . . . . . 235
3.9. Denición de la IDT en linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
3.10. Inicialización de la IDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
3.11. Gestión de la interrupción 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
3.12. Gestión de la llamada sysenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
3.13. Prototipo de la función ptrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
3.14. Ejemplo de un módulo básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
3.15. Función que obtiene la base del vector de syscalls . . . . . . . . . . . . . . . . . . 245
3.16. Ejemplo de la intercepción de la syscall Kill . . . . . . . . . . . . . . . . . . . . . 246
3.17. Líneas que son sobreescritas con un salto a la función. . . . . . . . . . . . . . . . 248
3.18. Shellcode a la que saltamos cuando se llama a la función.
. . . . . . . . . . . . . 249
3.19. Ejemplo de la creación y destrucción de un dispositovo /proc. . . . . . . . . . . . 250
3.20. Código que permite saber el ejecutable padre del que proviene el proceso. . . . . 252
3.21. Utilizanción de int2Eh en Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 259
3.22. Utilizanción de int2Eh en Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 259
3.23. Denición de la clase hEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
3.24. Ejemplo para obtener el Identicativo de la CPU en ensamblador sobre sistemas
GNU/Linux en nomenclatura AT&T . . . . . . . . . . . . . . . . . . . . . . . . . 362
15
16
Capítulo 1
Introducción
17
Resumen
Internet se ha convertido en los últimos tiempos en un hábitat peligroso. Cada día que pasa
se desarrollan nuevas y cada vez más potentes herramientas destinadas a atacar sistemas de
información y redes de comunicación de todo tipo, y miles de ordenadores en todos los puntos
del planeta son asaltados diariamente. Desgraciadamente, aún no se ha encontrado una solución
al problema si bien, dentro del área de conocimiento de la Detección de Intrusiones, el campo
de la Detección de Anomalías se perla como un rme candidato, con grandes posibilidades de
erigirse en la tecnología de seguridad de la información por excelencia, a medio plazo.
Esta situación se acerca cada día más al usuario, conforme se avanza en la tecnología, el ser
humano tiene a su disposición cada vez más elementos susceptibles de ser atacados. Actualmente
ya se desarrollan sistemas de protección para dispositivos móviles por parte de grandes compañías,
pero el problema del mundo de Internet tradicional se encuentra desplazado encima de un nuevo
mercado: la portabilidad y el multiemplazamiento de los nuevos dispositivos.
1.1. El papel de la detección de Intrusiones en la Sociedad de la
Información
Hasta el momento, las investigaciones llevadas a cabo en el campo de la seguridad de la
información respecto de la cuestión del asalto subversivo e ilegítimo a sistemas informáticos, no
han aportado más que soluciones muy parciales al problema. En el momento de escribir estas
líneas, la magnitud de esta cuestión es tal que prestigiosos observatorios y centros de respuesta
temprana ante incidentes de seguridad, como pueden ser el Computer Emergency Response Team
Coordination Center1 CERT[60], el Equipo de Seguridad para la Coordinación de Emergencias en
Redes Telemáticas2 ESCERT [123], su homólogo IrisCERT [98], o el servicio Alerta-Antivirus
3
[23], se ven colapsados con cientos de miles de casos de intrusiones al año. De hecho, se ha llegado
a un punto en el que los datos estadísticos que ofrecen periódicamente dejan de ser realmente
signicativos.
Figura 1.1: Ratio de plataformas PC compatible infectadas en el mundo
Asimismo, otros grandes referentes como pueden ser las reconocidas listas de distribución
1
Puesto en marcha en 1.988 por iniciativa del Departamento de Defensa [109] estadounidense, a través de
la Defense Advanced Research Project Agency [94], y en colaboración con la Carnegie Mellon University [70].
Su constitución, el día 17 de Noviembre de 1.988, fue llevada a cabo con carácter de urgencia a raíz del ataque
informático perpetrado dos semanas antes por Robert Tappan Morris. Se estima que el mítico Gusano de Morris
llegó a infectar alrededor del 10 % de los servidores que en aquel momento estaban conectados a Internet en el
mundo [118]. El oscuro horizonte que se abría en un sector tan crítico como el informático hizo que el todopoderoso
Departamento de Defensa decidiera acometer esta iniciativa para tratar de minimizar los efectos de crisis similares
en el futuro.
2
Tanto esCERT como IrisCERT son dependientes de CERT/CC y tienen un ámbito de actuación circunscrito
al territorio español. Actualmente, esCERT se encuentra ubicado en la Universidad Politécnica de Cataluña,
mientras que IrisCERT está soportado por la iniciativa RedIris [178].
3
Servicio provisto por la entidad pública empresarial Red.es [295], adscrita al Ministerio de Industria, Turismo
y Comercio, a través de la Secretaría de Estado para las Telecomunicaciones y para la Sociedad de la Información.
2
Cuadro 1.1: Utilización de Internet en las diferentes regiones del globo
sobre cuestiones de seguridad SecurityFocus BugTraq [132] o Full Disclosure [108], o los observatorios privados pertenecientes a los grandes fabricantes mundiales de soluciones de seguridad,
como pueden ser Panda Software [324], Kaspersky [222] o Symantec [74], apuntan en la misma
dirección. A modo de ejemplo, sirva la gura 1.1 para ilustrar la problemática de la seguridad
en el mundo, según el Global Virus Observatory de Panda Software.
De esta forma, la conclusión es clara: En una sociedad de la información cuya realidad depende
cada vez más de la tecnología, como puede deducirse de las cifras de crecimiento del número de
usuarios conectados a Internet [181, 103, 333, 359, 99], o de los diferentes estudios realizados
al respecto por las grandes consultoras como Forrester [172] o Gartner [173], la seguridad de
la información es un campo de las Ciencias de la Computación que aún presenta importantes
deciencias. Deciencias que, además, inciden de forma extraordinariamente negativa en el uido
desarrollo de actividades cruciales para una evolución tecnológica plena como son el movimiento
de capitales en general y el comercio electrónico en particular. De estar resuelta la cuestión
de la conabilidad en el uso de las tecnologías de la información y las comunicaciones, dichas
actividades podrían llegar a altísimas cotas de progreso; tal y como se indica en la línea prioritaria
de investigación Towards a Global Dependability and Security Framework del VI Programa
Marco Europeo [72, 296], dentro del Espacio Europeo de Investigación.
A este respecto, las tablas 1.1 y 1.2 ilustran de forma signicativa el crecimiento del número
de usuarios a nivel mundial, según cifras de Internet World Stats [180, 179].
En la misma línea, las guras 1.2 y 1.3 ilustran el grado de utilización de Internet en la Unión
Europea por parte de empresas y organizaciones, y usuarios particulares, respectivamente, según
cifras de la European Statistical Data Support [333]. Existen ciertos países para los que no hay
datos disponibles, y que lógicamente no aparecen en dichas guras.
De forma análoga, pero ya en el ámbito nacional, la gura 1.4 ilustra el crecimiento del número
de usuarios y los porcentajes de penetración de Internet en el territorio español, durante los cinco
últimos años, según cifras de la consultora Tatum [99]. Por otro lado, en lo relativo a la creciente
relevancia que está adquiriendo el comercio electrónico a nivel mundial, la tabla 1.3 representa las
3
Cuadro 1.2: Utilización de Internet en las diferentes regiones del globo
Cuadro 1.3: Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMarketer
4
Figura 1.2: Utilización de Internet por parte de empresas y organizaciones con sede en la UE
Figura 1.3: Utilización de Internet por parte de individuos particulares residentes en la UE
5
Figura 1.4: Crecimiento del número de usuarios en el territorio español, en miles de usuarios
previsiones realizadas por tres de las mayores rmas multinacionales de consultoría tecnológica,
como son Forrester, IDC y eMarketer. Dichas previsiones están recogidas en el E-Commerce and
Development Report que Naciones Unidas publica anualmente [268, 267].
De la misma forma, en la tabla 1.4 puede observarse la tendencia de crecimiento prevista para
la Unión Europea, entre otras regiones del planeta, como son Latinoamérica, África, regiones
en vías de desarrollo de Asia y Región del Pacíco y otras regiones en vías de desarrollo, y
Norteamérica y otras regiones desarrolladas de Asia y Región del Pacíco [267].
Por último, en las guras 1.5 y 1.6 pueden observarse las últimas cifras publicadas por la
Comisión del Mercado de las Telecomunicaciones [103], relativas a la situación del comercio
electrónico en el territorio nacional.
Por otro lado, en lo relativo a la problemática de la seguridad propiamente dicha, son especialmente signicativas las tendencias observadas por CERT/CC [59], así como por el Federal
Bureau of Investigation [128] en colaboración con el Computer Security Institute [79] [129], y que
están representadas en las guras 1.7 y 1.8. Dichos datos deben servir como botón de muestra
del problema de la seguridad en los Estados Unidos de Norteamérica, si bien la situación en el
resto del orbe es análoga, como se desprende de los estudios realizados por los miembros del
prestigioso Honeynet Project [283]. Dicho proyecto tiene como objetivos la detección y análisis
de comportamientos no documentados, y por lo tanto de alto riesgo, en la actividad subversiva de
Internet, mediante el despliegue de una vasta red (Honeynet) de servidores señuelo o Honeypots4 .
De esta forma, han llegado a observarse, por ejemplo, redes domésticas atacadas diariamente en
más de treinta ocasiones, o casos de intrusión en dichos servidores señuelo a los quince minutos
4
Honeypot o Tarro de miel: Recurso informático cuyo valor reside en ser atacado, comprometido y analizado,
con el objeto de descubrir nuevas formas de ataques informáticos; según la denición de su autor, Lance Spitzner
[221]. Por su parte, el concepto Honeynet hace referencia, como es lógico, a una red de Honeypots.
6
Cuadro 1.4: Previsiones de crecimiento del Comercio Electrónico, según Forrester, IDC y eMarketer
Figura 1.5: Evolución del comercio electrónico durante los últimos años (en Euros)
7
Figura 1.6: Evolución del comercio electrónico durante los últimos años (en número de transacciones)
de su conexión a Internet [282, 202].
Como puede observarse en la gura 1.7, el crecimiento del número de incidentes de seguridad
observados por CERT/CC desde su puesta en marcha, presentó hasta el año 2.003 un crecimiento exponencial, que ha terminado haciendo que los responsables máximos decidieran eliminar
dicho parámetro de sus estudios anuales, para pasar a proporcionar conclusiones abstractas de
mayor utilidad. De nada sirve conocer el número de víctimas; lo verdaderamente importante es
concienciarse del problema de la seguridad y averiguar cómo evitar convertirse en una de ellas.
De esta forma, a partir de 2.004, CERT/CC publica, en colaboración con el United States
Secret Service [363] y la prestigiosa revista CSO Magazine [80], su E- Crime Watch Survey [265],
del cual ya ha visto la luz su primera edición. En él pueden observarse datos alarmantes, como
por ejemplo el 70 % de organizaciones estadounidenses encuestadas que registraron al menos un
caso de intrusión en el último año, o los más de seiscientos sesenta millones de dólares de pérdidas
económicas derivadas de actividad cracker5 que se estiman durante el mismo periodo de tiempo.
En la misma línea, tal y como puede observarse en la gura 1.8, el informe que anualmente
5
Cracker: Someone who tries to break the security of, and gain access to, someone else's system without
being invited to do so. Denición del RFC 2828 [288] del Internet Engineering Task Force [169]. Es un término
confundido habitualmente con el de Hacker: Someone with a strong interest in computers, who enjoys learning
about them and experimenting with them. En cualquier caso, las connotaciones delictivas que se han arrogado a
este término están tan extendidas, que se admite en general su uso.
8
Figura 1.7: Evolución del número de incidentes de seguridad reportados anualmente por CERT/CC
presentan FBI y CSI12 también revela datos escalofriantes sobre la cantidad de ataques informáticos que concluyen con éxito, si bien en este caso la tendencia que se advierte permite cierto
margen para el optimismo, al menos a medio plazo. No obstante, a pesar de ello, la situación
dista aún mucho de ser halagüeña, ya que más de la mitad (70 % en el año 2.000) de los organismos y grandes corporaciones estadounidenses encuestadas sufren anualmente al menos un
caso de intrusión. Ademýs, existe un importante número de ellas (alrededor del 10 %) que ni
siquiera es capaz de determinar con precisión si sus recursos computacionales y de comunicación
son accedidos subversivamente o no.
Asimismo, de los resultados obtenidos por el anteriormente mencionado Honeynet Project
pueden obtenerse conclusiones similares: La seguridad informática se mantiene en niveles de alto
riesgo y la actividad hacker crece desmesuradamente día a día, llegando a observarse crecimientos
del número de ataques en torno al 890 % anual. Sin embargo, también se observa cierta mejora en
las cifras de incidentes registrados, debido fundamentalmente a una creciente concienciación por
parte de usuarios, administradores de sistemas y desarrolladores de aplicaciones del problema de
la seguridad, así como a una mayor utilización de las tecnologías de seguridad disponibles. De
esta forma, ha podido observarse un importante progreso, por ejemplo, en la esperanza de vida
media de un servidor GNU/Linux conectado a Internet, que ha pasado de tan sólo 72 horas en
el año 2.000, a tres meses en la actualidad [282]. Por otro lado, existe un importante factor a
9
Figura 1.8: Evolución del número de incidentes de seguridad reportados anualmente por FBI y
CSI en su Computer Crime and Security Survey
tener en cuenta a la hora de analizar estos datos de crecimiento de la actividad subversiva en
la red, que es el nivel de preparación técnica que necesita el potencial intruso para atacar un
determinado sistema informático; factor que inuye directamente en el orden de magnitud de la
amenaza.
Así pues, a medida que la sosticación, la potencia y la facilidad de uso de las herramientas
de hacking crece, mayor es la población potencial de individuos susceptibles de convertirse en
agentes propagadores de todo tipo de epidemias informáticas. En los orígenes del delito informático era habitual observar cómo los responsables de los incidentes de seguridad seguían un
perl común en el que el elemento fundamental era su alto grado de preparación técnica y sus
vastos conocimientos sobre el funcionamiento a bajo nivel de sistemas, redes y arquitecturas6 . Sin
embargo, hoy día la situación ha cambiado y, si bien los desarrolladores últimos de herramientas, utilidades y técnicas de hacking siguen correspondiendo a ese perl de antaño, los usuarios
habituales de las mismas se encuentran a gran distancia de aquéllos7 . De esta forma, la amenaza
6
Tradicionalmente se ha utilizado el término Blackhat Hacker para hacer referencia a este tipo de atacante
de elite.
7
En la gura 1.9 se ilustra esta conclusión. Como puede observarse, cada vez es necesario un menor conocimiento
técnico para orquestar un ataque mucho más potente y efectivo. De hecho, esta situación ha dado origen a una
nueva especie de pirata informático: El Script Kiddie, caracterizado fundamentalmente por su baja preparación
técnica y su carencia de objetivos concretos; características que lo hacen especialmente peligroso, dada la gran
facilidad de uso de las nuevas herramientas de hacking y lo indiscriminado de sus acciones.
10
Figura 1.9: Relación entre el nivel de preparación del hacker y el grado de sosticación de sus
ataques, según estudios realizados por CERT/CC
general crece aceleradamente en nuestros días, y sólo es posible contener el número de incidentes
de seguridad mediante la concienciación e interiorización del problema por parte de los usuarios,
y mediante la utilización de las contramedidas adecuadas, en un proceso continuo de vigilancia
tecnológica [58].
Además, no sólo es relevante la amenaza que constituye esa amplísima población de usuarios
malintencionados, sino que también es necesario prestar especial atención a la ingente colección
de malware8 en forma de virus9 , gusanos10 , caballos de Troya11 y demás, que prolifera por
doquier. Las diferentes variantes de estos tipos de códigos malignos son capaces de lanzar los
anteriormente mencionados ataques de forma automática, infectando y extendiendo el ataque a
otros sistemas a gran velocidad12 , lo que incrementa en varios órdenes de magnitud su impacto
8
9
Malware: Malicious software o código maligno [220].
Virus: Hidden, self-replicating section of computer software, usually malicious logic, that propagates by
infecting (i.e., inserting a copy of itself into and becoming part of ) another program. A virus cannot run by itself;
it requires that its host program be run to make the virus active. Denición del SANS glossary of terms used in
security and intrusion detection [177].
10
18 Gusano o Worm: Computer program that can run independently, can propagate a complete working
version of itself onto other hosts on a network, and may consume computer resources destructively. [177]
11
19 Caballo de Troya (Troyano) o Trojan horse: Computer program that appears to have a useful function, but
also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting
legitimate authorizations of a system entity that invokes the program. [177]
12
Staniford-Chen, Moore, Paxson y Weaver [332] calculan que un gusano de alta velocidad (Flash Worm) podría
infectar el 95 % de una población de un millón de ordenadores vulnerables en 510 milisegundos, mediante tráco
11
potencial [332]. Un ejemplo interesante de este extremo puede ser el del lamentablemente popular
gusano Slammer21, considerado el caso de malware autopropagable más rápido de la historia.
Según los estudios realizados por David Moore, Vern Paxson et al. [253], dicho gusano llegaba
a duplicar la población de ordenadores infectados cada ocho segundos y medio. Qué decir de lo
absurdo de intentar enfrentarse manualmente a amenazas como el mencionado Slammer u otros
históricos como el Witty [88], el Code Red [254], o el Nimda [53], por ejemplo.
En la misma línea, las interesantes cifras publicadas por CERT/CC para el año 2.002, en el
cual se registraron un total de 5.500 vulnerabilidades13 en software de todo tipo, se hacían eco
de esta cuestión y revelaban, además, lo inabordable del problema no ya de la respuesta ante
este tipo de ataques, sino incluso simplemente de una cuestión tan trivial como la administración
de las actualizaciones de seguridad del software por el operador humano. De hecho, se estimaba
en 298 días de trabajo al año el esfuerzo que necesitaría un eciente administrador de sistemas
solamente para leer las descripciones de dichas vulnerabilidades y descargar y aplicar los parches
o hotxes correspondientes [58].
De esta forma, a raíz de esta problemática situación, surge inmediatamente y de forma natural
una conclusión lógica: Es necesario responder ante estos avasalladores ataques con mecanismos
tan automatizados o más que los del atacante, ya sea éste un intruso real o virtual, para poder
contrarrestar ecazmente su abrumador poder ofensivo; necesidad esta que se ha visto parcialmente satisfecha en los últimos tiempos gracias a la aparición y al continuo desarrollo del área de
conocimiento conocida como Detección de Intrusiones. Dicha área de conocimiento se ve materializada actualmente en los denominados Sistemas de Detección y Prevención de Intrusiones, y
cuenta ya con investigaciones sólidas y de reputada solvencia que incluso han evolucionado hacia
productos comerciales ampliamente extendidos. Sin embargo, los modelos de funcionamiento que
se han venido explorando con mayor intensidad parecen haber tocado techo, y se hace necesario prestar una mayor atención a otras líneas de investigación, como puede ser la Detección de
Anomalías. De esta forma, será posible tratar ciertas cuestiones que hasta ahora han pasado desapercibidas y que pueden resolver las deciencias que tradicionalmente han venido presentando
dichos modelos [340, 297, 28, 15, 84]. Así, con el objetivo de cubrir esta necesidad y dar un paso
más allá en el Área de la Detección de Intrusiones se ha planteado y llevado a cabo el presente
desarrollo.
1.2. El papel innovador de la Detección de Intrusiones para dispositivos móviles
Expertos en seguridad de todo el mundo alertan sobre el crecimiento extraordinario de virus,
gusanos y troyanos que han encontrado en los terminales de telefonía móvil un nuevo objetivo
UDP. En el caso de utilizar tráco TCP serían necesarios 1,3 segundos.
13
Vulnerabilidad o Vulnerability: A aw or weakness in a system's design, implementation, or operation and
management that could be exploited to violate the system's security policy. [288]
12
a atacar, y sólo es cuestión de tiempo que alcancen las cifras de pérdidas económicas de sus
homólogos cableados, según arman especialistas como Aaron Davidson, Chief Executive Ocer de SimWorks International, uno de los grandes fabricantes mundiales de servicios móviles,
Bruce Hughes, investigador de la compañía TruSecure, o Norman Bennett, Gerente General de
Symantec Corporation; dos de los grandes fabricantes de soluciones de seguridad.
Así pues, son muchos los fraudes que puede perpetrar esta nueva generación de ataques
informáticos, y contra los que actualmente no existen soluciones de seguridad, con la honrosa
excepción de dos embrionarias herramientas antivirus como son F-Secure Mobile y Kaspersky, que
aún tienen un marcado carácter experimental. De esta forma, un hacker puede infectar el móvil de
un usuario mediante un código malicioso (malware) que realice arbitrariamente establecimientos
de llamadas (con las consiguientes pérdidas económicas), envíos masivos de SMS, MMS, etc. (el
denominado robo de servicio), o incluso espionaje de la información sensible (datos privados,
información bancaria, claves de acceso, etc.) almacenada en la memoria de dicho terminal.
Asimismo, es posible la automatización de estos ataques, lo que ha dado origen a una nueva
generación de gusanos auto-propagables, que pueden reenviarse, por ejemplo, a la lista de contactos; aunque, a través de protocolos wireless como Bluetooth u 802.11a/b/g [Wi-Fi], ni siquiera
es necesario este pequeño conocimiento previo de las víctimas (Overview de vulnerabilidades de
Securityfocus).
Por otro lado, y entrando en un área tecnológica también en creciente expansión, cada vez
son más los dispositivos y soluciones domóticas y de inteligencia ambiental (Ambiental Intelligence, AmI) que abogan por la utilización de tecnologías y protocolos móviles para resolver sus
requisitos de interoperabilidad y conectividad, por lo que, en caso de intrusión, no sólo quedaría
en compromiso el teléfono del usuario, sino toda su red doméstica.
Por último, también son posibles ataques de denegación de servicio [DoS] que inutilicen un
teléfono o dispositivo, o que saturen hasta la inoperancia el ancho de banda de la red telefónica. En este ámbito, existe un terminal especialmente amenazado: El teléfono con soporte lógico
de aplicaciones basado en Sistema Operativo, como Windows Mobile, o Symbian. Estos móviles tienen conectividad total con Internet, funcionan como mini-ordenadores, y pueden alojar
programas (que perfectamente pueden ser subversivos) como cualquier PC; de forma que heredan automáticamente las problemáticas de seguridad que tradicionalmente han venido sufriendo
éstos.
Además, según varias consultoras tecnológicas como Gartner, Nielsen-NetRatings o IDC, el
crecimiento en el número de ventas de estos dispositivos que se espera es extraordinario. Por
ejemplo, según la rma IDC, el número de estos aparatos vendidos en 2008 puede superar los
130 millones de unidades, un 15 % del parque mundial. Según ARC Group, en 2004 se vendieron
27 millones de unidades, casi el 5 % del total de móviles vendidos en todo el mundo. Las cifras
de la rma británica Canalys, que tratan los dos grandes tipos de terminales: los de voz (móviles
sincronizables con PC y Smartphones con posibilidad de cargar aplicaciones) y los de datos
13
(Handhelds o PDAs, con o sin conexión inalámbrica a redes); muestran crecimientos de hasta
un 101 % en el caso de los teléfonos móviles y de un 5 % en el caso de los PDA. Asimismo, el
fabricante PalmOne (líder del mercado) obtuvo unas ventas de 1.503.590 equipos en el último
cuarto de 2004, un 8 % más que en 2003, e incrementó un 154 % las ventas de sus conocidos
terminales Treo.
Por otro lado, según cifras de IDC, cada semana se venden en todo el mundo alrededor
de tres millones de dispositivos con tecnología inalámbrica Bluetooth (especialmente sensible a
manipulaciones subversivas), incluyendo no sólo teléfonos móviles, sino también componentes de
automoción, dispositivos domóticos, accesorios informáticos, etcétera, etcétera, y se preveía para
2008 un parque de unos 922 millones de unidades en todo el mundo. También es importante,
ya en un ámbito más local, el crecimiento de líneas UMTS que se espera en el estado: Según el
consejero delegado de Telefónica Móviles, Javier Aguilera, "Esperamos que en 2005 haya más de
un millón de líneas". A lo que hay que añadir, además del crecimiento del mercado mundial, los
más de 300 millones de Euros que preveía invertir Amena, y los 1700 de Telefónica Movistar.
Por otro lado, según consultoras como Tatum o Nielsen-NetRatings, u organizaciones como
la International Telecommunication Union (ITU), el previsible aumento de transacciones económicas realizadas a través de móviles es susceptible de convertirse en el principal motor del
malware móvil, al igual que ocurrió con el auge del e-business en el mundo. Los distintos tipos
de gusanos, virus y demás, permitirán el acceso a contraseñas, información bancaria o datos corporativos de millones de clientes que comienzan realmente a usar el móvil para realizar compras
y operaciones nancieras, sobre todo en Europa y Japón. Se estima que en 2004 más de cuatro
millones de personas usaron el teléfono móvil en el estado para pagar sus compras, según cifras
de la Comisión del Mercado de las Telecomunicaciones.
Por último, también es importante prestar atención al impacto que ESIDE-Mendizale puede
producir en el tejido empresarial vasco, siendo dos las incidencias positivas se detectan a priori:
Por un lado, este proyecto y los estudios sobre los que se basa pueden servir como base para
el desarrollo de un producto de calidad de protección de terminales móviles, precisamente en
un momento en el que la coyuntura mundial y local es muy favorable. Qué decir tiene que un
fabricante de soluciones de seguridad como Panda Software (recientemente galardonada con el
premio "Con mucho gusto" del Departamento de Industria, Comercio y Turismo del Gobierno
Vasco), una las grandes empresas fabricantes de soluciones de seguridad informática a nivel
mundial, y con la que la Facultad de Ingeniería - ESIDE mantiene unas estrechas relaciones,
adquiriría una considerable ventaja competitiva a raíz de este estudio, adelantándose a aquellos
competidores que aún no han contemplado la cuestión móvil entre sus prioridades.
Por otro lado, la cuestión de la seguridad es un problema cada vez más acuciante para organizaciones y empresas que cada vez más hacen uso de soluciones de movilidad para proporcionar
mayor exibilidad a sus procesos de negocio, y aunque existen herramientas que aportan cierta
seguridad, se está aún muy lejos de una solución denitiva.
14
Este proyecto puede sentar las bases para el desarrollo de una arquitectura de seguridad robusta, exible y económica, que reduzca las pérdidas por hacking móvil a su mínima expresión.
Además, este proyecto está orientado a servir como solución a un problema ampliamente extendido en empresas, organizaciones y usuarios particulares con todo tipo de perles, por lo que su
área potencial de implantación es muy amplia.
Así pues, ante un considerable volumen de actividad, es posible plantear una línea de servicio
en un operador de telefonía como puede ser Euskaltel (con quien la Facultad de Ingeniería ESIDE mantiene unas estrechas relaciones), que se vería en situación de poder ofrecer un servicio
de seguridad diferenciador y de valor añadido a sus clientes.
Realmente los benecios que se conseguirían gracias a la reducción drástica de las pérdidas
económicas debidas al acceso ilegítimo de intrusos a los recursos móviles de empresas y particulares, podrían llegar a ser muy importantes a medio plazo.
Para nalizar, también es interesante tener en cuenta los benecios que podría reportar
ESIDE-Mendizale a aquellas empresas que emplean a los alumnos del Máster en Seguridad de la
Información que se desarrolla en la Facultad de Ingeniería - ESIDE. Dicho Máster en Seguridad de
la Información acoge todos los años a un buen número de alumnos, que posteriormente incorporan
los conocimientos adquiridos a su trabajo cotidiano en empresas como Panda Software, Euskaltel,
IT-Deusto, Vodafone o Telefónica Movistar.
A este respecto, tal y como se ha hecho con los resultados del proyecto ESIDE-Depian (subvencionado por Diputación Foral de Bizkaia a través de del programa Bizkaitek 2004) se pretende
incluir en el módulo relativo a técnicas IDS/IPS un epígrafe con resultados y conclusiones obtenidas en el proyecto, lo que redundará aún más en la difusión de los mismos.
1.3. Conceptos Fundamentales
Es importante presentar algunos conceptos básicos, sobre los cuales está basada la presente
memoria de proyecto. En primer lugar se denen algunos conceptos fundamentales de Seguridad de la Información, y a continuación se pasa a denir conceptos básicos de Detección de
Intrusiones.
1.3.1. Conceptos Fundamentales de la Seguridad de la Información
A pesar de que en el Área de la Seguridad de la Información no existe un acuerdo universal
sobre el propio concepto de Seguridad, una denición plausible puede ser la que proporciona el
RFC2828 [288]:
Denición 1.1, Seguridad:
(1) Measures taken to protect a system. (2) The condition of a
system that results from the establishment and maintenance of measures to protect the system.
(3) The condition of system resources being free from unauthorized access and from
15
unauthorized or accidental change, destruction, or loss.14 La cual da paso de forma natural al siguiente concepto:
Denición 1.2, Seguridad de la Información:
The protection of data from disclosure,
alteration, destruction, or loss that either is accidental or is intentional but unauthorized.
15
No obstante, es posible obtener una denición más representativa del concepto a partir de
la evolución que ha sufrido el mismo hasta nuestros días. En un primer momento el área de
conocimiento de la Seguridad de la Información tenía como objetivo fundamental la protección
de dicha información contra accesos no autorizados; es decir, ser garante de la condencialidad
de la misma. Sin embargo, con la proliferación de redes de comunicación como Internet, y el
alto grado de conectividad que proporcionan, además, apareció la necesidad de proteger esa
misma información contra modicaciones o alteraciones no autorizadas. Surgió de esa forma un
segundo objetivo: Era necesario garantizar también la integridad de la información. Además,
dichas redes de comunicación también propiciaban cierto tipo de agresiones, conocidas como
ataques de denegación de servicio16 , que imposibilitaban el legítimo acceso a la información,
simplemente saturando el sistema informático hasta la inoperancia; de forma que fue necesario
incorporar a la denición de Seguridad de la Información el concepto de disponibilidad para
incluir esta cuestión. Finalmente, con el extraordinario desarrollo que han venido presentando
las transacciones económicas electrónicas, han aparecido dos nuevas problemáticas. Por un lado,
es necesario prestar especial atención a la cuestión de la autenticación de las partes implicadas
en dichas transacciones. Además, también es perentorio garantizar la responsabilidad de las
acciones tomadas por dichas partes. No puede darse la posibilidad de que los hechos de una de
las entidades implicadas en una transacción, sean repudiados por dicha entidad.
De esta forma, podemos encontrar una excelente denición de Seguridad de la Información
en la conferencia que pronunció Danniel G. Wolf [139], Information Assurance Director de la
National Security Agency [262], en el Federal Information Security Reform Act 2.002, la cual se
incluye a continuación, adaptada por cuestión de espacio17 :
Denición 1.3, Seguridad de la Información:
The condition of a system that results from
the establishment and maintenance of measures that assure information condentiality and
14
Como puede observarse, el RFC2828 proporciona tres deniciones, cada una de las cuales adquiere un mayor
nivel de concreción respecto a las precedentes: (1) Conjunto de medidas utilizadas para proteger un sistema. (2)
Estado de un sistema que resulta del establecimiento y mantenimiento de medidas de protección para dicho sistema. (3) Estado en el que los recursos de un sistema se encuentran libres del peligro de ser accedidos, modicados,
destruidos o dañados sin autorización.
15
Protección de los datos contra la divulgación, alteración, destrucción o menoscabo, ya sean éstas accidentales,
o intencionadas pero no autorizadas.
16
Denegación de servicio o Denial of Service: The prevention of authorized access to a system resource or the
delaying of system operations and functions. [288]
17
Lindqvist introduce idénticas reexiones en la denición de Seguridad de la Información que propone en su
tesis doctoral [358].
16
integrity, availability, authenticity and non-repudiation in computer and communication
systems.18 De hecho, Wolf va más allá del concepto tradicional e incluye las cuestiones de la detección
de intrusiones y la respuesta automática ante ellas como parte fundamental de la protección de
la información; tal es la importancia que está alcanzando este campo en el área de la Seguridad
de la Información:
Denición de Wolf, Seguridad de la Información:
In an age of constant probes and
attacks of on-line networks, however, an increasingly important element of protection deals with
operational responsiveness in terms of detecting and reacting to these time-sensitive events.
19
Una vez desarrollado el concepto fundamental, existe toda una colección de términos a su
alrededor, los cuales pueden consultarse en la abundante bibliografía al respecto [127, 177, 151,
352, 288][OSSTMM03]. A continuación, se incluyen los más importantes y sobre los que está
basada la anterior denición de Seguridad de la Información [288]:
Denición 1.4, Condencialidad:
The property that information is not made available or
disclosed to unauthorized individuals, entities, or processes; i.e., to any unauthorized system
entity.20 Denición 1.5, Integridad:
The property that data has not been changed, destroyed, or lost
in an unauthorized or accidental manner.21 Denición 1.6, Disponibilidad:
The property of a system or a system resource being
accessible and usable upon demand by an authorized system entity, according to performance
specications for the system; i.e., a system is available if it provides services according to the
system design whenever users request them.22 Denición 1.7, Autenticidad:
The property of being genuine and able to be veried and be
trusted.23 18
Estado de un sistema que resulta del establecimiento y mantenimiento de medidas de seguridad que aseguran
la condencialidad e integridad de la información, así como disponibilidad, autenticidad y no repudio en sistemas
de computación y de comunicaciones.
19
En una época de constantes rastreos y ataques contra redes de comunicación, un aspecto de seguridad cada
vez más importante es el de presentar una respuesta operativa, en términos de detectar y reaccionar ante esos
eventos que se producen en tiempo real.
20
Propiedad por la cual la información no se hace disponible ni se divulga a individuos, entidades o procesos
no autorizados; esto es, a cualquier entidad del sistema.
21
22
Propiedad por la cual los datos no se modican, destruyen o dañan, de forma no autorizada o accidental.
Propiedad de un sistema o de un recurso de sistema de ser utilizable ante la demanda de una entidad de
sistema autorizada, de acuerdo con las especicaciones de rendimiento de dicho sistema; esto es, un sistema es
disponible si proporciona sus servicios de acuerdo a su diseño en cualquier momento en el que los usuarios lo
soliciten.
23
Propiedad de ser genuino y hábil para ser vericado y recibir conanza.
17
Denial by a system entity that was involved in an association
Denición 1.8, Repudio:
(especially an association that transfers information) of having participated in the
relationship.24 1.3.2. Conceptos de Detección de Intrusiones
A continuación se describen los términos fundamentales de Detección de Intrusiones sobre
los cuales está basado el presente trabajo de investigación, y que se utilizarán frecuentemente a
lo largo de esta memoria [288]:
Denición 1.9, Ataque:
An assault on system security that derives from an intelligent
threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method
or technique) to evade security services and violate the security policy of a system.25 Denición 1.10, Intruso:
An entity that gains or attempts to gain access to a system or
system resource without having authorization to do so.26 Denición 1.11, Intrusión:
A security event, or a combination of multiple security events,
that constitutes a security incident in which an intruder gains, or attempts to gain, access to a
system (or system resource) without having authorization to do so.27 Respecto a la denición de Intrusión, también es interesante prestar atención a la propuesta
por Zamboni [92], en la cual se relaciona explícitamente la intencionalidad de la denición de
Shirey con los conceptos de Seguridad de la Información descritos anteriormente:
Denición 1.12, Intrusión:
Any set of actions that attempt to compromise the integrity,
condentiality, or availability of a computer resource.28
29
24
Negativa de una entidad de sistema de haber estado involucrada en una asociación (especialmente en una
asociación que implique transferencia de información) o de haber participado en dicha relación.
25
Asalto a la seguridad de un sistema que tiene su origen en una amenaza inteligente; esto es, un acto intelectual
que debe considerarse como un deliberado intento (especialmente en la medida en que se utiliza un método o una
técnica) de evadir los servicios de seguridad y violar la política de seguridad de dicho sistema.
26
Entidad que consigue o intenta conseguir acceso a un sistema o recurso de sistema sin tener autorización para
hacerlo.
27
Evento de seguridad, o combinación de múltiples eventos de seguridad, que constituye un incidente de segu-
ridad en el cual un intruso consigue, o intenta conseguir, acceso a un sistema (o recurso de sistema) sin tener
autorización para hacerlo.
28
Cualquier conjunto de acciones que intente poner en compromiso la integridad, condencialidad o disponibi-
lidad de un recurso computacional.
29
Como puede observarse, la denición de Zamboni no incluye los conceptos de Wolf de autenticidad y no
repudio. A pesar de que esa primera denición es menos exhaustiva, es la que aparece de forma generalizada en
la bibliografía.
18
Denición 1.13, Detección de Intrusiones:
A security service that monitors and analyzes
system events for the purpose of nding, and providing real-time or near real-time warning of,
attempts to access system resources in an unauthorized manner.30 A pesar de que la denición de Detección de Intrusiones proporcionada por el RFC2828 es
completa y perfectamente contrastada, existen algunas cuestiones que no se abordan completamente. Por ello, es interesante prestar atención a otras alternativas, entre las cuales se encuentra
la excelente denición de Rebecca Bace [28], que se incluye a continuación:
Denición 1.14, Detección de Intrusiones:
Intrusion detection is the process of
monitoring the events occurring in a computer system or network and analyzing them for signs
of intrusions, dened as attempts to compromise the condentiality, integrity, availability, or to
bypass the security mechanisms of a computer or network. Intrusions are caused by attackers
accessing the systems from the Internet, authorized users of the systems who attempt to gain
additional privileges for which they are not authorized, and authorized users who misuse the
privileges given them. Intrusion Detection Systems (IDSs) are software or hardware products
that automate this monitoring and analysis process.
31
Por otro lado, también es interesante observar la denición que proporciona el Instituto
SANS [177], ya que introduce una primera clasicación de Sistemas de Detección de Intrusiones,
en función del origen de los ataques a detectar:
Denición 1.15, Detección de Intrusiones:
Security management system for computers
and networks. An Intrusion Detection System gathers and analyzes information from various
areas within a computer or a network to identify possible security breaches, which include both
intrusions (attacks from outside the organization) and misuse (attacks from within the
organization).
32
De forma natural, esta denición de la expresión Detección de Intrusiones, como término
genérico que da nombre a un área de conocimiento, introduce el concepto Sistema de Detección
30
Servicio de seguridad que monitoriza y analiza los eventos del sistema con el propósito de encontrar intentos
de acceso a recursos de sistema de forma no autorizada, y proporcionar aviso en tiempo real (o cerca del tiempo
real) sobre ellos.
31
Detección de Intrusiones es el proceso de monitorizar los eventos que se dan en un sistema de computación
o en una red de comunicaciones, y analizarlos en busca de signos de intrusión; denidos éstos como intentos de
poner en compromiso la condencialidad, integridad o disponibilidad, o de evadir los mecanismos de seguridad
de dicho sistema o red. Dichas intrusiones son causadas por atacantes que consiguen acceder a sistemas desde
Internet, por usuarios autorizados de dichos sistemas que intentan obtener privilegios adicionales para los cuales
no están autorizados, o por usuarios autorizados que hacen un mal uso de los privilegios que se les han otorgado.
Por otro lado, los Sistemas de Detección de Intrusiones (IDS) son productos software o hardware que automatizan
este proceso de monitorización y análisis.
32
Sistema de gestión de la seguridad para computadores y redes. Un Sistema de Detección de Intrusiones
recoge y analiza información de diferentes áreas dentro de dicho computador o red, con el objetivo de identicar
posibles brechas de seguridad, entre las cuales se incluyen tanto intrusiones (ataques provenientes del exterior de
la organización) como usos indebidos (ataques provenientes del interior de dicha organización).
19
de Intrusiones, como realización instrumental del mismo. Bace ya daba paso a esta cuestión en
la denición anterior, si bien existen otras que tratan especícamente dicho concepto, como por
ejemplo la que da Zamboni en su tesis doctoral:
Denición 1.16, Sistema de Detección de Intrusiones:
A computer system (possibly a
combination of software and hardware) that attempts to perform intrusion detection.33 Por último, existe un concepto que adquiere especial relevancia en el presente trabajo de
investigación, ya que es la piedra angular sobre la cual se ha desarrollado el mismo, y que
se denomina Detección de Anomalías. El exhaustivo documento recopilatorio de Julia Allen
[15] recoge una excelente denición, si bien es un concepto que se desarrollará en profundidad
posteriormente:
Denición 1.17, Sistema de Detección de Anomalías:
Analysis method that identies
any unacceptable deviation from expected behavior. Expected behavior is dened, in advance,
by a manually developed proleor by an automatically developed prole. An automatically
developed prole is created by software that collects and processes characteristics of system
behavior over time and forms a statistically valid sample of such behavior. Note that
unexpected behavior is not necessarily an attack; it may represent new, legitimate behavior
that needs to be added to the category of expected behavior.
34
1.3.3. Modelo general de funcionamiento
Desde la aparición de la Detección de Intrusiones a principios de la década de los ochenta
[20] y hasta nuestros días, los diferentes enfoques propuestos han venido manteniendo, a pesar de
sus lógicas particularidades, un esquema de funcionamiento común. Por lo general, las responsabilidades de todo Sistema de Detección de Intrusiones son la captura de datos del sistema de
información, el análisis de dichos datos en el intento de detectar algún tipo de actividad subversiva a partir de ellos, y el proporcionar una respuesta ante aquellas situaciones susceptibles de
comprometer la seguridad del sistema. De esta forma, un primer modelo general de funcionamiento quedará compuesto por estos tres pilares fundamentales: Recogida de información, Análisis y
Respuesta [116, 351, 17, 28, 334, 26, 100, 204, 84, 216, 154]. La gura 1.10 describe dicho modelo
general.
33
Sistema de computación (posiblemente combinación de software y hardware) que intenta llevar a cabo la tarea
de detectar intrusiones.
34
Método de análisis que identica cualquier desviación inaceptable respecto del comportamiento esperado.
Dicho comportamiento se dene, a priori, mediante un perl que puede construirse manual o automáticamente.
Un perl construido automáticamente se realiza mediante un software que recoge y procesa características del
comportamiento del sistema a lo largo del tiempo, y que produce un modelo estadístico de dicho comportamiento.
Es interesante observar que un comportamiento no esperado no es necesariamente un ataque; simplemente puede
representar nuevo y legítimo comportamiento que necesitará ser incorporado a la categoría de comportamiento
esperado.
20
Figura 1.10: Modelo General de Funcionamiento
Como puede observarse, las tres fases de este modelo se llevan a cabo de forma secuencial
y por lo general ininterrumpida, ya que la mayoría de Sistemas de Detección de Intrusiones se
plantean el objetivo de responder ante los diferentes eventos del sistema en tiempo real [255].
Por otro lado, esta división en fases del modelo general, introduce una categorización de los
diferentes tipos de Sistemas de Detección de Intrusiones, en función de la losofía de diseño que
se sigue en cada una de ellas. De esta manera, existen diferentes tipos de Sistemas de Detección
de Intrusiones dependiendo de la fuente de información utilizada durante el proceso de recogida
de información, dependiendo de la losofía de análisis que se sigue a la hora de determinar si un
determinado comportamiento es legítimo o subversivo, y en función también del tipo de respuesta
que se proporciona.
Así pues, existen dos fuentes de información fundamentales, que introducen una primera categorización. El objetivo fundamental de la fase de recogida de información es obtener y registrar
todo aquel dato que sea susceptible de haber tenido cualquier tipo de relación con las acciones de
los usuarios del sistema. A continuación, a partir de esos datos, la fase de análisis deberá decidir
qué comportamientos están justicados y cuáles no, y por último la fase de respuesta actuará
en consecuencia. Para ello, en todo sistema informático, existen dos lugares fundamentales de
los cuales es posible extraer este tipo de información [116, 205, 340, 336, 240, 26, 100, 204]. Por
un lado, las acciones de todo usuario quedan registradas por el servicio de auditoría del Sistema
Operativo o por los registros históricos de los servicios de aplicación que corren en una determinada máquina35 , de forma que ésta se convierte precisamente en el primer punto natural del
cual obtener información para el proceso de análisis. Esta ubicación da origen a los denominados
Sistemas de Detección de Intrusiones orientados a la Máquina, e introduce la siguiente denición
[177]:
Denición 1.18, Sistema de Detección de Intrusiones orientado a la Máquina (Host
Intrusion Detection System):
35
Intrusion detection systems that use information from the
Algunas fuentes [351, 92, 28, 15, 84, 50] consideran que esta forma de recogida de información constituye por
sí misma una tercera categoría de Sistema de Detección de Intrusiones.
21
operating system audit records to watch all operations occurring on the host that the intrusion
detection software has been installed upon.36 [...]
Por otro lado, dado el extraordinario grado de conectividad que presentan hoy en día los
sistemas de información [58], es difícil que se dé el caso de un intruso que acceda físicamente a
su víctima, y sin embargo es mucho más probable que su asalto se realice a través de algún tipo
de red de comunicación. De esta forma, el tráco de red se convierte en el medio de transporte
habitual de las órdenes que dicho intruso envía hacia el sistema atacado, y por lo tanto en el
segundo punto lógico de captura de información. Análogamente al caso anterior, esta ubicación
da origen a los denominados Sistemas de Detección de Intrusiones orientados a la Red, e introduce
su correspondiente denición [177]:
Denición 1.19, Sistema de Detección de Intrusiones orientado a la Red (Network
Intrusion Detection System):
Intrusion Detection System that monitors the trac on its
network segment as a data source.37 [...]
Cada uno de estos enfoques presenta sus particularidades, sus ventajas, sus capacidades, sus
inconvenientes y sus limitaciones; aspectos todos ellos que serán tratados en profundidad más
adelante. En general, los sistemas orientados a la máquina consiguen una mayor precisión en
la decisión de análisis, a costa de circunscribir su ámbito de actuación al sistema que protegen
[336, 240]. Asimismo, dependen enormemente de la plataforma software sobre la cual operan.
Por su parte, los sistemas orientados a la red son capaces de salvaguardar por sí mismos redes
enteras de ordenadores, si bien no tienen la precisión de los anteriores y no resuelven por lo
general ciertos problemas, como el análisis de tráco de red cifrado [17, 28, 15, 26].
Por otro lado, la fase de análisis también presenta una clara dicotomía38 , en función del
método de análisis que se emplea [116, 351, 17, 28, 388, 100, 204, 84, 216]. Por un lado, es habitual utilizar técnicas de Inteligencia Articial basadas en reconocimiento de patrones39 , para
representar todo el conocimiento de que se dispone sobre la actividad subversiva que se pretende
detectar. Así, es posible construir una lista negra40 que incluye todos los comportamientos maliciosos conocidos hasta el momento, para a continuación pasar a contrastar la actividad cotidiana
de los usuarios del sistema con dicha lista.
Esta losofía de detección se denomina Detección de Usos Indebidos o Detección basada en
Conocimiento41 , y se caracteriza por su elevada precisión a la hora de decidir la legitimidad
36
Sistema de Detección de Intrusiones que usa información del registro de auditoría del sistema operativo para
observar todas las operaciones que tienen lugar en la máquina en la que está instalado el software de detección
de intrusiones.
37
38
Sistema de Detección de Intrusiones que monitoriza el tráco de su segmento de red como fuente de datos.
Algunas fuentes establecen una tercera categoría, denominada Detección de Anomalías de Protocolo [Go-
lomb03, Das01, Axelsson00].
39
Reconocimiento de patrones o pattern matching. En el área de la Detección de Intrusiones también se utiliza
habitualmente el concepto de rma o signature.
40
Lista negra o blacklist.
41
Detección basada en Conocimiento o Knowledge-based Detection.
22
de una determinada acción. Sin embargo, adolece de ciertos problemas, entre los cuales el más
relevante es su absoluta falta de respuesta ante ataques aún no documentados. Un intruso puede
construir una ligera variante de un ataque clásico, o por supuesto un ataque completamente
nuevo, y evadir así la vigilancia del Sistema de Detección de Intrusiones. Rebecca Bace y Peter
Mell proponen una buena denición [28]:
Denición 1.20, Detección de Usos Indebidos (Misuse Detection):
Detection method
that analyzes system activity, looking for events or sets of events that match a predened
pattern of events that describe a known attack.42 [...]
Otro método de detección, que precisamente trata de ir más allá de las limitaciones inherentes
a los métodos de Detección de Usos Indebidos, y conseguir que los Sistemas de Detección de
Intrusiones puedan responder ante ataques novedosos43 , no documentados, es la Detección de
Anomalías o Detección basada en Comportamiento44 . Esta losofía de detección también está
basada en técnicas de Inteligencia Articial, pero plantea una forma de análisis complementaria a
la anterior. En lugar de utilizar el conocimiento subversivo conocido para llevar a cabo el proceso
de decisión, utiliza el conocimiento legítimo45 . De esta forma, a partir de las acciones habituales
de los usuarios, se construye un perl de comportamiento que posteriormente es contrastado con
la actividad cotidiana que se registra durante la explotación normal del sistema.
Así, es posible detectar acciones que se salen de la forma de proceder habitual de dichos
usuarios; acciones entre las cuales se encuentran los novedosos modos de ataque mencionados
anteriormente. A este respecto, es importante destacar el hecho de que con este modo de operación
se consigue que el proceso de detección sea completo [100]; característica de la que adolecen los
sistemas de Detección de Usos Indebidos. Además de la denición enunciada por Julia Allen e
incluida en el apartado anterior, existe otra precisa alternativa, propuesta también por Bace y
Mell [28]:
Denición 1.21, Detección de Anomalías (Anomaly Detection):
Detection method
that identies abnormal unusual behavior (anomalies) on a host or network.46 [...]
Este enfoque proporciona capacidad de respuesta ante los peligrosos Zero-Day Attacks y
llega más allá de las habilidades propias de los Sistemas de Detección de Usos Indebidos. No
obstante, también presenta un importante inconveniente: Un nuevo elemento o componente en
el sistema introduce de forma natural nueva actividad, la cual no deja de ser legítima y, sin
42
Método de detección que analiza la actividad del sistema, en busca de eventos o conjuntos de eventos que
concuerden con un patrón de eventos predenido que describe un ataque conocido.
43
Conocidos como zero-day attacks, en contraposición con los anteriormente mencionados ataques conocidos o
well-known attacks.
44
45
46
Detección basada en Comportamiento o Behaviour-based Detection.
En este caso se está usando política de lista blanca o whitelist.
Método de detección que identica comportamiento inusual o anormal (anómalo) en una máquina o en una
red.
23
embargo, es calicada por el sistema de detección como subversiva [15, 26]. Esta cuestión obliga
a una actualización continua del perl de comportamiento, y hace que el sistema presente una
indeseada característica conocida como falso positivo47
48
49
. Una buena denición es la que
proponen Ptacek y Newsham [385]:
Denición 1.22, Falso Positivo (False Positive):
An event, incorrectly identied by the
Intrusion Detection System as being an intrusion when none has occurred.50 Asimismo, Ptacek y Newsham también proponen la correspondiente denición del concepto
complementario: el
falso negativo.
Denición 1.23, Falso Negativo (False Negative):
An event that the Intrusion Detection
System fails to identify as an intrusion when one has in fact occurred.51 Existe una gran colección de estudios realizados en el área de la Detección de Anomalías
[116, 227, 26, 50], si bien aún no se ha conseguido un modelo que consiga integrar todos los
benecios que teóricamente caracterizan a este tipo de enfoques [165]. La práctica totalidad de
productos comerciales aún no se ha decido por ella, y se siguen utilizando modelos basados en
Detección de Usos Indebidos [116, 351, 205, 78, 28, 204, 49], debido fundamentalmente a que su
ecacia aún es discutida y al mencionado problema de los falsos positivos [116, 28].
Por último, la fase de respuesta, que tradicionalmente ha mantenido una única losofía de
funcionamiento, también ha visto aparecer en los últimos tiempos un nuevo enfoque. De esta
forma, al clásico método de respuesta pasivo consistente en la simple noticación de eventos de
alarma al administrador, se suma la posibilidad de llevar a cabo una reacción activa, como puede
ser la reconguración del entorno de la víctima para aislarla del agresor. Asimismo, también es
posible activar la recogida detallada de información, de cara a la toma de las pertinentes acciones
legales, o pasar directamente al contraataque [28].
Además, actualmente, la tendencia consiste en hacer que esta reacción suponga el ltrado de
las acciones del usuario, para lo cual el Sistema de Detección de Intrusiones debe ubicarse en un
punto del sistema en el que sea posible interceptar las órdenes de dicho usuario. De este modo,
es posible analizar dichas órdenes antes de ser enviadas nalmente al sistema para su ejecución.
47
Falso positivo o falsa alarma. Un Sistema de Detección de Intrusiones basado en Detección de Anomalías con
una conguración deciente puede saturar de falsos positivos al administrador de dicho sistema, incapacitándole
incluso para responder ante los verdaderos ataques [Newman+02].
48
Se estima que es bastante común obtener ratios de alrededor de diez falsos positivos por cada alarma real
[78].
49
En contraposición con el fenómeno del falso positivo, se encuentra el denominado falso negativo. Esta cuestión
es incluso más preocupante que la anterior, ya que es fruto de la falta de reacción del sistema de detección ante
un cierto ataque. Sin embargo, dado el enorme riesgo que supone, es habitual optar por soluciones de compromiso
que eliminen la posibilidad de su aparición, por lo general a costa de perjudicar la tasa de falsos positivos.
50
Evento incorrectamente identicado como intrusión por el Sistema de Detección de Intrusiones, cuando por
el contrario no ha ocurrido tal intrusión.
51
Evento no identicado como intrusión por el Sistema de Detección de Intrusiones, cuando por el contrario sí
es merecedor de dicha identicación.
24
Figura 1.11: Taxonomía general
Este método de respuesta recibe la denominación de Prevención de Intrusiones y pretende dar
un paso más allá en la evolución.
De hecho, algunos autores consideran que dicha tecnología deberá constituir a medio plazo el
método de respuesta por defecto de todo Sistema de Detección de Intrusiones [337, 341], aunque
aún existen poderosas argumentaciones en contra [133]. Timothy Wickham propone una precisa
denición de Sistema de Prevención de Intrusiones en su polémico artículo
Intrusion Detection
is Dead. Long Live Intrusion Prevention! :
Denición 1.24, Sistema de Prevención de Intrusiones (Intrusion Prevention
System):
System that actively monitor a network or host for attacks and block those attacks
from occurring.52 De esta forma, a partir de las tres categorizaciones descritas es posible plantear una primera taxonomía general, que ilustra de forma conveniente una primera aproximación al área de
conocimiento de la Detección de Intrusiones. La gura 1.11 ilustra dicha taxonomía
52
Sistema que monitoriza activamente una red o una máquina en busca de ataques, y que evita que dichos
ataques ocurran.
25
1.3.4. Características de los diferentes enfoques
En la actualidad aún no se ha desarrollado un modelo conceptual de Sistema de Detección de
Intrusiones de amplio espectro que minimice los inconvenientes que parecen estar inherentemente
asociados a sus diversas alternativas. Cada uno de los enfoques de diseño existentes proporciona
soluciones a determinadas cuestiones, pero adolece invariablemente de ciertos problemas, por lo
que se hace necesario contemplar la vía de la integración de múltiples métodos de análisis como
el camino a seguir [65, 116, 165, 398, 15, 105]. A continuación se incluye una relación de las
ventajas e inconvenientes que presentan cada una de las ramas de la taxonomía del apartado
anterior.
0.3.4.1 Recogida de información
Respecto a la cuestión de la recogida de información, o lo que es lo mismo, al objetivo estratégico de un Sistema de Detección de Intrusiones que dene su ámbito de aplicación, las
dos losofías de funcionamiento que se han introducido anteriormente (Detección orientada a
la Máquina y Detección orientada a la Red) presentan poderosas capacidades, que convierten a
ambas en extraordinarias herramientas de seguridad en prácticamente todo tipo de sistemas. Sin
embargo, ambos métodos muestran importantes debilidades, que hacen necesario un profundo
esfuerzo de reexión, de cara a la consecución de un modelo híbrido que maximice las capacidades reduciendo los inconvenientes [116, 164, 240, 92, 15, 204]. A continuación se relacionan las
cualidades y defectos de ambas.
0.3.4.1.1 Detección de Intrusiones orientada a la Máquina
La Detección de Intrusiones orientada a la Máquina fue el primer enfoque de diseño sobre
el que se empezó a trabajar en los orígenes de la Detección de Intrusiones [20], y constituye
probablemente la rama sobre la que tradicionalmente se ha desarrollado un mayor número de
investigaciones. En general, este tipo de detección está considerado como el potencialmente más
exacto en la toma de decisiones, debido simplemente a su ubicación dentro del propio sistema que
se pretende proteger. Este emplazamiento permite que el Sistema de Detección pueda determinar
con precisión los usuarios y procesos que están involucrados en un determinado ataque. Además,
desde esta localización, es capaz de analizar el impacto en el sistema de cualquier acción, ya que
tiene a su disposición toda la potencia del Sistema Operativo, y puede analizar detalladamente
sistemas de cheros, interfaces de red, etcétera, de forma ágil [116, 78, 28, 240, 92].
Sin embargo, en redes corporativas de medio o gran tamaño, el alto coste administrativo
que suponen los procesos de instalación, conguración y mantenimiento de todo un parque de
Sistemas de Detección de Intrusiones orientados a la Máquina, hace que esta solución sea inviable
en la mayoría de los casos. Por lo general su utilización queda circunscrita a sistemas servidores
[351, 28]. Éstas son las principales características de este tipo de sistemas, aunque es importante
26
prestar atención al conjunto de sus particularidades. A continuación se relacionan las ventajas e
inconvenientes que supone la utilización de esta clase de métodos.
0.3.4.1.1.1 Ventajas
Posibilidad de determinar el éxito o fracaso de un ataque
Habitualmente, los Sistemas de Detección de Intrusiones orientados a la máquina basan sus
decisiones de análisis en los registros históricos de eventos del sistema o de servicios de aplicación,
por lo que pueden obtener una medida precisa del grado de éxito o fracaso de un ataque. Los
sistemas orientados a la red, por el contrario, solamente pueden detectar intentos de intrusión,
pero no son capaces de determinar si dichos intentos han fructicado o no. De esta forma, en
general, los sistemas orientados a la máquina presentan una tasa de falsos positivos muy reducida,
lo que hace que sean un buen complemento de los sistemas de red: Éstos detectan los primeros
indicios de actividad sospechosa que aparecen en la red y sus homólogos orientados a la máquina
comprueban si esa actividad ha tenido impacto en el sistema o no. [351, 336, 28, 164, 240]
Monitorización de actividades especícas
Este tipo de sistemas de detección puede monitorizar la utilización que los usuarios de un sistema
hacen de sus recursos, pudiendo centrar su atención en cuestiones particulares como el acceso
o modicación de archivos, utilización de credenciales y privilegios, manipulación de software,
ejecución y manipulación de procesos, etcétera. Además, su especial ubicación hace posible que
cualquier actividad sospechosa de poner en compromiso la seguridad del sistema pueda ser no
sólo detectada, sino incluso interceptada, mediante una simple redirección de los servicios del
Sistema Operativo en el que se encuentran instalados. [351, 78, 336, 28, 164, 240, 92, 100]
Detección de ataques físicos
Evidentemente, un sistema de detección orientado a la máquina puede revelar cualquier actividad
subversiva que se lleve a cabo mediante la presencia física del intruso ante la víctima. En aquellos
casos en los que el atacante ha alcanzado tan importante nivel de acceso, un sistema orientado
a la red es incapaz de responder, ya que es posible que el intruso no necesite utilizar los recursos
de comunicaciones de dicho sistema, o que incluso sea consciente de que no debe hacerlo para
pasar desapercibido. Por el contrario, un sistema de detección orientado a la máquina no tiene
ninguna dicultad para detectar dicha intrusión y noticarla convenientemente. [164, 92, 204]
Detección de ataques a través de medios de comunicación cifrados
Dado que este tipo de sistemas se instala directamente en la máquina a proteger, es posible dar
respuesta a un problema que tradicionalmente se ha caracterizado por la ceguera absoluta que
produce en los sistemas de detección orientados a la red, como es la cuestión del tráco de red
27
cifrado. Para poder analizar correctamente cualquier tipo de información, un sistema de detección
orientado a la red debe ser capaz de comprender su estructura, lo cual puede convertirse en una
tarea imposible de realizar en la práctica en el caso de que el atacante decida aplicar métodos de
cifrado sobre dicha información. De esta forma, un intruso puede apoyarse en dichos algoritmos
para conseguir eludir la vigilancia del sistema de detección. Sin embargo, dado que la información
que llega al sistema atacado (conteniendo órdenes, archivos o herramientas) debe ser descifrada
antes de ser interpretada por el Sistema Operativo, un sistema de detección orientado a la
máquina no tiene dicultad alguna para realizar su cometido. [116, 336, 28, 164, 92, 100, 204, 50]
Detección de ataques en redes de comunicación conmutadas
Una de las soluciones que tradicionalmente han abordado el problema de las escuchas ilegítimas
en redes de comunicación, como es el diseño de redes conmutadas, hace que los sistemas de
detección orientados a la red convencionales no puedan acceder a la información que necesitan
para llevar a cabo su actividad de análisis, ya que dichos entornos impiden que esa información
llegue a ellos. Sin embargo, en el caso de los sistemas orientados a la máquina, esa cuestión no
representa un problema, ya que pueden disponer de forma natural de toda la información dirigida
hacia el sistema que protegen. [340, 28, 100, 204, 50]
Reducido tiempo de respuesta
Dado que este tipo de sistemas sólo es responsable de analizar la actividad que se da en el sistema
al cual dedican su vigilancia, el volumen de información que deben analizar es relativamente
pequeño. Por ello, es posible proporcionar una respuesta en condiciones de tiempo real, o muy
cerca de ellas. De esta forma, en la mayoría de los casos, la actividad del intruso puede ser
detenida antes de que pueda producir cualquier daño en el sistema. [240, 92]
0.3.4.1.1.2 Inconvenientes
Elevado coste administrativo y económico
En el caso de utilizar Sistemas de Detección orientados a la Máquina en una red corporativa
con múltiples sistemas conectados, es necesario instalar, congurar, administrar y mantener un
sistema de detección en cada uno de dichos sistemas. Evidentemente, esta consideración implica
un extraordinario coste de administración, que a menudo hace que este tipo de soluciones sea
descartado. Por el contrario, un único sistema orientado a la red es capaz, por sí solo o en pequeñas
colectividades de agentes, de llevar a cabo la vigilancia de toda una red corporativa. Por ello,
los costes económicos derivados tanto de los mencionados esfuerzos administrativos, como de la
inversión económica propiamente dicha, son por lo general muy altos, en comparación con los
sistemas orientados a la red. [116, 351, 78, 28, 240, 92, 204]
Vulnerabilidad de emplazamiento
28
Dado que este tipo de sistemas de detección se ubica en el propio sistema a proteger como si
fuera un aplicativo convencional, en aquellos casos en los que el intruso consigue alcanzar cierto
nivel de operatividad en dicho sistema, aparece el riesgo potencial de que el sistema de detección
pueda ser desactivado o subvertido por dicho atacante. Por el contrario, un sistema de detección
orientado a la red es susceptible congurarse de forma que su presencia sea no sólo inexpugnable
sino incluso inadvertida para cualquier usuario. [351, 336, 28, 240, 92, 100, 50]
Limitada área de inuencia
La propia idiosincrasia de estos sistemas hace que su ámbito de protección se vea limitado a un
único sistema, debido a que solamente son capaces de detectar actividad subversiva a partir de
los registros de solicitudes de servicio que los aplicativos hacen al Sistema Operativo de dicho
sistema (ya sea en el nivel de aplicación o en el nivel de servicio), o a partir del tráco de red
exclusivamente dirigido hacia el mismo. Además, esta forma de actuación hace que el sistema de
detección sea dependiente de la plataforma software (fundamentalmente del Sistema Operativo),
lo que introduce una compleja componente de heterogeneidad en sistemas de información en los
que conviven múltiples tipos de plataformas. Un sistema de detección orientado a la red, por el
contrario, es capaz de detectar comportamientos ilegítimos dirigidos contra redes enteras, ya que
la información que maneja uye por el medio de comunicación y está rigurosamente estandarizada
en forma de protocolos de comunicación. [351, 340, 78, 336, 28, 240, 204]
Sensibilidad del propio sistema de detección
Un intruso potencial puede orquestar un ataque de denegación de servicio dirigido hacia el propio
sistema de detección, con el objetivo de deshabilitarlo. De esta forma, una vez conseguida la desactivación de dicho sistema, las acciones de dicho intruso pueden realizarse con total impunidad
e incluso sin dejar rastro. Ésta es una característica especialmente indeseada, tanto en este tipo
de sistemas como en sistemas de detección orientados a la red, y que debe minimizarse haciendo
especial énfasis en el desarrollo eciente y optimizado de toda la arquitectura interna del sistema
de detección. [336, 28, 240, 100, 204]
Alto consumo de recursos
Dado que este tipo de sistemas de detección debe ubicarse en el propio sistema a proteger,
necesita hacer uso de sus recursos para su ejecución. Por un lado, el consumo de recursos de
almacenamiento suele verse incrementado notablemente, debido al volumen que habitualmente
presentan los registros históricos de los sistemas operativos, así como al tamaño de los registros
generados por el propio sistema de detección. Por otro, también es importante el consumo de
capacidad de procesamiento que se requiere, ya que es necesario analizar cada una de las peticiones de servicio que los usuarios del sistema o sus aplicativos solicitan al Sistema Operativo local.
Además, es necesario observar que, tal y como se ha explicado anteriormente, cada máquina de
29
la red corporativa debe tener instalado su propio sistema de detección, por lo que esos grandes
consumos se extienden a todo el parque informático de la organización. [116, 336, 28, 100, 204, 50]
0.3.4.1.2 Detección de Intrusiones orientada a la Red
La Detección de Intrusiones orientada a la Red constituyó una importante evolución, introducida por L. Todd Heberlein [161], del concepto de Detección de Intrusiones original. Hasta aquel
momento la protección de sistemas informáticos se había realizado desde las propias infraestructuras hardware y software que se deseaban salvaguardar, y esta nueva losofía originó un gran
interés académico, y numerosas investigaciones cientícas e inversiones comerciales. En general,
este tipo de detección está considerado como el más poderoso y el que mejores prestaciones ofrece
en grandes infraestructuras informáticas [240]. Su ubicación, anexa al sistema de explotación de
la organización, a través de la captura continua del ujo de información transmitido a través
de las redes corporativas, consigue que la interferencia o sobrecarga introducidas en el sistema
sean nulas y que las decisiones generadas por el sistema de detección tengan carácter global
[50]; todo ello sin los costosos requerimientos de administración de los sistemas orientados a la
máquina. No obstante, estos sistemas también presentan algunas limitaciones, como por ejemplo
su incapacidad para detectar ataques locales o para determinar el impacto de los ataques que
detectan [28, 92]. Por otro lado, el reducido impacto económico que tiene en los presupuestos de
infraestructura de la organización, hace que la Detección de Intrusiones orientada a la Red sea
una opción muy utilizada, y que alcanza en la actualidad altas cotas de cuota de mercado [351].
En rasgos generales, éstas son las principales propiedades de este tipo de soluciones, aunque es
importante observar sus características en conjunto. A continuación se relacionan las ventajas e
inconvenientes que supone la utilización de esta clase de métodos.
0.3.4.1.2.1 Ventajas
Extensa área de inuencia
Un único Sistema de Detección de Intrusiones orientado a la Red es capaz de detectar por sí mismo
cualquier tipo de actividad subversiva o anómala que utilice la infraestructura de comunicaciones
de una organización como medio de transporte, incluso en redes con alto número de sistemas
conectados. Además, en casos en los que el volumen de información que uye a través del sistema
de información supera la capacidad de respuesta del sistema de detección, su arquitectura general
permite que el escalado de dicho sistema sea realmente sencillo y natural [92]. De esta manera,
en el caso de grandes redes corporativas, la vigilancia de los recursos computacionales del sistema
queda en manos no ya de un único sistema de detección, sino en una pequeña colectividad de
procesos agente que colaboran en las tareas de recogida de información, análisis y respuesta.
[351, 78, 336, 28, 240, 92, 204]
Nulas interferencia y sobrecarga en el sistema objetivo
30
El despliegue de este tipo de sistemas de detección tiene un impacto nulo sobre la infraestructura computacional y de comunicaciones subyacente, ya que por lo general se destina para ello
una máquina adicional dedicada en exclusiva. Así, habitualmente, un sistema orientado a la red
captura de forma pasiva el tráco de dicha red, sin intervenir activamente en ningún momento.
Simplemente escucha, decide e informa si lo considera necesario. Por ello, esta solución es ampliamente adoptada por empresas y organizaciones de todo tipo [351]; en perjuicio de los sistemas
orientados a la máquina, que sí necesitan una importante cantidad de recursos provenientes del
sistema a proteger, como pueden ser memoria principal, capacidad de almacenamiento, capacidad
de procesamiento, etcétera. [116, 336, 28, 100, 204, 50]
Fortaleza de emplazamiento
Un sistema de Detección de Intrusiones orientado a la Red puede congurarse de manera que
sea virtualmente invisible para cualquier usuario de la organización, incluyendo por supuesto a
cualquier potencial intruso que tenga como objetivo a dicha organización. Su carácter pasivo
propicia esta característica e incluso es posible utilizar dispositivos hardware o componentes
software que garantizan dicha propiedad [83]. Existen ciertas soluciones de detección orientada a
la red que abogan por un comportamiento reactivo ante las amenazas, pero mantienen igualmente
esta propiedad de su inexpugnabilidad. Por el contrario, un sistema orientado a la máquina es
fácilmente detectable por un intruso, quien puede intentar ponerlo en compromiso para conseguir
sus nes. Además, esta invisibilidad evita cualquier posibilidad de alteración o corrupción de los
recursos del sistema de detección mismo, de forma que los habituales métodos de eliminación de
evidencias son inviables de antemano; a pesar de que existan ciertas técnicas [385] dirigidas a
evadir la vigilancia de dicho sistema de detección. [351, 336, 28, 240, 92, 100, 50]
Detección de ataques orientados a la red
Dado que este tipo de sistemas de detección analizan todos y cada uno de los paquetes de
información que circulan por la red de comunicaciones, pueden detectar ataques que se realizan
por debajo de los niveles de aplicación o de servicio a los que habitualmente acceden los usuarios
de una máquina. Por lo general, un sistema orientado a la máquina no analiza todos los diferentes
aspectos del tráco de red, por lo que es incapaz de detectar numerosos tipos de ataque, como
pueden ser los de denegación de servicio o los de fragmentación [385]. Por el contrario, un sistema
orientado a la red sí observa cada uno de los diferentes parámetros que componen dichos paquetes,
y puede responder de forma eciente ante un mayor número de amenazas. [116, 336, 240, 100, 50]
Bajo coste administrativo y económico
Debido a la notable amplitud del ámbito de inuencia que por lo general poseen los sistemas
orientados a la red, unas mínimas tareas administrativas y de supervisión y mantenimiento son
en general sucientes para una explotación adecuada de dicho sistema de detección. Asimismo, la
31
inversión económica necesaria se mantiene contenida en la mayoría de los casos, y es susceptible
de incrementarse progresivamente a lo largo del tiempo en aquellas situaciones cuya evolución
va requiriendo mayores prestaciones. [116, 78, 28, 240, 92, 204]
Reducido tiempo de respuesta
Al igual que los sistemas orientados a la máquina, los sistemas orientados a la red proporcionan
por lo general excelentes tiempos de respuesta, lo que permite detectar un ataque mientras se está
llevando a cabo. Esta capacidad de respuesta posibilita que el administrador reciba la noticación
de dicho ataque a tiempo para responder convenientemente. Además, en el caso de que el sistema
de detección incorpore capacidades de reacción, la respuesta puede en muchos casos llegar incluso
a detener el ataque en cuestión. [28, 164]
Independencia de la plataforma
Como se ha explicado anteriormente, este tipo de sistemas de detección utiliza los paquetes de
información que se transmiten por la red para tomar sus decisiones; paquetes que se caracterizan
por estar conformados en virtud de estándares que regulan sus diferentes características. Dado
que dichos estándares tienen como objetivo la denición formal de protocolos de comunicación
entre plataformas habitualmente heterogéneas, la información de la que se nutren los sistemas
de detección orientados a la red es compatible e interpretable por un amplio número de plataformas hardware y software. Esto hace que un mismo sistema de detección sea capaz de advertir
comportamientos subversivos en redes que interconectan sistemas de computación heterogéneos,
lo que lo convierte en una herramienta de seguridad excepcional. Por el contrario, los sistemas
orientados a la máquina son especícos de la plataforma, por lo que ante la necesidad de vigilancia de sistemas de información heterogéneos son necesarias diferentes soluciones de detección;
con los costes administrativos y económicos que ello conlleva. [116, 78, 336, 240, 100, 50]
0.3.4.1.2.2 Inconvenientes
Rendimiento en redes de alta velocidad
Ante el problema de la detección de intrusiones en redes de alta velocidad, los sistemas de
detección orientados a la red adolecen por lo general de dicultades en el correcto procesamiento
de todos los paquetes de información que uyen por dichas redes, en situaciones de alta ocupación.
Habitualmente, dichos sistemas integran en su arquitectura interna mecanismos de control de
congestión para tratar de paliar este problema, pero, como es lógico, dichos mecanismos tienen
capacidades nitas. Por ello, es posible la pérdida de paquetes de red que el sistema no ha sido
capaz de capturar temporalmente para su análisis. Esta característica constituye una importante
fuente de inspiración para todo tipo de intrusos, que intentan saturar el sistema de detección,
incapacitándole para responder correctamente. Actualmente, la tendencia consiste en migrar
32
el software de detección a dispositivos hardware que incrementen el rendimiento, así como la
especialización de los tipos de ataque a detectar, y la optimización de los recursos computacionales
necesarios para proporcionar una respuesta en unos márgenes de tiempo aceptables. A este
respecto, está comúnmente aceptada la consideración de estos sistemas de detección orientados
a la red como sistemas de tiempo real acríticos. [116, 336, 28, 164, 240, 92, 100, 204, 50]
Problemas de detección de ataques en redes de comunicación conmutadas
Las redes de comunicación conmutadas se utilizan actualmente de forma habitual en redes corporativas de tamaño medio y grande, y están basadas en la separación lógica de distintos segmentos
de red, lo que permite alcanzar mayores rendimientos de transferencia de información que en los
anteriores medios compartidos. Sin embargo, esta deseable característica evita el libre acceso al
tráco de red, lo cual es una cualidad imprescindible para el funcionamiento de todo sistema de
detección orientado a la red. Para poder analizar el tráco de información, el sistema detector
tiene que poder acceder a él. En cualquier caso, esta problemática tiene una repercusión relativa,
ya que la mayoría de dispositivos de conmutación incorpora puertos especiales53 que permiten
acceder al ujo completo de información. Basta con conectar el sistema de detección a uno de
esos puertos para garantizar su correcto funcionamiento. [340, 28, 100, 204, 50]
Problemas de detección de ataques a través de medios de comunicación cifrados
Dado que los Sistemas de Detección de Intrusiones orientados a la Red necesitan acceder libremente a la información que circula por dicha red, cualquier obstáculo a ese acceso, ya sea físico
como en el caso anterior, o lógico como en el caso en el que las comunicaciones estén sujetas a esquemas de cifrado de la información, incapacita a dichos sistemas para cumplir con su cometido.
Un sistema de detección que no es capaz de interpretar la información contenida en un paquete
de red, no puede realizar ningún análisis respecto de dicho paquete, ni tomar decisión alguna.
Éste es uno de los grandes handicaps que tradicionalmente ha venido sufriendo la Detección de
Intrusiones orientada a la Red, si bien existe una evolución de estos sistemas por la cual es posible
solventar este problema, y que se conoce como Detección de Intrusiones orientada al Nodo de
Red54 [84, 78, 241]. Este enfoque consiste en convertir un sistema orientado a la red en un sistema
orientado a la máquina, que analice el tráco proveniente del subsistema de comunicaciones de
dicha máquina, después de haber sido descifrado por la capa criptográca de la pila de protocolos
de red. Por supuesto, este avance implica un retroceso en la tradicional capacidad de los sistemas
orientados a la red de detectar intrusiones en grandes redes. [116, 336, 50, 28, 164, 92, 100, 204]
Imposibilidad de determinar el éxito o fracaso de un ataque
53
54
Conocidos como tap ports o mirroring ports.
Este enfoque da lugar a los conocidos Sistemas de Detección de Intrusiones de Nodo de Red o Network Node
Intrusion Detection Systems.
33
Por lo general, los sistemas de detección orientados a la red no son capaces de determinar si un
ataque detectado por ellos ha sido exitoso para el atacante o no. Sólo pueden precisar que en un
momento dado se produjo dicho ataque. Esta particularidad obliga a que, después de detectado
un determinado ataque, el administrador del sistema deba investigar manualmente el impacto
que ha podido tener dicho ataque en su organización. [351, 336, 28, 164, 240]
0.3.4.2 Análisis
La fase de análisis constituye el núcleo central del modelo general de funcionamiento de
todo sistema de detección, ya que es en él donde deben tomarse las decisiones importantes
que afectan a la seguridad del sistema de información que se pretende proteger. La anterior
fase de recogida de información, así como la siguiente, de respuesta, están caracterizadas por
realizarse de forma prácticamente automática, mecánica. Por el contrario, en esta fase de análisis
es necesario disponer de un modelo de representación de conocimiento y de un mecanismo de
inferencia de conclusiones que sean capaces de procesar las complejas relaciones que existen
entre los múltiples parámetros que es necesario estudiar. Por supuesto, es en esta fase de análisis
donde se encuentra concentrado el mayor interés estratégico de todo el área de conocimiento
de la Detección de Intrusiones, y es en ella también donde se registra una mayor actividad
investigadora, ya que aún no se ha conseguido un modelo general que consiga superar los retos
existentes. A este respecto, es interesante observar las conclusiones que se desprenden del estudio
realizado por Emilie Lundin y Erland Jonsson sobre la actividad investigadora en el área de
la Detección de Intrusiones [379] en los últimos años55 . La tabla 1.5 es ruto de dicho estudio,
y muestra claramente como la fase de Análisis es el área que oncentra un mayor interés en la
comunidad académica.
A continuación se describen las principales características de las dos grandes losofías de
funcionamiento sobre las cuales está construida la mayoría de los componentes de análisis de
los actuales Sistemas de Detección de Intrusiones: Detección de Usos Indebidos y Detección de
Anomalías. Como se comprobará, ambos métodos proporcionan importantes benecios, pero no
consiguen evitar ciertas debilidades. Esta situación obliga a seguir investigando en búsqueda de
un modelo que sea capaz de aunar las ventajas de ambos métodos, minimizando en la medida
de lo posible los inconvenientes [65, 116, 351, 147, 165, 336, 28, 164, 92, 15, 26, 339].
0.3.4.2.1 Detección de Usos Indebidos
Actualmente, la Detección de Usos Indebidos es el enfoque más extendido y el que ha fructicado con mayor rmeza en el mercado [351, 50, 28]; éxito que ha venido producido fundamentalmente por su eciencia y sencillez de administración. Su principio de funcionamiento es simple:
55
Para el desarrollo de este estudio se han tomado en consideración las conferencias de mayor prestigio y
contabilizado el número de publicaciones en cada una de las diferentes áreas. En la tabla 1.5 se han seleccionado
solamente las áreas descritas en el modelo general, si bien existen otras líneas de investigación laterales más
especícas, que escapan a los objetivos de esta introducción.
34
Cuadro 1.5: Áreas de investigación sobre Detección de Intrusiones con mayor actividad
35
A partir del conocimiento de los diferentes tipos de ataques utilizados por la comunidad hacker,
basta con recoger los eventos que se produzcan en un determinado sistema y contrastarlos contra
dicho conocimiento, para poder detectar intentos de subversión en el sistema.
Por lo general, este conocimiento se estructura en forma patrones que describen las peculiaridades de cada ataque. De esta forma, una base de conocimiento puede estar compuesta por
varios miles de patrones o rmas [29, 18], cada uno de los cuales debe ser comparado con los
sucesos que van teniendo lugar en la explotación cotidiana del sistema de producción. Este modo
de operación hace que el sistema sea realmente sólido y que detecte con precisión toda actividad
maliciosa que tenga registrada en su base de rmas. Sin embargo, es precisamente este mismo
modo de operación la causa de su más importante limitación: No es posible detectar nada que
no esté previamente documentado.
De esta manera, un intruso (que puede estar al corriente de la conguración de las bases de
conocimiento que se estén utilizando) puede realizar una ligera modicación de un ataque y pasar
desapercibido para el sistema de detección. Es más, cada día aparecen ataques completamente
nuevos, que por supuesto pasan inadvertidos a los detectores, a menos que se incluyan las nuevas
rmas. Como es obvio, esta cuestión obliga a realizar un continuo y costoso proceso de mantenimiento, que queda en manos del operador humano, y que hace que el sistema de detección vaya
perdiendo progresivamente su eciencia. Ante continuas actualizaciones de la base de rmas,
llega un momento en el que el volumen de patrones a contrastar consume más tiempo del que
tardan en producirse los eventos del sistema. El detector se satura y se empiezan a ignorar dichos
eventos. Por todo ello, si se desea conseguir una auténtica protección ante ataques novedosos,
es necesario explorar otras vías de investigación que complementen a los sistemas basados en
rmas. [116, 147, 84, 165, 28, 26, 100, 204]
A continuación se relacionan las ventajas e inconvenientes fundamentales que presenta este
tipo de sistemas de detección:
0.3.4.2.1.1 Ventajas
Precisión en la detección
Los Sistemas de Detección de Usos Indebidos son muy efectivos en la detección de los ataques
que tienen documentados. Esto es debido a que su principio de funcionamiento se reduce a la
comparación de la actividad cotidiana del sistema que se pretende proteger, con una base de
rmas de ataques que se construye a partir de vasto conocimiento experto sobre métodos de
intrusión y procedimientos para explotar vulnerabilidades conocidas. De esta forma, cualquier
actividad subversiva que se encuentre tipicada en dicha base de conocimiento es advertida
rápidamente. [116, 147, 165, 28, 26, 100]
Ausencia de falsos positivos
36
Dada la simplicidad del método de detección, no es habitual que se produzca el fenómeno del falso
positivo, siempre y cuando la base de conocimiento se encuentre convenientemente congurada.
Ésta es precisamente la mayor ventaja que presenta este tipo de sistemas de detección con
respecto a otros, como puede ser la Detección de Anomalías, que ha sufrido tradicionalmente
este problema. [116, 84, 28, 15, 100, 358]
Estabilidad del conocimiento
Una característica negativa que presentan algunos Sistemas de Detección de Intrusiones más
ambiciosos que los basados en la Detección de Usos Indebidos, es la posibilidad de que los modelos
de representación de conocimiento adaptativos que utilizan puedan ser dirigidos progresiva e
intencionadamente56 para que, llegado el momento, dejen pasar desapercibidos ciertos eventos que
el potencial intruso no desea que sean detectados. Si el sistema de detección es capaz de adaptarse
a los cambios de comportamiento de los usuarios, es posible que alguno de esos usuarios utilice esa
indeseable característica con nes maliciosos. Sin embargo, en el caso de la detección de rmas,
la sencilla estructura de su motor de decisión elimina este problema. [116, 84, 17, 28, 100, 204]
Bajo coste administrativo
Un Sistema de Detección de Usos Indebidos puede proporcionar de forma rápida y able un
diagnóstico exacto sobre la situación de un sistema de información, sin necesidad de laboriosos
procedimientos administrativos y sin necesidad de disponer de personal de seguridad excepcionalmente experimentado. [116, 147, 28, 15, 100, 358]
0.3.4.2.1.2 Inconvenientes
Incapacidad de detección de ataques no documentados
La limitación por excelencia de todo sistema de detección de usos indebidos, dada la naturaleza
del propio principio de funcionamiento, consiste en la incapacidad absoluta de este tipo de sistemas de advertir cualquier comportamiento subversivo que no se encuentre documentado en su
base de conocimiento. Dado el extraordinario número de vulnerabilidades que se encuentran diariamente, así como de procedimientos de ataque que las explotan [59], esta cuestión adquiere de
forma natural carácter de urgencia. Actualmente, las soluciones al problema pasan por la actualización automática periódica de las bases de rmas, si bien este método termina por reducir la
eciencia del sistema de detección a medio y largo plazo. [116, 84, 205, 17, 28, 15, 26, 100, 204, 358]
Rendimiento decreciente
56
Dicha técnica es conocida habitualmente como session creeping.
37
El crecimiento que se produce en las bases de conocimiento a medida que se detectan, analizan y
documentan nuevos tipos de ataques, hace que dichas bases sean complejas de mantener, y que
el rendimiento del sistema termine por degradarse. En esta situación, el sistema de detección
puede llegar incluso a saturarse, y a tomar la decisión de ignorar aquellos eventos que están
saturando sus mecanismos de control de la congestión. Por supuesto, si el sistema se ve obligado
a dejar de analizar eventos, su ecacia pasa a verse en un serio compromiso. De hecho, existen
técnicas de evasión de Sistemas de Detección de Intrusiones [385] que se basan en esta indeseada
característica. [116, 147, 100, 204]
0.3.4.2.2 Detección de Anomalías
Con el objetivo de aportar una solución al principal problema de los Sistemas de Detección
de Usos Indebidos, y proporcionar un método capaz de detectar ataques desconocidos hasta
el momento, surge la Detección de Anomalías [105], si bien hasta la fecha existen pocos casos
de éxito de dicha tecnología, debido fundamentalmente a la complejidad de administración que
la ha venido caracterizando. Tal y como se describe en la denición 1.1.17, su principio de
funcionamiento consiste en primer lugar en elaborar un perl del comportamiento habitual de
los usuarios. A continuación, la actividad cotidiana de los mismos es comparada con dicho perl, y
en el caso de que se observe alguna desviación signicativa, dicha actividad será clasicada como
anómala. Por último, se generará la pertinente respuesta, que en función de la conguración del
sistema podrá quedar reducida a una noticación de alarma al administrador, o por el contrario
llegar a provocar un efecto reactivo sobre el sistema.
Por lo general, este modelo de funcionamiento está basado en las propiedades estadísticas de
los diferentes eventos que se producen en el sistema. De esta forma, es posible que el sistema
de detección aprenda la naturaleza del comportamiento de los usuarios del sistema, e inera
sus conclusiones, por lo general construidas en base al concepto de probabilidad. Este modo de
operación hace que el sistema pueda prescindir de todo conocimiento apriorístico, y que pueda
detectar ataques para los cuales no existe un modelo previamente documentado. Sin embargo,
su naturaleza probabilística y la necesidad del sistema de detección de permanecer en un estado
de adaptación continua a las variaciones del comportamiento de los usuarios, hace a dichos
sistemas susceptibles de generar falsos positivos. Esta característica no es preocupante siempre
que se mantenga dentro de unos límites de excepcionalidad, pero puede convertirse en un serio
problema si se da con mayor frecuencia. De hecho, la minimización de los falsos positivos es uno
de los mayores retos que actualmente presenta esta tecnología. [116, 84, 28, 15, 26, 100, 204, 358]
A continuación se relacionan las principales ventajas e inconvenientes que presenta la Detección
de Anomalías:
0.3.4.2.2.1 Ventajas
Detección de ataques desconocidos
38
La mayor capacidad de este tipo de Sistemas de Detección de Intrusiones es precisamente la
de poder responder ante lo desconocido. Dado que su losofía de funcionamiento está basada
en el aprendizaje que el propio sistema de detección hace sobre la realidad de la infraestructura
hardware y software que pretende proteger, es este conocimiento aprendido el elemento que marca
la diferencia entre lo legítimo y lo subversivo. De esta forma, no es necesario documentar todos y
cada uno de los tipos de ataque que aparecen diariamente, sino que basta con realizar un ejercicio
de introspección que determine cómo se comporta habitualmente un sistema de información, y
cómo no. [116, 147, 84, 28, 15, 26, 100, 204, 358]
Documentación de ataques desconocidos
Dada la poderosa propiedad anterior, un sistema de detección basado en anomalías puede generar
automáticamente información descriptiva sobre los nuevos ataques que detecta. De esta forma, es
posible construir, en base a dicha información, nuevas rmas de ataques que pueden ser utilizadas
por los sistemas de detección de usos indebidos, de cara a la utilización conjunta de ambos. [28]
Rendimiento constante
El modelo de representación de conocimiento de este tipo de sistemas no necesita incrementar
su volumen de conocimiento, sino simplemente adaptarlo a ajustarlo a la realidad de la infraestructura subyacente. Esta propiedad hace que estos sistemas tengan un prometedor futuro, ya
que no adolecen del problema de la pérdida de eciencia que sufren los modelos de detección de
usos indebidos. [116, 147]
0.3.4.2.2.2 Inconvenientes
Inestabilidad del conocimiento
Dada la necesidad de este tipo de sistemas de detección de adaptación continua a la siempre cambiante realidad del sistema a proteger, el conocimiento adquirido por los Sistemas de Detección
de Anomalías presenta cierta propensión a la inestabilidad. El comportamiento del sistema cambia, y ese cambio puede inuir para que lo que en un momento dado ha podido ser considerado
como legítimo, ahora pase a ser subversivo, y viceversa: que lo que en el pasado era considerado
anómalo, pase a convertirse en habitual. Por supuesto, esta cuestión se da cerca de los umbrales
de detección, y no signica que el sistema sufra de indeterminismo. [116, 28, 26, 100, 204, 358]
Posibilidad de subversión del conocimiento
Debido a la misma necesidad de adaptación del apartado anterior, aparece una remota, aunque
posible, probabilidad de que el inherente proceso de aprendizaje de este tipo de sistemas sea utilizado subversivamente, con el objetivo de que en un momento del futuro el sistema de detección
deje de percibir como anómalos ciertos eventos maliciosos. Para ello, un intruso puede provocar a
39
lo largo de un cierto periodo de tiempo ciertos sucesos normales (legítimos), pero cuyos atributos
cada vez se van acercando progresivamente al terreno de lo anómalo. De esta forma, teóricamente, llegaría un momento en el futuro en el que el sistema, que se habría adaptado a esos cambios,
consideraría un evento antes subversivo como perfectamente legítimo. [116, 84, 17, 28, 100, 204]
Alto coste administrativo
En la actualidad, el proceso de aprendizaje que caracteriza a los sistemas de detección de anomalías aún no ha conseguido liberarse de una relativamente costosa tarea de conguración y administración. Asimismo, y dada la naturaleza cambiante de dichos sistemas, el mantenimiento
de los mismos también contribuye de forma notable a incrementar los esfuerzos que una organización necesita soportar para que su sistema de detección pueda ser explotado con las mayores
garantías. Además, dicho proceso de aprendizaje no sólo precisa de esas importantes tareas de
conguración y administración, sino que, además, los modelos computacionales que se utilizan
(como pueden ser las redes neuronales o los algoritmos genéticos) requieren muy frecuentemente
la supervisión del mismo por parte del operador humano. [116, 28, 15, 204]
Presencia de falsos positivos
Debido fundamentalmente a la naturaleza probabilística de los modelos de Detección de Anomalías, es frecuente la necesidad de tomar un compromiso sobre la magnitud del volumen de respuestas que se consideran convenientes para su correcto procesamiento posterior. Dicho compromiso
se establece habitualmente en base a valores umbral que separan lo que se considera normal (y
por lo tanto, legítimo) de lo que se considera anómalo (y por lo tanto, ilegítimo). Un umbral
muy restrictivo hace que cualquier desviación, por leve que sea, sea considerada merecedora del
lanzamiento de una alarma u otra acción de respuesta. En principio, la seguridad del sistema es
muy alta, y se responde ante cualquier evento sospechoso. Sin embargo, el volumen de respuestas
es enorme, y en el caso habitual de utilizarse la simple respuesta pasiva mediante noticaciones
de alarma, el administrador queda automáticamente saturado de ingentes cantidades de mensajes que no puede procesar y que por lo general sólo implican acciones legítimas pero ligeramente
desviadas del perl de comportamiento. O lo que es lo mismo: falsos positivos. Además, y lo que
es aún peor, entre esos grandes volúmenes de mensajes suelen pasar desapercibidos auténticos
peligros, los cuales no pueden ser físicamente diferenciados de los anteriores. Por el contrario, un
umbral muy permisivo genera un número razonable de respuestas, pero posibilita la no detección
de ataques cercanos a dicho umbral, dando origen a los aún más peligrosos falsos negativos.
Por todo ello, parece evidente la necesidad de buscar un equilibrio entre los dos extremos, que
permita minimizar ambos efectos indeseados, si bien su eliminación completa es improbable.
[116, 147, 84, 28, 15, 26, 100, 204, 358]
40
0.3.4.3 Respuesta
Una vez que el sistema de detección ha recogido un determinado evento y tomado la decisión
que considera más apropiada sobre él, es necesario dar una respuesta oportuna al mismo. En la
mayoría de los casos, dicha respuesta implica el lanzamiento de un mensaje de alarma hacia una
consola de gestión a cargo del administrador de dicho sistema. Este modo de actuación es lo que
se conoce como Respuesta Pasiva, y se realiza habitualmente de forma remota, bien mediante un
protocolo de noticación propio del sistema de detección, bien mediante algún esquema estándar
de gestión de sistemas como puede ser por ejemplo SNMP57 [351, 147], o bien mediante los
servicios de noticación de eventos que proveen los sistemas operativos. Por el contrario, existen
otras soluciones que apuestan por el uso de técnicas más activas, y que intentan mitigar de
forma automática los efectos de los potenciales ataques. Por lo general, una vez detectado un
ataque, este tipo de aproximaciones intentan recabar toda la información posible sobre el origen
de dicho ataque, tanto para poder así orquestar una respuesta más precisa, como para poder
tomar las acciones legales correspondientes con mayor conocimiento de causa. Además, también
es habitual llevar a cabo acciones correctoras del entorno atacado, abortando las conexiones del
intruso con la víctima, bloqueando el acceso de dicho intruso, protegiendo el acceso a servicios
del sistema agredido, etcétera. Asimismo, existen sistemas de detección que presentan un mayor
nivel de agresividad, y optan directamente por contraatacar contra el origen de la amenaza. Por
último, como se ha explicado en apartados anteriores, es importante prestar atención a un nuevo
enfoque que está surgiendo al respecto, y que coloca al sistema de detección dentro del ujo
de información, de forma que le es posible no ya sólo detectar un cierto ataque, sino incluso
interceptarlo. Este enfoque se denomina Prevención de Intrusiones, y pretende proporcionar un
mayor nivel de seguridad, ltrando de forma selectiva aquellos eventos dirigidos al sistema que
se pretende proteger. [116, 351, 84, 165, 340, 336, 50, 17, 28, 15, 26, 100, 204] A continuación
se describen las dos principales losofías de respuesta que presentan los actuales sistemas de
detección: La respuesta pasiva y la respuesta activa.
0.3.4.3.1 Respuesta pasiva
Como se ha descrito anteriormente, la respuesta pasiva constituye la forma de respuesta
más simple y a su vez más extendida, fundamentalmente debido a dos razones: Por un lado,
es habitual que los administradores de sistemas de detección de intrusiones preeran mantener
un control estricto sobre las acciones que se llevan a cabo en el sistema de información que
tienen a su cargo, de forma que cualquier hipotética decisión que pudiera tomar dicho sistema
de detección representa un riesgo de inestabilidad en el sistema que en la mayoría de los casos no
es aconsejable tomar automáticamente, sin un cierto proceso de reexión. Por otro lado, parece
lógico que la responsabilidad de llevar a cabo acciones críticas para el sistema, como suelen ser
las relativas a modicaciones en la política de seguridad (como es lo habitual), recaigan en un
57
SNMP o Simple Network Management Protocol: Protocolo de gestión de red, basado en UDP [288].
41
operador humano, y no en un sistema que se encuentra en continuo peligro de ser subvertido.
[116, 28] A continuación se relacionan las ventajas e inconvenientes más importantes de este
método de respuesta:
0.3.4.3.1.1 Ventajas
Rapidez de respuesta
La principal característica positiva de este método de respuesta es su sencillez y rapidez. Es
posible lanzar una noticación de alarma a la consola de gestión del administrador o incluso
a su teléfono móvil en el mismo instante que se detecta un ataque. Una correcta conguración
del sistema de detección, que mantenga la tasa de falsos positivos en unos límites razonables,
en combinación con este tipo de respuesta, puede ser perfectamente válido en la mayoría de los
casos. [15, 204]
Imposibilidad de subversión
Al contrario que en otros tipo de sistemas más ambiciosos y agresivos, con este tipo de respuesta
no es posible que un potencial intruso llegue a utilizar subversivamente las peligrosas capacidades
de actuación sobre el entorno de dichos sistemas. Deberá ser el operador humano quien decida
si es necesario activar el registro de datos sobre el intruso, bloquear su acceso al sistema, o
contraatacarle. Es un método simple, pero no adolece de los delicados efectos laterales de otros
esquemas más sosticados. [351, 84, 340, 50, 28, 15, 26, 204]
0.3.4.3.1.2 Inconvenientes
Incapacidad de reacción
Debido a la propia naturaleza de este método de respuesta, no es posible realizar ningún tipo de
operación ante una determinada evidencia de agresión. En algunos casos, existen ciertas acciones
operativas que pueden tomarse sin riesgo de ser utilizadas en benecio del atacante, como por
ejemplo el ltrado de paquetes de red mal formados, y que este método no puede realizar por
defecto. [340, 28, 204]
Posibilidad de saturación del operador humano
En el caso de disponer de un sistema de detección con respuesta pasiva que sufra del problema de los falsos positivos, el método por defecto consistente en el envío de noticaciones de
alarma al administrador puede llegar a saturarle por completo. De hecho, puede llevarle hasta
la más absoluta inoperancia. Además, en muchos casos un determinado evento malicioso es el
desencadenante de otros muchos, de forma que un único ataque se traduce en una avalancha de
noticaciones. [116, 340, 204]
42
0.3.4.3.2 Respuesta activa
Como se ha explicado anteriormente, existen tres niveles de agresividad en las respuestas de
tipo activo: Recogida adicional de información, reconguración del entorno lógico de la víctima, y
contraataque [116, 351, 84, 340, 17, 28, 15, 26, 100, 204]. Además, existe un aspecto adicional, en
función de la ubicación del sistema de detección, que permite no ya sólo detectar un determinado
ataque, sino además prevenir al sistema contra él [337, 116, 165, 341, 17, 358]. En el primer caso,
el principio de funcionamiento consiste en, dado que habitualmente el registro de información
que realiza el sistema de detección es muy limitado por cuestiones de espacio, incrementar la
granularidad de la información que se recaba, una vez que se tiene constancia de estar sufriendo
un ataque. De esta forma, es posible registrar las direcciones origen del ataque, los identicativos
de usuario responsables del mismo, los recursos que están siendo utilizados, etcétera, etcétera, de
cara a una posterior depuración de responsabilidades. En segundo lugar, se plantea la cuestión
de intentar detener un ataque, una vez detectado, o al menos, evitar ataques posteriores. Para
ello, la solución habitual pasa por la terminación abrupta de las conexiones de red que el intruso
ha activado hacia la víctima. Es posible que el mal ya esté hecho, pero así se intenta al menos
detener cualquier actividad del agresor lo antes posible. Además, también es habitual intentar
evitar cualquier intento futuro de acceso por parte de dicho intruso, mediante la reconguración
de los dispositivos de enrutado y de ltrado de paquetes. Asimismo, una solución de agresividad
máxima consiste en atacar mediante patrones de ataque predenidos aquellas direcciones desde
las cuales se lanzó el mencionado ataque. Por supuesto, este último extremo no es recomendable
en la práctica, dadas las ambigüedades legales existentes. Por último, en los casos en que el
sistema de detección se encuentre ubicado dentro del ujo de información por el que deben
circular las órdenes de los usuarios hacia el sistema, es posible realizar ltrado de alta precisión,
exclusivamente de aquellos eventos que se identican como potencialmente peligrosos.
0.3.4.3.2.1 Ventajas
Reacción automática
En este tipo de sistemas es posible congurar un cierto grado de respuesta automática, de forma
que es posible graduar su intensidad, en función del grado de certidumbre de que se disponga.
Por ejemplo, aquellos eventos de naturaleza evidentemente maliciosa pueden ser ltrados directamente por el sistema de detección, mientras que otras cuestiones en las que exista una mayor
ambigüedad pueden seguir dejándose en manos del administrador. Por su parte, otros eventos
de riesgo medio pueden activar un mecanismo de registro detallado. [116, 84, 340, 28, 15, 204]
Reducción del volumen de noticaciones de alarma
A pesar de que esta cuestión depende en gran medida de la naturaleza de la fase de análisis,
una respuesta activa congurada convenientemente, de forma gradual, puede contribuir a reducir
notablemente la carga de trabajo del operador del sistema de detección. [84, 340]
43
Posibilidad de intercepción del ataque
En el caso de que el sistema de detección se encuentre ubicado en forma de sistema de prevención
de intrusiones, esto es, dentro del ujo de información y con capacidad de intercepción de cada uno
de los eventos que componen dicho ujo, a las capacidades anteriores es posible añadir esta última.
Con ella, el objetivo tradicional de detección de la intrusión se extiende extraordinariamente, y
hace posible que cualquier evento clasicado como malicioso sea eliminado del sistema que se
está protegiendo. [28, 15, 204]
0.3.4.3.2.2 Inconvenientes
Potencial exceso de responsabilidad
Un importante inconveniente de los métodos de respuesta activa es precisamente una de sus capacidades. Así como la absoluta carencia de responsabilidad del sistema de detección perjudica
el rendimiento de dicho sistema, un alto grado de responsabilidad supone un riesgo de inestabilidad difícilmente aceptable por cualquier administrador experimentado. De esta forma, la
solución lógica pasa por encontrar un equilibrio entre ambos extremos, de manera que el sistema
pueda hacerse cargo de cuestiones menores y de repercusión controlada, mientras que el operador
humano toma la responsabilidad de las cuestiones de mayor impacto. [351, 84, 340, 28, 15, 26, 204]
Posibilidad de subversión
Esta característica se encuentra muy relacionada con la anterior, ya que en aquellos casos en
los que el sistema de detección asume un gran nivel de responsabilidad, es posible que esa
capacidad de actuación sea utilizada subversivamente por el intruso. Por ejemplo, es habitual
la reconguración de dispositivos de red para que realicen el bloqueo de aquellas direcciones
de red desde las cuales se ha detectado un determinado ataque. De esta forma, un agresor que
falsica dichas direcciones en los paquetes de información que intercambia con su víctima puede
conseguir que el propio sistema de detección se encargue de denegar un determinado servicio
a todas las máquinas de la red que está protegiendo, con lo que habrá conseguido servirse a
su antojo de la herramienta que supuestamente debía velar por la seguridad del sistema de
información. [351, 84, 340, 50, 28, 15, 26, 204]
44
1.4. Retos por alcanzar
La novedad más importante de ESIDE-Mendizale radica en el hecho de que hasta el momento no hay ningún producto inteligente de seguridad en terminales móviles. Las tareas que
actualmente se están llevando a cabo (F-Secure Mobile, Kaspersky) son simplemente antivirales,
por reconocimiento de rmas de malware conocido, y no permiten responder ante situaciones de
riesgo para la que no existe un modelo claramente denido y documentado. Sin embargo, son
muchas las novedades que aporta este proyecto y que lo hacen realmente interesante, tanto desde
el punto de vista cientíco, como desde el tecnológico, como desde el puramente mercantil. A
continuación se relacionan las más importantes:
1.4.1. Respuesta ante ataques no conocidos (Zero-Day Attacks) contra teléfonos móviles
El sistema generará automáticamente y en tiempo real un modelo de comportamiento habitual del usuario que accede normalmente al teléfono móvil, en concreto a través de las interacciones internas que tienen los procesos y aplicaciones de dicho usuario con el Sistema Operativo
del terminal. De esta forma, mediante auditoría continua de dispositivos, llamadas al sistema,
hilos de ejecución, memoria consumida, servicios del API del Sistema Operativo, etcétera, será
perfectamente posible detectar desviaciones respecto del perl habitual que puedan derivar en
situaciones de peligro para el sistema.
Además, esta técnica permite eliminar los costosos requerimientos de actualización que presentan los IDSs basados en reglas. A partir de las capacidades y limitaciones descritas en los
apartados anteriores, se pueden observar ciertas cuestiones generales del área de conocimiento
de la Detección de Intrusiones que después de veinte años de investigación permanecen sin una
solución ecaz, y que actualmente constituyen los grandes retos pendientes de esta disciplina
[65, 116, 351, 147, 165, 340, 78, 336, 28, 164, 15, 26, 100, 204, 358, 77, 84].
1.4.2. Aprendizaje Bayesiano no supervisado de perles de usuario
El principal reto que actualmente presenta la Detección de Intrusiones consiste en dotar a
los módulos de análisis de los sistemas de detección de la capacidad de detectar ataques no
conocidos, en base al comportamiento habitual de los sistemas de información y de sus usuarios.
Las cifras de vulnerabilidades que aparecen periódicamente son extraordinarias [59] y, aunque
las habituales actualizaciones automáticas de las bases de conocimiento contribuyen de forma
notable a mitigar su impacto, la solución pasa por encontrar nuevos diseños que se enfrenten
directamente al problema.
Gracias a la capacidad de aprendizaje probabilístico (aprendizaje de correlaciones entre variables, e incluso aprendizaje de la estructura de las relaciones entre ellas) e inferencia que proporcionan las Redes Bayesianas y las Cadenas de Markov, se puede eliminar la costosa componente
45
de conguración y mantenimiento que presentan la mayoría de los actuales IDSs.
De esta manera, tanto la generación de los antes mencionados perles de comportamiento,
como el análisis propiamente dicho, se realizarán de forma transparente para el usuario nal.
Como se ha mencionado en apartados anteriores, se pretende usar el entorno OpenPNL de
Intel Corporation, en concreto en todo lo relativo a inferencia y aprendizaje automáticos. (Está
previsto que Intel desarrolle una serie de tarjetas aceleradoras especícas para toma de decisiones
mediante OpenPNL: hecho que puede aportar unos rendimientos extraordinarios -probablemente
cambiará el orden de magnitud- en cualquier solución software desarrollada sobre dicho entorno.)
Para ello, la Detección de Anomalías se convierte en la opción más interesante, y que presenta
a priori mayores posibilidades. De hecho, es precisamente es en esta área en el que se concentra
actualmente el mayor número de investigaciones. Sin embargo, tal y como se ha explicado en el
apartado anterior, dicha losofía de análisis presenta importantes inconvenientes, como pueden
ser el exceso de falsos positivos o la propensión a la inestabilidad de sus modelos de representación
de conocimiento. Por ello, es necesario desarrollar nuevos métodos de análisis que integren de
forma homogénea las capacidades de los métodos de Detección de Anomalías y de los de Detección
de Usos Indebidos, potenciando de forma sinérgica las ventajas de ambos, y minimizando sus
desventajas. De esta forma, será posible responder adecuadamente ante ataques bien conocidos,
a la vez que ante ataques de nuevo diseño. [65, 116, 340, 78, 28, 92, 15, 83].
Además, en ESIDE-Mendizale se pretende resolver una problemática tradicional que han
venido sufriendo las Cadenas de Markov, en cuanto a sus requisitos de parametrización estática.
En el presente proyecto se aborda dicha cuestión de forma dinámica, mediante la novedosa técnica
de Bayesian Merging desarrollada por Stolcke y Omohundro, en combinación con los algoritmos
Forward, Viterbi y Baum-Welch.
1.4.3. Unicación de modelos de detección de intrusiones
Otro objetivo fundamental que se plantea dentro de la Detección de Intrusiones es el de la
unicación de las múltiples soluciones de análisis que existen actualmente, fundamentalmente
mediante la homogeneización de los diferentes modelos de representación de conocimiento existentes, tanto de detección basada en rmas como de detección basada en anomalías. Para ello,
el factor principal que debe tenerse en consideración es la taxonomía de los parámetros de análisis, ya que a partir de ellos y de su morfología deben construirse posteriormente los motores de
análisis responsables de la toma de decisiones. De esta forma, en caso de conseguirse un modelo
denitivo de representación que acredite potencia descriptiva y exibilidad, sería posible avanzar
tanto en el mencionado objetivo de unicación, como en el anterior de detección de ataques
desconocidos en base a la integración de modelos de análisis. Asimismo, y dada la naturaleza
evolutiva y siempre cambiante de las tecnologías subyacentes, un paradigma de esas características contribuiría a proporcionar grandes posibilidades de extensibilidad al sistema; cualidad ésta
que habitualmente marca la diferencia entre un Sistema de Detección de Intrusiones correcto y
46
uno excelente. [65, 116, 165, 205, 336, 164, 92, 15, 84].
1.4.4. Respuesta preventiva mediante intercepción de llamadas al sistema
Se pretende diseñar el IDS/IPS de manera que sea capaz de interactuar con el núcleo del
Sistema Operativo, de forma que sea posible interceptar comandos y solicitudes de servicio potencialmente peligrosas. Según los grandes gurús de la detección de intrusiones, esta losofía debe
marcar el futuro inmediato de los IDSs.
Conseguir que según se ejecuta un determinado código se bloquee llegando a un estado
anómalo en particular es como decir que se puede hacer frente a las amenazas e incluso solucionar
el problema que presentan de raíz, dado que después de la intercepción hay formas en las que
se puede devolver a un sistema al estado correcto de funcionamiento inmediatamente anterior.
Esta casuística será cubierta en profundidad en apartados posteriores.
1.4.5. Optimización de tasas de falsos positivos y falsos negativos
Como se ha explicado anteriormente, existen numerosos enfoques de Detección de Intrusiones
que aún adolecen del problema de los falsos positivos, sobre todo en el caso de aquéllos que se
enmarcan dentro del área de la Detección de Anomalías. La cuestión de la existencia de falsos
negativos también representa un problema, sobre todo en el caso de los sistemas de Detección de
Usos Indebidos, pero a menudo se solventa mediante el compromiso de realizar una conguración
del sistema que proporcione una mayor seguridad, a costa de un mayor coste administrativo. Por
otro lado, dicho efecto también suele mitigarse mediante una actualización frecuente de las bases
de conocimiento. De esta forma, el principal asunto que queda por resolver es la reducción del
volumen de falsos positivos, que en sí mismos pueden constituir una vulnerabilidad susceptible
de ser explotada por un ataque de denegación de servicio, no contra el sistema de detección, sino
contra el operador humano responsable de su administración. [116, 147, 165, 78, 336, 28, 92, 26,
204, 358, 77, 84].
1.4.6. Superación de limitaciones arquitectónicas
En apartados anteriores se han descrito ciertas limitaciones inherentes a los actuales Sistemas
de Detección de Intrusiones orientados a la Red y al Host, como son su incapacidad para recoger
(y por lo tanto analizar) convenientemente información en grandes bloques. Otra cuestión arquitectónica que frecuentemente introduce problemas de ecacia en dichos sistemas de detección
es el crecimiento que habitualmente experimentan las infraestructuras hardware y software de
las organizaciones. Este crecimiento puede llegar a impedir que el detector de intrusiones pueda
realizar su labor convenientemente, con lo que toda la seguridad que debería aportar desaparece.
Por ello, es necesario que el diseño estructural de cada una de las tres fases que componen el modelo general de todo sistema de detección contemple la cuestión de la escalabilidad con especial
47
atención. [116, 351, 78, 28, 15, 26, 100, 204, 84]
Todas éstas son cuestiones en efecto problemáticas, pero no suponen propiamente un reto,
ya que ya existen soluciones cuando menos parciales que las solventan. Es perfectamente posible
distribuir los procesos de recogida de información, análisis y respuesta en redes con alta carga o
que escalan de tamaño frecuentemente. Sin embargo, en la mayoría de los casos, dichos inconvenientes repercuten negativamente en la penetración de las tecnologías de Detección de Intrusiones
en empresas y organizaciones, que no desean realizar inversiones, esfuerzos administrativos, ni
reestructuraciones de infraestructura extraordinarias producto de la incorporación de dichas tecnologías. En las actuales condiciones, el retorno de la inversión no está claro, y el verdadero reto
consiste en desarrollar nuevos modelos que justiquen sin lugar a dudas la implantación de la
Detección de Intrusiones con todas sus consecuencias. Cuanto menos claro estaba hasta la fecha
el llevar el mundo de la Seguridad de la Información a los terminales móviles, pero como se ha
expuesto es de primera necesidad en los tiempos que corren.
1.4.7. Base de conocimiento estándar
Se pretende diseñar la base de conocimiento que da soporte al algoritmo de análisis en formato
XML, para que pueda ser portada a otros sistemas de análisis o incluso a diferentes plataformas
de computación, dado el objetivo generalista del presente desarrollo en cuanto a su ámbito de
aplicación.
No en vano se plantea su integración con los grandes sistemas operativos que copan actualmente el mercado de terminales de telefonía móvil avanzados, como son GNU/Linux, Windows
CE/Mobile, Symbian OS, Palm-OS.
1.4.8. Análisis de tráco de redes inalámbricas
Dado que la utilización de redes y protocolos de comunicación inalámbricos (GSM, GPRS,
EDGE, UMTS, 802.11b/g -WiFi-, Bluetooth, etc.) es una realidad cada vez mayor, este proyecto
contempla el desarrollo de una batería de reglas especícas para el análisis del comportamiento
de los usuarios que se conectan a los sistemas informáticos a través de estos medios, lo cual
redunda de forma natural en el carácter global de esta solución de seguridad.
1.4.9. Reducción de requerimientos administrativos
Actualmente, la incorporación exitosa de un Sistema de Detección de Intrusiones a la infraestructura computacional y de comunicaciones de una organización requiere un considerable
esfuerzo de tiempo de administración. De hecho, por lo general, el coste principal no es el relativo
a la inversión en las licencias de uso de los productos (frente al cual incluso es posible optar por
48
soluciones de detección de libre distribución58 sólidas y de reputada solvencia59 ), sino el derivado
del tiempo que es necesario invertir para conseguir una conguración adecuada, así como para
llevar a cabo un mantenimiento que asegure la ecacia del sistema de detección a lo largo del
tiempo.
Asimismo, también es determinante el hecho de que el proceso de detección pueda realizarse
de forma unicada sobre arquitecturas hardware y software heterogéneas, como corresponde a
la realidad de cualquier organización moderna, considerando múltiples plataformas, sistemas
operativos, servicios de aplicación, etcétera. Por todo ello, cualquier modelo de funcionamiento
que se plantee debe ser especialmente cuidadoso en mantener unos requisitos administrativos y
de supervisión mínimos, que permitan una adopción natural del mismo por parte de empresas y
organizaciones. [116, 351, 28, 164, 92, 358, 77, 84]
1.4.10. Adaptación al comportamiento del sistema
A pesar de que la fructífera línea de la Detección de Usos Indebidos cuenta con casos de éxito
sobresalientes, enormemente extendidos, y que se caracterizan por su relativa sencillez administrativa, cada vez es más necesario que los Sistemas de Detección de Intrusiones se adapten por
sí mismos a la siempre cambiante realidad de las infraestructuras informáticas que deben salvaguardar. Esta cuestión, que en el caso anterior de los sistemas basados en rmas es importante,
en el caso de los sistemas basados en anomalías es trascendental.
Como se ha explicado en apartados anteriores, la Detección de Anomalías está llamada a
ser la solución al problema de los ataques desconocidos, ya que es capaz a priori de ir más allá
que sus homólogos basados en patrones. No obstante, aunque este extraordinario objetivo se vea
satisfecho, sus habituales y costosos requisitos administrativos deberán desaparecer, o al menos
igualar a los de dichos homólogos, ya que ningún modelo de detección tendrá una verdadera
expansión si no minimiza sus costes de implantación y mantenimiento. [116, 351, 165, 336, 28,
164, 240, 92, 204, 358, 77]
1.4.11. Fortalecimiento del sistema de detección
Actualmente, es frecuente observar cómo el propio Sistema de Detección de Intrusiones se
ha convertido en uno de los primeros elementos del sistema en recibir ataques de todo tipo.
De hecho, en la mente del agresor, esta realidad es fruto de un razonamiento absolutamente
lógico. Para él, no es posible materializar sus subversivas intenciones de forma inadvertida bajo
la estrecha vigilancia del sistema de detección. O lo que es más, en aquellos casos en los que el
sistema esté congurado para prevenir ese tipo de comportamientos, dicho atacante ni siquiera
58
El concepto de software de libre distribución o software libre fue acuñado por Richard Stallman en 1.984.
Dicho concepto hace referencia a una forma de entender la informática que aboga por la libertad de los usuarios
para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software [329].
59
Actualmente, el Sistema de Detección/Prevención de Intrusiones orientado a la Red de libre distribución por
antonomasia es Snort [242, 323].
49
tendrá la posibilidad de ejecutar acción alguna. De esta forma, el sistema de detección pasa a
ser una cotizada presa, que por lo general merece especial atención por parte del intruso.
Por ello, es imprescindible que el diseño e implementación de dicho sistema de detección
contemplen la resistencia a la subversión del mismo como un aspecto fundamental. De nada
sirve un sosticado módulo de análisis basado en complejas técnicas matemáticas, si el sistema
puede caer fácilmente ante un ataque de denegación de servicio, por ejemplo. Así pues, tiene que
ser extremadamente difícil para un intruso potencial conseguir desactivar o manipular cualquier
componente de dicho sistema de detección, así como lograr que sus acciones pasen inadvertidas
ante él. De hecho, es altamente recomendable considerar la posibilidad de que el propio sistema
sea capaz de automonitorizarse, en busca de ataques que hayan podido realizarse contra su
integridad; solución que ya se aplica, por ejemplo, dentro de algunos sistemas operativos, para
garantizar la consistencia de sus componentes internos. Además, es deseable que dicho sistema
de detección sea tolerante a fallos, en la medida en que debe ser capaz de recuperar su estado
ante fallos generales del sistema, ya sean éstos accidentales o intencionados. [116, 351, 165, 78,
28, 164, 92, 15, 26, 358, 77, 84].
1.4.12. Reducción del consumo de recursos computacionales
Hoy en día, la puesta en explotación de un Sistema de Detección de Intrusiones aún lleva
implícito un alto consumo de los recursos computacionales de la infraestructura que se pretende
proteger; especialmente en el caso de aquéllos sistemas que están orientados a la máquina. Por
ello, a pesar de sus grandes virtudes, la difusión de esta tecnología encuentra actualmente grandes
obstáculos a su incorporación como medida de seguridad en la infraestructura computacional y
de comunicaciones de numerosas organizaciones.
De esta forma, el diseño de los nuevos sistemas de detección debe asegurar la mínima sobrecarga posible de los mismos sobre los recursos del sistema de información objetivo del análisis, así
como la absoluta garantía de una nula interferencia en su actividad cotidiana. A este respecto,
a pesar de presentar algunas limitaciones intrínsecas (tal y como se ha explicado en apartados
anteriores), la tecnología de Detección de Intrusiones orientada a la Red se revela como el más
rme candidato al éxito, ya que el aprovechamiento que consigue de los recursos disponibles es
máximo. [116, 351, 78, 164, 92, 100, 77, 84]
1.5. Hipótesis fundamentales
A partir de los retos planteados en el apartado anterior, los cuales señalan la dirección en la
que debe orientarse toda investigación cientíca que se desarrolle en estos momentos en el área
de la Detección de Intrusiones, se establecen las siguientes hipótesis fundamentales,de ámbito
de aplicación, de unicidad y homogeneidad, sobre las cuales se sustentan los objetivos generales,
especícos y operacionales, así como el desarrollo mismo del presente trabajo:
50
Hipótesis fundamental 1: Ámbito de aplicación.
Se puede aplicar cualquier tipo de
técnica de Detección de Intrusiones (HIDS/HIPS) para sistemas cableados tradicionales en
terminales móviles.
Esta primera hipótesis se formula con el objetivo de explicar claramente que se ha llegado a
un punto tecnológico tan desarrollado, que es comparable un terminal móvil a un computador
cableado de hace años. Las técnicas de detección de intrusiones que se han estudiado engloban
mayoritariamente técnicas para sistemas cableados de análisis de funcionamiento del Software
Interno. Estás técnicas se van a poder aplicar en mayor o menor medida a los nuevos terminales
móviles, debido a que actualmente tienen la misma potencia que hace unos años el resto de
sistemas informáticos.
Hipótesis fundamental 2: Unicidad.
Es posible combinar en un único modelo de análisis
las principales ventajas de los métodos de Detección de Usos Indebidos y de Detección de
Anomalías orientados a la Host, e incluso alimentar el motor de Detección de Usos Indebidos
con los veredictos del motor de Detección de Anomalías
Esta segunda premisa se enuncia indicando que dado que los motores de Detección de Usos
Indebidos son más rápidos, una vez se obtenga un resultado por parte del Motor de Anomalías,
se puede incorporar a la batería de reglas del sistema. De esta forma de forma única se dispone
de un sistema que aglutina el conocimiento de ambos mundos de detección que tradicionalmente
han sido separados.
Hipótesis fundamental 2: Homogeneidad.
Es factible analizar de forma homogénea los
diferentes parámetros heterogéneos propios de los Métodos de Detección de Usos Indebidos y
de Detección de Anomalías orientados al Host. E incluso yendo un paso más adelante, se
pueden homogeneizar los veredictos entre Sistemas de Detección basados en Host (HIDS) con
los veredictos de los Sistemas de Detección basados en Red (NIDS).
Como puede observarse estas hipótesis pretenden aglutinar el resultado nal de el presente
proyecto: un sistema homogéneo entre diferentes fuentes:
Terminales Móviles (Symbian OS, Windows Mobile, Linux Mobile...)
Terminales Cableados
Redes y gestión de las mismas
Para lo que se ha creado una infraestructura que permita aglutinar de forma homogénea los conocimientos de los Sistemas Probabilísticos Expertos que se han desarrollado para cada submundo.
Aquí se abre una vía por la que una organización puede tener a buen recaudo el completo de
sus sistemas informatizados. Poco a poco se irá exponiendo la forma en la que se ha desarrollado
cada parte y el modo en que se va integrando en el sistema infraestructural completo.
51
1.6. Objetivos
Por todo lo anterior, el objetivo fundamental de ESIDE-Mendizale es desarrollar un Sistema
de Detección y Prevención de Intrusiones en Terminales Móviles, que detecte ataques conocidos
y no conocidos (Zero-Day Attacks), mediante Detección de Anomalías en las llamadas al Sistema Operativo; cumpliendo de esta forma con los objetivos del VI Programa Marco, dentro del
Espacio Europeo de Investigación, en concreto en todo lo relativo a la línea "Towards a Global
Dependability and Security Framework", que establece el objetivo prioritario de investigación
en medidas de seguridad orientadas al fortalecimiento de sistemas informáticos, para asegurar la
conabilidad en el uso de las TICs; así como con los objetivos del Plan de Ciencia y Tecnología del País Vasco, en el área prioritaria Entorno Seguro de Transacciones y Pago en Negocio
Electrónicoâ, del Programa Empresa Digital.
Asimismo, según las impresiones recogidas en la 11th International Conference on Concurrent Enterprising (recientemente celebrada en Munich y bajo la cual se organiza el Proyecto
MOSAIC, nanciado por dicho VI Programa Marco), la Seguridad en Movilidad es uno de los
pilares fundamentales para el pleno desarrollo de las TICs en Mobile Collaborative Working
Environments, una de las futuras líneas prioritarias del VII FP. Así pues, para ello, se creará
en tiempo real, mediante una herramienta matemática denominada Red Bayesiana (denominada
así en honor al creador de su principio básico de funcionamiento, Thomas Bayes, y desarrollada
como mecanismo computacional eciente de análisis multivariable por Judea Pearl, investigador
de la Universidad de Cambridge), un modelo del comportamiento normal del terminal móvil,
para posteriormente analizar la actividad cotidiana del mismo y detectar desviaciones que puedan comprometer su seguridad. En concreto, se pretende utilizar una tecnología recientemente
desarrollada y publicada por Intel Corporation, y conocida bajo el nombre de OpenPNL (Open
Probabilistic Network Library), para la programación de sus nuevos prototipos de chips de apoyo
inteligente a la toma de decisiones.
El objetivo fundamental que se pretende conseguir en el presente proyecto es el desarrollo de
una herramienta software que detecte ataques conocidos y desconocidos (aún no documentados)
contra terminales móviles, mediante el análisis de anomalías en las llamadas al Sistema Operativo.
Con esta información se pretende crear un modelo del comportamiento normal del trabajo
del dispositivo, para posteriormente comparar la adecuación de un determinado rastro o traza
de actividad (constituida mediante múltiples parámetros recogidos del sistema en tiempo real) al
modelo; permitiendo detectar desviaciones potencialmente peligrosas respecto al mismo. Estas
desviaciones son indicativas de un comportamiento anormal del sistema y denotan la necesidad
de noticar en forma de alarma dicho comportamiento, o de actuar de forma reactiva, impidiendo
que cualquier software malicioso pueda comprometer la seguridad del terminal.
Dada la actual situación de crecimiento del sector de las comunicaciones móviles, y las escasas
medidas de seguridad implementadas hoy por hoy en los terminales, es realmente factible el
desarrollar un producto comercial a partir del prototipo que se desarrolle en ESIDE-Mendizale.
52
Para ello, el objetivo especíco más importante que se pretende alcanzar, si bien no el único, es el
de desarrollar un nuevo método de Detección de Anomalías que resuelva las problemáticas de las
que aún adolecen los IDSs actuales y que, además, compatibilice dicho análisis con las habituales
restricciones computacionales y de almacenamiento que suelen presentar los terminales móviles.
Como ha podido observarse en el estudio del estado del arte llevado a cabo de cara a la
presentación, cada uno de los actuales enfoques de diseño de IDSs proporciona soluciones a
determinados problemas, pero deja sin tratamiento otras cuestiones; por lo que una labor importante que tendrá que afrontar el equipo investigador será la de desarrollar una solución que
sea capaz de modelizar de forma homogénea las dos grandes losofías de detección (Patrones de
Comportamiento Indebido y Anomalías), combinando las capacidades de ambas y eliminando sus
respectivos inconvenientes. De esta forma, podrá darse cumplimiento al objetivo de responder
ante situaciones de riesgo conocidas (mediante el conocimiento propio de la Detección de Patrones), y también ante situaciones anómalas (mediante el conocimiento propio de la Detección de
Anomalías), que podrían comprometer la seguridad del terminal.
Por otro lado, la capacidad preventiva de los actuales IDSs está muy limitada, y no es sucientemente efectiva en muchos casos. El IDS observa el comando, la llamada al sistema o el
paquete de red enviado por el atacante, pero no está en disposición de detener ese ataque. Como
mucho puede intentar abortar la conexión de red, o bloquear el rewall, cuando se trata de IDSs
de red, o denegar el acceso a algunos recursos cuando se trata de IDSs de host, pero por lo general
dichas respuestas suelen llegar tarde. Por lo tanto, su objetivo principal se reduce habitualmente
a la mera noticación del peligro, en la conanza de que el usuario o el administrador tomen las
contramedidas necesarias lo antes posible.
Así pues, el segundo objetivo especíco que se persigue en ESIDE-Mendizale consiste en
lograr no sólo la detección, sino también la intercepción de las solicitudes de actuación de los
usuarios del terminal móvil, para poder realizar el pertinente Análisis de Anomalías antes de que
dicha acción llegue realmente al Sistema Operativo, y sea por lo tanto ejecutada. De esta forma,
será perfectamente posible evitar ataques evidentes, con patrones conocidos y rmas de ataque
perfectamente reconocibles, y a la vez y de forma homogénea detectar ataques para los que no
existe un modelo previo pero que pueden resultar en algún tipo de perjuicio para el sistema.
Por último, una problemática adicional que suelen presentar los IDSs/IPSs, independientemente de su losofía de detección, es su alto grado de dependencia respecto del operador humano.
Por un lado, las baterías de reglas de los IDSs basados en reconocimiento de patrones deben ser
continuamente actualizadas con las rmas de los nuevos ataques se van documentando día a día,
para que el sistema pueda seguir manteniéndose efectivo. Por otro lado, los IDSs basados en
análisis de anomalías necesitan un profundo proceso de conguración personalizada y puesta a
punto, antes de ser lanzados a explotación y durante el funcionamiento cotidiano de la plataforma
en la que están instalados. Por supuesto, a este respecto, es muy conveniente mantener la losofía
de continua actualización ante el enemigo, pero también es muy deseable poder disponer de un
53
mayor nivel de automatización de los diferentes procesos del IDS/IPS; nivel de automatización
que puede conseguirse mediante técnicas de Inteligencia Articial como es el caso del Aprendizaje
Bayesiano No Supervisado que se plantea para este proyecto.
Siguiendo la línea anterior, el último objetivo especíco que se plantea en la presente propuesta
consiste en alcanzar un alto nivel de autosuciencia del IDS/IPS; objetivo que redunda de forma
natural en su exibilidad y adaptación a diferentes entornos y plataformas móviles. De esta
forma, estos objetivos persiguen el desarrollo de un IDS/IPS de Host Móvil, que sea capaz de
proteger de forma robusta toda la lógica implementada en los modernos terminales de telefonía
móvil, que se anticipe de forma eciente a situaciones de peligro conocidas o no, y que requiera
de una mínima interacción del operador humano; siendo su meta natural el posterior desarrollo
de un producto software estable y de calidad.
1.7. Estructura de la memoria
La organización de los capítulos de esta memoria es la siguiente:
Capítulo primero: Introducción.
En este capítulo se presenta el área de la Detección de
Intrusiones desde un punto de vista global, y se maniesta su relevancia como elemento de
seguridad en la actual Sociedad de la Información. Asimismo, se introducen los conceptos
fundamentales de Seguridad de la Información y Detección de Intrusiones, incluyendo el
modelo general de funcionamiento y las características más importantes que presentan
actualmente los Sistemas de Detección de Intrusiones. A continuación, a partir de dichas
características se enumeran los grandes retos que presenta la tecnología y se establecen las
hipótesis fundamentales sobre las cuales se basa la presente memoria. Por último, en base a
dichas hipótesis, se denen los objetivos generales, especícos y operacionales que deberán
alcanzarse para la correcta validación de las anteriores hipótesis.
Capítulo segundo: Entorno de trabajo.
En este capítulo se describen las dos disci-
plinas que conuyen en el presente estudio, como son la Detección de Intrusiones, por un
lado, y los Modelos de Redes Probabilísticas, por otro. Así, en primer lugar, en relación con
la primera de dichas disciplinas, se presenta la perspectiva histórica de los Sistemas de Detección de Intrusiones, desde su aparición en la década de los ochenta, hasta nuestros días.
Seguidamente, se continúa describiendo las diferentes áreas de conocimiento que componen
dicha disciplina, según el modelo conceptual propuesto por Emilie Lundin, y se analizan
las diferentes taxonomías de sistemas de detección propuestas por diversos autores, con el
objetivo de ubicar conceptualmente las hipótesis fundamentales y los objetivos enunciados. A continuación, se concluye con la descripción de las diferentes técnicas de análisis,
categorizadas según los dos grandes enfoques de diseño: Detección de Usos Indebidos y Detección de Anomalías. También se incluye un breve epígrafe en el que se describen algunas
implicaciones arquitectónicas. Por otro lado, en lo relativo a la segunda de las disciplinas
54
propuestas, se introducen los conceptos de Modelo de Red Probabilística y de Red Bayesiana, y se describen sus diferentes potencialidades, como son inferencia de conclusiones,
mediante diversos métodos de propagación exacta de evidencia, aprendizaje automático
estructural y paramétrico, y representación intrínseca de la magnitud temporal, mediante
el concepto de Red Bayesiana Dinámica.
Capítulo tercero: ESIDE-Mendizale.
Un framework bayesiano de Detección de Intru-
siones para Sistemas Móviles. En este capítulo se describe la solución propuesta, una vez
explorado el área de conocimiento de la Detección de Intrusiones, así como los diferentes
fundamentos probabilísticos. Dicha solución se ha dado en denominar ESIDE- Mendizale,
en correspondencia con el acrónimo de Mobile Environment for Discovery of Zero-Day
Attacks through Bayesian Learning. Por otro lado, para su descripción, se utiliza el modelo
conceptual propuesto por Emilie Lundin, cuya exhaustiva formulación sirve en esta ocasión
como inmejorable hilo conductor de la exposición. Así, a pesar de que las hipótesis fundamentales del presente estudio se ubican principalmente en la fase de Análisis, se describen
las cuestiones de Análisis de Riesgos y Formalización, Recogida de Información, Análisis,
Respuesta, Cuestiones Arquitectónicas, Fortaleza, Cuestiones Operacionales, Evaluación y
Aspectos Sociales.
Capítulo cuarto: Experimentación y Análisis de Resultados.
En este capítulo, una
vez denida la solución propuesta, se describe el proceso de experimentación realizado con el
objetivo de contrastar la validez de las hipótesis fundamentales de la presente memoria. Por
supuesto, a pesar de que son numerosas las implicaciones que presenta ESIDE-Mendizale
desde los diferentes puntos de vista, dichas hipótesis fundamentales se centran en la fase de
Análisis, por lo que la presente experimentación se orienta igualmente hacia esta cuestión.
Se incluyen secuencialmente los análisis de los resultados obtenidos a partir de los diferentes
experimentos.
Capítulo quinto: Conclusiones y Líneas de Investigación Futuras.
En este capítulo
se recogen las diferentes conclusiones obtenidas durante el desarrollo de las investigaciones
que han conducido a la consecución de los objetivos marcados en la presente tesis doctoral. Asimismo, también se incluye una relación de futuras líneas de investigación que son
susceptibles de abordarse a corto y medio plazo, y en base a las cuales es posible buscar
solución a ciertas cuestiones que aún permanecen por resolver, y a los nuevos retos que se
plantean a raíz de las conclusiones obtenidas.
Se concluye con un apartado dedicado a la bibliografía, con todas las referencias mencionadas
en esta memoria.
55
56
Capítulo 2
Entorno De Trabajo
2.1. Detección de Intrusiones
Durante la década de los ochenta y hasta la actualidad, el crecimiento exponencial de la
actividad subversiva contra sistemas de información de todo tipo [59] ha suscitado un desarrollo
igualmente acelerado en la investigación que se ha venido desarrollando en el área de la Detección
de Intrusiones.
Esta evolución está caracterizada por avances importantes que se han producido en momentos
puntuales, y ha venido modelando un panorama general complejo y en el que entran en juego
múltiples aspectos propios de los distintos enfoques de detección que se han desarrollado y sobre
los que se sigue investigando. Por ello, y dado que los objetivos marcados en el presente trabajo de
investigación se circunscriben a determinadas parcelas especícas de dicho panorama general, se
hace necesaria una acotación del ámbito del problema que se plantea. Con este n, en la presente
sección se procede a introducir las características generales del actual horizonte investigador, en
concreto a lo largo de los siguientes apartados, así como las características propias de aquellos
campos de la Detección de Intrusiones íntimamente ligados a los objetivos de la presente memoria,
en concreto a través del apartado de Técnicas
de Análisis .
2.1.1. Perspectiva
Tradicionalmente, las tareas de auditoría de los eventos de seguridad que se producían en
un determinado sistema de información eran llevadas a cabo de forma manual. Las máquinas en
explotación existentes en los diferentes tejidos de la sociedad no eran numerosas, las cifras de
usuarios y aplicaciones se mantenían en niveles bajos, y era no era descabellado el hecho de que
dichas tareas se realizaran de esa manera. Sin embargo, a medida que el número de máquinas,
usuarios, servicios de aplicación, capacidades de conectividad, etcétera, crecía, la magnitud del
número de eventos de seguridad adquiría progresivamente una mayor dimensión que hacía inviables los tradicionales procedimientos de auditoría. Era necesario abordar la búsqueda de nuevos
57
métodos de trabajo automatizados [84, 78, 28, 271, 15] .
De esta forma, en el año 1.980, James P. Anderson desarrolló un estudio, a petición de las
Fuerzas Aéreas de Estados Unidos [362], en el que propuso un sistema de clasicación automático
que utilizaba los eventos registrados por el subsistema de auditoría del Sistema Operativo para
detectar actividades subversivas a partir del comportamiento habitual de los usuarios de un
determinado sistema. Este trabajo supuso el comienzo de la Detección de Intrusiones en general,
así como de la Detección orientada a la Máquina y la Detección de Anomalías, en particular.
Muchas de las investigaciones que se han desarrollado desde entonces utilizan este concepto [20],
incluido el presente trabajo de investigación.
Posteriormente, a mediados de los ochenta, SRI International [327] comenzó un intenso esfuerzo investigador, por iniciativa del gobierno de los Estados Unidos, con el objetivo de analizar
los registros de auditoría de los grandes sistemas informáticos gubernamentales y crear perles de
comportamiento de los usuarios de dichos sistemas. En las primeras fases de esta investigación,
la Doctora Dorothy Denning diseñó un primer modelo general de Sistema de Detección de Intrusiones, a partir del cual se desarrolló posteriormente el denominado proyecto IDES1 [237, 396].
Las conclusiones obtenidas a partir de la realización de dicho proyecto están recogidas en su histórico artículo An Intrusion Detection Model [105], y aún hoy siguen constituyendo un referente
fundamental para todo trabajo de investigación que se desarrolle sobre el tema, sobre todo en el
campo de la Detección de Anomalías.
Por otro lado, mientras SRI International llevaba a cabo dicho proyecto IDES, el Laboratorio Lawrence Livermore [263] de la Universidad de California Davis [264] abordó el desarrollo
del proyecto Haystack2 , cuyo objetivo era la construcción de una nueva versión de Sistema de
Detección de Intrusiones para las Fuerzas Aéreas que proponía el análisis de los registros de auditoría mediante la comparación de los mismos con una batería de patrones de ataque predenidos
[Smaha88]. Dicho proyecto dio origen a lo que hoy se conoce como Detección de Usos Indebidos, y su evolución natural, denominada DIDS3 [322], constituyó asimismo la primera solución
distribuida de Detección de Intrusiones.
Posteriormente, al inicio de la década de los noventa, Todd Heberlein, investigador de la
Universidad de California Davis, presentó la idea de la Detección de Intrusiones orientada a la
Red. Hasta entonces, los estudios realizados por Anderson, Denning y el Laboratorio Lawrence
Livermore se habían centrado únicamente en la Detección orientada a la Máquina, de forma
que el desarrollo del denominado proyecto NSM4 supuso una revolución conceptual en el área
[161]. Además, las aportaciones de Heberlein fueron recogidas por el equipo de investigación
1
2
IDES: Intrusion Detection Expert System.
En una entrevista telefónica con Crosby Marks, uno de los desarrolladores del proyecto, éste confesó que:
"Searching through this large amount of data for one specic misuse was equivalent to looking for a needle in a
haystack." Este sentimiento del equipo investigador ante la magnitud del problema con el que se enfrentaban les
llevó a decidir dejar simbólica constancia del mismo en el propio nombre del proyecto [271].
3
4
DIDS: Distributed Intrusion Detection System.
NSM: Network Security Monitor.
58
del proyecto Haystack, quien extendió el proyecto DIDS con las nuevas ideas, proponiendo por
primera vez el concepto de Sistema de Detección de Intrusiones Híbrido.
En este ámbito, durante los últimos diez años, las diferentes investigaciones cientícas han
ido estabilizándose (como pueden ser los proyectos NIDES5 [19], EMERALD6 [384] o la familia
STAT7 [367, 170]), de forma que, desde nales de los años noventa y hasta la actualidad, han
aparecido múltiples productos comerciales y de libre distribución sólidos y de contrastada solvencia (como pueden ser ISS RealSecure [335] o Snort [323]), por lo general basados en Detección
de Usos Indebidos, que proporcionan soluciones ecientes a muchas de las problemáticas que
presenta el área de la Detección de Intrusiones.
Sin embargo, tal y como se explica en el apartado 1.3, la tecnología de la Detección de Intrusiones aún presenta grandes retos por superar, y aunque existen pruebas de concepto ambiciosas
y que prometen grandes resultados, dichas aproximaciones se basan por lo general en la integración de soluciones parciales, y no en el desarrollo de un modelo de representación e inferencia
intrínsecamente completo [116]. Por ello, todavía es necesario seguir trabajando en el diseño de
nuevos modelos que aborden los problemas de una forma unicada y homogénea, tal y como se
enuncia en las hipótesis fundamentales del apartado 1.4.
2.1.2. Modelo conceptual de Lundin
El desarrollo de un Sistema de Detección de Intrusiones no se limita a la obtención de un
mecanismo hardware o software que realice las tres operaciones fundamentales de recogida de
información, análisis y respuesta, constituyentes del modelo general de funcionamiento descrito
en el apartados anteriores.
Por el contrario, dichas componentes se encuentran ubicadas dentro de un contexto más
amplio y en el que existen ciertas cuestiones adicionales que es necesario tener en especial consideración a la hora de abordar el diseño de todo sistema de detección. Estas cuestiones son, en
concreto, la adaptación de dicho sistema al sistema de información que se desea proteger, el impacto administrativo y económico inherente a su despliegue, y el mantenimiento de la seguridad
ante ataques dirigidos hacia él [204, 154]. Asimismo, también es necesario prestar atención a otros
aspectos fundamentales como puede ser la denición de la taxonomía de ataques que se pretende
detectar, o la metodología de evaluación de dicho sistema de detección [17, 26, 100]. Por último,
existen ciertas consideraciones éticas y legales sobre las que igualmente es necesario realizar una
profunda reexión [116, 154]. Emilie Lundin describe este contexto, en su tesis doctoral, de una
forma excepcionalmente precisa. La gura 2.1 está extraída de dicho estudio y pretende ilustrar
las distintas áreas de conocimiento.
5
6
7
NIDES: Next Generation Intrusion Detection Expert System.
EMERALD: Event Monitoring Enabling Responses to Anomalous Live Disturbances.
STAT: State Transition Analysis Tool for Intrusion Detection.
59
Figura 2.1: Modelo conceptual de Lundin
Áreas de conocimiento
A continuación se describen las nueve áreas de conocimiento propuestas por Emilie Lundin,
las cuales sirven, además de para denir el exhaustivo modelo conceptual descrito en el apartado
anterior, para categorizar la actividad investigadora que se realiza actualmente en el campo de
la Detección de Intrusiones:
Análisis de Riesgos y Formalización
Ésta es el área de conocimiento en el que se establecen los fundamentos básicos de todo el proceso
de Detección de Intrusiones subsiguiente. En ella se dene el ámbito del problema de la detección
y se formaliza la taxonomía de intrusiones y de parámetros de detección que se pretende utilizar
como objetivo [116, 17, 26, 358, 304] . El Sistema de Detección de Intrusiones solamente será
capaz de detectar aquellos ataques que puedan especicarse en base a dicha taxonomía. De esta
forma, en este apartado, se estudian por tanto los diferentes tipos de vulnerabilidades, intrusiones
e intrusos, que se constituyen en elementos de riesgo para las plataformas tecnológicas que se
pretende proteger. Como es lógico, sin una suciente atención a esta cuestión en la fase de análisis,
sería extraordinariamente difícil desarrollar un modelo de Sistema de Detección de Intrusiones
que fuera realmente ecaz ante cualquier tipo de ataque. Además, sin unos objetivos claros y bien
denidos también se hace especialmente ardua la tarea de evaluación de la ecacia y eciencia
de cualquier tipo de sistema de detección [93].
Recogida de Información
60
En esta área se denen la taxonomía y el formato de los datos que se deben registrar para
desarrollar convenientemente las tareas de análisis. Además, otras cuestiones fundamentales que
se plantean en este punto son cómo debe realizarse la tarea de recogida de información, qué
mecanismos de recogida son los más adecuados para ser utilizados, dónde se va a realizar el
almacenamiento de dicha información, y en qué puntos del sistema es más conveniente realizar
dicha recogida. El posterior análisis y por lo tanto el resultado último de la detección, serán tan
ecaces como lo sea el presente proceso de recogida de información [116, 92, 204, 277, 134, 255].
Una mala calidad de los datos recogidos se traduce habitualmente en una menor cobertura ante
los ataques, una mayor tasa de falsos positivos, y en una reducción de la eciencia.
Análisis
La tarea de análisis es el corazón de la Detección de Intrusiones, su núcleo, ya que de ella
dependen las decisiones últimas que deben tomarse en el sistema de detección. En esta área
recae, por lo tanto, la responsabilidad de determinar con precisión y eciencia la línea que separa
el comportamiento legítimo de los usuarios de la infraestructura tecnológica de una determinada
organización, del comportamiento subversivo contra dicha infraestructura. De esta forma, el reto
que supone afrontar dicha responsabilidad hace que sea precisamente este componente de análisis
el que constituya el área de conocimiento sobre la cual se viene realizando en los últimos años el
mayor número de investigaciones y publicaciones cientícas [65, 116, 84, 340, 78, 28, 92, 15, 26,
367, 100].
Respuesta
Una vez que el componente de análisis ha tomado una decisión, es responsabilidad del componente
de respuesta llevar a cabo las acciones pertinentes. En el caso de haberse detectado un intento de
intrusión, o bien una intrusión efectiva, es necesario poner en marcha los mecanismos de alerta
pasiva o activa de que se disponga. Es perentorio noticar dicha intrusión al administrador del
sistema, y mitigar en la medida de lo posible el impacto potencial de dicha intrusión sobre la
infraestructura tecnológica. Las investigaciones en esta área apuntan hacia el desarrollo de nuevos
modelos de representación gráca de intrusiones, mecanismos de respuesta automática ecaces y
seguros, y elaboración de deniciones formales de las limitaciones a las que deben estar sujetos
dichos mecanismos de respuesta activa [116, 27, 28].
Cuestiones Arquitectónicas
La realidad tecnológica de la mayoría de las actuales corporaciones y organizaciones está caracterizada por el alto nivel de conectividad de sus sistemas de computación. La presencia de redes
de comunicación de diferentes tipos es condición sine qua non y la distribución de los componentes de los modelos de negocio propiciada por dicha conectividad es una práctica ampliamente
extendida.
61
De esta forma, no es descabellado pensar, asimismo, en la distribución de las distintas etapas
del proceso de Detección de Intrusiones [89, 116, 49, 92, 384, 330, 322], con el objetivo de
alcanzar mayores cotas de eciencia, tolerancia a fallos y escalabilidad. Sin embargo, la habitual
heterogeneidad de los sistemas de computación, así como de las redes de comunicación, introduce
una importante componente de complejidad en el sistema de detección, a la hora de recoger
información proveniente de diferentes sistemas operativos, diferentes protocolos de comunicación,
diferentes servicios de aplicación, etcétera.
Por otro lado, existen ciertas particularidades técnicas propias de los diferentes tipos de
arquitecturas que pueden llegar a suponer un obstáculo en la labor de dicho sistema de detección,
como pueden ser las anteriormente descritas cuestiones de las redes conmutadas o del cifrado de
las comunicaciones. Los costes de administración pueden elevarse considerablemente, en función
de la exibilidad que permita el sistema de detección en el momento de su despliegue. [351, 84,
78, 28, 15, 26, 100, 204]
Fortaleza
Como se ha explicado en apartados anteriores, el propio Sistema de Detección de Intrusiones
se convierte desde el momento de su implantación en uno de los objetivos fundamentales de
cualquier intruso. Para él, es necesario pasar lo más desapercibido posible, y la labor del sistema
de detección es precisamente la contraria. Esta es la razón por la que los sistemas de detección
suelen ser objeto de múltiples atentados contra su propia integridad y disponibilidad[116, 385].
En concreto, es muy importante proteger la etapa de recogida de información, tanto durante el
desarrollo de la misma, como posteriormente, en el momento del almacenamiento de la información que debe surtir al proceso de análisis [191]. De otra forma, la información de partida puede
ser objeto de subversión y el sistema de detección estaría proporcionando una falsa sensación de
seguridad. [116, 351, 84, 165, 78, 28, 164, 92, 15, 26, 358, 77]
Cuestiones Operacionales
Existe una amplia colección de cuestiones relativas a la utilización de los Sistemas de Detección
de Intrusiones por parte de los usuarios, entre las que se encuentran la cuestión del mantenimiento, la escalabilidad, la portabilidad o la extensibilidad. Además, existen otros aspectos
importantes como pueden ser la interoperabilidad entre los distintos componentes o incluso entre distintos sistemas de detección, o la supervisión administrativa necesaria para la correcta
parametrización de dichos sistemas. Por ello, es necesario prestar especial atención a esta cuestión de la operatividad, ya que puede marcar en muchos casos la diferencia entre una solución
eciente y que ofrece resultados de conanza, y un software sin utilidad real para el usuario
[116, 351, 84, 340, 28, 164, 92, 15, 358, 77].
Evaluación
62
Esta área de conocimiento debe enfrentarse a una cuestión sobre la que aún hay mucho trabajo
por desarrollar, como es la vericación de los resultados, tanto de análisis como de rendimiento, ofrecidos por los Sistemas de Detección de Intrusiones. Dicha cuestión de la evaluación ha
demostrado empíricamente ser un problema de difícil solución, ya que no es fácil encontrar una
taxonomía precisa de las propiedades de detección que deben medirse. Es necesario denir las
propiedades que caracterizan de la forma más adecuada múltiples tipos de sistemas de cómputo
y diferentes tipos de redes de comunicación, y además es necesario denir el conjunto de procedimientos de evaluación que deban aplicarse sobre dichas propiedades. De lo contrario, ante la
ausencia de una referencia sólida en la cuestión de la evaluación, ni los fabricantes de solución de
detección podrán comprobar la efectividad de sus productos, ni los investigadores podrán estar
seguros de la solidez de los modelos de detección sobre los que investigan [116, 249, 93, 232, 184].
Aspectos Sociales
La última cuestión componente del modelo conceptual hace referencia al nivel de responsabilidad
social que puede recaer sobre las decisiones tomadas por el Sistema de Detección de Intrusiones, y
que pueden afectar a terceras partes. Los problemas básicos que pueden observarse a este respecto
hacen referencia, por un lado, al nivel de agresividad que puede congurarse en la respuesta del
sistema de detección (máxime teniendo en consideración cuestiones como la potencialidad de
falsicación de la identidad del atacante), así como las cuestiones de privacidad derivadas de
la recogida de información necesaria para el proceso de detección. Asimismo, existe una última
consideración consistente en la potencial adaptación de los modelos de respuesta con el objetivo
de que sean capaces de proporcionar información pericial de carácter forense[116, 28, 154, 358] .
Actuales Líneas de Investigación
Cada una de las áreas de conocimiento descritas anteriormente presenta en mayor o menor
medida ciertas cuestiones aún no resueltas y sobre las cuales la comunidad cientíca plantea sus
líneas de investigación, con mayor o menor intensidad.
Con el objeto de construir una imagen de conjunto de los estudios más importantes que se
están llevando a cabo en la actualidad en el área de la Detección de Intrusiones, Emilie Lundin
y Erland Jonsson han realizado una recopilación de los artículos publicados en las conferencias
más representativas del sector durante los últimos años [116].
En la siguiente tabla, se incluye la versión completa que aparece en el estudio original, y en
la que se hace referencia al número de investigaciones realizadas en los últimos años en las nueve
áreas de conocimiento que componen el modelo conceptual.
63
Cuadro 2.1: Líneas de Investigación sobre Detección de Intrusiones
Relación entre retos y líneas de investigación
Cada una de las líneas de investigación descritas anteriormente y cuyo volumen de publicaciones se recoge en el apartado anterior, está íntimamente relacionada con los retos tecnológicos
descritos en el Capítulo 1. La tabla puesta a continuación describe de forma gráca dichas relaciones. Como puede observarse, la línea de investigación de análisis (la cual presenta, con una
gran diferencia con respecto al resto de líneas, el mayor número de publicaciones, según la tabla
anterior) aborda por sí misma la mayoría de los retos fundamentales descritos en el capítulo
primero, por lo que la selección de la misma como elemento fundamental del presente trabajo de
investigación puede calicarse como una opción más que razonable.
2.1.3. Taxonomía
De entre los diferentes elementos componentes del modelo conceptual de Lundin, aquéllos
que tradicionalmente se han utilizado para categorizar las distintas tipologías de Sistemas de Detección de Intrusiones han sido los que corresponden al conjunto de consideraciones funcionales
básicas. De esta forma, la recogida de información, el análisis y la respuesta son los tres pilares fundamentales que se consideran habitualmente, si bien en algunas ocasiones otras cuestiones
adicionales (arquitectónicas u operacionales, por lo general) son utilizadas también como criterios
de categorización. A este respecto, autores de reconocido prestigio internacional como pueden ser
Alessandri, Allen, Axelsson, Bace, Debar, Kahn, Krügel o Lazarevic, expresan diferentes sensibilidades respecto a la cuestión de la categorización, por lo que no existe una taxonomía general
64
Cuadro 2.2: Relación entre retos de la Detección de Intrusiones y líneas de investigación
única que pueda utilizarse como referente universal. Por ello, y con el objetivo de establecer una
clasicación general sobre la cual denir el ámbito y la ubicación conceptual del presente trabajo de investigación, se incluye a continuación un breve estudio sobre las diferentes alternativas
existentes.
Taxonomía de Alessandri et al.
A pesar de que el objetivo principal del trabajo de Alessandri et al. [17] consiste en clasicar,
fundamentalmente a nivel operacional y no tanto a nivel conceptual, tanto los distintos tipos de
sistemas de detección, como los distintos tipos de actividad subversiva, incluye una interesante
taxonomía general de Sistemas de Detección de Intrusiones. La gura siguiente ilustra dicha
taxonomía:
Dicha taxonomía está construida a partir de un modelo general de funcionamiento simple, en
el cual solamente se consideran los componentes de recogida de información y análisis. Dicho modelo general es compatible con los esfuerzos que desarrolla el Intrusion Detection Working Group
(IDWG) del IETF con el objetivo de estandarizar los ujos de información entre componentes
[102].
Taxonomía de Allen et al.
Julia Allen se aproxima considerablemente al modelo general propuesto por Alessandri [15].
En este caso, la descripción funcional de un Sistema de Detección de Intrusiones se divide en
tres elementos componentes: Sensor, analizador e interfaz de usuario. Alessandri consideraba
65
Figura 2.2: Taxonomía de Alessandri et al.
Figura 2.3: Modelo general de Alessandri et al.
66
Figura 2.4: Taxonomía de Allen et al.
que la cuestión del interfaz podía generalizarse fuera del sistema de detección, por lo que sólo
contemplaba las dos primeras cuestiones. Por otro lado, a partir de dicho modelo, se describen
independientemente las cuestiones de la recogida de información y del análisis. De esta forma,
en cuanto a la cuestión de la recogida de información, Allen establece cuatro tipos de fuentes de
información desde las cuales puede realizarse el proceso de detección: Aplicación, máquina, red o
infraestructura multi-red. Además, en concreto, en la recogida de información basada en máquina,
se diferencia el nivel lógico desde el que se recoge la información para la fase de análisis: A nivel
de servicio de aplicación de auditoría, y a nivel de servicio de llamadas al sistema. Por último,
en cuanto a la cuestión del método de análisis, se describen las dos grandes losofías: Detección
de usos indebidos, rmas, o patrones, y detección de anomalías. La taxonomía representada en
la gura 2.4 es un compendio de todas estas consideraciones:
Taxonomía de Bace y Mell
Rebecca Bace y Peter Mell siguen un modelo de taxonomía similar al propuesto por Allen
et al., si bien en este caso se presta una mayor atención al componente de respuesta, en el cual
se pasa de dar por supuesta la pasividad del mecanismo de respuesta (como es característico de
los casos anteriores), a considerar el hecho de que dicho mecanismo pueda responder de forma
activa [28]. La gura 2.5 ilustra esta taxonomía.
Taxonomía de Axelsson
A pesar de que Stefan Axelsson centra su estudio general sobre Detección de Intrusiones en
los principios fundamentales del componente de análisis (el cual lógicamente presenta un mayor
interés cientíco), también incluye una detallada categorización sobre el resto de características propias de todo sistema de detección [26]. La gura a continuación ilustra la taxonomía
presentada por dicho autor:
67
Figura 2.5: Taxonomía de Bace y Mell.
Figura 2.6: Taxonomía de Axelsson
68
Figura 2.7: Taxonomía de Debar, Dacier y Wespi
Taxonomía de Debar, Dacier y Wespi
Una taxonomía muy utilizada como referencia en la bibliografía [297] es la desarrollada por
Debar, Dacier y Wespi en 1.999 [100]. En ella, además de los tres grandes elementos de categorización que aparecen en la taxonomía de Bace, se introduce la componente de la frecuencia
de análisis del sistema de detección. Este aspecto ha sido especialmente relevante durante las
primeras etapas de la evolución de la Detección de Intrusiones, ya que marcaba la diferencia
entre aquellos sistemas que eran capaces de detectar casos de intrusión en el mismo instante en
que ésta se estaba produciendo, y aquéllos que no. Sin embargo, en la actualidad, la práctica totalidad de Sistemas de Detección de Intrusiones operan en tiempo real, por lo que dicha tipología
de clasicación ha perdido cierta importancia.
Esta clasicación fue revisada por Stefan Axelsson [26] y el propio Debar apenas un año
después [101]. En dicha revisión, se introdujo el concepto de paradigma de detección como nuevo
criterio principal de clasicación; paradigma que hace referencia al tipo de análisis que se realiza
y que presenta dos alternativas posibles: Detección orientada al análisis de los estados por los
que pasa el sistema, y detección orientada al análisis de las transiciones entre dichos estados.
Asimismo, dichas alternativas presentan a su vez dos enfoques distintos en lo referente a la
evaluación que llevan a cabo sobre el sistema: Evaluación proactiva y evaluación pasiva o no
intrusiva.
Por último, en cuanto al tipo de fuente de información, se introducen dos nuevas alternativas: Registro de auditoría de aplicación, por un lado8 , y registro de alertas provenientes de
otros sistemas de detección9 , conectados secuencialmente, por otro. La gura 2.8 ilustra estos
8
Concepto que hace que la taxonomía en cuestión se mantenga en perfecta consonancia con las alternativas
propuestas por Allen [15] y Bace [28].
9
Concepto que contempla la posibilidad de que un determinado Sistema de Detección de Intrusiones utilice
la información proveniente de otros sistemas de detección conectados, de esta forma, de manera secuencial. Esta
organización cooperativa de múltiples sistemas de detección permite abordar la problemática de la Reducción de
Auditoría [322] de una forma potencialmente más eciente.
69
Figura 2.8: Taxonomía revisada de Debar, Dacier y Wespi.
renamientos realizados sobre la taxonomía original.
Taxonomía de Lazarevic, Kumar y Srivastava
El modelo taxonómico más reciente es fruto de los estudios realizados por Aleksandar Lazarevic, Vipin Kumar y Jaideep Srivastava [227], y está basado fundamentalmente en las taxonomías
propuestas anteriormente por Stefan Axelsson [26] y Hervé Debar et al.[100]. En particular, a
los tres pilares fundamentales de recogida de información, análisis y respuesta, se propone la
agregación de la cuestión arquitectónica, así como de la cuestión de la tipología de restricciones
temporales a las que el sistema de detección debe estar sujeto.
Taxonomía de Krügel
Christopher Krügel utiliza en su tesis doctoral[50] una taxonomía similar a la propuesta por
Rebecca Bace y Peter Mell [28], a la cual añade el criterio fundamental del almacenamiento
de datos de auditoría. A continuación se describe, mediante la siguiente gura, la taxonomía
resultante.
Taxonomía de Indian CERT
El Indian Computer Emergency Response Team propone una clasicación de Sistemas de
Detección de Intrusiones dividida en dos grandes grupos de características: Componentes fundamentales y cuestiones adicionales [CERT/IN03].
70
Figura 2.9: Taxonomía de Lazarevic
Figura 2.10: Taxonomía de Krügel
71
Figura 2.11: Taxonomía de Indican CERT.
Como puede observarse, las cuestiones fundamentales son idénticas a las recogidas por Bace
y Mell en su propuesta de taxonomía. Por otro lado, las mencionadas cuestiones adicionales
toman en consideración las diferentes tipologías que pueden plantearse en cuanto a arquitecturas,
estrategias de control y temporización.
En concreto, en primer lugar, se hace referencia a la cuestión de la ubicación del sistema de
detección, que puede realizarse bien sobre el propio sistema objetivo a proteger, o bien mediante
una máquina especíca dedicada a tal efecto. En segundo lugar, se hace referencia al hecho
de que el control del sistema de detección puede llevarse a cabo desde diferentes niveles de
descentralización, de forma que puede optarse bien por una estrategia centralizada, bien por una
solución completamente distribuida, o bien por un esquema intermedio.
Por último, la periodicidad operativa del sistema de detección puede categorizarse en dos
grandes grupos: por un lado, sistemas orientados a determinar la ocurrencia o no de intrusiones
en el sistema con nes puramente forenses, y por otro, sistemas orientados a detectar inmediatamente cualquier intento de intrusión, con el objetivo de poder plantear una respuesta mientras
dicha intrusión aún está teniendo lugar.
Common Intrusion Detection Framework
Con el objetivo de proporcionar un marco de trabajo estándar, que permitiera tanto a fabricantes como a investigadores eliminar las dicultades de integración y comunicación que presentaban los distintos elementos de las múltiples arquitecturas de detección existentes, Kahn,
72
Figura 2.12: Arquitectura CIDF.
Porras, Staniford-Chen y Tung propusieron en 1.998 una arquitectura genérica, dividida en tres
grandes pilares fundamentales [208] que se describen a continuación:
Arquitectura de detección CIDF10 , construida a partir de componentes genéricos, denominados
Boxes,
y que son responsables de las tareas de recogida de información, almacena-
miento, análisis y respuesta.
Lenguaje de comunicación entre componentes CISL11 , que permite un intercambio de información semántica estándar y bien denida.
Especicación de directorio, a partir de la cual los diferentes componentes pueden localizarse y autenticarse entre ellos.
Contribución de Kim y Spaord
Dentro del área de conocimiento de la Detección de Intrusiones orientada a la Máquina, Gene
Kim y Eugene Spaord introdujeron en 1.994, en su artículo
of Tripwire: A File System Integrity Checker,
The Design and Implementation
el concepto de Vericación de Integridad, también
conocido como Detección de Intrusiones orientada a Objetivos12 . En dicho artículo, los autores
proponían un Sistema de Detección de Intrusiones que aplicaba técnicas criptográcas de cifrado
irreversible para garantizar la integridad de aquellos recursos críticos del sistema a proteger.
De esta forma, aparecía una nueva tipología de sistema de detección que, si bien mantenía
claramente su orientación a la máquina, dejaba de utilizar información proveniente de los registros
de auditoría de sistemas operativos y servicios de aplicación, y pasaba a utilizar sus propios
registros [389].
10
11
12
CIDF: Common Intrusion Detection Framework.
CISL: Common Intrusion Specication Languaje.
Detección de Intrusiones orientada a Objetivos o Target-based Intrusion Detection.
73
Figura 2.13: Taxonomía ESIDE.
Contribución de Ko, Ruschitzka y Levitt
Dentro del área de conocimiento de la Detección de Anomalías, Calvin Ko, Manfred Ruschitzka y Karl Levitt introdujeron en su artículo Execution monitoring of security-critical programs
in distributed systems: A specication-based approach, el concepto de Detección de Anomalías
basada en Especicación. Dicho concepto supone una importante innovación con respecto a la
losofía tradicional de detección de anomalías, que abogaba por la creación de perles (por lo
general estadísticos) de comportamiento para su posterior contraste con la actividad cotidiana
de los usuarios del sistema [213]. En el caso de la presente propuesta, dichos perles no se construyen dinámicamente, sino que se especican a partir de conocimiento experto que se formaliza
en forma de reglas. De esta forma, todo comportamiento que se desvíe signicativamente del
conjunto de reglas preestablecidas será susceptible de ser catalogado como subversivo, y recibirá
consecuentemente una respuesta en esta línea.
Taxonomía ESIDE-Mendizale
A partir de las múltiples consideraciones descritas en los apartados anteriores, se propone
un modelo de taxonomía general que pretende sintetizar los diferentes puntos de vista, desde
una perspectiva conceptual. Dicha taxonomía presenta tres pilares fundamentales: recogida de
información, análisis y respuesta [351, 28, 15] , tal y como se ilustra en la gura. Además, como
puede observarse en dicha gura, cada uno de esos tres pilares fundamentales presenta una
categorización propia, construida a partir de las diferentes reexiones aportadas por los autores
anteriores. En primer lugar, se clasican los Sistemas de Detección de Intrusiones en base al tipo
de recogida de información que implementan, que puede estar orientada a la máquina, o a la red
[100].
74
Figura 2.14: Ubicación de hipótesis fundamentales
De esta forma, dentro de las soluciones orientadas a la máquina, en primer lugar, pueden
observarse sistemas de detección basados en información del Sistema Operativo, de los servicios
de aplicación, o de sus propios registros de auditoría (característica particular de los sistemas
de vericación de integridad) [389]. Además, la recogida basada en el sistema Operativo puede
realizarse, asimismo, a nivel de servicio o a nivel de kernel o núcleo [15].
Por otro lado, en segundo lugar, la recogida de información orientada a la red presenta,
además de los mecanismos propios de dicha categoría, un tipo especial de sistema de detección
que se caracteriza por su orientación al nodo de red [84, 78, 241].
Asimismo, en lo relativo al método de análisis, la taxonomía propuesta contempla las dos grandes losofías de Detección de Intrusiones: Detección de Usos Indebidos y Detección de Anomalías
[351, 50, 28, 15, 101, 100, 208]. Además, dentro de la Detección de Anomalías, se presta especial
atención a la cuestión de la presencia o no de conocimiento experto, ya que el presente trabajo
de investigación considera especialmente la clara diferenciación que existe entre ambos métodos
[213].
Por último, la fase de respuesta presenta dos categorías de sistemas de detección: Por un lado,
la tradicional respuesta pasiva, consistente en noticaciones de alarma al operador humano, y
por otro, la respuesta activa contra agresiones detectadas contra el sistema que se pretende
proteger [351, 49, 28, 101, 100, 208]. Además, en lo relativo a la respuesta activa, se diferencia
entre aquellos sistemas que responden a la agresión y aquéllos diseñados para impedir que dicha
agresión consiga impactar en dicho sistema (concepto comúnmente identicado con el término
Prevención de Intrusiones) [337, 341].
75
2.2. Técnicas de análisis
Como se ha expuesto anteriormente, en los apartados anteriores, el componente de Análisis
constituye la línea de investigación en la que existe actualmente un mayor interés y sobre la cual
se está llevando a cabo la mayor actividad investigadora, tanto dentro del mundo académico
como dentro de la industria de la Seguridad de la Información.
Dicho componente acapara en estos momentos el mayor número de publicaciones de las
más prestigiosas conferencias internacionales, y centra sobre sí mismo las mayores inquietudes
innovadoras del área de conocimiento de la Detección de Intrusiones.
Además, tal y como se ha explicado, dicho elemento mantiene una íntima relación con los
retos tecnológicos que aún esperan ser resueltos, por lo que se revela claramente como el camino
por el que debe desarrollarse toda investigación relevante. Por todo ello, tanto las hipótesis fundamentales, como los objetivos generales, especícos y operacionales, se centran precisamente en
el mencionado módulo de análisis, y están basados esencialmente en los principios fundamentales
de éste.
De esta manera, con el objetivo de situar la actividad investigadora realizada en el presente
estudio en el vasto horizonte de cuestiones propias del área de la Detección de Intrusiones, se
describen a continuación las principales losofías de análisis existentes en la actualidad, esto es:
Detección de Usos Indebidos y Detección de Anomalías.
2.2.1. Detección de Usos Indebidos
Tal y como se explica en la denición 1.20, la Detección de Usos Indebidos hace referencia
al método de Detección de Intrusiones que aboga por utilizar la denición previa de dichas
intrusiones para su posterior contraste con la actividad cotidiana del sistema que se desea proteger
[28]. De esta manera, la operatoria del sistema de detección está basada por completo en la vasta
recopilación de conocimiento experto proveniente del operador humano, y que incluye una ingente
cantidad de deniciones de ataques conocidos, así como de vulnerabilidades conocidas. Así pues,
una vez recogido dicho conocimiento experto, la detección de cualquier rastro de una actividad
que previamente haya sido catalogada como maliciosa (y que utilice por lo tanto alguno de
los ataques documentados, o intente explotar alguna de las vulnerabilidades conocidas) puede
llevarse a cabo de forma eciente y, sobre todo, muy precisa.
No obstante, es precisamente el motivo de su efectividad la razón de que este tipo de Sistemas
de Detección de Intrusiones se encuentre enormemente limitado para responder ante situaciones
de riesgo para las que no existe un modelo previamente documentado. Por lo general, ante una
ligera variación de uno de los ataques documentados, el sistema de detección no localiza en
su base de conocimiento la rma o patrón representativo de dicho ataque y es por lo tanto
incapaz de responder. Esta cuestión obliga al administrador humano a una minuciosa (y por lo
tanto, costosa) elaboración de las rmas de ataque, con el doble objetivo de que sean lo más
76
Figura 2.15: Modelo general de Detección de Usos Indebidos.
genéricas posible y de que no generen falsos positivos. Por otro lado, la respuesta ante un ZeroDay Attack es igualmente fallida, lo que obliga (al igual que en el caso anterior) a una periódica
actualización de dicha base de conocimiento. En general, estas características propias de los
sistemas de detección basados en Detección de Usos Indebidos hacen que dichos sistemas sean
calicados habitualmente como precisos pero incompletos [100].
Así pues, con el objetivo de proporcionar una visión general sobre el funcionamiento interno de
este tipo de sistemas de detección, que permita extraer las conclusiones necesarias para identicar
las problemáticas existentes y enunciar los grandes retos que aún presenta esta tecnología, se
describen a continuación los principios básicos de funcionamiento sobre los cuales está construida
la inmensa mayoría de ellos.
Reconocimiento estático de Patrones.
Está técnica es la forma de Detección de Usos Indebidos más simple que existe, así como la
más extendida, y está basada en la búsqueda de patrones o rmas básicas13 dentro del ujo de
eventos proporcionado por el mecanismo de recogida de información [297, 317]. Dichos patrones
están constituidos por lo general por un conjunto de atributos discretos que tiene el objetivo de
formalizar el conocimiento experto que se deberá utilizar durante el proceso de detección. Por
otro lado, a pesar de las limitaciones semánticas que presenta este método, su sencillez permite
conseguir una gran eciencia a la hora de tomar decisiones, por lo que su utilización es en
muchos casos más que suciente. Algunos de los actuales Sistemas de Detección de Intrusiones
que utilizan, entre otras, esta técnica son Snort, Bro96[277], NFR97 [260, 294], RealSecure,
CISCO Secure IDS [69], o Dragon [171].
13
Es muy habitual la denición de patrones mediante la especicación de cadenas de símbolos que se correspon-
den con diferentes métodos de ataque. Si se localiza una cadena o subcadena concreta dentro de un determinado
evento, se habrá detectado el correspondiente ataque.
77
Figura 2.16: Batería de reglas de Snort para detección de Shellcodes
Figura 2.17: Firma de Snort para detección de ataques contra Apache
Figura 2.18: Firma de Bro para detección de ataques contra Apache
78
Figura 2.19: Batería de reglas de Dragon para detección de Shellcodes
Figura 2.20: Firma de NFR para detección del histórico ataque Land Attack
79
Probabilidad Condicional
El método anterior presenta un comportamiento suciente en muchos casos, pero adolece de
una importante carencia de capacidad representativa [297]. En concreto, es habitual el hecho
de que un determinado patrón identique la existencia de su ataque correspondiente no de
forma categórica, sino con una cierta probabilidad [304]. De esta manera, es posible la aparición
de situaciones en las que la detección del patrón no implique absolutamente el hecho de que
el sistema esté siendo atacado. Por ello, un motor de análisis semánticamente completo debe
contemplar el concepto de probabilidad condicional [155]:
(2 : 1)
P (Intrusion/P atron)14
A continuación, mediante la aplicación del Teorema de Bayes [360] a la expresión anterior,
es posible obtener:
(2 : 2)
P (Intrusion/P atron) = P (P atron/Intrusion)
P (Intrusion)
P (P atron)
De esta forma, a partir de la expresión 2.2, un administrador humano es capaz de cuanticar dicha probabilidad condicional, simplemente mediante el cálculo de los tres términos que
componen dicha expresión. Para ello, es necesario disponer de un registro histórico que recoja la
experiencia del sistema, y a través del cual sea posible cuanticar la probabilidad a priori15 [155]
de la ocurrencia de una intrusión, o P (Intrusion).
Asimismo, gracias a dicho histórico también es posible determinar, para cada uno de los patrones de ataque, tanto la probabilidad a priori de dicho patrón, o P (P atron), como la probabilidad
condicional P (P atron/Intrusion).
Por otro lado, este modo de calcular la probabilidad condicional puede no ya utilizarse ante
eventos individuales, sino extenderse incluso a secuencias de eventos, con lo que se consigue una
mayor capacidad representativa del estado del sistema que se pretende proteger. Para ello, sería
necesario calcular, de una forma similar, la probabilidad P (Intrusion/Secuencia De Eventos
[304].
Sistemas Expertos
Otra losofía de análisis, extremadamente potente, que se ha aplicado en algunas ocasiones a
la Detección de Intrusiones basada en Detección de Usos Indebidos es la utilización los denominados Sistemas de Producción o Sistemas Expertos[387]. Dichos sistemas persiguen el objetivo
fundamental de independizar la lógica de decisión del conocimiento necesario para formalizar la
solución a los problemas a los que se aplican. De esta forma, un sistema experto está compuesto
14
La expresión 2.1 indica la probabilidad condicional de que se haya producido una intrusión, ante la evidencia
de haberse detectado un determinado patrón de ataque.
15
102
80
Figura 2.21: Regla de MIDAS para monitorización de cuentas de usuario privilegiadas
Figura 2.22: Regla de MIDAs para análisis de horario inusual en el acceso a cuentas de usuario
por lo general de un motor de análisis o inferencia, responsable de la toma de decisiones, y de
una base de conocimiento basada en la especicación de baterías de reglas, cuya elaboración es
responsabilidad del experto humano.
En general, las reglas en las que estos sistemas codican el conocimiento experto responden
al modelo if-then, de forma que habitualmente están compuestas por dos elementos: un conjunto
de condiciones o hechos, y un conjunto de acciones a llevar a cabo en caso de que se cumplan las
condiciones correspondientes. De esta forma, cuando el motor de inferencia detecta que un determinado evento satisface el conjunto de condiciones de una regla, simplemente dispara el conjunto
de acciones asociado a dicha regla, pudiendo conrmar de esta forma nuevos hechos (satisfacer
nuevas condiciones) que permiten a su vez disparar nuevas reglas, de forma encadenada, hasta
que es explotado todo el conocimiento disponible.
A pesar de que esta losofía de detección resulta muy precisa, por lo general, el gran volumen
de datos de auditoría que habitualmente es necesario procesar a través del motor de inferencia
puede llegar a introducir serios problemas de rendimiento durante su explotación. El proyecto
Haystack [306] fue, en 1.988, el primer caso de sistema experto aplicado a la Detección de Intrusiones, si bien han aparecido desde entonces (sobre todo en los primeros años de la evolución)
otras muchas soluciones que aplican conceptos similares, como pueden ser MIDAS16
IDES, NIDES, EMERALD, DIDS o CMDS
18
17
[317],
[272].
También los más recientes y anteriormente mencionados Snort, Bro, NFR, RealSecure, CISCO Secure IDS, o Dragon usan esta técnica, en mayor o menor medida. Sin embargo, por lo
general, el conocimiento experto utilizado en estos sistemas no contempla la posibilidad de que
determinados patrones o rmas habiliten el disparo encadenado de nuevas reglas, lo que representa la pérdida de uno de los pilares fundamentales de los sistemas expertos. De esta forma,
16
17
MIDAS: Multics Intrusion Detection and Alerting System.
MIDAS utiliza el denominado Production-Based Expert System Toolset (P-BEST), desarrollado inicialmente
por Alan Whitehurst y evolucionado posteriormente en los desarrollos de IDES, NIDES y EMERALD [231].
18
CMDS: Computer Misuse Detection System.
81
Figura 2.23: Base de hechos de P-BEST/EMERALD para detección del histórico ataque TCP
SYN Flood.
la verdadera esencia de este enfoque queda muy frecuentemente sin explotar y restringida a tareas secundarias de registro de información forense, debido a la complejidad administrativa que
introduce su utilización plena19 .
Por otro lado, este tipo de sistemas presentan por lo general una importante limitación, relacionada con su incapacidad para representar la dimensión temporal, la cual es utilizada frecuentemente para resolver la ordenación cronológica de los eventos a medida que se van produciendo
en el sistema. El conjunto de todos los hechos demostrables de la base de conocimiento no lleva
asociada de forma implícita ningún tipo de información temporal, por lo que dichos sistemas
son simplemente incapaces de determinar el orden en que se han ido conrmando los diferentes
hechos, y por lo tanto de tomar consideración cronológica alguna durante el proceso de decisión.
Existen algunas soluciones que tratan de solventar esta cuestión mediante la especicación
explícita de la información temporal, si bien se reducen en la mayoría de los casos a propuestas
experimentales [304]. En general, aquellas problemáticas de seguridad que requieren necesariamente dichas consideraciones temporales, como pueden ser el escaneo de puertos20 o la denegación
de servicio, son resueltas mediante métodos especícos, añadidos como módulos del sistema de
detección [323].
Asimismo, otro inconveniente característico de estos sistemas consiste en que las decisiones
del motor de inferencia están limitadas cualitativamente a la calidad del conocimiento experto de
los responsables de seguridad encargados de la especicación de la base de conocimiento. Además,
el modo en que dichos responsables especican el mencionado conocimiento experto puede llegar
a hacer que la base de conocimiento sea en muchos casos completamente ininteligible, debido al
altísimo nivel de detalle que puede alcanzarse en la elaboración de las baterías de reglas, sobre
todo en entornos en los que es necesaria una alta optimización de dichas baterías.
Por último, es interesante prestar atención al hecho de que los sistemas expertos son susceptibles de ser utilizados con el objetivo de combinar múltiples parámetros de Detección de
Intrusiones, de forma que es posible construir un modelo homogéneo que, además, introduce en
el análisis el concepto de certidumbre. En cualquier caso, la representación de la certidumbre
en dichos sistemas de producción presenta grandes limitaciones, tal y como se desprende de los
19
De hecho, en las últimas versiones de Snort se apunta la posibilidad de eliminar la capacidad de encadena-
miento de reglas, en benecio de una solución de registro de información forense administrativamente más sencilla,
denominada Tagging [323].
20
Escaneo de Puertos o Port Scanning [138]: An attack that sends client requests to a range of server port ad-
dresses on a host, with the goal of nding an active port and exploiting a known vulnerability of that service. [288]
82
Figura 2.24: Batería de reglas de P-BEST/EMERALD para detección del histórico ataque TCP
SYN Flood
estudios realizados por Judea Pearl [187].
Diagramas de Transición de Estados
Esta propuesta pretende optimizar el volumen del ujo de alarmas que son transmitidas hacia
el operador humano. En concreto, su objetivo fundamental consiste en identicar, representar y
analizar las diferentes fases por las que suelen pasar, en general, los distintos tipos de agresiones
contra sistemas de información. De esta forma, en lugar de utilizar un único patrón para representar un determinado ataque, este tipo de sistemas utiliza diagramas de transición de estados,
o autómatas nitos21 [373], que representan los distintos estados que debe alcanzar un intruso
potencial para llevar a cabo con éxito dicho ataque. Asimismo, las transiciones entre estados se
caracterizan mediante condiciones, o asertos, que deben ser satisfechas para que se materialicen
dichas transiciones. Cada una de estas transiciones equivale a una regla de los anteriores sistemas
expertos. Por otro lado, el estado inicial de cada uno de los diagramas representa el estado del
sistema antes de ser agredido, mientras que el último de los estados se caracteriza por representar el éxito del ataque. Lógicamente, el sistema a proteger no debería llegar a ninguno de los
múltiples estados nales bajo ningún concepto.
De este modo, mediante el seguimiento del estado de avance en el que se encuentra un
determinado atacante, es posible liberar al administrador humano de una gran cantidad de
noticaciones de alarma. Solamente se le informa de aquellos eventos que pueden llevar al sistema
21
Denominados escenarios.
83
Figura 2.25: Escenario de STAT para detección de ataques contra servidores IMAP
Figura 2.26: Especicación en lenguaje STATL de escenario de STAT para detección de ataque
contra servidores IMAP
a un estado inseguro. La primera aproximación de Sistema de Detección de Intrusiones basado
en diagramas de transición de estados fue STAT[367, 170, 381] , que posteriormente fue portado
a sistemas Unix bajo el nombre de USTAT[203]. Las guras siguientes, extraídas de los estudios
de Steve Eckmann, describen de forma gráca un escenario de ataque contra servidores IMAP22 ,
escrito en lenguaje STATL[120].
Sin embargo, a pesar de lo aparentemente innovador de esta propuesta, la aportación conceptual que provee con respecto a los anteriores sistemas de detección basados en sistemas expertos
no es muy grande. Ambos modelos son semánticamente equivalentes [119], por lo que cualquier
diagrama de transición de estados puede representarse mediante un conjunto de reglas de producción, y viceversa. Eckmann incluso propone la traducción automática23 de baterías de reglas
de Snort24 [242] en escenarios de STAT [381]. Además, se da la circunstancia de que, en muchos
casos, los requisitos de rendimiento obligan a utilizar reglas muy ligeras y con pocas relaciones
entre ellas, por lo que dichos modelos son muy poco utilizados en la práctica.
22
23
24
IMAP: Internet Message Access Protocol. [288]
Para lo cual, el propio Eckmann ha desarrollado la herramienta Snort2Statl.
A pesar de que en la mayoría de los casos solamente se utiliza la capacidad de Snort de identicar patrones
estáticos, es posible utilizar toda la potencia conceptual de los sistemas de producción, a través de dos parámetros
especiales, denominados activates y dynamic [323].
84
Figura 2.27: Reglas de Snort para detección de ataques contra servidores IMAP
Figura 2.28: Red de Petri de IDIOT para validación del proceso de login
Redes de Petri
Una variante interesante de los sistemas de detección basados en diagramas de transición de
estados, es la propuesta en 1.994 por Sandeep Kumar y Eugene Spaord, en su sistema IDIOT25
[391], el cual hace uso de las denominadas Redes de Petri [56] para representar escenarios de
intrusión. Dichas Redes de Petri se caracterizan por poseer una capacidad semántica superior a
los tradicionales autómatas nitos [238], y su uso está muy extendido, sobre todo, en sistemas
de producción automática. En concreto, una de las características más potentes que presentan
es su capacidad de representar procesos o tareas concurrentes, de forma que un determinado
sistema puede encontrarse en un momento dado, no en un único estado de ejecución, sino en
varios. Para ello, una Red de Petri está compuesta, no sólo por un conjunto de estados y un
conjunto de transiciones entre dichos estados (como era el caso de los diagramas de transición de
estados, referenciados anteriormente), sino además por un conjunto de tokens, marcas o testigos,
que habilitan el disparo de dicho conjunto de transiciones. De esta forma, una determinada
transición no se materializará realmente, incluso aunque se conrme su condición asociada, a
menos que exista un número adecuado de tokens en los estados origen de dicha transición (que
pueden ser varios, al contrario que en el caso anterior) que la habiliten. Por otro lado, una
vez habilitada y disparada dicha transición, se consumen los tokens ya utilizados en los estados
origen, y se crean nuevos tokens en los estados destino de la misma. La gura 2.31, extraída
de los estudios originales de Kumar y Spaord [390], describe de forma gráca un escenario de
validación de intentos de acceso a un sistema Unix.
Sin embargo, a pesar de la mayor potencia de representatividad de las Redes de Petri, la
solución propuesta en el proyecto IDIOT, dada la complejidad administrativa que requiere la
elaboración de redes que aprovechen todo el potencial del modelo general, no hace uso de toda
la capacidad semántica que tiene a su disposición (sobre todo en lo relativo a la mencionada
especicación de concurrencia) [391], por lo que es posible construir un modelo equivalente ba25
IDIOT: Intrusión Detection In Our Time. Los autores deseaban hacer referencia explícita, no exenta de cierta
ironía, al habitual desfase de tiempo que existe desde que se construye el prototipo experimental hasta que se
lanza el desarrollo del sistema de producción.
85
sado en sistemas expertos. Además, al igual que en los casos anteriores, la calidad de la base
de conocimiento sigue dependiendo de la calidad del conocimiento experto del administrador
humano responsable de la conguración del sistema de detección.
Detección basada en Modelos
Esta técnica fue propuesta por Garvey y Lunt en 1991[383] e introduce el concepto de modelo
de ataque, en combinación con un mecanismo de razonamiento basado en evidencias que tiene
como objetivo la inferencia de conclusiones. Mantiene ciertas similitudes con los métodos basados
en diagramas de transición de estados, los cuales son en este caso denominados modelos, así como
con los métodos basados en probabilidad condicional. De esta forma, la omnipresente base de
conocimiento está compuesta en esta ocasión por un conjunto de modelos, cada uno de los
cuales representa una secuencia de comportamientos constitutivos de un determinado ataque.
Posteriormente, durante la explotación del sistema, a partir de las acciones de cada uno de los
usuarios del mismo, el motor de inferencia va descartando probabilísticamente ciertos modelos, de
forma que el conjunto de los ataques posibles que pueden corresponderse con la situación actual
de dicho sistema se va reduciendo progresivamente. De esta manera, si se da el caso de que
dicho conjunto de modelos potenciales queda vacío, se puede concluir que el comportamiento del
usuario en cuestión es legítimo. Además, este método va más allá del mero análisis estadístico
ya que anticipa, antes de llevar a cabo cada una de las comprobaciones, una selección de los
parámetros de comportamiento a vericar, en base al conjunto de modelos que en un momento
dado aún tiene posibilidades. De esta forma, no sólo se lleva a cabo el análisis pertinente, sino
que se busca continuamente cómo realizar dicho análisis de la forma más eciente posible.
En general, el proceso completo de análisis queda reducido de este modo a dos etapas: Una
primera etapa en la cual se establece un conjunto de hipótesis de comportamiento, y una segunda
en la cual se contrastan dichas hipótesis con la actividad registrada en el histórico de auditoría.
En términos probabilísticos, si se desea obtener una vericación precisa y eciente, la relación
entre las hipótesis de comportamiento y la actividad que realmente se lleva a cabo en el sistema
debe constituir el valor más alto posible [304].
(2 : 3)
P (Actividad/Comportamiento)
P (Actividad/Cualquier otro comportamiento)
Al igual que el caso de los Sistemas de Detección de Intrusiones basados en probabilidad
condicional, el registro histórico de las evidencias que se producen en el sistema permite obtener
un cálculo adaptativo de la probabilidad de los diferentes modelos. A medida que el sistema
evoluciona, algunos de esos modelos ganan peso especíco (se hacen más probables, dados ciertos
comportamientos), mientras que otros pierden relevancia.
De esta forma, es posible obtener una adecuada representación del concepto de certidumbre,
al igual que en el caso de los sistemas basados en probabilidades condicionales, de forma que se
pueden superar ciertas limitaciones inherentes a los sistemas expertos, como pueden ser la pro-
86
pagación de la certidumbre o la aparición de hechos contradictorios. Además, dada su capacidad
para anticipar los parámetros de detección a analizar, si se conguran los distintos modelos de
forma que utilicen progresivamente parámetros cada vez más detallados y complejos, es posible obtener unos requisitos computacionales muy bajos. Así pues, en primer lugar, cuando aún
se tiene un gran conjunto de modelos a vericar, se analizarían parámetros de grano grueso, y
posteriormente, cuando el número de modelos se va haciendo cada vez menor, se irían analizando parámetros con un mayor nivel de detalle. Por supuesto, todas estas consideraciones hacen
que la Detección de Intrusiones basada en Modelos presente unos requisitos de administración
extraordinarios, de forma que en la práctica su utilización es muy escasa.
Por último, es importante prestar especial atención al hecho de que este tipo de sistemas
de detección no sustituyen a los Sistemas de Detección de Intrusiones basados en Detección de
Anomalías, dada la especicación manual de las diferentes relaciones entre los múltiples parámetros que constituyen las colecciones de modelos. Esta técnica debe considerarse solamente como
un complemento a dichos sistemas, como se explica en la obra de Pearl [187].
2.2.2. Detección de Anomalías
La Detección de Anomalías hace referencia al método de Detección de Intrusiones que aboga
por comparar el conocimiento relativo al comportamiento habitual del sistema que se desea
proteger con la actividad cotidiana del mismo. De esta forma, la operatoria del sistema de
detección se basa en la elaboración y mantenimiento de un perl de actividad normal, compuesto
por un conjunto de parámetros o métricas de detección, y en el posterior contraste de dicho
perl con las acciones que se estén llevando a cabo en un momento dado. Toda acción que se
desvíe signicativamente del perl habitual será inmediatamente catalogada como subversiva y
provocará las acciones de respuesta correspondientes.
De esta manera, dado que la principal fuente de conocimiento del sistema de detección es
la realidad cotidiana del sistema a proteger, y no el conocimiento experto proveniente del administrador humano, es posible responder ante situaciones para las cuales no existe un modelo
de ataque conocido y documentado dentro de la base de conocimiento, con lo que se consigue
superar ampliamente las limitaciones características de los sistemas de detección basados en Detección de Usos Indebidos. No se utiliza la política de lista negra inherente a estos sistemas, sino
que se opta por una política de lista blanca construida a partir de la observación minuciosa del
sistema objetivo; de forma que es posible responder ante los Zero-Day Attacks mencionados en
apartados anteriores, no en base a lo que se conoce como malicioso, sino a partir de lo que se sabe
que es legítimo, o normal26 . En general, estas características propias de los sistemas de detección basados en Detección de Anomalías hacen que dichos sistemas sean calicados de completos
[100], si bien adolecen de cierta falta de precisión que da origen habitualmente a mayores tasas
26
Este modo de operación corresponde al modelo general de funcionamiento, si bien existen algunas propuestas
que abogan por la utilización de conocimiento experto positivo para especicar cómo debe ser el comportamiento
del sistema [213].
87
Figura 2.29: Modelo general de Detección de Anomalías
de falsos positivos.
De esta forma, con el objetivo de proporcionar una visión general sobre el funcionamiento
interno de este tipo de sistemas de detección, que permita extraer las conclusiones necesarias
para identicar las problemáticas existentes y enunciar los grandes retos que aún presenta esta
tecnología, se describen a continuación los principios básicos de funcionamiento sobre los cuales
está construida la inmensa mayoría de ellos.
Modelos estadísticos
Dorothy Denning describió en su histórico artículo An Intrusion Detection Model[105] cinco
modelos estadísticos en base a los cuales es posible categorizar los diferentes parámetros o métricas de detección que alimentan actualmente a la práctica totalidad de Sistemas de Detección de
Intrusiones basados en Detección de Anomalías. En concreto, el objetivo fundamental del estudio
desarrollado por Denning consistía en, dado un parámetro x y una secuencia de n observaciones
x1 , ..., xn , determinar si una nueva observación xn+1 es normal respecto del conjunto de observaciones previas o si, por el contrario, se desvía de forma signicativa de las mismas. Para ello,
Denning propone los modelos estadísticos que se describen a continuación, algunos de los cuales
fueron posteriormente incorporados dentro del proyecto IDES [237, 396].
Modelo Operacional
88
Este modelo está basado en la hipótesis de que la normalidad de los parámetros que componen
un determinado evento puede decidirse mediante la comparación de los mismos con un conjunto
de valores límite que se establecen manualmente en base al histórico de evidencias. De esta forma,
aunque las observaciones anteriores no se usan directamente en la decisión, sirven para establecer
esos límites particulares de las diferentes métricas de detección. A este respecto, el ejemplo de
modelo operacional por antonomasia es el de un contador de intentos de login por unidad de
tiempo, a partir del cual una observación por encima del límite habitual sugiere la existencia de
un intento intrusión.
Modelo basado en media y desviación típica
Este modelo pretende generalizar el modelo operacional, aportando una mayor capacidad representativa que se consigue a partir de los conceptos estadísticos clásicos de media, varianza y
desviación típica [155]. Para ello, el presente modelo se basa en la hipótesis de que los valores
más representativos del conjunto de las n observaciones pasadas son precisamente la media y la
desviación típica, las cuales se calculan mediante las expresiones siguientes:
(2 : 4)
Sumatorio = x1 + ... + xn
Sumatorio de cuadrados = x21 + ... + x2n
(2 : 5)
(2 : 6)
(2 : 7)
M edia =
V arianza =
Sumatorio
n
Sumatorio de cuadrados
− M edia2
(n − 1)
√
(2 : 8)
Desviacion tipica =
V arianza
De esta forma, una nueva observación es catalogada como anómala si cae fuera de un intervalo
de conanza centrado en el valor de la media y con un margen denido por el administrador
como una fracción k de la desviación típica. La expresión dene formalmente los límites de dicho
intervalo:
(2 : 9)
M edia ± k∆Desviacion tipica
Este modelo puede utilizarse sobre distintos tipos de parámetros, como pueden ser contadores
de eventos, temporizadores, y demás métricas acumulables. Además, presenta dos grandes ventajas con respecto al modelo anterior, ya que, por un lado, no necesita conocimiento acumulado
sobre la actividad del sistema para denir los diferentes límites. Por el contrario, el propio modelo
es capaz de aprender por sí mismo qué valores constituyen la actividad normal del sistema, y
89
en qué intervalos de conanza debe ubicarse el comportamiento de los usuarios. Además, por
otro lado, como los intervalos de conanza pueden construirse de forma especíca para cada uno
de los usuarios, el modelo soporta aquellas circunstancias en las que lo que es normal para un
determinado usuario sea anómalo para otro. Por último, con el objetivo de minimizar las posibilidades de sufrir Session Creeping, es posible plantear una variante de este modelo que penalice
progresivamente las observaciones más antiguas, en benecio de las más recientes.
Modelo Multivariable
Este modelo pretende generalizar el modelo basado en media y desviación típica, analizando las
potenciales correlaciones existentes entre dos o más métricas. Esta losofía está basada en la
hipótesis de que es posible obtener una mayor capacidad de discriminación a partir de combinaciones de múltiples parámetros de detección, que a partir de métricas individuales. De esta
forma, por ejemplo, la decisión de clasicar el comportamiento de un determinado usuario, se
realizaría en base al análisis conjunto de una colección de métricas como pueden ser tiempo de
procesador consumido, número de procesos en ejecución, número de operaciones de entrada-salida
solicitadas, frecuencia de acceso al sistema, duración de la sesión de usuario, etcétera, etcétera.
A este respecto, es interesante señalar el hecho de que uno de los mecanismos matemáticos de
análisis multivariable más poderosos son precisamente las Redes Bayesianas [187], mencionadas
anteriormente, y en base a las cuales se ha desarrollado el presente trabajo de investigación.
Modelo basado en Cadenas de Markov
Este modelo pretende complementar a los modelos anteriores, introduciendo el concepto de estado
en el proceso de análisis. Los distintos tipos de análisis descritos hasta el momento toman sus
decisiones sin tener en consideración las múltiples circunstancias por las que ha podido pasar el
sistema que se pretende proteger, por lo que su capacidad de representación se encuentra limitada.
Por el contrario, en este caso, se propone la utilización de un mecanismo matemático orientado
precisamente a resolver este problema de falta de memoria, y que es conocido habitualmente
como Cadena de Markov.
Para ello, este modelo considera no sólo el evento que acaba de producirse en este instante en
el sistema, sino también el que se produjo en el instante anterior. De esta forma, internamente,
se construye una matriz de estado que caracteriza las frecuencias de transición entre los múltiples estados por los que puede pasar el sistema a lo largo de su ciclo de vida (en lugar de las
frecuencias individuales de cada estado, como es característico de los casos anteriores). Así pues,
una determinada observación es categorizada como anómala si su probabilidad de ocurrencia,
dado el estado anterior, es demasiado baja.
Por otro lado, es interesante señalar la posibilidad de que este tipo de análisis puede generalizarse aún más, con el objetivo de tomar en consideración no ya el estado inmediatamente
anterior, sino un conjunto de n estados anteriores, mediante la utilización de Cadenas de Markov
Generalizadas [90].
90
Por último, es importante prestar especial atención al hecho de que este tipo de análisis,
que constituye un subconjunto semántico de las anteriormente mencionadas Redes Bayesianas
[73, 206, 57, 115, 63, 291], también se incorpora, de forma implícita, a la solución propuesta en
el presente estudio.
Modelo Temporal
Este último modelo pretende complementar las propuestas anteriores, analizando, además del
orden en que se producen los eventos en el sistema (tal y como es característico del caso anterior),
la longitud de los intervalos de tiempo existentes entre dichos eventos. Básicamente, se reduce
a la aplicación del modelo basado en media y desviación típica a una métrica especial que no
es más que el intervalo de tiempo transcurrido entre un determinado evento y el anterior. De
esta manera, una determinada observación será clasicada como anómala si su probabilidad de
ocurrir en ese preciso instante es demasiado baja. Este tipo de análisis presenta la ventaja de ser
capaz de estimar tendencias de comportamiento a lo largo del tiempo, lo que le permite detectar
cambios graduales en dicho comportamiento y adaptarse a la nueva realidad del sistema que se
pretende proteger. También esta cuestión es tomada en consideración en el presente trabajo de
investigación, con lo que el exhaustivo modelo estadístico de Denning es abordado en toda su
extensión.
Detección de Umbral
La detección de umbral constituye la forma más simple de Detección de Anomalías. Por
lo general, el principio básico de funcionamiento consiste en analizar, dentro de un intervalo
de tiempo, una determinada métrica de detección, como puede ser, por ejemplo, el número de
intentos de conexión fallidos por unidad de tiempo. Si una vez realizada la observación, dicha
métrica excede un determinado umbral, establecido previamente, se considera dicha observación
como anómala y se dispara la acción de respuesta correspondiente [297]. Un Sistema de Detección
de Intrusiones que goza de gran popularidad y que utiliza esta técnica es Tripwire [174, 357, 389].
Este tipo de detección se corresponde fundamentalmente con el modelo operacional propuesto
por Denning.
Detección basada en Perles
La detección basada en perles pretende generalizar el método anterior de detección de umbral, de forma que en lugar de considerarse una única métrica de detección, son analizados perles
compuestos por múltiples parámetros que sirven para obtener una representación más precisa de
la actividad que se lleva a cabo en el sistema. La siguiente tabla incluye algunas de las métricas
utilizadas por el sistema IDES [396, 237].
91
Cuadro 2.3: Métricas utilizadas en el sistema IDES de Detección de Intrusiones basada en perles
De esta forma, la combinación de este conjunto de métricas para un determinado usuario,
constituye en cada momento un perl actual de comportamiento, que es comparado periódicamente con un perl almacenado que contiene los múltiples valores umbrales de dicho conjunto
de métricas. Si se produce una situación en la que el perl actual se desvía signicativamente del
almacenado, se considera dicho perl actual como anómalo y se genera la respuesta pertinente
[297]. En algunos sistemas de detección, además, el mencionado perl almacenado se actualiza
regularmente con los datos contenidos en el perl actual, con lo que se consigue la adaptación
automática a potenciales cambios en el comportamiento de los usuarios [304]. Esta modalidad de
detección se corresponde fundamentalmente con el modelo operacional propuesto por Denning, si
bien, en función del tipo de comparación que se implemente internamente, puede presentar además ciertas peculiaridades propias del modelo basado en media y desviación típica, del modelo
multivariable, y del modelo temporal.
Métricas Estadísticas
En la línea del modelo operacional, del modelo basado en media y desviación típica, del
modelo multivariable y del modelo temporal propuestos por Denning, la detección basada en
métricas estadísticas aboga por el análisis conjunto de los distintos parámetros de detección en
base a una expresión heurística compuesta que combine las distintas componentes de anomalía
posibles. Sobre este principio básico de funcionamiento está basado, por ejemplo, el sistema de
detección NIDES [19], en el cual se utilizan además los conceptos anteriormente mencionados de
perl actual y perl almacenado. En concreto, el perl almacenado que se utiliza está compuesto,
en general, por un conjunto de i métricas s1...si , mientras que el perl actual está compuesto
por i observaciones c1...ci. Por otro lado, los valores de anormalidad o anomalía ai se obtienen
como la diferencia en valor absoluto entre ambos perles, de forma que se obtiene un conjunto
de valores a1...ai, para los que ai=|si - ci|. Además, no es habitual que todas las métricas tengan
la misma relevancia, de forma que es necesario añadir un peso especíco wi a cada métrica. Por
92
último, tampoco es habitual que todos los valores de anomalía tengan la misma repercusión en la
decisión nal. Las anomalías importantes deben tener una mayor relevancia que otras anomalías
menores, por lo que es necesario considerar dichos valores al cuadrado, por lo menos [297, 304].
Todas estas consideraciones sirven para construir la expresión 2.10, la cual constituye el núcleo
fundamental del mencionado proyecto NIDES.
(2 : 10)
Anomalia = w1 a21 + w2 a22 + ... + wi a2i , ∀i > 0
De esta forma, cualquier evento que produzca un valor de anomalía por encima de un determinado umbral, establecido de antemano, será considerado como anómalo y suscitará la respuesta
correspondiente por parte del sistema de detección. En general, este tipo de sistemas de detección (al igual que el caso anterior, de detección basada en perles) permite advertir utilizaciones
anómalas de los recursos computacionales del sistema que se desea proteger de forma ecaz, si
bien presenta ciertos inconvenientes de importancia, como pueden ser su incapacidad para representar información temporal (al igual que el caso de la Detección de Usos Indebidos basada en
sistemas expertos), la posibilidad de sufrir ataques de Session Creeping, y su falta de precisión
en entornos en los que el comportamiento de los usuarios es ligeramente errático o voluble[93].
Sistemas basados en Reglas
La Detección de Anomalías basada en sistemas de reglas pretende aportar una mayor capacidad semántica a los modelos anteriores. Mientras los sistemas de detección basados en métricas
estadísticas resuelven el problema de la comparación de perles mediante formulación matemática, sus homólogos basados en sistemas de reglas proponen, como se describe en apartados
anteriores, la utilización de un motor de inferencia responsable de interpretar baterías de reglas
que formalizan conocimiento experto. De esta forma, dado que los mencionados sistemas basados
en reglas presentan un mayor poder expresivo [297], se pretende mediante su utilización la resolución de algunos de los problemas inherentes a dichos modelos anteriores, como son el modelado
explícito de información temporal, y la adaptación del sistema de detección al comportamiento
anárquico de algunas tipologías de usuarios.
Un sistema de Detección de Anomalías basado en sistemas de reglas es ADS27 [380]. Dicho
sistema de detección está orientado a la máquina y es capaz de analizar información del Sistema
Operativo proveniente de los niveles de servicio, o de llamada al sistema, y de interpretación de
comandos. Para ello, es necesario especicar conjuntos de reglas que representan el comportamiento de cada uno de los usuarios del sistema, incluyendo métricas como el tipo de llamadas al
sistema permitidas, número de solicitudes de servicio realizadas, etcétera, etcétera. Una vez elaborado ese perl de comportamiento, durante la explotación del sistema de detección, cualquier
actividad que sobrepase los límites establecidos en el mismo será considerada como anómala por
el motor de inferencia, y se ejecutarán las acciones de respuesta correspondientes.
27
ADS: Anomaly Detection System.
93
Figura 2.30: Batería de reglas de TIM
En general, esta técnica está basada en la hipótesis de que las secuencias de eventos no se
producen aleatoriamente, sino que por el contrario siguen patrones regulares e identicables28 .
Por ello, un objetivo fundamental que se aborda es el del análisis de anomalías en la ordenación de
eventos, lo que hace que la Detección de Intrusiones adquiera una mayor calidad. Otros ejemplos
de sistemas de detección que utilizan esta técnica son Wisdom and Sense29 [395] y TIM30 [353].
La gura superior ilustra de forma conceptual el funcionamiento de una batería de reglas de
TIM, inferida a partir de la observación de una secuencia de eventos registrada en el sistema
a proteger. A pesar de lo particular de su enfoque, su mecanismo de inferencia es muy similar
a las anteriormente mencionadas Cadenas de Markov, por lo se ajusta extraordinariamente al
modelo de detección basado en Cadenas de Markov propuesto por Denning. Por su parte, la
gura siguiente ilustra un caso de ejemplo de estructura de reglas de decisión de Wisdom and
Sense, de similar capacidad representativa.
Redes Neuronales
Dado que el objetivo fundamental de todo Sistema de Detección de Intrusiones basado en
Detección de Anomalías consiste en deducir, a partir de un conjunto de x1 ...xn observaciones,
el grado de normalidad del evento xn + 1[105], la aplicación del mecanismo matemático de
aprendizaje e inferencia conocido como Red Neuronal [MacKay02] se revela como una opción
natural, con prometedoras posibilidades [386, 275]. En concreto, el objetivo fundamental que
se persigue con este enfoque es el de representar todo el conocimiento relativo a los perles de
comportamiento de los usuarios de una forma implícita al mecanismo de inferencia, y no mediante
los habituales esquemas explícitos inherentes a las aproximaciones basadas en perles, métricas
estadísticas o sistemas expertos. De esta forma, se enriquece, potencialmente, el conocimiento
28
Esta técnica también es conocida habitualmente como Generación de patrones predictivos o Predictive Pattern
Generation [304].
29
30
Wisdom and Sense: Sabiduría y Sensibilidad.
TIM: Time-based Inductive Machine.
94
Figura 2.31: Árbol de reglas de Wisdom and Sense
relativo a las múltiples relaciones existentes entre los diferentes parámetros de detección, con lo
que la calidad de las decisiones inferidas es teóricamente superior [297, 304].
Para ello, se organiza un esquema de funcionamiento compuesto por dos fases: aprendizaje,
o entrenamiento, y explotación. De esta manera, en primer lugar se entrena la red neuronal
con un histórico de la actividad de que se ha registrado en el pasado, el cual, además de las
métricas propias del perl de comportamiento, debe incluir un parámetro de detección adicional
que representa la clasicación de dicha actividad. Dicho parámetro de clasicación representa
el hecho de si la actividad analizada ha supuesto un ataque (y en caso armativo, el tipo de
ataque) o no contra la seguridad del sistema, de forma que su nalidad última no es otra que la
de etiquetar el conocimiento disponible para así proporcionar a la posterior fase de explotación
conciencia sobre el hecho clasicatorio.
Posteriormente, una vez que la red neuronal ha sido entrenada convenientemente, tanto el
conjunto de los múltiples perles de comportamiento, como sus métricas componentes, quedan
representados implícitamente y de forma unicada en las múltiples conexiones neuronales que
componen la citada red. De esta manera, la red en cuestión puede ser nalmente utilizada para
obtener conclusiones acerca del tipo de categorización que debe aplicarse a las nuevas observaciones que se registren en el sistema. Si los parámetros de detección que componen un determinado
evento mantienen cierta similitud con los recogidos por la red neuronal, dicho evento será considerado anómalo y el sistema de detección responderá en consecuencia. De esta forma, estos
sistemas de detección presentan poderosas posibilidades: son capaces de adaptarse por sí mismos
95
Figura 2.32: Aplicación de redes neuronales a Detección de Intrusiones
a sistemas computacionales cuya realidad evoluciona a lo largo del tiempo, mantienen una alta
estabilidad del conocimiento asimilado (incluso en situaciones sujetas a la inuencia de componentes de ruido), son capaces de inferir conclusiones de alto nivel de abstracción, sin necesidad
de hipótesis estadísticas previas, y además son muy ecientes, una vez puestos en explotación.
Sin embargo, la utilización de redes neuronales introduce un serio inconveniente en lo relativo a la inferencia de relaciones de tipo causa-efecto, ya que dentro de su naturaleza existe
una absoluta incapacidad de explicación de las conclusiones que ofrecen. La suma de sus múltiples conexiones, una vez entrenadas adecuadamente, proporciona unos resultados precisos y
de conanza, pero es imposible determinar cuáles son las causas exactas que producen dichos
resultados[57]. Por otro lado, la mencionada fase de aprendizaje requiere por lo general unos
costosos esfuerzos administrativos de supervisión, que hacen que, por lo general, este tipo de
sistemas de detección vea reducida su aplicación a condiciones de laboratorio. Algunos casos de
Sistemas de Detección de Intrusiones desarrollados en base a redes neuronales son los prototipos
correspondientes a los estudios realizados por Ángel Grediaga31 et al. [149], Anup Gosh32 et al.
[148], James Cannady y Jim Mahaey [54], David Endler , y Jake Ryan y Meng-Jang Lin [382].
A pesar de tratarse de un enfoque especialmente particular, puede clasicarse de una forma intuitiva dentro del modelo multivariable de Denning. La gura anterior ilustra un caso de red
neuronal utilizada para predicción de comandos en sistemas Unix [Fox+90].
31
En las investigaciones realizadas por Grediaga et al. y Cannady y Mahaey se utiliza un tipo especial de red
neuronal denominado Mapa Auto-Organizativo [338], que presenta la característica de que su fase de entrenamiento
puede realizarse de forma no supervisada. Ésta es una propiedad fundamental para conseguir unos requisitos
administrativos mínimos, que permitan una adopción natural del Sistema de Detección de Intrusiones resultante
por parte de empresas y organizaciones.
32
En las investigaciones realizadas por Gosh et al. se utiliza un tipo especial de red neuronal denominado
Red de Elman [122], que presenta la característica de que ser capaz de representar implícitamente la magnitud
temporal. Ésta es una propiedad fundamental para poder construir un modelo de representación y unos motores
de aprendizaje e inferencia que tomen en consideración de forma intrínseca el hecho cronológico.
96
Figura 2.33: Firma ISL de NFR
Lenguajes de Especicicación de Intenciones
Un método que aboga por la especicación apriorística del comportamiento de los usuarios
del sistema, es la utilización de lenguajes interpretados a través de los cuales especicar dicho
comportamiento33 . De esta forma, es posible la vericación en tiempo real del grado de desviación que está sufriendo el comportamiento actual de un determinado usuario, con respecto a su
comportamiento ideal, especicado mediante uno de dichos lenguajes. Éste es un método que,
además de permitir la especicación de comportamiento legítimo, también puede utilizarse para
representar conocimiento experto sobre comportamientos maliciosos de los que el administrador
humano tenga constancia, debido al alto grado de capacidad expresiva que presenta.
Algunos casos de éxito de Sistemas de Detección de Intrusiones que utilizan esta técnica son
IDML34 [230], NFR o Stalker[307]. En todos ellos, se utilizan lenguajes de especicación expresamente desarrollados para cada caso, si bien también existen soluciones de detección que utilizan
lenguajes de propósito general de construcción de sistemas expertos, aplicados a la especicación
de escenarios de Detección de Intrusiones, como pueden ser P-BEST35 o CLIPS36 [299]. Las guras siguientes ilustran dos casos de representación de conocimiento de Detección de Intrusiones
propios de NFR y P-BEST/EMERALD, respectivamente.
Por último, también es interesante prestar atención, respecto a la utilización de lenguajes de
especicación de intenciones, a los ambiciosos estudios realizados por Jon Doyle et al.[112] en el
Instituto Tecnológico de Massachusetts [251]. La gura 2.38 muestra un ejemplo de especicación de escenario de intrusión en un servidor de transferencia de cheros escrito en el lenguaje
propuesto en dicho trabajo de investigación.
Clasicación Bayesiana
Los métodos de clasicación Bayesiana [187] están basados en los conceptos clásicos de Teoría
de la Probabilidad de probabilidad conjunta [155] y probabilidad condicional, y se caracterizan
fundamentalmente por conseguir la clasicación no supervisada de objetos. Esta propiedad de
la no supervisión permite que estos métodos de análisis presenten unos requisitos administrativos mínimos y que los hacen especialmente atractivos, ya que elimina la necesidad de que sus
33
34
35
36
Conocidos como lenguajes de especicación de intenciones o Intent Specication Languajes o ISL [297].
IDML: Intrusion Detection Markup Languaje.
Utilizado dentro del proyecto EMERALD, entre otros.
Utilizado dentro de los proyectos CLIPSNIDS y DIDS, entre otros.
97
Figura 2.34: Batería de reglas ISL de P-BEST/EMERALD
Figura 2.35: Firma ISL del MIT
98
inherentes procesos de aprendizaje deban ser administrados por el operador humano, como es
menester, por ejemplo, en los casos de los métodos de detección de umbral, o en los basados en
perles, en métricas estadísticas, en sistemas de reglas, o en redes neuronales [304].
Figura 2.36: Red Bayesiana trivial de modelado de actividad intrusiva
De este modo se consigue una adaptación natural e instantánea a la evolución a lo largo del
tiempo de los sistemas que se pretende proteger, ya que es posible mantener, en paralelo con
los procesos de inferencia y decisión, perennes procesos de aprendizaje automático. Además, un
sistema de clasicación Bayesiano permite la identicación automática del número de categorías
de clasicación, dado el conjunto de datos a clasicar126, permite operar en base a datos incompletos, permite el análisis unicado de parámetros, sin los habituales criterios y restricciones de
excepción presentes en la mayoría de sistemas de detección, e incluso soporta el análisis homogéneo de parámetros discretos y continuos; parámetros que, además, pueden ser tanto cuantitativos
como temporales [376].
Sin embargo, a pesar de sus enormes posibilidades, también presenta ligeros inconvenientes.
Por un lado, estos métodos aún presentan cierta dicultad para denir los umbrales de detección
más adecuados; tarea que sigue siendo responsabilidad del administrador de seguridad. Por otro
lado, como es característico de cualquier sistema de adaptación automática al sistema objetivo,
presentan la teórica posibilidad de sufrir ataques de Session Creeping [57]. Algunas propuestas
de Sistemas de Detección de Intrusiones que utilizan métodos de clasicación Bayesianos son
los proyectos SPAMBayes [399], ADAM37 [32] y eBayes38 [Valdés+01], así como los estudios
realizados por Steven Scott [305] , Nasser Abouzakhar et al. [13], Christopher Krügel et al. [215],
Burroughs et al. [47], y Nong Ye y Mingming Xu [244]. La gura anterior ilustra un sistema de
clasicación bayesiano utilizado para Detección de Intrusiones orientada a la máquina [304].
Algoritmos Genéticos
Los denominados Algoritmos Genéticos [82] constituyen una técnica de búsqueda y optimización, perteneciente al área de conocimiento de los denominados Algoritmos Evolutivos [121],
37
38
ADAM: Audit Data Analysis and Mining.
Proyecto desarrollado por SRI International, como elemento componente del proyecto EMERALD.
99
Figura 2.37: Algoritmo Genético general, en pseudocódigo
que también ha sido propuesta dentro del área de conocimiento de la Detección de Anomalías,
en concreto como componente fundamental del motor de análisis del proyecto GASSATA39 [219],
desarrollado por Ludovic Mé. En general, este tipo de métodos están basados en la mecánica
de la Genética y de la Selección Natural [303]. De esta forma, el proceso de búsqueda u optimización se organiza en base a los principios genéticos clásicos de herencia, mutación, selección y
recombinación, para a partir de cromosomas, formados por vectores de parámetros de detección,
dar origen a un conjunto de generaciones sucesivas cuyos últimos miembros se ajusten perfectamente al problema propuesto. Al nalizar dicho proceso evolutivo, sólo habrán sobrevivido los
más fuertes.
De este modo, los resultados obtenidos por Mé fueron realmente prometedores, presentando
una tasa de acierto del 0,996 y una tasa de falsos positivos del 0,0044. Además, el tiempo necesario
para obtener dicha solución fue mínimo, por lo que la sobrecarga introducida en el sistema se
mantuvo en unos niveles realmente bajos. Otros estudios interesantes desarrollados en esta línea
pueden ser los llevados a cabo por Dong Kim et al. [211], por Wei Li[368], por el grupo de
investigación de Jan Elo [280], por Susan Bridges y Rayford Vaughn [40], por Sinclair et al.
[320], y por Mark Crosbie y Gene Spaord [76].
Lógica Difusa
La denominada Lógica Difusa40 [75] es una extensión de la Lógica de Boole [361] que se
caracteriza por ser capaz de representar el concepto de certidumbre, o grado de veracidad, aproximándose de esa forma al concepto idóneo de Probabilidad [57, 115]. De este modo, mientras
la lógica clásica utiliza únicamente los conceptos absolutos de verdadero o falso, la lógica difusa utiliza múltiples niveles o grados de veracidad, proporcionando de esa manera una mayor
aproximación al razonamiento humano. Por ejemplo, un Sistema de Detección de Intrusiones
basado en lógica difusa puede representar el concepto muy peligroso. Por ello, es posible que un
determinado evento sea clasicado como perteneciente (con diferentes grados de pertenencia) a
más de una clase simultáneamente. La gura siguiente ilustra de forma conceptual la diferencia
entre ambos enfoques utilizando para ello una única métrica de detección como es el número de
puertos TCP-IP accedidos por unidad de tiempo [41].
39
40
GASSATA: A Genetic Algorithm as an Alternative Tool for Security Audit Trails Analysis.
Lógica Difusa o Fuzzy Logic.
100
Figura 2.38: Clasicaciones convencional y difusa de un parámetro de detección
Por otro lado, es interesante tomar el consideración el hecho de que esta tecnología es susceptible de ser utilizada por sí sola, como elemento fundamental del proceso de Análisis, o bien de
usarse como complemento a otras técnicas de detección, como es el caso del proyecto IIDS41 , desarrollado en la Universidad de Mississippi por [41, 40]. Otras Susan Bridges y Rayford Vaughn42
investigaciones desarrolladas al respecto son las llevadas a cabo por John Dickerson et al. en
el proyecto FIRE43 [106, 107], así como los estudios realizados por Chavan et al. [64], Jonatan
Gómez y Dipankar Dasgupta[377], y Jianxiong Luo [183].
Máquinas de Vector Soporte
Las denominadas Máquinas de Vector Soporte44 [365] constituyen un método no lineal basado
en optimización cuadrática [150, 394] de aprendizaje supervisado dirigido a la resolución de
problemas de clasicación y regresión. Por lo tanto, el objetivo principal de dichos métodos ante
el problema de la Detección de Intrusiones se reduce a clasicar la actividad de los usuarios, en
principio en las dos grandes categorías canónicas: Maldad y Bondad. Este modo de operación
es similar a los que caracterizan a otros enfoques, como pueden ser las redes neuronales o los
clasicadores bayesianos, de forma que su aportación conceptual es limitada. Por otro lado, la
propia denición del término incluye una premisa, como es el hecho del aprendizaje supervisado,
que en general supone un importante obstáculo para la eciente utilización de un hipotético
Sistema de Detección de Intrusiones que resultara de la aplicación de las referidas máquinas de
vector soporte.
Otros métodos, como pueden ser las Redes Bayesianas, permiten operar de forma ecaz
sin dicha supervisión del entrenamiento [57, 115], de forma que los costes de administración
correspondientes se mantengan dentro de unos límites de adecuada eciencia económica. Algunas
41
42
IIDS: Intelligent Intrusion Detection System.
En el desarrollo de este proyecto, Bridges y Vaughn utilizaron Lógica Difusa combinada con Algoritmos
Genéticos.
43
44
FIRE: Fuzzy Intrusion Recognition Engine.
Máquinas de Vector Soporte o Support Vector Machines [SVM].
101
Figura 2.39: Clasicación de eventos basada en máquina de vector soporte
investigaciones en las que se han aplicado los principios fundamentales de dichas máquinas de
vector soporte son las llevadas a cabo por Crina Groçan et al. [150], por Srinivas Mukkamala y
Andrew Sung [394, 256], por Zonghua Zhang y Hong Shen [156], por Heller et al. [162], y por Hu
et al. [167]. La gura ilustra de forma conceptual el mecanismo de clasicación característico de
las máquinas de vector soporte [167].
Data Mining
El denominado Data Mining45 [349, 158], también conocido como Knowledge Discovery in
Databases46 , es una técnica de búsqueda automática de patrones o pautas regulares de conocimiento en ingentes volúmenes de información, para la cual se utilizan fundamentalmente técnicas
estadísticas y de reconocimiento de patrones. De este modo, la esencia última de dicha aproximación no diere sustancialmente de otras alternativas propuestas anteriormente, salvo por su
orientación no supervisada y por los grandes requerimientos de eciencia que presenta. De esta
forma, se pretende dar un paso adelante en la tecnología estadística clásica mediante la automatización del proceso de extracción de conocimiento.
Por otro lado, aunque los problemas especícos a los que puede enfrentarse el Data Mining
son múltiples, son tres los que predominan habitualmente, ya que proporcionan un conocimiento
de mayor calidad: Clasicación, Análisis Multivariable de Relaciones y Análisis de Secuencia
[229]. A continuación se describen someramente las mencionadas problemáticas:
Clasicación
El objetivo fundamental del problema de clasicación consiste en asignar una categoría a cada
uno de los hechos de la base de datos. Por otro lado, puede darse la circunstancia de que el
conjunto de categorías esté denido de antemano, o que deba ser inferido a partir de los datos.
45
46
Data Mining o Minería de Datos.
Knowledge Discovery in Databases (KDD) o Descubrimiento de Conocimiento en Bases de Datos.
102
A este respecto, las Redes Bayesianas en general, y las Redes Bayesianas de tipo Naïve en
particular, constituyen el paradigma por excelencia de clasicación automática a partir de los
datos [57, 115].
Análisis Multivariable de Relaciones
En este caso el problema consiste en identicar las relaciones de correlación y causalidad existentes entre las múltiples variables que componen cada uno de los hechos de la base de datos,
mediante la aplicación de tests estadísticos de independencia e independencia condicional. Al
igual que en el caso anterior, las Redes Bayesianas suponen un método excepcional para la resolución de dicho problema [57, 115]. Por otro lado, es interesante prestar atención a la absoluta
correspondencia existente entre este aspecto del Data Mining y el modelo multivariable propuesto
por Denning.
Análisis de Secuencia
En esta ocasión el problema consiste en identicar las relaciones de correlación y causalidad existentes entre los múltiples estados por los que pueden pasar las secuencias de eventos que tienen
origen en un determinado sistema de información. En este caso, los denominados Modelos de
Markov constituyen una excelente aproximación, si bien están superados por las anteriormente
mencionadas Redes Bayesianas, las cuales, aunque presentan unos mayores requisitos computacionales, proporcionan una mayor capacidad de representación [57, 115], imprescindible para
la resolución de problemas complejos. Al igual que el caso anterior, es interesante prestar atención a la absoluta correspondencia existente entre esta cuestión y el modelo basado en Cadenas
de Markov propuesto por Denning.
Son abundantes las investigaciones realizadas en el campo de la Detección de Intrusiones que
aplican técnicas de Data Mining. Algunas de las más representativas son las llevadas a cabo
por Guy Helmer et al. [163], por el equipo de investigación de la Universidad de Minnesota
[227, 110], por Wenke Lee y Salvatore Stolfo47 [228, 229, 393], de la Universidad de Columbia, y
por Christina Warrender et al. [374].
Selección de parámetros de detección
Al vasto abanico de posibilidades de análisis descrito en los apartados anteriores es necesario
añadir la cuestión fundamental de la formalización de la información que entra a dicho proceso
de análisis, en la línea del modelo conceptual propuesto por Emilie Lundin [116]. De esta forma,
una cuestión tan importante como la selección del modelo de análisis es la selección de aquellas
métricas o parámetros de detección a partir de los cuales debe desarrollarse éste, de modo que
la diferenciación entre la actividad anómala y la actividad legítima que se registre en el sistema
47
Lee y Stolfo utilizan un enfoque de inducción de reglas a partir de los datos muy similar al utilizado en el
proyecto TIM.
103
a proteger pueda llevarse a cabo de manera eciente. Para ello, es necesario seleccionar, de entre
la amplia colección de métricas que pueden estar a disposición del sistema de detección (en las
múltiples y variadas circunstancias propias de cada tipo de sistema), aquel subconjunto de ellas
que resuelva de forma precisa y eciente el problema.
Esta cuestión se denomina habitualmente Selección de parámetros de detección, y adquiere
una complejidad adicional debido a que, por lo general, distintos tipos de ataque requieren
la utilización de distintos tipos de métrica. Por ello, un determinado subconjunto limitado de
parámetros no suele ser adecuado para representar cualquier tipo de ataque, y además, por otro
lado, un conjunto excesivamente elevado de parámetros no consigue, en general, buenos niveles
de rendimiento. De esta forma, la solución pasa por alcanzar el equilibrio entre una adecuada
capacidad representativa y una eciencia satisfactoria, mediante la selección dinámica de dichos
parámetros de detección [304].
A este respecto, Heady et al. [160] proponen en su trabajo de investigación una aproximación
de Sistema de Detección de Intrusiones basada en Algoritmos Genéticos que permite explorar
todo el espacio de métricas posibles, con el objetivo de seleccionar un subconjunto ideal. En ella
se busca, a partir de un conjunto inicial de parámetros de detección y mediante las operaciones
genéticas anteriormente mencionadas de herencia, selección, recombinación y mutación, un proceso de selección natural que obtenga subconjuntos de métricas más fuertes, a partir del grado de
acierto de las predicciones de intrusión que se consiguen en cada una de las generaciones. Aquellas
generaciones que representan mejor el conjunto de ataques de entrenamiento son potenciadas y
resultan seleccionadas a la hora de llevar a cabo nuevas generaciones, en detrimento de aquellas
otras que se encuentran más alejadas del modelo ideal.
Dentro del área de conocimiento de los propuestos Modelos de Redes Probabilísticas, en
general, y en el caso del presente trabajo de investigación, en particular, esta selección se realiza
de forma natural mediante un procedimiento estadístico especialmente interesante, dada su gran
riqueza semántica, denominado Análisis de sensibilidades [57].
Combinación de múltiples métricas
Una vez determinado el conjunto de métricas que mejor es capaz de determinar la presencia
o no de actividad intrusiva en el sistema, es necesario un último esfuerzo de combinación de
todos esos parámetros de detección en una única medida que proporcione unidad al análisis.
Sólo de esta manera es posible obtener una magnitud que represente de forma global y unicada
la verdadera dimensión del riesgo que supone cada uno de los eventos que se analizan en el
sistema de detección. Para ello, dos enfoques de combinación muy extendidos son la utilización de
propiedades estadísticas Bayesianas, bien a partir de la aplicación sus principios fundamentales
o bien mediante el uso de los Modelos de Redes Probabilísticas, y la utilización de Matrices
de Covarianzas [304]. Por otro lado, además de la obtención de magnitudes de unicación de
métricas, estos principios combinatorios pueden generalizarse de forma que sus benecios sean
104
aplicables no ya a múltiples parámetros de detección, sino incluso a múltiples veredictos que
puedan ser generados por diferentes Sistemas de Detección de Intrusiones que cooperen en las
tareas de decisión. En concreto, en el presente trabajo de investigación también se plantea esta
cuestión, la cual se aborda mediante el uso de Redes Bayesianas de tipo Naïve, las cuales están
especícamente orientadas a la resolución de problemas de clasicación [57].
Estadística Bayesiana
Dado un conjunto de métricas A1 , A2 , ..., An utilizadas para determinar la legitimidad de la actividad que se registra en el sistema que se pretende proteger, es posible obtener conclusiones
globales acerca de la realidad de dicho conjunto de métricas, mediante la aplicación de los principios probabilísticos clásicos establecidos alrededor del Teorema de Bayes. Para ello, en primer
lugar, es habitual realizar un proceso de discretización de dichos parámetros de detección, que
por lo general implica la existencia de al menos dos estados48 : Maldad (o anormalidad) y Bondad.
Por otro lado, también es habitual el planteamiento de la hipótesis de que el sistema objetivo
es susceptible de sufrir intentos de intrusión, los cuales podrán, posteriormente, resultar exitosos o no. Dicha hipótesis de intrusión se representa como I y está sujeta a una distribución
de probabilidad P (I). A continuación, a partir de estas consideraciones, es posible calcular la
conabilidad y la sensibilidad de cada una de las métricas de detección Ai mediante las expresiones P (Ai = 1/I ) y P (Ai = 1/ ∼ I ). De esta forma, la probabilidad condicional de I , dado el
conjunto de parámetros Ai , mediante el citado Teorema de Bayes, puede representarse mediante
la expresión:
(2 : 11)
P (I/A1 , A2 , ..., An ) = P (A1 , A2 , ..., An /I)∆
P (I)
P (A1 , A2 , ..., An )
Como puede observarse, es necesario calcular la distribución de probabilidad conjunta del
conjunto de métricas, dada la variable I. Para ello, es necesario tener en especial consideración el
hecho de que el número de probabilidades requerido para representar dicha distribución de probabilidad es exponencial en el número de parámetros [57, 304], lo que puede hacer que el análisis
sea computacionalmente intratable. Por ello, para conseguir que el problema sea abordable en
términos de eciencia, es habitual tomar ciertas hipótesis de independencia condicional, que se
traducen en un exponencialmente menor número de probabilidades necesario. En concreto, por
lo general, se considera que cada uno de los parámetros de detección es independiente de los
demás, condicionalmente dada I . Dichas hipótesis se resumen en las siguientes expresiones, las
cuales resultan en la expresión nal:
(2 : 12)
P (A1 , A2 , ..., An /I) =
π
Y
P (Ai /I)
i=1
48
Por supuesto, en este punto, no es imprescindible que dicha discretización sea binaria, sino que es posible
plantear cualquier tipo de categorización, tanto de los parámetros de detección de entrada, como de los parámetros
de salida obtenidos a partir de éstos.
105
P (A1 , A2 , ..., An / ∼ I) =
(2 : 13)
π
Y
P (Ai / ∼ I)
i=1
(2 : 14)
Qn
P (Ai /I)
P (I/A1 , A2 , ..., An )
P (I)
Qn i=1
=
P (∼ I/A1 , A2 , ..., An )
P (∼ I) i=1 P (Ai / ∼ I)
Así pues, de esta forma, es posible calcular la probabilidad de ocurrencia de una intrusión,
dada una observación o evidencia del conjunto de métricas. Por supuesto, las hipótesis de independencia condicional tomadas pueden no ajustarse completamente a la realidad, por lo que
siempre es necesario contemplar la posibilidad de existencia de relaciones entre los parámetros
de detección, a costa de unos menores rendimientos computacionales.
Matrices de Covarianzas
El proyecto NIDES utiliza un modelo de representación de relaciones estadísticas entre variables
basado en el concepto de Matriz de Covarianza [155]. De esta forma, el conjunto de métricas
A1 , A2 , ..., An se representa como un vector A que permite el cálculo de una medida de anomalía
compuesta, en base a la expresión que se indica a continuación, en la que C es la matriz de
covarianzas que representa la dependencia estadística existente entre cada par de variables de
entrada.
AT C −1 A
(2 : 15)
Dicho modelo de representación es realmente eciente, pero adolece de una importante carencia de capacidad semántica, ya que solamente es capaz de representar relaciones entre parejas
de variables [304]. En ningún caso pueden plantearse conclusiones basadas en múltiples parámetros de detección, por lo que la calidad expresiva de este método se encuentra muy limitada,
máxime teniendo en consideración el hecho de que otros enfoques, entre los cuales se encuentran
las anteriormente mencionadas Redes Bayesianas, soportan perfectamente cualquier requisito de
análisis multivariable [57, 115, 187].
2.2.3. Modelo General de Denning
Además de la propuesta de modelo estadístico de Detección de Anomalías, Dorothy Denning [105] también propuso un Modelo General de Detección de Intrusiones, el cual perseguía
el objetivo de integrar los benecios y potencialidades de los métodos de Detección de Usos
Indebidos y de Detección de Anomalías. Dicho objetivo abstracto de integración evitaba tomar
en consideración cualquier aspecto de bajo nivel, como pudieran ser el tipo de sistema objetivo,
la formalización de datos de entrada, etcétera, lo que ha contribuido notablemente a que los
principios establecidos en dicho modelo general sigan siendo vigentes en los actuales Sistemas de
Detección de Intrusiones. La gura siguiente ilustra el mencionado modelo [304].
106
Figura 2.40: Modelo General de Detección de Intrusiones de Denning
Como puede observarse, los distintos eventos concretos se trasforman en una primera fase en
eventos abstractos, independientes de cuestiones como tipo de plataforma, Sistema Operativo,
protocolo de red, etcétera. Posteriormente, estos eventos son utilizados para alimentar tanto a
un primer motor de análisis basado en perles de comportamiento, denominado Activity Prole,
como a un segundo motor de análisis basado en reconocimiento de patrones, denominado Rule
Set. De esta forma, dicho Activity Prole, por un lado, utiliza el modelo estadístico de Denning
descrito anteriormente para detectar desviaciones signicativas de los perles de comportamiento,
a la vez que es capaz de construir nuevos perles ante la aparición de nuevos usuarios o recursos
en el sistema a proteger. Por su parte, el Rule Set se apoya sobre un sistema basado en reglas,
para detectar comportamientos subversivos conocidos. Además, el Activity Prole es capaz de
formular en forma de reglas del Rule Set toda aquella actividad que identica como anómala, de
forma que a partir de ese momento, será éste último el encargado de detectar nuevas apariciones
de dicha actividad, con el incremento de eciencia que ello conlleva. Por supuesto, ésta es la
propiedad más poderosa del modelo propuesto por Denning, y sobre la cual descansan todos los
esfuerzos de integración de las dos grandes losofías de detección llevados a cabo en sus trabajos
de investigación.
Por otro lado, aunque el presente estudio, desarrollado en el ámbito del proyecto IDES de SRI
International, revela la importancia de la integración de los dos grandes enfoques de Detección
de Intrusiones y constituye aún actualmente un referente de enorme importancia, alcanza dicha
integración mediante la utilización de una única colección de parámetros de detección que es
compartida por los dos motores de análisis. Los datos son la esencia de la integración, pero
la inferencia que se realiza sobre dichos datos es heterogénea y, por lo tanto, sujeta a grandes
limitaciones de expresividad que restringen la calidad de las conclusiones que se obtienen.
No obstante, a este respecto, es posible encontrar modelos de representación, como las Redes
Bayesianas, que aúnan completamente los principios de funcionamiento de dichos grandes enfoques, consiguiendo un modelo de representación unicado y homogéneo por un lado, y un método
107
de obtención de conclusiones que permite tanto el análisis y la toma de decisiones, como el aprendizaje de comportamiento, de una forma también unicada y homogénea, por otro [57, 115, 187].
Respecto a esta cuestión, es interesante observar la completa adecuación de dichas características a la declaración de objetivos general, especícos y operacionales del presente trabajo de
investigación.
2.3. Implicaciones Arquitectónicas en el Análisis
Además de las técnicas de análisis expuestas anteriormente, existe una serie de propuestas
relativas al modelo arquitectónico en base al cual se construye un determinado Sistema de Detección de Intrusiones que introducen ciertas consideraciones importantes en el proceso de análisis.
A continuación se describen las más representativas.
2.3.1. Detección basada en Agentes de Software
Los conceptos de Agente Software, Agente Autónomo y Agente Colaborativo [386], constituyen un enfoque de diseño que persigue dotar de sensibilidad y autosuciencia a los procesos
que implementan la lógica de negocio de cualquier servicio de aplicación tradicional. Además,
también tratan de conseguir el objetivo de la colaboración mediante la distribución lógica de
las cargas de trabajo. De esta forma, un agente software se desarrolla por lo general como un
proceso independiente del sistema, que será gestionado únicamente por el Sistema Operativo, y
que formará parte de una plataforma general dentro de la cual cumple una determinada labor,
monitorizando aquellos eventos que sean de su responsabilidad, analizándolos y actuando en
consecuencia.
El paradigma de sistema de agentes autónomos aplicado al campo de la Detección de Intrusiones es el proyecto AAFID49 [30], desarrollado por el equipo de investigación de Gene Spaord
en la Universidad de Purdue. La gura anterior ilustra un caso de ejemplo de arquitectura AAFID, en la que, como puede observarse, se plantea un estructura jerárquica en base a tres tipos
de componentes fundamentales implementados en forma de agentes autónomos. De esta forma,
cada uno de los agentes AAFID puede ser bien un Agente de campo, bien un Transceptor, o bien
un Monitor.
Por supuesto, cada una de estas categorías tiene asignada una misión concreta. En primer
lugar, los agentes de campo recopilan toda la información proveniente de la máquina que se desea
proteger, en el modo en que se especica en el apartado de formalización. Posteriormente, toda
esa información es enviada al transceptor asignado a cada uno de los agentes, de forma que pueda
encargarse de la coordinación de las operaciones de dichos agentes, así como de la importante
tarea de la Reducción de auditoría, la cual redunda de forma notable en la eciencia del motor
de análisis. A continuación, los resultados de este procesamiento son enviados al monitor corres49
AAFID: Autonomous Agents For Intrusion Detection.
108
Figura 2.41: Modelo General de Detección de Intrusiones de Denning
pondiente, quien tiene la responsabilidad de realizar el análisis propiamente dicho. Por último,
existe una capa de interfaz de usuario que puede aplicarse a cualquiera de los monitores, a través
de los cuales es posible realizar las labores de administración tanto del propio monitor, como de
los transceptores u otros monitores asignados a dicho monitor, como de los agentes de campo
asignados a dichos transceptores.
De esta forma, se consigue un Sistema de Detección de Intrusiones modular, robusto, escalable y extensible. El desarrollo de cada uno de los agentes es más sencillo y, por lo tanto, más
seguro. Por otro lado, el sistema en su conjunto no está sujeto a un único punto de fallo, como es
habitual en sistemas con una orientación más centralizada. Por último, también es posible incorporar nuevos agentes ante el crecimiento del sistema que se pretende proteger, así como añadir
fácilmente nuevas funcionalidades. Todas estas ventajas no pueden pasar desapercibidas, dada la
acelerada evolución a la que están sujetos los actuales sistemas de computación y comunicaciones,
por lo que son tomadas en especial consideración en el presente trabajo de investigación. Otros
estudios realizados en la misma línea más recientemente son los llevados a cabo en la Universidad
de Iowa por Guy Helmer et al. [Helmer+03], en el Instituto Nacional de Estándares [260] por
Wayne Jansen et al. [196], y en la Universidad de Monterrey por Joseph Barrus [33].
109
Figura 2.42: Representación conceptual de GrIDS de una epidemia vírica
2.3.2. Detección basada en Grafos
La enorme capacidad infecciosa de algunas de las actuales amenazas que se ciernen sobre
sistemas de información de todo tipo[332], en combinación con ciertas peculiaridades intrínsecas propias de cada una de ellas, han dado origen a una propuesta de Sistema de Detección
de Intrusiones que propone la identicación de dichas amenazas en función precisamente de características exclusivas de su modo de propagación. Dicha propuesta, denominada GrIDS50 , ha
sido desarrollada por el equipo investigador de Stuart Staniford-Chen [330], de la Universidad
de California Davis, y aborda el problema de la Detección de Intrusiones de esa manera.
En concreto, el sistema GrIDS monitoriza la actividad existente entre las distintas máquinas
conectadas a la red de comunicación del sistema de información que se pretende proteger, y
obtiene patrones de actividad, en forma de grafo, que posteriormente son comparados con los
patrones de propagación de epidemias conocidas que ya se encuentran documentadas. De esta
forma, el objetivo fundamental consiste en detectar estos ataques a gran escala en las primeras
fases de su desarrollo. La gura ilustra de forma conceptual un caso de epidemia vírica representada por GrIDS en forma de grafo. Por un lado, se muestra un primer grafo que representa
la propagación de una amenaza en sus primeros estadios de evolución, y por otro, se muestra un
segundo grafo en el que la citada epidemia ha alcanzado un estado completamente avanzado.
2.3.3. Sistema Inmunológico
Existe una línea conceptual dentro del área de conocimiento de la Detección de Intrusiones
que aboga por aprovechar las similitudes existentes entre un Sistema de Detección de Intrusiones
y el sistema inmunológico de los seres vivos [325]. Para ello, el objetivo fundamental de dicha
línea conceptual no consiste sino en diferenciar con precisión qué elementos de los presentes en
la realidad del sistema a proteger son propios de dicho sistema y cuáles no. A este respecto,
es interesante observar el alto grado de correspondencia de dicho objetivo fundamental con los
50
GrIDS: Graph-based Intrusion Detection System.
110
principios básicos de la Detección de Anomalías. De esta manera, al igual que un organismo
vivo es capaz de reconocer comportamientos extraños propios de antígenos, un sistema de detección inmunológico es capaz de detectar comportamientos anómalos de los usuarios, así como
comportamientos clasicados de antemano como subversivos.
Además, este tipo de sistemas persiguen otra serie de cuestiones que en el caso de los organismos vivos se dan con naturalidad, como pueden ser la orientación completamente distribuida,
la diversidad, la adaptabilidad, la autonomía, la cobertura dinámica, la detección de anomalías,
la identicación de comportamiento, la no existencia de componentes de conanza, o la detección subóptima o imperfecta. Como puede deducirse de manera natural, estas características se
adecuan extraordinariamente al conjunto de retos por alcanzar planteados. No obstante, a pesar
de lo ambicioso de los objetivos planteados y del horizonte de posibilidades que se abre de forma
apriorística ante este enfoque de detección, las investigaciones realizadas hasta el momento no
han conseguido eludir una costosa etapa inicial de aprendizaje supervisado, en la misma línea
que otros enfoques anteriormente descritos.
Por otro lado, a pesar de la supuesta novedad de la estrategia arquitectónica que se plantea, los
métodos de análisis que se utilizan dentro de cada uno de los elementos componentes del sistema
inmune también se corresponden con dichas aproximaciones anteriores, por lo que el nivel de
innovación aportado en lo puramente analítico es limitado. Algunas investigaciones interesantes
sobre el tema son las desarrolladas por Haiyu Hou y Gerry Dozier [378], por Dipankar Dasgupta
y Fabio González [96], y por el equipo de investigación de Steven Hofmeyr .
2.4. Técnicas de Análisis especícas para Host Intrusion Detection Systems (HIDS)
Los Sistemas de Detección de Intrusiones para Sistemas Operativos, o Host, como se vienen
denominando tradicionalmente requieren de datos para poder realizar su labor. Ha pasado
bastante tiempo desde que se empezó a tener ideas sobre cómo facilitar la auditoría de sistemas
en orden de garantizar la seguridad de los mismos. Existen incluso documentos, de hace bastante
tiempo, que arman que sin la capacidad de generar y almacenar información de auditoría, no
se puede considerar un sistema como seguro [279]
La auditoría permite dos puntos de acción fundamentales: el primero y más importante
es que si ha acaecido una violación de la seguridad del sistema, los sucesos que se han ido
produciendo son repetibles; así mismo, como segundo punto se tiene el que se va a poder predecir
el comportamiento de los usuarios y actuar en consideración si se estima un posible ataque en
base al conocimiento anterior.
Los Sistemas de Auditoría tienen que ser capaces de:
Aceptar datos de los procesos que puedan registrar sus propios datos de auditoría.
111
Recoger la suciente información como para deducir lo que está pasando en el sistema.
Recolectar datos en la totalidad del sistema a todos los efectos.
Hacer acopio de sucesos relativos a la seguridad en otras partes interesantes, aun sin ser
dependientes del host.
Otro de los problemas habituales en este tipo de sistemas es el hecho de que los eventos, evidencias
o muestras se producen muy rápido. Usualmente se afronta esta tesitura en genérico como en
la plataforma de [279], CMW51 , Recolección Selectiva y Reducción Selectiva. La Reducción
Selectiva se basa en recoger sucientes datos para cumplir los requisitos de identicación de
usuarios, objetos accedidos, nivel de seguridad, etcétera. La Recolección Selectiva es idéntica al
caso anterior pero recogiendo selectivamente cualquiera de las partes anteriores acorde al patrón
que se esté buscando. Así mismo, los datos deberán ser almacenados bien localmente o bien
externamente en centros de recopilación de información. El hecho de almacenar la información
localmente sucinta un riesgo de poder ser alterado indebidamente. La recogida de datos que
plantearon en su momento abordaba 3 niveles importantes de modo que la captura fuera global:
intercepción de llamadas de sistema (syscall) en kernel, en la interfaz que se le proporciona por
el sistema operativo al usuario y a captura de interacción entre sistema operativo y aplicación.
El problema asociado es el volumen de datos generados, dado que son muchos los recursos a
monitorizar: sistema, aplicaciones, usuarios, etc.
2.4.1. Preámbulo: Ataques Mimicry en Sistemas de Detección de Intrusiones
Se hace un estudio [372] sobre diferentes tipos de sistemas de detección basados en host
(HIDS) para ver la seguridad que presentan contra diferentes ataques evasivos. Los ataques
denominados Mimicry permiten a un atacante realizar el ataque sin ser detectado por ninguno de
los sistemas existentes. Para poder demostrar este tipo de ataques se desarrolla una aplicación
marco que permitiera efectuarlos, demostrando que era viable realizarlos contra la seguridad
existente en una implementación concreta de HIDS.
Los autores argumentan que para detección de anomalías, casi todos las llamadas al sistemas
se pueden traducir en operaciones de no-operación (no-op), de forma que puedan desorientar
al sistema de detección realizando nalmente la tarea que se desea. Hay mucha literatura que
explica diferentes mecanismos de detección que son susceptibles a engaños mediante este tipo de
técnica:
Sistemas basados en el análisis de llamadas al sistema [134, 310, 14, 309]
Minería de datos [369, 229]
Redes Neuronales [14]
51
Compartmented Mode Workstation
112
Autómatas Finitos [52]
Modelos de Markov Ocultos [374]
Reconocimiento de patrones en secuencias de comportamiento [343, 344]
Una de los puntos de partida de este tipo de técnica es el hecho que no todo código malicioso
tiene la necesidad de llamar a una llamada al sistema. Como segunda arma los atacantes suelen
tener de su mano la paciencia, esperar hasta que la secuencia sea aceptada por el sistema de
detección como comportamiento normal para lanzar el ataque, incluso conduciendo el aprendizaje
del sistema en uno u otro sentido. El atacante contra sistemas basados en detección de llamadas
de sistema, puede introducir un troyano que se encargue de modicar las librerías a las que se
ha llamado para realizar una determinada tarea.
Una parte importante que se debe tener en consideración cuando se realizan este tipo de
ataques es el hecho de que generalmente, después de haber realizado el ataque el sistema entra en
una serie de trazas de syscalls a las que le ha llevado el código atacante, que generalmente no están
contempladas por los sistemas de detección indicando esta anomalía debidamente (detección a
posteriori al ataque producido). Para poder solucionar este tipo de situaciones se debe llegar a
realizar un cierre de aplicación anticipado pero existente en el sistema de detección, haciendo
pasar el ataque como un fallo de programación en vez de como una violación en la seguridad.
Otra aproximación bastante acertada es realizar un ataque mediante las cadenas de syscalls
más comunes dentro de la aplicación objetivo. Es decir, crear de las diferentes trazas que se
puedan tener, aquella que sea más común para que la desviación nal sea lo menor posible.
Siguiendo esta línea incluso se pueden realizar ataques o troyanos que emulen a la aplicación
objetivo después de haber realizado el ataque para que el sistema parezca que se encuentra en
un estado correcto.
Un fallo o carencia habitual en los sistemas de detección es la ausencia en el estudio de los
parámetros, haciendo que haya situaciones en las que varias llamadas sean la misma, queriendo
realizar cosas muy diferentes:
Listing 2.1: Ejemplo de un ataque Mimicry
1
//LLAMADA AL SISTEMA INOFENSIVA
open ( " / l i b / l i b c . s o " , O_RDONLY) ;
//LLAMADA AL SISTEMA DE POSIBLE ATAQUE
6
open ( " / e t c / shadow " , O_RDWR) ;
Otro defecto observado es que si no hay forma de insertar el código atacante dentro del
modelo de la aplicación que mantiene el IDS, hay una forma de variar la secuencia del ataque
113
mediante la inserción de operaciones que no hagan nada. Estas operaciones conocidas como, sin
operación (nop), sirven para que la traza se mantenga acorde a lo que ha aprendido el sistema
de detección, pero realmente el objetivo nal es conseguir poner en marcha la vulnerabilidad de
la seguridad deseada.
Continuando con lo expuesto en el párrafo anterior, siempre es posible generar las variaciones
en el ataque que permitan llegar a la situación en la que el detector no va a ser capaz de indicar
la anomalía. Un ejemplo puede ser tan simple como que una llamada read() de un chero en
memoria, puede ser equiparada en código a una mmap() seguida de un acceso a memoria. Por
la misma regla, hay secuencias que pueden ser desordenadas desde el ataque original al necesario
para evadir el sistema HIDS. De la misma forma unas pocas llamadas al sistema le dotan al
atacante de un poder especial, como por ejemplo la fork(). Esta última llamada es tratada
por los sistemas HIDS desdoblando el sistema para seguir al proceso padre y al proceso hijo, lo
que permite al atacante realizar el ataque en dos pasos diferentes dentro de distintos procesos.
Además si se consigue un acceso a la llamada execve() se le ofrece al ataque la posibilidad de
ejecutar cualquier cosa que desee en el sistema.
2.4.2. Detección mediante Análisis Forense
Es posible mejorar el conocimiento de lo sucedido en un sistema informático mediante el uso
de técnicas forenses [198] que no requieren de predecir la naturaleza del ataque, el conocimiento
del atacante o de los detalles de los recursos del sistema y objetos afectados. Los principios
incluyen la grabación de datos sobre el sistema operativo en su totalidad, particularmente los
eventos y entornos en espacio de usuario, así como interpretando los eventos en capas de diferente
abstracción según el contexto donde han sucedido. Los autores además, proponen la creación de
una máquina de estados nita sobre la que los resultados puedan ser establecidos preferiblemente
a ser inferidos.
El análisis forense es el proceso de comprensión, recreación y análisis de los eventos que han
sucedido previamente. El logeo es la grabación de datos que puedan ser útiles en el futuro para la
comprensión de eventos pasados. El proceso de auditoría de sistemas se compone de la recogida,
examen y análisis los datos guardados.
El hecho de trabajar temporalmente después de haber sucedido la vulnerabilidad, les permite
a los expertos conocer la forma en la que ha sido cometida. Para poder realizar este tipo de
análisis hay que hacer uso de una serie de puntos clave:
El sistema al completo debe ser considerado.
Los efectos de una acción pueden ser diferentes de los que se espera que sean.
Los datos en ejecución son el único registro de qué pasó exactamente. Mientras que los
escaneos de vulnerabilidades anteriores y posteriores a la intrusión pueden ayudar ampli-
114
amente, un conjunto de datos en tiempo real es la única fuente autorizada de la que se
puede sacar información completamente able.
En este tipo de metodologías se tienen en cuenta una serie de premisas de partida:
Principio 1:
Tener en cuenta el sistema completamente. Esto incluye tanto el espacio de
usuario, como el espacio de núcleo del Sistema Operativo, sistemas de cheros, pila de
protocolos de red y subsistemas asociados.
Principio 2 :
No siempre esta logeado lo que se presupone sobre fallos esperados, ataques
y atacantes. No creer en ningún usuario y no conar en ninguna política, dado que no se
sabe de antemano lo que se encontrará.
Principio 3 :
Tener en consideración los efectos de los eventos, no solo por ser debidos a
una serie de acciones, si no por cómo esos efectos pueden alterar el contexto del entorno.
Principio 4 :
El contexto ayuda en la interpretación y compresión del signicado de un
determinado evento.
Principio 5 :
Cada acción y cada resultado debe ser procesado y presentado de forma que
pueda ser analizado y comprendido en un análisis forense.
En el artículo se expone que una de las mayores faltas en esta técnica es la inexistencia de un
análisis automatizado para poder realizar todas las comprobaciones. El resumen de realizar una
solución genérica pasa por recoger no solo los eventos del kernel, si no también información sobre los tiempos, tamaños y localizaciones de alojamientos de información en memoria, lecturas y
escrituras. Las herramientas deberán conseguir eventos de información acerca de enlaces abstractos, sobre todo de aquellos que vayan a la red o que sobrepasen el sistema de cheros local. Se
deben recoger datos de programas, funciones y nombres de variables. Mediante una correlación
apropiada de esos nombres, eventos de memoria, contexto del sistema, entorno del programa,
herramientas que cubran los principios anteriores, si es presentada de forma humanamente legible
se podrá tener una herramienta adecuada para estas problemáticas.
El análisis de intrusiones a día de hoy, suele ser un trabajo difícil que se realiza generalmente a
mano, debido a que los administradores carecen de información y herramientas para comprender
fácilmente la secuencia de los pasos que ocurren en un ataque. Los creadores de la aplicación
BackTracker [212], después de producirse la intrusión, han dispuesto de una serie de medidas
para poder relacionar las evidencias entre sí. Hay una serie de factores que pueden indicar una
dependencia entre eventos:
Dependencias entre procesos. Esto se produce cuando un proceso afecta directamente en
la ejecución de otro proceso. Las causas pueden ser: creación, compartición de memoria,
envío de mensajes o señales...
115
Dependencias proceso a chero. Conseguir datos interesantes de cheros del sistema mediante un proceso. También se puede cargar el chero completamente en memoria y leer/escribir directamente ahí antes de guardarlo.
Dependencias entre proceso y nombre de chero. Un ejemplo de esto puede ser cuando
una aplicación carga un chero con su conguración, si este contiene datos incorrectos se
pueden producir situaciones peligrosas.
Para realizar el trazado inverso de aplicaciones se logean los objetos y los eventos con las dependencias en tiempo de ejecución. De esta forma se puede construir un grafo que indique las
relaciones entre todos los objetos que se han ido viendo en ejecución. Un ejemplo de un grafo
orientado a los eventos que se van realizando, partiendo de la información de que se ha producido
un ataque:
Figure 2.43: Grafo de dependencia que puede seguirse realizando operaciones de BackTracking
2.4.3. Detección basada en análisis estático o instrumentación binaria del
sistema
En el documento [198] los autores explican la creación de una herramienta, DOME, que
realiza un análisis estático para identicar las localizaciones (espacio virtual de direcciones) de las
llamadas al sistema que realizan los programas ejecutables. Después de obtener esas direcciones
se monitorizan los programas en tiempo de ejecución y se verica que la posición de memoria
utilizada por el ejecutable es la que corresponde con el estudio del sistema anterior. Esta técnica
es simple, práctica y aplicable al mundo real, pero si bien el equipo de investigación S3lab de la
Universidad de Deusto debe indicar que es posible infectar el código de las llamadas a sistema,
manteniendo intacta la posición del mapeo de memoria virtual.
Los autores sostienen que mediante el sistema DOME realizado obtienen una potente técnica
para proteger el software contra código malicioso, bien código inyectado dentro de los procesos
(buer overows...), bien código generado automáticamente (virus polimórcos, troyanos que
116
guardan sus datos cifrados, descifrando su código fuente y ejecutándose en el momento de arrancar...), o bien código malicioso ofuscado (virus, troyanos, gusanos... que ocultan su código de
forma que sean difíciles de detectar).
Mediante esta técnica es posible entrar al tan ansiado campo para los administradores de
detección de ataques nóveles, Zero-day attacks. Este proyecto ha centrado su estudio en windows
2000, con lo que el formato de estudio consecuentemente se ha jado en formato de chero
portable ejecutable (formato PE).
Los desarrolladores indican que para la detección del código inyectado, problemática indicada
previamente por el equipo de investigación S3lab, no es posible realizar esta técnica, dado que
lo que se cambia no es la dirección o la llamada a una u otra función, si no el propio código que
se va a ejecutar en el momento de su carga.
Otro tema que plantean en el documento, es la posible sobrecarga del sistema al realizar
la captura de eventos producidos, se indica que producen una sobrecarga al sistema de un 5%
al realizar las funciones de comparación para cada llamada a la API. Así mismo el sistema
desarrollado esta limitado a las llamadas a funciones de Win32, dejando las llamadas más internas
al sistema sin capturar.
Los autores plantean una serie de premisas:
Cualquier código inyectado, generado dinámicamente u ofuscado se asume como malicioso.
El código maligno interactúa con el sistema operativo.
En la interacción con el sistema operativo, el código malicioso, usa las llamadas exportadas
por Win32 (en el sistema operativo en estudio de los autores).
Cuando un código malicioso se esconde de la detección y análisis mediante el uso de generación de código dinámico y ofuscación, se esconde a su vez el uso de las llamadas a
Win32.
Los ejecutables software que deben ser protegidos pueden ser desensamblados y se puede
obtener la información sobre las API's usadas. Por lo tanto son monitorizables.
Se suele hacer uso de Detours [140]como herramienta de análisis para facilitarse el acceso al sistema operativo en cuestión, herramienta que se introducirá y comentará en el siguiente capítulo.
La investigación últimamente esta decantándose en lo que se denomina instrumentación binaria dinámica, utilizada comúnmente en los estudios para realizar Análisis Forenses [366]. El
malware52 actual es susceptible de tener métodos para modicar el código de programa que usan.
Los compiladores en tiempo real (JIT) a pesar de dar un soporte transparente, no son capaces de
seguir sistemas o aplicaciones multihilo, programas automodicables o código que se autotestea
en modo de núcleo. Para poder resolver este problema los autores han creado una herramienta
52
Término genérico que hace referencia a virus, troyanos, software espía (spyware)
117
que analiza la granularidad sobre el proceso, la red, teclas usadas, cheros, registro de sistema
y un largo etcétera. Mediante esta herramienta después de detectar un comportamiento anómalo se puede analizar a través de debuggers las diferentes formas de un virus polimórco, su
cifrado-descifrado de datos, el contenido de memoria que ha usado.
Las técnicas de instrumentación binaria representan a la habilidad de controlar las construcciones pertenecientes a cualquier código y es empleada tanto en técnicas de análisis grueso como
granular. El control se reere a generar la construcción del ejecutable para observar una posible
alteración semántica. La instrumentación binaria se clasica en dos categorías:
Basadas en pruebas: Dtrace [55], Dyninst [45], Detours [140]. Realizan su función modicando el programa objetivo para ser ejecutado de una forma determinada cuando se llama
al programa original.
JIT: Pin [234], DynamoRIO [44], Valgrind [257]. Estos métodos se basan en la instrumentación mediante empleo de máquinas virtuales (VM).
Los métodos basados en pruebas no son transparentes debido a que las instrucciones originales
se sobreescriben en memoria por medio de lo que se denominan trampolines53 .
El sistema que denominan SPiKE ofrece una API sobre la que integrar las funciones para
los analizadores que se quieran. Introduce en la memoria virtual una serie de elementos lógicos
que se activan cuando se produce una lectura, escritura o ejecución. El producto se basa en
otro entorno denominado VAMPiRE [366] para poder insertar esos códigos lógicos en la posición
adecuada de memoria. La técnica de activación de eventos que usan, denominada por ellos
Invisible
Drift
lo que hace es insertar código en unas determinadas posiciones correspondientes a la
construcción del código del que se desea realizar la instrumentación. Un BreakPoint en código
permite detener la ejecución de código arbitrario durante el tiempo de ejecución. Para evitar
que se detecte este tipo de ganchos se usan páginas de memoria que contienen la información
referente a ellas mismas como no presente y se basan en el sistema de Detección de Excepciones
de Paginado en Memoria (PFE).
Los errores más comunes de programación de aplicaciones con los que se suele ganar el control
de un sistema o de una aplicación residen en la manipulación de corrupciones en memoria de
los procesos. Los ataques más comunes actualmente son debidos a buer overow o a format
string. Se considera importante identicar automáticamente cuándo se han producido estos
errores. El punto que presentan los autores de este texto [201] en el que se puede detectar el
error producido es el momento del cierre inesperado y de forma incorrecta de la ampliación.
Una vez conocidos los valores de datos y direcciones que se han embebido en el ataque se puede
bloquear este tipo de ejecuciones. En el documento [201] se presenta y desarrolla un sistema
descentralizado y auto protegido para los ordenadores cableados en red. Se pueden encontrar
53
Un trampolín es una secuencia de código que se puede atravesar entrando en múltiples partes de la misma
dado que no realiza operaciones que varíen el contexto del procesador.
118
numerosos intentos para la detección de rmas de ataque de este tipo, como pueden ser los
siguientes:
Honeycomb [214]
Autograph [210]
Early Bird [312]
Poligraph [193]
Pero este tipo de métodos suelen de una limitación, que generalmente se hace uso de un análisis
sintáctico sobre los ataques, olvidando la semántica en la que se han producido los mismos.
Muchas otras aproximaciones que se están desarrollando se basan más en la instrumentación del
código binario e incluso pueden recuperarse de los ataques una vez producidos:
TaintCheck [259], realiza un análisis dinámico mediante una emulación binaria del programa para atrapar la propagación del binario por la red. A su vez también se realizan
rmas de ataques basadas en semántica.
DIRA [321], hace una instrumentación del código para mantener un log de actualización de
la memoria mientras el programa está en ejecución, realizando incluso una vuelta a atrás
para volver a una zona segura cuando se ha producido el ataque.
STEM [311] realiza una aproximación reactiva. Después de detectar un ataque, se reemplaza la vulnerabilidad del programa con una versión parcheada.
Las herramientas anteriores aun siendo un paso importante introducen debido a la instrumentación de código una sobrecarga importante en la ejecución de un determinado proceso.
El análisis del ujo de la información dinámica (DIFA) [248] es muy útil para la detección de
intrusiones a nivel de aplicación. Uno de los efectos más habituales de los ataques sosticados es
el hecho de poder introducir información insegura dentro de partes importantes de la aplicación,
esta modicación es un hecho contrastable del suceso de este tipo de ataques. Muchos de estos
patrones de comportamiento, una vez detectados se pueden introducir en un sistema de detección
de intrusiones basado en rmas.
2.4.4. Detección basada en rmas
Arbaugh en el año 2001 [43] indica que en el mundo de la seguridad informática de los
sistemas de alta disponibilidad, los administradores se encuentran en la tesitura de mantener
sistemas a sabiendas con vulnerabilidades. Esta situación se produce debido a que se descubren
fallos de seguridad continuamente, pero pasa un tiempo hasta que se tiene la solución de los
119
Figure 2.44: Ciclo de vida de una vulnerabilidad en software
mismos, conllevando que estos administradores se encuentren indefensos durante periodos de
tiempo dado que una baja en el servicio conlleva pérdidas difícilmente cuanticables.
Para ello Arbaugh diseñó, implementó y evaluó un sistema que soporte la construcción y ejecución de predicados que representen una determinada vulnerabilidad. El sistema que presentan,
Intro-Virt, se vale de técnicas basadas en introspección de máquinas virtuales para monitorizar
la ejecución de la parte software, aplicaciones y sistema operativo.
El proceso por el que una aplicación determinada o sistema operativo se mantiene vulnerable
es el siguiente:
Como se puede ver en la imagen anterior, el hecho de que una vulnerabilidad sea observada,
no implica que inmediatamente se corrija, aquí entran en juego diferentes motivaciones de los
administradores, desarrolladores y directivos [157, 24, 43, 35].
La idea sobre la que se basan los autores es comprobar mediante una serie de predicados si se
dan las propiedades para una u otra vulnerabilidad. Así mismo, combinando los predicados con
los resúmenes de las máquinas virtuales creadas, el usuario podrá conocer si ha sucedido alguna
anomalía de este tipo en el pasado. Los autores dejan claro que descubrir vulnerabilidades
acaecidas, no es prevenir de una posible intrusión, pero sí es un punto de partida para conocer
hasta qué punto el sistema ha sido comprometido.
Otro de los pilares fundamentales que tienen en mente los autores es que mediante la combinación de predicados de vulnerabilidad especícos, junto con una respuesta estratégica se puede
alertar al usuario e incluso prevenir sobre los ataques que están sucediendo en el sistema.
Los predicados que buscan los autores son fáciles de escribir una vez que es conocida la
vulnerabilidad e incluso podrían ser transcritos por la entidad que se encargue de escribir el
parche. Un predicado correcto no puede tener ni falsos positivos ni falsos negativos, pero en
contraposición con los detectores de exploits especícos se lograría captura las variantes del
código malicioso, cualidad que no es soportada por estas últimas herramientas.
Los predicados con las deniciones de vulnerabilidades deberán ser ejecutados fuera del entorno del sistema, es decir, que no es apropiado mantener la revisión de los mismos ni en zona
de usuario, ni en zona de kernel. La solución pasa por tener hardware dedicado a este tipo de
tesituras.
Una de las primeras pruebas que realizan es ejecutar el software objetivo en una máquina
virtual, de esta forma se obtiene acceso total al sistema en estudio, esta técnica se denomina:
introspección de máquinas virtuales [142]. Para poder demostrar estas ideas los autores se basan
120
en VMM (Virtual Machine Monitor), que en plataformas de virtualización como Xen [276], es la
parte encargada de gestionar los recursos utilizados. Así mismo si el atacante consigue poner en
el peligro el propio núcleo del sistema de virtualización, debido a una fuga de la caja estanca en
la que se estaba trabajando, se tendrán problemas complejos de detectar y solventar.
2.4.5. Detección de ataques contra la lógica de las aplicaciones
Como ya hemos visto en secciones anteriores, la detección de anomalías basadas en el análisis
de trazas de llamadas al sistema de los diferentes programas para obtener un modelo de su comportamiento y posteriormente analizar sus llamadas en busca de anomalías, puede dar resultados
óptimos en la detección de ataques. No obstante, este tipo de detección no es apropiada cuando
lo que se ataca en la lógica de las aplicaciones. En estos casos se hace insuciente en análisis de
ujo de llamadas al sistema, pues estos ataques en contadas ocasiones modican la trayectoria
de ejecución de los procesos (con lo que la traza de llamadas al sistema invocada por éstos se
mantiene intacta). Por tanto, las aproximaciones basadas en el análisis de secuencias de llamadas
al sistema no detectarían estos ataques [134, 371].
Otro problema es que la información que se necesita para detectar ataques a nivel de lógica
de aplicación puede no estar o ser muy difícil de extraer de las llamadas al sistema invocadas por
el proceso.
Para detectar ataques de éste tipo, es recomendable realizar una auditoría selectiva en ciertos
puntos del ujo de control de la aplicación. El problema es que pocas aplicaciones proveen de un
hook54 , e incluso cuando éstos están disponibles no suelen estar colocados en el lugar correcto.
Además, la técnica de instrumentación suele ser especíca para cada aplicación y difícil de portar
a otros programas.
Auditando los datos
Auditar es el mecanismo de recogida de datos respecto a la actividad de los usuarios y las
aplicaciones. Ya que el sistema operativo es considerado como una entidad conable debido a
que se encarga de los accesos a los recursos (como memoria y cheros), la mayoría de los sistemas
de auditoría están implementados dentro de él. Estos sistemas de auditoría no están diseñados
especícamente para la detección de intrusiones y por lo tanto, en muchas ocasiones los datos
producidos por los sistemas de auditoría del sistema operativo contienen información irrelevante
y escasez de datos útiles. Debido a este hecho, usualmente los sistemas de detección de intrusiones
desarrollan herramientas propias para acceder directamente al sistema operativo en busca de la
información realmente relevante.
Lunt [235] sostiene que es necesario disponer de aplicaciones auditoras que provean de la
información puramente necesaria para la detección de intrusiones.
54
Sistema de recolección de datos a bajo nivel, como por ejemplo las llamadas al sistema invocadas y los
argumentos de éstas.
121
Reescritura binaria dinámica
Esta técnica es independiente de plataforma y soporta la recogida de información en cualquier lugar dentro del ujo de control de la aplicación [401] y es utilizada en conjunto con rmas
especícas de aplicación para detectar ataques que explotan los errores de la lógica de la aplicación. Esta aproximación ha sido validada a través de muchos estudios de casos de ataques contra
aplicaciones reales como por ejemplo Apache y OpenSSH [401].
La reescritura binaria dinámica es una técnica de post-compilación que cambia directamente
el código de los ejecutables. Al contrario que la librería de interposición dinámica, la reescritura
binaria dinámica funciona con programas vinculados estática y dinámicamente. Además provee
de un mayor acceso a la parte interna de la aplicación ya que además de las librerías de funciones, pueden ser utilizadas funciones estáticas de la aplicación. Existen dos tipos de técnica de
reescritura binaria:
1. Estática: Modica la imagen residente en disco del binario55 de los programas.
2. Dinámica: Cambia la imagen de memoria de un proceso.
ATOM [328], EEL [225], Purify [159], y Etch [345] son ejemplos de herramientas basadas en
técnicas de reescritura estática. Dyninst [45] y Detours [140] son ejemplos de herramientas de
reescritura dinámica.
Comparando ambos métodos, la escritura dinámica tiene la ventaja de que mantiene intactos
los ejecutables de las aplicaciones. Además, utilizando la escritura dinámica es posible modicar
los binarios de la aplicación de varias maneras, dependiendo del contexto de invocación de la
aplicación y permite mantener el código tras una llamada fork()56 , por lo que el proceso hijo
también será instrumentalizado.
En términos generales, la reescritura binaria dinámica es una aproximación de interposición.
La técnica de interposición a las llamadas al sistema ha sido utilizada para desarrollar perles
de usuario y depuración de sistemas software, además de ser muy utilizada con propósitos de
seguridad:
1. Curry, usa interposición dinámica de librerías para proling57 y traceo de llamadas a las
librerías [81].
2. Deteurs, una herramienta de depuración y proling que utiliza reescritura binaria dinámica
para interceptar funciones Win32 [140].
55
Los cheros binarios son archivos electrónicos que han sido guardados utilizando el código básico de las
computadoras u ordenadores: código binario, una sucesión de ceros y unos. [1]
56
Se trata de una llamada al sistema operativo para que duplique el proceso que ha llamado, creando por tanto
un proceso hijo que será una copia de él mismo.
57
Técnica de creación de perles de usuario, aplicaciones, ...
122
3. ByPass, extiende la funcionalidad del software de sistemas existente para computación
distribuida utilizando técnicas de interposición en librerías compartidas [354].
4. Interposition Agents, es un RootKit58 para interponerse entre el código de usuario y el
núcleo del sistema operativo [200].
Por lo tanto ésta aproximación separa las rutinas de auditoría de la aplicación original. De esta
manera puede ser añadido un nuevo módulo de auditoría sin que se requiera la recompilación
de la aplicación. La selección del módulo de auditoría es pospuesta hasta el momento en el
que la aplicación es invocada, permitiendo una selección de conguración de auditoría exible.
Además, las rutinas de auditoría y la aplicación corren bajo el mismo espacio de direcciones con
rendimiento comparable al acercamiento de modicación del código.
2.4.6. Detección basada en Secuencias de Syscalls
Estudio de secuencias de llamadas al sistema para clasicar las intrusiones [37] y los fallos
inducidos en procesos privilegiados de UNIX. La clasicación es una capacidad esencial para
responder a una anomalía, dado que permite asociar respuestas apropiadas para responder a
cada anomalía. Los autores [199] arman que la creación de un Diccionario de Anomalías es
imprescindible en este tipo de sistemas. Este tipo de diccionarios se encargan de contener la
información sobre las secuencias anómalas para cada tipo de anomalía. A su vez, en paralelo
con este tipo de diccionarios se pueden crear los denominados Diccionarios Normales, para poder
realizar la clasicación debidamente.
Los esfuerzos durante más de 20 años se han centrado en la generación de Sistemas de Seguridad de la Información aplicando técnicas de Minería de Datos, Aprendizaje de Máquinas, Reconocimiento de Patrones e Inteligencia Articial [192, 370, 289, 258]. La metodología planteada
en [199], denominada stide (sequence time-delay embedding) se puede resumir de la siguiente
forma:
1. Modelado: Se caracteriza el fenómeno en estudio por medio de una secuencia de variables
o símbolos dentro un alfabeto largo pero nito. Estas secuencias se obtienen manteniendo
el programa en estudio ejecutándose desde el arranque hasta el cierre.
2. Recolección de Datos Normales: Recogida de grandes volúmenes de datos correspondientes a la operación normal del programa, almacenando los símbolos generados. Ene este
apartado se realiza el estudio numerosas ocasiones, produciendo numerosos procesos, hilos... tratando de explorar la operación normal de funcionamiento de todas las formas
posibles.
58
Es una herramienta que se ejecuta a nivel del sistema operativo capaz de interceptar llamadas al sistema y
afectar a los procesos que se están ejecutando, con diversos propósitos.
123
3. Extracción de características: Se selecciona un tamaño de cadena (k), y se construye un
diccionario de secuencias cortas sobre los datos del Diccionario Normal. Esto se realiza
mediante una ventana deslizante del tamaño k a través de la muestra, saltando sólo un
único símbolo cada momento.
4. Detección: Dado una muestra de entrada del sistema en estudio, se realiza la detección
de anomalías mediante comparación de secuencias contra el chero salvado de normalidad
anterior. Si las secuencias no son encontradas se denominarán secuencias anómalas y se
almacenarán en el Diccionario de Anomalías.
2.4.7. Detección basada en grafo
Detección basada en grafo de llamadas al sistema
Los autores establecen que si bien el kernel de linux dota al usuario de una serie de funciones
interesantes de modularidad y exibilidad, en sistemas embebidos se puede lograr un mejor
rendimiento, para ello se valen de lo que han denominado como grafo de llamadas al sistema
basado en la ingeniería inversa de este tipo de sistemas. Mediante una representación en forma
de grafo se puede representar el comportamiento del sistema objetivo mejorando o haciendo
hincapié en optimizar determinadas funciones.
En la forma en la que trabajan los autores, se consigue representar y abstraer el funcionamiento interno del kernel, así como de las aplicaciones que hacen uso del mismo. Una
representación del funcionamiento de llamadas entre funciones de código puede ser el siguiente:
Figure 2.45: Grafo de llamadas que se producen desde código fuente.
Un grafo de llamadas es un grafo dirigido que representa la estructura estática del programa.
Al igual que el grafo anterior se ha realizado para un programa, se puede realizar un grafo
semejante para las llamadas desde el código fuente de las librerías. Es el mismo concepto que en
el caso anterior pero carece de raíz. Esto queda expresado en la gura siguiente:
124
Figure 2.46: Grafo de llamadas entre librerías
Teniendo el grafo adecuado para cada máquina, dependiendo de las aplicaciones que se tengan
instaladas, se puede diferenciar un comportamiento normal del mismo o sucesos anormales. En
la misma línea, dado que los sistemas de detección de intrusiones se usan para detectar los rastros
de actividades maliciosas sobre redes y sistemas, en el documento de Mutz de 2006, [95] se indica
una forma para detectar una secuencia de llamadas al sistema anómalas.
Los sistemas de detección de intrusiones se clasican, como ya se ha comentado en puntos
anteriores, de dos formas: basados en malos usos o basados en anomalías. En los primeros
sistemas (misuse-based) [277, 231] se tiene un número de descripciones de ataque, o rmas, que
se tratan de localizar sobre ujos de datos de auditoría de sistemas. Estos sistemas generalmente
son ecientes y tienen una baja tasa de detecciones erróneas que se denomina falsos positivos.
Si bien, la gran pega de este tipo de sistemas es el hecho de que no detectan ataques que no
haya sucedido alguna vez y de los que se tenga conocimiento. Un buen ejemplo para una tarea
concreta puede ser el caso de detección de condiciones de carrera, en el que se ha desarrollado un
lenguaje de auditoría de trazas BSM, denominado BSML [281]. En este documento se explica
un lenguaje para determinar cuando se dan estas situaciones y actuar en consecuencia por si se
esta produciendo un ataque.
Dentro de los diferentes tipos de sistemas de detección de intrusiones, los que se basan en
anomalías [105, 146] construyen modelos del comportamiento que se espera de las aplicaciones.
Para generar estos modelos se revisa la operación normal de las mismas, guardándolo como punto
de referencia. Los modelos que se consiguen se denominan perles.
De la forma anterior comparando los modelos de comportamiento de cada aplicación con
el comportamiento actual se pueden obtener las desviaciones que hayan surgido. Una de las
premisas de esta forma de actuación es el hecho de que una desviación sobre el comportamiento
aprendido, conlleva ser víctima de un ataque. En el documento de Denning [105] se trata de
125
realizar una aproximación basándose en perles de usuario, pero este tipo de técnicas no pueden
ajustarse a los cambios de repentinos de los usuarios en su comportamiento.
Se han desarrollado diferentes sistemas de anomalías con diferentes técnicas de detección.
Ejemplos de ello pueden ser desde la detección y de datos sobre el tráco de red [229] o análisis
estadísticos de registros de auditoría [396]. La secuencia de llamadas al sistema producida por
las aplicaciones ha sido objeto de análisis de detección de anomalías. Las técnicas que se han
ido proponiendo son aproximaciones de dos tipos: basadas en especicaciones y basadas en
aprendizaje.
La aproximación mediante especicaciones confía en unos modelos especícos para cada aplicación que han sido realizados manualmente [36, 62, 213], bien con conocimiento experto, bien
derivadas a través del uso de algún programa con alguna técnica de análisis [371]. Los perles
generados de esta forma son introducidos como entrada de un sistema de detección de intrusiones
en tiempo real, así cuando se produzca una secuencia de llamadas no conformes con el modelo
se levantará la correspondiente alerta. La mayor pega de este tipo de sistemas de detección es el
hecho de que tienen una limitada capacidad para generar las especicaciones, tarea normalmente
bastante ardua para ser realizada a mano. Otro problema de este tipo de HIDS es la necesidad
de interacción del usuario durante la fase de entrenamiento, si bien es posible utilizar modelos
predenidos para cada aplicación, no son aplicables para todos los usuarios, sobretodo al emplear
diferentes conguraciones. Así mismo, para este tipo de aproximación se requiere el acceso al
código fuente.
Si ahora se analiza la técnica de aprendizaje se debe señalar que no es necesario asumir nada
de antemano, si no que los perles se construyen en base al análisis de las llamadas al sistema
durante la ejecución normal. Esta primera aproximación vino de la mano de Forrest [134]. La
clave de este método es el hecho de que un programa que tiene que interaccionar con el sistema
operativo en el que esta siendo ejecutado requiere hacer uso de las llamadas al sistema para
poder causar un daño permanente en el sistema. Cuando una secuencia de llamadas al sistema
se desvía del comportamiento esperado, se asume que se está produciendo un ataque.
La idea era recabar durante la fase de aprendizaje todas las posibles secuencias de llamadas al
sistema de una determinada longitud. Durante la fase de detección, se comparaban las cadenas
de secuencias recogidas con las legítimas aprendidas en la primera fase, teniendo la posibilidad
frente a desviaciones de indicar la anomalía. El problema de esta técnica es que sólo hace uso de
la secuencia que siguen estas llamadas, dejando a un lado los argumentos y los valores devueltos
al retornar de las mismas. Además en la metodología de la autora sólo se examina un proceso
en concreto.
Siguiendo ésta línea de trabajo, otros autores han continuado el trabajo precursor del análisis
de secuencias de syscalls [371, 374, 131], y por norma general es la opción más utilizada para
análisis del comportamiento de los programas.
Las técnicas basadas en detección de anomalías conlleva un riesgo inherente de detectar como
126
anomalía comportamiento de secuencias que son legítimas en el funcionamiento de una determinada aplicación, así como realizar código malintencionado que siga las secuencias de llamadas
correctas. Además generalmente las técnicas que se aplican no hacen uso de los argumentos que
llevan asociados las llamadas al sistema.
Se proponen dos posibles mejoras a los sistemas de detección de anomalías basados en host:
1. Aplicar sistemas de detección que incorporen los argumentos que llevan las llamadas al
sistema.
2. Descubrir una forma de cuanticar la puntuación de anomalía de cada modelo en una
medida global. Este resultado determinará si un evento es parte o no de un ataque.
En concreto para resolver este problema los autores proponen una técnica que hace uso de las
Redes Bayesianas para realizar la clasicación de las llamadas al sistema. Los autores demuestran
que el análisis de los argumentos y el uso de clasicadores Bayesianos mejoran la precisión contra
los intentos de evasión. La salida de cada uno de los motores de detección individuales se combina
con una Clasicación Bayesiana, mejorando a los clasicadores basados en umbrales naive que
se usan para combinar las salidas de los modelos.
El sistema propuesto al estar basado en análisis de llamadas al sistema individuales, es más
resistente contra los ataques que tratan de asemejarse a la forma normal de comportamiento de
una aplicación: ataques mimicry attacks [348, 346, 372]. La denición formal de este tipo de
ataques es aquel que mediante código inyectado ataca a la seguridad de un sistema emulando la
secuencia de llamadas al sistema de las aplicaciones legítimas.
El modelo que presentan los autores [95], consiste en un ujo ordenado de llamadas al sistema
almacenadas dentro del sistema operativo S = {s1 , s2 , ...}. Cada llamada al sistema s ∈ S tiene
un valor de retorno rs y una lista de argumentos < as1 , ..., asn >. Se debe indicar que los autores
no están teniendo en cuenta las relaciones entre las llamadas al sistema. Para cada llamada al
sistema creada por una aplicación se crea un perl, comparando después del aprendizaje cada
llamada de esa aplicación a las syscalls del sistema si concuerdan con el perl aprendido en la
primera fase.
En el modo de detección, la función de cada modelo es devolver la probabilidad de que
ocurra un determinado argumento basándose en el modelo aprendido previamente. Un valor de
baja semejanza (likelihood) de que una determinada característica es observable en un perl
establecido indica la posible anomalía que se esta produciendo.
Para los autores del documento [95] sólo se considera ataque aquello que se salga de lo común
dentro de los posibles parámetros que se puedan tener en un argumento de llamada al sistema.
Si un ataque se realiza sin invocar a las llamadas del sistema con unos argumentos dentro de los
del modelo, no será reconocido. Para poder caracterizar las llamadas al sistema se aplican una
serie de modelos que ayudan a la identicación de anomalías:
127
1.
Longitud de la cadena de texto.
Generalmente los parámetros que se introducen en las
llamadas a las API's o al sistema ejecutivo tienen una longitud máxima de unos cientos de
caracteres y generalmente son legibles directamente por el ser humano. Si se introduce un
ataque dentro de este tipo de parámetros se acaban insertando caracteres no reconocidos
que aumentan los tamaños normales que se tenían dentro de cada parámetro.
2.
Distribución de Caracteres.
La forma en la que se distribuyen los caracteres dentro de las
cadenas de texto de los argumentos suele ser regular, aparte de ser generalmente caracteres legibles. Por normal la mayor parte de los caracteres se encuentran en un pequeño
conjunto de 256 caracteres: letras, números y unos poquitos caracteres especiales. Dentro
de los lenguajes naturales escritos, por ejemplo castellano o ingles, los caracteres tienen
una distribución de frecuencias de aparición uniforme. Es cierto que no se puede comparar
un lenguaje natural con el empleado por un sistema computerizado, pero tienen ciertas
semejanzas en la distribución de caracteres que bien pueden ser tenidas en cuenta.
3.
Inferencia estructural.
Es posible que el atacante haya conseguido mantener la acción
dentro de unos parámetros normales para la distribución de caracteres, y/o en una longitud
adecuada a la normalidad de las longitudes de cadenas de texto. Para poder capturar
adecuadamente este tipo de ataques se realiza el análisis de la estructura de argumentos,
que no es más que la gramática de expresiones regulares que puede emplear ese argumento
en concreto. La inferencia estructural es el proceso por el cual se obtiene esta gramática.
4.
Buscador de Tokens.
El objetivo del localizador de tokens es determinar si los valores de
determinados argumentos de llamadas al sistema se pueden resumir en un conjunto de
alternativas posibles reducido. Esto se debe a que generalmente una aplicación pasa a
menudo valores idénticos, como ags y handlers, en los argumentos de las syscalls. Cuando
un ataque cambia el ujo normal de ejecución y consigue saltar al código malicioso propiamente dicho, estas restricciones son violadas.
Finalmente para homogeneización de los resultados de los diferentes motores se emplea una
clasicación basada en redes bayesianas que tiene la siguiente estructura:
128
Figure 2.47: Arquitectura bayesiana del sistema de detección de anomalías para host propuesto
en [95]
Siguiendo la línea de investigación abierta para superación de los sistemas de detección más
utilizados basados en detección de desviaciones, hay autores que clasican estos sistemas como
caja blanca, caja negra o caja gris [141]. Para discernir los sistemas y poder clasicarlos se valen de la información que usan para construir el modelo mediante el que realizan la
comparación:
Los detectores de caja negra emplean únicamente el número de la llamada al sistema
utilizada. Potencialmente estos detectores pueden hacer uso de los argumentos en esas
llamadas.
Los detectores de caja gris extraen además información en tiempo de ejecución a medida
que las llamadas al sistema se van produciendo.
Los detectores de caja blanca extraen el modelo directamente desde el código fuente o del
binario.
Los detectores de caja negra y caja gris ya han sido comentados en el documento. Los detectores
de caja blanca se basan en el concepto de falsos positivos cero, dado que siempre indican una
posible intrusión. Si bien estos detectores no son siempre apropiados, en principio debido a que
el código fuente no es siempre accesible, además que el hecho de realizar un análisis estático es
129
complejo por causas externas: ofuscación, sistemas de protección digital, packers59 ... Otro inconveniente de las cajas blancas son los programas que se cambian a sí mismos, muy comúnmente
usados en técnicas víricas.
En el paper [141] exponen una nueva técnica que denominan grafo de ejecución, que es técnica
pionera juntando las tres cajas. Se trata de construir un modelo que acepte las mismas secuencias
de llamadas al sistema pero con las bases de partida de las cajas blancas. Los autores denominan
a la secuencia de observaciones como ejecución, basándose en llamadas a API's intermedias o
a syscalls directamente de sistemas UNIX, en los que se va apilando/rellenando los parámetros
en la pila para hacer la llamada o en los registros para solicitar la interrupción directamente.
Así mismo en la misma traza de ejecución se anexan los valores de retorno y las direcciones de
retorno que se requieran. Finalmente el concepto de grafo de ejecución, que se construyen en base
a las observaciones de ejecución explicadas con anterioridad, consta de pares de identicación
de llamadas al sistema consecutivas y las direcciones de retorno de la pila cuando se realiza la
llamada en sí misma. Dado que cada una de las direcciones devueltas revela información sobre
la estructura de llamadas del sistema, se puede considerar una aproximación a la terminología
de caja blanca.
Figure 2.48: Código fuente y grafo de ejecución presentado en el paper [141]
2.4.8. Visualización e identicación del contexto de las intrusiones desde las
trazas de llamadas al sistema
Los sistemas de detección basados en anomalías son muy útiles pues son capaces de detectar
técnicas de intrusiones nuevas que no han sido analizadas y que no tienen rmas conocidas.
Sin embargo esta capacidad conlleva el problema de la posibilidad de generar falsos positivos.
Esto es debido a que el análisis de la normalidad se lleva a cabo mediante el análisis del funcionamiento del programa y comportamientos normales pueden quedar fuera de éste análisis. La
mayoría de las técnicas tratan de generalizar el comportamiento normal para modelar mejor este
59
Un packer es un programa, generalmente comercial que se encarga de impedir que se pueda realizar ingeniería
inversa en los programas binarios que se distribuyen.
130
tipo de conducta. Aun así este hecho implica que se contemplará mayor parte de una posible
pauta intrusiva. La identicación del contexto de la intrusión60 puede ayudar signicativamente
a aumentar la tasa de detecciones y a reducir los falsos positivos generados [402].
Flujo de trabajo del Identicador del contexto de intrusiones (ICI)
La adeshión de un módulo de identicación del contexto de intrusiones consiste en colaborar
con el motor de análisis de anomalías, realizando un aprendizaje o-line, (es probable que al
módulo ICI le lleve un tiempo considerable determinar los contextos de intrusiones), en el cual
cada vez que salte una alarma el módulo ICI analizará el contexto y determinará si ésta era
un falso positivo o no. En caso de serlo la secuencia que ha hecho saltar la alarma debería
ser añadida al sistema inteligente de detección de intrusiones como parte del comportamiento
normal, evitando de esta manera futuros falsos positivos por el mismo motivo.
Ésta imagen detalla el el proceso en el que estaría involucrado el módulo ICI [402]:
Figura 2.49: Arquitectura de un sistema de detección de intrusiones sin (izq) y con (dch) un
módulo de identicación del contexto de intrusiones (ICI)
1. Todos los eventos procesados por el motor de análisis son copiados al móludo ICI para que
los guarde en un buer de tamaño predenido.
2. Toda alarma generada por el motor de análisis también es enviada al módulo ICI.
3. El módulo ICI extrae el contexto de la intrusión de la alarma, y más adelante lo procesará,
visualizará y/o lo agrupará.
4. El módulo ICI busca contextos de intrusión ya identicados similares.
5. Un experto en seguridad analiza el contexto de la intrusión y decide si la alarma ha sido
un falso positivo o no y el nivel de conanza teniendo en cuenta los contextos existentes.
6. El vector ICI (alarma,decisión,conanza) de la alarma es enviado al motor de análisis y/o
a los sistemas de respuesta.
60
En la detección de intrusiones basada en anomalías, el contexto de la intrusión que corresponde a una alarma,
son las huellas auditadas que se encuentran fuera del modelo normal del comportamiento las que hacen saltar la
alarma
131
7. El motor de análisis ana el modelo de comportamiento normal utilizando el vector obtenido
del ICI para evitar volver a dar el mismo falso positivo.
8. Los sistemas de respuesta activan diferentes estrategias en base al vector ICI.
Otras utilidades para el ICI
Además de la capacidad para reducir los falsos positivos, el módulo ICI puede ser utilizado
como una herramienta para analizar tareas como las que se enumeran a continuación:
1. Para fortalecer la correlación de alertas con las técnicas de detección de anomalías ya que
una alerta no puede determinar consistentemente una intrusión y el contexto de la intrusión
es capaz de mostrar las razones exactas.
2. Para estudiar las características de las intrusiones y mejorar después en base a la información obtenida la eciencia del experto y proponer nuevas técnicas de análisis.
3. Para aplicarlo en otros campos de la intrusión como el estudio forense.
Visualizando y analizando el contexto
Sabemos que las anomalías en una secuencia de llamadas intrusivas estarán indicadas por un
set de secuencias extranjeras. Por tanto sería de gran ayuda visualizar dicha secuencia no propia
del programa en el esquema del ICI. El tamaño de la ventana aplicado para dicha aplicación
también será crítico ya que en el caso de que la secuencia extraña sea mayor que el tamaño de
la ventana, ésta no será totalmente detectada. En los grácos producidos para la visualización
del contexto de la intrusión la longitud de todas las secuencias intrusivas deben ser mostradas
de modo que se conozca si existe la posibilidad de detectarlas completamente o no en base al
tamaño de la ventana. Este tipo de grafo llamado Gráco de secuencias extranjeras o anómalas
[402] (FSG Foreing secuence graph).
Finalmente se deberían tratar de identicar secuencias anómalas mínimas (MFS) y los eventos
con los que están asociadas para que sean identicados como parte del contexto. Para lograrlo,
los datos pueden ser analizados mediante dos métodos:
1. Separando los datos en bloques más pequeños y evaluando cada bloque.
2. Evaluando todo evento que se encuentre en los datos.
El primer método puede llegar a romper las secuencias anómalas, por lo que la utilización del
segundo método es más acertada.
La siguientes imágenes muestran un ejemplo [402] de visualización de un FSG. Los datos
provienen de la Universidad de Nuevo México y también han sido utilizados en [347, 374]
132
Figura 2.50: Set de datos utilizados para el FSG
Para analizar las características de cada intrusión, su set de datos, incluso siendo en el mismo
proceso es tratado como set de datos individual puesto que cada intrusión genera sus propias
características de contexto en los rastros revisados.
Figura 2.51: Ejemplo de FSG para diferentes procesos
133
Para éste gráco FSG, el número de secuencias anómalas en cada set de datos es representativo
y la mayoría de las intrusiones pueden ser detectadas aplicando un tamaño de ventana adecuado.
Otro fenómeno signicativo es que las intrusiones no generan secuencias anómalas en la primera
fase (excepto en la subgura b ). Por ejemplo en la imagen (a), tras 600 llamadas al sistema se
han generado secuencias de llamadas anómalas y esto de alguna forma es indicador de que existe
un periodo de calentamiento para las intrusiones, al menos para aquellas que son detectadas
mediante sistemas basados en anomalías.
Además en las tres instancias de sunsendmail en la subgura (g) se genera el mismo gráco
FSG. Esto quiere decir que tienen las mismas características de intrusión. Al mismo tiempo, para
las diferentes instancias de la misma intrusión en las subguras (a),(c),(f) o (i) sus grácos FSG
también son similares. Este fenómeno puede beneciar investigaciones en las técnicas de detección de anomalías puesto que no es necesario crear técnicas especícas para detectar diferentes
ejecuciones de una misma intrusión.
Para diferentes intrusiones en un proceso, los grácos FSG son diferentes; para el proceso
sendmail desde CERT, el gráco FSG de la intrusión en la subgura (c) es diferente del gráco
FSG para la intrusión sm565a o sm5x en la subgura (d); el gráco FSG de las intrusiones en el
mismo proceso sendmail (e), (f) y sunsendmailcp en la subgura (g) también son diferentes
entre si. Este hecho prueba que no existen estrategias generales para detectar todas las intrusiones
en un proceso, y que las estrategias de técnicas especícas de detección son necesarias para
detectarlas.
Identicando el contexto de las intrusiones: MFSs
Las secuencias anómalas mínimas en los rastros auditados son una de las características
producidas por una intrusión, lo cual es utilizado por detectores de anomalías para detectar la
intrusión. Como se ha mencionado antes, los MFS son el contexto de las alarmas. Basado en
la identicación del contexto de la intrusión en los set de datos, sus estadísticas numéricas son
resumidas en las siguientes tablas:
134
Figura 2.52: Número de Secuencias Anómalas Mínimas (MFS) no duplicadas en todos los set de
datos intrusivos
Figura 2.53: Secuencias Anómalas Mínimas (MFS) compartidas por la misma intrusión en el
mismo proceso
Del número total de secuencias anómalas mínimas en cada set de datos intrusivo, se puede
inferir que:
1. Que con un tamaño de ventana igual a 2, es suciente para detectar la mayoría de las
intrusiones a excepción de la instancia decode-280.
2. Que del gráco Ejemplo de FSG para diferentes procesos mostrado anteriormente y de
las estadísticas de la estancia de la intrusión decode-280, se observa que la longitud
mínima de la MFS es 6. Desde su índice posicional, se puede fácilmente encontrar que
135
éste corresponde a la secuencia 2-95-6-6-95-5. El siguiente listado muestra todas las MFS
acaecidas en las dos instancias decodicadas y las correspondientes llamadas al sistema:
decode-280 / proceso 283: 2-95-6-6-95-5 ; decode-314 / proceso 317: 112-6, 6-19, 2-95-1,
2-95-6-6-95-5.
3. Que las diferentes ejecuciones de una intrusión comparte la mayoría de las secuencias
anómalas mínimas (tabla inferior). Especialmente, las diferentes ejecuciones de sunsendmailcp tienen el mismo set de secuencias anómalas mínimas. Esto es útil para las investigaciones en técnicas de detección de anomalías puesto que la diversidad en diferentes
ejecuciones de la misma intrusión, es limitada por lo que no es necesario desarrollar un
diseño especíco para cada una de ellas. Al mismo tiempo, fortalece la armación de que
los grácos FSG son especícos para cada intrusión y que las diferentes ejecuciones deben
tener las mismas características (contexto de intrusión).
Por último la información de las tablas debería disuadir posibles ataques del tipo mimicry [372] y
del paradigma de ocultamiento de información [348], visto el gran número de secuencias anómalas
mínimas reportadas, en especial, para la intrusión de buer overow.
2.4.9. Modelación de llamadas al sistema mediante ventana deslizante
Este método extiende las primeras investigaciones [126] en la detección de anomalías en
llamadas al sistema para la detección de intrusiones, incorporando tamaños de ventana dinámicos.
El tamaño de la ventana es la longitud de la subsecuencia de una traza de llamadas al sistema
las cuales son utilizadas como la unidad básica para el modelado del comportamiento de una
aplicación o de un proceso. Se presentan dos métodos para la estimación óptima del tamaño
de la ventana basados ambos, en la disposición de datos para el entrenamiento [124]. El primer
método es un modelado de la entropía el cual, determina el tamaño óptimo de la ventana para
los datos. El segundo método es una función modeladora de probabilidad que tiene en cuenta el
contexto para establecer el tamaño de ventana. Un tamaño de ventana dependiente del contexto
está motivado por el hecho de que las llamadas al sistema son generadas por los procesos.
Modelo de entropía
Se puede utilizar un marco teórico de información para escoger el tamaño de ventana óptimo
para las llamadas al sistema. En este marco, se estima cual de los diferentes tamaños de ventana
realizará mejor la ordenación de los datos mediante computación. Una descripción detallada
sobre la aplicación teórica de información a la detección de anomalías es presentada en [10].
La premisa básica para la detección de intrusiones es esa ordenación intrínseca en los datos auditados que es consistente con el comportamiento normal, y distinto del comportamiento
anómalo. Se mostrará empíricamente que cuantos más datos ordenados existen mejor es el rendimiento del modelo de detección de anomalías. El proceso de construcción de un modelo de
136
detección de anomalías debería por tanto involucrar una primera medida de orden de los datos
bajo los diferentes modelos. En este caso, se está interesado en medir la ordenación bajo diferentes
tamaños de ventana. Esta ordenación puede ayudar a elegir el mejor tamaño de ventana.
Para modelar las llamadas al sistema, se usa un modelo predictivo a través del cual la probabilidad the n llamadas al sistema es estimada por las n-1 llamadas previas. La forma en que
la predicción del modelo es entrenada, es que por cada n-1 secuencia de llamadas al sistema
presentes en la traza61 , se mantienen contadores de las siguientes llamadas. La predicción para
una determinada llamada al sistema dada una secuencia de n-1 llamadas previas es, el número
de esa llamada dividido por el número total62 de llamadas. En este punto la longitud n es el
tamaño de la ventana del algoritmo que modela. Se medirá la ordenación de los datos para la
predicción del modelo bajo diferentes valores de n.
Se propone utilizar una medida teórica de los datos para medir la ordenación de los datos,
entropía condicional, para ayudarnos a elegir el valor de n. Cuantos más datos normalizados,
menor entropía.
La denición de la entropía condicional es:
Figura 2.54: Entropía condicional del modelo de ventana deslizante
donde P(x,y) es la probabilidad conjunta de x e y, y P(x|y) es la probabilidad condicional
de x dado y. En el contexto de la llamadas al sistema se deja que
al sistema e
sea el set de llamadas
sea el set de secuencias de llamadas al sistema de longitud n-1. D
será la notación para el total de secuencias en la traza, |(x,y) será el número de veces que se
origina la secuencia en D, y |D| será el total de números de secuencias en la traza. Se puede
denir entonces la probabilidad conjunta como
. La probabilidad condicionada
de P(x|y) es la predicción de éste modelo. Desde que P(x|y) = 0 para una secuencia (x,y) que no
ocurre en la traza y la entropía condicional es aditiva, se puede representar la entropía condicional
para una ventana de tamaño n como63 :
Figura 2.55: Entropía condicional para una ventana de tamaño n
61
Una traza de llamadas al sistema es una secuencia de todas las llamadas al sistema que un proceso de una
aplicación dada realiza durante su tiempo de vida (ejecución).
62
63
Para evitar probabilidades 0, al contador de cada tipo de llamada al sistema se le añade un pequeño valor.
La segunda ecuación puede ser computada de forma eciente
137
Grafo de llamadas de una aplicación
La motivación para una dependencia del contexto del tamaño de la ventana proviene del mecanismo subyacente de cómo un proceso se ejecuta. Las llamadas al sistema en la traza dependen
de la trayectoria en la ejecución del proceso. Asimismo, la trayectoria de un proceso depende de
muchos factores como entradas recibidas o el estado del sistema donde se está ejecutando. Estos
factores determinan que trayectoria de ejecución seguirá el proceso en cada desviación posible.
Se podrían modelar todos los set de las posibles trayectorias de la aplicación utilizando grafos
de llamadas64 . Los grafos de llamadas modelan la estructura de la aplicación y dene las posibles
trayectorias de la ejecución. Cada nodo representa una posible bifurcación del programa, y las
aristas están etiquetados con las llamadas al sistema que se dan entre los nodos. Existe un nodo
de comienzo denido para el grafo y al menos un nodo nal. Es posible observar la trayectoria
de ejecución de un proceso a través de el grafo de llamadas del sistema asociado a éste y por lo
tanto una traza de llamadas al sistema sería simplemente las llamadas al sistema a lo largo de
la trayectoria de ejecución del proceso.
Se debe tener en cuenta que a pesar de que estos grafos existan para todos los programas,
obtenerlos es muy costoso debido a que variarán por el código fuente, por el compilador y por
el sistema operativo empleados. Debido a ésto, es prácticamente inviable asumir que se pueden
recrear los grafos a partir de las llamadas al sistema observadas. Aún no pudiendo determinar
el grafo especíco de llamadas, se puede asumir que éste existe y utilizar ésto para motivar un
tamaño de ventana dependiente del contexto.
En la aplicación del grafo de llamadas al sistema a la detección de intrusiones, existe un set
de trayectorias de ejecución que corresponden a exploits65 . El objetivo del método de modelado
de llamadas al sistema es el ser capaz de determinar si una secuencia de llamadas al sistema
corresponden a una trayectoria de ejecución normal, o si bien pertenece a la trayectoria de
ejecución de un exploit. Hay que tener en cuenta la longitud de la secuencia ha sido ajustada en el
contexto del grafo de llamadas y que con mayor probabilidad una secuencia larga puede identicar
unívocamente una sección del grafo. Sin embargo, es usualmente demasiado larga para ajustarse
a una sola arista por lo que debe abarcar más ramas. Para que estas secuencias sean observadas
varias veces, los estados de los diferentes procesos donde tienen lugar las secuencias más largas
deberán forzar la trayectoria de ejecución para que coincida con estas ramas. Desgraciadamente
ésto puede generar ruido en el modelo.
Por otro lado, las secuencias más cortas abarcan menos ramas, sin embargo, pueden tener
lugar en múltiples puntos del grafo de llamadas resultando complicado determinar unívocamente
dónde surge la secuencia y, por tanto, si ésta pertenece a un trazado normal o a el trazado de
un exploit.
Idealmente, para una secuencia dada se preere escoger aquella que sea la más corta y que
64
65
Es un gráco en el cual cada ruta dene una posible trayectoria de ejecución para un proceso o una aplicación.
Es el nombre con el que se identica un programa informático malicioso, o parte del programa, que trata de
forzar alguna deciencia o vulnerabilidad de otro programa.[2]
138
identique unívocamente la rama del grafo donde se genere. Debido a que los nodos de las ramas
ocurren en lugares diferentes, la longitud óptima de una secuencia depende especícamente de
las llamadas al sistema que ésta contiene. Por lo tanto, la longitud óptima depende del contexto.
La siguiente gura muestra un ejemplo de grafo de llamadas al sistema:
Figura 2.56: Ejemplo de grafo de llamadas al sistema
Sparse Markov Transducers (SMT)
Los SMT[125] son utilizados para modelar trazas de llamadas al sistema estimando una
probabilidad predictiva dependiente del contexto motivada por el marco del grafo de llamadas.
Esta es la probabilidad de predecir la siguiente secuencia de llamadas al sistema dada la secuencia
previa. Una vez que se ha entrenado al modelo desde datos basados en la normalidad de un
proceso, se dispone de una distribución de probabilidad predictiva sobre dicho proceso. En la
fase de evaluación de secuencias de llamadas al sistema para determinar si entran dentro del
rango de la normalidad o si bien pertenecen a una traza generada por la ejecución de un exploit,
se computa cada la probabilidad predictiva para cada secuencia. Si la probabilidad obtenida
está por debajo del umbral establecido entonces la probabilidad de que la secuencia haya sido
originada por el proceso en funcionamiento normal es muy baja y la traza será evaluada como
exploit (anómala). El establecimiento del umbral dene la diferencia entre falsos positivos y el
ratio de detección del sistema
139
Detección basada en grafos N-gramas de llamadas al Sistema
Este tipo de sistemas basados en cadenas de Markov con N-gramas[246], se engloban en el
área denominada como computación inmunológica. para ello basándose en el documento de
Forrest [134] han introducido la idea de los n-gramas para caracterizar el modelo. Para poder
establecer el valor de la N se deben basar los cálculos en la granularidad de las llamadas al kernel,
que puede variar de un sistema operativo a otros.
La caracterización del comportamiento de un programa al igual de lo propuesto por Forrest
se basa en la recogida de segmentos deslizantes de longitud N. Los autores indican que un valor
de N grande implica un coste computacional alto y así mismo, un valor bajo será inválido para
la caracterización del sistema.
Otra de las partes importantes del estudio es la determinación del momento en el que se
puede dar el aprendizaje por nalizado, dado que un aprendizaje incompleto puede llevar a
estimar una tasa de falsos positivos altos. Para poder estimar de forma correcta, durante el
principio del aprendizaje la base de datos crece rápidamente, sin embargo cuando la tasa de
incremento desciende y se hace muy pequeña, se puede decir que la base de datos ha convergido.
En este momento se podrá concluir con que la base de datos es completa y se puede dar por
nalizado el aprendizaje.
Para poder construir la base de datos con cadenas de texto de múltiples longitudes se puede
tener en cuenta las siguientes consideraciones:
1. Se construye el árbol de sujos para los N-gramas de los datos de aprendizaje para algún
valor que sea sucientemente grande de N. N será el límite superior en la longitud de
cadenas multilongitudinales. Una máquina de estados nita (FSM) mediante el algoritmo
two-nger se puede construir de forma inmediata a partir de ese sujo.
2. Se puede compactar el árbol de sujos en un grafo dirigido acíclico mediante la fusión de
subárboles equivalentes.
3. Incluso se pueden llegar a anexar dos subárboles si son muy parecidos introduciendo una
pequeña variación en la forma de compactar.
En general un árbol de sujos para una determinada cadena de caracteres contiene todos los
posibles sujos de la misma, por lo que un árbol de sujos de longitud m tiene m sujos diferentes.
El árbol de sujos para un conjunto de cadenas contiene cada sujo de cada una de ellas. Así
mismo el árbol de sujos para un conjunto de N-gramas puede construirse realizando primero el
árbol de las cadenas de entrenamiento y después entroncando cada rama con la profundidad N
deseada.
140
Figure 2.57: Un árbol de sujos para el ejemplo de la cadena A B C C A B B C C A A B C
Cada nodo en profundidad k < N se denomina k-grama, los nodos hijos de profundidad N se
llaman N-gramas y el nodo raíz se rellena con una cadena vacía. Cada enlace se etiqueta con un
símbolo. Estos enlaces de sujos conectan cada nodo a su sujo apropiado más largo. Los sujos
más largos proporcionan una forma de ir de un N-grama (un nodo hijo) al siguiente N-grama:
Figure 2.58: Árbol de sujos con punteros de sujos incluidos
A veces puede ser necesario incluso incluir un nodo denominado Unknown_symbol (nodo
141
desconocido) para poder contemplar los sucesos que se salgan fuera de lo normal en el modelo
representado por el árbol.
El algoritmo denido como detección de two-nger es como leer la cadena ABCCABBCCABABC con dos dedos de la mano, dejas el dedo de la izquierda jo al principio de la cadena
mientras desplazas el derecho. El desplazar un caracter el dedo derecho es como descender un
nivel en el árbol. Como se requiere que los dedos estén separados como mucho por N letras,
cuando se alcanza este momento se desplaza una posición el dedo de la izquierda, luego si en
la cadena para una longitud de 4 el máximo era ABCC, ahora se tendrá BCC para continuar y posteriormente BCCA. Una anomalía en la cadena de llamadas al sistema requiere un
desplazamiento del dedo izquierdo.
Con esta representación del modelo de cadenas de llamadas al sistema se puede realizar el
mismo desarrollo efectuado por Forrest [134]para el análisis de las trazas del sistema y detección
de anomalías sobre las mismas.
Figure 2.59: Árbol nal resultante de la compresión de la gura anterior
Detección mediante el uso de Autómatas en Línea
Una nueva forma de abstracción en el comportamiento de un programa es la denominada
Inlined Automaton Model (IAM)[293]. Una vez se dene el modelo de comportamiento de
un determinado programa (accediendo al código fuente) se obtiene un grafo como el siguiente
ejemplo:
142
Figure 2.60: Ejemplo de código y representación de representación NFA
Si en base a lo anterior se materializa la forma en la que se ejecuta, como es el caso que se
esta planteando:
Figure 2.61: Ejemplos de implementación de IAM
La monitorización de los programas se basa en las llamadas a las librerías de funciones, con
lo que se tienen que desarrollar un sistema de interposición que se encargue de comparar las
llamadas con el modelo que se tiene. Los mayores problemas que se pueden plantear en este
tipo de situaciones son derivados de la recursividad. El hecho de que el código fuente de un
programa para diferentes casuísticas vuelva sobre sí mismo, deja un campo abierto para que se
tomen por buenas numerosos cambios en el mismo que darían un resultado de comportamiento
normal, teniendo un ataque en ejecución.
143
Figure 2.62: Ejemplo de recursividad y autómata generado.
Figure 2.63: Ejemplo de recursividad indirecta y autómata generado.
La granularidad es importante y un problema a considerar en este tipo de sistemas de detección. Idealmente un IDS debería monitorizar todas y cada una de las sentencias ejecutadas
por el programa en estudio y de esa forma, validar cada instrucción de la máquina. Esto por lo
general no es posible, lo que lleva a afrontar el problema desde diferentes puntos de granularidad:
cuanto más gruesa la aproximación más sencillo será generar un ataque mimicry. Por ejemplo,
restringir exclusivamente los eventos observables a llamadas al sistema, signica que las llamadas
a las librerías no son incluidas en el modelo. Numerosos ataques de buer overow y format
string han acaecido contra las propias librerías instaladas en el sistema operativo.
Detección mediante el uso de Autómatas en llamadas a la pila
Hay otro trabajo[233], que se basa a su vez en autómatas, que incluye en los mismos la
información de la pilla de llamadas. Este modelo se publicita como más potente sobre los que se
basan exclusivamente en secuencias de syscalls, detectando ataques adicionales que los anteriores
no detectan. Este método se basa en el descrito por Feng et al. [131], pero realizando su función
de forma más general. Aun basándose en autómatas de apilamiento de llamadas (HPDA), en vez
de hacer uso de una pila extra como en el modelo de PDA de Wagner and Dean [371], este motor
de análisis se basa exclusivamente en la pila del sistema operativo correspondiente. Cuando se
144
invoca a una syscall, el sistema de detección de intrusiones se activa y comprueba si se puede
pasar del estado en que se encuentra al siguiente. El modelo HPDA, parecido al PDA es una
5-tupla: (S, Σ, T, s, A) donde S es un conjunto nito de estados y Sigma es un conjunto nito
de símbolos denido como Σ = (Y xAddr) ∪ siendo Y = {Entry, Exit, Syscall}y Addr es el
conjunto de posibles direcciones denidas por el programa ejecutable. Las entradas de este tipo
de modelos son de los siguientes tipos:
Entrada. Es un punto de entrada para las llamadas del sistema. La dirección asociada es
la dirección de retorno de esta función.
Salida. Es un punto de salida de una función de llamada del sistema. La dirección asociada
es también la dirección de retorno de esta función.
Syscall es la invocación de una llamada al sistema, donde la dirección asociada es la
dirección de retorno de esta llamada.
es el string vacío.
T es el conjunto de funciones de transición (SxΣ → S)
s es el estado inicial (s ∈ S)
A es el conjunto de estados aceptados (A ⊆ S)
Figure 2.64: Ejemplo de código y modelo HPDA
2.4.10. Modelado de trayectorias de syscalls mediante en análisis del código
fuente
Uno de los inconvenientes a la hora de trabajar con sistemas de detección basados en anomalías del comportamiento normal de las aplicaciones, es que no se dispone de todas las muestras
145
posibles. Ésto tiene como consecuencia que un número, (normalmente muy bajo si el entrenamiento ha sido adecuado), de trayectorias de ejecución no es representado en el modelo creado
y por lo tanto, la posibilidad de generación de falsos positivos66 existe desde un principio. La
razón por la que un entrenamiento puede no se correcto, radica en la dicultad técnica de obtener
todas las trayectorias posibles de una aplicación ya que su comportamiento se captura durante su ejecución. Además en los sistemas basados en anomalías se jan umbrales de normalidad
debido a que pueden existir comportamientos normales que pueden ser tan inusuales como un
comportamiento intrusivo. Mediante esta medida se evita pasar comportamientos intrusivos por
alto, pero en cambio se desligitimiza por segunda vez funcionamientos poco probables aunque
correctos de la aplicación.
Wargner y Dean [371] introdujeron por primera vez la idea de extraer del código fuente de
las aplicaciones un modelo de las trayectorias de ejecución. En ejecución cualquier llamada al
sistema que se desvía del modelo determinado estáticamente es considerada como una intrusión
y por lo tanto debe ser prohibida. Un gráco de llamadas derivado de un gráco de control de
ujo (CFG) es un autómata nito no determinístico (NFA) debido como construye el control en
forma de if − then − else67 y funciones call/return68 . El grado de indeterminismo en un CFG
determina el número de trayectorias imposibles [371] y de esta manera latitud disponible para
los ataques de tipo mimicry [372], los cuales son capaces de evadir los sistemas que inspeccionan
patrones de llamadas al sistema generando los patrones de llamadas que la aplicación secuestrada
debería generar hasta que localizan el tipo de llamada al sistema que necesitan. Wagner [371]
y Gin [194] trataron de utilizar un modelo autómata de apilación inversa (PDA push-down
automaton) para tratar de mitigar el problema de trayectorias imposibles. Aunque el modelo de
PDA es más preciso que el de NFA, incurre en una costosa comprobación en tiempo de ejecución
[371, 194]. Sin embargo el desafío en la prevención de intrusiones basada en llamadas al sistema
es reducir la vulnerabilidad a ataques mimicry al tiempo que se minimiza la sobrecarga en tiempo
de ejecución.
Construcción del modelo de llamadas al sistema
Recientes sistemas de detección[371, 131, 319, 194, 374, 223, 309] denen modelos de comportamientos normal utilizando la actividad realizada en tiempo de ejecución. Los primeros trabajos
como [319, 309] utilizan perles para construir modelos de comportamiento normal. Sin embargo, generar los perles requiere tiempo y puede producir modelos incompletos. La manera más
idónea de construir el modelo es aplicar un análisis estático para extraer patrones de llamadas
66
Un falso positivo se da en el momento que el sistema de detección de anomalías detecta una trayectoria de
ejecución, (traza de llamadas al sistema), y genera una alerta siendo dicha trayectoria no intrusiva, (se encuentra
dentro del comportamiento normal de la aplicación).
67
Sentencias condicionales que en base al resultado de la evaluación de una condición booleana (positivo o
negativo) ejecutan unas acciones u otras.
68
Instrucciones de llamada y retorno a una función. En el retorno se da el control a la siguiente instrucción
desde donde fue hecha la llamada.
146
al sistema de la aplicación.
Figura 2.65: Ejemplo de un programa en C asociado a un modelo de grafo de llamadas (NFA) y
un modelo NDPDA.
La manera más sencilla de extraer un modelo de llamadas es partiendo del grafo de llamadas
propuesto por Wagner y Dean [371], quienes directamente deducen el grafo de llamadas del grafo
de control de ujo (CFG) abstrayendo todo a excepción de las funciones y los nodos de llamadas
al sistema como se muestra en la subgura (B). El CFG resultante es un autómata de estados
no determinista de NFA debido a que las construcciones tales como if − then − else, los bucles
y las funciones son llamadas desde múltiples sitios.
Una limitación en el modelo de grafo de llamadas es el problema de rutas imposibles como es
indicado por la linea intermitente en la subgura (B), la cual surge porque la función f es llamada
desde dos lugares, V y W . El grafo permite una trayectoria imposible {v− > Entrada(f )− >
Salida(f )− > W 0 }, lo cual no es posible. La consideración de este tipo de rutas como posibles tiene como consecuencia que exista una posibilidad para un ataque de tipo mimicry [372].
Por ejemplo, si asumimos que ocurre un ataque por desbordamiento del buer en la función f
en la gura (A), cuando f retorne la ejecución sería transferida al código intrusivo inyectado
mediante el desbordamiento. Al tomar el control, el código intrusivo generaría la secuencia de
llamadas {close(), exec(”/bin/sh”)}, logrando llevar a cabo el ataque pues la secuencia generada
se corresponde con una de las posibles en el grafo (B). Esta limitación de los modelos de grafos
de llamadas es debido al hecho que sólo verica el orden entre llamadas al sistema denidas como
la aplicación, pero no su emplazamiento.
Para eliminar las trayectorias imposibles, Wagner simula las operaciones de pila utilizando un
autómata no determinista de apilación inversa (NDPDA) [371] como se representa en la subgura
(C). La idea clave del modelo NDPDA reside en que cuando se encuentra una llamada desde
V , el estado de retorno correspondiente V 0 es introducido en una pila simulada antes de que el
147
control sea transferido, y es retirado cuando la llamada devuelve el control. Este funcionamiento
asegura que la función siempre retornará al lugar donde ha sido llamada sin importar los lugares
desde donde ha sido llamada. Sin embargo, para cada llamada al sistema entrante, el modelo
NDPDA debe calcular un set de posibles conguraciones de la pila, basándose en las llamadas al
sistema previas. Este set de conguraciones puede crecer indenidamente, especialmente en las
llamadas recursivas. A pesar de un complicado algoritmo para reducir la complejidad del modelo
NDPDA, el peor de los casos en tiempo de ejecución sigue siendo cúbico en la longitud de las
llamadas al sistema. Esto conlleva una alta e inaceptable sobrecarga en tiempo de ejecución para
aquellas aplicaciones que son de tamaño grande.
Los modelos PAID [223] y Dyck [195], utilizan inserciones de llamadas al sistema nulas para
transformar aplicaciones y eliminar el indeterminismo. Sin embargo el modelo Dyck puede producir sobrecargas impredecibles debido a una inserción desmesurada de llamadas al sistema nulas.
Más aun, el modelo Dyck es indeterminista debido a que no inserta llamadas al sistema nulas
en funciones recursivas. El modelo PAID[224], utiliza grafos inline para eliminar el problema de
trayectorias imposibles. Aunque PAID es un modelo determinista el modelo que genera es dos o
tres veces mayor y requiere extensas modicaciones:
Figura 2.66: Proceso de llamada a getuid utilizando el modelo VSL.
Cuando getuid es llamado, el VSL previo es {r1 , r2 , r3 }, el VSL actual es {r1 , r2 , r4 }, y el
prejo de ambos VSL es {r1 , r2 }. Por tanto, tras consumir r3 , el algoritmo pasa el estado actual
de S_setuid a C30 , y después a C4 tras consumir r4 . Finalmente, introduce r4 en la pila y mueve
el estado actual a Entry(f 4) [224].
Feng propuso un modelo estático (VPS) [2], el cual explota el estado de la pila de usuarios para identicar cada lugar de llamada al sistema. Para cada llamada al sistema entrante
extrae todas las direcciones que se encuentren actualmente en la pila para formar una lista
de pila virtual (VSL) y alimentar con ella a un autómata determinista de apilación inversa
o DPDA como se muestra en la gura anterior. Los símbolos de r1 a r4 en el DPDA representan la dirección de la llamada. Asumiendo que el VSL para una llamada al sistema pre-
148
via Sp es {a1 , a2 , ..., a1 , b1, b2, ..., bm }, y el VSL para las llamadas al sistema actuales Sc es
{a1 , a2 , ..., a1 , c1 , c2 , ..., cn }. La secuencia {a1 , a2 , ..., a1 }es un prejo común para los dos VSL.
Sus algoritmos transversales utilizan {bm , bm−1 , ..., b1 } para generar los símbolos de entrada que
simulan operaciones de retorno de funciones, y {c1 , c2 , ..., cn } para generar los símbolos de entrada que simulan operaciones de llamada a funciones. Tras la llamada a getuid en la gura superior
el VSL para getuid es {r1 , r2 }. Asumiendo que el estado actual es S_setuid, el algoritmo utiliza
{r3 } y {r4 } para generar las siguientes operaciones transversales:
1. No consumir nada y mover al siguiente estado Exit(f 3).
2. Sacar un elemento de la pila. Si el elemento en la parte alta de la pila es r3 , mover el estado
a C30 .
3. Consumir r4 y mover el estado a C4.
4. Empujar r4 en la pila y mover hasta el estado Entry(f 4).
5. Mover hasta el estado getuid cuyo contador coincide el contador de programa de la llamada
actual getuid.
Si todas estas operaciones son aceptadas por el modelo DPDA entonces la llamada al sistema
getuid actual es legítima.
Figura 2.67: Proceso de llamada getuid utilizando el modelo VPStatic.
Si getuid no es llamada, el modelo VPStatic no puede aceptar la llamada al sistema setuid
debiado a que el modelo no puede alcanzar el estado S − setuid desde el estado Entry(main). La
función f 1en la subgura de la derecha (B) es llamada dentro de un bucle. El algoritmo VPStatic
actual no puede aceptar la secuencia de llamadas {setuid, getuid, setuid} desde que el algoritmo
sólo retorna al prejo del actual VSL previo.
El modelo VPStatic no puede manejar el indeterminismo debido a las sentencias if − then −
else. Por ejemplo en la subgura superior (A), la llamada al sistema getuid en f 2 no es siempre
149
ejecutada debido a que se realiza dentro de una sentencia if − then − else. Si getuid no es ejecutado, el modelo VPStatic genera un falso positivo cuando setuid es ejecutado. En el momento
que setuid es llamado el VSL previo es {} y el VSL actual es {r1 }. Según el algoritmo, las únicas
operaciones que pueden generar para atravesar el autómata son:
1. Consumir r1 , mover al estado C1
2. Introducir r1 en la pila, mover hasta el estado Entry(f 1).
3. Mover hasta el estado setuid cuyo contador coincide el contador de programa de la llamada
actual setuid.
Obviamente, tras la segunda operación, la tercera no puede ser aceptada por el autómata desde
que C2 es el único estado que se puede alcanzar desde el estado Entry(f 1).
VPStatic también falla al manejar el indeterminismo cuando se efectúan llamadas a funciones
desde bucles, como se muestra en la subgura (B) superior. Además aunque utiliza el estado de
la pila del usuario, no puede prevenir todos los ataques mimicry [224]. Por ejemplo un ataque de
mimicry podría llenar la pila de tal manera que llegaría a engañarle demandando una llamada al
sistema mediante una instrucción trampa, y recuperando el control y repitiendo el mismo proceso.
Esto es debido a que el modelo no tiene en cuenta la dirección de retorno de la instrucción trampa
y el atacante puede obtener el control tras la llamada a la instrucción trampa.
El modelo PAID utiliza una combinación de todas las direcciones de retorno en la pila del
usuario y la dirección de retorno de la llamada trampa que se encuentra en la pila del núcleo como
coordenada unívoca para cada instancia de llamada al sistema en la aplicación. Además utiliza un
algoritmo nuevo de grafo transversal que soporta backtracking69 para tratar con indeterminismos
creados por sentencias condicionales del tipo if − then − else y es tan eciente como el algoritmo
transversal DFA [224]. Finalmente para reducir más aún la vulnerabilidad debido al tamaño
de ventana por parte de ataque mimicry, PAID realiza un extenso y restringido análisis de los
argumentos de las llamadas al sistema, el cual, puede crear restricciones totales o parciales en los
argumentos de llamadas al sistema basado en cheros de conguración. Ésta habilidad, estrecha
los posibles valores de los argumentos en muchas de las llamadas al sistema susceptibles de ser
atacadas, tales como la open().
2.4.11. Solución de instrumentación mediante criptografía
El avance de las llamadas al sistema autenticadas [252] se basa en el hecho de introducir
dentro de misma una serie de parámetros extra: argumentos para control de políticas, argumentos
criptográcos que garanticen la integridad de la política y de los argumentos. Para poder realizar
este tipo de funciones y proteger los sistemas:
69
Es un método de resolución automática de problemas mediante una búsqueda sistemática de posibles solu-
ciones. Las soluciones no válidas se eliminan y no se vuelven a comprobar.
150
1. Transformar los programas para cambiar las llamadas al sistema con llamadas al sistema
autenticadas.
2. Revisión en tiempo real por parte del kernel para asegurar que cada llamada al sistema
esta dentro de la política que le corresponde.
Para empezar, instalación en el sistema, se analiza el binario de un programa por un instalador de
conanza, quien primero generará la política que comprenda el comportamiento de cada llamada
al sistema usando un análisis estático y reescribe el binario de forma que cada syscall contenga
tanto la política como la validación criptográca que necesite.
Figure 2.68: Instalación del programa
El segundo paso, comprobación de la syscall en tiempo real, se realiza por medio de una
intercepción en el kernel, que verica el contenido criptográco utilizado, con lo que si todo es
correcto se permite la ejecución de la llamada y si no se obliga al cierre del programa solicitante.
Figure 2.69: Comprobación de las syscalls
2.4.12. Solución mediante virtualización para terminales móviles
En las especicaciones de seguridad [11] [12] se explican los retos tecnológicos en esta materia para la siguiente generación de dispositivos móviles: medición de la integridad, control
criptográco de acceso para los procesos, autenticación de usuarios, etc. El objetivo es conseguir aumentar la seguridad existente en los dispositivos móviles. El documento [175] se centra
151
en la creación de instancias de sistemas operativos, donde los usuarios son capaces de ejecutar
aplicaciones nativas descargadas de redes libres.
Un dominio (una instancia de Sistema Operativo) es denido como un entorno de ejecución
aislado preparado para un grupo de aplicaciones. Esta separación entre dominios hace posible
la prevención de accesos ilegales al espacio de direcciones de otros dominios y limita la máxima
cantidad de recursos que pueden usar las aplicaciones de un dominio en concreto. Estos dominios
incluso pueden funcionar con diferentes sistemas operativos para terminales móviles: SymbianOS, µ − IT RON , Linux, etc.
La propuesta no se centra en el uso intensivo de recursos hardware como es el caso de los
dominios basados en hardware. La idea es la creación de dominios software, para el que un
software (VMM, Virtual Machine Monitor) se encarga de gestionar los diferentes SO, así como
de compaginar el uso de recursos hardware. Si no que como ni la solución pura de virtualización
por software, ni la solución de implementar todo en hardware son del todo favorables se propone
una mezcla entre ambas aproximaciones. VIRTUS es una nueva propuesta de arquitectura de
un nuevo procesador con arquitectura de virtualización, creando un dominio hardware para
aplicaciones preinstaladas en un procesador y dominios software para aplicaciones descargadas
en otros procesadores para poder satisfacer los siguientes objetivos de diseño:
Seguridad más fuerte. Las aplicaciones preinstaladas en la siguiente generación de terminales móviles deben ser protegidas de las aplicaciones descargadas.
Virtualización exible del procesador. La siguiente generación de terminales móviles requerirá un número alto de dominios para instalar las aplicaciones descargadas. Se requiere
proporcionar en este tipo de sistemas, como en VIRTUS [175], un número ilimitado de
dominios software para los procesadores virtualizados.
Baja degradación en la funcionalidad. Es un requisito que el hecho de tener múltiples
dominios no degrade la funcionalidad del sistema en el trato con diferentes aplicaciones.
Poca interferencia en la funcionalidad. No debe existir interferencia entre las aplicaciones
preinstaladas y las aplicaciones descargadas. Una separación de aislamiento en los procesadores virtuales soluciona el problema, dado que el dominio de aplicaciones preinstaladas
se ejecuta en un procesador diferente que el que se usa para las descargadas, impidiendo la
infección del software original.
Tamaño de código pequeño. Este requerimiento es intrínseco a la capacidad de procesamiento que se puede tener en este tipo de terminales móviles.
152
Figure 2.70: Imagen de la arquitectura de los nuevos procesadores para terminales de tercera
generación
Para poder lograr estos objetivos:
1. una solución puede ser tener máquinas virtuales (VMM) asimétricas a través de las cuales
se pueda integrar el dominio hardware con los dominios software.
Figure 2.71: Comunicación VMM asimétricos
2. Se requiere una comunicación entre dominios que permita que una aplicación corriendo en
un determinado dominio pueda comunicarse de forma criptográcamente segura con otra
aplicación de otro dominio.
153
Figure 2.72: Comunicación dinámica inter-dominio
3. Así mismo debe resultar sencillo el trabajar con la virtualización para realizar desarrollos
efectivos en cuanto a esta tecnología.
Figure 2.73: ID de los registros del procesador lógico virtual
Listing 2.2: Hola esto es una prueba aquí
int
main ( i n t argc , char ∗∗ argv ) {
return
3
0;
}
2.5. Modelos de redes probabilísticas
2.5.1. Modelos de Redes Probabilísticas
Antes de comenzar a ver la denicion intuitiva de este concepto es aconsejable leer el ANEXO
RRBB.1 - Introducción de conceptos.
154
Redes Bayesianas
Denición intuitiva
Una red bayesiana, red de creencia o red de causalidad es una repre-
sentacion graca de las relaciones causa-efecto dentro del dominio de un determinado problema.
Una descripcion mas formal se puede encontrar en [187].
Denicion forma
Partiendo de un conjunto nito de nodos X̄ . Cada uno de ellos representa una variable, que
puede ser discreta o continua, aunque solo se van a manejar variables discretas por ser mas
sencillas. Esta relacion biunivoca entre nodos y variables nos premite emplear indistintamente
ambos terminos. Como se ha visto anteriormente los valores de una variable deben constituir un
conjunto exclusivo y exhaustiva.
Las redes bayesianas no necesitan suponer que los diagnosticos son exclusivos y exhaustivos, y
por tanto no es necesario tener una variable D que represente todos los posibles diagnosticos;
por ejemplo, en vez de una variable llamada D=Enfermedad, cuyos valores representasen los posibles diagnosticos correspondientes a la ebre: neumonia, amigdalitis, paludismo, etc., en la red
bayesiana tendriamos una variable Neumonia que puede tomar dos valores (neumonia-presente y
neumonia-ausente) o mas de dos valores (neumonia-ausente, neumonia-leve, neumonia-moderada
y neumonia-severa), dependiendo del grado de precision que necesitemos en el diagnostico , otra
variable Amigdalitis, Paludismo, etc. De este modo, la red bayesiana puede ofrecer dos o mas
diagnosticos a la vez (por ejemplo, amigdalitis-severa y neumonia-leve), lo cual era imposible con
el metodo probabilista clasico.
En el Anexo RRBB.2 - Denciones previas a las redes bayesianas se introducen ahora algunas
deniciones basicas sobre grafos necesarias para entender la denicion de red bayesiana.
Denicion de red bayesiana
La propiedad fundamental de la red bayesiana es la separacion direccional denida en [186, 187]
como:
Separacion direccional.
Dado un grafo dirigido aciclico conexo y una distribucion de prpobabili-
dad sobre sus variables, se dice que, hay separacion direccional si, dado un nodo X, el conjunto
de padres pa(X), separa condicionalmente este nodo de otro nodo subconjunto Ȳ en que no hay
descendientes de X. Es decir:
P (x|pa(x), ȳ) = P (x|pa(x))
155
Es habitual denir las redes bayesianas a partir de grafos dirigidos aciclicos (en ingles DAG,
de Directed Acyclic Graph). Es importante incluir la especicacion conexo por tres razones.
La primera, porque muchos de los algoritmos y propiedades de las redes bayesianas solo son
correctos para grafos conexos, por lo que es mejor incluir esta caracteristica en la denicion que
tener que añadirla como nota a pie de pagina en casos particulares. La segunda razon es que,
aun en el caso de tener un modelo con dos partes inconexas, podriamos tratarlo como dos redes
bayesianas independientes. Y la tercera, porque los modelos del mundo real con que se suele
trabajar son siempre conexos; si hubiera dos partes inconexas no se tendria uno sino dos modelos
independientes.
En base a todo lo anterior se pueden caraterizar las redes bayesianas, así:
Red bayesiana.
Grafo aciclico dirigido conexo mas una distribucion de probabilidad sobre
sus variables.
El término direccional hace referencia a la asimetria de dicha propiedad, que se maniesta
en las siguientes propiedades de las redes bayesianas:
Si A no tiene padres entoces P (x|pa(x)) = P (x|∅) = P (x) y la ecuacion {b.i.1.b.1} se
traduce en P (e|a) = P (e) para cada nodo E que no sea uno de los descendientes de A; en
otras palabras, E es a priori independiente de A. En consecuencia, dos nodos cualesquiera
D y E que no tengan antepasado comun son independientes a priori.
Si D es descendiente de A y antepasado de H, y existe ningun otro camino desde A hasta
H, entonces estos dos nodos se dice que quedan condicionalmente separados por D:
P (h|d, a) = P (h|d)
Si tanto G como H son hijos de D y no tienen ningun otro antepasado comun este ultimo
separa G y H, haciendo que sean condicionalmente independientes:
P (g|d, h) = P (g|d)
En general, la independencia a priori o condicional de dos nodos se pierde al conocer cualquiera
de sus descendientes comunes, ya que en este caso la propiedad de separacion direccional ya no
es aplicable.
Semántica de las redes bayesianas
Se han denido hasta el momento las redes bayesianas
desde un punto de vista matematico formal. La cuestión que se plantea ahora es su semantica, es
decir, ¾que interpretacion se le puede dar a una red bayesiana? ¾Como se corresponde un modelo
con el mundo real? ¾Por que se puede hablar de causas y efectos en una red bayesiana?
Esta cuestion esta ya parcialmente respondida en la presentacion intuitiva, que fue introducida
antes de la denicion formal de red bayesiana precisamente para mostrar que los conceptos
y axiomas introducidos no pareciesen arbitrarios, sino que responden a las propiedades de la
156
causalidad, segun nuestra concepcion intuitiva del mundo real. Es importante señalar que la
estructura de la red, por si misma, aporta gran cantidad de informacion cualitativa. En efecto,
un arco XY indica, ya antes de conocer el valor concreto de la probabilidad condicional, que
hay una correlacion entre ambas variables: el valor que toma X inuye sobre la probabilidad
de Y , y viceversa. Es lo que se ha dado en llamar inuencia causal directa. Tal es la relacion
que existe, por ejemplo, entre el pais de origen y el paludismo, o entre el paludismo y la ebre.
Profundizando un poco mas, se oserva que la existencia de un camino entre dos variables X e Y
, con variables intermedias Z, indica que hay una inuencia causal indirecta entre ambas.
Tal como se ha discutido en la presentacion intuitiva de las redes bayesianas, cuando el sentido
comun, basado en la experiencia, dice que la inuencia de una variable X sobre uno de sus efectos
Y1 (por ejemplo, del paludismo sobre la prueba de la gota gruesa) no depende de cuales han sido
las causas o mecanismos que han producido X, ni depende tampoco de si X a dado lugar a otros
efectos, entonces la red contendra un arco desde X hasta Y1 , y no habra ningun arco que conecte
Y1 con las demas variables. Por tanto, la ausencia de arcos es tambien una forma de expresar
informacion. El hecho de que Y1 depende solamente de su causa, X, se traduce matematicamente
diciendo que, conocido el valor de X, la probabilidad de Y1 es independiente de los valores que
toman esas otras variables, o dicho de otro modo, X separa Y1 de dichas variables. Se empieza a
ver aqui la relacion entre el concepto de padre y el de causa, entre el de hijo y el de efecto, entre
el de arco y el de inuencia causal directa, entre el de independencia en los mecanismos causales
y el de independencia probabilista.
En este punto es donde se maniesta la importancia del sentido de los arcos y su relacion con
la idea de causalidad. Volviendo al ejemplo del paludismo, el hecho de que las variables Pais-deorigen y Tipo-sanguineo no tengan ningun padre comun signica que son a priori independientes,
es decir, que el pais no inuye en el tipo sanguineo y viceversa, de modo que, si no hay mas
evidencia, no se puedeobtener ninguna informacion sobre el pais de origen a partir del tipo
sanguineo, ni viceversa. Sin embargo, el hecho de que ambas variables tengan un hijo comun
signica que, una vez conocido el valor de ese nodo, surgen correlaciones entre los padres70 . Se
puede decir, usando la terminología de [186], que el camino entre U1 y U2 permanece bloqueado
hasta que sea activado por la llegada de informacion sobre X o sobre alguno de sus descendientes.
Para el caso de los efectos de una variable ocurre precisamente lo contrario: todo medico
sabe que hay correlacion entre la ebre y el test de la gota gruesa. Sin embargo, tal como se
discute en la Dencion Intuitiva, la correlacion desaparece cuando se averigua si el paciente tiene
o no tiene paludismo. Es decir, el camino entre Y1 y Y2 está activado en principio, y se bloquea
solo al conocer el valor de X. De esta asimetria entre padres e hijos, reejo de la asimetría que
existe en el mundo real entre causas y efectos, procede el nombre de separacion direccional. Por
tanto, hay dos formas de justicar los enlaces que se introducen u omiten al construir una red.
La primera es de naturaleza teorica: se forma un modelo causal a partir de la experiencia de un
70
La correlación que aparece entre las causas se aprecia más claramente en el caso de una puerta OR
157
especialista y se trazan los arcos correspondientes al modelo; la relacion que se ha discutido entre
los mecanismos causales y las propiedades matematicas de independencia permite fundamentar
el modelo. El otro camino para justicar la red consiste en realizar una comprobacion empirica
a partir de un conjunto sucientemente amplio de casos, utilizando las herramientas estadisticas
que se emplean habitualmente para detectar correlaciones.
Hay otro punto relativo a la semantica de las redes bayesianas, que se va a mencionar solo
brevemente, pues aun esta muy discutido. Es el que se reere al debate entre los que deenden que
las redes probabilistas pueden expresar causalidad y los que sostienen que estas solo expresan
correlaciones entre variables. En realidad, no se trata de un debate limitado al campo de las
redes bayesianas, sino que la existencia de la causalidad es una cuestion que se han planteado
matematicos y losofos por lo menos desde el siglo XVII, a partir de las teor1as de Hume.
Para no entrar en esta cuestion se citaran solamente tres trabajos, los de [188] y [397] y el de
[113], que muestran como recientemente han surgido argumentos matematicos para defender la
interpretacion causal frente a la meramente correlacional.
En resumen, lo que se ha intentado mostrar en esta seccion es que la informacion cualitativa que expresa la estructura de una red bayesiana es mas importante aun que la informacion
cuantitativa, como lo demuestra el hecho de que se han construido redes cualitativas [273, 274],
capaces de razonar a partir de las propiedades de independencia de las redes bayesianas, incluso en ausencia de valores numericos. Por este motivo, [3] ha sugerido en nombre de redes de
independencia (independence networks) como el mas adecuado para las redes bayesianas.
Propagacion en poliárboles
El algoritmo para poliárboles que se presenta en esta sección,
basado en el paso de mensajes π yλ fue desarrollado por [153] a partir del que Pearl había
propuesto para árboles en [185]. Sin embargo, la principal limitación del algoritmo de Kim y
Pearl es que no permite tratar los bucles que aparecen inevitablemente al desarrollar modelos
del mundo real, por lo que en sí mismo resulta de muy poca utilidad y los constructores de
redes bayesianas. Recurren a otros que, aun perdiendo las ventajas de éste, son aplicables a
todo tipo de redes bayesianas. Sin embargo, aquí se va a estudiar con detalle por dos razones.
Primera, por su sencillez y elegancia, que permitirá comprender mejor las propiedades de las redes
bayesianas. Y segunda, porque el algoritmo de condicionamiento local [114], aplicable también
a redes múltiplemente conexas, es una extensión de éste, que se basa en los mismos conceptos y
deniciones. Para comprender mejor el desarrollo matemático que se va a realizar, puede ser útil
al lector repasar la dencion intuitiva, en que aparecen sencillos ejemplos numéricos que explican
por qué se introducen las deniciones de π y λ cómo se propaga la evidencia.
Una de las propiedades fundamentales de un poliarbol es que hay un unico camino entre cada
par de nodos. En consecuencia, la inuencia de cada hallazgo se propaga hasta un nodo X bien
a traves de los padres o a traves de los hijos de éste, por lo que para cada nodo X se pude hacer
una particion de la evidencia (o conjunto de hallazgos) en dos subconjuntos tales que:
158
e = e+
X ∪ eX
e+
X ∩ eX = ∅
Donde e+
X representa la evidencia por encima de X y eX la evidencia por debajo de X
en el sentido antes mencionado. De forma similar, la eliminacion de un enlace XY divide la red
y por lo tanto tambien la evidencia- en dos partes, una que se queda por encima del enlace
y otra que queda por debajo. Se llamaran e+
XY y eXY respectivamente. Al igual que en el caso
anterior se cumple que:
e = e+
XY ∪ eXY
e+
XY ∩ eXY = ∅
En base a la particion de evidencia podemos establecer las siguientes denciones:
π(x) ≡ P (x, e+
X)
λ(x) ≡ P (e-X |x)
πX (ui ) ≡ P (Ui , e+
Ui X )
λYi (x) ≡ P (e-XY j |x)
Figura 2.74: Esquema de la propagación en poliárboles
El sentido de estas denciones es el siguiente:
1. π(x) indica qué valor de X es mas probable según la evidencia relacionada con las causas
de X, es decir, segun la evidencia por encima de X.
2. λ(x) Indica que valor de X explica mejor los hallazgos correspondientes a los efectos de X,
es decir, la evidencia por debajo de X.
159
3. πX (u) Indica qué valor de U es mas probable según la evidencia por encima del enlace
UX.
4. λYi (x) Indica qué valor X explica mejor la evidencia por debajo del enlace XY.
Antes de concluir esta seccion es conveniente señalar que las denciones anteriores, aunque
tomadas del libro de Pearl [187] se han modicado de acuerdo con la propuesta de [278].
Un caso particular: Redes tipo Naive
Introducción
Los modelos bayesianos Naive (red naive a partir de ahora) se denominan naive (ingenuo) por
la hipótesis de la que parten. Son utilizadas extensamente en la clasicación de muestras de
todo tipo [22, 284, 245], llegando incluso a plantearse estructuras jerárquicas en su interior:
Augmented Naïve Bayes [61]. Hay numerosos estudios actuales para la aplicación y solución de
problemas más complejos mediante creación de Redes en Árbol Aumentadas (TAN), Multiredes
autónomas en las ramas, redes selectivas y variantes parecidas [135, 145, 67].
Una de las aplicaciones más usadas es la gestión de Spam en correos electrónicos mediante una
clasicación de textos, tras una temporada de aprendizaje se observan unos resultados
perfectamente válidos con una baja tasa de error71 .
Se pueden encontrar aproximaciones que indagan en la aplicación de esta algorítmica en aras
de la Seguridad en base a Anomalías [318]. Las redes activas72 pueden proporcionar una solución
real a la problemática de seguridad haciendo un uso cooperativo de los recursos para análisis por
medio de diferentes técnicas. En este caso se trataría de clasicar como normal o como anómalo
los sucesos que se ocasionan en tiempo real dentro de una red corporativa.
Siguiendo en la línea de seguridad hay otros trabajos que siguen en la línea de clasicación,
pero esta vez en base a determinados parámetros de los paquetes (datagramas / segmentos) o
incluso del contenido de los mismos (ejecutables, imágenes . . . ). Un ejemplo se puede ver en la
referencia [176].
Otras aproximaciones que hacen uso de este tipo de redes pueden ser aquellas en las que se
trata de clasicar un tipo de comportamiento en base a eventos. Estas aproximaciones tienen en
cuenta una serie de parámetros, y en base al valor que tomen los mismos, pueden decidir si el
comportamiento es anómalo o dentro del margen normal [217].
71
SpamBayes, proyecto localizado en la sede web: . Solución para el reconocimiento de spam en correo electrónico
iniciada por Paul Graham.
72
Redes caracterizadas por poder dirigir el ujo de información a través de diverso hardware programable por
sus usuarios o terceras partes.
160
Explicación en detalle
Las redes Naïve Bayes parten de la hipótesis de que cada variable Xi es condicionalmente
independiente del resto dado un cluster de varibles con el mismo padre C. Mediante esta
hipótesis la distribucion de probabilidad se puede representar ecientemente como el producto
de varias distribuciones más simples:
n
P (X1, X2, ..., Xn , C) = P (c)P (xi |C)
i=1
Una red naive es un caso especial de red bayesiana sobre las variables X1, ..., Xn y C, en la
que el padre de cada variable Xi es C y C no tiene padres. El aumento eciencia viene por el
uso de esta estructura restringida.
Para el uso más común, la clasicacion, se tiene que C representa la clase que se debe predecir
y Xi representan los atributos observables. Por ejemplo, en un ltro naive anti-spam, la C puede
represntar la clase spam y no-spam y Xi puede representar si la i-esima palabra está presente
en el mail tratado. Las distribuciones componentes se pueden aprender a partir de datos de
entrenamiento simplemente mediante el conteo de las ocurrencias de una palabra en las etiquetas
spam y no-spam. En este ejemplo, así como en muchas aplicaciones de las redes naive la
hipotesis ingenua es claramente falsa: las palabras presentes en un email depende de otras
tanto en spam como en email legitimos. Sin embargo, estos modelos tienden a realizarse bien en
la práctica y el análisis teórico ha demstrado que es óptimo [111].
Naive Bayes tambien se utiliza en el clustering, donde el objetivo es aprender la estructura
subyacente de los datos. Al contrario que en la tarea de clasicacion, C representa una variable
cluster que nunca se observa directamente. En muchos casos el numero de clusters presentes es
desconocido y se debe inferir [66].
Los modelos de clustering normalmente se aprenden mediante el algoritmo EM en un proceso
iterativo que consta de dos pasos como explica [104] y más adelante en esta memoria.
La estimacion Naive Bayes es la aplicación de los modelos naive Bayes a los problemas
generales de aprendizaje e inferencia, el caso de la inferencia se explica más adelante.
Hasta aquí se ha realizado una presentacion de lo que son las redes bayesianas como concepto, a partir de este punto se procede a describir las potentes funcionalidades de este articio
matematico.
Adicción y eliminación de nodos en caliente.
Con la ayuda de un experto en la materia, J.M. Gutierrez se plantea la siguiente evolución de
una red naive. Si se tiene de partida una red como la siguiente:
161
Figura 2.75: Ejemplo de red naive
La probabilidad para la clasicación en función de los dos nodos que aparecen en la gura es
la que sigue:
P(Padre) = P(Padre_a_priori) · P(Hijo1 / Padre) · P(Hijo2 / Padre)
Caso de que se quiera quitar un nodo dejando la red Naive con sólo un hijo, para calcular el
estado del padre en todo momento se tendría en cuenta únicamente la parte de la red de la que
se disponen datos:
Figura 2.76: Ejemplo de sustración de nodos en red Naive
P(Padre) = P(Padre_a_priori)· P(Hijo1 / Padre)
Igualmente, caso de que se quiera añadir un hijo más para el cómputo correspondiente del
estado del padre:
162
Figura 2.77: Ejemplo de adición de un nodo a una red Naive
P(Padre)=P(Padre_a_priori)·P(Hijo1/Padre)·P(Hijo2/Padre)·P(Hijo3/Padre)
Aprendizaje
Introducción al aprendizaje en redes bayesianas
Existen dos tipos de aprendizaje:
Estructural, que se reere al aprendizaje de la estructura (dependencia) gráca del grafo,
es decir, determinar las aristas a incluir en el grafo.
Paramétrico, que se reere al aprendizaje de la estructura parametrica, es decir, probabilidades. En el leguaje de los estadisticos, el aprendizaje parametrico se denomina estimacacion.
En este punto se van a explicar en detalle ambos tipos de aprendizaje asi como los algoritmos
usados en ESIDE-Depian para implementarlos.
Por otro lado, según [57] todo método de aprendizaje consta de 2 elementos:
Una medida de calidad, que se utiliza para decidir cual es mejor de un conjunto de redes
bayesianas candidatas. Esto es una media global de la calidad, ya que mide la calidad de
la red bayesiana en su totalidad, es decur ambas, la calidad de la estructura graca y la
calidad de los parametros estimados.
163
Un algoritmo de busqueda, que se usa para seleccionar un pequeño subconjunto de redes
bayesianas de alta calidad, del que se selecciona el mejor. Hay que darse cuenta que de
todas las posibles redes, incluso para un pequeño numero de variables , es extremadamente
grande y es virtualmente imposible determinar la calidad de todas las redes posibles.
Tambien en [57] se establecen las siguientes etapas para el aprendizaje estructural y
paramétrico:
Elegir la medida de calidad y el algorimo de busqueda.
Utilizar un algoritmo de busqueda para seleccionar un subconjunto de redes bayesianas
con calidades altas. Esto requiere estimar los parametros de las redes seleccionadas usando
metodos de estimacion y evaluando las calidades de todas las redes bayesianas en el conjunto
elegido.
Por ultimo, seleccionar la estructura de la red con mayor calidad del conjunto anterior.
2.5.2. Aprendizaje Estructural
El consiste en la obtencion de la estructura de la red bayesiana, es decir, los nodos y los enlaces
entre los nodos o de una forma más formal, consiste en obtener las relaciones de dependencia e
independencia de las variables involucradas [130].
Existen dos aproximaciones basicas al aprendizaje estructural:
Test de indepencia
Puntuación y procedimientos de búsqueda.
Existen multitud de algoritmos para este tipo de aprendizaje de los cuales se han utilizado los
siguientes:
Algoritmo PC
Este es un algoritmo basado en test de independencia desarrollado por [326] y que pertenece a
la clase de algoritmos basados en restricciones. La idea basica del algoritmo es desarrollar una
serie de declaraciones condicionales de dependencia e independencia mediante tests estadisticos.
El algoritmo realiza los siguientes pasos:
En primer lugar realiza una serie de test de independecia para todos los para de variables,
expecto para las que se haya denido algun tipo de restriccion estructural.
164
Posteriormente añade un enlace entre cada par de variables para las que no encuentra independecia condicional. El grafo resultante constituye el esqueleto de la estrucutura aprendida.
Seguidamente identica los colideres, asegurandose que no se dan ciclos dirigidos. (un
collider es un par de enlaces dirigidos tal que se encuentran en el mismo nodo).
Despues se hacen cumplir las direcciones para aquellos enlaces cuya dirección se puede
derivar de la independencia condicional encontrada y los colliders identicados.
Finalmente, los enlaces no dirigidos restantes se dirigen de forma aleatoria, aseguranado
que no se producen ciclos.
Hay que darse cuenta de una cosa muy importnte; y es que, en general, este algoritmo no es
capaz de derivar la direccion de todos los enlaces a partir de los datos y por lo tanto algunos
enlaces los dirige de forma aleatoria.
Mejora del Algoritmo PC, el algritmo NPC
NPC signica condicion de ruta necesaria y es un criterio desarrollado por investigadore s
de Siemens en Munich para resolver algunos problemas de los algoritmos basados en restricciones como el algoritmo PC. Basicamente PC y NPC son iguales en su funcionamiento (ambos
construyen el esqueleto de la red en bases a test de independencia).
NPC trata de reparar las deciencias del algoritmo PC y que ocurren espcialmente cuando
se usan conjuntos de datos incompletos. La solucion propuesta por el algorimo NPC se bsa en
la inclusion de un criterio conocido como condicion de ruta necesaria73 . Este criterio es la base
para introducir la nocion de regiones ambiguas74 que proporcionan un lenguaje para la seleccion
entre conjuntos de enlaces interdependientes e inciertos.
En los algoritmos basados en restricciones, el esquleto del gráfo se construye mediante la no
inclusion de un enlace en la gráfo siempre que los nodos correspondientes sean condicionalmente
independientes. Puede, sin embargo, haber incosistencias entre el conjunto de independicia condiconal y las condiciones de dependencia originadas por el uso de un conjunto de datos limitado.
Es decir no todas las condiciones se pueden representar a la vez.
El número de inconsistencias en el conjunto de condiciones reejan el gradod e incertidumbre
del modelo estructural. Por lo que, el numero de incertezas es un medida suciente como para
saber si el aprendizaje se realizo consuencientes datos o no. Las condiciones incosnsitentes
producen multples soluciones a la hora de inducir un grafo aciclico dirigido.
73
Informalmente, esta condicion dice que el orden de dos variables X e Y debe ser condicionamente independiente
de un conjunto S; es decir, debe existir una ruta entre X y cada Z perteneciente a S (que no atraviese Y) y entre
cada Y y cada Z de S (que no atraviese X). Si no, la inclusion de Z en S es inexplicable. Por lo que, para que la
declaracion de independencia sea valida, se requiere un numero de enlaces en el grafo.
74
Cuando la ausencia de un enlace, a, depende de la presencia de otro enlace, b, y viceversa, se deene a y b
para ser interdependientes. Tanto a como b constituyen lo que se llama enlaces inciertos. Una region ambigua es el
maximo conjunto de enlaces interdependientes. Es decir, una region ambigua es un conjunto de enlaces inceirtos.
El objetivo principal es obtener tan pocas y tan pequeñas regiones ambiguas como se pueda.
165
Algoritmo Hill-Climbing
Una descripción intuitiva de Hill-Climbing se puede encontrar en probablemente sea el
algoritmo de busqueda local mas conocido. La idea que subyace en este algoritmo es la
siguiente: empezando en un estado generado aleatoriamente; moverse al estado vecino con
mejor valor; reiniciandose, a otro estado aleatorio, cada vez que se alcanza el mimino local. Este
proceso se repite hasta que se encuentra la solucion. Hill-Climbing, por lo general, mantiene un
parametro llamado Max-Flips que se usa para limitar el numero de movimientos entre
cada reinicio, lo que ayuda a dejar minimos locales no estrictos. El hecho de que tenga que
explorar todos los vecinos del estado actual antes de realizar el siguiente movimiento, se debe
tener en cuenta, puesto que lleva cierto tiempo [5, 314].
El algoritmo Hill-Climbing es un algoritmo de descenso, de sencilla implementación y gran
robustez, que dada la repetitividad de su método de búsqueda permite contrastar resultados. La
dirección de búsqueda se hace de forma exhaustiva calculando todas las posibles direcciones, y
eligiendo aquella que consigue un mayor descenso. Para n variables z = (z0, z1,..., zn−1 ) se ensayan
2n formas [71]:
z1 = (z0 + s, z1,..., zn−1 ), z2 = (z0 − s, z1,..., zn−1 ), ..., z2n−1 = (z0, z1,..., zn−1 + s), z2n =
(z0, z1,..., zn−1 − s)
donde s toma valores arbitrarios. Tipicamente, se realizan varios escalones , asignando a s
valores decrecientes en los sucesivos escalones. Una vez alcanzada una situacion de equilibrio para
un determinado escalon (cuando ninguna direccion de busqueda proporciona una solucion que
mejore a la actual, cuando la mejora es menor que un cierto valor minimo, o cuando se alcanza
un maximo de busquedas), el proceso se repite para el siguiente escalon k+1 en el que se aplica
un salto s menor.
La tendencia a obtener minimos locales es el principal problema de este algoritmo, que se
debe al caracter descendiente del coste denido por los criterios de aceptacion del algoritmo, y
que depende en gran medida de la solucion de partida.
La descripción en forma de algoritmo se puede encontrar en [WIKIPEDI05].
Algoritmo Bayesian Information Criterion (BIC)
BIC se ha convertido en un criterio para la seleccion de modelos popular en los ultimos años.
BIC trata de proporcionar una medida del peso o el factor bayesiano de una evidencia que
favorece a un modelo sobre otro. Tiene, sin embargo, algunas desventajas importantes que
normalmente no son reconocidas [91].
Primero, los factores de Bayes dependen de la creencia previa sobre los valores esperados de
los parametros de la distribucion y no existen garantias de que el factor de Bayes, implicado
por BIC, vaya a hacer que este proximo a uno de los calculados previamente.
166
Segundo, para obtener los factores de Bayes que siguen desde BIC, los investigadores deben
variar la ditribucion previa dependiendo de la distribucion marginal de las variables y de
la naturaleza de las hipotesis. Dichas variaciones parecen injusticables, en prinicipio, y
tienden a hacer que BIC se incline a modelos excesivamente simples en la práctica.
Un modelo de mezcla nita se caracteriza por tener un numero de componentes K y un vector
de parametros θ = (p1,..., pK , λ1,..., λK ) . Una forma clasica de elegir un modelo es seleccionar
aquel que maximice la probabilidad integrada [4]:
b = arg(max f (x|m, K))
(m,
b K)
m,K
donde la probabilidad integrada es:
f (x|m, K) =
R
Θm,K
f (x|m, K, θ)π(θ|m, K)dθ
con la probabilidad:
f (x|m, K, θ) =
Qn
i=1 f (xi |m, K, θ)
y siendo Θm,K el parametro que representa el espacio del modelo m con K componentes y
π(θ|m, K) una distribucion debil o con poca informacion en θ para este modelo. Swarz propuso
una aproximacion asintotica de la probabilidad integrada, valida en condiciones normales:
b −
log f (x|m, K) ≈ log f (x|m, K, θ)
vm,K
2
log(n)
donde θb es la estimacion ML (Maximum-Likelihood) de θ
θb = argmax f (x|m, K, θ)
θ
y vm,K es el numero de parametros libres en el modelo m con K componentes. Esto lleva a
minimizar el supuesto criterio BIC:
BIC m,K = −2Lm,K + vm,K ln n
b es la maxima log-likelihood para m y K.
donde Lm,K = log f (x|m, K, θ)
Aprendizaje Paramétrico
El aprendizaje paramétrico consiste en encontrar los parámetros asociados a una estructra dada
de una red bayesiana. Dichos parámetros consisten en las probabilidades a priori de los nodos
raíz y las probabilidades condicionales de las demás variables, dados sus padres. Si se conocen
todas las variables, es fácil obtener las probabilidades requeridas. Las probabilidades previas
corresponden a las marginales de los nodos raíz, y las condicionales se obtienen de las conjuntas
de cada nodo con su(s) padre(s). Para que se actualizen las probabilidades con cada caso
observado, éstas se pueden representar como razones enteras, y actualizarse con cada
observación.
167
Aprendizaje Paramétrico en modelos discretos
La explicacion de este tipo de aprendizaje se realizara con un ejemplo. Supongase que se
compra una bolsa de caramelos de limon y de cerazas de un nuevo fabricante y de los que se
desconoce tolmente las proporciones de cada uno de ellos. En este caso se tiene una serie de
hipotesis continuas. El parametro en este caso, llamado θ , es la proporcion de caramelos de
cereza, y las la hipotesis es hθ . (La propocion de caramelos de limon es (1 − θ) ). Si se asume
que todas las proporciones iguales a priori, entonces la aprocimacion Maximum-likelhood es
razonable. Si se modela esta situacion mediante una red bayesiana, se necisita una variable
alatoria, Flavor (que representa el sabor de un caramelo extraido aleatoriamente de la bolsa).
Esta variable tiene los valores cereza y limon, donde la probabilidad de cereza es θ . Ahora se
supone que se tiene N caramelos sin envoltorio, de los cuales c son de cereza y |l = N − c| son
de limon. De esta forma la funcion de probabilidad es:
N
P (d|hθ ) = Π P (dj |hθ ) = θc (1 − θ)l
j=1
La hipotesis de maximum-likelihood viene dada por el valor de θ que maximiza esta expresion.
El mismo valor se obtiene maximizando el log-likelihood,
L(d|hθ ) = log P (d|hθ ) =
N
P
log P (dj |hθ ) = c log θ + l log(1 − θ)
j=1
Mediante algoritmos se reduce los productos a sumas de los datos , que normalmente es mas
facil de maximizar. Para encontrar el valor maximum-likelihood de θ , se diferencia L con
respecto θ e igualando la expresion resultante a 0, de la siguiente forma:
dL(d|hθ )
dθ
=
c
θ
−
l
1−θ
=0→θ=
c
c+l
=
c
N
Hasta aqui se ha reproducido el metodo de maximum-likelihood para el aprendizaje
parametrico, que en resumen consiste:
Escribir un expresion de probabilidad para los datos en funcion de los parametros.
Calcular la derivada del log-lokelihood para cada parametros
Encontrar el parametro cuya derivada es 0.
El ejemplo mostrado hasta aqui ilustra un problema importante del aprendizaje
maximum-likelihood en general: cuando el conjunto de datos es tan pequeño que algunos
eventos no se han sido observados -por ejemplo, que no hay caramelos de cereza- este
metodo asigna probabilidad 0 a estos eventos. Para evitar esto, se utilizan algun truco
como incializar el conteo de los eventos a 1 en vez de a 0.
168
Los resultados que proporciona este metodo son buenos y es facil comprobar que se puede
extender a cualquier tipo de red bayesiana cuyas probabilidades condicionales se representen
como tablas.
El punto mas imporante es que con datos completos, el problema del aprendizaje parametrico con maximum-likelihood en una red bayesiana se descompone en problemas separados,
uno para cada parametro. Otro punto importante es que los valores del parametro para
una variable, dados sus padres, son simplemente las frecuencias observadas de los valores
de las variables para cada conguracion de los valores de los padres. Como antes, se debe
tener cuidado con los cero cuando los conjuntos de datos son pequeños.
Existe aprendizaje parametrico para modelos continuos, pero como en el presente
proyecto no se hace uso de este tipo de modelos no se van a comentar; tan solo se
comenta que sique los mismos principios que el aprendizaje en modelos discretos.
Aprendizaje Paramétrico bayesiano
El aprendizaje maximum-likelihood da lugar a procedimientos de aprendizaje muy simples,
pero tiene serias deciencias en el tratamiento de conjuntos de datos pequeños. Por ejemplo,
siguiendo con el ejemplo de los caramelos, la hipotesis maximum-likelihood es que la bolsa tenga
el 100 % de caramelos de cereza ( θ = 1,0 ). A menos que la hipotesis previa sea que la bolsa
debe contener tanto todos los caramelos de limon o todos de cerezas, esta no es una conclusion
razonable. La aproximacion bayesiana para el aprendizaje de parametros establece una hipotesis
previa sobre los posibles valores de los parametros y actualiza la distribucion segun llegan los
datos.
El ejemplo de los caramelos tiene un parametros θ : la probabilidad de que un caramelo
cogido al azar sea de cereza. Desde el punto de vista bayesiano, θ es el valor (desconocido) de la
variable Θ ; la hipotesis previa es simplemente la distribucion previa P (Θ) . Por lo que P (Θ = θ)
es la probabilidad previa de que la bolsa tenga θ caramelos de cereza.
Si el parametro θ puede tener cualquier valor entre 0 y 1, entonces P (Θ) debe ser una
distribucion continua distinta de 0 solo entre 0 y 1 y que integra a 1. La densidad uniforme
P (θ) = U [0, 1](θ) es un candidato. Resulta que la densidad uniforme es un miembro de la familia
de la distribuciones beta. Cada distribucion beta se dene por dos hiperparametros a y b tales
que:
beta[a, b](θ) = αθa−1 (1 − θ)b−1
La constante de normalizacion depende de a y b. El valor medio de la distribucion es , por lo
que valores mas grandes sugieren la creencia de que esta mas cercano a 1 que a 0. Valore mayores
de a +b hace la distribucion mas escarpada, sugiriendo una gran certeza sobre el valor de . Por lo
que, la familia beta proporciona un intervalo util de posibilidades para las hipotesis previa.]para
169
θ en el intevalo [0,1]. La constante de normalizacion α depende de a y b. El valor medio de la
distribucion es a/(a + b) , por lo que valores mas grandes sugieren la creencia de que Θ esta mas
cercano a 1 que a 0. Valore mayores de a +b hace la distribucion mas escarpada, sugiriendo una
gran certeza sobre el valor de Θ . Por lo que, la familia beta proporciona un intervalo util de
posibilidades para las hipotesis previa.
Anterior, entonces, despues de observar un punto de referencia la distribucion posterior de
tambien es una distribucion beta. A la familia beta tambien se la llama conjugada previa para la
familia de distribuciones de variables booleanas. A continuacion se ve como trabaja, mediante el
ejemplo de los caramelos:]Ademas de su felxibilidad la familia beta tiene otras propiedades interesantes: si Θ tiene una beta[a, b] anterior, entonces, despues de observar un punto de referencia
la distribucion posterior de Θ tambien es una distribucion beta. A la familia beta tambien se la
llama conjugada previa para la familia de distribuciones de variables booleanas. A continuacion
se ve como trabaja, mediante el ejemplo de los caramelos:
P (θ|D1 = cereza) = αP (D1 = cereza|θ)P (θ)
=α' θ·beta[a, b](θ) = α' θ·θa−1 (1 − θ)b−1
=α' θa (1 − θ)b−1 = beta[a + 1, b](θ)
Previa se comporta exactamente como si se hubiera iniciado todo el proceso con una beta[1,1]
previa uniforme habiendo visto a-1 caramlelos de cereza actuales y b-1 caramelos de limon actuales. Así, despues de ver un caramelo de cereza, tan solo se incrementa el parametro a para obtener
la probabilidad anterior; de forma similar despues de ver un caramelo de limon, se incrementa
el paraemtro b. Asi, se puede ver que los hiperparametros a y b como contadores virtuales, en
el sentido de que la beta[a, b] previa se comporta exactamente como si se hubiera iniciado todo
el proceso con una beta[1,1] previa uniforme habiendo visto a-1 caramlelos de cereza actuales y
b-1 caramelos de limon actuales.
Mediante el examen de la secuencia de distribuciones beta para el incremento de los valores a
y b, manteniendo las proporciones jas, se puede ver directamente como la distribucion posterior
sobre el parametro Θ cambia segun llegan los datos. Por ejemplo, si se supone que en la bolsa
actual hay un 75 % de caramelos de cereza. La distribucion converge, claramente, a un pico al
rededor del valor de verdad de Θ . Para conjuntos de datos grandes el aprendizaje bayesiano
converge para dar los mismos resultados que el aprendizaje maximum-likelihood.
Si se utilizan tres parametros θ, θ1, θ2 donde θ se ha visto anteriormente lo que es, θ! es la
probabilidad de que los caramelos de cereza tengane envoltorio rojo y θ2 la probabilidad de que
los caramelos de limon tengan envoltorio rojo. La hipotesis bayesiana previa debe cubrir los tres
parametros completamente -es decir, necesitamos especifocar P (Θ, Θ1, Θ2 ) . Normalemente se
asume independencia de parametros:
P (Θ, Θ1, Θ2 ) = P (Θ)P (Θ1 )P (Θ2 )
Con esta asunción, cada parametro puede tener su propia distribucion beta que se actualiza
separadamente segun
170
llegan los datos.
Una vez que se tiene la idea de que los parametros desconocidos se pueden representar variables aleatorias como Θ , es natural incorporarlas a la red bayesiana. Para hacer esto, tambien
se deben hacer copias de las variables que describen cada caso. Por ejemplo, si se observan 3
caramelos entonces se necesita Sabor1, Sabor2, Sabor3 y Envoltorio1, Envoltorio2, Envoltorio3.
El parametro variable Θ determina la probabilidad de cada varibale Sabori :
P (sabor i = cereza|Θ = θ) = θ
De forma similar la probabilidades de envoltorio dependen de Θ1 y Θ2 . Por ejemplo:
P (Envoltorio i = rojo|Sabor i = cereza, Θ1, θ1 ) = θ1
Ahora el proceso de aprendizaje bayesiano se puede formular como un problema de inferencia
en una reb bayesiana contruida convenientemente. La prediccion para una nueva instancia se
realiza median la incorporacion nuevas variables de la instancia a la red, algunas de las cuales son
encoladas. Esta formulacion del aprendizaje y la prediccion meustra claramente que el aprendizaje
bayesiano no requiere de ningun principio de aprendizaje extra.
Aprendizaje paramétrico secuencial
Este tipo de aprendizaje es interesante, sobre todo, en situaciones en las que el proceso de
aprendizaje no puede almacenar todas las observaciones pasadas en la memoria principal [136].
El aprendizaje/adaptación secuencial se puede denir como la capacidad crucial de un sistema
para corregir los errores del modelo inicial y poder adaptarse a los cambios en la distribucion
subyacente [34]. Este tipo de aprendizaje es interesante, sobre todo, en situaciones en las que el
proceso de aprendizaje no puede almacenar todas las observaciones pasadas en la memoria
principal [136].
Distingue esto del entramiento y prere llamarlo adaptación. En este punto es interesante hacer
una distrincion entre la generacion del modelo inicial y la revision de los parametros que ya
existen en el modelo. Existen dominios donde hay sucientes datos disponibles para aprender
los parametros de la red a patir de una base de datos. Se puede defnir esta actividad como
entrenamiento. Sin embargo, el caso más normal es tener que usar una combinacion de
conocimiento experto y datos estadisticos para obtener los parametros requeridos. En este
punto alguien puede querer usar los datos recibidos para revisar los parametros de la red; los
parametros inicialmente se pueden precisar de forma imprecisa o, incluso, de forma incorrecta.
[266] distingue esto del entramiento y prere llamarlo adaptacion.
Cuando la muestra de entrenamiento aumenta y se requiere una actualizacion rapida e
incremental de la red bayesiana, se puede hacer una alteracion de parametros simple sin que
171
afecte a la estructura de los padres. Esto quiere decir, que para cada varible x ∈ X y para cada
conjunto de padres razonable Πx ∈ Px se debe incrementar el correspondiente valor de celdas y
actuzalar las posteriores. Normalmente este proceso debe afectar a los nodos vivos en el
entramado de padres. Por ejemplo, si se tiene una muestra z y se extiende a z' con el nuevo
ejemplo teniendo x=i y Πc = j, se debe incrementar nx=i|j y
(n
+αx )(n
Pr (ΠX |z ', ς, E) = Pr (ΠX |z, ς, E) (nx=i|j +mx αx x=.|j
)(n
x=.|j
−1+mx αx )
x=i|j −1+αx )
Todo esto se deriva de las propiedades recursivas de la funcion Gamma. El proceso de actualizacion completo realizara, por tanto, O(P) operaciones. Se puede mejorar este proceso actualizando inicialmente, solo, los nodos hoja en los enntramados del padre porque el cambio en el
conteo del ejemplo se puede ltrar hacia arriba sin referencia a los ejemplos.
Aprendizaje con datos incompletos
Una distinción importante sobre los datos incompletos (missing data) es si la ausencia de estos
datos es depediente del estado real de las variables. Por ejemplo, un dato perdido en un estudio
sobre dogadiccion puede indicar que el paciente lo hizo demasiado enfermo como para continuar
en el estudio. Por otro lado, si la variable es oculta (por ejemplo, nunca se ha observado el
caso) entonces la ausencia del dato es independiente del estado de la variable.
Aunque los metodos bayesianos y los modelos grácos estan preparados para el análisis de
ambas situaciones; los metodos necesarios para cuando la ausencia es independiente del estado son
más simples que que aquellos en los que la ausencia es dependiente. En este punto se van a tratar
algunos de ello para ver muchos mas se pueden utilizar las siguientes referencias [301, 190, 189].
Aprendizaje paramétrico con datos incompletos Se van a discutir ahora los métodos para el
aprendizaje paramétrico cuando se usa una muestra de datos incompleta (por ejemplo, cuando
no se han obserado algunas variables de algunos casos). La presentacion formal del problema es
la siguiente:
Suponiendo que se observa un unico caso incompleto. Sea Y ⊂ X y Z ⊂ X que son las
variables observada y no observadas respectivamente. Asumiendo la independencia de parametros
se puede calcular la distribucion posterior de θij para una estructura de red S, como sigue:
X
p(θij |y, S h ) =
p(z|y, S h )p(θij |y, z, S h )
x
= (1 −
p(pa ji |y, S h )){p(θij |S h )}
+
ri
X
p(xki , pa ji |y, S h ){p(θij |xki , pa ji , S h )}
k=1
Cada término dentro de las llaves en esta ecuacion es una distribucion de Dirichlet. Por lo
que, a menos que Xi y todas las variables en Pa i se observen en el caso y, la distribucion posterior
de θij sera una combinacion lineal de distribuciones de Dirichlet.
172
Cuando se observa un segundo caso incompleto, alguna o todos los componentes de Dirichlet
de la ecuacion anterior se dividirán en mezclas de Dirichlet. Lo que siginica, que la distribucion
posterior para θij se transformara en una mezcla de mezclas de Dirichlet. A medida que se
siguen observando datos incompletos, cada valor perdido para Z, la distribucion posterior de θij
contendra unnumero de componentes que es exponencial al numero de casos. En general, para
cualquier conjunto interesante de probabilidades y prioridades, el calculo exacto de la distribucion
posterior de θij es intratable. Por lo que se requiere una aproximacion para datos incompletos.
Se procede a continuación a explicar los metodos mas comúnmente utilizados.
Metodos de Monte-Carlo
Una clase de aproximaciones esta basada en los muestreos de Monte-Carlo. Estas
aproximaciones pueden ser extremadamente exactas, siempre que se este dispuesto a esperar
bastante tiempo hasta que se produzca la convergencia.
Se va a presetantar el metodo de Monte-Carlo conocido com Gibbs sampling (que aunque se
ha explicado anteriormente, aquí tiene otra aplicacion).
Dadas las variables X = {X1 , ..., Xn } con alguna distribución conjunta p(x) se puede utilizar
el sampler de Gibbs para aproximar la expectativa para la función f(x) con respecto de p(x) de
la siguiente forma. Primero, se elige (de alguna manera, por ejemplo, aleatoriamente) un estado
inicial para cada una de las variables en X. A continuación se elige una variable culaquiera Xi
se desasigna su estado actual, y se calcula su distribucion de probabilidad dados los estados
de resto de n-1 variables. Entonces se muestrea un estado para Xi basado en su distribucion
de probabilidad y se calcula f(x). Finalmente se repiten los dos primeros pasos, manteniendo un
registro del valor medio de f(x). En el límite, como el número de casos se aproxima a innito, esta
media es igual a Ep(x) (f (x)) con tal de que se cumplan dos condiciones. Primero, el sampler de
Gibbs debe ser irreducible, es decir, la distribución de probabilidad p(x) debe ser tal que se pueda
muestrear eventualmente cualquier posible conguracion de X dada cualquier conguración incial
de X. Segundo, cada Xi se debe elegir amenudo.
Para ilustar el funcionamiento de Gibbs Sampling, se aproximará la densidad p(θs |D, S h )
para cualquier conguracion de θs dado un conjunto de datos incompletos D = {yi , ..., yn }y una
red bayesiana de variables discretas con prioridades de Dirichlet independientes. Para aproximar
p(θs |D, S h ). Primero se incializa, de alguna forma, los estados de las variables no observadas en
cada caso. Como resultado, se obtiene una muestra completa y aleatoria Dc . Segundo, se elige
alguna variable Xil (variable Xi en el caso l) que no se ha observado en la muestra original D
elegida al azar, y se reasigna su estado de acuerdo con la distribucion de probabilidad:
p(x'il |Dc \ xil , S h ) =
p(x'il ,Dc \xil |S h )
p(xil ,Dc \xil |S h )
x
P
il
173
donde Dc \ xil indica el conjunto de datos Dc con la observacion Xil borrada. Tercero, se
puede repetir esta reasignacion para todas las variables no observadas en D, produciendo una
muestra completa aleatoria nueva Dc' . Cuarto, se calcula la probabilidad posterior p(θs |D, S h ) .
Y nalmente, se repiten los tres primeros pasos y se usa la media de p(θs |D, S h ).
Aproximación Gaussiana
Los metodos de Monte-Carlo proporcionan resultado exacto, pero normalmente son intratables,
por ejemplo, cuando se tiene una muestra de datos demasiado grande. Otra aproximación que
ofrece resultados practicamente igual de exactatos para muestras relativamente grandes es, esta
aproximacion gaussiana [209] y [12] que se comenta en este punto.
La idea que hay detras de esta aproximacion es que, para una cantidad de datos grande, p(θs |D, S h ) ∝ p(D|θs , S h )p(θs |S h ) se puede aproximar, frecuentemente, a una distribucion
Gaussiana multivarible.
Concretamente, sea:
g(θs ) ≡ log(p(D|θs , S h )p(θs |S h ))
También, se dene θ̃s como la conguracion de θs . Esta conguracion tambien maximiza
p(θs |D, S h ) y se conoce como la conguracion MAP de θs .
Para calcular esta aproximacion gaussiana, se debe calcular θ̃s , asi como, el Hessian75 negativo
de g(θs ) evaluado en θ̃s .
Aproximación MAP, ML y algoritmo EM
Como aumente el tamaño de la muestra, el pico gaussiano es más agudo tendiendo a la función
delta de la conguración MAP θ̃s . En este punto no es necesario calcular medias o expectativas.
En su lugar, simplemente se realizan predicciones basadas en la conguración MAP.
Una aproximación más profunda se basa en la observación de que, como el tamaño de la
muestra aumenta, el efecto de la anterior p(θs |S h )disminuye. Por lo que, se puede aproximar
θ̃s por medio de la conguracion de Maximum Likekihood del θs :
θ̃ = argmax {p(D|θs , S h )}
θa
Existe un tipo de tecnicas de optimizacion basada en gradiente para para encontrar ML o
MAP. Por ejemplo, se puede usar un gradiente ascendente, donde se siguien las derivadas de
g(θs ) o la probabilidad p(D|θs , S h ) hasta el maximo local. [302] y [355] muestran como calcular
las derivadas de la probabilidad de una red bayesiana con distribuiciones multinomiales no restringidas. [46] discute el caso más general donde la funcion de probabilidad viene de una familia
exponencial. Por supuesto estos metodos basados en gradiente encuentran sólo el maximo local.
75
http://rkb.home.cern.ch/rkb/AN16pp/node118.html
174
Otra tecnica para encontrar un ML o MAP local es el algoritmo EM descrito por [104]. Para
buscar el maximo local MAP o ML, se comienza por asignar, de alguna forma (por ejemplo,
aleatoria) un conguracion a θs . Seguidamente, se calcula la estadistica suciente esperada para
un conjunto de datos completo, donde la expectacion se toma con respecto a la distribucion
conjunta para X condicionada por la conguracion asignada a θs y los datos conocidos D. En el
ejemplo que se viene mostrando, se puede calcular:
Ep(x|D,θs ,S h ) (Nijk ) =
N
P
l=1
p(xki , pa ji |yl , θs , S h )
donde yl es el l-esimo caso incompleto de D. Cuando Xi y todas las variables en pa i se
observan en el caso xl el término para este caso requiere una computación trivial: es cero o uno.
Si no, se puede usar cualquier algoritmo de inferencia bayesiano para evaluar el término. Este
cálculo es el paso de expectacion del algoritmo EM.
Seguidamente, se usan las estadisticas-sucientes esperadas como si fuesen la actuales estadisiticassucientes de la muestra completa (aleatoria) D. Si se hace el calculo ML, se determina la conguracion de θs que maximiza p(Dc |θs , S h ). Siguiendo el ejemplo, se tiene que:
θijk =
Ep(x|D,θ ,S h ) (Nijk )
s
Pri
k=1 Ep(x|D,θ ,S h ) (Nijk )
s
Si se hace el calculo MAP, entonces se establece la conguracion de θs que maximiza p(Dc |θs , S h ).
Siguiendo el ejemplo, se tiene que:
θijk =
αijk +Ep(x|D,θ ,S h ) (Nijk )
s
Pri
k=1 (αijk +Ep(x|D,θ ,S h ) (Nijk ))
s
Esta asignacion, realmente, es el paso de maximizacion del algoritmo EM. Este algorimo
se usa normalmente cuando cuando existen sucientes estadisiticas (por ejemplo, cuando una
funcion de distribucion local está en una familia exponencial), aunque generalizaciones de EM
permiten que se use en distribuciones locales mas complicadas.
Una vez que se ha construido la red bayesiana ( a partir de concimiento, previo, datos o una
combinacion de ambos) normalmente, surge la necesidad de determinar algunas probabilidades
de interes a partir del modelo. Por ejemplo, en un problema sobre deteccion de fraude, se puede
pretender obtener la probabiliadad de un fraude dadas una serie de observaciones de otras variables. Esta probabilidad no se almacena directamente en el modelo y por tanto se debe calcular.
En general, el calculo de la probabilidad dado un modelo se conoce como inferencia. En este
punto se va a describir la inferencia en redes bayesiana [86].
Como una red bayesiana, para una variable X, determina la distribucion probabilidad conjunta de esa variable, se puede (en principio), usar la red baysiana para calcular cualquier probabilidad que resulte de interes. Por ejemplo, para la siguiente red:
175
Figura 2.78: Red bayesiana de ejemplo
La probabilidad se puede calcular:
p(f |a, s, g, j) =
p(f,a,s,g,j)
p(a,s,g,j)
=
P p(f,a,s,g,j)
p(f ' ,a,s,g,j)
f'
Para problemas con muchas más variables, sin embargo, esta aproximacion tan directa no es
posible. Afortunadamente, cuando todas las variables son discretas, se puede aprovechar la independencia condicional codicada en las redes bayesianas para hacer estos calculos más ecientes.
Dada la ecuacion de independecia condicional p(j|f, a, s, g) = p(j|f, a, s) la ecuacion anterior
se transforma en:
p(f |a, s, g, j) =
)p(j|f,a,s)
P p(f )p(a)p(s)p(g|f
p(f ' )p(a)p(s)(g|f ' )p(j|f ' ,a,s)
f'
=
)p(j|f,a,s)
P p(f )p(g|f
p(f ' )(g|f ' )p(j|f ' ,a,s)
f'
Muchos investigadores han desarrollado algoritmos de inferencia para redes bayesianas con
variables discretas que aprovechan la independencia condicional como se ha descrito arriba. Por
ejemplo en [166], [239] y [287] desarrollan algoritmos que invierten arcos o enlaces en la estructura
de la red hasta que la pregunta probabilista realizada se puede leer directamente del grafo. En
estos algoritmos cada enlace invertido se corresponde con una aplicacion del teorema de Bayes.
[186] desarrolla un esquema de paso de mensajes que actualiza las distribuciones de probabilidad
de cada nodo de una red bayesianas en respuesta a observaciones de una o más variables. [392],
[197] y [97] crearon un algoritmo que primero transforma la red bayesiana en un arbol donde cada
nodo en el arbol se correponde con un subconjunto de variables en X. El algoritmo se aprovecha,
entonces, de algunas propiedades matematicas de los arboles para realizar la inferencia. Este
algoritmo es el que más se utiliza con variables discretas.
Aunque se utiliza la independencia condicional para simplicar la inferencia probabilistica,
la inferencia exacta en redes bayesianas arbitrarias con nodos discretos es un problema NPhard76 . Incluso la inferencia aproximada mediante, por ejemplo, el metodo de Monte-Carlo es un
problema NP-hard. El origen de esta dicultad subyace en lo ciclos no dirigidos de la estructura
de la red bayesiana -ciclos en la estructura donde no se hace caso a la direccionalidad de los
enlaces. Cuando una red bayesiana contiene muchos ciclos la inferencia es intratable. Para muchas
aplicaciones la estructura es sucientemente simple (o se puede simplicar sin perder demasiada
exactitud) por lo que la inferencia es eciente.
76
http://es.wikipedia.org/wiki/NP-hard
176
Algoritmo Gibbs Sampling [51]
Este algoritmo es uno de los más simples dentro de los algoritmos de Monte-Carlo. Lo introdujo [144] en el contexto del procesamiento de imagenes y posteriormente lo discutio [350] en el
contexto de problemas de perdida de datos. El documento [143] ayuda a demostrar el valor del
algoritmo de Gibbs para un amplio abanico de problemas de analisis bayesiano.
Para denir este algoritmo, se establece la distribucion condicional total como:
{π(ψ1 |ψ2 , ..., ψp ); π(ψ2 |ψ1 , ψ3 , ..., ψp ); π(ψp |ψ1 , ..., ψd−1 )}
Ahora un ciclo del algoritmo se completa mediante la simulacion de {ψk }pk=1 para esas distri-
buciones, actualizando de forma recursiva las variables condicionantes. Cuando d=2 se obtienen
los dos bloques del sampler de Gibbs que aparecen en [350]. En este sampler cada bloque se
revisa en un orden jado, de la siguiente manera [39]:
(0)
(0)
Se especica un valor inicial ψ (0) = (ψ1 , ..., ψp )
Repetir para j = 1, 2, ..., M
(j+1)
desde π(ψ1 |ψ2 , ψ3 , ..., ψp )
(j+1)
desde π(ψ2 |ψ1
(j+1)
desde π(ψp |ψ1
• Generar ψ1
• Generar ψ2
(j)
(j)
(j)
(j+1)
, ψ3 , ..., ψp )
(j+1)
, ..., ψp−1 )
(j)
(j)
• ...
• Generar ψp
(j+1)
Devolver los valores {ψ (1) , ψ (2) , ..., ψ (M ) }
(j)
(j+1)
La densidad de la transicion de ψk hasta ψk
(j+1)
(j+1)
(j)
(j)
p(ψk |ψ1
, ..., ψk−1 , ψk+a , ..., ψp )
viene dado por
hasta que el bloque k-esimo se alcanza, el anterior (k-1) se
actualiza. Por lo tanto, la densidad de la transicion de la cadena, bajo el supuesto de que π es
absolutamente continua, viene dada por el producto de las transiciones de los nucleos de cada
bloque:
K(ψ, ψ ' ) =
p
Q
k=1
(j+1)
π(ψk |ψ1
j+1
j
, ..., ψk−1
, ψk+1
, ..., ψpj )
Para ilustrar la manera en que los bloques se revisan, se considera el caso de dos bloques,
cada uno con un único componente y esquematizado en la siguiente gura una posible trayectoria
del algoritmo.
177
Figura 2.79: Trayectoria Del Algoritmo
Los contornos en la gura representan la distribucion conjunta de ψ y las etiquetas (0),
(1), etc denotan los valores simulados.
Hay que darse cuenta que en cada iteracion del algoritmo se completa despues de que ambos
componentes han sido revisados. Tambien hay que darse cuenta de que cada componente se revisa
a lo largo de la los ejes de coordenas. Esta caracteristica puede ser una fuente de problemas
si dos componentes estan ampliamente correlacionados porque entonces los contornos tienen
compresiones y movimimientos a lo largo del eje de coordenadas que dan lugar a pequeños
movimientos.
Este algoritmo es aplicable cuando la distribucion conjunta no se conce explicitamente, pero
la distribucion condicional de cada variable si es conocida. En resumen, lo que hace este algoritmo
es generar una instancia de la distribucion de cada variable de forma condicional a los valores
actuales de las otras variables [WIKIPEDI05]. Este algoritmo es facil de implementar y garantiza
convergencia hacia la distribucion correcta, sin embargo puede requirir un numero excesivo de
iteraciones antes de que converja [87].
Algoritmo Naive
El metodo de inferencia que se prensenta en este punto se puede aplicar a cualquier modelo
naive.
En [87] describen el algoritmo de la siguiente forma: para preguntas marginales, sea X el
conjunto de variables de consulta, sea C la variable componente de k estados y Z el conjunto
de la demas variables ocultas. (Se asume que la variable componente nunca forma parte de la
consulta, esto es, nunca se observa en los datos de entrenamiento). Permitase que X se reera a
los estados jos de las variables de pregunta. Ahora se puede calcular la probabilidad marginal
directamente mediante la suma de todos los posibles estados de C y Z:
P (X = x) =
k P
P
P (X = x, Z = z, C = c)
c=1 z
178
Por la hipoteisis de naive Bayes, cada una de las otras variables son indepndientes dada C.
Usando esto, se puede expresar la probabilidad en terminos de las distribuciones aprendidas P(C)
y P (Xi |C) :
P (X = x) =
|Z |
|X |
k P
P
Q
Q
P (c) P (zi |c) P (xi |c)
c=1 k
Como
P
z
i=1
j =1
P (zi |c) siempre es 1, las variables en Z no afectan al calculo de la probabilidad y
se pueden ignorar con total seguridad:
P (X = x) =
k
P
X|
Q
|
P (c)
c=1
P (xj |c)
j =1
Como esta expresion es el producto de k sumas, cada suma conteniendo |X|+1 terminos,
el tiempo total requerido para calcaular P(X = x) es O(|X|k). El tiemp de inferencia de naive
Bayes es constante al numero de variables ocultas mientras la inferencia exacta bayesiana es
exponencial al numero de varibles ocultas.
Las probabilidades condicionales se pueden calcular ecientemente como ratios de las probabilidades marginales. Permitase a Y referirse a un conjunto de variables condionantes en la
consulta condicional y permitase a y referirse a un estado jo de Y.
=y)
P (X = x|Y = y) = P (X=x,Y
P (Y =y)
Las probabilidades marginales en numerador y denominador se pueden calcular en tiempo
O(k(|X |+|Y |)) y O(k |Y |) respectivamente. Por otro lado, la probabilidad condicional P(X =x |
Y = y) se pude calcular en tiempo O(k(|X |+|Y |)) . Hay que jarse en que este tiempo permanace
independiente del numero de variables ocultas.
Puesto que la distribucion de probabilidad completa, sobre multiples variables, especica un
probabilidad para cada uno de un numero exponencial de estados, almacenar estas probabiliadades puede requerir un tiempo y espacio tambien exponencial. Se puede, sin embargo, generar
de forma eciente un modelo reducido de naive Bayes que incorpore toda la evidencia. En este
modelo reducido se borran todas las variables de Y y las evidencias en Y se han incorporado
mediante el ajuste del peso de los componentes, P(C).
Inferencia con datos incompletos
Las inferencias sobre las magnitudes desconocidas parámetros, datos no observados, variables
latentes, etc se obtienen calculando la distribución condicionada de éstas por las magnitudes
conocidas, como son: el modelo estadístico, los datos observados, las variables explicativas, el
método de muestreo y cualquier otra información auxiliar, como pueda ser el redondeo de los
datos, la censura o truncado de estos, etc [182].
179
Puesto que no se han encontrado que metodos o algoritmos emplea la libreria PNL para
realizar esta labor; se pasa a describir algunos de los metodos mas importantes que se han
encontrado.
Metodos de imputacion multiple
La imputacion múltimple (MI) es la practica de rellenar los datos perdidos con valores
plausibles. Aparentemnente resuelve que existan missing-data al comienzo del analisis de los
datos. Sin embargo, una metodo de imputacion ingenuo puede crear mas problemas de los que
resuleve, distorsionando las estimaciones, produciendo errores de todo tipo como indica [300].
El procedimiento de MI proporciona tres metodos para la imputacion la imputacion de los valores perdidos y el metodos elegido depende del patron que sigan los missing-data. Para patrones
monotonos son apropoiados tanto el metodo de regresion parametrica, que asume normalidad
multivariable como un metodo no parametrico que usa un metodo de puntuacion de la propension. Para patrones arbitrarios se puede usar el metodo MCMC77 que asume normalidad
multivariable. A continuacion se describen estos tres metodos comentados.
1. Metodo de regresion paramétrica
De forma intuitiva, este metodo ajusta un modelo de regresion para cada variable con valores
perdidos, con las variables previas como covarianzas. En base al resultado del modelo simula un
nuevo modelo de regresión y lo usa para imputar los missing-data a cada variable [9]. Puesto
que el conjunto de datos tiene un patron de perdida de datos monotono, el proceso se repite
secuencialmente para variables con missing-data.
De un modo mas formal, para una variable Yj con valores perdidos, se ajusta con observaciones
no perdidas de un modelo
Yj = β0 + β1 Y1 + β2 Y2 + ... + β(j−1) Y(j−1)
El modelo ajustado tiene estimaciones del parametro de regresion (β̃0, β̃1, ..., β̃(j−1) , ) y la covarianza asociada σj2 Vj donde Vj es la matrix X'X de la interseccion y las variables Y1, Y2, ..., Y(j−1) .
Para cada imputacion, aparecen nuevos parametros (β̃* 0, β̃*1 , ..., β̃*(j−1) , ) y σ*2j de la distribucion predictiva de los missing-data. Es decir, se simulan de (β̃0, β̃1, ..., β̃(j−1) , ) , σj2 y Vj .
Los valores perdidos se reemplazan, entonces, por
β*0 + β*1y1 + β*2y2 + ... + β*(j−1)y(j−1) + zi σ* j
donde y1, y2, ..., y(j−1) son los valores de la covarianza de las primeras (j-1) variables y z es
una desviacion normal simulada.
77
Markov Chain Monte Carlo
180
1. Metodo de puntuación de la propensión
La puntuación de la propensión es la probabilidad condicional de la asignacion a un tratamiento
particular dado un vector de covarianzas observadas [301]. En este metodo se genera una puntuacion de la propension para cada variable con valores perdidos para indicar la probabilidad de
la observacion que falta . Las observaciones se agrupan entonces basandose en esa puntuacion y
se aplica a cada grupo una imputación bayesiana aproximada [226].
Con un patron de perdida de datos monótono, los pasos a seguir para imputar valores a cada
variable Yj con datos perdidos son los siguientes:
Crear una variable indicador Rj con el valor 0 para las boservaciones con Yj perdido y el
valor 1 en caso contrario.
Ajustar el modelo logico de la regresion de logit(pj ) = β0 + β1 Y1 + β2 Y2 + ... + β(j−1) Y(j−1)
donde pj = p(Rj = 0|Y1, Y2, ..., Y(j−1) ) y logit(p) = log(p/(1 − p))
Crear la puntuacion de la propension para cada una de las observaciones para indicar la
probabilidad de los datos perdidos.
Dividir las observaciones entre un jado de grupos basando es las puntuaciones.
Aplicar un arranque de imputacion bayeisano aproximado para cada grupo. En el grupo
k , denote Yobs la n1 obserbacion sin perdida de datos de los valores de Yj y denote Ymis
la observacion n0 con perdida de datos de Yj . El arraque aproximado de la imputacion
bayesiana primero muestra n1 observaciones aleatorias con remplazamiento de Yobs para
*
crear un nuevo conjunto de datos Yobs
. Este es una analogia no-parametrica de los para-
metros mostrados para la distribucion predictiva posterior de los datos perdidos. Entonces
*
muestra los n0 valores de Ymis reemplazandolos aleatoriamente con los valores de Yobs
.
Este proceso se repite secuencialmente para cada variable con valores perdidos.
Este metodo utiliza sólo la informacion de covarianza con la que esta relacionada si los
valores imputados de la varible estan perdidos. No usa correlaciones entre variables. Es efectivo
para inferencias sobre las distribuciones de variables imputadas individualmente, pero no es
apropiado para el analisis de las relaciones entre variables [400].
1. Metodo MCMC
En este metodo se construye una cadena de Markov sucientemente larga como para que la
distribucion de elementos se estabilice en una distribucion comun y estacionaria. Mediante
simulaciones repetidas se obtiene una distribucion de interes.
En inferencia bayesiana, la informacion sobre los parametros desconocidos se expresa en
forma de distribucion posteriror. MCMC se ha aplicado como un metodo de exploracion de
181
distribuciones posteriores en inferencia bayesiana. Es decir, mediante MCMC , se puede simular
la distribucion conjunta entera de las cantidades desconocidas y para obtener una estimacion
simulada de los parametros posterirores de interes.
Asumiendo que los datos son de una distribucion normal miltivariante, el aumento de datos se aplica a la inferencia bayesiana con missing-data mediante la repeticion de una serie de
imputaciones y pasos posteriores. Los pasos son los siguientes [400]:
Paso de imputacion I-step.
Con el vector de medias estimadas y la matriz de covarianza, este paso simula los valores
perdidos para cada una de las observaciones de forma independiente. Esto es, si se denota
las variables con valores perdidos de la observacion i como Yi(mis) y las variables con
valores observados como como Yi(obs) entonces el paso I-step muestra valores para Yi(mis)
de una distribucion condicional dado Yi(obs) .
Paso posterior p-step
Este paso simula el vector de poblacion media posterior y la matriz de covarianza para
estimaciones de muestras completas.. Estas nuevas estimaciones se usan en el pasos
I-step. Sin informacion previa sobre esos parametros, se usan piroridadas no informativas.
Se puede usar otras prioridades informativas.
Estos dos pasos se repiten lo suciente como para que sean conables para un conjunto
multiple de datos imputados [316].
La meta es tener la convergencia iterada a su distribucion estacionaria y entonces simular
una muestra independiente de valores perdidos. Es decir, con el parametro actualmente estimado
(t+1)
θ(t) en la t-esima iteracion el paso I-step muestra Ymiss
muestra
θ(t+1)
de
(t+1)
p(θ|Yobs , Ymis )
de p(Ymis |Yobs , θ(t)) y el paso p-step
(1)
(2)
. Esto crea la cadena de Markov (Ymis , θ(1) ), (Ymis , θ(2) ), ...,
que converge en una distribucion para p(Ymis , θ|Yobs ).
2.5.3. Modelado de la información de estado [137]
Sea X una variable aleatoria que puede tomar L posibles valores de un conjunto Σ. Sin pérdida
de generalidad, sea Σ={1, ..., L} . Proporcionando un conjunto de entrenamiento D que contiene
los resultados de N variables independientes x1, ..., xN de X de una distribucion multinomial
desconocida P*. Se puede indicar por Ni el número de ocurrencias del símbolo i en los datos
de entrenamiento. El problema de estimación multinomial es encontrar una aproximación buena
para P* (que tambien es una distribucion multinomial).
Este problema consiste en predecir el resultado de xN +1 dado x1, ..., xN . Dada una distribucion anterior sobre las posibles distribuciones multinomiales la estimacion Bayesiana es:
182
P (xN +1 |x1, ..., xN , ξ) =
R
P (xN +1 |θ, ξ)P (θ|x1, ..., X N , ξ)dθ
donde θ = (θ1 , ..., θL ) es un vector que describe los posibles valores de las probabilidades
desconocidas P * (1), ..., P * (L) , y ξ es la variable contexto que indica todas las posibles hipotesis
sobre el dominio.
La probabilidad posterior de θ se puede reescribir usando la ley de Bayes como:
P
P (θ|x1, ..., xN ) ∝ P (x1, ..., xN |θ, ξ)P (θ|ξ) = P (θ|ξ) θiNi
i
La distribucion de Dirichlet es una familia parametrica que son las conjugaciones de la distribucion multinomial. Esto es, si la distribucion previa es de esta familia, entoces esta en la
posterior. Un Dirichelet prior para X se especica mediante los hiperparametros α1 , ..., αL y
tienen la forma:
P (θ|ξ) =
donde Γ(x) =
R∞
0
P
Q
P
Γ(
Q i α i ) θ α i -1 ( θ i
i
Γ(α
)
i
i
i
i
= 1andθi > 0∀i)
tx-1 e-t dt es la funcion gamma. Dado un Dirichlet prior, la prediccion incial
para cada valor de X es:
P (X 1 = i|ξ) =
R
θiP (θ|ξ)dθ =
Pαi
j αj
Con todo esto es facil ver que, si el previo es un Dirichelet prior con hiperparametros α1 , ..., αL
eentondes el posterior es un Dirichelet con hipermarametros α1 + N1 , ..., αL + NL . Por lo la
prediccion para X N +1 es:
P (xN +1 = i|x1, ..., xN , ξ) =
P αi +Ni
j (αj +Nj )
Se puede pensar en los hiperparametros αi como un numero de ejemplos imaginarios en
los que se ha visto el resultado i. Así, el ratio entre los hiperparametros corresponde a la valoracion inicial de la probabilidad relativa de los resultados correspondientes. El peso total de los
hiperparametros representa la conanza en el conocimiento previo. Como se puede ver, si este
peso es grande, la estimacion de los parametros tiende a ir mas allá de las frecuencias observadas
empiricamente de los datos.
Cadenas de Markov
En este apartado se van a describir las cadenas de Markov, los modelos de Markov Ocultos y
diversas aproximaciones a su implementación. Además se dará una visión de las problemáticas
y algorítmicas empleadas. [290, 228]
183
Cadenas de Markov
Una cadena de Markov representa un automáta con estados nitos de la siguiente forma:
Figura 2.80: Cadena de Markov
Se dene como λ = N, {π1}, {aij} N, representa el número de estados que tiene la cadena.
π representa la probabilidad inicial o a priori de cada uno de los estados.
{aij}, representa la matriz de distribución de probabilidad para transiciones entre estados
de la cadena.
La premisa fundamental que se realiza en todo tratamiento y trabajo relacionado con modelos
de Markov es la hipótesis de independencia de todas las muestras anteriores con la actual salvo
para con la anteior. Esto explicado de forma matemática queda de la siguiente forma:
P (qt = j|qt−1 = i|qt−2 = k, ...) = P (qt = j|qt−1 = i)
La interpretación es que la probabilidad de estar en el estado j en el instante actual sólo
viene condicionada al estado en el que se encontraba el sistema en el instante t-1. El resto de
las muestras que se han producido en el modelo se descartan, si bien hay trabajos relacionados
para ampliación del número de etapas anteriores a tener en consideración: bigramas, trigramas,
. . . n-gramas.
Las cadenas de Markov además tienen la propiedad de ser estacionarias, es decir, que en cada
momento se cumple el principio de Markov, esto es:
P (qt = j|qt−1 = i) = P (qt+1 = j|qt+1−1 = i)
A este tipo de cadenas de Markov también se le suele denominar cadenas de primer orden.
A su vez denotar que los estados en estas cadenas son observables, es decir, se puede saber su
valor en todo momento.
La parte observable de este modelo es la propia secuencia de estados y a su vez se puede
calcular la probabilidad de que se de una observación en concreto para un determinado modelo:
184
P (X|M ) = πX1 · αX1 X2 . . . αXn−1 Xn
La fórmula anterior indica que para calcular la probabilidad de que una cadena de Markov
genere una determinada observación, se calcula de forma tan sencilla como la arriba indicada:
probabilidad de inicio por el primer estado de la observación, por la probabilidad de transición
entre el primer estado observado y el segundo, etc.
Representacion de cadenas de markov como RRBB
Las cadenas de Markov son un subconjunto de las propias Redes Bayesianas. Es decir, que se
puede representar lo mismo de ambas formas. Para el caso de una cadena de Markov simple
como la que sigue:
Figura 2.81: Cadena de Markov representada como red bayesiana
En esta red de ejemplo las probabilidades son las siguientes:
Cuadro 2.4: Tabla de probabilidades de la gura
Con una determinada distribución inicial π , que indica la probabilidad a priori de que se esté
en un estado o en otro.
Una red bayesiana que represente lo mismo, partiendo del principio de que sólo se mantiene
el conocimiento del estado anterior, queda tan simple como esta:
185
Figura 2.82: Tablas de probabilidad condicionada
Las tablas de probabilidades condicionadas para el nodo de la RRBB que se ha denominado
SFinal, van a indicar la probabilidad de que se de un determinado estado de la variable en
función del estado que haya ocurrido con anterioridad. Como se puede aprenciar en la gura,
además de tener las tablas de probabilidad condicionada en el segundo nodo, se tiene la tabla de
probabilidad a priori del primero, que coincidirá con la distribución π , de una cadena de markov
simple.
Denotar además, que solo hacen falta dos variables para computar todo, introduciendo evidencias parciales y manteniendo el productorio. Para el primer caso de las cadenas de Markov el
procedimiento para calcular la ruta S1, S2, S3, S5, S4, S1:
P (S1, S2, S3, S5, S4, S1) = P (S1) · P (S2|S1) · P (S3|S2) · P (S5|S3) · P (S4|S5) · P (S1|S4)
Realizando la misma operación, de la RRBB sólo nos va a interesar el CPD78 del segundo
nodo, para poder realizar el cálculo pertinente. Todas las probabilidades condicionadas se van
a poder obtener de la susodicha tabla. Además las probabilidades iniciales, para una cadena de
markov en la que no se tiene denido ni estado de principio ni de nal, quedan representadas en
la tabla o CPD del nodo denominado Sinicial .
En la forma anterior como se puede apreciar, resulta bastante sencilla la modelización de una
cadena de Markov y además se obtienen una serie de ventajas algoritmicas y computacionales
dadas por las redes bayesianas en sí mismas79 .
Hidden Markov Model
Los Modelos Ocultos de Markov son autómatas de estados nitos estocásticos con
observaciones continuas o discretas. Estas observaciones o salidas se conocen como símbolos y
en cada momento del tiempo sólo se extrae uno en concreto.
78
79
CPD, tabla de probabilidades del nodo en cuestión.
Inferencia, aprendizaje, correlación, independencia, representación del conocimiento . . .
186
Básicamente es el mismo concepto que las cadenas de Markov anteriores, con la salvedad de
que los estados no son visibles, si no que de ellos sólo se conoce la salida que emiten.
Se han utilizado extensamente en el reconocimiento del habla, en los que se llega incluso
a una jerarquía de modelos que van desde la detección de subpalabras (fonemas, semisílabas,
sílabas) hasta la detección de palabras y textos completos. Otros usos comunes son el modelado
de secuencias genéticas de ADN, el modelado de textos o la extracción de información de los
mismos [Rabiner93]. Aplicaciones en las que se utilizan pueden ser: robótica, reconocimiento de
voz, genoma humano, economía, nanzas, marketing y un largo etcétera.
Se pueden considerar como una máquina abstracta con k estados ocultos que emiten símbolos
observables de un alfabeto Σ. Cada estado tiene su propia distribución de probabilidad con lo
que la máquina varía entre los estados de acuerdo a esta distribución. Se tienen que tomar para
realizar un cambio de estado dos decisiones: ¾a qué estado se tiene que pasar?, y ¾qué símbolo
del alfabeto Σ es el que se tiene que emitir?
Los observadores pueden ver los símbolos que han sido o se están emitiendo, pero desconocen
el estado oculto en el que se encuentra el modelo HMM en cada momento. La idea subyacente
es conseguir identicar la secuencia de estados ocultos por la que se ha ido para la obtención de
una determinada serie de símbolos.
Los parámetros de un Modelo Oculto de Markov son los siguientes:
Alfabeto Σ de símbolos que pueden ser emitidos.
Conjunto S de estados ocultos que pueden emitir símbolos del alfabeto anterior.
Matriz de transiciones T. Indicando la probabilidad de pasar de un estado s a otro estado
s.
Matriz de emisiones A para cada estado. Indica la probabilidad de emitir un determinado
símbolo del alfabeto estando en un determinado estado.
Se puede denir otra variable acorde a la ruta seguida a través de los estados ocultos en el
interior del modelo que se denomina habitualmente path o hidden path.
Se asume que en total hay N estados Sn posibles para el modelo. Además, se añade un estado
S0 en el que siempre se va a comenzar por conveniencia en la implementación. También se añade
un estado SN como el estado nal del modelo, dado que llegado a ese punto, el modelo parará.
Se tiene a su vez un conjunto P como posibles salidas del modelo que cumplen el alfabeto Σ
= {a1, a2, . . . , aP}. Si además se añade un símbolo a 0 que reprensenta la salida nula se concede
al modelo que pueda haber momentos en los que no exista ninguna salida.
Cada estado Sj tiene una distribución de probabilidad de emisión de símbolos denida por el
vector Aj tal que la probablidad de emisón de a cuando se esté en el estado Sj sea denida por
Aj (a). Se cumple que:
187
P
A(α) = 1 ∀Sj ∈ S
α∈A
Para la matriz de transiciones T, dena de forma que Tjk es la probabilidad de moverse desde
el estado Sj al estado Sk. Denotar que las las de la matriz generada de esta forma deben sumar
1, si bien las columnas no tienen porqué. También se tiene que resaltar que los elementos de la
diagonal de esta matriz deberán ser diferentes de cero para poder permitir transiciones de un
estado a sí mismo.
Para poder eliminar la necesidad de almacenar la distribución inicial de partida de los estados
se tiene a usar el estado comentado anteriormente S0, estado en el que el modelo siempre empieza
y no vuelve nunca a él. Esto indica que la primera columna de la matriz T esté rellena de ceros
y que la primera la es sólo la distribución de probabilidad de comienzo de los estados.
En general por compendio se va a utilizar a partir de ahora la nomenclatura de [Rabiner93]
en la que una cadena de Markov queda completamente denida de la siguiente forma:
N estados ocultos.
M posibles observaciones.
Las distribuciones iniciales de los estados {π1, π2, . . . , πN }
Los estados se etiquetan como S1, S2,. . . , SN.
El número de observaciones se ja en T y éste será a su vez el número de estados ocultos
a través de los que se ha pasado.
La secuencia de observaciones: O = O1, O2,. . . , OT .
La notación que se emplea para una determinada ruta de estados ocultos es: Q = q1, q2,
. . . , qT.
La matriz de transición entre estados ocultos se denota A y sus coecientes serán aij.
La matriz de emisión de símbolos por estado se denota B y es única para cada estado
oculto, por lo que sus coecientes en función del estado son: bi(j).
De esta forma la nomenclatura completa para una cadena de Markov viene determinada por:
λ = N, M, {π1}, {aij}, {bi(j)} Los cálculos más comunes que se suelen emplear son:
Probabilidad de que una determinada secuencia siga un determinado camino en el interior
del modelo.
Probablidad de emitir una determinada serie de símbolos alcanzando el estado
188
Probabilidad de estar en un determinado estado símbolos.
Los problemas más comunes para los que se trata de buscar una solución mediante aplicación de
estos modelos [290]:
Calcular la probabilidad con la que un determinado modelo puede producir una secuencia
de observaciones.
Encontrar el camino óptimo dentro de los estados ocultos que más probablemente haya
podido generar una determinada secuencia.
Aprender un HMM que satisfaga lo mejor posible las secuencias observadas.
Para el primero de los problemas planteados, la solución pasa por calcular la probabilidad con la
que la secuencia observada se ajusta al modelo: P(O / λ). Esta útilidad permite seleccionar de
una serie de modelos, cúal es con mayor probabilidad el que la ha generado y por tanto permite
hacer una clasicación de la muestra adecuada.
El segundo problema implica que se tenga una observación y se quiera determinar cúal ha sido
el camino seguido en los estados ocultos. Mediante esta resolución se consigue descubrir y arrojar
luz a un comportamiento no observado directamente. Se puede a su vez dar una explicación a los
datos obtenidos al poder comprobar los estados ocultos que han sido los encargados de llegar a
ese resultado. Una de las partes más importantes que se deben de tener en cuenta en este punto
es el criterio de optimización a elegir para realizar la maximización de probabilidad, uno de los
más usados es el criterio de la semejanza, likelihood80 .
El tercer problema que se plantea es tratar de tener un modelo completamente ajustado a
los datos de muestras observadas. Sería partir de un histórico de observaciones y a partir de ellas
tratar de inferir los parámetros pertinentes del modelo HMM. Esto se consigue mediante entrenamiento del modelo, realizando un ajuste topológico del mismo y reestimando los parámetros
hasta que el ajuste a las muestras de partida es el mejor posible.
Sobre toda la problemática que se trata de resolver mediante modelos HMM se volverá
más extensamente y en detalle en la parte de algorítmica. Si bien es interesante mostrar la
representación de un HMM de ejemplo y la expansión posible en lo que se denomina Trellis:
80
Likelihood, valor de semejanza, generalmente usado en logaritmos. Este concepto se ampliará en secciones
posteriores.
189
Figura 2.83: Cadena de Markov y la evolución de sus estados.
En la gura anterior, a la izquierda se observa un HMM de ejemplo, y a la derecha se
puede observar un despliegue de hacia donde puede evolucionar cada estado en cada momento
dependiendo de la conexión que tenga con el resto. El modelo en Trellis será usado más adelante
para explicación de algoritmos.
Tipos de HMM
1. Prole Hidden Markov Models. PHMM
Un modelo oculto de Markov basado en perles es una representación de un alineamiento
múltiple. Este alimenamiento múltiple es indicado para encontrar una determinada secuencia.
Generalmente se usa en biotecnología o genética. El usar este tipo de modelos se justica
debido a la facilidad con la que puede cuanticar coincidencias potenciales de nuevas secuencias
proteicas.
Figura 2.84: Ejemplo de PHMM
1. Input Driven Hidden Markov Models, IDHMM
Son modelos de Markov Ocultos que además de quedar denida por:
λ = N, M, {π1}, {aij}, {bi(j)} tienen en consideración entradas externas en cada estado
oculto en cuestión. Queda de la siguiente forma:
190
Figura 2.85: Ejemplo de IDHMM
El modelo queda denido por una sextuplaλ = S, N, M, {π1}, {aij}, {bi(j)} , donde S
son los valores nitos de símbolos de entrada al mismo.
1. Hierarchilcal Hidden Markov Models, HHMM
Esta implementación de modelos de Markov oculto se basa en el establecimiento de una
determinada jerarquía en su interior. La parte superior de la misma por ejemplo podrían ser
estados que emitan frases, justo por debajo estarían otros modelos que representasen palabras,
silabas, cadenas cortas, etcétera. La idea es conseguir desarrollar una estructura lo
sucienmente amplia y genérica para dar cabida a la resolución de problemas con
características determinadas. Un ejemplo aplicado a biotecnología [Skounakis+03]:
Figura 2.86: Ejemplo de HHMM
1. Coupled Hidden Markov Models, CHMM [Zhong+01]
191
Figura 2.87: Ejemplo de integración de cadenas interrelacionadas
Los ejemplos de la gura superior indican la forma en la que se pueden integrar dos cadenas
correlacionadas/acopladas mediante una sucesión estructurada de estados ocultos. Los Modelos
de Markov Acoplados vienen dados por una necesidad de incremento de funcionalidad en los
Modelos de Markov simples. Otra aproximación para establecimiento de correlación entre estados
ocultos que se vean altamente relacionados (se incluyen en este punto los HMM Factoriales
izquierda y los HMM de Entrada-Salida):
Figura 2.88: Otra aproximación para la integración de cadenas interracionadas
Algorítmica
En la sección anterior se han descrito una serie de problemáticas a las que se puede dar
solución mediante los Modelos Markovianos. Las soluciones pasan por ajustarse a determinados
algoritmos para la realización de los cálculos pertinentes. A continuación se detalla el
funcionamiento de los algoritmos que se utilizarán:
1. Evaluación en HMM
Dada una secuencia de observaciones y, la probabilidad P(y) se calcula de las siguientes formas:
Calcular la probabilidad del camino seguido por los estados.
Calcular la probabilidad condicionada de cada símbolo emitido al estado en que se encuentra dado el camino anterior.
192
Suma del producto para el camino de la probabilidad del estado por la probabilidad condicionada de emitir esa observación.
P
P (y) =
x P (x, y)
=
P
x P (x)P (y/x)
Esta ecuación se simplica aplicando el concepto de Markov y asunciones de independencia
condicional. La probabilidad P(x) para el camino x es igual a la probabilidad inicia del estado
x0, por la probabilidad de realizar una transición del estado x0 al estado x1 , por la probabilidad
de pasar de x1 a x2 y así sucesivamente.
P (x) = π(x0 )
τ
Q
a(xt−1 , xt )
t=1
La probabilidad P(y/x) de observar una secuencia y dado un camino x se calcula multiplicando la probabilidad de observar y1 después de transicionar de x0 a x1 por la probabilidad de
observar y2 despues de pasar de x1 a x2 , etcétera.
P (y|x) =
τ
Q
b(xt−1 , xt , y t )
t=1
Y nalmente si se sustituye adecuadamente en la ecuación inicial por las dos anteriores se llega
a la conclusión:
P (y) =
τ
Q
o
a(xt−1 , xt )b(xt−1 , xt , y t )
x π(x )
t=1
P
La evaluación directa de la ecuación anterior implica O(T NT) multiplicaciones, donde N es el
número de estados en el HMM, y donde hay NT caminos a través de la red trellis en que cada
uno de ellos requiere T multiplicaciones.
1. Algoritmo Fordward
Este algoritmo es una altenativa eciente para cuanticar la probabilidad P(y) basado en una
programación dinámica. Este algoritmo calcula las probabilidades de secuencias de
observaciones parciales mediante el uso de probabilidades de observaciones más cortas y sus
posibles estados intermedios. Se denomina algoritmo forward debido a que funciona desde el
comienzo de una secuencia de observaciones hasta el nal.
Si se denomina αt (j) como la probabilidad conjunta en el instante t del estado xj para la
secuencia de observación parcial y1 , . . . , yt :
αt (j) = P (y 1 , ..., y t , X t = xj )
193
La probabilidad P(y1 , . . . , yt ) puede ser calculada marginalizando Xt , esto es, sumar las
probabilidades conjuntas de observar esta secuencia y visitar el estado x en el instante t, para
todo j:
P (y 1 , ..., y t ) =
P
P
P (y 1 , ..., y t , X t = xj ) = αt (j)
j
j
Siguiendo el razonamiento anterior se puede concluir que:
P (y) =
P T
α (j)
j
En base a la demostración anterior, el algoritmo
forward
trata de calcular los coecientes α
inductivamente en la forma que sigue:
α0 (j) = π(xj )
P
αt+1 (j) = αt (i)aij bij (y t+1 ),
para 0 ≤ t ≤ T − 1
En particular, α0 (j) se dene como la probabilidad inicial (a priori) del estado x , y αt+1 (j) se
calcula de la forma siguiente:
Tomar el valor αt (i) para el estado arbitrario xi .
Buscar la probabilidad de transición aij para pasar del estado x al estado x.
Encontrar la probabilidad de observar yt+1 después de transicionar del estado xi al estado
xj.
Y nalmente sumar el producto αt(i)·aij·bij·(yt+1) para todo i.
La complejidad del algoritmo forward es O(T·N2).
194
Figura 2.89: Complejidad del algoritmo Fordward
1. Algoritmo Backward
El algoritmo Backward es otro algoritmo para calcular la probabilidad P(y). Como en el
algoritmo anterior, es un algoritmo para programación dinámica. La diferencia con el anterior
radica en que trabaja desde el nal de la observación al principio de la misma, calculando las
probabilidades de las secuencias de observación parciales, en terminos de probabilidad de
observación de secuencias más cortas, dados los estados intermedios.
Como en el anterior la probabilidad P(yt+1 ,. . . ,yT ) puede ser calculado mediante una
marginalización de Xt : suma las probabilidades conjuntas de observar esta secuencia y visitar el
estado x en el tiempo t, para todo i:
Donde β T (i) denota la probabilidad de observación de la secuencia yt+1 , . . . , yT , cuando el
estado xi se visita en el instante t: β T (i)=P(yt+1 ,. . . ,yT / Xt = x). Teniendo en cuenta que
P(X0 x
) = ) se concluye que:
195
Los valores de β se pueden calcular de la forma siguiente:
Particularmente, β T (i) se inicializa a 1 y β t (i) se procesa así:
mirar la probabilidad de transición para pasar del estado x al estado x
observar la probabilidad de que se de una muestra y en la transición de x a x.
Buscar el valor β t (j) para el estado x, que será la probabilidad de observar la secuencia
(y,. . . ,y) dado x en el instante t.
Sumar el producto a b (y) β (i) para todo i.
La complejidad del algoritmo backward es de O(T N2 ).
Figura 2.90: Complejidad del algoritmo de Backward
196
1. Algoritmo Fordward-Backward
El objetivo del algoritmo Forward-Backward es aglutinar de alguna forma los valores α del
algoritmo forward y los valores β del algoritmo backward. Esto es:
Luego, mediante la marginalización de
X
t
, se consigue:
1. Filtrado y suavizado de las probabilidades. Filtering and Smoothing algorithms
Las probabilidades se pueden ltrar de forma sencilla mediante el uso de los valores [F103?]
para las muestras entre los instantes: 0 ≤ t ≤ T.
Las probabilidades suavizadas son calculadas mediante el uso de los valores [F103?] y β para
las muestras entre los intantes: 0 ≤ t ≤ T.
197
1. Decoding Algorithm (Vitervi)
El problema de la decodicación consiste en encontrar una ruta que maximice la probabilidad
de pasar por esos estados dada una secuencia de observaciones. Como la secuencia de
observaciones es dada, P(y) es constante con lo que:
Cualquier camino de estados ocultos que pertenezca a la maximización arriba indicada es una
solución válida para el problema de la decodicación.
El algoritmo de Vitervi resuelve el problema de la decodicación encontrando subrutas
(x , ..., xt ) tales que ∈ arg máx{x0 , ..., xt }P (x0 , ..., xt , y 1 , ..., y t ).
0
Si se dene:
El algoritmo de Vitervi se calcula inductivamente como sigue:
Simultáneamente, el algoritmo almacena los estados que comprenden el camino más probable:
Para calcular el camino más probable, se va hacia atrás en la traza en la forma que se detalla a
continuación:
198
Donde ahora se puede realizar:
Y en particular:
Figura 2.91: Cálculo del algoritmo de Viterbi
El problema del aprendizaje en HMM
Si se consiguieran pares de valores de estados y observaciones en la forma {(x1,y1),. . . ,(xn,yn)}
sería una cuestión muy sencilla la estimación de los parámetros de una cadena de markov
oculta, HMM λ = (π, A, B)Para maximizar la semejanza81 de los datos al modelo se usarían
81
Semejanza o Likelihood. Valor, logaritmico generalmente, que indica la probabilidad de que una muestra se
ajuste a un determinado modelo de Markov Oculto: P(Muestra/Modelo).
199
contadores frecuenciales relativos para estimar las probabilidades iniciales, de transición y de
emisión:
Donde #Z indica el número total de ocurrencias de un determinado evento Z.
En general, sin embargo, los datos de esta forma no están disponibles. Como su propio nombre
indica, la información de los estados está oculta en un HMM.
1. Algoritmo Baum-Welch
El algoritmo Baum-Welch, es un algoritmo destinado al aprendizaje de parámetros de un HMM
dada una secuencia de observaciones.
Si se denota:
Se puede derivar en base a los algoritmos anteriores:
200
La metodología a seguir para calcular el algoritmo Baum-Welch es la siguiente:
Inicializar λ = (π, A, B)
Iterar hasta conseguir que [λ = (π, A, B)] = [λ0 = (π 0 , A0 , B)]
• Maximización
◦ Ejecutar algoritmo forward para calcular:
◦ Ejecutar algoritmo backward para computar:
◦ Para 1 ≤ t ≤ T, calcular:
• Expectación:
◦ Estimar las probabilidades iniciales:
201
◦ Estimar las probabilidades de transición de
◦ Estimar la probabilidad de transición de
i
a j:
i
a
j
y emitir el símbolo k :
◦ Modelo:
1. Algoritmo Bayesian Merging
Introducción
Este algoritmo propuesto en el año 1994 con referencia [308], ha sido la base para el
aprendizaje automatizado en las partes que conllevan cadenas de Markov.
En el esquema general se pueden encontrar tres tipos de gramáticas probabilísticas:
n-gramas
Modelos de Markov Ocultos (HMM)
Gramáticas estocásticas de Contexto-Libre. (SCFG, Stocastic Context-Free Grammars)
En todas las anteriores sería aplicable este algoritmo en particular.
Problemas a solventar
202
La problemática se ja en encontrar o aprender modelos aplicables a un conjunto de muestras
determinado.
Los modelos probabilísticos más comunes se pueden caracterizar por dos partes:
una estructura discreta (la topología de un HMM, el backbone de contexto libre en un
SCFG)
y una serie de parámetros discretos/contínuos que determinan las probabilidades de las
observaciones que integren el modelo.
El problema radica en la determinación de la estructura. Se ha visto en el apaartado anterior
que el algoritmo baum-welch de partida necesita un modelo base. El hecho de requerir un
modelo de partida obliga a determinar de antemano el número de estados que va a disponer el
modelo en cuestión. Una vez jada la estructura, los parámetros pueden ser ajustados usando
los métodos estandar, como la maximización de similitud82 (ML).
En los modelos de variables/estados ocultos (HMM, SCFG) la estimación típicamente involucra
EM (Expectation Maximization, ej. Baum-Welch), acertado para estructuras prejadas, dado
que puede aprender cualquiera de los comoponentes de un modelo de markov oculto:
λ = (π, A, B):
Explicación funcional
El método denominado Bayesian Merging se puede usar tanto en HMM como en SCFG. Se
trata de realizar diferentes operaciones de unión de subestructuras de un modelo base tratando
de maximizar la probabilidad posterior bayesiana del mismo en base a los datos dados.
Este método se ha propuesto como una alternativa eciente, robusta, y cognitivamente plausible para la construccion de modelos probabilisticos en una amplia variedad de dominios.
Este método se ha propuesto como una alternativa eciente, robusta, y cognitivamente plausible para la construccion de modelos probabilisticos en una amplia variedad de dominios.
Este algoritmo se puede caracterizar de la siguiente forma:
Incorporacion de datos: Dado un cuerpo de datos X construir un modelo inicial M mediante
la acomodación explícita de cada punto individualmente, tal que, Maximice la probabilidad
P(X|M)83 . El tamaño del modelo inicial crecerá con la cantidad de datos y no exhibirá
normalmente una generalización signicativa.
82
83
Maximización de similitud o semejanza o likelihood. Explicada anteriormente en la parte algorítmica.
Donde X será la secuencia de observaciones y M será el modelo HMM en este caso.
203
Mezcla de estructura: Consiste en la construcción de una secuencia de nuevos modelos obteniendo M a partir de M mediante la aplicacion de una generalizacion o merging (operador
m) que se une a la subestructura en M.
En resumen, consiste en construir un modelo base de partida introduciendo explícitamente
cada punto de datos individualmente, de modo que el modelo M 0 maximize la similitud
P(x/M). Esto quiere decir que para cada muestra se tenga la probabilidad más elevada posible
de producirla con el modelo M planteado.
Después de este paso se construye una secuencia de nuevos modelos a los que se le aplica un
operador o función de merging M i+1 = m(Mi ). Las operaciones que realiza m() son dependientes del tipo de modelo, pero en general todo modelo se puede explicar por unas subestructuras
separadas.
Para comprobar la bondad de ajuste de un modelo i+1 con respecto al anterior se utiliza la
fórmula de Bayes (probabilidad posterior):
Esta fórmula como se puede apreciar es proporcional a la probabilidad apriori P(M) y a la
similitud P(x/M). El denominador a la hora de realizar la maximización no necesita ser tomado
en consideración, no depende de M, con lo que puede ser ignorado.
Por último, se necesita encontrar una estrategia para encontrar modelos con la más alta
probabilidad posterior posible. La que se usa en este caso es la denominada BEST-FIRST.
Empezando con el modelo inicial (maximiza la similitud, pero tiene generalmente una baja
probabilidad apriori) se exploran todos los posibles pasos de mezcla (merging). Sucesivamente se
va escogiendo uno (greedy search, búsqueda ávida) o unos (beam search, búsqueda de haz) que
den el mejor incremento inmediato en la probabilidad posterior.
En la práctica, para mantener funcionando correctamente a los modelos en un tamaño manejable, se puede usar una versión "on-line" para el algoritmo de mezcla, en el cual la incorporación
y los estados de mezcla/búsqueda estén intercalados.
Aplicación del modelo de mezcla en las gramáticas probabilísticas.
204
El caso que se esta estudiando se centra en los modelos de Markov Ocultos, HMM. La
aplicación del modelo de mezcla en estos modelos se realiza acorde a lo explicado en los
siguientes párrafos:
1. Para cada muestra observada se crea una única ruta (path) entre el estado inicial y el
nal asignando un nuevo estado para símbolo token en la misma. Es decir, si se dan los
datos ab, abab el modelo inicial es el siguiente:
2. En el proceso de mezcla, dos estados antiguos del HMM son reemplazados con un único
nuevo estado. Éste estado hereda la unión de las transiciones y emisiones de los estados
anteriores. Una muestra para el ejemplo anterior:
205
3. El punto crucial es que cada uno de estos modelos puede ser encontrado maximizando la
probabilidad posterior del HMM. El punto de parada es cuando se consigue un modelo
que produce un salto muy elevado en el término de similitud, decrementando
considerablemente la probabilidad aposteriori del modelo.
Distribuciones previas.
La aproximación se elige de forma "desinformada apriori", esto amplía la probabilidad apriori a
lo largo de todos los posibles HMMs sin dar preferencia explícita a topologías particulares. Un
modelo M es denido por su estructura M y sus parámetros continuos θ. De esta forma se
puede descomponer la probabilidad del modelo apriori en lo siguiente:
206
Además hay que tener en cuenta que las estructuras de los modelos reciben la probabilidad
apriori de acuerdo a su
longitud de descripción :
l(M) es el número de bits necesarios para codicar M, por ejemplo: número de bits necesarios
para codicar todas las transmisiones y emisiones.
Las probabilidades apriori para θ , son asignadas en base a la distribución de Dirichlet para
cada parámetro multinomial de transición y emisión, parecido a un arbol de decisión Bayesiana
[Buntine92]. Por conveniencia del modelado se asume que los parámetros asociados a cada estado
son apriori independientes.
Hay tres formas intuitivas de conocer el por qué las simples prioridades como las planteadas
en este apartado pueden conducir a probabilidades posteriores mayores para los modelos HMM.
Estas aproximaciones se demuestran debido a:
Las topologías pequeñas tienen una longitud de descripción menor, y por ello una probabilidad apriori mayor. Esto se corresponde con la intuición de que una estructura más grande
necesita ser seleccionada de un mayor rango de posibles alternativas equiprobables, por lo
que cada elección individual es menos probable en forma a priori.
Los modelos más grandes tienen más parámetros, por ello se hace que cada parámetro en
particular sea menos relevante. Se conoce también como factor de Occam [Gull98].
Después de que dos estados hayan sido unidos, la cantidad de datos efectiva para cada
parámetro se aumenta (la evidencia para las subestructuras mezcladas se junta). Esto
cambia y encumbra las distribuciones posteriores para esos parámetros más cercanos a las
conguraciones de máxima similitud.
1. Cómputo Posterior
El objetivo del procedimiento de inferencia es la estructura del modelo, luego como se ha dicho,
el objetivo es maximizar la probabilidad posterior del modelo:
207
El motivo matemático para maximizar la parte estructural en vez de simplemente P(M/x),
es que con nes inferenciales un modelo con una estructura posterior elevada representa mejor
la aproximación del procedimiento óptimo de Bayes para promediar todos los posibles modelos
M. Esta armación anterior se puede calcular de la siguiente forma:
Si bien, puede ser aproximada usando la suposición común de Vitervi sobre las probabilidades
en los HMMs.
208
Cuadro 2.5: Implementación del algoritmo
209
Otras cuestiones de implementación relacionadas
• Incorporacion eciente de muestras:
En el caso más simple este paso crea un estado dedicado para cada instancia de símbolo en
cada una de las muestras X. Estos estados son enlazados con transiciones de probabilidad a 1,
de tal modo que una muestra (x...x) es generado por una secuencia de estados (q...q). q puede
ser alcanzado desde q a través de una trasición de probabilidad 1/X, donde X es el número
total de muestras. Todos los estados emiten su correspondiente símbolo de salida xi con una
probabilidad de uno.
De esta forma, muestras repetidas llevan a multiples caminos a lo largo del modelo, todos
ellos generando el mismo string de entrada. La probabilidad total de un string x de acuerdo al
modelo inicial es entonces c(x)/X (la frecuencia relativa del string x). Como se ha introducido
anteriormente de esta forma se constituye el modelo de maxima similitud con los datos de X.
Denotar que los estados correspondientes en caminos equivalentes podrían ser mezclados sin
tener por ello una perdida en la similitud del modelo. Esto es básicamente lo que va haciendo el
algoritmo en las fases iniciales.
Una optimización en este estado es evitar la multitud de rutas y comprobar para cada nueva
muestra si ya esta introducida en una ruta existente. Caso de que sea de esta forma sólo habra que
actualizar la probabilidad de transmision inicial. Usando una extension del algoritmo de Viterbi,
la nueva muestra puede ser alineada con los estados existentes en el modelo, reclutando nuevos
estados sólo cuando y donde sea necesario. Este alineamiento no tiene efecto en las posibles
mezclas, no va a generar ciclos, pero si que puede reducir el número inicial de estados en el
modelo.
Cálculo de los candidatos a mezclarse
El caso general es examinar todos los posibles pares de estados en el modelo actual:
Como se puede apreciar, lo mejor es mantener el modelo con pocos estados, para evitar unos
costes elevados de cómputo. El coste de una mezcla está generalmente dominado por el coste de
mezclar las distribuciones de salida de los estados involucrados. Debido a lo anterior, conviene
en este caso indexar los estados de acuerdo a sus características de emisión y considerar solo
pares de estados que tengan similares entradas. Esta restricción se podría eliminar más adelante
después de que se hayan agotado todas las posibilidades de mezclas. El benecio es claro, dotar
210
al algoritmo de rapidez, y en casos de uso incremental previene de mezclas prematuras que a la
luz de nuevos datos deberían mantenerse separadas.
Evaluación del modelo usando rutas de Vitervi
Para encontrar la probabilidad posterior de un modelo potencial, necesitamos evaluar la
estructura inicial P(M).
El objetivo de la maximización puede ser MAP (Maximun Posterior Probability), cuyos
parámetros pueden calcularse a través del algoritmo Baum-Welch, teniendo en cuenta la condición
de inicio de Dirichlet tomada.
Por otro lado otro objetivo puede ser la evaluación de P(x/M s ), cuya solución no tiene una
solución obvia. Para solventar esta situación y la anterior se puede hacer uso de la aproximación
de Vitervi.
Computación de similitud
La probabilidad exacta de la similitud de un modelo con referencia a un cojunto de datos X, es
dada por el producto de cada una de las probabilidades de la muestra con la siguiente ecuacion:
Esto se puede leer como el productorio de la probabilidad de todas las muestras posibles que
haya. Y la probabilidad de las muestras se puede obtener calculando sucesivamente la probabilidad de pasar del estado Inicial al estado 1 por la probabilidad de que el estado 1 emita el
símbolo x1 de la muestra... y as sucesivamente hasta llegar al nal del "string" /Muestra/Cadena
en cuestión.
La aproximación de Viterbi implica el reemplazo de los sumatorios de todas las muestras por
los terminos con la contribucion mas elevada:
Los términos en esta expresión pueden ser agrupados por estados, llegando a la forma:
211
En esta ecuación anterior los componentes c(q→q) y C(c→σ ) son los contadores totales de
transiciones y emisiones que ocurran a lo largo de las rutas Viterbi asociadas a las muestras de
X. Si se usa la notación de c(q) para la colección de contadores de Vitervi asociados con el estado
q, la fórmula anterior quedará:
MAP parameter estimation.
Para estimar aproximadamente el parametro MAP basado en contadores de ruta Viterbi se han
de modicar los parametros para incluir las condiciones de Dirichlet.
Para implementar esta evaluacion hace falta aproximar la siguiente integral:
Aplicando una serie de aproximaciones basadas en las rutas óptimas de Vitervi y aplicación
de las prioridades de Dirichlet se puede llegar a obtener una formula más simple.
Actualizacion de ruta usando Viterbi de manera optimista.
Consiste basicamente en creer que los estados mezclados preservan las rutas de maxima
representacin de Vitervi. Para ello se requiere que los contadores intermedios de Vitervi se
mantengan durante la fase de mezcla.
212
Capítulo 3
ESIDE-Mendizale Un Framework
Bayesiano de detección de intrusiones
En este capítulo se explica el modelo conceptual de la solución dividiendo éste en nueve puntos, según el modelo conceptual propuesto por Emilie Lundin. Dichos puntos son: Formalización,
Captura de información, Análisis, Respuesta, Fortaleza, Cuestiones operacionales, Evaluación
y Aspectos sociales. De esta forma se obtiene una visión global del Modelo Conceptual de la
solución propuesta.
3.1. Análisis de riesgos y formalización
Este aspecto es fundamental a la hora de la implementación del modelo puesto que estos
parámetros constituyen las variables que tendra éste. Para dilucidar cuáles serian los parámetros
sensibles de mostrar una actividad anómala de los procesos, se ha realizado un estudio, primero
del estado del arte en cuestiones de sistemas de monitorización de actividad de sistemas, que
puede verse en puntos anteriores. Así como un estudio de cuáles pueden ser los valores susceptibles
de ser monitorizados para detectar dicha actividad anormal.
3.1.1. Posibles parámetros
En este punto se hace un repaso de todos parámetros manejados durante el desarrollo del
proyecto. Estos parámetros son medidas que se toman en los sistemas monitorizados, que permiten dilucidar si el equipo se encuentra comprometido o no. Para obtener dichos parámetros,
se han seguido las variables que un estudio previo de las soluciones ya realizadas en éste ámbito
utilizaban para sus desarrollos.
Estos parámetros se pueden dividir en dos grandes grupos muy diferenciados, por una
parte, las medidas que se pueden utilizar para realizar un proling de usuario [236], que
sirven para dilucidar si lo que el sistema está realizando es lo que el sistema suele realizar
213
Figura 3.1: Imagen del monitor de anomalías desarrollado por Teresa F.Lunt y R. Jagannathan.
para un usuario concreto, y por otra parte los parámetros que persiguen dilucidar si un
proceso realiza las acciones que suele realizar.
Estas dos aproximaciones permiten detectar las intrusiones a dos niveles completamente diferentes: por una parte, la detección de intrusiones basada en proling de usuario, permitiría detectar
intrusiones a nivel de usuario, es decir, podría resolver que el usuario actual, no es1 el usuario
que conocía. El otro método, permite controlar la utilización anómala de los recursos para cada
proceso. Es decir, permite realizar un proling de procesos.
Cada una de las técnicas conllevan un tipo de detección diferente y unos resultados diferentes
que se comentarán en los siguientes apartados.
Parámetros de proling de usuario
Estudios anteriores[236], demuestran que un proling de usuario, permite grandes tasas de
acierto sobre la variación de comportamientos de usuario, observando cierto numero de parámetros que permiten discernir un usuario sobre otro. Por lo tanto este método, aprendiendo el perl
de un usuario, se puede llegar a detectar una utilización anómala, tal y como habían anticipado
mucho tiempo antes[21].
Este sistema de proling de usuario para detección ha sido implementado por varios [236, 21,
117] sistemas, los cuales se enumerarán los parámetros que han manejado para dichos trabajo.
Teresa F. Lunt and R. Jagannathan, Experto de detección de intrusiones
El documento [236], expone la creación del experto de detección de intrusiones basado en
un experto que generaba perles de los usuarios. En dicho trabajo, utilizaban los siguientes
parámetros, divididos en dos grandes grupos, variables discretas y continuas:
1
O al menos se comporta de una manera totalmente diferente.
214
Variables discretas: Este tipo de variables tienen un rango de valores nito, se trata de un
conjunto de valores que se utilizan para caracterizar aspectos del usuario. Cada perl de
usuario está compuesto en parte por un conjunto de variables discretas y la probabilidad
de que el usuario cumpla dicho valor.
1.
Time of login :
Se trata del número de sesiones que un usuario inicia en un periodo de
veinticuatro horas. Asimismo, cada periodo de veinticuatro horas se encuentra dividido en
tres categorías diferentes: el periodo de día, periodo de tarde y periodo de cementerio2 , el
cuál no debería haber nadie. Cada login es caracterizado en alguno de estos tres periodos.
2.
Location of login :
Localización del login, es el número de sesiones que un determinado
usuario ha iniciado en un determinado lugar. La estación desde la que se conecta el usuario, puede bien estar directamente conectada con el servidor, bien puede estar conectado
mediante un multiplexor, o estar conectado remotamente. Cada localización diferente sería
un valor discreto dentro de la localización del login.
Variables continuas: Este tipo de variables tienen un rango de valores innito, es decir, que
pueden tomar cualquier valor, dado que son variables que van aumentando (los valores se
van acumulando), conforme la sesión va avanzando. Cada perl de usuario, maneja una
probabilidad condicionada de que se den los valores acumulados medios de las sesiones
anteriores. Asumiendo distribuciones normales a este tipo de variables se puede conseguir
el porcentaje de ajuste del valor actual con la normalidad3 . Para realizar el estudio normal,
se utilizaron los valores de los último 50 días para poder permitir un grado de cambio
gradual a los usuarios. Las variables estudiadas fueron las siguientes:
1.
Connect time :
Tiempo de conexión, que es la duración de una sesión en un sistema. Como
un sólo usuario puede iniciar varias sesiones en un mismo sistema4 , se identica cada una
de las sesiones con un identicativo de trabajo, y cuando se acaba la sesión, se cierra cada
uno de los trabajos creados.
2.
CPU Time :
Tiempo de CPU, es la suma del tiempo de procesamiento utilizado en una
sesión.
3.
IO Activity :
Actividad de entrada y salida, la suma de las actividades de entrada / salida
realizadas en una sesión.
4.
Protection Violations :
Violación de protecciones, es el número de violaciones de acceso
de los permisos acumulados en la sesión.
2
Traducción literal de Graveyard period , supuestamente en este periodo de tiempo no debería haber ningún
tipo de actividad en el sistema auditado. Considerando el inglés estadounidense también puede ser una variación
de Graveyard shift, que signica turno de noche.
3
4
Asumiendo que las interacciones anteriores eran interacciones normales.
Como es usual en sistemas Unix-Like.
215
Este sistema desarrollado, permitía detectar el 95 % de los ataques masquerade 5 , en tiempo real,
mostrando una interfaz que permitía al administrador de sistemas de conocer y tomar contra los
eventos anómalos detectados con el conjunto de parámetros anteriores.
Dorothy Denning
Dorothy Denning en su documento[105] establece un modelo en el que dene los siguientes
parámetros, todos ellos discretos para determinar si un sistema estaba siendo comprometido.
1.
Frecuencia de login :
Se trata de un parámetro discreto que reeja las veces que un usuario
se conecta a un servidor. También puede interpretarse como un parámetro para IDS de red
si se considera contra un servidor.
2.
Frecuencia de localización :
Parámetro discreto a nivel de host que reeja, como su nombre
indica las veces que se conecta un usuario desde un determinado lugar. También se puede
interpretar como parámetro a nivel de red si la validacion se hace contra un servidor.
3.
Ultimo login :
Parámetro discreto a nivel de host reeja como su nombre indica cuando se
produjo el último login del usuario. También se puede interpretar como parámetro a nivel
de red si la validación se hace contra un servidor.
4.
Tiempo entre sesiones :
Parámetro discreto a nivel de host que reeja, como su nombre
indica, el tiempo entre dos sesiones. También se puede interpretar como parámetro a nivel
de red si la validación se hace contra un servidor.
5.
Output de la sesión :
Este parámetro indica la cantidad de tráco generada durante una
sesión.
6.
Carga de CPU, IO,... etc de la sesión :
Se trata de un parámetro discretizado, que marca la
carga de entrada/salida y CPU que genera una sesión. Este parámetro puede considerarse
continuo, y suponer que sigue una ley normal para poder obtener una salida que marcase
la normalidad del mismo. D. Denning, ha discretizado este dato, en vez de utilizar leyes
normales para tratar estos parámetros.
7.
Numero fallos en contraseña:
Parámetro discreto a nivel de host reeja, como su nombre
indica, el intentos de validación fallidos. También se puede interpretar como parámetro a
nivel de red si la validación se hace contra un servidor.
8.
Frecuencia de ejecución :
Parámetro discreto a nivel de host reeja, como su nombre indica,
la frecuencia con que se ejecuta un determinado programa.
9.
Numero de ejecuciones denegadas :
Parámetro discreto a nivel de host que indica el número
de ejecuciones denegadas de un determinado programa.
5
Ataque de suplantación de usuario.
216
10.
Carga de CPU, IO,... etc del programa :
Parámetro discreto a nivel de host reeja, como
su nombre indica, el throughput de un determinado programa.
11.
Numero de veces que un programa se queda sin recursos :
Parámetro discreto a nivel de host
que indica el número de veces que un determinado programa se queda sin recursos.
12.
Frecuencia de lectura, escritura, creado y borrado de un chero :
Parámetro discreto a ni-
vel de host que reeja, como su nombre indica, la frecuencia de operaciones IO de un
determinado programa sobre los cheros.
13.
Registros leídos/escritos :
Parámetro discreto a nivel de host que reeja, como su nombre
indica, la frecuencia de operaciones IO de un determinado programa sobre los cheros.
14.
Fallos de lectura, escritura, creado y borrado de un chero :
Parámetro discreto a nivel de
host que reeja, como su nombre indica, los fallos de operaciones IO de un determinado
programa sobre los cheros.
15.
Fallos por excesivo uso de recursos por parte de un chero :
Parámetro discreto a nivel de
host que indica el número de veces que un determinado chero se queda sin recursos.
Una idea que se puede extraer de este documento es la organización del modelo en una serie de
planos o esferas conceptuales que represente diversos aspectos tales como tiempo, lugar por poner
algunos ejemplos sencillos. De esta forma se tiene un plano temporal, un plano de ubicación. Así
se podría conseguir analizar datos heterogéneos de forma homogénea muy fácilmente.
Además también se pueden ver dos aspectos importantes de los planos en los que se está
dando la auditoría en el sistema, tanto a nivel de proceso, como a nivel de usuario, para poder
monitorizar a nivel de usuario, o de proceso.
Parámetros de proling de proceso
Como se ha explicado anteriormente existen multitud de parámetros para modelizar el comportamiento de un usuario para con el equipo, pero muchos ataques no se producen por suplantación de usuario, sino que se dan al hacer que un proceso presente un comportamiento diferente
al que debería llegar. Por lo tanto, para llegar a detectar ataques que no son de suplantación de
usuario, habría que llegar a un nivel mas bajo: al proling de proceso[285].
Primeramente, hay que hacer una diferenciación entre el código fuente y los procesos. Los
procesos, son código fuente en proceso de ejecución, es decir el código fuente6 solo es el guión de
lo que se ejecuta, luego lo que se ejecuta es el código fuente cargado en memoria, con sus valores
su puntero de ejecución y su pila de valores, es decir, un proceso.
Cuando los procesos se están ejecutando, no interactúan directamente sobre el hardware del
sistema, sino que utiliza la abstracción que el sistema operativo provee a los programas para con
6
También conocido como código muerto.
217
los componentes. Si este sistema no funcionase de esta manera, el software sería especico de
una máquina concreta, dejando de funcionar cuando el software se ejecute sobre un hardware
diferente.
Para que este echo ocurra7 , el sistema operativo provee de un conjunto de rutinas
que abstraen a al software de los entresijos del funcionamiento del hardware, y permiten
ejecutar códigos fuente entre diferentes máquinas con diferente HW8 . Los mismos formatos ejecutable (Tanto PE para sistemas Windows como los COFF para formatos Unix), funcionan de
esta manera, reservando espacio para las llamadas a el núcleo que realiza el acceso al Hardware.
Figura 3.2: Arquitectura interna de los sistemas operativos
De la misma manera la arquitectura de los procesadores actuales, implementan en Hardware
todas estas capacidades de los sistemas operativos. Existen varios niveles de privilegio (también
conocidos como Rings), los cuales implementan a nivel hardware el funcionamiento interno del
sistema operativo descrito anteriormente.
Por lo tanto, para realizar un proling de proceso, hay que monitorizar la actividad del
proceso, esta actividad puede abordarse mediante dos perspectivas diferentes, monitorizando la
interacción de los procesos con el kernel, o observando externamente al proceso.
Parámetros de monitorización externa de procesos.
Los parámetros de monitorización externa de procesos, realizan un perl del aspecto externo
del proceso, es decir, sin analizar ningún tipo de llamada al sistema.
Estas variables son varias de las que explica D. Denning[105] en el artículo de monitorización
de usuarios. Estos parámetros son:
Consumo de memoria de un proceso.
E/S de un proceso.
7
8
Que exista la posibilidad de ejecutar software sobre plataformas Hardware diferentes.
Pos supuesto, nos referimos a HW similar, pero distinto, por ejemplo la utilización de un procesador AMD
o intel ó una tarjeta ATI, o una tarjeta Nvidia; en ningún caso cambios de HW tan grande que afecten a los
programas de zona de usuario como puede ser la utilización de una arquitectura de 64 y 32 bits.
218
Figura 3.3: Abstracción a dos niveles en sistemas Linux
Consumo CPU de un proceso.
Frecuencia de ejecución.
Fallos de escritura / lectura.
Fallos en los permisos.
Hay que resaltar que el método de monitorización externa de procesos, presenta un alto índice
de fallos, dado que los parámetros considerados, son susceptibles a grandes cambios por la carga
del sistema, y no sólo a la acción de ataques y /o intrusiones tanto externas como internas.
Parámetros de monitorización interna de procesos.
Los procesos, en los sistemas operativos modernos necesitan acceder a servicios provistos por
el sistema operativo para realizar acciones para con su entorno. Esta abstracción, permite que
un mismo código pueda ejecutarse en diferentes sistemas.
Pero esta abstracción no es la única que existe, dado que la cantidad de hardware disponible,
y lo diferentes que son entre sí, hacen que una API de kernel permanente y estándar sea algo
excesivamente rígido, por lo que también se da una abstracción a nivel de usuario, mediante
librerías, que son las que realizan las llamadas a las funciones del Kernel. En los sistemas Windows, la API al nivel de aplicación (en ring3), es conocida como la API Win32, que se encuentra
implementada en diversas DLL del sistema. En los sistemas Linux, esta API, es conocida como
la glibc, aunque también existen otras librerías menos importantes que también llaman al kernel,
como pueden ser la X11 o la librería de sincronización pthread, las cuales están recogidas en el
estándar POSIX.
Por lo tanto, en todos los sistemas operativos modernos, existen dos tipos de posibilidades
para realizar una monitorización interna de procesos, una de ellas, monitorizando las llamadas
219
a la librerías que implementas las API a nivel de usuario, es decir, monitorizar las llamadas a
las librerías Win32, glibc... o bien realizar una monitorización a nivel de llamadas desde dichas
librerías al kernel.
Las llamadas a las librerías de zona de usuario que abstraen las llamadas al kernel, y la
intercepción de este tipo de llamadas producirían una salida de más alto nivel, que permitiría
generar un proling a mayor nivel, pero como contrapartida, se genera gran cantidad de información que puede considerarse como ruido. Este inconveniente puede enmascarar las evidencias que
muestran un ataque. En éste ámbito existen varios sistemas[140]9 , que implementan la captura
de datos a este nivel.
Tal y como se comenta en estudios anteriores[247], la monitorización de todas las llamadas
de este tipo causa una gran sobrecarga sobre el sistema dado que los programas actualmente
hacen un uso exhaustivo de las rutinas en este tipo de librerías. Pero lo que también se reeja en
el estudio es que resultaría altamente interesante monitorizar algunas de las llamadas a librerías
externas como pueden ser por ejemplo el API de Winsock10 en sistemas Windows.
El prototipo de estas funciones es en C, y exportan servicios a los programas para que éstos
los consuman.
Listing 3.1: Prototipo de función VirtualAlloc de la API Win32.
LPVOID V i r t u a l A l l o c (
LPVOID lpAddress ,
SIZE_T dwSize ,
2
DWORD f l A l l o c a t i o n T y p e ,
DWORD f l P r o t e c ) ;
Listing 3.2: Prototipo de la función malloc para sistemas linux provista por el API de glibc.
void
∗ malloc ( size_t s i z e ) ;
La otra opción de monitorización interna de procesos son las syscalls o llamadas al sistema
que generan los programas, éstas bien pueden estar generadas por las librerías o directamente por
los programas que llaman a la función sysenter o bien la interrupción 2e en sistemas Windows o
a la interrupción 80 en sistemas GNU/linux.
Este tipo de parámetros han sido utilizados en estudios anteriores [279, 374, 37, 199, 126,
375, 194], estando demostrado[134] que una alteración del comportamiento o de la naturaleza de
los procesos provoca un cambio de las syscalls que se ejecutan en el nivel privilegiado del sistema
operativo.
Estas llamadas, están formados por un código de función11 , y por un número variable de
9
También existe para los sistemas GNU/Linux, las librerías ltrace, que permiten una auditoría de los programas
a este nivel de abstracción.
10
Especicación de la API de comunicación mediante red en sistemas Windows, actualmente se encuentra en
la versión número dos. Mas información en http://www.sockets.com/.
11
Que se almacena en el registro eax del procesador cuando se realiza la llamada a la interrupción.
220
argumentos que se almacenan también en los registros. Por lo tanto cada llamada al sistema
posee un prototipo, identicado por un número de llamada.
Listing 3.3: Prototipo de syscalls write (código 4) y kill (código 37) de sistemas GNU/linux
long
k i l l _ s a v e d ( pid_t , i n t ) ;
long
write_saved ( int , const char ∗ , s i z e _ t ) ;
Listing 3.4: Prototipo de la función NTCreateFile del kernel de Windows
NTSTATUS N t C r e a t e F i l e (
PHANDLE F i l e H a n d l e ,
ACCESS_MASK D e s i r e d A c c e s s ,
POBJECT_ATTRIBUTES O b j e c t A t t r i b u t e s ,
PIO_STATUS_BLOCK I o S t a t u s B l o c k ,
4
PLARGE_INTEGER A l l o c a t i o n S i z e ,
ULONG F i l e A t t r i b u t e s ,
ULONG ShareAccess ,
ULONG C r e a t e D i s p o s i t i o n ,
ULONG CreateOptions ,
9
PVOID EaBuffer ,
ULONG EaLength ) ;
3.1.2. Selección realizada
Finalmente los parámetros utilizados para el proyecto han sido las syscalls o llamadas al
sistema, los argumentos a favor de esta decisión se encuentra detallada a continuación:
Realiza un modelado del comportamiento de cada proceso:
Es decir, no solamente genera
perles de los usuarios[236], sino que se realiza un proling de proceso, el primer enfoque
es particularmente preciso a la hora de reconocer ataques de suplantación pero hoy en día
uno de los mayores problemas con los que se encuentra la seguridad hoy en día son los
conocidos como
buer overows
12
[269],
que modican el comportamiento de cada proceso
para poder realizar acciones arbitrarias sobre el sistema a nivel de proceso. Con el proling
de usuario, los ataques realizados mediante buer overows puede ser detectado, pero será
inherentemente mas lento e inexacto que un proling de proceso en el cuál se mantiene
un modelo de proceso y no de usuario; detectando inmediatamente si un proceso está
realizando acciones arbitrarias que no debería ejecutar dicho proceso con respecto a la
normalidad.
12
También conocidos como desbordamiento de buer, se trata de realizar sobre los programas acciones que per-
mitan ejecutar código arbitrario. Usualmente se utiliza la técnica de sobreescribir mediante copias no controladas
el valor de retorno almacenado en la pila del proceso.
221
Se trata de un mecanismo similar en todos los sistemas operativos modernos :
La mayoría
de lo sistemas operativos modernos implementan un mecanismo de comunicación entre los
procesos en zona de usuario y el kernel en ring 0, con privilegios para ejecutar cualquier
acceso al hardware, y es similar en todos los sistemas estudiados, lo que reduce los problemas
de integración entre los datos de diferentes plataformas.
En casi todos los sistemas operativos se encontraban ya implementados [375,
38] sistemas
de recogida de datos parecidos al que habíamos de implementar. Esto presenta la ventaja
de que se sabe de antemano que la auditoría de dichos parámetros es posible.
Permite la correlación de syscalls entre diferentes sistemas,
es decir, se puede realizar un
estudio de las syscalls que genera un proceso apache (por poner un ejemplo) en un sistema
GNU/Linux y en un sistema Windows.
Genera una menor cantidad de información,
el sistema implementado necesita la mayor
brevedad posible para poder tomar acciones con la mayor brevedad posible, y un volumen de
datos mayor[247] aumenta el tiempo necesario para aprender tanto la normalidad como para
aprender la estructura de los datos aprendidos. Aunque, conceptualmente puede percibirse
que parte de la información vital para la detección de anomalías se haya perdido, en realidad
dichas anomalías se encuentran también[134] en las syscalls de más bajo nivel. De esta
manea al reducir la cantidad de datos, se elimina una gran cantidad de ruido13 .
A menor nivel que la mayoría de infecciones de malware,
la mayoría[315, 247] de las infec-
ciones de malware utilizan la técnica de interceptar las llamadas a nivel de API del sistema,
por lo que si el sistema de recolección se encuentra en el mismo nivel, puede que el malware
haga que el sistema de recogida de datos no capte las acciones realizadas por el sistema, al
interceptar las llamadas a las API del sistema a un nivel más alto del que lo hace el sistema
de recolección de datos.
Proporciona datos que permiten detectar comportamientos anómalos,
que ya ha sido de-
mostrado por estudios anteriores[134], y que han sido la base de multitud de estudios
relacionados con la seguridad anteriormente[199, 126, 131, 375, 194, 309].
Las razones anteriores, han echo que la elección de parámetros para el sistema haya sido utilizar las llamadas al sistema para utilizarlas como parámetro en el sistema implementado en el
proyecto.
En el sistema se han utilizado las partes que integran una llamada al sistema:
Función llamada: Habitualmente ha sido el parámetro utilizado, para detectar desviaciones
en el comportamiento de los procesos, normalmente no se utiliza el nombre de la función
sino que se utiliza el número que idéntica unívocamente cada syscall.
13
Como ruido, se considera los datos que no tienen una representatividad y difuminan la importancia de los
que sí que la tienen.
222
Parámetros de la función: Los parámetros han sido siempre ignorados, hasta que un estudio[372]
demostró que conociendo el sistema que iba a auditar el proceso, era posible engañar al
sistema, emulando la cadena de syscalls que sería lícita en el sistema mediante llamadas a función que realmente no hacían nada. Este tipo de ataques denominados
mimicry,
hicieron necesaria la inclusión de los argumentos como parámetro a incluir en estudios
posteriores[68].
Valor de retorno de la función: El parámetro del valor de retorno[95, 233] , ha sido incluido
en varios estudios actuales de modelización de secuencias de llamadas al sistema.
Como puede apreciarse, cada llamada genera tres parámetros de entrada al sistema, que permiten
realizar una modelización a bajo nivel, para poder realizar una modelización de comportamiento
de procesos, y no de usuarios.
3.1.3. Futuros parámetros
Como futuros parámetros se establece la línea de investigación que se abre para correlacionar
los parámetros de un entorno de red con los parámetros que se contemplan del entorno de host.
Estos parámetros permitirían establecer una serie de esferas /planos de análisis, de forma, que
se integren en el análisis homogéneo parámetros heterogéneos.
Por lo tanto, un análisis de datos heterogéneos, puede dar relaciones entre los dos mundos
ampliamente separados desde sus inicios, como pueden ser los HIDS, y los NIDS.
A continuación se describen los posibles parámetros relacionados con el mundo de la red que
pudieran ser utilizados conjuntamente con los parámetros que ya han sido expuestos anteriormente.
Para obtener estos parámetros se tuvieron en cuenta fuentes como los protocolos IP, TCP,
UDP e ICMP, el sistema de detección de intrusos Snort y el proyecto Lerad [364] por citar
algunos. De forma general para todas las tablas, aquellos parámetros en los que el tipo se indica
Binario / Discreto
es porque se pueden implementar de las dos formas; por ejemplo, para
el parámetro Ipopts de Snort este se puede implementar de forma discreta con una variable
que contenga nueve estados o bien, de forma binaria mediante nueve variables (una para cada
estado) que contenga tan solo dos estados. Y también que en aquellos sitios donde aparece
cuanticable
No
es que el parámetro tiene naturaleza discreta pero los valores que pueden contener
son aleatorios.
Formato de las tramas
En este punto se explica el formato de las tramas IP, TCP, UDP, ICMP y se comentan los
posibles valores que pueden tomar y con qué tipo de variables se pueden representar. Se han
elegido estos protocolos puesto que son fundamentales en las redes Ethernet actuales.
223
Formato trama IP
El protocolo IP (Internet Protocol, IP) es un protocolo no orientado a conexión usado tanto
por el origen como por el destino para la comunicación de datos a través de una red de paquetes
conmutados. [8]
El formato de su datagrama es el siguiente, según [RFC791]:
Figura 3.4: Formato IP
El tipo y los posibles valores cada parámetro de este datagrama se detallan en la siguiente
tabla.
Parámetro
Tipo
Valores posibles
Versión
Internet Header Lenght
Tipo de servicio
Longitud Total
Identicador
Dont Fragment (DF)
More Fragment (MF)
Desplazamiento del fragmento
Tiempo de vida
Protocolo
Suma de comprobación
Dirección Origen
Dirección Destino
Discreto
Discreto
Discreto
Discreto
Discreto
Binario
Binario
Discreto
Discreto
Discreto
Discreto
Discreto
Discreto
4ó6
24
24
216
No cuanticable
0-1
0-1
213
26
26
216
232
232
Cuadro 3.1: Tipo y valores posibles de cada parámetro
224
Formato de TCP
El protocolo de control de transmisión ('Transmission Control Protocol', TCP) está pensado
para ser utilizado como un protocolo 'host' a 'host' muy able entre miembros de redes de comunicación de computadoras por intercambio de paquetes y en un sistema interconectado de tales
redes. [10]
Su formato según [10] es el siguiente:
Figura 3.5: Formato TCP
El tipo y los posibles valores cada parámetro de este protocolo se detallan en la siguiente
tabla.
Parámetro
Tipo
Valores posibles
Puerto origen
Puerto destino
Número de secuencia
Número de conrmación (ACK)
Desplazamiento
URG
ACK
PSH
RST
SYN
FIN
Ventana
Checksum
Puntero Urgente
Opciones + Relleno
Datos
Discreto
Discreto
Discreto
Discreto
Discreto
Binario
Binario
Binario
Binario
Binario
Binario
Discreto
Discreto
Discreto
Discreto
Discreto
216
216
212
212
24
0-1
0-1
0-1
0-1
0-1
0-1
216
216
216
No cuanticable
No cuanticable
Cuadro 3.2: Tipos y posibles parámetros del protocolo TCP
225
Formato UDP
Este Protocolo de Datagramas de Usuario (User Datagram Protocol, UDP) asume que el
protocolo IP se utiliza como protocolo subyacente. Este protocolo aporta un procedimiento para
que los programas de aplicación puedan enviar mensajes a otros programas con un mínimo de
mecanismo de protocolo. El protocolo se orienta a transacciones, y a la entrega como la protección
ante duplicados no se garantizan. Las aplicaciones que requieran de una entrega able y ordenada
de secuencias de datos deberían utilizar el protocolo TCP. [11]
Su formato según [11] es el siguiente:
Figura 3.6: Formato UDP
El tipo y los valores de cada parámetro de este protocolo se detallan en la siguiente tabla.
Parámetro
Tipo
Valores posibles
Puerto Origen
Puerto Destino
Longitud
Checksum
Discreto
Discreto
Discreto
Discreto
216
216
216
216
Cuadro 3.3: Tipos y posibles parámetros de UDP
Formato ICMP
El protocolo IP se utiliza para el servicio de datagramas de "host" a "host" en un sistema de
redes interconectadas denominado Catenet. Los dispositivos de conexión de redes se denominan
Pasarelas (Gateways). Estas pasarelas se comunican entre ellas con propósito de control mediante el Protocolo Pasarela a Pasarela (Gateway to Gateway Protocol (GGP)). Ocasionalmente,
una pasarela o un "host" de destino se comunicará con un "host" de origen para, por ejemplo,
informar de un error en el procesamiento de datagramas. El Protocolo de Mensajes de Control
Internet (ICMP) se usa para este propósito. ICMP utiliza el soporte básico de IP como si se
tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte integrante
de IP, y debe ser implementado por todo módulo IP. [7]
Su formato según [7] es
226
Figura 3.7: Formato ICMP
El tipo y los valores de cada parámetro de este protocolo se detallan en la siguiente tabla.
Parámetro
Tipo
Valores posibles
Tipo
Código
Checksum
Contenido
Discreto
Discreto
Discreto
Discreto
28
28
No cuanticable
216
Cuadro 3.4: Tipos y posibles parámetros ICMP
Snort
Mediante un exhaustivo proceso de revisión de las reglas que incluye este sistema se consiguió
extraer un conjunto de métricas que fueron separadas en dos categorías: Bajo Nivel y Alto Nivel
respectivamente. Las de bajo nivel se corresponden con la mayoría de los parámetros de las
tramas de los protocolos explicados anteriormente y las de alto nivel representan conceptos más
complejos que los propios parámetros. Los parámetros de bajo nivel son los siguientes:
Parámetro
Tipo
Valores posibles
Flags (Syn, Ack, Rst, etc)
Fragbits (MF,DF)
TTL
ID
Ipopts
Dsize
Flow
Window
Discreto/Binario
Binario
Discreto
Discreto
Discreto/binario
Discreto
Discreto/Binario
Discreto
0-1
0-1
26
No cuanticable
rr, eol, nop, ts, sec, lsrr, ssrr, satid, any
No cuanticable
to_client, to_server, from_client, from_server, establishe
No cuanticable
Cuadro 3.5: Tipo y parámetros de bajo nivel de Snort
Algunas de los parámetros de alto nivel son los siguientes:
227
Parámetro
Tipo
Valores posibles
Not-suspicious
Attempted-recon
Shellcode-detect
Suspicious-login
System-call-detect
Unsuccessful-user
Unsuccessful-admin
Icmp-event
Binario
Binario
Binario
Binario
Binario
Binario
Binario
Binario
0-1
0-1
0-1
0-1
0-1
0-1
0-1
0-1
Cuadro 3.6: Tipo y parámetros de alto nivel de Snort
Como se puede observar muchos de los parámetros de los obtenidos de las tramas se corresponde con los parámetros de bajo nivel de Snort, a continuación se muestra una tabla donde se
observa la correspondencia entre los parámetros obtenidos de las las tramas y los obtenidos de
Snort.
Todos los parámetros extraídos de Snort están recogidos en los parámetros de las tramas,
menos
Flow
que se puede implementar de una manera alternativa. Queda claro, de esta forma,
que implementar los parámetros de las tramas combinados con los de Snort permite extender y
mejorar el modelo que incorpora Snort.
Lerad
En el documento [364] Mahoney y Chan proponen un algoritmo para la detección de intrusiones que utiliza los siguientes parámetros.
Parámetro
Tipo
Puerto Origen
Puerto Destino
Longitud de la conexión
Duración de la conexión
Flags de los dos primeros paquetes
Flags de los dos últimos paquetes
Ocho primeros octetos del campo datos
Numero de conexiones a un puerto de una ip concreta
Discreto
Discreto
Discreto
Discreto
Binario/Discreto
Binario/Discreto
Discreto
Discreto
Valores posibles
No
No
No
No
216
216
cuanticable
cuanticable
0-1
0-1
cuanticable
cuanticable
Cuadro 3.7: Parámetros que proponen Mahoney y Chan[364].
Marina Bykova
Marina Bikova y otro en su documento [48] analiza los siguientes parámetros para detectar
comportamientos anómalos en la red.
228
Parámetro
Tipo
Numero de direcciones IP fuera de rango
Numero de otras violaciones en la dirección
Opciones IP no adecuadas
Numero de paquetes demasiado pequeños (IP/TCP)
Veces que aparece puerto cero
Checksum invalido
Discreto
Discreto
Discreto
Discreto
Discreto
Discreto
Cuadro 3.9: Parámetros de alto nivel de Marina Bykova
Parámetro
Tipo
Valores posibles
Tamaño paquete (IP/TCP)
Checksum (IP/TCP)
Dirección IP
Opciones IP
Puertos TCP
Flags TCP
Bits reservados TCP
Discreto
Discreto
Discreto
Discreto
Discreto
Binarios
Binarios
Tantos como paquetes
Tantos como paquetes
212
No cuanticable
216
0-1
0-1
Cuadro 3.8: Parámetros y tipos de Marina Bykova
Como puede comprobarse estos parámetros son los mismos que se obtienen del análisis de
las cabeceras de las tramas. Con estos parámetros, Bykova, establece los siguientes parámetros
de mayor de nivel de abstracción.
Christopher Kruegel
De la mano de dos autores altamente reconocidos, como son Christopher Krügel y Giovanni Vigna, en el documento [217] se comentan una serie de métricas factibles de ser aplicadas,
ampliadas y generalizadas. La idea de la que parten es la aplicación de conocimiento experto
para el análisis de solicitudes web. Dieren las peticiones en una serie de partes denidas por el
estándar del protocolo HTTP [6]. El objetivo general de la práctica que realizan es contrastar
el tráco que se genera en un determinado momento con el tráco aprendido como válido y sin
ataques en una fase de aprendizaje. Se compone por lo tanto de dos fases diferenciadas y claves,
el aprendizaje y la detección. Durante la primera se tratará de establecer el valor de la métrica
que corresponda en la forma más precisa posible y durante la segunda se comparará, como si de
una medida patrón se tratase, para validar una posible ocurrencia en dos categorías: normal o
anomalía.
Para realizar esta clasicación se basan en una serie de métricas susceptibles de ser añadidas
al sistema en futuras ampliaciones como parámetros.
229
3.2. Recogida de información
La recogida de la información permite alimentar el sistema con los datos de los terminales
móviles, (en este caso las syscalls con sus argumentos), estos terminales pueden ser heterogéneos,
es decir, se han desarrollados sistemas de captura de datos para diferentes plataformas: GNU/Linux, Windows, Windows Poquet PC y Symbian. Aunque el sistema esta diseñado para ser un
analizador de anomalías en terminales móviles, la solución implementada permite analizar diferentes plataformas, no solamente en terminales móviles, sino en sistemas operativos de propósito
general , ampliando el estudio realizado.
A continuación se detallan los sistemas de recogida de información llevada a cabo en los
sistemas mencionados.
3.2.1. Recogida de información en sistemas GNU/Linux
Los sistemas GNU/Linux se caracterizan por encontrarse en multitud de dispositivos y arquitecturas diferentes, desde dispositivos embebidos14 , hasta soluciones móviles, PDAs... por lo que
un aspecto interesante del proyecto pasaba por realizar un sistema de recogida de información
en sistemas GNU/Linux por la amplitud del arquitecturas y sistemas en los que se encuentran.
Particularmente la opción elegida pasaba por implementar un sistema de recolección de información para PDAs de Nokia N770 que utilizan una distribución propia llamada maemo15 .
Al nal de este apartado se especicarán los detalles de implantación en la Plataforma.
En los sistemas Unix-like16 , la arquitectura del sistema se divide en dos partes muy diferenciadas: el modo real y la zona de usuario, siendo las syscalls el lenguaje por el cual hablan las
dos partes. Dichas syscalls17 , son el mecanismo que permite conectar las dos zonas divididas por
el sistema operativo, el modo real, en el que se encuentra el kernel, y la zona de usuario, donde
se encuentran los programas de usuario.
Las diferencias entre estas dos zonas son muy signicativas, en el modo real, se realizan las
funciones primordiales de los sistemas operativos18 , como pueden ser la gestión de memoria,
la gestión de procesos... por lo tanto su tratamiento es eminentemente diferente a la zona de
usuario, en la que se disponen de los servicios provistos por el kernel (gestión de memoria virtual
19
, gestión de sistemas de cheros...); y para pedir dichos recursos al sistema operativo, ha que
14
15
16
también conocidos como dispositivos empotrados.
Mas información sobre esta distribución en www.maemo.org.
Se trata de un sistema de funcionamiento parecido al de un sistema Unix tradicional, pero que no se encuentra
bajo una especicación UNIX convencional, tradicionalmente este término ha estado ligado al software libre y a
sistemas abiertos como GNU/Linux.
17
18
También conocidas como llamadas al sistema.
Cabe destacar, la excepción de los sistemas microkernel, en el que las funciones del sistema operativo aparecen
en zona de usuario.
19
Los sistemas operativos emulan las direcciones de memoria utilizadas por los programas de usuario, haciéndoles
creer que disponen de un rango de direcciones mayor del que existe físicamente en la memoria física de la máquina.
De esta manera el sistema operativo puede almacenar temporalmente en zonas del disco duro (minimizando la
utilización de un recurso tan valioso como es la memoria) bloques de memoria virtual poco utilizados.
230
Figura 3.8: Esquema de la estructura del kernel
Figura 3.9: Proceso de llamada a una syscall
utilizar el mecanismo de las syscalls.
Los sistemas GNU/Linux, siguen el estándar POSIX
20
, que denen un conjunto de syscalls,
de esta manera se parte de un conjunto de llamadas al sistema susceptibles de ser recogidas
como parte de la información utilizada posteriormente para el aprendizaje e inferencia de la
herramienta, dado que ya ha sido demostrado en estudios anteriores[375] que los ataques generan
una variación detectable en las syscalls generadas por los procesos.
Sistema de syscalls en sistemas GNU/Linux
Antes de proceder a la intercepción de las llamadas a las syscalls, fue necesario realizar un
completo estudio de la arquitectura que posee el kernel de GNU/Linux para el tratamiento de
las syscalls.
La parte de la gestión de estas syscalls, se pueden dividir en dos partes muy diferenciadas:
La llamada desde la zona de usuario y la recepción por parte de el kernel.
20
Portable Operating System Interface, siendo la X referencia a los sistemas Unix. Se trata de un conjunto de
estándares que dene las syscalls que ha de implementar un sistema Unix. Se encuentra denida en los estándares
IEEE1003. Cabe destacar, que este estándar no solamente dene las syscalls, sino que también especica programas
a nivel de usuario (sed, awk...) linea de comandos y otros tantos aspectos de los sistemas Unix-Like.
231
Llamada a syscalls desde la zona de usuario
La llamada a las funciones del sistema en los sistemas GNU, se implementan mediante interrupciones21 generadas por instrucciones en ensamblador o mediante las puertas de llamada
lcall7/lcall2722 , por lo tanto, cuando alguno de los dos mecanismos ocurre, el procesador, cuando un proceso de zona de usuario requiere un recurso, interrumpe lo que estaba haciendo y da
servicio a la petición recibida.
Esta llamada puede realizarse desde los programas directamente en código ensamblador,
llamando a las interrupciones int0x80, para ello se cargan en los registros EAX el código de la
instrucción (en el ejemplo se trata del código de la instrucción write , con el número de syscall
4, seguido de la syscall 1, la exit).
Listing 3.5: Ejemplo de programa en ensamblador
.data
3
msg :
# Zona de d a t o s
. s t r i n g " Hello , world ! \ n"
# d e f i n i c i o n cadena
l e n = . − msg
# longitud
.text
. g l o b a l main
8
# decimos e l " e n t r y p o i n t "
main :
13
18
movl
$ l e n , %edx
# l o n g i t u d de l a cadena
movl
$msg , %ecx
# p u n t e r o a l a cadena
movl
$1 , %ebx
# h a n d l e r ( 1 = STDOUT)
movl
$4 , %eax
# (4 = write )
int
$0x80
# llamada a l k e r n e l
movl
$0 , %ebx
#c o d i g o de s a l i d a
movl
$1 , %eax
#(1 = e x i t )
int
$0x80
# llamada a l k e r n e l
Como se puede observar, el código para llamar a una syscall concreta, depende de la syscall
que sea llamada, esto, hace que tenga muchas variaciones, y que el código ensamblador sea
muy difícil de escribir. Por dicha razón, hoy en día la mayoría de las llamadas a las syscalls, se
21
Señal que indica al procesador que debe interrumpir el curso de ejecución actual, y proceder a ejecutar el
tratamiento especico para la interrupción que acaba de ejecutarse.
22
Puertas de llamada utilizadas en sistemas Solarix, Unixware, que también son soportados por el kernel de
Linux.
232
encuentran englobadas en una librería (conocida como la glibc23 ), que provee de una API a alto
nivel para las llamadas a las syscalls, lo que permite abstraernos de las llamadas a bajo nivel y
de los registros en los que tenemos que almacenar los argumentos.
Para comparar los dos sistemas, lo que antes se hacia en varias lineas crípticas de ensamblador,
se realiza en una sola línea en lenguaje C.
Listing 3.6: Ejemplo de la mejora con lenguaje C
1
int
main ( ) { p r i n t f ( " H o l a Mundo " ) ; }
También existe otro tipo de macros que permiten las llamadas a las syscalls abstrayéndonos
en cierto modo de los registros del sistema, estos son:
Listing 3.7: Macro para llamar a syscall
s y s c a l l 2 ( long , runqueue , unsigned long ∗ , dst , long , l e n ) ;
Los programas, al seguir su curso generan un numero determinado de syscalls que pueden
ser logeadas, mediante el comando strace24 (para ver las llamadas al sistema así como sus argumentos). Mediante esta útil herramienta se pueden depurar programas comúnmente utilizados,
viendo si existe algún tipo de comportamiento extraño en la secuencia o el tipo de llamadas a
las syscalls del sistema.
Esta herramienta fue un punto de partida sobre el que se planteó comenzar a trabajar, pero
se vieron varios y numerosos inconvenientes:
Se trata de un sistema que trabaja a petición, es decir, hay que decir explícitamente que
el programa se ejecute bajo la supervisión de strace.
Genera una salida en texto que habría que parsear, siendo este un arduo trabajo.
Los programas ejecutados bajo strace, se ejecutan más lentamente que los ejecutados normalmente.
Vistos estos inconvenientes se optó por otro tipo de sistema para capturar las llamadas al
sistema, ya que strace no ofrecía las funcionalidades necesarias, tratándose más de un medio de
depuración de los programas, más que un sistema de monitorización integral.
Recepción de syscalls en zona de kernel
Para poder interceptar las llamadas, se procedió a un estudio exhaustivo de cómo se realiza
la recepción y tratamiento de las llamadas al kernel en los sistemas GNU/Linux.
23
24
GNU C library, es una parte esencial de los sistemas GNU/Linux .
Strace es un comando de la linea de comandos de Linux (comúnmente conocida como bash), que permite
logear las llamadas al sistema que se efectúan por parte de un programa.
233
Figura 3.10: Ejemplo utilización del comando strace
234
La comunicación se realiza mediante syscalls, siendo éstas llamadas a la interrupción 0x80,
estas llamadas, se traducen, en la llamada a la rutina situada en la entrada 0x80 de la tabla
de manejo de interrupciones. Por lo tanto, por ejemplo si se produce una interrupción 0x13, se
sumaría 13 a la dirección base del vector tabla de interrupciones, obteniendo de esa manera la
dirección de la función que ha de gestionar dicha interrupción25 .
Este proceso completo se puede encontrar en varios archivos del kernel, en el archivo
r/src/linux/include/asm/unistd.h,
/us-
podemos encontrar un conjunto completo de las syscalls que
el kernel esta preparado para recibir, en cada versión del kernel existe un número diferente de
syscalls, siendo siempre mayor que el anterior, dado que una vez que se ha insertado una nuevas
syscall, hay que mantenerla en el kernel por razones de compatibilidad, cuando una syscall ha
dejado de ser implementada, se le asigna una nueva syscall: sys_ni_syscall, que devuelve el valor
-ENOSYS, que indica que dicha syscall ya no está implementada.
Listing 3.8: Contenido de unistd.h los números de las syscalls
#i f n d e f
_ASM_I386_UNISTD_H_
#d e f i n e
_ASM_I386_UNISTD_H_
/∗
4
9
∗
This
file
contains
the
system
#d e f i n e
__NR_restart_syscall
0
#d e f i n e
__NR_exit
1
#d e f i n e
__NR_fork
2
#d e f i n e
__NR_read
3
#d e f i n e
__NR_write
4
#d e f i n e
__NR_open
5
#d e f i n e
__NR_close
6
call
numbers .
∗/
Estas llamadas son recibidas a nivel de kernel por código especíco para cada tipo de procesador, que extrae el valor del registro
eax,
en el que almacena el numero de la syscall que va a
ejecutarse. Este numero (multiplicado por el tamaño de las direcciones de memoria) se suma a
la dirección base de la idt26 , obteniéndose el handler de la interrupción que va a ejecutarse.
Listing 3.9: Denición de la IDT en linux
struct
d e s c _ s t r u c t i d t _ t a b l e [ 2 5 6 ] __attribute__ ( ( __section__ ( " . d a t a .
i d t " ) ) ) = { {0 , 0} , } ;
Como se puede ver en la inicialización, existen varias interrupciones aparte de la 80, denida
por la macro
25
SYSCALL_VECTOR,
como pueden ser
división por 0, page fault...
El vector de interrupciones es conocido como la zona de memoria en la que se encuentran los punteros a las
funciones que tratan cada una de las interrupciones. Por lo tanto para desplazarnos por las entradas del vector,
sumamos a la dirección base del vector el número de interrupción que queremos tratar.
26
Interrupción Description Table: Vector en el que se almacenan
235
Listing 3.10: Inicialización de la IDT
set_trap_gate (0 ,& d i v i d e _ e r r o r ) ;
s e t _ i n t r _ g a t e (1 ,& debug ) ;
s e t _ i n t r _ g a t e (2 ,& nmi ) ;
4
set_system_intr_gate ( 3 , &i n t 3 ) ;
/∗
i n t 3 −5 can
be
called
from
all
∗/
set_system_gate (4 ,& o v e r f l o w ) ;
set_system_gate (5 ,& bounds ) ;
set_trap_gate (6 ,& i n v a l i d _ o p ) ;
set_trap_gate (7 ,& d e v i c e _ n o t _ a v a i l a b l e ) ;
9
set_task_gate ( 8 ,GDT_ENTRY_DOUBLEFAULT_TSS) ;
set_trap_gate (9 ,& coprocessor_segment_overrun ) ;
set_trap_gate (10 ,& invalid_TSS ) ;
set_trap_gate (11 ,& segment_not_present ) ;
set_trap_gate (12 ,& stack_segment ) ;
14
set_trap_gate (13 ,& g e n e r a l _ p r o t e c t i o n ) ;
s e t _ i n t r _ g a t e (14 ,& p a g e _ f a u l t ) ;
set_trap_gate (15 ,& s p u r i o u s _ i n t e r r u p t _ b u g ) ;
set_trap_gate (16 ,& c o p r o c e s s o r _ e r r o r ) ;
set_trap_gate (17 ,& alignment_check ) ;
19
#i f d e f
CONFIG_X86_MCE
set_trap_gate (18 ,& machine_check ) ;
#e n d i f
set_trap_gate (19 ,& s i m d _ c o p r o c e s s o r _ e r r o r ) ;
set_system_gate (SYSCALL_VECTOR,& s y s t e m _ c a l l ) ;
Otra función importante que existen en el kernel, se trata de la función
request_irq,
que
permite habilitar una interrupción, siendo argumentos de la misma, el handler27 , y el número
de la interrupción que deseamos mapear. Esta función se encuentra redenida para varias de las
arquitecturas, siendo el handler generalizado el que se puede encontrar en
l/irq/manage.c
28
/usr/src/linux/kerne-
.
Una vez que se ha recibido la IRQ, (la interrupción que ha enviado la zona de usuario), se
realiza la gestión de la misma, como se puede ver en la<inicialización de las interrupciones, se
27
28
La función que maneja una interrupción.
Se pueden encontrar otras implementaciones de este código para otras arquitecturas:
arm: arch/arm/kernel/irq.c
arm26: arch/arm26/kernel/irq.c
sparc: arch/sparc/kernel/irq.c
sparc64: arch/sparc64/kernel/irq.c
Estos son los cheros donde podemos encontrar la implementación de la función que recoge las interrupciones.
236
asigna una función a cada interrupción que será llamada cuando se de dicha interrupción.
Nueva gestión de llamadas al Kernel: Sysenter29 .
La gestión de interrupciones, aún a pesar de estar lo más optimizada posible, siguen siendo
una tarea ardua y dura, dado que el kernel tiene que gestionar las puertas de llamada, y todo
el sistema de runlevels. Para mitigar esta deciencia, ha surgido una nueva manera de llamar
al Kernel, que se trata de sysenter, que mejora el rendimiento en las llamadas al kernel. Este
sistema es totalmente compatible con el anteriormente explicado, las interrupciones se pueden
llamar tanto por Systenter como por int80. Pero la instrucción systenter está más optimizada.
En los sistemas GNU/Linux, las llamadas a las syscalls se realizan desde la glibc, y en los
últimos tiempos se está llevando a cabo una transición desde las llamadas a las syscalls mediante
la interrupción 80, a la llamada más rápida Sysenter.
Por supuesto esta nueva gestión de llamadas se realiza únicamente en sistemas i386, siendo
especico de ésta arquitectura.
Gestión de las syscalls en zona de Kernel
Cuando llega una interrupción 80, el sistema de gestión de interrupciones explicado anteriormente delega la gestión a el handler de las syscalls, o en su defecto, se realiza una llamada a la
función sysenter, llamando al handler de las interrupciones.
Este handler es diferente para sysenter y para la interrupción int80, pero esencialmente realizan la mismo: Inspeccionan si la syscall que se quiere llamar está implementada (el número de
syscall es menor o igual que el número mayor de syscalls), si se produce esta situación se devuelve
un error. En caso contrario, se calcula la dirección donde se encuentra almacenado el handler30
que ha de tratar dichas syscall y se llama a dicha función devolviendo a zona de usuario lo que
el handler devuelva.
Listing 3.11: Gestión de la interrupción 80
#System
2
c a l l handler stub
ENTRY( s y s t e m _ c a l l )
p u s h l %eax
# s a v e orig_eax
SAVE_ALL
GET_THREAD_INFO( %ebp )
# system c a l l t r a c i n g i n
operation / emulation
/∗
7
Note , _TIF_SECCOMP i s
and
29
not
testb
bit
number
8,
so
it
needs
testw
∗/
Para mayor información: http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223/#more,
articulo sobre la optimización realizada por la instrucción sysenter[152].
30
and
La función que se va a encargar de tratar dicha syscall
237
t e s t w $ (_TIF_SYSCALL_EMU|_TIF_SYSCALL_TRACE|_TIF_SECCOMP|
_TIF_SYSCALL_AUDIT) , T I _ f l a g s( %ebp )
jnz syscall_trace_entry
cmpl $ ( n r _ s y s c a l l s ) , %eax
jae syscall_badsys
12
syscall_call :
c a l l ∗ s y s _ c a l l _ t a b l e (, %eax , 4 )
movl %eax ,EAX( %e s p )
# s t o r e t h e return v a l u e
syscall_exit :
cli
# make s u r e we don ' t m i s s an
interrupt
# s e t t i n g need_resched or
17
sigpending
# b e t w e e n s a m p l i n g and t h e
iret
movl T I _ f l a g s ( %e b p ) , %e c x
t e s t w $_TIF_ALLWORK_MASK,
%c x
# c u r r e n t −>work
jne syscall_exit_work
Listing 3.12: Gestión de la llamada sysenter
#S y s e n t e r
2
c a l l handler stub
ENTRY( s y s e n t e r _ e n t r y )
movl TSS_sysenter_esp0( %e s p ), %e s p
sysenter_past_esp :
sti
p u s h l $ (__USER_DS)
p u s h l %ebp
7
pushfl
p u s h l $ (__USER_CS)
p u s h l $SYSENTER_RETURN
12
/∗
∗
Load
∗
Careful
the
potential
about
sixth
argument
security .
∗/
cmpl $__PAGE_OFFSET−3, %ebp
jae syscall_fault
17
1:
movl ( %ebp ), %ebp
238
from
user
stack .
. s e c t i o n __ex_table , " a "
. align 4
. long 1b , s y s c a l l _ f a u l t
22
. previous
p u s h l %eax
SAVE_ALL
GET_THREAD_INFO( %ebp )
27
/∗
Note , _TIF_SECCOMP i s
and
not
testb
bit
number
8,
and
so
it
needs
testw
∗/
t e s t w $ (_TIF_SYSCALL_EMU|_TIF_SYSCALL_TRACE|_TIF_SECCOMP|
_TIF_SYSCALL_AUDIT) , T I _ f l a g s( %ebp )
jnz syscall_trace_entry
cmpl $ ( n r _ s y s c a l l s ) , %eax
jae syscall_badsys
32
c a l l ∗ s y s _ c a l l _ t a b l e (, %eax , 4 )
movl %eax ,EAX( %e s p )
cli
movl T I _ f l a g s( %ebp ) , %ecx
t e s t w $_TIF_ALLWORK_MASK, %cx
37
jne syscall_exit_work
/∗
if
something
modifies
registers
it
must
also
disable
sysexit
∗/
movl EIP( %e s p ) , %edx
movl OLDESP( %e s p ) , %ecx
x o r l %ebp, %ebp
42
sti
sysexit
Como se puede ver en los ejemplos mostrados, la llamada call, que se realiza en ambos códigos
(call
*sys_call_table(, %eax,4) ),
es la parte en la que se llama a la función que se encarga de
manejar cada syscall.
Estos punteros a funciones se almacenan en un vector llamado
sys_call_table,
y como cada
dirección de memoria en i386 son 4 bytes, multiplicando por cuatro el valor de eax , se obtiene
31
el oset32 necesario para calcular la dirección en la que se almacena el puntero a función que se
va a llamar.
El objeto
31
32
sys_call_table,
es de especial importancia, en versiones anteriores del kernel (de
En eax en ese momento se almacena el número de syscall que se está llamando.
desplazamiento
239
Figura 3.11: Esquema de llamada a una interrupción mediante interrupción
la rama 2.4 y anteriores) dicho objeto se encontraba disponible por parte de cualquiera de los
módulos que se cargasen en el sistema, y con realizar extern void* sys_call_table[]; se tenía acceso
a uno de los puntos mas importantes del sistema operativo. Este aspecto ha sido ampliamente
explotado por rootkits33 , lo que llevó a Linus Torvalds34 , a decidir eliminar esta exportación
haciendo algo más difícil algo que anteriormente era trivial. Esta ocultación no ha permitido
eliminar todos los sistemas de troyanización del kernel, dado que la dirección de la sys_call_table,
se puede seguir accediendo desde otros caminos que se explicarán posteriormente.
Como se puede ver también en ambos ejemplos el manejo del retorno de la función llamada
es también igual en ambos casos, ya que las funciones llamadas mediante call, devuelven el valor
de retorno en almacenado en la pila, por lo tanto lo que se realiza es almacenar el contenido de
la cima de la pila, que es el resultado de la syscall (todas las syscalls por convención devuelven
un long).
Denición del sistema de recogida de datos en sistemas GNU/Linux
Para llegar a la sección de plantear las posibles opciones de acceder a las llamadas al sistema
que se dan en un momento en el sistema se realizó un estudio de las técnicas utilizadas para
auditar las aplicaciones en sistemas GNU/Linux.
De un comienzo aparecieron varias opciones:
Realizar un sistema vírico que intercepte las llamadas a las syscalls.
Utilizar un sistema de logeo de syscalls convencional, como pueden ser strace y ptrace.
33
34
Sistemas de troyanización del kernel de linux.
Creador del Kernel de Linux, y actualmente mantiene una parte del desarrollo del mismo.
240
Figura 3.12: Logo de SuSE, distribución alemana, respaldada por la empresa Novell
Utilizar un sistema ya realizado por Novell : LAuS[261]35 .
Utilizar el sistema de auditoría snare[16].
Adaptar un sistema BSM[270] de auditoría en sistemas Solaris
Los requisitos planeados eran los siguientes:
Funcionamiento en todo tipo de plataformas / arquitecturas.
Funcionamiento en tiempo real y transparente para el usuario.
No haya necesidad de interacción con el usuario.
Dados los requisitos, se fueron analizando las diferentes opciones. El sistema LAuS, era un sistema desarrollado por Novell para la distribución SuSE en forma de parche del kernel de linux,
que permitía auditar las syscalls. Este sistema existe para que los sistemas SuSE obtuvieran el
certicado de seguridad informática CC EAL436 , esta solución aunque buena para los sistemas
que empleen SuSE, no es exible para los requisitos marcados por el sistema a emplear, y no se
ha probado en sistemas embebidos ni sistemas móviles. Además para funcionar necesita que el
kernel sea recompilado y es un proceso que para nada es transparente para el usuario.
El sistema LAuS, permite en ordenadores convencionales auditar a procesos, pero no ofrece
la exibilidad necesaria para realizar un proyecto con él, por lo que la opción de SuSE y Novell
quedó desechada por dichas razones.
Los sistemas de
strace
y
ptrace
37
,
permiten seguir a un proceso el curso de la ejecución de
otro en forma de syscalls, reciben las acciones del otro proceso, este sistema implementable en
35
36
Se trata de un sistema de auditoría realizado por Novell para SuSE
Estándar de seguridad informática Common Criteria Assurance Level 4 : Methodically Designed, Tested
and Reviewed. Analysis is supported by the low-level design of the modules of the TOE, and a subset of
the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development
controls are supported by a life-cycle model, identication of tools, and automated conguration management.[URL]http://www.cesg.gov.uk/site/iacs/index.cfm?menuSelected=1&displayPage=13
37
La función ptrace, permite, al igual que el comando strace, seguir el funcionamiento de otro proceso.
http://linuxgazette.net/issue81/sandeep.html
241
Figura 3.13: Logo del agente de snare para sistemas GNU/Linux
zona de usuario puede parecer en principio una buena opción, pero entraña un gran peligro, que
es fácilmente superable por el malware existente actualmente.
Listing 3.13: Prototipo de la función ptrace
#include
long
<s y s / p t r a c e . h>
int
p t r a c e ( enum __ptrace_request r e q u e s t , pid_t pid , void ∗ addr
, void ∗ data )
El sistema de funcionamiento del sistema ptrace, solamente permite que un proceso siga la
ejecución de un proceso dado, es decir, un solo proceso puede seguir el funcionamiento de otro.
Algunos de los sistemas antimalware para sistemas GNU/Linux hacían uso de la función ptrace,
y la manera que desarrollaron los hackers, fue crear dos procesos en el malware, y se suscribían
mutuamente excluyendo la posibilidad de que cualquier otro proceso se suscribiese a su propia
ejecución, con esta
ptrace
maniobra de evasión
y el comando
strace
el sistema de auditoría de syscalls mediante la función
se ve inutilizado.
Otro aspecto dentro de el sistema de strace/ptrace es que el sistema deja de ser trasparente
para el usuario si se ejecutan bajo el comando strace, ya que los programas han de ser ejecutados
mediante línea de comandos lo que deja al sistema sin posibilidad de ser independiente del usuario
del sistema operativo auditado.
Los sistemas BSM proporcionan un sistema de auditoría y de alertas para el seguimiento de los
usuarios. Se trata de un sistema que no solamente realiza un histórico de las syscall generadas por
el sistema, sino que se encuentra abierto a muchos tipos de eventos, como puede ser que se abra
una conexión ftp... Por lo tanto se trata de un sistema que genera un grupo heterogéneo de datos
de entrada38 , en los que pueden aparecen relaciones de dependencia entre los datos de entrada por
el nivel de abstracción de los mismos. Además existen varios tipos de datos (sobre todo syscalls
a bajo nivel), que han sido rechazados para el sistema, dado que generan muchas entradas y que
genera datos sin sentido
39
, esta supresión de datos, para un sistema de experimentación como
puede ser Mendizale, dichos datos, pueden dar un perl mucho más exacto de los procesos que
están siendo inspeccionados. Por otra parte los sistemas BSM, permiten auditar usuarios, pero
no procesos en particular, lo que ha ocasionado que auditar procesos mediante un sistema de
auditoría de usuarios, no dé la solución más óptima.
38
Es decir, podemos encontrar, por una parte datos de muy alto nivel como puede ser la apertura de una
conexión ftp, y con datos de muy bajo nivel, como por ejemplo una syscall.
39
En concreto: Several audit classes were excluded because they did not generate meaningful information (or
generated too much data). 242
El sistema Snare[16], realizado por la empresa
intersec alliance,
es un sistema global de
detección de intrusiones el cuál dispone de un sistema de logeo de syscalls, que permite generar
reglas estáticas al administrador que genera alarmas cuando dicho evento se da en el sistema.
Este agente utiliza un sistema de auditoría, y por el momento únicamente funciona en Redhat
Enterprise Linux 4.0 U3, y ha sido testado en Fedora Core, en sistemas como Ubuntu Linux de
Canonical, no es funcional todavía, esta situación ha propiciado que este sistema que es funcional
haya sido rechazado en detrimento de la realización de un sistema de recogida de datos propio.
Por lo tanto las líneas que se han seguido han sido utilizar técnicas víricas que permitan
auditar el kernel de linux a bajo nivel. Este proceso se puede llevar a cabo de varias maneras,
pero siempre insertando código a nivel de kernel en forma de LKM40 .
Desarrollo del sistema de recogida de datos en sistemas GNU/Linux
Una vez denida cuál va a ser la losofía del sistema, se investigó cuáles eran las opciones
posibles:
Desarrollar un parche del kernel, conceptualmente puede que sea una buena solución dado
que modicar código que no está en ejecución puede ser mas seguro41 , que otras opciones,
pero no era una opción válida, dado que la transparencia con el usuario queda sustancialmente reducida con un proceso como recompilar el kernel.
Desarrollar un módulo del kernel de linux que secuestre las funciones del vector sys_call_table,
la cual era la opción más válida para el proyecto, y la que se ha desarrollado.
Por lo tanto, el sistema elegido ha fue un módulo del kernel que realice la recogida de datos, pero
existen también varias opciones en cuanto al acceso a las funciones llamadas a bajo nivel, por
lo tanto uno de los mayores problemas a la hora de desarrollar el sistema de recogida, ha sido
seleccionar qué método se utiliza a la hora de secuestrar las llamadas.
Para seleccionar el método necesario se ha tenido en cuenta la interoperabilidad entre diferentes plataformas o arquitecturas42 , y el impacto sobre el sistema operativo43 .
Los métodos implementados y estudiados para la elección del método denitivo, fueron dos:
Modicar las entradas de la
sys_call_table
para que en vez de que se llamen las funciones
que se han de encargar de las syscalls, se llame a funciones nuestras. Este sistema tiene la
complejidad añadida de que desde el kernel 2.5 el símbolo
sys_call_table,
no se encuentra
exportado en el kernel.
40
Loadable Kernel Module: Se trata de una sección de código que una vez compilada se la permite ser descargada
y carga en el kernel de linux.
41
Existen menos posibilidades de que se de un Kernel Panic modicando código fuente, que redireccionando
direcciones de memoria en tiempo de ejecución dado que puede tener consecuencias imprevisibles.
42
Alguno de los métodos utiliza código nativo a la hora de realizar la intercepción de las llamadas, y uno de los
requisitos de este sistema de recogida de datos era la interoperabilidad entre diferentes arquitecturas.
43
El tiempo de retraso que se puede dar por un proceso como el de la auditoría de syscalls.
243
Modicar en tiempo de ejecución el código de manipulación de las syscalls del kernel para
que en vez de realizar las funciones originales se llame a un método denido por nosotros.
Las dos opciones comentadas fueron han sido realizadas y probadas, para decidir cuál de las dos
era la mejor opción.
Desarrollo de sistema de recogida de datos basado en intercepción de sys_call_table
Esta opción, lo que realiza es la suplantación de las direcciones de memoria almacenadas
en la variable sys_call_table, haciendo que cuando se ejecute una llamada a una syscall (tanto
mediante la interrupción 80, como la llamada sysenter), se llame a una función propia.
El mecanismo de funcionamiento es muy simple, se realiza un módulo del kernel, que cuando
se cargue modique las entradas necesarias en el vector de direcciones, y que cuando se descargue
las deje como las encontró. El mecanismo de funcionamiento de los módulos del kernel permiten realizar esta tarea sin problemas, dado que la estructura básica de un módulo del kernel,
únicamente dispone de dos funciones, una que se la llama al cargar44 , y otra que se llama al
descargarse45 .
Listing 3.14: Ejemplo de un módulo básico
3
#include
<l i n u x / module . h>
#include
<l i n u x / k e r n e l . h>
#include
<l i n u x / timex . h>
static
int
__init f e n t _ i n i t ( void ) {
p r i n t k (KERN_INFO " H o l a s o y un LKM e n modo r e a l O_o"
! ! ! \ n" ) ;
return
0;
}
8
static
v o i d __exit f e n t _ e x i t ( v o i d ) {
p r i n t k (KERN_INFO " Se d e s c a r g a e l LKM. . . \ n " ) ;
}
13
module_init ( f e n t _ i n i t ) ;
module_exit ( f e n t _ e x i t ) ;
MODULE_LICENSE( "GPL" ) ;
44
Existen dos maneras de cargar módulos en el kernel, una mediante el comando insmod (que no carga los
módulos dependientes necesarios, y que carga el módulo desde cualquier localización), y el comando modprobe,
que realiza la carga tanto del módulo como de los módulos dependientes necesarios (los módulos han de estar
localizados en un sitio concreto de la jerarquía de cheros).
45
Mediante el comando rmmod.
244
El problema surge cuando deseamos buscar la dirección de memoria de la variable sys_call_table,
como ya hemos comentado anteriormente, a partir del kernel 2.5 no está disponible en el kernel
directamente. Las opciones para realizar el calculo de esta dirección son varias, este valor, se
encuentra almacenado en el chero System.map, resultante de compilar el kernel, en este chero
se encuentran las direcciones46 en las que se almacenarán las variables del kernel, y en este chero
sí que aparece la variable que nos interesa: sys_call_table.
Por lo tanto podemos copiar esta dirección, y embeberla en el código fuente para disponer
de una referencia a la dirección de memoria en la que se encuentra el vector de direcciones. Otra
opción sería también pasar la dirección mediante un parámetro del LKM, y en el script para
introducir, realizar una manipulación de System.map para que encuentre la dirección adecuada.
Esta solución es viable siempre y cuando se disponga del System.map del kernel que queremos auditar, no hace falta recompilar el kernel, sino que el System.map sea el original de la
compilación.
Si el chero System.map, no estuviese disponible o si la versión del mismo no fuese la original
existe otro método para localizar la dirección de la misma, se trata de buscar en el código que se
está ejecutando la dirección. El método[313] es bastante lógico, existe una función que permite
conocer la dirección base de la tabla IDT47 , por que entrando a la entrada 80, tenemos el handler
de la interrupción 80 que es la que se encarga de tratar las syscalls.
En este momento disponemos de el puntero a la función que se encarga de tratar las int80,
y mediante un memcpy48 , lo que hacemos es copiar el código de la función que se encarga de
tratar las syscalls (aparece anteriormente la sección de código que se encarga de ello).
Por lo tanto, para encontrar la dirección tenemos que buscar la llamada call que se realiza
desde el código fuente por lo que buscamos los códigos de operación
0x 0x14 0x85
49
, que se
corresponden a la llamada call, y posteriormente encontramos la dirección de la sys_call_table,
este método permite localizar la syscall table, pero tiene varios problemas que se detallarán a
continuación.
Listing 3.15: Función que obtiene la base del vector de syscalls
s t a t i c void
int
g e t _ s y s _ c a l l _ t a b l e ( void ) {
i;
unsigned i n t
char
sys_call_off ;
sc_asm [ SIZE ] ;
5
asm ( " s i d t %0" : "=m" ( i d t r ) ) ;
p r i n t k ( " [ + ] i d t r b a s e a t 0 x %08x \ n " , i d t r . b a s e ) ;
46
47
48
49
Direcciones físicas en las que se van a almacenar
La tabla IDT es el vector de interrupciones.
función de C, que se encarga de copiar una zona de memoria a otra.
Se trata código ensamblador, que se ocupa de hacer una call.
245
memcpy(& i d t , ( void ∗ ) ( i d t r . b a s e +8∗0x80 ) , s i z e o f ( i d t ) ) ;
s y s _ c a l l _ o f f = ( i d t . o f f 2 << 1 6 ) | i d t . o f f 1 ;
10
p r i n t k ( " [ + ] i d t [ 8 0 h ] d e s c r i p t o r p o i n t s t o 0 x %08x \ n " ,
sys_call_off ) ;
memcpy( sc_asm , ( void ∗ ) s y s _ c a l l _ o f f , SIZE ) ;
for (
i =0; i <SIZE ; i ++)
if
15
( ( sc_asm [ i ] == ' \ x f f ' ) &&
( sc_asm [ i +1] == ' \ x 1 4 ' ) &&
( sc_asm [ i +2] == ' \ x 8 5 ' ) ) {
printk ( " [+] s y s _ c a l l _ t a b l e c a l l found ! ( at
b y t e %d f r o m 0 x %08x a d d r e s s ) \ n " , i ,
sys_call_off ) ;
break
;;
}
20
if
( i <SIZE ) {
s y s _ c a l l _ t a b l e = ( void ∗ ) ∗ ( ( i n t ∗ ) &sc_asm [ i +3]) ;
p r i n t k ( " [ + ] s y s _ c a l l _ t a b l e a t 0 x %p \ n " , s y s _ c a l l _ t a b l e
);
} else {
printk ( " [ −] s y s _ c a l l _ t a b l e not found ! " ) ;
25
}
}
El código que hemos mostrado tiene el problema de que es muy dependiente de la arquitectura
en la que esté implementado el sistema, por lo que topa con el requisito marcado de independencia
de la arquitectura, dado que el código no sólo se quiere utilizar para arquitecturas i386, sino
también para arquitecturas ARM..., esta opción aunque atractiva, fue desechada.
Por lo tanto el sistema para encontrar la dirección mediante la búsqueda de la dirección de
la base del vector de syscalls, fue desechado en favor del método del System.map, siendo este un
sistema más exible para la utilización en diferentes arquitecturas.
Listing 3.16: Ejemplo de la intercepción de la syscall Kill
3
#include
<l i n u x / k e r n e l . h>
#include
<l i n u x / module . h>
#include
<l i n u x / i n i t . h>
#include
<l i n u x / t y p e s . h>
/∗
∗ Direccion
de
memoria
sacado
directamente
246
de
s y s t e m . map ,
la
entrada
es
:
sys_call_table
∗ ∗/
8
SYSCALLDIR 0 xc03337e0
#d e f i n e
MODULE_LICENSE( " GPLv2 o r l a t e r " ) ;
static
int
( ∗ k i l l _ s a v e d ) ( pid_t , i n t ) ;
almacenar
el
valor
∗ Direccion
de
memoria
// P u n t e r o
a
funcion
para
inicial
/∗
es
:
sacado
directamente
de
s y s t e m . map ,
la
entrada
sys_call_table
∗ ∗/
13
long
∗ s y s _ c a l l _ t a b l e = ( long ∗ ) SYSCALLDIR ;
static
int
m i _ k i l l ( pid_t pid , i n t s i g )
{
struct
del
task_struct ∗ ptr = current ;
// P i l l a m o s
la
instancia
pcb
p r i n t k ( " K Â ½ l l s i g n a l : %d u s u a r i o %d p i d : %d \ n " , s i g , ptr −>
18
uid , ptr −>p i d ) ;
return
( ( ∗ k i l l _ s a v e d ) ( pid , s i g ) ) ;
}
int
__init i n i t _ i n t e r c e p t ( void )
{
p r i n t k ( " M e n d i z a l e module l o a d e d \n" ) ;
23
gettimeofday_saved = ( int ( ∗ ) ( struct t i m e v a l
∗ , struct
t i m e z o n e ∗ ) ) ( s y s _ c a l l _ t a b l e [ __NR_gettimeofday ] ) ;
k i l l _ s a v e d = ( i n t ( ∗ ) ( pid_t , i n t ) ) ( s y s _ c a l l _ t a b l e [ __NR_kill ] )
;
s y s _ c a l l _ t a b l e [ __NR_kill ] = ( unsigned long ) m i _ k i l l ;
s y s _ c a l l _ t a b l e [ __NR_gettimeofday ] = ( unsigned long )
mi_gettimeofday ;
return
28
0;
}
void
__exit e x i t _ i n t e r c e p t ( void )
{
/ ∗ Lo d e j a m o s
todo
como
e s t a b a ∗/
s y s _ c a l l _ t a b l e [ __NR_kill ] = ( unsigned long ) k i l l _ s a v e d ;
33
s y s _ c a l l _ t a b l e [ __NR_gettimeofday ] = ( unsigned long )
gettimeofday_saved ;
}
247
module_init ( i n i t _ i n t e r c e p t ) ;
module_exit ( e x i t _ i n t e r c e p t ) ;
Por lo tanto, este método realiza una suplantación de las direcciones del vector de syscalls
original, esto supone que cuando una función kill es llamada, la función kill original, no es llamada,
sino que se llama realmente a la función suplantada por nosotros. Para no levantar sospechas ni
modicar el funcionamiento de las syscalls originales, después de realizar lo que queremos (en
el caso del ejemplo un simple printk), llamamos a la función kill original, devolviendo lo que la
función original ha devuelto. De este modo se consigue un logeo transparente al usuario.
Desarrollo de un sistema de recogida de datos basado en la modicación en tiempo
de ejecución de la rutina de tratamiento de las syscalls.
Este sistema de tratamiento ha sido desarrollado por parte de un hacker[292], para un rootkit
a nivel de kernel para kernels de la rama 2.6. Este sistema, utiliza una manera diferente para
interceptar todas las llamadas, en lugar de suplantar las direcciones a las que llama la rutina de
tratamiento de las syscalls, modica la rutina de tratamiento con técnicas víricas para ejecutar
su propia función cada vez que llega una syscall.
Este método, tiene la ventaja de que modicando en un solo punto50 el código fuente, ya
hookea todas las syscalls, su funcionamiento es eminentemente vírico. Su funcionamiento es
parecido al de un virus, modica el código que se va a ejecutar.
Listing 3.17: Líneas que son sobreescritas con un salto a la función.
a r c h / i 3 8 6 / k e r n e l / e n t r y . S −−−−
2
# system c a l l h a n d l e r s t u b
ENTRY( s y s t e m _ c a l l )
p u s h l %eax
# s a v e orig_eax
SAVE_ALL
GET_THREAD_INFO( %ebp )
7
cmpl $ ( n r _ s y s c a l l s ) , %eax //−−−>
Estas
instrucciones
seran
las
que
jae syscall_badsys
//−−−>
sobreescribiremos
con
nuestro
salto .
# system c a l l t r a c i n g i n o p e r a t i o n
12
t e s t b $_TIF_SYSCALL_TRACE, TI_FLAGS( %ebp )
jnz syscall_trace_entry
50
En el desarrollo anterior, hay que sustituir tantas direcciones a función como syscalls queremos hookear.
248
syscall_call :
c a l l ∗ s y s _ c a l l _ t a b l e (, %eax , 4 )
movl %eax ,EAX( %e s p )
17
# s t o r e t h e return v a l u e
....
−−−− e o f −−−−
Exactamente el sistema inserta un salto en la comprobación de si el número de syscall es
mayor al permitido (cmpl
$(nr_syscalls), %eax ),
y el salto condicional a sys_badsys si el número
de syscall no es el permitido. Estas acciones debemos realizarlas nosotros mismos dentro de la
rutina a la que lleva el salto. Estas dos operaciones ocupan en total 11bytes51 , lo más sencillo
será cambiar por un pushl y un ret52 , los cuales ocupan 6 bytes.
Este método ha de llevarse a cabo tanto en el handler de sysenter como en el de la interrupción
80, modicando en ambos los bytes concretos (en los dos sitios se realiza la misma comprobación).
Por lo tanto mediante este sistema podríamos tener un sistema que logease las interrupciones
o llamadas a la función sysenter sin tocar las direcciones de la sys_call_table.
El problema que plantea este método es la poca portabilidad que ofrece, dado que el código
que sobreescribe es altamente dependiente de la arquitectura sobre la que se ejecuta el sistema,
y además la dirección a la que salta es una shellcode53 , que por supuesto, es dependiente de
la arquitectura sobre la que se ejecute el sistema. Por lo tanto, este método, aunque limpio
y efectivo, se trata de un método ampliamente dependiente de la arquitectura en la que esté
implementado.
Listing 3.18: Shellcode a la que saltamos cuando se llama a la función.
char
idt_handler []=
//
( el
sysenter_handler
es
identico )
" \ x 9 0 \ x 9 0 \ x 9 0 \ x 9 0 \ x 9 0 \ x 9 0 \ x 9 0 \ x 9 0 \ x 9 0 \ x3d \ x 1 2 \ x 0 1 \ x 0 0 \ x 0 0 \ x 7 3 \ x 0 2
"
" \ xeb \ x06 \ x68 \ x90 \ x90 \ x90 \ x90 \ xc3 \ x83 \ x f 8 \ x25 \ x74 \ x06 \ x68 \ x90 \ x90
"
" \ x90 \ x90 \ xc3 \ x f f \ x15 \ x90 \ x90 \ x90 \ x90 \ x68 \ x90 \ x90 \ x90 \ x90 \ xc3 " ;
Mecanismo elegido, y detalles de implementación del mismo
Tras las dos aproximaciones que se desarrollaron, se decidió generar un sistema de recogida
de datos mediante la sobreescritura de la sys_call_table, dado que se trata del método arquitectónicamente más neutro y más transparente para el usuario. Por lo tanto el sistema que se
ha implementado necesita el archivo System.map original para funcionar. Esto implica que o
51
52
53
6 bytes el salto condicional y 5 la comparación.
Inserta un valor en la pila del sistema y salta a él mediante el ret.
código ensamblador embebido en el código fuente del LKM.
249
bien se ha compilado el kernel, o bien junto con el mismo se incluyen los archivos System.map
originales54 .
La naturaleza desestructurada del Kernel de linux, ha puesto alguna traba al desarrollo del
proyecto, como las cabeceras de las funciones que han de reemplazar a las originales han de ser
exactamente iguales, se hacía necesario buscar las declaraciones de las funciones por todo el árbol
de directorios del Kernel. Para automatizar todo este sistema, se desarrolló un script en Shell
script, que generaba las funciones necesarias para hookear todas las syscalls del kernel de linux.
Otro de los escollos a superar ha sido la comunicación kernel / userland que había que realizar,
dado que la intercepción se realiza a nivel de Kernel, y el análisis del mismo se realiza en otra
máquina. Este sistema implica que hay que realizar una comunicación kernel-userland, existiendo
las siguientes alternativas para que esta comunicación exista:
Netlink sockets Kernel-Userland.
Dispositivos de caracteres.
Dispositivos /proc.
Finalmente la comunicación se estableció mediante dispositivos /proc, generando un dispositivo55
mediante el cual se puede controlar el agente, ver estadísticas y para recibir las syscalls logeadas.
Listing 3.19: Ejemplo de la creación y destrucción de un dispositovo /proc.
1
static
int
if
__init p r o c _ i n i t ( void ) {
( ( p r o c F i l e = c r e a t e _ p r o c _ e n t r y ( " e j e m p l o " , 0 6 4 4 , NULL) )==
NULL)
{
remove_proc_entry ( " e j e m p l o " , &proc_root ) ;
p r i n t k (KERN_ALERT " E r r o r : C o u l d n o t c r e a t e p r o c
6
entry \n" ) ;
return
−ENOMEM;
}
p r o c F i l e −>owner = THIS_MODULE;
p r o c F i l e −>p r o c_ i o p s = &InodeAllowedOps ;
p r o c F i l e −>proc_fops = &FileAllowedOps ;
11
p r o c F i l e −>mode = S_IFREG | S_IRUGO | S_IWUSR;
p r o c F i l e −>u i d = 0 ;
p r o c F i l e −>g i d = 0 ;
p r o c F i l e −>s i z e = 1 0 0 0 ;
54
55
Echo que se da en la gran mayoría de las distribuciones de linux actuales.
Concretamente /proc/sysmonitor.
250
return
16
0;
}
s t a t i c void
__exit p r o c _ e x i t ( void ) {
remove_proc_entry ( " t e t a " , &proc_root ) ;
}
La ventaja de utilizar este tipo de dispositivos radica en que su creación es automática, al
contrario de los dispositivos de caracteres, para los que hay que ejecutar el comando
además permiten la ejecución de comandos como
cat, tail...,
mknod,
de esta manera la utilización del
sistema es mucho más sencilla y simple para el usuario, que utilizando mecanismos netlink, en los
cuales hay que recompilar el kernel y manejar complejas APIs para realizar dicha comunicación.
Otro de los grandes escollos que planteó la implementación del sistema de recolección, fue la
sincronización en el kernel y evitar que ocurran condiciones de carrera56 , para lo que se utilizaron
sistemas de sincronización a nivel de kernel, esto se da por la naturaleza multiproceso de los
sistemas GNU/Linux y que hacen que un proceso pueda pararse en cualquier momento para
que su ejecución sea relevada por otro, este proceso plantea el problema de como que algunos
procesos pueden escribir en zonas que otro proceso este leyendo.
Los sistemas utilizados han sido los siguientes:
spin_locks: Cerrojos, que los procesos abren y / o cierran mediante operaciones atómicas57 ,
y que permiten hacer exclusiva la utilización de un recurso por parte de un proceso.
Semáforos a nivel de kernel, con un funcionamiento similar a los semáforos a nivel de
usuario.
Colas de espera.
Mediante estos métodos se ha realizado un sistema de recepción de datos que ante pruebas de
stress no pierde datos ni entra en condiciones de carrera. Esta parte es importante dado que un
fallo, o un interbloqueo a nivel de kernel, puede ser especialmente dañino, dado que hay grandes
posibilidades de que el sistema sufra un
kernel panic
58
.
Existe una sola situación en la que se desechan datos de syscalls, que es cuando el buer en el
que se almacenan los datos se llenan (es decir, no se ha leído lo suciente), para evitar un buer
overow.
Otra situación que ha habido que solventar es la identicación del proceso, dado que cuando
estamos recibiendo la syscalls de un proceso, podemos saber el identicativo del proceso que
recibe dichas peticiones, pero no sabemos el nombre del ejecutable, para ello se utiliza un método
56
También conocidas como race conditions, se producen cuando dos o más procesos se quedan interbloqueados
a la espera de un recurso que nunca se va a liberar.
57
58
El proceso no se puede quedar a mitad de ejecución de dicha operación.
Nombre con el que se conoce a los fallos de Kernel.
251
que permite identicar el ejecutable del que proviene dicho proceso, de esta manera se puede
identicar no solamente el nombre del proceso59 , sino el ejecutable responsable de dicho proceso.
Listing 3.20: Código que permite saber el ejecutable padre del que proviene el proceso.
∗ GetEXE( void )
i n t char
{
if
( c u r r e n t −>mm) {
struct
(vma) {
while
5
vm_area_struct ∗ vma = c u r r e n t −>mm−>mmap;
if
( ( vma−>vm_flags & VM_EXECUTABLE) && vma−>vm_file ) {
char
∗ buf = k m a l l o c (PAGE_SIZE, GFP_KERNEL) ;
char
∗p ;
if
( buf == NULL) return NULL;
memset ( buf , 0 , PAGE_SIZE) ;
10
p = d_path (vma−>vm_file −>f_dentry , vma−>vm_file −>f_vfsmnt ,
buf , PAGE_SIZE) ;
if
( ! IS_ERR( p ) ) {
memmove( buf , p , s t r l e n ( p ) + 1 ) ;
return
( const char ∗ ) buf ;
}
15
k f r e e ( buf ) ; return NULL;
}
vma = vma−>vm_next ;
}
}
20
return
NULL;
}
El texto se envía en formato texto plano a la zona de usuario, debiendo el agente de zona de
usuario parsear 60 cada cadena de texto para conseguir toda la información.
Este agente de zona de usuario, conecta el sistema de recolección de datos con la infraestructura del sistema de análisis de Mendizale, enviando por red la información recogida por el agente
en el kernel de linux.
3.2.2. Recogida de información en sistemas Windows Mobile.
Windows Mobile es un sistema operativo compacto basado en el API Win32 de Microsoft, que
combinado con una serie de aplicaciones especícamente diseñadas para este tipo de sistemas,
59
60
Que se puede obtener del valor comm del task_struct que apunta current.
Extraer las diferentes partes de información de una unidad. En este caso concreto de una línea de texto.
252
da soporte a muchos de los dispositivos móviles que se encuentran hoy en el mercado61 .
Los sistemas Windows Mobile, en la totalidad de sus versiones Windows CE 3.X, 4.X y 5.X
presenta unas características especiales en el manejo de memoria62 , comunicación entre procesos...
que hacen imposible reutilizar herramientas desarrolladas para la auditoría de syscalls en sistemas
Windows convencionales en este tipo de sistema operativo.
Cuestiones de Desarrollo.
Los sistemas Windows CE, carecen por completo de sistemas de debuggeo o de programación
a bajo nivel, por lo que el desarrollo de cualquier tipo de aplicación o de agente de recolección de
información, suponía un gran esfuerzo por parte del equipo de investigación. Afortunadamente,
en la última versión del sistema de desarrollo Microsoft Visual Studio 2005, conscientes de la
situación que existía, Microsoft ha incorporado funcionalidades de depuración en tiempo real y
remotos de aplicaciones para Windows CE.
En concreto, la última versión de Windows Device Emulator, soporta la emulación real
de aplicaciones para Windows CE en todas sus versiones, lo que permite que una aplicación
pueda ser probada y desarrollada en un dispositivo63 que tenga las mismas características y
funcionalidades que el dispositivo nal en el que se va a ejecutar la aplicación nal. Este echo ha
facilitado la investigación dado que se ha podido emular y desarrollar el agente en un ambiente
idéntico al de un dispositivo físico real.
De esta manera en este momento es posible debugear directamente sobre el dispositivo físico
o sobre el emulador, pudiendo incluso atachearse 64 a procesos activos bien en la máquina real,
o en el emulador.
Sistema de llamadas al Kernel de Windows CE
El sistema de llamadas al kernel de Windows CE, es similar al de sus hermanos mayores,
los ejecutables tienen un formato PE65 , por lo que las llamadas al kernel de NT, no se realizan
directamente desde los programas sino que se realizan desde diferentes DLL que realizan dichos
accesos en lugar del el proceso directamente.
61
A nales del 2004 ya se hizo líder de ventas de software para este tipo de dispositivos por delante de PalmOS.
http://www.canalpda.com/displayarticle180.html
62
Los sistemas Windows Mobile, poseen un mecanismo propio de protección de memoria, que establece una capa
de abstracción entre la memoria virtual ofrecida por el procesador y la memoria que utilizan los procesadores. Este
mecanismo permite controlar los accesos de lectura / escritura a zonas de memoria que no hayan sido reservadas
anteriormente en la capa de abstracción[298].
63
64
Se trata de un dispositivo virtual, pero de las mismas características que un sistema Windows CE normal.
Se trata de una técnica de depuración que permite parar procesos en ejecución y ver lo que están ejecutando
en cada momento.
65
Portable Ejecutable, formato de archivo ejecutable introducido en la versión 3.1 del kernel de NT. Inspirado
en el formato COFF de sistemas Unix-like, mantiene la compatibilidad con todas las versiones de Windows. De
ahí el nombre de Portable.
253
Figura 3.14: Esquema del formato Portable Ejecutable
Este proceso es similar al que realiza la glibc, en sistemas GNU/Linux, pero en este sistema,
las llamadas las realizan diferentes DLLs en vez de una sola librería como la glibc.
Dada que la ubicación de las DLL dentro del sistema del usuario puede variar de una instalación a otra, el PE ha de especicar en la cabecera las DLL que va a necesitar, para que el loader
resuelva en dinámicamente las dependencias y si es necesario cargue las DLL que no estuvieran
cargadas en ese momento. De la misma manera, el formato PE, dene en la IAT66 , las funciones
que necesita de las DLL.
Desarrollo del sistema de recogida de datos para Windows Mobile
Para realizar la recogida de datos necesaria para el proyecto hace falta interceptar en algún
punto la llamada en cualquiera de sus fases desde la IAT, hasta el dispacher del kernel de Windows
CE.
Para realizar dicha aproximación varias opciones fueron barajadas[247], la primera de ellas
consistía en la modicación en la memoria permanente de las DLL involucradas en las llamadas
al Kernel de Windows CE. De esta manera sería posible inyectar código en cada DLL, o realizar
un wrapper67 sobre la misma. Sin embargo este proceso llevaría consigo la necesidad de modicar
la memoria ROM de todos los dispositivos en los que se quiere instalar el agente.
Soluciones heredadas de sistemas Windows, como la de modicar la IAT de todos los procesos
del sistema, o inyección de código en las entradas de las funciones exportadas por las DLL fueron
desechadas por el coste computacional que necesitaban y la limitada potencia de cálculo de los
sistemas ARM en los que se ejecuta Windows CE.
66
67
La IAT es el lugar donde el cargador escribe las direcciones de las funciones exportadas de alguna DLL.
Nombre técnico para un envoltorio software de ciertas funciones o DLLs.
254
Figura 3.15: Esquema de llamadas para ejecutar una operación a nivel de kernel.
La única solución una vez desechada las ideas anteriores, fue la de realizar una recogida de
datos a nivel de kernel, modicándolo en tiempo real, para que el usuario nal no tenga que
realizar pesadas instalaciones ni ralentice el sistema.
Para implementar una solución de este tipo, se necesita un gran conocimiento de cómo se
enumeran internamente las funciones, y de cómo se trata Windows CE las llamadas a las funciones
de su kernel. Pero, afortunadamente Microsoft liberó parte de las especicaciones internas de
su sistema operativo para sistemas móviles en el cuál se podían ver la distribución de ciertas
estructuras del kernel de linux, y de ciertas llamadas no documentadas del API de Windows CE,
en concreto la llamada PerfomCallBack4, ha sido de especial interés para el estudio que ha sido
llevado a cabo.
Entre los datos que se encontraron en dichas especicaciones, se encuentran varias estructuras
de gran importancia como puede ser la KDataStruct, que incluye información interna sobre
todo el sistema, y se encuentra siempre en la misma dirección de la memoria68 . Dentro de esta
estructura podemos encontrar:
SYSHANDLE_OFFSET: que da acceso al proceso actual.
KINFO_OFFSET: que da acceso a un array de estructuras UserKInfo, que poseen informaciones tan importantes como la lista de módulos, el heap del kernel, y la importantísima
tabla de punteros a las API, SystenAPISets.
En Windows CE existen dos tipos de API, las implícitas y las basadas en handles . Las
primeras son accesibles de forma global mediante el uso de la tabla de punteros a las API, encon68
En concreto se encuentra en las direcciones 0xFFFFC800 para el procesador ARM y 0x00005800 para el resto
de CPU soportadas por el sistema.
255
Figura 3.16: Esquema de la información contenida en la estructura KDataStruct
trándose indexadas por su el identicativo de su categoría (SH_WIN32, SH_GDI, SH_WMGR,
etc.) y su número de API. Este tipo de interfaces, se encuentran contenidas en objetos de kernel
como mutex o eventos y son referenciadas mediante su número de API y el puntero (handle)
al objeto que las contiene. Este tipo de APIs no son actualmente monitorizadas por el agente
desarrollado.
En los sistemas Windows CE, las llamadas a las funciones del kernel, se realizan mediante la
llamada a unas direcciones de memoria especiales llamadas
traps ,
que generan una excepción
que son gestionadas por el dispacher del kernel de Windows CE.
La manera más limpia y rápida de realizar una auditoría de las syscalls que ocurren en un
sistema Windows CE, es modicar los punteros de las funciones que realizan la gestión de las
excepciones generadas por los traps, para registrar los datos que nos son relevante para luego
devolver el control a la función original suplantada por nuestro agente.
Como algunas funciones del Kernel de Windows CE, realizan una comprobación de que el
propietario del thread en ejecución lo que hace que el agente deba de residir dentro del propio
thread.
Además como ya se ha comentado con anterioridad, las llamadas a las funciones del kernel de
Windows CE, se abstraen dentro de llamadas a DLLs, en este caso, existe una DLL, coredll.dll,
que mantiene una caché con las direcciones de las funciones que tratan las llamadas, por lo
tanto mediante este sistema que hemos explicado, ocurre el problema de que las funciones que
son llamadas desde coredll.dll, no serían redireccionadas debido a la caché que mantiene en su
interior.
Para ello, si queremos también capturar las llamadas de la librería core.dll, habremos de
modicar las la cache de la librería para todos los procesos.
Al igual que en los procesos en Windows NT/2000, la inyección de una DLL, pasa por
funciones no documentadas, en este caso PerfomCallBack4, que provoca la creación de un thread
256
Figura 3.17: Detalle de interfaz de usuario del agente.
remotamente en el proceso que se desee. La inyección previa de un código binario que efectúe la
llamada a loadlibrary, hace el resto.
Existe también la necesidad de monitorizar también las llamadas de los nuevos procesos que
se creen y no solamente de los que ya existan el sistema en el momento de la carga, por lo que
también es necesario monitorizar la llamada CreateProcess de la API del kernel, para realizar el
mismo proceso con los nuevos procesos.
Por lo tanto una vez denida la metodología a seguir, se dividió el desarrollo en dos partes
separadas:
El apartado de modicación de la caché de coredll.dll, de la inyección de una dll en todos los procesos que llamen a las funciones nuestras, y la monitorización de la función
CreateProcess, para realizar lo mismo con los procesos nuevos.
El apartado de comunicación con la infraestructura de Mendizale y de interfaz de usuario.
La comunicación entre ambos componentes se realiza mediante la librería HTRACE[356], que
permite la comunicación entre las dos partes del sistema mediante memoria compartida implementado como un buer circular.
El apartado de comunicación con la infraestructura de Mendizale, lo que realiza es leer las
llamadas al Kernel de Windows CE del buer circular, y enviarla mediante una conexión TCP
a la infraestructura.
La gestión de la conguración y de la interfaz de usuario sigue dos caminos separados, por
una parte la conguración de las llamadas que son capturadas y las que no, cuestión que sea
realiza mediante un chero XML, en el que se especica qué llamadas son capturadas y cuáles
no.
Por otra parte se puede congurar el puerto y dirección ip a la que se puede enviar el resultado
de la captura de las llamadas mediante la interfaz gráca, que es minimalista pero muy potente.
El sistema inserta un icono en el systray de Windows Mobile, estando en todo momento visible
y mostrando menús de conguración con el botón derecho del ratón.
Este sistema de interfaz gráca también permite parar y arrancar el sistema de logeo de las
llamadas, lo que permite al usuario del sistema nal controlar solamente los aspectos necesarios
para él.
257
3.2.3. Recogida de información en sistemas Windows.
Tradicionalmente Microsoft no ha caracterizado por permitir al usuario nal acceder a bajo
nivel a su plataforma Windows. Sin embargo la gran cantidad de usuarios que utilizan esta
plataforma siempre ofrece gran cantidad de información a los investigadores de los sistemas
operativos.
Desde que Desde que Windows 95 viera la luz en Agosto de 1995, se han publicado muchos
estudios y ensayos, sobre su funcionamiento interno y programación a bajo nivel. Gran parte de
estas investigaciones han sido llevadas a cabo por la comunidad de programadores de virus[315]
, que vieron en esta plataforma un entorno ideal al que migrar sus creaciones.
Actualmente, existen 3 grandes ramas en el mundo Windows. Por una parte tenemos la
conocida rama 9x, surgida del nacimiento de Windows 95, y dirigida al mercado doméstico.
Dada su orientación, la rama 9x carece de mecanismos de seguridad avanzados y permite una
gran exibilidad y compatibilidad con aplicaciones heredadas de MSDOS y Windows 3.x. La
rama 9x comprende también los sistemas operativos Windows 98 (1998) y Windows Millenium,
además de las diferentes revisiones de los mismos, Windows 95 OSR2, Windows 98 SE, etc.
Por otra parte encontramos la rama NT (New Tecnology), que surgió en la década de los
noventa con una clara vocación profesional, esta familia de sistemas operativos (Windows NT
3.X, Windows NT 3.5.X, Windows NT 4.X y Windows 2000), ofrecían una robustez y abilidad
ampliamente superior a los sistemas Windows 9X, que tenían un marcado carácter doméstico.
El comienzo de milenio, trajo consigo la eliminación por parte de Microsoft de la rama
Windows 9X, para ofrecer dos versiones de su sistema Windows XP, la versión Home Edition,
y la versión Professional, que ha disfrutado de una amplia difusión y fama en los sistemas
profesionales y privados, que puede considerarse como parte de la familia NT, ya que se trata de
una evolución de los sistemas NT.
De las misma manera los sistemas Windows 2003 (en todas sus versiones), también con un
marcado carácter profesional, se consideran dentro de los sistemas NT.
Otra de las ramas de los sistemas Windows, se trata de su versión para dispositivos móviles
con recursos limitados, como pueden ser PDAs o Tablet PC, Windows CE, tanto en sus versiones
CE4.1 (Windows Mobile 2003SE), ó CE 5.0 (Windows Mobile 2005).
Para nalizar, y con la inminente comercialización de los sistemas Windows Vista, surge
la última versión de Windows para PC con grandes cambios muy novedosos sobre las ramas
anteriores.
Actualmente el mercado doméstico de Microsoft esta copado con Microsoft Windows XP. El
mercado profesional utiliza también Windows XP (Professional) para escritorio, y Windows 2000
y 2003 para servidores.
El agente de recogida de información desarrollado está destinado a su uso en sistemas operativos de la rama NT, a partir de Windows 2000, cubriendo de esta manera la casi totalidad del
mercado actual.
258
Métodos de recogida de datos en sistemas Windows
Los sistemas de Microsoft Windows, funcionan a en dos niveles ofrecidos por la arquitectura
i386, los niveles 0, y 3 respectivamente. El kernel se ejecuta en nivel 0 (ring 0), y las aplicaciones
y procesos del sistema lo hacen a nivel 3 (ring 3).
Microsoft siempre ha tenido gran cuidado con mimar la compatibilidad entre sus plataformas
mediante la plataforma Win32, es decir, que una aplicación desarrollada en un sistema Windows
de la rama 9x, funciona igualmente en otro sistema de la rama NT.
Dado que en ambas ramas, el kernel es totalmente diferente en las dos ramas de Windows,
también lo son los procedimientos de llamada y de retorno de datos a la zona de usuario. Con
el n de salvar esta problemática en compatibilidad, los procesos de zona de usuario, nunca
llamarán directamente al kernel de Windows, sino que lo harán mediante la capa Win32, la cuál,
se encargará de la comunicación con el Kernel.
La capa win32 esta compuesta por una serie de DLLs del sistema que exportan un conjunto
de funciones similares, tanto en 9x como en NT, a los programas de usuario. A este conjunto de
funciones exportadas se le denomina la API win32.
A pesar de que la API ofrecida por la capa Win32, sea similar en todos los sistemas Windows,
la implementación interna de dicha capa, y de la comunicación con el kernel de Windows es
completamente diferente entre los diferentes sistemas. Por lo tanto la capa Win32, ofrece un
nivel de abstracción clave para el mantenimiento de la compatibilidad entre diferentes sistemas
Windows.
En el caso de la rama NT, la comunicación kernel - zona de usuario se realiza mediante dos
mecanismos diferenciados :
Mediante la interrupción 2E que al igual que la interrupción 80 en sistemas GNU/linux es
gestionada en zona Kernel, las DLL que forman la estructura de Win32, suelen terminar
su ejecución mediante la llamada a la interrupción int2Eh.
Listing 3.21: Utilizanción de int2Eh en Windows
2
MOV
EAX,
SyscallNumber
;
LEA
EDX,
[ ESP+4]
; EDX = p a r a m s . . .
INT
2Eh
requested
;
throw
;
return
the
syscall
number
execution
to
the
KM h a n d l e r
RET
4 ∗NUMBER_OF_PARAMS
Mediante la utilización de la instrucción optimizada sysenter[152] que realiza una ejecución
más rápida[31] que los sistemas tradicionales.
Listing 3.22: Utilizanción de int2Eh en Windows
push
fn
;
259
push
syscall
number
pop
eax
; EAX = s y s c a l l
push
eax
;
this
call
b
;
put
normalize
one
number
makes no
caller
diff
address
on
stack
5
b:
r:
add
[ esp ] , ( o f f s e t r − o f f s e t b )
;
mov
edx , esp
; EDX = s t a c k
db
0 fh , 34h
; SYSENTER i n s t r u c t i o n
add
esp ,
;
( param ∗ 4 )
normalize
stack
stack
De forma general, el sistema Win32, sigue utilizando la interrupción 2E, en lugar de la optimizada
sysenter, por lo que un debugger an nivel de usuario podría recoger la información de las llamadas
a las DLL, hasta que éstas efectúen la llamada al kernel de NT mediante dicha interrupción. Por
ejemplo, una llamada a la función
ExitProcess
de Kernel32.dll, prepara los argumentos para la
llamada ZwTerminateProcess en NTdll.dll, la cuál genera llamando a KiFastSystemCall, una
interrupción 2e.
De todo este funcionamiento se puede deducir, que existen dos maneras de monitorizar las
llamadas a el Kernel de Windows, una a nivel de zona de usuario, recibiendo las llamadas a las
DLL que conforman la capa Win32, y otra a nivel de Kernel, recibiendo las llamadas que realizan
dichas DLL al kernel de NT.
260
Figura 3.18: Esquema de memoria de NT, y posible puntos de recolección de datos.
Monitorización de llamadas a la API Win32
Por lo tanto el método a alto nivel, o a nivel de zona de usuario sería interceptar las llamadas a la API de Win32 que estandariza las llamadas al kernel de Windows. Para realizar esta
acción, existen diversos métodos, que permiten recoger información de este tipo de llamadas,
interponiendo el agente encargado de la recolección de datos entre el llamador y el llamado en
la función.
A continuación se enumeran las opciones posibles que se han contemplado para la implementación del agente a este nivel de el sistema operativo Windows.
Monitorización de la tabla de informaciones
Cuando un proceso hace uso de una llamada a una función implementada en una DLL, los
procesos no se limitan a saltar a la dirección de la función exportada. De echo aunque la dirección
de la función exportada se mapea en el propio espacio de direcciones de el proceso, no se garantiza
que las direcciones sean las mismas para todos los procesos, ni de que los desplazamientos para
la función exportada se mantenga entre diferentes sistemas operativos.
261
Este echo, puede ser fácilmente observado comparando con un debugger que las direcciones
de las funciones exportadas por el sistema para una misma función en los sistemas operativos
Windows 2000 y Windows NT, son diferentes.
Si diseñamos en ensamblador un programa que efectúe una llamada a ExitProcess asumiendo
como ja su ubicación en memoria para Windows XP, veremos como la ejecución de dicho
programa en un Windows 2000, u otro sistema operativo Microsoft, resulta en una excepción.
Los primeros ataques informáticos en forma de virus y shellcodes (ataques de inyección de
código), tomaban como jas las direcciones de memoria de las API que requerían, de tal manera
que eran especícos para una versión de Windows, fallando su aplicación genérica al resto de
versiones. En ocasiones, esta especicidad es tan grande que su aplicación para la misma versión
del sistema operativo, pero en distintos idiomas, no es viable.
Los primeros ataques informáticos en forma de virus y shellcodes (ataques de inyección de
código), tomaban como jas las direcciones de memoria de las API que requerían, de tal manera
que eran especícos para una versión de Windows, fallando su aplicación genérica al resto de
versiones. En ocasiones, esta especicidad es tan grande que su aplicación para la misma versión
del sistema operativo, pero en distintos idiomas, no es viable. Parece claro entonces que el proceso
no puede asumir una posición ja para las funciones exportadas por las DLL. Lo que ocurre en
realidad es que el proceso de usuario realiza una llamada a la API, de una forma indirecta a
través de la tabla de importaciones (IAT)69 .
Todos los programas win32 poseen formato PE (Portable Ejecutable), donde el .EXE se
encuentra dividido en un serie de cabeceras y secciones. Una parte de la cabecera PE esta
formada por la tabla de importaciones IAT, donde el programa expresa al cargador de Windows,
la lista de dependencias con funciones de DLLs.
El cargador del sistema operativo, realizará en el momento de la ejecución de dicho programa,
un mapeo de las DLLs necesarias donde del espacio de direcciones del proceso, y una resolución
dinámica de las funciones requeridas en la IAT. Se puede pensar en la IAT, como un largo
conjunto de buzones, donde en cada uno existe una etiqueta que indica el nombre de la función y
la DLL que la contiene. El cargador de Windows, se encargará en tiempo de carga, de introducir
un papel en cada buzón indicando la dirección de memoria absoluta de dicha función.
Posteriormente el proceso de usuario, cuando efectúa una llamada a una API como ExitProcess, tan solo realiza un salto indirecto sobre la IAT. De esta forma se garantiza una total
compatibilidad entre diferentes versiones de Windows.
La técnica de interposición basada en la modicación de la IAT, consiste en la modicación
de la tabla de importaciones de todos los procesos existentes, y de los nuevos generados. Esto se
puede hacer mediante el uso de ciertas APIs de Windows que permiten la escritura en la memoria
de otros procesos. El único problema es que la función trampolín a la que se redireccionará cada
API interpuesta, ha de residir en el espacio de direcciones de memoria del proceso remoto. La
69
Inport Address Table.
262
forma más sencilla de implementar esto es introduciendo todo el sistema de monitorización en
una DLL, y mapeando posteriormente dicha DLL en el espacio de direcciones de memoria del
proceso remoto al cual se pretende monitorizar. Esto se consigue mediante la introducción y
ejecución de un pequeño trozo de código ejecutable en el proceso remoto, que se encargue de
realizar una llamada a la API (LoadLibrary) que realice la carga de la DLL[218].
Existe un pequeño problema con la implementación de esta técnica de interposición. En
ocasiones, el proceso tan solo llama a un pequeño conjunto de funciones de DLL, presentes en
su IAT, y son estas DLLs las que internamente efectúan las llamadas a las DLLs del sistema.
Para evitar que estas llamadas pasaran desapercibidas (ya que no usan la IAT del proceso,
sino la IAT de la propia DLL que las contiene), hay que realizar recursivamente el proceso de
modicación de la IAT para todas las DLL utilizadas por el proceso.
Además, en ocasiones los procesos utilizan la carga y resolución dinámica de funciones de
DLLs, utilizando para ello las API LoadLibrary() y GetProcAddress. Con el n de detectar esto
último para realizar la modicación de la IAT de las nuevas API, es necesario interponer sendas
API LoadLibrary y GetProcAddress, para llamar en su ejecución al proceso de modicación de
IAT, antes de retornar el control al proceso que realizó la llamada.
Existen numerosas herramientas que implementan esta técnica, y todos ellos adolecen un
grave problema que sugiere la utilización de otro tipo de técnica para implementación de nuestro
agente.
Además, esta técnica para la interposición tan solo es efectiva cuando el proceso utiliza
método estándar para la resolución de la API. En efecto todos los procesos tienen la garantía de
utilizar este tipo de métodos, pero bajo los efectos de un ataque la situación cambia.
En los ataques de inyección de código, como por ejemplo los buer overfLow, un pequeño
trozo de código, llamado shellcode, es insertado y ejecutado dentro del proceso remoto atacado.
Esta shellcode efectúa una serie de acciones sobre el sistema que resultarán en una vulneración de
la seguridad del mismo. La shellcode requiere de la llamada a APIs y por tanto ha de resolverlas
dinámicamente.
Si bien es cierto que la shellcode podría utilizar la IAT para la resolución de la dirección de
las APIs, buscando en memoria el inicio de la tabla, existen otros métodos mucho más efectivos
para realizar dicha resolución que no toman la IAT como referencia[250].
Uno de ellos, por ejemplo, es la utilización del PEB (Program Execution Block) del proceso
para obtener la base de la dirección en memoria de kernel32.dll a n de localizar su tabla de
exportaciones para resolver todos sus métodos.
Al no utilizar la shellcode la IAT en su proceso de resolución, no se vería afectada por el
engaño
de la modicación de la IAT, y sus llamadas pasarían totalmente desapercibidas a
ojos del agente HIDS. El HIDS sería en este contexto totalmente incapaz de detectar ninguna
modicación entre las APIs llamadas por un proceso sano y uno que se encontrara bajo ataque.
En resumen, la interposición por modicación de IAT se muestra muy efectiva para el mode-
263
Figura 3.19: Ejemplo de modicación de memoria en el punto de inicio
lado de procesos en situaciones normales, pero gravemente incapaz de modelar todos los comportamientos de ataque. Por ello se ha descartado este método para la implementación de nuestro
agente.
Envolviendo DLLs
Otra técnica de interposición posible, consiste en la modicación en disco de todas las DLLs
del sistema (capa win32) a n de modicar el inicio de todas sus funciones para incluir el código
necesario para monitorizar su uso por parte del agente.
Un forma sencilla de implementar esta técnica, es la creación de DLLs envoltorio con las
mismas funciones exportadas que las originales. Cada función exportada sería simplemente una
función trampolín hacia la función original de la DLL real.
Esta técnica no resulta viable para su aplicación en nuestro HIDS ya que implicaría la modicación permanente en disco de importantes archivos de sistema, complicando de esta forma la
distribución e instalación del agente en sistemas en producción.
Modicando en memoria el punto de inicio de las API Win32
Otra aproximación posible es la modicación en memoria, en tiempo real, del inicio de todas
las funciones relevantes exportadas por las DLLs de sistema, para incluir una llamada a una
rutina del agente que realice la monitorización de la misma antes de devolver el control a la API
original.
Para simplicar el proceso, los bytes sobrescritos por el CALL introducido habrán de ser
restituidos (ejecutables) antes de que el control sea retornado. De esta manera el sistema, queda
igual una vez que se ha dejado de monitorizar las llamadas al API.
264
Este método es mas directo que la modicación de la IAT y no requiere ser realizado recursivamente por cada DLL, o la monitorización del uso de GetProcAddress. En efecto, al realizar
la interposición en el inicio de la cada función exportada, ésta es aplicable a todas las otras DLL
del proceso así como al proceso en si mismo.
Dado que cada DLL es mapeada de forma independiente en el espacio de direcciones de
memoria de cada proceso de usuario del sistema, la modicación de una de ellas no implica el
cambio de la misma en el resto de los procesos (no se encuentra en memoria compartida).
Por lo tanto el proceso de interposición habrá de realizarse para todos los procesos del sistema,
existiendo la necesidad de monitorizar la ejecución de nuevos procesos (mediante la interposición
de la API CreateProcess), a n de realizar el mismo proceso con ellos.
Finalmente, las funciones trampolín que se interponen a la llamada a las API originales, han
de residir en el mismo espacio de direcciones de memoria del proceso que efectúa la llamada. Para
que esto se cumpla, dichas funciones han de ser introducidas en la memoria del propio proceso.
Existe una librería, llamada Detours [168], provista por Microsoft Research que implementa
este método de interposición.
Detours automatiza el proceso de modicación del inicio de las APIs requeridas y la gestión
de la inyección remota de la DLL. Las funciones trampolín residen por tanto en una DLL que es
insertada en el proceso a monitorizar (o en todos si se desean monitorizar todos), para comunicar
mediante un PIPE, toda la monitorización realizada.
Interposición de llamadas al sistema en modo kernel
Al contrario que el resto de los métodos de monitorización que eran implementados a nivel
de usuario (ring-3), se presenta también la posibilidad de implementar la interposición a nivel de
kernel.
Como ya se ha comentado, las DLL del sistema terminan efectuando llamadas al kernel mediante la interrupción 2e, o la instrucción sysenter. El kernel posee un dispatcher que redirecciona
la ejecución a la función correspondiente indicada en los registros del procesador. Para ello el
dispatcher, utiliza la tabla de punteros a servicios (system service table) que contiene la ubicación
en memoria de las distintas funciones de kernel.
Modicando dicha tabla de punteros a servicio, es posible redireccionar la llamada a las
mismas a nuestras funciones trampolín, que tras registrar su ejecución, redireccionarán el control
a las originales.
Las funciones trampolín habrán por tanto de residir a nivel de kernel ring-0, y el efecto de la
interposición será global a todos los procesos.
Existe una librería provista por la empresa BlindView, recientemente adquirida por Symantec,
que implementa esta técnica para la monitorización genérica de llamadas al sistema. Su nombre
es strace[38].
Strace esta compuesto por un driver (.SYS) que corre a nivel de kernel, conteniendo las fun-
265
Figura 3.20: Esquema de funcionamiento de la librería strace
266
ciones trampolín y realizando la modicación de la tabla de punteros a servicios, y un programa
de usuario que se comunica con el driver de kernel mediante una tubería (named pipe).
Efectividad de los diferentes métodos de interposición, para el modelado de procesos
en el HIDS.
Al igual que en el caso de GNU/Linux, la efectividad de un HIDS por modelado de syscalls en
la plataforma Windows, depende de la capacidad del agente para monitorizar todas las syscalls
generadas, incluso aquellas realizadas a bajo nivel por los ataques y el malware, y de la hipótesis
que un ataque es una desviación visible de las secuencias normales de llamadas la sistema del
proceso.
Este último punto ya ha sido demostrado en otros estudios[375] para otras plataformas UNIX
(Solaris) y también ha sido demostrado para GNU/Linux en apartados anteriores. En este apartado nos centraremos en su demostración práctica para la Windows 2000/XP.
También estudiaremos la capacidad del agente desarrollado, explicado en detalle en el apartado anterior, para la detección de las syscalls generadas por los procesos y el malware.
En el apartado de GNU/Linux nos centramos en el estudio de las llamadas al sistema para ataques de inyección de código. En Windows hemos reproducido los mismos experimentos,
utilizando sencillos programas vulnerables que escuchan puertos de red, y creando exploits en
Python que los atacan.
Los resultados se muestran similares a los obtenidos con GNU/Linux, pero con algunas matizaciones importantes que pasaremos a relatar. Para la monitorización de los exploits hemos
utilizado la librería strace y también Detours, con el n de determinar la diferencia entre las
mismas, y seleccionar la más adecuada para su implementación en el agente.
En términos generales Detours se muestra mas precisa a la hora de trazar el comportamiento
del proceso bajo ataque, ya que strace se muestra incapaz de reejar ciertas acciones como la
escritura de datos en un socket.
Strace por otro lado, se muestra mucho más ecaz para la detección de llamadas al sistema
efectuadas a bajo nivel por parte de ciertas shellcodes, para las cuales Detours no detecta nada. A
pesar de que los procesos de usuario siempre utilizan la API de Windows para efectuar llamadas
al sistema, las shellcodes por el contrario suelen muchas veces realizar las llamadas a bajo nivel
ejecutando directamente la int2e o el procedimiento syscall.
Detours además presenta gravísimos problemas de rendimiento al intentar monitorizar un
gran conjunto de syscalls (1400 en nuestras pruebas) dejando el sistema prácticamente inutilizable.
Además de demostrar su viabilidad para la detección de ataques de inyección de código, hemos
querido determinar su capacidad para la detección de malware para lo cual se ha monitorizado
la acción de un virus informático del tipo win32.
Para las pruebas hemos monitorizado las llamadas al sistema generadas por un proceso note-
267
Figura 3.21: Monitorización de syscalls de un proceso infectado con el virus Satir.994 utilizando
strace
pad sin infectar, y las hemos comparado con el mismo proceso una vez infectado.
Observamos que en la diferencia encontramos las acciones del virus, muchas de las cuales son
traducidas en llamadas al sistema, que nuestro agente es capaz de monitorizar. Esta observación
abre la puerta a la utilización de modelos para detección mediante patrones o anomalías.
Diseño e implementación del agente
El agente desarrollado para Windows 2000/XP implementa la técnica de interposición de
llamadas al sistema mediante la modicación de la tabla de punteros a servicios (system service
table), a nivel de kernel (ring-0).
El agente esta compuesto por 2 componentes principales, uno que corre a nivel de kernel
(ring-0) y otro a nivel de proceso de usuario (ring-3).
El componente de kernel hace uso del driver provisto por la librería strace[38] de BlindView
c . Dicho driver permite la interposición de syscalls en sus diversas categorías, posibilitando la
selección de las mismas en base a ltros.
La comunicación con el componente de nivel de usuario se realiza mediante una tubería,
desde la cual el proceso de usuario recibe la información que procesará y enviará por socket al
Head DFSU.
El componente de nivel de usuario ofrece también una rica interfaz gráca al usuario donde
éste podrá especicar el alcance de la monitorización del agente.
La interfaz se divide en distintos tabulados donde podemos especicar el conjunto de procesos
a los que aplicar la monitorización y el destino de la misma, chero o DFSU remoto.
Por otra parte también es posible seleccionar la extensión de la monitorización, especicando
por categorías las llamadas al sistema que serán monitorizadas.
Las diferentes pruebas sobre los sistemas Windows 2000 y Windows XP sp2 arrojan resultados
positivos, mostrando muy poca sobrecarga en el sistema. Sin embargo aún existe algún problema
de compatibilidad no resuelto.
En Windows XP con service pack 2 instalado, es necesario desactivar en registro la protección
268
Figura 3.22: Interfaz de usuario del agente, menús generales.
Figura 3.23: Menú de selección de syscalls hookeadas
269
Figura 3.24: Simplicación de la arquitectura de Symbian OS
de memoria con el n de que el agente pueda modicar la tabla de llamadas a servicios a nivel
de kernel.
3.2.4. Recogida de información en sistemas Symbian OS.
Para comenzar a explicar las diferentes formas en las que se puede capturar la interacción del
usuario con las aplicaciones y de éstas con el sistema operativo conviene introducir los mecanismos
internos y la arquitectura de funcionamiento de este tipo de terminales móviles. Centrando un
poco más el tema, en la siguiente gura se hace un resumen de lo que sería la plataforma diseñada
por los desarrolladores de este sistema operativo:
Symbian OS es una arquitectura que toma las bondades de los sistemas monolínitico y los
basados en microkernels, es decir, que integra funcionalidades de ambos. Se dispone de un hilo
en ejecución con la prioridad más alta para todo el sistema que se denomina nanokernel. Éste
hilo supervisor se encarga de tareas como la sincronización y la organización temporal entre los
diferentes procesos que se tienen en ejecución, así mismo desempeña funciones de mantenimiento
y acceso a bajo nivel, proporcionando una interacción que cumpla con los exigentes requisitos de
las pilas de comunicación GSM/GPRS/UMTS, dado que es objetivo fundamental el cumplir los
tiempos y latencias para poder funcionar correctamente con este tipo de redes.
Por otra parte, por encima del nanokernel se tiene la parte denominada núcleo (kernel)
270
propiamente, que se ocupa de tareas más complejas: acceso a objetos más complejos (hilos de
modo usuario, procesos, manipuladores de objetos del sistema, librerías cargadas dinámicamente,
comunicación entre procesos, etc.). A su vez proporciona una sincronización para objetos más
compleja que el nanokernel, si bien a diferencia del anterior, esta parte no puede alojar memoria
dinámicamente. Dado que no ha sido diseñado el kernel para manipulación de memoria del
terminal, esta parte se ha dejado por completo a cargo del modelo de memoria, implementado
como servicio del kernel en vez de estar embebido dentro del código del mismo.
Los semáforos, mutex, y elementos de sincronización que son proporcionados por el nanokernel, son utilizados por el kernel para poder crear hilos de ejecución de procesos sincronizados,
para conseguir comunicar entre sí diferentes procesos y para manipular los diferentes arrays de
manipuladores que integran este sistema operativo.
El modelo de memoria extraído del núcleo en sí mismo, denominado ASIC, se encarga y
encapsula de manipular si una cache (entendida como porción de memoria) va a estar alojada
en espacio virtual o en espacio físico. Proporcionando una serie de accesos diferentes para la
aplicación que lo requiera:
Acceso directo (sin hacer uso de la MMU)
Movimiento entre partes (parecido a como se realizaba en versiones anteriores EKA170 )
Acceso múltiple.
Acceso realizado para el emulador de Symbian OS71 .
El modelo de memoria proporciona servicios de manipulación de memoria a bajo nivel, como por
ejemplo el mapeo por proceso de su espacio de direcciones, se encarga cuando se le pide del cambio
de contexto adecuado en la sincronización y es parte fundamental para lograr la comunicación
entre procesos del terminal. Así mismo es importante su función a la hora de creación de procesos
haciendo uso del servidor de cheros del sistema72
70
Actualmente se habla mayoritariamente de EKA2, que es la arquitectura de diseño y desarrollo que se esta
llevando a cabo por los desarrolladores de Symbian OS
71
Como se verá más adelante, la arquitectura ha sido desarrollada para dos soportes hardware diferentes. La
primera es para los propios terminales móviles y la segunda es para facilitiar el desarrollo con pcs ordinarios, de
forma que es posible trabajar con este sistema operativo de forma emulada en un ordenador convencional basado
en IA-32 y sistema operativo Windows, GNU/Linux o MacOS.
72
Symbian OS confía en la denición de servicio para la implementación del kernel. De esta forma ha desarrollado
servidores especializados, como en este caso el servidor de cheros, de forma que si hay que tocar algo de la
memoria física de archivos, de donde habrá que copiar el código fuente de la aplicación para ponerla en ejecución
(los cheros ejecutables tienen una forma de estructuración parecida al formato PE de Windows, se denominan
E32, disponible en http://newlc.com/El-formato-de-los-cheros.html), se encargue de forma única este servidor.
271
Figura 3.25: Formato interno de los cheros ejecutables y librerías para Symbian OS
Como se ha indicado anteriormente, este tipo de terminales requieren de funcionalidades
especícas para poder trabajar con la red de GSM/GPRS/UMTS, por lo que disponen de dos
procesadores arquitecturalmente hablando. Uno se hace cargo de mantener operativo el sistema
operativo funcionando, mientras que el otro se encarga de realizar las operaciones que se requieran
para las transaciones dentro de la red de comunicaciones correspondientes.
Figura 3.26: Modelo simplicado de la arquitectura de procesadores de un terminal Symbian OS
Ya entrando a nivel de software desarrollable se encuentran los drivers de dispositivo, su
función es la de controlar los diferentes periféricos de los que dispone el sistema. Estos drivers
proporcionan la interfaz requerida entre esos periféricos y el resto del sistema Symbian OS. Más
adelante se volverá sobre este tema, con los drivers LDD y PDD. Así mismo más adelante se
explicara junto con los drivers un subconjunto de los mismos, denominado Extensiones, que son
aquellos drivers que se cargan nada más arrancar el mismo (bootstrap process). Estós últimos se
emplean generalmente para inicializar los dispositivos pero han sido usados para otras funciones
272
menos agraciadas73
Otra pieza clave es la librería que hace de nexo entre el ejecutivo (núcleo o kernel) y los
procesos o aplicaciones de zona de usuario. Esta librería se denomina EUSER.DLL y proporciona
los siguientes servicios:
Ejecución de métodos que enteramente se quedan en la zona de usuario. Como pueden ser
la manipulacion de cadenas de texto74 .
Acceso a las funciones del kernel que sean requeridas por un proceso. Estas operaciones
son privilegiadas, es decir, que un proceso o aplicación no puede hacer uso de las mismas
directamente.
Acceso a funciones que le indiquen al kernel que debe modicar su propia memoria, como
pueden ser las de manipulación de hilos, creación de procesos o carga de una librería.
Para dar por concluida esta primera fase de aproximación al conocimiento de este sistema operativo se presenta a continuación una imagen indicativa de las diferentes capas que tiene el kernel:
Figura 3.27: Capas del núcleo de Symbian OS
Otra parte importante son las librerías cargadas dinámicamente (DLL), el núcleo crea un
objeto de librería para cada DLL que se cargue explícitamente en un proceso de usuario, esto
implica que los estos objetos son especícos y pertenecen exclusivamente al proceso para el que
73
El virus Cabir, o Caribe, y sus diferentes versiones, si bien no llegan a infectar el terminal propiamente.
No llegan a cambiar el código fuente o el de ejecución de las aplicaciones. Se valen de este tipo de drivers para
lanzar un proceso o aplicación durante el arranque del terminal. Este proceso es quien se encarga de escanear por
Bluetooth (una tecnología de comunicación inalámbrica) y enviar una copia del propio virus. Ha sido la voz de
alarma para las entidades y organizaciones antivirales de la necesidad de introducir productos para los terminales
móviles Symbian OS.
74
En Symbian OS las cadenas de texto o strings de otros lenguajes se denen como Descriptores y se dispone
de una serie de Macros que implementa la librería EUSER.DLL para trabajar con ellos convenientemente.
273
fueron creados hasta el punto de que si dos procesos comparten la misma librería, el núcleo realiza
dos objetos para representarla diferentes.
Llamadas al sistema en Symbian OS
En Symbian las llamadas al sistema se denominan
Executive Call
75
y son el mecanismo pro-
porcionado por el núcleo al código de zona de usuario para dar acceso al mismo a sus servicios.
Estas llamadas ejecutivas empiezan como una función en zona de usuario y después se sirven de
una excepción76 como puerta de enlace para permitirles solicitar código de modo kernel. En la
implementación hardware de los terminales móviles con Symbian OS, generalmente una interrupción se activa mediante una instrucción SWI y esta en la arquitectura ARM solo se dispone de
una para pasar a modo privilegiado. Por este motivo se usa un repartidor en el nanokernel para
decodicar un parámetro pasado desde zona de usuario (opcode) en la instrucción SWI y con él
poder determinar la función a la que tiene que llamar el repartidor (dispatcher). Este mecanismo
de llamadas da como resultado un bajo acoplamiento entre el kernel y los procesos de usuario,
con lo que se pueden realizar cambios en la implementación o en el diseño de ambas partes sin
afectar al resto del sistema operativo de forma sencilla.
El ujo de ejecución de una executive call esta reejado en la gura:
Figura 3.28: Llamada ejecutiva al kernel de Symbian OS
Si se asume que se ha producido una llamada desde un hilo en ejecución en espacio de usuario
75
76
Llamada ejecutiva o llamada al ejecutivo, conocido también como el núcleo o el kernel.
En otros sistemas operativos esto se conoce como la interrupción de solicitud. En el kernel de Linux se hace uso
de la interrupción int80h y en MS-Dos/Windows de la int20h. El tratamiento de excepciones y de interrupciones
funciona de maneja semejante en las arquitecturas ARM, PPC o IA-32/64.
274
como la siguiente, en la que se pide una porción de memoria compartida:
Figura 3.29: Código fuente en el que se realiza la llamada para reservar una porción de memoria
El fragmento de código anterior solicita la creación de una porción de memoria y almacena el
manipulador que se le devuelve para poder referenciar a este espacio. Lo siguiente es encontrar
la dirección base del espacio que se consigue mediante el método RChunk::Base(), un método
que se encuentra denido dentro de la librería de usuario EUSER.DLL. El paso 2 se realiza
dentro de la propia librería aparte de realizar una serie de funciones para realizar la función
solicitada acaba con una interrupción: SWI EExecChunkBase, donde EExecChunkBase es el
opcode necesario para el kernel. En el paso 3 ya interviene el dispatcher del nanokernel y dado
que esto es una llamada rápida (más adelante se volverá sobre este tipo de llamadas) se busca
en una tabla de parejas de entradas de 32 bits que referencian a la llamada que se ha de realizar.
Finalmente tras procesar el paso 3 dentro del nanokernel se requiere hacer uso de otra parte del
núcleo al margen del propio dispatcher quien se encargará de realizara las operaciones necesarias
para la solicitud del proceso en zona de usuario (pasos 4 y 5).
Denotar que las llamadas ejecutivas se realizan en el espacio y contexto del hilo que las
solicita, lo que implica que no se ha salido del espacio de memoria del proceso en cuestión, con lo
que no es posible machacar zonas de memoria de otros procesos haciendo uso de este mecanismo.
Si bien es posible que una vez llegado a código de kernel privilegiado poder solicitar el acceso
a memoria del sistema en general, aunque para ello se requiere realizar una modicación de la
información contenida en ROM del terminal móvil, solución bastante compleja para realizar una
infección vírica.
Ahora se va a comentar las diferencias y la forma de funcionamiento de las llamadas ejecutivas
rápidas y las lentas:
Slow executive calls
Estas llamadas se ejecutan con las interrupciones habilitadas y con el kernel desbloqueado, lo
que implica que pueden ser interrumpidas y cambiadas de orden en la ejecución por motivos
de sincronización o solicitudes más urgentes (preemptive system calls). Estas llamadas solicitan
un bloqueo del sistema rápido antes de llamar al manipulador que requieran para realizar sus
operaciones y posteriormente lo liberan para pasar a llamar al manipulador obtenido, después de
esto solicitan al manipulador que haga la tarea que se requiere, pero entran dentro de la tónica
del sistema apropiativo y sincronizable por lo que pueden pasar a segundo plano y tener que
cambiar de contexto de mientras otra solicitud más importante es atendida.
275
Fast executive calls
Las llamadas ejecutivas rápidas al contrario que las anteriores se ejecutan con las interrupciones
deshabilitadas, por lo que deben de ser muy cortas y requerir muy poco tiempo en ejecutarse. Así
mismo no hay muchas de este tipo de llamadas y suelen ser usadas para cosas muy puntuales que
se realicen de forma rápida y efectiva. Las llamadas ejecutivas lentas pueden contener hasta 11
parámetros asociados, en cambio estas llamadas rápidas solo pueden tener asociado un parámetro
de 32bits y sólo devuelven otro valor de 32bits.
Seguridad de instrumentación binaria en Symbian OS
La seguridad dentro del sistema corre a cargo dentro de lo que se denomina una Capability,
que no es más que una autorización que indica si el dueño ha conado para poder acceder a los
recursos protegidos por la cadena de texto asociada. Este token de autorización puede dar acceso
a API's internas muy sensibles como a los drivers de dispositivos o a datos como la conguración
del terminal.Los diseñadores han creado una serie de reglas entre lo que se permite hacer y lo
que no dentro del sistema operativo:
Cada proceso tiene un conjunto de tokens, capabilities, y éstas no cambian durante toda
su vida
Cuando se desarrolla un programa ejecutable, se tiene que crear un chero con extensión .MMP
que es el denominado chero de proyecto. Adicionalmente se requiere actualmente de una línea
extra que dena las capacidades que se le deberán otorgar a un determinado ejecutable. Tanto
los ejecutables .EXE, como las librerías .DLL tienen sus características denidas de esa forma.
Estas capacidades son leídas y escritas en disco durante el proceso de instalación y permanecerán
inalterables desde ese momento, incluso durante la carga se almacenan en memoria en sitios
diferentes y no accesibles desde el programa en ejecución. Se pueden consultar, pero no modicar.
Un proceso no puede cargar una librería DLL que tenga un conjunto menor de capacidades
que él mismo
Una librería DLL no puede linkarse estáticamente con otra DLL que tenga un conjunto
menor de capacidades denido.
Otra parte interesante en el orden de la seguridad interna del sistema operativo es el tratamiento
de la parte de Servidores/Clientes. Como se ha comentado, Symbian incorpora un particionado
especializado de funciones y funcionalidades para tener un bajo acoplamiento dentro del código.
Un servidor, por ejemplo de cheros o de sockets o de telefonía, siempre comprueba y pregunta a
sus posibles clientes a ver si tienen las capacidades adecuadas para poder solicitarle la realización
de una determinada tarea.
276
Drivers de dispositivo y Extensiones
El papel de los drivers de dispositivo es dotar al código de zona usuario acceso a los recursos
periféricos del hardware sin exponer la operación de acceso al mismo al código de usuario y
volver al dispositivo inestable. Generalmente en todo sistema operativo restringe al modo de
supervisión el acceso a los recursos hardware, con lo que el acceso desde el código usuario a un
driver plantea la misma barrera que entre código de núcleo privilegiado y código en ejecución de
las aplicaciones de usuario. Los drivers son cargados dinámicamente por el kernel y se alojan en
el proceso del kernel después del arranque del sistema.
La arquitectura de drivers en Symbian OS se distribuye en dos capas: lógica y física, como
se indica en la gura:
Figura 3.30: Arquitectura de los drivers de dispositivo simplicada
Los drivers de dispositivo lógicos, LDD, contienen la funcionalidad de una serie de dispositivos
y son los que se comunican con el código de usuario mediante una interfaz simple que dene una
API concreta. Este tipo de drivers denen una serie de funcionalidades genéricas y se valen de
los drivers físicos, PDD para realizar el acceso al hardware en la manera apropiada. Los PDD
controlan por lo general un dispositivo periférico en particular y por norma sólo se comunican
directamente con otro driver LDD o con una extensión.
Las Extensiones del kernel, no dejan de ser drivers también, con la salvedad de que son cargados en el sistema en el momento del arranque del mismo y usualmente son muy especializados
para poder inicializar los diferentes recursos convenientemente.
277
Debug en zona de núcleo (Kernel)
La arquitectura de los terminales móviles actuales basados en Symbian (Symbian S60 3a
generación), basada en EKA2 ha sido diseñada para admitir debugger remotos a nivel de kernel.
Estos debuggeos del núcleo se pueden producir de las siguientes formas:
Debuggers para Emulador. Solución aceptada e implementada en el presente proyecto para
acceder a las trazas del sistema.
La solución empleada para poder acceder a las trazas del sistema ha sido esta debido a la
simplicidad de trabajar con emuladores y al hecho de poder tener acceso físico a los mismos,
pudiendo modicarlos y adaptarlos convenientemente para la integración de los mismos en la
infraestructura. La operación realizada se basa en cambiar la librería EUSER.DLL, a la que todas
las aplicaciones hacen referencia en su funcionamiento para poder solicitar tareas avanzadas,
por otra librería modicada que permitiera realizar la captura y envío de los datos necesarios.
La práctica que se ha llevado a cabo se puede aplicar en los móviles comerciales mediante la
actualización del software y modicación de este fragmento de código que reside en la ROM77
del dispositivo.
Para el desarrollo de la intercepción de llamadas al sistema se ha hecho uso del proyecto
HookLogger78 , que modicado ha dado pie a poder observar la forma de trabajo existente en la
presente memoria.
Figura 3.31: Selección de hilos en ejecución a interceptar
77
ROM, Read Only Memory. Memoria que contiene el kernel, los drivers y las librerías del sistema operativo,
que no permite ser escrita o modicada salvo con el hardware apropiado.
78
Disponible en la dirección ocial http://developer.symbian.com/main/tools/devtools/code/index.jsp, sección
de herramientas de desarrolladores de SymbianOS
278
Figura 3.32: Volcado de la memoria y de las peticiones que se realizan a la librería
Figura 3.33: Detalles de un hilo en ejecución
Debuggers de aplicaciones en tiempo real. Ideal para el desarrollo e implantación de aplicaciones.
Los debuggers en tiempo real permiten que una aplicación que se encuentre en ejecución en un
terminal móvil Symbian OS pueda ser monitorizada y controlada en base a excepciones (para
poder introducir los breakpoints o puntos de ruptura) desde un PC remoto. La arquitectura de
este tipo de sistemas es la que sigue:
279
Figura 3.34: Run-Mode Debugger
Debuggers con opción de parada y congelación del sistema operativo. Se usan para el
desarrollo de Drivers de Dispositivo o otro software relacionado con el desarrollo del núcleo
3.3. Cuestiones arquitectónicas
Antes de entrar de pleno con DFSU es necesario que todos hablemos o al menos entendamos
el mismo lenguaje, para ello comenzaremos con un repaso al estado del arte en los sistemas de
detección de intrusiones. Tras la lectura de este capítulo el lector deberá comprender qué es un
sistema de detección de intrusiones, cuales son sus principales variantes así como cuáles son las
principales ventajas y desventajas de cada uno.
3.3.1. Riesgo tecnológico, un problema en alza.
Irónicamente, al tiempo que las nuevas tecnologías se vuelven más complejas, al tiempo que
se vuelven más rápidas, más accesibles, se vuelven también más vulnerables. Esta armación a
priori contradictoria cobra sentido al desglosar los factores que componen el
Riesgo tecnológico
(RT):
RT =
N A∗IE∗CA
ST
Figura 3.35: Ecuación del riesgo tecnológico
RT
La variable RT (Riesgo Tecnológico) pretende dar un aproximación cuantitativa de la amenaza
a la que se enfrentan nuestros sistemas informáticos.
NA
280
La variable NA (Número de Ataques) representa el número de ataques que sufren nuestros
sistemas, independientemente de si estos tienen éxito o no.
IE
Por supuesto la variable NA no tendría ningún fundamento sin IE (Indice de Éxito) de estos
ataques.
CA
La variable CA (Consecuencias del Ataque) representa cuales son los daños (en términos
económicos) del éxito de un hipotético ataque.
ST
La variable ST (Seguridad Teórica) representa cual es el grado de seguridad de nuestros
sistemas, ¾actualizamos nuestro software? ¾usamos cifrado? ¾claves de seguras? etc...
Si bien es cierto que nuestras medidas de seguridad teórica han mejorado notablemente,
gracias sobre todo a la expansión de las técnicas criptográcas y a la seguridad perimetral, la
delegación progresiva de responsabilidades hacia los sistemas informáticos hace que el papel de
estos sea cada día más importante, aumentando inevitablemente las repercusiones de un posible
ataque.
Si el Riesgo Tecnológico dependiese exclusivamente de estos dos factores (CA y ST), es posible
que hubiera podido controlarse gracias a las mejoras en Seguridad Teórica, lamentablemente la
balanza ha sido brutalmente descompensada por una explosión sin precedentes en el número de
ataques79
En todo sistema incipiente sea este: Social, Cultural, Económico o ½como no! Informático,
se produce una evolución a través del uso. Al igual que los caminos de la España del siglo XV
estaban infestados de rateros peligrosos, las autopistas de la información del siglo XXI están
plagadas de malhechores no menos desdeñables. Los técnicos y legisladores del siglo XXI deben
desarrollar técnicas capaces de limpiar Internet de la lacra que nos asola, sin embargo deben
hacerlo empleando juego limpio, es decir mejorando
la seguridad teórica
y no restringiendo sus
fantásticas capacidades y virtudes.
79
Una de las razones del aumento en el número de ataques está en los virus informáticos. Los worms de hoy
incorporan rutinas no sólo para replicarse y propagarse sino también para explotar vulnerabilidades conocidas,
de este modo muchos de los sistemas que antes pasaban desapercibidos por no ser de especial interés para un
atacante humano son ahora los más afectados .
281
3.3.2. Introducción
En la tarde del Miércoles 2 de noviembre de 1988 ordenadores de puntos vitales de los
Estados Unidos, como la NASA, el Pentágono, el Instituto Tecnológico de Massachusetts, las
Universidades de Berkeley, Stanford, Princeton, etcétera, de una costa a otra, de ARPANET a
MILNET, fueron cayendo uno tras otro, víctimas del
gusano
de Robert Morris.
Se habló entonces de millones de dólares en pérdidas y de un diez por ciento de Internet
colapsado. Tal fue la repercusión de ese primer gran ataque que tan solo una semana después,
con el gusano en cuestión aún en plena actividad, la Agencia de Proyectos de Investigación
Avanzada del Departamento de Defensa [DARPA] de los EEUU decidió fundar, en colaboración
con la Universidad Carnegie Mellon, el que sería el primer Centro de Respuesta ante Emergencias
Informáticas [CERT]; centro que posteriormente iría extendiéndose a un gran número de países,
entre ellos España [esCERT e IrisCERT].
Desde entonces hasta hoy los sistemas de seguridad informática han evolucionado enormemente y en muchas direcciones. Sin embargo, el hecho de que no exista una solución unicada,
que contemple el problema de forma global, es un síntoma de que dicho problema dista aún de
resolverse. Sin ir mas lejos, estos días Internet sigue convulsa tras ataques como el del gusano
Blaster y sus sucesivas variantes, con unas pérdidas económicas aún por cuanticar.
Tradicionalmente, la seguridad informática se ha fundamentado en los denominados mecanismos de control de acceso, de forma que el objetivo que se ha perseguido siempre ha sido el de
poder identicar a los usuarios que acceden al sistema, para así poder concederle o restringirle
el acceso a determinados recursos.
Si suponemos que nuestro sistema es una nca, este control de acceso podría realizarse poniendo unos buenos barrotes en las ventanas, reforzando las cerraduras y teniendo un exquisito
cuidado con quien recibe una copia de la llave para entrar. Además, sería una buena idea colocar
en el perímetro de la nca una verja electricada, para de este modo extender el área de seguridad más allá incluso de la puerta de entrada. Lejos de ser una simple metáfora, está es una
práctica que se sigue en el mundo de la informática casi al pie de la letra, esta es la idea con la
que se diseñaron los rewall o cortafuegos.
Sin embargo, no sólo evolucionan los mecanismos de defensa, también lo hacen las técnicas
de ataque y lo hacen hasta tal punto, que hoy en día los mecanismos de seguridad perimetral
(rewalls) son una medida necesaria pero claramente insuciente. Resumiendo: Una muralla cada
vez más gruesa siempre ha recibido el saludo de un cañón cada vez más potente.
Existe además una creencia generalizada (probablemente por llevar este tipo de paralelismos
con la vida real demasiado lejos) de que los ataques deben llegar siempre desde el exterior, nada
más lejos, gran parte de los ataques a lo que se enfrenta una red provienen precisamente desde su
interior. Empleados descontentos u ordenadores portátiles infectados, suelen ser las principales
fuentes. Salta a la vista que necesitamos un mecanismo automatizado para poder detectar a los
intrusos
que ya han conseguido vulnerar el perímetro de seguridad. Aquí es donde entran las
282
técnicas de detección de intrusiones.
Figura 3.36: Seguridad Perimetral (Firewall)
3.3.3. Detección de intrusiones
Un Sistema de Detección de Intrusos (IDS80 ) trata de detectar (y prevenir81 ) toda aquella
actividad subversiva que se desarrolla en el perímetro de nuestro sistema o que ya está dentro de
nuestra red. Una de las primeras referencias que podemos encontrar en el campo de la detección
de intrusos es el, ya un clásico, artículo de Dorothy E. Denning
An Intrusion Detection Model ,
de 1987 [EDENNING01]. Este artículo recoge desde un punto de vista conceptual gran parte de
las estrategias de detección más utilizadas en el momento. En él se establece por primera vez una
clasicación de los IDS que llega hasta nuestros días, por un lado el
de uso indebido
y por otro la
Reconocimiento de patrones
Detección de anomalías.
A pesar del peso histórico de escte artículo, utilizaremos otra clasicación más acorde con
los tiempos extraída de la obra Sistemas de Detección de Intrusiones por Diego González
[DGONZALEZ01]. Este autor establece tres fases generales de funcionamiento para cualquier
IDS, y los clasica según las técnicas empleadas en cada una de estas fases.
Como puede verse en la gura 3.37, la actividad del IDS se divide en 3 pasos:
1. Recogida de información: Capturar la información que posteriormente analizaremos.
2. Análisis: Dónde procesamos esta información.
3. Respuesta: Una vez el sistema he determinado si la información recogida compone una
amenaza o no deberemos tomar las medidas oportunas.
80
81
IDS, acrónimo de Intrusion Detection System
Últimamente los IDSs están evolucionando hacia los IPS (Intrusion Prevention System) donde se trata de
detectar la intrusión antes de que se produzca algún ataque.
283
Figura 3.37: Etapas en el proceso de detección
Taxonomía en base al método de recogida de información
Atendiendo a la fuente de la que los IDS's extraen la información, podemos establecer dos
categorías. Por un lado los IDS's basados es host (HIDS82 ) y por otro los IDS's basados en red
(NIDS83 ).
IDS's Basados en Máquina (HIDS)
Su funcionamiento en similar al de un antivirus en
el sentido en que el IDS se ejecuta como proceso local a la máquina que se desea vigilar. Este
proceso permanece habitualmente en estado dormido y en base a una serie de condiciones de
activación despierta para chequear si el estado del sistema es seguro o no. Determinar el estado
del sistema no es tarea fácil y su análisis debe afrontarse como si de una gran ecuación se tratara.
Esta ecuación debe tratarse con el mayor de los cuidados pues el más ligero cambio en cualquiera
de las variables puede signicar que el sistema a pasado de un estado seguro a uno inseguro o
viceversa.
82
83
HIDS, acrónimo de Host based Intrusion Detection System
NIDS, acrónimo de Network based Intrusion Detection System
284
A pesar de que todos los HIDS se ejecutan en la máquina a proteger, no todos ellos extraen
sus variables de los mismos puntos. A continuación se describen vagamente los enfoques más
comunes:
Llamadas al Sistema:
Los sistemas operativos ofrecen un conjunto de interrupciones que
pueden ser llamadas por las aplicaciones de usuario para invocar un servicio proporcionado
por éste. Cada uno de estos servicios se llama
syscall
syscall
o llamada al sistema, un ejemplo de
sería abrir un chero. Dependiendo de la complejidad del programa de usuario el
número de syscalls puede variar entre unas pocas en programas muy sencillos hasta miles o
decenas de miles en programas complejos. Al conjunto de syscalls que ejecuta un programa
se le llama
traza
y nos da una idea bastante precisa de su comportamiento.
Registros de Auditoría:
El Sistema Operativo, así como muchas de las aplicaciones de
usuario en ejecución sobre la máquina, mantienen una estricta contabilidad de todo lo que
está sucediendo84 . Esta información tradicionalmente se exporta en el caso del sistema
operativo a través de los dispositivos ubicados en /proc/85 y en el caso de los programas de
usuario a través de cheros de log. Por su sencillez y facilidad de acceso no es de extrañar
que esta fuese una de las fuentes de información más empleadas en los primeros IDS.
Vericaciones de integridad:
Dentro del área de conocimiento de la Detección de In-
trusiones orientada a la Máquina, Gene Kim y Eugene Spaord introdujeron, (1994), en
su artículo The Design and Implementation of Tripwire:
A File System Integrity Checker
[TRIPWIRE01], el concepto de Vericación de Integridad, también conocido como Detecci
ón de Intrusiones orientada a Objetivos86 . En dicho artículo, los autores proponían un Sistema de Detección de Intrusiones que aplicaba técnicas criptográcas de cifrado irreversible
empleando para ello funciones resumen, con unas propiedades muy características:
• La entrada del chero debe poder se de tamaño indeterminado.
• El resultado resumen debe ser de tamaño jo, como es lógico varios órdenes de magnitud más pequeño que la entrada.
• Dado x, calcular H(x) es en términos computacionales barato.
• H(x) es de un solo sentido, es decir no tiene función inversa.
• H(x) no debe presentar colisiones.
El objetivo perseguido por esta técnica es garantizar la integridad de aquellos recursos
críticos del sistema a proteger. De esta forma, aparecía una nueva tipología de sistema de
84
Esta información se suele emplear para generar perles de rendimiento o para análisis forense en caso de que
el sistema haya sido comprometido.
85
El empleo de dispositivos /proc es común en los sistemas Unix like, otros sistemas como por ejemplo Windows
utilizan otros métodos.
86
Detección de Intrusiones orientada a Objetivos o Target-based Intrusion Detection.
285
detección que, si bien mantenía claramente su orientación a la máquina, dejaba de utilizar
información proveniente de los registros de auditoría de sistemas operativos y servicios de
aplicación, y pasaba a utilizar sus propios registros.
/newpage
Conclusiones HIDS
A continuación se detallan las principales ventajas e inconvenientes de
los HIDS:
Puesto que se ejecutan en la máquina a proteger tienen acceso a un abanico de
variables mucho más rico que el tráco de red (syscalls, auditoría de cheros etc...)
Tienen además acceso al contenido de las conexiones cifradas por estar en uno de los
extremos del tráco.
Por otro lado, las labores de administración son mucho más costosas ya que deberá
congurarse cada ordenador a proteger.
Por muy bien que esté programado el HIDS, los fallos de seguridad existen, de
manera que irónicamente el mecanismo de protección pudiera convertirse en la puerta
de acceso para posibles ataques.
Toda la carga del proceso de detección se lleva a cabo en la propia máquina por lo
que el HIDS degrada el rendimiento de la máquina donde se instala.
IDS's Basados en Red (NIDS)
Este es el enfoque utilizado por la mayor parte de los IDS's
modernos que emplean la información capturada a través de sniers87 en diferentes segmentos de
la red del sistema para detectar posibles ataques. De este modo, un solo NIDS puede monitorizar
el tráco de toda una subred, protegiendo así varias máquinas simultáneamente.
A menudo una implementación real de un NIDS corporativo se compone no de uno, sino de
varios NIDS distribuidos en las distintas subredes, cada uno de ellos funcionado por separado en
su segmento de red. Así es precisamente como funciona Snort88 .
Figura 3.38: Logotipo de Snort
87
Un packet snier es un programa de captura de las tramas de red .Generalmente se usa para gestionar la red
con una nalidad docente, aunque también puede ser utilizado con nes maliciosos [WIKI03]
88
Snort es el estándar de facto de los NIDS. Snort (http://www.snort.org) está disponible bajo licencia GPL,
gratuito y funciona bajo plataformas Windows y Unix like.
286
Es habitual que los NIDS sean máquinas dedicadas exclusivamente a la detección de intrusiones, lo que por regla general los hace menos vulnerables89 , además no es extraño llegar al extremo
de no asignar IP al interfaz dedicado a la captura de paquetes, de este modo se evita que alguien
pueda direccionar ataques contra él e incluso utilizar cables de solo recepción o network taps,
evitando así que el equipo NIDS pueda ser
89
visto
por un hipotético atacante.
Esta armación a priori un tanto categórica se fundamenta en que en los sistemas muy especícos el número
de servicios suele ser muy reducido, un número de servicios reducido reduce a su vez las posibles puertas de acceso
a ese sistema. Esto lo hace más seguro.
287
A cada uno de los elementos de información que un IDS puede emplear para discernir si el
tráco que está analizando es o no un ataque se le llama métrica. Podemos clasicar las métricas
de red en dos subtipos [BYKOVA01]:
Información de cabecera:
El tráco de red va encapsulado dentro de las cabeceras
del protocolo que se esté utilizando. Como puede verse en la Figura 5: Cabecera IP esta
información se caracteriza por ser discreta90 y fácilmente extraíble ya que cada campo tiene
una longitud ja91 y está siempre en el mismo sitio. Los siguientes son ejemplos de métricas
extraídas de las cabeceras del protocolo:
• Direcciones IP origen y destino: Las direcciones de la máquina origen y de la
máquina destino son datos interesantes, tanto porque pueden ser empleados defensivamente en las medidas de control de acceso, como porque pueden llegar ser utilizadas
ofensivamente en denegaciones de servicio rudimentarias contra nuestro sistema. Supongamos por ejemplo que uno de nuestros servidores recibe un mensaje ICMP de
ping92 . Así pues, si el mensaje ha sido manipulado de forma que su dirección de origen
ha sido sustituida por la de destino, cuando nuestro servidor reciba dicho mensaje, en
lugar de responder al verdadero remitente se responderá a sí mismo indenidamente93 .
• Puertos origen y destino: Los puertos de origen y destino, son un excelente indicativo de actividades sospechosas, tanto para detectar barridos de puertos, como para
descubrir la presencia de servidores no autorizados en nuestra red (troyanos94 ).
• Flags TCP: Uno de los campos de la cabecera TCP, el de ags, contiene una serie de bits (URG, ACK, RST, SYN y FIN), por supuesto necesarios para el buen
funcionamiento del protocolo, pero que tradicionalmente se han modicado con otras
intenciones. Por ejemplo, para solicitar la conexión a un servidor, se activa el bit SYN,
mientras que el bit FIN hace justo lo contrario. Por sí solos no son especialmente signicativos, pero ¾no sería sospechoso que un mensaje llevase ambos bits activados?
Tampoco hay que olvidar que uno de los mayores problemas conocidos sobre plataformas Windows se fundamentaba en el manejo de paquetes OOB (Out of Band),
tramas con el bit URG activado [OOBATTACK01].
Carga útil:95
La información de cabecera es un añadido que los protocolos de comunica-
ciones deben agregar a sus transmisiones para que estas lleguen a su destino, sin embargo
90
91
Hay un número nito de posibles valores
Tal vez sería más apropiado explicar que la longitud del campo no siempre tiene por que se ja (casi siempre
lo es) sino que puede precalcularse cuanto va a ocupar. Esto sucede con el campo opciones de la cabecera IP.
92
Un ping es un mensaje con el que el emisor trata de averiguar si el receptor está activo, de forma que si es
así, éste devuelve un mensaje de echo.
93
94
Estos son los llamados ataques
chargen
Programa malicioso capaz de alojarse en computadoras y permitir el acceso a usuarios externos, a través de
una red local o de Internet, con el n de recabar información y/o controlar remotamente la máquina huésped.
95
También llamada payload.
288
lo que realmente le interesa al otro extremo es el contenido de la transmisión, la carga útil.
El problema del payload es que es generado en la capa de aplicación y cada aplicación tiene
su propio formato a la hora de organizar los datos del envío. Esto unido a que no existe un
modo able96 de determinar a que aplicación de usuario pertenece un determinado paquete,
hacen que la extracción de información del payload sea muy costosa.
Figura 3.39: Cabecera IP
96
Los puertos origen y destino podrían emplearse para identicar protocolos de aplicación conocidos. El pro-
blema es que no es un dato able ya que estos puertos pueden cambiar según las conguraciones.
289
Conclusiones NIDS
nientes:
Al igual que los HIDS, losNIDs también tienen sus ventajas e inconve-
Un solo NIDS bien situado puede cubrir las necesidades de un gran número de
ordenadores
El NIDS es transparente para los usuarios nales y siendo su administración
centralizada, los esfuerzos de los administradores de red son mínimos.
Pueden llegar a perder paquetes si el volumen de tráco en la red es muy elevado.
Los NIDS en principio no tienen acceso al payload de las conexiones cifradas
Un NIDS sabe si que ha tenido lugar un ataque, pero no sabe si ese ataque ha tenido
éxito o no, ni tampoco cual ha sido su impacto.
Taxonomía en base al método de análisis empleado
Atendiendo a que técnicas emplea el IDS para determinar, si las variables de control recogidas
representan o no un ataque, podemos distinguir principalmente dos corrientes. Por una lado los
sistemas de detección de usos indebidos y por otro los sistemas de detección de anomalías.
Reconocimiento de patrones de uso indebido
Este método trata de modelar todo el
conocimiento que los expertos de seguridad han adquirido a lo largo del tiempo, para de este
modo construir una lista negra de todas las actividades que pueden constituir un ataque. Su
utilidad es inmediata ya que el IDS sólo tiene que comparar el estado actual del sistema con
todos y cada uno de los estados recogidos dentro de la lista negra, si coincide con alguno de ellos
entonces es que se ha producido un ataque, de lo contrario el sistema está seguro.
Una denición sin duda más elegante es la propuesta por Rebecca Bace y Peter Mell:
Detection method that analyzes system activity, looking for events or sets of events that match a
predened pattern of events that describe a known attack.
Figura 3.40: Denición de patrones de uso indebido
Salta a la vista que este sistema tiene un fallo de base y es que aunque seamos capaces de
modelar todos y cada uno de los ataques existentes, algo por otra parte extraordinariamente
difícil, a medida que el tiempo vaya pasando surgirán nuevos ataques y poco a poco la lista irá
quedándose obsoleta.
/newpage
A pesar de sus claras limitaciones este sistema es muy popular, sobre todo por que cumple
perfectamente con su misión y por ser muy sencillo de comprender. A día de hoy este es el método
más empleado por los IDS modernos. A continuación se detallan sus variantes más conocidas:
Reconocimiento estático de patrones:
Esta técnica representa la forma más simple
de detectar malos usos. Normalmente se basa en sistemas que buscan mediante un reconocimiento de patrones relativamente simple cadenas o subcadenas dentro de las distintas
290
entradas. Si encuentran una determinada cadena binaria, entonces es que se ha detectado
un ataque.
Basada en probabilidades condicionales:
El reconocimiento estático de patrones de-
tecta una intrusión cuando cuando encuentra una determinada rma (característica), pero
esto no es del todo correcto, algunas rmas no reeje siempre un ataque. La aproximación
basada en probabilidad condicional trata de determinar la probabilidad condicional de que
una intrusión ocurra dada una cierta rma, para calcular esta probabilidad necesita datos
de intrusiones anteriores, por ejemplo, de logs de auditoría, eventos etc...
Basadas en análisis de transición de estados:
Esta aproximación representa las intru-
siones como una secuencia de transición de estados del sistema objetivo [PORRAS01]. Los
estados sucesivos se conectan mediante arcos que representan los eventos necesarios para
el cambio de estado. Cualquiera de los estados por separado no tiene por que constituir un
ataque en sí mismo, sin embargo la transición de un estado a otro sí puede constituirlo.
Detección basada en modelos:
Esta técnica combina modelos usos indebidos con el
razonamiento en base a evidencias. En este modelo, existe una base de datos con escenarios
de intrusiones formados por una secuencia de acciones que reejan el comportamiento de
una intrusión. En un momento dado un subconjunto de escenarios de ataque se considera
como escenario parecido. El IDS trata entonces de argumentar o rebatir los escenarios
dados en un chero de auditoría. El cálculo del razonamiento evidencial construido en el
sistema permite actualizar la probabilidad de la ocurrencia de los escenarios de ataque en
una lista de modelos activos.
Figura 3.41: Esquema de funcionamiento; Modelo de usos indebidos
291
Conclusiones reconocimiento de patrones de uso indebido
Los patrones de uso indebido son sencillos de implementar y de usar, tienen un índice de error
muy bajo, pero están limitados por su escasa exibilidad ante nuevos ataques. A continuación
se detallan sus principales ventajas e inconvenientes.
Es un sistema sencillo y de probada solvencia.
Al no requerir muchos cálculos los sistemas resultantes suelen tener un buen
rendimiento.
Están limitados en el sentido en que únicamente pueden detectar ataques conocidos
de previamente.
Detección de anomalías
Como respuesta a las carencias del sistema anterior surge una nueva
losofía de detección, fundamentándose ésta en una transgresora denición de ataque.
Una intrusión es una anomalía. Conozco lo que es 'normal' en mi sistema, para poder detectar
lo que no lo es (anomalías)
Figura 3.42: Ataque según la losofía de detección de anomalías
Tal y como puede verse en la Denición 2: Ataque según la losofía de detección de anomalías,
la base del funcionamiento de estos sistemas se basa en la suposición de que el perl de actividades
desarrollado durante una intrusión se desvía sensiblemente con respecto al perl de uso que un
usuario normal hace del sistema [CHEUK01]. De modo que el proceso de detección pasa por ser
capaz de modelar un perl del comportamiento normal del sistema para poder así identicar
cualquier desviación excesiva de ese perl como anómala y por tanto subversiva. A la hora de
determinar lo que es normal en el sistema, existen dos grandes aproximaciones [ROLAND01].
Por un lado están los sistemas capaces de aprender por sí mismos lo que es normal y lo que no,
para ello emplean técnicas estadísticas97 sobre variables como por ejemplo el número de procesos
en ejecución o el tráco de la red en un determinado instante y por otro los sistemas que en lugar
de aprender por sí mismos emplean conocimiento experto codicado en forma de reglas estáticas.
El primero de los problemas a los que deberá enfrentarse este modelo consiste en determinar
cuales son las variables más relevantes a la hora de denir un comportamiento normal. En
[HAROLD01] se proponer diferentes tipos de datos que pueden resultar útiles a la hora de
realizar la selección:
Variables de intensidad de actividad:
a una actividad
97
98
El sistema mide los valores numéricos asociado
a lo largo del pequeños intervalos de tiempo, de este modo obtiene de
Estas técnicas pueden variar desde lo más sencillo (medias, desviaciones, varianzas) hasta técnicas extrema-
damente sosticadas de aprendizaje automático (redes neuronales, redes bayesianas etc...)
98
Entendemos por actividad a cualquier proceso cuya ejecución pueda ser cuanticada numéricamente. Por
ejemplo el número de usuarios en el sistema o el número de Kbytes/segundo en una transferencia.
292
un modo muy preciso cual ha sido la evolución de esa actividad a lo largo de intervalos de
tiempo mayores.99
Variables Numéricas:
Algunas veces no tiene sentido analizar la evolución cronológica
de la variable, simplemente basta con conocer su valor100 .
Categóricas:
Aquellas cuyo resultado es una categoría individual, y miden la frecuencia
relativa o la distribución de una actividad determinada con respecto a otras actividades o
categorías101 [VILLALÓN01].
Registros de auditoría:
Esta medida analiza la distribución de las actividades generadas
en un pasado reciente basándose en los logs102 generados por las mismas; dicho análisis se
realiza de forma ponderada, teniendo más peso las actividades más recientes, y es comparado con un perl de actividades `habituales' previamente almacenado, de forma que permite
detectar si en un pasado reciente se han generado eventos inusuales[VILLALÓN01]
A día de hoy este es sin duda uno de los campos en la detección de intrusiones con una línea
de investigación más activa103 , no en vano existen cientos de aproximaciones104 , sin embargo, la
gran mayoría de ellas chocan con los mismos problemas [NATO01].
En primer lugar el sistema deberá ser capaz de describir de un modo efectivo el comportamiento del sistema, algo de por sí muy complicado105 , a esta dicultad se le añade el problema
de la comparación y es que dado un patrón de comportamiento almacenado y un patrón de
comportamiento actual ¾cual es la desviación mínima que marca la diferencia entre normal y
anómalo106 ?. Por si todo esto fuera poco, estos sistemas deben hacer frente a un problema más
y es que dependiendo en la técnica de aprendizaje que emplee el sistema, un atacante con los
conocimientos necesarios podría entrenar poco a poco el sistema con pequeñas variaciones de
comportamiento no lo sucientemente grandes como para ser consideradas en sí mismas como
una anomalía, pero si como para ir poco a poco cambiando el concepto de normalidad en el
sistema hasta adecuarlo a sus propositos.
99
Las mediciones se hacen cada breves periodos de tiempo para que un pico de actividad al comienzo del periodo
no pueda ser compensado con un descenso de actividad al nal del mismo.
100
101
Por ejemplo la variable número de procesos en ejecución.
Un ejemplo podría ser la comparación entre el número de intentos de entrada al sistema entre el usuario A y
el usuario B.
102
Un log es un registro de auditoría (generalmente un chero de texto) en el cual las aplicaciones vuelcan
información de algún tipo.
103
104
Esto es la más estudiada, pero no por ello la más extendida en entornos productivos.
El sólo hecho de que existan tantas técnicas debería ponernos sobre la pista de que algo no funciona bien ya
que si al menos una funcionase correctamente no habría sitio para muchas más. Esto pone de maniesto una vez
más el estado incipiente en el que se encuentran a día de hoy el conjunto de estas técnicas.
105
A pesar de que pueda parecer sencillo extraer las variables más relevantes incluso del sistema más sencillo
puede resultar extraordinariamente complicado.
106
Existen técnicas matemáticas que tratan de solucionar este problemas calculando el umbral óptimo, sin
embargo en la práctica el umbral suele ajustarse de un modo bastante ad-hoc
293
A pesar de los inconvenientes que presenta este método no debemos olvidarnos de sus ventajas
y es que teóricamente sería capaz de detectar los denominados
Zero days attacks
107
. Debemos
por tanto dar un voto de conanza a un modelo aún en las primeras etapas de su desarrollo, pero
que promete revolucionar el futuro de los sistemas de detección de intrusiones.
Figura 3.43: Esquema de funcionamiento de un modelo de detección de anomalías
107
Ataques nuevos aún no contemplados en las bases de datos, para los que evidentemente no existe ninguna
regla especíca.
294
Conclusiones detección de anomalías
A pesar de los inconvenientes presentados este es uno de los modelos más prometedores y sin
duda marcará el futuro de los sistemas de detección de intrusiones. A continuación se resumen
sus principales ventajas e inconvenientes:
Capacidad teórica de detectar ataques desconocidos por los expertos de seguridad.
Aprendizaje automático, menor necesidad de intervención por parte del administrador
de sistemas.
Tradicionalmente tanto su rendimiento como su efectividad ha sido baja comparada
con los sistemas basados en detección de usos indebidos.
Dado que el sistema evoluciona con el tiempo y la experiencia, cabe la posibilidad de
que un intruso pueda llegar a entrenarlo con el tiempo.
Taxonomía en base a la respuesta
Una vez detectado el ataque ha terminado gran parte de la labor del sistema de detección,
pero no toda, aún queda por decidir cual debe ser la respuesta ante dicho ataque. Existen dos
enfoques a la hora de tomar esta decisión:
Respuesta Pasiva
Este enfoque se caracteriza por una cesión de responsabilidad del sistema
hacia el administrador, el sistema simplemente noticará la ocurrencia de un determinado evento
y deberá ser el administrador quien tome las medidas oportunas para paliar en la medida de lo
posible los efectos del recién detectado ataque ente los métodos de noticación más comunes se
encuentran los siguientes:
Ficheros de registro108 :
Una de las alternativas más comunes y de mayor tradición con-
siste en que el programa escriba109 en un chero predeterminado cualquier evento o noticación que desee comunicar al administrador, será tarea de éste el analizar periódicamente
los cheros de registro en busca de información relevante.
Correo Electrónico:
Otra las alternativas más populares es el empleo del correo electró-
nico, de modo que la aplicación envía en un correo a la cuenta del administrador todas
aquellas incidencias que crea necesario reportar.
SMS110 :
Para noticaciones más importantes el sistema puede enviar un mensaje de texto
al administrador del sistema, indicándole brevemente el tipo y la hora de la incidencia que
se haya producido.
108
109
También llamados cheros de log
Para referirse a la acción de escribir en un chero de registro suele emplearse una mala adaptación del verbo
inglés to log : loguear
110
Acrónimo de Short Message Service, es un servicio disponible en los teléfonos móviles que permite el envión
de mensajes cortos entre teléfonos móviles, jos y otros dispositivos de mano [WIKI01].
295
En cualquiera de los métodos antes descritos se produce una diferencia de tiempo considerable
entre la detección del ataque por parte del sistema y la consiguiente acción del administrador. Es
precisamente este intervalo de tiempo el que hace incompatible el modelo de respuesta pasiva con
lo que más adelante describiremos como IPS o sistema de prevención de intrusiones. Podríamos
decir de un modo un tanto metafórico que un modelo de respuesta pasiva relega las funciones
del sistema de detección a las de un simple observador, es decir, puede presenciar un crimen y
llamar a la policía, pero nunca intervenir directamente a pesar de que una intervención temprana
resultaría casi siempre más efectiva.
Conclusiones respuesta pasiva
A pesar de ser un modelo muy conservador resulta ser una solución extremadamente útil
y la práctica totalidad de los sistemas de detección lo integran en sus soluciones, si no como
alternativa principal sí como complemento a una respuesta activa ecaz.
trusiones. A continuación se resumen sus principales ventajas e inconvenientes:
El sistema no podrá equivocarse tomando una decisión equivocada por cuenta propia.
Es más sencillo de instalar y congurar que un sistema de respuesta activa.
El sistema no podrá acertar tomando una decisión acertada por cuenta propia.
Requiere de una mayor intervención por parte del administrador de sistemas.
Respuesta Activa
Un sistema que implemente respuesta activa tiene la capacidad de res-
ponder ante un ataque una vez detectado. Este enfoque que a priori parece el más lógico111 , debe
con mucha prudencia, ya que a día de hoy no existe112 ningún sistema infalible113 . Deberá por
tanto tenerse en cuenta antes de introducir este tipo de modelos en sistemas productivos el hecho
de que en el caso de un falso positivo,el sistema estará respondiendo ante un estado legítimo.
Cualquier administrador de red sabe, que si la seguridad es importante, aún lo es más el asegurar
un buen servicio.
A continuación se describen las respuestas activas más comunes clasicadas en base el origen
de la captura de los datos:
Respuestas para sistemas de tipo Máquina
111
112
113
Quien mejor para intentar paliar los efectos de un ataque que aquel que viendo como sucede.
Podrá mejorarse la tasa de acierto pero probablemente no existirá nunca un sistema infalible.
falso positivo, es decir
falso negativo que es justo todo lo
Cuando un sistema falla puede hacerlo de dos formas: Bien con un
estado como subversivo cuando en realidad no lo es, o con un
catalogar como ataque un estado que en realidad si que lo es.
296
catalogar un
contrario, no
Envío de señales:
Si el sistema detecta que uno de los procesos en ejecución tiene un
comportamiento sospechosos puede enviarle una señal114 para nalizarlo.
Manipulación de los runlevels115 :
Para evitar males mayores, una vez detectado el
ataque, el sistema puede cambiar el runlevel, bien para apagar la máquina o para desactivar
las funciones de red. De este modo y como medida cautelar, el sistema quedaría en modo
de cuarentena hasta que el administrador del sistema decida cómo solucionar el problema.
Sistemas de decepción116 :
Una vez detectado el ataque, el sistema puede redireccionar el
proceso sospechoso a un honeypot, de este modo el proceso o la sesión del usuario seguiría
en ejecución pero en un contexto inocuo. El objetivo perseguido con esta técnica es ganar
tiempo para decidir si realmente es una ataque o en caso de que se conrme que sí lo es,
disponer del tiempo suciente para poder trazar la conexión e identicar al atacante.
Respuestas para sistemas de tipo Red
Interrupción de sesión:
Suponiendo que el protocolo en el que se encuentre el ataque
sea orientado a la conexión, sería posible que el sistema de detección cerrase esa conexión
remotamente. En el caso de TCP esto se consigue inyectando117 un paquete con el ag
RST activo. El éxito de esta técnica radica en inyectar el paquete antes de que el atacante,
de lo contrario no tendrá efecto pues los números de secuencia TCP no coincidirán.
Manipulación del Filtrado:
Esta opción permite la modicación de las reglas de un
rewall para así denegar el acceso118 a la IP del atacante durante un cierto tiempo.
DoS119 y DDoS120 :
Hay autores que consideran la opción de contraatacar frente a una
agresión. Para ello coordinarían una o varias máquinas para lanzar una denegación de
servicio al atacante.
114
115
En sistemas Unix like la señal que enviaría es la 9 (SIGKILL) denida en /usr/include/signal.h
En entornos Unix like, existen diferentes runlevels (niveles de ejecución), estos son los encargados de denir
que servicios están disponibles en el sistema. Para este caso en concreto son interesantes los runlevels 0 (parada
del sistema) 1 (modo monousuario) 2 (modo multiusuario sin red)
116
117
También llamados honeypots (tarros de miel)
Para inyectar un paquete dentro de una conexión de tipo TCP, necesitamos saber cuales son las IP origen
y destino de los dos extremos y el número de secuencia del segmento inmediatamente anterior al que queremos
inyectar. Toda esta información podemos conseguirla esnifando la conexión en curso.
118
119
En inglés se emplea el verbo to ban
Un ataque de denegación del servicio, también llamado ataque DoS (Denial of Service), es un ataque a un
sistema de ordenadores o red que causa una pérdida en el servicio a los usuarios. Normalmente provoca la pérdida
de la conectividad de la red por el consumo del ancho de banda de la red de la víctima o sobrecarga de los recursos
computacionales del sistema de la víctima. [WIKI02]
120
DDoS ( Distributed Denial of Service )es una ampliación del ataque DoS, se efectúa con la instalación de
varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos. [WIKI02]
297
Conclusiones respuesta activa
La respuesta activa es el primer paso hacia la prevención de intrusiones (IPS121 ). A día de
hoy pocos son los expertos en la materia que no vean en esta técnica a la alternativa dominante
en un futuro no muy lejano.
trusiones. A continuación se resumen sus principales ventajas e inconvenientes:
El sistema podrá acertar tomando una decisión por cuenta propia.
Requiere de una menor intervención por parte del administrador de sistemas.
El sistema podría equivocarse tomando una decisión equivocada por cuenta propia.
Dado que hay que integrar el sistema de detección con el resto del hardware de la red,
la conguración suele ser más compleja.
IPS Intrusion Prevention Systems
Una de las últimas tendencias en el desarrollo de sistemas de detección de intrusiones son
los IPS o sistemas de prevención de intrusiones. Estos sistemas son una evolución lógica hacia la
hibridación entre los rewalls122 y los NIDS (véase Figura 3.44: IPS integrado en una red).
Figura 3.44: IPS integrado en una red
121
122
IPS (Intrusion prevention systems) técnica que se explica más adelante.
Conjunto de hardware y/o software montados sobre un sistema que controla el tráco entre dos redes aplicando
una serie de reglas especicas.
298
¾Por qué detectar a nivel de Firewall?
El rewall es un elemento crítico en cualquier cualquier red.
Nexo de unión con el mundo exterior.
Punto medio por el que pasa todo el tráco.
Modicación sencilla.
Alta efectividad (bajos falsos positivos)
En un sistema de estas características el tráco es analizando antes de entrar en la propia red,
luego si detectamos un ataque, este no tiene por que llegar a su destino, basta con que el IPS
ordene al rewall que haga un drop del paquete en cuestión, para que el ataque nunca llegue a
su destino. Atendiendo a las características expuestas en [SANS01] un IPS debe:
Deben analizar el tráco y responder en tiempo real para detener el ataque que se este realizando, ya que si la respuesta es muy lenta o tardía los host pueden haber sido
comprometidos y la intrusión no haberse evitado.
Debe tener un ratio muy bajo de falsos negativos y ser capaz de detectar un numero elevado
de ataques que no solo buscan la intrusión sino también la evasión123 . Al tiempo que no
deben provocar la denegación de servicio a usuarios legítimos.
Deben detectar e informar de actividades, internas y externas, anómalas así como del mal
uso de los recursos de los sistemas.
Alertar al personal de seguridad y responder a los intentos de intrusión modicando el
rewall o bloqueando el ataque el curso.
Deben ser capaces de procesar todo el tráco que se produce en las redes de alta velocidad124 .
123
124
Es decir pasar el control del IPS, típicamente con campos de la cabecera ttl muy bajos.
De lo contrario no serían de procesar todo el traco y sólo les quedaría dos alternativas descartar el paquete
o dejar pasar el tráco sin analizarlo. Cualquiera de las dos alternativas es seguramente una mala idea.
299
3.3.4. Introducción a DFSU
A lo largo del Capítulo 1 hemos pasado revista en mayor o menor medida a los distintos
modelos que históricamente han sido empleados para tratar de detectar de un modo lo más
efectivo posible, cualquier intrusión o intento de intrusión. En el segundo capítulo, emplearemos
estos conocimientos para describir y clasicar DFSU tratando en la medida de los posible justicar
nuestras decisiones. Tras la lectura de este capítulo el lector deberá comprender cuál la estructura
básica de DFSU y ser capaz de describir comparativamente DFSU con respecto a las técnicas
descritas en el Capítulo 1.
¾Por qué desarrollar otro IDS?
A día de hoy existen en el mercado innidad de alternativas capaces de implementar la
práctica totalidad de las técnicas de detección descritas a lo largo del primer capítulo, parece por
tanto lógico hacerse las siguientes preguntas ¾tiene sentido crear otro IDS?, ¾aporta DFSU algo
nuevo al panorama tecnológico actual o es una simple prueba de concepto?
Para contestar a estas dos preguntas, lo mejor sería empezar por explicar lo qué no es DFSU.
A pesar del contexto puramente académico en el que se localiza el presente trabajo, DFSU
no es ni un desarrollo formal ni una prueba de concepto sino más bien todo lo contrario. DFSU
pretende ser una alternativa real a los problemas125 de seguridad a los que el conjunto de nuestros
sistemas de información deben hacer frente cada día, problemas que por otra parte ninguno de las
innumerables alternativas existentes en el mercado ha sido capaz de erradicar. Con la esperanza
de triunfar donde otros fallaron surge DFSU, un nuevo enfoque en los sistemas de detección de
intrusiones.
¾Qué es DFSU?
Si nos remontamos al comienzo de esta memoria, concretamente al Capítulo 1, capítulo en el
que se describe el estado del arte de los sistemas de detección de intrusiones, veremos que éste
se encuentra dividido en tres secciones principales. En cada una de estas secciones se describe
una taxonomía o clasicación126 :
Los IDS's pueden estar basados en host o basados en red,
basados en anomalías o basados en reglas .
Cada una de estas clasicaciones tiene sus ventajas e
inconvenientes, mientras que los sistemas basados en reglas son poco exibles pero muy ables,
los sistemas basados en anomalías son justo todo lo contrario, muy exibles pero poco ables.
La inmensa mayoría127 de los sistemas existentes siguen muy de cerca esta clasicación,
es decir, crean sistemas basados en máquina o en red, basados en anomalías o reglas, algunos
empiezan ahora a incorporar respuesta activa y respuesta pasiva pero son los menos128 . Nosotros
125
126
127
Problemas por otra parte no menos reales
Véase Figura 3.45
A excepción de DIDS (Distributed Intrusion Detection System) prototipo desarrollado por la universidad de
California, no se continua desarrollando.
128
Algunos plugins de snort permiten recongurar iptables y snort inline por su puesto
300
creemos que este tipo de clasicaciones están obsoletas129 , puede que tuviese sentido hace años
cuando la seguridad de la información era un problema virgen y tan gigantesco que tratar de
abarcarlo todo a la vez era impracticable. Hoy cada uno de los campos de especialización en los
que se dividió el problema para hacerlo más asequible, está lo sucientemente maduro como para
retomarlo y emplearlo como base solida desde la que lanzar el ataque nal hacia la unicación.
El futuro pasa por correlacionar el tráco sospechoso en un segmento de red con la actividad
anómala en el ordenador que lo generó y esto es precisamente lo que es DFSU; Un framework
capaz de analizar de un modo centralizado tanto la información de cualquier tipo de dispositivo
físico (PC's, PDA's, teléfonos móviles) como máquina de sus comunicaciones (tráco de red).
Figura 3.45: Taxonomía de los sistemas de detección de intrusiones
129
Al menos en la práctica, desde un punto de vista académico la clasicación seguirá siendo por supuesto válida.
301
DFSU, una visión arquitectónica
Para lograr la integración tan deseada, DFSU se fundamenta en un modelo multicapa de
agentes distribuidos. Cada uno de los agentes distribuidos será un punto de recogida de información heterogéneo que podrá estar instalado bien en una máquina, recogiendo la información que
procesaría un HIDS o bien en un segmento de red recogiendo la información que procesaría un
NIDS. Es importante recalcar que los agentes distribuidos a diferencia de los HIDS o NIDS no
realizan ningún tipo de procesamiento sobre la captura sino que simplemente lo empaquetan y
lo envían a través de la red hasta la infraestructura centralizada de procesado.
Dado que el procesado no tiene lugar en el punto de captura, los agentes serán procesos ligeros
que podrán instalarse en prácticamente cualquier dispositivo hardware130 sin una degradación
perceptible en su rendimiento131 . Evidentemente esto tiene su contrapartida, la infraestructura
centralizada a la que se reporta toda la información desde los agentes, deberá ser capaz de
procesar grandes volúmenes de información132 . DFSU consigue este objetivo introduciendo una
capa de procesamiento sobre la que el administrador podrá añadir o retirar unidades133 hasta
ajustarlo a las necesidades de su entorno productivo.
130
A día de hoy tenemos programados agentes de este tipo no sólo para segmentos de red u ordenadores perso-
nales, también para teléfonos móviles y PDAs
131
No degradando de un modo perceptible el rendimiento de la máquina sobre la que se ejecuta, solventamos
uno de los grandes inconvenientes presentados por los HIDS.
132
El volumen de información dependerá lógicamente del número de agentes y de la cantidad de información que
recojan.
133
Nos referimos por unidades a cualquier dispositivo capaz de procesar información, generalmente serán PCs
302
DFSU se fundamenta por tanto en una arquitectura cliente/servidor de 3 capas134 : la capa
de captura, capa de distribución y capa de procesamiento. La idea fundamental de la losofía
cliente/servidor es la distribución de las tareas que debe realizar el sistema. Cada capa se encarga
de proveer ciertos servicios:
Capa de captura:
Constituida por el conjunto de los agentes distribuidos, su misión será
recoger información heterogénea, empaquetarla y enviarla a la capa de distribución.
Capa de distribución:
Esta capa tiene la misión de centralizar tanto las entradas del
sistema (fuentes de información e interfaces de administración) como las repuestas
135
tras
la detección de un ataque.
Capa de procesamiento:
Una vez que la información llega hasta la capa de distribución,
esta se encarga de redistribuirla entre los distintas unidades que componen la capa de
procesamiento, estas en caso de detectar algún ataque le retornarán un aviso.
Una arquitectura multicapa cliente/servidor como lo que aquí se presenta, conere al sistema las
siguientes características:
1. Escalabilidad: Permite la adición de nuevos equipos en cualquiera de sus 3 niveles para
acomodarse a los requerimientos dinámicos del sistema.
2. Portabilidad: El software continua en vigencia más tiempo que el hardware que lo soporta,
es por ello que el software de DFSU se caracteriza por su portabilidad a través de distintos
tipos de hardware136 y sistemas operativos.
3. Apertura: Todos los datos están almacenados en cheros de formato abierto137 manipulables desde de un simple editor de textos.
4. Flexibilidad: Una arquitectura de este tipo permite ajustar la topología del sistema a un
gran número de entornos productivos.
3.3.5. Estructura básica de DFSU
Hoy en día la reducción de costes es un factor muy a tener en cuenta por toda empresa
que desee ser competitiva en el mercado, en este sentido, la adquisición de grandes máquinas
de procesamiento comienza a no ser justicable ante soluciones más económicas como son los
sistemas de procesamiento distribuido. En este capítulo se expondrán con nombre propio los
elementos que componen el sistema distribuido de DFSU ya explicados durante el Capítulo 2 así
como las topologías en que puede congurarse un sistema productivo.
134
135
136
Véase Figura 3.43[UINDEB01]
Véase el apartado 3.3.3
Hasta la fecha ha sido probado satisfactoriamente en arquitectura de 32 y 64 bits y en LittleEndian y BigEn-
dian
137
Formato XML Extensible Markup Language
303
Figura 3.46: Arquitectura de tres capas
Elementos estructurales y deniciones preliminares
Dentro de la estructura de DFSU se distinguen 3 elementos básicos: Masters, Heads y Tails,
la función de estos es implementar cada una de las capas en las que se divide DFSU:
1. Capa de Captura → Masters
2. Capa de Distribución → Heads
3. Capa de Procesamiento → Tails
Masters o agentes distribuidos
Los Masters son agentes heterogéneos y distribuidos cuya función es capturar, etiquetar y
encapsular en eventos la información que se desea analizar. Se encuentran dispersos a lo largo de
la red138 .
Además de enviar la información capturada a la unidad central (Head), estos agentes pueden
ser capaces de recibir y procesar comandos enviados por él. Estos comandos pueden ser de
conguración ya que DFSU se gestiona de un modo centralizado desde el Head o de respuesta
activa, en caso de que el sistema esté funcionando en modo IPS.
Dado que contamos con Masters especializados en diferentes campos (HIDS y NIDS), el
sistema dispone de una visión global de todo el entorno, pudiendo incluso llegar a correlacionar
eventos de máquina con eventos de red. Imaginemos por ejemplo una red en la que se dispone
de un master de red (Master2) y de un master de host (Master1)139 , ambos reportando la
información capturada a la infraestructura de DFSU. Supongamos ahora que el Master2 detecta
138
Normalmente los monitores de red suelen ubicarse en cada uno de los dominios de colisión de la red y los
Monitores de host en cada una de las máquinas que se quiera auditar.
139
Véase Figura 3.47
304
una anomalía en el tráco de red de la Subnet1, DFSU podría correlacionar esa anomalía con
el comportamiento de la aplicación que lo ha generado en el Host1, aprendiendo así cual es el
comportamiento a nivel de syscalls que tiene un efecto pernicioso para el sistema a nivel de red.
Fíjese el lector que DFSU desborda a los sistemas tradicionales ya que tiene acceso tanto
a los efectos del problema140 como a las causas que lo originaron141 , pudiendo así analizar el
problema desde los dos puntos de vista. Por si ésto fuera poco, DFSU puede llevar la respuesta
activa hasta cotas nunca antes soñadas y es que teniendo acceso directo tanto a las causas como a
los efectos puede intervenir sobre ambos. En el ejemplo propuesto, podría intervenir activamente
y recongurar un Firewall para que no deje pasar más tráco desde el Host1 (actuando sobre los
efectos) o podría cerrar la aplicación que esta creando problemas (actuando sobre las causas).
Como puede verse un modelo de este tipo permite un campo de acción prácticamente ilimitado.
Figura 3.47: Correlacionando HIDS y NIDS
Masters implementados hasta la fecha
A día de hoy DFSU cuenta con tres tipos de
masters completamente funcionales. Estos masters son tanto para la monitorización del tráco
de red como para la auditoría de máquinas. En el caso de los sistemas de red empleamos un
versión modicada de snort y en el caso de las auditorías hemos desarrollado una aplicación
nueva para la captura de syscalls como se explicará más adelante.
Monitor de red
Al comienzo del proyecto se planteó la opción de crear un monitor de
red empleando para ello la librería libpcap142 , llegando incluso a desarrollar versiones funcionales
de éste. Poco tiempo después nos dimos cuenta de que en realidad no tenía demasiado sentido
reprogramar desde cero algo sobre lo que habían estado trabajando programadores muy cualicados durante mucho tiempo. Decidimos por tanto adaptar Snort a nuestras necesidades. Ésta
elección tubo por dos motivos:
140
141
142
En este caso un ataque de red
Un conjunto de syscalls determinado.
Libpcap es una librería para la captura de datos desde zona usuario.
305
http://www.tcpdump.org
. [LOPEZ01]
1. Snort es a día de hoy el estándar de facto en los sistemas de detección de intrusiones basados
en red.
2. Snort está licenciado bajo GPL, gracias a esto podemos tomar su código modicarlo y
redistribuirlo143 .
Modicando Snort hemos conseguido no sólo las ventajas del mejor snier sino también un
veredicto con el que entrenar nuestros plugins basados en inteligencia articial de un modo
automático y no supervisado.
Monitor de Host
De todas las técnicas existentes a la hora de implementar un HIDS
hemos elegido la auditoría de syscalls por considerarla la más difícil de burlar144 siendo a la vez
la que puede suministrarnos una información más completa y detallada sobre la ejecución de los
programas en la zona usuario. No descartamos sin embargo integrar en el futuro esta solución
con otras ya existentes como por ejemplo Tripwire145 .
Actualmente en desarrollo
Existen a día de hoy varios proyectos del tecnológico de
Deusto que emplean la infraestructura de DFSU y en los cuales se están implementando nuevos
Masters, concretamente versiones para Windows Mobile lo que permitiría emplear DFSU en más
del 50 % del mercado de PDA's [EROSKI01], también para Symbian lo que cubriría el 57 % del
mercado de teléfonos de última generación146 [QUES01]. Finalmente existe también un proyecto
de crear una versión para Windows.
Head o unidad central
El Head es el elemento principal de la arquitectura e implementa la capa de distribución. Su
misión principal es la de recibir los eventos provenientes de los Masters y distribuirlos entre los
Tails pudiendo antes hacer ligeras147 modicaciones sobre esta información e incluso añadir nuevos datos. Se encarga también de centralizar todas las labores administrativas ya que implementa
las interfaces de usuario.
La distribución de la información o balanceo depende de la política de forwarding con la
que este congurado el sistema148 , el objetivo perseguido al balancear la información es dividir
el número de eventos entre varias unidades de procesamiento (Tails), logrando de este modo
aumentar el rendimiento y permitiendo una escalabilidad sin precedentes.
143
144
Por supuesto esto nos obliga a mantener la licencia original es decir GPL
Recordemos que está implementada a nivel de Kernel y no de usuario que es desde donde llegan los posibles
ataques.
145
146
147
Tripwire
http://sourceforge.net/projects/tripwire
También llamados SmartPhones
Las modicaciones deben ser computacionalmente sencillas, ya que si sobrecargamos el head toda la infraes-
tructura se resentirá notablemente.
148
Véase 3.3.7
306
Para simplicar las labores de administración, el Head centraliza además el conjunto de
alertas generadas por los Tails y toma la iniciativa de la respuesta activa enviando ordenes de
reconguración tanto a masters de red como a masters host.
El Head es una pieza clave del sistema, si el Head falla el sistema al completo dejaría de
funcionar, de ahí que en entornos reales existe la posibilidad de congurar Heads de respaldo los
cuales en circunstancias normales estarían inactivos pero que si ocurriera un fallo grave o una
labor de mantenimiento del sistema principal, podrían activarse y continuar con el trabajo.
Tails o unidades de procesamiento
Los Tails reciben y procesan tanto los eventos como los comandos que el Head les reenvía. Una
vez han recibido esta información se pone en marcha la infraestructura de eventos; Un paquete
de información es un evento de tipo red (nEvent) o de tipo host (hEvent) de modo que todos
los plugins suscritos al evento en curso serán llamados para que desarrollen la labor para la que
fueron creados.
Si el plugin en cuestión es un ExpertPlugin149 , éste deberá establecer si el paquete es o no
un ataque. En caso de que lo sea, la infraestructura generará un evento de tipo alerta (Alert)
que será enviado de vuelta al Head. Éste llamará a los plugins suscritos a eventos de tipo alerta
(OutputPlugins) y serán ellos quienes tomarán las medidas de respuesta oportuna.
Podríamos decir que los Tails son en núcleo de proceso de DFSU, pues en ellos se llevan a
cabo las labores de detección. Dado que la arquitectura permite escalar su capacidad simplemente
añadiendo maquinas, sería posible reducir el gasto en hardware empleando muchos ordenadores
lentos para igualar la prestaciones que daría uno más rápido o unir varios rápidos para manejar
un volumen de datos muy grande.
Conguraciones topológicas soportadas por DFSU
Uno de los principales problemas a los que deben hacer frente los sistemas de detección de
intrusiones es sin duda ser capaz de procesar un volumen de datos ingente y hacerlo además en
un lapso lo sucientemente pequeño como para poder dar una respuesta en tiempo real. Se hace
por tanto necesario, aumentar las capacidades de proceso de éstos sistemas.
Existen al menos dos alternativas para llevar a cabo ésta tarea; Por un lado nos encontramos
con la escalabilidad vertical. Esta consiste en denitiva en aumentar la potencia del hardware150
bien mejorando sus componentes151 , bien adquiriendo uno nuevo más potente. La otra alternativa
es la escalabilidad horizontal que consiste en emplear de un modo combinado la potencia de
equipos más pequeños, para lograr así un potencial de cálculo superior al que podrían desarrollar
cada uno de ellos por separado.
149
150
151
Véase 3.3.7
Esto puede conseguirse mediante el uso de mainframes y demás ordenadores de gama alta.
En inglés to upgrade
307
En las fases iniciales de este proyecto descartamos la escalabilidad vertical. La principal razón para tomar esta decisión, fue que ésta lleva asociada una inversión económica que no está
al alcance de muchas pequeñas y medianas empresas, ni por supuesto al de usuarios domésticos.
Decidimos por tanto apostar por un sistema de capas que permitiera ajustar de una manera exible y sencilla la capacidad de cómputo del sistema a cada escenario productivo. A continuación
se describen las principales
Estructura mono-capa
Esta es la conguración topológica más sencilla de todas y consiste en arrancar todas las capas
en la misma máquina. Es decir, tener en una sola máquina arrancados los Master y el Head con
los plugins de detección activos. Este modelo está totalmente desaconsejado para un sistema
productivo, sin embargo puede resultar muy socorrido en entornos académicos o de desarrollo en
los que el rendimiento no es un factor a tener en muy cuenta.
Estructura de dos capas
Únicamente desglosamos dos capas, una de captura y una en la que fusionamos distribución
y procesado. Activamos de este modo los plugins de detección en el Head prescindiendo de los
Tails pero aprovechando la potencialidad que nos dan los Masters distribuidos.
A la hora de montar este modelo, deberá tenerse en cuenta que la capacidad de procesamiento
de DFSU estará limitada por la máquina en la que se monte el Head, debiendo en cualquier caso
controlar el número de Masters distribuidos para no llegar a un escenario en el que el sistema se
vea sobrepasado por una carga de información excesiva.
En este tipo de conguración la escalabilidad en caso de sobrecarga está muy limitada, por eso
creemos que está puede resultar útil para sistemas no críticos quedando claramente descartada
para proteger redes de importancia crítica o que puedan generar un gran volumen de datos.
Figura 3.48: Estructura de dos capas
308
Estructura de tres capas
Esta es la conguración en donde DFSU explota plenamente el potencial de las tres capas152 .
En este esquema los plugins de detección se localizan en los Tails siendo éstos quienes envían las
alertas de vuelta hacia el Head para ser tratadas.
Como puede en Figura 2: Estructura de tres capas el número de Tails es variable, pudiendo
el administrador adaptar su número hasta adecuarlo a las necesidades de la red.
Figura 3.49: Estructura de tres capas
Se recomienda que la información que circula entre Heads, Tails y Masters vaya por una red
separada, de este modo no degradaremos el rendimiento de la red que pretendemos monitorizar153
sobre la que está montada el sistema productivo de la empresa y además proteger al propio
sistema de detección de potenciales ataques.
152
153
Véase Figura 3.43
De lo contrario un master de red el tráco de paquetes puesto que todo lo que circulo lo encapsula y reenvía
al head.
309
Estructura con plugins distribuidos
Los plugins de detección son los encargados del proceso de análisis de la información recogida
y pueden basarse bien en reglas cuya ejecución es poco costosa y por lo tanto suponen una
sobrecarga leve en el sistema o bien en redes con gran capacidad de análisis (Redes Bayesianas154 )
las cuales suponen una sobrecarga muy alta en la máquina donde están ejecutándose. Es en este
segundo caso donde los plugins distribuidos ayudan a evitar la sobrecarga del Tail que aloja los
expertos.
Figura 3.50: Estructura con plugins distribuidos
En caso de que dispongamos de un plugin muy pesado, podremos preparar una máquina, que
deberá estar conectada al Tail, donde se ejecutará el experto evitando así la posible sobrecarga.
154
Modelo probabilístico que relaciona un conjunto de variables indicando
explicitamente mediante un grafo dirigido inuencia causal.
310
Estructura con Heads jerárquicos
Si bien es cierto que el balanceo de carga existente en el Head alivia la carga que soportan los
Tails para que no se saturen, en sistemas con grandes volúmenes de información para analizar,
es el Head quien podría llegar a saturarse.
Para solucionar este posible aunque improbable problema, se puede establecer una jerarquía
de Heads que funcionarían de la siguiente manera:
1. En un primer nivel, el head únicamente actuaría como balanceador distribuyendo los eventos recibidos, sin realizar ningún cálculo ni procesado, de forma homogénea entre los Heads
de nivel 2.
2. En el segundo nivel, los Heads coordinados entre sí como si de uno solo se trataran, balancearían los eventos entre los Tails.
Figura 3.51: Estructura de Heads jerárquicos
Como puede verse en la Figura 3.51 podemos tener tantos Heads funcionando en paralelo
como se desee.
Conclusión
Sin duda contar con una arquitectura multicapa es una de las mayores virtudes DFSU, gracias
a ella podemos crear topologías tan diversas como las que se han presentado a lo largo de este
capítulo y que coneren a DFSU una escalabilidad y exibilidad sin precedentes en este campo
de estudio.
311
3.3.6. DFSU un programa polifacético
DFSU puede verse desde varias perspectivas según quién y cómo vaya a utilizarlo. Es por
ello que este apartado se desglosa en tres puntos; Perspectiva del usuario nal, perspectiva del
administrador de sistemas y perspectiva del desarrollador.
En cada apartado se explicará lo que cada usuario debería conocer para la correcta utilización
de DFSU y la repercusión que la implantación tendría en cada uno de ellos. Tras la lectura de
este apartado se deberán conocer las diferencias entre las tres perspectivas existentes.
DFSU desde la perspectiva del usuario nal
¾Quién puede ser un usuario nal de DFSU?
La respuesta a esta pregunta es fácil; cualquiera. Existen dos maneras a través de las cuales
DFSU puede estar recopilando nuestra información:
1. A través de la Red: Se da este caso cuando se está conectado a una red donde agentes
de DFSU están monitorizando el tráco que circula . La adquisición de datos por parte de
los agentes es completamente transparente para estos usuarios.
2. A través de Host: En este caso el agente debe estar instalado en la máquina del usuario.
Ésto genera un tráco añadido a la red que aún no siendo muy elevado, debe estar calculado
por los administradores de la misma con el n de que no repercuta en la percepción que el
usuario tiene de la calidad del servicio.
Problemática en materia de seguridad a la que se enfrentan los usuarios nales
Actualmente los usuarios que desean tener protegido su terminal, tanto PC's como PDA's y
terminales móviles, utilizan una serie de herramientas como antivirus, rewalls, HIDS, etc., que
repercuten de forma negativa en el rendimiento del sistema que utilizan. Además, deben soportar
las constantes actualizaciones a las que se ven sometidas diariamente estas aplicaciones con el
n de hacer frente a los nuevas herramientas de ataque.
La utilización de estos sistemas, en donde el cálculo se realiza en el cliente, comienza a no
estar justicada pues día a día se dispone de: Redes de mayor capacidad para el envío de la
información y Arquitecturas con mayor potencia de cálculo para el procesado de la misma.
¾En qué medida DFSU puede resolver estos problemas?
Al igual que en la tecnología web, donde los nuevos sistemas tienden a servidores que se
encargan de la mayoría de los cálculos y el usuario únicamente necesita un cliente muy ligero
para visualizar la información, DFSU propone agentes muy ligeros. Masters donde solamente
se captura y se envía la información que se desea procesar a través de la red. Esto supone una
312
mejora palpable en el rendimiento de los ordenadores, mucho más en terminales móviles, y por
tanto una transparencia casi total para el usuario cuando hablamos de auditoría de Hosts. La
transparencia total se ve reejada en el ámbito de las Redes y la monitorización de su tráco,
donde el usuario nal no necesita tener instalado en su terminal ningún tipo de agente. En
este caso son los propios administradores, (ISP's155 y demás operadores de telecomunicaciones,
bancos, multinacionales, etc.), quienes los instalan a lo largo de sus redes.
155
Internet Service Provider, (Proveedor de servicios de Internet)
313
DFSU desde la perspectiva del administrador
Un administrador debe ser capaz de congurar la infraestructura del modo que desee. En
esta sección se detallarán pues, los elementos congurables así como los diferentes modos de
funcionamiento y se hará una descripción exhaustiva sobre el sistema de plugins y su correcta
utilización.
¾Quién puede ser un administrador de DFSU?
Ya que entre las tareas más importantes que debe llevar a cabo un administrador de DFSU
tocan el ámbito de las redes y el sistema operativo GNU/Linux, lo más recomendable sería
disponer de un profesional con un nivel alto de conocimientos en estos campos.
Problemática a la que se enfrentan los administradores de sistemas
Los administradores de sistemas han de lidiar diariamente con ataques dirigidos contra las
redes que están administrando. Para ello instalan y mantienen sistemas de seguridad de diferentes
tipos por lo que deben conocer un amplio número de conguraciones posibles por cada sistema
instalado además de las interfaces y comandos que oferta cada uno de ellos.
¾En qué medida DFSU puede resolver estos problemas?
DFSU trata de solucionar en la mayor medida posible estas complicaciones, unicando los
diferentes sistemas de detección de intrusiones existentes y centralizando la conguración de todo
el sistema desde la unidad central (Head) que proporciona una interfaz intuitiva y potente.
Conjunto de tareas asociadas a un administrador de DFSU
El administrador de sistemas se deberá encargar de congurar y poner a punto el sistema,
así como de tomar las decisiones sobre:
1. Qué estructura es la más adecuada.
2. Cuántas y dónde se han de situar las sondas.
3. Los plugins que estarán cargados.
4. Las políticas de enrutado y de respuesta ante alertas.
Las sondas se han de colocar en aquellos sitios de la red donde se quiera monitorizar la información
que circula por ella y en aquellas máquinas en los que se quiera realizar una auditoría sobre su
funcionamiento.
314
Lo más habitual es cargar los mismos plugins de detección en todos los Tails, pero si se
dispone de una cantidad muy elevada de éstos, puede ser recomendable no cargarlos todos dejando
únicamente los más actuales.
De haber un plugin muy pesado, la mejor opción es que sea cargado en el sistema como
distribuido.
315
DFSU desde la perspectiva del desarrollador
DFSU es un proyecto vivo que debe seguir creciendo y adaptándose a las nuevas ideas y
requerimientos. Actualmente existen desarrolladores que se encargan de estas tareas y aquellos
programadores que deseen unirse al proyecto y aportar sus ideas y conocimientos, deben tener
una base y experiencia con el n de que lo realizado sea robusto y able.
¾Quién puede ser un desarrollador de DFSU?
La estructura principal de DFSU ha sido desarrollada en c++ bajo la plataforma GNU/Linux.
Es por esto por lo que un desarrollador que quiera ayudar en la mejora y ampliación de la
infraestructura interna, debe tener experiencia en los siguientes campos:
1. Diseño de aplicaciones con idiomas de programación orientados a objetos
2. Programación en c++ sobre el sistema operativo GNU/Linux
3. Programación en redes.
Si se desea desarrollar un agente distribuido, basta con conocer el sistema para el que se quiera
desarrollar el agente y tener conocimientos sobre programación en redes.
Como último apunte mencionar que es preferible que los desarrolladores utilicen la mayor
parte de código estándar posible.
316
3.3.7. Componentes de DFSU
Arquitectura de plugins
Los plugins son una parte fundamental de DFSU pues la captura de datos y el procesado
existente en la infraestructura, está destinado ha hacerles llegar la información que necesitan
debidamente formateada y de la forma más transparente posible.
Todos los plugins a excepción de los propios del sistema,
System Plugins ,
se compilan
fuera de la infraestructura como librerías dinámicas. Ésto quiere decir, que se puede desarrollar
un plugin y probarlo sin necesidad de compilar una y otra vez la infraestructura, ahorrando
un tiempo considerable. Además da la posibilidad de cargar solamente aquellos plugins que
deseemos en cada momento de forma dinámica, sin necesidad de modicar, recompilar o reiniciar
la infraestructura.
Otra de las ventajas de que los plugins sean independientes es que pueden estar licenciados
bajo una licencia diferente a la que lleva la estructura de DFSU, esto es; la GPL. Aquellos
desarrolladores que deseen colaborar añadiendo funcionalidades podrán escoger entre un gran
abanico de posibilidades a la hora de licenciar sus plugins.
Para desarrollar un plugin, basta con elegir la plantilla correspondiente según su función.
Todo plugin hereda de la clase
plugskel Figura 1: Estructura de herencia de los plugins
a
través de la propia al tipo, la cual aporta atributos particulares a cada plugin, como se muestra
en la gura:
Figura 3.52: Estructura de herencia de los plugins
Existen pues tres funciones comunes a modo de api que deben implementarse ya que están
preparadas para que la infraestructura se comunique y envíe información al plugin:
1. void callBack(Evento* evnt): Esta función se ejecutará cuando se de el evento a los
que está suscrito el plugin.
2. doThis(string cmd): Si se quieren interpretar los comandos recibidos por consola se
deberá implementar esta función.
317
3. onExit(): Esta función se ejecutará cuando se destruya el plugin y deberemos colocar en
ella la liberación de la memoria reservada.
Figura 3.53: Clase PlugSkel
318
Tipos de plugins
Como se puede observar en la Figura 1: Estructura de herencia de los plugins existen cinco
tipos de plugins; Utility Plugin, Expert Plugin, System Plugin, Output Plugin y Distributed
Plugin.
Cada plugin cumple una función determinada, por lo que hay que escoger adecuadamente la
plantilla cuando se vaya a desarrollar un plugin:
1. Utility Plugin: Este tipo de plugins suele tener una preferencia alta pues su función
debería ser la de transformar, ltrar o modicar de alguna manera la información referente
a los eventos para otros.
Entre estos plugins podemos encontrar al llamado
conntrack
del que más adelante se
hablará en detalle.
La plantilla de estos plugins se encuentra en
src/uplugins/templateU .
2. Expert Plugin: Los expert plugins o plugins expertos tienen la misión de analizar los
eventos recibidos aplicando algoritmos y técnicas de detección de anomalías, intrusiones
y/o ataques.
Figura 3.54: Clase ExpertSkel
Todo experto hereda de la clase
ExpertSkel
Figura 3: Clase ExpertSkel y debe hacer uso
de la función especial setVeredict que se encuentra sobrecargada posibilitando las siguientes
opciones:
a ) setVeredict(int veredicto):
Esta función únicamente especica el tipo de ataque.
b ) setVeredict(int veredicto, string descripción):
Aquí se nos da la posibilidad de
añadir una descripción en caso de que el veredicto para ataque sea positivo pudiendo
dar más información sobre el ataque.
319
c ) setVeredict(int veredicto, string descripción, int tipoAtaque):
Por último
se puede indicar además del veredicto y de la descripción el tipo de ataque con las
siguientes opciones:
1) INFORMATIVE: El evento recibido no es peligroso, pero se desea reportar su
entrada en el sistema.
2) PONTENTIALLY_DANGEROUS: Indica que de por si el evento no es
dañino y que probablemente depende de la evaluación de próximos eventos y/u
otros parámetros para poder determinar la forma en que afectará su entrada en
el sistema.
3) DANGEROUS: El evento recibido debe tratarse ya que es maligno para el
sistema contra el que va dirigido.
4) EXTREMELLY_DANGEROUS: Indica que el evento es extremadamente
peligroso para el sistema al que va dirigido.
5) TESTING: Es un identicar para pruebas en el sistema.
Por otro lado los valores posibles para los veredictos están denidos en la cabecera
de la clase
ExpertSkel
y pueden ser los siguientes:
El evento recibido no es un ataque.
a
0 NO:
b
0 YES:
c
0 NSNC156 :
El evento recibido es un ataque.
No se debe tener en cuenta el veredicto del plugin para este evento.
La plantilla de estos plugins se encuentra en
src/eplugins/templateE .
3. System Plugins: Los system plugins o plugins del sistema son imprescindibles, desempeñan funcionen críticas del sistema y se compilan junto con este no siendo posible descargarlos. Algunos ejemplos de las tareas que puede desarrollar un system plugin son por ejemplo
la interpretación de los eventos de comandos, decidir sobre el enrutado de paquetes etc...
La plantilla para la creación de estos plugins puede encontrarse en la ruta
src/splugins/-
tempalteS .
4. Output Plugins: Los Output plugins o plugins de salida, son plugins especializados en el
tratamiento de alertas. Una de las características más destacadas de este tipo de plugins es
que se ejecutan en un thread distinto al del resto de plugins, con esto pretendemos evitar
que una operación de entrada salida como por ejemplo la escritura a una base de datos
paralice la ejecución del resto de plugins.
La plantilla para la creación de estos plugins puede encontrarse en la ruta
tempalteO.
156
NSNC es el acrónimo de No Sabe No Contesta
320
src/splugins/-
Plugins con nombre propio
La mayor parte de los plugins con nombre propio son system plugins que desempeñan tareas
fundamentales para DFSU, es por tanto necesario comprender cómo actúan para de este modo
ser capaz de congurarlos adecuándolos a nuestras necesidades.
Deln
En la sección anterior hemos descrito a los Expert plugins como los encargados de
determinar si un determinado evento de tipo red o de tipo host es o no un ataque, dado que
en un sistema pueden convivir varios plugins expertos ¾que sucedería si varios expertos diesen
respuestas contradictorias sobre un mismo evento? aquí es donde entra Deln.
Deln debe su nombre a ser siempre el último plugin en ejecutarse, de este modo puede
recoger los veredictos del resto de plugins expertos que se han ejecutado antes que él y decidir
en base a su modo de funcionamiento que acción tomar, a continuación describiremos los modos
de funcionamiento distintos modos de funcionamiento de Deln, resolviendo en cada caso el
siguiente ejemplo:
1. OR_MODE: Cuando este modo está activo basta con que uno de los expertos arme que
el evento en cuestión es un ataque para que delfín genere un evento de tipo alerta. Si este
modo fuese el modo activo en el momento en que se da la situación descrita en el Ejemplo
2: , Deln generaría una única alerta con una descripción genérica.
2. FOREACH_MODE: En este caso, se generarán tantas alertas como plugins hayan armado que el evento es un ataque. En el ejemplo propuesto Deln generaría 3 alertas, cada
una de ellas con la descripción establecida por cada uno de los plugins expertos.
3. NAIVE_BAYES_MODE: Este es el modo más sosticado de todos los implementados, su funcionamiento se basa en el empleo de una red Bayesiana de tipo Naïve, sin entrar
demasiado en detalle en el funcionamiento de una red Naïve, esta se fundamenta en probabilidades condicionales, de cada uno de los expertos que han dado el veredicto con respecto
a la variable ataque157 , por lo tanto ya no dependerá tanto del número de nodos que digan
que es un ataque sino de la abilidad158 de estos. Se introduce de este modo un factor muy
interesante que es el de puntuación de los expertos o scoring, aquellos con una probabilidad
condicionada alta serán más ables y por lo tanto mejores que otros que expliquen peor la
variable ataque.
157
Empleamos la variable ataque que nos viene del agente de red para entrenar Deln y obtener así unas
probabilidades condicionales lo más realistas posibles, para el caso de los agentes de syscalls el entrenamiento
debería hacerse manualemente ya que no contamos con una variable ataque asociada a cada una de las traza de
syscalls analizadas.
158
Fiabilidad en el mundo de las redes Naïve podría describirse como una probabilidad condicionada alta de que
dado el veredicto armativo de un experto el evento en cuestión
321
Ejemplos de conguración práctica
la consola emplearemos el comando
cmd
Para congurar los modos antes explicados desde
tal y como se detalla a continuación:
En esta imagen pueden verse las opciones que nos da Deln a través del comando cmd.
Figura 3.55: Deln opciones de conguración
Podemos modicar el modo de funcionamiento mediante el comando mostrado en la gura
sustituyendo el indicado por el que deseamos.
Para conocer el modo en el que está funcionando Deln basta con ejecutar el comando de la
gura.
Figura 3.56: Deln cambiando el modo de funcionamiento
322
Figura 3.57: Deln mostrando el modo de funcionamiento actual
Figura 3.58: Listado de modos de funcionamiento de Deln
Este es el listado de modos con los que podemos congurar Deln.
En esta imagen podemos ver la salida del plugin cmdOut mostrando en pantalla una alerta
generada por Deln.
Conntrack
Una de las secciones más importantes de DFSU es Conntrack, este plugin159 se
encarga de llevar un seguimiento a nivel de sesión, una sesión es en el caso de un monitor de
red cada una de las conexiones160 sobre las que está capturando datos, una conexión de red
se identica por una clave privada compuesta por la dirección IP origen + puerto origen + IP
destino + puerto destino. En el caso de los monitores de host una sesión se identica por la
máquina origen y el identicativo de proceso al que pertenecen las syscalls auditadas.
Conntrack implementa un algoritmo LRU161 con las últimas X sesiones 162 ordenadas en base
al número de eventos pertenecientes cada una de las sesiones y el timestamp del último evento
perteneciente a dicha sesión.
159
160
Es un utility plugin, calcula datos para otros plugins
Nos referimos a conexiones lógicas no físicas, de ahí que conntrack también funciona con protocolos no
orientados a la conexión como UDP.
161
162
Least Frequently Used
Dentro de esta sesión Conntrack permite además guardar información de estado asociada a esta sesión como
por ejemplo el número de bytes transmitidos o el número de syscalls procesadas.
Figura 3.59: Deln ejemplo de una alerta
323
En el siguiente apartado se explicará por qué esta información es tan importante para DFSU.
eforwarder
Su función radica en escoger a que Tail al que hay que enviar la información
recogida desde el master, si conntrack es tan importante para DFSU es por que muchos expert
plugins tienen estado163 y si enviásemos por ejemplo la traza de syscalls de un determinado host
cada vez a un Tail distinto este sería incapaz de correlacionar la información de las primeras
syscalls con la de las siguientes pues estas nunca le llegaron. La información de conntrack nos
sirve para poder enviar la información de una misma sesión siempre al mismo tail.
163
statefull expert plugins
324
Figura 3.60: eForwarder opciones de conguración
Figura 3.61: eForwarder listado de modos
eForwarder al igual que Deln dispone de varios modos de funcionamiento, a continuación se
describen brevemente:
1. MODE_ROUND_ROBIN: En este modo los eventos se envían de modo equitativo a
los Tails conectados. Si hubiera 2 Tails conectados, el primer evento se enviará al primer
Tail, el segundo al segundo Tail, el tercero al primer Tail otra vez, etc...
Es el modo óptimo desde el punto de vista del balanceo de carga ya que la diferencia de
eventos recibidos entre Tails será como máximo de uno.
2. MODE_BY_ORIGIN: Este modo envía todos los evento recibidos por un mismo master al mismo Tail.
3. MODE_BY_PROCESS: Este modo envía todas las syscalls generadas por un mismo
proceso siempre al mismo Tail.
4. MODE_BY_USER: Este modo envía todas las syscalls generadas por un mismo usuario
siempre al mismo Tail.
5. MODE_BROADCAST: Duplica la información recibida desde los Masters a todos y
cada uno de los Tails suscritos.
Ejemplos de conguración práctica
la consola emplearemos el comando
cmd
Para congurar los modos antes explicados desde
tal y como se detalla a continuación:
Estos son los comandos con los que podemos comunicarnos con el plugin eForwarder.
Estos son los modos de conguración posibles para eForwarder.
Este es el modo que está funcionando actualmente.
325
Figura 3.62: eForwarer mostrando el modo de funcionamiento actual
Figura 3.63: eForwarder cambiando el modo de funcionamiento
Esta es la forma de cambiar el modo de funcionamiento de eForwarder.
Stats
Para controlar el rendimiento de la infraestructura DFSU cuenta con este System plugin,
su labor es llevar una estadística de las variables más relevantes, por ejemplo el número de eventos
recibidos y su tipo, el número de ataques, si se están produciendo drops etc...164 , en la imagen
Figura 13: Stats, ejemplo de salida por pantalla podemos ver un ejemplo de la salida del comando
cmd Stats.
164
Un drop consiste en descartar un paquete y tiene lugar cuando llega un evento para el que no hay sitio en las
colas.
326
Figura 3.64: Stats, ejemplo de estadisticas de sistema.
Servidor Web Integrado
Uno de los mayores aciertos de DFSU fue integrar un servidor web dentro de la propia
infraestructura, gracias a este servidor al que bautizamos WebOs DFSU cuenta con las siguientes
ventajas:
1. Fácil diseño de interfaces: Al haber programado WebOs desde 0 pudimos adecuar su
diseño perfectamente a nuestras necesidades, una de las ventajas que obtuvimos fue poder
controlar cuando comienza y cuando acaba una petición web de manera que podemos
recoger ordenes desde los CGI165 y así permitir que una interfaz escrita en HTML tenga
acceso directo a una API166 en XML desde la que ejecutar comandos dentro de DFSU
(carga de plugins, descarga etc...). Además al permitir programar en perl, un lenguaje que
conocen muchos administradores de sistemas, permitimos que la gente pueda desarrollar
sus propias interfaces grácas sin tener que recompilar DFSU y sin tener que meter una
sola línea de C++.
2. Arquitectura C/S: Al ser una arquitectura cliente/servidor el administrador puede congurar la arquitectura de DFSU desde cualquier terminal conectado a la red.
3. Independencia de plataforma: La tecnología web es una tecnología estandarizada que
permite a cualquier sistema que tenga programado un navegador compatible acceder a
cualquier web. Algo que no puede decirse de las interfaces web convencionales.
165
166
Common Gateway Interface
Application programming interface
327
3.3.8. DFSU primeros pasos
¾Cómo conseguir el código?
DFSU es software libre y como todo programa de software libre tiene su sitio en sourceforge167 ,
concretamente en la siguiente url: http://dfsu.sourceforge.net
Además puede visitar la web de DFSU en www.dfsu.net donde además de informarse sobre
las últimos cambios puede unirse a las distintas listas de distribución:
Usuarios:
users@dfsu.net
Administradores:
Developers:
admin@dfsu.net
devel@dfsu.net
Licencia
Como ya se ha mencionado con anterioridad DFSU se enmarca dentro del gran proyecto que
es el software libre y como es lógico empleamos licencias libres. El código de DFSU está licenciado
bajo GPL y la memoria que ahora está leyendo está licenciada bajo Creative Commons.
DFSU sigue una política parecida a la del Kernel de Linux en materia de licencias y es que
DFSU usa y apoya explícitamente licencias sin embargo no las forzamos, si un programador o
empresa desea desarrollar plugins para DFSU, no sólo puede hacerlo sino que además puede
elegir la licencia que más le convenza, lo que lógicamente incluye licencias privativas y/o de
código cerrado.
Estructura de directorios
Lo primero que se debería conocer perfectamente es la estructura de directorios en que se
compone el proyecto con el n de poder localizar y congurar lo más ecientemente posible la
opciones necesarias.
Los tres elementos de la infraestructura comparten una jerarquía de directorios muy similar
con la que cualquier administrador de sistemas Unix like se sentirá muy familiarizado. En el
directorio raíz de esta jerarquía se distinguen las carpetas
src
para los cheros fuente,
doc
para los cheros de documentación, etc para los cheros de conguración, lib para las librerías
y
bin
para los binarios.
A continuación expandiremos uno por uno los directorios expuestos anteriormente:
Estructura de la raíz del proyecto
dfsu:
Esta es la rama principal de donde cuelgan la estructura de directorios del Head,
Tail y Masters.
167
http://www.sourceforge.net
328
• dfsu/Head: Contiene todos los cheros fuentes de este elemento de la estructura.
• dfsu/Tail: Contiene los mismos cheros y estructura que la carpeta anterior estando
la diferencia en los datos de los cheros de conguración.
• dfsu/Masters: Es la raíz de donde parten los Masters implementados.
◦ Masters/snortMaster
◦ Masters/syshooker
329
Estructura de directorios en el Head y en el Tail
Head/src:
Agrupa todos los cheros fuentes de la infraestructura proyecto.
• src/includes: Contiene las cabeceras de los fuentes que se encuentran en
src .
• src/eplugins: Carpeta para almacenar los plugins expertos.
• src/oplugins: Carpeta para guardar los plugins de respuesta.
• src/splugins: Carpeta con los plugins del sistema.
• src/uplugins: Carpeta que contiene los plugins de utilidad.
• src/webos: Aquí se encuentran todos los cheros que conciernen al servidor web
WebOs.
◦ src/webos/src: Aglutina todos los cheros fuente que forman el servidor web.
◦ src/webos/etc: Contiene el chero de conguración del servidor web webos.xml .
◦ src/webos/htdocs: Contiene los documentos que utiliza el servidor web para
presentar la página inicial además de una estructura propia de directorios con
todo lo necesario para la edición de la interfaz web.
htdocs/cgi-bin: Carpeta que contiene los scripts ejecutables en perl.
htdocs/xml: Contiene el chero
hirearchy.xml
donde se especica la jerar-
quía que se visualizará en el menú que aparece en la izquierda en la interfaz
web.
htdocs/images: Carpeta donde se encuentran las imágenes que se muestran
en la interfaz.
htdocs/inc: Contiene los cheros que forman la cabecera, en pie de página
y el menú a incluir en las páginas que se quieran desarrollar.
htdocs/static: Contiene los cheros html jos que forman la página web que
se muestra.
htdocs/stylesheet: Ficheros .css que contienen los estilos a utilizar.
htdocs/vars: Ficheros variables que se generan en cada sesión.
◦ src/webos/logs: Carpeta donde el servidor web deja los logs generados.
Head/etc:
Contiene los cheros de conguración más importantes
slaveconf.xml
y
oa-
conf.xml.
Head/bin:
Contiene los ejecutables, tanto del programa como el compilador de plugins
que más adelante se detallará.
Head/doc:
Contiene la documentación al completo de DFSU.
330
Head/lib:
Contiene la librería estática en la que se compilan todos los objetos que se
encuentran en la carpeta
Head/logs:
src .
Carpeta donde se guardan los logs del sistema.
Head/sessions:
Carpeta donde se guarda un xml con un resumen de la sesión con infor-
mación proporcionada por los plugins del sistema, como el número de ataques detectado.
331
Estructura de directorios en el Master Syshooker
Dado que este Master se compone, como ya se ha explicado, de dos aplicaciones existen dos
directorios base para cada una de ellas:
dfsu/syshooker:
Es el nombre del directorio raíz, y de aquí parte la estructura de las dos
aplicaciones.
• syshooker/hookermaster: Este es el módulo que se encarga de capturar las syscalls
del sistema para que las recoja la aplicación cliente. No tiene una estructura interna
de directorios por el reducido número de cheros que lo componen.
• syshooker/hookerclient: La aplicación cliente se encuentra a partir de este directorio. Además aquí podemos encontrar los cheros para compilar y ejecutar la aplicación.
◦ hookerclient/bin: En esta carpeta es donde se encuentra el archivo ejecutable.
◦ hookerclient/etc: Contiene el chero de conguración mastercong.xml , donde
se han de congurar los parámetros para la conexión como más adelante veremos.
◦ hookerclient/lib: Contiene la librería estática donde compilan todos los objetos
del programa.
◦ hookerclient/src: En esta carpeta se encuentran los cheros fuentes de la aplicación.
src/includes: Contiene las cabeceras de los cheros fuentes arriba mencionados.
Estructura de directorios en el Master Snort modicado
Dado que la gran mayoría de esta aplicación es externa al proyecto DFSU, únicamente explicaremos dónde y que se encuentra en las modicaciones añadidas.
snortMaster/src/dfsu:
En esta carpeta es donde se encuentran los cheros fuentes de la
aplicación.
Compilación e Instalación de una instancia de DFSU
Para realizar la instalación y la compilación de DFSU han de seguirse unos pasos y se necesitan
ciertos paquetes de los que se depende los cuales vienen detallados en esta sección.
Se ha intentado que el número de dependencias sea el menor posible para facilitar al máximo
este proceso.
332
Compilación e Instalación
Este apartado se encuentra dividido en tantas partes como de ellas se compone DFSU. Al
principio de cada una de ellas se hará un repaso de los paquetes que se necesitan tener instalados
para poder compilar el programa.
Ya que DFSU está escrito en c++ y la compilación se lleva a cabo mediante el comando
make, necesitaremos tener instalado una versión de g++-3.3 o superior así como una versión de
automake.
Compilación e instalación del Head y el Tail
En el chero INSTALL que encontraremos
en la raíz de la estructura de directorios se nos indican las dependencias de los paquetes necesarios
para poder realizar una compilación satisfactoria. Los paquetes en cuestión son los siguientes:
1. LibXML2: http://xmlsoft.org/
2. ReadLine: http://cnswww.cns.cwru.edu/chet/readline/rltop.html
3. Libncurses5-dev:
4. Perl: libxml-simple-perl
Una vez instalados estos paquetes, bien en su forma binaria, bien desde las fuentes tenemos todo
lo necesario para poder construir DFSU, a continuación se explica cómo:
Abriremos una consola y nos posicionaremos en la raíz del árbol de directorios de DFSU, una
vez ahí entraremos en la carpeta
dfsu/Head ,
donde ejecutaremos el siguiente comando:
$ make
Una vez que el comando haya terminado, podremos entrar dentro de la carpeta
y comprobar que existe el ejecutable
dfsu/Head/bin
dfsu/Head/bin/slave.
Compilación e instalación del Snort Modicado
Para compilar este agente debemos tener
instalada la librería Libpcap. Una vez la tengamos instalada nos situaremos en la carpeta raíz
snortMaster/
y ejecutar los siguientes comandos:
1. $ ./congure
2. $ make
Finalmente para llevar a cabo la instalación se ejecutara el comando:
3. $ make install
333
echo trivialExpert
1
sh p++.sh ../src/eplugins/trivialexpert/ trivialexpert
echo cmdOut
2
sh p++.sh ../src/oplugins/cmdout/ cmdout
Cuadro 3.10: Fichero de compilación compileAll.sh
Compilación e Instalación del Syshooker
Para compilar el módulo del kernel Syshooker
necesitará tener un kernel compilado a mano que puede conseguir en http://www.kernel.org.
Una vez descargado y recompilado con las opciones básicas entre en la carpeta donde se
encuentra el syshooker y ejecute las siguientes instrucciones:
1. $ make
Tras la ejecución de este comando se construirá el módulo del kernel, chero .ko, el cual
podrá insertar dentro del núcleo con el siguiente comando:
2. $ insmod syshooker.ko
Compilación e Instalación de los Plugins
Para la compilación de los plugins tenemos dos
herramientas disponibles en la carpeta bin/ que se encuentra en la raíz de Head y del Tail.
Estas herramientas son scripts de consola; el
p++.sh
y el
compileAll.sh.
Cuando se dispone de un número bajo de plugins lo mejor es editar el segundo chero que
contiene lo siguiente:
Vemos como este script básicamente lo único que utiliza es el p++.sh pues es el que se
encarga realmente de compilar los plugins.
En caso de no querer utilizar este chero lo único que necesitaremos hacer es copiar la linea
marcada con un 1 o la linea marcada con el 2 y cambiar la ruta y el nombre del plugin que
deseamos compilar.
Una vez compilados, solamente necesitaremos incluirlos en el chero
oaconf.xml
para que
sean cargados en el sistema.
3.3.9. DFSU conguración y puesta en marcha de una instancia
Comprendiendo los cheros de conguración
La mayoría de los elementos congurables en el sistema disponen de un chero en el cual
se indica la conguración elegida. Éstos están en formato xml por ser el estándar de facto por
excelencia para el intercambio de información y se encuentran validados mediante un DTD, por
lo que es importante no modicar su estructura.
334
Hay que tener en cuenta, que si bien el Master y los plugins son aplicaciones cada una
independiente de la otra, el programa que ejecutado en el Head y en el Tail es el mismo estando
congurado de modo diferente. Ésto puede ser indicador de la gran importancia de conocer a
fondo las funciones y posibilidades de cada chero.
Ficheros del Head y de los Tails
Son tres los cheros congurables en el Head y el Tail: slaveconf.xml , oaconf.xml y
webos.xml. A continuación se explica su descripción interna y la ruta donde se encuentran:
slaveconf.xml
Es el chero de conguración maestro tanto para los Head como para los Tail.
Todos los puntos comentados aquí sirven tanto para el Head como para el Tail, a no ser que se
especique explícitamente lo contrario.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dfsu_slave SYSTEM "slaveconf.dtd">
<dfsu_slave>
1
<workAsHead value="no"/>
2
<name value="Tail1"/>
3
<verbose value="no"/>
4
<debug value="no"/>
5
<logPath value="etc/"/>
6
<webosPath2Cong value="src/webos/etc/webos.xml"/>
7
<oaPath2Cong value="etc/oaconf.xml"/>
8
<queuesSize value="500"/>
9
<tentacleTimeOut value="15"/>
10
<maxMasters value="15"/>
11
<maxTails value="15"/>
12
<headIp value="192.168.0.1"/>
13
<headBeaconPort value="4320"/>
14
<localBeaconPort value="4320"/>
15
<localTCPPort value="4320"/>
</dfsu_slave>
Cuadro 3.11: Fichero slaveconf.xml del Head y del Tail
335
workAsHead:
La primera etiqueta es posiblemente la más importante de todas, ya que
dene el comportamiento interno de la aplicación, variando de Head a Tail según pongamos
yes
o
no
respectivamente
En el caso de escoger
tiene como nombre
name:
yes
las etiquetas 2, 12 y 13 carecen de sentido. El Head siempre
Head .
La etiqueta name se utilizará para identicar a los diferentes Tails que se conecten y
la única restricción en este campo es que no puede tener el valor
Head .
En caso contrario
no podrá conectarse
En el caso de escoger no da igual lo que se ponga en la etiqueta 6 y 11.
verbose:
Muestra por la consola existente, más información sobre lo que está ocurriendo
en la infraestructura.
debug:
Muestra información útil únicamente para desarrolladores del sistema.
logPath:
Ruta donde se guardarán los cheros de log.
webosPath2Cong:
Es la ruta donde se encuentra el chero de conguración del servidor
web integrado WebOs, que más adelante se detallará.
oaPath2Cong:
Especica la rula a uno de los cheros de conguración más importantes.
En él se almacena toda la información referente a los plugins que deben ser cargados en el
sistema.
queuesSize:
Indica cual es el número máximo de eventos que puede haber dentro de una
cola del sistema. Es importante no dar un valor reducido pues la infraestructura necesita
un margen para poder funcionar correctamente.
tentacleTimeOut:
Es el tiempo que se esperará antes de desconectar desde la ultima
recepción o envío satisfactorio al Head en el caso del Tail o de los Masters y Tails en el
caso del Head.
maxMasters:
maxTails:
headIp:
Es el número máximo de masters que se pueden conectar.
Es el número máximo de Tails que se pueden conectar.
Cuando funcionamos como Tail, es esta la ip a la que nos intentaremos conectar
cuando se arranque la aplicación.
headBeaconPort:
Operando como Tails, este será el puerto al que se envíe la información
de control.
localBeaconPort:
Puerto por el que se escuchará la información de control.
336
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plugins SYSTEM "oaconf.dtd">
<plugins>
1
<plugin>
2
<loadOnBoot value="yes" />
3
<name value="CmdOut" />
4
<precedence value="1" />
5
<absPath value="src/oplugins/cmdout/cmdout.so"/>
6
<subscriptionList>
7
<EID value="5"/>
8
<EID value="0"/></subscriptionList>
9
<path2cong value=""/>
10
<enabledOnBoot value="yes"/>
</plugin>
</plugins>
Cuadro 3.12: Fichero oaconf.xml del head y del tail
localTCPPort:
Puerto por el que se esperarán conexiones entrantes provenientes del Head
si funcionamos como Tail o de Masters si funcionamos como Head.
oaconf.xml
loadOnBoot:
plugin:
Especica si el plugin se cargará en memoria al inicio del programa.
Los datos de carga de cada plugin vienen indicados dentro de esta etiqueta, por
lo que en caso de querer añadir nuevos plugins bastará con repetir el bloque <plugin>,
(como en el ejemplo), entre la etiqueta <plugins>.
name:
Es el nombre con el que aparecerá el plugin en los listados una vez se esté ejecutando
la aplicación.
precedence:
Indica cual será el orden en el que se llamará a el plugin pero existen unos
límites en el valor de la precedencia para asegurar que ciertos plugins del sistema se ejecutan
los primeros y los últimos. Puede haber plugins con la misma precedencia.
La máxima precedencia es 1, y la mínima 1000.
absPath:
Ruta absoluta hasta el chero compilado como librería.
337
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE weboscong SYSTEM "weboscong.dtd">
<weboscong>
1
<ip>127.0.0.1</ip>
2
<index_page>index.pl</index_page>
3
<htdocs_dir>src/webos/htdocs/</htdocs_dir>
4
<max_requests>100 </max_requests>
5
<port>81 </port>
6
<user>www-data </user>
7
<perl_executable>/usr/bin/perl</perl_executable>
8
<logle>src/webos/logs/access.log </logle>
9
<cgi_pattern>.pl </cgi_pattern>
10
<hostname>titania </hostname>
11
<max_age>3</max_age>
</weboscong>
Cuadro 3.13: Fichero webos.xml del Head y del Tail
subsCriptionList:
Es el listado de eventos a los que se desea que se suscriba el plugin
para que se le llame cuando se den. El listado de eventos y su valor lo podemos consultar
en el chero:
EID:
src/includes/eid_table.h.
Indica un evento al que se suscribirá el plugin. Para suscribir el plugin a más de un
evento basta con repetir esta etiqueta cambiando el valor del atributo
path2cong:
valor .
En caso de que el plugin tenga un chero de conguración propio será aquí
donde indiquemos la ruta hasta su chero.
enabledOnBoot:
A pesar de estar cargado, un plugin puede estar deshabilitado por lo
que no se le llamará cuando se de uno de los eventos a los que se ha suscrito.
webos.xml
ip:
En el caso de existir varias interfaces, se le puede indicar al servidor por cual de ellas
queremos que quede a la escucha.
index_page:
En caso de no indicarle en el navegador el chero al que queremos acceder,
buscará el chero que pongamos aquí para mostrar su información.
htdocs_dir:
Es la ruta donde encontrará todos los documentos necesarios para la visua-
lización correcta de las páginas.
338
1
make
8
2
rmmod syshooker
3
insmod syshooker.ko sysCallTable=322395980
Cuadro 3.14: Fichero reload.sh del Syshooker
max_requests:
Para evitar en lo posible una ataque de denegación de servicio, es posible
indicar el número máximo de peticiones que se pueden atender simultáneamente.
port:
Puerto por el que quedará a la escucha el servidor web.
perl_executable:
logle:
Ruta hasta el interprete de perl que deseamos utilizar.
Ruta del chero donde se dejarán los mensajes de log.
cgi_pattern:
Es la extensión que tendrán los cheros que deseamos que sean ejecutados.
hostname:
Es el nombre de nuestra máquina.
max_age:
Para evitar que el servidor web se quede bloqueado debido a la ejecución de
un script que consuma muchos recursos debido a bucles innitos podemos especicar el
tiempo máximo de ejecución que tiene un script.
Ficheros de los Masters
Al igual que el Head y los Tails, los Masters disponen de sus propios cheros de conguración
con los que les indicaremos los datos necesarios para su funcionamiento.
Syshooker
Este Master se compone de dos aplicaciones, un LKM que se encarga de capturar las
syscalls generada por los procesos en ejecución, y un programa cliente que recibe esa información,
la procesa y la transmite al Head.
Existen pues dos cheros que deberemos congurar,
339
reload.sh
y
mastercong.xml .
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dfsu_master SYSTEM "mastercong.dtd">
<dfsu_master>
1
<name value="Master1"/>
2
<tentacleTimeOut value="3"/>
3
<headIp value="172.26.0.2"/>
4
<headTCPPort value="4320"/>
</dfsu_master>
Cuadro 3.15: Fichero mastercong.xml del Syshooker
Este primer chero no es más que un script para cargar el módulo que recoge las syscalls
en el sistema operativo de la máquina. El parámetro que se debe modicar se encuentra en la
línea tres, y es el número que aparece después de sysCallTable=. Para obtener dicho número
deberemos ejecutar el comando:
$ cat /boot/System.map |grep sys_call_table
que retornará un valor similar al siguiente:
C0484700 D sys_call_table
Este valor es la dirección de memoria en hexadecimal
donde el kernel ubica la tabla de syscalls, deberemos por tanto convertirla a decimal.
El chero
mastercong.cfg
name:
tiene las líneas de conguración que se explican a continuación:
Es el nombre con el que se identicará al Master.
tentacleTimeOut:
Este valor indica cuanto tiempo pasará antes de desconectarse y volver
a conectarse al Head desde la ultima recepción o el último envío de datos.
headIp: Como su propio nombre indica, aquí se especica la dirección de Red de la máquina
en la que se está ejecutando el Head.
headTCPPort:
Es el campo donde hay que poner el puerto de escucha del Head para que
la conexión sea posible.
Snort Modicado
run.sh .
Este Master dispone de dos cheros de conguración,
dfsumcong.cfg
y
En el primer de ellos especicaremos los datos necesarios para que el Master pueda
encontrar el Head y establecer la conexión:
340
1[SLAVE]
2
IP=127.0.0.1
3
PORT=4320
4
BUFFERSIZE=500
5
NAME=Master2
Cuadro 3.16: Fichero dfsumcon.cfg del Snort Modicado
src/snort -i eth2 -l /tmp/ -c etc/snort.conf -j dfsumcong.cfg -A console
Cuadro 3.17: Fichero run.sh del Snort Modicado
Su funcionamiento es muy simple ya que únicamente hay que editar las lineas 2 y 3 e indicar la
dirección de red y el puerto de la máquina que contiene el Head.
En el segundo chero solamente lo modicaremos para especicar la interfaz por la que se
monitorizará el tráco de red.
Escogiendo la estructura óptima
Es muy importante escoger bien la estructura que mejor se adapte a nuestras necesidades
en pos de obtener el mínimo coste. En caso de no estar seguros sobre cual es la más adecuada,
empezar por una estructura de tres capas con uno o dos Tails es lo más recomendable.
Mediante los indicadores de sobrecarga del sistema visibles en la interfaz web determinaremos
si necesitamos más capacidad de cálculo o no. En caso armativo el procedimiento a seguir
para solucionar el problema será el de ir añadiendo Tails de forma progresiva hasta lograr un
rendimiento adecuado.
Congurando el Master, el Head y el Tail
Una vez escogida la estructura que deseamos implementar en nuestra red, deberemos congurar el Head y los Tails correctamente. A continuación se explicarán con detalle todos los pasos
que se han de llevar a cabo para poner en funcionamiento la estructura de DFSU.
Ejemplo de conexión paso a paso
Al igual que en la hostelería, qué mejor método para explicar cómo llevar a cabo una tarea que
un ejemplo. Es por ello que en los siguientes pasos se creará una estructura completa, compuesta
de los siguientes ingredientes:
Un master de Host
Un master de Red
341
Un Head
Un Tail
Para este ejemplo se han utilizado tres máquinas, siendo cada una de ellas uno de los elementos
de la estructura, (Master, Head y Tail).
Así pues en la primera máquina hemos colocado tanto el Master de Red como el de Host, en
la segunda el Head y en la Tercera el Tail.
342
Editando los cheros de conguración
Como ya aprendimos en la sección de conguración, los primeros cheros que hemos de editar
son slaveconf.xml para el Head y el Tail, dfsumcong.cfg, run.sh para el Master de Snort
modicado y mastercong.xml para el Master de Host.
Lo primero que se debe saber, para poder entender las conguraciones elegidas en los cheros
de ejemplo, son los datos de red que tienen las máquinas que albergan los diferentes elementos:
Conguración de la máquina que contiene los Masters
Dirección de Red:
192.168.0.1
Máscara de Subred:
255.255.255.0
Dirección de Red eth2:
192.27.0.15
Máscara de Subred eth2:
255.255.255.0
Conguración máquina que contiene el Head
Direccion de Red:
192.168.0.2
Máscara de Subred:
255.255.255.0
Conguración de la máquina que contiene los Tails
Dirección de Red:
192.168.0.3
Máscara de Subred:
255.255.255.0
En caso de existir alguna duda sobre los datos que se han congurado en los cheros, es
recomendable volver a la sección
Comprendiendo los cheros de conguración.
Los campos más importantes que han sido modicados para poder realizar la conexión se
encuentran en negrita y los campos que no tienen sentido según se funcione como Head o como
Tail carecen de contenido.
Conguración del Master
1. Fichero dfsumcong.cfg:
Los parámetros más importantes que debemos indicar son la dirección de red y el puerto
de la máquina en la que se encuentra escuchando el Head.
2. Fichero run.sh:
En este chero hemos congurado el Snort modicado de manera que capture el tráco
que llega por la interfaz 2. La conexión hacia el Head se está lanzando por la interfaz de
red eth1.
343
[SLAVE]
IP=127.0.0.1
PORT=4320
BUFFERSIZE=500
NAME=Master2
Cuadro 3.18: Ejemplo de conguración del chero dfsumcong.cfg del Snort Modicado
src/snort -i eth2 -l /tmp/ -c etc/snort.conf -j dfsumcong.cfg -A console
Cuadro 3.19: Ejemplo de conguración del chero run.sh en el Snort Modicado
Conguración del chero mastercong.xml
como
Master1
Vemos que este master se identicará
y se intentará conectar a la ip y puertos que hemos congurado en la máquina
donde se está ejecutando el Head.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dfsu_master SYSTEM "mastercong.dtd">
<dfsu_master>
<name value="Master1"/>
<tentacleTimeOut value="3"/>
<headIp value="192.168.0.2"/>
<headTCPPort value="4320"/>
</dfsu_master>
Cuadro 3.20: Ejemplo de conguración del chero mastercong.xml en el Syshooker
Conguración del chero slaveconf.xml del Head
En el Head, lo más importante a denir en su chero de conguración es el primer campo, donde
se especica que funcionará como tal, y los campos de los puertos. A pesar de que en el ejemplo
los puertos BeaconPort y TCPPort son iguales, no es obligatorio que sea de ésta manera.
Conguración del chero slaveconf.xml del Tail
Además del primer campo que
dene su funcionamiento como Tail, es muy importante el campo del nombre y los campos de
conexión. Existe una restricción en los nombres que se asignan a los Tails y por el cual el Head
puede prohibir la conexión: El Head no dejará conectarse a un Tail si ya existe una conexión con
otro que tenga el mismo nombre congurado o si por nombre lleva la palabra Head.
En este punto ya tenemos correctamente congurados todos los elementos del sistema para
que la conexión sea posible. Los cheros de conguración de los plugins aún no los hemos con-
344
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dfsu_slave SYSTEM "slaveconf.dtd">
<dfsu_slave>
<workAsHead value="yes"/>
<name value=""/>
<verbose value="no"/>
<debug value="no"/>
<logPath value="logs/"/>
<webosPath2Cong value="src/webos/etc/webos.xml"/>
<oaPath2Cong value="etc/oaconf.xml"/>
<queuesSize value="500"/>
<tentacleTimeOut value="15"/>
<maxMasters value="15"/>
<maxTails value="15"/>
<headIp value=""/>
<headBeaconPort value=""/>
<localBeaconPort value="4320"/>
<localTCPPort value="4320"/>
</dfsu_slave>
Cuadro 3.21: Ejemplo de conguración del archivo slaveconf.xml en el Head
345
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dfsu_slave SYSTEM "slaveconf.dtd">
<dfsu_slave>
<workAsHead value="no"/>
<name value="Tail_1"/>
<verbose value="no"/>
<debug value="no"/>
<logPath value="logs/"/>
<webosPath2Cong value=""/>
<oaPath2Cong value="etc/oaconf.xml"/>
<queuesSize value="500"/>
<tentacleTimeOut value="15"/>
<maxMasters value="15"/>
<maxTails value="15"/>
<headIp value="192.168.0.2"/>
<headBeaconPort value="4320"/>
<localBeaconPort value="8000"/>
<localTCPPort value="8000"/>
</dfsu_slave>
Cuadro 3.22: Ejemplo de conguración del chero slaveconf.xml en el Tail
346
gurado pues lo primero es asegurarnos de que la estructura está operativa. Más adelante veremos
como congurar y detectar un ataque de manera detallada.
Lanzando las aplicaciones
Lanzando el Head
La
Pasemos ahora a lanzar las aplicaciones una a una:
Figura
3.65 muestra el resultado que deberemos obtener una vez que
hayamos lanzado las aplicaciones en el siguiente orden:
1. Lanzamos el Head: Para esto utilizamos el comando $ sh run.sh en la carpeta Head/ .
2. Lanzamos los Masters: En la máquina donde hemos colocado los Masters ejecutamos
sin importar cual de ellos se lance primero los siguientes comandos:
a ) snortMaster/: $ sh run.sh
b ) syshooker/: $ sh run.sh
3. Lanzamos el Tail: En la máquina donde tenemos el Tail, en el directorio raiz
ejecutamos el comando
$ sh run.sh.
Figura 3.65: Head con un tail y dos masters conectados
347
Head/
Figura 3.66: Plugins cargados en el Head
Figura 3.67: Plugins cargados en el Tail
Comprobando que todo funciona bien
Lo primero que comprobaremos es que la carga de
los plugins cmdOut y TrivialExpert ha sido realizada en el Head y en el Tail respectivamente.
Para ésto ejecutaremos el comando
ls -all
en las dos aplicaciones:
Aquí vemos como efectivamente en el Head el plugin cargado es el cmdOut y cómo el TrivialExpert se encuentra descargado.
No debe confundirnos el hecho de que el valor de
ENABLED
sea
YES
pues sólo se tiene
en cuenta una vez que el plugin se encuentra cargado.
En el Tail deberá aparecernos los contrario a lo que hemos visto en la imagen Figura 3.66:
Plugins cargados en el Head, encontrándose cargado el TrivialExpert y el cmdOut descargado.
348
Figura 3.68: Visualización de las alertas en el Head
Si ésto es correcto, entonces en la terminal de consola donde hemos ejecutado el Head deberían
estar apareciendo alertas como las de la siguiente gura:
Resumiendo
Hasta ahora hemos congurado y conectado dos Masters, un Head, un Tail
y se han generado alertas por los eventos recibidos desde los Masters.
Por si queda alguna duda se dará ahora una breve explicación de lo que ha pasado en el
sistema, empezando por recordar algunos aspectos del funcionamiento de cada elemento de la
estructura:
1. En el momento en el que los Masters se conectan al Head, éstos empiezan a enviarle datos
que están capturando.
2. Por defecto en el chero oaconf.xml del Head viene activo el plugin cmdOut que se encarga
de mostrar las alertas que llegan desde los Tails.
3. Por otra parte en el Tail el plugin TrivialExpert, que está activo de forma predeterminada,
trata a todo evento recibido como si fuese maligno.
Por lo tanto, en el momento en el que hemos conectado los Tails y los Masters al Head se han
empezado a generar alertas.
349
3.3.10. DFSU descripción de las interfaces
Habitualmente se utilizan dos tipos de interfaces, las grácas y los interpretes de comando.
Por lo general las interfaces grácas son más intuitivas y visuales pero carecen de la potencia
que proporciona un interprete de comandos.
Para no perder ninguna de las ventajas que cada interfaz aporta decidimos implementar en
DFSU los dos tipos. La interfaz gráca, que es opcional, es proporcionada por el servidor web
WebOs y el interprete de comandos se ejecuta de forma nativa cuando se arranca el sistema.
En este capítulo se explicarán las posibilidades que nos brindan éstas interfaces y como llevar
a cabo las tareas de mantenimiento y supervisión con su ayuda.
Interfaz Web: Servidor web integrado WebOs
El servidor WebOs solamente es posible activarla cuando se funciona en modo Head ya que
es aquí donde se concentra toda la información mostrada.
Presenta el siguiente aspecto:
Figura 3.69: Pantalla principal servidor WebOs
En la imagen Figura 1: Pantalla principal servidor WebOs se nos muestran de forma rápida
los elementos conectados al Head en cada momento (Masters y Tails) junto con su nombre, de
modo que podamos diferenciarlos.
En los grácos inferiores se muestra la carga que están soportando el Head y los Tails que
tiene conectado en la parte inferior mediante un gráco que varía en tamaño y color.
350
En el menú de la izquierda se nos ofrece la posibilidad de navegar por las opciones que
incluyen tanto la documentación y manual de usuario como la información referente al proyecto.
351
Existe la posibilidad de hacer click sobre las burbujas del Head y los Tails con lo que se nos
mostrara la siguiente información:
Figura 3.70: Graco del sysload
Desde esta pantalla se visualiza toda la información necesaria para poder administrar remotamente el Tail. Además de ver los plugins que aparecen en el chero oaconf.xml del Tail en
cuestión, se sabrá el estado en el que se encuentran con la posibilidad de modicarlo activando/desactivando, cargando y descargando.
Las estadísticas nos muestran el número y tipo de los paquetes recibidos y procesados por
el Tail, además de la carga del sistema. En el caso de que un Tail esté sobrecargado siempre se
puede desactivar el plugin más pesado hasta que se solucione el problema.
Figura 3.71: Pantalla de información gráca sobre el Tail
Por último se pueden modicar algunos de los parámetros del chero slaveconf.xml remota-
352
mente para que la próxima vez que se inicie el Tail se ejecute con la nueva conguración.
Interfaz de comandos: La consola
La consola se encuentra activa tanto en el Head como en los Tails y desde ella podemos ejecutar todos los comandos implementados en la interfaz gráca además de otros que se detallarán
ahora.
Cuando se arranca la aplicación se nos muestra la pantalla de bienvenida
de inicio de la consola
Figura 4: Pantalla
y se nos da la posibilidad de empezar a ejecutar comandos.
En este ejemplo se nos informa de que se han arrancado los plugins TrivialExpert y cmdOut,
además de que estamos funcionando como Head y que el servidor Web esta funcionando en el
puerto 81.
Figura 3.72: Pantalla de inicio de la consola
Como toda consola, disponemos del comando
help
que nos ayudará en la tarea de admi-
nistración informándonos de cuales son nuestras posibilidades Figura 1: Panta de ayuda de la
consola.
Comandos sobre plugins:
Al igual que en la interfaz web donde podemos ejecutar coman-
dos para administrar los plugins locales y remotos, según donde hiciéramos click, sobre el Head
(local) o sobre algún Tail (remoto), disponemos de los comandos
sable
para administración local y
rload , runload , renable
y
load , unload , enable y dirdisable
para control remoto.
La sintaxis es común para cada uno de los grupos, local o remoto, siendo la siguiente :
1. Locales:
<comando><nombre-plugin>
353
2. Remotos:
<comando><nombre-Tail><nombre-plugin>
Para conocer los plugins que hay en el sistema deberemos ejecutar el comando
ls -all.
Además de éstos, disponemos de la posibilidad de enviar órdenes directamente a los plugins
utilizando el comando
Su sintaxis es:
cmd .
cmd <nombre-plugin><orden-para-el-plugin>
/newpage
Comando para el servidor WebOs:
Existe un comando dedicado a la gestión del servidor web:
Figura 3.73: Comandos de consola para webOs
webos <opción>:
• status: Muestra el estado en el que se encuentra el servidor , en ejecución o detenido.
• start: Inicia la ejecución del servidor web.
• stop: Detiene la ejecución del servidor web.
• restart: Detiene el servidor web si está en ejecución y vuelve a iniciarlo.
Comandos sobre Tails:
comando
ls -tails ,
Podemos controlar que Tails tenemos conectados mediante el
pudiendo además prohibir la conexión y listar quienes la tienen prohibida,
expulsar y readmitir mediante los comandos ban , ls -banned , kick y unban respectivamente.
El comando
kickban
ejecuta esas dos acciones consecutivamente.
354
Figura 3.74: Pantalla de ayuda de la consola
Como se muestra en la imagen, la sintaxis es común para las órdenes ban , kick , unban
y kickban : <comando><nombre-Tail>
Siempre que ejecutemos el comando
nombre
Head ,
ls -banned
veremos por lo menos una entrada con el
pues como ya se ha comentado no se permite que ningún Tail se conecte con ese
nombre. No es posible ejecutar con éxito el comando
unban
sobre ese nombre.
Figura 3.75: Comandos de consola ls
Comandos de información general:
ls <opción>:
Lista información útil que varía según el parámetro introducido
• ls -sall: Muestra el listado de plugins de sistema.
355
• ls -uall: Muestra el listado de plugins de utilidad.
• ls -oall: Muestra el listado de plugins de salida.
• ls -eall: Muestra el listado de plugins expertos.
• ls -all: Muestra un listado con todos los plugins que conoce el sistema.
• ls -masters: Muestra un listado con los Master conectados.
• ls -tails: Muestra un listado con los Tails conectados.
• ls -banned: Muestra un listado con los Tails que han sido baneados del sistema.
set [verbose|debug] [on|o ]:
Con este comando podemos activar y desactivar el modo
verbose y debug que nos mostrarán más información de lo que ocurre por la consola.
mode:
Muestra la información con la que está congurada el sistema Figura 1: Pantalla
de consola comando Mode. Puede variar de la que contiene el chero
slaveconf.xml
si se
ha modicado alguno de los parámetros mediante comandos.
sys <comando shell>:
Da la posibilidad de ejecutar un comando de una terminal como
sobre la que se ha lanzado la propia aplicación.
exit, quit:
Finaliza la ejecución de la aplicación. También es posible nalizar mediante la
combinación de teclas ctrl+c.
3.4. Análisis
Una vez determinada la relación de parámetros de detección que deberán formar parte del
análisis, y desarrollada la solución de recogida de información pertinente, dichos parámetros están
listos para ser introducidos en la fase de Análisis.
Como se enuncia en el capítulo 1, el objetivo primordial del presente estudio consiste en el
desarrollo de un método de análisis basado en Detección de Anomalías que reporte su conocimiento a motores de Detección de Firmas, de modo que el tiempo de procesado y comprobación
requerido sea el más óptimo posible para los terminales en los que se implante el sistema. A este
respecto, y dado que las Redes Bayesianas han sido utilizadas en proyectos semejantes para Sistemas de Detección de Intrusiones basados en Host[95], se va a plantear y desarrollar un modelo
que englobe, sustituya y mejore a las técnicas existentes [399, 305, 13, 215, 47, 207, 331, 244].
3.4.1. Modelo General Operativo
Como se desprende del enunciado de los objetivos operacionales descritos en el capítulo 1,
la consecución del n último de la presente memoria pasa, en primer lugar, por la obtención de
un Modelo de Representación de Conocimiento. Éste, tomando en consideración el conjunto de
parámetros de detección enumerados en el apartados anteriores, hará uso de toda la potencia de
356
modelado e inferencia de las Redes Bayesianas. El objetivo principal es determinar la probabilidad
con la que pertenece al modelo de comportamiento del sistema operativo en estudio.
Para obtener la valoración nal del comportamiento correcto o anómalo de una determinada
aplicación se va a hacer uso de las técnicas de Redes Bayesianas Dinámicas para evaluación de
cadenas o secuencias de llamadas al sistema junto con un análisis ponderado de los parámetros
asociados a cada llamada en particular haciendo uso del algoritmo Bayesian Merging [308].
El aprendizaje de estructura de la Red Bayesiana Dinámica como tal no es necesario, dado
que está claramente jado en los papers revisados durante toda la memoria. Al n y al cabo el
objetivo en esta parte es validar que la secuencia de syscalls, que se están produciendo, pertenece
a un modelo aprendido de comportamiento correcto o no. Posteriormente ese experto, entendido
como la parte que se encarga de dotar a la infraestructura de Inteligencia Articial, generará una
regla procesable por la clase Cerebelum. Finalmente antes de acometerse una nueva investigación
mediante Inteligencia Articial en la secuencia de llamadas, si se descubre una coincidencia dentro
de las reglas inferidas y aprendidas por la infraestructura de una situación marcada anteriormente
como anómala, será indicado directamente. De esta forma se consigue aglutinar la rapidez de los
Sistemas de Detección de Intrusiones basados en rmas junto con la efectividad demostrada por
los Sistemas de Detección de Anomalías.
El administrador de la infraestructura podrá estudiar las reglas generadas por el motor de
Inteligencia Articial y cambiarlas o ampliarlas acorde a su conocimiento experto, pudiendo incluso obligar a la parte de IA a aprender esa regla como válida dentro del modelo de conocimiento
que tiene para una determinada aplicación.
3.4.2. Obtención de la Muestra Evidencial.
Se han desarrollado una serie de entidades software que se ocupan de la recogida en el
Sistema Operativo correspondiente de las llamadas al Sistema. Esta recogida se produce en la
forma comentada anteriormente y esos datos son enviados a la infraestructura DFSU desarrollada
para esta solución que se plantea. Una vez los paquetes llegan a la infraestructura son redirigidos
internamente hacia las entidades denominadas tails. Los Tails serán los encargados de trabajar
con el ujo de información entrante que llega desde los Masters. En ellos es donde se despliegan
los expertos basados en IA o en reglas que se encargan de comprobar los ujos de información
recibidos.
La infraestructura como se ha comentado tiene diferentes modos de funcionamiento, entre
ellos cabe destacar para la entrega de los mismos a los expertos los siguientes:
Modo BroadCast: Toda la información que entre en el sistema se distribuye por todos los
Tails.
Imaginando que se tiene un conjunto de terminales móviles de diferentes sistemas operativos,
la información que se obtenga será pasada en bloque a los diferentes Tails. Dentro de ellos
357
la información se repartirá acorde al tipo de evento al que estén suscritos estos expertos. El
comportamiento de la infraestructura en este caso sirve para poder tener diferentes expertos
repartidos por los tails que se encuentren disponibles, pero no es el más óptimo para la resolución
de la problemática planteada. Hay modos de funcionamiento mucho más precisos para la forma
de recogida de la información que se requiere.
Se indica que este modo no es el más óptimo dado que puede darse el caso de que existan
expertos suscritos a los Eventos de Host a los que llegaría la misma información y o bien se
encargan ellos de discernirlos para generar los diferentes modelos de conocimiento mediante
Redes Bayesianas Dinámicas o bien se procesarían los eventos recibidos varias veces.
Modo Usuario, modo origen, modo proceso y máquina.
Estos modos son los más adecuados a la funcionalidad deseada, dado que la infraestructura ha
sido diseñada para balancear carga y distribuir el procesado de los eventos que se introduzcan
al sistema. El bloque de información entra en el sistema y se va a distribuir acorde al modo de
funcionamiento en el que se encuentre. De esta forma se va a conseguir que cada Tail pueda
encargarse de lo acaecido en una máquina determinada, con un usuario concreto o de un origen
absoluto (denotar que la infraestructura no tiene intención de quedarse exclusivamente en la
Detección de Intrusiones basada en Host, si no que puede aceptar información de Red a la vez).
Esta forma de funcionamiento ha permitido el desarrollo e integración con la infraestructura
desarrollada en años anteriores por este equipo de investigación ESIDE-DEPIAN[42] encargada
del tratamiento de los eventos acaecidos en la red. El funcionar de esta manera permitirá la
correlación de eventos mediante clasicaciones bayesianas entre Host y Red como se detallará el
Capítulo 4 de Conclusiones y Retos Futuros.
Continuando con el proyecto que ilustra esta memoria, el funcionamiento en esta serie de
modos hace posible que un sistema de análisis no se sobrecargue con la información de varios
Host's. Los eventos llegarán acorde a su origen, al usuario que haya efectuado los mismos (o sus
aplicaciones) incluso de diferentes sistemas operativos, o desde una máquina en concreto. Una
vez obtenido el ujo de la forma deseada se discriminará basándose en la aplicación que haya
realizado una u otra llamada, de forma que los expertos inteligentes puedan aprender de la forma
correcta el modelo de comportamiento de la misma.
Las evidencias de host mantienen en su interior información sobre los siguientes campos:
Listing 3.23: Denición de la clase hEvent
2
#d e f i n e
TOH_LINUX
0
#d e f i n e
TOH_WINDOWS
1
#d e f i n e
TOH_WINMOV
2
#d e f i n e
TOH_SYMBIAN
3
typedef s t r u c t
MHEventHeader_
{
358
uint8_t toh ;
7
uint32_t numArgs ;
time_t etStamp ;
}MHEventHeader ;
12
typedef c l a s s
hEvent
{
MHEventHeader mheh ;
17
bool
error ;
char ∗
data ;
int
dataSize ;
Argument ∗ a r g s ;
public :
22
27
void
i n i t ( char ∗ data , i n t dataSize_ ) ;
bool
isError () ;
char ∗
getData ( ) ;
int
getDataSize () ;
void
setDataNull () ;
int
getNumArgumens ( ) ;
Argument ∗
getArgument ( i n t numArg ) ;
uint8_t getTypeOfHost ( ) ;
time_t getArrivalTimeStamp ( ) ;
char ∗
marshall ( int ∗ t S i z e ) ;
hEvent ( char ∗ data , i n t dataSize_ ) ;
32
~hEvent ( ) ;
};
En la denición anterior se observa la información a la que van a tener acceso los diferentes
plugins o expertos dentro de la infraestructura. Básicamente se divide por el tipo de sistema
operativo sobre el que está puesto el interceptor de las llamadas (syscalls):
Linux
Windows
Windows Mobile
Symbian
359
Posteriormente se dene el número de argumentos. Esta parte es importante para poder dimensionar el experto basado en IA (Redes Bayesianas Dinámicas junto con Bayesian Merging) y
empezar a crear el posible modelo que va a dar cabida a este tipo de información. Por cada
argumento se deberá crear un objeto Bayesian Merging que se encargará del modelado de cada
parámetro que acompañe a la llamada al sistema. Finalmente se tiene el timestamp, el momento
temporal de la captura, para poder relacionar en la línea de tiempos cuándo se han producido
las diferentes llamadas al sistema.
Fuera de la parte de cabecera que ayuda y simplica a la creación y mantenimiento de los
modelos se tiene el resto de parámetros de la clase Evento de Host, como pueden ser el valor de
retorno, el valor del error producido y la sucesión de argumentos propiamente dicha.
3.4.3. Aprendizaje e Inferencia de Expertos Mendizale
Una vez obtenidos los datos se procederá a realizar el estudio que permita adecuarse de la
manera más plausible posible a los requerimientos especicados. La primera fase es el aprendizaje
de los argumentos y su escalado para introducirse dentro del Modelo de Comportamiento general.
Se va a partir de un ejemplo de captura de un terminal Windows Mobile 2005 y en base al
mismo se va a desarrollar la forma en la que se manipula la información en el presente proyecto.
En este ejemplo en cuestión se han interceptado las siguientes librerías:
(1) API0119, número de veces llamada en la sesión: 890, número de argumentos: 11
(2) API0148, número de veces llamada en la sesión: 21, número de argumentos: 11
(3) API0177, número de veces llamada en la sesión: 0
(4) API079, número de veces llamada en la sesión: 7391, número de argumentos: 11
(5) API08, número de veces llamada en la sesión: 33, número de argumentos: 11
(6) API082, número de veces llamada en la sesión: 0
(7) API09, número de veces llamada en la sesión: 3, número de argumentos: 11
(8) API095, número de veces llamada en la sesión: 13, número de argumentos: 11
(9) API096, número de veces llamada en la sesión: 18, número de argumentos: 11
(10) API097, número de veces llamada en la sesión: 64, número de argumentos: 11
(11) API098, número de veces llamada en la sesión: 426, número de argumentos: 11
(12) API20116, número de veces llamada en la sesión: 0
(13) API20117, número de veces llamada en la sesión: 0
360
(14) API202, número de veces llamada en la sesión: 0
(15) API203, número de veces llamada en la sesión: 0
(16) API204, número de veces llamada en la sesión: 338, número de argumentos: 11
(17) API205, número de veces llamada en la sesión: 0
(18) API2063, número de veces llamada en la sesión: 0
(19) API209, número de veces llamada en la sesión: 0
El procesos implicados tienen los siguientes PID (Identicativo de Proceso)168 :
2d82b0aa: 1(1), 2(1), 10(7)
2dfe8262: 4(6920), 16(338)
4da96fd6: 4(6), 11(29)
4dc1d0f2: 1(7), 2(3), 4(225), 9(4)
6d696f6a: 1(114), 2(3), 4(2), 5(7), 8(2), 10(17), 11(94)
6da3cfb6: 1(8), 2(1), 10(7)
8dd76a22: 1(142), 2(4), 4(197), 5(5), 8(2), 9(14), 10(9), 11(121)
8dd76eea: 4(1)
ad6ba0da: 1(39), 2(2), 5(5), 8(2), 10(9), 11(21)
adde1b92: 11(11)
cdb96c92: 1(129), 2(4), 5(8), 8(2), 10(4), 11(118)
cdc13e46: 1(65), 2(3), 4(17), 5(8), 7(3), 8(5), 10(11), 11(32)
dfaa4ca: 4(23)
La primera escisión en el estudio es la unidad máquina:proceso. Esta unidad es para identicar
de forma única el modelo correspondiente tanto para aprendizaje como para cálculos posteriores
de validez. Esta unidad se reeja mediante la ip del host correspondiente y el PID del proceso a
modelar. Tomando por ejemplo el primer PID (Identicador de Proceso) que se ha puesto en la
lista y extrayendo de la captura un trozo de la misma tenemos la siguiente evolución:
168
Se indica el número interno de las librerías a las que llaman y entre paréntesis el número de veces que ha
sucedido en la sesión
361
PID2d82b0aaAPI10(210cc:,0,2,f000fdb0,c894,f000fe3c,0,1,21904,8dd7c6b0,1)
PID2d82b0aaAPI10(210b0:,0,2,f000fdb0,1eb8668,f000fe3c,0,1,2191c,8dd7c6b0,1)
PID2d82b0aaAPI10(2f91174:,0,2,f000fdb0,8dd7cea4,f000fe3c,0,1,2f94dd0,c894,f000fc)
PID2d82b0aaAPI10(2002fc90:,0,2,f000fdb0,0,f000fe3c,0,1,2fa265c,730074,720068)
PID2d82b0aaAPI10(2fc10b0:,0,2,f000fdb0,8dd61744,1eb6610,0,1,2fc3028,c894,f000fe3c)
PID2d82b0aaAPI10(2df101c:,0,2,f000fdb0,8da7c440,1e9d580,0,1,2df3634,c894,f000fe3c)
PID2d82b0aaAPI10(2002fc8c:,0,2,f000fdb0,0,1e9d580,0,1,2fa265c,720062,77006f)
PID2d82b0aaAPI1(2df16a0:,f000e0,2df16a0,2df17f8,2df17f8,1e9d6f0,1e9d71c,2df5608,1e9d71c,0,10)
PID2d82b0aaAPI2(8dd33cbc:,f000dc,8dd33cbc,0,1e9d604,0,0,2df6468,8da7c440,f000fe3c,2df3660)
Cuadro 3.23: Listado de llamadas al sistema por el PID 2d82b0aa
Recordando, dentro del listado anterior se tiene primero el identicativo PID, la librería o
función o llamada al sistema que realiza, los parámetros entre paréntesis y para nalizar se tiene
el valor de retorno (un entero de 32 bits) y el valor del error indicado por el sistema (si es que
se ha producido). Como se ha indicado anteriormente todas las llamadas llevan capturados 11
parámetros, no tiene por qué ser así en todos los sistemas operativos.
Aprendizaje y semejanza de parámetros de las llamadas al sistema.
Lo primero que debe realizarse es establecer dentro del modelo de parámetros es establecer
el orden correcto y la posición adecuada de los parámetros, así como traducir si son punteros a
cadenas de texto o arrays, para poder observar los valores convenientemente.
El orden de parámetros se ja dinámicamente dado que en la creación conforme se van leyendo
los parámetros se añaden al modelo general los modelos Bayesian Mergin que contendrán la
información correspondiente para ese parámetro en concreto. Si se plantea una solución como
por ejemplo en sistemas operativos GNU/Linux para realizar una escritura por pantalla, se le
debe pasar a la llamada que se encarga del mismo un descriptor (puntero único que hace referencia
a un chero del disco duro), el puntero a la cadena que se va a escribir y el tamaño de la cadena.
Así mismo para este caso si tenemos el siguiente código en ensamblador (en nomenclatura AT&T
para el ensamblador de GNU/Linux, GNU/Assembler).
Listing 3.24: Ejemplo para obtener el Identicativo de la CPU en ensamblador sobre sistemas
GNU/Linux en nomenclatura AT&T
. s e c t i o n .data
output :
. a s c i i " E l ID d e l v e n d e d o r e s ' x x x x x x x x x x x x ' \ n "
5
.section .text
. g l o b l _start
_start :
362
nop
10
movl $0 , %eax
cpuid
movl $output , %edi
movl %ebx , 23( % edi )
movl %edx , 27( % edi )
15
movl %ecx , 31( % edi )
movl $4 , %eax
movl $1 , %ebx
movl $output , %ecx
20
movl $37 , %edx
int
$0x80
movl $1 , %eax
movl $0 , %ebx
25
int
$0x80
En el código de la gura superior se escribe por pantalla el modelo de la CPU que se tiene,
haciendo uso de la instrucción de los procesadores compatibles IA-32: cpuid. Se tomarán los
valores que devuelva esta llamada y se introducirán dentro de un buer de texto creado a tal
efecto. Finalmente llega la parte que realmente interesaba mostrar, en la que se van introduciendo
los valores para realizar la llamada al sistema de escritura. Se introduce en el registro EAX el
valor de la llamada que se va a realizar, en este caso el valor entero de 32 bits 4. Igualmente se
introduce en el registro EBX el valor del descriptor de chero donde se va a realizar la escritura,
para esta ocasión el valor es 1 que indica que será escrito por la pantalla de usuario. Los dos
últimos valores, si bien también indican literales de 32 bits, uno de ellos lleva asociada una cadena
de texto dado que es un puntero a la misma. Estos valores son los que se tendrán que interceptar
de forma correcta y así mismo representar en los modelos que corresponda:
Número de Parámetro
Valor de Dicho Parámetro
Parámetro 2
Parámetro 3
Parámetro 4
1
El ID del vendedor es 'GenuineIntel'\n
37
Cuadro 3.24: Listado de parámetros para realizar una llamada write en GNU/Linux
Acorde a la tabla anterior el modelo que se iría generando es el siguiente:
363
Figura 3.76: Aprendizaje de Parámetros de las llamadas al Sistema
Como se puede ver en la gura anterior, los parámetros obligan al Experto Mendizale a
crear nuevos objetivos Bayesian Merging conforme se van leyendo nuevos. El parámetro 1 crea el
Objeto Modelo Bayesian Merging 1, el segundo el segundo modelo y así sucesivamente. De esta
forma se tienen modelados los parámetro de esa syscall y de ese proceso que se esta analizando.
Estos modelos se realizan por cada llamada al sistema que se produzca, de forma que todas
las llamadas tendrán una representación para sus parámetros. Conforme vayan llegando nuevos
parámetros para esa syscall y ese proceso seguirán el método de funcionamiento de las técnicas
Bayesian Merging desarrolladas por este equipo en el proyecto ESIDE-DEPIAN[42]. Esta técnica
innovadora en su momento para el análisis de los protocolos basados en texto se aplica de forma
pionera también en estos Sistemas de Inteligencia Articial, de forma que con los parámetros se
pueda precisar según la posición que ocupen (modelo de parámetro 1, modelo de parámetro 2...)
si realmente pertenecen al modelo o no.
Aparte se ha introducido una modicación importante, se parte siempre de un estado inicial
y se cierra siempre en una posición nal, de forma que se pueda controlar más especícamente
la progresión que puede soportar el parámetro correspondiente.
Como se puede ver un parámetro queda cuanticado probabilísticamente como Cadena de
Markov Oculta (HMM) indicando la probabilidad con la que se pasa de uno de sus caracteres (si
es un buer) al siguiente y se actualiza esta información con el modo de aprendizaje activo. Los
modelos autoaprenden cuando se le indica actualizando las tablas de probabilidades iniciales así
como las tablas de transición entre estados. Así mismo el cómputo de semejanza global para los
parámetros queda de la siguiente forma:
Likelihood(param1) = p(Estado1 → Estado2) · p(Emision_Simbolo1) · p(Estado2 →
Estado3)...
Y siguiendo en la misma línea, la probabilidad de semejanza y de ajuste de los parámetros
de esa llamada al sistema en concreto sería la siguiente.
Likelihood_T OT AL = Likelihood(param1) · Likelihood(param2) · Likelihood(param3)...
Hasta este punto se tiene una gramática que modeliza convenientemente las llamadas al
364
sistema, ésta permite que se sepa de antemano si hay alguna anomalía a nivel paramétrico en
las secuencias de syscalls.
Generalmente los sistemas de detección de Intrusiones no hacen uso de los parámetros pero
resultan muy signicativos en el estudio efectuado de los posibles ataques, sobre todo para
impedir sucesos como los detectados y creados con los ataques Mimicry.
El veredicto completo de este subsistema se integrará en el apartado completo del Modelo
Mendizale en el siguiente apartado.
Aprendizaje de secuencia de syscalls.
Muchos autores intentan jar una ventana para cada proceso en estudio y con ello poder
reejar una anomalía en la secuencia de syscalls que se van produciendo. Esta técnica ha tratado
siempre de ser modicada, mejorada y reestimada desde el documento que trató por primera vez
este secuenciamiento[134].
A este respecto en este documento se recurre a otra técnica: Las Redes Bayesianas Dinámicas.
No va a ser necesario estimar la ventana correspondiente para deslizarse sobre las secuencias de
llamadas al sistema como se ha realizado tradicionalmente. Tomando el ejemplo anterior de un
determinado proceso, se tenía la siguiente información del mismo:
PID2d82b0aaAPI10(210cc:,0,2,f000fdb0,c894,f000fe3c,0,1,21904,8dd7c6b0,1)
PID2d82b0aaAPI10(210b0:,0,2,f000fdb0,1eb8668,f000fe3c,0,1,2191c,8dd7c6b0,1)
PID2d82b0aaAPI10(2f91174:,0,2,f000fdb0,8dd7cea4,f000fe3c,0,1,2f94dd0,c894,f000fc)
PID2d82b0aaAPI10(2002fc90:,0,2,f000fdb0,0,f000fe3c,0,1,2fa265c,730074,720068)
PID2d82b0aaAPI10(2fc10b0:,0,2,f000fdb0,8dd61744,1eb6610,0,1,2fc3028,c894,f000fe3c)
PID2d82b0aaAPI10(2df101c:,0,2,f000fdb0,8da7c440,1e9d580,0,1,2df3634,c894,f000fe3c)
PID2d82b0aaAPI10(2002fc8c:,0,2,f000fdb0,0,1e9d580,0,1,2fa265c,720062,77006f)
PID2d82b0aaAPI1(2df16a0:,f000e0,2df16a0,2df17f8,2df17f8,1e9d6f0,1e9d71c,2df5608,1e9d71c,0,10)
PID2d82b0aaAPI2(8dd33cbc:,f000dc,8dd33cbc,0,1e9d604,0,0,2df6468,8da7c440,f000fe3c,2df3660)
Cuadro 3.25: Listado de llamadas al sistema por el PID 2d82b0aa (recordatorio)
Si traducimos la evolución de este proceso de llamadas tendría el siguiente aspecto:
Figura 3.77: Aprendizaje de Parámetros de las llamadas al Sistema
Para poder ilustrar el resto del comportamiento se va a usar una cadena más larga, como
podría ser: 10, 1, 2, 7, 15, 3, 10, 10, 10, 5, 15, 3, 10. Los trabajos tradicionales que se tienen
realizarían su función mediante una ventana deslizante por las mismas teniendo problema de
365
establecer el tamaño de la misma. La gran diferencia del método desarrollado en el presente
documento es que no requiere del conocimiento del número de la ventana deslizante de antemano.
Las evidencias se introducen en el modelo bayesiano dinámico de dos en dos para realizar el
aprendizaje paramétrico de las tablas de probabilidad internas, lo que no implicará más adelante
tener que seguir con una ventana de dimensión dos.
Una vez actualizado el sistema queda congurado de la siguiente forma:
Figura 3.78: Aprendizaje de Parámetros de las llamadas al Sistema
El modelo en modo aprendizaje ha actualizado las tablas de probabilidad internas conforme
a los datos de secuencias que se han ido introduciendo. Estas secuencias se introducen en el
modelo en una ventana deslizante de tamaño 2. Con esta evolución que parece sin memoria
más que del estado anterior como si fuera una cadena de Markov tradicional se consigue que el
366
modelo represente la realidad completamente del proceso en cuestión. La forma que tiene esta
red inicial DBN sigue las leyes de los HMM Autoregresivos, en los que las variables denominadas
Likelihood Parámetro N ayudan signicativamente a establecer a veracidad de resultados del
modelo.
La red DBN presentada se compone de un nodo padre con tantos estados como número de
librerías o de llamadas al sistema que se quiera modelar. Como hijo tiene el resultado de la
operación anterior de semejanza paramétrica de los parámetros que acompañen a esa llamada. Y
para completar la funcionalidad de DBN esto se repite enlazando tantas veces como sea necesario
esta estructura, conectando los padres entre sí y los hijos correspondientemente. Esta forma de
trabajo en DBN's se conoce como Unrollling.
Realizado el aprendizaje y el jado de la estructura que contendrá el modelo debidamente,
el siguiente paso es ajustar el número de etapas que va a tener el modelo a la hora de nalizar
el aprendizaje. Para ello se ha desarrollado una fase en la que se determina este valor, haciendo
uso de algoritmos EM y de la librería que subyace por debajo del sistema: PNL de Intel. Se
comienza con una ventana de dos nodos y se pide que se prediga el posible valor que tendría
acorde al modelo la syscall siguiente. Acorde a la secuencia planteada, se introducirían los valores
de llamada al sistema 10 y 1 observando si el siguiente valor que se ofrece es el 2. Caso de acertar
se desplazaría la ventana sobre los datos de aprendizaje para predecir (método Predict de la
librería de Intel) el siguiente estado, en esta caso se introduce 1 y 2, para ver si es 7. Si con este
tamaño de ventana se consiguen resultados apropiados este modelo sería congurado para un
tamaño de 2. En cambio si se produce un fallo en el diagnostico predictivo de la siguiente etapa,
en vez de introducir solo 2 valores de la secuencia se pasaría a introducir 3 valores y predecir
el 4o . De esta manera se consigue establecer el tamaño necesario para la inferencia de forma
adecuada y de manera automática.
Finalmente cuando se tiene el modelo completamente aprendido y actualizado se procede a
la puesta en ejecución y análisis del mismo, sobre el que se usan las metodologías de cálculo de
Semejanza. Es decir, establecido el modelo se introducen las nuevas evidencias sobre el tamaño
de ventana jado y se le indica al experto que reeje la probabilidad con la que esa secuencia
pertenece al modelo aprendido previamente. Este resultado por debajo de un umbral congurable
por el administrador será el índice sobre el que lanzarán las alertas correspondientes de Detección
de Anomalía.
3.4.4. Proceso de Razonamiento en la Red Naive de Unicación de Conclusiones
Por último, como se describe en el apartado anteriores, una vez obtenido el conjunto de
conclusiones parciales acondicionadas, resultado de cada uno de los diferentes procesos de razonamiento de los Motores Inteligente Mendizale para tratamiento de llamadas al sistema, puede
construirse una evidencia de alto nivel que presentar al motor de razonamiento correspondiente
367
al modelo de Red Naive de unicación de conclusiones parciales.
De este modo, dicho modelo podrá efectuar, en un segundo nivel jerárquico, el mismo ciclo
de inferencia y adaptación de sus homólogos especializados, con el objetivo de obtener una única
conclusión global nal que represente el valor de probabilidad a posteriori de la maldad inherente
a cada una de las evidencias recogidas en el sistema protegido, e introducidas al motor de análisis.
Debe denotarse que actualmente los ataques no solo involucran a una parte en concreto, si no que
generalmente llegan y se reproducen por la red, por lo que el sistema se integra con los expertos
bayesianos que se tenían de proyectos anteriores, con la nalidad de unicar y pre-detectar
los posibles ataques que se introduzcan. Por otro lado, es importante prestar especial atención
al hecho de que, dada la especialización presente en los diferentes modelos de Red Bayesiana
responsables de la representación de los diferentes tipos de parámetros, es posible la aparición de
situaciones en la que un determinado modelo no se encuentre en disposición de inferir conclusión
parcial alguna, por lo que el componente de inferencia del mencionado modelo de Red Naive debe
contemplar dicha posibilidad en su objetivo de obtención de la conclusión global. Asimismo, dicha
cuestión introduce idéntica consideración en el componente de adaptación.
Así, una vez construida la evidencia denitiva, puede procederse a la presentación de la misma al método de propagación de evidencia de Pearl. De esta manera, se obtiene nalmente un
valor continuo que representa la probabilidad de que una determinada evidencia sea maliciosa,
subversiva y anómala. Así, nalmente, dicho valor de probabilidad puede ser utilizado para efectuar la priorización de las noticaciones de alarma que se envían al operador humano encargado
de la administración y supervisión del sistema de detección. No obstante, una vez efectuada
dicha noticación, es necesario que el mencionado valor de probabilidad sea introducido en el
componente de adaptación, encargado de adaptar el conocimiento almacenado en el modelo de
Red Naive a las variaciones de conocimiento introducidas por dicha evidencia, por lo que se
precisa nuevamente de una etapa de acondicionamiento de la conclusión global. Así, en este caso,
la función de acondicionamiento aplicada al presente modelo de Red Bayesiana, se dene como
un valor umbral relativo169 .
De esta manera, los innitos valores que puede adoptar la mencionada probabilidad, una vez
acondicionada, quedan representados mediante los habituales dos posibles valores de normalidad
y legitimidad, o anomalía y subversión. Por su parte, a continuación, el componente de adaptación
no presenta ninguna diferencia con respecto a sus homólogos especializados, por lo que, una
vez inferida la probabilidad a posteriori de una determinada evidencia, puede procederse a la
aplicación de la variante secuencial del método de estimación de máxima verosimilitud utilizado
anteriormente, con el objetivo de adaptar el conocimiento almacenado en el modelo de Red
Bayesiana correspondiente a las variaciones de conocimiento introducidas por dicha evidencia.
169
El modelo de Red Naíve de unicación de conclusiones conlleva un proceso de inferencia de conclusiones
basado en la selección del estado nal más probable de la variable que representa la categoría, en este caso la
conclusión global. Por ello, el resultado nal obtenido por el componente de inferencia no es sino la probabilidad
a posteriori del estado más probable.
368
Una vez efectuada esta operación, el motor de razonamiento queda nuevamente dispuesto para
recibir la siguiente evidencia.
Finalmente el sistema automáticamente entrega las causas en forma de regla al administrador
correspondiente para que si lo desea sea introducida dentro del sistema. De esta forma se tiene
controlado en el propio ujo de la infraestructura si se ha producido, de forma que se realice
una captura temprana basada en aprendizajes anteriores. Esta captura indica al sistema no que
es requerido que vuelva a procesar esos mismos datos dado que ya se sabe el resultado que han
tenido con anterioridad. Queda a merced del administrador el hacer uso de esta funcionalidad y
de los periodos que se requieren de aprendizaje, así como de los niveles de umbrales que desea
en el sistema para indicar las posibles anomalías. Dependiendo de las necesidades concretas de
algún proceso o host, se pueden jar umbrales diferentes para la reacción de la infraestructura.
3.5. Respuesta
Los resultados obtenidos de la fase de análisis, se utilizan para tomar las decisiones que
conducirán a una respuesta. El conjunto de acciones y mecanismos que se pueden efectuar en esta
etapa es amplio. A continuación se describirán los requisitos y tipos de respuesta más comunes.
Una de las consideraciones a tener en cuenta al diseñar un mecanismo de respuesta es el
entorno operacional en el que se va a utilizar. Un sistema de detección que deba coordinar la
información de múltiples agentes, distribuidos a lo largo de una red de producción, no tiene
las mismas necesidades de alarma y noticación que un sistema no distribuido, instalado en un
ordenador personal. El elemento monitorizado juega, también, un papel importante en el modelo
de respuesta. Una de las razones por las que se proporcionan respuestas activas, como el bloqueo
de las conexiones del atacante, paralización de los procesos sospechosos de ser ataques, se debe
a la existencia de sistemas que proporcionan funciones o servicios críticos a los usuarios.
Por otra parte, las alarmas y avisos proporcionados por un mecanismo de respuesta deberían
presentar suciente información adicional para indicar las acciones a tomar en cada situación. Algunos productos de seguridad sólo indican el identicador del error mediante un simple mensaje,
siendo más útil añadir el posible origen del problema y cómo solucionarlo.
3.5.1. Tipos de respuestas
Las respuestas de un sistema de detección de intrusiones pueden ser de dos tipos: pasivas o
activas. Se pueden dar ambos tipos de respuestas en un sistema de detección, por lo que no son
excluyentes, más bien, son complementarias. Es posible que, en determinadas anomalías, sólo sea
necesario registrar la actividad ocurrida para su posterior examen, mientras que en intrusiones a
sistemas críticos haga falta una actuación más activa y urgente. Todo depende de las necesidades
de cada caso[85].
369
Respuestas pasivas
Son aquellas respuestas que consisten en el envío de información al responsable correspondiente, dejando recaer en él la toma de decisiones. En los primeros detectores de intrusiones,
todas las respuestas eran pasivas. Aunque la tecnología ha evolucionado mucho desde entonces,
las respuestas pasivas siguen existiendo. Y es que, por muy anados que sean los mecanismos
de respuesta automática, hay ocasiones en que un sistema no tiene la responsabilidad suciente
para tomar una decisión.
El mecanismo más común son las alarmas por pantalla, en los que un mensaje en una ventana
indica al usuario que se ha cometido una posible intrusión, acompañando a veces el mensaje con
información adicional, como la dirección del posible atacante, el protocolo usado, etc. El contenido
de estas alarmas se puede congurar en muchas ocasiones.
Otra forma de recibir respuestas pasivas es a través del correo electrónico o mensajes a un
teléfono móvil ?SMS, WAP push, etc-. La ventaja del segundo caso sobre el primero, es que se
puede recibir en cualquier lugar, cualidad muy apreciada entre administradores. No obstante, un
correo electrónico puede contener más información, proporcionando un mensaje más extenso, y
menos ambiguo, sobre la incidencia. El modelo presentado en este punto implementa el segundo
tipo de respuesta, a continuación se muestran algunas pantallas de los mensajes enviados ante
un ataque.
Figura 3.79: Ejemplo de envío de alerta de ataque al telefono móvil (Respuesta pasiva).
370
Por otra parte, algunos sistemas de detección de intrusiones están integrados con mecanismos
de gestión de redes. En estos casos se suele hacer uso de mensajes SNMP170 . La integración con
este sistema de comunicación permite utilizar canales ya existentes para el envío de incidencias.
No obstante, un uso excesivo por parte de detectores de intrusiones de estos canales, puede
perjudicar a otros sistemas que también hagan uso de ellos.
Respuestas activas
Este tipo de respuestas implican alguna acción en particular, como el bloqueo de un proceso,
el cierre inmediato de una cuenta, o la prohibición de ejecución de determinados comandos. Estas
acciones que pueden ser de diversa naturaleza se pueden clasicar básicamente en tres categorías
principales: Ejecución de acciones contra el intruso, Corrección del entorno y Recopilación de
información que se resumen a continuación.
La forma más directa de
Ejecución de acciones contra el intruso
consiste en identicar
el origen del ataque e impedirle el acceso al sistema, por ejemplo, en el caso de un sistema
de detección de intrusiones basado en red, la ejecución de acciones contra el usuario puede ser
desactivar una conexión de red o bloquear la máquina comprometida-, acciones menos drásticas
pueden ser, terminar la sesión TCP problemática o bloquear durante un intervalo de tiempo el
origen de las intrusiones. En cuanto a los sistemas HIDS, las acciones a tomar contra el usuario
pueden ser, por ejemplo impedimiento al proceso sospechoso de ejecutar más syscalls, eliminar los
procesos sospechosos, o incluso impedir al usuario involucrado en el evento sospechoso ejecutar
ningún programa más.
Como su nombre indica la
Corrección del entorno
consiste en efectuar las acciones perti-
nentes para restaurar el sistema y corregir los posibles problemas de seguridad existentes. En
muchas ocasiones, esta respuesta activa suele ser la acción más acertada. Aquellos sistemas que
cuentan con métodos de de auto-curación son capaces de identicar el problema y proporcionar los métodos adecuados para corregirlo. A menudo, este tipo de respuestas puede provocar
cambios en el motor de análisis o en los sistemas expertos, generalmente aumentando su sensibilidad e incrementando el nivel de sospecha ante posibles intrusiones, o ante usuarios o procesos
concretos.
La
Recopilación de más información
se utiliza en ocasiones para cumplir los requisitos de
información necesarios para poder tomar acciones legales contra posibles criminales. Normalmente se aplica en sistemas que proporcionan servicios críticos. Otra de las situaciones en las que se
puede dar este tipo de respuesta, es en máquinas o redes que imitan comportamientos y servicios
reales, para engañar a los intrusos. Tal es el caso de servidores trampa y honeypots por citar
algunos.
170
Simple Network Management Protocol
371
Prevención
Las respuestas activas, tienen varios problemas para con algunos tipos de ataque, en los cuales
la acción de la respuesta activa queda eliminada o minimizada.
Incapacidad de interactuar con ataque spoofeados171 , si un intruso lograse hacer pasar un
proceso con un nombre (por ejemplo
proceso
apache
apache ),
la respuesta activa puede encontrar a el
legítimo como un proceso sospechoso y tomas acciones para con él, como
puede ser pararlo, o suspenderlo, cuando se trata de un proceso legítimo.
Incapacidad de mantener Listas blancas de procesos, dado que los procesos son vulnerables
a ataques de overow, por lo que en los sistemas de host es imposible mantener este tipo
de listas.
Imposibilidad de bloquear el evento que ha disparado la alerta. Este es el mayor problema
del que adolecen los sistemas de respuesta activa, dado que hay ataques que únicamente
ejecutan una acción que puede ser sensible de ser localizada172 .
Figura 3.80: Problemática de la respuesta activa en sistemas NIDS
Por lo tanto, la prevención añade una solución a los problemas de la respuesta activa, aparte
de eliminar otro problema de la mísma que es dotar de la inteligencia necesaria al sistema de de
repuesta activa como para que tome acciones correctas contra los atacantes, dado que en este
tipo de sistemas [243, 342], sólamente atajan las syscalls173 , o los paquetes de red174 .
171
172
Ataques de suplantación
Como pueden ser por ejemplo los ataques ICMP en red, o un buer overow sobre un argumento de una
syscall.
173
174
En el caso de los sistemas HIDS (Sistemas de intrusión de host) como el que estamos tratando ahora mísmo
en el caso de los sistemas NIDS (Sistema de detección de intrusiones basado en red).
372
3.5.2. Respuesta implementada en ESIDE-Mendizale.
En el sistema de respuesta activa de ESIDE-Mendizale se encuentran implementados varios
tipos de respuesta activa explicados en el punto anterior, por una parte un sistema de respuesta
pasiva implementada dentro de la infraestrucutra del sistema, que permite realizar diferentes
alertas.
Por otra parte el sistema ofrece también la posibilidad de implementar respuesta activa, con
diferentes puntos de vista en la aplicación de la mísma.
Respuesta pasiva implementada en ESIDE-Mendizale
La respuesta pasiva implementada en el presente proyecto, se encuentra soportada por el sistema de respueta que está explícitamente implementado para el presente proyecto. Esta respuesta
pasiva, realiza un aviso, sobre el ataque o anomalía que se ha detectado.
Este tipo de respuesta es la más implementada en los sistemas convencionales, tanto por su
sencillez como por no tener que implementar una lógica de respuesta, la cuál se deja a manos de
el agente humano o administrador de sistemas que tome la acción necesaria para el evento que
se ha recogido.
La respuesta pasiva se implementa en varias versiones, mediante un mensaje SMS, que permite
informar al administrador de sistemas allí donde se encuentre, y tomar las acciones necesarias
al momento. Otra de las opciones implementadas es generar la salida mediante XML, para
un posíble data mining o procesado por parte de otros procesos este chero, que simplica y
estandariza el acceso a datos.
Respuesta activa implementada en ESIDE-Mendizale
La respuesta activa implementada en ESIDE-Mendizale, se encuentra dividida en dos grandes
partes: por una parte la respuesta activa implementada a nivel de proceso, y por otra parte la
respuesta activa implementada a nivel de usuario o usuario efectivo.
La respuesta activa a nivel de proceso, implica que una vez que se ha detectado que un
proceso es anómalo
175
, dicho proceso no pueda ejecutar ninguna llamada al sistemas más, es
decir, puede llamar a las librerías del sistema, pero éstas no pueden ejecutar ningúna llamada al
kernel de dicho proceso. Este sistema, permite
congelar
los procesos para que una aprobación
del administrador del sistema permita liberar dicho proceso. Este proceso se puede dar porque
el sistema de recolección de datos inserta una función
tranpolín
entre las llamadas legítimas y
las de nuestro sistema. Este sistema de recogida de datos posee absolutamente todo el control
sobre dichas llamadas, incluso si se ejecutan, si no se ejecutan o no se responden hasta que el
administrador de sistemas de un aviso de que el proceso puede seguir, en caso contrario puede
matar dicho proceso.
175
Alguna de sus systems calls ha generado una anomalía en algún experto del sistema.
373
Otra opción barajada para la respuesta activa a nivel de proceso, se trata de suspender a nivel
de kernel el proceso involucrado, cambiando el estado del proceso a suspendido, este sistema, al
nal no ha sido utilizado por la necesidad de estudiar el planicador de procesos de cada sistema
operativo, el cuál es conocido para GNU/Linux, pero no para el resto de sistema para los que se
ha implementado el sistema.
La otra opción dentro de la respuesta activa, es realizarla a nivel de usuario, es decir, que
si algún proceso de algún usuario realiza una acción que es detectada como una anomalía todos
los procesos de dicho usuario se mantienen bloqueados sin realizar ninguna syscall hasta que el
administrador de sistemas da el visto bueno a dicha anomalía, o en su defecto hace que dichos
procesos mueran. En cuanto a este tipo de respuesta activa, es en los sitemas GNU/Linux, existe
una opción que se ha barajado, que es extender este tipo de acciones no sólamente a los usuarios,
sino también a los usuarios efectivos176 , este tipo de usuario, existe en los sistemas GNU/Linux,
por el bit SUID177 , que permite que el chero que contiene dicho bit activo se ejecute con los
provilegios del creador. Por ejemplo el comando
ping
necesita acceder a dispositivos reales para
ejecutar mediante raw sockets su cometido, que es mandar mensajes ICMP. Por lo tanto en un
sistema sin SUID, ningún usuario, excepto el superusuario o root, podría ejecutar el comando ping
y que enviase mensajes ICMP al exterior, dado que para acceder para escritura a dispositivos
hace falta generalmente ser superusuario. Para solucionar este problema, existe el SUID, que
permite ejecutar el programa ping con los privilegios de su creador, en su caso, root. De esta
manera, se permite bloquear un usuario permanentemente en todos los niveles, incluso cuando
es otro usuario cuando ejecuta sus cheros.
Esta opción es justicada porque si un código vírico es ejecutado bajo un usuario, éste código
vírico puede infectar todos los cheros en los que puede escribir dicho usurio. Por lo tanto, si un
usuario queda infectado, todos sus cheros con el bit SUID también podrían quedar infectados
y ser ejecutados por otros usurios, de ahí que se limite la utilización del EUID.
Prevención implementada en ESIDE-Mendizale
La prevención no ha sido implementada en ESIDE-Mendizale, dado que no era uno de los
objetivos principales e implica grandes problemas técnicos en comparación con sistemas NIDS, de
todas maneras, se va a realizar una pequeña aproximación a cómo se implementaría la prevención
en sistemas HIDS, estudio que se llevó a cabo para descartar la implementación de la prevención.
La prevención en este tipo de sistemas, implicaría realizar un estudio de cada una de las
syscalls que se recolectan ántes de que se ejecuten. Esto requeríria ver si cada una de las syscalls
se ajusta al modelo realizado según el apartado
análisis,
y si éste se ajusta, dejar que la syscall
siga su camino.
Este sistema, debería de ser lo sucientemente rápido como para que la ejecución de el pro176
177
También conocidos como EUID, o Eective User IDencation.
Bit especial contemplado dentro de los bits de permisos del sistema GNU/Linux.
374
grama no se ralentize en exceso, dado que estamos haciendo que cada instrucción del programa
pase una vercación. Esta necesidad, haría necesario que el modelo de vercación de cada instrucción se ejecutase en el kernel a modo de LKM178 , para evitar la lentitud ocasionada por la
comunicadión de las zonas de usuario y de kernel.
3.6. Fortaleza
Los sistemas de deteccion de intrusiones son, desde el primer momento en que son implantados, el blanco de los ataques de los intrusos[117], por ello, el sistema de deteccion de intrusiones
debe de ser lo sucientemente able y seguro como para que este tipo de ataques no lleguen a
buen puerto y den una falsa sensacin de seguridad.
Dos de las partes de los sistemas de detección de intrusiones son particularmente sensibles a
este tipo de ataques, en concreto la parte de recogida de información y de almacenamiento de
los resultados obtenidos del proceso de análisis. De otra forma, la información de partida puede
ser objeto de subversión y el sistema de detección estaría proporcionando una falsa sensación de
seguridad.
Este aspecto de la seguridad de la fortaleza que el sistema IDS implementado en ESIDEMendizale, ha sido desarrollado mejorando la seguridad, transparencia y escalabilidad del sistema.
Por una parte, en cuanto a la transparencia de los sistemas, se ha realizado una ocultación de
los procesos y los módulos involucrados en el sistema. Esta solución es dependiente de cada uno
de los sistemas en los que se ha realizado el sistema de recolección de datos, y se ha utilizado el
control que otorga el lugar en el que se encuentra emplazado el sistema de recolección de datos
para esconder la existencia de los procesos y módulos involucrados en el sistema, sensibles a un
atacante externo. Esto se realiza, haciendo que el atacante no pueda ver los procesos existentes,
para ello se utilizan técnicas esencialmente víricas que sobreescriben las llamadas al sistema que
iplementan la escritura y la lectura (Dependiendo del sistema sobre el que se implemente se
modicará el funcionamiento de una o de otra). Estas llamadas se encuentran ya capturadas
mediante funciones
trampolín ,
que implementan la recolección de datos, por lo tanto para
esconder la existencia de dichos procesos, se elimina del buer del resultado los nombres de los
procesos y de los módulos implicados.
Con este sistema, conseguimos que los atacantes sean incapaces de conocer si en ese sistema
existe un sistema de auditoría, porque sencillamente, son incapaces de verlo.
Por otro lado, el uso de una superestructura paralelizable, como la explicada anteriormente,
permite evitar ataques de denegación de servicio basados en complejidad algorítmica. Según [25]
estos ataques se basan en explotar vulnerabilidades algorítmicas de muchos de los algoritmos
empleados en el software a atacar. La idea clave del ataque es que muchas de las estructuras
de datos y algoritmos empleados habitualmente, tienen un buen comportamiento en los casos
178
Loadable Kernel Module
375
normales, pero pueden degenerar a casos críticos -en consumo de memoria o de CPU- ante
situaciones patológicas. De esta forma, sí la superestructura se paraleliza para que se ejecute,
de forma distribuida, cada una en un equipo este ataque pasa a ser inocuo porque se podrá
sobrecargar uno o varios sistemas pero el resto siguen funcionando a pleno rendimiento.
Añadido a lo anterior el uso de una superestructura orientada a la poda de expertos, ya
comentado anteriormente, hace que se eviten ataques de denegación de servicio basados en complejidad algorítmica. Sí un experto se satura el propio modelo es capaz de "podar" esa rama,
que lo esta ralentizando, hasta que su situación vuelva a la normalidad.
Otra forma de dotar de fortaleza al sistema de detección es mediante la protección de la
recogida de información en base a la ubicación de los elementos de etiquetado y análisis en una
red privada virtual paralela a la infraestructura de comunicaciones a proteger. Un ejemplo de
esto puede verse en la siguiente gura:
Figura 3.81: Ejemplo de arquitectura del sistema, que asegura la fortaleza del sistema mediante
VPNs.
En esta gura se puede apreciar como los sistema de recolección de datos se comunican con
el resto de agentes, es aquí donde la comunicación se puede hacer cifrada mediante una VPN
-representadas por el candado-. Gracias a este cifrado que proporciona la VPN se consiguen tres
de los cuatro pilares básicos de la seguridad de la informacion, a saber: Autenticación -el que
envía la información es realmente quien dice ser-, Condencialidad - nadie en el punto intermedio
entre el snier y el analizador es capaz de ver la información que se esta transmitiendo- y por
último Integridad -los datos que se envían no sufren alteración ninguna en su camino-.
De esta manera, se ha conseguido un sistema que presenta una gran fortaleza contra todo
376
tipo de agresiones, tanto de ataques de denegación como de servicio (mediante la distribución
del cálculo y la posibilidad de poda de elementos sobrecargados), la transparencia de los agentes
de recolección de datos que se autoocultan para no aparecer a los ojos de los atacantes, y la
utilización de redes privadas virtuales (VPN) para la comunicación entre los diferentes elementos
de la red.
3.7. Cuestiones Operacionales
Este apartado, tal y como se ha descrito anteriormente trata sobre cuestiones como la escalabilidad, portabilidad, extensibilidad, así como otros aspectos como pueden ser la interoperabilidad
entre los diferentes componentes o incluso entre diferentes sistemas de detección de intrusiones.
Este tipo de cuestiones son de las más importantes para los usuarios de los sistemas de
detección de intrusiones, la facilidad de mantenimiento, reto establecido en el punto, se supera
ampliamente gracias a que el sistema genera sus salidas comparandolo con la normalidad lo que
dota al modelo de la capacidad de auto-adaptación a la realidad cambiante de la red reduciendo
al mínimo las labores administrativas, no como en otro tipo de sistemas expertos que necesitan
de un operado les inserte el conocimiento.
La portabilidad, entendida desde distintos sistemas operativos, máquinas y redes. Es decir, el
ids debe ser capaz de ejecutarse en distintos sistemas operativos, en distintas arquitecturas y distintas redes, este punto queda ámpliamente superado por la infraestructura de ESIDE-Mendizale,
dado que se ejecuta tanto en sistemas GNU/Linux como en Windows bajo la plataforma CygWin179 , y se adapta a todo tipo de conguraciones y de arquitecturas, gracias a su conguración
en tres capas, dando como lugar un sistema totalmente adapatable a la conguración del entorno
o a las necesidades del sistema a implantar.
La cuestion de la extensibilidad, muy ligada a la esclabilidad, queda de nuevo solventada por
la la estructura del sistema que permite conectar y desconectar nodos de computación (Tails) en
caliente,y cargar y /o descargar dinámicamente plugins en los Tails y Heads.
Cuestiones secundarias como el conocimiento requerido para su conguración y la interoperatibilidad con otros IDS no se han tenido en cuenta a la hora de desarrollar el sistema
ESIDE-Mendizale.
3.8. Aspectos sociales
Los aspectos sociales de un sistema de detección de intrusiones tiene dos vertientes bastante
diferencias, una relativa a los usuarios del entorno que protege y otro relativa a las acciones a
realizar contra los atacantes.
179
Cygwin se trata de la implementación del API de GNU/Linux bajo windows, se trata de una herraminetat
libre disponible en : http://www.cygwin.com/
377
En los aspectos relativos a los usuarios cabe hacerse preguntas del estilo a ¾Cómo afecta el ids
a la comunidad de usuarios que protege?, ¾Realmente evitará la consecución de intrusiones?, ¾Los
usuarios sentirán que sus datos se encuentran más protegidos?, ¾Verán los usuarios al sistema
como el ?gran hermano? que todo lo observa?. La respuesta a todas estas preguntas dependen
de que tipo de ids escoja la organización y que información/formación se les de a los usuarios.
Por tanto, como dependen totalmente del tipo de organización, su respuesta queda totalmente
fuera del ámbito de este proyecto y desde aquí solo se ha querido introducir estas cuestiones.
Por otro lado, la implementación de un sistema de detección de intrusiones implica, en muchas
ocasiones, el cumplimiento de una serie de requisitos impuestos por la ley. Cumplir con estas
obligaciones permite perseguir a los culpables mediante procesos legales o judiciales. Los registros
e informes proporcionados por el detector de intrusiones pueden constituir pruebas que ayuden
a localizar y condenar a los responsables. Sin embargo estos registros e informes pueden incluir
información considerada personal. Johnston establece, en su documento [286],que partes de la
información usada por un IDS se pueden considerar personal y por tanto entran dentro de
las leyes de privacidad. Por todo esto, aunque anteriormente se han presentado las respuestas
activas/reactivas, en el modelo no se hace una utilización, agresiva, de esta capacidad tan solo
se contempla la realización de un sistema de aviso de anomalías.
378
Capítulo 4
Conclusiones y líneas de investigación
futuras
Finalmente, una vez concluido el desarrollo de las diferentes tareas de investigación que
componen el presente estudio, y a la vista de los resultados obtenidos durante la fase de desarrollo
análisis de los resultados, es necesario determinar el grado de innovación con el que se alcanzan en
ESIDE- Depian las hipótesis fundamentales, planteadas en el capítulo 1. Además, por otro lado,
el desarrollo de las investigaciones conducentes a los objetivos marcados en la presente memoria
sirve asimismo para señalar las futuras líneas de trabajo a través de las cuales buscar solución a
ciertas cuestiones que aún permanecen por resolver y los nuevos retos que se plantean a raíz de
los estudios realizados. De este modo, se exponen a continuación tanto las conclusiones obtenidas
a lo largo de las diferentes partes que componen el presente trabajo de investigación, como las
futuras líneas de investigación que son susceptibles de abordarse a corto plazo, con el objetivo
de dar nuevos pasos en el desarrollo del área de conocimiento de la Detección de Intrusiones.
4.1. Conclusiones
Se ha desarrollado una infraestructura con la vista puesta en el futuro y en las siguientes
líneas de investigación. Esta infraestructura va a permitir alcanzar una integridad y unicidad,
aparte de la homogeinización de los resultados. Así mismo se han mezclado y unido las líneas de
investigación basadas en detección de rmas y detección de anomalías por medio de la infraestructura desarrollada: Heptopus. Se ha dedicado un gran esfuerzo en el desarrollo de la misma
para optimizar la rapidez de respuesta y la distribución de carga computacional de forma que se
permitan numerosas conguraciones e implantaciones acorde a los requisitos que sean requeridos.
Así mismo se ha dedicado un gran esfuerzo de trabajo en el desarrollo de una metodología de
trabajo para análisis de trazas de sistema que se espera dé resultados a corto plazo y se materialice
en diferentes proyectos comerciales. Las técnicas de inteligencia articial desarrolladas componen
un avance signicativo en el campo de detección de intrusiones automatizadas para entornos host.
379
El dinamismo y la automatización, así como la conclusión de reglas en base a los mismos hacen
de este proyecto un conjunto único y una nueva visión de desarrollo para las técnicas actuales
existentes en el campo hasta la fecha.
No queda más que indicar que todos estos objetivos no hubieran sido cubiertos sin la existencia
de una librería mantenida por la comunidad del software libre: PNL (subvencionada por Intel).
Sobre la misma se ha desarrollado un sistema software de adaptación, para facilitar el trabajo
con la librería anterior que ha llevado más de la mitad del tiempo de desarrollo del proyecto.
Esta adaptación permite acometer las formas de trabajo con la librería de Intel de forma sencilla
y automática, simplicando el uso de la misma y los requisitos de conocimiento necesarios para
realizar las mismas operaciones directamente con ella.
El equipo de investigación espera grandes resultados del trabajo de este periodo, conando en
la acogida de la comunidad investigadora con entusiasmo a esta nueva visión de la seguridad en
entornos de detección de intrusiones basados en red, en host e incluyendo los terminales móviles
y sus comunicaciones. Si bien el proyecto originariamente se desarrollo en vías a solventar las
problemáticas de este tipo de terminales, los dispositivos móviles, acorde a las hipótesis estas
técnicas pueden usarse indistintamente tanto en terminales móviles como en unidades cableadas.
En primer lugar, el objetivo operacional de desarrollo de un modelo de detección de intrusiones basado en anomalías para terminales móviles ha sido cubierto con creces. Dado que la
metodología de trabajo necesaria para acometer este trabajo en terminales móviles era paralela
a la desarrollada para sistemas informáticos cableados (mainframes, servidores, ordenadores de
sobremesa, portátiles, etc), el proyecto se amplió, introduciendo interceptores para los diferentes
sistemas operativos: Windows y Linux, así como para los sistemas operativos móviles: Symbian
OS, Linux para terminales móviles (Nokia N770 y derivados) y Windows Mobile. El sistema,
ampliado de miras ya, en las pruebas que se han realizado durante el desarrollo del software implementado en este periodo de trabajo ha dado resultados muy esperanzadores sobre el proyecto
desarrollado. La infraestructura ha demostrado acoger las líneas de trabajo anteriores de forma
válida y ha permitido la introducción de una distribución de carga necesaria y requerida para no
saturar los sistemas de detección.
Uno de los principales retos que se presentaron en la parte de retos era el modelado de
perles de usuario no supervisados, con objetivo directo en la detección de ataques noveles (zday attacks). Este objetivo ha sido estudiado en base a las áreas actuales de investigación a
nivel mundial y se ha conseguido mejorar las técnicas existentes para la tecnología actual. Este
modelo basado en Redes Bayesianas puede arrojar una llamada preventiva, dado que al generar
una regla se puede detectar prematuramente e incluso introducir este tipo de regla estáticas
dentro de los terminales móviles, evitando la necesidad de enviar información sobre patrones ya
conocidos como anómalos.
Fruto de un aprendizaje prematuro y una creación de un modelo incompleto se pueden
presentar tasas altas de falsos positivos, esta tasa se puede ajustar por medio de conocimiento
380
experto o volviendo a entrar en modo aprendizaje para los expertos basados en Redes Bayesianas.
Es conveniente observar la tasa de alertas que se van generando para poder garantizar la abilidad
del sistema, dado que puede tener un conocimiento incompleto sobre la aplicación en estudio.
Toda la base de conocimiento del sistema puede ser estudiada dado que sigue un formato
estandarizado en cheros XML que permiten creación, modicación o logeo de características
dentro de la infraestructura y de los propios expertos bayesianos. Además esta parte se aplica
incluyendo a las reglas de detección estática y los veredictos que entregan los expertos, pudiendo
realizarse integraciones con otras aplicaciones. Esta escalabilidad posibilita a los futuros usuarios
o administradores de esta infraestructura gestionarla en la forma que estimen más conveniente.
Un objetivo fundamental es la simplicación del trabajo de las personas dedicadas al tratamiento integral de la seguridad en organizaciones especícas. El prototipo que se ha desarrollado
si bien no esta en un estadio de madurez suciente como para realizar un producto comercial, no
dista mucho de un proyecto de estas características. El objetivo futuro que se plantea por el equipo de investigación es la conclusión de productos comerciales que permitan a los futuros usuarios
una forma sencilla de uso de la infraestructura. Además se les dota de medidas estudiadas y
contrastadas para la detección temprana y corrección de las anomalías que acaezcan.
4.2. Líneas de investigación futuras
Las líneas futuras en las que se esta trabajando actualmente para dar el prototipo por concluido es la medición de tasas de errores, tiempos de aprendizaje y jación de umbrales para
poder dar una visión menos subjetiva a los usuarios de conguración de la plataforma. Si bien es
ajustable en todos sus parámetros, conviene entregar una serie de datos y pruebas más extensa
que la que se dispone actualmente. En plazo corto se dispondrá de estos datos para poder dar el
prototipo por acabado.
Otra línea de investigación es la integración completa con los sistemas de detección de red,
para ello el despliegue de esta plataforma deberá realizarse del lado del operador de telefonía
móvil. Este operador será quien pueda tener acceso a las comunicaciones de los terminales vía
internet (llamadas de datos GSM/GPRS/UMTS) y podrá incorporan los sistemas desarrollados,
tanto para análisis del tráco de red, como para análisis de llamadas al sistema. Esta integración
homogénea y unicada de los datos corre a cargo de una parte fundamental de la plataforma, la
red bayesiana naive de unicación de resultados. Esta red permitirá sacar futuras conclusiones
sobre la concurrencia de que se produzca un ataque de red y se encuentren modicaciones en
el comportamiento de las aplicaciones en estudio y viceversa. Este paso futuro es la integración
fundamental, según la visión de la seguridad de este equipo de investigación, que deberá tenerse
instaurada en todo entorno informatizado para dotarlo de la seguridad requerida.
Líneas de investigación más rompedoras conllevan una modicación en la forma de trabajo
de los terminales móviles, como son la instrumentación de software y aplicaciones instaladas de
forma virtual. Este tipo de sistemas operativos virtualizados, llevados a terminales móviles, dotan
381
a los mismos de entornos seguros de aplicación y comportamiento estanco entre unas aplicaciones
y otras, si bien será necesario instrumentalizar y comprobar el comportamiento anómalo que se
produzcan incluso en el interior de este tipo de entornos.
El desarrollo de sistemas que permitan la instrumentación codicada de métodos implicaría
un fuerte incremento en el consumo de recursos del sistema, pero puede ser un paso adelante en
la instalación de aplicaciones. Esta medida se viene aplicando de forma reducida dentro de los
instaladores, vericando números de serie, funciones resumen criptográca (hash) o cheros de
conguración de permisos. Esto puede ser sobrepasado con la instalación de un sistema de seguridad, mediante una instrumentalización binaria criptográca, en la que se realice la instalación
controlada y la inclusión de los códigos necesarios en el sistema para que cuando se requiera una
funcionalidad del mismo se verique que todo siga bajo la normalidad.
Más puntos interesantes puede ser el estudio de ataques mimicry contra sistemas de detección
criptográcos existentes, un proyecto aparte puede llegar a ser el realizar un proyecto fuera de las
líneas de desarrollo habituales. Siguiendo la línea en la que un auditor de sistemas no desarrolla un
trabajo adecuado si no ha estado desarrollando al otro lado de la barrera, se considera necesario
dedicar un tiempo para desarrollar ataques e infecciones posibles contra los sistemas móviles
y la seguridad que conllevan. Este tipo de desarrollo puede ayudar con conocimiento experto
para los sistemas de detección de intrusiones como el que se ha realizado, introduciendo nuevas
conclusiones en el mismo o nuevas tesituras a tener en cuenta.
382
Bibliografía
[1]
Wikipedia, http://es.wikipedia.org/wiki/Ficherobinario.
[2]
Wikipedia, http://es.wikipedia.org/wiki/Exploit.
[3] R. e. neapolitan. probabilistic reasoning in expert systems: Theory and algorithms.
Interscience, New York,
Wiley-
1990.
[4] The bayesian information criterion (bic).
Disponible en département de mathématiques
de Besançon. http://www-math.univ-fcomte.fr/mixmod/statdoc/node21.html,
Septiembre
2005.
[5] Databases and articial intelligence. articial intelligence segment. hill-climbing .
ble en: http://www.cee.hw.ac.uk/ alison/,
[6] Hypertext
transfer
protocol
Disponi-
2005.
http/1.1.
2005.
Disponible
en
http://www.ietf.org/rfc/rfc2616.txt.
[7] Internet control message protocol. darpa internet program. protocol specication. 2005.
http://www.ietf.org/rfc/rfc768.txt.
[8] Internet protocol. darpa internet program. protocol specication. 2005. Disponible en
http://www.ietf.org/rfc/rfc791.txt.
[9] Multiple
imputation
for
missing
data.
http://support.sas.com/rnd/app/da/new/dami.html,
Disponible
en
Octubre 2005.
[10] Transport control protocol. darpa internet program. protocol specication. 2005. Disponible en http://www.ietf.org/rfc/rfc793.txt.
[11] User datagram protocol. darpa internet program. protocol specication. 2005. Disponible
en : http://www.ietf.org/rfc/rfc768.txt.
[12] Raftery A. Bayesian model selection in social research.
Methodology. Blackwells, Cambridge, MA,
1995.
383
In Marsden, P., editor, Sociological
[13] N. Abouzakhar, A. Gani, and Abuitbel M. y King D Manson G. Bayesian learning networks
approach to cybercrime detection.
Liverpool, UK,
Post Graduate Symposium, John Moore University,
Junio 2003.
[14] M. Schatz A.K. Ghosh, A. Schwartzbard. Using program behavior proles for intrusion
detection.
3rd SANS Workshop on Intrusion Detection and Response,
1999.
[15] J. Allen, A. Christie, Fithen W., McHugh J., Pickel J., and Stoner E. State of the practice of intrusion detection technologies.
Institute, Technical Report,
Carnegie Mellon University Software Engineering
2000.
[16] Intersect Alliance. Guide to snare epilog for unix, snareapache and snaresquid. 2006.
[17] P. Alípio, P. Carvalho, and J. Neves. Using clips to detect network intrusion.
Lecture
Notes in Computer Science, Vol. 2902/2003, Pag. 341-354, ISBN 0302-9743, SpringerVerlag,
Diciembre 2003.
[18] K. Anagnostakis, S. Antonatos, E. Markatos, and M. Polychronakis. E2xb: A domainspecic string matching algorithm for intrusion detection.
International Information Security Conference,
Proceeding of the 18th IFIP
Mayo 2003.
[19] D. Anderson, T. Frivold, A. Tamaru, and A. Valdés. Next generation intrusion detection
expert system (nides), software users manual.
tional,
Computer Science Laboratory, SRI Interna-
Mayo 1994.
[20] J. Anderson. Computer security threat monitoring and surveillance.
Washington, Pennsylvania,
Technical Report, Fort
Abril 1980.
[21] J. P. Anderson. Computer security threat monitoring and surveillance. 1980.
[22] Kamal Nigam Andrew McCallum. A comparison of event models for naive bayes text
classication.
School of Computer Science Carnegie Mellon University,
1998.
[23] Alerta Antivirus. Centro de alerta temprana sobre virus y seguridad informática. Disponible
en http://alerta-antivirus.red.es/portada/,
2006.
[24] W. A. Arbaugh, W. L. Fithen, and J. McHugh. Windows of vulnerability: A case study
analysis.
IEEE Computer,
December 2000.
[25] J. Avión. Denegación de servicio a través de ataques de complejidad algorítmica.
Disponible
http://www.computeridea.net/Actualidad/Noticias/Seguridad/Vulnerabilidades/20030729002,
2005.
[26] S. Axelsson. Intrusion detection systems: A survey and taxonomy.
Technical report 99-15,
Department of Computer Engineering, Chalmers University. Goteborg, Suecia,
384
2000.
[27] S. Axelsson. Visualization for intrusion detection: Hooking the worm.
Proceedings of the
8th European Symposium on Research in Computer Security, Vol. 2808 of Lecture Notes
in Computer Science, Springer-Verlag, Noruega,
Octubre 2003.
[28] R. Bace and P. Mell. Intrusion detection systems.
NIST Special Publication on Intrusion
Detection Systems. Disponible en http://csrc.nist.gov/publications/nistpubs/,
2001.
[29] Z. Baker and V. Prasanna. Automatic synthesis of ecient intrusion detection systems on
fpgas.
Proceedings of the International Conference on Field-Programmable Logic and its
Applications, Bélgica,
Septiembre 2004.
[30] J. Balasubramaniyan, J. Omar, D. Isaco, G. Spaord, and D. Zamboni. An architecture for
intrusion detection using autonomous agents.
Technical Report 98/05, COAST Laboratory,
Purdue University, West Lafayette, IN 47907-1398, USA,
[31] P. Bania. Windows syscall shellcode.
SecurityFocus,
Junio 1998.
2005.
[32] D. Barbará, N. Wu, and S. Jajodia. Detecting novel network intrusion using bayes estimators.
First SIAM International Conference on Data Mining,
2001.
[33] J. Barrus. A distributed autonomous-agent network-intrusion detection and response system.
Proceedings of the 1998 Command and Control Research and Technology Symposium,
Monterey, Canadá,
Julio 1998.
[34] E. Bauer, D. Koller, and Y. Singer. Udpate rules for parameter estimation in bayesian
networks.
Stanford University, AT&T Labs,
1996.
[35] S. Beattie, S. Arnold, C. Cowan, P. Wagle, C. Wright, and A. Shostack. Timing the
application of security patches for optimal uptime.
Systems Administration Conference (LISA).,
In Proceedings of the 2002. USENIX
November 2002.
[36] M. Bernaschi, E. Gabrielli, , and L. V. Mancini. Remus: a security-enhanced operating
system.
ACM Transactions on Information and System Security 5, 36 (Feb.),
2002.
[37] Massimo Bernaschi, Emanuele Gabrielli, and Luigi V. Mancini. Operating system enhancements to prevent the misuse of system calls.
Rome, Italy,
IAC-CNR. Viale del Policlinico, 137. 00161
2000.
[38] BlindView. Strace for windows. 2005.
[39] Charles S. Bos. Markov chain monte carlo methods: Implementation and comparison.
Tinbergen Institute & Vrije Universiteit Amsterdam. In Progress.,
Agosto 2004.
[40] S. Bridges and R. Vaughn. Fuzzy data mining and genetic algorithms applied to intrusion detection.
Proceedings of the 2000 National Information Systems Security Conference
(NISSC), Baltimore, USA,
Octubre 2000.
385
[41] S. Bridges and R. Vaughn. Intrusion detection via fuzzy data mining.
12th Annual Canadian Information Technology Security Symposium,
Proceedings of the
Junio 2000.
[42] P. García Bringas and J.L. Val Román. Eside-depian: Entorno de seguridad inteligente para la detección y prevención de intrusiones de red basado en anomalías.
Bizkaiko
Foru Aldundia - Diputación Foral de Bizkaia, Berrikuntza eta Ekonomi Sustapen Saila Departamento de Innovación y Promoción Económica. Informe-Solicitud aprobado por el
programa Bizkaitek,
2004.
[43] H. K. Browne, W. A. Arbaugh, J. McHugh, and W. L. Fithen. A trend analysis of exploitations.
In Proceedings of the 2001 IEEE Symposium on Security and Privacy,
May
2001.
[44] D. L. Bruening. Ecient, transparent, and comprehensive runtime code manipulation.
Ph.D., M.I.T. http://www.cag.lcs.mit.edu/dynamorio/,
2004.
[45] B. Buck and J. K. Hollingsworth. An api for runtime code patching.
The International
Journal of High Performance Computing Applications, 14(4):317 to 329.,
[46] W. Buntine. Learning classication trees.
2000.
In Articial Intelligence Frontiers in Statistics:
AI and statistics III. Chapman and Hall, New York,
1994.
[47] D. Burroughs, L. Wilson, and G. Cybenko. Analysis of distributed intrusion detection
systems using bayesian methods analysis of distributed intrusion detection systems using
bayesian methods. Proceedings of the 21th International Performance Computing and Communications Conference,
Abril 2002.
[48] M. Bykova and S. Ostermann. Staistical analisys of malformed packets and their origins
in the modern internet.
University,
School of Electrical Engineering and Computer Science, Ohio
2002.
[49] Kruegel C. Network alertness, towards an adaptative collaborating intrusion detection
system. 2002.
[50] Krügel C. Network alertness, towards an adaptative, collaborating intrusion detection
system.
Dissertation for the degree of Doctor of Philosophy, University of Wien, Austria,
2002.
[51] Siddhartha
C.
The
gibbs
sampling
algorithm.
http://www.quantlet.com/mdstat/scripts/csa/html/node28.html,
Disponible
en
Septiembre 2005.
[52] A. Ghosh C. Michael. Using nite automata to mine execution data for intrusion detection:
A preliminary report.
RAID 2000, LNCS 1907, pp.66-79,
386
2000.
[53] CAIDA.
Dynamic
graphs
of
the
nimda
http://www.caida.org/dynamic/analysis/security/nimda/,
worm.
Disponible
en
2001.
[54] J. Cannady and J. Mahaey. The application of articial intelligence to misuse detection.
Proceedings of the First Recent Advances in Intrusion Detection (RAID) Conference,
1998.
[55] Shapiro M. W. Cantrill, B. M. and A. H. Leventhal. Dynamic instrumentation of production
systems.
6th Symposium on Operating Systems Design and Implementation,pp. 15?28.,
2004.
[56] Jannette Cardoso and Heloisa Camargo.
Fuzziness in Petri Nets, Physica-Verlag.
98.
[57] E. Castillo, J.M. Gutiérrez, and A. Hadi. Sistemas expertos y modelos de redes probabilísticas.
Monografías de la Academia de Ingeniería, ISBN 8460093956,
1998.
[58] CERT Computer Emergency Response Team Coordination Center. Cert/cc overview incident and vulnerability trends.
trends/,
Disponible en http://www.cert.org/present/cert-overview-
2003.
[59] CERT Computer Emergency Response Team Coordination Center. Cert/cc statistics 19882005.
Disponible en http://www.cert.org/stats/certstats.html,
2005.
[60] CERT Coordination Center. Computer emergency response team coordination center home
page. http://www.cert.org/, 2006. Disponible en http://www.cert.org/.
[61] Jesús Cerquides and Ramón López de Mantaras. Tractable bayesian learning of tree augmented naive bayes classiers.
Instituto de Investigación en Inteligencia Articial, CSIC,
2003.
[62] S. N. Chari and P.-C. Cheng. Bluebox: A policy-driven, host-based intrusion detection
system.
In Proceedings of the 2002 ISOC Symposium on Network and Distributed System
Security (NDSS'02). San Diego, CA.,
2002.
[63] E. Charniak. Statistical languaje learning.
MIT Press, Cambridge, Massachusetts,
1993.
[64] S. Chavan, K. Shah, N. Dave, S. Mukherjee, A. Abraham, and S. Sanyal. Adaptative
neuro-fuzzy intrusion detection systems.
Proceedings of the 2004 International Conference
on Information Technology: Coding and Computing (ITCC), Vol. 1, Pag. 70,
2004.
[65] S. Chebrolu, A. Abraham, and J. Thomas. Feature deduction and ensemble design of
intrusion detection systems.
Elsevier Science,
Computers and Security Journal, Vol. 24/4, Pag. 295-307,
2005.
[66] P. Cheeseman and J. Stutz. Bayesian classication (autoclass): Theory and results.
puters and Security Journal, Vol. 24/4, Pag. 295-307, Elsevier Science,
387
1995.
Com-
[67] Jie Cheng and Russell Greiner. Learning bayesian belief network classiers: Algorithms and
systems.
Canadian Imperial Bank of Commerce, Toronto, Ontario, Canada. Department
of Computing Science, University of Alberta Edmonton, Alberta, Canada,
[68] Fredrik Valeur Giovanny Vigna Christopher Kruegel, Darren Mutz.
Anomalous System Call Arguments.
[69] CISCO.
Cisco
intrusion
2000.
On the Detection of
Springer Berlin / Heidelberg, 2003.
detection
home
http://www.cisco.com/warp/public/cc/pd/sqsw/sqidsz/,
[70] CMU. Carnegie mellon university home page.
page.
Disponible
en
2006.
Disponible en http://www.cmu.edu/,
2006.
[71] J. Conesa, M. Contero, and P. Company. Comportamiento de los algoritmos de optimización en la reconstrucción geométrica de sólidos.
Universitat Jaume I,
Univerisidad Politecnica de Cartagena.
2001.
[72] Cordis. Community research and development information service home page.
en http://www.cordis.lu/en/home.html,
Disponible
2006.
[73] Intel Corporation. Probabilistic network library: User guide and referente manual.
Technology Laboratories, Intel Corporation,
2004.
[74] Symantec Corporation. Ensuring your information is secure and available.
http://www.symantec.com/,
Systems
Disponible en
2006.
[75] E. Cox. The fuzzy systems handbook: A practitioner's guide to building, using, and maintaining fuzzy systems.
AP Professional, Primera edició, ISBN 0121942708,
Febrero 1994.
[76] M. Crosbie and G. Saord. Applying genetic programming to intrusion detection.
Working
Notes for the AAAI Symposium on Genetic Programming, Pag. 1-8, MIT, Cambridge,
USA,
Diciembre 1995.
[77] M. Crosbie and G. Spaord. Active defense of a computer system using autonomous agents.
Technical Report 95-008, COAST Group, Department of Computer Sciences, Purdue University, West Lafayette, Indiana, USA,
Febrero 1995.
[78] T. Crothers. Implementing intrusion detection systems: A hands-on guide for securing the
network.
John Whiley and Sons, Incorporated. ISBN 0764549499,
[79] CSI. Computer security institute home page.
[80] CSO.
Diciembre 2002.
Disponible en http://www.gocsi.com/,
Computer security ocer: The resource for security executives.
http://www.csoonline.com/,
2006.
Disponible en
2006.
[81] T. W. Curry. Proling and tracing dynamic library usage via interposition.
Summer 1994 Technical Conference, pages 267 to 278, Boston, MA.,
388
1994.
In USENIX
[82] Goldberg D. The design of innovation: Lessons from and for competent genetic algorithms.
Addison-Wesley, Primera edición, ISBN 1402070985,
[83] González
D.
Receive-only
utp
http://www.dgonzalez.net/pub/roc/,
[84] González D.
and
network
D.
Modelo
taps.
Disponible
en
2003.
Sistemas de deteccion de intrusiones.
http://www.dgonzalez.net/pub/ids/,
[85] Gonzalez
cables
Junio 2002.
Version 1.01, Disponible en
Julio 2003.
de
funcionamiento.
2005.
Disponible
en:http://www.dgonzalez.net/pub/ids/html/cap03.htm.
[86] Heckerman D. A tutorial on learning with bayesian networks. Marzo 1995.
[87] Lowd D. Naive bayes models for probability estimation.
and Engineering. University of Washington,
2005.
[88] Shannon C. Y Moore D. The spread of the witty worm.
2, N. 4,
Department of Computer Science
IEEE Security and Privacy, Vol
Julio Y Agosto 2004.
[89] Spaord E. Y Zamboni D. Intrusion detection using autonomous agents.
tworks, 34(4):547-570,
Computer Ne-
Octubre 2000.
[90] Upper D. Theory and algorithms for hidden markov models and generalized hidden markov
models.
Dissertation for the degree of Doctor of Philosophy, Mathematics Department,
University of California, Berkeley, USA,
Febrero 1997.
[91] Weakliem D. A critique of the bayesian information criterion for model selection. University
of Connecticut. Sociological Methods & Research, Vol. 27, No. 3, 359-397,
[92] Zamboni D. Using internal sensor for computer intrusion detection.
1999.
Center for Education
and Research in Information Assurance and Security. Thesis submitted to the Faculty of
Purdue University,
[93] DARPA.
2001.
Darpa
intrusion
http://www.ll.mit.edu/IST/ideval/,
[94] DARPA.
detection
evaluation.
en
Julio 2001.
Defense advanced research projects agency home page.
http://www.darpa.mil/,
Disponible
Disponible en
2006.
[95] GIOVANNI VIGNA CHRISTOPHER KRUEGEL DARREN MUTZ, FREDRIK VALEUR. Anomalous system call detection.
nical University of Vienna,
University of California, Santa Barbara - Tech-
February.
389
[96] D. Dasgupta and F. González. An immunity-based technique to characterize intrusions
in computer networks.
Pag. 1081-1088,
Transactions of the IEEE Evolutionary Computing, Vol. 6, No. 3,
Junio 2002.
[97] A.P. Dawid. Prequential data analysis.
In M. Ghosh and P. K. Pathak, editors, Current
Issues in Statistical Inference: Essays in Honor of D. Basu, IMS Lecture NotesMonographs
Series 17, pages 113126. Institute of Mathematical Statistics, Hayward, California,
1992.
[98] Red Iris: Red Española de Investigacion y Desarrollo. Servicio de seguridad iris-cert.
http://www.rediris.es/cert/, 2006. Disponible en http://www.rediris.es/cert/.
[99] Tatum Consultoría Comercial Y de Marketing. Informe de e-commerce (b2c).
en http://www.tatum.es/,
Disponible
2004.
[100] H. Debar, M. Dacier, and A. Wespi. Towards a taxonomy of intrusion-detection systems.
Computer Networks, Vol. 31, No. 8, Pag. 805-822,
Abril 1999.
[101] H. Debar, M. Dacier, and A. Wespi. A revised taxonomy for intrusion-detection systems.
Annales des Télécommunications, Vol. 55, Pag. 361-378,
2000.
[102] H. Debar, M. Huang, and D. Donahoo. Intrusion detection exchange format data model.
Disponible en http://www.ietf.org/internet-drafts/draft-ietf-idwg-datamodel-03.txt,
Ju-
nio 2000.
[103] Comision del Mercado de las Telecomunicaciones. Informe sobre el comercio electronico
en españa a través de entidades de medios de pago (4âo trimestre 2004).
http://www.cmt.es/cmt/centroinfo/publicaciones/index.htm,
Disponible en
2005.
[104] A. Dempster, N. Laird, and D. Rubin. Maximum likelihood from incomplete data via the
em algorithm.
Journal of the Royal Statistical Society, Series B, 39(1):138,
[105] D. Denning. An intrusion detection model.
13, 2 (Feb.), 222-232,
1977.
IEEE Transactions on Software Engineering
1987.
[106] J.E. Dickerson and J.A. Dickerson. Fuzzy network proling for intrusion detection.
Pro-
ceedings of the NAFIPS 19th International Conference of the North American Fuzzy Information Processing Society, Pag. 301-206, Atlanta, USA,
Julio 2000.
[107] J.E. Dickerson, J. Juslin, O. Koukousoula, and J.A. Dickerson. Fuzzy intrusion detection.
Proceedings of the IFSA World Congress and NAFIPS 20th International Conference of the
North American Fuzzy Information Processing Society, Vol. 3, Pag. 1506-1510, Vancouver,
Canada,
Julio 2001.
[108] Full Disclosure. An unmoderated mailing list for the discussion of security issues. Disponible
en https://lists.grok.org.uk/mailman/listinfo/full-disclosure,
390
2006.
[109] DoD.
United
states
department
http://www.defenselink.mil/,
of
defense
home
page.
Disponible
en
2006.
[110] P. Dokas, L. Ertoz, V. Kumar, A. Lazarevic, J. Srivastava, and P. Tan. Data mining for
network intrusion detection.
Mining, Baltimore, USA,
Proceedings of the NSF Workshop on Next Generation Data
Noviembre 2002.
[111] P. Domingos and M. Pazzani. On the optimality of the simple bayesian classier under
zero-one loss.
Machine Learning, 29:103-130,
1997.
[112] J. Doyle, I. Kohane, W. Long, H. Shrobe, and P. Szolovits. Event recognition beyond
signature and anomaly.
Proceedings of the 2001 IEEE Workshop on Information Assurance
and Security United States Military Academy, West Point, New York, USA,
[113] M. Druzdzel and H. Simon. Causality in bayesian belief networks.
Junio 2001.
Proceedings of the
9th Conference on Uncertainty in Articial Intelligence, Pag. 3-11, Washington, Morgan
Kaufmann, San Mateo, California, USA,
1993.
[114] F.J. Díez. Local conditioning in bayesian networks.
Articial Intelligence, 87:120,
[115] F.J. Díez. Introducción al razonamiento aproximado.
cial, Universidad de Educación a Distancia,
1996.
Departamento de Inteligencia Arti-
1998.
[116] Lundin E. Logging for intrusion and fraud detection.
Thesis for the degree of Doctor of
Philosophy, Department of Computer Engineering, Chalmers University, Göteborg, Suecia,
2004.
[117] Lunding E. Logging for intrusion and fraud detection.
Philosophy Department of Computer Engineering,
Thesis for the degree of Doctor of
2004.
[118] Spaord E. The internet worm: Crisis and aftermath.
32(6):678-687,
Communications of the ACM,
Junio 1989.
[119] S. Eckmann. Translating snort rules to statl scenarios.
Fourth International Symposium
on Recent Advances in Intrusion Detection, University of California Davis, Lecture Notes
in Computer Science 2212, Pag. 69-84,
Octubre 2001.
[120] S. Eckmann, G. Vigna, and R. Kemmerer. Statl: An attack languaje for state-based intrusion detection.
Technical Report, Department of Computer Science, University of Califor-
nia, Santa Barbara, USA,
2000.
[121] A. Eiben and J. Smith. Introduction to evolutionary computing. Springer, Primera edición,
ISBN 3540401849,
Noviembre 2003.
391
[122] D. Endler. Intrusion detection. applying machine learning to solaris audit data.
Proceedings
of the 14th Annual Computer Security Applications Conference (ACSAC), Pag. 268,
[123] esCERT.
1998.
Equipo de seguridad para la coordinacipn de emergencias en redes te-
lematicas.
http://www.escert.org/index.php/web/es/index.html, 2006.
Disponible en
http://www.escert.org/index.php/web/es/index.html.
[124] E. Eskin. Anomaly detection over noisy data using learned probability distributions.
Proceedings of ICML 2000, Menlo Park, CA, 2000. AAAI Press.,
In
2000.
[125] E. Eskin, W. N. Grundy, and Y. Singer. Protein family classication using sparse markov
transducers.
In Proceedings of the Eighth International Conference on Intelligent Systems
for Molecular Biology, Menlo Park, CA. AAAI Press.,
2000.
[126] Eleazar Eskin, Wenke Lee, J. Salvatore, and Stolfo. Modeling system calls for instrusion
detecction with dynamic window sizes. 2001.
[127] The Common Criteria Evaluation and Validation Scheme. Common criteria for information
technology security evaluation.
Version 3.0,
Junio 2005.
[128] FBI. Federal bureau of investigation home page.
[129] FBI/CSI.
Disponible en http://www.fbi.gov,
2005 fbi/csi computer crime and security survey.
http://www.gocsi.com/,
2006.
Disponible
en
2005.
[130] P. Felgaer, P. Britos, J. Sucre, A. Servetto, R. García-Martínez, and G. Perichinsky. Optimización de redes bayesianas basado en técnicas de aprendizaje por inducción. 1995.
[131] H. Feng, O. Kolesnikov, P. Fogla, and W. Lee. Anomaly detection using call stack information.
In Proceedings of the 2003 IEEE Symposium on Security and Privacy.,
[132] Security
Focus.
Bugtraq
mailing
http://www.securityfocus.com/archive/1,
[133] B.
Fonseca.
The
ips
list.
2003.
Disponible
en
2006.
question.
InfoWorld
Magazine.
http://www.infoworld.com/article/03/04/04/14ips1.html?security,
Disponible
en
Abril 2003.
[134] S. Forrest, S. A. Hofmeyr, A. Somayaji, and T. A. Longsta. A sense of self for unix
processes.
In Proceedings of the 1996 IEEE Symposium on Security and Privacy, pages ,
Los Alamitos, CA. IEEE Computer Society Press.,
1996.
[135] Friedman, Geiger, and Goldszmidt. Bayesian network classiers.
AT&T Labs,
University of California.
1997.
[136] N. Friedman and M. Goldszmidt. Sequential update of bayesian network structure.
versity of California, Computer Science Division. SRI International,
392
1995.
Uni-
[137] N. Friedman and Y. Singer. Ecient bayesian parameter estimation in large discrete
domains.
Computer Science Division University of California. AT&T Labs,
[138] Fyodor. The art of port scanning.
1997.
Disponible en http://www.insecure.org/nmap/,
1997.
[139] Wolf D. G. Statement before the house committee on government reform, subcommittee
on government eciency, nancial management and intergovernmental relations, and the
subcommittee for technology and procurement policy.
Act,
Federal Information Security Reform
2002.
[140] D.B. G. Hunt. Detours: Binary interception of win32 functions.
Microsoft Research,
1999.
[141] Debin Gao, Michael K. Reiter, and Dawn Song. Gray-box extraction of execution graphs
for anomaly detection.
nications security,
Proceedings of the 11th ACM conference on Computer and commu-
October 2004.
[142] T. Garnkel and M. Rosenblum. A virtual machine introspection based architecture for
intrusion detection.
In Proceedings of the 2003 Network and Distributed System Security
Symposium (NDSS),
February, 2003.
[143] A.E. Gelfand and A.F.M. Smith. Sampling-based approaches to calculating marginal densities.
Journal of the American Statistical Association, 85: 398-409,
1990.
[144] S. Geman and D. Geman. Stochastic relaxation, gibbs distributions and the bayesian
restoration of images.
12: 609-628,
IEEE Transactions on Pattern Analysis and Machine Intelligence,
1984.
[145] Zhihai Wang Geof Webb, Janice Boughton. Not so naive bayesian classication.
Monash
University, Melbourne, Australia.
[146] Wanken J. Ghosh, A. and F. Charron. Detecting anomalous and unknown intrusions
against programs.
In Proceedings of the Annual Computer Security Application Conference
(ACSAC'98). Scottsdale, AZ. 259-267,
1998.
[147] Golomb03. Intrusion detection methodologies demystied.
ted Technical Whitepaper,
Enterasys Networks Incorpora-
Diciembre 2003.
[148] Schwartzbard A. y Schatz M. Gosh A. Learning program behavior proles for intrusion
detection.
Proceedings of the rst USENIX Workshop on Intrusion Detection and Network
Monitoring, Santa Clara, California, USA,
Abril 1999.
[149] Ledesma B. y Brotons F. Grediaga A., Ibarra F. Utilización de redes neuronales para la detección de intrusos.
de Alicante,
Departamento de Tecnología Informática y Computación, Universidad
2002.
393
[150] Abraham A. y Han S. Grocan C. Mepids: Multi-expression programming for intrusion detection system.
International Work-Conference on the Interplay between Natural and Arti-
cial Computation (IWINAC), Lecture Notes in Computer Science, LNCS 3562, SpringerVerlag, Pag. 163-172, España,
2005.
[151] Oulu University Secure Programming Group. Glossary of vulnerability testing terminology.
Disponible en http://www.ee.oulu./research/ouspg/sage/glossary/,
2004.
[152] John Gulbrandsen. System call optimization with the sysenter instruction.
[153] Kim J. H. Convince: A conversational inference consolidation engine.
Computer Science, University of California, Los Angeles,
codeguru,
2004.
Tesis doctoral, Dept.
1983.
[154] Kvarnstram H. A survey of commercial tools for intrusion detection.
Technical Report
TR99-8, Department of Computer Engineering, Chalmers University of Technology, Goteborg, Suecia,
1999.
[155] Tijms H. Understanding probability: Chance rules in everyday life.
Press, ISBN 0521540364,
Cambrigde University
Agosto 2004.
[156] Zhang Z. Y Shen H. Online training of SVMs for real-time intrusion detection.
Proceedings
of the International Conference on Advanced Information Networking and Applications
(AINA), Vol. 1, Pag. 568,
2004.
[157] D. R. Simon H. J. Wang, C. Guo and A. Zugenmaier. Shield: Vulnerability-driven network lters for preventing known vulnerability exploits.
SIGCOMM Conference,
In Proceedings of the 2004 ACM
August, 2004.
[158] Mannila H. y Smyth P. Hand D. Principles of data mining.
Cambridge, Massachusetts, USA,
MIT Press, ISBN 026208290X,
2001.
[159] R. Hastings and B. Joyce. Purify: Fast detection of memory leaks and access errors.
Procedings of the Winter USENIX Technical Conference, San Francisco, CA.,
In
January
1992.
[160] Maccabe A. y Servilla M. Heady R., Luger G. The architecture of a network level intrusion
detection system.
Mexico, USA,
Technical Report, Department of Computer Science, University of New
Agosto 1990.
[161] Levitt K. N. Mukherjee B. Wood J. y Wolber D. Heberlein L.T., Dias G.V. A network
security monitor.
Pag. 296-304,
Proceeding of the IEEE Symposium on Research in Security and Privacy,
Mayo 1990.
394
[162] Keromytis A. y Stolfo S. Heller K., Svore K. One class support vector machines for detecting
anomalous windows registry accesses.
Proceedings of the ICDM Workshop on Data Mining
for Computer Security (SMSEC), Melbourne, Florida, USA,
Noviembre 2003.
[163] Honavar V. Miller L. y Wang Y. Helmer G., Wong J. Lightweight agents for intrusion
detection.
Elsevier Journal of Systems and Software, No. 67, Pag. 109-122,
2003.
[164] S. Y. Ho. Intrusion detection systems for today and tomorrow. SANS Institute. Information
Security Reading Room,
2001.
[165] Meier M. y König H. Holz T. High-ecient intrusion detection infraestructure.
ture. DFN-Arbeitstagung über Kommunikationsnetze, 217-232,
Infrastruc-
2003.
[166] R.A. Howard and J. Matheson. Readings on the principles and applications of decision
analysis.
Strategic Decisions Group, Menlo Park,
1981.
[167] Liao Y. y Vemuri R. Hu W. Robust support vector machines for anomaly detection in
computer security.
Proceedings of the 2003 International Conference on Machine Learning
and Applications (ICMLA), Los Angeles, California, USA,
Junio 2003.
[168] G. Hunt and D. Brubacher. Detours: Binary interception of win32 functions.
Windows NT Symposium,
USENIX
1999.
[169] IETF. Internet engineering task force home page.
Disponible en http://www.ietf.org/,
2006.
[170] Kemmerer R. y Porras P. Ilgun K. State transition analysis: A rule-based intrusion detection approach.
IEEE Transactions on Software Engineering, Vol. 21, No. 3, Pag. 181-199,
1995.
[171] Enterasys Networks Incorporated. Enterasys dragon intrusion defense.
http://www.enterasys.com/products/ids/,
Disponible en
2006.
[172] Forrester Incorporated. Forrester research: Technology research and advice home page.
Disponible en http://www.forrester.com/,
2006.
[173] Gartner Incorporated. Gartner group: It research and analysis home page.
http://www.gartner.com/,
2006.
[174] Tripwire Incorporated. Tripwire change auditing solutions home page.
http://www.tripwire.com/,
Disponible en
Disponible en
2006.
[175] INOUE, Hiroaki Akihisa Ikeno, Masaki Kondo, Junji Sakai, and Masato Edahiro. Virtus:
A new processor virtualization architecture for security-oriented next-generation mobile
terminals.
System Devices Research Laboratories, NEC Corporation, 1120, Shimokuzawa,
Sagamihara, Kanagawa, 229-1198 Japan. - NEC Informatec Systems, Ltd. 3-2-1, Sakado,
Takatsu-ku, Kawasaki, Kanagawa, 213-0012 Japan,
395
July, 2006.
[176] Ulrich Ultes-Nitsche. Inseon Yoo. Adaptative detection of worm/viruses in rewalls.
partament of Informatics, University of Fribourg, Switzerland,
De-
2002.
[177] SANS Institute. SANS glossary of terms used in security and intrusion detection. Disponible
en http://www.sans.org/resources/glossary.php,
2005.
[178] Red Iris. Red española de investigación y desarrollo.
Disponible en http://www.rediris.es/,
2006.
[179] IWS.
Top 20 countries with the highest number of internet users.
http://www.internetworldstats.com/top20.htm,
[180] IWS.
World
internet
users
and
http://www.internetworldstats.com/stats.htm,
[181] IWS. Internet world stats home page.
Disponible en
2005.
population
stats.
Disponible
en
2005.
Disponible en http://www.internetworldstats.com/,
2006.
[182] Giron F. J. Regresión logística y análisis discriminante robustos: un enfoque bayesiano.
Universidad de Málaga,
2005.
[183] Luo J. Integrating fuzzy logic with data mining methods for intrusion detection.
Report, Mississippi State University,
Technical
1999.
[184] McHugh J. The 1998 licoln laboratory ids evaluation: A critique.
Proceedings of the 3th
International Workshop on Recent Advances in Intrusion Detection, Vol. 1907 of Lecture
Notes in Computer Science, Springer-Verlag, Tolouse, Francia,
Octubre 2000.
[185] Pearl J. Reverend bayes on inference engines: A distributed hierarchical approach.
ceedings of the AAAI National Conference on AI, Pag. 133-136, Pittsburgh, PA,
Pro-
Agosto
1982.
[186] Pearl J. Fusion, propagation and structuring in belief networks.
29:241 288,
Articial Intelligence,
1986.
[187] Pearl J. Probabilistic reasoning in intelligent systems: Networks of plausible inference.
Morgan Kaufmann, ISBN 1558604790,
Septiembre 1988.
[188] Pearl J. From conditional oughts to qualitative decision theory.
Proceedings of the 9th Con-
ference on Uncertainty in Articial Intelligence, Pag. 12-20, Washington, Morgan Kaufmann, San Mateo, California, USA,
1993.
[189] Pearl J. Causal diagrams for empirical research.
Biometrika, 82:669-710,
1995.
[190] Robins J. A new approach to causal inference in mortality studies with sustained exposure
results. mathematical modelling.
7:1393-1512,
396
1986.
[191] Schenier B. Y Kelsey J. Secure audit logs to support computer forensics. ACM Transactions
on Information and System Security, 2(2),
Mayo 1999.
[192] B. Ravichandran J. B. D. Cabrera and R. K. Mehra. Statistical trac modeling for network
intrusion detection.
In Proceedings of the Eighth International Symposium on Modeling,
Analysis, and Simulation of Computer and Telecommunications Systems, pages 466-473,
San Francisco, CA. IEEE Computer Society.,
August, 2000.
[193] B. Karp J. Newsome and D. Song. Ploygraph: Automatically generating signatures for
polymorphic worms.
In Proceedings of the IEEE Symposium on Security and Privacy,
May, 2005.
[194] S. Jha J. T. Gin and B. P. Miller. Detecting manipulated remote call streams.
Security Symposium.,
USENIX
August 2002.
[195] S. Jha J. T. Gin and B. P. Miller. Ecient context-sensitive intrusion detection.
Annual Network and Distributed System Security Symposium.,
11th
February 2004.
[196] Karygiannis T. y Marks D. Jansen W., Mell P. Mobile agents in intrusion detection
and response.
Proceedings of the 12th Annual Canadian Information Technology Security
Symposium, Ottawa, Canadá,
2000.
[197] S. L. Lauritzen Jensen F. V. and K. G. Olesen. Bayesian updating in causal probabilistic
networks by local computations.
Computational Statistics Quarterly 4, 269282,
1990.
[198] Scott M. Lewandowski Robert K. Cunningham Jesse C. Rabek, Roger I. Khazan. Detection
of injected, dynamically generated, and obfuscated malicious code.
of Technology, Lincoln Laboratory, 244 Wood Street, Lexington.,
Massachusetts Institute
October 2003.
[199] Lundy Lewis Joao B. D. Cabrera and Raman K. Mehra. Detection and classication of
intrusions and faults using sequences of system calls.
Scientic Systems Company, 500
West Cummings Park, Suite 3000. Woburn MA 01801 USA,
December, 2001.
[200] M. B. Jones. Interposition agents: Transparently interposing user code at the system
interface.
In Proceedings of the Symposium on Operating Systems Principles, pages 80 to
93, Asheville, NC.,
1993.
[201] Chongkyung Kil Yan Zhai Chris Bookholt Jun Xu, Peng Ning. Automatic diagnosis and
response to memory corruption vulnerabilities.
Cyber Defense Laboratory. Department of
Computer Science. North Carolina, State University,
[202] Gubbels K. Hands in the honeypot.
November, 2005.
SANS Institute Information Security Reading Room.
GIAC Security Essentials Certication (GSEC), Practical Assignment, Version 1.4b,
397
2002.
[203] Ilgun K. Ustat: A real-time intrusion detection system for unix.
Proceedings of the IEEE
Symposium on Research on Security and Privacy, Oakland, USA,
[204] Jackson K. Intrusion detection system product survey.
Mayo 1993.
Technical Report LA-UR-99-3883.
Distributed Knowledge Systems Team, Computer Research and Applications Group, Los
Alamos National Laboratory, New Mexico,
Junio 1999.
[205] Julisch K. Using root cause analysis to handle intrusion detection alarms.
IBM Zurich
Research Laboratory. Dissertation for the degree of Doctor of Philosophy, University of
Dortmund, Alemania,
2003.
[206] Murphy K. An introduction to graphical models.
Corporation,
TechnicalReport, Intel Research, Intel
Mayo 2001.
[207] Valdés A. Y Skiner K. Probabilistic alert correlation.
Proceedings of the 4th International
Symposium on Recent Advances in Intrusion Detection, Pag. 54-68,
2001.
[208] Staniford-Chen S. y Tung B. Kahn C., Porras P. A common intrusion detection framework.
Journal of Computer Security,
Julio 1998.
[209] Tierney L. Kass, R. and J. Kadane. Asymptotics in bayesian computation.
In Bernardo,
J., DeGroot, M., Lindley, D., and Smith, A., editors, Bayesian Statistics 3, pages 261-278.
Oxford University Press,
1988.
[210] H. A. Kim and B. Karp. Autograph: Toward automated, distributed worm signature
detection.
In Proceedings of the 13th Usenix Security Symposium,
August, 2004.
[211] Nguyen H. y Park J. Kim D. Genetic algorithm to improve svm based network intrusion detection system.
Proceedings of the 19th International Conference on Advanced Information
Networking and Applications (AINA), Vol. 2, Pag. 155-158,
2005.
[212] Samuel T. King and Peter M. Chen. Backtracking intrusions.
Engineering and Computer Science. University of Michigan,
Department of Electrical
February, 2005.
[213] Ruschitzka M. y Levitt K. Ko C. Execution monitoring of security-critical programs in
distributed systems: A specication-based approach.
posium on Security and Privacy, Oakland, USA,
Proceedings of the 1997 IEEE Sym-
1997.
[214] C. Kreibich and J. Crowcroft. Honeycomb - creating intrusion detection signatures using
honeypots. In Proceedings of the Second Workshop on Hot Topics in Networks (HotNets-II),
November, 2003.
[215] Robertson W. y Valeur F. Krügel C., Mutz D. Bayesian event classication for intrusion
detection.
Vegas,
Proceedings of the 19th Annual Computer Security Applications Conference, Las
Diciembre 2003.
398
[216] Vigna G. y Kemmerer R. Krügel C., Valeur F. Stateful intrusion detection for high-speed
networks.
Proceedings of the IEEE Symposium on Security and Privacy, IEEE Press, Pag.
285-293, Oakland, USA,
Mayo 2002.
[217] G. Krügel. C, Vigna. Anomaly detection of web-based attacks.
University of California, Santa Barbara,
Reliable Software Group,
2003.
[218] R. Kuster. Three ways to inject your code into another process. 2003.
[219] Me L. Gassata, a genetic algorithm as an alternative tool for security audit trails analysis.
First International Workshop on the Recent Advances in Intrusion Detection, Louvain-laNeuve, Belgica,
Septiembre 1998.
[220] Skoudis E. Y Zeltser L. Malware: Fighting malicious code.
ISBN 0131014056,
Prentice Hall, Primera Edición,
Noviembre 2003.
[221] Spitzner L. Honeypots: Tracking hackers.
Addison-Wesley Professional, ISBN 0321108957,
2002.
[222] Kaspersky Lab. Premier protection against viruses, hackers and spam.
http://www.kaspersky.com/,
Disponible en
2006.
[223] L. C. Lam and T. Chiueh. Automatic extraction of highly accurate application-specic
sandboxing policy.
In Seventh International Symposium on Recent Advances in Intrusion
Detection, Sophia Antipolis, French Riviera, France.,
September 2004.
[224] Lap-Chung Lam, Wei Li, and Tzi cker Chiueh. Accurate and automated system call policybased intrusion prevention.
2006 International Conference on Dependable Systems and Ne-
tworks (DSN 2006), 25-28 June 2006, Philadelphia, Pennsylvania,USA, Proceedings .IEEE
Computer Society,
2006.
[225] J. Larus and E. Schnarr. Eel: Machine-independent executable editing. In Proceedings of the
ACM SIGPLAN '95 Conference on Programming Language Design and Implementation,
La Jolla, CA.,
June 1995.
[226] Dawson R. Lavori P.W. and Shera D. A multiple imputation strategy for clinical trials
with truncation of patient data.
Statistics in Medicine, 14, 19131925,
1995.
[227] Kumar V. Ozgur A. y Srivastava J. Lazarevic A., Ertoz L. A comparative study of anomaly
detection schemes in network intrusion detection.
Mining,
SIAM International Conference on Data
Mayo 2003.
[228] Chan P. Eskin E. Fan W. Miller M. Hershkop S. y Zhang J. Lee W., Stolfo S. Real time
data mining-based intrusion detection.
Proceedings of the second DARPA Information
Survivability Conference and Exposition,
2001.
399
[229] Stolfo S. y Mok K. Lee W. A data mining framework for building intrusion detection
models.
Proceedings of the IEEE Symposium on Security and Privacy, Pag. 120-132,
1999.
[230] Tseng S. y Lin S. Lin Y. An intrusion detection model based upon intrusion detection
markup languaje (idml).
Department of Computer and Information Science, National
Chiao Tung University, Taiwan,
Agosto 2001.
[231] U. Lindqvist and P. Porras. Detecting computer and network misuse with the production based expert system toolset (p-best).
Oakland, CA. 146-161.,
In IEEE Symposium on Security and Privacy.
1999.
[232] Fried D. Korba J. y Das K. Lippmann R., Haines J. The 1999 darpa o-line intrusion
detection evaluation.
Computer Networks, Vol. 34(4):579-595, Elsevier Science,
Octubre
2000.
[233] Zhen Liu and Susan M. Bridges. Dynamic learning of automata from the call stack log for
anomaly detection.
University,
Department of Computer Science and Engineering. Mississippi State
April, 2005.
[234] Cohn R. Muth R. Patil H. Klauser A. Lowney G. Wallace S. Reddi V. J. Luk, C. and
K. Hazelwoo. Pin: Building customized program analysis tools with dynamic instrumentation.
ACM SIGPLAN Conference on Programming Language Design and Implementation
(PLDI), Chicago, IL, USA, pp. 190?200.,
2005.
[235] T. F. Lunt. Detecting intruders in computer systems.
In Proceedings of the Sixth Annual
Symposium and Technical Displays on Physical and Electronic Security,,
1993.
[236] Teresa F. Lunt and R. Jagannathan. A prototipe real-time intrusion-detection expert
system.
IEEE Symposium on Security and Privacy,,
1988.
[237] Gilham F. Jagannathan R. Newumann P. y Jalali C. Lunt T., Tamaru A. Ides: A progress
report.
Proceedings of the 6th Annual Computer Security Applications Conference,
[238] Llorens M. Redes recongurables. modelizacion y vericacion.
1990.
Tesis Doctoral, Depar-
tamento de Sistemas Informaticos y Computacion, Universidad Politecnica de Valencia,
2003.
[239] Olmsted Scott M. On representing and solving decision problems.
Ph.D. thesis, Stanford
University, Department of Engineering-Economic Systems, Stanford, CA,
[240] Ranum M. Coverage in intrusion detection systems.
Incorporated Technical Publication,
Technical Publication. NFR Security
Junio 2001.
[241] Ranum M. Experiences benchmarking intrusion detection systems.
porated Technical Publication,
Diciembre 1983.
Diciembre 2001.
400
NFR Security Incor-
[242] Roesch M. Snort: Lightweight intrusion detection for networks.
13th Systems Administration Conference, Pag. 229-238,
Proceedings of LISA'99:
Noviembre 1999.
[243] Roesch M. Next-generation intrusion prevention: The pre-attack period. 2005. Disponible
en http://searchsecurity.techtarget.com/tip/1289483sid14gci112130700.html.
[244] Ye N. Y Xu M. Probabilistic networks with undirected links for anomaly detection.
Works-
hop on Information Assurance and Security, Proceedings of the IEEE, Pag. 175-179,
2000.
[245] N. Fakotakis G. Kokkinakis M. Maragoudakis, E. Kavallieratou. How conditional independence assumption aects handwritten character segmentation.
and Computer Engineering, University of Patras, Greece,
Department of Electrical
2000.
[246] Carla Marceau. Characterizing the behavior of a program using multiple-length n-grams.
Odyssey Research Associates. Ithaca, NY 14850,
February, 2001.
[247] Jose Ignacio Sánchez Martín. Técnicas de modelado de llamadas al sistema como aproximación a la detección de intrusiones en sistemas gnu/linux, microsoft windows 2000/xp y
microsoft windows mobile. 2006.
[248] Wes Masri and Andy Podgurski. Using dynamic information ow analysis to detect attacks against applications.
Computer Science Department. American University of Beirut.
Beirut, Lebanon 1107 2020 - Electrical Engineering and Computer Science Department.
Case Western Reserve University. Cleveland, OH 44106,
May, 2005.
[249] Lippmann R. Haines J. y Zissman M. Mell P., Hu V. An overview of issues in testing intrusion detection systems.
Technical report, National Institute of Standards and Technology,
Massachusetts Institute of Techonology Lincoln Laboratory, USA,
[250] M. Miller. Understanding windows shellcode.
nologin,
Junio 2003.
2003.
[251] MIT. Massachusetts institute of technology home page. Disponible en http://www.mit.edu/,
2006.
[252] Trevor Jim Richard Schlichting Mohan Rajagopalan, Matti Hiltunen. Authenticated system calls.
Department of Computer Science, The University of Arizona. AT and T Labs-
Research, 180 Park Avenue,
July, 2006.
[253] Savage S. Shannon C. Staniford-Chen S. y Weaver N. Moore D., Paxson V. The spread of
the sapphire/slammer worm.
IEEE Security and Privacy, Vol 1, N. 4,
Julio-Agosto 2003.
[254] Shannon C y Brown J. Moore D. Code-red: A case study on the spread and victims of an
internet worm.
Internet Measurement Workshop (IMW),
401
2002.
[255] Heberlein T. y Levitt K. Mukherjee B. Network intrusion detection.
8(3):26-41,
IEEE Network,
Junio 2004.
[256] Sung A. y Abraham A. Mukkamala S. Intrusion detection using an ensemble of intelligent
paradigms.
Science,
Journal of Network and Computer Applications, No. 28, Pag. 167-182, Elsevier
2005.
[257] N. Nethercote and J. Seward. Valgrind: A program supervision framework. In 3rd Workshop
on Runtime Verication,
2003.
[258] P. G. Neumann and P. A. Porras. Experience with emerald to date.
Usenix Workshop on Intrusion Detection,
In Proceedings of the
1999.
[259] James Newsome and Dawn Song. Dynamic taint analysis for automatic detection, analysis,
and signature generation of exploits on commodity software.
In Proceedings of the 12th
Annual Network and Distributed System Security Symposium (NDSS),
[260] NIST.
2005.
National institute of standards and technology home page.
http://www.nist.gov/,
Disponible en
2006.
[261] Novell. Linux audit-subsystem design documentation for kernel 2.6. 2004.
[262] NSA. National security agency home page.
Disponible en http://www.nsa.gov/,
[263] University of California. Lawrence livermore national laboratory home page.
en http://www.llnl.gov/,
2006.
Disponible
2006.
[264] University of California Davis. University of california davis home page.
http://www.ucdavis.edu/,
Disponible en
2006.
[265] CSO. Computer Security Ocer.
http://www.csoonline.com,
2005 e-crime watch survey.
Disponible
en
2005.
[266] Lauritzen S. y Jensen F. Olesen K. ahugin: A system creating adaptive causal probabilistic
networks.
Dubois et al. Eds, Pag. 223-229,
1992.
[267] United Nations. United Nations Conference on Trade and Development. E-commerce and
development report 2002. 2002.
[268] United Nations. United Nations Conference on Trade and Development. E-commerce and
development report 2004. 2004.
[269] A. One. Smashing the stack for fun and prot.
Phrack, 7(49):14,
[270] William Osser. Auditing in the solaris8 operating environment.
402
1996.
Sun BluePrints,
2002.
[271] Inella P. The evolution of intrusion detection systems.
http://www.securityfocus.com/infocus/1514,
2001. Security Focus. Disponible en
2001.
[272] Proctor P. Computer misuse detection system (cmds) concepts.
International Corporation (SAIC), Technical Paper,
Science Applications
1996.
[273] Wellman M. P. Fundamental concepts of qualitative probabilistic networks.
Intelligence, 44:257 303,
1990.
[274] Wellman M. P. Graphical inference in qualitative probabilistic networks.
701,
Articial
Networks, 20:687
1990.
[275] Winston P. Articial intelligence.
ción, ISBN 0201533774,
Addison Wesley, Reading, Massachusetts, Tercera Edi-
Enero 1992.
[276] K. Fraser S. Hand T. Harris A. Ho R. Neugebauer I. Pratt P. Barham, B. Dragovic and
A. Wareld. Xen and the art of virtualization.
Operating Systems Principles,
In Proceedings of the 2003 Symposium on
October, 2003.
[277] V. Paxson. Bro: A system for detecting network intruders in real-time.
7th USENIX Security Symposium. San Antonio, TX,
In Proceedings of
1998.
[278] Shachter R. D. Peot M.A. Fusion and propagation with multiple observations in belief
networks.
Articial Intelligence, 48:299318,
1991.
[279] J. Picciotto. The desing of an eective auditing subsystem.
Bedford, Massachusetts,
The MITRE Corporation,
1978.
[280] Elo J. y Venter H. Pillai M. An approach to implement a network intrusion detection
system using genetic algorithms.
Proceedings of the 2004 annual research conference of the
South African institute of computer scientists and information technologists on IT research
in developing countries, ACM International Conference Proceedings Series, Vol. 75,
2004.
[281] Uday Joshi Prem Uppuluri and Arnab Ray. Preventing race condition attacks on lesystems.
Dept. of Computer Science University of Missouri at Kansas City, MO, 641 10 -
Dept. of Computer Science State University of New York Stony Brook, NY, 11790,
[282] The Honeynet Project.
Know your enemy: Trend analysis.
http://honeynet.org/papers/kye.html,
2005.
Disponible
en
2004.
[283] The Honeynet Project. To learn tools, tactics and motives involved in computer and
network attacks, and share the lessons learned.
2006.
403
Disponible en http://project.honeynet.org/,
[284] Jeerson Provost. Naive bayes vs rule-learning in classication of email.
Computer Sciences, University of Texas, Austin,
Departmen of
1999.
[285] Xueyao Li Qingbo yin, Rubo Zhang. An new intrusion detection method based on linear
prediction.
2002 Symposium on Applications and the Internet,
2002.
[286] Johnston. S. R. The impact of privacy and data protection legislation on the sharing of
intrusion detection information.
In Proceedings of the 4th International Symposium on
Recent Advances in Intrusión Detection, Lecture Notes in Computer Science,
[287] Shachter R. Probabilistic inference and inuence diagrams.
Pag. 589-604,
[288] Shirey R.
2212, 2001.
Operations Research, No. 36,
1988.
Internet security glossary.
Internet RFC 2828. The Internet Society, Ne-
twork Working Group, GTE/BBN Technologies. Disponible en http://www.ietf.org/rfc/
/rfc2828.txt,
Mayo 2000.
[289] J. Gagnon R. K. Mukkamala and S. Jajodia. Integrating data mining techniques with
intrusion detection.
In V. Atluri and J. Hale, editors, Research Advances in Database and
Information Systems Security, pages 33-46. Kluwer Publishers,
2000.
[290] L. R. Rabiner. A tutorial on hidden markov models and selected applications in speech
recognition.
Proceedings of the IEEE, 77(2).,
1989.
[291] L. R. Rabiner and B. H. Juang. An introduction to hidden markov models.
Magazine, pages 4 to 16, Jannuary.,
IEEE ASSP
1986.
[292] RaiSe. Lkm rootkits en linux x86 v2.6.
enye-sec,
2005.
[293] Jan Vitek Rajeev Gopalakrishna, Eugene H. Spaord. Ecient intrusion detection using
automaton inlining.
Center for Education and Research in Information Assurance and
Security. Department of Computer Sciences. Purdue University,
May, 2005.
[294] Stolarchuk M. Sienkiewicz M. Lambeth A. y Wall E. Ranum M., Landeld K. Implementing
a generalized tool for network monitoring.
Conference, San Diego, California, USA,
Proceedings of the 11th Systems Administration
Octubre 1997.
[295] Red.es. Entidad pública empresarial red.es.
Disponible en http://red.es/,
2006.
[296] Cordis. Community Research and Development Information Service. Information society
technologies.
Disponible en http://www.cordis.lu/fp6/ist.htm,
2006.
[297] NATO Research and Technology Organisation. Intrusion detection: Generics and state-ofthe-art.
Technical Report 49,
2002.
404
[298] John Muray Reuter.
Inside Windows CE.
Microsoft Press, 1998.
[299] Culbert C. Donell B. Ly B. Ortiz C. Giarrantano J. y López F. Riley G., Savely R. Clips:
A tool for building expert systems.
Disponible en http://www.ghg.net/clips/CLIPS.html,
2005.
[300] Little R.J.A. and Rubin D.B. Statistical analysis with missing data.
York,
J. Wiley & Sons, New
1987.
[301] D.B. Rubin. Multiple imputation for nonresponse in surveys.
Sons, Inc.,
New York: John Wiley &
1987.
[302] Koller D. y Kanazawa K. Russellm S., Binder J. Local learning in probabilistic networks
with hidden variables.
In Proceedings of the Fourteenth International Joint Conference
on Articial Intelligence, Montreal, QU, pages 1146-1152. Morgan Kaufmann, San Mateo,
CA,
1995.
[303] Gould S. The structure of evolutionary theory.
0674006135,
Belknap Press, Primera edición, ISBN
Marzo 2002.
[304] Kumar S. Classication and detection of computer intrusions.
degree of Doctor of Philosophy, Purdue University, USA,
Thesis submitted for the
Agosto 1995.
[305] Scott S. A bayesian paradigm for designing intrusion detection systems.
Computational
Statistics and Data Analysis, Elsevier Science, Vol. 45, Issue. 1, Pag. 69-83,
[306] Smaha S. Haystack: An intrusion detection system.
Febrero 2004.
Proceedings of the 4th Aerospace
Computer Security Applications Conference, Orlando, FL,
Diciembre 1988.
[307] Smaha S. Y Snapp S. Method and system for detecting intrusion into and misuse of a data
processing system.
US 555742, US Patent Oce,
Septiembre 1996.
[308] Stolcke A. Y Omohundro S. Inducing probabilistic grammars by bayesian model merging.
Proceedings of the 1994 International Conference on Grammatical Inference, Pag. 999,
1994.
[309] S. Forrest S. A. Hofmeyr and A. Somayaji. Intrusion detecction using sequences of system
calls.
Journal of Computer Security, 6:151 to 180.,
1998.
[310] L. Allen R. Cherukuri S. Forrest, A.S. Perelson. Self-nonself discrimination in a computer.
IEEE Symposium on Security and Privacy,
1994.
[311] S.W. Boyd S. Sidiroglou, M.E. Locasto and A.D. Keromytis. Building a reactive immune
system for software services.
pages 149 - 161,
In Proceedings of USENIX Annual Technical Conference,
April, 2005.
405
[312] G. Varghese S. Singh, C.Estan and S. Savage. Automated worm ngerprinting.
In Procee-
dings of the 6th ACM/USENIX Symposium on Operating System Design and Implementation (OSDI),
December, 2004.
[313] Pablo Garaizar Sagarminaga. Linux 2.6 kernel hacking.
hackAndalus,
2004.
[314] Barbery F. Salido M.A. Stochastic local search for distributed constraint satisfaction
problems.
Universidad de Alicante, Universidad de Valencia,
[315] Querty Sandman. Pe infection under w32.
29a ezine,
2003.
1996.
[316] J.L. Schafer. Analysis of incomplete multivariate data.
New York: Chapman and Hall,
1997.
[317] Hanna M. Y Whitehurst R. Sebring M., Shellhouse E. Expert systems in intrusion detection, a case study.
Baltimore, USA,
Proceedings of the 11th National Computer Security Conference,
1988.
[318] Abdallah Abbey Sebyala, Temitope Olukemi, and Dr. Lionel Sacks. Active platform security through intrusion detection using naïve bayesian network for anomaly detection.
Departament of Electronic and Electrical Engineering, University Colleage London, Torrington Place, England, UK.,
2002.
[319] R. Sekar, M. Bendre, P. Bollineni, and D. Dhurjati. A fast automaton-based method for
detecting anomalous program behaviors.
144 to 155.,
IEEE Symposium on Security and Privacy, pages
2001.
[320] Pierce L. Y Matzner S. Sinclair C. An application of machine learning to network intrusion.
Proccedings of the 15th Annual Computer Security Applications Conference (ACSAC), Pag.
371,
1999.
[321] A. Smirnov and T. Chiueh. Dira: Automatic detection, identication, and repair of controlhijacking attacks.
In Proceedings of The 12th Annual Network and Distributed System
Security Symposium (NDSS '05),
February, 2005.
[322] Dias G. Goan T. Heberlein T. Ho C. Levitt K. Mukherjee B. Smaha S. Grance T. Teal D.
Y Mansur D. Snapp S., Brentano J. DIDS (distributed intrusion detection system) - motivation, architecture, and an early prototype.
Security Conference, Washington, DC,
Proceedings of the 14th National Computer
Octubre 1991.
[323] Snort. Snort: The facto standard for intrusion Detection/Prevention home page.
en http://www.snort.org/,
Disponible
2006.
[324] Panda Software. Protection against viruses, spyware, hackers, spam and other internet
threats.
Disponible en http://www.pandasoftware.com/,
406
2006.
[325] Hofmeyr S. Y Forrest S. Somayaji A. Principles of a computer immune system.
Proceedings
of the 1997 Meeting on New Security Paradigms, Pag. 75-82, Langdale, UK,
Septiembre
1997.
[326] Glymour C. Y Scheines R. Spirtes P. Causation, prediction and search.
MIT Press,
Adaptative Computation and Machine Learning, Segunda Edición, ISBN 0262194406,
[327] SRI. Stanford research institute home page.
Disponible en http://ww.sri.com/,
2000.
2006.
[328] A. Srivastava and A. Eustace. Atom - a system for building customized program analysis
tools.
In Proceesings of the Symposium on Programming Language Design and Implemen-
tation, pages 196 to 205, Orlando, FL.,
1994.
[329] R. Stallman. The free software foundation home page.
Disponible en http://www.fsf.org/,
2006.
[330] Cheung R. Crawford R. Dilger M. Frank J. Hoagland J. Levitt K. Wee C. Yip R. Y Zerkle D.
Staniford-Chen S., Chen S. GrIDS - a graph-based intrusion detection system for large
networks.
Proceedings of the 19th National Information Systems Security Conference,
1996.
[331] Hoagland J. Y Mc Alerney J. Staniford-Chen S. Practical automated detection of stealthy
portscans.
Proceedings of the 7th ACM Conference on Computer and Communications
Security, Atenas, Grecia,
2000.
[332] Paxson V. Y Weaver N. Staniford-Chen S., Moore D. The top speed of ash worms.
Proceedings of the ACM Workshop on Rapid Malcode (WORM),
2004.
[333] European Statistical Data Support. Internet usage by individuals and enterprises 2004.
Disponible en http://www.europa.eu.int/comm/eurostat/,
2005.
[334] Internet Security Systems. The evolution of intrusion detection technology.
White Paper,
Agosto 2001.
[335] Internet Security Systems.
http://www.iss.net/,
Real secure server sensor home page.
Disponible en
2006.
[336] Goeldenitz T. Ids today and tomorrow.
Room,
ISS Technical
SANS Institute Information Security Reading
Enero 2002.
[337] Holland T. Understanding ips and ids: Using ips and ids together for defense in depth.
SANS Institute Information Security Reading Room,
[338] Kohonen T. Self-organizing maps.
Febrero 2004.
Springer-Verlag, Berlin,
407
1997.
[339] Lane T. Machine learning techniques for the computer security domain of anomaly detection.
Thesis submitted for the degree of Doctor of Philosophy, Purdue University, USA,
Agosto 2000.
[340] Toth T. Improving intrusion detection systems.
Dissertation submitted for the degree of
Doctor of Philosophy, University of Vienna, Austria,
2003.
[341] Wickham T. Intrusion detection is dead. long live to intrusion prevention!
Information Security GIAC Certication Practical, version GSEC 1.4b,
Abril 2003.
[342] Wickman T. Intrusion detection is dead. long live to intrusion prevention!
Information Security GIAC Certication Practical,
SANS Institute
SANS Institute
2003.
[343] C.E. Brodley T. Lane. Sequence matching and learning in anomaly detection for computer
security. AAAI Workshop: AI Approaches to Fraud Detection and Risk Management, pp.4949,
1997.
[344] C.E. Brodley T. Lane. Temporal sequence learning and data reduction for anomaly detection.
ACM Trans. Information and System Security, vol. 2, no. 3, pp. 295-331,
1999.
[345] D. Lee A. Wolman W. Wong H. Levy T. Romer, G. Voelker and B. Bershad. Instrumentation and optimization of win32/intel executables using etch.
Workshop, Seattle, WA.,
In USENIX Windows NT
1997.
[346] K. Tan and R. Maxion. Why 6?? dening the operational limits of stide, an anomaly
based intrusion detector.
Oakland, CA. 188-202,
In Proceedings of the IEEE Symposium on Security and Privacy.
2002.
[347] K. Tan and R. Maxion. Determining the operational limits of an anomaly-based intrusion
detector.
IEEE Journal on selected areas in communications, 21(1):96?110.,
Jan. 2003.
[348] K. Tan, J. Mchugh, and K. Killourhy. Hiding intrusions: From the abnormal to the normal
and beyond.
In Proceedings of Information Hiding,
pages 117, 2002.
[349] Steinbach M. Y Kumar V. Tan P. Introduction to data mining.
Edición, ISBN 0321321367,
Addison Wesley, Primera
Mayo 2005.
[350] M.A. Tanner and W.H. Wong. The calculation of posterior distributions by data augmentation.
Journal of the American Statistical Association, 82: 528-549,
1987.
[351] CERT/In Indian Computer Emergency Response Team. Ids - intrusion detection system.
CERT/In Security Guideline CISG-2003-06,
2003.
[352] Security Telecommunications and Information Systems Security Committee. National information systems security glossary. 2000.
408
[353] Chen K. Y Lu S. Teng H. Adaptative real-time anomaly detection using inductively generated sequential patterns.
Proceedings of the 1990 IEEE Symposium on Research in Security
and Privacy, Oakland, USA,
Mayo 1990.
[354] D. Thain and M. Livny. Multiple bypass: Interposition agents for distributed computing.
Journal of Cluster Computing, 4(1):39 to 47.,
March 2001.
[355] B Thiesson. Accelerated quantication of bayesian networks with incomplete data.
In
Proceedings of First International Conference on Knowledge Discovery and Data Mining,
Montreal, QU, pages 306-311. Morgan Kaufmann,
[356] T.Hurman. Exploring windows ce shellcode.
[357] Open Source Tripwire.
1995.
Pentest,
2005.
Open source tripwire home page.
http://sourceforge.net/projects/tripwire/,
Disponible
en
2006.
[358] Lindqvist U. On the fundamentals of analysis and detection of computer misuse.
Thesis for
the degree of Doctor of Philosophy, Chalmers University of Technology. Göteborg, Suecia,
1999.
[359] International Telecommunication Union. Internet indicators: Hosts, users and number of
pcs.
Disponible en http://www.itu.int/ITU-D/ict/statistics/,
[360] Stanford University. Stanford encyclopedia of philosophy.
2005.
Consulta del término "Bayes'
Theorem". Disponible en http://plato.stanford.edu/entries/bayes-theorem/,
[361] Stanford University. Stanford encyclopedia of philosophy.
Consulta del término "Boolean
Algebra". Disponible en http://plato.stanford.edu/entries/boolalg-math/,
[362] USAF. United states air force home page.
2006.
2006.
Disponible en http://www.af.mil/,
2006.
[363] USSS. United states secret service home page. Disponible en http://www.secretservice.gov/,
2006.
[364] Mahoney M. V. and Chan P.K. Learning rules for anomaly detection of hostile network
trac. 2001.
[365] Vapnik V. The nature of statistical learning theory.
Springer-Verlag, ISBN 0387945598,
1995.
[366] Amit Vasudevan and Ramesh Yerraballi. Spike: Engineering malware analysis tools using
unobtrusive binary-instrumentation.
Department of Computer Science and Engineering.
University of Texas at Arlington, Box 19015, 416 Yates St., 300 Nedderman Hall, Arlington, TX 76019-0015, USA. Box 19015, 416 Yates St., 300 Nedderman Hall, Arlington, TX
76019-0015, USA.,
January, 2006.
409
[367] Eckman S. Y Kemmerer R. Vigna G. The STAT tool suite.
IEEE Press, Hilton Head, South Carolina,
Proceedings of DISCEX 2000,
Enero 2000.
[368] Li W. Using genetic algorithm for network intrusion detection.
Proceedings of the United
States Department of Energy Cyber Security Group 2004 Training Conference, Kansas
City, USA,
Mayo 2004.
[369] K. Mok W. Lee, S.J. Stolfo. A data mining framework for building intrusion detection
models.
IEEE Symposium on Security and Privacy,
1999.
[370] S. Stolfo W. Lee and K. Mok. Adaptive intrusion detection: A data mining approach.
Articial Intelligence Review,
December, 2000.
[371] D. Wagner and D. Dean. Intrusion detection via static analysis.
In Proceedings of the
IEEE Symposium on Security and Privacy. IEEE Press, Oakland, CA.,
2001.
[372] D. Wagner and P. Soto. Mimicry attacks on host-based intrusion detection systems.
In
Proceedings of the 9th ACM Conference on Computer and Communications Security. Washington DC. 255-264,
2002.
[373] Wagner T. Y Wolstenholme P. Wagner F., Schmuki R. Modelling software with nite state
machines: A practical approach.
Auerbach Publications, ISBN 0849380863,
Mayo 2006.
[374] Forrest S. Warrender, C. and B. Pearlmutter. Detecting intrusions using system calls:
Alternative data models.
In Proceedings of the IEEE Symposium on Security and Privacy.,
1999.
[375] Stephanie Forrest Warrender, Christina and Barak Pearlmutter. Detecting intrusions using
system calls: Alternative data models.
IEEE Synposium on security and privacy,
1999.
[376] Mahoney M. y Chan P. Phad: Packet header anomaly detection for identifying hostile
network trac.
Florida Tech. Techical Report,
Abril 2001.
[377] Gómez J. y Dasgupta D. Evolving fuzzy classiers for intrusion detection.
Proceedings
of the 2002 IEEE Workshop on Information Assurance, United States Military Academy,
West Point, Ney York, USA,
Junio 2001.
[378] Hou H. y Dozier G. Immunity-based intrusion detection system design, vulnerability analysis, and genertia's genetic arms race.
Proceedings of the 2005 ACM Symposium on Applied
Computing, Pag. 952-956, Santa Fe, New Mexico, USA,
2005.
[379] Lundin E. y Jonsson E. Setting the scene for intrusion detection.
Technical Report 04-
05. Department of Computer Engineering, Chalmers University of Technology. Göteborg,
Suecia,
Agosto 2004.
410
[380] Kantzavelou I. y Katsikas S. An attack detection system for secure computer systems outline of the solution.
Proceedings of the IFIP TC11 13th International Conference on
Information Security, Copenhagen, Dinamarca,
Mayo 1997.
[381] Porras P. y Kemmerer R. Penetration state transition analysis - a rule-based intrusion
detection approach.
Eighth Annual Computer Security Applications Conference, Pag. 220-
229, IEEE Computer Society Press,
Diciembre 1992.
[382] Ryan J. y Lin M. Intrusion detection with neural networks. Advances in Neural Information
Processing Systems, No. 10, MIT Press, Cambridge, Massachusetts, USA,
[383] Garvey T. y Lunt T. Model based intrusion detection.
Computer Security Conference, Pag. 372-385,
1998.
Proceedings of the 14th National
Octubre 1991.
[384] Porras P. y Neumann P. Emerald: Event monitoring enabling responses to anomalous live
disturbances.
Proceddings of the 20th NIST-NCSC National Information Systems Security
Conference, Pag. 353-365,
1997.
[385] Ptacek T. y Newsham T. Insertion, evasion and denial of service: Eluding intrusion detection.
Technical Report, Secure Networks Incorporated,
Enero 1998.
[386] Russell S. y Norvig P. Articial intelligence: A modern approach.
Hall, ISBN 0137903952,
Second Edition, Prentice
Diciembre 2002.
[387] Giarratano J. y Riley G. Expert systems: Principles and programming.
Cuarta Edicion, ISBN 0534384471,
Course Technology,
Octubre 2005.
[388] Jones A. y Sielken R. Computer system intrusion detection: A survey.
Computer Science Department, University of Virginia,
Technical Report,
2000.
[389] Kim G. y Spaord E. The design and implementation of tripwire: A le system integrity
checker.
ACM Conference on Computer and Communications Security, Pag. 18-29,
1994.
[390] Kumar S. y Spaord E. An application of pattern matching in intrusion detection. Technical
Report 94-013, Department of Computer Science, Purdue University,
Marzo 1994.
[391] Kumar S. y Spaord E. A pattern matching model for misuse intrusion detection.
dings of the 7th National Computer Security Conference, Baltimore, USA,
Procee-
Octubre 1994.
[392] Lauritzen S. y Spiegelhalter D. Local computations with probabilities on graphical structures and their application to expert systems.
Journal of the Royal Statistical Society, Series
B (Methodological), No. 50, Vol. 2, Pag. 157-224,
1988.
[393] Lee W. y Stolfo S. Data mining approaches for intrusion detection.
USENIX security symposium, Pag. 79-93, San Antonio, USA,
411
Proceedings of the 7th
Enero 1998.
[394] Mukkamala S. y Sung A. A comparative study of techniques for intrusion detection.
Proceedings of the 15th IEEE International Conference on Tools with Articial Intelligence
(ICTAI), Pag. 570,
2003.
[395] Liepins G. y Vaccaro H. Intrusion detection: Its role and validation.
Computers and
Security, Vol. 11, Pag. 347-355, Elsevier Science Publishers Limited, Oxford, UK,
[396] Javitz H. y Valdés A. The sri ides statistical anomaly detector.
IEEE Symposium on Research in Security and Privacy,
Proceedings of the 1991
Mayo 1991.
[397] Pearl J. y Verma T. A statistical semantics for causation.
2, Pag. 91-95,
1992.
Statistics and Computing, Vol.
1992.
[398] Kemmerer R. y Vigna G. Intrusion detection: A brief history and overview.
Reliable
Software Group, Computer Science Department, University of California Santa Barbara,
2002.
[399] Meyer T. y Whateley B. Spambayes: Eective open-source, bayesian based, email classication system.
Proceedings of the 2004 Conference on Email and Anti-Spam (CEAS),
Mountain View, California, USA,
Julio 2004.
[400] Yang C. Yuan. Multiple imputation for missing data: Concepts and new development.
Institute Inc., Rockville, MD,
SAS
1997.
[401] Jingyu Zhou and Giovanni Vigna. Detecting attacks that exploit application-logic errors
through application-level auditing.
University of California Santa Barbara, USA,
2004.
[402] Amitabha Das Zhuowei Li. Visualizing and identifying intrusion context from system
calls trace.
Proceedings of the 20th Annual Computer Security Applications Conference
(ACSAC'04), IEEE Computer Society,
December 2004.
412