Manuel d'exploitation RoamSwitch Sensor

Le guide d'installation et d'exploitation de RoamSwitch Sensor — un capteur réseau qui, une fois placé sur votre LAN, détecte les nouveaux appareils et l'usurpation sur le même segment, et exécute des audits actifs de vulnérabilités sur tout terminal déjà équipé de RoamSwitch (Mac / Linux Client / Server Edition). Distribué via des paquets apt/dnf.

1. Présentation & positionnement

RoamSwitch (Mac / Linux Client / Server Edition) est, dans tous les cas, un agent résidant sur l'hôte. Cette forme comporte deux angles morts structurels.

• L'auto-diagnostic d'un hôte isolé comporte un angle mort fondamental : le risque de mouvement latéral — « fermé vers l'extérieur, mais totalement exposé depuis un autre appareil du même LAN » — ne peut jamais être détecté par un hôte qui ne s'observe que lui-même.
• Certains appareils ne pourront jamais exécuter RoamSwitch : appareils IoT (caméras réseau, prises connectées, imprimantes multifonctions), appareils invités/BYOD, équipements réseau eux-mêmes, appareils embarqués, etc.

RoamSwitch Sensor est un nœud dédié que vous placez sur le LAN pour combler ces deux angles morts. Ce qui est aujourd’hui implémenté et vérifié comprend : des audits actifs de vulnérabilités des terminaux équipés de RoamSwitch sur le même LAN ; un registre des appareils du LAN construit à partir d’un balayage ARP et de la surveillance de la table ARP, avec détection des nouveaux appareils et de l’usurpation ; et des informations de référence sur les comportements suspects (connexions vers des IP malveillantes, signes de participation à un botnet, tunneling DNS, etc.) issues d’une capture passive activée sur option (voir §6). Sensor se contente de détecter et de signaler ; il ne bloque jamais le trafic. Il est conçu comme un NDR léger (Network Detection & Response) associé à un scanner de vulnérabilités interne fondé sur la preuve, et non comme un EDR.

L'autodéfense n'est délibérément pas implémentée (un choix de conception assumé). Si vous devez protéger l'hôte du Sensor lui-même contre les attaques, nous recommandons d'installer séparément RoamSwitch for Linux Server Edition sur la même machine. Les deux s'exécutent en tant que processus totalement indépendants et coexistent sans conflit.

2. Environnement de vérification actuel

• OS pris en charge : Debian 12 (bookworm) ou ultérieur / Ubuntu 22.04 ou ultérieur (apt), famille Fedora/RHEL (dnf). Uniquement x86_64 (amd64) — arm64 n'est pas encore pris en charge.
• Matériel cible (plan futur) : pour une exploitation réelle, nous envisageons un appareil basse consommation adapté au fonctionnement continu, comme un mini PC sans ventilateur de la gamme N100/N150, mais aucune construction ni livraison dédiée à cet effet n'est proposée aujourd'hui.
• Placement réseau : il doit être raccordé, physiquement ou logiquement, au segment de LAN que vous souhaitez surveiller (roamswitch-sensor.service s’exécute sur le réseau de l’hôte, car il doit observer directement la table ARP). Pour accepter les demandes d’appairage et d’audit des terminaux, il doit en outre fonctionner sur une adresse IP fixe (attribution statique ou réservation DHCP). Il écoute sur le port TCP 50543 (sur toutes les interfaces par défaut ; modifiez-le avec control.bind_addr ; TLS 1.3 est accepté sur le même port — voir §4.4).
• Consommation de ressources : quelques dizaines de Mo de mémoire résidente ; charge CPU au repos extrêmement faible.
• Recommandé : nmap (utilisé pour le balayage ARP, les vérifications complémentaires NSE et la vérification MAC des audits planifiés). Sans lui, les autres fonctions continuent de marcher, mais aucun balayage ARP n’est effectué et Sensor bascule en mode passif, où il ne voit que les appareils avec lesquels il a lui-même communiqué.

3. Installation & démarrage

Installez le paquet roamswitch-sensor depuis le dépôt officiel signé. Après l'installation, roamswitch-sensor.service (systemd) est automatiquement activé et démarré.

3.1 APT (Ubuntu / Debian)

# 1. Enregistrer la clé de signature du dépôt
curl -fsSL https://lafine.net/apt/roamswitch-archive-keyring.asc \
  | sudo gpg --dearmor -o /usr/share/keyrings/roamswitch-archive-keyring.gpg

# 2. Ajouter le dépôt
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. Installer
sudo apt update && sudo apt install roamswitch-sensor

3.2 DNF / RPM (Fedora / RHEL)

# 1. Importer la clé GPG
sudo rpm --import https://lafine.net/rpm/RPM-GPG-KEY-roamswitch

# 2. Ajouter le fichier de configuration du dépôt
sudo curl -fsSL -o /etc/yum.repos.d/roamswitch.repo https://lafine.net/rpm/fedora/roamswitch.repo

# 3. Installer
sudo dnf install roamswitch-sensor

3.3 Vérification du démarrage

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

3.4 Exécution du CLI / TUI

Le CLI (roamswitch-sensor) et le TUI interactif (roamswitch-sensor-tui) peuvent être exécutés directement après l'installation.

sudo roamswitch-sensor status
sudo roamswitch-sensor-tui

4. Appairage (méthode par code)

À sa sortie d'usine, Sensor ne fait confiance à rien. L'appairage se fait à l'aide d'un code d'appairage à usage unique émis par l'opérateur du Sensor. La relation de confiance — « Sensor est autorisé à exécuter des audits actifs de vulnérabilités contre ce terminal » — s'établit simultanément dans les deux sens en une seule étape d'appairage (il n'existe pas d'état de confiance à sens unique).

Prérequis : faites fonctionner Sensor avec une adresse IP fixe (attribution statique, ou réservation côté serveur DHCP). Une fois l'appairage effectué, le terminal se connecte désormais toujours directement à l'adresse IP de Sensor constatée lors de l'appairage (il n'y a plus de découverte automatique, via mDNS ou autre) ; si l'IP de Sensor change par la suite, un nouvel appairage sera nécessaire. Le terminal peut, lui, conserver une IP dynamique.

4.1 Émettre un code d'appairage (côté Sensor)

# À exécuter côté Sensor (ou appuyer sur c dans le TUI)
sudo roamswitch-sensor issue-code

Un code à usage unique de 8 caractères est émis (lettres majuscules et chiffres ; les caractères facilement confondus 0/O/1/I/L sont exclus). Il expire au bout de 10 minutes et ne fonctionne qu’une fois : transmettez-le donc rapidement à l’opérateur du terminal par un canal hors bande (de vive voix, par chat). L’empreinte du certificat TLS (SHA-256) de Sensor est également affichée. Le terminal épingle cette valeur : transmettez-la donc avec le code (vous pouvez toujours la consulter avec roamswitch-sensor pairing show ou sur l’écran T de la TUI).

4.2 Appairage avec le code (côté terminal)

# Côté terminal (roamswitch-linux)
sudo roamswitch sensor pair --addr <SENSOR_IP> --code <CODE> --fingerprint <SHA256_FINGERPRINT>

Sur l’édition Mac, vous pouvez faire de même dans l’interface graphique depuis l’élément de la barre des menus « 🔍 RoamSwitch Sensor Pairing… », en saisissant l’adresse IP du Sensor, le code d’appairage et l’empreinte du certificat.

Une fois l’appairage effectué, chaque audit actif et chaque récupération de résultats ultérieurs sont authentifiés par des signatures Ed25519. Un terminal Linux ne dialogue en TLS 1.3 qu’avec un Sensor dont le certificat correspond à l’empreinte que vous avez saisie, et ne retombe jamais automatiquement en clair (§4.4). À ce stade, le terminal qui connaissait le code et le Sensor qui l’a émis se font mutuellement confiance.

4.3 Appairage manuel (enregistrement direct d’une clé publique déjà connue)

Si l'opérateur du Sensor connaît déjà, par un autre canal, la clé publique et l'adresse d'un terminal, il peut aussi l'enregistrer directement côté Sensor sans échanger de code d'appairage (il est en principe préférable d'utiliser la méthode par code du §4.2 et de laisser le terminal s'appairer lui-même). Vous pouvez consulter votre propre clé publique et votre adresse avec les commandes suivantes.

# Vérifier sa propre clé publique/adresse côté terminal
sudo roamswitch sensor key

# Vérifier sa propre clé publique/adresse/adresse MAC côté Sensor
sudo roamswitch-sensor status

# Côté Sensor
sudo roamswitch-sensor pair <clé publique complète> --addr <adresse IP> --confirm

4.4 Sécurité de l’API de contrôle (TCP 50543) : TLS, empreinte, blocage

L’appairage, les demandes d’audit et la récupération des résultats passent par l’API de contrôle de Sensor (TCP 50543). Les protections suivantes sont intégrées.

• TLS 1.3 et épinglage du certificat : le réglage control.tls (appliqué au redémarrage du démon) vaut off (clair uniquement), optional (par défaut : TLS 1.3 et ancien mode en clair sur le même port, avec un avertissement à chaque connexion en clair acceptée) ou required (TLS 1.3 uniquement). Le certificat est auto-signé (ECDSA P-256) et la confiance est déterminée par l’épinglage de son empreinte SHA-256, et non par son expiration ni son nom. L’empreinte n’est jamais récupérée via le réseau : l’opérateur saisit sur le terminal la valeur affichée sur l’écran de Sensor.
• Liaison de l’empreinte à la demande d’appairage : le terminal signe l’empreinte qu’il a épinglée avec sa propre clé privée et l’inclut dans la demande d’appairage. Une demande passée par un homme du milieu présentant un autre certificat échoue avec fingerprint_mismatch, et le code d’appairage n’est pas consommé.
• Signatures résistantes au rejeu (v2) : les signatures des demandes d’audit et de récupération des résultats utilisent le format v2, qui inclut un horodatage (±300 s) et un nonce, de sorte que les rejeux sont refusés. Les anciennes signatures v1 n’ont ni l’un ni l’autre et peuvent être rejouées ; control.allow_legacy_signatures (true par défaut, prévu pour la période de migration ; chaque utilisation journalise un avertissement de dépréciation) détermine si elles sont acceptées. Réglez-le sur false dès que tous les terminaux envoient du v2.
• Blocage : la devinette de codes d’appairage bloque une IP source pendant 60 secondes après 5 échecs en 10 minutes (durée étendue exponentiellement en cas de récidive, jusqu’à 1 heure), et 20 échecs toutes sources confondues déclenchent un blocage global. Les échecs de signature sont traités un peu plus indulgemment (10 par IP source, 100 au total). Un blocage déclenche la notification control_api_lockout.
• Adresse d’écoute : restreindre control.bind_addr (0.0.0.0 par défaut, appliqué au redémarrage) à l’adresse LAN de Sensor réduit l’exposition. Le démon émet un avertissement tant qu’il s’agit d’une adresse générique.
• Rotation du certificat : roamswitch-sensor tls rotate (dans la TUI, écran T, touche R) régénère le certificat. Tous les épinglages de l’ancienne empreinte deviennent invalides : chaque terminal doit donc saisir la nouvelle valeur (sudo roamswitch sensor repin <public key> --fingerprint <value>). L’appairage lui-même est conservé.

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. Audit actif des vulnérabilités

