New firewall behavior

This section lists the changes made to the automatic behavior of the firewall when your SNS firewall in version 4.3.32 LTSB is updated from the latest 3.7 LTSB version available.

Changes introduced in version 4.3.31 LTSB

Find out more

SMC/Encryption suites that can be used with an SNS firewall - Communications between an SNS firewall and its SMC administration server can now use only these encryption suites:

  • TLS_AES_128_GCM_SHA256,
  • TLS_CHACHA20_POLY1305_SHA256,
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
  • TLS_EMPTY_RENEGOTIATION_INFO_SCSV.

 

Changes introduced in version 4.3.28 LTSB

  • Sandboxing - Only files that have been classified as archive, Office document, executable, PDF and Java files will now be sandboxed to reduce the load on the service. Files that have been classified as other or unknown files will no longer be analyzed.

Changes introduced in version 4.3.26 LTSB

  • NC-1-8xG-FIB-SFP network module - On SN-L-Series and SN-XL-Series model firewalls, the wrong sequence of ports on 8-port fiber modules with the reference NC-1-8xG-FIB-SFP, which is found in SNS version 4.3.25 LTSB, can be fixed by updating the firewall to SNS version 4.3.26 LTSB.

Order of ports in the module in SNS version 4.3.25 LTSB:

1 3 5 7
2 4 6 8

Order of ports in the module in SNS version 4.3.26 LTSB:

1 2 3 4
5 6 7 8

Changes introduced in version 4.3.25 LTSB

  • SNMP agent - The value returned by the OID 1.3.6.1.2.1.1.7 is now 76, corresponding to a device that provides services on OSI layers 3, 4 and 7. Previously, the value returned was 72.

Changes introduced in version 4.3.24 LTSB

  • SN1100 - The maximum number of IPsec tunnels that SN1100 firewalls accepted was too high. The number has been reduced to match announced data.

  • Extended Web Control (EWC) URL classification - The Bitdefender URL database is now the database used.

    To set up a URL/SSL filter policy, you are advised to operate in blacklist mode, i.e., explicitly place the URL categories to be prohibited in URL/SSL filter rules with a block action. These rules must then be placed above the rule that allows all the other categories.

     

    While updating a firewall, which uses a whitelisted URL/SSL filter policy, to SNS version 4.3.24 LTSB or higher (filter rules explicitly allow some categories and are placed above the rule that blocks all other categories), we strongly recommend adding a rule that allows the URL categories misc (miscellaneous), unknown, computersandsoftware (software download websites) and hosting (websites hosting) to avoid affecting user experience. This rule must be placed above the rule that blocks all the other categories.

    For more information on the migration of URL/SSL filter policies when the firewall is updated to SNS version 4.3.24 LTSB or higher, please refer to the Technical Note Migrating a security policy to the new EWC URL database.

    IMPORTANT
    URL/SSL filter policies that have been updated after the firewall was updated to SNS version 4.3.24 LTSB must be thoroughly checked.

Changes introduced in version 4.3.23 LTSB

Find out more

  • Routing - Loopback objects that are used as default gateways are automatically replaced with the blackhole object when the firewall is updated to SNS version 4.3.23 LTSB or higher.
  • Oscar and Gnutella - Protocols Oscar and Gnutella are now considered obsolete. These protocol scans are automatically disabled when the firewall is updated to SNS version 4.3.23 LTSB.

Changes introduced in version 4.3.22 LTSB

Find out more

  • SSH connections to the firewall - On firewalls in factory configuration and in SNS version 4.3 LTSB (from version 4.3.22 LTSB onwards), the encryption algorithms ssh-rsa, hmac-sha2-256 and hmac-sha2-512 are no longer allowed for SSH connections to the firewall.

Changes introduced in version 4.3.21 LTSB

Find out more

  • IPsec DR - During the generation of certificate request payloads, ANSSI's IPsec DR guidelines recommend replacing the algorithm with SHA2 (previously SHA1). SNS 4.3 LTSB versions (from version 4.3.21 LTSB onwards) comply with this recommendation.
    If IPsec DR mode is enabled on an SNS firewall in version 4.3.21 LTSB, VPN tunnels can only be negotiated with peers that comply with this recommendation.
  • VPN Exclusive client (with DR mode) - the VPN Exclusive client 7.4 (or higher) must be used to set up IPsec tunnels in DR mode with firewalls in SNS version 4.3.21 LTSB and higher 4.3 LTSB versions.

Changes introduced in version 4.3.18 LTSB

