Palo Alto's PA-4020 is not just another firewall. Yes, it has what you'd expect in a basic firewall: 24 ports, divided into16 gigabit Ethernet ports and eight SFP ports. It has a rule base, some basic VPN capabilities, and a Web-based management interface. If the description ended there, Palo Alto would not likely make any headway into the enterprise firewall business which is already carved up between Check Point, Cisco, and Juniper.
Palo Alto Networks' PA-4020 is not just another firewall.
Yes, it has what you'd expect in a basic firewall: 24 ports, divided into16 gigabit Ethernet ports and eight SFP ports. It has a rule base, some basic VPN capabilities, and a Web-based management interface. If the description ended there, Palo Alto would not likely make any headway into the enterprise firewall business which is already carved up between Check Point, Cisco, and Juniper (Compare products).
Palo Alto's performance holds steady as security measures increase
Palo Alto's secret sauce lies in the visibility it provides. Most firewalls do what they do, and provide little information (other than logs) about what they're seeing. The Palo Alto PA-4020 has a much greater focus on exposing the actual application-layer traffic, and then giving the network manager visibility into the traffic and threats in the network.
In this Clear Choice, we found the Palo Alto Networks PA-4020 to be an innovative turn on the traditional firewall (see Is Palo Alto's firewall a firewall or not?). By looking at application data streams, rather than TCP/IP port numbers, the PA-4020 is able to provide a finer-grained control over end-user Internet usage than has previously been available in any firewall. The PA-4020 also leverages this application knowledge to provide unprecedented (for a firewall, that is) levels of visibility into network traffic.
That said, we found the PA-4020 to still be a work in progress. Weaknesses in areas such as bandwidth management and virus scanning mean that it can't fully replace the combination of a firewall and Web security gateway — yet.
What's it all about
The Palo Alto PA-4020 (like all Palo Alto's firewalls) claims to do something that no other firewall can do: control based on application, rather than on port number. For traffic coming into an enterprise, that's not very interesting, because most network managers know for which applications they're opening holes in the firewall. However, when it comes to outbound traffic, network managers haven't had that vital visibility.
The alternatives, up to now, have been slim. Either run with a "default outbound allow" policy and have no idea what people are really doing. Or, block all outgoing traffic and force users through proxies that can control and log what's happening.
Palo Alto changes the game by allowing you to write your firewall rules based on the applications you want to control. The familiar firewall rules page is changed in a subtle, but very important way: you get one more column called "application." To block outbound SMTP from everyone other than your mail server, rather than specify Port 25 (which will catch some, but not all SMTP), you could simply block the application SMTP. We tested the PA-4020 and it found SMTP on non-standard ports without a problem.
The PA-4020 we tested had information about 638 applications loaded into it. Those applications ranged from obvious protocol-based ones (Session Initiation Protocol and FTP) to browser-based programs (Facebook, SharePoint and PokerStars) to client-server applications (World of Warcraft, VMware and SSH) to peer-to-peer code (BitTorrent and Gnutella). We tested a selection of applications on the PA-4020 and found that it works… most of the time, and for the things you probably care about.
We tried a basic test of allowing all outbound traffic, but blocking BitTorrent and Skype. That worked fine; the PA-4020 was able to identify both of those applications and effectively block them. Then, we tried allowing all Web browsing, but blocking Web mail services. The PA-4020 successfully identified and blocked nine Web mail services, including some large public services such as Yahoo and Google's Web mail, but also other privately run Web mail gateways.
But additional tests showed several false positives. For example, some of our tests to Yahoo's pages triggered the PA-4020 to block us, because it identified the application as an IM application (Yahoo Web Messenger) rather than a simple Web page — but not consistently.
We also ran into issues when we tested the ms-update and apple-update services. We wanted to allow servers to get updates from Microsoft or Apple, but not to allow general web browsing. That's hard to do on a conventional firewall, because the update servers don't use fixed IP addresses, and thus there's no way to write a firewall rule to allow update traffic but block all others. The PA-4020 got halfway through this test by successfully identifying the update traffic, but ultimately failed the test by lumping in the download traffic with other Web browsing. This means you could use a PA-4020 to block update traffic, for example, if you wanted to force servers to only use your own update server. But you can't allow update traffic without also allowing Web browsing.
We can't ignore the obvious question of "what about encryption?" If the traffic through the firewall is encrypted, then the PA-4020 can't identify what's inside. There's no true solution to the problem, but Palo Alto has implemented what most security analysts feel is a good second choice: a "man-in-the-middle" decryption for secure-HTTP traffic. The PA-4020 intercepts encrypted Web connections and makes up its own digital certificate on the fly to match the one at the destination of the connection. If you use this technique, you'll have to give the PA-4020 a signing certificate that's trusted by the Web browsers on your LAN to avoid having a message pop up every time the user hits an encrypted Web page. You can create a policy on the PA-4020 to only decrypt certain types of URLs or to exempt some URLs from decryption (such as banking sites). A nice feature here is that the PA-4020 can (optionally) put up an interstitial page allowing the user to opt-out of having their SSL decrypted.
One confusing thing about the PA-4020 is that it also includes SurfControl's URL filtering capability — which also automatically turns on SSL decryption, even though you may not have enabled it in the policy. (Palo Alto told us that this would be controllable in a future release of the product). Some of the URL filtering capabilities overlap with the application detection capabilities. Web mail is a good example: you can block Web mail using the sophisticated application detection of the PA-4020, and hopefully get all Web mail sites. Or you can use plain old URL filtering, which would have a different set of false positives and false negatives.
Not just control. Also visibility.
Most firewalls generate traffic logs. Because the PA-4020 has greater visibility into the traffic passing through it (or past it — you can set interfaces on the PA-4020 to act as intrusion-detection system taps as well as firewall interfaces), the logs out of the PA-4020 have correspondingly more information about what is happening on the network. Each traffic log message also includes the application being used (if the PA-4020 can identify it). An additional feature of the PA-4020, which we did not test, can also correlate traffic information with Windows Active Directory user information. That adds up to a lot of useful data.
To help sift through the information, the PA-4020 includes both a log browser and a report-writing tool. We ran these directly on the PA-4020 system itself, which has an internal hard drive to store logs. As an alternative, Palo Alto offers an external management tool (we did not test this) to handle multiple firewalls and aggregate their logs.
We spent a lot of time using the log browser to dig through traffic and threat logs to see what the PA-4020 was, and wasn't detecting. While it's easy to find fault with the tools we had from Palo Alto, the sober reality is that no other firewall we've tested made it this easy to find out what was happening on our network, either from the general traffic point of view or when seeking out genuine threats.
At this stage in the product's life cycle, the PA-4020 has a long way to go before it'll be a full-fledged forensics tool. Navigation through the data set is cumbersome and slow; it's impossible to jump from summary to detailed views; DNS lookups aren't applied consistently; you can't use wildcards in some fields; and queries get lost when moving between screens. But for a first pass, the monitoring, reporting and application investigation tools are more useful than any other firewall offers on a system-resident Web interface.
It's fair to characterize the PA-4020 visibility tools as a "first taste" of what could be done with the information available. If the PA-4020 is compared to a pure intrusion prevention/detection system (IPS/IDS), then the logging and browsing tools are immature and lacking serious functionality. But when you consider the combination of firewall and application logs, IPS/IDS logs, antivirus/antispyware logs, and URL filtering logs, there's a powerful pile of visibility information not available in a typical IPS, IDS or firewall. Not everything you'd want is there. For example, traffic information isn't broken out by direction, and when a threat, such as a virus or IDS alert, is logged, you don't get very much information about the threat. But even with missing pieces, we found that the PA-4020 offers a unified, clear — if somewhat clumsy — view into both traffic and threats on a network.
The PA-4020 will sit well into many network topologies, because the device can act either as a Layer 2 bridge or as a Layer 3 router (although only IPv4 is supported in the version we tested; IPv6 is targeted for first half of 2009). When in Layer 3 mode, features such as NAT are also available. Routing functionality is limited in this release to static routes and RIP and Open Shortest Path First routing protocols. The PA-4020 includes virtual routers and virtual systems, which would make it easy to carve the PA-4020 into smaller pieces to serve multiple departments within an organization, even ones with conflicting IP address space. With 24 gigabit Ethernet ports, there's plenty of firewall to go around.
Palo Alto manages to do all this with heavily customized hardware. This isn't a standard Intel PC with Linux on it; Palo Alto builds its own hardware, which also helps keep its power consumption down to a miserly 1.9 Amps.
There is one big gap in the PA-4020's capabilities at this juncture in that there is no ability to apply QoS controls and bandwidth limits. The PA-4020 can label traffic based on application so that other devices can provide bandwidth limits, but does not actually do even rudimentary limiting (other than outright blocking) of applications. Palo Alto told us that this feature will be available in the first half of 2009, and will be hardware accelerated.
Are the issues we found killer problems with the PA-4020? No, definitely not. This product is fresh out of the gate, and some rough spots are expected. If you are attracted to the idea of controlling outbound access with a firewall rather than forcing traffic through a proxy, you’ll still think that the PA-4020 has a lot to offer. Overall, enterprise network managers who need additional visibility and controls over employee Internet access will find the PA-4020 a valuable tool that goes beyond traditional firewalls.
Snyder is senior partner with Opus One in Tucson, Arizona. He can be reached at Joel.Snyder@opus1.com.
Snyder is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.