Who is it for?

People looking to securely connect to remote windows servers using RDS over the Internet.

What is it about?

Discussion about some major threats to Windows servers on the public Internet, various remote access technologies and 3 different solutions to solve the problems.

Threat

As soon as your server is live on the Internet, brace yourself for hackers’ attacks. In figure 1.1, you can see how many login attempts took place in just few hours (even minutes!) after the server went up.

To get a better idea of what can be done to alleviate the risk, first let’s have a look at some common attack vectors:

Dictionary or brute force technique.

The dictionary based attack uses a list of common words (+ some variations), that Sys admins could use as passwords.

For example, one of the words in the list might be jenny and the variations would be jenny1, jenny2, etc… Brute force is basically similar but based on a sequence or randomly generated string. In both cases a program, running on one or more machines, would spend all day trying to login into a server using the login ‘Administrator’ and the generated passwords.

Denial Of Service (Dos) and Distributed Dos (DDos).

The idea of these techniques is to push a server OS or application into overload by blasting too many requests in a very short timeframe. For example, a web server designed to process 150 HTTP requests per second suddenly start receiving 1000/s: this will block genuine web users from connecting to the website until the attack is over. The Dos type of attacks can also target the OS directly (flooding a given remote port with TCP Syn packets,…).

Attacks come in different types and shapes. It is useless to list them all or try to protect against each one. Instead, it’s better to minimize the attack surface and have as few running services and opened ports as possible.

However, there is a fine balance between hardening and server administration: Ideally Sys admins should be able to use RDP/RDS (including drive mapping) on remote Windows server without compromising on security.

The rest of this article will discuss various methods of securely connecting to remote desktop services from anywhere, over the public Internet.

Solution 1: Login, IP and Port Hardening

In this solution we put in place multiple security layers on top of one another. Each layer is protecting one, unrelated, part of the system. The idea here is to limit and confuse hackers: should one layer give in, the hacker is then faced with another and so on… until they eventually get bored, give up and try someone else.

Reducing the Attack Surface:  All services, ports and programs not required on the server should be turned off or closed. For example, if the server has a static IP address, there is no need for DHCP Client services. Same goes for file sharing, printing services, Network Discovery services, etc…

Changing the Administrator Login: All Windows server installations create a default system admin called Administrator. The server admin should create a second sys admin user with all the administrator permissions (part of the Admin Group but you can also export/apply icals from the default one) and disable the default Administrator. Of course, the second admin login should be difficult to guess (don’t use root, too simple!) and the password very strong. You can then delete or disable the Administrator login. Be careful with this approach: some applications/services expect the sys admin Administrator to be there and might fail if not. It is better to remove it from the Administrators Group (Server Manager->Configuration->Local Users and Groups->Groups->Administrators). Make sure you test everything with the secondary login before doing anything with the primary Administrator login. Test, test, test…

Changing RDP Default port: With a default installation, RDS listens for connections on port 3389. Changing the port will force anyone who is trying to connect to use the new port. Bots and other scanning programs expecting RDS/RDP connections on port 3389 will be fooled into thinking no RDS is available on the server. Choosing a random big port number (say 43652) is even better: Not only the number will be difficult to guess but also the scanning will take longer and hopefully your hosting provider will have some port scanning defenses in place that will block the scanning in time.