Find out more

  • BIRD dynamic routing - In configurations that use BGP with authentication, the "source address <ip>;" directive must be used so that BGP sessions continue to be set up after the SNS firewall has been updated.

Changes introduced in version 4.3.17 LTSB

Find out more

  • IPsec VPN on SN 160(W), SN210(W) and SN310 model firewalls - The ESN (Extended Sequence Number) option is no longer automatically enabled when the selected encryption algorithm is compatible with hardware acceleration. Automatically enabling it would negatively affect performance.

Changes introduced in version 4.3.16 LTSB

Find out more

  • SSL/TLS-based protocols - For security reasons, encryption suites that base their key exchanges on Diffie-Hellman methods (DHE-based suites) have been removed. Only ECDHE-based suites are now available on SNS firewalls.
    This change may have an impact on connections initiated to or from the firewall for various SSL-secured protocols (HTTPS, SSH, LDAPS, SMTPS, etc.) as well as SSL connections established through the firewall's proxy.
    Due to this change, SNS firewalls may become incompatible with older client applications and external services/machines that use such protocols.

    The ECDHE-based encryption suites available on SNS firewalls are:
    • TLS_AES_128_GCM_SHA256,
    • TLS_CHACHA20_POLY1305_SHA256,
    • TLS_AES_256_GCM_SHA384,
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
    • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
    • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
    • TLS_EMPTY_RENEGOTIATION_INFO_SCSV.

Changes introduced in version 4.3.15

Find out more

  • Quality of Service (QoS) - The Treatment when full field, in which the packet congestion processing algorithm in queues (TailDrop or BLUE) could be selected, has been removed from QoS settings. The algorithm used by default is now TailDrop and can only be changed via the CLI/Serverd command CONFIG OBJECT QOS DROP.
  • TLS 1.3 protocol - the mechanism that analyzes TLS 1.3 certificates on SSL servers is now automatically disabled when a firewall is migrated from a version lower than SNS 4.3.x to a version higher than or equal to SNS 4.3.15. It is also disabled by default in the incoming SSL analysis profile SSL_00 for firewalls in factory configuration in version 4.3.15 or higher.

Changes introduced in version 4.3.11

Find out more

  • Hardening of the operating system - Text editors Vim and JOE have been removed from the system and replaced with vi.
  • IPsec/IPv6 - The keepalive function can no longer be enabled on IPsec tunnels in IPv6.
  • IPsec DR mode - When DR mode is enabled for the first time, Diffie-Hellman group DH28 is now suggested as the default group for IKE DR and IPsec DR profiles.

Changes introduced in version 4.3.10

Find out more

  • Quality of Service (QoS) - Queues are no longer defined by percentage of bandwidth. After certain SNS firewalls, on which the QoS configuration used queues defined by percentage of bandwidth, are updated to version 4.3.10 or higher, this percentage will automatically be converted to equivalent absolute bandwidth values.

Changes introduced in version 4.3.9

Find out more

  • IPsec IKEv2 VPN - Whenever an IPsec IKEv2 tunnel set up with a mobile peer in config mode is abruptly shut down by the remote client, the IP address that is assigned to it remains locked and unavailable. The unique parameter (for UniqueIDs) has been added to the CLI/Serverd commands CONFIG IPSEC PEER NEW and CONFIG IPSEC PEER UPDATE so that this behavior can be modified.

    For example, to allow users to recover their previous IP addresses, use the parameter unique=no, then reload the configuration of the VPN policy by using the CLI/Serverd commands CONFIG IPSEC ACTIVATE and CONFIG IPSEC RELOAD (this will shut down tunnels in progress).

Changes introduced in version 4.3.7

Find out more

  • Stealth mode - SNS firewalls in factory configuration are now in stealth mode by default.

Changes introduced in version 4.3.3

