Vergangene Logs mit Wazuh erfassen: Was der Agent standardmäßig sammelt, was wirklich tut und wie man historische Logs sicher nachlädt

von

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

Wazuh ist primär als Realtime-SIEM/XDR-Plattform konzipiert. Entsprechend sammelt der Agent standardmäßig nur neue Logeinträge, die ab dem Start des Logcollectors entstehen. In der Praxis entsteht jedoch häufig der Bedarf, bereits vorhandene Logs (z. B. vor der Agent-Installation oder während einer Downtime) nachträglich zu analysieren – etwa im Rahmen einer forensischen Untersuchung oder eines Incident-Backfills. Dieser Beitrag klärt, was mit Wazuh möglich ist, wo häufige Missverständnisse liegen und wie man historische Logs kontrolliert und betriebssicher in Wazuh einspeist.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Typische Fragestellung:

  • „Kann der Wazuh Agent alle bestehenden Logs auf dem System einsammeln oder nur neue?“
  • Erwartung: Nach Agent-Installation sollen auch alte Einträge aus /var/log/* oder Windows Event Logs sichtbar werden.
  • Realität: Nach der Installation erscheinen keine historischen Alerts, nur neue Events.

Relevanter Kontext:

  • Wazuh Agent mit aktivem wazuh-logcollector
  • Logquellen über <localfile> in ossec.conf
  • Linux- oder Windows-Systeme (Mechanik unterscheidet sich)

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

1) Standardverhalten des Wazuh Logcollectors

Der Wazuh Logcollector setzt beim Start des Agents seinen Lesezeiger standardmäßig ans Ende der Logdatei. Das bedeutet:

  • Logeinträge, die vor dem ersten Start des Agents existierten, werden nicht gelesen
  • Logeinträge, die während eines Agent-Stillstands geschrieben wurden, werden beim nächsten Start übersprungen

Dieses Verhalten ist bewusst so implementiert, um:

  • Massive Backlogs zu vermeiden
  • Agent-, Manager- und Queue-Überläufe zu verhindern
  • Realtime-Analyse zu priorisieren

Wazuh ist damit kein klassisches „Log-Archiv-Replay“-System, sondern ein Streaming-orientiertes SIEM.

2) Das häufig missverstandene <only-future-events>

Die Option <only-future-events> wird oft falsch interpretiert.

Wichtig:
<only-future-events>no</only-future-events> bedeutet nicht, dass Wazuh automatisch vom Anfang einer Logdatei liest.

Die tatsächliche Funktion ist:

  • yes (Default):
    Beim Start des Agents wird immer ans Ende der Datei gesprungen.
  • no:
    Der Logcollector merkt sich die letzte gelesene Position.
    Wenn der Agent stoppt und später neu startet, liest er ab der letzten bekannten Position weiter, statt ans Ende zu springen.

Damit verhindert man Event-Verlust während Agent-Downtimes, bekommt aber keine Logs von vor der Erstinstallation.

Offizielle Dokumentation:
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#only-future-events

3) Warum Wazuh alte Logs nicht automatisch „rewindet“

Ein automatisches Einlesen kompletter Loghistorien hätte erhebliche Nebenwirkungen:

  • Extreme Last auf Agent (CPU, RAM, Queue)
  • Event-Drops im Agent-Client-Buffer
  • Backpressure auf Manager, Remoted und Indexer
  • Alerts ohne zeitlichen Kontext (Monate/Jahre alt)

Daher überlässt Wazuh das bewusste Nachladen historischer Logs dem Administrator.

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

Option A: Vergangene Logs seit letztem Agent-Stopp erfassen

Wenn das Ziel ist, Logs nicht zu verlieren, die während eines Agent-Neustarts entstanden sind:

<ossec_config>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
    <only-future-events>no</only-future-events>
  </localfile>
</ossec_config>

➡️ Der Agent liest nach einem Neustart dort weiter, wo er zuvor aufgehört hat.
➡️ Keine historische Rückwärtsanalyse, aber saubere Kontinuität.

Dokumentation:
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#only-future-events

Option B: Historische Logs bewusst nachladen (Linux)

Wenn bereits existierende Logs analysiert werden sollen (z. B. forensisch), ist ein kontrolliertes Replay nötig.

Bewährtes Vorgehen:

  1. Logdatei sichern
cp /var/log/example.log /tmp/example.log.backup
  1. Originaldatei leeren (Logcollector springt an den Anfang)
: > /var/log/example.log
  1. Alte Inhalte wieder appendieren, damit sie als „neue Events“ erscheinen
cat /tmp/example.log.backup >> /var/log/example.log
  1. Backup entfernen
rm /tmp/example.log.backup

➡️ Wazuh sieht alle angehängten Zeilen als neue Logevents und verarbeitet sie vollständig.

Option C: Rate-Limiting beim Nachladen (dringend empfohlen)

Das ungefilterte Anhängen von zehntausenden Logzeilen kann:

  • Agent-Queues überlaufen lassen
  • Zu massivem Event-Drop führen (50 %+ Verlust ist realistisch)

Best Practice ist rate-limited Replay, z. B. mit pv:

cat /tmp/example.log.backup | pv --line-mode --rate-limit 200 >> /var/log/example.log

➡️ Max. 200 Zeilen pro Sekunde
➡️ Deutlich stabiler Betrieb für Agent, Manager und Indexer

Dieses Verfahren eignet sich auch für gezielte Replays einzelner Zeiträume oder Logfiles.

Option D: Alternative Tools für reine Forensik

Wenn das Ziel nicht Realtime-SIEM, sondern tiefe forensische Analyse historischer Logs ist, kann es sinnvoll sein, ergänzende Tools zu nutzen (z. B. für Sigma-Detections auf alten Logs) und Wazuh eher für laufende Überwachung einzusetzen.

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

  • Wazuh ist Streaming-first, kein automatisches Log-Archiv-Replay
  • <only-future-events> schützt vor Event-Verlust bei Neustarts, ersetzt aber kein Backfill
  • Historische Logs sollten gezielt und kontrolliert nachgeladen werden
  • Rate-Limiting ist Pflicht, um Queue- und Buffer-Probleme zu vermeiden
  • Für forensische Sonderfälle: bewusst entscheiden, ob Wazuh oder spezialisierte Tools genutzt werden

Fazit (knappe Zusammenfassung mit Mehrwert)

Ein Wazuh Agent sammelt standardmäßig nur neue Logevents ab dem Start des Logcollectors. Bereits vorhandene Logs werden nicht automatisch eingelesen. Mit <only-future-events>no</only-future-events> lassen sich zwar Lücken bei Agent-Neustarts vermeiden, echte historische Analysen erfordern jedoch ein bewusstes Replay der Logdaten. Mit kontrolliertem Append und Rate-Limiting lassen sich alte Logs zuverlässig und betriebssicher in Wazuh einspeisen – ohne das SIEM zu überlasten.

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