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.
sudo -i
for a root shell - even if you don't allow ssh access at all. It's a lot more secure to have two passwords (or one password and a key) to get root access.