Configuración de Snort para Manipulación de Paquetes – Preprocessors

Una de las características mas interesantes de Snort y de casi cualquier IDS en la capacidad de implementar Preprocessors, estos son componentes del IDS que realizan operaciones de análisis de paquetes entrantes y salientes justo antes de que el motor de detección se ejecute y justo después de que el paquete ha sido recibido y decodificado.

Los preprocessors son un mecanismo ampliamente utilizado en Snort para restringir el uso de técnicas de evasión de IDS empleadas por atacantes con el fin de saltar sobre las reglas del motor de detección, por este motivo, si se desea fortalecer un sistema de detección de intrusos, esta opción es indispensable y tiene que ser correctamente configurada.

Los preprocessors se declaran en el fichero de configuración de Snort utilizando la palabra reservada

preprocessor <nombre_preprocessor> : <opciones_preprocessor>

A continuación se indica el uso de los preprocessors Frag3 y Stream5 que son la base de la cual dependen muchos de los preprocessors mas importantes en Snort.

Frag3:

Se trata de un modulo de Snort que permite tratar con paquetes IP fragmentados con el fin de modelar y detectar técnicas de anti-evasión utilizadas por atacantes, el concepto principal de este modulo es modelar los objetivos actuales de un segmento de red en lugar de solamente modelar los protocolos en busca de posibles ataques. Se trata de un concepto nuevo y que ayuda a los IDS a mitigar un problema que tienen actualmente: La “No-Estandarizacion” que se da en la implementación de las pilas del protocolo IP definidas en las RFC, dado que aunque las RFC definen un estándar en términos de seguridad y otros aspectos, en algunas de estas normas existen ciertas ambigüedades que son “mitigadas” por cada proveedor en el código que desarrollan para cumplir con ellas.

Si un atacante conoce el mecanismo de defragmentacion de paquetes IP utilizado por un objetivo, este puede fragmentar los paquetes de tal forma que el sistema objetivo los “junte” de tal forma que aunque tengan payloads maliciosos, no sean detectados como una amenaza. Por esta razón existe el processor Frag3.

A continuación se indica el mecanismo para activar este modulo en Snort.

1. Se necesita activar dos directivas, una directiva de configuración Global y otra directiva de instancia de motor, pueden existir un numero arbitrario de directivas de instancia de motor pero solamente existe una directiva de configuración Global. El preprocessor correspondiente a la configuración global de Frag3 es frag3_global, mientras que el preprocessor correspondiente a la instancia de motor es frag3_engine, La configuración de estos preprocessors es muy similar, la diferencia radica en que para el preprocessor global las opciones se separan con coma, mientras que para el preprocessor de motor se separa con espacio.

frag3_global: Cuenta con las siguientes opciones de configuración

max frags <numero>

Numero de fragmentos simultáneos a tracear es 8192 por defecto

memcap <bytes>

Tamaño de memoria reservada para las capturas (4 MB por defecto)

prealloc frags <numero>

Se trata de un modo de administración de memoria alterno, usando fragmentos prelocalizados.

disabled

Desactiva el preprocessor

frag3_engine: Cuenta con las siguientes opciones de configuración

timeout <segundos>

Tiempo de vida en segundos de los fragmentos en memoria, una vez se cumpla este periodo de tiempo, se borran automáticamente, el valor por defecto es 60 segundos.

min_ttl <valor>

Valor TTL mínimo aceptable para un fragmento, por defecto el valor es 1, el rango esta entre 1 y 255

detect_anomalies

Intenta detectar cualquier tipo de anomalía sobre un fragmento analizado.

bind_to <Lista de IP>

Se trata de un listado de direcciones IP validas, en este orden de ideas, el motor solamente permitirá el procesamiento de paquetes cuya dirección de destino este contenida en este listado, por defecto el valor de esta propiedad es all

overlap_limit <numero>

Limita el numero de fragmentos superpuestos por paquete, el valor por defecto es 0 (sin limite) sin embargo para que tenga efecto se deben establecer valores superiores a 0 ademas de que la propiedad “detect_anomalies” también debe encontrarse establecida.

