 Product Test and Buyer's GuideThis newsletter is sponsored by Raritan Computer, Inc. Data Center Build outs Simplified Product Test and Buyer's Guide, 09/06/07By Christine BurnsAs Network World’s testing editor, I work very closely with all of our Lab Alliance Members and one of our longest standing testers is security consultant Joel Snyder. Joel is currently pounding on 10 unified threat management (UTM) enterprise products in his lab so that we can publish the test results in early November. It’s not an easy job and he reminds me of that daily, typically with an e-mail note with a 2 a.m. time stamp so I know he’s putting in the necessary time to evaluate this type of multi-faceted product. As these test run their course – usually a 4 to 6 month process - ideas for articles outside the realm of presenting pure test results bubble to the surface. Below is the text of a yet-to–be published article outlining Joel’s thoughts on the general inner workings of UTMs in the market today. If you happen to be researching UTMs because you need to purchase one for your network, you can tap into the Network World Buyer’s Guide on the topic here. With this listing, you can compare and contrast over 20 UTM products from nine vendors to help narrow the field. Joel’s article – previewed in its entirety below - will be featured as part of a completely revamped UTM Buyer’s Guide set to go live early next month. Stay tuned for more information on that front.
Now, back to Joel’s thoughts on why UTM firewall products work so slowly … Why Do UTMs work so slowly? By Joel Snyder, Network World Lab Alliance 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 share 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-$1,000 products that can handle speeds nearing 100Mbps, because they just don’t require that much CPU speed. In the open source world, people often brag of using 100-MHz 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: antivirus and antispam definitely sit at the application layer, while effective intrusion prevention also requires application layer awareness. Add to that the structure of antivirus and antispam 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 1000Mbps, you’re lucky if it will do 100Mbps 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. |
| Contact the author: Christine Burns is the Executive Editor of Testing. She can be reached at cburns@nww.com This newsletter is sponsored by Raritan Computer, Inc. Data Center Build outs Simplified BONUS FEATUREIT PRODUCT RESEARCH AT YOUR FINGERTIPS Get detailed information on thousands of products, conduct side-by-side comparisons and read product test and review results with Network World’s IT Buyer’s Guides. Find the best solution faster than ever with over 100 distinct categories across the security, storage, management, wireless, infrastructure and convergence markets. Click here for details. PRINT SUBSCRIPTIONS AVAILABLE International subscribers, click here. SUBSCRIPTION SERVICESTo subscribe or unsubscribe to any Network World newsletter, change your e-mail address or contact us, click here. This message was sent to: security.world@gmail.com. Please use this address when modifying your subscription. Advertising information: Write to Associate Publisher Online Susan Cardoza Network World, Inc., 118 Turnpike Road, Southborough, MA 01772 Copyright Network World, Inc., 2007  |
No comments:
Post a Comment