De NOC a NOC+SOC en casa: lo que pasó cuando añadí Wazuh a mi Zabbix

NOC+SOC

De “todo en verde” a “tienes un problema”

Como admins de sistemas nos pasa mucho: mientras el panel de Zabbix está en verde, respiramos tranquilos.

En mi caso tenía montado un NOC bastante decente en casa/lab:

  • Cluster de virtualización (Proxmox).
  • Zabbix monitorizando servidores, servicios y dispositivos de red.
  • Grafana encima, con paneles bonitos de CPU, RAM, discos, latencias, etc.

Entre Zabbix y Grafana sentía que tenía la película controlada:

  • Alertas cuando algo se caía.
  • Gráficas históricas para ver tendencias.
  • Dashboards chulos que enseñaban que “todo funciona”.

La clave está en esa última palabra: funciona.

Disponibilidad bajo control. Si algo se caía, me enteraba.

Añadiendo el SOC: Wazuh entra en juego

Quería ir más allá de la monitorización clásica, así que desplegué Wazuh como SOC:

Servidor Wazuh en una nueva VM.

Agentes en mis servidores Linux (Zabbix, n8n, etc.).

Activé módulos de:

  • Security Configuration Assessment (SCA),
  • Detección de vulnerabilidades,
  • Integración de logs y eventos de seguridad.

Todo seguía igual en Zabbix y Grafana: paneles verdes, recursos controlados, alertas silenciosas.

Hasta que lancé el primer benchmark CIS sobre uno de mis servidores.

La parte divertida vino cuando activé el primer Security Configuration Assessment (SCA) sobre uno de mis servidores Linux.

Contenido del artículo

El bofetón de realidad: CIS benchmark y un 55% de suspensos

Primera política aplicada: CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0 sobre un servidor que, sinceramente, yo consideraba “bastante limpio”.

Resultado del primer escaneo:

  • 109 checks “Passed”
  • 128 checks “Failed”
  • 42 “Not applicable”

Es decir: más de la mitad de las pruebas relevantes falladas.

Un suspenso en toda regla.

Lo irónico es que:

  • Zabbix no mostraba ningún problema.
  • Grafana enseñaba gráficas preciosas, sin picos ni alarmas.
  • El servicio funcionaba perfecto.

El NOC decía “todo OK”, pero el SOC acababa de demostrar lo contrario.

Ahí entendí de golpe la diferencia:

El NOC te dice: “todo está funcionando”.

Qué tipo de cosas empezó a sacar Wazuh

Los detalles del SCA son muy concretos. Empiezas a ver checks del estilo:

  • Opciones de montaje en /tmp, /dev/shm, /home que no son las recomendadas.
  • Servicios que no deberían estar habilitados en un servidor.
  • Permisos demasiado abiertos en ciertos archivos de configuración.
  • Parámetros de SSH que convendría endurecer.
  • Reglas de logging que se quedan cortas.

Cada check viene con:

  • Una explicación de qué está revisando.
  • La razón de seguridad.
  • Y, lo mejor, una acción de remediación sugerida.

Y aquí es donde te cae la ficha: tu infraestructura puede estar perfectamente “monitorizada”… y a la vez llena de pequeños agujeros.

Contenido del artículo

Cómo cambia el día a día de administración

Pasar de tener sólo Zabbix a tener Zabbix + Wazuh no es sólo “otro panel más”. Cambian varias cosas en cómo piensas la administración de sistemas:

1. De mirar “si se ha caído” a mirar “por qué está así”

Antes:

  • Miraba gráficas, triggers, disponibilidad.
  • Si el servicio estaba arriba y los recursos no iban al 100%, asunto resuelto.

Ahora:

  • Sigo mirando eso, pero además tengo:

Ya no sólo pregunto “¿funciona?”, pregunto también “¿tiene sentido que esté así?”.

2. Del “yo creo que lo dejé bien” al “tengo una métrica”

Todos hemos dicho alguna vez:

“Este server está bastante seguro, lo monté yo y soy cuidadoso”.

El SOC te quita la subjetividad:

  • 37% de score en un CIS benchmark
  • 55% de checks fallados en otro
  • Lista de vulnerabilidades por CVE asociadas a tus paquetes reales

Ya no es opinión, son números. Y lo bueno es que puedes repetir el escaneo después de aplicar cambios y ver:

  • Cómo sube el % de cumplimiento.
  • Qué checks siguen fallando y por qué.

3. De acciones reactivas a un plan continuo de endurecimiento

Con sólo el NOC, la mayor parte del trabajo es reactivo:

  • Se cae algo → alerta de Zabbix → lo levantas.
  • Hay un pico de CPU → investigas.

Con el SOC, aparece una tarea de fondo permanente:

  • Revisar los findings del SCA.
  • Decidir qué endurecer primero (SSH, logs, permisos…).
  • Ir corrigiendo poco a poco.

No es apagar fuegos, es subir el listón de base.

Contenido del artículo

NOC + SOC: no es redundante, es complementario

Lo interesante es que no sustituyes nada:

  • Zabbix sigue siendo mi centro de:
  • Wazuh se ha convertido en:

En un entorno pequeño (un laboratorio, una pyme, incluso una infraestructura doméstica “seria”) la combinación de ambos te da algo que antes estaba sólo al alcance de entornos más grandes:

Visibilidad de operación + visibilidad de seguridad en el mismo juego.

Conclusión: no esperes a “ser grande” para pensar como un SOC

Lo que más me ha sorprendido de montar Wazuh junto a Zabbix no es la tecnología, es el cambio de mentalidad:

  • Pasas de asumir que “si todo está en verde, todo está bien”,
  • a aceptar que tenerlo funcionando no significa tenerlo bien configurado ni seguro.

Y también desmonta una idea peligrosa:

“Como esto es sólo un laboratorio / una red pequeña, no hace falta tanto”.

Precisamente en esos entornos es donde más se aprende de verdad, donde puedes permitirte romper cosas, aplicar benchmarks como CIS, y ver cómo mejora tu postura de seguridad con datos reales.

Si ya tienes un NOC montado con herramientas tipo Zabbix, añadir un SOC con algo como Wazuh es un ejercicio brutal para medir de verdad:

  • Cómo de seguros están tus servidores,
  • Qué configuraciones dabas por buenas,
  • Y cuántas de ellas realmente no pasarían un examen básico de seguridad.

A mí me ha dejado claro que el “todo OK” del NOC era sólo la mitad de la historia.

La otra mitad me la ha contado ese donut rojo y verde que ves cuando el SOC te dice: “has fallado más de lo que te crees… pero ahora sabes por dónde empezar a mejorar”.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *