Translated from
http://www.marcozanon.com/documenti/assistenza-remota-multipiattaforma-open-source

Remote Assistance multiplatform open source
Introduction

In this white paper we see how you can configure an entire system of remote support platform exclusively with open source tools. For convenience are taken into account only the operating systems Windows and Linux, but with small changes you can adapt the instructions to other platforms (Mac OS, Solaris, BSD, etc.)..

The ultimate goal is to make sure that a client (server) by running a simple connection software (called single-click because it should not present major difficulties) can put in a technical condition (viewer) to provide assistance even if both are in private networks are not publicly accessible and can not open specific ports on the respective firewall (for limits imposed by the system administrator, for scarce capacity of the remote customer or simply for convenience).

Of course, that is only one of the proposed solutions, which are mainly due to a lot of different techniques and existing security implementations sometimes "custom" of the RFB protocol at the base of all VNC.

Configuring the Repeater

One of the first components we are going to configure is the so-called repeater. This is a software that can be connected to the server and the viewer when they are in a private network so that each of the two parties make a connection only "exit" from its network and is (hopefully) blocked by the firewall.
Of course, because of its role, the repeater must be reachable from the public network. Can then for example be conveniently installed on a VPS.

I chose to entrust to ultravnc_repeater.pl, excellent Perl script by Karl J. Runge allowing us to use a Linux server and still be able to connect in either simple encrypted.
More precisely, I derived a custom version called mz_ultravnc_repeater we are going to download from my SVN repository and the original adds the ability to filter the server and viewer based on certain connection ID.

First type:

$. / Mz_ultravnc_repeater.pl-h

for a complete list of options and explanations.

To run just type the command:

$. / Mz_ultravnc_repeater.pl-r-i-i ID_CONNESSIONE_1 ID_CONNESSIONE_2 ID_CONNESSIONE_3-i-l LOGFILE PORTA_VIEWER PORTA_SERVER

that launches the software and accepting connections from certain ID PORTA_VIEWER (which connects the technician) and PORTA_SERVER (which connects the customer), refusing, however, consecutive two connections with the same ID (not to disconnect a previous server) and logging in the 'activity LOGFILE.

For example, a configuration that provides for the use by 3 technicians (ID respectively 1000, 1001 and 1002) could be the following:

$. / Mz_ultravnc_repeater.pl-r-s 1000-s 1001-s 1002-l / var / log / mz_ultravnc_repeater.log 5901 5501

It goes without saying that you must open the corresponding ports on the firewall of the network that hosts the repeater.

To avoid unpleasant surprises in the event of some flaw in the repeater, or simply to not allow the use of the same by third parties not customers, recommend the following safety measures.

• Do not run the repeater as root, since it is not necessary to do so.
• Better yet, run it only when it is needed (ie, when a customer calls asking for assistance) and with the-i and-r to assign specific channels Connection ID and immediately take them to a server session-viewer. The script also includes the ability to be run as a CGI (so for example on the web), but in this case I recommend that you read the instructions carefully because there may be potential security risks.
• Always use the log file, which of course must be configured to allow writing even non-root user that runs the repeater.
It is not particularly useful for filtering MAC address connections viewer, given that the repeater would read address as the router from which the technician connects and not that of his specific computer.
Even configure the repeater to accept connections on non-standard ports (which by default are 5900 and 5500) is a guarantee of safety, and that is because you could easily "peek" in the connection software to read these parameters. However, it can be a help to prevent attacks by automated software, and therefore it is advisable to go this route.

Configuring the Windows server

For Windows the choice "forced" to the server is UltraVNC version Single-Click (SC), a special service that allows you to upload a file on the appropriate creator online and get the program version already compiled.
Theoretically it is all documented on the website, which, however, is very confusing and often contradictory information presented or exceeded.

Let us go to the page containing the documentation, download and unpack the file basis custom.zip and look at the rest of the information on the page to understand what kind of customizations we need.

Then we set the file helpdesk.txt in a manner similar to the following:

[TITLE]
Remote Assistance

[HOST]
Simple connection (double-click)
Id-12345678-connect IP_DEL_REPEATER: PORTA_SERVER-noregistry

[TEXTTOP]
Warn phone before connecting.

[TEXTMIDDLE]
The service 'available exclusively

[TEXTBOTTOM]
for customers with special contract.

[TEXTRTOP]
__NOME_AZIENDA__

[TEXTRMIDDLE]
__EMAIL_AZIENDA__

[TEXTRBOTTOM]
__TEL_AZIENDA__

[TEXTBUTTON]
Website

[WEBPAGE]
__SITO_WEB_AZIENDA__

[TEXTCLOSEBUTTON]
Close

[BALLOON1TITLE]
Connection in progress

[BALLOON1A]
Please wait a moment ...

[BALLOON2TITLE]
Connection is active

[BALLOON2A]
Your desktop may 'now be viewed and controlled by the Advisor.

[BALLOON2B]
And 'possible to disconnect the connection at any time by right-clicking and selecting "Close".

Clearly the connection string and the messages must be configured as desired, as well as icons, the logo and the background image in the file custom.zip original.

At the end ricompattiamo all in a file NomeDiNostroGradimento.zip, carichiamolo online and wait a few seconds. The resulting file is NomeDiNostroGradimento.exe our server to Windows clients.

When compiling the content of helpdesk.txt be given to the following.

• Do not use accented or non-ASCII characters.
• It is possible for a bug in the compiler, the TITLE section is in fact irrelevant because in the end the program window does not appear no title (not bad).
• It is essential that, in the HOST, the option-id is put before-connect, otherwise the ID is not passed to the connection.
• In testing can be useful to add to the foot of the directive file (it is not even a section) DEBUG to follow step-by-step evolution of the connection.
The steps allow to obtain an executable that opens a connection simple.
If you want to add an encrypted connection, you need to add another section HOST:

[HOST]

Encrypted connection (double-click)
-Plugin-id 12345678-connect IP_DEL_REPEATER: PORTA_SERVER-noregistry

The option-plugin, to be at the beginning of the string, is to use the plug-in encryption. UltraVNC-SC officially supports a plugin called MSRC4Plugin.dsm very weak and flawed, so you should instead download SecureVNCPlugin that works perfectly as long as you rename MSRC4Plugin.dsm.
Inglobiamo that file in our package and NomeDiNostroGradimento.zip ricarichiamolo online to get the upgraded server.

Please note that as you will be able to say later, this specific connection currently works only with the UltraVNC client (ie Windows only, or emulation under Linux via Wine) version 1.0.9.6.2 or higher. We must also use the same client-side plugin SecureVNCPlugin.

If the encrypted connection does not work, try reconfiguring UltraVNC-SC using precisely that SecureVNCPlugin file as distributed together with UltraVNC version 1.0.9.6.2 or higher (rather than downloaded from the official website), of course, always renaming MSRC4Plugin.dsm.

Configuring the Linux server

For Linux there is a similar solution to UltraVNC-SC. So, inspired by an article in the Linux Journal and studying the excellent x11vnc, I made a tool to configure and create a script called autorun single_click_remote_help, which can be downloaded from my SVN repository.

To configure simply open the file and change the skeleton section 1 (constant) with strings of messages and connections you want, the symbol "|" splits the label parameters to be passed to x11vnc server to the list of which refer to the specific page.

For example, to obtain a simple connection and an encrypted we will use:

CONNECTIONS [0] = "encrypted connection (double-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] = "Simple connection (double-click) |-connect_or_exit repeater :/ / IP_DEL_REPEATER: PORTA_SERVER + ID: ID_TECNICO"

The syntax repeater :/ / IP: PORT + ID: NNNNNNNN allows precisely to make connections through a repeater and pass a specific ID.

Then simply run:

$. / Build.sh

to obtain the server (single_click_remote_help.sh).

You can now load the server on its website, warning the user before execution must necessarily to manually assign attribute executability downloaded the script (Linux, thankfully, does not allow to directly execute any file downloaded from the network ).

Is currently only supported version for i686 processors and above, in addition, since the script uses zenity or (in the absence) of kdialog, you need these tools installed. In fact, however, most of the distributions should have no trouble to run the software.

Configuring the Windows viewer

In the Windows environment should rely on UltraVNC (full version, not SC of course) as generic viewer, as it allows to connect to any standard VNC server and UltraVNC-SC (which instead uses a protocol RFB modified and therefore not standard).

Please note that this plugin SecureVNCPlugin.dsm executable UltraVNC-SC must be present in the same directory as the UltraVNC viewer.

The connection parameters are ID: ID_TECNICO as Host: Port and IP_DEL_REPEATER: PORTA_VIEWER as Proxy / Repeater, possibly by activating and selecting Use DSMPlugin SecureVNCPlugin.dsm.

The only problem is the connection to the Linux server single_click_remote_help encrypted. Only for this type of connections and unload SSVNC use of Karl J. Runge, which, unfortunately, although very valid can not be used as a "viewer unique" because the Windows version (unlike that Linux) does not connect well to UltraVNC server-SC.

In this case, the connection parameters are: 0 for VNC Host: Display, repeater :/ / IP_DEL_REPEATER: PORTA_VIEWER + ID: ID_TECNICO as Proxy / Gateway, such as Use SSL encryption, Verify All Certs disabled and Do not Probe for VeNCrypt enabled.

Configuring the Linux viewer

On Linux, the situation is reversed from Windows. Should download (but it may already exist in your distribution) SSVNC the already named, which is a wrapper of TightVNC but with customizations of the latter and encryption tools that extend far use possible is made of a kind of "Swiss boxcutter" VNC connections, albeit with an (intentionally) spartan.

With SSVNC we connect to any server except to UltraVNC-SC in encrypted version, to be honest, in the latest versions is also provided for this possibility, but right now I am not quite working. For now, then, only in these cases fall back on UltraVNC launched in emulation through Wine.

For the connection parameters of both viewer reuse information already studied in the previous paragraph, of course with the appropriate setting on the type of encryption used (none, SSL, SecureVNCPlugin) and leaving the option VeNCrypt Server uses SSL encryption disabled.

Summary table of server connections-viewer

In light of the above, can be summarized in a report which the viewer, depending on the type of connection and the server operating system, it is advisable to use.

Viewer Viewer Windows Linux
Windows Server, simple connection: UltraVNC UltraVNC SC-SSVNC
Windows server, encrypted connection: UltraVNC UltraVNC-SC SecureVNCPlugin + + + SecureVNCPlugin SSVNC SecureVNCPlugin, or (via Wine) UltraVNC + SecureVNCPlugin
Linux servers, simple connection: single_click_remote_help UltraVNC SSVNC
Linux servers, encrypted connection: single_click_remote_help SSVNC SSVNC

Alternative and Future Prospects

Practical alternatives (we omit the experimental projects) for the choice of the repeater now seem to be the following:

• UltraVNC Repeater: UltraVNC part of the project, is a good solution but it requires a Windows server;
• UltraVNC Repeater SSL variant of the first that supports only a particular mode SCIII (which also means the reconfiguration of server and viewer), this requires a Windows server;
• vncssld: written in Perl, is analogous to the previous Unix systems.
A little help could arrive from the accommodation of some bugs in SSVNC (and TightVNC) in such a way that it can be exploited as the "viewer only" under Windows and Linux, regardless of the server used and also in the presence of encrypted connections.

More generally, as regards the choice of the server and the viewer, in my view, a project that deserves to be kept an eye on is TigerVNC (evolution of TightVNC), in a single product that provides easy interface (minimal) and encryption integrated, in addition to being cross-platform: in fact, all that is needed to provide remote support.
Its drawback is that currently does not support any repeater, which does not make it integrated with the solution described above (and here's the reason why I have not considered in this document). However, a flaw that I expect to be exceeded in future releases.

Last note, perhaps paranoid. The security of the connections can be further improved by the generation of keys signed, so as to avoid man-in-the-middle attack. However, since this path more complicated and less flexible than the one provided, I confined myself to illustrate some configurations, standard interventions for remote support, I think it is reasonably safe.