Wazuh Office 365 Integration läuft, aber keine Logs im Dashboard – am Ende waren es Zertifikate & Filebeat

von

Ausgangslage

In einem All-in-One-Setup (Wazuh Manager, Dashboard und Indexer auf derselben Azure-VM mit privater IP 10.0.1.4) wurde die Office 365 (O365) Integration eingerichtet. In ossec.log erschien zwar:

  • wazuh-modulesd:office365: INFO: Module Office365 started.

…trotzdem waren keine O365-Events im Wazuh Dashboard sichtbar, obwohl in Microsoft 365 Audit Logs vorhanden waren.

Symptome & erste Hinweise

  • Keine offensichtlichen Fehler in ossec.log (nur Warnungen).
  • O365-Modul startet sauber.
  • Subscriptions sind konfiguriert (z. B. Audit.General, Audit.AzureActiveDirectory, Audit.Exchange, Audit.SharePoint).
  • Verdacht fiel auf indexer-connector Warnungen – die sind aber primär für IT Hygiene relevant und nicht direkt für O365.

Wichtig war hier die Trennung:

  • O365 sammelt Events → Wazuh Manager
  • Dashboard sieht Events erst, wenn sie über Filebeat im Indexer landen

Entscheidender Diagnose-Schritt: Wo “hängen” die Logs?

  1. Sind O365-Alerts im Manager vorhanden?
grep -i office365 /var/ossec/logs/alerts/alerts.json

➡️ Ergebnis: Ja, O365-Einträge waren in alerts.json vorhanden.

Damit war klar:
✅ O365-Ingestion funktioniert auf Manager-Ebene.
❌ Anzeige/Indexierung im Dashboard ist kaputt → Fokus auf Filebeat → Indexer.

  1. Filebeat Output testen
sudo filebeat test output

➡️ Ergebnis:

  • Verbindung gegen https://127.0.0.1:9200 schlug fehl (connection refused)
  • Gleichzeitig war der Indexer über https://10.0.1.4:9200 erreichbar (z. B. via curl -k)
  1. Host/Bind prüfen
nc -zv 10.0.1.4 9200
nc -zv 127.0.0.1 9200

➡️ 10.0.1.4:9200 OK, 127.0.0.1:9200 refused
Und in opensearch.yml:

  • network.host: "10.0.1.4"

Damit war klar: Indexer lauscht nicht auf localhost, sondern auf der privaten IP.

Root Cause: Zertifikat passt nicht zur IP (SAN-Mismatch)

Beim sauberen TLS-Test ohne -k kam der eigentliche Knackpunkt:

curl: (60) SSL: no alternative certificate subject name matches target host name '10.0.1.4'

Heißt: Das genutzte Zertifikat war nur für 127.0.0.1 gültig, aber Filebeat/Clients verbinden auf 10.0.1.4. Die Option ssl.verification_mode: none in filebeat.yml kaschiert das zwar teilweise, aber in der Praxis endet man trotzdem schnell in Verbindungs-/Trust-Problemen (und es ist unsauber).

Zusätzlich: Im filebeat test output tauchte zeitweise noch 127.0.0.1 auf – das deutet auf Inkonsistenz (Konfig/Reload/Servicezustand oder alte Settings), aber der zentrale Fehler blieb: TLS-Zertifikat ohne SAN für 10.0.1.4.

Lösung: Zertifikate korrekt mit SAN für 10.0.1.4 generieren und für alle Komponenten ausrollen

Da kein CA-Root-Key vorhanden war, lief es auf Neu-Generierung (Option “from scratch”) hinaus.

Wichtig: Für ein All-in-One Setup müssen im config.yml alle Rollen definiert sein (server/indexer/dashboard), selbst wenn sie auf derselben IP laufen:

nodes:
  server:
    - name: wazuh-server
      ip: 10.0.1.4
  indexer:
    - name: wazuh-indexer
      ip: 10.0.1.4
  dashboard:
    - name: wazuh-dashboard
      ip: 10.0.1.4

Danach Zertifikate neu generieren (über das Wazuh-Zertifikat-Tool aus der Doku) und die Zertifikate für alle beteiligten Komponenten aktualisieren:

  • Wazuh Indexer
  • Wazuh Dashboard
  • Filebeat
  • (ggf.) Manager/Connectoren

Wenn Dateinamen gleich bleiben, reicht meist: überschreiben + Ownership/Permissions korrigieren; sonst müssen die Pfade in Configs angepasst werden.

Verifikation nach Fix

  1. TLS-Healthcheck ohne -k:
sudo curl -u admin:<pass> \
  --cacert /etc/filebeat/certs/root-ca.pem \
  --cert   /etc/filebeat/certs/wazuh-server.pem \
  --key    /etc/filebeat/certs/wazuh-server-key.pem \
  https://10.0.1.4:9200/_cluster/health
  1. Filebeat Output:
sudo filebeat test output
  1. Filebeat Logs:
cd /var/log/filebeat
grep -iE "(error|warn|critical)" filebeat*
  1. Im Dashboard prüfen, ob O365-Events nun sichtbar sind.

Takeaways

  • Wenn alerts.json O365-Events enthält, aber im Dashboard nichts auftaucht, liegt es fast immer an Indexer/Filebeat, nicht am O365-Modul selbst.
  • In Azure/Cloud Setups ist SAN (Subject Alternative Name) bei Zertifikaten praktisch Pflicht: IP/Hostname muss exakt passen.
  • All-in-One heißt nicht “ein Zertifikat reicht”: Indexer/Dashboard/Filebeat brauchen konsistente TLS-Kette und passende Hosts.

https://wazuh.slack.com/archives/C0A933R8E/p1765293024598729