Sensor exécute des diagnostics de vulnérabilité non destructifs et à preuve d'exploitation sur les terminaux appairés. Il n'effectue jamais d'opération destructive (écriture ou suppression de données, arrêt de services).

sudo roamswitch-sensor scan <clé publique ou son début>

L'audit se compose de quatre phases.

1. Analyse complète des ports : détecte de façon exhaustive tous les ports TCP ouverts sur l'hôte cible.
2. Diagnostic de signatures connues : vérifications non destructives et à preuve d'exploitation de schémas de vulnérabilité connus — exposition non authentifiée de Redis / dockerd / Memcached / MongoDB / Elasticsearch / CouchDB / Jenkins / VNC, diagnostic de relais ouvert SMTP (une méthode sûre qui n'envoie que MAIL FROM/RCPT TO, jamais DATA), et diagnostics de mauvaise configuration CORS, de traversée de répertoires et de redirection ouverte sur les serveurs de développement, entre autres.
3. Récupération générique de bannière : pour les ports ouverts non couverts par les signatures ci-dessus, récupère la chaîne de bannière par simple connexion (aucune donnée n'est envoyée).
4. Diagnostic complémentaire nmap NSE : diagnostic complémentaire à large couverture de protocoles via nmap --script safe. S'exécute automatiquement dès que nmap est installé sur l'hôte (sans effet dans le cas contraire).

Chaque exécution d'audit est enregistrée dans /var/lib/roamswitch-sensor/scan_history.json — que quelque chose ait été détecté ou non, car un résultat propre à ce moment-là a aussi une valeur d'archive — et peut être consultée via le CLI ou le TUI.

roamswitch-sensor history
sudo roamswitch-sensor report <clé publique ou son début> --out /tmp/report.md

5.1 Demande d’audit depuis le client (modèle pull)

Un terminal appairé peut aussi demander activement un audit à Sensor. Dans l’édition Mac, utilisez « Demander un audit au Sensor » dans la barre de menus ; sous Linux, utilisez la commande suivante.

sudo roamswitch sensor request-audit

Une fois l’audit exécuté par Sensor, le terminal interroge le résultat à partir de 5 minutes après la demande, puis toutes les 5 minutes, jusqu’à 5 tentatives (soit 25 minutes maximum au total). Tout résultat récupéré est également enregistré localement sur le terminal.

roamswitch sensor results

Dans l’édition Mac, les résultats apparaissent aussi dans la liste « Résultats d’audit » de la fenêtre de réglages, ou peuvent être lus via l’outil MCP get_sensor_audit_results, comme donnée d’entrée pour un agent IA élaborant un plan de remédiation. La récupération d’un résultat peut aussi être explicitement refusée, par exemple si l’appairage a été révoqué côté Sensor (voir §10 Q6).

6. Surveillance ARP passive & visibilité LAN

Sensor découvre les appareils du LAN de deux manières. (1) Surveillance de la table ARP : il lit sa propre table ARP (/proc/net/arp) environ toutes les 10 secondes et détecte « une nouvelle IP/MAC jamais vue » et « un changement d’adresse MAC pour une IP connue » (signe d’usurpation de la passerelle, etc.). (2) Un balayage ARP actif : nmap -sn -PR balaie le sous-réseau directement raccordé (jusqu’à un /22) et enregistre dans le registre des appareils l’IP, la MAC, le nom d’hôte, le constructeur, l’état en ligne, la première/dernière observation et l’historique des IP. Le balayage s’exécute toutes les heures, à la demande (refresh / touche r de la TUI) et au démarrage de la TUI ; sans nmap, seul le comportement passif (1) subsiste. Le constructeur et une classe d’appareil (IoT ou non, etc.) sont aussi déduits de l’OUI de la MAC.

roamswitch-sensor arp-events

Les événements détectés sont affichés par roamswitch-sensor arp-events et dans l’onglet « Événements ARP » de la TUI (Entrée pour les détails). Chaque événement comporte son horodatage, une gravité (de critique à info ; un changement de MAC de l’IP de la passerelle est « critique »), le raisonnement, l’identité des appareils concernés et des actions concrètes à mener.

6.1 Extension de la visibilité LAN passive (opt-in)

Alors que la surveillance ARP ci-dessus ne couvre que les appareils avec lesquels Sensor a lui-même communiqué, définir la variable d'environnement ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE sur une interface cible permet d'observer les en-têtes Ethernet/IPv4 sur celle-ci (sans inspection de la charge utile) pour détecter ce qui suit.

• Observation passive des nouveaux appareils : appareils avec lesquels Sensor n'a jamais communiqué directement, non couverts par la seule surveillance ARP. Appris à partir du trafic broadcast/multicast.
• Détection du contact avec des IP malveillantes connues : signale le trafic dont l'IP de destination correspond au flux de menaces local (même format que l'Egress Guard de RoamSwitch lui-même) — détection uniquement, jamais bloqué.

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 Registre des appareils et notes d’appareil

