O365-Integration läuft, aber im Wazuh Dashboard „keine Logs“: Wenn Filebeat am Indexer scheitert (SAN/Host-Mismatch)

von

TL;DR

Wenn das Office365-Modul sauber startet und du O365-Events in alerts.json findest, aber im Dashboard nichts siehst, ist die Integration meist nicht das Problem – sondern der Transport in den Indexer (typisch: Filebeat → Indexer). In diesem Fall war die Ursache ein TLS-Zertifikat ohne passenden SAN für die private IP (10.0.1.4): Das Zertifikat war nur für 127.0.0.1 gültig.

Ausgangslage

Alok Shukla betreibt Wazuh v4.14.1 (All-in-One: Manager, Indexer, Dashboard auf derselben Azure VM) und nutzt die Office365-Integration.

Im ossec.log sieht er:

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

Trotzdem: keine O365-Logs im Dashboard, obwohl Unified Audit Log (UAL) aktiviert ist und Subscriptions gesetzt sind.

Symptome und was sie bedeuten

1) O365-Modul läuft – aber Dashboard bleibt leer

Wichtiger Check: Sind Events am Manager vorhanden?

  • Alok bestätigt: alerts.json enthält O365-Logs.

Damit ist klar: Office365-Modul zieht Daten und der Manager erzeugt Alerts.

2) Verwirrende Warnungen: IndexerConnector

Parallel tauchen Warnings auf wie:

  • indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-...'

Ein Community-Mitglied ordnet korrekt ein:
Das betrifft eher IT Hygiene/States/Inventory und ist nicht automatisch der Grund, warum O365 nicht im Dashboard erscheint.

Die entscheidende Frage lautet stattdessen:
Schafft Filebeat die Alerts in den Indexer?

Der Durchbruch: Filebeat kann nicht zum Indexer verbinden

Filebeat Connectivity Test

sudo filebeat test output

Ergebnis:

  • dial tcp 127.0.0.1:9200: connect: connection refused

Und in /var/log/filebeat/filebeat*:

  • Failed to connect to backoff(elasticsearch(https://127.0.0.1:9200)) ... connection refused

Filebeat kann den Indexer-Endpunkt nicht erreichen (oder versucht den falschen).

Indexer läuft aber grundsätzlich

Indexer ist über die private IP erreichbar:

curl -k -u user:pwd https://10.0.1.4:9200/_cat/indices?v

Indexer läuft, Indizes sind green.

Root Cause: Zertifikat passt nicht zum Host (SAN fehlt)

Ein sauberer TLS-Test (ohne -k) liefert die eigentliche Ursache:

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 \
  -X GET "https://10.0.1.4:9200/_cluster/health"

Fehler:

  • SSL: no alternative certificate subject name matches target host name '10.0.1.4'
  • (sinngemäß) Zertifikat ist für 127.0.0.1, nicht für 10.0.1.4

Zusätzlich bestätigt das Netz-/Bind-Verhalten:

  • nc -zv 127.0.0.1 9200 → refused
  • nc -zv 10.0.1.4 9200 → success
  • network.host: "10.0.1.4" (Indexer bindet auf private IP)

Der Indexer hört auf 10.0.1.4, aber die Zertifikate enthalten keinen Subject Alternative Name (SAN) für diese IP.
Das führt zu TLS-Handshake-Abbruch und verhindert, dass Filebeat die Alerts indexiert.

Hinweis: ssl.verification_mode: none kann Symptome kaschieren, behebt aber die eigentliche Inkonsistenz nicht sauber (und ist sicherheitstechnisch unschön).

Lösung: Zertifikate neu generieren – mit korrektem SAN für 10.0.1.4

Da es ein All-in-One-Setup ist, müssen Zertifikate für server + indexer + dashboard konsistent erzeugt werden. Entscheidend ist die config.yml für das Wazuh Cert Tool (inkl. IP/DNS, die später auch wirklich genutzt werden).

Beispiel config.yml:

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

Dann:

  1. Zertifikate neu generieren (mit Wazuh-Certs-Tool gemäß Doku).
  2. Certs an die richtigen Orte ausrollen/überschreiben (Indexer, Dashboard, Filebeat).
  3. Ownership/Permissions korrekt setzen.
  4. Services neu starten (Indexer, Filebeat, ggf. Dashboard/Manager).
  5. TLS-Tests wiederholen (curl ohne -k), anschließend filebeat test output.

Am Ende bestätigt der Threadersteller: Problem gelöst.

Minimal-Checkliste für ähnliche Fälle

A) Ist O365 wirklich da?

grep -i office365 /var/ossec/logs/alerts/alerts.json | tail

Wenn hier Treffer sind, ist O365 ok.

B) Filebeat → Indexer prüfen

sudo filebeat test output
cd /var/log/filebeat && grep -iE "(error|warn|critical)" filebeat*

C) Indexer bindet worauf?

sudo grep -i "network.host" /etc/wazuh-indexer/opensearch.yml
nc -zv 10.0.1.4 9200
nc -zv 127.0.0.1 9200

D) TLS sauber testen (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 \
  -X GET "https://10.0.1.4:9200/_cluster/health"

Wenn hier SAN-/Hostname-Fehler kommen → Zertifikate neu mit korrektem SAN.

Lessons Learned

  • „O365 startet“ ≠ „Dashboard zeigt Logs“. Erst prüfen, ob Events im Manager ankommen (alerts.json).
  • Wenn alerts.json O365 hat und Dashboard leer ist, ist fast immer Indexer/Filebeat das Bottleneck.
  • SAN muss zur echten IP/DNS passen, die du in Filebeat/Manager/Indexer verwendest – sonst bricht TLS korrekt ab.
  • ssl.verification_mode: none ist ein Notbehelf; sauber ist ein Zertifikat mit richtigen SANs.