Application-Level Firewalls: Smaller Net, Tighter Filter

Second, because application-level proxies act as both client and servers for a protocol, they can enforce protocol conformance. For example, attacks over HTTP that violate the protocol, such as those that send non-ASCII data in the header fields, should be dropped because of nonconformance. An example is the IIS printer ISAPI buffer overflow, Bugtraq ID 2674, which inserts an overly long string along with non-ASCII characters in the host field. Exploits that do not violate HTTP, however, will pass through the application proxy. Application proxies handle complex protocols, such as H.323 and SQL*Net, which open dynamic ports.

Finally, application proxies look deeper into sessions and can make pass/drop decisions based on information in the application-protocol headers or in the application payload. SMTP application proxies, for example, can be configured to allow only necessary SMTP commands, such as helo, mail from: and rcpt to:, to pass through the firewall while blocking other commands, such as expn and vrfy, which try to expand a list and verify that an account exists, respectively, and are used by attackers and spammers to enumerate e-mail accounts. Other protocol-specific items like MIME type and message size can be used to filter traffic as well. Application proxies used in firewalls rarely delve into the protocol payload to make pass/fail decisions. However, there are HTTP-specific proxies that do examine HTTP data and form/fields (see "Proxies Add a Protective Shield").For this review, we focused on the protection mechanisms provided by application-level firewalls. We also examined the levels of performance degradation between application-level protection and stateful packet filtering. We asked vendors to send us firewalls that provided application-level protection for common protocols, including HTTP, SMTP, POP3, IMAP, SQL*Net, DNS, FTP, H.323. And for our performance tests, we asked vendors to supply hardware that can handle up to 1 Gbps of traffic (see "Supplied Hardware for Application-Level Firewalls"). Four of the five did; however, WatchGuard Technologies sent us a Fast Ethernet solution. We didn't accept any OEM products because there wouldn't be any security value added to the firewall software. Before you tell us how your OEM vendor provides better protection of the firewall because the OEM strips the OS, please note that all the firewalls we tested run on hardened versions of general-purpose operating systems.

We tested Check Point Software Technologies' FireWall-1 Next Generation Feature Pack 3, Microsoft Corp.'s Internet Security & Acceleration (ISA) Server 2000, Secure Computing Corp.'s Sidewinder G2, Symantec Corp.'s Enterprise Firewall with VPN 7.0 and WatchGuard's Firebox 4500. Cisco Systems, NetScreen, and SonicWall declined our invitations because, they said, their products were not a good fit. The only surprising no-show was CyberGuard Corp., which has a 12 percent market share, according to Gartner. Company officials said they didn't want to lend credence to Check Point's (29.7 percent market share when combined with Nokia) application-level firewall support. Um, OK then.

We set out to investigate the protection mechanisms application firewalls provide above and beyond stateful packet filtering. We also limited the criteria to inbound traffic where the firewall would be in front of servers in a DMZ. The specific protocol-protection features varied widely between vendors. WatchGuard offered no protocol-level protection for inbound HTTP traffic while all the other firewalls provided at least protocol enforcement so sessions with non-ASCII header data were dropped. FireWall-1 NG, ISA and Enterprise Firewall all successfully blocked Unicode directory-traversal attacks using URL pattern-matching techniques. None of the firewalls offered application-level support for POP3 or IMAP and only Secure Computing's Sidewinder G2 successfully blocked our DNS cache poisoning attack (see "Application-Level Firewall Features,", and "Application Security Test Results" for details on the protection tested).

Performance is always an issue with network equipment and this is especially true with firewalls. It's a no-brainer to assume that application-level proxy firewalls will mean a performance hit because the proxies are doing more work to inspect the packets and the proxies have to set up two connections for every incoming connection. None of the firewalls could come near 1 Gbps of traffic. When testing HTTP traffic, Microsoft's ISA came in at 170 Mbps with 550 connections per second. That will cover an OC-3 connection but it's inadequate for near-gigabit speeds. In comparison, FireWall-1 NG ran at a whopping 766 Mbps with stateful packet filtering but dropped to 122 Mbps when using the application proxy. Application proxies provide better protection but at a performance cost.Secure Computing's Sidewinder G2 earned our Editor's Choice award. Sidewinder is tops at combining protection and performance, though its reporting capabilities still need work. Sidewinder G2 Sidewinder G2 is the first new version from Secure Computing since the purchase of the Gauntlet firewall from Network Associates. Sidewinder still installs with a hardened BSDI 4.3 OS with type enforcement, but nearly all configuration is done through the installation wizard or the Sidewinder management GUI. Gone are the days when you had to be a Bind/DNS/Sendmail guru to properly set up the firewall. Secure Computing has done a nice job of easing the product's installation process while preserving its security strengths.

