9 IDS Sistemas Detección Intrusos

Módulo 9 Sistemas Detección Intrusos Diplomado Seguridad Informática

Detección/Prevención de Intrusos

Adolfo Grego, M.S, CISSP, NSA-IAM, OSWPDirector de Tecnología

Grupo RF

Profesor de Cátedra

ITESM-CEM

@adolfogrego

1


Un gramo de prevención equivale a un kilo de detección

2


Por qué Hablar de IDS?

• Tecnología emergente.

– Muy interesante y prometedora.

– Pero…

• Sobre explotada por los mercadólogos.

• Mantenerse informado es la mejor arma que

puede tener el analista de seguridad.

– Y sirve para mantener a los proveedores de

tecnología honestos!

3


Qué es una intrusión?• Difícil de definir.

– No hay un consenso.

– Esto es un gran problema:• Que tal si alguien efectúa un telnet al sistema de usted…

– Y trata de entrar al sistema como root ?

• Que ocurre con un escaneo de pings ?

• O un escaneo de algún producto comercial (ISS, Axent) ?

• O que tal si alguien prueba phf en su webserver ?

– Y que pasa sí phf funciona …

» Y el atacante se puede cargar al sistema.

4


Qué es un IDS ?

• El sistema ideal de detección de intrusos

notificará al administrador de sistema/red la

existencia de un ataque en proceso:

– Con 100% de exactitud.

– Inmediatamente (t<1min).

– Con un diagnóstico completo del ataque.

– Con recomendaciones de como bloquear el

ataque.

Lástima que no existe!

5


Objetivos: Exactitud

• 100% de exactitud y 0% de falsos positivos.

– Un falso positivo ocurre cuando el sistema genera una falsa alarma.

• O lo que es lo mismo el

síndrome de Juanito y el Lobo…

– Generar un 0% de

falsos positivos es trivial:

• No detectar nada.

– Generar un 0% de falsos

negativos es un objetivo adicional:

• No permitir que ningún ataque pase desapercibido.

6


Objetivos: Notificación Oportuna• Para ser exacto en el diagnóstico, el IDS puede

tener necesidad de “sentarse” sobre la

información hasta que todos los

detalles lleguen.

– Implicaciones directas acerca

de la definición de un IDS

de tiempo real.

– El IDS debe informar al usuario

acerca de la demora.

7


Objetivos: Notificación Oportuna

• El canal de notificación debe estar protegido.

– El atacante puede bloquear/inutilizar el

mecanismo de notificación.

– Un IDS que usa e-mail

como canal de notificación

va a tener problemas al

informar que el servidor

de correo esta siendo atacado.

8


Objetivos: Diagnóstico

• Idealmente el IDS categorizará / identificará el

ataque:

– Demasiado detalle para el administrador de red, al

tener que conocer íntimamente los ataques.

• Difícil de implementar:

– Especialmente cuando las cosas

“se ven raras” y no concuerdan

con ataques conocidos.

9


Objetivos: Recomendaciones

• El IDS perfecto no solo identificará un ataque,

también:

– Evalúa la vulnerabilidad del blanco.

– Si el blanco es vulnerable informará al

administrador.

– Si la vulnerabilidad tiene un “parche” conocido,

indicará al administrador como aplicarlo.

• Esto requiere cantidades tremendas de

conocimiento incorporado al sistema.

10


IDS: a Favor

• Un IDS razonablemente efectivo puede

identificar:

– Ataques internos.

– Ataques externos.

• Permite al administrador medir la cantidad de

ataques que está sufriendo la infraestructura.

• Puede funcionar como respaldo de seguridad

perimetral en caso de falla de otros sistemas

(firewall, filtros).

11


IDS: en Contra

• No tienen como característica principal

prevenir o bloquear ataques.

– No son un reemplazo de firewalls, routers, etc.

• Si el IDS detecta problemas en la red interna,

que debe hacer el administrador ?

– Por definición, ya es demasiado tarde.

12


Paradigmas para el Uso del IDS

• Detección de ataques.

• Detección de intrusiones.

13


Detección de Ataques

Router

Firewall

IDS

Server

Server

DMZ

Workstation

LaptopEl IDS detecta y cuenta los ataques contra la DMZ y el firewall.

14


Detección de Ataques

• Ubicar el IDS fuera del perímetro de seguridad

permite grabar registros al nivel de ataque.

– Se supone que si el perímetro está bien diseñado

los ataques no deben de afectarlo.

– Información útil a nivel directivo.

• Nos han intentado atacar 3,789,231 veces.

– Predicción: la detección de ataques generará

demasiado ruido y será ignorada rápidamente.

15


Detección de Intrusos

Router

Firewall

IDS

Server

Server

DMZ

Workstation

LaptopEl IDS detecta actividades ilegales dentro del perímetro protegido, ya sea de entrada o salida.

16


Detección de Intrusos

• Colocar el IDS dentro del perímetro, detectará

instancias claras de comportamiento

incorrecto.

– Backdoors.

– Ataques provenientes del Staff.

– Ataques que cruzan por el firewall.

• Cuando el IDS dispara una alarma, esta es de

máxima prioridad.

17


Detección de Ataques vs. Intrusos

• Idealmente efectuar las dos.

• Siendo realista, primero efectuar detección de

intrusos y después detección de ataques.

– O liberar primero la detección de ataque para

justificar la decisión ante la directiva, después

liberar la detección de intrusos.

• La pregunta importante tiene que ver con los

costos de staff para reaccionar ante alarmas

generadas por el sistema de detección de

ataques.

18


Paradigmas de Correlación

de Datos

• IDES

• Auditoría

• Inline

• Híbrido

19


IDES

• Basado en trabajo de Dorothy Denning (1986).

• Define el IDS en términos de:– Sujetos: Iniciadores de actividad.

– Objetos: Blancos de actividad.

– Perfiles: Caracterización de como los sujetos operan los objetos (ya

sea de forma estadística o por reconocimiento de patrones).

– Registros de Auditoría.

– Registros de Anomalías.

– Alarmas.

– IE DIDS, Stalker, Emerald

20


Hosto

Sniffer

Pre-procesamiento Analisis Estadistico

Reconocimiento dePatrones

Administrador de Alertas

Persistencia

Base deConocimientosGUI

Administrador deRespuestas

Diagrama de Bloques de un IDS Genérico


Auditoría• Post procesamiento de la información de

auditoría.

– Primero se genera la información de auditoría, después se

procesa.

– Procesamiento batch.

– Problema: De dónde tomar los datos.

Kernel yAplicaciones

DB deAuditoria Correlacion

efectuada por el IDS

Generacion deAlertas

22


Auditoría• El problema es determinar cuál es el mejor

punto de auditoría (medición).

• El libro naranja (Orange Book) del DOD incluye

23 puntos de recolección de datos, dentro del

Kernel de UNIX y aplicaciones.

• Open, R/W

• Creación de IPC

• Bad Login

• Process Fork

• Etc

23


Eventos de Red Auditables

• Login en horas atípicas.

• Reboots inexplicables.

• Cambios de tiempo inexplicables.

• Errores inusuales.

• Intentos fallidos de login.

• Login desde ubicaciones no cotidianas.

24


Inline

• Inline IDS procesa datos de auditoría

conforme estos se van generando.

– Descarta datos de auditoría que no son

considerados relevantes.

– La cantidad de correlación tiene a ser limitada.

Kernely Aplicaciones

CorrelacionEfectuada por el IDS

Base de DatosIncidentes

Reporte deAlertas

25


Auditoría vs. Inline

• Inline es mas rápido, pero solo provee de una vista

local, a menos que una gran cantidad de datos sea

enviada a tiempo real hacia una localidad central.

• El esquema de auditoría profundiza más, pero

requiere mantener grandes cantidades de datos.

• Los sistemas híbridos explotan ambos esquemas:

detección inline de eventos significativos que se

envían a una estación de auditoría.

26


Paradigmas de IDS

Según la Fuente de Datos

• Los datos provienen del Host.

• Los datos provienen de la Red.

27


IDS Basado en el Host

• Se obtienen los datos desde puntos ubicados

