Whitepaper zu RoamSwitch-Architektur und -Sicherheit

§1

RoamSwitch ist eine Menüleisten-App für den Mac. Je nachdem, wie sehr Sie dem Netzwerk vertrauen, dem Sie vertrauen aktuell verbunden, schaltet es automatisch die macOS-Firewall, die Freigabedienste, AirDrop usw. um. und DNS. Es überwacht auch ARP-Spoofing, nach außen offene Ports, USB-Speicher usw Ransomware-ähnliche Verschlüsselungsaktivitäten, und wenn etwas Gefährliches entdeckt wird, geht es so weit Unterbrechen des Datenverkehrs mit dem Paketfilter (pf) – ein Notfall-Air-Gap.

Mit anderen Worten: RoamSwitch installiert einen Root-privilegierten Daemon und könnte, wenn er wollte, alle stoppen Netzwerkverkehr auf dem Mac. Es wird von einer Person gebaut und „Bitte vertrau mir“ reicht nicht aus rechtfertigen Sie dieses Privileg. Stattdessen erklärt dieses Dokument das Design in einer Form, die Sie überprüfen können.

Für wen das ist

• Ingenieure entscheiden über die Installation
• Sicherheitsforscher und Journalisten, die vor einer Rezension oder einem Artikel die Interna verstehen wollen
• Sicherheitspersonal bei Partnerunternehmen evaluiert einen internen Rollout oder eine OEM-Bündelung

Was dieses Dokument nicht abdeckt

Es geht nicht um die Optimierung der Erkennungsschwelle, falsch-positive Statistiken oder exemplarische Vorgehensweisen für die Benutzeroberfläche. Es erklärt vier Dinge: Privilegien, Prozessgrenzen, Datenfluss und Kryptographie. Die Funktionsspezifikationen selbst befinden sich in der gebündelten MCP-Ressource roamswitch://docs/features und in der In-App-Hilfe.

Was wird offengelegt und wie weit (Offenlegungsrichtlinie)

Dieses Dokument basiert auf der Annahme, dass ein Angreifer bereits über die verteilte Binärdatei verfügt. Alle Endpunkt-URLs, Kennungen, Dateipfade, XPC-Protokolle und eingebetteten öffentlichen Schlüssel, die hier angezeigt werden kann in wenigen Minuten aus dem Versand RoamSwitch.app gezogen werden strings, codesign -d oder ein Verkehrsproxy. Schreiben Sie sie daher hier auf gibt einem Angreifer nichts Neues. Der einzige Fortschritt ist das Verständnis des Rezensenten.

Andererseits ist die serverseitige Implementierung nicht aus der Binärdatei ersichtlich – Rate-Limit Schwellenwerte, Schlüssel, Admin-Endpunkte, das DB-Schema, das Firebase-Projektlayout – sind nicht enthalten. Das OEM- und Partner-Integrationsdesign liegt hier ebenfalls nicht im Rahmen und wird separat behandelt internes Dokument. „Was man durch die Beobachtung des Klienten lernen kann“ lautet die Offenlegungszeile hierfür Dokument.

§2

RoamSwitch.app besteht aus drei ausführbaren Dateien. Nur einer von ihnen ist privilegiert; die Die anderen beiden werden mit Login-Benutzerrechten ausgeführt. Alle drei werden mit aktivierter Hardened Runtime und Entwickler-ID ausgeliefert unterzeichnet und notariell beglaubigt.

Berechtigungen und Unterzeichnung

• Alle drei Ziele haben ENABLE_HARDENED_RUNTIME = true.
• App Sandbox ist deaktiviert (com.apple.security.app-sandbox = false). Die Berechtigungen des Helfers und des MCPServers sind leere Wörterbücher.
• Distributions-Builds werden vom Entwickler-ID-Antrag unterzeichnet, von Apple notariell beglaubigt und geheftet (§10).

§3

Wie es registriert wird

Der Helfer wird mit SMAppService.daemon(plistName:) als LaunchDaemon registriert. Die plist in die App eingebettet (Contents/Library/LaunchDaemons/com.tetsuharu.RoamSwitch.Helper.plist) deklariert nur Label, BundleProgram, ein einzelner MachServices-Eintrag und AssociatedBundleIdentifiers. Aufgrund der Funktionsweise von SMAppService Eine Registrierung ist nicht einmal möglich, es sei denn, die App ist in /Applications. Am ersten Nach der Registrierung wird der Helfer erst dann aktiv, wenn der Benutzer ihn im System manuell genehmigt Einstellungen.

Wessen Verbindungen es akzeptiert (ClientValidator)

Der Helfer überprüft den Verbindungsvorgang in NSXPCListeners shouldAcceptNewConnection und verteilt HelperProtocol nur an diejenigen, die passieren. Die Inspektion verwendet den audit_token anstelle der PID Vermeiden Sie die Wiederverwendung von PIDs und TOCTOU.

# Code-Signing-Anforderungen, die der Release-Build an verbindende Clients stellt
identifier "com.tetsuharu.RoamSwitch"
  and anchor apple generic
  and certificate leaf[subject.OU] = "GV76B6G4YU"

Diese Anforderung wird mit SecCodeCopyGuestWithAttributes und überprüft SecStaticCodeCheckValidity, und die Verbindung wird getrennt, wenn sie nicht erfolgreich ist. Nur DEBUG-Builds verzichten aus Gründen der Entwicklungsfreundlichkeit auf die Team-ID-PIN. Was tatsächlich versendet wird, ist immer ein Release-Build.

Was der Helfer tun kann (die vollständige Liste)

Die in Shared/HelperProtocol.swift definierten privilegierten Operationen sind alle davon. Es gibt keine privilegierte API, die hier nicht aufgeführt ist.

Zustand im Helfer

• HelperTool.shared ist eine einzelne Instanz, die von allen Verbindungen gemeinsam genutzt wird. Früher war es eine separate Instanz pro Verbindung, sodass eine Notfalleindämmung, die eine neue Verbindung öffnete, zu einem Rennen führen konnte, bei dem der Überblick darüber verloren ging, „welche Dienste wiederhergestellt werden sollten“.
• Der Sharing-Service und die DNS-Backups werden nur in einer seriellen Warteschlange (stateQueue) mutiert.

Rechtetrennung im Helper und die Ausnahme zum Lesen des SSH-Protokolls

Der Helper legt sich gleich nach dem Start selbst eine vom Kernel durchgesetzte Obergrenze auf (eine Laufzeit-Sandbox, die nichts mit dem oben genannten App-Sandbox-Entitlement zu tun hat); auch die von ihm gestarteten Kindprozesse erben sie. Sie verhindert das Ersetzen von Systemprogrammen, das Registrieren eines LaunchDaemon oder LaunchAgent, das Umschreiben der Konfiguration von sudoers, PAM oder sshd, das direkte Schreiben in den lokalen Verzeichnisspeicher und das Ausführen von Programmen aus Orten, in die Benutzer, externe Volumes oder temporäre Ordner schreiben können. Nicht verhindert werden Kontoänderungen über Open Directory (dscl), und den Netzwerkverkehr schränkt sie nicht ein (dafür ist die Obergrenze nicht gedacht).

Unter dieser Obergrenze läuft /usr/bin/log nicht. Unter macOS 26 weigert sich log, innerhalb einer Sandbox zu laufen (log: Cannot run while sandboxed), und ebenso als nobody (Must be admin). Damit können weder die App des angemeldeten Benutzers noch der root-Helper in seiner Sandbox das sshd-Protokoll (das einheitliche Protokoll) lesen. Die SSH-Brute-Force-Erkennung muss dieses Protokoll lesen, deshalb gibt es in der Rechtetrennung eine Ausnahme.

Die Ausnahme ist ein kleiner root-Prozess: Bevor der Helper in seine Sandbox geht, startet er dieselbe Binärdatei mit --ssh-log-reader. Dieser Prozess nimmt nur einen Ein-Byte-Befehl (Start oder Stopp) an und startet nichts weiter als /usr/bin/log mit festen Argumenten (log stream --style ndjson --level info und einer festen Bedingung, die nur sshd-Zeilen durchlässt). Er gibt keine Umgebungsvariablen weiter, und der Aufrufer hat keine Möglichkeit, Argumente oder einen Befehl vorzugeben. Er liest und interpretiert das Protokoll nicht; die Ausgabe fließt in eine Pipe, die der Helper übergeben hat.