About the only security problem we found is that the HTTP proxy doesn't support URL string pattern blocking. Such support is handy as a stopgap to block the latest URL-specific worm while you are patching your Web servers. But aside from a couple of foibles, Sidewinder still strikes a nice balance between protection and performance.

Sidewinder's protections come from its application proxies. It provided the best protection mechanisms for both H.323 and DNS. Sidewinder can selectively block H.323 codecs and T.120 functions, such as chat, application sharing and videoconferencing. This provides much finer control over how H.323 is used.

For DNS protection, Sidewinder uses a hardened Bind 9 DNS server and it can be configured as a hosted split-DNS or transparent-DNS proxy. Split DNS makes a noncaching DNS server available to the outside world that is used to resolve only those addresses that are published. A second caching DNS server is used for internal clients trying to resolve hosts both internally and externally. Splitting the DNS means external users will never reach internal DNS servers. An added benefit of using Bind 9 is that when the DNS server gets a response to a query that contains an alias (CNAME) to another host name, the DNS server will try to resolve the alias rather than trust the response. That blocked our attempt to poison our internal DNS server. In all the other firewalls we tested, cache corruption of our internal DNS server was successful.

The management GUI is radically different from earlier versions of Sidewinder and does take some getting used to. The only real down side is rule management. Firewall rules are created and then added to groups. Groups are combined into a firewall policy. The order of the groups and the order of the rules in the groups determines the rule order in the resulting policy. When we viewed the active policy, we couldn't edit any of the rules nor could we determine what group a rule belonged to. We had to keep track of it ourselves. We have enough details to remember--the admin console should do that for us. Also, the real-time logging still leaves much to be desired. Manually scanning syslog entries is fine for experienced administrators, but not for novices.When it comes to performance numbers, the Sidewinder can handle a ridiculous number of concurrent connections--30 KB, second only to the Firebox 4500. Microsoft's ISA came in at a respectable 10 KB. The rate for connections per second came in at 800 in our testing. Sidewinder did a bit better than Check Point's FireWall-1 in the bandwidth test with HTTP application filtering enabled. However, when we ran the same test using stateful packet filtering, it only yielded an increase of 10 Mbps. In comparison, FireWall-1's stateful packet filtering screamed. After working with Secure Computing engineers, we determined the bottleneck was with memory allocation, for which we had no workaround.

Sidewinder G2, Secure Computing Corp., (800) 379-4944, (408) 979-6100. www.securecomputing.comOK, how many of you know that FireWall-1 NG has application proxies? Not many, I bet. Check Point has been putting in application proxies--Security Servers in Check Point parlance--since version 4.0. We found a huge difference in HTTP performance when Security Servers were active as compared with performance when they were inactive. HTTP performance took a dive when we enabled application scanning, highlighting what we knew all along: Application filtering is much more resource-intensive than stateful packet filtering. However, the price is worth paying because the protection you get with application proxies is much better.

The FireWall-1 management GUI still offers the same rule-based paradigm. It's clean and easy to use and the logging is better than what you'd find with most other firewalls in terms of detail. Symantec's Enterprise Firewall is one that provides more detail. If you want to blend application proxies with stateful packet filtering, FireWall-1 will provide good protection and performance.

Security Servers are added via the resource mechanism. In the resources area you can configure specific protection features, such as URL length for HTTP or MIME types for SMTP. Once the resource is configured, it is added to the rule base just like a regular service and you're done. The types of protection are configured in the SmartDefense dialog for the particular resource. Using HTTP as an example, the HTTP Security Server SmartDefense options are applied to all HTTP Security Servers or to one selected in the rule base. Here we could choose to enforce URL lengths and HTTP Header lengths as well as enforce the use of ASCII characters in the HTTP request and response headers. Because Web server buffer overflows tend to use long strings in header fields and/or pass non-ASCII data in the header, these two selections should block requests that are not HTTP-compliant.

During our performance tests, FireWall-1 NG operated at 766 Mbps during stateful packet filtering. Once we enabled the Security Server, performance dropped to 122 Mbps. It's the same old trade-off--performance versus protection. Bear in mind, however, that using application proxies is not an all or nothing option with FireWall-1 or any of the firewalls we tested. It's possible to mix and match proxy and stateful packet filtering in the same rule base to balance protection and performance on a per-rule basis.FireWall-1 NG offers other protection mechanisms besides the Security Servers. Some types of attacks--including URL regular expression matching, IP spoofing, DoS (denial of service) attacks, and other network- and transport-based anomalies--are caught in the kernel without the need for Security Servers. This translates to improved protection without sacrificing performance.

FireWall-1 NG has a good mix of both performance and protection, however we think that Sidewinder with it OS type enforcement, split DNS and SMTP, and H.323 application proxies puts it over the top. If you're a FireWall-1 user, try to eke out some more protection without hitting performance too much.

FireWall-1 Next Generation Feature Pack 3, Check Point Software Technologies, (800) 429-4391, (650) 628-2000. www.checkpoint.comSymantec Enterprise Firewall with VPN 7.0 | Microsoft Internet Security & Acceleration Server 2000 | WatchGuard Technologies Firebox 4500

Symantec Enterprise Firewall with VPN 7.0

Symantec Enterprise Firewall (SEF) offers somewhat better protection for HTTP traffic than Sidewinder but lacks NetMeeting filtering options. Its performance was much slower compared with the other firewalls we tested. SEF performed at well below 100 Mbps with HTTP application scanning enabled. The management station is on par with Check Point's and its logging is some of the best we have seen.

Regarding application-proxy protection, SEF is no slouch. It blocked all our attempts to pass malformed HTTP, DNS and SMTP traffic. SEF also can block traffic based on URL filtering on a per-rule basis by adding the http.urlpattern directive into the Advanced Services tab of the rule. Once that was done, we saved and reconfigured the firewall and it began to block URLs matching the pattern. For example, to block Unicode traversal on our unpatched IIS5 Web servers, we entered Unicode patterns, such as scripts/..%c0%af.., that we wanted to block. Likewise, any URI string can be matched. Both features are welcome stopgap measures for known attacks. SEF comes with a sample pattern file that contains most of the common patterns.

Like the Sidewinder, SEF also blocks SMTP relay attempts as well as SMTP source routing. SEF in unique in that it can detect what appear to be telnet connections to Port 25 and drop the connection. This is probably because telnet connections send one character at a time whereas real SMTP clients send all the strings at once.As for performance, SEF was comparatively slow. Once we started loading the firewall with connections, SEF's CPU utilization hit 100 percent and stayed there. We started seeing failures at around 67 Mbps with 330 connections per second, and the failure rate was dramatic. Once the firewall was saturated, it stopped accepting new connections.

Symantec Enterprise Firewall with VPN 7.0, Symantec Corp., (800) 441-7234, (541) 335-7000. www.symantec.com

Microsoft Internet Security and Acceleration Server 2000

Micrsoft's ISA is a full-featured HTTP proxy. However, it lacks support for some key protocols. ISA is unique in that it can be installed on a Web or Exchange server and offers tight integration with Windows 2000 and Outlook Web Access (OWA). We did find a DoS problem with the DNS filtering, which Microsoft patched (you can find more details on this problem in Microsoft's Knowledge Base, article number Q331065). Our testing also revealed that you cannot create stateful packet-filtering rules between multiple internal networks nor can you install the proxy transparently for inbound traffic. These important implementation features are available in the other firewalls we tested. ISA was the fastest HTTP application proxy in the review, operating at 170 Mbps.

ISA's HTTP proxy takes URL filtering one step further than the other firewalls we tested. When a URL is sent to ISA, before it passes the URL to the destination host, it decodes any Unicode or ASCII encoded strings. To block directory-traversal attacks, we simply entered the string "../.." into the URLScan filter--we didn't have to monkey with regular expressions.

While testing ISA with Cenzic's Hailstorm, we noted that the POP3 intrusion-detection filter only looked for long strings in the user-name field during login. We informed Microsoft and the company confirmed that the POP3 is working as designed, but there may be other fields susceptible to attack besides the user field and the filter supplies limited detection. Finally, we found ISA's SMTP application filtering only works one way--inbound. We put a Netcat listener on Port 25 inside the firewall and telnetted to the SMTP proxy on ISA. Although we weren't able to send arbitrary data from the client to the server, we could send arbitrary data from the server to the client.

Microsoft Internet Security and Acceleration Server 2000, Microsoft Corp., (800) 426-9400, (425) 882-8080. www.microsoft.com

WatchGuard Technologies Firebox 4500

The Firebox is a good firewall if most of your HTTP traffic is headed outbound from internal clients. But we simply cannot recommend it to protect a Web server because the Web proxy doesn't perform any HTTP protocol enforcement on traffic originating from the external network. It's no better than a stateful packet-filtering firewall. We did find the SMTP application proxy top notch. Limited to fast Ethernet ports, the Firebox easily handled the HTTP traffic we threw at it, operating at about 90 Mbps.

