Skip to main content

02.1 Wazuh Grundkonfiguration

Einleitung

Nach der Installation läuft Wazuh – aber damit ist es noch lange nicht fertig. Jetzt kommt der Teil, der später darüber entscheidet, ob die Kiste wirklich hilft oder einfach nur sehr viele bunte Meldungen produziert.

Ich gehe dabei lieber in Ruhe von außen nach innen vor: erst das Betriebssystem und die Zugriffe, dann die Datenquellen und ganz zum Schluss die Alarme. Sonst hat man sehr schnell tausende Events und noch keine Idee, wer sie eigentlich lesen oder wie lange man sie behalten soll.

Diese Seite bleibt dabei die Übersicht und der grobe Leitfaden. Die konkrete Umsetzung mit Kommandos, Konfigurationsbeispielen und Prüfungen steht auf der nächsten Seite: 02.2 Wazuh Grundkonfiguration – technische Umsetzung.

1. Erst mal gucken, was da ist

Auch bei einer frischen Installation lohnt sich eine kleine Bestandsaufnahme:

  • Wazuh-Versionen von Server, Indexer und Dashboard;
  • Betriebssystem, Kernel, CPU, RAM und Dateisysteme;
  • FQDN, IP-Adressen, DNS, Gateway und NTP-Quellen;
  • Dienstzustände und konfigurierte Autostarts;
  • Zertifikate einschließlich Aussteller, SANs und Ablaufdatum;
  • offene Ports und erlaubte Quellnetze;
  • Benutzer, Rollen, technische Konten und Secret-Ablage;
  • Indexgröße, freie Kapazität und Aufbewahrung;
  • Backupziel, Häufigkeit und letzter Restore-Test.

Das klingt größer, als es ist. Im Zweifel reicht am Anfang eine saubere Markdown-Seite. Wichtig ist nur, Änderungen später noch nachvollziehen und bei Bedarf zurückrollen zu können.

2. Das Betriebssystem nicht vergessen

Für einen dedizierten Wazuh-Server gilt:

  • Minimalinstallation ohne unnötige grafische oder administrative Webdienste;
  • vollständiger Patchstand vor der Wazuh-Installation;
  • SSH nur mit individuellen Schlüsseln und ohne direkten Root-Login;
  • sudo nach Least Privilege; allgemeines NOPASSWD: ALL vermeiden;
  • Hostfirewall mit expliziten Quellnetzen;
  • SELinux oder vergleichbare Mandatory Access Control aktiviert lassen;
  • persistentes Journald mit Größen- und Zeitbegrenzung;
  • Core Dumps, Debugschnittstellen und ungenutzte Dienste prüfen;
  • Dateisysteme, Inodes und Logwachstum überwachen.

Automatische Betriebssystemupdates sind nicht identisch mit automatischen Wazuh-Komponentenupdates. Zentrale Wazuh-Pakete sollten gemeinsam, getestet und mit Backup aktualisiert werden.

3. Zeit, Namen und Zertifikate

Wazuh lebt von Zeitstempeln. Wenn Server und Agents unterschiedliche Uhren haben, werden Zertifikate, Korrelationen und die spätere Fehlersuche unnötig lustig. Deshalb mindestens zwei Zeitquellen konfigurieren und, wenn möglich, NTS verwenden.

Für Zertifikate gilt:

  • jeder Dienst verwendet den Namen, der im Zertifikat als SAN enthalten ist;
  • private Schlüssel sind nur für den jeweiligen Dienst lesbar;
  • Ablaufdaten werden überwacht;
  • eine interne CA wird auf den administrativen Clients als vertrauenswürdig verteilt;
  • ein Reverse Proxy ersetzt nicht die TLS-Absicherung der internen Komponentenkommunikation;
  • selbstsignierte Installationszertifikate werden bewusst akzeptiert oder kontrolliert durch die eigene PKI ersetzt.

4. Nur die Türen öffnen, die ich wirklich brauche

Die Firewall richtet sich nach dem echten Datenfluss:

Quelle Ziel Port Zweck
Agents Wazuh Server 1514/TCP laufende Agentenkommunikation
Agents Wazuh Server 1515/TCP Enrollment, wenn verwendet
Dashboard Wazuh Server 55000/TCP Server-API
Wazuh Server/Filebeat Indexer 9200/TCP TLS-gesicherte Datenübergabe
Administratoren/Reverse Proxy Dashboard 443/TCP Weboberfläche
Cluster-Nodes Cluster-Nodes 1516 bzw. 9300–9400/TCP nur bei Clustern

