RoamSwitch Sensor Betriebshandbuch

Das Einrichtungs- und Betriebshandbuch für RoamSwitch Sensor — einen Netzwerksensor, der, sobald er im LAN platziert ist, neue Geräte und Spoofing im selben Segment erkennt und aktive Schwachstellenprüfungen gegen jeden Endpunkt durchführt, auf dem bereits RoamSwitch (Mac / Linux Client / Server Edition) läuft. Verteilt über apt/dnf-Pakete.

1. Überblick & Einordnung

RoamSwitch (Mac / Linux Client / Server Edition) ist in jeder Form ein auf dem Host residenter Agent. Dieser Aufbau hat zwei strukturelle blinde Flecken.

• Die Selbstdiagnose eines einzelnen Hosts hat einen grundsätzlichen blinden Fleck: Das Risiko lateraler Bewegung – "nach außen geschlossen, aber von einem anderen Gerät im selben LAN aus völlig offen einsehbar" – kann ein Host, der nur sich selbst betrachtet, niemals erkennen.
• Manche Geräte können RoamSwitch grundsätzlich nicht ausführen: IoT-Geräte (Netzwerkkameras, Smart Plugs, Multifunktionsdrucker), Gäste-/BYOD-Geräte, Netzwerkgeräte selbst, eingebettete Geräte und mehr.

RoamSwitch Sensor ist ein dedizierter, im LAN platzierter Knoten, der diese beiden Lücken schließen soll. Heute implementiert und verifiziert sind: aktive Schwachstellenaudits von RoamSwitch-Endpunkten im selben LAN; ein Geräteverzeichnis des LAN, aufgebaut aus einem ARP-Sweep und der Überwachung der ARP-Tabelle, mit Erkennung neuer Geräte und von Spoofing; sowie Referenzinformationen zu verdächtigem Verhalten (Verbindungen zu bösartigen IPs, Anzeichen einer Botnet-Beteiligung, DNS-Tunneling und mehr) aus dem optionalen passiven Mitschnitt (Opt-in) (siehe §6). Der Sensor erkennt und meldet nur; er blockiert nie Datenverkehr. Er ist als schlanke NDR-Lösung (Network Detection & Response) in Kombination mit einem eigenen, beweisbasierten Schwachstellenscanner konzipiert – nicht als EDR.

Selbstschutz wird bewusst nicht implementiert (eine gezielte Designentscheidung). Wenn Sie den Sensor-Host selbst vor Angriffen schützen müssen, empfehlen wir, zusätzlich RoamSwitch for Linux Server Edition auf derselben Maschine zu installieren. Beide laufen als vollständig unabhängige Prozesse nebeneinander.

2. Aktuelle Verifizierungsumgebung

• Unterstütztes Betriebssystem: Debian 12 (bookworm)+ / Ubuntu 22.04+ (apt), Fedora/RHEL-Familie (dnf). Nur x86_64 (amd64) — arm64 wird noch nicht unterstützt.
• Zielhardware (Zukunftsplan): Für den Praxisbetrieb stellen wir uns ein stromsparendes, für den Dauerbetrieb geeignetes Gerät vor, etwa einen lüfterlosen Mini-PC der N100/N150-Klasse, aber es gibt heute keinen dedizierten Build oder keine darauf ausgerichtete Auslieferung.
• Netzwerkplatzierung: Er muss physisch oder logisch an das zu überwachende LAN-Segment angeschlossen sein (roamswitch-sensor.service läuft im Host-Netzwerk, da er die ARP-Tabelle direkt beobachten muss). Um Kopplungs- und Audit-Anfragen von Endpunkten anzunehmen, muss er außerdem mit einer festen IP-Adresse laufen (statische Zuweisung oder DHCP-Reservierung). Er lauscht auf TCP-Port 50543 (standardmäßig auf allen Schnittstellen; änderbar mit control.bind_addr; TLS 1.3 wird auf demselben Port akzeptiert – siehe §4.4).
• Ressourcenverbrauch: residenter Speicher im Bereich weniger Dutzend MB; die CPU-Last im Leerlauf ist äußerst gering.
• Empfohlen: nmap (für den ARP-Sweep, die ergänzenden NSE-Prüfungen und die MAC-Prüfung geplanter Audits). Ohne nmap funktionieren die übrigen Funktionen weiterhin, aber es wird kein ARP-Sweep durchgeführt, und der Sensor fällt auf einen passiven Betrieb zurück, der nur Geräte sieht, mit denen er selbst kommuniziert hat.

3. Installation & Start

Installieren Sie das Paket roamswitch-sensor aus dem offiziellen, signierten Paket-Repository. Nach der Installation wird roamswitch-sensor.service (systemd) automatisch aktiviert und gestartet.

3.1 APT (Ubuntu/Debian)

# 1. Repository-Signaturschlüssel registrieren
curl -fsSL https://lafine.net/apt/roamswitch-archive-keyring.asc \
  | sudo gpg --dearmor -o /usr/share/keyrings/roamswitch-archive-keyring.gpg

# 2. Repository hinzufügen
echo "deb [signed-by=/usr/share/keyrings/roamswitch-archive-keyring.gpg] https://lafine.net/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/roamswitch.list

# 3. Installieren
sudo apt update && sudo apt install roamswitch-sensor

3.2 DNF/RPM (Fedora/RHEL)

# 1. GPG-Schlüssel importieren
sudo rpm --import https://lafine.net/rpm/RPM-GPG-KEY-roamswitch

# 2. Repository-Konfigurationsdatei hinzufügen
sudo curl -fsSL -o /etc/yum.repos.d/roamswitch.repo https://lafine.net/rpm/fedora/roamswitch.repo

# 3. Installieren
sudo dnf install roamswitch-sensor

3.3 Startprüfung

systemctl status roamswitch-sensor.service
sudo roamswitch-sensor status

3.4 CLI/TUI ausführen

Die CLI (roamswitch-sensor) und das interaktive TUI (roamswitch-sensor-tui) können direkt nach der Installation ausgeführt werden.

sudo roamswitch-sensor status
sudo roamswitch-sensor-tui

4. Pairing (Code-Verfahren)

Im Auslieferungszustand vertraut Sensor niemandem. Das Pairing erfolgt mit einem einmaligen Pairing-Code, den der Sensor-Betreiber ausstellt. Das Vertrauensverhältnis — „Sensor darf aktive Schwachstellenprüfungen gegen diesen Endpunkt ausführen“ — wird in einem einzigen Pairing-Schritt gleichzeitig in beide Richtungen hergestellt (ein nur einseitiges Vertrauen gibt es nicht).

Voraussetzung: Betreiben Sie Sensor unter einer festen IP-Adresse (statische Zuweisung oder DHCP-Reservierung). Nach dem Pairing verbindet sich der Endpunkt fortan stets direkt mit der beim Pairing bestätigten IP-Adresse von Sensor (es gibt keine automatische Erkennung mehr, etwa per mDNS) — ändert sich Sensors IP später, ist ein erneutes Pairing nötig. Der Endpunkt selbst kann weiterhin eine dynamische IP haben.

4.1 Einen Pairing-Code ausstellen (Sensor-Seite)

# Auf der Sensor-Seite ausführen (oder in der TUI die Taste c drücken)
sudo roamswitch-sensor issue-code

Es wird ein 8-stelliger, einmaliger Code ausgestellt (Großbuchstaben und Ziffern; die leicht zu verwechselnden Zeichen 0/O/1/I/L sind ausgeschlossen). Er läuft nach 10 Minuten ab und ist nur einmal verwendbar; geben Sie ihn daher zügig auf einem Out-of-Band-Weg (Telefon, Chat) an den Endpunkt-Betreiber weiter. Angezeigt wird außerdem der Fingerprint des TLS-Zertifikats (SHA-256) des Sensors. Der Endpunkt pinnt diesen Wert, geben Sie ihn also zusammen mit dem Code weiter (Sie sehen ihn jederzeit mit roamswitch-sensor pairing show oder in der TUI auf dem Bildschirm T).

4.2 Pairing mit dem Code (Endpunktseite)

# Endpunktseite (roamswitch-linux)
sudo roamswitch sensor pair --addr <SENSOR_IP> --code <CODE> --fingerprint <SHA256_FINGERPRINT>

In der Mac-Edition gelingt dasselbe in der GUI über den Menüleisten-Eintrag „🔍 RoamSwitch Sensor-Kopplung…“ durch Eingabe der IP-Adresse des Sensors, des Pairing-Codes und des Zertifikats-Fingerprints.

Nach der Kopplung wird jedes weitere aktive Audit und jeder Abruf von Ergebnissen mit Ed25519-Signaturen authentifiziert. Ein Linux-Endpunkt kommuniziert über TLS 1.3 nur mit einem Sensor, dessen Zertifikat zum eingegebenen Fingerprint passt, und fällt nie automatisch auf Klartext zurück (§4.4). Ab diesem Punkt betrachten der Endpunkt, der den Code kannte, und der Sensor, der ihn ausgestellt hat, einander als vertrauenswürdig.

4.3 Manuelles Pairing (direktes Registrieren eines bekannten Public Keys)

Kennt der Sensor-Betreiber den Public Key und die Adresse eines Endpunkts bereits aus einer anderen Quelle, kann er diesen auch ohne Austausch eines Pairing-Codes direkt auf der Sensor-Seite registrieren (normalerweise sollten Sie stattdessen das codebasierte Verfahren aus §4.2 verwenden und den Endpunkt sich selbst pairen lassen). Ihren eigenen Public Key und Ihre Adresse können Sie mit den folgenden Befehlen abfragen.

# Eigenen Public Key/Adresse auf der Endpunktseite prüfen
sudo roamswitch sensor key

# Eigenen Public Key/Adresse/MAC-Adresse auf der Sensor-Seite prüfen
sudo roamswitch-sensor status

# Sensor-Seite
sudo roamswitch-sensor pair <vollständiger öffentlicher Schlüssel> --addr <IP-Adresse> --confirm

4.4 Sicherheit der Control-API (TCP 50543): TLS, Fingerprint, Sperre

Kopplung, Audit-Anfragen und der Abruf von Ergebnissen laufen über die Control-API des Sensors (TCP 50543). Die folgenden Schutzmaßnahmen sind eingebaut.

• TLS 1.3 und ein Zertifikats-Pin: Die Einstellung control.tls (wirksam nach Neustart des Daemons) ist off (nur Klartext), optional (der Standard: TLS 1.3 und veralteter Klartext auf demselben Port, mit einer Warnung bei jeder angenommenen Klartextverbindung) oder required (nur TLS 1.3). Das Zertifikat ist selbstsigniert (ECDSA P-256), und das Vertrauen wird durch einen Pin seines SHA-256-Fingerprints entschieden, nicht durch Ablaufdatum oder Name. Der Pin wird nie über das Netzwerk abgerufen: Der Betreiber tippt den auf dem Sensor-Bildschirm angezeigten Wert in den Endpunkt ein.
• Fingerprint-Bindung der Kopplungsanfrage: Der Endpunkt signiert den von ihm gepinnten Fingerprint mit seinem eigenen privaten Schlüssel und nimmt ihn in die Kopplungsanfrage auf. Eine Anfrage, die über einen Man-in-the-Middle mit einem anderen Zertifikat lief, schlägt mit fingerprint_mismatch fehl, und der Pairing-Code wird nicht verbraucht.
• Replay-sichere Signaturen (v2): Signaturen für Audit-Anfragen und den Abruf von Ergebnissen nutzen das v2-Format, das einen Zeitstempel (±300 s) und eine Nonce enthält, sodass Wiedereinspielungen abgewiesen werden. Veraltete v1-Signaturen enthalten beides nicht und können wiedereingespielt werden; control.allow_legacy_signatures (Standard true, gedacht für die Migrationsphase; jede Verwendung protokolliert eine Deprecation-Warnung) entscheidet, ob sie akzeptiert werden. Setzen Sie es auf false, sobald jeder Endpunkt v2 sendet.
• Sperre: Das Erraten von Pairing-Codes sperrt eine Quell-IP für 60 Sekunden nach 5 Fehlversuchen innerhalb von 10 Minuten (bei Wiederholung exponentiell verlängert, bis zu 1 Stunde), und 20 Fehlversuche über alle Quellen hinweg lösen eine globale Sperre aus. Signaturfehler werden etwas nachsichtiger behandelt (10 pro Quell-IP, 100 insgesamt). Eine Sperre löst die Benachrichtigung control_api_lockout aus.
• Lauschadresse: Das Einschränken von control.bind_addr (Standard 0.0.0.0, wirksam nach Neustart) auf die LAN-Adresse des Sensors verringert die Angriffsfläche. Der Daemon warnt, solange es sich um eine Wildcard-Adresse handelt.
• Zertifikatsrotation: roamswitch-sensor tls rotate (in der TUI auf dem Bildschirm T die Taste R drücken) erzeugt das Zertifikat neu. Jeder Pin des alten Fingerprints wird ungültig, sodass jeder Endpunkt den neuen Wert eingeben muss (sudo roamswitch sensor repin <public key> --fingerprint <value>). Die Kopplung selbst bleibt erhalten.

sudo roamswitch-sensor pairing show                       # mode, fingerprint, warnings
sudo roamswitch-sensor tls rotate                         # regenerate the certificate
sudo roamswitch sensor repin <PUBLIC_KEY> --fingerprint <NEW_FINGERPRINT>   # on each endpoint

5. Aktive Schwachstellenprüfung

Sensor führt nicht-destruktive, beweisbasierte Schwachstellendiagnosen gegen gepaarte Endpunkte durch. Destruktive Operationen (Schreiben oder Löschen von Daten, Stoppen von Diensten) werden niemals ausgeführt.

sudo roamswitch-sensor scan <öffentlicher Schlüssel oder dessen Anfang>

Die Prüfung besteht aus vier Phasen.

1. Vollständiger Portscan: erkennt lückenlos jeden offenen TCP-Port auf dem Zielhost.
2. Diagnose bekannter Signaturen: nicht-destruktive, beweisbasierte Prüfungen bekannter Schwachstellenmuster – unauthentifizierte Exposition von Redis / dockerd / Memcached / MongoDB / Elasticsearch / CouchDB / Jenkins / VNC, SMTP-Open-Relay-Diagnose (eine sichere Methode, die nur MAIL FROM/RCPT TO sendet, niemals DATA) sowie Diagnosen für CORS-Fehlkonfigurationen, Path Traversal und Open Redirects auf Dev-Servern, unter anderem.
3. Generisches Banner-Grabbing: ruft für offene Ports, die nicht durch die obigen Signaturen abgedeckt sind, den Banner-String allein durch Verbindungsaufbau ab (es werden keine Daten gesendet).
4. Ergänzende nmap-NSE-Diagnose: breite, protokollübergreifende ergänzende Diagnose über nmap --script safe. Wird automatisch ausgeführt, sobald nmap auf dem Host installiert ist (andernfalls passiert nichts).

Jeder Prüfdurchlauf wird in /var/lib/roamswitch-sensor/scan_history.json protokolliert – unabhängig davon, ob etwas gefunden wurde, da auch ein zu diesem Zeitpunkt sauberes Ergebnis einen dokumentarischen Wert hat – und kann über die CLI oder das TUI eingesehen werden.

roamswitch-sensor history
sudo roamswitch-sensor report <öffentlicher Schlüssel oder dessen Anfang> --out /tmp/report.md

5.1 Audit-Anfrage von Client-Seite (Pull-Modell)

Ein gepaarter Endpunkt kann auch aktiv ein Audit bei Sensor anfordern. In der Mac-Edition nutzen Sie „Audit von Sensor anfordern“ in der Menüleiste, unter Linux den folgenden Befehl.

sudo roamswitch sensor request-audit

Nachdem Sensor das Audit ausgeführt hat, fragt der Endpunkt das Ergebnis ab — beginnend 5 Minuten nach der Anfrage, danach alle 5 Minuten, bis zu 5 Versuche lang (also maximal 25 Minuten). Jedes abgerufene Ergebnis wird auch lokal auf dem Endpunkt gespeichert.

roamswitch sensor results

In der Mac-Edition erscheinen Ergebnisse zudem in der Liste „Audit-Ergebnisse“ im Einstellungsfenster oder können über das MCP-Tool get_sensor_audit_results abgerufen werden — als Eingabe für einen KI-Agenten, der eine Abhilfemaßnahme plant. Der Abruf eines Ergebnisses kann auch ausdrücklich abgelehnt werden, etwa wenn das Pairing auf der Sensor-Seite aufgehoben wurde (siehe §10 F6).

6. Passive ARP-Überwachung & LAN-Sichtbarkeit

Der Sensor lernt LAN-Geräte auf zwei Wegen kennen. (1) Überwachung der ARP-Tabelle: Er liest etwa alle 10 Sekunden seine eigene ARP-Tabelle (/proc/net/arp) und erkennt „eine neue, nie zuvor gesehene IP/MAC“ sowie „eine Änderung der MAC-Adresse einer bekannten IP“ (ein Hinweis auf Gateway-Spoofing und Ähnliches). (2) Ein aktiver ARP-Sweep: nmap -sn -PR durchsucht das direkt angeschlossene Subnetz (bis zu einem /22) und speichert IP, MAC, Hostnamen, Hersteller, Online-Status, Erst-/Letztsichtung und IP-Historie im Geräteverzeichnis. Der Sweep läuft stündlich, auf Anforderung (refresh / die Taste r der TUI) und beim Start der TUI; ohne nmap bleibt nur das passive Verhalten (1). Hersteller und eine Geräteklasse (IoT oder nicht usw.) werden zusätzlich aus dem OUI der MAC abgeleitet.

roamswitch-sensor arp-events

Erkannte Ereignisse zeigt roamswitch-sensor arp-events sowie der TUI-Reiter „ARP-Ereignisse“ (Enter für Details). Jedes Ereignis enthält seinen Zeitpunkt, einen Schweregrad (von kritisch bis Info; eine MAC-Änderung der Gateway-IP ist „kritisch“), die Begründung, die Identität der beteiligten Geräte und konkrete nächste Schritte.

6.1 Erweiterung der passiven LAN-Sichtbarkeit (Opt-in)

Während die obige ARP-Überwachung nur Geräte erfasst, mit denen Sensor selbst kommuniziert hat, werden durch Setzen der Umgebungsvariable ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE auf eine Zielschnittstelle Ethernet/IPv4-Header darauf beobachtet (keine Payload-Prüfung), um Folgendes zu erkennen.

• Passive Beobachtung neuer Geräte: Geräte, mit denen Sensor nie direkt kommuniziert hat und die die reine ARP-Überwachung nicht abdeckt. Wird aus Broadcast-/Multicast-Verkehr gelernt.
• Erkennung von Kontakt mit bekannten bösartigen IPs: markiert Datenverkehr, dessen Ziel-IP mit dem lokalen Bedrohungs-Feed übereinstimmt (gleiches Format wie der Egress Guard von RoamSwitch selbst) — nur Erkennung, niemals Blockierung.

sudo systemctl edit roamswitch-sensor.service
# [Service]
# Environment=ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE=eth0

sudo systemctl restart roamswitch-sensor.service
roamswitch-sensor passive-events

6.2 Geräteverzeichnis und Gerätenotizen

Das Verzeichnis zeigen Sie mit roamswitch-sensor device-inventory (TUI-Reiter „Netzwerk“). Wird mit device-note (Taste n in der TUI) eine Notiz wie Name, Zweck oder Standort hinterlegt, gilt das Gerät als „erfasst“, während Geräte ohne Notiz als „zu prüfen“ hervorgehoben werden (zum Abgleich mit Ihrem Asset-Register).

sudo roamswitch-sensor refresh
roamswitch-sensor device-inventory
sudo roamswitch-sensor device-note aa:bb:cc:dd:ee:ff "3F copier"

6.3 Referenzinformationen zu verdächtigem Verhalten (nur Erkennung)

Bei aktivem passivem Mitschnitt (§6.1, Opt-in) werden die folgenden Referenzinformationen angezeigt. Alles davon ist nur Erkennung und Anzeige; der Sensor blockiert nie Datenverkehr.

• Verhalten von IoT-Geräten (iot-events): Verbindungen klassifizierter Geräte zu bekannten bösartigen IPs oder zu Verwaltungsports (SSH/RDP/SMB usw.). Zusätzlich wird die Modellerkennung anhand der eigenen mDNS-/SSDP-/DHCP-Ankündigungen der Geräte genutzt.
• Verdächtiger Datenverkehr (network-threats): Verbindungen zu vielen Zielen innerhalb eines 30-Sekunden-Fensters (Hinweis auf Scanning oder einen Sprungpunkt), eine Flut von Verbindungen zu einem Ziel (Hinweis auf DDoS-Beteiligung) sowie Anzeichen von DNS-Tunneling/C2 (nur die strukturellen Merkmale der Abfragenamen werden verwendet; Domainnamen werden nicht gespeichert).
• Advisories (iot-advisories): Referenzinformationen zu öffentlichen CVEs für Produkte bekannter IoT-Hersteller (statisch mitgeliefert; es gibt kein Netzwerk-Update).

7. CLI-Befehlsübersicht

Die CLI unterstützt nur Japanisch und Englisch (sie richtet sich nach der Umgebungsvariable LANG).

8. TUI-Bedienungsanleitung

Die interaktive TUI (roamswitch-sensor-tui) unterstützt 10 Sprachen und kann jeden CLI-Unterbefehl, jede IPC-Methode des Daemons, jeden Konfigurationsschlüssel und den Collector bedienen (mit m öffnen Sie das Funktionsmenü). Sechs Haupt-Reiter wechseln Sie mit der Tab-Taste (Shift+Tab geht zurück): Gekoppelt (der jeweils neueste Audit-Stand jedes Endpunkts) / Netzwerk (jedes Gerät im LAN, mit Notizen) / ARP-Ereignisse / Scan-Verlauf / Diff (Änderungen seit dem vorherigen Audit; neue Befunde in Rot, behobene in Grün, vermutlich nicht erreichbar in Gelb) / Audit-Protokoll (wer wann was freigegeben oder ausgeführt hat; das Ergebnis der Hash-Ketten-Prüfung steht oben). Ansichten, die nicht in 80 Spalten passen (passive Überwachung, IoT-Verhalten, verdächtiger Datenverkehr, IoT-Advisories), öffnen sich über das Menü m.

9. Vertrauensmodell & Sicherheitsdesign

• Bestätigung über einen Out-of-Band-Kanal (nicht TOFU): Der Betreiber gibt den auf dem Sensor-Bildschirm angezeigten Zertifikats-Fingerprint und den Pairing-Code per Telefon, Chat o. Ä. an den Endpunkt weiter. Der Endpunkt ruft den Pin nie über das Netzwerk ab (es ist kein TOFU, das der ersten Verbindung bedingungslos vertraut) und kommuniziert nur mit einem Sensor, dessen Zertifikat zum eingegebenen Wert passt, und koppelt sich nur mit diesem. Die bei der Kopplung ausgetauschten Public Keys verifizieren jede spätere Sondierung und Anfrage.
• So konzipiert, dass Lücken erkannt werden, die destruktive Aktionen ermöglichen würden – ohne selbst je eine destruktive Aktion auszuführen: Jede aktive Schwachstellenprüfung ist nicht-destruktiv (sie schreibt oder löscht niemals Daten und stoppt keine Dienste). Erkannt werden dagegen die Fehlkonfigurationen selbst – etwa „ohne Authentifizierung beschreibbar“ oder „funktioniert als Open Relay“ –, die bei Ausnutzung eine destruktive Aktion ermöglichen würden.
• Fehlalarm-Vermeidung (Selbstprüfungs-Ausschluss): Ein Abgleich der Quell-IP ist eingebaut, damit die eigene Voll-Port-Prüfung eines gepaarten Sensors nicht von der Eingangsportscan-Erkennung (einer RoamSwitch-seitigen Funktion) als Aufklärung fehlinterpretiert wird. Die IP wird ausschließlich für diesen Abgleich verwendet, um eine automatische Sperrung zu vermeiden – niemals für die Vertrauensentscheidung selbst. Außerdem formuliert die Mac-Ausgabe nur von der Anforderung einer Prüfung bei einem Sensor bis zum Eintreffen des Berichts (höchstens etwa 25 Minuten, falls kein Bericht kommt) die Erkennungen von der Sensor-Adresse und die „SYN-Flut“-Warnung (die keine Quelladresse hat) ruhiger als wahrscheinlich durch die Prüfung verursacht; die Linux-Ausgabe tut dies für die „SYN-Flut“-Warnung. Außerhalb dieses Fensters bleibt die deutliche Warnung wie bisher, und vom Sensor selbst gestartete Prüfungen sind nicht erfasst.
• Ausgehender Datenverkehr ist begrenzt, und Gerätedaten werden standardmäßig nicht gesendet: Erkannte Geräteinformationen, Audit-Ergebnisse und ARP-Ereignisse werden standardmäßig nur im lokalen Speicher des Sensors abgelegt und nie an Lafine oder Dritte gesendet. Der einzige ausgehende Datenverkehr ist der Abruf von Erkennungsdaten (der CVE-Map und der nmap-NSE-Datenbank; mit updates.fetch_cve_map abschaltbar, ohne Geräte- oder Audit-Daten) sowie die Benachrichtigungen (Webhook, syslog) und Uploads an den zentralen Collector aus §11, die nur an Ihre eigenen Ziele gehen und nur, wenn Sie sie konfigurieren.

10. Fehlerbehebung & FAQ

F1. Die Eingabe eines Pairing-Codes wird abgelehnt.

Es gibt vier wahrscheinliche Ursachen: (1) Der Code ist 10 Minuten nach der Ausstellung abgelaufen (den Sensor-Betreiber mit issue-code einen neuen ausstellen lassen), (2) ein Tippfehler im Code (die leicht zu verwechselnden Zeichen 0/O/1/I/L werden bei der Ausstellung ausgeschlossen, ein Code enthält sie also nie), (3) die an --addr übergebene IP-Adresse stimmt nicht mit der aktuellen festen IP-Adresse des Sensors überein, (4) --fingerprint stimmt nicht mit dem Zertifikat des Sensors überein (pin_mismatch / fingerprint_mismatch; prüfen Sie den Wert mit roamswitch-sensor pairing show. Wiederholte Fehler sperren Sie aus und liefern rate_limited).

F2. Das ergänzende NSE-Diagnoseergebnis ist leer.

Einer von zwei Gründen: (1) nmap ist im Container nicht installiert; (2) es wurde ausgeführt, aber die für die Zielports zutreffenden sicheren Skripte lieferten tatsächlich keine Ausgabe. Die ergänzende nmap-NSE-Diagnose wird automatisch ausgeführt, sobald nmap auf dem Host installiert ist.

F3. Wie lange dauert eine vollständige Prüfung?

Ein reiner vollständiger Portscan dauert etwa einige Dutzend Sekunden, aber sobald nmap auf dem Host installiert ist, kommt die ergänzende NSE-Diagnose automatisch hinzu, wodurch es je nach Anzahl offener Ports des Ziels bis zu etwa 2 Minuten dauern kann. Das TUI zeigt während der Ausführung fortlaufend die verstrichenen Sekunden an, sodass Sie den Fortschritt beim Warten verfolgen können.

F4. Ich habe gepaart, kann aber immer noch kein Audit ausführen.

Wahrscheinliche Ursachen: (1) sensor_pairing_enabled: true ist auf dem Endpunkt nicht gesetzt (standardmäßig aus), (2) die feste IP-Adresse des Sensors hat sich nach der Kopplung geändert, und der Endpunkt erreicht die alte, bei ihm hinterlegte Adresse nicht mehr (neu koppeln), (3) die Kopplung wurde auf dem Sensor mit unpair entfernt, (4) der Sensor hat sein Zertifikat neu erzeugt (tls rotate), sodass der Pin des Endpunkts veraltet ist (den neuen Fingerprint mit roamswitch sensor repin eingeben). Prüfen Sie mit roamswitch sensor list (Endpunkt) und roamswitch-sensor list (Sensor), dass jede Seite die andere aufführt.

F5. Kann Sensor selbst zusammen mit RoamSwitch (Client/Server Edition) verwendet werden?

Ja. Da Sensor bewusst ohne Selbstschutzfunktionen konzipiert ist, empfehlen wir, RoamSwitch for Linux Server Edition zusätzlich auf derselben Maschine zu betreiben. Beide arbeiten als vollständig unabhängige Prozesse und Datenspeicher ohne Konflikte.

F6. roamswitch sensor results meldet, das Pairing sei aufgehoben worden.

Das Pairing dieses Endpunkts wurde auf der Sensor-Seite mit unpair entfernt. Bitten Sie den Sensor-Betreiber, einen neuen Pairing-Code auszustellen, und pairen Sie erneut mit roamswitch sensor pair --addr <ip> --code <code> --fingerprint <SHA-256>.

11. Audit-Funktionen für Organisationen (optional)

Funktionen für Sicherheitsteams großer Organisationen, die Audit-Nachweise und einen klaren Überblick über Veränderungen benötigen. Alle sind standardmäßig deaktiviert, und es wird nie etwas an Lafine oder Dritte gesendet – jedes Ziel für Benachrichtigungen oder Aggregation legt Ihre Organisation selbst fest. Einstellungen ändern Sie mit sudo roamswitch-sensor config set <Schlüssel> <Wert> (kein Neustart des Daemons nötig; jede Änderung wird im Betriebsprotokoll festgehalten); config show zeigt die aktuellen Werte.

11.1 Geplante Audits und Änderungserkennung

Mit schedule.enabled auf true werden alle gekoppelten Endpunkte automatisch auditiert (standardmäßig alle 24 Stunden: schedule.interval_hours; Zeitfenster in Ortszeit, in dem Audits starten dürfen: schedule.window_start_hour / window_end_hour, auch über Mitternacht; Parallelität: schedule.max_parallel). Jedes Audit wird mit dem vorherigen verglichen; roamswitch-sensor diff zeigt neue Befunde (Regressionen), behobene Befunde und neu geöffnete Ports. Sind plötzlich alle zuvor offenen Ports nicht mehr sichtbar, gilt das als vermutlich nicht erreichbar, nicht als „behoben“ – ein ausgeschaltetes Gerät ist von einem, das alle Ports geschlossen hat, von außen nicht zu unterscheiden.

Auch unbeaufsichtigte Audits brechen nicht die Zusicherung, dass nur zustimmende Endpunkte auditiert werden. Die IP eines Endpunkts kann per DHCP an ein anderes Gerät gehen. Der Sensor speichert daher die MAC-Adresse, die der Endpunkt bei seiner letzten Authentifizierung (Kopplung oder signierte Audit-Anfrage) hatte, und prüft vor und nach jedem geplanten Audit mit einer echten ARP-Anfrage von nmap, dass unter dieser IP weiterhin dieselbe MAC antwortet. Andernfalls wird das Audit übersprungen (oder sein Ergebnis verworfen) und eine Benachrichtigung ausgelöst. Auch ein manueller scan wird abgelehnt, wenn es Hinweise gibt, dass die Adresse nun einem anderen Gerät gehört. Die Prüfung setzt nmap voraus; vor dieser Funktion gekoppelte Endpunkte werden erst nach erneuter Kopplung oder einer signierten Audit-Anfrage eingeplant; erfasst werden nur Endpunkte im selben L2-Segment.

11.2 Benachrichtigungen (Webhook und syslog)

Regressionen, neue Geräte, ARP-Spoofing, verdächtiger Datenverkehr u. a. gehen an notify.webhook_urls (Incoming-Webhooks von Slack, Discord oder Teams oder ein beliebiger generischer JSON-Endpunkt) und an notify.syslog.host / port / protocol (RFC 5424 über UDP oder TCP). Einschränken lässt sich mit notify.min_severity (info / medium / high / critical) und notify.cooldown_minutes (Mindestabstand, bevor dasselbe Ereignis erneut gesendet wird). roamswitch-sensor notify-test prüft jedes Ziel.

11.3 Audit-Nachweise exportieren

roamswitch-sensor export <scans|inventory|audit-log|all> --format csv|json|html [--out FILE] [--endpoint KEY-PREFIX] [--since DATE]. Die HTML-Ausgabe ist eine einzelne Datei: im Browser öffnen und „Als PDF speichern“ wählen, um ein PDF zum Einreichen zu erhalten. CSV ist gegen Formelinjektion in Tabellenkalkulationen geschützt. Das Geräteverzeichnis (inventory) enthält eine Spalte, die zeigt, ob jedes Gerät von RoamSwitch verwaltet (gekoppelt) wird. Ausgabedateien sind nur für ihren Eigentümer lesbar (0600), und der Export selbst wird im Audit-Protokoll festgehalten. Die Taste e der TUI bietet dieselben Auswahlmöglichkeiten in einem Formular, und Berichte und Exporte werden in der Anzeigesprache erzeugt (10 Sprachen; die CLI gibt es auf Japanisch und Englisch).

11.4 Betriebs- und Freigabeprotokoll (manipulationssicher)

Kopplung, Aufhebung der Kopplung, Start und Abschluss von Audits, Konfigurationsänderungen und abgelehnte Zugriffe werden mit dem Verursacher (UID / öffentlicher Schlüssel des Endpunkts / Quell-IP) aufgezeichnet. Jede Zeile enthält den SHA-256 der vorherigen, sodass jede Änderung oder Löschung mit roamswitch-sensor audit-log verify erkannt wird (Exit-Code 2 bei Problemen). Einträge listet roamswitch-sensor audit-log [--limit N] auf. Webhook-URLs enthalten oft ein Token, daher stehen ihre Werte nie im Protokoll der Konfigurationsänderungen. Eine Hash-Kette allein verrät nicht, dass die neuesten Einträge abgeschnitten wurden; deshalb wird der Kettenkopf (Sequenznummer und Hash) auch an den Collector (§11.6) gesendet.

11.5 Aufbewahrung

Setzen Sie retention.scan_history_days, retention.audit_log_days und retention.inventory_stale_days, damit alte Audit-Historie, Protokolleinträge und lange nicht gesehene Geräte automatisch gelöscht werden (0 = nie nach Alter löschen, Standard). Geräte mit einer Notiz werden nie aus dem Inventar entfernt.

11.6 Mehrere Sensoren zusammenführen (zentraler Collector, optional)

Laufen mehrere Sensoren an mehreren Standorten, betreiben Sie auf einem separaten Host roamswitch-sensor-collector (im Paket enthalten, standardmäßig deaktiviert), der signierte Zusammenfassungen aller Sensoren sammelt.

# On the collector host (a separate host from the Sensor is recommended)
sudo systemctl enable --now roamswitch-sensor-collector   # listens on 127.0.0.1:8443 by default
sudo roamswitch-sensor-collector token                     # read token for the dashboard
sudo roamswitch-sensor-collector enroll <Sensor public key> --name Tokyo --site Tokyo

# On each Sensor
sudo roamswitch-sensor config set collector.url https://collector.example.org:8443
sudo roamswitch-sensor config set collector.enabled true

• Akzeptiert werden nur signierte Anfragen von registrierten (enroll) Sensoren (Ed25519-Identität); der Zeitstempel weist außerdem Wiedereinspielungen zurück.
• Sobald er von außerhalb des LAN erreichbar ist, ist TLS erforderlich. Tragen Sie --bind 0.0.0.0:8443 --tls-cert … --tls-key … in COLLECTOR_ARGS in /etc/default/roamswitch-sensor-collector ein oder nutzen Sie --allow-plain-http hinter einem TLS-terminierenden Reverse-Proxy. Das Lauschen auf etwas anderem als 127.0.0.1 ohne TLS wird beim Start abgelehnt.
• Das Dashboard ist durch ein Token geschützt und bietet Filter nach Standort, Ereignisse nach Schweregrad und CSV-Export. Es hebt Sensoren hervor, die verstummt sind, sowie Sensoren, deren Audit-Protokoll abgeschnitten, zurückgesetzt oder verzweigt wirkt (nach der Untersuchung mit clear-anomaly <öffentlicher-Schlüssel> aufheben).
• Mit collector.send_unmanaged_devices (Standard true) nimmt der Sensor nicht gekoppelte Geräte (nicht verwaltete Geräte) in die Zusammenfassung auf. Jedes Gerät wird als „nicht gekoppelter RoamSwitch-Host“ (wenn RoamSwitch in seiner mDNS-/SSDP-Selbstankündigung erscheint; die Aktivierung von collector.probe_control_port unternimmt zusätzlich einen TCP-Verbindungsversuch zum Control-Port 50543, standardmäßig aus) oder als „unbekanntes Gerät“ klassifiziert, und es werden nur MAC, Hersteller, Geräteklasse und Zeitpunkt der Erstsichtung gesendet (niemals Inhalte des Datenverkehrs). In der TUI öffnet O den Verwaltungsbildschirm des Collectors.

11.7 Abruf von Erkennungsdaten (updates.fetch_cve_map)

Der Sensor ruft jeden Tag die signierte CVE-Map (die bekannten Schwachstellendaten für aktive Prüfungen) und die nmap-NSE-Datenbank vom Update-Dienst ab. Dieser Datenverkehr enthält keine Geräte- oder Audit-Daten. Für einen vollständigen Offline-Betrieb führen Sie sudo roamswitch-sensor config set updates.fetch_cve_map false aus (die Änderung gilt ohne Neustart ab dem nächsten Zyklus, und danach werden nur noch die mitgelieferten Daten verwendet).

11.8 Referenz der Konfigurationsschlüssel

Aktuelle Werte prüfen Sie mit roamswitch-sensor config show, ändern können Sie sie mit config set <key> <value> [<key> <value> …] (mehrere Schlüssel werden atomar gespeichert; auch der Konfigurationseditor C der TUI ändert sie). Nur Schlüssel, die in der Spalte „Neustart“ mit „Ja“ markiert sind, erfordern einen Neustart des Daemons (sudo systemctl restart roamswitch-sensor).

12. Rogue-DHCP- und IPv6-Erkennung

Erkannt werden ein anderer Router oder das Gerät eines Angreifers, das ins Netz gebracht wurde und sich als der legitime ausgibt, um zu bestimmen, wohin der Verkehr der Clients läuft. Es wird nur erkannt und gemeldet; der Sensor blockiert nie Datenverkehr. Die Funktion ist standardmäßig an und braucht kein Passiv-Capture. Ergebnisse stehen in roamswitch-sensor network-threats, im TUI-Reiter „Bedrohungen“ (über m), in den Benachrichtigungen (dhcp_rogue_server, ipv6_rogue_router, ndp_spoof, ipv6_unknown_device), im Vorgangsprotokoll und in den Exporten.

12.1 Rogue-DHCP-Server (IPv4 und DHCPv6)

Jede Stunde (und bei jedem roamswitch-sensor refresh) sendet der Sensor von einer zufälligen MAC-Adresse ein DHCP-Discover-Paket (bei DHCPv6 ein SOLICIT) und zählt jeden antwortenden Server. Er sendet kein REQUEST, es wird also keine Adresse geleast. DHCP-Antworten, die das Passiv-Capture sieht, durchlaufen dieselbe Beurteilung. Der zuerst gehörte Server wird als legitim gelernt, jeder später auftauchende wird gemeldet. Ein Server, der ein Gateway oder einen DNS-Server verteilt, den der legitime nicht verteilt, bestimmt, wohin Clients mit seiner Zuweisung ihren Verkehr schicken, und gilt deshalb als schwerste Stufe, critical. Antworten bei der allerersten Abfrage mehrere Server gleichzeitig, kann der Sensor nicht erkennen, welcher echt ist; er lernt keinen und meldet alle.

12.2 IPv6 (Rogue-Router-Advertisements, NDP-Spoofing, reine IPv6-Geräte)

Rogue-Router-Advertisements: Jeder im LAN kann sich als IPv6-Router ausgeben. Der Sensor wertet die Nachbartabelle und die Standardrouten des Kernels, die vom Passiv-Capture gesehenen Router-Advertisements und die Antworten auf seine eigene Router-Solicitation aus und meldet es, wenn etwas anderes als das IPv4-Standardgateway als Router auftritt (den echten in ipv6.allowed_routers eintragen, dann gilt er als legitim; ein Netz, dessen IPv6-Router ein anderes Gerät als das IPv4-Gateway ist, ist ein normaler Fall, tragen Sie ihn dann dort ein). Advertisements mit einem Hop-Limit ungleich 255 sind gefälscht oder geroutet und werden ignoriert. NDP-Spoofing: Wechselt die MAC des Besitzers einer IPv6-Adresse, wird das gemeldet (high, wenn es die Adresse eines Routers ist). Reine IPv6-Geräte: Ein Gerät, das in ARP nie auftaucht, aber in der Nachbartabelle erscheint, wird erst gemeldet, nachdem ein ARP-Sweep die Chance hatte, es zu finden. Das Geräteinventar (CSV-Spalte ipv6, ipv6_addrs in JSON) führt ebenfalls IPv6-Adressen.

12.3 Wer als legitim gilt, und die Einstellungen

Mit dhcp.allowed_servers und ipv6.allowed_routers (MAC oder IP) wird alles andere, was antwortet, gemeldet; bleibt die Liste leer, wird der zuerst gefundene gelernt. dhcp.active_probe und ipv6.active_probe (Standard true) schalten die aktiven Abfragen ab, ipv6.enabled die gesamte IPv6-Überwachung. Das Lauschen der Steuer-API (50543) auf IPv6 kommt mit control.listen_ipv6 hinzu (Standard false, wirkt nach Neustart); eine globale IPv6-Adresse kann aus dem Internet erreichbar sein, wenn der Router keine IPv6-Firewall hat, daher ist es nicht standardmäßig an. Verbindungslimits und Sperren zählen IPv6 pro /64. Ein Endpunkt, der von einer Link-Local-Adresse aus verbunden war, wird nicht als Prüfziel gemerkt, weil er ohne Scope-ID nicht zurückgerufen werden kann.

13. Leichte Prüfung von Geräten ohne RoamSwitch (optional)

Das aktive Schwachstellen-Audit aus §5 betrifft nur Endpunkte, die gekoppelt sind und zugestimmt haben. Für Drucker, Kameras, NAS-Geräte und andere Geräte, die nie gekoppelt wurden, deren offene Dienste man aber trotzdem kennen möchte, gibt es eine getrennte, weit eingeschränktere Prüfung. Tiefe Diagnosen im Stil von OpenVAS, Login-Versuche, das Ausnutzen von Schwachstellen, nmap NSE und Scans des gesamten Portbereichs werden nur bei Endpunkten durchgeführt, die zugestimmt haben.

13.1 Was geprüft wird

Geprüft wird nur die TCP-Verbindung zu 54 festen Ports (Telnet, FTP, RDP, VNC, SMB, Redis, MongoDB, Docker-API, MQTT, RTSP usw.), gelesen wird das Banner, das ein Dienst von sich aus sendet (bei Web-Ports zusätzlich ein HEAD /), und ergänzt wird ein Hinweis, wenn der Hersteller Schwachstellen veröffentlicht hat (Tabelle der IoT-Hinweise). Ein Ergebnis lautet „dieser Dienst ist aus dem LAN erreichbar“, nie „das ist verwundbar“; jeder Befund vermerkt, dass nicht geprüft wurde, ob die Authentifizierung aktiv ist.

13.2 Aktivieren

Zum Aktivieren von unmanaged_audit.enabled setzen Sie zuerst unmanaged_audit.authorization (wer es freigegeben hat: Name, Ticketnummer oder Richtlinienverweis) und unmanaged_audit.allowed_cidrs (die prüfbaren Bereiche; IPv4-Bereiche breiter als /16 und IPv6-Bereiche breiter als /48 werden abgelehnt). Geplante Läufe erfolgen alle interval_hours (Standard 168) innerhalb des schedule-Zeitfensters. Ein manueller Lauf braucht --confirm als zweite Zustimmung.

sudo roamswitch-sensor config set unmanaged_audit.authorization "IT policy 2026-07, approved by A. Suzuki"
sudo roamswitch-sensor config set unmanaged_audit.allowed_cidrs 192.168.10.0/24
sudo roamswitch-sensor config set unmanaged_audit.exclude 192.168.10.1
sudo roamswitch-sensor config set unmanaged_audit.enabled true
sudo roamswitch-sensor audit-unmanaged 192.168.10.40 --confirm
roamswitch-sensor unmanaged-audits --detail

13.3 Schutzvorkehrungen

Nichts außerhalb von allowed_cidrs, kein Gerät aus unmanaged_audit.exclude (IP, Bereich oder MAC), kein gekoppelter Endpunkt und nicht der Sensor selbst wird je untersucht. Vor und nach einem Lauf wird die MAC des Geräts unter dieser Adresse per Live-Abfrage bestätigt (ARP bei IPv4, dafür ist nmap nötig; Neighbour Solicitation bei IPv6); hat sie sich geändert, wird der Lauf abgebrochen oder das Ergebnis verworfen und eine Benachrichtigung gesendet. Der Text von authorization wird bei jedem Lauf ins Vorgangsprotokoll geschrieben und erscheint in den Exporten (export unmanaged, JSON, HTML-Bericht), sodass sich zeigen lässt, wer die Prüfung freigegeben hat.

13.4 Produktprüfung (hat das Produkt Schwachstellen aus dem CISA-KEV-Katalog? Opt-in)

Wenn Sie unmanaged_audit.product_check einschalten (standardmäßig aus), liest die leichte Prüfung den Produktnamen von der Webseite, die ein Gerät normalerweise ausliefert, und meldet, ob dieses Produkt Schwachstellen aus dem CISA-KEV-Katalog hat. Gesendet wird nur ein GET / an die Web-Ports, die eine Verbindung angenommen haben (80, 8080, 8181, 443, 8443, 10443), die Weiterleitungen, auf die das Gerät selbst an derselben Adresse verweist (höchstens zwei), und das Auslesen von Aussteller und Subjekt des HTTPS-Zertifikats. Es werden keine Anmeldungen, Passwortversuche, erratene Pfade und nichts gesendet, was eine Schwachstelle ausnutzt. Das Limit sind 12 Anfragen pro Gerät im Abstand von 150 ms. Die Einwilligungsbedingungen (enabled, authorization, allowed_cidrs, exclude, Ausschluss gekoppelter Geräte und MAC-Neuprüfung) sind genau die aus §13.2–13.3; ist die leichte Prüfung aus, wird nichts gesendet, auch wenn product_check an ist.

Ein Produkt wird nur benannt, wenn seine Merkmale auf der Oberfläche alle in derselben Antwort vorkommen. Als betroffen (high) gilt es nur, wenn die vom Gerät selbst angezeigte Version gelesen werden kann und ein CVE einen NVD-Bereich hat, der sie enthält. Lässt sich die Version nicht lesen, bleibt es bei einem Hinweis (medium): Dieses Produkt hat im KEV gelistete Schwachstellen, die Version war nicht lesbar, ob es betroffen ist, ist unbestätigt. Es wird nie behauptet, das Gerät sei verwundbar. Derzeit zeigt nur MikroTik RouterOS seine Version an, andere Produkte erhalten daher normalerweise den Hinweis „unbestätigt“. Abgedeckt sind Fortinet FortiGate, Ivanti Connect Secure, Citrix NetScaler, Cisco (das ASA-SSL-VPN und die IOS-XE-Weboberfläche), UniFi OS, GeoVision, TerraMaster, Check Point Security Gateway und MikroTik RouterOS; für Aruba-Geräte gibt es keinen KEV-Eintrag, sie sind nicht abgedeckt. Die Merkmale beruhen auf öffentlichen Erkennungssignaturen und wurden nicht an echten Geräten geprüft; ein nicht passendes Merkmal führt eher dazu, dass nichts erkannt wird. Eine KEV-Kopie wird mitgeliefert und nur aktualisiert, wenn product_check und updates.fetch_cve_map beide an sind, indem alle 24 Stunden eine öffentliche CISA-Feed-Datei abgerufen wird (nichts über Ihr LAN wird gesendet).

14. Bei Verlust, Diebstahl oder Außerbetriebnahme

Ein Sensor enthält die Liste der je Endpunkt gefundenen Schwachstellen, die Adressen der gekoppelten Endpunkte und seinen Signaturschlüssel. Die gekoppelten Endpunkte behandeln ihn außerdem als zugelassenen Scanner; ein gestohlener Sensor im selben LAN könnte sich also als solcher ausgeben. Das verhindert Folgendes.

14.1 Widerruf am Collector und Sperre

Nach roamswitch-sensor-collector revoke <öffentlicher Schlüssel> --reason TEXT werden die Uploads dieses Sensors mit 403 sensor_revoked abgelehnt (nur bei Anfragen mit gültiger Signatur, sodass nur der Besitzer des Schlüssels es erfährt). Ein widerrufener Sensor erfährt das beim nächsten Upload und hält sich selbst an (Sperre). Gesperrt antwortet die Steuer-API nur noch mit sensor_locked_down, und Kopplungen, Prüfungen (geplant und manuell), Uploads zum Collector, Benachrichtigungen und das Abtasten des Netzwerks hören auf. Die Sperre steht in einer Datei und übersteht daher einen Neustart; ist die Datei nicht lesbar, bleibt der Sensor gesperrt. Die Daten bleiben erhalten; mit roamswitch-sensor lockdown off (im TUI K) lässt sich die Sperre aufheben, sobald sicher ist, dass er wieder in vertrauenswürdigen Händen ist. Ist er am Collector noch widerrufen, sperrt er sich beim nächsten Upload erneut. revoke zeigt außerdem die Endpunkte, die mit diesem Sensor gekoppelt waren, und wie jeder von ihnen die Kopplung aufhebt.

14.2 Löschen, Außerbetriebnahme und Offline-Erkennung

Steht security.on_revoked auf wipe, überschreibt ein widerrufener Sensor Schlüssel, TLS-Schlüssel, Einstellungen (einschließlich Webhook-URLs), die Liste der gekoppelten Endpunkte, Prüfergebnisse und das Geräteinventar mit Nullen und löscht sie. Nur das Vorgangsprotokoll bleibt als Nachweis erhalten. lockdown (Standard) hält ihn an und behält die Daten, none meldet nur. Einen Sensor, den man in der Hand hat, nimmt man mit roamswitch-sensor decommission --confirm außer Betrieb (sperren und löschen; nicht umkehrbar). Wird security.lockdown_after_offline_days auf eine Zahl von Tagen gesetzt, hält sich ein Sensor selbst an, der den Collector so lange nicht erreicht hat, als Absicherung gegen einen gestohlenen Sensor in einem anderen Netz; das gilt nur, wenn der Collector-Upload aktiv ist und mindestens einmal gelang, Standard ist 0 (aus).

14.3 Was das nicht leisten kann

Die zuvor gekoppelten Endpunkte vertrauen dem Sensor weiter, bis jeder von ihnen die Kopplung aufhebt. Ein Sensor kann seine Endpunkte nicht benachrichtigen; führen Sie daher an jedem Endpunkt der von revoke und decommission ausgegebenen Liste unter Linux roamswitch sensor unpair <öffentlicher Schlüssel dieses Sensors> aus, am Mac Einstellungen > Sensor > Kopplung aufheben. Ein Sensor, der ausgeschaltet oder ohne Netzverbindung mitgenommen wird, erhält den Sperrbefehl nie; dort schützt nur Festplattenverschlüsselung (LUKS o. Ä.). Überschreiben garantiert auf Flash-Speicher oder Copy-on-Write-Dateisystemen keine vollständige Löschung.