Contexto y objetivo
Construí un laboratorio doméstico para practicar la administración de sistemas y la investigación de alertas en equipos propios. El objetivo es seguir una señal desde su origen hasta su consulta en Wazuh, entendiendo qué se ha detectado y qué información falta para interpretarla.
El entorno combina Windows, una Raspberry Pi con Linux y un servidor Wazuh virtualizado. También incorporé la supervisión de las copias de seguridad: la disponibilidad de los datos forma parte del trabajo defensivo.
Arquitectura
- Windows: agente Wazuh y Sysmon como fuentes de eventos del equipo.
- Raspberry Pi 5: sensor Suricata y agente Wazuh para recoger registros de Linux y del IDS.
- Switch gestionable: duplica el tráfico del puerto del PC hacia el sensor en ambos sentidos.
- Máquina virtual: aloja Wazuh Manager, Indexer y Dashboard en VirtualBox sobre el PC.
El switch envía una copia del tráfico del PC a Suricata. Su registro EVE y los eventos de Linux llegan a Wazuh mediante el agente de la Raspberry. El agente de Windows aporta los eventos del equipo. El servidor permite consultar ambas fuentes.
El diagrama se carga al entrar en esta sección.
flowchart TD P["Tráfico del PC"] --> M["Duplicado en switch"] M --> S["Suricata y registro EVE"] S --> A["Agente Linux"] L["Eventos Linux y copias"] --> A W["Windows y Sysmon"] --> B["Agente Windows"] A --> C["Servidor Wazuh"] B --> C C --> D["Consulta en Dashboard"]El esquema resume la recogida de eventos; no implica que exista una regla de correlación conjunta entre todas las fuentes.
Una detección de principio a fin
La prueba documentada utiliza una respuesta HTTP local preparada para activar una firma de Suricata. Es una simulación controlada, realizada en el laboratorio, sin explotar un sistema ni representar un compromiso real.
Demostración interactiva
Del tráfico de prueba a la alerta
Explora las cinco etapas de una prueba controlada de mi SOC. Los campos son un resumen didáctico de las comprobaciones documentadas, no registros en directo.
Etapa 1 de 5
Preparo la señal
Genero una respuesta HTTP controlada para comprobar que el laboratorio puede detectar un patrón conocido.
- Señal o evidencia
- Respuesta HTTP de prueba dentro de un entorno propio.
- Qué compruebo
- Todavía no hay una alerta: este es el punto de partida.
Etapa 2 de 5
El sensor recibe el tráfico
El switch envía a la Raspberry una copia del tráfico del PC. Suricata puede analizarla sin estar en el camino de la conexión.
- Señal o evidencia
- Tráfico del PC → mirroring → sensor de red.
- Qué compruebo
- Compruebo que la copia llega al sensor antes de interpretar alertas.
Etapa 3 de 5
Suricata reconoce la firma
La respuesta de prueba activa la firma 2100498 y el evento queda registrado en EVE JSON.
- Señal o evidencia
- Firma 2100498 · acción allowed · registro EVE JSON.
- Qué compruebo
- Allowed significa que el tráfico pasó. Aquí Suricata detecta, no bloquea.
Etapa 4 de 5
La alerta llega al dashboard
El agente de la Raspberry recoge el evento y lo envía al servidor Wazuh para consultarlo.
- Señal o evidencia
- Regla Wazuh 86601 · nivel 3 · origen: sensor Linux.
- Qué compruebo
- Puedo seguir la misma señal desde Suricata hasta Wazuh.
Etapa 5 de 5
Interpreto el resultado
Reviso de dónde viene el aviso, qué regla se ha activado y qué significa su acción.
- Señal o evidencia
- Cadena comprobada: prueba → Suricata → agente → Wazuh.
- Qué compruebo
- Registro el resultado y separo la detección de una posible respuesta. No se ha producido un incidente real.
El resultado confirma el recorrido de esa señal desde el sensor hasta Wazuh. No demuestra por sí solo la detección de un ataque completo.
Supervisión de las copias
El monitor de copias genera eventos JSON ante fallos y recuperaciones. Integré su lectura en el agente de Linux y validé reglas locales con wazuh-logtest. La documentación recoge avisos por ausencia del disco de copias y por recuperación, consultables en el dashboard.
Esto permite practicar el mismo método con una incidencia operativa: identificar el problema, comprobar el evento y verificar que se registra la vuelta al estado correcto.
Ensayo independiente en Windows
También documenté una prueba benigna con PowerShell codificado. Según el registro del laboratorio, Wazuh recibió una alerta de la regla 92057, nivel 12, clasificada con MITRE T1059.001. Es una comprobación de la fuente Sysmon/EventChannel, distinta de las pruebas de Suricata y de la detección HTTP descrita arriba. No es un ataque real ni prueba que el tráfico fuese bloqueado. La imagen seleccionada muestra el comando de prueba, no el evento recibido en Wazuh.
Evidencias visuales
Las siguientes son fotografías y capturas históricas revisadas. El aviso de Home Assistant muestra datos de monitorización no recientes tras interrumpir el monitor; no demuestra que todos los servicios Wazuh se detuvieran.
Selecciona una imagen para ampliarla. En el visor puedes usar las flechas y cerrar con Esc.
Decisiones y aprendizaje
- Separar detección y bloqueo para interpretar las alertas sin atribuir al IDS una respuesta que no realiza.
- Centralizar registros conservando su origen: un evento de red y uno de endpoint aportan perspectivas diferentes.
- Llevar los logs de Suricata al SSD y comprobar su rotación para gestionar el crecimiento del almacenamiento.
- Comprobar cada tramo de la integración antes de ampliar las reglas o los paneles.
Alcance y límites
El servidor Wazuh depende del PC que aloja la máquina virtual; su disponibilidad no es continua cuando el PC está apagado. El duplicado verificado corresponde al tráfico del PC, no a toda la red Wi-Fi. Esta prueba HTTP tampoco acredita inspección del contenido HTTPS ni ausencia permanente de pérdida de paquetes.
La ficha resume las comprobaciones recogidas en la documentación del laboratorio hasta el 25 de octubre de 2026. La galería utiliza tres copias revisadas y sin metadatos privados; las alertas completas con identificadores quedan fuera de la web. El panel operativo permanece privado.
La infraestructura que hace posible la captura y el acceso remoto se explica en el caso de red y servicios domésticos.