Wazuh: SIEM y EDR Open Source para el SOC
Guia completa de Wazuh como plataforma SIEM y EDR open source. Arquitectura (manager, agents, indexer), reglas, decoders, FIM, deteccion de vulnerabilidades, active response, despliegue con Docker y SCA.
Por que Wazuh importa
En un mercado donde las licencias EDR pueden superar los 30 EUR por endpoint al mes, Wazuh ofrece algo inusual: una plataforma de seguridad completa sin coste de licencia. No es un juguete ni un proyecto abandonado. Con mas de 10 millones de descargas y una comunidad activa, Wazuh se ha convertido en la referencia de seguridad open source para organizaciones que necesitan visibilidad sin hipotecar el presupuesto.
Pero "gratis" no significa "sin esfuerzo". Wazuh requiere conocimiento tecnico para desplegarlo, tunearlo y mantenerlo. Este articulo cubre la arquitectura, las capacidades reales y las limitaciones honestas de la plataforma.
Arquitectura de Wazuh
Wazuh sigue un modelo cliente-servidor con tres componentes principales que pueden desplegarse juntos o por separado segun las necesidades de escalabilidad.
Wazuh Manager (servidor central)
El manager es el cerebro de la operacion. Recibe datos de los agentes, aplica reglas de decodificacion y deteccion, y genera alertas. Sus funciones principales incluyen:
- Motor de analisis: procesa eventos en tiempo real aplicando decoders y reglas
- Gestion de agentes: registra, autentica y gestiona la comunicacion con cada agente
- API RESTful: expone todas las funciones de gestion via API (puerto 55000)
- Cluster mode: permite desplegar multiples managers en alta disponibilidad
El manager almacena la configuracion de reglas en /var/ossec/etc/rules/ y los decoders en /var/ossec/etc/decoders/. Cuando un evento llega de un agente, el flujo es: raw log, decodificacion (extraer campos), matching de reglas (generar alerta si aplica).
Wazuh Agent (endpoint)
El agente se instala en cada endpoint (Windows, Linux, macOS) y recopila telemetria local. No es un agente "pesado" como los EDR enterprise: su consumo tipico ronda los 50-100 MB de RAM y un uso de CPU marginal.
Modulos del agente:
| Modulo | Funcion | Plataforma |
|---|---|---|
| Log collector | Recopila logs del sistema y aplicaciones | Todas |
| Syscheck (FIM) | Monitoriza cambios en archivos y registros | Todas |
| Rootcheck | Deteccion de rootkits y anomalias | Linux, macOS |
| SCA | Evaluacion de configuracion de seguridad | Todas |
| Syscollector | Inventario de hardware, software, procesos, puertos | Todas |
| Command monitoring | Ejecuta comandos periodicos y analiza la salida | Todas |
| Osquery integration | Consultas SQL sobre el estado del sistema | Todas |
La comunicacion entre agente y manager usa el protocolo propio de Wazuh sobre el puerto 1514 (TCP o UDP), con cifrado AES-256 y autenticacion por clave precompartida.
Wazuh Indexer (almacenamiento y busqueda)
El indexer esta basado en OpenSearch (fork de Elasticsearch) y se encarga de almacenar, indexar y permitir la busqueda de todas las alertas y eventos. Es el componente que mas recursos consume, especialmente en disco.
Puntos clave del indexer:
- Indices rotativos por dia (
wazuh-alerts-4.x-YYYY.MM.DD) - Full-text search sobre todos los campos de las alertas
- Retencion configurable con ISM (Index State Management)
- Soporte para snapshots y backups incrementales
Wazuh Dashboard
El dashboard (basado en OpenSearch Dashboards) proporciona la interfaz web para visualizacion, busqueda y gestion. Incluye dashboards predefinidos para:
- Vista general de seguridad (Security Events)
- Integridad de archivos (FIM)
- Vulnerabilidades detectadas
- Compliance (PCI DSS, GDPR, HIPAA, NIST 800-53)
- MITRE ATT&CK mapping
Reglas y decoders: el motor de deteccion
El sistema de deteccion de Wazuh se basa en dos conceptos fundamentales: decoders (que extraen campos de los logs) y rules (que generan alertas basandose en esos campos).
Decoders
Un decoder toma un log en texto plano y extrae campos estructurados. Wazuh incluye mas de 500 decoders predefinidos para formatos comunes (syslog, Windows Event Log, Apache, nginx, SSH, etc.).
Ejemplo de decoder personalizado para un log de aplicacion:
<decoder name="myapp">
<program_name>myapp</program_name>
</decoder>
<decoder name="myapp-auth">
<parent>myapp</parent>
<regex>Authentication (failed|success) for user (\S+) from (\S+)</regex>
<order>status, user, srcip</order>
</decoder>
Los decoders se encadenan: primero el padre identifica el programa, luego los hijos extraen campos especificos. Este sistema de herencia permite reutilizar logica de parseo.
Rules
Las reglas de Wazuh son la capa de deteccion. Cada regla tiene un ID unico, un nivel de severidad (0-15) y condiciones de matching. Wazuh incluye mas de 4.000 reglas predefinidas.
Estructura basica de una regla:
<rule id="100001" level="10">
<decoded_as>myapp-auth</decoded_as>
<field name="status">failed</field>
<description>Failed authentication in MyApp</description>
<group>authentication_failed,</group>
<mitre>
<id>T1110</id>
</mitre>
</rule>
Niveles de severidad relevantes:
| Nivel | Significado | Ejemplo |
|---|---|---|
| 0-3 | Informativo / ruido | Login exitoso |
| 4-7 | Bajo / medio | Fallo de autenticacion aislado |
| 8-11 | Alto | Multiples fallos, cambio de configuracion critica |
| 12-15 | Critico | Rootkit detectado, integridad comprometida |
Reglas compuestas y correlacion
Wazuh soporta reglas compuestas que correlacionan multiples eventos en ventanas de tiempo:
<rule id="100002" level="12" frequency="5" timeframe="120">
<if_matched_sid>100001</if_matched_sid>
<description>Brute force attack detected on MyApp (5 failures in 2 min)</description>
<mitre>
<id>T1110.001</id>
</mitre>
</rule>
Este tipo de reglas es fundamental para detectar patrones como fuerza bruta, escaneo de puertos o movimiento lateral. La correlacion se ejecuta en el manager, no en el agente.
File Integrity Monitoring (FIM)
El modulo Syscheck de Wazuh monitoriza cambios en archivos y directorios del sistema. Es una de sus capacidades mas maduras y utiles.
Configuracion de FIM
La configuracion se define en ossec.conf del agente:
<syscheck>
<frequency>600</frequency>
<directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes" realtime="yes">/boot</directories>
<directories check_all="yes" report_changes="yes">/etc/passwd,/etc/shadow</directories>
<!-- Windows -->
<directories check_all="yes" realtime="yes">C:\Windows\System32</directories>
<directories check_all="yes">HKEY_LOCAL_MACHINE\SOFTWARE</directories>
<ignore>/etc/mtab</ignore>
<ignore type="sregex">.log$</ignore>
</syscheck>
Que monitoriza FIM
Para cada archivo o clave de registro monitorizado, Syscheck registra:
- Hash (MD5, SHA1, SHA256)
- Permisos (owner, group, mode)
- Tamano
- Timestamps (mtime, ctime, atime)
- Atributos extendidos (Windows: ACLs)
- Contenido de los cambios (si
report_changes="yes")
Cuando detecta un cambio, genera una alerta con el diff entre el estado anterior y el actual. Esto permite detectar:
- Modificacion de binarios del sistema (posible rootkit o backdoor)
- Cambios en archivos de configuracion criticos
- Creacion de nuevos ejecutables en directorios sensibles
- Modificacion de claves de registro de autoarranque (Windows)
FIM en tiempo real vs programado
Wazuh soporta dos modos de FIM:
- Programado (
frequency): escanea los directorios cada N segundos. Menor consumo de recursos - Tiempo real (
realtime="yes"): usa inotify (Linux) o ReadDirectoryChangesW (Windows) para detectar cambios al instante. Mayor consumo pero deteccion inmediata
Para entornos de produccion, la combinacion recomendada es tiempo real en directorios criticos (/etc, System32) y programado para el resto.
Deteccion de vulnerabilidades
El modulo Vulnerability Detector de Wazuh compara el inventario de software instalado (recopilado por Syscollector) contra bases de datos de vulnerabilidades conocidas.
Fuentes de vulnerabilidades
Wazuh consulta automaticamente:
- NVD (National Vulnerability Database): CVEs con puntuacion CVSS
- Canonical: USN (Ubuntu Security Notices)
- Red Hat: RHSA, RHBA advisories
- Debian: DSA (Debian Security Advisory)
- CISA KEV: vulnerabilidades activamente explotadas
- Microsoft: actualizaciones de seguridad (via Windows Update)
Como funciona
- El agente recopila el inventario de software instalado (nombre, version, arquitectura)
- El manager descarga y mantiene actualizada la base de datos de CVEs
- El motor cruza inventario contra CVEs conocidos
- Genera alertas con CVE ID, CVSS score, paquete afectado y version parcheada
Ejemplo de alerta de vulnerabilidad:
{
"rule": {
"id": "23505",
"level": 10,
"description": "CVE-2024-1234 affects openssl-3.0.2"
},
"data": {
"vulnerability": {
"cve": "CVE-2024-1234",
"cvss": 9.8,
"package": { "name": "openssl", "version": "3.0.2" },
"fix_version": "3.0.13",
"status": "Active"
}
}
}
Limitaciones
La deteccion de vulnerabilidades de Wazuh se basa exclusivamente en version matching. No verifica si la vulnerabilidad es realmente explotable en el contexto del endpoint. Esto genera falsos positivos en casos donde:
- El paquete esta instalado pero no expuesto
- Se aplico un parche sin cambiar la version (backport)
- La configuracion del sistema mitiga la vulnerabilidad
Para reducir ruido, es recomendable filtrar por CVSS score minimo y cruzar con CISA KEV para priorizar las vulnerabilidades activamente explotadas.
Active Response: respuesta automatizada
Active Response es el modulo de Wazuh que ejecuta acciones automaticas cuando se dispara una alerta. No es tan sofisticado como la respuesta autonoma de un SentinelOne, pero permite automatizar bloqueos basicos.
Acciones predefinidas
Wazuh incluye scripts de respuesta para:
| Accion | Descripcion | Plataforma |
|---|---|---|
| firewall-drop | Bloquea IP en iptables/ipfw | Linux, macOS |
| win_route-null | Ruta nula a IP atacante | Windows |
| host-deny | Anade IP a /etc/hosts.deny | Linux |
| disable-account | Deshabilita cuenta de usuario | Linux, Windows |
| restart-wazuh | Reinicia el agente Wazuh | Todas |
Configuracion de Active Response
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100002</rules_id>
<timeout>3600</timeout>
</active-response>
Esta configuracion bloquea la IP atacante durante una hora cuando se detecta fuerza bruta (regla 100002). El location puede ser local (en el agente que genero la alerta), server (en el manager) o all (en todos los agentes).
Active Response personalizado
Se pueden crear scripts personalizados de respuesta. Wazuh pasa informacion del evento al script como parametros:
#!/bin/bash
# custom-response.sh
ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5
if [ "$ACTION" = "add" ]; then
# Accion de bloqueo
logger "Blocking $IP due to rule $RULEID"
# Integrar con firewall, SOAR, ticket system...
elif [ "$ACTION" = "delete" ]; then
# Revertir bloqueo (cuando expira timeout)
logger "Unblocking $IP"
fi
Precauciones
Active Response puede causar denegacion de servicio si no se configura con cuidado. Recomendaciones:
- Siempre usar
timeoutpara evitar bloqueos permanentes - Empezar en modo "alerta sin accion" y validar los triggers
- Excluir IPs criticas (gateways, DNS, management) con
white_list - Documentar cada regla de Active Response y su impacto potencial
Security Configuration Assessment (SCA)
El modulo SCA evalua la configuracion de seguridad de los endpoints contra politicas predefinidas basadas en estandares de la industria.
Politicas incluidas
Wazuh incluye politicas SCA para:
- CIS Benchmarks: Windows 10/11, Windows Server, Ubuntu, RHEL, Debian, macOS
- PCI DSS: requisitos de configuracion
- HIPAA: controles tecnicos
- NIST 800-53: controles de seguridad
Como funciona SCA
Cada politica define una serie de checks que verifican configuraciones especificas:
# Ejemplo de check SCA
- id: 1001
title: "Ensure password expiration is 365 days or less"
description: "The PASS_MAX_DAYS parameter controls the maximum number of days a password may be used"
rationale: "Reducing password lifetime reduces the window of opportunity for a compromised password"
remediation: "Set PASS_MAX_DAYS to 365 in /etc/login.defs"
condition: all
rules:
- 'f:/etc/login.defs -> r:^PASS_MAX_DAYS\s+(\d+) -> compare <= 365'
compliance:
- cis: "5.5.1.1"
- pci_dss: "8.2.4"
Los resultados se clasifican como Passed, Failed o Not Applicable, con un score global por politica. Esto facilita el reporting de compliance y la priorizacion de remediaciones.
Despliegue con Docker
Docker es la forma mas rapida de levantar un entorno Wazuh completo para evaluacion o produccion ligera.
Docker Compose basico
version: '3.8'
services:
wazuh.manager:
image: wazuh/wazuh-manager:4.9.0
hostname: wazuh.manager
ports:
- "1514:1514"
- "1515:1515"
- "514:514/udp"
- "55000:55000"
environment:
INDEXER_URL: https://wazuh.indexer:9200
INDEXER_USERNAME: admin
INDEXER_PASSWORD: SecretPassword
volumes:
- wazuh_api_configuration:/var/ossec/api/configuration
- wazuh_etc:/var/ossec/etc
- wazuh_logs:/var/ossec/logs
- wazuh_queue:/var/ossec/queue
- wazuh_var_multigroups:/var/ossec/var/multigroups
- wazuh_integrations:/var/ossec/integrations
- wazuh_active_response:/var/ossec/active-response/bin
- wazuh_wodles:/var/ossec/wodles
wazuh.indexer:
image: wazuh/wazuh-indexer:4.9.0
hostname: wazuh.indexer
environment:
OPENSEARCH_JAVA_OPTS: "-Xms1g -Xmx1g"
volumes:
- wazuh-indexer-data:/var/lib/wazuh-indexer
wazuh.dashboard:
image: wazuh/wazuh-dashboard:4.9.0
hostname: wazuh.dashboard
ports:
- "443:5601"
environment:
INDEXER_USERNAME: admin
INDEXER_PASSWORD: SecretPassword
WAZUH_API_URL: https://wazuh.manager
DASHBOARD_USERNAME: kibanaserver
DASHBOARD_PASSWORD: kibanaserver
volumes:
wazuh_api_configuration:
wazuh_etc:
wazuh_logs:
wazuh_queue:
wazuh_var_multigroups:
wazuh_integrations:
wazuh_active_response:
wazuh_wodles:
wazuh-indexer-data:
Registro de agentes
Una vez desplegado el manager, registrar un agente Linux:
# Instalar agente
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" > /etc/apt/sources.list.d/wazuh.list
apt-get update && apt-get install wazuh-agent
# Configurar y registrar
WAZUH_MANAGER='192.168.1.100' WAZUH_REGISTRATION_SERVER='192.168.1.100' /var/ossec/bin/agent-auth -m 192.168.1.100
# Iniciar agente
systemctl start wazuh-agent
systemctl enable wazuh-agent
Para Windows, el instalador MSI permite configurar el manager durante la instalacion:
wazuh-agent-4.9.0-1.msi /q WAZUH_MANAGER="192.168.1.100" WAZUH_REGISTRATION_SERVER="192.168.1.100"
Integracion con MITRE ATT&CK
Wazuh mapea sus reglas de deteccion a tecnicas MITRE ATT&CK. Cada regla puede incluir uno o mas IDs de tecnica:
<rule id="92001" level="8">
<if_sid>60106</if_sid>
<field name="win.eventdata.parentImage">\\cmd.exe$|\\powershell.exe$</field>
<description>Possible command and scripting interpreter execution</description>
<mitre>
<id>T1059.001</id>
<id>T1059.003</id>
</mitre>
</rule>
El dashboard de Wazuh incluye una vista MITRE ATT&CK que muestra:
- Heatmap de tacticas y tecnicas detectadas
- Timeline de eventos por tecnica
- Filtrado por agente, grupo o periodo de tiempo
- Drill-down desde tecnica a los eventos individuales
La cobertura MITRE de Wazuh depende directamente de las reglas configuradas. Con las reglas por defecto, la cobertura es parcial (centrada en Initial Access, Execution, Persistence y Defense Evasion). Ampliar la cobertura requiere escribir reglas personalizadas o importar reglas de la comunidad.
Integraciones externas
Wazuh se integra con herramientas externas mediante varios mecanismos.
Integraciones nativas
| Herramienta | Tipo | Descripcion |
|---|---|---|
| VirusTotal | Enrichment | Analizar hashes de archivos nuevos o modificados |
| Slack | Notificacion | Enviar alertas a canales Slack |
| PagerDuty | Notificacion | Escalado de alertas criticas |
| Shuffle | SOAR | Orquestacion de respuesta |
| TheHive | Case management | Crear casos automaticamente |
| MISP | Threat intel | Buscar IOCs en feeds MISP |
Syslog forwarding
Wazuh puede enviar alertas via syslog a cualquier SIEM externo:
<ossec_config>
<syslog_output>
<server>10.0.0.50</server>
<port>514</port>
<format>json</format>
<level>7</level>
</syslog_output>
</ossec_config>
API RESTful
La API de Wazuh (puerto 55000) permite gestionar toda la plataforma programaticamente: agentes, reglas, decoders, grupos, configuracion. Esto facilita la integracion con pipelines de CI/CD, scripts de automatizacion y herramientas SOAR.
Limitaciones honestas
Wazuh es una herramienta potente, pero no es un EDR enterprise. Las limitaciones que debes conocer:
Sin prevencion en tiempo real: Wazuh detecta y puede responder (Active Response), pero no bloquea procesos maliciosos antes de que se ejecuten. No tiene capacidad de aislamiento de endpoint comparable a un EDR enterprise.
Dependencia de reglas: la calidad de la deteccion depende directamente de las reglas configuradas. Sin tuning, el ruido puede ser significativo y los gaps de deteccion amplios.
Complejidad operativa: mantener Wazuh requiere conocimiento de Linux, OpenSearch, expresiones regulares y el sistema de reglas propio. No es "instalar y olvidar".
Sin sandboxing ni analisis de malware: Wazuh no analiza archivos sospechosos. Para eso necesitas integrarlo con herramientas externas como VirusTotal, YARA o un sandbox dedicado.
Escalabilidad: el indexer (OpenSearch) consume recursos significativos. Despliegues grandes (miles de agentes) requieren planificacion de capacidad seria y posiblemente hardware dedicado.
Soporte comercial: existe Wazuh Inc. que ofrece soporte de pago y una version cloud, pero el modelo es diferente al soporte 24/7 de un vendor enterprise.
Cuando elegir Wazuh
Wazuh encaja bien en estos escenarios:
- Presupuesto limitado: organizaciones que no pueden permitirse licencias EDR enterprise pero necesitan visibilidad
- Compliance: necesidad de monitoring de integridad, deteccion de vulnerabilidades y reporting de cumplimiento normativo
- Entornos mixtos: monitorizacion de Linux, Windows y macOS desde una sola plataforma
- Complemento a EDR enterprise: usar Wazuh como SIEM para logs que el EDR no cubre (aplicaciones, cloud, OT)
- Laboratorios y formacion: entorno completo de seguridad para aprender sin coste de licencias
- Soberania de datos: todo se despliega on-premise, sin dependencia de cloud de terceros
Conclusion
Wazuh no compite directamente con CrowdStrike o SentinelOne en prevencion de amenazas avanzadas. Pero en deteccion, compliance y visibilidad, ofrece una plataforma sorprendentemente completa para ser gratuita. La clave esta en invertir tiempo en configuracion y tuning: unas reglas bien ajustadas, FIM en los directorios correctos y Active Response con cautela pueden convertir a Wazuh en la columna vertebral de un SOC con recursos limitados.
Para organizaciones que ya tienen un EDR enterprise, Wazuh sigue siendo valioso como SIEM complementario: recopilando logs de aplicaciones, monitorizando integridad de archivos y proporcionando dashboards de compliance que muchos EDR no cubren.
Preguntas frecuentes
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.