How to change RDS listening port: This can be done via the GUI (RemoteApp Manager->RD Session Host Server Settings) or the registry (requires a restart of the Remote Desktop Services service). The key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp -> PortNumber. (More info at http://support.microsoft.com/kb/2477176 . Note that, as of this writing, the registry key is wrong in the MS article. Use the one above). Remember to disable the predefined firewall rules for Remote Desktop (TCP-In) and replace them with new rules allowing the new port.

How to connect RDC to a different port: mstsc.exe (both the GUI and the command line) take the server name as <server[:port]>. By default, 3389 is assumed when connecting to a server; to connect to a different remote server port, add the “:port” after the server name. For example, to connect to remote port 47856, use servername:47856 in the RDC window. From a console window, use mstsc.exe /v:servername:47856

Restrict access to RDP by IP: You can greatly improve your server defenses by limiting inbound connections to a list of authorized IP addresses only.  If you access your remote servers (say for administration, backup, monitoring, etc…) from a few locations, then you could restrict RDS (and other services) to a know list of IP Addresses. This is the most important and effective security layer you can have in place, second only to blocking everything on the server (or using Vedivi)!

There are few major caveats to this approach:

• The IP addresses you are connecting from (or at least some of them) MUST be public and static to avoid locking yourself out of the server.
• You won’t be able to remotely connect to your server from an unauthorized location (for example, using a laptop from an airport or hotel).
• It will quickly become tedious to update the list of authorized IPs when the server is used with the Remote Desktop Services role installed and configured for mobile users. It might work ok when setting up connections from another physical location like a branch office (preferably with a static public IP address) but it will be nearly impossible to manage connections from hotels, homes or other public places

Solution 1 - Conclusion

This method is interesting because it adds independent security layers which you can choose to implement depending on your business requirements and does not need additional software. The benefit of not having to install anything extra is dwarfed by the manual settings changes and connectivity restrictions. This solution works best when you have a couple of servers to manage, with limited access requirements and static public IP addresses in your office(s). Anything different and it all start going downhill.

Solution 2: SSH tunneling - PuTTY

The tunneling idea is to allow applications on your local computer to indirectly connect to a remote server. Tunneling can happen at the network level (For example via a site-to-site virtual private network) or at the connection level (port forwarding). Creating a VPN between your office and each remote server is somehow unrealistic (unless all your remote servers are on a remote Lan or vLan). On the other hand, tunneling RDP (or any other application) is pretty simple once you understand the concept.

In a classic Client/Server connection, the Server listens for connections on a specific port (25 for SMTP, 80 for HTTP, 3389 for RDP, etc…). The Client application opens a direct connection to that port and start exchanging data. Tunneling and port forwarding work by adding an extra player sitting in the middle (acting as a router). This is similar to how TCP/IP packets are forwarded all the time on the Internet or your private network, the only difference is that the Client application does not connect to the remote Server’s DNS name or IP address anymore but uses localhost or 127.0.0.1 instead. The new connection flow works as follow:

• The Client application connects to localhost on port X
• The Tunneling software accepts the connection on port X and start NATting packets
• The Tunneling application creates a secure tunnel with the remote server
• On the remote server, a connection from/to localhost is created on port X with reverse NATting
• Data packets are forwarded back and forth between the local and remote computers

What do You Need?

In this article, we chose PuTTY as the SSH Client and CopSSH as the server but there are plenty of other free and commercial software that you could use.

Below are small excerpts from both softwares’ website:

“Copssh is an OpenSSH server and client implementation for Windows systems with an administration GUI. It is a yet another packaging of portable OpenSSH, Cygwin, some popular utilites, plus implementation of some best practices regarding security. You can use Copssh for remote administration of your systems or gathering remote information in a secure way.”

“PuTTY is a free implementation of Telnet and SSH for Windows and Unix platforms (including a xterm terminal emulator). It is written and maintained primarily by Simon Tatham.”

Both have a small memory and disk footprints, low maintenance time and are pretty straight to install and run (PuTTY is an exe file, no install required).

How to Setup?

First, install the OpenSSH server on your Windows server. Most of the steps from Solution 1 above should be applied before you continue, i.e.:

• Reducing the Attack Surface
• Changing the Administrator Login
• Changing SSH Default port (Default 22)
• Restricting access to SSH by IP

By default, the sys admin user authentication (or password authentication) is enabled on the SSH server: the username that was mapped during the installation can be used to test the connection (tunnel) from a local machine.

Ideally, and for extra security, the SSH server should accept Public Key Authentication only. The password authentication method should be disabled as soon as the PKA one is setup and tested. This way, nobody can connect to the SSH server without providing the private key, no matter how hard they try (private keys are impossible to guess in a normal lifetime under normal conditions). The other advantage of the PKA is to increase security when restricting access to certain IPs is not possible (either for technical, practical or business reasons).

How does it Work?

We will show how to setup PuTTY to forward a specific port and connect using RDC to the remote server via a SSH tunnel. The principle is the same for any other application. The steps for Remote Desktop Connection are:

1. Setting up the SSH Client to forward a specific port

When the application port exists locally (for example RDP is available on the local machine on port 3389) we have to choose a surrogate port to connect to and to forward from. If the application is not running on the source PC, say telnet or ftp, the same port can be used. For RDP, we map (port NATting) port 13389 on the local machine to port 3389 on the remote server as shown here:

Snapshot.jpg

2. Start RDP with localhost:port as the server name

PuTTY starts listening as soon as the SSH tunnel is established and stops when the tunnel is broken or stopped. The same goes for any forwarded traffic. Once the SSH tunnel is up and running, start the RDC window. In our example, to connect to the remote windows server, we use localhost:13889 :

RDC.jpg

The chain of events from the time we press the “connect” button is:

1. RDC opens a socket to localhost on port 13889
2. On the local machine, PuTTY accepts the socket and forward the open socket request (TCP Syn packet) to the SSH server on the remote windows server via the secure SSL tunnel
3. The SSH server opens another socket to localhost (this is the remote server now) on port 3389 with the original TCP Syn packet
4. Encrypted data then start flowing between the Remote Desktop Client and the Remote Desktop Services service (or Terminal Server)

Note that the local port on the source computer (13889 in this example) can be any number that is easiest to remember or use: It doesn’t have to be a big random number because PuTTY listens on the loopback address only. Remember to allow any used port on your firewalls.

Solution 2 - Conclusion

The SSH tunneling method adds more security and flexibility compared to solution 1. With little setup on the client side, PuTTY can forward multiple ports at the same time, without changing the SSH server; this increases the number of applications accessible on the remote server without opening any more ports on the public NICs.

To avoid disconnections in RDC and other applications, you have to maintain the SSH tunnel opened at all times; if nothing is forwarded for a while, the tunnel might timeout and you will lose all connections. Also, adding new forwarded ports requires restarting the SSH session and tunnel.

The learning curve for the SSH tunneling solution is pretty steep (some Unix/Linux experience could help a lot here) but once you get around the initial install, configuration and testing, the rest is quite straight forwarded (but still manual though…).

Solution 3: Windows Servers 2008 – Secure Access using Vedivi

Vedivi is based on the concepts of tunneling and virtual private networking using outbound connections only. It also follows the multi-layer security methodology by leveraging Windows Authentication and security.

The Vedivi website acts as a virtual Remote Desktop Console, automatically listing all the Windows servers that are accessible directly using Remote Desktop Client (RDC).

The advantage is that the console is always up to date:  every new server automatically updates the list (when the server on, off or decommissioned). If there are multiple servers on the same remote LAN or vLAN, you can also manually add RDC connections to the online console without installing Vedivi on each. Running Vedivi on a server gives access to the whole remote network at once.

Insert image of web console.jpg here

How to setup?

Install Vedivi on the server you want to access remotely. During installation, choose “Server Mode” and proceed to the next steps. The Full Mode allows you to use the Vedivi console on the server to create a full blown VPN to another server. This is not what we want here. In “Server Mode”, you can install Vedivi and start using it without restarting the remote server. Once the installation completes, sign-in to the console with your Vedivi credentials. Vedivi runs as a service, so unless you change your Vedivi password, you won’t need to bother about the console anymore.

Once Vedivi is up and running on the remote Windows server, fire up your favorite web browser on the local machine, sign-in to your Vedivi online account. After few seconds, your remote server will appear under “My Computers”.

Click on the server you want to RDC to, put your Windows credentials and connect. That’s it!

How does it Work?

Vedivi takes care of the connectivity between your local computer and the remote servers. All connections are outbound at both locations, so that no public IP address, port opening and NATting are required.  All connections are SSL encrypted directly between your local and remote machines: only the sender and receiver can decipher the data.

Once Vedivi is installed on a server, you can go ahead and harden your server: close all the unused ports in the Windows firewall (for the public and domain profiles, including RDS), stop the unused services, etc…

The Vedivi credentials and the remote server’s are completely independent. Vedivi integrates on top of Windows security layers: You must have proper Windows credentials to be able to open a RDS session, including a valid login/password, compliance with the Network Access Protection, NAP, if enforced (Network Policy Server, Health Registration Authority, HCAP, etc…).

Solution 3 – Conclusion

Vedivi is the best way to connect to remote Windows servers over the Internet. Installing Vedivi takes few seconds: no extra setup and configurations, you are ready to go in minutes.

Another advantage, other than simplicity and security, is the centralization of your remote access in one place. All the remote servers are accessible directly from the Vedivi website the remote desktop.

The downside is that Vedivi must be running on at least one server per network. The upside is simplicity and security.