WAZUH – ein SIEM (Überwachungs- und Sicherheitslösung) für dein Netzwerk

Das kennst du sicher: Irgendwann hast du Software installiert, sie lange nicht genutzt und im Grunde schon vergessen. Da du nicht ständig IT-Sicherheitsblogs verfolgst, entgeht dir, dass Anbieter XY mal wieder durch gravierende Sicherheitsmängel aufgefallen ist. Letztendlich bist du davon betroffen, weil dessen Softwareprodukt auch bei dir installiert ist. Die CVE-Datenbank dokumentiert Sicherheitslücken – aber wenn du davon keine Kenntnis hast …

Großartig wäre es, wenn es etwas gäbe, das deine Systeme regelmäßig überprüft, die Daten korreliert und gegen die CVE-Datenbank laufen lässt und dich darüber informiert, dass du tätig werden musst. Die gute Nachricht: Das gibt es. SIEM-Lösungen gibt es viele – von Open Source bis rein kommerziell ohne Einsicht in den Quellcode. Aber was, wenn ich dir sage, dass es das nicht nur Open Source, sondern auch kostenlos gibt? Quasi das Sicherheitsinformations- und Ereignismanagement (SIEM) für deine eigene Netzwerkumgebung.

Ich nutze WAZUH schon länger und finde es als Open-Source-Lösung großartig, um die eigenen Server und Clients im Netzwerk auf Schwachstellen, Sicherheitslücken und Auffälligkeiten zu überwachen. Dabei ist es nahezu unerheblich, welches Betriebssystem die Endgeräte haben, denn es gibt für fast alles einen passenden Agenten

Grundsätzlich zeige ich dir hier den Weg für eine Single-Node-Installation. WAZUH selbst besteht nämlich aus mehreren Komponenten: dem Server, dem Indexer, dem Dashboard und den Agenten. Darüber hinaus kannst du Wazuh beliebig skalieren, also mehrere Server und mehrere Indexer nutzen.

Schauen wir uns zunächst die einzelnen Komponenten an:

Auf allen Endpoints laufen sogenannte Wazuh Agents, die auf den Clients und Servern sämtliche Daten (Logs, installierte Programme, Dateien etc.) einsammeln und an die Worker Nodes liefern. Dort werden die Daten in mehreren Stufen ausgewertet, kategorisiert und dann einem Indexer zugeführt, der sie relativ sparsam in einer Datenbank sichert. Wenn diese voll ist, überschreibt der neueste Eintrag immer den ältesten. Das Dashboard dient der Interaktion mit dem Wazuh-Nutzer und stellt sozusagen das grafische Frontend dar.

Installation

WAZUH empfiehlt folgende Voraussetzungen für die Installation:

Agents	CPU	RAM	Storage (90 Tage)
1-25	4 vCPU	8 GiB	50 GB
25-50	8 vCPU	8 GiB	100 GB
50-100	8 vCPU	8 GiB	200 GB

Variante 1 – Proxmox-Helper-Scripts

Unter Proxmox ist die Installation inzwischen sehr einfach. Du kannst die Proxmox-Helper-Scripts nutzen, um einen neuen Container mit installiertem WAZUH zu erstellen. Öffne dazu eine Shell direkt auf deinem Proxmox-Server und gib das folgende Kommando ein:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/wazuh.sh)"

Die Anmeldedaten für WAZUH findest du im Anschluss mit:

cat ~/wazuh.creds

Variante 2 – der Standard-Weg

Du kannst aber auch den Weg gehen, den die Entwickler auf ihrer Homepage beschreiben. Das heißt, du erstellst einen neuen LXC-Container mit den erforderlichen Voraussetzungen (siehe oben), startest und aktualisierst diesen und führst dann in der Shell das folgende Kommando aus:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

Am Ende der Installation werden deine generierten WAZUH-Anmeldedaten in der Installationsausgabe angezeigt.

INFO: --- Summary ---
INFO: You can access the web interface https://<WAZUH_DASHBOARD_IP_ADDRESS>
    User: admin
    Password: <ADMIN_PASSWORD>
