This release of the product includes these new features that have been added since NGFW 5.5.

Transcription

1 Release Notes Revision A McAfee Next Generation Firewall Contents About this release New features Enhancements Known limitations Resolved issues System requirements Installation instructions Upgrade instructions Additional information Build version Compatibility Known issues Find product documentation About this release This document contains important information about the current release. We strongly recommend that you read the entire document. The Security Engine product name has changed in this release. The Security Engine is now known as the McAfee Next Generation Firewall or NG. NG engines are still represented by Security Engine elements in the Management Client. New features This release of the product includes these new features that have been added since NG 5.5. New features introduced in NG 5.7 Botnet detection McAfee NG now supports botnet detection using the following new Command and Control (C&C) communication detection methods: - Decryption-based detection: Detect known characteristics of the botnet C&C, port number, carrier, encryption protocol, and key material. - Message length sequence analysis detection: Extract message length for sequence analysis for botnet C&C detection. 1

2 New features introduced in NG 5.6 Virtual Security Engines in and Layer 2 Firewall roles McAfee NG now supports Virtual Security Engines in the Virtual and Layer 2 Firewall roles. Support for the Virtual Firewall/VPN role was added in version 5.5. Virtual Security Engines are logically separate engines that run as virtual engine instances on a physical engine device. You can now use a physical NG device as a Master Engine to provide resources for Virtual Security Engines. This means that the same Master Engine can simultaneously have different security policies, separate routing tables, and overlapping IP addresses for different interfaces (reserved by different Virtual Security Engines). You can configure up to 250 Virtual Firewalls, Virtual engines, or Virtual Layer 2 Firewalls per Master Engine. The Master Engine can be clustered. The Virtual Security Engines are load-balanced between the Master Engine nodes. One Master Engine handles all the traffic of one Virtual Security Engine at any given time. All Virtual Engines hosted by one Master Engine or Master Engine cluster must be in the same role. Virtual Security Engines do not require individual licenses. Instead, the license for the Master Engine defines how many Virtual Resources can be created. The number of Virtual Resources limits the number of Virtual Security Engines. In this major version, Virtual Security Engines can be used in the Firewall/VPN,, and Layer 2 Firewall roles with some limitations in normal engine features. Virtualization works across several administrative Domains. For example, the Master Engine can be in the Shared Domain and the Virtual Security Engines can be in one or several other Domains. Enhancements This release of the product includes these enhancements added since NG 5.5. Enhancements introduced in NG Anti-virus robustness improved Anti-virus robustness and self-protection have been improved. Botnet detection improved Botnet detection coverage has been expanded. OpenSSL library updated to the latest version The OpenSSL library has been updated to version 1.0.1j. Enhancements introduced in NG 5.7 Application detection coverage has been improved The McAfee AppPrism Application signature library is now used for application detection with McAfee NG. Anti-virus engine changed The anti-virus engine used in McAfee NG engines is now based on the McAfee Anti-Virus Scanning Engine. Out of window TCP resets dropped in Normal Connection Tracking Mode without inspection Protection against spoofed TCP reset packets has been improved in Normal Connection Tracking Mode. In the new TCP reset protection feature, RFC 5961 blind reset attack protection is implemented in the engine on behalf of the connection endpoints. The feature is configured through the TCP Reset Sensitivity setting in the DoS Protection Settings in the engine properties. Rule tag logging Connection closed log entries now also contain the rule tag associated with the connection. Related connection log entries now also contain the rule tag of the parent connection.

