Publishing Terminal Servers with ISA Firewalls (2004) v1.1


Publishing Terminal Servers with ISA Firewalls (2004) v1.1

By Thomas W Shinder MD, MVP


For more information about Windows Terminal Services, please visit MSTerminalServices.org.


Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=22;t=000054


(WARNING: the first part of this article contains a rant regarding HTTP/HTTPS tunneling. After the rant, we’ll get into the details of publishing a Terminal Server)


As a firewall administrator your primary concern is access control. You want to control exactly what services internal network users can access on other networks, and you want exact control over what services external users can access on the internal network. That’s the reason you have a firewall. If you don’t want someone to access a specific service on the Internet, then you either do not allow it (the preferred method) or you explicitly block it (the less preferred method). This isn’t a radical approach and is something inherent in all good firewall policies.


Get the New Book!


For example, you have created a firewall policy allowing a specific group of users outbound access to only HTTP and HTTPS. You do this because you want this group of users to have access to Web sites on the Internet, so that they can see Web content and connect to secure Web sites to get business done. You do not allow them access to other protocols such as IRC, FTP, SSH, VPN, Telnet or any others, because your organization has determined that these protocols can put your network at risk when used by these users you have given access to only HTTP and HTTPS.


So what happens when a user uses the HTTP protocol to “tunnel” other application protocols? The popular GoToMyPC is a remote access application that the vendor claims “does not compromise the integrity of your firewall” (https://www.gotomypc.com/ourTechnology.tmpl). Oh really?


As a firewall administrator, I open outbound HTTPS to selected users so that they can go to secure Web sites. I do not open outbound access to HTTPS (SSL) so that they can use remote access technologies that enable them to connect to their home computer and then transfer virus infected files from their home computer (which isn’t under our administrative control). And because the GoToMyPC application runs in an SSL tunnel, virtually no firewall on the market today (including the ISA firewall) can inspect the contents of the SSL stream once SSL session is negotiated.


GoToMyPC is just one example of HTTP tunneling of non-Web applications. If you do a Google search of “HTTP tunnel” and you’ll come up with a slew of applications that allow users to subvert firewall policy by tunneling dangerous applications through an HTTP connection.


For example, near the top of the list on the Google search is HTTP-Tunnel. You can see a list of applications your users can use with this software at http://www.http-tunnel.com/html/support/user_guides.asp. As a firewall administrator, you enable users access to applications they have permission to access and they should not be able to use applications that they are not permitted to access. The HTTP tunneling software subverts firewall policy and security, and potentially violates corporate network access policies.



ISA Firewall Alert
If your corporate network access policy does not include explicit guidelines forbidding use of this type of software, then you need to get such as policy in line now. Otherwise, you’re going to be blank-faced when the CEO wants to know how a user was able to introduce a destructive worm into the corporate network by using one of these applications.


So what does all this have to do with Terminal Services? Microsoft has announced that it intends to provide an HTTP tunneled RDP client and server in the R2 release of Windows Server 2003. This purportedly is done to allow for Access Anywhere, so that users can create RDP sessions through “restrictive firewalls”. Maybe there’s a reason why those firewalls are restrictive! (you can find more information on this HTTPS tunneled RDP client over at http://www.brianmadden.com/content/content.asp?ID=61)


The next time you hear someone joke about TCP 80 and 443 being the “Universal Firewall Ports”, you’ll know what they mean. This also points out that the future of firewalls moves far beyond the conventional stateful filtering firewall (like most so-called “hardware firewalls” on the market today).


The future of network firewalls is the stateful application layer inspection firewall. The good news is that the ISA firewall is the poster boy of the stateful application layer inspection firewall. Only a stateful application layer inspection firewall is going to be able to completely take apart the HTTP/HTTPS communications and then validate them against firewall policy. One thing is for sure: its not going to be easy.



ISA Firewall Wish List
Because of the serious risks HTTPS tunneling can pose to the network, on the top of my wish list right now is that the ISA firewall development team implements a mechanism allowing us to perform SSL to SSL bridging for outgoing connections. We can do it now with Web Publishing Rules, but we can’t do it for outbound connections at this time. Those outbound HTTPS connections containing data hiding in the outbound SSL tunnel continue to pose a serious risk to your network’s overall security posture.


Get the New Book!


Publishing a Terminal (RDP) Server using the ISA Firewall


Publishing a Terminal Server is fairly easy using the ISA firewall. There are just a couple basic rules you need to keep in mind:



  • You need to bind an IP address for each Terminal Server you want to publish to the external interface of the ISA firewall if you want to publish them using the default RDP port (3389). For example, if you want to publish the RDP server on the ISA firewall and you also want to publish the Terminal Server on the internal network, then you’ll need to bind two addresses to the external interface of the ISA firewall.
  • If you do not have multiple IP addresses to bind to the external interface, then you can publish each terminal server on a different port. For example, you can publish one Terminal Server on TCP port 9999 and a second Terminal Server on TCP port 8888. You don’t even need to change the Terminal Server’s listening port when using the ISA firewall to publish these sites

I think the second option will be more popular than the first. This option allows you to publish all your Terminal Servers on alternate ports, which gives you a small measure of security through obscurity. This option also allows you to publish hundreds of Terminal Servers through the ISA firewall using a single IP address on the external interface of the ISA firewall.


In this article we’ll publish two RDP servers: the RDP server on the ISA firewall and an RDP server on the internal network. The figure below shows the basic layout of the scenario.



We will cover the following steps:



  • Publish the Terminal Server on the ISA firewall using an alternate listening port
  • Publish the Terminal Server on the Internal network using an alternate listening port
  • Test the Server Publishing Rules by using the RDP 5.1 client to connect to the RDP server on the ISA firewall and on the RDP server on the internal network

Publishing the RDP Server on the ISA Firewall


The first step is to publish the RDP Server on the ISA firewall. I’ll assume that you have already enabled the Remote Desktop on the ISA firewall so that the ISA firewall is ready to accept incoming RDP connections.


Perform the following steps to publish the RDP server on the ISA firewall:



  1. Open the Microsoft Internet Security and Acceleration Server 2004 management console and expand the server name. Click on the Firewall Policy node.
  2. On the Firewall Policy node, click the Tasks tab in the Task Pane. Click the Create a New Server Publishing rule.
  3. On the Welcome to the New Server Publishing Rule page, enter a name for the rule in the Server Publishing Rule name text box. In this example we’ll name it ISA Firewall RDP Server. Click Next.
  4. On the Select Server page, enter the IP address of the internal interface of the ISA firewall in the Server IP address text box. In this example, we’ll enter 10.0.0.1. Click Next.
  5. On the Select Protocol page, select the RDP (Terminal Services) Server option from the Selected protocol list. Click the Ports button.



  1. In the Ports dialog box, select the Publish on this port instead of the default port option in the Firewall Ports frame. Enter the alternate port number in the text box. In this example, we’ll use port number 9999. Click OK.



  1. Click Next on the Select Protocol page.
  2. On the IP Addresses page, put a checkmark in the External checkbox and click Next.
  3. Click Finish on the Completing the New Server Publishing Rule Wizard page.

Publishing the RDP Server on the Internal Network


Now we can publish the second RDP server, which is located on the Internal network. Perform the following steps to publish the second RDP server:



  1. Open the Microsoft Internet Security and Acceleration Server 2004 management console and expand the server name. Click on the Firewall Policy node.
  2. On the Firewall Policy node, click the Tasks tab in the Task Pane. Click the Create a New Server Publishing rule.
  3. On the Welcome to the New Server Publishing Rule page, enter a name for the rule in the Server Publishing Rule name text box. In this example we’ll name it Internal RDP Server. Click Next.
  4. On the Select Server page, enter the IP address of the Terminal Server on the corporate network in the Server IP address text box. In this example, we’ll enter 10.0.0.2. Click Next.
  5. On the Select Protocol page, select the RDP (Terminal Services) Server option from the Selected protocol list. Click the Ports button.



  1. In the Ports dialog box, select the Publish on this port instead of the default port option in the Firewall Ports frame. Enter the alternate port number in the text box. In this example, we’ll use port number 8888. Click OK.



  1. Click Next on the Select Protocol page.
  2. On the IP Addresses page, put a checkmark in the External checkbox and click Next.
  3. Click Finish on the Completing the New Server Publishing Rule Wizard page.

Your Firewall Policy should look like the figure below.



Click Apply to save the changes and update the firewall policy and then click OK in the Apply New Configuration dialog box.


Testing the ISA Firewall Server Publishing Rules


Now for the fun part! Let’s test our Server Publishing Rules. First, you’ll need the RDP 5.1 or RDP 5.2 client. Either one will work. If you’re not using Windows XP or Windows Server 2003, you can download version 5.2 at http://www.microsoft.com/downloads/details.aspx?FamilyID=a8255ffc-4b4a-40e7-a706-cde7e9b57e79&displaylang=en


We’ll connect to the RDP server on the ISA firewall first. Open the Remote Desktop Connection application and enter the IP address on the external interface of the ISA firewall and the port number you configured that Server Publishing Rule to listen on. In this case, its port 9999. It should appear as in the figure below.



It worked!



Now let’s try it with the internal network RDP server. You can leave the connection open to the ISA firewall while you connect. This will demonstrate that these connections do not interfere with one another.



Great! It worked again!



Get the New Book!


Summary


In this article we examine methods you can use to publish Terminal Servers using the ISA firewall. We focused on the ISA firewall’s ability to change the listening port for the RDP Server protocol and used this feature to publish multiple Terminal Servers using just a single IP address on the external interface of the ISA firewall.


I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=22;t=000054  and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

For more information about Windows Terminal Services, please visit MSTerminalServices.org.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top