Taller de Sistemas de detección de intrusiones SNORT

Taller de Sistemas de detección de intrusiones SNORT 1 - Objetivos ~- Cómo funciona Snort en todas sus facetas, instalación y configuración //(sistemas Windows)//. interpretación y configuración de las alertas. Creación de reglas (//Snort rules//). ~- Creación de reglas desde cero, es decir, capturando paquetes considerados maliciosos en nuestra red, interpretándolos para sacar los datos que nos permitan crear los patrones y reglas snort. //Por ejemplo: detectar un ping desde un Windows 2000 usando un sniffer (Ethereal) y, analizando los paquetes de datos, averiguar qué datos son los que nos permiten saber que se trata de un ping, que proviene de un host con S.O. Windows 2000 y de qué manera implementarlo en un regla para que a partir de ese momento siempre nos detecte el ping.// ~- Prácticas y ejemplos de creación de reglas, etc.

2 - Reglas SNORT 6-11-02 Aquí disponéis la recopilación de las últimas reglas snort actualizadas al 6-11-02, creo recordar. También tienes un archivo *.rules con reglas especiales que no vienen incluidas en Snort por defecto. //Hay que tener cuidado, porque contiene también el fichero de configuración de snort por defecto (snort.conf) y no conviene pisarlo que el personalizado que cada uno tenga.// Uno de los archivos de reglas //(vision18.rules)// contiene reglas para detectar ataques DDoS, troyanos, detectores de Sniffers, etc." ~- Enlace relacionado: Honeynet in spanish// (añadido por maty)//

3 - Breve descripción ~- Un IDS o Sistema de Detección de Intrusiones es una herramienta de seguridad que intenta //detectar o monitorizar los eventos// ocurridos en un determinado sistema informático o red informática en busca de intentos de comprometer la seguridad de dicho sistema. ~- Los IDS buscan //patrones previamente definidos// que impliquen cualquier tipo de actividad sospechosa o maliciosa sobre nuestra red o host. ~- Los IDS aportan a nuestra seguridad una capacidad de prevención y de alerta anticipada ante cualquier actividad sospechosa. //No están diseñados para detener un ataque, aunque sí pueden generar ciertos tipos de respuesta ante éstos.// ~- Los IDS: //aumentan la seguridad de nuestro sistema, vigilan el tráfico de nuestra red, examinan los paquetes analizándolos en busca de datos sospechosos y detectan las primeras fases de cualquier ataque como pueden ser el análisis de nuestra red, barrido de puertos, etc.//

4 - Tipos de IDS Según sus características

1. HIDS (Host IDS) Protege contra un único Servidor, PC o host. Monitorizan gran cantidad de eventos, analizando actividades con una gran precisión, determinando de esta manera qué procesos y usuarios se involucran en una determinada acción. Recaban información del sistema como ficheros, logs, recursos, etc, para su posterior análisis en busca de posibles incidencias. Todo ello en modo local, dentro del propio sistema. Fueron los primeros IDS en desarrollar por la industria de la

seguridad informática.

2. NIDS (Net IDS)

Protege un sistema basado en red. Actúan sobre una red capturando y analizando paquetes de red, es decir, son sniffers del tráfico de red. Luego analizan los paquetes capturados, buscando patrones que supongan algún tipo de ataque. Bien ubicados, pueden analizar grandes redes y su impacto en el tráfico suele ser pequeño. Actúan mediante la utilización de un dispositivo de red configurado en modo promiscuo (analizan ,"ven" todos los paquetes que circulan por un segmento de red aunque estos nos vayan dirigidos a un determinado equipo). Analizan el trafico de red, normalmente, en tiempo real. No sólo trabajan a nivel TCP/IP, también lo pueden hacer a nivel de aplicación. Las capas del TCP/IP y las del modelo OSI, y su correspondencia:

*A este tipo de IDS pertenece Snort.

3. DNIDS

Este tipo de IDS, más que proteger, monitoriza la actividad entre varias redes. Tiene una visión global.

Por el tipo de respuesta

o

Pasivos

Son aquellos IDS que notifican a la autoridad competente o administrador de la red mediante el sistema que sea, alerta, etc. Pero no actúa sobre el ataque o atacante.

o

Activos

Generan algún tipo de respuesta sobre el sistema atacante o fuente de ataque como cerrar la conexión o enviar algún tipo de respuesta predefinida en nuestra configuración.

