SOC con Wazuh como SIEM #

En este proyecto se tratará de montar un SOC en Vmware Workstation, pero toalmente funcional, se irá actualizando poco a poco. Los elementos principales con los que se va a contar son:

• SIEM (Wazuh)
• IDS (Suricata)
• Adversary simulation (Caldera)
• Honeypots
• pFsense (Enrutar, NATear y aislar las distintas redes)

Índice #

1. SOC con Wazuh como SIEM 1.1. Elementos principales

2. Planeamiento 2.1. Redes y conexiones 2.2. IMPORTANTE

3. 📌 Configuración de Máquinas Virtuales y Redes 3.1. Tabla de configuración de redes

4. 📌 Tabla de Credenciales del Laboratorio

5. Esquema de red

6. Requisitos previos 6.1. Configuración en Windows 6.2. Configuración en Linux (Debian 12)

7. Instalación y configuración pFsense 7.1. Configuración de interfaces en pFsense 7.2. Reglas de firewall 7.3. Configuración firewall WAN Interface 7.4. Configuración firewall SOC Interface 7.5. Configuración firewall HONEYPOT Interface

8. Instalación y configuración Wazuh 8.1. Instalación de Wazuh 8.2. Generación de ficheros de configuración e instalación 8.3. Deshabilitar repositorios Wazuh

9. Instalación y configuración Suricata 9.1. Instalación de Suricata 9.2. Configuración de Suricata 9.3. Comprobación de alertas 9.4. Envío de logs de Suricata a Wazuh

10. Instalación y configuración Honeypot 10.1. Instalación de Honeypot 10.2. Lanzar Honeypot 10.3. Lanzar honeypots

11. Instalación e inicio Caldera 11.1. Instalación de Caldera 11.2. Alternativa Docker

12. File Integrity Monitoring (FIM)

13. Custom SCA con Wazuh

14. CONTINUARÁ EL DESARROLLO CON: 14.1. CDB lists 14.2. VirusTotal integration 14.3. Windows defender logs integration 14.4. Sysmon integration 14.5. TheHive + Cortex 14.6. MISP 14.7. Shuffle SOAR 14.8. Active response scripts 14.9. Threat Hunting

Planeamiento #

Lo primero que se va a planear son las redes y conexiones, tendremos 3 redes:

• LAN: será la que de acceso a la WAN
• SOC: donde tendremos Wazuh, Suricata y Caldera
• SERVERS: donde tendremos el Honeypot

IMPORTANTE #

Al diseñar el laboratorio en vmware workstation (linux), no funciona el modo promiscuo para suricata, o al menos yo no lo conseguí hacer funcionar, algo imprescindible para el “sniffing” de paquetes de la red de Honeypot. Para ello se necesitaría o:

• Poner suricata de proxy entre honeypot y pfsense
• Un switch físico y hacer port-mirroring hacia un interfaz de suricata
• Realizar el laboratorio en workstation Windows (teóricamente funciona)

No obstante, se ha detallado el proyecto para que puedas realizarlo de una de estas 3 maneras. En mi caso, la máquina suricata llevará el honeypot integrado, es decir, Suricata + Honeypot en la misma MV.

La guía se puede seguir perfectamente, a la hora de instalar el honeypot, se avisará de lo que hay que hacer (caso de usar Vmware Workstation en Linux)

**📌 Configuración de Máquinas Virtuales y Redes ** #

📌 Tabla de Credenciales del Laboratorio #

Esquema de red #

Requisitos previos #

Para no extender mucho esta guía, se omitirán ciertos pasos pero que son requisito previo e indispensable:

• Crear Vmnets

• Asegurarse que el Vmnet0 en modo bridge está en bridge con la interfaz deseada

• Configurar router de la red de casa para:

  • pFsense (192.168.1.200) tenga todos sus puertos abiertos. Se puede meter en DMZ
  • Reenvío de tráfico de los servicios que queramos ser atacados hacia el pFsense

• Configurar el equipo anfitrión en la red de SOC para poder acceder a las interfaces de wazuh, caldera, etc.

  #Windows Tan sencillo como editar la interfaz desde el administrador de interfaces

  #Linux (Debian 12) Crear un fichero para el interfaz: sudo nano /etc/systemd/network/10-vmnet1.network (Para otras ocasiones solo cambiar el vmnet, lo del “10-” se mantiene).

  [Match]
  Name=vmnet1
  
  [Network]
  Address=10.0.1.3/24
  Gateway=10.0.1.200
  

