4

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.

1
  • Add a normal user, and use 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.
    – Phil Lello
    Mar 21, 2016 at 20:28

3 Answers 3

5

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.

8
  • 1
    I'd also limit the ranges on the ssh port to IP addresses I'm expected to come from, it doesn't stop a targeted attack but it will at least stop most scripted attempts.
    – ewanm89
    Jun 7, 2012 at 12:13
  • @ewanm89 Fail2Ban is a great piece of software for handling that.
    – Jeff Ferland
    Jun 7, 2012 at 14:08
  • @JeffFerland I add that too, finally turn off password auth use keybased auth instead.
    – ewanm89
    Jun 7, 2012 at 14:14
  • I feel I should clarify that I was trying to answer broiyan's specific question in a focussed way, and so have not mentioned the many other terrible security practices that are clearly going on here. :-) Jun 7, 2012 at 16:05
  • @GrahamHill Kinda why I added them as a comment not a separate answer.
    – ewanm89
    Jun 8, 2012 at 11:29
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).

2

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.,

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .