Wazuh E-Mail-Flut stoppen, ohne Detection zu verlieren: noalert vs. no_email_alert und saubere Rule-Änderungen für Frequency/Timeframe-Korrelation

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

E-Mail-Benachrichtigungen sind in Wazuh ein bewährtes Mittel, um kritische Ereignisse schnell sichtbar zu machen. In der Praxis kippt dieses Signal aber schnell in Lärm – insbesondere bei Korrelationsregeln mit frequency/timeframe, die bei Scan- oder Recon-Mustern viele Alerts erzeugen. Der typische Wunsch aus dem Betrieb lautet dann: „Regel soll weiter funktionieren, aber keine E-Mails mehr schicken.“

Genau hier passieren häufig Fehlgriffe: Wer reflexartig noalert setzt, schaltet nicht nur E-Mails ab, sondern die Regel komplett – inklusive Alert-Erzeugung, Indexing und Downstream-Korrelation.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Es existiert eine Korrelationsregel, die Webserver-400er als Scan-Indikator aggregiert:

<rule id="100213" level="12" frequency="50" timeframe="60">
  <if_matched_sid>31101</if_matched_sid>
  <same_source_ip />
  <description>Multiple web server 400 error codes fired more than 50 times in 60 seconds from the same source IP.</description>
  <mitre>
    <id>T1595.002</id>
  </mitre>
  <group>web_scan,recon,pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4</group>
</rule>

Der Kunde erhält bei Treffer zu viele E-Mails und möchte die Mailbenachrichtigung unterbinden – die Regel selbst soll aber weiterhin Alerts erzeugen und im Dashboard sichtbar bleiben.

Die zentrale Frage: Geht das mit <noalert />?

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) noalert ist ein Regel-Attribut – und bedeutet „keine Alerts“, nicht „keine E-Mails“

In der Wazuh-Regelsyntax ist noalert als Regel-Attribut beschrieben. Das ist wichtig, weil es die Semantik klar macht: noalert unterdrückt die Alert-Erzeugung dieser Regel „in jeder Bedeutung“ – also nicht nur E-Mail, sondern das gesamte Alerting (inkl. Persistenz/Indexing, Sichtbarkeit im Dashboard und nachgelagerter Verarbeitung).

Wenn der Kunde weiterhin Dashboard-Visibility und SIEM-Auswertung will, ist noalert in der Regel die falsche Wahl.

2) E-Mail-Steuerung passiert über <options> und globale Schwellenwerte

Wazuh trennt zwischen:

  • Alert-Erzeugung (im Manager, Speicherung z. B. in alerts.json)
  • E-Mail-Benachrichtigung (gesteuert über Manager-Alert/Email-Schwellen und Rule-Optionen)

Global steuern u. a. diese Werte die Schwellen:

  • <log_alert_level> (ab welchem Level Alerts geloggt/gespeichert werden)
  • <email_alert_level> (ab welchem Level E-Mails verschickt werden)

Die Default-Konfiguration zeigt: log_alert_level ist 3 und email_alert_level ist 12.

Das passt exakt zum Beispiel: Die Regel hat level="12" und liegt damit per Default genau auf der E-Mail-Schwelle.

3) Die richtige Lösung heißt no_email_alert – als Rule-Option

Wazuh bietet für genau diesen Fall eine Rule-Option, die E-Mail unterdrückt, ohne die Regel auszuschalten: no_email_alert innerhalb von <options>. Das ist in der Rules-Syntax als „rules options“ dokumentiert.

Typischer Stolperstein: Es gibt kein <no_email_alert /> Tag als Standalone-Element – es muss als <options>no_email_alert</options> gesetzt werden.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Variante A: Regel weiter alerten, aber niemals E-Mails dafür senden

So sieht die korrekte Anpassung aus:

<rule id="100213" level="12" frequency="50" timeframe="60">
  <if_matched_sid>31101</if_matched_sid>
  <same_source_ip />
  <description>
    Multiple web server 400 error codes fired more than 50 times in 60 seconds from the same source IP.
  </description>
  <mitre>
    <id>T1595.002</id>
  </mitre>
  <group>web_scan,recon,pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4</group>

  <!-- Suppress email notifications, keep alert generation -->
  <options>no_email_alert</options>
</rule>

Warum das die Betriebssicht erfüllt:

  • Alert wird weiterhin erzeugt, geloggt und indexiert (Dashboard/Reports/Korrelation bleibt erhalten).
  • E-Mail wird für genau diese Regel unterdrückt (selektiv statt global).

Variante B: Mailmenge senken, ohne E-Mail komplett abzuschalten

Wenn der Kunde nicht „keine E-Mails“, sondern „weniger E-Mails“ meint, sind oft diese Ansätze sinnvoller:

  1. Rule-Level nicht bei 12 belassen, sondern z. B. 10 oder 11 setzen (unterhalb der Default-Mail-Schwelle 12).
    Das nutzt die globale <email_alert_level>-Logik.
  2. Globales E-Mail-Threshold anheben (nur wenn das organisatorisch passt).
    Ebenfalls über <email_alert_level>.
  3. Zusätzliche Bedingungen (z. B. nur externe Netze, nur bestimmte vHosts/Paths), um False Positives zu reduzieren.

Wo wird die Regel gepflegt: Dashboard oder Server-Datei?

Für Custom Rules empfiehlt Wazuh, Änderungen in /var/ossec/etc/rules/ zu verwalten, bei kleineren Anpassungen typischerweise in local_rules.xml, bei größerem Umfang in eigenen Dateien in diesem Verzeichnis.

In der Praxis kannst du Custom Rules:

  • entweder per CLI/SSH im Wazuh-Server unter /var/ossec/etc/rules/ pflegen,
  • oder über die Wazuh Dashboard-Funktionen für Rule-Management (wenn in deiner Umgebung aktiviert/organisatorisch erlaubt).

Wichtig ist das Betriebsprinzip: Custom Rules gehören in den /var/ossec/etc/rules/-Pfad, damit Updates der Standardrules sie nicht überschreiben.

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • noalert ist ein „Kill Switch“ für Alerting – nicht ein E-Mail-Toggle. Wenn du es setzt, verlierst du Sichtbarkeit und oft auch Downstream-Korrelation.
  • Für „Rule soll weiter arbeiten, aber keine E-Mail“ ist <options>no_email_alert</options> die richtige Lösung.
  • Behalte die globalen Schwellen im Blick: Default email_alert_level=12 erklärt viele „Warum mailt das so viel?“-Situationen.
  • Pflege Custom Rules updatesicher in /var/ossec/etc/rules/ (z. B. local_rules.xml oder eigene Rule-Datei).
  • Bei Scan-Detections ist nicht nur „Mail an/aus“ wichtig: Oft lohnt es sich, Noise über zusätzliche Bedingungen und sauber kalibrierte Thresholds zu reduzieren.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn eine Wazuh-Regel weiterhin Alerts erzeugen soll, aber keine E-Mails mehr senden darf, ist noalert der falsche Hebel: Es unterdrückt die Regel vollständig. Die saubere, selektive Lösung ist <options>no_email_alert</options> innerhalb der Regel. Ergänzend hilft das Verständnis der Default-Schwellen (email_alert_level=12), um E-Mail-Verhalten planbar zu machen und Scan/Recon-Korrelationen betrieblich erträglich zu halten.

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/p1769003916092259