PDF de programación - Introducción a conceptos de IDS y técnicas avanzadas con Snort

Introducción a conceptos de IDS
y técnicas avanzadas con Snort

Alejandro Gramajo
Baicom Networks

23 de junio de 2005

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

Índice

1. Introducción a IDS

1.1. Tipos de IDS . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Técnicas de detección . . . . . . . . . . . . . . . . . . . . . .
1.3. Problemas con los IDS . . . . . . . . . . . . . . . . . . . . . .
1.4. Resumiendo . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Snort

2.1. Open source . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Add-ons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Mejorando la performance . . . . . . . . . . . . . . . . . . . .
2.3.1. MMAPed pcap . . . . . . . . . . . . . . . . . . . . . .
2.3.2. Barnyard . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Software contrib . . . . . . . . . . . . . . . . . . . . . . . . .

3. Creando nuevas reglas

3.1. Examinando tráfico . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Event thresholding . . . . . . . . . . . . . . . . . . . . . . . .

4. Modificando y rechazando paquetes

4.1. Ejemplo básico de Snort INLINE, para reescribir el payload .
4.2. Varios ejemplos mas avanzados . . . . . . . . . . . . . . . . .
4.2.1. Cambiando consultas MySQL . . . . . . . . . . . . . .
4.2.2. Rechazando consultas MySQL . . . . . . . . . . . . .
4.2.3. Evitando un buffer overflow . . . . . . . . . . . . . . .
4.2.4. Detectando un SQL injection . . . . . . . . . . . . . .

1
1
2
2
3

3
3
5
5
5
6
6

7
10
10

10
11
12
12
13
15
16

1

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

5. Para seguir pensando

5.1. Cambio de licencia para las reglas
. . . . . . . . . . . . . . .
5.2. Futuro: Detectando 0 days? . . . . . . . . . . . . . . . . . . .

6. Apéndice A

6.1. Compilando Snort usando Debian 3.0 (stable) . . . . . . . . .

16
16

17
17
17

17
17

1.

Introducción a IDS

La detección de intrusos es el proceso de monitorear computadoras o
redes, para detectar entradas no autorizadas, actividad o modificación de
archivos.

Un IDS puede también ser usado para monitorear trafico, por ej. así pue-
de detectar si un sistema esta siendo un objetivo de un ataque de red como
un DoS (denial of service).

1.1. Tipos de IDS

Existen dos grupos importantes en los tipos de IDS:

Host IDS
Orientados a examinar los datos en computadoras individuales.

Network IDS
Examinan el intercambio de datos entre computadoras. Esos paquetes
son examinados y a veces comparados contra datos empíricos para
verificar su naturaleza: mala o buena.
Como se tiende a examinar varios puntos de la red es común encon-
trarlos de forma distribuida en la red.

Hybrid IDS
Una mezcla de los dos tipos anteriores.

1.2. Técnicas de detección

Existen varios técnicas y tipos de detección para los IDS, estos son los

mas usados y destacados:

Anomalía (anomaly)
Sirve para descubrir patrones anómalos comparándolos con los consi-
derados normales.

2

Especial interés para aplicación de algoritmos genéticos, redes neuro-
nales y estadística (data mining en general [1])
Se puede separar también en “Protocol Modelling”, que buscan ano-
malías en los protocolos o configuraciones poco comunes.

Firma (signature)
Comparación de firmas almacenadas contra una porción de un paquete
de red.
Reducción del análisis, subconjunto del total.

Objetivo (target)
Generalmente a nivel de sistema operativo, buscan modificaciones en
archivos específicos, controles de accesos, uso de recursos. (HIDS en su
mayoria)

1.3. Problemas con los IDS

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

tantes:

Falsos positivos
Un falso positivo es un termino aplicado a un fallo de detección en
un sistema de alertas. Sucede cuando se detecta la presencia de una
intrusión en el sistema que realmente no existe.
Principalmente se pueden dividir en 5 categorías (existen mas):

• Reactionary traffic alarms

