Sistemas de Detección de intrusos y Snort. (II). Creación de Reglas (II). Opciones de las reglas.

Seguimos avanzando en el estudio y creación de las reglas Snort que iniciamos en el capítulo dedicado a las reglas.

Hemos visto que las reglas snort se dividen en cabecera y opciones. Vamos a estudiar a continuación las opciones. Opciones que en las que establecemos los mensajes, decisiones a tomar por la regla o los valores del los campos que debe tener el paquete que cumpla la condición de la cabecera.

lo vemos en el siguiente ejemplo:

alert icmp 192.168.1.10 any -> $RED_EXTERNA any (msg:»lanzando un ping»;icode:0;itype:8;sid:00001;classtype:reglas_personales;rev:0;)

Las opciones están entre paréntesis. Cada opción esta separada de la siguiente mediante un ;.

Hemos visto que las reglas snort se dividen en cabecera y opciones. Vamos a estudiar a continuación las opciones. Opciones que en las que establecemos los mensajes, decisiones a tomar por la regla o los valores del los campos que debe tener el paquete que cumpla la condición de la cabecera.

lo vemos en el siguiente ejemplo:

alert icmp 192.168.1.10 any -> $RED_EXTERNA any (msg:»lanzando un ping»;icode:0;itype:8;sid:1000000;classtype:reglas_personales;rev:0;)

Las opciones están entre paréntesis. Cada opción esta separada de la siguiente mediante un ;.

• msg incluimos un mensaje en en el log. En este caso «lanzando un ping«.
• icode comprobamos el valor del campo code de la cabecera ICMP
• itype comprobamos el valor del campo type de la cabecera ICMP

  

Vemos en el gráfico de arriba una cabecera ICMP con los campos code (código) y type (tipo).

• sid un número para identificar la regla.
• classtype clase de ataque. Sirve para identificar el tipo de regla. Categoría de la regla.

Existen categorias predefinidas por Snort que se describen y almacenan en el archivo etc/classification.config. Las categorías se ordenan según su importancia.

Parte del contenido de este archivo donde observamos las classificaciones.

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1

# NEW CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: kickass-porn,SCORE! Get the lotion!,1
config classification: policy-violation,Potential Corporate Privacy Violation,1
config classification: default-login-attempt,Attempt to login by a default username and password,2

Vemos que si formato es:

config classification: ,,

Como usuarios podemos, según este formato, crear nuestras propias clasificaciones de reglas para nuestras reglas personalizadas que queramos crear.

Cuando creamos nuestra regla, tan solo tenemos que añadir la opción classtype:.

Ya veremos que existe una opción independiente priority que indica un prioridad independiente de la clasificación.

• rev revisión de la regla por posibles modificaciones.

Pero existen más opciones. Las describimos y añadimos algunos ejemplos.

Otras opciones de reglas Snort.

A parte de las opciones que ya hemos visto en el ejemplo anterior tenemos:

• reference referencia de una regla. Si tenemos una alerta, podemos buscar más información al sitio indicado en la referencia.

Lo vemos en el siguiente ejemplo:

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;)

Puede también contener una URL:

reference:url,www.cert.org/advisories/CA-2003-12.html

O contener varias referencias:

reference:arachnids,198;reference:bugtraq,2345

• gid se usa para identificar que parte de Snort genera un evento cuando se activa una regla. Es decir, nos informa si ha sido un determinado preprocesador (lo veremos más adelante) el que se activo. La lista de de valores gid se encuentra en etc/gen-msg.map

• metadata permite integrar información adicional sobre la regla.

Un ejemplo:

alert tcp any any -> any 80 (msg: «Shared Library Rule Example»; metadata:engine shared, soid 3|12345😉

• content busca un determinado patrón en el contenido del paquete. Es sensible a mayúsculas/minúsculas. Puede sert texto, binario o una mezcla de ambos. el contenido binario se encierra entre || y se representa en hexadecimal. Podemos negar también un contenido.

Algunos ejemplo:

alert tcp any 110 -> (content: «filename=\»TOMOFONICA.TXT.vbs\»»; nocase; msg: «Virus tomofonica»;)

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

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

Negación del contenido, observese que negamos con !:

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

• nocase para la opción content hacemos que el contenido sea independiente del uso de mayúsculas/minúsculas. La regla anterior nos sirve de ejemplo: content:! «NAVIDAD.EXE»; nocase

• rawbytes no hacer caso, para el contenido, de content del uso de preprocesadores.

• depth extensión del tamaño de datos que se ha de inspeccionar. Es también un modificador de content. Se especifica en bytes y se cuenta a partir del valor de offset que se especifique. Por defecto, si no se especifica offset se hace desde el principio.

• offset modicador de contect que indica a partir de donde se ha de inspeccionar el contenido. Eespecificado en bytes.

Un ejemplo:

alert tcp any any -> any 80 (content: «cgi-bin/phf»; offset:4; depth:20😉

Es decir: inspeccionar 20 bytes a partir del byte 4 del paquete TCP.

En el proximo capítulo seguiremos con modificadores de contect y el resto de opciones.