Wazuh Regeln überschreiben: Unterschied zwischen den Versionen

Aus maxTechCorner
← Zum vorherigen Versionsunterschied
Deko (Diskussion | Beiträge)
877 Bearbeitungen
Wamu (Diskussion | Beiträge)
30 Bearbeitungen
Keine Bearbeitungszusammenfassung
 
(4 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Wazuh''' ist eine freie SIEM-Lösung, die es erlaubt Logs zentral zu sichern, auszuwerten und selbstständig Aktionen auszuführen<br />
{{Steckbrief
oder den Administrator zu alarmieren.<br />
| gilt_fuer  = Wazuh (Regel-Engine, OSSEC-basiert)
| bereich    = IT-Security
| dauer      = ca. 10 Minuten
| rechte      = Administrator (Wazuh-Manager)
| stand      = September 2026
}}
'''Wazuh''' ist eine freie SIEM-Lösung, die Logs zentral sichert, auswertet und bei Bedarf eigenständig Aktionen ausführt oder Administratoren alarmiert. Gelegentlich schlägt eine Regel an, obwohl kein echtes Problem vorliegt – ein '''False Positive'''. Dieser Artikel zeigt, wie sich eine Regel gezielt anpassen (überschreiben) lässt, ohne sie ganz zu deaktivieren.


Hin und wieder kommt es vor, dass Regeln zuschlagen, obwohl kein wirkliches Problem besteht, ein sogenannter false-positive. <br />
== Beispiel: False Positive durch logrotate ==
Ein klassisches Beispiel sind <code>su</code>-Meldungen von logrotate unter Debian. Wazuh würde hier sofort Alarm schlagen:
<syntaxhighlight lang="text">
Received From: (host62) any->/var/log/auth.log
Rule: 40101 fired (level 12) -> "System user successfully logged to the system."
User: nobody
Portion of the log(s):
Apr 30 06:25:01 host62 su[29446]: + ??? root:nobody
</syntaxhighlight>


Ein klassisches Beispiel sind SU Meldungen von Logrotate in Debian. Ein SIEM würde hier sofort Alarm schlagen:<br />
== Lösung: Regel überschreiben mit Zeitfenster ==
    Received From: (host62) any->/var/log/auth.log<br />
Ein Alarm dieser Art ist grundsätzlich erwünscht – nur nicht für den logrotate-Lauf. Dazu kopiert man die betroffene Regel in die '''local rules''' (<code>local_rules.xml</code>), setzt <code>overwrite="yes"</code> und grenzt sie über eine <code>&lt;time&gt;</code>-Angabe zeitlich aus:
    Rule: 40101 fired (level 12) -> "System user successfully logged to the sys-tem."<br />
<syntaxhighlight lang="xml">
    User: nobody<br />
<group name="syslog,attacks,">
    Portion of the log(s):<br />
  <rule id="40101" level="9" overwrite="yes">
    Apr 30 06:25:01 host62 su[29446]: + ??? root:nobody
    <if_group>authentication_success</if_group>
Da ein Alarm dieser Art erwünscht ist, allerdings nicht von logrotate, können wir die Zeiten für diese Job einfach ausklammern.<br />
    <user>$SYS_USERS</user>
Dazu kopieren wir die betroffene Regel in die local rules, setzen „overwrite=yes“ und geben eine timerange an:<br />
    <time>6:30 am - 6:20 am</time>
    <group name="syslog,attacks,"><br />
    <description>System user successfully logged to the system.</description>
      <rule id="40101" level="9" overwrite="yes"><br />
    <group>invalid_login,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,</group>
        <if_group>authentication_success</if_group><br />
  </rule>
        <user>$SYS_USERS</user><br />
</group>
        <time>6:30 am - 6:20 am</time><br />
</syntaxhighlight>
        <description>System user successfully logged to the system.</description<br />
Anschließend Wazuh '''neu laden''' – die Regel wird weiterhin geprüft, der Fehlalarm im ausgeklammerten Zeitfenster (hier rund um den logrotate-Lauf) aber vermieden.
      <group>invalid_login,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,<br />
    hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,</group><br />
      </rule><br />
    </group>
Jetzt noch Wazuh '''neu laden''' und die Regel wird weiter geprüft, ein Fehlalarm aber vermieden.<br /><br />


==='''Tags'''===
{{Hinweis|Die <code>&lt;time&gt;</code>-Angabe definiert das Zeitfenster, in dem die Regel greift. Passen Sie Regel-ID, Level und Zeitfenster an den konkreten False Positive an.}}
SIEM Wazuh OSSEC <br /><br />


==='''Weiterführende Informationen'''===  
== Unterstützung von m.a.x. it ==
Mehr Informationen finden Sie unter [https://www.max-it.de/ www.max-it.de].<br /><br />
Beim Feintuning von Regeln, dem Betrieb und der Beratung rund um Wazuh unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].


=== '''Kontakt''' ===
== Siehe auch ==
Wenn Sie Fragen oder Anmerkungen zu diesem Artikel haben,<br />
* [[NIS2 und Wazuh]]
melden Sie sich bitte bei uns unter [http://mailto:vertrieb@max-it.de vertrieb@max-it.de].<br /><br />
* [[Wazuh-O365]]


== Links und Quellen ==
* [https://wazuh.com/ Wazuh – offizielle Projektseite]
* [https://www.max-it.de/it-services/siem-open-source/ m.a.x. it – SIEM mit Open Source]


 
{{Uebermax}}
[[Kategorie: IT-Security]]
[[Kategorie:IT-Security]]

Aktuelle Version vom 15. September 2026, 12:19 Uhr

Auf einen Blick

Gilt fürWazuh (Regel-Engine, OSSEC-basiert)
BereichIT-Security
Dauerca. 10 Minuten
RechteAdministrator (Wazuh-Manager)
StandSeptember 2026

Wazuh ist eine freie SIEM-Lösung, die Logs zentral sichert, auswertet und bei Bedarf eigenständig Aktionen ausführt oder Administratoren alarmiert. Gelegentlich schlägt eine Regel an, obwohl kein echtes Problem vorliegt – ein False Positive. Dieser Artikel zeigt, wie sich eine Regel gezielt anpassen (überschreiben) lässt, ohne sie ganz zu deaktivieren.

Beispiel: False Positive durch logrotate

Ein klassisches Beispiel sind su-Meldungen von logrotate unter Debian. Wazuh würde hier sofort Alarm schlagen: 

Received From: (host62) any->/var/log/auth.log
Rule: 40101 fired (level 12) -> "System user successfully logged to the system."
User: nobody
Portion of the log(s):
Apr 30 06:25:01 host62 su[29446]: + ??? root:nobody

Lösung: Regel überschreiben mit Zeitfenster

Ein Alarm dieser Art ist grundsätzlich erwünscht – nur nicht für den logrotate-Lauf. Dazu kopiert man die betroffene Regel in die local rules (local_rules.xml), setzt overwrite="yes" und grenzt sie über eine <time>-Angabe zeitlich aus: 

<group name="syslog,attacks,">
  <rule id="40101" level="9" overwrite="yes">
    <if_group>authentication_success</if_group>
    <user>$SYS_USERS</user>
    <time>6:30 am - 6:20 am</time>
    <description>System user successfully logged to the system.</description>
    <group>invalid_login,pci_dss_10.2.4,pci_dss_10.2.5,gpg13_7.8,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,</group>
  </rule>
</group>

Anschließend Wazuh neu laden – die Regel wird weiterhin geprüft, der Fehlalarm im ausgeklammerten Zeitfenster (hier rund um den logrotate-Lauf) aber vermieden.


HinweisDie <time>-Angabe definiert das Zeitfenster, in dem die Regel greift. Passen Sie Regel-ID, Level und Zeitfenster an den konkreten False Positive an.

Unterstützung von m.a.x. it

Beim Feintuning von Regeln, dem Betrieb und der Beratung rund um Wazuh unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.

Siehe auch

Links und Quellen


Ü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? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Wazuh_Regeln_überschreiben&oldid=2271“