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