Wazuh Docker Compose: SIEM y XDR Self-Hosted 2026

Wazuh Docker Compose centralizando alertas de seguridad de varios servidores

Montar Wazuh Docker Compose te da una plataforma de seguridad completa en tu propio servidor: recogida de registros de todos tus equipos, detección de intrusiones, vigilancia de integridad de ficheros, inventario de vulnerabilidades y respuesta automática. Todo lo que un SIEM comercial cobra por evento, sin coste de licencia.

El precio lo pagas en recursos: es el despliegue más pesado que hemos cubierto en esta serie y necesita al menos 6 GB de RAM para funcionar con dignidad.

Qué compone Wazuh Docker Compose

Wazuh Docker Compose tiene tres piezas, y saber qué hace cada una te ahorra la mitad de los problemas de diagnóstico.

ComponenteFunciónPeso
ManagerRecibe los datos de los agentes, aplica reglas y genera alertas.Medio
IndexerAlmacena y busca. Es un motor derivado de OpenSearch.Alto
DashboardInterfaz web de consulta y administración.Medio

El indexador es el que se come la memoria, porque es una base de datos de búsqueda basada en Java. Si ya trabajaste con OpenSearch en Docker Compose, reconocerás el comportamiento y las mismas exigencias de configuración del sistema.

Frente a soluciones más ligeras, la diferencia de enfoque es clara: CrowdSec bloquea ataques en tiempo real con un consumo mínimo; esto además guarda, correlaciona e investiga. No compiten, se complementan.


Requisitos previos de Wazuh Docker Compose

RecursoMínimoRecomendado
RAM6 GB8-16 GB
CPU4 núcleos8 núcleos
Disco50 GB200 GB SSD
Docker Engine24.xÚltima estable

Hay además un ajuste del núcleo que no es opcional. Sin él, el indexador de Wazuh Docker Compose ni siquiera arranca.

sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf

La segunda línea lo hace permanente. Si te la saltas, todo funcionará hasta el siguiente reinicio del servidor, y entonces el fallo aparecerá sin causa aparente.

Instalar Wazuh Docker Compose paso a paso

Paso 1: clonar el repositorio de despliegue

El proyecto mantiene los ficheros de Wazuh Docker Compose aparte del código. Clona siempre fijando la etiqueta de versión, nunca la rama principal.

git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.7
cd wazuh-docker/single-node/

Hay dos variantes: single-node, que es la que usaremos, y multi-node con tres indexadores para alta disponibilidad. Para empezar, y para la mayoría de instalaciones pequeñas, la primera sobra.

Paso 2: generar los certificados

Los componentes de Wazuh Docker Compose se comunican entre sí cifrados y con autenticación mutua, así que necesitan una autoridad propia. El repositorio incluye un generador.

docker compose -f generate-indexer-certs.yml run --rm generator
ls -l config/wazuh_indexer_ssl_certs/

Deberías ver los certificados del indexador, del gestor, del panel y de la autoridad. Si ese directorio está vacío, no sigas: nada arrancará después.

Paso 3: cambiar las contraseñas por defecto

Este paso de Wazuh Docker Compose va antes de levantar nada, y es el que más se salta la gente. El despliegue viene con credenciales públicas documentadas: usuario admin con contraseña SecretPassword.

Advertencia: no es una contraseña, es un aviso

Una plataforma de seguridad con la contraseña de ejemplo es peor que no tener plataforma: concentra los registros de todos tus servidores en un sitio al que cualquiera puede entrar. Cámbiala antes del primer arranque y no lo dejes «para luego».

Las contraseñas del indexador no van en claro, sino como hash. Genera el tuyo con la herramienta que trae la propia imagen.

docker run --rm -ti wazuh/wazuh-indexer:4.14.7 \
  bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh \
  -p 'MiContrasenaLargaYUnica'

Ese hash se pega en config/wazuh_indexer/internal_users.yml, sustituyendo el del usuario admin. Después, en el docker-compose.yml, actualiza las variables con la contraseña en claro para que los demás servicios puedan autenticarse.

      - INDEXER_PASSWORD=MiContrasenaLargaYUnica
      - DASHBOARD_PASSWORD=OtraContrasenaDistinta
      - API_PASSWORD=UnaTerceraContrasena

Paso 4: levantar la pila

docker compose up -d
docker compose ps
docker compose logs -f wazuh.indexer

El primer arranque de Wazuh Docker Compose tarda varios minutos: el indexador crea sus índices y aplica la configuración de seguridad. Ten paciencia antes de dar por fallida la instalación.

