Homelab SOC #15 - Integración Suricata + Wazuh
Por Wuilmer Bolívar · IT Operations Specialist
En el capítulo anterior desplegamos Suricata dentro de OPNsense, incorporando una nueva capa de visibilidad dentro de nuestro Homelab SOC.
Hasta ese momento, nuestro firewall ya era capaz de:
-
Analizar el tráfico de red.
-
Detectar patrones asociados a amenazas conocidas.
-
Generar alertas mediante reglas IDS.
-
Identificar actividades como escaneos de puertos realizados desde Kali Linux.
Durante las pruebas realizadas comprobamos cómo una actividad de reconocimiento podía ser detectada por Suricata:
Kali Linux
|
|
Escaneo Nmap
|
|
OPNsense + Suricata
|
|
Alerta IDS
Sin embargo, todavía existía una limitación importante, las alertas generadas por Suricata permanecían dentro del propio firewall, esto significa que, aunque Suricata detectaba correctamente la actividad sospechosa, la información no estaba integrada con el resto de la plataforma de monitoreo.
En un entorno SOC real, normalmente no se trabaja revisando cada herramienta de seguridad de manera independiente.
Un analista necesita una plataforma centralizada donde pueda consultar:
-
Eventos de endpoints.
-
Logs de servidores.
-
Alertas de red.
-
Indicadores de compromiso.
-
Actividades sospechosas.
Aquí es donde entra Wazuh.
Integrando las capas del SOC
Hasta este punto, nuestro laboratorio cuenta con diferentes fuentes de información:
Endpoint Detection
Windows 11 genera eventos utilizando Sysmon.
Windows 11
|
|
Sysmon
|
|
Wazuh Agent
Estos eventos permiten observar actividades como:
-
Creación de procesos.
-
Cambios en archivos.
-
Conexiones de red.
-
Ejecución de comandos.
Linux Monitoring
Ubuntu Server envía información del sistema mediante el agente de Wazuh.
Ubuntu Server
|
Wazuh Agent
|
Wazuh Manager
Esto permite analizar:
-
Autenticaciones.
-
Errores del sistema.
-
Servicios activos.
-
Eventos de seguridad.
Network Detection
Suricata agrega la visibilidad desde la capa de red.
Tráfico de red
|
Suricata IDS
|
Alertas JSON
|
Wazuh Manager
Ahora nuestro objetivo será unir estas fuentes.
La arquitectura final será:
Internet
|
OPNsense Firewall
|
Suricata IDS
|
Eventos eve.json
|
Wazuh Manager
|
+-------------+-------------+
| |
Windows 11 Ubuntu Server
Sysmon Logs Linux
| |
+-------------+-------------+
|
Wazuh Dashboard
¿Qué es la integración Suricata + Wazuh?
La integración consiste en permitir que Wazuh lea los eventos generados por Suricata.
Suricata almacena sus alertas en un archivo llamado:
eve.json
Este archivo contiene eventos en formato JSON.
JSON significa:
JavaScript Object Notation
Es un formato estructurado utilizado ampliamente para intercambio de información entre aplicaciones. Un evento generado por Suricata puede contener información como:
{
"timestamp": "2026-07-23T15:20:10.123456",
"event_type": "alert",
"src_ip": "10.0.100.100",
"dest_ip": "10.0.100.20",
"proto": "TCP",
"alert": {
"signature": "ET SCAN Nmap Scripting Engine User-Agent Detected",
"category": "Attempted Information Leak",
"severity": 2
}
}
Podemos interpretar este evento de la siguiente manera:
| Campo | Descripción |
|---|---|
| timestamp | Fecha y hora del evento |
| event_type | Tipo de evento generado |
| src_ip | Dirección IP origen |
| dest_ip | Dirección IP destino |
| proto | Protocolo utilizado |
| signature | Regla que generó la alerta |
| severity | Nivel de severidad |
La ventaja de utilizar un formato estructurado es que Wazuh puede analizar automáticamente cada campo y aplicar reglas de detección.
Verificando Suricata en OPNsense
Antes de integrar ambas plataformas debemos comprobar que Suricata está funcionando correctamente.
Ingresamos al panel web de OPNsense y navegamos hasta:
Services
└── Intrusion Detection
└── Administration
Debemos verificar:
-
Servicio habilitado.
-
Interfaz LAN seleccionada.
-
Reglas descargadas.
En este laboratorio mantenemos inicialmente Suricata en modo IDS. Esto significa:
IDS (Intrusion Detection System) detecta y genera alertas, pero no bloquea automáticamente.
IPS (Intrusion Prevention System) además puede tomar acciones como bloquear tráfico.
Para una fase inicial del laboratorio es recomendable comenzar con IDS para analizar el comportamiento antes de aplicar bloqueos automáticos.
Ubicación de los eventos de Suricata
Cuando Suricata está activo comienza a generar diferentes archivos de registro.
El más importante para esta integración es:
/var/log/suricata/eve.json
Este archivo será consumido posteriormente por Wazuh. Para verificar que existe ingresamos mediante SSH a OPNsense.
Para ello he configurado el archivo: .ssh/config con lo siguiente:
Host soc-wazuh virtual
HostName 192.168.100.130
User debian
Host soc-fw
HostName 10.0.100.1
User root
ProxyJump soc-wazuh
Eso me permitira conectarme a la maquina de opnsense por ssh usando la maquina Debian como sProxyJump considerando que se encuentra en mi red local:
ssh sof-fw
Una vez dentro ejecutamos:
ls -lah /var/log/suricata/
Debemos encontrar archivos similares:
eve.json
suricata.log
stats.log
El archivo que utilizaremos será:
eve.json
porque contiene los eventos estructurados que Wazuh puede interpretar.
Preparando Wazuh para recibir eventos
Nuestro siguiente paso será configurar Wazuh Manager para leer estos eventos. En nuestra arquitectura, Wazuh Manager se encuentra en nuestra red local, por lo cual puedo acceder así:
Debian Server
IP: 192.168.100.130
Accedemos al servidor:
ssh debian@192.168.100.130
Antes de modificar archivos importantes realizaremos una copia de seguridad.
sudo cp /var/ossec/etc/ossec.conf \
/var/ossec/etc/ossec.conf.backup
Configurar lectura de eventos en Wazuh
Wazuh utiliza un archivo principal de configuración llamado:
/var/ossec/etc/ossec.conf
Este archivo define diferentes parámetros del manager, incluyendo:
-
Fuentes de logs que deben ser monitorizadas.
-
Formatos de eventos.
-
Integraciones externas.
-
Configuración de módulos.
Para indicarle a Wazuh que debe leer eventos generados por Suricata agregaremos una nueva fuente de logs.
Editamos el archivo:
sudo nano /var/ossec/etc/ossec.conf
Dentro del archivo buscamos la sección:
<ossec_config>
Y agregamos:
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
La configuración indica:
| Parámetro | Función |
|---|---|
| localfile | Define un archivo que Wazuh debe monitorear |
| log_format | Indica el formato del evento |
| json | Permite interpretar estructuras JSON |
| location | Ruta del archivo generado por Suricata |
El reto de la arquitectura
En este punto existe un detalle importante. Suricata está ejecutándose dentro de OPNsense, mientras que Wazuh Manager está instalado en Debian Server.
Por lo tanto, los eventos generados por Suricata:
/var/log/suricata/eve.json
existen únicamente dentro del firewall y no directamente dentro del servidor Wazuh.
Actualmente tenemos:
OPNsense (10.0.100.1)
|
/var/log/suricata/eve.json
y:
Debian Server (10.0.100.10)
|
Wazuh Manager
/var/ossec/etc/ossec.conf
Necesitamos establecer un mecanismo que permita transportar los eventos generados por Suricata desde OPNsense hacia Wazuh para poder analizarlos dentro del SIEM.
Existen diferentes alternativas para realizar esta integración:
Opción 1 - Instalar un agente Wazuh en OPNsense
Esta opción consiste en instalar un agente Wazuh directamente dentro del firewall para enviar información hacia el Manager.
Ventajas:
-
Comunicación directa con Wazuh.
-
Arquitectura similar a otros endpoints monitorizados.
-
Permite aprovechar las capacidades nativas del agente.
Desventajas:
-
OPNsense no está diseñado como un sistema operativo tradicional.
-
Las actualizaciones del firewall podrían afectar la instalación.
-
Requiere mayor mantenimiento.
Opción 2 - Utilizar Syslog remoto
Otra alternativa es utilizar el mecanismo estándar de Syslog para enviar eventos desde OPNsense hacia Wazuh.
Este método es ampliamente utilizado en ambientes empresariales, especialmente con:
-
Firewalls.
-
Routers.
-
Switches.
-
Appliances de seguridad.
Ventajas:
-
No requiere instalar agentes adicionales.
-
Es compatible con prácticamente cualquier dispositivo de red.
-
Representa una arquitectura habitual en entornos SOC.
Desventajas:
-
Requiere configurar correctamente el envío y recepción de eventos.
-
Se debe considerar la protección del canal de comunicación.
Integración utilizando Wazuh Agent en OPNsense
Para este laboratorio inicialmente se evaluó la integración mediante Syslog remoto. Sin embargo, finalmente se optó por utilizar el plugin disponible para OPNsense:
Wazuh Agent
Este plugin permite registrar OPNsense como un endpoint administrado por Wazuh y facilita el intercambio de información entre el firewall y Wazuh Manager.
La instalación se realiza desde:
System
└── Firmware
└── Plugins
Buscamos:
os-wazuh-agent
e instalamos el complemento.
Una vez instalado, configuramos la conexión contra nuestro servidor Wazuh:
Wazuh Manager: 10.0.100.10
Después de completar la configuración y reiniciar el servicio, OPNsense comienza a comunicarse con Wazuh Manager permitiendo centralizar los eventos generados por el firewall y Suricata.
La arquitectura final queda:
Suricata IDS
|
OPNsense Firewall (10.0.100.1)
|
Wazuh Agent Plugin
|
Red interna SOC
|
Wazuh Manager (10.0.100.10)
Alternativa: integración mediante Syslog remoto
Aunque en este laboratorio utilizamos el plugin Wazuh Agent, también es posible realizar esta integración utilizando Syslog remoto.
Esta opción resulta especialmente útil cuando trabajamos con dispositivos donde no es posible instalar agentes, como firewalls comerciales, routers o appliances.
La configuración se encuentra en:
System
└── Settings
└── Logging
└── Remote
Creamos una nueva entrada:
Enabled: Activado
Transport: UDP
Applications: Suricata
Levels: info
Facilities: log alert
Hostname: 10.0.100.10
Port: 514
RFC5424: Desactivado
Description: Wazuh Syslog
La comunicación quedaría:
OPNsense
|
Syslog UDP 514
|
Wazuh Manager
10.0.100.10
En ambientes productivos normalmente se recomienda utilizar mecanismos más seguros como Syslog sobre TLS o canales autenticados.
En este laboratorio utilizamos UDP 514 únicamente para demostrar el flujo de integración entre un firewall, IDS y plataforma SIEM.
Configurando Wazuh como receptor Syslog
Si se utiliza la alternativa mediante Syslog, Wazuh debe configurarse para aceptar eventos externos.
Editamos:
sudo nano /var/ossec/etc/ossec.conf
Agregamos:
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>10.0.100.1</allowed-ips>
<local_ip>10.0.100.10</local_ip>
</remote>
Esta configuración indica:
| Campo | Descripción |
|---|---|
| connection | Tipo de conexión utilizada |
| syslog | Permite recibir eventos Syslog |
| port | Puerto donde Wazuh escucha |
| protocol | Protocolo de transporte utilizado |
Guardamos los cambios y reiniciamos el servicio.
Con esto OPNsense queda integrado dentro de la arquitectura SOC, permitiendo que los eventos generados por Suricata y el firewall sean enviados hacia Wazuh para su análisis, correlación y generación de alertas.
Permitiendo el puerto en Debian
Si tenemos habilitado UFW debemos permitir el tráfico Syslog.
Verificamos el estado:
sudo ufw status
Si está activo:
sudo ufw allow 514/udp
Reiniciando Wazuh Manager
Después de modificar la configuración debemos reiniciar el servicio.
sudo systemctl restart wazuh-manager
Validamos que inició correctamente:
sudo systemctl status wazuh-manager
El resultado esperado:
Active:
active (running)
Validando recepción de eventos
Antes de realizar pruebas de seguridad debemos comprobar que Wazuh está recibiendo información.
Observamos los logs del manager:
sudo tail -f /var/ossec/logs/ossec.log
Si la integración es correcta podremos observar mensajes relacionados con:
syslog
remote
connection accepted
Generando una alerta de prueba
Ahora validaremos la integración utilizando Kali Linux.
La prueba consistirá en realizar un escaneo contra Windows 11.
Nuestra arquitectura:
Kali Linux
10.0.150.10
|
Nmap
|
Ubuntu (10.0.110.20)
Desde Kali ejecutamos:
nmap -sV 10.0.110.20
Este comando realiza:
-
Descubrimiento de servicios.
-
Identificación de versiones.
-
Enumeración básica de puertos.
Desde la perspectiva de un atacante, representa una fase inicial de reconocimiento.
Desde la perspectiva del SOC, representa una actividad que debe ser investigada.
Analizando la alerta generada
Suricata procesa el tráfico y genera un evento.
Ejemplo:
{
"event_type": "alert",
"src_ip": "10.0.150.10",
"dest_ip": "10.0.110.20",
"alert": {
"signature": "ET SCAN Nmap User-Agent Detected",
"severity": 2
}
}
El flujo completo ahora es:
Kali Linux (Escaneo Nmap)
|
OPNsense + Suricata
|
Alerta IDS (Syslog)
|
Wazuh Manager (Dashboard)
Diferencia entre IDS, IPS y SIEM
Durante el proyecto hemos utilizado diferentes tecnologías que cumplen funciones distintas.
| Tecnología | Función |
|---|---|
| Firewall | Controla conexiones permitidas o bloqueadas |
| IDS | Detecta actividad sospechosa |
| IPS | Detecta y bloquea automáticamente |
| SIEM | Centraliza y analiza eventos |
En este laboratorio:
OPNsense (Firewall) + Suricata (IDS) + Wazuh (SIEM)
Cada componente aporta una capa diferente de visibilidad.
Lo aprendido
En este capítulo integramos Suricata con Wazuh, conectando la capa de detección de red con nuestro sistema centralizado de monitoreo.
Durante el proceso aprendimos:
-
Cómo Suricata genera eventos utilizando formato JSON.
-
Cómo transportar eventos desde un dispositivo de red hacia un SIEM.
-
Cómo configurar Wazuh para recibir información externa.
-
Cómo validar alertas utilizando técnicas de reconocimiento.
-
Cómo analizar eventos desde la perspectiva de un analista SOC.
Esta integración representa un punto importante dentro del proyecto porque nuestro laboratorio deja de ser un conjunto de herramientas independientes y comienza a comportarse como una plataforma integrada de seguridad.
Actualmente contamos con visibilidad desde diferentes capas:
Capa de red
OPNsense + Suricata
Permite identificar: Escaneos, Patrones maliciosos y Actividad sospechosa.
Capa de endpoint
Windows + Sysmon + Wazuh Agent
Permite analizar: Procesos, Cambios del sistema y Ejecuciones sospechosas.
Capa de servidores
Ubuntu Server + Wazuh Agent
Permite monitorear: Servicios, Autenticaciones y Eventos del sistema.
Te invito a continuar el resto del proceso en próximas publicaciones.