Snort puede funcionar de las dos maneras.

5 - Arquitectura de un IDS Normalmente la arquitectura de un IDS, a grandes rasgos, está formada: ~1) La fuente de recogida de datos. Estas fuentes pueen ser un log, dispositivo de red, o como en el caso de los IDS basados en host, el propio sistema. ~1) Reglas que contienen los datos y patrones para detectar anomalías de seguridad en el sistema. ~1) Filtros que comparan los datos snifados de la red o de logs con los patrones almacenados en las reglas. ~1) Detectores de eventos anormales en el tráfico de red.

~1) Dispositivo generador de informes y alarmas. En algunos casos con la sofisticación suficiente como para enviar alertas via mail, o SMS. Esto es a modo general. Ya veremos que cada IDS implementa la arquitectura de manera diferente. Snort, por ejemplo, tiene una arquitectura dividida en tres subsistemas: ~1) Decodificador de paquetes ~1) Motor de detección ~1) Loggins y alertas Evidentemente, son parte de la arquitectura global de un IDS que hemos comentado líneas más arriba.

6 - Dónde colocar el IDS Una actitud paranoica por nuestra parte nos podría llevar a instalar un IDS en cada host ó en cada tramo de red. Esto último sería un tanto lógico cuando se trata de grandes redes, no es nuestro caso ahora. Lo lógico sería instalar el IDS en un dispositivo por donde pase todo el tráfico de red que nos interese. Dificultades o o

Un problema de los IDS es cuando queremos implementarlos en redes commutadas ya que no hay segmento de red por donde pase todo el tráfico. Otro problema para un IDS son las redes con velocidades de tráfico muy altas en las cuales es difícil procesar todos los paquetes. Posición de IDS

o o o

Si colocamos el IDS antes del cortafuegos capturaremos todo el tráfico de entrada y salida de nuestra red. La posibilidad de falsas alarmas es grande. La colocación detrás del cortafuegos monitorizará todo el tráfico que no sea detectado y parado por el firewall o cortafuegos, por lo que será considerado como malicioso en un alto porcentaje de los casos . La posibilidad de falsas alarmas muy inferior. Algunos administradores de sistemas colocan dos IDS, uno delante y otro detrás del cortafuegos para obtener información exacta de los tipos de ataques que recibe nuestra red ya que si el cortafuegos está bien configurado puede parar o filtras muchos ataques.

En ambientes domésticos, que es el propósito de este taller sobre IDS y Snort, podemos colocar el IDS en la misma máquina que el cortafuegos. En este caso actúan en paralelo, es decir, el firewall detecta los paquetes y el IDS los analizaría.

7 - Introducción a SNORT

Snort es un IDS o 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 anomalía previamente definida como patrones que corresponden a ataques, barridos, intentos aprovechar alguna vulnerabilidad, análisis de protocolos, etc conocidos. Todo esto en tiempo real. Snort (www.snort.org) está disponible bajo licencia GPL, gratuito y funciona bajo plataformas Windows y UNIX/Linux. Es uno de los más usados y dispone de una gran cantidad de filtros o patrones ya 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. Este IDS implementa un lenguaje de creación de reglas flexible, potente y sencillo. Durante su instalación ya nos provee de cientos de filtros o reglas para backdoor, ddos, finger, ftp, ataques web, CGI, escaneos Nmap.... Puede funcionar como sniffer (podemos ver en consola y en tiempo real qué ocurre en nuestra red, todo nuestro tráfico), registro de paquetes (permite guardar en un archivo los logs para su posterior análisis, un análisis offline) o como un IDS normal (en este caso NIDS). En este taller daremos una importancia mayor a su funcionamiento como NIDS y, sobre todo, a la creación personalizada de reglas e interpretación de las alertas. La colocación de Snort en nuestra red puede realizarse según el tráfico quieren vigilar: paquetes que entran, paquetes salientes, dentro del firewall, fuera del firewall... y en realidad prácticamente donde queramos. Una característica muy importante e implementada desde hace pocas versiones es FlexResp. Permite, dada una conexión que emita tráfico malicioso, darla de baja, hacerle un DROP mediante el envío de un paquete con el flag RST activa, con lo cual cumpliría funciones de firewall, cortando las conexiones que cumplan ciertas reglas predefinidas. No sólo corta la conexiones ya que puede realizar otras muchas acciones. Veremos más adelante su funcionamiento y ejemplos.

