SISTEMAS DE DETECCION DE INTRUSOSAntonio Villaln Huerta oMayo, 2005

Este documento se corresponde casi en su totalidad con el cap tulo 18 de Seguridad en Unix y Redes v2.1, de Antonio Villaln Huerta. o

Indice General1 Introduccin o 2 Clasicacin de los IDSes o 3 Requisitos de un IDS 4 IDSes basados en mquina a 5 IDSes basados en red 6 Deteccin de anomal o as 7 Deteccin de usos indebidos o 8 Implantacin real de un IDS o 8.1 IDS en el cortafuegos . . . . 8.2 IDS en la red: snort . . . . 8.3 IDS en la mquina . . . . . a 8.4 Estrategias de respuesta . . 8.5 Ampliacin del esquema . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 4 5 7 10 12 14 15 16 21 24 26

1

Introduccin o

A pesar de que un enfoque clsico de la seguridad de un sistema informtico siempre dene como a a principal defensa del mismo sus controles de acceso (desde una pol tica implantada en un cortafuegos hasta unas listas de control de acceso en un router o en el propio sistema de cheros de una mquina), esta visin es extremadamente simplista si no tenemos en cuenta que en muchos casos a o esos controles no pueden protegernos ante un ataque ([Lun90]). Por poner un ejemplo sencillo, pensemos en un rewall donde hemos implantado una pol tica que deje acceder al puerto 80 de nuestros servidores web desde cualquier mquina de Internet; ese cortafuegos slo comprobar si a o a el puerto destino de una trama es el que hemos decidido para el servicio http, pero seguramente no tendr en cuenta si ese trco representa o no un ataque o una violacin de nuestra pol a a o tica de seguridad: por ejemplo, no detendr a un pirata que trate de acceder al archivo de contraseas de a n una mquina aprovechando un bug del servidor web. Desde un pirata informtico externo a nuestra a a organizacin a un usuario autorizado que intenta obtener privilegios que no le corresponden en un o sistema, nuestro entorno de trabajo no va a estar nunca a salvo de intrusiones. Llamaremos intrusin a un conjunto de acciones que intentan comprometer la integridad, cono dencialidad o disponibilidad de un recurso ([HLMS90]); analizando esta denicin, podemos darnos o cuenta de que una intrusin no tiene por qu consistir en un acceso no autorizado a una mquina: o e a tambin puede ser una negacin de servicio. A los sistemas utilizados para detectar las intrusiones e o o los intentos de intrusin se les denomina sistemas de deteccin de intrusiones (Intrusion Deo o tection Systems, IDS) o, ms habitualmente y aunque no sea la traduccin literal sistemas de a o deteccin de intrusos; cualquier mecanismo de seguridad con este propsito puede ser considerao o do un IDS, pero generalmente slo se aplica esta denominacin a los sistemas automticos (software o o a o hardware): es decir, aunque un guardia de seguridad que vigila en la puerta de la sala de operaciones pueda considerarse en principio como un sistema de deteccin de intrusos, como veremos a o continuacin lo habitual (y lgico) es que a la hora de hablar de IDSes no se contemplen estos casos. o o Una de las primeras cosas que deber amos plantearnos a la hora de hablar de IDSes es si realmente necesitamos uno de ellos en nuestro entorno de trabajo; a n de cuentas, debemos tener ya un sistema de proteccin perimetral basado en cortafuegos, y por si nuestro rewall fallara, cada o sistema habr de estar congurado de una manera correcta, de forma que incluso sin cortafuegos a cualquier mquina pudiera seguirse considerando relativamente segura. La respuesta es, sin duda, a s debemos esperar que en cualquier momento alguien consiga romper la seguridad de nuestro ; entorno informtico, y por tanto hemos de ser capaces de detectar ese problema tan pronto como a sea posible (incluso antes de que se produzca, cuando el potencial atacante se limite a probar suerte contra nuestras mquinas). Ningn sistema informtico puede considerarse completamente seguro, a u a pero incluso aunque nadie consiga violar nuestras pol ticas de seguridad, los sistemas de deteccin o de intrusos se encargarn de mostrarnos todos los intentos de multitud de piratas para penetrar en a nuestro entorno, no dejndonos caer en ninguna falsa sensacin de seguridad: si somos conscientes a o de que a diario hay gente que trata de romper nuestros sistemas, no caeremos en la tentacin de o pensar que nuestras mquinas estn seguras porque nadie sabe de su existencia o porque no son a a interesantes para un pirata. Los sistemas de deteccin de intrusos no son precisamente nuevos: el primer trabajo sobre esta o materia ([And80]) data de 1980; no obstante, este es uno de los campos ms en auge desde hace a ya unos aos dentro de la seguridad informtica. Y no es extrao: la capacidad para detectar y n a n responder ante los intentos de ataque contra nuestros sistemas es realmente muy interesante. Durante estos veinte aos, cientos de investigadores de todo el mundo han desarrollado, con mayor o n menor xito, sistemas de deteccin de todo tipo, desde simples procesadores de logs hasta complee o jos sistemas distribuidos, especialmente vigentes con el auge de las redes de computadores en los ultimos aos; una excelente perspectiva histrica de algunos de ellos puede encontrarse en [Lis95] n o o [Axe98].

2

Clasicacin de los IDSes o

Generalmente existen dos grandes enfoques a la hora de clasicar a los sistemas de deteccin de o intrusos: o bien en funcin de qu sistemas vigilan, o bien en funcin de cmo lo hacen. o e o o Si elegimos la primera de estas aproximaciones tenemos dos grupos de sistemas de deteccin de o intrusos: los que analizan actividades de una unica mquina en busca de posibles ataques, y los que a lo hacen de una subred (generalmente, de un mismo dominio de colisin) aunque se emplazen en o uno slo de los hosts de la misma. Esta ultima puntualizacin es importante: un IDS que detecta o o actividades sospechosas en una red no tiene porqu (y de hecho en la mayor parte de casos no suele e ser as ubicarse en todas las mquinas de esa red. ) a 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 trco (como un HUB a o un enrutador). Est donde est, monitorizar diversas mquinas y no una sola: esta es la e e a a principal diferencia con los sistemas de deteccin de intrusos basados en host. o IDSes basados en mquina. a Mientras que los sistemas de deteccin de intrusos basados en red operan bajo todo un dominio o de colisin, los basados en mquina realizan su funcin protegiendo un unico sistema; de una o a o forma similar guardando las distancias, por supuesto a como acta un escudo antivirus u residente en MS-DOS, el IDS es un proceso que trabaja en background (o que despierta peridicamente) buscando patrones que puedan denotar un intento de intrusin y alertando o o o tomando las medidas oportunas en caso de que uno de estos intentos sea detectado. Algunos autores ([Gra00]) dividen el segundo grupo, el de los sistemas de deteccin de intrusos o basados en mquina, en tres subcategor a as: Vericadores de integridad del sistema (SIV). Un vericador de integridad no es ms que un mecanismo encargado de monitorizar archivos de a una mquina en busca de posibles modicaciones no autorizadas, por normal general backdoors a dejadas por un intruso (por ejemplo, una entrada adicional en el chero de contraseas o un n /bin/login que permite el acceso ante cierto nombre de usuario no registrado). El SIV ms a conocido es sin duda Tripwire; la importancia de estos mecanismos es tal que en la actualidad algunos sistemas Unix integran de serie vericadores 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 mquina en busca de patrones que puedan indicar un ataque o una a intrusin. Un ejemplo de monitor puede ser swatch, pero ms habituales que l son los peo a e queos shellscripts que casi todos los administradores realizan para comprobar peridicamente n o 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 decepcin. o Los sistemas de decepcin o tarros de miel (honeypots), como Deception Toolkit (DTK), son o 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 a mecanismo util en muchas ocasiones por ejemplo, para conseguir entretener al atacante mientras se tracea su conexin pero que puede resultar peligroso: qu sucede si el propio o e sistema de decepcin tiene un bug que desconocemos, y el atacante lo aprovecha para acceder o realmente a nuestra mquina? a Realmente esta divisin queda algo pobre, ya que cada d se avanza ms en la construccin de o a a o sistemas de deteccin de intrusos basados en host que no podr englobarse en ninguna de las o an

subcategor anteriores. as La segunda gran clasicacin de los IDSes se realiza en funcin de cmo actan estos sistemas; o o o u actualmente existen dos grandes tcnicas de deteccin de intrusos ([Sun96]): las basadas en la dee o teccin de anomal (anomaly detection) y las basadas en la deteccin de usos indebidos del sistema o as o (misuse detection). Aunque ms tarde hablaremos con mayor profundidad de cada uno de estos a modelos, la idea bsica de los mismos es la siguiente: a Deteccin de anomal o as. La base del funcionamiento de estos sistemas es suponer que una intrusin se puede ver como o una anomal de nuestro sistema, por lo que si furamos capaces de establecer un perl del a e comportamiento habitual de los sistemas ser amos capaces de detectar las intrusiones por pura estad stica: probablemente una intrusin ser una desviacin excesiva de la media de nuestro o a o perl de comportamiento. Deteccin de usos indebidos. o El funcionamiento de los IDSes basados en la deteccin de usos indebidos presupone que o podemos establecer patrones para los diferentes ataques conocidos y algunas de sus variaciones; mientras que la deteccin de anomal conoce lo normal y detecta lo que no lo es, este o as esquema se limita a conocer lo anormal para poderlo detectar. Para ver ms claramente la diferencia entre ambos esquemas, imaginemos un sistema de deteccin a o basado en monitorizar las mquinas origen desde las que un usuario sospechoso conecta a nuestro a sistema: si se tratara de un modelo basado en la deteccin de anomal seguramente mantendr o as, a una lista de las dos o tres direcciones ms utilizadas por el usuario leg a 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 deteccin de usos indebidos, mantendr una lista mucho ms amplia que o a a 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 mquinas, entonces a es cuando el sistema tomar las acciones oportunas. a En muchos trabajos ([Esc98], [Thu00]. . . ) aparece una tercera clasicacin de los IDSes; se trata o de la diferenciacin entre los sistemas que trabajan peridicamente y los que operan en tiempo real. o o Nosotros no contemplaremos, aunque la citemos, esta clasicacin, ya que es totalmente minoritao ria en comparacin con las otras dos que hemos comentado. De cualquier forma, la idea es muy o simple: un IDS de tiempo real (los denominados RealTime 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 automtica) contra sus sistemas para vericar que a no presentan problemas de seguridad.

