Stonesoft Security Engine. Release Notes for Version 5.4.6

Transcription

1 Stonesoft Security Engine Release Notes for Version Created: September 2, 2013

2 Table of Contents What s New... 3 New Features in Role... 3 New Features in and Layer 2 Firewall Roles... 4 Enhancements... 5 Other Changes... 8 Known Limitations... 8 System Requirements... 9 Stonesoft Appliances... 9 Certified Intel Platforms Basic Security Engine Hardware Requirements Requirements for Virtual Nodes Build Version Product Binary Checksums Compatibility Installation Instructions Upgrade Instructions Known Issues... 14

3 What s New Stonesoft Security Engine is a maintenance release for the new combined Stonesoft Security Engine. The Stonesoft Security Engine combines the previously separate code branches of the and /IDS product lines. The engine software is now a combined Stonesoft Security Engine that supports all previous functionalities of the separate engines and the new functionality introduced in version 5.4 simply by changing the configuration and licensing. Together with Stonesoft modular appliances, this provides great flexibility for end users, as the engine can be reused in different deployment scenarios. The same Security Engine software is also used with engine-specific and licenses when the engine is upgraded to version 5.4 or higher. New Features in Role Features that have been added since Stonesoft version 5.3 are described in the table below. Feature Security Engine Full Inspection in Role Wider Application Identification Support Web Filtering for HTTP Over IPv6 Integrated Traffic Capture Route-Based VPN Description In version 5.4, Stonesoft launched a new Security Engine product that can be run as a (layer 3),, or Layer 2 Firewall. If you have purchased a Security Engine license, you can change the role of the engine any time according to your changing business requirements. There is no Security Engine element in the SMC. Instead, there are Firewall,, and Layer 2 Firewall elements. The same software also supports traditional engine-specific and licenses. The role now has the same inspection coverage as the role. Security Engine licenses include this feature by default. For traditional licenses, this can be enabled with an add-on license. The role can now also identify non-http-based applications. Application identification coverage is also wider in all roles compared to previous versions. Web filtering is now also supported for HTTP over IPv6 connections. engines now contain an integrated traffic capture tool that allows you to collect tcpdumps from any interface and from any Firewall cluster simultaneously through a single Management Client command. It is also possible to set filters for traffic captures for each interface. The tcpdump files are always stored on the Management Server and can also be retrieved automatically using the Management Client. The role adds support for the Route-Based VPN. The Route-Based VPN allows you to create tunnels between Firewall interfaces that are designated as tunnel End-Points. Any traffic that is routed to the specified interfaces and allowed by the Access rules is sent into the tunnel. You can also use the GRE and IP-IP tunneling protocols to direct multicast traffic into the VPN tunnels. This enables the use of dynamic routing protocols over VPNs. 3 Stonesoft Security Engine Release Notes for Version 5.4.6