Consultez le registre avec roamswitch-sensor device-inventory (onglet « Réseau » de la TUI). Enregistrer une note (nom, usage, emplacement, etc.) avec device-note (touche n dans la TUI) marque l’appareil comme « identifié », tandis que les appareils sans note sont mis en évidence comme « à vérifier » (pour le rapprocher de votre inventaire des actifs).

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

6.3 Informations de référence sur les comportements suspects (détection uniquement)

Lorsque la capture passive (§6.1, activée sur option) est active, les informations de référence suivantes sont présentées. Il s’agit uniquement de détection et d’affichage ; Sensor ne bloque jamais le trafic.

• Comportement des appareils IoT (iot-events) : connexions d’appareils classifiés vers des IP malveillantes connues ou vers des ports d’administration (SSH/RDP/SMB, etc.). L’identification du modèle à partir des annonces mDNS/SSDP/DHCP des appareils eux-mêmes est également utilisée.
• Trafic suspect (network-threats) : connexions vers de nombreuses destinations dans une fenêtre de 30 secondes (signe de balayage ou de rebond), afflux de connexions vers une même destination (signe de participation à un DDoS) et signes de tunneling DNS/C2 (seules les caractéristiques structurelles des noms de requête sont utilisées ; les noms de domaine ne sont pas stockés).
• Avis de sécurité (iot-advisories) : informations de référence sur les CVE publiques concernant les produits de constructeurs IoT connus (intégrées statiquement ; aucune mise à jour via le réseau).

7. Référence des commandes CLI

Le CLI ne prend en charge que le japonais et l'anglais (il suit la variable d'environnement LANG).

8. Guide d'utilisation du TUI

La TUI interactive (roamswitch-sensor-tui) prend en charge 10 langues et permet d’utiliser chaque sous-commande de la CLI, chaque méthode IPC du démon, chaque clé de configuration et le collecteur (appuyez sur m pour le menu des fonctions). Six onglets principaux se changent avec la touche Tab (Maj+Tab pour revenir en arrière) : Appairés (le dernier état d’audit de chaque terminal) / Réseau (tous les appareils du LAN, avec leurs notes) / Événements ARP / Historique des analyses / Différences (changements depuis l’audit précédent ; nouvelles détections en rouge, résolues en vert, présumées inaccessibles en jaune) / Journal d’audit (qui a approuvé ou exécuté quoi, et quand ; le résultat de la vérification de la chaîne de hachage est affiché en haut). Les vues qui ne tiennent pas en 80 colonnes (surveillance passive, comportement IoT, trafic suspect, avis de sécurité IoT) s’ouvrent depuis le menu m.

9. Modèle de confiance & conception de sécurité

• Confirmation hors bande (pas de TOFU) : l’opérateur transmet au terminal l’empreinte du certificat affichée sur l’écran de Sensor et le code d’appairage, de vive voix, par chat ou équivalent. Le terminal ne récupère jamais l’empreinte via le réseau (ce n’est pas du TOFU, qui fait aveuglément confiance à la première connexion) et ne dialogue et n’établit un appairage qu’avec un Sensor dont le certificat correspond à la valeur saisie. Les clés publiques échangées lors de l’appairage vérifient ensuite chaque sonde et chaque requête.
• Conçu pour découvrir les failles qui permettraient une action destructive, sans jamais en exécuter une lui-même : chaque audit actif de vulnérabilités est non destructif (il n'écrit ni ne supprime jamais de données, et n'arrête jamais de service). Ce qui est détecté, ce sont les erreurs de configuration elles-mêmes — comme « inscriptible sans authentification » ou « fonctionne comme relais ouvert » — qui, si exploitées, permettraient une action destructive.
• Atténuation des faux positifs (exclusion de l'auto-audit) : une exclusion par correspondance d'IP source est intégrée afin que l'audit complet des ports effectué par un Sensor appairé lui-même ne soit pas confondu avec une reconnaissance par la garde de détection de scan de ports entrants (une fonction côté RoamSwitch). L'IP n'est utilisée que pour cette correspondance, uniquement pour éviter un blocage automatique — jamais pour la détermination de confiance elle-même. De plus, uniquement entre la demande d'audit de ce poste à un Sensor et l'arrivée du rapport (25 minutes au plus environ si aucun rapport n'arrive), l'édition Mac présente les détections issues de l'adresse du Sensor, ainsi que l'alerte « inondation de SYN » (sans adresse source), en termes plus calmes comme probablement causées par l'audit ; l'édition Linux le fait pour l'alerte « inondation de SYN ». En dehors de cette fenêtre, l'alerte forte reste inchangée, et les audits lancés par le Sensor de sa propre initiative ne sont pas couverts.
• Le trafic sortant est limité et aucune donnée d’appareil n’est envoyée par défaut : les informations sur les appareils découverts, les résultats d’audit et les événements ARP sont stockés uniquement dans le stockage local de Sensor par défaut et ne sont jamais envoyés à Lafine ni à un tiers. Le seul trafic sortant est la récupération des données de détection (la carte des CVE et la base de données NSE de nmap ; elle peut être arrêtée avec updates.fetch_cve_map et ne contient aucune donnée d’appareil ni d’audit), ainsi que les notifications (webhook, syslog) et les envois au collecteur central décrits au §11, qui ne vont que vers vos propres destinations et uniquement si vous les configurez.

10. Dépannage & FAQ

Q1. La saisie d'un code d'appairage est rejetée.

