IntermedioWazuhSIEMEDRopen sourceFIMactive responsedeteccion

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.

MalwareIntel Research··14 min lectura

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:

ModuloFuncionPlataforma
Log collectorRecopila logs del sistema y aplicacionesTodas
Syscheck (FIM)Monitoriza cambios en archivos y registrosTodas
RootcheckDeteccion de rootkits y anomaliasLinux, macOS
SCAEvaluacion de configuracion de seguridadTodas
SyscollectorInventario de hardware, software, procesos, puertosTodas
Command monitoringEjecuta comandos periodicos y analiza la salidaTodas
Osquery integrationConsultas SQL sobre el estado del sistemaTodas

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:

NivelSignificadoEjemplo
0-3Informativo / ruidoLogin exitoso
4-7Bajo / medioFallo de autenticacion aislado
8-11AltoMultiples fallos, cambio de configuracion critica
12-15CriticoRootkit 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

  1. El agente recopila el inventario de software instalado (nombre, version, arquitectura)
  2. El manager descarga y mantiene actualizada la base de datos de CVEs
  3. El motor cruza inventario contra CVEs conocidos
  4. 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:

AccionDescripcionPlataforma
firewall-dropBloquea IP en iptables/ipfwLinux, macOS
win_route-nullRuta nula a IP atacanteWindows
host-denyAnade IP a /etc/hosts.denyLinux
disable-accountDeshabilita cuenta de usuarioLinux, Windows
restart-wazuhReinicia el agente WazuhTodas

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 timeout para 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

HerramientaTipoDescripcion
VirusTotalEnrichmentAnalizar hashes de archivos nuevos o modificados
SlackNotificacionEnviar alertas a canales Slack
PagerDutyNotificacionEscalado de alertas criticas
ShuffleSOAROrquestacion de respuesta
TheHiveCase managementCrear casos automaticamente
MISPThreat intelBuscar 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.