Cuando termine, el panel está en https://tu-servidor por el puerto 443. El certificado es autofirmado, así que el navegador protestará; para uso real, pon delante un proxy inverso con certificado válido, como vimos con Traefik.

Paso 5: desplegar agentes

El servidor de Wazuh Docker Compose por sí solo no ve nada. Los agentes son los que recogen registros y vigilan ficheros en cada máquina, y se conectan por los puertos 1514 y 1515.

curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.7-1_amd64.deb \
  && sudo WAZUH_MANAGER='192.168.1.50' WAZUH_AGENT_NAME='web01' dpkg -i ./wazuh-agent.deb

sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

En un par de minutos el agente aparece como activo en el panel. Si gestionas varias máquinas, este despliegue es candidato perfecto para automatizarlo con un playbook, en la línea de lo que vimos en los tutoriales de Ansible.


Qué configurar primero en Wazuh Docker Compose

Recién instalado, Wazuh Docker Compose ya detecta bastante, pero hay tres cosas que multiplican su utilidad y que conviene tocar el primer día.

Vigilancia de integridad de ficheros

Avisa cuando cambia algo que no debería cambiar. Se define en la configuración del gestor y se propaga a los agentes.

<syscheck>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/var/www</directories>
  <directories check_all="yes">/usr/bin,/usr/sbin</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/resolv.conf</ignore>
</syscheck>

Cuidado con activar tiempo real sobre directorios muy movidos: genera muchísimo ruido y acaba enterrando las alertas que importan. Los directorios de registros, las cachés y los temporales son los sospechosos habituales, y conviene excluirlos explícitamente desde el principio.

Detección de vulnerabilidades

Cruza el inventario de paquetes de cada agente con las bases de datos públicas de CVE. Te da, sin instalar nada más, un listado de qué máquinas tienen software con fallos conocidos y cuáles son críticos. Es probablemente la función que antes justifica el consumo de memoria.

El valor práctico se ve el día que sale un aviso crítico en la prensa técnica. En lugar de recorrer servidor por servidor preguntándote si te afecta, filtras por el identificador del CVE en el panel y en treinta segundos tienes la lista exacta de máquinas pendientes de parchear, con su versión instalada. Esa capacidad de respuesta es difícil de conseguir de otra forma cuando el parque pasa de unas pocas máquinas.

Respuesta activa

Permite ejecutar una acción cuando salta una regla: bloquear una dirección en el cortafuegos durante diez minutos tras varios intentos fallidos, por ejemplo. Empieza siempre con bloqueos temporales y en modo de prueba, porque una respuesta activa mal ajustada puede dejarte fuera de tu propio servidor.

Domar el ruido: el trabajo de verdad

Aquí está el motivo por el que la mayoría de instalaciones de Wazuh Docker Compose acaban abandonadas a los dos meses. El primer día el panel se llena de alertas, muchas de ellas intrascendentes, y llega un punto en que nadie las mira. Un sistema de detección que nadie consulta es peor que no tenerlo, porque da una falsa sensación de control.

Las reglas tienen un nivel de severidad del 0 al 15. Conviene conocer la escala porque es la palanca principal para decidir qué merece tu atención.

NivelSignificadoQué hacer
0-3InformativoIgnorar salvo investigación puntual
4-7Bajo y medioRevisar de forma agregada
8-11ImportanteRevisión diaria
12-15CríticoAviso inmediato

La estrategia que funciona es empezar solo con nivel 12 o superior enviando notificación, y dejar el resto para revisión semanal. Cuando lleves un mes y conozcas tu línea base, vas bajando el umbral poco a poco.

Para las alertas que sabes que son falsas en tu entorno, la solución no es apagar la regla entera sino escribir una excepción acotada.

<group name="local,syslog,">
  <rule id="100010" level="0">
    <if_sid>5710</if_sid>
    <srcip>192.168.1.0/24</srcip>
    <description>Intento SSH desde la red interna: ignorado</description>
  </rule>
</group>

Poner el nivel a cero silencia esa combinación concreta sin tocar la regla original, que seguirá alertando para el resto de orígenes. Las reglas propias van siempre en el fichero local y con identificadores por encima de 100000, para que no choquen con las que trae el sistema ni se pierdan al actualizar.


Mantenimiento de Wazuh Docker Compose y fallos típicos

