Introduction
I’ve been using Windows based terminal services ever since the Windows NT Terminal Services Edition. In the beginning, it seemed useful, sort of fun, but nothing close to a killer application. Over the years, Terminal Services has changed and matured. Even the name has been changed, to Remote Desktop Services. And over the years I have found it to become more useful with each new version. On my intranet, I find that I do a large proportion of my work on machines that I’m not sitting in front of. Instead, I can sit down at a networked computer anywhere in my home/office, and then RDP into another machine that typically has more power. And with the enhanced support for multiple monitors that comes with Windows 7, and some additional software that enables the use of multiple desktops over RDP, I find that RDP has quietly revolutionized the way I work in my home office environment.
But what about when I’m not at home? My work also involves going on the road, to conferences and events. When I’m working out of a hotel room or convention center or another company’s site, do I lose all the value I get with RDP when I am at home? In the past I would have had to say “yes”. At one time, reliable high speed Internet connections were hard to find. In the typical hotel room even just a couple of years ago (including high dollar hotels), you were lucky if your “high-speed” Internet connection enabled as much as 768Kbps downstream. That isn’t optimal for a high quality RDP experience. But over the last few years, things have changed quite a bit. Now even low end hotels are offering at least 1.5Mbps down, and many of them are providing 3-5Mbps down. With those kinds of speeds, I can take full advantage of RDP when I’m away from home. This gives me access to everything I need – not only on the machine to which I connect over the RDP connection, but also to any other machine on the home network to which I need access.
The challenge
The challenge with RDP over the Internet is security-related. The problem is that the default RDP port (TCP 3389) is a frequently probed port. When an Internet based attacker port scans your IP address, you can be sure that 3389 is on the top of the attacker’s list. That makes sense. If the attacker can get full control of a machine over RDP, then the attacker will have the keys to your kingdom. For this reason, opening up RDP over the Internet can present a serious security risk.
The solution
To help slow down and possible prevent attacks on the RDP server that you’re exposing to the Internet, you can configure the TMG firewall to publish the RDP server on an alternate port. When using the TMG firewall, you only change the port on the Server Publishing Rule; you can leave the default port on the RDP listener on the RDP server. This configuration gives you the ability to access the RDP server using the default port when you’re on your intranet and you can use the alternate port when accessing the RDP host over the Internet.
The configuration
Here are the steps for creating a Server Publishing Rule to publish the RDP server on an alternate port:
-
Open the TMG firewall console and click Firewall Policy in the left pane of the console. Click the Tasks tab in the Task Pane and then click Publish Non-Web Server Protocols.
Figure 1
-
The New Server Publishing Rule Wizard launches, as shown in Figure 2. Type in the name of the rule you want to create. For our example, we will use a friendly name to help us identify this rule: RDP to Server 1. Click Next.
Figure 2
-
On the Select Server page, enter the IP address of the server that you are publishing. In this example, we’ll enter 192.168.0.251. Click Next.
Figure 3
-
On the Select Protocol page shown in Figure 4, choose the protocol you want to publish. In this case, we’ll select RDP (Terminal Services) Server from the Selected Protocol drop-down list, as shown in Figure 5 below. The Select Protocol page is then modified as shown in Figure 6. Click Next.
Figure 4
Figure 5
Figure 6
-
On the Select Protocol page, click the Ports button. You will see the Ports dialog box as seen in Figure 7 below. Notice that you have several options here:
Publish using the default port defined in the protocol definition – this option will publish the protocol using the default port for the protocol. For RDP the default port is TCP 3389, which is not what we want, so we won’t be selecting that option.
Publish on this port instead of the default port – this is the option we want to use in this example, for better security. For example, if we want to publish the RDP server on TCP port 6688, we put 6688 in the text box next to this option.
Send requests to the default port on the published server – this option will configure the TMG firewall to forward the request to the default port for the protocol to the published server. In the case of RDP, that port would be TCP port 3389. We will use this option in the current example. Note that if you wanted to change the default port used by the RDP service on the server, you could configure the TMG firewall to use an alternate port, which we see in the next option.
Send requests to this port on the published server – if the published server is using an alternate port, you can enter the value of the alternate port in the text box for this option. In this example, the RDP service on the published server is using the default port, so we won’t use this option.
Allow traffic from any allowed source port – in most cases, the client side application is going to use some random port number as the source port for the connection to the published server. If you don’t want to control the traffic based on source port, or if you don’t know how to control the source port for the client side application that connects to your published server, then use this option.
Limit access to traffic from this range of source ports – this is a very high security option. When you enable this option, the client must use a specific source port or range of source ports to connect to the server over the Server Publishing Rule on the TMG firewall that is publishing the server. At one time I thought I read that there was a way to configure the source port of the Microsoft RDP client. But I did a search for this and couldn’t find any information along these lines. If you know how to control the source port on the RDP client, then please send me a note and I’ll amend this article to include this information.
Figure 7
-
After making the suggested changes, the dialog box should look like Figure 8 below. Click OK.
Figure 8
-
On the Network Listener IP Addresses page shown in Figure 9, notice all the networks that are available in the Listen for requests from these networks list. You could take advantage of this list by publishing servers on different sections of your intranet. However, in this example, we’re looking at an Internet publishing scenario, so put a checkmark in the External checkbox and then click Addresses.
Figure 9
-
On the External Network Listener IP Selection page shown in Figure 10, you have three options:
All IP addresses on the Forefront TMG firewall that are in the selected network – if you select this option, all the IP addresses bound to the interface that defines the network you selected will listen for connections for the Server Publishing Rule. In general, you will probably want to be more selective and so you won’t use this option very often.
Default IP addresses for network adapters on this network. If Network Load Balancing is enabled for this network, the default virtual IP address will be used – It’s important to note here that the definition of the default IP address has changed for the TMG firewall. With the ISA firewall, the default IP address was the topmost IP address bound to the NIC. That is no longer true. To find out how the TMG firewall defines the default IP address, check out this article on the TMG firewall team blog.
Specified IP addresses on the Forefront TMG computer in the selected network – This is the option you’ll most likely use. When you select this option, you select a specific IP address on the external interface of the TMG firewall that you want to listen for incoming connections to the published server. Select the IP address you want to use from the Available IP Addresses list and then click Add. It will move that address to the Selected IP Addresses section.
In this example, we’ll select an IP address and then click OK.
Figure 10
-
You will see the selected IP address on the Network Listener IP Addresses page shown in Figure 11. Click Next.
Figure 11
-
On the Completing the New Server Publishing Rule Wizard page that you see in Figure 12, click Finish.
Figure 12
Make sure that you click the Apply button to save the changes to the firewall policy before you try to connect to the published RDP server.
The next step is to figure out how to connect to the published RDP server on the alternate port. You can enter the following command in the cmd window:
mstsc /v:<Server>:< Port >
Just replace the <Server> entry with the FQDN or IP address of the destination server and the <Port> entry with the alternate port you configured in the Server Publishing Rule for publishing the remote desktop server.
Summary
The TMG firewall’s Server Publishing Rules provide you with a lot of flexibility when it comes to controlling how connections will be made to published servers through the firewall. In this article, we gave an example of this flexibility by publishing an RDP server on an alternate port. This is a trick I’ve used on many occasions and it works great. If you have a Server Publishing Rule trick that you’ve used successfully in the past and would like to share it, let me know! Send me a note at [email protected] and I’ll share it with the rest of the ISAserver.org community. Thanks! –Deb.
