How should I defend against TightVNC brute-force attacks?

Question

How should I defend against this type of attack? This is a tightvnc logfile excerpt from a linode cloud server running Ubuntu 12.04 (Precise) with the ubuntu-desktop package added to the bare server. By default this Ubuntu linode cloud server has exactly one user named root. No other users will ever be needed for this server and sudo is considered to be inconvenient. This server runs exactly one application for a very small anonymous business. When running, the application talks unattended through a socket/port over the internet. The viewing of application results occurs through an SSH tunnel for VNC. Light administration occurs via ssh, sftp, scp and rsync with SSH.

The IPs shown in the excerpt are not the IP of the legitimate client.

05/06/12 20:07:32 Got connection from client 69.194.204.90
05/06/12 20:07:32 Non-standard protocol version 3.4, using 3.3 instead
05/06/12 20:07:32 Too many authentication failures - client rejected
05/06/12 20:07:32 Client 69.194.204.90 gone
05/06/12 20:07:32 Statistics:
05/06/12 20:07:32   framebuffer updates 0, rectangles 0, bytes 0

05/06/12 20:24:56 Got connection from client 79.161.16.40
05/06/12 20:24:56 Non-standard protocol version 3.4, using 3.3 instead
05/06/12 20:24:56 Too many authentication failures - client rejected
05/06/12 20:24:56 Client 79.161.16.40 gone
05/06/12 20:24:56 Statistics:
05/06/12 20:24:56   framebuffer updates 0, rectangles 0, bytes 0

05/06/12 20:29:27 Got connection from client 109.230.246.54
05/06/12 20:29:27 Non-standard protocol version 3.4, using 3.3 instead
05/06/12 20:29:28 rfbVncAuthProcessResponse: authentication failed from 109.230.246.54
05/06/12 20:29:28 Client 109.230.246.54 gone
05/06/12 20:29:28 Statistics:
05/06/12 20:29:28   framebuffer updates 0, rectangles 0, bytes 0

This is a problem because eventually tightvnc rejects a new legitimate client session and reports that there were too many authentication failures when the legitimate client tries to do a VNC session. The workaround is to reboot and reloading tightvnc on a frequent basis.

Answer 1

Since you're only accessing VNC over a SSH tunnel, just close the VNC port at the firewall and drop every connection attempt coming from outside.

Answer 2

has exactly one user named root. No other users will ever be needed for this server

Firstly, I'd be very suprised if there really is only one user - more likely that this is the only one you know whom has a login account. If you're in the slightest bit concerned about security/availability then this should be very high on your list of things to address.

The viewing of application results occurs through an SSH tunnel for VNC

But it looks like people are trying to access the VNC server without using the tunnel - so you've got no (effective) firewall in place, and you've configured the vnc server to allow such connections. Not all versions of VNC allow you to configure access by IP address, and it's implemented in different ways - so as a minimum, you should start by blocking the VNC ports for anything other than 127.0.0.1 using iptables. Ubuntu provides a very simple tool - gufw - for setting up your firewall.

You should also take measures to restrict ssh access - restricting access to a whitelist of networks, running fail2ban or using port knocking are simple solutions (but the latter is difficult to integrate with gufw).

Answer 3

I would use DenyHosts to block attempts after X amount of attempts, etc. It can be configured to block all services, not just SSH and it's simple to install. That is, if you think you are being targeted but its a good idea anyway with useful logs.,