Wazuh „Not enough buffer space“ in wazuh-remoted: Warum einzelne Agents Konfigs nicht mehr bekommen und wie man bqueue-/Send-Buffer-Backpressure sauber debuggt

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Wenn Wazuh-Agenten keine Shared Configs oder Active-Response-Kommandos mehr erhalten, ist das kein „Komfortproblem“, sondern ein Sicherheitsrisiko: Policies, Detektionslogik und Reaktionen kommen nicht mehr zuverlässig am Endpoint an. In der Praxis äußert sich das häufig über wazuh-remoted-Meldungen wie „Not enough buffer space“ und „Package dropped“. Der reflexartige Ansatz, remoted.send_buffer_size hochzusetzen, hilft oft nur kurzfristig – weil die eigentliche Ursache meist Backpressure ist: Der Manager schreibt weiter Daten in eine per-Agent-Queue, während der Agent sie nicht (mehr) zuverlässig abnimmt oder quittiert.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Beobachtungen aus dem Thread:

  • Wazuh Server/Worker: 4.10.1
  • Betroffene Agents: u. a. Debian 12, Agent-Version 4.5.4 (deutlich älter)
  • Wiederkehrende Worker-Logs:
    • Not enough buffer space... (nahezu vollgelaufener Send Buffer)
    • Package dropped...
  • Auswirkungen:
    • Shared configuration / Active response werden nicht mehr zugestellt (Control-Plane betroffen)
  • Auffällig:
    • Nur wenige Agents betroffen, andere am selben Worker funktionieren
    • Neustart von Manager/Worker ändert nichts
    • Agent zeigt „Active“, aber Agent-Log meldet:
      • (1218): Unable to send message to 'server': Connection timed out
      • (1218): Unable to send message to 'server': Success

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) Was „Not enough buffer space“ in remoted praktisch bedeutet

wazuh-remoted ist der Server-seitige Daemon für die Agent-Kommunikation.
Intern hält remoted je Verbindung Warteschlangen/Queues (u. a. für ausgehende Daten wie zentrale Konfiguration). Wenn ein Agent diese Daten nicht schnell genug abnimmt (oder die Verbindung instabil ist), steigt der Used-Teil des Buffers, bis neue Nachrichten nicht mehr appended werden können – dann folgen Retries und schließlich Drops.

Dass das Problem nur bei einzelnen Agents auftritt, ist ein starker Hinweis auf Agent-spezifische Drain-Probleme (Netz, TLS, Retries, Version/Kompatibilität, defekte Enrollment-Keys, „flapping“ Verbindungen) statt auf eine globale Manager-Knappheit.

2) „Timeout/Success“-Muster: Socket-/Transportproblem statt RAM/CPU

Die Kombination aus Connection timed out und dem irritierenden „Success“ ist ein Indikator für socket-level Instabilität (Verbindungsabbrüche, Retransmits, NAT/Firewall/IPS, MTU, TLS-Inspection, Paketverlust). Genau deshalb zielt die Wazuh Enrollment-Troubleshooting-Doku zuerst auf Erreichbarkeit/Ports/Netzpfad ab.

Wenn ein Agent zwar als „Active“ auftaucht, aber wiederholt Timeouts beim Senden protokolliert, kann die Session „halb offen“ sein: Der Manager hält noch Pending-Daten (z. B. Konfig), der Agent nimmt sie nicht zuverlässig an – die per-Agent-Queue wächst.

3) Version Drift: Manager 4.10.1 vs. Agent 4.5.4

Ein Agent, der mehrere Minor-/Patch-Zyklen hinter dem Manager liegt, ist ein klassischer Multiplikator für Kommunikations- und Protokollrandfälle. Wazuh liefert explizit Anleitungen für Agent-Upgrades (lokal oder remote) und empfiehlt, Agents aktuell zu halten.
Im Thread war das Upgrade daher der naheliegende, risikoarme Hebel: Erst auf denselben Versionszweig bringen, dann weiter analysieren.

4) Messpunkte statt Bauchgefühl: wazuh-remoted.state

Wazuh stellt mit wazuh-remoted.state eine Statistikdatei bereit (u. a. Queue-Größen, discarded messages, Verbindungen) – ideal, um festzustellen, ob es ein per-Agent Queue-/Discard-Problem gibt und ob sich das mit den Remoted-Logs deckt.

5) Enrollment-/Key-Probleme können Backpressure triggern

Wenn ein Agent nicht sauber enrolled (agent-auth scheitert, Keys manuell kopiert), ist es möglich, dass er zwar „erscheint“, aber in der Kommunikation ständig neu aushandelt/abbricht. Wazuh dokumentiert sowohl Troubleshooting bei Enrollment als auch das saubere Entfernen von Agents, um eine saubere Re-Enrollment-Basis zu schaffen.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: Backpressure objektivieren (Manager/Worker)

  1. Per-Agent remoted Statistik prüfen
    Datei: /var/ossec/var/run/wazuh-remoted.state
    Achten Sie auf:
  • Queue/Buffer-Werte, Discards
  • Auffällige Werte korrelierend zu den betroffenen Agent-IDs
  1. Remoted-Logs für betroffene Agent-ID filtern
grep -E "Not enough buffer space|Package dropped|<AGENT_ID>" /var/ossec/logs/ossec.log
  1. Remoted Debug gezielt aktivieren (nur temporär)
    Wazuh verweist darauf, dass interne Optionen primär fürs Troubleshooting gedacht sind und bei Fehlern das System beeinträchtigen können.
    Aktivieren Sie Debug nur kurzzeitig und dokumentieren Sie die Änderung (und dass internal_options.conf bei Upgrades überschrieben werden kann).

Schritt 2: Agent-seitige Ursache abklopfen (Netz/TLS/Flapping)

  1. Agent-Log prüfen (Linux: /var/ossec/logs/ossec.log) – Wazuh nennt den Pfad auch im Enrollment-Troubleshooting.
    Suchen nach:
  • reconnect loops
  • TLS/Certificate errors
  • „unable to send message“ Häufung
  • Konfig-Update-/Module-Fehler
  1. Netzpfad validieren (ohne Annahmen):
  • Ports/Erreichbarkeit gemäß Enrollment-Troubleshooting testen (Firewall, Security Groups, Middleboxes).

Schritt 3: Versionsstand angleichen (wichtigster Quick Win)

  • Agent von 4.5.4 auf „current“ upgraden gemäß Upgrade Guide.
    Wazuh bietet lokale und remote Upgrade-Optionen (agent_upgrade / API).

Side-Effect/Planung: Vor dem Upgrade die Agent-Konfiguration sichern (lokale Änderungen, custom integrations) und in Wartungsfenstern deployen.

Schritt 4: Wenn Enrollment/Keys „unsauber“ wirken: sauber entfernen und neu enrollen

  • Agent in Wazuh korrekt entfernen (CLI oder API) und danach sauber neu registrieren.
    Das reduziert den „Schmutz“ aus alten Keys/IDs und hilft, Protokollrandfälle auszuschließen.

Schritt 5: Wenn nach Upgrade & sauberem Enrollment weiterhin Drops auftreten

Dann ist die Wahrscheinlichkeit hoch, dass es agent-spezifische Störungen gibt (z. B. Network Devices, VPN, MTU, NAT Timeouts, IDS/IPS). In dem Fall sind die entscheidenden Artefakte:

  • remoted.state Snapshot(s) im 5–10s Raster (zeigt Trends)
  • Manager ossec.log Ausschnitt für die Agent-ID
  • Agent ossec.log Ausschnitt mit denselben Zeitstempeln
  • Ggf. ein Paket-Capture (nur wenn betrieblich möglich)

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • Agent-Versionen nicht „jahrelang“ hinterherziehen: Version Drift ist ein Risiko für Stabilität und Debugbarkeit. Upgrade-Mechanismen sind dokumentiert und sollten regelmäßig genutzt werden.
  • Backpressure immer per Statistikdateien messen: wazuh-remoted.state ist der schnellste Weg, Queue-/Discard-Probleme von „gefühlt“ zu „belegt“ zu machen.
  • Enrollment-Probleme nicht „workarounden“ (manuelles Key-Kopieren als Dauerlösung): lieber sauber entfernen und neu enrollen, wenn die Kommunikation auffällig ist.
  • Konfig-Tuning ist sekundär: send_buffer_size hochzusetzen kann Symptome verschieben, behebt aber nicht, warum ein einzelner Agent nicht drainen kann.

Fazit (knappe Zusammenfassung mit Mehrwert)

„Not enough buffer space“ in wazuh-remoted ist in der Regel kein reines Manager-Tuning-Thema, sondern ein Signal für per-Agent Backpressure: Der Manager kann Daten für einen Agent nicht zuverlässig zustellen, die Queue läuft voll, Pakete werden gedroppt – und zentrale Konfiguration/Active Response bleiben hängen. In der Praxis führt der schnellste Weg zur Ursache über: wazuh-remoted.state prüfen, Agent-Kommunikation (Timeout/Flapping) validieren, Agent-Version an den Manager anpassen und bei Bedarf sauber neu enrollen. Erst wenn diese Grundlagen stimmen, lohnt Feintuning am Buffer.

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