1

Hello,

I am looking for recommendations on how to secure RDP for access to Windows Servers. MFA sounds like a good start but I’m not sure the best options are to do this. I was thinking perhaps setting up a jump box or bastion host with MFA. Does anyone have other ideas?

23 Spice ups
2

Secure it on the LAN or over the internet - the latter is a bad idea, but you could start by restricting the IPs allowed to RDP to it.

Likewise, with LAN based RDP, you could limit only RDP sessions from the IT users devices (they would also have to be static or on a subnet of their own) as a start to reduce the risks

1 Spice up
3

Avoid direct internet RDP connections if at all possible. For remote users, have them VPN in to access RDP. Most modern firewalls allow for easy VPN setup including MFA access for VPN connection. For access to the RDP itself, you can configure certificate based access (internal certs are fine for this - no need to spend big bucks for NetSol, DigiCert, etc. since these will only be used inside your enterprise) and can even use these certs as part of the VPN authentication.

10 Spice ups
4

We dumped all external RDP access a couple of years ago, there is just so many better options out there. VPN to internal system and then RDP or go with a service like Conectwise with MFA.

5

My feeling is no RDP to the internet, unless you want to do custom ports for the traffic, but if I’m not mistaken, crims can listen on many ports for RDP traffic?

VPN is the way to go. Then I would decide how you want to filter who can connect to the host with RDP enabled. Some good ideas have already been posted.

1 Spice up
6

Bastion host for cloud workloads is great since the portal can be controlled with conditional access/etc. On-prem, VPN into the network and then allow to a jump box as the entry point and then jump from there (rather than allowing all RDP from the VPN network), enforce MFA for the VPN.

7

My first thought was to use a SSH tunnel (don’t ask me for details … it’s something I’ve heard of, but never used myself).

A VPN (as suggested by others) would probably be a better option … just make sure it is setup well. Improperly implemented VPNs can actually be a security hole/risk.

Where I work, we provide remote RDP access via Citrix (is it still called XenApp?).

8

As has been advised, VPN connection first then Remote Desktop access through via the VPN is the way to do remote access.
Any login prompt that you have open to the Internet is easy to find. Doesn’t matter if it is on the standard port or your so-called random one. The script kiddies and the hacker 101 tools will scan the port range.
SSH tunnelling is a technique of locally re-directing a tcp port to port 22 and then passing the traffic on port 22 (ssh’s well-known port) through the firewall. Similar re-directing is done on the local end also. It is convenient, but I would not allow it or recommend using it in a production environment.

9

So there is lots of confusion out there on this topic. When you hear it said that RDP should never be open to the public. What is meant is raw TCP 3389. A Microsoft RDS Gateway, Azure Bastion, a Citrix Netscaler Gateway or VMware Horizon View Universal Gateway all are tunneling technologies. So you can hack the same thing together with a VPN or SSH tunnel. The trick is to do so in addition to some other form of authentication. Restricting by IP is pretty basic but counts. A device or user authentication certificate in addition to password is better. But TOTP or Push Authentication MFA is generally considered best. Duo will integrate directly with the Microsoft RDS Gateway. Or you could use AzureAD App Proxy. These are well established and affordable solutions.

Moreover, beyond setting up and establishing tunneling and MFA you still need to harden your Gateway preferably with a next generation firewall and also your endpoints.

6 Spice ups
10

+1 for VPN 1st.

You forgot to mention whether this was on-premise or cloud.

If On-Premise, I’ve been using Sonicwall UTMs for decades for SMB client VPN’s. You can use the traditional client, or, SSH Client. They work similarily, however with SSH you have the option of creating an easy-to-use landing page for a RDP Bookmark to the desired device.

It looks like you can now actually create Application RDP bookmarks - not just whole-desktop - with the latest firmwares.

https://www.sonicwall.com/support/knowledge-base/how-to-configure-html5-rdp-bookmark-to-access-a-particular-application-instead-of-the-whole-desktop/170502581068724/

11

Definitely agree with everyone, RDP really shouldn’t be open to the Internet and, if for some reason you absolutely have to, change the port and highly audit access with account lockout. But like others have said, even if it’s on a different port it can be found, just not as fast. OP didn’t really say whether he needs to secure RDP internally, externally or both.

Here are some articles on securing RDP (applies to both internal and external):

A VPN is a better solution, but, again, like others have said, just creating a VPN for RDP access is just shifting the security from RDP to the VPN, so you’ll want to make sure that’s done correctly too (auditing, secure passwords, that sort of thing).

IMHO the real problem with RDP is that there are tons of scripts out there that constantly scan IP hosts on port 3389. I’m sure VPNs are scanned too, but not nearly as many as RDP.

12

We don’t allow RDP from the internet. All my users must connect via the VPN first, then rdp into the server via the VPN

13

ours is set up as so.

VPN using OTP

once you are VPN the system knows who you are and we restrict where you can RDP to.

So if i VPN in i need my OTP and then i can only access my PC IP address nothing else. Once i am on my PC i am unrestricted but in order to do that i have to get onto my PC first and only after i have got onto the VPN.

14

I like zerotier for this situation, it creates an encrypted tunnel much like a VPN but its transparent to the user.
It’s also possible to expose LANs over zerotier so is possible to create a WAN.

1 Spice up
15

It’s pretty easy. Keep it patched and require either good password policy (including account lockouts), digital certificate authentication (a feature of RDP), or phishing-resistant MFA. RDP does not have some particular weakness that makes it more or less susceptible to hacking as compared to any other remote access method. Just keep it patched and use a good authentication method. That’s it.

I wrote about this years ago: https://www.csoonline.com/article/3318123/windows-security/experience-an-rdp-attack-it-s-your-fault-not-microsoft-s.html

16

Internet accessible RDP is an exploit/beach waiting to happen.

As others have said, implement on premise VPN. Once the user(s) are connected then allow the RDP connection. Use groups to allow users access. For cloud access, have some MFA set up to allow access to the cloud environment and then groups to specifically allow the RDP access.

17

Change RDP port
Restrict only to user with absolute necessity
MFA for VPN as well as logging in. We use a MFA to connect to the VPN and then to actually log in to a computer we use Okta to verify the user logging in is who they claim to be.

18

I agree there is good value with changing RDP from its default port, TCP 3389. You don’t need to do that to protect RDP…just patch and have secure auth. That’s enough. But changing the port will remove it from all the port scanners that ONLY scan for common default ports and so it gives you some additional risk lowering for low cost. The only problem is that if you change the default port that you have to reconfigure all the RDP listening instances to listen on the new port, tell all the legitimate connecting RDP clients to connect to the non-default ports, and make sure all the firewalls and filters allow the non-default port. I sometimes had problems connecting to my non-default RDP port when connecting from hotels and other sites that didn’t allow non-default ports (or any ports beyond 80 and 443) outbound. But still a good idea.

I really miss the “port knocking” concept back from the early days where every listening service, whether on a default port or not, listened for a specific set of port probes (like a digital lock combination) before the filtering component would allow the eventual connecting to the main defined port for that service.

19

We use DUO MFA for RDP. Every machine has DUO installed but this is only an issue if someone it going to remote into that machine, otherwise they don’t know about it. People that will have permissions are put in a special group that syncs AD with DUO. The only problem is if that server goes down, we can’t use DUO but we’ve mitigated that risk.

20

DUO also has an option to apply MFA when connecting to Microsoft Remote Desktop Gateway avoiding the need to install it on every workstation.