Laboratorio SIEM con Wazuh

Resumen — Arquitectura de un SIEM Wazuh de un solo nodo para proteger a una empresa ficticia de 40 personas: telemetría de Windows (Sysmon), Linux (auditd) y del firewall, ocho casos de uso de detección mapeados a MITRE ATT&CK, herramientas con versiones fijadas y un sistema de medición probado. Entregable: arquitectura, herramientas y pruebas, listas para construir; resultados del laboratorio aún sin medir.

1. Problema

• Contexto: una empresa ficticia de servicios profesionales con 40 personas tiene un dominio Windows, un servidor Linux y un firewall perimetral. Los registros se quedan en cada máquina y nadie los revisa.
• Por qué importa: el robo de credenciales, la persistencia y el abuso de privilegios pasarían inadvertidos durante semanas. La empresa no puede pagar un SIEM comercial ni un SOC 24/7.
• Objetivos:
  1. Centralizar la telemetría de Windows, Linux y el firewall en un SIEM de código abierto.
  2. Detectar 8 comportamientos de atacantes relevantes para una empresa de este tamaño, mapeados a MITRE ATT&CK.
  3. Mantener un volumen de alertas que una sola persona a tiempo parcial pueda revisar a diario.
  4. Hacer que todo el laboratorio sea reproducible desde el repositorio.
• Alcance y restricciones: solo herramientas de código abierto; licencias de evaluación para Windows; todo se ejecuta en un laboratorio aislado sin ruta hacia ninguna red de producción.
• Criterios de éxito: cada caso de uso tiene un resultado de detección registrado; el volumen diario de alertas se mide antes y después del ajuste; la construcción es reproducible con los scripts del repositorio.

2. Arquitectura

• Flujos de datos: agentes → wazuh01 por 1514/tcp (protocolo cifrado del agente); fw01 → wazuh01 por syslog 514/udp; analista → dashboard de Wazuh por 443/tcp, solo desde la VLAN de gestión.

3. Construcción

1. Requisitos — host Proxmox con ≥32 GB de RAM; bridge/VLAN aisladas 20, 30 y 99; ISO de evaluación de Windows Server 2022 y Windows 11; ISO de Ubuntu 24.04; el firewall OPNsense del Lab 02.
2. Servidor Wazuh — en wazuh01 ejecuta scripts/deploy/install-wazuh.sh. Descarga el instalador oficial 4.14.8, verifica su SHA-256 e instala el indexador, el servidor y el dashboard. Guarda la contraseña de administrador generada en un gestor de contraseñas.
3. Agentes — inscribe dc01, ws01 y srv01 siguiendo la documentación oficial de agentes de Wazuh 4.14; la configuración de recolección está en configs/agents/.
4. Sysmon — instálalo en dc01 y ws01 con la configuración fijada de sysmon-modular (configs/sysmon/README.md).
5. Registros del firewall — configura el syslog remoto de OPNsense hacia wazuh01 (Lab 02, guía 08).
6. Línea base — deja el laboratorio funcionando con actividad normal durante una semana y exporta el conteo diario de alertas con scripts/report/export_alert_metrics.py.

Notas de construcción: los imprevistos y sus soluciones se registran en docs/build-notes.md.

4. Plan de detección

Cada caso de uso indica el host donde se ejecuta, el comportamiento a detectar y la telemetría que lo hace visible. Los casos de uso se ejecutan únicamente dentro del laboratorio aislado (snapshot de la VM antes y reversión después), siguiendo la documentación oficial de Atomic Red Team para la versión fijada; los resultados se registran en tests/test-plan.md.

5. Entregables y medición

Entregado en este repositorio:

• Arquitectura y dimensionamiento de un laboratorio de cinco VM y tres VLAN (diagrama).
• Plan de detección: ocho casos de uso mapeados a MITRE ATT&CK y a la telemetría que necesita cada uno.
• Un instalador de Wazuh 4.14.8 con versión fijada que verifica el checksum del proveedor antes de ejecutarse.
• Un sistema de reportes probado en CI: export_alert_metrics.py exporta el conteo diario de alertas del indexador de Wazuh y coverage_table.py convierte el plan de pruebas y esas exportaciones en las tablas de resultados.

Cómo se miden los resultados (python scripts/report/coverage_table.py):

La cobertura solo se reporta cuando todos los casos de uso tienen un resultado registrado, de modo que nunca se puede calcular a partir de un subconjunto favorable de pruebas.

6. Lecciones de diseño y hoja de ruta

• Fija las versiones y verifica lo que descargas. Un instalador "latest" hace imposible reproducir un laboratorio meses después. Fijar Wazuh 4.14.8 y comprobar el SHA-256 del instalador convierte un cambio silencioso del proveedor en una detención visible.
• Revisa los límites de licencia antes de diseñar alrededor de un producto. La prueba gratuita de FortiGate-VM solo permite tres interfaces, políticas y rutas, y no recibe actualizaciones de FortiGuard; por eso la fuente de registros del firewall usa OPNsense (Lab 02), que no tiene esos límites. La ruta de syslog no cambia si más adelante se usa un FortiGate con licencia.
• Planifica la telemetría antes que las reglas. La mayoría de los casos de uso de Windows dependen de que Sysmon, la política de auditoría avanzada y el registro de bloques de script de PowerShell estén activos; sin ellos, una regla no tiene nada que detectar. Por eso cada caso de uso indica su fuente de telemetría.
• Dimensiona primero el SIEM. Solo el indexador de Wazuh necesita 8 GB de RAM y el laboratorio completo unos 19 GB, lo que define el requisito de un host con ≥32 GB.
• Define las métricas antes de recolectar datos. Escribir las definiciones de cobertura y volumen de alertas (y la regla de no reportar resultados parciales) antes de cualquier prueba mantiene los resultados honestos.

Hoja de ruta: construir el laboratorio a partir de este diseño, recolectar una semana de línea base, ejecutar los ocho casos de uso, escribir reglas personalizadas para las brechas, ajustar y publicar aquí los resultados medidos de cobertura y volumen de alertas.

7. Reprodúcelo tú mismo

• Clonar: git clone https://github.com/santorest/lab-01-wazuh-siem.git
• Descargar el paquete: desde el sitio del portafolio (el SHA-256 aparece junto a la descarga).
• Tiempo estimado: 1–2 días de construcción, más una semana de línea base.
• Limpieza: elimina las VM del laboratorio y el bridge aislado; no se usan recursos en la nube.

8. Mapeo

Todas las pruebas se realizan en un entorno de laboratorio aislado de mi propiedad. No se incluyen datos, nombres de host ni configuraciones de ninguna organización real.