Palo Alto earns short list status

Palo Alto Networks has injected excitement and innovation into the firewall market with its "next-generation" appliances that combine traditional firewalls, threat mitigation technologies such as anti-malware and intrusion prevention, and the new magic dust of application identification.

We first tested Palo Alto in late 2008 and found the PA-4020 to be an interesting product that still needed work. This time around, we tested Palo-Alto's newest high-end appliance, the PA-5060 and found plenty to love.

The product clocked multi-gigabit speeds even with all threat mitigation and identification features enabled, proving that it's capable of conducting deep session analysis in an enterprise setting. In fact, using the exact same test scenario, the PA-5060 forwarded traffic 10 times faster than the product we tested in 2008 (see story, "Palo Alto PA5060 is one fast firewall").

With a solid basic firewall feature set and UTM protections such as anti-malware and intrusion-prevention system (IPS), the PA-5060 can be used for inbound traffic. And its application awareness makes it even better suited as an outbound firewall, giving extended visibility into what is happening, and fine-grained control over what is allowed.

Of course, no product is perfect. Palo Alto Networks is a relatively new company with limited resources, and features such as centralized management, Web-based GUI, VPN and network access control-like user identification and host scanning could be improved upon.

Next-gen firewalls: Off to a good start

Fast-forwarding firewall faceoff

However, none of these rough spots should stop network managers from looking carefully at the PA-5060, especially when tackling the thorny problem of outbound access control. The PA-5060 is also able to replace some Web security gateways, with the advantage of combining firewall and gateway in a single device.

Effective outbound traffic control

Security-conscious network managers have long known that port number is not the same as application. For example, two applications can share the same port, such as Skype and Web browsing over TCP Port 80. And, an application can change ports. For example, some network managers run SSL VPN servers on TCP Port 53, normally reserved for DNS, to tunnel through many pay-per-use Wi-Fi hotspots that allow DNS, but not much else.

A firewall rule that allows incoming traffic to specific ports is generally sufficient to control traffic, since you control your own servers and know what applications are running on them — in theory, at least. While the PA-5060 can be used for inbound traffic to enterprise networks, we focused most of our evaluation on outbound traffic, such as Web browsing.

Outgoing traffic has long ignored the idea of specific port numbers, with applications of all types running over whatever port seemed good at the time. Network managers using port restrictions to control applications such as Amazon Cloud Drive or Google Talk File can't easily do so, because those applications are happy to run over the traditional port for encrypted Web traffic, 443.

Controlling outbound mail traffic by redirecting everything sent to ports 25, 587 and 495, the common SMTP ports, to enterprise mail servers works only as long as no one out on the Internet is running SMTP on yet another alternative port.

Even without the effects of crafty applications and crafty users, enterprise network managers want greater granularity than allowing or denying all Web browsing. Because so many applications are now run through Web browsers, allowing general Web browsing while blocking specific applications is one of the reasons to use a next-generation firewall. Or, you may want to go deeper, such as letting people read blogs, but not let them post to blogs. Or read Facebook, but not run Facebook applications or use Facebook chat.

We tested the PA-5060 to determine if it could do what Palo Alto says it can: effectively control application traffic. With about 1,300 application signatures, we knew that we couldn't test every application. So, we picked a set of 100 common applications that we thought network managers might want to use as policy building blocks.

Our first challenge came because many applications can be effectively blocked using URL filtering, and the PA-5060 handles URL filtering separately from application identification. This requires some rethinking of security policy, because you may use URL filtering for some parts and application identification for others. For example, to block access to investing Web sites, we used "financial services" URL filtering, but to block people from posting to financial Web sites, we created an application group with applications such as "motleyfool-posting" and "google-finance-posting" to control that traffic. In some cases, such as blocking Internet proxies, we used both URL filtering and application identification.

In the end, we were able to block 83% of the applications we set out to, and we could probably have improved that score by adding our own custom signatures.

Our overall conclusion is that the PA-5060 has more than most managers would need to effectively control outbound application usage in enterprise networks. While splitting application controls between URL filtering and application identification can be error-prone and time-consuming, we didn't find the additional work to be a show-stopper.

We did discover that working with the PA-5060 requires some new ways of thinking. In theory, since you're writing rules based on application identification, you actually don't have to put port numbers in your firewall rules, at least in the outbound direction.

However, by not putting port numbers in, the PA-5060 allows all outbound connections, only cutting off traffic once something prohibited is found. That can have other side-effects, such as letting short bits of traffic out that you weren't expecting. We found a bug in the beta version we first evaluated using an outbound policy without most port numbers. In this case, the PA-5060 allowed entire connections that should have been prohibited. Palo Alto Networks fixed the bug quickly, but it's an example of the kind of issue that can come up.

Since the PA-5060 must look deep into outbound traffic to identify applications, some type of man-in-the-middle SSL decryption is required. Configuring and using SSL decryption is not difficult, and the PA-5060 has a very well thought-out model for handling the subtle issues of SSL man-in-the-middle. For example, a proper configuration gives the PA-5060 two different certificates to use to re-encrypt traffic: one considered valid by end-users and one considered invalid.

This lets the PA-5060 properly pass back to the end-user cases where an invalid certificate was offered by an upstream Web site. SSL decryption is handled in a separate policy from normal firewall rules, another well-designed separation that helps to reduce confusion.

The last piece of next generation firewall wizardry we looked at was the ability to identify users, and write rules based on user, rather than just zone or IP address. While the PA-5060 definitely has this feature, there are significant limitations.

Gathering user identification information is hard. One option is the built-in captive portal, which may be useful in a guest wireless network or an environment where network users are accustomed to such gateways, such as a university network. But we don't think that enterprises would find this acceptable.

The other is via a Windows application which captures domain authentications and IP addresses out of the event logs from Active Directory servers, and sends this information to the PA-5060. That would work fine in a very constrained, very homogeneous environment, but would miss a lot of users in others.

This difficulty isn't actually the PA-5060's fault: no one has come up with a particularly good way to capture this information short of deploying 802.1X and some type of NAC on their LAN. Unfortunately, if you did enable 802.1X, the PA-5060 has no ability to gather that information from NAC products.

With user identification fully integrated into the normal policy rules, it's easy to constrain outbound access based on who the user is. Unfortunately, getting that information is so difficult that we think this will have limited usefulness in large networks and work best in small environments, such as branch offices, which have simpler and more consistent architectures. The PA-5060 is definitely not the right firewall for that environment, but Palo Alto has other models sized for the branch office.

User identification is the incomplete piece that would let the PA-5060 take on another significant enterprise security market, the Web security gateway or Web proxy. The PA-5060 does everything that enterprise products from vendors such as Blue Coat Systems, Cisco, McAfee and Websense do.

If Palo Alto Networks wants to fully take on these giants in all market niches, it will need to work harder on the user identification part of the PA-5060. For now, the application control and filtering features of the PA-5060 are all you need to get rid of a standalone Web security gateway — if you're happy with the user identification options Palo Alto Networks gives you today.

Even if you don't choose to write access control rules based on user identification, there is a good reason to collect that information: it appears in the log files. Since every session through the PA-5060 firewall is logged with extensive information, adding user identification just makes the job of the security analyst that much easier. For this reason, we'd recommend turning on user identification, even if it doesn't properly identify 100% of network users.

Eye-opening visibility features

Traditionally, firewalls have been control points for security, and network managers who want to know what is happening on their networks turn to other devices and other vendors. We expect that next-generation firewalls will begin to be more than control points, and will start to also answer the question "what traffic is passing over the network?"

This visibility and reporting function won't obviate the need for IDSs, Netflow tools and protocol analyzers. Instead, it will supplement them by giving detailed information on what is, and is not, passing through the firewall itself.

The main reason for adding visibility, a radical increase in functionality, is the need for matching context between reporting and rule writing. The additional functionality of a next-generation firewall, including application identification and user identification, requires reporting to use the exact same terms as the firewall controls.

For example, our PA-5060's reports broke traffic to our Web servers into five separate categories: web-browsing, web-crawlers, http-audio, http-video, and flash. Without knowing exactly how the firewall was going to categorize the traffic, we couldn't effectively write rules to control the traffic. In other words, without knowing the context the firewall would use, we couldn't know how to use the firewall properly.

Adding a visibility function also makes sense because the firewall has already done most of the work. Next-generation firewalls are constantly engaging in deep session inspection to identify applications, threats, URLs, and other attributes of the session, in order to apply their rules. Therefore, it's reasonable to re-use that work by reporting on what is passing through the firewall.

The Palo Alto Networks PA-5060 has so many good reporting and visibility tools that it's easy to forget that it's a firewall. But that's important to keep in mind, because although the tools work great, they only take you so far — and the PA-5060 is not a complete replacement for other visibility-focused products.

The main starting point for viewing your traffic is the PA-5060's Application Command Center, which shows a constantly updated list of top applications, source and destination hosts and countries, URL filtering categories, IPS rules, data types (such as ZIP, PDF, Excel file, etc.), and a few other categories. This view alone will likely be an eye-opener for most network managers, as most of these data are not available in traditional visibility tools.

For example, the PA-5060 told us that the top application (both in terms of sessions, and byte counts) running on our networks was not what we expected -- Web traffic of some kind, or maybe email -- but something completely different: DNS. More importantly, by clicking through the Web-based reports, we were able to drill-down further into the summary information to identify the misbehaving hosts.

The Application Command Center only has summary information in it, giving you lists of up to 500 items (whether applications, threats, hosts, URL categories, and so on) for any timeframe you choose. That sounds good, although we found that asking for more than the past 24 hours worth of data was slow going. Still, if you wanted to get those top lists for the past month and were willing to wait a few minutes, the PA-5060 could give it to you.

The Application Control Center is great for what it is, but it's not re-summarizing the firewall logs every time you click. This means that trying to filter the data on something that the PA-5060 is not reporting on can't be done. For example, since there is no report on "port number," you can't summarize all traffic on Port 80.

Hacker 'handshake' hole found in common firewalls