dentro del sistema operativo.

– Bitácoras de auditoría C2.

– Bitácoras de sistema.

– Bitácoras de aplicación.

• Los datos se recolectan de manera muy

compacta.

– Pero es dependiente del SO y de las aplicaciones.

28


IDS Basado en el Host:

Argumentos a Favor• La calidad de la información es muy alta.

– El software puede parametrizar que información

requiere obtener para análisis.

– Las bitácoras del Kernel “saben” quien es el

usuario que esta utilizando la sesión.

• La densidad de la información es muy alta.

– Con frecuencia las bitácoras contienen

información pre-procesada.

29



Argumentos en Contra

• La captura es normalmente específica del

sistema.

– Usualmente 1,2 o 3 plataformas son soportadas

(“puedes detectar intrusos siempre que sea sobre

Solaris o NT”).

• El desempeño es un punto de incertidumbre.

– Para bajar la demanda de procesamiento, los logs

se envían a algún sistema externo.

30




• Los hosts son normalmente el blanco de los

ataques.

– En caso haber sido comprometidos por un

atacante, las bitácoras pudieron ser

contaminadas.

– Los datos enviados al IDS pueden haber sufrido

alguna corrupción.

– Si el IDS corre sobre el host, pudo haber sido

contaminado.

31


IDS Basado en la Red

• Recolecta datos ya sea de la red o de un

hub/switch.

– Reensambla paquetes.

– Examina encabezados.

• Intenta inferir que es lo que está ocurriendo a

partir del contenido del tráfico de la red.

– Identidades inferidas a partir de las acciones.

32



Argumentos a Favor

• No tiene impacto en el desempeño.

• Más resistente a ataques externos.

• No tiene impacto de administración sobre

plataformas.

• Trabajo sin importar los SO’s presentes.

• Puede derivar información que las bitácoras

del host no contienen.

– Fragmentación, scanning, etc.

33




• Puede perder paquetes en redes saturadas.

• Puede fallar en el reensamble de paquetes.

• Puede no entender protocolos específicos de los SO’s

(i.e. SMB, appletalk, etc.)

• Puede no entender protocolos obsoletos de red (i.e.

cualquier cosa que no sea IP).

• No maneja datos encriptados.**

– Gran problema para aplicaciones de e-commerce,

transaccionales, etc.

34


Paradigmas de Operación

de los IDS

• Detección de anomalías o el enfoque de IA.

• Detección de mal uso o el enfoque fácil y

sencillo.

• Alarmas Contra Robo o la detección basada en

políticas.

• Honey Pots o el enfoque pásale a lo barrido.

• Híbridos

35


Detección de Anomalías

• Metas:

– Analizar la red o sistema e inferir que es normal.

– Aplicar medidas estadísticas o heurísticas a

eventos subsecuentes, para determinar si estos

concuerdan con el modelo o estadística de lo que

es”normal”.

– Si los eventos se encuentran fuera de una ventana

de probabilidad que determine lo que es normal,

se genera una alerta.

• Control configurable de falsos positivos.

36



• Implementaciones típicas para detección de

anomalías:

– Redes neuronales: reconocimiento de patrones

basado en probabilidades.

– Análisis estadístico: modelado del

comportamiento de los usuarios y búsqueda de

desviaciones de la norma.

– Análisis de cambio de estados: modelado del

estado del sistema y búsqueda de desviaciones de

la norma.37



Argumentos a Favor• Si funciona, puede detectar cualquier ataque posible.

• Si funciona, puede detectar ataques que no sean

conocidos.

– O variantes muy cercanas de ataques comunes.

• Lo mejor de todo, evita tener que mantenerse al día

en técnicas de ataque.

• La mayor parte de R&D de IDS es en esta tendencia.

38




• Las implementaciones actuales no funcionan

muy bien.

– Demasiados falsos positivos/negativos.

• No categorizan ataques de forma adecuada.

• “Algo se ve anormal”

• Requiere conocimiento experto para entender que

detono la alarma.

– Una red neuronal no puede explicar por que detono.

39



Ejemplos

• IDES/NIDES

• GrIDS

• Emerald

40


