/ BLOG / Here be dragons

The “SBS Diva” very recently posted about unfettered access to port 3389. Incase you need the blanks filled in this would be the default Remote Desktop Protocol (RDP) port, which is used to manage any relatively recent Windows box, 99% of the time.

The general take in the Windows admin world is that open RDP is basically a very bad idea and that you should protect it in some way. I’m not against this as a concept at all, and I want to make this very clear. I do have a problem with most common implementation behind “securing” it.

Despite this in some circumstances it’s not necessarily an option to lock something down down, so the service remains publically open. This doesn’t necessarily mean you’re going to “OMGWTFZ h@x0r3d” within 10 seconds. You are likely to see brute force attempts every now and then, in the instance of RDP, much like you can see people trying to brute force FTP or SSH servers. If you factor this into the equation from the beginning then an open service isn’t necessarily as large a problem as you might imagine.

At the end of the you can make the life for any attacker harder;

  1. Rename any default accounts - Most of the brute force attacks you see use default usernames, be it ‘administrator’, ‘root’ or your name (if the attacker is targetting you specifically).
  2. Employ additional authentication, such as two factor auth.
  3. Use your logs wisely - Setup the server/domain to log any failed logons and then some software to monitor that. Get it to notify you of a significant number of logon failures (lets say 3 consecutive) and then take action. Depending on what firewall, etc. you have available and what you use to monitor the system will vary on what you can do. Simply getting a notification is better than nothing. Tools like fail2ban or denyhosts can be very handy in the Unix-like world, and there’s no reason why similiar things cannot be implemented for other platforms. I can think of various tools that can monitor logs and preform actions on Windows, off the top of my head (although several are commercial).
  4. Change the service away from the default port number - this is security through obscurity though, and eventually someone will probably find it.
  5. Lock it down at the firewall so only specific IPs can talk to the service
  6. Hide it behind a port knocking, or port rotation mechanism
  7. Hide it behind a VPN
  8. Use an IPSec policy to secure any incoming traffic to the RDP port (negotiate and require security)
There are, of course, other things you can do on a case-by-case basis. To my mind the automated monitoring and response is probably one of the better solutions, but I’d be relatively happy to implement the first 4 options, should a client stipulate a need to have something like RDP or SSH wide open.

However, I do have issues with the remaining options and in particular the VPN solution, which a lot of Windows admins rant about and yet use PPTP without any form of quarantine/NAC behind it (i.e. once you’re connected, you’re in). And here’s why; Anything that requires some form of authentication, on a service that is even partially open by default, can be attacked, be it brute force, dictionary, and so on. The tools may not be available but if the protocol, or method of obsfuscation, is documented the tools can be written. Even then the tools can be written with enough time, patience and determination - which has been proven many times over. In the immortal words of a 70s SciFi: “Gentlemen, we have the technology”;

The great thing is that there are various repositories, libraries, guides, search engines, and of course distros which make these things available for everyone, so I’m not sure there’s any excuse. But, it’s really up to you to decide, just how far you want to go to protect any public services and how desirable access to your systems are to an outsider, at the end of the day.