Find out more

  • QoS - QoS configurations set in versions earlier than SNS 4.3 are no longer valid, and QoS must be configured again following a firewall update.
  • High availability and link aggregation - On configurations equipped with link aggregation, when high availability is initialized, the Enable link aggregation when the firewall is passive option is enabled by default.
  • TPM-equipped firewalls (SNi20, SN1100 and SN3100) - After an update to SNS version 4.3, secrets stored in the TPM must be sealed with the new technical characteristics of the system, by using the command: tpmctl -svp <TPMpassword> .
    For more information on this topic, refer to the Stormshield knowledge base. .
  • TLS 1.3 protocol - Some TLS 1.3 traffic that previously could not be blocked, can now be blocked due to a new server certificate analysis.
  • TLS 1.3 protocol - When the firewall analyzes TLS 1.3 certificates from SSL servers, permissions may need to be explicitly granted in peripheral security devices for the firewall's IP address(es) to access the SSL servers contacted.
  • TLS 1.3 protocol - The SSL proxy now supports the TLS 1.3 protocol.
  • IPsec profiles/Diffie-Hellman groups - When an IKE/IPsec profile is created, the Diffie-Hellman group suggested by default is now DH14 (more secure) instead of DH1.
  • Protection from brute force attacks - Remote SSH access to the firewall is now protected from brute force attacks.
  • RADIUS authentication - The maximum number of tries and the idle timeout allowed to set up a connection to a RADIUS server (main server and backup server) can now be configured.
  • RADIUS authentication - RADIUS servers can now be reached in IPv6.
  • SSL VPN - The minimum mask size for the network object assigned to TCP and UDP clients in the SSL VPN configuration is now /28. If the mask of this network object was /29, it must be changed before migrating the firewall to version 4.3.3 or higher.
  • Certificate enrollment - When they submit a certificate enrollment request, users must now personally define the encryption key used to encrypt their private key.
  • Hardening of the operating system - A specific local port for connection to agents/servers (main and backup) can no longer be specified for the RADIUS and SSO Agent authentication methods. These options could only be configured by using the AgentBindPort and BackupBindPort tokens found in the configuration files for these authentication methods.
  • Hardening of the operating system - SNS firewalls now generate a system event whenever the mechanism that verifies the integrity of executable files refuses to run a binary.

Changes introduced in version 4.2.7

Find out more

  • SSL certificate authentication with TLS v1.3 - To support post-handshake authentication on the firewall, the web browser used must allow post-handshake authentication so that the SSL certificate authentication method can function with TLS v1.3.

Changes introduced in version 4.2.5

Find out more

  • SPNEGO authentication - The spnego.bat script, available in the MyStormshield personal area, now supports AES256-SHA1, replacing the previous cryptographic algorithm used, RC4-HMAC-NT.

Changes introduced in version 4.2.4

Find out more

  • Hardening of the operating system - Only shell scripts are allowed, but they must be explicitly called up by the interpreter (e.g., sh script.sh instead of ./script.sh).
  • Hardening of the operating system - For scripts launched through the event scheduler (eventd), the interpreter must be added for each task described in the event scheduler configuration file.
  • Hardening of the operating system - Scripts must be located only in the root partition (/) so that they can be run.
  • Stealth mode - SNS firewalls in factory configuration are no longer in stealth mode by default.
  • IPsec DR mode - New warnings now appear in the Messages widget of the dashboard when IPsec DR mode is enabled.
  • IPsec DR mode - After fixing an anomaly in the implementation of the ECDSA algorithm based on Brainpool 256 elliptic curves, IPsec tunnels could no longer be set up in DR mode, based on ECDSA and Brainpool 256 elliptic curves, between firewalls in SNS version 4.2.1 or SNS 4.2.2 and firewalls in SNS version 4.2.4 (or higher).
  • Active Update - For clients who use internal mirror sites, you need to update the Active Update packets hosted on their own servers so that packets signed by the new certification authority are used.
  • Stormshield Management Center agent - On SNS firewalls managed via SMC in version 3.0, if the link with the SMC server cannot be set up within 30 seconds after a configuration is restored, the previous configuration will be restored.
  • Logs - The possibility of storing all types of logs on a disk (including connection logs) has been enabled again by default on firewalls in factory configuration

Changes introduced in version 4.2.2

Find out more

  • IPsec VPN - The firewall disables the ESN when the peer is in IKEv1.

Changes introduced in version 4.2.1

