Wazuh Agent auf Ubuntu und Debian installieren und prüfen

Der Manager läuft, das Dashboard ist erreichbar. Jetzt braucht Wazuh Daten von den Rechnern, die es überwachen soll. Dafür installiere ich auf Ubuntu und Debian den Wazuh Agent. Er meldet unter anderem Sicherheitsereignisse, Paketinformationen und Ergebnisse der Konfigurationsprüfung an den Manager.

In meiner Umgebung laufen zwölf Linux-Agenten. Trotzdem prüfe ich drei Dinge getrennt: Ist der Agent verbunden? Liefert er die erwarteten Daten? Unterstützt Wazuh die eingesetzte Betriebssystemversion für die betreffende Funktion? Ein grüner Verbindungsstatus beantwortet nur die erste Frage.

Vor dem Download

Vom überwachten Rechner muss der Manager erreichbar sein. In dieser Serie verwenden wir TCP 1514 für die Datenverbindung und TCP 1515 für die Registrierung. Der Browserport des Dashboards ist kein Agentenport.

Ich nutze einen privaten Netzwerkpfad beziehungsweise das VPN. Prüfe bei Problemen vom Agenten aus zum Beispiel:

nc -vz wazuh.example.internal 1514
nc -vz wazuh.example.internal 1515

wazuh.example.internal steht für deinen Manager. Der Name muss auf dem Agenten auflösbar sein. Die Registrierung muss zum gewählten Manager-Verfahren passen; bei aktiviertem Registrierungspasswort gehört dieses zum Installationsvorgang.

Signiertes Repository hinzufügen

Die folgenden Befehle sind für aktuelle Debian- und Ubuntu-Systeme mit APT gedacht:

sudo apt update
sudo apt install curl gnupg ca-certificates
curl -fsSL https://packages.wazuh.com/key/GPG-KEY-WAZUH \
  -o /tmp/wazuh-package-key.asc
sudo gpg --dearmor --yes -o /usr/share/keyrings/wazuh.gpg \
  /tmp/wazuh-package-key.asc
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo 'deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main' \
  | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update
apt-cache policy wazuh-agent

Die Paketquelle und der zugehörige Signaturschlüssel sind in der offiziellen Linux-Agent-Anleitung dokumentiert. Den Schlüssel solltest du über den offiziellen Kanal beziehen und vor der Nutzung nach deinen üblichen Vertrauensregeln prüfen.

Agentenname und Version festlegen

Ein aussagekräftiger Name erleichtert später die Auswertung. Ich verwende beispielsweise Namen für Mail-, Web- und Backup-Systeme. Vermeide doppelte Namen und wechselnde Namen bei jedem Installationsversuch.

Für diese Serie hat der Manager Version 4.14.8. Ich installiere dazu passend den Agenten und lese das Registrierungspasswort verdeckt ein:

read -rsp 'Registrierungspasswort: ' enrollment_secret
printf '\n'
sudo env WAZUH_MANAGER='wazuh.example.internal' \
  WAZUH_AGENT_NAME='web-demo' \
  WAZUH_REGISTRATION_PASSWORD="$enrollment_secret" \
  apt-get install wazuh-agent=4.14.8-1
unset enrollment_secret
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

Damit steht das Passwort nicht als wörtlicher Befehl in der Shell-History. Während der Installation können privilegierte lokale Prozesse weiterhin Umgebungswerte sehen. Nutze also keinen unsicheren Mehrbenutzerrechner zum Verteilen deiner Geheimnisse. Wenn dein Manager kein Registrierungspasswort verwendet, entfällt genau diese Variable; die Manager-Konfiguration entscheidet darüber. Deployment-Variablen

Der Manager sollte mindestens die Agentenversion unterstützen. Plane spätere Agentenupdates gemeinsam mit den Serverupdates und lasse das Agenten-Repository nicht ungeprüft einer neueren Hauptversion folgen.

Verbindung und Daten prüfen

systemctl is-active wazuh-agent
sudo tail -n 80 /var/ossec/logs/ossec.log

Im Dashboard muss der neue Agent als aktiv erscheinen. Anschließend schaue ich nach Paketinventar und SCA-Bericht. Diese Daten müssen nicht in derselben Sekunde vorhanden sein; die Module arbeiten mit ihren eigenen Intervallen.

Für einen einfachen Logtest erzeuge ich eine harmlose Markierung:

logger -t wazuh-serie 'WAZUH_SERIE_LOGTEST'

Der Test ist nur aussagekräftig, wenn Wazuh den betreffenden Syslog- oder Journal-Eingang tatsächlich liest. Die Markierung erzeugt außerdem nicht zwangsläufig einen Alert: Eine passende Regel muss sie bewerten, und rohe Archive müssen für eine Suche in Rohdaten gesondert eingerichtet sein. Prüfe zuerst den lokalen Logeintrag, danach die Sammlung und schließlich die Regel. Das verhindert, dass „nicht in der Alertsuche“ vorschnell als „Agent kaputt“ interpretiert wird.

Gruppen ordnen die spätere Einrichtung

Ich lasse alle Agenten in der Gruppe default und ergänze eine gemeinsame Linux-Basis sowie Rollen für Web, Mail, Datenbank und Backup. So kann ich Einstellungen für eine Gruppe zentral verwalten, ohne jeden Rechner gleich zu behandeln.

Eine Webserver-Gruppe kann beispielsweise zusätzliche Logpfade erhalten. Das bedeutet aber nicht, dass nach ihrer Erstellung sofort alle Anwendungslogs vorhanden sind. Bei nginx, einer Datenbank oder einem Maildienst muss der konkrete Pfad beziehungsweise Journal-Eingang passend eingerichtet werden.

Beginne mit einem Testrechner und einer kleinen Änderung. Prüfe die Gruppensynchronisierung, bevor du dieselbe Konfiguration auf alle produktiven Agenten verteilst.

Aktiver Agent bedeutet nicht vollständige Schwachstellenerkennung

Bei meinen Ubuntu-26-Systemen laufen die Agenten und liefern Daten. Die am 14. Oktober 2026 veröffentlichte Wazuh-Kompatibilitätsmatrix für Vulnerability Detection nennt Ubuntu 26.04 jedoch noch nicht. Auch vorhandene Paketbefunde machen daraus keine offiziell bestätigte vollständige Abdeckung. Kompatibilitätsmatrix

Das ist ein guter Grund, die Betriebssystemversion neben den Prüfergebnissen anzuzeigen. Im SCA-Artikel zeige ich außerdem, wie ich eigene Prüfungen von vollständigen CIS-Profilen unterscheide. Als Nächstes bauen wir die Dashboard-Übersicht.