Remote Computing Secured
by Xphile

     Remote Control Applications are the greatest things since sliced bread
but without proper security they can quickly turn into your worst nightmare.
In issue 22:2, Screamer mentions in his article "Optimum Online and You" that
he merely installed VNC on his local machine and allowed users to connect as
if they were on his LAN.  This might seem fine to most people, but for the
readers of 2600 I feel that it's not, hence the reason I am writing
this article.

     This article will focus mainly on some of the methods to successfully
secure VNC using SSH1, SSH2, and SSL while also covering correct application
configurations.

Virtual Network Computing (VNC)

     VNC in my opinion is one of the best remote control applications available
today mainly because it's open-source and it's free, hence it's portable
and it doesn't hog system resources like PCAnywhere or M$'s proprietary 
software.  With that said...

Laying the Foundation

     The default installation of VNC leaves quite a bit to be desired security
wise but where there's a will there's a way.  One of the most important
things to do is gather all of the latest patches for the flavor that you have.
You wouldn't want any "skript kiddies" taking advantage of the flawed
authentication methods, would you?  On most versions of VNC (TightVNC 1.2.9,
current version as of 8/28/2003), the default settings do not limit the amount
of connections coming in a set amount of time, therefore allowing any genius
to run a dictionary attack on your server and in time compromise the machine.

     The brings me to my next topic, the RFB (Remote Frame Buffer) which is
the protocol used in the communication between the server and the client.  The
RFB protocol has no type of security implementation.  Therefore all traffic is
in a compressed but unencrypted form that can be read with a packet sniffing
tool.  Unfortunately there is no fix for the RFB protocol, but that will be
taken care of with tunneling.  Password policy is also very weak with the
default installation.  Hashes are stored locally on the server and encrypted
using the DES encryption method, yet they use a fixed key allowing any user
the availability to run a cracking tool such an VNCcrack.

Getting Stronger, But Not Good Enough

     Now that we have covered just some of the problems with the default
install of VNC, let's fix them.  In regards to the multiple connections and 
brute force cracking, go into the advanced section of the VNC server options.
There you will find under "Connection Priority" a setting called "Refuse
Concurrent Connections."  You will want that enabled.  I would also enable
query console for incoming connections and the log.  Since the VNC server is a
well known port (5900), you might want to change that along with the HTTP
daemon.  The last order of business would be password policy.  Since VNC doesn't
require a minimum length of the server to properly enforce a password policy
that won't be easily cracked remotely or by a local user (i.e., six characters
and numbers minimum).

VNC All Wrapped Up

     You now have a secure, VNC server running and it's completely safe, right?
Not exactly, but you're almost there.  Since we now have a pretty strong install
of the VNC server configured, it's time to take care of the RFP protocol 
problem.  To do this we will use virtual tunneling using SSH or SSL.

SSH and SSH2

     Before we start I must stress that you get the latest version of the SSH
server of your choice and that you apply all patches.  That being said, let's
get into the specifics.  For my example I will be using OpenSSH 3.6.1, which
contains both SSH1 and SSH2 suites.  Once OpenSSH is installed you must 
configure the server to "wrap" all instances of the VNC server so that all
information that is passed through to the VNC goes through the SSH server 
first.  The first step in the process is to reboot after installation so that
the server (SSH or SSH2) will start.  Next you must manually tunnel all 
connections using the command line.  Load up 'cmd.exe' and insert the following
command:
	
	ssh -L 5900:localhost:5901 localhost

     '-L' initializes local port forwarding so the servers can communicate.
'5900' is the default VNC port.  'localhost' is the machine running the server.

     This will create the virtual tunnel.  The next thing that you will want to
do is get yourself a good SSH/telnet client so you can start the SSH session.
After you have logged into the SSH server, load up VNC viewer and connect to
'localhost:5901'.

SSL

     If you do not wish to use SSH or SSH2 to tunnel your VNC connection, there
is always the option to use SSL for the tunneling, but it's a bit more 
complicated.  'Stunnel' and OpenSSL will be used in the following examples.  The
first step would be to install OpenSSL and all packages and updates and then
on top of that install 'stunnel' (for 'stunnel' to work properly it must have
some sort of SSL library, in this case OpenSSL).  This is where the tricky part
comes in.  You will have to find the file 'stunnel.pem'.  It's located in the
'\system32' folder.  The next part was taken directly from 
stunnel.org and I give full credit to the author of the configuration file as follows:

	[PORT]
	 client = no
         cert = stunnel.pem

	[vnc]
	 accept = 7777
	 connect = 5900

	[VNC Servers]
	 client = yes
	 cert = stunnel.pem

	[vnc]
	 accept = 5900
  	 connect = xxx.xxx.xxx.xxx:7777
	[vnc2]
	 accept = 5901
         connect = 192.168.0.8:7777


	LIBEAY32.DLL	1,379,459 12-31-02	11:54a libeay32.dll
	LIBSSL32.DLL	  476,329 12-31-02	11:54a libssl32.dll
	 OPENSSL.EXE    1,089,536 12-31-02	11:54a  openssl.exe
         STUNNEL.EXE       59,904 01-12-03       4:54p  stunnel.exe
         STUNNEL.PEM	    1,690 02-28-03      12:24a  stunnel.pem

     Once you have this in the configuration file you now must start the
service.  The final step in this process is to load up 'VNCviewer' and put in
the IP address of the machine you are trying to connect to.  You are now
finished and fully encrypted.

Conclusion

     Security should be a concern for everyone, not just the computer savvy
network administrator for some Fortune 500 corporation.  I hope this article
has given you the tools and foresight to secure your remote connection.

     All software was used under Windows, but there are of course UNIX/Linux
versions.

Shouts and Thanks: DigitalX, Somefun, JimmyBones, Decoy_0ct, Poundofflour,
and most of all eagelspeedwell for guidance.

Return to $2600 Index