The SMTP proxy blocked our attempts to relay mail and can silently strip header fields that are not in the approved list. Any errors the destination message-transfer agent encounters are sent back to the sender. However, when the Firebox is under load, it stops responding to the management station. Although WatchGuard made a design decision to put traffic performance ahead of management, losing management control is not acceptable.

Firebox 4500, WatchGuard Technologies, www.watchguard.com

Mike fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Write to him at [email protected].Post a comment or question on this story.

Stateful packet-filtering firewalls protect the enterprise at the network level, but application-level attacks can cross a stateful packet-filtering firewall easily. Application proxies, like the ones we tested, take perimeter security to a higher level by inspecting traffic at the application-protocol level. The proxies make decisions on the types of data and the commands allowed. Among the products we tested, we found good support across the board for common protocols such as HTTP and SMTP but support for more complex protocols such as H.323 and Oracle's SQL*Net varied greatly. The price for this increased protection is performance. Even with gigabit interfaces, none of the firewalls came close to 200 Mbps.

Luckily, these firewalls offer both stateful packet filtering and application proxy support, so there's plenty of room for rule-based customization. Our Editor's Choice, Secure Computing's Sidewinder, squeaked out a win because of its protection features. We wanted to determine how well the firewalls protected application-layer traffic and how well they performed. We were surprised to see little support for POP3 or IMAP and support for H.323 limited to opening the necessary UDP ports.

For the protocols we were most interested in--DNS, FTP, H.323, HTTP, IMAP, POP3, SMTP--we tried to find out whether the firewall performed any syntax checking at the protocol layer. We used Netcat, a tool developed by @Stake, to bind a commend shell to specific TCP and UDP ports. We then telnetted to the port. If we received the command shell, we knew the protocols weren't being enforced and we could move on. If we couldn't get a shell, we knew the firewalls were enforcing protection. We then tried two paths to determine how well the enforcement worked.

First we took well-known exploits that violated the protocol and determined if we could get the traffic through the firewall. We used Network Associates' Sniffer Distributed s4000 Model EG2S to monitor the packets coming out of the firewall. If the attack didn't get through the firewall, we knew the firewall was blocking. Then we used Cenzic's Hailstorm 2.0 to generate malformed packets primarily against HTTP, IMAP, POP3 and SMTP protocols. With Hailstorm, we could try to send header strings with long strings and non-ASCII characters through the headers, which typically is not allowed. You can find more detailed descriptions of our protection testing below.

We used Spirent Technologies' WebAvalanche and WebReflector to create a large user base and a Web farm, respectively. WebAvalanche and WebReflector combined produced a closed-loop test bed that simulated large numbers of users performing HTTP gets. We created three scenarios designed to test each firewall's ability to handle a high connection and tear-down rate, a high number of concurrent connections and a high traffic load over a moderate number of concurrent connections. We made every attempt to configure each firewall to provide a similar level of protection.

More Details on Our Performance Tests

Throughput testing typically consists of bit-blasting the device under test(DUT) to find when the DUT begins to fail. And though bit-blasting is fine fortesting Layer 2/3 infrastructure devices, it doesn't really test the performanceof DUTs that have to maintain session state while passing traffic. Withfirewalls?both stateful packet filtering and application proxies?new TCP/UDPsessions start and end while traffic is flowing through the DUT. Because thefirewall is kept busy tracking a dynamic traffic load, session managementbecomes a serious performance factor.

We created three tests to test specific aspects of firewall performance. Ourconnection-rate test determined how many connections per second the firewallcould handle. Although typical traffic patterns are predictable and can bescaled to, you'll always need to accommodate spikes in traffic. Our maximumsustained connections test determined how many connections the DUT could holdopen. This finds the upper limit of sustained connections. Finally, ourthroughput test determined how much data could be passed through the firewallover HTTP while opening and closing sessions. This test is a better determinerof firewall performance than a bit-blast test over a few open sessions becausethe firewall is doing real work similar to what you would see on a real network.

Connection Rate

