Despliegue de una HoneyNet en la red de la Diputación de Cádiz para la investigación de ataques informáticos

Posted on 203 visualizaciones 0 comentarios

Descripción corta:

Diseñar y desplegar una red honeynet virtual que sirva como punto de detección y análisis de ataques informáticos en la frontera de la red de la Diputación de Cádiz.

Fecha de elaboración del texto:

Texto elaborado para la candidatura al Premio mejor Iniciativa de Innovación. CNIS 2019.

Autores:

  • Carlos Carretero Aguilar, Alumno del Máster de CIberseguridad de la Universidad de Cádiz.
  • Manuel Añón Rodríguez, Coordinador del Departamento de Redes de EPICSA.
  • Antonio Galán Obregón, Jefe Adjunto del Área de Sistemas, Redes, Explotación y CAU. EPICSA.
  • Antonio García Vázquez, Gerente de EPICSA

Administración / Proveedor que lo propone: Diputación de Cádiz.

Área responsable del proyecto: Empresa Provincial de Información S.A. (en adelante EPICSA), Área de Coordinación Política.

Estado del Proyecto / Caso en la fecha del alta:  Implantado.

Carácter innovador:

Con este proyecto se añade un elemento más en la seguridad de la red provincial dando un paso más en materia de Ciberseguridad y el cumplimiento del Esquema Nacional de Seguridad usando estándares y tecnologías de fuentes abiertas, continuando así la línea de colaboración con la Universidad de Cádiz con el “Sistema de monitorización de eventos de la red provincial”, galardonado con el primer premio en la categoría de Seguridad del CNIS 2018.

Problemática:

La importancia de la detección y análisis de ataques informáticos en el mundo moderno está fuera de toda duda. Hoy en día, la gran interconexión de las grandes organizaciones y el acceso de la población a Internet provocan un gran tráfico de información cada segundo. Según el Centro Criptográfico Nacional, en el año 2016, se registraron 3.675.824.813 usuarios activos en Internet, lo que supone la mitad de la población mundial actual.

Toda esta información es susceptible de ser atacada, de hecho, hoy en día, el número de ataques informáticos que se producen aumentan a un ritmo vertiginoso., los ataques informáticos suponen actualmente una amenaza mundial del mismo nivel que el desempleo o las crisis económicas.

Solución planteada:

El objetivo de este proyecto ha sido diseñar y desplegar una red honeynet virtual que sirva como punto de detección y análisis de ataques informáticos en la frontera de la red de la Diputación de Cádiz.

Dicha honeynet se constituye un conjunto de equipos intencionadamente vulnerables interconectados entre sí. La honeynet debe proveer de mecanismos de detección de ataques, de las herramientas necesarias para el control de los equipos vulnerables, así como de un sistema de visualización de todos los datos recogidos por la honeynet.

La red honeynet debe proveer de la posibilidad de desplegar todos los sistemas y procesos vulnerables necesarios dentro de una misma máquina física, de tal manera que se optimice al máximo la facilidad de despliegue, de mantenimiento y de portabilidad.

Detalles de la solución:

OBJETIVOS:

Los objetivos del proyecto de despliegue de una honeynet virtual para la detección y el estudio de ataques informáticos son los siguientes:

  • R-01: Desplegar una honeynet que no sobrecargue la infraestructura existente. La arquitectura de la honeynet desplegada no debe sobrecargar la infraestructura de red en producción.
  • R-02: Desplegar una honeynet escalable. La arquitectura de la honeynet debe permitir la rápida y fácil escalabilidad de los servicios desplegados.
  • R-03: Implementar control y limitación de conexiones. La honeynet debe controlar y limitar todas las sesiones establecidas con honeypots de la red vulnerable.
  • R-04: Implementar prevención de intrusiones en red. La honeynet debe ser capaz de alertar y bloquear ante la detección de tráfico de red sospechoso.
  • R-05: Implementar detección de intrusiones en honeypots. La honeynet debe ser capaz de alertar ante la detección de software malicioso en los honeypots.
  • R-06: Implementar control de integridad en honeypots. La honeynet debe ser capaz de alertar ante el cambio de ficheros o software existentes en el sistema, así como la aparición de nuevos ficheros o software.
  • R-07: Implementar registro de inicios de sesión. La honeynet debe capturar todos los registros de inicio de sesión en los diferentes honeypots.
  • R-08: Implementar registro de comandos. La honeynet debe capturar todos los registros de comandos emitidos en los diferentes honeypots.
  • R-09: Implementar captura de tráfico. La honeynet debe capturar todo el tráfico que la atraviese
  • R-10: Recoger estadísticas de uso y sesiones de la red. La honeynet debe generar estadísticas de uso de la red con información de las diferentes sesiones establecidas.
  • R-11: Recoger estadísticas de uso de recursos de la honeynet. La honeynet debe generar estadísticas de uso de los recursos de los honeypots y el honeywall.
  • R-12: Implementar cifrado en la colección de datos. Todo intercambio de información entre el honeywall y los honeypots debe ser a través de canales cifrados.
  • R-13: Implementar un sistema de análisis de información. La honeynet debe provisionar de un sistema de análisis de información residente en el honeywall.
  • R-14: Configurar una conexión cifrada con el honeywall. Toda conexión que se establezca con el honeywall ya sea para análisis de datos o administración de la honeynet, debe ser cifrada.

Alcance

Este proyecto se aplica al diseño y despliegue de una honeynet virtual para la detección y análisis de ataques informáticos en un entorno de investigación.

Este proyecto incluye:

  • Especificación de requisitos de la honeynet virtual
  • Introducción teórica a los ataques informáticos
  • Estudio teórico de los honeypots.
  • Establecimiento de mediciones de recursos para la consecución del proyecto.
  • Elaboración de un presupuesto para la consecución del proyecto.
  • Estudio de alternativas y viabilidad de las diferentes alternativas hardware y software para la realización del proyecto.
  • Descripción de las soluciones adoptadas.
  • Anexo de información sobre la configuración del software utilizado.

Estudio de alternativas y viabilidad

En este apartado se estudiarán las posibles alternativas a considerar en la consecución de este proyecto. Las siguientes alternativas se desarrollarán en los apartados sucesivos.

Arquitectura de la honeynet

La red interna de la Diputación de Cádiz, administrada por EPICSA, es una red extensa, compleja y muy heterogénea, desde el núcleo de la red, hasta la zona frontera de la misma con toda la interconexión a internet, sedes remotas y teletrabajadores de la Diputación de Cádiz.

Un despliegue de una honeynet de tercera generación queda descartado para el presente proyecto debido a que la red es tan compleja, que la investigación que supone la integración de servicios vulnerables, así como protección de los sistemas colindantes, sería de tal magnitud que se aleja del alcance del proyecto en cuestión. Por ello, se opta por implantar una honeynet separada física y lógicamente de la red interna en producción de la Diputación de Cádiz.

Una honeynet de primera generación supondría configurar todo el control, captura, colección y análisis de datos en los cortafuegos frontera ya desplegados en la red de la Diputación de Cádiz. Esta tarea puede suponer un gran reto a la hora de que dicha configuración no suponga ningún tipo de interferencia con el desempeño diario de la red interna de la Diputación de Cádiz, ya que, sin la honeynet, los cortafuegos de la frontera de la red ya soportan una gran carga de trabajo con los accesos a la red DMZ y con el control de accesos a las redes internas.

Por ello, para cumplir con el requisito R-01: se va a desplegar una honeynet de segunda generación, donde todas las tareas de control, captura, colección y análisis de datos recaigan en el honeywall, liberando así a los cortafuegos de la frontera de toda la posible carga de trabajo que supondría la implementación de toda la gestión de datos de la honeynet. El diagrama de la red frontera de la Diputación de Cádiz, tras la integración de la honeynet sería el siguiente:

Despliegue de la honeynet

Para reducir al máximo posible los costes de despliegue de la honeynet mientras que se aprovecha al máximo las capacidades de los softwares actuales de virtualización disponibles, la honeynet se va a desplegar en la red de la Diputación de Cádiz mediante soluciones virtualizadas.

