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 el CPD de Tecnidom: qué decisiones tomamos, qué pasos seguimos y qué errores encontramos por el camino.
No es una guía oficial ni la única forma de hacerlo. Es la experiencia real de cómo lo desplegamos en Tecnidom con los recursos disponibles en aquel momento.
1. Punto de partida: el NOC que ya tenía
Mi punto de partida era este:
- Proxmox como plataforma de virtualización del CPD de Tecnidom.
- 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:
- Wazuh all-in-one En la primera fase del CPD de Tecnidom optamos por un despliegue con manager + indexer + dashboard en una sola VM para simplificar la operación y validar la arquitectura antes de escalar.
- Una VM dedicada en el clúster de Tecnidom
- 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).
- 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 el repositorio de ISO 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 los servidores del CPD (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)
- Deploy new agent → Linux → DEB amd64.
- Server address: IP de mi SOC.
- Agent name: zabbix-server.
- Group: Linux.
- 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é:
- Security Configuration Assessment (SCA)
- Vulnerability Detection
- 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:
- 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.
- 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”.
- 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.
- 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 los servidores clave del CPD.
- 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á pensado para entornos muy estrictos y debe evaluarse según el contexto operativo”.
Porque si algo he aprendido con este experimento es que:
- Desplegar técnicamente un SOC 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.
Monitorización y seguridad como servicio
Wazuh y Zabbix son piezas de una operación continua. Si quieres ver cómo trasladamos esa filosofía a entornos empresariales, consulta nuestros servicios de monitorización IT y ciberseguridad para empresas.
¿Necesitas ayuda con la tecnología de tu empresa?
Podemos revisar contigo qué está ocurriendo, qué riesgos existen y por dónde tiene sentido empezar.
