Should You Allow SSL Through Your ISA Firewall?
(and why your hardware firewall leaves you defenseless)
By Thomas W Shinder MD, MVP
Got Questions?
Discuss this article at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=20;t=000696
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 users access only the protocols you want them to use, connect only to the servers you want them to connect to, download 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, 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. You also need to be able to do this on a user/group basis so that not all users are treated equally from a security context.
Your firewall is able to enforce 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.
The Dangers of SSL Tunneling
But what happens when your 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 Netscreen) sees an incoming connection to TCP port 443. An ACL on the hardware firewall allows the incoming connection and forwards 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 access to the encrypted SSL “tunnel” contents.
There’s nothing the hardware firewall can do if an attacker or worm on the OWA client launches an exploit 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”. You then get to spend the next week trying to repair your Exchange organization.
This clearly isn’t a good security posture. The fact that attackers can leverage an encrypted channel that you’ve explicitly allowed 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, and you can’t enforce corporate access control policy over the incoming encrypted connections because your hardware firewall can’t meet the challenge.
Everyone’s Getting into the HTTP Tunneling Act
While the OWA example should give you cause for concern, the situation gets even worse. Many application developers are getting into the HTTP tunneling act. Application developers tunnel their apps in an HTTP header ostensibly be get around “restrictive firewalls”. These “restrictive firewalls” allow only HTTP and/or HTTPS outbound or inbound. To solve this problem of “restrictive firewalls” they “wrap” their own application protocol in an HTTP header. Once their application is wrapped in the HTTP header, firewalls configured to allow HTTP/HTTPS communications will let 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 (http://www.google.com/search?hl=en&ie=UTF-8&q=HTTP+tunnel). So-called “SSL VPNs” also belong to this group, as they can be 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 with the goal of bypassing firewall access controls and security.
Even for non-encrypted HTTP tunneled applications, the hardware firewalls are helpless at preventing these applications from tunneling themselves through an outbound TCP 80 channel. In contrast, the ISA firewall’s HTTP Security Filter can check the HTTP header information in the connection request and block the HTTP tunneled connection. This is a major security enhancement and additional protection for networks protected by the ISA firewall.
The ISA Firewall Solves the Problem of Hidden SSL Encrypted Exploits
While hardware firewalls do not have the ability to inspect contents of an SSL tunnel and thus are unable to block access to application protocols hidden inside the tunnel, the ISA firewall does have this ability. The ISA firewall, which represents a third-generation stateful filtering and stateful application layer inspection firewall, is able to provide a much higher level of application layer protocol security than simple packet filter based firewalls. The ISA firewall is can break open the SSL encrypted tunnel, statefully inspect the contents of the HTTP communication, and then re-encrypt the session and forward the connection to the secure site on the corporate network.
In the example of remote access to OWA sites on the corporate network we saw the hardware firewall gives a thumbs-up to 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. My personal opinion is that I would not feel that I’ve performed the requisite due diligence to protect 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.
Note:
While outside the context of this conversation, I recommend that you consider Federal guidelines when thinking about whether you can should allow SSL to HTTP bridging. For this reason, we always recommend that you use SSL to SSL bridging.
In contrast, when the ISA firewall accepts the remote access connection from the OWA client on the Internet it decrypts the communication and performs stateful application layer inspection on its contents. The stateful application layer inspection is performed by the HTTP security filter, which 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 HTTP 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. Note that OWA is used as an example here, any secure Web server can be protected.
At this point it should be clear that the ISA firewall provides a much higher level of security than a traditional packet filter hardware firewall. Today’s most vicious attacks are at the application layer and are focused against the servers and services on the corporate network that drive modern business. The ISA firewall’s unique design makes it the standard-bearer for the modern application layer inspection, universal threat management, third-generation firewall.
We’re Still at the Mercy of Outbound SSL Connections
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. In this case, the ISA firewall provides the same level of security as the conventional hardware packet filter firewall.
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 SSL tunneling security solution. Once outbound SSL bridging is available, you’ll be able to block internal users from hiding HTTP tunneled applications in their encrypted SSL links.
So what’s the Bottom line? Be wary of “SSL VPNs” and any other application that hides the real nature of its communications inside an SSL encrypted link. Strongly consider whether your users actually need outbound access to SSL sites. If so, you should strictly limit the users and groups that can access SSL sites and create very explicit domain name sets representing the sites uses can connect to using the SSL protocol. Never enable an “all open” rules that allows users to access all sites using the SSL protocol. 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 and users and applications will not be able to hide exploits and disallowed protocols and applications within an SSL channel.
Until then, check out Finjan’s solutions – Vital Security for Web (http://www.finjan.com/products/VitalSecurityForWeb/) and Vital Security ICAP for ISA Firewalls (http://www.finjan.com/products/VitalSecurityICAPAdaptorForMicrosoftISAServer/).
Legal 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.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=20;t=000696 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.
