If you would like to read the other parts in this article series please go to:
- Using the TMG Firewall in Azure Infrastructure Services (Part 1)
- Using the TMG Firewall in Azure Infrastructure Services (Part 2)
- Using the TMG Firewall in Azure Infrastructure Services (Part 4)
- Using the TMG Firewall in Azure Infrastructure Services (Part 5)
Introduction
In the first part of this series on how to use the TMG firewall in Windows Azure, I talked about how you might deploy a TMG firewall as a forward proxy server in an Azure Virtual Network. The primary advantage of that scenario was that you could provide forward proxy and web filtering and anti-malware services to external users and not use up any bandwidth on your corporate Internet connection. In the second part of the article I wrote about how you can use the TMG firewall as a web caching server when placed on an Azure Virtual Network.
As a reminder, here are the scenarios I called out in the first part of the article series:
- Web caching
- Web publishing for FTP and HTTP servers
- OWA, ActiveSync and RPC/HTTPS publishing (Outlook Anywhere)
- Remote Access VPN
In Part 2, we discussed web caching scenarios. Now let’s take a look now at some web publishing scenarios.
Web Publishing
For those of you who are new to the TMG firewall, or for those of you who don’t use it as a web proxy server, the TMG firewall is able to do something called “web publishing”. Web Publishing is just another term for reverse web proxy. When you Web publish a web site, you allow users to connect to the TMG firewall instead of the web server itself. When the connection is received by the TMG firewall, it can then forward the connection request and subsequent communications to and from the Web server through the TMG firewall.
Advantages of web publishing
This has several advantages. When you web publish a web server through the TMG firewall, you can do the following:
- Require that users authenticate to the TMG firewall. This prevents anonymous connections from making it to the published web server, which is a huge security advantage.
- Limit access to authorized users. This allows you to set authorization rules to access a web server. Even if the user is able to successful authenticate, that user must be authorized to reach the site – so users must be authenticated and authorized to reach the published service.
- Limit which IP addresses can connect to the site. Even if a user is authenticated and authorized, if the user’s traffic is coming from an IP address that is not allowed to access the published web site, then the connection will be denied.
- Perform application layer inspection. The TMG firewall can check the HTTP protocol stream and block anything that isn’t seen as legitimate HTTP communications. The TMG firewall, being an application layer firewall, is able to block connections that have characteristics that are consistent with some type of exploit.
- Apply IDS/IPS rules. The TMG firewall has the Network Inspection System (NIS), which is a sophisticated IDS/IPS. If the connection attempt contains commands that are seen as potential exploits, the Network Inspection System will kill the connection.
- DoS protection. The TMG firewall has a robust denial of service protection system that will prevent intruders from taking out the TMG firewall. This is especially useful since it will prevent the intruders from taking down the web server with a denial of service attack.
This is just a short list of the advantages of putting the TMG firewall in front of a web server and then using the Web Publishing capability to ensure secure connections to the web server.
Publishing HTTPS
The TMG firewall can publish HTTP, HTTPS and FTP sites. If you want to publish an HTTPS site, you have the option of allowing the SSL connection to be terminated at the TMG firewall. After that, the TMG firewall forwards the connection to the web server as a regular HTTP communication. This is sometimes called “SSL offloading” because it offloads the SSL cryptographic processing off of the web server and thus the web server will be able to handle more requests than it would be able to if it had to do its own cryptographic duties.
Of course, there are those who will argue that when a user connects to a secure web site that there is an implicit expectation of end to end encryption. Therefore, if you are going to take advantage of SSL offloading, you should probably first talk to the legal team in your organization to make sure that you are covered in this area.
You don’t have to perform SSL offloading. You can have the external user connect to the TMG firewall using an SSL connection, and then have the TMG firewall forward that connection as a second SSL connection to the published web server. In this scenario, the user establishes an SSL connection to the TMG firewall. The TMG firewall decrypts the connection, and then establishes a second SSL connection to the published SSL web server. Note that this is a second SSL connection and not a continuation of the original connection established by the client. This means that after the TMG firewall decrypts the initial connection, it will then need to re-encrypt the connection in order to forward it to the web server. This will require the TMG firewall to dedicate more processor cycles to the encryption process, since it will be twice as processor-intensive as it would have been if you had been performing an SSL offload.
In both cases (SSL offload and non-SSL offload) the TMG firewall will be able to inspect the protocol stream. When not performing SSL offload, the TMG firewall has access to the data after it decrypts it, after the connection is received from the user. In the non-SSL offload scenario, the TMG firewall has access to the protocol stream between the time it decrypts the connection it received from the user and the time that it re-encrypts the connection to forward it to the published SSL server. This enables the TMG firewall to perform application layer inspection on otherwise secure connections.
In addition, when the TMG firewall publishes a web server, in both scenarios, the TMG firewall actually impersonates the published SSL web server. This impersonation process is possible because of the common or subject name on the certificate that is used on the “web listener,” which is used to accept the incoming SSL connections from users. The certificate will contain the name of the web server, which is the name that the user uses to connect to the web site (for example, www.isaserver.org is what the user types into the URL box in the browser, and the common/subject name on the certificate is www.isaserver.org). If the user’s computer trusts the issuer of the certificate, then that computer will accept that the TMG firewall is actually web site. I suppose you could think of this as a “trusted man in the middle” configuration.
Publishing FTP
The TMG firewall can also publish FTP servers (You might be wondering: does anyone actually use FTP anymore? But you’d be surprised at the number of people who do). You can publish the FTP server using a Server Publishing Rule, which is essentially a reverse NAT connection to the FTP server and does not involve the web proxy component at all. You can also publish the FTP server by using something called protocol transition. In this scenario, the user establishes an HTTP or HTTPS connection to the TMG firewall, and then the TMG firewall translates that into an FTP connection to the published FTP server.
This allows you to take advantage of the web proxy security features that you get with Web Publishing – such as authentication, authorization and all the other controls mentioned earlier. Note that while you can enable a secure SSL connection to the TMG firewall in this scenario, there is no support for encryption offloading when publishing an FTP server. In other words, while you can have a secure connection between the user and the TMG firewall, the TMG firewall will not support secure FTP between itself and the published FTP server. That would be a nice feature, but it isn’t supported and it doesn’t work.
High availability
High availability is an important consideration for all web publishing scenarios. The good news is that you can take advantage of the TMG firewall’s built in NLB or you can use an external load balancer to support web publishing scenarios. However, when enabling high availability, you will need to use an array of TMG firewalls that represent a single logical TMG firewall to publish the web or FTP site. With the TMG firewall, you can create enterprise arrays or stand-alone arrays. Both of these types of arrays will enable you to have high availability for your published web sites.
Summary
Now that we have a basic understanding of how Web publishing works for HTTP, HTTPS and FTP sites, we can investigate how we might be able to leverage this functionality by putting the TMG firewall in an Azure Virtual Network. However, before we go into that, in Part 4 I’ll cover secure Exchange Server publishing, which is a form of web publishing (for the most part). After you understand these concepts, we’ll get into the rationale for why you might want to put the TMG firewall in Azure and the advantages that will accrue from doing so. We’ll also talk about some issues you’ll need to look out for. We’ll do that in the next article. See you then! –Deb.
If you would like to read the other parts in this article series please go to:
