A SANS Product Review
Written by Dave Shackleford
June 2014
Sponsored by
McAfee, part of Intel Security
Advanced Network Protection with
McAfee Next Generation Firewall
Attacks today incorporate increasingly sophisticated methods of social engineering and client-side software manipulation to exfiltrate data without detection. Some attackers leverage so-called spearphishing to entice employees to give up access information and spread their attacks to other enterprise systems; others use password crackers against compromised applications in order to gain further access rights to the network. The attackers might also set up channels for command and control communications with the compromised systems, as in the case of the Zeus or SpyEye bot infections.
New types of network detection and prevention—with the ability to inspect complex network traffic and correlate its results with additional information, such as user IDs
and system names—must replace traditional firewalls. Such technologies enable deeper investigation of network attacks and help analysts distinguish those from benign anomalies. These enhanced or “next-generation” firewalls may be able to completely replace other network protection systems such as IPS or traditional firewalls, although not in every case. The first major feature consideration for such systems is application inspection and identification. Conventional firewalls focus primarily on Layer 4 ports (e.g., ICMP, TCP and UDP), with some additional inspection of Layer 7 (applications), but next-generation firewalls go further, performing deeper analysis of traffic and looking for unusual protocol specifications and behavior.
Another core feature for any next-generation firewall is the ability to track application traffic (particularly traffic identified as being potentially malicious or suspicious in nature) to specific users and systems within the environment. In order to do this, a next-generation firewall needs to integrate natively with user directory services such as Microsoft Active Directory or Lightweight Directory Access Protocol (LDAP).
We had the opportunity to review McAfee Next Generation Firewall (McAfee NGFW) to see if it stands up to advanced threats and meets these requirements. We found McAfee NGFW’s interface easy to access and use and its policies simple to create and push to devices. The VPN capabilities worked as advertised, and the ability to create simple rules that automatically create VPN tunnels can help organizations protect data in transit. Its availability and redundancy features were easy to configure and functioned properly, and
Introduction
Advanced Features: McAfee Next Generation Firewall
In this review, McAfee Next Generation Firewall (McAfee NGFW) met the demands for next-generation firewall features, including: t&BTFPGVTFBOEDFOUSBMJ[FENBOBHFNFOU It was simple to
add a new firewall node and remotely push policies to the devices. t*OUFHSBUFE71/The integrated VPN features let us easily
examine rules, such as a client-to-site VPN rule, test the connectivity and evaluate a site-to-site VPN connection. t)JHIBWBJMBCJMJUZBOESFEVOEBODZ We evaluated these
critical features for advanced, high-capacity firewalls by looking at McAfee NGFW’s clustering configuration options. We tested the functionality of a firewall cluster and then built a simulated WAN connection with redundant ISP links to test a larger-scale deployment with multiple sites and distributed WAN connectivity; in both cases, failover happened seamlessly.
t"CJMJUZUPTUPQTPQIJTUJDBUFEBUUBDLT Most importantly, when we evaluated the platform’s Advanced Evasion Technique (AET) protection, it was able to stop sophisticated attacks even when we modified traffic and attack payloads to mimic their attempts to avoid detection.
Ease of Use and Policy Management
The first use cases we evaluated with McAfee NGFW focused on basic functionality and operational simplicity.
Adding New Firewalls to Manage
To see how easy it was to use, we started with McAfee Security Management Center (SMC), which runs on Linux or Windows clients and provides a “single pane of glass” view that reduces the amount of resources needed to configure and manage firewalls. Once in the GUI, we simply right-clicked the firewall category, and added a “single firewall” object as shown in Figure 1.
A new window opened, in which we were able to enter information about the new device. As shown in Figure 2, we used SANS-Test as its host name.
Simplicity such as this provides real advantages to IT security teams who are strapped for resources and need a better way to add, change and configure firewalls from a central location.
Figure 1. Adding a Firewall Object in Security Management Center
Ease of Use and Policy Management
(CONTINUED)
Network Interface Con
fi
guration
Adding network interface configuration details to our firewall object was also simple. We configured two interfaces (Interface 0 for unprotected WAN traffic and secure, in-band management traffic and Interface 1 for protected LAN traffic), as shown in Figure 3.
We then configured the device’s basic functions via its command line interface (CLI), which we accessed via Telnet. Other options involve a direct connection through the device’s serial interface, booting from a USB drive or using an innovative “plug and play” option. The latter uses a secure cloud service operated by McAfee to download and install the device’s initial configuration and enables secure communication between the McAfee NGFW and SMC. McAfee NGFW receives its final configuration and associated policies without any hands-on interaction required. This process can reduce setup time to a few minutes of a non-expert user’s day.
Figure 3. McAfee NGFW Network Interface Configuration
McAfee’s “plug and play”
con
fi
guration option uses
a secure cloud service to
con
fi
gure and set up the
device without any hands-on
interaction required.
Ease of Use and Policy Management
(CONTINUED)
A simple menu-driven CLI wizard enabled us to configure the local device settings and then link the device to the placeholder object in SMC. One of the CLI wizard screens, for a single-device firewall with the host name SANS-SingleNode, is shown in Figure 4.
Once we had linked a device to the corresponding object in SMC, we did all further work through the GUI.
Adding Firewall Policies
Through SMC, security analysts can create and reuse firewall policy templates for efficiency and simplicity. After completing the wizard and adding the new firewall into SMC, we uploaded a policy to the new device to block users from going to specific websites. In this case, we configured the rule to drop all traffic destined for Amazon.com, Box.net and Facebook. McAfee had already created a default policy template for our testbed, called NGFW_SingleNode. We pushed that policy, shown in Figure 5 with the ID of 15.1, to the device.
Figure 4. CLI Wizard for New Device Setup
Ease of Use and Policy Management
(CONTINUED)
Once the rule was applied, we did a simple test to see if it was working. We logged in to a test client workstation via Remote Desktop Protocol (RDP) and used its web browser to access a number of sites such as Amazon, Google and MSN; the last two were allowed, but access to Amazon was blocked. We confirmed this in the real-time logs in SMC. Figure 6 illustrates that the Amazon service and all other sites appearing in the red rows are blocked traffic.
In the next use case, we wanted to explicitly block access to a certain internal subnet from user bsmith (predefined in Active Directory by McAfee during the testbed setup). Using the SMC policy editor shown in Figure 7, we easily added the rule to the policy.
Figure 6. Blocked Access to Amazon.com
Ease of Use and Policy Management
(CONTINUED)
The rule we created had the ID of 15.2 and blocked any HTTP traffic from user bsmith and with a destination of a specified network subnet. The final rule set is shown in Figure 8.
Testing this use case was simple: We used RDP to log in to a test workstation as several different users. First, we logged in as user Lisa Dataleak (ldataleak) and successfully accessed a website at IP address 70.100.100.150. We then logged out, logged back in as user bsmith and attempted to access the same IIS site; this failed. The log from SMC is shown in Figure 9.
Figure 8. New NGFW Policy Rule in Place
Ease of Use and Policy Management
(CONTINUED)
Investigating a New Firewall Event
We found troubleshooting easy to accomplish with the help of SMC’s view of log events, which enables drill down into events to obtain detailed information such as the rule triggering the event. To begin our investigation of the firewall event, we drilled into the details of the event, which provided a simple visual representation of what happened, along with all the different fields in the generated event (shown in Figure 10).
We found it simple to add the McAfee NGFW to SMC. Creating some basic rules was fast and easy, as well. The rules worked perfectly, blocking traffic based on user IDs, IP addresses and URLs.
The next use cases we reviewed focused on VPN policies and access control. McAfee’s VPN capabilities are part of McAfee NGFW’s included feature set and include the ability to have an augmented VPN—which combines multiple VPNs into one logical VPN—with IPsec. Configuring the VPN is a simple process; one first creates a gateway in SMC, drags and drops remote sites (e.g., a branch office) to add to the configuration and, finally, deploys the updated configuration.
In the first example, we established a client VPN connection to the firewall. We entered credentials into the VPN client for user bsmith. Figure 11 shows the status of the VPN authentication process.
VPN Policies and Access Management
VPN Policies and Access Management
(CONTINUED)
Simultaneously, we monitored the McAfee NGFW logs in SMC to see the IPSec authentication process, shown in Figure 12 by the white rows of the table.
The policy rule in place for this use case explicitly forbids the use of RDP to a specific network zone by user bsmith while on a VPN connection, as shown in Figure 13.
We tested this rule by logging into a client workstation as user bsmith, and then attempting to RDP to 30.100.3.110. The connection failed, as demonstrated in NGFW logs (see Figure 14).
We then disconnected the VPN client as bsmith, logged in again as user ldataleak and successfully initiated an RDP connection to 30.100.3.110.
For the second VPN scenario, we tested a site-to-site VPN connection with NGFW rules in place to allow file transfers with FTP. First, we logged in to a desktop system as the user bsmith, then used WinSCP to log in to the host 30.100.3.110 using the FTP protocol. While the connection was occurring, we viewed the logs in SMC, as shown in Figure 15.
Figure 12. VPN IPSec Authentication
Figure 14. RDP Connection Discarded for bsmith
Figure 15. FTP Events for bsmith Figure 13. RDP Discard Rule
VPN Policies and Access Management
(CONTINUED)
We right-clicked on the events shown and selected View Rule; this displayed a rule enforcing a site-to-site VPN connection between the internal network and the “branch” range (defined elsewhere in SMC), as shown in Figure 16.
This rule allowed any services between the specified source and destination, as long as a site-to-site VPN was in place. More detail on the events generated with the FTP transfer are shown in Figure 17.
We found the process of setting up both client-to-site and site-to-site VPN connections to be quick and simple, while generating rules in the McAfee NGFW platform that leveraged VPN connectivity (or behaved in specific fashions depending on connection state) was also easy. Such rules are invaluable for organizations looking to ensure connection security before certain types of communication are allowed.
Figure 16. Site-to-Site VPN Rule
The next category of configuration options we tested centered on availability. Given that the McAfee NGFW may replace existing firewall and network platforms, it must be highly available and operate seamlessly in a load-balanced and clustered configuration. The native clustering features of McAfee NGFW replace external load balancers, simplifying network design and making troubleshooting simpler than before.
A McAfee NGFW cluster supports up to 16 physical devices and provides native, on-the-box load balancing of the network traffic. Another convenient feature of McAfee’s clustering technology is its ability to support a mixed physical and code environment, which enables an organization to perform upgrades in either sphere without taking down the cluster.
The first use case we walked through was adding a new node to an existing cluster, a straightforward process in SMC. First, we right-clicked on the icon for our firewall cluster (which McAfee had set up for our testing with two nodes) and selected Add Node; in the pop-up window, we noted the new node’s “One Time Generated Password,” outlined in red in Figure 18.
Availability and Redundancy Settings and Options
Figure 18. New Cluster Node with One-Time Password
McAfee NGFW’s native
clustering features simplify
network design and make
troubleshooting simple.
Availability and Redundancy Settings and Options
(CONTINUED)
Then we used the CLI wizard to connect the new node to SMC; the step where we
finalized the connection and entered the one-time password is shown in Figure 19.
After refreshing the new node’s policy in SMC, the third cluster node connected successfully, as denoted by its green icon in Figure 20.
Figure 19. Finalizing Connectivity to SMC
Availability and Redundancy Settings and Options
(CONTINUED)
To test the availability aspects of the cluster, we took one of the nodes offline (in this case, node 2) as a simulated node failure or maintenance outage. This process is shown in Figure 21.
Using the bsmith account, we browsed to several YouTube videos and started them from a workstation. The traffic continued in this configuration (nodes 1 and 3 online, and node 2 offline) without fail. We then took node 1 offline and the traffic continued through node 3 (the remaining node), as shown by the HTTP events in Figure 22.
Figure 21. Taking a Cluster Node Offline
Availability and Redundancy Settings and Options
(CONTINUED)
Our second use case for availability focused on McAfee NGFW’s “Multi-Link” feature, which adds redundancy and provides quality of service (QoS) and bandwidth aggregation capabilities for more efficient traffic management.
We created a simple Multi-Link using two ISP connections defined by McAfee in the test environment, as shown in Figure 23.
We then added a network address translation (NAT) rule to our firewall cluster, directing it to use the Multi-Link, as shown in Figure 24.
Figure 23. New Multi-Link Connection
Availability and Redundancy Settings and Options
(CONTINUED)
Once the Multi-Link was established and online, we took one of its ISP connections down manually, as shown in Figure 25.
With the same bsmith account, we verified that YouTube videos continued playing seamlessly when the link was disabled, verifying the immediate failover condition, as we did earlier when we took two out of three firewall nodes offline.
Redundancy and availability is a critical aspect to any firewall deployment, and ensuring uninterrupted connectivity for users and systems is paramount. McAfee NGFW makes the creation of redundant clusters and multi-links for ISP connectivity very easy and manageable. We also verified that all traffic flowed without interruption, even when cluster nodes and links were forced offline.
McAfee NGFW’s AET (Advanced Evasion Technique) protection includes a number of built-in packet reassembly and inspection techniques that can detect and prevent attacks that disguise their traffic via multiple techniques such as these:
t&YQMPJUJOHUIF1"84 1SPUFDUJPO"HBJOTU8SBQQFE4FRVFODFOVNCFST
FYUFOTJPOTUP5$1UPDIBOHFUIFUJNFTUBNQPGUIFIFBEFSUPEFMBZUIFQBDLFU
DPOGVTJOHTFDVSJUZUPPMTJOUPBMMPXJOHJUUPQBTT1 In addition, attackers can
randomize the payload data with tools that leverage these extensions. The NGFW platform can easily reverse this process, taking advantage of the same tcp_paws
libraries that attackers use.
t'SBHNFOUJOH*1WQBDLFUTJOUPTNBMMFSPOFTUPTQMJUVQBNBMJDJPVTQBZMPBE
This technique bypasses the signature matching used by most IPS and firewall platforms, but McAfee NGFW can reconstruct unusual, nonstandard fragmented packets for analysis with the same ipv4_frag libraries that attackers use.
t3FBSSBOHJOHQBDLFUEBUBXJUIiCJHFOEJBOwFODPEJOH This places the highest
(most significant) byte of a packet first, instead of last (the normal order), confusing the firewall or IPS into thinking the packets are benign because they don’t match any entries in the signature database for malicious programs. McAfee NGFW uses the Microsoft RPC big-endian libraries to analyze this type of traffic and foil this attack.
For our test, we used the publicly available McAfee Evader attack simulator, which can generate well-known exploits (similar to those from Metasploit and other attack frameworks) to attack systems and test the efficacy of defense systems.2
Packet Inspection and Reassembly with AET
1 PAWS is described in IETF RFC 1323, www.ietf.org/rfc/rfc1323.txt 2 http://evader.mcafee.com
Packet Inspection and Reassembly with AET
(CONTINUED)
We tested a number of well-known attacks that modern defense systems should always catch, such as exploits attacking unpatched Windows systems missing the MS08-067 patch. The Evader system configuration is shown in Figure 26.
The tool was targeting a Windows XP SP2 desktop system in our test environment, one that we knew to be susceptible to all the attacks preloaded into Evader. All attacks were going through a single-device firewall; the Windows Calculator application would open upon successful exploit of the XP desktop’s vulnerability.
Packet Inspection and Reassembly with AET
(CONTINUED)
For this test, we attempted three different exploits with IPv4 fragmentation, big-endian encoding, TCP timestamp and other evasions. When we ran these through the firewall cluster, McAfee NGFW decoded and normalized the traffic, performing a horizontal data stream analysis that examined all the protocol layers and detected all of the exploits hidden in the protocol layers; meanwhile, our target remained untouched. Logs of the attempts displayed in SMC are shown in Figure 27.
In this screenshot, all the red events are blocked attack traffic that correspond to the attacks we generated using the Evader tool. The green events are unrelated. McAfee NGFW handled all the protocol anomaly detection and packet inspection automatically in software—so we did not need to spend any time configuring protocol handlers to see accurate detection and prevention actions successfully taken.
After testing the various configuration options and features of McAfee Next Generation Firewall, we declared that the system works as advertised in all categories. Through McAfee Security Management Center, all functions were readily available and easy to
find. We successfully added a new node to a firewall cluster, pushed a policy to the device and tested that the policy was functioning properly. Then, we created a new policy that restricted traffic from a specific user and tested this successfully as well. McAfee NGFW’s VPN capabilities were simple to configure and evaluate. We created and tested client-based and site-to-site VPN policies. Both successfully enforced policies based on a variety of conditions over a VPN connection.
Availability features such as clustering and multiple WAN links were easy to configure. When tested, both worked with various components disabled, and we never
experienced a disruption in traffic passing through the devices.
Finally, McAfee NGFW’s advanced evasion detection capabilities worked as expected. We sent a number of well-known exploits through the firewall cluster, using several different protocol and application evasion tactics, and it caught all of them.
In short, McAfee NGFW was simple to configure and offered powerful firewalling and threat detection capabilities, while providing highly available and redundant connectivity and sophisticated, policy-based connection security.
About the Author
Sponsor
%BWF4IBDLMFGPSE is the founder and principal consultant with Voodoo Security, a SANS analyst,
instructor and course author, and a GIAC technical director. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft and CTO for the Center for Internet Security. Dave is the author of the Sybex book Virtualization Security. Recently, Dave co-authored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.
