New features and enhancements in SNS 4.8.1 EA

Zero trust network access (ZTNA) - Verifying the compliance of client workstations

In order to implement zero trust network access (ZTNA), you can now configure policies to check the compliance of client workstations that set up SSL VPN tunnels with the SNS firewall. When it is enabled, client workstations or users that do not comply with the criteria in the policy will not be able to set up SSL VPN tunnels with the SNS firewall.

Only the Stormshield SSL VPN client in version 4.0 and higher is compatible with the client workstation compliance check feature. Every workstation in the corporate network has to therefore use the Stormshield SSL VPN client in version 4.0 and higher when the feature is enabled.

However, there is an option to allow incompatible SSL VPN clients to set up SSL VPN tunnels. This option should be used only on a temporary basis, for example to gradually upgrade a pool of SSL VPN clients to a compatible version.

For more information on implementing zero trust network access (ZTNA) and the client workstation compliance check feature, refer to the technical note Configuring and using the SSL VPN on SNS firewalls.

Multifactor authentication in IKEv2 via EAP

As of SNS version 4.8, multifactor authentication is supported for IKEv2-based mobile tunnels via EAP (Extensible Authentication Protocol).

Multifactor authentication can also be provided in the following ways:

  • EAP-Generic Token Card: the mobile peer must present a login/password pair,
  • Certificate and EAP-Generic Token Card: the mobile peer must present a certificate and login/password pair,
  • For increased security, you can use time-based one-time passwords (TOTP) with the EAP methods above, by using the Stormshield TOTP solution.

Note:

  • EAP methods are not compatible with the Diffusion Restreinte (DR) mode, and IKEv1-based tunnels that need to use Xauth for multifactor authentication,
  • The Stormshield VPN Exclusive client in version 7.4 and higher needs to be used in order to set up IKEv2-based mobile tunnels via EAP.

For more information, refer to the technical note Mobile IKEv2 IPsec VPN - EAP and Certificate Authentication.

Protection against post-quantum attacks

SNS version 4.8 begins with the option of setting post-quantum pre-shared keys (PPK) for peers using the IKEv2 protocol with certificate-based authentication.

The computing power of quantum computers will very likely allow it to decrypt keys that were negotiated using the Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) methods, therefore endangering the security of the IKEv2 protocol.

Malicious users would now be able to carry out "store now, decrypt later" attacks, by intercepting IPsec communications and storing them in order to decrypt them later using a quantum computer.

Clients who wish to protect themselves against such attacks can use SNS version 4.8, which follows the recommendations in RFC 8784, and therefore makes it possible to use PPKs meant to protect data encryption key exchanges. Do note that to be effective, these PPKs must have a sufficiently high entropy (minimum 256 bits according to RFC).

To find out more on the use of PPKs for the IKEv2 protocol, refer to RFC 8784.

For more information on how to configure PPKs, refer to the IPsec VPN sections Peers and Identification in the SNS user guide.

Dynamic multicast routing

The multicast routing configuration panel has been simplified and a monitoring panel has been added.

Dynamic multicast routing is no longer an early-access feature.

More information on dynamic multicast routing.

BIRD dynamic routing

Version 2 added, version 1 obsolete

Version 2 of the BIRD dynamic routing engine is now available. In the Dynamic routing configuration panel, you can:

  • Enable a version of BIRD in a new General tab,
  • Prepare a migration to the new version of the engine in the BIRD v2 tab before activating it. When editing the BIRD v2 configuration, you can display the BIRD v1 configuration in a panel on the right.

Version 1 of the BIRD dynamic routing engine is now considered obsolete, and a message in the Messages widget on the dashboard informs you of this.

For more information, refer to the technical note BIRD v2 dynamic routing.

SNS firewall pools managed by an SMC server

If your SNS firewall pool is managed by an SMC server, it is not possible to manage dynamic routing on your firewalls in 4.8.1 EA versions and higher from SMC in version 3.6 and below. The SNS firewall will then reject the deployment of the configuration by the SMC server, and report an error.

For more information on SMC versions, refer to the section New features and enhancements in SMC 3.6 in the SMC version release notes.

New 4 bypass (NA-EX-CARD-BP-8xG-C) hardware module

As of SNS version 4.8, the hardware module NA-EX-CARD-BP- 8xG-C is supported, making it possible to have 1 to 4 bypass modules on the following firewall models:

  • SN-M-Series-520,

  • SN-M-Series-720,

  • SN-M-Series-920,

  • SN1100 (only in the left extension slot).

More information on how to operate and enable the bypass feature.

Support for new firewall models

As of SNS version 4.8, the following firewall models are supported:

  • SN-L-Series-2200 and SN-L-Series-3200,
  • SN-XL-Series-5200 and SN-XL-Series-6200.

Protection against denial of service attacks (DoS and DDoS)

Protection against DoS and DDoS attacks has been strengthened. These improvements apply to UDP and TCP, and you can set new detection thresholds in inspection profiles.

More information on configuring protections against TCP-UDP denial of service attacks.

Increased security

Hardening of the system

Hardening the system in SNS version 4.8 increases the security of the product.

NTP keys - Selection of algorithms added

You can now select SHA1, SHA256, SHA384, SHA512 and AES-CBC-128 as algorithms in the configuration of NTP keys.

More information on date and time settings.

Analyzing extension mechanisms for DNS (EDNS)

The intrusion prevention system now includes the analysis of extension mechanisms for DNS (EDNS), which are described in RFC 6891.

New restrictions for certificates used in TLS connections

The following certificates can no longer be used during TLS connections on the SNS firewall:

  • Certificates containing the restriction "CA:TRUE" (it has to be "CA:FALSE"),
  • Certificates containing the XKU "OCSP Server".

SNMPv3 agent - Obsolete algorithms

Authentication algorithm MD5 and encryption algorithms DES and SHA1, which the SNMPv3 agent uses, are obsolete and will be removed in a future SNS firmware release. An indication that these algorithms are obsolete now appears in the SNMPv3 agent configuration panel.

Now you can change the algorithms that the SNMPv3 agent uses with the following CLI/Serverd commands:

CONFIG SNMP ACCESS USERV3 username=<username> authtype=SHA256 authpass=<passphrase> privtype=AES privpass=<passphrase>

CONFIG SNMP ACTIVATE

After an update to SNS version 4.8, DES will be selected by default as the encryption algorithm if no algorithm has been selected earlier. Do note that password encryption remains disabled as long as no password has been entered in the field associated with the encryption algorithm.

Internal LDAP directory - Obsolete algorithms

Password hash algorithms MD5, SMD5, SHA, SSHA, SHA256, SHA384 and SHA512, which the Internal LDAP directory uses, are obsolete and will be removed in a future SNS firmware release. An indication that these algorithms are obsolete now appears in the advanced configuration panel of the internal LDAP directory.

SSL VPN portal - Obsolete features

The SSL VPN portal feature is obsolete and will be deleted in a future SNS firmware version. An indication that this feature is obsolete now appears in the SSL VPN portal configuration panel.

Removal of the OSCAR protocol scan

Considered obsolete since SNS version 4.6.9, the OSCAR protocol scan has been removed from the SNS firewall. Do note that this protocol scan was automatically disabled when the firewall was updated to SNS version 4.7.2 EA.

RSA key size

The size of RSA keys generated on the SNS firewall is now 4096 bits by default.

Integration into various environments

Link aggregation - Support for broadcast mode

As of SNS version 4.8, aggregates can be configured in broadcast mode directly in the firewall administration interface, under an aggregate's Advanced configuration tab. This mode, which was introduced in SNS version 4.7.5, could only be configured by modifying a configuration file on the firewall.

More information on configuring an aggregate.

Multiple Diffie-Hellman (DH) groups

Several DH groups can now be specified in the same IKE and IPsec encryption profile to facilitate the migration of peers to a single group.

More information on encryption profiles.

HTTP and SSL proxies - WebSocket support

As of SNS version 4.8, HTTP and SSL proxies support WebSocket. Do note that in the IPS profiles of incoming connections (such as IPS_00), the alarm http:301 blocks WebSocket support by default (Block action).

IPsec DR - OCSP

In an IPsec DR context, and in line with RFC 4806, peers can now validate the certificate of the remote gateway that is presented when the IKEv2 tunnel is being set up, but without exposing the OCSP server.

This configuration is possible only by using the CLI/Serverd command set:

CONFIG IPSEC OCSP

More information on the CONFIG IPSEC OCSP commands.

Asynchronous authentication

The SNS firewall's authentication mechanism can now manage user authentication asynchronously, thereby enabling better integration of third-party multifactor authentication solutions.

SD-WAN

SD-WAN route management has been improved.

OpenVPN - Source address of TCP requests

The source IP address of TCP requests sent by OpenVPN can now be specified. This parameter can only be modified through the following CLI/Serverd commands:

CONFIG OPENVPN UPDATE BindAddr=(<firewall_ip_object>|"")
CONFIG OPENVPN ACTIVATE

When OpenVPN is the only engine on the SNS firewall that listens on the TCP port, performance has been shown to improve.

More information on the CONFIG OPENVPN commands.

Sending data to sekoia.io servers

If you have a subscription allowing you to send data to sekoia.io servers, you can now configure the authentication key provided by Sekoia (Intake Key) in the Syslog profile configuration.

More information on configuring Syslog profiles.

TLS 1.3 traffic - Analysis of server certificates

You can now specify the source IP address of requests sent by the intrusion prevention engine when it attempts to retrieve the server certificate for every TLS 1.3 traffic stream that passes through the firewall so that any potential security flaws relating to this certificate can be analyzed.

