Manuale Operativo di RoamSwitch Sensor

La guida all'installazione e alla gestione di RoamSwitch Sensor, un sensore di rete che, una volta collocato nella LAN, rileva nuovi dispositivi e spoofing nello stesso segmento, ed esegue controlli attivi delle vulnerabilità su qualsiasi endpoint già dotato di RoamSwitch (Mac / Linux Client / Server Edition). Distribuito tramite pacchetti apt/dnf.

1. Panoramica e posizionamento

RoamSwitch (Mac / Linux Client / Server Edition) è, in ogni caso, un agente residente sull'host. Questa forma presenta due punti ciechi strutturali.

• L'autodiagnosi di un singolo host presenta un punto cieco fondamentale: il rischio di movimento laterale — "chiuso verso l'esterno, ma completamente esposto da un altro dispositivo sulla stessa LAN" — non può mai essere rilevato da un host che osserva solo se stesso.
• Alcuni dispositivi non potranno mai eseguire RoamSwitch: dispositivi IoT (telecamere di rete, prese intelligenti, stampanti multifunzione), dispositivi ospiti/BYOD, le stesse apparecchiature di rete, dispositivi embedded e altro ancora.

RoamSwitch Sensor è un nodo dedicato da collocare nella LAN per colmare queste due lacune. Ciò che oggi è implementato e verificato è: audit attivi delle vulnerabilità degli endpoint con RoamSwitch abilitato sulla stessa LAN; un inventario dei dispositivi della LAN costruito da una scansione ARP e dal monitoraggio della tabella ARP, con rilevamento di nuovi dispositivi e di spoofing; e informazioni di riferimento sui comportamenti sospetti (connessioni a IP malevoli, segni di partecipazione a botnet, tunneling DNS e altro) ottenute da una cattura passiva opt-in (vedere §6). Il Sensor rileva e segnala soltanto; non blocca mai il traffico. È progettato come un NDR (Network Detection & Response) leggero combinato con uno scanner di vulnerabilità proprietario basato su prove, non come un EDR.

L'autodifesa non è implementata intenzionalmente (una scelta progettuale deliberata). Se è necessario proteggere l'host del Sensor stesso dagli attacchi, si consiglia di installare separatamente RoamSwitch for Linux Server Edition sulla stessa macchina. I due funzionano come processi completamente indipendenti e coesistono senza conflitti.

2. Ambiente di verifica attuale

• SO supportato: Debian 12 (bookworm) o successivo / Ubuntu 22.04 o successivo (apt), famiglia Fedora/RHEL (dnf). Solo x86_64 (amd64) — arm64 non è ancora supportato.
• Hardware di destinazione (piano futuro): per l'uso reale prevediamo un dispositivo a basso consumo adatto al funzionamento continuo, come un mini PC senza ventola della serie N100/N150, ma oggi non viene fornita alcuna build o consegna dedicata a questo scopo.
• Posizionamento nella rete: deve essere collegato, fisicamente o logicamente, al segmento di LAN che si vuole monitorare (roamswitch-sensor.service viene eseguito nella rete dell’host perché deve osservare direttamente la tabella ARP). Per accettare richieste di abbinamento e di audit dagli endpoint deve inoltre operare con un indirizzo IP fisso (assegnazione statica o prenotazione DHCP). È in ascolto sulla porta TCP 50543 (su tutte le interfacce per impostazione predefinita; modificatela con control.bind_addr; TLS 1.3 è accettato sulla stessa porta, vedere §4.4).
• Consumo di risorse: memoria residente dell'ordine di decine di MB; il carico CPU a riposo è estremamente contenuto.
• Consigliato: nmap (usato per la scansione ARP, i controlli supplementari NSE e il controllo MAC degli audit pianificati). Senza di esso le altre funzioni continuano a operare, ma non viene eseguita alcuna scansione ARP e il Sensor ripiega su un funzionamento passivo che vede solo i dispositivi con cui ha comunicato direttamente.

3. Installazione e avvio

Installare il pacchetto roamswitch-sensor dal repository ufficiale firmato. Dopo l'installazione, roamswitch-sensor.service (systemd) viene abilitato e avviato automaticamente.

3.1 APT (Ubuntu / Debian)

# 1. Registrare la chiave di firma del repository
curl -fsSL https://lafine.net/apt/roamswitch-archive-keyring.asc \
  | sudo gpg --dearmor -o /usr/share/keyrings/roamswitch-archive-keyring.gpg

# 2. Aggiungere il repository
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. Installare
sudo apt update && sudo apt install roamswitch-sensor

3.2 DNF / RPM (Fedora / RHEL)

# 1. Importare la chiave GPG
sudo rpm --import https://lafine.net/rpm/RPM-GPG-KEY-roamswitch

# 2. Aggiungere il file di configurazione del repository
sudo curl -fsSL -o /etc/yum.repos.d/roamswitch.repo https://lafine.net/rpm/fedora/roamswitch.repo

# 3. Installare
sudo dnf install roamswitch-sensor

3.3 Verifica dell'avvio

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

3.4 Esecuzione di CLI / TUI

La CLI (roamswitch-sensor) e la TUI interattiva (roamswitch-sensor-tui) possono essere eseguite direttamente dopo l'installazione.

sudo roamswitch-sensor status
sudo roamswitch-sensor-tui

4. Abbinamento (metodo a codice)

Di fabbrica, Sensor non si fida di nulla. L'abbinamento avviene tramite un codice di abbinamento monouso rilasciato dall'operatore del Sensor. Il rapporto di fiducia — «Sensor può eseguire controlli attivi delle vulnerabilità su questo endpoint» — si stabilisce simultaneamente in entrambe le direzioni con un unico passaggio di abbinamento (non esiste uno stato di fiducia in una sola direzione).

Prerequisito: eseguire Sensor con un indirizzo IP fisso (assegnazione statica, o riserva lato server DHCP). Dopo l'abbinamento, l'endpoint si connette sempre direttamente all'indirizzo IP di Sensor confermato al momento dell'abbinamento (non esiste più alcuna scoperta automatica, né tramite mDNS né altrimenti); se l'IP di Sensor cambia in seguito, sarà necessario un nuovo abbinamento. Il lato endpoint può continuare a usare un IP dinamico.

4.1 Rilasciare un codice di abbinamento (lato Sensor)

# Eseguire sul lato Sensor (oppure premere c nella TUI)
sudo roamswitch-sensor issue-code

Viene rilasciato un codice monouso di 8 caratteri (lettere maiuscole e cifre; sono esclusi i caratteri facilmente confondibili 0/O/1/I/L). Scade dopo 10 minuti e funziona una sola volta, quindi comunicatelo tempestivamente all’operatore dell’endpoint con un qualsiasi canale fuori banda (a voce, in chat). Viene mostrata anche l’impronta digitale (SHA-256) del certificato TLS del Sensor. L’endpoint fissa (pin) quel valore, quindi comunicatelo insieme al codice (potete sempre vederlo con roamswitch-sensor pairing show o nella schermata T della TUI).

4.2 Abbinamento tramite codice (lato endpoint)

# Lato endpoint (roamswitch-linux)
sudo roamswitch sensor pair --addr <SENSOR_IP> --code <CODE> --fingerprint <SHA256_FINGERPRINT>

Nell’edizione per Mac potete fare lo stesso nella GUI dalla voce della barra dei menu «🔍 Abbinamento RoamSwitch Sensor…», inserendo l’indirizzo IP del Sensor, il codice di abbinamento e l’impronta digitale del certificato.

Una volta abbinati, ogni successivo audit attivo e recupero dei risultati è autenticato con firme Ed25519. Un endpoint Linux comunica su TLS 1.3 solo con un Sensor il cui certificato corrisponde all’impronta digitale inserita, e non ripiega mai automaticamente sul testo in chiaro (§4.4). A questo punto l’endpoint che conosceva il codice e il Sensor che lo ha rilasciato si considerano reciprocamente attendibili.

4.3 Associazione manuale (registrazione diretta di una chiave pubblica già nota)

