134---Fosf-

•

IPN

Todos los Materiales

21/10/2022

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Introducción al Derecho I

136.593 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y
ELÉCTRICA
UNIDAD CULHUACAN

SEMINARIO DE TITULACIÓN
“SEGURIDAD DE LA INFORMACIÓN”

TESINA

“IMPLEMENTACIÓN DE UN IDS CON SNORT COMO
HERRAMIENTA DE MONITORIZACIÓN”

QUE PRESENTAN PARA OBTENER EL TÍTULO DE
INGENIERO EN COMPUTACIÓN

MARTÍNEZ OLIVARES MARÍA ANDREA
PULIDO BAUTISTA JUAN JOSÉ

Asesores:
DR. GABRIEL SANCHEZ PÉREZ
ING. ARTURO DE LA CRUZ TELLEZ

VIGENCIA: DES/ESIME-CUL-2008/23/1/09

México, D.F., Abril 2010

AGRADECIMIENTOS

A mi familia.

Quiero expresar un profundo agradecimiento a todos aquellos, quiénes con su
ayuda, apoyo y comprensión me impulsaron a cerrar esta etapa en mi vida
académica y me impulsan a continuar cosechando éxito en mi vida profesional.

María Andrea Martínez Olivares.

Agradezco a todas las personas que estuvieron cerca de mí, sobre todo a mi esposa
que siempre me fortalece para seguir adelante, a mi futuro fruto que viene en camino
y a mis padres. Sencillamente quiero decirles a todos mis compañeros, amigos y los
que han confiado incondicionalmente en mi, gracias.

Juan José Pulido Bautista.

INDICE GENERAL

PAGS.

OBJETIVO ............................................................................................................ I

JUSTIFICACIÓN .................................................................................................. II

INTRODUCCIÓN ................................................................................................. III

CAPITULO I ANTECEDENTES
1.1. Definición de un IDS ................................................................... 2
1.2. Clasificación de un IDS ................................................................... 2
1.3. Requisitos de un IDS ................................................................... 4
1.4. IDS basado en red (NIDS) ......................................................... 5
1.5. Diferentes herramientas de IDS ......................................................... 12

CAPITULO II IDS CON SNORT
2.1. IDS de red: SNORT ................................................................... 16
2.2. Estructura de las reglas ................................................................... 20
2.3. Componentes de SNORT ................................................................... 20
2.4. Ejemplo de SNORT ................................................................... 23

CAPITULO III IMPLEMENTACION DE UN IDS
3.1. Escenario de Implementación ......................................................... 34
3.2. Instalación del software ................................................................... 36
3.3. Configuración de SNORT ................................................................... 45
3.3.1 Configuración de red ......................................................... 45
3.3.2 Configuración de reglas ......................................................... 45
3.3.3 Configuración de acceso ......................................................... 46
3.4. Configuración MySQL ................................................................... 49

3.5. Configuración de PHP ................................................................... 51
CAPITULO IV PRUEBAS EN EL NIDS
4.1. Funcionamiento de SNORT ......................................................... 54
4.2. Servicios de MySQL ……............................................................ 59
4.3. Implementación de una interfaz web .............................................. 62

CONCLUSIONES ................................................................................................... 64

BIBLIOGRAFÍA ......................................................................................... 66

INDICE DE FIGURAS

PAGS.

CAPITULO I ANTECEDENTES

CAPITULO II IDS CON SNORT
2.1. Diagrama de los componentes de SNORT ......................... 21

CAPITULO III IMPLEMENTACION DE UN IDS
3.1 Escenario de implementación de un NIDS ………………………… 35
3.2 Iniciando la instalación de Snort ….…………………………………….. 36
3.3 Opciones de instalación …..…………………………………............... 37
3.4 Componentes necesarios para instalar Snort ….…………................. 38
3.5 Ruta de instalación de Snort …………….………………………….. 38
3.6 Instalación exitosa de Snort ………………………………………... 39
3.7 Iniciando la instalación de WinPcap 4.1 ……...………………………… 40
3.8 Opciones de instalación de WinPcap ………...……………………… 41
3.9 Finalizando la instalación de WinPcap ……..…………………………. 41
3.10 Instalación de Xampp 1.5.3 ………………….…………………….. 42
3.11 Activación de servicio de Apache, MySQL ………………………... 42
3.12 Servicios y puertos asignados de Apache ….…………………….. 43
3.13 MySQL asignado al puerto 3306 ………….…………………………….. 43
3.14 Instalación satisfactoria de Xampp ………..………………………. 43
3.15 Panel de control ………………………..………………………………. 44
3.16 Xampp para Windows servicios instalados ………………………… 44
3.17 Snort en línea de comandos mostrando la versión ………………… 46
3.18 Listado de interfaz de red con Snort …...……………….................. 47
3.19 Ejecucion de comando console ……………………………...…........... 47
3.20 Comportamiento de Snort al realizar un ping …….………………….. 48
3.21 Consulta de la tabla event de la base de datos snort .………….......... 51

3.22 Ubicación de los archivos de configuración de PHP …...…...…….… 52

CAPITULO IV PRUEBAS EN EL NIDS
4.4. Funcionamiento de SNORT ......................................................... 55
4.5. Servicios de MySQL ................................................................... 56
4.6. Implementación de una interfaz web .............................................. 56
4.7. Rastreo de paquetes ................................................................... 57
4.8. Contenido del proceso SnortServiceBegin .................................... 58
4.9. Proceso SnortServiceEnd ……………………………………...… 58
4.10. Conexión a la base de conocimientos de Snort ………………... 59
4.11. Estructura de tablas de la base de conocimientos ………………... 59
4.12. Registro de la tabla event ……………….............................................. 60
4.13. Consulta de la tabla event ……………….............................................. 60
4.14. Administrador de MySQL ……………….............................................. 61
4.15. Administrador de la base de conocimientos de Snort ………...…….... 61
4.16. Procesos que integra la interfaz web ………………......................... 62
4.17. Interfaz web ……………………………………………………………...... 62

Objetivo

El objetivo de este trabajo es implementar SNORT como un Sistema de detección de
Intrusiones (IDS) complementado con otras herramientas, para facilitar la
monitorización de las alertas. Para lograrlo se hace necesario conocer un poco más
a fondo los componentes principales de un IDS, y SNORT, para finalmente diseñar
de manera práctica una interfaz que nos muestre el funcionamiento del mismo.

Justificación

Actualmente la tecnología ha tenido un crecimiento bastante significativo que hace
que las compañías que se dedican a ofrecer productos y servicios lleven sus ofertas
a Internet y de esta forma exhiben la estructura de su organización, toda la
información o sistema de información a cualquier usuario, debido a esto existen otro
tipo de usuarios que tratan de aprovechar esos canales para poder acceder, no
únicamente a esa información, sino, a algunos datos que sean de mayor importancia
para la organización de una forma ilícita.

Para poderproteger la información, la mayoría de las organizaciones se ven en la
necesidad de realizar políticas de seguridad dependiendo de sus necesidades, pero
el llevarlas a cabo implica una inversión considerable de capital, tanto para realizar
un análisis de seguridad, como el comprar el equipo necesario.

Hay empresas pequeñas o que apenas ingresan al mercado que no tienen la
suficiente infraestructura o presupuesto para poder implementar algún sistema de
seguridad y de igual forma no pueden esperar a que su información sea vulnerada
por cualquier usuario, por lo que se llevo al desarrollo de un sistema que detecte
esos intentos de intrusiones de tal forma que la información no se vea tan vulnerable,
y el costo del mismo sea el mínimo.

Este desarrollo es una simple acción inicial para proteger el sistema de información,
pero se hace necesario continuar con un análisis más extenso para poder proteger
de forma adecuada el sistema de información.

III

Introducción

Durante los últimos años se ha demostrado que las redes de ordenadores facilitan el
trabajo, la comunicación y la coordinación de las diferentes áreas que definen una
empresa. Esto, unido al crecimiento de Internet y al número de clientes potenciales
que puede atraer, hace que lo que era una red de ordenadores corta y de fácil
administración se convierta en una extensa y compleja red donde recae la
responsabilidad de comunicación y la necesidad de darse a conocer ofreciendo sus
productos u ofertas.

Por este motivo y debido a la importancia que han adquirido las redes de
ordenadores para el desarrollo empresarial actual, se hace necesario desarrollar una
política de seguridad general aplicada a toda la estructura empresarial. Cada vez es
más cotidiano escuchar noticias de empresas atacadas por piratas informáticos en
las cuales toda la información de sus clientes ha sido sustraída o cuyos servidores
que proporcionan conexión con Internet, han dejado de funcionar.

Es aquí en donde surgen nuevos conceptos relacionados a la seguridad de las redes
de ordenadores, como la vulnerabilidad, las intrusiones y los ataques, tanto internos
como externos. La diferencia entre vulnerabilidad y ataque, es que la vulnerabilidad
es referente a errores de software o de configuración que pueden permitir a un
intruso acceder a un sistema mientras que un ataque es un intento de explotar una
vulnerabilidad en ese sistema.