Il y a quatre causes probables : (1) le code a expiré 10 minutes après son émission (demandez à l’opérateur de Sensor d’en émettre un nouveau avec issue-code), (2) une faute de frappe dans le code (les caractères facilement confondus 0/O/1/I/L sont exclus lors de l’émission, un code n’en contient donc jamais), (3) l’adresse IP donnée à --addr ne correspond pas à l’adresse IP fixe actuelle de Sensor, (4) --fingerprint ne correspond pas au certificat de Sensor (pin_mismatch / fingerprint_mismatch ; vérifiez la valeur avec roamswitch-sensor pairing show. Des erreurs répétées entraînent un blocage et renvoient rate_limited).

Q2. Le résultat du diagnostic complémentaire NSE est vide.

L'une de ces deux causes : (1) nmap n'est pas installé dans le conteneur ; (2) l'exécution a eu lieu, mais les scripts sûrs applicables aux ports cibles n'ont réellement produit aucune sortie. Le diagnostic complémentaire nmap NSE s'exécute automatiquement dès que nmap est installé sur l'hôte.

Q3. Combien de temps prend un audit complet ?

Une simple analyse complète des ports prend environ quelques dizaines de secondes, mais dès que nmap est installé sur l'hôte, le diagnostic complémentaire NSE s'y ajoute automatiquement et peut prendre jusqu'à environ 2 minutes selon le nombre de ports ouverts de la cible. Le TUI affiche en continu les secondes écoulées pendant l'exécution, vous pouvez donc suivre la progression en attendant.

Q4. J'ai appairé, mais je n'arrive toujours pas à lancer d'audit.

Causes probables : (1) sensor_pairing_enabled: true n’est pas défini sur le terminal (désactivé par défaut), (2) l’adresse IP fixe de Sensor a changé après l’appairage et le terminal ne peut plus joindre l’ancienne adresse qu’il conserve (réappairez), (3) l’appairage a été supprimé sur Sensor avec unpair, (4) Sensor a régénéré son certificat (tls rotate), de sorte que l’empreinte épinglée par le terminal est périmée (saisissez la nouvelle empreinte avec roamswitch sensor repin). Vérifiez avec roamswitch sensor list (terminal) et roamswitch-sensor list (Sensor) que chaque côté répertorie l’autre.

Q5. Sensor peut-il être utilisé en parallèle de RoamSwitch lui-même (Client/Server Edition) ?

Oui. Sensor étant conçu sans fonction d'autodéfense, nous recommandons d'installer également RoamSwitch for Linux Server Edition sur la même machine. Les deux fonctionnent avec des processus et des stockages de données totalement indépendants, sans conflit.

Q6. roamswitch sensor results indique que l’appairage a été révoqué.

L’appairage de ce terminal a été supprimé côté Sensor avec unpair. Demandez à l’opérateur du Sensor d’émettre un nouveau code d’appairage, puis réappairez avec roamswitch sensor pair --addr <ip> --code <code> --fingerprint <SHA-256>.

11. Fonctions d'audit à l'échelle d'une organisation (optionnelles)

Un ensemble de fonctions pour les équipes de sécurité des grandes organisations qui ont besoin de preuves d'audit et d'une vue claire de ce qui a changé. Toutes sont désactivées par défaut, et rien n'est jamais envoyé à Lafine ni à un tiers : chaque destination de notification ou d'agrégation est choisie par votre organisation. Les réglages se modifient avec sudo roamswitch-sensor config set <clé> <valeur> (sans redémarrer le démon ; chaque modification est consignée dans le journal des opérations) ; config show affiche les valeurs actuelles.

11.1 Audits planifiés et détection des changements

En mettant schedule.enabled à true, tous les points d'accès appairés sont audités automatiquement (toutes les 24 heures par défaut : schedule.interval_hours ; plage horaire locale dans laquelle un audit peut démarrer : schedule.window_start_hour / window_end_hour, éventuellement à cheval sur minuit ; parallélisme : schedule.max_parallel). Chaque audit est comparé au précédent, et roamswitch-sensor diff affiche les nouvelles détections (régressions), les détections résolues et les ports nouvellement ouverts. Si tous les ports auparavant ouverts deviennent soudain invisibles, cela est signalé comme injoignable probable et non comme « résolu » : un hôte éteint ne se distingue pas, de l'extérieur, d'un hôte ayant fermé tous ses ports.

Les audits sans surveillance ne remettent pas en cause la garantie que seuls les points d'accès consentants sont audités. L'IP d'un point d'accès peut être attribuée à un autre appareil par le DHCP ; le Sensor conserve donc l'adresse MAC qu'avait le point d'accès lors de sa dernière authentification (appairage ou demande d'audit signée) et vérifie, avant et après chaque audit planifié, par une véritable requête ARP de nmap, que la même MAC répond toujours à cette IP. Sinon, l'audit est ignoré (ou son résultat écarté) et une notification est émise. Un scan manuel est lui aussi refusé s'il existe des indices que l'adresse appartient désormais à un autre appareil. Cette vérification exige nmap ; les points d'accès appairés avant cette fonction ne sont planifiés qu'après un nouvel appairage ou l'envoi d'une demande d'audit signée ; seuls les points d'accès du même segment L2 sont couverts.

11.2 Notifications (webhook et syslog)

Régressions, nouveaux appareils, usurpation ARP, trafic suspect, etc. sont envoyés à notify.webhook_urls (webhooks entrants de Slack, Discord ou Teams, ou tout point de réception JSON générique) et à notify.syslog.host / port / protocol (RFC 5424 sur UDP ou TCP). On peut restreindre avec notify.min_severity (info / medium / high / critical) et notify.cooldown_minutes (délai minimal avant de renvoyer le même événement). roamswitch-sensor notify-test vérifie chaque destination.