min_fragment_length <numero>

Define el tamaño más pequeño de fragmento para ser considerado como valido, los fragmentos mas pequeños o iguales a este limite son considerados como maliciosos y se lanzará un evento, el valor por defecto es 0, (sin limite) sin embargo para que tenga efecto, debe de estar establecida la propiedad detect_anomalies.

policy <tipo>

Selecciona el mecanismo de defragmentacion utilizado por una arquitectura concreta, los valores de esta propiedad son:
“first”, “last”,“bsd”,“bsd- right” y “linux”

En este orden de ideas, una configuración de este Preprocessor puede ser:

Configuración mínima

preprocessor frag3_global

preprocessor frag3_engine

Configuración Avanzada

preprocessor frag3_global: max_frags 65536

preprocessor frag3_engine: policy windows detect_anomalies overlap_limit 10 min_fragment_length 100 timeout 180

preprocessor frag3_engine: policy linux detect_anomalies bind_to [192.168.1.33,192.168.1.34] min_fragment_length 100 timeout 180

Stream5

Se trata de un modulo en Snort capaz de realizar montaje de paquetes TCP y UDP basados en una arquitectura objetivo, también es capaz de tracear sesiones TCP y UDP. Con Stream5 se manejan opciones similares a las que se han indicado con Frag3, ya que permite la detección de superposicionamiento de fragmentos y de otras anomalías como Timestamp inválidos en paquetes IP, datos en paquetes SYN, FIN y Reset, etc.

Para Stream5 existen tres configuraciones TCP, UDP y ICMP Ademas de una configuración Global, (como en el uso del preprocessor Frag3) a continuación se lista su uso:

Stream5 Global: stream5_global

track_tcp <yes|no> Tracear sesiones TCP, por defecto es “yes”
max_tcp <numero> Número máximo de sesiones traceadas de forma simultanea, por defecto son ”262144”, el valor máximo es de ”1048576”, el valor mínimo es ”1”
track_udp <yes|no> Tracear sesiones UDP, por defecto es “yes”
max_udp <numero> Número máximo de sesiones UDP traceadas de forma simultanea, por defecto son “131072” , el valor máximo es de ”1048576”, el valor mínimo es ”1”
track_icmp <yes|no> Tracear sesiones ICMP, por defecto es “yes”
max_icmp <numero> Número máximo de sesiones ICMP traceadas de forma simultanea, por defecto son “65536” , el valor máximo es de ”1048576”, el valor mínimo es ”1”
disabled Para desactivar el modulo Stream5, cuando se desactiva este preprocessor, solamente las opciones memcap, max_tcp, max_udp y

max_icmp son aplicadas.show_rebuilt_packets Enseña los paquetes después de reconstruirlos para fines de depuración, por defecto esta opción se encuentra desactivada.

Stream5 TCP: stream5_tcp

bind_to <Direcciones IP> Listado de direcciones IP que deben contener los paquetes IP para que estos puedan ser procesados.
timeout <segundos> Número de Segundos en los cuales la sesión TCP (conexión) se mantendrá activa, por defecto su valor es de 30, el valor mínimo es de 1 y el máximo de 86400 (aproximadamente un día)
policy <tipo> Se trata de la política que se debe de aplicar para el tratamiento de los paquetes, los posibles valores son:
“first”: Primero el SO tratara paquetes superpuestos“last”: Los paquetes superpuestos serán tratados finalmente por el SO.“bsd” FreeBSD 4.x, 3.x y Recientes, NetBSD 2.x y recientes.

“linux”: Linux 2.4 y recientes

“old-linux”: Linux 2.2 y anteriores

“windows”: Windows 2000,XP, 95/98/ME

“win2003”: Windows 2003

“vista”: Windows Vista

“solaris”: Solaris 9.x y recientes

“hpux”: HPUX 11 y recientes

“hpux10”: HPUX 10

“irix”: IRIX 6 y recientes

“macos”: MacOS 10.3 y recientes