Formato de la cabecera (header) del TCP

o

Puerto origen (16 bits). Puerto de la máquina origen. Al igual que el puerto destino es necesario para identificar la conexión actual.

o

Puerto destino (16 bits). Puerto de la máquina destino.

o

Número de secuencia (32 bits). Indica el número de secuencia del primer byte que trasporta el segmento.

o

Número de acuse de recibo (32 bits). Indica el número de secuencia del siguiente byte que se espera recibir. Con este campo se indica al otro extremo de la conexión que los bytes anteriores se han recibido correctamente.

o

Posición de los datos (4 bits). Longitud de la cabecera medida en múltiplos de 32 bits (4 bytes). El valor mínimo de este campo es 5, que corresponde a un segmento sin datos (20 bytes).

o

Reservado (6 bits). Bits reservados para un posible uso futuro.

o

Bits de código o indicadores (6 bits). Los bits de código determinan el propósito y contenido del segmento. A continuación se explica el significado de cada uno de estos bits (mostrados de izquierda a derecha) si está a 1:

URG. El campo Puntero de urgencia contiene información válida. ACK. El campo Número de acuse de recibo contiene información válida, es decir, el segmento actual lleva un ACK. Observemos que un mismo segmento puede transportar los datos de un sentido y las confirmaciones

del

otro

sentido

de

la

comunicación.

PSH. La aplicación ha solicitado una operación push (enviar los datos existentes en la memoria temporal sin esperar a completar el segmento). RST.

Interrupción

de

la

conexión

actual.

SYN. Sincronización de los números de secuencia. Se utiliza al crear una conexión para indicar al otro extremo cual va a ser el primer número de secuencia con el que va a comenzar a transmitir (veremos que

no

tiene

porqué

ser

el

cero).

FIN. Indica al otro extremo que la aplicación ya no tiene más datos para enviar. Se utiliza para solicitar el cierre de la conexión actual.

o

Ventana (16 bits). Número de bytes que el emisor del segmento está dispuesto a aceptar por parte del destino.

o

Suma de verificación (24 bits). Suma de comprobación de errores del segmento actual. Para su cálculo se utiliza una pseudo-cabecera que también incluye las direcciones IP origen y destino.

o

Puntero de urgencia (8 bits). Se utiliza cuando se están enviando datos urgentes que tienen preferencia sobre todos los demás e indica el siguiente byte del campo Datos que sigue a los datos urgentes. Esto le permite al destino identificar donde terminan los datos urgentes. Nótese que un mismo segmento puede contener tanto datos urgentes (al principio) como normales (después de los urgentes).

o

Opciones (variable). Si está presente únicamente se define una opción: el tamaño máximo de segmento que será aceptado.

o

Relleno. Se utiliza para que la longitud de la cabecera sea múltiplo de 32 bits.

o

Datos. Información que envía la aplicación.

También se puede usar junto a MySQL o Microsoft SQL, ejecutando consultas SQL a una base de datos. Guarda logs también en formato XML.

No se limita sólo al análisis de los protocolos típicos como ftp, smtp, http, pop3, telnet ... , además analiza otros: ethernet, arp, decnet, lat, rarp ...

Recompone tráfico fragmentado, analiza tráfico tipo BackOrifice (independientemente del puerto usado), es capaz de "ver" datos del tipo decode o unicode, traceroute, pings..... Puede actuar como antivirus, aunque esta opción no es muy recomendable. Es mejor dejar esta tarea a aplicaciones preparadas para ello. Snort como sniffer se basa en las librerías de captura de paquetes libcap que provee a snort de la capacidad de sniffer de paquetes. En windows la librería sería WinPCAP http://winpcap.polito.it/ . Snort puede, para su fácil configuración y gestión, usarse mediante una interfaz gráfica. Aquí hablaremos de IDScenter.

IDSCenter, ahora en su versión 1.09 Beta 2, es una interface gráfica que nos sirve para configurar todas las características de Snort como las alertas, tests, reglas, variables, funcionamiento junto a MySQL o BlackIce Defender, rotación de logs, notificaciones via mail o sonido, plugins, preprocesadores, FlexResp ...

EJEMPLO de funcionamiento básico en los tres modos:

o

Usando Snort en modo IDS:

Snort -l log -dev -h 192.168.4.0/24 -c snort.conf (Revisemos el contenido de la carpeta log)

o

Usando Snort en modo sniffer:

Snort -dev

o

Usando Snort en modo Packet Logger (registro de paquetes):

Snort -dev -l log (Revisemos el contenido de la carpeta log)

EXPLICACIÓN DE LAS OPCIONES UTILIZADAS:

-l log lo usamos para volcar la información la carpeta log que se supone está ubicada en C:\Snort\log. En esta carpeta se estructurarán una serie de directorios con el nombre de la dirección IP del host que genere el tráfico o intrusión. También creará en esta carpeta un archivo (alert.ids) donde registrará las alarmas que genere así como un archivo de registro de escaneado de puertos (si se da el caso), etc. Contenido de un alert.ids:

-dev imprime en pantalla la dirección IP y cabeceras TCP/UDP/ICMP, los datos que pasan por la interface de red con información bastante detallada.

-h 192.168.4.0/24 es el home network (nuestra red).

-c snort.conf indicamos que SNORT use el fichero de configuración de Snort con la lista de archivos de reglas y otros parámetros. Esta opción tiene una variante al cambiarse el archivo snort.conf por uno de reglas o rules personalizada.

Snort puede obtener los datos desde una interface de red -i eth0 o desde un archivo -r nombarchivo. Normalmente no hará fata indicarle la interface de red.

