Topología de Wazuh: conexión entre agente, manager, indexer y dashboard

Cuando una operación de seguridad depende de Wazuh, la primera pregunta no suele ser "¿qué reglas configuro?", sino "¿cómo están conectados los componentes y qué pasa si uno falla?". Entender la topología —no solo el flujo de datos— es lo que separa una implementación que aguanta el ritmo de producción de una que genera ruido, pérdida de eventos y horas de troubleshooting.

Por qué la arquitectura de Wazuh importa en operaciones de seguridad

El dolor más común en equipos que operan Wazuh sin una arquitectura clara es la dispersión: agentes instalados sin criterio, eventos que llegan a destiempo, correlación limitada y cambios no autorizados que nadie detecta a tiempo. Cuando los componentes no están bien dimensionados ni conectados, la visibilidad de seguridad se degrada silenciosamente.

Una topología bien diseñada resuelve tres problemas concretos:

• Centralización: todos los eventos de seguridad convergen en un solo punto, lo que permite correlacionar actividad entre servidores, endpoints y aplicaciones.
• Escalabilidad: separar las cargas de análisis, almacenamiento y visualización evita que un componente sature a los demás.
• Trazabilidad: con una arquitectura clara, es posible rastrear qué agente generó un evento, cómo llegó al manager y cuándo quedó disponible en el dashboard.

Sin esa estructura, el equipo de operaciones termina revisando logs en cada servidor, sin una visión consolidada y sin poder responder preguntas básicas como "¿qué cambió en producción esta madrugada?".

Componentes y su rol en la topología

Wazuh se compone de cuatro elementos principales que cumplen funciones distintas y complementarias:

Agente: es el componente liviano que se instala en los servidores, endpoints o aplicaciones que se desea monitorear. Su trabajo es recolectar eventos del sistema operativo, detectar cambios en archivos, monitorear procesos y ejecutar respuestas activas. Envía la información al manager de forma continua.

Manager: es el cerebro del análisis. Recibe los eventos de los agentes, los normaliza, aplica reglas de correlación y genera alertas. También gestiona la configuración de los agentes de forma centralizada y puede ejecutar respuestas activas. Es el componente que más consume CPU, porque el análisis en tiempo real ocurre aquí.

Indexer: es el motor de almacenamiento y búsqueda. Recibe las alertas y eventos ya procesados desde el manager, los indexa y los mantiene disponibles para consultas rápidas. En la práctica, es un clúster de OpenSearch que guarda los datos históricos y permite búsquedas sobre grandes volúmenes de información.

Dashboard: es la interfaz de visualización. Se conecta al indexer para mostrar alertas, generar gráficos, tableros y permitir búsquedas. Es la capa que usan los analistas y operadores para interactuar con los datos.

La relación entre estos componentes es jerárquica: los agentes se comunican con el manager, el manager con el indexer, y el dashboard consulta al indexer. No hay comunicación directa entre agentes y dashboard, ni entre agentes e indexer.

Cómo se conectan: flujo de comunicación entre componentes

La conectividad entre componentes sigue un esquema definido, con puertos y protocolos específicos que conviene conocer al momento de dimensionar firewalls o resolver problemas de comunicación.

Agente → Manager: los agentes se comunican con el manager a través del puerto 1514/TCP (o 1514/UDP, según configuración). La comunicación es bidireccional: el agente envía eventos y el manager puede enviar comandos de configuración o respuestas activas. Esta conexión es la más crítica de toda la topología: si se pierde, los agentes quedan aislados y la visibilidad desaparece.

Manager → Indexer: el manager envía las alertas y eventos procesados al indexer mediante el puerto 9200/TCP (API de OpenSearch). Esta conexión es de escritura masiva: el manager indexa los datos que luego serán consultados. Si el indexer está caído o lento, el manager acumula datos en cola o los descarta, dependiendo de la configuración.

