Wazuh „Too big message size“ bei VMware vSphere Syslog über Rsyslog: Ursachen, Grenzen und robuste Workarounds

von

Einleitung

VMware® vSphere erzeugt teils sehr verbose Syslog-Ereignisse – insbesondere bei bestimmten Audit-, API-, Hostd-/Vpxa- oder Security-relevanten Events. In SIEM-Pipelines, die vSphere → Rsyslog → Wazuh führen, tritt dann häufig ein scheinbar „mysteriöses“ Verhalten auf: Wazuh meldet „Too big message size“, kürzt Events, Decoder greifen nicht mehr sauber – und im Dashboard fehlt die erwartete Indexierung. Dieser Beitrag erklärt die technische Ursache, warum das erwartbar ist, und zeigt praxistaugliche Best Practices, um die Pipeline stabil zu betreiben.

Ausgangslage / Problemstellung

Umgebung (typisch):

  • Zwei VMware® vSphere Quellen senden Syslog an einen zentralen Rsyslog-Relay
  • Rsyslog leitet Syslog an einen Wazuh All-in-One (z. B. Wazuh 4.12.0) weiter
  • In Wazuh-Logs erscheinen Warnungen wie „Too big message size“
  • Wazuh trunkiert betroffene Nachrichten → Inhalte werden malformed → Decoder/Parser scheitern → kein sauberes Indexing im Dashboard

Symptom-Kern:
Die Übertragung funktioniert grundsätzlich, aber einzelne (oder viele) vSphere-Events sind so groß, dass sie die maximale Nachrichtengröße in Wazuh überschreiten. Das führt nicht nur zu Datenverlust, sondern oft auch zu „kaputten“ Syslog-Zeilen, die anschließend nicht mehr zuverlässig normalisiert/decodiert werden können.

Technische Analyse

1) Die harte Grenze liegt in Wazuh – nicht in rsyslog.conf

Wazuh verarbeitet eingehende Events (auch Syslog) über Komponenten, die intern mit einer maximalen Message-/Payload-Größe arbeiten. In der Praxis ist diese Grenze hart: Wenn ein Event darüber liegt, wird es verworfen oder gekürzt – und Wazuh protokolliert den Hinweis „Too big message size“. Die Folge ist eine Trunkierung mitten im Event, wodurch Syslog-Strukturen (Header, Structured Data, JSON-Fragmente, Key/Value-Blöcke) „zerschnitten“ werden.

Wichtig: Parameter wie max_message_size oder queue_size sind keine gültigen generischen Stellschrauben in ossec.conf, um diese Grenze beliebig nach oben zu drehen. Man kann also nicht „einfach“ Wazuh auf unbegrenenzte Syslog-Größe konfigurieren.

2) Warum Decoder und Indexierung dann ausfallen

Wazuh (und downstream OpenSearch/Indexer) lebt davon, dass Events deterministisch geparst werden können:

  • Syslog Header (RFC3164/5424) muss vollständig sein
  • Der Message-Body muss in erwarteter Struktur vorliegen (z. B. definierte Felder, vollständige JSON-Objekte, keine halben Key/Value-Paare)

Wenn Wazuh in der Mitte abschneidet, ist das Ergebnis oft syntaktisch ungültig. Dann greifen Standard-Decoder nicht, Custom-Decoder matchen nicht, Felder werden nicht extrahiert – und das Event landet bestenfalls als „raw/unparsed“, schlimmstenfalls gar nicht.

3) Ein reines „Rsyslog → Wazuh Forwarding“ ändert das Problem nicht

Auch wenn Rsyslog korrekt empfängt und weiterleitet: Solange die zu große Nachricht unverändert bei Wazuh ankommt, bleibt die Wazuh-Grenze der Flaschenhals. Deshalb kann ein Wechsel der Transportart (UDP/TCP) allein das Problem nicht lösen – er reduziert höchstens Paketverlust, nicht aber die Payload-Größe.

Lösung / Best Practices

Ziel ist: Kein Event größer als Wazuh-Maximum darf in Richtung Wazuh gelangen – und zwar vor der Übergabe an Wazuh. Dafür gibt es zwei praxistaugliche Strategien, je nach Anspruch an Datenintegrität.

Option A: „Safe Truncation“ im Rsyslog-Relay (robust, einfach, SIEM-tauglich)

Wenn ein vSphere-Event > Maximalgröße ist, wird es im Relay kontrolliert gekürzt (und idealerweise markiert). Damit bleibt das Syslog-Format stabil, Decoder können weiterhin arbeiten, und Wazuh „verschluckt“ sich nicht mehr.

Beispiel: Rsyslog Template mit Begrenzung des Message-Teils
(Prinzip: nur %msg% wird begrenzt; Header bleibt sauber)

