Wazuh Dashboard erstellen mit Visualize und einer klaren Sicherheitsübersicht

Wazuh sammelt nach der Einrichtung schnell mehr Daten, als ich im Alltag einzeln anschauen kann. Die verschiedenen Standardansichten sind für die Untersuchung eines Problems hilfreich. Mir fehlte jedoch eine Startseite, die sofort zeigt, wo ich zuerst hinsehen sollte.

Dafür ist die Visualize-Funktion geeignet: Dort erstellst du einzelne Darstellungen, die du anschließend in einem Dashboard zusammensetzt. Bei mir sind daraus sechs Seiten geworden. Die erste dient dem Überblick, die anderen beantworten jeweils eine konkrete Frage.

Erst die Fragen festlegen

Eine gute Übersicht beginnt für mich mit vier Fragen: Gibt es etwas Dringendes? Welche Systeme sind betroffen? Welche Daten fehlen? Funktioniert die Überwachung selbst noch?

Ich habe die Inhalte so verteilt:

Ereignisse und aktuellen Bestand auseinanderhalten

Die Datenquellen sind nicht austauschbar. wazuh-alerts-* enthält zeitbezogene Ereignisse. wazuh-states-vulnerabilities-* enthält den aktuellen Schwachstellenbestand. Wenn ich im Ereigniszeitraum die letzten 24 Stunden auswähle, darf dadurch nicht die aktuelle Zahl der Paketbefunde auf die neuen Meldungen dieses Tages schrumpfen.

Für Ereignisse lege ich ein Indexmuster mit timestamp als Zeitfeld an. Das Indexmuster für den aktuellen CVE-Bestand bekommt in meiner Übersicht keinen globalen Ereigniszeitfilter. Beim Importieren oder Erstellen musst du diese Entscheidung bewusst treffen; ein passender Zeitstempel im Dokument allein macht den Bestand noch nicht zu einer Ereignisreihe.

Auch der Agentenstatus ist ein eigener Datentyp. Meine Installation verwendet dafür regelmäßig geschriebene Statusabzüge aus der Manager-API. Eine neu installierte Standardumgebung besitzt diese zusätzliche Datenquelle noch nicht. Übernimm eine solche Statuskarte daher erst, wenn die Datenerfassung samt Zeitstempel funktioniert. Bis dahin ist die native Agentenliste die verlässliche Ansicht.

Eine erste Visualisierung in der Oberfläche erstellen

Öffne über das Menü Visualize, wähle eine neue Visualisierung und beginne mit Metric. Verwende das Ereignis-Indexmuster wazuh-alerts-* und die Anzahl der Dokumente. Setze einen Filter für rule.level >= 12 und speichere die Darstellung als „Ereignisse ab Level 12“.

Danach folgt ein horizontales Balkendiagramm mit derselben Datenquelle. Verwende die Anzahl der Dokumente als Messwert und agent.name als Aufteilung. Ein Filter ab Level 7 zeigt, welche Systeme die meisten höher bewerteten Ereignisse liefern. Prüfe die Feldnamen in deiner Umgebung; die gezeigten Felder sind in meiner Installation aggregierbar und brauchen keinen zusätzlichen .keyword-Suffix.

Wähle anschließend Dashboards, erstelle ein neues Dashboard und füge die beiden gespeicherten Visualisierungen hinzu. Ergänze ein Markdown-Panel, das den Zeitraum und die Bedeutung der Zahlen erklärt. Der Wazuh-Leitfaden für eigene Dashboards beschreibt die Werkzeuge der Oberfläche.

Wann Vega hilfreich wird

Für Standarddiagramme reichen die normalen Visualisierungen. Vega verwende ich dort, wo die Darstellung mehr Kontext braucht: beispielsweise für fest definierte Logquellen oder für einen Hinweis auf fehlende Daten.

Die folgende Vorlage ist eine kleine, eigenständige Startvorlage. In Visualize erstellst du eine Vega-Visualisierung und fügst den kompletten Inhalt ein. Sie liest nur Ereignisse aus wazuh-alerts-*, berücksichtigt den Dashboard-Zeitraum und benötigt keinen zusätzlichen Statuskollektor.

Die vollständige Vorlage:

{
  "$schema": "https://vega.github.io/schema/vega/v5.json",
  "description": "Wazuh-Ereignisse ab Level 12 im gewählten Zeitraum. Keine Aussage über bestätigte Angriffe.",
  "autosize": {"type": "fit", "contains": "padding"},
  "padding": 12,
  "data": [{
    "name": "count",
    "url": {
      "index": "wazuh-alerts-*",
      "body": {
        "size": 0,
        "track_total_hits": true,
        "query": {"bool": {
          "must": ["%dashboard_context-must_clause%"],
          "filter": [
            "%dashboard_context-filter_clause%",
            {"range": {"timestamp": {"%timefilter%": true}}},
            {"range": {"rule.level": {"gte": 12}}}
          ],
          "must_not": ["%dashboard_context-must_not_clause%"]
        }}
      }
    },
    "format": {"property": "hits.total"}
  }],
  "marks": [{
    "type": "text",
    "from": {"data": "count"},
    "encode": {"update": {
      "x": {"signal": "width/2"},
      "y": {"signal": "height/2-10"},
      "align": {"value": "center"},
      "baseline": {"value": "middle"},
      "fontSize": {"value": 40},
      "fontWeight": {"value": "bold"},
      "fill": {"value": "#CF314B"},
      "text": {"signal": "format(datum.value, ',d')"}
    }}
  }, {
    "type": "text",
    "encode": {"update": {
      "x": {"signal": "width/2"},
      "y": {"signal": "height/2+28"},
      "align": {"value": "center"},
      "fontSize": {"value": 13},
      "fill": {"value": "#64748B"},
      "text": {"value": "Ereignisse ab Level 12 · gewählter Zeitraum"}
    }}
  }]
}

Die Prozent-Ausdrücke ersetzt OpenSearch Dashboards zur Laufzeit. Du kannst die Abfrage daher nicht unverändert als normale Indexer-Abfrage absenden. track_total_hits sorgt dafür, damit größere Trefferzahlen nicht bei 10.000 abgeschnitten werden. Vega in OpenSearch Dashboards

Details erst auf der zweiten Ebene

Auf der Zugriffsseite möchte ich betroffene Systeme, Quellen und Regeln vergleichen. Die vollständige Meldung gehört in die Detailansicht, nicht in jede Kachel der Startseite. Bekannte erfolgreiche Monitoring-Abfragen können dort viel Rauschen erzeugen. Ich behandle bei mir nur genau abgegrenzte erfolgreiche Abfragen einer bekannten Quelle als Routine; andere Quellen, Fehlercodes und ungewöhnliche Ziele bleiben sichtbar.

Die Schwachstellenseite zeigt Paketbefunde, keine bestätigten Angriffe und keine Zahl eindeutiger CVEs. Eine CVE kann mehrere Pakete betreffen. „Noch in Bewertung“ bedeutet unbekannt. Wie man diese Befunde bearbeitet, erkläre ich im Schwachstellen-Artikel.

Bei SCA zeige ich den Policy-Namen neben dem Ergebnis. Ein eigenes Profil mit 14 Prüfungen kann sonst genauso beeindruckend aussehen wie ein umfangreiches CIS-Profil, obwohl beide etwas anderes messen.

Fehlende Daten müssen sichtbar bleiben

Jede Logquelle bekommt bei mir eine eigene Karte mit dem letzten Eingang. Liefert eine Quelle keine Logs, steht das ausdrücklich dort, zusammen mit dem Hinweis, dass fehlende Logs keine Aussage über die Geräteverfügbarkeit erlauben. Die prüfe ich parallel in Zabbix.

Auch die Betriebsseite gehört zur Sicherheitsübersicht. Hier will ich sehen, ob Datenerfassung, Benachrichtigung und Backups funktionieren. Bei Abdeckung unterscheide ich zwischen „Daten vorhanden“ und „Betriebssystem offiziell unterstützt“. Ein vorhandener CVE-Datensatz ist kein Beleg für vollständige Erkennung auf einer noch nicht aufgeführten Betriebssystemversion.

Mein täglicher Ablauf

Ich öffne die Sicherheitslage, schaue auf höher bewertete Ereignisse und prüfe die betroffenen Systeme. Danach kontrolliere ich Änderungen beim aktuellen Paketbestand. Für einen auffälligen Treffer öffne ich die Detailansicht mit Regel, Zeitstempel und Originalmeldung.

Die automatische Aktualisierung steht bei mir auf 60 Sekunden. Das bedeutet nicht, dass alle dahinterliegenden Daten jede Minute erhoben werden. Statusabzüge und Inventardaten haben ihre eigenen Intervalle; die angezeigte Aktualität muss zur jeweiligen Datenquelle passen.

Ein Dashboard ersetzt keine Benachrichtigung. Damit wichtige Ereignisse auch ohne offenen Browser auffallen, folgt die Telegram-Einrichtung.