RoamSwitch für Linux
Whitepaper zu Architektur und Sicherheit

§1

RoamSwitch für Linux ist eine residente Netzwerksicherheits- und Systemdiagnoseanwendung, die das Zero-Trust-Netzwerkverteidigungsmodell von macOS RoamSwitch auf Linux (systemd + nftables-Umgebungen) bringt.

Diese Edition zielt auf Client-Maschinen (Workstations, Laptops, Einplatinencomputer) ab und setzt autonomes Verhalten voraus, das der Maschine folgt, wenn sie sich zwischen Netzwerken bewegt. Eine gehärtete Server-/Headless-Infrastruktur-Edition (RoamSwitch Server Edition – Always-on-Default-Deny, Critical-Path-FIM-Integrität, Remote-Webhooks und statische Richtliniendurchsetzung) wird als dedizierter Server-Build bereitgestellt.

Es identifiziert das verbundene WLAN/kabelgebundene Netzwerk anhand seiner Gateway-MAC-Adresse und schaltet selbstständig das aktive nftables-Firewallprofil um. Darüber hinaus bietet es drei Ebenen der Man-in-the-Middle-Verteidigung (MITM) in nicht vertrauenswürdigen Netzwerken: einen VPN-Tunnel + Kill-Switch (WireGuard oder Tailscale, die primäre Verteidigung), eine präventive ARP/NDP-Sperre und ARP-Spoof-Erkennung. Hinzu kommen verhaltensbasierte Ransomware-Erkennung (Fanotify + Shannon-Entropie + Kanarienvögel), ein passiver Link Guard, der Phishing-Verbindungen kennzeichnet oder blockiert (NFQUEUE + SNI), ein Port Anomaly Guard, BadUSB-Abwehr, Gegenmaßnahmen gegen Kernel Local Privilege Escalation (LPE) (als Abschwächung von Frag Gap CVE-2026-53362 lässt sich die Ablehnung nicht privilegierter Benutzer-Namensräume in nicht vertrauenswürdigen Netzwerken optional aktivieren; standardmäßig deaktiviert), eBPF-Laufzeit-Bedrohungssensor-Integration (Falco/Tetragon) mit Einfrieren des angreifenden Prozesses im Millisekundenbereich (SIGSTOP) und automatischer Air-Gap-Isolation, eine 27-Punkte-Bewertung des Sicherheitszustands und ein integrierter Model Context Protocol (MCP)-Server.

Dieses Whitepaper beschreibt die Architektur, das Bedrohungsmodell und das Design jedes Abwehrmechanismus – und insbesondere, wie das Prinzip „vollständig lokale Verarbeitung; standardmäßig verlässt nur eine Anfrage nach signierten Erkennungsdaten die Maschine, und sie enthält nichts über Sie“ auf Codeebene sichergestellt wird. Opt-in-Funktionen, die ein Betreiber ausdrücklich aktivieren muss (etwa die Ereignisweiterleitung), sind Ausnahmen von diesem Standard; sie sind alle in der folgenden Tabelle und in §9.4 aufgeführt. Es vermeidet Marketingsprache; die Aussagen lassen sich am tatsächlichen Verhalten des verteilten Pakets (Binärdatei) und an der Selbstprüfung im Anhang überprüfen. RoamSwitch für Linux ist proprietäre Freeware, der Quellcode wird nicht veröffentlicht (§11).

§2

RoamSwitch für Linux zielt hauptsächlich auf Laptops/mobile Workstations ab, die zwischen nicht vertrauenswürdigen Netzwerken wechseln.

Angreifer im Visier

• ___
• Bösartige USB-Geräte (BadUSB) – Vortäuschen einer Tastatur und Einschleusen von Tastenanschlägen, bevor der Bildschirm gesperrt wird; unregistrierter USB-Massenspeicher zur Datenexfiltration oder zum Einschleusen von Schadsoftware.
• Ransomware/dateilose Malware – Eindringen über eine heruntergeladene Datei und Massenverschlüsselung der Dokumente des Benutzers.
• DNS-basiertes C2 und Phishing – Malware, die Namensauflösung nutzt, um einen C2-Server oder eine Phishing-Site zu erreichen.

Außerhalb des Gültigkeitsbereichs

• Ein Angreifer, der bereits Wurzeln schlägt; Rootkits auf Kernel- oder Firmware-Ebene.
• Angriffe, die die Festplatte physisch entfernen (die Domäne der vollständigen Festplattenverschlüsselung; RoamSwitch diagnostiziert, ob eine Verschlüsselung vorhanden ist, führt jedoch keine Verschlüsselung durch).
• Proximity Wireless Sharing-Steuerung im AirDrop-Stil (kein Betriebssystem-nativer Mechanismus unter Linux; nicht unterstützt).

§3

RoamSwitch für Linux ist in Rust implementiert, und das Paket enthält acht ausführbare Dateien (roamswitch-daemon, roamswitch-app, roamswitch (CLI), roamswitch-mcp, roamswitch-updater, roamswitch-honeytokens, roamswitch-incident-capture und das experimentelle, standardmäßig deaktivierte roamswitch-xdp-gate). Die gemeinsame Logik liegt in der Bibliothek roamswitch-core, und roamswitchkit ist das Client-SDK. Die gesamte Kommunikation mit dem Daemon erfolgt über /run/roamswitch/roamswitch.sock (einen Unix-Domänen-Socket). Es gibt keinen lauschenden TCP/UDP-Socket im Daemon, in der App oder im MCP-Server. Das Einzige, was die App per bind öffnet, ist ein einzelner Unix-Socket, um eine zweite Instanz zu verhindern.

# Userspace (unprivilegiert)
roamswitch-app      GTK3 + AppIndicator-Tray
roamswitch (CLI)    Schlankes Shell-Frontend
roamswitch-mcp      stdio JSON-RPC (von AI-Clients gestartet)
      │
      │  AF_UNIX  /run/roamswitch/roamswitch.sock  (nur lokales IPC)
      ▼
roamswitch-daemon   root / systemd Type=notify + WatchdogSec=30
  ・nftables-Profilsteuerung (inet roamswitch-Tabelle)
  ・Sentinel-Schleife (Netzwerkerkennung & Profildurchsetzung)
  ・VPN-Tunnel + Kill-Switch (WireGuard: wg-quick / roamswitch_vpn, Tailscale: roamswitch_ts)
  ・Präventive ARP/NDP-Sperre (Neigh-Tabellen-Pin) / Erkennung
  ・Port-Anomalie-Wächter (roamswitch_dev_guard)
  ・fanotify-Wächter (Ransomware / Malware)
  ・Link Guard (NFQUEUE — inet roamswitch_linkguard)
  ・Canary-Engine / Quarantäne-Vault
  ・Kernel-LPE-Gegenmaßnahmen (Ablehnung nicht privilegierter userns optional, standardmäßig aus)
  ・eBPF-Laufzeitintegration (/var/run/roamswitch/events.sock)
  ・SIGSTOP-Einfrieren angreifender Prozesse im Millisekundenbereich & Air-Gap-Kopplung
  ・USB-Überwachung (evdev EVIOCGRAB — BadUSB) / Freigabe-Warteschlange
  ・Ed25519-Lizenzprüfung

roamswitch-updater  Ein eigenständiger systemd-Timer-Helfer. Das einzige Crate
                    mit HTTP/TLS-Stack (täglicher signierter Manifest-GET)
roamswitch-honeytokens          Vom Daemon gestarteter Hilfsprozess (legt Köder-Zugangsdaten an und überwacht sie)
roamswitch-incident-capture     Vom Daemon gestarteter Hilfsprozess (sammelt bei der Eindämmung ein Beweispaket)
roamswitch-core     Reine Logikbibliothek (von allen Crates geteilt)
roamswitchkit       MCP-Client-SDK

Die gesamte Kommunikation mit dem Daemon erfolgt über /run/roamswitch/roamswitch.sock (das Verzeichnis hat 0755, der Socket 0666). Die Zugriffskontrolle beruht nicht auf Dateiberechtigungen, sondern auf der Prüfung des Aufrufers: Der Daemon liest die UID der Gegenstelle über SO_PEERCRED, weist Systemkonten ab (UIDs 1 bis 999 und nobody) und nimmt zustandsändernde Aufrufe nur von root oder von einer UID an, die eine lokale Login-Sitzung besitzt (§1). Die Benutzerkonfiguration wird als Klartext-JSON unter ~/.config/roamswitch/config.json gespeichert. Der Daemon durchsucht und liest /home/*/.config/roamswitch/config.json mit Root-Rechten (er läuft mit HOME=/root). Akzeptiert wird nur eine Datei, die dem Konto selbst gehört, kein symbolischer Link ist und für andere Benutzer nicht beschreibbar ist. Die Konfiguration verlässt nie die Maschine; es gibt keine Kontoregistrierung und keine Cloud-Synchronisierung.

§4

Die Sentinel-Schleife (3-Sekunden-Zyklus) liest den MAC des Standard-Gateways von /proc/net/arp und ip neigh und gleicht ihn mit den registrierten MACs in config.json ab. MAC wird anstelle von SSID verwendet, da eine SSID auf einfache Weise gefälscht werden kann. Die beim Profilwechsel angezeigte Desktop-Benachrichtigung nennt den Grund für den Wechsel („ein nicht registriertes Netzwerk“ / „Ihre Einstellung für das registrierte Netzwerk X“ / „keine Netzwerkverbindung“).

Alle Regeln sind in einer dedizierten nftables-Tabelle mit dem Namen inet roamswitch isoliert und kollidieren nie mit anderen Firewall-Konfigurationen (ufw/firewalld). Der Ablauf der manuellen Überschreibung (1 Stunde / 2 Stunden / 4 Stunden / bis Mitternacht / bis zur Löschung / bis zur nächsten Trennung) wird vom Daemon als einzigem Autor erzwungen. Die GUI schreibt niemals einen Ablauf; Es liest den config.json, den der Daemon beim nächsten Tick neu geschrieben hat, erneut und spiegelt ihn in der Benutzeroberfläche wider (wodurch ein Konflikt vermieden wird).

Air-Gap (Notfall-Netzwerkisolierung)

Ein vollständiger Isolationsmodus, der policy drop (Priorität -100) sowohl für die Eingabe- als auch für die Ausgabe-Hooks der Tabelle inet roamswitch festlegt und nur lo zulässt.

• Fail close – Beim Neustart des Daemons wird durch die Erkennung der Markierungsdatei (/run/roamswitch/airgap.active) die Isolation erneut sichergestellt.
• Selbstheilend – Wenn ein externer Prozess die Regeln mit nft delete table löscht, wird die Sentinel-Schleife innerhalb von Sekunden erneut angewendet.
• Auslöser mit geringer Konfidenz enden per kurzem Timer — ein einfaches manuelles Air-Gap ohne Warnkontext (eine GUI-Schaltfläche oder roamswitch airgap) ist ein Auslöser mit geringer Konfidenz und wird über einen kurzen Timer (airgap_low_confidence_secs, Standard 600 Sekunden) vollständig aufgehoben, damit ein versehentlicher Klick oder ein Fehlalarm die Maschine nicht lange vom Netz trennt. Eine ARP-Anomalie außerhalb von lockdown, eine Port-Anomalie und ein eBPF-Ereignis der Stufe Error oder darunter werden in der gemeinsamen Zustandsmaschine ebenfalls als gering konfident eingestuft, doch der Client löst dafür nie automatisch ein Air-Gap aus; sie führen nur zu einer Benachrichtigung oder einem Protokolleintrag oder sperren den einzelnen Port.
• Auslöser mit hoher Konfidenz stellen nie stillschweigend wieder her — Kanarien-Manipulation, ein eBPF-Ereignis Emergency/Alert (ein Ereignis der Stufe Critical nur, wenn sich der einzelne Prozess nicht eindämmen ließ), ARP-Spoofing unter lockdown, an dem das Gateway beteiligt ist, und ein als Reaktion auf eine ARP-Warnung ausgelöstes Air-Gap (sowie, nur bei Opt-in, eine Regel des Ausführungsrekorders mit hohem Schweregrad; §5) werden nicht automatisch aufgehoben, egal wie viel Zeit vergeht. Ab dem kurzen Timer wird in jedem Zyklus geprüft, ob die Ursache fortbesteht (eingefrorene PID noch aktiv, Kanarie erneut überschrieben, ARP-Anomalie hält an usw.); nur wenn die Ursache nachweislich beseitigt ist, wird mit Benachrichtigung aufgehoben. Eine nicht eindeutige Prüfung gilt als „nicht behoben“. Ein Ransomware-Entropie-Burst löst zusätzlich zum Einfrieren des Prozesses mit SIGSTOP und einer Benachrichtigung auch ein Air-Gap aus und gilt ebenso als Auslöser mit hoher Konfidenz.
• DEGRADED-Modus — erreicht eine Isolation mit hoher Konfidenz die Obergrenze (airgap_hard_cap_secs, Standard 3600 Sekunden; 0 = keine Obergrenze), ohne dass der Benutzer sie aufhebt und ohne nachgewiesen beseitigte Ursache, wechselt sie in DEGRADED. Beim Client ist DEGRADED so streng wie FULL – alles außer Loopback wird verworfen, auch bestehende Verbindungen; der Unterschied ist, dass es sich niemals per Timer wieder öffnet. Aufgehoben wird durch den lokalen Benutzer (GUI-Schaltfläche oder roamswitch emergency-restore) oder durch eine Neuprüfung, die das Verschwinden der Ursache nachweist. Air-Gap sperrt standardmäßig auch das WLAN-Funkmodul per rfkill (airgapAutoRfkill); DEGRADED lässt es gesperrt, sofern airgap_degraded_lift_rfkill nicht auf true steht.
• Übergänge werden protokolliert und gemeldet — der Wechsel von FULL nach DEGRADED, jede Art automatischer Aufhebung und eine Aufhebung durch den Benutzer werden in der Vorfall-Zeitleiste festgehalten und lösen eine Desktop-Benachrichtigung aus. Der Isolationszustand liegt in /run/roamswitch/airgap_isolation.json und übersteht einen Daemon-Neustart (ein Neustart setzt den Zähler aufeinanderfolgender ARP-Prüfungen zurück, was zugunsten der fortbestehenden Isolation ausfällt – fail-closed).

table inet roamswitch {
    chain input {
        type filter hook input priority -100; policy <accept|drop>;
        iif "lo" accept
        ct state established,related accept
        # open ist policy accept ohne Regeln; balanced / lockdown sind policy drop (ICMP / ICMPv6 sind nur in balanced erlaubt)
    }
    chain output {
        type filter hook output priority -100; policy <accept|drop>;
        # Bei Air-Gap (Isolation) wird dieselbe Tabelle neu aufgebaut: input und output mit policy drop, nur lo ist erlaubt (auch bestehende Verbindungen werden nicht durchgelassen)
    }
}

Passiver Link Guard (Erkennung von Phishing-Verbindungen)

Der Daemon überwacht, wohin ausgehende Verbindungen gehen, und markiert bzw. blockiert Verbindungen zu gefährlichen Hosts, wenn es sich um die eng gefasste Gruppe „eindeutig Phishing“ handelt. Es ersetzt den älteren Paste-a-URL-Checker, der ein Eingreifen des Benutzers erforderte.

• Interception – eine dedizierte nftables-Tabelle inet roamswitch_linkguard bindet den Pfad output ein und stellt DNS-Fragen und neue/frühe Webverbindungen über NFQUEUE in die Warteschlange für einen Userspace-Worker. NFQUEUE ist ein Kernel↔Userspace-Urteilskanal über AF_NETLINK; Der Daemon bindet keinen Socket und generiert kein Paket. Die Warteschlangenregeln tragen bypass, sodass der Datenverkehr ungehindert durchläuft, wenn der Worker nicht ausgeführt wird (Air-Gap bleibt der separate harte Stopp).
• Hostname-Quellen – der DNS-Fragename, der TLS-ClientHello SNI (damit ein Browser, der DoH verwendet, immer noch durch den Hostnamen abgedeckt wird) und der Klartext-HTTP-Header Host. Encrypted ClientHello (ECH), sobald es weit verbreitet ist, ist ein bekannter blinder Fleck.
• Verdict (roamswitch-core, reine Logik) – ein Host wird anhand des lokalen Phishing-/Bedrohungs-Feeds und einer Reihe von Offline-Heuristiken überprüft: IDN/verwechselbares Homograph einer geschützten Marke, Markentoken in einer nicht offiziellen Domäne, Raw-IP-Host, TLD mit hohem Risiko.

Hart blockiert wird nur ein Feed-Treffer oder ein Host mit Markenhomograph; alles, was die Heuristik allein kennzeichnet, bleibt ein Urteil auf Warnstufe, ohne Blockierung und ohne Benachrichtigung. Der warn-Modus hält die Verbindung zu einem gefährlichen Host bis zu 8 Sekunden an, während der Benutzer gefragt wird; läuft die Sperre ohne Antwort ab, ist sie fail-closed (die Pakete werden verworfen und das Urteil wird nicht zwischengespeichert). Eine ausbleibende Antwort auf „Ist diese Site in Ordnung?“ darf nicht als „Ja“ gelten; beim nächsten Versuch wird erneut gefragt. Im block-Modus werden eine Benachrichtigung und ein Zulassungsdialog nur einmal pro Host angezeigt (ein Browser, der viele Verbindungen zum gleichen blockierten Host öffnet, überflutet die Benachrichtigungen nicht mehr). In einem Genehmigungsdialog für ein gefährliches Ziel ist die Standardschaltfläche „Weiter blockieren“, und „Zulassen“ ist die unauffällige, nicht voreingestellte Option. Wählt man im Genehmigungsdialog „Zulassen“, wird der blockierte Host dauerhaft zu linkGuard.allowlist hinzugefügt und passiert, bis er in den Einstellungen wieder entfernt wird.

DNS wird überprüft, nie gefälscht: Eine DNS-Frage auf der Blockliste erzeugt nur eine Benachrichtigung; die Durchsetzung erfolgt auf der nachfolgenden TCP-Verbindung, sodass RoamSwitch niemals eine synthetische DNS-Antwort einfügt. Der Feed ist eine zusammengestellte Liste von Phishing-/Betrugsdomänen, die im Paket geliefert und vom täglichen Updater aktualisiert wird (§11). Auch wenn kein Feed vorhanden ist, werden die Offline-Heuristiken weiterhin ausgeführt. Die Ed25519-Signatur und der SHA-256 des Feeds werden vom täglichen Updater geprüft, bevor er etwas installiert; nicht passende Daten werden nicht übernommen. Der Link Guard lädt den installierten Feed (oder den im Paket mitgelieferten); ist keiner von beiden vorhanden, arbeitet er „nur mit Heuristiken“ und niemals mit „alles zulassen“.

VPN-Tunnel + Kill-Switch (die primäre MITM-Verteidigung)

Anti-MITM-Schutz, der nicht von der Integrität der Schicht 2 abhängt. In einem nicht vertrauenswürdigen Netzwerk macht ein ständig aktiver verschlüsselter Tunnel zu einem vertrauenswürdigen Endpunkt lokales ARP/NDP-Spoofing, Rogue-DHCP und passives Sniffing irrelevant – der Angreifer sieht nur Chiffretext. Die ARP/NDP-Sperre und die folgende Erkennung sind für diese Funktion zweitrangig.

Zwei Backends zur Auswahl – „WireGuard (Konfigurationsdatei)“ oder „Tailscale (Ausgangsknoten)“. RoamSwitch implementiert keine eigene Kryptografie und ist kein VPN-Anbieter. Beide Backends sind optionale Abhängigkeiten; Wenn nicht, zeigt die GUI den Installationsbefehl an.

(A) WireGuard-Backend

• Es wird kein VPN-Server bereitgestellt – verwendet eine WireGuard-Konfiguration, die der Benutzer bereitstellt: eine .conf von einem Anbieter wie Mullvad, IVPN oder Proton VPN oder den eigenen WireGuard-Server des Benutzers (ein VPS oder ein Heimserver). Es wird keine Standardkonfiguration ausgeliefert.
• Config – der Daemon validiert den .conf und speichert ihn unter /etc/wireguard/roamswitch.conf (0600, Schnittstelle roamswitch). Es kann nicht anderswo leben: Das AppArmor wg-quick-Profil unter Ubuntu 24.04+ / Debian 13 verweigert wg-quick das Lesen eines .conf außerhalb von /etc/wireguard/ – selbst als Root. Eine Split-Tunnel-Konfiguration (AllowedIPs, nicht 0.0.0.0/0 / ::/0) wird als „nicht der gesamte Datenverkehr ist geschützt“ gekennzeichnet.
• Kill-switch – eine dedizierte nftables-Tabelle inet roamswitch_vpn (policy drop, beide Hooks) verwirft alles außer Loopback, der Tunnelschnittstelle (roamswitch, passend zu oifname), UDP zur angehefteten Endpunkt-IP, DHCP und ICMP. Es wird vor installiert, bevor der Tunnel eingerichtet wird (der Endpunkt wird zuerst über getent ahosts in feste IPs aufgelöst), sodass es kein Leckfenster gibt. Wenn wg-quick up fehlschlägt, bleibt der Kill-Switch aktiv.

(B) Tailscale-Backend

• Für Benutzer, die Tailscale bereits ausführen. RoamSwitch führt nicht aus, führt tailscale up / login / install tailscaled aus – es liest tailscale status --json und führt tailscale set --exit-node=<node> / --exit-node= aus (klar).
• Ein Exit-Knoten ist erforderlich – Anti-MITM-Schutz gilt nur bei einem Exit-Knoten, der den gesamten Datenverkehr weiterleitet. Wenn „Keine“ konfiguriert ist, ist der Schutz nicht aktiviert und die Benutzeroberfläche warnt „nicht geschützt“. Wenn der ausgewählte Knoten offline geht, wird der Schutz automatisch deaktiviert und der Benutzer benachrichtigt (die Weiterleitung aller Daten über einen toten Knoten würde die Verbindung blockieren).
• Kill-switch (inet roamswitch_ts, policy drop) – Der Transport von Tailscale kann nicht an eine einzelne Endpunkt-IP (DERP-Relays + Roaming-Peers) angeheftet werden, daher ist dieser lockerer als der von WireGuard. Es ermöglicht: Loopback, die Tunnelschnittstelle (tailscale0), die CGNAT-Bereiche 100.64.0.0/10 und fd7a:115c:a1e0::/48, STUN (udp/3478), DERP (tcp/443), udp/41641, DHCP, ICMP, MagicDNS (100.100.100.100:53), aufgebaute Verbindungen. Alles andere – beliebiges UDP, DNS zu einem lokalen Resolver, SMB, mDNS, Klartext-HTTP, beliebiges TCP – wird gelöscht.
• Kill-Switch-Vorbehalte – (1) breitere Zulassungsliste als das WireGuard-Backend (udp/3478, tcp/443, das gesamte CGNAT /10). (2) Ein On-Path-Angreifer sieht immer noch Metadaten (dass Tailscale verwendet wird, DERP-Region, Timing) und kann sie löschen/verzögern – kann die getunnelte Nutzlast jedoch nicht lesen. (3) Wenn direktes UDP blockiert ist, beruht die Vertraulichkeit auf Tailscales eigenem DERP TLS mit festem Zertifikat. (4) Wenn MagicDNS ausgeschaltet ist und ein lokaler Resolver vorhanden ist, bricht DNS im aktivierten Zustand ab (UI-Warnung). (5) Captive-Portale müssen vor der Aktivierung angemeldet sein.

Gemeinsam – nur aktiviert, wenn vpn_on_untrusted_enabled gesetzt ist und das Profil lockdown ist. Bei open und balanced wird der Tunnel nicht aufgebaut, und bei Tailscale wird der Exit-Knoten gelöscht und der Kill-Switch entfernt (niemals tailscale down). Standardmäßig deaktiviert, Opt-in. Der WireGuard-Tunnel/Tailscale-Transport geht an den eigenen VPN-Endpunkt/das eigene Tailnet des Benutzers und hat nichts mit der Infrastruktur von lafine zu tun (§9).

Präventive ARP/NDP-Sperre

Sobald ein nicht vertrauenswürdiges Netzwerk beitritt, werden die MAC-Adressen der On-Link-Infrastruktur, die ein MITM-Angreifer nachahmen müsste, in der Kernel-Nachbartabelle als PERMANENT (statische) Einträge verankert. Nach dem Fixieren ignoriert der Kernel gefälschte ARP-Antworten/Nachbar-Ankündigungen.

• ___ IPv6-Nachbarn werden mit ip -6 neigh replace ... nud permanent gepinnt.
• Vertrauenswürdige Netzwerke werden nie angeheftet – ein Neustart des Heimrouters kann also nicht dazu führen, dass der Benutzer ins Schwarze getroffen wird. Auf jedem Netzwerk-Switch neu angepinnt (TOFU); Bei der nächsten Wiederherstellung der Verbindung wird ein legitimes Failover erkannt. Angepinnte Einträge werden in /var/lib/roamswitch/arp_lock.json aufgezeichnet.
• Standardmäßig aktiviert (Community Edition-Richtlinie; gleiche Aufschlüsselung wie beim macOS Pro-Build). Umschalten: gateway_arp_lock_enabled.

ARP-Spoof-Erkennung (notify-first)

Überwacht /proc/net/arp auf eine MAC, die für mehrere IPs antwortet (doppelte MAC), und auf eine verdächtige plötzliche Änderung der Gateway-MAC. Im Lockdown: Ist das Gateway beteiligt, wird der gesamte Verkehr unterbrochen (Air-Gap) und benachrichtigt. In balanced-/vertrauenswürdigen Netzwerken: nur benachrichtigen, ohne zu trennen; der Benutzer löst das Notfall-Air-Gap über RoamSwitch aus. Dies (a) verhindert, dass ein Angreifer ein einzelnes gefälschtes ARP-Paket als Waffe für einen selbstverschuldeten Ausfall nutzt, und (b) verhindert, dass ein Router-Neustart oder ein Access-Point-Roaming die Funktion versehentlich auslöst. Umschalten: arp_spoof_guard_enabled.

Prüfung der Ursache vor Aufhebung eines Air-Gap (ARP-Neuprüfung)

Ein durch ARP-Spoofing ausgelöstes Air-Gap (unter lockdown erkannt oder als Reaktion auf eine ARP-Warnung ausgelöst) wird nur dann als „Ursache beseitigt“ aufgehoben, wenn Folgendes gilt. Der Daemon liest die Neighbour-Tabelle des Kernels (ip -j neigh show, ersatzweise /proc/net/arp) und die Standardroute; die MAC des Standard-Gateways muss der bei der Auslösung gespeicherten vertrauenswürdigen MAC entsprechen (Zustand REACHABLE, STALE, DELAY, PROBE oder PERMANENT, und kein anderer IPv4-Host am selben Gerät beansprucht diese MAC), und zwar über arp_recheck_consecutive aufeinanderfolgende Prüfungen (Standard 3), die mindestens arp_recheck_min_secs Sekunden umfassen (Standard 60). Nur wenn der Neighbour-Eintrag fehlt oder fehlgeschlagen ist und die Verbindung steht (Carrier vorhanden, operstate up, WLAN nicht per rfkill gesperrt), sendet er ein einzelnes ARP-who-has an das Gateway (mindestens 20 Sekunden Abstand, über AF_PACKET) zur Prüfung (arp_recheck_active_probe, Standard true). Trägt irgendeine Antwort eine andere MAC als die vertrauenswürdige, ist das eine Abweichung. Abweichung, fehlender Eintrag, doppelte MAC, Lesefehler oder keine gespeicherte vertrauenswürdige MAC gelten alle als „nicht behoben“ (fail-closed) und setzen den Zähler zurück. Bekannte Einschränkung: Ein Angreifer, der die MAC des echten Gateways klont, ist durch keinen MAC-Vergleich erkennbar, weder aus dem Cache noch aktiv.

Ein erkannter ARP-Spoof löst das automatische Air-Gap nur aus, wenn das Gateway beteiligt ist: Die MAC des Gateways hat sich geändert, oder die IP des Gateways teilt sich eine MAC mit einer anderen IP. Ändert sich die MAC eines anderen Hosts oder antwortet ein Rechner mit einer MAC für mehrere IPs (ein PC mit virtuellen Maschinen, ein NAS mit Alias-Adresse), wird nur gemeldet und nicht getrennt. Dieselbe Regel gilt für die Freigabeprüfung: Nur ein Duplikat, an dem das Gateway beteiligt ist, zählt als „Ursache besteht fort“. Bei der Korrektur in 1.10.7 (26.09.2026) löste in einem echten LAN ein von einem anderen Rechner gesendetes gefälschtes Gateway-ARP das Air-Gap nach etwa 1 Sekunde aus; es wurde etwa 11 Minuten nach Ende des Angriffs automatisch aufgehoben (Standard 10 Minuten plus 60 Sekunden Bestätigung), auch während zwei unbeteiligte IPs weiter mit einer MAC antworteten. Vor dieser Regel löste allein dieses harmlose Duplikat eine vollständige Trennung aus und wurde nie aufgehoben.

Port Anomaly Guard

Enthält automatisch einen Überwachungsport, der neu dem externen LAN zugänglich gemacht wird (eine Hintertür, C2 oder ein Entwicklungsserver/eine lokale LLM-API, die versehentlich an 0.0.0.0 gebunden ist). Das Urteil lautet baseline-relative, nicht „gefährliche Portnummer“. Bei der Aktivierung werden die aktuell verfügbar gemachten ausführbaren Dateien als „bekannt“ erlernt; Danach wird nur eine neu erschienene verfügbar gemachte ausführbare Datei markiert (Identität = der ausführbare Pfad, Snapshots normalisiert auf snap:<name>). Systemdämonen liegen außerhalb des Gültigkeitsbereichs. Die Eindämmung erfolgt über die Tabelle inet roamswitch_dev_guard: Legen Sie TCP von einem beliebigen Ort außer lo auf diesen Port ab – die Maschine selbst verwendet ihn weiterhin. Bei der automatischen Eindämmung wird sofort ein Desktop-Benachrichtigungs- und Bestätigungsdialogfeld („Diesen Port zulassen“/„Blockiert halten“) angezeigt, der eine permanente Whitelist mit einem Klick ermöglicht. Über den Port-Diagnosebildschirm kann jeder Port auch einzeln zugelassen und die Baseline neu erfasst werden. Standardmäßig aktiviert. Umschalten: port_anomaly_guard_enabled. Portiert von macOS.

DNS-Tunneling-/Exfiltrationserkennung

Läuft durchgehend als Teil des bestehenden NFQUEUE-DNS-Pfads des passiven Link Guard (es gibt keinen eigenen Schalter dafür). Eine DNS-Abfrage wird als „verdächtig geformt“ gezählt, wenn sie eines der für DNS-Tunneling-Tools wie iodine oder dnscat2 typischen Muster aufweist — ein Abfrage-Label über 40 Byte UND eine Shannon-Entropie über 3,8, oder ein TXT-/NULL-Eintragstyp —, und es wird erst benachrichtigt, wenn innerhalb eines gleitenden 60-Sekunden-Fensters 10 oder mehr solcher Abfragen auftreten (zwischen wiederholten Benachrichtigungen für dieselbe Apex-Domain liegt eine Abklingzeit von 300 Sekunden, die bei fortlaufenden Benachrichtigungen auf 600, 1200 und höchstens 1800 Sekunden anwächst und nach einer ruhigen Phase von mindestens der doppelten Abklingzeit wieder auf 300 Sekunden zurückfällt). Geprüft wird ausschließlich DNS (UDP/TCP-Port 53); anderer Datenverkehr wird nicht untersucht. Die Funktion benachrichtigt nur und blockiert nie automatisch. Eine TXT-Abfrage an clamav.net allein wird nicht gezählt, weil freshclam sie für Aktualitätsprüfungen verwendet. Die zugrunde liegende NFQUEUE-Regel trägt das Flag bypass, sodass DNS-Datenverkehr unverändert durchgelassen wird, falls der Erkennungsprozess selbst ausfällt oder nicht reagiert — die Namensauflösung wird durch einen Ausfall dieser Funktion niemals blockiert (dasselbe Fail-open-Design wie beim passiven Link Guard selbst).

Bekannte Einschränkung — Lange, durch Bindestriche getrennte Hostnamen (etwa prod-us-east-1-web-server-node-0042) sowie die Aggregation von TXT-/NULL-Bursts über einen einzigen globalen Zähler, der nicht nach Zieldomäne unterschied, führten hier nachweislich zu Fehlalarmen. Beides wurde am 23.09.2026 behoben. Die Lösung ist eine konfigurierbare Entropie-Allowlist sowie eine nach Apex-Domain (eine einfache Näherung anhand der letzten beiden Labels des QNAME, keine strikte Public-Suffix-List-Implementierung) aufgeschlüsselte Burst-Zählung. Die Allowlist enthält standardmäßig 16 gängige CDN-/Cloud- und PaaS-Suffixe (cloudfront.net, akamaiedge.net, akamaized.net, edgekey.net, edgesuite.net, fastly.net, azureedge.net, googleusercontent.com, amazonaws.com, r2.dev, workers.dev, vercel.app, netlify.app, supabase.co, firebaseapp.com, web.app), und Administratoren können über LinkGuardCfg.dns_tunnel_entropy_allowlist eigene interne Domains hinzufügen (die Link-Guard-Einstellungen von roamswitch-app haben dafür ein eigenes Feld mit kommagetrennter Eingabe). Die Allowlist setzt nur die Prüfung aus Label-Länge und Entropie außer Kraft; die TXT-/NULL-Qtype-Erkennung greift unabhängig von der Allowlist immer, sodass ein Angreifer einen Tunnel nicht unter einer zugelassenen Domain verstecken kann (die einzige Ausnahme ist TXT unter clamav.net, das freshclam für Aktualitätsprüfungen nutzt und das über eine eigene kleine Ausnahmeliste nicht mitgezählt wird). Der Burst-Zähler ist jetzt pro Apex-Domain aufgeschlüsselt, wodurch die durch einen einzigen, zieldomänenunabhängigen globalen Zähler verursachten Fehlalarme entfallen (die Entscheidungslogik des gleitenden 60-Sekunden-Fensters ist unverändert; die Abklingzeit für wiederholte Benachrichtigungen beginnt bei 300 Sekunden und wächst bei fortlaufenden Benachrichtigungen auf höchstens 1800 Sekunden). Echter bösartiger Datenverkehr von Tools wie iodine oder dnscat2 rotiert Labels und Qtypes stets unter derselben, vom Angreifer kontrollierten Domain, sodass die Beschränkung auf eine Zählung pro Apex-Domain die Erkennungsleistung nicht mindert.

Docker-Risikoerkennung & Firewall-Umgehungsschutz

Von Docker veröffentlichte Ports (-p) sind bekanntermaßen in der Lage, die Standard-Firewall des Hosts zu umgehen. Daher werden dauerhaft Prüfregeln in die DOCKER-USER-Chain eingefügt, die jeglichen nicht ausdrücklich erlaubten externen Datenverkehr blockieren (keine Konfiguration nötig, standardmäßig aktiv). Zusätzlich wird docker events in Echtzeit überwacht, um den Moment zu erkennen, in dem ein --privileged-Container startet oder /var/run/docker.sock eingebunden wird – ein Risiko für einen Container-Ausbruch – und Sie sofort zu benachrichtigen. Da dies eine riskante Konfiguration und keine bestätigte Kompromittierung anzeigt, erfolgt nur eine Benachrichtigung ohne automatische Blockierung.

Abdeckung — Diese Prüfung der DOCKER-USER-Kette deckt das iptables-Backend (IPv4), IPv6 und das native nftables-Backend von Docker ab und prüft und repariert sich alle 60 Sekunden selbst (auch in der Desktop-Edition, ab 1.10.4; frühere Versionen deckten nur das iptables-Backend (IPv4) ab).

Scanner für Geheimnisse & API-Schlüssel-Lecks

Erkennt API-Schlüssel (OpenAI, Anthropic, AWS, GitHub, Slack, Stripe u. a.) und SSH-Private-Keys mittels Shannon-Entropie und Mustererkennung. roamswitch audit-secrets <text|Datei|Verzeichnis> durchsucht Text und Dateien sowie rekursiv ein ganzes Verzeichnis (überspringt .git, node_modules u. Ä.; Dateien über 2 MB oder die binär wirken, werden übersprungen). Dieselbe Erkennung steht auch über das MCP-Tool audit_secrets (mit text oder path) und über den Rust-Client roamswitch-linux-kit des öffentlichen SDK zur Verfügung (audit_secrets() für Text, audit_secrets_path() für eine Datei oder ein Verzeichnis). Inhalte werden niemals irgendwohin übertragen.

Erkennung und Sperrung von SSH-Brute-Force (nur solange sshd läuft)

Der Daemon der Client Edition betreibt dieselbe Engine wie die Server Edition (ssh_guard_enabled, standardmäßig true). Es gibt drei Unterschiede. Erstens arbeitet er nur, solange sshd läuft: Jede Minute prüft er, ob an den SSH-Ports etwas lauscht, und hält nach drei Fehlschlägen in Folge an. Auf einem Rechner ohne sshd liest er das Log nicht mit und berührt keine nftables-Tabelle. Zweitens sind die Einstellungen dieselben 10 Schlüssel (ssh_guard_*) mit denselben Standardwerten, abgelegt in config.json und nach etwa einer Minute wirksam. Drittens sind die Benachrichtigungen Desktop-Benachrichtigungen und ein Eintrag im Vorfallsprotokoll des Clients; ein Air-Gap startet er nie. Eine Quelle, deren Fehlversuche die Schwelle erreichen (Standard: 6 innerhalb von 600 Sekunden), verliert ihre neuen Verbindungen, und die SSH-Verbindungen, die sie bereits offen hatte, werden gleichzeitig getrennt (eine authentifizierte Sitzung und eine ausgenommene Quelle werden nie getrennt). Schützt fail2ban (mit aktivem sshd-Jail) oder CrowdSec sshd bereits, wird nur erkannt und gemeldet. Sperren werden mit sudo roamswitch bans und sudo roamswitch unban <IP> aufgelistet und aufgehoben; dafür gibt es keine GTK-Oberfläche, nur config.json und die Befehle. Bei den Standard-Schutzstufen des Clients ist eingehender Verkehr geschlossen, sodass Verbindungen SSH möglicherweise gar nicht erreichen.

Erstmaliger Setup-Assistent und Bestätigungs-Benutzeroberfläche

Das Paket wird mit /etc/xdg/autostart/roamswitch.desktop geliefert, sodass der Setup-Assistent bei der ersten Anmeldung nach der Installation gestartet wird (danach ist er nur noch in der Taskleiste vorhanden). Beim Aktivieren/Deaktivieren eines Sicherheitswächters wird ein Bestätigungsdialogfeld für dieselben Wächter wie beim macOS-Build angezeigt (Portanomalie, ARP-Auto-Containment, USB-Speicher, BadUSB-Tastatur, Bluetooth). Entscheidungen zum Ereigniszeitpunkt (eine unbekannte USB-Tastatur, ein nicht registriertes USB-Laufwerk, ein unbekannter automatisch blockierter Port, ein Notfall-Air-Gap) werden als modale Dialoge dargestellt.

§5

Shannon-Entropie-Burst-Erkennung · YARA-Scanning

Schreibereignisse werden pro PID verfolgt. Wenn ein einzelner Prozess innerhalb von 5 Sekunden 20 oder mehr verschiedene Dateien mit einer Entropie ≥ 7,92 erstellt, wird dies als Ransomware-Massenverschlüsselung behandelt: Der Prozess wird mit SIGSTOP eingefroren. Darauf folgen eine Desktop-Benachrichtigung, ein Eintrag in der Incident-Zeitleiste und ein Beweispaket. Diese Erkennung löst ebenfalls ein Air-Gap aus (die netzwerkweite Trennung) – als Auslöser mit hoher Konfidenz, wie Kanarien-Manipulation und eBPF-Ereignisse mit hohem Schweregrad.

Gemessen auf einer echten Maschine (Ubuntu 24.04, Kernel 7.0) mit einem Reproduktionsprogramm, das 40 Dateien neu schreibt (Messung vom 26.09.2026 gegen den Daemon der Version 1.10.7, die die Erkennung von Teilverschlüsselung enthält). Eine vollständige Verschlüsselung wurde nach der 20. Datei erkannt und der Prozess bei der 31. eingefroren. Auch wenn sich der Prozess in python3 oder git umbenennt, wird er erkannt: Die Allowlist prüft jetzt, dass Programmdatei und Skriptname zum Namen passen, nicht nur den Namen (früher blieben alle 40 Dateien unbemerkt). cp -r, rsync -a, tar -x und Python-Skripte werden erkannt, wenn der Schreibvorgang gesehen wird, und lösen daher auch dann keinen Fehlalarm mehr aus, wenn sie schnell enden (früher waren sie bei der Auswertung schon beendet und wurden als „unbekannter Prozess“ gemeldet). Eine Teilverschlüsselung (16 von je 32 Bytes, so wie LockBit-artige Ransomware schreibt) blieb unter dem Gesamtdurchschnitt von 7,92 und wurde früher nicht erkannt; seit 1.10.7 wird sie erkannt. Die Regel sucht nach 16-Byte-Blöcken, die zwischen zufallsähnlich und textähnlich wechseln; sie erkannte 94 % der simulierten Dateien und löste bei 19.997 gewöhnlichen Dateien 2 Fehlalarme aus (0,01 %). Ein Reproduktionsprogramm, das mit voller Geschwindigkeit ohne Pause pro Datei schreibt, hat alle 40 Dateien fertig geschrieben, bevor die Schwelle von 20 Dateien ausgewertet wird, sodass der Prozess beim Stoppen schon beendet war; mit 0,2 Sekunden pro Datei wurde er bei der 20. angehalten. Verschlüsselung nur des Dateianfangs, Verschlüsselung mit übersprungenen Bereichen und als Base64 geschriebene verschlüsselte Daten zählen nicht als Erkennung: Sie werden nur protokolliert und nichts wird eingefroren, weil sie gewöhnliche Dateien fälschlich erkennen würden. Ransomware, die in einem echten Allowlist-Programm (etwa python3) geschrieben ist, lässt sich am Namen ebenfalls nicht unterscheiden.

• Trennung von YARA-Scanning und Entropie-Tracking – Die YARA-Malware-Inspektion wird auf geschriebene Dateien ohne Ausschluss nach Dateiendung angewendet, einschließlich ~/.cache/, node_modules/ und Archiven (ausgenommen sind die vom Benutzer konfigurierten scan_exclusions, der Quarantäne-Vault, /dev/shm sowie Dateien im Arbeitsspeicher oder gelöschte Dateien, Orte wie /proc, /sys und /dev und Dateien, die von Systemprozessen wie dem Daemon selbst, ClamAV und der Desktop-Basis geschrieben werden; gelesen werden nur die ersten 256 KB einer Datei). Unterdessen schließt die Ransomware-Entropie-Burst-Analyse natürlich komprimierte Formate (.zip, .tgz, .tar.gz, .gz, .png, .jpg, .mp4, .wasm usw.), Dateien, die noch mit einem echten Komprimierungs- oder Medien-Header beginnen (seit 1.10.25), und verifizierte Paketmanager (npm, npx, cargo, rustc, dpkg, apt, tar usw.), die in Build-/Cache-Bäumen arbeiten, aus, um falsch positive SIGSTOP-Einfrierungen zu verhindern.
• Wiederholte Überschreibungen derselben Datei (z. B. die drei Durchläufe von shred) zählen als ein Ereignis.
• Schutz kritischer Prozesse – Prozesse werden mit einer fest codierten Liste geschützter Prozesse abgeglichen (PROTECTED_PROCESS_NAMES: systemd / dockerd / NetworkManager / sshd / gnome-shell usw.); ein Prozess, dessen Name übereinstimmt und dessen ausführbare Datei in einem Systemverzeichnis liegt (etwa /usr oder /opt), wird niemals eingefroren (das verhindert ein Hängen der gesamten Maschine). Ein Programm in /tmp oder /home, das nur den Namen nachahmt, ist nicht geschützt.

Regeln der Web-Anwendungsschicht (Web-Shells und eingeschleuster Code)

Eigene Regeln erkennen PHP-, JavaScript-, JSP- und ASP-Web-Shells, eingeschleusten verschleierten Code, in Bildern versteckten PHP-Code und die Übernahme der Ausführung über .htaccess. Sie sind von der eingebauten ELF- und Shell-Erkennung getrennt und in einer kleinen Sprache aus Literalen, Literalfolgen mit begrenztem Abstand und zwei Statistiken (extrem lange Zeile, riesiger Base64-Block) geschrieben. Ohne reguläre Ausdrücke kann die Auswertung weder ausufern noch hängen; selbst eine feindliche Regeldatei kann nur Fehlalarme verursachen. Keine Signatur stammt aus einer echten Probe oder ist an eine benannte Malware-Familie gebunden: Die 18 Regeln beschreiben nur öffentlich dokumentierte Techniken (Ausführung der Ausgabe eines Dekoders, direkt ausgeführte Request-Werte, ausführbares PHP in Upload-Verzeichnissen, PHP in einem Bild, .htaccess-Handler-Zuordnungen, mit unescape gebaute Injektionsskripte, Miner-Bibliotheken im Browser).

Die Regeln gibt es in drei Schichten: eingebaut, vom täglichen Updater (11.3) nach Signaturprüfung installiert und eigene Dateien in /etc/roamswitch/rules.d/*.json (gelesen werden nur Dateien, die root gehören und die Gruppe und andere nicht beschreiben können). Die Schweregrade sind critical, high, medium und low; critical und high laufen über Freigabe oder Quarantäne, medium und darunter werden nur gemeldet. Automatische Quarantäne gilt standardmäßig nur für critical (quarantine in /etc/roamswitch/web_rules.conf); in der Client-Edition entscheidet bei einer Erkennung beim Schreiben oder Ausführen weiterhin der Benutzer im Freigabedialog. Alles unter tests/, fixtures/ und .git/ wird standardmäßig übersprungen, weil Testcode dieselben Konstrukte zitiert.

Nach einer Erkennung erhält eine ausführbare Datei unter /etc/roamswitch/hooks/post-detection die Treffer als JSON auf der Standardeingabe (ausgeführt wird nur eine root gehörende, nicht beschreibbare Datei in einem sicheren Verzeichnis; keine Shell, minimale Umgebung, Abbruch nach 30 Sekunden). Die optionale Kontomaßnahme (standardmäßig aus) sperrt die Login-Shell des Besitzers einer isolierten Datei. Sie tut nichts für root, Konten unter account_min_uid (Standard 1000), angemeldete Benutzer und den Benutzer des Daemons; die frühere Shell wird gespeichert und roamswitch web-rules unlock-account stellt sie wieder her. Gemessene Fehlalarme: 0 in WordPress-Kern (2.409 Dateien), phpMyAdmin (3.356 Dateien) und npm-Abhängigkeiten (14.743 Dateien). Grenzen: Gelesen werden nur die ersten 256 KB (beim Schreiben/Ausführen) bzw. 4 MB (Scan), zerlegte Namen wie 'ev'.'al' werden nicht verfolgt, und mangels echter Proben werden keine Signaturen für einzelne bekannte Malware mitgeliefert.

Kanarienvögel (Köderdateien)

Decoy-Dateien werden in den Ordnern „Dokumente“, „Desktop“, „Downloads“ und „Bilder“ des Benutzers sowie in einem speziellen Verzeichnis abgelegt und in einem 3-Sekunden-Zyklus mit einer SHA-256-Basislinie verglichen. Jede Umbenennung, Löschung, Kürzung oder Inhaltsänderung löst Air-Gap sofort aus. Da der Daemon als Root ausgeführt wird, zählt er /home/* auf und stellt Canaries in den Verzeichnissen jedes echten Benutzers bereit.

Forensische Beweissicherungs-Bundles

Nur wenn die Ransomware-Entropie-Burst-Überwachung auslöst oder ein Ereignis der Schwere Critical des eBPF-Laufzeit-Bedrohungssensors eine prozessgenaue Eindämmung (SIGSTOP plus Netzwerkisolation) zustande bringt, wird roamswitch-incident-capture gestartet und sichert ein Beweis-Bundle unter <Statusverzeichnis>/incident-evidence/<Zeitstempel>-<Kurz-ID>/. Erfasst werden: eine begrenzte, 30 Sekunden lange Paketaufzeichnung per tshark auf der Standard-Routing-Schnittstelle (als übersprungen vermerkt, falls tshark nicht installiert ist) sowie, wenn eine PID übergeben wird, ein /proc/<pid>-Snapshot des betroffenen Prozesses (status, cmdline, maps, ein environ mit als Geheimnisse erkannten Werten, ersetzt durch [REDACTED], eine Liste der Ziel-Links offener Dateideskriptoren — deren Inhalt wird nicht erfasst — sowie die Kette der Vorgängerprozesse). Das Scheitern eines einzelnen Artefakts gilt nicht als fataler Fehler; es wird vermerkt, und die übrige Erfassung läuft weiter. Bei eBPF-Ereignissen wird die PID des betroffenen Prozesses übergeben. Bei der Entropie-Burst-Überwachung wird die PID übergeben, wenn sich der schreibende Prozess identifizieren ließ; war dieser Prozess bei der Auswertung des Bursts schon beendet, startet das Werkzeug ohne PID und erfasst nur die Pakete. Die Beweissicherung läuft nicht, wenn die prozessgenaue Eindämmung nicht möglich ist oder fehlschlägt und auf eine hostweite Air-Gap-Isolation zurückfällt, ebenso wenig bei Ereignissen der Stufe Emergency/Alert, die direkt eine hostweite Isolation auslösen. Die Pakete bis 1.10.4 enthielten das für diese Funktion nötige roamswitch-incident-capture nicht, sodass sie bei Installationen aus den Paketen nicht lief. Seit 1.10.5 ist es enthalten.

Die Ergebnisse werden in manifest.json festgehalten, das zusätzlich den SHA-256-Hash jeder anderen Datei im Bundle einbettet (damit nachträgliche Manipulation erkennbar ist). Bundles werden nie automatisch gelöscht — alte Bundles werden nur entfernt, wenn roamswitch-incident-capture prune (Standardaufbewahrung: 30 Tage) explizit ausgeführt wird.

Erfasste Beweise werden zum Zeitpunkt der Erfassung nicht verifiziert. Um nachträglich auf Manipulation zu prüfen, führen Sie roamswitch-incident-capture verify <Bundle-Verzeichnis> [--json] aus. Der Befehl berechnet die Hashes aller aktuell im Bundle vorhandenen Dateien neu, gleicht sie mit den in manifest.json erfassten Werten ab und meldet jede Abweichung einzeln als geändert, fehlend oder nicht erfasst (eine Datei, die im Manifest nicht verzeichnet ist).

Bekannte Einschränkung — Diese Prüfung vergleicht den SHA-256 von manifest.json mit Aufzeichnungen außerhalb des Bündels, und zwar an zwei Stellen: einer Hash-Kette außerhalb des Bündels (evidence_anchor.log, jede Zeile bindet sich an die vorherige, wo das Dateisystem es erlaubt nur zum Anhängen gesetzt) und dem Systemlog (Tag roamswitch-evidence). Wird manifest.json nach der Erfassung umgeschrieben, schlägt verify fehl; ebenso, wenn eine Zeile der Kette geändert oder entfernt wird, weil die Kette dann reißt. Ein Angreifer mit root, der sowohl die Kette als auch das Ziel der Systemlog-Weiterleitung umschreiben kann, wird dadurch nicht aufgehalten; empfohlen wird, das Systemlog an einen anderen Rechner weiterzuleiten. Signaturen sind nicht umgesetzt. Ein Bündel ohne Eintrag (von einer älteren Version erfasst) wird als „kein Eintrag“ gemeldet, d. h. es gibt keine Bestätigung von außen.

Honeytokens (Anmeldedaten-Köder)

Beim Start des Daemons legt RoamSwitch idempotent Köder-Anmeldedateien an bekannten, tatsächlich von Angreifern und automatisierten Tools zum Diebstahl von Anmeldedaten durchsuchten Pfaden ab — ~/.aws/credentials, ~/.ssh/id_rsa und ~/.docker/config.json, ~/.pypirc, ~/.env.backup (im Home-Verzeichnis des aufrufenden Benutzers) —, jeweils mit dem Marker ROAMSWITCH_HONEYTOKEN. Existiert an einem dieser Pfade bereits eine echte Datei, wird sie niemals überschrieben (vor der Bereitstellung wird stets zuerst geprüft, ob die Datei existiert). Ein tatsächlicher Zugriff auf ein Honeytoken kann zudem eine kaskadierende Bereitstellung weiterer, verwandter Köder auslösen. Die Pakete bis 1.10.4 enthielten das für diese Funktion nötige roamswitch-honeytokens nicht, sodass sie bei Installationen aus den Paketen nicht lief. Seit 1.10.5 ist es enthalten. Seit 1.11.1 wird jeder docker-Befehl, den RoamSwitch selbst ausführt, mit einem leeren, privaten Verzeichnis als DOCKER_CONFIG gestartet und löst daher den Köder ~/.docker/config.json nicht aus. Ein Lesezugriff durch ein anderes Programm wird weiterhin wie bisher erkannt.

Ein Hintergrundwächter überwacht mit benachrichtigendem fanotify (FAN_OPEN/FAN_ACCESS pro Datei auf jedem Köder) das Lesen und Öffnen jedes Köders; wo fanotify nicht verfügbar ist (etwa bei Ausführung ohne Root), wechselt er zu inotify. Da kein legitimer Prozess einen Grund hat, diese Dateien zu lesen, wird jeder Zugriff als starkes Signal für eine Aufklärung durch einen Angreifer nach einer Kompromittierung gewertet (MITRE ATT&CK T1552); RoamSwitch versucht, den zugreifenden Prozess zu identifizieren, und erfasst das Ereignis mit der Schwere Critical in der Incident-Zeitleiste (es erscheint kein Desktop-Popup; bei aktivierter Ereignisweiterleitung wird es weitergeleitet). Zugriffe durch die eigenen ausführbaren Dateien von RoamSwitch sowie durch die OpenSSH-Client-Familie (ssh, scp, sftp, ssh-add, ssh-agent) auf die SSH-Köder werden nicht erfasst, um Fehlalarme zu vermeiden; ein Zugriff, dessen ausführbare Datei sich nicht identifizieren lässt, wird erfasst. Dies dient ausschließlich der Aufzeichnung — der zugreifende Prozess wird dadurch weder eingefroren noch blockiert.

Bekannte Einschränkung — Der Inhalt des ~/.ssh/id_rsa-Köders enthält lesbaren Text und bleibt als Base64-Rumpf eines echten OpenSSH-Privatschlüssels ungültig. Da die meisten Secret-Scanner Dateien jedoch allein anhand eines Regex-Treffers auf den Header -----BEGIN ... PRIVATE KEY----- markieren, schätzen wir die Auswirkung auf die tatsächliche Erkennungsrate als gering ein. Außerdem wird der zugreifende Prozess normalerweise anhand der PID des fanotify-Ereignisses identifiziert; nur wenn fanotify nicht verfügbar ist und auf inotify umgeschaltet wird, kommt ein fuser-Aufruf zum Einsatz, der bei sehr kurzlebigen Prozessen, die sich unmittelbar nach dem Lesen der Datei beenden, PID und Prozessname möglicherweise nicht ermitteln kann. In diesem Fall wird der Prozess lediglich als unbekannt erfasst; die Erkennung des Zugriffs selbst (Ereignisauslösung und Erfassung) ist davon nicht betroffen.

Fanotify-Überwachung · Quarantäne-Tresor · ClamAV

• Der Daemon überwacht /home, /tmp, /var/tmp und /dev/shm mit Marken auf Dateisystemebene (seit 1.10.18; eine Marke auf Mount-Ebene ist nur der Ersatz, falls eine Dateisystem-Marke abgelehnt wird) und überwacht die Schreibabschlüsse auf / insgesamt ebenfalls auf Dateisystemebene, und zwar über FAN_CLASS_CONTENT (Berechtigungsmodus; Fallback FAN_CLASS_NOTIF). Ab 1.10.4 gelten Berechtigungsereignisse nur für die Ausführung (FAN_OPEN_EXEC_PERM); open wird als Benachrichtigung behandelt (mit fanotify_open_perm lässt sich das frühere Verhalten wiederherstellen). Bereits als sauber geprüfte ausführbare Dateien werden 60 Sekunden zwischengespeichert, und die eigenen Kindprozesse des Daemons werden von der Überwachung ausgenommen.
• Notify-first, keine Quarantäne vor Bestätigung (fanotify-Wächter). Ein bloßer YARA-/ClamAV-Treffer führt im fanotify-Wächter nie zu einer Quarantäne ohne Bestätigung oder zu FAN_DENY. Eine echte Signatur löst eine modale Anfrage in /run/roamswitch/approvals.json (Quarantäne/Zulassen/Später) aus; nichts gelangt in den Tresor, bis der Benutzer dies bestätigt. Nur ein tatsächlicher execve erhält FAN_DENY, und nur, wenn pre_exec_blocking_enabled aktiviert ist. Die Genehmigung läuft bei Fail-open ab. Die Download-Überwachung (standardmäßig ~/Downloads und ~/Desktop, ergänzt durch watched_folders) ist ein eigener Pfad: Eine Datei, die YARA oder ClamAV (außer EICAR) meldet, wird ohne Rückfrage sofort in den Quarantäne-Vault verschoben, und eine Benachrichtigung folgt.
• Testsignaturen wie EICAR werden nur im Verlauf erfasst – die branchenübliche Testzeichenfolge löst keine Benachrichtigung aus, sondern erzeugt nur einen Eintrag im Benachrichtigungsverlauf, und wird weder im Fanotify-Guard noch im Download-Guard unter Quarantäne gestellt oder blockiert.
• Eine vom Benutzer konfigurierte scan_exclusions-Pfadliste (absolute Pfade, rekursiv angewendet; sie fasst das alte clamav_exclusions zusammen) wird sowohl von den YARA- als auch den ClamAV-Scannern berücksichtigt. „Zulassen“ in der Eingabeaufforderung und „Wiederherstellen“ in der Registerkarte „Quarantäne“ werden beide daran angehängt, sodass dieselbe Datei nicht erneut markiert wird.
• Erkannte echte Malware (im fanotify-Wächter nur, was der Benutzer bestätigt hat) wird in das nur für Root zugängliche Verzeichnis /var/lib/roamswitch/quarantine/ verschoben (früher lag sie im jeweiligen ~/.local/share/roamswitch/quarantine/ des Benutzers; der alte Speicherort wird beim Start automatisch migriert). Das Vault-Verzeichnis gehört root und hat 0700; jede Probe gehört root und hat 0400 (schreibgeschützt, nicht ausführbar). Benutzer können den Vault nur über das IPC des Daemons bedienen und nur die selbst unter Quarantäne gestellten Einträge auflisten, wiederherstellen und löschen. Eine Wiederherstellung schreibt ein Kindprozess, der auf die Rechte des aufrufenden Benutzers heruntergestuft wurde, als Datei mit 0644 (eine vorhandene Datei wird nie überschrieben).
• Die Berechtigungsereignisschleife liest die Konfigurationsdatei nie – die Konfiguration wird von einem dedizierten Hintergrundthread in einen Mutex<GuardConfig>-Snapshot gelesen; die Hot-Path-Zugriffe auf die Konfiguration sperren und kopieren nur (das Lesen des Dateianfangs der auszuführenden Datei zur Beurteilung ist davon getrennt). Dies ist eine Designinvariante: Ein Blockieren auf FAN_OPEN_EXEC_PERM würde die Maschine einfrieren.
• Wenn ClamAV vorhanden ist (clamav_enabled, standardmäßig aktiviert), werden neue Dateien, die in den überwachten Ordnern der Download-Überwachung erscheinen (standardmäßig ~/Downloads und ~/Desktop), nach dem eingebauten YARA-Scan anhand der lokalen Datenbank gescannt. Ausführbare Windows-Formate wie .exe lösen eine Benachrichtigung aus, Linux-Verteilformate (.sh, .deb, .elf usw.) werden nur im Verlauf vermerkt, und gefährliche KI-Modelle (.pkl, .pt) lösen eine Benachrichtigung mit Angabe der Herkunft aus. ClamAV ist eine optionale Abhängigkeit; die anderen Abwehrmechanismen funktionieren auch ohne. Ist es installiert, ruft der tägliche Updater (§11) freshclam auf, damit die Signaturdatenbank aktuell bleibt.

Prozess-Ausführungsrekorder (nur lokal)

Ein rein lokaler Rekorder, der exec-Ereignisse und uid-Wechsel über den netlink-Prozess-Connector (proc connector) protokolliert. Er erfasst Programmpfad, Kommandozeilenargumente (auf 64 Argumente, je 512 Zeichen und insgesamt 4096 begrenzt, Steuerzeichen maskiert), Elternprozess-Abstammung, uid, Arbeitsverzeichnis, Container-ID, SHA-256 der ausführbaren Datei u. a. Er ist standardmäßig aktiv, standardmäßig aber aus auf Maschinen mit weniger als 1 GiB RAM (eine ausdrückliche Einstellung von exec_recorder_enabled hat Vorrang). Die eigene CPU-Nutzung ist auf 3 % eines Kerns begrenzt (exec_recorder_cpu_budget_pct); er läuft mit nice 10. Lässt sich der Prozess-Connector nicht öffnen, fällt er auf einen seltenen /proc-Scan zurück (kurzlebige Prozesse werden dabei verpasst).

• Speicherung — die Einträge liegen unter /var/lib/roamswitch/exec_log als in 8-MiB-Segmente aufgeteilte JSON Lines (0600). Standardmäßige Aufbewahrung: 200 MB / 14 Tage (exec_recorder_retention_mb / exec_recorder_retention_days). Eine Hash-Kette macht Manipulation erkennbar, aber nicht verhinderbar (ein Angreifer mit Root kann die gesamte Kette neu schreiben). Suche mit roamswitch events search|tree|export|verify; die schreibgeschützten MCP-Werkzeuge für KI-Clients sind search_exec_events und get_process_tree.
• Nur benachrichtigende Korrelationsregeln (EXR-001 bis EXR-010) — zehn Regeln: eine von einem Webdienst gestartete Shell, Ausführung aus /tmp, einer Speicherdatei (memfd) oder einer gelöschten Datei, Ausführung unmittelbar nach einem Download, ein base64/eval-Einzeiler, Erlangen von uid 0 ohne setuid-Pfad, Ausführung einer Binärdatei, die direkt nach einer cron/systemd-Änderung abgelegt wurde, Ausführung nach einer Änderung an /etc/ld.so.preload, ein lokaler Dateisystem-Snapshot (btrfs, LVM), der von etwas anderem als einem bekannten Verwaltungswerkzeug wie snapper oder timeshift gelöscht wurde (EXR-008, 1.10.11), derselbe Akteur, der innerhalb von 30 Sekunden mit which und Ähnlichem nach 8 oder mehr Angriffswerkzeugen sucht (EXR-009, 1.11.0), sowie eine Skript-Laufzeitumgebung wie python oder node, die innerhalb von 2 Minuten 3 oder mehr Angriffswerkzeuge startet (EXR-010, 1.11.0; ausgenommen ist die Eingabe durch einen Menschen unter sshd, login oder einem Terminal). Jede Regel trägt eine MITRE-ATT&CK-Technik-ID. Regeln benachrichtigen nur und isolieren nie allein; nur wenn ein Betreiber exec_rules_isolation_optin (Standard false) ausdrücklich aktiviert, wird eine Regel mit hohem Schweregrad als Air-Gap-Auslöser mit hoher Konfidenz behandelt (§4).
• Nichts verlässt die Maschine — das Rohprotokoll wird nie weitergeleitet. Nur wenn die Ereignisweiterleitung (§9.4) aktiviert ist, werden die Regelmeldungen (Schweregrad, Regel-ID, Prozessname, Zusammenfassung) und die Segment-Siegel-Hashes gesendet, und zwar nur an das vom Betreiber konfigurierte Ziel.

Überwachung des Zugriffs auf Zugangsdaten-Dateien (standardmäßig an, nur Benachrichtigung)

Standardmäßig an (credential_access_watch_enabled ist true; mit false wird es abgeschaltet, auch über den Schalter im Malware-Guard-Bildschirm). Es benachrichtigt, wenn ein unerwartetes Programm einen SSH-Privatschlüssel (~/.ssh/id_*), ~/.aws/credentials, die Zugangsdatendateien unter ~/.config/gcloud/ (vier Arten, etwa credentials.db) oder den Zugangsdaten-/Cookie-Speicher eines gängigen Browsers öffnet (nur Benachrichtigung). Es setzt lediglich das fanotify-Benachrichtigungsereignis FAN_OPEN auf wenige einzelne Dateien, blockiert nie etwas, friert nie etwas ein und verweigert nie etwas, und der Kernel wartet nicht auf eine Antwort. Der Name der ausführbaren Datei des öffnenden Programms wird mit nach Art getrennten Zulassungslisten (ssh / git / gpg-agent, Browser, aws / terraform / kubectl usw.) abgeglichen; wiederholte Meldungen für dasselbe (Programm, Datei)-Paar werden 10 Minuten lang unterdrückt. Backup-Werkzeuge (restic, borg usw.) und Indexer (tracker, baloo usw.) sind von Anfang an erlaubt. Weitere Programme, für die Sie keine Meldungen wollen, tragen Sie in credential_access_watch_allow in der config.json ein. Bei AWS-Zugangsdaten sind Werkzeuge erlaubt, die als python, python3 oder ansible laufen, etwa boto3-Skripte und Ansible (bei gcloud python und python3); ein Einzeiler wie python -c löst dennoch eine Meldung aus. Der Preis dieser Erlaubnis ist, dass auch ein Programm zum Diebstahl von Zugangsdaten, das als python-Skriptdatei läuft, keine Meldung auslöst. Andere Interpreter wie node oder ruby sowie allgemeine Such- und Synchronisierungswerkzeuge wie grep oder rclone sind bewusst nicht erlaubt, weil ein Programm, das Zugangsdaten stiehlt, genauso aussieht; sie können daher Meldungen auslösen. Ein sehr kurzer Lesezugriff wie bei cat oder head, bei dem sich das Programm beendet, bevor RoamSwitch seine ausführbare Datei bestimmen kann, wird möglicherweise nicht gemeldet (ein Lesezugriff durch ein Programm, das eine Weile weiterläuft, wird gemeldet). RoamSwitch nutzt zur Umgehung dieser Grenze nicht das fanotify der Berechtigungsklasse, weil es das System anhalten könnte. Änderungen wirken nach etwa 30 Sekunden, ohne Neustart.

Der Einbruchsweg in Benachrichtigungen über Dateimanipulation

Auch die Benachrichtigungen der Überwachung wichtiger Dateien (FIM) des Clients und der Überwachung von Abhängigkeits-Lockfiles nennen den Prozess, der die Änderung vorgenommen hat (Konto, ausführbare Datei, Befehl), und die SSH-Anmeldung, zu der er gehört (Quelle, Zeit, Authentifizierungsmethode). Das ist fim_intrusion_context_enabled in config.json, standardmäßig true; es wird nichts nach außen gesendet. Eine Benachrichtigung über den Zugriff auf eine Zugangsdaten-Datei erhält nur dann eine zusätzliche Zeile, wenn der Prozess zu einer SSH-Anmeldung gehört. Wie es funktioniert, welchen Werten es traut und welche drei Antworten es auseinanderhält (gefunden / keine SSH-Anmeldung gefunden / Anmeldeweg nicht ermittelbar), ist wie in der Server Edition. Was nicht geprüft werden konnte, wird nie als „keine Anmeldung“ gemeldet. Die Aufzeichnung liegt in /var/lib/roamswitch/fim_intrusions.json und im Feld recentIntrusionContext des MCP-Tools verify_fim.

Kernel Local Privilege Escalation (LPE) Preemption & Hardening

Wenn ein Angreifer oder eine Schadsoftware unprivilegierten Benutzern Zugang verschafft, verhindert die Tiefenverteidigung, dass Schwachstellen im Linux-Kernel ausgenutzt werden, um Root-Rechte zu erlangen.

• Umgang mit nicht privilegierten User-Namespaces (Frag Gap CVE-2026-53362 Abschwächung) — Viele moderne Linux-Kernel-LPE-Schwachstellen beruhen darauf, dass nicht privilegierte Benutzer mit unshare(CLONE_NEWUSER) isolierte User-Namespaces anlegen und darin auf nicht initialisierte Kernel-Strukturen oder ältere Netzwerk-Subsysteme zugreifen. Die Diagnose prüft und zeigt den Zustand von user.max_user_namespaces und kernel.unprivileged_userns_clone an; da eine Deaktivierung jedoch Browser, Flatpak, Electron und Rootless-Container beeinträchtigen kann, empfiehlt die Client-Edition sie nicht und nimmt sie nicht in das One-Click-Hardening auf (ist user.max_user_namespaces = 0 gesetzt, rät der Bericht, den Standardwert wiederherzustellen). Die Deaktivierung ist eine Übergangslösung, die nur Angriffswege schließt, die einen User-Namespace benötigen; andere Wege stoppt sie nicht. Das Setzen von kernel.unprivileged_userns_clone = 0 nur während eines nicht vertrauenswürdigen Netzwerks wird nur angewendet, wenn Sie adaptive_security.untrusted_network_actions.auto_enable_userns_restriction in guard.yaml ausdrücklich aktivieren (standardmäßig deaktiviert; auf Kerneln ohne diese Einstellung bewirkt es nichts). Die Server Edition wendet es standardmäßig dauerhaft an (harden_userns_enabled). Die eigentliche Lösung ist ein Update auf einen gepatchten Kernel und ein Neustart.
• Yama LSM-Speicherschutz – Durch die Durchsetzung von kernel.yama.ptrace_scope = 1 (oder 2) wird verhindert, dass nicht autorisierte Prozesse über ptrace eine Verbindung herstellen oder über /proc/$pid/mem den Speicher lesen, wodurch Browsersitzungen und private GPG/SSH-Schlüssel geschützt werden.
• Core Dump Suppression – Die Einstellung fs.suid_dumpable = 0 verhindert, dass abstürzende sensible Prozesse Klartext-Speicherauszüge auf die Festplatte schreiben.
• __

# eBPF-Laufzeit-Bedrohungserkennung & autonomer Abwehrfluss
[Bösartiger Prozess (LPE/Malware)]
    │ Illegale Syscall-Ausführung (Frag-Gap-Ausnutzungsversuch)
    ▼
[Linux-Kernel (eBPF-Sonde)]
    │ eBPF-Ringpuffer (kompaktes 2-MB-Design)
    ▼
[Falco (RoamSwitch Optimized)]
    │ Direkter UNIX-Socket im Arbeitsspeicher (/var/run/roamswitch/events.sock)
    ▼
[roamswitch-daemon (root)]
    ├─► ① Millisekunden-Einfrieren des angreifenden Prozesses: kill(pid, SIGSTOP) [Zustand: Ts]
    ├─► ② Netzwerksperre: Critical nur für den Benutzer des Prozesses (roamswitch_isolate), Emergency/Alert nftables input/output drop [Air-Gap aktiviert]
    └─► ③ Desktop-Notfallwarnung: GTK3-Modal & libnotify-Benachrichtigung