Security-Stack mit Open Source
Bausteine statt Blackbox
Veröffentlicht in Ausgabe 04/2026 - SCHWERPUNKT
Ohne Open Source ist das Internet in seiner heutigen Form kaum vorstellbar. Gerade auch im Bereich Security sind bedeutende Tools entstanden. Netzwerk-IDS und Werkzeuge für die hostbasierte Überwachung, die Loganalyse und die automatisierte Reaktion stehen heute in einer Reife zur Verfügung, die vor wenigen Jahren noch kommerziellen Produkten vorbehalten waren. Der große Vorteil: Administratoren behalten die volle Kontrolle über Daten, Erkennungslogik und Integrationen – und können ihr Sicherheitssystem exakt an die eigene Infrastruktur anpassen.
Allerdings bringt diese Freiheit auch eine Herausforderung mit sich: Open Source liefert keine "Alles-in-einem"-Appliance. Ein wirksames Angriffserkennungssystem entsteht erst durch das gezielte Zusammenspiel mehrerer Komponenten – von Sensoren über Korrelation bis hin zur Reaktion. Wer lediglich einzelne Tools installiert, erzeugt schnell eine Flut von Meldungen, aber keine echte Sicherheit.
Die Lösung scheint auf den ersten Blick einfach: Ihr eigener modularer Security-Monitoring-Stack. Die isolierte Betrachtung einzelner Tools greift hier zu kurz; vielmehr gilt es, den Fokus auf Rollen, Datenflüssen und sinnvollen Kombinationen zu legen. Der vorliegende Beitrag geht zwei zentralen Fragen nach: Welche Bausteine brauchen Sie wirklich – und wie greifen sie sinnvoll ineinander? Wie sieht ein optimal auf die Unternehmensgröße und Anforderungen abgestimmter Stack konkret aus?
Ohne Open Source ist das Internet in seiner heutigen Form kaum vorstellbar. Gerade auch im Bereich Security sind bedeutende Tools entstanden. Netzwerk-IDS und Werkzeuge für die hostbasierte Überwachung, die Loganalyse und die automatisierte Reaktion stehen heute in einer Reife zur Verfügung, die vor wenigen Jahren noch kommerziellen Produkten vorbehalten waren. Der große Vorteil: Administratoren behalten die volle Kontrolle über Daten, Erkennungslogik und Integrationen – und können ihr Sicherheitssystem exakt an die eigene Infrastruktur anpassen.
Allerdings bringt diese Freiheit auch eine Herausforderung mit sich: Open Source liefert keine "Alles-in-einem"-Appliance. Ein wirksames Angriffserkennungssystem entsteht erst durch das gezielte Zusammenspiel mehrerer Komponenten – von Sensoren über Korrelation bis hin zur Reaktion. Wer lediglich einzelne Tools installiert, erzeugt schnell eine Flut von Meldungen, aber keine echte Sicherheit.
Die Lösung scheint auf den ersten Blick einfach: Ihr eigener modularer Security-Monitoring-Stack. Die isolierte Betrachtung einzelner Tools greift hier zu kurz; vielmehr gilt es, den Fokus auf Rollen, Datenflüssen und sinnvollen Kombinationen zu legen. Der vorliegende Beitrag geht zwei zentralen Fragen nach: Welche Bausteine brauchen Sie wirklich – und wie greifen sie sinnvoll ineinander? Wie sieht ein optimal auf die Unternehmensgröße und Anforderungen abgestimmter Stack konkret aus?
Schichten eines Security-Monitoring-Stacks
Ein modernes Angriffserkennungssystem besteht aus mehreren funktional getrennten Schichten, die gemeinsam ein belastbares Sicherheitsbild erzeugen. Jede dieser Schichten erfüllt eine eigene Aufgabe und beantwortet eine andere sicherheitsrelevante Fragestellung. Erst das Zusammenspiel dieser Ebenen ermöglicht es, Angriffe nicht nur zu erkennen, sondern sie auch einzuordnen, zu bewerten und angemessen darauf zu reagieren. Grundsätzlich lässt sich ein solcher Stack in vier Ebenen gliedern: Sensorik, Analyse und Erkennung, Korrelation und Kontextualisierung sowie Reaktion und Prävention. Dieses Modell ist unabhängig von konkreten Produkten und hat sich in der Praxis sowohl in kleinen als auch in größeren Umgebungen bewährt.
Die unterste Ebene bilden Sensoren, die Rohdaten erfassen. Im Netzwerk übernehmen diese Aufgabe Network-Based Intrusion Detection Systems, die den Datenverkehr analysieren, ohne selbst aktiv in die Kommunikation einzugreifen. Auf Hostebene liefern Agenten und lokale Monitoringkomponenten Informationen darüber, was auf einzelnen Systemen geschieht. Diese Daten bilden die Grundlage aller weiteren Auswertungen.
Im Bereich der netzwerkbasierten Angriffserkennung haben sich unterschiedliche Werkzeuge etabliert, die jeweils einen eigenen Ansatz verfolgen. Zeek [1], früher unter dem Namen Bro bekannt, ist dabei kein klassisches Intrusion Detection System. Statt Paketdaten mit festen Signaturen zu vergleichen, analysiert Zeek Netzwerkprotokolle semantisch und erzeugt strukturierte Ereignisse. Es protokolliert beispielsweise DNS-Abfragen, HTTP-Header oder TLS-Handshakes und macht so Kommunikationsbeziehungen sichtbar, die mit rein signaturbasierten Systemen oft verborgen bleiben. Zeek eignet sich besonders für die Analyse von Anomalien, für forensische Untersuchungen und zur langfristigen Beobachtung von Netzwerkverhalten. Die Stärke von Zeek liegt in der Tiefe und im Kontext, nicht in der unmittelbaren Alarmierung oder Blockierung.
Eine andere Rolle übernimmt Suricata [2]. Dieses Werkzeug ist ein klassisches IDS beziehungsweise IPS und arbeitet primär signaturbasiert. Suricata ist in der Lage, Netzwerkverkehr mit hoher Performance zu analysieren und bekannte Angriffsmuster zuverlässig zu erkennen. Durch Multi-Threading, moderne Protokollparser und die Unterstützung gängiger Regelwerke wie Emerging Threats Open eignet sich Suricata auch für Umgebungen mit hohem Durchsatz. Im IPS-Modus kann es darüber hinaus aktiv eingreifen und verdächtigen Verkehr blockieren. Suricata beantwortet damit eine andere Frage als Zeek: Es erkennt, ob ein bestimmter Datenstrom bekannten Angriffen ähnelt.
Snort [3] ist ein alter Bekannter und gilt als Pionier unter den Open-Source-IDS-Produkten. Auch wenn Snort in Bezug auf Skalierbarkeit und moderne Analysefunktionen hinter neuerer Software zurückbleibt, kommt es weiterhin in kleineren Umgebungen oder als zusätzlicher Sensor zum Einsatz. Seine Relevanz liegt heute vor allem in bestehenden Installationen und in Szenarien mit überschaubarem Netzwerkverkehr. In der Praxis zeigt sich, dass sich diese Werkzeuge sinnvoll ergänzen. Während Suricata konkrete Alarme auf bekannte Angriffsmuster liefert, erzeugt Zeek den notwendigen Kontext, um diese Alarme einzuordnen. Der parallele Einsatz beider Systeme führt zu einem deutlich besseren Verständnis dessen, was im Netzwerk tatsächlich geschieht.
Doch die netzwerkbasierte Erkennung allein reicht nicht aus. Sobald ein Angreifer ein System erfolgreich kompromittiert hat, verlagert sich die relevante Aktivität häufig auf die Hostebene. Hier setzt hostbasiertes Monitoring an. Wazuh [4] kombiniert mehrere Sicherheitsfunktionen in einer zentral verwalteten Plattform. Agenten auf den überwachten Systemen analysieren Logdateien, behalten die Integrität kritischer Dateien im Auge, erkennen verdächtige Prozesse und prüfen Systeme auf bekannte Schwachstellen oder Abweichungen von Sicherheitsrichtlinien. Dadurch lassen sich Manipulationen erkennen, die im Netzwerkverkehr nicht zwangsläufig sichtbar wären. Wazuh fungiert somit als Bindeglied zwischen klassischem HIDS und moderner host-basierter Angriffserkennung.
Optional lässt sich diese Ebene durch osquery [5] ergänzen. Das Tool ermöglicht es, Betriebssysteme über strukturierte Abfragen zu analysieren und eignet sich besonders für Inventarisierung, kontinuierliches Monitoring und Threat-Hunting-Szenarien. Es ersetzt keine hostbasierte Erkennung, erweitert diese jedoch um flexible Abfragemöglichkeiten.
Ganzheitlicher Blick
Die zahlreichen Ereignisse, die Netzwerk- und Hostsensoren erzeugen, entfalten ihren Nutzen erst dann vollständig, wenn sie auch zentral gesammelt und ausgewertet werden. Diese Aufgabe übernimmt die Korrelationsebene. Eine verbreitete Umgebung ist der Elastic Stack, bestehend aus Elasticsearch [6], Logstash [7] oder Filebeat [8] und Kibana [9]. Der Stack ermöglicht es, große Mengen an Logdaten zu speichern, zu durchsuchen und visuell aufzubereiten. Durch Regeln, Alarme und maschinelle Lernverfahren lassen sich aus einzelnen Ereignissen zusammenhängende Angriffsszenarien ableiten. Der Preis für diese Flexibilität ist ein nicht unerheblicher Ressourcenbedarf sowie eine steigende Komplexität mit wachsendem Datenvolumen.
Für kleinere Umgebungen bietet sich mit Grafana [10] und Loki [11] eine ressourcenschonendere Alternative. Diese Kombination eignet sich gut zur zentralen Logsammlung und Visualisierung, bietet jedoch weniger Möglichkeiten zur tiefgehenden Korrelation. Sie ist damit eher als Observability-Tool denn als vollwertiges SIEM zu verstehen.
Die oberste Schicht eines modernen Security-Monitoring-Stacks ist die Reaktion. Ziel ist es, erkannte Angriffe nicht nur zu melden, sondern automatisiert darauf zu reagieren. CrowdSec [12] verfolgt hier einen verhaltensbasierten Ansatz. Anhand von Logdaten erkennt das System typische Angriffsmuster wie Brute-Force-Versuche oder Scans und blockiert Angreifer automatisiert über angebundene Firewalls, Reverse Proxys oder Webserver.
Ein besonderes Merkmal ist der Community-Ansatz: Erkenntnisse aus einer Installation fließen anonymisiert in eine gemeinsame Threat-Intelligence-Datenbasis ein, von der alle Teilnehmer profitieren.
Für Organisationen mit höherem Reifegrad bieten sich zusätzlich Plattformen wie MISP [13] und TheHive [14] an. Sie ermöglichen eine strukturierte Verwaltung von Bedrohungsinformationen und ein koordiniertes Incident-Handling, sind jedoch in der Regel erst dann sinnvoll, wenn Prozesse und Zuständigkeiten klar definiert sind.
Welcher Stack für welchen Reifegrad?
Open-Source-Komponenten lassen sich schrittweise kombinieren, wobei der Einstieg vor allem Transparenz schafft. Dieser Ansatz passt zu kleineren Umgebungen oder Organisationen, die erstmals eine strukturierte Angriffserkennung etablieren. Ein netzwerkbasierter Sensor wie Suricata erkennt bekannte Angriffsmuster, während Wazuh auf ausgewählten Systemen hostbasierte Ereignisse erfasst. Eine zentrale Plattform sammelt und visualisiert die Logs, etwa mit dem Elastic Stack oder alternativ mit Grafana und Loki. Erste automatisierte Reaktionen blockieren mit CrowdSec wiederkehrende Angriffe.Mit wachsender Infrastruktur steigt der Bedarf an Kontext und Korrelation. In diesem Szenario ergänzt Zeek Suricata und liefert detaillierte Protokolldaten. Wazuh deckt mehr Systeme ab, zusätzliche Logquellen fließen in die Analyse ein. Der Elastic Stack übernimmt die zentrale Auswertung inklusive Alarmierung und Korrelation. Automatisierte Reaktionen bleiben Bestandteil des Konzepts, greifen jedoch gezielter, um Angriffsketten statt isolierter Einzelereignisse zu identifizieren.In reiferen Umgebungen entwickelt sich der Stack zu einem leichtgewichtigen Security Operations Center. Netzwerk- und Hostsensorik skalieren, Incident-Workflows und Threat Intelligence kommen hinzu, etwa über MISP und TheHive. Der Schwerpunkt verschiebt sich von neuen Werkzeugen hin zu klar definierten Prozessen, sauberer Dokumentation und kontinuierlicher Verbesserung. Ein überschaubares, gut verstandenes System entfaltet in der Praxis meist mehr Wirkung als eine komplexe, schwer beherrschbare Architektur.
Informationen gezielt verarbeiten
Vor dem Hintergrund der zuvor angestellten strategischen Überlegungen, stellt sich die Frage, wie diese Komponenten in der Praxis zusammenspielen. Eine funktionierende Angriffserkennung entsteht nicht durch die bloße Installation einzelner Werkzeuge, sondern durch einen definierten Datenfluss vom Sensor bis zur Reaktion. Dabei ist es weniger wichtig, jede mögliche Datenquelle einzubinden, als vielmehr die relevanten Informationen gezielt und nachvollziehbar zu verarbeiten.
Am Anfang dieses Datenflusses stehen die Sensoren. Im Netzwerk erfassen Systeme wie Suricata oder Zeek den Traffic typischerweise über einen SPAN-Port, einen Network Tap oder virtuell über Mirror-Interfaces in Cloud- und Hypervisor-Umgebungen. Suricata analysiert den Traffic signaturbasiert und erzeugt Alerts, wenn bekannte Angriffsmuster auftreten. Zeek verarbeitet denselben Verkehr protokollorientiert und erzeugt detaillierte Ereignisprotokolle, die Kommunikationsbeziehungen, Metadaten und Auffälligkeiten sichtbar machen. Beide Systeme liefern unterschiedliche, sich ergänzende Informationen über denselben Vorgang.
Parallel dazu erfassen hostbasierte Komponenten das Geschehen auf den einzelnen Systemen. Wazuh kommt hierfür über Agenten auf Servern, virtuellen Maschinen oder Containern zum Einsatz. Diese Agenten analysieren lokale Logdateien, überwachen die Integrität kritischer Dateien und melden sicherheitsrelevante Ereignisse an einen zentralen Manager. Während ein Netzwerk-IDS beispielsweise einen verdächtigen Loginversuch erkennt, kann Wazuh feststellen, ob dieser Versuch erfolgreich war und welche Prozesse anschließend gestartet wurden. Erst durch diese Kombination entsteht ein vollständiges Bild.
Die von Netzwerk- und Hostsensoren erzeugten Daten laufen anschließend in der Korrelationsebene zusammen. In vielen Umgebungen übernimmt der Elastic Stack diese Aufgabe. Leichtgewichtige Agenten wie Filebeat [15] oder andere Log-Shipper sammeln die Ereignisse und übertragen sie zentral an Elasticsearch. Dort werden sie indexiert, angereichert und für die weitere Analyse bereitgestellt. Dashboards in Kibana erlauben es, sowohl den aktuellen Zustand als auch historische Entwicklungen zu betrachten. Alternativ bietet sich für kleinere Installationen eine Kombination aus Grafana und Loki an, die den Einstieg erleichtert, jedoch weniger Möglichkeiten zur tiefgehenden Korrelation bereithält.
Der eigentliche Mehrwert entsteht in dieser Phase durch die Verknüpfung einzelner Ereignisse. Ein isolierter Alarm aus dem Netzwerk ist selten kritisch. Doch zeitlich und logisch mit einem fehlgeschlagenen Login, einer erfolgreichen Authentifizierung und einer anschließenden Änderung an Systemdateien kombiniert, entsteht ein belastbarer Verdacht auf einen Angriff. Moderne SIEM-Funktionen erlauben es, solche Zusammenhänge regelbasiert oder heuristisch zu erkennen und gezielt hervorzuheben. Damit reduziert sich die Anzahl irrelevanter Meldungen, während gleichzeitig die Aussagekraft der verbleibenden Alarme steigt.
Auf dem Weg zur Reaktion
Auf diese Analyse folgt die Alarmierung. Je nach Schweregrad und organisatorischem Reifegrad kann diese sehr unterschiedlich ausfallen. In einfachen Szenarien genügt eine Benachrichtigung per E-Mail oder Chat, um Administratoren auf einen Vorfall aufmerksam zu machen. In fortgeschritteneren Umgebungen werden Alarme priorisiert, gruppiert und an definierte Eskalationswege weitergeleitet. Alarme müssen dabei nicht nur technisch korrekt, sondern auch handlungsrelevant formuliert sein. Ein guter Alarm beantwortet nicht nur die Frage, dass etwas passiert ist, sondern auch was passiert ist und warum er relevant ist.
Die letzte Stufe im Datenfluss bildet die Reaktion. In diesem Kontext kommt häufig CrowdSec zum Einsatz. Das Werkzeug analysiert Logdaten aus unterschiedlichen Quellen und identifiziert typische Angriffsmuster wie Brute-Force-Versuche, Scans oder den Missbrauch von Webanwendungen. Erkennt CrowdSec ein entsprechendes Verhalten, greift das System automatisiert ein und blockiert die verantwortliche IP-Adresse über angebundene Firewalls, Reverse Proxys oder Webserver. Regelbasierte Mechanismen steuern diese Reaktionen und erlauben eine feine Abstimmung, um Fehlblockierungen zu vermeiden. Einen zusätzlichen Mehrwert liefert der Community-Ansatz: Anonymisierte Erkenntnisse fließen in eine gemeinsame Threat-Intelligence-Datenbasis ein.
In der Praxis empfiehlt sich eine schrittweise Einführung automatisierter Reaktionen. Klare, eindeutig identifizierbare Angriffsmuster lassen sich zuverlässig automatisiert blockieren. Komplexere Vorfälle sollten Sie zunächst lediglich melden und manuell bewerten. Auch das Deployment der Komponenten spielt eine wichtige Rolle. Viele der genannten Werkzeuge lassen sich containerisiert betreiben, etwa mit Docker oder Podman. Dieser Ansatz trennt Sensoren, Logverarbeitung und Analyse sauber voneinander, vereinfacht Updates und ermöglicht einen reproduzierbaren Betrieb.
Herausforderungen im Betrieb
Der technische Aufbau eines Security-Monitoring-Stacks stellt nur einen Teil der Aufgabe dar. In der Praxis scheitern viele Implementierungen weniger an fehlenden Funktionen als an operativen Herausforderungen. Eine der größten Hürden ist die Datenmenge. Moderne Sensoren erzeugen schnell mehr Ereignisse, als sich sinnvoll auswerten lassen. Statt möglichst viele Logs zu sammeln, sollten Sie gezielt sicherheitsrelevante Daten erfassen. Frühzeitiges Filtern, sinnvoll gewählte Loglevel und eine bewusste Auswahl der Datenquellen reduzieren Komplexität und Kosten.
Eng damit verknüpft ist die Pflege von Regeln und Erkennungslogik. Signaturbasierte Systeme produzieren ohne Anpassung häufig eine hohe Zahl an Fehlalarmen. Regelmäßiges Tuning senkt die Quote an False Positives und erhöht die Akzeptanz des Systems. Ein Alarm, den niemand ernst nimmt, verliert seinen Wert. Gleichzeitig sollten Sie Regeln versionieren und Änderungen nachvollziehbar dokumentieren, um unbeabsichtigte Nebeneffekte zu vermeiden.
Ein weiterer wichtiger Punkt ist der Umgang mit sensiblen Inhalten. Logdaten enthalten häufig personenbezogene Informationen, Zugangsdaten oder interne IP-Strukturen. Sie müssen daher Speicherung, Zugriff und Aufbewahrungsdauer nicht nur technisch, sondern auch rechtlich sauber regeln. Datenschutzanforderungen wie die DSGVO gelten auch für Sicherheitslogs und sollten frühzeitig in die Planung einfließen.
Angriffserkennung ersetzt weder Patchmanagement noch saubere Zugriffskontrollen oder eine durchdachte Netzwerksegmentierung. Ihren vollen Nutzen entfaltet sie nur im Zusammenspiel mit grundlegenden Sicherheitsmaßnahmen. Defense in Depth bleibt auch im Open-Source-Umfeld zentral. Überprüfen Sie Ihre Systeme zudem regelmäßig. Testangriffe, Log-Replays oder gezielte Simulationen helfen Ihnen, die tatsächliche Erkennungsfähigkeit realistisch zu bewerten.
KI und Anomalieerkennung
Mit wachsender Datenmenge stoßen klassische, regelbasierte Verfahren zur Angriffserkennung zunehmend an ihre Grenzen. Logs, Netzwerkmetadaten und Hostereignisse liefern zwar wertvolle Informationen, ihre manuelle Auswertung skaliert jedoch nur begrenzt. An dieser Stelle treten maschinelle Lernverfahren und KI-gestützte Ansätze auf den Plan – insbesondere wenn um das Erkennen unbekannter oder subtiler Angriffsmuster geht.
Bereits heute kommen in einigen Open-Source-Stacks statistische Verfahren zur Anomalieerkennung zum Einsatz, etwa zur Identifikation ungewöhnlicher Loginzeiten, Datenvolumina oder Kommunikationsbeziehungen. Diese Verfahren ersetzen keine klassische Erkennung, sondern ergänzen sie dort, wo feste Regeln an ihre Grenzen stoßen. Ihr Mehrwert liegt weniger in präzisen Alarmen als in der frühzeitigen Hervorhebung verdächtiger Abweichungen vom Normalverhalten.
Zunehmend ins Rampenlicht rücken zudem domänenspezifische Modelle, die gezielt auf Sicherheitsdaten trainiert sind. Statt allgemeiner Sprach- oder Klassifikationsmodelle kommen kleinere, spezialisierte Varianten zum Einsatz, die etwa Syslog-Daten, Netzwerkflüsse oder Prozessinformationen unter die Lupe nehmen. Solche Modelle können helfen, Logdaten zu priorisieren, Zusammenhänge vorzuschlagen oder Analysten bei der Einordnung von Vorfällen zu unterstützen. Das Ganze steht und fällt natürlich mit der Qualität der Trainingsdaten. KI-Systeme sind zudem nach wie vor fehleranfällig, schwer erklärbar und nicht immun gegen Fehlinterpretationen oder Manipulation. Langfristig liegt das Potenzial weniger in der automatisierten Angriffserkennung als in der Entlastung von Administratoren und Analysten. KI kann helfen, Muster sichtbar zu machen, Prioritäten zu setzen und Routineaufgaben zu reduzieren.
Fazit
Bei der Angriffserkennung mit Open Source kommt nicht so sehr auf die Wahl einzelner Werkzeuge an, sondern auf ein Verständnis ihres Zusammenspiels. Ein wirksames System entsteht dort, wo Netzwerk- und Hostsensorik, zentrale Korrelation und angemessene Reaktionsmechanismen sinnvoll ineinandergreifen. Der vorgestellte Schichtenansatz zeigt, dass sich Angriffserkennung mit überschaubarem Aufwand realisieren lässt.
(dr)
Links
[1] Zeek: https://it-a.eu/q4z51
[2] Suricata: https://it-a.eu/q4z52
[3] Snort: https://it-a.eu/m0z62
[4] Wazuh: https://it-a.eu/q4z54
[5] osquery: https://it-a.eu/q4z55
[6] Elasticsearch: https://it-a.eu/q4z56
[7] Logstash: https://it-a.eu/q4z57
[8] Filebeat: https://it-a.eu/n6z56
[9] Kibana: https://it-a.eu/q4z59
[10] Grafana: https://it-a.eu/j7z91
[11] Grafana Loki: https://it-a.eu/k7z12
[12] Crowdsec: https://it-a.eu/m0z41
[13] MISP: https://it-a.eu/l3pd4
[14] TheHive: https://it-a.eu/q4z5d
[15] Filebbeat: https://it-a.eu/n6z56