Wazuh + GLPI: email alerts, automatic tickets and taming false alarms

At work (public sector) we use Wazuh as our SIEM and GLPI for tickets and inventory. The idea is simple: if Wazuh sees something serious, it shouldn’t sit on a dashboard nobody checks. It should end up as a ticket with someone assigned to it.

The problem shows up on day one: a fresh Wazuh install alerts on everything. Wire that straight into GLPI and within a week you have hundreds of tickets that nobody reads. So this article has two parts: how to connect them and, above all, how to get rid of the noise.

Everything here is generic: no server or organisation names.

1. Make Wazuh send emails

Wazuh sends mail from the manager, in /var/ossec/etc/ossec.conf:

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@your-domain.com</email_from>
  <email_to>support@your-domain.com</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: only alerts at this level or higher get emailed. Start high (10-12) and lower it later.
• email_maxperhour: a brake so an alert storm doesn’t flood your inbox (the rest get grouped).

One detail that catches people out: Wazuh can’t authenticate against the SMTP server. If your mail server needs a username and password, run Postfix on the manager as a relay (listening on localhost only) and point smtp_server at localhost.

For more control there are <email_alerts> blocks to send to a different recipient by rule group or level:

<email_alerts>
  <email_to>sysadmins@your-domain.com</email_to>
  <level>10</level>
  <group>authentication_failures,</group>
  <do_not_delay />
</email_alerts>

Restart to apply:

sudo systemctl restart wazuh-manager

2. Make GLPI turn those emails into tickets

The easiest way needs no code at all: GLPI’s mail receiver.

1. Create a mailbox just for this (for example glpi-alerts@...) and have Wazuh send there (email_to).
2. In GLPI: Setup → Receivers → Add, with that mailbox’s IMAP details.
3. GLPI reads the mailbox every few minutes (it’s an automatic action) and each email becomes a ticket.
4. With Administration → Rules → Business rules for tickets you set category, technician group and priority based on the subject. For example, if the subject contains “Wazuh”, it goes to the sysadmin group.

One decision to make: if Wazuh groups several alerts into one email, you get one ticket with several alerts inside. With <do_not_group /> in an <email_alerts> block each alert goes in its own email, so its own ticket. I prefer one ticket per alert only for high levels. Otherwise you’re back to the flood.

Want something finer? Wazuh supports custom integrations (a script in /var/ossec/integrations/ named custom-something) that can create the ticket directly through GLPI’s REST API. It works very well, but email is easier to set up and to fix when it breaks.

3. The noise: cleaning up the flood of false positives

This is where the real work is. My method, in order:

Step 1: measure which rules are noisiest

Almost always a few rules generate most of the alerts. On the manager you can get the ranking straight from the alerts file:

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

(In the web dashboard you do the same with a visualisation aggregated by rule.id.)

Write those 20 down. That’s your work list.

Step 2: for each one, decide what it is

For each rule in the ranking, open several alerts and ask yourself:

• Is it real but something I don’t care about? For example, a temp folder an application rewrites every night that trips the integrity monitor. → It can be silenced.
• Is it real and I do care, just not that much? → Lower its level so it’s still stored but doesn’t send email.
• Is it telling me something is misconfigured? → Don’t silence it: fix it. Many “false alarms” are actually small real problems.

Step 3: if you can, remove it at the source

The cleanest option is for the agent not to look at it at all. For file integrity monitoring (FIM), in the agent configuration:

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

If you manage agents by groups, this goes in the group’s agent.conf and gets distributed automatically.

Step 4: if not, a custom rule

Custom rules go in /var/ossec/etc/rules/local_rules.xml and use IDs 100000 to 120000 so they don’t clash with the official ones. A “child” rule that hangs off the original and sets it to level 0 (no alert):

<group name="local,syscheck,">
  <!-- 2026-09: app X rewrites this folder every night. Checked: harmless. -->
  <rule id="100200" level="0">
    <if_sid>550</if_sid>
    <field name="file" type="pcre2">(?i)\\temp\\app-x\\</field>
    <description>Expected changes in app X temp folder</description>
  </rule>
</group>

• if_sid → only acts once the original rule has fired (550 is “file checksum changed”).
• field → and only if the file is under that path.
• The comment with date and reason is mandatory for me. A year from now nobody will remember why it was silenced.

For alerts that come from logs (not from integrity monitoring), test the rule before restarting with:

sudo /var/ossec/bin/wazuh-logtest

Paste a real log line and it tells you which rule fires and at what level.

Step 5: repeat every week

Run the ranking from step 1 again. The list changes: once you remove the noisiest thing, the next one shows up. After a few rounds you go from an inbox nobody reads to one where every email means something.

What not to do

• Silence by level with a sledgehammer (raise email_alert_level to 15 and call it done). You get nothing, including the important stuff.
• Set a whole rule to level 0 with no conditions. Always prefer a child rule with if_sid and a specific filter.
• Silence failed logins because “there are too many”. If there are too many, find out where they come from: it’s usually an old password saved somewhere… or something worse.

Summary

1. Wazuh emails only the serious stuff (high email_alert_level).
2. GLPI reads that mailbox and creates tickets with its business rules.
3. You measure which rules are noisy, fix at the source what you can, and silence the rest with documented child rules.

A SIEM that alerts on everything is as useless as one that alerts on nothing. You have to tune it, and that isn’t a one-off job: it’s maintenance, like backups.