Wazuh: Plataforma de seguridad integral de código abierto

Introducción

Wazuh es una plataforma de seguridad de código abierto enfocada en la monitorización de amenazas y respuesta a incidentes. Ofrece una protección integral frente a ataques en tiempo real, con capacidades avanzadas de detección de intrusiones, análisis de eventos y automatización de respuestas. En esencia, Wazuh combina funciones de SIEM (Security Information and Event Management) y de HIDS (Host-based Intrusion Detection System) para recopilar información de seguridad de múltiples orígenes, correlacionar eventos y alertar sobre comportamientos maliciosos. Su enfoque unificado permite identificar y mitigar ataques antes de que comprometan sistemas críticos [1], a la vez que ayuda a las organizaciones a cumplir con normativas de seguridad al proporcionar visibilidad centralizada y control sobre sus sistemas.

Diseñada inicialmente como una mejora al proyecto OSSEC, Wazuh ha evolucionado hacia una solución open source completa de XDR (Extended Detection and Response). La plataforma puede desplegarse en entornos heterogéneos (servidores on-premise, nubes públicas/privadas, contenedores, etc.), con agentes disponibles para Windows, Linux, macOS y otros sistemas. Gracias a esta flexibilidad, Wazuh protege una amplia gama de activos de TI y se integra en flujos de trabajo de seguridad existentes. A continuación, se detallan sus características técnicas, arquitectura, proceso de instalación, casos de uso y buenas prácticas para aprovechar al máximo esta plataforma.

Características principales

Wazuh incorpora múltiples funcionalidades de seguridad que la convierten en una solución integral para equipos de ciberseguridad. Entre las capacidades más destacadas se incluyen la detección de intrusiones, el cumplimiento normativo, el análisis de logs, el monitoreo de integridad de archivos, la respuesta ante incidentes y la detección de vulnerabilidades, entre otras. A continuación, se describen estas funciones clave con mayor detalle:

Detección de intrusiones

Una de las funciones centrales de Wazuh es la detección de intrusiones en tiempo real a nivel de host. La plataforma está diseñada para identificar actividades maliciosas y comportamientos sospechosos conforme ocurren, empleando una combinación de análisis de registros, monitoreo de integridad de archivos y detección de patrones anómalos de comportamiento [1]. El motor de análisis del Wazuh Manager aplica miles de reglas de correlación (predefinidas y personalizables) que examinan los eventos del sistema en busca de indicadores de intrusión. Esto permite, por ejemplo, detectar intentos de acceso no autorizados, escaladas de privilegios, ejecuciones de comandos inusuales o la presencia de rootkits en un endpoint. Cuando un conjunto de eventos coincide con alguna regla (por ejemplo, varios intentos fallidos de login seguidos de un acceso exitoso anómalo), Wazuh genera de inmediato una alerta clasificada por severidad. Gracias a esta correlación basada en reglas, la plataforma puede identificar ataques complejos y amenazas persistentes que podrían pasar desapercibidos con monitoreo manual.

Wazuh actúa, por tanto, como un sistema de detección de intrusos host-based, monitorizando continuamente la actividad de los endpoints protegidos. Su base de reglas integra tanto firmas de amenazas conocidas (p. ej., huellas de malware o exploits comunes) como detección de anomalías (p. ej., comportamiento fuera de lo habitual de un proceso del sistema). Es importante destacar que estas reglas pueden adaptarse al entorno: los analistas tienen la capacidad de ajustar umbrales, desactivar reglas irrelevantes o añadir reglas personalizadas para cubrir casos específicos. En resumen, Wazuh brinda una capacidad robusta de detección temprana de intrusiones, funcionando como los “sentidos” del equipo de seguridad en cada sistema monitorizado.

Cumplimiento normativo

Además de detectar amenazas, Wazuh ayuda a las organizaciones a cumplir con normas y estándares de seguridad. La plataforma incluye módulos de auditoría de configuración y políticas que facilitan la adaptación a marcos regulatorios como PCI DSS, GDPR, HIPAA, ISO 27001, NIST 800-53, entre otros [3]. Por ejemplo, Wazuh posee un componente de Security Configuration Assessment (SCA) que realiza verificaciones periódicas del sistema contra guías de seguridad (como los benchmarks de CIS) para identificar configuraciones débiles o no conformes [6]. Esto permite detectar desviaciones de políticas internas o requisitos regulatorios (por ejemplo, configuración incorrecta de contraseñas, puertos inseguros abiertos, servicios no autorizados ejecutándose, etc.) y generar alertas con recomendaciones para endurecer la seguridad.

Otra aportación clave de Wazuh al cumplimiento normativo es la conservación centralizada de registros y eventos de seguridad. La plataforma registra y almacena de forma segura todos los eventos relevantes en una base de datos indexada, lo cual es esencial para propósitos de auditoría. Por ejemplo, en entornos regulados se exige conservar evidencia de accesos, cambios de configuración y otras actividades; Wazuh facilita esto al centralizar los logs y garantizar su integridad [3]. Estos registros unificados pueden usarse para generar informes de cumplimiento y demostrar a auditores externos que se están monitoreando los controles de seguridad requeridos. Adicionalmente, Wazuh ofrece plantillas de reglas alineadas con estándares comunes –el conjunto de reglas por defecto cubre requisitos técnicos de PCI DSS, HIPAA, GDPR, etc.– de modo que muchas detecciones vienen ya mapeadas a controles específicos de dichas normativas [8]. En conjunto, mediante monitoreo continuo, auditorías automatizadas y generación de evidencias, Wazuh se convierte en una herramienta eficaz para sostener el cumplimiento de marcos regulatorios de seguridad.

Análisis de logs

El análisis de logs es otra piedra angular de Wazuh. La plataforma recopila y analiza registros de eventos provenientes de una amplia gama de fuentes: sistemas operativos, aplicaciones, dispositivos de red, soluciones de seguridad perimetral, entre otros [1]. Estos logs contienen información vital que puede indicar amenazas –por ejemplo, intentos repetidos de autenticación fallida, errores de aplicaciones que sugieran explotación, o cambios sospechosos en servicios del sistema–. El agente de Wazuh en cada endpoint intercepta dichos eventos (leyendo archivos de log locales, entradas del registro de Windows, etc.) y los envía al servidor para su decodificación. Wazuh incluye decodificadores predefinidos que interpretan el formato de logs comunes (syslog, event logs de Windows, logs de aplicaciones web, etc.) y extraen los campos relevantes para su análisis.

Un valor añadido importante es que Wazuh admite también fuentes sin agente. Dispositivos como firewalls, IDS/IPS de red, routers o switches pueden integrarse enviando sus eventos vía Syslog al servidor Wazuh, donde serán igualmente procesados [5]. Esto permite centralizar en Wazuh la observación de prácticamente cualquier evento de seguridad de la infraestructura. Toda la información recopilada se almacena en un índice unificado, lo que habilita búsquedas y correlaciones entre diferentes fuentes. Por ejemplo, un analista podría buscar en Wazuh todas las ocurrencias de una IP específica a través de logs de firewall, servidor y base de datos simultáneamente, algo inviable si los logs estuvieran aislados en cada sistema.

En resumen, Wazuh actúa como un sistema central de análisis de registros, rompiendo los silos de información. Su capacidad de ingestión y normalización de grandes volúmenes de datos en tiempo real [1] proporciona a los equipos de seguridad una visibilidad completa de la actividad en la red. Esto no solo permite detectar eventos maliciosos, sino también usar la plataforma como herramienta de investigación forense tras un incidente, al tener un historial consultable de todo lo ocurrido en los sistemas monitoreados.

Monitoreo de integridad de archivos

La función de monitoreo de integridad de archivos (FIM) de Wazuh permite detectar alteraciones no autorizadas en archivos y directorios importantes del sistema. El agente Wazuh vigila en tiempo real los ficheros críticos (por ejemplo, binarios del sistema, configuraciones sensibles, scripts en servidores web, registros, etc.) y genera eventos cuando ocurren cambios como modificaciones, creaciones o eliminaciones de archivos. Esto es crucial para identificar ataques dirigidos a la manipulación de datos o la persistencia maliciosa en un sistema [1]. Por ejemplo, si un atacante inserta una puerta trasera modificando un binario del sistema o cambiando una entrada en /etc/passwd, Wazuh lo detectará y alertará inmediatamente.

El módulo FIM reporta detalles completos de cada cambio detectado, incluyendo qué archivo cambió, el usuario o proceso que realizó la alteración, la fecha y hora exacta, e incluso puede mantener una suma de verificación o hash del contenido para comparar versiones [6]. Internamente, Wazuh mantiene una base de datos de la última huella conocida de los archivos monitoreados, de modo que cualquier discrepancia nueva se identifica con precisión. Esta capacidad resulta invaluable para descubrir intrusiones sutiles (por ejemplo, la sustitución de un ejecutable por una versión troyanizada) así como para cumplir requisitos específicos de integridad (PCI DSS requerimiento 11.5 exige monitorear la integridad de archivos críticos). Los administradores pueden configurar qué rutas del sistema son vigiladas por FIM y excluir aquellas que generen cambios legítimos frecuentes para evitar ruido. En entornos corporativos, típicamente se monitorean rutas como /etc/ (configuración), /bin/ y /usr/bin/ (ejecutables), registros del sistema, y otras ubicaciones donde una alteración inadvertida puede indicar compromiso. Gracias a Wazuh FIM, cualquier modificación fuera de proceso de cambio aprobados será detectada y notificada, proporcionando un nivel adicional de seguridad contra ataques que impliquen cambio de ficheros o introducción de malware.

Respuesta ante incidentes

Wazuh no solo detecta los ataques, sino que también puede responder automáticamente para contenerlos o mitigarlos. Esta capacidad se materializa a través del módulo de Respuesta Activa (Active Response), que permite ejecutar acciones predefinidas cuando se dispara cierta alerta o condición. En otras palabras, Wazuh puede comportarse como un sistema IPS (Intrusion Prevention System) básico en el endpoint, tomando medidas inmediatas ante amenazas identificadas. Por ejemplo, si Wazuh detecta que una dirección IP externa está lanzando un ataque de fuerza bruta contra un servidor, puede automáticamente añadir una regla de firewall para bloquear esa IP durante un tiempo determinado. Del mismo modo, ante la detección de un malware, el agente Wazuh podría aislar o eliminar el archivo malicioso involucrado, o si un proceso sospechoso se está ejecutando, podría enviar una orden para terminar dicho proceso.

Esta automatización de la respuesta se configura mediante scripts y políticas definidos por el administrador de seguridad. Wazuh trae integraciones listas para acciones comunes, como bloquear IPs (ej. vía iptables en Linux o Firewall de Windows), detener servicios, desconectar un sistema de la red, etc. [1, 6]. Un caso de uso típico es la integración con herramientas de protección de endpoints: Wazuh puede enviar órdenes a soluciones EDR/antivirus para que escaneen o pongan en cuarentena un host cuando sus alertas sugieren una infección activa. Gracias a estas respuestas activas, se logra contener en segundos una amenaza que de otro modo requeriría intervención manual. Es importante usarlas con prudencia (para evitar bloquear algo legítimo por error), pero bien afinadas, actúan como un “reflejo” de defensa de la infraestructura.

Un ejemplo concreto: si un ransomware comienza a cifrar archivos en un servidor, el monitoreo de integridad de Wazuh podría detectar la actividad anómala en múltiples ficheros; inmediatamente, Active Response podría deshabilitar la cuenta del usuario afectado o aislar el host de la red para frenar la propagación. En definitiva, la respuesta ante incidentes en Wazuh cierra el ciclo de seguridad al pasar de la detección a la acción, permitiendo una remediación rápida incluso fuera de horario o sin intervención humana directa.

Detección de vulnerabilidades

Como complemento a sus capacidades de monitoreo, Wazuh incluye un módulo de detección de vulnerabilidades que ayuda a identificar software vulnerable en los sistemas monitoreados. Esta funcionalidad, conocida como Vulnerability Detector, compara la información de los paquetes y aplicaciones instaladas en cada endpoint contra múltiples bases de datos de vulnerabilidades conocidas (como la NVD –National Vulnerability Database–, alertas de distribuciones Linux, Microsoft, etc.) [7]. El agente Wazuh recopila periódicamente el inventario de software (nombres, versiones, paquetes) y envía esos datos al manager, donde se cruzan con los feeds de vulnerabilidades. Si se encuentra que una versión instalada corresponde con una vulnerabilidad reportada (identificada por un CVE), Wazuh genera una alerta detallando el hallazgo: CVE, gravedad, descripción y recomendaciones de actualización.

Gracias a este módulo, Wazuh proporciona visibilidad sobre los puntos débiles conocidos de los sistemas antes de que sean explotados. En lugar de depender solo de detectar comportamientos anómalos (que indican ataques en curso), Wazuh también avisa proactivamente de qué sistemas necesitan parches o actualizaciones de seguridad. Por ejemplo, si se divulga una vulnerabilidad crítica en Apache o OpenSSL, el administrador de Wazuh podrá ver inmediatamente qué servidores tienen versiones afectadas y tomar acción antes de que ocurra un ataque. Las alertas de vulnerabilidades pueden priorizarse según su criticidad (CVSS) para enfocar la gestión de parches.

Adicionalmente, estas detecciones de vulnerabilidades contribuyen al cumplimiento normativo: muchos estándares requieren mantener un proceso de gestión de vulnerabilidades; Wazuh automatiza buena parte de ese proceso al identificar y reportar los hallazgos. En ambientes muy regulados, esta capacidad se combina con auditorías de configuración para lograr una visión completa de la postura de seguridad. Cabe destacar que Wazuh se enfoca en vulnerabilidades de software ya instalado (no es un escáner de puertos o de pentesting en red), por lo que complementa pero no reemplaza otras herramientas de análisis de vulnerabilidades. Aun así, su integración en la plataforma ofrece una manera conveniente de mantener el inventario de parches al día. En conjunto, Wazuh no solo detecta amenazas activas, sino que también evalúa de forma continua la exposición a vulnerabilidades de los sistemas, ayudando a cerrar brechas de seguridad antes de que sean explotadas [3].

Arquitectura técnica

La arquitectura de Wazuh (véase la Figura 1) se basa en una comunicación cliente-servidor distribuida en cuatro componentes principales: agentes, servidor (manager), indexador y dashboard. Cada uno desempeña un rol específico dentro del flujo de datos de la plataforma.

En términos generales, los agentes desplegados en los endpoints recolectan la información y la envían al servidor Wazuh para su análisis; el servidor corre el motor de detección y luego envía los resultados (eventos y alertas) a un almacenamiento indexado; finalmente, el dashboard web permite a los usuarios consultar y visualizar toda esa información en forma unificada. A continuación, se describe cada componente y la interacción entre ellos:

• Agente Wazuh: es un servicio ligero que se instala en cada host o endpoint que deseamos monitorizar (ya sea un servidor, máquina virtual, equipo de escritorio, instancia cloud, contenedor, etc.). Su función es recopilar datos de seguridad localmente y enviarlos al servidor central. El agente intercepta logs del sistema, eventos del kernel, entradas de los registros de aplicaciones, cambios en archivos, información de estado del sistema (procesos, puertos abiertos, etc.) y cualquier otro dato relevante mediante sus distintos módulos. Estos eventos son preprocesados y transmitidos de forma continua al servidor Wazuh para su análisis [5]. Los agentes están disponibles para múltiples plataformas (Windows, varias distribuciones Linux, UNIX tradicionales, macOS, etc.), lo que permite una cobertura heterogénea. Por defecto, cada agente mantiene una conexión persistente cifrada con el manager y puede recibir de este último configuraciones o comandos (por ejemplo, para activar una respuesta activa). Cabe mencionar que dispositivos que no pueden tener un agente (p.ej. equipos de red) pueden enviar logs vía protocolo Syslog a un agente intermediario o directamente al servidor, logrando una integración incluso de equipos agentless.

En definitiva, el agente Wazuh actúa como el sensor local en cada sistema monitorizado, encargándose tanto de la recolección de datos de seguridad como de la ejecución de acciones (p. ej. respuestas activas) ordenadas por el servidor.

• Servidor Wazuh (Manager): es el núcleo central de la plataforma. En el servidor Wazuh reside el motor de análisis y correlación que procesa todos los eventos recibidos de los agentes. El manager decodifica los datos entrantes, aplica las reglas de detección sobre esos eventos y genera alertas cuando se cumplen condiciones de amenaza o anomalía [2]. Es decir, aquí es donde “cobra vida” la inteligencia de detección definida por Wazuh. El servidor también agrega los logs de todos los agentes, manteniendo un registro consolidado. Arquitectónicamente, el Wazuh Manager incluye varios subcomponentes: el servicio ossec-analysisd (analiza eventos contra las reglas), ossec-remoted (gestiona la comunicación con agentes), ossec-syscheckd (monitoreo de integridad), ossec-authd (registro de nuevos agentes), entre otros. Asimismo, en implementaciones recientes, el servidor Wazuh integra un servicio Filebeat que actúa como forwarder de los datos analizados hacia el indexador [2]. En entornos no triviales, suele haber uno o más servidores Wazuh funcionando en clúster (un nodo maestro y varios nodos trabajadores) para distribuir la carga de análisis de muchos agentes y ofrecer alta disponibilidad. El servidor Wazuh expone además una API REST segura que permite consultar y modificar la configuración, y a la cual se conectará el dashboard para tareas de administración.

En resumen, el servidor Wazuh es el “cerebro” de la plataforma: centraliza la inteligencia de detección y la coordinación con el resto de componentes.

• Wazuh Indexer: es el componente encargado del almacenamiento, indexación y búsqueda de los datos de seguridad. Wazuh Indexer está basado en Elasticsearch/OpenSearch (tecnología de búsqueda de texto completo y análisis de datos en tiempo real) y recibe todos los eventos y alertas procesados por el manager, indexándolos para hacerlos consultables de manera eficiente [9]. Cada alerta de seguridad generada por Wazuh, así como los logs archivados, se almacenan en índices de este motor, permitiendo posteriormente realizar búsquedas complejas, agregaciones, filtrados por campos, etc. El indexador es fundamental para poder manejar grandes volúmenes de datos y retener históricos de eventos. Soporta despliegues multinodo en clúster –varios nodos de indexación compartiendo índices y replicando datos– lo cual es recomendado en entornos con cientos de agentes o alto volumen de logs, para asegurar escalabilidad y alta disponibilidad [5]. En instalaciones pequeñas puede bastar un solo nodo indexador. Este componente generalmente corre en un servidor dedicado (o varios), separado del manager, dada la intensidad de I/O y CPU/RAM que requiere el motor de búsqueda. El Wazuh Indexer expone interfaces (API REST, puerto 9200) para la ingestión y consulta de datos; sin embargo, los usuarios finales no interactúan directamente con él, sino a través del dashboard o las herramientas de Wazuh. Su mantenimiento implica gestión de índices (rotación, purgado de datos antiguos, etc.) para lo cual ofrece herramientas integradas. En suma, el indexador Wazuh actúa como la base de datos central de seguridad, almacenando de forma estructurada los eventos y proporcionando capacidades de análisis forense y generación de reportes sobre los mismos.
• Wazuh Dashboard: es la interfaz web que permite a usuarios y administradores interactuar con la plataforma de forma amigable. Consiste en un panel de control web donde se visualizan las alertas, gráficos, estadísticas y estados de los agentes en tiempo real, y desde el cual se pueden configurar diversos aspectos del sistema. El dashboard se comunica internamente con el servidor Wazuh mediante llamadas a la API REST (que por defecto escucha en el puerto 55000/TCP) para obtener información de estado, configuración e inventario de agentes [5]. También realiza consultas al Wazuh Indexer (de forma transparente para el usuario) para buscar y filtrar eventos históricos que alimentan las vistas y gráficos. La autenticación al dashboard está protegida con usuario/contraseña, y la comunicación es cifrada por TLS. A través de esta interfaz, un analista puede navegar por las secciones de Alertas (donde aparece cada evento disparado con su nivel de gravedad, agente origen, regla asociada, etc.), Gráficos o dashboards personalizables (por ejemplo, número de eventos por tipo, top 10 IPs bloqueadas, nivel de cumplimiento de políticas en los agentes, etc.), Gestión de Agentes (estado de cada agente, última vez visto, versión, sistema operativo, posibilidad de agregar/eliminar agentes, agruparlos, etc.), Configuración (editar ficheros de configuración de Wazuh, reglas locales, listas blancas, etc.), entre otras opciones. El Wazuh Dashboard simplifica la operación diaria, evitando tener que revisar archivos de log manualmente en el servidor. Además, permite algunas acciones de administración, como activar/desactivar reglas, lanzar tareas de escaneo de vulnerabilidades bajo demanda, gestionar usuarios del propio dashboard, y configurar integraciones (p.ej., definir un conector para Slack o e-mail para el envío de alertas).

En definitiva, el Dashboard es la capa visual y de gestión de Wazuh, imprescindible para aprovechar cómodamente toda la información recopilada y analizada por la plataforma.

Flujo de datos y comunicaciones: Los componentes de Wazuh se comunican entre sí mediante canales seguros. Tipícamente, cada agente establece una conexión con el servidor por el puerto 1514/TCP (configuración por defecto) para el envío constante de eventos [5]. Esta comunicación agente-manager está cifrada con AES-256 (mediante un protocolo propio de Wazuh) utilizando claves únicas por agente, lo que garantiza la confidencialidad e integridad de los datos transmitidos [4]. Adicionalmente, el proceso de registro inicial de un agente con el manager implica un intercambio de claves precompartidas o tokens de autenticación, de modo que solo agentes autorizados puedan unirse. Por su parte, el servidor Wazuh, una vez que analiza los eventos, utiliza Filebeat para reenviar las alertas y logs al Wazuh Indexer mediante una conexión TLS segura (HTTPS) al puerto 9200/TCP [5]. Esto añade una capa adicional de cifrado y autenticación cuando el almacenamiento de datos reside en otro host. En caso de que servidor e indexador se ubiquen en el mismo equipo, la comunicación puede ser interna, pero igualmente cifrada. Los nodos del clúster de servidores Wazuh (si existe más de uno) se sincronizan entre sí mediante conexiones TLS, replicando información de estado, claves de agentes y asegurando la conmutación por error (o Failover) transparente. Finalmente, el acceso de los usuarios al dashboard web se realiza vía HTTPS (típicamente el dashboard escucha en el puerto 443/TCP o 5601/TCP según la configuración) y todas las peticiones del dashboard hacia el backend viajan cifradas (TLS) y requieren autenticación. Gracias a este diseño, todas las comunicaciones en Wazuh están autenticadas y cifradas ya sea con AES o TLS, protegiendo los datos tanto en tránsito como en almacenamiento [4].

En una implementación de producción, se suelen separar los componentes en diferentes servidores por motivos de rendimiento y seguridad. Es una buena práctica dedicar uno o varios servidores (en clúster) para el Wazuh Manager, y uno o varios nodos separados para el Indexer, evitando que el almacenamiento de datos consuma recursos del análisis o viceversa [5]. Asimismo, para entornos de cientos o miles de agentes, la arquitectura puede escalar horizontalmente: múltiples managers distribuyendo la carga de procesamiento y múltiples nodos de indexador compartiendo la carga de indexación de datos. Esta modularidad hace a Wazuh apto para manejar desde pequeñas instalaciones (una sola máquina con todo-en-uno) hasta despliegues empresariales a gran escala.

Proceso de instalación en Linux (paso a paso)

Instalar Wazuh en un sistema Linux implica desplegar sus componentes centrales (manager, indexador y dashboard) y luego conectar los agentes de los endpoints que se deseen monitorizar. A continuación se presenta un proceso de instalación paso a paso asumiendo un entorno basado en Debian (los pasos son similares en otras distribuciones, cambiando los comandos de gestor de paquetes):

1. Preparar el repositorio e instalar la clave GPG de Wazuh: Primero, se añade el repositorio oficial de paquetes de Wazuh y su clave pública para verificar firmas. Por ejemplo, en Debian/Ubuntu se pueden ejecutar:

sudo apt-get install -y curl apt-transport-https gnupg
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

Con ello tendremos disponibles los paquetes necesarios desde los repositorios de Wazuh.

2. Instalar el Wazuh Indexer: A continuación, instalamos el componente de indexación (basado en OpenSearch) que almacenará los datos de seguridad:

sudo apt-get install -y wazuh-indexer

Este paso desplegará un servicio de Wazuh Indexer en el sistema. Durante la instalación, se configura un usuario administrador por defecto para el indexador (usualmente admin con una contraseña auto-generada que se muestra una vez). Es importante anotar las credenciales de este usuario administrador del indexador, ya que se usarán luego para conectar el manager y el dashboard.

3. Instalar el Wazuh Manager (servidor): Procedemos a instalar el servicio central Wazuh Manager junto con Filebeat (el cual reenviará eventos al indexador):

sudo apt-get install -y wazuh-manager filebeat

Esto instala y configura el servidor Wazuh. Tras la instalación, el manager genera automáticamente una clave por defecto para la API (usuario: wazuh, password: wazuh en versiones recientes, o credenciales definidas durante el proceso). Más adelante se recomienda cambiar estas credenciales por seguridad. El servicio de Filebeat también queda instalado; este se encargará de enviar los datos del manager al indexador, pero requerirá una configuración adicional en el siguiente paso.

4. Instalar el Wazuh Dashboard: Ahora instalamos la interfaz web de Wazuh (basada en Kibana/Opendistro):

sudo apt-get install -y wazuh-dashboard

Esto despliega el servicio de dashboard web. Por defecto, el dashboard suele escuchar en el puerto 5601 con conexión HTTP/HTTPS. La instalación crea un usuario administrador del dashboard (usualmente admin), inicializado con una contraseña predeterminada (por defecto admin en algunas versiones [9] o una aleatoria mostrada durante la instalación). Tomar nota de estas credenciales para el primer acceso web.

5. Configurar la comunicación segura manager-indexer: Para que el Wazuh Manager pueda enviar correctamente las alertas al Indexer, es necesario configurar Filebeat con los parámetros de conexión al indexador. Wazuh proporciona una herramienta (wazuh-certs-tool.sh) que genera certificados TLS para asegurar la comunicación entre el manager y el indexador, la cual se puede ejecutar en este punto para obtener certificados tanto para Filebeat como para el Indexer [2]. Tras generar los certificados, se deben colocar en las rutas adecuadas (por ejemplo, cert y clave del indexador en el directorio de Filebeat del manager, según documentación).

Luego, editar el archivo de configuración de Filebeat (en el manager) ubicado en /etc/filebeat/filebeat.yml para especificar la dirección del Wazuh Indexer y credenciales:

output.elasticsearch:
  hosts: ["<IP_INDEXER>:9200"]
  protocol: https
  username: "admin"
  password: "contraseña_del_indexer"

En este fichero se indica la URL (o IP) del nodo del indexador y el usuario/clave admin configurados al instalar el indexador [2, 2]. Alternativamente, es posible usar el keystore de Filebeat para no poner la contraseña en texto plano. Por ejemplo, los comandos:

filebeat keystore create 
echo "admin" | filebeat keystore add username --stdin 
echo "contraseña" | filebeat keystore add password --stdin

almacenarían credenciales cifradas, y en filebeat.yml se podrían referenciar. En cualquier caso, una vez configurado, Filebeat sabrá a qué servidor indexador enviar los datos y con qué autenticación.

Nota: Si el manager y el indexador están en máquinas separadas, asegúrate de que el puerto 9200/TCP del indexador esté accesible desde el manager y que el certificado TLS esté correctamente configurado en ambos extremos (el indexador por defecto viene con certificado autofirmado y en el manager se debe importar el certificado de la CA de Wazuh para que Filebeat confíe). En entornos de prueba, también es posible configurar salida por HTTP sin TLS, pero no es recomendable en producción.

6. Iniciar y habilitar los servicios: Con todos los componentes instalados y configurados, arrancamos los servicios y los habilitamos para inicio automático al arrancar el sistema:

sudo systemctl enable --now wazuh-indexer
sudo systemctl enable --now wazuh-manager
sudo systemctl enable --now filebeat
sudo systemctl enable --now wazuh-dashboard

Este comando pone en marcha el indexador, el manager (y su Filebeat asociado) y el dashboard web. Podemos verificar el estado de cada uno con systemctl status <servicio> o consultando los logs (p. ej. en /var/log/wazuh-indexer/ para el indexador, /var/ossec/logs/ossec.log para el manager, etc.). Tras la instalación, el indexador debería estar escuchando en su puerto (9200), el manager esperando conexiones de agentes en el puerto 1514, y el dashboard accesible vía navegador web. Por ejemplo, si instalamos todo en un servidor local, podríamos acceder al dashboard visitando https://<IP_del_Servidor>:5601/ (o la URL/puerto configurados) e iniciar sesión con las credenciales de administrador establecidas.

7. Registro de agentes en el servidor: Finalmente, para incorporar los endpoints a monitorizar, se instalan los agentes Wazuh en cada uno de ellos (siguiendo un proceso similar de agregar repo e instalar wazuh-agent en Linux o usando el instalador en Windows). Cada agente nuevo debe registrarse/autenticarse contra el Wazuh Manager. Esto puede hacerse de varias formas: usando el comando manage_agents en el servidor para agregar manualmente y generar una clave para el agente, o habilitando el servicio de registro por contraseña (authd) y usando en el agente el script de instalación con un código de registro. Por ejemplo, desde el dashboard web es posible ir a Agents > Deploy new agent, seleccionar el SO del endpoint y obtener un script o comando único de instalación/enrolamiento. Al ejecutar ese comando en el endpoint, el agente se conectará automáticamente al manager y quedará enrolado (el manager le asignará una ID y establecerá una clave única de comunicación). Tras este proceso, el agente comenzará a enviar información y aparecerá en el dashboard como activo.

