Windows Logoff-Events fluten Wazuh: So filterst du nur „echte“ User-Logins (AD/Windows Server)

von

Problem:
Auf einem Windows Server (z. B. Domain Controller/Active Directory) laufen die Windows User Logoff-Events heiß und erzeugen in Wazuh eine Log-Flut – ohne echten Mehrwert. Ziel ist: Nur relevante Login-Events behalten (z. B. interaktive Logins), den Rest möglichst früh abstellen.

Warum das passiert

Auf Windows-Systemen entstehen Login/Logout-Events sehr häufig – nicht nur durch „echte“ Benutzer, sondern auch durch:

  • Services, Scheduled Tasks, Systemprozesse
  • Netzwerk-Authentifizierung / Session-Management
  • RDP/Remote Sessions
  • Hintergrund-Mechanismen von AD/Windows

Typische Security Event IDs im Kontext:

  • 4624 (Logon)
  • 4634 (Logoff)
  • 4647 (User initiated logoff)

Das ist normal – aber in vielen Umgebungen für das SOC-Dashboard eher Rauschen.

Zwei Wege: „Stumm schalten“ vs. „an der Quelle filtern“

Option A: Auf dem Wazuh Manager per Rule „stumm schalten“

Du kannst Events über Regeln (Rule Level, Gruppen, Ignore/Drop-Mechanismen) so behandeln, dass sie nicht als Alert auftauchen.

Nachteil:
Das stoppt nicht die Flut selbst. Die Agenten lesen und senden die Events weiterhin – Bandbreite, Queue, Storage und Performance leiden trotzdem.

Option B (empfohlen): Bereits am Agent filtern (Eventchannel Query)

Der saubere Ansatz ist: Der Agent sammelt diese Events gar nicht erst.
Das erreichst du über eine Query im localfile-Block auf dem Windows Agent.

Beispiel (wie im Community-Thread vorgeschlagen) – Filter auf Event ID 4624 und Ausschluss eines LogonTypes:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event[System/EventID = 4624 and EventData/Data[@Name='LogonType'] != 10]</query>
</localfile>

Was macht das?

  • Es sammelt weiterhin 4624 (Logon),
  • aber nicht, wenn LogonType = 10 ist (typisch RDP/RemoteInteractive).

Damit reduzierst du Noise drastisch – ohne komplett auf Login-Telemetrie zu verzichten.

So gehst du praktisch vor

  1. Identifiziere die Flood-Events
    • Schau dir ein Beispiel in Wazuh an, z. B. aus:
      • /var/ossec/logs/alerts/alerts.json (Manager)
  2. Bestimme, was “echter Login” für dich bedeutet
    • Interaktiv an Konsole?
    • Nur bestimmte LogonTypes?
    • Nur bestimmte Accounts/Groups?
  3. Baue eine Query, die nur das sammelt, was du brauchst
    • Startpunkt: Event ID 4624
    • Optional: explizit nur „echte User“ (z. B. excluding Machine Accounts, Service Accounts)
  4. Deploye die Änderung auf dem Agent
    • In der Agent-Konfiguration (ossec.conf / agent.conf je nach Setup)
  5. Validiere das Ergebnis
    • Sinkt das Event-Volumen?
    • Kommen die gewünschten Logins weiterhin an?

Wichtig: Ohne Sample-Logs ist „perfektes Filtering“ schwer

Der Community-Responder hat es gut auf den Punkt gebracht:
Um die Query wirklich sauber zu machen, braucht man ein paar Beispiele der Events, die dich fluten (inkl. EventData-Felder), damit man genau diese Fälle ausschließt – und keine relevanten Logins aus Versehen wegfiltert.

Fazit

Wenn Windows-Logoff/Login-Events dein Wazuh fluten, ist Filtering am Agent der beste Hebel:

  • ✅ Weniger Noise
  • ✅ Weniger Storage/Indexer-Last
  • ✅ Weniger Agent/Manager-Overhead
  • ✅ Fokus auf wirklich relevante Logins

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …