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.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