Detección de Mal Uso

• Metas

– Conocer que es lo que constituye un ataque.

– Detectarlo.

41



• Implementaciones típicas de mal uso:

– Network Grep: búsqueda de strings en conexiones

de red que puedan indicar que esta ocurriendo un

ataque.

– Reconocimiento de patrones: Codificar series de

estados que son intercambiados durante el

transcurso de un ataque.

• E.g. el cambio de dueño de /etc/passwd

• Open /etc/passwd para W

– Su forma de operar es muy similar a los antivirus.

42



Argumentos a Favor

• Fácil de implementar.

• Fácil de liberar.

• Fácil de actualizar.

• Fácil de entender.

• Pocos falsos positivos.

• Rápido.

43




• No puede detectar algo que sea desconocido.

• Necesidad constante de actualización.

• Mas fácil de engañar.

44



Ejemplos

• ISS Real Secure

• CISCO Netranger

• NAI CyberCop

• NFR Network Flight Recorder.

45


Alarmas Contra Robo

• Es un sistema de detección de mal uso que

tiene un blanco muy específico.

– Puede no interesarme alguien que escanea mi

firewall desde el exterior.

– Puede no interesarme alguien que escanee mi

mainframe desde el interior.

– La configuración hace que se detecte el mal uso a

partir de las políticas del site.

46


Alarmas Contra Robo

• Metas:

– Basadas en políticas, alertan al administrador

sobre violaciones a estas.

– Detectan eventos que no necesariamente son

violaciones de seguridad, pero si de políticas.

• Nuevos ruteadores.

• Nuevas subredes.

• Nuevos servidores.

47


Alarmas Contra Robo

• Alarmas Contra Robo triviales se puede

construir con TCPdump y PERL.

• La ubicación ideal de una alarma de robo es

en un punto donde se detonará cuando el

atacante haya efectuado una acción que

normalmente ejecutaría teniendo éxito en la

penetración.

– Añadir un userid.

– Borrar una bitácora.

48


Alarmas Contra Robo

• Muy apreciadas por los gerentes de redes:

– Aprovecha el conocimiento interno de la red local.

– Aprovecha el conocimiento sobre los trucos de

ataque más comunes.

49


Alarmas Contra Robo

Argumentos a Favor

• Confiable.

• Predecible.



• Generación casi nula de falsos positivos.

• Puede (a veces) detectar ataques

desconocidos.

50


Alarmas Contra Robo


• Dirigidos por políticas.

– Requiere conocimiento sobre la red.

– Requiere estabilidad dentro de la red.

• Requiere cuidado de no ser uno mismo el que

detone las alarmas.

51


Honey Pots

• Es un sistema que fue configurado para atraer

al atacante.

– ecom.tienda.com.mx

– transfers.banco.com.mx

– tacacs.isp.net.mx

52


Honey Pots

• Metas:

– Hacer que se vea atractivo al atacante.

– Hacer que se vea débil y fácil de atacar.

– Hacer que sea posible monitorear todo el tráfico

que entra y sale del sistema.

– Alertar al administrador cada vez que alguien

logra accesar al sistema.

53


Honey Pots

• Se pueden construir de forma muy sencilla

utilizando herramientas como:

– Tcpwrappers

– TCPdump

– PERL

• Un clásico es para leer es el paper de Bellovin:

“An evening with Berferd”. Vale la pena leerlo.

54


Honey Pots

Argumentos a Favor



• Confiable.

• Sin costo en el desempeño.

55


Honey Pots


• Asume que el atacante es tonto.

– Los atacantes no lo son.

• Más bien un sistema de juego para atacantes

menos sofisticados.

• No monitorea todo lo que pasa en la red.

– Honey pot en la red segura ?

– Honey por en DMZ?

56


IDS Híbridos

• La mayor parte de los IDS comerciales son de

este tipo.

• Su fortaleza es en la detección de anomalías.

– Estadística.

– Demasiados falsos positivos.

• Los híbridos ideales deben incorporar lógica

de los scaners de vulnerabilidades.

57


Engañando al IDS

• La calidad de la información disponible al IDS

es directamente proporcional a que tan

