Wazuh SOC erste 30 Tage

WAZUH SOC von Null auf Produktiv — was ich in den ersten 30 Tagen gelernt habe

SEO-Titel: WAZUH SOC aufbauen: Meine ersten 30 Tage — Fehler, Setup & Erkenntnisse
Meta-Description: Von der ersten Installation zum produktiven Security Operations Center: Welche Fehler ich mit WAZUH gemacht habe, was das Buch von Frank Neugebauer gebracht hat, und wie KI-gestützte Auswertung den nächsten Schritt ermöglicht.
Tags: WAZUH, SIEM, SOC, IT-Sicherheit, Open Source, Klinik-IT, MITRE ATT&CK, KI, MCP, Active Response
Geschätzte Lesezeit: 12 Minuten

Ein Security Operations Center für eine Reha-Klinik aufbauen — ohne Budget für kommerzielle SIEM-Lösungen, ohne dediziertes Security-Team, aber mit dem klaren Auftrag: die IT-Infrastruktur absichern, bevor etwas passiert. Das war meine Ausgangslage.

Die Lösung: WAZUH — Open Source, mächtig, flexibel. Aber auch: steile Lernkurve, dürftige deutschsprachige Dokumentation, und eine Community, in der man sich vieles selbst zusammensuchen muss.

Bevor ich überhaupt die erste Config-Datei anfasste, habe ich mir sechs Monate Zeit genommen, das Buch „Cyber Security mit Wazuh" von Frank Neugebauer durchzuarbeiten — Kapitel für Kapitel, mit eigener Laborumgebung auf Proxmox. Das war die beste Entscheidung, die ich treffen konnte. Der zentrale Satz, der sich wie ein roter Faden durch das Buch zieht, hat auch meine Herangehensweise geprägt: „IT-Sicherheit ist keine Maßnahme, sondern ein Konzept."

Wer das hier liest, ist vermutlich in einer ähnlichen Situation: Du betreust eine IT-Infrastruktur (Klinik, Mittelstand, öffentliche Einrichtung), hast kein sechsstelliges Security-Budget, aber den Druck, etwas gegen wachsende Bedrohungen zu tun. Du hast von WAZUH gehört, vielleicht schon eine Testinstanz aufgesetzt — und fragst dich jetzt: Wie mache ich daraus ein echtes, produktives SOC?

Die kurze Antwort: Indem du kleiner anfängst, als du denkst. Die lange Antwort steht in den nächsten Abschnitten.

Was ich aus dem WAZUH-Buch gelernt habe — und was ich trotzdem falsch gemacht habe

Rückblickend hat mir das Buch in drei Bereichen die Augen geöffnet. Und trotzdem bin ich in genau diese Fallen getappt, weil Theorie und Praxis zwei verschiedene Paar Schuhe sind.

1. WAZUH ist kein Alarmsystem — es ist ein Sensor-Netzwerk

Das Buch macht von Anfang an klar: WAZUH ist in erster Linie ein Sammler von Sicherheitsinformationen im weitesten Sinne — CVEs, Compliance-Prüfungen, Installationsvorgaben, und erst dann ein Alarmgeber über seine fein justierbaren Agenten.

Mein Fehler: Ich habe es genau andersherum angegangen. Direkt nach der Installation alle Detection-Rules aktiviert und auf Alerts gewartet. Ergebnis: Über 1.000 Meldungen pro Tag auf einem Netz mit ca. 100 Endpoints. Alert-Fatigue vom Feinsten.

Was ich daraus gemacht habe: Ich bin zurück zum Buch-Konzept und habe WAZUH zuerst als Inventory- und Compliance-Tool genutzt, bevor ich mich an die Alarmierung gewagt habe. Konkret: SCA-Policies für alle Linux-Server ausgerollt und erstmal die Compliance-Abweichungen bereinigt. Erst als das Inventory stimmte und die Baselines sauber waren, habe ich schrittweise Detection-Rules aktiviert — dieses Mal selektiv und mit Bedacht.

2. Die Agenten sind das Herzstück — aber nur, wenn sie sauber konfiguriert sind

Das Buch widmet der Agent-Konfiguration zu Recht viel Raum. Die Agenten von WAZUH sind „fein granular justierbare Alarmgeber" — das klingt in der Theorie großartig, bedeutet in der Praxis aber: Du musst jeden Agenten verstehen und gezielt einstellen, sonst produzieren sie entweder nichts oder zu viel.

Mein Fehler: Ich hatte den ersten Agenten installiert, ossec.conf eingerichtet — und er tauchte einfach nicht im Manager auf. Der Manager lief in einem Docker-Container in einem separaten Netz, der Agent konnte den Hostname nicht auflösen. Dazu kam ein nicht gesetzter authd.pass, wodurch der Registrierungsdienst stillschweigend ablehnte — ohne hilfreiche Fehlermeldung.

