Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACAN SEMINARIO DE TITULACIÓN “SEGURIDAD DE LA INFORMACIÓN” TESINA “IMPLEMENTACIÓN DE UN IDS CON SNORT COMO HERRAMIENTA DE MONITORIZACIÓN” QUE PRESENTAN PARA OBTENER EL TÍTULO DE INGENIERO EN COMPUTACIÓN MARTÍNEZ OLIVARES MARÍA ANDREA PULIDO BAUTISTA JUAN JOSÉ Asesores: DR. GABRIEL SANCHEZ PÉREZ ING. ARTURO DE LA CRUZ TELLEZ VIGENCIA: DES/ESIME-CUL-2008/23/1/09 México, D.F., Abril 2010 AGRADECIMIENTOS A mi familia. Quiero expresar un profundo agradecimiento a todos aquellos, quiénes con su ayuda, apoyo y comprensión me impulsaron a cerrar esta etapa en mi vida académica y me impulsan a continuar cosechando éxito en mi vida profesional. María Andrea Martínez Olivares. Agradezco a todas las personas que estuvieron cerca de mí, sobre todo a mi esposa que siempre me fortalece para seguir adelante, a mi futuro fruto que viene en camino y a mis padres. Sencillamente quiero decirles a todos mis compañeros, amigos y los que han confiado incondicionalmente en mi, gracias. Juan José Pulido Bautista. INDICE GENERAL PAGS. OBJETIVO ............................................................................................................ I JUSTIFICACIÓN .................................................................................................. II INTRODUCCIÓN ................................................................................................. III CAPITULO I ANTECEDENTES 1.1. Definición de un IDS ................................................................... 2 1.2. Clasificación de un IDS ................................................................... 2 1.3. Requisitos de un IDS ................................................................... 4 1.4. IDS basado en red (NIDS) ......................................................... 5 1.5. Diferentes herramientas de IDS ......................................................... 12 CAPITULO II IDS CON SNORT 2.1. IDS de red: SNORT ................................................................... 16 2.2. Estructura de las reglas ................................................................... 20 2.3. Componentes de SNORT ................................................................... 20 2.4. Ejemplo de SNORT ................................................................... 23 CAPITULO III IMPLEMENTACION DE UN IDS 3.1. Escenario de Implementación ......................................................... 34 3.2. Instalación del software ................................................................... 36 3.3. Configuración de SNORT ................................................................... 45 3.3.1 Configuración de red ......................................................... 45 3.3.2 Configuración de reglas ......................................................... 45 3.3.3 Configuración de acceso ......................................................... 46 3.4. Configuración MySQL ................................................................... 49 3.5. Configuración de PHP ................................................................... 51 CAPITULO IV PRUEBAS EN EL NIDS 4.1. Funcionamiento de SNORT ......................................................... 54 4.2. Servicios de MySQL ……............................................................ 59 4.3. Implementación de una interfaz web .............................................. 62 CONCLUSIONES ................................................................................................... 64 BIBLIOGRAFÍA ......................................................................................... 66 INDICE DE FIGURAS PAGS. CAPITULO I ANTECEDENTES CAPITULO II IDS CON SNORT 2.1. Diagrama de los componentes de SNORT ......................... 21 CAPITULO III IMPLEMENTACION DE UN IDS 3.1 Escenario de implementación de un NIDS ………………………… 35 3.2 Iniciando la instalación de Snort ….…………………………………….. 36 3.3 Opciones de instalación …..…………………………………............... 37 3.4 Componentes necesarios para instalar Snort ….…………................. 38 3.5 Ruta de instalación de Snort …………….………………………….. 38 3.6 Instalación exitosa de Snort ………………………………………... 39 3.7 Iniciando la instalación de WinPcap 4.1 ……...………………………… 40 3.8 Opciones de instalación de WinPcap ………...……………………… 41 3.9 Finalizando la instalación de WinPcap ……..…………………………. 41 3.10 Instalación de Xampp 1.5.3 ………………….…………………….. 42 3.11 Activación de servicio de Apache, MySQL ………………………... 42 3.12 Servicios y puertos asignados de Apache ….…………………….. 43 3.13 MySQL asignado al puerto 3306 ………….…………………………….. 43 3.14 Instalación satisfactoria de Xampp ………..………………………. 43 3.15 Panel de control ………………………..………………………………. 44 3.16 Xampp para Windows servicios instalados ………………………… 44 3.17 Snort en línea de comandos mostrando la versión ………………… 46 3.18 Listado de interfaz de red con Snort …...……………….................. 47 3.19 Ejecucion de comando console ……………………………...…........... 47 3.20 Comportamiento de Snort al realizar un ping …….………………….. 48 3.21 Consulta de la tabla event de la base de datos snort .………….......... 51 3.22 Ubicación de los archivos de configuración de PHP …...…...…….… 52 CAPITULO IV PRUEBAS EN EL NIDS 4.4. Funcionamiento de SNORT ......................................................... 55 4.5. Servicios de MySQL ................................................................... 56 4.6. Implementación de una interfaz web .............................................. 56 4.7. Rastreo de paquetes ................................................................... 57 4.8. Contenido del proceso SnortServiceBegin .................................... 58 4.9. Proceso SnortServiceEnd ……………………………………...… 58 4.10. Conexión a la base de conocimientos de Snort ………………... 59 4.11. Estructura de tablas de la base de conocimientos ………………... 59 4.12. Registro de la tabla event ……………….............................................. 60 4.13. Consulta de la tabla event ……………….............................................. 60 4.14. Administrador de MySQL ……………….............................................. 61 4.15. Administrador de la base de conocimientos de Snort ………...…….... 61 4.16. Procesos que integra la interfaz web ………………......................... 62 4.17. Interfaz web ……………………………………………………………...... 62 I Objetivo El objetivo de este trabajo es implementar SNORT como un Sistema de detección de Intrusiones (IDS) complementado con otras herramientas, para facilitar la monitorización de las alertas. Para lograrlo se hace necesario conocer un poco más a fondo los componentes principales de un IDS, y SNORT, para finalmente diseñar de manera práctica una interfaz que nos muestre el funcionamiento del mismo. II Justificación Actualmente la tecnología ha tenido un crecimiento bastante significativo que hace que las compañías que se dedican a ofrecer productos y servicios lleven sus ofertas a Internet y de esta forma exhiben la estructura de su organización, toda la información o sistema de información a cualquier usuario, debido a esto existen otro tipo de usuarios que tratan de aprovechar esos canales para poder acceder, no únicamente a esa información, sino, a algunos datos que sean de mayor importancia para la organización de una forma ilícita. Para poderproteger la información, la mayoría de las organizaciones se ven en la necesidad de realizar políticas de seguridad dependiendo de sus necesidades, pero el llevarlas a cabo implica una inversión considerable de capital, tanto para realizar un análisis de seguridad, como el comprar el equipo necesario. Hay empresas pequeñas o que apenas ingresan al mercado que no tienen la suficiente infraestructura o presupuesto para poder implementar algún sistema de seguridad y de igual forma no pueden esperar a que su información sea vulnerada por cualquier usuario, por lo que se llevo al desarrollo de un sistema que detecte esos intentos de intrusiones de tal forma que la información no se vea tan vulnerable, y el costo del mismo sea el mínimo. Este desarrollo es una simple acción inicial para proteger el sistema de información, pero se hace necesario continuar con un análisis más extenso para poder proteger de forma adecuada el sistema de información. III Introducción Durante los últimos años se ha demostrado que las redes de ordenadores facilitan el trabajo, la comunicación y la coordinación de las diferentes áreas que definen una empresa. Esto, unido al crecimiento de Internet y al número de clientes potenciales que puede atraer, hace que lo que era una red de ordenadores corta y de fácil administración se convierta en una extensa y compleja red donde recae la responsabilidad de comunicación y la necesidad de darse a conocer ofreciendo sus productos u ofertas. Por este motivo y debido a la importancia que han adquirido las redes de ordenadores para el desarrollo empresarial actual, se hace necesario desarrollar una política de seguridad general aplicada a toda la estructura empresarial. Cada vez es más cotidiano escuchar noticias de empresas atacadas por piratas informáticos en las cuales toda la información de sus clientes ha sido sustraída o cuyos servidores que proporcionan conexión con Internet, han dejado de funcionar. Es aquí en donde surgen nuevos conceptos relacionados a la seguridad de las redes de ordenadores, como la vulnerabilidad, las intrusiones y los ataques, tanto internos como externos. La diferencia entre vulnerabilidad y ataque, es que la vulnerabilidad es referente a errores de software o de configuración que pueden permitir a un intruso acceder a un sistema mientras que un ataque es un intento de explotar una vulnerabilidad en ese sistema. Cómo todas las vulnerabilidades no son conocidas, así como tampoco son conocidos los posibles ataques, en los últimos años se han desarrollado productos para detectar tanto las posibles vulnerabilidades de los programas instalados en los ordenadores, del sistema operativo como de servicios de red, como los posibles ataques que se pueden perpetrar. IV El concepto intrusión se refiere a un conjunto de acciones que intentan comprometer la integridad, confidencialidad o disponibilidad de un recurso; una intrusión no necesariamente consiste en un acceso no autorizado a una máquina: también puede ser una negación de servicio. A los sistemas utilizados para detectar las intrusiones o los intentos de intrusión se les denomina Sistemas de Detección de Intrusiones (por sus siglas en inglés, IDS) o, sistemas de detección de intrusos; cualquier mecanismo de seguridad que tenga este propósito puede ser considerado un IDS, pero generalmente sólo se aplica esta denominación a los sistemas automáticos (software o hardware). Uno de los primeros pasos al momento de hablar de IDS es analizar si realmente se necesita uno de ellos en el ambiente de trabajo; a fin de cuentas, se debe tener ya un sistema de protección perimetral basado en cortafuegos, y por si ese cortafuego fallara, cada sistema habría de estar configurado de una manera correcta, de forma que incluso sin cortafuegos cualquier máquina pudiera seguirse considerando relativamente segura. Otro aspecto a considerar es si se debe esperar que en cualquier momento alguien consiga romper la seguridad del ambiente de trabajo, y por tanto, se debe ser capaz, de detectar ese problema tan pronto como sea posible, incluso antes de que se produzca. Ningún sistema informático puede considerarse completamente seguro, pero incluso aunque nadie consiga violar las políticas de seguridad, los sistemas de detección de intrusos se encargarán de mostrar todos los intentos de multitud de piratas para penetrar en el entorno, no dejándo caer en ninguna falsa sensación de seguridad: si se es consciente de que a diario hay gente que trata de corromper los sistemas, no se cae en la tentación de pensar que las máquinas están seguras porque nadie sabe de su existencia o porque no son interesantes para un pirata. Capítulo I. Antecedentes - 1 - CAPITULO I ANTECEDENTES Capítulo I. Antecedentes - 2 - 1.1 Definición de un IDS Un Sistema de Detección de Intrusión (IDS) se puede definir como un sistema de software o hardware que automatiza el proceso de supervisión del tráfico de la red y / o actividades del sistema, analizándolas para detectar actividades sospechosas o no deseadas de tal forma que se reduce el riesgo de una intrusión 1[1]. 1.2 Clasificación de un IDS Generalmente existen dos formas de clasificar a los sistemas de detección de intrusos: en función de qué sistemas vigilan, o en función de cómo lo hacen. Para la primera de estas clasificaciones tenemos dos grupos de sistemas de detección de intrusos: los que analizan actividades de una única máquina en busca de posibles ataques, y los que lo hacen en una subred (generalmente, de un mismo dominio de colisión). Esta última puntualización es importante: un IDS que detecta actividades sospechosas en una red no tiene porqué ubicarse en todas las máquinas de esa red. • IDS basados en red (Network based IDS). Un IDS basado en red monitoriza los paquetes que circulan por nuestra red en busca de elementos que denoten un ataque contra alguno de los sistemas ubicados en ella; el IDS puede situarse en cualquiera de los hosts o en un elemento que analice todo el tráfico (como un HUB o un enrutador). _____________________ 1 intrusión es un conjunto de acciones que intentan comprometer la integridad, confidencialidad o disponibilidad de un recurso Capítulo I. Antecedentes - 3 - Esté donde esté, monitorizará diversas máquinas y no una sola: esta es la principal diferencia con los sistemas de detección de intrusos basados en máquina. • IDS basados en máquina (Host based IDS). Mientras que los sistemas de detección de intrusos basados en red operan bajo todo un dominio de colisión, los basados en máquina realizan su función protegiendo un único sistema; de una forma similar - guardando las distancias, por supuesto - a como actúa un escudo antivirus residente en MS-DOS, el IDS es un proceso que trabaja en background (o que despierta periódicamente) buscando patrones que puedan denotar un intento de intrusión y alertando o tomando las medidas oportunas en caso de que uno de estos intentos sea detectado. La segunda gran clasificación de los IDS se realiza en función de cómo actúan estos sistemas; actualmente existen dos grandes técnicas de detección de intrusos: las basadas en la detección de anomalías (anomaly detection) y las basadas en la detección de usos indebidos del sistema (misuse detection). • Detección de anomalías. La base del funcionamiento de estos sistemas es suponer que una intrusión se puede ver como una anomalía dentro del sistema, por lo que si se puede establecer un perfil del comportamiento habitualde los sistemas, éste podría ser capaz de detectar las intrusiones por pura estadística: probablemente una intrusión sería una desviación excesiva de la media de nuestro perfil de comportamiento. Capítulo I. Antecedentes - 4 - • Detección de usos indebidos. El funcionamiento de los IDS basados en la detección de usos indebidos presupone que se pueden establecer patrones para los diferentes ataques conocidos y algunas de sus variaciones; mientras que la detección de anomalías conoce lo normal (en ocasiones se dice que tienen un ‘conocimiento positivo’, positive knowledge) y detecta lo que no lo es, este esquema se limita a conocer lo anormal para poderlo detectar (conocimiento negativo, negative knowledge). Un IDS de tiempo real (los denominados Real-Time Intrusion Detection Systems) trabaja continuamente en busca de posibles ataques, mientras que los sistemas que se ejecutan a intervalos (Vulnerability Scanners) son analizadores de vulnerabilidades que cualquier administrador ha de ejecutar regularmente (ya sea de forma manual o automática) contra sus sistemas para verificar que no presentan problemas de seguridad. 1.3 Requisitos de un IDS Sin importar qué sistemas vigile o su forma de trabajar, cualquier sistema de detección de intrusos ha de cumplir algunas propiedades para poder desarrollar su trabajo correctamente. En primer lugar, y quizás como característica más importante, el IDS ha de ejecutarse continuamente sin nadie que esté obligado a supervisarlo; independientemente de que al detectar un problema se informe a un operador o se lance una respuesta automática, el funcionamiento habitual no debe implicar interacción con un humano. Otra propiedad, y también como una característica a tener siempre en cuenta, es la aceptabilidad o grado de aceptación del IDS; al igual que sucedía con cualquier modelo de autenticación, los mecanismos de detección de intrusos han de ser Capítulo I. Antecedentes - 5 - aceptables para las personas que trabajan habitualmente en el entorno. Por ejemplo, no ha de introducir una sobrecarga considerable en el sistema (si un IDS ralentiza demasiado una máquina, simplemente no se utilizará) ni generar una cantidad elevada de falsos positivos (detección de intrusiones que realmente no lo son) o de archivos .log, ya que entonces llegará un momento en que nadie se preocupe de comprobar las alertas emitidas por el detector. Una tercera característica a evaluar a la hora de hablar de sistemas de detección de intrusiones es la adaptabilidad del mismo a cambios en el entorno de trabajo. Como es sabido, ningún sistema informático puede considerarse estático: desde la aplicación más pequeña hasta el propio kernel de Unix, pasando por supuesto por la forma de trabajar de los usuarios, todo cambia con una periodicidad más o menos elevada. Si los mecanismos de detección de intrusiones no son capaces de adaptarse rápidamente a esos cambios, están condenados al fracaso. Todo IDS debe además presentar cierta tolerancia a fallos o capacidad de respuesta ante situaciones inesperadas y un IDS ha de ser capaz de responder siempre adecuadamente ante los mismos. 1.4 IDS basado en Red La mayoría de los sistemas de detección de intrusiones comerciales son los basados en red. Los sistemas de detección de intrusiones basados en red, NIDS (network- based IDS) normalmente consisten de un sensor de simple propósito colocado en un solo lugar o posicionado en hosts en varios puntos de la red. Esas unidades monitorizan el tráfico de la red, realizando un análisis local de ese tráfico y reportando ataques a la consola de administración central. Como los sensores son limitados a correr el IDS, ellos pueden ser fácilmente resguardados contra los ataques. Muchos de esos sensores están diseñados para correr en modo silencioso, Capítulo I. Antecedentes - 6 - en orden que lo realizan mas dificultad tiene el atacante para detectar su presencia y ubicación. Los sistemas NIDS son capaces de detectar ataques contra diferentes sistemas de una misma red (en concreto, de un mismo dominio de colisión), aunque generalmente se ejecuten en uno solo de los hosts de esa red. Para lograr su objetivo, al menos una de las interfaces de red de esta máquina sensor trabaja en modo promiscuo, capturando y analizando todas las tramas de red que pasan por él, escuchando en un segmento de red o switch, en busca de patrones indicativos de un ataque. Los patrones pueden ser casi cualquiera de los diferentes campos de una trama de red TCP/IP puede tener un valor que, con mayor o menor probabilidad, represente un ataque real; los casos más habituales incluyen: • Campos de fragmentación. Una cabecera IP contiene 16 bits reservados a información sobre el nivel de fragmentación del datagrama; de ellos, uno no se utiliza y trece indican el desplazamiento del fragmento que transportan. Los otros dos bits indican o bien que el paquete no ha de ser fragmentado por un router intermedio (df, Don’t Fragment) o bien que el paquete ha sido fragmentado y no es el último que se va a recibir (mf, More Fragments). Valores incorrectos de parámetros de fragmentación de los datagramas se han venido utilizando típicamente para causar importantes negaciones de servicio a los sistemas y, desde hace también un tiempo incluso para obtener la versión del operativo que se ejecuta en un determinado host. En ocasiones, en algunas máquinas se puede observar ciertas combinaciones de bits relacionados con la fragmentación por lo que se concluye que se tienen motivos para - cuanto menos - sospechar que alguien trata de atacarnos. Capítulo I. Antecedentes - 7 - • Dirección origen y destino. Las direcciones de la máquina que envía un paquete y la de la que lo va a recibir también son campos interesantes de cara a detectar intrusiones en los sistemas o en la red. Solo se tiene que tomar en cuenta el tráfico proveniente de una DMZ que tenga como destino una red protegida: es muy posible que esos paquetes constituyan un intento de violación de la política de seguridad. Otros ejemplos clásicos son las peticiones originadas desde Internet y que tienen como destino máquinas de una organización que no están ofreciendo servicios directos al exterior, como un servidor de bases de datos cuyo acceso está restringido a sistemas de cualquier red. • Puerto origen y destino. Los puertos origen y destino (especialmente este último) son un excelente indicativo de actividades sospechosas en redes. Aparte de los intentos de acceso no autorizado a los servicios del sistema, pueden detectar actividades que también supondrán a priori violaciones de las políticas de seguridad, como la existencia de troyanos, ciertos tipos de barridos de puertos, o la presencia de servidores no autorizados dentro de la red. • Flags TCP. Uno de los campos de una cabecera TCP contiene 6 bits (urg, ack, psh, rst, syn y fin), cada uno de ellos con una finalidad diferente (por ejemplo, el bit syn es utilizado para establecer una nueva conexión, mientras que fin hace justo lo contrario: liberarla). Evidentemente el valor de cada uno de estos bits será 0 o 1, lo cual de forma aislada no suele decir mucho (ni bueno ni malo) de su emisor; no obstante, ciertas combinaciones de valores suelen ser bastante sospechosas: por ejemplo, una trama con los dos bits de los que han mencionado - syn y fin - activados Capítulo I. Antecedentes - 8 - simultáneamente sería indicativa de una conexión que trata de abrirse y cerrarse al mismo tiempo.Para dar una idea de la importancia de estos bits de control, es conveniente no olvidar que uno de los problemas de seguridad más conocidos de los últimos años sobre plataformas Windows, estaba fundamentado básicamente en el manejo de paquetes oob (Out Of Band): tramas con el bit urg activado. • Campo de datos. Seguramente, el campo de datos de un paquete que circula por la red es donde más probabilidades se tiene de localizar un ataque contra los sistemas; esto es debido a que con toda probabilidad el o los cortafuegos corporativo detendrá tramas cuya cabecera sea ‘sospechosa' (por ejemplo, aquellas cuyo origen no esté autorizado a alcanzar su destino o con campos incorrectos), pero rara vez un cortafuegos se parará a analizar el contenido de los datos transportados en la trama. Puede parecer que los sistemas de detección de intrusiones basados en red funcionan únicamente mediante la detección de patrones; realmente, esto no es así: en principio, un detector de intrusiones basado en red puede estar basado en la detección de anomalías, igual que lo puede estar uno basado en máquinas. No obstante, esta aproximación es minoritaria; aunque una intrusión generará probablemente comportamientos anormales (por ejemplo, un tráfico excesivo entre el sistema atacante y el atacado) susceptibles de ser detectados y eliminados, con demasiada frecuencia estos sistemas no detectarán la intrusión hasta que la misma se encuentre en un estado avanzado. Este problema hace que la mayor parte de IDS basados en red que existen actualmente, funcionen siguiendo modelos de detección de usos indebidos. Capítulo I. Antecedentes - 9 - Dentro de los sistemas de detección de intrusiones basados en red se encuentra las llamadas honeynets - literalmente, ‘redes de miel’ -. Se trata de un concepto muy parecido al de los honeypots2, pero extendido ahora a redes completas: redes diseñadas para ser comprometidas, formadas por sistemas reales de todo tipo que, una vez penetrados, permiten capturar y analizar las acciones que está realizando el atacante para así poder aprender más sobre aspectos como sus técnicas o sus objetivos. Realmente, aunque la idea general sea común, existen dos grandes diferencias de diseño entre una honeypot y una honeynet: por un lado, esta última evidentemente es una red completa que alberga diferentes entornos de trabajo, no se trata de una única máquina; por otro, los sistemas dentro de esta red son sistemas reales, en el sentido de que no simulan ninguna vulnerabilidad, sino que ejecutan aplicaciones típicas (bases de datos, sistemas de desarrollo, entre otros.) similares a las que se encuentran en cualquier entorno de trabajo ‘normal'. El objetivo de una honeynet no es la decepción, sino principalmente conocer los movimientos de un pirata en entornos semireales, de forma que aspectos como sus vulnerabilidades o sus configuraciones incorrectas se puedan extrapolar a muchos de los sistemas que cualquier empresa posee en la actualidad; de esta forma podemos prevenir nuevos ataques exitosos contra entornos reales. En el funcionamiento de una ‘red de miel' existen dos aspectos fundamentales y especialmente críticos, que son los que introducen la gran cantidad de trabajo de administración extra que una honeynet implica para cualquier organización. Por un lado, tenemos el control del flujo de los datos: es vital para la seguridad garantizar que una vez que un sistema dentro de la honeynet ha sido penetrado, este no se utilice como plataforma de salto para atacar otras máquinas, de ninguna organización; la ‘red de miel’ ha de permanecer perfectamente controlada, y por supuesto aislada del resto de los segmentos de la organización. En segundo lugar, otro aspecto básico es la captura de datos, la monitorización de las actividades que un atacante lleva a cabo en la honeynet. _________________________________________ 2 Honeypots son sistemas señuelo, que son diseñados para atraer un atacante potencial desde sistemas críticos. Capítulo I. Antecedentes - 10 - El objetivo principal en este tipo de sistemas es conocer los movimientos de la comunidad pirata para poder extrapolarlos a sistemas reales, por lo que también es muy importante para el correcto funcionamiento de una honeynet una correcta recolección de datos generados por el atacante: ha de ser capturada toda la información posible de cada acción, de una forma poco agresiva (esto es, sin tener que realizar grandes cambios en cada uno de los sistemas) y por supuesto sin que el atacante se entere. Además (muy importante), estos datos recolectados nunca se han de mantener dentro del perímetro de la honeynet, ya que si fuera así cualquier pirata podría destruirlos con una probabilidad demasiado elevada [2]. Como se ha mencionado que, los sistemas de detección de intrusos basados en red, son con diferencia los más utilizados actualmente en sistemas en explotación; no obstante, como casi cualquier herramienta relacionada con la seguridad, estos sistemas no son ninguna panacea, y su implantación ha de verse complementada con una correcta configuración de elementos como el cortafuegos corporativo o, por supuesto, los sistemas de detección basados en host. Ventajas de los NIDS: • Los NIDS bien configurados pueden monitorizar una gran extensión de red. • El desarrollo de un NIDS tiene poco impacto sobre una red existente. Los NIDS son normalmente dispositivos pasivos que escuchan en una red sin interferir con la operación cotidiana de la misma. De esta forma, es muy fácil readaptar una red, para incluir un NIDS basado en red con un mínimo esfuerzo • NIDS pueden ser muy seguros contra los ataques y también pueden ser invisibles a muchos atacantes. Capítulo I. Antecedentes - 11 - Desventajas de los NIDS: • Los NIDS pueden tener dificultad al procesar una gran cantidad de paquetes en una red muy robusta o demasiado ocupada, por lo tanto, puede fallar al momento de reconocer un ataque lanzado durante periodos de alto tráfico. Algunos vendedores han intentado resolver este problema, implementando el IDS completamente en hardware, el cual es mucho más rápido. • Muchas de las ventajas de los NIDS no aplica a muchas redes de módem basadas en switch. Los switches subdividen la red en pequeños segmentos y provee conexiones dedicadas entre el servicio de host y el mismo switch. Muchos switches no proporcionan puertos de monitoreo universal y esto limita el rango de monitoreo de un sensor NIDS a un solo host. • Los NIDS no pueden analizar información cifrada. Este problema ha incrementado en muchas organizaciones utilizando redes virtuales privadas. • Muchos NIDS no pueden decir si un ataque tuvo éxito; únicamente pueden percibir cuando un ataque ha iniciado. Esto quiere decir que después que un NIDS detectó un ataque, el administrador debe investigar manualmente cada ataque al host para determinar si este, fue realmente penetrado. • Algunos NIDS tienen problemas tratando con ataques basados en red que involucran paquetes fragmentados. Esos malformados paquetes causan que un IDS llegue a ser inestable y fracase [3]. Capítulo I. Antecedentes - 12 - 1.5 Diferentes Herramientas de IDS Para poder monitorizar y analizar el tráfico de una red es necesario utilizar un rastreador de paquetes (sniffer), dentro del cual se pueden detectar los diferentes tipo de problemas en ella, como los llamados cuello de botella, de igual forma puede capturar los datos que se transfieren dentro de la red. Debido a la importancia que tienen en el mercado, se hace mención dealgunos de ellos. • TCPDUMP. Te permite monitorizar tráfico de red en tiempo real. Los filtros que se pueden crear para mostrar tan sólo la información que interesa, hacen de tcpdump una herramienta muy potente para el análisis de tráfico en redes de comunicaciones. Tcpdump es una aplicación “peligrosa”, por lo que en los sistemas UNIX sólo se permite su utilización al usuario root. Tcpdump permite examinar todas las conversaciones, incluyendo mensajes de broadcast SMB y NMB. Mientras que sus capacidades en detección de errores están principalmente a nivel de capa de red OSI, todavía se puede usar su salida para obtener una idea general de qué están intentando hacer el servidor y el cliente. • TRIPWIRE. Es un programa de computador Código Abierto3 (Open Source, en inglés) consistente en una herramienta de seguridad e integridad de datos. Tripwire es útil para monitorizar y alertar de cambios específicos de ficheros en un rango de sistemas. Para mejor eficacia, se recomienda instalar el programa antes de haber conectado el computador por primera vez a Internet a fin de crear una base de datos de los ficheros existentes en el sistema, para poder contrastar los posibles cambios en éstos una vez conectado a la red. Tripwire funciona correctamente en sistemas operativos GNU/Linux. ____________________ 3 Código Abierto. Es el término con el que se conoce al software distribuido y desarrollado libremente. Capítulo I. Antecedentes - 13 - • NGREP. Muestra y busca paquetes. Ngrep se esfuerza por proveer de la mayoría de características comunes del "grep" de GNU, aplicándolas a la capa de red del modelo de referencia OSI. Actualmente reconoce TCP, UDP, e ICMP sobre Ethernet, PPP, SLIP e interfaces nulas, y comprende la lógica de un filtro "bpf" de la misma manera que herramientas más comunes de sniffing como tcpdump y snoop. • SNORT. Snort es utilizado como un 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 que corresponden a ataques, barridos o aprovechar alguna vulnerabilidad, todo esto en tiempo real. Está disponible gratuitamente bajo licencia GPL, y funciona en plataformas Windows y UNIX/Linux. Dispone de una gran cantidad de filtros o patrones predefinidos, así como actualizaciones constantes ante casos de ataques, barridos o vulnerabilidades que vayan siendo detectadas a través de los distintos boletines de seguridad. • NWATCH. Se puede entender como un analizador de puertos pasivo, que está solamente interesado en tráfico IP y de organizar los resultados como un explorador de puertos. Esto agrega la ventaja de que cualquier herramienta que funcione encendiendo tal salida (NDiff) puede utilizar los datos. Para la seguridad de la red, NWatch es un complemento excelente al barrido de puertos regular de sus redes. Por defecto, NWatch permanece activo indefinidamente hasta que recibe un SIGINT (CTRL-c). Durante ese tiempo mira la interfaz por defecto (eth0), siguiendo cada combinación del IP host/port que descubre. En el último caso sería típicamente útil para espiar o quizás mostrar y analizar los patrones del uso neto más bien que para una supervisión de la seguridad. • ETTERCAP. Es un sniffer/interceptor/logger para redes LAN con switches, que soporta la disección activa y pasiva de muchos protocolos (incluso Capítulo I. Antecedentes - 14 - cifrados) e incluye muchas características para el análisis de la red y del host (anfitrión). Entre sus funciones, más destacadas se encuentran: o Inyección de caracteres en una conexión establecida emulando comandos o respuestas mientras la conexión está activa. o Compatibilidad con SSH1: Puede interceptar users y passwords incluso en conexiones "seguras" con SSH. o Compatibilidad con HTTPS: Intercepta conexiones mediante http SSL (supuestamente seguras) incluso si se establecen a través de un proxy. o Intercepta tráfico remoto mediante un túnel GRE: Si la conexión se establece mediante un túnel GRE con un router Cisco, puede interceptarla y crear un ataque "Man in the Middle". "Man in the Middle" contra túneles PPTP (Point-to-Point Tunneling Protocol). o Soporte para Plug-ins. En este trabajo se enfocará principalmente al rastreador de paquetes SNORT, el cual presenta la característica de trabajar como un sistema detector de intrusiones basado en red. - 15 - CAPITULO II SNORT COMO IDS Capítulo II. SNORT como IDS - 16 - 2.1 IDS de red: SNORT SNORT se puede clasificar como un sniffer4 de paquetes, es uno de los más comunes y tiene la característica principal de actuar como sistema de detección de intrusiones basado en red (NIDS). Implementa un motor de detección de ataques y barrido de puertos que permite registrar, alertar y responder ante cualquier uso indebido [5], en redes de tráfico moderado. Estos usos indebidos - o cuanto menos sospechosos - se reflejan en una base de datos formada por patrones de ataques, barridos, intentos de aprovechar alguna vulnerabilidad, análisis de protocolo, etc.; dicha base de datos se puede descargar también desde la propia página web de SNORT, donde además se pueden generar bases de patrones ‘a medida' de diferentes entornos (por ejemplo, ataques contra servidores web, intentos de negaciones de servicio, exploits...). El archivo que se utilice en el entorno será la base para el correcto funcionamiento del sistema de detección de intrusiones. Es de fácil configuración, y puede analizar el tráfico de una red en tiempo real, así como registrar paquetes en redes IP, y sobre todo el ser un software gratuito, lo convierten en una buena elección para poder implementar un IDS. SNORT tiene la ventaja de funcionar sobre una gran cantidad de plataformas. Está basado en las librerías libcap, esto es, cualquier plataforma que acepte estas librerías puede trabajar con SNORT. La colocación de SNORT en una red puede realizarse según el tráfico que se quiere vigilar: paquetes que entran, paquetes que salen, dentro del cortafuego, fuera del cortafuego, y en realidad prácticamente donde se desee colocar. Para configurar SNORT como un sistema de detección de intrusiones, se requiere ____________________ 4 Sniffer es un programa de captura de las tramas de red. Capítulo II. SNORT como IDS - 17 - evidentemente el programa, está disponible bajo la licencia GPL5. Dispone de actualizaciones constantes ante casos de ataques, barrido o vulnerabilidades que vayan siendo detectadas a través de los distintos boletines de seguridad. Además, para compilarlo correctamente es necesario disponer de las librerías LibpCap, o WinpCap, un interfaz para tratamiento de paquetes de red desde espacio de usuario, y es recomendable también (aunque no obligatorio) instalar Libnet, librería para la construcción y el manejo de paquetes de red. Una vez 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 más graves en la detección de intrusos. Por lógica, uno tiende a pensar que el sensor proporcionará mejores resultados cuantos más patrones de ataques contenga en su base de datos; nada más lejos 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 se sitúa el sensor en una zona desmilitarizada donde únicamente se ofrece el servicio de web. Lo lógico es que las políticas implementadas en el cortafuegos nisiquiera dejen pasar tráfico hacia puertos que no sean los de los servidores web pero, incluso en caso de que el potencial ataque se produjera entre máquinas del propio segmento, se debe evaluar con mucho cuidado si realmente vale la pena sobrecargar la base de datos con patrones que permitan detectar estos ataques. Evidentemente, cuanta más azúcar más dulce, pero si el sensor ha de analizar todo el tráfico, quizás mientras trata de decidir si un paquete entre dos máquinas protegidas se adapta a un patrón se está dejando pasar tramas provenientes del exterior que realmente representan ataques: se debe tener presente que el sniffer no detendrá el tráfico que no sea capaz de analizar para hacerlo más tarde, sino que simplemente lo dejará pasar. Así, se introduce en la base de patrones de ataques los justos para detectar actividades sospechosas contra una red. ____________________ 5 General Public License. Es una licencia creada por la Free Software Foundation en 1989 (la primera versión), y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Capítulo II. SNORT como IDS - 18 - En segundo lugar, pero no menos importante, es necesario estudiar los patrones de tráfico que circulan por el segmento donde el sensor escucha para detectar falsos positivos y, o bien reconfigurar la base de datos, para eliminar los patrones que generan esas falsas alarmas. Aunque suene extraño, si un patrón genera un número considerable de falsos positivos, se debe plantear si se requiere o votar por su eliminación: simplemente no se podría decidir si se trata de verdaderas o de falsas alarmas. Esto es especialmente crítico si se lanzan respuestas automáticas contra las direcciones ‘atacantes' (por ejemplo, detener todo su tráfico en el cortafuegos): volviendo al ejemplo de la zona desmilitarizada con servidores web, se puede llegar al extremo de detener a simples visitantes en las páginas simplemente porque han generado falsos positivos; aunque en un entorno de alta seguridad quizás vale la pena detener muchas acciones no dañinas con tal de bloquear también algunos ataques (aunque constituiría una negación de servicio en toda regla contra los usuarios que hacen uso legítimo de los sistemas), en un entorno normal de producción esto es impensable. Seguramente será más provechoso detectar y detener estos ataques por otros mecanismos ajenos al sensor. En resumen, se debe de adaptar al entorno de trabajo, de una forma muy fina, la base de datos de patrones de posibles ataques. Quizás valga la pena perder el tiempo que sea necesario en esta parte de la implantación, ya que eso ahorrará después muchos análisis de falsas alarmas o la detección de algún otro tipo de ataque. SNORT genera archivos .log en el directorio /var/log/snort/ si no se le indica lo contrario. En ese directorio se encuentra un fichero denominado alert con las actividades que se vayan registrando, también existe el ‘packet logging’ que es una serie de subdirectorios cuyos nombres son las direcciones IP de las máquinas de las que se detecta alguna actividad, este es configurable. Como lo que se busca es básicamente la generación de alarmas, independiente del packet logging, no es necesario generar estos directorios. Capítulo II. SNORT como IDS - 19 - En principio, si se deja que el sensor analice el tráfico antes de que sea filtrado en el cortafuegos, se estarían detectando todos los ataques reales que se lanzan contra la red, sin ningún tipo de filtrado que pueda detener las actividades de un pirata; no obstante, probablemente lo que realmente interesa no es detectar todos estos intentos de ataque (aunque nunca está de más permanecer informado en este sentido), sino detectar el tráfico sospechoso que atraviesa el cortafuegos y que puede comprometer a los servidores. Por tanto, es recomendable [6] emplazar el sensor del sistema de detección de intrusiones en la zona protegida; de cualquier forma, los potenciales ataques que no lleguen al mismo, quedarán registrados en los archivos .log del cortafuego, e incluso serán neutralizados en el mismo. Como el sensor ha de analizar todo el tráfico dirigido a las máquinas protegidas, si se encuentra en un entorno donde dichas máquinas se conecten mediante un concentrador (hub) o mediante otras arquitecturas en las que cualquiera de ellas vea (o pueda ver) el tráfico de las demás, no hay muchos problemas de decisión sobre dónde situar al sensor: se puede hacer en cualquier parte del segmento. Sin embargo, si los sistemas se conectan con un switch la cuestión se complica un poco, ya que en las bocas de este elemento se verá únicamente el tráfico dirigido a las máquinas que estén conectadas a cada una de ellas; en este caso, existen varias opciones. Una de ellas puede ser modificar por completo - con todo lo que esto implica - la arquitectura de red para integrar un concentrador por el que pasen los paquetes ya filtrados antes de llegar a las máquinas del switch. No obstante, suelen existir alternativas más sencillas y cómodas, como la replicación de puertos que se puede configurar en la mayoría de switches; la idea es muy simple: todo el tráfico dirigido a determinada boca del switch se monitoriza y se duplica en otra boca. Así, únicamente se tiene que configurar este port mirroring y replicar la boca por la que se dirige el tráfico hacia el segmento de máquinas a monitorizar, enviándolo también a una segunda boca en la que se concentraría el sensor. Capítulo II. SNORT como IDS - 20 - 2.2 Estructura de las reglas Se basan en una serie de normas que se definen inicialmente como descripción, Cabecera y Opciones. Luego de la descripción de la regla, se define en la cabecera la acción, protocolos, Ips, máscaras de subred, puertos origen y destino y los datos de destino del paquete. En la sección de opciones se contienen los mensajes y la información necesaria para tomar la decisión. Pero toda esta teoría se expone perfectamente en un ejemplo como puede ser que el IDS de aviso al detectar la descarga de un archivo .mp3. Una alternativa inicial y ciento por ciento didáctica es definir la siguiente regla: Alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg .Se está descargando un archivo mp3. ;flags:AP;content:. .mp3. ;) Para comprender fácilmente este ejemplo es conveniente tener nociones de TCP/IP, concretamente los flags (ack, push, etc.). Para generar este tipo de reglas se puede utilizar un análisis de tráfico mediante Ethereal o TCPDump. Otro ejemplo, en este caso que alerta un ataque de fingerprint mediante técnicas conocidas que utiliza Nmap, es reaccionar ante el envío de los flags en conjunto de SYN . FIN . PUSH . URGENT. scan.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap fingerprint attempt";flags:SFPU; reference:arachnids,05;) 2.3 Componentes de SNORT SNORT se encuentra dividido en varios componentes que interactúan entre sí y forman un IDS en su totalidad. • Decodificador de paquetes Capítulo II. SNORT como IDS - 21 - • Preprocesadores • Motor de detección • Sistema de alerta y logueo • Módulos de salida 2.1 Diagrama de los componentes de SNORT • Decodificador de paquetes Éste decodificador toma los paquetes provenientes de las interfaces de red (no importando su tipo), los prepara y envía al preprocesador o al motor de detección. • Preprocesador Los preprocesadores son módulos o plugins que se pueden utilizar con Snort para modificar los paquetes de datos antes de que sean atrapados por el motor de detección. Los preprocesadores pueden defragmentar paquetes, decodificar URLs HTTP, reensamblar streams TCP, etc. Capítulo II. SNORT como IDS - 22 - Un ejemplo de preprocesador es el Arpspoof, el cúal dispone de cuatro mecanismosde detección: o Para cada una de las peticiones ARP detectadas se valida la dirección origen de Ethernet contra la dirección origen del paquete ARP. o Para cada una de las respuestas ARP, se comparan las direcciones origen y destino, si alguna de estas no coincide Snort genera una alerta. o También se generan alertas para peticiones ARP unicast (en lugar de broadcast). o Se pueden comprobar los paquetes ARP basados en una lista de direcciones IP/MAC previamente generada por el administrador (se puede implementar solo en redes pequeñas). Este es un ejemplo práctico de lo que puede hacer un preprocesador, aunque para el caso de este tipo de ataques la capacidad de SNORT se denota que es limitada. • Motor de detección Éste es el componente más importante de Snort, responsable de detectar si existe alguna actividad de intrusión en los paquetes. Este motor emplea las reglas descritas anteriormente y verifica si la condición de las mismas es positiva con alguno de los paquetes observados. De allí se determina la acción a seguir que puede ser tanto un acceso en archivo o base de datos como el envío de una alerta al administrador. El tiempo de análisis de los paquetes es un factor crítico dentro del sistema, el cual depende directamente con la cantidad de reglas analizadas, la potencia de la máquina que se encuentra corriendo SNORT y la carga de la red, entre otras cosas. Capítulo II. SNORT como IDS - 23 - • Sistema de alertas y logueo Dependiendo de lo que el motor de detección encuentra en los paquetes, este sistema generará alertas o salidas al archivo .log del SNORT (ubicado generalmente en /var/log/snort) inicialmente configurado para mantener dos formatos: Un aviso en texto claro y un detalle del tráfico en formato tcpdump. • Módulo de salida También llamados plugins de salida, pueden realizar diferentes operaciones de envío de alertas o logueo de eventos, dependiendo básicamente de la configuración del sistema. Los más utilizados son [7]: o Logueo simple en archivo de texto (Ej. /var/log/snort/alert) o Intercambio de información a través de mensajes SNMP. o Envío de mensajes al syslog. o Logueo de eventos en bases de datos como MySQL u Oracle. o Generación de XMLs. o Modificación de reglas de ruteo o cortafuegos. o Envío de mensajes a máquinas Windows a través de SMB. o Y muchas otras herramientas como la utilización de alertas por mails o SMSs. Capítulo II. SNORT como IDS - 24 - 2.4 Ejemplo de SNORT A continuación se describe el funcionamiento básico de SNORT y algunas de las diferentes modalidades en que se puede utilizar. Para inicializar se escribe la siguiente instrucción: C:\Snort20\bin>snort Y se despliega algo similar a esto, en pantalla: -*> Snort! <*- Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72) By Martin Roesch (roesch@sourcefire.com, www.snort.org) 1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike) .8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com) El formato general de utilizar una instrucción SNORT es la siguiente: snort [-opción] <opciones de filtro> snort /SERVICE /INSTALL [-opciones] <opciones de filtro> snort /SERVICE /UNINSTALL snort /SERVICE /SHOW Las diferentes opciones que ofrece SNORT son, la descripción de estas opciones se deja en su versión original: -A Set alert mode: fast, full, console, or none (alert file alerts only) -b Log packets in tcpdump format (much faster!) -c <rules> Use Rules File <rules> -C Print out payloads with character data only (no hex) -d Dump the Application Layer -e Display the second layer header info -E Log alert messages to NT Eventlog. (Win32 only) Capítulo II. SNORT como IDS - 25 - -f Turn off fflush() calls after binary log writes -F <bpf> Read BPF filters from file <bpf> -h <hn> Home network = <hn> -i <if> Listen on interface <if> -I Add Interface name to alert output -k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none) -l <ld> Log to directory <ld> -L <file> Log to this tcpdump file -n <cnt> Exit after receiving <cnt> packets -N Turn off logging (alerts still work) -o Change the rule testing order to Pass|Alert|Log -O Obfuscate the logged IP addresses -p Disable promiscuous mode sniffing -P <snap> Set explicit snaplen of packet (default: 1514) -q Quiet. Don't show banner and status report -r <tf> Read and process tcpdump file <tf> -R <id> Include 'id' in snort_intf<id>.pid file name -s Log alert messages to syslog -S <n=v> Set rules file variable n equal to value v -T Test and report on the current Snort configuration -U Use UTC for timestamps -v Be verbose -V Show version number -W Lists available interfaces. (Win32 only) -w Dump 802.11 management and control frames -X Dump the raw packet data starting at the link layer -y Include year in timestamp in the alert and log files -z Set assurance mode, match on established sesions (for TCP) -? Show this information Las opciones de filtro, son opciones BPF estándar, como en TCPDump. Un ejemplo mas concreto de SNORT se muestra a continuación: C:\Snort20\bin>snort -v Running in packet dump mode Log directory = log Capítulo II. SNORT como IDS - 26 - Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF} --== Initializing Snort ==-- Initializing Output Plugins! Decoding Ethernet on interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA- 81175A8C32BF} --== Initialization Complete ==-- -*> Snort! <*- Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72) By Martin Roesch (roesch@sourcefire.com, www.snort.org) 1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike) 1.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com) 05/21-11:00:28.593943 ARP who-has 192.168.2.92 tell 192.168.2.60 05/21-11:00:28.594419 ARP who-has 192.168.2.8 tell 192.168.2.60 05/21-11:00:28.594544 ARP who-has 192.168.2.93 tell 192.168.2.60 05/21-11:00:30.467265 192.168.2.5:1025 -> 192.168.2.1:139 TCP TTL:128 TOS:0x0 ID:16685 IpLen:20 DgmLen:104 DF ***AP*** Seq: 0x6B703 Ack: 0x2266A0C Win: 0x2238 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 05/21-11:00:30.467731 192.168.2.1:139 -> 192.168.2.5:1025 TCP TTL:128 TOS:0x0 ID:47513 IpLen:20 DgmLen:1500 DF Con esta opción -v se inicia SNORT en modo sniffer visualizando en pantalla las cabeceras de los paquetes TCP/IP, es decir, en modo sniffer. Esta opción en modo verbouse y mostrará las cabeceras IP, TCP, UDP y ICMP. Si se desea, además, visualizar los campos de datos que pasan por la interface de red, se añade -d. Capítulo II. SNORT como IDS - 27 - C:\Snort20\bin>snort -vd Running in packet dump mode Log directory = log Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF} =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 05/21-11:06:18.943887 192.168.4.5:3890 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:33216 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 05/21-11:06:18.962018 192.168.4.5:3890 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:33217 IpLen:20 DgmLen:681 DF ***AP*** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20 47 45 54 20 68 74 74 70 3A 2F 2F 77 77 77 2E 6F GET http://www.x 6D 65 6C 65 74 65 2E 63 6F 6D 2E 62 72 2F 73 75 xxxx.com.br/xx 70 65 72 6F 6D 65 6C 65 74 65 2F 64 6F 77 6E 6C xxxxxxx/downl 6F 61 64 73 2F 64 65 66 61 75 6C 74 2E 61 73 70 oads/default.asp 20 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D HTTP/1.0..User-41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 Agent: Mozilla/4 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65 3B 20 .0 (compatible; 4D 53 49 45 20 36 2E 30 3B 20 57 69 6E 64 6F 77 MSIE 6.0; Window 73 20 4E 54 20 35 2E 30 29 20 4F 70 65 72 61 20 s NT 5.0) Opera 37 2E 31 31 20 20 5B 65 6E 5D 0D 0A 48 6F 73 74 7.11 [en]..Host 3A 20 77 77 77 2E 6F 6D 65 6C 65 74 65 2E 63 6F : www.xxxxx.co 6D 2E 62 72 0D 0A 41 63 63 65 70 74 3A 20 74 65 m.br..Accept: te 78 74 2F 68 74 6D 6C 2C 20 69 6D 61 67 65 2F 70 xt/html, image/p 6E 67 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C 20 ng, image/jpeg, 69 6D 61 67 65 2F 67 69 66 2C 20 69 6D 61 67 65 image/gif, image 2F 78 2D 78 62 69 74 6D 61 70 2C 20 2A 2F 2A 3B /x-xbitmap, */*; 71 3D 30 2E 31 0D 0A 41 63 63 65 70 74 2D 4C 61 q=0.1..Accept-La Añadiendo la opción -e, SNORT mostrará información más detallada, como las cabeceras a nivel de enlace. Capítulo II. SNORT como IDS - 28 - Con estas opciones y dependiendo del tráfico en la red, se puede observar una gran cantidad de información desplegada en pantalla, con lo cual se hace interesante registrar, guardar estos datos a disco para su posterior estudio. Se configuraría entonces SNORT como packet logger o registro de paquetes. C:\Snort20\bin>snort -dev -l ./log La opción -l indica a SNORT que debe guardar los archivos .log en un directorio determinado. Dentro de la carpeta log se creará una estructura de directorios donde se archivarán los archivos .log. Se puede indicar la IP de la red a registrar ( -h ) y que el formato de los archivos .log sea en modo binario (-b), es decir, el modo que entiende TCPDump o Windump, para estudiar más a fondo con los potentes filtros de estos programas los archivos log de SNORT. La salida del log en el caso de la opción de salida binaria ya no será una estructura de directorios, si no, un sólo archivo. C:\Snort20\bin>snort -vde -l ./log -h 192.168.4.0/24 Running in packet logging mode Log directory = ./log C:\Snort20\bin>snort -l ./log -b Running in packet logging mode Log directory = ./log Usando la opción -b no hará falta indicarle IP alguna de red (-h). Guardará todo en un mismo archivo y recogerá datos de toda la red. Tampoco serán necesarias las opciones -de y -v. El archivo generado por SNORT en modo binario también se puede leer con este usando la opción -r nombrearchivo.log. Capítulo II. SNORT como IDS - 29 - Otra opción a tomar en cuenta es -i para indicar a SNORT que interfaz de red usar en el caso de que se tenga dos o más. Se hace de distinta forma dependiendo si se está haciendo uso de SNORT para Win32 o para Linux/UNIX. Para averiguar las interfaces de se encuentran disponibles, en Win32 por ejemplo, se utiliza la opción -W. C:\Snort20\bin>snort -vde -i 1 # snort -vde -i eth0 C:\Snort20\bin>snort -W Se pueden añadir una serie de filtros, a parte de las opciones, para optimizar los resultados obtenidos. Estos filtros se añadirán en el mismo formato que usa programas como TCPDump ya que usan las mismas librerías de captura de paquetes (LibpCap o WinpCap). C:\Snort20\bin>snort -vd host 192.168.4.5 and dst port 8080 Running in packet dump mode Log directory = ./log Initializing Network Interface eth0 --== Initializing Snort ==-- Initializing Output Plugins! Decoding Ethernet on interface eth0 --== Initialization Complete ==-- -*> Snort! <*- Version 2.0.0 (Build 72) By Martin Roesch (roesch@sourcefire.com, www.snort.org) 07/15-12:34:26.059644 192.168.4.5:4533 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:16544 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xC47AC53E Ack: 0xC83C2362 Win: 0xFAF0 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Capítulo II. SNORT como IDS - 30 - 07/15-12:34:26.059880 192.168.4.5:4533 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:16545 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xC47AC53E Ack: 0xC83C31E4 Win: 0xFAF0 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Snort aceptará también filtros más avanzados en su modo sniffer: C:\Snort20\bin>snort -vd icmp[0] = 8 and dst host 192.168.4.1 C:\Snort20\bin>snort -vd icmp[0] != 8 and icmp[0] != 0 C:\Snort20\bin>snort -vd 'udp[0:2] < 1024' and host 192.168.4.1 El modo detección de intrusos de red se activa añadiendo a la línea de comandos de SNORT la opción -c snort.conf. En este archivo, snort.conf, se guarda toda la configuración de las reglas, preprocesadores y otras configuraciones necesarias para el funcionamiento en modo NIDS C:\Snort20\bin>snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf Con al opción -D se indica que corra como un servicio. Esto es sólo válido para las versiónes Linux/UNIX: # snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf –D Hay varias formas de configurar la salida de SNORT, es decir, las alertas, el modo en que se almacenarán estas en el archivo alert.ids. SNORT dispone de siete modos de alertas en la línea de órdenes, completo, rápido, socket, syslog, smb (WinPopup), consola y ninguno, las cuáles se listan a continuación: Capítulo II. SNORT como IDS - 31 - • Full: El modo de Alerta Completa regresa información sobre: tiempo, mensaje de la alerta, clasificación, prioridad de la alerta, IP y puerto de origen/destino e información completa de las cabeceras de los paquetes registrados. C:\Snort20\bin>snort -A full -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf [**] [1:620:2] SCAN Proxy (8080) attempt [**] [Classification: Attempted Information Leak] [Priority: 2] 09/19-14:53:38.481065 192.168.4.3:3159 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF ******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28 TCP Options (4) => MSS: 1456 NOP NOP SackOK Información de la cabecera del paquete: TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF ******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28 TCP Options (4) => MSS: 1456 NOP NOP SackOK • Fast: El modo Alerta Rápida regresa información sobre: tiempo, mensaje de la alerta, clasificación, prioridad de la alerta, IP y puerto de origen y destino. C:\Snort20\bin>snort -A fast -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf 09/19-19:06:37.421286 [**] [1:620:2] SCAN Proxy (8080) attempt [**] [Classification: Attempted Information Leak] [Priority: 2] ... ... {TCP} 192.168.4.3:1382 -> 192.168.4.15:8080 • Socket: Manda las alertas a través de un socket, para que las escuche otra aplicación. Está opción es para Linux/UNIX. # snort -A unsock -c snort.conf • Syslog: Envía las alarmas al syslog Capítulo II. SNORT como IDS - 32 - C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -s 192.168.4.33:514 • SMB: Permite a SNORT realizar llamadas al cliente de SMB (cliente de Samba, en Linux), y enviar mensajes de alerta a hosts Windows (WinPopUp). Para activar este modo de alerta, se debe compilar SNORT con el conmutador de habilitar alertas SMB (enable -smbalerts). Evidentemente este modo es para sistemas Linux/UNIX. Para usar esta característica enviando un WinPopUp a un sistema Windows, se agrega a la línea de comandos de SNORT: -M WORKSTATIONS. • Console: Imprime las alarmas en pantalla. C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf • None: Desactiva las alarmas. # snort -A none -c snort.conf • Eventlog: Registra las alertas para visualizarse a través del visor de sucesos de un sistema Windows. Esta opción se activará mediante -E y sólo para Win32 [8]. 33 CAPITULO III IMPLEMENTACIONDE UN IDS Capítulo III. Implementación de un IDS - 34 - 3.1 Escenario de implementación. En este apartado se verán cuáles son los elementos necesarios para implementar un IDS de red o NIDS en una organización o institución. Existen varios NIDS comerciales sin embargo, se utilizara software Open Source de Snort para Windows, se escogió esta plataforma porque es una alternativa por infraestructura comercial a la cual se puede economizar y existe soporte en la mayor parte de las empresas; también se seleccionó Snort ya que es una organización que se adapta a los estándares recomendados para las buenas prácticas de seguridad informática. En la actualidad los circuitos telefónicos, las redes de computadoras son canales de comunicación compartidos, el compartir significa que las computadoras pueden recibir información proveniente de otras máquinas, al capturar información proveniente de otra parte de la red, a este proceso se le llama “sniffing” [12] (tarea primordial del NIDS). El sistema de Snort es una herramienta, que en pleno funcionamiento consume recursos de procesamiento, y la razón por la que éste demande recursos, es por el mecanismo de rastreo en la red de paquetes, también está en proceso de análisis y a su vez alerta de los posibles incidentes que pudieran considerarse como una amenaza de seguridad [13]; para ello se requieren las siguientes características de rendimiento del equipo en el que se desarrollara el sistema, los cuales son: • Equipo Dell • Procesador Intel Pentium Dual Core de 2.1 GHz • 3 GB de memoria en Ram • Sistema Operativo Windows 7 de 64 bits • Adaptador de red integrado Marvell Yukon Capítulo III. Implementación de un IDS - 35 - Estas características son importantes en la implementación de un NIDS ya que ciertas estructuras de red que son demandantes en la capacidad con los equipos, así como el tráfico excesivo que pudiera presentarse, este no dará abasto para realizar el análisis completo y no lograr su buen funcionamiento, teniendo como resultados, falsos negativos por la dificultad al procesar gran cantidad de paquetes. En la figura 3.1 se muestra el modelo para sniffear la red; el cual está constituido por varios clientes que pueden realizar peticiones entre ellos y/o al web server, el NIDS estará conectado al mismo medio que estos comparten, así mismo detectara las peticiones que hay entre todos y lograra monitorear en tiempo real su comportamiento, así como almacenarlo a través de una base de datos o un archivo como bitácora. Web Server NIDS Cliente A Cliente B Cliente C Figura 3.1 Escenario de implementación de un NIDS. Se determino este modelo para comprender el funcionamiento que por simpleza logre facilitar la explicación en cuanto a la lógica de la red, así como plantear un orden en cuanto a las peticiones para el NIDS. Capítulo III. Implementación de un IDS - 36 - 3.2 Instalación del software. El software que se instaló se consultó en los sitios oficiales de internet, y las versiones son las siguientes: • Snort versión 2.8.4 • Winpcap versión 4.1.1 • Xampp versión 1.6.4 Snort es el sistema de detector de intrusos basado en red, es muy flexible ofrece capacidades de almacenamiento de comportamientos tanto en bitácoras como una base de datos, implementa un motor de detección de ataques y barrido de puertos que permite registrar y alertar ante una anomalía previamente definida. La característica más apreciada es su subsistema flexible de firmas de ataques. Snort tiene una base de datos de ataques que se actualiza constantemente la cual se puede añadir a través de internet. Los usuarios pueden crear firmas de seguridad basada en las categorías de los nuevos ataques de red y enviarla a la lista de correo de firmas de seguridad de Snort. Para mayor referencia ingresar al sitio oficial http://www.snort.org. Una vez descargado el programa del sitio anteriormente mencionado, se inicia la instalación de Snort como se muestra en la siguiente ventana de la figura 3.2, la cual contiene la licencia libre GPL que es compatible para la versión que se implementara en el sistema operativo que es Windows, uno de los términos que expresa durante esta parte de la instalación es que el administrador de esta herramienta es el responsable en cuanto a su configuración asi como su desempeño de la seguridad de la red, para eso esta disponible el manual en el sitio ofical. Capítulo III. Implementación de un IDS - 37 - Figura 3.2 Iniciando la instalación de Snort. En la figura 3.2 muestra información de la instalación iniciada, se selecciona la opción ‘I Agree’. En la siguiente ventana se selecciona ‘I do not plan to log to a database, or I am planning to log to one of the databases listed Above’, y oprimir ‘next’ como se muestra en la figura 3.3. Figura 3.3 Opciones de instalación En la figura 3.3 en la primera opción muestra que no se cuenta con una base de datos pero se puede realizar dicha tarea en otro momento, en la segunda opción es para direccionar el log para solo clientes Sql server, la tercera opción hace referencia Capítulo III. Implementación de un IDS - 38 - a clientes oracle y en la última parte para protocolo de comunicación IPv6, para fines de esta investigación solamente se habilita la primera opción y oprimir ‘next’. En la siguiente ventana se muestran los componentes que se instalaran en Snort, en este caso se seleccionan todos como lo muestra en la figura 3.4, después seleccionar ‘next’. Figura 3.4 Componentes necesarios para instalar Snort. En la siguiente ventana se conserva la ruta de instalación como se muestra en la figura 3.5 que es C:\Snort; si se contara con algún requerimiento de instalarlo en otra localidad fuera de la unidad propuesta, los parámetros de configuración tendrán que estar dirigidos a dicha ruta para que este funcione. Para fines de esta investigación no se propone otra localidad diferente. Figura 3.5 Ruta de instalación de Snort. Capítulo III. Implementación de un IDS - 39 - Después se selecciona ‘next’, si todo marcha bien el proceso de instalación se mostrara la figura 3.6 que son dos ventanas, la primera es una ventana grande con referencias de lo instalado así como el nombre de los módulos instalados; y la segunda hace una clara referencia de que requiere Winpcap para que este funcione, así también en la misma ventana hace referencia a las especificaciones al archivo de configuración snort.conf. Figura 3.6 Instalación exitosa de Snort. Para mayor información de los modos de configuración de Snort también está disponible el manual en línea de la página oficial, y por último se selecciona ‘aceptar’, la instalación del NIDS ha terminado. Pcap es una interfaz de una aplicación de programación para captura de paquetes. La implementación para sistemas basados en UNIX se conoce como libpcap, es una herramienta open source escrita en C y es portable entre un gran número de sistemas operativos [14]; mientras que en Windows recibe el nombre de Winpcap. Winpcap es la herramienta estándar de la industria para acceder a la conexión entre capas de red en entornos Windows. Permite a las aplicaciones capturar y transmitir Capítulo III. Implementación de un IDS - 40 - los paquetes de red puenteando la pila de protocolos, a demás filtra paquetes a nivel núcleo, genera un motor de estadística de red y soporta captura de paquetes remotos. El sitio oficial es http://www.winpcap.org, esta herramienta es requerida para la instalación y funcionamiento de Snort. Es relevante remarcar que este programa es utilizado por otras herramientas dedicadas al análisis y tráfico de red como tcpdump, Wireshark, Nmap, Cain & Abel. Una vez descargado elinstalador del sitio oficial, se inicia la instalación de Winpcap la cual mostrara la ventana siguiente de la figura 3.7. Figura 3.7 Iniciando la instalación de WinPcap 4.1 CACE Technologies, Inc. ofrece soporte en línea para desarrolladores con diversos ambientes en el análisis de redes orientado a la captura de paquetes de Winpcap entre otros como los que se mencionaron anteriormente. También se puede ver en la figura 3.8 durante la instalación que automáticamente detecta el sistema operativo, el kernel en el que trabaja el sistema y algunos archivos que son librerías para el correcto funcionamiento de Winpcap. Capítulo III. Implementación de un IDS - 41 - Figura 3.8 Opciones de instalación de WinPcap. Si todo marcha bien, se ha cumplido con lo requerido para instalar WinPcap de dicha versión y mostrara la última ventana de instalación como se muestra en la figura 3.9 al cual se selecciona ‘finish’. Figura 3.9 Finalizando la instalación de WinPcap. Xampp es un servidor independiente de plataforma, open source, que consiste principalmente en la base de datos MySQL, el servidor Web Apache y los intérpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X para cualquiera de los diferentes sistemas operativos, Apache, MySQL, PHP y Perl. Capítulo III. Implementación de un IDS - 42 - El sitio oficial de Xampp es http://www.apachefriends.org/es/xampp.html, para descargar gratuitamente. Durante la instalación mostrara ventanas como en la primera parte se selecciona el lenguaje por defecto en español. En el proceso preguntara el directorio de instalación, por lo regular es en archivos de programa, no modificar este criterio se deja tal cual y de ahí inicia el proceso de instalación como se muestra en la figura 3.10. Figura 3.10 Instalación de Xampp 1.5.3 Posteriormente al terminar la instalación preguntara si se requiere que se active como servicio Apache y MySQL como se muestra en la figura 3.11 al cual se selecciona ‘sí’. Figura 3.11 Activación de servicio de Apache, MySQL Capítulo III. Implementación de un IDS - 43 - En la siguiente ventana pregunta si se requiere el servicio de Apache aun que ya se selecciono que ‘si’, se mostrara la siguiente figura 3.12 observando los puertos disponibles para Apache. Figura 3.12 Servicios y puertos asignados de Apache. En la siguiente ventana muestra si se requiere MySQL como servicio de igual forma se selecciona ‘aceptar’. A continuación muestra que se han hecho los cambios y la asignación de puerto como servicio como se muestra en la figura 3.13. Figura 3.13 MySQL asignado al puerto 3306 En el siguiente proceso pregunta si se requiere iniciar automáticamente los servicios, se selecciona ‘sí’, y también si se requiere iniciar los servicios, se selecciona ‘aceptar’. Se mostrara la siguiente ventana que se ha instalado correctamente estos servicios como lo muestra la figura 3.14. Figura 3.14 Instalación satisfactoria de Xampp. Capítulo III. Implementación de un IDS - 44 - En seguida oprimir que si se requiere ver en ese momento el Panel de Control el cual mostrara la figura 3.15. Figura 3.15 Panel de control. Como se puede mostrar en la figura 3.15 los módulos que se instalaron están trabajando como servicio. A continuación se inicia internet explorer y en la barra de dirección se escribe ‘http:\\localhost\’ lo cual mostrara el administrador del servidor Xampp ver figura 3.16, como se puede apreciar en la figura el administrador de servicios de Xampp es amigable para configurar los componentes que en instalación fueron seleccionados. Figura 3.16 Xampp para Windows servicios instalados. Capítulo III. Implementación de un IDS - 45 - 3.3 Configuración de SNORT. Una vez instalado Snort el siguiente paso es configurar Snort en la ruta que se instaló C:\Snort\etc el archivo snort.conf y para su modificación se utiliza un editor de textos como wordpad o notepad, se sugiere wordpad ya que son demasiadas líneas de código al cual no deberá cambiar en cuanto al formato y su orden. 3.3.1 Configuración de red. La configuración de red está dada por la variable var HOME_NET any Existen varios modos de configuración con dicha variable. Tipo de red Utilizando la variable de configuración Tipo C var HOME_NET 192.168.1.0/24 Host especifico var HOME_NET 192.168.1.3/32 Varios Host var HOME_NET 192.168.1.2/32, 192.168.1.3/32, 192.168.1.4/32 Cualquier Host var HOME_NET any En nuestro caso utilizaremos para cualquier host. 3.3.2 Configuración de reglas. En la configuración de reglas cabe mencionar que en la página web de Snort se pueden descargar las reglas para que estas sean incluidas en el directorio de C:\Snort\rules. Se busca en el mismo archivo de Snort.conf lo siguiente: var RULE_PATH../rules y lo sustituimos por var RULE_PATH C:\Snort\rules Capítulo III. Implementación de un IDS - 46 - 3.3.3 Configuración de acceso. En este apartado se configuraran algunas líneas que son importantes para que el funcionamiento sea el adecuado, en el archivo snort.conf se deberá buscar entre las instrucciones la línea que contenga lo siguiente: dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/ Una vez localizada, se debera modificar de la siguiente manera: dynamicpreprocessor directory c:\snort\lib\snort_dynamicpreprocessor Y en la instrucción original cuyo argumento se muestra a continuación: dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so Se deberá modificar con la siguiente instrucción: dynamicengine c:\snort\lib\snort_dynamicengine\sf_engine.dll Una vez realizado lo anterior, se abre una sesión en el prompt de windows o línea de comandos en la ruta C:\Snort\bin y se edita la siguiente instrucción: C:\Snort\bin\Snort –V En seguida mostrara información acerca de la versión de Snort como se muestra en la figura 3.17 Figura 3.17 Snort en línea de comandos mostrando la versión. Capítulo III. Implementación de un IDS - 47 - El comando snort –W mostrara las interfaces de red que dispone el equipo, eso quiere decir que las tarjetas de red están configuradas para realizar el monitoreo de paquetes aun sean tarjetas virtuales o emuladas por alguna aplicación. Figura 3.18 Listado de interfaz de red con Snort. En este caso se utilizara la interfaz 4, cuya sintaxis para realizar un análisis de paquetes ICMP es la siguiente: Una vez ejecutado esta sintaxis mostrara una serie de comandos y procesos que ejecuta el programa de snort como se aprecia en la figura 3.19. Figura 3.19 Ejecucion de comando console. Capítulo III. Implementación de un IDS - 48 - El último mensaje no muestra nada al final del proceso en ejecución ya que cuando se está conectado a la red, no se realiza ninguna petición hacia algún sitio en específico, es por eso que está en espera de recibir algún paquete y muestra el mensaje de ‘Not Using PCAP_FRAMES’; se abre una línea de comandos más y se realiza un ping de prueba a la página de Google. Lo que en la misma ventana captura el contenido de la figura 3.19 a comparación de la figura 3.20 donde no había actividad en la red, se muestran los resultados a continuación. Figura 3.20 Comportamiento de Snort al realizar un ping. El comportamiento registrado muestra los eventos en orden de fecha y hora, nombre de la alerta, dirección fuente y destino. Estas reglas se personalizan acorde a la seguridad que se requiera implementar en el sistema, en este caso solo se refiere a la funcionalidad que esta por defecto. Capítulo III. Implementación de un IDS - 49 - 3.4 Configuración de MySQL. Una vez instalado MySql en Xampp, se crea la base
Compartir