Logzeilen enthalten Zeichenfolgen, die ein Angreifer schreiben kann, etwa den Benutzernamen; deshalb interpretiert der root-Helper sie nicht. Er übergibt jede Zeile an einen Parse-Worker, der als nobody in einer Sandbox läuft, die Netzwerkzugriff, Dateischreibzugriffe sowie das Starten und Forken von Prozessen verbietet, und die Quelladresse stammt vom Zeilenende (IP port N), auf das der Benutzername keinen Einfluss hat. Auf einem Mac mit ausgeschalteter Entfernter Anmeldung startet dieser Prozess log nicht und liest nichts. Über die XPC-Schnittstelle des Helpers lassen sich fünf SSH-Operationen aufrufen: Einstellungen anwenden, Status, Einträge und Anmeldungen abrufen und eine Sperre aufheben. Keine davon nimmt einen Befehl entgegen.

§4

Vier Funktionen berühren Pf: den Notfall-Air-Gap, den Dev-Server-Port-Guard und die VPN-Tunnel WireGuard-Kill-Switch (§5, 1.7.6+) und sein Tailscale-Kill-Switch (§5, 1.8.0+ – nur die ausgewählten Backends). Alle gehen immer über einen einzelnen Einstiegspunkt, PFRulesetCoordinator, und wird niemals ausgeführt pfctl -f selbst.

Warum es einen einzigen Einstiegspunkt gibt

Zuvor luden die beiden Funktionen jeweils unabhängig voneinander Regeln mit pfctl -f und konkurrierten über den einzigen Hauptregelsatz von pf. Wenn die enge Regel des Hafenwächters block ... port {…} war Nachdem der Luftspalt block drop all geladen wurde, könnte es zu einem Zustand kommen, in dem der Bildschirm nicht mehr funktioniert sagte „isoliert“, aber der Mac war immer noch erreichbar. Dieser Fehler wurde durch einen tatsächlichen Angriff auf gefunden Maschine von einem anderen Host und wurde in 1.4.3 behoben (die Geschichte ist geschrieben in docs/marketing/zenn/03_lan_side_attack_test.md).

Wie es jetzt funktioniert

• Jedes Mal vollständig neu erstellt. Der gesamte erforderliche Regelsatz wird ausgehend vom aktuellen Status neu erstellt und auf einmal angewendet. Es wird niemals als Diff angewendet.
• Eine serielle Warteschlange. Jede PF-Änderung wird auf demselben DispatchQueue ausgeführt. Unabhängig davon, ob sie von einer XPC-Verbindung, dem Start des Hilfsprogramms oder dem Failsafe-Timer stammt, werden Änderungen der Reihe nach verarbeitet.
• Die Prioritätsreihenfolge ist wie folgt (weiter oben stehende Einträge haben Vorrang).
  1. Notluftspalt → set skip on lo0 und block drop all (nichts anderes wird berücksichtigt)
  2. VPN-Kill-Switch → block drop all plus pass quick nur für: lo, die Tunnelschnittstelle (utunN), den UDP-Handshake zu den angepinnten Endpunkt-IP(s), DHCP und ICMP
  3. Dev-Server-Wächter → block drop in quick proto tcp ... port { … }
  4. Keine → /etc/pf.conf neu laden und pf in seinen ursprünglichen Zustand zurückversetzen
• Nach der Anwendung zurücklesen. pfctl -sr liest die Regeln zurück, um zu bestätigen, dass block drop all oder die Regel jedes Ports tatsächlich geladen ist. Ein Fall, in dem pfctl -f stillschweigend ignoriert wurde, wird nicht als Erfolg gewertet.
• Die temporäre Datei wird in einen Pfad geschrieben, der einen UUID enthält, und nach der Anwendung gelöscht. (v1.4.5 hat den festen Pfad zugunsten eines schwer zu erratenden Pfads gelöscht). Das Statusverzeichnis ist /Library/Application Support/RoamSwitch.

§5

Die Arten von Blöcken sind jeweils unterschiedlich

Wie das Air-Gap weder hängen bleibt noch ausgesessen werden kann

• Wie es endet, hängt vom Auslöser ab (ab 1.9.52). Ein manipulierter Ransomware-Köder, eine bestätigte XProtect-Erkennung und eine manuelle Isolation aus einer ARP-Warnung gelten als „hohe Sicherheit“; ClickFix, Portanomalien und Ähnliches als „niedrige Sicherheit“. Eine Isolation mit niedriger Sicherheit wird wie bisher spätestens nach 10 Minuten selbst aufgehoben. Eine mit hoher Sicherheit wird nach 10 Minuten nicht aufgehoben: Eine rein zeitgesteuerte volle Aufhebung ließe sich von einem Angreifer einfach aussitzen.
• Eine Isolation mit hoher Sicherheit bleibt bis zu einer Obergrenze (standardmäßig 1 Stunde, in den Einstellungen 5 Minuten bis 24 Stunden) vollständig geschlossen und prüft dann die Ursache. Bei Ransomware gilt die Ursache nur dann als beseitigt, wenn der verdächtige Prozess identifiziert wurde und beendet ist und sich die Köder seit der Erkennung nicht mehr verändert haben. Lässt sich das nicht bestätigen, geht sie in den „eingeschränkten Modus“ über: Neue Verbindungen bleiben gesperrt (außer Loopback und DHCP), nur das WLAN-Funkmodul wird wieder eingeschaltet, damit Sie die Lage prüfen können. Er öffnet sich nie allein durch Zeitablauf. Er öffnet sich nur, wenn Sie ihn aufheben oder die Ursache als beseitigt bestätigt ist.
• Beim Start einer Isolation werden auch bereits offene ausgehende Verbindungen getrennt. Die Zustandstabelle von pf wird geleert (pfctl -F states); damit stoppt Verkehr, der schon vor der Isolation lief. Beim Wechsel in den eingeschränkten Modus geschieht dasselbe.
• Eine durch ARP-Spoofing ausgelöste Isolation wird nur dann automatisch aufgehoben, wenn ohne jeden Datenverkehr bestätigt werden kann, dass die Ursache weg ist. Die Prüfung liest nur den ARP-Cache (sie sendet keine Pakete) und stellt die Beseitigung fest, wenn die vertrauenswürdige Gateway-MAC bei 3 aufeinanderfolgenden Prüfungen über mindestens 60 Sekunden zu sehen ist. Während der Isolation kann der ARP-Eintrag des Gateways jedoch aus der Nachbartabelle verschwinden (auf einem echten Mac bestätigt); dann lässt sich die Ursache nicht bestätigen. In diesem Fall bleibt die Isolation im eingeschränkten Modus, bis Sie sie aufheben.
• Auch wenn der Helper abstürzt, hört die Prüfung zur Aufhebung nicht auf. Ein eigener LaunchDaemon ganz ohne KeepAlive (AirGapFailsafe) startet alle 3 Minuten für sich und trifft dieselbe Entscheidung wie der Helper (niedrige Sicherheit: Aufhebung nach 10 Minuten; hohe Sicherheit: Ursachenprüfung an der Obergrenze, dann eingeschränkter Modus). Stürzt der Helper selbst ab und verliert damit seinen eigenen Aufhebungs-Timer, bleibt dieses Sicherheitsnetz unberührt (ab 1.8.6; die Entscheidung nach Sicherheit ab 1.9.52).
• Dieser dedizierte Daemon rührt niemals die eigene Startkonfiguration des interaktiven Helfers an. Ein früherer Ansatz (1.8.5) nutzte für diese Wiederherstellung das eigene KeepAlive.PathState des Helfers, das jedoch gelegentlich mit einem normalen Beenden der App kollidierte und einen unbeabsichtigten Neustart auslöste, weshalb er zugunsten des jetzigen, vollständig unabhängigen Daemons zurückgenommen wurde.
• Die Zeitstempelprüfung verwendet eine Hybridlösung aus monotoner Systemlaufzeit (ProcessInfo.systemUptime) und der Uhrzeit. Bevorzugt wird normalerweise die monotone Systemlaufzeit, sodass NTP-Korrekturen und manuelle Uhrzeitänderungen keine Auswirkung haben. Nur wenn die Systemlaufzeit nicht vertrauenswürdig ist – unmittelbar nach einem Neustart, erkannt daran, dass der aktuelle Wert kleiner ist als der gespeicherte – wird auf die Uhrzeit zurückgegriffen.
• Nach einem Neustart oder dem Neuerstellen des Daemons wird es erneut angewendet. Beim Start liest der Helper den Zustand von der Festplatte mit reapplyFromDisk() und stellt Air-Gap, Port-Wächter und Systemstandard in dieser Reihenfolge selbst wieder her. Auch der Zustand der Isolation (Sicherheit, voll oder eingeschränkt) und die verstrichene Zeit werden übernommen; die Zeitmessung läuft ab dem ersten Auslösen weiter (auf einem echten Mac durch Neustart des Helpers bestätigt).
• ___ Auf dem Bildschirm wird nie fälschlicherweise „angehoben“ angezeigt.
• Sie können jederzeit die Kontrolle zurückholen: mit „Air-Gap-Isolation aufheben“ in der Menüleiste, mit der Aufhebe-Schaltfläche im Modal oder einfach durch Ausschalten des WLANs. Das Aufheben erfordert kein Pro (es funktioniert auch, wenn Pro mitten in einer Isolation abläuft).

