PDF de programación - Nivel de Inmadurez de los Sistemas de Detección de Intrusiones de Red (NIDS)

Nivel de Inmadurez de los Sistemas de Detección de Intrusiones de

Red (NIDS).

Nivel de inmadurez de los IDS.

Por: Alejandro Corletti

[email protected], [email protected]

1. Presentación:
El presente trabajo, surge dentro de la Gerencia de Seguridad de Redes y Servicios de Telefónica
Móviles en España, a través de una iniciativa promovida y dirigida a desde fines del 2001 por
Miguel Cros (y en la actualidad por José Luis GilPérez) e implementada por un equipo de gente que
no puedo dejar de mencionar por su excelente nivel de conocimientos técnicos, los cuales muy
pocas veces en mi corta experiencia informática he encontrado, y del cual tengo el gusto de formar
parte. Se trata de Raúl Bretón, Ignacio Bravo, Yago Molina y Alejandro Jareño.
La idea es la de incluir estas nuevas tecnologías en la red de esta importante empresa, para lo cual,
no sólo se analizaron las opciones disponibles, sino que para que el tema no fuera abordado
ligeramente, se encargó un análisis (Benchmark) de los diferentes productos existentes en el
mercado, para determinar cuáles de ellos se ajustaban mejor a las características de esta red.
La evaluación de los productos (aún no finalizada), incluyó las siguientes tareas:

Investigación de mercado.

a.
b. Reunión de información de los productos.
c. Determinación de las características que se consideran más importantes en un IDS para esta

red.

d. Selección preliminar de un número de ellos para investigar en detalle (en la etapa final,

quedaron sólo tres productos que se creyó podían ser los más adecuados a esta empresa).

e. Comparativa: Sobre esta actividad es donde se hizo mayor hincapié y se dedicó más

tiempo, subdividiéndola en tres partes:
1) Respuesta ante ataques conocidos.
2) Respuesta ante anomalías a lo determinado en las RFC correspondientes a los protocolos

de la familia TCP/IP.
3) Aspectos generales.

f. Análisis de vulnerabilidades en NIDS.

Al ir avanzando en la evaluación de estos productos (en particular las tareas del punto e.)
comienzan a aparecer una serie de detalles que dan origen a este trabajo que creo demuestran que
aún no se ha alcanzado un nivel de madurez adecuado para confiar plenamente en la
información que los IDS entregan y que presentan a su vez un gran número de vulnerabilidades.
Las conclusiones finales tratan de marcar los detalles más importantes y lo que creo que puede ser
un curso de acción orientado a continuar mejorando estos nuevos dispositivos de seguridad.
Por último, a lo largo de este texto no se hará mención al nombre de los productos, empresa
propietaria o de distribución (comercial o gratuita), pues no se trata aquí de promover un NIDS en
particular, sino de plantear lo que se aprecia como estado actual de esta tecnología,
independientemente de sus fabricantes. En los casos en que se presente alguna comparativa, será

Alejandro Corletti

Página 1 de 28

como producto A, B o C, y pido disculpas por anticipado, si en algún momento se deja translucir
las características de alguno de ellos.

Nivel de inmadurez de los IDS.

2. Marco de trabajo:

Se armó una pequeña red de laboratorio y a su vez se comenzó también con una etapa de prueba de
los distintos productos en varias zonas de la red en producción de Telefónica Móviles, tratando de
trabajar con plataformas de hardware similares.
Se estudió los distintos SPLITTER del mercado, encontrando en ellos varias diferencias en sus
prestaciones de trabajo en 100 Mbps, en particular cuando se trataba de tráfico full dúplex.
Los productos que lo permitían fueron comprobados sobre sistemas operativos Linux, Solaris y
Windows 2000.
En todos los productos se emplearon los conjuntos de reglas (o firmas) que proporcionaban la
máxima cobertura, sin personalizar ninguna de ellas, para obtener el mismo línea base o punto de
partida con todos.
Si bien es un factor importante, no se pudo evaluar la pérdida de paquetes al trabajar a 100 Mbps,
pero sí se tuvo en cuenta el empleo de CPU y memoria de los distintos productos.
Se está trabajando en la actualidad sobre una investigación de los distintos productos que permitan
correlar eventos, para poder determinar su eficiencia en la centralización de todos los dispositivos
de seguridad.

3. Breve descripción de la comparativa:
El presente trabajo se basó en tres aspectos para realizar la comparación:

a. Respuesta ante ataques conocidos.
b. Respuesta ante anomalías a lo determinado en las RFCs correspondientes a los protocolos de

la familia TCP/IP.
Comparativa de aspectos generales.

c.

Los cuales se desarrollan a continuación.

a. Respuesta ante ataques conocidos:

Esta tarea se divide en dos partes:
- Aprovechamiento de la información recolectada a través de la actividad generada por

dos empresas que desarrollaron haking ético.

- Generación de tráfico a través de distintas herramientas conocidas (Internet Security
Scanner, Retina y Nessus), programas de generación de ataques realizados en PERL, y
herramientas de scan de puertos y otras vulnerabilidades.

b. Respuesta ante anomalías a lo determinado en las RFC correspondientes a los

protocolos de la familia TCP/IP:

Alejandro Corletti

Página 2 de 28

Nivel de inmadurez de los IDS.

