Solutions pour la gestion des domaines Windows Active Directory

How to configure the TightVNC remote control tool (screen sharing)?

How can I make sure TightVNC is secure to use?

I've heard there are a lot security issues with the VNC family of products.

The use of a remote maintenance tool, whatever it is, carries the risk for a company of creating potential security holes. In the case of VNC, the main reproaches made are:

• Unencrypted storage of the connection password in the Windows registry (older versions of VNC).
  
• Connections are "possible" at any moment when the VNC module installed on the client is running as a service.
  
• Unencrypted transmission of data between the administration machine and the administered machine.

As a consequence, depending on the implemented security, the risks incurred from "users" with malicious intentions (call them pirates if you prefer) are:

• Recovery of the unencrypted connection password stored in the Windows registry.
  
• Brute force attempts at discovering the connection password.
  
• Analysis of the packets exchanged between the administration machine and the administered machine ("packet sniffing"), and therefore possible retrieval of any confidential data entered via the keyboard.

Anyone in possession of the password would then be able to take control of the client machine and gain access to all its data, including confidential data.

In order to cure this first problem, IDEAL Administration and IDEAL Remote now only use TightVNC, which is an "improved" version of VNC. The improvements take the form of an encrypted password stored in the Windows registry and increased display speed on low throughput networks (when taking control via a modem, ISDN line, WAN, etc.) Furthermore, as far as setting the options goes, TightVNC is much more flexible than VNC (no need to alter the Registry with regedit or any other tool).

It should be noted that TightVNC (as well as VNC) uses "challenge-response" mode for authentication. The principle is roughly the following: one of the machines generates a random number, sends it to the other, encrypts it using the password, recovers the result of the same encryption done by the other machine, then compares the two results. If the results match, then the password is correct; otherwise it isn't! Henceforth, the password never travels over the network.

To cure the second potential security problem, Pointdev has altered TightVNC's standard way of working. You can now configure IA so that the "VNC Server" service is shut down when you have finished taking control remotely. From now on, in order to enable remote control, the "VNC Server" service must first be started on the remote machine. IA/IR automatically carries out this operation.

Note: This applies only to NT/W2K/XP/Windows 7/Windows 10 machines.

Lastly, as far as network connections are concerned, communications between the administration and administered machines may from now on pass through an encrypted tunnel. From then on, any packets exchanged between these two machines are virtually uncrackable!

The principle behind tunneling is as follows:

• A virtual circuit, known as a tunnel, is created between two machines. As soon as this virtual circuit is established, all data passing through it is encrypted.
  
• In order for an application on either machine to use this virtual circuit, all it has to do is redirect the data away from the normal communication port it uses to the port used for this circuit.

See Picture at the end.

In the "normal" case, VNC Viewer (on the administration machine) communicates with VNC Server (on the administered machine) via a local TCP port (eg. 2373) and a remote TCP port (5900 by default). Data transiting between the two machines (the twin red arrow) is unencrypted at this stage.

If a tunnel is being used (the twin green arrow), local TCP port 2373 will be redirected for example to local TCP port 11965 (tunnel entry), and the remote TCP port 5900 will be redirected for example to remote TCP port 11965 (tunnel exit). Since the tunnel is encrypted, our mission is accomplished!

Practically, here's what has to be done:

• On each machine, installation of the tunneling software.
  
• On the administered machine, the tunneling software works in "server" mode (accepts incoming connections), redirecting local TCP port 5900 to local TCP port 11965.
  
• On the administration machine, the tunneling software works in "client" mode (accepts outgoing connections), redirecting local TCP port 2373 to local TCP port 11965.
  
• Lastly, all that remains is to start up VNC Viewer with the right parameters!

The tunneling software selected for use by Pointdev is "Zebedee" (http://www.winton.org.uk/zebedee/)

Like TightVNC (http://www.tightvnc.com/), Zebedee is distributed under the GPL's licensing conditions GPL.

You will find the source code of Pointdev's modified version of TightVNC, along with a link to Zebedee source code, the text of the GPL and other free tools made available by Pointdev, at

http://www.pointdev.com/en/free

Notes:

[list=1][*] Packets passing through the tunnel are not only encrypted but also compressed. Consequently, if VNC is used over a relatively low throughput network (switched telephone network, ISDN, WAN, ADSL, etc.), improved response times should be observed.
Nevertheless, given that TightVNC also uses compression algorithms, we strongly advise against setting Zebedee's compression value to its top limit (9). The numerous tests we've carried out show that the default value of 6 is more than adequate!

[*] As far as packet sniffing goes, it mustn't be forgotten that this is possible and quite simple to do as long as the network is hub-based. From the moment there are switches on the network - which is becoming more and more frequent - packet sniffing is no longer possible except on a single section that is still controlled by one or more hubs.

[*] For maximum security, you must:
- Close down the VNC Server service when finishing a remote maintenance session.
- Change the default VNC Server listening port on the client machines.
- Use Zebedee on the administration and administered machines.
- Use personal keys for Zebedee authentication (which is not the default configuration set by our installer). To do this, please refer directly to the Zebedee documentation (file zebedee.htm in the C:Program FilesPointdevZebedee directory).
- Authorize only loopback-type connections at the VNC Server (i.e., on the administered machines). Once this is done, any attempt at taking control directly (i.e., without passing through Zebedee on the administered machine) is purely and simply rejected!
To put this into effect, when the VNC Server service is active, select Start/Program Files/Pointdev/GPL/TightVNC/Administration/Show Default Settings and then press the "Advanced" button and put a check mark in the "Allow ONLY loopback" box. This parameter corresponds to the following key: KHLM\SOFTWARE\ORL\WinVNC3\LoopBackOnly:DWORD=1

[*] One of the many interesting features of Zebedee is its ability to carry out remote maintenance sessions across a firewall. Due to its listening port numbers being configurable, you could quite easily configure it to use, say, port 23189, and then open this port on your firewall. As this port is not assigned to any specific application (see list of assigned TCP and UDP ports), it draws less attention to itself (from "pirates") than ports in the 5900 (or 5800) range, which are reserved for VNC family tools.
Note: The default Zebedee port (11965) is not referenced by the IANA. Having said that, it doesn't take long to find the information out using Google or some other search engine.

[*] Finally, one more interesting feature of Zebedee, which stems from the previous one, is the option of taking remote control of several machines behind a firewall (or filtering router) while leaving just one single port open on it. The way this is done is as follows: open port 23189 (say) on the firewall and translate it to port 23073 (say) on a machine on the internal network on which Zebedee is installed; this machine will act as a relay. In the Zebedee configuration on this machine, the serverport, target, and redirect parameters will need to be defined as follows:
serverport 23073
redirect 5900
target 192.168.1.0/24
The effect of this will be to listen on local port 23073 and to authorize redirection of client requests to port 5900 on any machine on the 192.168.1.0/24 network.
Lastly, on the administration machine, the command zebedee -T 23189 external_ip_address_of_firewall 23000:192.168.1.1:5900 will have the effect of creating a tunnel between that machine and the remote relaying machine across the firewall. This tunnel's departure port on the administration machine will be 23000 and its arrival port on the relaying machine behind the firewall will be 23073. Since in our command we requested port 5900 on machine 192.168.1.1, the relaying machine will "transfer" our request to the standard VNC listening port on that machine.
From now on, the command vncviewer localhost:23000 on the administration machine will bring up the screen display from the machine behind the firewall whose IP address is 192.168.1.1.

Note: This configuration is far from being the simplest or the most common, so don't fret too much if you didn't understand everything!