Firewalls: A Hammer in Search of a Nail

• By Doug Gale
• 05/29/08

Back in 1990s one of the debates was whether the network should be smart or just a "big dumb pipe."  By the turn of the century we thought the "big dumb pipe" theory of networking won.  The network would provide end-to-end connectivity that was agnostic with regard to content.  Any problems would be resolved by simply adding more bandwidth.  But now, rather than a large agnostic pipe we find that applications must navigate through firewalls, anti-virus gateways, traffic shapers, proxies, and other active network security devices.  In short, the network has become very content-aware and our "security" devices may be downgrading performance for many applications.  

As part of a presentation on Cyberinfrasturcture Architectures, Security and Advanced Applications at the Internet2 Member Meeting held last April, Joe St. Sauver, University of Oregon and Manager of the Internet2 Security Programs talked about the pros and cons of firewalls and considered their impact on advanced applications.  The points he makes should be carefully considered.

Firewalls Everywhere
The foundation of most campuses' network security is built around firewalls, dedicated hardware appliances, or software running on dedicated computers that looks at messages passing through the firewall and blocks those that do not meet specified security criteria.  This examination is done in a variety of ways, including: looking at each packet traversing the firewall and accepting or rejecting it based on user defined rules; applying security restrictions to specific applications such as FTP and Telnet; applying security restrictions when a TCP or UDP connection is established; and hiding a network's true network address by implementing a proxy server.  

Philosophically, firewalls are a perimeter defense, much like the walls surrounding ancient Troy.  (And we all know how successful they were.)  One variable is how big the defensive perimeter is: the entire campus, a department, or an individual computer.  Or all three.  And like any perimeter defense there has been substantial discussion over the years regarding the efficiency of such strategies.  (See for example Terry Grays classic 2003 paper "Firewalls: Friend or Foe.")  

But how much protection do firewalls really provide and what are the negative impacts on advanced applications?  

A Firewall Is Our Friend
St. Sauver identified a number of good reasons for running a firewall:

• Firewalls help us isolate private networks from the public.
• Firewalls help us log problematic traffic.
• Firewalls help us enforce local policies such as "no peer-to-peer" traffic.
• Firewalls may be required for auditing reasons.
• Firewalls may enable NAT and help us preserve routable addresses in Ipv4.
• Firewalls embody the security principle of "least privilege," or giving a person or computer only the access needed.
• Firewalls can be part of a Defense in Depth that relies on multiple defensive strategies.

And in some cases, such as reinstalling Microsoft Windows, which begins with an unpatched operating system, they are even essential.  (The SANS Institute reports that the average time for an unpatched system to become infected is less than 10 minutes if not behind a firewall.)

Other Reasons We Have Firewalls
The real reasons we have firewalls may be less analytical and include the fact that:

• Firewalls are ubiquitous; everyone else is running one.  (Ninety-seven percent of the respondents to a recent survey indicated that their institution used firewalls.)
• Firewalls are widely regarded as part of due diligence in maintaining network security.  (The old "You're always safe if you buy IBM and Cisco Theory.")
• Firewalls make us feel more secure.  (The Linus Blanket theory of security.)

The Downside to Firewalls
But while it is conventional wisdom that a network must be protected by a firewall, not everyone agrees.  At the RSA 2008 Conference, Bill Cheswick, who is frequently referred to as the "father of the firewall" and is one of the authors of Firewalls and Internet Security: Repelling the Wily Hacker, remarked about 34 minutes into a live Web interview, "I haven't used firewalls in, uh, well, mostly, for 10 years or more."  He went on to say,  "They still have their use, but I really want my hosts to be secure enough they don't need a firewall."
       
So what's not to like about firewalls?

• Firewalls may encourage an over reliance on a single security technique and introduce a false sense of security.
• Firewalls don't address the problem of "insider threats," which are roughly as common as external threats.
• Firewalls don't protect you from Distributed Denial of Service (DDoS) attacks, which now account for 1 percent to 3 percent of all inter-domain traffic.
• Firewalls aren't of much help in protecting personally identifiable information (PII), as most firewalls routinely permit arbitrary outbound traffic to all external destinations.

And the list goes on.  The point critics are making is that firewalls were designed to mitigate classic computer intrusions based on automated scans and brute force login attempts, but that isn't the primary threat anymore.  Our strategic systems are protected by two-factor identification, and traffic is likely to be encrypted.

Problems with Advanced Applications
There are two basic problems with firewalls: They degrade network performance and make it difficult to troubleshoot network-based application problems.  In short, instead of a big dumb pipe, we have a "smart" pipe.  Instead of having a network that always passes traffic, we have a network that sometimes passes traffic.  If all a user is doing is Web browsing or e-mail, this isn't a problem.  But what happens to more advanced applications--the kind of applications that characterize a research institution.  If things don't work, is it a network problem or an application problem, or is it both?  And remember, packets are traversing multiple firewalls managed by multiple organizations.  A classic example of firewalls breaking applications is videoconferencing.

Videoconferencing
This is an application that has personally burned me.  Back when I was running an ISP, we were an early leader in the use of H.323 video conferencing, and one of our clients was a large urban university whose president was on my board of directors.  We did a good job of selling the potential of H.323 videoconferencing, and he became a both a user and an advocate.  Unfortunately his campus had outsourced network operations to a private company that believed that firewalls were transparent to all legitimate traffic.  The documentation provided by the firewall manufacturer clearly stated that video should work just fine through the firewall.  But it didn't.  And no amount of technical or empirical evidence could convince them that their firewall was the problem.   The only way we could make things work, after an incredible investment of time, was to hack his campus network and bypass the offending firewall.  The downside was that my board member blamed the problems on my organization, not his campus firewall.

So how do you run H.323 video?  The H.323 protocol requires a number of UDP and TCP dynamic ports to complete a successful connection.  While configuring a connection behind a firewall can be done with extensive configuration and testing in some cases, a simpler approach is to put the codec outside the firewall, sometimes called a DMZ (after "demilitarized zone"), and take some precautions such as turning off FTP, Telnet, Web, and SNMP.  For more information, go to MOREnet's technical support Web site.

Grid Computing
Grid computing is another advanced application that frequently encounters difficulties when run between networks protected by firewalls.  This is particularly true for for grid applications with huge bandwidth demands running over single data stream.  A good description of the challenges of running grid applications in firewall-protected networks can be found in the 2006 Open Grid Forum document Firewalls Issues Overview.  The article explains why grid-related systems often end up positioned outside an institutional firewall, in the "DMZ," or connected via a dedicated high-performance link.

Conclusions
Perhaps the time has come to reconsider our reliance on firewalls for network security and to consider the importance of network usability and the concept of the network as a big dumb pipe.  A good place to start is to join the discussions on Salsa (Security At Line Speed) and NetGuru.