Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 1)

If you would like to read the other parts in this article series please go to:

• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 2)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 3)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 4)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 5)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 6)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 7)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 8)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 9)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 10)

Introduction

Outbound access controls are definitely important in securing any corporate network. However, you know that there is a lot more to security than just securing outbound access. In today’s “cloudy” world, one of the essential characteristics of cloud computing that I’ve discussed in my articles about the private cloud over on WindowsNetworking.com is “broad network access”. The concept of broad network access means that users should be able to obtain information in your private cloud from any time, from any location, using almost any type of device – including small form factor devices such as a variety of smart phones and tablets and similar mobile devices, as well. And to be completely consistent in fulfilling the essential characteristic of broad network access, you should be prepared to provide access to devices that you can’t even dream of yet today, but that will be here tomorrow.

Enabling inbound access

This is where inbound access comes in. Inbound access is sometimes referred to an “ingress”. However, some would argue that the terms “ingress” and “egress” imply a certain time factoring and “slowness” to the movement, which I think we can all agree is not the case when talking about network communications that are moving at hundreds or even thousands of megabits per second. However, it doesn’t really matter what we call it, as long as we understand that inbound access is all about enabling external users to access information that’s located on the corporate network.

So how do we enable inbound access from external hosts to resources on our internal network and on our private cloud? In the TMG firewall, there are essentially two ways you can do this:

• Enable Web Publishing Rules that allow connections for web services inbound to servers on your network.
• Enable Server Publishing Rules that allow connections for almost any protocol inbound to servers on your network.

In general, Web Publishing Rules are much more robust and enable higher levels of security for inbound access when compared to Server Publishing Rules. The reason for this is the Web Publishing Rules take advantage of a feature that’s included in the TMG firewall, which is referred to as “reverse web proxy”. When the TMG firewall performs the reverse web proxy function, it actually takes the incoming connection from a remote web client and analyzes it, and then re-generates the request when it forwards the connection request to the published server.

While it might seem as if this is nothing more than something like reverse NAT, it is in fact not the same thing at all. The web proxy service on the TMG firewall is able to manipulate any of the components of the incoming web request because it is actually recreating and sending the recreated request. In contrast, Server Publishing Rules are mostly about reverse NAT, with some security enhancements that are enabled because you can apply a collection of access and security filters to some of the available Server Publishing protocols. This is just one of the differences between Web Publishing and Server Publishing that some folks may have trouble understanding.

What Web Publishing Rules Bring to the TMG Firewall’s Table

We will start the discussion about the differences between Web Publishing Rules and Server Publishing Rules by going over some of the key capabilities that are enabled by Web Publishing Rules. First, Web Publishing Rules are used to publish HTTP, HTTPS and FTP sites. Note that the FTP publishing that is done with Web Publishing Rules is accomplished through protocol transition – whereby the incoming request is an HTTP request and then it is transformed into an FTP request to an FTP server that is being published by the TMG firewall.

So what do you get with Web Publishing Rules in the TMG firewall? Here is a list of some of the more important capabilities:

• Reverse proxy to published Web sites and FTP sites.
• Authentication of users before they reach the published web server to increase security.
• Port and Protocol Redirection to published web and FTP servers.
• You can conserve IP addresses by publishing multiple sites on a single address or collection of addresses.
• You can use advanced authentication mechanisms such as RADIUS, SecurID, One-time Password (OTP) authentication and Kerberos Constrained Delegation (KCD).
• Problematic URLs delivered by web applications can be rewritten by the TMG firewall.
• You can increase security by limiting path access and performing path redirection.
• You have the ability to control the methods that can be used to communicate with the published web server using application layer inspection capabilities.
• Improved performance on the published web server and reduction of network traffic on the intranet by performing reverse caching.
• You can perform source IP address rewrite to suit the routing requirements for your organization.
• You have the capability of scheduling when Web Publishing Rules will be active and inactive.
• Web publishing wizards for Exchange and SharePoint make configuration easy.

In this multi-part series, we’re going to look at each of these capabilities a bit more closely and find out how we can put them to best use in our TMG firewall’s reverse proxy deployments. We’ll start, here in Part 1, with how TMG can perform reverse proxy duties to published Web and FTP sites.

Reverse proxy to published Web sites and FTP sites

As I mentioned earlier, one of the key features of Web Publishing Rules is the ability to reverse proxy the communications that are accepted from a web client located somewhere on the Internet. We can use Web Publishing Rules to accept connections from these clients and then we can forward them to HTTP servers, HTTPS (SSL) servers and FTP servers.

When accepting connections for HTTP servers, you have the option to forward those connections as HTTP connections, HTTPS connections or FTP connections. I can’t think of many scenarios where you would forward an HTTP connection as an HTTPS connection, but it is possible. There are times when you would want to simplify FTP publishing by allowing users to access your FTP site through HTTP. HTTP is much more firewall friendly and you don’t have to worry about issues regarding Active or Passive Mode FTP connections or about whether or not the firewall that the web client is behind will be able to use one method or the other. Instead, they just initiate an HTTP connection, the TMG firewall accepts that connection, and then it converts the connection to an FTP request to the FTP server located behind the TMG firewall. Nice, huh?

One feature that is especially valuable with the reverse web proxy is the ability to accept SSL connections and handle them in a number of different ways. In general, you want to be able to provide the users with the ability to have an end-to-end secure experience. After all, the user established an SSL connection because it carries with it the expectation that the connection will be secure from end to end. However, with the TMG firewall, you can subvert this expectation of end-to-end security by using something that’s referred to as “SSL offload”. When you use SSL offload, you can accept the incoming SSL connection from the external web client and then forward that connection request to your published server as an HTTP request. The goal of this “SSL to HTTP” bridging is that you offload the processing required for SSL on the published web server and therefore you will be able to get more performance out of that server.

If you want to keep the connection secure from end to end, you can do that and still benefit from the TMG firewall’s application layer inspection capabilities. The TMG firewall can do this by using something that is referred to as “SSL to SSL bridging”. When you use SSL to SSL bridging, the TMG firewall will accept the incoming SSL connection and decrypt the connection so that it can inspect the contents for the communication. While Web Publishing Rules to not allow you to use the web anti-malware capabilities that you get with forward web proxy connections, there are a number of controls that are available to you to make sure that the wrong methods aren’t used when incoming connections are made to your web servers. The TMG firewall can check for these when the SSL connection is unencrypted. If the connection passes the checks, it is then re-encrypted and forwarded as another SSL connection to the destination web server. In this way, you get the security benefits of an end-to-end SSL secured connection with the added benefits of application layer security.

Summary

In this first of a multi-part article in which I’ll provide a comprehensive overview of web and server publishing rules, we discussed the importance of enabling inbound access, what the TMG web publishing rules bring to the table, and how TMG can act as a reverse proxy to published Web and FTP sites. In Part 2, we’ll look at how TMG can authenticate users before they reach the published web server, port and protocol redirection to published web and FTP servers, and how you can conserve IP addresses by publishing multiple sites on a single address or collection of addresses.