Cuando las falsas alarmas son falsas
IDS (Intrusion-Detection Systems)
Si algo se puede decir con certeza de los sistemas de detección de intrusiones (IDS) basados en red es que con toda probabilidad consumirán todo el ancho de banda disponible. Que además detecten las intrusiones ya no es tan seguro. Estas son las principales conclusiones del análisis de ocho productos IDS realizado por la Network World Global Test Alliance de IDG Communications.
No es lo mismo el laboratorio que un entorno de producción real. Y así quedó de manifiesto en la evaluación realizada por IDG de siete productos IDS comerciales y uno de fuente abierta en un segmento plenamente operativo de un ISP: no sólo algunos IDS fallaron en repetidas ocasiones ante la avalancha de falsas alarmas que ellos mismos generaban, sino que incluso seguían reportando como tales los ataques reales. Por si fuera poco, algunas interfaces son tan complejas que hacían del análisis de estas falsas alarmas todo un reto. Por suerte, no todos los productos cometieron todos estos fallos.
Como ningún dispositivo se distinguió del resto, se optó por no nombrar ningún ganador. Los ocho productos probados –de Cisco, Intrusion, Lancope, Network Flight Recorder (NFR), Nokia (corriendo una versión OEM de Internet Security Systems RealSecure 6.5), OneSecure, Recourse Technologies y el paquete de fuente abierta Snort– exigen demasiado tiempo y experiencia a los usuarios. Esto no quiere decir que no ocupen un lugar destacado en las redes corporativas; de hecho, pueden ser herramientas valiosas para validar las tareas de otros dispositivos de seguridad. Pero instalar y poner en marcha las soluciones que conforman la actual generación de IDS requiere una sustancial inversión de tiempo si se quiere estar seguro de que se ocuparán del tráfico sospechoso, sin interferir en todo lo demás. Pero que no se recojan puntuaciones no quita valor al análisis: creemos que su lectura servirá a muchos usuarios a adentrarse en los principios de los intricados IDS.
Para la evaluación se utilizó como banco de pruebas la red de producción de Opus One, ISP estadounidense que ofrece servicios de acceso a Internet por línea telefónica convencional, DSL y líneas alquiladas, además de Web hosting. Su red troncal incluye nueve circuitos T-1 (E-1 –2 Mbps–, en Europa) con una utilización media de entre 9 y 12 Mbps.
Para dar más sabor al entorno creado, se desplegaron cuatro “señuelos” en forma de sistemas corriendo versiones sin actualizaciones posteriores de Windows 2000 Server y NT 4.0 Server, Red Hat Linux 6.2 y Sun Solaris 2.6, que es como pedir a voces que se produzcan ataques. No en vano, diversos estudios han demostrado que en sólo cuestión de minutos un atacante es capaz de hacerse con sistemas que no han sido debidamente “parcheados” a partir de sus versiones originales. Para ello, basta con emplear scripts automatizados que encuentran y explotan sus vulnerabilidades, ya descubiertas con anterioridad y ampliamente difundidas. Se dio por supuesto desde el primer momento que los sensores de los IDS detectarían rápidamente este tipo de ataques.
Todos los IDS cuentan con al menos un sensor que monitoriza el tráfico y envía alarmas cuando se produce un comportamiento sospechoso. Hay dos principales métodos de detectar los problemas: detección de firmas y detección de anomalías. El primero, utiliza- do por todos los productos revisados salvo StealthWatch, de Lancope, genera una alarma siempre que el tráfico se comporta según un patrón de ataque conocido. Mediante la detección de anomalías, el IDS compara el comportamiento del tráfico en un momento dado con el considerado como normal, y activa alarmas cuando se registran diferencias sospechosas.
Obviamente, en la detección de firmas el tamaño de la biblioteca de ataques es clave. Como el IDS sólo informa de un ataque si conoce previamente su naturaleza, es perentorio mantener la bilbioteca lo más actualizada posible.
Por el contrario, los IDS que siguen la detección de anomalías no precisan conocer de antemano ataques específicos, sino comportamientos excepcionales, lo que simplifica su mantenimiento. Claro que sus alarmas serán tan útiles como lo sea el comportamiento “normal” del tráfico que emplea como referencia para establecer las comparaciones. No es imposible que un sistema basado en anomalías establezca como “normal” una red que ya haya experimentado diversos ataques, incapacitándose así para detectar futuras intrusiones.
También se analizaron las funciones de gestión de los IDS. La mayoría de estos productos ofrecen una jerarquía de gestión de dos o más capas: los sensores instalados en la red reportan a una consola de gestión y a una base de datos situada en otro emplazamiento. Para modelar este enfoque distribuido, se creó un túnel IP Security entre los sensores situados en Opus One y los laboratorios de pruebas, donde residían las estaciones de gestión.
Caídas por doquier
Inicialmente, se pensó en analizar los IDS en cuanto a precisión y facilidad de uso; luego fue necesario añadir como tercer parámetro la disponibilidad. Y aquí se impuso la dura realidad: todos los productos probados, salvo uno, experimentaron alguna caída durante los 30 días que aproximadamente duró la evaluación.
Incluso antes de activar los “señuelos”, se registraron numerosos problemas a medida que los sensores de los IDS se esforzaban por seguir el ritmo del tráfico. En algunos casos, esto se produce debido a que se sobrepasa la capacidad del sensor. Una primera versión del software NFR, por ejemplo, provocó que el sensor NID200 consumiese toda la memoria y recursos de CPU disponibles, fenómeno que desapareció con el “parche” adecuado. Un problema más común es el relacionado con las estaciones de gestión; la mayor parte estuvieron operativas sólo unos pocos días debido a la sobrecarga de la base de datos.
Secure Intrusion Detection System 4235 (Cisco), SecureNet 7145C (Intrusion) e IP530 (Nokia) fueron especialmente inestables en cuanto a disponibilidad. El sensor de Cisco no se bloqueó en ningún momento, pero no se puede decir lo mismo de su software de gestión. El fabricante suministró inicialmente la versión 2.3.3i de su Cisco Secure Policy Manager (CSPM). Se trata de una potente aplicación tan cargada de características útiles como tocada por un muy significativo punto flaco: si su base de datos crece demasiado, la aplicación deja de funcionar. Cisco sugirió que se creara y corriera diariamente un archivo batch que de forma automática eliminara los logs de CSPM. Este remedio mantiene en activo la base de datos, pero a costa de “extirpar” entradas previas que CSPM podría necesitar en algún momento para realizar sus funciones de correlación de eventos y generación de informes. Afortunadamente, la firma ha anunciado una nueva versión del producto que incorpora una base de datos más robusta.
Lo cierto es que, pese a que la solución se vende como capaz de manejar datos procedentes de un gran número de sensores, en la evaluación bastó uno solo para asfixiarle. También es justo decir que se utilizó una versión beta de la herramienta de gestión gratuita de Cisco Integrated Device Manager (IDM) con Integrated Event Viewer con total satisfacción.
El software SecureNet Provider (SNP), de Intrusion, emplea un enfoque multi
No es lo mismo el laboratorio que un entorno de producción real. Y así quedó de manifiesto en la evaluación realizada por IDG de siete productos IDS comerciales y uno de fuente abierta en un segmento plenamente operativo de un ISP: no sólo algunos IDS fallaron en repetidas ocasiones ante la avalancha de falsas alarmas que ellos mismos generaban, sino que incluso seguían reportando como tales los ataques reales. Por si fuera poco, algunas interfaces son tan complejas que hacían del análisis de estas falsas alarmas todo un reto. Por suerte, no todos los productos cometieron todos estos fallos.
Como ningún dispositivo se distinguió del resto, se optó por no nombrar ningún ganador. Los ocho productos probados –de Cisco, Intrusion, Lancope, Network Flight Recorder (NFR), Nokia (corriendo una versión OEM de Internet Security Systems RealSecure 6.5), OneSecure, Recourse Technologies y el paquete de fuente abierta Snort– exigen demasiado tiempo y experiencia a los usuarios. Esto no quiere decir que no ocupen un lugar destacado en las redes corporativas; de hecho, pueden ser herramientas valiosas para validar las tareas de otros dispositivos de seguridad. Pero instalar y poner en marcha las soluciones que conforman la actual generación de IDS requiere una sustancial inversión de tiempo si se quiere estar seguro de que se ocuparán del tráfico sospechoso, sin interferir en todo lo demás. Pero que no se recojan puntuaciones no quita valor al análisis: creemos que su lectura servirá a muchos usuarios a adentrarse en los principios de los intricados IDS.
Para la evaluación se utilizó como banco de pruebas la red de producción de Opus One, ISP estadounidense que ofrece servicios de acceso a Internet por línea telefónica convencional, DSL y líneas alquiladas, además de Web hosting. Su red troncal incluye nueve circuitos T-1 (E-1 –2 Mbps–, en Europa) con una utilización media de entre 9 y 12 Mbps.
Para dar más sabor al entorno creado, se desplegaron cuatro “señuelos” en forma de sistemas corriendo versiones sin actualizaciones posteriores de Windows 2000 Server y NT 4.0 Server, Red Hat Linux 6.2 y Sun Solaris 2.6, que es como pedir a voces que se produzcan ataques. No en vano, diversos estudios han demostrado que en sólo cuestión de minutos un atacante es capaz de hacerse con sistemas que no han sido debidamente “parcheados” a partir de sus versiones originales. Para ello, basta con emplear scripts automatizados que encuentran y explotan sus vulnerabilidades, ya descubiertas con anterioridad y ampliamente difundidas. Se dio por supuesto desde el primer momento que los sensores de los IDS detectarían rápidamente este tipo de ataques.
Todos los IDS cuentan con al menos un sensor que monitoriza el tráfico y envía alarmas cuando se produce un comportamiento sospechoso. Hay dos principales métodos de detectar los problemas: detección de firmas y detección de anomalías. El primero, utiliza- do por todos los productos revisados salvo StealthWatch, de Lancope, genera una alarma siempre que el tráfico se comporta según un patrón de ataque conocido. Mediante la detección de anomalías, el IDS compara el comportamiento del tráfico en un momento dado con el considerado como normal, y activa alarmas cuando se registran diferencias sospechosas.
Obviamente, en la detección de firmas el tamaño de la biblioteca de ataques es clave. Como el IDS sólo informa de un ataque si conoce previamente su naturaleza, es perentorio mantener la bilbioteca lo más actualizada posible.
Por el contrario, los IDS que siguen la detección de anomalías no precisan conocer de antemano ataques específicos, sino comportamientos excepcionales, lo que simplifica su mantenimiento. Claro que sus alarmas serán tan útiles como lo sea el comportamiento “normal” del tráfico que emplea como referencia para establecer las comparaciones. No es imposible que un sistema basado en anomalías establezca como “normal” una red que ya haya experimentado diversos ataques, incapacitándose así para detectar futuras intrusiones.
También se analizaron las funciones de gestión de los IDS. La mayoría de estos productos ofrecen una jerarquía de gestión de dos o más capas: los sensores instalados en la red reportan a una consola de gestión y a una base de datos situada en otro emplazamiento. Para modelar este enfoque distribuido, se creó un túnel IP Security entre los sensores situados en Opus One y los laboratorios de pruebas, donde residían las estaciones de gestión.
Caídas por doquier
Inicialmente, se pensó en analizar los IDS en cuanto a precisión y facilidad de uso; luego fue necesario añadir como tercer parámetro la disponibilidad. Y aquí se impuso la dura realidad: todos los productos probados, salvo uno, experimentaron alguna caída durante los 30 días que aproximadamente duró la evaluación.
Incluso antes de activar los “señuelos”, se registraron numerosos problemas a medida que los sensores de los IDS se esforzaban por seguir el ritmo del tráfico. En algunos casos, esto se produce debido a que se sobrepasa la capacidad del sensor. Una primera versión del software NFR, por ejemplo, provocó que el sensor NID200 consumiese toda la memoria y recursos de CPU disponibles, fenómeno que desapareció con el “parche” adecuado. Un problema más común es el relacionado con las estaciones de gestión; la mayor parte estuvieron operativas sólo unos pocos días debido a la sobrecarga de la base de datos.
Secure Intrusion Detection System 4235 (Cisco), SecureNet 7145C (Intrusion) e IP530 (Nokia) fueron especialmente inestables en cuanto a disponibilidad. El sensor de Cisco no se bloqueó en ningún momento, pero no se puede decir lo mismo de su software de gestión. El fabricante suministró inicialmente la versión 2.3.3i de su Cisco Secure Policy Manager (CSPM). Se trata de una potente aplicación tan cargada de características útiles como tocada por un muy significativo punto flaco: si su base de datos crece demasiado, la aplicación deja de funcionar. Cisco sugirió que se creara y corriera diariamente un archivo batch que de forma automática eliminara los logs de CSPM. Este remedio mantiene en activo la base de datos, pero a costa de “extirpar” entradas previas que CSPM podría necesitar en algún momento para realizar sus funciones de correlación de eventos y generación de informes. Afortunadamente, la firma ha anunciado una nueva versión del producto que incorpora una base de datos más robusta.
Lo cierto es que, pese a que la solución se vende como capaz de manejar datos procedentes de un gran número de sensores, en la evaluación bastó uno solo para asfixiarle. También es justo decir que se utilizó una versión beta de la herramienta de gestión gratuita de Cisco Integrated Device Manager (IDM) con Integrated Event Viewer con total satisfacción.
El software SecureNet Provider (SNP), de Intrusion, emplea un enfoque multi