sudo systemctl restart systemd-networkd

Instalación y configuración pFsense #

Una vez tengamos la MV instalada, le agregaremos 3 interfaces de red conectados a:

• Vmnet0 será la WAN
• Vmnet1 será SOC
• Vmnet2 será Honeypot

Se habilita el interfaz, asignamos un nombre, establecemos IP estática, cambiamos el CIDR y nos aseguramos que la interfaz de WAN, su gateway de “upstream” sea la gw de tu red local de casa.

El siguiente paso es configurar las reglas de firewall, las principal intención de comunicación es:

• Honeypot puede ser accedido dese WAN (para ser atacado)
• Honeypot puede acceder a SOC (para enviar logs a Wazuh)
• Honeypot puede ser accedido desde SOC (Para acceder desde Kali, Wazuh, Caldera, etc)
• Suricata NO puede ser accedido desde WAN (no tiene motivos para ello)
• Suricata puede acceder a WAN (buscar updates)
• Suricata puede acceder a SOC (enviar logs a Wazuh)
• Suricata puede ser accedido desde SOC
• SOC puede acceder a WAN (updates e internet)
• SOC NO puede ser accedido desde WAN (no tiene motivos para ello)

Configuración firewall WAN Interface #

Configuración firewall SOC Interface #

Configuración firewall HONEYPOT Interface #

Instalación y configuración Wazuh #

Instalamos (En mi caso Ubuntu Server 22.04), asignamos Vmnet1, establecemos direccionamiento IP (10.0.1.2/24 - Gw 10.0.1.200).

apt update && apt upgrade -y

NOTA:Dependiendo de la versión de wazuh, los comandos pueden variar, lo mejor es consultar la documentación oficial

15. Descargar el script de instalación (la URL variará)

curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.10/config.yml

16. Editar el config.yml con el hostname de la MV y la IP

17. Generar ficheros de configuración e instalar

bash wazuh-install.sh --generate-config-files
bash wazuh-install.sh -a

18. Eliminar repositorios de wazuh, para evitar un upgrade accidental que pueda estropear el servicio. (OPCIONAL)

sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt update

Instalación y configuración Suricata #

Instalamos el S.O, asignamos 2 interfaces de red al Vmnet1, y establecemos direccionamiento IP.

apt update && apt upgrade -y
add-apt-repository ppa:oisf/suricata-stable
apt install suricata -y



# Descargar emmerging rules
cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz  
sudo tar -xvzf emerging.rules.tar.gz && mkdir /etc/suricata/rules && sudo mv rules/*.rules /etc/suricata/rules/  
	sudo chmod 640 /etc/suricata/rules/*.rules

19. Editar configuración para especificar la interfaz de red, y la HOME_NET (la red que queremos monitorear), ademas de las nuevas rules descargadas.

20. Habilitar al inicio e iniciar

systemctl enable suricata
systemctl start suricata

21. Comprobar alertas

#Ya deberiamos ver los scans de nmap, por ejemplo
tail -f /var/log/suricata/fast.log

Envío logs Suricata > Wazuh #

Para ello necesitaremos tener un agente de Wazuh instalado en suricata. En el panel de Wazuh > Deploy Agents. Rellenamos con la IP del servidor, elegimos S.O destino, etc. y nos generará un comando similar al siguiente, que descargará el agente de los servidores de Wazuh (internet) con la configuración deseada. En caso de ser offilne, se puede descargar e importar el agente de manera offline.

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.1-1_amd64.deb && sudo WAZUH_MANAGER='10.0.1.2' dpkg -i ./wazuh-agent_4.10.1-1_amd64.deb

Editamos el siguiente fichero para decirle al agente de wazuh donde están los logs: Si no funciona, agregar tambien al fichero ossec.conf del manager, desde la interfaz web

/var/ossec/etc/ossec.conf


# eal final del fichero en el ultimo <ossec_config> (no en el primero)
	
	<localfile>
		<log_format>syslog</log_format>
		<location>/var/log/suricata/eve.json</location>
	</localfile>

Por último habilitamos el servicio y lo iniciamos:

sudo systemctl daemon-reload 
sudo systemctl enable wazuh-agent 
sudo systemctl start wazuh-agent

Instalación y configuración Honeypot #

Llegados a este punto, si virtualizas en workstation con linux, debes agregar una regla para permitir el tráfico desde WAN hacia suricata. Si tu caso es cualquier otro descrito en esta guía, puedes seguir normalmnete., teniendo en cuenta en que MV instalar el Honeypot.

Instalación #

apt
apt install python3-pip
pip install honeypots

Lanzar honeypot #

Honeypots tiene una larga lista de servicios que se pueden lanzar, para ver el listado:

Listar honeypots #

honeypots --list

Lanzar honeypot #

# Ejepmplo lanazr SSH
python3 -m honeypots --setup ssh --auto

# Lanzar todos:
python3 -m honeypots --setup all --auto

Instalación e inicio Caldera #

Caldera es un servicio para la emulación del adversario, de esta manera podremos lanzar ataques simulados a nuestro honeypot y comprobar la detección por parte de wazuh.

git clone https://github.com/mitre/caldera.git --recursive
cd caldera
pip3 install -r requirements.txt

#### INICIAR EL SERVICIO
python3 server.py --insecure --build

Instalación docker (alternativa) #

# Recursively clone the Caldera repository if you have not done so
git clone https://github.com/mitre/caldera.git --recursive

# Build the docker image. Change image tagging as desired.
# WIN_BUILD is set to true to allow Caldera installation to compile windows-based agents.
# Alternatively, you can use the docker compose YML file via "docker-compose build"
cd caldera
docker build . --build-arg WIN_BUILD=true -t caldera:latest

# Run the image. Change port forwarding configuration as desired.
docker run -p 8888:8888 caldera:latest

Tras el despliegue, debemos desplegar un agente en el honeypot, para lanzar los ataques simulados y ver si en wazuh vemos los detalles de esos ataques.

ACCESO #

https://<ip>:8888

File Integrity Monitoring (FIM) #

Trata de monitorizar la integridad de ciertos ficheros y directorios importantes. para ello en el agente de la MV en cuestión (honeypot), debemos agregar los directorios y/o ficheros que queramos monitorizar.

Dependiendo de la maquina, en un entorno real, unos directorios serán importantes y otros no. Debemos conocer nuestro servicio y la criticidad para saber determinar que es importante y que no.

## EQUIPO CLIENTE LINUX CON AGENTE WSUS
/var/ossec/etc/ossec.conf

# Apartado de File integrity monitoring
<syscheck>
  <disabled>no</disabled>
  <frequency>720</frequency>
  <scan_on_start>yes</scan_on_start>
  <directories check_all="yes" report_changes="yes" real_time="yes">/etc,/bin,/sbin</directories>
  <directories check_all="yes" report_changes="yes" real_time="yes">/lib,/lib64,/usr/lib,/usr/lib64</directories>
  <directories check_all="yes" report_changes="yes" real_time="yes">/var/www,/var/log,/var/named</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>
  <ignore>/etc/random-seed</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore>/etc/httpd/logs</ignore>
  <ignore>/etc/utmpx</ignore>
  <ignore>/etc/wtmpx</ignore>
  <ignore>/etc/cups/certs</ignore>
  <ignore>/etc/dumpdates</ignore>
  <ignore>/etc/svc/volatile</ignore>
  <ignore>/sys/kernel/security</ignore>
  <ignore>/sys/kernel/debug</ignore>
  <ignore>/sys</ignore>
  <ignore>/dev</ignore>
  <ignore>/tmp</ignore>
  <ignore>/proc</ignore>
  <ignore>/var/run</ignore>
  <ignore>/var/lock</ignore>
  <ignore>/var/run/utmp</ignore>
</syscheck>

Custom SCA con Wazuh #

Cumplimiento CCN-STICS #

El Security Configuration Assessment (SCA) es una herramienta clave para evaluar el cumplimiento de estándares de seguridad como CIS o NIST, verificando configuraciones como el tiempo de desconexión tras inactividad.

En este caso se desarrolla el cumplimiento de las CCN-STICS para cumplir con el marco del ENS (Esquema nacional de seguridad Español)

Debido a lo extenso que es este apartado, se ha desarrollado en otro artículo, publicado en la siguiente url: Custom SCA con Wazuh

CONTINUARÁ EL DESARROLLO CON: #

• CDB lists
• VirusTotal integration
• Windows defender logs integration
• Sysmon integration
• TheHive + Cortex
• MISP
• Shuffle SOAR
• Active response scripts
• Threat Hunting