***************************************************************************************
-
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 ReactivosLos 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 redMis 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 comportamientosLa 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 logsOtro 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)
***************************************************************************************