Wie ein Port-Guard-Falsch-Positiv-Ergebnis wiederhergestellt wird

Die automatische Blockierung unbekannter Ports (Pro, standardmäßig aktiviert, sobald Pro aktiviert ist) kann einen legitimen Port stoppen LAN-Empfänger – LocalSend, Syncthing, alles, was nach der Aktivierung des Wächters gestartet wurde. Wenn das passiert, erlauben Sie es über die Schaltfläche „Zulassen“ im Benachrichtigungsbanner oder in der entsprechenden Zeile den Bildschirm „Freigelegte Anschlüsse“. Eine einmal zulässige ausführbare Datei wird als bekannt aufgezeichnet und nicht blockiert wieder (PortAnomalyGuard.allowPort(_:)). Beachten Sie, dass generische Skriptinterpreter (Python, Node.js, Netcat usw.) haben einen strengen Gültigkeitsbereich von path:port und nicht von Binärdateien allein, um Angriffe von Landbewohnern zu verhindern. Apple-System-Daemons, die zufriedenstellend sind anchor apple (rapportd, das Handoff unterstützt und dergleichen) sind es nicht als erstes gesehen.

Selbstheilender Ransomware-Kanarienköder und Eindämmungsunterdrückung

Wenn Canary-Decoy-Dateien manipuliert oder umbenannt werden und den Notfall-Luftspalt auslösen, erfolgt die Freigabe Nach der Sicherheitsüberprüfung werden fehlende oder beschädigte Canary-Dateien automatisch neu generiert kehren zu ihrem authentischen Basis-Hash zurück, der aus eingebetteten Vorlagen generiert wurde, wodurch die ununterbrochene Überwachung der K-Warteschlange sofort wiederhergestellt wird (wodurch eine Kontamination der Basislinie durch den Gegner verhindert wird). Darüber hinaus werden während der aktiven Eindämmung (während das Notfallmodal angezeigt wird) redundante Benachrichtigungen und erneut auslösende Ereignisse aus regelmäßigen Hintergrund-Integritätsabfragen automatisch unterdrückt, um eine Ablenkung des Benutzers während der Reaktion auf den Vorfall zu vermeiden.

Allgemeine entropiebasierte Ransomware-Erkennung — 1.10.0, Pro, standardmäßig aktiviert

Überwacht die Ordner Dokumente, Schreibtisch, Downloads und Fotos per FSEvents und schlägt an, wenn Schreibvorgänge mit einer Shannon-Entropie über dem Schwellenwert (7,92) in einem Burst von 20 oder mehr Dateien innerhalb von 5 Sekunden auftreten. Anders als der Canary-Ansatz (Köderdatei) hängt dies nicht von der Manipulation einer Köderdatei ab, sodass auch Verschlüsselung an Orten ohne Canary-Datei erkannt wird. Erst wenn der Schwellenwert erreicht ist, wird per lsof der aktuelle Prozess ermittelt und mit einer Zulassungsliste abgeglichen (cp, mv, ditto, tar, ffmpeg, Xcode, Time Machine, gängige Browser usw.). Bei Erkennung löst es über denselben RansomwareContainmentManager wie der Canary-Guard die automatische Netzwerksperre aus.

Die Linux-Version kann Bursts pro Prozess verfolgen, da fanotify jedem Schreibereignis eine PID zuordnet. macOS hat weder fanotify noch (bewusst) EndpointSecurity, daher liest diese Implementierung über FSEvents nur den Pfad und zählt den Burst global, unabhängig vom Prozess. Einschränkung: Wenn mehrere legitime Prozesse gleichzeitig große Mengen hochentropischer Dateien schreiben (etwa bei sich überschneidenden Komprimierungs- oder Verschlüsselungsvorgängen), ist hier eher mit Fehlalarmen zu rechnen als in der Linux-Version.

Snapshots vor dem Schaden für die Ransomware-Wiederherstellung (Mac)

Ein Snapshot zum Zeitpunkt der Erkennung enthält bereits alle Dateien, die davor verschlüsselt wurden, und ist daher kein Rückweg. RoamSwitch legt deshalb unabhängig von einer Erkennung regelmäßig APFS-Snapshots an (standardmäßig alle 6 Stunden; aus, 1, 3, 6, 12 oder 24 Stunden). Bei einer Erkennung pausieren neue Snapshots vor dem Schaden und das Aufräumen für bis zu 7 Tage (Aufbewahrungsmodus), damit der verschlüsselte Zustand die letzte Generation vor der Verschlüsselung nicht verdrängt. Die Wiederherstellung erfolgt immer manuell: Nur die gewählten Dateien werden nach ~/RoamSwitch-Recovered/ kopiert. Aktuelle Dateien werden nie überschrieben, eine Wiederherstellung des ganzen Volumes gibt es nicht. Zum Kopieren muss der Snapshot eingehängt werden, deshalb braucht der privilegierte Helper den Vollzugriff auf die Festplatte (Snapshots entstehen auch ohne ihn). macOS kann lokale Snapshots selbst löschen, etwa bei knappem Speicherplatz, daher ist ein Bestand über etwa 24 Stunden hinaus nicht garantiert. Das Wiederherstellungsfenster ist eine Pro-Funktion (das Anlegen der Snapshots funktioniert auch ohne Pro).

Forensisches Beweispaket — 1.10.0

Beginnt ein Notfall-Air-Gap — ausgelöst durch den Canary-Guard, den entropiebasierten Ransomware-Guard oder Ähnliches — sichert eine Hintergrundwarteschlange, die die Eindämmung selbst nicht blockiert, einen Schnappschuss der Prozessliste (ps), der Netzwerkverbindungen (lsof -i), der in den letzten fünf Minuten geänderten Dateien sowie der vom verdächtigen Prozess geöffneten Dateien unter ~/Library/Application Support/RoamSwitch/incident-evidence/<Zeitstempel>/manifest.json. Das Manifest erfasst den SHA-256 jedes Artefakts, damit spätere Manipulation erkennbar ist. Die Liste der Pakete ist über das MCP-Tool get_forensic_evidence_bundles abrufbar. Einschränkung: Da hierfür kein EndpointSecurity-Entitlement genutzt wird, werden weder Paketmitschnitte noch Speicher-/Dateideskriptor-Schnappschüsse des Prozesses erfasst.

Aufzeichnung von Prozessausführungen (Mac, Pro, standardmäßig aus)

Der privilegierte Helper startet das in macOS enthaltene /usr/bin/eslogger (exec, fork, exit) als Kindprozess und zeichnet Prozessstarts nur auf diesem Mac auf. Er beantragt die EndpointSecurity-Berechtigung nicht (es_new_client wird nie aufgerufen); RoamSwitch muss unter „Vollzugriff auf die Festplatte“ erlaubt sein (Systemeinstellungen; falls nicht aufgeführt, /Applications/RoamSwitch.app über „+“ hinzufügen). Solange die Erlaubnis fehlt, zeigt er den Status „nicht verfügbar“ an, wartet und prüft alle 60 Sekunden erneut (er wechselt nicht zu aufwendigem Polling). Er benachrichtigt nur. Er blockiert weder Ausführung noch Kommunikation und isoliert nicht.

