How to secure a public facing Remote Desktop Server?
Solution 1:
This may be more than what you're looking to do, but here's how we use RDP for remote users who aren't using VPN.
We recently started using the RD Gateway Manager with Remote Desktop Services, a role in Windows 2008. We have it setup to go through our TMG server and directly to a users machine. It uses NLA as mentioned above. The user connecting has to be a member of the right AD group, and a member of the right local group to be allowed access. Depending on how you want it setup, you can connect via a webpage which basiclly opens up mstsc and inputs the proxy setting for the RD Gateway, or you can set the settings on your machine manually so that each time you open it it attempts to go through that proxy. So far it has worked quite well and seems to be secure.
Solution 2:
As recent history has shown us, there are inherent risks to exposing the protocol. But, there are some steps that you can take to protect the system:
- Enforce Network Level Authentication.
- Enforce connection encryption.
- Restrict the users allowed to log in over Terminal Services to the absolute minimum, and don't allow "special" accounts like the default domain
Administratoraccount, or ideally any other high privilege accounts. - Make sure the passwords are strong on accounts that are allowed to log in. Depends on how many users and how your policies look right now, but dumping the hashes and attempting to crack them, upping the limits on password length, or simply educating users are good approaches.
Solution 3:
I strongly suggest using the Remote Desktop gateway service. It gives you a place where you can enforce policies about who can connect to what from where. It gives you a good place for logging, so you can see who is trying to login without inspecting the event logs of the individual servers in your farm.
If you haven't done it already, make sure your account lockout policies are set pretty strong. RDP even with NLA and a gateway give people something to attempt brute forcing passwords. A strong lockout policy greatly make it very difficult for brute force attempts to succeed.
Setup valid SSL certificates on the systems, so the client will notify end users if someone is trying to perform some kind of MITM attack.
Solution 4:
This is not very secure, hoowever, there are a few ways to strengthen security.
Disallow Internet access from that server. Many of the more serious malware attempts to communicate back to their command and control server when it compromises your system. Configuring a firewall access rule to disallow outbound access by default, and a rule to allow outbound access only to internal/known networks and RFC 1928 subnets can mitigate the risk.
Use smart cards or some other type of two-factor authentication. This is typically expensive and found predominately in large organizations, however the options are improving (PhoneFactor comes to mind). Note that requiring smart cards can be done per-server, as an option to configuring it at the account level.
Configure a perimeter network, place the remote desktop server in the perimeter, and use an inexpensive VPN to provide the access. An example would be Hamachi. Note that disallowing Internet access from a perimeter network is also a good practice.
If possible, do not provide a full desktop, but publish the applications that they need. If someone only needs access to a single application, it is also possible to configure an "initial program", which could be a simple wrapper shell that can enforce a logoff when the application closes.