Erkennung mit Wazuh und OPNsense — der Stack hinter der ersten Stunde

/01Begriff und Abgrenzung: Managed Detection ist kein Virenscanner mit Abo

Managed Detection ist der Dienst, der verdächtiges Verhalten in einer IT-Umgebung erkennt, bewertet und eine erste Reaktion einleitet — unabhängig davon, ob der Kunde ein eigenes Analystenteam hat. Das unterscheidet den Dienst von zwei Nachbarn, mit denen er oft verwechselt wird: Ein Virenschutz erkennt bekannte Schadsoftware auf einem einzelnen Gerät, ohne Ereignisse über mehrere Systeme hinweg zu verknüpfen. Ein reines Monitoring meldet, ob ein Server erreichbar ist und wie ausgelastet er ist — nicht, ob sich jemand unbefugt darauf anmeldet. Managed Detection korreliert SIEM-Daten aus mehreren Quellen und erkennt damit Muster, die auf keinem einzelnen System für sich genommen auffällig aussehen — ein Baustein von Managed Services, der ohne laufende Pflege genauso veraltet wie jeder andere.

Dieser Artikel behandelt den technischen Stack dahinter im Detail: Wazuh als Auswertungsplattform und OPNsense mit der Erkennungs-Engine Suricata als Sensor am Netzrand. Die geschäftliche Seite — Servicezeiten, was beim Kunden an Verantwortung bleibt, die vollständige Kostenrechnung gegenüber einem Eigenbetrieb — behandelt der Schwesterartikel zur Angriffserkennung ohne eigenes SOC ausführlicher; hier liegt der Schwerpunkt auf der Technik: wie ein Alarm überhaupt entsteht, was er bedeutet, und was in der ersten Stunde danach passiert. Für diesen Artikel wurden die Wazuh- und OPNsense-Dokumentation sowie die Leistungsbeschreibung des Managed SOC von HostSpezial im Volltext geprüft.

Ein durchgespieltes Beispiel trägt den Artikel: ein Fileserver in einer Umgebung mit rund 60 Arbeitsplätzen, der nachts beginnt, ungewöhnlich viele Dateien umzubenennen — ein typisches Vorläufersymptom einer Verschlüsselung durch Ransomware. An diesem Beispiel zeigen die folgenden Abschnitte, welche Komponente was sieht, welches Regel-Level der Vorgang auslöst, und was in der ersten Stunde nach dem Alarm tatsächlich passiert.

/02Der Stack: Wazuh als SIEM/XDR, OPNsense und Suricata als Sensor am Netzrand

Wazuh beschreibt sich in der eigenen Dokumentation als quelloffene Sicherheitsplattform, die XDR- und SIEM-Fähigkeiten vereint — Extended Detection and Response auf der einen Seite, zentrale Protokollauswertung auf der anderen. Die Architektur besteht aus vier Teilen: dem Indexer für Speicherung und Suche, dem Server, der Ereignisse auswertet und Regeln anwendet, dem Dashboard für Analysten, und dem Agenten, der auf Servern und Arbeitsplätzen läuft und Rohereignisse liefert. Zu den dokumentierten Fähigkeiten zählen Log-Datenanalyse, Dateiintegritätsprüfung, Schwachstellenerkennung, Sicherheitskonfigurationsbewertung und Threat Hunting — Bausteine, die einzeln wenig aussagen, aber zusammen ein Bild ergeben, das ein einzelnes Werkzeug nicht liefert.

Was Wazuh von sich aus nicht hat, ist Sicht auf den Netzwerkrand. Dafür sorgt OPNsense mit der Intrusion-Detection- und -Prevention-Funktion auf Basis von Suricata. Die offizielle OPNsense-Dokumentation unterscheidet klar: Ein IDS „beobachtet den Netzwerkverkehr auf verdächtige Muster und kann Betreiber alarmieren, wenn ein Muster zu bekanntem Verhalten passt" — ein IPS geht einen Schritt weiter und prüft jedes Paket beim Durchqueren einer Schnittstelle, um es bei Verdacht zu verwerfen. OPNsense bietet dafür drei Betriebsmodi: reine Beobachtung ohne Eingriff, ein Netmap-Modus mit aktivem Verwerfen über den Netmap-Treiber, und ein Divert-Modus, der verdächtige Pakete über Firewall-Regeln umleitet. Die kostenlose Regelbasis ET Open deckt laut Dokumentation ausdrücklich „nicht die volle Bandbreite" möglicher Signaturen ab — ein Punkt, der bei der Erwartungshaltung an den Grundschutz wichtig ist.