8 - INSTALACIÓN Y CONFIGURACIÓN DEL IDS CENTER En los siguientes capítulos veremos la instalación de IDSCenter, uno de los front-end (//interfaz gráfico//) de Snort más usados en sistemas Windows NT/2000/XP. Es licencia GNU General Public Licence //(GNU89)//.

9 - Descarga de IDSCenter En el momento en que se escribe este capítulo, la versión es la 109beta2 http://www.packx.net/packx/html/en/idscenter/index-idscenter.htm http://packetstormsecurity.nl/sniffers/snort/idscenter109beta2.zip Una vez descargado el archivo, lo descomprimimos, y ejecutamos el setup.exe. Seguimos los pasos normales para la instalación de cualquier programa de Windows. Hay que tener en cuneta también que es necesario la instalación de la librería WinPCAP: http://winpcap.polito.it/.

10 - Configuración Una vez instalado el programa, lo ejecutamos y aparecerá en la barra de iconos al lado del reloj:

un icono negro tachado de rojo. Este nuestro icono de IDSCenter. Botón derecho sobre el icono:

y pulsamos sobre Setting, tras lo cual aparecerá el front-end de configuración de Snort con el panel General > Main configuration:

Aquí comentaremos la configuración de nuestro programa. En este capítulo lo configuraremos desde IDSCenter con la configuración más básica. Más adelante iremos complicando la configuración y viendo más opciones.

Desde este panel configuraremos la versión de Snort instalada en nuestro sistema: "Snort 1.8" o "Snort 1.7".

o o o

Snort executable file: localización del ejecutable Snort.exe. Disponemos de un botón de navegación para su facil localización. Log file: ubicación del fichero de texto alert.ids, en el cual se almacenarán los logs de las alertas, intrusiones, etc a nuestro sistema. Log viewer: configura el tipo de salida para nuestros logs generados por Snort. Lo dejaremos de momento en internal logs viewer, aunque como vemos, podemos usar una salida tipo XML.

De momento esto es todo en este panel.

Vamos ahora al panel IDS rules > Snort config

Aquí le diremos a IDSCenter la ubicación del fichero de configuración de Snort (snort.conf).

Configuration file (Snort.conf): Ubicación de snort.conf

Aquí no hace falta configurar nada más. Ahora sólo tendremos que pulsar en el botón "Apply" para cargar snort.conf y nos aparecerá su contenido en la ventana.

Para comprobar que todo va bien y no hay errores de momento nos vamos al panel General > Overview:

En la ventana Configuration errors aparecerán, si se da el caso, los errores de configuración que hayamos cometido. Más abajo en Snort commandline vemos la línea de comandos que ejecutará Snort. Este paso de General > Overwiew para ver los errores de configuración lo podemos realizar en cualquier momento.

Panel Log setting > Logging parameters

Aquí entre otras muchas opciones que veremos en próximos capítulos, podemos seleccionar la interface de red. Útil para servidores con dos o más interfaces de red. Si hacemos algún cambio debemos pulsar "Apply".

Si pulsamos "Test setting" aparecerá una ventana DOS donde visualizaremos la ejecución de Snort en línea de comando para testear que con nuestra configuración no existe error alguno.

En este caso vemos que tras la carga de Snort.exe con los parámetros de configuración establecidos en IDSCenter, el sistema no nos devuelve error alguno y se queda el programa activo y en funcionamiento. Una vez visto esto, podemos cerrar la ventana.

11 - Puesta en marcha de SNORT con IDScenter Una vez realizados estos pasos ya podemos pulsar "Start Snort" que se encuentra arriba a la izquierda del panel que tengamos abierto.

Este icono que ahora aparece tachado dejará de estarlo y Snort entrará en funcionamiento como IDS,.

El panel de configuración ya podemos cerrarlo. Si pulsamos sobre el icono de Snort > botón derecho del ratón, tendremos un pequeño menú de opciones:

Pulsemos "View alerts" y veremos algo parecido a esto:

Este es el contenido del archivo alerts.ids donde se almacenan los logs de las alertas.

Si pulsamos en el menú anterior "Open logs folder", aparecerá el directorio logs con carpetas correspondientes a las direcciones IP de las máquinas que hayan sido logeadas por Snort, conteniendo detalles sobre la intrusión.

Ya tenemos trabajando a Snort como IDS, pero vamos a adelantar ahora algunas otras configuraciones.

12 - Otras opciones de IDSCenter En el panel Alerts > Alert notification

Podemos configurar si queremos algún tipo de sonido (.wav) para las alarmas y el modo en que funcionarán éstas.

También podemos hacer trabajar conjuntamente Snort con BlackICE para usar las configuraciones de Autoblock que vienen implementadas en BlackICE. Sólo tendremos que marcar en la casilla correspondiente e indicar donde esta el archivo de configuración de BlackICE (recordemos que este cortafuegos software no para la salida al exterior de posibles troyanos, sólo detecta y para los intentos de entrada, como el "cortafuegos" interno del XP).

En Alerts > Alert Mail podemos configurar Snort para que nos envíe un mensaje vía correo electrónico.

Siempre que queramos modificar alguna configuración desde IDSCenter, una vez que lo hayamos iniciado, debemos parar Snort: "Stop Snort" y aplicar los cambios "Apply". Una vez hecho esto ya podemos otra vez "Start Snort".

Panel IDS rules > Rules/Signatures

En este panel vemos todas las reglas, ya preconfiguradas, que podemos activar/desactivar según nuestras necesidades. También podemos añadir otros set de reglas que hayamos escrito nosotros mismos.

El resto de configuraciones como Network variables, Preprocesadores, etc lo veremos en el siguiente capítulo.

13 - Alert.ids: Fichero de alerta generado por SNORT El fichero Alert.ids es el archivo donde se almacenarán las alertas y registros de paquetes generados por Snort. Tiene un formato ASCII plano, fácilmente editable por cualquier procesador de textos.

Alert.ids está ubicado en el directorio /log dentro de la carpeta donde se realizó la instalación, normalmente C:\Snort.

*En este directorio también se almacenarán otros ficheros, como los relacionados a salidas o registros del preprocesador de scan de puertos o los registros de alertas asociados a la dirección IP que generó la alerta.

Para mejor comprensión de las alertas generadas por Snort, podemos configurar desde IDSCenter dos tipos de alertas:

1. Set alert mode FAST o Alerta Rápida 2. Set alert mode FULL o Alerta Completa

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

El modo de Alerta Completa nos devolverá 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.

Para configurar estos dos modos:

Panel Log setting > Logging parameters

Marcamos en "Set alert mode (desactivate with Snort MySQL...)" y a continuación entre Full y Fast. Terminada la operación Aplicamos la regla ("Apply") y "Start Snort".

Veamos dos ejemplos:

Se trata de dos simples accesos a un servidor proxy ubicado en el puerto 8080 de la máquina destino IP: 192.168.4.15 por parte del host IP: 192.168.4.3 que realiza la conexión mediante el puerto 1382 en el primer caso y 3159 en el segundo.

Snort clasifica o describe esta alerta como un intento de pérdida de información, clasificado como prioridad 2.

o Modo Alerta Rápida:

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

o Modo Alerta Completa:

[] [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

14 - CREACIÓN DE REGLAS CON SNORT ==== Introducción ==== El lenguaje usado por Snort es flexible y potente, basado en una serie de normas que serán las que nos sirvan de guía para la escritura de las reglas. Dentro de estas normas tenemos: ~- la descripción de cada regla ~- cabecera ~- opciones ~- uso de preprocesadores Dentro del lenguaje Snort de rules //(reglas)// //veremos// el //uso intensivo de nociones de TCP/IP//, en concreto de TCP, flag, números de secuencia, etc, etc, por lo cual es //imprescindible su repaso// para una mejor comprensión. Recomendado el uso tambíén de //software de captura de paquetes// tipo Ethereal o TCPdump/Windump para ver en un escenario real la función de las nociones aprendidas sobre TCP como:

~- el establecimiento de una conexión TCP //(ver explicación en el cápítulo dedicado a Nmap APÉNDICE 1.1)// ~- el flujo de datos ~- el uso de flags ~- conexiones half-open usadas en escaneos de puertos ~- etc. ==== Reglas ==== La reglas Snort las podemos dividir en dos secciones lógicas, a saber: //cabecera de la regla y opciones//: ~- La cabecera contiene //la acción de la regla en sí, protocolo, IPs, máscaras de red, puertos origen y destino y destino del paquete o dirección de la operación.// ~- La sección opciones contiene //los mensajes y la información necesaria para la decisión a tomar por parte de la alerta en forma de opciones.// Resumiendo lo visto hasta ahora, //las reglas Snort las dividiremos// de la siguiente manera: @@|| CABECERA ~- //Acción// ~- //Protocolos involucrados// ~- //Direcciones IP// ~//Números de puerto// ~- //Dirección de la operación// || OPCIONES ~- //Mensaje// ~//Opciones de decisión// || @@ EJEMPLO 1 Veamos ahora un ejemplo de regla Snort para alertar de un //escaneo nmap// del //tipo TCP ping//: alert tcp $EXTERNAL_NET any -> $HOME_NET any //(msg:"Escaneo ping con nmap";flags:A;ack:0; reference:arachnids,28;classtype:attempted-recon; sid:628; rev:1;)// Analicemos esta alerta: CABECERA ~- //Acción de la regla:// alert ~- //Protocolo:// tcp ~- //Direccion IP origen:// $EXTERNAL_NET //(toda la red)// ~- //Puerto IP origen:// any //(cualquiera)// ~- //Direccion IP destino:// $HOME_NET //(toda nuestra red)// ~- //Puerto IP destino:// any //(cualquiera)// ~- //Dirección de la operación:// -> //(puede ser ->, 192.168.1.0/24 111 //(content:"|00 01 86 a5|"; msg: "mountd access";)// Acceso al //demonio de administración// mountd de UNIX, el cual tiene tiene diversos problemas de desbordamiento de memoria intermedia, que permiten a un //atacante remoto// obtener //privilegios de administrador// en los sistemas vulnerables. Dos consideraciones: ~1) El orden de la sección opciones. Primero las opciones y después el mensaje. El orden, pues, es indiferente. ~1) La opción //'content'//. Es una de las opciones //más importantes// ya que nos permite la //búsqueda de contenidos dentro del campo datos del paquete IP//. Se puede añadir //'nocase'// para que la búsqueda de los datos no sea sensible a las mayúsculas. Estos datos pueden estar en formato hexadecimal, texto plano o binario.

15 - Practicas A. Descifrar la siguiente regla: alert tcp any 110 -> any any (msg:"Virus - Posible Virus-Worm Timofonica"; alert tcp any 110 -> content: "filename=\"TIMOFONICA.TXT.vbs\""; nocase; alert tcp any 110 -> reference:MCAFEE,98674; sid:799; classtype:misc-activity; rev:3;) B. Crear una regla para detectar download de ficheros *.MP3. Una posible solución: alert tcp $EXTERNAL_NET any -> $HOME_NET any //(msg: "Cuidado, están descargando MP3";flags: AP; content: ".mp3";)// Teoría para esta práctica En TCP cuando una aplicación desea asegurarse de que todos los datos que han pasado al nivel inferior se han transmitido, es decir, necesita estar segura de que todos los datos pasados a TCP han llegado al destino, se utiliza la función PUSH //(enviar inmediatamente o empujar los datos)//. Si se ejecuta una aplicación de cliente en un equipo con //una implementación de TCP/IP que no establece el bit PUSH en las operaciones de envío, se pueden producir retrasos en la respuesta//. Por tanto, las aplicaciones dedicadas a la transmisión de datos es norma común el establecer este bit. Esto lo podemos verificar claramente observando cualquier traza de http://windump.polito.it/ TCPDump/Windump o http://www.ethereal.com/ Ethereal si capturamos alguna trasmisión de información entre host de nuestra red. Por otra parte, en cualquier transmisión de datos siempre se envían mensajes de acuse de recibo //(ACK - Acknowledgement)// conforme se van va recibiendo las tramas //(Asentimiento de

datos)//. Resumiendo. En cualquier transmisión de datos, //una vez establecida la conexión TCP// tenemos: ~- Un indicador P es el flag P //(push)// presente en la cabecera del paquete TCP, indicando que se trata de un //paquete normal conteniendo datos//. ~- Un ack=x indica que se está //confirmando la recepción correcta de datos// hasta un determinado número de secuencia.

16 - Reglas Snort para casos varios 1.- W32.Sircam.Worm@mm 2001-07-20 -- W32.Sircam.Worm@mm alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "Te mando este archivo para que me des tu punto de vista"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "Espero me puedas ayudar con el archivo que te mando"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "Espero te guste este archivo que te mando"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "Este es el archivo con la informaci=n que me pediste"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "I send you this file in order to have your advice"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "I hope you can help me with this file that I send"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "I hope you like the file that I sendo you"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible W32.Sircam.Worm@mm"; content: "This is the file with the information that you ask for"; nocase; rev:2;) alert tcp any any -> any 25 (msg:"Virus - Posible VBS.VBSWG2.X@mm Worm"; content: "name=\"Homepage.HTML.vbs\""; nocase; rev:1;) 2.- Reglas para escaneos nmap varios zardoz~/src/snortrules>grep -i nmap * icmp.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Nmap2.36BETA or HPING2 Echo ";itype:8;dsize:0; reference:arachnids,162;) icmp.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING NMAP"; dsize: 0; itype: 8; reference:arachnids,162;) scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap fingerprint attempt";flags:SFPU; reference:arachnids,05;) scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap TCP";flags:A;ack:0;