Con estos pasos, se tendría un entorno básico de Wazuh funcionando: el servidor (manager) procesando datos, el indexador almacenándolos, el dashboard presentando la información, y al menos un agente enviando eventos. Desde este punto, se puede proceder a afinar la configuración y a añadir más agentes según sea necesario en la infraestructura objetivo.

Configuración básica inicial para un entorno real

Después de una instalación correcta de Wazuh, es recomendable realizar una configuración inicial para adaptar la plataforma al entorno específico y garantizar su funcionamiento óptimo en producción. Algunas de las tareas básicas de configuración inicial son:

• Incorporación de los agentes y verificación de conexión: Añadir todos los sistemas que se van a monitorizar instalando en ellos el agente Wazuh correspondiente y registrándolos en el servidor. Es importante verificar en el dashboard o mediante la API que cada agente aparece con estado “online” y está reportando datos. Se puede realizar una prueba generando un evento conocido en un endpoint (por ejemplo, forzar un inicio de sesión fallido, crear un archivo de prueba en un directorio monitoreado, etc.) y comprobar que Wazuh genera la alerta correspondiente. Esto confirma que la comunicación agente-manager-indexador-dashboard funciona correctamente.
• Ajuste de la configuración de monitoreo: Revisar y personalizar el archivo de configuración principal (ossec.conf) y archivos de políticas en el manager para adecuarlos a las necesidades del entorno. Por ejemplo, definir rutas de logs adicionales que se deban vigilar (usando la etiqueta <localfile> para incluir, p.ej., logs de aplicaciones propias), ajustar qué extensiones de archivo ignorar en el monitoreo de integridad, o activar módulos opcionales como el monitoreo de registro de Windows (si se tienen agentes Windows). Asimismo, se pueden cargar políticas SCA específicas si la empresa sigue cierto estándar (por ejemplo, políticas de hardening de CIS Debian, o una política interna personalizada). Esta etapa de tuning inicial asegura que Wazuh esté observando los activos más críticos y aplicando las reglas más relevantes desde el comienzo.
• Configuración de alertas y notificaciones: En un entorno real es útil integrar Wazuh con los mecanismos de notificación existentes para asegurarse de que las alertas críticas generen una respuesta oportuna. Por ejemplo, se puede configurar el envío de alertas por correo electrónico (editando la sección <global> de ossec.conf para definir un servidor SMTP y destinatarios, y asociando niveles de alerta a email), o emplear la API de Wazuh junto con webhooks para notificar a canales de Slack, Microsoft Teams u otras plataformas cuando ocurra un evento importante. Wazuh permite también ejecutar scripts locales al generarse ciertas alertas (usando active responses personalizadas) lo cual se puede aprovechar para integrarse con sistemas de ticketing. Como configuración básica, se recomienda al menos establecer notificaciones por correo para alertas de nivel alto o crítico, de modo que los incidentes graves no pasen inadvertidos fuera del dashboard.
• Gestión de usuarios y roles en el Dashboard: Al iniciar Wazuh, tanto el dashboard web como la API vienen con credenciales predeterminadas (por ejemplo, el usuario admin). En un entorno corporativo, se debe cambiar inmediatamente las contraseñas por defecto por unas seguras, y crear usuarios adicionales con roles según corresponda (analistas de seguridad, administradores, operadores de TI, etc.). El dashboard de Wazuh soporta control de acceso basado en roles, permitiendo por ejemplo crear usuarios solo-lectura que puedan ver las alertas pero no cambiar la configuración. Definir usuarios individuales ayuda también a tener trazabilidad de qué cambios se realizan en la configuración (pues quedan registrados vía API). Esta tarea inicial de asegurar las credenciales y accesos evita que actores no autorizados puedan entrar al panel de Wazuh con credenciales conocidas. También es aconsejable limitar la accesibilidad del dashboard/API en la red –por ejemplo, permitiendo su acceso solo desde la red interna de administración o vía VPN– para reducir la superficie de ataque.
• Políticas de retención y rotación de datos: Por defecto, el Wazuh Indexer almacenará todos los eventos que reciba, lo cual con el tiempo puede implicar gran volumen de datos. Como configuración inicial, conviene establecer políticas de retención acordes a las necesidades de la organización: por ejemplo, conservar 30 o 90 días de logs online en el indexador y rotar o borrar los más antiguos, o archivarlos externamente si se requieren periodos más largos (p. ej., por cumplimiento). Esto se puede lograr ajustando la configuración de índices en OpenSearch/Elasticsearch (definiendo ILM policies o utilizando scripts de curator). Implementar estas políticas desde el inicio previene problemas de almacenamiento y mantiene el rendimiento del indexador estable a lo largo del tiempo.
• Afinación de reglas y niveles de alerta: Durante las primeras semanas de operación, es recomendable observar las alertas generadas por Wazuh y ajustar el umbral de ruido mediante la modificación de las reglas. Cada entorno tiene particularidades, y es posible que inicialmente Wazuh genere advertencias de eventos que no representan riesgos reales en la organización (falsos positivos). Por ejemplo, puede ser necesario deshabilitar ciertas reglas que no apliquen (si ningún agente es Windows, las reglas de Windows pueden desactivarse), modificar la severidad de algunas alertas, o añadir filtros para ignorar eventos esperados. Wazuh permite crear un archivo de reglas locales (/var/ossec/etc/rules/local_rules.xml) donde se pueden sobreescribir las reglas existentes o agregar nuevas. Una buena práctica de configuración inicial es implementar en local_rules.xml excepciones para los falsos positivos conocidos (por ejemplo, ignorar ciertos logs de aplicación que siempre generan la misma alerta benigna) y, por el contrario, agregar reglas propias para detectar condiciones específicas de la empresa (por ejemplo, monitorear un proceso interno crítico). Este tuning inicial mejorará considerablemente la eficacia de las alertas, reduciendo el ruido y asegurando que cuando ocurre una alerta esta requiera realmente atención.
• Hardening del servidor Wazuh: Finalmente, como parte de la puesta en marcha, se debe asegurar el propio servidor que alberga Wazuh. Esto incluye aplicar actualizaciones de sistema operativo, habilitar un firewall local limitando accesos sólo a los puertos necesarios (1514/UDP-TCP, 1515, 55000, 9200, 5601, etc., según la arquitectura desplegada), y monitorear los recursos del servidor. Dado que Wazuh se convierte en una pieza crítica de la seguridad, hay que protegerlo adecuadamente: por ejemplo, cambiar los puertos por defecto podría considerarse en algunos casos, o restringir mediante iptables qué hosts pueden conectarse (ej. solo los IP de los agentes conocidos). También es importante configurar copias de seguridad periódicas de la configuración de Wazuh (los archivos de configuración, las reglas personalizadas, y posiblemente una copia de los índices si fuera necesario reconstruirlos). Estas medidas aseguran que la plataforma Wazuh en sí no sea un eslabón débil y esté preparada para operar de forma continua y segura.

Con estas configuraciones iniciales, Wazuh quedará mejor alineado con el entorno productivo en el que se despliega. A partir de aquí, la plataforma podrá ser operada eficientemente: los analistas deberán monitorear las alertas entrantes, responder a ellas según los procedimientos definidos, y ajustar continuamente la configuración a medida que evolucione la infraestructura o aparezcan nuevas amenazas. Wazuh ofrece mucha flexibilidad, por lo que la fase inicial de ajuste es clave para sacar el máximo provecho con el mínimo de falsos positivos.

Ejemplos concretos de uso

A continuación se presentan algunos casos de uso prácticos de Wazuh en escenarios de seguridad, ilustrando cómo la plataforma aporta valor en la detección de amenazas, el cumplimiento de normativas, el análisis de logs y la correlación de eventos en un entorno real:

Detección de amenazas en tiempo real

Caso: Una empresa desea detectar intentos de intrusión en sus servidores de forma temprana, por ejemplo ataques de fuerza bruta SSH o comportamientos anómalos que puedan indicar una cuenta comprometida.

Cómo ayuda Wazuh: Gracias a sus reglas de correlación, Wazuh puede identificar patrones de ataque distribuidos en el tiempo o en múltiples fuentes. Por ejemplo, si un atacante realiza numerosos intentos fallidos de inicio de sesión SSH contra un servidor Linux y eventualmente logra acceder, Wazuh correlacionará los eventos de autenticación fallida seguidos del acceso exitoso y generará una alerta de alta prioridad por posible ataque de fuerza bruta. Del lado del agente, cada intento fallido aparece en el log del sistema (auth.log); el agente envía esos eventos y el manager aplica una regla que cuenta el número de fallos desde una misma IP en un intervalo corto. Al exceder el umbral (por ejemplo 5 intentos en 2 minutos) se dispara la alerta. Seguidamente, el registro del “login exitoso” desde esa IP completa el patrón indicando intrusión, lo que Wazuh eleva a incidente grave. Inmediatamente, se podría activar una respuesta activa: el agente puede ejecutar un script que agregue la IP ofensora a iptables bloqueándola automáticamente.

Otro ejemplo: Supongamos que en un servidor se produce una escalada de privilegios –un usuario normal consigue ejecutar un comando como root fuera de procedimientos normales–. Wazuh detectaría esto porque el módulo de log analysis capturaría un mensaje de sudo o un cambio de UID en los logs, y una regla específica alertaría sobre la elevación de privilegios inesperada. La alerta incluiría información como el usuario involucrado y el comando ejecutado. El equipo de seguridad, al recibirla, podría rápidamente iniciar una investigación o contener al usuario en cuestión.

De igual forma, Wazuh es efectivo detectando indicadores de malware: si un proceso empieza a ocultarse o se crean conexiones a dominios conocidos por ser de comando y control (C&C), las reglas de Wazuh (alimentadas por listas de IoCs y threat intelligence) reconocerán esos patrones. Por ejemplo, la aparición de un proceso con nombre similar a svchost pero ejecutado desde un directorio inusual en Windows generaría una alerta de posible troyano. En resumen, en el día a día Wazuh actúa como un sistema nervioso que reacciona en tiempo real a las señales de ataque en los equipos, permitiendo al equipo de seguridad detectar y cortar incidentes en sus fases iniciales.

Cumplimiento de PCI DSS en una red de servidores

Caso: Una compañía que maneja datos de tarjetas de pago debe cumplir con el estándar PCI DSS 4.0. Entre otras cosas, necesita: monitorear todos los accesos a los sistemas que procesan datos de tarjeta, asegurar la integridad de archivos sensibles, y demostrar mediante auditorías que dichas medidas están implementadas.

Cómo ayuda Wazuh: Wazuh puede ser configurado para cubrir múltiples requisitos de PCI DSS de forma integrada. Para el Requisito 10 (Seguimiento y monitorización de todos los accesos a recursos de la red y datos de titulares de tarjeta), Wazuh actúa como un SIEM que recopila todos los eventos de los servidores en el entorno de pago. Cada inicio de sesión, cambio de cuenta o acceso a datos sensibles queda registrado en Wazuh (vía los logs del sistema operativo o de las aplicaciones) y puede generar alertas en caso de actividades sospechosas (por ejemplo, intento de uso de cuentas por defecto, accesos fuera de horario, etc.). La empresa puede luego usar el dashboard de Wazuh para generar reportes periódicos de quién accedió a qué, facilitando las auditorías de cumplimiento.

En cuanto al Requisito 11.5 (Implementar monitoreo de integridad de archivos), Wazuh cubre esto directamente con su módulo FIM. Configurando el agente para vigilar los archivos y directorios que PCI DSS considera críticos (por ejemplo, archivos de configuración de seguridad, registros de auditoría, tablas de base de datos de tarjetas, scripts que manejan datos de tarjeta, etc.), cualquier modificación no autorizada será detectada [1]. Wazuh alertará si, por ejemplo, alguien edita un archivo de configuración del sistema de pagos o altera los binarios de la aplicación que procesa las tarjetas, cumpliendo así el control requerido. Estos avisos pueden integrarse en el proceso de gestión de cambios de la empresa para verificar que todo cambio en dichos archivos fue planeado y aprobado.

Adicionalmente, Wazuh cuenta con políticas SCA específicas para PCI DSS. Al habilitarlas, el agente evalúa configuraciones del sistema (fortaleza de contraseñas, cifrado TLS habilitado, configuración de logging adecuada, etc.) y reporta el nivel de cumplimiento. Esto ayuda con el Requisito 2 (No usar configuraciones por defecto inseguras) y otros, ya que puede detectar si algún servidor tiene ajustes fuera de las prácticas seguras exigidas. La plataforma ofrece dashboards de cumplimiento donde se ve el porcentaje de controles PCI cumplidos por cada host.

En resumen, al desplegar Wazuh en todos los sistemas del Cardholder Data Environment, la compañía obtiene un monitoreo centralizado continuo que satisface muchas de las obligaciones de PCI DSS. Tendrán registros completos y seguros de los eventos (con retención suficiente), alertas en tiempo real de violaciones a políticas, y podrán demostrar a un auditor externo, con reportes de Wazuh, que cuentan con mecanismos automáticos de detección de intrusiones y de integridad de archivos [8]. Esto reduce significativamente el esfuerzo manual de cumplimiento y eleva el nivel de seguridad de la red de acuerdo con los estándares de la industria de pagos.

Análisis centralizado de logs tras un incidente

Caso: Se sospecha que una cuenta interna ha sido comprometida en la red de la organización, debido a actividades inusuales. El equipo de seguridad necesita revisar los logs de múltiples servidores y aplicaciones para trazar las acciones realizadas por el usuario sospechoso en un periodo determinado.

Cómo ayuda Wazuh: Con Wazuh implementado, el equipo de seguridad dispone de todas las evidencias centralizadas y accesibles desde una única interfaz, en lugar de tener que recolectar logs manualmente de cada sistema. Usando el visor de eventos o la funcionalidad de búsqueda del Wazuh Dashboard (o directamente consultando el indexador con consultas Elasticsearch/OSQL), los analistas pueden buscar el identificador de la cuenta sospechosa y obtener resultados inmediatos de todos los eventos relacionados a ella en distintos sistemas. Por ejemplo, podrían filtrar por el nombre de usuario en los logs y ver: intentos de autenticación en servidores Linux, accesos RDP en servidores Windows, comandos ejecutados con sudo en alguna máquina, accesos a bases de datos, etc., todos listados cronológicamente.

Wazuh indexa eventos con metadatos de origen (fecha, host, aplicación, tipo de evento, usuario, etc.), lo que permite hacer consultas muy específicas. El analista podría preguntar: “muéstrame todas las acciones del usuario juan.perez en cualquier sistema durante la última semana”. En segundos obtendrá un panorama consolidado. Supongamos que la cuenta comprometida fue usada para extraer información: buscando por ese usuario, se descubre que ha iniciado sesión en un servidor al que normalmente no accede, luego se observan varios comandos de archivado y transferencia de ficheros (capturados en el log de bash history o auditd), y finalmente accesos a un servidor de ficheros corporativo fuera del horario habitual. Toda esa secuencia, que manualmente sería difícil de ensamblar, se vuelve evidente mediante el análisis transversal que posibilita Wazuh.

Además, Wazuh conserva los logs históricos de forma íntegra. Si el atacante intentó borrar trazas en un servidor comprometido, es muy probable que los eventos ya hubiesen sido enviados al Wazuh Manager antes de ser borrados localmente. Por tanto, los registros en Wazuh actúan como una caja negra forense. El equipo de respuesta a incidentes puede extraer de Wazuh los logs necesarios para sus reportes post-incidente, e incluso utilizar las capacidades de exportación (por ejemplo, exportar resultados de búsqueda a JSON/CSV) para entregar evidencias. En este caso, Wazuh agiliza en gran medida el análisis forense, reduciendo horas de trabajo en correlacionar archivos de log y ayudando a entender el alcance completo del incidente (qué sistemas tocó la cuenta comprometida, qué hizo, qué datos pudo haber accedido o exfiltrado, etc.).

Correlación de eventos de seguridad distribuidos

Caso: Una amenaza avanzada logra infiltrar la red haciendo uso de múltiples vectores. Por ejemplo, se observa actividad sospechosa en el firewall perimetral (posibles escaneos), luego algunos equipos internos empiezan a comunicar con un servidor externo desconocido, y finalmente se detectan movimientos laterales dentro de la red. La detección de este tipo de ataque requiere correlacionar eventos dispares.

Cómo ayuda Wazuh: La correlación multi-fuente es una de las fortalezas de Wazuh. La plataforma puede combinar eventos de diferentes dispositivos y momentos para inferir patrones complejos de ataque [1]. En el escenario descrito, Wazuh recibiría, por un lado, los logs del firewall (via Syslog) indicando que la IP X realizó un escaneo de puertos contra varios hosts internos. Quizá eso por sí solo genere una alerta de severidad baja (escaneo detectado). Horas más tarde, en los logs de endpoints, los agentes Wazuh reportan conexiones de esos mismos hosts internos hacia la IP X por puertos inusuales, lo que activa otra alerta (posible comunicación C&C). Finalmente, se registran en Active Directory intentos de autenticación con múltiples cuentas desde un host interno comprometido (movimiento lateral), produciendo alertas adicionales. Wazuh es capaz de correlacionar todos estos eventos –que comparten un hilo conductor, la IP X del atacante y patrones temporales– y elevar un alerta unificada de mayor nivel, identificando que hay probablemente un mismo incidente orquestado en curso.

Gracias a su motor de reglas jerárquicas, Wazuh puede escalar la criticidad cuando ocurren ciertas secuencias. Por ejemplo, puede haber una regla que diga: “Si se detecta escaneo de puertos desde una IP y en las siguientes 24 horas esa misma IP aparece en una alerta de malware o en un intento de login interno, generar una alerta de ataque dirigido”. De esta forma, aunque cada evento por separado pudiera considerarse de nivel moderado, la correlación indica algo más grave y Wazuh avisa en consecuencia. Esto es invaluable para detectar amenazas avanzadas persistentes (APT), que típicamente realizan reconocimiento, luego intrusión, luego expansión.

Otro caso de correlación es entre distintos niveles de la pila. Wazuh puede correlacionar, por ejemplo, eventos del sistema operativo con eventos de una aplicación. Imaginemos un ataque SQL injection a una aplicación web: Wazuh podría correlacionar un patrón malicioso en el log de Apache (entrada con ' OR '1'='1 o similares) con un mensaje de error en el log de la base de datos y con un aumento de privilegios en el sistema operativo, todo ello para concluir que el ataque web logró comprometer el sistema. Esta visión holística es posible porque Wazuh ve todas las capas y tiene las reglas para relacionar eventos. La ventaja para el equipo de seguridad es enorme: en lugar de recibir alertas aisladas de distintos sistemas, Wazuh entrega una historia consolidada del incidente, facilitando la comprensión y respuesta.

En resumen, mediante la correlación avanzada de eventos, Wazuh permite detectar ataques complejos y distribuidos que de otra forma podrían pasar desapercibidos. Su capacidad de combinar información de firewalls, sistemas, aplicaciones y usuarios le da un contexto mucho más rico a cada alerta, reduciendo la carga de análisis manual para el equipo de seguridad.

Buenas prácticas y recomendaciones para entornos productivos

Al implementar Wazuh en un entorno de producción, conviene seguir una serie de buenas prácticas para garantizar un despliegue seguro, eficiente y sostenible. A continuación se enumeran recomendaciones clave:

• Separación de componentes y alta disponibilidad: En producción, se debe instalar el Wazuh Manager (servidor) y el Wazuh Indexer en servidores distintos para distribuir la carga y mejorar la resiliencia. Esto evita que un uso intensivo del indexador afecte el rendimiento del análisis en el manager y viceversa. Además, se debe considerar desplegar un clúster de managers (un nodo maestro y nodos worker) si se tienen muchos agentes, así como un clúster de nodos indexadores para balancear la indexación de grandes volúmenes de datos [5]. La arquitectura distribuida con múltiples nodos asegura continuidad de servicio ante la caída de alguno y soporta mejor el crecimiento futuro de la infraestructura.
• Seguridad en las comunicaciones: Asegúrese de mantener cifradas y autenticadas todas las comunicaciones entre componentes de Wazuh. Por defecto, Wazuh cifra el tráfico agente-manager con AES-256 [5], y utiliza TLS en la comunicación manager-indexer y dashboard-API. Use siempre certificados válidos o autofirmados confiables para estas conexiones (puede usar las utilidades provistas por Wazuh para generarlos). Si envía logs de dispositivos vía Syslog, hágalo sobre TLS o a través de un agente Wazuh para no transmitir datos en claro. Asimismo, mantenga seguras las claves y certificados (por ejemplo, protegiendo el archivo client.keys que almacena las claves de agentes, restringiendo permisos de archivos de configuración, etc.). Todas las comunicaciones de Wazuh deben permanecer cifradas para impedir intercepciones o alteraciones [4].
• Gestión de contraseñas y accesos: Cambie todas las contraseñas predeterminadas tras la instalación (usuario admin del dashboard, credenciales de API wazuh:wazuh si aplicara, usuario admin del indexador, etc.). Defina contraseñas robustas que cumplan buenas prácticas (longitud, complejidad) y guárdelas de forma segura. Implemente usuarios individuales con los privilegios mínimos necesarios en el Dashboard y API. Por ejemplo, entregue accesos de solo lectura a quienes solo necesitan monitorear alertas, y privilegios de administrador solo a personal autorizado para cambiar la configuración. Revise periódicamente estos accesos y deshabilite o elimine cuentas que ya no se usen (p. ej., si un empleado con acceso se retira). Esto reduce la superficie de ataque en la propia plataforma Wazuh y mejora la trazabilidad de acciones (cada cambio queda asociado a un usuario distinto).
• Actualizaciones periódicas: Mantenga Wazuh actualizado a la última versión estable. El equipo de Wazuh publica actualizaciones frecuentes del software que incluyen nuevas funcionalidades, mejoras de rendimiento y parches de seguridad. Aplicar estas actualizaciones en tiempo razonable asegurará que su despliegue tenga las últimas reglas de detección y esté protegido contra vulnerabilidades conocidas en la propia plataforma. Del mismo modo, actualice los agentes en los endpoints cuando actualice el manager para aprovechar las mejoras (Wazuh provee mecanismos para autoactualizar agentes de forma remota desde el manager/API, facilitando esta tarea). Antes de actualizar en producción, se recomienda probar la nueva versión en un entorno de prueba para detectar cualquier cambio de configuración necesario. Adicionalmente, mantenga actualizados los paquetes de listas de vulnerabilidades (Wazuh descarga periódicamente feeds de CVEs) y las reglas/reglas personalizadas conforme la comunidad las mejore.
• Monitoreo del rendimiento y capacidad: A medida que crece el número de agentes o la cantidad de logs procesados, monitoree el consumo de recursos del servidor Wazuh y del indexador. Utilice herramientas de sistema (top, htop, iostat, etc.) o monitoreo externo para vigilar CPU, memoria, disco y uso de red. Si el indexador comienza a usar >80% de su RAM, considere ampliarla o agregar nodos. Controle el tamaño de los índices en disco; implemente rotación de índices para mantener un tamaño manejable (por ejemplo, podría limitar a X GB o Y días de retención según se necesite). Verifique también la latencia de comunicación con agentes (agentes con alta latencia podrían indicar sobrecarga en el manager). En entornos críticos, habilite las alertas de integridad de Wazuh (que avisan si un agente lleva tiempo sin informar, etc.) para detectar posibles problemas. Una plataforma Wazuh bien dimensionada debe funcionar en segundo plano sin degradar los sistemas monitorizados ni dejar de procesar eventos a tiempo.
• Afinación continua de reglas (tuning): Las reglas de Wazuh abarcan muchas situaciones generales. Es importante que, una vez estabilizada la instalación, se dedique esfuerzo a afinar la política de alertas según la realidad de su entorno. Esto implica ajustar umbrales (por ejemplo, si una regla lanza alerta tras 5 intentos fallidos, quizá en su entorno necesita ser 3 o 10, según el caso), suprimir falsos positivos conocidos y añadir reglas para detectar condiciones específicas que le interesen. Mantenga un archivo local_rules.xml organizado con comentarios sobre qué se ha cambiado y por qué, para facilitar futuras actualizaciones. Revise también las decoders si tiene aplicaciones con formatos de log no estándar: podría necesitar escribir decodificadores personalizados para que Wazuh interprete correctamente ciertos eventos de aplicaciones propietarias. Esta inversión en tuning paga dividendos en reducir la fatiga de alertas y hacer que las notificaciones que lleguen al equipo sean realmente accionables.
• Integración con la respuesta a incidentes: Defina de antemano procedimientos de respuesta para las alertas de Wazuh. Por ejemplo, si Wazuh alerta un posible ransomware, ¿cuál es el plan de acción? Quizá apagar el equipo afectado y analizarlo. Si alerta una desviación de política de cumplimiento, ¿se crea un ticket para que TI corrija la configuración? Al tener claridad en la respuesta, podrá aprovechar al máximo la detección temprana. Considere también integrar Wazuh con herramientas SIEM/SOAR de nivel superior si las tiene: Wazuh puede enviar sus alertas a otro sistema central (mediante Syslog output o API) para correlacionarlas con otras fuentes. No obstante, en muchos casos Wazuh por sí solo puede ser el SIEM principal. Lo importante es que las alertas que genera desencadenen un flujo de trabajo definido y no se queden sin atender. Documente las acciones tomadas ante los incidentes detectados vía Wazuh, esto ayudará a refinar tanto las reglas como las respuestas activas a futuro.
• Seguridad del entorno Wazuh: Considere el propio sistema Wazuh como parte de la superficie a proteger. Aplíquele hardening: mínimo de servicios instalados, firewall local activo, acceso SSH restringido, etc. Mantenga a salvo las claves de los agentes (cada agente tiene una key usada para cifrar comunicaciones; si un atacante obtuviera esas keys podría potencialmente imitar a un agente). También proteja el acceso a la API Wazuh –que tiene mucho poder, incluyendo desactivar agentes o cambiar configuración– limitando qué direcciones IP pueden conectarse a ella, o requiriendo una VPN para acceso remoto. Realice copias de seguridad frecuentes de la carpeta /var/ossec/ (que contiene configuración, claves y logs locales) y, si es viable, de los índices del Wazuh Indexer (para no perder datos históricos ante un desastre). Ensaye la recuperación de Wazuh en caso de fallo total: por ejemplo, tener documentado cómo reinstalar un manager e importar la configuración y restaurar agentes sin tener que reinstalarlos uno por uno (las IDs y keys se pueden guardar). Al proteger la infraestructura Wazuh, recuerde que esta se vuelve un componente crítico: cualquier indisponibilidad o manipulación maliciosa podría dejar a ciegas la vigilancia de la red.

Aplicando estas buenas prácticas, la plataforma Wazuh operará de forma robusta y segura en entornos de producción. Se minimizarán los riesgos de desempeño o brechas de seguridad en la propia herramienta, y el equipo de seguridad podrá concentrarse en responder a las amenazas detectadas con confianza en la calidad de las alertas. Wazuh, correctamente implementado y ajustado, se convierte en un aliado invaluable para el Blue Team, elevando significativamente la postura de seguridad de la organización.

Referencias

1. Camaño JG. Hackers al ataque: Cómo Wazuh identifica ataques en tiempo real y protege tu negocio. Blog de CTL Information Technology. 11 de febrero de 2025 (Hackers al ataque: Cómo Wazuh identifica ataques en tiempo real - CTL Information Technology).
2. Fernández Durán JJ. Instalación del servidor Wazuh paso a paso en Debian/Ubuntu. Blog Binario 0. Diciembre 2024 (Instalación del servidor Wazuh paso a paso en Debian/Ubuntu - Binario 0).
3. TecnetOne. Auditoría de Seguridad en Entornos Regulados con Wazuh. Blog de TecnetOne. 2023 (Auditoría de Seguridad en Entornos Regulados con Wazuh).
4. a3Sec. Guía básica para integración de tecnologías mediante protocolo Syslog (Wazuh). Blog de a3Sec. 2021 (Guía Básica para integración de tecnologías mediante Protocolo SYSLOG).
5. Wazuh, Inc. Wazuh Documentation – Architecture. Version 4.x (documentación oficial). 2023 (Architecture - Getting started with Wazuh · Wazuh documentation).
6. Wazuh, Inc. Wazuh Documentation – Wazuh agent components (FIM, SCA, Active Response). Version 4.x. 2023 (Wazuh agent - Components · Wazuh documentation)
7. Wazuh, Inc. Wazuh Documentation – Vulnerability detection module. 2024 (Vulnerability detection - Capabilities - Wazuh documentation).
8. Wazuh, Inc. Wazuh Documentation – Regulatory compliance (use cases). 2024 (Regulatory compliance - Wazuh documentation).
9. Wazuh, Inc. Wazuh Documentation – Wazuh indexer. 2024 (Wazuh indexer - Installation guide · Wazuh documentation).