Benachrichtigt bei diesen zehn Verhaltensweisen: ein Browser, Office- oder Mail-App startet direkt eine Shell; ein unsigniertes Binary wird aus einem temporären Ordner oder einem unter Quarantäne stehenden Ort ausgeführt; ein Einzeiler lädt herunter und leitet in eine Shell (in Kombination mit einer Roh-IP-URL, base64, eval oder deaktivierter TLS-Prüfung); osascript verwendet base64 oder eval; eine Datei wird unmittelbar nach Entfernen ihres Quarantäne-Attributs ausgeführt; ein unsigniertes Binary wird aus einem gerade geschriebenen Autostart-Eintrag (LaunchAgent oder LaunchDaemon) gestartet; ein nicht von Apple signierter Elternprozess liest ein Schlüsselbund-Geheimnis aus (etwa security find-generic-password -w); ein python3-, perl-, ruby-, php- oder pwsh-Einzeiler mit -c/-e/-Command, bei dem eine base64-/eval-Dekodierung und ein Aufruf von curl, wget, exec oder system in derselben Zeile stehen (ab 1.10.0 — base64 oder eval allein lösen dies nicht aus); und der Start eines Prozesses mit gesetzter Umgebungsvariable DYLD_INSERT_LIBRARIES (ab 1.10.0 — um keine Geheimnisse preiszugeben, wird ausschließlich der Wert dieser einen Variable gelesen; Apple-signierte Prozesse sind ausgenommen); und eine Befehlszeile, die direkt eine von RoamSwitch ausgelegte Köder-Zugangsdatendatei nennt (etwa ~/.aws/credentials oder ~/.env.backup, erkannt an der Markierung im Inhalt), zum Beispiel cat, tar oder curl -F; echte Dateien treffen nie zu, Lesezugriffe über eine Bibliothek überlässt die Regel der Honeytoken-Überwachung. Jede Erkennung trägt eine MITRE-ATT&CK-Technik-ID.

Nur Erkennungen mit hoher Schwere werden zu Bannern, gleichartige werden auf einmal pro 10 Minuten zusammengefasst (im Protokoll bleibt jedes Ereignis). Entwicklerwerkzeuge wie Claude Code und die GitHub CLI, die ihre eigenen Zugangsdaten lesen, werden standardmäßig nicht gemeldet. Liest ein anderes Programm sie, erlaubt die Aktion „Dieses Programm erlauben“ in der Benachrichtigung genau diesen Eintrag (bei Signatur nach Team ID, sonst nach Programmname, jeweils zusammen mit dem Eintragsnamen).

Das Protokoll wird nur für root lesbar gespeichert (Ordner 0700, Dateien 0600) und hält standardmäßig 200 MB und 14 Tage vor. Umgebungsvariablen werden nicht gespeichert, Kommandozeilenargumente können aber Geheimnisse enthalten. Jedes Segment wird in einer Hash-Kette versiegelt, die an den Hash des vorherigen Segments anknüpft; „Kette prüfen“ erkennt Änderungen, fehlende Segmente und entfernte Siegel (jeweils auf einem echten Mac bestätigt). Das erkennt Manipulation, es verhindert sie nicht. Das Löschen oder Zurücksetzen des neuesten Segments lässt sich nicht erkennen. Gelesen wird über das XPC des Helpers, MCP läuft über die App (mit erneuter Pro-Prüfung).

Grenzen: Ausführungen vor dem Start des Helpers oder vor dem Aktivieren der Aufzeichnung werden nicht erfasst. eslogger beobachtet im Nachhinein und kann nicht blockieren. Unter Last, etwa bei Tausenden Prozessstarts pro Sekunde, gehen Ereignisse verloren (die Anzahl wird angezeigt, der Betrieb läuft weiter). Diese Aufzeichnung ersetzt kein EDR (Endpoint Detection and Response).

Anmeldedaten-Honeytoken — 1.10.0, Pro, standardmäßig aktiviert

Platziert an drei Orten eine mit einem Erkennungsmerkmal versehene Köder-Anmeldedatei: ~/.aws/credentials, ~/.ssh/id_rsa_backup und ~/.docker/config.json. Eine dort bereits vorhandene echte Datei wird niemals überschrieben. Die Zugriffserkennung kombiniert denselben kqueue-Mechanismus (DispatchSource.makeFileSystemObjectSource) wie der Canary-Guard mit einem 30-Sekunden-Polling der Zugriffszeit, da ein open()-Ereignis ohne EndpointSecurity nicht zuverlässig abgefangen werden kann. Die Erkennung benachrichtigt nur; sie blockiert nichts und löst keine Isolation aus. Der ssh-Köder verwendet einen Namen, den ssh standardmäßig nicht sucht (nicht id_rsa), sodass ein normaler ssh-Aufruf weder gestört noch fälschlich gemeldet wird. Der AWS-Köder nutzt einen eigenen Profilnamen statt [default], der Docker-Köder zeigt auf eine nicht existierende interne Registry, und alle werden mit Modus 0600 angelegt (ab 1.10.3). Zusätzlich zu diesen dreien werden ~/.pypirc und ~/.env.backup ausgelegt (für Suchen nach PyPI-Token, .env-Dateien und KI-API-Schlüsseln). ~/.npmrc wird nicht verwendet, weil npm sie bei jedem Lauf liest, und GCP-Zugangsdaten nicht, weil eine gefälschte Datei die echte Authentifizierung stören würde. Wird ein Köder tatsächlich abgerufen, wird genau ein verwandter Köder (~/.aws/config, ~/.ssh/config oder ~/.kube/config) zusätzlich ausgelegt und ebenfalls überwacht; die Kette endet nach einem Schritt, und keine vorhandene Datei wird überschrieben.

Überwachung des Browser-Anmeldedatenzugriffs — 1.10.0, auch innerhalb von Pro Opt-in, standardmäßig deaktiviert

Überwacht per FSEvents Schreibvorgänge auf die gespeicherten Passwort-/Cookie-Datenbanken von Chrome, Brave, Edge, Vivaldi, Chromium und Firefox. Bei einem Burst identifiziert lsof den Prozess; alles außer dem Browser selbst, einem Indexer wie Spotlight oder einem Backup-Daemon zählt als Treffer. Anders als die übrigen neuen Guards wird dies durch Aktivieren von Pro nicht automatisch eingeschaltet — eine Browser-Erweiterung oder die Importfunktion eines Passwort-Managers kann es auslösen, sodass das Fehlalarmrisiko inhärent hoch genug ist, dass es standardmäßig als Opt-in ausgeliefert wird.

Kommunikation mit dem Sensor (TLS und Signaturen)

Kopplung, Audit-Anfragen und Abruf der Ergebnisse mit einem RoamSwitch Sensor (ein separates Produkt) im selben LAN laufen über TLS 1.3 mit festgesetztem Zertifikat-Fingerabdruck (SHA-256) (Sensor 0.3.9 und neuer). Der Fingerabdruck wird nicht über das Netzwerk geholt; der Nutzer tippt den auf dem Sensor-Bildschirm angezeigten Wert ein. Zertifizierungsstelle, Hostname und Ablaufdatum werden nicht geprüft, vertraut wird nur dem festgesetzten Wert. Schlägt TLS fehl, wird nicht auf Klartext ausgewichen (sonst könnte ein Man-in-the-Middle die Verbindung herabstufen). Anfragesignaturen enthalten Zeitstempel und Nonce (v2), um Wiedereinspielung zu verhindern. Nur eine alte Kopplung ohne Fingerabdruck verbindet sich weiterhin im Klartext, mit einer Warnung.

Ändert sich das Zertifikat, wird die Verbindung abgelehnt. Das Festsetzen wird nie automatisch aktualisiert: Es wird nur gespeichert, wenn der Nutzer den neuen Wert eingibt und bestätigt und eine signierte Sondierung tatsächlich per TLS gelingt. Grenze: Diese Sondierung prüft nicht per Schlüssel, ob es derselbe Sensor ist, der zuvor gekoppelt wurde. Sie setzt voraus, dass der Nutzer den auf dem Sensor-Bildschirm bestätigten Wert eingibt.

Mehrschichtige Erkennung heruntergeladener Dateien (statische Signaturen + ClamAV) – statische Signaturschicht ab 1.8.7

Neu im Downloads-, Schreibtisch- oder Dokumente-Ordner abgelegte Dateien durchlaufen zunächst eine leichtgewichtige statische Signaturprüfung durch StaticSignatureScanner (nur die ersten 4 MB, einfacher AND/OR-Bytemuster-Abgleich – keine regulären Ausdrücke oder Entropieberechnungen). Sie benötigt kein EndpointSecurity-Entitlement und funktioniert auch dort weiter, wo ClamAV nicht installiert ist. Die Erkennung ist bewusst auf das beschränkt, was ohne einen echten Malware-Korpus als Tatsache belegt werden kann: die branchenübliche EICAR-Testsignatur sowie fünf in öffentlichen Offensive-Security-Referenzen (z. B. PayloadsAllTheThings) dokumentierte Lehrbuch-Reverse-Shell-Einzeiler – /dev/tcp/ von bash/sh, -e von netcat, pty.spawn von Python, Socket von Perl und fsockopen von PHP. Wir schreiben keine bytegenauen „Signaturen“ für namentlich bekannte Malware-Familien, ohne eine echte Probe zu besitzen, aus der sie extrahiert werden könnten – das wäre nur ein trügerisches Sicherheitsgefühl. Die Muster selbst werden XOR-0x5A-verschleiert gespeichert, damit RoamSwitchs eigene Binärdatei niemals eine wörtliche EICAR-Zeichenfolge oder einen Reverse-Shell-Einzeiler enthält, wegen der ClamAV selbst sie melden könnte.

Nur Dateien, die die statische Signaturschicht als „sauber“ einstuft, gehen weiter in den ClamAV-Scan. Neu im Downloads-, Schreibtisch- oder Dokumente-Ordner abgelegte Dateien werden unabhängig von einer .tmp-Erweiterung oder einem com.apple.quarantine-Attribut (etwa bei einer über das Terminal erstellten Kopie) sofort von ClamAV gescannt. EICAR und andere branchenübliche Testsignaturen gelten als harmlos: Es wird keine Benachrichtigung angezeigt, sondern nur ein Eintrag im Benachrichtigungsverlauf angelegt – und sie werden nie unter Quarantäne gestellt oder blockiert (nur echte Malware-Proben werden unter Quarantäne gestellt). Und war bereits zuvor eine Datei gleichen Namens unter Quarantäne gestellt worden, wird die neue trotzdem unter einem eindeutigen, zeitgestempelten Namen in den Quarantäne-Ordner verschoben, sodass eine Bedrohung wegen einer Namenskollision nie an ihrem ursprünglichen Ort verbleiben kann.

Web-Shell-Erkennung in Entwicklungs-Webordnern (Web Rules)

Dateien der lokalen Webentwicklung (~/Sites, MAMP, Herd, Local, /Library/WebServer/Documents und die für den Paket-CVE-Abgleich registrierten Projektordner) werden mit denselben 18 Erkennungsregeln wie in der Linux-Edition geprüft: PHP, JavaScript, JSP und ASP. Die Regeln beschreiben nur öffentlich dokumentierte Techniken und enthalten keine aus einer echten Probe gewonnene Signatur. Es gibt drei Schichten: in die App eingebaut, ein signiertes, nur empfangendes Update einmal täglich (im bestehenden einen Abruf enthalten) und eigene Regeln in ~/Library/Application Support/RoamSwitch/rules.d (gelesen werden nur Dateien, die root oder Ihnen gehören und die Gruppe und andere nicht beschreiben können). Bereits überwachte Ordner wie Downloads werden direkt nach dem Schreiben geprüft; Webentwicklungsordner einmal täglich und auf Abruf (die tägliche Prüfung betritt node_modules und .git nicht; eine Prüfung eines gewählten Ordners betritt node_modules). Da EndpointSecurity nicht verwendet wird, kann nichts vor der Ausführung gestoppt werden: Jede Erkennung erfolgt nachträglich.

Standardmäßig wird nur critical automatisch isoliert. Ein high-Treffer lässt die Datei unangetastet und erscheint als Benachrichtigung und in einer Liste in den Einstellungen, wo Sie „nicht mehr erkennen“ wählen können (die Quarantäne-Stufe lässt sich in den Einstellungen ändern). Der Hook nach der Erkennung (~/Library/Application Support/RoamSwitch/hooks/post-detection) läuft nur, wenn er root oder Ihnen gehört und niemand sonst ihn beschreiben kann, und wird nach 30 Sekunden gestoppt. Die Kontomaßnahme (standardmäßig aus; zum Einschalten ist das Administratorpasswort nötig) sperrt die Login-Shell des Besitzers einer isolierten Datei, berührt aber weder root noch UIDs unter 501 noch angemeldete Benutzer (auch nicht Sie selbst, während Sie diesen Mac benutzen). Als root unter der eigenen Sandbox des Helfers in einer macOS-26-VM wurden die echte Shell-Änderung per dscl und ihre Wiederherstellung überprüft (die Sandbox blockiert direkte Schreibzugriffe auf dslocal, nicht aber Änderungen über dscl). Die Bestätigung per Administratorpasswort und der Aufrufweg von der App zum Helfer wurden auf einem echten Gerät noch nicht überprüft. In 114.501 Dateien eines Entwicklungsordners gab es 0 Treffer.

Überwachung neuer Autostart-Persistenz (LaunchAgent/LaunchDaemon) – 1.8.7

Neue .plist-Dateien unter ~/Library/LaunchAgents, /Library/LaunchAgents oder /Library/LaunchDaemons werden per FSEvents in Echtzeit erkannt (PersistenceMonitorGuard). Ohne ES_EVENT_TYPE_AUTH_CREATE von EndpointSecurity lässt sich der Schreibvorgang selbst nicht blockieren. Möglich ist jedoch, ihn innerhalb von Sekunden zu bemerken und den Inhalt zu bewerten.

Die Bewertung stützt sich darauf, was direkt gestartet wird, nicht auf die Signatur der ausführbaren Datei selbst. Reale Techniken aus dem Jahr 2026 – ein als Google Update getarnter LaunchAgent, der ein Base64-dekodiertes Bash-Skript verbirgt, oder ein LaunchDaemon mit Root-Rechten, der bei jedem Neustart eine Base64-dekodierte AppleScript-Payload erneut ausführt – verstecken den bösartigen Code beide Male im Skript selbst, während sie ein gültig signiertes /bin/bash oder /usr/bin/osascript unverändert aufrufen. Eine Prüfung, die nur die Signatur der ausführbaren Datei betrachtet, würde beides ungehindert durchlassen. Deshalb wird jeder neu registrierte LaunchAgent/LaunchDaemon, der einen rohen Skriptinterpreter (bash, sh, zsh, osascript, python3, perl, ruby, php und Ähnliches) direkt aufruft, unabhängig von dessen gültiger eigener Signatur, ausnahmslos gemeldet. Die dabei übergebenen Argumente werden zudem durch StaticSignatureScanner geprüft, und jedes gefundene bekannte bösartige Muster wird in die Benachrichtigung aufgenommen. Einträge, die über BundleProgram (verweist auf eine signierte, kompilierte Binärdatei innerhalb eines App-Bundles – einschließlich RoamSwitchs eigenem Helfer) registriert wurden, werden ganz normal per codesign --verify --strict verifiziert.

ClickFix-Erkennung und Notfall-Abriegelung – 1.8.7, standardmäßig deaktiviert

„ClickFix“ ist eine Social-Engineering-Technik, bei der ein gefälschtes CAPTCHA oder eine Fehlermeldung dazu auffordert, das Terminal zu öffnen und einen Befehl „zur Verifizierung“ einzufügen. Die Erkennungen stiegen von 2024 bis 2025 um über 500 %, und bis 2026 gilt sie als einer der am weitesten verbreiteten macOS-Angriffsvektoren. Da es sich um die eigene, legitime Shell handelt, die genau das ausführt, was eingegeben wurde, umgeht sie Gatekeepers Signaturprüfung vollständig.

Menüleiste → Malware-Schutz → ClickFix-Abwehr (Pro, standardmäßig deaktiviert). Überwacht per FSEvents neu angehängte Zeilen in ~/.zsh_history/~/.bash_history (nur Zeilen, die nach dem Start der Wache hinzugefügt werden – der bestehende Verlauf wird nie durchsucht) und gleicht ausschließlich die Reverse-Shell-Einzeiler ab, die sie mit StaticSignatureScanner teilt, sowie die spezifische Kombination aus Base64-Dekodierung direkt in eine Shell oder in osascript. Ein bloßes curl | bash – bei legitimen Installationsprogrammen äußerst verbreitet – ist bewusst ausgeschlossen, da es sich nicht von den offiziellen Installationsanleitungen für Homebrew, rustup, nvm und Ähnliches unterscheiden lässt. Sobald eine Übereinstimmung gefunden wird, löst sie denselben oben beschriebenen Notfall-Air-Gap aus. Da der Befehl bereits ausgeführt wurde, geschieht dies zwangsläufig im Nachhinein, kann aber dennoch einen laufenden zweiten Download oder eine Zugangsdaten-Exfiltration unterbrechen. Wie jeder andere Air-Gap-Auslöser hebt sie sich von selbst nach spätestens 10 Minuten auf (siehe Beginn dieses Abschnitts).

Eine bekannte Einschränkung. Da die Erkennung von einem Schreibvorgang in den Shell-Verlauf abhängt, kann sie die dateilose Variante nicht erfassen, die das Terminal vollständig umgeht, indem sie den Skripteditor direkt über das applescript://-URL-Schema aufruft und nichts auf die Festplatte schreibt. Apple hat hierfür eine gewisse Abschwächung eingeführt (ein Bestätigungsdialog für nicht identifizierte Skripte), doch es wurden Varianten gemeldet, die diese umgehen. Wir haben diesen Pfad auf echter Hardware gegen das einheitliche macOS-Protokoll (log show/log stream) getestet und kein charakteristisches Protokollsignal gefunden, an dem eine Erkennung ansetzen könnte. Wir stellen diese Einschränkung lieber offen dar, als eine Abdeckung zu behaupten, die wir nicht haben.

Docker-Risikoerkennung — 1.8.9, Pro, standardmäßig deaktiviert

Menüleiste → „Malware-Schutz“ → „Privilegierte Docker-Container & docker.sock-Mounts erkennen“ (DockerEventGuard). Da es in dieser Codebasis keinen Präzedenzfall für eine dauerhafte Streaming-Verbindung wie docker events gibt, wird derselbe Timer-Polling-Ansatz wie bei PortAnomalyGuard verwendet. Alle 20 Sekunden wird mit einem leichten docker ps -q die Menge der Container-IDs abgerufen, und nur die Differenz zum vorherigen Stand (neu gestartete Container) wird mit docker inspect --format im Detail geprüft. Der zur Erkennung verwendete Format-String ist absichtlich identisch mit dem der Linux-Edition (roamswitch_core::health::LinuxHealthChecker::DOCKER_INSPECT_RISK_FORMAT), sodass beide Plattformen exakt dieselben Bedingungen erkennen (Start im --privileged-Modus oder ein /var/run/docker.sock-Bind-Mount).

Bei der Erkennung wird keine automatische Aktion ausgelöst. Ein privilegierter Container oder ein docker.sock-Mount ist eine riskante „Konfiguration“, die einen Container-Escape ermöglichen könnte, aber keine bestätigte Kompromittierung – es gibt auch legitime Anwendungsfälle, etwa den bewussten Betrieb eines Überwachungs-Agents als privilegiert. Da die meisten Nutzer überhaupt kein Docker verwenden, bleibt diese Funktion auch mit Pro-Lizenz standardmäßig deaktiviert. Sie verwendet nicht das EndpointSecurity-Entitlement; die docker-CLI wird zunächst am Standard-Installationspfad von Docker Desktop, dann über Homebrew und schließlich über which gesucht. Verifiziert an einer echten Docker-Desktop-Installation (29.7.2) anhand von drei Szenarien – ein privilegierter Container, ein Container mit docker.sock-Mount und ein normaler Container – ohne Fehlalarme oder verpasste Erkennungen.

Geheimnis-/API-Schlüssel-Leck-Audit — hinzugefügt in 1.8.4, Ordner-Scan hinzugefügt in 1.8.9

Menüleiste → „Malware-Schutz“ → „Geheimnis-/API-Schlüssel-Leck-Audit“. Text einfügen, und er wird sofort auf durchgesickerte API-Schlüssel und Tokens geprüft, mit Zeilennummer, maskiertem String und einer Handlungsempfehlung je Fund (SecretLeakAuditor, vollständig auf dem Gerät). In 1.8.9 kam die Option „Ordner zum Scannen auswählen“ hinzu, mit der dieselbe Erkennungs-Engine ein Verzeichnis – etwa einen Quellcode-Checkout – rekursiv über auditDirectory(at:) prüfen kann. .git, node_modules, target, vendor, dist, build, __pycache__ und venv werden automatisch ausgeschlossen, ebenso Dateien über 2 MB oder als Binärdatei erkannte Dateien. Die Verarbeitung läuft außerhalb des Hauptthreads, um die Oberfläche nicht zu blockieren, und es wird niemals etwas nach außen gesendet.

Link Guard (blockiert Phishing-Verbindungen) – 1.7.2 und höher, verstärkt in 1.8.0

Menüleiste → „Malware-Schutz“ → „Link Guard“ (Pro). Blockiert Verbindungen zu Phishing-/Betrugsseiten auf dem Gerät, in jedem Browser und in jeder App. Es gibt zwei Durchsetzungspunkte, die zusammen in der Reihenfolge ihrer Priorität verwendet werden.

• ① Content-Filter-Systemerweiterung (RoamSwitchLinkFilter, 1.8.0+, nach Genehmigung bevorzugt). Eine NEFilterDataProvider-Systemerweiterung – keine Apple-Überprüfung (Content-Filter-Anbieter sind Selbstbedienungsanbieter, keine Genehmigungswarteschlange). Es überprüft den tatsächlichen ausgehenden TCP-Fluss after Namensauflösung. Der Zielname stammt aus dem vom Betriebssystem aufgelösten Hostnamen oder, falls dies nicht der Fall ist, wurde der TLS SNI aus den ersten Bytes des Flusses geparst – ein Browser, der sein eigenes DoH/DoT ausführt und eine Verbindung zu einer nackten IP herstellt, wird also immer noch blockiert. Es schreibt /etc/hosts nie neu und ordnet jeden Fluss einem Prozess zu. QUIC (UDP/443) hat kein lesbares SNI, daher wird es im block-Modus gelöscht, wodurch der Browser gezwungen wird, auf HTTP/2 über TCP zurückzugreifen. Erfordert eine einmalige Genehmigung in den Systemeinstellungen.
• ② /etc/hosts Sinkhole (Fallback, während die Erweiterung nicht genehmigt/abgelehnt ist). Der privilegierte Helfer schreibt die Zieldomänen in einen durch Trennzeichen getrennten verwalteten Abschnitt von /etc/hosts als 0.0.0.0 und leert den Cache. Maximal 60.000. Sobald die Erweiterung aktiv ist, wird dieser Abschnitt entfernt.
• Drei Modi. „Aus“ deaktiviert es. „Nur warnen“ pausiert die passende Verbindung und fragt den Benutzer (siehe Real warn unten). „Offensichtliche Betrugsseiten automatisch blockieren (empfohlen)“ wird sofort entfernt. Der Standardwert ist Block ab 1.7.2.
• ___ Sobald das Tippen des Benutzers allowlist.txt / extra.txt erreicht – die Erweiterung fragt alle 1,5 s die kleinen Statusdateien ab – werden die angehaltenen Flows fortgesetzt (zulassen) oder gelöscht (blockieren). Keine Antwort innerhalb von 25 s schlägt open fehl (eine Warnung ist beratend). Die Entscheidung wird pro Host zwischengespeichert (5 Minuten zulassen/1 Stunde blockieren), sodass die anderen Flüsse der Seite und spätere Besuche sofort erfolgen und erzwungen werden. Die block-Benachrichtigung ist unverändert: „Blockiert …“ mit der Schaltfläche „Einmal zulassen (5 Min.)“.
• Nur eindeutige Fälle werden blockiert. Eine Auflistung im Bedrohungs-Feed oder ein Marken-Unicode-Homograph – alles andere (Hochrisiko-TLDs, Subdomain-Nachahmung usw.) ist eine Warnung. Die Urteils-Engine wird mit der Linux-Edition geteilt und sendet URLs nirgendwohin.
• Wiederherstellung nach einer falschen Blockierung. Eine Domain über die Benachrichtigung oder das Menü zulassen (5 Minuten oder dauerhaft). Die Zulassungsliste wird abgezogen, wenn der Abschnitt neu generiert wird.
• Pro-gated. Die Durchsetzung (applyMode()) erfolgt nur bei einer gültigen Pro-Lizenz. Ohne Pro wird der Modus gespeichert, aber /etc/hosts wird nie berührt. Die Aktivierung oder das Erlöschen einer Lizenz wird mitten in der Sitzung wirksam.
• Feed und gebündelter Seed. Die Blockliste stammt aus dem signierten Bedrohungs-Feed (§7, verifiziert mit einem Feed-spezifischen Schlüssel). Es funktioniert bereits vor dem ersten Abruf mit dem gebündelten Seed der App (ca. 60.000 Einträge) und die Deaktivierung von „Auto-Update“ bedeutet, dass kein ausgehender Datenverkehr stattfindet.

Präventive Gateway-ARP/NDP-Sperre – 1.7.5 und höher

Menüleiste → „Port- und Gerätemonitor“ → „ARP/NDP des Gateways an nicht vertrauenswürdige Netzwerke anheften (präventiv)“ (Pro, standardmäßig deaktiviert).

• Wie es funktioniert. Beim Beitritt zu einem nicht vertrauenswürdigen Netzwerk wird der aktuelle MAC des IPv4-Gateways, des IPv6-Standardrouters und der On-Link-DNS-Resolver von route / scutil --dns / arp -n / ndp -an erfasst, und der Helfer pinnt jeden als permanent-Eintrag mit arp -s / ndp -s (Vertrauen bei der ersten Verwendung – der erste beobachtete MAC ist vertrauenswürdig). Gefälschte ARP/NDP-Antworten für diese IPs werden dann ignoriert, sodass kein Man-in-the-Middle-Angriff durchgeführt werden kann.
• Scope. Nur diese drei Arten von Einträgen werden angeheftet. Vertrauenswürdige (offene) Netzwerke werden niemals gepinnt. Bei jedem Netzwerkwechsel wird es einmal entsperrt und erneut angepinnt. Öffentliche Off-Link-Resolver (8.8.8.8, …) haben keinen On-Link-ARP-Eintrag und werden automatisch ausgeschlossen.
• arp -s ist präventiv; der Luftspalt ist nachträglich. Dieser Pin existiert, daher kann eine Parodie nicht erfolgreich sein; Die ARP-Spoofing-Erkennung (ARPSpoofContainmentManager) und der Notfall-Luftspalt dienen dazu, „schneller als ein Mensch zu schneiden“, sobald einer erkannt wird. Sie laufen unabhängig.
• Persistence. Der Pin-Satz wird unter /Library/Application Support/RoamSwitch/gateway_arp_lock.json gespeichert, sodass er bei einer erneuten XPC-Verbindung oder einem Neustart des Hilfsprogramms entsperrt werden kann.

Der VPN-Tunnel (WireGuard / Tailscale) und sein Kill-Switch – 1.7.6 und höher, auswählbares Backend in 1.8.0

Menüleiste → „Port- und Gerätemonitor“ → „VPN-Tunnel“ (Pro, standardmäßig deaktiviert). Dies ist die primäre Anti-MITM-Abwehr – sie hängt nicht von der Integrität von L2 (ARP/NDP) ab. Das Backend ist wählbar (Untermenü → „Backend“) zwischen „WireGuard (config file)“ und „Tailscale (Exit Node)“. RoamSwitch implementiert selbst keine Kryptografie; Nur das ausgewählte Backend ist scharfgeschaltet.