You can apply this configuration with the following CLI/serverd command:

CONFIG PROTOCOL SSL PROFILE IPS CONFIG index=<slot> TLSServerCertBindAddr=<host>

More information on the CONFIG PROTOCOL SSL PROFILE IPS CONFIG command.

Changes to performance

TLS 1.3 - Cache added when certificate retrieval fails

When a request fails to get a certificate, the requests that follow now receive an instant response with the help of a cache. This cache is enabled by default and keeps data for 6 hours.

You can customize the cache duration (in seconds) using the CLI/Serverd command:

CONFIG PROTOCOL SSL COMMON IPS CONFIG TLSCertCacheErrorTTL=<60..259200>

More information on the CONFIG PROTOCOL SSL COMMON IPS CONFIG command.

You can disable this cache by setting the value of the TLSServerCertCacheError configuration token to 0 in the ConfigFiles/Protocols/ssl/ file of the policy that is used.

Improved user experience

Initial configuration via USB key - New operations

Certificates and their CRLs can now be imported during the initial configuration of an SNS firewall via USB key, by using the certimport and crlimport operations.

For more information on these operations, refer to the sections certimport operation and crlimport operation in the technical note Initial configuration via USB key.

Stealth mode

When stealth mode is disabled, a link that directs to the IP protocol settings now appears in the warning in the Messages widget on the dashboard.

More information on IP protocol furtive mode.

URL objects module

The URL object configuration panel has been improved. Category groups are now configured in the Certificate names (CN) tab.

More information on configuring URL objects.

Disabling the button to reset the firewall to its factory settings (defaultconfig).

Support reference 84328

The button to reset the firewall to its factory settings can now be disabled, to prevent the firewall's configuration from being accidentally reset.

The button can only be disabled by using the following CLI/SSH command:

setconf /usr/Firewall/ConfigFiles/system DefaultConfig EnableButton 0 && nhup hardwared

Better visibility of certain information

Alarm messages relating to high availability or hardware failures

Alarm messages relating to high availability or hardware failures now show:

  • The SNS firewall's serial number,
  • The system node name, if it has been defined.

MIB STORMSHIELD-PROPERTY-MIB - OID snsSystemNodeName added

The OID snsSystemNodeName has been added to the MIB STORMSHIELD-PROPERTY-MIB, which returns a value corresponding to the system node name.

Configuration restoration alarms

A system alarm appears on the dashboard when a configuration is restored using a CLI/Serverd command or via a USB key, indicating:

  • Whether the restoration is full or partial,

  • The results of the file content hash (SHA2 method),

  • The user that ran the CLI/Serverd command.

sfctl command - Using the name of an object in filters

For easier troubleshooting, you can now use the name of an object in filters when the sfctl command is used with the parameters -H type=modifier.

More information on the sfctl command.

Addition of filters for the commands MONITOR GETSA, GETSPD and GETIKESA

Filters can now be used in the following IPsec VPN monitoring CLI/Serverd commands:

MONITOR GETSA Global=<0|1> List=<full|light>
MONITOR GETIKESA Global=<0|1> List=<full|light>
MONITOR GETSPD Global=<0|1> List=<full|light>

For more information on these commands, refer to the sections MONITOR GETSA, MONITOR GETIKESA and MONITOR GETSPD of the CLI/Serverd commands reference guide.

Firewall hardware activity monitoring mechanism (watchdog)

The management of the firewall hardware activity monitoring mechanism (watchdog) has been enhanced. Real-time monitors are now shown in a tooltip, and the configuration of the monitoring mechanism can now be managed in the administration interface of virtual firewalls.

SNMP agent

The value assigned to the sysname field presented by the SNMP agent now follows this order:

  1. The value specified in the Name field in the Configuration of MIB-II information (Notifications > SNMP agent module),
  2. Otherwise, the value specified in the Firewall name field (System > Configuration > General configuration tab),
  3. Otherwise, the serial number of the firewall.

Telemetry

Status of the telemetry service

The status of the telemetry service is now shown in the dashboard.

New data reported by the telemetry service

The telemetry service in SNS version 4.8 now reports new data:

  • Data regarding the use of the IPsec VPN module:
    • Number of site-to-site or mobile tunnels configured and enabled in the active IPsec policy,
    • Number of tunnels configured in IKEv1 or IKEv2 in the active IPsec policy,
    • Number of times each authentication method was used in tunnels configured in the active IPsec policy,
    • Maximum number of site-to-site or mobile tunnels connected,
  • Data regarding the TLS 1.3 cache:

    • Total number of entries in the TLS 1.3 cache,

    • Total number of times the cache was purged when it was saturated,

    • Number of failed certificate requests.

By sending such data, which is completely anonymous, you will be helping Stormshield to refine the dimensions and restrictions on future hardware platforms and SNS versions.

More information on telemetry services.