Quelltext der Seite Cisco-IOS-Syslog mit Millisekunden in Wazuh korrekt dekodieren

== Einleitung ==

Cisco-IOS-Geräte können Syslog-Zeitstempel in unterschiedlichen Varianten ausgeben: mit oder ohne Jahr, Zeitzone und Millisekunden. Für Wazuh ist diese Formatvielfalt relevant, weil bereits eine kleine Abweichung im Zeitstempel dazu führen kann, dass der übergeordnete Cisco-IOS-Decoder nicht greift.

Das Ereignis wird in diesem Fall zwar vom Wazuh Manager empfangen, aber nicht als Cisco-IOS-Meldung strukturiert. Felder wie Facility, Severity und Mnemonic fehlen anschließend für Regeln, Korrelationen und Dashboards. Dadurch entsteht ein potenzieller Monitoring-Blindspot, obwohl das Rohereignis technisch im System angekommen ist.

== Ausgangslage / Problemstellung ==

Betroffen war ein Cisco-IOS-Syslog im folgenden Format:

<syntaxhighlight lang="text">
host.domain.com : Jul 21 2026 15:09:33.812 CEST: %SYS-SW1-5-CONFIG_I: Configured from console by username on vty0 (10.10.10.1)
</syntaxhighlight>

Der Wazuh-Regeltest zeigte für dieses Ereignis:

<syntaxhighlight lang="text">
**Phase 1: Completed pre-decoding.
    full event: 'host.domain.com : Jul 21 2026 15:09:33.812 CEST: %SYS-SW1-5-CONFIG_I: Configured from console by username on vty0 (10.10.10.1)'

**Phase 2: Completed decoding.
    No decoder matched.
</syntaxhighlight>

Wurden ausschließlich die Millisekunden entfernt, funktionierte die Dekodierung:

<syntaxhighlight lang="text">
host.domain.com : Jul 21 2026 15:09:33 CEST: %SYS-SW1-5-CONFIG_I: Configured from console by username on vty0 (10.10.10.1)
</syntaxhighlight>

Das Ergebnis enthielt anschließend die erwarteten Cisco-Felder:

<syntaxhighlight lang="text">
name: 'cisco-ios'
cisco.facility: 'SYS-SW1'
cisco.mnemonic: 'CONFIG_I'
cisco.severity: '5'
</syntaxhighlight>

Die eigentliche Cisco-Meldung war somit gültig. Ausschlaggebend war die Kombination aus:

* zweistelligem Kalendertag,
* vierstelligem Jahr,
* Millisekunden,
* Zeitzone.

== Technische Analyse ==

Wazuh verarbeitet eingehende Logs in mehreren Stufen. Zunächst versucht das Pre-Decoding, typische Syslog-Bestandteile wie Zeitstempel, Hostname und Programmname zu erkennen. Danach wählen die Decoder anhand von <code>program_name</code>, <code>prematch</code> und regulären Ausdrücken einen passenden Decoder aus. Erst anschließend werden die dekodierten Felder gegen Regeln geprüft.

Beim betroffenen Ereignis erkannte das Pre-Decoding wegen des vorangestellten Formats <code>host.domain.com :</code> keinen klassischen Syslog-Header. Der relevante Cisco-IOS-Parent-Decoder musste deshalb innerhalb des vollständigen Ereignisses nach dem Cisco-Zeitstempel und dem anschließenden Prozentzeichen suchen.

Die untersuchte Version von <code>0065-cisco-ios_decoders.xml</code> enthält dafür mehrere <code>prematch</code>-Alternativen. Sie berücksichtigen unter anderem Cisco-Zeitstempel mit Jahr, Zeitzone und Millisekunden. Die Datei dokumentiert ausdrücklich, dass diese Bestandteile abhängig von der Gerätekonfiguration optional vorkommen können.

Für die Kombination aus Jahr, Millisekunden und Zeitzone war folgende Abschlussalternative vorhanden:

<syntaxhighlight lang="text">
<prematch>\w+\s+\d\p*\s\d+\s\d+:\d+:\d+.\d+\s+\w+:\s+%</prematch>
</syntaxhighlight>

Das Problem liegt im Abschnitt für den Kalendertag:

<syntaxhighlight lang="text">
\d\p*
</syntaxhighlight>

In Wazuhs OSRegex steht <code>\d</code> für genau eine Ziffer. <code>\p*</code> akzeptiert danach beliebig viele Satz- und Sonderzeichen, aber keine weitere Ziffer. Ein einstelliger Tag wie <code>Jul 9</code> kann deshalb passen, während ein zweistelliger Tag wie <code>Jul 21</code> an der zweiten Ziffer scheitert.

Ohne Millisekunden wird eine andere, korrekt definierte Alternative verwendet. Deshalb funktioniert das ansonsten identische Ereignis sofort, sobald <code>.812</code> entfernt wird.

Ein weiterer wichtiger Punkt ist die Verarbeitung mehrfacher <code>prematch</code>-Elemente: Wazuh behandelt sie nicht als vollständig voneinander unabhängige XML-Bedingungen, sondern verkettet ihre Inhalte zu einem gemeinsamen Ausdruck. Die vorhandenen Alternativen enden daher bis auf die letzte Zeile mit <code>|</code>. Wird eine zusätzliche Zeile an der falschen Position eingefügt, kann ein ungültiger oder nicht mehr erreichbarer Gesamtausdruck entstehen.

Auch die Punktsyntax ist bei OSRegex ungewöhnlich. Ein nicht maskierter Punkt steht dort für einen literalen Punkt. <code>\.</code> bedeutet dagegen „beliebiges Zeichen“. Der Ausdruck zwischen Sekunden und Millisekunden muss deshalb in diesem Decoder tatsächlich als <code>.\d+</code> geschrieben werden und darf nicht unreflektiert nach PCRE-Konvention in <code>\.\d+</code> geändert werden.

== Lösung / Best Practices ==

Die mit Wazuh ausgelieferte Datei unter <code>/var/ossec/ruleset/decoders/</code> sollte nicht direkt verändert werden. Änderungen in diesem Verzeichnis können bei einem Upgrade überschrieben werden. Der von Wazuh dokumentierte Weg besteht darin, die vollständige Decoder-Datei nach <code>/var/ossec/etc/decoders/</code> zu kopieren und anschließend die Originaldatei über <code>decoder_exclude</code> auszuschließen.

=== 1. Konfiguration sichern ===

<syntaxhighlight lang="text">
sudo cp -a /var/ossec/etc/ossec.conf \
  /var/ossec/etc/ossec.conf.bak.$(date +%F-%H%M%S)
</syntaxhighlight>

=== 2. Cisco-IOS-Decoder in das benutzerdefinierte Verzeichnis kopieren ===

<syntaxhighlight lang="text">
sudo cp /var/ossec/ruleset/decoders/0065-cisco-ios_decoders.xml \
  /var/ossec/etc/decoders/custom-cisco-ios_decoders.xml
</syntaxhighlight>

Anschließend werden Eigentümer und Berechtigungen gesetzt:

<syntaxhighlight lang="text">
sudo chown wazuh:wazuh \
  /var/ossec/etc/decoders/custom-cisco-ios_decoders.xml

sudo chmod 660 \
  /var/ossec/etc/decoders/custom-cisco-ios_decoders.xml
</syntaxhighlight>

Die vollständige Datei muss kopiert werden, weil sie neben dem Parent-Decoder auch die zugehörigen Cisco-IOS-Child-Decoder enthält. Würde ausschließlich ein neuer Parent mit demselben Namen angelegt, könnten Decoder-Reihenfolge, Mehrfachdefinitionen und die vorhandenen Child-Decoder zu unerwartetem Verhalten führen.

=== 3. Fehlerhafte <code>prematch</code>-Alternative korrigieren ===

Die benutzerdefinierte Datei wird mit einem Editor geöffnet:

<syntaxhighlight lang="text">
sudoedit /var/ossec/etc/decoders/custom-cisco-ios_decoders.xml
</syntaxhighlight>

Innerhalb des <code>cisco-ios</code>-Blocks für Datums- und Zeitformate wird die fehlerhafte Abschlussalternative gesucht:

<syntaxhighlight lang="text">
<prematch>\w+\s+\d\p*\s\d+\s\d+:\d+:\d+.\d+\s+\w+:\s+%</prematch>
</syntaxhighlight>

Sie wird durch folgende Variante ersetzt:

<syntaxhighlight lang="text">
<prematch>\p*\w+\s+\d+\s+\d+\s+\d+:\d+:\d+.\d+\s+\w+:\s+%</prematch>
</syntaxhighlight>

Der Ausdruck verarbeitet nun beispielsweise:

<syntaxhighlight lang="text">
Jul 21 2026 15:09:33.812 CEST: %
</syntaxhighlight>

Die Bestandteile sind:

<syntaxhighlight lang="text">
\p*       optionale Cisco-Zeitmarkierung wie * oder .
\w+       Monat
\s+       Leerzeichen
\d+       ein- oder zweistelliger Kalendertag
\s+
\d+       Jahr
\s+
\d+:\d+:\d+
.         literaler Punkt in OSRegex
\d+       Millisekunden
\s+
\w+       Zeitzone
:\s+%     Übergang zur Cisco-Meldungskennung
</syntaxhighlight>

Das Ersetzen der bisherigen Abschlussalternative ist sicherer, als eine weitere <code>prematch</code>-Zeile unkontrolliert am Ende einzufügen. Bei einer zusätzlichen Alternative müsste sichergestellt werden, dass zwischen ihr und der vorherigen Alternative ein <code>|</code> vorhanden ist.

Nicht empfehlenswert wäre eine Änderung auf:

<syntaxhighlight lang="text">
\d+\.\d+
</syntaxhighlight>

Bei Wazuh OSRegex würde <code>\.</code> nicht ausschließlich den Punkt zwischen Sekunden und Millisekunden abbilden, sondern ein beliebiges Zeichen akzeptieren.

=== 4. Originaldecoder in <code>ossec.conf</code> ausschließen ===

In der bestehenden Datei <code>/var/ossec/etc/ossec.conf</code> wird der vorhandene <code><ruleset></code>-Block ergänzt. Es darf dafür kein zweiter paralleler <code><ruleset></code>-Block angelegt werden.

Die relevante Konfiguration sollte sinngemäß folgendermaßen aussehen:

<syntaxhighlight lang="text">
<ruleset>
  <decoder_dir>ruleset/decoders</decoder_dir>
  <rule_dir>ruleset/rules</rule_dir>

  <decoder_dir>etc/decoders</decoder_dir>
  <rule_dir>etc/rules</rule_dir>

  <decoder_exclude>ruleset/decoders/0065-cisco-ios_decoders.xml</decoder_exclude>
</ruleset>
</syntaxhighlight>

In Standardinstallationen ist <code>etc/decoders</code> üblicherweise bereits eingetragen. Der bestehende Block sollte deshalb geprüft und nur um den fehlenden <code>decoder_exclude</code>-Eintrag ergänzt werden.

<code>decoder_exclude</code> verhindert, dass der originale und der angepasste Cisco-IOS-Decoder gleichzeitig geladen werden. Wazuh lädt stattdessen die vollständige Kopie aus <code>/var/ossec/etc/decoders/</code>. Die verfügbaren Regeln und Child-Decoder bleiben dadurch erhalten.

=== 5. Konfiguration vor dem Neustart validieren ===

Die globale Ruleset- und Decoder-Konfiguration lässt sich mit <code>wazuh-analysisd</code> prüfen:

<syntaxhighlight lang="text">
sudo /var/ossec/bin/wazuh-analysisd -t
</syntaxhighlight>

Der Parameter <code>-t</code> führt einen Konfigurationstest durch und sollte vor jedem Manager-Neustart verwendet werden.

