SISTEMAS DE DETECCION DE INTRUSOS (IDS) PRESENTADO POR: FABIOLA MARTÍNEZ PEÑARANDA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER INGENIERIA DE SISTEMAS SAN JOSE DE CUCUTA 2012 SISTEMAS DE DETECCION DE INTRUSOS (IDS) PRESENTADO POR: FABIOLA MARTÍNEZ PEÑARANDA PRESENTADO A: ING. JEAN POLO CEQUEDA UNIVERSIDAD FRANCISCO DE PAULA SANTANDER INGENIERIA DE SISTEMAS SAN JOSE DE CUCUTA 2012 SISTEMAS DE DETECCION DE INTRUSOS (IDS) 1. INTRODUCCION A LOS SISTEMAS DE DETECCION DE INTRUSOS 1.1. DEFINICION Un Sistema de Detección de Intrusos o IDS (Intrusion Detection System) es una herramienta de seguridad encargada de monitorizar los eventos que ocurren en un sistema informático en busca de tentativas de intrusión, las cuales se definen como cualquier intento de comprometer la confiabilidad, integridad, disponibilidad o traspasar los mecanismos de seguridad de una computadora o red. Las intrusiones se pueden producir de tres formas: Penetración externa: Se define como la intrusión que lleva a cabo un usuario o un sistema de computadores no autorizado desde otra red. Penetración interna: Es aquella que lleva a cabo el usuario interno que excede sus permisos de acceso. Abuso de recursos: Se define como el abuso que un usuario lleva a cabo sobre unos datos o recursos de un sistema al que está autorizado su acceso. Las diferentes intrusiones que puede reconocer un IDS, considerando si la intrusión está dentro de lo normal o anómalo son: Intrusivas pero no anómalas: Se les denomina falsos negativos y en este caso la actividad es intrusiva pero como no es anómala no se consigue detectarla. Se denominan falsos negativos porque el sistema erróneamente indica ausencia de intrusión. No intrusivas pero anómalas: se denominan falsos positivos y en este caso la actividad es no intrusiva, pero como es anómala el sistema la detecta como intrusiva. Se denominan falsos positivos, porque el sistema erróneamente indica la existencia de intrusión. Ni intrusiva ni anómala: Son negativos verdaderos, la actividad es no intrusiva y se indica como tal. Intrusiva y anómala: Se denominan positivos verdaderos, la actividad es intrusiva y es detectada. Fig. 1: Tipos de intrusiones La detección de intrusiones permite a las organizaciones proteger sus sistemas de las amenazas que aparecen al incrementar la conectividad en red y la dependencia hacia los sistema de información, por tal la razón, los IDS han ganado gran aceptación como una pieza fundamental en la infraestructura de seguridad de la organización. 1.2. ARQUITECTURA GENERAL DE UN IDS Desde que se empezaron a crear estos sistemas de detección de intrusos, se han llevado a cabo múltiples estudios referentes a él. En todos estos estudios se han realizado diferentes propuestas de diseño, entre las que se encuentran la establecida por el Common Intrusion Detection Framework: Fig. 2: Esquema de la arquitectura CIDF (Common Intrusion Detection Framework) E-block: bloque de escucha. Proporciona información sobre los eventos del entorno al resto de elementos del IDS. A-block: motor de análisis. Son los bloques encargados de analizar los datos recogidos por los bloques de escucha y clasificarlos en una de las 4 categorías de la Figura 1. D-block: Bloque de base de datos. Estos bloques son los encargados de almacenar la información observada en los E-blocks para su procesamiento en los bloques de análisis y de respuesta si esto fuera necesario. R-block: motor de respuesta. La respuesta puede ser pasiva o activa la cual significa que de manera automática realiza acciones contra la intrusión. El empleo de respuestas activas ha de ser cuidadosamente considerado ya que pueden incurrir ante un falso positivo en una denegación de servicio a un usuario legítimo. Pese a que el esquema establecido por el CIDF no tuvo éxito como estándar para el desarrollo de nuevos sistemas de detección de intrusos resulta satisfactorio como ejemplo genérico de los componentes de cualquier IDS y de las relaciones existentes entre ellos. Cabe destacar que en la actualidad es cada vez más necesaria la colaboración entre distintos IDS para la correcta detección de las amenazas y la minimización de las falsas alarmas por lo que la emergencia de un estándar para este tipo de sistemas resulta de un gran interés. 1.3. CLASIFICACION DE LOS IDS Los Sistemas de Detección de Intrusos, puede clasificarse de acuerdo a las fuentes de información, las técnicas de análisis y las estrategias de respuesta que implementan. Fig. 3: Clasificación de los IDS A continuación se describirán cada uno de ellos: 1.3.1. Fuentes de Información Se describen las diferentes fuentes de información de eventos usadas para determinar si una intrusión ha tenido lugar. Estas fuentes pueden provenir de diferentes niveles del sistema, siendo más comunes las de monitoreo de red, host y aplicación. Basados en Red: Se encarga de recoger información de eventos sucedidos a nivel de tráfico de red (analizando las cabeceras IP de todos los datagramas que pasan por la interfaz de red). Fig. 4: Implementación de IDS basado en Red Basados en Host: Operan sobre información recolectada de un sistema de cómputo individual, lo que permite analizar actividades con gran confiabilidad y precisión, determinando exactamente que procesos y usuarios están involucrados en un ataque particular sobre el sistema operativo. A diferencia de los IDS basado en red, estos IDS pueden “ver” el resultado de un ataque frustrado, ya que pueden acceder y monitorear directamente los archivos de datos y procesos del sistema usualmente blancos de los ataques. Los IDS basados en host normalmente utilizan dos tipos de fuente de información, los seguimientos de auditoria del sistema operativo y los logs del sistema. Fig. 5: Implementación de un IDS basado en Host Basados en Aplicación: Son un conjunto especial de los IDS basado en host, que analizan los eventos que ocurren dentro de una aplicación de software. La fuente común de información utilizada por los IDS basados en aplicación son los archivos log de las transacciones de las aplicaciones. 1.3.2. Análisis La parte de los sistemas de detección de intrusiones que realmente organiza e interpreta los eventos derivados de las fuentes de información, decidiendo cuando esos eventos indican que están ocurriendo intrusiones o que ya han ocurrido. Los tipos más comunes de análisis son detección de uso indebido y detección de anomalías. Detección de usos indebidos Este modelo se basa en un conocimiento a priori de secuencias y actividades deshonestas. Los procesadores de eventos que implementan este esquema analizan los eventos en busca de patrones de ataques conocidos o actividad que ataque vulnerabilidades típicas de los equipos. Esta secuencias o patrones se conocen bajo el nombre de firmas de ataques, así los componentes de detección basados en el modelo de uso indebidos, comparan los eventos enviados por los sensores con las firmas de ataque que mantienen almacenadas en sus bases de conocimiento. En el momento de detectar alguna concordancia de algún acontecimiento o secuencia de eventos con alguna firma de ataque, el componente lanzara una alarma. Detección de Anomalías Este esquema trata de identificar actividades sospechosas comparando el comportamiento de un usuario, proceso o servicio, con el comportamiento de perfil clasificado como normal. Entonces cualquier desviación que supere un cierto umbral respecto al perfil almacenado será tratado como una evidencia de ataque o intruso. Uno de los requisitos de este modelo es la necesidad de inicializar un perfil por defecto que se ira adaptando progresivamente al comportamiento de un usuario, proceso o servicio no sospechoso. Esta detección ofrece claras ventajas respecto a la detección basada en usos indebidos. La ventaja más destacarle es la posibilidad de detectar ataques desconocidos. Esto es posible por que independientemente como haya conseguido el atacante entrar a un sistema, tan pronto como sus actividades comiencen a desviarse del comportamiento de un usuario normal, el procesador de eventos lanzara una alarma de un posible intruso. 1.3.3. Respuesta El conjunto de acciones que el sistema toma una vez esta detectada una intrusión. Típicamente son agrupadas en activas y pasivas. Respuestas activas: Tienen como objetivo actuar contra el ataque, intentando su neutralización, en el momento en que es detectado (o mientras esta continúa en curso). Un ejemplo de respuesta activa puede ser la cancelación de la conexión en la red que origino el ataque o el propio seguimiento del ataque que permitiría más adelante el análisis correspondiente. El problema de las respuestas activas es que pueden acabar en una denegación de servicio contra usuarios o sistemas legítimos. Es muy probable que algunas de las alarmas que los procesadores hacen saltar sean incorrectas. Por ejemplo, si la unidad de respuesta cortara inmediatamente con la conexión que origino esta alarma, o con aquellos procesos considerados sospechosos, ellos podrían suponer la pérdida de trabajo de un usuario o servicio inocente. Respuestas pasivas: Se limitan a lanzar una alarma para informar y describir el ataque detectado para administrador del sistema. La mayoría de los componentes de respuesta pasiva ofrecen distintas formas de hacer llegar esta información al administrador, como por ejemplo, mediante correo electrónico o la utilización de mensajes SMS, etc. 2. HERRAMIENTAS DE DETECCION DE INTRUSOS 2.1. SNORT Es un IDS en tiempo real desarrollado por Martin Roesch y disponible bajo GPL. Se puede ejecutar en máquinas UNIX y Windows. Es el número uno en sistemas de detección de intrusos en este momento. Dispone actualmente de unas 1.600 reglas, de multitud de aplicaciones para el análisis de sus alertas y soporta algunas funciones de detección de anomalías. Snort puede realizar análisis de protocolos, búsqueda y comparación de contenidos, puede detectar gran variedad de ataques y sondeos, tales como desbordamientos de buffer, escaneo sigiloso de puertos, ataques CGI, intentos de identificación de sistema operativo, etc. También, puede utilizarse como un rastreador de paquetes (sniffer), como registrador de paquetes, y como detector de intrusiones de red; proporciona una interfaz de usuario de fácil manejo y emite reportes de los análisis realizados. La arquitectura de Snort se enfocó par ser eficiente, simple y flexible los elementos que componen el esquema básico de su arquitectura son: Módulo de captura del tráfico: Es el encargado de capturar todos los paquetes de la red utilizando la librería libpcap. Decodificador: Se encarga de formar las estructuras de datos con los paquetes capturados e identificar los protocolos de enlace, de red, etc. Preprocesadores: Permiten extender las funcionalidades preparando los datos para la detección. Existen diferentes tipos de preprocesadores dependiendo del tráfico que queremos analizar (por ejemplo, existen los preprocesadores http, telnet) Motor de Detección: Analiza los paquetes en base a las reglas definidas para detectar los ataques. Archivo de Reglas: Definen el conjunto de reglas que regirán el análisis de los paquetes detectados. Plugins de detección: Partes del software que son compilados con Snort y se usan para modificar el motor de detección. Plugins de salida: Permiten definir qué, cómo y dónde se guardan las alertas y los correspondientes paquetes de red que las generaron. Pueden ser archivos de texto, bases de datos, servidor syslog, etc. Fig. 7: Arquitectura de Snort 2.2. eTRUST eTrust Intrusion Detection ofrece una protección de red de última generación mediante la detección automática de patrones de tráfico en la red que indican ataques, abusos e intrusiones potenciales. Por ejemplo, eTrust puede detectar un ataque de denegación de servicio, y tomar las medidas oportunas de acuerdo con las políticas predefinidas, antes de que se vean afectados los servidores y servicios. eTrust Intrusion Detection ofrece ventajas que incluyen: Control del acceso a la red: eTrust utiliza una base de normas para definir qué usuarios pueden acceder a ciertos recursos de la red, garantizando así un acceso autorizado a dichos recursos. Motor antivirus avanzado: Un motor de exploración de virus detecta y bloquea el tráfico en la red que contiene virus informáticos. Protege a los usuarios frente a la descarga de archivos infectados por virus. Las firmas de virus nuevas y actualizadas se encuentran disponibles en el sitio web de CA (Computer Associates). Amplia biblioteca de patrones de ataque: eTrust detecta de modo automático los patrones de ataque del tráfico en la red, incluso mientras están en curso. La actualización regular de las firmas de ataque garantiza la puesta al día de eTrust. Tecnología de búsqueda de paquetes. eTrust opera en modo oculto, sin que puedan detectarla los atacantes. Los piratas informáticos a menudo son detectados sin darse cuenta, ya que no saben que están siendo observados. Bloqueo de las direcciones URL. Los administradores pueden designar direcciones URL cuya visita no se permite a los usuarios, impidiendo así una navegación improductiva por la web. Exploración del patrón de texto. Con eTrust, los administradores pueden definir patrones de texto para indicar cualquier violación de las políticas. De esta forma se evita el envío no autorizado de datos confidenciales a través del correo electrónico o la Web. Registro de utilización de la red. eTrust permite a los administradores de la red hacer un seguimiento del uso de la red por parte de usuarios finales, aplicaciones, etc. Ayuda a mejorar la planificación de políticas de red y proporciona una carga de red precisa. Gestión remota. Los usuarios remotos pueden acceder a una estación de trabajo mediante la ejecución de eTrust, utilizando una conexión TCP/IP o módem. Una vez conectado, el usuario puede ver y controlar los datos de eTrust, cambiar las normas y crear informes según los permisos definidos por el administrador de eTrust. Registro y análisis de intrusiones. eTrust ofrece un amplio sistema para capturar información y dejarla disponible para el análisis correspondiente. Tras instalar el software y diseñar una ubicación de archivo, el usuario define una norma que registra los datos de la sesión en un archivo. Los usuarios pueden utilizar entonces el navegador para filtrar, clasificar y mostrar la información archivada, así como crear informes detallados. Los entornos soportados son: Servidores: Windows 95/98/2000 Windows NT Redes: Redes TCP/IP Fig. 9: Los resultados del monitoreo se muestran gráficamente en un formato intuitivo 2.3. SNARE SNARE (System Intrusion Analysis and Reporting Environment) es un IDS basado en host para la recolección, análisis, generación de informes y archivo de eventos de auditoría. Existen "agentes" de seguridad SNARE para múltiples sistemas operativos y aplicaciones, y un servidor SNARE propietario. El sistema SNARE consta de: Los cambios en un núcleo del sistema operativo (para añadir soporte de auditoría). El demonio de auditoría SNARE (que actúa como interfaz entre el núcleo y el administrador de seguridad). La GUI SNARE auditoría (interfaz de usuario para administrar el demonio). El administrador puede activar eventos, filtro de salida y, potencialmente, impulsar la información de registro de auditoría en una ubicación central. SNARE está disponible para Linux, Solaris y Windows. Fig. 8: Entorno Snare 2.4. TRIPWIRE La herramienta Tripwire es un comprobador para archivos y directorios de sistemas Unix diseñado por el Dr. Eugeene Spafford en 1992. La idea de esta herramienta es crear un resumen de cada archivo o directorio importante al instalar el sistema, y esos resúmenes se almacenan en un medio seguro, de forma que si alguno de los archivos es modificado (por ejemplo, por un atacante que sustituye un programa por una versión troyanizada o añade una entrada al archivo de contraseñas) Tripwire envía una alerta la próxima vez que se realice la comprobación. Tripwire se encuentra en sus versiones empresariales y Open Source GNU, las diferencias consisten en que la primera posee una mejor presentación de informes, una más amplia plataforma de apoyo, y, con el componente opcional Tripwire Manager, la centralización de la presentación de informes además de una interfaz gráfica de usuario. Por su parte, Tripwire Open Source se encuentra en la versión 2.4.0, la cual contiene una mejora de la funcionalidad de las secuencias de comandos para compilar en una gama más amplia de sistemas operativos de tipo POSIX (Linux/ BSD/ UNIX). Está disponible en los repositorios de las distribuciones Debian, Ubuntu, RedHat y SuSe, que son de las más utilizadas. El siguiente diagrama de flujo resume la metodología implementada por Tripwire. Fig. 6: Diagrama de flujo de Tripwire 2.5. PRELUDE El sistema de detección de intrusos Prelude, fue creado en 1998 por el experto en seguridad de la información Yoann Vandoorselaere. Prelude nació de la observación de que mientras que un número cada vez mayor de sistemas de detección de intrusiones (IDS basados en red - NIDS, verificadores de integridad de archivos, escáneres de vulnerabilidades, etc.) fueron llegando en el mercado, no existía un marco que les permitiera trabajar en conjunto y por lo tanto aumentar la seguridad de manera exponencial. Prelude se ha convertido en un sistema universal de gestión de seguridad de la Información. Prelude recopila, normaliza y ordena los informes de todos los eventos relacionados con la seguridad independientemente de la marca del producto o licencia que da lugar a este tipo de eventos; Preludio es "sin agente". Además es capaz de recuperar cualquier tipo de registro (logs del sistema, archivos planos, etc.), Prelude ofrece el beneficio de una compatibilidad nativa con una serie de sistemas dedicados a enriquecer la información aún más (snort, samhain, ossec, auditd, etc.). Los eventos de seguridad son normalizadas gracias a un formato único, denominado “Intrusion Detection Message Exchange Format” (IDMEF), que es un estándar internacional creado por iniciativa del IETF, junto con la participación del equipos Prelude para permitir la interacción con las diversas herramientas de seguridad actualmente disponible en el mercado. Prelude se divide en varios componentes: Los sensores son responsables de la detección de intrusos, y reportar alertas en una forma centralizada mediante una conexión TLS con un servidor “Prelude-manager”. El servidor “Prelude-manager” puede procesar estas alertas y entregarlos a un medio especificada por el usuario (base de datos mysql, postgresql, archivo XML). La consola Prelude se puede utilizar para ver estas alertas. Este es un ejemplo sencillo de cómo interactúan los diferentes componentes de Prelude: Fig. Nº x Arquitectura simple de Prelude 2.6. RESUMEN DE IDS En la siguiente tabla se muestra un resumen de los IDS estudiados en este documento, se muestra el tipo de sistema del que se trata, las principales características y una descripción de los mismos. RESUMEN IDS NOMBRE ENFOQUE Firma Digital Basado en Firmas Basado en Firmas Basado en patrones Anomalías ORIGEN DE DATOS DESCRPCION SITIO OFICIAL HIDS Tripwire es el IDS basado en host más popular para Linux. Proporciona un único punto de control para seguridad y estándares de configuración en entornos físicos y virtuales. www.tripwire.com NIDS Implementa un motor de detección de ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier anomalía previamente definida como patrones. http://www.snort.org/ HIDS Es un Sistema de Análisis de Intrusión e Informes del Entorno. Puede monitorizar y logear numerosos tipos de eventos de sistema, incluyendo: cuándo se ejecuta un programa, quién lo ejecuta y a qué archivos accede, etc. http://www.intersectall iance.com/projects/S nare/oldindex.html NIDS Detección automática de patrones. Representa la última generación de protección de redes para empresas www.ca.com Hibrido Prelude (Sistema de Gestión de Información de Seguridad) recoge, normaliza, clasifica, agrega, correlaciona y relata todos los eventos relacionados con la seguridad. www.prelude-ids.org 3. INSTALACION Y CONFIGURACION DE TRIPWIRE 1. Descargamos e instalamos Tripwire. A continuación se abrirán algunas interfaces en las que definiremos la configuración de Tripwire Escogemos el tipo de configuración de servidor de correo El nombre de sistema de correo, dejaremos la que es dada por defecto. Tripwire utiliza dos claves (que pueden ser palabras u oraciones) para almacenar su información. Una de ellas, la "site key" o "clave de sitio", se emplea para encriptar los archivos de configuración y de las políticas. La otra "local key" o "clave local", se usa para encriptar la información referida al estado de los archivos del sistema que se monitorean. En las siguientes interfaces definiremos cada una de ellas 2. Una vez instalado el HIDS Tripwire, podemos consultar su archivo de configuración, el cual se encuentra en la ruta /etc/tripwire/twcg.txt, y modificar aquellos parámetros que consideremos necesarios. Para el caso nuestro archivo de configuración fue editado, el resultado fue: POLFILE: Especifica la ubicación del archivo de políticas. DBFILE: Especifica la ubicación del archivo de la base de datos. REPORTFILE: Especifica la ubicación de los archivos de informes. SITEKEYFILE: Especifica la ubicación del archivo de la llave del sitio. 3. LOCALKEYFILE: Especifica la ubicación del archivo de la llave local. EDITOR: Especifica el editor de texto llamado por Tripwire. LATEPROMPTING: Si se coloca a verdadero, esta variable configura Tripwire para que espere tanto como sea posible antes de preguntar al usuario por una contraseña, minimizando así el tiempo que la contraseña permanece en memoria. LOOSEDIRECTORYCHECKING: Si es verdadero, esta variable configura Tripwire para que informe sobre los cambios que se han realizado en un archivo de un directorio y no sobre los cambios propios del directorio. Esto limita la redundancia en los informes de Tripwire. SYSLOGREPORTING: Si es verdadero, esta variable configura Tripwire para informe al demonio syslog con la facilidad del "usuario". El nivel de informe está colocado a aviso. Vea la página del manula de syslogd para más información. MAILNOVIOLATIONS: Si es verdadero, esta variable configura Tripwire para que mande un informe en forma de e-mail a intervalos regulares sin tener en cuenta si se han producido violaciones. EMAILREPORTLEVEL: Especifica el nivel de detalles para los informes enviados a través de email. Los valores válidos para esta variable son 0 a 4. REPORTLEVEL: Especifica el nivel de detalles para los informes generados por el comando twprint. Este valor se puede cambiar en la línea de comandos. MAILMETHOD: Especifica qué protocolo de correo debe usar Tripwire. Los valores válidos son SMTP and SENDMAIL. MAILPROGRAM: Especifica cúal programa de correo usará Tripwire. Ahora actualizamos el archivo de configuración "twcfg.txt" CONFIGURACION DE LOS ARCHIVOS DE POLITICAS 4. La configuración de los archivos que van a ser monitoreados por Tripwire se mantiene en un gran archivo conocido como "archivo de políticas" (policy file.) Su manipulación es algo tediosa dada su extensión. Tripwire viene con un archivo que sirve de "plantilla" para ser modificado. Este archivo es: /etc/tripwire/twpol.txt. Para el caso lo modificaremos y dejaremos solo las siguientes políticas: En esta parte, además podemos insertas la directiva emailto = user@host.domain en la configuración de cada grupo de archivos que vamos a monitorear, en el caso de querer ser alertados cuando existan modificaciones en los mismos. 5. Cuando el archivo de políticas contiene todo lo que se pretende monitorear, hay que "instalarlo". En realidad Tripwire usa una versión compilada y encriptada de este archivo, que se almacena en/etc/tripwire/tw.pol. Para generarlo (y regenerarlo cuantas veces se necesite), usar: INICIALIZACION DE LA BASE DE DATOS Cuando Tripwire inicializa su base de datos, crea una colección de objetos de sistemas de archivos basados en las reglas en el archivo de políticas. Esta base de datos sirve como la base para los controles de integridad. 6. Para inicializar la base de datos Tripwire, use el comando siguiente: La base de datos fue creada en /var/lib/tripwire/Fabiola-VirtualBox.twd 7. Ejecución de un control de integridad. Por defecto, el RPM Tripwire añade un script de la shell llamado tripwire-check al directorio /etc/cron.daily/. Este script ejecuta automaticamente un control de integridad una vez al día. Sin embargo, usted puede ejecutar un control de integridad de Tripwire en cualquier momento mediante el comando: Cuando ejecuta un control de integridad, Tripwire compara los objetos de sistema de archivos actuales y reales con sus propiedades como han sido indicadas en su base de datos. Las violaciones se imprimen a una salida estándar y se guardan en un archivo de informe en /var/lib/tripwire/report/. 8. Para visualizar informes de Tripwire, lo hacemos con el comando twprint -m r indicandole a twprint cual archivo de informe mostrar. También puede usar twprint para ver la base de datos completa o información sobre determinados archivos en la base de datos Tripwire. Esto es útil para ver la cantidad de información que Tripwire está supervisando en su sistema. Para ver la base de datos completa Tripwire, escriba este comando: PRUEBAS Después de generada la base de datos, editaremos el archivo /bin/zcat. Cambiaremos la línea Report bugs to <bug-gzip@gnu.org>.” Por: Report bugs to <report-doc@ufps.edu.co>.” Y a continuación, realizaremos un chequeo de seguridad de los archivos con el comando: tripwire –check El resultado Por último, para enviar el informe al e-mail establecido en el documento de políticas, se hace uso del comando: Informe enviado por Tripware