Introduccion a conceptos de IDS

y tecnicas avanzadas con Snort

Alejandro GramajoBaicom Networks

23 de junio de 2005

“Your eyes can deceive you. Don’t trust them!Stretch out with your feelings...”

Obiwan Kenobi

Indice

1. Introduccion a IDS 11.1. Tipos de IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Tecnicas de deteccion . . . . . . . . . . . . . . . . . . . . . . 21.3. Problemas con los IDS . . . . . . . . . . . . . . . . . . . . . . 21.4. Resumiendo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Snort 32.1. Open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Add-ons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3. Mejorando la performance . . . . . . . . . . . . . . . . . . . . 5

2.3.1. MMAPed pcap . . . . . . . . . . . . . . . . . . . . . . 52.3.2. Barnyard . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4. Software contrib . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Creando nuevas reglas 73.1. Examinando trafico . . . . . . . . . . . . . . . . . . . . . . . . 103.2. Event thresholding . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Modificando y rechazando paquetes 104.1. Ejemplo basico de Snort INLINE, para reescribir el payload . 114.2. Varios ejemplos mas avanzados . . . . . . . . . . . . . . . . . 12

4.2.1. Cambiando consultas MySQL . . . . . . . . . . . . . . 124.2.2. Rechazando consultas MySQL . . . . . . . . . . . . . 134.2.3. Evitando un buffer overflow . . . . . . . . . . . . . . . 154.2.4. Detectando un SQL injection . . . . . . . . . . . . . . 16

1

4.2.5. Detectando un XSS . . . . . . . . . . . . . . . . . . . 164.2.6. Devolviendo un mensaje “http” al cliente . . . . . . . 16

5. Para seguir pensando 175.1. Cambio de licencia para las reglas . . . . . . . . . . . . . . . 175.2. Futuro: Detectando 0 days? . . . . . . . . . . . . . . . . . . . 17

6. Apendice A 176.1. Compilando Snort usando Debian 3.0 (stable) . . . . . . . . . 17

1. Introduccion a IDS

La deteccion de intrusos es el proceso de monitorear computadoras oredes, para detectar entradas no autorizadas, actividad o modificacion dearchivos.

Un IDS puede tambien ser usado para monitorear trafico, por ej. ası pue-de detectar si un sistema esta siendo un objetivo de un ataque de red comoun DoS (denial of service).

1.1. Tipos de IDS

Existen dos grupos importantes en los tipos de IDS:

Host IDSOrientados a examinar los datos en computadoras individuales.

Network IDSExaminan el intercambio de datos entre computadoras. Esos paquetesson examinados y a veces comparados contra datos empıricos paraverificar su naturaleza: mala o buena.

Como se tiende a examinar varios puntos de la red es comun encon-trarlos de forma distribuida en la red.

Hybrid IDSUna mezcla de los dos tipos anteriores.

1.2. Tecnicas de deteccion

Existen varios tecnicas y tipos de deteccion para los IDS, estos son losmas usados y destacados:

Anomalıa (anomaly)Sirve para descubrir patrones anomalos comparandolos con los consi-derados normales.

2

Especial interes para aplicacion de algoritmos geneticos, redes neuro-nales y estadıstica (data mining en general [1])

Se puede separar tambien en “Protocol Modelling”, que buscan ano-malıas en los protocolos o configuraciones poco comunes.

Firma (signature)Comparacion de firmas almacenadas contra una porcion de un paquetede red.

Reduccion del analisis, subconjunto del total.

Objetivo (target)Generalmente a nivel de sistema operativo, buscan modificaciones enarchivos especıficos, controles de accesos, uso de recursos. (HIDS en sumayoria)

1.3. Problemas con los IDS

Cuando usamos los IDS nos encontramos con dos problemas muy impor-tantes:

Falsos positivosUn falso positivo es un termino aplicado a un fallo de deteccion enun sistema de alertas. Sucede cuando se detecta la presencia de unaintrusion en el sistema que realmente no existe.

Principalmente se pueden dividir en 5 categorıas (existen mas):

• Reactionary traffic alarmsSe detecta un comportamiento sospechoso como consecuencia detrafico generado anteriormente (generalmente no malicioso). Ej.ICMP network unreachable.

• Equipment-related alarmsSe detectan paquetes dentro del trafico de la red que identificacomo no “usuales”. Ej. balanceadores de carga.