Find out more

  • IPsec VPN - ESN support for ESP anti-replay is automatically enabled.
  • IPsec VPN - DR mode in SNS version 4.2 is not compatible with DR mode in earlier SNS versions, and the firewall does not allow updates of firewalls with DR mode enabled.
    Refer to the IPsec VPN technical note - Diffusion Restreinte mode on how to configure DR mode in SNS 4.2 versions and higher.
  • The configurations listed below are no longer allowed in version 4.2:
    • IKEv1 rules based on pre-shared key authentication in aggressive mode (mobile and site-to-site tunnels),
    • IKEv1 rules based on hybrid mode authentication (mobile tunnels),
    • IKEv1 backup peers.
  • IPsec VPN - version 4.2 no longer supports the following algorithms:

    • Blowfish,

    • DES,

    • CAST128,

    • MD5,

    • HMAC_MD5,

    • NON_AUTH,

    • NULL_ENC.

    If the IPsec policy of a firewall that must be updated to version 4.2 uses any of these algorithms, they must be replaced in the firewall's IPsec configuration before performing the update.

  • NAT-T - In configurations that implement NAT-T (NAT-Traversal - transporting the IPsec protocol through a network that performs dynamic address translation), the translated IP address must be set efined as the ID of a peer that uses pre-shared key authentication and for which a local ID in the form of an IP address had been forced. 
  • Logs - A field specifying the type of VPN rule (mobile tunnel or site-to-site tunnel) was added to IPsec VPN logs.
  • SNMP - An SNMP trap is now raised whenever an IPsec VPN peer cannot be reached.
  • SNMP - A new MIB (STORMSHIELD-OVPNTABLE-MIB) is available.
  • SNMP - STORMSHIELD-VPNSA-MIB offers additional IPsec statistics.
  • Authentication - Captive portal - The configuration of the captive portal no longer accepts the selection of certificates other than server certificates that contain the ExtendedKeyUsage ServerAuth.
  • Authentication - SSO Agent - The SSO agent v3.0 or higher must be used with SNS firewalls in version 4.2..
  • SSL VPN - The SSL VPN client must be in v2.9.1 or higher, and we recommend using the latest version of the SSL VPN client with SNS firewalls in version 4.2.
  • Logs - Log files created when verbose mode is enabled on firewall services are now placed in a dedicated folder /log/verbose and no longer directly in the /log folder.
  • SSL VPN - The configuration file meant for the Stormshield SSL VPN client includes the parameter auth-nocache to force the client not to cache the user's password (except for SSL VPN clients configured in Manual mode).
  • TLS v1.3 protocol - TLS v1.3 is used for services on the firewall (captive portal, LDAPS, Syslog TLS, Autoupdate, etc.).
  • The cryptographic suites that the firewall uses to initiate its own TLS connections (LDAPS, SYSLOG TLS, SMTPS, etc.) have been updated. The following are the suites that can now be used:
    • ECDHE-ECDSA-AES128-GCM-SHA256,
    • ECDHE-RSA-AES128-GCM-SHA256,
    • DHE-RSA-AES128-GCM-SHA256,
    • ECDHE-ECDSA-CHACHA20-POLY1305,
    • ECDHE-RSA-CHACHA20-POLY1305,
    • ECDHE-ECDSA-AES256-GCM-SHA384,
    • ECDHE-RSA-AES256-GCM-SHA384,
    • DHE-RSA-AES256-GCM-SHA384,
    • TLS_AES_128_GCM_SHA256,
    • TLS_CHACHA20_POLY1305_SHA256,
    • TLS_AES_256_GCM_SHA384.
    This update may affect the firewall's compatibility with servers that use less robust suites. You are therefore advised to check the compatibility of TLS services that interact with the firewall. In the specific case of the LDAPS service in Microsoft Azure, the firewall must be forced to initiate connections that use less robust cryptographic suites (ECDHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA256, ECDHE-RSA-AES256-SHA384 or DHE-RSA-AES256-SHA256) by executing the CLI/Serverd command CONFIG CRYPTO SSLParanoiac=0. The firewall must be restarted for changes to be applied.

Changes introduced in version 4.1.6

Find out more

  • After signature certificates are updated, the USB Recovery procedure must be used to install a version lower than 4.1.6 on a firewall in version 4.1.6 or higher.

Changes introduced in version 4.1.4

Find out more

  • SSL VPN - A new version of the component that SSL VPN uses in portal mode is offered to users of this service.

Changes introduced in version 4.1.3

Find out more

  • IPsec VPN (IKEv1 + IKEv2) - The warning that appeared when a combined IKEv1/ IKEv2 IPsec policy was used has been deleted.
  • SSL VPN - The SSL VPN client now applies the interval before key renegotiation set by default on the SSL VPN server to 14400 seconds (4 hours).
  • Default gateway - Default gateways located in a public IP network outside the firewall’s public address range can again be defined on the firewall. This behavior already existed in version 3.11.

Changes introduced in version 4.1.1

Find out more

  • LDAP directories - Secure connections to internal LDAP directories are now based on standard protocol TLS 1.2.
  • HTTP cache function - The HTTP cache function can no longer be used in filter rules.
    The proxy cache must be disabled before you update your configuration. Otherwise, the proxy will no longer function.
  • Directory configuration - The default port used to access the backup LDAP server is now the same as the port that the main LDAP server uses.
  • SNMP agent - The use of the value snmpEngineBoots has changed in order to comply with RFC 3414.
  • Configuring protected mode - A new setting (stealth mode) makes it possible to allow the firewall’s response to ICMP requests. This new setting takes priority over sysctl net.inet.ip.icmpreply calls.

Changes introduced in version 4.0.3

Find out more

  • IPsec VPN - As some algorithms are obsolete and will be phased out in a future version of SNS, a warning message now appears to encourage administrators to modify their configurations. This message appears when these algorithms are used in the profiles of IPsec peers.

Changes introduced in version 4.0.2

Find out more

  • Tighter security during firmware updates - Security is now tighter during firmware updates. In addition to update packages being protected by signatures to ensure their integrity, Stormshield now also secures communications with the update servers used. These communications now take place in HTTPS and over port 443.

Changes introduced in version 4.0.1

Find out more

  • The network controller used on SNi40, SN2000, SN3000, SN6000, SN510, SN710, SN910, SN2100, SN3100 and SN6100 firewalls has been upgraded and now allows VLANs with an ID value of 0. This measure is necessary for the industrial protocol PROFINET-RT.
  • The internal name for interfaces has changed on firewall models SN160 and SN210(W). For configurations based on these firewall models and which use Bird dynamic routing, the dynamic routing configuration must be manually changed to indicate the new network interface names.
  • Preferences in the web administration interface - When the firewall is updated to SNS version 4.0.1 or higher, preferences in the web administration interface will be reset (e.g., custom filters).
  • Policy-based routing - If the firewall has been reset to its factory settings (defaultconfig) after a migration from version 2 to version 3 then to version 4, the order in which routing will be evaluated changes and policy-based routing [PBR] will take over priority (policy-based routing > static routing > dynamic routing >…> default route). However, if the firewall has not been reset, the order of evaluation stays the same as in version 1 (static routing > dynamic routing > policy-based routing [PBR] > routing by interface > routing by load balancing > default route).
  • Industrial license - Industrial licenses are now verified and the configuration of industrial protocols is suspended if the license is missing (or when firewall maintenance has expired).
  • New graphical interface - The SNS version 4.0.1 graphical interface has been fully reworked to improve user comfort. It is now easier to switch between Configuration and Monitoring modules.
  • Different MAC addresses on SN310 firewalls - When an SN310 model firewall switches to SNS v4, this will change MAC addresses on the firewall's network interfaces. This difference in addresses may have an impact if the firewall's former MAC addresses were entered on third-party network devices (e.g., DHCP servers or routers).
  • IPsec and HA - IPsec tunnels that were set up will not be synchronized between both members of the cluster during an update, but will be renegotiated to let encrypted traffic pass through.
  • Filtering and MAC addresses - SNS now makes it possible to define and use MAC address-based network objects in filter policies. When a MAC address is specified in an object used in a filter rule, any traffic originating from this object that matches this filter rule will not be evaluated if the MAC address presented during the exchange is different from the object's address.

Notable changes introduced between the last 3.7 LTSB version and the last 3.11 LTSB version

IPsec VPN and CRL

When the CRLRequired parameter is enabled in the configuration of a VPN policy, you now must have all the CRLs in the certification chain.

SSL VPN

Strengthened security

The level of security implemented during the negotiation and use of SSL VPN tunnels (OpenVPN) has been raised.

If you use the Stormshield VPN SSL client with automatic mode disabled, or another OpenVPN client, the configuration of SSL VPN clients must be changed accordingly. To do so, download the SSL VPN configuration from the captive portal of the SNS firewall that hosts the SSL VPN service and import it on the clients. With the Stormshield VPN SSL client in automatic mode, the client will automatically retrieve its configuration.

The new requirements to follow are:

  • Stronger authentication and encryption algorithms:
    • SHA256,
    • ECDHE-RSA-AES128-SHA256,
    • AES-256-CBC (except on SN160(W), SN210(W) and SN310 firewalls, which continue to use AES-128-CBC).
  • LZ4-based data compression (can be enabled or disabled),
  • Strict verification of certificates presented by the server (certificate name and "server" certificates).

If you are not using the Stormshield VPN SSL client, you must work with a recent version of OpenVPN (2.4.x) or OpenVPN Connect (smartphones and tablets) clients.

SSL VPN and certificates

In SSL VPN configurations that use certificates without the KeyUsage field, some external services may no longer be able to communicate with the firewall.

To authenticate peers (client or server) in TLS, Stormshield firewalls now only accept certificates that have the Key Usage field, i.e., certificates that comply with X509 v3.