En concreto, una honeynet virtualizada independiente supondría la adquisición de hardware de altas prestaciones al tener que implementar todos los procesos de la honeynet en la misma máquina y, aunque la haría más portable, no es conveniente que la honeynet depende de un único punto de fallo en el hardware sobre el que se fuera a desplegar. Además, los ataques que pudieran sufrir los servicios vulnerables en máquinas virtuales podrían tener interferencias con el desempeño del honeywall, impidiendo el control, la captura, la colección y el análisis de datos.

Por ello, para cumplir con el requisito R-02: Desplegar una honeynet escalable. de este proyecto, se va a desplegar una honeynet virtualizada híbrida donde se configuran dos servidores, uno para el honeywall, y otro para los honeypots virtualizados. Así subsanamos algunas desventajas introducidas anteriormente. Por una parte, estamos reduciendo los requerimientos hardware de los servidores al repartir la carga de trabajo
entre ellos. También eliminamos el único punto de fallo de la honeynet, permitiendo que un ataque en uno de los honeypots no tenga influencia directa en el honeywall, permitiendo así todos los procesos de control, captura, colección y análisis de datos. De igual modo, al desplegar los honeypots de manera virtualizada, se aumenta al máximo la rapidez en el despliegue de nuevos servicios vulnerables.

Con tal consideración, el diagrama de red de la red frontera de la Diputación de Cádiz con una honeynet de segunda generación introducido en el apartado anterior se ve actualizado para introducir una honeynet virtual híbrida.

El acceso público a la honeynet se establece a través del caudal contratado con Telefónica para datos y aplicaciones, así como para el acceso público a la DMZ de la red de la Diputación de Cádiz. El acceso de administración a la honeynet se realiza a través de una línea exclusiva ADSL de 12 Mb/s contratada con el ISP Telefónica.

Limitación de conexiones

Para el cumplimiento del requisito R-03: Implementar control y limitación de conexiones, se configura IPTables para que limite las conexiones entrantes en el puente de red a 50 paquetes por segundo, de tal manera, serán descartadas aquellas conexiones que superen dicho número de paquetes por segundo. Cada segundo se reinicia el contador de paquetes por segundo, por lo que las conexiones no se bloquean permanentemente, sino que se limitan, por lo que un atacante no pierde la conexión con la honeynet, sino que se limita su capacidad de llevar a cabo acciones que supongan una alta carga de tráfico.

El esquema lógico de configuración de IPTables con limitación de tráfico sobre el puente de red sería el siguiente.

Figura 11 Funcionamiento de IPTables sobre el puente de red

La aplicación del control de conexiones se aplica tanto para conexiones iniciadas desde el exterior como para conexiones iniciadas por alguno de los honeypots o incluso el servidor de virtualización.

Prevención de intrusiones en red

Focalizando el análisis de soluciones en la instalación de un IPS en la honeynet, para el cumplimiento del requisito R-04: Implementar prevención de intrusiones en red, al encontrarnos en una honeynet de segunda generación se debe tener en cuenta que el IPS se deberá desplegar en el honeywall por lo que ahora se debe decidir que software escoger entre todas las alternativas introducidas con anterioridad. Debido a la continua apuesta de la Diputación de Cádiz por el código abierto, se descarta cualquier opción privativa.

Dicho esto, entre Snort y Suricata, las dos soluciones IPS de código abierto más conocidas, se opta por Suricata por las siguientes razones:

  • Soporte de ejecución multihilo, lo que conlleva mejor rendimiento.
  • Exportación de datos en formato JSON, lo que facilita la integración de dichos datos con los mecanismos de recolección de datos de la honeynet.

A la hora de configurar Suricata para su desempeño como IPS en una honeynet sobre un puente red, se deben tener en cuenta las siguientes consideraciones.

  • En su modo IPS, Suricata utiliza un sistema de colas de paquetes denominado NFQ. Un sistema Linux puede decidir enviar los paquetes de red mediante IPTables a diferentes colas NFQ para que sean procesados por otro software diferente del usuario. Suricata es capaz de escuchar en diferentes colas NFQ y decidir si el tráfico puede continuar su camino o ser cortado.
  • Se debe habilitar la actualización automática de reglas para que esta recojan la información del tráfico de red malicioso más actualizada posible, de tal manera que el tráfico que atraviese la red sea, o no malicioso, o de nuevas amenazas sin descubrir. Para este proyecto, se descargaron las reglas de EmergingThreats mediante el software Oinkmaster.
  • Las reglas de EmergingThreats, por defecto, solo alertan del tráfico no malicioso en vez de bloquearlo. Para cambiar este comportamiento al deseado, se deben modificar las reglas cada vez que se actualicen, para ello, se utilizará también el software Oinkmaster.

