On Firewall Obsolescence

This has been a popular topic the past week. But I think that in both Richard's and William's respective positions, it's a game of semantics that's being played here. The real debate on whether or not firewalls are still relevant is actually taking place in marketing meetings, not product development meetings, though the two are inexorably linked. I'll tell you why.

Firewalls are not an actual control, or even a technology. They are a concept. Without reposting the chronological history of the firewall here, I'll simply point out that firewalls have been made up of varying combinations of packet filters, state tables, address translators, and proxies. Vendor-driven convergence has further complicated defining what a firewall is by adding VPN tunneling, content filtering, anti-virus, and IDS/IPS functionality to their products and continuing to call them "firewalls."

So let's do away with the repackaged-converged-for-post-2002-sales firewall and break it down by function. Here's what's not obsolete:

• Packet filter with a state table - Easy and fast to deploy for outbound Internet traffic. Most modern OS's come with one built in. If you're doing outbound traffic without it and instead proxying everything you are either:
• Using SOCKSv4 on AIX 3.3 and your uptime dates back to 1995 ...or...
• Only allowing SMTP and DNS outbound, which makes you my hero
  
• Proxies - Content filtering or inline anti-virus with your "UTM" appliance? Transparent proxy. Web application firewall? Reverse proxy. PIX? They call yours fixups. Check Point? They call yours "Security Servers." FYI - you have proxies.
• NAT - Unless you're The University of Michigan and have a spreadsheet to keep track of the public Class A's that you own, you need NAT. For that matter, University of Michigan has NAT, too. But they don't have to. You do.
  

Here's what is obsolete:

• tcp_wrappers - Replaced by stateful firewall in the kernel.
• Straight up packet filtering - Memory is cheap. Your routers all have state tables now.
  

What Richard and William are really complaining about is how most shipping firewalls don't already handle security for complicated app-protocol-over-HTTP stuff like SOAP, XMLP, and even the easier stuff that's getting everybody in trouble these days like SQL injection, XSS, and SEO poisoning. It's this valid, if semantically challenged, line of dialog that is fostering a perceived demand for new capabilities in a firewall and also sending vendors scrambling to position their products in a way that differentiates them from what's out there right now. It seems that every time that this happens, somebody has to declare the old stuff dead. This has happened to firewalls before as well as anti-virus and IDS.

The thing is, this isn't new functionality, it's new content. Back in 2001 I was writing patterns for Raptor's HTTPD proxy to discard inbound CodeRed exploit attempts against web servers. And since that time, I've been writing custom Snort rules to detect or block specific threats including attacks against web servers. Whether by proxy or by packet payload inspection, we've already seen the underlying concept that will make these new security features possible. The hard part isn't getting the data to the rule set. The hard part is going to be writing rules to prevent injection attacks via XML. This is where security vendors discover that extensible protocols are a real bitch.