{"id":264,"date":"2026-06-20T08:00:00","date_gmt":"2026-06-20T08:00:00","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/20\/wazuh-siem-einrichten-tutorial\/"},"modified":"2026-06-20T20:27:00","modified_gmt":"2026-06-20T20:27:00","slug":"wazuh-siem-einrichten-tutorial","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/20\/wazuh-siem-einrichten-tutorial\/","title":{"rendered":"Wazuh SIEM einrichten: Open-Source Security in 12 Schritten [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Wazuh SIEM erkennt Angriffe, die andere Tools \u00fcbersehen. Das quelloffene Security-Information-and-Event-Management-System verarbeitet Protokolle von Tausenden Endpunkten, korreliert Ereignisse in Echtzeit und liefert Alerts nach dem MITRE ATT&amp;CK-Framework. In diesem Tutorial installierst du Wazuh 4.9 auf einem Ubuntu 24.04 Server, verbindest drei Agenten (Linux, Windows, Docker) und konfigurierst aktive Reaktionen auf Brute-Force-Angriffe. Zeitaufwand: 45 Minuten.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"was-ist-wazuh-siem-und-warum-setzen-25-millionen-endpunkte-darauf\">Was ist Wazuh SIEM und warum setzen 25 Millionen Endpunkte darauf?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh ist eine Open-Source-Sicherheitsplattform, die SIEM, XDR (Extended Detection and Response) und CSPM (Cloud Security Posture Management) in einem einzigen Stack vereint. Laut der Wazuh-Projektseite sch\u00fctzt die Plattform Stand 2026 mehr als 25 Millionen Endpunkte weltweit. Das GitHub-Repository z\u00e4hlt \u00fcber 10.000 Sterne. Die Wazuh-Community ist aktiv, mit w\u00f6chentlichen Releases und einem Forum mit \u00fcber 40.000 registrierten Mitgliedern.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh basiert auf dem Fork des eingestellten OSSEC-Projekts, wurde aber grundlegend neu entwickelt. Heute bietet es eine vollst\u00e4ndige REST-API, eine Kibana-\u00e4hnliche Weboberfl\u00e4che (Wazuh Dashboard, intern auf OpenSearch aufgebaut) und native Integrationen mit AWS, Azure, Google Cloud, Microsoft 365 und GitHub. F\u00fcr deutsche Unternehmen, die NIS-2 oder das KRITIS-Dachgesetz einhalten m\u00fcssen, liefert Wazuh die Audit-Protokollierung und Incident-Detection-Funktionen, die Regulatoren erwarten, ohne Lizenzkosten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Wazuh-Stack besteht aus drei Hauptkomponenten: dem <strong>Wazuh Manager<\/strong> (Regelmaschine, Alerting, Active Response), dem <strong>Wazuh Indexer<\/strong> (auf OpenSearch basierend, Speicher und Suche der Sicherheitsereignisse) und dem <strong>Wazuh Dashboard<\/strong> (Web-UI auf OpenSearch Dashboards). Auf den \u00fcberwachten Hosts l\u00e4uft ein leichtgewichtiger <strong>Wazuh Agent<\/strong>, der Protokolle, Systemzustandsdaten und Dateiintegrit\u00e4tsergebnisse verschl\u00fcsselt an den Manager sendet. Die Kommunikation zwischen Agent und Manager erfolgt \u00fcber TLS-verschl\u00fcsselte Verbindungen auf Port 1514.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Gegen\u00fcber klassischen SIEM-L\u00f6sungen hat Wazuh einen entscheidenden Vorteil: Es denkt vom Endpunkt aus. Statt Protokolle nachtr\u00e4glich in ein zentrales System zu laden, verarbeitet der Agent auf dem Host bereits einen Teil der Analyse. Das reduziert die Netzwerklast, beschleunigt die Reaktionszeit bei Active-Response-Regeln und erm\u00f6glicht Offline-Erkennung, wenn der Netzwerkzugang zum Manager unterbrochen ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"voraussetzungen-hardware-software-und-versionen\">Voraussetzungen: Hardware, Software und Versionen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor du anf\u00e4ngst, stelle sicher, dass dein Server diese Mindestanforderungen erf\u00fcllt. Wazuh ist ressourcenhungrig, besonders der OpenSearch-basierte Indexer. Die folgende Tabelle zeigt die Anforderungen f\u00fcr unterschiedliche Umgebungsgr\u00f6\u00dfen:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Komponente<\/th><th>Mindest (Lab)<\/th><th>Klein (bis 100 Agenten)<\/th><th>Produktion (500+ Agenten)<\/th><\/tr><\/thead><tbody><tr><td>CPU<\/td><td>2 vCPU<\/td><td>4 vCPU<\/td><td>8+ vCPU<\/td><\/tr><tr><td>RAM<\/td><td>4 GB<\/td><td>8 GB<\/td><td>16 GB+<\/td><\/tr><tr><td>Festplatte<\/td><td>50 GB SSD<\/td><td>200 GB SSD<\/td><td>500 GB SSD (RAID)<\/td><\/tr><tr><td>Betriebssystem<\/td><td>Ubuntu 22.04 \/ 24.04<\/td><td>Ubuntu 24.04 LTS<\/td><td>Ubuntu 24.04 LTS oder RHEL 9<\/td><\/tr><tr><td>Wazuh-Version<\/td><td>4.9.x<\/td><td>4.9.x<\/td><td>4.9.x (Cluster)<\/td><\/tr><tr><td>Netzwerk-Ports<\/td><td>1514, 1515, 55000, 9200, 443<\/td><td>gleich<\/td><td>+ 9300, 1516 (Cluster)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Du ben\u00f6tigst Root-Zugriff oder sudo-Rechte auf dem Server, einen g\u00fcltigen DNS-Eintrag (optional, aber f\u00fcr TLS-Zertifikate empfohlen) und Python 3.8 oder h\u00f6her f\u00fcr das Wazuh-Installationsskript. F\u00fcr den Windows-Agenten ben\u00f6tigst du Windows 10 21H2 oder neuer (Windows Server 2019+). F\u00fcr Docker-Agenten brauchst du Docker Engine 24.0 oder neuer. Java wird nicht separat ben\u00f6tigt; der Wazuh Indexer bringt eine geb\u00fcndelte JVM mit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"netzwerktopologie-fuer-dieses-tutorial\">Netzwerktopologie f\u00fcr dieses Tutorial<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In diesem Tutorial verwenden wir folgende Struktur: Der Wazuh-Server l\u00e4uft auf <code>192.168.1.10<\/code>, ein Linux-Agent auf <code>192.168.1.20<\/code>, ein Windows-Agent auf <code>192.168.1.30<\/code> und ein Docker-Host auf <code>192.168.1.40<\/code>. Alle Maschinen befinden sich im selben privaten Subnetz. Im Produktionsbetrieb empfiehlt sich der Wazuh-Server in einem dedizierten Management-VLAN, das nur von Agenten erreichbar ist, um die Angriffsfl\u00e4che zu minimieren. Ein Angreifer, der Zugang zu einem \u00fcberwachten Host bekommt, sollte den Manager nicht direkt erreichen k\u00f6nnen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die <strong>Port-\u00dcbersicht<\/strong> f\u00fcr deine Firewall-Regeln: Port 1514\/TCP+UDP ist der Datentransfer-Port von Agenten zum Manager. Port 1515\/TCP ist der Enrollment-Port f\u00fcr neue Agenten. Port 1516\/TCP ist f\u00fcr den Manager-Cluster (nur bei Multi-Node-Setup). Port 55000\/TCP ist die REST-API des Managers. Port 9200\/TCP ist der OpenSearch-HTTP-Endpunkt (intern). Port 443\/TCP ist das Wazuh Dashboard. Port 9300\/TCP ist der OpenSearch-Cluster-Kommunikationsport (nur bei Multi-Node-Indexer).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-1-system-vorbereiten-und-updates-einspielen\">Schritt 1: System vorbereiten und Updates einspielen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Beginne mit einem frischen Ubuntu-24.04-Server. Spiele alle Sicherheitsupdates ein und stelle die korrekte Zeitzone ein. Wazuh-Timestamps sind f\u00fcr die Ereigniskorrelation kritisch; Uhrzeitabweichungen zwischen Server und Agenten f\u00fchren zu verpassten Alerts oder falschen Zeitfenstern bei Korrelationsregeln.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt update && sudo apt upgrade -y\nsudo apt install curl wget gnupg2 apt-transport-https lsb-release ca-certificates -y\n\n# Zeitzone auf Europe\/Berlin setzen\nsudo timedatectl set-timezone Europe\/Berlin\nsudo timedatectl set-ntp true\n\n# Hostname korrekt setzen (wichtig f\u00fcr TLS-Zertifikate)\nsudo hostnamectl set-hostname wazuh-server\necho \"192.168.1.10 wazuh-server\" | sudo tee -a \/etc\/hosts\n\n# Swap deaktivieren (OpenSearch-Anforderung)\nsudo swapoff -a\nsudo sed -i '\/swap\/d' \/etc\/fstab\n\n# Kernel-Parameter f\u00fcr OpenSearch\necho \"vm.max_map_count=262144\" | sudo tee -a \/etc\/sysctl.conf\necho \"net.core.somaxconn=65535\" | sudo tee -a \/etc\/sysctl.conf\nsudo sysctl -p<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Parameter <code>vm.max_map_count=262144<\/code> ist zwingend notwendig. Ohne ihn startet der Wazuh Indexer (OpenSearch) nicht und gibt den Fehler <code>max virtual memory areas vm.max_map_count [65530] is too low<\/code> aus. Das ist einer der h\u00e4ufigsten Installationsfehler. Vergiss au\u00dferdem nicht, Swap zu deaktivieren. OpenSearch-Dokumentation schreibt dies explizit vor, da Swap die Suchperformance massiv degradiert und zu sporadischen Timeouts bei Abfragen f\u00fchren kann. Der Zusatz <code>net.core.somaxconn=65535<\/code> erh\u00f6ht den maximalen Socket-Backlog, was bei vielen gleichzeitigen Agentenverbindungen relevant ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-2-wazuh-installationsskript-herunterladen-und-konfigurieren\">Schritt 2: Wazuh-Installationsskript herunterladen und konfigurieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh bietet ein All-in-One-Installationsskript, das alle drei Komponenten (Indexer, Manager, Dashboard) automatisch einrichtet. Lade es von der offiziellen Wazuh-Quelle herunter und verifiziere die SHA256-Pr\u00fcfsumme vor der Ausf\u00fchrung. Das Skript basiert auf signierten Paketen und dem offiziellen Wazuh-APT-Repository.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Installationsskript und Konfigurationsvorlage herunterladen\ncurl -sO https:\/\/packages.wazuh.com\/4.9\/wazuh-install.sh\ncurl -sO https:\/\/packages.wazuh.com\/4.9\/config.yml\n\n# SHA256 pr\u00fcfen (Ausgabe mit offizieller Dokumentation vergleichen)\nsha256sum wazuh-install.sh\n\n# Konfigurationsdatei anpassen\nnano config.yml<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Datei <code>config.yml<\/code> definiert, welche Knoten installiert werden und welche IP-Adressen sie verwenden. F\u00fcr eine Single-Node-Installation (ein Server f\u00fcr alle Rollen) passe sie wie folgt an:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># config.yml f\u00fcr Single-Node-Installation\nnodes:\n  indexer:\n    - name: node-1\n      ip: \"192.168.1.10\"\n  server:\n    - name: wazuh-1\n      ip: \"192.168.1.10\"\n  dashboard:\n    - name: dashboard\n      ip: \"192.168.1.10\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Starte die Installation. Der Prozess l\u00e4dt die Wazuh-Pakete herunter, generiert TLS-Zertifikate f\u00fcr die interne Kommunikation, konfiguriert OpenSearch, startet alle drei Dienste und erstellt die initiale Passwortdatei. Auf einem schnellen Server mit guter Internetverbindung dauert das 8 bis 12 Minuten:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo bash wazuh-install.sh -a\n\n# Ausgabe am Ende der Installation (Beispiel):\n# INFO: --- Summary ---\n# INFO: You can access the web interface https:\/\/192.168.1.10\n#    User: admin\n#    Password: Ab1Cd2Ef3Gh4Ij5K\n# INFO: Installation finished.\n\n# Passwortdatei sichern\nsudo cat \/home\/$USER\/wazuh-passwords.txt > ~\/wazuh-passwords-backup.txt\nchmod 600 ~\/wazuh-passwords-backup.txt<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Das Skript generiert am Ende eine Passwortdatei <code>wazuh-passwords.txt<\/code>. <strong>Speichere diese Datei sofort an einem sicheren Ort.<\/strong> Sie enth\u00e4lt Credentials f\u00fcr den Admin-Account, den Wazuh-API-User, den Indexer-Admin und mehrere interne Service-Accounts. Die Passw\u00f6rter k\u00f6nnen nachtr\u00e4glich ge\u00e4ndert werden, aber vergessene Indexer-Admin-Passw\u00f6rter erfordern eine aufwendige Reset-Prozedur \u00fcber die OpenSearch Security-Tools.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-3-installation-verifizieren-und-services-pruefen\">Schritt 3: Installation verifizieren und Services pr\u00fcfen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Nach der Installation pr\u00fcfe den Status aller drei Dienste. Alle m\u00fcssen <code>active (running)<\/code> zeigen. Falls einer der Dienste im Status <code>failed<\/code> ist, pr\u00fcfe das Journal-Log des betroffenen Dienstes.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Status aller Wazuh-Dienste pr\u00fcfen\nsudo systemctl status wazuh-indexer --no-pager\nsudo systemctl status wazuh-manager --no-pager\nsudo systemctl status wazuh-dashboard --no-pager\n\n# Wazuh Indexer-Gesundheit pr\u00fcfen\ncurl -k -u admin:DEIN_PASSWORT https:\/\/localhost:9200\/_cat\/health?v\n\n# Erwartete Ausgabe:\n# epoch      timestamp cluster       status node.total node.data shards pri relo init unassign\n# 1750000000 12:00:00  wazuh-cluster green           1         1      0   0    0    0        0\n\n# Manager-Status direkt pr\u00fcfen\nsudo \/var\/ossec\/bin\/wazuh-control status\n\n# Erwartete Ausgabe:\n# wazuh-execd is running...\n# wazuh-analysisd is running...\n# wazuh-syscheckd is running...\n# wazuh-monitord is running...\n# wazuh-logcollector is running...\n# wazuh-remoted is running...\n# wazuh-db is running...\n# wazuh-apid is running...\n# wazuh-authd is running...<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Greife nun auf das Dashboard zu: \u00d6ffne <code>https:\/\/192.168.1.10<\/code> im Browser (HTTPS, Port 443). Der Browser zeigt eine Zertifikatswarnung, da ein selbst signiertes Zertifikat verwendet wird. Klicke auf &#8220;Erweitert&#8221; und dann &#8220;Weiter zur Seite&#8221;. Melde dich mit dem Benutzernamen <code>admin<\/code> und dem Passwort aus der <code>wazuh-passwords.txt<\/code> an. Nach dem Login siehst du das Wazuh-Hauptdashboard mit der \u00dcbersicht der aktiven Agenten, aktuellen Alerts und MITRE ATT&amp;CK-Abdeckung.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-4-ersten-linux-agenten-installieren-und-registrieren\">Schritt 4: Ersten Linux-Agenten installieren und registrieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh-Agenten senden Protokolle, Datei-Integrit\u00e4tspr\u00fcfungen, Schwachstellen-Inventar und System-Metadaten an den Manager. Die Kommunikation ist TLS-verschl\u00fcsselt; der Agent authentifiziert sich beim ersten Start automatisch \u00fcber den Enrollment-Mechanismus auf Port 1515. Installiere den Agenten auf dem Linux-Rechner (<code>192.168.1.20<\/code>):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Auf dem Linux-Agent (192.168.1.20) ausf\u00fchren\ncurl -s https:\/\/packages.wazuh.com\/key\/GPG-KEY-WAZUH | \\\n  gpg --no-default-keyring \\\n  --keyring gnupg-ring:\/usr\/share\/keyrings\/wazuh.gpg \\\n  --import\nchmod 644 \/usr\/share\/keyrings\/wazuh.gpg\n\necho \"deb [signed-by=\/usr\/share\/keyrings\/wazuh.gpg] \\\n  https:\/\/packages.wazuh.com\/4.x\/apt\/ stable main\" | \\\n  sudo tee \/etc\/apt\/sources.list.d\/wazuh.list\n\nsudo apt update\nsudo apt install wazuh-agent -y\n\n# Agent mit dem Manager verbinden (Umgebungsvariablen-Methode)\nsudo WAZUH_MANAGER=\"192.168.1.10\" \\\n  WAZUH_AGENT_NAME=\"linux-server-01\" \\\n  WAZUH_AGENT_GROUP=\"linux-servers\" \\\n  dpkg-reconfigure wazuh-agent\n\n# Service aktivieren und starten\nsudo systemctl daemon-reload\nsudo systemctl enable wazuh-agent\nsudo systemctl start wazuh-agent\n\n# Verbindungsstatus pr\u00fcfen\nsudo \/var\/ossec\/bin\/wazuh-control status | grep agent<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Nach dem Start muss der Agent beim Manager registriert werden. Das geschieht bei Wazuh 4.x automatisch \u00fcber den Enrollment-Mechanismus ohne manuelle Zertifikatsverteilung. Du siehst den Agenten nach etwa 30 Sekunden im Dashboard unter &#8220;Agents&#8221; mit dem Status &#8220;Active&#8221;. Falls er nach 2 Minuten noch &#8220;Never connected&#8221; zeigt, pr\u00fcfe die Konnektivit\u00e4t: der Agent muss Port 1514 (UDP\/TCP) und Port 1515 (TCP, Enrollment) auf dem Manager-Server erreichen k\u00f6nnen. Nutze <code>telnet 192.168.1.10 1514<\/code> f\u00fcr den schnellen Test.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-5-windows-agenten-per-powershell-installieren\">Schritt 5: Windows-Agenten per PowerShell installieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr Windows-Hosts steht ein MSI-Installer bereit. Die unbeaufsichtigte PowerShell-Installation ist f\u00fcr GPO-Rollouts in Active-Directory-Umgebungen bevorzugt, weil sie ohne Benutzerinteraktion funktioniert und \u00fcber Group Policy Software Installation oder Softwareverteilungswerkzeuge wie SCCM\/Intune ausgerollt werden kann.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># PowerShell auf dem Windows-Host (als Administrator ausf\u00fchren)\n# Verzeichnis erstellen und MSI herunterladen\nNew-Item -ItemType Directory -Force -Path \"C:\\Temp\"\nInvoke-WebRequest -Uri \"https:\/\/packages.wazuh.com\/4.x\/windows\/wazuh-agent-4.9.0-1.msi\" `\n  -OutFile \"C:\\Temp\\wazuh-agent.msi\"\n\n# Signatur pr\u00fcfen (empfohlen)\nGet-AuthenticodeSignature \"C:\\Temp\\wazuh-agent.msi\"\n\n# Unattended Installation mit Manager-Konfiguration\nStart-Process msiexec.exe -Wait -ArgumentList `\n  '\/i C:\\Temp\\wazuh-agent.msi `\n  WAZUH_MANAGER=\"192.168.1.10\" `\n  WAZUH_AGENT_NAME=\"windows-client-01\" `\n  WAZUH_AGENT_GROUP=\"windows-clients\" `\n  \/qn \/l*v C:\\Temp\\wazuh-install.log'\n\n# Service starten und auf automatisch setzen\nStart-Service WazuhSvc\nSet-Service WazuhSvc -StartupType Automatic\n\n# Verbindungsstatus pr\u00fcfen\nGet-Service -Name WazuhSvc | Select-Object Status, DisplayName, StartType<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Windows-Agent \u00fcberwacht standardm\u00e4\u00dfig die Windows-Ereignisprotokolle (Security Log f\u00fcr Anmelde-Events, System Log f\u00fcr Service-\u00c4nderungen, Application Log f\u00fcr Softwarefehler), den Registry-Pfad <code>HKLM\\Software<\/code> auf \u00c4nderungen (wichtig f\u00fcr Malware-Persistenz-Erkennung) und ausgew\u00e4hlte Systemordner auf Datei\u00e4nderungen. Diese Konfiguration liegt in <code>C:\\Program Files (x86)\\ossec-agent\\ossec.conf<\/code> und kann angepasst werden. F\u00fcr Sicherheits-Auditing ist besonders der Windows Security Event Log mit den Event-IDs 4624 (Login), 4625 (Login-Fehler), 4688 (Prozessstart) und 4698 (geplante Task erstellt) relevant.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-6-docker-container-mit-dem-wazuh-docker-listener-ueberwachen\">Schritt 6: Docker-Container mit dem Wazuh Docker Listener \u00fcberwachen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh kann Docker-Ereignisse direkt abh\u00f6ren: Container-Starts und -Stopps, Image-Pulls, Volume-Mounts, Netzwerk-Konfigurations\u00e4nderungen und besonders gef\u00e4hrliche Aktionen wie das Starten privilegierter Container. Das Docker-Listener-Modul kommuniziert mit dem Docker-Daemon \u00fcber den Unix-Socket und ben\u00f6tigt entsprechende Gruppenrechte.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Auf dem Docker-Host (192.168.1.40) nach Agent-Installation\n# Wazuh-Benutzer zur Docker-Gruppe hinzuf\u00fcgen\nsudo usermod -aG docker wazuh\n\n# Docker-Listener in \/var\/ossec\/etc\/ossec.conf aktivieren\n# F\u00fcge innerhalb von <ossec_config> hinzu:\n\ncat << 'EOF' | sudo tee \/tmp\/docker-listener.xml\n<wodle name=\"docker-listener\">\n  <disabled>no<\/disabled>\n  <interval>10<\/interval>\n  <attempts>5<\/attempts>\n  <run_on_start>yes<\/run_on_start>\n<\/wodle>\nEOF\n\n# Manuelle Einf\u00fcgung: F\u00fcge den obigen Block in \/var\/ossec\/etc\/ossec.conf ein\n# (vor dem schlie\u00dfenden <\/ossec_config>-Tag)\n\n# Agent neustarten\nsudo systemctl restart wazuh-agent\n\n# Testweise einen privilegierten Container starten\n# (Wazuh sollte Alert Stufe 12 generieren)\ndocker run --rm --privileged alpine echo \"Privilege-Escalation-Test\"\n\n# Events im Log pr\u00fcfen\nsudo tail -50 \/var\/ossec\/logs\/ossec.log | grep docker<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Im Wazuh-Dashboard siehst du nach 60 Sekunden unter dem Agenten Docker-Events wie <code>Docker: Container started<\/code>, <code>Docker: Image pulled<\/code> und bei privilegierten Containern: <code>Docker: Privileged container started (T1611)<\/code>. Das MITRE ATT&amp;CK-Framework ordnet privilegierte Container-Starts der Technik <strong>T1611 (Escape to Host)<\/strong> unter der Taktik Privilege Escalation zu. Wazuh mappt dies automatisch und zeigt den MITRE-Link im Alert-Detail. F\u00fcr Kubernetes-Umgebungen gibt es das separate Wazuh-Kubernetes-Modul, das Audit-Logs des API-Servers auswertet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-7-regelwerk-verstehen-und-eigene-erkennungsregeln-schreiben\">Schritt 7: Regelwerk verstehen und eigene Erkennungsregeln schreiben<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh enth\u00e4lt \u00fcber 3.000 vorinstallierte Erkennungsregeln, die vom Wazuh-Team regelm\u00e4\u00dfig aktualisiert werden. Die Regeln liegen im Verzeichnis <code>\/var\/ossec\/ruleset\/rules\/<\/code>. Wichtig: Bearbeite Dateien in diesem Verzeichnis nie direkt, da sie bei jedem Update \u00fcberschrieben werden. Eigene Regeln geh\u00f6ren ausschlie\u00dflich in <code>\/var\/ossec\/etc\/rules\/local_rules.xml<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Jede Regel besteht aus einer eindeutigen ID (100000-119999 f\u00fcr eigene Regeln), einer Schweregradbewertung (Level 0-15) und einer Bedingung (regul\u00e4rer Ausdruck, Elternregel-Referenz oder Decoder-Ausgabe). Hier sind praxisnahe Beispielregeln f\u00fcr h\u00e4ufige Angriffsmuster:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;!-- \/var\/ossec\/etc\/rules\/local_rules.xml --&gt;\n&lt;group name=\"local,custom,\"&gt;\n\n  &lt;!-- Alert wenn sudoers-Datei ge\u00e4ndert wird (Privilege Escalation) --&gt;\n  &lt;rule id=\"100001\" level=\"12\"&gt;\n    &lt;if_sid&gt;5402&lt;\/if_sid&gt;\n    &lt;match&gt;sudo: .* COMMAND=\/usr\/sbin\/visudo&lt;\/match&gt;\n    &lt;description&gt;Sudoers-Datei wurde bearbeitet - Privilege Escalation moeglich&lt;\/description&gt;\n    &lt;mitre&gt;\n      &lt;id&gt;T1548.003&lt;\/id&gt;\n    &lt;\/mitre&gt;\n  &lt;\/rule&gt;\n\n  &lt;!-- Alert bei Root-Shell via sudo --&gt;\n  &lt;rule id=\"100002\" level=\"10\"&gt;\n    &lt;if_sid&gt;5402&lt;\/if_sid&gt;\n    &lt;match&gt;sudo: .* COMMAND=\/bin\/bash|COMMAND=\/bin\/sh&lt;\/match&gt;\n    &lt;description&gt;Root-Shell ueber sudo ausgefuehrt (T1548)&lt;\/description&gt;\n    &lt;mitre&gt;\n      &lt;id&gt;T1548.003&lt;\/id&gt;\n    &lt;\/mitre&gt;\n  &lt;\/rule&gt;\n\n  &lt;!-- Alert bei neuen cron-Jobs (Persistence) --&gt;\n  &lt;rule id=\"100003\" level=\"8\"&gt;\n    &lt;if_group&gt;syscheck&lt;\/if_group&gt;\n    &lt;match&gt;\/etc\/cron|\/var\/spool\/cron&lt;\/match&gt;\n    &lt;description&gt;Cron-Verzeichnis geaendert - moegliche Persistence (T1053)&lt;\/description&gt;\n    &lt;mitre&gt;\n      &lt;id&gt;T1053.003&lt;\/id&gt;\n    &lt;\/mitre&gt;\n  &lt;\/rule&gt;\n\n  &lt;!-- Massendownload via curl\/wget erkennen --&gt;\n  &lt;rule id=\"100004\" level=\"6\"&gt;\n    &lt;if_sid&gt;0&lt;\/if_sid&gt;\n    &lt;program_name&gt;bash|sh&lt;\/program_name&gt;\n    &lt;match&gt;curl.*http|wget.*http&lt;\/match&gt;\n    &lt;description&gt;Download-Tool in Shell ausgefuehrt - Staging moeglich (T1105)&lt;\/description&gt;\n    &lt;mitre&gt;\n      &lt;id&gt;T1105&lt;\/id&gt;\n    &lt;\/mitre&gt;\n  &lt;\/rule&gt;\n\n&lt;\/group&gt;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Nach dem Erstellen eigener Regeln muss die Syntax validiert und der Manager neugeladen werden:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Regelvalidierung mit wazuh-logtest\nsudo \/var\/ossec\/bin\/wazuh-logtest\n\n# Beispieleingabe zum Testen der Regel 100001:\n# Apr 10 12:00:00 server sudo:  admin : TTY=pts\/0 ; PWD=\/home\/admin ; USER=root ; COMMAND=\/usr\/sbin\/visudo\n\n# Manager-Regeln neu laden (kein Neustart n\u00f6tig seit Wazuh 4.2)\nsudo \/var\/ossec\/bin\/wazuh-control reload\n\n# Oder vollst\u00e4ndiger Neustart:\nsudo systemctl restart wazuh-manager<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Schweregradbewertung (Level) folgt einer festen Semantik: Level 0-2 sind Debug-Informationen, 3-5 niedrige Ereignisse (Login-Erfolge, Systemstarts), 6-9 mittlere Bedrohungen (fehlgeschlagene Logins, Konfigurations\u00e4nderungen), 10-12 hohe Bedrohungen (Privilege Escalation, Brute Force erkannt) und 13-15 kritische Angriffe (aktiver Einbruch, Rootkit-Erkennung). Standard-E-Mail-Alerts beginnen bei Level 10; Active Response bei Level 6 (konfigurierbar).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-8-datei-integritaetsueberwachung-fim-fuer-kritische-pfade-einrichten\">Schritt 8: Datei-Integrit\u00e4ts\u00fcberwachung (FIM) f\u00fcr kritische Pfade einrichten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">File Integrity Monitoring (FIM) ist f\u00fcr Compliance-Anforderungen nach BSI-Grundschutz (OPS.1.1.5), PCI DSS (Anforderung 11.5) und NIS-2 unverzichtbar. FIM erkennt \u00c4nderungen an kritischen Systemdateien in Echtzeit oder nach einem festgelegten Zeitplan. Ein Angreifer, der <code>\/etc\/passwd<\/code>, <code>\/etc\/sudoers<\/code> oder Webserver-Skripte manipuliert, wird innerhalb von Sekunden entdeckt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;!-- Erweiterte FIM-Konfiguration im Agent (\/var\/ossec\/etc\/ossec.conf) --&gt;\n&lt;syscheck&gt;\n  &lt;disabled&gt;no&lt;\/disabled&gt;\n\n  &lt;!-- Vollst\u00e4ndiger Scan alle 6 Stunden --&gt;\n  &lt;frequency&gt;21600&lt;\/frequency&gt;\n\n  &lt;!-- Echtzeit-\u00dcberwachung kritischer Systemdateien --&gt;\n  &lt;directories realtime=\"yes\" check_all=\"yes\"&gt;\/etc&lt;\/directories&gt;\n  &lt;directories realtime=\"yes\" check_all=\"yes\"&gt;\/usr\/bin,\/usr\/sbin&lt;\/directories&gt;\n  &lt;directories realtime=\"yes\" check_all=\"yes\" report_changes=\"yes\"&gt;\/root&lt;\/directories&gt;\n  &lt;directories realtime=\"yes\" check_all=\"yes\"&gt;\/boot&lt;\/directories&gt;\n\n  &lt;!-- Webanwendungen \u00fcberwachen --&gt;\n  &lt;directories realtime=\"yes\" check_all=\"yes\" report_changes=\"yes\"&gt;\n    \/var\/www\/html\n  &lt;\/directories&gt;\n\n  &lt;!-- SSH-Konfiguration besonders sch\u00fctzen --&gt;\n  &lt;directories realtime=\"yes\" check_all=\"yes\" report_changes=\"yes\"&gt;\n    \/etc\/ssh\n  &lt;\/directories&gt;\n\n  &lt;!-- Ausnahmen f\u00fcr h\u00e4ufig \u00e4ndernde Dateien (Rauschreduzierung) --&gt;\n  &lt;ignore&gt;\/etc\/mtab&lt;\/ignore&gt;\n  &lt;ignore&gt;\/etc\/hosts.deny&lt;\/ignore&gt;\n  &lt;ignore&gt;\/etc\/resolv.conf&lt;\/ignore&gt;\n  &lt;ignore type=\"sregex\"&gt;.log$|.tmp$|.pid$|.swp$&lt;\/ignore&gt;\n  &lt;ignore type=\"sregex\"&gt;^\/proc&lt;\/ignore&gt;\n  &lt;ignore type=\"sregex\"&gt;^\/sys&lt;\/ignore&gt;\n\n  &lt;!-- Scan-Geschwindigkeit begrenzen (CPU-Schonung) --&gt;\n  &lt;max_files_per_second&gt;100&lt;\/max_files_per_second&gt;\n\n  &lt;!-- Datenbankgr\u00f6\u00dfe begrenzen --&gt;\n  &lt;database&gt;disk&lt;\/database&gt;\n&lt;\/syscheck&gt;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">FIM erkennt sieben Arten von \u00c4nderungen: MD5\/SHA1\/SHA256-Hash\u00e4nderungen, Besitzer\u00e4nderungen (UID\/GID), Berechtigungs\u00e4nderungen (chmod), Dateigr\u00f6\u00dfen\u00e4nderungen, Erstellungsvorg\u00e4nge (neue Dateien), L\u00f6schvorg\u00e4nge und Inhalts\u00e4nderungen (bei aktiviertem <code>report_changes=\"yes\"<\/code>). Im Wazuh-Dashboard erscheinen FIM-Events unter dem Modul &#8220;Integrity Monitoring&#8221;. Du kannst nach Dateipfad, Benutzer, \u00c4nderungstyp und Zeitraum filtern. Die historischen FIM-Events sind 90 Tage durchsuchbar (konfigurierbar \u00fcber ILM).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-9-brute-force-erkennung-und-automatische-ip-sperrung\">Schritt 9: Brute-Force-Erkennung und automatische IP-Sperrung<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Active Response ist eine der st\u00e4rksten Wazuh-Funktionen f\u00fcr Systemh\u00e4rtung in Echtzeit. Sie f\u00fchrt automatisch Gegenma\u00dfnahmen aus, wenn definierte Regeln ausgel\u00f6st werden. Der h\u00e4ufigste Anwendungsfall: automatisches Blockieren von IP-Adressen, die SSH-Brute-Force-Angriffe durchf\u00fchren.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;!-- Active Response in \/var\/ossec\/etc\/ossec.conf auf dem Manager --&gt;\n\n&lt;!-- SSH Brute Force: Blockierung bei erkanntem Angriff (Regel 5763) --&gt;\n&lt;active-response&gt;\n  &lt;command&gt;firewall-drop&lt;\/command&gt;\n  &lt;location&gt;local&lt;\/location&gt;\n  &lt;rules_id&gt;5763&lt;\/rules_id&gt;\n  &lt;timeout&gt;600&lt;\/timeout&gt;\n  &lt;!-- Whitelist: Admin-Netzwerke nie blockieren --&gt;\n  &lt;white_list&gt;192.168.1.0\/24&lt;\/white_list&gt;\n  &lt;white_list&gt;10.0.0.0\/8&lt;\/white_list&gt;\n&lt;\/active-response&gt;\n\n&lt;!-- Allgemeine Authentifizierungsfehler: Blockierung bei Level 6+ --&gt;\n&lt;active-response&gt;\n  &lt;command&gt;firewall-drop&lt;\/command&gt;\n  &lt;location&gt;local&lt;\/location&gt;\n  &lt;level&gt;6&lt;\/level&gt;\n  &lt;rules_group&gt;authentication_failures&lt;\/rules_group&gt;\n  &lt;timeout&gt;1800&lt;\/timeout&gt;\n  &lt;white_list&gt;192.168.1.0\/24&lt;\/white_list&gt;\n&lt;\/active-response&gt;\n\n&lt;!-- Host-Blocking auch auf Agenten ausf\u00fchren (location: all) --&gt;\n&lt;active-response&gt;\n  &lt;command&gt;firewall-drop&lt;\/command&gt;\n  &lt;location&gt;all&lt;\/location&gt;\n  &lt;rules_id&gt;5763&lt;\/rules_id&gt;\n  &lt;timeout&gt;600&lt;\/timeout&gt;\n&lt;\/active-response&gt;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Das <code>firewall-drop<\/code>-Skript verwendet auf Linux-Systemen iptables oder nftables, auf macOS pf und auf Windows die Windows Firewall. Nach der Aktivierung teste die Funktion mit einem kontrollierten Brute-Force-Test von einer isolierten Test-IP (nicht der Produktionsmaschine):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Active Response manuell ausl\u00f6sen (Test)\n# Auf dem Manager ausf\u00fchren:\nsudo \/var\/ossec\/bin\/agent_control -b 203.0.113.5 -f firewall-drop0 -u 001\n\n# Blockierte IPs auf dem Agenten pr\u00fcfen\nsudo iptables -L INPUT -n | grep DROP\n\n# Wazuh Active Response Log\nsudo tail -f \/var\/ossec\/logs\/active-responses.log\n\n# Alert-Log auf Active Response Events pr\u00fcfen\nsudo grep \"active-response\" \/var\/ossec\/logs\/alerts\/alerts.log | tail -20<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-10-vulnerability-detection-fuer-alle-endpunkte-aktivieren\">Schritt 10: Vulnerability Detection f\u00fcr alle Endpunkte aktivieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Das Vulnerability-Detection-Modul vergleicht die installierten Pakete aller Agenten gegen bekannte CVEs aus der National Vulnerability Database (NVD), RedHat Security Advisories, Canonical USN (Ubuntu Security Notices) und OVAL-Feeds. Die Schwachstellendatenbank wird automatisch alle 60 Minuten aktualisiert.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;!-- Vulnerability Detection im Manager (\/var\/ossec\/etc\/ossec.conf) --&gt;\n&lt;vulnerability-detection&gt;\n  &lt;enabled&gt;yes&lt;\/enabled&gt;\n  &lt;index-status&gt;yes&lt;\/index-status&gt;\n  &lt;feed-update-interval&gt;60m&lt;\/feed-update-interval&gt;\n&lt;\/vulnerability-detection&gt;\n\n&lt;!-- Syscollector auf Agenten aktivieren (Software-Inventar) --&gt;\n&lt;wodle name=\"syscollector\"&gt;\n  &lt;disabled&gt;no&lt;\/disabled&gt;\n  &lt;interval&gt;1h&lt;\/interval&gt;\n  &lt;scan_on_start&gt;yes&lt;\/scan_on_start&gt;\n  &lt;packages&gt;yes&lt;\/packages&gt;\n  &lt;os&gt;yes&lt;\/os&gt;\n  &lt;processes&gt;yes&lt;\/processes&gt;\n  &lt;ports all=\"no\"&gt;yes&lt;\/ports&gt;\n  &lt;network&gt;yes&lt;\/network&gt;\n  &lt;hotfixes&gt;yes&lt;\/hotfixes&gt;\n&lt;\/wodle&gt;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Nach Aktivierung zeigt das Dashboard unter &#8220;Vulnerability Detection&#8221; alle gefundenen CVEs je Agent, sortiert nach Schweregrad (Critical, High, Medium, Low, Informational). Jeder Eintrag enth\u00e4lt die CVSS-Bewertung (v2 und v3), die betroffene Paketversion, ob ein Patch verf\u00fcgbar ist, und einen direkten Link zur NVD-Datenbank. Die <strong>Hotfix-Erkennung auf Windows<\/strong> vergleicht installierte KB-Patches mit den aktuellen Microsoft Security Updates und meldet fehlende Patches als Schwachstellen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In einem typischen Ubuntu-24.04-System, das 30 Tage ohne Updates lief, findet Wazuh zwischen 15 und 80 bekannte Schwachstellen. Ein frisch gepatchtes System zeigt in der Regel 0-5 Low-Severity-CVEs, die auf Kernel-Versionen zur\u00fcckgehen, die noch keinen \u00f6ffentlichen Patch haben.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-11-e-mail-benachrichtigungen-und-slack-integration\">Schritt 11: E-Mail-Benachrichtigungen und Slack-Integration<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh-Alerts sind nur n\u00fctzlich, wenn das Team sie sieht. Konfiguriere E-Mail-Benachrichtigungen f\u00fcr kritische Alerts und optionale Slack-Webhooks f\u00fcr schnelle Reaktionszeiten im SOC-Team. Die E-Mail-Konfiguration erfolgt im <code>&lt;global&gt;<\/code>-Block der Manager-Konfiguration:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;!-- E-Mail-Konfiguration in \/var\/ossec\/etc\/ossec.conf --&gt;\n&lt;global&gt;\n  &lt;jsonout_output&gt;yes&lt;\/jsonout_output&gt;\n  &lt;alerts_log&gt;yes&lt;\/alerts_log&gt;\n  &lt;email_notification&gt;yes&lt;\/email_notification&gt;\n  &lt;smtp_server&gt;smtp.example.de&lt;\/smtp_server&gt;\n  &lt;smtp_port&gt;587&lt;\/smtp_port&gt;\n  &lt;email_from&gt;wazuh@example.de&lt;\/email_from&gt;\n  &lt;email_to&gt;soc@example.de&lt;\/email_to&gt;\n  &lt;email_maxperhour&gt;12&lt;\/email_maxperhour&gt;\n  &lt;email_alert_level&gt;10&lt;\/email_alert_level&gt;\n&lt;\/global&gt;\n\n&lt;!-- Slack-Integration (Webhook) --&gt;\n&lt;integration&gt;\n  &lt;name&gt;slack&lt;\/name&gt;\n  &lt;hook_url&gt;https:\/\/hooks.slack.com\/services\/DEIN\/WEBHOOK\/TOKEN&lt;\/hook_url&gt;\n  &lt;level&gt;10&lt;\/level&gt;\n  &lt;alert_format&gt;json&lt;\/alert_format&gt;\n&lt;\/integration&gt;\n\n&lt;!-- PagerDuty-Integration f\u00fcr On-Call-Teams --&gt;\n&lt;integration&gt;\n  &lt;name&gt;pagerduty&lt;\/name&gt;\n  &lt;api_key&gt;DEIN_PAGERDUTY_INTEGRATION_KEY&lt;\/api_key&gt;\n  &lt;level&gt;12&lt;\/level&gt;\n  &lt;alert_format&gt;json&lt;\/alert_format&gt;\n&lt;\/integration&gt;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh unterst\u00fctzt neben Slack und PagerDuty auch Microsoft Teams, TheHive (Open-Source-Incident-Response-Plattform), Jira und IBM QRadar \u00fcber die Integration-Engine. F\u00fcr komplexe SOAR-Workflows ist die REST-API auf Port 55000 besser geeignet: Sie erm\u00f6glicht vollst\u00e4ndige Automatisierung von Alert-Triage, Ticket-Erstellung und Gegenma\u00dfnahmen-Ausl\u00f6sung \u00fcber Tools wie Shuffle oder n8n.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-12-mitre-attck-dashboard-und-compliance-berichte-nutzen\">Schritt 12: MITRE ATT&amp;CK-Dashboard und Compliance-Berichte nutzen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Das Wazuh-Dashboard enth\u00e4lt ein eingebautes MITRE ATT&amp;CK-Panel, das alle Alerts automatisch den entsprechenden Taktiken und Techniken zuordnet. Die Heatmap zeigt auf einen Blick, welche ATT&amp;CK-Phasen in deiner Umgebung am h\u00e4ufigsten ausgel\u00f6st werden. Das ist besonders wertvoll f\u00fcr das Reporting an CISO-Ebene und f\u00fcr externe Audits.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr Compliance-Berichte (PCI DSS, HIPAA, GDPR, NIS-2) navigiere im Dashboard zu &#8220;Regulatory Compliance&#8221;. Wazuh mappt seine Regeln automatisch auf diese Standards. Berichte lassen sich als PDF exportieren oder \u00fcber die API abrufen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Wazuh REST-API: Authentifizierung und Abfragen\n# Schritt 1: JWT-Token abrufen\nTOKEN=$(curl -k -s -u \"wazuh:DEIN_API_PASSWORT\" \\\n  -X POST \"https:\/\/192.168.1.10:55000\/security\/user\/authenticate?raw=true\")\n\n# Schritt 2: Alle aktiven Agenten auflisten\ncurl -k -s -X GET \"https:\/\/192.168.1.10:55000\/agents?status=active&limit=50\" \\\n  -H \"Authorization: Bearer $TOKEN\" | python3 -m json.tool | head -50\n\n# Schritt 3: Kritische Schwachstellen aller Agenten abfragen\ncurl -k -s -X GET \"https:\/\/192.168.1.10:55000\/vulnerability\/agents?severity=critical\" \\\n  -H \"Authorization: Bearer $TOKEN\" | python3 -m json.tool\n\n# Schritt 4: Letzte 10 kritischen Alerts (Level 12+) exportieren\ncurl -k -s -X GET \"https:\/\/192.168.1.10:55000\/alerts?level=12&limit=10&sort=-timestamp\" \\\n  -H \"Authorization: Bearer $TOKEN\" | python3 -m json.tool<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh deckt folgende PCI-DSS-Anforderungen ab: 10.5 (Protokollschutz), 10.6 (Protokollauswertung), 11.5 (Dateiintegrit\u00e4ts\u00fcberwachung) und 11.4 (Intrusion Detection). F\u00fcr NIS-2-konforme Unternehmen in Deutschland liefert die automatische Protokollierung mit Index-basierter Tamper-Evidenz die geforderte Aufzeichnung sicherheitsrelevanter Ereignisse. Verl\u00e4ngere die Aufbewahrungsdauer im ILM-Policy auf 365 Tage (statt Standard 90 Tage), um die NIS-2-Anforderung f\u00fcr die 12-monatige Protokollaufbewahrung zu erf\u00fcllen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"5-haeufige-fehler-bei-der-wazuh-installation-und-wie-du-sie-vermeidest\">5 h\u00e4ufige Fehler bei der Wazuh-Installation und wie du sie vermeidest<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Diese Fallstricke kosten bei der Erstinstallation regelm\u00e4\u00dfig Stunden und frustrieren Einsteiger:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Fehler<\/th><th>Symptom<\/th><th>Ursache<\/th><th>L\u00f6sung<\/th><\/tr><\/thead><tbody><tr><td><code>vm.max_map_count<\/code> zu niedrig<\/td><td>Wazuh Indexer startet nicht<\/td><td>OpenSearch-Anforderung nicht erf\u00fcllt<\/td><td><code>sysctl -w vm.max_map_count=262144<\/code> + \/etc\/sysctl.conf<\/td><\/tr><tr><td>Swap aktiviert<\/td><td>Indexer-Timeouts, schlechte Performance<\/td><td>OpenSearch braucht kein Swap<\/td><td><code>swapoff -a<\/code> + \/etc\/fstab bereinigen<\/td><\/tr><tr><td>Port 1514\/1515 blockiert<\/td><td>Agent &#8220;Never connected&#8221;<\/td><td>Firewall blockiert Enrollment-Port<\/td><td>UFW\/iptables: Port 1514 und 1515 \u00f6ffnen<\/td><\/tr><tr><td>Falsche Zeitzone auf Agenten<\/td><td>Timestamps falsch, Korrelation schl\u00e4gt fehl<\/td><td>NTP nicht aktiv oder falsche Zone<\/td><td><code>timedatectl set-ntp true<\/code> auf allen Hosts<\/td><\/tr><tr><td>Eigene Regeln in \/ruleset\/ gespeichert<\/td><td>Regeln nach Update verschwunden<\/td><td>Update \u00fcberschreibt \/ruleset\/<\/td><td>Nur <code>\/var\/ossec\/etc\/rules\/local_rules.xml<\/code> verwenden<\/td><\/tr><tr><td>Active Response ohne Whitelist<\/td><td>Admin-IPs werden gesperrt<\/td><td>Eigene IPs nicht ausgenommen<\/td><td><code>&lt;white_list&gt;<\/code> f\u00fcr interne Netze setzen<\/td><\/tr><tr><td>Dashboard-Zertifikat abgelaufen<\/td><td>Browser-Fehler 525 nach einem Jahr<\/td><td>Selbst signierte Certs (1 Jahr G\u00fcltigkeit)<\/td><td>Zertifikate mit wazuh-certs-tool.sh erneuern<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kritischer-pitfall-pseudo-dateisysteme-in-fim-ueberwachen\">Kritischer Pitfall: Pseudo-Dateisysteme in FIM \u00fcberwachen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ein h\u00e4ufiger Fehler bei der FIM-Konfiguration ist es, <code>\/proc<\/code> oder <code>\/sys<\/code> in die \u00dcberwachungsliste aufzunehmen. Diese Pseudo-Dateisysteme \u00e4ndern sich st\u00e4ndig (Tausende \u00c4nderungen pro Sekunde), \u00fcberfluten das Dashboard mit False Positives und verursachen hohe CPU-Last auf dem Agenten (<code>wazuh-syscheckd<\/code>-Prozess). Schlie\u00dfe sie immer explizit aus:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;!-- Immer diese Ausnahmen in syscheck setzen --&gt;\n&lt;ignore type=\"sregex\"&gt;^\/proc&lt;\/ignore&gt;\n&lt;ignore type=\"sregex\"&gt;^\/sys&lt;\/ignore&gt;\n&lt;ignore type=\"sregex\"&gt;^\/dev&lt;\/ignore&gt;\n&lt;ignore type=\"sregex\"&gt;^\/run&lt;\/ignore&gt;<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wazuh-siem-vs-splunk-vs-elk-stack-direkter-vergleich\">Wazuh SIEM vs. Splunk vs. ELK Stack: Direkter Vergleich<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh positioniert sich als sicherheitsspezialisierte, kostenfreie Alternative zu Splunk und zum generischen ELK-Stack. Der wichtigste Unterschied: Wazuh wurde von Grund auf als Sicherheitsplattform gebaut, w\u00e4hrend ELK ein generisches Log-Analyse-Tool ist und Splunk erst durch Erweiterungen Sicherheitsfunktionen erh\u00e4lt.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Kriterium<\/th><th>Wazuh 4.9<\/th><th>Splunk Enterprise<\/th><th>ELK Stack 8.x<\/th><\/tr><\/thead><tbody><tr><td>Kosten (100 Agenten\/Jahr)<\/td><td>0 \u20ac (Open Source)<\/td><td>ca. 47.000 $<\/td><td>0 \u20ac (Basis) \/ 10.560 $ (Elastic Security)<\/td><\/tr><tr><td>MITRE ATT&amp;CK-Mapping<\/td><td>Eingebaut, 3.000+ Regeln<\/td><td>Erweiterung (MITRE ATT&amp;CK App)<\/td><td>Nur mit Elastic Security<\/td><\/tr><tr><td>Vulnerability Detection<\/td><td>Eingebaut (NVD, RedHat, Canonical)<\/td><td>Kostenpflichtige Add-ons<\/td><td>Nicht eingebaut<\/td><\/tr><tr><td>File Integrity Monitoring<\/td><td>Eingebaut, Echtzeit<\/td><td>Add-on (Splunk UBA)<\/td><td>Nicht eingebaut<\/td><\/tr><tr><td>Active Response<\/td><td>50+ eingebaute Skripte<\/td><td>SOAR-Integration n\u00f6tig<\/td><td>Nicht eingebaut<\/td><\/tr><tr><td>Endpoint-Agent<\/td><td>Eigener Lightweight-Agent<\/td><td>Splunk UF\/HF<\/td><td>Beats\/Elastic Agent<\/td><\/tr><tr><td>Setup-Aufwand<\/td><td>45 Min (All-in-One-Skript)<\/td><td>1-3 Tage<\/td><td>4-8 Stunden (Basis)<\/td><\/tr><tr><td>Max. skalierbar<\/td><td>100.000+ (Cluster)<\/td><td>Unbegrenzt (Splunk Cloud)<\/td><td>Unbegrenzt (Managed)<\/td><\/tr><tr><td>NIS-2-Compliance<\/td><td>Eingebaut (GDPR, PCI, NIS-2)<\/td><td>Mit Enterprise Security App<\/td><td>Nur mit kostenpfl. Erweiterung<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr KMUs und Organisationen ohne dediziertes SOC-Team ist Wazuh die beste Wahl: es liefert sofort einsetzbare Sicherheitsfunktionen ohne Lizenzkosten und ohne tiefes SIEM-Expertenwissen. Splunk \u00fcberzeugt bei Enterprise-Deployments mit komplexen Korrelationsanforderungen und dediziertem Analyse-Team. Der ELK-Stack eignet sich, wenn die prim\u00e4re Anforderung Log-Analyse f\u00fcr Anwendungen ist und Sicherheits\u00fcberwachung sekund\u00e4r bleibt. Wazuh und ELK k\u00f6nnen kombiniert werden: Wazuh-Indexer basiert auf OpenSearch (einem OpenSearch-Fork), und Wazuh-Alerts lassen sich in einen separaten ELK-Stack weiterleiten.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"hochverfuegbarkeit-wazuh-manager-cluster-einrichten\">Hochverf\u00fcgbarkeit: Wazuh Manager-Cluster einrichten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr Produktionsumgebungen mit Verf\u00fcgbarkeitsanforderungen empfiehlt sich ein Wazuh-Manager-Cluster mit mindestens zwei Knoten (Master + Worker). Ein Ausfall des Single-Node-Setups bedeutet blinde Flecken in der Sicherheitsprotokollierung. Der Manager-Cluster funktioniert im Master\/Worker-Modell: der Master verwaltet die Konfiguration und Agenten-Zuordnung, Worker-Knoten verarbeiten die Agenten-Events.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Cluster-Konfiguration auf dem Master-Node\n# \/var\/ossec\/etc\/ossec.conf (Master)\n&lt;cluster&gt;\n  &lt;name&gt;wazuh-cluster-prod&lt;\/name&gt;\n  &lt;node_name&gt;master-node&lt;\/node_name&gt;\n  &lt;node_type&gt;master&lt;\/node_type&gt;\n  &lt;key&gt;$(openssl rand -hex 16)&lt;\/key&gt;\n  &lt;port&gt;1516&lt;\/port&gt;\n  &lt;bind_addr&gt;0.0.0.0&lt;\/bind_addr&gt;\n  &lt;nodes&gt;\n    &lt;node&gt;192.168.1.10&lt;\/node&gt;\n    &lt;node&gt;192.168.1.11&lt;\/node&gt;\n  &lt;\/nodes&gt;\n  &lt;hidden&gt;no&lt;\/hidden&gt;\n  &lt;disabled&gt;no&lt;\/disabled&gt;\n&lt;\/cluster&gt;\n\n# Auf Worker-Nodes: node_type auf \"worker\" setzen\n# Cluster-Status \u00fcberwachen:\nsudo \/var\/ossec\/bin\/cluster_control -l\n\n# Erwartete Ausgabe:\n# NAME         TYPE    VERSION  ADDRESS\n# master-node  master  4.9.0    192.168.1.10\n# worker-node  worker  4.9.0    192.168.1.11<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Cluster-Key muss auf allen Knoten identisch sein. Generiere ihn einmalig mit <code>openssl rand -hex 16<\/code> und verteile ihn sicher (z.B. \u00fcber HashiCorp Vault oder Ansible Vault). Ein kompromittierter Cluster-Key erm\u00f6glicht es einem Angreifer, einen gef\u00e4lschten Worker-Knoten einzuschleusen und Alerts zu manipulieren. Wechsle den Cluster-Key alle 90 Tage oder nach mutma\u00dflicher Kompromittierung.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"8-troubleshooting-tipps-fuer-wazuh-siem-probleme\">8 Troubleshooting-Tipps f\u00fcr Wazuh SIEM Probleme<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>1. Agent zeigt &#8220;Never connected&#8221; im Dashboard.<\/strong> Pr\u00fcfe die Manager-IP-Adresse in <code>\/var\/ossec\/etc\/ossec.conf<\/code> auf dem Agenten. Teste die Port-Erreichbarkeit mit <code>telnet 192.168.1.10 1514<\/code> und <code>telnet 192.168.1.10 1515<\/code>. Falls telnet nicht verf\u00fcgbar: <code>nc -zv 192.168.1.10 1514<\/code>. Pr\u00fcfe die UFW-Regeln auf dem Manager: <code>sudo ufw status verbose<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. Dashboard zeigt &#8220;No results&#8221; obwohl Agenten aktiv sind.<\/strong> Pr\u00fcfe den Indexer-Cluster-Status: <code>curl -k -u admin:PASSWORT https:\/\/localhost:9200\/_cat\/health<\/code>. Ein &#8220;red&#8221; Status bedeutet nicht beschreibbare Indizes. H\u00e4ufigste Ursache: Festplatte zu \u00fcber 85 % belegt (OpenSearch Flood Watermark). L\u00f6sung: Speicher freimachen oder ILM-L\u00f6schpolicy versch\u00e4rfen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. Wazuh Indexer startet nach Update nicht.<\/strong> Pr\u00fcfe das Journal: <code>journalctl -u wazuh-indexer -n 200 --no-pager<\/code>. OpenSearch-Major-Updates erfordern manchmal Index-Migration. Der Fehler &#8220;index.version.created&#8221; zeigt veraltete Index-Mappings. L\u00f6sung: Indizes mit veralteten Mappings l\u00f6schen (au\u00dfer Produktionsdaten) oder mit einer Snapshot-Strategie migrieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>4. Zu viele False-Positive-Alerts \u00fcberfluten das Dashboard.<\/strong> Nutze <code>\/var\/ossec\/bin\/wazuh-logtest<\/code>, um problematische Protokollzeilen durch das Regelwerk zu testen und die ausl\u00f6sende Regel zu identifizieren. Erh\u00f6he den Level-Schwellenwert der betroffenen Regel um 2-3 Stufen in <code>local_rules.xml<\/code> oder f\u00fcge eine Ausnahme-Regel mit <code>overwrite=\"yes\"<\/code> hinzu.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>5. Windows-Agent sendet nach Windows-Update keine Events mehr.<\/strong> Windows Defender kann den Wazuh-Agent-Prozess nach Updates blockieren. F\u00fcge den Wazuh-Installationspfad (<code>C:\\Program Files (x86)\\ossec-agent\\<\/code>) als Ausnahme in Windows Defender Antivirus ein. Pr\u00fcfe im Windows Event Log, ob der WazuhSvc-Service einen Startfehler zeigt (Event ID 7000).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>6. Hohe CPU-Last durch wazuh-syscheckd-Prozess.<\/strong> FIM-Konfiguration \u00fcberwacht zu viele Dateien oder zu h\u00e4ufig. Pr\u00fcfe, ob <code>\/proc<\/code>, <code>\/sys<\/code> oder <code>\/dev<\/code> versehentlich \u00fcberwacht werden. Erh\u00f6he <code>&lt;frequency&gt;<\/code> auf 43200 (12 Stunden) f\u00fcr Nicht-Echtzeit-Verzeichnisse. Setze <code>&lt;max_files_per_second&gt;50&lt;\/max_files_per_second&gt;<\/code> f\u00fcr CPU-Schonung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>7. Dashboard-Timeout bei vielen Agenten und Abfragen.<\/strong> Erh\u00f6he den OpenSearch-Request-Timeout in <code>\/etc\/wazuh-dashboard\/opensearch_dashboards.yml<\/code>: <code>opensearch.requestTimeout: 120000<\/code>. Bei mehr als 500 Agenten sollte der Indexer mit 3 Knoten geclustert werden. \u00dcberpr\u00fcfe au\u00dferdem, ob Abfragen zu breite Zeitfenster (z.B. &#8220;Letzte 90 Tage&#8221;) abfragen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>8. API-Aufrufe schlagen mit &#8220;401 Unauthorized&#8221; fehl.<\/strong> Wazuh-API-JWT-Tokens laufen nach 900 Sekunden (15 Minuten) ab. Skripte m\u00fcssen Tokens regelm\u00e4\u00dfig erneuern. Pr\u00fcfe die Token-G\u00fcltigkeit mit <code>jwt.io<\/code> (Decode des Bearer-Tokens). F\u00fcr lang laufende Automatisierungen: erh\u00f6he die Token-Laufzeit in <code>\/var\/ossec\/api\/configuration\/api.yaml<\/code> unter <code>auth_token_exp_timeout<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wazuh-siem-fuer-nis-2-und-kritis-dachgesetz-in-deutschland\">Wazuh SIEM f\u00fcr NIS-2 und KRITIS-Dachgesetz in Deutschland<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Deutsche Unternehmen stehen 2026 unter erheblichem Regulierungsdruck. Das <strong>NIS-2-Umsetzungsgesetz<\/strong> betrifft 29.500 Organisationen und schreibt technische Sicherheitsma\u00dfnahmen, Protokollierung und Vorfallsmeldung innerhalb von 24 Stunden vor. Das <strong>KRITIS-Dachgesetz<\/strong> mit Deadline 17. Juli 2026 versch\u00e4rft die Anforderungen f\u00fcr kritische Infrastrukturen mit Bu\u00dfgeldern bis 1 Million Euro.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh adressiert konkrete NIS-2-Anforderungen aus Artikel 21: Das FIM-Modul liefert die nach BSI-Grundschutz-Baustein OPS.1.1.5 geforderte Integrit\u00e4ts\u00fcberwachung. Das Vulnerability-Detection-Modul unterst\u00fctzt das Patch-Management nach BSI-Grundschutz-Baustein OPS.1.1.3. Die Active-Response-Funktion erm\u00f6glicht automatisierte Gegenma\u00dfnahmen nach DER.2.1 (Behandlung von Sicherheitsvorf\u00e4llen). Die Compliance-Reports im Dashboard dokumentieren den Sicherheitsstatus f\u00fcr externe Audits nach ISO 27001 und BSI-Grundschutz.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr vollst\u00e4ndige NIS-2-Konformit\u00e4t empfiehlt sich eine Aufbewahrungsdauer von 12 Monaten (Verl\u00e4ngerung \u00fcber ILM), t\u00e4gliche Compliance-Reports als PDF (automatisierbar per API) und die Integration mit einem Ticket-System f\u00fcr Vorfallsmeldungen (TheHive oder Jira) mit definierten SLAs f\u00fcr kritische Alerts. Die automatische 24-Stunden-Meldepflicht bei erheblichen Sicherheitsvorf\u00e4llen l\u00e4sst sich durch Wazuh-Active-Response-Skripte an das BSI-Meldungsportal ankoppeln.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fortgeschrittene-optimierungen-fuer-langzeitbetrieb\">Fortgeschrittene Optimierungen f\u00fcr Langzeitbetrieb<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Index Lifecycle Management (ILM) konfigurieren:<\/strong> Ohne ILM f\u00fcllt die t\u00e4gliche Indexerstellung die Festplatte innerhalb von Wochen. Richte \u00fcber das Dashboard unter &#8220;Stack Management > Index Lifecycle Policies&#8221; einen automatischen Rollover (nach 30 GB oder 30 Tagen) und eine automatische L\u00f6schung (nach 90 oder 365 Tagen) ein. F\u00fcr NIS-2 nutze eine 12-Monats-Retention-Policy.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Agenten-Gruppen f\u00fcr skalierbare Konfiguration:<\/strong> Statt jede Agent-Konfiguration manuell zu verwalten, nutze Wazuh-Gruppen. Erstelle Gruppen (<code>linux-servers<\/code>, <code>windows-desktops<\/code>, <code>docker-hosts<\/code>, <code>web-servers<\/code>) \u00fcber die API oder das Dashboard. Konfigurations\u00e4nderungen werden automatisch an alle Gruppenagenten verteilt, ohne jeden Host einzeln anzupassen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Alert-Aggregation mit Deduplication:<\/strong> Wiederholende Events aus cron-Jobs, Backup-Software oder Log-Rotation k\u00f6nnen das Dashboard \u00fcberfluten. Nutze <code>&lt;frequency&gt;<\/code> und <code>&lt;timeframe&gt;<\/code> in Regeln: <code>&lt;same_source_ip \/&gt;<\/code> b\u00fcndelt wiederholende Alerts von der gleichen Quelle zu einem einzigen aggregierten Alert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Automatische Regelupdates via Cron:<\/strong> Wazuh ver\u00f6ffentlicht w\u00f6chentlich aktualisierte Regeln f\u00fcr neue CVEs und Angriffsmuster. Automatisiere Updates mit einem Cron-Job, der nachts l\u00e4uft und nach dem Update den Manager-Reload ausl\u00f6st: <code>0 2 * * 0 apt update && apt install --only-upgrade wazuh-manager -y && \/var\/ossec\/bin\/wazuh-control reload<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"verwandte-artikel\">Verwandte Artikel<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"weiterfuehrende-lektuere-auf-shattered-io\">Weiterf\u00fchrende Lekt\u00fcre auf shattered.io<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/de\/splunk-vs-elk-stack\/\">Splunk vs ELK Stack: $47.000 vs 0 \u20ac im SIEM-Vergleich [2026]<\/a><\/li>\n<li><a href=\"\/de\/crowdsec-vs-fail2ban\/\">CrowdSec vs Fail2ban: 13.941 vs 18.007 Stars [2026]<\/a><\/li>\n<li><a href=\"\/de\/pfsense-vs-opnsense\/\">pfSense vs OPNsense: Open-Source-Firewall 940 Mbps [2026]<\/a><\/li>\n<li><a href=\"\/de\/nmap-tutorial-netzwerk-scanner\/\">Nmap-Tutorial: Netzwerke scannen in 12 Schritten [2026]<\/a><\/li>\n<li><a href=\"\/de\/docker-container-absichern-tutorial\/\">Docker Container absichern: 12 Schritte, 45 Min [2026]<\/a><\/li>\n<li><a href=\"\/de\/nis2-umsetzungsgesetz-deutschland-2026\/\">NIS-2 Deutschland: 29.500 Firmen, \u20ac10 Mio. Strafe [2026]<\/a><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Externe Ressourcen: <a href=\"https:\/\/documentation.wazuh.com\/current\/index.html\" target=\"_blank\" rel=\"noopener\">Wazuh-Dokumentation (offiziell)<\/a>, <a href=\"https:\/\/github.com\/wazuh\/wazuh\" target=\"_blank\" rel=\"noopener\">Wazuh auf GitHub<\/a>, <a href=\"https:\/\/attack.mitre.org\/\" target=\"_blank\" rel=\"noopener\">MITRE ATT&amp;CK Framework<\/a>, <a href=\"https:\/\/wazuh.com\/platform\/siem\/\" target=\"_blank\" rel=\"noopener\">Wazuh SIEM-Plattform<\/a>, <a href=\"https:\/\/documentation.wazuh.com\/current\/getting-started\/components\/index.html\" target=\"_blank\" rel=\"noopener\">Wazuh-Komponenten (Architektur\u00fcbersicht)<\/a>, <a href=\"https:\/\/www.bsi.bund.de\/DE\/Themen\/Unternehmen-und-Organisationen\/Informationen-und-Empfehlungen\/Empfehlungen-nach-Angriffszielen\/Webanwendungen\/webanwendungen_node.html\" target=\"_blank\" rel=\"noopener\">BSI: IT-Sicherheitsempfehlungen<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"faq-wazuh-siem\">FAQ: Wazuh SIEM<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ist-wazuh-wirklich-kostenlos-oder-gibt-es-versteckte-kosten\">Ist Wazuh wirklich kostenlos, oder gibt es versteckte Kosten?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh ist vollst\u00e4ndig Open Source unter der GPL-2.0-Lizenz. Das gilt f\u00fcr alle Komponenten: Manager, Indexer, Dashboard und Agenten. Es gibt keine Agentenlizenzen, keine Datenmengen-Beschr\u00e4nkungen und keine kommerziellen Features hinter einer Paywall. Wazuh Inc. bietet kommerzielle Support-Pakete an, die Hosting, professionellen Support und dedizierte Threat-Intelligence-Feeds einschlie\u00dfen. Die Software selbst bleibt ohne jede Einschr\u00e4nkung kostenlos nutzbar.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-viele-agenten-kann-ein-einzelner-wazuh-server-verwalten\">Wie viele Agenten kann ein einzelner Wazuh-Server verwalten?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Single-Node-Wazuh-Server mit 8 CPU-Kernen und 16 GB RAM verwaltet nach Wazuh-Dokumentation zuverl\u00e4ssig bis zu 500 Agenten. Mit einem Manager-Cluster (Master + Worker) skaliert Wazuh auf \u00fcber 100.000 Agenten. Der Wazuh-Indexer ist der Flaschenhals bei der Skalierung; f\u00fcr mehr als 1.000 Agenten empfiehlt Wazuh einen 3-Knoten-OpenSearch-Cluster mit dedizierten Coordinator-Nodes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kann-wazuh-einen-kommerziellen-edr-ersetzen\">Kann Wazuh einen kommerziellen EDR ersetzen?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh liefert viele Kernfunktionen eines EDR: Prozess\u00fcberwachung, FIM, Schwachstellenerkennung und Active Response. F\u00fcr KMUs ist es ein vollwertiger EDR-Ersatz. Enterprise-EDR-Produkte wie CrowdStrike Falcon oder SentinelOne bieten dar\u00fcber hinaus ML-basierte Verhaltensanalyse, automatische Forensik-Snapshots und integrierte Threat-Intelligence-Feeds mit IOC-Matching in Echtzeit. Wazuh l\u00e4sst sich mit MISP oder OTX-Threat-Intelligence-Feeds erweitern, erfordert aber mehr Konfigurationsaufwand als kommerzielle L\u00f6sungen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-lange-dauert-die-einrichtung-in-einem-unternehmensumfeld-realistisch\">Wie lange dauert die Einrichtung in einem Unternehmensumfeld realistisch?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Die reine Server-Installation dauert 45 Minuten. Das Onboarding der ersten 10 Agenten ben\u00f6tigt weitere 1-2 Stunden. Die Erstanpassung der Regelkonfiguration an die Unternehmensumgebung (False-Positive-Tuning, eigene Regelkonfiguration, Integrations-Setup) dauert in einem 50-Personen-Unternehmen typischerweise 2 bis 3 Werktage. Die laufende Pflege betr\u00e4gt ca. 2 bis 4 Stunden pro Woche f\u00fcr einen erfahrenen Administrator.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"kann-wazuh-cloud-dienste-wie-aws-cloudtrail-ueberwachen\">Kann Wazuh Cloud-Dienste wie AWS CloudTrail \u00fcberwachen?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja. Wazuh hat eingebaute Module f\u00fcr AWS CloudTrail, AWS S3, AWS Config, AWS GuardDuty, Azure Active Directory, Azure Log Analytics, Azure Activity und Google Cloud Pub\/Sub. Die Protokolle werden direkt \u00fcber die jeweiligen Cloud-APIs abgeholt, ohne einen Agenten auf Cloud-Infrastruktur zu ben\u00f6tigen. F\u00fcr Microsoft 365 gibt es das Microsoft Graph API-Modul, das Teams-, Exchange- und SharePoint-Aktivit\u00e4ten erfasst.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"welche-protokollformate-versteht-wazuh-nativ\">Welche Protokollformate versteht Wazuh nativ?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Wazuh versteht nativ \u00fcber 400 Protokollformate: Syslog (RFC 3164 und 5424), Apache\/Nginx\/IIS-Zugriffsprotokolle, Windows Event Log (EVTX und XML), MySQL\/PostgreSQL Query Logs, Cisco IOS, Palo Alto PAN-OS, Fortinet FortiGate, Auditd, Suricata-EVE-JSON, Zeek (fr\u00fcher Bro), OpenVPN und viele mehr. F\u00fcr unbekannte Formate definierst du eigene Decoder mit regul\u00e4ren Ausdr\u00fccken in <code>\/var\/ossec\/etc\/decoders\/local_decoder.xml<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-sichere-ich-das-wazuh-dashboard-gegen-unbefugten-zugriff-ab\">Wie sichere ich das Wazuh-Dashboard gegen unbefugten Zugriff ab?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Das Dashboard l\u00e4uft standardm\u00e4\u00dfig auf Port 443 mit einem selbst signierten Zertifikat. Empfohlene H\u00e4rtungsma\u00dfnahmen: Erstens, ersetze das selbst signierte Zertifikat durch ein Let&#8217;s-Encrypt- oder Unternehmens-CA-Zertifikat. Zweitens, aktiviere TOTP-basierte Zwei-Faktor-Authentifizierung \u00fcber das OpenSearch Security Plugin. Drittens, beschr\u00e4nke den Dashboard-Zugriff per iptables oder Nginx Reverse Proxy auf definierte Admin-IP-Ranges. Viertens, \u00e4ndere alle Standard-Credentials aus der Passwortdatei unmittelbar nach der Installation und setze starke Passw\u00f6rter (min. 24 Zeichen).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Wazuh SIEM erkennt Angriffe, die andere Tools \u00fcbersehen. Das quelloffene Security-Information-and-Event-Management-System verarbeitet Protokolle von Tausenden Endpunkten, korreliert Ereignisse in Echtzeit und liefert Alerts nach dem MITRE ATT&amp;CK-Framework. In diesem Tutorial\u2026<\/p>\n","protected":false},"author":9,"featured_media":265,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/comments?post=264"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/264\/revisions"}],"predecessor-version":[{"id":266,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/264\/revisions\/266"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/media\/265"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/media?parent=264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/categories?post=264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/tags?post=264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}