As you probably all know, new security flaws continue to emerge in RDP for Windows. I have googled and read about this issue, and possible fixes/solutions.

It surprises me that no one mentions, to limit ip-scope in the windows firewall as a possible fix (so that only your ip's can connect to the machine). I guess this is because, for some reason, it is not a good solution (I am no expert).

So my question is, what is wrong with this solution?

  • 1
    Every layer of security, however insignificant, adds to your overall security. The only question is whether it will cause more problems or cost more than it's worth. That said, this makes it more inconvenient to attack you more than anything. – Chris S Mar 17 '12 at 2:24

Part of the reason you're not seeing that advice as a potential fix is that isn't a fix, merely a work-around. By setting up an IP block that way you're limiting the scope to something similar to the scope presented by a VPN server that allows anyone with the right credentials to connect to it. It limits the scope of the vulnerability, but it doesn't mitigate it.

The failure-mode is that one of the trusted IP's will become infected with some badware that has an RDP vuln-scanner on it, and then you're off to the races.

However, limiting the IP scope for the service vastly reduces the exposure this problem presents! Still a good idea.

|improve this answer|||||

Nothing, in the appropriate circumstances. We do it for customers all the time.

The problem comes when you don't realise (or forget) that you've got IP address restrictions in place, and your last (or only) RDP-accessable IP address changes -- suddenly, you're locked out, and you can't fix it (because you're locked out).

We've solved the problem at work by adding our staff VPN ranges (which are RFC1918 and hence not likely to be forcibly renumbered) to the allowed IP ranges on all customer servers, so if a customer gets locked out they can always call us up to get the restrictions changed. We also have remote console access to everything (either via the VM host console, or iDRAC, depending on whether it's a VM or physical machine, accessable only via an out-of-band backdoor network with it's own, redundant, set of VPN-mediated access restrictions).

However, absent an out-of-band mechanism for (re-)gaining access, IP address restrictions always have that risk of locking yourself out completely (and, depending on your circumstances, possibly irretrievably).

|improve this answer|||||
  • Thanks for the reply, and interesting comments. Why do you say that you can be locked out "irretrievably"? Is it not always an option to log-on the console locally? – Eydun Mar 17 '12 at 0:32
  • Walking up to the console would be one of the options for an "out-of-band" access mechanism; in some cases it is not an option (or not a good enough option for restoring access to the system in a timely fashion). – Shane Madden Mar 17 '12 at 0:40
  • 2
    @Eydun: When you're dealing with machines in a remote facility, especially one that isn't staffed 24x7 (or at all), losing your RDP can effectively mean you're dead in the water. – womble Mar 17 '12 at 0:45
  • of course RFC 1918 addresses have their own problems. IP address restrictions should not be based simply on ip addresses numbers – Jim B Mar 17 '12 at 15:16
  • @JimB: Please re-read my answer. I never said that we used RFC1918 for security, merely that they had a lower risk of problems in this scenario because we would never need to renumber. – womble Mar 17 '12 at 21:09

Nothing. It's a great solution if you open your RDP to the internet. Another best practice is to move the internet facing side to a different port (other than 3389).

The only reason I can think of is that folks are too lazy to maintain a possibly changing IP restriction range in the firewall.

RDP is as secure as any other protocol - as long as its managed correctly.

|improve this answer|||||

Nothing- this has been windows best practice since windows 2000 see this article for references on how to set up various levels of isolation http://technet.microsoft.com/en-us/network/bb545651

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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