3 TLS 1.2 support in TLS inspection TLS protocol version 1.2 is now supported in TLS inspection for client protection and server protection. Decompression in inspection By default, the engine now also decompresses.zip archives that have been compressed using the Deflate method when inspecting traffic. Enhancements introduced in NG 5.6 Scan detection You can configure Security Engines and Master Engines to detect if network ports are scanned. When you enable Scan Detection on a Firewall, engine, Layer 2 Firewall, Master Engine, or Virtual Security Engine, a log is generated if scan probes are detected. Security Engines and Master Engines support IPv4 and IPv6 protocols and detect TCP, UDP, and ICMP scan types. Scan detection has been redesigned in version 5.6. Scan detection performance has been optimized for multi-core platforms and the feature activation has been simplified. You can now define a general Scan Detection setting in the engine properties. You can override the general Scan Detection settings in Access rules. SYN flood protection You can configure Security Engines to detect SYN flood attacks. When you enable SYN flood protection on a Firewall, engine, Layer 2 Firewall, or Virtual Security Engine, a log is generated if a SYN flood is detected. The engine uses the SYN cookie method to prevent SYN packets sent from spoofed IP addresses from reaching the target host. When a SYN flood attack ends, a new log event is generated. The SYN flood protection feature has been redesigned in version 5.6. The performance of SYN flood protection has been optimized for multi-core platforms and the feature activation has been simplified. You can define SYN flood protection settings as part of general DoS Protection settings in the engine properties. You can override the general DoS Protection settings in Access rules. Protection against slow HTTP requests You can configure the Security Engines to detect very slow HTTP GET or POST requests that may indicate an attack against web applications and may cause a DoS situation. The engine uses a faster timeout for HTTP connections if the HTTP GET and POST requests are very slow. You can define protection against slow HTTP requests as part of general DoS Protection settings in the engine properties. You can override the general DoS Protection settings in Access rules. VLAN Interface support for engines and Layer 2 Firewalls You can now use VLAN Interfaces and re-tag network traffic on engines and Layer 2 Firewalls. The settings are configured in the engine properties. Ethernet MTU can be defined for engine and Layer 2 Firewall interfaces The Ethernet Maximum Transmission Unit (MTU) can now be defined for engine and Layer 2 Firewall interfaces in the engine properties. Improved connection tracking configuration for engines and Layer 2 Firewalls You can now choose between three connection tracking modes (Strict, Normal, and Loose) in the engine properties. You can override the engine-specific setting in Access rules. Interface link aggregation improved for Firewalls Interface link aggregation performance has been improved in this major version. 3

4 Known limitations High-Security Inspection Policy and Strict TCP mode are not supported in asymmetrically routed networks in and Layer 2 Firewall roles The High-Security Inspection Policy and Strict TCP mode are not supported in asymmetrically routed networks or in environments where an NG in the or Layer 2 Firewall role is directly connected to a load-balancing or High Availability network device. It is recommended to base policies on the Medium-Security Inspection Policy in such cases. In Strict TCP mode and in the High-Security Inspection Policy, the engine controls the progress of a TCP connection and checks that the TCP handshake proceeds according to the TCP protocol. The same engine node must be able to see all the packets in the connection. In Strict TCP mode, the engine also enforces the packet direction (for example, SYN and SYN-ACK packets are not allowed from the same interface). The TLS inspection and URL filtering features use Strict TCP mode and are not supported in asymmetrically routed networks in the and Layer 2 Firewall roles. SSL/TLS inspection and web filtering are not supported in capture (IDS) mode The TLS inspection and URL filtering features are not supported in capture (IDS) mode. Inline Interface Disconnect Mode in role The Inline Interface Disconnect Mode is not supported on Virtual Appliances, software installations, appliance models other than -6xxx, or modular appliance models on bypass NIC modules.

5 Resolved issues These issues have been resolved since version NG For a list of issues that have been fixed in earlier releases, see the Release Notes for the specific release. Issue Role Description Inspection process might restart (#90139) L2 The inspection process might restart when some types of HTTP traffic are inspected. Link Status test fails after configuring new interface for new Virtual Resource (#101522) SSL/TLS inspection might not handle all handshake messages correctly (#105943) Using anti-virus and TLS inspection might cause inspection process to restart (#108533) Only locally created blacklist entries can be removed from engine (#108932) IGMP Proxy might not work (#109420) DHCP packets might not be correctly balanced in a cluster (#109421) Destination Zone is not shown in logs (#109736) PXE protocol might not work through VPNs (#109863) Support for using interfaces with loopback IP addresses as VPN endpoints (#109928) Anti-virus database update increases memory consumption (#109944) Static route configuration might fail with large number of Tunnel Interfaces (#110024) L2 L2 L2 After adding an interface to a new Virtual Resource and installing the policy, the Link Status test fails and one of the nodes in the Master Engine Cluster goes offline. If the Virtual Resource is not associated with a Virtual Security Engine, the interface is not up. However, the Link Status Test is active if the Link Status test is set to run on all interfaces. SSL/TLS inspection might not handle all TLS handshake messages correctly, leading to connection errors when opening HTTPS connections that the engine is configured to decrypt and inspect. Using anti-virus and TLS inspection at the same time might cause the inspection process to restart. When using the sg-blacklist del or flush commands, only the blacklist entries created locally on the engine can be removed. In rare cases, the IGMP Proxy might not work in IGMPv2 mode. DHCP packets might not be correctly balanced in a loadbalanced cluster immediately after a cluster node has been rebooted. The Destination Zone is not shown in logs. The PXE protocol might not work through site-to-site VPNs. It is now possible to use Firewall interfaces that have loopback IP addresses as VPN endpoints. The memory consumption of the anti-virus feature increases when the anti-virus database is updated. When the Firewall engine configuration contains a large number of Tunnel Interfaces, some static routes through these interfaces might not be configured when the policy is uploaded. 5

6 Anti-virus process can leave scanned files on the engine (#110088) QoS class set with Continue rule does not work if Application matches are used in Access rules (#110438) Applying QoS configuration might cause engine to reboot (#110788) Refreshing the policy might fail when Browser- Based User Authentication is used (#110823) Hardware monitoring might stop working (#110990) Communication between User Agent and NG might not work (#111018) MTU setting for VLAN trunk might be incorrectly configured (#111078) Problems with application detection accuracy when using Firewall license (#111179) Backing up dynamic routing configuration does not work with Virtual Security Engines (#111315) Authentication timeout setting in Access rules affects VPN client connections (#111721) IPsec NAT-T keepalive packets might be dropped (#111736) Engine might stop sending ICMP messages (#111747) SIP messages with large payloads are not handled correctly (#111809) L2 L2 L2 L2 L2 L2 The anti-virus feature can leave scanned files in /spool/av/scan. A QoS class set with a Continue rule does not work correctly if Application matches are used in Access rules. In rare cases, refreshing the policy when QoS is configured might cause the engine to reboot. Refreshing the policy might fail when Browser-Based User Authentication is used. In rare cases, hardware monitoring might stop working. This causes operations that depend on hardware monitoring, such as sginfo collection, to stop. The User Agent might stop forwarding user information to the engine if the connectivity between the User Agent and the engine is not working reliably. The MTU setting for the VLAN trunk might be incorrectly set in some configurations. When you use application detection on a Firewall that has a Firewall license, application detection can only identify a subset of applications compared to a Firewall that has a Security Engine license. Backing up a dynamic routing configuration does not work with Virtual Security Engines when Master Engines are running in active-active mode. When the VPN client connection matches an Access rule that has an authentication timeout defined, the mobile VPN user authentication inherits the timeout setting. This can lead to a situation where a mobile VPN user is not able to access internal resources because authentication has timed out, but the VPN tunnel is still up. In some cluster configurations, IPsec NAT-T keepalive packets might be incorrectly treated as spoofed packets. The engine might stop sending ICMP messages after an arbitrary length of time. SIP messages with large payloads are not handled correctly. This leads causes open related connections to fail.

7 Traffic that matches Ethernet rules using MAC addresses is not inspected (#111836) Inspected connections might fail when dynamic source NAT is applied (#111873) Engine might drop SYN packets (#111876) Route-Based VPN packets might be dropped on Firewall Clusters (#112070) SunRPC connections might fail (#112105) IPv6 traffic over IPsec VPN with IPv4 endpoints does not work (#112164) Processing NATed ICMPv6 packets can cause engine to restart (#112266) Inspecting compressed files can lead to inspection process restarting (#112280) RPC connections can cause engine to restart (#112312) VPN process might restart (#112344) Inspecting tunneled traffic can lead to a memory leak (#112397) Engine might use wrong certificate fingerprint in SMC connection verification (#112422) Logs related to inspected GRE traffic might be missing information (#112463) Decryption of POP3S or IMAPS traffic might not work (#112480) L2 L2 L2 L2 L2 L2 L2 If traffic matches an Ethernet rule that specifies MAC addresses, the traffic might not be sent for deep inspection, even if deep inspection is enabled in the policy. Inspected connections might fail when dynamic source NAT is applied. The engine might prevent a new connection from being established if the connection uses the same IP address and port pairs as a previous connection. Route-Based VPN packets might be dropped as spoofed on Firewall Clusters. SunRPC connections through the engine might fail. IPv6 traffic over an IPsec VPN with IPv4 endpoints does not work. The IPsec tunnel is negotiated but traffic is not sent into the tunnel. Processing NATed ICMPv6 packets can cause the engine to restart. Inspecting compressed files can cause the inspection process to restart. If RPC connections originated from a node are allowed in a rule using the RPC protocol agent, the engine might restart. In rare cases, the VPN process might restart. This causes established VPN connections to fail. Inspecting tunneled traffic can cause a memory leak. If the management CA is changed from RSA to ECDSA or from ECDSA to RSA, and the Management Server certificate fingerprint has been defined in the engine, the engine tries to verify the management connection using the previous fingerprint. Some information might be missing from logs related to inspected GRE tunneled traffic. Decryption of POP3S or IMAPS traffic might not work. 7

8 Engine might reboot when refreshing the policy (#112481) VPN-related information missing from logs with applications (#112526) Master Engine might reboot (#113059) Engine might not answer SNMP queries sent to Interfaces with dynamic IP addresses (#113074) Using dynamic routing can cause the engine to reboot when refreshing the policy. Application logs might not contain all VPN-related information. The Master Engine might reboot when it is processing connections that use the H323, Oracle, or RSH Protocol Agents, and NAT is applied to the connections. The engine might not answer SNMP queries that are sent to interfaces that have dynamic IP addresses. System requirements McAfee NG appliances Appliance model Supported roles -315 Firewall/VPN MIL-320 Firewall/VPN L321 Firewall/VPN NGF321 Firewall/VPN,, and Layer 2 Firewall L325 Firewall/VPN NGF325 Firewall/VPN,, and Layer 2 Firewall Firewall/VPN Firewall/VPN Firewall/VPN and Layer 2 Firewall and Layer 2 Firewall and Layer 2 Firewall 1035 Firewall/VPN,, and Layer 2 Firewall 1065 Firewall/VPN,, and Layer 2 Firewall 1301 Firewall/VPN,, and Layer 2 Firewall 1302 Firewall/VPN,, and Layer 2 Firewall 1402 Firewall/VPN,, and Layer 2 Firewall 3201 Firewall/VPN,, and Layer 2 Firewall 3202 Firewall/VPN,, and Layer 2 Firewall 3205 Firewall/VPN,, and Layer 2 Firewall 3206 Firewall/VPN,, and Layer 2 Firewall 5201 Firewall/VPN,, and Layer 2 Firewall 5205 Firewall/VPN,, and Layer 2 Firewall 5206 Firewall/VPN,, and Layer 2 Firewall

9 Some features in this release are not available for all appliance models. See and for up-to-date appliance-specific software compatibility information. McAfee appliances support only the software architecture version (32-bit or 64-bit) that they are shipped with. Certified Intel platforms McAfee has certified specific Intel-based platforms for the Next Generation Firewall. Tested platforms can be found from McAfee Support Knowledge Center ( under the Next Generation Firewall product. We strongly recommend using certified hardware or a pre-installed McAfee appliance as the hardware solution for new McAfee NG installations. If it is not possible to use a certified platform, the NG can also run on standard Intel-based hardware that fulfills the hardware requirements. Basic NG hardware requirements Intel Core 2 / Intel Xeon based hardware IDE hard disk (IDE RAID controllers are not supported) and CD-ROM drive Memory: 2 GB RAM minimum for 32-bit (i386) installation 8 GB RAM minimum for 64-bit (x86-64) installation VGA-compatible display and keyboard One or more certified network interfaces for the Firewall/VPN role 2 or more certified network interfaces for with IDS configuration 3 or more certified network interfaces for Inline or Layer 2 Firewall For more information on certified network interfaces, see Requirements for Master Engines Each Master Engine must run on a separate physical NG device. For more details, please read the hardware requirements document at All the Virtual Security Engines hosted by a Master Engine or Master Engine cluster must have the same role and the same Failure Mode ( fail-open or fail-close ). Master Engines can allocate VLANs or interfaces to Virtual Security Engines. If the Failure Mode of the Virtual engines or Virtual Layer 2 Firewalls is Normal (fail-close) and you want to allocate VLANs to several engines, you must use the Master Engine cluster in standby mode. Cabling requirements for Master Engine clusters that host Virtual engines or Layer 2 Firewalls: Failure Mode Bypass (fail-open) requires serial cluster cabling. Failure Mode Normal (fail-close) requires Layer 2 Firewall cluster cabling. For more information on cabling, see the McAfee NG Reference Guide for and Layer 2 Firewall Roles. 9

10 Requirements for Virtual Appliance Nodes VMware ESXi versions 5.1 and GB virtual disk 1 GB RAM minimum, 2 GB recommended if inspection is used A minimum of one virtual network interface for the Firewall/VPN role, three for or Layer 2 Firewall roles The following limitations apply when a McAfee NG is run as a virtual appliance node in the Firewall/VPN role: Only Packet Dispatching CVI mode is supported. Only Standby clustering mode is supported. Heartbeat requires a dedicated non-vlan-tagged interface. The following limitations apply when a McAfee NG is run as a virtual appliance node in the or Layer 2 Firewall role: Clustering is not supported. Installation instructions Note The sgadmin user is reserved for McAfee use on Linux, so it must not exist before the McAfee Security Management Center is installed for the first time. The main installation steps for the McAfee Security Management Center (SMC) and the NG engines are as follows: 1. Install the Management Server, the Log Server(s), and optionally the Web Portal Server(s) and the Authentication Server(s). 2. Import the licenses for all components (you can generate licenses at 3. Configure the Firewall,, or Layer 2 Firewall elements with the Management Client using the Security Engine Configuration view. 4. Generate initial configurations for the engines by right-clicking each Firewall,, or Layer 2 Firewall element and selecting Save Initial Configuration. 5. Make the initial connection from the engines to the Management Server and enter the one-time password provided during Step Create and upload a policy on the engines using the Management Client. The detailed installation instructions can be found in the product-specific installation guides. For a more thorough explanation of using the McAfee Security Management Center, refer to the Management Client Online Help or the McAfee SMC Administrator s Guide. For background information on how the system works, consult the McAfee SMC Reference Guide. All guides are available for download at

11 Upgrade instructions McAfee NG version requires an updated license if upgrading from version 5.6.x or lower. The license upgrade can be requested at Install the new license using the Management Client before upgrading the software. The license is updated automatically by the SMC if communication with McAfee servers is enabled and the maintenance contract is valid. Note The anti-virus engine changes from ClamAV to McAfee when upgrading from a version lower than to version or higher. To upgrade and maintain anti-virus scanning capability, these steps must be taken: 1. Upgrade the SMC to version 5.7 or higher and the engine to version or a higher 5.5 version. 2. Before upgrading the engine, issue this command for each engine from the Monitoring view in the Management Client: Commands Update Anti-Virus Database 3. Wait until the Appliance Status monitoring confirms that the new anti-virus signature database has been downloaded. 4. Upgrade the engine using the remote upgrade feature normally. If the engine does not have the new anti-virus database available before the upgrade, the upgrade can be done but it takes some time before anti-virus is operational again after the upgrade. To upgrade the engine, use the remote upgrade feature or reboot from the installation CD and follow the instructions. Detailed instructions can be found in the McAfee NG Installation Guide for Firewall/VPN Role and the McAfee NG Installation Guide for and Layer 2 Firewall Roles. Note McAfee NG appliances support only the software architecture version that they are pre-installed with. 32-bit versions (i386) can only be upgraded to another 32-bit version and 64-bit versions (x86-64) can only be upgraded to another 64-bit version. Clusters can only have online nodes using the same software architecture version. State synchronization between 32-bit and 64-bit versions is not supported. Changing architecture for third-party server machines using software licenses requires full re-installation using a CD. Upgrading to any 5.7.x version is only supported from a 5.5.x, 5.6.x, or 5.7.x version. If you are running a lower version, upgrade first to the highest 5.5.x version following the instructions in the release notes for that version. Note If you have not changed the root password since engine version 4.x, change the root password before upgrading using the sg-reconfigure tool or the Management Client. If the upgrade is done without changing the root password, root login to the engine does not work after upgrading to or a higher version until the password has been reset in the Management Client. It is recommended to change the root password in any case, as the salted hash of the root password is stored using a stronger hash (SHA-512) in versions and higher. Additional information In this major version New brand Stonesoft Management Center is now called McAfee Security Management Center. At the same time, we have changed the main application icons, the OS level icons, the look and feel of the SMC installer, the login page, the Getting Started page, the Web Start page, the Web Portal, the browser-based user authentication pages, the Online Help, and the SMC API documentation pages. We have also updated the Windows Service names and the default installation folder paths. The Security Engine product name has also changed in this release. The Security Engine is now known as the McAfee Next Generation Firewall or NG. NG engines are still represented by Security Engine elements in the Management Client. 11

12 Build version McAfee Next Generation Firewall version build version is Product Binary Checksums sg_engine_ _i386.iso SHA1SUM: 2a2687aa3f8a3d178c86ff68d477921d1da69848 SHA512SUM: 5a90624ab1a3e3dff23b6b05fb5997a9adbd0a33969ba0d6668baedfa264bacc10a247ae800df7ccb00a90fc f211edbcb f9ef4b0e f2 sg_engine_ _i386.zip SHA1SUM: b5e7cf1dbe520bfa f72a2178aab99b3eb SHA512SUM: 6dcb961f9ccee789c81f409bd0682e6b307905c7d0dfd ea8c562162b58c891a2fd5f0d2845d1a0 b58728f000c218dae6c6cf80dd1c215da20e37f95 sg_engine_ _x86-64.iso SHA1SUM: b4f9cc08f7d3c56567b40c16a17f0358ee35504c SHA512SUM: d683e75220c344c65c1946c8c2a036fc51dd9d685e6e76739d74da91c9eaaed8027ed0676a88dd12e37e67 2b1b1caa98b9167e6c2b31f49b375419d596a5e20d sg_engine_ _x86-64.zip SHA1SUM: a6672a84d36789f3a16a88c0155fb9e404455ae4 SHA512SUM: 4502b94260a680a5dd651324ee1c40bb91e97a6edba83216ec43ae7a1ef1a10e6ad0de210e2b02f60c7e5e f24b9046e2dad696f04d57ca2a5fd40ed1 sg_engine_ _x86-64-small.iso SHA1SUM: 630db7a71e93a8ac98f2581fc07a0ea568d21ef8 SHA512SUM: f6ed4ab993a36ca6d45be b1cd3c74b08c1c461a278135e4fcc622e229576a6923a28b b2aeb8f277c34fbcc4956e8d7926d9620c0372e sg_engine_ _x86-64-small.zip SHA1SUM: a6672a84d36789f3a16a88c0155fb9e404455ae4 SHA512SUM: 4502b94260a680a5dd651324ee1c40bb91e97a6edba83216ec43ae7a1ef1a10e6ad0de210e2b02f60c7e5e f24b9046e2dad696f04d57ca2a5fd40ed1

13 Compatibility Minimum McAfee NG version is compatible with the following component versions: McAfee Security Management Center or higher Dynamic Update 545 or higher Stonesoft IPsec VPN Client or higher Server Pool Monitoring Agent or higher User Agent or higher Known issues The current important known issues of McAfee NG version are described in the table below. Issue Role Description Link aggregation issues (#109104) The interface link aggregation driver has issues that affect proper LACP operation. The drivers are updated in NG versions and higher. Find product documentation McAfee provides the information you need during each phase of product implementation, from installation to daily use and troubleshooting. After a product is released, information about the product is entered into the online Knowledge Center. 1. Go to the McAfee ServicePortal at and click Knowledge Center. 2. Enter a product name, select a version, then click Search to display a list of documents. 13

14 Copyright 2014 McAfee, Inc. Do not copy without permission. McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other names and brands may be claimed as the property of others. 00-A