Die Lösung: Nicht dem Erstbesten-Tutorial blind folgen. Mit vorab generierten Schlüsseln arbeiten statt mit automatischer Registrierung. Spart Debugging-Zeit und ist sicherer.

3. Der ganzheitliche Blick: WAZUH ist nur ein Baustein

Was mich am Buch am meisten beeindruckt hat, ist der Blick über WAZUH hinaus: TheHive für Fallbearbeitung, Shuffle für Workflow-Automatisierung — der Weg zu einem vollständigen SOC. Das Buch vermittelt: WAZUH allein ist kein SOC. Erst die Integration mit anderen Open-Source-Tools macht aus einer Alertsammlung ein echtes Operations Center.

Mein Fehler: In den ersten Wochen habe ich mich ausschließlich auf WAZUH konzentriert — Dashboards gebaut, Rules getuned, Alerts sortiert — und dabei komplett ausgeblendet, dass ich gar keinen Incident-Response-Prozess hatte. Was passiert mit einem Alert, nachdem ich ihn gesehen habe? Wer bearbeitet ihn? Wo wird dokumentiert, was unternommen wurde? All diese Fragen hatte ich null durchdacht.

Die Lösung (in Arbeit): TheHive + Cortex parallel aufgesetzt, um von reiner Erkennung zu tatsächlicher Reaktion zu kommen. Das ist kein 30-Tage-Projekt, sondern ein kontinuierlicher Aufbau. Aber die Richtung stimmt jetzt.

Und ja — der nächste logische Schritt ist die KI-gestützte Auswertung. Das Fundament dafür steht: Die Integration von WAZUH als MCP-Server, angebunden über AnythingLLM mit DeepSeek, hat funktioniert — mit echtem Datenzugriff, ohne Simulation. Das nächste Kapitel wird die automatisierte Triage-Unterstützung und intelligente Korrelation von Sicherheitsereignissen sein. Aber das ist Stoff für einen eigenen Artikel.

Mein produktives Minimal-Setup nach 30 Tagen

Nachdem ich die ersten Fehler hinter mir hatte und das Buch-Konzept verinnerlicht war, habe ich mich gefragt: Was ist das absolute Minimum, das ein produktives SOC braucht — ohne Ballast, ohne Deko-Dashboards, ohne Regeln, die in meiner Umgebung sowieso nie feuern?

Hier ist, was nach 30 Tagen stand:

Die drei Dashboards, die ich täglich nutze

1. Agent-Status-Übersicht — wie viele Endpoints sind online, wie viele mit veraltetem Agenten, wie viele seit 24h stumm? Zusätzlich SCA-Compliance-Bewertung pro Agent, um Baseline-Abweichungen sofort zu sehen.

2. Top-10-Alerts der letzten 24 Stunden — gefiltert auf meine Umgebung: alles unter Level 5 deaktiviert, syscheck auf /tmp stummgeschaltet, Windows-Regeln raus. Aus über 1.000 Alerts pro Tag wurden ca. 30-50, davon 5-10 wirklich relevant.

3. MITRE ATT&CK Heatmap — für den wöchentlichen strategischen Check: welche Taktiken häufen sich, wo zeichnen sich Muster ab?

Das Agent-Deployment: Testumgebung zuerst, dann schrittweise in Produktion

Das Buch begleitet den Leser beim Aufbau einer vollständigen Laborumgebung — und genau diesen Weg bin ich auch gegangen. Zuerst eine komplette Testumgebung auf Proxmox: WAZUH-Manager, ein paar Linux- und Windows-Agenten, verschiedene Angriffsszenarien simuliert, Alarme getestet und verstanden. Das hat mir die Sicherheit gegeben, die Konfiguration zu beherrschen, bevor ich überhaupt an die Produktivumgebung dachte.

Dann der entscheidende Schritt: eine frische, separate WAZUH-Instanz in der Produktivumgebung aufgesetzt — sauber, ohne Altlasten aus der Testphase. Kein einfaches Kopieren der Testkonfiguration, sondern bewusst von Null aufgesetzt, mit genau den Regeln, die ich in der Testumgebung als relevant identifiziert hatte.

Ab da habe ich die Agenten gruppenweise ausgerollt: erst eine kleine Pilotgruppe (3 Server, also nicht gleich den Exchange und DC), dann die nächste Gruppe (weitere Linux-Server), dann schrittweise weitere Endpoints. Zwischen jeder Gruppe habe ich 2-3 Tage Pause gelassen, um das Alert-Aufkommen zu beobachten und Fehlalarme zu tunen, bevor die nächste Welle Agenten dazukam.

