Remote Computing Secured
by Xphile
Remote computing applications are the greatest things since sliced bread but without proper security they can quickly turn into your worst nightmare.
In issue 20: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 Remote Frame Buffer (RFB) 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 as 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 RFB 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 (SSH1 or SSH2) will start.
Next you must manually tunnel all connections using the command line.
Load up CMD.EXE and insert the following command:
-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 vncviewer and connect to: localhost::5901
SSL
If you do not wish to use SSH1 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:
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.