Wazuh E-Mail-Benachrichtigungen richtig verstehen: Warum email alert level granulare Regeln übersteuert
Einleitung
Die E-Mail-Benachrichtigung in Wazuh wirkt auf den ersten Blick einfach: globale SMTP-Einstellungen definieren, Alert-Level festlegen und bei Bedarf mit <email_alerts> gezielt einzelne Regeln oder Gruppen auswählen. In der Praxis führt genau diese Kombination jedoch regelmäßig zu Missverständnissen. Besonders häufig ist die Annahme, dass ein <email_alerts>-Block mit einer bestimmten rule_id auch dann eine E-Mail auslösen kann, wenn die zugehörige Regel unterhalb des globalen <email_alert_level> liegt. Genau das ist standardmäßig nicht der Fall. Wazuh dokumentiert ausdrücklich, dass email_alert_level den minimalen Schweregrad für E-Mails festlegt und die granularen E-Mail-Optionen übersteuert. Nur die Regeloption alert_by_email kann diese Schwelle wiederum gezielt übergehen.
Ausgangslage / Problemstellung
In der betrachteten Konfiguration war die globale E-Mail-Funktion auf dem Wazuh-Manager bereits aktiviert. Im <alerts>-Block war email_alert_level gesetzt, zusätzlich wurde ein granularer <email_alerts>-Block ergänzt, um für eine bestimmte Regel-ID – hier 92653 – E-Mails zu versenden. Parallel entstand Unsicherheit durch eine Formulierung in der Wazuh-Dokumentation, wonach der level innerhalb von <email_alerts> „at or above the email_alert_level“ liegen müsse. Die praktische Frage dahinter ist entscheidend: Kann Wazuh überhaupt E-Mails für Regeln unterhalb des globalen E-Mail-Levels senden, wenn diese Regel explizit in <email_alerts> referenziert wird? Die aktuelle Wazuh-Dokumentation beantwortet das klar: nein, nicht allein über <email_alerts>.
Zusätzlich fiel eine Inkonsistenz zwischen offizieller Dokumentation und dem Wazuh-Puppet-Modul auf. Die Doku erlaubt mehrere <email_to>-Einträge innerhalb eines <email_alerts>-Blocks, während das angesprochene Puppet-Template dies offenbar nicht sauber abbildet. Die Wazuh-Dokumentation beschreibt mehrfach wiederholbare <email_to>-Elemente ausdrücklich als gültig; damit ist die Einschränkung eher als Modullimitierung als als Wazuh-Kernverhalten zu verstehen.
Technische Analyse
Wazuh trennt die E-Mail-Logik in drei Ebenen.
Die erste Ebene ist die globale Basiskonfiguration im <global>-Block. Hier werden SMTP-Server, Absender, Empfänger und weitere Mail-Parameter gesetzt. Ohne diese globale Mail-Konfiguration funktionieren granulare E-Mail-Regeln überhaupt nicht. Die Referenzseite zu <email_alerts> weist explizit darauf hin, dass die globale E-Mail-Konfiguration Voraussetzung für granulare Optionen ist.
Die zweite Ebene ist der <alerts>-Block. Dort definiert log_alert_level, ab welchem Level Alerts in alerts.log beziehungsweise alerts.json landen, und email_alert_level, ab welchem Level Wazuh überhaupt E-Mails erzeugt. Für die hier diskutierte Frage ist wichtig: email_alert_level ist kein bloßer Default-Wert, sondern eine harte globale Mindestschwelle. Wazuh formuliert das in der Referenz eindeutig: Setzt man den Wert etwa auf 10, werden E-Mails für Alerts unterhalb von 10 verhindert, auch wenn die granulare Mail-Konfiguration niedrigere Levels referenziert.
Die dritte Ebene ist <email_alerts>. Diese Sektion dient dazu, die globale E-Mail-Funktion gezielt einzuschränken oder auf bestimmte Regel-IDs, Gruppen oder Event-Locations einzugrenzen. Sie erweitert die E-Mail-Optionen, ersetzt aber nicht die globale Mindestschwelle. Deshalb ist der Hinweis in der Dokumentation logisch: Der level innerhalb von <email_alerts> muss auf oder über email_alert_level liegen, weil alles darunter ohnehin vom globalen Threshold blockiert wird.
Der einzig dokumentierte Mechanismus, der diese globale Mindestschwelle durchbrechen kann, ist alert_by_email direkt in einer Regeldefinition. Wazuh beschreibt das sowohl in der Alert-Management-Dokumentation als auch in der Referenz zu email_alert_level: Eine einzelne Regel kann mit alert_by_email E-Mail-Versand erzwingen, unabhängig von globalen oder granularen Alert-Level-Schwellen.
Lösung / Best Practices
Wer E-Mails für eine spezifische Regel erhalten möchte, obwohl deren Regel-Level unterhalb des globalen email_alert_level liegt, hat in der Praxis drei saubere Wege.
Der erste Weg ist, email_alert_level global abzusenken. Das ist technisch einfach, aber meist operativ ungeeignet, weil dadurch deutlich mehr E-Mails erzeugt werden. Gerade in produktiven Umgebungen führt das schnell zu Alert-Fatigue.
Der zweite Weg ist, die betroffene Regel lokal zu überschreiben und alert_by_email zu setzen. Das ist der präziseste Ansatz, wenn wirklich nur einzelne Regeln unabhängig vom globalen E-Mail-Level Nachrichten auslösen sollen. Wazuh dokumentiert ausdrücklich, dass alert_by_email globale und granulare E-Mail-Schwellen übersteuern kann.
Eine saubere lokale Regelanpassung kann beispielsweise so aussehen:
<group name="local,custom_email,">
<rule id="100926" level="7" overwrite="yes">
<if_sid>92653</if_sid>
<description>Spezifische Regel 92653 mit erzwungener E-Mail-Benachrichtigung</description>
<options>alert_by_email</options>
</rule>
</group>
Je nach vorhandener Regelstruktur ist auch eine direkte Regelkopie oder ein gezieltes Overwrite der Originalregel möglich. Entscheidend ist nicht die exakte XML-Variante, sondern dass alert_by_email in der final wirksamen Regel gesetzt ist.
Der dritte Weg ist die Nutzung von <email_alerts> nur im vorgesehenen Rahmen: also zur Eingrenzung bereits E-Mail-fähiger Alerts auf bestimmte Empfänger, Gruppen, Regel-IDs oder Standorte. Eine typische Konfiguration dafür wäre:
<alerts>
<log_alert_level>3</log_alert_level>
<email_alert_level>15</email_alert_level>
</alerts><email_alerts>
<email_to>myemail@mydomain.com</email_to>
<rule_id>92653</rule_id>
<level>15</level>
</email_alerts>
Diese Konfiguration funktioniert nur dann wie erwartet, wenn die Regel selbst mindestens Level 15 erreicht oder per alert_by_email explizit E-Mails erzwingt. Sonst greift die globale Schwelle und blockiert den Versand.
Für mehrere Empfänger innerhalb eines granularen Blocks erlaubt Wazuh laut aktueller Dokumentation mehrere separate <email_to>-Einträge:
<email_alerts>
<email_to>soc@mydomain.com</email_to>
<email_to>ir@mydomain.com</email_to>
<rule_id>92653</rule_id>
<level>15</level>
</email_alerts>
Wenn das Puppet-Modul diese Struktur nicht unterstützt, sollte dies als Abweichung des Automatisierungstemplates behandelt werden, nicht als Wazuh-Produktgrenze. In solchen Fällen ist entweder ein Template-Fix im Modul oder eine nachgelagerte Konfigurationsanpassung notwendig.
Lessons Learned / Best Practices
Die wichtigste Erkenntnis ist, dass <email_alerts> in Wazuh keine Priorisierung über der globalen E-Mail-Schwelle darstellt. Viele Administratoren lesen den Block intuitiv als Positivliste nach dem Motto „Wenn die Regel-ID hier steht, dann sende immer eine Mail“. Tatsächlich ist <email_alerts> aber nur eine granulare Filterebene unterhalb der globalen E-Mail-Policy.
Für den Betrieb bedeutet das: email_alert_level sollte als zentrale Rauschgrenze verstanden werden. Alles, was darunter dennoch per E-Mail verschickt werden soll, gehört bewusst und dokumentiert über alert_by_email in eine Regelanpassung. Das ist sauberer, nachvollziehbarer und update-sicherer als ein globales Absenken des Schwellenwertes.
Ebenso wichtig ist die Trennung zwischen Produktverhalten und Tooling-Verhalten. Wenn ein Puppet-Modul mehrere <email_to>-Elemente nicht korrekt modelliert, ist das kein Beleg gegen die Wazuh-Dokumentation, sondern ein Hinweis auf ein Template- oder Datenmodellproblem in der Automatisierungsschicht.
Fazit
Ja, die Interpretation ist korrekt: Mit der Standardlogik von Wazuh können Regeln unterhalb des global gesetzten <email_alert_level> nicht allein durch einen <email_alerts>-Eintrag E-Mails auslösen. Die globale Schwelle hat Vorrang vor der granularen Konfiguration. Wer gezielt niedrigere oder abweichende Regeln per Mail versenden will, sollte dafür alert_by_email in einer lokalen Regelanpassung einsetzen. Genau diese Kombination aus globaler Mindestschwelle, granularer Einschränkung und optionalem Regel-Override ist das saubere Wazuh-Modell für E-Mail-Alerting.
Quellenverweis
https://documentation.wazuh.com/current/user-manual/manager/alert-management.html
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/alerts.html
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/email-alerts.html
https://github.com/wazuh/wazuh-puppet
Mehr zu Wazuh … https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Mehr zum Wazuh Ambassador Program … https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
https://wazuh.slack.com/archives/C0A933R8E/p1771601980391029
Quelle
Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 24. Mai 2026).
Unterstützung von m.a.x. it
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