Der nächste logische Schritt: TheHive und Cortex

WAZUH allein kann Alarme erkennen — aber was passiert danach? Die Bearbeitung, Dokumentation und Analyse von Vorfällen braucht mehr als ein Dashboard. Deshalb ist die Integration mit TheHive (Fallbearbeitung) und Cortex (automatisierte Analyse von Observables) der nächste große Schritt — und das Thema für den Folgeartikel. Aber das Grundprinzip, das ich aus dem Buch mitgenommen habe, gilt auch hier: Erst das Fundament verstehen, dann schrittweise erweitern.

USB-Port-Überwachung — das didaktische Highlight aus dem Buch

Eine der am besten erklärten Funktionen im Buch ist die USB-Port-Überwachung. Ich habe das direkt in mein Setup übernommen, weil es in einer Klinik-Umgebung mit sensiblen Patientendaten praxisrelevant ist: Wenn jemand einen USB-Stick an einen Klinik-PC steckt, wird das geloggt, der Event geht an WAZUH, und ich bekomme einen Alert. Konfiguriert in unter 30 Minuten, funktioniert seitdem zuverlässig — und gibt der Geschäftsführung ein konkretes Beispiel, warum das SOC wichtig ist.

Der Wendepunkt: Vom Alerts-Leser zum proaktiven SOC

Es gab diesen einen Moment, etwa in Woche drei, in dem mir klar wurde: Ich verbringe 80% meiner Zeit damit, Alerts zu lesen — und 20% damit, tatsächlich etwas zu tun. Das Verhältnis musste sich umdrehen.

Active Response: Der erste Schritt zur Automatisierung

WAZUH kann nicht nur erkennen, sondern auch reagieren. Das war mir theoretisch aus dem Buch bekannt, aber ich hatte es wochenlang vor mir hergeschoben. Zu komplex, zu riskant, „das mache ich später".

n8n und Shuffle bieten sich an, ich bin aber noch nicht soweit.

Der nächste logische Schritt: KI-gestützte Auswertung

Wenn man erstmal anfängt, WAZUH nicht nur als Alarm-Sammler zu sehen, sondern als Datenplattform, ändert sich der Blick. Die nächste Frage war für mich nicht mehr „Wie kriege ich weniger Alerts?", sondern: „Wie kann ich die vorhandenen Daten intelligenter auswerten?"

Die Antwort liegt in der Anbindung von KI. Inzwischen ist es mir gelungen, den WAZUH-Server als echten MCP-Server (Model Context Protocol) anzubinden — mit realem Datenzugriff, ohne Simulation. Das bedeutet: Ich kann in natürlicher Sprache Fragen an mein SOC stellen. „Welche Agenten hatten in den letzten 24 Stunden die meisten kritischen Alerts?" — „Gibt es ein Muster bei den SSH-Angriffen der letzten Woche?" — „Zeig mir alle Events vom Typ X, korreliert mit MITRE ATT&CK Tactic Y."

Das ist kein Zukunftstraum, sondern funktioniert bereits — mit LLM oder Agenten und DeepSeek (z.Bs.) als Sprachmodell dahinter. Den konkreten Aufbau beschreibe ich in einem separaten Artikel, aber das Prinzip ist simpel: WAZUH wird über MCP als Datenquelle angebunden, und ein lokal laufendes KI-Modell kann direkt darauf zugreifen — keine Cloud, keine Daten, die das Haus verlassen, und trotzdem die volle Power moderner Sprachmodelle.

Was sich dadurch verändert hat

Rückblickend hat sich mein gesamter Arbeitsrhythmus in diesen 30 Tagen verschoben:

• Vor Woche 3: Morgens eingeloggt, 15 Alerts gescannt, 2-3 relevante manuell verfolgt, Rest ignoriert.
• Nach Woche 4: Morgens eine Zusammenfassung der kritischen Alerts (automatisch generiert), ein Blick aufs Agent-Dashboard, und dann Zeit für das, was wirklich zählt: Prävention, Härtung, neue Detections bauen.

Der Unterschied ist nicht die Technik allein — es ist die Erkenntnis, dass WAZUH ein Werkzeug ist, kein Selbstzweck. Oder um es mit dem Buch zu sagen: „IT-Sicherheit ist keine Maßnahme, sondern ein Konzept." Das SOC ist kein Produkt, das man einmal baut und dann abhakt. Es ist ein Prozess, der mit den ersten 30 Tagen beginnt — und danach jeden Tag weiterwächst.