Se l'operatore del Sensor conosce già, tramite un altro canale, la chiave pubblica e l'indirizzo di un endpoint, può anche registrarlo direttamente sul lato Sensor senza scambiare un codice di abbinamento (normalmente è preferibile usare il metodo a codice del §4.2 e lasciare che l'endpoint si abbini da solo). È possibile consultare la propria chiave pubblica e il proprio indirizzo con i seguenti comandi.

# Verificare la propria chiave pubblica/indirizzo sul lato endpoint
sudo roamswitch sensor key

# Verificare la propria chiave pubblica/indirizzo/indirizzo MAC sul lato Sensor
sudo roamswitch-sensor status

# Lato Sensor
sudo roamswitch-sensor pair <chiave pubblica completa> --addr <indirizzo IP> --confirm

4.4 Sicurezza dell’API di controllo (TCP 50543): TLS, impronta digitale, blocco

Abbinamento, richieste di audit e recupero dei risultati passano dall’API di controllo del Sensor (TCP 50543). Sono integrate le seguenti protezioni.

• TLS 1.3 e certificato fissato (pin): l’impostazione control.tls (applicata al riavvio del demone) può essere off (solo testo in chiaro), optional (il predefinito: TLS 1.3 e testo in chiaro legacy sulla stessa porta, con un avviso a ogni accettazione di testo in chiaro) o required (solo TLS 1.3). Il certificato è autofirmato (ECDSA P-256) e la fiducia è decisa da un pin della sua impronta SHA-256, non dalla scadenza né dal nome. Il pin non viene mai recuperato via rete: l’operatore digita nell’endpoint il valore mostrato sullo schermo del Sensor.
• Associazione dell’impronta digitale alla richiesta di abbinamento: l’endpoint firma con la propria chiave privata l’impronta che ha fissato e la include nella richiesta di abbinamento. Una richiesta passata attraverso un attacco man-in-the-middle con un certificato diverso fallisce con fingerprint_mismatch e il codice di abbinamento non viene consumato.
• Firme a prova di replay (v2): le firme delle richieste di audit e di recupero dei risultati usano il formato v2, che include un timestamp (±300 s) e un nonce, così i replay vengono respinti. Le firme v1 legacy non contengono né l’uno né l’altro e possono essere riprodotte; control.allow_legacy_signatures (predefinito true, pensato per il periodo di migrazione; ogni uso registra un avviso di deprecazione) decide se vengono accettate. Impostatelo su false quando ogni endpoint invia v2.
• Blocco: indovinare i codici di abbinamento blocca un IP di origine per 60 secondi dopo 5 fallimenti in 10 minuti (esteso in modo esponenziale se ripetuto, fino a 1 ora), e 20 fallimenti da tutte le origini attivano un blocco globale. I fallimenti di firma sono trattati con un po’ più di tolleranza (10 per IP di origine, 100 in totale). Un blocco genera la notifica control_api_lockout.
• Indirizzo di ascolto: restringere control.bind_addr (predefinito 0.0.0.0, applicato al riavvio) all’indirizzo LAN del Sensor riduce l’esposizione. Il demone avvisa finché l’indirizzo è un wildcard.
• Rotazione del certificato: roamswitch-sensor tls rotate (nella schermata T della TUI, premere R) rigenera il certificato. Tutti i pin della vecchia impronta diventano non validi, quindi ogni endpoint deve inserire il nuovo valore (sudo roamswitch sensor repin <public key> --fingerprint <value>). L’abbinamento in sé viene mantenuto.

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. Controllo attivo delle vulnerabilità

Sensor esegue diagnosi delle vulnerabilità non distruttive e basate su prove sugli endpoint associati. Non esegue mai operazioni distruttive (scrittura o cancellazione di dati, arresto di servizi).

sudo roamswitch-sensor scan <chiave pubblica o il suo inizio>

Il controllo si compone di quattro fasi.

1. Scansione completa delle porte: rileva in modo esaustivo tutte le porte TCP aperte sull'host di destinazione.
2. Diagnosi delle firme note: verifiche non distruttive e basate su prove contro pattern di vulnerabilità noti — esposizione non autenticata di Redis / dockerd / Memcached / MongoDB / Elasticsearch / CouchDB / Jenkins / VNC, diagnosi di open relay SMTP (un metodo sicuro che invia solo MAIL FROM/RCPT TO, mai DATA) e diagnosi di configurazione CORS errata, path traversal e open redirect su server di sviluppo, tra le altre.
3. Acquisizione generica del banner: per le porte aperte non coperte dalle firme sopra indicate, recupera la stringa del banner semplicemente connettendosi (non viene inviato alcun dato).
4. Diagnosi supplementare nmap NSE: diagnosi supplementare ad ampia copertura di protocolli tramite nmap --script safe. Viene eseguita automaticamente non appena nmap è installato sull'host (altrimenti non fa nulla).

Ogni esecuzione di controllo viene registrata in /var/lib/roamswitch-sensor/scan_history.json — indipendentemente dal fatto che sia stato rilevato qualcosa, poiché anche un risultato pulito in quel momento ha valore documentale — e può essere consultata da CLI o TUI.

roamswitch-sensor history
sudo roamswitch-sensor report <chiave pubblica o il suo inizio> --out /tmp/report.md

5.1 Richiesta di un controllo dal lato client (modello pull)

Un endpoint abbinato può anche richiedere attivamente un controllo a Sensor. Nell’edizione Mac, usare «Richiedi controllo al Sensor» nella barra dei menu; su Linux, usare il comando seguente.

sudo roamswitch sensor request-audit

Dopo che Sensor ha eseguito il controllo, l’endpoint interroga il risultato a partire da 5 minuti dopo la richiesta, poi ogni 5 minuti per un massimo di 5 tentativi (quindi fino a 25 minuti in totale). Il risultato ottenuto viene salvato anche localmente sull’endpoint.

roamswitch sensor results

Nell’edizione Mac, i risultati compaiono anche nell’elenco «Risultati dei controlli» della finestra delle impostazioni, oppure possono essere letti tramite lo strumento MCP get_sensor_audit_results, come input per un agente IA che pianifica una remediation. Il recupero di un risultato può anche essere esplicitamente rifiutato, ad esempio se l’abbinamento è stato revocato sul lato Sensor (vedere §10 D6).

6. Monitoraggio ARP passivo e visibilità della LAN

Il Sensor conosce i dispositivi della LAN in due modi. (1) Monitoraggio della tabella ARP: legge la propria tabella ARP (/proc/net/arp) circa ogni 10 secondi e rileva «un nuovo IP/MAC mai visto prima» e «un cambio di indirizzo MAC per un IP noto» (segno di spoofing del gateway e simili). (2) Una scansione ARP attiva: nmap -sn -PR scansiona la sottorete collegata direttamente (fino a una /22) e salva IP, MAC, nome host, produttore, stato online, prima/ultima rilevazione e cronologia degli IP nell’inventario dei dispositivi. La scansione viene eseguita ogni ora, su richiesta (refresh / il tasto r della TUI) e all’avvio della TUI; senza nmap resta solo il comportamento passivo (1). Il produttore e una classe di dispositivo (IoT o meno, ecc.) sono inoltre dedotti dall’OUI del MAC.

roamswitch-sensor arp-events

Gli eventi rilevati sono mostrati da roamswitch-sensor arp-events e nella scheda «Eventi ARP» della TUI (Invio per i dettagli). Ogni evento riporta l’ora, una gravità (da critica a informativa; un cambio di MAC dell’IP del gateway è «critica»), la motivazione, l’identità dei dispositivi coinvolti e i passi concreti successivi.

6.1 Estensione della visibilità passiva della LAN (opt-in)

Mentre il monitoraggio ARP sopra descritto copre solo i dispositivi con cui Sensor ha comunicato, impostando la variabile d'ambiente ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE su un'interfaccia di destinazione si osservano le intestazioni Ethernet/IPv4 su di essa (senza ispezione del payload) per rilevare quanto segue.

• Osservazione passiva di nuovi dispositivi: dispositivi con cui Sensor non ha mai comunicato direttamente, non coperti dal solo monitoraggio ARP. Appresi dal traffico broadcast/multicast.
• Rilevamento del contatto con IP dannosi noti: segnala il traffico la cui destinazione IP corrisponde al feed di minacce locale (stesso formato dell'Egress Guard di RoamSwitch stesso) — solo rilevamento, mai bloccato.

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 Inventario dei dispositivi e note sui dispositivi

Consultate l’inventario con roamswitch-sensor device-inventory (la scheda «Dispositivi» della TUI). Registrare una nota, ad esempio un nome, uno scopo o una posizione, con device-note (il tasto n nella TUI) contrassegna il dispositivo come «censito», mentre i dispositivi senza nota sono evidenziati come «da verificare» (per riconciliarli con il vostro registro degli asset).

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

6.3 Informazioni di riferimento sui comportamenti sospetti (solo rilevamento)

Con la cattura passiva (§6.1, opt-in) abilitata vengono presentate le seguenti informazioni di riferimento. Tutto è solo rilevamento e visualizzazione; il Sensor non blocca mai il traffico.

• Comportamento dei dispositivi IoT (iot-events): connessioni da dispositivi classificati verso IP malevoli noti o porte di gestione (SSH/RDP/SMB e simili). Viene usata anche l’identificazione del modello dagli annunci mDNS/SSDP/DHCP dei dispositivi stessi.
• Traffico sospetto (network-threats): connessioni verso molte destinazioni in una finestra di 30 secondi (segno di scansione o di stepping stone), un’ondata di connessioni verso una sola destinazione (segno di partecipazione a un DDoS) e segni di tunneling DNS/C2 (si usano solo le caratteristiche strutturali dei nomi di query; i nomi di dominio non vengono salvati).
• Advisory (iot-advisories): informazioni di riferimento sulle CVE pubbliche relative ai prodotti di produttori IoT noti (incluse staticamente; non c’è aggiornamento via rete).

7. Guida rapida ai comandi CLI

La CLI supporta solo giapponese e inglese (segue la variabile d'ambiente LANG).

8. Guida operativa della TUI

La TUI interattiva (roamswitch-sensor-tui) supporta 10 lingue e può gestire ogni sottocomando della CLI, ogni metodo IPC del demone, ogni chiave di configurazione e il collector (premere m per il menu delle funzioni). Con il tasto Tab (Shift+Tab per tornare indietro) si passa tra sei schede principali: Attendibile (ultimo stato di audit di ogni endpoint) / Dispositivi (tutti i dispositivi della LAN, con note) / Eventi ARP / Cronologia / Variazioni (cosa è cambiato dall’audit precedente: nuovi rilevamenti in rosso, risolti in verde, probabilmente irraggiungibile in giallo) / Registro (chi ha approvato o eseguito cosa e quando; in alto è mostrato l’esito della verifica della catena di hash). Le viste che non entrano in 80 colonne (monitoraggio passivo, comportamento IoT, traffico sospetto, advisory IoT) si aprono dal menu m.

9. Modello di fiducia e progettazione della sicurezza

• Conferma fuori banda (non TOFU): l’operatore comunica all’endpoint l’impronta digitale del certificato mostrata sullo schermo del Sensor e il codice di abbinamento, a voce, in chat o in modo simile. L’endpoint non recupera mai il pin via rete (non è TOFU, che si fida incondizionatamente della prima connessione) e comunica e si abbina solo con un Sensor il cui certificato corrisponde al valore inserito. Le chiavi pubbliche scambiate durante l’abbinamento verificano ogni successiva sonda e richiesta.
• Progettato per individuare falle che consentirebbero un'azione distruttiva, senza mai eseguirne una esso stesso: ogni controllo attivo delle vulnerabilità è non distruttivo (non scrive né cancella mai dati, né arresta servizi). Ciò che rileva sono le configurazioni errate stesse — come «scrivibile senza autenticazione» o «funziona come open relay» — che, se sfruttate, consentirebbero un'azione distruttiva.
• Mitigazione dei falsi positivi (esclusione dell'auto-controllo): è integrata un'esclusione basata sulla corrispondenza dell'IP di origine, in modo che il controllo completo delle porte eseguito da un Sensor associato non venga scambiato per un'attività di ricognizione dalla protezione di rilevamento delle scansioni delle porte in ingresso (una funzione lato RoamSwitch). L'IP viene usato solo per questa corrispondenza, unicamente per evitare un blocco automatico, mai per la determinazione della fiducia stessa. Inoltre, solo da quando questo endpoint richiede un audit a un Sensor fino all'arrivo del rapporto (circa 25 minuti al massimo se non ne arriva alcuno), l'edizione per Mac formula con toni più calmi i rilevamenti provenienti dall'indirizzo del Sensor e l'avviso di «flood di SYN» (privo di indirizzo di origine) come probabilmente causati dall'audit; l'edizione per Linux lo fa per l'avviso di «flood di SYN». Al di fuori di quella finestra l'avviso forte resta invariato, e gli audit avviati dal Sensor di propria iniziativa non sono coperti.
• Il traffico in uscita è limitato e per impostazione predefinita non vengono inviati dati dei dispositivi: le informazioni sui dispositivi scoperti, i risultati degli audit e gli eventi ARP sono salvati per impostazione predefinita solo nell’archiviazione locale del Sensor stesso e non vengono mai inviati a Lafine né a terzi. L’unico traffico in uscita è il recupero dei dati di rilevamento (la mappa CVE e il database NSE di nmap; può essere fermato con updates.fetch_cve_map e non contiene dati dei dispositivi né di audit) e le notifiche (webhook, syslog) e i caricamenti sul collector centrale del §11, che vanno solo alle vostre destinazioni e solo se le configurate.

10. Risoluzione dei problemi e FAQ

D1. L'inserimento di un codice di abbinamento viene rifiutato.

Le cause probabili sono quattro: (1) il codice è scaduto 10 minuti dopo il rilascio (chiedete all’operatore del Sensor di rilasciarne uno nuovo con issue-code), (2) un errore di battitura nel codice (i caratteri facilmente confondibili 0/O/1/I/L sono esclusi al rilascio dei codici, quindi un codice non li contiene mai), (3) l’indirizzo IP passato a --addr non corrisponde all’attuale indirizzo IP fisso del Sensor, (4) --fingerprint non corrisponde al certificato del Sensor (pin_mismatch / fingerprint_mismatch; controllate il valore con roamswitch-sensor pairing show. Errori ripetuti causano un blocco e viene restituito rate_limited).

D2. Il risultato della diagnosi supplementare NSE è vuoto.

Una di queste due cause: (1) nmap non è installato nel container; (2) è stato eseguito, ma gli script sicuri applicabili alle porte di destinazione non hanno effettivamente prodotto alcun output. La diagnosi supplementare nmap NSE viene eseguita automaticamente non appena nmap è installato sull'host.

D3. Quanto tempo richiede il completamento di un controllo?

Una semplice scansione completa delle porte richiede circa qualche decina di secondi, ma non appena nmap è installato sull'host, si aggiunge automaticamente la diagnosi supplementare NSE, che può richiedere fino a circa 2 minuti a seconda del numero di porte aperte del bersaglio. La TUI continua a mostrare i secondi trascorsi durante l'esecuzione, così è possibile seguire l'avanzamento mentre si attende.

D4. Ho associato, ma non riesco ancora a eseguire un controllo.

Cause probabili: (1) sensor_pairing_enabled: true non è impostato sull’endpoint (disattivato per impostazione predefinita), (2) l’indirizzo IP fisso del Sensor è cambiato dopo l’abbinamento e l’endpoint non riesce più a raggiungere il vecchio indirizzo che conserva (abbinate di nuovo), (3) l’abbinamento è stato rimosso sul Sensor con unpair, (4) il Sensor ha rigenerato il proprio certificato (tls rotate), quindi il pin dell’endpoint è obsoleto (inserite la nuova impronta digitale con roamswitch sensor repin). Verificate con roamswitch sensor list (endpoint) e roamswitch-sensor list (Sensor) che ciascun lato elenchi l’altro.

D5. Sensor può essere utilizzato insieme a RoamSwitch stesso (Client/Server Edition)?

Sì. Poiché Sensor è progettato senza funzioni di autodifesa, si consiglia di eseguire anche RoamSwitch for Linux Server Edition sulla stessa macchina. I due funzionano con processi e archivi dati completamente indipendenti, senza conflitti.

D6. roamswitch sensor results segnala che l’abbinamento è stato revocato.

L’abbinamento di questo endpoint è stato rimosso sul lato Sensor con unpair. Chiedere all’operatore del Sensor di rilasciare un nuovo codice di abbinamento, quindi riabbinare con roamswitch sensor pair --addr <ip> --code <code> --fingerprint <SHA-256>.

11. Funzioni di audit per le organizzazioni (opzionali)

Un insieme di funzioni per i team di sicurezza delle grandi organizzazioni che hanno bisogno di evidenze di audit e di un quadro chiaro di ciò che è cambiato. Tutte sono disattivate per impostazione predefinita e non viene mai inviato nulla a Lafine né a terzi: ogni destinazione di notifica o aggregazione è scelta dalla vostra organizzazione. Le impostazioni si modificano con sudo roamswitch-sensor config set <chiave> <valore> (senza riavviare il demone; ogni modifica viene registrata nel registro delle operazioni); config show mostra i valori correnti.

11.1 Audit pianificati e rilevamento delle variazioni

Impostando schedule.enabled su true, tutti gli endpoint abbinati vengono sottoposti ad audit automaticamente (ogni 24 ore per impostazione predefinita: schedule.interval_hours; fascia oraria locale in cui un audit può iniziare: schedule.window_start_hour / window_end_hour, anche a cavallo della mezzanotte; parallelismo: schedule.max_parallel). Ogni audit viene confrontato con il precedente e roamswitch-sensor diff mostra i nuovi rilevamenti (regressioni), quelli risolti e le porte appena aperte. Se tutte le porte prima aperte diventano improvvisamente invisibili, il caso è segnalato come probabilmente irraggiungibile, non come «risolto»: un host spento non si distingue dall'esterno da uno che ha chiuso tutte le porte.

Gli audit non presidiati non intaccano la garanzia che vengano sottoposti ad audit solo gli endpoint consenzienti. L'IP di un endpoint può essere assegnato a un altro dispositivo dal DHCP; il Sensor memorizza quindi il MAC che l'endpoint aveva all'ultima autenticazione (abbinamento o richiesta di audit firmata) e verifica, prima e dopo ogni audit pianificato, con una vera richiesta ARP di nmap che a quell'IP risponda ancora lo stesso MAC. In caso contrario l'audit viene saltato (o il suo risultato scartato) e viene inviata una notifica. Anche uno scan manuale viene rifiutato se vi sono indizi che l'indirizzo appartenga ormai a un altro dispositivo. Il controllo richiede nmap; gli endpoint abbinati prima di questa funzione non vengono pianificati finché non si riabbinano o inviano una richiesta di audit firmata; sono coperti solo gli endpoint dello stesso segmento L2.

11.2 Notifiche (webhook e syslog)

Regressioni, nuovi dispositivi, ARP spoofing, traffico sospetto e altro vengono inviati a notify.webhook_urls (webhook in ingresso di Slack, Discord o Teams, oppure qualsiasi endpoint JSON generico) e a notify.syslog.host / port / protocol (RFC 5424 su UDP o TCP). Si possono restringere con notify.min_severity (info / medium / high / critical) e notify.cooldown_minutes (intervallo minimo prima di reinviare lo stesso evento). roamswitch-sensor notify-test verifica ogni destinazione.

11.3 Esportazione delle evidenze di audit

roamswitch-sensor export <scans|inventory|audit-log|all> --format csv|json|html [--out FILE] [--endpoint KEY-PREFIX] [--since DATE]. L’output html è un unico file: apritelo in un browser e scegliete «Salva come PDF» per ottenere un PDF da consegnare. Il CSV è protetto dall’iniezione di formule nei fogli di calcolo. L’inventario dei dispositivi (inventory) ha una colonna che indica se ciascun dispositivo è gestito da RoamSwitch (abbinato). I file di output sono leggibili solo dal proprietario (0600), e l’esportazione stessa viene registrata nel registro di audit. Il tasto e della TUI offre le stesse scelte in un modulo, e report ed esportazioni sono prodotti nella lingua di visualizzazione (10 lingue; la CLI è in giapponese e inglese).

11.4 Registro di operazioni e approvazioni (a prova di manomissione)

Abbinamento, rimozione dell'abbinamento, avvio e completamento degli audit, modifiche di configurazione e accessi rifiutati vengono registrati insieme a chi li ha eseguiti (UID / chiave pubblica dell'endpoint / IP di origine). Ogni riga contiene lo SHA-256 della precedente, quindi qualsiasi modifica o cancellazione viene rilevata da roamswitch-sensor audit-log verify (codice di uscita 2 in caso di problemi). L'elenco si ottiene con roamswitch-sensor audit-log [--limit N]. Gli URL dei webhook contengono spesso un token, perciò il registro delle modifiche di configurazione non ne conserva mai i valori. Una catena di hash da sola non rivela che le voci più recenti siano state troncate; per questo la testa della catena (numero di sequenza e hash) viene inviata anche al collector (§11.6).

11.5 Conservazione

Impostate retention.scan_history_days, retention.audit_log_days e retention.inventory_stale_days per eliminare automaticamente la cronologia degli audit, le voci del registro e i dispositivi non visti da tempo (0 = nessuna eliminazione per età, valore predefinito). I dispositivi con una nota non vengono mai rimossi dall'inventario.

11.6 Aggregare più Sensor (collector centrale, opzionale)

Quando più Sensor operano in più sedi, eseguite roamswitch-sensor-collector (incluso nel pacchetto, disattivato per impostazione predefinita) su un host separato per raccogliere i riepiloghi firmati di ciascuno.

# 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

• Vengono accettate solo richieste firmate (Ed25519) dei Sensor registrati (enroll); il timestamp respinge inoltre i replay.
• TLS è obbligatorio ogni volta che il servizio è raggiungibile dall'esterno della LAN. Indicate --bind 0.0.0.0:8443 --tls-cert … --tls-key … in COLLECTOR_ARGS di /etc/default/roamswitch-sensor-collector, oppure usate --allow-plain-http dietro un reverse proxy che termina TLS. L'ascolto su un indirizzo diverso da 127.0.0.1 senza TLS viene rifiutato all'avvio.
• La dashboard è protetta da un token e offre filtro per sede, eventi per gravità ed esportazione CSV. Evidenzia i Sensor che non rispondono più e quelli il cui registro di audit sembra troncato, riportato indietro o biforcato (da rimuovere con clear-anomaly <chiave-pubblica> dopo l'indagine).
• Con collector.send_unmanaged_devices (predefinito true) il Sensor include nel riepilogo i dispositivi non abbinati (dispositivi non gestiti). Ogni dispositivo è classificato come «host RoamSwitch non abbinato» (quando RoamSwitch compare nel suo auto-annuncio mDNS/SSDP; abilitare collector.probe_control_port esegue anche un tentativo di connessione TCP alla porta di controllo 50543, disattivato per impostazione predefinita) o «dispositivo sconosciuto», e vengono inviati solo MAC, produttore, classe del dispositivo e ora della prima rilevazione (mai alcun contenuto del traffico). Nella TUI, O apre la schermata di gestione del collector.

11.7 Recupero dei dati di rilevamento (updates.fetch_cve_map)

Il Sensor scarica ogni giorno dal servizio di aggiornamento la mappa CVE firmata (i dati sulle vulnerabilità note usati dai controlli attivi) e il database NSE di nmap. Questo traffico non contiene dati dei dispositivi né di audit. Per operare completamente offline, eseguite sudo roamswitch-sensor config set updates.fetch_cve_map false (la modifica ha effetto dal ciclo successivo senza riavvio, e da quel momento si usano solo i dati inclusi).

11.8 Riferimento delle chiavi di configurazione

Verificate i valori correnti con roamswitch-sensor config show e modificateli con config set <key> <value> [<key> <value> …] (più chiavi vengono salvate in modo atomico; anche l’editor di configurazione C della TUI le modifica). Solo le chiavi contrassegnate con «Sì» nella colonna Riavvio richiedono il riavvio del demone (sudo systemctl restart roamswitch-sensor).

12. Rilevamento di DHCP e IPv6 non autorizzati

Individua un altro router, o la macchina di un attaccante, portato nella rete che si finge quello legittimo per dirottare il traffico dei client. Si limita a rilevare e notificare; il Sensor non blocca mai il traffico. È attivo per impostazione predefinita e non richiede la cattura passiva. I risultati compaiono in roamswitch-sensor network-threats, nella scheda Minacce della TUI (da m), nelle notifiche (dhcp_rogue_server, ipv6_rogue_router, ndp_spoof, ipv6_unknown_device), nel registro operazioni e nelle esportazioni.

12.1 Server DHCP non autorizzati (IPv4 e DHCPv6)

Ogni ora (e a ogni roamswitch-sensor refresh) il Sensor invia un solo pacchetto DHCP discover (un SOLICIT per DHCPv6) da un indirizzo MAC casuale e conta ogni server che risponde. Non invia alcun REQUEST, quindi non prende alcun lease. Le risposte DHCP viste dalla cattura passiva seguono lo stesso giudizio. Il primo server sentito viene appreso come legittimo e ogni server comparso dopo viene segnalato. Un server che distribuisce un gateway o un DNS che quello legittimo non distribuisce decide dove i client che accettano il suo lease inviano il traffico, ed è il livello più grave, critical. Se più server rispondono insieme alla primissima sonda, il Sensor non può sapere quale sia quello autentico: non ne apprende nessuno e li segnala tutti.

12.2 IPv6 (annunci di router non autorizzati, spoofing NDP, dispositivi solo IPv6)

Annunci di router non autorizzati: chiunque sulla LAN può dichiararsi router IPv6. Il Sensor incrocia la tabella dei vicini e le route predefinite del kernel, gli annunci di router visti dalla cattura passiva e le risposte alla propria richiesta di router, e segnala se qualcosa di diverso dal gateway IPv4 predefinito si comporta da router (aggiungi quello autentico a ipv6.allowed_routers per trattarlo come legittimo; una rete il cui router IPv6 è un dispositivo diverso dal gateway IPv4 è un caso normale, aggiungilo allora). Gli annunci con hop limit diverso da 255 sono falsificati o instradati e vengono ignorati. Spoofing NDP: segnala un indirizzo IPv6 il cui proprietario cambia MAC (high se è l'indirizzo di un router). Dispositivi solo IPv6: un dispositivo che non compare mai in ARP ma compare nella tabella dei vicini viene segnalato solo dopo che una scansione ARP ha avuto modo di trovarlo. L'inventario dei dispositivi (colonna CSV ipv6, ipv6_addrs in JSON) elenca anche gli indirizzi IPv6.

12.3 Chi è considerato legittimo e le impostazioni

Con dhcp.allowed_servers e ipv6.allowed_routers (MAC o IP), tutto il resto che risponde viene segnalato; se restano vuoti, si apprende il primo trovato. dhcp.active_probe e ipv6.active_probe (predefinito true) disattivano le sonde attive, e ipv6.enabled disattiva tutto il monitoraggio IPv6. L'ascolto dell'API di controllo (50543) su IPv6 si aggiunge con control.listen_ipv6 (predefinito false, applicato al riavvio); un indirizzo IPv6 globale può essere raggiungibile da Internet se il router non ha un firewall IPv6, quindi non è attivo per impostazione predefinita. I limiti di connessione e i blocchi contano l'IPv6 per /64. Un endpoint che si è connesso da un indirizzo link-local non viene ricordato come bersaglio di audit, perché non può essere richiamato senza un identificatore di ambito.

13. Audit leggero dei dispositivi senza RoamSwitch (opzionale)

L'audit attivo delle vulnerabilità del §5 riguarda solo gli endpoint abbinati che hanno accettato. Per stampanti, telecamere, NAS e altri dispositivi mai abbinati di cui si vogliono comunque conoscere i servizi esposti, esiste un controllo separato e molto più limitato. Le diagnosi profonde in stile OpenVAS, i tentativi di accesso, lo sfruttamento di vulnerabilità, nmap NSE e le scansioni dell'intero intervallo di porte vengono eseguiti solo sugli endpoint che hanno accettato.

13.1 Cosa fa

Fa soltanto una connessione TCP a 54 porte fisse (Telnet, FTP, RDP, VNC, SMB, Redis, MongoDB, API Docker, MQTT, RTSP, ecc.), legge il banner che un servizio invia da solo sulle porte aperte (più un HEAD / alle porte web) e aggiunge una nota quando il produttore ha pubblicato vulnerabilità (tabella degli avvisi IoT). Un risultato dice «a questo servizio si arriva dalla LAN», mai «questo è vulnerabile»; ogni rilevamento precisa che non è stato verificato se l'autenticazione è attiva.

13.2 Attivarlo

Per attivare unmanaged_audit.enabled, imposta prima unmanaged_audit.authorization (chi l'ha approvato: un nome, un numero di ticket o un riferimento di policy) e unmanaged_audit.allowed_cidrs (gli intervalli verificabili; gli intervalli IPv4 più ampi di /16 e IPv6 più ampi di /48 sono rifiutati). Le esecuzioni pianificate avvengono ogni interval_hours (168 per impostazione predefinita) entro la finestra di schedule. Un'esecuzione manuale richiede --confirm come secondo consenso.

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 Tutele

Nulla al di fuori di allowed_cidrs, nessun dispositivo in unmanaged_audit.exclude (IP, intervallo o MAC), nessun endpoint abbinato e nemmeno il Sensor stesso viene mai esaminato. Prima e dopo un'esecuzione, il MAC del dispositivo a quell'indirizzo viene confermato con una query in tempo reale (ARP per IPv4, che richiede nmap; richiesta di vicino per IPv6); se è cambiato, l'esecuzione viene interrotta o il risultato scartato e viene inviata una notifica. Il testo di authorization viene scritto nel registro operazioni a ogni esecuzione e compare nelle esportazioni (export unmanaged, JSON, report HTML), così si può mostrare chi ha approvato l'audit.

13.4 Verifica del prodotto (ha vulnerabilità del KEV della CISA? Opt-in)

Attivando unmanaged_audit.product_check (disattivato per impostazione predefinita), l'audit leggero legge il nome del prodotto dalla pagina web che un dispositivo restituisce normalmente e indica se quel prodotto ha vulnerabilità del catalogo KEV della CISA. Vengono inviati solo un GET / alle porte web che hanno accettato la connessione (80, 8080, 8181, 443, 8443, 10443), i reindirizzamenti che il dispositivo stesso indica verso lo stesso indirizzo (al massimo due) e la lettura di emittente e soggetto del certificato HTTPS. Non vengono inviati accessi, tentativi di password, percorsi indovinati né nulla che sfrutti una vulnerabilità. Il limite è di 12 richieste per dispositivo, a 150 ms l'una dall'altra. Le condizioni di consenso (enabled, authorization, allowed_cidrs, exclude, esclusione dei dispositivi associati e nuova verifica del MAC) sono esattamente quelle dei §13.2–13.3; se l'audit leggero è disattivato non viene inviato nulla, anche con product_check attivo.

Un prodotto viene indicato solo quando tutti i suoi segni sullo schermo compaiono nella stessa risposta. È segnalato come interessato (high) solo se si può leggere la versione mostrata dal dispositivo stesso e un CVE ha un intervallo NVD che la comprende. Se la versione non è leggibile, resta un avviso (medium): questo prodotto ha vulnerabilità elencate nel KEV, la versione non è stata letta, quindi non è confermato se sia interessato. Non si dice mai che il dispositivo sia vulnerabile. Oggi solo MikroTik RouterOS mostra la propria versione, perciò gli altri prodotti ricevono di norma l'avviso «non confermato». Sono coperti Fortinet FortiGate, Ivanti Connect Secure, Citrix NetScaler, Cisco (la VPN SSL di ASA e l'interfaccia web di IOS XE), UniFi OS, GeoVision, TerraMaster, Check Point Security Gateway e MikroTik RouterOS; i dispositivi Aruba non hanno voci nel KEV e non sono coperti. I segni si basano su firme di rilevamento pubbliche e non sono stati verificati su dispositivi reali; un segno che non corrisponde tende a non rilevare nulla. Una copia del KEV è inclusa nel prodotto e viene aggiornata, solo quando product_check e updates.fetch_cve_map sono entrambi attivi, scaricando ogni 24 ore un file del feed pubblico della CISA (non viene inviato nulla della tua LAN).

14. In caso di smarrimento, furto o dismissione

Un Sensor contiene l'elenco delle vulnerabilità trovate su ogni endpoint, gli indirizzi degli endpoint abbinati e la propria chiave di firma. Gli endpoint abbinati lo trattano anche come uno scanner autorizzato, quindi un Sensor rubato collegato alla stessa LAN potrebbe farsi passare per tale. Quanto segue lo impedisce.

14.1 Revoca sul collector e blocco

Dopo roamswitch-sensor-collector revoke <chiave pubblica> --reason TESTO, gli invii di quel Sensor vengono rifiutati con 403 sensor_revoked (dato solo alle richieste con firma valida, quindi lo apprende solo chi ha la chiave). Un Sensor revocato lo scopre al prossimo invio e si ferma da solo (blocco). Bloccata, l'API di controllo risponde solo sensor_locked_down, e si fermano abbinamenti, audit (pianificati e manuali), invii al collector, notifiche e sondaggio della rete. Il blocco è salvato in un file, quindi sopravvive a un riavvio, e se quel file non è leggibile il Sensor resta bloccato. I dati restano; con roamswitch-sensor lockdown off (K nella TUI) lo si sblocca quando si è certi che sia tornato in mani sicure. Se è ancora revocato sul collector, si blocca di nuovo al prossimo invio. revoke mostra anche gli endpoint che erano abbinati a quel Sensor e come rimuovere l'abbinamento su ciascuno.

14.2 Cancellazione, dismissione e rilevamento offline

Con security.on_revoked su wipe, un Sensor revocato sovrascrive con zeri e cancella chiavi, chiave TLS, impostazioni (inclusi gli URL dei webhook), elenco degli endpoint abbinati, risultati degli audit e inventario dei dispositivi. Resta solo il registro operazioni, come prova. lockdown (predefinito) lo ferma e conserva i dati, e none si limita a notificare. Per dismettere manualmente un Sensor che si ha in mano si usa roamswitch-sensor decommission --confirm (blocco e cancellazione; irreversibile). Impostando security.lockdown_after_offline_days a un numero di giorni, un Sensor che non ha raggiunto il collector per tutto quel tempo si ferma da solo, a tutela di uno rubato e usato su un'altra rete; vale solo se l'invio al collector è attivo ed è riuscito almeno una volta, e il valore predefinito è 0 (disattivato).

14.3 Cosa non può fare

Gli endpoint che erano abbinati al Sensor continuano a fidarsi di lui finché ciascuno non rimuove l'abbinamento. Un Sensor non ha modo di avvisare i suoi endpoint, quindi su ogni endpoint dell'elenco mostrato da revoke e decommission esegui roamswitch sensor unpair <chiave pubblica di questo Sensor> su Linux, oppure Impostazioni > Sensor > Rimuovi abbinamento su Mac. Un Sensor portato via spento o tenuto fuori dalla rete non riceve mai l'ordine di fermarsi; lì la vera protezione è la cifratura del disco (LUKS e simili). La sovrascrittura non garantisce una cancellazione completa su memoria flash o file system copy-on-write.