# rsyslog.conf (Relay)

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

# WICHTIG: Message-Teil begrenzen (Wert konservativ unterhalb 64K wählen)
template(name="TplWazuhForward" type="string"
  string="<%pri%>%timestamp:::date-rfc3339% %hostname% %app-name%: %msg:1:60000%\n"
)

action(
  type="omfwd"
  target="WAZUH_IP"
  port="1514"
  protocol="tcp"
  template="TplWazuhForward"
  action.resumeRetryCount="-1"
  queue.type="linkedList"
  queue.size="100000"
)

Warum konservativ (z. B. 60000 statt 65536)?
Weil Overhead (Header, Timestamp-Rendering, ggf. Escape-Sequenzen) und unterschiedliche Pfade/Normalisierungen eine Rolle spielen. „Knapp drunter“ ist betrieblich stabiler als „theoretisch Maximum“.

Ergänzung (Best Practice): Truncation sichtbar machen
Du kannst ein Prefix hinzufügen, wenn abgeschnitten wird (z. B. über zusätzliche Regeln/Property-Tests), damit Analysten wissen: „Dieses Event ist gekürzt“. Das ist wichtig für Forensik/Compliance.

Option B: Splitting/Chunking vor Wazuh (datenintegrer, aber konzeptionell heikler)

Wenn du wirklich den kompletten Inhalt brauchst, ist „nur kürzen“ ggf. nicht akzeptabel. Dann müsstest du zu große Events vor Wazuh in mehrere kleinere, jeweils valide Events aufteilen (Chunking). Das ist möglich, hat aber Konsequenzen:

  • Wazuh/Decoder sehen mehrere Events statt einem
  • Korrelationslogik muss ggf. angepasst werden (z. B. über gemeinsame IDs, Sequenznummern)
  • Dashboards/Queries müssen „Reassembly“ berücksichtigen

In vielen SIEM-Setups ist Option A deshalb die bevorzugte Betriebsvariante, weil sie Stabilität und Parsebarkeit priorisiert.

Transport & Format: RFC5424, TCP, saubere Framing-Regeln

Unabhängig von A/B gilt:

  • TCP statt UDP für Forwarding zum SIEM (Verlust-/Fragmentierungsrisiken minimieren)
  • Möglichst konsistentes Format (RFC5424 ist oft robuster als „loose“ RFC3164-Varianten)
  • Keine „Kreativformate“ zwischen Relay und Wazuh, die Decoder schwer machen

Wichtig: Das löst nicht die Größenobergrenze, reduziert aber Sekundärfehler (z. B. halb kaputte Zeilen durch Transportprobleme).

Wazuh-Seite: Aufnahme korrekt, Parser stabil

Auf dem Wazuh Manager/All-in-One muss Syslog-Empfang korrekt definiert sein (Port/Protokoll/Format). Entscheidend ist anschließend: Es dürfen keine oversized Events mehr ankommen, sonst bleibt „Too big message size“ bestehen – egal wie sauber die Empfangskonfiguration ist.

Lessons Learned / Best Practices

  • Wazuh hat eine harte Maximalgröße pro Event. Plane Syslog-Pipelines so, dass Quellen/Relays darunter bleiben.
  • vSphere kann Extrem-Events erzeugen (z. B. sehr große strukturierte Payloads). Das ist kein „Rsyslog kaputt“, sondern eine Datenrealität.
  • Kontrolliertes Truncation im Relay ist oft der beste Kompromiss: SIEM bleibt stabil, Decoder funktionieren, Pipeline skaliert.
  • Markiere gekürzte Events sichtbar, damit Security-Analysten die Einschränkung kennen.
  • Behandle Relays als Normalisierungs-Schicht: Format vereinheitlichen, Größe begrenzen, Transport robust machen (TCP, Queueing).
  • Nach der Stabilisierung: Prüfe Decoder/Regeln gezielt für VMware/vSphere-Logs (insbesondere, wenn du zuvor malformed Daten hattest – das kann zu „false negatives“ geführt haben).

Fazit

Wenn Wazuh bei vSphere-Syslog über Rsyslog „Too big message size“ meldet, ist das in der Regel kein Konfigurationsfehler, sondern ein Größenlimit, das durch einzelne sehr große Events überschritten wird. Der zuverlässigste Weg ist, diese Events vor Wazuh zu entschärfen: entweder durch kontrollierte Begrenzung/Truncation (praxisbewährt) oder durch Chunking (datenvollständiger, aber operativ komplexer). Sobald keine oversized Messages mehr bei Wazuh ankommen, stabilisieren sich Decoder, Felderxtraktion und Indexierung im Dashboard wieder.

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