Edition macOS Linux Sensor

Ein dedizierter Sensor-Knoten fürs LAN: „RoamSwitch Sensor“

RoamSwitch Sensor ist ein dedizierter LAN-Knoten, der die RoamSwitch-Endpunkte im selben LAN (Mac / Linux Client / Server Edition) von außen prüft. Er stellt fest, wie ein Host für ein anderes Gerät im LAN aussieht (offene Ports, ohne Authentifizierung erreichbare Dienste, Ansatzpunkte für laterale Bewegung), was der Host durch Selbstdiagnose prinzipiell nicht sehen kann. Zusätzlich bietet er ein Geräteinventar des LANs und die Erkennung von ARP-Spoofing.

RoamSwitch Sensor: a dedicated LAN sensor node with ARP sweep and passive ARP monitoring, IoT risk classification, active vulnerability audit of paired RoamSwitch endpoints, and pairing-code (Ed25519, fixed IP) pairing

🛡️ Aktives Schwachstellen-Audit (nur gekoppelte Endpunkte)

Vollständiger Portscan → Prüfung bekannter Signaturen (unauthentifizierte Redis/dockerd/Memcached/MongoDB/Elasticsearch/CouchDB/Jenkins/VNC-Exposition, SMBv1 und fehlende SMB-Signierung, RDP ohne NLA, offenes SMTP-Relay usw.) → generisches Banner-Grabbing → ergänzender nmap-NSE-Scan — vier Phasen, komplett zerstörungsfrei.

📋 Netzwerkzusammensetzung erfassen (aktiver ARP-Sweep)

Findet die Geräte im LAN mit einem ARP-Sweep. Daraus entsteht ein Inventar mit IP, MAC, Hostname, Hersteller, Online-Status, Erst-/Letztsichtung und IP-Verlauf; pro Gerät lässt sich frei Name oder Zweck notieren. Geräte ohne Notiz werden als prüfungsbedürftig hervorgehoben, sodass die Liste auch zum Abgleich mit Ihrer Inventarliste dient. Ohne nmap fällt der Sensor auf einen passiven Modus zurück, der nur Geräte zeigt, mit denen er selbst kommuniziert hat.

👁️ ARP-Ereignisse mit „Nächste Schritte“

Neu auftauchende Geräte und MAC-Änderungen bei einer bekannten IP (Hinweis auf ARP-Spoofing) werden mit Zeitstempel, Schweregrad (kritisch bis Info), Begründung, Beteiligten und konkreten Prüfschritten angezeigt. Eine MAC-Änderung bei der Gateway-IP gilt als kritisch. Mit der optionalen passiven Erfassung erkennt der Sensor außerdem ein Gerät, das ARP-Anfragen für viele IPs sendet (interne Aufklärung).

🔎 Überblick über andere LAN-Geräte & verdächtiges Verhalten (nur Erkennung)

Zeigt als Referenzinformation: MAC-Hersteller und Gerätekategorie, Modellerkennung über mDNS/SSDP/DHCP-Selbstauskünfte, Verbindungen zu bekannten bösartigen IPs oder Admin-Ports, Anzeichen für Botnet-/DDoS-Beteiligung (viele Ziele) sowie für DNS-Tunneling/C2. Das meiste erfordert die optionale passive Erfassung (z. B. Mirror-Port); der Sensor blockiert nie Datenverkehr.

🔑 Kopplung per Pairing-Code (Ed25519, feste IP, Zertifikats-Pin)

Vertraut standardmäßig niemandem. Die Eingabe des 10 Minuten gültigen, einmaligen Pairing-Codes, den der Sensor-Betreiber ausgestellt hat, zusammen mit der festen IP-Adresse des Sensors und dem auf dem Sensor-Bildschirm angezeigten Zertifikats-Fingerprint, stellt in einem einzigen Schritt gegenseitiges Vertrauen in beide Richtungen her. Public Keys werden automatisch ausgetauscht, Sie müssen sie also nicht vorab kennen. Keine Cloud-Registrierung oder Konto nötig.

🔐 Härtung der Control-API (TLS 1.3, Zertifikats-Pin, Replay-Schutz)

Der Steuerungsverkehr mit Endpunkten (TCP 50543) wird über TLS 1.3 angenommen (control.tls: off / optional (Standard) / required). Das Zertifikat ist selbstsigniert; das Vertrauen beruht auf dem auf dem Sensor-Bildschirm angezeigten Fingerprint, den der Endpunkt pinnt – er wird nie über das Netzwerk abgerufen. Signaturen von Audit-Anfragen nutzen das v2-Format mit Zeitstempel und Nonce, sodass Wiedereinspielungen abgewiesen werden; das Erraten von Pairing-Codes und fehlgeschlagene Signaturen sperren die Quell-IP. Ob veraltete v1-Signaturen akzeptiert werden und auf welcher IP die API lauscht, ist ebenfalls konfigurierbar.

🖥️ Eine TUI in 10 Sprachen, die jede Funktion abdeckt

Die interaktive TUI erreicht jeden CLI-Unterbefehl, jede IPC-Methode des Daemons und jeden Konfigurationsschlüssel (Konfigurationseditor, TLS-Status und Zertifikatsrotation, manuelle Kopplung, Benachrichtigungstest), Collector-Operationen und jede Ereignisansicht (einschließlich passiver Überwachung, IoT-Verhalten, verdächtigem Datenverkehr und Advisories) in 10 Sprachen. Die CLI gibt es auf Japanisch und Englisch. Auch Audit-Berichte und Exporte lassen sich in 10 Sprachen erzeugen.

📅 Geplante Audits und Änderungserkennung (optional)