cercana a la fuente se efectúa su recolección.

– Difícil.

• Modificar SW de app. Para obtener bitácoras.

• Problemas de performance, al sacar datos del kernel.

• La recolección sobre la red es la más transparente y no

intrusiva en su operación.

58


Engañando al IDS

• Mientras más lejos de la fuente de datos se

encuentre el IDS, más vulnerable es a ataques

de spoofing.

– Ej:

• stty erase w

• rxwoxwoxwtkit

• stty erase ^?

59


Engañando al IDS

• Inundar redes con datos sirve para

enmascarar un ataque contra un IDS.

– De cualquier manera, esto es obvio de un ataque.

– Pocos sistemas pueden capturar a velocidades

mayores a 1000Mbs.

• Aunque obvio, si lo demás falla, el atacante

puede tratar de tirar al IDS.

60


Engañando al IDS

• No todos los IDS hacen reensamble completo

de TCP, son vulnerables a la manipulación del

Stream de datos de TCP.

– Estos eventos deben de ser tratados como

eventos interesantes.

– Verificar situaciones como que la red este

partiendo paquetes grandes en fragmentos de 40

bytes.

61


Engañando al IDS

• En resumen, el diseñador de IDS debe

balancear entre los siguientes escenarios:

– Almacenar demasiada información, siendo muy

intrusivo y lento.

– Recolectar rápidamente información de segunda

mano y posiblemente ser engañado o perder

algún detalle.

62


IDS y el WWW

• Candidatos ideales para proteger websites.

– Fallan en presencia de SSL.

– Usar IDS basados en el Host para web servers.

– Usar IDS basados en red para hacer un perfil de

sweeps y scans.

63


IDS y Firewalls

• Eventualmente se fusionaran en una sola

aplicación.

– Los firewalls pueden detonar eventos en presencia

de ciertos patrones de tráfico.

• Syn Floods.

• Scans.

• Se puede usar esto para construir alarmas contra robo.

64


IDS y VPN’s

• Los IDS basados en red tienen problemas en

presencia de VPN’s.

– Crypto.

– Sin embargo, pueden detectar errores de

sincronización.

– Las VPN’s proveen de buenas bitácoras de

operación a los administradores.

65


IDS y Switches

• Tendencia hacia ambientes switcheados.

– Es difícil para un IDS basado en red grabar el

tráfico de un red switcheada.

• Inundar al switch.

• Inundar al IDS.

– Las soluciones aún no están muy maduras.

• Lo mejor es conectar un hub frente a sistemas críticos

para monitorearlos.

66


IDS y Desempeño

• No operan bien en redes de alta velocidad.

– Muchos tiran paquetes arriba de 30Mb/s.

– TCPdump también!

– La única forma de verificar esto es un conteo de

paquetes enviados vs. lo que el IDS dice haber

registrado.

• Es importante verificar el desempeño de

cualquier IDS antes de liberarlo.

67


IDS• Son una herramienta que hay que saber

utilizar.

• No son un silver bullet.

• Requieren de mucho soporte por parte de los administradores.

• Requieren de conocimiento profundo del comportamiento de la red/sistemas.

• Es importante hacer una buena evaluación de la ubicación del IDS.

• Sigue siendo una tecnología joven.

68


Bibliografía

• Network Intrusion Detection, Northcutt et al,

New Riders.

• Intrusion Signatures and Analysis, Northcutt et

al, New Riders.

• Internet Security and Firewalls, Cheswick and

Bellovin, Addison Wesley.

• TCP/IP Illustrated Vol. 1, Stevens, Addison

Wesley.

69


Algunas Referencias Interesantes

• www.tcpdump.org

• www.snort.org

• www.securityfocus.com

• www.esecurityonline.com

• www.sans.org

• www.cert.org

70


Detección/Prevención de Intrusos

Adolfo Grego, M.S, CISSP, NSA-IAM, OSWPDirector de Tecnología

Grupo RF

Profesor de Cátedra

ITESM-CEM

@adolfogrego

71

9 IDS Sistemas Detección Intrusos

Documents

Transcript of 9 IDS Sistemas Detección Intrusos