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 mit dem Ziel, beide Lücken zu schließen. Tatsächlich implementiert und heute verifiziert sind nur zwei Dinge: aktive Schwachstellenprüfungen gegen RoamSwitch-Endpunkte im selben LAN und passive Erkennung neu erscheinender Geräte und von Spoofing, ausgehend von Sensors eigener ARP-Tabelle (wie in §6 erläutert, ist dies keine Funktion, die aktiv jedes Gerät im LAN scannt und sichtbar macht). Es ist nicht als EDR konzipiert, sondern als leichtgewichtiges NDR (Network Detection & Response) in Kombination mit einem selbst entwickelten, beweisbasierten Schwachstellenscanner.

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: muss physisch oder logisch mit dem zu überwachenden LAN-Segment verbunden sein (roamswitch-sensor.service läuft im Host-Netzwerk — erforderlich, um die ARP-Tabelle direkt zu beobachten). Außerdem muss der Sensor unter einer festen IP-Adresse (statische Zuweisung oder DHCP-Reservierung) laufen, damit Endpunkte ihn für Pairing und Audit-Anfragen erreichen können. Er lauscht auf TCP-Port 50543.
• Ressourcenverbrauch: residenter Speicher im Bereich weniger Dutzend MB; die CPU-Last im Leerlauf ist äußerst gering.
• Optional: nmap (wird für ergänzende NSE-Diagnosen verwendet; alle übrigen Funktionen arbeiten auch ohne Installation normal).

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, ohne die leicht zu verwechselnden Zeichen 0/O/1/I/L). Er läuft 10 Minuten nach Ausstellung ab und kann nur einmal eingelöst werden — geben Sie ihn dem Betreiber des Endpunkts daher umgehend über einen beliebigen Out-of-Band-Kanal (mündlich, Chat usw.) weiter.

4.2 Pairing mit dem Code (Endpunktseite)

# Endpunktseite (roamswitch-linux)
sudo roamswitch sensor pair --addr <feste IP-Adresse des Sensors> --code <Kopplungscode>

In der Mac-Edition steht dieselbe Aktion über die grafische Oberfläche unter „🔍 RoamSwitch Sensor Pairing…“ in der Menüleiste zur Verfügung, wo Sie die IP-Adresse und den Pairing-Code des Sensors eingeben.

Sobald das Pairing erfolgreich war, wird jede weitere aktive Schwachstellenprüfung und jeder Abruf von Prüfergebnissen mit einer Ed25519-Signatur authentifiziert. Sowohl der Endpunkt, der den Code kannte, als auch der Sensor, der ihn ausgestellt hat, vertrauen einander ab diesem Zeitpunkt.

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

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

Sensor erstellt regelmäßig eine Momentaufnahme seiner eigenen ARP-Tabelle (entspricht /proc/net/arp) und erkennt durch den Abgleich mit der vorherigen Momentaufnahme zwei Arten von Ereignissen: eine neue, noch nie gesehene IP/MAC-Adresse, und eine MAC-Adressänderung für eine bereits bekannte IP (ein Anzeichen z. B. für Gateway-Spoofing). Es werden niemals aktiv Pakete gesendet, und es werden nur Geräte erfasst, mit denen Sensor bereits auf irgendeine Weise kommuniziert hat (dies ist keine Funktion, die aktiv jedes Gerät im LAN erkennt und auflistet). Es gibt keine Möglichkeit, den Gerätetyp zu klassifizieren (z. B. ob es sich um ein IoT-Gerät handelt) — es wird lediglich eine IP/MAC-Änderung erkannt.

roamswitch-sensor arp-events

Erkannte Ereignisse lassen sich auch im TUI-Tab „ARP Events“ auflisten, wo zwischen zwei Arten unterschieden wird: „neues Gerät erschienen“ und „MAC-Adresse einer bekannten IP geändert (Spoofing-Verdacht)“.

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

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. Mit der Tab-Taste (Shift+Tab zurück) wechseln Sie zwischen sechs Reitern: Vertraut (letzter Audit-Stand jedes Endpunkts) / Geräte (alle Geräte im LAN, mit Notizen) / ARP-Ereignisse / Prüfverlauf / Änderungen (was sich seit dem vorherigen Audit geändert hat – neue Befunde rot, behobene grün, vermutlich nicht erreichbar gelb) / Protokoll (wer wann was freigegeben oder ausgeführt hat; oben steht das Ergebnis der Hash-Ketten-Prüfung).

9. Vertrauensmodell & Sicherheitsdesign

• TOFU (Trust On First Use): Der Pairing-Code selbst ist kein kryptografischer Eigentumsnachweis, sondern wird durch das eigene Urteil des Betreibers bestätigt, der den vom Sensor-Betreiber ausgestellten Code über einen Out-of-Band-Kanal (mündlich, Chat usw.) erhalten hat — ähnlich der expliziten gegenseitigen Bestätigung beim Bluetooth-Pairing. Ab dem Moment eines erfolgreichen Pairings wird die Legitimität jeder weiteren Probe oder Anfrage anhand des dabei ausgetauschten Public Keys überprüft.
• 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.
• Ohne Ihre Konfiguration wird nichts gesendet: Erkannte Geräteinformationen, Audit-Ergebnisse und ARP-Ereignisse werden standardmäßig nur im lokalen Speicher des Sensors abgelegt und niemals an Lafine oder Server Dritter gesendet. Die in §11 beschriebenen Benachrichtigungen (Webhook / syslog) und die Übermittlung an den zentralen Collector gehen nur an Ziele, die Ihre Organisation eingerichtet hat.

10. Fehlerbehebung & FAQ

F1. Die Eingabe eines Pairing-Codes wird abgelehnt.

Drei mögliche Ursachen: (1) seit der Ausstellung sind mehr als 10 Minuten vergangen und der Code ist abgelaufen — bitten Sie den Sensor-Betreiber, mit issue-code einen neuen auszustellen; (2) ein Tippfehler im Code (die leicht zu verwechselnden Zeichen 0/O/1/I/L werden bereits bei der Ausstellung ausgeschlossen, ein Code enthält sie also nie); (3) die mit --addr angegebene IP-Adresse stimmt nicht mit Sensors aktueller fester IP-Adresse überein.

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.

Mögliche Ursachen: (1) sensor_pairing_enabled: true ist auf der Endpunktseite nicht gesetzt (standardmäßig aus); (2) Sensors feste IP-Adresse hat sich nach dem Pairing geändert, sodass der Endpunkt eine veraltete Adresse anspricht (erneutes Pairing behebt dies); (3) das Pairing wurde auf der Sensor-Seite mit unpair entfernt. Prüfen Sie mit roamswitch sensor list (Endpunktseite) und roamswitch-sensor list (Sensor-Seite), dass beide Seiten die jeweils andere kennen.

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>.

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 Datei] [--endpoint Schlüsselpräfix] [--since Datum]. Die HTML-Ausgabe ist eine einzelne, in sich geschlossene Datei: im Browser öffnen und „Als PDF speichern“ wählen, um ein PDF für Prüfer zu erhalten. CSV ist gegen Formel-Injection in Tabellenkalkulationen geschützt. Der Export des Geräteinventars enthält eine Spalte, ob ein Gerät unter RoamSwitch-Verwaltung steht (gekoppelt). Ausgabedateien sind nur für den Eigentümer lesbar (0600), und der Export selbst wird im Betriebsprotokoll festgehalten.

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).