• The Dangers of Encrypted Tunnels
• Tom and Deb Shinder's Configuring ISA Server 2004 -- Pre-order Today!
• ISAserver.org Learning Zone articles of Interest
• KB Articles of the Month
• Post of the Month
• ISA Firewall Links of the Month
• Ask Dr. Tom

1. The Dangers of Encrypted Tunnels

By Dr. Thomas W Shinder, MD, MVP

As an ISA firewall administrator your main concern is controlling what external users can access on your corporate network and what users on the corporate network can access on the Internet and other networks within the corporate network. You spend a lot of time configuring firewall policy so that users have access only to the protocols you want them to use, connect only to the servers you want them to connect to, download only the content corporate security policy approves, and access resources only at a specified time of day.

Access control is the name of the game. If you don't have access control, then you don't have any control. You must have the ability to allow or deny VPN connections, allow or deny remote desktop connections, allow or deny access to Web servers and allow or deny file transfer via Web or instant messenger connections.

Your firewall is able to carry out your access control policy because it has information about connections established through it. The firewall inspects network layer, transport layer and application layer information and makes allow or deny decisions based on firewall policy you create.

But what happens when the firewall encounters an encrypted communication? Let's look at remote access to OWA sites as an example. A conventional hardware firewall (such as PIX or Sonicwall) sees an incoming connection to TCP port 443. An access rule on the hardware firewall says to allow the incoming connection and forward it to the OWA site on the corporate network.

The remote access OWA client negotiates an encrypted SSL connection with the OWA site. All communications moving through the hardware firewall are now encrypted and the hardware firewall has no idea of the encrypted SSL "tunnel" contents. There's nothing the hardware firewall can do if an attacker or worm on the OWA client machine launches an attack against the OWA server through this SSL encrypted session. The simple stateful filtering hardware firewall just says "this is an SSL connection and I'm configured to allow SSL connections to the OWA server, have a nice day".

This clearly isn't good. The fact that attackers can leverage an encrypted channel that you allow through the firewall means you have lost control. You've lost control because corporate access policy can't be enforced against the contents of the encrypted channel.

But wait, the situation gets even worse. Many application developers are getting into the HTTP tunneling act. They do this ostensibly be get around "restrictive firewalls" that allow only HTTP and/or HTTPS outbound or inbound. What they do is "wrap" their application protocol in an HTTP header so that firewalls configured to allow HTTP/HTTPS communications allows their application through.

Examples of this type of HTTP tunneling of non-Web applications include RPC over HTTP(S), the GoToMyPC application, and a large number of HTTP tunneling applications explicitly designed to subvert firewall policy. So-called "SSL VPNs" also belong to this group, as they are used to bypass firewall security and tunnel an array of application protocols within an encrypted SSL link. All of these applications, whether they were designed to increase productivity (such as RPC over HTTP) or to explicitly violate network use policy have a common goal: hide the underlying application protocol inside an encrypted SSL tunnel.

While hardware firewalls do not have the ability to inspect contents of an SSL tunnel and thus block access to application protocols hidden inside the tunnel, the ISA firewall does. The ISA firewall, which represents a third-generation firewall, does much more than simple packet filter based firewalls. The ISA firewall is able to break open the SSL encrypted tunnel, inspect the contents of the communication, and then re-encrypt the communication and forward the connection to the site on the corporate network.

In the example of remote access to OWA sites on the corporate network we saw the hardware firewall gives the thumbs-up on exploits moving through the SSL encrypted link. I personally would never allow remote access to any resource on the corporate network if all I had was a traditional hardware packet filter based firewall. I do not feel that I've performed the requisite due diligence to protect the corporate assets if the firewall cannot protect the published OWA site from attacks within the SSL tunnel. This is something you should consider if your firewall security is subject to Federal regulations.

In contrast, the ISA firewall accepts the remote access connection from the OWA client on the Internet. The ISA firewall then decrypts the connection and performs stateful application layer inspection on the contents of the communication. The HTTP security filter blocks a wide range of HTTP exploits (viruses, worms and blended exploits) and allows you to block unapproved application protocols wrapped in the SSL communication. If the ISA firewall's security filters detect suspicious or dangerous information within the application layer headers or data, the connection will be dropped. If the connection is clean, then the ISA firewall re-encrypts the data as it establishes a second SSL connection, this time between itself and the destination OWA server on the corporate network.

At this point it should be clear that the ISA firewall provides a much higher level of security than a traditional packet filter based hardware firewall. Today's attacks are at the application layer and are focused against the servers and services on the corporate network which drive the business. The ISA firewall's unique design makes it the standard bearer for the modern application layer inspection third-generation firewall.

This is not to say that the ISA firewall administrator's life is perfect. While the ISA firewall's "SSL bridging" feature allows it to provide a level of security orders of magnitude higher than what you see with hardware firewalls for incoming connections, we still have to worry about SSL tunneled applications sourcing from the corporate network and connecting to Internet sites.

The ISA firewall performs inbound SSL bridging and performs stateful application layer inspection, but it does not perform outbound SSL bridging. And this is what we need to complete the circle. Once outbound SSL bridging is available, you'll be able to block internal users from hiding HTTP tunneled applications in their encrypted SSL links.

Bottom line: Be wary of "SSL VPNs" and any other application that hides the real nature of its communications inside an SSL encrypted link. Keep this in mind when creating firewall policies. Do users really need outbound access to SSL? If so, you should strictly limit the sites they can establish SSL connections to. Otherwise, users could leverage their permission to use SSL to tunnel just about any protocol inside that SSL link, and you do not want that.

I'm looking forward to the day when the ISA firewall development team rolls out an outbound SSL to SSL bridging solution. When this happens, we'll have complete control over the SSL channel.

Until then, check out Finjan's solutions - Vital Security for Web and Vital Security ICAP for ISA Firewalls.

NOTE: Make sure that all users on your network and those who connect to resources through your ISA firewall are aware that you monitor communications moving through an encrypted tunnel (at the present time only inbound connections using SSL bridging). Users must sign-off on this policy and this policy should also be reviewed and approved by corporate legal departments. Finally, you must do everything you can to prevent users from using SSL encrypted channels. You'll be surprised to find out that the overwhelming majority of SSL encrypted connections made through the ISA firewall are not for business purposes.

2. Tom and Deb Shinder's Configuring ISA Server 2004 -- Pre-order Today!

Tom and Deb Shinder's best selling books on ISA Server 2000 were the "ISA Server Bibles" for thousands of ISA Server 2000 network administrators. Tom and Deb Shinder are preparing for you their next ISA Server book, Configuring ISA Server 2004. This book leverages the over two years of pre-release experience Tom and Deb have had with ISA Server 2004, from pre-alpha to RTM and all the versions and builds in between. They've logging literally 1000's of flight hours with ISA Server 2004 and they'll be sharing the Good, the Great, the Bad and the Ugly of ISA Server 2004 with their no holds barred coverage of Microsoft's new one of a kind application layer inspection firewall. While the ISA Server 2000 books were good, Configuring ISA Server 2004 is going to be even better. Tom and Deb bring their unique "insider's perspective" to provide you with information that isn't and won't be available anywhere else! Pre-order your copy of Configuring ISA Server 2004 by clicking the link. You'll be glad you did.

Click here to Order your copy today

3. ISAserver.org Learning Zone articles of Interest

• Using the Browser on the ISA Firewall (2004)
• Opening MSN through ISA server
• Configuring Remote Access VPN Servers in a Back to Back ISA Firewall Configuration
• ISAserver.org New Article Alerts for your PC or Website Using our RSS Feed!
• Allowing Intradomain Communications through the ISA Firewall (2004)
• Network Behind A Network (2004) - v1.1
• Strong Outbound Access Control using the ISA Firewall (2004): Using Scripts to Populate URL Sets and Domain Name Sets

4. KB Articles of the Month

• You receive a "Setup failed while registering Wspadmin.dll" error message when you try to install ISA Server 2004
• How to delete the Web cache in Internet Security and Acceleration Server 2004
• The external network adapter on your ISA Server 2004 computer cannot obtain a valid IP address from a DHCP server
• Clients receive an "Error 792: The L2TP connection attempt failed because security negotiation timed out." error message when they try to complete a VPN connection to ISA Server 2004
• How to prevent the caching of content from certain Web sites in Internet Security and Acceleration Server 2004
• How to configure the firewall policy if pcAnywhere is installed on an ISA Server 2004-based computer
• The differences between the Back Up feature and the Export feature in ISA Server 2004, and the differences between the Restore feature and the Import feature in ISA Server 2004
• Interoperability of Routing and Remote Access and Internet Security and Acceleration Server 2004
• Users cannot submit data to a Web site that you publish by using client certificate authentication in ISA Server 2004

5. Post of the Month

"This is a known, benign and irritating problem.
1 - By default, ISA 2004 uses MSDE logging and so installs it
2 - The MSDE instance isn't properly registered with the SQL service manager
3 - you can work around this by entering <machinename>\msfw in the "server" field and hitting <TAB>"

6. ISA Firewall Links of the Month

• Configuring Microsoft Office Live Communications Server 2003 Standard Edition, with ISA Server 2004
• Configuring IPSec Tunnel Mode VPN Between ISA Server 2004 and Cisco Pix v6.3.1
• Configuring IPSec Tunnel Mode VPN Between ISA Server 2004 and Astaro Security Linux
• Configuring IPSec Tunnel Mode VPN Between ISA Server 2004 and SmoothWall
• Publishing a SQL Server Computer with ISA Server 2004
• Configuring the ISA Server Computer as a DHCP Server
• Hardening the Windows Infrastructure on the ISA Server 2004 Computer

7. Ask Dr. Tom

QUESTION: Does ISA2004 Site-to-Site VPN feature protect my network from viruses, worms, trojans, etc. that might be present on the network located on the other side of the tunnel? If not what do most companies do to protect themselves from these types of attacks coming thru the tunnel? Thanks again for all the information great advice you provide. Thanks! --John

ANSWER: Yes. This is one of the very cool features of the new ISA firewall. The ISA firewall performs both stateful filtering (like all hardware firewalls) and stateful application layer inspection on all interfaces. This includes both the remote access VPN and VPN gateway interfaces.

A site to site VPN connection enables you to connect multiple offices to the main office using a VPN link. You can configure firewall policy to limit branch office user access to only servers they need to connect to, and use only the protocols they require to connect to those servers. You can also create user/group based Access Rules so that some branch office users can access more content at the main office and other branch office users access a limited set of content.

The branch office ISA firewall protects the main office against exploits introduced at a branch office. For example, a user or consultant might bring a laptop computer to the branch office. Since the laptop isn't under corporate control, you have no idea what security policy is enforced on the laptop. The laptop might have the Blaster worm. If so, the main office is fully protected because the RPC filter on the branch office VPN gateway blocks the blaster attack.

Maybe a malicious user located at one of the branch offices tries to attack Web servers at the main office through the site to site VPN connection. The ISA firewall at the branch office blocks the attack because the exploits are blocked by the branch office's HTTP security filter. You can also configure the HTTP security filter to block file downloads, block viruses, and block peer to peer communications through the VPN site to site link.