Wazuh + GLPI: alertas por correo, tickets solos y cómo domar las falsas alarmas

En el trabajo (sector público) usamos Wazuh como SIEM y GLPI para los tickets y el inventario. La idea es sencilla: si Wazuh ve algo serio, que no se quede en un panel que nadie mira, sino que acabe en un ticket con alguien asignado.

El problema llega el primer día: Wazuh, recién instalado, avisa de todo. Si conectas eso tal cual a GLPI, en una semana tienes cientos de tickets y nadie les hace caso. Así que este artículo tiene dos partes: cómo conectarlos y, sobre todo, cómo quitar el ruido.

Todo lo que sale aquí es genérico: nada de nombres de servidores ni de la organización.

1. Que Wazuh mande correos

Wazuh manda correo desde el manager, en /var/ossec/etc/ossec.conf:

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@tu-dominio.es</email_from>
  <email_to>soporte@tu-dominio.es</email_to>
  <email_maxperhour>12</email_maxperhour>
</global>

<alerts>
  <log_alert_level>3</log_alert_level>
  <email_alert_level>12</email_alert_level>
</alerts>

• email_alert_level: solo se mandan por correo las alertas de este nivel o más. Empieza alto (10-12) y ya bajarás.
• email_maxperhour: un freno para que una tormenta de alertas no te inunde el buzón (el resto se agrupan).

Un detalle que despista: Wazuh no sabe autenticarse en el servidor SMTP. Si tu correo pide usuario y contraseña, pon un Postfix en el propio manager como relé (que escuche solo en local) y apunta smtp_server a localhost.

Si quieres más control, hay bloques <email_alerts> para mandar a otro destinatario según el grupo de la regla o el nivel:

<email_alerts>
  <email_to>sistemas@tu-dominio.es</email_to>
  <level>10</level>
  <group>authentication_failures,</group>
  <do_not_delay />
</email_alerts>

Reinicia para aplicar:

sudo systemctl restart wazuh-manager

2. Que GLPI convierta esos correos en tickets

La forma más fácil no necesita programar nada: el receptor de correo de GLPI.

1. Crea un buzón solo para esto (por ejemplo, alertas-glpi@...) y haz que Wazuh mande ahí (email_to).
2. En GLPI: Configuración → Receptores → Añadir, con los datos IMAP de ese buzón.
3. GLPI lee el buzón cada pocos minutos (es una acción automática) y cada correo pasa a ser un ticket.
4. Con Administración → Reglas → Reglas de negocio para tickets asignas categoría, grupo técnico y prioridad según el asunto. Por ejemplo, si el asunto contiene «Wazuh», va al grupo de sistemas.

Una decisión que hay que tomar: si Wazuh agrupa varias alertas en un correo, te llega un ticket con varias dentro. Con <do_not_group /> en un bloque <email_alerts> cada alerta va en su propio correo y, por tanto, en su propio ticket. Yo prefiero un ticket por alerta solo para los niveles altos. Si no, vuelves a la avalancha.

¿Algo más fino? Wazuh permite integraciones propias (un script en /var/ossec/integrations/ llamado custom-algo) que pueden crear el ticket directamente por la API REST de GLPI. Funciona muy bien, pero el correo es más fácil de montar y de arreglar cuando falla.

3. El ruido: cómo limpiar la avalancha de falsos positivos

Aquí está el trabajo de verdad. Mi método, por orden:

Paso 1: mide qué reglas hacen más ruido

Casi siempre unas pocas reglas generan la mayoría de las alertas. En el manager puedes sacar el ranking directamente del fichero de alertas:

sudo jq -r '"\(.rule.id)  nivel \(.rule.level)  \(.rule.description)"' \
  /var/ossec/logs/alerts/alerts.json | sort | uniq -c | sort -rn | head -20

(En el panel web se hace lo mismo con una visualización agrupada por rule.id.)

Apunta esas 20. Esa es tu lista de trabajo.

Paso 2: para cada una, decide qué es

Con cada regla del ranking, abre varias alertas y pregúntate:

• ¿Es algo real que no me importa? Por ejemplo, una carpeta temporal que una aplicación reescribe cada noche y que salta en el control de integridad. → Se puede silenciar.
• ¿Es real y sí me importa, pero no tanto? → Bájale el nivel para que siga guardándose pero no mande correo.
• ¿Es un aviso de que algo está mal configurado? → No lo silencies: arréglalo. Muchas «falsas alarmas» son, en realidad, problemas de verdad pequeños.

Paso 3: si se puede, quítalo en el origen

Lo más limpio es que el agente ni lo mire. Por ejemplo, para el control de integridad (FIM), en la configuración del agente:

<syscheck>
  <ignore type="sregex">\\AppData\\Local\\Temp\\</ignore>
</syscheck>

Si gestionas los agentes por grupos, esto va en el agent.conf del grupo y se reparte solo.

Paso 4: si no, una regla propia

Las reglas propias van en /var/ossec/etc/rules/local_rules.xml y usan IDs del 100000 al 120000 para no chocar con las oficiales. Una regla «hija» que cuelga de la original y la deja a nivel 0 (no genera alerta):

<group name="local,syscheck,">
  <!-- 2026-09: la app X reescribe esta carpeta cada noche. Revisado: inofensivo. -->
  <rule id="100200" level="0">
    <if_sid>550</if_sid>
    <field name="file" type="pcre2">(?i)\\temp\\app-x\\</field>
    <description>Cambios esperados en la carpeta temporal de la app X</description>
  </rule>
</group>

• if_sid → solo actúa cuando ya ha saltado la regla original (la 550 es «cambió el checksum de un fichero»).
• field → y además, solo si el fichero está en esa ruta.
• El comentario con fecha y motivo es obligatorio para mí. Dentro de un año nadie recordará por qué se silenció.

Para las alertas que vienen de logs (no del control de integridad), prueba la regla antes de reiniciar con:

sudo /var/ossec/bin/wazuh-logtest

Pegas una línea de log real y te dice qué regla salta y con qué nivel.

Paso 5: repite cada semana

Vuelve a sacar el ranking del paso 1. La lista cambia: al quitar lo más ruidoso aparece lo siguiente. En unas pocas vueltas pasas de un buzón que nadie lee a uno donde cada correo significa algo.

Lo que no hay que hacer

• Silenciar por nivel a lo bruto (subir email_alert_level a 15 y listo). No te llega nada, pero tampoco lo importante.
• Poner nivel 0 a una regla entera sin condiciones. Mejor siempre una regla hija con if_sid y un filtro concreto.
• Silenciar intentos de inicio de sesión fallidos porque «son muchos». Si son muchos, averigua de dónde vienen: suele ser una contraseña antigua guardada en algún sitio… o algo peor.

Resumen

1. Wazuh manda correo solo de lo grave (email_alert_level alto).
2. GLPI lee ese buzón y crea tickets con sus reglas de negocio.
3. Mides qué reglas hacen ruido, arreglas en el origen lo que puedas y silencias con reglas hijas documentadas el resto.

Un SIEM que avisa de todo es igual de inútil que uno que no avisa de nada. Hay que ajustarlo, y eso no se hace una vez y ya: es un trabajo de mantenimiento, como las copias.