Cómo todas las vulnerabilidades no son conocidas, así como tampoco son conocidos
los posibles ataques, en los últimos años se han desarrollado productos para
detectar tanto las posibles vulnerabilidades de los programas instalados en los
ordenadores, del sistema operativo como de servicios de red, como los posibles
ataques que se pueden perpetrar.

El concepto intrusión se refiere a un conjunto de acciones que intentan comprometer
la integridad, confidencialidad o disponibilidad de un recurso; una intrusión no
necesariamente consiste en un acceso no autorizado a una máquina: también puede
ser una negación de servicio. A los sistemas utilizados para detectar las intrusiones o
los intentos de intrusión se les denomina Sistemas de Detección de Intrusiones (por
sus siglas en inglés, IDS) o, sistemas de detección de intrusos; cualquier mecanismo
de seguridad que tenga este propósito puede ser considerado un IDS, pero
generalmente sólo se aplica esta denominación a los sistemas automáticos
(software o hardware).

Uno de los primeros pasos al momento de hablar de IDS es analizar si realmente se
necesita uno de ellos en el ambiente de trabajo; a fin de cuentas, se debe tener ya un
sistema de protección perimetral basado en cortafuegos, y por si ese cortafuego
fallara, cada sistema habría de estar configurado de una manera correcta, de forma
que incluso sin cortafuegos cualquier máquina pudiera seguirse considerando
relativamente segura. Otro aspecto a considerar es si se debe esperar que en
cualquier momento alguien consiga romper la seguridad del ambiente de trabajo, y
por tanto, se debe ser capaz, de detectar ese problema tan pronto como sea posible,
incluso antes de que se produzca. Ningún sistema informático puede considerarse
completamente seguro, pero incluso aunque nadie consiga violar las políticas de
seguridad, los sistemas de detección de intrusos se encargarán de mostrar todos los
intentos de multitud de piratas para penetrar en el entorno, no dejándo caer en
ninguna falsa sensación de seguridad: si se es consciente de que a diario hay gente
que trata de corromper los sistemas, no se cae en la tentación de pensar que las
máquinas están seguras porque nadie sabe de su existencia o porque no son
interesantes para un pirata.

Capítulo I. Antecedentes

- 1 -

CAPITULO I
ANTECEDENTES

Capítulo I. Antecedentes

- 2 -

1.1 Definición de un IDS

Un Sistema de Detección de Intrusión (IDS) se puede definir como un sistema de
software o hardware que automatiza el proceso de supervisión del tráfico de la red y /
o actividades del sistema, analizándolas para detectar actividades sospechosas o no
deseadas de tal forma que se reduce el riesgo de una intrusión 1[1].

1.2 Clasificación de un IDS

Generalmente existen dos formas de clasificar a los sistemas de detección de
intrusos: en función de qué sistemas vigilan, o en función de cómo lo hacen.

Para la primera de estas clasificaciones tenemos dos grupos de sistemas de
detección de intrusos: los que analizan actividades de una única máquina en busca
de posibles ataques, y los que lo hacen en una subred (generalmente, de un mismo
dominio de colisión). Esta última puntualización es importante: un IDS que detecta
actividades sospechosas en una red no tiene porqué ubicarse en todas las máquinas
de esa red.

• IDS basados en red (Network based IDS).

Un IDS basado en red monitoriza los paquetes que circulan por nuestra red
en busca de elementos que denoten un ataque contra alguno de los
sistemas ubicados en ella; el IDS puede situarse en cualquiera de los hosts
o en un elemento que analice todo el tráfico (como un HUB o un
enrutador).

_____________________
1 intrusión es un conjunto de acciones que intentan comprometer la integridad, confidencialidad o disponibilidad de un recurso
Capítulo I. Antecedentes

- 3 -

Esté donde esté, monitorizará diversas máquinas y no una sola: esta
es la principal diferencia con los sistemas de detección de intrusos
basados en máquina.

• IDS basados en máquina (Host based IDS).

Mientras que los sistemas de detección de intrusos basados en red operan
bajo todo un dominio de colisión, los basados en máquina realizan su
función protegiendo un único sistema; de una forma similar - guardando las
distancias, por supuesto - a como actúa un escudo antivirus residente en
MS-DOS, el IDS es un proceso que trabaja en background (o que despierta
periódicamente) buscando patrones que puedan denotar un intento de
intrusión y alertando o tomando las medidas oportunas en caso de que uno
de estos intentos sea detectado.

La segunda gran clasificación de los IDS se realiza en función de cómo actúan estos
sistemas; actualmente existen dos grandes técnicas de detección de intrusos: las
basadas en la detección de anomalías (anomaly detection) y las basadas en la
detección de usos indebidos del sistema (misuse detection).

• Detección de anomalías.

La base del funcionamiento de estos sistemas es suponer que una
intrusión se puede ver como una anomalía dentro del sistema, por lo que si
se puede establecer un perfil del comportamiento habitualde los sistemas,
éste podría ser capaz de detectar las intrusiones por pura estadística:
probablemente una intrusión sería una desviación excesiva de la media de
nuestro perfil de comportamiento.

Capítulo I. Antecedentes

- 4 -

• Detección de usos indebidos.

El funcionamiento de los IDS basados en la detección de usos indebidos
presupone que se pueden establecer patrones para los diferentes ataques
conocidos y algunas de sus variaciones; mientras que la detección de
anomalías conoce lo normal (en ocasiones se dice que tienen un
‘conocimiento positivo’, positive knowledge) y detecta lo que no lo es, este
esquema se limita a conocer lo anormal para poderlo detectar
(conocimiento negativo, negative knowledge).

Un IDS de tiempo real (los denominados Real-Time Intrusion Detection Systems)
trabaja continuamente en busca de posibles ataques, mientras que los sistemas que
se ejecutan a intervalos (Vulnerability Scanners) son analizadores de
vulnerabilidades que cualquier administrador ha de ejecutar regularmente (ya sea de
forma manual o automática) contra sus sistemas para verificar que no presentan
problemas de seguridad.

1.3 Requisitos de un IDS

Sin importar qué sistemas vigile o su forma de trabajar, cualquier sistema de
detección de intrusos ha de cumplir algunas propiedades para poder desarrollar su
trabajo correctamente. En primer lugar, y quizás como característica más
importante, el IDS ha de ejecutarse continuamente sin nadie que esté obligado a
supervisarlo; independientemente de que al detectar un problema se informe a un
operador o se lance una respuesta automática, el funcionamiento habitual no debe
implicar interacción con un humano.

Otra propiedad, y también como una característica a tener siempre en cuenta, es la
aceptabilidad o grado de aceptación del IDS; al igual que sucedía con cualquier
modelo de autenticación, los mecanismos de detección de intrusos han de ser
Capítulo I. Antecedentes

- 5 -

aceptables para las personas que trabajan habitualmente en el entorno. Por
ejemplo, no ha de introducir una sobrecarga considerable en el sistema (si un IDS
ralentiza demasiado una máquina, simplemente no se utilizará) ni generar una
cantidad elevada de falsos positivos (detección de intrusiones que realmente no lo
son) o de archivos .log, ya que entonces llegará un momento en que nadie se
preocupe de comprobar las alertas emitidas por el detector.

Una tercera característica a evaluar a la hora de hablar de sistemas de detección de
intrusiones es la adaptabilidad del mismo a cambios en el entorno de trabajo. Como
es sabido, ningún sistema informático puede considerarse estático: desde la
aplicación más pequeña hasta el propio kernel de Unix, pasando por supuesto por la
forma de trabajar de los usuarios, todo cambia con una periodicidad más o menos
elevada. Si los mecanismos de detección de intrusiones no son capaces de
adaptarse rápidamente a esos cambios, están condenados al fracaso.

Todo IDS debe además presentar cierta tolerancia a fallos o capacidad de respuesta
ante situaciones inesperadas y un IDS ha de ser capaz de responder siempre
adecuadamente ante los mismos.

1.4 IDS basado en Red

La mayoría de los sistemas de detección de intrusiones comerciales son los basados
en red. Los sistemas de detección de intrusiones basados en red, NIDS (network-
based IDS) normalmente consisten de un sensor de simple propósito colocado en un
solo lugar o posicionado en hosts en varios puntos de la red. Esas unidades
monitorizan el tráfico de la red, realizando un análisis local de ese tráfico y
reportando ataques a la consola de administración central. Como los sensores son
limitados a correr el IDS, ellos pueden ser fácilmente resguardados contra los
ataques. Muchos de esos sensores están diseñados para correr en modo silencioso,
Capítulo I. Antecedentes

- 6 -

en orden que lo realizan mas dificultad tiene el atacante para detectar su presencia y
ubicación.

Los sistemas NIDS son capaces de detectar ataques contra diferentes sistemas de
una misma red (en concreto, de un mismo dominio de colisión), aunque
generalmente se ejecuten en uno solo de los hosts de esa red. Para lograr su
objetivo, al menos una de las interfaces de red de esta máquina sensor trabaja en
modo promiscuo, capturando y analizando todas las tramas de red que pasan por él,
escuchando en un segmento de red o switch, en busca de patrones indicativos de un
ataque.

Los patrones pueden ser casi cualquiera de los diferentes campos de una trama de
red TCP/IP puede tener un valor que, con mayor o menor probabilidad, represente un
ataque real; los casos más habituales incluyen:

