Diseño e implementación de una plataforma de detección de amenazas de red

Universidad de Valladolid Escuela de Ingeniería Informática Trabajo Fin de Grado Grado en Ingeniería Informática Mención Tecnologías de la Información Diseño e Implementación de una Plataforma de detección de amenazas de red Autor: D. Alberto Alonso Frutos Universidad de Valladolid Escuela de Ingeniería Informática Trabajo Fin de Grado Grado en Ingeniería Informática Mención Tecnologías de la Información Diseño e Implementación de una Plataforma de detección de amenazas de red Autor: D. Alberto Alonso Frutos Tutor: D. Javier Isaac Ramos López Resumen Este TFG presenta una guía completa de los aspectos teóricos y prácticos necesarios para realizar el diseño e implementación de una plataforma de detección de amenazas en la red del Departamento de Informática de la Universidad de Valladolid. Como introducción al proyecto se nos describen los problemas de seguridad a los que se expone una red y las distintas medidas existentes para lograr protegerla. Esta introducción nos presenta las medidas de seguridad que tendrán relevancia a lo largo del proyecto, estas medidas son los sistemas de detección de intrusos (IDS) y los sistemas de seguridad de la información y gestión de eventos(SIEM). Con el fin de realizar la elección de las herramientas empleadas en la plataforma de detección, se ha realizado un estudio individualizado de las herramientas IDS y SIEM en el mercado. Este estudio nos ha permitido decidir emplear la distribución Security Onion para la creación de la plataforma de detección. Mediante el diseño e implementación de una arquitectura distribuida Security Onion se ha logrado monitorizar el tráfico del Departamento de Informática y con ello permitir desarrollar un estudio con las posibles vulnerabilidades de la red. Como comprobaciones complementarias, se ha realizado la inyección sobre la plataforma de detección de archivos PCAP con tráfico malicioso que nos ha permitido corroborar la correcta detección de ataques. Índice 1Introducción ......................................................... 9 1.1 Contexto del TFG 10 1.1.1 Situación actual de la ciberseguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2 Motivaciones 11 1.3 Objetivos 11 1.4 Organización de la memoria 12 2Marco tecnológico ................................................ 13 2.1 Seguridad de la red 13 2.1.1 Métodosdeproteccióndelared ..........................................14 2.1.2 Tiposdeataques ........................................................19 2.1.3 Ataquesmásempleados .................................................19 2.1.4 Sistemas de detección de intrusos (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.5 Sistemasdeprevención(IPS) ..............................................25 2.2 Seguridad de la información y gestión de eventos (SIEM) 26 2.2.1 HerramientasSIEM .......................................................26 2.2.2 Splunk ..................................................................26 2.2.3 ArcSight ................................................................27 2.2.4 IBMQRadar .............................................................28 2.3 Herramientas de detección 29 2.3.1 SNORT ..................................................................29 2.3.2 Suricata ................................................................32 2.3.3 Zeek ...................................................................35 2.3.4 OSSEC..................................................................36 2.3.5 OSSECWazuh ...........................................................39 2.3.6 Tripwire .................................................................40 2.3.7 AIDE ...................................................................41 2.3.8 SAMHAIN ...............................................................41 2.3.9 Comparativa general herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3Sistema de monitorización ........................................ 47 3.1 Security Onion 47 3.1.1 Herramientasintegradas ..................................................49 3.1.2 Arquitecturas ............................................................53 3.1.3 Ventajas y desventajas de Security Onion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4Análisis y Diseño ................................................... 59 4.1 Tecnologías elegidas 59 4.2 Sistema de virtualización 61 4.3 Diseño de Security Onion 62 5Despliegue ......................................................... 67 5.1 Configuraciones iniciales 67 5.2 Instalación nodo manager 68 5.3 Instalación nodo search 73 5.4 Instalación nodo sensor 74 5.5 Instalación máquina analista 76 6Analisis de Resultados ............................................. 77 6.1 Intervalo de tiempo escogido 77 6.2 Descripción de los datos 78 6.3 Datos obtenidos 79 6.4 Análisis de la red 82 6.5 Alertas de red generadas 85 6.6 Monitorización del sistema 93 7Pruebas ............................................................. 97 7.1 Conjunto de datos 97 7.2 Importación de los datos 98 7.3 Análisis de alertas obtenidas 99 8Conclusiones y Trabajo Futuro ................................... 105 8.1 Conclusiones 105 8.2 Trabajo futuro 106 Bibliografía ........................................................ 107 Libros 107 Web 107 9Anexos ............................................................. 113 9.1 Ejemplo log de red 113 9.2 Ejemplo log de host 117 9.3 Ejemplo alerta de red 119 9.4 Mensaje alerta por descarga de troyano 124 14 Capítulo 2. Marco tecnológico que debe aplicarse en la organización a proteger. Las principales capas que vamos a detallar son la seguridad física, seguridad técnica y seguridad administrativa [8]. • La seguridad física [9] se basa en evitar el acceso físico a nuestra red con el fin de evitar manipulaciones en dispositivos como routers u ordenadores personales • La seguridad técnica se centra en aplicar técnicas software y hardware para garantizar la protección de los datos tanto del interior de nuestra organización como del exterior. • La seguridad administrativa [9] se enfoca en aplicar una serie de políticas de seguridad con el fin de controlar como aspecto principal el comportamiento de los usuarios. Este tipo de seguridad engloba aspectos como la forma de autenticarse, los niveles de acceso existentes, el cumplimiento de los reglamentos presentes respecto a seguridad o la realización de auditorías periódicamente. Teniendo en cuenta los objetivos que queremos lograr en nuestro proyecto, vamos a enfocarnos en la aplicación de la seguridad técnica. 2.1.1 Métodos de protección de la red Como ya hemos mencionado la seguridad solo se logra mediante la agrupación de distintas técnicas, por este motivo vamos a definir una serie de medidas que se aplican de forma general en el apartado de seguridad técnica de las redes. Gracias a la implementación de las medidas descritas por la compañía Cisco [10], unido a la plataforma de detección que desarrollaremos en este documento, nos permitirá garantizar la seguridad de la red. •Utilización Firewall. Un firewall [11] es un dispositivo de seguridad que monitoriza el tráfico de red de entrada y salida basándose en un conjunto de reglas de seguridad anteriormente definidas. Básicamente funcionaría como una barrera entre la red interna de la organización e Internet. El funcionamiento se puede observar de forma más clara en la imagen 2.1. Imagen 2.1: Funcionamiento de un firewall 2.1 Seguridad de la red 15 •Seguridad correo electrónico. Mediante la aplicación de un software de control de los correos entrantes en nuestra organización, podemos evitar una gran cantidad de amenazas de seguridad como por ejemplo campañas de phising. En concreto, detallaremos la técnica del phising [12], la cual se basa en contactar con el personal de nuestra organización simulando ser una institución legitima, por ejemplo un banco o una red social, con el fin de que el usuario introduzca información personal como nombres, contraseñas o datos bancarios. •Instalación Antivirus. Un antivirus [13] es un software que está diseñado para la prevención, búsqueda, detección y eliminación de programas que tengan un comportamiento malicioso en nuestro sistema. Como ejemplos de estos programas maliciosos podríamos destacar los virus, gusanos y troyanos. Imagen 2.2: Antivirus más famosos actualmente [14] •Seguridad de aplicaciones. Cada una de las aplicaciones que se ejecutan dentro de nuestra organización pueden contener vulnerabilidades que permitan a los atacantes poner en peligro la seguridad de nuestra red. La implementación de medidas que nos permitan detectar y eliminar esas vulnerabilidades supone un gran beneficio para la seguridad de nuestra red. •Analíticas de comportamiento. Esta medida de seguridad se basa en la aplicación de herramientas que generan estadísticas del comportamiento normal de nuestra red [15]. Mediante estas estadísticas podemos detectar si el funcionamiento de la red es distinto al normal y con ello identificar un posible problema de seguridad. •Segmentación de red. La segmentación de red [16] consiste en dividir la totalidad de la red en partes más pequeñas denominadas subredes. Debido al menor tamaño de las subredes se facilita la aplicación de políticas de seguridad y permitir lograr un aumento del rendimiento y del control de la red. En la imagen 2.3 podemos observar una red segmentada en 3 distintas subredes. 16 Capítulo 2. Marco tecnológico Imagen 2.3: Segmentación de red •Seguridad en la nube. En la actualidad las organizaciones disponen de aplicaciones, servicios y datos almacenados en la nube. Este hecho conlleva que sea necesaria la aplicación de tecnologías y procesos para la protección de la nube. Una de las medidas que se emplea para asegurar la nube, es el cifrado de la información almacenada, como mejor ejemplo de una compañía que emplee la nube y aplique este cifrado podemos destacar Amazon Web Service(AWS) [17] •Software de prevención de perdida de datos. La implementación de un software de prevención de perdida de datos [18] nos garantiza que no se produzcan filtraciones de información confidencial mediante la monitorización de los datos clave almacenados en nuestra organización. •Control de acceso. Con el fin de evitar el acceso de posibles atacantes es necesario reconocer a cada usuario y dispositivo. Por este motivo, es importante implementar una tecnología de control de accesos [19] en nuestra red que emplee distintas políticas de seguridad. Podemos detallar un ejemplo concreto de red que implementa control de acceso mediante la imagen 2.4. En el diagrama mostrado, se dispone de un servidor de autenticación mediante el cual se aplican las políticas de seguridad deseadas. Impidiendo, en caso de no cumplir las políticas de acceso establecida, la conexión al servidor web tanto desde Internet como desde el equipo. 2.1 Seguridad de la red 17 Imagen 2.4: Control de Acceso •Sistemas de detección (IDS). Este tipo de software se centra en la monitorización de redes o sistemas con el fin de detectar actividades anómalas en nuestra organización. Como podemos observar en la imagen 2.5, el IDS se encontraría dentro de nuestra red y se encargaría, dependiendo del IDS empleado, de analizar el tráfico que pasa a través del router o de monitorizar los equipos dentro de nuestra organización. Imagen 2.5: Funcionamiento de un IDS En posteriores apartados desarrollaremos de forma más detallada este tipo de herramienta. •Seguridad de dispositivos móviles. El número de aplicaciones móviles que se utilizan en las organizaciones se ha incrementado en los últimos años. Con el fin de garantizar la seguridad es necesario controlar el acceso y configuración de los dispositivos móviles permitidos en nuestra red. 18 Capítulo 2. Marco tecnológico •Seguridad de la información y gestión de eventos. Existen un tipo de herramientas denominadas SIEM, (Security Information and event management) que implementadas en nuestra red nos permiten agrupar toda la información de la que disponemos respecto a la seguridad de nuestra organización. Esto nos permitirá observar de forma general nuestra organización y poder responder e identificar cualquier tipo de problema más rápidamente. •VPN. La aplicación de una VPN o también denominada red virtual privada permite a un dispositivo concreto conectarse a una red de forma encriptada, de esta forma se garantiza una conexión segura entre los dispositivos de nuestra organización e Internet. •Seguridad web. [20] Existen potenciales problemas de seguridad durante la navegación web tales como acceso a webs maliciosas o inyección SQL, entre otros muchos ejemplos. En concreto en el caso de una inyección SQL [21], se emplean los campos de entrada de datos de las webs con el fin de ejecutar consultas maliciosas en la base de datos. Mediante un software que monitorice la seguridad web, seremos capaces de controlar que cualquiera de los miembros de nuestra organización no acceda a webs con alguno de los peligros descritos. •Seguridad redes inalámbricas. Las redes inalámbricas, conocidas coloquialmente como WIFI, suponen un mayor peligro que las redes cableadas. Por este motivo debemos disponer de herramientas que controlen el acceso y uso de los usuarios de la red inalámbrica. Tras mencionar en este apartado las principales medidas empleadas para lograr una seguridad efectiva, vamos a proceder a explicar a qué problemas de seguridad se enfrentan las redes, es con esta problemática donde surge el concepto de ataque. 2.1 Seguridad de la red 19 2.1.2 Tipos de ataques Como paso previo a clasificar los ataques, vamos a definir el concepto de ataque puesto que será empleado a lo largo de todo el documento. Definimos ataque [22] como un asalto a la seguridad del sistema derivado de un acto inteligente y deliberado para eludir los servicios de seguridad y violar la política de seguridad de un sistema. Para posteriores apartados en los que detallaremos la detección de ataques, vamos a necesitar realizar una clasificación respecto al impacto que generan sobre el sistema. Siguiendo esta división, diferenciamos entre ataques pasivos y ataques activos [23]. •Ataques pasivos. [24] Su objetivo es intentar conocer o hacer uso de información del sistema, pero sin afectar a los recursos del mismo. Debido a que se basan en escuchar u observar de forma no autorizada no realizan ninguna modificación y su detección es más compleja. Por este último motivo, cobra mayor importancia la prevención antes que la detección. •Ataques activos. [23] El objetivo de este tipo de ataques es alterar los recursos del sistema o afectar a su funcionamiento, para lograrlo realizan modificaciones sobre el flujo de datos o crean flujos de datos falsos. En este caso la detección es más sencilla y la mejor estrategia para tratarlos es la detección y recuperación rápida. 2.1.3 Ataques más empleados Una vez hemos definido y clasificado los ataques, uno de los aspectos más importantes es definir cuales son los más empleados [25] en la actualidad. A continuación, vamos a realizar una descripción detallada de cada uno de los ataques que mas obtendremos en nuestra plataforma de detección. •Ataque de negación de servicio. Un ataque de negación de servicio es un intento de inhabilitar un servicio o red mediante la saturación de este con paquetes de red. En el ámbito de la seguridad, se diferencia entre ataque de negación de servicio distribuido (DDOS) y ataque de negación de servicio (DOS). La principal diferencia entre ellos es que, en el caso de un DDOS, el ataque a un sistema se realiza desde varios sistemas mientras que en un DOS se emplea un único sistema. Entre los posibles tipos de ataques de negación de servicio [26] podemos destacar: – Ataques basados en volumen. Se basan en la saturación del ancho de banda de red mediante el envío masivo de paquetes UDP y ICMP. – Ataques de protocolo. Se basa en la utilización de determinadas vulnerabilidades de los protocolos como Ping of Death attack oSmurf DDoS para consumir recursos del servidor. Un ataque Smurf DDos [27] se basa en saturar el servidor con paquetes del protocolo ICMP (Internet Control Message Protocol) que tienen en sus cabeceras valores de IP falsificados. – Ataques de la capa de aplicación. Incluye ataques que tienen como objetivo explotar las 20 Capítulo 2. Marco tecnológico vulnerabilidades de las aplicaciones de red contenidas en la capa de aplicación del modelo ISO-OSI. Podemos destacar ataques que tienen como objetivo vulnerabilidades presentes en sistemas operativos. •Ataques de escaneo. El objetivo del escaneo de red es conocer información sobre la red objetivo con el fin de facilitarnos un ataque futuro, gracias a este ataque podemos conocer datos sobre la topología, el tráfico de red aceptado o sistema operativo entre otros muchos datos. Este ataque se realiza mediante el envió de paquetes a un sistema y a la posterior comprobación del contenido obtenido de la respuesta. •Ataques de penetración. Se basa en la utilización de posibles errores en el software para obtener acceso como root y disponer así de control total sobre el sistema. Una vez mencionados los ataques más empleados en la actualidad, nos vamos a centrar en explicar las herramientas que emplearemos para ponerles solución. 2.1 Seguridad de la red 21 2.1.4 Sistemas de detección de intrusos (IDS) Los sistemas de detección de intrusos o IDS (Intrusion Detection System)[28] son un tipo de software de seguridad que monitoriza los ordenadores individuales y analiza el tráfico de red, logrando así ser capaz de detectar distintos tipos de ataques provenientes tanto del interior como del exterior de nuestra organización. Con el fin de realizar una explicación más sencilla, podemos establecer un símil de un IDS con la alarma antirrobo de un vehículo. De forma similar al robo de un vehículo y el consecuente sonido de la alarma, un IDS funcionaría de forma análoga a la alarma, alertándonos en caso de que se intente entrar a través del firewall o se realice algún acceso no autorizado u algún otro tipo de brecha en la seguridad. En la imagen 2.5 podemos ver un esquema del despliegue de un IDS en una red. Según la procedencia de los datos podemos clasificar los IDS en los dos siguientes tipos: • En caso de que los datos que analiza el IDS provengan de un dispositivo individual lo denominamos Host Intrusion Detection System , o según sus siglas HIDS . La información que evalúan los HIDS, proviene del análisis de los logs generados en el ordenador y de la información proporcionada por el sistema operativo del sistema en el que se encuentren instalados. A partir de este momento vamos a definir a cada ordenador individual de nuestra infraestructura como host. • Cuando la fuente de datos de nuestro IDS son los paquetes que circulan por nuestra red, denominamos el software como Network Intrusion Detection System o según sus siglas NIDS . De forma general, el funcionamiento de un NIDS se basaría en monitorizar una interfaz de red y con ello obtener alertas para el tráfico que fluye por ella. Además de una clasificación según la procedencia de los datos, los IDS también se diferencian según el método que utilicen para la detección de ataques, pudiendo distinguir entre los dos siguientes tipos: •Los IDS centrados en la utilización de firmas se basan en comparar los paquetes de red con patrones denominados firmas o reglas, en los casos en los que se determine que el paquete de red coincide con ese patrón, determinaremos que se trata de tráfico malicioso y se enviará una alerta. Para cada IDS se dispone de una base de datos de firmas que puede ser editable por el administrador, pudiendo así añadir firmas propias para determinados casos. Poniendo un ejemplo concreto, podríamos crear firmas específicas para detectar escaneos de puertos o la llegada de peticiones de determinada dirección IP. Generalmente las firmas pueden clasificarse [28] en tres tipos distintos que son los siguientes: – Sistemas expertos. Este sistema se centra en establecer un número de condiciones y en 22 Capítulo 2. Marco tecnológico caso de cumplirse todas ellas lanzar la firma correspondiente. Como ejemplo de esta firma podríamos detallar la aplicación de condiciones en los paquetes de red para detectar determinados caracteres ASCII. Estos caracteres representarían palabras clave dentro del paquete como son la contraseña o el usuario. – Detección de firmas. Este enfoque de firmas se basa en comparar los eventos que suceden en el sistema con las firmas almacenadas en la base de datos de firmas. – Análisis de transacción de estados. Para la implementación de un análisis de transacción de estados es necesario considerar un ataque como una secuencia de pasos. Cada uno de los pasos representará el estado en el cual se encuentra el ataque. Este sistema se centra en generar una alerta en los casos en los que un ataque ha llegado al estado considerado como amenaza para la seguridad. El principal problema existente en este tipo de enfoque basado en firmas se centra en que el IDS no es capaz de detectar nuevos ataques, esto se debe a que no disponemos de información sobre ellos al no encontrarse en la base de datos de firmas. Este hecho hace que sea de vital importancia realizar una actualización periódica de estas firmas. •Los IDS basados en anomalías funcionan mediante la comparación del estado actual del sistema con un modelo creado anteriormente, este modelo refleja el comportamiento normal de nuestra red en términos de ancho de banda utilizado, puertos abiertos y otros datos de nuestro entorno. En los casos en los que el tráfico de red obtenido conlleve una variación de nuestros sistemas, el sistema de detección generará una alerta. Con el fin de establecer que se considera comportamiento normal y crear con ello el modelo mencionado, podemos definir 3 enfoques [28]: – Sistemas basados en conocimiento. Este tipo de sistema se emplea al inicio del despliegue del IDS, por este motivo no dispone de información de su funcionamiento y emplea las reglas almacenadas en la base de datos de reglas. – Sistemas basados en métodos estadísticos Se emplea el comportamiento del usuario para realizar el cálculo de métricas y modelos estadísticos. – Sistemas basados en aprendizaje automático Este enfoque se centra en emplear algoritmos que vayan aprendiendo de los datos en cada iteración, este aprendizaje les permite reconocer patrones y generar modelos del comportamiento del sistema. Una de las principales ventajas de este enfoque basado en anomalías es que nos permite detectar ataques nuevos, ya que al centrarnos en nuestro sistema el método de ataque no influye en su detección. A continuación, vamos a proceder a realizar una comparación entre HIDS y NIDS con el fin de 2.1 Seguridad de la red 23 conocer que nos aporta cada uno de ellos a nuestra infraestructura y establecer los puntos débiles que vamos a tener en cuenta en nuestra implementación. Detección en hosts Como hemos definido anteriormente un HIDS en un sistema de detección que obtiene los datos de análisis de host individuales, este hecho nos proporciona una de sus principales ventajas que consiste en que se nos permite conocer el proceso especifico por el que se ha causado esa alerta en ese host. Con este proceso localizado podemos controlar el comportamiento de ese usuario y poder solucionarlo de forma más efectiva. Respecto a la implementación de este tipo de IDS en nuestra infraestructura podemos determinar que nos proporciona gran escalabilidad y una relación coste eficacia muy beneficiosa, esto se debe a que la carga se distribuye entre los hosts, siendo solo necesaria la instalación de un agente en cada uno de ellos. Definiríamos un agente, como un software que monitoriza el sistema buscando malware, rootkits y anomalías sospechosas. Teniendo en cuenta la gran cantidad de información que se genera en los logs del sistema, también tiene sentido que una de las ventajas de los HIDS sea la gran cantidad de información que nos puede proporcionar sobre el host. Obviamente esta tecnología no dispone solo de ventajas, también tiene algunos puntos débiles que deberemos cubrir y que vamos a detallar a continuación. Como hemos mencionado anteriormente, un HIDS nos proporciona gran cantidad de información, aunque esto en principio es una ventaja, con ello también nos surge un problema puesto que los archivos requieren una gran cantidad de uso de disco. Respecto a los datos obtenidos, dispondremos de aquellos que se generen por el sistema operativo del host y en caso de querer determinada información que no se genere puede que sea necesario una modificación del código del sistema operativo. Teniendo en cuenta la instalación en entornos de gran tamaño también podemos establecer como desventaja que el precio de gestión y despliegue de un software no enfocado a entornos grandes puede ser muy costoso. Detección en red En este apartado, de forma análoga al anterior, vamos a desarrollar las ventajas e inconvenientes que tendría la implementación de un NIDS, en nuestra infraestructura. En primer lugar, en términos del coste y rendimiento que nos ofrece, se puede indicar que un NIDS no reduce el rendimiento de otros programas ejecutándose sobre la red, es de fácil mantenimiento e instalación y es independiente al sistema operativo instalado, además un solo NIDS puede cubrir una gran cantidad del tráfico de red.Como resultado de todos los aspectos mencionados, se considera a los NIDS un software muy bueno económicamente hablando. Por supuesto los NIDS también suponen desventajas en nuestra infraestructura. Estas desventajas 30 Capítulo 2. Marco tecnológico agrupándolos jerárquicamente mediante la dirección IP de cada datagrama. •Modo NIDS. Esta modalidad se caracteriza principalmente por aplicar el conjunto de reglas al tráfico de red para la detección de alertas. Siendo más específicos, en el caso de Snort el fichero de configuración de las reglas se denomina snort.conf y los resultados obtenidos de su aplicación se almacenan en el directorio /var/log/snort. Para nuestro caso particular nos resulta más importante el modo de funcionamiento NIDS, ya que será el que aplicaremos en nuestro ejemplo práctico. Debido a este último motivo, vamos a explicar más detalladamente su funcionamiento incluyendo un ejemplo de alerta estándar que nos podría generar. Funcionamiento en modo NIDS El funcionamiento de Snort [40] se caracteriza por estar divido en 5 módulos que podemos observar en la imagen 2.3.1 y que explicaremos a continuación: Imagen 2.10: Arquitectura de Snort[40] •Captura de paquetes. Mediante la aplicación de la librería llamada DAQ (Data acQuisition), se realiza un registro de todos los datos transmitidos en la red. Una vez obtenidos, son enviados para su decodificación. •Decodificación. Este módulo se encarga de analizar las cabeceras de los paquetes, permitiendo detectar anomalías como por ejemplo problemas en los flags al utilizar el protocolo TCP. Los flags de las cabeceras son campos que se envían previo a los datos que nos indican distintas características de la comunicación entre los dispositivos de red. 2.3 Herramientas de detección 31 •Preprocesado. El preprocesado en una ampliación de la decodificación diseñado para realizar el análisis de los datos para la capa de red, transporte y aplicación del modelo ISO-OSI. El aplicado del preprocesado, puede lograr detectar problemas de nuestra red en el uso de protocolos como FTP, SMTP, SSL o SSH entre otros muchos ejemplos. •Motor de detección. En este punto del funcionamiento, se aplican las reglas mencionadas anteriormente para la detección de alertas. •Modulo salida. Una vez obtenidos los resultados estos pueden mostrarse de distintas formas, para ello el módulo de salida nos proporciona la posibilidad de ver los resultados como ficheros syslog, ASCII o PCAP. Salida estándar de Snort Con el fin de comprender de forma sencilla una salida estándar para un IDS, en este caso Snort, vamos a explicar un ejemplo concreto para el que detallaremos toda la información que es capaz de proporcionarnos, el ejemplo se puede observar a continuación. [**] [116:56 : 1 ] ( snort_decoder ) : T/TCP Detected [**] • El primer número (116) denominado GeneratorID nos indica el componente del IDS que ha generado esta alerta, la lista de GeneratorID del IDS se pueden ver en el directorio /etc/generators. • El segundo número (56) se trata del Snort ID y nos permite identificar la regla que se ha empleado para su detección, en este caso vemos que es la regla 56 que se trata de la regla T/TCP event. • El tercer número (1) es el revision ID, el cual se irá incrementando para cada una de las ejecuciones de la regla. • Por último, en los dos últimos campos se nos muestra en forma de texto una breve descripción de la alerta detectada. Ventajas y desventajas En la siguiente tabla 2.1 se nos van a indicar las principales ventajas y desventajas de desplegar Snort como NIDS en un entorno de red. 32 Capítulo 2. Marco tecnológico VENTAJAS DESVENTAJAS Multiplataforma Dificultad de aprendizaje Gratuito No dispone de GUI Manual y comunidad de soporte Configuración especial para falsos positivos Reglas actualizadas y customizables Saturación de información debido a una base de datos de reglas muy amplia Bajos requisitos necesarios No enfocado a entornos de gran tamaño Disponibilidad de interfaz web No diseñado para infraestructuras modernas No soporta IPV6, multithread o velocidades altas de red Tabla 2.1: Ventajas y desventajas Snort 2.3.2 Suricata Suricata se define [41] como un sofware multiplataforma gratuito y de código libre desarrollado por la Open Information Security Foundation que proporciona la funcionalidad de NIDS y NIPS. Gracias a su implementación nos permite monitorizar la red y comparar el tráfico dentro de ella con un conjunto de reglas para detectar y alertar en caso de actividad maliciosa. Una vez ha detectado algún tipo de comportamiento malicioso, también dispone de la posibilidad de aplicar la respuesta necesaria para cada alerta. Imagen 2.11: Logo de Suricata Aunque utiliza una colección de reglas similar a Snort, siendo incluso compatible con las mismas, la principal diferencia radica en que nos permite una mayor especificación de reglas para los protocolos de la capa de aplicación. Una de las principales diferencias respecto a otro NIDS, es que se encuentra preparado para multihilos y para aplicar automáticamente balanceo de carga entre estos hilos. Debido a este motivo, es una herramienta enfocada a ofrecernos la posibilidad de escalar a entornos de mayor tamaño. Respecto a las salidas que produce, podemos destacar que recoge estadísticas de rendimiento en el archivo stat.log y que se pueden obtener las salidas en formato YAML. Este último formato facilita el uso de herramientas como Logstash que explicaremos en siguientes apartados. 2.3 Herramientas de detección 33 Funcionamiento de Suricata El funcionamiento de Suricata [40] es similar al de Snort puesto que su desarrollo se ha realizado basándose en el que emplea Snort. En el caso de Suricata se divide en 4 módulos los cuales están representada en la imagen 2.12. A continuación, voy a proceder a detallar los aspectos de cada módulo que se diferencien respecto a los mencionados para Snort. Imagen 2.12: Arquitectura de Suricata [40] •Captura de paquetes. A lo largo de la ejecución de este módulo la información de la red se transforma en una representación interna que simula un paquete de red para Suricata. •Decodificación de paquetes. Este proceso de decodificación consiste en aplicar una a una un conjunto de funciones que añaden información a la representación interna del paquete obtenido previamente. Cabe destacar que este módulo puede ampliar su funcionalidad mediante la creación de nuevas funciones. •Detección. De forma simultánea y una vez ya hemos decodificado el paquete, podemos aplicar el conjunto de reglas definido para la detección de alertas. Este conjunto de reglas se aplica mediante módulos de detección, los cuales agrupan cada uno de ellos una serie de reglas. Entre algunos de esos módulos de detección podemos destacar ET POLICY oET INFO, los cuales se detallarán posteriormente mediante casos prácticos. A mayores se aporta la posibilidad de crear nuevos módulos de detección. •Salida. Como último paso, realizamos la salida de los datos obtenidos siguiendo el formato que indiquemos de los disponibles. 34 Capítulo 2. Marco tecnológico Ventajas y desventajas En la siguiente tabla 2.2, se nos van a indicar las principales ventajas y desventajas de desplegar Suricata como NIDS en nuestro despliegue. VENTAJAS DESVENTAJAS Multiplataforma Mayor uso de recursos (CPU, RAM) Gratuito Obtención de mayor número de falsos positivos Manual de usuario y para desarrollo Posibilidad de positivos grises Reglas actualizadas y customizables Mayor precisión que otros IDS Escalabilidad Tabla 2.2: Ventajas y desventajas Suricata Nota 2.3.1 Los IDS pueden obtener 4 resultados dependiendo de si la detección del ataque es correcta o incorrecta. • Verdadero positivo: Ataques reales predicho como ataque • Falso positivo: Se identifica como ataque positivo un resultado negativo. • Verdadero negativo: Se identifica como negativo un resultado que tiene que ser negativo. • Falso negativo: Se identifica como negativo un resultado que es positivo. También cabe indicar que un positivo gris es una alerta que puede ser percibida por el IDS tanto como un falso positivo como verdadero positivo dependiendo del contexto. 2.3 Herramientas de detección 35 2.3.3 Zeek La herramienta Zeek [42] es un analizador de tráfico de red de código abierto cuya incorporación a nuestro entorno nos proporciona una gran cantidad de ficheros logs con la activad de nuestra red. En estos logs se va almacenando información como por ejemplo las sesiones HTTP, certificados SSL o las peticiones DNS, entre otros muchos datos. Imagen 2.13: Logo de Zeek También podemos definir Zeek como un NIDS basado en anomalías, que a mayores de las funcionalidades estándar de un sistema de detección, nos proporciona un lenguaje de scripting que nos permite un mayor espectro de posibilidades de detectar actividad maliciosa. Arquitectura de Zeek La arquitectura de Zeek se basa en dos componentes principales como se detalla en la imagen 2.14, el motor de eventos y el intérprete de scripts. En primer lugar, actúa el motor de eventos, que se encarga de transformar el flujo de paquetes de red obtenido en una serie de eventos de alto nivel. Los eventos obtenidos solo describen la actividad de la red sin tener en cuenta si pueden provocar posibles problemas en nuestra red, de este aspecto se encargará el intérprete de scripts. Imagen 2.14: Arquitectura de Zeek [42] 36 Capítulo 2. Marco tecnológico El intérprete de scripts recibirá una serie de eventos que se corresponden con la actividad de la red. En este momento, se encargará de ejecutar el conjunto de manejadores de eventos (event handlers) definidos, los cuales se encargan de la detección y respuesta de los ataques a nuestra red. En caso de implementar Zeek en nuestra plataforma, se obtendrán las alertas mediante los scripts incluidos en su configuración inicial. Ventajas y desventajas de Zeek En la siguiente tabla 2.3 se nos van a indicar las principales ventajas y desventajas de desplegar Zeek como NIDS en nuestro despliegue. VENTAJAS DESVENTAJAS Multiplataforma Necesidad de formación en su propio lenguaje Open-source gratuito No dispone de funcionalidad multithread. Lenguaje de scripting propio Alto rendimiento en redes con altas velocidades(10-100GB) debido al uso de balance de carga Disponibilidad de manual Tabla 2.3: Ventajas y desventajas de Zeek 2.3.4 OSSEC OSSEC [43] es un HIDS de código abierto y multiplataforma, al tratarse de un HIDS implica que va a obtener los datos que se generan en los dispositivos conectados a la red como ordenadores personales o dispositivos móviles. Imagen 2.15: Logo de OSSEC Entre sus principales funcionalidades encontramos la realización de análisis de los logs generados dentro del sistema, chequeo de la integridad de los ficheros, permitiéndonos así comprobar que los datos son correctos, monitorización de los registros de Windows, detección de rootkits, alertas en tiempo real y respuesta activa a cada alerta generada. Un rootkit es un conjunto de herramientas software utilizadas para permitir el acceso privilegiado sobre un dispositivo a un usuario que no 2.3 Herramientas de detección 37 debería disponer de ese acceso. A continuación, vamos a explicar más detalladamente la arquitectura y funcionamiento de OSSEC. Funcionamiento de OSSEC La arquitectura de OSSEC está compuesta por un conjunto de piezas como podemos observar en la imagen 2.16. Como pieza más importante disponemos de un manager oserver central que se encarga de recibir y monitorizar la información de los agentes, syslogs y bases de datos. Un agente Ossec es un pequeño programa o colección de programas instalado en el host a monitorizar que recolecta la información en tiempo real y la envía al manager para su análisis. Además de los agentes podemos recolectar información procedente de máquinas virtuales, switches,routers entre otros muchos dispositivos de nuestra red. Resumiendo, el funcionamiento de OSSEC se basa en el uso de servidores y agentes, siendo el servidor el que gestiona y analiza la información que recibe de los agentes. Imagen 2.16: Arquitectura OSSEC [43] Ventajas y desventajas En la siguiente tabla 2.4, se nos van a indicar las principales ventajas y desventajas de desplegar OSSEC como HIDS en nuestro despliegue. 38 Capítulo 2. Marco tecnológico VENTAJAS DESVENTAJAS Multiplataforma Dificulta de actualización Gratuito Envió de claves entre agente y servidor problemático Analiza información de múltiples dispositivos y en formatos distintos Sistema de respuesta en tiempo real y alertas configurables Gestión centralizada de políticas de seguridad en sistemas operativos distintos Manual de uso Tabla 2.4: Ventajas y desventajas de OSSEC 2.3 Herramientas de detección 39 2.3.5 OSSEC Wazuh Wazuh [44] es una plataforma gratuita y de código abierto utilizada para la detección de amenazas, monitorización de seguridad y sistema de respuesta frente a incidencias. Imagen 2.17: Logo de Wazuh Centrándonos en su utilización como sistema de detección, definiríamos Wazuh como un HIDS que utiliza un enfoque basado en firmas y un motor de expresiones regulares para el análisis de logs. La aplicación de esta tecnología en los agentes nos proporciona la posibilidad de detectar malware, rootkits y posibles anomalías. Su arquitectura y funcionamiento general es similar a OSSEC puesto que en su desarrollo comenzó siendo una bifurcación de este, aunque ahora mismo ha logrado proporcionar más funcionalidad, escalabilidad y facilidad de uso. A continuación, voy a explicar las principales funcionalidades añadidas a Wazuh respecto a OSSEC: •Integración con ELK Stack. Wazuh dispone de su propio plugin de Kibana que permite la comunicación entre Kibana y el manager con el fin de mostrar estadísticas de los agentes de forma más clara y concisa. Como resultado de esta integración se proporcionan las funcionalidades siguientes. –Visualización de los datos obtenidos en Kibana –Motor de búsqueda para encontrar información concreta –Almacenamiento de datos a largo plazo •Conjunto de reglas de Wazuh. El conjunto de reglas existentes en Wazuh es una versión mejorada y más actualizada de las proporcionadas en OSSEC, este aspecto nos proporciona mayor precisión y reglas añadidas para Amazon Web Services ,docker ofirewall. •Documentación. Disponibilidad de mayor cantidad de manuales y tutoriales para su implementación. 46 Capítulo 2. Marco tecnológico IDS Manuales y soporte SNORT Gran disponibilidad de documentación y comunidad de desarrollo SURICATA Gran disponibilidad de documentación y comunidad de desarrollo ZEEK Dispone de documentación propia y soporte a organizaciones WAZUH Dispone de documentación propia y soporte de pago por parte de los desarrolladores TRIPWIRE Dispone de manual de utilización en el sistema operativo Linux AIDE No dispone de documentación de calidad SAMHAIN Dispone de documentación oficial Tabla 2.14: Documentación por IDS 3. Sistema de monitorización 3.1 Security Onion En el ámbito empresarial se dispone de una gran cantidad de herramientas destinadas a la detección de posibles problemas de seguridad. Las más empleadas en la actualidad las hemos mencionado en el apartado 2.3, en el cual hemos destacado algunas como Zeek, Suricata, Snort o Wazuh. Cada una de las opciones mencionadas funciona individualmente de forma muy satisfactoria, pero no nos permiten observar una situación general de la seguridad. Es en este punto en el que surge la opción de la utilización de Security Onion, ya que nos permite combinar las funcionalidades tanto de los IDS como de los SIEM. Siendo mas específicos, la herramienta nos permitirá emplear todas las herramientas de detección deseadas además de presentarnos los datos obtenidos de forma clara y sencilla. De esta forma nos facilita el análisis sobre los datos obtenidos y con ello nos permite aumentar las posibilidades de encontrar posibles vulnerabilidades en nuestra red. Se han considerado otras opciones que nos ofrezcan funcionalidades similares a Security Onion pero han sido descartadas debido a que no integraban las herramientas de detección que queríamos emplear o debido a su alto precio de compra. Poniendo un ejemplo concreto, podemos destacar SolarWinds Security Event Manager, que aunque es una herramienta muy potente, ha sido rechazada debido a su precio de licencia (2.127C). Security Onion [48] es una distribución Linux gratuita y open-source enfocada a la caza de amenazas, monitorización de seguridad y gestión de logs. Incluye una gran variedad de herramientas de seguridad como TheHive, CyberChef, Elasticsearch, Logstash, Kibana, Suricata, Snort, Zeek, Wazuh. Su 48 Capítulo 3. Sistema de monitorización implementación nos proporciona la posibilidad de construir un sistema que sea capaz de proveernos de visibilidad y contexto de todo el tráfico que fluye por nuestra red. Imagen 3.1: Logo de Security Onion Una vez conocemos Security Onion, voy a detallar las aportaciones que obtenemos debido a su implementación mediante el despliegue realizado en la red de ejemplo presentada en la imagen 3.2 Imagen 3.2: Diagrama explicativo Security Onion [48] En nuestra red ejemplo podemos observar que disponemos de firewall, servidores y workstations y dos tipos distintos de tráfico. El primero de ellos denominado North-South TAP se trata de tráfico de red proveniente o con dirección a un elemento que reside fuera de nuestro entorno, por otra parte, el segundo denominado East-West TAP es tráfico de red que procede y tiene como dirección los elementos de nuestra red. 3.1 Security Onion 49 Mediante la recopilación de logs de estos dos tipos de tráfico, Security Onion es capaz de detectar problemas a lo largo de nuestra red y en estaciones individuales al mismo tiempo. 3.1.1 Herramientas integradas Para diferenciar de forma sencilla las distintas herramientas que componen Security Onion, vamos a clasificarlas basándonos en las 4 funciones generales que realiza esta distribución, las cuales vamos a mencionar a continuación: •Obtención de información sobre el tráfico de red. Para proveernos de visibilidad del tráfico de red, Security Onion dispone de Suricata y Zeek ya mencionadas en la sección 2.3. •Obtención de información en los hosts. Respecto a la monitorización de host, se dispone de varias posibilidades, la más empleada es el HIDS Wazuh explicado anteriormente en la sección 2.3. Su uso extendido como HIDS se debe que es la solución actual en el mercado que engloba más funcionalidades. A mayores disponemos de otras opciones para la obtención de datos de host que son Osquery, Beats o simplemente obtener los datos via Syslog. •Recogida y almacenamiento de logs generados. Todos los logs generados debido al funcionamiento de las herramientas NIDS y HIDS son gestionados por el paquete ELK Stack, el cual explicaremos a continuación. Podemos destacar también el uso de Redis para la gestión de las colas de logs que va a crear el paquete ELK Stack. •Visualización de los datos obtenidos. Una vez disponemos de todos los logs Security Onion, dispone de múltiples herramientas para facilitarnos su comprensión entre ellas nos encontramos Security Onion Console (SOC), TheHive, Kibana, CyberChef y Playbook. Una vez clasificadas las distintas herramientas vamos a describir cada una de las mencionadas que no hayan sido explicadas anteriormente. ELK Stack El proyecto ELK Stack [49] es una colección de los 4 productos de código abierto ElasticSearch, Logstash, Kibana y Beats. Imagen 3.3: Logo de ELK Stack 50 Capítulo 3. Sistema de monitorización La aplicación de estos 4 productos nos permite realizar una gestión centralizada de los logs logrando así transformar sistemas heterogéneos y distribuidos en sistemas más sencillos. La simplificación del sistema nos permite una mayor facilidad de monitorización y con ello una mejor gestión de la seguridad. La mejor forma de definir ELK Stack es mencionando las siguientes 4 capacidades claves que nos aporta: •Agregación. Capacidad para recolectar logs de fuentes de datos distintas. •Procesamiento. Capacidad de transformar los mensajes presentes en los logs en datos de mayor relevancia para su análisis. •Almacenamiento. Capacidad de almacenar los datos durante un periodo de tiempo extendido. •Análisis. Capacidad de visualizar y realizar consultas sobre los datos. Cada una de estas funcionalidades se realiza mediante la aplicación de Beats, Logstash, ElasticSearch y Kibana de la forma que vemos en la imagen 3.4. Imagen 3.4: Funcionamiento ELK Stack Siguiendo la línea temporal de la imagen 3.4, podemos determinar que en primer lugar Beats se encarga de la recolección de datos en host, Logstash de la agregación y procesamiento de los logs obtenidos, ElasticSearch se encarga de indexar y almacenar estos datos y por último Kibana nos proporciona una interfaz de usuario para visualizar y realizar consultas sobre los resultados obtenidos. En el caso concreto de Beats, vamos a detallar que dispone de un software incluido denominado FileBeat que se encarga de obtener los logs del sistema de ficheros del host en el que se encuentra. A mayores de los mencionados, la distribución Security Onion emplea el software Curator. Curator se centra en gestionar los índices que emplea ElasticSearch para el almacenamiento de los datos, de forma que se logre la solución más eficiente posible. 3.1 Security Onion 51 Osquery Osquery [50] es un framework para Windows, OS X (macOS), Linux, y FreeBSD encargado de la recolección de datos del sistema operativo. Imagen 3.5: Logo de Osquery Su funcionamiento se basa en considerar el sistema operativo como una base de datos relacional de alto rendimiento. De esta forma es capaz de realizar consultas para obtener datos del sistema operativo, por ejemplo podríamos obtener los procesos existentes en el sistema o los dispositivos USB conectados a él. Redis Redis [51] es una base de datos en memoria que nos permite acceder de forma rápida a datos necesarios para el funcionamiento de Security Onion en algunas arquitecturas. Imagen 3.6: Logo de Redis Su principal función en esta distribución es almacenar en memoria las colas de los logs que va a utilizar el paquete ELK Stack. Estas colas se emplean para poder planificar el tratamiento de los logs, pudiendo ir obteniendo la cantidad de logs deseada en cada momento. Con el fin de conocer el aumento de eficiencia que se logra al implementar Redis en vez de una base de datos relacional, se ha estudiado un benchmark [52] que establece una comparación entre el rendimiento de MySQL y de Redis. El benchmark estudiado, el cual podemos observar en la tabla 3.1, consiste en comparar el tiempo total en el que se realiza un número de peticiones a dos bases de datos con MySQL en la que la segunda implementa a mayores Redis. 52 Capítulo 3. Sistema de monitorización N.º de peticiones Tiempo total MySQL(s) Tiempo total Redis(s) 1000 0.0856 0.2618 10000 0.7908 1.9814 100000 7.4592 15.8395 1000000 67.7995 59.4885 10000000 679.9420 512.9122 Tabla 3.1: Benchmark Redis vs Mysql Tras el estudio de los datos, podemos observar que la implementación de Redis disminuye de forma notable el tiempo necesario para un número de peticiones elevado. Si estudiamos Redis como herramienta independiente podemos determinar que es capaz de realizar 110.000 peticiones SETs por segundo, y 81.000 peticiones GETs por segundo. Security Onion Console(SOC) La herramienta de Security Onion dispone de una consola a la que podremos acceder mediante el buscador web. Esta consola, mostrada en la imagen 3.7, nos ofrecerá la posibilidad de acceder a las distintas herramientas presentes en Security Onion. Imagen 3.7: Security Onion Console De esta consola vamos a detallar las opciones Alert, Hunt, PCAP y Grid. •Alert. Alert nos presenta una interfaz para ver todas las alertas generadas por los NIDS y HIDS de nuestro despliegue Security Onion. Además, nos permite realizar un filtrado de estas alertas por varios parámetros. •Hunt. En el caso de Hunt, esta opción nos presenta una interfaz para ver todos los logs obtenidos por los IDS en nuestro despliegue Security Onion. •PCAP. La opción PCAP nos permite observar más en detalle los paquetes que recorren nuestra red. 3.1 Security Onion 53 •Grid. En el apartado Grid se nos muestra una interfaz con todos los nodos conectados en el despliegue Security Onion y una serie de datos para cada uno de ello. TheHive TheHive es una plataforma de respuesta a incidentes de seguridad. Su funcionamiento se basa en permitir la creación de expedientes sobre las alertas que podemos ver en las opciones de Alert y Hunt. Imagen 3.8: Logo de TheHive Podríamos definir un expediente como un documento que permite ser compartido y editado por los distintos técnicos de seguridad, en el cual se mostrara toda la información existente para la alerta que queremos estudiar. Este software permitirá a todos los expertos trabajar de forma simultánea, con el fin de solucionar de forma conjunta el problema que causa la alerta. CyberChef CyberChef [53] es una aplicación web centrada en ofrecer la posibilidad de realizar operaciones avanzadas sobre los datos. Entre las operaciones que incluye podemos destacar la posibilidad de aplicar algoritmos de encriptación y realizar el cálculo de valores hash ychecksums. En la distribución Security Onion, esta aplicación se enfoca principalmente en permitirnos realizar operaciones sobre los datos de los paquetes obtenidos en la opción PCAP. PlayBook Como última herramienta vamos a explicar PlayBook, que se trata de una aplicación web que nos permite crear un libro en el que podremos almacenar cada ataque detectado como una entrada. Playbook nos permitirá definir una guía con las medidas empleadas para su detección y solución, de esta forma podremos consultar los pasos a realizar en caso de ataques futuros. 3.1.2 Arquitecturas En la siguiente sección vamos a desarrollar los distintos despliegues existentes de Security Onion. La implementación de uno u otro dependerá de las funcionalidades que busquemos o de los recursos disponibles. Vamos a distinguir entre 4 arquitecturas denominadas import,evaluation,standalone y Standalone. 54 Capítulo 3. Sistema de monitorización Import La arquitectura import se caracteriza por ser la más sencilla ya que solo necesita un único nodo que ejecute un capturador de paquetes. Una vez el capturador de paquetes está funcionando, los IDS Suricata y Zeek se encargan del análisis de los paquetes y la posterior generación de logs. Como último paso, los logs son recogidos por Filebeat y mandados a ElasticSearch para su análisis e indexación, proporcionándonos así la posibilidad de ver los resultados mediante la consola de Security Onion o algún otro visualizador de datos. Evaluation Esta arquitectura indicada en la imagen 3.9 requiere la necesidad de disponer de una interfaz de red dedicada a obtener el tráfico que han ido obteniendo un TAP o span port. Un TAP es un dispositivo físico o software que puede ver y almacenar todo el tráfico de la red en tiempo real y un span port es un puerto de un switch dedicado a realizar y enviar copias de todo el tráfico de red que ha pasado por ese switch. Imagen 3.9: Arquitectura evaluation [48] En esta arquitectura, los logs son obtenidos mediante la utilización de las herramientas NIDS y HIDS. Estos logs resultantes, son tratados por Filebeat y enviados a ElasticSearch de forma similar a como se realiza en un nodo import. Esta arquitectura, incluye a mayores Curator para el tratamiento de los índices que emplea ElasticSearch en el almacenamiento de los logs. 3.1 Security Onion 55 Standalone La arquitectura standalone, la cual se puede observar en la imagen 3.10, funciona de forma similar a una arquitectura evaluation respecto a la obtención de paquetes y de logs. Una vez disponemos de los logs, estos son tratados de forma distinta ya que se mandan en primer lugar a Logstash para su posterior tratamiento por Elasticsearch. Logstash aparece en la arquitectura en dos ocasiones, esto se debe a que en primer lugar se emplea para mandar datos a Redis para la creación de las colas de logs. Estas colas van a ser empleadas por Logstash en su segunda aparición, en la cual su función va a ser ir obteniendo logs de la cola y enviárselos a ElasticSearch. Imagen 3.10: Arquitectura standalone [48] Distribuida El despliegue de una arquitectura distribuida se basa en la partición de las funcionalidades en distintos nodos. Esta división, aunque aumenta el coste, garantiza una mayor escalabilidad y rendimiento. En una arquitectura distribuida simple como la indicada en la imagen 3.11, se definen 3 tipos de nodos: •Nodos forward o Nodos sensores. Ejecutan los distintos IDS configurados en nuestro entorno para la obtención de los logs. Posteriormente se encarga de su envio al manager Node mediante la utilización de Filebeat. 62 Capítulo 4. Análisis y Diseño que decidamos la arquitectura de Security Onion elegida, mencionaremos los recursos necesarios para cada nodo. 4.3 Diseño de Security Onion Una vez hemos descrito en la sección 3.1.2 las distintas arquitecturas en las cuales se puede desplegar Security Onion, es de vital importancia escoger aquella que mejor encaja con nuestro entorno. Debido a que queremos demostrar la posibilidad que tiene la solución propuesta de escalar unido a que disponemos de recursos suficientes tanto de memoria como CPU y disco, hemos escogido una arquitectura distribuida que es la que mejor satisface estas necesidades. Gracias a esta arquitectura se nos posibilita la opción de añadir los nodos tanto de almacenamiento como sensores que sean necesarios en cada momento, unido a que nos proporciona un mayor rendimiento que cualquier otra arquitectura. Como ya hemos mencionado, este tipo de arquitectura dispone de 3 tipos de nodos que resumiendo según su funcionamiento son: •Nodo manager. Centrado en la gestión general del sistema. •Nodo search. Encargado del almacenamiento de los datos. •Nodo sensor. Se centra en la obtención de los logs. A mayores de los indicados dispondremos de un nodo que llamaremos máquina de analista. Esta máquina nos permitirá disponer de un buscador web para acceder a la consola de Security Onion(SOC) y a todas las herramientas de visualización de las que disponemos. Aunque la instalación de esta máquina de analista es independiente al rol del nodo, con lo que podría realizarse en un nodo manager,search osensor, se ha decidido la utilización de una máquina distinta para que exista la mayor independencia posible entre cada una de las funcionalidades. El diseño distribuido de Security Onion constara de 8 nodos más la máquina de analista como podemos observar en la imagen 4.2. 4.3 Diseño de Security Onion 63 Imagen 4.2: Diseño Security Onion La elección de este número de nodos se ha realizado para simular un sistema lo más real posible a una implementación en explotación. Además, teniendo en cuenta los recursos de los que disponíamos, se ha decidido por representar 5 sensores distintos que están situados en distintos nodos del sistema de virtualización. Es en este momento en el que conocemos todos los nodos de los que dispondremos, cuando vamos a especificar el hardware necesario para cada uno de ellos. Aunque los distintos nodos empleen recursos distintos, todos dispondrán de la ISO del sistema operativo CentOS, esto se debe a que es el indicado como preferible en la documentación de Security Onion. Nodo manager Los recursos necesarios para el nodo manager son los mostrados en la tabla 4.1. Podemos destacar que solo necesita una interfaz de red de monitorización, esta interfaz es la empleada para comunicarse 64 Capítulo 4. Análisis y Diseño entre todos los nodos que forman el sistema distribuido. Nombre Dirección IP Memoria CPU Interfaz de red managernode1.infor.uva.es 10.124.60.1 32 GB 8 Núcleos ETH0 Tabla 4.1: Nodo manager Como hemos especificado anteriormente, hemos creado distintos discos para cada máquina, en el caso del nodo manager seguirán el esquema mostrado en la tabla 4.2 Disco Espacio Directorio Disco 1 10GB / Disco 2 20GB /nsm Disco 3 2GB /tmp Disco 4 25GB /var/lib/docker Tabla 4.2: Discos nodo manager Los directorios especificados para el disco 2 y el disco 4 se deben en el caso del disco 2 a que todos los logs de las herramientas IDS se almacenan en el directorio /nsm y en el caso del disco 4 se debe a que cada una de las herramientas se ejecutan mediante el despliegue de Dockers, los cuales se almacenan en el directorio /var/lib/docker. Docker [54] es una tecnología de creación de contenedores que permite la creación y uso de contenedores Linux. Un contenedor se define como una pequeña parte aislada del sistema que dispone de lo esencial para ejecutar un programa. En nuestro despliegue estos contenedores van a ejecutar las herramientas que emplea Security Onion, por ejemplo los IDS (Suricata, Zeek, Wazuh), el paquete ELK o las herramientas de visualización (PlayBook, TheHive). Nodos search En nuestro diseño disponemos de 2 nodos search que dispondrán de los recursos mostrados en las tablas 4.3, 4.4. La estructura de discos necesaria es igual a la del nodo manager. Nombre Dirección IP Memoria CPU Interfaz de red searchnode1.infor.uva.es 10.124.60.2 16 GB 8 Núcleos ETH0 Tabla 4.3: Nodo search 1 Nombre Dirección IP Memoria CPU Interfaz de red searchnode2.infor.uva.es 10.124.60.3 16 GB 8 Núcleos ETH0 Tabla 4.4: Nodo search 2 4.3 Diseño de Security Onion 65 Nodos sensores Todos los nodos sensores van a necesitar los mismos recursos, esto se debe a que se encargarán de monitorizar tráficos de red similares. En diferencia con el nodo manager, los sensores dispondrán de una interfaz de sniffing. Esta interfaz dispone de la capacidad de capturar los paquetes tanto de entrada como de salida. A continuación, vamos a especificar los 5 nodos sensores mediante las tablas 4.5, 4.6, 4.7, 4.8 y 4.9. Nombre Dirección IP Memoria CPU Interfaz de red sensornode1.infor.uva.es 10.124.60.4 16 GB 8 Núcleos ETH0, ETH1 Tabla 4.5: Nodo sensor 1 Nombre Dirección IP Memoria CPU Interfaz de red sensornode2.infor.uva.es 10.124.60.5 16 GB 8 Núcleos ETH0, ETH1 Tabla 4.6: Nodo sensor 2 Nombre Dirección IP Memoria CPU Interfaz de red sensornode3.infor.uva.es 10.124.60.7 16 GB 8 Núcleos ETH0, ETH1 Tabla 4.7: Nodo sensor 3 Nombre Dirección IP Memoria CPU Interfaz de red sensornode4.infor.uva.es 10.124.60.8 16 GB 8 Núcleos ETH0, ETH1 Tabla 4.8: Nodo sensor 4 Nombre Dirección IP Memoria CPU Interfaz de red sensornode5.infor.uva.es 10.124.60.9 16 GB 8 Núcleos ETH0, ETH1 Tabla 4.9: Nodo sensor 5 Respecto a la necesidad de discos de los sensores, mostrados en la tabla 4.10, cabe destacar que son los encargados de almacenar la mayoría de los datos que se obtienen y por tanto hemos aumentado el disco del directorio /nsm. Disco Espacio Directorio Disco 1 10GB / Disco 2 30GB /nsm Disco 3 2GB /tmp Disco 4 25GB /var/lib/docker Tabla 4.10: Discos nodo sensor 66 Capítulo 4. Análisis y Diseño Máquina de analista La máquina de analista no requiere de una gran cantidad de recursos, ya que su funcionalidad es únicamente permitirnos utilizar las herramientas y visualizar los datos. Como la cantidad de recursos no era relevante se ha realizado una clonación con los mismos recursos de un nodo manager, los cuales podemos observar en la tabla 4.11. Nombre Dirección IP Memoria CPU Interfaz de red sensorforeignnode1.infor.uva.es 10.124.60.6 16 GB 8 Núcleos ETH0 Tabla 4.11: Máquina analista 5. Despliegue En esta sección vamos a describir los pasos necesarios para el despliegue del diseño descrito en la sección 4. Siendo más específicos, el conjunto de pasos se centrará en la instalación y puesta en funcionamiento de los nodos manager,search, sensor y la máquina de analista. 5.1 Configuraciones iniciales Como paso previo a la instalación de cada uno de los nodos, las maquinas empleadas deben disponer de una configuración común. En primer lugar, todos los nodos se deberán configurar sobre una máquina que ejecute el sistema operativo CentOS y en cada uno de ellos será necesario establecer las configuraciones de red que se requieren para su tipo de nodo. Para la instalación de CentOS dispondremos del archivo ISO en la documentación de Security Onion. Con el fin de simplificar el despliegue, hemos creado un modelo que sirva como base para la creación de las máquinas que forman el diseño. Este modelo dispondrá de 16 GB de memoria, 8 núcleos y 4 discos que serán de 2,10, 20 y 25 GB, siendo la estructura de discos similar a la mostrada anteriormente en la tabla 4.2. Una vez disponemos del modelo base, se ha empleado el sistema de virtualización para clonar esta máquina y de esta forma obtener todas las máquinas virtuales empleadas en nuestra plataforma de detección. Para cada una de las máquinas clonadas únicamente será necesario establecer el nombre que le corresponda según el diseño y su configuración de red. Este último aspecto relativo a la configuración de red constara de la asignación de su dirección IP, la comprobación de que puede conectarse por SSH 68 Capítulo 5. Despliegue con las otras máquinas y la creación de las interfaces ETH1 en caso de necesitarlas. La instalación del tipo de nodo (manager,search, sensor) que ejecutara cada una de las máquinas virtuales, se realizará mediante la utilización del ejecutable so-setup-network, situado en el directorio /SecurityOnion. Tras su ejecución nos mostrará una serie de ventanas que seguirán el mismo formato al mostrado en la imagen 5.1. Esta interfaz nos permitirá escoger la arquitectura de Security Onion deseada y el tipo de nodo a instalar junto con su configuración. Imagen 5.1: Ventana inicial instalación nodo Para los nodos descritos en nuestro diseño, escogeremos una arquitectura distribuida como podemos mostrar en la imagen 5.2. Imagen 5.2: Elección arquitectura nodo 5.2 Instalación nodo manager El nodo manager debe ser el primer nodo en crearse puesto que funcionará como punto de unión de los demás nodos a la arquitectura distribuida. A lo largo de los siguientes puntos, vamos a argumentar siguiendo el orden de aparición en la instalación, cada una de las configuraciones realizadas. 5.2 Instalación nodo manager 69 Elección tipo de Nodo Como se nos muestra en la imagen 5.3 seleccionaremos la creación de un nodo manager. Imagen 5.3: Elección nodo manager Elección nombre del nodo Los nodos de tipo manager seguirán la estructura managernode unido al número de nodo manager que vayamos a desplegar, en nuestro caso, al disponer de un único nodo, el hostname del nodo es el indicado en la imagen 5.4. Imagen 5.4: Elección hostname manager Selección interfaz monitorización Estableceremos la interfaz ETH0 como interfaz de monitorización como se puede observar en la imagen 5.5. Los nodos manager solo necesitan la configuración de una única interfaz para la comunicación con otros nodos. 70 Capítulo 5. Despliegue Imagen 5.5: Elección interfaz Manager Método actualización Respecto a la forma de actualizarse, observable en la imagen 5.6, indicaremos que las actualizaciones se realicen de forma automática y que todos los nodos se conecten al nodo manager para su realización. Imagen 5.6: Actualizaciones nodo Manager Rango de direcciones IP En este punto, deberemos fijar las subredes que contendrán los nodos que vamos a añadir a la red. En nuestro caso hemos fijado la dirección 192.186.60.0 con mascara de 16 bits que corresponderán con los nodos añadidos en el diseño. A mayores, hemos añadido el rango de direcciones IP privadas 10.0.0.0/8 y 172.16.0.0/12. Esta configuración se puede ver en la imagen 5.7 5.2 Instalación nodo manager 71 Imagen 5.7: Direcciones IP añadidas Manager Instalación avanzada Realizaremos la instalación avanzada, mostrada en la imagen 5.8, para definir las herramientas NIDS que vamos a emplear y las herramientas de Security Onion que incluiremos. Imagen 5.8: Instalación avanzada manager Elección herramientas NIDS Como hemos mencionado en el diseño, seleccionaremos Zeek para la recolección de logs de la actividad de red y Suricata para las alertas. Esta elección, junto con una breve descripción, se puede observar en la imagen 5.9. Imagen 5.9: Herramientas NIDS escogidas 78 Capítulo 6. Analisis de Resultados funcionamiento normal. La semana escogida es la semana del 5 al 12 de mayo, la cual dispone de 5 días lectivos y se sitúa en un periodo durante el cual hay bastante uso por parte de los usuarios. 6.2 Descripción de los datos Como ya sabemos, Zeek, Wazuh y Suricata obtienen información de la red y de los hosts y la almacenan en archivos de logs. Antes de realizar un análisis del contenido que nos ofrecen estos logs, vamos a explicar de forma concreta como es un log y que datos nos ofrece. Descripción de un log En nuestra plataforma, disponemos de logs obtenidos por HIDS y NIDS, en ambos casos podemos describir un log como un objeto de formato JSON que dispone de parámetros informativos. Independientemente de la herramienta por la que han sido generados, los logs disponen de campos comunes para su gestión dentro de Security Onion, entre ellos podemos destacar: • Índice. • Versión. • Marcas temporales. • Nodo por el cual se ha generado. • Nodo de almacenamiento. • Directorio en el que está situado. Una vez hemos indicado los campos comunes, vamos a explicar aquellos que son característicos en función del tipo de log: • En el caso de los logs generados por herramientas NIDS o logs de red , el JSON contendrá información sobre la petición que se envía entre los equipos. Entre sus datos más relevantes, los cuales se pueden observar en el log anexo 9.1, podemos destacar: – Datos del servidor. Se nos indicará la dirección IP y puerto de destino. – Cliente. Se nos indicará dirección IP y puerto de origen. – Información de los protocolos empleados. Entre algunos protocolos utilizados podemos mencionar UDP, TCP, DHCP o DNS. – Paquetes enviados. El JSON contendrá el número de paquetes enviados entre cliente y servidor junto con el tamaño en bytes de los paquetes. – Descripción estado conexión. Incluye información sobre el establecimiento de la conexión mediante los flags (Ej:ACK, SYN). • Para los logs generados por herramientas HIDS o logs de host , debido a su instalación particular en cada host, los parámetros de los que dispone están enfocados en datos pertenecientes 6.3 Datos obtenidos 79 al sistema que monitoriza. Entre sus datos más relevantes, que se pueden observar en el log anexo 9.2, podemos destacar: – Mensaje explicativo alerta. – Información del proceso por el cual es provocado. • Como caso específico de logs, podemos mencionar las alertas que variaran su información dependiendo de si se han generado por NIDS o por HIDS. En el caso de las alertas de red , dispondrán de las direcciones IP contenidas en el log de red que ha generado esa alerta, mientras que para las alertas de Host dispondremos de información concreta del sistema obtenida del log de host. Aunque ambos tipos de logs varían en función del log que han empleado para su detección, en los dos casos contienen información de la regla que genera esa alerta. Entre estos campos, que se pueden observar en el anexo 9.3, podemos destacar: – Nombre de la regla. – Categoría de la regla. – Severidad de la regla. La severidad nos indica la medida en la que una alerta representa un problema de mayor o menor gravedad. En Security Onion disponemos de 3 valores para la severidad, los cuales son severidad baja, media y alta. Para la visualización de todo este tipo de logs vamos a emplear Kibana, que nos permitirá mediante su interfaz gráfica filtrar por el intervalo de tiempo deseado. A mayores de un filtrado temporal, se nos ofrece la posibilidad de realizar filtrados más específicos dependiendo de distintos factores. Entre los más empleados podemos destacar: • Filtrado de los logs generados por nodos. • Filtrado según sean logs de red o de host. • Filtrado según la herramienta que ha generado el log. • Filtrado por protocolos de red. • Filtrado de alertas. 6.3 Datos obtenidos Una vez conocemos cómo y de qué tipo son los datos que obtenemos, vamos a proceder a describir los que se han obtenido durante el funcionamiento de nuestra plataforma. Durante el periodo establecido, la plataforma ha obtenido 8,523,612 logs como se puede observar en la imagen 6.1. 80 Capítulo 6. Analisis de Resultados Imagen 6.1: logs totales obtenidos El número de logs que se generan por día varía en función del uso que realizan los usuarios, pudiendo observar en la imagen 6.2 como existen 5 picos diferenciados que se corresponden con los días lectivos. Imagen 6.2: logs obtenidos por día También disponemos de información respecto a la cantidad de logs que ha generado cada nodo como se puede observar en la imagen 6.3. Este dato nos permitirá conocer los puntos de nuestra red por los que más tráfico fluye. Respecto al número de logs que genera cada herramienta podemos mostrar la imagen 6.4. En esta última imagen destacamos la gran cantidad de logs que obtiene Zeek ya que se encarga de monitorizar todo el tráfico que fluye por la red y Ossec que también tiene bastante impacto puesto que obtiene una gran cantidad de logs para cada sistema. En el caso de Suricata, debido a que se encuentra centrado en la obtención de alertas, el número de logs que obtiene es mucho menor. Imagen 6.3: logs por nodo Imagen 6.4: logs por herramienta 6.3 Datos obtenidos 81 En este momento en el que ya conocemos todos los logs que se han generado en la plataforma vamos a realizar un análisis independiente centrándonos en cada uno de los logs explicados. El reparto de los 8,523,612 logs según sean de red o host se puede observar en la imagen 6.5. Imagen 6.5: Distribución de los logs A mayores de la división basada en host y network, la imagen anterior clasifica los logs en función de la herramienta por la cual ha sido generado. Basándonos en este criterio, podemos destacar los siguientes aspectos: •logs de Zeek. Generados para la monitorización del tráfico de la red, suponen una gran parte de la totalidad de los logs obtenidos. Siendo más concretos, disponemos de 7,160,825 logs de Zeek, que representa el 84 % del número total obtenido. Este número tan elevado, se debe a que la plataforma ha analizado durante la semana alrededor de 7 TB de paquetes de red. •logs de Suricata. El número de alertas obtenidas por Suricata en nuestra plataforma es de 23,521. •logs de Ossec. Se dispone de 1,339,204 logs de host obtenidos por Ossec. •logs de Osquery. Este tipo de logs suponen un caso especial en nuestro despliegue, ya que que no hemos implementado el uso de osquery. Los 62 logs generados no representan información del departamento, sino que consisten en usuarios de ejemplo realizados por el nodo manager para comprobar el funcionamiento de osquery. Debido a que nuestra plataforma obtiene los logs de hosts de los propios nodos que forman el diseño de Security Onion, se ha considerado más relevante el análisis de la red. Esto se debe a que nos permite analizar el tráfico real del Departamento de Informática de la Universidad de Valladolid. 82 Capítulo 6. Analisis de Resultados 6.4 Análisis de la red La plataforma de detección se ha implementado mediante el sistema de virtualización que se encuentra dentro de la Universidad de Valladolid. Este aspecto supone que los datos que obtenemos se vean influenciados debido a las medidas de seguridad desplegadas en la Universidad. Actualmente, como medida de seguridad que nos influye destacan dos firewalls, el primero de ellos situado tras el sistema de virtualización que se aplica sobre las máquinas virtualizadas y el segundo situado en la entrada de la red de la UVA. Este último firewall se encarga de controlar todo el tráfico entrante a la universidad. Debido al funcionamiento de los firewalls, podemos indicar que el tráfico que obtenemos se encuentra limitado a aquel que se considera aceptable según las comprobaciones que realizan los técnicos de seguridad. Este aspecto será tenido en cuenta en posteriores apartados. Para la obtención de los logs que nos interesan en este apartado, vamos a realizar un filtrado para quedarnos únicamente con los logs de red. El número de logs resultante es de 7,184,346 como se puede observar la imagen 6.6. Imagen 6.6: logs de red obtenidos Vamos a realizar un análisis general del contenido de todos estos logs de red con el fin de conocer el tráfico que fluye por el Departamento de Informática de la Universidad de Valladolid. El primer paso que se ha realizado para observar de forma sencilla el tráfico que más influencia tiene en el departamento, es realizar una clasificación de todos los logs de red basándonos el conjunto de datos que representa en Kibana. Este conjunto de datos nos separará el tráfico en función de aspectos como el protocolo que emplea. El gráfico se puede observar en la imagen 6.7. 6.4 Análisis de la red 83 Imagen 6.7: Tráfico de la red Con el fin de comprender de forma más clara este tráfico,vamos a detallar cada una de las opciones mostradas en la leyenda: •DNS. Las peticiones DNS (Domain Name System) nos permiten emplear nombres para obtener las direcciones IP del servidor al que vamos a acceder. Un ejemplo concreto del uso de DNS sería el acceso a www.google.com, puesto que mediante una petición DNS obtendríamos la IP del servidor que aloja esa dirección web. •CONN. Las peticiones CONN se centran en el establecimiento de la conexión entre ambas partes de la comunicación. Estas peticiones determinaran entre otros aspectos si el host se ha conectado al servidor, si el servidor ha respondido y se encuentra activo y todos aquellos aspectos relacionados con el uso de flags, entre los que podemos destacar el flag ACK o SYN. •DHCP. El protocolo DHCP (Dynamic Host Configuration Protocol) permitirá la asignación de direcciones IP y otros parámetros a todos los dispositivos de nuestra red. •SYSLOG. Mediante el protocolo SYSLOG se permite realizar el envío de mensajes de registro o de eventos a un servidor específico. •WEIRD. Este tipo de tráfico es clasificado por Zeek como extraño puesto que no concuerda con ningún tipo de tráfico conocido. La clasificación como WEIRD de un log, se puede deber 84 Capítulo 6. Analisis de Resultados a errores o modificaciones de los paquetes de red. Debido a este último aspecto, este tráfico se obtiene debido a intentos de ataque que se basen en la modificación de los campos de los paquetes de red. •SSH. El protocolo SSH nos permite el acceso remoto entre dos sistemas mediante el uso de un canal seguro y cifrado. Aunque este es el tipo de tráfico más frecuente en nuestra red, podemos destacar otros tipos de tráfico que tienen un número mucho menor de logs. Entre los más relevantes podemos destacar: • Tráfico del protocolo SNMP • Tráfico del protocolo SSL • Tráfico HTTP • Descargas de archivos • Tráfico generado por Kerberos o x509 • Tráfico del protocolo SMTP Una vez hemos indicado el tráfico existente en nuestra red, es necesario conocer si los resultados obtenidos son aquellos deseados y esperables en una red que funcione correctamente. Para realizar una comparativa de nuestros datos con el tráfico esperado en una red vamos a emplear un estudio [55] realizado en la Universidad de República Checa. Este estudio, se centra en cuantificar mediante estadísticas los datos del tráfico de determinadas redes de la Universidad de Republica Checa. Se ha considerado como ejemplo representativo debido a que dispone de Eduroam, igual que la Universidad de Valladolid, unido a que en la investigación se monitorizan una serie de entornos similares al departamento escogido. Como primer aspecto a destacar de nuestro tráfico de red, podemos resaltar el gran uso que se realiza del protocolo UDP que supone el 77% del tráfico total. El mayor uso del protocolo UDP garantiza una mayor velocidad en nuestra red, aunque puede significar mayor pérdida de paquetes de red y, en principio, conexiones menos seguras. Este porcentaje de uso de UDP es elevado en comparación con los obtenidos en la Universidad de República Checa, el cual se sitúa alrededor del 65%. De todas formas, se sitúa dentro de valores aceptables dentro de una red. Respecto al uso de los distintos tipos de protocolos como DNS, DHCP, SSH o HTTP, el tráfico que generen variará en función del comportamiento de los usuarios que utilicen la red. Como aspecto común a todas las redes podemos concluir que el tráfico de DNS y de CONN supone un alto porcentaje del tráfico de red. Esta afirmación concuerda con nuestros datos obtenidos y los mostrados en el estudio analizado. Si ponemos un ejemplo concreto podemos detallar el valor del uso de DNS, ya que 6.5 Alertas de red generadas 85 para una situación similar en la universidad de República Checa el valor se encuentra sobre el 40%, un valor similar al obtenido en nuestro despliegue. Teniendo en cuenta los demás protocolos, se observa un número de peticiones HTTP y SNMP considerablemente más bajo que en cualquiera de las redes estudiadas. Una vez observados y explicados los datos, podemos detallar que la mayoría del tráfico de nuestra red se debe al uso de DNS, DHCP y CONN. Este tipo de tráfico es una fuente de un posible ataque a nuestra red. Mediante la generación de alertas vamos a ser capaces de controlarlo y determinar si existe algún tipo de peligro en nuestra red. En este momento, una vez ya conocemos que existe tráfico en nuestra red que puede suponer una fuente de ataques, vamos a centrarnos en cómo se detectan los posibles ataques asociados a ese tráfico. Para responder a esta necesidad de detección, surgen las alertas de red generadas por Suricata y Zeek. Mediante su estudio se nos proporcionará información relevante para la obtención de posibles vulnerabilidades de la red. 6.5 Alertas de red generadas En este apartado, vamos a mostrar un estudio de las alertas de red obtenidas para cada una de las herramientas NIDS en nuestro despliegue. En primer momento, realizaremos un análisis general que nos ofrecerá una vista de los potenciales problemas de seguridad en nuestro departamento. Una vez conozcamos la situación general, detallaremos algún ejemplo de alerta concreta que nos permita observar de forma clara los beneficios de los NIDS en nuestra seguridad de red. Alertas de Suricata Con el fin de obtener las alertas que nos interesan en este apartado, vamos a realizar un filtrado para quedarnos únicamente con las alertas de red de Suricata. Nota 6.5.1 Filtrado de alertas de Suricata event.dataset:alert AND event.module:suricata Durante la semana analizada, Suricata ha conseguido obtener 23,521 alertas en nuestra red como podemos observar en la imagen 6.8. 86 Capítulo 6. Analisis de Resultados Imagen 6.8: Alertas generadas Suricata En cuestión del número de alertas generadas diariamente, se puede observar en la imagen 6.9 que existen picos diferenciados que nos permiten detectar intervalos en los que nuestro sistema ha detectado una gran cantidad de alertas. Siendo más concretos, se obtienen pequeños incrementos correspondientes a los días laborables de la semana y un gran pico presente el día 11 de mayo, el cual será analizado posteriormente como un posible ataque grupal a nuestra red. Imagen 6.9: Alertas Suricata obtenidas por día Cada una de las alertas generadas, se corresponde con la ejecución de una regla en la herramienta Suricata. El estudio de las reglas que más se han ejecutado en nuestra red nos permitirá conocer los posibles ataques sufridos y centrarnos en los casos que nos van a resultar más relevantes. Como primer aspecto, es necesario realizar una clasificación como la mostrada en la tabla 6.1, donde podemos observar las 10 reglas más obtenidas en nuestra plataforma. Regla N.º de alertas ET POLICY Spotify P2P Client 7108 ET SCAN Potential SSH Scan 6396 ET DROP Dshield Block Listed Source group 1 712 ET 3CORESec Poor Reputation IP group 13 521 ET COMPROMISED Hostile Host Traffic group 49 503 ET COMPROMISED Hostile Host Traffic group 61 452 ET COMPROMISED Hostile Host Traffic group 84 393 ET COMPROMISED Hostile Host Traffic group 80 326 ET COMPROMISED Hostile Host Traffic group 65 297 GPL SNMP public access udp 265 Tabla 6.1: Alertas por regla Como se puede observar un gran porcentaje de las 23521 alertas se han generado debido a estas 10 6.5 Alertas de red generadas 87 reglas. Debido a este hecho, vamos a explicar más detalladamente en que consiste cada una de las 10 reglas mostradas: •ET POLICY Spotify P2P Client. Esta regla se lanza debido a la política de seguridad establecida en las reglas TALOS, la cual intenta avisar del tráfico P2P que genera Spotify. La severidad de esta alerta es baja y simplemente es informativa y nos permite conocer esta situación en caso de querer evitar este tipo de tráfico. •ET SCAN Potential SSH Scan. Como hemos mencionado en la sección 2.1.2, uno de los ataques más realizados consiste en intentar escanear nuestra red en busca de información para posibles ataques futuros. La regla ET SCAN Potential SSH Scan. se enfoca en detectar los ataques de escaneo mediante SSH sobre nuestra red. •ET DROP Dshield Block Listed Source group. Esta regla se ejecuta para peticiones de red con una dirección IP de origen catalogada como maliciosa. La lista de direcciones IP no confiables está realizada por grupos internacionales de seguridad como el Internet Storm Center. •ET 3CORESec Poor Reputation IP Group. Suricata dispone de un proceso para el cálculo de la reputación de una dirección IP. La regla se obtendrá en aquellos casos en la que la dirección IP no cumpla determinados criterios y se califique como de baja reputación. •ET COMPROMISED Known Compromised or Hostile Host Traffic Group. Esta regla indica que nuestro IDS ha detectado tráfico proveniente de una dirección IP que se encuentra dentro de la lista de amenazas emergentes. Esta lista engloba todos los orígenes o grupos, como los denomina Suricata, para los cuales se conoce que han realizado ataques. En nuestro despliegue nos hemos encontrado gran cantidad de apariciones de este tipo de regla, aunque han sido generadas por grupos distintos. •GPL SNMP public access udp. Esta regla se obtiene en los casos en los que Suricata ha detectado tráfico que podría estar utilizando una vulnerabilidad del protocolo SNMP para la realización de un ataque. Otro de los aspectos más relevantes de las alertas se basa en la severidad que se nos indica para cada una de ellas. Para las alertas Suricata generadas en nuestro despliegue, hemos obtenido la severidad indicada en la imagen 6.10. Respecto a la severidad obtenida, podemos destacar que no disponemos de ninguna alerta que este marcada como severidad alta, lo que nos indica que no será necesario realizar medidas inmediatas. Como único aspecto a tener en cuenta podemos mencionar el número de escaneos SSH que se realizan sobre nuestra red, llegando a obtener 6396 alertas de este tipo durante la semana estudiada. 94 Capítulo 6. Analisis de Resultados Nota 6.6.2 InfluxDB es la base de datos que emplea Grafana. Imagen 6.18: Porcentajes de CPU por tarea • La imagen 6.19 nos muestra información del funcionamiento de Redis. Para este nodo disponemos del número de logs presente en la cola de logs generada, así como de la memoria y CPU que emplea. Como aspecto a mayores, este panel muestra el tamaño de la base de datos de InfluxDB. Imagen 6.19: Métricas de Redis • En términos de uso de memoria, podemos observar en la imagen 6.20, el valor disponible y utilizado de memoria, así como la función para la que se está empleando. 6.6 Monitorización del sistema 95 Imagen 6.20: Uso de memoria • Respecto al uso de disco de nuestro nodo disponemos del panel de la imagen 6.21, en el cual se muestra los mebibytes (MiB) escritos y leídos del disco a lo largo de la semana. También se nos proporciona el número de eventos estimados por segundo que están ocurriendo en nuestro nodo. En la imagen de ejemplo observamos los picos de eventos ocurridos en los días laborables de la semana. Imagen 6.21: Entrada/salida de disco y eventos del sistema A mayores de los indicados, existen otros paneles informativos que hemos considerado de menor relevancia. Estos paneles nos presentan datos como el número de procesos o hilos del nodo o la carga 96 Capítulo 6. Analisis de Resultados media del nodo. Mediante el control de los valores de cada métrica seremos capaces de detectar si es necesario aumentar determinados recursos como la memoria o el disco, así como también lograremos identificar la causa en casos de problemas de rendimiento. 7. Pruebas En la sección anterior hemos mostrado las distintas alertas que se han generado por nuestro sistema durante una única semana de estudio y en un entorno en el que ya existen medidas de seguridad. Estos condicionantes conllevan que solo se está poniendo a prueba la plataforma de detección para un pequeño porcentaje de los potenciales ataques que podría sufrir el Departamento de Informática de la Universidad de Valladolid. Con el fin de resolver esta problemática, vamos a probar que el sistema genera alertas para distintos ataques simulados. La simulación de ataques se realizará mediante el uso de archivos PCAP que contienen paquetes de red. El contenido de estos paquetes simula la realización de ataques concretos sobre nuestra red. 7.1 Conjunto de datos Como hemos descrito, necesitaremos una serie de archivos PCAP que serán obtenidos de una biblioteca [56] centrada en este tipo de archivos con tráfico malicioso, los archivos elegidos son los siguientes: • PCAP de análisis de tráfico de red del 2021-02-08, que denominaremos PCAP_2021-0208 Nota 7.1.1 Obtención del PCAP: wget https://www.malware-traffic-analysis.net/2021/02/08/2021-02-08-traffic-analysis-exercise.pcap.zip • PCAP de análisis de tráfico de red del 2021-01-21, que denominaremos PCAP_2021-01- 98 Capítulo 7. Pruebas 21 Nota 7.1.2 Obtención del PCAP: wget https://www.malware-traffic-analysis.net/2021/01/21/2021-01-21-traffic-analysis-exercise.pcap.zip 7.2 Importación de los datos En la sección 3.1.2 hemos detallado los distintos tipos de arquitectura Security Onion. Según la documentación de Security Onion, para realizar la importación de PCAPS es preferible emplear una arquitectura import. Este tipo de despliegue nos permite generar automáticamente alertas sin la necesidad de realizar modificaciones en Suricata, algo que si sería necesario realizar en nuestro despliegue distribuido. A continuación, vamos a mostrar los pasos llevados a cabo para la instalación de la arquitectura import: •Clonación de la máquina modelo. •Elección y configuración de la arquitectura. Se ha empleado el ejecutable so-setup-network de forma similar a cualquier otro tipo de nodo desplegado anteriormente. Como únicas configuraciones que no hayan sido mostradas destaca la elección de la arquitectura y el hostname. Estas configuraciones se pueden observar en las imágenes 7.1 y 7.2. Imagen 7.1: Arquitectura import Imagen 7.2: Hostname import •Creación máquina analista. Se ha creado una máquina de analista dentro del nodo Import. 7.3 Análisis de alertas obtenidas 99 Aunque esta máquina se ha desplegado de forma similar a la explicada anteriormente, como aspecto diferenciador destaca que se encuentra dentro del propio nodo y que por este motivo no es necesario permitir la máquina de analista en el firewall. Para la generación de logs el tráfico contenido dentro del PCAP será enviado a la interfaz de la que dispone el nodo import, simulando de esta forma que se están realizando los ataques durante un funcionamiento normal de la red. Para realizar esta función, disponemos de dos opciones que son el comando so-import-pcap y tcpreplay. Se ha seleccionado so-import-pcap puesto que tiene en cuenta la fecha del tráfico enviado a la interfaz, lo que nos permitirá posteriormente un filtrado por fechas en Kibana. Para los dos conjuntos de datos los comandos empleados se pueden observar en la tabla 7.1. PCAP Comando PCAP_2021-02-08 so-import-pcap 2021-02-08-traffic-analysis-exercise.pcap PCAP_2021-01-21 so-import-pcap 2021-01-21-traffic-analysis-exercise.pcap Tabla 7.1: Comandos empleados por PCAP Una vez hemos realizado la importación de los datos, el PCAP introducido es analizado por Suricata y Zeek en busca de alertas, las cuales nos serán accesibles a través de Kibana y de las opciones Hunt, PCAP y Alert de Security Onion. A mayores de las alertas también dispondremos de logs de Zeek especificándonos información sobre el tráfico de red contenido en el PCAP. 7.3 Análisis de alertas obtenidas En esta sección vamos a explicar las alertas obtenidas en cada uno de los PCAP y de esta forma demostrar la variedad de ataques que podemos detectar. Para cada uno de ellos destacaremos aquellas alertas que se consideran relevantes debido a su frecuencia de aparición o severidad. Análisis del PCAP_2021-02-08 En el caso de este PCAP, la plataforma de detección ha generado 158 alertas de red como se puede observar en la imagen 7.3. Imagen 7.3: Alertas generadas PCAP_2021-02-08 100 Capítulo 7. Pruebas Respecto a la severidad de las alertas, la cual se muestra en la imagen 7.4, podemos destacar la presencia de varias alertas de severidad alta, las cuales si suponen un problema inmediato en nuestra red. Imagen 7.4: Severidad alertas PCAP_2021-02-08 Como análisis previo de los resultados, vemos que este PCAP se caracteriza por presentarnos alertas variadas que se corresponden a distintos tipos de ataque sobre nuestra red. Las alertas obtenidas se pueden observar en la tabla 7.2. Regla Nº de alertas ET JA3 Hash - [Abuse.ch] Possible Dridex 141 ET HUNTING SUSPICIOUS POST with Fake Browser 5 ET MALWARE Win32/Ficker Stealer Activity 4 ET PHISHING Lets Encrypt Free SSLPossible Phishing 2 ET POLICY DNS Update From External net 2 ET INFO Packed Executable Download 1 ET POLICY External IP Lookup (ipify .org) 1 ET POLICY External IP Lookup api.ipify.org 1 ET POLICY PE EXE or DLL Windows file download HTTP 1 Tabla 7.2: Reglas empleadas PCAP 2021-02-08 Vamos a proceder a explicar las reglas de mayor relevancia en este PCAP, de esta forma estableceremos que tipos de ataque estamos detectando: •ET JA3 Hash - [Abuse.ch] Possible Dridex. Esta regla nos indica que existe la posibilidad de que se haya ejecutado el malware Dridex en nuestra red. Dridex se especializa en obtener credenciales bancarias, para ello realiza envíos masivos de correos con archivos Word y Excel corruptos. Una vez el usuario abra estos archivos, el malware ya se encontrará funcionando en nuestro dispositivo. 7.3 Análisis de alertas obtenidas 101 •ET HUNTING SUSPICIOUS POST to Dotted Quad with Fake Browser. Este caso se obtiene debido a la recepción de peticiones POST realizadas por navegadores falsos. Estas peticiones pueden formar parte de un posible ataque de negación de servicio realizado por bots sobre nuestra red. •ET MALWARE Win32/Ficker Stealer Activity. La regla Ficker Stealer Activiy nos muestra que existe actividad en nuestra red del malware Ficker. Este malware, simula aplicaciones legitimas mediante páginas web falsas, entre alguna de estas aplicaciones podemos destacar Microsoft Store o Spotify. En el momento en el que ejecutamos los archivos que se nos ofrecen en esas páginas web falsas, los atacantes ya tienen la posibilidad de robar los datos de nuestro sistema. •ET PHISHING Lets Encrypt Free SSLPossible Phishing. La entidad Lets Encrypt se encarga de proporcionar certificados con los que garantizar la seguridad de las páginas web y evitar ataques de phising. Existen ciertos certificados de Lets Encrypt que han sido alterados y que hacen que consideremos fiables determinadas webs que en realidad se dedican al robo de información. Esta regla se ejecuta en los casos en los que se ha detectado uno de estos certificados modificados. Respecto a las otras reglas no mencionadas, cabe destacar que se enmarcan dentro de las categorías ET POLICY y ET INFO. La categoría ET POLICY no se obtiene debido a un ataque en particular, sino que simplemente remarca algo que puede violar la política de seguridad establecida por el administrador de la red. Como casos concretos de ET POLICY en este PCAP, nos encontramos los casos siguientes: • Actualización de servidor DNS desde una red Externa. • Descarga de un fichero ejecutable de Windows mediante http. • Intentos de obtención de IPs de nuestra red. La comprobación de las alertas de este PCAP nos garantiza que nuestra plataforma está detectando correctamente diversos tipos de Malware, como Dridex y Ficker, además de estar analizando en casos de posibles peticiones sospechosas y ataques de phising mediante el uso de certificados no válidos. Análisis del PCAP_2021-01-21 Tras la inyección de este PCAP al sistema y el posterior filtrado temporal en Kibana, hemos obtenido 349 alertas de red, como se puede ver en la imagen 7.5 102 Capítulo 7. Pruebas Imagen 7.5: Alertas generadas PCAP_2021-01-21 Tras un breve análisis de las reglas por las cuales se han generado esas alertas, hemos llegado a la conclusión de que este PCAP muestra todos los pasos realizados para lograr que nuestra infraestructura se encuentre infectada por malware. Mediante este ejemplo, se pretende demostrar que la plataforma es capaz de detectar las fases previas del ataque, pudiendo así evitarlo antes de que se realice. Las reglas empleadas se pueden observar en la tabla 7.3 Regla Nº de alertas ET JA3 Hash - [Abuse.ch] Possible Gozi 178 ET JA3 Hash - [Abuse.ch] Possible Quakbot 156 ET MALWARE Likely Evil EXE download from MSXMLHTTP 3 ET INFO Dotted Quad Host RAR Request 2 ET MALWARE Ursnif Payload Request (grab32.rar) 2 ET POLICY DNS Update From External net 2 ET POLICY External IP Lookup Domain 2 ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response 1 ET MALWARE Generic .bin download from Dotted Quad 1 ET MALWARE Zbot Generic URI/Header Struct .bin 1 ET POLICY PE EXE or DLL Windows file download HTTP 1 Tabla 7.3: Reglas empleadas PCAP 2021-02-08 Las alertas obtenidas, nos indican que actualmente se están ejecutando dos troyanos, los cuales están centrados en la obtención de credenciales bancarias. Los nombres de estos troyanos son Gozi, también denominado Ursnif, y Quakbot. Las siguientes reglas, muestran las alertas obtenidas debido a la ejecución de los dos troyanos mencionados: • ET JA3 Hash - [Abuse.ch] Possible Gozi • ET JA3 Hash - [Abuse.ch] Possible Quakbot • ET MALWARE Ursnif Payload Request (grab32.rar) Como hemos mencionado, este PCAP nos informa de manera completa de la inclusión de estos troyanos. Debido a este hecho, disponemos de alertas que nos indican la descarga de los archivos maliciosos que forman los troyanos. Las reglas en las que podemos ver que se ha realizado la descarga del ejecutable que contiene el troyano son las siguientes: • ET MALWARE Likely Evil EXE download from MSXMLHTTP 7.3 Análisis de alertas obtenidas 103 • ET MALWARE Generic .bin download from Dotted Quad Si analizamos las alertas de forma individual, se observa que los archivos maliciosos se han descargado en nuestro sistema mediante peticiones MSXMLHTTP realizadas de forma no deseada. La descarga del troyano se ve de forma clara en el mensaje asociado a la alerta, puesto que en él vemos un archivo files en la petición de nombre 1.bin que se corresponde con el mostrado en las alertas de ejecución de los troyanos. Este mensaje asociado se puede observar en la parte final del anexo 9.4. 110 Capítulo 8. Conclusiones y Trabajo Futuro [28] Incibe 2021. Diseño y Configuración De IPS, IDS y SIEM En Sistemas De Control Industrial. URL: www.incibe-cert.es/blog/diseno-y-configuracion-ips-ids-y-siemsistemas-control-industrial. (último acceso: Abril 2021) (citado en páginas 21, 22). [29] Jeff Petters 2020. IDS vs. IPS: What is the Difference? URL: https://www.varonis.com/ blog/ids-vs-ips/. (último acceso: Febrero 2021) (citado en página 25). [30] Tim Keary 2021. IDS vs IPS - What’s the Difference Which do You Need.URL: https : //www.comparitech.com/net-admin/ids-vs-ips/#What_is_an_IDS_and_What_ Does_it_Do. (último acceso: Febrero 2021) (citado en página 25). [31] LogPoint 2021. What is SIEM? A complete guide to SIEM: Benefits of a SIEM solution.URL: https://www.logpoint.com/en/understand/what-is-siem/ . (último acceso: Abril 2021) (citado en página 26). [32] Imperva 2020. What is SIEM: Security Information and Event Management Tools: Imperva. URL: https://www.imperva.com/learn/applicationsecurity/siem/ . (último acceso: Abril 2021) (citado en página 26). [33] Techslang 2020. What is SIEM - Definition by Techslang.URL: https://www.techslang. com/definition/what-is-siem/. (último acceso: Abril 2021) (citado en página 26). [34] Jeff Goldman 2018. ArcSight vs Splunk: SIEM Product Comparison.URL: https://www. esecurityplanet.com/products/arcsight-vs-splunk/ . (último acceso: Abril 2021) (citado en páginas 26, 27). [35] Check Point Software 2021. What is SOC (Security Operation Center).URL: https://www. checkpoint.com/cyber-hub/threat-prevention/what-is-soc/ . (último acceso: Abril 2021) (citado en página 28). [36] IBM 2021. Security Information and Event Management (SIEM) Solutions.URL: https : / / www . ibm . com / security / security - intelligence . (último acceso: Abril 2021) (citado en página 28). [37] TrustRadius 2019. Pros and Cons of IBM QRadar 2021.URL: https://www.trustradius. com/products/ibm-qradar/reviews?qs=pros-and-cons . (último acceso: Abril 2021) (citado en página 28). [38] Deepti Vidyarthi 2013 Surya Bhagavan Ambati. A brief study and comparison of, open source intrusion detection system tools.URL: http://www.iraj.in/journal/journal_file/ journal_pdf/32713908783672632.pdf . (último acceso: Mayo 2021) (citado en página 29). 8.2 Trabajo futuro 111 [39] Snort 2021. Pagina web y documentación de Snort.URL: https://www.snort.org/ . (último acceso: Mayo 2021) (citado en página 29). [41] Suricata 2021. Documentación Suricata.URL: https://suricata.readthedocs.io/en/ latest/index.html. (último acceso: Mayo 2021) (citado en página 32). [42] Zeek 2021. Zeek Documentation.URL: https://docs.zeek.org/en/master/ . (último acceso: Mayo 2021) (citado en página 35). [43] OSSEC Project Team 2021. Documentación de Ossec.URL: https://www.ossec.net/ docs/. (último acceso: Mayo 2021) (citado en páginas 36, 37). [44] Wazuh 2021. Wazuh · The Open Source Security Platform.URL: https://wazuh.com/ . (último acceso: Mayo 2021) (citado en página 39). [45] Tripwire 2021. Security Configuration Management (SCM).URL: https://www.tripwire. com/products/tripwire-enterprise/ . (último acceso: Mayo 2021) (citado en página 40). [46] Hannes von Haugwitz 2010. Documentación de AIDE.URL: https://aide.github.io/ . (último acceso: Mayo 2021) (citado en página 41). [47] 24 Alternatives To Samhain, Pros, Cons Questions. 2020. URL: https://hackerspad.net/ software/samhain/#pros. (último acceso: Mayo 2021) (citado en página 41). [48] Security Onion 2021. Security Onion Documentation.URL: https://docs.securityonion. net/en/2.3/. (último acceso: Junio 2021) (citado en páginas 47, 48, 54–56). [49] Elastic NV 2021. ELK Stack: Elasticsearch, Logstash, Kibana.URL: https://www.elastic. co/es/what-is/elk-stack. (último acceso: Mayo 2021) (citado en página 49). [50] Osquery 2021. Documentación de Osquery.URL: https://osquery.readthedocs.io/ en/stable/. (último acceso: Mayo 2021) (citado en página 51). [51] Redis Labs 2021. Redis.URL: https://docs.securityonion.net/en/2.3/redis. html#redis. (último acceso: Mayo 2021) (citado en página 51). [52] Ayush Jain 2020. Redis vs. MySQL Benchmarks - DZone Database.URL: https://dzone. com/articles/redis-vs-mysql-benchmarks . (último acceso: Mayo 2021) (citado en página 51). [53] Gchq 2021. CyberChef.URL: https://github.com/gchq/CyberChef . (último acceso: Mayo 2021) (citado en página 53). [54] Red Hat Inc. n.d. Información sobre Dockers.URL: https : / / www . redhat . com / es / topics/containers/what-is-docker . (último acceso: Mayo 2021) (citado en página 64). 112 Capítulo 8. Conclusiones y Trabajo Futuro [56] Malware-Traffic-Analysis.net 2021. Fuente de Pcaps.URL: https : / / www . malware - traffic-analysis.net/index.html. (último acceso: Mayo 2021) (citado en página 97). 9. Anexos 9.1 Ejemplo log de red 1{ 2"_index":"managernode1:so-zeek-2021.05.12", 3"_type":"_doc", 4"_id":"peUHY3kBJlSZx3lugbMy", 5"_version":1, 6"_score":null, 7"_source":{ 8"server":{ 9"port":"67", 10 "bytes":600, 11 "ip":"10.0.1.231", 12 "ip_bytes":656, 13 "packets":2 14 }, 15 "log":{ 16 "file":{ 17 "path":"/nsm/zeek/logs/current/conn.log" 18 }, 19 "offset":27758, 114 Capítulo 9. Anexos 20 "id":{ 21 "uid":"C68d003wcbzxSUCeg1" 22 } 23 }, 24 "destination":{ 25 "port":67, 26 "ip":"10.0.1.231" 27 }, 28 "source":{ 29 "port":68, 30 "ip":"255.255.255.255" 31 }, 32 "network":{ 33 "protocol":"dhcp", 34 "community_id":"1:0svgzrxr7mMGGAUzKNnwFzxf5tU=", 35 "bytes":600, 36 "transport":"udp" 37 }, 38 "ingest":{ 39 "timestamp":"2021-05-13T00:01:43.450Z" 40 }, 41 "observer":{ 42 "name":"sensornode3" 43 }, 44 "ecs":{ 45 "version":"1.6.0" 46 }, 47 "@version":"1", 48 "client":{ 49 "port":"68", 50 "bytes":0, 51 "ip":"255.255.255.255", 52 "ip_bytes":0, 9.1 Ejemplo log de red 115 53 "packets":0 54 }, 55 "connection":{ 56 "state_description":"Responder sent a SYN ACK followed by a FIN,we never saw a SYN from the originator", 57 "bytes":{ 58 "missed":0 59 }, 60 "state":"SHR", 61 "history":"^d", 62 "local":{ 63 "responder":true, 64 "originator":false 65 } 66 }, 67 "event":{ 68 "duration":42.40098690986633, 69 "module":"zeek", 70 "category":"network", 71 "dataset":"conn" 72 }, 73 "message":"{\"ts\":\"2021-05-12T23:59:59.863548Z\",\"uid\":\"C68d003 wcbzxSUCeg1\",\"id.orig_h\":\"255.255.255.255\",\"id.orig_p\":68,\" id.resp_h\":\"10.0.1.231\",\"id.resp_p\":67,\"proto\":\"udp\",\" service\":\"dhcp\",\"duration\":42.40098690986633,\"orig_bytes\":0, \"resp_bytes\":600,\"conn_state\":\"SHR\",\"local_orig\":false,\" local_resp\":true,\"missed_bytes\":0,\"history\":\"^d\",\"orig_pkts \":0,\"orig_ip_bytes\":0,\"resp_pkts\":2,\"resp_ip_bytes\":656,\" community_id\":\"1:0svgzrxr7mMGGAUzKNnwFzxf5tU=\"}", 74 "tags":[ 75 "beats_input_codec_plain_applied" 76 ], 77 "@timestamp":"2021-05-12T23:59:59.863Z" 116 Capítulo 9. Anexos 78 }, 79 "fields":{ 80 "@timestamp":[ 81 "2021-05-12T23:59:59.863Z" 82 ], 83 "Push to TheHive":[ 84 "https://managernode1/soctopus/thehive/case/peUHY3kBJlSZx3lugbMy" 85 ] 86 }, 87 "sort":[ 88 1620863999863 89 ] 90 } 9.2 Ejemplo log de host 117 9.2 Ejemplo log de host 1{ 2"_index":"managernode1:so-ossec-2021.05.12", 3"_type":"_doc", 4"_id":"iuUEY3kBJlSZx3lu1a6i", 5"_version":1, 6"_score":null, 7"_source":{ 8"agent":{ 9"name":"sensornode5-wazuh-manager", 10 "id":"000" 11 }, 12 "manager":{ 13 "name":"sensornode5-wazuh-manager" 14 }, 15 "log":{ 16 "file":{ 17 "path":"/wazuh/archives/archives.json" 18 }, 19 "offset":24749237, 20 "location":"df -P", 21 "id":{ 22 "id":"1620863925.4698" 23 }, 24 "full":"ossec:output:’df -P’:/dev/sdd1 20960256 18647744 2312512 89% /var/ossec/data" 25 }, 26 "decoder":{}, 27 "message":"{\"timestamp\":\"2021-05-12T23:58:45.367+0000\",\"agent\": {\"id\":\"000\",\"name\":\"sensornode5-wazuh-manager\"},\"manager\" :{\"name\":\"sensornode5-wazuh-manager\"},\"id\":\"1620863925.4698 \",\"full_log\":\"ossec:output:’df -P’:/dev/sdd1 2096025 6 18647744 2312512 89% /var/ossec/data\",\"decoder\":{\"name 118 Capítulo 9. Anexos \":\"ossec\"},\"location\":\"df -P\"}", 28 "tags":[ 29 "beats_input_codec_plain_applied" 30 ], 31 "@timestamp":"2021-05-12T23:58:48.640Z", 32 "ecs":{ 33 "version":"1.6.0" 34 }, 35 "@version":"1", 36 "host":{ 37 "name":"sensornode5" 38 }, 39 "event":{ 40 "code":"", 41 "module":"ossec", 42 "category":"host", 43 "dataset":"ossec", 44 "timestamp":"2021-05-12T23:58:45.367+0000" 45 } 46 }, 47 "fields":{ 48 "@timestamp":[ 49 "2021-05-12T23:58:48.640Z" 50 ], 51 "Push to TheHive":[ 52 "https://managernode1/soctopus/thehive/case/iuUEY3kBJlSZx3lu1a6i" 53 ] 54 }, 55 "highlight":{ 56 "event.category.keyword":[ 57 "@kibana-highlighted-field@host@/kibana-highlighted-field@" 58 ] 59 }, 9.3 Ejemplo alerta de red 119 60 "sort":[ 61 1620863928640 62 ] 63 } 9.3 Ejemplo alerta de red 1{ 2"_index":"managernode1:so-ids-2021.05.12", 3"_type":"_doc", 4"_id":"IeX4YnkBJlSZx3lu7plG", 5"_version":1, 6"_score":null, 7"_source":{ 8"log":{ 9"file":{ 10 "path":"/nsm/suricata/eve-2021-05-12-23:23.json" 11 }, 12 "offset":13887, 13 "id":{ 14 "uid":"1045948698930669" 15 } 16 }, 17 "destination":{ 18 "geo":{ 19 "continent_name":"Europe", 20 "region_iso_code":"ES-VA", 21 "city_name":"Valladolid", 22 "country_iso_code":"ES", 23 "timezone":"Europe/Madrid", 24 "ip":"157.88.123.10", 25 "country_name":"Spain", 26 "region_name":"Valladolid",