=== 6. Beide Zeitstempelformate mit <code>wazuh-logtest</code> testen ===

<syntaxhighlight lang="text">
sudo /var/ossec/bin/wazuh-logtest
</syntaxhighlight>

Danach werden sowohl das Format mit als auch das Format ohne Millisekunden eingefügt:

<syntaxhighlight lang="text">
host.domain.com : Jul 21 2026 15:09:33.812 CEST: %SYS-SW1-5-CONFIG_I: Configured from console by username on vty0 (10.10.10.1)

host.domain.com : Jul 21 2026 15:09:33 CEST: %SYS-SW1-5-CONFIG_I: Configured from console by username on vty0 (10.10.10.1)
</syntaxhighlight>

Für beide Ereignisse muss Phase 2 mindestens folgende Felder liefern:

<syntaxhighlight lang="text">
name: 'cisco-ios'
cisco.facility: 'SYS-SW1'
cisco.severity: '5'
cisco.mnemonic: 'CONFIG_I'
</syntaxhighlight>

<code>wazuh-logtest</code> lädt Decoder und Regeln in einer eigenen Testsitzung. Gespeicherte Decoder-Änderungen können deshalb bereits vor dem Manager-Neustart geprüft werden. Für die produktive Ereignisverarbeitung ist anschließend weiterhin ein Neustart des Managers erforderlich.

Die in Phase 3 angezeigte Regel-ID und das Alert-Level können je nach Wazuh-Version und installierten eigenen Regeln abweichen. Entscheidend für diesen Test ist zunächst, dass der Decoder greift und die Cisco-Felder extrahiert werden.

=== 7. Wazuh Manager neu starten ===

<syntaxhighlight lang="text">
sudo systemctl restart wazuh-manager
</syntaxhighlight>

Anschließend sollte der Dienststatus kontrolliert werden:

<syntaxhighlight lang="text">
sudo systemctl status wazuh-manager --no-pager
</syntaxhighlight>

== Lessons Learned / Best Practices ==

=== Decoder-Tests müssen reale Zeitstempelvarianten enthalten ===

Ein einzelnes erfolgreich getestetes Cisco-Syslogformat reicht nicht aus. Für Netzwerkgeräte sollte mindestens eine Testmatrix aus folgenden Varianten gepflegt werden:

* einstelliger und zweistelliger Kalendertag,
* mit und ohne Jahr,
* mit und ohne Millisekunden,
* mit und ohne Zeitzone,
* mit <code>*</code> oder <code>.</code> als Cisco-Zeitstatus,
* mit Sequenznummer oder Origin-ID,
* mit und ohne vorgeschalteten Syslog-Relay-Hostname.

Gerade die Kombination mehrerer optionaler Bestandteile deckt Fehler auf, die bei isolierten Tests nicht sichtbar werden.

=== Nicht nur Phase 3 kontrollieren ===

Bei Decoderproblemen ist Phase 2 des Regeltests entscheidend. Wird dort <code>No decoder matched</code> angezeigt, kann eine nachgelagerte Regel das Ereignis nicht über strukturierte Cisco-Felder auswerten.

Ein vorhandenes Rohlog ist daher nicht automatisch gleichbedeutend mit funktionierender Security Detection.

=== Level 0 ist kein produktiver Alarm ===

Im ursprünglichen Test wurde nach erfolgreicher Dekodierung eine generische Cisco-IOS-Regel mit Level 0 erreicht. Das bedeutet, dass das Ereignis zwar klassifiziert wurde, daraus aber nicht zwingend ein sichtbarer Alarm entsteht.

Für sicherheitsrelevante Meldungen wie <code>CONFIG_I</code> sollte separat geprüft werden, ob eine passende Regel für die verwendete Facility existiert. Hersteller- oder standortspezifische Facilities wie <code>SYS-SW1</code> können von Regeln abweichen, die ausschließlich <code>SYS</code> erwarten. In diesem Fall ist nach der Decoder-Korrektur zusätzlich eine eigene Regelanpassung erforderlich.