• Campos de fragmentación.

Una cabecera IP contiene 16 bits reservados a información sobre el nivel
de fragmentación del datagrama; de ellos, uno no se utiliza y trece indican
el desplazamiento del fragmento que transportan. Los otros dos bits
indican o bien que el paquete no ha de ser fragmentado por un router
intermedio (df, Don’t Fragment) o bien que el paquete ha sido fragmentado
y no es el último que se va a recibir (mf, More Fragments). Valores
incorrectos de parámetros de fragmentación de los datagramas se han
venido utilizando típicamente para causar importantes negaciones de
servicio a los sistemas y, desde hace también un tiempo incluso para
obtener la versión del operativo que se ejecuta en un determinado host. En
ocasiones, en algunas máquinas se puede observar ciertas combinaciones
de bits relacionados con la fragmentación por lo que se concluye que se
tienen motivos para - cuanto menos - sospechar que alguien trata de
atacarnos.
Capítulo I. Antecedentes

- 7 -

• Dirección origen y destino.

Las direcciones de la máquina que envía un paquete y la de la que lo va a
recibir también son campos interesantes de cara a detectar intrusiones en
los sistemas o en la red. Solo se tiene que tomar en cuenta el tráfico
proveniente de una DMZ que tenga como destino una red protegida: es
muy posible que esos paquetes constituyan un intento de violación de la
política de seguridad. Otros ejemplos clásicos son las peticiones originadas
desde Internet y que tienen como destino máquinas de una organización
que no están ofreciendo servicios directos al exterior, como un servidor de
bases de datos cuyo acceso está restringido a sistemas de cualquier red.

• Puerto origen y destino.

Los puertos origen y destino (especialmente este último) son un excelente
indicativo de actividades sospechosas en redes. Aparte de los intentos de
acceso no autorizado a los servicios del sistema, pueden detectar
actividades que también supondrán a priori violaciones de las políticas de
seguridad, como la existencia de troyanos, ciertos tipos de barridos de
puertos, o la presencia de servidores no autorizados dentro de la red.

• Flags TCP.

Uno de los campos de una cabecera TCP contiene 6 bits (urg, ack, psh,
rst, syn y fin), cada uno de ellos con una finalidad diferente (por ejemplo, el
bit syn es utilizado para establecer una nueva conexión, mientras que fin
hace justo lo contrario: liberarla). Evidentemente el valor de cada uno de
estos bits será 0 o 1, lo cual de forma aislada no suele decir mucho (ni
bueno ni malo) de su emisor; no obstante, ciertas combinaciones de
valores suelen ser bastante sospechosas: por ejemplo, una trama con los
dos bits de los que han mencionado - syn y fin - activados
Capítulo I. Antecedentes

- 8 -

simultáneamente sería indicativa de una conexión que trata de abrirse y
cerrarse al mismo tiempo.Para dar una idea de la importancia de estos bits
de control, es conveniente no olvidar que uno de los problemas de
seguridad más conocidos de los últimos años sobre plataformas Windows,
estaba fundamentado básicamente en el manejo de paquetes oob (Out Of
Band): tramas con el bit urg activado.

• Campo de datos.

Seguramente, el campo de datos de un paquete que circula por la red es
donde más probabilidades se tiene de localizar un ataque contra los
sistemas; esto es debido a que con toda probabilidad el o los cortafuegos
corporativo detendrá tramas cuya cabecera sea ‘sospechosa' (por ejemplo,
aquellas cuyo origen no esté autorizado a alcanzar su destino o con
campos incorrectos), pero rara vez un cortafuegos se parará a analizar el
contenido de los datos transportados en la trama.

Puede parecer que los sistemas de detección de intrusiones basados en red
funcionan únicamente mediante la detección de patrones; realmente, esto no es así:
en principio, un detector de intrusiones basado en red puede estar basado en la
detección de anomalías, igual que lo puede estar uno basado en máquinas. No
obstante, esta aproximación es minoritaria; aunque una intrusión generará
probablemente comportamientos anormales (por ejemplo, un tráfico excesivo entre el
sistema atacante y el atacado) susceptibles de ser detectados y eliminados, con
demasiada frecuencia estos sistemas no detectarán la intrusión hasta que la misma
se encuentre en un estado avanzado. Este problema hace que la mayor parte de IDS
basados en red que existen actualmente, funcionen siguiendo modelos de detección
de usos indebidos.

Capítulo I. Antecedentes

- 9 -

Dentro de los sistemas de detección de intrusiones basados en red se encuentra las
llamadas honeynets - literalmente, ‘redes de miel’ -. Se trata de un concepto muy
parecido al de los honeypots2, pero extendido ahora a redes completas: redes
diseñadas para ser comprometidas, formadas por sistemas reales de todo tipo que,
una vez penetrados, permiten capturar y analizar las acciones que está realizando el
atacante para así poder aprender más sobre aspectos como sus técnicas o sus
objetivos. Realmente, aunque la idea general sea común, existen dos grandes
diferencias de diseño entre una honeypot y una honeynet: por un lado, esta última
evidentemente es una red completa que alberga diferentes entornos de trabajo, no
se trata de una única máquina; por otro, los sistemas dentro de esta red son
sistemas reales, en el sentido de que no simulan ninguna vulnerabilidad, sino que
ejecutan aplicaciones típicas (bases de datos, sistemas de desarrollo, entre otros.)
similares a las que se encuentran en cualquier entorno de trabajo ‘normal'. El objetivo
de una honeynet no es la decepción, sino principalmente conocer los movimientos de
un pirata en entornos semireales, de forma que aspectos como sus vulnerabilidades
o sus configuraciones incorrectas se puedan extrapolar a muchos de los sistemas
que cualquier empresa posee en la actualidad; de esta forma podemos prevenir
nuevos ataques exitosos contra entornos reales.

En el funcionamiento de una ‘red de miel' existen dos aspectos fundamentales y
especialmente críticos, que son los que introducen la gran cantidad de trabajo de
administración extra que una honeynet implica para cualquier organización. Por un
lado, tenemos el control del flujo de los datos: es vital para la seguridad garantizar
que una vez que un sistema dentro de la honeynet ha sido penetrado, este no se
utilice como plataforma de salto para atacar otras máquinas, de ninguna
organización; la ‘red de miel’ ha de permanecer perfectamente controlada, y por
supuesto aislada del resto de los segmentos de la organización. En segundo lugar,
otro aspecto básico es la captura de datos, la monitorización de las actividades que
un atacante lleva a cabo en la honeynet.

_________________________________________
2 Honeypots son sistemas señuelo, que son diseñados para atraer un atacante potencial desde sistemas críticos.
Capítulo I. Antecedentes

- 10 -

El objetivo principal en este tipo de sistemas es conocer los movimientos de la
comunidad pirata para poder extrapolarlos a sistemas reales, por lo que también es
muy importante para el correcto funcionamiento de una honeynet una correcta
recolección de datos generados por el atacante: ha de ser capturada toda la
información posible de cada acción, de una forma poco agresiva (esto es, sin tener
que realizar grandes cambios en cada uno de los sistemas) y por supuesto sin que el
atacante se entere. Además (muy importante), estos datos recolectados nunca se
han de mantener dentro del perímetro de la honeynet, ya que si fuera así cualquier
pirata podría destruirlos con una probabilidad demasiado elevada [2].

Como se ha mencionado que, los sistemas de detección de intrusos basados en red,
son con diferencia los más utilizados actualmente en sistemas en explotación; no
obstante, como casi cualquier herramienta relacionada con la seguridad, estos
sistemas no son ninguna panacea, y su implantación ha de verse complementada
con una correcta configuración de elementos como el cortafuegos corporativo o, por
supuesto, los sistemas de detección basados en host.

Ventajas de los NIDS:

• Los NIDS bien configurados pueden monitorizar una gran extensión de red.

• El desarrollo de un NIDS tiene poco impacto sobre una red existente. Los
NIDS son normalmente dispositivos pasivos que escuchan en una red sin
interferir con la operación cotidiana de la misma. De esta forma, es muy
fácil readaptar una red, para incluir un NIDS basado en red con un mínimo
esfuerzo

• NIDS pueden ser muy seguros contra los ataques y también pueden ser
invisibles a muchos atacantes.

Capítulo I. Antecedentes

- 11 -

Desventajas de los NIDS:

• Los NIDS pueden tener dificultad al procesar una gran cantidad de
paquetes en una red muy robusta o demasiado ocupada, por lo tanto,
puede fallar al momento de reconocer un ataque lanzado durante periodos
de alto tráfico. Algunos vendedores han intentado resolver este problema,
implementando el IDS completamente en hardware, el cual es mucho más
rápido.

• Muchas de las ventajas de los NIDS no aplica a muchas redes de módem
basadas en switch. Los switches subdividen la red en pequeños
segmentos y provee conexiones dedicadas entre el servicio de host y el
mismo switch. Muchos switches no proporcionan puertos de monitoreo
universal y esto limita el rango de monitoreo de un sensor NIDS a un solo
host.

• Los NIDS no pueden analizar información cifrada. Este problema ha
incrementado en muchas organizaciones utilizando redes virtuales
privadas.