La modificación de reglas para cambiar su comportamiento consiste en sustituir el campo de acción que determina que debe hacer Suricata si el tráfico analizado coincide con lo establecido en la regla. Si el campo está establecido en alert, Suricata alerta y deja pasar el tráfico, por el contrario, si el campo está establecido en drop, Suricata alerta y bloquea el tráfico, por lo tanto, todas las reglas que contengan el campo alert y se desea que bloqueen el tráfico, se debe cambiar por drop. Pero no se pueden cambiar todas las reglas, debidos a que existe una clasificación de las reglas en tres niveles de peligro: alto, medio y bajo.

Si se bloquea el tráfico que es identificado por reglas de categoría baja, se corre el riesgo de bloquear tráfico legítimo. Por lo tanto, se decide modificar las reglas de nivel medio y alto. Para ello, se configurará Oinkmaster para que cambie la acción de todas aquellas reglas de nivel medio y alto, salvo las de violación de políticas (policy-violation, tipo Alto), que deben ser especificadas por la organización en cuestión.

Una vez desplegado Suricata en el honeywall, el diagrama de control de datos del honeywall es el siguiente:

La aplicación de reglas de Suricata en modo IPS al tráfico de red se realiza para el tráfico del puente de red en ambos sentidos, Internet hacia honeypots y viceversa.

Detección de intrusiones en honeypots

Para el cumplimiento de los requisitos R-05: Implementar detección de intrusiones en honeypots, R-06: Implementar control de integridad en honeypots y R-07: Implementar registro de inicios de sesión, se configurará la infraestructura de HIDS del software OSSEC en modo cliente/servidor, siendo el servidor el honeywall y los clientes los diferentes honeypots que se instalen en la honeynet. Las clientes OSSEC de
los honeypots enviarán al servidor los datos cifrados de los logs monitorizados y el servidor, juzgará los eventos según un conjunto de reglas para decidir si alertar o no ante dicho evento recibido. El funcionamiento esquemático es el siguiente:

Figura 13 Arquitectura de HIDS OSSEC cliente/servidor

Los datos que se almacenan ante una alerta del servidor generada por el envío de un evento sospechoso de un honeypot son principalmente:

  • Regla que genera la alerta.
  • IP origen de la actividad sospechosa (si procede).
  • Usuario involucrado (si procede).
  • Origen del evento que genera la alerta (honeypot + fichero local).
  • Log completo del evento.

Análisis de datos

Para el cumplimiento del requisito R-13: Implementar un sistema de análisis de información de este proyecto se debe configurar en el honeywall las herramientas necesarias para el análisis de todos los datos almacenados en Elasticsearch gracias a todos los mecanismos de control, captura y colección de datos ya especificados en apartados anteriores.

Para este proyecto, se va a optar por la configuración de la herramienta Kibana, en detrimento de la herramienta Grafana, debido a que Kibana, al ser Elasticsearch el único motor de búsqueda de datos disponible, es la herramienta que ofrece mejores resultados y búsquedas más avanzadas.

Ventajas

  • Detección y análisis de ataques informáticos, que suponen una amenaza mundial del mismo nivel que el
    desempleo o las crisis económicas.
  • Control de los equipos vulnerables.

Financiación:
Pública

Contacto (1):
Antonio García Vázquez

Cargo: 
Gerente de EPICSA.

Teléfono:

Correo electrónico: 

Dirección:

Plaza Madrid s/n., Edificio Carranza, Fondo Sur, Local 10. 11010. Cádiz.

Desde el 25 de mayo hemos actualizado nuestra forma de comunicarnos contigo debido a la entrada en vigor del Reglamento General de Protección de Datos (RGPD).

Si no has recibido ningún correo nuevo o quieres comenzar a recibirlos, suscríbete y recibe gratis en tu correo nuestro boletín mensual con toda la actualidad del sector público.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *