Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Sistemas de Detección de Intrusiones
Amor y odio (I de III)
***************************************************************************************
- Sistemas de Detección de Intrusiones. Amor y Odio (I de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (II de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (III de III)
***************************************************************************************
Los IDS suenan genial en su concepto: "Aquí se acabaron los cachondeos, soy yo el puto amo, y nada de intrusioncitas en esta red", pero nunca me han llegado a convencer lo suficiente y siempre les encuentro mil peros. La idea de un IDS es detectar una intrusión en un sistema y existen múltiples vertientes y formas de clasificar los IDS en función de cuándo, cómo y de qué manera realizan este trabajo.
Los IDS se pueden clasificar en función del cuando actuan en IDS reactivos o IDS preventivos, evolucionados a IPS (Intrusion Prevention System). En función de dónde toman la información en IDS de Host (HIDS) o de red (NIDS). En función de la forma en que analizan el tráfico en IDS basados en firmas o IDS basados en profiles. Toda una fiesta de colores y sabores. Mi opinión respecto a estos sistemas es bastante mala, aunque reconozco que sí hay algunas cosas maravillosas con ellos. Tras asistir a varias charlas de IDS recientemente he visto cosas que no me convencen y cosas que me gustan. Ahí van algunas de ellas.
IDS Reactivos
Los IDS reactivos son aquellos que detectan una intrusión o un intento de intrusión después de que este se haya producido. Es decir, detectan el ataque pero no lo evitan. Sin embargo, a pesar de no evitarlo teóricamente, pueden configurarse reglas de tratamiento de la intrusión que mitiguen los impactos, ya sea bloqueando una IP en el firewall, desactivando una boca en un switch o apagando un servicio. Debido a esto, muchos de ellos pasan a llamarse IPS en lugar de IDS. Estos IDS pueden trabajar de múltiples formas. Unos lo hacen analizando tráfico de red, otros mirando registros en los logs y eventos registrados y los, por supuesto, coordinados, que correlacionan eventos en todos los puntos de la red para determinar si se está produciendo una intrusión.
IDS de red reactivos en base firmas de red
Mis primeras quejas con los IDS van dirigidas a los IDS que inspeccionan tráfico de red, los NIDS. Para poder realizar esta inspección es necesario que el tráfico pase por el equipo, así que lo primero que hay que habilitar son puertos mirror o de monitorización en los switches. Este análisis implica el uso de sondas de red que puedan repartirse el trabajo de analizar todo el tráfico que circula por una red. El ejemplo por excelencia de este tipo de IDS es Snort o las soluciones Proventia de IBM que vienen de la compra de ISS (Internet Security Systems) con su Real Secure que previamente había comprado a BlackICE.
El análisis del tráfico puede realizarse en base al contenido de la red, y por lo tanto usando firmas o mirando solamente el uso que se hace de la misma, para ver si es “normal” o “anormal”.
Si el análisis es en base a firmas entonces todo el tráfico debe poder ser interpretado, así que nada de cifrado, con lo que IPSec, SSL, PPP, etc… quedan fuera de las opciones. Sí, supongo que podremos justificar la existencia de los NIDS analizando la red en puntos clave en los que no haya cifrado o dónde no sea necesario, pero no implantar IPSec por usar un IDS para mí no es una buena opción.
IDS de red reactivos en base a comportamientos
La segunda queja viene con respecto a los NIDS basados en comportamientos “normales” y “anormales”. Estos son los basados en profiling. Es decir, se analiza durante un tiempo la red y se estudia el tráfico “normal” de la misma, a partir de ahí se marcan unas alertas en función del tráfico generado, del tráfico recibido, de la promiscuidad de un equipo o del número de conexiones abiertas por enlace entre equipos, marcando unos límites máximo y mínimo.
En el 11th ICCS 2008 del IEEE he asistido a la presentación de un trabajo basado en un NIDS basado en profiling del número de conexiones abiertas por cada equipo. En el trabajo decían que detectaban casi el 92 % de las intrusiones de red. Yo me he quedado un poco flipado, pero luego lo he entendido. En su estudio han utilizado la batería de pruebas de DARPA off-line Intrusion Detection System Evaluation 1999. Es decir, un conjunto de resultados grabados y utlizados como evaluación de IDSs.
Pero… ¿es fiable esta batería de pruebas para los entornos de hoy en día? Las redes de 1999 no se parecen en nada a las actuales, los objetivos por los que se realizaban los ataques en 1999 no son los mismos objetivos que se persiguen hoy en día, los sistemas operativos y las formas de atacarlos han cambiado. Bajo mi punto de vista, está bien, como forma de “jugar” pero no me acaba de convencer. En el trabajo se utiliza, como factor de descubrimiento de intrusiones el número de conexiones abiertas por un equipo. Claro, eso, cuando se hace un ataque de fuerza bruta canta a la primera, pero cuando es una conexión reversa desde un troyano o un exploit con una shellcode, el número de conexiones no es que sea muy alto.
No es esta mi única queja con los NIDS basados en profiling. El uso de las redes cambia, luego el profile normal debe cambiar, y además, el comportamiento normal de la red se puede ir al carajo si ese día es la final de Operación Triunfo o si España gana la Eurocopa. Es decir, el uso de la red puede verse afectado por acontecimientos externos incontrolables y si el sistema no es “elástico” pueden saltar todas las alarmas, mientras que si es muy “elástico” no detecta ningún comportamiento anómalo.
IDS de red reactivos en base firmas en logs
Otro tipo de IDS reactivo es el que se basa en la recogida de logs. Este tipo de IDS captura los logs de los elementos de red, los servicios y los equipos e intenta correlacionar sucesos para detectar una intrusión. Estos sí que me molan. No sólo no tienes que cepillarte el cifrado de tu red sino que además puedes detectar violaciones de la política de seguridad de la compañía como envío de correos con adjuntos no permitidos por parte de usuarios, o incluso, de grabación de dvds con ficheros Excel cogido de un servidor de datos. Sí, cualquier cosa que genere un log puede incorporarse en estos IDS.
De estos hay algunos muy sencillos como los simples analizadores de logs de Apache para detectar un ataque a un servidor Web o los más complejos y configurables para correlacionar distintos logs como los famosos Bitácora de S21Sec y OSSIM o, la implementación de reglas a tu gusto con el System Center Operations Manager o el GFI Security Event Log Monitor. Con todos ellos, configurando las reglas adecuadas y recogiendo los sucesos de los puntos clave se pueden detectar muchas intrusiones o intentos de ellas.
¿El problema de estos IDS? Pues la definición de las reglas, por supuesto. Ajustar uno de estos sistemas a tu entorno puede ser bastante complicado y más si tus herramientas no están preparadas. En la Navarparty 6, Ivan González dio una charla sobre "Design for Operations" en la que explicaba que las herramientas creadas por los desarrolladores deben estar preparadas para ser gestionadas por los “rudos hombretones y mujeronas” de sistemas y para ello las alertas tiene que estar preparadas para acabar en el visor de sucesos, en logs centralizados o en el System Center Operations Manager de turno. Por desgracia esto no es así y son los rudos hombretones y mujeronas de sistemas los que tienen que ir a cada una de las herramientas que generan logs, apretarle la tripa para que saque la lengua, ver como se genera el puñetero registro, configurarlo lo máximo que se pueda y luego ver la forma de integrar ese log dentro del sistema centralizado. Vamos, todo diversión.
Saludos Malignos!
***************************************************************************************
- Sistemas de Detección de Intrusiones. Amor y Odio (I de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (II de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (III de III)
***************************************************************************************
- Sistemas de Detección de Intrusiones. Amor y Odio (I de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (II de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (III de III)
***************************************************************************************
Los IDS suenan genial en su concepto: "Aquí se acabaron los cachondeos, soy yo el puto amo, y nada de intrusioncitas en esta red", pero nunca me han llegado a convencer lo suficiente y siempre les encuentro mil peros. La idea de un IDS es detectar una intrusión en un sistema y existen múltiples vertientes y formas de clasificar los IDS en función de cuándo, cómo y de qué manera realizan este trabajo.
Los IDS se pueden clasificar en función del cuando actuan en IDS reactivos o IDS preventivos, evolucionados a IPS (Intrusion Prevention System). En función de dónde toman la información en IDS de Host (HIDS) o de red (NIDS). En función de la forma en que analizan el tráfico en IDS basados en firmas o IDS basados en profiles. Toda una fiesta de colores y sabores. Mi opinión respecto a estos sistemas es bastante mala, aunque reconozco que sí hay algunas cosas maravillosas con ellos. Tras asistir a varias charlas de IDS recientemente he visto cosas que no me convencen y cosas que me gustan. Ahí van algunas de ellas.
IDS Reactivos
Los IDS reactivos son aquellos que detectan una intrusión o un intento de intrusión después de que este se haya producido. Es decir, detectan el ataque pero no lo evitan. Sin embargo, a pesar de no evitarlo teóricamente, pueden configurarse reglas de tratamiento de la intrusión que mitiguen los impactos, ya sea bloqueando una IP en el firewall, desactivando una boca en un switch o apagando un servicio. Debido a esto, muchos de ellos pasan a llamarse IPS en lugar de IDS. Estos IDS pueden trabajar de múltiples formas. Unos lo hacen analizando tráfico de red, otros mirando registros en los logs y eventos registrados y los, por supuesto, coordinados, que correlacionan eventos en todos los puntos de la red para determinar si se está produciendo una intrusión.
IDS de red reactivos en base firmas de red
Mis primeras quejas con los IDS van dirigidas a los IDS que inspeccionan tráfico de red, los NIDS. Para poder realizar esta inspección es necesario que el tráfico pase por el equipo, así que lo primero que hay que habilitar son puertos mirror o de monitorización en los switches. Este análisis implica el uso de sondas de red que puedan repartirse el trabajo de analizar todo el tráfico que circula por una red. El ejemplo por excelencia de este tipo de IDS es Snort o las soluciones Proventia de IBM que vienen de la compra de ISS (Internet Security Systems) con su Real Secure que previamente había comprado a BlackICE.
El análisis del tráfico puede realizarse en base al contenido de la red, y por lo tanto usando firmas o mirando solamente el uso que se hace de la misma, para ver si es “normal” o “anormal”.
Si el análisis es en base a firmas entonces todo el tráfico debe poder ser interpretado, así que nada de cifrado, con lo que IPSec, SSL, PPP, etc… quedan fuera de las opciones. Sí, supongo que podremos justificar la existencia de los NIDS analizando la red en puntos clave en los que no haya cifrado o dónde no sea necesario, pero no implantar IPSec por usar un IDS para mí no es una buena opción.
IDS de red reactivos en base a comportamientos
La segunda queja viene con respecto a los NIDS basados en comportamientos “normales” y “anormales”. Estos son los basados en profiling. Es decir, se analiza durante un tiempo la red y se estudia el tráfico “normal” de la misma, a partir de ahí se marcan unas alertas en función del tráfico generado, del tráfico recibido, de la promiscuidad de un equipo o del número de conexiones abiertas por enlace entre equipos, marcando unos límites máximo y mínimo.
En el 11th ICCS 2008 del IEEE he asistido a la presentación de un trabajo basado en un NIDS basado en profiling del número de conexiones abiertas por cada equipo. En el trabajo decían que detectaban casi el 92 % de las intrusiones de red. Yo me he quedado un poco flipado, pero luego lo he entendido. En su estudio han utilizado la batería de pruebas de DARPA off-line Intrusion Detection System Evaluation 1999. Es decir, un conjunto de resultados grabados y utlizados como evaluación de IDSs.
Pero… ¿es fiable esta batería de pruebas para los entornos de hoy en día? Las redes de 1999 no se parecen en nada a las actuales, los objetivos por los que se realizaban los ataques en 1999 no son los mismos objetivos que se persiguen hoy en día, los sistemas operativos y las formas de atacarlos han cambiado. Bajo mi punto de vista, está bien, como forma de “jugar” pero no me acaba de convencer. En el trabajo se utiliza, como factor de descubrimiento de intrusiones el número de conexiones abiertas por un equipo. Claro, eso, cuando se hace un ataque de fuerza bruta canta a la primera, pero cuando es una conexión reversa desde un troyano o un exploit con una shellcode, el número de conexiones no es que sea muy alto.
No es esta mi única queja con los NIDS basados en profiling. El uso de las redes cambia, luego el profile normal debe cambiar, y además, el comportamiento normal de la red se puede ir al carajo si ese día es la final de Operación Triunfo o si España gana la Eurocopa. Es decir, el uso de la red puede verse afectado por acontecimientos externos incontrolables y si el sistema no es “elástico” pueden saltar todas las alarmas, mientras que si es muy “elástico” no detecta ningún comportamiento anómalo.
IDS de red reactivos en base firmas en logs
Otro tipo de IDS reactivo es el que se basa en la recogida de logs. Este tipo de IDS captura los logs de los elementos de red, los servicios y los equipos e intenta correlacionar sucesos para detectar una intrusión. Estos sí que me molan. No sólo no tienes que cepillarte el cifrado de tu red sino que además puedes detectar violaciones de la política de seguridad de la compañía como envío de correos con adjuntos no permitidos por parte de usuarios, o incluso, de grabación de dvds con ficheros Excel cogido de un servidor de datos. Sí, cualquier cosa que genere un log puede incorporarse en estos IDS.
De estos hay algunos muy sencillos como los simples analizadores de logs de Apache para detectar un ataque a un servidor Web o los más complejos y configurables para correlacionar distintos logs como los famosos Bitácora de S21Sec y OSSIM o, la implementación de reglas a tu gusto con el System Center Operations Manager o el GFI Security Event Log Monitor. Con todos ellos, configurando las reglas adecuadas y recogiendo los sucesos de los puntos clave se pueden detectar muchas intrusiones o intentos de ellas.
¿El problema de estos IDS? Pues la definición de las reglas, por supuesto. Ajustar uno de estos sistemas a tu entorno puede ser bastante complicado y más si tus herramientas no están preparadas. En la Navarparty 6, Ivan González dio una charla sobre "Design for Operations" en la que explicaba que las herramientas creadas por los desarrolladores deben estar preparadas para ser gestionadas por los “rudos hombretones y mujeronas” de sistemas y para ello las alertas tiene que estar preparadas para acabar en el visor de sucesos, en logs centralizados o en el System Center Operations Manager de turno. Por desgracia esto no es así y son los rudos hombretones y mujeronas de sistemas los que tienen que ir a cada una de las herramientas que generan logs, apretarle la tripa para que saque la lengua, ver como se genera el puñetero registro, configurarlo lo máximo que se pueda y luego ver la forma de integrar ese log dentro del sistema centralizado. Vamos, todo diversión.
Saludos Malignos!
***************************************************************************************
- Sistemas de Detección de Intrusiones. Amor y Odio (I de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (II de III)
- Sistemas de Detección de Intrusiones. Amor y Odio (III de III)
***************************************************************************************
6 comentarios:
De hecho OSSIM no es solo un IDS o correlador propiamente dicho. También hace de monitor de red, escaner de vulnerabilidades (usa nessus), tiene sistemas de ticketing para interactuar con el cliente....
OSSIM realmente es una bestia que hay que saber controlar. Aquí en Expo estuvimos trabajando con OSSIM y realmente daba muy buenos resultados. Trabaja con Snort, Ntop, Nessus, OSSEC, etc y la verdad es que cuando se configura bien realmente es útil, como ha dicho anónimo tiene un sistema de ticketing y de reports bastante bueno.
Yo también soy un poco escéptico con los IDS aunque algunos implementan cosas muy potentes y curiosas
Lo difícil es crear reglas equilibradas, como dice Chema o te pasas o no llegas, como en casi todo lo nuestro la búsqueda del plug and forget es una pérdida de tiempo, hay que supervisarlo, revisarlo y fusionar diferentes técnicas para adaptarse a los nuevos ataques y seguro que un ataque usando la última técnica te acabará afectando igual... siempre hay una primera vez...
saludos.
Además del tema de las reglas y el aprendizaje, en mi opinión, uno de los problemas reales es el producido por la segmentación de red: el dispositivo (si no está basado en host) debe ser capaz de ver *todo* el tráfico.
Esto obliga a tener TAPs o puertos de mirroring. Ambas cosas difíciles de mantener en entornos de alta disponibilidad y alto rendimiento.
Saludos normales,
gato
Mi propuesta es tener un IDS basado en firmas para entrada y basado en correlación y estadísticas de tráfico para salida.
Interesante articulo como siempre :).
Cuando he tenido que trabajar con sistemas IDS me he encontrado con el dilema que nos propones :P. Normalmente suelo realizar este ultimo a base de evaluar los logs. Ya que depende de que sistemas el análisis puede dar una bajada de rendimiento enorme si hablamos de reglas realtime. Como por ejemplo ModSecurity. En este caso hay que definir un conjunto de reglas básicas que deben ser mantenidas según va creciendo la aplicación Web (obviamente podemos modular la infraestructura creando un proxy inverso para gestionar las peticiones). El trabajo es algo más tedioso pero a nivel Web da buen resultado. Para esto recomiendo Remo :) es un editor de reglas para mod_security que ayuda bastante a “asegurar” una aplicación Web. Por curiosidad estoy trabajando en un “modulo similar” en LigHTTPD. Gracias a mod_magnet y Lua :) y siendo “ágiles” podemos crear un escenario bastante seguro y de rápida respuesta. También para los que les interese el tema de monitorizar servicios MySQL pueden echarle un ojo a GreenSQL o dedicarle un rato a MySQL Proxy con unas buenas reglas en Lua :P.
saludos benignos :P
Publicar un comentario