RoamSwitch Icon RoamSwitch by Lafine Systems Design
É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, épinglage du certificat)

Aucune confiance par défaut. En saisissant le code d’appairage à usage unique, valable 10 minutes, émis par l’opérateur du Sensor, ainsi que l’adresse IP fixe du Sensor et l’empreinte du certificat affichée sur son écran, vous établissez 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 cloud ni enregistrement n’est requis.

🔐 Durcissement de l’API de contrôle (TLS 1.3, épinglage du certificat, protection contre le rejeu)

Le trafic de contrôle avec les terminaux (TCP 50543) est accepté en TLS 1.3 (control.tls : off / optional (par défaut) / required). Le certificat est auto-signé ; la confiance repose sur l’empreinte affichée sur l’écran du Sensor, que le terminal épingle — elle n’est jamais récupérée via le réseau. Les signatures des demandes d’audit utilisent le format v2 avec horodatage et nonce, de sorte que les rejeux sont refusés, et les tentatives de devinette du code d’appairage ainsi que les échecs de signature entraînent le blocage de l’IP source. L’acceptation des anciennes signatures v1 et l’IP sur laquelle l’API écoute sont également configurables.

🖥️ Une TUI en 10 langues couvrant toutes les fonctions

La TUI interactive donne accès à chaque sous-commande de la CLI, à chaque méthode IPC du démon et à chaque clé de configuration (éditeur de configuration, état TLS et rotation du certificat, appairage manuel, test de notification), aux opérations du collecteur et à toutes les vues d’événements (y compris la surveillance passive, le comportement des appareils IoT, le trafic suspect et les avis de sécurité), en 10 langues. La CLI est en japonais et en anglais. Les rapports d’audit et les exports peuvent aussi être produits en 10 langues.

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

Envoyez les régressions, les nouveaux appareils, l’usurpation ARP et plus encore vers des webhooks (Slack, Discord, Teams, etc.) et vers syslog (RFC 5424). L’appairage, la suppression d’appairage, les audits et les modifications de configuration sont consignés, avec l’identité de 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 peuvent être exportés en CSV, JSON ou en rapport HTML (à enregistrer en PDF depuis un navigateur). Chaque destination de notification est configurée par vous ; par défaut, aucune donnée d’appareil ni aucun résultat d’audit n’est envoyé nulle part. Les données de détection (la carte des CVE et la base de données NSE de nmap) sont récupérées chaque jour auprès du service de mise à jour ; vous pouvez désactiver cela avec updates.fetch_cve_map, et ce trafic ne contient aucune donnée d’appareil ni d’audit.

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

Pour les organisations disposant de Sensors sur plusieurs sites, un collecteur central qui rassemble des synthèses signées est inclus (désactivé par défaut). Il fournit 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. Les appareils sans RoamSwitch (appareils non gérés) peuvent être inclus dans la synthèse, classés comme « hôte RoamSwitch non appairé » ou « appareil inconnu » (collector.send_unmanaged_devices ; jamais aucun contenu de trafic). Il n’accepte que les requêtes signées provenant de Sensors que vous avez enrôlés, et refuse d’être exposé au-delà du LAN sans TLS.

🚨 Serveurs DHCP et routeurs IPv6 pirates (détection seule)

Une fois par heure, il envoie depuis une MAC aléatoire un seul paquet DHCP discover (DHCPv6 solicit pour IPv6) et compte chaque serveur qui répond ; aucun bail n'est pris. Il signale les serveurs apparus ensuite, ceux qui distribuent une passerelle ou un DNS que le serveur légitime ne distribue pas, les annonces de routeur IPv6 venant d'autre chose que la passerelle IPv4, un changement de détenteur d'adresse IPv6 (usurpation NDP) et les appareils visibles seulement en IPv6. L'inventaire des appareils contient aussi les adresses IPv6. Le Sensor ne bloque jamais le trafic.

🔎 Audit léger des appareils sans RoamSwitch (optionnel, tests de connexion seulement)

Pour les imprimantes, caméras, NAS et autres appareils jamais appairés, et uniquement dans les plages autorisées par l'opérateur, il teste la connexion à un ensemble fixe de ports et lit ce que les services annoncent eux-mêmes. Aucune connexion n'est tentée et aucune vulnérabilité n'est exploitée ; les analyses profondes de type OpenVAS sont réservées aux terminaux qui ont accepté (appairés). Il ne peut être activé qu'une fois l'enregistrement de l'approbateur et les plages autorisées définis, et l'autorisation est inscrite au journal d'audit à chaque exécution.

🔒 Révocation et verrouillage en cas de perte, de vol ou de mise hors service

Révoqué sur le collecteur, un Sensor s'arrête de lui-même à son prochain envoi : plus d'appairage, d'audit, d'envoi ni de notification, et l'arrêt survit à un redémarrage. Il peut aussi effacer ses clés et ses données, s'arrêter s'il ne joint plus le collecteur depuis trop longtemps, ou être mis hors service par une commande. La liste des terminaux qui lui étaient appairés, avec la façon de les dissocier, est également affichée.

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 peut être produit dans l’une des 10 langues ; un exemple en japonais et un exemple en anglais sont présentés ici.

Voir le guide de vérification complet →