Nicht benötigte UDP-Varianten, Syslog-Port 514 und Clusterports bleiben geschlossen. API- und Indexerports werden nicht direkt in Client-, Gast- oder IoT-Netze veröffentlicht.

5. Wohin mit Passwörtern und Dienstkonten?

Die Installation erzeugt mehrere voneinander unabhängige Identitäten. Sie dürfen nicht zu einem gemeinsamen „Wazuh-Passwort“ zusammengefasst werden.

Empfohlene Trennung:

  • persönliches Administratorkonto;
  • persönliches Read-only-Konto;
  • technisches Reporting-Konto mit minimalen Rechten;
  • API-Konto für kontrollierte Automatisierung;
  • Indexer-Admin nur für seltene Wartungsaufgaben;
  • Enrollment-Geheimnis oder Zertifikate für Agenten.

Passwörter, API-Token und private Schlüssel liegen ausschließlich in einem verschlüsselten Secret-Store. Beispielkonfigurationen im Git-Repository enthalten nur Platzhalter. Secrets gehören weder in Wiki-Seiten noch in Screenshots, Shell-Historien oder Supportausgaben.

6. Wer darf eigentlich was?

Das initiale admin-Konto ist ein Bootstrap- und Notfallkonto, kein persönliches Tageskonto. Danach:

  1. persönliche Konten anlegen;
  2. administrative und lesende Rollen trennen;
  3. technische Konten auf benötigte API-Aktionen und Agentengruppen begrenzen;
  4. Anmeldung und fehlgeschlagene Anmeldeversuche überwachen;
  5. Berechtigungen mit einem Read-only-Konto praktisch testen;
  6. Notfallzugang offline dokumentieren und regelmäßig prüfen.

Wenn das Dashboard hinter einem Reverse Proxy liegt, muss der Proxy WebSockets, Header und Uploadgrößen passend behandeln. Nur der Proxy ist aus dem Administrationsnetz erreichbar; der native Dashboard-Port bleibt intern.

7. Agents sauber anmelden

Für kleine, vollständig kontrollierte Netze kann ein gemeinsames, starkes Enrollment-Passwort ausreichend sein. Zusätzliche Zertifikatsprüfung oder eine restriktivere Enrollment-Strecke wird spätestens erforderlich bei:

  • fremden oder nicht vollständig kontrollierten Clients;
  • Zugriff aus Gast-, IoT-, Test- oder externen Netzen;
  • mehreren Administratoren oder automatischer Massenregistrierung;
  • unbekannten, doppelten oder wiederholten Enrollment-Versuchen.

Grundregeln:

  • eindeutige, stabile Agentennamen verwenden;
  • Altobjekte kontrolliert entfernen statt blind force_reenroll einzusetzen;
  • Port 1515 nur aus vorgesehenen Netzen zulassen;
  • neue Agents zuerst in einer Pilotgruppe aufnehmen;
  • Agentversion und Gruppensynchronisation nach der Anmeldung prüfen.

8. Ordnung mit Agentengruppen

Mit zentralen agent.conf-Dateien muss man nicht auf jedem Endpoint dieselben Änderungen von Hand wiederholen. Für den Anfang funktioniert diese additive Struktur gut:

Gruppe Inhalt
default sichere, für alle Agents geeignete Basis
os-linux, os-windows betriebssystemspezifische Erfassung und SCA
role-docker Docker-Ereignisse und relevante Konfigurationspfade
role-reverse-proxy Proxy- und Zugriffslogs
role-database Datenbanklogs und Integritätsprüfungen
role-critical strengere Überwachung besonders wichtiger Systeme

Konfigurationen werden zuerst als temporäre Datei bereitgestellt, mit verify-agent-conf validiert und erst danach produktiv umbenannt. Nach jeder Änderung muss der Agent group_config_status: synced melden.

Bei Logquellen gilt: erst klein anfangen. Ein pauschales Journald oder jede Container-JSON-Datei kann die Queue und den Indexer stärker belasten als alle anderen Agents zusammen. Auch das habe ich inzwischen praktisch getestet :D

9. Welche Wazuh-Funktionen zuerst?

Nicht alles muss am ersten Abend eingeschaltet werden. Diese Funktionen sind ein sinnvoller Startpunkt:

  • Syscollector: Betriebssystem, Pakete, Ports, Prozesse und Hardware;
  • Vulnerability Detection: Abgleich inventarisierter Software gegen Wazuh CTI;
  • SCA: Sicherheitskonfigurationsprüfungen passend zum Betriebssystem;
  • FIM/Syscheck: kritische Konfigurationspfade, nicht pauschal ganze Dateisysteme;
  • Rootcheck: ergänzende Prüfungen auf verdächtige Artefakte;
  • Logcollector: gezielte System-, Authentifizierungs- und Anwendungslogs;
  • Docker Listener: nur auf echten Docker-Hosts und mit bewusstem Umgang mit dem privilegierten Docker-Socket.