Die Kombination ist der eigentliche Punkt: Ein Agent auf dem Server sieht, dass sich ein Prozess ungewöhnlich verhält; Suricata am Netzrand sieht, dass derselbe Server kurz danach Daten an eine unbekannte Adresse sendet. Jedes Signal für sich ist ein Verdacht. Beide zusammen, zeitlich korreliert im SIEM, sind ein Befund.

/03Wie ein Alarm entsteht: von der Suricata-Zeile zur Wazuh-Regel

Technisch läuft das über mehrere Schichten. Suricata prüft Netzverkehr gegen Signaturen und schreibt Treffer als strukturierte EVE-JSON-Zeile; OPNsense sendet diese Zeile per Syslog weiter, laut Dokumentation mit der Einschränkung, dass verworfene Pakete nur an die interne Protokollierung gehen, nicht zwangsläufig an jeden externen Syslog-Empfänger. Auf der Wazuh-Seite verarbeitet ein Decoder das eingehende Ereignis, und eine Regel entscheidet über dessen Bedeutung. Jede Regel trägt ein Level zwischen 0 und 16: Level 0 bedeutet laut Dokumentation „keine Aktion, dient der Vermeidung von Fehlalarmen", Level 12 steht für ein „wichtiges Ereignis ... kann auf einen Angriff gegen eine bestimmte Anwendung hindeuten", Level 15 für einen schweren Angriff, bei dem laut Dokumentation „keine Chance auf einen Fehlalarm" mehr besteht.

Zwei Schwellenwerte entscheiden darüber, was ein Analyst überhaupt zu Gesicht bekommt: log_alert_level legt fest, ab welchem Level ein Ereignis überhaupt protokolliert wird — Standardwert 3 — und email_alert_level, ab welchem Level eine Benachrichtigung verschickt wird — Standardwert 12. Ereignisse unterhalb von Level 3 verschwinden damit im Grundrauschen, Ereignisse zwischen 3 und 11 stehen im Protokoll, ohne dass jemand sofort benachrichtigt wird, und erst ab 12 piept ein Postfach. Ein Managed-Detection-Dienst, der diese Schwellen nicht aktiv auf die jeweilige Umgebung abstimmt, meldet entweder zu viel — und Analysten werden taub für echte Treffer — oder zu wenig, weil relevante Stufe-10-Ereignisse im Rauschen untergehen.

# Wazuh-Regel mit MITRE-ATT&CK-Zuordnung (Auszug, Wazuh-Dokumentation)
<rule id="110011" level="10">
  <if_sid>61615</if_sid>
  <field name="win.eventdata.targetObject" type="pcre2">HKLM\\System\\CurrentControlSet\\Services\\PSEXESVC</field>
  <mitre>
    <id>T1543.003</id>
  </mitre>
</rule>

# Entsprechender Ausschnitt aus dem Alarm-JSON
"rule": {
  "mitre": {
    "technique": ["Windows Service"],
    "id": ["T1543.003"],
    "tactic": ["Persistence", "Privilege Escalation"]
  }
}

Der <mitre>-Tag ist kein Dekor. Er verbindet eine einzelne Regel mit einer katalogisierten Angriffstechnik — hier T1543.003, „Windows Service" im MITRE-ATT&CK-Framework, zugeordnet den Taktiken Persistence und Privilege Escalation. Ein Analyst, der einen Alarm mit dieser Kennung sieht, weiß sofort, in welcher Phase eines Angriffs er sich befindet, ohne die Regel selbst lesen zu müssen — und kann sie mit anderen Alarmen derselben Kette verknüpfen.

/04Typische Erkennungs-Use-Cases — mit Regel-Level und MITRE-Technik

In der Praxis wiederholen sich bei den meisten Mittelstandsumgebungen dieselben Grundmuster. Die folgende Tabelle zeigt vier davon mit der Quelle, die sie liefert, und der Größenordnung des Regel-Levels, mit dem Wazuh-Regelsätze üblicherweise auf solche Muster reagieren.

