Introduzione
In questo documento tecnico vediamo come si può configurare un intero sistema di assistenza remota multipiattaforma esclusivamente con strumenti open source. Per motivi di praticità vengono presi in considerazione solo i sistemi operativi Windows e Linux, ma con piccole modifiche si possono adattare le istruzioni anche ad altre piattaforme (Mac OS, Solaris, BSD, ecc.).
L'obiettivo finale è fare in modo che un cliente (server) lanciando un semplice software di connessione (detto single-click perché non deve presentare particolari difficoltà) possa mettere in condizione un tecnico (viewer) di fornirgli assistenza anche se entrambi si trovano in reti private, non sono raggiungibili pubblicamente e non possono aprire specifiche porte sui rispettivi firewall (per limiti imposti dall'amministratore di sistema, per scarse capacità del cliente remoto o semplicemente per praticità).
Naturalmente quella prospettata rappresenta solo una delle possibili soluzioni di assistenza remota multipiattaforma open source, che sono tantissime a causa soprattutto delle differenti tecniche di sicurezza esistenti e delle implementazioni talvolta "personalizzate" del protocollo RFB alla base di tutti i software VNC.
Configurazione del repeater
Una delle prime componenti che andiamo a configurare è il cosiddetto repeater. Trattasi di un software a cui si possono collegare il server ed il viewer quando si trovano in una rete privata in modo che ciascuna delle due parti effettui una connessione solo "in uscita" dalla propria rete e non sia (sperabilmente) bloccata dal firewall.
Naturalmente, a causa del suo ruolo, il repeater deve essere raggiungibile da rete pubblica. Può quindi ad esempio essere comodamente installato su un VPS.
Ho scelto di affidarmi ad ultravnc_repeater.pl, ottimo script in Perl di Karl J. Runge che consente di sfruttare un server Linux e di potersi comunque connettere sia in modalità semplice che crittografata.
Più precisamente, ne ho derivato una versione personalizzata denominata mz_ultravnc_repeater che andiamo a scaricare dal mio repository SVN e che rispetto all'originale aggiunge la possibilità di filtrare i server ed i viewer in base a determinati ID di connessione.
Digitare anzitutto:
$ ./mz_ultravnc_repeater.pl -h
per un elenco completo di opzioni e relative spiegazioni.
Per l'esecuzione è sufficiente digitare il comando:
$ ./mz_ultravnc_repeater.pl -r -i ID_CONNESSIONE_1 -i ID_CONNESSIONE_2 -i ID_CONNESSIONE_3 -l FILE_DI_LOG PORTA_VIEWER PORTA_SERVER
che lancia il software accettando determinati ID e connessioni da PORTA_VIEWER (a cui si connette il tecnico) e PORTA_SERVER (a cui si connette il cliente), rifiutando peraltro due connessioni consecutive con lo stesso ID (per non disconnettere un precedente server) e loggando l'attività su FILE_DI_LOG.
Ad esempio una configurazione che preveda l'uso da parte di 3 tecnici (ID rispettivamente 1000, 1001 e 1002) potrebbe essere la seguente:
$ ./mz_ultravnc_repeater.pl -r -i 1000 -i 1001 -i 1002 -l /var/log/mz_ultravnc_repeater.log 5901 5501
Va da sé che devono essere aperte le corrispondenti porte sul firewall della rete che ospita il repeater.
Per evitare brutte sorprese in caso di qualche falla all'interno del repeater, oppure semplicemente per non permettere lo sfruttamento dello stesso da parte di terzi non clienti, consiglio i seguenti accorgimenti di sicurezza.
- Evitare di lanciare il repeater come root, dato che non è indispensabile farlo.
- Meglio ancora, lanciarlo solo quando effettivamente serve (ovvero quando un cliente telefona chiedendo assistenza) e con le opzioni
-ie-rin modo da assegnare specifici canali ID di connessione e farli occupare subito da una sessione server-viewer. Lo script prevede anche la possibilità di essere lanciato come cgi (quindi ad esempio via web), ma in tal caso consiglio di leggere bene le istruzioni perché ci possono essere dei potenziali rischi di sicurezza. - Utilizzare sempre il file di log, che ovviamente deve essere configurato in modo da permettere la scrittura anche all'utente non root che manda in esecuzione il repeater.
Non è invece particolarmente utile filtrare per MAC address le connessioni viewer, dato che il repeater leggerebbe come indirizzo quello del router da cui il tecnico si connette e non quello del suo specifico computer.
Nemmeno configurare il repeater per accettare connessioni su porte non standard (che di default sono la 5900 e la 5500) è garanzia di sicurezza, e ciò perché si potrebbe facilmente "sbirciare" nei software di connessione per leggere tali parametri. Tuttavia può essere un aiuto per prevenire attacchi da software automatizzati, e quindi è comunque consigliabile seguire questa strada.
Configurazione del server Windows
Per Windows la scelta "obbligata" per il server è UltraVNC in versione Single-Click (SC), servizio particolare che consente di caricare un file sull'apposito creatore online e di ottenere il programma in versione già compilata.
Teoricamente è tutto documentato sul sito web, il quale però è molto confusionario e presenta spesso informazioni contraddittorie o superate.
Rechiamoci sulla pagina contenente la documentazione, scarichiamo e scompattiamo il file di base custom.zip e diamo un'occhiata al resto delle informazioni contenute nella pagina per capire che tipo di personalizzazioni ci servono.
Dopodiché impostiamo il file helpdesk.txt in modo simile al seguente:
[TITLE]
Assistenza remota
[HOST]
Connessione semplice (doppio-click)
-id 12345678 -connect IP_DEL_REPEATER:PORTA_SERVER -noregistry
[TEXTTOP]
Avverti telefonicamente prima di connetterti.
[TEXTMIDDLE]
Il servizio e' disponibile esclusivamente
[TEXTBOTTOM]
per Clienti con apposito contratto.
[TEXTRTOP]
__NOME_AZIENDA__
[TEXTRMIDDLE]
__EMAIL_AZIENDA__
[TEXTRBOTTOM]
__TEL_AZIENDA__
[TEXTBUTTON]
Sito web
[WEBPAGE]
__SITO_WEB_AZIENDA__
[TEXTCLOSEBUTTON]
Chiudi
[BALLOON1TITLE]
Connessione in corso
[BALLOON1A]
Attendi qualche istante...
[BALLOON2TITLE]
Connessione attiva
[BALLOON2A]
Il tuo desktop puo' ora essere visualizzato e comandato dal Consulente.
[BALLOON2B]
E' possibile interrompere la connessione in qualunque momento facendo click destro e selezionando la voce "Close".
Chiaramente la stringa di connessione ed i messaggi vanno configurati a piacimento, così come le icone, il logo e l'immagine di background presenti nel file custom.zip originale.
Al termine ricompattiamo il tutto in un file NomeDiNostroGradimento.zip, carichiamolo online ed attendiamo qualche secondo. Il file risultante NomeDiNostroGradimento.exe è il nostro server per clienti Windows.
Quando si compila il contenuto di helpdesk.txt va tenuto presente quanto segue.
- Non utilizzare lettere accentate o caratteri non-ASCII.
- Probabilmente per un bug nel compilatore, la sezione
[TITLE]risulta di fatto ininfluente perché nella finestra del programma finale non appare alcun titolo (poco male). - È essenziale che, nella sezione
[HOST], l'opzione-idsia messa prima di-connect, altrimenti l'ID non viene passato alla connessione. - In fase di test può risultare utile aggiungere al piede del file la direttiva (non è nemmeno una sezione)
DEBUG, per seguire passo-passo l'evoluzione della connessione.
I passaggi illustrati permettono di ottenere un eseguibile che apre una connessione semplice.
Se si desidera aggiungere anche una connessione crittografata, bisogna aggiungere un'altra sezione [HOST]:
[HOST]
Connessione crittografata (doppio-click)
-plugin -id 12345678 -connect IP_DEL_REPEATER:PORTA_SERVER -noregistry
L'opzione -plugin, da mettere all'inizio della stringa, serve per utilizzare il plugin di crittografia. UltraVNC-SC supporta ufficialmente un plugin molto debole e fallato chiamato MSRC4Plugin.dsm, per cui è consigliabile invece scaricare SecureVNCPlugin che funziona perfettamente a patto di rinominarlo MSRC4Plugin.dsm.
Inglobiamo anche questo file nel nostro pacchetto NomeDiNostroGradimento.zip e ricarichiamolo online per ottenere il server aggiornato.
Attenzione che, come si avrà modo di dire in seguito, questa specifica connessione funziona attualmente solo con il client UltraVNC (quindi solo in ambiente Windows, o in emulazione tramite Wine sotto Linux) versione 1.0.9.6.2 o superiore. Bisogna poi utilizzare lato client il medesimo plugin SecureVNCPlugin.
Se la connessione crittografata non funziona, provare a riconfigurare UltraVNC-SC usando come file SecureVNCPlugin proprio quello distribuito assieme ad UltraVNC versione 1.0.9.6.2 o superiore (anziché quello scaricato dal sito ufficiale), naturalmente sempre rinominandolo MSRC4Plugin.dsm.
Configurazione del server Linux
Per Linux non esiste una soluzione simile ad UltraVNC-SC. Per cui, prendendo spunto da un articolo sul Linux Journal e studiando l'ottimo x11vnc, ho realizzato uno strumento per configurare e creare uno script autoeseguibile chiamato single_click_remote_help, che si può scaricare dal mio repository SVN.
Per la configurazione è sufficiente aprire il file skeleton e modificare la sezione 1 (costanti) con le stringhe di messaggi e connessioni desiderate; il simbolo "|" suddivide l'etichetta dai parametri da passare al server x11vnc, per la cui elencazione rimando alla specifica pagina.
Ad esempio, per ottenere una connessione semplice ed una crittografata usiamo:
CONNECTIONS[0]="Connessione crittografata (doppio-click)|-connect_or_exit repeater://IP_DEL_REPEATER:PORTA_SERVER+ID:ID_TECNICO -ssl TMP -env X11VNC_DISABLE_SSL_CLIENT_MODE=1 -sslonly"
CONNECTIONS[1]="Connessione semplice (doppio-click)|-connect_or_exit repeater://IP_DEL_REPEATER:PORTA_SERVER+ID:ID_TECNICO"
La sintassi repeater://IP:PORTA+ID:NNNNNNNN consente appunto di effettuare connessioni tramite un repeater e passando uno specifico ID.
Dopodiché basta eseguire:
$ ./build.sh
per ottenere il server (single_click_remote_help.sh).
Si può ora caricare il server sul proprio sito web, avvertendo l'utente che prima dell'esecuzione deve per forza assegnare a mano l'attributo di eseguibilità allo script scaricato (Linux infatti, per fortuna, non permette di eseguire direttamente qualunque file scaricato dalla rete).
Attualmente è supportata solo la versione per processori i686 o superiori; inoltre, poiché lo script fa uso di Zenity o (in mancanza) di KDialog, sono necessari questi strumenti installati. Di fatto, però, la maggior parte delle distribuzioni non dovrebbe aver problemi ad eseguire il software.
Configurazione del viewer Windows
In ambiente Windows conviene affidarsi a UltraVNC (versione completa, non SC naturalmente) come viewer generico, in quanto consente di connettersi a qualsiasi server VNC standard e ad UltraVNC-SC (che utilizza invece un protocollo RFB modificato e quindi non standard).
Attenzione che il plugin SecureVNCPlugin.dsm presente nell'eseguibile UltraVNC-SC deve essere il medesimo presente nella directory del viewer UltraVNC.
I parametri di connessione sono ID:ID_TECNICO come Host:Port e IP_DEL_REPEATER:PORTA_VIEWER come Proxy/Repeater, eventualmente attivando Use DSMPlugin e scegliendo SecureVNCPlugin.dsm.
L'unico problema è rappresentato dalla connessione con server Linux single_click_remote_help crittografati. Solo per questo tipo di connessioni scarichiamo ed utilizziamo SSVNC di Karl J. Runge, che purtroppo pur essendo molto valido non può essere usato come "viewer unico" perché la versione Windows (a differenza di quella Linux) non si connette bene a server UltraVNC-SC.
In questo caso i parametri di connessione sono :0 come VNC Host:Display, repeater://IP_DEL_REPEATER:PORTA_VIEWER+ID:ID_TECNICO come Proxy/Gateway, Use SSL come crittografia, Verify All Certs disabilitato e Do not Probe for VeNCrypt abilitato.
Configurazione del viewer Linux
In ambiente Linux la situazione è opposta rispetto a Windows. Conviene scaricare (ma potrebbe già essere presente nella nostra distribuzione) il già nominato SSVNC, che è un wrapper di TightVNC però con personalizzazioni di quest'ultimo e tool di crittografia che ne estendono di gran lunga l'utilizzo possibile: di fatto è una sorta di "coltellino svizzero" delle connessioni VNC, seppur con un'interfaccia (volutamente) spartana.
Con SSVNC ci connettiamo a qualunque server tranne che ad UltraVNC-SC in versione crittografata; a dire il vero, nelle ultime versioni è prevista anche questa possibilità, che però al momento non mi risulta del tutto funzionante. Per ora, quindi, solo in questi casi ripieghiamo su UltraVNC lanciato in emulazione tramite Wine.
Per i parametri di connessione di entrambi i viewer riutilizziamo le informazioni già studiate al paragrafo precedente, ovviamente con le dovute impostazioni in merito al tipo di crittografia utilizzata (nessuna, SSL, SecureVNCPlugin) e lasciando l'opzione Server uses VeNCrypt SSL encryption disabilitata.
Prospetto riassuntivo delle connessioni server-viewer
Alla luce di tutto quanto esposto, possiamo riassumere in un prospetto i viewer di cui, a seconda del tipo di connessione e del sistema operativo server, è consigliabile l'utilizzo.
| Viewer Windows | Viewer Linux | |
| Server Windows, connessione semplice: UltraVNC-SC | UltraVNC | SSVNC |
| Server Windows, connessione crittografata: UltraVNC-SC + SecureVNCPlugin | UltraVNC + SecureVNCPlugin | SSVNC + SecureVNCPlugin, oppure (tramite Wine) UltraVNC + SecureVNCPlugin |
| Server Linux, connessione semplice: single_click_remote_help | UltraVNC | SSVNC |
| Server Linux, connessione crittografata: single_click_remote_help | SSVNC | SSVNC |
Alternative e prospettive future
Le alternative concrete (tralasciamo i progetti sperimentali) per la scelta del repeater appaiono oggi essere le seguenti:
- UltraVNC Repeater: parte del progetto UltraVNC, è una buona soluzione ma necessita di un server Windows;
- UltraVNC Repeater SSL: variante del primo che supporta solo una particolare modalità SCIII (che implicherebbe anche la riconfigurazione di server e viewer), anche questo necessita di un server Windows;
- vncssld: scritto in Perl, rappresenta l'analogo del precedente per i sistemi Unix.
Un piccolo aiuto potrebbe arrivare dalla sistemazione di alcuni bug in SSVNC (e TightVNC) in modo tale da poterlo sfruttare come "viewer unico" sotto Windows e Linux, indipendentemente dal server usato ed anche in presenza di connessioni crittografate.
Più in generale, per quanto riguarda invece la scelta del server e del viewer, a mio avviso un progetto che merita di essere tenuto d'occhio è TigerVNC (evoluzione di TightVNC), che in un unico prodotto fornisce semplicità (interfaccia minimale) e crittografia integrata, oltre ad essere multipiattaforma: di fatto, tutto quello che serve per fornire servizi di assistenza remota.
Il suo neo è che attualmente non supporta alcun repeater, il che non lo rende integrabile con la soluzione sopra prospettata (ed ecco il motivo per cui non l'ho considerato in questo documento). È comunque un difetto che mi aspetto venga superato nelle prossime release.
Ultima nota, forse paranoica. La sicurezza delle connessioni può essere ulteriormente migliorata tramite la generazione di chiavi firmate, in modo da evitare attacchi man-in-the-middle. Tuttavia, essendo questo percorso più complicato e meno flessibile rispetto a quelli illustrati, mi sono limitato ad illustrare alcune configurazioni che, per interventi standard di assistenza remota, ritengo siano ragionevolmente sicure.