New firewall behavior
This section lists the changes made to the automatic behavior of the firewall when your SNS firewall in version 4.5.3 is updated from the latest 3.11.x LTSB version available.
Changes introduced in version 4.3.11
- 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
- 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.7
- Stealth mode - SNS firewalls in factory configuration are now in stealth mode by default.
Changes introduced in version 4.3.3
- QoS - QoS configurations set in versions earlier than SNS 4.3 are no longer valid. Traffic shapers must be configured so that such QoS configurations can be enabled after the update to SNS version 4.3.
- 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.5
- 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
- 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
- IPsec VPN - The firewall disables the ESN when the peer is in IKEv1.
Changes introduced in version 4.2.1
- 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.
- 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:
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.
- 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 - On firewalls configured in strict HTTPS mode (using the CLI/Serverd command CONFIG AUTH HTTPS sslparanoiac=1), the configuration of the captive portal no longer allows the selection of certificates other than server certificates containing 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 v2.9.1 or higher must be used 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:
Changes introduced in version 4.1.6
- 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
- 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
- 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
- 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.
- 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
- 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
- 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
- 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).