Wazuh Syslog: UniFi-Logs per CEF an Wazuh senden und auswerten

UniFi liefert mehr als Portstatistiken und WLAN-Auslastung. In den Systemlogs stehen unter anderem Anmeldungen an der Verwaltung, Firewall-Ereignisse, Geräteprobleme und Verbindungswechsel. Mit Wazuh kann ich diese Meldungen neben den Sicherheitsereignissen meiner Linux-Server betrachten.

Bei mir läuft das mit einem UCG-Ultra. Das Gateway schickt seine Ereignisse per Syslog an den Wazuh-Manager, und Wazuh wertet sie zusammen mit den Daten meiner Linux-Server aus: zwei Proxmox-Hosts mit zahlreichen VMs und zwei VPS bei Hetzner.

Wazuh Syslog oder SNMP? Zwei verschiedene Fragen

Für Erreichbarkeit, Portlast und ähnliche Messwerte verwende ich weiterhin UniFi mit Zabbix per SNMP. Syslog ergänzt das um Ereignisse. Ein Switch kann erreichbar sein und trotzdem eine wichtige Sicherheitsmeldung senden. Umgekehrt beweist ein leerer Logeingang nicht, dass ein Access Point offline ist.

UniFi exportiert die neueren strukturierten Systemereignisse im Common Event Format, kurz CEF. Die Meldung besteht aus einem Header und zusätzlichen Schlüssel-Wert-Feldern. Klassische Geräte-Syslogs und dieser CEF-Export können unterschiedliche Konfigurationsstellen und Inhalte haben. UniFi System Logs und SIEM

Den Wazuh-Syslog-Eingang am Manager einrichten

Für die hier gezeigte Umgebung verwende ich UDP 514. Prüfe bei deiner UniFi-Version das tatsächlich verwendete Transportprotokoll und richte beide Seiten gleich ein. UDP selbst liefert weder Verschlüsselung noch eine Zustellbestätigung. Für einen entfernten Standort gehört die Strecke deshalb in ein abgesichertes Netz, beispielsweise einen passenden VPN-Pfad.

In die Manager-Konfiguration kommt zusätzlich zum vorhandenen sicheren Agenteneingang ein eigener remote-Block:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.50.1</allowed-ips>
</remote>

Die Beispieladresse ist die erlaubte Quelle des Gateways. Bei NAT oder einem Relay sieht der Manager möglicherweise eine andere Quelladresse. Verwende die tatsächlich beobachtete Adresse und begrenze sie passend. allowed-ips ist für den Syslog-Eingang erforderlich. Wazuh-Syslog-Konfiguration

In der Docker-Installation dieser Serie bearbeitest du die eingebundene Datei config/wazuh_cluster/wazuh_manager.conf. Veröffentliche den Port am Manager gezielt:

ports:
  - "192.168.50.10:514:514/udp"

Ergänze die Zeile im vorhandenen Ports-Block und starte den Manager mit docker compose up -d --force-recreate wazuh.manager neu. Ein Neustart verursacht eine kurze Unterbrechung des Managers; plane ihn entsprechend. Prüfe danach die Startlogs auf Konfigurationsfehler.

Wo die Einstellung in UniFi steht

Die Screenshots zeigen die tatsächlich erreichbare Network-Konsole meines UCG-Ultra. In dieser Oberfläche liegt der Einstieg unter Integrationen → Systemprotokollierung / SIEM. Die Bezeichnung und Position können sich mit der Network-Version ändern.

Die Auswahl SIEM-Server öffnet die Kategorien sowie Serveradresse und Port. Für einen neuen Aufbau trägst du dort die erreichbare Adresse des Wazuh-Syslog-Empfängers und den vereinbarten Port ein. Beginne mit Verwaltungs-, Sicherheits- und Geräteereignissen; Client-Ereignisse erzeugen in einem größeren WLAN wesentlich mehr Meldungen.

Speichere in deinem Aufbau die gewünschte Weiterleitung erst nach dem Abgleich des Empfängers. Die Oberfläche bietet auch „Testereignis senden“. Ein harmloser Test ist hilfreicher als das absichtliche Auslösen einer Sicherheitsstörung.

Eingang, Decoder und Regel getrennt testen

Wenn nichts sichtbar wird, prüfe die Strecke in drei Schritten. Zunächst muss das Paket am Docker-Host eintreffen:

sudo tcpdump -ni any 'udp port 514' -c 10

Ein Paketmitschnitt kann personenbezogene Daten enthalten. Für den kurzen Funktionstest reicht normalerweise der Nachweis von Quelle, Ziel und Port. Anschließend prüfst du, ob der Manager die Meldung annimmt und ob eine Regel daraus einen Alert macht.

Eine anonymisierte CEF-Meldung kannst du interaktiv durch den Regeltester schicken:

docker compose exec wazuh.manager /var/ossec/bin/wazuh-logtest

Füge eine einzelne echte, zuvor bereinigte Testmeldung ein. Der Tester zeigt Decoder und ausgelöste Regel. Nicht jede UniFi-Meldung wird durch jede Wazuh-Version automatisch passend ausgewertet. In meiner Installation kommen dafür eigene Decoder und Regeln zum Einsatz. Überprüfe daher erst deine Ausgabe, bevor du Diagramme nach data.unifi.event_name baust. Der Feldname ist das Ergebnis meines Decoders, kein allgemein garantiertes UniFi-Feld in jeder Wazuh-Installation.

Mehrere Quellen eindeutig zuordnen

Bei mir erfolgt die Zuordnung anhand des Logquellenfeldes location. Kommen weitere Gateways hinzu, etwa über ein VPN, berücksichtige ich sowohl die LAN- als auch die mögliche VPN-Quelladresse. Werden mehrere Gateways über dasselbe Relay geschickt, reicht dieses Feld möglicherweise nicht mehr; dann muss ein vertrauenswürdiges Herkunftsmerkmal erhalten bleiben.

Liefert eine Quelle keine Ereignisse, schreibe ich im Dashboard ausdrücklich „keine UniFi-Ereignisse empfangen“ und nicht „alles in Ordnung“ oder „Gerät offline“.

Welche Ereignisse ein Alarm werden sollten

Ein WLAN-Client, der sich abmeldet, ist in einem normalen WLAN kein Grund für eine dringende Nachricht. Ein UniFi-Gerät, das offline geht, verdient mehr Aufmerksamkeit. Eine Intrusion-Meldung benötigt wiederum eine andere Bewertung als ein gewöhnlicher Verbindungswechsel.

Deshalb suche ich bei eigenen Regeln nicht pauschal nach dem Wort Disconnected. Das würde Client-Abmeldungen und Geräteausfälle vermischen. Ich prüfe Ereignistyp und Kontext und teste beide Fälle getrennt. Gleiches gilt für Firewall-Meldungen: „blockiert“ kann genau das gewünschte Verhalten der Firewall sein.

Mit dem Syslog-Eingang ist außerdem noch keine vollständige Flow-Auswertung oder Schwachstellenprüfung der AP-Firmware eingerichtet. Der Umfang hängt von den exportierten Kategorien, den Geräten und den Regeln ab. Die Telegram-Monitore setzen anschließend auf den bewerteten Ereignissen auf.