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 ->, <-, <>)// OPCIONES ~- //Mensaje:// msg ~- //Opciones:// flags:A;ack:0; reference:arachnids..(1) Un poco de teoría: ~- flags://A// Establece el contenido de los flags o banderas TCP, en este caso ACK //(puede tener varios valores y operadores que veremos más adelante)//. ~- ack://// Caso particular para valor ACK=0, es el valor que pone nmap para TCP ping scan. ~- reference://arachnids,28// Referencia un a un Advisory, alerta tipo Bugtrac, etc.
~- classtype:attempted-recon Categoría de la alerta según unos niveles predefinidos y prioridades (//veremos más adelante las categorías).// ~- sid://628// Identificación única para esta regla snort según unos tramos determinados. ~- rev://1// Identificación de la revisión o versión de la regla. EJEMPLO 2 En el //manual oficial// del Snort como primer ejemplo tenemos: alert tcp any any -> 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! <*Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 //(Build 72)// By Martin Roesch //(
[email protected], www.snort.org)// 1.7-WIN32 Port By Michael Davis //(
[email protected], www.datanerds.net/~mike)// 1.8 - 2.0 WIN32 Port By Chris Reid //(
[email protected])// USAGE: snort [-options]
snort /SERVICE /INSTALL [-options] snort /SERVICE /UNINSTALL snort /SERVICE /SHOW Options: -A Set alert mode: fast, full, console, or none //(alert file alerts only)// -b Log packets in tcpdump format //(much faster!)// -c Use Rules File -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)// -f Turn off fflush() calls after binary log writes -F Read BPF filters from file
-h Home network = -i Listen on interface -I Add Interface name to alert output -k Checksum mode //(all,noip,notcp,noudp,noicmp,none)// -l Log to directory -L Log to this tcpdump file -n Exit after receiving 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 Set explicit snaplen of packet //(default: 1514)// -q Quiet. Don't show banner and status report -r Read and process tcpdump file -R Include 'id' in snort_intf.pid file name -s Log alert messages to syslog -S 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 are standard BPF options, as seen in TCPDump
Uh, you need to tell me to do something... : No such file or directory
20 - Snort en modo Sniffer y registro de paquetes El formato genérico para este modo es: snort [-opciones] < filtro > C:\Snort20\bin>snort -v Running in packet dump mode Log directory = log 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 ([email protected], www.snort.org) 1.7-WIN32 Port By Michael Davis ([email protected], www.datanerds.net/~mike) 1.8 - 2.0 WIN32 Port By Chris Reid ([email protected]) 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 MODO SNIFFER Con esta opción -v iniciamos //snort visualizando en pantalla las cabeceras de los paquetes TCP/IP//, es decir, en modo sniffer. Esta opción es el modo verbouse y mostrará las cabeceras IP, TCP, UDP y ICMP. Si queremos, además, visualizar los campos de datos que pasan por la interface de red, añadiremos -d. 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 nos mostrará //información más detallada//. Nos mostrará las cabeceras a nivel de enlace.
MODO PACKET LOGGER //(registro de paquetes)// Con estas opciones, //y dependiendo del tráfico en nuestra red//, veremos gran cantidad de información pasar por nuestra pantalla, con lo cual sería interesante //registrar, guardar estos datos a disco para su posterior estudio//. Entraríamos entonces en 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 logs en un directorio determinado//, en este caso //C:\Snort20\bin\log//. Dentro de la carpeta log se creará una estructura de directorios donde se archivarán los logs. Podemos: -h// indicar la ip de la red a registrar// C:\Snort20\bin>snort -vde -l ./log -h 192.168.4.0/24 Running in packet logging mode Log directory = ./log -b que el //formato de los logs sea en modo binario// es decir, el modo que entiende TCPDump o Windump, para estudiar más a fondo con los potentes filtros de estos programas los logs de snort. //La salida del logs 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 -l ./log -b Running in packet logging mode Log directory = ./log Ventajas de utilizar esta opción -b ~- //N////o hará falta indicarle IP alguna de nuestra red// ( -h ). ~- //Guardará todo en un mismo archivo y recogerá datos de toda nuestra red// ~- Tampoco serán necesarias las opciones -de ~- Ni la opción -v. Lectura del archivo binario generado El archivo generado por snort en modo binario también podemos leerlo con este usando la opción: -rnombrearchivo.log Elección de interface de red Otra opción a toma en cuenta es -i para //indicar a snort qué interface de red usar// en el caso de que tengamos dos o más. ~- Si usamos snort para Win32: C:\Snort20\bin>snort -vde -i 1 ~- Para Linux/UNIX.
# snort -vde -i eth0 ~- Para averiguar las interfaces de que disponemos en Win32, usaremos la opción -W. C:\Snort20\bin>snort -W
21 - Snort en modo NIDS En este apartado es donde nos centraremos más. 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. C:\Snort20\bin>snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf En el archivo //snort.conf//, se guarda toda la configuración de: ~- Las reglas ~- Preprocesadores ~- Otras configuraciones necesarias para el funcionamiento en modo NIDS Con la opción -D indicará a snort que //corra como un servicio//. ~- Esto es sólo válido para las versión Linux/UNIX: # snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -D ~- Para las versión win32 usaremos /SERVICE /INSTALL: C:\Snort20\bin>snort /SERVICE /INSTALL -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf ~- /SERVICE /UNINSTALL desinstala snort como servicio.
22 - Alertas generadas. Modos de Alerta Snort creará, //a parte de la estructura de directorios//, un archivo //alert.ids// donde //almacenará las alertas generadas//. Hay varias maneras 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 ordenes: //completo, rápido, socket, syslog, smb (WinPopup), consola y ninguna.// FAST 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.// 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 FULL
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.// 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 SOCKET Snort 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 CONSOLE En modo console el programa 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 Se desactivan las alarmas. # snort -A none -c snort.conf SMB Permite a Snort realizar llamadas al cliente de SMB //(cliente de Samba, en Linux)//, y enviar mensajes de alerta a hosts Windows //(WinPopUp)//. Evidentemente este modo es para sistemas Linux / UNIX. Se ha de tener presente: ~- Para activar este modo de alerta, //se debe compilar Snort con el conmutador de habilitar alertas SMB// //(enable -smbalerts)//.
~- Para usar esta característica enviando un WinPopUp a un sistema Windows, añadiremos a la línea de comandos de snort: -M WORKSTATIONS SYSLOG El programa Snort envía las alarmas al syslog. C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -s //Este modo dispone de varios parámetros, que estudiaremos más adelante.// EVENTLOG Funcionando en este modo se 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. -PROXIMAMENTE En //próximos capítulos// avanzaremos en la //creación de reglas snort//, explicando todas las opciones y seguiremos con Snort //en línea de comandos// con la configuración del archivo //snort.conf//.
23 - APÉNDICE 1: ENVIANDO ALERTAS A UN SYSLOG REMOTO CON SNORT Y/O IDSCEN En este artículo vamos a ver una funcionalidad de Snort e IDSCenter. Se trata de usar la opción de envío de alertas a un syslog remoto.
Syslog es el servicio de registro de actividad presente en la mayoría de sistemas Unix.
Para Windows disponemos de varios programas que hacen de servidor syslog. Veamos uno de ellos. Se trata de Kiwi Syslog Daemon, aunque puede ser otro cualquiera.
http://www.kiwisyslog.com/products.htm#syslog
Una vez instalado el servidor syslog, procedemos a configurarlo para que escuche por un determinado puerto y así Snort pueda de forma remota enviar los logs a través de la red.
Configurando Kiwi Syslog Daemon
File > Properties > Imputs > UDP
Marcamos "Listen for UDP Syslog messages"
UDP Port (1-65535): 514 (en este caso 514, aunque puede ser cualquiera)
Configurando IDSCenter
Vamos a icono de IDSCenter pulsamos con el ratón en "Setting", para cargar el GUI de configuración de Snort. Pulsamos en "Stop Snort" para realizar los siguientes cambios:
IDS Rules > Output plugins
Log setting > Logging parameters
Add > Syslog alert plugins
marcamos "Log to remote syslog (-s)" Facility: LOG_LOCAL7
Server: IP del host donde esté corriendo el servidor syslog
Port: 514 o el que hayamos introducido en el servidor syslog
Priority: LOG_ALERT
marcamos:
LOG_CONS
LOG_PERROR
LOG_NDELAY
LOG_PID
Pulsamos "Add" para añadir el plugin configurado.
Para terminar pulsamos arriba del panel "Apply" para cargar la configuración en el archivo snort.conf y "Start Snort" para activar Snort.
A medida que Snort genere alertas basadas en las reglas activadas, las irá enviando al syslog remoto a través del puerto UDP que hayamos designado y veremos las alertas en la consola del syslog y serán grabadas en el directorio /log del servidor.
Configuración de syslog sin IDSCenter
Si tenemos Snort corriendo sin el GUI IDSCenter podemos también realizar esta operación añadiendo (-s) a nuestra línea de comandos Snort y modificando el archivo de configuración de Snort (snort.conf).
En Snort, tan sólo tendremos que añadir como hemos apuntado, la opción (-s). Ejemplo:
snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -s 192.168.4.3:514
-s activa envio a syslog
192.168.4.9: la IP de la máquina donde correo el servicio syslog
514: puerto UDP por donde escucha el servicio.
Ahora vamos al fichero de configuración de snort (snort.conf). Nos posicionamos en la sección de configuración de plugins de salida:
################################################################
# Step #3: Configure output plugins
# General configuration for output plugins is of the form:
# output :
################################################################
Añadimos una línea de tal forma que nos quede de esta manera:
################################################################
# Step #3: Configure output plugins
# General configuration for output plugins is of the form:
# output :
output alert_syslog: LOG_LOCAL7 LOG_ALERT LOG_CONS LOG_NDELAY LOG_PERROR LOG_PID
################################################################
También podemos hacer lo siguiente:
################################################################
# Step #3: Configure output plugins
# General configuration for output plugins is of the form:
# output :
output alert_syslog: host:192.168.4.3:514, LOG_LOCAL7 LOG_ALERT LOG_CONS LOG_NDELAY LOG_PERROR LOG_PID
################################################################
Es decir, que en snort.conf indicamos también el host y puerto del syslog remoto. De esta manera podemos prescindir del añadido -s 192.168.4.3:514 en la línea de comandos de Snort.
Testeando la configuración y envío al syslog
Mediante Windump o TCPDump verificamos que Snort está enviando las alertas al syslog:
Snort está enviando correctamente al syslog que corre en el host 192.168.4.3 las alertas al puerto UDP 514.
Vemos en la consola del syslog remoto que efectivamente las alertas aparecen correctamente.
