Intrusion Detection Systems

Clasificación de los IDSes
Generalmente existen dos grandes enfoques a la hora de clasificar a los sistemas de detección de intrusos: o bien en función de qué sistemas vigilan, o bien en función de cómo lo hacen.

Si elegimos la primera de estas aproximaciones tenemos dos grupos de sistemas de detección de intrusos: los que analizan actividades de una única máquina en busca de posibles ataques, y los que lo hacen de una subred (generalmente, de un mismo dominio de colisión) aunque se emplazen en uno sólo de los hosts de la misma. Esta última puntualización es importante: un IDS que detecta actividades sospechosas en una red no tiene porqué (y de hecho en la mayor parte de casos no suele ser así) ubicarse en todas las máquinas de esa red.
IDSes basados en red.
Un IDS basado en red monitoriza los paquetes que circulan por nuestra red en busca de elementos que denoten un ataque contra alguno de los sistemas ubicados en ella; el IDS puede situarse en cualquiera de los hosts o en un elemento que analice todo el tráfico (como un HUB o un enrutador). Esté donde esté, monitorizará diversas máquinas y no una sola: esta es la principal diferencia con los sistemas de detección de intrusos basados en host.
IDSes basados en máquina.
Mientras que los sistemas de detección de intrusos basados en red operan bajo todo un dominio de colisión, los basados en máquina realizan su función protegiendo un único sistema; de una forma similar - guardando las distancias, por supuesto - a como actúa un escudo antivirus residente en MS-DOS, el IDS es un proceso que trabaja en background (o que despierta periódicamente) buscando patrones que puedan denotar un intento de intrusión y alertando o tomando las medidas oportunas en caso de que uno de estos intentos sea detectado.
Algunos autores dividen el segundo grupo, el de los sistemas de detección de intrusos basados en máquina, en tres subcategorías:
Verificadores de integridad del sistema (SIV).
Un verificador de integridad no es más que un mecanismo encargado de monitorizar archivos de una máquina en busca de posibles modificaciones no autorizadas, por norma general backdoors dejadas por un intruso (por ejemplo, una entrada adicional en el fichero de contraseñas o un /bin/login que permite el acceso ante cierto nombre de usuario no registrado). El SIV más conocido es sin duda Tripwire, comentado en este mismo trabajo; la importancia de estos mecanismos es tal que en la actualidad algunos sistemas Unix integran `de serie' verificadores de integridad, como Solaris y su ASET (Automated Security Enhancement Tools).
Monitores de registros (LFM).
Estos sistemas monitorizan los archivos de log generados por los programas - generalmente demonios de red - de una máquina en busca de patrones que puedan indicar un ataque o una intrusión. Un ejemplo de monitor puede ser swatch, pero más habituales que él son los pequeños shellscripts que casi todos los administradores realizan para comprobar periódicamente sus archivos de log en busca de entradas sospechosas (por ejemplo, conexiones rechazadas en varios puertos provenientes de un determinado host, intentos de entrada remota como root...).
Sistemas de decepción.
Los sistemas de decepción o tarros de miel (honeypots), como Deception Toolkit (DTK), son mecanismos encargados de simular servicios con problemas de seguridad de forma que un pirata piense que realmente el problema se puede aprovechar para acceder a un sistema, cuando realmente se está aprovechando para registrar todas sus actividades. Se trata de un mecanismo útil en muchas ocasiones - por ejemplo, para conseguir `entretener' al atacante mientras se tracea su conexión - pero que puede resultar peligroso: >qué sucede si el propio sistema de decepción tiene un bug que desconocemos, y el atacante lo aprovecha para acceder realmente a nuestra máquina?
Realmente esta división queda algo pobre, ya que cada día se avanza más en la construcción de sistemas de detección de intrusos basados en host que no podrían englobarse en ninguna de las subcategorías anteriores.

La segunda gran clasificación de los IDSes se realiza en función de cómo actúan estos sistemas; actualmente existen dos grandes técnicas de detección de intrusos : las basadas en la detección de anomalías (anomaly detection) y las basadas en la detección de usos indebidos del sistema (misuse detection). Aunque más tarde hablaremos con mayor profundidad de cada uno de estos modelos, la idea básica de los mismos es la siguiente:
Detección de anomalías.
La base del funcionamiento de estos sistemas es suponer que una intrusión se puede ver como una anomalía de nuestro sistema, por lo que si fuéramos capaces de establecer un perfil del comportamiento habitual de los sistemas seríamos capaces de detectar las intrusiones por pura estadística: probablemente una intrusión sería una desviación excesiva de la media de nuestro perfil de comportamiento.
Detección de usos indebidos.
El funcionamiento de los IDSes basados en la detección de usos indebidos presupone que podemos establecer patrones para los diferentes ataques conocidos y algunas de sus variaciones; mientras que la detección de anomalías conoce lo normal (en ocasiones se dice que tienen un `conocimiento positivo', positive knowledge) y detecta lo que no lo es, este esquema se limita a conocer lo anormal para poderlo detectar (conocimiento negativo, negative knowledge).
Para ver más claramente la diferencia entre ambos esquemas, imaginemos un sistema de detección basado en monitorizar las máquinas origen desde las que un usuario sospechoso conecta a nuestro sistema: si se tratara de un modelo basado en la detección de anomalías, seguramente mantendría una lista de las dos o tres direcciones más utilizadas por el usuario legítimo, alertando al responsable de seguridad en caso de que el usuario conecte desde otro lugar; por contra, si se tratara de un modelo basado en la detección de usos indebidos, mantendría una lista mucho más amplia que la anterior, pero formada por las direcciones desde las sabemos con una alta probabilidad que ese usuario no va a conectar, de forma que si detectara un acceso desde una de esas máquinas, entonces es cuando el sistema tomaría las acciones oportunas.

En muchos trabajos aparece una tercera clasificación de los IDSes; se trata de la diferenciación entre los sistemas que trabajan periódicamente (denominados `pasivos') y los que operan en tiempo real (activos). Nosotros no contemplaremos, aunque la citemos, esta clasificación, ya que es totalmente minoritaria en comparación con las otras dos que hemos comentado. De cualquier forma, la idea es muy simple: un IDS de tiempo real (los denominados Real-Time Intrusion Detection Systems) trabaja contínuamente en busca de posibles ataques, mientras que los sistemas que se ejecutan a intervalos (Vulnerability Scanners) son analizadores de vulnerabilidades que cualquier administrador ha de ejecutar regularmente (ya sea de forma manual o automática) contra sus sistemas para verificar que no presentan problemas de seguridad.

Requisitos de un IDS
Sin importar qué sistemas vigile o su forma de trabajar, cualquier sistema de detección de intrusos ha de cumplir algunas propiedades para poder desarrollar su trabajo correctamente. En primer lugar, y quizás como característica más importante, el IDS ha de ejecutarse contínuamente sin nadie que esté obligado a supervisarlo; independientemente de que al detectar un problema se informe a un operador o se lance una respuesta automática, el funcionamiento habitual no debe implicar interacción con un humano. Podemos fijarnos en que esto parece algo evidente: muy pocas empresas estarían dispuestas a contratar a una o varias personas simplemente para analizar logs o controlar los patrones del tráfico de una red. Sin entrar a juzgar la superioridad de los humanos frente a las máquinas (>puede un algoritmo determinar perfectamente si un uso del sistema está correctamente autorizado?) o viceversa (>sería capaz una persona de analizar en tiempo real todo el tráfico que llega a un servidor web mediano?), hemos de tener presente que los sistemas de detección son mecanismos automatizados que se instalan y configuran de forma que su trabajo habitual sea transparente a los operadores del entorno informático.

Otra propiedad, y también como una característica a tener siempre en cuenta, es la aceptabilidad o grado de aceptación del IDS; al igual que sucedía con cualquier modelo de autenticación, los mecanismos de detección de intrusos han de ser aceptables para las personas que trabajan habitualmente en el entorno. Por ejemplo, no ha de introducir una sobrecarga considerable en el sistema (si un IDS ralentiza demasiado una máquina, simplemente no se utilizará) ni generar una cantidad elevada de falsos positivos (detección de intrusiones que realmente no lo son) o de logs, ya que entonces llegará un momento en que nadie se preocupe de comprobar las alertas emitidas por el detector. Por supuesto (y esto puede parecer una tontería, pero es algo que se hace más a menudo de lo que podamos imaginar), si para evitar problemas con las intrusiones simplemente apagamos el equipo o lo desconectamos de la red, tenemos un sistema bastante seguro...pero inaceptable.

Una tercera característica a evaluar a la hora de hablar de sistemas de detección de intrusos es la adaptabilidad del mismo a cambios en el entorno de trabajo. Como todos sabemos, ningún sistema informático puede considerarse estático: desde la aplicación más pequeña hasta el propio kernel de Unix, pasando por supuesto por la forma de trabajar de los usuarios (>quién nos asegura que ese engorroso procedimiento desde una `desfasada' línea de órdenes mañana no se realizará desde una aplicación gráfica, que realmente hace el mismo trabajo pero que genera unos patrones completamente diferentes en nuestro sistema?), todo cambia con una periodicidad más o menos elevada. Si nuestros mecanismos de detección de intrusos no son capaces de adaptarse rápidamente a esos cambios, están condenados al fracaso.

Todo IDS debe además presentar cierta tolerancia a fallos o capacidad de respuesta ante situaciones inesperadas; insistiendo en lo que comentábamos antes sobre el carácter altamente dinámico de un entorno informático, algunos - o muchos - de los cambios que se pueden producir en dicho entorno no son graduales sino bruscos, y un IDS ha de ser capaz de responder siempre adecuadamente ante los mismos. Podemos contemplar, por ejemplo, un reinicio inesperado de varias máquinas o un intento de engaño hacia el IDS; esto último es especialmente crítico: sólo hemos de pararnos a pensar que si un atacante consigue modificar el comportamiento del sistema de detección y el propio sistema no se da cuenta de ello, la intrusión nunca será notificada, con los dos graves problemas que eso implica: aparte de la intrusión en sí, la falsa sensación de seguridad que produce un IDS que no genera ninguna alarma es un grave inconveniente de cara a lograr sistemas seguros.

IDSes basados en máquina
Como antes hemos comentado, un sistema de detección de intrusos basado en máquina (host-based IDS) es un mecanismo que permite detectar ataques o intrusiones contra la máquina sobre la que se ejecuta.

Tradicionalmente, los modelos de detección basados en máquina han consistido por una parte en la utilización de herramientas automáticas de análisis de logs generados por diferentes aplicaciones o por el propio kernel del sistema operativo, prestando siempre especial atención a los registros relativos a demonios de red, como un servidor web o el propio inetd, y por otra - quizás no tan habitual como la anterior - en el uso de verificadores de integridad de determinados ficheros vitales para el sistema, como el de contraseñas; no obstante, desde hace unos años un tercer esquema de detección se está implantando con cierta fuerza: se trata de los sistemas de detección, honeypots o tarros de miel.

El análisis de logs generados por el sistema (entendiendo como tales no sólo a los relativos al núcleo, sino también a aquellos de aplicaciones nativas de cada Unix, como syslogd) varía entre diferentes clones de Unix por una sencilla razón: cada uno de ellos guarda la información con un cierto formato, y en determinados ficheros, aunque todos - o casi todos - sean capaces de registrar los mismos datos, que son aquellos que pueden ser indicativos de un ataque. La mayor parte de Unices son capaces de registrar con una granularidad lo suficientemente fina casi todas las actividades que se llevan a cabo en el sistema, en especial aquellas que pueden suponer - aunque sea remotamente - una vulneración de su seguridad; sin embargo, el problema radica en que pocos administradores se preocupan de revisar con un mínimo de atención esos logs, por lo que muchos ataques contra la máquina, tanto externos como internos, y tanto fallidos como exitosos, pasan finalmente desapercibidos. Aquí es donde entran en juego las herramientas automáticas de análisis, como swatch o logcheck; a grandes rasgos, realizan la misma actividad que podría ejecutar un shellscript convenientemente planificado que incluyera entre sus líneas algunos grep de registros sospechosos en los archivos de log.

>A qué entradas de estos ficheros debemos estar atentos? Evidentemente, esto depende de cada sistema y de lo que sea `normal' en él, aunque suelen existir registros que en cualquier máquina denotan una actividad cuanto menos sospechosa. Esto incluye ejecuciones fallidas o exitosas de la orden su, peticiones no habituales al servicio SMTP (como vrfy o expn), conexiones a diferentes puertos rechazadas por TCP Wrappers, intentos de acceso remotos como superusuario, etc; si en la propia máquina tenemos instalado un cortafuegos independiente del corporativo, o cualquier otro software de seguridad - uno que quizás es especialmente recomendable es PortSentry -, también conviene estar atentos a los logs generados por los mismos, que habitualmente se registran en los ficheros normales de auditoría del sistema (syslog, messages...) y que suelen contener información que con una probabilidad elevada denotan un ataque real.

Por otra parte, la verificación de integridad de archivos se puede realizar a diferentes niveles, cada uno de los cuales ofrece un mayor o menor grado de seguridad. Por ejemplo, un administrador puede programar y planificar un sencillo shellscript para que se ejecute periódicamente y compruebe el propietario y el tamaño de ciertos ficheros como /etc/passwd o /etc/shadow; evidentemente, este esquema es extremadamente débil, ya que si un usuario se limita a cambiar en el archivo correspondiente su UID de 100 a 000, este modelo no descubriría el ataque a pesar de su gravedad. Por tanto, parece obvio que se necesita un esquema de detección mucho más robusto, que compruebe aparte de la integridad de la información registrada en el inodo asociado a cada fichero (fecha de última modificación, propietario, grupo propietario...) la integridad de la información contenida en dicho archivo; y esto se consigue muy fácilmente utilizando funciones resumen sobre cada uno de los ficheros a monitorizar, funciones capaces de generar un hash único para cada contenido de los archivos. De esta forma, cualquier modificación en su contenido generará un resumen diferente, que al ser comparado con el original dará la voz de alarma; esta es la forma de trabajar de Tripwire, el más conocido y utilizado de todos los verificadores de integridad disponibles para entornos Unix.

Sea cual sea nuestro modelo de verificación, en cualquiera de ellos debemos llevar a cabo inicialmente un paso común: generar una base de datos de referencia contra la que posteriormente compararemos la información de cada archivo. Por ejemplo, si nos limitamos a comprobar el tamaño de ciertos ficheros debemos, nada más configurar el sistema, registrar todos los nombres y tamaños de los ficheros que deseemos, para después comparar la información que periódicamente registraremos en nuestra máquina con la que hemos almacenado en dicha base de datos; si existen diferencias, podemos encontrarnos ante un indicio de ataque. Lo mismo sucederá si registramos funciones resumen: debemos generar un hash inicial de cada archivo contra el que comparar después la información obtenida en la máquina. Independientemente de los contenidos que deseemos registrar en esa base de datos inicial, siempre hemos de tener presente una cosa: si un pirata consigue modificarla de forma no autorizada, habrá burlado por completo a nuestro sistema de verificación. Así, es vital mantener su integridad; incluso es recomendable utilizar medios de sólo lectura, como un CD-ROM, o incluso unidades extraíbles - discos o disquetes - que habitualmente no estarán disponibles en el sistema, y sólo se utilizarán cuando tengamos que comprobar la integridad de los archivos de la máquina.

Por último, aunque su utilización no esté tan extendida como la de los analizadores de logs o la de los verificadores de integridad, es necesario hablar, dentro de la categoría de los sistemas de detección de intrusos basados en máquina, de los sistemas de decepción o honeypots. Básicamente, estos `tarros de miel' son sistemas completos o parte de los mismos (aplicaciones, servicios, subentornos...) diseñados para recibir ciertos tipos de ataques; cuando sufren uno, los honeypots detectan la actividad hostil y aplican una estrategia de respuesta. Dicha estrategia puede consistir desde un simple correo electrónico al responsable de la seguridad de la máquina hasta un bloqueo automático de la dirección atacante; incluso muchos de los sistemas - la mayoría - son capaces de simular vulnerabilidades conocidas de forma que el atacante piense que ha tenido éxito y prosiga con su actividad, mientras es monitorizado por el detector de intrusos.

El concepto teórico que está detrás de los tarros de miel es el denominado `conocimiento negativo': proporcionar deliveradamente a un intruso información falsa - pero que él considerará real - de nuestros sistemas, con diferentes fines: desde poder monitorizar durante más tiempo sus actividades, hasta despistarlo, pasando por supuesto por la simple diversión. Evidentemente, para lograr engañar a un pirata medianamente experimentado la simulación de vulnerabilidades ha de ser muy `real', dedicando a tal efecto incluso sistemas completos (denominados 'máquinas de sacrificio'), pero con atacantes de nivel medio o bajo dicho engaño es muchísimo más sencillo: en muchos casos basta simular la existencia de un troyano como BackOrifice mediante FakeBO (http://cvs.linux.hr/fakebo/) para que el pirata determine que realmente estamos infectados e intente utilizar ese camino en su ataque contra nuestro sistema.

Algunos sistemas de decepción no simulan vulnerabilidades tal y como habitualmente se suele entender este concepto; dicho de otra forma, su objetivo no es engañar a un atacante durante mucho tiempo, proporcionándole un subentorno en el sistema que aparente de forma muy realista ser algo vulnerable, sino que su `decepción' es bastante más elemental: se limitan a presentar un aspecto (quizás deberíamos llamarle interfaz) que parece vulnerable, pero que cualquier aprendiz de pirata puede descubrir sin problemas que no es más que un engaño. >Dónde está entonces la función de estos sistemas, denominados en ocasiones `detectores de pruebas'? Por norma, su tarea es recopilar información del atacante y del ataque en sí; por ejemplo, ya que antes hemos hablado de FakeBO, podemos imaginar un programa que se encargue de escuchar en el puerto 31337 de nuestro sistema - donde lo hace el troyano real - y, cada vez que alguien acceda a él, guardar la hora, la dirección origen, y los datos enviados por el atacante. En realidad, no es una simulación que pueda engañar ni al pirata más novato, pero hemos logrado el objetivo de cualquier sistema de detección de intrusos: registrar el ataque; además, también se puede considerar un honeypot, ya que simula un entorno vulnerable, aunque sólo logre engañar a nuestro atacante durante unos segundos. De cualquier forma, es necesario indicar que en algunas publicaciones (como [Gra00]) se diferencia a los sistemas de decepción `completos' de estos mecanismos de engaño simple, aunque a todos se les englobe dentro del conjunto denominado honeypots.

Hemos revisado en este punto las ideas más generales de los sistemas de detección de intrusos basados en host; aunque hoy en día los que vamos a describir a continuación, los basados en red, son con diferencia los más utilizados, como veremos más adelante todos son igualmente necesarios si deseamos crear un esquema de detección con la máxima efectividad. Se trata de niveles de protección diferentes pero que tienen un mismo objetivo: alertar de actividades sospechosas y, en algunos casos, proporcionar una respuesta automática a las mismas.

IDSes basados en red
Los sistemas de detección de intrusos basados en red (network-based IDS) son aquellos capaces de detectar ataques contra diferentes sistemas de una misma red (en concreto, de un mismo dominio de colisión), aunque generalmente se ejecuten en uno solo de los hosts de esa red. Para lograr su objetivo, al menos uno de los interfaces de red de esta máquina sensor trabaja en modo promiscuo, capturando y analizando todas las tramas que pasan por él en busca de patrones indicativos de un ataque.

>Cuáles pueden ser estos `patrones identificativos de un ataque' a los que estamos haciendo referencia? Casi cualquiera de los diferentes campos de una trama de red TCP/IP puede tener un valor que, con mayor o menor probabilidad, represente un ataque real; los casos más habituales incluyen:
Campos de fragmentación.
Una cabecera IP contiene dieciseis bits reservados a información sobre el nivel de fragmentación del datagrama; de ellos, uno no se utiliza y trece indican el desplazamiento del fragmento que transportan. Los otros dos bits indican o bien que el paquete no ha de ser fragmentado por un router intermedio (DF, Don´t Fragment) o bien que el paquete ha sido fragmentado y no es el último que se va a recibir (MF, More Fragments). Valores incorrectos de parámetros de fragmentación de los datagramas se han venido utilizando típicamente para causar importantes negaciones de servicio a los sistemas y, desde hace también un tiempo incluso para obtener la versión del operativo que se ejecuta en un determinado host; por ejemplo, >qué le sucedería al subsistema de red implantado en el núcleo de una máquina Unix si nunca recibe una trama con el bit MF reseteado, indicando que es el último de un paquete? >se quedaría permanentemente esperándola? >y si recibe uno que en teoría no está fragmentado pero se le indica que no es el último que va a recibir? >cómo respondería el núcleo del operativo en este caso? Como vemos, si en nuestras máquinas observamos ciertas combinaciones de bits relacionados con la fragmentación realmente tenemos motivos para - cuanto menos - sospechar que alguien trata de atacarnos.
Dirección origen y destino.
Las direcciones de la máquina que envía un paquete y la de la que lo va a recibir también son campos interesantes de cara a detectar intrusiones en nuestros sistemas o en nuestra red. No tenemos más que pensar el tráfico proveniente de nuestra DMZ (y que no se trate de la típica respuesta ante una petición como las que se generan al visitar páginas web, por poner un ejemplo) que tenga como destino nuestra red protegida: es muy posible que esos paquetes constituyan un intento de violación de nuestra política de seguridad. Otros ejemplos clásicos son las peticiones originadas desde Internet y que tienen como destino máquinas de nuestra organización que no están ofreciendo servicios directos al exterior, como un servidor de bases de datos cuyo acceso está restringido a sistemas de nuestra red.
Puerto origen y destino.
Los puertos origen y destino (especialmente este último) son un excelente indicativo de actividades sospechosas en nuestra red. Aparte de los intentos de acceso no autorizado a servicios de nuestros sistemas, pueden detectar actividades que también supondrán a priori violaciones de nuestras políticas de seguridad, como la existencia de troyanos, ciertos tipos de barridos de puertos, o la presencia de servidores no autorizados dentro de nuestra red.
Flags TCP.
Uno de los campos de una cabecera TCP contiene seis bits (URG, ACK, PSH, RST, SYN y FIN), cada uno de ellos con una finalidad diferente (por ejemplo, el bit SYN es utilizado para establecer una nueva conexión, mientras que FIN hace justo lo contrario: liberarla). Evidentemente el valor de cada uno de estos bits será 0 o 1, lo cual de forma aislada no suele decir mucho (ni bueno ni malo) de su emisor; no obstante, ciertas combinaciones de valores suelen ser bastante sospechosas: por ejemplo, una trama con los dos bits de los que hemos hablado - SYN y FIN - activados simultáneamente sería indicativa de una conexión que trata de abrirse y cerrarse al mismo tiempo. Para hacernos una idea de la importancia de estos bits de control, no conviene olvidar que uno de los problemas de seguridad más conocidos de los últimos años sobre plataformas Windows - de los muchos que han tenido estos entornos - estaba fundamentado básicamente en el manejo de paquetes OOB (Out Of Band): tramas con el bit URG activado.
Campo de datos.
Seguramente, el campo de datos de un paquete que circula por la red es donde más probabilidades tenemos de localizar un ataque contra nuestros sistemas; esto es debido a que con toda probabilidad nuestro cortafuegos corporativo detendrá tramas cuya cabecera sea `sospechosa' (por ejemplo, aquellas cuyo origen no esté autorizado a alcanzar su destino o con campos incorrectos), pero rara vez un firewall se parará a analizar el contenido de los datos transportados en la trama. Por ejemplo, una petición como `GET ../../../etc/passwd HTTP/1.0' contra el puerto 80 del servidor web de nuestra empresa no se detendrá en el cortafuegos, pero muy probablemente se trata de un intento de intrusión contra nuestros sistemas.
Acabamos de ver sólo algunos ejemplos de campos de una trama TCP/IP que, al presentar determinados valores, pueden ser indicativos de un ataque; sin embargo, no todo es tan sencillo como comprobar ciertos parámetros de cada paquete que circula por uno de nuestros segmentos. También es posible y necesario que un detector de intrusos basado en red sea capaz de notificar otros ataques que no se pueden apreciar en una única trama; uno de estos ataques es la presencia de peticiones que, aunque por sí mismas no sean sospechosas, por su repetición en un intervalo de tiempo más o menos pequeño puedan ser indicativas de un ataque (por ejemplo, barridos de puertos horizontales o verticales). Otros ataques difíciles de detectar analizando tramas de forma independiente son las negaciones de servicio distribuidas (DDoS, Distributed Denial of Service), justamente por el gran número de orígenes que el ataque tiene por definición.

Según lo expuesto hasta ahora en este punto, puede parecer que los sistemas de detección de intrusos basados en red funcionan únicamente mediante la detección de patrones; realmente, esto no es así: en principio, un detector de intrusos basado en red puede estar basado en la detección de anomalías, igual que lo puede estar uno basado en máquinas. No obstante, esta aproximación es minoritaria; aunque una intrusión generará probablemente comportamientos anormales (por ejemplo, un tráfico excesivo entre el sistema atacante y el atacado) susceptibles de ser detectados y eliminados, con demasiada frecuencia estos sistemas no detectarán la intrusión hasta que la misma se encuentre en un estado avanzado. Este problema hace que la mayor parte de IDSes basados en red que existen actualmente funcionen siguiendo modelos de detección de usos indebidos.

Para finalizar este punto dedicado a los sistemas de detección de intrusos basados en red es necesario hablar de las honeynets ([Spi01b]) - literalmente, `redes de miel' -. Se trata de un concepto muy parecido al de los honeypots, de los que ya hemos hablado, pero extendido ahora a redes completas: redes diseñadas para ser comprometidas, formadas por sistemas reales de todo tipo que, una vez penetrados, permiten capturar y analizar las acciones que está realizando el atacante para así poder aprender más sobre aspectos como sus técnicas o sus objetivos. Realmente, aunque la idea general sea común, existen dos grandes diferencias de diseño entre un tarro de miel y una honeynet: por un lado, esta última evidentemente es una red completa que alberga diferentes entornos de trabajo, no se trata de una única máquina; por otro, los sistemas dentro de esta red son sistemas reales, en el sentido de que no simulan ninguna vulnerabilidad, sino que ejecutan aplicaciones típicas (bases de datos, sistemas de desarrollo...) similares a las que podemos encontrar en cualquier entorno de trabajo `normal'. El objetivo de una honeynet no es la decepción, sino principalmente conocer los movimientos de un pirata en entornos semireales, de forma que aspectos como sus vulnerabilidades o sus configuraciones incorrectas se puedan extrapolar a muchos de los sistemas que cualquier empresa posee en la actualidad; de esta forma podemos prevenir nuevos ataques exitosos contra entornos reales.

En el funcionamiento de una `red de miel' existen dos aspectos fundamentales y especialmente críticos, que son los que introducen la gran cantidad trabajo de administración extra que una honeynet implica para cualquier organización. Por un lado, tenemos el control del flujo de los datos: es vital para nuestra seguridad garantizar que una vez que un sistema dentro de la honeynet ha sido penetrado, este no se utilice como plataforma de salto para atacar otras máquinas, ni de nuestra organización ni de cualquier otra; la `red de miel' ha de permanecer perfectamente controlada, y por supuesto aislada del resto de los segmentos de nuestra organización. En segundo lugar, otro aspecto básico es la captura de datos, la monitorización de las actividades que un atacante lleva a cabo en la honeynet. Recordemos que nuestro objetivo principal era conocer los movimientos de la comunidad pirata para poder extrapolarlos a sistemas reales, por lo que también es muy importante para el correcto funcionamiento de una honeynet una correcta recogida de datos generados por el atacante: ha de ser capturada toda la información posible de cada acción, de una forma poco agresiva (esto es, sin tener que realizar grandes cambios en cada uno de los sistemas) y por supuesto sin que el atacante se entere. Además (muy importante), estos datos recogidos nunca se han de mantener dentro del perímetro de la honeynet, ya que si fuera así cualquier pirata podría destruirlos con una probabilidad demasiado elevada.

El concepto de honeynet es relativamente nuevo dentro del mundo de la seguridad y, en concreto, de los sistemas de detección de intrusos; a pesar de ello, se trata de una idea muy interesante que presumiblemente va a extenderse de una forma más o menos rápida (no todo lo rápida que nos gustaría, ya que implantar y explotar una honeynet no es algo ni trivial, ni mucho menos rápido); cada día más, las herramientas de seguridad no se conforman con detectar problemas conocidos, sino que tratan de anticiparse a nuevas vulnerabilidades que aún no se han publicado pero que pueden estar - y de hecho están - presentes en multitud de sistemas. Conocer cuanto antes cualquier avance de la comunidad underground es algo vital si queremos lograr este objetivo.

Como antes hemos comentado, los sistemas de detección de intrusos basados en red, de los que hemos hablado a lo largo de este punto, son con diferencia los más utilizados actualmente en sistemas en explotación; no obstante, como casi cualquier herramienta relacionada con la seguridad, estos sistemas no son ninguna panacea, y su implantación ha de verse complementada con una correcta configuración de elementos como nuestro cortafuegos corporativo o, por supuesto, los sistemas de detección basados en host. Veremos más adelante, en este mismo capítulo, que ambos tipos de IDSes son igualmente necesarios en nuestro entorno de trabajo.

--------------------------------------------------------------------------------

Mierda, muy buena data che, yo hace un par de meses finalize con una implementación, snort+mysql+acid, y te digo este documento esta muy copado, si puedo voy a tirarles data de este tema ya que es fascinante asi como el mundo de los honeypots, saludos y gracias

Excelente DATA ...


D4RK .. muchas gracias por el aporte !

MUY BUENA DATA!!!!

Muchas Gracias!!!!

BUENISIMA LA INFO MUCHAS GRACIAS SUBI MAS SI PODES GRACIAS!!!!!!!!!!!!!

hola, queria preguntar que soft de deteccion de intrusos (automatico) me recomendas para mi pc que tengo todo el dia prendida... ?

muchas gracias
saludos