4 New Features in and Layer 2 Firewall Roles Features that have been added since Stonesoft version 5.2 are described in the table below. Feature Security Engine Web Filtering for HTTP Over IPv6 TLS Matching Application Identification User Identification and Access Control Bandwidth Management and QoS Access Control by Domain Names Access Control by Zones Layer 2 Firewall Role Active-standby clustering in Layer 2 Firewall Role Description In version 5.4, Stonesoft launched a new Security Engine product that can be run as a (layer 3),, or Layer 2 Firewall. If you have purchased a Security Engine license, you can change the role of the engine any time according to your changing business requirements. There is no "Security Engine" element in the SMC. Instead, there are Firewall,, and Layer 2 Firewall elements. The same software also supports traditional engine-specific and licenses. Web filtering is now also supported for HTTP over IPv6 connections. TLS Matches define matching criteria that is checked against the server certificate in TLS connections. In addition to the predefined TLS Matches, you can optionally define your own TLS Matches to override the properties of an Application in an Access rule. Applications provide a way to dynamically identify traffic patterns related to the use of a particular application. Applications allow you to more flexibly identify traffic beyond specifying a network protocol and ports for TCP and UDP traffic with a Service element. In addition, Applications provide an accurate protocol context for deep inspection, which reduces false positives. Applications can be used as matching criteria in Access rules. This feature has previously been available only for the. You can now use User and User Group elements in the and Layer 2 Firewall rules to allow specific users to access services without requiring user authentication. The users must be stored on a Microsoft Active Directory server, and the User Agent must be installed on a Windows system in the same domain to associate users with IP addresses. This feature has previously been available only for the. Traffic management and QoS are now available for both and Layer 2 Firewall roles. Supported new features are: Policy-based traffic shaping Guaranteed / maximum / bandwidth prioritization Differentiated Services Code Point (DSCP) matching and marking Bandwidth Management and QoS features have previously been available only for the. Domain Name elements represent an Internet domain that may be associated with multiple IP addresses. The engine automatically resolves the domain names to IP addresses. Domain Names can be used as matching criteria in the Access rules. This feature has previously been available only for the. Zone elements are interface references that can combine several network interfaces of an engine into one logical entity. You can use Zones in the Access rules to restrict traffic according to which interface(s) the traffic is traveling through. This feature has previously been available only for the. There is a new type of engine: Layer 2 Firewalls. Layer 2 Firewalls are basic firewalls with a limited set of functionalities. They provide access control and deep inspection of traffic. Layer 2 Firewalls inspect traffic in a very similar way to engines. The main difference is that Layer 2 Firewalls drop packets that have not specifically been allowed to pass according to the engine s policy. Additionally, the Layer 2 Firewall does not support fail-open interfaces. The Layer 2 Firewall now supports clustering in an Active-Standby configuration, providing link-layer redundancy for the Layer 2 Firewall. 4 Stonesoft Security Engine Release Notes for Version 5.4.6