Wichtig an dieser Tabelle ist die dritte Spalte in Grautönen: Wazuhs Ruleset selbst vergibt feste Level für bekannte Muster — ein neues Konto mit Administratorrechten etwa landet in Regelsätzen üblicherweise deutlich über der E-Mail-Schwelle von 12 —, aber ein ungewöhnlicher Datenabfluss ist selten ein einzelner Treffer. Er entsteht erst durch Korrelation: viele kleine, für sich unauffällige Ereignisse, deren Summe ein Analyst oder eine Korrelationsregel erst als Muster erkennt. Das ist der Unterschied zwischen einer Signatur und echter Erkennung — eine Signatur meldet ein bekanntes Muster, Korrelation findet ein unbekanntes aus bekannten Teilen.

Für das Beispiel aus Abschnitt 1 heißt das konkret: Der Wazuh-Agent auf dem Fileserver meldet über seine Dateiintegritätsprüfung eine ungewöhnlich hohe Zahl veränderter Dateien in wenigen Minuten — für sich genommen ein Ereignis, das je nach Regel bereits im oberen Levelbereich landet. Lag dem Vorfall ein kompromittiertes Konto ohne zweiten Faktor zugrunde, zeigt der Verzeichnisdienst kurz zuvor eine Anmeldung von einem ungewöhnlichen Gerät oder zu ungewöhnlicher Zeit — ein zweites, eigenständig unauffälliges Ereignis, das erst in Verbindung mit der Dateiänderung zum eindeutigen Befund wird. Ohne Netzsegmentierung in VLANs hätte derselbe Vorgang zudem Nachbarsysteme erreichen können; die Firewall-Protokolle von OPNsense zeigen in einem solchen Fall häufig schon vorher ungewöhnliche interne Verbindungsversuche, die bei sauberer Segmentierung gar nicht erst möglich wären.

/05Active Response: Was automatisch passiert — und was nicht

Wazuh kann auf einen Alarm nicht nur hinweisen, sondern automatisch reagieren — die Funktion heißt Active Response und führt laut Dokumentation Skripte auf überwachten Endpunkten aus, sobald ein Alarm eine bestimmte Regel-ID, ein Level oder eine Regelgruppe auslöst. Konkrete Beispiele aus der Dokumentation: Skripte, die böswilligen Netzwerkzugriff blockieren, böswillige Dateien auf einem Endpunkt entfernen, SSH-Brute-Force-Versuche sperren, einen Agenten neu starten oder ein Linux-Benutzerkonto deaktivieren. Technisch gibt es zwei Varianten: stateless — eine einmalige Aktion ohne definiertes Ende — und stateful, bei der die Aktion nach einer festgelegten Zeitspanne automatisch wieder zurückgenommen wird, etwa eine temporäre IP-Sperre, die nach einer Stunde von selbst endet.

Das klingt nach voller Automatisierung, ist es aber bewusst nicht. Jede Active-Response-Regel ist eine Entscheidung, die vorher getroffen und konfiguriert werden muss — welche Regel-ID welches Skript auslöst, ist eine Frage, die ein Mensch vor dem ersten Alarm beantwortet, nicht während eines laufenden Vorfalls. Für risikoarme, eindeutige Muster wie eine erkannte Brute-Force-Attacke auf einen SSH-Port eignet sich eine automatische Sperre gut — der Schaden eines falsch gesperrten Zugriffs ist gering gegenüber dem Nutzen. Für eine Entscheidung wie „diesen Produktionsserver vom Netz trennen" ist Automatik der falsche Reflex: Das Risiko eines Fehlalarms mit Betriebsunterbrechung ist größer als der Zeitgewinn durch Automatisierung, und genau deshalb bleibt diese Eskalationsstufe in einem gut konfigurierten Managed-Detection-Setup eine Freigabe durch einen Analysten, nicht ein Skript.

/06Die erste Stunde nach einem Alarm: ein Ablauf in vier Phasen

Was in der ersten Stunde nach einem bestätigten Alarm passiert, folgt in einem funktionierenden Managed-Detection-Setup einem festen Muster, keiner Improvisation — am Beispiel des Fileservers aus Abschnitt 1 lässt sich das Minute für Minute durchgehen.

