Édition macOS Linux Sensor

Un nœud capteur dédié pour votre réseau local : « RoamSwitch Sensor »

RoamSwitch Sensor est un nœud dédié au réseau local qui audite, de l'extérieur, les postes RoamSwitch du même réseau (Mac / Linux Client / Server Edition). Il vérifie comment un hôte apparaît depuis un autre appareil du réseau (ports ouverts, services exposés sans authentification, points d'appui pour un mouvement latéral), ce que l'hôte ne peut, par principe, pas voir par son propre autodiagnostic. Il fournit aussi un inventaire des appareils du réseau et la détection de l'usurpation ARP.

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

🛡️ Audit de vulnérabilités actif (points d'accès appairés uniquement)

Scan complet des ports → vérifications de signatures connues (exposition non authentifiée de Redis/dockerd/Memcached/MongoDB/Elasticsearch/CouchDB/Jenkins/VNC, SMBv1 et absence de signature SMB, RDP sans NLA, relais SMTP ouvert, etc.) → récupération générique de bannières → scan complémentaire nmap NSE — quatre phases, entièrement non destructives.

📋 Composition du réseau (balayage ARP actif)

Repère les appareils du LAN par un balayage ARP. Il constitue un inventaire : IP, MAC, nom d’hôte, fabricant, état en ligne, première/dernière détection et historique d’IP, avec une note libre (nom, usage) par appareil. Les appareils sans note sont signalés « à vérifier », ce qui permet un rapprochement avec votre inventaire. Sans nmap, le Sensor revient à un mode passif qui n’affiche que les appareils avec lesquels il a lui-même communiqué.

👁️ Événements ARP avec « Que faire ensuite »

L’apparition d’un nouvel appareil et le changement de MAC sur une IP connue (signe d’usurpation ARP) sont présentés avec l’horodatage, la gravité (critique à info), les raisons, les appareils concernés et des étapes de vérification concrètes. Un changement de MAC sur l’IP de la passerelle est jugé critique. Avec la capture passive facultative, il détecte aussi un appareil qui envoie des requêtes ARP pour de nombreuses IP (reconnaissance interne).

🔎 Vue d'ensemble des autres appareils du réseau & comportements suspects (détection seule)

Fournit à titre indicatif : fabricant MAC et catégorie d’appareil, identification du modèle via les auto-annonces mDNS/SSDP/DHCP, connexions vers des IP malveillantes connues ou des ports d’administration, signes de participation à un botnet/DDoS (nombreuses destinations) et de tunneling DNS/C2. L’essentiel nécessite la capture passive facultative (p. ex. port miroir) ; le Sensor ne bloque jamais le trafic.

🔑 Appairage par code (Ed25519, IP fixe)

Ne fait confiance à rien par défaut. Saisir le code d'appairage à usage unique, valable 10 minutes, émis par l'opérateur du Sensor, avec l'adresse IP fixe du Sensor, établit en une seule étape une confiance mutuelle dans les deux sens. Les clés publiques sont échangées automatiquement, inutile de les connaître à l'avance. Aucun compte ni inscription dans le cloud requis.

📅 Audits planifiés et détection des changements (optionnel)

Audite automatiquement, selon un calendrier, tous les points d'accès appairés et montre ce qui a changé depuis l'audit précédent : nouvelles détections, détections résolues et ports nouvellement ouverts. Si tous les ports auparavant ouverts deviennent soudain invisibles, cela est signalé comme injoignable probable, et non comme résolu. Même sans surveillance, le Sensor vérifie avant et après chaque audit que l'adresse MAC du point d'accès est toujours celle avec laquelle il s'est authentifié, et n'audite pas si l'IP est passée à un autre appareil. Désactivé par défaut ; vous réglez l'intervalle et la plage horaire.

📣 Notifications et preuves d'audit (optionnel)

Les régressions, nouveaux appareils, usurpations ARP, etc. peuvent être envoyés à des webhooks (Slack, Discord, Teams et autres) et à syslog (RFC 5424). Appairage, désappairage, audits et modifications de configuration sont consignés avec leur auteur dans un journal des opérations infalsifiable (chaîne de hachage), et les résultats d'audit, l'inventaire des appareils et le journal s'exportent en CSV, JSON ou rapport HTML (à enregistrer en PDF depuis un navigateur). Chaque destination est choisie par vous ; rien n'est envoyé par défaut.

🗂️ Agréger plusieurs Sensors (collecteur central, optionnel)

Pour les organisations qui déploient des Sensors sur plusieurs sites, un collecteur central qui rassemble des synthèses signées est inclus (désactivé par défaut). Il offre un tableau de bord par site et un export CSV, et détecte qu'un journal d'audit de Sensor a été tronqué ou ramené en arrière. Il n'accepte que les requêtes signées des Sensors enregistrés et refuse d'être exposé hors du LAN sans TLS.

Si le Sensor lui-même doit être protégé contre des attaques, nous recommandons d'installer séparément RoamSwitch for Linux Server Edition sur la même machine — les deux fonctionnent comme des processus totalement indépendants.

Exemple de rapport d'audit

Exemple du rapport produit par roamswitch-sensor export all --format html (touche e dans le TUI). C'est un fichier HTML unique : ouvrez-le dans un navigateur et choisissez « Enregistrer au format PDF » pour obtenir un PDF à remettre aux auditeurs.

Tous les noms de machines, adresses MAC, adresses IP et clés affichés sont fictifs. Le corps du rapport est produit en japonais ou en anglais (hors affichage japonais, la version anglaise est présentée).

Voir le guide de vérification complet →