3

Requisitos de un IDS

Sin importar qu sistemas vigile o su forma de trabajar, cualquier sistema de deteccin de intrusos e o ha de cumplir algunas propiedades para poder desarrollar su trabajo correctamente. En primer lugar, y quizs como caracter a stica ms importante, el IDS ha de ejecutarse cont a nuamente sin nadie que est obligado a supervisarlo; independientemente de que al detectar un problema se informe e a un operador o se lance una respuesta automtica, el funcionamiento habitual no debe implicar a interaccin con un humano. Podemos jarnos en que esto parece algo evidente: muy pocas emo presas estar dispuestas a contratar a una o varias personas simplemente para analizar logs o an controlar los patrones del trco de una red. Sin entrar a juzgar la superioridad de los humanos a frente a las mquinas (puede un algoritmo determinar perfectamente si un uso del sistema est a a correctamente autorizado?) o viceversa (ser capaz una persona de analizar en tiempo real todo el a trco que llega a un servidor web mediano?), hemos de tener presente que los sistemas de deteccin a o son mecanismos automatizados que se instalan y conguran de forma que su trabajo habitual sea transparente a los operadores del entorno informtico. a

Otra propiedad, y tambin como una caracter e stica a tener siempre en cuenta, es la aceptabilidad o grado de aceptacin del IDS; al igual que suced con cualquier modelo de autenticacin, o a o los mecanismos de deteccin de intrusos han de ser aceptables para las personas que trabajan hao bitualmente en el entorno. Por ejemplo, no ha de introducir una sobrecarga considerable en el sistema (si un IDS ralentiza demasiado una mquina, simplemente no se utilizar) ni generar una a a cantidad elevada de falsos positivos (deteccin de intrusiones que realmente no lo son) o de logs, ya o que entonces llegar un momento en que nadie se preocupe de comprobar las alertas emitidas por el a detector. Por supuesto (y esto puede parecer una tonter pero es algo que se hace ms a menudo a, a 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 deteccin de intrusos es o la adaptabilidad del mismo a cambios en el entorno de trabajo. Como todos sabemos, ningn u sistema informtico puede considerarse esttico: desde la aplicacin ms pequea hasta el propio a a o a n kernel de Unix, pasando por supuesto por la forma de trabajar de los usuarios (quin nos asegura e que ese engorroso procedimiento desde una desfasada l nea de rdenes maana no se realizar o n a desde una aplicacin grca, que realmente hace el mismo trabajo pero que genera unos patrones o a completamente diferentes en nuestro sistema?), todo cambia con una periodicidad ms o menos a elevada. Si nuestros mecanismos de deteccin de intrusos no son capaces de adaptarse rpidamente o a a esos cambios, estn condenados al fracaso. a Todo IDS debe adems presentar cierta tolerancia a fallos o capacidad de respuesta ante situaa ciones inesperadas; insistiendo en lo que comentbamos antes sobre el carcter altamente dinmico a a a de un entorno informtico, algunos o muchos de los cambios que se pueden producir en dicho ena torno 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 mquinas o a un intento de engao hacia el IDS; esto ultimo es especialmente cr n tico: slo hemos de pararnos a o pensar que si un atacante consigue modicar el comportamiento del sistema de deteccin y el propio o sistema no se da cuenta de ello, la intrusin nunca ser noticada, con los dos graves problemas o a que eso implica: aparte de la intrusin en s la falsa sensacin de seguridad que produce un IDS o , o que no genera ninguna alarma es un grave inconveniente de cara a lograr sistemas seguros.

4

IDSes basados en mquina a

Como antes hemos comentado, un sistema de deteccin de intrusos basado en mquina (hostbased o a IDS) es un mecanismo que permite detectar ataques o intrusiones contra la mquina sobre la que a se ejecuta. Tradicionalmente, los modelos de deteccin basados en mquina han consistido por una parte en o a la utilizacin de herramientas automticas de anlisis de logs generados por diferentes aplicaciones o a a o por el propio kernel del sistema operativo, prestando siempre especial atencin a los registros o relativos a demonios de red, como un servidor web o el propio inetd, y por otra quizs no tan a habitual como la anterior en el uso de vericadores de integridad de determinados cheros vitales para el sistema, como el de contraseas; no obstante, desde hace unos aos un tercer esquema de n n deteccin se est implantando con cierta fuerza: se trata de los sistemas de deteccin, honeypots o o a o tarros de miel. El anlisis de logs generados por el sistema (entendiendo como tales no slo a los relativos al a o ncleo, sino tambin a aquellos de aplicaciones nativas de cada Unix, como syslogd) var entre u e a diferentes clones de Unix por una sencilla razn: cada uno de ellos guarda la informacin con un o o cierto formato, y en determinados cheros, 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 sucientemente na casi todas las actividades que se llevan a cabo en el sistema, en especial aquellas que pueden suponer aunque sea remotamente una vulneracin de su seguridad; sin embargo, el problema radica en que pocos o administradores se preocupan de revisar con un m nimo de atencin esos logs, por lo que muchos o

ataques contra la mquina, tanto externos como internos, y tanto fallidos como exitosos, pasan a nalmente desapercibidos. Aqu es donde entran en juego las herramientas automticas de anlisis, a a como swatch o logcheck; a grandes rasgos, realizan la misma actividad que podr ejecutar un a shellscript convenientemente planicado que incluyera entre sus l neas algunos grep de registros sospechosos en los archivos de log. A qu entradas de estos cheros debemos estar atentos? Evidentemente, esto depende de cae da sistema y de lo que sea normal en l, aunque suelen existir registros que en cualquier mquina e a 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 mquina tenemos instalado un cortafuegos independiente del corporativo, o cualquier otro a software de seguridad uno que quizs es especialmente recomendable es PortSentry , tambin a e conviene estar atentos a los logs generados por los mismos, que habitualmente se registran en los cheros normales de auditor del sistema (syslog, messages. . . ) y que suelen contener informaa cin que con una probabilidad elevada denotan un ataque real. o Por otra parte, la vericacin de integridad de archivos se puede realizar a diferentes niveles, cada o uno de los cuales ofrece un mayor o menor grado de seguridad. Por ejemplo, un administrador puede programar y planicar un sencillo shellscript para que se ejecute peridicamente y compruebe el o propietario y el tamao de ciertos cheros como /etc/passwd o /etc/shadow; evidentemente, este n esquema es extremadamente dbil, ya que si un usuario se limita a cambiar en el archivo correse pondiente su UID de 100 a 000, este modelo no descubrir el ataque a pesar de su gravedad. Por a tanto, parece obvio que se necesita un esquema de deteccin mucho ms robusto, que compruebe o a aparte de la integridad de la informacin registrada en el inodo asociado a cada chero (fecha de o ultima modicacin, propietario, grupo propietario. . . ) la integridad de la informacin contenida o o en dicho archivo; y esto se consigue muy fcilmente utilizando funciones resumen sobre cada uno a de los cheros a monitorizar, funciones capaces de generar un hash unico para cada contenido de los archivos. De esta forma, cualquier modicacin en su contenido generar un resumen diferente, o a que al ser comparado con el original dar la voz de alarma; esta es la forma de trabajar de Tripwire, a el ms conocido y utilizado de todos los vericadores de integridad disponibles para entornos Unix. a Sea cual sea nuestro modelo de vericacin, en cualquiera de ellos debemos llevar a cabo inio cialmente un paso comn: generar una base de datos de referencia contra la que posteriormente u compararemos la informacin de cada archivo. Por ejemplo, si nos limitamos a comprobar el tao mao de ciertos cheros debemos, nada ms congurar el sistema, registrar todos los nombres y n a tamaos de los cheros que deseemos, para despus comparar la informacin que peridicamente n e o o registraremos en nuestra mquina con la que hemos almacenado en dicha base de datos; si existen a diferencias, podemos encontrarnos ante un indicio de ataque. Lo mismo suceder si registramos a funciones resumen: debemos generar un hash inicial de cada archivo contra el que comparar despus e la informacin obtenida en la mquina. Independientemente de los contenidos que deseemos regiso a trar en esa base de datos inicial, siempre hemos de tener presente una cosa: si un pirata consigue modicarla de forma no autorizada, habr burlado por completo a nuestro sistema de vericacin. a o As es vital mantener su integridad; incluso es recomendable utilizar medios de slo lectura, como , o un CD-ROM, o incluso unidades extra bles discos o disquetes que habitualmente no estarn a disponibles en el sistema, y slo se utilizarn cuando tengamos que comprobar la integridad de los o a archivos de la mquina. a Por ultimo, aunque su utilizacin no est tan extendida como la de los analizadores de logs o o e la de los vericadores de integridad, es necesario hablar, dentro de la categor de los sistemas de a deteccin de intrusos basados en mquina, de los sistemas de decepcin o honeypots. Bsicamente, o a o a estos tarros de miel son sistemas completos o parte de los mismos (aplicaciones, servicios, subentornos. . . ) diseados para recibir ciertos tipos de ataques; cuando sufren uno, los honeypots n detectan la actividad hostil y aplican una estrategia de respuesta. Dicha estrategia puede consistir desde un simple correo electrnico al responsable de la seguridad de la mquina hasta un bloqueo o a automtico de la direccin atacante; incluso muchos de los sistemas la mayor son capaces de a o a simular vulnerabilidades conocidas de forma que el atacante piense que ha tenido xito y prosiga e

con su actividad, mientras es monitorizado por el detector de intrusos. El concepto terico que est detrs de los tarros de miel es el denominado conocimiento negao a a tivo: proporcionar deliveradamente a un intruso informacin falsa pero que l considerar real o e a de nuestros sistemas, con diferentes nes: desde poder monitorizar durante ms tiempo sus a actividades, hasta despistarlo, pasando por supuesto por la simple diversin. Evidentemente, pao ra lograr engaar a un pirata medianamente experimentado la simulacin de vulnerabilidades ha n o de ser muy real, dedicando a tal efecto incluso sistemas completos (denominados mquinas de a sacricio), pero con atacantes de nivel medio o bajo dicho engao es much n simo ms sencillo: a en muchos casos basta simular la existencia de un troyano como BackOrice 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 decepcin no simulan vulnerabilidades tal y como habitualmente se suele o entender este concepto; dicho de otra forma, su objetivo no es engaar a un atacante durante n mucho tiempo, proporcionndole un subentorno en el sistema que aparente de forma muy realista a ser algo vulnerable, sino que su decepcin es bastante ms elemental: se limitan a presentar un o a aspecto (quizs deber a amos llamarle interfaz) que parece vulnerable, pero que cualquier aprendiz de pirata puede descubrir sin problemas que no es ms que un engao. Dnde est entonces la a n o a funcin de estos sistemas, denominados en ocasiones detectores de pruebas ? Por norma, su tarea o es recopilar informacin del atacante y del ataque en s por ejemplo, ya que antes hemos hablado o ; 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 e hora, la direccin origen, y los datos enviados por el atacante. En realidad, no es una simulacin o o que pueda engaar ni al pirata ms novato, pero hemos logrado el objetivo de cualquier sistema n a de deteccin de intrusos: registrar el ataque; adems, tambin se puede considerar un honeypot, o a e ya que simula un entorno vulnerable, aunque slo logre engaar a nuestro atacante durante unos o n segundos. De cualquier forma, es necesario indicar que en algunas publicaciones (como [Gra00]) se diferencia a los sistemas de decepcin completos de estos mecanismos de engao simple, aunque a o n todos se les englobe dentro del conjunto denominado honeypots. Hemos revisado en este punto las ideas ms generales de los sistemas de deteccin de intrusos a o basados en host; aunque hoy en d los que vamos a describir a continuacin, los basados en red, a o son con diferencia los ms utilizados, como veremos ms adelante todos son igualmente necesarios si a a deseamos crear un esquema de deteccin con la mxima efectividad. Se trata de niveles de proteco a cin diferentes pero que tienen un mismo objetivo: alertar de actividades sospechosas y, en algunos o casos, proporcionar una respuesta automtica a las mismas. a

5

IDSes basados en red

Los sistemas de deteccin de intrusos basados en red (networkbased IDS) son aquellos capaces de o detectar ataques contra diferentes sistemas de una misma red (en concreto, de un mismo dominio de colisin), aunque generalmente se ejecuten en uno solo de los hosts de esa red. Para lograr su o objetivo, al menos uno de los interfaces de red de esta mquina sensor trabaja en modo promiscuo, a capturando y analizando todas las tramas que pasan por l en busca de patrones indicativos de un e ataque. Cules pueden ser estos patrones identicativos de un ataque a los que estamos haciendo rea ferencia? Casi cualquiera de los diferentes campos de una trama de red tcp/ip (podemos consultar [Ste94], [Com95] o [Tan96] para conocer en profundidad el signicado y la utilidad de cada uno de ellos) puede tener un valor que, con mayor o menor probabilidad, represente un ataque real; los casos ms habituales incluyen: a Campos de fragmentacin. o Una cabecera ip contiene dieciseis bits reservados a informacin sobre el nivel de fragmentao cin del datagrama; de ellos, uno no se utiliza y trece indican el desplazamiento del fragmento o que transportan. Los otros dos bits indican o bien que el paquete no ha de ser fragmentado

por un router intermedio (df, Dont Fragment) o bien que el paquete ha sido fragmentado y no es el ultimo que se va a recibir (mf, More Fragments). Valores incorrectos de parmetros a de fragmentacin de los datagramas se han venido utilizando t o picamente para causar importantes negaciones de servicio a los sistemas y, desde hace tambin un tiempo incluso para e obtener la versin del operativo que se ejecuta en un determinado host ([Fyo98]); por ejemplo, o qu le suceder al subsistema de red implantado en el ncleo de una mquina Unix si nunca e a u a recibe una trama con el bit mf reseteado, indicando que es el ultimo de un paquete? se quedar permanentemente esperndola? y si recibe uno que en teor no est fragmentado a a a a pero se le indica que no es el ultimo que va a recibir? cmo responder el ncleo del ope o a u rativo en este caso? Como vemos, si en nuestras mquinas observamos ciertas combinaciones a de bits relacionados con la fragmentacin realmente tenemos motivos para cuanto menos o sospechar que alguien trata de atacarnos. Direccin origen y destino. o Las direcciones de la mquina que env un paquete y la de la que lo va a recibir tambin a a e son campos interesantes de cara a detectar intrusiones en nuestros sistemas o en nuestra red. No tenemos ms que pensar el trco proveniente de nuestra DMZ (y que no se trate de la a a t pica respuesta ante una peticin como las que se generan al visitar pginas web, por poner o a un ejemplo) que tenga como destino nuestra red protegida: es muy posible que esos paquetes constituyan un intento de violacin de nuestra pol o tica de seguridad. Otros ejemplos clsicos a son las peticiones originadas desde Internet y que tienen como destino mquinas de nuestra a organizacin que no estn ofreciendo servicios directos al exterior, como un servidor de bases o a de datos cuyo acceso est restringido a sistemas de nuestra red. a Puerto origen y destino. Los puertos origen y destino (especialmente este ultimo) son un excelente indicativo de acti vidades sospechosas en nuestra red. Aparte de los intentos de acceso no autorizado a servicios de nuestros sistemas, pueden detectar actividades que tambin supondrn a priori violaciones e a 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 nalidad diferente (por ejemplo, el bit syn es utilizado para establecer una nueva conexin, mientras que fin hace justo lo contrario: liberarla). o Evidentemente el valor de cada uno de estos bits ser 0 o 1, lo cual de forma aislada no suele a 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 simultneamente ser indicativa de una conexin que trata a a o 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 ms conocidos de a los ultimos aos sobre plataformas Windows de los muchos que han tenido estos entornos n estaba fundamentado bsicamente en el manejo de paquetes oob (Out Of Band): tramas con a el bit urg activado. Campo de datos. Seguramente, el campo de datos de un paquete que circula por la red es donde ms probabilia dades 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 a (por ejemplo, aquellas cuyo origen no est autorizado a alcanzar su destino o con campos e incorrectos), pero rara vez un rewall se parar a analizar el contenido de los datos transpora tados en la trama. Por ejemplo, una peticin como GET ../../../etc/passwd HTTP/1.0 o contra el puerto 80 del servidor web de nuestra empresa no se detendr en el cortafuegos, pero a muy probablemente se trata de un intento de intrusin contra nuestros sistemas. o Acabamos de ver slo algunos ejemplos de campos de una trama tcp/ip que, al presentar detero minados valores, pueden ser indicativos de un ataque; sin embargo, no todo es tan sencillo como comprobar ciertos parmetros de cada paquete que circula por uno de nuestros segmentos. Tambin a e es posible y necesario que un detector de intrusos basado en red sea capaz de noticar otros ataques

que no se pueden apreciar en una unica trama; uno de estos ataques es la presencia de peticiones que, aunque por s mismas no sean sospechosas, por su repeticin en un intervalo de tiempo ms o o a menos pequeo puedan ser indicativas de un ataque (por ejemplo, barridos de puertos horizontales n 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 nmero de or u genes que el ataque tiene por denicin. o Segn lo expuesto hasta ahora en este punto, puede parecer que los sistemas de deteccin de u o intrusos basados en red funcionan unicamente mediante la deteccin de patrones; realmente, esto o no es as en principio, un detector de intrusos basado en red puede estar basado en la deteccin : o de anomal igual que lo puede estar uno basado en mquinas. No obstante, esta aproximacin es as, a o minoritaria; aunque una intrusin generar probablemente comportamientos anormales (por ejemo a plo, un trco excesivo entre el sistema atacante y el atacado) susceptibles de ser detectados y a eliminados, con demasiada frecuencia estos sistemas no detectarn la intrusin hasta que la misma a o 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 deteccin de usos indebidos. o Para nalizar este punto dedicado a los sistemas de deteccin de intrusos basados en red es necesario o hablar de las honeynets ([Spi01]) 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 diseadas para ser comprometidas, formadas por sistemas reales de todo tipo que, una vez n penetrados, permiten capturar y analizar las acciones que est realizando el atacante para as poder a aprender ms sobre aspectos como sus tcnicas o sus objetivos. Realmente, aunque la idea general a e sea comn, existen dos grandes diferencias de diseo entre un tarro de miel y una honeynet: por u n un lado, esta ultima evidentemente es una red completa que alberga diferentes entornos de trabajo, no se trata de una unica mquina; por otro, los sistemas dentro de esta red son sistemas reales, en a 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 decepcin, sino principalmente conocer los o movimientos de un pirata en entornos semireales, de forma que aspectos como sus vulnerabilidades o sus conguraciones 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 administracin extra que una hoo neynet implica para cualquier organizacin. Por un lado, tenemos el control del ujo de los datos: o 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 mquinas, ni de nuestra a organizacin ni de cualquier otra; la red de miel ha de permanecer perfectamente controlada, y por o supuesto aislada del resto de los segmentos de nuestra organizacin. En segundo lugar, otro aspecto o bsico es la captura de datos, la monitorizacin de las actividades que un atacante lleva a cabo en la a o honeynet. Recordemos que nuestro objetivo principal era conocer los movimientos de la comunidad pirata para poder extrapolarlos a sistemas reales, por lo que tambin es muy importante para el e correcto funcionamiento de una honeynet una correcta recogida de datos generados por el atacante: ha de ser capturada toda la informacin posible de cada accin, de una forma poco agresiva (esto o o es, sin tener que realizar grandes cambios en cada uno de los sistemas) y por supuesto sin que el atacante se entere. Adems (muy importante), estos datos recogidos nunca se han de mantener a dentro del per metro de la honeynet, ya que si fuera as cualquier pirata podr destruirlos con una a probabilidad demasiado elevada. El concepto de honeynet es relativamente nuevo dentro del mundo de la seguridad y, en concreto, de los sistemas de deteccin de intrusos; a pesar de ello, se trata de una idea muy interesante que o presumiblemente va a extenderse de una forma ms o menos rpida (no todo lo rpida que nos gusa a a tar ya que implantar y explotar una honeynet no es algo ni trivial, ni mucho menos rpido); cada a, a d ms, las herramientas de seguridad no se conforman con detectar problemas conocidos, sino que a a tratan de anticiparse a nuevas vulnerabilidades que an no se han publicado pero que pueden estar u

y de hecho estn presentes en multitud de sistemas. Conocer cuanto antes cualquier avance de a la comunidad underground es algo vital si queremos lograr este objetivo. Como antes hemos comentado, los sistemas de deteccin de intrusos basados en red, de los que o hemos hablado a lo largo de este punto, son con diferencia los ms utilizados actualmente en sisa temas en explotacin; no obstante, como casi cualquier herramienta relacionada con la seguridad, o estos sistemas no son ninguna panacea, y su implantacin ha de verse complementada con una o correcta conguracin de elementos como nuestro cortafuegos corporativo o, por supuesto, los siso temas de deteccin basados en host. Veremos ms adelante, en este mismo cap o a tulo, que ambos tipos de IDSes son igualmente necesarios en nuestro entorno de trabajo.

6

Deteccin de anomal o as

Desde que en 1980 James P. Anderson propusiera la deteccin de anomal como un mtodo vlido o as e a para detectar intrusiones en sistemas informticos ([And80]), la l a nea de investigacin ms activa o a (esto es, la ms estudiada, pero no por ello la ms extendida en entornos reales) es la denominada a a Anomaly Detection IDS, IDSes basados en la deteccin de anomal La idea es a priori muy inteo as. resante: estos modelos de deteccin conocen lo que es normal en nuestra red o nuestras mquinas o a a lo largo del tiempo, desarrollando y actualizando conjuntos de patrones contra los que comparar los eventos que se producen en los sistemas. Si uno de esos eventos (por ejemplo, una trama procedente de una mquina desconocida) se sale del conjunto de normalidad, automticamente se a a cataloga como sospechoso. Los IDSes basados en deteccin de anomal se basan en la premisa de que cualquier ataque o o as intento de ataque implica un uso anormal de los sistemas ([Ko96], [KS94]. . . ). Pero, cmo puede o un sistema conocer lo que es y lo que no es normal en nuestro entorno de trabajo? Para conseguirlo, existen dos grandes aproximaciones ([BB99]): o es el sistema el que es capaz de aprenderlo por s mismo (basndose por ejemplo en el comportamiento de los usuarios, de sus procesos, del trco a a de nuestra red. . . ) o bien se le especica al sistema dicho comportamiento mediante un conjunto de reglas. La primera de estas aproximaciones utiliza bsicamente mtodos estad a e sticos (medias, varianzas. . . ), aunque tambin existen modelos en los que se aplican algoritmos de aprendizaje e automtico; la segunda aproximacin consiste en especicar mediante un conjunto de reglas los a o perles de comportamiento habitual basndose en determinados parmetros de los sistemas (con a a la dicultad aadida de decidir cules de esos parmetros que con mayor precisin delimitan los n a a o comportamientos intrusivos). En el primero de los casos (el basado en mtodos estad e sticos), el detector observa las actividades de los elementos del sistema, activos sujetos , pasivos objetos o ambos, y genera para cada uno de ellos un perl que dene su comportamiento; dicho perl es almacenado en el sistema, y se actualiza con determinada frecuencia envejeciendo la informacin ms antigua y priorizando la o a ms fresca. El comportamiento del usuario en un determinado momento se guarda temporalmente a en otro perl, denominado perl actual (current prole), y a intervalos regulares se compara con el almacenado previamente en busca de desviaciones que puedan indicar una anomal a. En [JV93] se denen diferentes tipos de datos o medidas que pueden ser utiles en la elaboracin de o estos perles: 1. Intensidad de la actividad. Reejan el ratio de progreso de la actividad en el sistema, para lo cual recogen datos a intervalos muy pequeos t n picamente entre un minuto y una hora . Estas medidas detectan rfagas de comportamiento (por ejemplo, una excesiva generacin de a o peticiones de entrada/salida en un cierto intervalo) que en espacios de tiempo ms amplios a no podr ser detectadas. an 2. Numricas. Se trata de medidas de la actividad cuyo resultado se puede representar en forma e de valor numrico, como el nmero de cheros le e u dos por cierto usuario en una sesin o la o cantidad de veces que ese usuario se ha equivocado al teclear su contrasea de acceso al n sistema.

3. Categricas. Las medidas categricas son aquellas cuyo resultado es una categor individual, o o a y miden la frecuencia relativa o la distribucin de una actividad determinada con respecto a o otras actividades o categor por ejemplo, cual es la relacin entre la frecuencia de acceso a as; o un determinado directorio del sistema en comparacin con la de acceso a otro. Seguramente o la palabra categor no es la ms afortunada (por lo menos, no la ms clara), ya que bajo a a a este trmino se pueden englobar tanto a objetos (por ejemplo, cheros) como a eventos (por e ejemplo, llamadas a la funcin crypt()) del sistema; esta denicin genrica puede resultar o o e ms sencilla si distinguimos entre categor globales e individuales: en castellano plano, poa as demos entender las categor globales como acciones muy genricas dentro de un entorno, as e mientras que las categor individuales ser la particularizacin para un elemento determias an o nado del sistema. As una categor global puede ser la formada por el conjunto de accesos , a remotos a la mquina, mientras que una individual ser la formada por los accesos desde una a a determinada ubicacin f o sica. 4. Distribucin de registros de auditor Esta medida analiza la distribucin de las actividao a. o des generadas en un pasado reciente basndose en los logs generados por las mismas; dicho a anlisis se realiza de forma ponderada, teniendo ms peso las actividades ms recientes, y es a a a comparado con un perl de actividades habituales previamente almacenado, de forma que permite detectar si en un pasado reciente se han generado eventos inusuales. La segunda aproximacin a la que antes hemos hecho referencia era la consistente en indicar mediano te un conjunto de reglas el comportamiento habitual del sistema; suele ser denominada deteccin o de anomal basada en especicaciones (specicationbased anomaly detection), y fu propuesta as e y desarrollada inicialmente por Calvin Cheuk Wang Ko y otros investigadores de la Universidad de California en Davis, durante la segunda mitad de los noventa ([Ko96], [CKL97]. . . ). La idea en la que se sustentan los sistemas de deteccin de anomal basados en especicaciones es que o as se puede describir el comportamiento deseable (entendiendo por deseable el comportamiento normal) de cualquier programa cuya seguridad sea cr tica; esta descripcin se realiza en base a o una especicacin de seguridad mediante gramticas, y se considera una violacin de la seguridad o a o al menos en principio a las ejecuciones de dichos programas que violen su respectiva especicacin. o Para ver ms claramente el concepto de la deteccin de anomal basada en especicaciones, a o as podemos pensar en la ejecucin de un programa que se puede considerar cr o tico, por ser privilegiado: /bin/passwd. Si conseguimos diferenciar las diferentes ejecuciones de esta orden que se pueden considerar habituales (por ejemplo, cuando un usuario cambia su contrasea sin problen mas, cuando se equivoca, cuando el sistema no le deja cambiarla por los motivos t picos es dbil, e hace poco que la cambi. . . ), podr o amos especicar formalmente cada una de estas secuencias de operacin. De esta forma, cada vez que un usuario invoque a /bin/passwd, el sistema de deteccin o o monitorizar las operaciones que esa llamada genere, y considerar una intrusin a cualquiera que a a o no sea habitual. La idea de los sistemas de deteccin de intrusos basados en la deteccin de anomal es realo o as mente atractiva; no obstante, existen numerosos problemas a los que estos mecanismos tratan de hacer frente. En primer lugar podemos pararnos a pensar en las dicultades que existen a la hora de aprender o simplemente especicar lo habitual: si alguien piensa que por ejemplo obtener un patrn de trco normal en una red es fcil, se equivoca; quizs establecer un conjunto de procesos o a a a habituales en una unica mquina resulte menos complicado, pero tampoco se trata de una tarea a trivial. Adems, conforme aumentan las dimensiones de los sistemas (redes con un gran nmero de a u mquinas interconectadas, equipos con miles de usuarios. . . ) estos se hacen cada vez ms aleatorios a a e impredecibles. Otro gran problema de los sistemas basados en deteccin de anomal radica en la pol o as tica de aprendizaje que stos sigan ([Ran98]); si se trata de esquemas donde el aprendizaje es rpido, un e a intruso puede generar eventos para conseguir un modelo distorsionado de lo normal antes de que el responsable humano de los sistemas se percate de ello, de forma que el IDS no llegue a detectar un ataque porque lo considera algo habitual. Si por el contrario el aprendizaje es lento, el IDS considerar cualquier evento que se aleje m a nimamente de sus patrones como algo anmalo, generando o un gran nmero de falsos positivos (falsas alarmas), que a la larga harn que los responsables de u a

los sistemas ignoren cualquier informacin proveniente del IDS, con los evidentes riesgos que esto o implica.

7

Deteccin de usos indebidos o

Dentro de la clasicacin de los sistemas de deteccin de intrusos en base a su forma de actuar, la o o segunda gran familia de modelos es la formada por los basados en la deteccin de usos indebidos. o Este esquema se basa en especicar de una forma ms o menos formal las potenciales intrusiones a que amenazan a un sistema y simplemente esperar a que alguna de ellas ocurra; para conseguirlo existen cuatro grandes aproximaciones ([Ko96]): los sistemas expertos, los anlisis de transicin a o entre estados, las reglas de comparacin y emparejamiento de patrones (pattern matching) y la o deteccin basada en modelos. o Los primeros sistemas de deteccin de usos indebidos, como NIDES ([L+ 92]), se basaban en los o sistemas expertos para realizar su trabajo; en ellos las intrusiones se codican como reglas de la base de conocimiento del sistema experto, de la forma genrica ifthen (if condicion then accion). e Cada una de estas reglas puede detectar eventos unicos o secuencias de eventos que denotan una potencial intrusin, y se basan en el anlisis generalmente en tiempo real de los registros de o a auditor proporcionados por cualquier sistema Unix: esta es una de las principales ventajas de los a sistemas expertos, el hecho de que el mecanismo de registro dentro de Unix venga proporcionado de serie, ya que de esta forma el sistema de deteccin trabaja siempre por encima del espacio del o sistema operativo, algo que facilita enormemente su integracin dentro de diferentes clones de Unix. o Podemos pensar en un caso real que nos ayude a comprender el funcionamiento de los sistemas expertos a la hora de detectar intrusiones; el t pico ejemplo es la deteccin de un mismo usuario o conectado simultneamente desde dos direcciones diferentes. Cada vez que un usuario se autentica a correctamente en el sistema, cualquier Unix genera una l nea de registro que se guarda en el chero de log correspondiente; as al conectar a un servidor Linux Slackware v ssh, se registra el evento , a de esta forma: May 27 03:08:27 rosita sshd[5562]: User toni, coming from anita, authenticated. Al leer este registro, un sistema experto comprobar si el usuario toni ya tiene una sesin abierta a o desde una mquina diferente de anita; si esta condicin se cumple (recordemos la forma genrica a o e de las reglas del sistema experto, ifthen) se realizar la accin denida en la regla correspondiente, a o por norma generar una alarma dirigida al responsable de seguridad del sistema. La segunda implementacin de los sistemas de deteccin de usos indebidos era la basada en los o o anlisis de transicin entre estados ([PK92]); bajo este esquema, una intrusin se puede contemplar a o o como una secuencia de eventos que conducen al atacante desde un conjunto de estados inicial a un estado determinado, representando este ultimo una violacin consumada de nuestra seguridad. o Cada uno de esos estados no es ms que una imagen de diferentes parmetros del sistema en un a a momento determinado, siendo el estado inicial el inmediatamente posterior al inicio de la intrusin, o y el ultimo de ellos el resultante de la completitud del ataque; la idea es que si conseguimos identi car los estados intermedios entre ambos, seremos capaces de detener la intrusin antes de que se o haga efectiva. Sin duda el sistema de deteccin basado en el anlisis de transicin entre estados ms conocido o a o a es ustat ([Ilg92]), basado en stat ([Por92]). Este modelo fu desarrollado inicialmente sobre Sue nOS 4.1.1 (en la actualidad est portado a Solaris 2), y utiliza los registros de auditor generados a a por el C2 Basic Security Module de este operativo. En ustat, estos registros del c2-bsm son transformados a otros de la forma , representando cada uno de ellos un evento de la forma el sujeto S realiza la accin A sobre el objeto O; a su vez, cada elemento de la terna anterior est o a formado por diferentes campos que permiten identicar un vocamente el evento representado. El sistema de deteccin utiliza adems una base de datos realmente, se trata de simples cheros o a planos formada principalmente por dos tablas, una donde se almacenan las descripciones de los diferentes estados (SDT, State Description Table) y otra en la que se almacenan las transiciones

entre estados que denotan un potencial ataque (SAT, Signature Action Table). Cuando ustat registre una sucesin determinada de eventos que representen un ataque entrar en juego el motor o a de decisiones, que emprender la accin que se le haya especicado (desde un simple mensaje en a o consola informando de la situacin hasta acciones de respuesta automtica capaces de interferir en o a tiempo real con la intrusin). o La tercera implementacin que hab o amos comentado era la basada en el uso de reglas de comparacin y emparejamiento de patrones o pattern matching ([SG91], [KS94]); en ella, el detector se o basa en la premisa de que el sistema llega a un estado comprometido cuando recibe como entrada el patrn de la intrusin, sin importar el estado en que se encuentre en ese momento. Dicho de o o otra forma, simplemente especicando patrones que denoten intentos de intrusin el sistema puede o ser capaz de detectar los ataques que sufre, sin importar el estado inicial en que est cuando se e produzca dicha deteccin, lo cual suele representar una ventaja con respecto a otros modelos de los o que hemos comentado. Actualmente muchos de los sistemas de deteccin de intrusos ms conocidos (por poner un ejemplo, o a podemos citar a snort o RealSecure) estn basados en el pattern matching. Utilizando una base a de datos de patrones que denotan ataques, estos programas se dedican a examinar todo el trco a que ven en su segmento de red y a comparar ciertas propiedades de cada trama observada con las registradas en su base de datos como potenciales ataques; si alguna de las tramas empareja con un patrn sospechoso, automticamente se genera una alarma en el registro del sistema. En el punto o a 8.2 hablaremos con ms detalle del funcionamiento de snort, uno de los sistemas de deteccin de a o intrusos basados en red ms utilizado en entornos con requisitos de seguridad media. a Por ultimo, tenemos que hablar de los sistemas de deteccin de intrusos basados en modelos o ([GL91]); se trata de una aproximacin conceptualmente muy similar a la basada en la transicin o o entre estados, en el sentido que contempla los ataques como un conjunto de estados y objetivos, pero ahora se representa a los mismos como escenarios en lugar de hacerlo como transiciones entre estados. En este caso se combina la deteccin de usos indebidos con una deduccin o un razonao o miento que concluye la existencia o inexistencia de una intrusin; para ello, el sistema utiliza una o base de datos de escenarios de ataques, cada uno de los cuales est formado por una secuencia a de eventos que conforman el ataque. En cada momento existe un subconjunto de esos escenarios, denominado de escenarios activos, que representa los ataques que se pueden estar presentando en el entorno; un proceso denominado anticipador analiza los registros de auditor generados por el a sistema y obtiene los eventos a vericar en dichos registros para determinar si la intrusin se est o o a no produciendo (realmente, al ser esos registros dependientes de cada sistema Unix, el anticipador pasa su informacin a otro proceso denominado planner, que los traduce al formato de auditor o a utilizado en cada sistema). El anticipador tambin actualiza constantemente el conjunto de escenae rios activos, de manera que este estar siempre formado por los escenarios que representan ataques a posibles en un determinado momento y no por la base de datos completa. Hasta hace poco tiempo no exist sistemas de deteccin de intrusos basados en modelos funan o cionando en sistemas reales ([Kum95]), por lo que era dif determinar aspectos como su eciencia cil a la hora de detectar ataques. En 1998 se present nstat ([Kem98]), una extensin de ustat o o (del cual hemos hablado antes) a entornos distribuidos y redes de computadores, y en el que se combina el anlisis de transicin entre estados con la deteccin de intrusos basada en modelos. A a o o pesar de todo, este modelo es el menos utilizado a la hora de detectar ataques y efectuar respuestas automticas ante los mismos, especialmente si lo comparamos con los basados en la comparacin y a o emparejamiento de patrones. Los IDSes basados en la deteccin de usos indebidos son en principio ms robustos que los bao a sados en la deteccin de anomal al conocer la forma de los ataques, es tericamente extrao que o as: o n generen falsos positivos (a no ser que se trate de un evento autorizado pero muy similar al patrn o de un ataque); es necesario recalcar el matiz tericamente, porque como veremos ms adelante, la o a generacin de falsos positivos es un problema a la hora de implantar cualquier sistema de deteccin. o o No obstante, en este mismo hecho radica su debilidad: slo son capaces de detectar lo que conocen, o de forma que si alguien nos lanza un ataque desconocido para el IDS ste no nos noticar ningn e a u

'

# $

h h !

4

INet&

- Router" %

$

1 b b

b b b

? b b

'

FWb b b

b

b

-

LAN

&

h

h % 3

2

Figura 1: Puntos clsicos de defensa entre un atacante y un objetivo. a problema; como ya dijimos, es algo similar a los programas antivirus, y de igual manera que cada cierto tiempo es conveniente (en MS-DOS y derivados) actualizar la versin del antivirus usado, o tambin es conveniente mantener al d la base de datos de los IDSes basados en deteccin de usos e a o indebidos. An as seremos vulnerables a nuevos ataques. u , Otro grave problema de los IDSes basados en la deteccin de usos indebidos es la incapacidad o para detectar patrones de ataque convenientemente camuados. Volviendo al ejemplo de los antivirus, pensemos en un antivirus que base su funcionamiento en la bsqueda de cadenas virales: u lo que bsicamente har ese programa ser buscar cadenas de cdigo hexadecimal pertenecientes a a a a o determinados virus en cada uno de los archivos a analizar, de forma que si encuentra alguna de esas cadenas el software asumir que el chero est contaminado. Y de la misma forma que un virus a a puede ocultar su presencia simplemente cifrando esas cadenas (por ejemplo de forma semialeatoria utilizando eventos del sistema, como el reloj), un atacante puede evitar al sistema de deteccin de o intrusos sin ms que insertar espacios en blanco o rotaciones de bits en ciertos patrones del ataque; a aunque algunos IDSes son capaces de identicar estas transformaciones en un patrn, otros muchos o no lo hacen.

8

Implantacin real de un IDS o

Vamos a tratar ahora de denir unas pautas para crear un sistema distribuido de deteccin de o intrusos, capaz de generar respuestas automticas, alarmas, o simplemente logs a distintos niveles a de nuestra arquitectura de red, formando lo que se suele denominar un modelo de seguridad de c rculos concntricos ([ISV95]). Para ello, imaginemos un pirata externo a nuestra organizacin que e o intenta atacar una determinada mquina, y pensemos en el primer punto en el que podemos detectar a dicho ataque y actuar sobre l: ah es donde deberemos implantar el primer sensor, ya que se trata e de la primera barrera que estamos interponiendo entre el atacante y su objetivo; ese primer punto no es otro que nuestro router de salida a Internet, el marcado como 1 en la gura 1 (pido perdn por o mi estilo art stico). No podemos entrar aqu a tratar detalles sobre las capacidades de deteccin de o intrusos de productos como los routers Cisco y su IOS, o de otros elementos fcilmente integrables a con esta electrnica de red, como NetRanger (tambin de Cisco), ya que se trata de sistemas que o e poco tienen que ver con Unix, y que en muchos casos no controlamos nosotros directamente sino una tercera organizacin (por ejemplo, Telefnica), a pesar de que tengan incluso una direccin o o o IP perteneciente a nuestra red. En las pginas web de los distintos fabricantes se puede encontrar a

informacin muy util sobre sus productos orientados a la deteccin y respuesta ante ataques. o o

8.1

IDS en el cortafuegos

Volviendo a la gura 1, el segundo punto que separar al atacante de su objetivo (es decir, nos a proteger de l) ser nuestro cortafuegos corporativo. Este elemento, sobre el que probablemente a e a ya tendremos pleno control, estar formado por uno o varios sistemas Unix con un software de a ltrado de paquetes ejecutndose sobre ellos, y es aqu donde vamos a implantar el primer esquema a de deteccin de intrusos y respuesta automtica ante ataques (esta respuesta ser habitualmente el o a a bloqueo de la direccin atacante en el propio rewall). o Para decidir qu tipos de ataques debemos detectar y bloquear en nuestro cortafuegos debemos e pararnos a pensar con qu informacin trabaja habitualmente este sistema; cualquier rewall lo e o har al menos con los cinco elementos que denen una conexin bajo la pila tcp/ip: direccin a o o origen, direccin destino, puerto origen, puerto destino y protocolo. De estos cinco, quizs los dos o a menos importantes (de cara a detectar ataques) son quizs el protocolo utilizado y el puerto oria gen de la conexin; por tanto, son los otros tres elementos los que nos ayudarn en la constitucin o a o de nuestro IDS y los que nos facilitarn el poder lanzar una respuesta automtica contra el atacante. a a Conociendo las direcciones origen y destino y el puerto destino de una conexin ya podemos deo tectar cierto tipo de ataques; quizs el ejemplo ms habitual son los escaneos de puertos, tanto a a horizontales como verticales, que se lanzan contra nuestros sistemas. La tcnica de deteccin de e o estos ataques se dene perfectamente en [Nor99]: est basada por el momento en comprobar X a eventos de inters dentro de una ventana de tiempo Y. As podemos analizar en nuestro cortae , fuegos cundo una misma direccin origen accede a un determinado puerto de varios destinos en a o menos de un cierto tiempo umbral (escaneo horizontal) o cuando accede a diferentes puertos bien conocidos de un mismo sistema tambin en menos de ese tiempo umbral (escaneo vertical). Por e qu el hecho de jarnos slo en puertos bien conocidos en este ultimo caso? Muy sencillo: muchas e o aplicaciones abren muchos puertos destino, generalmente altos (por encima del 1024), en una unica sesin de funcionamiento, por lo que esa sesin ser identicada por el cortafuegos como un escaneo o o a vertical cuando realmente no lo es (y si adems en nuestro esquema de respuesta automtica decidia a mo bloquear la IP atacante, causar amos una grave negacin de servicio contra usuarios leg o timos de nuestros sistemas). Una tcnica alternativa que con frecuencia suele ser utilizada con bastante efectividad para dee tectar escaneos verticales consiste en vigilar del acceso a determinados puertos de los sistemas protegidos por el rewall, acceso que con toda probabilidad representar un intento de violacin a o de nuestras pol ticas de seguridad. No nos engaemos: si alguien trata de acceder desde fuera n del segmento protegido a puertos como echo (7/tcp,udp), systat (11/tcp), netstat (15/tcp), tcpmux (1/tcp) o el desfasado uucp (540/tcp), lo ms probable es que se trate de una persona que a no lleva muy buena intencin con respecto a nuestras mquinas. Seguramente estar lanzando un o a a escaneo vertical contra nosotros, aunque a veces tambin se puede tratar de un simple curioso que e trata de comprobar nuestro grado de seguridad para lanzar un ataque posterior: evidentemente, si alguien tiene abierto un puerto de los citados anteriormente, denota una escasa preocupacion por su seguridad, por lo que casi con toda certeza se puede intuir que tendr agujeros importantes en a alguna de sus mquinas. a Otro tipo de ataques que tambin son fcilmente detectables vigilando el acceso a determinados e a puertos de nuestros sistemas protegidos son aquellos que detectan la presencia o la comprobacin o de la presencia de diferentes troyanos como NetBus o BackOrice: si en el rewall se detecta trco dirigido a puertos como 12345, 12346 o 20034 (tcp) o como 31337 (udp), sin duda se trata a de un atacante que est tratando de aprovechar estos troyanos; en muchos casos la mayor se a a tratar de escaneos horizontales en busca de mquinas contaminadas a lo largo de toda o gran parte a a de nuestra clase C. En la tabla 1 se muestran algunos de los puertos a los que conviene estar atentos a la hora de disear una pol n tica de deteccin de intrusos en nuestro cortafuegos; por supuesto, exiso ten muchos ms que pueden ser considerados sospechosos, pero en cualquier caso siempre conviene a ser muy precavido con su monitorizacin ya que algunos de ellos pueden ser usados por usuarios o

Servicio ttymux echo systat daytime netstat finger who uucp NetBus NetBus NetBus BackOrice HackaTack HackaTack

Puerto 1 7 7 13 15 79 513 540 12345 12346 20034 31337 31789 31790

Protocolo tcp tcp/udp tcp tcp/udp tcp tcp udp tcp tcp tcp tcp udp udp udp

Ataque Escaneo horizontal Escaneo horizontal Escaneo horizontal Escaneo horizontal Escaneo horizontal Escaneo horizontal/vertical Escaneo horizontal Escaneo horizontal/vertical Troyano Troyano Troyano Troyano Troyano Troyano

Tabla 1: Algunos puertos a monitorizar en un rewall l citos a los que causar amos una grave negacin de servicio si, por ejemplo, les bloqueramos el o a acceso a nuestra red a causa de un falso positivo. Todos sabemos que el cortafuegos es algo vital para proteger a nuestros sistemas, pero lamentablemente es un elemento muy limitado a la hora de detectar ataques. Por ejemplo, imaginemos la siguiente situacin: un atacante decide comprobar si nuestro servidor web corporativo tiene algn o u tipo de vulnerabilidad que le pueda ayudar en un ataque contra la mquina; algo muy comn hoy a u en d ya que quizs uno de los mayores daos que puede sufrir la imagen de una empresa esa, a n pecialmente si est relacionada con las nuevas tecnolog es una modicacin de su pgina web a as o a principal. Es muy probable que ese pirata lanzara en primer lugar un escaneo de puertos vertical contra el servidor, para comprobar si aparte del servicio http se est ofreciendo algn otro; si a u todo es correcto, el puerto de web ser el unico abierto en el cortafuegos corporativo, cortafuegos a que adems detectar el ataque contra la mquina y bloquear, al menos temporalmente, cuala a a a quier acceso de la direccin atacante. Un punto a nuestro favor, pero el pirata no tiene ms que o a colgar el mdem y volver a llamar a su proveedor para conseguir otra IP, con lo cual obtiene de nueo vo acceso a nuestro servicio http y adems ya sabe que el unico puerto abierto en la mquina es ese. a a Ahora ese atacante no necesita ningn tipo de escaneo de puertos adicional; puede seguir varios u caminos para atacarnos, pero sin duda el ms lgico y fcil es tratar de localizar vulnerabilidades en a o a el servidor web de nuestra organizacin. Para ello puede lanzar un escaneador de vulnerabilidades o en servidores web1 contra la mquina, escaneador que no generar ninguna alerta en el cortafuegos; a a al n y al cabo, lo unico que hacen estos programas es lanzar peticiones al puerto 80 de nuestro servidor web, algo que el rewall no contempla como sospechoso: para l, no hay diferencia entre e un analizador de CGIs y peticiones normales a nuestras pginas. a Parece por tanto evidente que nuestra primera barrera de deteccin de intrusos es realmente util, o pero tambin insuciente frente a determinados ataques; entonces entra en juego el segundo nivel e de nuestro sistema de deteccin de intrusos, el ubicado en el segmento de red en el dominio de o colisin en el que se encuentra el host que estamos tratando de proteger. o

8.2

IDS en la red: snort

snort ([Roe99]) es un snier capaz de actuar como sistema de deteccin de intrusos en redes de o trco moderado; su facilidad de conguracin, su adaptabilidad, sus requerimientos m a o nimos (funciona en diferentes Unices, incluyendo un simple PC con Linux, Solaris o cualquier BSD gratuito),1 Generalmente se les denomina CGI Scanners, aunque no slo comprueban la presencia de CGIs vulnerables, sino o que tambin detectan errores de conguracin, versiones de los demonios, etc. e o

y sobre todo su precio (se trata de un software completamente gratuito que podemos descargar desde su pgina ocial en INet, http://www.snort.org/) lo convierten en una ptima eleccin en a o o multitud de entornos, frente a otros sistemas como NFR (Network Flight Recorder) o ISS RealSecure que, aunque quizs sean ms potentes, son tambin mucho ms pesados e innitamente ms caros. a a e a a Para instalar un sistema de deteccin de intrusos basado en snort en primer lugar necesitamos o evidentemente este programa, que podemos descargar desde su pgina web. Adems, para coma a pilarlo correctamente es necesario disponer de las librer libpcap, un interfaz para tratamiento as de paquetes de red desde espacio de usuario, y es recomendable tambin (aunque no obligatorio) e instalar Libnet, librer para la construccin y el manejo de paquetes de red. Con este software a o correctamente instalado en nuestro sistema, la compilacin de snort es trivial. o Si volvemos a la clasicacin de IDSes que hemos presentado al principio de este cap o tulo, podemos clasicar a snort como un sistema basado en red (se monitoriza todo un dominio de colisin) y que o funciona mediante deteccin de usos indebidos. Estos usos indebidos o cuanto menos sospechosos o se reejan en una base de datos formada por patrones de ataques; dicha base de datos se puede descargar tambin desde la propia pgina web de snort, donde adems se pueden generar bases de e a a patrones a medida de diferentes entornos (por ejemplo, ataques contra servidores web, intentos de negaciones de servicio, exploits. . . ). El archivo que utilicemos en nuestro entorno ser la base para a el correcto funcionamiento de nuestro sistema de deteccin de intrusos. o Una vez hemos compilado e instalado correctamente el programa llega el momento de ponerlo en funcionamiento; y es aqu donde se produce al menos inicialmente uno de los errores ms a graves en la deteccin de intrusos. Por lgica, uno tiende a pensar que el sensor proporcionar o o a mejores resultados cuantos ms patrones de ataques contenga en su base de datos; nada ms lejos a a de la realidad. En primer lugar, es muy probable que no todos los ataques que snort es capaz de detectar sean susceptibles de producirse en el segmento de red monitorizado; si situamos el sensor en una zona desmilitarizada donde unicamente ofrecemos servicio de web, qu inters tiene tratar e e de detectar ataques contra DNS? Lo lgico es que las pol o ticas implementadas en nuestro cortafuegos ni siquiera dejen pasar trco hacia puertos que no sean los de los servidores web pero, incluso a en caso de que el potencial ataque se produjera entre mquinas del propio segmento, hemos de a evaluar con mucho cuidado si realmente vale la pena sobrecargar la base de datos con patrones que permitan detectar estos ataques. Evidentemente, cuanta ms azcar ms dulce, pero si el sensor ha a u a de analizar todo el trco, quizs mientras trata de decidir si un paquete entre dos mquinas protea a a gidas se adapta a un patrn estamos dejando pasar tramas provenientes del exterior que realmente o representan ataques: hemos de tener presente que el snier no detendr el trco que no sea capaz a a de analizar para hacerlo ms tarde, sino que simplemente lo dejar pasar. As debemos introducir a a , en la base de patrones de ataques los justos para detectar actividades sospechosas contra nuestra red. En segundo lugar, pero no menos importante, es necesario estudiar los patrones de trco que a circulan por el segmento donde el sensor escucha para detectar falsos positivos y, o bien recongurar la base de datos, o bien eliminar los patrones que generan esas falsas alarmas. Aunque suene algo crudo, si un patrn nos genera un nmero considerable de falsos positivos, debemos o u plantearnos su eliminacin: simplemente no podremos decidir si se trata de verdaderas o de falsas o alarmas. Esto es especialmente cr tico si lanzamos respuestas automticas contra las direcciones a atacantes (por ejemplo, detener todo su trco en nuestro rewall): volviendo al ejemplo de la a zona desmilitarizada con servidores web, podemos llegar al extremo de detener a simples visitantes de nuestras pginas simplemente porque han generado falsos positivos; aunque en un entorno de a alta seguridad quizs vale la pena detener muchas acciones no dainas con tal de bloquear tambin a n e algunos ataques (aunque constituir una negacin de servicio en toda regla contra los usuarios que a o hacen uso leg timo de nuestros sistemas), en un entorno normal de produccin esto es impensable. o Seguramente ser ms provechoso detectar y detener estos ataques por otros mecanismos ajenos al a a sensor. En resumen, hemos de adaptar a nuestro entorno de trabajo, de una forma muy na, la base de datos de patrones de posibles ataques. Quizs valga la pena perder tiempo el tiempo que sea a necesario en esta parte de la implantacin, ya que eso nos ahorrar despus muchos anlisis de falo a e a

sas alarmas y, por qu negarlo, algn que otro susto; una vez tengamos todo congurado, podemos e u utilizar el siguiente script para lanzar snort de forma automtica al arrancar el sistema (Solaris): a anita:~# cat /etc/init.d/snort #!/sbin/sh # # Instalacion: # # cp /etc/init.d/snort # # chmod 744 /etc/init.d/snort # # chown root:sys /etc/init.d/snort # # ln /etc/init.d/snort /etc/rc2.d/S99snort # # Directorio de log DIRLOG=/var/log/snort # Fichero de reglas RULES=/usr/local/security/snort.conf # Ejecutable SNORT=/usr/local/security/snort # Interfaz IF=hme0 case "$1" in start) if [ ! -d "$DIRLOG" ]; then mkdir -p "$DIRLOG" fi if [ ! -r "$RULES" ]; then echo "No puedo leer el fichero de patrones..." exit -1 fi if [ ! -x "$SNORT" ]; then echo "No encuentro el ejecutable..." exit -1 fi $SNORT -l $DIRLOG -c $RULES -i $IF -N -D ;; stop) if [ ! -r "/var/run/snort_$IF.pid" ]; then echo "No puedo obtener el PID..." exit -1 fi kill -TERM cat /var/run/snort_$IF.pid ;; *) echo "Usage: $0 { start | stop }" exit 1 esac exit 0 anita:~# Con el sensor y sus patrones correctamente congurados ya estamos listos para poner en funcionamiento nuestro sistema de deteccin de intrusos. Seguramente hasta ahora no hemos tenido muchos o problemas con el IDS; no obstante, a partir de ahora las cosas se empiezan a complicar un poco, ya que comienza la segunda parte, la del tratamiento de la informacin que nuestro sensor nos va o a proporcionar. Y es que desde este momento el sistema de deteccin va a empezar a funcionar y a o generar logs con noticaciones de posibles ataques, o cuanto menos de actividades sospechosas; es hora de decidir cosas como dnde situar al sensor, qu hacer ante la generacin de un evento en el o e o

mismo, cmo procesar la informacin recibida, o simplemente cundo rotar los logs generados. o o a El ultimo de los problemas planteados realmente tiene fcil solucin; cundo rotar los logs que a o a snort genera? La respuesta es muy sencilla: depende. Depende de la cantidad de informes generados en nuestro sensor, depende de la frecuencia con la que debamos realizar informes de los ataque sufridos, depende de la implementacin elegida para ejecutar respuestas automticas ante o a un ataque (si las ejecutamos), etc. En denitiva, la rotacin correcta de unos logs es algo que se o debe estudiar y planicar para cada entorno concreto, no se puede dar un periodo estricto que se aplique siempre porque ser sin duda errneo. No obstante, una idea que nos puede ayudar en la a o toma de esta decisin es la siguiente: rotaremos los logs cuando los hayamos procesado y extra o do de ellos la informacin que nos pueda interesar para proteger nuestro entorno. o snort genera logs en el directorio /var/log/snort/ si no le indicamos lo contrario (podemos hacerlo con la opcin -l del programa). En ese directorio encontraremos un chero denominado o alert con las actividades que se vayan registrando, y, si no hubiramos especicado la opcin -N e o al arrancar el programa, una serie de subdirectorios cuyos nombres son las direcciones IP de las mquinas de las que se detecta alguna actividad (es el denominado packet logging). Como nosoa tros lo que buscamos es bsicamente la generacin de alarmas, independiente del packet logging, no a o necesitamos generar estos directorios (aunque nada nos impide hacerlo). El siguiente shellscript planicado convenientemente con crontab (si lo ejecutamos ms de una a vez durante el d quizs nos interese anar la variable $FECHA) puede ser utilizado para realizar la a a rotacin del archivo de alarmas generado por snort: o anita:~# cat /usr/local/security/rotalog #!/bin/sh # # Directorio de log DIRLOG=/var/log/snort # Fecha (DD/MM/YY) FECHA=date +%d.%m.%Y # Interfaz IF=hme0 if [ ! -d "$DIRLOG" ]; then mkdir -p "$DIRLOG" fi cd $DIRLOG mv alert alert-$FECHA touch alert chmod 600 alert kill -HUP cat /var/run/snort_$IF.pid compress alert-$FECHA anita:~# Independientemente de la rotacin de logs que llevemos a cabo en cada sensor, suele resultar inteo resante centralizar todos los logs generados en un slo sistema (a veces se le denomina maestro o o master), aunque slo sea para realizar estad o sticas, seguimientos de mquinas atacantes y atacadas, a o simplemente un top ten de piratas. Para ello podemos establecer relaciones de conanza entre los sensores y ese maestro para que puedan conectarse entre s sin necesidad de contraseas y, de forma n automtica, transferir los logs almacenados y rotados. Por supuesto, a estas alturas dicha relacin a o no la estableceremos mediante la denicin de mquinas conables en archivos .rhosts o similares, o a ni con las herramientas r-, sino mediante ssh y las claves pblicas y privadas de cada mquina. u a Aparte de una mayor seguridad (no autenticamos a una mquina simplemente por su direccin o a o nombre, algo fcilmente falseable), siguiendo un mecanismo de este estilo conseguimos que todas a las comunicaciones entre sistemas se realicen de forma cifrada, algo que aqu es muy importante: cualquier informacin relativa a potenciales ataques o respuestas automticas a los mismos se ha de o a considerar como condencial, por lo que ser un grave error echar todo nuestro trabajo a perder a

Q Q

? Q Q

Q

Q

FWQ Q Q ?

Q

Q

Q

-

Q Q

? Q QQ Q Q

FW

Q

Q Q Q ?

Q

SWITCH? ? ? ? ??

HUB?

SWITCH???????

SENSOR

Figura 2: Situacin del sensor o simplemente porque alguien sea capaz de esnifar dicho trco. a Volviendo a nuestras cuestiones iniciales, tambin deb e amos decidir dnde situar lgicamente al o o sensor; por ejemplo, una cuestin t o pica es si debemos emplazarlo detrs o delante del rewall que a protege a nuestra red. En principio, si dejamos que el sensor analice el trco antes de que sea a ltrado en el cortafuegos, estaremos en disposicin de detectar todos los ataques reales que se lanzan o contra nuestra red, sin ningn tipo de ltrado que pueda detener las actividades de un pirata; no u obstante, probablemente lo que ms nos interesar no es detectar todos estos intentos de ataque a a (aunque nunca est de ms permanecer informado en este sentido), sino detectar el trco sospea a a choso que atraviesa nuestro rewall y que puede comprometer a nuestros servidores. Por tanto, es recomendable ([Con99]) emplazar el sensor de nuestro sistema de deteccin de intrusos en la zona o protegida; de cualquier forma, los potenciales ataques que no lleguen al mismo quedarn registrados a en los logs del cortafuegos, e incluso sern neutralizados en el mismo. a Como el sensor ha de analizar todo el trco dirigido a las mquinas protegidas, si nos encontramos a a en un entorno donde dichas mquinas se conecten mediante un concentrador (hub) o mediante otras a arquitecturas en las que cualquiera de ellas vea (o pueda ver) el trco de las dems, no hay muchos a a problemas de decisin sobre dnde situar al sensor: lo haremos en cualquier parte del segmento. o o Sin embargo, si nuestros sistemas se conectan con un switch la cuestin se complica un poco, ya o que en las bocas de este elemento se ver unicamente el trco dirigido a las mquinas que estn a a a e conectadas a cada una de ellas; en este caso, tenemos varias opciones. Una de ellas puede ser modicar por completo con todo lo que esto implica nuestra arquitectura de red para integrar un concentrador por el que pasen los paquetes ya ltrados antes de llegar a las mquinas del switch, tal a y como se muestra en la gura 2. No obstante, suelen existir alternativas ms sencillas y cmodas, a o como la replicacin de puertos que se puede congurar en la mayor de switches; la idea es muy o a simple: todo el trco dirigido a determinada boca del switch se monitoriza y se duplica en otra a boca. As no tenemos ms que congurar este port mirroring y replicar la boca por la que se dirige , a el trco hacia el segmento de mquinas a monitorizar, envindolo tambin a una segunda boca en a a a e la que conectaremos nuestro sensor. Para acabar con los comentarios sobre dnde y cmo situar al sensor de nuestro sistema detector o o de intrusos, un ultimo apunte: quizs nos conviene recordar que el interfaz por el que se analiza a

el trco (hablando claro, por el que se esnifan las tramas) no tiene por qu tener direccin IP. a e o Perfectamente podemos tener un interfaz levantado e inicializado pero sin asignarle ninguna direccin. Esto nos puede resultar util si no nos interesa que en el segmento protegido se detecte una o nueva mquina, o simplemente si no queremos que nuestro sensor sea alcanzable de alguna forma a por el resto de sistemas de su dominio de colisin. Para nuestra comodidad (por ejemplo, a la o hora de centralizar logs de diferentes sensores) podemos usar una mquina con dos interfaces, una a escuchando todo el trco y la otra congurada de forma normal, que ser por la que accedamos a a al sistema.

8.3

IDS en la mquina a

Tras leer la seccin anterior seguramente habr quedado claro que un correcto esquema de deteccin o a o de intrusos basado en red es vital para proteger cualquier sistema; con frecuencia suele ser el punto ms importante, que ms ataques detecta, y donde se suelen emplazar la mayor de sistemas de a a a deteccin que existen instalados en entornos reales hoy en d No obstante, esta enorme importancia o a. suele degenerar en un error bastante grave: en muchos entornos los responsables de seguridad, a la hora de trabajar con IDSes, se limitan a instalar diversos sensores de deteccin basados en red o en cada segmento a proteger, creyendo que as son capaces de detectar la mayor de ataques. a Y eso suele generar una falsa sensacin de seguridad grave, ya que a la hora de lanzar ciertos o ataques un pirata puede eludir fcilmente a estos sensores; los sensores de deteccin en nuestros a o segmentos de red son importantes, pero no son la panacea. Para comprobarlo, volvamos a nuestro ejemplo anterior, en el que un atacante trata de descubrir vulnerabilidades en nuestros servidores http: si recordamos dnde nos hab o amos quedado, el pirata estaba lanzando un escaneador de vulnerabilidades web contra el puerto 80 de nuestro servidor corporativo; el esquema de deteccin o implantado en el cortafuegos no percibir nada extrao, pero el sensor ubicado en el segmento a n donde se encuentra el servidor sin duda ver patrones que denotan un ataque. Por ejemplo, en a el momento en que el escner compruebe la existencia en el servidor de un CGI denominado phf, a snort generar una alerta similar a esta: a [**] IDS128 - CVE-1999-0067 - CGI phf attempt [**] 03/10-03:29:59.834996 192.168.0.3:1032 -> 192.168.0.1:80 TCP TTL:56 TOS:0x0 ID:5040 IpLen:20 DgmLen:58 DF ***AP*** Seq: 0x91FA846 Ack: 0x5AD9A72 Win: 0x7D78 TcpLen: 20 Como veremos en el punto siguiente, es posible que al generar este aviso, el propio sensor decida lanzar una respuesta automtica contra la direccin atacante (por ejemplo, bloquearla en el cortaa o fuegos corporativo). Pero snort trabaja basndose en su base de datos de patrones de ataques; en a dicha base de datos habr una regla como la siguiente: a alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-CGI phf access";\ flags: A+; content:"/phf";flags: A+; nocase; reference:arachnids,128; \ reference:cve,CVE-1999-0067; ) A grandes rasgos, esta regla viene a decir que cuando el sensor detecte una peticin al puerto 80 o de nuestro servidor web en cuyo contenido se encuentre la cadena /phf levante la alerta correspondiente; de esta forma, cuando el atacante solicite el archivo /cgi-bin/phf del servidor, snort ver dicha cadena en la peticin y generar una alarma. Pero qu sucede si el atacante solicita a o a e ese mismo chero pero utilizando una peticin ofuscada, formada por los cdigos ASCII de cada o o carcter? Es decir, si en lugar de lanzar una peticin como GET /cgi-bin/phf hace una similar a o a GET %2f%63%67%69%2d%62%69%6e%2f%70%68%66. La respuesta es sencilla: la peticin anterior o se decodica en el propio servidor web, o como mucho en un proxy intermedio. Algunos detectores de intrusos, como RealSecure, son en teor capaces de procesar este tipo de trco y analizarlo a a normalmente en busca de patrones sospechosos, pero otros muchos (snort en este caso) no; as , estos ultimos no vern en ningn momento la cadena /phf circulando por la red, y por tanto no a u generarn ninguna alarma. Parece entonces evidente que es necesario un nivel adicional en nuestro a esquema de deteccin: justamente el compuesto por los sistemas basados en la propia mquina a o a proteger. Antes hemos hablado de los tres modelos bsicos de IDSes basados en mquina: vericadores a a

de integridad, analizadores de registros y honeypots. Parece claro que un vericador de integridad en nuestro caso no va a resultar muy util para detectar a ese atacante (esto no signica que no se trate de modelos necesarios y utiles en otras muchas situaciones). Tendremos por tanto que recurrir a analizadores de logs o a tarros de miel instalados en la mquina. Si optamos por los primeros, es a sencillo construir un shellscript que procese los archivos generados por el servidor web en nuestro caso, aunque igualmente sencillo que procesar registros del sistema o de otras aplicaciones en busca de patrones que puedan denotar un ataque, como el acceso a determinados archivos bajo el DocumentRoot. Si analizamos cualquier CGI Scanner nos podremos hacer una idea de a qu e patrones debemos estar atentos: por ejemplo, intentos de acceso a CGIs como phf o printenv, a archivos passwd, a cheros fuera del DocumentRoot, etc. Aunque analizar los registros generados por una aplicacin en busca de ciertos patrones sospeo chosos es una tarea trivial, no lo es tanto el integrar ese anlisis en un esquema de deteccin de a o intrusos. Seguramente procesar la salida de un tail -f del archivo de log correspondiente, enviando un correo electrnico al responsable de seguridad cuando se detecte una entrada sospechosa o es fcil, pero por poner un simple ejemplo, qu sucede cuando la mquina se reinicia o el chero a e a de registros se rota? Es necesario volver a entrar y lanzar de nuevo la orden correspondiente para analizar los logs? Seguramente alguien plantear que se puede planicar una tarea para que a peridicamente compruebe que se est procesando el archivo, y lance el anlisis en caso de que no o a a sea as . . pero hasta qu punto es esto cmodo? qu sucede con las entradas duplicadas? y con . e o e los registros perdidos que no se llegan a procesar? Evidentemente, no todo es tan sencillo como el simple tail -f anterior. El anlisis de registros generados por el sistema o por ciertas aplicaciones suele ser una excea lente fuente de informacin de cara a la deteccin de actividades sospechosas en nuestros entornos, o o pero no es habitual aplicar dicho anlisis en un esquema de respuesta automtica ante ataques. a a Es mucho ms comn automatizar la revisin de logs para que peridicamente (por ejemplo, cada a u o o noche) se analicen esos registros y se env un mensaje de alerta por correo electrnico a los rese o ponsables de seguridad en caso de que algo anormal se detecte; evidentemente no es un modelo que trabaje en tiempo real, pero no por ello deja de ser un esquema util en la deteccin de intrusos; o el unico problema que se presenta a la hora de realizar el anlisis suele ser la decisin de qu pa a o e trones buscar en los registros, algo que depende por completo del tipo de log que estemos analizando. Aparte de los sistemas de deteccin basados en el anlisis de registros, otro esquema que podeo a mos y debemos implantar en cada mquina son los honeypots o tarros de miel, mecanismo que a nos ha de permitir detectar ciertos ataques aunque el resto de sensores de nuestro modelo falle. Como antes hemos comentado, hay diferentes modelos de tarros de miel, desde los simples detectores de pruebas hasta los complejos sistemas dedicados por completo a esta tarea; para detectar ataques rutinarios estos ultimos suelen ser algo excesivo e incluso en ocasiones dif no slo desde cil o un punto de vista estrictamente tcnico, ya que no siempre podemos dedicar una mquina entera e a a engaar atacantes, aparte del tiempo necesario para congurarla correctamente, actualizarla, n revisar sus registros, etc. Esquemas tericamente ms simples pueden incluso resultar ms efectivos o a a en la prctica. a En nuestro caso no vamos a complicarnos mucho la existencia; si recordamos a nuestro atacante, estaba lanzando un escaneo de vulnerabilidades contra nuestro servidor web; nuestro IDS basado en red detectar el ataque y en consecuencia dar la voz de alarma y, adicionalmente, ejecutar una a a a respuesta automtica contra el pirata, bloquendolo en el cortafuegos corporativo. Ese atacante ya a a puede ms que sospechar que tenemos un detector de intrusos basado en red que le impide complea tar su escaneo, ya que en el momento que se detecta trco sospechoso bloquea por completo a la a direccin origen; por tanto, un paso lgico para l es intentar un anlisis de vulnerabilidades camuo o e a ado, bien mediante una simple codicacin de peticiones bien mediante un complejo stealth scan. o De nuevo, buscar la existencia de CGIs vulnerables, como /cgi-bin/phf o /cgi-bin/printenv, a y en este caso snort ser incapaz de detectar el ataque. Pero forzosamente a nuestro servidor web a han de llegar estas peticiones, por lo que qu mejor forma de detectar al pirata que en la propia e mquina? No tenemos ms que situar en el directorio donde se ubican nuestros CGIs un programa a a que nos informe si alguien intenta acceder a l, tan simple como el siguiente shellscript: e

anita:~# cat /web/cgi-bin/phf #!/bin/sh /bin/echo "Pirata desde "$REMOTE_ADDR""|mailx -s "Ataque PHF" root /bin/echo "Content-type: text/html" /bin/echo "" /bin/echo "Sonrie a la camara oculta..." anita:~# Evidentemente la decepcin del sistema anterior en un atacante durar unos pocos segundos, ya que o a es inmediato para ste detectar que se trata de una simple trampa; si queremos algo ms elaborado, e a tampoco es dif conseguirlo: podemos simular el comportamiento de diferentes CGIs con vulneracil bilidades conocidas de una forma muy sencilla. Por