Dashboard → Indexer: el dashboard se conecta al indexer a través del puerto 443/TCP (HTTPS) para autenticarse y consultar datos. Esta conexión es de lectura: el dashboard no escribe directamente en el indexer, solo consulta.

Manager → Dashboard: no existe una conexión directa entre ambos. El dashboard obtiene toda la información desde el indexer. Esto significa que si el indexer falla, el dashboard queda inutilizable aunque el manager siga procesando eventos.

Un punto que suele confundir: el manager no "empuja" datos al dashboard. El flujo es agente → manager → indexer → dashboard. Si se quiere entender el recorrido completo de un evento, conviene revisar el post sobre Arquitectura de Wazuh: el camino del evento desde el agente hasta el dashboard, que profundiza en esa trayectoria. Aquí el foco está en la topología y sus dependencias.

Puntos de fallo y señales de salud que conviene observar

En esta arquitectura, los puntos de fallo más comunes no están en los agentes, sino en las conexiones entre componentes y en el dimensionamiento de cada capa.

Manager sobrecargado: cuando hay demasiados agentes conectados a un solo manager, el análisis en tiempo real se degrada. Las señales típicas son latencia en la generación de alertas, colas de eventos acumulándose y agentes que pierden conectividad temporal. El manager es el componente que más CPU consume, y su capacidad depende de la cantidad de eventos por segundo que debe procesar.

Indexer sin espacio o sin réplicas: si el almacenamiento se llena, el indexer deja de aceptar datos y el manager empieza a acumular o descartar eventos. Si el clúster no tiene réplicas configuradas, un nodo caído significa pérdida de disponibilidad de búsqueda. Las señales de alerta son latencia en las consultas del dashboard, errores de índice y uso de disco por encima del 80%.

Dashboard lento: generalmente no es un problema del dashboard en sí, sino del indexer. Si las consultas tardan, el problema suele estar en la capacidad de búsqueda del clúster, no en la interfaz.

Pérdida de conectividad agente-manager: es el fallo más silencioso. Los agentes pueden seguir funcionando normalmente, pero si no llegan al manager, no hay visibilidad. Conviene monitorear la cantidad de agentes activos versus los instalados, y revisar si hay agentes que llevan horas sin reportar.

Certificados vencidos o mal distribuidos: Wazuh usa certificados TLS para autenticar la comunicación entre componentes. Un certificado vencido en un agente o en el manager interrumpe la conexión sin generar errores evidentes en el dashboard.

Criterios para evaluar esta arquitectura en tu operación

Antes de decidir si la topología actual es adecuada, conviene hacerse algunas preguntas concretas:

• ¿Cuántos agentes necesitas conectar y cuántos eventos por segundo genera tu operación? Esto define si un solo manager es suficiente o si necesitas una arquitectura distribuida.
• ¿Tu indexer tiene capacidad de almacenamiento para el período de retención que necesitas? No es lo mismo guardar 30 días que 12 meses de eventos.
• ¿Tienes redundancia en los componentes críticos? Si el manager o el indexer caen, ¿tu operación puede quedar sin visibilidad?
• ¿Quién monitorea a los monitores? Si el dashboard está caído, ¿cómo te enteras? Es necesario tener alertas sobre la salud de los propios componentes de Wazuh.
• ¿Tu equipo tiene tiempo para mantener actualizaciones, certificados y ajustes de rendimiento? La operación de Wazuh requiere mantenimiento continuo, no solo instalación inicial.

Evaluar estos puntos ayuda a decidir si la arquitectura actual es sostenible o si conviene externalizar la operación. Un servicio gestionado de Wazuh como Servicio permite delegar el dimensionamiento, la actualización y el monitoreo de la plataforma, mientras tu equipo se enfoca en analizar alertas y responder incidentes, no en mantener infraestructura.

La decisión no es binaria entre "todo interno" o "todo externo". Se trata de evaluar si la topología actual responde a las necesidades de tu operación y si tu equipo tiene la capacidad de mantenerla operativa en el tiempo.