Prüft alle gekoppelten Endpunkte automatisch nach Zeitplan und zeigt, was sich seit dem vorherigen Audit geändert hat – neue Befunde, behobene und neu geöffnete Ports. Sind alle zuvor offenen Ports plötzlich nicht mehr sichtbar, gilt das als vermutlich nicht erreichbar, nicht als behoben. Auch unbeaufsichtigt bestätigt der Sensor vor und nach jedem Audit, dass die MAC-Adresse des Endpunkts noch die bei seiner Authentifizierung ist, und überspringt das Audit, wenn die IP an ein anderes Gerät gegangen ist. Standardmäßig aus; Intervall und Zeitfenster stellen Sie ein.

📣 Benachrichtigungen und Audit-Nachweise (optional)

Sendet Regressionen, neue Geräte, ARP-Spoofing und mehr an Webhooks (Slack, Discord, Teams und andere) und syslog (RFC 5424). Kopplung, Aufhebung der Kopplung, Audits und Konfigurationsänderungen werden mit dem Verursacher in einem manipulationssicheren Betriebsprotokoll (einer Hash-Kette) festgehalten; Audit-Ergebnisse, das Geräteinventar und das Protokoll lassen sich als CSV, JSON oder HTML-Bericht exportieren (im Browser als PDF speichern). Jedes Benachrichtigungsziel legen Sie selbst fest; standardmäßig werden weder Gerätedaten noch Audit-Ergebnisse irgendwohin gesendet. Erkennungsdaten (die CVE-Map und die nmap-NSE-Datenbank) werden täglich vom Update-Dienst abgerufen; mit updates.fetch_cve_map lässt sich das abschalten, und dieser Datenverkehr enthält weder Geräte- noch Audit-Daten.

🗂️ Mehrere Sensoren zusammenführen (zentraler Collector, optional)

Für Organisationen mit Sensoren an mehreren Standorten ist ein zentraler Collector enthalten, der signierte Zusammenfassungen sammelt (standardmäßig deaktiviert). Er bietet ein Dashboard je Standort und CSV-Export und erkennt, wenn das Audit-Protokoll eines Sensors abgeschnitten oder zurückgesetzt wurde. Geräte ohne RoamSwitch (nicht verwaltete Geräte) können in die Zusammenfassung aufgenommen werden, klassifiziert als „nicht gekoppelter RoamSwitch-Host“ oder „unbekanntes Gerät“ (collector.send_unmanaged_devices; niemals Inhalte des Datenverkehrs). Er akzeptiert nur signierte Anfragen von Sensoren, die Sie registriert haben, und weigert sich, ohne TLS über das LAN hinaus erreichbar zu sein.

🚨 Rogue-DHCP-Server und IPv6-Router erkennen (nur Erkennung)

Einmal pro Stunde sendet er von einer zufälligen MAC genau ein DHCP-Discover-Paket (bei IPv6 ein DHCPv6-Solicit) und zählt jeden antwortenden Server; es wird keine Adresse geleast. Gemeldet werden später hinzugekommene Server, Server mit einem Gateway oder DNS, das der legitime Server nicht verteilt, IPv6-Router-Advertisements von anderen Geräten als dem IPv4-Gateway, ein Besitzerwechsel einer IPv6-Adresse (NDP-Spoofing) und Geräte, die nur über IPv6 sichtbar sind. Das Geräteinventar führt jetzt auch IPv6-Adressen. Der Sensor blockiert nie Datenverkehr.

🔎 Leichte Prüfung von Geräten ohne RoamSwitch (optional, nur Verbindungstests)

Für nie gekoppelte Drucker, Kameras, NAS-Geräte usw. und nur innerhalb der vom Betreiber freigegebenen Bereiche werden feste Ports auf Verbindung geprüft und gelesen, was die Dienste von sich aus melden. Es wird kein Login versucht und keine Schwachstelle ausgenutzt; tiefe Scans im Stil von OpenVAS bleiben Endpunkten vorbehalten, die zugestimmt haben (gekoppelt). Aktivieren lässt sich das erst, wenn Freigabevermerk und erlaubte Bereiche gesetzt sind, und die Freigabe wird bei jedem Lauf ins Auditprotokoll geschrieben.

🔒 Widerruf und Sperre bei Verlust, Diebstahl oder Außerbetriebnahme

Wird ein Sensor am Collector widerrufen, hält er sich beim nächsten Upload selbst an: keine Kopplungen, Prüfungen, Uploads oder Benachrichtigungen mehr, und die Sperre übersteht einen Neustart. Optional löscht er Schlüssel und gespeicherte Daten, sperrt sich, wenn er den Collector zu lange nicht erreicht, oder wird per Befehl außer Betrieb genommen. Die Liste der zuvor gekoppelten Endpunkte samt Anleitung zum Aufheben der Kopplung wird ebenfalls angezeigt.

Falls der Sensor selbst gegen Angriffe gehärtet werden muss, empfehlen wir, RoamSwitch for Linux Server Edition separat auf derselben Maschine zu installieren — beide laufen als vollständig unabhängige Prozesse.

Beispiel eines Audit-Berichts

Beispiel für den Bericht, den roamswitch-sensor export all --format html (in der TUI die Taste e) erzeugt. Es ist eine einzelne HTML-Datei: im Browser öffnen und „Als PDF speichern“ wählen, um ein PDF für Prüfer zu erhalten.

Alle angezeigten Rechnernamen, MAC-Adressen, IP-Adressen und Schlüssel sind fiktiv. Der Berichtstext kann in jeder der 10 Sprachen erzeugt werden; hier werden ein japanisches und ein englisches Beispiel gezeigt.

Vollständigen Verifizierungsleitfaden ansehen →