MikroTik-Logs kommen an – aber erscheinen nicht im Wazuh Dashboard: Ursachenanalyse und saubere Lösung

von

Einleitung

Die Einbindung von Netzwerkgeräten über Syslog gehört zu den klassischen Einsatzszenarien von Wazuh. Gerade Router wie MikroTik liefern sicherheitsrelevante Informationen zu Verbindungen, Firewalls, NAT und Systemereignissen. Häufig tritt jedoch ein typisches Problem auf: Die Logs werden korrekt per Syslog empfangen und sogar im Wazuh-Archiv gespeichert, tauchen aber weder als Alerts noch in den Dashboards auf.

Dieser Beitrag zeigt anhand eines realistischen Community-Falls, warum das passiert, wie man es technisch korrekt analysiert und wie fehlende Decoder- und Rule-Matches sauber ergänzt werden, damit MikroTik-Logs im Wazuh Dashboard sichtbar und auswertbar werden.

Ausgangslage / Problemstellung

  • MikroTik-Router sendet Logs per Syslog
  • Logs werden auf einem Syslog-Server gespeichert
  • Wazuh-Agent + rsyslog sind gemäß offizieller Anleitung konfiguriert
  • Im Wazuh Dashboard erscheinen keine MikroTik-Events oder Alerts

Wichtig: Es liegt kein Ingest-Problem vor. Die Logs kommen an, werden aber nicht weiterverarbeitet.

Technische Analyse

1. Der häufigste Denkfehler: „Logs da = Alerts da“

Wazuh unterscheidet strikt zwischen:

  • Empfangenen Rohlogs
  • Dekodierten Events
  • Regelbasierten Alerts

Nur Logs, die:

  1. korrekt dekodiert werden und
  2. mindestens eine Rule auslösen

erscheinen als Alerts im Indexer und damit im Dashboard.

2. Verifikation: Kommen die Logs wirklich beim Manager an?

Der erste Debug-Schritt ist immer die Archivierung. Damit lässt sich zweifelsfrei feststellen, ob der Wazuh Manager die Logs sieht.

Aktivieren der Archivierung in /var/ossec/etc/ossec.conf:

<ossec_config>
  <global>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Danach den Manager neu starten:

systemctl restart wazuh-manager

Prüfung der JSON-Archive:

cat /var/ossec/logs/archives/archives.json | grep "Mikrotik"

Ergebnis:
Die MikroTik-Logs sind vollständig vorhanden. Der Ingest funktioniert korrekt.

Nach der Verifikation sollte die Archivierung wieder deaktiviert werden, da sie dauerhaft hohe I/O-Last erzeugt.

3. Warum trotzdem keine Alerts entstehen

Beim Blick in die archivierten JSON-Einträge zeigt sich:

  • Ein Decoder greift teilweise oder generisch
  • Es wird keine passende Rule ausgelöst

Das bedeutet:

  • Die mitgelieferten MikroTik-Decoder aus der Dokumentation sind nicht vollständig kompatibel mit allen Logformaten
  • Abweichungen in Logstruktur, Reihenfolge oder Feldern verhindern einen vollständigen Decoder- und Rule-Match

Wichtig: Die offizielle Anleitung ist eine Referenz, keine vollständige Abdeckung aller MikroTik-Logvarianten.

Lösung / Best Practices

1. Eigene Decoder für nicht abgedeckte Logformate erstellen

Basierend auf einem realen MikroTik-Firewall-Log kann ein spezifischer Decoder ergänzt werden, z. B.:

<decoder name="mikrotik-firewall">
  <parent>mikrotik</parent>
  <regex type="pcre2">\S+ (\w+ \d+ \d+:\d+:\d+) Mikrotik (\w+): in:(\S+) out:\((.*?)\), connection-state:(\w+) src-mac (\S+), proto (\w+), (\d+\.\d+\.\d+\.\d+):(\d+)->(\d+\.\d+\.\d+\.\d+):(\d+), len (\d+)</regex>
  <order>logtimestamp, chain, in_interface, out_interface, conn_state, src_mac, protocol, src_ip, src_port, dst_ip, dst_port, packet_length</order>
</decoder>

Empfohlener Ablageort:

/var/ossec/etc/decoders/mikrotik_decoders.xml

2. Passende Rules definieren, damit Alerts entstehen

Ohne Rules bleiben selbst korrekt dekodierte Logs unsichtbar im Dashboard.

Beispielregel:

<rule id="110005" level="5">
  <if_sid>110000</if_sid>
  <match>connection-state:new</match>
  <description>MikroTik Firewall: Neue Verbindung erkannt</description>
</rule>

Empfohlener Ablageort:

/var/ossec/etc/rules/mikrotik_rules.xml

Nach Änderungen:

systemctl restart wazuh-manager

3. Ergebnis

  • MikroTik-Logs werden dekodiert
  • Regeln triggern Alerts
  • Events erscheinen im Wazuh Indexer
  • Dashboards zeigen Firewall-Aktivität, Verbindungen und sicherheitsrelevante Muster

Lessons Learned / Best Practices

  1. Archivierung ist das wichtigste Debug-Tool
    archives.json zeigt die Wahrheit – alles Weitere baut darauf auf.
  2. Decoder ≠ Rule
    Decoder strukturieren Logs, Rules erzeugen Bedeutung. Beides ist zwingend notwendig.
  3. Hersteller-Logs sind selten einheitlich
    Selbst innerhalb eines MikroTik-Setups können Logformate variieren. Eigene Sub-Decoder sind normal und erwartet.
  4. Dokumentation ist Referenz, nicht Garantie
    Die offiziellen Beispiele decken typische Fälle ab, aber nicht jede reale Logvariante.
  5. Saubere Trennung von Syslog und Analyse
    rsyslog + Wazuh Agent ist der empfohlene Weg, um Netzwerklogs stabil, puffersicher und kontrollierbar zu verarbeiten.

Fazit

Wenn MikroTik-Logs im Syslog und in archives.json sichtbar sind, aber nicht im Wazuh Dashboard erscheinen, liegt das Problem fast immer an fehlenden oder unpassenden Decodern und Rules. Durch gezielte Analyse der archivierten JSON-Logs und das Ergänzen eigener Decoder- und Regeldefinitionen lässt sich die Sichtbarkeit vollständig herstellen. Dieser Ansatz ist kein Workaround, sondern gelebte Best Practice im produktiven Wazuh-Betrieb mit Netzwerkgeräten.

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