SíntomaCausaSolución
El indexador no arrancavm.max_map_count bajoAjustarlo y hacerlo permanente
Panel con error de conexiónContraseñas descuadradasIgualar hash y variables
Agente desconectadoPuertos 1514/1515 cerradosAbrirlos en el cortafuegos
Disco lleno en semanasSin política de retenciónConfigurar índices y borrado
Todo va muy lentoMemoria insuficienteAmpliar RAM o ajustar la JVM

La retención de Wazuh Docker Compose merece atención desde el principio. Los registros crecen sin freno y en un mes pueden ocupar decenas de gigas; define cuántos días conservas antes de que el disco te obligue a decidirlo con prisa.

Para las copias, respalda la configuración del gestor y los datos del indexador. Y ten presente que un servidor de seguridad comprometido es un problema doble: guarda las copias fuera de su alcance, con Duplicati y cifrado o equivalente.

Sacar las alertas del panel

Un panel solo sirve si alguien lo abre, y a las tres semanas nadie lo abre. Por eso el paso que de verdad convierte Wazuh Docker Compose en algo útil es enviar las alertas críticas a donde ya miras: correo, chat del equipo o el servicio de notificaciones que uses.

La configuración de integraciones va en el fichero principal del gestor y admite varios destinos con su propio umbral.

<integration>
  <name>custom-notificador</name>
  <hook_url>https://ntfy.midominio.es/seguridad</hook_url>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

Ese level es la clave de que el sistema siga vivo dentro de seis meses. Con 12 recibes solo lo grave; si lo bajas a 7 el primer día, el canal se llena de ruido y acabarás silenciándolo, que es exactamente el resultado que quieres evitar. Si tienes montado ntfy para notificaciones push, el circuito se cierra sin añadir ninguna pieza nueva.

Para el correo, la configuración es igual de directa y no requiere integración externa.

<global>
  <email_notification>yes</email_notification>
  <email_to>seguridad@midominio.es</email_to>
  <smtp_server>smtp.midominio.es</smtp_server>
  <email_from>wazuh@midominio.es</email_from>
  <email_alert_level>12</email_alert_level>
</global>

Un consejo que ahorra disgustos: prueba la notificación provocando tú mismo una alerta conocida —varios intentos de inicio de sesión fallidos, por ejemplo— en lugar de esperar a que llegue sola. Descubrir que el correo nunca salió el día que lo necesitas de verdad es una situación bastante desagradable, y ese tipo de fallo silencioso es más frecuente de lo que parece cuando hay un cortafuegos o un servidor de correo con filtros por medio.


Conclusión sobre Wazuh Docker Compose

Wazuh Docker Compose no es un servicio para instalar un domingo por curiosidad. Pide máquina, pide ajustes y pide dedicarle tiempo a afinar reglas para que las alertas signifiquen algo. Pero si gestionas más de cinco o seis servidores, tener los registros centralizados y correlacionados cambia por completo la capacidad de responder cuando algo va mal.

Mi consejo con Wazuh Docker Compose es empezar con dos agentes, dejarlo una semana y dedicar un rato a silenciar el ruido antes de ampliar. Un panel lleno de alertas que nadie mira no sirve para nada. Tienes la guía en la documentación oficial de despliegue con Docker, los ficheros en el repositorio wazuh-docker, el código en GitHub, la referencia de configuración en el manual de usuario, el proyecto en su web y más ideas en los tutoriales de Docker Compose.

Preguntas frecuentes sobre Wazuh Docker Compose

¿Puedo usarlo con menos de 6 GB de RAM?

Arranca con 4 GB ajustando la memoria de la JVM del indexador, pero con pocos agentes y sabiendo que las búsquedas irán lentas. Por debajo de eso, los servicios empiezan a morir por falta de memoria.

¿Sirve para Windows además de Linux?

Sí, hay agente para Windows, macOS y varias distribuciones de Linux. En Windows recoge además el registro de eventos, que es donde está la información más útil de ese sistema.

¿Cuántos agentes aguanta un solo nodo?

Con la instalación de nodo único y hardware holgado, del orden de unas decenas sin problema. A partir de ahí conviene pasar a la variante de varios nodos, que reparte el indexado.

¿Reemplaza a un antivirus?

No exactamente. Detecta comportamientos anómalos, cambios en ficheros y vulnerabilidades conocidas, pero no analiza ficheros en tiempo real como lo hace un antivirus tradicional. Se complementan.

¿Cómo actualizo a una versión nueva?

Cambiando la etiqueta de versión en el repositorio de despliegue y recreando los contenedores. Haz copia antes, revisa las notas de la versión y actualiza los agentes después del servidor, nunca al revés.

Avatar

Por Mid

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x