Wenn die Wächter schlafen: Von einem Fehlalarm zur mehrschichtigen Sicherheitsarchitektur
Wenn die Wächter schlafen: Von einem Fehlalarm zur mehrschichtigen Sicherheitsarchitektur
Inhaltsverzeichnis
- Ein Alarm, der alles ins Rollen brachte
- Wenn die Wächter schlafen: tote Alarme
- Defense in Depth: das Prinzip der Schichten
- Säule 1 — Das SIEM (Wazuh)
- Säule 2 — Die WAF/IPS (CrowdSec)
- Säule 3 — Runtime-Security (Falco)
- Ein Dashboard für alles: das SOC
- Ein Geheimnis in aller Öffentlichkeit
- Lessons Learned
Sicherheit ist selten ein Projekt, das man an einem Tag „fertig" macht. Häufiger ist sie eine Kette von Erkenntnissen, die eine an der anderen hängt — und die oft mit etwas Unscheinbarem beginnt. Dieser Beitrag erzählt eine solche Kette: Sie begann mit einer harmlosen CPU-Warnung und endete mit einer vollständigen, mehrschichtigen Sicherheitsarchitektur. Unterwegs stellen wir die drei zentralen Open-Source-Werkzeuge vor, die heute zusammen wachen — als Einstieg für alle, die ihre eigene selbstgehostete Umgebung absichern wollen.
Ein Alarm, der alles ins Rollen brachte
Alles begann mit einer Warnung: Ein Dienst meldete dauerhaft hohe CPU-Last. Nichts Dramatisches auf den ersten Blick. Doch beim Nachsehen zeigte sich, dass die eigentliche Ursache ganz woanders lag — ein anderer Container startete sich seit vier Tagen alle zwölf Sekunden selbst neu. Zehntausende Neustarts, und niemand hatte es bemerkt.
Jeder Neustart erzeugte technisch einen „neuen" Container, was das Überwachungssystem zwang, laufend neue Kennzahlen anzulegen — eine Datenflut, die schließlich den Arbeitsspeicher der Monitoring-Datenbank sprengte und deren CPU nach oben trieb. Der laute CPU-Alarm war also nur das letzte Glied einer Kette, die vier Ebenen tiefer begann.
Die eigentlich beunruhigende Frage war aber nicht „Warum ist das passiert?", sondern „Warum hat das niemand gemeldet?" Denn es gab einen Alarm für genau diesen Fall: „Container startet zu häufig neu." Er hatte nie ausgelöst.
Wenn die Wächter schlafen: tote Alarme
Die Antwort war ernüchternd: Der Alarm verwies auf eine Kennzahl, die es gar nicht gab. Er war syntaktisch korrekt, galt als „gesund" — und konnte doch niemals feuern. Ein Alarm, der strukturell blind ist, hielt ein Problem tagelang unsichtbar.
Das war der Anlass, die gesamte Alarmierung zu prüfen. Das Ergebnis: Von zwölf Regeln waren sieben defekt. Manche konnten nie auslösen, andere feuerten ununterbrochen. Beide Sorten sind gefährlich:
Der falsch-positive Alarm feuert ständig ohne echten Grund — und erzieht seine Empfänger dazu, ihn wegzuklicken. Der Tag, an dem eine echte Warnung im selben Kanal ankommt, ist dann der Tag, an dem niemand hinsieht.
Ein Beispiel für die tote Sorte: Regeln, die prüften, ob ein Container „läuft = 0". Der verwendete Datensammler führt den Zustand aber als Beschriftung, nicht als Wert. Fällt ein Container aus, verschwindet die „läuft"-Datenreihe einfach — sie springt nie auf Null. Der Vergleich konnte also nie wahr werden. Gemessen an sieben Tagen Historie: null Auslösungen, obwohl in dieser Zeit mehrere Container real gestoppt waren.
Erst als die Wächter selbst wieder verlässlich waren, ergab es Sinn, das Wachpersonal zu verstärken. Denn was nützt die beste Sicherheitstechnik, wenn die Meldekette blind ist?
Defense in Depth: das Prinzip der Schichten
Der Leitgedanke moderner Absicherung heißt Defense in Depth — Verteidigung in der Tiefe. Statt auf eine einzige, perfekte Mauer zu setzen, staffelt man mehrere unabhängige Schichten hintereinander. Fällt eine, steht die nächste. Jede Grenze, die ein Angreifer überwinden muss, kostet ihn Zeit und hinterlässt Spuren.
Für eine selbstgehostete Umgebung mit vielen Diensten lassen sich drei komplementäre Schichten unterscheiden — und für jede gibt es ein etabliertes Open-Source-Werkzeug:
| Schicht | Frage | Werkzeug |
|---|---|---|
| Erkennung & Korrelation | Was ist passiert — und hängt es zusammen? | Wazuh (SIEM) |
| Prävention am Rand | Wer klopft an, und sollte er überhaupt durch? | CrowdSec (WAF/IPS) |
| Laufzeit im Inneren | Was tut ein Prozess jetzt gerade im Container? | Falco (Runtime-Security) |
Sehen wir uns die drei der Reihe nach an — jeweils mit einer kurzen Einführung für Einsteiger.
Säule 1 — Das SIEM (Wazuh)
Wazuh ist eine weit verbreitete, quelloffene SIEM-Plattform. Sie kann weit mehr als Logs sammeln:
- Dateiintegrität (FIM): Sie merkt, wenn sich kritische Systemdateien unerwartet ändern — ein klassisches Einbruchssignal.
- Schwachstellen-Erkennung: Sie gleicht installierte Software gegen bekannte Sicherheitslücken ab.
- Härtungsprüfung: Sie bewertet die Konfiguration gegen anerkannte Sicherheits-Benchmarks.
- Log-Analyse: Sie zieht Anmeldeversuche, Web-Zugriffe, Mail-Verkehr und Kernel-Ereignisse zusammen und macht sie durchsuchbar.
In dieser Session bekam Wazuh zusätzlich einen frischen Satz Regeln zur Erkennung von Web-Angriffen — Mustern wie Pfad-Durchquerung, Injektionsversuchen, Skript-Einschleusung und Scanner-Signaturen. Diese liefen auf den ohnehin schon gesammelten Web-Zugriffslogs; es fehlten nur die Regeln, die daraus Angriffserkennung machen.
%20). Eine Regel, die auf
literale Zeichen prüft, geht dann ins Leere. Deshalb wurden die Muster kodierungs-robust
geschrieben — und gegen echte Angriffszeilen und hunderte legitime Anfragen
getestet, um Fehlalarme auszuschließen.
Säule 2 — Die WAF/IPS (CrowdSec)
CrowdSec ist eine moderne, quelloffene WAF/IPS-Lösung mit einem besonderen Kniff: Sie analysiert Verhaltensmuster in den Logs (viele Fehlversuche, typische Scanner-Pfade) und trifft daraufhin Sperrentscheidungen. Das eigentlich Bemerkenswerte ist aber die kollektive Threat-Intelligence:
Die Durchsetzung übernimmt ein sogenannter Bouncer, der die Sperrentscheidungen in die Firewall des Systems einträgt. Genau hier war Sorgfalt gefragt: In einer Umgebung, in der bereits mehrere Komponenten an derselben Firewall arbeiten, darf ein neuer Akteur die bestehende Ordnung nicht durcheinanderbringen. Die Lösung war, den Bouncer in einer eigenen, getrennten Firewall-Struktur arbeiten zu lassen — so blockt er zuverlässig, ohne den empfindlichen Rest anzutasten. Nach der Aktivierung wurde genau das überprüft: Die bestehenden Regeln blieben unangetastet.
Säule 3 — Runtime-Security (Falco)
Falco ist das führende Open-Source-Werkzeug dafür. Es erkennt Dinge, die weder in Logs noch im Netzwerkverkehr auftauchen:
- eine interaktive Shell, die sich in einem Container öffnet
- einen Container-Ausbruch (den Versuch, aus der Isolation zu entkommen)
- den Zugriff auf sensible Dateien wie Passwort- oder Schlüsselspeicher
- das Nachladen und Ausführen fremder Programme — ein typisches Miner-Muster
Moderne Falco-Varianten nutzen eine Kernel-Technik namens eBPF, die tief im System mithört, ohne dass ein zusätzliches Kernel-Modul installiert werden muss — die sicherste und wartungsärmste Variante.
Kritische Falco-Ereignisse landen als Push-Benachrichtigung auf dem Handy — aber bewusst nur die schwerwiegenden. Das alltägliche Grundrauschen bleibt im Protokoll für die spätere Analyse, ohne zu stören.
Ein Dashboard für alles: das SOC
Drei mächtige Werkzeuge nebeneinander sind gut. Drei mächtige Werkzeuge, die man einzeln durchklicken muss, sind ein Problem — man verliert den Überblick, und Zusammenhänge zwischen den Schichten bleiben unentdeckt. Der letzte Schritt war deshalb die Zusammenführung: Die Ereignisse von CrowdSec und Falco fließen zusätzlich ins zentrale SIEM.
Der elegante Teil daran: Es brauchte keine neue Infrastruktur. Beide Werkzeuge schreiben ihre Ereignisse in strukturierte Protokolldateien, die das SIEM ohnehin schon einlesen kann — es fehlten nur die passenden Regeln. Jetzt sind ein blockierter Angreifer (CrowdSec), ein verdächtiger Syscall (Falco) und ein fehlgeschlagener Anmeldeversuch (SIEM) im selben Dashboard sichtbar und miteinander korrelierbar.
Ein Geheimnis in aller Öffentlichkeit
Zwischen all der Infrastruktur steckte noch eine Lektion, die stellvertretend für eine ganze Klasse von Fehlern steht. Ein Dienst nutzte einen geheimen Schlüssel, um eine interne Schnittstelle abzusichern. Der Schlüssel lag ordentlich in einer Konfiguration — nur leider in einer Variable, die eine moderne Web-App in das an jeden Besucher ausgelieferte JavaScript einbäckt.
Die richtige Lösung ist architektonisch: Der Browser spricht nur noch mit dem eigenen Server, und erst dieser fügt den Schlüssel serverseitig hinzu, bevor er die interne Schnittstelle anspricht. So wird aus einem öffentlichen Pseudo-Geheimnis ein echtes: Der Schlüssel verlässt den Server nie mehr. Erst danach ergibt eine Rotation überhaupt einen Sinn — und die wurde ebenfalls durchgeführt.
Die allgemeine Regel dahinter: Alles, was mit dem Präfix für „öffentliche" Client-Variablen markiert ist, ist per Definition nicht geheim. Secrets gehören ausschließlich auf den Server.
Lessons Learned
- Prüfe zuerst die Wächter. Ein Alarm, der nie feuern kann, ist gefährlicher als gar keiner — er erzeugt falsche Sicherheit. Regeln müssen gegen echte Daten getestet werden.
- Das lauteste Symptom ist selten die Ursache. Folge einem Alarm bis zur Wurzel, statt ihn ruhigzustellen.
- Sicherheit ist mehrschichtig: Erkennung (SIEM), Prävention (WAF/IPS) und Laufzeit (Runtime-Security) ergänzen sich, ersetzen sich aber nicht.
- Kollektive Threat-Intelligence ist ein Multiplikator: von den Angriffen auf tausend andere lernen, statt jeden selbst abzuwarten.
- Neue Sicherheitswerkzeuge dürfen die bestehende Ordnung nicht stören — besonders an gemeinsam genutzten Ressourcen wie der Firewall. Getrennte Strukturen und Verifikation nach jeder Änderung.
- Runtime-Security braucht Tuning, sonst ertrinkt man im Rauschen. Nur eindeutig Legitimes ausnehmen.
- Bündle die Signale. Drei Werkzeuge in einem Dashboard schlagen drei getrennte Kanäle — aber ohne Alarm-Dopplung.
- Ein „geheimer" Schlüssel im Browser-Code ist öffentlich. Secrets leben auf dem Server.
Am Ende steht kein einzelnes Werkzeug, sondern ein Zusammenspiel: verlässliche Wächter, drei sich ergänzende Verteidigungsschichten und ein zentrales Bild, das alles zusammenführt. Der Weg dahin begann mit einer harmlosen CPU-Warnung — ein guter Beleg dafür, dass es sich lohnt, jedem Alarm bis zum Grund zu folgen. Für alle, die selbst hosten: Wazuh, CrowdSec und Falco sind quelloffen, gut dokumentiert und ein lohnender Einstieg in die Welt der mehrschichtigen Absicherung.