• Minute 0 bis 15 — Triage. Ein Analyst sieht den Alarm zu den massenhaften Dateiumbenennungen, prüft ihn gegen Kontext: welcher Agent, welche Regel, welches Level, welche MITRE-Technik, gab es Vorläufer-Ereignisse derselben Quelle — etwa die ungewöhnliche Anmeldung aus Abschnitt 4. HostSpezial nennt für diesen ersten Schritt eine mittlere Erkennungszeit (MTTD) unter 5 Minuten und eine Erstreaktion (MTTR) unter 15 Minuten.
• Minute 15 bis 30 — Eindämmung. Je nach vorab festgelegter Regel greift Active Response automatisch — etwa eine Netzwerksperre für den betroffenen Fileserver — oder ein Analyst leitet die Maßnahme manuell ein, etwa eine Kontosperrung im Verzeichnisdienst, über das sich der Angreifer vermutlich angemeldet hat.
• Minute 30 bis 50 — Korrelation. Weitere Quellen werden geprüft: Hat derselbe Agent noch andere Alarme ausgelöst, zeigt der OPNsense-Flow-Export ungewöhnliche Ziele, gibt es vergleichbare Muster auf anderen Systemen im selben Netzsegment. Hier entscheidet sich, ob es ein isoliertes Ereignis oder der Anfang einer Kette ist — bei einem Fileserver mit Verschlüsselungsverdacht ist das die entscheidende Frage, bevor überhaupt über eine Eindämmung hinausgehende Schritte gesprochen wird.
• Minute 50 bis 60 — Eskalation. Der Kunde wird über die vorher vereinbarte Kontaktkette informiert, mit dem, was bereits eingeleitet wurde — nicht mit einer offenen Frage, sondern mit einem Status und einer Empfehlung für den nächsten Schritt, etwa die Prüfung des letzten sauberen Backup-Standes.

Was in dieser Stunde ausdrücklich nicht passiert: eine vollständige forensische Aufklärung, wie weit ein Angreifer tatsächlich gekommen ist, und keine Wiederherstellung betroffener Systeme. Diese Abgrenzung ist keine Lücke im Dienst, sondern seine Definition — Erkennung und Erstreaktion sind etwas anderes als Incident-Response im vollen Umfang oder als Wiederherstellung, die beide eigene Prozesse und eigene Zuständigkeiten haben. Für den Fileserver aus dem Beispiel heißt das konkret: Innerhalb der ersten Stunde ist der Angriffsweg unterbrochen und der Kunde informiert — ob und welche Dateien tatsächlich wiederhergestellt werden müssen, klärt sich danach, über den eigenen Backup-Prozess.

/07Was HostSpezial im Managed Detection konkret übernimmt — und was nicht

HostSpezial betreibt die Erkennungsplattform für seine Kunden im Rechenzentrum der SÜC in Coburg, mit Ausweichstandort bei den Stadtwerken Neustadt, zertifiziert nach ISO/IEC 27001:2024. Übernommen werden laut Leistungsbeschreibung: der Betrieb der Wazuh-Plattform, die Auswertung und Bewertung von Alarmen durch Analysten rund um die Uhr, die Erstreaktion mit vereinbarten Eskalationsstufen, und die laufende Pflege des Regelwerks. Die Zahlen, mit denen HostSpezial das beziffert: mittlere Erkennungszeit unter 5 Minuten, Erstreaktion unter 15 Minuten, Aufbauzeit von einwöchigem Assessment plus zwei bis drei Wochen Integration und Tuning. Ein eigener Betrieb in vergleichbarer Tiefe braucht nach Anbieterangabe mindestens fünf Vollzeitstellen für echten 24/7-Betrieb, eine Setup-Investition zwischen 100.000 und 250.000 Euro und laufende Kosten von rund 420.000 Euro im Jahr zuzüglich 40.000 bis 120.000 Euro Lizenzen — gegenüber einem Einstieg ab 12.000 Euro im Jahr im Managed-Modell.

Was ausdrücklich nicht übernommen wird: Die Vereinbarung ist eine 24/7 besetzte Erkennungs- und Erstreaktionsschicht, keine 24/7-Zusage für jede denkbare Folgearbeit. Wiederherstellung von Systemen bleibt Aufgabe von Backup und IT-Betrieb. Die Entscheidung, ob ein Produktionsserver tatsächlich vom Netz geht, trifft am Ende der Kunde — das Analystenteam isoliert nach vorher vereinbarter Regel, es schreibt die Regel nicht selbst. Und das Team sieht nur, was angeschlossen ist: ein Gerät ohne Agenten, ein Cloud-Dienst ohne Protokollanbindung bleiben unsichtbar, unabhängig davon, wie gut die Plattform im Übrigen funktioniert. Diese Grenzen gehören vor Vertragsschluss auf den Tisch, nicht erst beim ersten Vorfall.

/08Wo es hakt: Grenzen von Wazuh und OPNsense als Erkennungsstack

Drei technische Grenzen gehören zur ehrlichen Einordnung, nicht nur zum Kleingedruckten.

ET Open deckt nicht alles ab

Die kostenlose Signaturbasis für Suricata ist nach eigener Beschreibung der Dokumentation „keine vollständige Abdeckung" — neue oder seltene Angriffsmuster, für die es noch keine veröffentlichte Signatur gibt, laufen durch, bis eine kommerzielle Erweiterung oder ein eigenes Regel-Update sie erfasst.

Regel-Tuning ist Dauerarbeit, kein Einmalaufwand

Ein Regelwerk, das bei der Einführung passend eingestellt wurde, veraltet mit jeder Softwareänderung in der überwachten Umgebung. Schwellenwerte wie log_alert_level und email_alert_level sind kein Konfigurationsschritt, der einmal passiert und dann vergessen werden kann — wer sie nicht pflegt, bekommt entweder zu viele Alarme, die niemand mehr liest, oder zu wenige, weil eine zu grobe Regel echte Treffer verschluckt.

Automatik hat eine Grenze, die bewusst gezogen ist

Active Response reagiert nur auf Muster, für die vorher eine Regel konfiguriert wurde. Ein neuartiger Angriffsweg, der keiner bekannten Regel entspricht, löst keine automatische Reaktion aus — er braucht einen Menschen, der das Muster zum ersten Mal erkennt, bevor daraus eine Regel wird.

Keine dieser Grenzen ist ein Grund, auf den Stack zu verzichten — sie sind der Grund, warum eine Plattform allein nicht reicht und ein laufend gepflegtes Regelwerk mit Analysten dahinter den Unterschied macht.

/09Wann sich der eigene Stack lohnt — und wann Managed Detection

Wazuh und OPNsense sind beide quelloffen und ohne Lizenzkosten nutzbar — das bedeutet nicht, dass der Eigenbetrieb für jeden Mittelständler die richtige Wahl ist.

Dafür spricht der eigene Betrieb

• Eine vorhandene IT-Abteilung mit Security-Erfahrung, die Kapazität für Regelpflege und mindestens Bürozeiten-Abdeckung hat, kann mit Wazuh und OPNsense ohne Lizenzkosten starten.
• Sehr spezifische, branchentypische Erkennungsmuster, die ein externer Dienstleister erst mühsam lernen müsste, lassen sich intern direkt in Regeln gießen.

Dagegen spricht der Eigenbetrieb — meist

• Echter 24/7-Betrieb braucht nach Anbieterangabe mindestens fünf Vollzeitstellen — für die meisten Betriebe mit ein bis zwei IT-Kräften ist das keine Fragestellung des Budgets, sondern des Personals, das nicht zu finden ist.
• Regel-Tuning ohne Erfahrung führt zu zu vielen oder zu wenigen Alarmen — die Plattform ist in Wochen aufgesetzt, die Fähigkeit, sie richtig einzustellen, wächst über Monate und über viele gesehene Vorfälle.
• Ein Richtwert aus der Praxis: Ab etwa 50 Mitarbeitern beginnt die Rechnung zugunsten eines Managed-Dienstes zu kippen — darunter trägt oft ein gut betriebenes Backup mit Endpoint-Schutz allein mehr zur Sicherheit bei als eine halb besetzte Erkennungsschicht.

In der Praxis ist die tragfähigste Lösung für die meisten Mittelständler nicht die Frage „Wazuh selbst betreiben oder nicht", sondern wer die Plattform betreibt — die Technik bleibt dieselbe, Open Source und ohne Lizenzgebühr, aber Betrieb, Regelpflege und die Besetzung der Nachtschicht sind eine andere Rechnung als der Download der Software.

/10Häufige Fragen