overlap_limit <numero> Limita el número de paquetes superpuestos por sesión, el valor mínimo es 0 el máximo 255, por defecto
require_3whs <segundos> Establece sesiones TCP solamente cuando ocurre un “handshake” es decir se ha completado la secuencia de reconocimiento y sincronización TCP SYN/SYN-ACK/ACK recibe un número de segundos que es el tiempo de gracia en el que las sesiones existentes deben ser consideradas como establecidas al momento en el que Snort se ha iniciado, inmediatamente después de este intervalo, la sesión es descartada, por defecto su valor es 0 (este valor indique que Snort asume que antes de su arranque no existen sesiones anteriormente establecidas) y el valor máximo es 86400, aproximadamente 1 día.
detect_anomalies Detecta y Alerta sobre anomalías en el protocolo TCP
check_session_hijacking Chequea un posible secuestro de sesión TCP, donde se valida la dirección MAC de ambos lados para la conexión, chequeando que los paquetes enviados para el establecimiento de la conexión (handshake) sean recibidos por sesión y que las direcciones MAC de todos ellos coincidan, cuando una de estas direcciones en cliente y servidor no son iguales se genera una alerta sobre una anomalía, para que esta opción funcione adecuadamente se tiene que establecer la propiedad detect_anomalies
dont_store_large_packets Los paquetes largos que son almacenados en el buffer de paquetes a reconstruir no son almacenados, se utiliza por razones de desempeño, sin embargo cuando se activa puede resultar en que algunos ataques no son detectados.
dont_reassemble_async No apilar paquetes que no han sido vistos en ambas direcciones de la conexión, por defecto los paquetes se apilan.
max_queued_bytes <bytes> Número de bytes máximo en la pila de paquetes a reconstruir en una sesión TCP, por defecto es ”1048576” (1MB), El valor de 0 significa sin limites.
max_queued_segs <numero> Limita el numero de segmentos apilados para remontaje de una sesión TCP dada por defecto es de ”2621” el valor de 0 significa sin limites.
ports < client|server|both|all puertos> Especifica donde se realizará el remontaje de los paquetes apilados, se especifica la ubicación (cliente, servidor o ambos) ademas se establece el listado de los puertos para realizar el remontaje, el valor mínimo es 1 y el máximo 65535, esta opción puede aparecer múltiples veces en un fichero de configuración
protocol <client|server|both> <all|service name(s)> Especifica donde se realizará el remontaje de los paquetes apilados, se especifica la ubicación (cliente, servidor o ambos) ademas se establece el nombre del servicio para realizar el remontaje, esta opción puede aparecer múltiples veces en un fichero de configuración, el valor por defecto es:

protocolo client ftp telnet smtp nameserver

dns http pop3 sunrpc dcerpc netbios-ssn imap login shell

mssql oracle cvs mysql.

Stream5 UDP: stream5_udp

timeout <segundos> Número de segundos para timeout de sesión, por defecto es “30” el mínimo es “1” y el máximo “86400” aproximadamente 1 día

Stream5 ICMP: stream5_icmp

timeout <segundos> Número de segundos para timeout de sesión, por defecto es “30” el mínimo es “1” y el máximo “86400” aproximadamente 1 día

La configuración de este preprocessor en el fichero de configuración de snort puede tener los siguientes valores.

preprocessor stream5_global: max_tcp 8192 track_tcp yes track_udp yes track_icmp yes

preprocessor stream5_tcp: bind_to 192.168.1.0/24, policy windows

preprocessor stream5_tcp: bind_to 192.168.1.0/24, policy linux

preprocessor stream5_tcp: policy solaris

Como se ha podido apreciar, la principal diferencia entre Frag3 y Stream5 es que Frag3 se enfoca en el procesamiento de los fragmentos enviados en paquetes IP, mientras que Stream5 se enfoca directamente sobre los paquetes que viajan entre origen y destino, no se trata de preprocessors excluyentes, por el contrario, tener habilitados y correctamente configurados ambos módulos es lo recomendado.