Einleitung
Cisco-IOS-Syslog ist in vielen Netzwerken eine der wichtigsten Telemetriequellen für Zugriffskontrolle und Incident Response. Gerade erfolgreiche Logins sind für Security-Teams relevant (z. B. für Anomalieerkennung, Laterale Bewegung, Valid-Accounts-Missbrauch). Wazuh bringt zwar bereits Cisco-IOS-Decoder und Regeln mit – in der Praxis möchte man aber oft eigene Felder extrahieren und eigene Alerts erzeugen, ohne die Standardregeln komplett abzuschalten.
Dieser Beitrag zeigt eine saubere Vorgehensweise, wie du für Logs wie
21357: Dec 29 11:18:27: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: monetx.nms] [Source: 172.16.0.125] [localport: 23] at 11:18:27 PKT Mon Dec 29 2025
einen Custom-Decoder + Custom-Rule erstellst, die parallel zu den Default-Rules weiterlaufen – inklusive Test mit wazuh-logtest.
Ausgangslage / Problemstellung
Typische Symptome in der Praxis:
- Die Cisco-Logs werden bereits durch den Default Cisco-IOS Decoder erkannt, es feuern Standardregeln (z. B. eine generische Login-Rule).
- Man möchte zusätzlich eine eigene Rule erzeugen (z. B. mit MITRE-Mapping, anderem Level, eigenem Rule-ID-Bereich, erweiterten Feldern).
- Ein Custom-Decoder in
local_decoder.xmlmatcht nicht, weil der Default-Decoder „zuvor“ greift oder weil die Vererbung/Regex-Voraussetzungen nicht passen.
Wichtig: „Parallel“ bedeutet hier nicht, dass ein einzelnes Event automatisch zwei unterschiedliche Decoder-Namen erzeugt. Ziel ist, dass Default-Rules weiterhin verfügbar bleiben, während deine Custom-Rule zuverlässig auf deinem Decoder-Namen matcht.
Technische Analyse
Wie Wazuh Logs verarbeitet (relevant für dieses Problem)
Wazuh verarbeitet Logs in grob drei Stufen:
- Pre-decoding (Syslog-Header, Metadaten)
- Decoding (Decoder extrahiert Felder via
prematch/regex) - Rules (Matching via
decoded_as, Gruppen, Feldbedingungen)
Entscheidend: Decoder-Matching ist reihenfolge- und kontextabhängig. Decoder-Syntax hat klare Anforderungen: Wenn regex genutzt wird, braucht Wazuh eine sinnvolle Eingrenzung, z. B. über prematch oder program_name (direkt oder geerbt). Wazuh Dokumentation+1
Warum „nur local_decoder.xml“ oft nicht reicht
Bei Cisco-IOS-Logs existiert bereits ein Default-Decoder. Wenn du zusätzlich einen Decoder definierst, kann es passieren, dass:
- der Default-Decoder das Event bereits „in Besitz nimmt“, bevor dein lokaler Decoder greift,
- dein Decoder zu unspezifisch ist (kein eindeutiger
prematch), - oder dein Decoder nicht korrekt in die Cisco-Decoder-Kette eingebunden ist (fehlendes
parent).
Die Wazuh-Dokumentation empfiehlt für solche Fälle: Default-Decoder nicht direkt in ruleset/decoders ändern, sondern die Datei in /var/ossec/etc/decoders/ „übernehmen“ und die Originaldatei per decoder_exclude aus der Lade-Liste nehmen. Wazuh Dokumentation+1
Lösung / Best Practices
Zielbild
- Default Rules bleiben aktiv (keine
rule_exclude-Keule). - Default Cisco-IOS Decoder wird „ersetzt“ durch eine lokal kopierte Version, in die du deinen zusätzlichen Decoder vor die Standarddecoder setzt.
- Deine Custom Rule matcht auf
decoded_as=custom-cisco-login.
Schritt 1: Default-Decoderdatei gezielt ersetzen (ohne Default-Rules zu deaktivieren)
In /var/ossec/etc/ossec.conf im <ruleset>-Block nur den Original-Decoder ausschließen (keine Rules ausschließen):
<ruleset>
<!-- Default ruleset -->
<decoder_dir>ruleset/decoders</decoder_dir>
<rule_dir>ruleset/rules</rule_dir>
<!-- User-defined ruleset -->
<decoder_dir>etc/decoders</decoder_dir>
<rule_dir>etc/rules</rule_dir>
<!-- Exclude only the original Cisco IOS decoder file -->
<decoder_exclude>ruleset/decoders/0065-cisco-ios_decoders.xml</decoder_exclude>
</ruleset>
Hintergrund: decoder_exclude ist der saubere Mechanismus, um Default-Decoder auszutauschen. Wazuh Dokumentation+1
Schritt 2: Cisco-IOS Decoderdatei nach /var/ossec/etc/decoders/ kopieren
cp -a /var/ossec/ruleset/decoders/0065-cisco-ios_decoders.xml /var/ossec/etc/decoders/
Damit lädt Wazuh künftig die lokale Kopie (weil das Original explizit ausgeschlossen ist).
Schritt 3: Custom-Decoder vor den Standarddecodern einfügen
Öffne nun /var/ossec/etc/decoders/0065-cisco-ios_decoders.xml und füge oberhalb des passenden Default-Blocks (also früh in der Datei) diesen Decoder ein:
<decoder name="custom-cisco-login">
<parent>cisco-ios</parent>
<prematch>%SEC_LOGIN-5-LOGIN_SUCCESS</prematch>
<use_own_name>true</use_own_name>
<regex>user:\s(\S+)]\s\[Source:\s(\S+)]\s\[localport:\s(\d+)]</regex>
<order>srcuser, srcip, dstport</order>
</decoder>
Warum diese Form?
parent>cisco-ios</parent>bindet dich in die Cisco-IOS-Decoderfamilie ein, statt „gegen“ sie zu arbeiten.prematchmacht das Matching stabil und erfüllt die Empfehlung,regexnicht ohne Eingrenzung laufen zu lassen. Wazuh Dokumentation+1use_own_namesorgt dafür, dass dein Decodername (custom-cisco-login) im Event steht und damitdecoded_assauber matcht (Best Practice, wenn man innerhalb einer Decoderfamilie unterscheidbar sein will). Füruse_own_nameist ein klarerprematchin der Praxis ebenfalls wichtig. GitHub
Hinweis zur Regex-Robustheit: In Cisco-Logs sind die eckigen Klammern Teil des Formats. Deshalb werden [ und ] in der Regex sauber escaped (hier über \[ … ]). Wenn du abweichende Varianten hast (z. B. zusätzliche Felder), erweitere die Regex lieber schrittweise und teste mit wazuh-logtest.
Schritt 4: Custom Rule anlegen (lokal)
In /var/ossec/etc/rules/local_rules.xml:
<group name="syslog,cisco_ios,">
<rule id="100100" level="3">
<decoded_as>custom-cisco-login</decoded_as>
<description>Cisco IOS: Login Success for user $(srcuser) from $(srcip) (localport $(dstport))</description>
<mitre>
<id>T1078</id>
</mitre>
</rule>
</group>
decoded_asbindet die Rule hart an deinen Decoder.- Rule-IDs im lokalen Bereich (z. B. 100000+) sind gängig, um Kollisionen zu vermeiden.
- MITRE T1078 („Valid Accounts“) ist für erfolgreiche Logins häufig passend – je nach Use Case kannst du auch Level/Groups anders setzen.
Custom-Rules sind offiziell so vorgesehen. Wazuh Dokumentation+1
Schritt 5: Wazuh Manager neu starten
systemctl restart wazuh-manager
Die Dokumentation weist explizit darauf hin, dass Decoder/Rule-Änderungen erst nach Restart sicher greifen. Wazuh Dokumentation
Schritt 6: Funktionstest mit wazuh-logtest
Starte:
/var/ossec/bin/wazuh-logtest
Füge dann ein Beispiel-Log ein und prüfe:
- Phase 2:
name: 'custom-cisco-login' - Felder:
srcuser,srcip,dstport - Phase 3: Rule-Match auf deine ID
100100
wazuh-logtest ist das Standardtool, um Decoder-Extraktion und Rule-Matching reproduzierbar zu verifizieren. Wazuh Dokumentation+1
Lessons Learned / Best Practices
- Default-Rules nicht blind deaktivieren. Häufig reicht es, nur den Decoderpfad sauber zu „übernehmen“ (
decoder_exclude+ Kopie nach/var/ossec/etc/decoders). Wazuh Dokumentation+1 - Prematch zuerst, Regex danach. Ein präziser
prematcherhöht Performance und verhindert Überraschungen durch konkurrierende Decoder. Wazuh Dokumentation+1 - Decoder-Reihenfolge ist entscheidend. Platziere den Custom-Decoder vor dem Default-Block, damit er priorisiert wird.
- Regeln an Decoder binden (
decoded_as). So vermeidest du, dass deine Rule auf andere Cisco-Events feuert. - Regelmäßig mit
wazuh-logtesttesten, besonders nach Wazuh-Updates oder bei Logformat-Änderungen. Wazuh Dokumentation
Fazit
Wenn Cisco-IOS-Login-Events bereits durch Wazuh erkannt werden, ist der sauberste Weg zu einem eigenen Parsing/Alerting nicht das komplette Abschalten des Cisco-Rulesets, sondern das gezielte Ersetzen der Decoderdatei: Original per decoder_exclude deaktivieren, in /var/ossec/etc/decoders/ übernehmen und dort einen vorgelagerten Custom-Decoder ergänzen. Damit laufen Standardregeln weiter, während deine eigenen Felder und Rules stabil und wartbar greifen.
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/p1766996228400229