Libro bianco sull'architettura e la sicurezza di RoamSwitch

§1

RoamSwitch è un'app della barra dei menu per Mac. A seconda di quanto ti fidi della rete che sei attualmente connesso, cambia automaticamente il firewall macOS, i servizi di condivisione, AirDrop, e DNS. Controlla anche lo spoofing ARP, le porte aperte verso l'esterno, l'archiviazione USB e attività di crittografia simile a un ransomware e quando rileva qualcosa di pericoloso arriverà fino al punto tagliare il traffico con il filtro dei pacchetti (pf) — un air-gap di emergenza.

In altre parole, RoamSwitch installa un demone con privilegi di root e, se lo volesse, potrebbe bloccare tutto traffico di rete sul Mac. È stato costruito da una sola persona e "per favore fidati di me" non è sufficiente giustificare quel privilegio. Quindi, invece, questo documento spiega il progetto in un formato che puoi verificare.

Per chi è questo

• Gli ingegneri decidono se installarlo
• Ricercatori e giornalisti di sicurezza che vogliono comprendere i dettagli prima di una recensione o di un articolo
• Il personale addetto alla sicurezza presso le aziende partner sta valutando un'implementazione interna o un raggruppamento OEM

Cosa non copre questo documento

Non riguarda l'ottimizzazione della soglia di rilevamento, le statistiche sui falsi positivi o le procedure dettagliate dell'interfaccia utente. Ciò che spiega sono quattro cose: privilegi, limiti del processo, flusso di dati e crittografia. Le specifiche delle funzionalità stesse si trovano nella risorsa MCP in bundle roamswitch://docs/features e nella guida in-app.

Cosa viene divulgato e in che misura (politica di divulgazione)

Questo documento è scritto partendo dal presupposto che un utente malintenzionato abbia già il file binario distribuito. Ogni URL, identificatore, percorso file, protocollo XPC e chiave pubblica incorporata dell'endpoint visualizzato qui può essere estratto dalla spedizione RoamSwitch.app in pochi minuti con strings, codesign -d o un proxy di traffico. Scriveteli qui dunque non dà nulla di nuovo all'attaccante. L'unica cosa che avanza è la comprensione del revisore.

D'altra parte, l'implementazione lato server che non può essere vista dal binario è un limite di velocità soglie, chiavi, endpoint di amministrazione, schema DB, layout del progetto Firebase non sono inclusi. Anche la progettazione dell'integrazione OEM e partner non rientra nell'ambito di questo contesto ed è trattata in un documento separato documento interno. "Cosa puoi imparare osservando il cliente" è la riga di divulgazione per questo documento.

§2

RoamSwitch.app è composto da tre eseguibili. Solo uno di essi è privilegiato; il gli altri due vengono eseguiti con diritti di utente di accesso. Tutti e tre vengono forniti con Hardened Runtime abilitato, ID sviluppatore firmato e autenticato.

Diritti e firma

• Tutti e tre gli obiettivi hanno ENABLE_HARDENED_RUNTIME = true.
• La sandbox dell'app è disabilitata (com.apple.security.app-sandbox = false). I diritti dell'helper e di MCPServer sono dizionari vuoti.
• Le build di distribuzione sono firmate dall'applicazione ID sviluppatore, autenticate da Apple e pinzate (§10).

§3

Come viene registrato

L'helper è registrato come LaunchDaemon utilizzando SMAppService.daemon(plistName:). Il plist incorporato nell'app (Contents/Library/LaunchDaemons/com.tetsuharu.RoamSwitch.Helper.plist) dichiara solo Label, BundleProgram, una singola voce MachServices e AssociatedBundleIdentifiers. A causa di come funziona SMAppService, la registrazione non è nemmeno possibile a meno che l'app non sia in /Applications. Sul primo registrazione, l'helper non diventa attivo finché l'utente non lo approva manualmente nel sistema Impostazioni.

Di quali connessioni accetta (ClientValidator)

L'aiutante controlla il processo di connessione in NSXPCListener shouldAcceptNewConnection e distribuisce HelperProtocol solo a quelli che passare. L'ispezione utilizza audit_token anziché il PID evitare il riutilizzo del PID e il TOCTOU.

# Requisiti di firma del codice richiesti dalla build Release ai client che si connettono
identifier "com.tetsuharu.RoamSwitch"
  and anchor apple generic
  and certificate leaf[subject.OU] = "GV76B6G4YU"

Questo requisito viene verificato con SecCodeCopyGuestWithAttributes e SecStaticCodeCheckValidity e la connessione viene interrotta se non passa. Solo Le build DEBUG rilasciano il pin ID squadra, per comodità di sviluppo. Ciò che effettivamente viene spedito è sempre a Rilascia la build.

Cosa può fare l'aiutante (l'elenco completo)

Le operazioni privilegiate definite in Shared/HelperProtocol.swift sono tutte. Non esiste alcuna API privilegiata che non sia elencata qui.

Stato all'interno dell'aiutante

• HelperTool.shared è una singola istanza condivisa tra connessioni. In passato si trattava di un'istanza separata per connessione, quindi un contenimento di emergenza che apriva una nuova connessione poteva colpire una gara che aveva perso traccia di "quali servizi ripristinare".
• Il servizio di condivisione e i backup DNS vengono modificati solo su una coda seriale (stateQueue).

Separazione dei privilegi nell’helper ed eccezione per la lettura del log SSH

Subito dopo l'avvio, l'helper si impone da solo un limite applicato dal kernel (un sandbox in esecuzione, distinto dall'entitlement App Sandbox citato sopra), che ereditano anche i processi figli che avvia. Questo limite impedisce di sostituire programmi di sistema, registrare un LaunchDaemon o un LaunchAgent, riscrivere la configurazione di sudoers, PAM o sshd, scrivere direttamente nell'archivio locale delle directory ed eseguire programmi che si trovano in posizioni in cui possono scrivere gli utenti, i volumi esterni o le cartelle temporanee. Non impedisce le modifiche agli account fatte tramite Open Directory (dscl) e non limita il traffico di rete (non è questo il suo scopo).

Sotto questo limite, /usr/bin/log non viene eseguito. Su macOS 26, log si rifiuta di funzionare dentro un sandbox (log: Cannot run while sandboxed) e anche come nobody (Must be admin). Quindi né l'app dell'utente connesso né l'helper root dentro il suo sandbox possono leggere il log di sshd (il log unificato). Il rilevamento della forza bruta SSH deve leggere quel log, perciò la separazione dei privilegi ha un'eccezione.

L'eccezione è un piccolo processo root: prima di entrare nel proprio sandbox, l'helper avvia lo stesso binario con --ssh-log-reader. Quel processo accetta solo un comando di un byte (avvio o arresto) e non fa altro che lanciare /usr/bin/log con argomenti fissi (log stream --style ndjson --level info e un filtro fisso che lascia passare solo le righe di sshd). Non passa variabili d'ambiente e chi chiama non ha modo di scegliere argomenti o un comando. Non legge né interpreta il log; l'output va in una pipe consegnata dall'helper.

Le righe del log contengono stringhe che un attaccante può scrivere, come il nome utente, quindi l'helper root non le interpreta. Passa ogni riga a un worker di analisi che gira come nobody in un sandbox che vieta l'accesso alla rete, la scrittura di file e l'avvio o la duplicazione di processi, e l'indirizzo di origine viene preso dalla fine della riga (IP port N), su cui il nome utente non può influire. Su un Mac con il login remoto disattivato, questo processo non avvia log e non legge nulla. Le operazioni SSH richiamabili tramite l'XPC dell'helper sono cinque: applicare le impostazioni, ottenere stato, record e accessi, e rimuovere un blocco. Nessuna accetta un comando.

§4

Quattro funzionalità toccano pf: l'air-gap di emergenza, la protezione della porta del server di sviluppo, il tunnel VPN Kill-switch WireGuard (§5, 1.7.6+) e il suo kill-switch Tailscale (§5, 1.8.0+ — solo il backend selezionato). Vanno sempre tutti attraverso un unico punto di ingresso, PFRulesetCoordinator, e non eseguire mai pfctl -f stessi.

Perché esiste un unico punto di ingresso

In precedenza, le due funzionalità caricavano ciascuna regole con pfctl -f in modo indipendente, competendo sull'unico set di regole principali di pf. Se la regola ristretta della guardia del porto fosse block ... port {…} caricato dopo block drop all dell'air-gap, potresti ritrovarti in uno stato in cui screen ha detto "isolato" ma il Mac era ancora raggiungibile. Questo bug è stato trovato attaccando effettivamente il file macchina da un altro host ed è stato corretto nella versione 1.4.3 (la storia è scritta in docs/marketing/zenn/03_lan_side_attack_test.md).

Come funziona adesso

• Ricostruito completamente ogni volta. L'intero set di regole richiesto viene ricostruito dallo stato corrente e applicato in un colpo solo. Non viene mai applicato come diff.
• Una coda seriale. Ogni modifica pf viene eseguita sullo stesso DispatchQueue, quindi, indipendentemente dal fatto che provenga da una connessione XPC, dall'avvio dell'helper o dal timer di failsafe, le modifiche vengono elaborate in ordine.
• L'ordine di priorità è il seguente (gli elementi più in alto hanno la precedenza).
  1. Air-gap di emergenza → set skip on lo0 e block drop all (nient'altro viene considerato)
  2. Kill-switch VPN → block drop all più pass quick solo per: lo, l'interfaccia tunnel (utunN), l'handshake UDP agli IP dell'endpoint bloccato, DHCP e ICMP
  3. Guardia del server di sviluppo → block drop in quick proto tcp ... port { … }
  4. Nessuno → ricarica /etc/pf.conf e riporta pf al suo stato originale
• Rileggi dopo l'applicazione. pfctl -sr rilegge le regole per confermare che block drop all, o la regola di ciascuna porta, è effettivamente caricata. Un caso in cui pfctl -f è stato silenziosamente ignorato non viene considerato un successo.
• Il file temporaneo viene scritto in un percorso contenente UUID ed eliminato una volta applicato (la versione 1.4.5 ha abbandonato il percorso fisso a favore di uno difficile da indovinare). La directory dello stato è /Library/Application Support/RoamSwitch.

§5

I tipi di blocco sono diversi

Come l'Air-Gap non si prolunga e non può essere aspettato

• Il modo in cui termina dipende da ciò che lo ha attivato (da 1.9.52). Un'esca antiransomware manomessa, un rilevamento XProtect confermato e un isolamento manuale scelto da un avviso ARP sono di «alta affidabilità»; ClickFix, le anomalie di porta e simili sono di «bassa affidabilità». Un isolamento a bassa affidabilità si rimuove comunque da solo al massimo dopo 10 minuti. Uno ad alta affidabilità non si rimuove a 10 minuti: una rimozione completa basata solo sul tempo permetterebbe a un attaccante di limitarsi ad aspettare.
• Un isolamento ad alta affidabilità resta completamente chiuso fino a un limite (1 ora per impostazione predefinita, da 5 minuti a 24 ore nelle impostazioni) e lì verifica la causa. Nel caso del ransomware considera la causa scomparsa solo se il processo sospetto è stato identificato ed è terminato e le esche non sono cambiate dal rilevamento. Se non è possibile confermarlo, passa alla «modalità ridotta»: le nuove connessioni restano bloccate (tranne loopback e DHCP) e viene ripristinata solo la radio Wi-Fi, così da poter vedere cosa accade. Non si apre mai per il solo trascorrere del tempo. Si apre solo se lo rimuovi tu o se la causa è confermata scomparsa.
• All'inizio di un isolamento vengono interrotte anche le connessioni in uscita già aperte. La tabella degli stati di pf viene svuotata (pfctl -F states), fermando il traffico iniziato prima dell'isolamento. Lo stesso avviene al passaggio alla modalità ridotta.
• Un isolamento causato da ARP spoofing viene rimosso automaticamente solo quando si conferma, senza alcun traffico, che la causa è scomparsa. Il controllo legge soltanto la cache ARP (non invia pacchetti) e considera la causa scomparsa quando il MAC attendibile del gateway viene visto in 3 controlli consecutivi che coprono almeno 60 secondi. Durante l'isolamento, però, la voce ARP del gateway può scomparire dalla tabella dei vicini (confermato su un Mac reale) e allora la causa non può essere confermata. In quel caso resta in modalità ridotta finché non lo rimuovi tu.
• Anche se l'helper si blocca, il controllo di rimozione non si ferma. Un LaunchDaemon dedicato senza alcun KeepAlive (AirGapFailsafe) si avvia da solo ogni 3 minuti e prende la stessa decisione dell'helper (bassa affidabilità: rimozione a 10 minuti; alta affidabilità: verifica della causa al limite, poi modalità ridotta). Se l'helper stesso si blocca e perde il proprio timer di rimozione, questa rete di sicurezza non ne risente (da 1.8.6; la decisione in base all'affidabilità da 1.9.52).
• Questo daemon dedicato non tocca mai la configurazione di avvio dell'helper interattivo stesso. Un tentativo precedente (1.8.5) usava il KeepAlive.PathState proprio dell'helper per questo ripristino, ma a volte interferiva con una normale chiusura dell'app causando un riavvio indesiderato, per cui è stato annullato a favore dell'attuale daemon completamente indipendente.
• Il controllo del timestamp utilizza una combinazione ibrida di tempo di attività monotono (ProcessInfo.systemUptime) e ora dell'orologio. Normalmente privilegia il tempo di attività monotono, così le correzioni NTP e i cambi manuali dell'ora non hanno effetto. Ricorre all'ora dell'orologio solo quando il tempo di attività non è affidabile — subito dopo un riavvio, rilevato quando il valore attuale è inferiore a quello memorizzato.
• Viene riapplicato dopo un riavvio o la ricreazione del demone. All'avvio l'helper legge lo stato dal disco con reapplyFromDisk() e ripristina da sé Air-Gap, protezione delle porte e impostazioni di sistema predefinite, in quest'ordine. Riprende anche lo stato dell'isolamento (affidabilità, completo o ridotto) e il tempo trascorso; il conteggio prosegue dalla prima attivazione (confermato su un Mac reale riavviando l'helper).
• Un sollevamento fallito viene trattato come un fallimento. Se block drop all non può essere effettivamente rimosso, il timestamp viene riscritto in modo che il timer di failsafe e il nuovo tentativo abbiano qualcosa su cui convergere. Lo schermo non mostra mai erroneamente "sollevato".
• Puoi riprendere il controllo in qualsiasi momento: con «Rimuovi isolamento Air-Gap» nella barra dei menu, con il pulsante di rimozione nella finestra modale, o semplicemente spegnendo il Wi-Fi. La rimozione non richiede Pro (funziona anche se Pro scade nel mezzo di un isolamento).

Come viene recuperato un falso positivo Port-Guard

Il blocco automatico delle porte sconosciute (Pro, attivo per impostazione predefinita una volta attivato Pro) può interrompere un traffico legittimo Ricevitore LAN: LocalSend, Syncthing, qualsiasi cosa avviata dopo l'attivazione della guardia. Quando quello accade, consentilo dal pulsante "Consenti" sul banner di notifica o sulla riga corrispondente la schermata "Porte esposte". Un eseguibile consentito una volta viene registrato come noto e non viene bloccato ancora (PortAnomalyGuard.allowPort(_:)). Tieni presente che gli interpreti di script generici (Python, Node.js, Netcat, ecc.) hanno un ambito rigorosamente path:port anziché binario da solo per prevenire gli attacchi di chi vive fuori terra. Demoni di sistema Apple che soddisfano anchor apple (rapportd, che sostiene Handoff e simili) non lo sono guardato in primo luogo.

Esca canary ransomware autoriparante e soppressione del contenimento

Se i file esca canary vengono manomessi o rinominati e attivano l'air-gap di emergenza, rilasciando il contenimento dopo aver verificato la sicurezza rigenera automaticamente i file Canary mancanti o danneggiati al loro hash di base autentico generato da modelli incorporati, ripristinando immediatamente la sorveglianza ininterrotta della coda (prevenendo la contaminazione della linea di base avversaria). Inoltre, durante il contenimento attivo (mentre è visualizzata la modalità di emergenza), gli avvisi di notifica ridondanti e gli eventi di riattivazione dal polling periodico dell'integrità in background vengono automaticamente soppressi per evitare di distrarre l'utente durante la risposta agli incidenti.

Rilevamento generico del ransomware basato sull'entropia — 1.10.0, Pro, attivo per impostazione predefinita

Monitora le cartelle Documenti, Scrivania, Download e Immagini tramite FSEvents e scatta quando scritture con entropia di Shannon superiore alla soglia (7,92) arrivano in un burst di 20 o più file entro 5 secondi. A differenza dell'approccio canary (file esca), non dipende dalla manomissione di un file esca, quindi rileva anche la cifratura in luoghi privi di file canary. Solo al raggiungimento della soglia usa lsof per identificare il processo e confrontarlo con una lista consentiti (cp, mv, ditto, tar, ffmpeg, Xcode, Time Machine, browser principali, ecc.). Alla rilevazione, attiva lo stesso blocco automatico della rete, tramite RansomwareContainmentManager, usato dalla guardia canary.

L'edizione Linux può tracciare i burst per processo perché fanotify associa un PID a ogni evento di scrittura. macOS non dispone né di fanotify né (per scelta) di EndpointSecurity, quindi questa implementazione legge solo il percorso tramite FSEvents e conta il burst globalmente, indipendentemente dal processo. Limite: quando più processi legittimi scrivono contemporaneamente grandi quantità di file ad alta entropia (ad esempio lavori di compressione o cifratura concorrenti), qui è più probabile un falso positivo rispetto all'edizione Linux.

Snapshot precedenti al danno per il recupero da ransomware (Mac)

Uno snapshot fatto al momento del rilevamento contiene già i file cifrati prima di esso, quindi non è una via di ritorno. RoamSwitch crea perciò snapshot locali APFS a intervalli regolari, indipendentemente dal rilevamento (ogni 6 ore per impostazione predefinita; disattivato, 1, 3, 6, 12 o 24 ore). Quando scatta un rilevamento, i nuovi snapshot precedenti al danno e la pulizia si fermano fino a 7 giorni (modalità di conservazione), così lo stato cifrato non scalza l'ultima generazione precedente alla cifratura. Il recupero è sempre manuale: solo i file scelti vengono copiati in ~/RoamSwitch-Recovered/. I file attuali non vengono mai sovrascritti e non è previsto il ripristino dell'intero volume. Per copiare occorre montare lo snapshot, quindi l'helper privilegiato richiede l'accesso completo al disco (gli snapshot vengono creati comunque senza). macOS può eliminare da solo gli snapshot locali, per esempio quando lo spazio libero scarseggia, e non c'è garanzia che durino oltre circa 24 ore. La finestra di recupero è una funzione Pro (la creazione degli snapshot funziona anche senza Pro).

Pacchetto di prove forensi — 1.10.0

Quando inizia un Air-Gap di emergenza — attivato dalla guardia canary, dalla guardia ransomware basata sull'entropia o simili — una coda in background che non blocca il contenimento stesso salva un'istantanea dell'elenco processi (ps), delle connessioni di rete (lsof -i), dei file modificati negli ultimi cinque minuti e dei file aperti dal processo sospetto, in ~/Library/Application Support/RoamSwitch/incident-evidence/<timestamp>/manifest.json. Il manifest registra lo SHA-256 di ogni artefatto, così da poter rilevare manomissioni successive. L'elenco dei pacchetti è disponibile tramite lo strumento MCP get_forensic_evidence_bundles. Limite: essendo costruito senza un entitlement EndpointSecurity, non acquisisce tracce di pacchetti né istantanee di memoria/descrittori di file del processo.

Registrazione delle esecuzioni dei processi (Mac, Pro, disattivata per impostazione predefinita)

L'helper privilegiato avvia come processo figlio il /usr/bin/eslogger incluso in macOS (exec, fork, exit) e registra gli avvii dei processi solo su questo Mac. Non richiede l'entitlement EndpointSecurity (non chiama mai es_new_client) e RoamSwitch deve essere consentito in Accesso completo al disco (Impostazioni di Sistema; se non è in elenco, aggiungi /Applications/RoamSwitch.app con «+»). Finché manca il permesso, mostra lo stato «non disponibile», attende e ricontrolla ogni 60 secondi (non passa a un polling oneroso). Si limita a notificare. Non blocca l'esecuzione né la comunicazione e non isola.

Notifica questi dieci comportamenti: un browser, un'app Office o di posta che avvia direttamente una shell; l'esecuzione di un binario non firmato da una cartella temporanea o da una posizione in quarantena; un comando su una riga che scarica e reindirizza a una shell (combinato con un URL a IP grezzo, base64, eval o verifica TLS disattivata); osascript che usa base64 o eval; l'esecuzione di un file subito dopo la rimozione del suo attributo di quarantena; l'avvio di un binario non firmato da una registrazione di avvio automatico appena scritta (LaunchAgent o LaunchDaemon); un processo genitore non firmato da Apple che legge un segreto del portachiavi (come security find-generic-password -w); una riga singola python3, perl, ruby, php o pwsh con -c/-e/-Command in cui una decodifica base64/eval e una chiamata a curl, wget, exec o system compaiono entrambe sulla stessa riga (da 1.10.0 — il solo uso di base64 o eval non attiva questo rilevamento); e l'avvio di un processo con la variabile d'ambiente DYLD_INSERT_LIBRARIES impostata (da 1.10.0 — per evitare fughe di segreti, viene letto solo il valore di questa unica variabile; i processi firmati da Apple sono esclusi); e una riga di comando che indica direttamente un file di credenziali esca collocato da RoamSwitch (come ~/.aws/credentials o ~/.env.backup, riconosciuto dal marcatore al suo interno), ad esempio cat, tar o curl -F; i file reali non corrispondono mai e le letture tramite una libreria restano alla sorveglianza degli honeytoken. Ogni rilevamento porta un ID tecnica MITRE ATT&CK.

Solo i rilevamenti di gravità alta diventano banner, e quelli dello stesso tipo sono raggruppati in uno ogni 10 minuti (ogni evento resta nel registro). Gli strumenti di sviluppo come Claude Code e la CLI di GitHub che leggono le proprie credenziali non vengono notificati per impostazione predefinita. Se le legge un altro programma, l'azione «Consenti questo programma» della notifica consente solo quella voce (per Team ID se è firmato, altrimenti per nome dell'eseguibile, abbinato al nome della voce).

Il registro è salvato leggibile solo da root (cartella 0700, file 0600) e conserva per impostazione predefinita 200 MB e 14 giorni. Le variabili d'ambiente non vengono salvate, ma gli argomenti della riga di comando possono contenere segreti. Ogni segmento è sigillato in una catena di hash collegata all'hash del segmento precedente, e «Verifica catena» rileva modifiche, segmenti mancanti e sigilli rimossi (ciascuno confermato su un Mac reale). Questo rileva la manomissione, non la impedisce. L'eliminazione o il ripristino del segmento più recente non è rilevabile. La lettura passa per l'XPC dell'helper, e MCP passa per l'app (con nuova verifica di Pro).

Limiti: le esecuzioni prima dell'avvio dell'helper o prima dell'attivazione della registrazione non vengono registrate. eslogger osserva a posteriori e non può bloccare. Con carichi come migliaia di avvii di processo al secondo, alcuni eventi vanno persi (il conteggio è mostrato a schermo e il funzionamento continua). Questa registrazione non sostituisce un EDR (rilevamento e risposta sugli endpoint).

Honeytoken delle credenziali — 1.10.0, Pro, attivi per impostazione predefinita

Colloca un file di credenziali esca, contrassegnato con un valore sentinella, in ciascuna di queste tre posizioni: ~/.aws/credentials, ~/.ssh/id_rsa_backup e ~/.docker/config.json. Non sovrascrive mai un file reale già presente in quel percorso. Il rilevamento degli accessi combina lo stesso meccanismo kqueue (DispatchSource.makeFileSystemObjectSource) usato dalla guardia canary con un polling della data di accesso ogni 30 secondi, poiché senza EndpointSecurity un evento open() non può essere intercettato in modo affidabile. Il rilevamento si limita a notificare; non blocca nulla né attiva l'isolamento. L'esca ssh usa un nome che ssh non cerca per impostazione predefinita (non id_rsa), quindi una normale esecuzione di ssh non viene interrotta né segnalata per errore. L'esca AWS usa un nome di profilo distinto invece di [default], quella Docker punta a un registro interno inesistente e tutte vengono create con modalità 0600 (dalla 1.10.3). Oltre a questi tre, vengono collocate esche anche in ~/.pypirc e ~/.env.backup (per le ricerche di token PyPI, file .env e chiavi API di IA). Non si usa ~/.npmrc perché npm lo legge a ogni esecuzione, né le credenziali GCP perché un file falso comprometterebbe l'autenticazione reale. Quando un'esca viene davvero consultata, viene collocata in più esattamente un'esca correlata (~/.aws/config, ~/.ssh/config o ~/.kube/config), sorvegliata a sua volta; la catena si ferma dopo un passo e nessun file esistente viene sovrascritto.

Monitoraggio dell'accesso alle credenziali del browser — 1.10.0, opt-in anche in Pro, disattivato per impostazione predefinita

Monitora, tramite FSEvents, le scritture nei database di password/cookie salvati di Chrome, Brave, Edge, Vivaldi, Chromium e Firefox. In caso di burst, lsof identifica il processo; qualsiasi cosa diversa dal browser stesso, da un indicizzatore come Spotlight o da un demone di backup conta come rilevamento. A differenza delle altre nuove guardie, l'attivazione di Pro non la attiva automaticamente — un'estensione del browser o la funzione di importazione di un gestore di password possono attivarla, per cui il rischio di falsi positivi è intrinsecamente abbastanza alto da renderla opt-in di serie.

Comunicazione con il Sensor (TLS e firme)

L'abbinamento, le richieste di audit e il recupero dei risultati con un RoamSwitch Sensor (un prodotto separato) nella stessa LAN usano TLS 1.3 con l'impronta del certificato (SHA-256) fissata (Sensor 0.3.9 e successivi). L'impronta non viene ottenuta via rete; l'utente digita il valore mostrato sullo schermo del Sensor. Autorità di certificazione, nome host e scadenza non vengono verificati, ci si fida solo del valore fissato. Se TLS fallisce, non si ripiega sul testo in chiaro (il ripiego permetterebbe a un man in the middle di degradare la connessione). Le firme delle richieste includono marca temporale e nonce (v2) per impedire il replay. Solo un vecchio abbinamento senza impronta si connette ancora in chiaro come prima, con un avviso.

Se il certificato cambia, la connessione viene rifiutata. L'aggiornamento dell'impronta fissata non è mai automatico: viene salvato solo quando l'utente digita e conferma il nuovo valore e una sonda firmata riesce davvero via TLS. Limite: questa sonda non verifica con una chiave che il Sensor sia lo stesso abbinato in precedenza. Presuppone che l'utente digiti il valore che ha confermato sullo schermo del Sensor.

Rilevamento multilivello dei download (firme statiche + ClamAV) — livello di firme statiche aggiunto nella 1.8.7

I file appena inseriti nelle cartelle Download, Scrivania o Documenti passano prima per un leggero controllo di firme statiche tramite StaticSignatureScanner (solo i primi 4 MB, semplice corrispondenza di pattern di byte AND/OR, senza espressioni regolari né calcoli di entropia). Non richiede l'entitlement EndpointSecurity e continua a funzionare anche dove ClamAV non è installato. Il rilevamento è deliberatamente limitato a ciò che può essere affermato come un fatto senza un corpus reale di malware: la firma di test EICAR, standard del settore, e cinque reverse shell da manuale documentate in riferimenti pubblici di offensive security (ad esempio PayloadsAllTheThings) — /dev/tcp/ di bash/sh, -e di netcat, pty.spawn di Python, Socket di Perl e fsockopen di PHP. Non scriviamo «firme» a livello di byte per famiglie di malware specifiche senza disporre di un campione reale da cui estrarle: sarebbe solo un falso senso di sicurezza. I pattern stessi sono memorizzati offuscati con XOR 0x5A, in modo che il binario di RoamSwitch non contenga mai letteralmente una stringa EICAR o una reverse shell per cui ClamAV stesso potrebbe segnalarlo.

Solo i file che il livello di firme statiche giudica «puliti» passano poi alla scansione ClamAV. I file appena inseriti nelle cartelle Download, Scrivania o Documenti vengono scansionati immediatamente da ClamAV, indipendentemente da un'estensione .tmp o da un attributo com.apple.quarantine (ad esempio una copia fatta da Terminale). EICAR e altre firme di test standard del settore sono considerate innocue: non viene mostrata alcuna notifica, ma solo registrata una voce nella cronologia delle notifiche, e non vengono mai messe in quarantena o bloccate (solo i campioni di malware autentici vengono messi in quarantena). E se un file con lo stesso nome era già stato messo in quarantena in precedenza, la nuova minaccia viene comunque spostata nella cartella di quarantena con un nome univoco e con timestamp, così una minaccia non può mai restare nella sua posizione originale a causa di una collisione di nomi.

Rilevamento di web shell nelle cartelle web di sviluppo (Web Rules)

I file dello sviluppo web locale (~/Sites, MAMP, Herd, Local, /Library/WebServer/Documents e le cartelle di progetto registrate per il confronto delle CVE dei pacchetti) vengono controllati con le stesse 18 regole di rilevamento dell'edizione Linux: PHP, JavaScript, JSP e ASP. Le regole descrivono solo tecniche documentate pubblicamente e non contengono alcuna firma ricavata da un campione reale. I livelli sono tre: integrate nell'app, un aggiornamento firmato in sola ricezione una volta al giorno (incluso nel recupero unico esistente) e le tue regole in ~/Library/Application Support/RoamSwitch/rules.d (si leggono solo file di proprietà di root o tua che né il gruppo né altri possono scrivere). Le cartelle già monitorate, come Download, vengono controllate subito dopo una scrittura; le cartelle web di sviluppo una volta al giorno e su richiesta (il controllo giornaliero non entra in node_modules e .git; quello di una cartella scelta entra in node_modules). Poiché EndpointSecurity non è usato, nulla può essere fermato prima dell'esecuzione: ogni rilevamento avviene a posteriori.

Per impostazione predefinita viene messo in quarantena automaticamente solo critical. Un risultato high non tocca il file e compare come notifica e in un elenco nelle Impostazioni, dove puoi scegliere «non rilevare più» (il livello di quarantena si cambia nelle Impostazioni). L'hook post-rilevamento (~/Library/Application Support/RoamSwitch/hooks/post-detection) viene eseguito solo se appartiene a root o a te e nessun altro può scriverlo, e viene interrotto dopo 30 secondi. La risposta sugli account (disattivata per impostazione predefinita; per attivarla serve la password di amministratore) revoca la shell di login del proprietario di un file in quarantena, ma non tocca root, UID inferiori a 501 né utenti connessi (compreso te, che stai usando questo Mac). Eseguito come root sotto il sandbox dell'helper in una macchina virtuale macOS 26, sono stati verificati il vero cambio di shell con dscl e il suo ripristino (il sandbox blocca le scritture dirette in dslocal, ma non le modifiche fatte tramite dscl). La conferma con la password di amministratore e il percorso di chiamata dall'app all'helper non sono ancora stati verificati su una macchina reale. Ci sono stati 0 risultati in 114.501 file di una cartella di sviluppo.

Monitoraggio di nuova persistenza di avvio (LaunchAgent/LaunchDaemon) — 1.8.7

I nuovi file .plist collocati in ~/Library/LaunchAgents, /Library/LaunchAgents o /Library/LaunchDaemons vengono rilevati in tempo reale tramite FSEvents (PersistenceMonitorGuard). Senza ES_EVENT_TYPE_AUTH_CREATE di EndpointSecurity, la scrittura stessa non può essere bloccata. Ciò che si può fare è accorgersene entro pochi secondi e valutarne il contenuto.

La valutazione si basa su cosa viene avviato direttamente, non sulla firma dell'eseguibile stesso. Tecniche reali osservate nel 2026 — un LaunchAgent camuffato da Google Update che nasconde uno script bash decodificato in base64, oppure un LaunchDaemon con privilegi root che riesegue a ogni avvio un payload AppleScript decodificato in base64 — nascondono entrambe il codice malevolo nello script stesso, mentre richiamano semplicemente un /bin/bash o /usr/bin/osascript firmato validamente. Un controllo che guardasse solo la firma dell'eseguibile lascerebbe passare entrambi i casi. Per questo, qualsiasi LaunchAgent/LaunchDaemon appena registrato che invochi direttamente un interprete di script grezzo (bash, sh, zsh, osascript, python3, perl, ruby, php e simili) viene segnalato incondizionatamente, indipendentemente dalla validità della firma dell'interprete stesso. Gli argomenti passati vengono inoltre sottoposti a StaticSignatureScanner, e ogni pattern noto come malevolo viene incluso nella notifica. Le voci registrate tramite BundleProgram (che puntano a un binario compilato e firmato all'interno di un bundle applicativo, incluso l'Helper stesso di RoamSwitch) vengono semplicemente verificate nel modo consueto, con codesign --verify --strict.

Rilevamento di ClickFix e blocco di emergenza — 1.8.7, disattivato di default

«ClickFix» è una tecnica di ingegneria sociale in cui una falsa schermata CAPTCHA o di errore invita ad aprire il Terminale e a incollare un comando «per la verifica». Le rilevazioni sono aumentate di oltre il 500% dal 2024 al 2025, e entro il 2026 è considerata uno dei vettori di attacco macOS più diffusi. Poiché è la shell legittima dell'utente stesso a eseguire esattamente ciò che è stato digitato, elude completamente la verifica della firma di Gatekeeper.

Barra dei menu → Protezione da malware → Difesa ClickFix (Pro, disattivata di default). Monitora tramite FSEvents le nuove righe aggiunte a ~/.zsh_history/~/.bash_history (solo le righe aggiunte dopo l'avvio della protezione — non esamina mai la cronologia già esistente), e verifica la corrispondenza solo con le reverse shell da manuale condivise con StaticSignatureScanner, oltre alla specifica combinazione di decodifica base64 direttamente verso una shell o verso osascript. Un semplice curl | bash — estremamente comune negli installer legittimi — è deliberatamente escluso, poiché è indistinguibile dalle istruzioni ufficiali di installazione di Homebrew, rustup, nvm e simili. Non appena viene trovata una corrispondenza, si attiva lo stesso air-gap di emergenza descritto sopra. Poiché il comando è già stato eseguito, si tratta necessariamente di una reazione successiva, ma può comunque interrompere un download di seconda fase o un'esfiltrazione di credenziali in corso. Come qualsiasi altro trigger dell'air-gap, si disattiva da solo dopo al massimo 10 minuti (vedi l'inizio di questa sezione).

Un limite noto. Poiché il rilevamento dipende da una scrittura nella cronologia della shell, non può individuare la variante fileless che elude completamente il Terminale invocando direttamente l'Editor di script tramite lo schema URL applescript://, senza scrivere nulla su disco. Apple ha introdotto una certa mitigazione per questo (una finestra di conferma per gli script non identificati), ma sono state segnalate varianti che la aggirano. Abbiamo testato questo percorso su hardware reale usando il log unificato di macOS (log show/log stream) e non abbiamo trovato alcun segnale di log distintivo su cui basare il rilevamento. Preferiamo dichiarare apertamente questo limite piuttosto che rivendicare una copertura che non abbiamo.

Rilevamento rischi Docker — 1.8.9, Pro, disattivato per impostazione predefinita

Barra dei menu → "Protezione da malware" → "Rileva container Docker privilegiati e mount docker.sock" (DockerEventGuard). Poiché questa codebase non ha precedenti di connessioni di streaming persistenti come docker events, utilizza lo stesso approccio di polling a timer di PortAnomalyGuard. Ogni 20 secondi recupera l'insieme degli ID dei container con un leggero docker ps -q, quindi esegue docker inspect --format solo sulla differenza (container appena avviati) per un'ispezione dettagliata. La stringa di formato usata per il rilevamento è deliberatamente identica a quella dell'edizione Linux (roamswitch_core::health::LinuxHealthChecker::DOCKER_INSPECT_RISK_FORMAT), quindi entrambe le piattaforme segnalano esattamente le stesse condizioni (avvio in modalità --privileged, o un mount collegato di /var/run/docker.sock).

Nessuna azione automatica viene intrapresa al rilevamento. Un container privilegiato o un mount docker.sock è una "configurazione" rischiosa che potrebbe consentire l'escape dal container, ma non è una compromissione confermata: esistono anche usi legittimi, come l'esecuzione deliberata di un agente di monitoraggio in modalità privilegiata. Poiché la maggior parte degli utenti non utilizza affatto Docker, questa funzione resta disattivata per impostazione predefinita anche con una licenza Pro. Non utilizza l'entitlement EndpointSecurity; la CLI docker viene individuata controllando prima il percorso di installazione predefinito di Docker Desktop, poi Homebrew, poi which. Verificata su un'installazione reale di Docker Desktop (29.7.2) in tre scenari — un container privilegiato, un container con mount docker.sock e un container normale — senza falsi positivi né rilevamenti mancati.

Controllo fughe di segreti/chiavi API — aggiunto in 1.8.4, scansione cartelle aggiunta in 1.8.9

Barra dei menu → "Protezione da malware" → "Controllo fughe di segreti/chiavi API". Incolla del testo e viene verificato all'istante alla ricerca di chiavi API e token trapelati, mostrando il numero di riga, una stringa mascherata e un consiglio per ogni risultato (SecretLeakAuditor, interamente sul dispositivo). La versione 1.8.9 ha aggiunto l'opzione "Scegli cartella da scansionare", che consente allo stesso motore di rilevamento di controllare ricorsivamente una directory — come un checkout del codice sorgente — tramite auditDirectory(at:). .git, node_modules, target, vendor, dist, build, __pycache__ e venv vengono esclusi automaticamente, così come i file superiori a 2 MB o rilevati come binari. L'elaborazione viene eseguita fuori dal thread principale per non bloccare l'interfaccia, e non viene mai inviato nulla all'esterno.

Link Guard (blocco delle connessioni di phishing) — 1.7.2 e versioni successive, rafforzato in 1.8.0

Barra dei menu → "Protezione malware" → "Link Guard" (Pro). Blocca le connessioni a siti di phishing/truffa sul dispositivo, su ogni browser e app. Esistono due punti di applicazione, utilizzati insieme in ordine di priorità.

• ① Estensione del sistema di filtro dei contenuti (RoamSwitchLinkFilter, 1.8.0+, preferibile una volta approvata). Un'estensione del sistema NEFilterDataProvider: nessuna revisione da parte di Apple (i fornitori di filtri dei contenuti sono self-service, nessuna coda di approvazione). Esamina l'effettivo flusso TCP in uscita dopo risoluzione dei nomi. Il nome di destinazione deriva dal nome host risolto dal sistema operativo o, in caso contrario, TLS SNI viene analizzato dai primi byte del flusso, quindi un browser che esegue il proprio DoH/DoT e si connette a un IP nudo è ancora bloccato. Non riscrive mai /etc/hosts e attribuisce ogni flusso a un processo. QUIC (UDP/443) non ha SNI leggibile, quindi in modalità block viene eliminato, costringendo il browser a ricorrere a HTTP/2 su TCP. Richiede un'approvazione una tantum nelle Impostazioni di sistema.
• ② /etc/hosts sinkhole (fallback, mentre l'estensione non è approvata/rifiutata). L'helper privilegiato scrive i domini di destinazione in una sezione gestita delimitata di /etc/hosts come 0.0.0.0 e svuota la cache. Limite massimo a 60.000. Una volta attiva l'estensione, questa sezione verrà rimossa.
• Tre modalità. "Off" lo disabilita. "Solo avviso" mette in pausa la connessione corrispondente e chiede all'utente (vedi Real warn di seguito). "Blocco automatico dei siti truffa evidenti (consigliato)" viene eliminato immediatamente. L'impostazione predefinita è blocco a partire dalla versione 1.7.2.
• Real warn (1.8.0+, solo estensione). Su warn premi l'estensione di sistema holds il flusso (sia il nome del sistema operativo che il percorso SNI) con .pause() e l'app genera una notifica "Consenti/Blocca". Nel momento in cui il tocco dell'utente raggiunge allowlist.txt / extra.txt (l'estensione esegue il polling dei piccoli file di stato ogni 1,5 s) i flussi sospesi riprendono (consenti) o interrompono (bloccano). Nessuna risposta entro 25 s fallisce open (un avviso è consultivo). La decisione viene memorizzata nella cache per host (consenti 5 minuti/blocco 1 ora), quindi gli altri flussi della pagina e le visite successive sono istantanei e applicati. La notifica block è invariata: "Bloccato..." con un pulsante "Consenti una volta (5 min)".
• Solo i casi chiari vengono bloccati. Un elenco nel feed delle minacce o un omografo Unicode di un marchio: tutto il resto (TLD ad alto rischio, impersonificazione di sottodomini, ...) è un avvertimento. Il motore del verdetto è condiviso con l'edizione Linux e non invia URL da nessuna parte.
• Recupero da un blocco sbagliato. Consenti un dominio dalla notifica o dal menu (5 minuti o permanente). L'elenco consentito viene sottratto quando la sezione viene rigenerata.
• Pro-gate. L'applicazione (applyMode()) avviene solo su una licenza Pro valida. Senza Pro la modalità viene memorizzata ma /etc/hosts non viene mai toccata. L'attivazione o la decadenza di una licenza ha effetto a metà sessione.
• Feed e seed in bundle. L'elenco dei blocchi proviene dal feed delle minacce firmato (§7, verificato con una chiave dedicata al feed). Funziona sul seed in bundle dell'app (~ 60.000 voci) anche prima del primo recupero e la disattivazione dell'"Aggiornamento automatico" significa assenza di traffico in uscita.

Blocco preventivo ARP/NDP del gateway: 1.7.5 e versioni successive

Barra dei menu → "Monitoraggio porta e dispositivo" → "Aggiungi ARP/NDP del gateway su reti non attendibili (preventivo)" (Pro, disattivato per impostazione predefinita).

• Come funziona. Quando si accede a una rete non attendibile, il MAC corrente del gateway IPv4, del router predefinito IPv6 e dei risolutori DNS sul collegamento viene raccolto da route / scutil --dns / arp -n / ndp -an e l'helper blocca ciascuno come voce permanent con arp -s / ndp -s (attendibilità al primo utilizzo — il primo MAC osservato è attendibile). Le risposte ARP/NDP contraffatte per tali IP vengono quindi ignorate, quindi non è possibile impostare un attacco man-in-the-middle.
• Scope. Vengono bloccati solo questi tre tipi di voce. Le reti affidabili (aperte) non vengono mai bloccate. Ad ogni modifica della rete si sblocca una volta e si ricollega. I risolutori pubblici off-link (8.8.8.8, …) non hanno alcuna voce ARP on-link e sono automaticamente esclusi.
• arp -s è preventivo; l'air-gap è successivo al fatto. Questo pin esiste quindi uno spoofing non può avere successo; Il rilevamento dello spoofing ARP (ARPSpoofContainmentManager) e l'air-gap di emergenza esistono per "tagliare più velocemente di un essere umano" una volta che ne viene visto uno. Corrono in modo indipendente.
• Persistenza. Il set di pin viene salvato in /Library/Application Support/RoamSwitch/gateway_arp_lock.json in modo che possa essere sbloccato tramite una riconnessione XPC o un riavvio dell'assistente.

Il tunnel VPN (WireGuard/Tailscale) e il suo kill switch — 1.7.6 e versioni successive, backend selezionabile nella 1.8.0

Barra dei menu → "Monitor porta e dispositivo" → "Tunnel VPN" (Pro, disattivato per impostazione predefinita). Questa è la difesa primary anti-MITM: non dipende dall'integrità di L2 (ARP/NDP). Il backend è selezionabile (sottomenu → "Backend") tra "WireGuard (file di configurazione)" e "Tailscale (Nodo di uscita)". RoamSwitch non implementa alcuna crittografia stessa; solo il backend scelto è armato.

• (A) Backend WireGuard. Guida wireguard-tools di Homebrew (nessun diritto all'estensione di rete Apple). Importa il tuo .conf; l'aiutante lo salva in 0600. Kill-switch: pf block drop all più un pass quick solo per lo, l'interfaccia del tunnel, l'handshake UDP agli IP dell'endpoint bloccato, DHCP e ICMP. Un tunnel AllowedIPs non pieno genera un avviso di tunnel diviso.
• (B) Backend Tailscale (1.8.0+). Per gli utenti che già eseguono Tailscale. RoamSwitch non esegue tailscale up / accede / lo installa: legge tailscale status --json ed esegue tailscale set --exit-node=<node>. Si consiglia la build Standalone (download diretto da tailscale.com) con l’integrazione CLI attivata (Impostazioni → “CLI integration” → “Install Now”, che aggiunge /usr/local/bin/tailscale): la build dell'App Store (GUI) non può essere gestita dall'esterno dell'app (sandbox); con esso scegli il nodo di uscita nell'app Tailscale e RoamSwitch mostra solo lo stato. È richiesto un nodo di uscita (indirizza tutto il traffico attraverso il tunnel); viene disattivato automaticamente se va offline o non è raggiungibile.
• ⚠️ La build Homebrew (brew install tailscale) non è consigliata. Il tailscaled distribuito da Homebrew presenta un bug noto su macOS che può impedirgli di riscrivere correttamente la tabella di routing (tailscale/tailscale#21395, #21216) — un exit node può risultare “connesso” mentre il traffico continua a fuoriuscire, oppure la sua disattivazione può interrompere completamente la connessione Internet del Mac. RoamSwitch verifica l’effettiva tabella di routing del sistema operativo e avvisa quando ciò accade, ma usare la build Standalone sopra indicata evita il problema a monte.
• Riconfigurazione della rete alla disconnessione. Il macOS autonomo tailscaled non ripristina in modo pulito il routing + DNS quando un nodo di uscita viene cancellato, quindi RoamSwitch rimbalza i servizi di rete attivi (lo stesso che attivare manualmente il Wi-Fi; solo servizi con un indirizzo IPv4, sicuro per multi-NIC e IP statico). Il traffico diminuisce per circa 5-10 secondi e il livello di protezione non viene abbassato durante tale periodo.
• Il kill switch di Tailscale è disattivato per impostazione predefinita (opt-in). Il nodo di uscita esegue già il tunneling di tutto; il pf block drop all (consente solo CGNAT/MagicDNS/STUN/DERP/DHCP/ICMP/DNS) è per utenti avanzati ed è "resistente alle perdite, non a prova di perdite" (il DNS è consentito, quindi tailscaled sopravvive).
• Automatico / in caso di perdita della licenza. Si attiva su reti non attendibili, diminuisce su quelle attendibili; revocato alla scadenza della licenza Pro.

§6

Quando ti connetti a una rete che non hai registrato, l'interruttore del "livello di protezione" non viene utilizzato pf. Modifica semplicemente le impostazioni standard del sistema operativo in un modo che può essere invertito in seguito.

Niente di tutto questo è un nuovo meccanismo di blocco aggiunto da RoamSwitch: si tratta semplicemente di attivare/disattivare le impostazioni del sistema operativo. Se elimini l'app, l'unica cosa che si ferma è la commutazione dipendente dalla rete; l'ultimo sistema operativo le impostazioni applicate rimangono invariate. Niente viene lasciato bloccato, ma se vuoi sbagliare sul per sicurezza, reimpostarlo su "Aperto" su una rete attendibile prima di disinstallarlo.

§7

Cosa rimane sul Mac

Traffico in uscita dalla macchina (l'elenco completo)

Non esiste alcun codice che raccolga e invii risultati diagnostici, informazioni sulle porte, URL o log. Non sono inclusi SDK di analisi né SDK di crash reporting. L'unica libreria esterna è Sparkle (aggiornamenti). Ciò che esce in rete sono i seguenti otto percorsi, più le funzioni avviate dall'utente, le funzioni disattivate per impostazione predefinita e la protezione DNS dalle minacce descritte sotto la tabella, e nient'altro (il sesto solo se l'utente configura una VPN, il settimo solo se è attivata l'associazione RoamSwitch Sensor).

# Firma Developer ID e Team ID
codesign -dvvv /Applications/RoamSwitch.app 2>&1 | grep -E 'Authority|TeamIdentifier|flags'

# Se il ticket di notarizzazione è stato allegato (staple)
stapler validate /Applications/RoamSwitch.app
spctl -a -t exec -vvv /Applications/RoamSwitch.app

# Firma dell'helper incluso / server MCP
codesign -dvvv /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchHelper
codesign -dvvv /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer

codesign -d --entitlements :- /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchHelper
codesign -d --entitlements :- /Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer
# → Un dizionario di entitlements vuoto. Nessuna chiave app-sandbox / network client.

# Esegui tcpdump in parallelo per confermare che, nell'uso normale, non ci sia traffico al di fuori dei percorsi della tabella
sudo tcpdump -i any -n 'host not 127.0.0.1' and 'not port 53'
# Nessun traffico se non i percorsi della tabella (attivazione della licenza, controlli di aggiornamento, dati di aggiornamento firmati, aggiornamenti di ClamAV e così via)

Per un controllo più rigoroso e automatizzato con attribuzione per processo, vedere rs-zerotel-audit.sh in roamswitch-support/audit/

# Verifica automaticamente in un unico passaggio il confine di autorizzazione XPC, la priorità Air-Gap di pf, il rilevamento dell'esposizione delle porte, la modalità di sola lettura di MCP e il monitoraggio ARP
git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Test di penetrazione in tempo reale e audit di difesa multilivello da una VM macOS: RESULTS-DEFENSE-2026-08-30

# Interroga il dominio di test ufficiale di Quad9 per verificare il blocco delle minacce
nslookup test.dns9.quad9.net
# → Deve restituire ** server can't find test.dns9.quad9.net: NXDOMAIN, cioè la risoluzione dei nomi è bloccata

# Crea la stringa di test antivirus standard e innocua (EICAR) in Downloads
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > ~/Downloads/eicar_test.com
# → Il rilevamento FSEvents attiva una scansione immediata di ClamAV; non viene mostrata alcuna notifica e "firma di test EICAR rilevata (innocua)"
#   viene registrata nella cronologia delle notifiche. Poiché EICAR è un file di test standard del settore e non una minaccia reale,
#   non viene messo in quarantena né bloccato e il file resta al suo posto (solo un vero campione di malware viene spostato nel gestore della quarantena).

## Una reverse shell da manuale tratta da riferimenti pubblici di offensive security (innocua, non viene mai eseguita)
echo 'bash -i >& /dev/tcp/127.0.0.1/4444 0>&1' > ~/Downloads/rs_test.sh
## → Anche senza ClamAV installato, appare una notifica «File scaricato pericoloso messo in quarantena» e il file viene
##   spostato immediatamente nella cartella Quarantine (indipendentemente dal database delle firme di ClamAV)

# Creare un LaunchAgent innocuo che invoca direttamente un interprete di script grezzo (non viene mai realmente eseguito)
cat > ~/Library/LaunchAgents/com.example.selfcheck.plist <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
  <key>Label</key><string>com.example.selfcheck</string>
  <key>ProgramArguments</key><array><string>/bin/bash</string><string>-c</string><string>echo hi</string></array>
</dict></plist>
EOF
# → Entro pochi secondi dovrebbe apparire una notifica «Rilevata nuova registrazione di avvio automatico». Rimuoverlo in seguito:
rm ~/Library/LaunchAgents/com.example.selfcheck.plist

# Se la sezione gestita è presente (2 righe BEGIN/END in modalità Pro + predefinita)
sudo grep -c 'RoamSwitch link guard' /etc/hosts

# Il contenuto della sezione e il numero di sinkhole
sudo sed -n '/BEGIN RoamSwitch link guard/,/END RoamSwitch link guard/p' /etc/hosts | head -4
sudo sed -n '/BEGIN RoamSwitch link guard/,/END RoamSwitch link guard/p' /etc/hosts | grep -c '^0\.0\.0\.0'

# Se viene effettivamente bloccato (verificato con una voce della sezione; innocuo)
D=$(sudo sed -n '/BEGIN RoamSwitch/,/END RoamSwitch/p' /etc/hosts | awk '/^0\.0\.0\.0/{print $2; exit}')
dscacheutil -q host -a name "$D"   # → ip_address: 0.0.0.0 (risoluzione dei nomi bloccata)

# Verifica anche che la sezione precedente scompaia tramite Menu → "Protezione link" → "Off"

# Feed e manifest pubblici (chiunque può recuperarli e verificarli)
curl -s https://lafine.net/updates/v1/manifest        # version/generated/threatfeed{...}
curl -sI https://lafine.net/updates/v1/manifest.sig   # → text/plain
# Viene inviata solo una GET senza query string, cookie o identificatore per dispositivo (solo lo User-Agent standard). Verificabile eseguendo tcpdump in parallelo.

# Connettersi a una rete non attendibile con il blocco preventivo attivo → verificare le voci permanent
arp -an | grep -i permanent          # Il gateway e le altre IP sono elencati come (permanent)
ndp -an | grep -i 'P '               # Lato IPv6 (P = permanent)
sudo cat "/Library/Application Support/RoamSwitch/gateway_arp_lock.json"  # L'insieme delle mappature IP→MAC attualmente fissate
# Rilascia il blocco dal menu → quanto sopra dovrebbe scomparire

# Presuppone wireguard-tools (tramite Homebrew)
brew list wireguard-tools >/dev/null && echo "wireguard-tools: OK"

# Attiva la VPN su una rete non attendibile → prima che il tunnel sia attivo, pf è in stato di kill-switch
sudo pfctl -sr | grep -E 'block drop all|pass .*(utun|udp)'   # block drop all + un insieme limitato di regole pass quick

# Dopo che il tunnel è attivo (wg-quick up già eseguito)
wg show                              # handshake / transfer è attivo
route -n get default | grep interface  # → utunN (la route predefinita è il tunnel)
# Disattiva la VPN → il kill-switch viene rilasciato e pf torna allo stato precedente

# Il LaunchDaemon registrato
sudo launchctl print system/com.tetsuharu.RoamSwitch.Helper

# Le regole pf attualmente caricate (stato reale di Air-Gap / guardia porte)
sudo pfctl -sr

# La directory di stato dell'helper
ls -la "/Library/Application Support/RoamSwitch/"

BIN=/Applications/RoamSwitch.app/Contents/MacOS/RoamSwitchMCPServer
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
              '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | "$BIN"
# Restituisce serverInfo e le definizioni degli strumenti. Non si verifica alcuna connessione di rete.

git clone https://github.com/lafine1211/roamswitch-mcp
cd roamswitch-mcp
swift build -c release        # Lo stesso codice sorgente del binario distribuito
swift test                    # Test unitari, input avversari, stdio e fuzzing a mutazione
# Consulta SECURITY_TESTING.md per il contenuto dei test e i problemi riscontrati

# Il valore grezzo associato al token (viene inviato solo uno SHA-256 con salt)
ioreg -d2 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'