• Muchos NIDS no pueden decir si un ataque tuvo éxito; únicamente pueden
percibir cuando un ataque ha iniciado. Esto quiere decir que después que
un NIDS detectó un ataque, el administrador debe investigar manualmente
cada ataque al host para determinar si este, fue realmente penetrado.

• Algunos NIDS tienen problemas tratando con ataques basados en red que
involucran paquetes fragmentados. Esos malformados paquetes causan
que un IDS llegue a ser inestable y fracase [3].

Capítulo I. Antecedentes

- 12 -

1.5 Diferentes Herramientas de IDS

Para poder monitorizar y analizar el tráfico de una red es necesario utilizar un
rastreador de paquetes (sniffer), dentro del cual se pueden detectar los diferentes
tipo de problemas en ella, como los llamados cuello de botella, de igual forma puede
capturar los datos que se transfieren dentro de la red. Debido a la importancia que
tienen en el mercado, se hace mención dealgunos de ellos.

• TCPDUMP. Te permite monitorizar tráfico de red en tiempo real. Los filtros
que se pueden crear para mostrar tan sólo la información que interesa,
hacen de tcpdump una herramienta muy potente para el análisis de tráfico
en redes de comunicaciones. Tcpdump es una aplicación “peligrosa”, por lo
que en los sistemas UNIX sólo se permite su utilización al usuario root.
Tcpdump permite examinar todas las conversaciones, incluyendo
mensajes de broadcast SMB y NMB. Mientras que sus capacidades en
detección de errores están principalmente a nivel de capa de red OSI,
todavía se puede usar su salida para obtener una idea general de qué
están intentando hacer el servidor y el cliente.

• TRIPWIRE. Es un programa de computador Código Abierto3 (Open Source,
en inglés) consistente en una herramienta de seguridad e integridad de
datos. Tripwire es útil para monitorizar y alertar de cambios específicos de
ficheros en un rango de sistemas. Para mejor eficacia, se recomienda
instalar el programa antes de haber conectado el computador por primera
vez a Internet a fin de crear una base de datos de los ficheros existentes
en el sistema, para poder contrastar los posibles cambios en éstos una vez
conectado a la red. Tripwire funciona correctamente en sistemas
operativos GNU/Linux.
____________________
3
Código Abierto. Es el término con el que se conoce al software distribuido y desarrollado libremente.

Capítulo I. Antecedentes

- 13 -

• NGREP. Muestra y busca paquetes. Ngrep se esfuerza por proveer de la
mayoría de características comunes del "grep" de GNU, aplicándolas a la
capa de red del modelo de referencia OSI. Actualmente reconoce TCP,
UDP, e ICMP sobre Ethernet, PPP, SLIP e interfaces nulas, y comprende
la lógica de un filtro "bpf" de la misma manera que herramientas más
comunes de sniffing como tcpdump y snoop.

• SNORT. Snort es utilizado como un NIDS. Implementa un motor de
detección de ataques y barrido de puertos que permite registrar, alertar y
responder ante cualquier anomalía previamente definida como patrones
que corresponden a ataques, barridos o aprovechar alguna vulnerabilidad,
todo esto en tiempo real. Está disponible gratuitamente bajo licencia GPL,
y funciona en plataformas Windows y UNIX/Linux. Dispone de una gran
cantidad de filtros o patrones predefinidos, así como actualizaciones
constantes ante casos de ataques, barridos o vulnerabilidades que vayan
siendo detectadas a través de los distintos boletines de seguridad.

• NWATCH. Se puede entender como un analizador de puertos pasivo, que
está solamente interesado en tráfico IP y de organizar los resultados como
un explorador de puertos. Esto agrega la ventaja de que cualquier
herramienta que funcione encendiendo tal salida (NDiff) puede utilizar los
datos. Para la seguridad de la red, NWatch es un complemento excelente
al barrido de puertos regular de sus redes. Por defecto, NWatch
permanece activo indefinidamente hasta que recibe un SIGINT (CTRL-c).
Durante ese tiempo mira la interfaz por defecto (eth0), siguiendo cada
combinación del IP host/port que descubre. En el último caso sería
típicamente útil para espiar o quizás mostrar y analizar los patrones del uso
neto más bien que para una supervisión de la seguridad.

• ETTERCAP. Es un sniffer/interceptor/logger para redes LAN con switches,
que soporta la disección activa y pasiva de muchos protocolos (incluso
Capítulo I. Antecedentes

- 14 -

cifrados) e incluye muchas características para el análisis de la red y del
host (anfitrión). Entre sus funciones, más destacadas se encuentran:

o Inyección de caracteres en una conexión establecida emulando
comandos o respuestas mientras la conexión está activa.

o Compatibilidad con SSH1: Puede interceptar users y passwords incluso
en conexiones "seguras" con SSH.

o Compatibilidad con HTTPS: Intercepta conexiones mediante http SSL
(supuestamente seguras) incluso si se establecen a través de un proxy.

o Intercepta tráfico remoto mediante un túnel GRE: Si la conexión se
establece mediante un túnel GRE con un router Cisco, puede
interceptarla y crear un ataque "Man in the Middle". "Man in the Middle"
contra túneles PPTP (Point-to-Point Tunneling Protocol).

o Soporte para Plug-ins.

En este trabajo se enfocará principalmente al rastreador de paquetes SNORT, el cual
presenta la característica de trabajar como un sistema detector de intrusiones
basado en red.

- 15 -

CAPITULO II
SNORT COMO IDS

Capítulo II. SNORT como IDS

- 16 -

2.1 IDS de red: SNORT

SNORT se puede clasificar como un sniffer4 de paquetes, es uno de los más
comunes y tiene la característica principal de actuar como sistema de detección de
intrusiones basado en red (NIDS). Implementa un motor de detección de ataques y
barrido de puertos que permite registrar, alertar y responder ante cualquier uso
indebido [5], en redes de tráfico moderado. Estos usos indebidos - o cuanto menos
sospechosos - se reflejan en una base de datos formada por patrones de ataques,
barridos, intentos de aprovechar alguna vulnerabilidad, análisis de protocolo, etc.;
dicha base de datos se puede descargar también desde la propia página web de
SNORT, donde además se pueden generar bases de patrones ‘a medida' de
diferentes entornos (por ejemplo, ataques contra servidores web, intentos de
negaciones de servicio, exploits...).

El archivo que se utilice en el entorno será la base para el correcto funcionamiento
del sistema de detección de intrusiones. Es de fácil configuración, y puede analizar el
tráfico de una red en tiempo real, así como registrar paquetes en redes IP, y sobre
todo el ser un software gratuito, lo convierten en una buena elección para poder
implementar un IDS.

SNORT tiene la ventaja de funcionar sobre una gran cantidad de plataformas. Está
basado en las librerías libcap, esto es, cualquier plataforma que acepte estas
librerías puede trabajar con SNORT. La colocación de SNORT en una red puede
realizarse según el tráfico que se quiere vigilar: paquetes que entran, paquetes que
salen, dentro del cortafuego, fuera del cortafuego, y en realidad prácticamente donde
se desee colocar.

Para configurar SNORT como un sistema de detección de intrusiones, se requiere

____________________
4
Sniffer es un programa de captura de las tramas de red.
Capítulo II. SNORT como IDS

- 17 -

evidentemente el programa, está disponible bajo la licencia GPL5. Dispone de
actualizaciones constantes ante casos de ataques, barrido o vulnerabilidades que
vayan siendo detectadas a través de los distintos boletines de seguridad. Además,
para compilarlo correctamente es necesario disponer de las librerías LibpCap, o
WinpCap, un interfaz para tratamiento de paquetes de red desde espacio de usuario,
y es recomendable también (aunque no obligatorio) instalar Libnet, librería para la
construcción y el manejo de paquetes de red.

Una vez compilado e instalado correctamente el programa llega el momento de
ponerlo en funcionamiento; y es aquí donde se produce - al menos inicialmente - uno
de los errores más graves en la detección de intrusos. Por lógica, uno tiende a
pensar que el sensor proporcionará mejores resultados cuantos más patrones de
ataques contenga en su base de datos; nada más lejos de la realidad. En primer
lugar, es muy probable que no todos los ataques que SNORT es capaz de detectar
sean susceptibles de producirse en el segmento de red monitorizado; si se sitúa el
sensor en una zona desmilitarizada donde únicamente se ofrece el servicio de web.
Lo lógico es que las políticas implementadas en el cortafuegos nisiquiera dejen
pasar tráfico hacia puertos que no sean los de los servidores web pero, incluso en
caso de que el potencial ataque se produjera entre máquinas del propio segmento,
se debe evaluar con mucho cuidado si realmente vale la pena sobrecargar la base de
datos con patrones que permitan detectar estos ataques. Evidentemente, cuanta más
azúcar más dulce, pero si el sensor ha de analizar todo el tráfico, quizás mientras
trata de decidir si un paquete entre dos máquinas protegidas se adapta a un patrón
se está dejando pasar tramas provenientes del exterior que realmente representan
ataques: se debe tener presente que el sniffer no detendrá el tráfico que no sea
capaz de analizar para hacerlo más tarde, sino que simplemente lo dejará pasar. Así,
se introduce en la base de patrones de ataques los justos para detectar actividades
sospechosas contra una red.

____________________
5
General Public License. Es una licencia creada por la Free Software Foundation en 1989 (la primera versión), y está
orientada principalmente a proteger la libre distribución, modificación y uso de software.
Capítulo II. SNORT como IDS

- 18 -

En segundo lugar, pero no menos importante, es necesario estudiar los patrones de
tráfico que circulan por el segmento donde el sensor escucha para detectar falsos
positivos y, o bien reconfigurar la base de datos, para eliminar los patrones que
generan esas falsas alarmas. Aunque suene extraño, si un patrón genera un número
considerable de falsos positivos, se debe plantear si se requiere o votar por su
eliminación: simplemente no se podría decidir si se trata de verdaderas o de falsas
alarmas. Esto es especialmente crítico si se lanzan respuestas automáticas contra
las direcciones ‘atacantes' (por ejemplo, detener todo su tráfico en el cortafuegos):
volviendo al ejemplo de la zona desmilitarizada con servidores web, se puede llegar
al extremo de detener a simples visitantes en las páginas simplemente porque han
generado falsos positivos; aunque en un entorno de alta seguridad quizás vale la
pena detener muchas acciones no dañinas con tal de bloquear también algunos
ataques (aunque constituiría una negación de servicio en toda regla contra los
usuarios que hacen uso legítimo de los sistemas), en un entorno normal de
producción esto es impensable. Seguramente será más provechoso detectar y
detener estos ataques por otros mecanismos ajenos al sensor.

En resumen, se debe de adaptar al entorno de trabajo, de una forma muy fina, la
base de datos de patrones de posibles ataques. Quizás valga la pena perder el
tiempo que sea necesario en esta parte de la implantación, ya que eso ahorrará
después muchos análisis de falsas alarmas o la detección de algún otro tipo de
ataque.

SNORT genera archivos .log en el directorio /var/log/snort/ si no se le indica lo
contrario. En ese directorio se encuentra un fichero denominado alert con las
actividades que se vayan registrando, también existe el ‘packet logging’ que es una
serie de subdirectorios cuyos nombres son las direcciones IP de las máquinas de las
que se detecta alguna actividad, este es configurable. Como lo que se busca es
básicamente la generación de alarmas, independiente del packet logging, no es
necesario generar estos directorios.

Capítulo II. SNORT como IDS

- 19 -

En principio, si se deja que el sensor analice el tráfico antes de que sea filtrado en el
cortafuegos, se estarían detectando todos los ataques reales que se lanzan contra la
red, sin ningún tipo de filtrado que pueda detener las actividades de un pirata; no
obstante, probablemente lo que realmente interesa no es detectar todos estos
intentos de ataque (aunque nunca está de más permanecer informado en este
sentido), sino detectar el tráfico sospechoso que atraviesa el cortafuegos y que
puede comprometer a los servidores. Por tanto, es recomendable [6] emplazar el
sensor del sistema de detección de intrusiones en la zona protegida; de cualquier
forma, los potenciales ataques que no lleguen al mismo, quedarán registrados en los
archivos .log del cortafuego, e incluso serán neutralizados en el mismo.

Como el sensor ha de analizar todo el tráfico dirigido a las máquinas protegidas, si se
encuentra en un entorno donde dichas máquinas se conecten mediante un
concentrador (hub) o mediante otras arquitecturas en las que cualquiera de ellas vea
(o pueda ver) el tráfico de las demás, no hay muchos problemas de decisión sobre
dónde situar al sensor: se puede hacer en cualquier parte del segmento. Sin
embargo, si los sistemas se conectan con un switch la cuestión se complica un poco,
ya que en las bocas de este elemento se verá únicamente el tráfico dirigido a las
máquinas que estén conectadas a cada una de ellas; en este caso, existen varias
opciones. Una de ellas puede ser modificar por completo - con todo lo que esto
implica - la arquitectura de red para integrar un concentrador por el que pasen los
paquetes ya filtrados antes de llegar a las máquinas del switch. No obstante, suelen
existir alternativas más sencillas y cómodas, como la replicación de puertos que se
puede configurar en la mayoría de switches; la idea es muy simple: todo el tráfico
dirigido a determinada boca del switch se monitoriza y se duplica en otra boca. Así,
únicamente se tiene que configurar este port mirroring y replicar la boca por la que se
dirige el tráfico hacia el segmento de máquinas a monitorizar, enviándolo también a
una segunda boca en la que se concentraría el sensor.

Capítulo II. SNORT como IDS

- 20 -

2.2 Estructura de las reglas

Se basan en una serie de normas que se definen inicialmente como descripción,
Cabecera y Opciones. Luego de la descripción de la regla, se define en la cabecera
la acción, protocolos, Ips, máscaras de subred, puertos origen y destino y los datos
de destino del paquete. En la sección de opciones se contienen los mensajes y la
información necesaria para tomar la decisión. Pero toda esta teoría se expone
perfectamente en un ejemplo como puede ser que el IDS de aviso al detectar la
descarga de un archivo .mp3. Una alternativa inicial y ciento por ciento didáctica es
definir la siguiente regla:

Alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg .Se está descargando un archivo
mp3. ;flags:AP;content:. .mp3. ;)

Para comprender fácilmente este ejemplo es conveniente tener nociones de TCP/IP,
concretamente los flags (ack, push, etc.). Para generar este tipo de reglas se puede
utilizar un análisis de tráfico mediante Ethereal o TCPDump. Otro ejemplo, en este
caso que alerta un ataque de fingerprint mediante técnicas conocidas que utiliza
Nmap, es reaccionar ante el envío de los flags en conjunto de SYN . FIN . PUSH .
URGENT.

scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN
nmap fingerprint attempt";flags:SFPU; reference:arachnids,05;)

2.3 Componentes de SNORT

SNORT se encuentra dividido en varios componentes que interactúan entre sí y
forman un IDS en su totalidad.

• Decodificador de paquetes
Capítulo II. SNORT como IDS

- 21 -

• Preprocesadores
• Motor de detección
• Sistema de alerta y logueo
• Módulos de salida

2.1 Diagrama de los componentes de SNORT

• Decodificador de paquetes

Éste decodificador toma los paquetes provenientes de las interfaces de red
(no importando su tipo), los prepara y envía al preprocesador o al motor de
detección.

• Preprocesador

Los preprocesadores son módulos o plugins que se pueden utilizar con Snort
para modificar los paquetes de datos antes de que sean atrapados por el
motor de detección. Los preprocesadores pueden defragmentar paquetes,
decodificar URLs HTTP, reensamblar streams TCP, etc.

Capítulo II. SNORT como IDS

- 22 -

Un ejemplo de preprocesador es el Arpspoof, el cúal dispone de cuatro
mecanismosde detección:

o Para cada una de las peticiones ARP detectadas se valida la dirección
origen de Ethernet contra la dirección origen del paquete ARP.

o Para cada una de las respuestas ARP, se comparan las direcciones
origen y destino, si alguna de estas no coincide Snort genera una
alerta.

o También se generan alertas para peticiones ARP unicast (en lugar de
broadcast).

o Se pueden comprobar los paquetes ARP basados en una lista de
direcciones IP/MAC previamente generada por el administrador (se
puede implementar solo en redes pequeñas).

Este es un ejemplo práctico de lo que puede hacer un preprocesador, aunque
para el caso de este tipo de ataques la capacidad de SNORT se denota que
es limitada.

• Motor de detección

Éste es el componente más importante de Snort, responsable de detectar si
existe alguna actividad de intrusión en los paquetes. Este motor emplea las
reglas descritas anteriormente y verifica si la condición de las mismas es
positiva con alguno de los paquetes observados. De allí se determina la acción
a seguir que puede ser tanto un acceso en archivo o base de datos como el
envío de una alerta al administrador. El tiempo de análisis de los paquetes es
un factor crítico dentro del sistema, el cual depende directamente con la
cantidad de reglas analizadas, la potencia de la máquina que se encuentra
corriendo SNORT y la carga de la red, entre otras cosas.
Capítulo II. SNORT como IDS

- 23 -

• Sistema de alertas y logueo

Dependiendo de lo que el motor de detección encuentra en los paquetes, este
sistema generará alertas o salidas al archivo .log del SNORT (ubicado
generalmente en /var/log/snort) inicialmente configurado para mantener dos
formatos: Un aviso en texto claro y un detalle del tráfico en formato tcpdump.

• Módulo de salida

También llamados plugins de salida, pueden realizar diferentes operaciones
de envío de alertas o logueo de eventos, dependiendo básicamente de la
configuración del sistema. Los más utilizados son [7]:

o Logueo simple en archivo de texto (Ej. /var/log/snort/alert)

o Intercambio de información a través de mensajes SNMP.

o Envío de mensajes al syslog.

o Logueo de eventos en bases de datos como MySQL u Oracle.

o Generación de XMLs.

o Modificación de reglas de ruteo o cortafuegos.

o Envío de mensajes a máquinas Windows a través de SMB.

o Y muchas otras herramientas como la utilización de alertas por mails o
SMSs.

Capítulo II. SNORT como IDS

- 24 -

2.4 Ejemplo de SNORT

A continuación se describe el funcionamiento básico de SNORT y algunas de las
diferentes modalidades en que se puede utilizar. Para inicializar se escribe la
siguiente instrucción:

C:\Snort20\bin>snort

Y se despliega algo similar a esto, en pantalla:

-*> Snort! <*-
Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike)
.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com)

El formato general de utilizar una instrucción SNORT es la siguiente:

snort [-opción] <opciones de filtro>

snort /SERVICE /INSTALL [-opciones] <opciones de filtro>
snort /SERVICE /UNINSTALL
snort /SERVICE /SHOW

Las diferentes opciones que ofrece SNORT son, la descripción de estas opciones se
deja en su versión original:

-A Set alert mode: fast, full, console, or none (alert file alerts only)
-b Log packets in tcpdump format (much faster!)
-c <rules> Use Rules File <rules>
-C Print out payloads with character data only (no hex)
-d Dump the Application Layer
-e Display the second layer header info
-E Log alert messages to NT Eventlog. (Win32 only)
Capítulo II. SNORT como IDS

- 25 -

-f Turn off fflush() calls after binary log writes
-F <bpf> Read BPF filters from file <bpf>
-h <hn> Home network = <hn>
-i <if> Listen on interface <if>
-I Add Interface name to alert output
-k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
-l <ld> Log to directory <ld>
-L <file> Log to this tcpdump file
-n <cnt> Exit after receiving <cnt> packets
-N Turn off logging (alerts still work)
-o Change the rule testing order to Pass|Alert|Log
-O Obfuscate the logged IP addresses
-p Disable promiscuous mode sniffing
-P <snap> Set explicit snaplen of packet (default: 1514)
-q Quiet. Don't show banner and status report
-r <tf> Read and process tcpdump file <tf>
-R <id> Include 'id' in snort_intf<id>.pid file name
-s Log alert messages to syslog
-S <n=v> Set rules file variable n equal to value v
-T Test and report on the current Snort configuration
-U Use UTC for timestamps
-v Be verbose
-V Show version number
-W Lists available interfaces. (Win32 only)
-w Dump 802.11 management and control frames
-X Dump the raw packet data starting at the link layer
-y Include year in timestamp in the alert and log files
-z Set assurance mode, match on established sesions (for TCP)
-? Show this information

Las opciones de filtro, son opciones BPF estándar, como en TCPDump.

Un ejemplo mas concreto de SNORT se muestra a continuación:

C:\Snort20\bin>snort -v
Running in packet dump mode
Log directory = log
Capítulo II. SNORT como IDS

- 26 -

Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-
81175A8C32BF}
--== Initialization Complete ==--

-*> Snort! <*-

Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike)
1.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com)
05/21-11:00:28.593943 ARP who-has 192.168.2.92 tell 192.168.2.60

05/21-11:00:28.594419 ARP who-has 192.168.2.8 tell 192.168.2.60

05/21-11:00:28.594544 ARP who-has 192.168.2.93 tell 192.168.2.60

05/21-11:00:30.467265 192.168.2.5:1025 -> 192.168.2.1:139
TCP TTL:128 TOS:0x0 ID:16685 IpLen:20 DgmLen:104 DF
***AP*** Seq: 0x6B703 Ack: 0x2266A0C Win: 0x2238 TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:00:30.467731 192.168.2.1:139 -> 192.168.2.5:1025
TCP TTL:128 TOS:0x0 ID:47513 IpLen:20 DgmLen:1500 DF

Con esta opción -v se inicia SNORT en modo sniffer visualizando en pantalla las
cabeceras de los paquetes TCP/IP, es decir, en modo sniffer. Esta opción en modo
verbouse y mostrará las cabeceras IP, TCP, UDP y ICMP.

Si se desea, además, visualizar los campos de datos que pasan por la interface de
red, se añade -d.

Capítulo II. SNORT como IDS

- 27 -

C:\Snort20\bin>snort -vd
Running in packet dump mode
Log directory = log
Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:06:18.943887 192.168.4.5:3890 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:33216 IpLen:20 DgmLen:40 DF
***A**** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:06:18.962018 192.168.4.5:3890 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:33217 IpLen:20 DgmLen:681 DF
***AP*** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20
47 45 54 20 68 74 74 70 3A 2F 2F 77 77 77 2E 6F GET http://www.x
6D 65 6C 65 74 65 2E 63 6F 6D 2E 62 72 2F 73 75 xxxx.com.br/xx
70 65 72 6F 6D 65 6C 65 74 65 2F 64 6F 77 6E 6C xxxxxxx/downl
6F 61 64 73 2F 64 65 66 61 75 6C 74 2E 61 73 70 oads/default.asp
20 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D HTTP/1.0..User-41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 Agent: Mozilla/4
2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65 3B 20 .0 (compatible;
4D 53 49 45 20 36 2E 30 3B 20 57 69 6E 64 6F 77 MSIE 6.0; Window
73 20 4E 54 20 35 2E 30 29 20 4F 70 65 72 61 20 s NT 5.0) Opera
37 2E 31 31 20 20 5B 65 6E 5D 0D 0A 48 6F 73 74 7.11 [en]..Host
3A 20 77 77 77 2E 6F 6D 65 6C 65 74 65 2E 63 6F : www.xxxxx.co
6D 2E 62 72 0D 0A 41 63 63 65 70 74 3A 20 74 65 m.br..Accept: te
78 74 2F 68 74 6D 6C 2C 20 69 6D 61 67 65 2F 70 xt/html, image/p
6E 67 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C 20 ng, image/jpeg,
69 6D 61 67 65 2F 67 69 66 2C 20 69 6D 61 67 65 image/gif, image
2F 78 2D 78 62 69 74 6D 61 70 2C 20 2A 2F 2A 3B /x-xbitmap, */*;
71 3D 30 2E 31 0D 0A 41 63 63 65 70 74 2D 4C 61 q=0.1..Accept-La

Añadiendo la opción -e, SNORT mostrará información más detallada, como las
cabeceras a nivel de enlace.

Capítulo II. SNORT como IDS

- 28 -

Con estas opciones y dependiendo del tráfico en la red, se puede observar una gran
cantidad de información desplegada en pantalla, con lo cual se hace interesante
registrar, guardar estos datos a disco para su posterior estudio. Se configuraría
entonces SNORT como packet logger o registro de paquetes.

C:\Snort20\bin>snort -dev -l ./log

La opción -l indica a SNORT que debe guardar los archivos .log en un directorio
determinado. Dentro de la carpeta log se creará una estructura de directorios donde
se archivarán los archivos .log.

Se puede indicar la IP de la red a registrar ( -h ) y que el formato de los archivos .log
sea en modo binario (-b), es decir, el modo que entiende TCPDump o Windump,
para estudiar más a fondo con los potentes filtros de estos programas los archivos
log de SNORT. La salida del log en el caso de la opción de salida binaria ya no será
una estructura de directorios, si no, un sólo archivo.

C:\Snort20\bin>snort -vde -l ./log -h 192.168.4.0/24
Running in packet logging mode
Log directory = ./log

C:\Snort20\bin>snort -l ./log -b
Running in packet logging mode
Log directory = ./log

Usando la opción -b no hará falta indicarle IP alguna de red (-h). Guardará todo en
un mismo archivo y recogerá datos de toda la red. Tampoco serán necesarias las
opciones -de y -v.

El archivo generado por SNORT en modo binario también se puede leer con este
usando la opción -r nombrearchivo.log.

Capítulo II. SNORT como IDS

- 29 -

Otra opción a tomar en cuenta es -i para indicar a SNORT que interfaz de red usar
en el caso de que se tenga dos o más. Se hace de distinta forma dependiendo si se
está haciendo uso de SNORT para Win32 o para Linux/UNIX. Para averiguar las
interfaces de se encuentran disponibles, en Win32 por ejemplo, se utiliza la opción
-W.

C:\Snort20\bin>snort -vde -i 1
# snort -vde -i eth0
C:\Snort20\bin>snort -W

Se pueden añadir una serie de filtros, a parte de las opciones, para optimizar los
resultados obtenidos. Estos filtros se añadirán en el mismo formato que usa
programas como TCPDump ya que usan las mismas librerías de captura de
paquetes (LibpCap o WinpCap).

C:\Snort20\bin>snort -vd host 192.168.4.5 and dst port 8080
Running in packet dump mode
Log directory = ./log

Initializing Network Interface eth0

--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0
--== Initialization Complete ==--

-*> Snort! <*-

Version 2.0.0 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
07/15-12:34:26.059644 192.168.4.5:4533 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:16544 IpLen:20 DgmLen:40 DF
***A**** Seq: 0xC47AC53E Ack: 0xC83C2362 Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Capítulo II. SNORT como IDS

- 30 -

07/15-12:34:26.059880 192.168.4.5:4533 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:16545 IpLen:20 DgmLen:40 DF
***A**** Seq: 0xC47AC53E Ack: 0xC83C31E4 Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Snort aceptará también filtros más avanzados en su modo sniffer:

C:\Snort20\bin>snort -vd icmp[0] = 8 and dst host 192.168.4.1

C:\Snort20\bin>snort -vd icmp[0] != 8 and icmp[0] != 0

C:\Snort20\bin>snort -vd 'udp[0:2] < 1024' and host 192.168.4.1

El modo detección de intrusos de red se activa añadiendo a la línea de comandos de
SNORT la opción -c snort.conf. En este archivo, snort.conf, se guarda toda la
configuración de las reglas, preprocesadores y otras configuraciones necesarias para
el funcionamiento en modo NIDS

C:\Snort20\bin>snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

Con al opción -D se indica que corra como un servicio. Esto es sólo válido para las
versiónes Linux/UNIX:

# snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf –D

Hay varias formas de configurar la salida de SNORT, es decir, las alertas, el modo en
que se almacenarán estas en el archivo alert.ids.

SNORT dispone de siete modos de alertas en la línea de órdenes, completo, rápido,
socket, syslog, smb (WinPopup), consola y ninguno, las cuáles se listan a
continuación:

Capítulo II. SNORT como IDS

- 31 -

• Full: El modo de Alerta Completa regresa información sobre: tiempo, mensaje
de la alerta, clasificación, prioridad de la alerta, IP y puerto de origen/destino e
información completa de las cabeceras de los paquetes registrados.

C:\Snort20\bin>snort -A full -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

[**] [1:620:2] SCAN Proxy (8080) attempt [**]
[Classification: Attempted Information Leak] [Priority: 2]
09/19-14:53:38.481065 192.168.4.3:3159 -> 192.168.4.15:8080
TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF
******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28
TCP Options (4) => MSS: 1456 NOP NOP SackOK

Información de la cabecera del paquete:

TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF
******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28
TCP Options (4) => MSS: 1456 NOP NOP SackOK

• Fast: El modo Alerta Rápida regresa información sobre: tiempo, mensaje de la
alerta, clasificación, prioridad de la alerta, IP y puerto de origen y destino.

C:\Snort20\bin>snort -A fast -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

09/19-19:06:37.421286 [**] [1:620:2] SCAN Proxy (8080) attempt [**]
[Classification: Attempted Information Leak] [Priority: 2] ...
... {TCP} 192.168.4.3:1382 -> 192.168.4.15:8080

• Socket: Manda las alertas a través de un socket, para que las escuche otra
aplicación. Está opción es para Linux/UNIX.

# snort -A unsock -c snort.conf

• Syslog: Envía las alarmas al syslog

Capítulo II. SNORT como IDS

- 32 -

C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -s
192.168.4.33:514

• SMB: Permite a SNORT realizar llamadas al cliente de SMB (cliente de
Samba, en Linux), y enviar mensajes de alerta a hosts Windows (WinPopUp).
Para activar este modo de alerta, se debe compilar SNORT con el conmutador
de habilitar alertas SMB (enable -smbalerts). Evidentemente este modo es
para sistemas Linux/UNIX. Para usar esta característica enviando un
WinPopUp a un sistema Windows, se agrega a la línea de comandos de
SNORT: -M WORKSTATIONS.

• Console: Imprime las alarmas en pantalla.

C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

• None: Desactiva las alarmas.

# snort -A none -c snort.conf

• Eventlog: Registra las alertas para visualizarse a través del visor de sucesos
de un sistema Windows. Esta opción se activará mediante -E y sólo para
Win32 [8].

CAPITULO III
IMPLEMENTACIONDE UN
IDS

Capítulo III. Implementación de un IDS

- 34 -

3.1 Escenario de implementación.

En este apartado se verán cuáles son los elementos necesarios para implementar un
IDS de red o NIDS en una organización o institución.

Existen varios NIDS comerciales sin embargo, se utilizara software Open Source de
Snort para Windows, se escogió esta plataforma porque es una alternativa por
infraestructura comercial a la cual se puede economizar y existe soporte en la mayor
parte de las empresas; también se seleccionó Snort ya que es una organización que
se adapta a los estándares recomendados para las buenas prácticas de seguridad
informática.

En la actualidad los circuitos telefónicos, las redes de computadoras son canales de
comunicación compartidos, el compartir significa que las computadoras pueden
recibir información proveniente de otras máquinas, al capturar información
proveniente de otra parte de la red, a este proceso se le llama “sniffing” [12] (tarea
primordial del NIDS).

El sistema de Snort es una herramienta, que en pleno funcionamiento consume
recursos de procesamiento, y la razón por la que éste demande recursos, es por el
mecanismo de rastreo en la red de paquetes, también está en proceso de análisis y a
su vez alerta de los posibles incidentes que pudieran considerarse como una
amenaza de seguridad [13]; para ello se requieren las siguientes características de
rendimiento del equipo en el que se desarrollara el sistema, los cuales son:

• Equipo Dell
• Procesador Intel Pentium Dual Core de 2.1 GHz
• 3 GB de memoria en Ram
• Sistema Operativo Windows 7 de 64 bits
• Adaptador de red integrado Marvell Yukon
Capítulo III. Implementación de un IDS

- 35 -

Estas características son importantes en la implementación de un NIDS ya que
ciertas estructuras de red que son demandantes en la capacidad con los equipos, así
como el tráfico excesivo que pudiera presentarse, este no dará abasto para realizar
el análisis completo y no lograr su buen funcionamiento, teniendo como resultados,
falsos negativos por la dificultad al procesar gran cantidad de paquetes.

En la figura 3.1 se muestra el modelo para sniffear la red; el cual está constituido por
varios clientes que pueden realizar peticiones entre ellos y/o al web server, el NIDS
estará conectado al mismo medio que estos comparten, así mismo detectara las
peticiones que hay entre todos y lograra monitorear en tiempo real su
comportamiento, así como almacenarlo a través de una base de datos o un archivo
como bitácora.

Web Server
NIDS
Cliente A
Cliente B
Cliente C
Figura 3.1 Escenario de implementación de un NIDS.

Se determino este modelo para comprender el funcionamiento que por simpleza
logre facilitar la explicación en cuanto a la lógica de la red, así como plantear un
orden en cuanto a las peticiones para el NIDS.

Capítulo III. Implementación de un IDS

- 36 -

3.2 Instalación del software.

El software que se instaló se consultó en los sitios oficiales de internet, y las
versiones son las siguientes:

• Snort versión 2.8.4
• Winpcap versión 4.1.1
• Xampp versión 1.6.4

Snort es el sistema de detector de intrusos basado en red, es muy flexible ofrece
capacidades de almacenamiento de comportamientos tanto en bitácoras como una
base de datos, implementa un motor de detección de ataques y barrido de puertos
que permite registrar y alertar ante una anomalía previamente definida.

La característica más apreciada es su subsistema flexible de firmas de ataques.
Snort tiene una base de datos de ataques que se actualiza constantemente la cual se
puede añadir a través de internet. Los usuarios pueden crear firmas de seguridad
basada en las categorías de los nuevos ataques de red y enviarla a la lista de correo
de firmas de seguridad de Snort. Para mayor referencia ingresar al sitio oficial
http://www.snort.org.

Una vez descargado el programa del sitio anteriormente mencionado, se inicia la
instalación de Snort como se muestra en la siguiente ventana de la figura 3.2, la cual
contiene la licencia libre GPL que es compatible para la versión que se implementara
en el sistema operativo que es Windows, uno de los términos que expresa durante
esta parte de la instalación es que el administrador de esta herramienta es el
responsable en cuanto a su configuración asi como su desempeño de la seguridad
de la red, para eso esta disponible el manual en el sitio ofical.

Capítulo III. Implementación de un IDS

- 37 -

Figura 3.2 Iniciando la instalación de Snort.

En la figura 3.2 muestra información de la instalación iniciada, se selecciona la
opción ‘I Agree’.

En la siguiente ventana se selecciona ‘I do not plan to log to a database, or I am
planning to log to one of the databases listed Above’, y oprimir ‘next’ como se
muestra en la figura 3.3.

Figura 3.3 Opciones de instalación

En la figura 3.3 en la primera opción muestra que no se cuenta con una base de
datos pero se puede realizar dicha tarea en otro momento, en la segunda opción es
para direccionar el log para solo clientes Sql server, la tercera opción hace referencia
Capítulo III. Implementación de un IDS

- 38 -

a clientes oracle y en la última parte para protocolo de comunicación IPv6, para fines
de esta investigación solamente se habilita la primera opción y oprimir ‘next’.

En la siguiente ventana se muestran los componentes que se instalaran en Snort, en
este caso se seleccionan todos como lo muestra en la figura 3.4, después
seleccionar ‘next’.

Figura 3.4 Componentes necesarios para instalar Snort.

En la siguiente ventana se conserva la ruta de instalación como se muestra en la
figura 3.5 que es C:\Snort; si se contara con algún requerimiento de instalarlo en otra
localidad fuera de la unidad propuesta, los parámetros de configuración tendrán que
estar dirigidos a dicha ruta para que este funcione. Para fines de esta investigación
no se propone otra localidad diferente.

Figura 3.5 Ruta de instalación de Snort.
Capítulo III. Implementación de un IDS

- 39 -

Después se selecciona ‘next’, si todo marcha bien el proceso de instalación se
mostrara la figura 3.6 que son dos ventanas, la primera es una ventana grande con
referencias de lo instalado así como el nombre de los módulos instalados; y la
segunda hace una clara referencia de que requiere Winpcap para que este funcione,
así también en la misma ventana hace referencia a las especificaciones al archivo de
configuración snort.conf.

Figura 3.6 Instalación exitosa de Snort.

Para mayor información de los modos de configuración de Snort también está
disponible el manual en línea de la página oficial, y por último se selecciona ‘aceptar’,
la instalación del NIDS ha terminado.

Pcap es una interfaz de una aplicación de programación para captura de paquetes.
La implementación para sistemas basados en UNIX se conoce como libpcap, es una
herramienta open source escrita en C y es portable entre un gran número de
sistemas operativos [14]; mientras que en Windows recibe el nombre de Winpcap.

Winpcap es la herramienta estándar de la industria para acceder a la conexión entre
capas de red en entornos Windows. Permite a las aplicaciones capturar y transmitir
Capítulo III. Implementación de un IDS

- 40 -

los paquetes de red puenteando la pila de protocolos, a demás filtra paquetes a nivel
núcleo, genera un motor de estadística de red y soporta captura de paquetes
remotos. El sitio oficial es http://www.winpcap.org, esta herramienta es requerida
para la instalación y funcionamiento de Snort.

Es relevante remarcar que este programa es utilizado por otras herramientas
dedicadas al análisis y tráfico de red como tcpdump, Wireshark, Nmap, Cain & Abel.

Una vez descargado elinstalador del sitio oficial, se inicia la instalación de Winpcap
la cual mostrara la ventana siguiente de la figura 3.7.

Figura 3.7 Iniciando la instalación de WinPcap 4.1

CACE Technologies, Inc. ofrece soporte en línea para desarrolladores con diversos
ambientes en el análisis de redes orientado a la captura de paquetes de Winpcap
entre otros como los que se mencionaron anteriormente.

También se puede ver en la figura 3.8 durante la instalación que automáticamente
detecta el sistema operativo, el kernel en el que trabaja el sistema y algunos archivos
que son librerías para el correcto funcionamiento de Winpcap.
Capítulo III. Implementación de un IDS

- 41 -

Figura 3.8 Opciones de instalación de WinPcap.

Si todo marcha bien, se ha cumplido con lo requerido para instalar WinPcap de dicha
versión y mostrara la última ventana de instalación como se muestra en la figura 3.9
al cual se selecciona ‘finish’.

Figura 3.9 Finalizando la instalación de WinPcap.

Xampp es un servidor independiente de plataforma, open source, que consiste
principalmente en la base de datos MySQL, el servidor Web Apache y los intérpretes
para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X para
cualquiera de los diferentes sistemas operativos, Apache, MySQL, PHP y Perl.
Capítulo III. Implementación de un IDS

- 42 -

El sitio oficial de Xampp es http://www.apachefriends.org/es/xampp.html, para
descargar gratuitamente.

Durante la instalación mostrara ventanas como en la primera parte se selecciona el
lenguaje por defecto en español.

En el proceso preguntara el directorio de instalación, por lo regular es en archivos de
programa, no modificar este criterio se deja tal cual y de ahí inicia el proceso de
instalación como se muestra en la figura 3.10.

Figura 3.10 Instalación de Xampp 1.5.3

Posteriormente al terminar la instalación preguntara si se requiere que se active
como servicio Apache y MySQL como se muestra en la figura 3.11 al cual se
selecciona ‘sí’.

Figura 3.11 Activación de servicio de Apache, MySQL

Capítulo III. Implementación de un IDS

- 43 -

En la siguiente ventana pregunta si se requiere el servicio de Apache aun que ya se
selecciono que ‘si’, se mostrara la siguiente figura 3.12 observando los puertos
disponibles para Apache.

Figura 3.12 Servicios y puertos asignados de Apache.

En la siguiente ventana muestra si se requiere MySQL como servicio de igual forma
se selecciona ‘aceptar’. A continuación muestra que se han hecho los cambios y la
asignación de puerto como servicio como se muestra en la figura 3.13.

Figura 3.13 MySQL asignado al puerto 3306

En el siguiente proceso pregunta si se requiere iniciar automáticamente los servicios,
se selecciona ‘sí’, y también si se requiere iniciar los servicios, se selecciona
‘aceptar’. Se mostrara la siguiente ventana que se ha instalado correctamente estos
servicios como lo muestra la figura 3.14.

Figura 3.14 Instalación satisfactoria de Xampp.

Capítulo III. Implementación de un IDS

- 44 -

En seguida oprimir que si se requiere ver en ese momento el Panel de Control el cual
mostrara la figura 3.15.

Figura 3.15 Panel de control.

Como se puede mostrar en la figura 3.15 los módulos que se instalaron están
trabajando como servicio.

A continuación se inicia internet explorer y en la barra de dirección se escribe
‘http:\\localhost\’ lo cual mostrara el administrador del servidor Xampp ver figura 3.16,
como se puede apreciar en la figura el administrador de servicios de Xampp es
amigable para configurar los componentes que en instalación fueron seleccionados.

Figura 3.16 Xampp para Windows servicios instalados.
Capítulo III. Implementación de un IDS

- 45 -

3.3 Configuración de SNORT.

Una vez instalado Snort el siguiente paso es configurar Snort en la ruta que se
instaló C:\Snort\etc el archivo snort.conf y para su modificación se utiliza un editor de
textos como wordpad o notepad, se sugiere wordpad ya que son demasiadas líneas
de código al cual no deberá cambiar en cuanto al formato y su orden.

3.3.1 Configuración de red.

La configuración de red está dada por la variable
var HOME_NET any

Existen varios modos de configuración con dicha variable.
Tipo de red Utilizando la variable de configuración
Tipo C var HOME_NET 192.168.1.0/24
Host especifico var HOME_NET 192.168.1.3/32
Varios Host var HOME_NET 192.168.1.2/32, 192.168.1.3/32, 192.168.1.4/32
Cualquier Host var HOME_NET any

En nuestro caso utilizaremos para cualquier host.

3.3.2 Configuración de reglas.

En la configuración de reglas cabe mencionar que en la página web de Snort se
pueden descargar las reglas para que estas sean incluidas en el directorio de
C:\Snort\rules.

Se busca en el mismo archivo de Snort.conf lo siguiente:
var RULE_PATH../rules y lo sustituimos por
var RULE_PATH C:\Snort\rules

Capítulo III. Implementación de un IDS

- 46 -

3.3.3 Configuración de acceso.

En este apartado se configuraran algunas líneas que son importantes para que el
funcionamiento sea el adecuado, en el archivo snort.conf se deberá buscar entre
las instrucciones la línea que contenga lo siguiente:

dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/

Una vez localizada, se debera modificar de la siguiente manera:

dynamicpreprocessor directory c:\snort\lib\snort_dynamicpreprocessor

Y en la instrucción original cuyo argumento se muestra a continuación:

dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so

Se deberá modificar con la siguiente instrucción:

dynamicengine c:\snort\lib\snort_dynamicengine\sf_engine.dll

Una vez realizado lo anterior, se abre una sesión en el prompt de windows o línea
de comandos en la ruta C:\Snort\bin y se edita la siguiente instrucción:

C:\Snort\bin\Snort –V

En seguida mostrara información acerca de la versión de Snort como se muestra
en la figura 3.17

Figura 3.17 Snort en línea de comandos mostrando la versión.

Capítulo III. Implementación de un IDS

- 47 -

El comando snort –W mostrara las interfaces de red que dispone el equipo, eso
quiere decir que las tarjetas de red están configuradas para realizar el monitoreo
de paquetes aun sean tarjetas virtuales o emuladas por alguna aplicación.

Figura 3.18 Listado de interfaz de red con Snort.

En este caso se utilizara la interfaz 4, cuya sintaxis para realizar un análisis de
paquetes ICMP es la siguiente:

Una vez ejecutado esta sintaxis mostrara una serie de comandos y procesos que
ejecuta el programa de snort como se aprecia en la figura 3.19.

Figura 3.19 Ejecucion de comando console.

Capítulo III. Implementación de un IDS

- 48 -

El último mensaje no muestra nada al final del proceso en ejecución ya que
cuando se está conectado a la red, no se realiza ninguna petición hacia algún
sitio en específico, es por eso que está en espera de recibir algún paquete y
muestra el mensaje de ‘Not Using PCAP_FRAMES’; se abre una línea de
comandos más y se realiza un ping de prueba a la página de Google.

Lo que en la misma ventana captura el contenido de la figura 3.19 a comparación
de la figura 3.20 donde no había actividad en la red, se muestran los resultados a
continuación.

Figura 3.20 Comportamiento de Snort al realizar un ping.

El comportamiento registrado muestra los eventos en orden de fecha y hora, nombre
de la alerta, dirección fuente y destino. Estas reglas se personalizan acorde a la
seguridad que se requiera implementar en el sistema, en este caso solo se refiere a
la funcionalidad que esta por defecto.
Capítulo III. Implementación de un IDS

- 49 -

3.4 Configuración de MySQL.

Una vez instalado MySql en Xampp, se crea la base