Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

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.

share|improve this answer
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 '12 at 12:13
    
@ewanm89 Fail2Ban is a great piece of software for handling that. –  Jeff Ferland Jun 7 '12 at 14:08
    
@JeffFerland I add that too, finally turn off password auth use keybased auth instead. –  ewanm89 Jun 7 '12 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. :-) –  Graham Hill Jun 7 '12 at 16:05
    
@GrahamHill Kinda why I added them as a comment not a separate answer. –  ewanm89 Jun 8 '12 at 11:29
show 2 more comments

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

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.