DEMONSTRATION MODULE ON SELECTED ANTENATAL EXERCISE

En 1998, Martin Roesch desarrolló una nueva tecnología llamada Snort .al la cual le llamó una tecnología de detección de intrusión "de peso ligero" en comparación de los sistemas comerciales existentes en esa época.

Durante los años el Snort ha adquirido madurez, destaca la rica tecnología que brinda la configuración estándar del sistema de prevención de intrusos. Avances recientes como lo es la actualización de las reglas así como las capacidades que ofrecen la detección de amenazas más flexible y exacta disponibles, haciendo a Snort una herramienta de peso pesado de la prevención de intrusos.

2.1.1 ¿Qué es Snort?

Snort es un sistema de detección y/o prevención de intrusiones de red en código abierto, capaz de analizar la ejecución del tráfico en tiempo real, y registros de paquetes en direcciones IP de red. Puede realizarse el análisis de protocolo, contenido búsqueda/acoplamiento, y puede ser usado para detectar una variedad de ataques pruebas, por ejemplo desbordamientos del almacenador intermediario, exploraciones del

puerto stealth, ataques CGI, pruebas SMB, tentativas de huella dactilar del SO y muchas

más.

Snort utiliza reglas flexibles de lenguaje, para describir el tráfico que debe pasar o recoger, así como un motor de la detección que utiliza una arquitectura plugin modular. Snort tiene una capacidad de alertar en tiempo real también, incorporando mecanismos de alerta para syslog, un archivo especificado de usuario, un socket UNIX, o mensajes WinPopup para clientes Windows usando los clientes SMB de Samba.

Snort tiene tres usos primarios. Puede ser usado como succionador de paquete recto como tcpdump, una herramienta del paquete (útil para eliminar errores del tráfico de la red, etc), o como un sistema completamente abastecido para la prevención de las intrusiones de la red.

2.1.2 Arquitectura del IDS Snort

Es realmente importante y necesario conocer los componentes con los que Snort cuenta, debido a que este utiliza distintos conectores de software, para personalizar su implementación, y aunque Snort puede desarrollar muchas tareas sencillas se hace indispensable el entender su arquitectura, ya que tendremos una visión más clara de lo que este software realiza. Básicamente se encuentra conformada por cuatro componentes básicos:

Decodificador de paquetes Preprocesador

Motor de detección

Figura 2.1 Diagrama de operación de Snort, versión oficial.

La figura 2.2 ofrece un modelo a gran escala de la arquitectura de Snort. En su forma mas simple, la arquitectura de este software es similar a un clasificador de monedas mecánico.

Toma todas las monedas (paquetes de la red que se están escuchando).

Entonces la envía atreves de un canal inclinado para determinar si son monedas y como deben ser clasificadas (preprocesador).

A continuación ordena las monedas de acuerdo a su tipo. Esto es para el almacenamiento de centavos, monedas de 1, 2, 5, etc. Pesos (en el IDS es la maquina de detección de paquetes que va separando los paquetes dependiendo de su contenido y riesgo).

Finalmente es la decisión del administrador que hacer con las monedas, usualmente almacenarlas (es el registro y almacenamiento en alguna base de datos).

2.1.2.1 Decodificador de paquetes (Visor de Paquetes)

El decodificador de paquetes permite a una aplicación o dispositivo escuchar de forma disimulada el tráfico de la red, tienen como objetivo la obtención de datos del exterior del sistema de detección de intrusos.; son los “ojos” del IDS.

Soporta gran variedad de protocolos de capa de enlace bajo TCP/IP, tales como Ethernet, ICMP (Internet Control Message Protocol), UDP (User Data Protocol), TCP (Transfer Control Protocol).Es el encargado de organizar los paquetes conforme van pasando por la pila de protocolos.

Cada subrutina del decodificador ordena de una forma distinta los paquetes, formando una estructura de datos basada en punteros por encima del tráfico real capturado. Esta estructura de datos será la que guíe al motor de análisis para el posterior análisis. La figura 2.3nos muestra la capacidad del visor de paquetes.

Figura 2.3 Diagrama a bloques de Visor o decodificador de paquetes 2.1.2.2 Preprocesador

Las entradas que el preprocesador toma serán los datos en bruto del entorno exterior al IDS los verifica y compara contra ciertos plugins para pasarlos a un formato común al resto de los componentes y proporcionan los eventos al resto de componentes; es decir, cuando algún paquete ya ha sido clasificado como algún tipo de conducta pasa al motor de detección, prácticamente en tiempo real. En la figura 2.4 se observa la forma en como opera el preprocesador.

Figura 2.4 Diagrama a bloques del Preprocesador

Interface Visible eth1 Interface Visible eth0 SSH HTTPS SQL SMB SNMB VISOR DE PAQUETES

RED

Preprocesador

_{Motor de Detección}

PAQUETES

Una característica de suma importancia para los IDS es esta debido a que se pueden habilitar o deshabilitar los plugins a nuestro criterio o según convenga a nuestras necesidades, conforme lo vaya requiriendo el nivel del preprocesador.

2.1.2.3 Motor de Detección

El motor de detección es el núcleo de los IDS. Es el motor de inferencia que, gracias a unos conocimientos, será capaz de discernir la relevancia de los eventos recibidos. Además toma los datos que vienen del preprocesador y debido a que Snort se basa en reglas este mantiene sus reglas de detección en una lista enlazada bidimensional. La lista base se denomina Cabecera de Cadena (Chain Header) y la que deriva de ésta se llama Opción de Cadena (Chain Option). Cuando llega un paquete al motor de detección, éste busca en la lista Cabecera de Cadena de izquierda a derecha la primera coincidencia. Después, buscará por la lista Opción de Cadena si el paquete cumple las opciones especificadas. Si aparece alguna coincidencia no seguirá buscando y se tomarán las acciones correspondientes. En caso contrario, buscará en el siguiente nodo de Cabecera de Cadena.

Figura 2.5 Diagrama a bloques del Motor de Detección

El motor de búsqueda tiene capacidad para la inserción de módulos plug-in (extiende las capacidades de un navegador), que pueden utilizarse para dos cosas:

a) Permiten hacer búsquedas más complicadas en los paquetes o flujos TCP cuando la sintaxis de las reglas no lo permite. A estos módulos se les llama preprocesadores, y los más utilizados son el detector de escaneos de puertos, el desfragmentador, el reconstructor de flujo TCP y el Spade, un motor de detección de anomalías aun en fase muy primitiva.

b) Permite definir modos de alerta y log no pertenecientes a Snort, como bases de datos (MySQL, Oracle,), SNMP traps, CSV o salida en formato XML

Motor de Detección Regla ¿Coincide con los paquetes? NO Descartar SI

Registro de

Alerta

2.1.2.4 Subsistema de Alerta/ Registros (Log)

Después de pasar los paquetes de datos por el motor de detección, debe salir de alguna forma, y esto lo hace con ayuda de este subsistema de Alertas y Registros. En este existen tres sistemas de registro o log y cuatro de alerta. Las opciones de los registros pueden ser activadas para almacenar paquetes en forma decodificada y entendible para humanos. El formato decodificado se usa para un análisis rápido y el tcpdump es mucho más rápido de almacenar y proporciona un mayor rendimiento. Las alertas se pueden realizar por syslog, en ficheros texto mediante dos formatos distintos (rápido y completo). Avisan del tipo de ataque detectado y ofrece información adicional como IP origen y destino, fecha y hora de la detección y campo de datos.

El componente de alertas en forma similar al motor de detección y al preprocesador utiliza plugins para enviar alertas a las bases de datos y a través de protocolos de red como SNMP. Ver la figura 2.6 para observar como funciona.

Figura 2.6 Diagrama a bloques del Subsistema de Alerta y Log

Snort dispone de un mecanismo que optimiza considerablemente su rendimiento. Puesto que normalmente se quiere un sistema de back-end potente como una base de datos SQL para hacer correlaciones de los ataques, las escrituras de los logs o registros suelen ser muy robusto. Al ser Snort un proceso monolítico, mientras que se encuentra escribiendo en la base de datos es incapaz de hacer otras cosas, como procesar el tráfico de entrada.