Nota de @guille_hartek
¡Buenas a todos! Hoy traemos una colaboración muy especial. Se trata de un fragmento del trabajo de fin de grado de Cristina Martínez Carpintero, de título Desarrollo de un entorno virtual para pruebas de hacking y hardenización. Con gran ilusión por mi parte, tuve el placer de ser codirector de este trabajo, que estuvo basado en continuar y expandir las dos primeras partes de la serie de GNS3 en este blog.
He de decir que el resultado ha sido un trabajo de grandísima calidad por su parte. Y por si fuera poco se ha ofrecido a publicar un fragmento del apartado técnico en nuestra página. ¡Muchísimas gracias Cristina!
Sin más, os dejo con esta magnífica colaboración. ¡Muchas gracias por leernos!
¡Buenas, conejetes! Hoy venimos con la tercera parte de la saga de GNS3, por aquí os dejo la primera parte y por aquí la segunda parte. Continuaremos con esa topología de red que teníamos montada, os pongo el esquema para refrescar la memoria:
En esta nueva entrada, introduciremos una nueva máquina para la parte WAN de la red, incorporaremos un sistema de prevención de intrusos (IPS) que además de configurar, pondremos a prueba (para saber cómo tendréis que seguir leyendo, no os voy a hacer spoiler), y por último, integraremos el IPS con un sistema de gestión de eventos (SIEM) para facilitarnos el trabajo de monitorizado de la red.
Red Externa
Como veis, tenemos trabajo por delante, ¡así que vamos a ello! Al final del segundo post creamos un DNAT para poder acceder al servidor web desde un equipo de usuario en el lado WAN, este DNAT redirigía a la máquina Debian todo el tráfico de tipo Web Surfing que tuviese como destino la dirección de la interfaz WAN (192.168.122.2). Pues bien, retomamos por ahí, vamos a introducir en nuestra red un equipo que pertenezca a la red externa.
Este equipo va a ser una máquina Kali Linux, porque ya que estamos, alguna perrería habrá que hacerle a la red, ¿no? Je,je… La podéis descargar de aquí.
Después de montar toda la red ya sabréis como funciona esto, pero vamos a refrescar la memoria. Una vez instalada la máquina Kali en VMware, tenemos que importarla a GNS3 desde Edit -> Preferences -> VMwares VMs -> New.
Después podemos encontrarla en el menú lateral, en Browse End Devices, así que la arrastramos al proyecto y cambiamos su nombre por attacker_Kali. También del menú Browse End Device cogeremos el dispositivo NAT, lo metemos al proyecto y lo llamamos NET_KALI. Ahora, con la herramienta Add a link, que es la última del menú lateral, toca conectarlos. Tanto la máquina como el dispositivo NAT tienen una única interfaz, así que no hay posibilidad de fallo.
Después tenemos que buscar Kali en VMware y eliminar la interfaz de red que tenga asignada, y en GNS3, desde Edit -> Preferences -> VMware -> Advanced local settings, pulsar Configure. Por si no recordáis del primer post, esto es necesario para que GNS3 pueda gestionar las interfaces virtuales de VMware.
Ya podemos encender la máquina Kali y asignarle una dirección IP. La aplicación NAT se encuentra en el rango IP 192.168.122.0/24, por lo que asignaremos a la máquina cualquier dirección IP dentro de este rango, yo he asignado la dirección 192.168.122.101.
Ahora ya podremos acceder desde esta máquina al servidor web, o desde la dirección IP 192.168.122.2, es decir, la dirección de la interfaz WAN a la que configuramos el DNAT, o podemos aprovechar que estamos en una distribución de Linux y asignar un nombre de dominio en el fichero hosts… Vamos a hacer las dos cosas, ¿por qué no?
Accedemos al fichero de configuración /etc/hosts y asignamos la IP de la interfaz WAN al nombre de dominio que queramos, en mi caso he cogido apache.local.
Y probamos a acceder al servidor con la IP de la interfaz WAN y también con el nombre de dominio.
De momento va todo bien, la máquina de la red externa tiene conectividad con el servidor web, por lo que ya la tenemos preparada para la prueba que haremos después.
Sistema de prevención de intrusos
Vamos con la máquina Debian, le vamos a instalar Suricata, un software de detección y prevención de intrusos (IDS/IPS) que inspecciona el tráfico en tiempo real utilizando un lenguaje de firmas y reglas.
Lo primero, como es obvio, será instalar Suricata en la máquina, lo cual es muy sencillo, ya que Suricata se encuentra en los repositorios Debian.
sudo apt install suricata
Una vez instalado, vamos a comprobar que está activo y funcionando correctamente mediante el comando
systemctl status suricata
Todo correcto, ahora es necesario realizar unos pequeños cambios en la configuración de Suricata para que funcione correctamente. Suricata está configurado para trabajar por defecto sobre la interfaz eth0, pero en las últimas versiones de Debian esta interfaz no existe, por lo que necesitamos saber el nombre de la interfaz de red.
Sabiendo que el nombre de la interfaz es ens33, hay que acceder al archivo suricata.yaml ubicado en la ruta /etc/suricata y modificar la interfaz de trabajo. En la imagen podéis ver también cómo localizar rápidamente la línea que hay que modificar, ya que el archivo es bastante extenso (busco la cadena “af-Packet”, el módulo de trabajo de Suricata).
Con esto, Suricata ya sabe por dónde le llegará el tráfico que debe analizar, ahora debemos decirle qué reglas debe aplicar para analizar este tráfico. Crearemos alguna regla manual, pero primero vamos a instalar las reglas de Emerging Threats, que cubren una gran cantidad de amenazas. Para instalarlas simplemente escribir:
suricata-oinkmaster-updater
Estas reglas se almacenan en la ruta /etc/suricata/rules, y si echamos un vistazo, veremos que son unas cuantas…
Vamos a volver al archivo suricata.yaml para definir la red local y la red externa. Como red local le vamos a poner el rango IP de la VLAN 10, la VLAN 20, y la DMZ (que en su día definimos como VLAN 16), y como red externa le vamos a poner “!$HOME_NET”, es decir, que considere red externa todo lo que no sea red local.
Vamos a crear ahora una regla para… ¡detectar y detener un ataque de denegación de servicio! (las reglas instaladas ya contienen un conjunto de reglas “emerging-dos”, pero ninguna de estas se activa ante el ataque lanzado, ya que son muchos los parámetros a tener en cuenta). Crearemos un archivo en la ruta /etc/suricata/rules de nombre custom.rules que contendrá lo siguiente:
drop tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg: ”Potential DoS attack. Rejecting…”; flags: S,12; threshold: type both, track by_dst, count 50, seconds 1; sid:4; rev:3.5; classtype:DoS-custom-event;)
A grandes rasgos, lo que le estamos diciendo con esta regla es que rechace el tráfico TCP SYN (SYN porque especificamos el flag S) que provenga de cualquier puerto de la red externa si este va dirigido al puerto 80 de la red interna, pero esta regla solamente se activará cuando detecte más de 50 peticiones/segundo a la misma dirección IP de destino.
Es una buena práctica asignar a cada regla:
- sid: número identificador.
- rev: valor numérico cuya función es llevar un control de la versión de la regla si esta sufre modificaciones.
- classtype: sirve para asignar el valor que se desee al campo “Classification” y “Priority” de los logs, para lo cual hay que añadir el Classtype al fichero /etc/suricata/classification.config
Con esto, todas las reglas a las que se les asigne el Classtype “DoS-custom-event” se clasificarán en los logs como “DoS attack” con una prioridad de 2.
La regla ya está creada, pero por defecto Suricata no la tiene incorporada en su lista de reglas con las que analizar el tráfico, tenemos que añadirla a esta lista, que se encuentra en el archivo suricata.yaml.
Por último, quedaría recargar el servicio para cargar las nuevas reglas y configuraciones:
sudo systemctl reload suricata
Antes de ver si la regla funciona correctamente, mencionar que los registros de Suricata se almacenan en la ruta /var/log/suricata, y que, aunque tiene cuatro ficheros de registros, nosotros realmente solo nos fijaremos en dos, fast.log, que almacena los eventos disparados por las reglas y da una visión bastante directa de estos, y eve.json, que da información más detallada y además en formato JSON (lo cual ya os adelanto que será bastante útil).
Ahora usaremos la máquina Kali que hemos configurado antes para lanzar un ataque de denegación de servicio al servidor con hping3. No me detendré mucho en la realización del ataque, en la imagen podéis ver los parámetros que he usado para lanzarlo.
No os asustéis porque os diga que todos los paquetes se están perdiendo, el modo –flood no muestra resultados en la terminal, y eso hace que los paquetes consten como perdidos, pero el ataque está llegando al servidor.
Vamos a ver ahora que está pasando por Suricata….
tail -f fast.log | grep “DoS”
tail -f eve.json | grep “DoS”
¡Funciona! Viendo los registros de Suricata es obvio que está detectando el ataque, pero no es tan evidente que también lo está bloqueando, sin embargo, os invito a que levantéis Wireshark en el enlace del switch a la máquina Debian durante el ataque DoS y veáis los RST del servidor al atacante. Este RST se debe al parámetro drop de la regla, si queréis que la presencia del IPS en la red no sea tan cantosa para posibles atacantes, podéis sustituir este parámetro por reject, detendrá el ataque igualmente pero no enviará el RST.
De momento tenemos Suricata con una regla que detecta y detiene los ataques de denegación de servicio, además de otras tantas reglas, las que hemos instalado de Emerging Threats, que si recordáis eran unas cuantas… probad a echar un vistazo a los registros de Suricata sin el “| grep DoS”, veréis que divertido 😊.
Trabajar con registros es… poco amigable, los de Suricata no iban a ser menos, y la cantidad de registros que genera aun cuando aparentemente no hay movimiento en la red es una locura. Vamos a intentar simplificarnos un poco la vida indexando todos los registros que genera Suricata en un sistema de gestión de eventos (SIEM), desde ahí será más fácil monitorizar la red.
Sistema de Gestión de Eventos (SIEM)
El SIEM elegido es Splunk, en este enlace podéis descargar una prueba de la versión Splunk Enterprise y tras 60 días podréis comprarla o pasar a la versión Splunk Free, que será suficiente en la mayoría de los casos.
Una vez descargado el archivo .deb (para la máquina Debian), lo instalaremos en el directorio /opt/splunk, y accederemos al directorio /opt/splunk/bin para poder ejecutarlo, mediante el comando:
./splunk start
Pedirá entonces crear un usuario y contraseña para poder acceder luego al entorno web, y aceptar la licencia de Splunk Enterprise. Tras esto anunciará la dirección y el puerto mediante los que se accederán al entorno web de Splunk, que será localhost:8000 si el puerto 8000 está disponible, si no es así, buscará otro puerto libre.
Vamos a ver ahora las configuraciones necesarias para la integración con Suricata. En primer lugar, descargaremos la aplicación Splunk TA for Suricata incluida en la comunidad de Splunkbase, esta se encargará de adaptar los logs de Suricata al formato Splunk CIM.
Una vez descargada, para su instalación debemos acceder al entorno web de Splunk mediante la dirección mencionada y el usuario y contraseña creados anteriormente, y en el panel lateral izquierdo, acceder a los ajustes del menú Apps y después seleccionar Install app from file.
En la ventana que se abre, buscamos el archivo Splunk TA for Suricata descargado de Splunkbase y pulsamos Upload.
Si ahora vamos a Settings – Data inputs – Files & Directories, veremos un input llamado /var/log/suricata/eve.json, este input se ha creado automáticamente con la instalación de la aplicación, y pinchando sobre él podemos ver y modificar sus parámetros.
- Host: nombre identificativo que nos servirá para identificar la máquina de la que provienen los eventos.
- Source type: sirve para clasificar el tipo de eventos que está indexando de este input.
- Index: simplificándolo, el index es la estructura que define Splunk para almacenar los datos que recibe de un input.
Es decir, la entrada de datos es el archivo eve.json de Suricata, y todos los datos que indexe de este input los almacenará en un index llamado Suricata, que tenemos que definir. La definición del index se puede hacer o bien mediante el entorno web en Settings – Indexes, o bien mediante el fichero indexes.conf. Mi experiencia con la creación del index en el entorno web no ha sido buena, por lo que os recomiendo que lo creéis directamente mediante el fichero.
Splunk almacena sus index creados por defecto en el fichero indexes.conf ubicado en la ruta /opt/splunk/etc/system/default, no obstante, el fichero avisa en su cabecera que no debe ser modificado, por lo tanto, vamos a crear un nuevo fichero con el mismo nombre en la ruta /opt/splunk/etc/system/local, donde haremos la configuración del index nombrado anteriormente como “suricata”.
Realmente solo debemos configurar los 5 primeros parámetros, el resto, los que están a 0 y 1, se añaden automáticamente una vez que el index está en funcionamiento. Con esto, Splunk debería comenzar a indexar los registros de Suricata. Si aún no os funciona, debéis crear un fichero inputs.conf en la ruta /opt/splunk/etc/system/default para definir manualmente el input de los registros de Suricata.
Una vez que los registros de Suricata están en Splunk, sentíos libres de navegar por todas las herramientas que ofrece Splunk, yo os voy a dar un ejemplo de la creación de un nuevo panel que contendrá una gráfica para visualizar los eventos del ataque de denegación de servicio. Para esto he lanzado la siguiente búsqueda:
index=”suricata” “alert.category”=”DoS attack” | timechart count as “DoS events”
Tras realizar la búsqueda, entraremos en el menú “Visualization”, donde podemos elegir el tipo de gráfico que más se adapte al dato que estamos visualizando, el nombre de los ejes, de la gráfica, la franja temporal…
Una vez que tenemos el gráfico tal y como lo queremos, iremos a “Save As… Dashboard Panel” y elegimos crear un panel nuevo y su título.
Y después de esto, accediendo al menú Dashboards, encontramos el panel creado con una gráfica que muestra los eventos clasificados como ataque de denegación de servicio en las últimas 24h.
Una vez que tenemos una búsqueda añadida como resultado a un panel, esto facilita enormemente el trabajo de monitorizado de la red, ya que debajo del resultado (en este caso el resultado es una gráfica, pero también hay, por ejemplo, contadores) podemos encontrar un botón de “Open in search” que nos permite acceder al momento a los eventos del resultado y ver toda la información.
Con esto, el engranaje Suricata-Splunk ya está en marcha; Suricata por sí solo ya tiene un gran potencial, ya que si manejamos la estructura de sus reglas se pueden crear reglas para todo, pero si además lo combinamos con Splunk, donde además de lanzar consultas podemos generar paneles, reportes, alertas en tiempo real… el resultado es un tándem bastante poderoso.
Extraído del TFG: Desarrollo de un entorno virtual para pruebas de hacking y hardenización.
Cristina Martínez Carpintero.