INFO: Installation finished.

Öffne einen Browser und rufe http:// auf. Mit den oben genannten Credentials gelangst du auf die Startseite.

Das war es auch schon mit der Installation des WAZUH-Servers. Vergiss aber nicht, deinen WAZUH-Server ggf. hinter einen Reverse-Proxy zu hängen, damit du bei Bedarf auch aus dem Internet darauf zugreifen kannst. Wenn du das vorhast, solltest du auch die Ports 1514 (TCP, optional UDP) für die Agentenverbindung zum Server und 1515 (TCP) für das Enrollment der Agenten auf deinen WAZUH-Server forwarden.

Endpoint-Konfiguration mittels Agents

Wenn du im Dashboard oben links auf „Deploy new agent” klickst, wirst du durch die Einrichtung der Agents geführt.

Zunächst wählst du das Zielbetriebssystem aus. Du siehst, dass es bei diesem Assistenten in erster Linie um Standard-Systeme geht. Ich wähle hier exemplarisch Windows aus, um einen Agenten auf meinem Windows-PC zu installieren.

Als Zweites gibst du die IP-Adresse oder den FQDN deines WAZUH-Servers an, an den der Agent später seine Daten senden soll. Im Homelab reicht die IP-Adresse, wenn du jedoch auch externe Server wie z. B. deinen VPS im Internet überwachen willst, ist ein FQDN essenziell.

Als Drittes, wenn auch optional, gibst du einen Agentennamen an, zum Beispiel den Hostnamen des Clients/Servers. Wenn du das nicht machst, nimmt der Agent später automatisch den Hostnamen. Außerdem kannst du deine Clients gruppieren, zum Beispiel nach Linux, Windows etc. Gruppen kannst du über das Burgermenü oben links > Agents Management > Groups einrichten.

Unter den Punkten vier bis fünf siehst du jetzt die Schritte, die du auf dem Client/Server ausführen musst.

Dazu öffnest du eine administrative PowerShell (hier unter Windows) auf dem Zielrechner und gibst die beiden Kommandos ein.

Klicke im Dashboard auf „Back to agent list“ (Schritt 6), um den neuen Client sofort zu sehen.

Bei Linux-Clients ist das nicht viel anders: Auch dort werden im Dashboard zwei Kommandozeilen generiert. Eine lädt den Agent herunter und installiert ihn mit den eingestellten Parametern (Server-IP, Hostname, Gruppen etc.). Die andere startet den Systemdienst WAZUH.

Über das Auge am Ende der Zeile eines jeweiligen Eintrags gelangst du zur Detailansicht des Clients. Sei geduldig, das Sammeln der Daten dauert eine Weile und wird dann später periodisch durch den Agenten durchgeführt und an den Server gemeldet.

Und was fange ich mit der Information jetzt an?

Erstens siehst du an meinem Beispiel, dass es offenbar zwei kritische und zwei als hohes Risiko eingestufte Sicherheitsvorfälle gibt. Beide hängen mit dem Microsoft ASP.NET Core 8.0.14 Shared Framework (x86) zusammen. Das kannst du mit einem Klick auf „Vulnerability Detection” näher betrachten.

Es gibt also zwei CVEs, die mein System aktuell betreffen. Dazu muss erwähnt werden, dass ich dieses Windows-11-System erst vor wenigen Tagen frisch installiert und gestern einige Anwendungen installiert habe. Über „Einstellungen“ > „Apps“ > „Installierte Apps“ konnte ich herausfinden, dass ASP.NET erst gestern installiert wurde. Da ich das wissentlich nicht installiert habe, muss es durch die Installation eines anderen Programms mitinstalliert worden sein. Leider war die Liste ein wenig zu lang: ein alternativer Messenger, ein Browser und ein Mail-Programm sowie MS Office 2024 – im Grunde dieselbe Software wie auf meinen anderen Rechnern (außer Office 2024; da bin ich von der Version 2019 auf die Version 2024 umgestiegen).

