Wazuh:

montar un SIEM/XDR open source en tu laboratorio

Serie Blue Team  |  unfantasmaenelsistema.com

En los artículos anteriores de la serie fuimos generando telemetría: Sysmon aportando eventos de proceso, red e inyección; los canales nativos de Windows con sus Event ID; auditd en Linux. Todo eso produce miles de líneas al día repartidas por cada equipo. El paso que falta es el sitio donde esa telemetría se centraliza, se normaliza, se compara con reglas de detección y se convierte en alertas priorizadas. Ese sitio, en un montón de SOC reales y en casi cualquier laboratorio doméstico, es Wazuh.

Wazuh es una plataforma libre (licencia GPLv2) que nació como un fork de OSSEC y hoy combina HIDS, gestión de logs, detección basada en reglas, monitorización de integridad de ficheros, evaluación de configuración y un módulo que mapea cada alerta contra MITRE ATT&CK. Se suele describir como SIEM y, desde que incorporó respuesta activa y capacidades de endpoint, también como XDR. Este artículo es una guía para levantarlo en un laboratorio propio, entender sus piezas y escribir tus primeras reglas y detecciones.

1. Arquitectura: las cuatro piezas

Wazuh tiene una arquitectura clara una vez se separan sus componentes. El flujo de un evento va siempre en la misma dirección: se genera en el endpoint, el agente lo envía cifrado al servidor, el servidor lo analiza y decide si es una alerta, y el resultado se almacena e indexa para que el panel lo muestre y se pueda buscar sobre él.

En produccion cada pieza se despliega por separado y el indexador se agrupa en cluster. En un laboratorio se instala todo en una sola maquina virtual con el instalador todo-en-uno, que en unos minutos deja el servidor, el indexador y el panel funcionando sobre la misma VM.

2. Despliegue todo-en-uno para el laboratorio

Necesitas una VM con una distribucion soportada (Ubuntu 22.04/24.04, Debian 12, RHEL/Alma/Rocky 8-9), al menos 4 vCPU y 8 GB de RAM (16 GB si vas a tener varios agentes y retienes datos), y unos 50 GB de disco. El indexador es lo que mas RAM consume por la JVM.

# --- Instalador todo-en-uno (servidor + indexador + panel) ---
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash ./wazuh-install.sh -a -i
 
# Al terminar imprime la contrasena del usuario 'admin'.
# Panel: https://<IP-de-la-VM>  (certificado autofirmado en el lab)
 
# Recuperar credenciales mas tarde:
sudo tar -O -xf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Para instalar el agente en un endpoint se descarga el paquete de la plataforma y se le indica la IP del servidor. El panel tiene un asistente en Agents > Deploy new agent que genera el comando exacto con la clave de registro.

# --- Agente en Linux (Debian/Ubuntu) ---
WAZUH_MANAGER='192.168.56.20' apt-get install wazuh-agent
systemctl enable --now wazuh-agent
 
# --- Agente en Windows (PowerShell como admin) ---
# msiexec /i wazuh-agent-4.x.msi /q WAZUH_MANAGER='192.168.56.20'
# NET START WazuhSvc
 
# En el servidor, comprobar que el agente aparece 'Active':
sudo /var/ossec/bin/agent_control -l

3. Qué recolecta el agente

El comportamiento del agente se define en su fichero ossec.conf (y, de forma centralizada, en los grupos de agentes desde el servidor, en /var/ossec/etc/shared/). Lo que recoge por defecto y lo que se suele anadir:

En Windows, el par natural es Sysmon + Wazuh: Sysmon produce la telemetria rica (hashes, arbol de procesos, conexiones por proceso) y Wazuh la recoge, la normaliza y le aplica reglas. La configuracion de Sysmon se cubre en su articulo dedicado de esta serie.

4. Decoders y reglas: cómo un log se convierte en alerta

Cuando un evento llega al servidor pasa por dos etapas. Primero un decoder extrae los campos (usuario, IP de origen, ID de evento, ruta del fichero…) a partir del texto crudo. Despues, el motor de reglas compara esos campos con condiciones y, si alguna coincide, genera una alerta con un nivel del 0 al 15.

Las reglas base viven en /var/ossec/ruleset/rules/ y no se editan: se actualizan con el paquete. Tus reglas propias van en /var/ossec/etc/rules/local_rules.xml, y tus decoders propios en /var/ossec/etc/decoders/local_decoder.xml. Una regla propia suele construirse encima de una existente con if_sid (dispara solo si antes disparo tal regla) o if_group.

<!-- /var/ossec/etc/rules/local_rules.xml -->
<!-- Elevar a nivel alto un 4104 de PowerShell con nivel Warning -->
<group name="local,powershell,">
 
  <rule id="100210" level="12">
    <if_sid>91802</if_sid>            <!-- regla base de Script Block Logging -->
    <field name="win.system.level">3</field>
    <description>PowerShell: bloque de script marcado como sospechoso (4104 Warning)</description>
    <mitre><id>T1059.001</id></mitre>
  </rule>
 
  <!-- Ignorar el ruido de una tarea programada interna conocida -->
  <rule id="100211" level="0">
    <if_sid>92100</if_sid>
    <field name="win.eventdata.image">C:\\ProgramData\\miapp\\updater\.exe</field>
    <description>Updater interno de MiApp: comportamiento esperado</description>
  </rule>
 
</group>

5. Más allá de los logs: FIM, rootcheck, SCA e inventario

Wazuh no solo lee logs. El agente lleva varios modulos que generan sus propios eventos y que, en un laboratorio, son de lo mas util para practicar deteccion.

5.1 Integridad de ficheros (FIM / syscheck)

El modulo syscheck vigila directorios y calcula hash, propietario, permisos y fecha de cada fichero. Cuando algo cambia, genera un evento (regla 550 modificado, 554 anadido, 553 borrado) con el antes y el despues. En modo whodata (auditd en Linux, SACL en Windows) ademas dice quien hizo el cambio y con que proceso.

<!-- ossec.conf del agente: vigilar en tiempo real y con whodata -->
<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" whodata="yes">/var/www/html</directories>
  <directories check_all="yes" realtime="yes">C:\Windows\System32\drivers\etc</directories>
  <frequency>43200</frequency>
</syscheck>

5.2 Rootcheck y detección de rootkits

El modulo rootcheck compara la lista de procesos, puertos y ficheros que ve el sistema con la que obtiene por llamadas de bajo nivel, y busca firmas conocidas de rootkits y anomalias (ficheros ocultos, PID que existen pero no aparecen en /proc, puertos abiertos que netstat no muestra).

5.3 Evaluación de configuración (SCA)

Security Configuration Assessment ejecuta politicas de bastionado (CIS Benchmarks para Windows, Linux, Docker…) y da un porcentaje de cumplimiento con el detalle de cada control que falla y como corregirlo. Es la forma mas rapida de ver el estado de hardening de una maquina del lab.

5.4 Inventario

El modulo syscollector recoge hardware, sistema operativo, paquetes instalados, puertos a la escucha y procesos. Cruzado con feeds de vulnerabilidades (Vulnerability Detection), Wazuh lista los CVE que afectan a cada agente segun sus paquetes.

6. El módulo MITRE ATT&CK

Cada regla de Wazuh puede llevar una o varias etiquetas <mitre><id>Txxxx</id></mitre>. El panel agrega esas etiquetas en una vista dedicada (MITRE ATT&CK > Framework / Intelligence / Events) donde se ve, por tactica y por tecnica, que se ha disparado, en que agente y cuando. Es el puente entre «ha saltado la regla 100210» y «estamos viendo ejecucion via interprete de comandos (T1059) en el host WIN-LAB-01».

El detalle del marco ATT&CK, sus tacticas y como se usa como lenguaje comun entre ataque y defensa se cubre en el articulo dedicado a MITRE ATT&CK de la web.

Estas tres se pueden reproducir en minutos en un laboratorio aislado (crear un servicio de prueba con sc.exe, dejar un fichero .php inocuo en el webroot, lanzar unos cuantos intentos de login fallidos contra tu propia VM) y verlas aparecer en el panel con su tecnica asociada. Sirve para entender el recorrido completo: evento -> decoder -> regla -> alerta -> ATT&CK.

7. Alertas y envío: correo, Slack y SOAR

Por defecto las alertas quedan en el panel y en /var/ossec/logs/alerts/. Para que salgan del servidor se configuran integraciones en el ossec.conf del manager:

• Correo: bloque <global> con smtp_server y email_to, y <email_alerts> por nivel o por grupo de reglas. email_alert_level 12 evita inundar el buzon
• Slack / Teams / Discord / PagerDuty: bloque <integration> con el name correspondiente y el hook_url del webhook; se puede filtrar por level, rule_id o group
• TheHive: integracion nativa para crear casos y alertas de forma automatica a partir de eventos de Wazuh
• Shuffle / n8n (SOAR): reciben el JSON de la alerta por webhook y orquestan la respuesta (enriquecer con VirusTotal, aislar el host, abrir un ticket)

<!-- /var/ossec/etc/ossec.conf (manager): alertas a Slack de nivel >= 10 -->
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/XXXX/YYYY/ZZZZ</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

8. Buenas prácticas para el laboratorio

• Empieza con un manager y dos agentes (un Windows con Sysmon, un Linux con auditd); anade complejidad solo cuando entiendas el flujo
• Usa wazuh-logtest de forma sistematica: es la manera de aprender como decodifica Wazuh cada tipo de log
• Centraliza la configuracion de agentes con grupos y el fichero agent.conf compartido; evita tocar ossec.conf equipo por equipo
• Versiona local_rules.xml, local_decoder.xml y las configuraciones compartidas en un repositorio git
• Dimensiona la retencion: en el lab, index lifecycle management borrando indices de mas de 15-30 dias evita llenar el disco
• Practica con emulacion de adversario (Atomic Red Team) contra tus propias VM y comprueba que reglas disparan y cuales faltan
• Manten Wazuh actualizado: las reglas base y los feeds de vulnerabilidades mejoran en cada version

Conclusión

Wazuh es la pieza que cierra el circuito de la serie Blue Team: recoge la telemetria que ya generaban Sysmon, los canales de Windows y auditd, la normaliza con decoders, la evalua con un ruleset extensible y la presenta como alertas priorizadas y mapeadas a ATT&CK, sin coste de licencia. Anade ademas integridad de ficheros, deteccion de rootkits, cumplimiento CIS e inventario de vulnerabilidades en el mismo agente.

Montarlo en un laboratorio aislado con un manager todo-en-uno y un par de agentes es cuestion de una tarde, y es la mejor forma de entender de verdad como una linea de log se convierte en una deteccion. A partir de ahi, cada regla que escribes y cada tecnica de Atomic Red Team que reproduces te acerca a operar un SOC pequeno con herramientas enteramente libres.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)