• (A) WireGuard-Backend. Steuert Homebrews wireguard-tools (keine Berechtigung zur Apple Network Extension). Importieren Sie Ihr eigenes .conf; Der Helfer speichert es bei 0600. Kill-Switch: pf block drop all plus ein pass quick nur für lo, die Tunnelschnittstelle, den UDP-Handshake zu den angehefteten Endpunkt-IP(s), DHCP und ICMP. Ein nicht vollständiger Tunnel AllowedIPs löst eine Split-Tunnel-Warnung aus.
• (B) Tailscale-Backend (1.8.0+). Für Benutzer, die Tailscale bereits ausführen. RoamSwitch führt nicht aus, führt tailscale up aus / meldet sich an / installiert es – es liest tailscale status --json und führt tailscale set --exit-node=<node> aus. Empfohlen wird der Standalone-Build (direkter Download von tailscale.com) mit aktivierter CLI-Integration (Einstellungen → „CLI integration“ → „Install Now“, fügt /usr/local/bin/tailscale hinzu) – der App Store (GUI)-Build kann nicht von außerhalb der App (Sandbox) gesteuert werden; Damit wählen Sie den Ausgangsknoten in der Tailscale-App aus und RoamSwitch zeigt nur den Status an. Ein Ausgangsknoten ist erforderlich (leitet den gesamten Datenverkehr durch den Tunnel); Es wird automatisch deaktiviert, wenn es offline geht oder nicht erreichbar ist.
• ⚠️ Der Homebrew-Build (brew install tailscale) wird nicht empfohlen. Das von Homebrew ausgelieferte tailscaled hat einen bekannten macOS-Fehler, durch den die Routing-Tabelle unter Umständen nicht korrekt neu geschrieben wird (tailscale/tailscale#21395, #21216) — ein Exit Node kann als „verbunden“ angezeigt werden, während der Datenverkehr weiterhin ungeschützt austritt, oder das Aufheben der Verbindung kann die gesamte Internetverbindung des Mac lahmlegen. RoamSwitch überprüft die tatsächliche Routing-Tabelle des Betriebssystems und warnt in diesem Fall, aber die Verwendung des oben genannten Standalone-Builds vermeidet das Problem von vornherein.
• ___ Der Datenverkehr sinkt für ca. 5–10 s und die Schutzstufe wird in diesem Fenster nicht herabgestuft.
• Der Tailscale-Kill-Switch ist standardmäßig deaktiviert (Opt-in). Der Exit-Knoten tunnelt bereits alles; der pf block drop all (erlaubt nur CGNAT/MagicDNS/STUN/DERP/DHCP/ICMP/DNS) ist für fortgeschrittene Benutzer und ist „lecksicher, nicht lecksicher“ (DNS ist erlaubt, daher bleibt tailscaled bestehen).
• Automatisch / bei Lizenzverlust. Kommt bei nicht vertrauenswürdigen Netzwerken hoch, bei vertrauenswürdigen herunter; wird aufgehoben, wenn die Pro-Lizenz erlischt.

§6

Wenn Sie eine Verbindung zu einem Netzwerk herstellen, das Sie nicht registriert haben, wird der Schalter „Schutzstufe“ nicht verwendet pf. Es ändert lediglich die Standardeinstellungen des Betriebssystems auf eine Weise, die später rückgängig gemacht werden kann.

Dabei handelt es sich nicht um einen neuen Blockierungsmechanismus, den RoamSwitch hinzufügt – es handelt sich lediglich um das Umschalten der Betriebssystemeinstellungen. Wenn löscht man die App, stoppt nur noch die netzwerkabhängige Umschaltung; das letzte Betriebssystem Die angewendeten Einstellungen bleiben unverändert. Nichts bleibt gesperrt, aber wenn Sie sich irren möchten Stellen Sie es auf der sicheren Seite in einem vertrauenswürdigen Netzwerk wieder auf „Offen“, bevor Sie es deinstallieren.

§7

Was bleibt auf dem Mac

Verkehr, der die Maschine verlässt (die vollständige Liste)

Es gibt nirgendwo Code, der Diagnoseergebnisse, Portinformationen, URLs oder Protokolle sammelt und sendet. Es sind weder ein Analyse-SDK noch ein Crash-Reporter-SDK eingebunden. Die einzige externe Bibliothek ist Sparkle (Updates). Ins Netzwerk gehen die folgenden acht Wege, dazu die unter der Tabelle beschriebenen, vom Benutzer ausgelösten Funktionen, standardmäßig deaktivierten Funktionen und der DNS-Bedrohungsschutz, und sonst nichts (der sechste nur, wenn der Benutzer ein VPN konfiguriert, der siebte nur, wenn die RoamSwitch Sensor-Kopplung aktiviert ist).

# Developer-ID-Signatur und Team-ID
codesign -dvvv /Applications/RoamSwitch.app 2>&1 | grep -E 'Authority|TeamIdentifier|flags'

# Ob das Notarization-Ticket gestapelt (staple) ist
stapler validate /Applications/RoamSwitch.app
spctl -a -t exec -vvv /Applications/RoamSwitch.app

# Signatur des mitgelieferten Helpers / MCP-Servers
codesign -dvvv /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchHelper
codesign -dvvv /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer

codesign -d --entitlements :- /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchHelper
codesign -d --entitlements :- /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer
# → Ein leeres Entitlements-Dictionary. Keine app-sandbox-/network-client-Schlüssel.

# tcpdump parallel mitlaufen lassen, um zu bestätigen, dass bei normaler Nutzung kein Traffic außerhalb der Wege in der Tabelle entsteht
sudo tcpdump -i any -n 'host not 127.0.0.1' and 'not port 53'
# Kein Traffic außer den Wegen der Tabelle (Lizenzaktivierung, Update-Prüfungen, signierte Update-Daten, ClamAV-Updates usw.)

Eine strengere, automatisierte Prüfung mit Zuordnung pro Prozess finden Sie unter rs-zerotel-audit.sh in roamswitch-support/audit/

# Verifiziert automatisch in einem Durchgang: XPC-Autorisierungsgrenze, pf-Air-Gap-Priorität, Port-Expositionserkennung, MCP-Nur-Lesen, ARP-Überwachung
git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Live-Penetrationstests und mehrschichtiges Verteidigungsaudit von einer macOS-VM: RESULTS-DEFENSE-2026-08-30

# Abfrage der offiziellen Quad9-Testdomain zur Verifikation der Bedrohungsblockierung
nslookup test.dns9.quad9.net
# → Sollte ** server can't find test.dns9.quad9.net: NXDOMAIN liefern, d. h. die Namensauflösung ist blockiert

# Die harmlose branchenübliche Antiviren-Teststring (EICAR) in Downloads erstellen
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/Downloads/eicar_test.com
# → Die FSEvents-Erkennung löst einen sofortigen ClamAV-Scan aus; es erscheint keine Benachrichtigung, "EICAR-Testsignatur erkannt (harmlos)"
#   wird nur im Benachrichtigungsverlauf erfasst. Da EICAR eine branchenübliche Testdatei und keine echte Bedrohung ist,
#   wird sie weder unter Quarantäne gestellt noch blockiert, und die Datei bleibt unverändert (nur eine echte Malware-Probe wird in den Quarantäne-Manager verschoben).

## Ein Lehrbuch-Reverse-Shell-Einzeiler aus öffentlichen Offensive-Security-Referenzen (harmlos, wird nie ausgeführt)
echo 'bash -i >& /dev/tcp/127.0.0.1/4444 0>&1' > ~/Downloads/rs_test.sh
## → Auch ohne installiertes ClamAV erscheint eine Benachrichtigung „Gefährliche Download-Datei unter Quarantäne gestellt“, und die Datei wird
##   sofort in den Quarantäne-Ordner verschoben (unabhängig von ClamAVs Signaturdatenbank)

# Einen harmlosen LaunchAgent anlegen, der einen rohen Skriptinterpreter direkt aufruft (wird nie tatsächlich ausgeführt)
cat > ~/Library/LaunchAgents/com.example.selfcheck.plist <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>com.example.selfcheck</string>
  <key>ProgramArguments</key><array><string>/bin/bash</string><string>-c</string><string>echo hi</string></array>
</dict></plist>
EOF
# → Innerhalb weniger Sekunden sollte eine Benachrichtigung „Neue Autostart-Registrierung erkannt“ erscheinen. Danach entfernen:
rm ~/Library/LaunchAgents/com.example.selfcheck.plist

# Ob der verwaltete Abschnitt vorhanden ist (2 BEGIN/END-Zeilen bei Pro + Standardmodus)
sudo grep -c 'RoamSwitch link guard' /etc/hosts

# Inhalt des Abschnitts und Anzahl der Sinkholes
sudo sed -n '/BEGIN RoamSwitch link guard/,/END RoamSwitch link guard/p' /etc/hosts | head -4
sudo sed -n '/BEGIN RoamSwitch link guard/,/END RoamSwitch link guard/p' /etc/hosts | grep -c '^0\.0\.0\.0'

# Ob es tatsächlich blockiert wird (mit einem Eintrag aus dem Abschnitt geprüft; harmlos)
D=$(sudo sed -n '/BEGIN RoamSwitch/,/END RoamSwitch/p' /etc/hosts | awk '/^0\.0\.0\.0/{print $2; exit}')
dscacheutil -q host -a name "$D"   # → ip_address: 0.0.0.0 (Namensauflösung ist blockiert)

# Auch bestätigen, dass der obige Abschnitt über Menü → „Linkschutz" → „Aus" verschwindet

# Öffentlicher Feed und Manifest (von jedem abrufbar und überprüfbar)
curl -s https://lafine.net/updates/v1/manifest        # version/generated/threatfeed{...}
curl -sI https://lafine.net/updates/v1/manifest.sig   # → text/plain
# Es wird nur ein GET ohne Query-String, Cookies oder gerätespezifische Kennung gesendet (nur der Standard-User-Agent). Mit parallel laufendem tcpdump überprüfbar.

# Mit aktivierter präventiver Sperre mit einem nicht vertrauenswürdigen Netzwerk verbinden → auf permanent-Einträge prüfen
arp -an | grep -i permanent          # Gateway und andere IPs werden als (permanent) aufgeführt
ndp -an | grep -i 'P '               # IPv6-Seite (P = permanent)
sudo cat "/Library/Application Support/RoamSwitch/gateway_arp_lock.json"  # Die Menge der aktuell fixierten IP→MAC-Zuordnungen
# Sperre über das Menü aufheben → das Obige sollte verschwinden

# Setzt wireguard-tools voraus (über Homebrew)
brew list wireguard-tools >/dev/null && echo "wireguard-tools: OK"

# VPN in einem nicht vertrauenswürdigen Netzwerk aktivieren → bevor der Tunnel steht, befindet sich pf im Kill-Switch-Zustand
sudo pfctl -sr | grep -E 'block drop all|pass .*(utun|udp)'   # block drop all + eine begrenzte Menge an pass-quick-Regeln

# Nachdem der Tunnel steht (wg-quick up bereits ausgeführt)
wg show                              # handshake / transfer läuft
route -n get default | grep interface  # → utunN (die Standardroute ist der Tunnel)
# VPN deaktivieren → Kill-Switch wird aufgehoben, pf kehrt in den vorherigen Zustand zurück

# Der registrierte LaunchDaemon
sudo launchctl print system/com.tetsuharu.RoamSwitch.Helper

# Die aktuell geladenen pf-Regeln (tatsächlicher Zustand von Air-Gap / Port-Guard)
sudo pfctl -sr

# Das Zustandsverzeichnis des Helpers
ls -la "/Library/Application Support/RoamSwitch/"

BIN=/Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
              '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | "$BIN"
# Liefert serverInfo und die Tool-Definitionen zurück. Es entsteht keine Netzwerkverbindung.

git clone https://github.com/lafine1211/roamswitch-mcp
cd roamswitch-mcp
swift build -c release        # Derselbe Quellcode wie in der ausgelieferten Binärdatei
swift test                    # Unit-, Adversarial-Input-, stdio- und Mutations-Fuzzing-Tests
# Testinhalte und gefundene Probleme siehe SECURITY_TESTING.md

# Der Rohwert, der an das Token gebunden ist (gesendet wird nur ein gesalzener SHA-256)
ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'