11.3 Export des preuves d'audit

roamswitch-sensor export <scans|inventory|audit-log|all> --format csv|json|html [--out FILE] [--endpoint KEY-PREFIX] [--since DATE]. La sortie html est un fichier unique : ouvrez-le dans un navigateur et choisissez « Enregistrer au format PDF » pour obtenir un PDF à remettre. Le CSV est protégé contre l’injection de formules de tableur. Le registre des appareils (inventory) comporte une colonne indiquant si chaque appareil est géré par RoamSwitch (appairé). Les fichiers de sortie ne sont lisibles que par leur propriétaire (0600), et l’export lui-même est consigné dans le journal d’audit. La touche e de la TUI propose les mêmes choix dans un formulaire, et les rapports et exports sont produits dans la langue d’affichage (10 langues ; la CLI est en japonais et en anglais).

11.4 Journal des opérations et des approbations (infalsifiable)

Appairage, désappairage, début et fin des audits, modifications de configuration et accès refusés sont enregistrés avec leur auteur (UID / clé publique du point d'accès / IP source). Chaque ligne contient le SHA-256 de la précédente ; toute modification ou suppression est donc détectée par roamswitch-sensor audit-log verify (code de sortie 2 en cas de problème). La liste s'obtient avec roamswitch-sensor audit-log [--limit N]. Les URL de webhook contiennent souvent un jeton ; le journal des changements de configuration n'en conserve donc jamais la valeur. Une chaîne de hachage seule ne révèle pas que les entrées les plus récentes ont été coupées ; la tête de chaîne (numéro de séquence et hachage) est donc aussi envoyée au collecteur (§11.6).

11.5 Conservation

Renseignez retention.scan_history_days, retention.audit_log_days et retention.inventory_stale_days pour supprimer automatiquement l'ancien historique d'audit, les anciennes entrées du journal et les appareils non vus depuis longtemps (0 = aucune suppression par ancienneté, valeur par défaut). Les appareils ayant une note ne sont jamais retirés de l'inventaire.

11.6 Agréger plusieurs Sensors (collecteur central, optionnel)

Lorsque plusieurs Sensors fonctionnent sur plusieurs sites, exécutez roamswitch-sensor-collector (fourni dans le paquet, désactivé par défaut) sur un hôte distinct pour collecter les synthèses signées de chacun.

# 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

• Seules les requêtes signées (Ed25519) des Sensors enregistrés (enroll) sont acceptées ; l'horodatage permet en outre de rejeter les rejeux.
• TLS est obligatoire dès que le service est joignable depuis l'extérieur du LAN. Placez --bind 0.0.0.0:8443 --tls-cert … --tls-key … dans COLLECTOR_ARGS de /etc/default/roamswitch-sensor-collector, ou utilisez --allow-plain-http derrière un reverse proxy qui termine TLS. Écouter sur autre chose que 127.0.0.1 sans TLS est refusé au démarrage.
• Le tableau de bord est protégé par un jeton et propose un filtrage par site, les événements par gravité et l'export CSV. Il met en évidence les Sensors devenus silencieux ainsi que ceux dont le journal d'audit semble tronqué, revenu en arrière ou bifurqué (à lever avec clear-anomaly <clé-publique> après enquête).
• Avec collector.send_unmanaged_devices (true par défaut), Sensor inclut dans la synthèse les appareils qui ne sont pas appairés (appareils non gérés). Chaque appareil est classé comme « hôte RoamSwitch non appairé » (lorsque RoamSwitch apparaît dans son auto-annonce mDNS/SSDP ; l’activation de collector.probe_control_port effectue en outre une tentative de connexion TCP vers le port de contrôle 50543, désactivée par défaut) ou « appareil inconnu », et seuls la MAC, le constructeur, la classe d’appareil et l’heure de première observation sont envoyés (jamais aucun contenu de trafic). Dans la TUI, O ouvre l’écran de gestion du collecteur.

11.7 Récupération des données de détection (updates.fetch_cve_map)

Sensor récupère chaque jour auprès du service de mise à jour la carte des CVE signée (les données de vulnérabilités connues utilisées par les vérifications actives) et la base de données NSE de nmap. Ce trafic ne transporte aucune donnée d’appareil ni d’audit. Pour fonctionner entièrement hors ligne, exécutez sudo roamswitch-sensor config set updates.fetch_cve_map false (le changement prend effet au cycle suivant sans redémarrage, et seules les données intégrées sont ensuite utilisées).

11.8 Référence des clés de configuration

Consultez les valeurs actuelles avec roamswitch-sensor config show et modifiez-les avec config set <key> <value> [<key> <value> …] (plusieurs clés sont enregistrées de façon atomique ; l’éditeur de configuration C de la TUI les modifie aussi). Seules les clés marquées « Oui » dans la colonne Redémarrage exigent un redémarrage du démon (sudo systemctl restart roamswitch-sensor).

12. Détection DHCP et IPv6 pirates

Cela détecte un autre routeur, ou la machine d'un attaquant, introduit dans le réseau et se faisant passer pour le légitime afin de détourner le trafic des clients. Il se limite à détecter et à notifier ; le Sensor ne bloque jamais le trafic. C'est activé par défaut et ne demande aucune capture passive. Les résultats apparaissent dans roamswitch-sensor network-threats, l'onglet Menaces de la TUI (depuis m), les notifications (dhcp_rogue_server, ipv6_rogue_router, ndp_spoof, ipv6_unknown_device), le journal des opérations et les exports.

12.1 Serveurs DHCP pirates (IPv4 et DHCPv6)

Chaque heure (et à chaque roamswitch-sensor refresh), le Sensor envoie un seul paquet DHCP discover (un SOLICIT pour DHCPv6) depuis une adresse MAC aléatoire et compte chaque serveur qui répond. Il n'envoie aucun REQUEST : aucun bail n'est pris. Les réponses DHCP vues par la capture passive passent par le même jugement. Le premier serveur entendu est appris comme légitime, et tout serveur apparu ensuite est signalé. Un serveur qui distribue une passerelle ou un DNS que le légitime ne distribue pas décide où va le trafic des clients qui acceptent son bail : c'est le niveau le plus grave, critical. Si plusieurs serveurs répondent en même temps dès la toute première sonde, le Sensor ne peut pas savoir lequel est authentique : il n'en apprend aucun et les signale tous.

12.2 IPv6 (annonces de routeur pirates, usurpation NDP, appareils IPv6 seuls)

Annonces de routeur pirates : n'importe qui sur le LAN peut se dire routeur IPv6. Le Sensor recoupe la table des voisins et les routes par défaut du noyau, les annonces de routeur vues par la capture passive et les réponses à sa propre sollicitation de routeur, et signale tout ce qui, autre que la passerelle IPv4 par défaut, se comporte en routeur (ajoutez le vrai dans ipv6.allowed_routers pour le tenir pour légitime ; un réseau dont le routeur IPv6 est un autre appareil que sa passerelle IPv4 est un cas normal, ajoutez-le alors). Les annonces dont la limite de sauts n'est pas 255 sont falsifiées ou routées et sont ignorées. Usurpation NDP : il signale une adresse IPv6 dont le détenteur change de MAC (high s'il s'agit d'une adresse de routeur). Appareils IPv6 seuls : un appareil absent d'ARP mais présent dans la table des voisins n'est signalé qu'après qu'un balayage ARP a eu l'occasion de le trouver. L'inventaire des appareils (colonne CSV ipv6, ipv6_addrs en JSON) liste aussi les adresses IPv6.

12.3 Qui est légitime, et les réglages

Avec dhcp.allowed_servers et ipv6.allowed_routers (MAC ou IP), tout le reste qui répond est signalé ; laissées vides, le premier trouvé est appris. dhcp.active_probe et ipv6.active_probe (par défaut true) coupent les sondes actives, et ipv6.enabled coupe toute la surveillance IPv6. L'écoute de l'API de contrôle (50543) en IPv6 s'ajoute avec control.listen_ipv6 (par défaut false, effectif au redémarrage) ; une adresse IPv6 globale peut être joignable depuis Internet si le routeur n'a pas de pare-feu IPv6, elle n'est donc pas activée par défaut. Les limites de connexion et les verrouillages comptent l'IPv6 par /64. Un terminal connecté depuis une adresse lien-local n'est pas retenu comme cible d'audit, car il ne peut pas être rappelé sans identifiant de portée.

13. Audit léger des appareils sans RoamSwitch (optionnel)

L'audit de vulnérabilités actif du §5 ne concerne que les terminaux appairés qui ont accepté. Pour les imprimantes, caméras, NAS et autres appareils jamais appairés dont on veut tout de même connaître les services exposés, il existe un contrôle distinct et bien plus limité. Les diagnostics profonds de type OpenVAS, les tentatives de connexion, l'exploitation de vulnérabilités, nmap NSE et les balayages de tous les ports ne sont faits que sur les terminaux qui ont accepté.

13.1 Ce qui est fait

Il ne fait qu'un test de connexion TCP vers 54 ports fixes (Telnet, FTP, RDP, VNC, SMB, Redis, MongoDB, API Docker, MQTT, RTSP, etc.), lit la bannière qu'un service envoie de lui-même sur les ports ouverts (plus un HEAD / sur les ports web) et ajoute une note quand le fabricant a publié des vulnérabilités (table des avis IoT). Un résultat dit « ce service est joignable depuis le LAN », jamais « ceci est vulnérable » ; chaque constat précise que l'activation de l'authentification n'a pas été testée.

13.2 L'activer

Pour activer unmanaged_audit.enabled, définissez d'abord unmanaged_audit.authorization (qui l'a approuvé : un nom, un numéro de ticket ou une référence de politique) et unmanaged_audit.allowed_cidrs (les plages auditables ; les plages IPv4 plus larges que /16 et IPv6 plus larges que /48 sont refusées). Les exécutions planifiées ont lieu toutes les interval_hours (168 par défaut) dans la fenêtre de schedule. Une exécution manuelle demande --confirm comme seconde approbation.

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 Garde-fous

Rien en dehors de allowed_cidrs, aucun appareil de unmanaged_audit.exclude (IP, plage ou MAC), aucun terminal appairé et pas le Sensor lui-même n'est jamais examiné. Avant et après une exécution, la MAC de l'appareil à cette adresse est confirmée par une requête en direct (ARP pour IPv4, ce qui demande nmap ; sollicitation de voisin pour IPv6) ; si elle a changé, l'exécution est interrompue ou le résultat écarté, avec notification. Le texte de authorization est inscrit au journal des opérations à chaque exécution et figure dans les exports (export unmanaged, JSON, rapport HTML), ce qui permet de montrer qui a approuvé l'audit.

13.4 Vérification du produit (a-t-il des vulnérabilités du KEV de la CISA ? Opt-in)

Activer unmanaged_audit.product_check (désactivé par défaut) fait lire par l'audit léger le nom du produit dans la page web qu'un appareil renvoie normalement, puis indique si ce produit a des vulnérabilités du catalogue KEV de la CISA. Seuls sont envoyés un GET / vers les ports web qui ont accepté la connexion (80, 8080, 8181, 443, 8443, 10443), les redirections que l'appareil indique lui-même vers la même adresse (au plus deux) et la lecture de l'émetteur et du sujet du certificat HTTPS. Aucune connexion, aucun essai de mot de passe, aucun chemin deviné et rien qui exploite une vulnérabilité n'est envoyé. La limite est de 12 requêtes par appareil, espacées de 150 ms. Les conditions de consentement (enabled, authorization, allowed_cidrs, exclude, exclusion des appareils appairés et revérification de l'adresse MAC) sont exactement celles des §13.2–13.3 ; si l'audit léger est désactivé, rien n'est envoyé même si product_check est activé.

Un produit n'est nommé que si tous ses repères à l'écran apparaissent dans la même réponse. Il est signalé comme concerné (high) seulement si la version affichée par l'appareil lui-même peut être lue et qu'une CVE a une plage NVD qui la contient. Si la version est illisible, il reste un avis (medium) : ce produit a des vulnérabilités listées dans le KEV, la version n'a pas pu être lue, donc le fait d'être concerné n'est pas confirmé. L'appareil n'est jamais déclaré vulnérable. Aujourd'hui, seul MikroTik RouterOS affiche sa version ; les autres produits reçoivent donc normalement l'avis « non confirmé ». Sont couverts Fortinet FortiGate, Ivanti Connect Secure, Citrix NetScaler, Cisco (le VPN SSL de l'ASA et l'interface web d'IOS XE), UniFi OS, GeoVision, TerraMaster, Check Point Security Gateway et MikroTik RouterOS ; les appareils Aruba n'ont pas d'entrée dans le KEV et ne sont pas couverts. Les repères reposent sur des signatures de détection publiques et n'ont pas été vérifiés sur de vrais appareils ; un repère qui ne correspond pas penche vers l'absence de détection. Une copie du KEV est fournie avec le produit et n'est mise à jour, uniquement si product_check et updates.fetch_cve_map sont tous deux activés, qu'en récupérant toutes les 24 heures un fichier de flux public de la CISA (rien sur votre LAN n'est envoyé).

14. En cas de perte, de vol ou de mise hors service

Un Sensor contient la liste des vulnérabilités trouvées sur chaque terminal, les adresses des terminaux appairés et sa clé de signature. Les terminaux appairés le traitent aussi comme un scanner autorisé ; un Sensor volé branché sur le même LAN pourrait donc se faire passer pour tel. Voici ce qui l'en empêche.

14.1 Révocation sur le collecteur et verrouillage

Après roamswitch-sensor-collector revoke <clé publique> --reason TEXTE, les envois de ce Sensor sont refusés avec 403 sensor_revoked (réponse donnée seulement aux requêtes à signature valide, donc seul le détenteur de la clé l'apprend). Un Sensor révoqué l'apprend à son prochain envoi et s'arrête de lui-même (verrouillage). Verrouillée, l'API de contrôle ne répond plus que sensor_locked_down, et l'appairage, les audits (planifiés et manuels), l'envoi au collecteur, les notifications et le sondage du réseau cessent. L'arrêt est consigné dans un fichier : il survit à un redémarrage, et si ce fichier est illisible, le Sensor reste verrouillé. Les données sont conservées ; roamswitch-sensor lockdown off (K dans la TUI) le déverrouille quand on est certain qu'il est revenu en de bonnes mains. S'il est encore révoqué sur le collecteur, il se reverrouille à son prochain envoi. revoke affiche aussi les terminaux qui lui étaient appairés et comment dissocier chacun.

14.2 Effacement, mise hors service et détection hors ligne

Avec security.on_revoked à wipe, un Sensor révoqué écrase de zéros puis supprime ses clés, sa clé TLS, ses réglages (URL de webhook comprises), la liste des terminaux appairés, les résultats d'audit et l'inventaire des appareils. Seul le journal des opérations est conservé, comme preuve. lockdown (par défaut) l'arrête et garde les données, none se limite à notifier. Pour mettre hors service un Sensor qu'on a en main, utilisez roamswitch-sensor decommission --confirm (verrouillage et effacement ; irréversible). Mettre security.lockdown_after_offline_days à un nombre de jours fait s'arrêter de lui-même un Sensor qui n'a pas joint le collecteur depuis ce temps, en protection d'un Sensor volé et utilisé sur un autre réseau ; cela ne joue que si l'envoi au collecteur est activé et a réussi au moins une fois, et la valeur par défaut est 0 (désactivé).

14.3 Ce que cela ne peut pas faire

Les terminaux qui étaient appairés au Sensor continuent de lui faire confiance tant que chacun n'a pas supprimé l'appairage. Un Sensor ne peut pas prévenir ses terminaux : sur chaque terminal de la liste qu'affichent revoke et decommission, exécutez roamswitch sensor unpair <clé publique de ce Sensor> sous Linux, ou Réglages > Sensor > Dissocier sous Mac. Un Sensor emporté éteint ou tenu hors du réseau ne reçoit jamais l'ordre de s'arrêter ; le chiffrement du disque (LUKS, etc.) est alors la vraie protection. L'écrasement ne garantit pas un effacement complet sur du stockage flash ou des systèmes de fichiers à copie sur écriture.