As a firewall administrator your primary concern is access control. You want to control exactly what services internal network users can access on other networks, and you want exact control over what services external users can access on the internal network. That’s the reason you have a firewall. If you don’t want someone to access a specific service on the Internet, then you either do not allow it (the preferred method) or you explicitly block it (the less preferred method). This isn’t a radical approach and is something inherent in all good firewall policies.

For example, you have created a firewall policy allowing a specific group of users outbound access to only HTTP and HTTPS. You do this because you want this group of users to have access to Web sites on the Internet, so that they can see Web content and connect to secure Web sites to get business done. You do not allow them access to other protocols such as IRC, FTP, SSH, VPN, Telnet or any others, because your organization has determined that these protocols can put your network at risk when used by these users you have given access to only HTTP and HTTPS.

So what happens when a user uses the HTTP protocol to "tunnel" other application protocols? The popular GoToMyPC is a remote access application that the vendor claims "does not compromise the integrity of your firewall" (https://www.gotomypc.com/ourTechnology.tmpl). Oh really?

As a firewall administrator, I open outbound HTTPS to selected users so that they can go to secure Web sites. I do not open outbound access to HTTPS (SSL) so that they can use remote access technologies that enable them to connect to their home computer and then transfer virus infected files from their home computer (which isn’t under our administrative control). And because the GoToMyPC application runs in an SSL tunnel, virtually no firewall on the market today (including the ISA firewall) can inspect the contents of the SSL stream once SSL session is negotiated.

GoToMyPC is just one example of HTTP tunneling of non-Web applications. If you do a Google search of "HTTP tunnel" and you’ll come up with a slew of applications that allow users to subvert firewall policy by tunneling dangerous applications through an HTTP connection.

For example, near the top of the list on the Google search is HTTP-Tunnel. You can see a list of applications your users can use with this software at http://www.http-tunnel.com/html/support/user_guides.asp. As a firewall administrator, you enable users access to applications they have permission to access and they should not be able to use applications that they are not permitted to access. The HTTP tunneling software subverts firewall policy and security, and potentially violates corporate network access policies.

So what does all this have to do with Terminal Services? Microsoft has announced that it intends to provide an HTTP tunneled RDP client and server in the R2 release of Windows Server 2003. This purportedly is done to allow for Access Anywhere, so that users can create RDP sessions through "restrictive firewalls". Maybe there’s a reason why those firewalls are restrictive! (you can find more information on this HTTPS tunneled RDP client over at http://www.brianmadden.com/content/content.asp?ID=61)

The next time you hear someone joke about TCP 80 and 443 being the "Universal Firewall Ports", you’ll know what they mean. This also points out that the future of firewalls moves far beyond the conventional stateful filtering firewall (like most so-called "hardware firewalls" on the market today).

The future of network firewalls is the stateful application layer inspection firewall. The good news is that the ISA firewall is the poster boy of the stateful application layer inspection firewall. Only a stateful application layer inspection firewall is going to be able to completely take apart the HTTP/HTTPS communications and then validate them against firewall policy. One thing is for sure: its not going to be easy.