reference:arachnids,28;) zardoz~/src/snortrules>

17 - Practica comentada. Un caso real Crear una regla Snort "desde cero" para la detección de ping desde windows 2000.

Para detectar un ping realizado desde fuera de nuestra red, lo primero que debemos saber es qué tipo de datos intervienen en la cabecera del datagrama IP, en la ICMP y los datos.

*La teoría TCP/IP nos dice que:

1. un echo request es de tipo 8 para obtener un echo reply (tipo 0)

2. en el campo Protocolo de la cabecera IP debe ir el dato ICMP y poco más recordaremos.

Así que la cuestión es cómo averiguar el resto de datos y, sobre todo, qué traza deja un ping enviado desde windows 2000.

*Formato de petición y respuesta de eco. Ping echo / echo request:

Para todo esto contamos con un tipo de herramientas llamadas sniffers. Utilizaremos para nuestra práctica Ethereal por ser de los más intuitivos y fáciles de usar e interpretar. Podemos usar también TCPDump/Windump.

1. Segundos antes de enviar un ping desde un host emisor pulsamos en Ethereal (o el soft que hayamos elegido para la captura de trazas): Capture > Start.

2. En nuestro host receptor activamos el capturador de paquetes.

3. Enviamos el ping al host receptor, dejando unos segundos para que "termine" el ping y pulsamos Stop en el panel de captura del host receptor