Se detecta un comportamiento sospechoso como consecuencia de
trafico generado anteriormente (generalmente no malicioso). Ej.
ICMP network unreachable.

• Equipment-related alarms

Se detectan paquetes dentro del trafico de la red que identifica
como no “usuales”. Ej. balanceadores de carga.

• Protocol violations

Se producen por software mal programado (bugs) o que imple-
mentan de forma incorrecta o anticuada algunas partes de los
protocolos de Internet.
• Non malicious alarms

Alarmas 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 positives

Toda alarma que no se encuentre en las anteriores categorías.

3

Falsos negativos
Un falso negativo es un termino que hace referencia a un fallo en el
sistema de alerta.
Sucede cuando una intrusión 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 útil y confiable debe producir los

mínimos falsos positivos posibles y “ningún” falso negativo.

2. Snort

2.1. Open source

Snort es rápido, flexible y un NIDS open-source. Empezó a fines de 1998

como un sniffer. Con licencia GPL version 2. 1

Por default utiliza técnicas de detección de firmas y anomalías no es-

tadística.

Puede correr en varios modos de ejecución:

Sniffer (similar al tcpdump [11])

Packet Logger

NIDS

IPS con FlexResp o Inline
Requiere 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 detección (Detection Engine)
Comparación 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 --> logging

decoder

pcap / ipq

engine

alert

|
v

|
v

drop

output plugins

Estos componentes trabajan juntos para detectar ataques particulares y

generar una salida en algún formato requerido.

El “decodificador de paquete”, toma los paquetes de diferentes tipos de
interfaces de red, y prepara el paquete para ser “preprocesado” o enviado al
motor de detección.

Los “preprocesadores” son componentes o plugins que pueden ser usados
con Snort para arreglar, rearmar o modificar datos, antes que el “motor de
detección” haga alguna operación para encontrar si el paquete esta siendo
enviado por un intruso.

Algunos preprocesadores realizan detección buscando anomalías en los
headers de los paquetes y generando alertas. Son muy importantes porque
preparan los datos para ser analizados contra reglas en el motor de detección.
El “motor de detección” es la parte mas importante de Snort, es res-
ponsable de detectar si alguna actividad de intrusión existe en un paquete.
El motor utiliza las reglas para este propósito. Las reglas (o cadenas) son
macheadas contra todos los paquetes. Si un paquete machea una regla, la
acción descripta en la misma es tomada.

Dependiendo que detecte el motor dentro de un paquete, el “logging y
sistema de alerta”, se encarga de loguear o generar una alerta. Los logs son
almacenados en archivos de texto, archivos con formato “tcpdump” u otro
formato.

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

Snort nos permite extenderlo y agregarle nuevas funciones. Posee mucha
facilidad para programar nuevos add-ons, ya sean preprocesadores o output
plugins.

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 están 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 tráfico en tiempo real, necesitamos mas recursos de
de “cpu” y “memoria”. Obviamente depende como almacenamos las alertas
la entrada y salida “io” de “disco” también puede ser un cuello de botella.
La creación de reglas óptimas es importante, para no demorar al motor
de detección. En la sección 3 “Creando nuevas reglas” se dan tips para
aumentar la eficacia y velocidad de las reglas.

Acá hay un detalle de dos formas de aumentar la performance de Snort.

2.3.1. MMAPed pcap

Es una reimplementación de la libpcap [9], agregándole un cambio, en
vez de copiar los paquetes de la “kernel memory” a‘ “userland memory” la
libpcap puede encolar los paquetes en un “shared buffer” que el Snort puede
leer directamente.

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

El buffer en ethernet puede tener hasta 52Mbytes.

6

2.3.2. Barnyard

El método de output plugin mas rápido 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 forma

detallada.

Para recolectar esta información, se puede utilizar el Barnyard [10], es
daemon que se encarga de tomar la información y enviarla a una base de
datos, archivo, etc.

2.4. Software contrib

Existen varios software para administrar los IDS, mi