Wazuh-Agenten plötzlich offline: Wie eine fehlerhafte Syslog-Konfiguration die gesamte Agent-Kommunikation lahmlegt

von

Einleitung

Stabile Agent-Konnektivität ist die Grundlage jeder Wazuh-Installation. Wenn plötzlich alle Agenten im Dashboard als „disconnected“ erscheinen, obwohl Systeme laufen und Benutzer aktiv sind, deutet dies meist auf ein zentrales Konfigurations- oder Kommunikationsproblem hin. Besonders kritisch wird es, wenn mehrere Funktionen – etwa Agent-Kommunikation und Syslog-Empfang – auf derselben Schnittstelle konfiguriert werden.

Dieser Beitrag analysiert einen realen Community-Fall, bei dem eine scheinbar korrekte Syslog-Konfiguration dazu führte, dass sämtliche Wazuh-Agenten die Verbindung zum Manager verloren. Die Ursache liegt tiefer in der Wazuh-Architektur begründet, als es auf den ersten Blick scheint.

Ausgangslage / Problemstellung

In der beschriebenen Umgebung waren Wazuh Manager, Indexer und Dashboard kürzlich erfolgreich aktualisiert worden und mehrere Wochen stabil in Betrieb. Ohne erkennbare Änderung meldeten sich jedoch plötzlich alle Agenten als „offline“.

Typische Symptome:

  • Alle Agenten im Wazuh-Dashboard disconnected
  • Agentenprozesse laufen weiterhin auf den Endpunkten
  • Im Agent-Log erscheint wiederholt:
    WARNING: (4101): Waiting for server reply (not started)
  • Benutzeraktivität auf den Systemen vorhanden, aber keine neuen Events im SIEM

Die Kommunikation der Agenten erfolgte regulär über TCP Port 1514. Parallel dazu wurde begonnen, den Wazuh Manager als Syslog-Server zu konfigurieren – gemäß offizieller Dokumentation.

Technische Analyse

Relevante Architekturkomponenten

Wazuh nutzt im ossec.conf die <remote>-Blöcke, um eingehende Verbindungen zu definieren. Dabei ist entscheidend:

  • Agent-Kommunikation (<connection>secure</connection>)
  • Syslog-Empfang (<connection>syslog</connection>)

Beide Funktionen verwenden dieselbe Konfigurationsstruktur, erfüllen jedoch völlig unterschiedliche Aufgaben.

Kernproblem: Mehrfachnutzung eines <remote>-Blocks

Im vorliegenden Fall wurde ein Syslog-Listener in denselben <remote>-Block integriert bzw. nicht sauber getrennt. Beispiel:

<remote>
  <connection>syslog</connection>
  <port>6514</port>
  <protocol>tcp</protocol>
  <allowed-ips>192.x.x.x</allowed-ips>
  <local_ip>192.x.x.x</local_ip>
</remote>

Wird versucht, Agent-Kommunikation und Syslog innerhalb eines gemeinsamen oder falsch priorisierten <remote>-Blocks zu konfigurieren, greift intern nur die zuletzt definierte Port- und Connection-Kombination. Die vorherige Definition wird stillschweigend überschrieben.

Die Folge:

  • Entweder funktionieren Agenten oder Syslog
  • Niemals beides gleichzeitig
  • Reihenfolge im ossec.conf entscheidet über Erfolg oder Ausfall

Warum Port 1514 nicht für Syslog geeignet ist

Port 1514 ist ausschließlich für die verschlüsselte Agent-Kommunikation vorgesehen. Wird er zusätzlich für Syslog genutzt:

  • bricht die Agent-Kommunikation vollständig ab oder
  • der Syslog-Dienst startet nicht korrekt

Wazuh trennt diese Kommunikationspfade bewusst, um Integrität, Authentizität und Skalierbarkeit sicherzustellen.

Lösung / Best Practices

1. Strikte Trennung der <remote>-Blöcke

Agent-Kommunikation (Standard):

<remote>
  <connection>secure</connection>
  <port>1514</port>
  <protocol>tcp</protocol>
  <queue_size>131072</queue_size>
</remote>

Separater Syslog-Listener:

<remote>
  <connection>syslog</connection>
  <port>6514</port>
  <protocol>tcp</protocol>
  <allowed-ips>192.168.2.0/24</allowed-ips>
  <local_ip>192.168.2.10</local_ip>
</remote>

Die vollständige Referenz dazu findet sich in der offiziellen Dokumentation:
https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/syslog.html

2. Wahl des Syslog-Ports

  • 514 (Standard): nur sinnvoll, wenn kein OS-Syslog (rsyslog, syslog-ng) aktiv ist
  • 6514: empfohlene Alternative, insbesondere für TLS-gesichertes Syslog
  • Niemals: 1514

3. Alternative: Syslog über Agent + rsyslog

Die robusteste und skalierbarste Variante besteht darin, Syslog nicht direkt am Manager, sondern über einen dedizierten Agenten zu sammeln:

  1. rsyslog empfängt Logs und schreibt sie in Dateien
  2. Wazuh-Agent liest diese Dateien via <localfile>
  3. Manager bleibt ausschließlich für Agent-Traffic zuständig

Dokumentation:
https://documentation.wazuh.com/current/cloud-service/your-environment/send-syslog-data.html#rsyslog-on-linux

Lessons Learned / Best Practices

  • Agent-Kommunikation und Syslog niemals in denselben <remote>-Block konfigurieren
  • Port 1514 ist exklusiv für Wazuh-Agenten reserviert
  • Änderungen am ossec.conf können globale Auswirkungen haben
  • Funktionierende Konfigurationen sollten versioniert und dokumentiert werden
  • Für größere Umgebungen ist Syslog-Sammlung über Agent + rsyslog deutlich wartungsfreundlicher
  • Nach Änderungen immer ossec.log auf Warnungen und Fehler prüfen

Fazit

Ein einzelner falsch platzierter <remote>-Block kann ausreichen, um eine komplette Wazuh-Umgebung lahmzulegen. Der hier analysierte Fall zeigt eindrücklich, wie wichtig ein tiefes Verständnis der Wazuh-Kommunikationsarchitektur ist – insbesondere beim parallelen Einsatz von Agenten und Syslog-Quellen.

Die saubere Trennung von Kommunikationspfaden, die richtige Portwahl und der Einsatz bewährter Best Practices verhindern nicht nur Ausfälle, sondern sorgen langfristig für Stabilität und Skalierbarkeit im SIEM-Betrieb.

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/C07BK5RJM3R/p1766383285695609