12

I'm trying to figure out the risks of running RDP over the internet, using two windows 10 professional stations, and if a VPN is absolutely necessary to achieve good security.

From the information I found so far on the net, a leak was discovered in 2012 that allowed the creation of exploits to intercept an RDP session. I understand this leak was closed in the meantime and that you were always protected if you used Network Level Authentication (NLA).

Most other security issues seem to be focused on the client side, i.e. when connecting to an untrusted RDP session with the main purpose of stealing a user's credentials.

If we assume the following situation:

  • Windows 10 Professional used on host and client side
  • Host side with fixed IP, no DNS involved to establish connection
  • NLA used
  • Strong passwords used, changed monthly, Administrator account not active
  • Host machine contains confidential information

Would you not feel comfortable enough? Where do you see the biggest risk as opposed to a connection over VPN? And is there a way to increase security of the RDP connection without resorting to VPN?

vic
  • 546
  • 3
  • 11
  • Can you give us a sense of why you *don't* want to use a VPN? – Graham Hill Nov 14 '15 at 19:05
  • It's not that I specifically don't want to have VPN, I would just like to understand the difference in security and if this difference justifies the installation and maintenance of additional tools. – vic Nov 14 '15 at 21:24
  • main practical risk is likely to be account lockout (assuming predictable usernames), or password re-use (one of your "strong" passwords gets used by a user at another site), + the risk of 0-day/unpatched issues in RDP. Whether these are a realistic concern likely depends on your threat model... – Rory McCune Nov 16 '15 at 12:42
  • 1
    Thanks. Considering that you could have a 0-day risk with VPN, too, and the other two points wouldn't bother me too much, I guess I would not be overly concerned. – vic Nov 16 '15 at 12:52
  • ooh I forgot there's also a small info. leak inevitably when you put RDP on the Internet , which is it'll expose the valid login contexts for the system (e.g. the local system name, the AD domain) – Rory McCune Nov 16 '15 at 13:01
  • Oh, that's good to know, I wasn't aware of that. That makes the whole thing a bit trickier. – vic Nov 16 '15 at 13:03
  • aaand @avid pointed out that if you have NLA configured it probably won't have the leak, so if you do that you may be ok --> has more info. https://technet.microsoft.com/en-gb/library/cc732713.aspx – Rory McCune Nov 16 '15 at 21:18

2 Answers2

5

I advise against exposing internal servers directly to the Internet.

Remote code execution vulnerabilities crop up too frequently for comfort and direct exposure of internal hosts.

That said you can mitigate the risks somewhat with a few steps (these are not alternatives, they are layered complementary defenses):

  1. Perimeter firewall enforcing white list of source IPs specifically to tcp/3389 on the Windows host or hosts
  2. Windows firewall on each of the Windows hosts enforcing white list of source IPs specifically to tcp/3389 on localhost
  3. Either: use Remote Desktop Gateways as bastion hosts in your DMZ that are on a separate domain and put the similar restriction to 1 and 2 between DMZ and internal
  4. OR: use SSH bastion hosts and port forwarding as above if RDG isn't a good option

These steps substantially reduce the exposure to reconnaissance or attack

Alain O'Dea
  • 1,615
  • 9
  • 13
  • Thanks for your advice, Alain, I'll take it to heart. Your second sentence is what I would be most worried about but in terms of frequency, it seems to me that a vulnerability for RDP was only discovered once and it was patched/mitigated. Or am I misunderstanding what you mean? – vic Nov 16 '15 at 12:54
  • @vic that's more of a general concern. I was initially tagging Windows here, but OpenSSL has been hit so frequently lately that it's really a concern for defense in depth regardless of platform to expose internal hosts. – Alain O'Dea Nov 16 '15 at 12:56
  • Any service could be next on the zero day list, so defense in depth, particularly layering, is your best bet for mitigation of risk. – Alain O'Dea Nov 16 '15 at 12:58
  • 2
    I would replace #3 with: using RD Gateway, and this is not optional or a bonus: This is super-important. A whole nice set of security policies can be applied to it, isolate internal hosts properly, good restrictions, etc. This give much of the value of a VPN, without actually using a VPN. @vic should definitely use a RDG, and have the perimeter firewall restrict access to that server alone. – AviD Nov 16 '15 at 21:12
  • @AviD good point. I'll make that change now. – Alain O'Dea Nov 16 '15 at 21:13
  • 1
    Problem in my specific case is that my server infrastructure is all *nix, so while I'd love to use a RDG, it doesn't seem possible at the time. – vic Nov 16 '15 at 21:24
  • @vic no worries. Use SSH bastion hosts and port forwarding then :) – Alain O'Dea Nov 16 '15 at 22:04
  • 1
    @Alain O'Dea - What would your views be on limiting IP addresses that can access services via RDP? How easy or difficult would it be to spoof these? – Motivated Apr 13 '16 at 18:06
  • @Motivated IP spoofing isn't very practical with TCP protocols like RDP unless the attacker is close in. IP lockdown is a reasonable measure as long as you have a very small set of known static IPs. – Alain O'Dea Apr 13 '16 at 20:11
  • 1
    @Alain O'Dea - What do you mean by 'close in'? – Motivated Apr 14 '16 at 05:01
  • @Motivated by close in I meant getting onto the same subnet as the RDP host. Sorry for the jargon :). There's a pretty good explanation of close in attacks here: http://computernetworkingnotes.com/network-security-access-lists-standards-and-extended/types-of-attack.html – Alain O'Dea Apr 14 '16 at 11:20
  • 1
    @Alain O'Dea - Thanks. You mentioned that ` IP spoofing isn't very practical with TCP protocols like RDP unless the attacker is close in`. Is there an authoritative sources that describes this further? I am attempting to convey this to senior management as there is plenty of FUD regarding it. – Motivated Apr 14 '16 at 17:37
  • 1
    @Alain O'Dea - Also, what is your view on RDP over VPN vs IP restricted RDP? – Motivated Apr 14 '16 at 17:46
  • 1
    @Motivated I prefer VPN or SSH for RDP over IP restricted. The protocol itself has been vulnerable to MitM attacks in the past. IP spoofing on the Internet for connected protocols is basically nonsense. Anti-RPF (reverse path forgery) is commonly deployed and prevents the reply packets from traversing routers. Even without anti-RPF the attacker would have to be spoofing an IP on the trusted network via an attack like ARP poisoning. More here: https://www.researchgate.net/publication/244416576_A_Practical_IP_Spoofing_Defense_Through_Route-Based_Fltering – Alain O'Dea Apr 14 '16 at 20:31
2

There are a few ways to protect RDP.

  • Best practice is don't use public port #3389. Translate it to something different. Is the best way to decrease hack attempts.
  • Allow only certain IPs(or range of IPs) address to public IP. Use smart routers. I use mikrotik (http://wiki.mikrotik.com/wiki/Bruteforce_login_prevention) or Cisco.
  • Configure firewall blocking to many attempts. I use third party tools to block the traffic. A free tools is from www.bfguard.com. There are several more but I like this one because it free. This tool analyzes event logs for failed logins and then add IP to windows firewall for blocking.
  • Last as it is more complex but not bad is to setup a VPN. There is few ways to do so.
    1. Use built in windows VPN server
    2. Use your router's functionality. Most of betters routers has it built in to.
    3. Setup separate access server like OpenVPN, Mikrotik, or some linux based....
  • Consider to encrypt your sensitive data using secondary password with bitlocker on secondary drive which could be virtual disk stored on primary disk.
  • Use random username with strong password. You can check your password and username leaked passwords list
Mant
  • 31
  • 2
  • The link you just added gives me a *Could not connect: Network is unreachable* error message. – kasperd Nov 26 '16 at 11:52
  • Turns out `wiki.skullsecurity.org` responds with RST on port 443. But because the domain is dual stack I got a misleading error message from the browser. It never told me about the RST from the server, which is the real problem. – kasperd Nov 26 '16 at 12:11