Se subdividió este análisis por protocolos, empleando desarrollos propios que generaban
tráfico los cuales, pudiendo o no ser ataques conocidos, no cumplían lo determinado por las
RFCs correspondientes a esos protocolos. Los protocolos investigados fueron:
1) ETHERNET (encabezado MAC)(IEEE: 802.3).

Se generaron 2 patrones de tráfico: arp1.cap de tramas y Ethernet1.cap de 170
tramas con las siguientes características:
Incoherencias de solicitudes y réplicas ARP.
Tamaños de trama incorrectos.
Campo Length o Ethertype modificados.
Excesivos Broadcast.
Falsos Multicast.
Misma dirección fuente y destino.
Direcciones globalmente administradas erróneas.
Errores de CRC.
Ataques ARP.
Modificación de tablas ARP.

2) BOOTP (RFC 1541, 1531, 1533 y 1534): Se trabajó directamante con DHCP, estas
RFCs son muy claras en las combinaciones permitidas acorde a qué tipo de mensaje
DHCP se trate, cualquier otra combinación no contemplada no debería generarse.
Se generó 1 patrón de tráfico: dhcp1.cap de 230 tramas con las siguientes
características:
Valores erróneos en los campos:
• OP (sólo permite 1 y 2).
• HTYPE (sólo permite del 1 al 7).
• HLEN: Especifica el tipo y longitud de la dirección de Hardware (Debería estar

de acuerdo con Ethernet tiene tipo 1 para 10 Mbps y longitud 6 octetos).

• HOPS: El cliente debería colocar (0), si es necesario pasar a través de distintos

router , el servidor BOOTP o DHCP lo incrementará.

• TRANSACTION ID: Dependerá de las solicitudes y respuestas, debe contener un

número entero que permite llevar el control entre las solicitudes y respuestas.
• SECONDS: Determina el tiempo transcurrido desde que se inició la operación.
• FLAGS: Identifica por medio del primer bit si es un Broadcast, los restantes

quince deben estar puestos a cero.

• CLIENT IP ADDRESS:
• YOUR IP ADDRESS:
• SERVER IP ADDRESS:
• ROUTER IP ADDRESS:
• CLIENT HARDWARE ADDRESS:
• SERVER HOST NAME:
• BOOT FILE NAME: Debería contener el tipo de arranque(Ej: UNIX)
• OPTIONS: Define máscara de subred, hora,etc.

Obtención de información, con R_ARP, BOOT_P o DHCP.
Saturación de direcciones en servidores.

3) IP (RFC 791):

Se generó 1 patrón de tráfico: ip1.cap de 261 tramas con las siguientes
características:
Errores de campo versión.

Alejandro Corletti

Página 3 de 28

Nivel de inmadurez de los IDS.

Falsas longitudes de cabecera.
Falsos valores de campo Protocol
Incoherencias de combinaciones de TOS y D, T , R.
Datagramas con ID number de igual valor.
Datagramas con igual IP fuente y destino (ataque LAND).
Direcciones IP reservadas.
Errores de fragmentación.
Falsoso valores de TTL
Errores de checksum.
Incoherencias y uso dudoso de campo opciones.
Rellenos no múltiplos de 4 Byte.
Análisis de comportamiento con ECN (bit 6 y 7 de TOS).
Detección de ACL empleando IP con encabezados erróneos.

4)

ICMP (RFC 792):
Se generó 1 patrón de tráfico: icmp1.cap de 578 tramas con las siguientes
características:
Valores no permitidos en campos:

•
•
•
•
•

ICMP Type.
ICMP Code (combinaciones de códigos no existentes para determinados tipos)
ICMP Time Stamp.
ICMP Information request.
ICMP Address mask request.

Mensaje de fragmentación requerida y no permitida de ICMP erróneos.
Mensajes de puerto, red o destino inalcanzable erróneos.
Empleos de traceroute.
Solicitudes de información ICMP.
Empleo de ICMP fragmentado.
ICMP con campos IP erróneos.
Mensajes TTL excedido erróneos.
Redirigido (Ataque Winfreeze).
Ping con datos.
Ping de longitud excesiva.
Combinaciones no permitidas de IP con ICMP.
Broadcast ICMP.

5) IGMP (RFC 1112, Apéndice 1):

Se generó 1 patrón de tráfico: igmp1.cap de 232 tramas con las siguientes
características:
Errores en campos:

• Versión: Sólo es válido 1 y 2.
• Tipo: Sólo dos tipos 1 (consulta) y 2 (Reporte). (El analizador de protocolos

reconoce hasta el valor 4, aún no sé qué RFC los amplía).
• No usado: sólo 0 en envío y debería ignorarse en reporte.
• Checksum: se refiere sólo a los 8 octetos del mensaje.
• Dirección de grupo: en envío debería ser 0, (abusos de grupo).

Captura y alteración de mensajes entre routers y switchs.
Direcciones multicast origen.
Combinaciones de direcciones MAC 01-00-5E-XX-XX-XX con falsas IP multicast.
Anuncios de host para incorporación a grupos multicast.

Alejandro Corletti

Página 4 de 28

Nivel de inmadurez de los IDS.

Mensajes de propagación de grupos.
Falsos sondeos multicast por parte de “Routers (falsos