In WebReflector, we created four Web servers for the clients connect to and setup 500 connections per second for a 60-second time period. The connections wereHTTP/1.0 with KeepAlive turned off, and the file was an 8-byte file (we didn'twant to saturate the link). Next, we increased the connections per second by 500over a 60-second time period. That gave us a gradual increase in connections persecond without triggering SYN flood detection. We continued to increase theconnections per second until we saw failures. We then stepped the test back tothe failure point and ran each test for 10 minutes until we found the sustainedconnection rate. Since the WebAvalanche simulated Web users, as one connectionclosed, another was opened, maintaining the desired connection-per-second rate.This exercised the firewall's state and TCP tables.Maximum Sustained Connections

We a similar test bed similar to that of our connection-rate test, but we set adelay on WebReflector of 60 seconds, which kept the connection active. We thenramped up the connections until we could make no more. We set the maximumconnections to varying levels until we found the maximum number of connections.

Throughput

We used HTTP/1.1 with persistent connections and created a transaction where auser asked for a 25-KB page with two subobjects of 25 KB each. Each transactionthen consisted of a 75-KB download. We varied the number of connections persecond to reach a desired bandwidth. We disabled caching on the firewalls thatsupported it and configured each page to be expired.

Protection TestingWe used a mixture of exploit from online.securityfocus.com and Cenzic'sHailstorm to exercise the firewall application proxies. We set up DNS, FTP,HTTP, IMAP, PO3, SMTP and NetMeeting for H.323.

Protocol Conformance

We wanted to determine if we could get nonprotocol conforming traffic past theproxies?like you would see with server-based buffer overflows where non-ASCIItraffic is inserted into the protocol headers?or make a telnet connection to aNetcat listener on a well-known port. If the firewall is a real applicationproxy, nonconforming traffic should be blocked. We tested DNS, HTTP, IMAP, POP3and SMTP for conformance. We used scripts from Cenzic Hailstorm to generate fillheaders with long strings as an attempt to overflow buffers and we used BitWalker, which essentially flips bits in a string to generate ASCII and non-ASCIIcharacters. To determine if the protocols got through the firewall, we usedNetwork Associates Sniffer Distributed to capture packets on the protected sideof the firewall. Any malformed packets that got through were marked as afailure.

For H.323, which opens dynamic protocol ports during the connections, we starteda session and then used WUPS, a Windows UDP port scanner from Arne Vidstrom, onthe host making the connection. If we saw the UDP packets on the protected sideof the firewall, we knew that dynamic ports were not opened as needed.

HTTP TestingWe tested the ability of the proxies to block methods and HTTP URL filteringbased on length or text matching. Application firewalls aren't meant to providefull-blown Web application protection; however, simple URL matching shouldn't bedifficult. We tested whether the HTTP proxy could block a commondirectory-traversal attack. We used regular expressions or simple strings,depending on what the firewall supported. We tested the blocking by sending theoffending URL containing the offending strings and even Unicode encoded them tobypass the filter proxies.

DNS Cache Poisoning

We set up a Bind DNS server on the external network and created a new zone underour domain name called zone-1-1. We also created a zone called zone-1-2. Wecreated an alias, "spoof" on zone-1-1 that points to "real" in zone-1-2. Inzone-1-2, we created an A record that resolved "real" to an IP address. When wequeried zone-1-2 for "spoofed," the DNS server returned the answer as an aliasfor real.zone-1-2 and the address for real.zone-1-2. Our misconfigured DNSserver promptly cached both entries.

SMTP testing

Because none of the firewalls had true POP3 and IMAP application proxies, wefocused on SMTP. We tested open relaying of e-mail by configuring the SMTP proxyonly to allow e-mail to our domain, and then, using an SMTP client on theoutside, we tried to relay mail by direct relay and used bang-path strings suchas [email protected] or victim%[email protected].

Glossary
• Application-level firewall: A proxy that examines network traffic at the application-protocol level and can enforce protocol syntax and filter specific protocol commands and content.

• Circuit-level gateway (also known as a proxy): A circuit-level gateway is similar to a stateful packet filter except the circuit-level gateway proxies connections passing through it. Clients and servers never communicate directly.
• Stateful packet-filtering firewall: A firewall that monitors TCP session state and drop/reject packets that are not part of a current session or are out of state with a current session. Application filtering is usually limited to handling randomly assigned connections within protocols like FTP or H.323.Web Links
"Defense Starts Here" (Network Computing, Feb. 20, 2003)

"3Com Embeds Firewall in PC NICs" (Network Computing, Nov. 15, 2002)

"Dial 1-800 Plug Holes" (Network Computing, Nov. 1, 2002)

"Building an In-Depth Defense" (Network Computing, July 9, 2001)

"A Rookie's Guide to Defensive Blocks" (Network Computing, June 24, 2002)

R E V I E W

Application Level Firewalls

Sorry,
your browser
is not Java
enabled

Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.

Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.Click here for more information about our Interactive Report Card ®.