Leider zeigt Windows keine Uhrzeiten an, sodass ich die verantwortliche Software nicht ermitteln konnte. Angesichts eines Scores von 9,9/10 habe ich mich entschieden, ASP.net vorerst zu deinstallieren. Alternativ hätte ich auch die von Microsoft angebotenen Patches installieren können, aber ich hatte gehofft, später herauszufinden, welche Software ggf. Probleme verursacht, weil ASP.net fehlt.

Keine Stunde später waren die gefundenen Schwachstellen auch in der Wazuh-Übersicht wieder als „gelöst“ markiert (und ich habe ein besseres Gefühl).

Alarmierung per Mail

Was nützt das beste SIEM, wenn man nicht ständig ein Auge darauf hat? So wie ich mir täglich eine E-Mail von Logwatch von meinem Server im Internet zusenden lasse, möchte ich auch von Wazuh eine Meldung erhalten, wenn etwas Relevantes passiert.

Installieren wir also zunächst die notwendigen Pakete auf dem Wazuh-Server.

sudo apt update && sudo apt install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

Sollte sich der Postfix-Installationsassistent, quittierst du das mit „Keine Konfiguration“, denn das erledigen wir gleich manuell in dem wir die Datei mittels sudo /etc/postfix/main.cf bearbeiten. Füge folgende Zeilen der ggf. bereits vorhandenen Datei hinzu:

sudo nanao /etc/postfix/main.cf

relayhost = [smtp.mailserver.com]:587  
mynetworks = 127.0.0.0/8  
inet_interfaces = loopback-only  
smtp_use_tls = yes  
smtp_always_send_ehlo = yes  
smtp_sasl_auth_enable = yes  
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd  
smtp_sasl_security_options = noanonymous  
smtp_sasl_tls_security_options = noanonymous  
smtp_tls_security_level = encrypt  
smtp_generic_maps = hash:/etc/postfix/generic  
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt  
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Danach müssen wir die Anmeldedaten für unseren E-Mail-Account für einen Postausgangsserver hinterlegen, also den Postausgangsserver, den Benutzernamen und das Passwort deines E-Mail-Anbieters (die Daten musst du entsprechend anpassen).

sudo nano /etc/postfix/sasl_passwd

Dann sichern wir die Datei so ab, dass nur der Benutzer root entsprechende Berechtigungen darauf hat.

sudo chown root:root /etc/postfix/sasl_passwd  
sudo chmod 0600 /etc/postfix/sasl_passwd  
sudo postmap /etc/postfix/sasl_passwd

… und legst die Generic-Konfiguration mit folgendem Inhalt an, wobei du „email@yourdomain” durch deine E-Mail-Adresse ersetzt:

sudo nano /etc/postfix/generic

Anschließend setzen wir hier ebenfalls die passende Berechtigung und starten den Postfix-Dienst neu.

sudo chown root:root /etc/postfix/generic  
sudo chmod 0600 /etc/postfix/generic  
sudo postmap /etc/postfix/generic
sudo systemctl restart postfix

Verifiziere mit folgendem Kommando, ob der E-Mail-Versand über deinen Provider funktioniert. Du kannst den FROM-Wert z. B. in wazuh@yourdomain ändern, sofern dein Provider dies unterstützt.

echo "Testmail" | mail -s "WAZUH Testmail" empfaenger@yourdomain -a "FROM:absender@yourdomain"

Wenn das funktioniert, kannst du deine OSSEC-Konfiguration so anpassen, dass Wazuh deine Mail-Konfiguration inkludiert. Falls nicht überprüfe das passende Logfile mit sudo tail -n 50 /var/log/mail.log

sudo nano /var/ossec/etc/ossec.conf

.… tausche dazu die vier Zeilen relativ zu Beginn der Datei im ersten global-Abschnitt aus.

  <global> 
    ... 
    <email_notification>yes</email_notification>  
    <smtp_server>localhost</smtp_server>  
    <email_from>absender@yourdomain</email_from>  
    <email_to>empfaenger@domain</email_to> 
    ... 
  </global>