Zurück zum Blog

Wenn die Wächter schlafen: Von einem Fehlalarm zur mehrschichtigen Sicherheitsarchitektur

Wenn die Wächter schlafen: Von einem Fehlalarm zur mehrschichtigen Sicherheitsarchitektur

Datum 17. Juli 2026
Kategorie Security
Lesezeit 15 Minuten

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-negative Alarm feuert nie, obwohl das Problem eintritt — und wiegt in falscher Sicherheit.

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.

Die wichtigste Lehre der ganzen Session: Eine Alarmregel wird nicht dadurch vertrauenswürdig, dass ihre Syntaxprüfung „OK" sagt. Sie muss gegen echte Daten gemessen werden: Hätte sie den letzten realen Vorfall erkannt — und im Normalbetrieb geschwiegen? Wo möglich, ist der Königsweg der scharfe Test: eine unkritische Komponente kontrolliert stoppen und beobachten, ob der Alarm wirklich anschlägt.

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)

Was ist ein SIEM? Die Abkürzung steht für Security Information and Event Management. Ein SIEM ist das Nervenzentrum der Überwachung: Es sammelt Log- und Ereignisdaten aus vielen Quellen an einer zentralen Stelle, normalisiert sie, wendet Regeln an und schlägt Alarm, wenn ein Muster verdächtig ist. Es beantwortet nicht nur „Was ist passiert?", sondern durch Korrelation auch „Gehören diese fünf Ereignisse zusammen?".

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.

Ein Detail, das leicht zur Falle wird: Angriffe kommen meist URL-kodiert an (ein Leerzeichen wird zu %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)

Was ist eine WAF, was ein IPS? Eine Web Application Firewall (WAF) prüft Web-Anfragen und blockt bösartige, bevor sie die Anwendung erreichen. Ein Intrusion Prevention System (IPS) erkennt Angriffsmuster und sperrt die Quelle aktiv aus. Der Unterschied zum SIEM: Ein SIEM erkennt und meldet im Nachhinein — eine WAF/IPS verhindert in Echtzeit.

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:

Der Schwarm-Effekt: Wird ein Angreifer irgendwo in der weltweiten CrowdSec-Gemeinschaft auffällig, landet seine Adresse auf einer geteilten Sperrliste. Jede teilnehmende Installation kann diese Liste nutzen — und blockt bekannte Angreifer proaktiv, bevor sie überhaupt etwas versuchen. In dieser Umgebung wurden dadurch sofort mehrere Tausend bekannt-bösartige Adressen gesperrt.

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)

Was ist Runtime-Security? SIEM und WAF sehen Logs und Netzwerkverkehr. Aber was passiert innerhalb eines laufenden Containers? Wenn ein Angreifer es geschafft hat, Code auszuführen, öffnet er vielleicht eine Shell, liest heimlich eine Passwortdatei oder startet einen Krypto-Miner. Runtime-Security beobachtet die Systemaufrufe (Syscalls) — die elementaren Anfragen jedes Programms an den Betriebssystem-Kern — und erkennt so verdächtiges Verhalten in dem Moment, in dem es geschieht.

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.

Runtime-Security ist von Natur aus laut. Viele völlig legitime Vorgänge sehen auf Syscall-Ebene „verdächtig" aus — ein Dienst, der beim Start seine eigenen Konfigurationsdateien schreibt, oder ein System-Prozess, der beim Login eine Passwortdatei liest. Ohne Feinabstimmung ertränkt Falco seine Betreiber in Fehlalarmen. Der Schlüssel ist Tuning: bekannte, legitime Muster gezielt ausnehmen, damit die echten Signale sichtbar bleiben. Dabei gilt eine goldene Regel — nur eindeutig Legitimes stummschalten, niemals pauschal.

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

Was ist ein SOC? Ein Security Operations Center ist im Großen ein Raum voller Analysten, die Sicherheitsereignisse zentral beobachten. Im Kleinen — für eine selbstgehostete Umgebung — ist es vor allem ein Prinzip: alle Sicherheitssignale an einem Ort, statt in drei getrennten Werkzeugen verstreut.

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.

Eine bewusste Design-Entscheidung: Damit nicht jedes Ereignis doppelt alarmiert (Falco meldet ja schon selbst, CrowdSec blockt schon selbst), wurden die SIEM-Regeln für diese Quellen unterhalb der Alarmierungs-Schwelle gehalten. Sie dienen der Sichtbarkeit und Korrelation — nicht einer zweiten, redundanten Benachrichtigung. Wer das SIEM später zum einzigen Melde-Kanal machen will, kann die Schwellen gezielt anheben. Konsolidierung ohne Lärm ist auch eine Kunst.

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.

Ein „geheimer" Schlüssel im Browser ist kein Geheimnis. Jede Person, die die Seite öffnet, kann ihn mit den Entwicklerwerkzeugen des Browsers auslesen. Ihn zu rotieren oder aus dem Quellcode-Verlauf zu tilgen, gibt eine trügerische Sicherheit — der Ersatz-Schlüssel wäre genauso öffentlich.

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

Die wichtigsten Erkenntnisse dieser Session:
  • 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.