Desarrollo de una honeynet en la UVa para la investigación de ataques informáticos

Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención en Tecnologías de la Información) Desarrollo de una honeynet en la UVa para la investigación de ataques informáticos Autor: D. Luis Tomé Urgellés Agradecimientos Este proyecto no se habría llevado a cabo de no ser por todas esas personas que han estado a mi lado durante el transcurso de la carrera. A los compañeros y amigos, los que ya tenía y los que he ido conociendo, por los buenos momentos y su compañía. A los profesores y en especial a mi tutor por darme los conocimientos y guiarme por el mundo de la informática. Y por último, a las tres personas más importantes de mi vida: mis padres y mi hermana. Por su apoyo emocional y económico como sus sabios consejos durante mi carrera académica. Universidad de Valladolid Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática (Mención en Tecnologías de la Información) Desarrollo de una honeynet en la UVa para la investigación de ataques informáticos Autor: D. Luis Tomé Urgellés Tutores: D. Blas Torregrosa García Resumen El principal objetivo de este trabajo de fin de grado es implementar y diseñar una red HoneyNet virtual. Se pretende con ello comprender el funcionamiento de esta red en una infraestructura existente como es la Universidad de Valladolid. La idea del proyecto nace de un incremento de ciberataques durante estos últimos años a empresas privadas e instituciones públicas que conllevan pérdidas millonarias o información confidencial. El objetivo de los atacantes siempre son los activos de las empresas almacenados en servidores y equipos, siendo estos los que reciben la mayoría de vectores de ataque. En consecuencia, para evitar estos ataques, se diseñó expresamente una red expuesta al público con el objetivo de engañar a los ciberatacantes para que crean que están explotando la verdadera red de la empresa. Esta red contendrá servicios alojados con un nivel específico de interacción y sin activos de empresa. Para este proyecto se desplegará una honeynet virtual que implemente servicios similares de la red de la Universidad de Valladolid y que sea capaz de capturar, centralizar y visualizar el tráfico generado de los diferentes sistemas por los intrusos, de alertar en caso de una detección de ataque y de analizar ese tráfico para sacar una conclusión de qué técnicas o Modus operandi usó el atacante. Índice Página 1. Introducción y objetivos 1 1.1. Antecedentes ............................................. 1 1.2. Objetivos y alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Planificación temporal 3 2.1. Gestiónderiesgos .......................................... 3 2.2. Planificacióntemporal........................................ 3 3. Descripción actual de la red universitaria de Valladolid 5 3.1. Infraestructura universitaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Reconocimientodeservicios..................................... 6 3.2.1. Reconocimiento de puertos con NMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Teoría Honeynet 12 4.1. ¿Qué es un honeypot?¿y una honeynet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. ClasificacióndeHoneypots ..................................... 13 4.2.1. Segúnsuutilidad....................................... 13 4.2.2. Según su interacción con los atacantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Arquitecturadehoneypots...................................... 15 4.3.1. GENI............................................. 15 4.3.2. GENII ............................................ 16 4.3.3. GEN III (Virtual Híbrida) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. ¿Dónde se ubica la Honeynet en la red de la empresa? . . . . . . . . . . . . . . . . . . . . . . 19 4.5. Tecnologías usadas durante el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.1. IPtables............................................ 19 4.5.2. Docker............................................. 20 4.5.3. PilaELK ........................................... 22 4.5.4. Suricata............................................ 24 5. Honeynet UVa 26 5.1. Arquitectura de la red Honeynet UVa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2. Especificacionesdehardware .................................... 27 5.3. Configuración de las conexiones de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.1. Configuración NAT en el HoneyWall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3.2. Configurar Port Forwarding en el HoneyWall . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.3. Configuración DNS en el HoneyWall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4. Instalación de Docker y sus contenedores en el HoneyDocker . . . . . . . . . . . . . . . . . . . 31 5.4.1. InstalacióndeDocker .................................... 31 5.4.2. Docker nginx de aulas.inf.uva.es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.4.3. Docker SSH de jair.lab.inf.uva.es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.5. InstalacióndeSuricata........................................ 35 5.6. InstalacióndeStackELK ...................................... 37 5.7. InstalacióndeFilebeat........................................ 40 5.8. Creación de Dashboard Kibana para Logs de Suricata . . . . . . . . . . . . . . . . . . . . . . 43 5.9. Recolección de diferentes logs con Filebeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.9.1. Eventosdelsistema ..................................... 45 5.9.2. TráficoderedPacketbeat .................................. 46 5.9.3. Eventos de los contenedores Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6. Batería de pruebas 50 6.1. Ataque: Escaneo de puertos con NMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. Escaneo de vulnerabilidades con OpenVAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3. Fuerza bruta SSH contra Cowrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.4. Comandos Linux dentro del Docker Cowrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7. Conclusión y posibles mejoras a futuro 59 7.1. Conclusiones ............................................. 59 7.2. Posiblesmejorasafuturo ...................................... 59 8. ANEXO 62 8.1. Configuracióndered......................................... 62 8.2. Configuración DNS del HoneyWall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 8.3. ConfiguraciónIPtables........................................ 64 8.4. ConfiguraciónSuricata........................................ 66 8.5. ConfiguraciónStackELK ...................................... 68 8.6. ConfiguraciónFilebeat........................................ 68 8.7. ConfiguraciónPacketbeat ...................................... 70 Bibliografía 72 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 4: Mapa de interconexiones de Red CAYLE Estos dos routers externos de la red se comunican con cada uno de los routers de la capa óptica (León, Salamanca, Burgos y Valladolid). En este proyecto, nos centraremos en analizar los servicios que ofrece al exterior el router de Valladolid de la capa óptica. Éste también da soporte a los campus de Palencia, Segovia y Soria. Figura 5: Infraestructura de Red CAYLE 3.2. Reconocimiento de servicios Este paso es interesante cuando se quiere investigar que servicios replicar en la Honeynet. En este caso, ya decidimos imitar los servicios de jair.lab.inf.uva.es y aulas.inf.uva.es, pero aun así es un paso importante cuando desconoces los servicios de la red. Para hacer un reconocimiento de los servicios, se han utilizado herramientas como amass y NMAP. Amass [23] es una herramienta de código libre para el mapeo de superficies de ataque y descubrimiento de activos externos mediante la recopilación de información. Con esta herramienta, podemos obtener todos los subdominios recursivamente que cuelguen del dominio principal que será uva.es e ir escaneando los que veamos convenientes en busca de los servicios públicos que estén disponibles. Con el siguiente comando obtenemos todos los subdominios e IP de uva.es.   $ amass enum −ipv4 −d uva .es   Página 6 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 6: Algunos subdominios de uva.es Figura 7: Resumen de Amass sobre uva.es Como se puede ver, 10824 subdominios pertenecen a uva.es. Existen muchos que no están relacionados con la RedIRIS y la Universidad de Valladolid, otros están deshabilitados, no tienen ningún servicio o son Página 7 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 páginas creadas para un día en concreto. A partir de este punto, empieza la investigación por parte del administrador de la Honeynet de buscar los servicios que podrían ser más interesantes para los intrusos, nosotros en este TFG escogeremos dos servicios de la rama de Ingeniería Informática como es aulas.inf.uva.es y jair.lab.inf.uva.es. Dominio IP Funcionamiento del Dominio aulas.inf.uva.es 157.88.109.245 Moodle virtual para alumnos y profesores de la Escuela de Ingeniería Informática jair.lab.inf.uva.es 157.88.125.192 Servidor para conectarnos a nuestro perfil de alumno de Ingeniería Informática Cuadro 1: Tabla de dominios a implementar en la HoneyNet El uso de Amass es interesante cuando se desconoce que subdominios tiene una IP o si se esta utilizando virtual hosting o alojamiento compartido. La infraestructura de la UVa utiliza la dirección de red pública 157.88.0.0/16. 3.2.1. Reconocimiento de puertos con NMAP Una vez localizados estos dos dominios, pasaremos a escanear sus puertos con NMAP. NMAP [key6] es una herramienta de código abierto que sirve para efectuar escaneos de puertos o equipos en internet o una red interna. De esta manera, podemos saber si un host tiene puertos abiertos, si están filtrados por un firewall, detectar qué servicios se están ejecutando en esos puertos, e incluso obtener que sistema operativo y versiones utiliza el objetivo. Las opciones que tenemos para realizar un escaneo son numerosas. Sin embargo, en este caso usaremos las opciones: -p- para que compruebe todos los puertos (0-65536) -O para identificar el sistema operativo y versión -f para fragmentar los paquetes de escaneo por si hay algún firewall o IDS entre medias -Pn para evitar que nos bloqueen los ping el firewall o un dispositivo de seguridad -oN para guardar la salida del comando en un fichero.   $ nmap −p− −O−f−Pn 157.88.109.245 −oN aulas .txt   Página 8 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 8: NMAP sobre aulas.inf.uva.es Con esto obtenemos todos los puertos pero sin mucha información de qué hay detrás de estos puertos. Entonces ejecutamos un segundo comando especificando los puertos abiertos que nos han aparecido con -p[port],[port] y con -sV para obtener más información sobre estos. La información que podemos obtener de cada puerto depende de si esta filtrado por el firewall, si aparece ’closed’ y otros factores.   $ nmap −p80 ,443,8008 −sV −f−Pn 157.88.109.245 −oN aulas_port_sv .txt   Figura 9: NMAP sobre aulas.inf.uva.es con la opción -sV En este caso, solo hemos obtenido mas información del puerto 80 y 443 que es un servicio de Apache httpd con versión PHP 7.3.25. Realizamos la misma operación sobre el dominio jair.lab.inf.uva.es para tener una idea de que servicios y versiones implementaremos en nuestra honeynet: Página 9 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 10: NMAP sobre jair.lab.inf.uva.es aulas.inf.uva.es: •Port 80 y 443: Aloja un servicio apache httpd y versión PHP 7.3.25 para la web de aulas de Ingeniería Informática. •Port 8008: Sobre este puerto no se ha obtenido ningún tipo de información. Figura 11: Portal web/moodle alojado en aulas.inf.uva.es Página 10 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 jair.lab.inf.uva.es: •Port 22: Protocolo SSH versión OpenSSH 8.4 •Port 8008: Sobre este puerto no se ha obtenido ningún tipo de información. Página 11 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 4. Teoría Honeynet Dentro de las organizaciones, la mayoría tienen implementadas soluciones o dispositivos de seguridad conocidos como pueden ser firewalls, IDS, IPS, sniffers, antivirus, soluciones contra DDoS, VPNs, proxy pero en muy pocas empresas se despliega una solución como son los Honeypots o Honeynet. Esta solución es desconocida incluso por gente del sector TIC que no sabe cuál es su finalidad, qué tipos de honeynet existen, dónde se puede desplegar esta arquitectura, con qué programas trabaja conjuntamente y otra serie de preguntas. En este apartado, resolveremos este tipo de preguntas teóricas. 4.1. ¿Qué es un honeypot?¿y una honeynet? Un honeypot o sistema trampa es un dispositivo de seguridad basado en un sistema con ficheros, directorios y servicios como un sistema real implementado en la red cuyo objetivo es ser probado, atacado y comprometido por un posible ataque informático, para así detectarlo y permitir el análisis del ataque en un entorno controlado. [key32] Un honeypot, como se puede observar, no es una herramienta preventiva ya que su función es la de recoger información de ataques informáticos y detectar la firma de estos, por lo que es más una herramienta de detección. Además de ser una herramienta de detección, entra dentro de la categoría de herramientas de respuesta ya que, una vez recogida la información , se analiza el proceso de cómo se ejecutó el ataque, si se ha utilizado una herramienta de escaneo de puertos , de detección de vulnerabilidades, fuerza bruta, o métodos desconocidos, dando lugar a los encargados de la seguridad de la red a desplegar una respuesta y contramedida contra este tipo de amenazas. Como conclusión, un honeypot es una herramienta que recoge información y evidencias sobre las potenciales amenazas y vulnerabilidades de redes y sistemas, y obtiene el conocimiento para ejecutar una contramedida ante estos ataques. Figura 12: Tipos de honeypots según el tipo de información que se quiera recopilar Página 12 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 La honeynet, como se puede deducir, es una arquitectura de red formada por honeypots y su función es la misma: ser atacada para posteriormente recopilar información. Los Honeypots pueden jugar diferentes roles en la red de una organización: mejora de IDS y Firewalls, investigación, respuesta a incidentes, análisis forense, engaño a los atacantes y disuasión. Este tipo de herramientas deben ser desplegadas y mantenidas por manos expertas, ya que una mala configuración del sistema puede llevar a generar una entrada al sistema de producción o red de la empresa, o a que el honeypot sea usado para comprometer otras empresas externas usándolo como un proxy. Por lo tanto, los honeypots/honeynet deben ser atendidos y actualizados constantemente y suelen ir respaldados por otros dispositivos de seguridad como firewalls, IDS/IPS, antivirus, UTM, etc, así como políticas de seguridad y procesos auditados. 4.2. Clasificación de Honeypots Dentro de los honeypots, se pueden diferenciar en varias categorías: según su utilidad (producción o investigación) o según la interacción del atacante (baja, media o alta). [key33] 4.2.1. Según su utilidad Honeypots de producción: Se usan para proteger la infraestructura interna de la red. Es necesario que estén correctamente diseñados e implementados ya que puede llegar a ser un punto vulnerable de la red, aunque su naturaleza sea ser probados y atacados, se debe tener precaución. La finalidad de este tipo de honeypots es desviar o mitigar el riesgo de cualquier red contra los ciberataques. El despliegue e implementación de los honeypots de producción son más sencillos ya que requieren menos funcionalidad y servicios ejecutándose. Honeypots de investigación: Se usa para acumular evidencias e información con el fin de analizar el comportamiento, patrones, firmas y motivos por los que el atacante ha perpetrado este ataque contra la red o sistema. La información que podemos obtener a través de esta herramienta son qué herramientas ha utilizado para el ataque, el sistema operativo, tipos de exploits utilizados, si se trata de un hacker individual, un grupo terrorista o de un país, la metodología usada, etc. Con este análisis podemos sacar conclusiones que ayuden a otras empresas a alertar y mitigar estos ataques, advertir a entidades que estén en el punto de mira según el motivo de los atacantes (información de personas, empresas, gobiernos, etc..) Como conclusión, si una organización quiere proteger sus activos de ataques informáticos, con un honeypot de producción se pueden bloquear los ataques potenciales y perseguir a los atacantes. En cambio, si se quiere conocer las técnicas, metodologías, comportamientos, herramientas, exploits, grupo de atacantes, etc. para aprender y poderlo aplicar a sistemas de seguridad en modo de actualización o parchear fallos, el honeypot de investigación es el más adecuado. 4.2.2. Según su interacción con los atacantes Otro tipo de honeypot que podemos distinguir son por el nivel de interacción con los atacantes y la capa de la pila de componentes de un servicio que sea emulado en el honeypot. Página 13 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Honeypots de baja interacción: Los aspectos para la implementación son sencillos, ya que son procesos de instalación, configuración, despliegue y mantenimiento, que no llevan ninguna complejidad. En estos sistemas se emulan los sistemas operativos, protocolos y servicios básicos sobre un host con Microsoft Windows o Linux, y puede ser en una máquina física o entorno virtualizado como VMware, Promox, KVM. Estos sistemas deben ser bastionados para prevenir que el atacante pueda obtener acceso al sistema que soporta la virtualización o sistema host. El nombre de baja interacción viene dado porque el atacante solo tendría capacidad para conocer el sistema operativo que se está emulando, aprovechar alguna vulnerabilidad básica o escalada de privilegios sobre algún servicio básico del honeypot, pero nada más, ya que no se está ejecutando ningún servicio real. Algunos de los resultados que podemos obtener, son si el atacante ha utilizado fuerza bruta para acceder al servicio FTP, SSH, correo, con qué datos ha probado los intentos, la fecha y hora a la que se realizó el ataque, protocolo, herramienta, dirección IP, etc. El nivel de riesgo de estos honeypots es bajo, ya que no pueden ser utilizados como puente para atacar otras partes de las redes, puesto que simulan el servicio y no es real. Algunos ejemplos de honeypots de baja interacción son Specter, Honeyd, SF Sensor. Honeypots de media interacción: El despliegue del sistema operativo y servicios es más real, proveyendo de más información al atacante. Un ejemplo es que pasamos a poder emular servicios de base de datos o servidores de aplicaciones. El honeypot debe estar configurado para responder parcialmente a los ataques ya que, los protocolos, puertos y funciones deben estar emulados de forma correcta. Como este despliegue es parcial y los servicios y aplicaciones no son completamente reales, el ataque no se puede ejecutar del todo, por lo que obtenemos más información que el honeypot de baja interacción pero sin llegar a que el intruso pueda terminar su ataque. Este tipo de honeypots requiere más conocimientos para implementarlos, por el simple hecho que debe saber cómo funcionan los protocolos y qué hacen los servicios y aplicaciones a emular. Además es importante asegurar que el sistema operativo real sea robusto contra la intrusión para que en caso de ser comprometido no afecte a la red. Honeypots de alta interacción: En este sistema no se emula nada, todos los servicios y aplicaciones son reales. Por lo tanto, hay un aumento del riesgo pero a su vez se amplía el alcance de la información que se puede obtener de un atacante. Al ser los sistemas reales, la instalación, despliegue y configuración pasan a ser muy complejas y necesariamente realizadas por alguien experto en la materia y con un gran conocimiento en las aplicaciones que se van a instalar. El fin de este tipo de honeypot es que el atacante se haga con el control del honeypot, de manera que obtenga privilegios de super usuario. La información que podemos obtener de estos atacantes, a parte de la mencionada en los de interacción baja y media, es el poder monitorizar la interacción con todos los componentes del servicio, como el sistema operativo, middleware, aplicaciones, etc.. Al ser un riesgo muy elevado, este honeypot debe estar monitorizado 24 horas por un experto y aislados de la red de producción de la empresa para reducir la capacidad del atacante mediante un firewall o IDS que bloquee el tráfico saliente a otra red. Página 14 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 4.3. Arquitectura de honeypots A la hora de crear una arquitectura de honeynet, existe una absoluta libertad de qué topología de red diseñar y de qué herramientas usar para capturar la información, monitorizar, controlar y analizar el tráfico del atacante. Sin embargo existen tres tipos de arquitecturas básicas llamadas GEN I, GEN II o GEN III (virtual). 4.3.1. GEN I Esta arquitectura es la más clásica de todas, conformada por un firewall fronterizo al exterior para filtrar el tráfico y redirigirlo o a la honeynet o a la red de producción, un router detrás del firewall que separa la red de producción y la honeynet y ayuda a reforzar la seguridad junto al firewall, y un IDS conectado a la red de producción y a la red de honeynet mediante port mirroring. Figura 13: Infraestructura de HoneyNet de generación I El firewall controla las conexiones entrantes y salientes, pero además de eso, tiene que controlar el límite de conexiones que se realiza de un honeypot a Internet, cerrando conexiones cada x número de conexiones por hora. Esto se puede hacer automáticamente o manualmente ya que, si el técnico encargado de vigilar quiere aprender más sobre el ataque que se está realizando, puede levantar la mano un poco al atacante. Esto se hace para que el atacante no realice ataques DDoS o fuerza bruta usando los honeypots como equipo intermediario. El router está después del firewall para: Página 15 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Incompatibilidad con ciertas aplicaciones: Las aplicaciones con ventanas o gráficas no son compatibles con los contenedores o incluso algunas aplicaciones por la manera en que Docker encapsula una aplicación con sus librerías esenciales y configuraciones. Si se requiere una librería adicional se complica la configuración del contenedor Docker. 4.5.3. Pila ELK La pila ELK [key12] es un conjunto de herramientas de gran potencial de código abierto que se combinan para crear una herramienta de administración de registros permitiendo la monitorización, consolidación y análisis de logs generados en múltiples servidores. ELK está compuesto por las herramientas: Elasticsearch, Logstash y Kibana. La pila ELK se implementa en muchos centros de respuesta ante incidentes de seguridad como CERT, CSIRT y SOC, ya que ofrece la detección de incidencias en tiempo real, almacenamiento de gran cantidad de información, escalabilidad de un sistema, centralización y búsqueda compleja de la información de los logs. Sin este conjunto de herramientas sería bastante difícil o casi imposible monitorizar o esclarecer los incidentes que ocurran en una red donde puede haber más de 100 dispositivos generando logs. [key13] A continuación, se hace una explicación de cada componente de la pila ELK: Logstash es la herramienta que se utiliza para recolectar, analizar (parsear) y guardar los logs para futuras búsquedas. Logstash soporta : •Entradas: Son las fuentes de datos de dispositivos que generar los logs en la red como puede ser un firewall, endpoint o servidor. •Codecs: Convierten un formato de entrada en un formato aceptado por Logstash. •Filtros: Se utilizan para procesar (parsear) los eventos y que se vean con un formato más adecuado y estructurado. •Salidas: Son los destinos donde los datos ya procesados serán enviados, normalmente será al Elasticsearch. Los problemas que soluciona Logstash son la descentralización de los logs, ya que por cada dispositivo se genera uno o varios logs diferentes por cada aplicación que esté ejecutando. Con Logstash se pueden recibir todos estos logs y parsearlos para que tengan un formato más legible y más fácil de analizar. Cada log puede venir con un formato de tiempo distinto. Elasticsearch es un motor de búsqueda que se basa en Lucene el cual nos permite realizar búsquedas por una gran cantidad de datos de un texto específico. También se puede definir como una base de datos NoSQL orientada a documentos JSON y que nos permite indexar grandes volúmenes de datos para poder consultarlos posteriormente. Elasticsearch permite acceder a los datos en tiempo real. Kibana es un software de panel de visualización de datos para Elasticsearch. Proporciona capacidades de visualización además del contenido indexado en un clúster de Elasticsearch. Los usuarios pueden crear gráficos de barras, de líneas y de dispersión, o mapas sobre grandes volúmenes de datos. Kibana se relaciona con Elasticsearch para buscar, ver y visualizar datos indexados en Elasticsearch y analizarlos a través de la creación de gráficas de barras, tablas, histogramas y mapas. Desde Kibana se Página 22 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 pueden crear Dashboard que son recopilaciones de gráficos, grafos, métricas, búsquedas y mapas que se recopilaron en un solo panel, pudiendo así echar un vistazo sobre datos desde varias perspectivas y permitiendo a los usuarios explorar los detalles de estos [key14]. Beat es la herramienta que se utiliza en los servidores o dispositivos de la red para enviar los logs que generan al servidor ELK. Normalmente van directos al Elasticsearch o si necesitan otro formato pasan primero por el Logstash para parsearlos. Dicho de otra manera, son los agentes encargados de envíar datos o logs de cientos o miles de máquinas y sistemas a Logstash o Elasticsearch. Existen diferentes tipos de Beat, los más utilizados son: Filebeat: permite la recolección, parseo y envío de datos de ficheros logs. Metricbeat: permite la recolección y envío de métricas a nivel de sistema, como uso de CPU, memoria, sistema de ficheros, accesos a disco y a red,... Packetbeat: permite la monitorización de servicios y aplicaciones en tiempo real, obteniendo métricas como latencia, tiempo de respuesta, errores, patrones de acceso,... Winlogbeat: permite la recolección y envío de eventos de sistemas Windows. Auditbeat: permite la recolección y envío de métricas de auditoría de sistemas. Heartbeat: permite la monitorización de la disponibilidad y los tiempos de respuesta de los servicios. Ahora que tenemos un conocimiento de cada componente, explicaremos el funcionamiento en conjunto de la pila ELK combinado con Filebeat para obtener los logs del sistema. Lo primero es instalar Filebeat en todas las máquinas que se quieran monitorizar y después configurarlos para que envíen los datos a una máquina central. En esta máquina central, estará Logstash recopilando todos los logs que llegan, analizándolos y filtrando para enviárselos al Elasticsearch. Cuando nosotros realicemos una consulta será Elasticsearch el que buscará los datos que coincidan con la consulta, sobre enormes cantidades de datos, devolviéndonos el resultado. Por último, Kibana nos mostrará estos datos que indexó Elasticsearch para que el usuario final pueda visualizarlos en modo de gráficos, tablas, etc.. Figura 18: Proceso de Stack ELK Página 23 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 4.5.4. Suricata Suricata [key15] es un detector de red de alto rendimiento IDS (Intrusion Detection System), IPS y seguridad de red. Está basado en un conjunto de reglas desarrolladas para supervisar el tráfico de la red y proporcionar alertas al administrador del sistema cuando se producen ciertos eventos que coinciden con las firmas o reglas. Algunas de sus características son: Se puede integrar en componentes de seguridad de redes existentes. A diferencia de Snort, Suricata es Multi-Threaded que permite procesar una mayor cantidad de paquetes de forma simultánea. Con Suricata se pueden escribir reglas independientemente del puerto que un protocolo use por defecto. Genera logs de estadísticas y análisis de rendimiento. Al ser código abierto, hay muchos repositorios de alertas community para aplicarlas sobre nuestra red. El modo de ejecución por defecto de Suricata es autofp. Este modo balancea automáticamente la carga de flujo, es decir, que los paquetes de cada flujo distinto se asignan a un solo hilo de detección. Los flujos se asignan a los subprocesos con el número más bajo de paquetes no procesados. Para ejecutar Suricata desde la línea de comandos sobre una interface como “ens38”: [key16] [key17]   $ suricata −i ens38 −c/etc/suricata/suricata .yaml −s/etc/suricata/ rules −l/var/log/suricata −D−user suricata −group suricata   Si necesitamos configurar el Suricata lo haremos a través del fichero /etc/suricata/suricata.yaml. Para añadir reglas personalizadas usaremos el fichero /etc/suricata/rules/custom-rules. Si tenemos un fichero con reglas lo copiamos en la carpeta /etc/suricata/rules. Los logs que genera el Suricata se pueden dividir en varios ficheros (/var/log/suricata): suricata.log: Eventos propios del servicio Suricata como inicializaciones, errores, reinicios ... stats.log: Estadísticas regulares acerca del tráfico que se ha ido analizando hasta el momento. fast.log: Eventos disparados por las reglas. Es muy útil para hacerse una idea rápida de qué ha ocurrido en la red. eve.json: Alertas detectadas y todos los detalles del tráfico capturado en formato JSON. El formato para la creación de una regla es el siguiente: action tcp $HOME_NET any ->$EXTERNAL_NET any (msg: “message”;) La parte roja corresponde con la acción que se debe realizar cuando se cumpla la regla (alert, drop, reject, rejectsrc, rejectdst, rejectboth). La parte verde se refiere al protocolo (tcp, udp, http, ftp, smtp,...), IP origen y IP destino, incluyendo los puertos que se deben cumplir para que salte la regla. Por último, la parte azul detalla las opciones como el mensaje de la alerta, el identificador de la regla, el tipo de classtype, opciones sobre el protocolo de la regla, etcétera. Un ejemplo de una regla: Página 24 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 drop http $EXTERNAL_NET any ->$HOME_NET 22 (msg:“SSH Detected”; ssh.proto; sid:1;) Esta regla comprueba que si una petición SSH se realiza desde fuera hacia dentro sea descartada, y cuando salte muestre el mensaje “SSH Detected” en los logs. Para que no sea muy tedioso agregar reglas una a una, existe una herramienta como suricata-update [key18] que se encarga de actualizar las reglas a través de repositorios de reglas de empresas de Threat Intelligence como Proofpoint. Página 25 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 5. Honeynet UVa 5.1. Arquitectura de la red Honeynet UVa El despliegue se ha desarrollado en un entorno totalmente virtualizado mediante VMware Workstation Pro para reducir costes y centralizar el proyecto. La idea del proyecto es poderlo implementar físicamente en la red de la Universidad de Valladolid en un futuro. El diseño de la Honeynet corresponde con una estructura de tipo híbrida virtual compuesta por el HoneyWall y HoneyDocker, soportado por un Debian 10 Buster como sistema operativo, y el equipo del intruso, que tiene como sistema operativo Kali Linux. En este caso, el HoneyWall y el HoneyDocker están virtualizados, y los honeypots que contendrá la red serán los Dockers virtualizados dentro del propio HoneyDocker. De esta manera, tendremos una red muy flexible y de fácil escalabilidad. El HoneyWall será donde recaerá el mayor peso del proyecto, debido a que este sistema tendrá la funcionalidad de filtrar, alertar y actuar contra las conexiones entrantes y salientes de la Honeynet; recopilar, centralizar y analizar la información de la red y los sistemas del HoneyDocker. Este sistema a parte de las características que se han expuesto anteriormente, tiene la funcionalidad de router, ya que interconecta la red del atacante (WAN) con el sistema de HoneyDocker que esta dentro de la LAN. El HoneyDocker estará ejecutando servicios replicados de la UVa para ser vulnerados sobre los contenedores Docker. Recopilará la información que sea generada por parte del atacante en sus contenedores y a continuación la enviará al HoneyWall. El intruso o atacante Kali Linux simulará los ataques informáticos realizados desde la WAN o Internet para ver y analizar el funcionamiento de la Honeynet. Figura 19: Diagrama de red del proyecto HoneyNet UVa En el diagrama de red se identifican dos redes virtualizadas: Página 26 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 La red que simula una WAN o Internet (10.10.2.0/24) conformada por el intruso (Kali Linux / 10.10.2.2), que atacará al HoneyDocker a través del HoneyWall (10.10.2.1). La red que simula una LAN (10.10.1.0/24) dentro de la UVa formada por el HoneyWall (10.10.1.1) y el HoneyDocker (10.10.1.2). Conexión al exterior a través del sistema Host. Es necesario que estas máquinas estén conectadas al exterior para la descarga de paquetes, actualizaciones, etcétera. El sistema HoneyDocker se conecta a Internet a través del HoneyWall una vez configuradas las IPtables. 5.2. Especificaciones de hardware Teniendo en cuenta que este proyecto se esta desarrollando sobre un entorno totalmente virtualizado, el propio sistema host debe tener unas altas especificaciones de hardware para poder soportar 3 máquinas ejecutándose al mismo tiempo. Cada máquina virtualizada, requiere un determinado rendimiento para su buen funcionamiento, por ejemplo, la máquina HoneyDocker al ejecutar contenedores Docker y no máquinas virtuales con su sistema operativo completo, se maximiza el rendimiento de la máquina con el mínimo de características hardware. En cambio, el HoneyWall al soportar una estructura de tipo pila ELK y demás tecnologías de captura de tráfico necesita un mayor rendimiento de memoria RAM. Figura 20: Especificaciones Hardware 5.3. Configuración de las conexiones de red Para configurar las conexiones entre los diferentes sistemas, se ha modificado el fichero /etc/network/interfaces de cada sistema Linux (HoneyWall , HoneyDocker y Kali Linux). En la red WAN que contiene al Kali y HoneyWall esta definida la dirección IP de red 10.10.2.0/24 y en la red LAN que se encuentra el HoneyDocker y HoneyWall esta definida la dirección IP de red 10.10.1.0/24. Para que el Kali Linux pueda acceder a los servicios del HoneyDocker es necesario configurar lo siguiente: El HoneyWall tiene que ser capaz de hacer enrutamiento por NAT para cambiar paquetes entre dos redes diferentes. Página 27 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 El HoneyWall debe tener configurado port forwarding para redirigir un puerto de red de un nodo de red a otro. Se tiene que configurar un DNS en el HoneyWall para resolver los nombres de dominio. 5.3.1. Configuración NAT en el HoneyWall Para configurar NAT en el HoneyWall, lo haremos a través de IPtables, que es una herramienta de Linux que se encarga de filtrar los paquetes de red. Si queremos que el HoneyWall funcione como router, debemos poner la variable del sistema ’IP forwarding’ a 1 para IPv4 [key30].   $ echo "1" > /proc/sys/net/ipv4/ip_forward   Es importante, tener en cuenta que cada vez que reiniciemos el sistema, debemos reactivarlo. Por lo tanto, se puede crear un script en bash para cuando necesitemos activar o desactivar el ip forward y las reglas del firewall. En el transcurso de este proyecto iremos añadiendo nuevas iptables sobre estos script que llamaremos iptablesUp.sh para activar y iptablesDown.sh para desactivar el firewall. Por defecto, la política que tendrá el firewall es de aceptar todo tipo de tráfico y después se añaden reglas explícitamente para filtrar los paquetes.   $ iptables −P INPUT ACCEPT $ iptables −P OUTPUT ACCEPT $ iptables −P FORWARD ACCEPT $ iptables −t nat −P PREROUTING ACCEPT $ iptables −t nat −P POSTROUTING ACCEPT   Debemos añadir las siguientes reglas para poder redireccionar mediante NAT los paquetes que vienen de nuestra red interna 10.10.1.0/24 y salen al exterior hacia la WAN del Kali (ens37) y hacia Internet a través de nuestro sistema host (ens33).   $ iptables −t nat −A POSTROUTING −s10.10.1.0/24 −o ens37 −j MASQUERADE $ iptables −t nat −A POSTROUTING −s10.10.1.0/24 −o ens33 −j MASQUERADE   Con esta configuración el HoneyDocker es capaz de comunicarse con el Kali Linux que se encuentra en otra red distinta. Figura 21: Comprobación de conectividad de HoneyDocker a Kali Linux Vemos que conecta perfectamente con Kali Linux. Sin embargo, si lo hacemos al revés no funcionaría, ya que la conexión de Kali Linux a HoneyDocker debe ser redirigida por el HoneyWall hacia un puerto concreto del HoneyDocker. Esto se puede implementar mediante IPtables con port forwarding NAT. Página 28 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 5.3.2. Configurar Port Forwarding en el HoneyWall Port Fordwarding es el proceso de redireccionar con NAT un puerto específico de un host, en este caso el HoneyWall, hacia otro puerto de otro equipo de la red, como puede ser el HoneyDocker. Como todavía no tenemos ejecutando ningún contenedor en el HoneyDocker, vamos a redireccionar el puerto 333 del HoneyWall hacia el puerto 80 del HoneyDocker para ver el funcionamiento del Port Forwarding.   $ iptables −A FORWARD −m state −p tcp −d10.10.1.2 − −dport 80 − −state NEW ,ESTABLISHED ,RELATED −j ACCEPT $ iptables −t nat −A PREROUTING −p tcp −−dport 333 −j DNAT −−to− destination 10.10.1.2:80   Si activamos estas reglas, desde Kali Linux podemos ejecutar desde el navegador http://10.10.2.1:333 que nos mostrará la página que está alojada en el puerto 80 del HoneyDocker. Estas reglas son un ejemplo o comprobación de que funciona y no se añadirán al script final de iptablesUp.sh . Figura 22: Port Forwarding 10.10.2.1:333 ->10.10.1.2:80 Como se puede ver, el atacante no conoce la IP final ni el recorrido que hace dentro de la LAN, pero mediante traceroute sí que puede saber los saltos que realiza el paquete. Si realizamos traceroute sobre el puerto 333 nos dará dos saltos por el HoneyWall y el HoneyDocker y si probamos con otro puerto como el 334 solo hace un salto, ya que no hay redirección aplicada a ese puerto. Figura 23: Traceroute sobre puerto con redirección / Traceroute sobre puerto normal Página 29 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 5.3.3. Configuración DNS en el HoneyWall Es necesario tener configurado un DNS en la red que resuelva los nombres de dominio y los asocie con una IP. El HoneyWall se va a encargar de esto mediante bind9, que es un software de código libre para implementar DNS en servidores Linux. Con este servicio DNS conseguiremos resolver los dominios de aulas.inf.uva.es yjair.lab.inf.uva.es para que se asocien con la IP del HoneyDocker. Tendremos que configurar los ficheros: /etc/bind/named.conf.options : Sobre este fichero tenemos que añadir los forwarders para que en caso de que nuestro servidor DNS no pueda resolver esa petición se envíe a un servidor externo que sí pueda, como pueden ser los de google (8.8.8.8 y 8.8.4.4). /etc/bind/named.conf.local : En este fichero añadiremos las zonas inf.uva.es y 1.10.10.in-addr.arpa que queremos que resuelva de forma directa e inversa respectivamente. /etc/bind/zones/db.inf.uva.es y /etc/bind/zones/db.10.10.1 : Sobre el fichero db.inf.uva.es configuramos la resolución directa añadiendo las líneas de name server (NS) y direcciones a resolver (A). En cambio, sobre el db.10.10.1 añadimos la línea de name server (NS) y para resolver las direcciones de forma inversa (PTR). Además de configurar el servidor DNS del HoneyWall, debemos cambiar el DNS sobre el que resuelven las peticiones los equipos de la red (Kali Linux, HoneyWall y HoneyDocker). Para ello, añadimos en el fichero /etc/resolv.conf lo siguiente:   nameserver 10.10.2.1   Con la parte del DNS configurada, ya podemos resolver los dominios que queremos simular en nuestra HoneyNet. Figura 24: Resolución de aulas.inf.uva.es y jair.lab.inf.uva.es desde Kali Linux Página 30 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 5.4. Instalación de Docker y sus contenedores en el HoneyDocker 5.4.1. Instalación de Docker La instalación de Docker [key34] se realiza mediante los repositorios oficiales de Debian y la última versión de Docker es la 20.10.5. Primero instalamos las dependencias que nos permitan usar paquetes sobre HTTPS:   $ sudo apt−get install apt−transport−https ca−certificates curl gnupg2 software−properties−common   Añadimos la GPG key del repositorio oficial de Docker a nuestro sistema:   $ curl −fsSL https :// download .docker .com/linux/debian/gpg |sudo apt−key add −   Añadimos el repositorio de Docker a /etc/apt/sources.list:   $ sudo add−apt−repository "deb [arch=amd64 ]https :// download .docker .com /linux/debian $(lsb_release −cs )stable"   Volvemos a actualizar los paquetes con apt-get update e instalamos el paquete docker-ce:   $ sudo apt−get install docker−ce   Una vez instalado comprobamos si está encendido, en caso de que no lo esté es así lo ejecutamos con systemctl start docker y vemos su estado con systemctl status docker. Figura 25: Status de servicio Docker 5.4.2. Docker nginx de aulas.inf.uva.es Para hacer el honeypot de aulas.inf.uva.es sobre un Docker necesitamos la estructura y el código de la web para replicar la web sobre el Docker. Para obtener estos recursos, utilizamos HTTrack Website Copier que sirve para la captura del código público de sitios web. Descargamos el programa, creamos un nuevo proyecto y añadimos la url de la página que queremos que nos descargue todo su contenido, en este caso "http://aulas.inf.uva.es". Página 31 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 $ systemctl enable elasticsearch $ systemctl start elasticsearch $ systemctl status elasticsearch   Figura 33: Status del servicio Elasticsearch Una vez instalado el Elasticsearch, instalamos el Kibana:   $ apt install kibana   El archivo de configuración principal de Kibana se encuentra en /etc/kibana/kibana.yml. Configuramos la dirección IP (server.port: "0.0.0.0") y el puerto (server.port: 5601) para acceder al Kibana. Además cambiaremos la configuración de como se conecta Kibana a Elasticsearch con elasticsearch.hosts: ["http:127.0.0.1:9200"]. Se puede implementar una autenticación básica para acceder al Kibana mediante elasticsearch.username: “user” yelasticsearch.password: “pass”. En este caso, se decidió no utilizar credenciales. Igual que hicimos con el Elasticsearch, iniciamos el servicio de Kibana y vemos su estado:   $ systemctl enable kibana $ systemctl start kibana $ systemctl status kibana   Figura 34: Status del servicio Kibana Ahora se puede acceder al Kibana desde el PC Host (http://192.168.1.45:5601) Página 38 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 35: Página inicial Kibana Por último, instalaremos el servicio Logstash:   $ apt install logstash   De momento no configuraremos ninguna entrada, filtro o salida del Logstash, por lo que iniciamos el servicio y revisamos su estado:   $ systemctl enable logstash $ systemctl start logstash $ systemctl status logstash   Figura 36: Status del servicio Logstash Dada la configuración del Stack ELK, se han dejado abiertos los puertos 5601 (Kibana), 9200 (Elasticsearch) y 9300 (Java) accesibles desde la red del Kali Linux. Por lo tanto, creamos unas reglas con IPtables para bloquear cualquier petición dirigida a esos puertos desde esa red. Además de bloquear estas peticiones, especificamos que nos genere un evento por cada petición en los logs del sistema para que más tarde lo visualicemos desde Kibana. Página 39 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021   $ iptables −A INPUT −i ens37 −p tcp −−destination−port 5601 −j LOG −− log−prefix ’Access Port Blocked (5601) ’ $ iptables −A INPUT −i ens37 −p tcp −−destination−port 5601 −j DROP $ iptables −A INPUT −i ens37 −p tcp −−destination−port 9200 −j LOG −− log−prefix ’Access Port Blocked (9200) ’ $ iptables −A INPUT −i ens37 −p tcp −−destination−port 9200 −j DROP $ iptables −A INPUT −i ens37 −p tcp −−destination−port 9300 −j LOG −− log−prefix ’Access Port Blocked (9300) ’ $ iptables −A INPUT −i ens37 −p tcp −−destination−port 9300 −j DROP   5.7. Instalación de Filebeat Como ya se explicó, ELK puede usar Beats para enviar datos de varias fuentes y presentárselos a Logstash o Elasticsearch. Instalamos el paquete Filebeat:   $ apt install filebeat   El archivo de configuración predeterminado se encuentra en /etc/filebeat/filebeat.yml. Si queremos que los datos que envíe Filebeat vayan directos al Elasticsearch, no debemos modificar el fichero. En cambio, si queremos que Filebeat envíe sus datos al Logstash para que los procese, debemos descomentar las líneas output.logstash: yhosts: ["127.0.0.1:5044"], y comentar las líneas output.elasticsearch: yhosts: ["127.0.0.1:9200"]. En nuestro caso, el flujo será Filebeat →Elasticsearch por lo que nos quedamos con las líneas del output.elasticsearch. Iniciamos el servicio Filebeat y listamos los módulos que se pueden activar:   $ systemctl start filebeat $ filebeat modules list   El primer módulo que usaremos será el Suricata, por lo que para activarlo ejecutamos el siguiente comando:   $ filebeat modules enable suricata   Página 40 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 37: Lista de módulos Filebeat (Enabled/Disabled) Desde /etc/filebeat/modules.d/suricata.yml, configuramos el módulo Suricata para que sepa qué logs de Suricata enviar. Los logs que revisaremos son eve.json, http.log y fast.log, pero si se necesitan más logs se añaden a este fichero. Desde Kibana, tenemos que crear un patrón para los índices (index pattern) para que Kibana sepa qué datos debe procesar. Para definir el primero accedemos a Management →Stack Management →Index Patterns →Create index pattern y escribimos una expresión regular que seleccione todas las fuentes relacionadas con Filebeat como "filebeat*". Figura 38: Index pattern Filebeat* Con esto ya tendríamos creado el index pattern. Si generamos algo de tráfico desde el Kali Linux, y accedemos al discover "filebeat*"de Kibana, podremos ver lo siguiente: Página 41 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 39: Eventos Suricata visualizados en el Kibana Con esta configuración, podremos ver los eventos que genera el Suricata y filtrarlos, por ejemplo, por la IP de origen o destino, la petición HTTP, el User-Agent, el sistema operativo y versión del origen, etc... Filebeat tiene dashboards por defecto que se pueden cargar en Kibana si tenemos activada la opción setup.kibana en el fichero de configuración filebeat.yml. Para cargar los dashboard ejecutamos el siguiente comando y ya podemos visualizarlos desde Kibana:   $ filebeat setup −−dashboards   Figura 40: Dashboards predeterminados de Filebeat para Kibana Página 42 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 41: Dashboard Suricata Events Los dashboards predeterminados son sencillos y cómodos, pero si necesitamos crear uno más personalizado para explorar o analizar mejor los eventos, desde el editor de dashboard se pueden crear de manera muy sencilla. 5.8. Creación de Dashboard Kibana para Logs de Suricata Como se ha explicado antes, Kibana puede formar gráficos o tablas a partir de estos datos para perfeccionar la búsqueda. El conjunto de estos gráficos se llama ”dashboard”. Desde Kibana se pueden hacer dashboard tanto sencillos o complejos. En este proyecto, vamos a realizar un dashboard con los campos más útiles del Suricata. [key24] Accedemos a la página Dashboard →Create dashboard y nos encontraremos un editor donde podemos ir añadiendo paneles, gráficas y tablas pulsando ’Create panel’ →’Lens’. Figura 42: Creador de panel Una vez en el editor del panel, se seleccionará un campo y el gráfico con el que vamos a trabajar, por Página 43 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 ejemplo, un gráfico de barras verticales con el campo @timestamp. Guardamos este panel en la esquina de arriba a la derecha y volvemos al editor del dashboard: Figura 43: Gráfico de barras verticales de campo @timestamp Ahora podemos cambiar el nombre al panel, maximizarlo, posicionarlo donde nosotros queramos dentro del dashboard. Para completar más el dashboard de Suricata añadimos unos gráficos sobre los campos: suricata.eve.src_ip, suricata.eve.dest_ip, http.request.method, http.response.status_code, file.path y un panel con los eventos tal cual está en la pestaña Discover. Figura 44: Dashboard Suricata parte 1 Figura 45: Dashboard Suricata parte 2 Página 44 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Con este dashboard podremos filtrar y precisar la búsqueda de los datos. 5.9. Recolección de diferentes logs con Filebeat Ahora mismo nuestro recolector solo recoge los eventos de Suricata. Es importante en sistemas como Honeynet y SIEM recoger todos los eventos que puedan ocurrir ya que, si no recolectamos algún tipo de evento, los atacantes pueden usar ese sistema que no estamos controlando como vector de ataque y no nos hayamos dado cuenta de ello. Los eventos que nos faltan por visualizar son: Eventos del sistema de HoneyWall. Eventos del sistema de HoneyDocker. Tráfico de red para complementar eventos que no capture Suricata. Eventos de los contenedores Docker: aulas.inf.uva.es y jair.lab.inf.uva.es Es necesario tener instalado y configurado Filebeat en el HoneyDocker para que éste pueda enviar sus logs al HoneyWall. Se instala el paquete Filebeat y se configura en el fichero principal la salida hacia el Elasticsearch del HoneyWall como hosts: ["10.10.1.1:9200"]. Por último, reiniciamos el servicio Filebeat. 5.9.1. Eventos del sistema Para los eventos del sistema HoneyWall y HoneyDocker utilizaremos el módulo de Filebeat System que será el encargado de recolectar y parsear los logs creados por el servicio de registros del sistema Unix/Linux. Cuando se ejecuta el módulo, realiza algunas tareas por debajo como establecer las rutas predeterminadas a los archivos de registros como auth.log, syslog, etcéra, y asegurar de que cada evento de registro de varias líneas se envíe como un solo evento. Utiliza el nodo de ingesta para analizar y procesar las líneas de registro para luego formar una estructura adecuada y visualizarlo en Kibana. Para activar el módulo usamos el siguiente comando:   $ filebeat modules enable system   Por defecto, el módulo System envía todos los logs que se encuentren en la ruta /var/log/ y tengan la extensión *.log. Por lo tanto, algunos ficheros que registra son [key25]: auth.log: Proporciona un registro de todas las actividades que implican un proceso de autenticación. Por ejemplo registro de usuarios logeados con su día, hora, usuario y órdenes que se han ejecutado con el comando sudo. syslog: Contiene la totalidad de logs capturados por rsyslogd. Este log es muy difícil de consultar y filtrar por su extenso tamaño, por eso se distribuye en otros ficheros siguiendo la configuración del fichero /etc/rsyslog.conf. messages: Contiene mensajes informativos y no críticos de la actividad del sistema operativo. Errores que se registran en el arranque del sistema no relacionados con el Kernel. kern.log: Proporciona información detallada de mensajes del kernel como mensajes de error y advertencias al compilar el kernel o detectar problemas del hardware. Página 45 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Para no visualizar demasiados eventos o ruido en el Kibana, desde el fichero de configuración del módulo System (/etc/filebeat/modules.d/system.yml) solo seleccionaremos los ficheros imprescindibles para este proyecto: /var/log/auth.log, /var/log/messages, /var/log/kern.log, /var/log/faillog y /var/log/lastlog en HoneyWall y en HoneyDocker Las reglas de IPtables que hayamos definido para que nos generen un evento de log, se registrarán tanto en los logs messages como kern.log de la siguiente forma: Figura 46: Logs IPtables visualizados en kern.log En el Kibana podemos visualizar estos eventos estructurados en los diferentes campos para poderlos filtrar más fácilmente según su fecha, IP origen, de qué fichero procede ese evento, etcétera. Figura 47: Ejemplo de bloqueo de peticiones por IPtables en Kibana Figura 48: Ejemplo de sesión iniciada y cerrada por el usuario root en Kibana Figura 49: Ejemplo de inicio sesión fallido en Kibana 5.9.2. Tráfico de red Packetbeat Una buena práctica para los sistemas SIEM, o Honeynet como es en este caso, es recolectar el tráfico de red desde más de una fuente. En nuestro ejemplo, si Suricata ha devuelto un error o directamente no ha capturado cierto tráfico, estamos expuestos a que haya habido una fuga de información o que un equipo haya quedado comprometido sin percatarnos. Por lo tanto, es necesario instalar otra fuente de monitorización de tráfico de red. Página 46 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 El software complementario que instalaremos es Packetbeat [key26], que es un analizador de paquetes de red ligero que envía datos desde sus hosts a Logstash o Elasticsearch. Packetbeat es un tipo de Beat como Filebeat perteneciente a la empresa Elastic Stack. El proceso que sigue Packetbeat es capturar el tráfico de red, decodificar los protocolos de red, correlacionar las peticiones con sus respuestas, extraer los campos como el tiempo de respuesta, estado, etc.. y agrupar los JSON para enviárselos a Logstash o Elasticsearch. Con Packetbeat monitorizaremos la interfaz externa del HoneyWall (10.10.2.1). Como Filebeat y ELK requieren repositorios ya incluidos en Packetbeat, solo faltaría instalarlo y ponerlo en ejecución:   $ apt install packetbeat $ systemctl enable packetbeat $ systemctl start packetbeat   Configuramos el fichero predeterminado que se encuentra en /etc/packetbeat/packetbeat.yml. Definimos la interfaz que va a monitorizar con packetbeat.interfaces.device: ens37, añadimos el puerto 22 en la sección TLS ya que es tráfico cifrado, configuramos que la salida sea hacia Elasticsearch y, por último, descomentamos la sección setup.kibana para poder cargar los dashboards predeterminados de Packetbeat. Reiniciamos el servicio Packetbeat y cargamos los dashboards de Packetbeat:   $ packetbeat setup −−dashboards   Igual que con Filebeat, necesitamos crear un index pattern para que Kibana pueda procesar los datos del Packetbeat. Por lo tanto, lo creamos utilizando "packetbeat*" como expresión regular. Los eventos de Packetbeat los veremos desde "packetbeat*" para que no se junten con los del Suricata, que están en el "filebeat*", y no se refleje el tráfico dos veces a la hora de explorar. Solo se usará Packetbeat cuando en Suricata se hayan perdido eventos o no se llegue a apreciar suficientemente bien el comportamiento del ataque. Algunos ejemplos de eventos de Packetbeat: Figura 50: Ejemplo de petición HTTP GET contra aulas.inf.uva.es en Kibana Figura 51: Ejemplo de Ping ICMP contra jair.lab.inf.uva.es 5.9.3. Eventos de los contenedores Docker Para recoger los logs de los contenedores Docker [key27] hay dos maneras: la compleja, que sería r enviar desde el propio contenedor Docke los logs al Elasticsearch del HoneyWall; o la sencilla, que sería enviar el log que genera cada contenedor Docker en el HoneyDocker al Elasticsearch del HoneyWall. Para no complicar más el proyecto, se decidió utilizar la forma sencilla y enviar los logs que se encuentran en /var/lib/docker/containers/<container_id>/<container_id>-json.log. En este caso, serían dos logs: uno del Docker de aulas.inf.uva.es (httpd) y otro del Docker de jair.lab.inf.uva.es (cowrie/cowrie). Página 47 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Este ha sido el conteo de los códigos de error. Si filtramos por el código 200 (OK), que significa petición procesada exitosamente, veremos algunas peticiones exitosas como a recursos ’/rss’, ’/pluginfile.php/153/user/’, ’/libhtp::request_uri_not_seen’ y más. Aquí es donde entra el analista de ciberseguridad para ver el impacto del escaneo, replicando estas peticiones y siguiendo los mismos pasos que el atacante. Figura 65: Ejemplo de petición 200 OK desde Kibana Figura 66: Ejemplo de petición 404 Not Found desde Kibana 6.3. Fuerza bruta SSH contra Cowrie Se realizará un intento de fuerza bruta de SSH mediante hydra con un diccionario que contiene 900 posibles contraseñas, incluida la correcta. Las credenciales a intentar encontrar son "test/test", con el siguiente comando ejecutamos la fuerza bruta:   $ hydra −l test −P/usr/share/wordlists/dirb/small .txt ssh :// jair .lab . inf .uva .es −t4   Después de 10 minutos ejecutándose, el ataque finaliza encontrando la contraseña correcta del usuario test. Página 54 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 67: Bruteforce con hydra con el usuario test Con una media de 100 intentos por minutos con 4 tareas ejecutándose en paralelo, el volumen que genera en este ataque en el Kibana es de 4146 eventos. Como se puede observar, no es tan amplio como un escaneo de puertos. Esto se debe en mayor parte a que ha habido mas puertos escaneados que contraseñas intentadas pero también a que, cuando se realiza una ataque de fuerza bruta por SSH durante una sola conexión TCP establecida, se prueban hasta 4 contraseñas. Este proceso evita realizar varios handshake TCP que en un escaneo de puertos corriente no podría. Figura 68: Intento de logeo fallido con credenciales test/table Como se trata de una conexión SSH, el tráfico pasa cifrado, por lo que la única manera de saber el contenido del paquete es revisándolo con los logs del Docker Cowrie. Desde estos logs podemos ver cómo se han realizado intentos de inicio de sesión desde la IP 10.10.2.2 con las credenciales test/table o test/engine y han resultado fallidas. Página 55 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 69: Intento de logeo fallido con credenciales test/table Figura 70: Intento de logeo fallido con credenciales test/engine Si filtramos en Kibana con la palabra ’succeeded’ encontramos un evento de un intento de inicio de sesión exitoso con las credenciales test/test, por lo que podemos deducir que el ataque tiene las credenciales de ese usuario y, por lo tanto, acceso a la máquina Cowrie. Figura 71: Intento de logeo exitoso con credenciales test/test Página 56 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 6.4. Comandos Linux dentro del Docker Cowrie Como se ha mencionado anteriormente el tráfico SSH esta cifrado, por lo que vemos los comandos que se ejecutan desde los logs del Cowrie Docker. A continuación probamos a conectarnos con la cuenta de root al Docker Cowrie y ejecutamos un par de comandos: Figura 72: Ejecución de algunos comandos en una sesión SSH Si observamos los resultados obtenidos desde Kibana veremos el comando que ha ejecutado, aunque no el resultado devuelto por el comando. Una manera conocer el resultado es replicando los comandos contra el mismo sistema. Figura 73: Comando ’cat /etc/resolv.conf’ Figura 74: Comando ’pwd’ Página 57 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Figura 75: Comando ’ls -la /root’ Página 58 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 7. Conclusión y posibles mejoras a futuro 7.1. Conclusiones Durante el desarrollo del trabajo de fin de grado hemos aprendido sobre qué es una red Honeynet y su funcionamiento como su posterior utilización contra atacantes. Seguidamente, se enumeran los objetivos que se han conseguido durante el proyecto desarrollado: Se ha adquirido un conocimiento amplio sobre las redes Honeynet y su funcionamiento. Se ha implementado una Honeynet basada en servicios reales de la Universidad de Valladolid. Se ha desplegado un laboratorio para comprobar la funcionalidad de la Honeynet. Se ha desarrollado una Honeynet sobre un entorno seguro y virtualizado siguiendo un patrón de GEN III Virtual Híbrida. Se ha estudiado e implementado las diferentes tecnologías SIEM como pila ELK, Suricata e IPtables. Se ha desplegado un entorno escalable con la ayuda de la tecnología Docker. Se han simulado los diferentes vectores de ataque inicial que usaría un atacante. Se ha aprendido cómo trabaja un analista de ciberseguridad mediante la investigación de alertas. Querría remarcar uno de los objetivos principales propuestos al inicio de este proyecto que era adquirir los conocimientos de ciberseguridad que se podrían implementar en un CERT o SIEM como es el uso y despliegue de la pila ELK, la implementación de reglas Suricata o el uso de contenedores Docker para virtualizar; y puedo manifestar que he aprendido mucho sobre estos temas. A pesar de que en la carrera existen asignaturas como Administración de Sistemas Operativos, Gestión de la Seguridad de la Información y Redes que me han ayudado a que me resulte más sencillo el desarrollo del proyecto, he tenido que trabajar duro e investigar cada una de las tecnologías y componentes que se han utilizado para obtener este resultado final. Desde otra perspectiva, me gustaría indicar que, a pesar de que haya sido duro, he disfrutado desarrollando un proyecto relacionado con el campo de la ciberseguridad ya que es mi pasión y mi meta como trabajo. 7.2. Posibles mejoras a futuro Durante la investigación y desarrollo de este trabajo de fin de grado, se han recopilado posibles mejoras a futuro sobre la Honeynet que, debido al poco tiempo para finalizar el proyecto y el desconocimiento, no se han realizado. A continuación se nombran las posibles mejoras: Mejorar el nivel de interacción de los atacantes con los contenedores Docker: Actualmente en el proyecto tenemos dos contenedores Docker de baja interacción, uno basado en una web y otro en un sistema Linux SSH. Una mejora es añadir más interacción a los contenedores existenes como añadir una base de datos, sistema de credenciales o configurar un sistema más real que el Docker Cowrie. Además de esto, agregar más contenedores como un servidor de correo, FTP o un Windows AD. Separar la funcionalidad del HoneyWall: Otra mejora es separar la funcionalidad del HoneyWall. Por una parte crear otro sistema Host que sea el router con sus IPtables, port forwarding y que separe las redes; y por otra, que otro sistema se encargue de monitorizar toda la red dentro de la propia LAN. Con esto ganamos menos carga sobre un equipo y más seguridad ya que, en caso de que se infecté el equipo HoneyWall no podrá acceder a los logs que están almacenados en él. Además se podría configurar una interfaz bridge en el ’nuevo’ firewall. Página 59 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Mejora del parseo en los logs: En este proyecto, no se ha dado mucha importancia a cómo llegaban estructurados los logs al Elasticsearch. Es por esto que una mejora podría ser mejorar el parseo mediante Logstash y grok. Añadir más medidas preventivas: Actualmente en nuestro proyecto se han desplegado 2 tecnologías de seguridad preventiva: IPtables y IPS Suricata. Únicamente estamos utilizando la parte de prevención en IPtables para que bloquee los puertos descritos en iptablesUp.sh. Una mejora sería que para ataques conocidos, que no nos interese registrar o que generen mucha carga de tráfico a la Honeynet, sean bloqueados por el IPS Suricata. Implementación del proyecto en un entorno real: Una de las principales idea del proyecto es poder implementar esta Honeynet en un entorno real y, más en concreto, en la red de la Universidad de Valladolid. Página 60 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 - Anexos - Página 61 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 8. ANEXO 8.1. Configuración de red   1source /etc/network/interfaces .d/∗ 2 3#The loopback network interface 4auto lo 5iface lo inet loopback 6 7#Interface para acceder a Internet 8auto ens33 9iface ens33 inet static 10 address 192.168.1.45 11 netmask 255.255.255.0 12 network 192.168.1.0 13 broadcast 192.168.1.255 14 gateway 192.168.1.1 15 16 #Interface WAN con Kali 17 auto ens37 18 iface ens37 inet static 19 address 10.10.2.1 20 netmask 255.255.255.0 21 network 10.10.2.0 22 broadcast 10.10.2.255 23 24 #Interface LAN con HoneyDocker 25 auto ens38 26 iface ens38 inet static 27 address 10.10.1.1 28 netmask 255.255.255.0 29 network 10.10.1.0 30 broadcast 10.10.1.255   Listing 1: /etc/network/interfaces de HoneyWall   1source /etc/network/interfaces .d/∗ 2 3#The loopback network interface 4auto lo 5iface lo inet loopback 6 7#Interface LAN con HoneyDocker 8auto ens34 9iface ens34 inet static 10 address 10.10.1.2 11 netmask 255.255.255.0 Página 62 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 12 network 10.10.1.0 13 broadcast 10.10.1.255 14 gateway 10.10.1.1   Listing 2: /etc/network/interfaces de HoneyDocker   1source /etc/network/interfaces .d/∗ 2 3#The loopback network interface 4auto lo 5iface lo inet loopback 6 7#Interface para acceder a Internet 8auto eth1 9iface eth1 inet static 10 address 192.168.1.55 11 netmask 255.255.255.0 12 network 192.168.1.0 13 broadcast 192.168.1.255 14 gateway 192.168.1.1 15 16 #Interface WAN con HoneyWall 17 auto eth0 18 iface eth0 inet static 19 address 10.10.2.2 20 netmask 255.255.255.0 21 network 10.10.2.0 22 broadcast 10.10.2.255   Listing 3: /etc/network/interfaces de Kali Linux 8.2. Configuración DNS del HoneyWall   1options { 2directory "/var/cache/bind " ; 3 4forwarders { 58 . 8 . 8 . 8 ; 68 . 8 . 4 . 4 ; 7}; 8 9dnssec−validation auto ; 10 listen−on−v6 {any }; 11 };   Listing 4: /etc/bind/named.conf.options   Página 63 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 6enabled:true 7 8# S et c u s t o m p a t h s f or th e log f i l e s . If l e ft em pty , 9# F i l e b e a t w il l c h o o se the p at hs d e p e n d i n g on yo ur OS . 10 var .p a t h s :[" / var / log / s u r i c a t a / eve . j s on " ," / var / log / s u r i c a t a / h t tp . log " ," / var / log / s u r i c a t a / f ast . log " ]   Listing 14: Módulo Filebeat suricata.yml   1# M o d u l e : s y s t e m 2 3−m o d u l e :syst e m 4# S y s l o g 5s y s l o g : 6enabled:true 7 8# S et c u s t o m p a t h s f or th e log f i l e s . If l e ft em pty , 9# F i l e b e a t w il l c h o o se the p at hs d e p e n d i n g on yo ur OS . 10 var .p a t h s :[" / var / log / l a s t l o g " ," / var / log / ke r n . log " ," / var / log / m e s s a g e s " ," / v ar / log / f a i l l o g " ] 11 12 # Authorization logs 13 auth: 14 enabled:true 15 16 # S et c u s t o m p a t h s f or th e log f i l e s . If l e ft em pty , 17 # F i l e b e a t w il l c h o o se the p at hs d e p e n d i n g on yo ur OS . 18 var .p a t h s :[" / var / log / a u th . log " ]   Listing 15: Módulo Filebeat system.yml 8.7. Configuración Packetbeat   1# = = = = = = = = = = = = = = = = = = = = N et w o r k d e v i ce = = = = = = = = = = = = = = = = = = = = = 2 3packetbeat .interfaces .d e v i c e :ens37 4 5# = = = = = = = = = = = = = = = = = = = = T r a n sa c t i on p r o t o co l s = = = = = = = = = = = = = = 6 7packetbeat .p r o t o c o l s : 8... 9−type:t l s 10 11 p o r t s : 12 -22 # SSH 13 -443 # H T T P S 14 -993 # I M A P S 15 -995 # P O P 3 S 16 -5223 # XM P P o v er SSL Página 70 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 17 -8443 18 -8883 # S e c u r e M Q TT 19 -9243 # Elasticsearch 20 ... 21 # ==================== Kibana ===================== 22 ... 23 24 s e t u p .k i b a n a : 25 host:" l o c a l h o s t : 5 60 1 " 26 ... 27 # = = = = = = = = = = = = = = = = = = = = E l a s t i c s e a r c h O u tp ut = = = = = = = = = = = = = = = = = = = 28 ... 29 o u t p u t .elasticsearch: 30 h o s t s :[" l o c a l h o s t : 9 20 0 " ] 31 ... 32 # ==================== Logstash Output ==================== 33 ... 34 # o u t pu t . l o g s t a s h : 35 # h o st s : [ " 1 2 7 . 0 . 0 . 1 : 5 0 4 4 " ] 36 ...   Listing 16: packetbeat.yml Página 71 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 Bibliografía [1] Antonio Salvador. Estadística de ciberataques 2020. 2021. url:https://www.elindependiente.com/ espana/2021/01/01/2020-ano-record-en-ciberataques/. [2] Adnan Rahić. Logs en Docker. 2020. url:https://sematext.com/blog/docker-logs-location/. [3] Antonio Ramos Varón y col. Seguridad perimetral, monitorización y ataques en redes. 2014. [4] Brian Hogan. How To Install and Use Docker on Debian 10. 2019. url:https://www.digitalocean. com/community/tutorials/how-to-install-and-use-docker-on-debian-10. [5] Conjunto de reglas Suricata Emerging Threats. 2021. url:https://rules.emergingthreats.net/ open/suricata/rules/. [6] Carlos Álvarez Martín y Pablo González Pérez. Hardening de servidores GNU/Linux. 2017. [7] Carlos Carretero Aguilar. Despliegue de una honeynet en la red de la diputación de Cádiz para la investigación de ataques informáticos. 2018. [8] Darkcrizt. Suricata 4.0 supervisa el tráfico de la red. 2017. url:https://ubunlog.com/suricata-4- 0-supervisa-el-trafico-de-la-red/. [9] Docker. Docker Oficial. 2013. url:https://docs.docker.com/. [10] Erik Czumadewski. Desventajas de Docker. 2019. url:https://es.quora.com/Cu%C3%A1les-son- las-desventajas-de-usar-Docker. [11] Elastic. Packetbeat Documentation.url:https://www.elastic.co/es/beats/packetbeat. [12] Eduardo Malo. Los ciberataques son ya la segunda mayor preocupación entre los CEOs españoles. 2020. url:https://www.muycanal.com/2020/02/06/ciberataques-preocupacion-espana/. [13] Emiliano. IPtables tutorial básico. 2016. url:https : / / www . linuxito . com / seguridad / 793 - tutorial-basico-de-iptables-en-linux. [14] Funcionamiento Cowrie. 2018. url:https://hackertarget.com/cowrie-honeypot-ubuntu/. [15] Federación de Enseñanza de CC.OO. de Andalucía. “HoneyNets, una desconocida en la seguridad informática”. En: (2009). [16] Gobierno de España. Información sobre RedIRIS Corporativa. 2020. url:https://www.rediris.es/ rediris/mm/RedIRIS_corporativa_2020.es.pdf. [17] Hartek. Suricata IDS jugando con las reglas. 2018. url:https://ubunlog.com/suricata- 4- 0- supervisa-el-trafico-de-la-red/. [18] Hartek. IDS IPS Suricata entendiendo y configurando. 2018. url:https://fwhibbit.es/suricataids-jugando-con-las-reglas. [19] itamarst. Cheat Sheets Docker.url:https://github.com/OWASP/CheatSheetSeries/blob/master/ cheatsheets/Docker_Security_Cheat_Sheet.md. [20] Instalación y configuración de Suricata. 2021. url:https : / / blog . elhacker . net / 2021 / 03 / suricata-ids-ips-instalacion-configuracion-reglas-.html. [21] jasonish. suricata-update GitHub.url:https://github.com/OISF/suricata-update. [22] Joan Carles. Logs en Linux. 2019. url:https://geekland.eu/logs-en-linux/. [23] caffix. Github Amass.url:https://github.com/OWASP/Amass. [24] Lourdes Peñalver Herrero. ELK para el análisis de logs - TFG - Escuela Politécnica de Valencia. 2020. url:https://riunet.upv.es/bitstream/handle/10251/156901/Simarro%20-%20ELK%20para% 20el%20an%C3%A1lisis%20de%20logs.pdf?sequence=1%5C&isAllowed=y. Página 72 TFG - HoneyNet - Escuela de Ingeniería Informática 2020/2021 [25] Lorna Chepkoech. Instalación ELK en Debian 10. 2021. url:https://techviewleo.com/installelastic-stack-7-elk-on-debian/. [26] micheloosterhof. Cowrie Honeypot Github. 2020. url:https://github.com/cowrie/cowrie. [27] nmap. NMAP Página Oficial.url:https://nmap.org/. [28] OpenVAS. OpenVAS Documentación.url:https://www.openvas.org/. [29] Red Hat. ¿Qué es Docker? 2013. url:https://www.redhat.com/es/topics/containers/what-is- docker. [30] Sergio Losada. ¿Qué es ELK? 2018. url:https : / / openwebinars . net / blog / que - es - elk - elasticsearch-logstash-y-kibana/. [31] Scayle. Información sobre la Red CAYLE.url:https://www.scayle.es/redcayle/infraestructura/. [32] Tutorial Kibana: Creación de index pattern y dashboard. 2019. url:https : / / www . ionos . es / digitalguide/online-marketing/analisis-web/tutorial-de-kibana/. [33] Victor García. Monitorización de aplicaciones usando ELK Stack. 2019. url:https://enimbos.com/ monitorizacion-de-aplicaciones-usando-elk-stack/. Página 73