← Zurück zu Referenzprojekte

Fallstudie · Sicherheits-Engineering

Ein Endpoint-SOC für ein einzelnes Gerät

Wie ein zweistufiges KI-Agenten-System, deterministische Guardrails und klassische Unix-Sensorik zusammen ein Reisegerät überwachen — ohne dass die KI je selbst etwas ausführt.

Rolle
Konzept, Architektur, Umsetzung
Stack
Bash · systemd · Python · Claude-Agenten
Scope
ein Endgerät, kein Server-Fleet
Ausgangslage

Ein Gerät, viele fremde Netze

Ein Laptop, der zwischen Hotel-WLANs, Cafés und dem Heimnetz wechselt, hat kein Unternehmens-SOC im Rücken, das Traffic korreliert, Anomalien einordnet und im Ernstfall reagiert. Klassische Endpoint-Antivirensoftware deckt Signaturen ab, aber nicht Netzwerk-Manipulation, Rogue-Access-Points oder stille Persistenz-Versuche. Die Frage war: wie viel echte SOC-Praxis lässt sich auf ein einzelnes Gerät herunterskalieren — mit Werkzeugen, die es auf jedem Linux-System schon gibt, plus einer KI-Schicht für die Einordnung?

Die Antwort sollte kein Prototyp bleiben, der beim ersten Fehlalarm ignoriert wird — sondern etwas, das man tatsächlich tagelang mitlaufen lässt.

Leitprinzip

Empfehlung ja, Ausführung nein

Jede LLM-gestützte Sicherheitsautomatisierung hat ein strukturelles Risiko: ein Modell, das Logs fehlinterpretiert — oder durch präparierte Log-Inhalte manipuliert wird — und dabei Werkzeuggewalt besitzt, kann selbst zum Sicherheitsproblem werden. Deshalb gilt für dieses System eine einzige, nicht verhandelbare Regel:

Architekturprinzip

Die KI bewertet und empfiehlt. Ausgeführt wird ausschliesslich nach expliziter, manueller Bestätigung durch einen Menschen — und erst nach einer zweiten, rein deterministischen Prüfung derselben Empfehlung.

Das reduziert die KI-Komponente auf das, was sie gut kann — Muster in unstrukturierten Daten erkennen und einordnen — und hält sie von dem fern, was bei einer Fehleinschätzung teuer wird: tatsächlich etwas am System zu verändern.

Architektur

Vom Sensor bis zur Freigabe

Sieben Stationen, jede mit einer klaren Zuständigkeit. Nichts überspringt eine Stufe.

01

Sensoren

Passive Netzwerk-Beobachtung, Datei-/Log-Überwachung, USB-Ereignisse — nichts sendet aktiv Pakete an fremde Geräte.

02

Event-Log

Ein gemeinsames JSON-Schema für alle Quellen: Zeitstempel, Stufe, Kategorie, Nachricht.

03

Triage-Agent

Günstig, häufig getaktet. Stuft Kritikalität ein, nur bei echtem Signal.

04

Eskalations-Agent

Nur bei Bedarf. Tieferer Kontext, genau eine strukturierte Empfehlung.

05

Guardrails

Deterministische Regeln prüfen jede Empfehlung — vor Anzeige und erneut vor Ausführung.

06

Mensch bestätigt

Dialog oder Terminal, mit Klartext-Vorschau des exakten Befehls.

07

Ausführung

Genau der geprüfte Befehl — nie ein vom Modell frei generierter String.

Ansicht

Das Ergebnis im Dashboard

Alle Sensoren, beide Agenten und der Freigabe-Status laufen in einer lokalen, ausschliesslich auf 127.0.0.1 gebundenen Weboberfläche zusammen. Nachbau des tatsächlichen Layouts — Adressen, MAC-Adressen und Netzwerknamen sind frei erfunden (RFC-5737-Dokumentationsbereiche).

127.0.0.1:8787 — anonymisierte Beispieldaten

🛡 Mini-SIEM Dashboard

CPU 18%  RAM 61%
Netzwerkstatus
netwatch🟢 läuft
WLANCafé-Gast-WLAN · 192.0.2.24
Signal72% · Kanal 44
Router-MAC02:00:00:aa:bb:01
VPN🟢 CH (203.0.113.9)
Firewall🟢 aktiv · Kill-Switch an
Auto-Blocks / Events
Aktive Blocks1
🔴 Warnung2
🟡 Hinweis14
🟢 OK31
Signatur-Datenbanken
ClamAVSig. #27184 (15.09.)
rkhunterBaseline 14.09.
Integrität🟢 Baseline ok
Live-Events
14:12:03integrityIntegritäts-Check: keine Abweichung von der Baseline
14:09:41wifi_securityMöglicher Rogue-AP: "Café-Gast-WLAN" über unbekannte BSSID
14:06:15mdnsmDNS: 198.51.100.44 → Drucker [_ipp._tcp]
14:02:58allgemeinNeues Gerät: 198.51.100.17 [MAC 02:1a:2b:3c:4d:5e] Typ: Mobile-Gerät
13:58:30portscanpsad: möglicher Scan von 203.0.113.201 (extern)
13:41:07auto_blockAuto-Block für 203.0.113.55 nach TTL aufgehoben
Netzwerk-Topologie
💻Dieses Gerät 🌐192.0.2.1 🖨️Drucker 📱Mobile-Gerät +3 unbek. 🌍203.0.113.201
SOC-Analysen — Triage-Agent
── SOC-Triage · 14:09:41 ──KRITIKALITÄT: niedrig ZUSAMMENFASSUNG: Die gemeldete Scan-Aktivität stammt von einer der eigenen Interface-Adressen dieses Geräts (192.0.2.24) und ist damit kein externer Angriff, sondern die passive Netzwerk-Sondierung von netwatch selbst — psad wertet dieses Muster im Grenzfall fälschlich als Scan. Das aktuell verbundene WLAN "Café-Gast-WLAN" ist ein offenes Gastnetz ohne erkennbare Vertrauensbeziehung zu diesem Gerät; die parallel aufgetretene Rogue-AP-Meldung verdient dennoch weitere Beobachtung, da BSSID-Wechsel in Gastnetzen häufiger vorkommen als in Heimnetzen. Keine Gegenmassnahme empfohlen.
── SOC-Triage · 13:52:08 ──KRITIKALITÄT: hoch ZUSAMMENFASSUNG: Fünf fehlgeschlagene Login-Versuche von 203.0.113.201 innerhalb von zwei Minuten, gefolgt von einem erfolgreichen sudo-Befehl des regulären Nutzers fünf Minuten später — die zeitliche Nähe ist auffällig, auch wenn der sudo-Befehl selbst unauffällig ist. Die Quelladresse gehört nicht zu diesem Gerät und war zuvor nicht bekannt. Empfehlung: Eskalationsstufe zur Tiefenanalyse (Prozess- und Verbindungsliste, vollständiges Auth-Log) auslösen.

Nachgebaute Ansicht mit synthetischen Werten — Layout, Farblogik und Datenfelder entsprechen dem produktiven Dashboard. Die beiden Analyse-Texte zeigen das reale Format der Triage-Ausgabe; Inhalte anonymisiert.

Werkzeuge im Hintergrund

Was tatsächlich gemessen wird

Alles rein passiv oder auf lokale, bereits vorhandene Standard-Anfragen beschränkt — dazu mehr im Abschnitt zur ethischen Leitplanke weiter unten. Jede Zeile in der Tabelle mündet über das gemeinsame Event-Schema in dieselbe Agenten-Pipeline.

QuelleLiefertFliesst ein in
net.recon (passiv)Geräte- und ARP-Tabelle, Netzwerk-TopologieEvent-Log → Triage
ip neighNeue Hosts, ARP-Konflikte (Spoofing-Verdacht)Event-Log → Triage
avahi-browse (mDNS)Geräteklasse: Drucker, Kamera, IoT, Lautsprecher …Event-Log → Triage
nmcli (WLAN)SSID/BSSID-Historie, VerschlüsselungsstärkeEvil-Twin-Erkennung
p0fPassives OS-Fingerprinting pro IPEskalations-Kontext
psadPortscan-Muster aus Firewall-/Kernel-LogEvent-Log (eigener Traffic vorgefiltert)
ClamAV / rkhunterSignatur- und Heuristik-FundeDirekt an Eskalations-Agent
auth.log / journalctlLogin-Fehlversuche, sudo, neue Nutzer, USB/VPN/WLAN-WarnungenEvent-Log → Triage
SHA256-BaselineAbweichung an den eigenen Sicherheits-SkriptenDirekt an Eskalations-Agent
ufw / VPN-StatusFirewall- und Kill-Switch-ZustandKontext für beide Agenten

Gekürzt — die vollständige Pipeline verarbeitet zusätzliche Quellen wie Verbindungs- und Prozesslisten.

Zwei Agenten, zwei Aufgaben

Günstige Triage, teure Tiefenanalyse

Ein einzelner, immer gleich teurer Agent wäre entweder zu langsam für ständige Beobachtung oder zu teuer für seltene Tiefenanalyse. Die Lösung: zwei Stufen mit unterschiedlichem Budget.

Triage-Agent

Stufe 1 · häufig
Takt
Alle 5 Minuten, aber nur bei tatsächlich neuen Ereignissen ausgelöst
Kontext
Neue Events seit letztem Lauf, aktive Sitzungen, offene Verbindungen, WLAN-Name, eigene IP-Adressen, VPN-Status
Output
niedrig mittel hoch/kritisch + 3–5 Sätze Einordnung
Bei hoch/kritisch
Desktop-Meldung, E-Mail, Übergabe an Stufe 2

Eskalations-Agent

Stufe 2 · nur bei Bedarf
Takt
Nur getriggert — von Stufe 1 oder direkt von AV-/Rootkit-/ Integritäts-Funden
Kontext
Prozessliste, alle Verbindungen, Login-Historie, 200 Zeilen Auth-Log, aktive Auto-Blocks, autorisierte SSH-Schlüssel, Firewall-Status
Output
Genau eine strukturierte Empfehlung: Ziel, Begründung, Konfidenz — oder «keine»
Führt aus
Nichts. Schreibt eine Freigabe-Anfrage, sonst nichts.
2026-·· ··:··:·· [HINWEIS] Neues Gerät im Netzwerk: 198.51.100.24 [MAC: 3c:xx:xx:xx:xx:12] Typ: Router/Gateway 2026-·· ··:··:·· [WARNUNG] Möglicher Rogue-AP: WLAN "Beispiel-Netz" läuft über unbekannte BSSID 2026-·· ··:··:·· [OK] Auto-Block für 203.0.113.5 nach Ablauf der TTL aufgehoben

Anonymisiertes Beispiel aus dem strukturierten Event-Schema — Adressen durch RFC-5737-Dokumentationsbereiche ersetzt. Log-Text bewusst im Original (Deutsch) belassen.

Konkret

Wie eine Empfehlung tatsächlich aussieht

Der Eskalations-Agent schreibt bei einer echten Empfehlung eine einzelne Datei — keinen ausführbaren Befehl, nur strukturierte Felder:

{ "id": "a1b2c3d4-…", "action": "prozess_killen", "target": "48213", "reasoning": "Prozess 'xmrig' auf PID 48213 wurde nicht durch dpkg installiert, verbindet ausgehend auf Port 4444 zu einer unbekannten IP und war zum Zeitpunkt des Auth-Log-Funds noch nicht aktiv.", "confidence": "hoch", "human_preview": "kill -TERM 48213 (Prozess: xmrig)", "expires": "… (30 Min. nach Erstellung)" }

Das erreicht mich über vier parallele Kanäle: Desktop-Benachrichtigung, E-Mail, ein Ja/Nein-Dialog (läuft als eigenständige systemd-Einheit, unabhängig vom Timer-Dienst, der ihn ausgelöst hat) und als Terminal-Fallback jederzeit per Befehl, der Ziel, Begründung, Konfidenz und die exakte Befehlsvorschau nochmal anzeigt, bevor ich bestätige. Reagiere ich nicht, verfällt die Empfehlung nach 30 Minuten automatisch — ohne Aktion.

Fünf mögliche Aktionstypen, sonst keine

Das Modell liefert ausschliesslich action und target als kurze Strings — nie einen fertigen Befehl. Der ausführende Teil baut die echte Aktion selbst aus einem festen Template pro Typ:

EmpfehlungTatsächlich ausgeführter BefehlHarte Grenze
prozess_killenkill -TERM <PID>Denylist (systemd, sshd, NetworkManager, eigene Toolchain, Terminal …), PID 1 nie
netz_trennennmcli device disconnect <Interface>Nur das überwachte Interface, kein anderes
user_sperrenusermod -L <User>Nie eigener Account oder root, nur reguläre UID≥1000
key_entfernenExakte Zeile aus authorized_keys löschen (Backup vorher)Zeile muss wortwörtlich vorhanden sein
datei_quarantänierenDatei nach /var/quarantine/, chmod 000 (kein Löschen)Nur unter definierten, unkritischen Pfaden — Skripte/SSH-Verzeichnis ausgeschlossen
keine

Alles ausserhalb dieser fünf Zeilen fällt im ausführenden Skript in einen Default-Zweig, der nichts tut. Es gibt keinen sechsten Weg.

Kontrollschicht

Guardrails, nicht Vertrauen

Jede Empfehlung durchläuft dieselbe Guardrail-Prüfung aus der Tabelle oben zweimal — einmal direkt nach der Analyse, ein zweites Mal unmittelbar vor der Ausführung, falls sich der Zustand in der Zwischenzeit geändert hat (der Prozess etwa schon von selbst beendet wurde). Eine abgelehnte Empfehlung wird protokolliert, aber nie zu einer Freigabe-Anfrage.

Ausserdem: Log-Inhalte sind teils von aussen beeinflussbar — ein SSH-Benutzername in einem Login-Fehlversuch etwa. Jeder Prompt trennt deshalb explizit zwischen «zu bewertenden Daten» und «Anweisungen an das Modell» und wurde gegen wörtlich eingebettete Injection-Versuche getestet.

Design-Entscheidung, kein Zufall

Was bewusst nicht gebaut wurde

Verworfen — nicht aus technischen Gründen

Eine frühe Version enthielt ein Modul, das aktiv unbekannte Geräte im Netz anspricht, um die Topologie schneller und vollständiger zu kartieren.

Das wurde wieder entfernt. Aktives Anstupsen fremder Geräte in einem Netz, das man nicht selbst betreibt — etwa in einem Hotel-WLAN — ist eine Grenze, die ein Einzelgerät-Werkzeug nicht überschreiten sollte, unabhängig davon, wie harmlos die Absicht ist. Seither gilt: ausschliesslich Mithören von Broadcast-/Multicast-Verkehr und höchstens eine einzelne, für jedes Gerät ohnehin übliche Standardanfrage (etwa ein mDNS-Browse, wie ihn jeder Druck-Dialog selbst auslöst).

Betriebsreife

Wer überwacht die Wächter?

Ein Sicherheitssystem, das selbst unbemerkt ausfallen oder manipuliert werden kann, ist keine Verbesserung. Drei Massnahmen adressieren genau das:

Watchdog Der Sensor-Dienst meldet sich periodisch bei systemd; bleibt das Lebenszeichen aus, wird er automatisch neu gestartet — kein manuelles Eingreifen nötig.
Integrität Eine SHA256-Baseline der eigenen Skripte liegt root-geschützt ausserhalb des normalen Nutzer-Zugriffs. Weicht ein Skript davon ab, löst das selbst einen Sicherheits-Alarm aus — und lässt sich nur per expliziter, manueller Freigabe neu setzen.
Log-Rotation Alle Protokolle sind grössen- und zeitbegrenzt. Unbegrenztes Wachstum, das am Ende die Platte füllt und die Überwachung selbst lahmlegt, ist damit ausgeschlossen.
Einordnung

Kein Enterprise-SIEM — und das ist Absicht

Dieses System ersetzt kein Team, keine Korrelation über hunderte Hosts, keine forensische Tiefe eines echten SOC. Es ist bewusst für genau einen Anwendungsfall gebaut: ein Gerät, ein Nutzer, wechselnde, nicht vertrauenswürdige Netze.

Übertragbar ist dagegen das Grundmuster dahinter — eine KI-Komponente, die bewertet statt zu handeln, deren Vorschläge doppelt deterministisch geprüft werden, und deren Entscheidungswege nachvollziehbar bleiben. Genau diese drei Eigenschaften — menschliche Aufsicht, Nachvollziehbarkeit, Eingriffsmöglichkeit — sind auch der Kern dessen, was regulierte KI-Systeme unter EU AI Act und ISO 42001 verlangen. In diesem Projekt ging es zuerst um ein privates Sicherheitsproblem; das Architekturmuster dahinter ist dasselbe, das auch in professionellem Kontext für vertrauenswürdige KI-Automatisierung trägt.