4. Buscamos en la secuencia de captura o traza, la información de envío de ping usando el protocolo ICMP.

Pulsando encima de la información nos saldrá algo paracido a esto en Ethereal:

Frame 61 (74 on wire, 74 captured) Arrival Time: Jun 28, 2002 09:04:11.247973000 Time delta from previous packet: 0.000060000 seconds Time relative to first packet: 1.864325000 seconds Frame Number: 61 Packet Length: 74 bytes Capture Length: 74 bytes Ethernet II

Destination: 00:04:76:9a:66:a6 (INFOGRAFIA5) Source: 00:01:02:9f:7b:0d (INFOGRAFIA3) Type: IP (0x0800) Internet Protocol, Src Addr: INFOGRAFIA3 (192.168.4.3), Dst Addr: INFOGRAFIA5 (192.168.4.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 60 Identification: 0x6aaa Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 128 Protocol: ICMP (0x01) Header checksum: 0x46be (correct) Source: INFOGRAFIA3 (192.168.4.3) Destination: INFOGRAFIA5 (192.168.4.5) Internet Control Message Protocol Type: 0 (Echo (ping) reply) Code: 0 Checksum: 0x4e5c (correct) Identifier: 0x0200 Sequence number: 05:00 Data (32 bytes)

0000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop 0010 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi

Las dos últimas líneas son los datos (32 bytes) que nos servirán como firma o huella para nuestra regla snort.

Ya sabemos la firma o huella que deja un ping en Windows 2000. Ya sólo nos queda crear una regla donde la opcion content tenga los datos "abcdefghijklmnopqrstuvwabcdefghi"

La regla nos quedaría entonces:

alert ICMP $EXTERNAL any -> $INTERNAL any (msg: "ICMP ping en Windows 2000."; dsize: 32; itype: 8; content: "abcdefghijklmnopqrstuvwabcdefghi"; depth: 32;)

Donde aparecen nuevos indicadores:

o dsize: tamaño de datos. comprobación del tamaño del contenido del paquete.

o itype: tipo de icmp, en este caso para un ping es 8.

o depth: extensión del tamaño de datos que se ha de inspeccionar.

De esta práctica podemos desprender que para la creación de la mayoría de las reglas Snort el procedimiento es estudiar las trazas dejadas por cortafuegos y NIDS que supongan algún tipo de ataque o intrusión al sistema que queremos proteger.

Basándonos en el estudio de estas trazas, hallaremos la firma o huella del ataque que nos servirá en la creación de la regla de detección.

18 - Instalación de las reglas creadas

Las reglas Snort de ubican en ficheros .rules (snort rules). Aquí vemos parte del contenido de uno de estos ficheros:

# (C) Copyright 2001,2002, Martin Roesch, Brian Caswell, et al. # All rights reserved. # $Id: virus.rules,v 1.16 2002/08/18 20:28:43 cazz Exp $ #

# VIRUS RULES #

# # NOTE: These rules are NOT being actively maintained. # # # If you would like to MAINTAIN these rules, e-mail # [email protected] # alert tcp any 110 -> any any (msg:"Virus - SnowWhite Trojan Incoming"; content:"Suddlently"; sid:720; classtype:misc activity; rev:3;) alert tcp any 110 -> any any (msg:"Virus - Possible pif Worm"; content: ".pif"; nocase; sid:721; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible NAVIDAD Worm"; content: "NAVIDAD.EXE"; nocase; sid:722; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; content: "myromeo.exe"; nocase; sid:723; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; content: "myjuliet.chm"; nocase; sid:724; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; content: "ble bla"; nocase; sid:725; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; content: "I Love You"; sid:726; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; content: "Sorry... Hey you !"; sid:727; classtype:misc-activity; rev:3;)

alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; content: "my picture from shake-beer"; sid:728; classtype:misc-activity; rev:3;) Crearemos un fichero como este personalizado para almacenar nuestras reglas creadas (lo importante de este fichero de texto plano son las reglas, el resto -con la marca # - es sólo a título informativo).

Estos ficheros .rules se almacenan en el directorio raíz de Snort (por defecto).

Instalación de las reglas desde IDSCenter

Panel de IDSCenter > IDS rules > Rules/Signatures

Con el navegador del panel buscamos nuestro archivo con las reglas o regla creada (.rules), la añadimos al set con "Add" y aplicamos con "Apply".

Esta operación la realizaremos, como ya comentamos en el TEMA 8, con Snort parado Stop Snort, una vez hecho todo el proceso lo volveremos a iniciar con los cambios aplicados.

19 - SNORT EN LINEA DE COMANDOS Ya adelantamos algo sobre usar Snort en línea de comando en el capítulo I de esta serie. Ahora nos adentraremos en el uso de Snort de esta forma, //abandonando por completo IDSCenter y cualquier GUI intermedia//. Aprenderemos también a configurar: ~- Reglas ~- Preprocesadores ~- y otras opciones desde el archivo de configuaciones de snort: //snort.conf.// Todos los ejemplos, mientras no se indique lo contrario, serán válidos para win32 y Linux / UNIX. C:\Snort20\bin>snort -*> Snort!