Por qué desplegar Wazuh en tu VPS
Un servidor Linux emite continuamente señales de seguridad: intentos de conexión SSH, modificaciones de archivos del sistema, escaladas de privilegios, procesos inusuales. Estos eventos viven en logs dispersos — /var/log/auth.log, los logs de tus contenedores, los logs de aplicaciones — que nadie correlaciona. Un SIEM es precisamente la herramienta que centraliza estos flujos, los analiza y hace aflorar los incidentes.
Wazuh es hoy la referencia open source en este ámbito. Su arquitectura se basa en un manager (el cerebro de la detección) que recibe datos de agentes ligeros instalados en cada uno de tus servidores. El manager integra un motor de correlación de reglas, un módulo de integridad de archivos (FIM), un módulo de detección de vulnerabilidades y dashboards de cumplimiento normativo listos para usar.
A diferencia de Datadog SIEM o Elastic SIEM en modo cloud, Wazuh no te cobra por ingestión y tus datos permanecen en tu propia infraestructura. Este es el enfoque a adoptar cuando gestionas varios servidores y necesitas justificar tu postura de seguridad.
Qué aporta Wazuh a tu infraestructura
- Centralización de logs de todos tus servidores Linux en un único dashboard: sin más conexiones SSH de máquina en máquina para leer
auth.log. - Detección de intrusiones basada en reglas: intentos de fuerza bruta, escaladas de privilegios, modificaciones de archivos críticos — con correlación multi-fuente.
- File Integrity Monitoring (FIM) en tiempo real: cualquier modificación de
/etc/passwd,/etc/sudoerso de tus binarios del sistema genera una alerta inmediata. - Reglas de cumplimiento PCI-DSS, HIPAA, GDPR y NIST SP 800-53 integradas en el conjunto de reglas predeterminado — cada alerta se etiqueta automáticamente con los controles normativos afectados.
- Detección activa de vulnerabilidades: Wazuh consulta bases de datos CVE e identifica paquetes instalados expuestos a CVEs conocidas.
- Complementario a CrowdSec y Fail2ban: Wazuh correlaciona y archiva para el cumplimiento normativo, CrowdSec actúa en el perímetro — las dos herramientas se refuerzan sin duplicarse.
- Sin coste de ingestión: conservas el historial tanto tiempo como permita tu disco.
Requisitos previos con cifras concretas
El despliegue single-node de Wazuh (manager + indexer + dashboard en tres contenedores Docker) es más exigente en recursos que un simple agente de monitorización. Estos son los mínimos realistas para un uso en producción.
Para el manager (nodo central):
- 4 vCPU mínimo, 8 vCPU recomendados para un parque de 10 servidores o más.
- 8 GB de RAM mínimo para el nodo single-node. Prevé 16 GB si indexas un volumen alto de eventos o gestionas más de 50 agentes.
- 50 GB de disco SSD mínimo; 100 GB o más si conservas 90 días de historial.
- Ubuntu 22.04 LTS o Debian 12, actualizados.
- Docker Engine 24.0+ y Docker Compose v2 instalados.
- Un nombre de dominio para exponer el dashboard Wazuh en HTTPS mediante un proxy inverso.
Para cada agente (en tus otros servidores):
- El agente Wazuh es muy ligero: menos de 64 MB de RAM y menos del 1% de CPU en condiciones normales.
- Compatible con Linux (Debian, Ubuntu, AlmaLinux, Rocky), Windows y macOS.
Puertos de red a abrir en el manager:
- 1514/UDP y 1514/TCP: comunicación agente → manager.
- 1515/TCP: registro de agentes.
- 55000/TCP: API REST de Wazuh (acceso local únicamente, no exponer públicamente).
- 9200/TCP y 9300/TCP: Wazuh Indexer (uso interno entre contenedores).
- 443/TCP: Wazuh Dashboard a través de tu proxy inverso.
Desplegar Wazuh con Docker Compose: procedimiento completo
Preparar el servidor e instalar Docker
Actualiza el sistema e instala Docker Engine y Docker Compose v2 desde el repositorio oficial de Docker:
apt-get update && apt-get upgrade -y curl -fsSL https://get.docker.com | sh docker --version && docker compose versionVerifica que Docker Compose v2 responde correctamente (comando
docker compose, sin guión). Activa Docker al inicio:systemctl enable --now docker.Clonar el repositorio oficial Wazuh Docker
Wazuh publica sus archivos Docker Compose oficiales en el repositorio
wazuh/wazuh-docker. Clona la rama correspondiente a la versión estable actual (v4.14.8 en el momento de este artículo):git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.8 --depth 1 cd wazuh-docker/single-nodeLa carpeta
single-nodecontiene eldocker-compose.ymlpreconfigurado con tres servicios:wazuh.manager,wazuh.indexerywazuh.dashboard.Generar los certificados TLS entre componentes
Wazuh requiere certificados TLS para la comunicación entre el manager, el indexer y el dashboard. El repositorio proporciona un archivo Compose dedicado para su generación:
docker compose -f generate-indexer-certs.yml run --rm generatorLos certificados se escriben en
config/wazuh_indexer_ssl_certs/. Este paso se requiere una sola vez; para renovarlos, vuelve a ejecutar el comando y reinicia el stack.Arrancar el stack de Wazuh
Lanza los tres contenedores en segundo plano:
docker compose up -dEl primer arranque descarga las imágenes oficiales (aproximadamente 2 GB en total) e inicializa el indexer. Espera 60 a 90 segundos y comprueba que los tres servicios estén en estado
healthy:docker compose psSi
wazuh.indexerpermanece enstartingmás de 3 minutos, revisa sus logs:docker compose logs wazuh.indexer | tail -50.Cambiar la contraseña predeterminada del dashboard
Las credenciales predeterminadas del dashboard de Wazuh son
admin/SecretPassword. Cámbialas inmediatamente a través de la API de OpenSearch Indexer:docker compose exec wazuh.indexer curl -sk -X PUT \ https://localhost:9200/_plugins/_security/api/account \ -u admin:SecretPassword \ -H 'Content-Type: application/json' \ -d '{"password": "TuNuevaContraseña", "current_password": "SecretPassword"}'Actualiza la variable
DASHBOARD_PASSWORDendocker-compose.ymly vuelve a ejecutardocker compose up -dpara que el dashboard use la nueva contraseña.Exponer el dashboard a través de un proxy inverso HTTPS
No expongas el dashboard directamente en el puerto 443 sin proxy inverso. Con nginx, crea un vhost que haga proxy hacia
https://127.0.0.1:5601desactivando la verificación del certificado autofirmado en el lado upstream:server { listen 443 ssl; server_name wazuh.tu-dominio.com; location / { proxy_pass https://127.0.0.1:5601; proxy_ssl_verify off; } }Renueva tu certificado Let's Encrypt con Certbot. No expongas los puertos 9200, 55000 ni 1514/1515 públicamente.
Instalar y registrar un agente en un servidor remoto
En cada servidor Linux que quieras monitorizar, instala el agente Wazuh apuntando a la IP o DNS de tu manager. En Ubuntu/Debian:
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \ --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \ chmod 644 /usr/share/keyrings/wazuh.gpg echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \ tee /etc/apt/sources.list.d/wazuh.list apt-get update && apt-get install -y wazuh-agentConfigura la dirección del manager en
/var/ossec/etc/ossec.conf(etiqueta<address>), luego inicia y activa el agente:systemctl daemon-reload systemctl enable wazuh-agent systemctl start wazuh-agentEl agente aparece en el dashboard bajo Agents en los 30 segundos siguientes.
Configuración post-instalación: agentes, reglas y dashboards de cumplimiento
Una vez que el stack está operativo y los primeros agentes conectados, tres ajustes mejoran significativamente la relevancia de las alertas.
Activar la monitorización de integridad de archivos (FIM). En la configuración del agente (/var/ossec/etc/ossec.conf), añade los directorios sensibles en la sección <syscheck>:
<syscheck>
<frequency>43200</frequency>
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/var/www</directories>
</syscheck>Cualquier modificación en estos directorios genera una alerta de nivel 7 o superior.
Explorar los dashboards de cumplimiento. En el dashboard de Wazuh, la sección Modules expone vistas preconfiguradas para PCI-DSS, HIPAA, GDPR y NIST SP 800-53. Cada alerta hereda automáticamente las etiquetas normativas definidas en las reglas XML del manager.
Ajustar el umbral de nivel de alerta. El umbral predeterminado es 3. Para recibir solo alertas significativas, edita /var/ossec/etc/ossec.conf en el manager y eleva el umbral a 7 en la sección <alerts>:
<alerts>
<log_alert_level>7</log_alert_level>
<email_alert_level>9</email_alert_level>
</alerts>Reinicia el manager tras cualquier cambio de configuración: docker compose restart wazuh.manager.
Bastionado del despliegue
Algunos ajustes reducen la superficie de ataque del manager en sí.
Aisla el manager en su propio VPS o, como mínimo, detrás de un firewall que solo abra los puertos 1514-1515 a las IPs de tus agentes — nunca a 0.0.0.0.
Activa la autenticación TLS mutua entre agentes y manager generando certificados de agente firmados por tu CA interna en lugar de usar el registro automático (ossec-authd). La documentación oficial de Wazuh detalla el procedimiento bajo "Agent enrollment via the Wazuh manager API".
Cifra los volúmenes Docker que contienen el índice OpenSearch y las configuraciones — especialmente si alojas el manager en un VPS compartido.
Monitoriza el propio manager: instala un agente Wazuh en el VPS que ejecuta el manager para detectar cualquier modificación de las imágenes Docker o los archivos de configuración.
Resolución de problemas: errores frecuentes
Estos son los cinco problemas más frecuentes al desplegar Wazuh con Docker, con los mensajes exactos y sus correcciones.
1. max virtual memory areas vm.max_map_count [65530] is too low
El indexer OpenSearch requiere al menos 262144. Añade esta línea en /etc/sysctl.conf del host (no dentro del contenedor): vm.max_map_count=262144, luego aplica con sysctl -p. Es el error más frecuente en un VPS recién creado.
2. wazuh.indexer permanece en estado starting indefinidamente
Revisa primero los logs (docker compose logs wazuh.indexer). Si ves bootstrap checks failed, casi siempre es vm.max_map_count (ver arriba) o falta de RAM. Si ves certificate not found, vuelve a generar los certificados.
3. El agente aparece como Disconnected en el dashboard
Verifica que el puerto 1514 está abierto en el manager y que la dirección del manager está correctamente configurada en el agente. Prueba la conectividad: nc -zv <IP_MANAGER> 1514.
4. ERROR: [agent_auth] Unable to create ssl context
El agente no puede validar el certificado TLS del manager. Comprueba que ossec.cfg apunta al nombre DNS y no a la IP si usas un certificado nominado.
5. Too many open files en los logs del manager
Aumenta los límites nofile en el host en /etc/security/limits.conf: * soft nofile 65536 y * hard nofile 65536. En docker-compose.yml, añade ulimits: nofile: soft: 65536 hard: 65536 al servicio wazuh.manager y reinicia.
Wazuh en tu stack de seguridad
Wazuh es más efectivo cuando se integra con lo que ya tienes desplegado. Combinado con CrowdSec (que bloquea IPs a nivel de red), cubre tanto el perímetro como la profundidad del sistema. Combinado con Fail2ban, añade correlación y archivado normativo que Fail2ban no puede generar por sí solo. Y si ya tienes una stack de Grafana + Prometheus, Wazuh complementa la observabilidad del sistema con una capa de seguridad: Prometheus te dice que la CPU está al 90%, Wazuh te dice por qué.
El bastionado de tu servidor define una postura de seguridad estática. Wazuh es la monitorización continua que verifica que esa postura se mantiene en el tiempo.
Para alojar tu manager Wazuh en una infraestructura cuyo nivel de seguridad controlas, consulta cómo ServOrbit estructura la seguridad de su infraestructura y elige el VPS que se adapta a tu parque de agentes.