5 Enhancements Enhancements that have been made since Stonesoft Security Engine Enhancement Source address can now be defined when Security Engine connects to User Agent Description In previous versions, when the Security Engine connected to the User Agent, the source address was decided based on routing. Now the "Source for Authentication Requests" option in the Security Engine Interface Properties defines which interface and IP addresses are used. Fixes Problems described in the table below have been fixed in Stonesoft Security Engine A workaround solution is presented for earlier versions where available. Synopsis Role Description Time settings in Access rules may not work if Security Engine hardware time changes (#79411) Sg-inspection process may create core dump files (#87402) Connections may not match correct rules when Logical Interfaces are used (#89889) DHCP requests for IPsec VPN Client's Virtual IP address contain only one of the user's group memberships (#90784) Related connections may not inherit idle timeout settings from parent connection (#91237) Web or traffic may get corrupted when anti-virus or anti-spam is used (#91533) Link Status test checks interfaces in bypass mode (#92767) Anti-spam feature may crash with some types of traffic (#93295) L2 L2 L2 L2 Access rules that have time settings defined may not work correctly in cases where the hardware time of the Security Engine changes. In some cases, the sg-inspection process on the Security Engine may create core dump files. Connections may not match the correct Access rules when Logical Interfaces have been defined in the rules. When the Firewall is configured to generate a DHCP request for the Virtual IP address of the IPsec VPN Client users and the Add Group Information option is enabled in the Gateway properties, only one of the groups to which the user belongs is added to the DHCP request. Idle timeout settings for related connections may not be inherited from the parent connection with FTP and MSRPC protocols. Instead, fixed one-hour or two-hour idle timeouts are used. Some HTTP, HTTPS, POP, or IMAP traffic may get corrupted if it is inspected by anti-virus. Some SMTP traffic may get corrupted if it is inspected by anti-spam or anti-virus. Even though an interface is in bypass mode, the Link Status test checks the status of the interface. As a result, an alert that the test failed is unnecessarily triggered. The anti-spam process may crash when it inspects certain types of traffic. Workaround for Previous Versions 5 Stonesoft Security Engine Release Notes for Version 5.4.6

6 Synopsis Role Description HTTP_Request-Unknown Situation is logged for non- HTTP traffic (#94589) Sg-reconfigure may stop working at interface configuration when Security Engine is in role (#95173) Firewall that has an interface with a dynamic IP address may use old IP address in Firewall Policy (#95195) Proxy ARP does not work on VLAN Interface if link aggregation is used on Single Firewall (#95326) 3G Modem may not initialize properly after reboot (#95335) Security Engine cannot always re-establish connection to BrightCloud servers (#95343) Firewall engine may run out of memory if 3G Modem is plugged in to the appliance but not used (#95449) Firewall may not use new dynamic IP address if PPP is used (#95506) Initial contact with Management Server may fail when initial configuration is fetched from Installation Server (#95516) Using single port as blacklisting criterion may not work (#95702) Generating IPsec VPN Client certificate request for Security Gateway does not work (#95797) FTP or MSRPC traffic may cause Security Engine to reboot itself (#96008) Timeouts set for Browser-Based User Authentication may not work (#96982) L2 L2 L2 L2 The HTTP_Request-Unknown Situation may appear in logs generated by non-http traffic when the Access rules have any of the following configurations: - The Log Application Information setting in the Logging options is set to Enforced - Deep Inspection is enabled in a rule in which the Service is ANY - Protocol identification is enabled using an Application element in which the default port is ANY. When running sg-reconfigure on a Security Engine that is in role, the sg-reconfigure wizard may stop working when you try to open the interface configuration page. When a Firewall has an interface with a dynamic IP address, it may continue to use the old IP address in the Access rules of the Firewall Policy. This causes connections from the new IP address to be discarded. Proxy ARP may not work on a VLAN Interface that is part of a link aggregation configuration on a Single Firewall. 3G Modem may not be properly initialized after reboot. A missing Modem Interface may cause the Firewall engine to return to the initial configuration state. The Security Engine cannot always re-establish a connection to the BrightCloud servers. As a result, the Security Engine is not able to check the URL categorization information. The Firewall engine may run out of memory when a 3G Modem is plugged in to the appliance but not used. If a Firewall has an interface with a dynamic IP address and the IP address changes, the Firewall may continue to use the old IP address in cases where PPP is used on the interface. Initial contact may fail in cases where the Firewall engine uses different interfaces to contact the Installation Server and the Management Server. Using a single port as the matching criterion for blacklisting traffic may not work. Generating an IPsec VPN Client certificate request for a Security Gateway does not work if the "ID Type" option is set to "Distinguished Name" in some of the Security Gateway end-points. In certain situations, FTP or MSRPC traffic may cause the Security Engine to reboot itself. In some situations, the firewall may not apply the configured timeout values for Browser-Based User Authentication. Because of this, the firewall may incorrectly log users out. Workaround for Previous Versions In an Inspection Policy, use an Exception that matches the HTTP_Request-Unknown Situation to set the Log Level to None. Reboot the Firewall engine by removing the power cable or turning the power off using the power switch. Reboot the Security Engine that cannot establish a connection to BrightCloud servers. Unplug the 3G Modem from the appliance. Reboot the Firewall engine. Reboot the Firewall engine or run sg-reconfigure. 6 Stonesoft Security Engine Release Notes for Version 5.4.6

7 Synopsis Role Description GRE and IP-IP traffic over Policy-Based VPN may be dropped after policy is refreshed (#97022) Existing inspected connections not checked when policy is reloaded (#97164) Inline Pair Link Speed test may fail if there are several Inline Interface pairs (#97445) IPv6 HTTP traffic does not work if a rule uses an HTTP Service with a Protocol Agent but not Deep Inspection (#95367) Challenge-response Authentication Methods do not work with Browser-Based User Authentication (#95103) L2 L2 GRE or IP-IP traffic that should be transferred over the Policy-Based VPN may be dropped after the policy is refreshed. When a policy is reloaded, the engine checks whether existing connections are still allowed, and terminates any connections that are not allowed by the new policy. Existing connections for which Deep Inspection is enabled are not re-checked and are never terminated when the policy is reloaded. This issue does not apply to connections where Anti-Virus or Anti-Spam are enabled. When there are several Inline Interface pairs, the Inline Pair Link Speed test may fail continuously. IPv6 HTTP traffic does not work if an IPv6 Access rule uses an HTTP Service with a Protocol Agent but Deep Inspection is not enabled for the rule. The following message is seen in the Firewall logs: "Could not instantiate Protocol Agent 8 (-22)". Challenge-response Authentication Methods, such as Mobile ID - Challenge, do not work with Browser- Based User Authentication. Workaround for Previous Versions Terminate the connections manually in the Connection Monitoring view. Disable the Inline Pair Link Speed test. Create a custom HTTP Service without a Protocol Agent and use that in the IPv6 Access rules or enable Deep Inspection for IPv6 HTTP traffic. 7 Stonesoft Security Engine Release Notes for Version 5.4.6

8 Other Changes Changes since previous major version are described in the table below. Change Naming and Branding Analyzer Element no Longer Used Shared Inspection Policy Description The StoneGate product name is replaced with Stonesoft in version 5.4. Stonesoft is used both as the company and product name. The application name is now Stonesoft Management Center. In addition to the application name, we have slightly changed the Management Client and Web Portal look-and-feel, statistics colors, Browser-Based User Authentication features, Management Client login screens, Web Start page, Welcome screen in the Management Client, Online Help, and other places in which the Stonesoft brand is visible. In version 5.4, the Analyzer functionalities have been transferred to the Log Server and to Security Engines, and the Analyzer is no longer used. Correlation is no longer limited to : correlations can now run simultaneously on the Log Server and on all engine roles. In addition, it is now possible to use the Terminate Action with correlation directly on the engines. Because of this change, additional steps are required for upgrading legacy Sensors, Sensor Clusters, and combined Sensor-Analyzers to version 5.4 or higher. It is still possible to manage version 5.2 Analyzers with SMC 5.4. However, after upgrading Sensors to 5.4, log data is sent directly to the Log Server instead of to the Analyzer component. Inspection rules have been separated from Firewall and Policy elements into a separate Inspection Policy element. This enables you to reuse the same Inspection Policy for multiple Security Engines. Known Limitations Before upgrading to this version, note the following limitations related to version 5.4 configuration. Limitation Dynamic overload handling is not available in and Layer 2 Firewall roles High-Security Inspection Policy and Strict TCP mode are not supported in asymmetrically-routed networks in and Layer 2 Firewall roles SSL/TLS Inspection and Web filtering are not supported in capture (IDS) mode Inline interface Disconnect Mode on role. Description The dynamic overload handling feature is not available in Firewall and Layer 2 Firewall roles. The High-Security Inspection Policy and Strict TCP mode are not supported in asymmetricallyrouted networks or in environments where a Security Engine 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 Security 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 Web Filtering features use Strict TCP mode and are not supported in asymmetrically-routed networks in and Layer 2 Firewall roles. The TLS Inspection and Web Filtering features are not supported in capture (IDS) mode. The inline interface Disconnect Mode is not supported on Virtual, software installations or appliance models other than -6xxx or modular (13xx, 32xx,52xx) appliance models on bypass NIC modules. 8 Stonesoft Security Engine Release Notes for Version 5.4.6

9 System Requirements Stonesoft Appliances Appliance model e L Supported roles and Layer 2 Firewall and Layer 2 Firewall and Layer 2 Firewall and Layer 2 Firewall and Layer 2 Firewall and Layer 2 Firewall 1035,, and Layer 2 Firewall 1065,, and Layer 2 Firewall 1301,, and Layer 2 Firewall 1302,, and Layer 2 Firewall 3201,, and Layer 2 Firewall 3202,, and Layer 2 Firewall 3205,, and Layer 2 Firewall 3206,, and Layer 2 Firewall 5201,, and Layer 2 Firewall 5205,, and Layer 2 Firewall 5206,, and Layer 2 Firewall Some features of this release are not available for all appliance models. See and for up-to-date appliance-specific software compatibility information. Stonesoft appliances support only the software architecture version (32-bit or 64-bit) that they are shipped with. 9 Stonesoft Security Engine Release Notes for Version 5.4.6

10 Certified Intel Platforms Stonesoft has certified specific Intel-based platforms for the Stonesoft Security Engine. The list of certified platforms can be found at We strongly recommend using certified hardware or a preinstalled Stonesoft appliance as the hardware solution for new Stonesoft Security Engine installations. If it is not possible to use a certified platform, the Stonesoft Security Engine can also run on standard Intel-based hardware that fulfills the Stonesoft hardware requirements. Basic Security Engine 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 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 Virtual Nodes VMware ESXi versions 5.0 and GB virtual disk 1 GB RAM minimum, 2 GB recommended if inspection is used A minimum of one virtual network interface for the role, three for or Layer 2 Firewall roles The following limitations apply when a Stonesoft Security Engine is run as a virtual node in the 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 Stonesoft Security Engine is run as a virtual node in the or Layer 2 Firewall role: Clustering is not supported. 10 Stonesoft Security Engine Release Notes for Version 5.4.6

11 Build Version The Stonesoft Security Engine version build version is Product Binary Checksums sg_engine_ _i386.iso MD5SUM 6b24259ff07dfe86e7bb4fb2e667cdd7 SHA1SUM 3bd38f94661e2634b f2198f3c72 sg_engine_ _i386.zip MD5SUM ed4786f97b24ed18c321a4f3444b6b92 SHA1SUM dca3e7e7f84154ed510e3fbadd07f9b53e56ab58 sg_engine_ _x86-64.iso MD5SUM 0b875658a099a eb6102e65 SHA1SUM 8fb35f0fcacc296e2097aadb2dfc0e2d32a59439 sg_engine_ _x86-64.zip MD5SUM cf6a4d28bce81116d92441fcd325f472 SHA1SUM dd91ca2fe6a469373def8d671cb Compatibility Stonesoft Security Engine version is recommended to be used with the following Stonesoft component versions: Component Minimum Compatible Version Recommended Version Stonesoft Management Center Latest 5.4 maintenance version Stonesoft Dynamic Update 453 Latest available Stonesoft IPsec VPN Client Latest 5.4 maintenance version Stonesoft Server Pool Monitoring Agent Latest 4.0 or 5.0 maintenance version Stonesoft User Agent Latest available 11 Stonesoft Security Engine Release Notes for Version 5.4.6

12 Installation Instructions The main installation steps for Stonesoft Security Engine are as follows: 1. Install the Management Server, the Log Server(s), and the Management Client to host(s) to be used as the management system. The Authentication Server and Web Portal Server(s) need to be installed if the optional Authentication Server and Stonesoft Web Portal are used. 2. Configure the Firewall,, or Layer 2 Firewall element using the Management Client. 3. Generate an initial configuration for the engines by right-clicking the element and selecting Save Initial Configuration. 4. If you are not using Stonesoft appliances, install the engines by rebooting the machines from the installation DVD. 5. Make the initial connection from the engines to the Management Server and enter the onetime password provided during step Create and upload a policy on the engines using the Management Client. 7. Command the nodes online by right-clicking the element and selecting Commands Go Online. The detailed installation instructions can be found in the Stonesoft Management Center Installation Guide, Installation Guide, and and Layer 2 Firewall Installation Guide documents. For more information on using the Stonesoft system, refer to the Management Client Online Help or the Stonesoft Administrator s Guide. For background information on how the system works, consult the Stonesoft Management Center Reference Guide, Reference Guide, and and Layer 2 Firewall Reference Guide. Upgrade Instructions Stonesoft Security Engine version requires an updated license if you are upgrading from version 5.3.x, 5.2.x, or earlier. The license upgrade can be requested at our website at Install the new license using the Management Client before upgrading the software. The license is updated automatically by SMC if communication with Stonesoft servers is enabled and the maintenance contract is valid. To upgrade the engine, use the remote upgrade feature or reboot from the installation DVD and follow the instructions. Detailed instructions can be found in the Installation Guide and and Layer 2 Firewall Installation Guide. NOTE Stonesoft 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 DVD. 12 Stonesoft Security Engine Release Notes for Version 5.4.6

13 Upgrading the to Security Engine version 5.4 automatically enables the role in the Security Engine. When running a version older than 5.3.0, you must first upgrade to the latest 5.3.x version following the instructions in the Release Notes for that version. Upgrading to version 5.4.x is not supported from other versions. Upgrading the to Security Engine version 5.4 automatically enables the role in the Security Engine. When running an version older than 5.2.0, you must first upgrade to the latest 5.2.x version following the instructions in the Release Notes for that version. Upgrading to version 5.4.x is not supported from other versions. Prior to version 5.4, engines consisted either of separate Sensor and Analyzer engines, or combined Sensor-Analyzer engines. In version 5.4, the Analyzer functionalities have been transferred to the Log Server and to the Security Engines, and the Analyzer is no longer used. Because of this change, additional steps are required for upgrading legacy Sensors, Sensor Clusters, and combined Sensor-Analyzers to version 5.4 or higher. Upgrading Sensors and Sensor Clusters to Engines: 1. Upgrade the engine software to Security Engine version 5.4 or higher. Use the remote upgrade feature or reboot from the installation DVD and follow the instructions. 2. Open the properties of the upgraded engine or engine cluster in the Management Client. 3. Select a Log Server. 4. Select None for the Analyzer and click OK. 5. Refresh the policy of the upgraded engine. For detailed upgrade instructions, see the section titled Upgrading Legacy Engines in the Stonesoft Administrator s Guide or the Management Client Online Help. Upgrading a Legacy Sensor-Analyzer to a Single Engine: 1. To check for references to the Analyzer node of the Sensor-Analyzer in the Management Client, right-click the Sensor-Analyzer element and select Tools References. If there are any references to the Analyzer, remove the references before the upgrade. 2. Upgrade the engine software to Security Engine version 5.4 or higher. Use the remote upgrade feature or reboot from the installation DVD and follow the instructions. 3. Right-click the Sensor-Analyzer element and select Configuration Upgrade to Single. The Sensor-Analyzer properties dialog opens. 4. Select a Log Server. 5. Select the Failure Mode (Bypass or Normal) for the Inline Interface(s). 6. Click OK to begin the conversion. 7. Refresh the policy of the upgraded engine. For detailed upgrade instructions, see the section titled Upgrading Legacy Engines in the Stonesoft Administrator s Guide or the Management Client Online Help. 13 Stonesoft Security Engine Release Notes for Version 5.4.6

14 Known Issues The current known issues of Stonesoft Security Engine version are described in the table below. For a full and updated list of known issues, consult our website at In the table below, the following abbreviations are used for the engine roles: : : Intrusion Prevention System L2: Layer 2 Firewall Synopsis Role Description Workaround Port scan detection can cause performance loss under SYN flood attack (#79063) SunRPC Protocol Agent is not supported in and Layer 2 Firewall roles (#79844) Non-stateful access control for ICMP in Layer 2 Firewall (#81807) Security engine displays log message State sync kernel event Setting node X failed (#82888) Using a VLAN Interface as the Control Interface does not work (#82993) Zone logging done according to packet instead of connection with inspection (#83175) TLS Match may generate false log events when SSL/TLS Inspection is not activated (#84071) L2 L2 L2 L2 L2 L2 L2 TCP port scan Situations can lead to high CPU load if the engine is under SYN flood attack. The SunRPC Protocol Agent is not supported in and Layer 2 Firewall roles. In the and Layer 2 Firewall roles, matching for non-tcp or non-udp traffic is packetbased. For this reason, incoming and outgoing ICMP traffic must be allowed separately in the Layer 2 Firewall Policy. The Security Engine 5.4 in the and Layer 2 Firewall roles displays the following log message: State sync kernel event Setting node X failed. This log message requires no administrator action. Using a VLAN Interface as the Control Interface does not work in the or Layer 2 Firewall roles. Zone matching follows the packet instead of the connection. For example, inspection of an FTP connection may cause several logs that have alternating Destination and Source Zones, even though the logged Destination and Source addresses are always the same. The TLS_Decrypted-Domain Situation is triggered when the detected domain name does not match any domain names that are excluded from decryption. The description of the Situation is the following: The connection will be decrypted. However, when no Client Protection Certificate Authority or Server Protection Credentials are configured for SSL/TLS Inspection, the connection is never decrypted. Disable the following TCP port scan Situations: TCP_Stealth_Scan_Started TCP_SYN_Scan_Started Aggressive_TCP_Scan_Started 14 Stonesoft Security Engine Release Notes for Version 5.4.6

15 Synopsis Role Description Workaround DNS protocol enforcement may drop valid DNS responses (#84145) Some statistics items do not show any data for or Layer 2 Firewall engines (#84316) SNMP IP-MIB: ipinreceives counter does not work correctly (#84964) IPv6 ICMP Packet Too Big messages not allowed by default (#87542) L2 L2 L2 DNS responses with additional response records (RRs) trigger the DNS_Server-UDP- Extra-Data Situation, even though additional response records are valid in queries as specified in RFC 2671: Extension Mechanisms for DNS (EDNS0). If DNS protocol enforcement has been activated in a custom DNS Service element, this also triggers the DNS_Protocol_Violation Situation, and the response is terminated. The following statistics items that were available for version 5.2 and earlier do not show the following data: - Lost traffic, IF (Bits) - Received traffic - Allowed inspected TCP/UDP connections - Allowed inspected TCP/UDP connections - Allowed uninspected TCP/UDP connections - Discarded TCP/UDP connections The IP-MIB ipinreceives counter included in the SNMP IP-MIB does not provide the total number of input datagrams received from interfaces. ICMPv6 Packet Too Big messages generated for VPN path MTU discovery originate from cluster CVI addresses instead of NDI addresses. By default, these messages are not allowed from cluster CVI addresses. Disable DNS protocol enforcement from the custom DNS Service element (it is disabled by default). Add a rule to allow ICMPv6 Packet Too Big messages from the cluster CVI addresses. 15 Stonesoft Security Engine Release Notes for Version 5.4.6

16 Copyright and Disclaimer Stonesoft Corporation. All rights reserved. These materials, Stonesoft products, and related documentation are protected by copyright and other laws, international treaties and conventions. All rights, title and interest in the materials, Stonesoft products and related documentation shall remain with Stonesoft and its licensors. All registered or unregistered trademarks in these materials are the sole property of their respective owners. No part of this document or related Stonesoft products may be reproduced in any form, or by any means without written authorization of Stonesoft Corporation. Stonesoft provides these materials for informational purposes only. They are subject to change without notice and do not represent a commitment on the part of Stonesoft. Stonesoft assumes no liability for any errors or inaccuracies that may appear in these materials or for incompatibility between different hardware components, required BIOS settings, NIC drivers, or any NIC configuration issues. Use these materials at your own risk. Stonesoft does not warrant or endorse any third party products described herein. THESE MATERIALS ARE PROVIDED "AS-IS." STONESOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION CONTAINED HEREIN. IN ADDITION, STONESOFT MAKES NO EXPRESS OR IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR USE WITH RESPECT TO THE INFORMATION CONTAINED IN THESE MATERIALS. IN NO EVENT SHALL STONESOFT BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL OR INCIDENTAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING FROM THE USE OF THESE MATERIALS, EVEN IF ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH DAMAGES. Trademarks and Patents Stonesoft, the Stonesoft logo and StoneGate are all trademarks or registered trademarks of Stonesoft Corporation. Multi-Link technology, Multi-Link VPN, and the Stonesoft clustering technology-as well as other technologies included in Stonesoft-are protected by patents or pending patent applications in the U.S. and other countries. All other trademarks or registered trademarks are property of their respective owners. Stonesoft Corporation Itälahdenkatu 22A FI Helsinki Finland Tel Fax Stonesoft Inc Crown Pointe Parkway Suite 900 Atlanta, GA USA Tel Fax Copyright 2013 Stonesoft Corporation. All rights reserved. All specifications are subject to change.