16

I am looking at needing to expose my Remote Desktop Server (Terminal Services) to be accessed from outside our network. Right now, it can only be accessed from inside our network.

I know it's easy enough to open up the firewall and forward the port.

However, how do I secure the machine itself and what are the best practices around this? My concern is hackers being able to work at breaking into it.

Any best practice guidelines/recommendations would be much appreciated.

Edit:

Question about a product I found:

Filter Incoming RDP Connections by IP, MAC Address, Computer Name and More

Can anyone comment on the security of this? Looks like I could also use it to limit access by machine name/mac? Anyone else used it?

LarsTech
  • 115
  • 1
  • 1
  • 6
me2011
  • 319
  • 2
  • 3
  • 9
  • 1
    I think you are asking not only how to secure this machine and any RDP connection to it, but also how to reduce the risk to the rest of your network should it be compromised. Is that right? – dunxd Apr 19 '12 at 16:49
  • Yes correct, due to how small we are, there is only one RDP server and it does need full desktop access/network resources for the internal users. – me2011 Apr 19 '12 at 17:06

9 Answers9

14

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.

Don
  • 838
  • 8
  • 19
  • 33
  • 3
    +1 for this. I also use RD Gateway with great success, and you need only expose port 443 to the internet for it to work. RD Gateway was not susceptible to that MS12-020 bug from a few weeks ago that threatened RDP. – Ryan Ries Apr 19 '12 at 18:06
  • +1 there are also a LOT fewer bots attacking RD gateways than there are direct RDP. – Grant May 30 '14 at 02:52
8

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 Administrator account, 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.
Shane Madden
  • 114,520
  • 13
  • 181
  • 251
6

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.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
3

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.

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
1

I would suggest the following measures :

  1. Change the port used for remote desktop connection
  2. Don't use generic usernames but a more complicated naming policy
  3. High passwords requirements
  4. Close any other unused port from outside (inbound)

Optional

  1. Use a VPN(CISCO , Open VPN etc) then connect to the server using internal IP.
  2. Use smart card log on if possible
Alex H
  • 1,814
  • 11
  • 18
  • I tend to change the port on the firewall, not on the server (doing it on the server requires changes to the registry). It's usually easier to setup a port forward on the router, and safer (no registry touching). – JohnThePro Apr 19 '12 at 16:12
  • Yap :) , I just said that because some people don't have access or knowledge to user port forwarding . Even though it is recommended not to change registry unless is necessary , I never had any issues . The only issue you can encounter is if you change it to an already used port . – Alex H Apr 19 '12 at 16:18
  • Yea, I mean its not the biggest deal in the world, and anyone who knows regedit is probably smart enough to be careful.... but you can't know that. :) – JohnThePro Apr 19 '12 at 16:19
1

You could run WinSSHD on port 22 and then use the Tunnelier client to create a tunnel for you and automatically open a Terminal services session through the tunnel with ONE click. This also gives you a very nice secure FTP option as well for transferring files.

djangofan
  • 4,182
  • 10
  • 46
  • 59
1

I use ssh port forwarding for these things, and only allow user level, public key based authentication. All users private keys should be encrypted as well. On Windows Putty does this well, and pageant makes it easy for users to load their key. If you don't run any Linux/BSD servers that have ssh by default you can use OpenSSH in Cygwin to do this.

I recommend a dedicated remote shell server with a local firewall blocking things you don't want people remoting into, since allowing port forwarding in SSH is basically opening up any internal server/port to the users you want.

Jon Zobrist
  • 41
  • 3
1

Bitvise SSH is a good free SSH for Windows.

I'd go for a cheap SSL VPN termination from client to Internet gateway perimeter for anything more than casual use (Commercial In-Confidence for example).

The above posts about securing RDP are also good practice and should always be done if you do not wish to share your computers with freeloaders.

will
  • 11
  • 1
0

not really best practice but some random thoughts:

  • keep your system updated - allow automated updates, dont use products that are end of life,
  • use long / complicated passwords for all system accounts
  • i'll get scolded here for suggesting the 'security through obscurity' but it will not do you any harm if you:
    • change the default 3389/tcp port to something else like 26438/tcp
    • add port-knocking [if possible] on the firewall level so that potential rdp user has first to visit some web page and only then can rdp to your server.
pQd
  • 29,981
  • 6
  • 66
  • 109