Homelab SOC #14 - Desplegando Suricata como IDS en OPNsense
Por Wuilmer Bolívar · IT Operations Specialist
En el capítulo anterior completamos una de las modificaciones más importantes dentro de la arquitectura del Homelab SOC: la migración de la red interna desde el segmento temporal:
192.168.1.0/24
hacia la red definitiva:
10.0.100.0/24
Este cambio permitió establecer una estructura de direccionamiento consistente para todos los componentes del laboratorio:
Internet
│
NAT VirtualBox
10.0.2.0/24
│
WAN (DHCP)
OPNsense
│
LAN 10.0.100.1/24
│
Red Interna HomelabSOC
│
┌──────────────┼──────────────┐
│ │ │
Kali Linux Windows 11 Ubuntu Server
10.0.100.100 10.0.100.20 10.0.100.30
│
Wazuh Server
10.0.100.10
Hasta este punto, OPNsense cumple principalmente las funciones de:
- Firewall.
- Gateway de la red interna.
- Servidor DHCP.
- NAT hacia Internet.
Sin embargo, aunque el firewall controla el tráfico, todavía existe una limitación importante:
El firewall permite o bloquea conexiones, pero no necesariamente comprende si una actividad representa un comportamiento malicioso.
Por ejemplo, un escaneo de puertos realizado desde Kali Linux puede ser permitido por las reglas actuales, pero desde una perspectiva de seguridad representa una actividad que debería ser observada y registrada.
Aquí es donde entra Suricata.
Objetivo de este capítulo
La pregunta que responderemos será:
¿Cómo convertir OPNsense en una plataforma capaz de detectar actividades sospechosas dentro de la red utilizando Suricata?
Durante este capítulo instalaremos y configuraremos Suricata como motor de detección de amenazas, habilitando capacidades de:
- Network Intrusion Detection System (NIDS).
- Network Intrusion Prevention System (NIPS).
- Análisis de tráfico en tiempo real.
- Detección basada en firmas.
- Generación de alertas de seguridad.
Al finalizar tendremos una nueva capa dentro del Homelab SOC:
Internet
│
OPNsense
│
Suricata IDS
│
Análisis del tráfico
│
Alertas SOC
Estas alertas serán posteriormente integradas con Wazuh para lograr una visión centralizada de los eventos de seguridad.
¿Qué es Suricata?
Suricata es un motor de análisis de red de código abierto desarrollado por la comunidad de seguridad informática, su objetivo principal es inspeccionar paquetes de red en tiempo real y detectar patrones asociados con actividades maliciosas.
A diferencia de un firewall tradicional, que toma decisiones principalmente basadas en:
- Dirección IP.
- Puerto.
- Protocolo.
- Estado de conexión.
Suricata analiza el contenido y comportamiento del tráfico utilizando reglas de detección.
Por ejemplo:
Un firewall puede observar:
Kali Linux
10.0.100.100
Conexión TCP hacia:
10.0.100.20:445
Mientras que Suricata puede identificar:
ET SCAN Possible Nmap Scan
Origen:
10.0.100.100
Destino:
10.0.100.20
Actividad:
Reconocimiento de red
Esta diferencia es fundamental dentro de un SOC.
El objetivo no es únicamente permitir o bloquear tráfico, sino generar contexto sobre lo que está ocurriendo dentro de la infraestructura.
IDS vs IPS
Antes de activar Suricata es importante diferenciar dos modos de operación.
IDS - Intrusion Detection System
Un IDS funciona como un sistema de monitoreo.
Su función es:
- Observar tráfico.
- Comparar eventos contra reglas.
- Generar alertas.
El flujo sería:
Tráfico
│
▼
Suricata IDS
│
▼
Alerta
Ejemplo:
Detectado:
Posible escaneo Nmap
Acción:
Registrar evento
El tráfico continúa pasando.
IPS - Intrusion Prevention System
Un IPS agrega capacidad de bloqueo.
El flujo sería:
Tráfico
│
▼
Suricata IPS
│
┌──────┴──────┐
│ │
Permitido Bloqueado
Ejemplo:
Detectado:
Comunicación con servidor C2 conocido
Acción:
Bloquear conexión
Durante esta primera implementación del Homelab SOC utilizaremos Suricata principalmente como IDS, la prioridad inicial es comprender la generación de eventos, analizar alertas y posteriormente integrar esta información con Wazuh.
En ambientes empresariales, activar capacidades IPS requiere una fase previa de pruebas debido a que una regla mal configurada podría bloquear tráfico legítimo.
¿Por qué incorporar Suricata ahora?
La arquitectura actual del laboratorio ya cuenta con visibilidad sobre los equipos mediante agentes:
Windows 11
│
Sysmon
│
Wazuh Agent
│
Wazuh Server
Ubuntu Server
│
Wazuh Agent
│
Wazuh Server
Esto nos permite observar eventos generados dentro de los sistemas operativos, sin embargo, todavía existe una capa que no estamos analizando:
Usuarios
│
▼
Tráfico de red
│
▼
Infraestructura
Un atacante normalmente no comienza ejecutando malware directamente.
Antes suele realizar actividades como:
- Reconocimiento.
- Escaneo de puertos.
- Enumeración de servicios.
- Identificación de versiones.
- Búsqueda de vulnerabilidades.
Estas actividades ocurren en la capa de red. Por esta razón, incorporar Suricata complementa la arquitectura actual:
Homelab SOC
Endpoint Security
│
│
Wazuh
│
│
-------------------
│
│
Network Security
│
│
OPNsense + Suricata
Instalación de Suricata en OPNsense
Después de definir el objetivo de incorporar una capa de detección de red dentro del Homelab SOC, el siguiente paso consiste en habilitar Suricata dentro de OPNsense.
OPNsense integra Suricata como motor IDS/IPS mediante un paquete adicional, permitiendo utilizar el firewall como una plataforma de monitoreo de seguridad de red sin necesidad de desplegar un sensor independiente.
Antes de comenzar la configuración es importante aclarar una diferencia que puede generar confusión durante la instalación.
Plugins vs Packages en OPNsense
Dentro de OPNsense existen dos secciones relacionadas con componentes adicionales:
System
→ Firmware
→ Plugins
→ Packages
Los Plugins corresponden principalmente a extensiones empaquetadas para OPNsense que agregan funcionalidades adicionales al sistema.
Los Packages corresponden a paquetes instalables disponibles desde los repositorios del sistema.
Durante esta implementación Suricata no aparecía dentro de la sección Plugins, pero sí estaba disponible como paquete:
suricata
Version: 8.0.6
Repository: OPNsense
License: GPLv2
Comment:
High Performance Network IDS, IPS and Security Monitoring engine
Al estar disponible únicamente dentro de Packages, esto indica que el motor Suricata ya estaba integrado como paquete del sistema.
System
└── Firmware
└── Packages
└── suricata
En algunas versiones de OPNsense Suricata puede aparecer directamente dentro de Plugins como “os-suricata”, mientras que en otras instalaciones el motor se administra como paquete base.
La funcionalidad final es la misma: disponer del motor Suricata integrado dentro del firewall.
Verificando la instalación
Desde:
System
→ Firmware
→ Packages
confirmamos que Suricata se encontraba instalado.
La opción disponible era:
Reinstall
Esto confirmó que el paquete ya estaba presente en el sistema y no era necesario realizar una nueva instalación, después de esta validación accedemos al menú donde OPNsense expone la administración del IDS:
Services
→ Intrusion Detection
Dentro de esta sección encontramos:
Administration
Policy
Log File
La instalación del motor estaba completada y el siguiente paso era realizar la configuración inicial.
Configuración inicial de Suricata
Dentro de:
Services
→ Intrusion Detection
→ Administration
→ Settings
Configuración aplicada
| Parámetro | Valor |
|---|---|
| Enabled | Activado |
| Capture mode | Netmap IPS |
| Interface | LAN |
| Home networks | 10.0.0.0/8 |
| Detect Profile | Default |
| Pattern matcher | Default |
La arquitectura queda:
Red Homelab SOC
│
10.0.100.0/24
│
OPNsense LAN
│
Suricata IDS
│
Reglas de detección
│
Alertas SOC
Suricata quedó instalado y configurado dentro de OPNsense, el siguiente paso será descargar y activar las reglas de detección que permitirán identificar actividades como escaneos, explotación de vulnerabilidades, malware y comunicaciones sospechosas.
Descargando las reglas de Suricata
Con el motor Suricata instalado y la configuración inicial completada, el siguiente paso es incorporar las reglas que permitirán detectar comportamientos sospechosos dentro del tráfico de red.
Suricata por sí solo no sabe qué debe buscar.
El motor funciona mediante un conjunto de reglas que contienen patrones conocidos relacionados con:
- Escaneos de red.
- Explotación de vulnerabilidades.
- Malware.
- Comunicación con servidores de comando y control (C2).
- Actividad sospechosa en protocolos.
- Técnicas utilizadas durante ataques.
La arquitectura comienza a tomar la siguiente forma:
Tráfico de red
│
▼
OPNsense
│
▼
Motor Suricata
│
▼
Reglas de detección
│
▼
Alertas SOC
Fuentes de reglas
Suricata permite utilizar diferentes fuentes de reglas. En este laboratorio utilizaremos principalmente:
ET Open Rules
pertenecientes al proyecto:
Emerging Threats Open
Estas reglas son ampliamente utilizadas en soluciones IDS/IPS y proporcionan una buena base para un laboratorio de seguridad.
Dentro de OPNsense podemos administrarlas desde:
Services
→ Intrusion Detection
→ Administration
→ Downloads
Actualizando las reglas disponibles
Al ingresar en la sección:
Downloads
encontramos el botón:
Download & Update Rules
Este proceso realiza varias tareas:
- Descarga los repositorios configurados.
- Actualiza el catálogo disponible.
- Verifica las reglas compatibles con la versión instalada de Suricata.
Ejecutamos:
Download & Update Rules
Después de completar el proceso, OPNsense muestra las categorías disponibles.
Selección de categorías
Suricata organiza las reglas por categorías.
Algunas de las más relevantes para un laboratorio SOC son:
| Categoría | Objetivo |
|---|---|
| emerging-scan | Detección de escaneos |
| emerging-exploit | Intentos de explotación |
| emerging-malware | Actividad relacionada con malware |
| threatview_CS_c2 | Indicadores de Command & Control |
| botcc | Detección de botnets |
| web_client | Actividad sospechosa desde clientes web |
| web_server | Ataques contra servidores web |
| shellcode | Patrones relacionados con código malicioso |
Para esta primera implementación seleccioné las categorías orientadas a obtener visibilidad sobre las técnicas más comunes utilizadas durante una fase de reconocimiento y ataque.
La selección inicial fue:
ET open/emerging-scan
ET open/emerging-exploit
ET open/emerging-exploit_kit
ET open/emerging-malware
ET open/threatview_CS_c2
ET open/botcc
ET open/emerging-shellcode
ET open/emerging-web_client
ET open/emerging-web_server
¿Por qué no activar todas las reglas?
Una pregunta habitual al configurar un IDS es:
¿Por qué no activar todas las reglas disponibles?
Aunque Suricata dispone de miles de reglas, activar todo desde el inicio no siempre es recomendable.
Existen varios motivos:
Rendimiento
Cada regla representa una condición adicional que debe evaluarse contra el tráfico.
En un entorno empresarial con miles de equipos existen equipos dedicados exclusivamente al procesamiento IDS.
En nuestro caso utilizamos un entorno virtualizado:
Host:
Arch Linux
Virtualización:
VirtualBox
Firewall:
OPNsense
IDS:
Suricata
Por lo tanto es importante mantener un equilibrio entre visibilidad y consumo de recursos.
Preparando las pruebas de detección
Con Suricata activo y las reglas cargadas, el siguiente paso será comprobar que realmente pueda detectar actividad sospechosa.
Para ello utilizaremos técnicas controladas dentro del laboratorio:
- Escaneo de puertos con Nmap.
- Generación de tráfico sospechoso.
- Validación desde el panel de alertas.
El objetivo será comprobar el flujo completo:
Kali Linux
↓
Actividad sospechosa
↓
OPNsense
↓
Suricata
↓
Regla activada
↓
Alerta IDS
Las reglas de Suricata fueron descargadas correctamente y el motor ya cuenta con firmas suficientes para comenzar las primeras pruebas de detección.
Primeras pruebas de detección con Suricata
Después de instalar las reglas de detección, el siguiente paso era validar que Suricata realmente estuviera inspeccionando el tráfico del laboratorio y generando eventos de seguridad.
En un entorno SOC no basta únicamente con instalar una herramienta. Es necesario comprobar todo el ciclo:
Generación de actividad
↓
Captura del tráfico
↓
Análisis mediante Suricata
↓
Evaluación de reglas
↓
Generación de alerta
Para estas pruebas utilizaremos Kali Linux como equipo de simulación de actividad ofensiva.
La arquitectura utilizada es:
Kali Linux
10.0.100.100
│
│
Escaneo Nmap
│
▼
OPNsense
10.0.100.1
│
▼
Suricata IDS
│
▼
Alertas
Primera prueba: escaneo con Nmap
Desde Kali Linux ejecutamos un escaneo básico contra el firewall OPNsense.
nmap -sS 10.0.100.1
El resultado fue:
Nmap scan report for soc-fw.homelab.local (10.0.100.1)
Host is up.
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
El escaneo funcionó correctamente desde la perspectiva de red.
Revisando las alertas de Suricata:
Services
→ Intrusion Detection
→ Administration
→ Alerts
y aparecieron las primeras detecciones.
2026-07-20T19:44:24
SID:
2024364
Action:
allowed
Interface:
LAN
Source:
10.0.100.100
Destination:
10.0.100.1
Destination Port:
80
Signature:
ET SCAN Possible Nmap User-Agent Observed
Analizando la alerta
Esta alerta contiene información importante para un analista SOC.
Vamos a dividirla.
Timestamp
2026-07-20T19:44:24
Indica el momento exacto en que ocurrió la detección.
Esto permite correlacionar eventos con otras fuentes como:
- Wazuh.
- Logs del sistema.
- Eventos de endpoints.
Signature
ET SCAN Possible Nmap User-Agent Observed
Esta es la regla que activó la alerta.
Pertenece a:
ET open/emerging-scan
Su objetivo es identificar actividad relacionada con reconocimiento.
Source
10.0.100.100
Corresponde a:
Kali Linux
Dentro del laboratorio representa el equipo atacante.
Destination
10.0.100.1
Corresponde a:
OPNsense Firewall
El objetivo del escaneo.
Action
allowed
Este punto es importante, la alerta fue generada, pero el tráfico no fue bloqueado.
Esto ocurre porque actualmente Suricata está funcionando como:
IDS
no como:
IPS preventivo
La función actual es:
Detectar
↓
Registrar
↓
Generar alerta
Más adelante podremos analizar políticas de bloqueo.
Probando tráfico contra otros equipos
Después de validar contra OPNsense se realizaron pruebas contra otros equipos:
Windows 11
10.0.100.20
y:
Ubuntu Server
10.0.100.30
La expectativa era observar alertas similares, sin embargo, inicialmente no aparecían eventos.
Esto llevó a una fase de investigación.
Investigación del tráfico hacia Windows
Desde Kali Linux se ejecutó:
nmap -sS 10.0.100.20
Resultado inicial:
Host is up.
All 1000 scanned ports
are in ignored states.
1000 filtered tcp ports
(no-response)
Desde la perspectiva de Nmap, el equipo estaba activo pero no respondía.
La primera hipótesis fue:
Windows Defender Firewall
bloqueando las solicitudes.
Validando con Packet Capture
Se realizó una captura directamente en OPNsense.
Resultado:
El tráfico de Windows no mostraba el escaneo esperado.
En cambio aparecían principalmente:
ARP requests
y
conexiones HTTPS hacia Internet
Ejemplo:
10.0.100.20:58563 > 172.64.41.3:443
Esto indicaba que:
- Windows tenía conectividad.
- OPNsense veía tráfico normal.
- Pero el escaneo Nmap no estaba atravesando la interfaz esperada.
Desactivando temporalmente Windows Firewall
Para descartar el firewall del sistema operativo se deshabilitó temporalmente la protección de red de Windows.
Después se ejecutó nuevamente:
nmap -sS 10.0.100.20
El resultado cambió:
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Ahora Windows respondía correctamente, sin embargo, Suricata todavía no generaba alertas.
Conclusión de la primera fase de pruebas
Durante esta validación se confirmó:
✅ Suricata estaba instalado correctamente.
✅ Las reglas Emerging Threats funcionaban.
✅ OPNsense estaba capturando tráfico.
✅ Las alertas IDS funcionaban con tráfico hacia el firewall.
Pero también apareció una nueva pregunta:
¿Por qué Suricata detecta tráfico dirigido al propio firewall pero no todos los equipos de la LAN?
La respuesta está relacionada con la arquitectura de red utilizada en VirtualBox y cómo circula el tráfico dentro de una red interna. Esta investigación será importante porque reproduce un escenario muy común en redes reales:
Tener un IDS instalado no garantiza que esté viendo todo el tráfico necesario.
La primera alerta real de Suricata fue generada correctamente utilizando Nmap desde Kali Linux. Con esto comprobamos que el motor IDS, las reglas y la captura funcionan correctamente.
Investigando por qué Suricata no detectaba todo el tráfico
Después de obtener la primera alerta con Nmap contra OPNsense, surgió una situación interesante. El motor IDS funcionaba correctamente, pero únicamente generaba eventos cuando el tráfico tenía como destino el propio firewall.
Las pruebas contra otros equipos del laboratorio no producían alertas.
Los objetivos probados fueron:
OPNsense
10.0.100.1
Windows 11
10.0.100.20
Ubuntu Server
10.0.100.30
La diferencia era clara:
| Objetivo | Resultado |
|---|---|
| OPNsense | Generaba alertas |
| Windows 11 | Sin alertas |
| Ubuntu Server | Sin alertas |
Esto indicaba que el problema no estaba en:
- Las reglas.
- La instalación de Suricata.
- El motor de detección.
El problema estaba relacionado con la visibilidad del tráfico.
Entendiendo cómo funciona un IDS en una red
Una idea importante en seguridad de redes es:
Un IDS solamente puede detectar aquello que puede observar. Suricata no analiza mágicamente todos los paquetes de la red, debe recibir una copia del tráfico mediante una interfaz donde esos paquetes circulen.
La arquitectura actual del laboratorio es:
Internet
│
NAT VirtualBox
│
WAN
OPNsense
LAN
│
Red Interna HomelabSOC
│
┌───────────────┼───────────────┐
│ │ │
Kali Windows Ubuntu
10.0.100.100 10.0.100.20 10.0.100.30
A primera vista parece correcto, sin embargo, existe un detalle importante.
Tráfico hacia Internet vs tráfico interno
Cuando Kali Linux accede a Internet, el flujo es:
Kali Linux
10.0.100.100
│
▼
OPNsense LAN
10.0.100.1
│
▼
OPNsense WAN
10.0.2.15
│
▼
Internet
Todo el tráfico pasa por OPNsense. Por eso Suricata puede verlo.
Ejemplo:
Kali Linux
↓
Navegación web
↓
OPNsense
↓
Internet
Pero cuando Kali escanea Windows:
Kali Linux
10.0.100.100
│
│
▼
Windows 11
10.0.100.20
ambos equipos pertenecen a la misma red:
10.0.100.0/24
Por lo tanto la comunicación ocurre directamente dentro del segmento LAN. El tráfico no necesita pasar por el gateway.
La comunicación real es:
Kali
│
│ tráfico directo
│
Windows
OPNsense solamente actúa como gateway para salir de la red.
¿Por qué el firewall no ve ese tráfico?
En una red Ethernet tradicional: Cada equipo aprende las direcciones MAC mediante ARP.
Ejemplo:
Kali consulta:
¿Quién tiene 10.0.100.20?
Windows responde:
10.0.100.20 pertenece a MAC XX:XX:XX
Después ambos equipos se comunican directamente. El firewall queda fuera del camino.
La comunicación queda:
Kali MAC
↓
Switch / Red interna
↓
Windows MAC
No:
Kali
↓
OPNsense
↓
Windows
Por eso Suricata no genera alertas.
Confirmando con Packet Capture
Para comprobarlo utilizamos:
Interfaces
→ Diagnostics
→ Packet Capture
Seleccionamos:
Interface:
LAN
Durante el escaneo contra Windows no aparecieron paquetes TCP relacionados con Nmap.
Lo que sí apareció fue tráfico normal:
ARP
HTTPS
DNS
Conexiones hacia Internet
Ejemplo:
10.0.100.20:58563 > 172.64.41.3:443
Esto confirmó que:
- Windows tenía conectividad.
- La interfaz LAN funcionaba.
- Suricata estaba observando.
- Pero el escaneo no atravesaba OPNsense.
Comparación con un entorno empresarial
Este comportamiento también ocurre en redes reales.
Imaginemos:
Usuario A
│
│ tráfico lateral
│
Servidor interno
Si ambos están en la misma VLAN:
VLAN 10
10.10.10.0/24
el firewall perimetral tampoco verá necesariamente esa comunicación.
Por este motivo las organizaciones implementan controles adicionales:
- Segmentación de VLAN.
- Firewalls internos.
- Network TAP.
- Port Mirroring.
- Sensores IDS distribuidos.
Un SOC real necesita visibilidad completa.
Opciones para mejorar la visibilidad
Opción 1 — Utilizar OPNsense como punto obligatorio de tránsito
La arquitectura sería:
Kali
│
▼
OPNsense
│
▼
Windows
Esto implica separar redes:
LAN usuarios
10.0.100.0/24
DMZ servidores
10.0.200.0/24
Todo tráfico entre segmentos pasa por el firewall.
Ventaja: Mayor visibilidad.
Desventaja: Requiere rediseñar la arquitectura.
Opción 2 - ¿?
No se… No se me ocurre nada. Tendré que investigar.
Decisión para el Homelab SOC
Por ahora lo voy a dejar así, no vamos a tener atacante en la red interna. El objetivo de esta fase no es únicamente instalar herramientas, sino comprender cómo funcionan realmente dentro de una infraestructura.
La situación encontrada representa una enseñanza importante:
Tener un IDS instalado no significa automáticamente tener visibilidad completa de la red.
En el estado actual Suricata puede detectar:
- Tráfico hacia el firewall.
- Tráfico hacia Internet.
- Comunicaciones que atraviesan OPNsense.
Pero no necesariamente:
- Tráfico directo entre equipos dentro de la misma LAN.
Validando que Suricata funciona correctamente
Aunque no detectó todos los escenarios esperados, las pruebas confirmaron:
✓ Motor Suricata operativo
✓ Reglas Emerging Threats cargadas
✓ Interfaz LAN monitorizada
✓ Alertas generadas
✓ Detección de Nmap funcionando
La alerta obtenida:
ET SCAN Possible Nmap User-Agent Observed
demuestra que el pipeline completo funciona.
Lección aprendida
Durante esta implementación apareció un concepto fundamental para un analista SOC:
La visibilidad es el primer control de seguridad
Antes de pensar en detecciones avanzadas, correlación o automatización, es necesario responder:
¿Estoy viendo realmente el tráfico que necesito proteger?
Un IDS mal ubicado puede estar correctamente configurado y aun así no detectar eventos importantes. La ubicación del sensor es tan importante como las reglas utilizadas.
La investigación permitió identificar que la ausencia de alertas no estaba causada por una falla de Suricata, sino por la forma en que circula el tráfico dentro de una red LAN.
Esta validación acerca el laboratorio a situaciones reales donde la arquitectura de red determina la capacidad de detección de un SOC.
Preparando la integración con Wazuh
Después de completar la instalación de Suricata dentro de OPNsense y validar sus primeras detecciones, el siguiente paso natural dentro del Homelab SOC será integrar estos eventos dentro de la plataforma SIEM.
Actualmente tenemos dos fuentes principales de información:
Endpoint Monitoring
│
▼
Wazuh
│
▼
Logs de sistemas operativos
y:
Network Monitoring
│
▼
Suricata
│
▼
Alertas de red
Cada herramienta proporciona una perspectiva diferente.
¿Por qué integrar Suricata con Wazuh?
Un SOC no analiza eventos aislados. El verdadero valor aparece cuando diferentes fuentes de información pueden ser correlacionadas.
Por ejemplo:
Suricata puede detectar:
ET SCAN Possible Nmap User-Agent Observed
Origen:
10.0.100.100
(Kali Linux)
Destino:
10.0.100.20
(Windows 11)
Pero Wazuh puede aportar información adicional:
Windows 11
Usuario conectado
Procesos ejecutados
Cambios en archivos
Eventos de seguridad
La combinación permite responder preguntas más completas:
- ¿Quién realizó el escaneo?
- ¿Desde qué equipo?
- ¿Qué ocurrió después?
- ¿Se ejecutó algún proceso sospechoso?
- ¿Existe compromiso del endpoint?
Lo aprendido
En este capítulo incorporamos una nueva capa de seguridad dentro del Homelab SOC mediante la instalación e integración inicial de Suricata sobre OPNsense.
Durante el proceso aprendimos que implementar un IDS no consiste únicamente en instalar un paquete y activar reglas.
Fue necesario comprender varios conceptos fundamentales:
- Diferencia entre instalación del motor y configuración del servicio.
- Importancia de seleccionar correctamente las interfaces monitorizadas.
- Funcionamiento de las reglas Emerging Threats.
- Interpretación de alertas IDS.
- Diferencia entre detección y prevención.
- Importancia de la ubicación del sensor dentro de la arquitectura de red.
Uno de los aprendizajes más importantes apareció durante las pruebas con Nmap. Inicialmente parecía que Suricata no estaba funcionando porque no generaba alertas contra todos los equipos del laboratorio.
Después del análisis mediante Packet Capture descubrimos que el problema no estaba en Suricata, sino en la forma en que funciona una red LAN.
Cuando dos equipos pertenecen al mismo segmento:
10.0.100.0/24
pueden comunicarse directamente sin atravesar el firewall.
Esto demuestra un principio fundamental en seguridad:
La capacidad de detección depende directamente de la visibilidad que tenga el sensor.
Un IDS correctamente configurado pero ubicado en un punto incorrecto puede dejar tráfico importante sin analizar.
Próximo capítulo
Con Suricata funcionando como sensor de red, el siguiente paso será centralizar sus eventos dentro del SIEM.
En el próximo capítulo realizaremos:
- Identificación de logs generados por Suricata.
- Configuración del envío de eventos hacia Wazuh.
- Creación de reglas y decoders.
- Visualización de alertas dentro del dashboard.
- Correlación entre eventos de red y eventos de endpoint.
Con esta integración el Homelab SOC comenzará a comportarse como una arquitectura real de monitoreo, donde la información de red y los eventos de los sistemas operativos se analizan desde una única plataforma.
Suricata quedó operativo dentro del Homelab SOC y preparado para convertirse en una fuente adicional de inteligencia para Wazuh.
La siguiente fase permitirá transformar estas alertas aisladas en eventos centralizados y correlacionados dentro del SIEM.