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.
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.
