Guilgo Blog

Si ya usas Wazuh en serio, sabes dónde duele.

Ruido en alertas. Upgrades frágiles. Un stack que funciona… hasta que escala.
Wazuh 5 será interesante solo si mejora eso. No por “features”, sino por operación.

Este post va de criterios: qué tendría que demostrar para merecer producción y cómo adoptarlo sin convertirlo en otra fuente de deuda.

Conecta con posts anteriores del blog (misma idea: señal útil, no teatro):

• SOC proactivo en un homelab (Wazuh, Kubernetes, Trivy, Telegram)
• Priorizar parches en WSUS con Wazuh (CVEs sin ruido)
• Detección de DNS tunneling con Wazuh Lite

Tesis: Wazuh 5 no arregla un mal diseño

Hay dos formas de “fracasar” con Wazuh:

• Montarlo sin decidir qué quieres detectar (y qué no), y terminar en fatiga de alertas.
• Ignorar que indexado + retención + consultas es un sistema, y pegarte con el rendimiento cuando crece.

Si hoy no tienes eso claro, cambiar de versión no te salva.

Criterios de producción (no wishlist)

1) Upgrades sin miedo (y sin compatibilidades traicioneras)

• Proceso repetible.
• Compatibilidad clara entre componentes.
• Rollback razonable.
• Sin “arreglos” manuales post-upgrade para volver a verde.

Y un clásico a vigilar: la pieza de UI (históricamente, la App/plug-in de Wazuh en el dashboard) ha sido un punto de fricción por incompatibilidades.
Si en Wazuh 5 eso queda mejor resuelto, es un win. Si no, entra directo en tu checklist de riesgo.

2) Rendimiento con margen (EPS, picos y latencia)

• Ingesta estable con picos reales.
• Latencia bajo control.
• Dashboards habituales sin degradar el sistema.

Insight de trinchera: el cuello de botella no suele ser el agente. Es el indexer cuando mezclas retención larga con consultas pesadas y dashboards que acaban siendo BI encubierto.

Si Wazuh 5 trae mejoras aquí (rotación/gestión de índices, estrategias tipo hot/warm, o simplemente defaults más sensatos), perfecto… pero yo lo daría por bueno solo cuando lo vea aguantar carga real.

3) Señal > ruido (detección operable)

• Reglas base útiles.
• Contexto accionable en alertas.
• Recortar ruido sin cargarte visibilidad.

El objetivo no es “más alertas”. Es alertas que te ahorren tiempo.

4) Vulnerabilidades con priorización real

• Inventario fiable (lo instalado de verdad).
• Enriquecimiento que ayude a decidir.
• Vistas pensadas para operar, no para “listar”.

Insight de trinchera: el problema no es el número de CVEs. Es que gran parte no aplica, otra no es prioritaria, y el resto compite con incidentes reales. Si no priorizas, lo ignoras.

5) Operación y seguridad del stack

• Healthchecks claros.
• Backups/restores probados.
• Sane defaults y límites razonables.
• RBAC y TLS consistentes.

Si no es operable, no es producción.

Lo que sí merece la pena si lo anterior se cumple

• Endpoints: auth, procesos, persistencias típicas, integridad.
• Fuentes críticas: firewall e IAM/auditoría cloud sin bricolaje constante.
• Multi-entorno: separación de datos y permisos sin lío (si aplica).
• Automatización mínima: ticket con evidencias, notificación útil, bloqueo/aislado cuando esté soportado.

Lo que NO haría (aunque suene tentador)

• No migraría big bang. Paralelo o nada.
• No activaría vulnerability detection sin un flujo de priorización definido: acabarás ignorándolo.
• No asumiría que las reglas por defecto valen para tu entorno: primero, verlas disparar y calibrar.
• No encendería todos los módulos el día 1: empezaría por lo que reduce MTTR o evita incidentes repetibles.
• No mediría éxito por volumen de alertas.

Cómo lo adoptaría (en serio)

Antes del piloto

• 10–15 detecciones “top” (las que te importan).
• Activos críticos y fuentes de logs clave.
• Baseline de EPS, retención y coste/recursos.
• 3–5 métricas de éxito.

Piloto pequeño (con ejemplos de reglas “top”)

• IT + 1 servidor crítico + 1 fuente (firewall o IAM).
• 10–20 reglas de alto valor, por ejemplo:
  • creación/alta de usuarios y cambios de grupos privilegiados (AD/LDAP)
  • uso de sudo en servidores críticos y comandos fuera de patrón
  • anomalías de autenticación (VPN/SSO): ráfagas de fallos, geografías raras, horarios imposibles
  • nuevos servicios/daemons en servidores (persistencia “clásica”)
  • cambios en ficheros sensibles (SSH, PAM, sudoers, tareas programadas)
  • ejecución de binarios desde rutas sospechosas (si tu telemetría lo permite)
• Tuning semanal con decisión explícita: qué se queda y qué se mata.
• Criterio de corte: si en 2–3 semanas no reduces ruido o no mejoras MTTR, el piloto falla.

Escalar por oleadas

• Por criticidad o unidad.
• Con rollback claro.
• Documentando “gotchas” antes de ampliar cobertura.

Checklist rápido

• Upgrades repetibles (incluida la UI/App).
• EPS con margen (picos incluidos).
• Retención viable sin matar rendimiento.
• Señal/ruido controlable.
• Backups + restore probados.
• RBAC/TLS y hardening coherentes.

Remate

Si hoy no sabes qué quieres detectar ni cómo medirlo, la versión da igual.

Producción no es instalar. Es operar sin que te coma.