Guide to Unified Threat Management

Why Do UTM Firewalls Work So Slowly?

By  Joel Snyder, Network World Lab Alliance, 10/1/07

From the outside, a UTM firewall looks like an amalgamation of different security features, all smooshed into a single box. However, there are some significant limits that come from combining firewalls and application-aware security services. Knowing how these things are put together from the inside out will help you understand what UTM firewalls can, and cannot, do.

Thinking about UTM firewalls should start with the realization that most firewalls use stateful packet filtering to control flows. The early 1990's firewall "wars" between packet filter vendors and proxy vendors were decided fairly firmly in favor of the packet filter camp: Check Point, most prominently, but nowadays also including Cisco, SonicWALL, and Juniper. These companies went on to take the lion's shares of the firewall market,. This leaves what are now the two main proxy firewall vendors, Secure Computing and WatchGuard, to take what's left of that pie. Although there are many reasons enterprise buyers voted for packet filters, one of them was speed: packet filters could keep up with the rapidly increasing speed of Internet connections, while proxy firewalls could not.

The speed of packet filtering firewalls stems from the fact that they don't need to keep track of, and check, every bit of information going through them. Packet filtering firewalls operate fairly low in the TCP/IP stack, doing most of their work at the IP and-to some extent-TCP layers, with only an occasional foray into the application layer during connection setup and the first few packets of a connection. A proxy firewall, properly implemented, has awareness and control all the way up to the application layer. This means that, in theory, an attacker can slip more application-layer badness through a packet filtering firewall than through a proxy. On the other hand, the proxy firewall is going to be slower because it has more work to do all the way up the stack.

The result of this performance win is that packet filtering firewalls can be made incredibly inexpensively. All leading packet-filtering vendors offer sub-$1000 products that can handle speeds nearing 100 Mbps, because they just don't require that much CPU speed. In the open source world, people often brag of using 100MHz systems that were destined for the scrap heap as their firewalls, just because that turns out to be plenty of speed for a simple packet filter.

Security, though, continues to be just as important as speed in the firewall business. Both camps have come to compromise positions. Packet-filtering firewall vendors are looking higher and higher in the application stack to catch common attacks, giving them some of the security features already offered in proxy firewalls. At the same time, proxy vendors have made short-cuts here and there, sometimes reducing their product's ability to look at or control the application layer, in order to achieve competitive performance.

The difficulty for security managers comes when UTM features are added. While UTM add-ons can occur at any layer, the ones of greatest value to network managers require application-layer awareness: anti-virus and anti-spam definitely sit at the application layer, while effective intrusion prevention also requires application layer awareness. Add to that the structure of anti-virus and anti-spam products: many thousands of signatures, all running across a single complete data stream, and you're now on the wrong side of the CPU and memory power curve. You've got a firewall of an entirely different architecture. The result is a massive performance hit. In our testing, adding UTM features to a standard firewall typically causes a 10:1 performance hit: if it used to do 1000 Mbps, you're lucky if it will do 100 Mbps with any other UTM features turned on.

To counteract this performance penalty, vendors have turned to a combination of tricks to keep their collective CPUs above water without adding in a co-processor or separate IPS blade. A common one is to require the network manager to pre-configure all the different applications on the firewall, indicating which ones should be scanned and which application is running on which port. That works fine in certain cases, such as incoming SMTP mail, which is on a predictable port going to a predictable system. However, except for the small business case where the UTM firewall is the only threat protection in place, scanning incoming SMTP mail for viruses is one of the least useful features of a UTM firewall. Where network managers need additional protection is in all the other ways that end users have of getting information off the Internet, such as via Web traffic, IM traffic, personal mail accounts being checked at work, and peer-to-peer applications.

The result is that UTM firewalls fail pretty miserably where they are most needed. For example, in our testing, UTM firewalls were outstanding at catching viruses being downloaded from Web servers on TCP port 80, the most common port for web traffic. However, as soon as we moved the Web server to a different port, the firewalls missed the traffic entirely. We didn't even bother to try encrypted Web traffic, since the firewalls definitely can't see into an encrypted session without breaking the end-to-end security model. The exact same class of problems occurs in the IPS engines inside of UTM firewalls: without predictable applications on predictable ports, UTM IPS generally won't catch application-layer attacks. This means that a malware distributor simply needs to add ":81" to the end of links in phishing messages to bypass most UTM protections.

 

Subscribe to the Security Watch Newsletter

Comments