• Protocol violationsSe producen por software mal programado (bugs) o que imple-mentan de forma incorrecta o anticuada algunas partes de losprotocolos de Internet.

• Non malicious alarmsAlarmas producidas al detectar rastros de comportamientos ma-liciosos pero que en este contexto determinado no lo son.Ej. publicamos un shellcode en nuestra pagina web :-)

• True false positivesToda alarma que no se encuentre en las anteriores categorıas.

3

Falsos negativosUn falso negativo es un termino que hace referencia a un fallo en elsistema de alerta.

Sucede cuando una intrusion existe en nuestro IDS y es “permitida”(ignorada o no detectada) por el sistema de alerta.

Ej. 0 days :-(

1.4. Resumiendo

Un sistema de intrusos para que sea util y confiable debe producir losmınimos falsos positivos posibles y “ningun” falso negativo.

2. Snort

2.1. Open source

Snort es rapido, flexible y un NIDS open-source. Empezo a fines de 1998como un sniffer. Con licencia GPL version 2. 1

Por default utiliza tecnicas de deteccion de firmas y anomalıas no es-tadıstica.

Puede correr en varios modos de ejecucion:

Sniffer (similar al tcpdump [11])

Packet Logger

NIDS

IPS con FlexResp o InlineRequiere libnet [13]. Para Inline se necesita libipq [12].

El “engine” del Snort esta dividido en componentes:

Decodificador del paquete (Packet Decoder)Toma los datos de libpcap [11] o libipq.

Preprocesadores (Preprocessors o Input Plugins)

Motor de deteccion (Detection Engine)Comparacion contra firmas

Logging y sistema de alerta (Logging and Alerting System)

Plugins de salida (Output Plugins)1puede cambiar a una diferente.

4

internet --> packet --> preprocessors --> detection --> loggingdecoder engine alert

| |pcap / ipq v v

drop output plugins

Estos componentes trabajan juntos para detectar ataques particulares ygenerar una salida en algun formato requerido.

El “decodificador de paquete”, toma los paquetes de diferentes tipos deinterfaces de red, y prepara el paquete para ser “preprocesado” o enviado almotor de deteccion.

Los “preprocesadores” son componentes o plugins que pueden ser usadoscon Snort para arreglar, rearmar o modificar datos, antes que el “motor dedeteccion” haga alguna operacion para encontrar si el paquete esta siendoenviado por un intruso.

Algunos preprocesadores realizan deteccion buscando anomalıas en losheaders de los paquetes y generando alertas. Son muy importantes porquepreparan los datos para ser analizados contra reglas en el motor de deteccion.

El “motor de deteccion” es la parte mas importante de Snort, es res-ponsable de detectar si alguna actividad de intrusion existe en un paquete.El motor utiliza las reglas para este proposito. Las reglas (o cadenas) sonmacheadas contra todos los paquetes. Si un paquete machea una regla, laaccion descripta en la misma es tomada.

Dependiendo que detecte el motor dentro de un paquete, el “logging ysistema de alerta”, se encarga de loguear o generar una alerta. Los logs sonalmacenados en archivos de texto, archivos con formato “tcpdump” u otroformato.

Los “plugins de salida” toman la salida del “sistema de alerta” y per-miten almacenarlas en distintos formatos o reaccionar antes el mismo. Porejemplo:. enviar emails, traps SNMP, syslog, insertar en una base de datos,etc. 2

Snort nos permite extenderlo y agregarle nuevas funciones. Posee muchafacilidad para programar nuevos add-ons, ya sean preprocesadores o outputplugins.

2.2. Add-ons

Preprocesadores Existen mas de 14 pre-procesadores. Los mas desta-cados son:

• port scanning (flow-portscan y sfportscan)2SnortSam es un plug-in de salida y nos permite bloquear conexiones en router y

firewalls.

5

• frag2 (ip packet defragmentation)

• stream4 (tcp stream reassembly y stateful inspection)

• http-inspect

• arp-spoof

Estos no estan integrados por default el source del Snort:

• spp-fnord (Multi-architecture mutated NOP sled detector)

• Spade [19] (Statistical Packet Anomaly Detection Engine)

Output plugins

• Database (mysql, postgres, etc)

• Syslog

• XML

• Traps SNMP

• Mensajes SMB

2.3. Mejorando la performance

Cuando analizamos trafico en tiempo real, necesitamos mas recursos dede “cpu” y “memoria”. Obviamente depende como almacenamos las alertasla entrada y salida “io” de “disco” tambien puede ser un cuello de botella.

La creacion de reglas optimas es importante, para no demorar al motorde deteccion. En la seccion 3 “Creando nuevas reglas” se dan tips paraaumentar la eficacia y velocidad de las reglas.

Aca hay un detalle de dos formas de aumentar la performance de Snort.

2.3.1. MMAPed pcap

Es una reimplementacion de la libpcap [9], agregandole un cambio, envez de copiar los paquetes de la “kernel memory” a‘ “userland memory” lalibpcap puede encolar los paquetes en un “shared buffer” que el Snort puedeleer directamente.

Este cambio aumenta la velocidad del Snort, limitando el numero deveces que un paquete es copiado antes que el Snort pueda realizar una de-teccion sobre el. (packet decoder)

El buffer en ethernet puede tener hasta 52Mbytes.

6

2.3.2. Barnyard

El metodo de output plugin mas rapido es el “unified”, este loguea even-tos en formato binario y permite guardar dos tipos de archivos, “alert” y“log”. [10]

El primero tiene los datos del evento y el segundo el paquete en formadetallada.

Para recolectar esta informacion, se puede utilizar el Barnyard [10], esdaemon que se encarga de tomar la informacion y enviarla a una base dedatos, archivo, etc.

2.4. Software contrib

Existen varios software para administrar los IDS, mirar alertas, etc.

ACID / BASEEs una consola para el Snort, que trabaja con la base de datos (inter-fase web, php, apache y mysql).

OinkmasterPermite hacer un upgrade de las reglas de forma automatica (o semi).

IDS Policy ManagerPermite administrar las reglas en forma de polıticas por sensor. Lainterfaz es muy potente pero esta hecha para Win32 y no es de codigoabierto.

SnortCenterAdministra las reglas y maneja remotamente los sensores (interfaseweb).

SnortsamPlugin que permite bloquear direcciones IP en los firewalls mas cono-cidos:

COMERCIALES:

• Checkp*int Firewall-1

• Cisc* PIX firewalls

• Cisc* Routers (con ACLs o Null-routes)

• F*rmer Netscreen, (ahora Juniper)

• WatchGuard Fireb*x

• 8signs (Win32)

• M$ ISA Server (Win32)

• CHX

7

OPEN SOURCE AND FREE:

• ipchains

• iptables (ebtables tambien)

• ipf (conocido en BSD)

• ipfw2 (FreeBSD 5.x)

• pf (OpenBSD packet filter)

Y otros...

3. Creando nuevas reglas

Las reglas nos sirven para machear el trafico contra una “firma”, la cualdispara una alarma (o evento).

Es importante mantener nuestra base de reglas actualizada, pero paramayor eficacia es conveniente armar (o modificar) nuestras propias reglas,de esa manera minimizamos los falsos positivos.

Las reglas que abarcan muchos casos generales, suelen poseer altos ındi-ces de falsos positivos, mientras que las particulares no.

La idea es dar un detalle de como crear nuevas reglas avanzadas, enfuncion de los servicios que deseamos monitorear.

Snort permite mucha versatilidad para crear nuevas reglas. La estructurade una regla tiene esta forma:

+---------------+----------------+| RULE HEADER | RULE OPTIONS |+---------------+----------------+

Y el RULE HEADER tiene una forma similar a:

+--------+----------+---------+------+-----------+---------+------+| ACTION | PROTOCOL | ADDRESS | PORT | DIRECTION | ADDRESS | PORT |+--------+----------+---------+------+-----------+---------+------+

Las RULE OPTIONS son muchısimas, seria extenso explicar todas aquı,para una referencia mayor ir al manual del Snort [1].

Ejemplos de reglas:Generamos el mensaje “Ping” como alerta, ante la presencia de ICMP

alert icmp any any -> any any \(msg: "Ping";)

Si un server responde con SSH-1 tiene activado el protocolo viejo SSH1

8

alert tcp $HOME 22 -> $EXTERNAL any \(msg: "SSH version 1 support detected; \flow: to_client, established; \content: "SSH-1."; \nocase; \offset: 0; \depth: 6;)

Podemos activar reglas

activate tcp $EXTERNAL any -> $HOME 143 \(flags: PA; \content: "|E8C0FFFFFF|/bin";activates: 1; \msg: "IMAP buffer overflow";)

dynamic tcp $EXTERNAM any -> $HOME 143 \(activated_by 1;count: 50;msg: "50 paquetes al 143, una vez activado el IMAP bo")

Para una referencia detallada, de las opciones para las reglas, se debemirar la documentacion del Snort [1].

Cuando armamos una regla, para mejorar su eficacia y velocidad:

Intentaremos machear la vulnerabilidad en si, no el codigo exploit, yaque estos pueden cambiar con facilidad.

Utilizar “content” en la medida que sea posible. La primera fase delmotor de deteccion del Snort 2.x, busca el patron del content, cuantomas exacto sea mas exacto el el match.

Atrapar las singularidades del protocolo. Por ej.

Queremos generar una alerta cuando se intenta loguear un usuariocomo “root” al ftp.

alert tcp any any -> any any 21 (content:"user root";)

Tenemos un problema ya que el protocolo ftp acepta:

’USER root’’user root’’user root’’user<tab>root’

9

Una regla mejor seria:

alert tcp any any -> any 21 \(flow:to_server,established; \content:"root"; \pcre:"/user\s+root/i"; )

El “flow” se utiliza para verificar que el trafico esta llendo hacia elserver y esta establecido.

El “content” machea la palabra “root”, las reglas content son impor-tantes ya que descarta rapidamente si no encuentra el match.

El “pcre” es para expresiones regulares, y en este caso busca el co-mando separado por un caracter o mas (espacio o tab), seguido delusuario, e ignora entre mayusculas y minusculas.

Optimizacion de reglas. Por ej.

NOTA:Las reglas poseen una naturaleza recursiva, si un patron de una re-gla machea y si ninguna de las opciones posteriores falla, entonces sevuelve a buscar en el paquete otra vez, desde el lugar donde macheola vez anterior. Y se repite hasta que el patron no sea encontrado ohasta que las opciones concuerden.

Si buscamos un paquete de size 1 byte con el “;” adentro: Pensarıamosesta regla:

content:"|29|"; dsize:1;

Sin embargo, por la naturaleza recursiva del Snort, si tenemos un pa-quete de 1000 bytes con todos “;”, macheara 1000 veces!

Para evitar esto:

dize:1; content:"|29|";

De esta manera solo agarra payloads con “data size” de 1 byte.

Probar valores numericos

Existen dos opciones muy importantes que se incluyeron a partir dela version 2.x: “byte test” y “byte jmp”, las dos son utiles para armarreglas que chequeen bytes dentro de una cadena o payload.

10

3.1. Examinando trafico

Cuando creamos una regla para un servicio especifico, lo mejor que pode-mos hacer es analizar el protocolo del mismo. Buscar como funciona, dondeestan las fallas o donde pueden estar.

Para eso es importante manejar alguna herramienta de “sniffing”, en estonos puede ayudar el Snort (en modo sniffer) o el TCPDUMP.

Veremos en el proximo tema, un detalle de un protocolo especifico, ycomo ajustar una regla para el mismo.

3.2. Event thresholding

Esta es una extension especial a las opciones, que nos permite reducirel numero de alertas logueadas para evitar “ruido”. Y puede ser usado paracrear un nuevo tipo de reglas, que limitan la cantidad de veces, que seproduce un evento en un determinado intervalo de tiempo.

4. Modificando y rechazando paquetes

Una utilidad que se le puede dar al Snort es transformarlo en un IntrusionPrevention System (IPS).

Un punto importante en este tema es que el Snort debe estar en unpunto especial de nuestra red, ya sea como gateway/firewall o un bridge. Latopologıa de nuestra red es completamente dependiente en este caso.

Aquı hay que tener en cuenta que si el Snort comete un “falso positivo”,se bloqueara una conexion “valida”.

Para lograr un IPS existen varias maneras:

Examinar los logs en “tiempo real” y agregar reglas en nuestro firewall(local o remoto). Como ejemplo podemos usar el SnortGuardian queutiliza nuestro firewall local (por ej. iptables/ipf/etc).

Compilar Snort con FlexResp o INLINE. De esta manera podemosarmar reglas que permitan al Snort que bloquee o rechace las cone-xiones, de acuerdo a los patrones que armemos. Tambien podemos,cuando usamos “http” devolver un mensaje al cliente.

Snort INLINE nos provee la facilidad de modificar el payload, esto nospuede servir cuando tenemos un server que no podemos patchear o elpatch todavıa no salio y no podemos desactivar la funcionalidad queposee el bug.

11

4.1. Ejemplo basico de Snort INLINE, para reescribir el pay-load

Supongamos que tenemos un server en la DMZ “thttpd” en el port 80,detras de un firewall que hace NAT.

internet||

firewall|

------+----+-|

thttpd192.168.0.2

Ahora cuando vemos la respuesta del pedido ”HEAD...”

asdf@nowhere:~$ curl -I public80HTTP/1.1 200 OKServer: thttpd/patched_by_baicomContent-Type: text/html; charset=iso-8859-1Date: Mon, 07 Mar 2005 21:04:20 GMTLast-Modified: Fri, 29 Oct 2004 18:57:50 GMTAccept-Ranges: bytesConnection: closeContent-Length: 482

Utilizando una caracterıstica del Snort, llamada INLINE, podemos rees-cribir la porcion de paquete que queramos, a modo de ejemplo, voy a cambiarel banner del “Server:”, mas adelante haremos algo mas util :-)

Esta seria la regla ejemplo, para reescribir:

alert tcp $EXTERNAL any -> $HOME 80 \(msg: "server signature replace"; \content: "Server|3A20|thttpd/patched_by_baicom"; \replace: "Server|3A20|thttpd/patched_by_INLINE";)

Aca vemos la modificacion:

asdf@nowhere:~$ curl -I public80HTTP/1.1 200 OKServer: thttpd/patched_by_INLINE <----------------- BINGOContent-Type: text/html; charset=iso-8859-1Date: Mon, 07 Mar 2005 21:06:40 GMT

12

Last-Modified: Fri, 29 Oct 2004 18:57:50 GMTAccept-Ranges: bytesConnection: closeContent-Length: 482

Bueno ahora la explicacion de como funciona todo esto, pero antes asimple vista (casi) podemos ver una limitacion importante que es el tamanodel paquete macheado y el tamanno del paquete modificado TIENEN QUESER IGUALES.

Snort mas el patch de INLINE, en vez de tomar los paquetes de libpcap[11] lo toman de libipq (iptables queue).

Pasando del modo kernel al modo usuario de esta manera, en el modousuario, en este caso dentro del Snort se le aplica un “verdict” al paquete,esto permite aceptarlo, denegarlo y modificarlo. Como vimos anteriormente.

El ejemplo que vimos recien, realmente no tiene una utilidad practica,a menos bien que queramos cambiar el banner de nuestro server web, paraevitar un “banner grabbing”.

Usar INLINE tiene varios problemas, si el proceso Snort, se cae, nuestropaquete no seguira su curso, ya que necesita de un proceso en modo usuarioque aplique el “verdict” correspondiente.

Otra cuestion importante es la performance, si tenemos grandes cantida-des de reglas a modificar y grandes flujos de datos estamos en un problema.

Es importante recalcar que no es la unica, ni la mejor forma de modificarun paquete usar Snort INLINE, pero es una opcion a tener en cuenta.

4.2. Varios ejemplos mas avanzados

Para entender como armar una regla que evite falsos positivos, e intenteser lo mas optima posible,

4.2.1. Cambiando consultas MySQL

Existen varios comandos que podrıamos llamarlos “peligrosos”:

UNION SELECTLOAD_FILE functionLOAD DATA INFILE statementSELECT... INTO OUTFILE statementBENCHMARK functionUser Defined Functions (UFDs)DROP DATABASE

Seria interesante poder eliminarlas (hay otras formas posibles, ej. enmy.cnf set-variable=local-infile=0)

Eliminamos la funcion “drop database”:

13

alert tcp any any <> any any \(msg: "mysql replace"; \content: "drop database"; \replace: "select’LAMER’";)

Si nos conectamos al mysql desde un host remoto

mysql> drop database test;+-------+| test |+-------+| LAMER |+-------+1 row in set (0.01 sec)

4.2.2. Rechazando consultas MySQL

Nos conectamos al motor, y ejecutamos un “drop table test1”, poniendoel Snort en modo sniffer podemos ver el paquete que envıa el cliente al server:

HEADER----------------------------------------------------------------03/10-19:07:09.572760 200.123.146.139:32975 -> 192.168.0.2:3306TCP TTL:62 TOS:0x8 ID:12232 IpLen:20 DgmLen:73 DF***AP*** Seq: 0x35C18013 Ack: 0xE0DAC3DA Win: 0x16D0 TcpLen: 32TCP Options (3) => NOP NOP TS: 156914262 165056290

PAYLOAD----------------------------------------------------------------11 00 00 00 03 64 72 6F 70 20 74 61 62 6C 65 20 .....drop table74 65 73 74 31 test1

Aca podemos ver un detalle del protocolo del MySQL para “querys”::

11 00 00 body length= 17 bytes (little endian)00 packet= 003 command= QUERY

64 72 6F 70 20 74 61 62 6C 65 20 74 65 73 74 31 args= drop table test1d r o p t a b l e t e s t 1

Como vemos empieza el texto del “query” en el 6to byte. Esto nos sirvepara fijar el offset en 5 (empieza en 0) en nuestra regla.

Si quisieramos rechazar la conexion:Regla para INLINE, “reject” le dice al IPTABLES que dropee el paquete

y lo loguee el Snort, y envia un TCP reset si el protocolo es TCP, o un ICMPPORT UNREACHEABLE y el protocolo es UDP

14

reject tcp $EXTERNAL any -> $HOME 3306 \(msg: "mysql drop reject"; \content: "drop table"; \offset: 5; )

Con FlexResp no necesitamos crear una regla QUEUE (no usa libipq).Regla para FrexResp, “resp:” permite configurar modificadores de res-

puesta “rst snd” envıa TCP-RST al socket que esta enviando, “icmp all”envia los paquetes ICMP NET UNREACH, ICMP HOST UNREACH eICMP PORT UNREACH.

alert tcp $EXTERNAL any -> $HOME 3306 \(msg: "mysql replace2"; \content: "drop table"; \offset: 5; \resp: rst_snd, icmp_all; )

Aca vemos el efecto de la segunda regla, que utiliza FlexResp:Nos conectamos y ejecutamos el “drop table ...”

bnall2:/usr/local/src# mysql -h bna140 -u test -ptest testYour MySQL connection id is 45 to server version: 3.23.49-log

Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer.

mysql> drop table test1;ERROR 2013 (HY000): Lost connection to MySQL server during query

Y si miramos el paquete enviado al cliente para “resetear” la conexion...

03/10-19:23:13.855643 200.123.146.139:32977 -> 192.168.0.2:3306TCP TTL:253 TOS:0x0 ID:0 IpLen:20 DgmLen:40 DF*****R** Seq: 0x71E77E7C Ack: 0x0 Win: 0x0 TcpLen: 20

^|BIT RESET

Y podemos ver los 3 tipos de icmp devueltos...

03/10-20:17:02.075098 200.123.146.140 -> 200.123.146.139ICMP TTL:110 TOS:0x0 ID:52957 IpLen:20 DgmLen:56Type:3 Code:0 DESTINATION UNREACHABLE: NET UNREACHABLE

03/10-20:17:02.075111 200.123.146.140 -> 200.123.146.139ICMP TTL:110 TOS:0x0 ID:52957 IpLen:20 DgmLen:56

15

Type:3 Code:1 DESTINATION UNREACHABLE: HOST UNREACHABLE

03/10-20:17:02.075141 200.123.146.140 -> 200.123.146.139ICMP TTL:110 TOS:0x0 ID:52957 IpLen:20 DgmLen:56Type:3 Code:3 DESTINATION UNREACHABLE: PORT UNREACHABLE

Como vemos analizando el protocolo en detalle podemos ver muchascosas, por ejemplo si supieramos que a partir de un tamano de paquete, seproduce un overflow, podrıamos verificar el tamano y crear alguna regla quenos avise.

Supongamos por un momento que existe un bug en los query del MySQL,y se produce cuando el tamano del paquete es mayor a 4095 (0x0FFF)

En la primera parte del protocolo vendrıa algo ası:

00 10 00 body length= 0x1000 == 4096 (little endian)XX packet= 003 command= 0x03 == QUERY

Hacemos una regla que si el paquete es mayor a ese tamano dispare unaalerta:

alert tcp $EXTERNAL any -> $HOME 3306 \(msg: "mysql command query packet size > 4095"; \byte_test:3,>,4095,0, little; \content: "|03|"; \offset: 4; )

4.2.3. Evitando un buffer overflow

Mirando un exploit y el reporte del: ’remote buffer overflow exploit forthe Arkeia Network Backup Client’ podemos armar una regla para evitarlo,veamos los detalles:

El buffer overflow ocurre cuando un paquete con tipo 77 es enviado conla seccion de datos muy grande.

Para construir una regla util, tenemos que pensar no en armar un caso,particular del codigo exploit, sino en entender donde esta el bug, en queparte se produce.

Primero vamos a analizar el header del protocolo enviado al cliente:

00 4d 2-bytes type 77 requestXX XX XX XX 4-bytes ?nn nn 2-bytes size de la seccion datos (big endian)... seccion datos

Una regla para atrapar esta vulnerabilidad y el intento de explotarla:

16

alert tcp $EXTERNAL any -> $HOME 617 ( \content:"|00 4d|"; \offset:0; \depth:2; \byte_test:2,>,23,6; \ # bytes 7 y 8, son mayor a 23?isdataat:31; \ # hay datos en el byte 31?content:!"|00|"; \ # distinto de NULLoffset:8; \ # a partir 9no bytedepth:23; ) # hasta 23 bytes

4.2.4. Detectando un SQL injection

Para estos casos y para el XSS son muy utiles las expresiones regulares.Aca detectamos con expresiones regulares una injeccion de meta-caracteres:

simple-quote (’), double-dash (--) y comment (#)

alert tcp $EXTERNAL any -> $HTTP 80 \(msg:"SQL Injection - Meta chars detected"; \flow:to_server,established; \uricontent:".cgi"; \pcre:"/(\%27)|(\’)|(\-\-)|(%23)|(#)/i"; );

Detectar una ejecucion de un store procedure “exec sp” o “exec xp” enM$ SQL usando como expresion regular de la alerta:

pcre:"/exec(\s|\+)+(s|x)p\w+/ix";

Para detectar comandos en particular, por ej “union”:

pcre:"/((\%27)|(\’))union/ix";

4.2.5. Detectando un XSS

Esta alerta mira un tag de apertura html (<) y su hexa equivalente,seguido de uno o mas caracteres que no son newline, y seguido de su tag decierre (>) o su hexa equivalente:

pcre:"/((\%3C)|<)[^\n]+((\%3E)|>)/i";

4.2.6. Devolviendo un mensaje “http” al cliente

Podemos devolver un mensaje al cliente http, utiliza FlexResp:

alert tcp any any <> $HOME 80 \(content: "p0rn.html"; \ # patron que macheamsg: "Not for you!"; \ # loguea y mensaje devueltoreact: block, msg; ) # bloquea y envia el mensaje

17

En este ejemplo podemos usar “uricontent”. Vemos el pedido y la res-puesta:

GET /p0rn.html HTTP/1.0

Snort!Version 2.3.0

You are not authorized to open this site!

Not for you!

Any questions?

Como sugerencia, este tipo de filtros de contenido es mejor realizarlo,con un proxy server como SQUID, el cual permite redirects mas complejos.

5. Para seguir pensando

Como vemos es muy extenso el tema y la cantidad de operaciones quepodemos realizar con Snort. Es importante leer y capacitarse en el uso deesta herramienta como alternativa a cualquier IDS, ya que cuenta con ca-racterısticas altamente profesionales.

Se destaca la capacidad que tiene para extender el codigo y agregarlenuevas funciones, como ası tambien quiza lo mas importante la granularidadque permite las reglas. Y no olvidarse de la posibilidad de armar un IPSusando FlexResp o Inline como vimos en los ejemplos.

5.1. Cambio de licencia para las reglas

Actualmente Snort (en realidad SourceFire) agrego un servicio con reglas“probadas” y certificadas, el cual no viene con licencia GPL, sino con unalicencia limitada para su comercializacion como producto o servicio.

5.2. Futuro: Detectando 0 days?

Por ahora los metodos para detectar “0 days”, son con detectores es-tadısticos, o analizando fallas en los protocolos.

6. Apendice A

6.1. Compilando Snort usando Debian 3.0 (stable)

Nos traemos las libs que necesitamos

18

$ apt-get install libpcap0$ apt-get install libpcre3-dev$ apt-get install libpcap-dev

Agregamos el grupo y usuario “snort”

$ groupadd snort$ useradd -g snort -s /bin/false -m -k /dev/null snort$ mkdir /var/log/snort$ chown snort.snort /var/log/snort/

Bajamos el soft

$ cd /usr/local/src$ wget http://www.snort.org/dl/current/snort-2.3.1.tar.gz$ tar -xvfz snort-2.3.1.tar.gz$ cd snort-2.3.1/

Soporte MySQL

$ apt-get install libmysqlclient10-dev$ ./configure --with-mysql

Soporte Inline

$ apt-get install libnet0-dev$ ./configure \

--enable-inline \--with-libipq-includes=/usr/include/libipq

Soporte FlexResp

$ apt-get install libnet0-dev$ ./configure \

--enable-flexresp \--with-libipq-includes=/usr/include/libipq

Y compilamos

$ make$ strip src/snort$ cp src/snort WHATEVER_YOU_WANT_DIR/

19

Referencias

[1] Snort home page: source code, manual and docs.http://www.snort.org/

[2] Insertion, Evasion, and Denial of Service: Eluding NID.http://www.snort.org/docs/idspaper

[3] Multi-architecture mutated NOP sled detector.http://cansecwest.com/spp fnord.c

[4] Securityfocus Archive IDS.http://www.securityfocus.com/infocus/ids

[5] K. K. Mookhey and Nilesh Burghate, March, 2004.Detection of SQL Injection and Cross-site Scripting Attacks.http://www.securityfocus.com/infocus/1768

[6] Bleeding Snort.http://www.bleedingsnort.com

[7] More signatures.http://snort.demarc.com/signatures

[8] MySQL Protocol 3.2xhttp://www.redferni.uklinux.net/mysql/MySQL-323.html

[9] MMAPed pcap.http://public.lanl.gov/cpw/

[10] Barnyard.http://www.snort.org/dl/barnyard/

[11] Libpcap, Tcpdump.http://www.tcpdump.org/

[12] Libipq, Netfilter.http://www.netfilter.org/

[13] The Libnet Packet Construction Library.http://www.packetfactory.net/libnet/

[14] Gabriel Verdejo AlvarezSistemas de deteccion de intrusos (IDS)http://tau.uab.es/ gaby/

[15] Rafeeq RehmanIntrusion Detection with Snort: Advanced IDS Techniques UsingSnort, Apache, MySQL, PHP, and ACID. ISBN 0-131-40733-3.

20

[16] Kerry J. Cox, Christopher GergManaging Security with Snort and IDS Tools.ISBN 0-596-00661-6.

[17] Chris AnleyHackproofing MySQLhttp://www.ngssoftware.com/papers/HackproofingMySQL.pdf

[18] William MetcalfSnort Inline.http://snort-inline.sourceforge.net/

[19] SPADE Statistical Packet Anomaly Detection Enginehttp://www.computersecurityonline.com/spade/

[20] Defeating Honeypots: Network Issues, Part 2.http://www.securityfocus.com/infocus/1805

[21] Data Mining in Intrusion Detection.http://www.sans.org/resources/idfaq/data mining.php

[22] Intrusion Detection FAQ.Can you explain traffic analysis and anomaly detection?http://www.sans.org/resources/idfaq/anomaly detection.php

Licencia

Copyright (c) 2005 Alejandro Gramajo, Baicom Networks

Este trabajo esta licenciado bajo‘‘Creative Commons Attribution-NonCommercial-ShareAlike License’’(Reconocimiento-NoComercial-CompartirIgual).

Para ver una copia de esta licencia, visitarhttp://creativecommons.org/licenses/by-nc-sa/2.5/deed.es o enviar una carta aCreative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Ideas para la conferencia

La idea es disertar en profundidad sobre los temas mas avanzados deeste paper:

Una introduccion al tema, junto con un review de posibilidades y pro-blemas de usar Snort.

La minimizacion de falsos positivos, escribiendo reglas mas detalladas encuanto al bug/exploit, error o protocolo, y optimizacion.

Transformar al IDS en un IPS, bloqueando contenido y manipulandopaquetes.

21

Contacto

Alejandro GramajoEmail Principal: agramajo at baicom.comEmail Alternativo: agramajo at gmail.comPGP: http://people.baicom.com/∼agramajo/pgp.asc

22