Considerations for Replacing your TMG Firewall (Part 1)

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

• Considerations for Replacing your TMG Firewall (Part 2)
• Considerations for Replacing your TMG Firewall (Part 3)
• Considerations for Replacing your TMG Firewall (Part 4)
• Considerations for Replacing your TMG Firewall (Part 5)

Introduction

Now that Microsoft has officially announced the impending demise of TMG, I’ve received a lot of mail from people who want to know what they should use to replace it when the time inevitably comes. This got me thinking about how my relationship with firewalls started and grew. When Tom and I got started in the IT business, back in the 1990s, we didn’t know much about firewalls.

If you’re old like me, you’ll recall that back in those days, you had to learn just about everything from books and magazines. Sure, you could get a formal education in computer science, but that didn’t necessarily give you a lot of practical knowledge that you could apply as an IT pro. Security was barely even on the radar for most home users and even many businesses. AOL was all the rage during that era and the idea of general public access to the Internet was a new thing. The Internet was something you might use if you worked in the military/federal government or an institute of higher education, or if you were an ubergeek hobbyist. The vast majority of home and even business computers weren’t networked to anything off their premises, and the only access they had to non-local networks was through a POTS line to an ISP or to AOL or some similar service.

A short journey through time

It’s scary to think about the things we did back then and the security ramifications if we did things the same way now. One of our first customers was a small head-hunting business and they had a thick net network that they used to connect the computers in their office to each other. They eventually wanted to connect this network to the Internet. All the machines on this network had public IP addresses and they were connected to the Internet using a router. There was no firewall, no NAT device, just a router! And that was pretty much standard operating procedure. Thank goodness that those were the early days of the Internet, before there was widespread distribution of viruses, Trojans, worms, bots and all the rest.

The first time we connected our home office network to the Internet, we did it through the Windows NT RRAS service. There was no firewall installed on the NT 4 Server, just the RRAS NAT service. There weren’t even any packet filters configured in the beginning – and it was running the server service and whatever other services were enabled by default in those days. I guess the old saying is true, that God takes care of fools and children; otherwise that server would have been hacked in no time. But it was a kinder, gentler, more innocent time – at least online.

Fast forward to 2012. Things have changed quite a bit. Everyone has some kind of network, even home users in one-person households. And just about everyone has a firewall of some kind installed to protect their network. Most people also have host based firewalls installed on their individual computers. There are firewalls and packet filters everywhere. And that’s a good thing, because there are many cybercriminals and a lot of malware out there, just waiting for the chance to compromise your computer.

End of the edge?

People keep predicting the end of the edge firewall, citing the blurring of boundaries between internal and external systems and the disappearing perimeter. It’s true that security is moving inward, focused more on systems and data resources and less on the network as a whole. But most of us wouldn’t be very comfortable taking down that wall completely and relying only on host-based security mechanisms.

Given, then, that we still need a network firewall, what are we going to do about the fact that the TMG firewall is hurtling toward its personal end of days? There are many good reasons that we all made a commitment to the TMG firewall instead of some other choice, and now we’re going to have to think about those reasons again, as part of the process of investigating our current options and deciding what we’re going to use to replace the TMG firewall in the future.

Feature focus

The first step is to determine which features and functionalities can be categorized as “much have” in your firewall. This may differ somewhat from one organization to another, based on your usage and the level of security you need. However, I think the following features are critical to most businesses for any replacement you might be thinking about for the TMG firewall:

• Inbound SSL Bridging
• Outbound SSL Bridging – SSL inspection
• Pre-authenticating Web Proxy
• SSTP VPN Server – remote access client VPN server
• Site to Site VPN server
• Winsock Proxy
• URL Filtering
• Web Antimalware
• Multi-ISP connectivity
• Network Load Balancing – HA support

Let’s take a look at each of these in a little bit more detail.

Inbound SSL Bridging

The TMG firewall, like the ISA firewalls before it, is able to terminate an incoming SSL connection and then forward the SSL connection to a published server. The TMG firewall is able to do this because it can be configured with a certificate that has the common name (subject name) of the published web server. The clients connect to the TMG firewall using that name and terminate their connections to the TMG firewall’s external interface.

The TMG firewall is then able to decrypt the session and inspect the contents of the communications. If the TMG firewall finds something wrong with the connection, it can drop and disconnect the host. This type of inbound SSL inspection significantly increases the level of security that the TMG firewall can provide.

After the TMG firewall inspects the incoming communications and finds that there are no problems, it will then forward the communication to the published web server by establishing an entirely new SSL session with the published web server. The published web server then responds to the TMG firewall over the SSL sessions, and the TMG firewall can inspect this response, since at that point the session is decrypted. Then it re-encrypts the connection and sends the response to the client over the Internet.

The ability to terminate the inbound SSL is useful not only from a security perspective, but also from a performance point of view. The reason for this is that you don’t have to forward the connection to the published server as an SSL connection. Instead, what you can do is have the clients connect to the external interface of the TMG firewall using an SSL connection and then forward the connection as an unencrypted HTTP connection. In that way, you offload the SSL processing on the web server, which can help with the web server’s overall performance.

The SSL offloading capability is quite useful when you have heavily loaded web servers. However, I have always been wary of this configuration. That’s because, when a user connects to an SSL site, that user expects to have the session encrypted from end to end. If you perform SSL offloading, then that implicit agreement you have with the user will be broken. If the HTTP session is somehow compromised, then there may be issues you will have to deal with regarding breaking that implicit agreement. If you do choose to use SSL offloading, make sure to check with your legal department about potential implications and liabilities.

Any replacement for my TMG firewall is going to have to support inbound SSL bridging. In addition, it will need to support pre-authentication for those sessions, too. I’ll talk more about that later in this article series.

Outbound SSL Bridging – SSL Inspection

Outbound SSL bridging is similar to inbound SSL bridging, but in this case the clients are behind the TMG firewall instead of in front of it. What happens in this scenario is that the web proxy clients on the internal network send outbound requests to SSL servers on the Internet. The TMG firewall then impersonates those servers by dynamically creating certificates that have the common/subject name of the destination web server. This essentially creates a trusted “man in the middle” situation. As the man in the middle, the TMG firewall is then able to decrypt the connection, inspect it, and then re-encrypt the session and forward it to the SSL web server on the Internet. When the SSL server on the Internet returns its response, the TMG firewall decrypts the session, inspects it, and then returns the response to the web proxy client on the intranet.

Outbound SSL bridging is a critically important security feature. As with VPN connections, most firewalls are not able to inspect the contents of an SSL connection. That’s why a many organizations don’t allow outbound VPN connections from their networks; after all, the firewall can’t protect the network if it can’t inspect the contents of the session. The same is true for SSL connections. Unfortunately, SSL’s default port TCP port 443 is known to be one of the “universal firewall ports” and it’s set to allow outbound traffic by default on most of the firewalls in the world.

This creates a dangerous situation, because malware writers are aware of the situation and will code malicious software to “call home” over an SSL channel. Since the firewall isn’t aware of what’s taking place inside of the SSL session, the malware can upload private information and download other exploits from a SSL server on the Internet. Therefore, it’s imperative that we have some way to inspect these sessions.

The ability to inspect SSL sessions was introduced with the TMG firewall. Previous ISA firewalls did not have this ability. I see this as a key requirement for any firewall that will replace the TMG firewall in my network environment.

Summary

In this article, Part 1 in a series, we started out with a small trip down memory lane and discussed how the world has changed from one I came from, where you could consider putting a NAT server on the edge of the network without any type of firewall in front of it or even on the NAT server itself. We discussed how firewalls now are not only required at the edge of the network, but on all networked devices themselves. Then we got into the core of the issue by beginning a discussion on what I believe are the key feature requirements for any firewall that might take the place of the TMG firewall in the future. In the next article in this series, we’ll continue our discussion of the features that our next firewall is going to need in order to fully replace ourfo current TMG firewall. See you then! –Deb.