Expose remote desktop directly to the internet

Question

I have a small server behind my router which runs Windows 10. It's pretty easy to set up remote desktop directly to the internet and expose the required port by changing the configuration of the router.

Question: Do I have to be aware of security issues refering to that? I mean my server is at least accessable by everyone who knows a valid username/password combination.

MS just says

If you want to restrict who can access your PC, choose to allow access only with Network Level Authentication (NLA). When you enable this option, users have to authenticate themselves to the network before they can connect to your PC. Allowing connections only from computers running Remote Desktop with NLA is a more secure authentication method that can help protect your computer from malicious users and software. To learn more about NLA and Remote Desktop, check out Configure NLA for RDS Connections.

Answer 1

No serious network administrator would directly expose an RDP server onto the Internet.

If there are any holes /backdoors in it, not only is it "game over" for part of the system (ie an inflection point/jump box), but it is an opportunity for DoS attacks and fingerprinting desktop(s) on the LAN giving unneccessary information away.

Depending on the RDP server and client, it may also be possible to do a MITM (man in the middle) attack. There are various ways this might be done including forcing a protocol downgrade or relying on insecure cryptography. You might find https://labs.portcullis.co.uk/blog/ssl-man-in-the-middle-attacks-on-rdp/ interesting.

A prudent operator might set up a VPN and only allow remote RDP access over that to provide another layer of security, access management, auditing and control.

Answer 2

Microsoft’s Remote Desktop uses encryption, so communications are therefore reasonably protected. The weak point is that of brute-force attack against your user-name and password.

With the way hackers are continuously scanning the Internet for weak points, and with the number of currently known (and unknown) exploits, it is much better to set up as many protections as you can (but not to the point of over-complicating the access).

To secure RDP you may do the following :

1. Change the default port that Remote Desktop listens on

2. Strong credentials
   Use a non-default user-name and a long and complicated password

3. Restricted user accounts
   Limit severely the users that can use RDP by running secpol.msc and navigating to Local Policies > User Rights Assignment, double-click on "Allow log on through Remote Desktop Services" and remove all displayed groups, then add your one user.

4. High security level
   Run gpedit.msc and navigate to Local Computer Policy > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security and set:

   • "Set client connection encryption level" -> Enabled and High Level, for your sessions to be secured with 128-bit encryption
   • "Require use of specific security layer for remote (RDP) connections" -> SSL
   • "Require user authentication for remote connections by using Network Level Authentication" -> Enabled

5. Set an account lockout policy
   To lock an account for a period of time after a number of incorrect guesses, go to Administrative Tools > Local Security Policy > Account Policies > Account Lockout Policies, and set values for all three options (3 invalid attempts with 3 minute lockout duration is reasonable).

6. keep track of logging into your PC
   Periodically go to Event Viewer in Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManger > Operational, to see login information.

7. Keep a high UAC level

8. Create a VPN server
   You may also go to the length of setting up a VPN server (link), which will add another layer of security.

I have had contact on our website with posters that have implemented all the above points, and that seems like enough protection. With all of these precautions implemented, a brute-force attack becomes basically impossible, so the only remaining threat is some exploit. But as no exploits were ever found in VPN login or in RDP login, I would think that this setup is safe enough.

Answer 3

Sorry I'm late to the party, but I thought for your and other's future reference, you might find my experiences with a related issue -- let's just go with "interesting".

I setup an OpenVPN on a Linux server a while back. Linux has excellent logging features using IPTables (an amazing piece of networking software, BTW). I opened up the SSH port so I could transmit certificates.

That night, I reviewed the logs and discovered an outside actor started to brute force that port within seconds after exposing it on the router. Then, because they knew the account could be locked out after three failed attempts, their bot farm was using the same password, and rotating through account names, preventing the system from recognizing multiple failed attempts on the same account name. Then, because they must have realized that IPTables could block failed attempts from the same IP address, they only tried about six attempts from the same IP before shifting to another computer.

I say bot farm, because throughout the week (I locked out SSH soon after, but kept the port open so I could watch -- I was utterly fascinated) the number of IP's that the source came from was never repeated, every couple of seconds, every minute, every hour of every day -- six attempts and a new IP address showed up continuing from the same alphabetical list of account names.

Setup a VPN. Use certificates, and not account names. And don't expose things like RDP for more than a few hours, even if you do have an awesome system for creating passwords. Don't do it. (BTW, my account name was on his list, just waiting for him to reach the correct password.)

Answer 4

Modeling the threats helps identify defensive measures. It's helpful to compare the threats and defenses to those of web services successfully used on the internet all the time.

Threat: Exploit in the code

• Defense: Prompt patching. This is the same as for most internet services.

Threat: Brute-force password attacks

• Defense: Lock-out after too many sign-ins. This is used by some internet services. This is fine for many sites, but for others, denial of service is a problem, with captcha being a solution. Since plain RDS doesn't support captcha, another defense is useful if lock-outs become a problem.

• Defense: Authenticate client device. Most internet services don't do this because friction-free ubiquitous access is so important, and the defense isn't necessary for a secure system. RDS installations often have few client devices, making client authentication a practical option, which is useful if other defenses are inadequate.

Threat: Weak passwords

• Defense: Device-assisted sign-in. As with internet services generally, the user-facing devices can store the remote sign-in secrets. The device authenticates the user via a low-friction challenge such as a per-device PIN or face recognition. Without the burden of having to frequently enter a cumbersome password, users are more likely to use choose strong passwords.

• Defense: Strong password guidance. The benefit is the same for RDS as for internet services, although presenting guidance may not be practical for RDS, depending on the password change UI available.

• Defense: Multi-factor authentication. The benefit is the same for RDS as for internet services, although for RDS, a complementary service is required.

• Defense: Limit user access. Grant the user least privilege, similar to how on a website each user has limited access to the site's data.

Threat: Compromised client device

• Defense: Multi-factor authentication. Same as above. However, as with internet services, if the device is already validated, the multi-factor check won't be performed.

Threat: Weak protocol versions

• Defense: Configure only support of strong protocols. The web equivalent is disabling old SSL versions.

---

Securing Remote Desktop (RDP) for System Administrators has techniques for implementing many of these defenses.