VNC, Securely: Part 2

In Part 1 of this series, we learned how to set up transparent usage of a VNC desktop both remotely across a network and on a console, via a display manager, in such a way that the same desktop (and its desktop state) is available from both types of locations. In Part 2 we talk about making this ubiquitous access more secure. We'll be using OpenSSH from www.openssh.org, but other implementations of SSH may work as well.

Our goal is to access our VNC desktop in a secure manner from any location. By secure, we wish to have both strong authentication, thus ensuring only authorized individuals can access the desktop, as well as privacy, so that no one can see the contents of our desktop or what instructions we are sending it.

This article will use Linux computers as both the clients and the server. We will concentrate on using the VNC client called vncviewer and the OpenSSH implementation of the SSH Secure Shell protocol.

As per the first article, we have a VNC-based desktop running on our server. We'll refer to this server as "myhost". Also on this server is sshd, the SSH server. On the client we need to have the SSH client, ssh.

Figure 1. What is Going On

As figure 1 shows, we'll use ssh on the client machine to create an encrypted and authenticated tunnel between client and server. Then we'll configure vncviewer to use that tunnel to show the desktop on the client.

Please refer to "The 101 Uses of OpenSSH: Part I & Part II" by Mick Bauer (Linux Journal, December 2000 and January 2001) for proper setup of OpenSSH, if it hasn't been set up already. My Red Hat 7.1 install has it preconfigured.

As described in those articles, you'll want to configure your client system to use either "null-passphrase" keys or an ssh-agent to cache your passphrase. If you prefer use only passwords, you will not be able to automate the SSH tunnel for our remote VNC desktop via a script.

You might be asking "Is VNC insecure?" As always when dealing with security, the answer is "It depends." The factors it depends on are: what is the likelihood of penetration or exploit, and how bad would it be to be exploited?

The VNC protocol is not without its own defenses. It uses a DES challenge-response handshake for authentication, which is better than sending passwords, like Telnet or FTP do. But with the power of today's commodity computers, DES is not very secure against brute force attacks. Besides this, VNC tries to secure only authentication; it does not make the connection private. SSH can do that for us.

Recall from the first article that we configured VNC to start up in the file /etc/sysconfig/vncserver (on an Red Hat 7.1 system). We added this line:

VNCSERVERS="1:jdimpson"(where jdimpson is your own user name).

The number prepended to the user name, 1 in this case, tells the server what VNC session number is mapped to each user.

For each session number, VNC will listen on three different network sockets. If N is the session number, VNC server will listen on 5800 + N for HTTP connections, on 5900 + N for VNC RFB connections and on 6000 + N. This last port allows X applications to connect to the VNC server. So in our case, the ports that VNC uses are 5801, 5901 and 6001.

We want to prevent any connections to the VNC server from a remote or external client. We do want local applications to be able to connect, though. To do this we will use Linux's built-in firewalling utilities. There are currently two such utilities. On my Red Hat 7.1 box, ipchains and iptables are installed. Although iptables is the newer and more powerful implementation, Red Hat seems to favor the usage of ipchains.

If you know something about firewalls, and have already configured your system so that the default input rule is DENY, you can skip this section. But you must make sure that you ALLOW SSH traffic (port 22). Otherwise, you should run the following commmands:

        ipchains -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 5801:5801 -p 6 -j DENY -l 
        ipchains -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 5901:5901 -p 6 -j DENY -l 
        ipchains -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 6001:6001 -p 6 -j DENY -l 

If your server is a gateway to an internal LAN, and you want to allow hosts from the internal LAN access to VNC without needing to use SSH, you can add the flag -i ethX (where ethX is the network interface on any external, untrusted network).

It might be easier (and more secure) to block all ports from 5800 to 6010. Then you can start as many VNC (and X) sessions as you wish, without worrying about reconfiguration:

ipchains -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 5800:6010 -p 6 -j DENY -l

(Note: when I configure firewalling rules and set up a rule for a TCP connection like above, for symmetry I usually also set up a similar rule for UDP traffic. You can accomplish this my running the ipchains commands again, using -p 17 instead of -p 6.)

The flag -l says to log data to syslog, so you can look at /var/log/messages (or similar) to see if it works. Test by using a VNC client (like vncviewer) to try to connect. You should see log messages like those in Listing 1.

Listing 1: ipchains' Log Messages in /var/log/messages Showing Blocked Connections to Port 5901

Now only VNC clients that are running locally are able to connect to the VNC server.

Remember that unless you do something about it, these rules will be put back into place on reboot. Some systems (like Red Hat 7.X) let you save ipchains configurations by running /etc/init.d/ipchains save. Otherwise, see the man page for ipchains-save.

If you use iptables, the rules you want are

        iptables -A INPUT -p tcp --sport 5801 -j DROP
        iptables -A FORWARD -p tcp --sport 5801 -j DROP
        iptables -A INPUT -p tcp --sport 5901 -j DROP
        iptables -A FORWARD -p tcp --sport 5901 -j DROP
        iptables -A INPUT -p tcp --sport 6001 -j DROP
        iptables -A FORWARD -p tcp --sport 6001 -j DROP

See netfilter.filewatcher.org for more information.