Cómo monté un SOC con Wazuh junto a mi NOC con Zabbix y Grafana (en un laboratorio casero)

En el artículo anterior contaba cómo, teniendo ya un NOC montado con Zabbix + Grafana, al añadir un SOC con Wazuh descubrí que uno de mis servidores suspendía más del 55 % de los checks CIS.

En este segundo artículo no quiero quedarme en la teoría, sino contar cómo lo he montado realmente en mi laboratorio: qué decisiones tomé, qué pasos seguí y qué errores me encontré por el camino.

No es una guía oficial ni la única forma de hacerlo. Es simplemente “así lo he hecho yo, con los recursos que tenía”.

1. Punto de partida: el NOC que ya tenía

Mi punto de partida era este:

• Proxmox con un pequeño cluster de NUCs.
• Una VM con Zabbix Server (Debian 12).
• Grafana apoyándose en Zabbix para la parte de visualización.

Con eso tenía cubierto:

• Inventario y disponibilidad de servicios.
• Métricas de CPU, RAM, disco, red, etc.
• Dashboards en Grafana para ver tendencias y “vender” bien el NOC.

Lo que no tenía:

• Revisión sistemática de configuración de seguridad.
• Información centralizada de logs.
• Detección de vulnerabilidades ni correlación de eventos.

Ahí es donde entra Wazuh.

2. Decisiones de diseño antes de tocar nada

Antes de lanzar comandos, decidí tres cosas:

1. Wazuh all-in-one Para un laboratorio casero, un despliegue con manager + indexer + dashboard en una sola VM es más que suficiente. Menos piezas, menos dolor de cabeza.
2. Una VM dedicada en mi cluster

• SO: Ubuntu Server 24.04.3 LTS
• vCPU: 2
• RAM: 8 GB
• Disco: 200 GB (Ya veremos si tendré que ampliar más adelante los logs crecen rápido)
• IP fija en la misma red que Zabbix y el resto de VMs (En un artículo anterior expliqué como tengo configuradas las diferentes vlan).

1. Empezar por Linux Primero quería ver Wazuh vigilando:

• El propio servidor de Zabbix.
• El servidor de n8n. Más adelante iré añadiendo Windows server, plex, ollama, routers por syslog, etc.

En Proxmox/VMware creé una VM a la que llamé, sin mucha imaginación, soc-wazuh.

• Le asigné el disco de 200 GB y dejé que el instalador de Ubuntu hiciera el particionado con LVM.
• Le puse una IP fija en la LAN.

Aquí vino el primer error interesante:

• Probé inicialmente con una versión no LTS (Ubuntu 24.10 “oracular” la que tenía subida en mi carpeta de ISO’s de proxmox :-O ).
• Al hacer apt update me encontré con que los repos estaban ya en old-releases y faltaban ficheros Release.
• Moraleja: para un servidor de seguridad, mejor LTS y nos ahorramos sustos.

Reinstalé con Ubuntu 24.04.3 LTS, y a partir de ahí todo fue más fluido.

4. Instalación de Wazuh 4.14 en modo all-in-one

Con el sistema ya limpio y actualizado (apt update && apt upgrade -y), el despliegue de Wazuh fue bastante directo.

En la VM del SOC:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a 

El script se encargó de:

• Instalar y configurar:
• Generar el usuario admin y la contraseña inicial.
• Dejar el panel accesible en https://IP_DEL_SOC.

Una vez terminó:

• Entré por navegador a https://mi-ip:443.
• Acepté el certificado autofirmado.
• Cambié la contraseña de admin por algo razonable.

En ese momento tenía un SOC vacío: todo instalado, pero sin agentes ni datos.

5. Conectando el SOC con mis servidores (agentes Linux)

5.1. Crear el grupo “Linux”

En el dashboard de Wazuh:

• Fui a Agents management → Groups.
• Creé un grupo llamado Linux.

La idea: todo servidor Linux que añada irá a ese grupo y heredará la misma configuración de módulos (SCA, FIM, vulnerabilidades…).

5.2. Agente en el servidor de Zabbix (Debian 12)

1. Deploy new agent → Linux → DEB amd64.
2. Server address: IP de mi SOC.
3. Agent name: zabbix-server.
4. Group: Linux.
5. Copié el comando que genera Wazuh.

En el servidor Zabbix:

# Me conecté por SSH y pegué el comando generado
sudo systemctl status wazuh-agent 

Cuando vi el active (running) y el agente en verde en el panel, sabía que el SOC ya “veía” a mi Zabbix.

5.3. Agente en el servidor de n8n (Ubuntu 24.04)

Lo mismo, pero:

• Agent name: n8n-server.
• También dentro del grupo Linux.

En unos segundos tenía dos agentes activos reportando al SOC.

6. Activando los módulos que marcan la diferencia

Con los agentes vivos, el siguiente paso fue decirle a Wazuh qué quería que analizara.

Dentro del grupo Linux activé:

1. Security Configuration Assessment (SCA)
2. Vulnerability Detection
3. File Integrity Monitoring (FIM)

No toqué nada más al principio. Con solo esto ya hay material de sobra para aprender.

7. El momento “ajá”: cuando el SOC empieza a hablar

Un rato después de activar SCA, fui a:

• Endpoint security → Configuration assessment
• Elegí zabbix-server y n8n-server en el selector.

Y aparecieron las famosas gráficas:

• En Ubuntu 24.04 (n8n):
• En Debian 12 (Zabbix):

Mientras tanto:

• En Zabbix, los hosts estaban en verde.
• En Grafana, las gráficas de CPU, RAM y latencia se veían perfectas.

Esa combinación fue lo que dio origen al primer artículo: con el NOC todo parecía ok; con el SOC, quedaba claro que había mucho por endurecer.

8. Pequeñas lecciones aprendidas en el despliegue

Algunas cosas que me llevo de este montaje:

1. No subestimar las LTS Intentar montar un SOC sobre una versión no LTS me regaló problemas con repositorios EOL. Para algo de seguridad, mejor jugar sobre terreno estable.
2. Agrupar desde el principio Haber creado el grupo Linux desde el inicio hace muy fácil añadir más servidores: solo instalo el agente y lo meto en el grupo. SCA/FIM/vulnerabilidades vienen “de serie”.
3. No empezar por todo a la vez Es tentador activar todos los módulos de Wazuh de golpe, pero acabas ahogado en información. Con SCA + Vulnerabilities + FIM ya tienes mucho que masticar.
4. NOC y SOC no compiten, se complementan

9. Qué viene después

Este artículo se centraba en cómo lo he montado:

• VM de Wazuh sobre Proxmox.
• Instalación all-in-one.
• Agentes en mis servidores clave.
• Activación de SCA, FIM y vulnerabilidades.

En el siguiente paso quiero contar algo aún más práctico:

Qué checks CIS estoy aplicando (y cuáles he decidido conscientemente no tocar)

Es decir, bajar a ejemplos concretos del tipo:

• “Este check de SSH sí merece la pena en casi cualquier servidor”.
• “Este otro está bien para entornos muy estrictos, pero no lo necesito en mi lab”.

Porque si algo he aprendido con este experimento es que:

• Montar un SOC en casa es relativamente sencillo.
• Lo difícil, y lo interesante, es traducir todas esas alertas en cambios concretos que mejoren la seguridad sin complicarte la vida innecesariamente.