Snort. Opciones reglas no relacionadas con el contenido. ( III Parte )

Seguimos con las opciones de Snort que no está relacionadas con el contenido o Payload. Ya vimos en la primera parte las opciones Fragoffset y Fragbits. También vimos en la segunda parte TTL, ID, Dsize, Seq, Ack, Icode, Itype y Tos, que forman parte de campos de la cabecera IP, segmento TCP, e ICMP.

En este capítulo terminaremos con este tipo de opciones de reglas con ipopts, flags, flow y window.

IPOPTS

Uno de los campos de la cabecera IP que vimos en su momento es Opciones. Según el RFC:

Las opciones pueden o no aparecer en los datagramas. Deben ser implementadas por todos los módulos IP (host y pasarelas). Lo que es opcional es su transmisión en cualquier datagrama en particular, no su implementación.

En algunos entornos la opción de seguridad puede ser requerida en todos los datagramas.

El campo opción es de longitud variable. Pueden existir cero o más opciones.

Ipopts busca en el campo opcion de la cabecera del datagrama IP una de estas opciones:

• rr Registrar Ruta (Record Route). Usado para rastrear la ruta que sigue un datagrama internet.

• eol Fin de la lista de opciones. Esta opción ocupa un sólo octeto.

• nop Sin Operación. Esta opción ocupa un sólo octeto.

• ts Marca de Tiempo Internet (Internet Timestamp)

• sec Seguridad. Usado para Seguridad.

• lsrr Encaminamiento de Origen No Estricto (Loose Source Routing). Usado para encaminar el datagrama internet en base a la información suministrada por el origen.

• ssrr Encaminamiento de Origen Fijo (Strict Source Routing). Usado para encaminar eldatagrama internet en base a la información suministrada por el origen.

• satid Identificador de Flujo (Stream ID). Usado para transportar el identificador de flujo.

• any Si algúna opción está activa.

Ejemplo:

alert tcp any any -> 192.168.1.0/24 any (ipopts:lsrr;)

FLAGS

En el capítulo dedicado al Segmento TCP vimos el campo de bits reservados y bits de indicadores o flags. Lo recordamos:

Campo reservado (para un posible uso futuro) + Bits de código o indicadores. (6 + 6 bits.)

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.

Pues bien, la opcion flags de las reglas Snort, detecta la activacion de flags en el segmente TCP. como en otras opciones, admite comodines:

• + aparece el flag especificado y cualquier otro
• * se produce la coincidencia si cualquiera de los flags especificados aparece
• ! notación de negación.

Esta opción se usa, por ejemplo, para la detección de ciertos tipos de escaneos:

alert tcp $EXTERNAL_NET any -> $HOME_NET any /

(msg:"SCAN SYN FIN"; flow:stateless; flags:SF,12; /

reference:arachnids,198; classtype:attempted-recon; sid:624; rev:8;) 

De esta forma para detectar un SYN SCAN, la opción quedaría

flags:S

FLOW

Con esta opción indicamos que se aplique la regla solo a uno de los sentidos del flujo de comunicación. De esta forma podemos aplicar la regla solo a clientes o servidores. Veamos las opciones según los flujos.

• to_client respuesta de servidores A hacia B
• to_server peticiones de servidores A hacia B
• from_client peticiones de clientes A hacia B
• from_server respuesta de servidores de A hacia B
• established conexiones TCP establecidas
• stateless no tiene en cuenta la inspección de estado

Como ejemplo, si establecemos la opción flow de la siguiente forma:

flow:to_server,established;

estamos diciendo que: un cliente haya formalizado una petición, el servidor atiende e indicamos que la conexión haya sido establecida.

Otro ejemplo bastante simple:

alert tcp $HOME_NET 1024: -> $EXTERNAL_NET any /

(msg:"BACKDOOR netbus active"; flow:from_server,established; /

content:"NetBus"; 

WINDOW

Esta opcón verifica el campo del segmento TCP window o tamaño de ventana. (16 bits). Esta opción del segmento tcp establece el número de bytes que el emisor del segmento está dispuesto a aceptar por parte del
destino.

Por ejemplo: window:64857;