Jede Quelle beginnt mit kleiner, nachvollziehbarer Abdeckung. Datenvolumen und Fehlalarme werden gemessen, bevor die nächste Quelle hinzukommt.

10. Damit nicht irgendwann die Platte voll ist

Ein paar Entscheidungen sollte man treffen, bevor der Indexer sie durch Platzmangel erzwingt:

  • wie lange Alerts online durchsuchbar bleiben;
  • ob Compliance- oder Forensikdaten länger archiviert werden;
  • wann Indizes gerollt, geschlossen oder gelöscht werden;
  • welche Reserve vor Index-Merges und Updates erforderlich ist;
  • welche Schwellen Warnung und kritischen Alarm auslösen.

Mindestens überwachen:

  • Belegung und Inodes aller Wazuh-Dateisysteme;
  • Indexer-Clusterzustand und Shard-Zuweisung;
  • JVM-Heap und Speicherdruck;
  • Agentqueues sowie Managerqueues;
  • events_dropped in wazuh-analysisd.state;
  • discarded_count in wazuh-remoted.state;
  • tägliches Indexwachstum und ungewöhnliche Top-Quellen.

events_dropped und discarded_count sollen null bleiben. Ein größerer Datenträger allein behebt keine ungefilterte Logquelle.

11. Alarme, die man auch noch lesen möchte

Eine praxistaugliche Baseline unterscheidet:

Stufe Beispiel Kanal
Information einzelner Loginfehler, Agent wieder verbunden Dashboard
Handlungsbedarf wiederholte Loginfehler, Container unhealthy, Patchrückstand Mail oder Ticketsystem
Kritisch Datenverlust, volle Dateisysteme, ausgefallene Überwachung Mail plus Sofortkanal

Alarme brauchen ein ignore- oder Korrelationsfenster, damit eine einzige Fehlerschleife nicht hunderte Mails erzeugt. Einfach stummschalten ist trotzdem selten die beste Lösung: Erst gucken, warum die Quelle so laut ist, dann Filter und Puffer passend einstellen.

Vor produktivem Versand werden Regeln mit wazuh-logtest und einem kontrollierten Ende-zu-Ende-Ereignis geprüft. Externe Nachrichten enthalten keine vollständigen Logzeilen, Tokens, Benutzernamen oder andere unnötige personenbezogene Daten.

12. Backup – und bitte auch mal zurückspielen

Mindestens sichern:

  • Managerkonfiguration, eigene Decoder und Regeln;
  • zentrale Agentengruppen;
  • Zertifikate und deren Wiederbeschaffungsweg;
  • RBAC- und Dashboard-Konfiguration;
  • dokumentierte, verschlüsselte Secrets;
  • Indexer-Snapshots, wenn die Alert-Historie wiederherstellbar sein muss.

VM-Snapshots allein sind bei einem laufenden Indexer kein vollständiges Wiederherstellungskonzept. Für kleine Umgebungen kann ein dokumentierter Neuaufbau plus Konfigurationsrestore wirtschaftlicher sein als die Sicherung aller historischen Alerts. Diese Entscheidung muss bewusst getroffen und getestet werden.

13. Zum Schluss einmal abhaken

  • DNS, Zeit und TLS sind fehlerfrei.
  • Hostfirewall erlaubt nur dokumentierte Flows.
  • Persönliches Admin- und Read-only-Konto wurden getestet.
  • Secrets liegen verschlüsselt außerhalb des Wikis und Git-Arbeitsbaums.
  • Ein Test-Agent ist aktiv, eindeutig benannt und synchronisiert.
  • Syscollector, Vulnerability Detection, SCA und gezielte Logs liefern plausible Daten.
  • Queue-, Indexer- und Dateisystemüberwachung sind aktiv.
  • Mindestens ein Warn- und ein kritischer Alarm wurden Ende-zu-Ende getestet.
  • Backup und Restore-Verantwortung sind dokumentiert.
  • Paketupdates erfolgen kontrolliert und komponentenübergreifend.

Weiterlesen

Zuletzt aktualisiert am 18.08.2026 · 3 Aufrufe

No comments to display

Back to top
Entity Select