Sistema de Detección de Intrusos basado en Redes Neuronales.

INSTITUTO TECNOLOGICO DE COSTA RICA
DEPARTAMENTO DE COMPUTACION
PROGRAMA DE MAESTRIA
Sistema de detección de intrusos sobre la red
basado en redes neuronales
Tesis para optar al grado de
Magister Scientiae en Computación
Herson Esquivel Vargas
Cartago, Costa Rica
Junio, 2012
ii
Aprobación de Tesis
Sistema de detección de intrusos
sobre la red basado en
redes neuronales
Tribunal Examinador
_____________________
_____________________
Arnoldo Rodríguez, Ph.D.
Lector externo
Alexander Valerín, M.Sc.
Lector interno
_____________________
Luis Carlos Loaiza, M.Sc.
Profesor asesor
_____________________
Edwin Aguilar, Ph.D.
Director Maestría
iii
Resumen
La presente investigación se enfoca en el tema de la
seguridad informática, específicamente en la detección de
intrusos sobre la red.
Este
documento
incluye
una
revisión
general
de
la
bibliografía referente a los sistemas de detección de
intrusos,
en
sus
diferentes
formas
de
aplicación
e
implementación.
El objetivo primordial de un sistema de detección de intrusos
basado en anomalías, es lograr identificar si se está
realizando un ataque, independientemente de si se trata de un
ataque nuevo o previamente conocido. Para poder llegar a esta
conclusión, los sistemas utilizan distintas herramientas
matemáticas, de inteligencia artificial o de minería de
datos.
En el prototipo desarrollado como parte de esta investigación
se utilizaron redes neuronales de perceptrones multicapa, de
propagación hacia atrás.
Los principales aportes de esta investigación son: (1) la
aplicación de las redes neuronales como mecanismo de
detección de intrusos en tiempo real; (2) la utilización de
módulos
débilmente
acoplados
que
usan
mensajes
para
comunicarse y que facilitan la futura experimentación con
otros mecanismos de detección sin necesidad de reimplementar
la totalidad del sistema; (3) la ejecución distribuida de sus
componentes le brinda al sistema una escalabilidad superior a
los sistemas de detección de intrusos tradicionales; (4) la
demostración de la inefectividad de los datos de prueba
existentes para evaluar sistemas de detección de intrusos.
El entrenamiento de las redes neuronales se realizó
utilizando el conjunto de datos “DARPA Intrusion Detection
Evaluation 1999”, del cual se eligieron tres días completos
de tráfico anómalo mezclado con tráfico normal.
Los resultados experimentales mostraron un 0,7% de falsos
positivos con el tráfico normal, un 8,33% de verdaderos
positivos con ataques conocidos y un 100% de falsos negativos
con ataques desconocidos. Estos resultados se justifican por
la cantidad de atributos disponibles a la hora de hacer un
análisis en tiempo real y a la mala calidad de los datos de
entrenamiento disponibles para tal fin.
iv
Abstract
This research is focused on computer security, specifically
on network intrusion detection.
This document includes a bibliographic review about the
Intrusion Detection Systems in their different approaches of
application and implementation.
The main objective of any Anomaly Based Intrusion Detection
System, is to identify if there is any attack being
developed, indifferently whether it is a new kind of attack
or a previously known attack. To obtain this conclusion,
Intrusion
Detection Systems use mathematical, artificial
intelligence and data mining tools.
In the prototype developed as part of this research, we used
Multilayer Perceptron (MLP) Backpropagation neural networks.
The main contributions of this research are: (1) the
application of neural networks as a detection mechanism in a
real-time Network Intrusion Detection System; (2) the use of
loosely coupled modules with a message based communication
which facilitates future experimentation with other detection
mechanisms without the need of reimplement the whole system;
(3) the distributed execution of its components gives to the
system a better scalability compared to traditional Intrusion
Detection
Systems;
(4)
it
was
demonstrated
the
ineffectiveness of the currently available data on Intrusion
Detection Evaluation.
Neural networks training was done using the “DARPA Intrusion
Detection Evaluation 1999” dataset, from which were selected
three days of network traffic containing attacks and regular
traffic.
Experimental results showed 0.7% of false positives with
regular traffic, 8.33% of true positives with known attacks
and 100.00% of false negatives with unknown attacks. This
results are justified by the small amount of attributes
available on network traffic to perform a real-time analisys
and to the bad quality of the data available to train and
test Intrusion Detection Systems.
v
ÍNDICE
1.INTRODUCCIÓN..............................................9
1.1 Sobre este documento.................................9
1.2 Problema.............................................9
1.3 Objetivos de la investigación.......................11
1.4 Organización de este documento......................12
2.MARCO TEÓRICO............................................14
2.1 Antecedentes........................................14
2.2 Redes neuronales....................................15
2.2.1 Conceptos generales.............................16
2.2.2 Tipos...........................................19
2.2.2.1 Perceptrón..................................19
2.2.2.2 Mapa auto-organizado........................20
2.2.2.3 Teoría de la resonancia adaptativa..........21
2.3 Detección de intrusos...............................23
2.3.1 Evolución.......................................26
2.3.2 Estrategias utilizadas..........................27
2.3.2.1 Estadística.................................30
2.3.2.2 Sistemas expertos...........................33
2.3.2.3 Minería de datos............................35
2.3.2.4 Híbridos....................................38
2.4 Evaluación de sistemas de detección de intrusos.....39
3.ESPECIFICACIÓN DE REQUERIMIENTOS.........................47
3.1 Descripción general.................................47
3.1.1 Perspectiva del producto........................47
3.1.1.1 Interfaces de usuario.......................48
3.1.1.2 Interfaces de hardware......................49
3.1.1.3 Interfaces de software......................50
3.1.1.4 Restricciones de hardware...................50
3.1.1.5 Operaciones.................................52
3.1.1.6 Requisitos de adaptación....................52
3.1.2 Funcionalidad del producto......................52
3.1.2.1 Análisis....................................53
3.1.2.2 Accesibilidad...............................53
3.1.2.3 Seguridad...................................53
3.1.2.4 Inserción de datos..........................54
3.1.2.5 Mantenimiento...............................54
3.1.2.6 Diagrama de contexto........................56
3.1.3 Características de los usuario..................56
3.1.4 Restricciones...................................57
3.1.5 Suposiciones y dependencias.....................57
3.1.6 Evolución previsible del sistema................58
3.2 Requerimientos específicos..........................59
3.2.1 Interfaces externas.............................59
vi
3.2.2 Casos de uso....................................59
3.2.3 Requerimientos de rendimiento...................65
3.2.4 Requerimientos lógicos de la base de datos......65
3.2.4.1 Restricciones de integridad.................65
3.2.4.2 Requerimientos de retención de datos........65
3.2.5 Restricciones de diseño.........................65
3.2.6 Atributos del sistema de software...............66
3.2.6.1 Confiabilidad...............................66
3.2.6.2 Disponibilidad..............................66
3.2.6.3 Seguridad...................................69
3.2.6.4 Mantenimiento...............................70
3.2.6.5 Portabilidad................................70
4.DISEÑO DEL SISTEMA.......................................71
4.1 Descripción de los módulos..........................72
4.1.1 Módulo de recolección de datos de auditoría
(sniffer)..............................................72
4.1.2 Módulo de almacenamiento de datos de auditoría. .74
4.1.3 Módulo de análisis y detección..................79
4.2 Diseño de las redes neuronales......................82
4.2.1 IP + ICMP.......................................87
4.2.2 IP + UDP........................................89
4.2.3 IP + TCP........................................90
5.PROTOTIPO................................................93
5.1 Lenguaje de programación............................93
5.2 Sistema operativo...................................95
5.3 Almacenamiento......................................95
5.4 Análisis de datos...................................97
5.5 Reportes de salida..................................97
6.METODOLOGÍA..............................................99
6.1 Datos de entrenamiento..............................99
6.2 Entrenamiento de las redes neuronales..............102
6.3 Ambiente de prueba.................................104
7.RESULTADOS EXPERIMENTALES...............................111
7.1 Tráfico normal.....................................112
7.2 Ataques conocidos..................................114
7.3 Ataques desconocidos...............................118
8.ANÁLISIS DE RESULTADOS..................................122
8.1 Comparación con otras investigaciones..............125
9.CONCLUSIONES............................................135
9.1 Trabajo futuro.....................................136
10.Anexos.................................................139
10.1 Anexo 1: Evolución de los ataques informáticos. . .139
10.2 Anexo 2: Componentes de una red neuronal artificial
........................................................140
10.3 Anexo 3: Taxonomía de ataques de Hansman y Hunt. . .141
vii
10.4 Anexo 4: Descripción de ataques comunes...........142
10.4.1 SYN flood.....................................142
10.4.2 Ping of death.................................144
10.5 Anexo 5: Estadísticas de utilización de IDSs en Costa
Rica....................................................146
10.6 Anexo 6: Atributos incluidos en el conjunto de datos
KDD '99.................................................147
10.7 Anexo 7: Código fuente pcap_processor.py..........148
10.8 Anexo 8: Código fuente batch.sh...................149
10.9 Anexo 9: Resultados de investigaciones previas....150
11.BIBLIOGARFÍA...........................................151
9
1. INTRODUCCIÓN
1.1
Sobre este documento
Este documento es el resultado de una investigación en el
tema de las redes neuronales y su aplicación en el campo de
la seguridad informática, específicamente, en los sistemas de
detección de intrusos (IDS).
La investigación abarca un repaso bibliográfico de los temas
involucrados,
ejecución
de
pruebas
de
laboratorio
y
el
desarrollo de un prototipo funcional.
La funcionalidad primordial del prototipo esta concentrada en
la detección de intrusos en la red, sin formar parte del
alcance del presente proyecto de tesis, la programación de un
módulo de respuesta ante ataques u otros módulos adicionales.
1.2
Problema
La necesidad de analizar el tráfico de la red en tiempo real
y
tomar
decisiones
característica
con
base
indispensable
en
para
ese
la
análisis,
protección
es
de
informáticas y toda la información que circula en ellas.
una
redes
10
El problema que se enfrenta en esta tesis, es la carencia de
un sistema eficiente de detección de intrusos basado en la
red, que
sea capaz
de detectar
tanto ataques
previamente
conocidos, así como nuevos ataques.
Uno de los principales obstáculos será el diseño de una red
neuronal altamente eficiente, ya que se trata de un sistema
que requiere gran velocidad de respuesta para no convertirlo
en
un
cuello
de
botella.
Es
importante
destacar
que
la
investigación girará en torno al análisis en línea de la
información
del
tráfico
de
la
red,
y
no
con
lotes
de
registros de eventos pasados (off-line analysis). Se busca
poder detectar intrusos de una red con prontitud, precisión y
autonomía,
aprovechando
al
máximo
los
recursos
computacionales disponibles.
Los
atacantes
informáticos
utilizan
vulnerabilidades
de
software que les permitan ingresar a un sistema y además
garantizar sus futuros accesos.
Es
interesante
monitorizar
la
la
creación
actividad
de
de
una
los
herramienta
usuarios,
capaz
sin
de
buscar
específicamente ataques conocidos [10].
Un estudio publicado en el mes de marzo del 2011, elaborado
por IBM en colaboración con The Economist Intelligence Unit
(EIU) [17], destaca que 78% de los profesionales encuestados
11
aseguran
que
la
seguridad
informática
es
la
preocupación
número uno en las empresas y es prioridad en la gerencia de
riesgo en TI.
A nivel de gobierno, muchos países también se han preocupado
y cuentan con oficinas especializadas en la seguridad de la
información, grupo al cual se unió Costa Rica en el mes de
abril del 2012, con la creación mediante decreto ejecutivo
del
Centro
de
Respuesta
de
Incidentes
de
Seguridad
Informática (CSIRT-CR), con sede en el Ministerio de Ciencia
y Tecnología,
con el
objetivo de
coordinar acciones
para
mejorar la seguridad informática del país[32]. En el anexo 5
se muestran algunas estadísticas referentes al software de
seguridad informática utilizado en las instituciones públicas
de Costa Rica.
1.3
•
Objetivos de la investigación
Conocer el estado del arte del uso de redes neuronales
en sistemas de detección de intrusos.
•
Conocer, experimentar y medir el impacto de al menos
diez ataques informáticos realizados a través de la red.
12
•
Escribir una especificación de requerimientos detallada,
que sirva como guía para el diseño de un IDS, con todas
las
características
que
se
determinen
como
deseables
durante la investigación previa.
•
Escribir
un
documento
de
diseño
basado
en
la
especificación de requerimientos.
•
Implementar un prototipo de IDS sobre la red basado en
redes neuronales, con una arquitectura modular, segura y
escalable, capaz de detectar ataques nuevos y conocidos
con autonomía, manteniendo una tasa de falsos positivos
y de falsos negativos menor a 10%.
1.4
Organización de este documento
Este documento consta de 10 secciones principales.
La sección 1 es la presente Introducción a la investigación;
la sección 2 la constituye el Marco Teórico con un revisión
bibliográfica
investigación:
general
la
sobre
detección
los
de
dos
temas
intrusos
base
y
las
de
la
redes
neuronales; en la sección 3 se presenta una Especificación de
13
Requerimientos
con
los
aspectos
clave
que
debe
tener
un
Sistema de Detección de Intrusos, que va a ser complementada
con el Diseño del software presentado en la sección 4.
La
sección
5
detalla
implementado. En
utilizada
las
la sección
durante
los
características
6 se
del
describe la
experimentos
prototipo
Metodología
realizados,
resultados obtenidos se exponen en la sección 7,
y
los
junto el
Análisis respectivo en la sección 8.
Finalmente, en la sección 9 se encuentran las conclusiones de
la
investigación
junto
con
las
perspectivas
de
trabajo
futuro.
El capítulo 10, son una serie de Anexos que ilustran diversos
temas relacionados con la detección de intrusos usando redes
neuronales.
14
2. MARCO TEÓRICO
2.1
Antecedentes
Los incidentes de seguridad sobre las redes aparecieron desde
que Internet se convirtió en una red abierta. Para 1988 se
creó
el
primer
actualidad
la
gusano
cantidad
[9];
de
desde
ataques
entonces
se
ha
y
hasta
la
incrementado
de
manera exponencial [16]. Sin embargo, no es posible conocer
con precisión los datos sobre ataques ya que frecuentemente
son
ocultados
de
la
luz
pública
para
evitar
que
la
credibilidad de las organizaciones se vea afectada.
Sin importar el tipo de organización, el manejo masivo de
información en formato digital es un factor que ha mejorado
la
eficiencia
y
comunicación
en
los
últimos
30
años.
La
administración inadecuada de esa información puede llevar a
la divulgación de información confidencial y la pérdida o
modificación de datos. Sin duda, ninguno de esos escenarios
es deseable para las organizaciones.
Con la aparición de los ataques sobre redes informáticas,
surge
la
necesidad
efectivamente
comienza
la
las
de
evitarlos
consecuencias
investigación
sobre
o
que
al
menos
pueden
sistemas
de
de
mitigar
provocar.
detección
Así
de
15
intrusos durante la década de 1980 [4].
El aumento significativo en la cantidad y sofisticación de
los ataques, se cree [25], se debe a la proliferación de
software que automatiza los ataques, de modo que cualquier
persona aun sin ningún tipo de conocimiento técnico puede
realizar los ataques. Algunos ejemplos de herramientas de
software
que
automatizan
los
ataques
son:
(http://www.metasploit.com/),
(http://www.nessus.org/),
(http://www.oxid.it/cain.html),
Metasploit
Nessus
Cain
entre
and
otros
(ver
Abel
anexo
1)
[25] .
Aunque existen muchos métodos para responder a una intrusión
en la red, todos ellos requieren la identificación precisa y
a tiempo del ataque [2].
2.2
Redes neuronales
Soft computing es un término bastante general para describir
un conjunto de técnicas de optimización y procesamiento que
son tolerantes a imprecisión e incertidumbre. Las principales
técnicas de soft computing son los algoritmos genéticos, la
lógica difusa, el razonamiento probabilístico y las redes
neuronales [28].
16
2.2.1
Conceptos generales
Las redes neuronales artificiales (ANN en inglés) son una
abstracción
computacional
inspirada
en
el
cerebro
de
los
animales.
“Una red neuronal es un procesador masivamente distribuido y
paralelizado hecho de unidades simples de procesamiento, que
tienen
una
propensión
natural
a
almacenar
conocimiento
obtenido a través de la experiencia y haciéndolo disponible
para su posterior uso” [15]. Se asemejan al cerebro en dos
aspectos:
1. El conocimiento de la red es adquirido del ambiente, a
través de un proceso de aprendizaje.
2. El nivel (fortaleza) de interconexión entre neuronas,
conocido como pesos sinápticos, es usado para almacenar
el conocimiento adquirido.
De
este
modo,
las
redes
neuronales
artificiales
pueden
aprender por actualización adaptativa de sus pesos sinápticos
que caracterizan la fortaleza de las conexiones. Los pesos
son actualizados de acuerdo a la información extraída de los
patrones de entrenamiento[8].
La neurona es básicamente una entidad que recibe entradas que
pueden provenir directamente de una fuente de datos, o bien,
17
de otras neuronas. Cada neurona va a establecer un peso a la
información que recibe, dependiendo de la fuente. Estos son
los pesos que se ajustarán durante la fase de entrenamiento
(ver anexo 2a).
La interconexión de cierta cantidad de neuronas permite crear
una red neuronal, que con el entrenamiento adecuado, tienen
múltiples ámbitos de aplicación en tareas de clasificación,
predicción, procesamiento y aproximación.
El procesamiento interno de una neurona consiste en sumar la
multiplicación de cada entrada por su respectivo peso, por lo
tanto, se van a a sumar tantos valores como entradas tenga la
neurona. Para normalizar la salida, el valor obtenido se pasa
por una función de umbral (threshold) (ver anexo 2b), no
lineal y continua, conocida como sigmoid (ver anexo 2c).
La salida de cada neurona se convertirá en la entrada de
todas
las
neuronas
de
la
siguiente
capa.
El
proceso
de
aprendizaje es esencialmente un problema de optimización en
el que se deben encontrar el mejor conjunto de coeficientes
de conexión (pesos) para solucionar un problema particular
siguiendo algunos pasos [1]:
•
Presentar un conjunto de entradas a la red neuronal.
•
Contrastar la salida deseada y la salida obtenida.
18
•
Modificar los
pesos de
la red
neuronal para
obtener
mejores aproximaciones a la salida deseada.
Un problema que se puede enfrentar durante el entrenamiento
de
la
ANN,
se
denomina
“over-fitting”
o
“sobre
entrenamiento”, que consiste en una reducción significativa
del error obtenido durante el entrenamiento, a cambio de un
error mayor en aquellos casos desconocidos para la red. En
estos
casos,
la
red
ha
memorizado
los
ejemplos
de
entrenamiento, sin embargo, no ha aprendido a generalizar la
solución ante nuevas situaciones [1, 28].
Posterior al entrenamiento, se deben realizar pruebas a la
red neuronal que involucran básicamente dos pasos [1]:
1. Verificación: en el que se le pasan a la red algunos
datos que utilizó durante el entrenamiento.
2. “Recall” o validación: en el que se le pasan a la red
datos que no ha procesado anteriormente.
Una de las desventajas de las redes neuronales es que después
del entrenamiento, no se tiene certeza de qué es lo que
realmente ha aprendido [20] ya que simplemente han cambiado
los valores
denotan
esto
de los
como
pesos sinápticos.
el
“problema
de
Algunos autores
caja
negra”.
[2]
Otra
desventaja es el alto costo de procesador en el caso de que
la red sea muy grande. En [29] también se menciona como un
19
problema que en algunos casos la red neuronal puede que no
logre encontrar una solución satisfactoria.
2.2.2
Tipos
Dependiendo de ciertas características como el ordenamiento
de las neuronas, el tipo de entrenamiento o los flujos de
información,
varios
las
tipos,
redes
tres
neuronales
de
los
se
han
clasificado
en
cuales
se
describirán
a
continuación.
2.2.2.1
Perceptrón
Este tipo de ANN es de múltiples capas, las cuales pertenecen
a tres categorías:
1. Nodos
fuente:
Conforman
la
primer
capa
de
la
red.
Reciben la información directamente de la fuente.
2. Nodos ocultos: Se ubican después de la capa de nodos
fuente.
La
cantidad
de
capas
y
nodos
ocultos
es
variable. Le permiten a la red aprender tareas complejas
extrayendo
progresivamente
los
aspectos
más
significativos de las entradas que recibe.
3. Nodos de salida: Pueden ser uno o más. Es el encargado
de transmitir la decisión o resultado final de la red.
20
El flujo de información va desde los nodos fuente hacia los
nodos ocultos hasta llegar finalmente a el o los nodos de
salida.
Este tipo de redes utilizan un algoritmo de propagación del
aprendizaje hacia atrás, razón por la cual se identifican dos
fases en el entrenamiento de la red:
1. Hacia adelante: un vector de entrada excita los nodos
fuente y su efecto se propaga por la red, capa por capa.
2. Hacia atrás: se corrigen los pesos sinápticos de la red.
Se
obtiene
esperado
la
para
diferencia
producir
del
la
valor
“señal
obtenido
de
error”
y
el
que
posteriormente será propagada hacia atrás.
Según el teorema de aproximación universal, una red neuronal
de perceptrones multicapa puede aproximar cualquier función
con una precisión arbitraria. Generalmente se logra mayor
precisión aumentando la cantidad de nodos en la capa oculta
de la red neuronal, con un mayor costo computacional en el
rendimiento durante la ejecución [28].
2.2.2.2
Estas
Mapa auto-organizado
redes
se
basan
en
el
concepto
de
aprendizaje
competitivo, en el que las neuronas de salida (o de una capa
21
particular) compiten entre ellas para ser activadas, con el
resultado de que sólo una de ellas puede ser la ganadora en
un momento dado.
Las
neuronas
son
colocadas
típicamente
en
estructuras
bidimensionales (como una rejilla / matriz), aunque también
es
posible
usar
sensibilizadas
(estímulos)
más
dimensiones.
selectivamente
en
el
curso
a
Estas
ciertos
del
neuronas
tipos
proceso
de
de
son
entradas
aprendizaje
competitivo, de modo que se auto-organizan en el espacio ndimensional. De esta forma se crea sobre la estructura un
sistema de coordenadas significativo para cada una de las
posibles entradas [15].
Un mapa de auto-organización es entonces caracterizado por la
información de un mapa topográfico de los patrones de entrada
en el que las ubicaciones espaciales (coordenadas) de las
neuronas en la estructura, son indicativos de características
estadísticas
intrínsecas
contenidas
en
los
patrones
de
entrada, de donde proviene el nombre de “self-organizing map”
[15].
2.2.2.3
La
teoría
Teoría de la resonancia adaptativa
de
la
resonancia
adaptativa
(ART)
ha
sido
22
desarrollada
para
atacar
el
dilema
de
la
estabilidad-
plasticidad en redes de aprendizaje competitivo. El dilema de
la estabilidad-plasticidad se enfoca en cómo un sistema de
aprendizaje
puede
preservar
sus
conocimientos
antiguos,
manteniendo su capacidad de aprender nuevos patrones. Los
modelos de arquitectura ART pueden auto-organizarse en tiempo
real
produciendo
reconocimiento
estable,
aun
recibiendo
patrones distintos de los almacenados originalmente.
ART es una familia de diferentes arquitecturas neuronales. La
primera y más básica es ART1. ART1 puede aprender y reconocer
patrones binarios. ART2 es una clase de arquitecturas que
categorizan
secuencias
arbitrarias
de
patrones
de
entrada
analógicos.
Un sistema de ART consta de dos subsistemas, un subsistema de
atención y de un subsistema de orientación. La estabilización
del aprendizaje y la activación ocurre en el subsistema de
atención, haciendo una comparación bottom-up de la entrada,
con otra top-down de la salida esperada. El subsistema de
orientación
controla
el
subsistema
de
atención
cuando
la
comparación no es satisfactoria en el subsistema de atención.
En otras palabras, el subsistema de orientación funciona como
un detector de novedad.
Un
sistema
de
ART
tiene
cuatro
propiedades
básicas.
La
23
primera son las unidades computacionales auto-escalables. El
subsistema de atención se basa en el aprendizaje competitivo
que tiende a mejorar el reconocimiento de características
importantes y a suprimir el ruido. La segunda es memoria de
búsqueda
auto-ajustable.
El
sistema
puede
buscar
en
la
memoria de forma paralela y adaptativamente cambiar su orden
de
búsqueda.
La
aprendidos
tercera
acceden
correspondiente.
Por
es
que
los
directamente
último,
el
patrones
a
sistema
previamente
su
puede
categoría
modular
de
forma adaptativa la vigilancia de atención usando el ambiente
para aprender. Si el ambiente desaprueba el reconocimiento
actual
del
sistema,
cambia
este
parámetro
para
ser
más
garantizar
la
vigilante [40].
2.3
La
Detección de intrusos
seguridad
informática
confidencialidad,
integridad
consiste
y
en
disponibilidad
de
la
información [31]; una intrusión es un conjunto de acciones
que atentan comprometer cualquiera de esos tres aspectos [5].
La detección de intrusos inició como un proceso manual que
realizaban los administradores de sistemas, en el cual debían
revisar datos de auditoría, como bitácoras (logs) del sistema
24
operativo,
bitácoras
de
aplicaciones,
puertos
utilizados,
entre otros, para determinar si alguna secuencia de acciones
particular, se debía a la ejecución de algún ataque [6]. El
proceso era lento, propenso a errores e imposible de realizar
con grandes redes corporativas. En un intento por automatizar
el tedioso proceso, nacieron los sistemas de detección de
intrusos que básicamente tomaban los mismos datos de entrada
que anteriormente
revisaba el
administrador de
la red,
y
analizaba los datos mediante algoritmos para determinar si
había ocurrido o no un ataque. El proceso consumía muchos
recursos computacionales, razón por la cual era ejecutado
solo por las noches con los datos recabados durante el día
[6], es decir, no se podía hacer una detección de intrusos en
tiempo real.
Con
las
mejoras
en
el
desarrollo
del
hardware
se
logró
construir IDSs capaces de analizar grandes cantidades datos
en tiempo real.
Un IDS analiza los eventos de una red o sistema informático,
en búsqueda de signos de posibles incidentes, como ataques o
violación de políticas de seguridad. La detección implica la
experimentación y el aprendizaje de ataques, antes, durante y
después de que éstos sucedan. Por otro lado, la prevención de
intrusos es
la implementación
de retos
que solamente
los
25
usuarios
legítimos
tradicionales
de
podrán
sobrepasar.
autenticación,
como
Los
sistemas
usuario/password,
tokens, biométricos, entre otros, se consideran mecanismos de
prevención de intrusos, ya que permiten el ingreso solamente
a las
puesta
personas autorizadas.
a
prueba
Sin embargo,
frecuentemente
su fortaleza
[4].
Los
es
firewall
tradicionales basados en el bloqueo de puertos se consideran
equipo
de
desarrollan
prevención
los
de
Sistemas
intrusos.
de
A
Detección
raíz
y
de
esto,
se
Prevención
de
Intrusos (IDPS por sus siglas en inglés) que combinan las
funcionalidades de un IDS y un firewall [11]. Estos sistemas
primeramente realizan un análisis en el proceso de detección,
y
en
caso
de
encontrar
actividad
anómala,
pueden
tomar
medidas como el bloqueo de puertos (propio de un firewall)
para interrumpir la comunicación del atacante.
Según el reporte técnico del proyecto IDES [23], para poder
construir un sistema que detecte intrusos, se identifican dos
premisas fundamentales:
1.Se puede auditar el tráfico de la red.
2.La actividad de un intruso es diferenciable de la actividad
de un usuario legítimo.
26
2.3.1
Evolución
Aunque el concepto de IDS ha existido por décadas, los IDS
automatizados
Inicialmente
aparecieron
analizaban
en
la
década
información
a
de
nivel
los
de
80.
sistema
operativo pero con el tiempo han emergido IDS que identifican
comportamiento intrusivo a diferentes niveles de operación
[13]. Ejemplos de IDS a nivel de sistema operativo incluyen
el IDES [23] y NIDES [3] como prototipos pioneros. La mayoría
de
los
antivirus
actuales
también
pertenecen
a
esta
categoría.
Dado
que
muchas
aplicaciones
específicas
tenían
bitácoras
particulares (distintos a los que usaba el sistema operativo)
que debían ser analizados, se desarrollaron también IDS de
software de aplicación, especialmente de bases de datos como
RIPPER y Discovery [13].
En
los
años
90,
con
la
popularización
de
las
redes
de
computadoras, se diseñaron IDS que utilizaban precisamente el
tráfico
de
análisis.
red
como
Entre
los
datos
más
de
entrada
populares
para
están
realizar
Snort,
Bro
el
y
NetRanger.
El
tráfico
secuencias
de
de
red
es
llamadas
más
del
difícil
sistema
de
modelar
(system
que
calls),
las
y
27
regularmente debe ser procesado más rápidamente [24].
La principal ventaja de monitorizar el tráfico de red, es que
es independiente de los sistemas operativos que conforman la
red,
ya
que
se
analizan
Adicionalmente, puede
protocolos
ser añadido
a una
estándar
red sin
[2].
requerir
cambios en ninguno de los hosts que la conforman [30], lo
cual es una enorme ventaja en redes con miles de nodos.
Resultaría de gran utilidad para la construcción de IDSs,
contar
con
acuerdo
a
una
sus
clasificación
estándar
características.
de
Con
los
la
ataques
intensión
de
de
caracterizar y clasificar los distintos tipos de ataques, se
han creado diversas taxonomías (ver anexo 3) sin que se haya
logrado hasta ahora crear un consenso con alguna de ellas.
Esta
categorización
de
los
IDS
se
basa
en
los
datos
de
auditoría que utilizan y resulta útil en el macro-escenario
de la seguridad, pero dentro de cada una de estas grandes
categorías se distinguen diferentes estrategias de análisis
de datos.
2.3.2
Estrategias utilizadas
Se conocen dos enfoques para la detección de intrusos; (1)la
detección de anomalías, que consiste en caracterizar a los
28
usuarios
punto
legítimos
de
para
referencia;
consiste
en
la
irrumpir
en
un
poder
y
(2)la
identificación
sistema
utilizar
dicho
detección
de
de
intrusos
utilizando
perfil
como
abusos,
que
técnicas
que
intentan
previamente
conocidas [12].
La detección de abusos se puede realizar mediante sistemas
basados en reglas, razón por la cual los sistemas expertos
gozan de gran popularidad en esta variedad específica de IDS
[23].
La
forma
tradicional
y
más
desarrollada
para
detectar
intrusos, es el uso de un subsistema con una base de datos de
firmas de ataques previamente conocidos, y que el sistema
debe
mantener
actualizada
para
proveer
la
protección
necesaria [12]. Este método tiene dos problemas principales:
el primero, es que no es capaz de detectar nuevos ataques
sino que solamente detecta aquellos que contenga en su base
de datos; el segundo, es que el administrador de la red debe
mantener siempre las actualizaciones de la base de datos al
día para que la defensa sea efectiva. Entre sus ventajas
están la velocidad, la alta confiabilidad y la baja tasa
falsas alarmas [29].
Por otro lado, la detección de anomalías se puede dividir en
estática y
dinámica. La
estática consiste
en realizar
un
29
análisis sobre una porción estática del sistema cuyos datos
de auditoría son de naturaleza invariable, como bitácoras o
archivos de registros pasados. Por otro lado, la detección de
anomalías dinámica toma datos de auditoría en tiempo real
para
ser
analizados
demandantes
de
[13].
Los
recursos
IDS
dinámicos
computacionales
debido
son
a
muy
la
monitorización continua [33].
“Los sistemas de detección de anomalías utilizan un perfil
base para caracterizar comportamiento normal. Este perfil se
compone
de
observadas
un
para
conjunto
un
de
conjunto
medidas
de
seleccionado
comportamiento
de
dimensiones”
[13].
“El
principal
reto
para
los
sistemas
de
detección
de
anomalías dinámicos es construir perfiles base precisos para
después
reconocer
comportamientos
que
se
desvían
significativamente de dicho perfil” [13]. Otro problema es
que se trata de una solución que no escala fácilmente, pero
que funcionó bien mientras que la cantidad de ataques era
reducida.
Investigaciones
expandir o
previas
modificar los
[5]
indican
niveles de
que
el
proceso
de
sensibilidad, es
más
difícil en el modelo de detección de anomalías que en el
modelo de detección de abusos.
30
Para
medir
la
desviación
de
la
actividad
observada
con
respecto al perfil base, se utilizan diferentes estrategias
que se detallan en las siguientes secciones.
2.3.2.1
Se
definen
Estadística
un
conjunto
de
medidas
particulares
como
el
promedio de tiempo de CPU utilizado por un usuario, memoria
consumida, cantidad de accesos a archivos, ancho de banda
utilizado, entre otros, que caracterizan la utilización de
una variedad de recursos.
Estas métricas usualmente pertenecen a uno de los siguientes
tipos [2]:
•
Contadores de eventos: identifican las ocurrencias de
una acción específica en cierto periodo de tiempo. Aquí
se incluyen por ejemplo los intentos de ingreso (login)
o el número de veces que un archivo fue accedido.
•
Intervalos de tiempo: identifica el intervalo de tiempo
entre dos eventos relacionados. Por ejemplo, el espacio
de tiempo entre los ingresos a un sistema por parte de
un usuario.
•
Utilización de recursos: identificación cuantitativa de
eventos como la cantidad de tiempo de CPU utilizado,
31
cantidad de registros leídos/escritos a la base de datos
o número de archivos transmitidos por la red.
Las métricas seleccionadas son entonces usadas en modelos
estadísticos
norma
que
intentan
establecida.
frecuentemente
identificar
Los
usados
modelos
incluyen
desviaciones
que
el
han
modelo
de
sido
una
más
operacional,
promedio, desviación estándar, multivariante, Markov y series
de tiempo. El modelo operacional asume que una anomalía puede
ser identificada mediante la comparación de una observación
con
un
límite
predefinido.
Este
modelo
es
frecuentemente
usado en situaciones en que un número específico de eventos
(por ejemplo, logins fallidos) es una indicación directa de
un probable ataque. El promedio y la desviación estándar en
la
determinación
particularmente
estadística
útiles
para
la
tradicional,
identificación
resultan
de
qué
es
normal para un usuario individual, sin tener que compararlo
con otros usuarios. El análisis multivariante se basa en la
correlación de dos o más métricas. Finalmente, las series de
tiempo intentan identificar anomalías mediante la revisión
del orden y el intervalo de tiempo de las actividades del
usuario.
Si la probabilidad de ocurrencia de una observación es baja,
entonces el evento es etiquetado como anormal. Este método
32
provee la habilidad de evolucionar en el tiempo basado en las
actividades de los usuarios [2].
Estos
modelos
se
usan
para
desarrollar
una
variedad
de
perfiles que intentarán plasmar las actividades no intrusivas
del sistema. Los perfiles permiten establecer una línea base
del comportamiento de los usuarios, que luego podrá ser usado
para comparar con las observaciones registradas [2].
Cuando se realice el análisis de algún registro de auditoría,
se contrastará el evento actual, como por ejemplo la lectura
y escritura de 1.000 archivos, con el rango correspondiente
en la distribución de probabilidad. Si resulta que es un
evento
altamente
probable,
gracias
a
la
caracterización
histórica del usuario, entonces el IDS no emitirá ninguna
alarma. Si por el contrario, resulta que la operación no es
habitual, el IDS deberá generar la correspondiente alerta. Se
debe notar que la determinación de cuánto es una probabilidad
alta o baja, es completamente subjetivo y configurable por
parte del administrador del sistema.
Entre
sus
ventajas
está
que
no
requiere
de
conocimiento
previo sobre ataques y entre sus desventajas se anota que
requiere
sistemas
de
alto
rendimiento
para
el
análisis
dinámico de los datos de auditoría [29].
El módulo estadístico del proyecto IDES [23] (A Real-Time
33
Intrusion-Detection
Expert
System),
es
el
encargado
de
detectar anomalías. Propone la generación de un valor T2 por
cada evento. Dicho valor será la calificación de peligrosidad
del evento. Si el valor de T2 está entre 0 y 22, se considera
“normal”
(consistente
con
el
comportamiento
observado
previamente); entre 22 y 28, “amarillo”; mayor de 28, “rojo”.
Otra herramienta estadística utilizada en este software, es
la correlación: un valor en el rango [-1, 1] que mide el
grado de asociación entre dos variables, de modo que por
ejemplo, se pueda establecer que es muy probable un aumento
de consumo de ancho de banda los días viernes, o que es poco
probable la lectura de archivos de 6:00pm a 7:00am, durante
la noche y madrugada.
2.3.2.2
Sistemas expertos
Los sistemas
expertos fueron
una de
las herramientas
más
populares para la detección de intrusos, cuando se iniciaron
las investigaciones al respecto [23,
3].
Un sistema experto consiste de un conjunto de reglas que
codifican el conocimiento de un humano experto [2].
En el caso del proyecto IDES [23], el sistema experto tenía
el propósito de detectar abuso, es decir, ataques previamente
conocidos. Tanto el componente estadístico como el sistema
34
experto de IDES, compartían los mismos registros de auditoría
como
entrada,
subsistemas
sistema
pero
era
el
procesamiento
independiente.
experto
contiene
El
interno
conocimiento
información
de
ambos
base
del
acerca
de
vulnerabilidades conocidas y escenarios de ataque reportados.
En su reporte técnico recomiendan mantener actualizada dicha
base de conocimiento para obtener una mayor efectividad de
detección en el sistema experto.
Por otro lado NIDES [3], realizó mejoras al sistema experto
como por ejemplo la posibilidad de agregar reglas al sistema
sin
detener
la
ejecución
y
la
posibilidad
de
“apagar”
o
“encender” algunas reglas.
El principal problema de los sistemas expertos consiste en el
hecho
de
inteligente
que
y
se
considera
flexible,
al
intruso
mientras
que
los
como
IDS
un
agente
basados
en
reglas siguen reglas estáticas [28].
Los sistemas expertos requieren de actualizaciones frecuentes
por parte del administrador para mantenerlo vigente. La falta
de actualización tiende a degradar la seguridad del sistema
mientras que brinda una falsa sensación de seguridad a los
usuarios.
35
2.3.2.3
Minería de datos
Una variedad de técnicas de clasificación han sido propuestas
en la literatura. Estas incluyen lógica difusa, algoritmos
genéticos, redes neuronales, entre otras [29].
La habilidad de las técnicas de soft computing para lidiar
con
la
incertidumbre
y
datos
incompletos,
las
hacen
atractivas para ser aplicadas en la detección de intrusos
[28].
La aplicación más popular de las redes neuronales en IDSs,
consiste en entrenar la red con una secuencia de unidades de
información, cada una de las cuales puede ser un registro de
auditoría o una secuencia de comandos.
Una de las ventajas de las ANN en la detección de ataques es
la flexibilidad, ya que por ejemplo, pueden analizar datos
tomados de la red aún y cuando están incompletos o fuera de
los estándares. Las ANN desarrollan generalizaciones que les
permiten
detectar
ataques
desconocidos
o
variaciones
de
ataques conocidos [1].
Una desventajas de usar ANN en la detección de intrusos es
que la habilidad de una ANN para identificar intrusiones es
completamente
dependiente
de
la
precisión
del
sistema
de
entrenamiento: los datos de entrenamiento y los métodos de
entrenamiento son críticos. El entrenamiento puede requerir
36
miles de secuencias de ataques individuales, y esta cantidad
de información sensitiva, resulta difícil de obtener [2].
Uno de los primeros desarrollos de ANN en IDS (a nivel de
sistema operativo) [10], utilizaba una combinación de una ANN
con sistema experto, de modo que sólo aquellos casos que la
ANN
consideraba
minuciosamente
como
por
potenciales
el
sistema
ataques,
experto,
eran
revisados
considerado
más
complejo computacionalmente que el análisis inicial realizado
por la red neuronal.
En
la
herramienta
tradicional
de
NNID
tres
[33]
capas
se
utilizó
utilizando
una
el
red
neuronal
algoritmo
de
propagación hacia atrás. Esta herramienta tomaba como entrada
comandos del sistema operativo UNIX y realizaba el análisis
off-line.
Usando
precisión
del
96%
dicha
y
un
red
7%
lograron
de
resultados
falsos
positivos
con
una
en
sus
una
red
experimentos con una cantidad de diez de usuarios.
En
una
investigación
previa
[6]
también
propuso
neuronal con propagación hacia atrás para la detección de
intrusos. Realizaron entrenamientos de 100, 1.000, 5.000 y
20.000 épocas con 4, 6, 12 y 24 neuronas en la capa oculta.
La mejor tasa de detección fue de un 86% con un 0% de falsos
positivos, probablemente debido a que utilizaron solo 40 y
100 sesiones de tráfico durante las pruebas reportadas.
37
En una investigación posterior [28], la entrada de la red
consiste del comando actual y los w comandos pasados (w es el
tamaño de la ventana de los comandos por examinar). Con dicho
entrenamiento,
conjunto
de
determinado.
la
red
puede
comandos
Además,
son
se
indicar
o
no
posteriormente
típicos
pretendía
no
de
sólo
un
si
un
usuario
identificar
la
ocurrencia o ausencia de un ataque, sino que también trataba
de
identificar
entrada
el
ataque.
registros
del
Esta
tráfico
herramienta
de
red
tomaba
junto
con
como
otros
atributos adicionales y los analizaba off-line. En la capa de
salida
utilizaba
tres
neuronas
para
indica
condiciones
normales [1 0 0], ataques por escaneo [0 0 1] y ataques SYN
flood [0 1 0]. La capa de entrada la constituían 35 neuronas,
una por cada característica tomada en cuenta en el vector de
entrada.
Otra investigación [8] utilizó métodos de aprendizaje neurodifusos
(neuro-fuzzy)
para
el
entrenamiento
de
una
ANN.
Adicionalmente, diseñaron una ANN para cada tipo de ataque,
funcionando
todas
concurrentemente,
y
mediante
un
procedimiento determinaban la subred neuronal con el puntaje
ganador.
38
2.3.2.4
Híbridos
Actualmente
diferentes
se
está
técnicas
siguiendo
para
la
la
tendencia
detección
de
de
ciertos
mezclar
tipos
específicos de ataques. Por mencionar algunos ejemplos, se
han hecho pruebas mezclando ANN con otras técnicas de minería
de datos [35], ANN con sistemas de inferencia difusos [8],
Support Vector Machine (SVM) con técnicas de lógica difusa
para establecer un límite dinámico pero difuso entre tráfico
“bueno” y “malo” [41].
39
2.4 Evaluación de sistemas de detección de intrusos
La evaluación de los sistemas de detección de intrusos se ha
realizado
tradicionalmente
midiendo
las
tasas
de
falsos
positivos y falsos negativos obtenidos.
Los
falsos
paquetes
errores
o
positivos
actividades
pueden
la
ocurren
degradar
debido
a
invocación
falsos
negativos
ocurren
cuando
normales,
la
el
IDS
como
un
productividad
innecesaria
porque
un
de
de
malinterpreta
ataque.
los
Estos
sistemas
contramedidas.
ataque
real
ha
Los
sido
clasificado como tráfico o actividad normal. Estos errores
pueden causar grandes pérdidas a las organizaciones por lo
que han sido investigados [18] como un caso particularmente
importante.
Por otro lado, se definen también los verdaderos positivos:
tráfico anómalo detectado como tal; y verdaderos negativos:
tráfico normal también considerado así por el IDS.
Altas tasas de falsos positivos pueden resultar en un sistema
excesivamente caro de implementar, aun cuando tenga una alta
precisión en la detección [22].
Algunos autores [29] sugieren agregar una nueva métrica de
evaluación: la capacidad de un IDS para defenderse a sí mismo
de los ataques.
40
Para realizar la evaluación de un Network IDS se requieren
datos de red como entrada para el sistema. Dichos datos deben
estar debidamente categorizados como ataques o como tráfico
normal, con el fin de poder identificar las tasas de falsos
negativos y positivos. Dado que muchos proyectos en el área
de seguridad tenían el mismo requerimiento de datos, se creó
el conjunto de datos de DARPA Intrusion Detection Evaluation
[21] para la evaluación de sistemas de detección de intrusos.
De este modo, se consolidó un conjunto de datos que sirve de
referencia y estándar para la evaluación de IDSs.
Estos datos se generaron en el Information System Technology
Group del MIT, patrocinados por el Defence Advanced Research
Project
Agency
(DARPA).
La
meta
de
DARPA
es
desarrollar
sistemas de detección de intrusos o sistemas agregados que
puedan detectar más del 99% de los ataques con una tasa de
falsos
positivos
menor
a
1%
[6].
Bajas
tasas
de
falsos
positivos combinadas con altas tasas de detección, significa
que
las
alertas
son
confiables
y
que
la
labor
humana
necesaria para confirmar la detección es minimizada [22].
Para recolectar dichos datos se estableció un ambiente de red
TCP/IP para obtener un volcado de datos crudos (raw dump)
simulando un ambiente típico de una red de área local de la
Fuerza Aérea Estadounidense.
41
Este proyecto generó tres conjuntos de datos, cada uno de los
cuales presenta particularidades que los diferencia de los
demás:
Conjunto de datos de 1998: Fue el primer conjunto de datos
generado. Consiste en una red con la topología mostrada en la
figura 2.1 (tomada de la documentación oficial del proyecto,
en
inglés)
de
la
cual
se
auditan
y
proveen
información
variada desde múltiples puntos de la red: (1) el tráfico de
red a ambos lados del enrutador (tcpdump); (2) registros del
SUN
Basic
Security
Module;
(3)
información
completa
del
sistema de archivos de los servidores (file system dump); (4)
listado del tráfico con los ataques etiquetados.
Dicha
LAN
fue
administrada
como
una
LAN
real,
pero
fue
probada con múltiples ataques.
Cada registro de ataque pertenece a una de cuatro categorías
a saber [8]:
1. Probe: El atacante escanea la red de computadoras para
recolectar
información
o
buscar
vulnerabilidades
conocidas.
2. DoS (Denegación de servicio): El atacante consume gran
parte de los recursos computacionales de un sistema para
inhabilitar su servicio a los usuarios legítimos.
3. R2L (Remote to Local): Un atacante que no posee una
42
cuenta de acceso a una máquina remota, envía paquetes
por la red para explotar alguna vulnerabilidad y ganar
acceso local como si fuera un usuario de dicho sistema .
4. U2R (User to Root): El atacante que posee acceso como un
usuario normal del sistema (sin privilegios), explota
una vulnerabilidad para obtener acceso al sistema con el
usuario root.
43
Figura 2.1: Topología utilizada en el proyecto DARPA-MIT 1998.
A
partir
del
subconjunto
conjunto
para
el
de
datos
proyecto
KDD
de
red
se
(Knowledge
generó
un
Discovery
in
Databases) de la Universidad de California en Irvine, que se
denominó
TCP/IP
KDD
se
cualitativas
'99. En
extrajeron
[39]
este subconjunto,
41
tanto
a
por cada
características
nivel
de
red,
conexión
cuantitativas
como
de
y
sistema
operativo. Estos atributos se detallan en el anexo 6.
Conjunto de datos de 1999: La topología de la red utilizada
es bastante similar a la de 1998, sin embargo, en este nuevo
44
conjunto de datos no se proveen algunos datos que sí se
brindaban en el anterior, como la información completa del
sistema de archivos de los servidores; en su lugar se brindó
solamente
un
listado
detallado
de
los
archivos
de
los
principales directorios del sistema operativo.
Al igual que en el anterior, en este conjunto de datos se
brinda
como
el tráfico de red a ambos lados del enrutador, así
información
adicional
de
bitácoras
de
los
sistemas
operativos.
Se agregan estaciones con el sistema operativo Windows NT® a
la red de servidores.
Se
creó
una
categoría
de
ataque
adicional
a
las
cuatro
definidas en 1998:
5. Data compromise: Consiste en el acceso no autorizado o
la modificación de datos de manera local o remota.
De las 3 semanas de generación de datos de entrenamiento, la
primera y la última corresponden únicamente a tráfico normal,
mientras que la segunda semana es en la que ocurren los
ataques.
Posteriormente, se
agregaron dos
semanas más
de datos
de
prueba (semanas 4 y 5) con tráfico de ataques mezclado con
actividad normal.
Este conjunto de datos consta de 190 instancias de 57 ataques
45
que incluyen: 37 de probing, 63 DoS, 53 R2L y 37 U2R/Data
compromise [36].
Conjunto de datos del 2000: Este conjunto de datos no es de
tráfico general como los dos anteriores, sino que crea tres
escenarios específicos para distintos ataques. Los primeros
dos son sobre ataques de denegación de servicio distribuidos
(DDoS). El tercero es sobre ataques específicos para Windows
NT®.
Todos los datos, tanto de red como de sistema operativo,
están disponibles en línea para la evaluación de los IDS que
así lo requieran [21].
Investigaciones previas [22] indican que los ataques de tipo
probe o DoS son más fácilmente detectados por sistemas cuya
entrada es la información de red, mientras que los ataques de
R2L y U2R son detectados de mejor manera en IDS que toman
como entrada la información que provee el sistema operativo.
Aunque la mayoría de investigaciones sobre el tema, utiliza
el conjunto de datos de DARPA (específicamente KDD '99) para
la evaluación [8, 28, 1, 35, 39, 6], existen algunas otras
que no lo utilizan [20] y obtienen sus propios datos por
otros medios, aunque no los publican para la validación de
46
pares.
De las 41 características
conexión en
KDD '99,
disponibles por cada registro de
algunas investigaciones
[8, 28,
35]
decidieron reducir la cantidad y descartar algunas de ellas
para obtener un mejor rendimiento computacional.
El detalle de dos ataques específicos junto con las posibles
contramedidas se encuentra en el anexo 4.
47
3. ESPECIFICACIÓN DE REQUERIMIENTOS
3.1 Descripción general
El
proyecto
de
software
a
implementar
consiste
en
un
prototipo de sistema de detección de intrusos sobre la red
basado en redes neuronales.
El prototipo de IDS deberá contar con algunos requerimientos
básicos
como
proveer
algún
mecanismo
de
instalación,
configuración, administración y reporte.
La presente especificación de requerimientos, abarca aspectos
mucho más amplios que los requeridos para el prototipo, sin
embargo, se decidió hacer una especificación completa que
sirva de base para el trabajo futuro en la misma temática.
Dado que un IDS es un componente de hardware + software muy
especializado,
conocedores
en
los
usuarios
temas
de
del
redes,
mismo
se
seguridad
asumen
y
como
sistemas
operativos.
3.1.1
Perspectiva del producto
El sistema
estará instalado
en un
punto de
interconexión
entre dos redes, de modo que todo el tráfico desde y hacia la
48
red que se desea proteger, tenga que pasar a través de él
para poder analizar el tráfico.
Dicha topología, con un único punto de salida a otra red
(generalmente Internet) suele ser un estándar de facto en la
mayoría de organizaciones, ya que les permite concentrar en
un punto el tráfico para aplicar sus políticas de utilización
de la red.
Cada paquete recibido por la interfaz de red del IDS, deberá
ser almacenado para su posterior análisis. Dicho análisis
deberá
poder
hacerse
en
tiempo
real
para
detectar
oportunamente los ataques y emitir el respectivo reporte al
encargado del sistema.
3.1.1.1 Interfaces de usuario
Entrada
La interacción con los usuarios será a través de una línea de
comandos de usuario (CLI).
Salida
Los reportes generados ante posibles incidentes deberán tener
como mínimo la siguiente información:
•
Host remoto.
49
•
Host local.
•
Puerto remoto.
•
Puerto local.
•
Fecha y hora.
•
Cantidad de información transferida (Bytes).
•
Protocolo de transporte utilizado.
La ausencia de reportes indicará la no detección de tráfico
anómalo.
3.1.1.2 Interfaces de hardware
Infraestructura de red
La aplicación necesita para su funcionamiento al menos dos
tarjetas de red Ethernet instaladas en la computadora: una
hacia la red que se desea proteger y otra hacia la red de
donde provienen las amenazas.
50
3.1.1.3 Interfaces de software
Base de datos
Nombre
Mnesia
Versión
4.5
Fuente
www.erlang.org/doc/apps/mnesia
Propósito
Almacenamiento temporal de la información previo
a su análisis.
Almacenamiento persistente de la información en
caso de ser necesario un posterior análisis
forense.
Tabla 3.1: Interfaz con la BD Mnesia.
Máquina virtual
Nombre
Erlang
Versión
R15B01
Fuente
www.erlang.org
Propósito Ejecución del software de detección de intrusos.
Tabla 3.2: Interfaz con la máquina virtual de Erlang.
3.1.1.4 Restricciones de hardware
Tarjetas de red
Los requerimientos de velocidad de dichas tarjetas varían de
acuerdo a la cantidad de usuarios en la LAN, así como de la
velocidad disponible en la red.
51
Memoria
La aplicación realizará un análisis exhaustivo del tráfico de
red que deberá mantenerse en memoria mientras es analizado.
Se recomienda como mínimo 2GB de memoria RAM en el equipo a
utilizar.
Disco
No existe un requerimiento específico que limite el tamaño
máximo de la aplicación.
El consumo de disco estará determinado principalmente por la
cantidad de tráfico que el administrador desee almacenar en
la
base
de
datos
y
la
cantidad
de
tiempo
que
desee
conservarlo.
CPU
No existe un requerimiento específico que limite la cantidad
de procesamiento de la aplicación.
El consumo de tiempo de CPU estará determinado principalmente
por la cantidad de tráfico que deba ser analizada, así como
la profundidad de dicho análisis.
52
3.1.1.5 Operaciones
Configuración
1. Determinar qué se almacena en la base de datos.
2. Especificar las horas de funcionamiento del sistema.
Administración
1. Iniciar / detener el sistema
2. Respaldar la base de datos
3. Respaldar la configuración
4. Generar reportes
3.1.1.6 Requisitos de adaptación
El lugar donde se ubique el IDS debe estar a una temperatura
regulada de 20º Celcius.
El acceso físico debe ser restringido a únicamente personal
autorizado (el o los administradores del sistema).
3.1.2
Funcionalidad del producto
53
3.1.2.1 Análisis
El IDS deberá analizar el tráfico de la red utilizando redes
neuronales
como
mecanismo
de
detección.
No
existe
una
restricción sobre la cantidad o el tipo de red neuronal que
debe ser utilizada en la aplicación.
Como
mínimo
se
deberá
implementar
el
análisis
de
los
protocolos IP, TCP, UDP e ICMP.
3.1.2.2 Accesibilidad
El acceso al sistema será mediante una conexión remota segura
de Secure Shell (SSH).
Es posible también utilizar una sesión local en caso de tener
acceso físico al hardware.
3.1.2.3 Seguridad
La aplicación podrá ser ejecutada únicamente por el usuario
root (administrador) del sistema operativo u otro usuario con
privilegios similares.
El prototipo de IDS no realizará administración propia de
usuarios, sino que delegará esta función al sistema operativo
54
subyacente.
3.1.2.4 Inserción de datos
Configuración
La configuración del sistema se realizará mediante archivos
de texto.
Administración
Las
labores
serie
de
de
administración
programas
que
se
se
realizarán
ejecutarán
desde
mediante
la
línea
una
de
comandos.
3.1.2.5 Mantenimiento
Respaldo
Se almacena una copia de la base de datos y la configuración
del sistema para una posterior recuperación en caso de falla
o catástrofe.
Recuperación
Se reemplaza, usando uno de los respaldos, la base de datos y
configuración del sistema ante una falla crítica de hardware
55
o software.
3.1.2.6 Diagrama de contexto
Figura 3.1: Diagrama de contexto del IDS.
3.1.3
Características de los usuario
Tipo de usuario
Administrador.
Formación
Ing. Computación / Telemática.
Habilidades
Manejo de sistemas operativos *NIX.
Experiencia en configuración de equipos de
red (firewall, switches, routers).
Manejo de interfaces orientadas a la línea
56
de comandos (CLI).
Actividades
Instalación del IDS.
Configuración el IDS.
Administración del IDS.
Análisis de reportes generados.
Tabla 3.3: Características del usuario administrador del IDS.
3.1.4
Restricciones
La
•
aplicación
deberá
ejecutarse
en
plataformas
GNU/Linux.
El servidor deberá estar dedicado exclusivamente a la
•
ejecución
del
IDS,
ya
que
software
adicional
podría
incluir vulnerabilidades y aumentar el riesgo de ataque
al IDS mismo.
3.1.5
Suposiciones y dependencias
Teóricamente el sistema podría funcionar en otros sistemas
operativos, pero no se garantiza el correcto funcionamiento
en
sistemas
distintos
a
GNU/Linux,
que
es
la
plataforma
oficial de pruebas y desarrollo.
El sistema establece una fuerte dependencia con el motor de
57
base de datos seleccionado: Mnesia.
Se supondrá que la arquitectura de hardware a utilizar en
producción, es soportada por la máquina virtual de Erlang.
3.1.6
•
Evolución previsible del sistema
En caso de que la cantidad de tráfico por analizar,
supere
las
capacidades
instalación
inicial,
del
hardware
utilizado
el
sistema
deberá
en
la
proveer
facilidades que permitan que el análisis se ejecute de
manera
distribuida
en
hardware
adicional,
realizando
pocas o ninguna modificación al software.
•
Una posible extensión al sistema, sería la capacidad de
contar con múltiples módulos de análisis que puedan ser
integrados para la elaboración conclusiones.
•
Adicionalmente,
capacidad
de
sería
deseable
integrar
distintas
que
el
fuentes
IDS
de
tenga
datos
de
auditoría (distintos sistemas operativos, aplicaciones,
etc.)
que
le
permitan
analizar
un
escenario
más
completo.
•
Enviar
personas
notificaciones
por
encargadas,
en
administrador.
distintos
caso
de
medios
a
ausencia
otras
del
58
3.2 Requerimientos específicos
3.2.1
Interfaces externas
Nombre
LibPCap
Propósito
Fuente / destino
Tomar el tráfico de la tarjeta Red / Mnesia
de
red
(sniffer)
para
transferirlo a la aplicación.
Mnesia
Almacenar
información
del Mnesia / IDS
tráfico de red por analizar.
Sistema
de Escribir en archivos la salida IDS / archivo
archivos
con los resultados obtenidos.
Tabla 3.4: Interfaces con software externo.
3.2.2
Casos de uso
59
Caso #1:
Iniciar la ejecución del IDS.
Actores:
Administrador.
Resumen:
El administrador inicia la ejecución del
software del IDS.
Tipo:
Primario y esencial.
Curso normal de eventos
Acción del actor
Respuesta del sistema
1
Editar
el
archivo
“config.txt”
con
las
configuraciones deseadas.
2
Escribir en la línea de
comandos el nombre del
script del software junto
con
las
opciones
correspondientes:
“ids
-start
-c
<path_config_file>”
3
Indica mediante un mensaje
en
la
consola
que
el
software ha iniciado la
operación.
Tabla 3.5: Curso normal de eventos en el caso de uso #1.
Curso alterno de eventos
Línea Acción
2
2
No se encuentra el archivo de configuración en la ruta
ingresada por el usuario. Se muestra un mensaje en la
consola indicando como un error la ausencia del
archivo requerido. No es posible iniciar el software.
El IDS ya está en ejecución. Se imprime un mensaje en
consola
indicando
que
el
software
está
siendo
ejecutado.
Tabla 3.6: Curso alterno de eventos en el caso de uso #1.
60
Caso #2:
Detener la ejecución del IDS.
Actores:
Administrador.
Resumen:
El administrador detiene la ejecución del
software del IDS.
Tipo:
Primario y esencial.
Curso normal de eventos
Acción del actor
1
Respuesta del sistema
Escribir en la línea de
comandos el nombre del
script del software junto
con
la
opción
correspondiente:
“ids -stop”
2
Indica mediante un mensaje
en
la
consola
que
el
software ha detenido la
operación.
Tabla 3.7: Curso normal de eventos en el caso de uso #2.
Curso alterno de eventos
Línea Acción
1
El IDS no está en ejecución. Se imprime un mensaje en
consola indicando que el software no está siendo
ejecutado.
Tabla 3.8: Curso alterno de eventos en el caso de uso #2.
61
Caso #3:
Respaldar la base de datos.
Actores:
Administrador.
Resumen:
El administrador respalda en un archivo el
contenido de la base de datos.
Tipo:
Primario y esencial.
Curso normal de eventos
Acción del actor
1
Respuesta del sistema
Escribir en la línea de
comandos el nombre del
script del software junto
con
las
opciones
correspondientes:
“ids
-backupDB
-o
<path_output_file>”
2
Genera un archivo con el
nombre especificado por el
usuario, con el respaldo
correspondiente.
3
Indica mediante un mensaje
en
la
consola
que
el
respaldo se ha realizado.
Tabla 3.9: Curso normal de eventos en el caso de uso #3.
Curso alterno de eventos
Línea Acción
2
2
No hay espacio suficiente para guardar el respaldo. Se
imprime un mensaje en consola indicando la carencia de
espacio.
El usuario no posee privilegios de escritura en el
directorio que contendrá el respaldo. El software
imprime
un
mensaje
indicando
los
problemas
de
privilegios en el sistema de archivos.
Tabla 3.10: Curso alterno de eventos en el caso de uso #3.
62
Caso #4:
Respaldar la configuración del IDS.
Actores:
Administrador.
Resumen:
El administrador respalda tanto el archivo de
configuración como la composición interna de
la red neuronal (pesos sinápticos).
Tipo:
Primario y esencial.
Curso normal de eventos
Acción del actor
1
Respuesta del sistema
Escribir en la línea de
comandos el nombre del
script del software junto
con
las
opciones
correspondientes:
“ids
-backupConf
-o
<path_output_dir>”
2
Genera
los
respaldos
correspondientes
en
el
directorio
especificado
por el usuario en la línea
de comandos.
3
Indica mediante un mensaje
en
la
consola
que
el
respaldo se ha realizado.
Tabla 3.11: Curso normal de eventos en el caso de uso #4.
Curso alterno de eventos
Línea Acción
2
2
No hay espacio suficiente para guardar el respaldo. Se
imprime un mensaje en consola indicando la carencia de
espacio.
El usuario no posee privilegios de escritura en el
directorio que contendrá el respaldo. El software
imprime
un
mensaje
indicando
los
problemas
de
privilegios en el sistema de archivos.
Tabla 3.12: Curso alterno de eventos en el caso de uso #4.
63
Caso #5:
Generación de reporte.
Actores:
IDS.
Resumen:
El IDS detecta un ataque lo cual desencadena
como reacción la generación de un reporte en
un archivo de texto.
Tipo:
Primario y esencial.
Curso normal de eventos
Acción del actor
1
Respuesta del sistema
Detección de un ataque en
curso.
2
Escribe
en
disco
un
archivo con el reporte del
evento anómalo.
Tabla 3.13: Curso normal de eventos en el caso de uso #5.
Curso alterno de eventos
Línea Acción
2
2
No hay espacio suficiente para guardar el reporte. Se
imprime un mensaje en consola indicando la carencia de
espacio.
El usuario no posee privilegios de escritura en el
directorio que contendrá el reporte. El software
imprime
un
mensaje
indicando
los
problemas
de
privilegios en el sistema de archivos.
Tabla 3.14: Curso alterno de eventos en el caso de uso #5.
64
3.2.3
Requerimientos de rendimiento
El sistema debe ser capaz de detectar los ataques a los que
sea
sometida
la
red
protegida,
con
una
tasa
de
falsos
negativos y falsos positivos menor a 10%.
3.2.4
Requerimientos lógicos de la base de datos
3.2.4.1 Restricciones de integridad
Debido a la flexibilidad del motor de base de datos (schemaless) y a la adaptabilidad del mecanismo de detección para
trabajar
con
información
incompleta,
no
se
determinan
inicialmente restricciones de integridad en la base de datos.
3.2.4.2 Requerimientos de retención de datos
El administrador tendrá la potestad de configurar si se debe
almacenar
toda
la
información
de
tráfico
de
red
ó
solo
aquella considerada anómala, y por cuánto tiempo.
3.2.5
1. Se
Restricciones de diseño
debe
utilizar
el
motor
de
base
de
datos
Mnesia
65
(NoSQL, schema-less).
2. Se debe
utilizar una
red neuronal
como mecanismo
de
detección.
3. Debido
a
restricciones
legales,
toda
la
información
almacenada en la base de datos del sistema debe ser
tratada con privacidad, por lo tanto se deben aplicar
medidas de seguridad.
3.2.6
Atributos del sistema de software
3.2.6.1 Confiabilidad
El sistema debe ser capaz de detectar los ataques a los que
sea
sometida
la
red
protegida,
con
una
tasa
de
falsos
negativos y falsos positivos menor a 10%.
3.2.6.2 Disponibilidad
Para que el sistema sea funcional debe ejecutarse 24 horas al
día,
todos
los
días
de
la
semana.
Esto
debido
impredecible del momento en que se realizará un ataque.
a
lo
66
Plan de recuperación de fallas
Ante cualquier tipo de falla en el sistema, se debe de seguir
una serie de pasos para registrar, analizar y calcular los
pasos para reparar el problema y evitarlo en el futuro.
Las
posibles
exploits,
fuentes
corrupción
de
falla
en
de
datos,
un
fallas
IDS
abarcan
eléctricas,
virus,
entre
otros.
Diagnóstico
Antes de ejecutar cualquier acción preventiva o paliativa, se
debe de realizar un escaneo total del sistema, revisando la
integridad
de
la
base
de
datos
y
posible
malware
en
el
sistema.
Prevención
Acciones preventivas ante cualquier falla son:
1. Programar diagnósticos semanales para la base de datos y
el
sistema
(información
operativo,
básica
en
con
la
horas
que
de
poco
deberá
tráfico
contar
el
administrador del sistema).
2. Instalación de software antivirus y antispyware capaz de
proteger el sistema.
3. Uso de un servidor dedicado, de manera que se conozca
67
con certeza que no hay acciones de terceras aplicaciones
que
puedan
crear
problemas
o
introducir
vulnerabilidades.
Acciones en caso de fallas
Ante
cualquier
emergencia
en
el
IDS
se
deben
tomar
las
siguientes acciones:
1. Desconectar la línea del acceso a Internet para evitar
la continuación del posible ataque o que pueda ocurrir
uno mientras el IDS está fuera de servicio.
2. Deshabilitar servicios o aplicaciones que no sean del
sistema operativo para eliminar cualquier posibilidad de
malware.
3. En caso de errores por la corrupción de la base de
datos:
1. Revisar las bitácoras.
2. Obtener la fecha y hora en que inició el error.
3. Analizar si es más fácil reparar el error manualmente
o restaurar un respaldo.
4. Antes de restaurar un respaldo, registrar los datos
que potencialmente podrían perderse.
5. Si el fallo es catastrófico, se debe considerar la
restauración completa del sistema o la utilización de
68
herramientas forenses de recuperación.
Software / hardware sugerido
1. Antivirus
2. Software de automatización de respaldos
3. RAID-1: espejo y duplicación de datos.
Responsabilidades
Ante
cualquier
falla,
el
responsable
de
la
detección,
análisis y corrección de la misma es el administrador.
El
administrador
debe
reportar
los
problemas,
sus
antecedentes, características, alcance y posibles soluciones
ante su instancia superior.
Antes de cualquier acción correctiva o paliativa, se debe
informar a
los usuarios
de las
posibles repercusiones
de
usabilidad en la red.
3.2.6.3 Seguridad
El IDS debe tener capacidad de defenderse a sí mismo ante
ataques
ya
que
es
una
práctica
común
que
los
intrusos
desactiven las herramientas de defensa de una red antes de
perpetrar el ataque al objetivo principal.
69
3.2.6.4 Mantenimiento
De acuerdo a las políticas establecidas en la organización,
el administrador deberá hacer respaldos periódicos, tanto de
la configuración como de la base de datos.
3.2.6.5 Portabilidad
El
sistema
será
capaz
de
ser
portado
a
todas
aquellas
arquitecturas que estén soportadas por la máquina virtual de
Erlang, aunque como se menciona en la sección de suposiciones
y dependencias “no se garantiza el correcto funcionamiento en
sistemas distintos a GNU/Linux, que es la plataforma oficial
de pruebas y desarrollo”.
70
4. DISEÑO DEL SISTEMA
Este
diseño
está
basado
en
la
Especificación
de
Requerimientos del capítulo 3. Se incluyen algunos aspectos
adicionales a los requeridos por el prototipo a desarrollar
con el objetivo de que sirva de base para el trabajo futuro
en el mismo tema.
Todo sistema de detección de intrusos cuenta con un conjunto
mínimo de módulos necesarios para operar. La arquitectura
estándar
propuesta
por
Axelsson
[29]
identifica
siete
de
estos módulos que se interrelacionan como se muestra en la
figura 4.1.
Figura 4.1: Arquitectura de IDS propuesta por Axelsson.
71
4.1 Descripción de los módulos
El
prototipo
tiene
un
alcance
acotado
únicamente
a
los
módulos de recolección de datos, almacenamiento de datos y el
módulo de análisis. Una descripción del diseño de cada uno de
ellos se muestra en las siguientes secciones.
4.1.1
Módulo de recolección de datos de auditoría (sniffer)
Este módulo es la interfaz entre el IDS propiamente dicho y
la tarjeta de red desde la cual se recolectarán los datos que
serán analizados.
Para este módulo es necesaria la ayuda de un sniffer de red
que se programará en el lenguaje C, utilizando la biblioteca
libpcap, que le enviará los datos a un proceso de Erlang como
se ilustra en la figura 4.2.
Es
posible
ejecutar
simultáneamente
varios
procesos
de
recolección de datos en varios puntos independientes de una
red.
Este módulo se comportará como un servidor que proveerá de
datos a un conjunto de clientes que se unirán a él por
suscripción. Sus clientes son los procesos de almacenamiento
de
datos
de
auditoría
que
se
detallan
en
la
siguiente
72
sección.
Figura 4.2: Diagrama de comunicación mediante puertos Erlang.
Las tareas específicas de este módulo son:
•
Recibir toda la información que circule por la interfaz
de red auditada.
•
Mantener una lista de procesos que recibirán los datos
para almacenarlos en la base de datos.
•
Enviar los datos con el formato apropiado a cada proceso
de almacenamiento en la lista.
La interfaz pública del módulo se detalla en la tabla 4.1.
73
Método
Entrada
start_link Interfaz
de red
stop
Salida
Descripción
Id.
del Inicio
del
proceso
de
proceso
sniffing
en
la
interfaz
especificada. En caso de no
proveerse alguna, el módulo
la elegirá.
Id.
del
proceso
Detiene
sniffing.
el
proceso
subscribe
Id.
del
Permite la suscripción de
proceso
los
procesos
de
de
almacenamiento a un sniffer
almacenaparticular.
miento
Tabla 4.1: Interfaz pública del módulo de recolección de datos.
Cada trama Ethernet recibida deberá ser enviada en formato
binario,
tal
almacenamiento
cual
es
recibida,
previamente
a
suscritos.
los
La
procesos
lista
de
de
suscriptores inicia vacía.
4.1.2
Módulo de almacenamiento de datos de auditoría
Los IDSs generalmente almacenan temporal o indefinidamente
los
datos
de
auditoría
dichos datos en el futuro.
para
poder
brindar
referencias
a
74
Figura 4.3: Proceso de almacenamiento con
múltiples fuentes de datos.
En la presente implementación, los procesos de almacenamiento
pueden tener múltiples fuentes de datos (ver figura 4.3). En
el caso particular de la figura, el proceso de almacenamiento
está
suscrito
a
n
procesos
de
recolección
de
datos
(sniffers).
Es
posible
ejecutar
almacenamiento
de
simultáneamente
datos,
cada
uno
varios
de
los
procesos
cuales
de
puede
suscribirse a cualquiera de los sniffers.
Los procesos de almacenamiento de datos pueden ejecutarse en
el mismo nodo que los módulos de recolección o en otros nodos
de la red.
La base de datos en que se almacenará la información recibida
75
es
Mnesia,
tablas
de
cuyas
manera
características
distribuida
en
permiten
diferentes
almacenar
las
servidores,
e
inclusive, segmentar las tablas vertical u horizontalmente
entre ellos.
Las tareas específicas de este módulo son:
•
Etiquetar los datos que reciben con información de la
fuente.
•
Dar formato a los datos de acuerdo a los protocolos
analizados.
•
Almacenar la información en la base de datos Mnesia.
La interfaz pública del módulo se detalla en la tabla 4.1
Método
Entrada
start_link
stop
Salida
Descripción
Id. del Inicializa el esquema de
proceso la base de datos.
Crea las tablas si no aún
no existen.
Inicia
el
proceso
de
Mnesia.
Id.
del
proceso
receive_packet Sniffer,
Packet
Detiene
el
proceso
de
almacenamiento de datos.
Se recibe información del
sniffer
fuente
de
los
datos recibidos así como
los datos mismos.
Cada
uno
de
los
encabezados de la trama
recibida es almacenado en
Mnesia.
Tabla 4.1: Interfaz pública del módulo de almacenamiento de datos.
76
Las tablas creadas corresponden uno a uno con cada protocolo
soportado por el IDS. Para el prototipo se implementará el
análisis de los protocolos IP, TCP, UDP e ICMP.
Figura 4.4: Tablas de la base de datos.
Dado que Mnesia no es una base de datos relacional, no es
requerido ningún tipo de normalización. Con el diseño de la
figura 4.4, se explota el hecho de que Mnesia trabaja con
registros del tipo “llave – valor”, de modo que el gobal_id
conformará la llave y el resto de la tupla, el valor.
La llave deberá estar conformada por una combinación del nodo
77
fuente
(sniffer)
desde
el
cual
fue
capturada
la
trama
Ethernet, más una estampilla de tiempo. De este modo, todos
los encabezados de las distintas capas podrán ser unificadas
en caso de ser necesario, ya que todas ellas pertenecen a la
misma trama y por lo tanto, comparten el mismo identificador
global (ver figura 4.5).
Figura 4.5: Estructura de los paquetes recibidos.
4.1.3
Módulo de análisis y detección
Es el módulo más importante del sistema ya que hace efectivo
el proceso de detección de intrusos: objetivo último de un
78
IDS.
Como se mostró en el marco teórico, para lograr una detección
efectiva
árboles
existen
de
múltiples
decisión,
herramientas
minería
de
datos
de
estadística,
e
inteligencia
artificial, algunas de las cuales ya han sido ampliamente
probadas y estudiadas en el pasado con un éxito parcial, y
otras que están actualmente en investigación académica y de
las cuales aún no existen productos en el mercado.
Para el presente proyecto de tesis, uno de los objetivos
consiste en el uso de redes neuronales como mecanismo de
detección de intrusos.
Aunque
existen
seleccionó
una
gran
con
variedad
perceptrones
de
redes
multicapa
neuronales
de
se
propagación
hacia atrás. Se llegó a esta decisión asumiendo como válido
el resultado obtenido en una investigación previa [1] que
compara este tipo de redes neuronales con otras (MSOM, ART1 y
ART2), obteniendo con ella mejores resultados como lo ilustra
el gráfico de la figura 4.6.
Con el
objetivo de
distribuido del
especializadas:
•
IP + ICMP
•
IP + UDP
experimentar la
IDS, se
capacidad de
decidió crear
3 redes
análisis
neuronales
79
•
IP + TCP
Figura 4.6: Tasas de detección con distintas redes neuronales
80
4.2 Diseño de las redes neuronales
Dado que el prototipo de IDS se especificó particularmente
para redes IP, y se seleccionaron como protocolos de prueba
el ICMP, UDP y TCP, se decidió la creación una red neuronal
para cada uno de estos protocolos.
Todas las redes neuronales deberán incluir entre sus entradas
los
datos
constituye
del
el
encabezado
transporte
del
base
protocolo
IP
para
demás
los
ya
que
este
protocolos
soportados: ICMP, UDP y TCP.
De todos los campos de los encabezados disponibles en los
protocolos
soportados
seleccionó como
tabla
4.2
se
solo
entrada para
detallan
los
un
subconjunto
de
ellos
las redes
neuronales. En
atributos
seleccionados
se
la
del
protocolo IP.
En la tabla 4.3 se muestran los campos del encabezado IP
descartados y las razones para no tomarlos en cuenta.
Todas las redes neuronales contarán con una única neurona de
salida que indicará la ausencia (señalada con 0) o presencia
(señalada con 1) de tráfico anómalo.
81
Atributo
Descripción
Versión
Versión del protocolo IP usada por el datagrama
Long. Encabezado Longitud del encabezado IP en palabras de 32 bits
Servicios Diferen. Intento de clasificación de diversos servicios sobre IP
Long. Total
Longitud total del datagrama en bytes
Bandera no usada “Evil bit”
No fragmentar
Solicitud de no fragmentar el datagrama
Más fragmentos Indicación de fragmentos pendientes
Tiempo de vida
Contador que limita el tiempo de vida de un datagrama
Tipo
Continuo
Continuo
Continuo
Continuo
Discreto
Discreto
Discreto
Continuo
Ejemplo
4
5
120
20354
false
true
false
64
Tabla 4.2: Atributos seleccionados para el protocolo IP.
Atributo
Identificación
Motivo
Sirve para unir fragmentos de un mismo paquete, no brinda información
del contenido. Todos los fragmentos de un paquete comparten la misma
identificación.
Desplazamiento
fragmento.
del Sirve para unir fragmentos de un mismo paquete, no brinda información
del contenido.
Protocolo
Se usa para dirigir el paquete hacia alguna de las tres redes neuronales
construidas, mas no es una entrada en ninguna de ellas ya que el valor
siempre sería el mismo en cada una: 0x06 para TCP, 0x11 para UDP y
0x01 para ICMP.
Checksum
Valor completamente variable y que no brinda información alguna sobre
el contenido del paquete.
Dirección fuente
El direccionamiento IP utilizado es altamente variable de una
organización a otra, por lo que resulta inapropiado entrenar las redes
neuronales con un direccionamiento particular.
Dirección destino
El direccionamiento IP utilizado es altamente variable de una
organización a otra, por lo que resulta inapropiado entrenar las redes
neuronales con un direccionamiento particular.
Tabla 4.3: Atributos descartados para el protocolo IP.
El esquema conceptual de operación del IDS se muestra en la
figura 4.7, donde se cuenta con dos redes: una representa la
red
que
se
desea
proteger
y
la
otra,
la
red
de
la
que
provienen las amenazas. En medio se coloca una puerta de
enlace (gateway) que servirá como un punto concentrador de
82
tráfico sobre el cual se colocará el sniffer de red que
tomará
todo
almacenarlo
el
tráfico
de
forma
que
circule
distribuida
para
en
posteriormente
tres
servidores
distintos, cada uno de los cuales a su vez contará con la red
neuronal
especializada
en
el
correspondiente.
Figura 4.7: Esquema conceptual de operación del IDS.
análisis
del
tráfico
83
4.2.1
IP + ICMP
Esta red neuronal consta de ocho neuronas en su capa de
entrada. Seis de ellas encargadas de recibir los seis datos
del encabezado IP descrito anteriormente (comprimiendo las
tres
banderas
en
un
solo
dato),
más
dos
atributos
del
encabezado ICMP:
Atributo
Tipo
Código
Descripción
Tipo de mensaje (Ej. echo request, echo reply)
Subtipo particular del mensaje (Ej. Dest. unreachable)
Tipo
Continuo
Continuo
Ejemplo
8
5
Tabla 4.4: Atributos seleccionados para el protocolo ICMP.
En la capa oculta se probará con dos subcapas de seis y
cuatro neuronas. De este modo, se puede visualizar dicha red
tal y como se muestra en la figura 4.8.
En
la
tabla
5.5
están
los
atributos
descartados
para
el
protocolo ICMP.
Atributo
Motivo
Identificador global
Campo de control. No brinda información del contenido.
Checksum
Valor completamente variable y que no brinda información alguna sobre
el contenido del paquete.
Opciones
Contenido variable dependiendo del tipo y el código.
Tabla 4.5: Atributos descartados para el protocolo ICMP.
84
Figura 4.8: Representación gráfica de la red neuronal IP+ICMP.
4.2.2
IP + UDP
Esta red neuronal consta de nueve neuronas en su capa de
entrada. Seis de ellas encargadas de recibir los seis datos
del encabezado IP descrito anteriormente, más tres atributos
del encabezado UDP:
Atributo
Puerto fuente
Puerto destino
Longitud
Descripción
Puerto fuente del emisor del segmento
Puerto destino en el receptor del segmento
Longitud incluyendo los 8 bytes del encabezado UDP
Tabla 4.6: Atributos seleccionados para el protocolo UDP.
Tipo
Continuo
Continuo
Continuo
Ejemplo
15354
53
8865
85
El único campo del encabezado UDP descartado fue el Checksum.
Se puede visualizar dicha red tal y como se muestra en la
figura 4.9.
Figura 4.9: Representación gráfica de la red neuronal IP+UDP.
4.2.3
IP + TCP
Esta red neuronal consta de diez neuronas en su capa de
entrada. Seis de ellas encargadas de recibir los seis datos
del encabezado IP descrito anteriormente, más:
7. Puerto fuente
86
8. Puerto destino
9. Banderas (comprimidas en un solo dato)
10. Tamaño de ventana
Atributo
Source port
Destination port
Unused4bits
CWR
ECE
URG
ACK
PSH
RST
SYN
FIN
Window size
Descripción
Puerto fuente del emisor del segmento
Puerto destino en el receptor del segmento
Manejo de congestión
Manejo de congestión
Determina el uso del Urgent Pointer
Indica que el número de ACK es válido
Enviar datos directamente a la aplicación, sin buffer
Reiniciar abruptamente una conexión
Establecimiento de la conexión
Finalización de la conexión
Cuántos bytes pueden ser enviados
Tipo
Continuo
Continuo
Continuo
Discreto
Discreto
Discreto
Discreto
Discreto
Discreto
Discreto
Discreto
Continuo
Ejemplo
15354
53
5
false
false
true
false
true
false
false
true
20568
Tabla 4.7: Atributos seleccionados para el protocolo TCP.
En la capa oculta se probará con dos subcapas de siete y tres
neuronas. De este modo, se puede visualizar dicha red tal y
como se muestra en la figura 4.10.
En
la
tabla
5.8
se
muestran
los
descartados para el protocolo TCP.
campos
del
encabezado
87
Figura 4.10: Representación gráfica de la red neuronal IP+TCP.
Atributo
Número de secuencia
Motivo
Campo de control.
Número de confirmación Campo de control.
(ACK)
Checksum
Valor completamente variable y que no brinda información alguna sobre
el contenido del segmento TCP.
Puntero de urgencia
Indica un desplazamiento. No brinda información del contenido.
Opciones
Posee longitud variable, lo cual sesgaría los datos de entrenamiento.
Tabla 4.8: Atributos descartados para el protocolo TCP.
88
5. PROTOTIPO
5.1
Lenguaje de programación
El prototipo desarrollado consta de módulos en tres lenguajes
de programación:
1. La lectura de datos de la red está a cargo de un módulo
escrito
en
C,
utilizando
la
biblioteca
PCAP
(Packet
Capture) que realiza la labor de más bajo nivel del IDS.
2. El almacenamiento de los datos de red (encabezados de
protocolos)
se
distribuida
y
realiza
que
en
una
forma
base
parte
de
del
datos
no-sql
lenguaje
de
programación Erlang. Se seleccionó este lenguaje, debido
a que
posee funcionalidades
que lo
hacen ideal
para
realizar procesamiento distribuido, que es una de las
recomendaciones
más
comunes
de
las
investigaciones
previas [20, 8, 12, 13, 1] en el tema de la detección de
intrusos.
Erlang
es
concurrente
virtual.
un
lenguaje
que
se
Fue
de
ejecuta
diseñado
paradigma
sobre
para
su
funcional
propia
y
máquina
aplicaciones
de
telecomunicaciones y tiene características que lo hacen
útil
para
crear
un
IDS
[19]
como
la
sencilla
89
manipulación de información binaria.
Erlang
permite
crear
procesos
livianos
(light
weigth
processes) que cuenta con un identificador único que les
permite comunicarse entre sí mediante el intercambio de
mensajes.
3. El análisis de los datos está a cargo de tres redes
neuronales
que
están
escritas
en
el
lenguaje
de
programación Java, utilizando la biblioteca Neuroph 2.6.
Existen al menos cuatro métodos para conectar el sniffer en C
con el proceso de almacenamiento en Erlang: Ports, C Nodes,
Linked in drivers y NIFs.
De ellos el seleccionado fue el método de “puertos”, ya que
estos facilitan la construcción de un proceso productor en C
y un proceso consumidor en Erlang, que es la relación que se
presenta entre el sniffer en C y el procesador en Erlang.
Adicionalmente, se utilizó el lenguaje de programación Python
con la biblioteca Scapy para la extracción de datos de los
archivos .pcap de entrenamiento de la red neuronal, junto con
el lenguaje de scripting Bash para el procesamiento en lote
de archivos .pcap.
90
Ambos scripts se encuentran documentados en los anexos 7 y 8.
5.2 Sistema operativo
Para
la
implementación
desarrollado
se
utilizó
y
puesta
en
el
sistema
marcha
operativo
del
Debian
IDS
6.0
("squeeze") debido a la seguridad y estabilidad que ofrece
esta distribución de GNU/Linux. Fue publicada originalmente
con la versión 6.0.0 el 6 de febrero de 2011 y su última
actualización es la versión 6.0.4, publicada el 28 de enero
de 2012.
5.3 Almacenamiento
El uso del DDBMS Mnesia se consideró un requerimiento desde
el principio debido a sus beneficiosas características de
escalabilidad que se consideran deseables para el tratamiento
masivo de datos como podría llegar a tenerlo un sistema de
detección de intrusos sobre la red.
Después de la implementación exitosa del diseño realizado, se
pudo
constatar
apropiado
aún
replicada en
que
y
el
cuando
almacenamiento
la
diferentes nodos
base
de
de una
de
datos
los
se
datos
es
encuentra
LAN Ethernet
10/100
91
Mbps.
En la figura 5.1 se muestra información general de Mnesia
sobre las tablas usadas por la aplicación y en la figura 5.2
la
tabla
del
protocolo
TCP
cargada
con
prueba.
Figura 5.1: Visualización de las tablas creadas en Mnesia.
Figura 5.2: Datos de prueba en la tabla de TCP.
algunos
datos
de
92
5.4
Análisis de datos
Los datos analizados corresponden a un subconjunto de los
campos de los encabezados de los cuatro protocolos soportados
por este prototipo: IP, UDP, TCP e ICMP.
El análisis de los datos es llevado a cabo mediante tres
redes neuronales creadas con la biblioteca Neuroph. Las redes
neuronales creadas para el prototipo se apegan totalmente al
diseño
mencionado en la sección 4.2.
Cada una de las tres redes neuronales ejecuta su función
desde un servidor distinto, por lo que en este prototipo se
le delega al administrador del sistema la tarea de verificar
los reportes generados en cada uno de los tres servidores.
5.5 Reportes de salida
Los reportes de cada una de las redes neuronales son enviados
a un archivo de texto que deberá ser leído e interpretado por
el
administrador
solamente
cuando
actividad
anómala.
del
sistema.
alguna
La
de
las
ausencia
Los
reportes
redes
de
se
generan
neuronales
detecta
reportes
denota
la
no
detección de tráfico anómalo en la red.
En el prototipo implementado, el reporte de salida indica
93
únicamente el identificador del paquete que ha sido detectado
como
anómalo.
Con
dicho
identificador
es
posible
obtener
mediante una consulta a la base de datos, todos los campos de
todos los protocolos del paquete, con lo cual se cumple con
los requerimientos contemplados durante la especificación del
software.
Un ejemplo de un reporte de salida se muestra en la tabla
5.1, donde se especifica el proceso y el servidor en el que
se produce la alerta, así como una estampilla de tiempo con
el formato {megasegundos, segundos, microsegundos}, contados
a partir de las 0 horas GMT del 1º de enero del 1970.
La
estampilla
paquete
que
de
ha
tiempo
sido
identifica
analizado
por
de
forma
el
IDS,
única
de
modo
a
un
que
utilizando dicho identificador es posible obtener todos los
campos de todos los encabezados mediante una consulta a la
base de datos.
{process1@node1,{1333,684973,347631}}
{process1@node1,{1333,684974,141381}}
{process1@node1,{1333,684976,275931}}
{process1@node1,{1333,684976,340574}}
Tabla 5.1: Ejemplo de un reporte de salida del prototipo de IDS.
94
6. METODOLOGÍA
Es este capítulo se presenta en detalle la metodología de
investigación empleada para realizar las pruebas al prototipo
de IDS desarrollado como parte del proyecto de tesis.
6.1 Datos de entrenamiento
Para entrenar las redes neuronales se utilizará el conjunto
de datos de DARPA Intrusion Detection Evaluation 1999.
Dicho conjunto
de datos
está conformado
por, entre
otras
cosas, cinco semanas de tráfico de red en formato tcpdump, de
los cuales se eligieron tres días completos de tráfico para
el entrenamiento de la red neuronal: lunes y miércoles de la
semana #4 y el lunes de la semana #5. Los tres días de
tráfico suman 1109MB de tráfico de red.
En la figura 6.1 se muestra la distribución de los distintos
tipos de tráfico en los archivos seleccionados.
En
los
archivos
con
formato
pcap
utilizados
en
esta
investigación, se incluyen únicamente los atributos de todos
los encabezados en las múltiples capas, desde Ethernet (capa
de enlace de datos) hasta la capa de aplicación. Entre los
95
atributos de los encabezados que no se tomaron en cuenta para
analizar
en
el
prototipo,
están
aquellos
que
tienen
una
validez acotada a un contexto particular como las direcciones
IP o los verificadores de integridad (checksum).
Cantidad de paquetes por día
1600000
1400000
1200000
UDP
TCP
ICMP
1000000
800000
600000
400000
200000
0
S4: Lunes
S4: Miércoles
S5: Lunes
Figura 6.1: Cantidad de paquetes por día, agrupados por protocolo.
Para
extraer
de
los
archivos
de
prueba
solamente
los
atributos requeridos se realizó un script, en el lenguaje de
programación Python usando la biblioteca Scapy [34], que se
incluye en el anexo 7. Debido a que el script presentaba
problemas al ejecutarse con los archivos pcap originales (de
más de 300MB cada uno), se fragmentaron en múltiples archivos
96
pcap con un máximo de 10.000 paquetes cada uno, utilizando el
comando
quedó
editcap.
con
procesar
un
con
Una
peso
el
vez
fragmentados,
aproximado
script
de
de
2MB
python.
cada
que
Para
archivo
sí
que
era
pcap
posible
dicho
script
tomara en cuenta todos los nuevos archivos fragmentados, se
requirió de otro script en el lenguaje Bash (GNU/Linux) que
se muestra en el anexo 8.
La salida de dicho procesamiento son 3 archivos:
icmp.out: con los atributos seleccionados de IP e ICMP.
udp.out: con los atributos seleccionados de IP y UDP.
tcp.out: con los atributos seleccionados de IP y TCP.
Cada uno de ellos especializado en el entrenamiento de la red
neuronal correspondiente.
Un ejemplo del formato del archivo icmp.out se muestra en la
tabla 6.1, en la cual los primeros seis datos de cada fila
corresponden a los atributos seleccionados del protocolo IP
(las
cuatro
siguientes
banderas
dos
se
comprimen
corresponden
a
los
en
un
sólo
atributos
dato),
los
seleccionados
(type y code) de ICMP y el último dato indica si se trata (1)
o no (0) de un paquete que forma parte de un ataque.
[4, 5, 0, 38, 0, 64, 1, 0, 0]
[4, 5, 0, 50, 0, 32, 1, 8, 0]
[4, 5, 0, 50, 0, 255, 1, 0, 0]
97
[4, 5, 192, 89, 0, 64, 1, 3, 1]
[4, 5, 192, 90, 0, 64, 1, 3, 1]
Tabla 6.1: Ejemplo de 5 paquetes ICMP procesados para entrenar la
red neuronal.
De forma similar, se muestra en la tabla 6.2 un ejemplo de 5
registros de entrenamiento para la red neuronal encargada de
analizar
los
primeros
seis
encabezados
datos
de
de
cada
los
protocolos
registro
IP+TCP.
pertenecen
a
Los
los
atributos seleccionados de IP y los restantes corresponden a
datos del encabezado de TCP (comprimiendo las banderas en un
solo
elemento)
más
la
indicación
de
ataque
en
el
último
número a la derecha de cada tupla.
[4, 5, 0, 60, 2, 64, 46987, 80, 2, 14600, 0]
[4, 5, 0, 60, 2, 54, 80, 46987, 18, 4344, 0]
[4, 5, 0, 52, 2, 64, 46987, 80, 16, 913, 0]
[4, 5, 0, 469, 2, 64, 46987, 80, 24, 913, 1]
[4, 5, 0, 52, 2, 54, 80, 46987, 16, 6, 1]
Tabla 6.2: Ejemplo de 5 paquetes TCP procesados para entrenar la red
neuronal.
6.2 Entrenamiento de las redes neuronales
El entrenamiento de las redes neuronales se debe realizar
tomando en cuenta tres días completos de tráfico de DARPA-MIT
1999: se eligieron sin ninguna razón particular el lunes y
miércoles de la semana 4 y el lunes de la semana 5. En ambas
semanas se incluyeron algunos ataques mezclados con tráfico
98
normal de red.
Después de realizar cinco pruebas de entrenamiento con cada
una
de
las
valores
de
redes
neuronales,
configuración
con
que
el
fin
brindaran
de
obtener
los
los
mejores
resultados, se obtuvo la siguiente configuración final para
cada una de ellas (ver las tablas 6.3, 6.4 y 6.5).
Parámetro
Valor
Número de entradas
10
Número de neuronas de la capa oculta
7, 3
Número de neuronas de salida
1
Tasa de aprendizaje (learning rate)
0.6
Momentum
0.2
Error
0.001
Iteraciones
Tabla 6.3: Configuración de la red neuronal IP+TCP.
5000
Parámetro
Valor
Número de entradas
9
Número de neuronas de la capa oculta
6, 4
Número de neuronas de salida
1
Tasa de aprendizaje (learning rate)
0.4
Momentum
0.3
Error
0.001
Iteraciones
Tabla 6.4: Configuración de la red neuronal IP+UDP.
5000
99
Parámetro
Valor
Número de entradas
8
Número de neuronas de la capa oculta
6, 4
Número de neuronas de salida
1
Tasa de aprendizaje (learning rate)
0.5
Momentum
0.3
Error
0.001
Iteraciones
Tabla 6.5: Configuración de la red neuronal IP+ICMP.
5000
En todos los casos el máximo error permitido es de 0.001 lo
que
le
brinda
detectar
a
nuevos
las
redes
ataques
suficiente
sin
llegar
flexibilidad
a
estar
para
“sobre
entrenadas”, perdiendo así capacidad de generalización. Una
vez
alcanzado
dicho
margen
tolerable
de
error,
el
entrenamiento se detiene. Si no se hubiese alcanzado dicho
margen
de
error,
las
redes
harán
un
máximo
de
5000
iteraciones sobre el conjunto de datos de entrenamiento.
6.3 Ambiente de prueba
Las pruebas al prototipo se realizarán usando tráfico real
generado en una red LAN.
Al momento de realizar las pruebas, y con afán de simplificar
la
topología
sin
perder
confiabilidad,
se
utilizarán
servidores virtuales hospedados en un servidor físico con las
100
siguientes características de hardware: 2GB de memoria RAM, 1
CPU Intel® Core™ 2 Duo E8400 a 3.00GHz y una tarjeta de red
Intel® 82567LM-3 de 1Gbps.
Los ataques de prueba se realizarán contra los siguientes
servidores y servicios:
1.
Windows 2008 Server
1.1.
IIS
1.2.
SMB
2.
Ubuntu 12.04 LTS Desktop
2.1.
Apache + PHP
a)
Joomla! CMS
2.2.
3.
MySQL
Damn Vulnerable Linux
3.1.
Apache + PHP
a)
Joomla! CMS
3.2.
Si
bien
MySQL
Ubuntu
y
Windows
son
sistemas
operativos
relativamente bien conocidos, Damn Vulnerable Linux es una
distribución
operativo
de
Linux
consiste
en
que
un
no
lo
ambiente
es
tanto.
altamente
Este
sistema
vulnerable
a
diversos tipos de ataque que fue desarrollado por el IITAC
(International
Certification)
Institute
para
for
entrenar
a
Training,
Assessment
profesionales
en
and
seguridad
101
informática.
Para las pruebas se tomará en cuenta un servidor Windows con
dos de sus servicios básicos: el servidor web IIS sirviendo
solamente páginas estáticas y ASP; y el SMB para compartir
archivos en la red.
Por
otro
lado,
los
dos
Linux
(Ubuntu
y
el
DVL)
tendrán
exactamente el mismo software instalado aunque en distintas
versiones:
un
servidor
web
apache
con
los
módulos
para
ejecutar aplicaciones PHP y el motor de base de datos MySQL.
Sobre estos
dos servicios
Joomla!
idea
La
de
que
se ejecutará
ambos
la aplicación
tengan
el
mismo
web
software
consiste en que al momento de lanzar los ataques es muy
posible
que
fructifiquen
cuando
sean
contra
el
DVL
(que
cuenta con versiones vulnerables y antiguas del software)
mientras que con la última versión de Ubuntu (la 12.04 LTS)
los
ataques
no
surtan
ningún
efecto,
ya
que
cuenta
con
versiones estables y seguras del software.
Dado que todos los servidores virtuales (cada uno con su
respectiva
dirección
IP),
así
como
el
servidor
real
utilizarán la misma tarjeta de red física, el sniffer se
instalará en el servidor físico, aprovechando este punto de
concentración de tráfico de red.
El almacenamiento y análisis de datos del prototipo de IDS se
102
realizará sobre tres servidores distintos con características
de
hardware
idénticas:
1GB
de
memoria
RAM,
1
CPU
Intel®
Pentium® 4 a 2.8GHz y una tarjeta de red Realtek® de 1Gbps.
Sobre la misma LAN, se conectará una PC desde la cuál se
lanzarán los ataques contra los servidores virtuales.
Las características de hardware de la PC son: CPU Intel®
Centrino™ Duo a 1.83GHz, 1GB de memoria RAM, tarjeta de red
Intel® Gigabit Ethernet 82573L.
Aunque tanto la tarjeta de red de la PC como la de los
servidores pueden trabajar a 1 Gigabit, dado que el switch al
que se conectarán permite una velocidad máxima de 100Mbps, la
velocidad de tráfico entre los equipos estará limitada por
esta condición.
Esta topología se muestra en figura 6.1.
Figura 6.2: Topología empleada durante las pruebas.
El sistema operativo utilizado en la PC será Backtrack Linux
103
5.0.
Esta
distribución
está
diseñada
específicamente
para
realizar auditorías de seguridad informática ya que cuenta
con una gran variedad de herramientas de software utilizadas
comúnmente
para
este
fin.
Una
de
estas
herramientas
es
Metasploit. El Framework Metasploit es un software que ayuda
al
desarrollo
y
ejecución
de
exploits
en
computadoras
remotas.
Los
ataques
lanzados
contra
los
servidores
se
realizarán
utilizando la herramienta Nmap para el escaneo de puertos,
Joomscan
para
detectar
vulnerabilidades
en
Joomla!,
Metasploit para ataques con exploits, y la biblioteca Scapy
del lenguaje Python, para los ataques de más bajo nivel.
Adicionalmente, la PC también generará tráfico normal hacia
los servidores
virtuales como
consultas de
SQL, acceso
a
páginas web y transferencias de archivos.
La lista de los ataques que se ejecutarán se resume en la
tabla
6.6.
En
el
anexo
4
se
encuentra
una
descripción
detallada de algunos de los ataques mencionados en la tabla
6.6.
104
Ataque
Herramienta
Objetivo
Ping of death
Scapy
DVL
SYN flood
Scapy
DVL
Ubuntu
Windows
Scan attack
Nmap
DVL
Ubuntu
Windows
ARP spoofing
Scapy
DVL
Ubuntu
Windows
ms03_007_ntdll_webdav
Metasploit
Windows (IIS)
ms06_040_netapi
Metasploit
Windows (SMB)
ms07_029_msdns_zonename
Metasploit
Windows (SMB)
mysql_yassl_getname
Metasploit
DVL
Ubuntu
mysql_yassl_hello
Metasploit
DVL
Ubuntu
Joomscan
DVL
Ubuntu
Scan attack
Tabla 6.6: Ataques empleados durante las pruebas.
Se
realizarán
ataques.
tres
Durante
monitorizará
la
la
instancias
de
ejecución
salida
de
de
los
cada
cada
tres
uno
uno
nodos
de
estos
de
diez
ellos
se
encargados
de
almacenamiento y análisis con el fin de verificar si reportan
actividad anómala en el momento indicado.
De
los
ataques
a
ejecutar,
el
“scan
attack”,
el
“ARP
spoofing”, el “ping of death” y el “SYN flood” formaron parte
de los ataques con los que se entrenó la red neuronal.
105
Por otra parte, los ataques de metasploit y joomscan son
totalmente desconocidos para la red neuronal.
Vale la pena destacar que el “Scan attack” realizado por nmap
y
que
escaneo
es
de
conocido
puertos
por
en
las
la
redes
capa
de
neuronales,
transporte
realiza
(TCP,
un
UDP),
mientras que el escaneo que realiza la herramienta joomscan
es a nivel de la capa de aplicación, por lo que aunque el
concepto es el mismo, ambos ataques no resultan comparables.
Todo el tráfico de red se deberá guardar en formato tcpdump
con el fin de contabilizar la cantidad de paquetes empleados
durante el tráfico normal y los ataques.
106
7. RESULTADOS EXPERIMENTALES
En esta sección se exponen los resultados obtenidos durante
los experimentos
y en
el siguiente
capítulo (Análisis
de
resultados) se presenta su interpretación y justificación.
Siguiendo la metodología expuesta en la sección anterior, el
prototipo de IDS se enfrentó a tráfico normal y a tráfico
anómalo durante 30 ataques realizados a los tres servidores
instalados. Todos los ataques constan de múltiples paquetes
de red que pasan a través del sniffer. Debido a que el IDS
analiza uno a uno todos los paquetes recibidos, ocurrió que
algunas instancias de ataques fueron detectadas más de una
vez, durante el análisis de varios paquetes pertenecientes al
mismo ataque.
En estos
casos, aunque
se dieron
múltiples
alarmas para un solo ataque, se toma en cuenta para los
resultados solamente una única detección.
Otra situación que se dio, fue la detección de un mismo
ataque por diferentes redes neuronales, en el caso particular
de aquellos ataques que involucran tráfico en TCP y en UDP,
como los ataques de escaneo de puertos.
Los resultados obtenidos se dividieron tomando en cuenta el
tipo de tráfico al que fue sometido el IDS: tráfico normal,
ataques conocidos y ataques desconocidos.
107
7.1 Tráfico normal
Durante los momentos en que el IDS fue sometido al análisis
de tráfico normal se obtuvieron los resultados expuestos en
la tabla 7.1.
Tipo de
tráfico
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
Windows (IIS)
18672
0
-
DVL (Apache)
15793
0
-
Ubuntu
(Apache)
20419
0
-
8452
408
IP + TCP
DVL (MySQL)
568
48
IP + TCP
Ubuntu (MySQL)
721
0
-
Windows
121
0
-
98
0
-
Ubuntu
100
Tabla 7.1: Resultados obtenidos con tráfico normal.
0
-
Web
Objetivo
Trasferencia Windows (SMB)
de archivos
SQL
ICMP
DVL
De 64.944 paquetes en 11.35MB de tráfico normal, se emitieron
456 reportes que constituyen falsos positivos emitidos por el
sistema detector de intrusos. Dado que ninguno de ellos era
realmente un ataque, se cuentan de forma individual cada uno
de los reportes emitidos. En el gráfico de la figura 7.1 se
muestra
proporcionalmente
la
cantidad
total
de
paquetes
analizados, así como la porción de ellos que fue detectada
108
como anómala.
De
las
tres
redes
neuronales,
solo
una
de
ellas
emitió
reportes durante las actividades realizadas: 408 reportes se
desencadenaron con el tráfico de SMB en el servidor Windows y
48 reportes adicionales al realizar consultas SQL al servidor
DVL.
Falsos positivos con tráfico normal
456
Verdaderos negativos
Falsos positivos
64488
Figura 7.1: Gráfico de verdaderos negativos y falsos positivos detectados.
En términos porcentuales, un 0.70% de los paquetes fueron
identificados erróneamente como ataques en curso y el 99.30%
fueron detectados correctamente como verdaderos negativos.
109
7.2 Ataques conocidos
Se denomina “ataques conocidos” a aquellos que formaron parte
del entrenamiento de las redes neuronales. En este grupo de
encuentran:
1. El “scan attack” (nmap)
2. El “ARP spoofing”
3. El “ping of death”
4. El “SYN flood”
Cada uno de estos cuatro ataques fue ejecutado contra los
tres
servidores
en
operación,
lo
que
significa
que
cada
prueba está compuesta por doce ataques. Además, se realizaron
tres
pruebas
para
un
total
de
treinta
y
seis
ataques
conocidos ejecutados. Los resultados de dichas ejecuciones se
muestran en las tablas 7.2, 7.3 y 7.4.
Tipo de
ataque
Objetivo
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
“scan
Windows
4143
11
16
IP+TCP
IP+UDP
attack”
DVL
3982
0
-
(nmap)
Ubuntu
4062
0
-
“ARP
Windows
1237
0
-
DVL
2310
0
-
Ubuntu
1854
0
-
spoofing”
110
“ping
of Windows
death”
“SYN flood”
568
0
-
DVL
729
0
-
Ubuntu
597
0
-
Windows
35874
0
-
DVL
41413
0
-
Ubuntu
40578
0
Tabla 7.2: Resultados obtenidos con ataques conocidos. Prueba #1.
Tipo de
ataque
Objetivo
-
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
“scan
Windows
3957
13
6
IP+TCP
IP+UDP
attack”
DVL
4101
0
-
(nmap)
Ubuntu
4009
0
-
“ARP
Windows
1687
0
-
DVL
2811
0
-
Ubuntu
2409
0
-
674
0
-
DVL
569
0
-
Ubuntu
412
0
-
Windows
32745
0
-
DVL
29587
0
-
spoofing”
“ping
of Windows
death”
“SYN flood”
Ubuntu
41682
0
Tabla 7.3: Resultados obtenidos con ataques conocidos. Prueba #2.
-
111
Tipo de
ataque
Objetivo
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
“scan
Windows
4105
10
8
IP+TCP
IP+UDP
attack”
DVL
3984
0
-
(nmap)
Ubuntu
3895
0
-
“ARP
Windows
2678
0
-
DVL
1931
0
-
Ubuntu
2319
0
-
479
0
-
DVL
653
0
-
Ubuntu
594
0
-
Windows
44210
0
-
DVL
38517
0
-
spoofing”
“ping
of Windows
death”
“SYN flood”
Ubuntu
39466
0
Tabla 7.4: Resultados obtenidos con ataques conocidos. Prueba #3.
-
Aunque cada ataque está compuesto por una gran cantidad de
paquetes, la métrica a utilizar en este caso no serán los
paquetes, sino
la cantidad
de ataques
ejecutados para
no
perder la perspectiva de que lo realmente importante para el
IDS
es
detectar
los
ataques
usando
múltiples paquetes que lo componen.
cualquiera
de
los
112
Resultado con ataques conocidos
3
Falsos negativos
Verdaderos positivos
33
Figura 7.2: Gráfico de falsos negativos y verdaderos positivos.
Por cada prueba, compuesta por doce ataques, se obtuvo una
única detección. A nivel total, de los treinta y seis ataques
únicamente tres de ellos fueron detectados como tales (ver
figura 7.2). Porcentualmente, solo un 8.33% de los ataques
fueron detectados.
113
7.3 Ataques desconocidos
Se denomina “ataques desconocidos” a aquellos que no formaron
parte del
entrenamiento de
las redes
neuronales. En
este
grupo de encuentran:
1. ms03_007_ntdll_webdav
2. ms06_040_netapi
3. ms07_029_msdns_zonename
4. mysql_yassl_getname
5. mysql_yassl_hello
6. Scan attack (joomscan)
Al igual que con los ataques conocidos, se realizaron tres
pruebas con cada ataque. El total de ataques en cada una de
las pruebas es de nueve, por lo tanto, en total se someterá
al IDS a veintisiete instancias de seis ataques desconocidos.
Los
resultados
de
dichas
tablas 7.5, 7.6 y 7.7.
ejecuciones
se
muestran
en
las
114
Tipo de
ataque
Ms03_007_
Objetivo
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
Windows (IIS)
1326
0
-
Windows (SMB)
1267
0
-
Windows (SMB)
1452
0
-
1005
0
-
1147
0
-
689
0
-
627
0
-
3268
0
-
ntdll_webdav
Ms06_040_
netapi
Ms07_029_
msdns_
zonename
mysql_yassl_ Ubuntu (MySQL)
getname
DVL (MySQL)
mysql_yassl_ Ubuntu (MySQL)
hello
DVL (MySQL)
Scan
attack Ubuntu
(Joomla!)
(joomscan)
DVL (Joomla!)
2974
0
Tabla 7.5: Resultados obtenidos con ataques desconocidos. Prueba #1.
Tipo de
ataque
Ms03_007_
Objetivo
-
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
Windows (IIS)
1456
0
-
Windows (SMB)
1332
0
-
Windows (SMB)
1417
0
-
ntdll_webdav
Ms06_040_
netapi
Ms07_029_
msdns_
115
zonename
mysql_yassl_ Ubuntu (MySQL)
getname
DVL (MySQL)
mysql_yassl_ Ubuntu (MySQL)
hello
DVL (MySQL)
Scan
attack Ubuntu
(Joomla!)
(joomscan)
DVL (Joomla!)
1104
0
-
1293
0
-
715
0
-
687
0
-
3142
0
-
2978
0
Tabla 7.6: Resultados obtenidos con ataques desconocidos. Prueba #2.
Tipo de
ataque
Ms03_007_
Objetivo
-
Cantidad
total de
paquetes
Cantidad
de
reportes
Red
neuronal
Windows (IIS)
1437
0
-
Windows (SMB)
1472
0
-
Windows (SMB)
1440
0
-
1203
0
-
1198
0
-
814
0
-
762
0
-
3068
0
-
ntdll_webdav
Ms06_040_
netapi
Ms07_029_
msdns_
zonename
mysql_yassl_ Ubuntu (MySQL)
getname
DVL (MySQL)
mysql_yassl_ Ubuntu (MySQL)
hello
Scan
DVL (MySQL)
attack Ubuntu
(Joomla!)
(joomscan)
DVL (Joomla!)
3129
0
Tabla 7.7: Resultados obtenidos con ataques desconocidos. Prueba #3.
-
116
De
los
veintisiete
ataques
desconocidos,
no
se
detecto
ninguno, por lo tanto, los porcentajes de falsos negativos y
verdaderos positivos, son 100% y 0% respectivamente (figura
7.3).
Resultado con ataques desconocidos
falsos negativos
verdaderos positivos
Figura 7.3: Falsos negativos obtenidos
117
8. ANÁLISIS DE RESULTADOS
Los resultados revelaron un desempeño pobre al momento de
enfrentar el prototipo con tráfico real en una LAN.
En el proceso de interpretación de estos resultados hay dos
preguntas
que
surgieron
y
merecen
ser
analizadas
detalladamente:
1. ¿Son de calidad (correctos, completos, confiables) los
datos con que fueron entrenadas las redes neuronales?
2. ¿Son
suficientes
los
atributos
seleccionados
para
el
entrenamiento y posterior análisis de datos en las redes
neuronales?
Para responder la primera, vale la pena destacar que las
redes
neuronales
con
aprendizaje
supervisado
(como
las
utilizadas en este proyecto) siempre tendrán un rendimiento
tan bueno, como hayan sido sus datos de entrenamiento; si
existen deficiencias, carencias o sesgos, estos problemas se
verán reflejados en los resultados cuando la red neuronal sea
confrontada
con
datos
durante el entrenamiento.
diferentes
a
aquellos
utilizados
118
Puntualmente, algunos de los problemas del conjunto de datos
de entrenamiento que pudieron haber afectado el rendimiento
del IDS son:
•
En
los
datos
de
entrenamiento,
el
campo
TTL
del
encabezado IP de las máquinas que emitían los ataques
siempre era el mismo y distinto al de las máquinas que
generaban tráfico normal [36], lo cual es un sesgo que
una
red
neuronal
puede
aprender
fácilmente
y
al
confrontar la red neuronal con otros datos de la misma
fuente, generará buenos resultados, sin embargo, en otra
red que no cumpla con las mismas características los
resultados no serían igual de buenos.
•
La antigüedad de los ataques incluidos en los conjuntos
de datos DARPA-MIT, provocan que el entrenamiento de una
red
neuronal
modernos.
Si
entrenamiento
pierda
bien
capacidad
las
adecuado,
de
redes
detectar
neuronales,
aprenden
a
ataques
con
el
generalizar,
es
posible que un lapso de más de diez años entre los
ataques conocidos y los ataques desconocidos, haya sido
mucho mayor a la capacidad de generalización de una red
neuronal. Con esto surge la hipótesis de que existe una
ventana de tiempo máxima, en la evolución de los ataques
informáticos,
en
la
cual
una
red
neuronal
es
capaz
119
extrapolar
su
conocimiento
y
capacidad
de
generalización.
La segunda pregunta, sobre la suficiencia de los atributos de
los
protocolos
seleccionados
como
entrada
de
las
redes
neuronales, viene a confrontar las investigaciones realizadas
en
condiciones
de
laboratorio
ideales
versus
la
presente
investigación con condiciones de tráfico de red reales.
En esta investigación, los atributos seleccionados de cada
protocolo,
son
característica
y
aquellos
particular
que
del
brindan
emisor
y
información
receptor
de
la
comunicación, así como atributos administrativos que pueden
ser
manipulados
maliciosamente
para
perpetrar
un
ataque:
números de puerto, TTL, longitudes, entre otros (descritos
detalladamente en la sección 4).
Se omitieron aquellos que solo tienen validez en un contexto
particular de tiempo y espacio: direcciones IP, números de
secuencia,
verificaciones
de
integridad
o
checksum,
entre
otros.
De este modo, y con una selección de 25 atributos para los
protocolos
IP,
ICMP,
TCP
y
UDP,
se
puedo
comprobar
que
resulta insuficiente para una red neuronal de aprendizaje
supervisado, realizar las detecciones debidas.
120
Si bien es cierto, un 0.7% de falsos positivos durante el
tráfico normal es un buen resultado, durante la ejecución de
los ataques el rendimiento fue completamente inesperado e
incorrecto.
La detección de solamente el 8.33% de los ataques conocidos,
siendo en todos los casos el ataque de escaneo de puertos de
capa de transporte con la herramienta nmap, denota que existe
una particularidad en dicho ataque que facilita su detección
a
las
redes
durante
el
neuronales
proceso
de
de
IP+TCP
e
investigación
IP+UDP,
y
sin
búsqueda
embargo
de
dicha
particularidad, no se logró identificar claramente que un
atributo
o
grupo
de
atributos
tuviesen
una
distinción
particular.
8.1 Comparación con otras investigaciones
Durante
la
construcción
revisión
del
bibliográfica
Marco
teórico
de
realizada
esta
para
investigación,
la
se
constató que en todos los trabajos previos sobre el tema, se
lograban
resultados
sobresalientes
utilizando
redes
neuronales (ver anexo 9).
La pregunta que salta a la vista es: ¿cuál es la diferencia
de
las
condiciones
entre
este
proyecto
y
las
demás
121
investigaciones?
Cuando se
definió la
metodología, se
decidió utilizar
el
conjunto de datos DARPA-MIT Intrusion Detection Evaluation
1999, ya que este constituye una de las únicas fuentes de
datos sobre el tema de la detección de intrusos en redes
informáticas.
Los datos de DARPA-MIT son utilizados por prácticamente todas
investigaciones previas, sin embargo, las demás utilizan la
versión preprocesada del conjunto de datos de 1998, llamada
KDD '99.
En
KDD
'99
(descrito
en
la
sección
2.4),
los
datos
son
preprocesados y proveen información adicional de múltiples
fuentes
(protocolos
de
red,
sistema
operativo,
etc.),
mientras que la presente investigación utiliza solo los datos
de red de DARPA-MIT 1999.
Algunos ejemplos concretos de atributos incluidos en KDD '99
que favorecen
la obtención
de buenos
resultados en
otras
investigaciones son:
•
El
atributo
“sospechosos”
“hot”:
[37],
Es
sin
un
número
embargo
no
de
indicadores
indican
cómo
se
obtiene dicho número.
•
El atributo “srv_count”: Indica el número de conexiones
a un mismo servicio en los últimos dos segundos [37].
122
•
El
atributo
“dst_host_same_src_port_rate”:
Indica,
porcentualmente, la tasa de utilización de un puerto
particular, del host destino [37]
Contar con estos atributos resulta ser muy conveniente ya que
caracterizan
significativamente
a
algunos
de
los
ataques.
Para demostrar esto, se seleccionaron once ataques incluidos
en KDD '99 y se determinó con qué frecuencia estos tres
atributos
identificaban
la
presencia
o
ausencia
de
algún
ataque específico.
Los siguientes resultados fueron obtenidos con base en el
subconjunto de datos KDD '99 disponible en [38], con 494.021
registros de conexiones.
Para el caso del atributo “hot”, los resultados se detallan
en la tabla 8.1 y gráficamente se muestran en la figura 8.1.
En los casos que el atributo “hot” es mayor que cero, se
tiene
que,
de
manera
sobresaliente,
identifica
el
ataque
“Back” en un 99,59% de los casos, un ataque “guess_passwd” en
un 98,11% de los casos y un “BoF” en un 73,33% de los casos.
En cuanto al tráfico normal, solamente un 0,56% de los casos
posee este atributo con un valor mayor que cero, por lo que
se puede identificar con un más del 99% de certeza, que
cuando el atributo “hot” es cero, el tráfico es normal.
123
Ataque
Frecuencia de
identificación
Tráfico normal
0,56%
Back
99,59%
BoF
73,33%
Ftp_write
25,00%
Guess_passwd
98,11%
Imap
16,67%
ip_sweep
0,00%
Land
0,00%
Nmap
0,00%
Port_sweep
0,19%
Smurf
0,00%
warezmaster
5,00%
Tabla 8.1: Capacidad del atributo “hot” para identificar ataques.
Tasa de detección con el atributo “hot”
120,00%
100,00%
80,00%
60,00%
40,00%
20,00%
0,00%
a
warezm
smurf
ster.
ep
passwd
e ep
port_sw
normal
nmap
land
ip_swe
imap
guess_
e
ftp_writ
BoF
back
Figura 8.1: Capacidad del atributo “hot” para identificar ataques.
124
De forma análoga, se identificó que el atributo “srv_count”
caracteriza con gran certeza los ataques “smurf” y “imap”
(99,98%
y
66,67%
“srv_count”
es
respectivamente),
mayor
que
cuando
cincuenta.
el
Es
valor
de
claramente
diferenciable también, el tráfico normal. El detalle de los
resultados para los once ataques se muestra en la tabla y
gráfico 8.2.
Ataque
Frecuencia de
identificación
Tráfico normal
1,31%
Back
0,00%
BoF
0,00%
Ftp_write
0,00%
Guess_passwd
0,00%
Imap
66,67%
ip_sweep
3,45%
Land
0,00%
Nmap
3,46%
Port_sweep
0,00%
Smurf
99,98%
warezmaster
0,00%
Tabla 8.2: Capacidad del atributo “srv_count” para
identificar ataques.
125
Tasa de detección con el atributo “srv_count”
120,00%
100,00%
80,00%
60,00%
40,00%
20,00%
0,00%
a
warezm
smurf
ster
ep
passwd
e ep
port_sw
normal
nmap
land
ip_swe
imap
guess_
e
ftp_writ
BoF
back
Figura 8.2: Capacidad del atributo “srv_count” para identificar ataques.
Otro de los atributos que identifica gran cantidad de ataques
y
discrimina
notablemente
el
tráfico
normal
es
el
“dst_host_same_src_port_rate”.
Los resultados de los once ataques más el tráfico normal,
tomando como referencia este atributo se muestran en la tabla
y figura 8.3.
Este atributo posee gran capacidad para identificar nueve de
los once ataques analizados, cuando tiene un valor mayor a
0,5.
126
Ataque
Frecuencia de
identificación
Tráfico normal
5,66%
Back
0,36%
BoF
73,33%
Ftp_write
100,00%
Guess_passwd
5,66%
Imap
66,67%
ip_sweep
92,78%
Land
85,71%
Nmap
98,27%
Port_sweep
89,13%
Smurf
99,97%
warezmaster
90,00%
Tabla 8.3: Capacidad del atributo
“dst_host_same_src_port_rate” para identificar ataques.
Tasa de detección con el atributo
“dst_host_same_src_port_rate”
120,00%
100,00%
80,00%
60,00%
40,00%
20,00%
0,00%
a
warezm
smurf
ster
ep
d
passw
e ep
port_sw
normal
nmap
land
ip_swe
imap
guess_
e
ftp_writ
B oF
back
8.3. Figura: Capacidad del atributo “dst_host_same_src_port_rate” para identificar
ataques.
127
De este modo, no es posible establecer una justa comparación
entre la presente investigación y los demás trabajos, ya que
las bases de operación son completamente diferentes.
128
9. CONCLUSIONES
•
Si
bien,
uno
de
los
objetivos
de
utilizar
redes
neuronales en sistemas de detección de intrusos es su
capacidad de generalizar para detectar ataques nuevos
basándose en un entrenamiento con ataques conocidos, se
pudo notar
que al
entrenar las
redes neuronales
con
datos de hace más de diez años, éstas tienen serios
problemas detectando ataques modernos.
•
Las condiciones ideales de operación de un IDS, en las
que se cuenta con información preprocesada de alto nivel
discriminatorio entre los tipos de tráfico, están muy
lejos de ser las mismas condiciones de operación de un
IDS
basado
solamente
en
el
tráfico
de
red,
lo
que
influye de manera directa en la capacidad de detección
de un IDS.
•
Las redes neuronales con aprendizaje supervisado no son
las más aptas para la detección de intrusos en ambientes
reales debido a que requieren de datos de entrenamiento
confiables, inexistentes en este momento.
•
Queda pendiente mucho trabajo de investigación antes de
poder ver en el mercado algún producto de detección de
129
intrusos basado en redes neuronales.
Entre
los
principales
aportes
de
esta
investigación
se
identifican:
Se demostró
•
datos
en la
DARPA-MIT
práctica, la
para
evaluar
y
insuficiencia de
entrenar
los
Sistemas
de
Detección de Intrusos.
A diferencia de otras investigaciones, en la presente se
•
enfatizó sobre el análisis en tiempo real de datos de
auditoría provenientes únicamente desde la red.
Se probó la factibilidad de implementar una arquitectura
•
de IDS distribuida, que es una de las recomendaciones de
múltiples investigaciones previas [20, 8, 13, 1 y 12].
Se diseñó una arquitectura de IDS modular que permite la
•
fácil experimentación con nuevos mecanismos de detección
por investigar en el futuro.
9.1
El
Trabajo futuro
campo
de
investigación
en
sistemas
de
detección
de
intrusos está completamente abierto al desarrollo de nuevos
mecanismos
de
detección
que
sean
más
eficientes,
menos
intrusivos y más sencillos de configurar y administrar.
Entre
las
tareas
pendientes
para
que
se
desarrolle
130
adecuadamente este campo de investigación, está la creación
de un nuevo conjunto de datos que sirva tanto para evaluar
IDSs, como para entrenarlos en caso de que se utilicen redes
neuronales
con
aprendizaje
supervisado
como
mecanismo
de
detección. Dicha labor no es para nada trivial en una red con
una
gran
cantidad
aleatoriedad
de
del
equipos,
tráfico
ya
que
real
la
concurrencia
requiere
de
y
extrema
coordinación, control y monitorización de los distintos nodos
para poder etiquetar correctamente los datos como “tráfico
anómalo” o “tráfico normal”.
Otra línea de investigación interesante sería utilizar redes
neuronales con aprendizaje no supervisado, de modo que no sea
un
requerimiento
conjunto
de
clasificación
indispensable
datos
de
de
este
contar
de
entrenamiento.
tipo
de
redes
antemano
La
con
capacidad
neuronales,
un
de
podría
resultar útil para determinar si un determinado paquete de
red está completamente fuera de un patrón (lo que indicaría
una posible anomalía) o si más bien está agrupado con otros
paquetes similares.
La utilización de sensores remotos en distintos puntos de la
red,
con
el
fin
de
obtener
tráfico
de
distintas
fuentes
podría facilitar también la detección de ciertos tipos de
ataques que se desarrollan a lo interno de la LAN, sin pasar
131
nunca por un punto concentrador de tráfico, como el gateway o
puerta de enlace de una red.
La profundidad
de análisis
sobre los
datos de
auditoría,
sigue siendo un punto por investigar detenidamente, ya que es
posible
que
cierto
tipo
de
ataques
sean
fácilmente
identificables mediante un mecanismo de análisis específico,
mientras que para otros ataques, sean otros los mecanismos
más eficientes. La idea de que la combinación de mecanismos
de detección hará más eficientes a los IDSs, es por ahora,
una hipótesis por demostrar.
132
10.
Anexos
10.1
Anexo 1: Evolución de los ataques
informáticos
Relación entre la cantidad y sofisticación de los ataques en
el tiempo. Fuente [25].
133
10.2
Anexo 2: Componentes de una red neuronal artificial
a) Representación gráfica de una neurona.
b) Función de umbral.
c) Gráfica de la función Sigmoid.
134
10.3
Anexo 3: Taxonomía de ataques de Hansman y Hunt
Fuente [14].
Dimensión
Vector
ataque
Descripción
de Es el medio que se utiliza para perpetrar el ataque.
Por
ejemplo,
si
se
replica
solo
y
usando
la
red,
significa que es un gusano. Podría especificarse más
indicando que el medio de propagación por la red es el
correo electrónico.
Objetivo
En esta dimensión se detalla el elemento específico que
del ataque será
atacado.
Por
ejemplo,
una
jerarquía
en
esta
dimensión podría ser: Software → Sistema operativo →
Unix → FreeBSD → 5.1.
Vulnerabi- Indica
lidades
la
o
las
vulnerabilidades
presentes
en
el
objetivo del ataque y que hacen posible que el atacante
tenga éxito. El estándar de facto para clasificación de
vulnerabilidades es el Common Vulnerabilities Exposures
(CVE). Por ejemplo, se puede indicar en esta dimensión
que la vulnerabilidad posee la referencia pública CVE2001-0500.
Payload
Especifica la acción del malware una vez instalado y
ejecutado. Por ejemplo, un gusano podría tener como
payload la instalación de una puerta trasera que le
permita el acceso irrestricto al atacante creador del
gusano.
135
10.4
Anexo 4: Descripción de ataques comunes
10.4.1
SYN flood
Descripción
El establecimiento de una conexión TCP se realiza mediante un
procedimiento conocido como “3 way handshake” que se observa
en la figura. El ataque de SYN flood consiste en que el
cliente (atacante) envía un paquete SYN al servidor (víctima)
que
contesta
normalmente
con
el
SYN/ACK,
sin
embargo
el
cliente nunca contesta el ACK del paso 3, sino que repite el
procedimiento una cantidad indeterminada de veces con el fin
de agotar la memoria que el servidor tiene para conexiones
136
pendientes. Una descripción muy detallada de este ataque se
puede encontrar en [7].
Impacto
Sistemas que proveen servicios basados en TCP sobre Internet,
podrían ser incapaces de proveer dichos servicios mientras se
encuentren bajo ataque e inclusive algún tiempo después del
ataque.
El servicio en sí no sufre de ningún daño, solamente la
posibilidad de accederlo se ve afectada.
Detección
A nivel de IDS sobre la red, la detección de este ataque
puede realizarse tomando en cuenta el balance entre paquetes
de SYN y ACKs [29].
A nivel de IDS de sistema operativo, la detección del ataque
puede
realizarse
analizando
las
tablas
de
estado “SYN_RECEIVED”, como se detalla en [7].
conexiones
en
137
10.4.2 Ping of death
Descripción
Este ataque consiste en el envío de un datagrama IP de un
tamaño
mayor
paquete
ICMP,
al
permitido.
echo
Concretamente
request,
el
popularmente
envío
de
conocido
un
como
“ping”.
El tamaño máximo total de un datagrama IP es de 65535 bytes,
sin embargo, es común que dichos datagramas se fragmenten de
acuerdo a los requerimientos de las capas inferiores. Cada
uno de esos fragmentos contiene el desplazamiento de memoria
adecuado para que el receptor del datagrama pueda reensamblar
todos los segmentos y obtener así, el datagrama IP original.
El
ataque
ellos
consiste
en
completamente
enviar
legales,
múltiples
pero
que
fragmentos,
al
momento
todos
de
la
reensamblación formen un datagrama ilegal.
Si bien es cierto la aparición de este ataque fue en la
segunda mitad de la década de los 90 y podría considerarse
completamente obsoleto, en el 2011 un conjunto de sistemas
operativos
de
Microsoft®
requirió
de
una
actualización
urgente para subsanar dicha vulnerabilidad [26].
Debido
a
(cámaras,
la
reciente
teléfonos,
proliferación
impresoras,
de
etc)
dispositivos
es
IP
recomendable
138
verificar
que
la
implementación
del
protocolo
sea
la
apropiada.
Impacto
Es un ataque que se clasifica como de Denegación de Servicio
(DoS) ya que provoca que los sistemas se apaguen, reinicien o
congelen,
por
lo
que
se
considera
una
vulnerabilidad
de
impacto muy alto.
Un aspecto que agrava la condición de esta vulnerabilidad es
la facilidad con la que puede ser explotado, ya que solamente
se requiere de la dirección IP del objetivo para enviar el
ataque con el ping ilegal.
Detección
A nivel de sistema operativo la detección es relativamente
sencilla: se debe validar que la reensamblación del datagrama
IP quepa en el tamaño máximo permitido de 65.535 bytes.
Sin embargo, para que un IDS basado en la red pueda detectar
este tipo de ataques, es necesario que además de analizar
cada uno de los fragmentos de forma individual, él mismo
pueda realizar la reensamblación para verificar de manera
estricta el cumplimiento del datagrama con respecto al RFC791.
139
10.5
Anexo 5: Estadísticas de utilización de IDSs en Costa
Rica
Software de seguridad utilizado en instituciones públicas1.
Porcentaje de utilización de Sistemas de Detección de Intrusos en instituciones públicas.
1 Datos tomados de [27].
140
10.6
Anexo 6: Atributos incluidos en el conjunto de datos
KDD '99
a) Características básicas de conexiones TCP individuales
Atributo
Descripción
Duración (en segundos) de la conexión
duration
protocol_type
Tipo de protocolo (ej. tcp, udp, etc.)
service
Nombre del servicio (ej. http, telnet, etc.)
Número de bytes desde la fuente hacia el destino
src_bytes
Número de bytes desde el destino hacia la fuente
dst_bytes
Estatus normal o de error en la conexión
flag
1 si la conexión es desde/hacia el mismo host/puerto; 0 en otro caso
land
Número de fragmentos erróneos
wrong_fragment
Número de paquetes urgentes
urgent
Tipo
Continuo
Discreto
Discreto
Continuo
Continuo
Discreto
Discreto
Continuo
Continuo
b) Características del contenido dentro de una conexión sugeridas por el conocimiento del dominio.
Atributo
Descripción
Tipo
Número de indicadores “sospechosos”
Continuo
hot
Número de intentos fallidos de ingreso (login)
Continuo
num_failed_logins
1
ingreso
(login)
satisfactorio;
0
en
otro
caso
Discreto
logged_in
num_compromised
Número de condiciones “comprometidas”
Continuo
root_shell
1 si se obtuvo una terminal de root; 0 en otro caso
Discreto
su_attempted
1 si se intentó el comando “su root”; 0 en otro caso
Discreto
num_root
Número de accesos del usuario root
Continuo
num_file_creations
Número de archivos creados
Continuo
num_shells
Número de terminales
Continuo
num_access_files
Número de operaciones en archivos de control de acceso
Continuo
num_outbound_cmds Número de comandos de salida en una sesión de FTP
Continuo
is_hot_login
1 si se considera un ingreso (login) “sospechoso”; 0 en otro caso
Discreto
is_guest_login
1 si el ingreso (login) es de un usuario “invitado”; 0 en otro caso
Discreto
c) Características del tráfico en un lapso de dos segundos.
Atributo
Descripción
count
Número de conexiones al mismo host
Nota: Los siguientes atributos se refieren al host
serror_rate
% de conexiones que tienen errores de “SYN”
rerror_rate
% de conexiones que tiene errores de “REJ”
same_srv_rate
% de conexiones al mismo servicio
% de conexiones a diferente servicio
diff_srv_rate
Número de conexiones al mismo servicio
srv_count
Nota: Los siguientes atributos se refieren al servicio
% de conexiones que tienen errores de “SYN”
srv_serror_rate
% de conexiones que tiene errores de “REJ”
srv_rerror_rate
% de conexiones a diferentes hosts
srv_diff_host_rate
Tipo
Continuo
Continuo
Continuo
Continuo
Continuo
Continuo
Continuo
Continuo
Continuo
141
10.7
Anexo 7: Código fuente pcap_processor.py
#******************************************************************************
# El código totalmente comentado se encuentra en el disco compacto con la totalidad del software
# desarrollado en este proyecto de tesis
#******************************************************************************
from scapy.all import *
if __name__ == "__main__":
input_file_name = sys.argv[1]
output_file_name_icmp = 'icmp.out'
output_file_name_tcp = 'tcp.out'
output_file_name_udp = 'udp.out'
file_handler_icmp = open(output_file_name_icmp, 'a')
file_handler_tcp = open(output_file_name_tcp, 'a')
file_handler_udp = open(output_file_name_udp, 'a')
# Read the whole file
full_data_list = rdpcap(input_file_name)
# Keep only IP packets with TCP, UDP or ICMP above
filtered_data_list = [pkt for pkt in full_data_list
if IP in pkt and
# IP with...
(pkt[IP].proto == 6 or # tcp or
pkt[IP].proto == 17 or
# udp or
pkt[IP].proto == 1)]
# icmp
for pkt in filtered_data_list:
# Set selected IP header fields
vector = [int(pkt[IP].version), int(pkt[IP].ihl), int(pkt[IP].tos),
int(pkt[IP].len), int(pkt[IP].flags), pkt[IP].ttl,
pkt[IP].proto]
if UDP in pkt:
vector.append(pkt[UDP].sport)
vector.append(pkt[UDP].dport)
vector.append(pkt[UDP].len)
file_handler_udp.write(str(vector) + '\n')
elif TCP in pkt:
vector.append(pkt[TCP].sport)
vector.append(pkt[TCP].dport)
vector.append(int(pkt[TCP].flags))
vector.append(pkt[TCP].window)
file_handler_tcp.write(str(vector) + '\n')
elif ICMP in pkt:
vector.append(pkt[ICMP].type)
vector.append(pkt[ICMP].code)
file_handler_icmp.write(str(vector) + '\n')
file_handler_icmp.close()
file_handler_tcp.close()
file_handler_udp.close()
142
10.8
Anexo 8: Código fuente batch.sh
#!/bin/bash
# Author: Herson Esquivel Vargas
# Date: 05 / 04 / 2012
# Description:
# Due to memory constraints in the python script (scapy library), it was needed
# to shrink the pcap files into smaller ones (~2MB each one) to work properly .
# Then, the whole set of .pcap files is processed with this script.
#***************************************************************
# Initial timestamp
date
# Search all .pcap files
FILES=`ls *.pcap`
# For each of them
for file in $FILES
do
python pcap_processor.py $file
done
# Compress output
tar -czf tarball.tar.gz *.out
# Final timestamp
date
exit 0
# eof
# Parse with the python script
143
10.9
Anexo 9: Resultados de investigaciones previas
144
11.
BIBLIOGARFÍA
[1] Ahmad, I., Abdullah, A. B., & S Alghamdi, A. “Application
of
artificial
attacks”.
neural
IEEE
network
Symposium
on
in
detection
Industrial
of
probing
Electronics
&
Applications, (Isiea), págs. 557-562, 2009.
[2]
Akram,
A.,
Comparative
Ahmad,
Analysis
I.,
Pervez,
of
S.,
Artificial
Swati,
Neural
S.
U.
“A
Network
Technologies in Intrusion Detection”. Proceedings of the 6th
WSEAS Internationa Conference on Multimedia, Internet & Video
Technologies, págs 84-89, 2006.
[3] Anderson, D., Frivold, T., Valdes, A. “Next-generation
Intrusion Detection Expert System (NIDES): A Summary”. SRI
International, Computer Science Laboratory, 1995.
[4] Anderson, J. “Computer security threat monitoring and
surveillance”. Technical report, Fort Washington, 1980.
[5]
Biermann,
E.
“A
comparison
of
Intrusion
Detection
systems”. Computers Security, Vol. 20 Núm.8, págs. 676-683,
2001.
145
[6] Birkely, R. “A Neural Network Based Intelligent Intrusion
Detection System”. Masters Disertation, Griffith University,
2003.
[7]
CERT.
“Advisory
Spoofing Attacks”.
CA-1996-21
TCP
SYN
Flooding
and
IP
Fecha de consulta: Abril 3, 2012 desde:
http://www.cert.org/advisories/CA-1996-21.html
[8] Chavan, S., Shah, K., Dave, N., Mukherjee, S., Abraham,
A.,
Sanyal, S. “Adaptive Neuro-Fuzzy Intrusion Detection
Systems”.
Proceedings
of
the
International
Conference
on
Information Technology: Coding and Computing (ITCC’04), 2004.
[9] Christos J. P. Moschovitis. History of the Internet: a
chronology, 1843 to the present. Estados Unidos de América,
University of Michigan, 1999.
[10] Debar, H., Becker, M., Siboni, D. “A neural network
component for an intrusion detection system.” Research in
Security
and
Privacy,
1992.
Proceedings.,
Society Symposium, págs. 240–250, 1992.
IEEE
Computer
146
[11] Desai, N. “Intrusion Prevention Systems: the Next Step
in
the
Evolution
of
IDS”.
Publicado
en
línea
desde:
http://www.symantec.com/connect/es/articles/intrusionprevention-systems-next-step-evolution-ids, 2010.
[12] Faysel, M. A., Haque, S. S. “Towards Cyber Defense:
Research
in
Intrusion
Detection
and
Intrusion
Prevention
Systems”. Journal of Computer Science and Network Security,
Vol. 10 Núm 7, págs. 316-325, 2010.
[13]
Grandison,
T.,
Terzi,
E.
"Intrusion
Detection
Technology", Publicado en línea, 2007.
[14]
Hansman,
S.,
computer attacks”.
Hunt,
R.
“A
Computers &
taxonomy
of
Security, Vol.
network
24 Núm.
and
1,
págs. 31-43, 2005.
[15] Haykin, S. Neural Networks: A Comprehensive Foundation.
Estados Unidos de América, Prentice Hall, 1999.
[16] Hu, X. “Large-Scale Malware Analysis, Detection, and
Signature Generation”. Doctoral Dissertation, University of
Michigan, 2011.
147
[17]
IBM
(2010).
“Taming
the
data
daemons:
leveraging
information in the age of risk”. Fecha de consulta: Marzo 28,
2011
desde
http://www-
935.ibm.com/services/us/gbs/bus/html/risk_study.html.
[18] Joo, D., Hong, T., Han, I. “The neural network models
for
IDS
errors
based
and
on
the
false
asymmetric
positive
costs
errors”.
of
false
Expert
negative
Systems
with
Applications, Vol. 25 Núm. 1, págs. 69-75, 2003.
[19]
Letia,
Intrusion
I.,
&
Alex,
Detection,
D.
with
“Embarking
Erlang”.
on
10th
the
road
of
International
Conference on Development and Application Systems, 2010.
[20] Li, J., Zhang, G.-yin, Gu, G.-chang. “The research and
implementation
of
intelligent
intrusion
detection
system
based on artificial neural network”. Machine Learning and
Cybernetics. Proceedings
of 2004
International Conference,
Vol. 5, págs. 3178–3182, 2004.
[21] Lincoln Laboratory, MIT. “Cyber Systems and Technology:
DARPA
Intrusion
Febrero
Detection
15,
Evaluation”,
2012
Fecha
de
consulta:
desde:
148
http://www.ll.mit.edu/mission/communications/ist/CST/index.ht
ml
[22] Lippmann, R., Haines, J. W., Fried, D. J., Korba, J.,
Das,
K.
“The
1999
DARPA
off-line
intrusion
detection
evaluation”. Computer Networks, Vol. 34 Núm. 4, págs. 579–
595, 2000.
[23] Lunt, T. et al. “A Real-Time Intrusion-Detection Expert
System (IDES)”. SRI International. Final Technical Report,
1992.
[24] Mahoney, M. V. “Draft: Intrusion Detection by Low Level
Anomalies in Network Traffic”, Publicado en línea, 2000.
[25]
Mchugh,
Publicado
en
J.
línea:
“Intrusion
27
and
Julio,
intrusion
2001
–
©
detection”.
Springer-Verlag,
Pittsburgh, 2001.
[26]
TCP/IP
Microsoft
Stack
consulta:
Security
Could
Allow
Junio
TechCenter.
Denial
5,
of
“Vulnerabilities
Service”.
2012
Fecha
in
de
desde:
http://technet.microsoft.com/en-us/security/bulletin/ms11-064
149
[27] Ministerio de Ambiente, Energía y Telecomunicaciones.
“Estado de
la Seguridad
Informática en
el Sector
Público
Costarricense”. Costa Rica: MINAET, 2011.
[28]
Moradi,
system
for
M.,
Zulkernine,
intrusion
M.
detection
“A
neural
and
network
based
classification
of
attacks”. Queen University, Canada. Publicado en línea, 2004.
[29]
Patcha,
detection
A.,
Park,
techniques:
J.
M.
Existing
“An
overview
solutions
of
anomaly
and
latest
technological trends”. Computer Networks, Vol. 51 Núm 12,
2007.
[30] Paxson, V., Berkeley, L. “Bro: A System for Detecting
Network Intruders in Real-Time”. Computer Networks, Vol. 31
Núm. 24, págs. 2435-2463, 1999.
[31] Pfleeger, C. Security in Computing. Estados Unidos de
América, Prentice Hall, 1997.
[32] Presidencia de la República y Ministerio de Ciencia y
Tecnología. “Creación del centro de respuesta de incidentes
de seguridad informática CSIRT-CR”. Publicado en el Diario
150
Oficial “La Gaceta” 72 del 13 de Abril del 2012.
[33] Ryan, J., Meng-Jang, L., Miikkulainen, R. “Intrusion
detection
with
neural
networks”.
Advances
in
neural
information processing systems 10. MIT Press, 1998.
[34] Scapy. “About Scapy”.
Fecha de consulta: Enero 15, 2012
desde http://www.secdev.org/projects/scapy/
[35] Thanasekaran, R. D. “A Robust and Efficient Real Time
Network Intrusion Detection System Using Artificial Neural
Network In Data Mining”. International Journal of Information
Technology Convergence and Services, Vol. 1 Núm. 4, págs. 1019, 2011.
[36] Thomas, C., Sharma, V., Balakrishnan, N. “Usefulness of
DARPA
dataset
for
intrusion
detection
system
evaluation”.
Proceedings of SPIE, 2008.
[37] University of California, Irvine. “KDD Cup 1999 Data”.
Fecha
de
consulta:
Marzo
25,
2012
http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.html
desde:
151
[38] University of California, Irvine. “KDD Cup 1999 Data”.
Fecha
de
consulta:
Marzo
25,
2012
desde:http://kdd.ics.uci.edu/databases/kddcup99/kddcup.data_1
0_percent.gz
[39]
Visumathi,
J.,
Shunmuganathan,
K.
“A
computational
intelligence for evaluation of intrusion detection system”.
Indian Journal of Science and Technology, Vol. 4 Núm. 1,
págs. 40-45, 2011.
[40] Weitzenfeld, A., Arbib, M., Alexander, A. The Neural
Simulation Language: A System for Brain Modeling. Estados
Unidos de América, MIT Press, 2002.
[41]
Yao,
J.,
Zhao,
S.,
Saxton,
L.
“A
study
on
fuzzy
intrusion detection”. Publicado en línea, 2005. Disponible en
http://citeseerx.ist.psu.edu/viewdoc/summary?
doi=10.1.1.63.2767