Product Review: Collective Software's ClearTunnel
Product: Collective Software's ClearTunnel
Product Homepage: Click here
Why do you have a firewall? Most of us would say that it should do two things:
- Prevent inbound connections from bad guys
- Prevent outbound connection to bad guys
While historically “hardware” firewall admins focused on preventing inbound connections from bad guys, they’ve completely ignored a more important threat – outbound connections from users on the corporate network to dangerous, malicious and productivity draining sites that allows them to download malware and other mobile malicious code on to your network.
Today, most firewall admins are aware that they need both strong inbound and outbound access control. So what do they do? Set strong firewall policies to prevent users from going to dangerous sites, purchase Web filtering software, and prevent users from downloading malware by using Web anti-malware products. You can do all of this with the ISA Firewall, so you would expect that when you have your ISA Firewall in place, with Web and AV filtering adds-on installed, you’d be secure.
But are you?
Not likely. Why? Because one of the primary channels for downloading malicious code is the SSL tunnel. To put the dangers of SSL tunnels in context, consider the following:
- Why do you think that savvy firewall admins prevent outbound VPN connections? It’s because they know that anything moving over the VPN channel can’t be inspected and VPN users can easily download exploits to your network.
- Why do you think admins put glue in the USB ports on a machine? To prevent data leakage and to prevent malicious code from being copied from removable USB devices.
- Why do you think security admins pull CD ROM drives from employee computers? To prevent data leakage from CD burning and to prevent copying malicious code to the network from infected CDs.
- Why do you think modem ports are pulled from corporate computers? To prevent users from connecting to the Internet through an unmonitored link.
- Why do you think employees get fired for setting up rogue wireless access points? Because rouge WAPs can allow groups of users throughout the network to connect to a PC that is using an out of band channel to connect to an uninspected Internet connection.
The point is that you need maximum control over what comes into and what leaves your network, regardless of how data is moved. There are two requirements for this control:
- You need to control the access points.
- You need to be able to inspect anything moving through network access points, especially the Internet connection.
The SSL Security Hole
While you might have done everything you can to control all the access points (glue up the USB ports, prevent VPN connections, etc) and set up application layer inspection on your ISA Firewalls, you’re still flying blind when it comes to SSL. The reason is that everything moving over an SSL tunnel is completely hidden from the firewall. And because it’s hidden, viruses, worms, and worse can move through that encrypted SSL tunnel.
Not only does the SSL security hole expose you to risks from downloaded exploits, but perhaps even great risks due to data leakage. Users can upload sensitive documents, personally identifiable information, and other types of information that is under regulatory control. Allowing uninspected outbound SSL connections can put your entire company at risk of regulatory non-compliance and hefty fines.
Another big problem companies have is employee access to bandwidth and productivity wasting sites. Access to Skype, rogue Internet Web proxies, gtalk and many other time wasting and potentially dangerous applications tunnel themselves over an encrypted SSL link, again leaving your firewall helpless to protect you against these services.
The ISA Firewall protects you from the dangers of an SSL security hole in Web Publishing scenarios. The ISA Firewall’s SSL to SSL bridging is available for inbound Web connections to published Web servers. We can do this for inbound connections because the ISA Firewall is able to impersonate the Web servers you’re publishing. Since the external clients’ SSL sessions are terminated at the external interface of the ISA Firewall, the ISA Firewall is able to decrypt the SSL tunnels, examine the data, and then encrypt the data again and send it back and forth to and from the published secure server on the corporate network.
Enabling the ISA Firewall to inspect the contents of outbound SSL sessions is a more complex problem. It’s easy to configure the ISA Firewall to support inbound SSL bridging because we know the names required on the certificates. In an outbound scenario, we have no idea which sites will be accessed, and thus we can’t create all the possible certificates required to allow the ISA Firewall to impersonate the destination secure Web server.
The solution to the problem is Collective Software’s (www.collectivesoftware.com) ClearTunnel. What ClearTunnel does is create Web site certificates on the fly so that the ISA Firewall can impersonate any SSL site the user might connect to. Since Web Proxy clients actually terminate their initial client requests at the ISA Firewall’s internal interface, it’s possible for ClearTunnel to intercept these requests and decrypt the contents of the outbound SSL tunnel. This enables the ISA Firewall to inspect the contents of the session before re-encrypting the connection and forwarding it to the destination secure Web server.
But in order to make this work, it requires a lot of complex configuration on the ISA Firewall so that it can act as a subordinate CA. Do we really want to do all of that? Is it possible that ClearTunnel is good enough so that the ISA Firewall admin doesn’t have to make it an avocation to get it up and running?
Let’s kick the tires on ClearTunnel and see if it actually works and how much pain it takes to make it work.
Preparing for the Installation
There’s not a whole lot you need to do in terms of preparation in order to get ClearTunnel up and running. The most important issue is that you have a certificate server up and running so that you can request a certificate for ClearTunnel to use. This is critical since ClearTunnel needs a certificate to act as a subordinate CA that can create certificates on the fly when users connect to SSL sites.
Most of you are probably already using certificates for your OWA and other secure Web Publishing Rules, but you might have received those from a commercial certificate authority. Commercial certificate authorities are fine in your publishing scenarios, because most of your external clients aren’t domain members, so you really need a commercial certificate on your ISA Firewall for Web Publishing Rules to prevent error messages when connecting to your sites.
However, in the case of outbound SSL bridging, which is what ClearTunnel does, you need to have at least one certificate server online. Preferably, you’ll have an enterprise CA running on Windows 2003. You don’t need some kind of complex PKI with multiple levels of certificate servers and offline root CAs. You don’t need to get lost in the magico-mystical world of PKI terminology, most of which doesn’t make sense to mortal men. To get ClearTunnel to work quickly and easily, just install a single enterprise CA on a domain member computer. I guarantee that there’s nothing to be afraid of and that installing an enterprise CA has never broken anyone’s network. And it only takes a minute to install the enterprise CA and you don’t even have to configure it. The enterprise CA will just work.
Just as important is getting the root CA certificate on all the client machines. The client computers connecting to the Internet through the ISA Firewall that’s running ClearTunnel will need to trust the certificates created by ClearTunnel. You don’t have to worry about it if you installed an enterprise CA, because all your domain member machines will have that certificate installed automatically. You might have to wait up to 90 minutes, or you can restart your machine if you’re impatient.
Once the enterprise CA is up, the root CA certificate for your enterprise CA will be automatically installed on all domain members, including the ISA Firewall. Since ClearTunnel is all about outbound access control, and outbound access control is all about controlling users, logging users and reporting on users, the ISA Firewall has to be a domain member.
This isn’t a problem. I’ve mentioned hundreds of times on ISAserver.org that domain membership is an ISA Firewall best security practice. With the ISA Firewall being a domain member in a domain with an enterprise CA, the root CA certificate will be automatically installed on the ISA Firewall. You won’t have to worry about installing it manually. Again, it just works.
The Lab Network
Now for my lab network. It’s a very simple one with only two machines:
- The ISA Firewall. This machine has an internal and external interface and is running ISA 2006 with the supportability update pack. Caching is enabled. The ISA Firewall is a member of the msfirewall.org domain.
- The domain controller and client machine. This machine is running Windows Server 2003 SP2 and is configured as a domain controller for the msfirewall.org domain. Microsoft Certificate Services are installed in enterprise CA mode.
That’s it, a very simple lab network to demonstrate how to install and configure ClearTunnel.
Installing ClearTunnel is easy. First, download the ClearTunnel executable at http://www.collectivesoftware.com/Downloads/ and copy it to your ISA Firewall. Double click on it once it’s copied to the ISA Firewall. You will see the Welcome to ClearTunnel screen. Click Next.
Read the End-User License Agreement and put a checkmark in the I accept the terms in the License Agreement checkbox and click Next.
On the Choose Setup Type screen, click the Custom button.
On the Custom Setup page, you see the ClearTunnel components that will be installed on the ISA Firewall. We want to install all the components, so don’t change anything here. Click Next.
Click Install on the Ready to Install page.
Whoops! I guess there are some software prerequisites. I don’t think I really need MMC 3.0 installed on this machine, so I’m going to guess that all I need is the .NET framework. Let’s try downloading that first and installing it and see if ClearTunnel installs.
If you minimize the Web page, you’ll see this error from the installer if you are missing some prerequisite software. Looks like this dialog box gives more information than the Web page because it’s specific about needing the .NET framework 2.0 or higher installed. My guess was right!
I saw this page in the installation wizard after I dismissed the warning dialog box informing me that I need the .NET framework.
The good news is that after installing the .NET framework and running the ClearTunnel installer again, everything went fine and it successfully installed.
Create an All Open Access Rule from the ISA Firewall to the CA
Because of a small bug in the RPC filter on the ISA Firewall, you can’t request certificates from an online Enterprise CA using RPC without creating an all open rule between the ISA Firewall and the Enterprise CA..
Remember, we need to install a certificate on the ISA Firewall so that it can act as an intermediate CA which enables it to impersonate the destination SSL Web site.
To create that rule, click the Create an Access Rule link in on the Tasks tab of the Task Pane. On the Welcome to the New Access Rule Wizard page, enter a name for the rule. In this example we’ll name the rule All Open CA and click Next.
On the Rule Action page, select the Allow option and click Next.
On the Protocols page, select the All outbound traffic option from the This rule applies to drop down list and click Next.
On the Access Rule Sources page, click the Add button. In the Add Network Entities dialog box, click the Networks folder and then double click the Local Host entry. Click Close.
On the Access Rule Sources page you should see Local Host in the list. Click Next.
On the Access Rule Destinations page, click the Add button. In the Add Network Entities dialog box, click the New menu and click Computer.
In the New Computer Rule Element dialog box, enter a name for the computer in the Name text box. In this example, we’ll name it CA. Enter the IP address of the computer in the Computer IP Address text box. In this example, the IP address of our DC and enterprise CA is 10.0.0.2, so we’ll enter that into the text box. Click OK in the New Computer Rule Element dialog box.
Click the Computers folder and then double click the CA entry. Click Close.
You should see CA in the list of destinations. Click Next.
On the User Sets page, accept the default entry, All Users, and click Next.
Click Finish on the Completing the New Access Rule Wizard page.
Click Apply to save the changes and update the firewall policy.
Now we’re ready to take a look at the ClearTunnel configuration interface. In the ISA Firewall console, expand the Configuration node and click on the Add-ins node. Click the Web Filters tab in the middle pane of the ISA Firewall console. On the top of the list of Web Filters is ClearTunnel. Right click on ClearTunnel and click Properties.
In the ClearTunnel dialog box, the first tab you’ll see is the General tab. Here you’ll see the version of ClearTunnel.
Click the Mode tab. This allows you to select the mode in which you’re deploying the ISA Firewall(s) and ClearTunnel. There are four modes:
- Disabled Turns ClearTunnel off and the ISA Firewall won’t be able to inspect the contents of SSL sessions. Not good.
- Full Bridge For simple installations where Web proxy chaining is not enabled. Both encryption and decryption take place on the same ISA Firewall.
- Split: Downstream Select this option when you have a Web Chaining configuration and this machine is the proximal ISA Firewall (proximal meaning closer to the clients making outbound requests to the Internet).
- Split: Upstream Select this option when you have a Web Chaining configuration and this machine is the distal ISA Firewall (distal meaning the ISA Firewall closer to the Internet than the proximal ISA Firewall).
Note that in these kinds of Web Proxy chaining scenarios, only the proximal ISA Firewall should be performing authentication. Also, when using ClearTunnel in a Web Proxy Chaining scenario, the traffic between the proximal and distal ISA Firewalls will be by default unencrypted. However, you can configure the traffic between the proximal and distal ISA Firewalls to be encrypted. That configuration is made in the Properties of the Web chaining rule.
One interesting thing about using ClearTunnel in a Web Proxy chaining scenario where the link between the proximal and distal ISA Firewall is unencrypted is that IDS systems have the opportunity to scan traffic as it moves between the ISA Firewalls. This can be very useful if you’re using an IDS like Snort, which has no way to feed traffic in except from a tap on the network. As far as I know, this is the first time anyone has considered using Web Chaining in this way to augment the ISA Firewall’s inspection capability with wire-sniffing tools! This is something that will certainly make your security team happy.
In this review we’ll take a look at a non-Web Chaining scenario, so I’ll select the Full Bridge option.
Click on the Certificates tab. ClearTunnel has automatically detected our online Enterprise CA, which is a nice feature. Now we need to obtain an subordinate CA certificate for the ISA Firewall so that it can impersonate the Internet SSL Web server. There are two ways we can do this: the easy way or the hard way. I like the easy way, so let’s use that one.
The designers of ClearTunnel show their genius by including a wizard that will automatically obtain the certificate for you. Makes you wonder why Microsoft hasn’t included a similar wizard with the ISA firewall (hint, hint!).
Click the Install Certificates button and watch the magic happen.
Everything worked! Click OK in the All tasks finished dialog box.
You’ll see that the Certificate status is now Certificate is installed.
If you open an MMC and use the Certificates snap-in with the focus being the local machine account, you’ll see in the Personal\Certificates store the new ClearTunnelSigning certificate. Right click on it and click Open.
In the Certificate dialog box, on the General tab, you’ll see the details of the certificate and that the certificate has a private key corresponding to the certificate.
On the Settings tab, you have the option to set the Web Proxy port that ClearTunnel will listen on. If you don’t want to change the port configuration on the Web browsers, change this value to 8080. Make sure there are checkmarks in the Require certificates to be valid and trusted and Try to check revocation sources checkboxes. You need ClearTunnel to take care of this since your browser will always trust the certificate provided to it by ClearTunnel. Because the browser can’t check, it’s up to ClearTunnel to do this checking on behalf of the clients.
On the License tab, you see information on when ClearTunnel was installed and when it expires if you haven’t licensed it yet. You can enter your license key here, too. If you use ClearTunnel past it’s expiration date, it will enter Lab/Demo mode. In this case, it will work normally for two hours past the start of the Firewall service, but then after that a report of “license expired” will be sent to clients. Click OK to save the changes.
Configure the Web Proxy Listener to Listen on an Alternate Port
Since ClearTunnel is going to listen for Web Proxy client connections on TCP port 8080, we have to make sure that the Web Proxy listener doesn’t bind the same port. Remember, the ISA Firewall hates when two components try to listen on the same port (port contention). We can fix this by changing the listener port.
In the ISA Firewall console, expand the Configuration node and then click on the Networks node. Right click on the default Internal Network and click Properties.
In the Internal Properties dialog box, click the Web Proxy tab. In the HTTP port text box, enter an alternate port. In this example we’ll use 8888 because we know that no service or rule is using this port. Click OK.
There may be some sites that you don’t want ClearTunnel to inspect. If that’s the case, you can create an exception list. When you install ClearTunnel, it will create a Domain Name Set for you named ClearTunnel Excluded Sites. Double click the ClearTunnel Excluded Sites entry.
In the ClearTunnel Excluded Sites Properties dialog box, click the Add button to add sites to the exclusion list.
Before I installed ClearTunnel, I had created two Access Rules on the ISA Firewall. One rule was to allow all authenticated users to use the HTTP/HTTPS protocols from the default Internal Network and the second rule allows all users access to all protocols from the default Internal Network.
After installing ClearTunnel, you’ll notice that existing rules will be changed so that the Local Host network is added as a source network for outgoing connections. This is related to an issue with the ISA Firewall that will be remediated in the future. However, to work around this issue, ClearTunnel requires that you have the Local Host Network included as a source Network, in addition to the default Internal Network (or any other source Network you might have configured on your ISA Firewall). So remember, include both the actual source Network and the Local Host Network in your Access Rules so that ClearTunnel can work with that rule. ClearTunnel will do this for you on existing Access Rules, but you’ll have to do it yourself for any HTTP or HTTPS rules you create afterwards.
Click Apply to save the changes and update the firewall policy.
Open a Web proxy client browser on a system behind the ISA Firewall. When you connect to a secure Web site, you’ll see the lock icon in the lower left side of the browser window. Double click on the icon and you’ll see the certificate. Notice that the certificate was Issued to the name of the destination Web site and that is was Issued by ClearTunnel. This shows that ClearTunnel is successfully impersonating the Web site.
If you look at the ISA Firewall’s log files, you’ll see that ClearTunnel is working. Normally, the ISA Firewall is completely unaware of the path of the connections to the secure Web site, since that information is hidden inside the SSL tunnel between the client and the destination secure Web server. However, since ClearTunnel decrypts the connections, the ISA Firewall has full access to the session and can report on where on the secure Web server the user is going.
In addition, if you have Web filtering or anti-malware add-ons installed on the ISA Firewall, those add-ons will be able to clean the connection and block downloads of dangerous code. In contrast, if you didn’t have ClearTunnel, users could download whatever they want and infect your network because the ISA Firewall wouldn’t be able to inspect the contents of the SSL tunnel.
You can test this for yourself. First, turn off ClearTunnel by changing the bridging mode to Disabled. If you have an AV add-on on your ISA Firewall, go to http://www.collectivesoftware.com/Test/. Try to download some of the simulated malware on the page. You’ll find that your Web AV add-on is able to detect and block the download. Now go to https://www.collectivesoftware.com/Test/ and try to download the simulated malware. You’ll find that it downloads without a problem because your AV add-on can’t see inside the SSL tunnel.
Now turn ClearTunnel back on. Try to download the simulated malware again from https://www.collectivesoftware.com/Test/. You’ll find that your AV add-on now blocks the download because ClearTunnel made the content available to your anti-malware engine. That’s why you need ClearTunnel!
We can also check to see if ClearTunnel is working by checking the ISA Firewall’s cache file. If ClearTunnel isn’t working, the ISA Firewall won’t be able to cache the contents of the secure SSL session, since it can’t see what’s in the tunnel. If ClearTunnel is working, then we’ll see something in the cache.
In order to search the cache file, use the following command:
find /i <search_string> <file_name>
Where search_string is the string you want to search for and the <file_name> is the name of the cache file you want to search.
For example, to check if ClearTunnel is able to cache SSL pages delivered by a banking site, change the focus to the cache file directory (urlcache) and enter the following command:
find /i “service.capitalone.com” dir1.cdat
This is the output:
Not bad! We see the ClearTunnel is indeed working, as the contents of the SSL session are located in the ISA Firewall’s Web proxy cache file.
In this review, our lab really wasn’t set up for comprehensive performance testing. However, informal tests with ClearTunnel turned on and off didn’t show any obvious difference in client side perceived Web performance.
However, you should be aware that two SSL transactions per outbound connection will quickly spool up the ISA Firewall’s processor once you expose the ISA Firewall to significant outbound SSL traffic. This shouldn’t be considered bad, it’s just necessary. People often ask me "how many concurrent connections does the ISA Firewall support". It drives me crazy at times because this metric is completely dependent on hardware and network usage patterns.
In regards to ClearTunnel, I would expect that ClearTunnel is doing roughly the same amount of processing as it takes to do inbound SSL bridging. Because of this, you can use tools like the ISA Firewall sizing calculator on www.microsoft.com/isaserver to determine how much hardware you need.
A couple of other things to be aware of:
- Cached SSL content will be delivered faster with ClearTunnel than without it, even with the increased CPU utilization. The reason for this is that the content is served from the ISA Firewall’s cache rather than from a distant Web server. In addition, ClearTunnel doesn’t actually do as much SSL work since ClearTunnel doesn’t have to communicate with the real Web server as much (or at all).
- We all expect a magic hardware pill that will make SSL go faster. No SSL "offload" card on the market can function with forward proxies in an outbound SSL to SSL bridging scenario, for reasons similar to how the ISA Firewall itself without ClearTunnel can't do this. They don't know how to act as certificate issuers and make policy decisions about public SSL sites on the net. Solutions like Blue Coat roll custom hardware and software in, you can't buy that kind of synergy off the shelf or for cheap. The bottom line is that it's significantly less expensive to add a few more ISA Firewalls into your ISA Firewall array and use CARP, than to try and soup up the existing boxes with neon-chrome, pimped-out and insanely expensive SSL cards or Blue Coat. In addition, scaling out provides for fault tolerance and high availability, something you can’t get with Blue Coat’s approach of scaling up.
Given the potential complexity behind a product that is able to impersonate secure sites on the fly, I was pleasantly surprised by how easy it was to install and configure ClearTunnel. What surprised me even more was the fact that it actually worked without endless calls to Collective Software’s help desk. I found ClearTunnel to be the ideal “plug and play” solution for solving the problem of users compromising your network through SSL tunnels. ClearTunnel didn’t seem to create any performance issues and there was no adverse effect on stability.
Because this product says what it does and does what it says (and does what it says so well), with so little effort on my part to make it work, I must award ClearTunnel a full five stars. I can’t think of any way Collective Software could make this product better. In fact, I would award ClearTunnel six stars if I could, if for the only reason being their ingenious certificate request wizard!
My conclusion is that only the deluded or a fool would consider using overpriced and underpowered Blue Coat boxes for outbound SSL inspection when you can benefit from the superior performance and lower pricing that the combination of the ISA Firewall and ClearTunnel can provide.
ISAserver.org Rating: 5/5
Get more information about Collective Software's ClearTunnel