=== Benutzerdefinierte Kopien erzeugen Upgrade-Verantwortung ===

Durch den Ausschluss der Originaldatei erhält die benutzerdefinierte Kopie keine zukünftigen Änderungen des ausgelieferten Cisco-IOS-Decoders. Wazuh weist in der Dokumentation ausdrücklich darauf hin, dass relevante Upstream-Änderungen nach Upgrades manuell übernommen werden müssen.

Nach jedem Wazuh-Upgrade sollte deshalb ein Vergleich erfolgen:

<syntaxhighlight lang="text">
diff -u \
  /var/ossec/ruleset/decoders/0065-cisco-ios_decoders.xml \
  /var/ossec/etc/decoders/custom-cisco-ios_decoders.xml
</syntaxhighlight>

Dabei müssen die eigene Korrektur und neue offizielle Decoder-Erweiterungen zusammengeführt werden. Sobald die verwendete Wazuh-Version das betroffene Format nativ korrekt verarbeitet, kann die benutzerdefinierte Kopie nach vollständigem Regressionstest wieder entfernt werden.

=== Änderungen versionieren ===

Eigene Decoder, Regeln und relevante Ausschnitte aus <code>ossec.conf</code> sollten in einer Versionsverwaltung dokumentiert werden. Sinnvoll sind zusätzlich:

* betroffene Wazuh-Version,
* repräsentative anonymisierte Testlogs,
* erwartete Decoder-Felder,
* erwartete Regel-ID und Alert-Stufe,
* Datum der letzten Prüfung gegen den ausgelieferten Decoder.

Damit lässt sich nach Upgrades nachvollziehen, warum eine Abweichung vom Standard-Ruleset existiert.

== Fazit ==

Die Ursache lag nicht grundsätzlich in der Unterstützung von Millisekunden, sondern in einer einzelnen unvollständigen <code>prematch</code>-Alternative für die Kombination aus zweistelligem Tag, Jahr, Millisekunden und Zeitzone.

Durch das Kopieren des vollständigen Cisco-IOS-Decoders in das benutzerdefinierte Decoder-Verzeichnis, die Korrektur des Tagesausdrucks und den Ausschluss der Originaldatei kann Wazuh beide Zeitstempelformate zuverlässig verarbeiten.

Besonders wichtig sind dabei drei Punkte: OSRegex besitzt eine von PCRE abweichende Punktsyntax, mehrere <code>prematch</code>-Elemente werden verkettet und eine vollständig kopierte Decoder-Datei muss nach Wazuh-Upgrades manuell mit dem ausgelieferten Ruleset abgeglichen werden.

== Quellenverweise ==

Cisco-IOS-Decoder der untersuchten Wazuh-Version:
[https://github.com/wazuh/wazuh/blob/8c41e20c34c9b455e1976b5962c79f8631b31004/ruleset/decoders/0065-cisco-ios_decoders.xml https://github.com/wazuh/wazuh/blob/8c41e20c34c9b455e1976b5962c79f8631b31004/ruleset/decoders/0065-cisco-ios_decoders.xml]

Wazuh-Dokumentation zu benutzerdefinierten und angepassten Decodern:
[https://documentation.wazuh.com/current/user-manual/ruleset/decoders/custom.html https://documentation.wazuh.com/current/user-manual/ruleset/decoders/custom.html]

Wazuh Decoder Syntax:
[https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html]

Wazuh Regular Expression Syntax:
[https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html]

Wazuh-Regeln und Decoder testen:
[https://documentation.wazuh.com/current/user-manual/ruleset/testing.html https://documentation.wazuh.com/current/user-manual/ruleset/testing.html]

[https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program Mehr zu Wazuh …]

[https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program Mehr zum Wazuh Ambassador Program …]

[https://wazuh.slack.com/archives/C07CCCCGHHP/p1784804208375469 https://wazuh.slack.com/archives/C07CCCCGHHP/p1784804208375469]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/cisco-ios-syslog-mit-millisekunden-in-wazuh-korrekt-dekodieren/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 30. Juli 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 [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]