Changements de comportement
Cette section liste les changements de comportements automatiques liés à la mise à jour de votre firewall SNS en version 4.3.32 LTSB depuis la dernière version 3.7 LTSB disponible.
Changements introduits en version 4.3.31 LTSB
SMC / Suites de chiffrement utilisables avec un firewall SNS - Les suites de chiffrement utilisables lors de la communication entre un firewall SNS et son serveur d'administration SMC sont désormais uniquement les suivantes :
- 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.
Changements introduits en version 4.3.28 LTSB
- Analyse Sandboxing - Seuls les fichiers classifiés dans l'une des catégories Archive, Document bureautique, Exécutable, PDF et Java sont désormais soumis à l'analyse Sandboxing afin de limiter la charge du service. Les fichiers classifiés dans Autre ou Inconnu ne sont plus envoyés pour analyse.
Changements introduits en version 4.3.26 LTSB
- Module réseau NC-1-8xG-FIB-SFP - Sur les firewalls modèles SN-L-Series et SN-XL-Series, un défaut d'ordonnancement des ports du module 8 ports fibre référence NC-1-8xG-FIB-SFP présent en version SNS 4.3.25 LTSB est corrigé lors de la mise à jour du firewall en version SNS 4.3.26 LTSB.
Ordre des ports du module en version SNS 4.3.25 LTSB :
1 | 3 | 5 | 7 |
2 | 4 | 6 | 8 |
Ordre des ports du module en version SNS 4.3.26 LTSB :
1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 |
Changements introduits en version 4.3.25 LTSB
- Agent SNMP - La valeur retournée par l'OID 1.3.6.1.2.1.1.7 est désormais 76, ce qui correspond à un équipement offrant des services sur les couches OSI 3, 4 et 7. Auparavant, la valeur retournée était 72.
Changements introduits en version 4.3.24 LTSB
-
SN1100 - Le nombre maximal de tunnels IPsec acceptés par un firewall SN1100 était trop élevé. Il a été diminué pour correspondre aux données annoncées.
- Classification d'URL Extended Web Control (EWC) - La base d'URL utilisée est désormais celle du fournisseur Bitdefender.
Pour mettre en place une politique de filtrage d'URL / filtrage SSL, il est recommandé de travailler en mode "liste noire", c'est-à-dire de positionner explicitement les catégories d'URL à interdire dans des règles de filtrage d'URL / filtrage SSL avec l'action bloquer. Ces règles sont à placer au-dessus de la règle autorisant toutes les autres catégories.
Dans le cadre de la mise à jour en version SNS 4.3.24 LTSB ou supérieure d'un firewall utilisant une politique de filtrage d'URL / filtrage SSL en mode "liste blanche" (règles de filtrage autorisant explicitement certaines catégories et placées au-dessus de la règle bloquant toutes les autres catégories), il est fortement recommandé d'ajouter une règle autorisant les catégories d'URL misc (Divers), unknown (Inconnu), computersandsoftware (Sites de téléchargement de logiciels) et hosting (Hébergement de sites Web) pour éviter un risque de dégradation de l’expérience utilisateur. Cette règle est à placer au-dessus de la règle bloquant toutes les autres catégories.
Pour plus d'informations sur la migration d'une politique de filtrage d'URL / filtrage SSL lors de la mise à jour du firewall en version SNS 4.3.24 LTSB ou supérieure, veuillez consulter la Note Technique Migrer une politique de sécurité vers la nouvelle base d'URL EWC.IMPORTANT
Il est impératif de contrôler minutieusement toute politique de filtrage d'URL / filtrage SSL mise à jour suite au passage du firewall en version SNS 4.3.24 LTSB.
Changements introduits en version 4.3.23 LTSB
- Routage - Les objets de type loopback utilisés en passerelle par défaut sont automatiquement remplacés par l'objet blackhole lors de la mise à jour du firewall en version SNS 4.3.23 LTSB ou supérieure.
- Protocoles Oscar et Gnutella - Les protocoles Oscar et Gnutella sont désormais considérés comme obsolètes. L'analyse de ces protocoles est automatiquement désactivée lors de la mise à jour du firewall en version SNS 4.3.23 LTSB.
Changements introduits en version 4.3.22 LTSB
- Connexions SSH à destination du firewall - Sur un firewall en configuration d'usine et en version SNS 4.3 LTSB (à partir de la version 4.3.22 LTSB), les algorithmes de chiffrement ssh-rsa, hmac-sha2-256 et hmac-sha2-512 ne sont plus autorisés pour les connexions SSH à destination du firewall.
Changements introduits en version 4.3.21 LTSB
- IPsec DR - Le référentiel IPsec DR de l'ANSSI demande de remplacer l'algorithme utilisé dans la génération des Certificate Request Payload par le SHA2 (anciennement SHA1). Les versions SNS 4.3 LTSB (à partir de la version 4.3.21 LTSB) respectent cette recommandation.
Si le mode IPsec DR est activé sur un firewall SNS en version 4.3.21 LTSB, la négociation de tunnels VPN est possible uniquement avec des correspondants respectant cette recommandation. - Client VPN Exclusive (avec mode DR) - Il est nécessaire d'utiliser le client VPN Exclusive 7.4 (ou supérieur) pour établir des tunnels IPsec en mode DR avec des firewalls en version SNS 4.3.21 LTSB et versions 4.3 LTSB supérieures.
Changements introduits en version 4.3.18 LTSB
- Routage dynamique BIRD - Dans les configurations utilisant le protocole BGP avec de l'authentification, il est nécessaire d'utiliser la directive "source address <ip>;" pour que les sessions BGP continuent de s'établir après la mise à jour du firewall SNS.
Changements introduits en version 4.3.17 LTSB
- VPN IPsec sur les firewalls modèles SN 160(W), SN210(W) et SN310 - L'option ESN (Extended Sequence Number) n'est plus activée automatiquement lorsque l'algorithme de chiffrement sélectionné est compatible avec l'accélération matérielle. Cette activation automatique entraînait en effet une baisse de performances.
Changements introduits en version 4.3.16 LTSB
- Protocoles basés sur SSL / TLS - Pour des raisons de sécurité, les suites de chiffrement utilisant un échange de clés basées sur les méthodes Diffie-Hellman (suites basées sur DHE) ont été supprimées. Seules les suites basées sur ECDHE sont disponibles sur les firewalls SNS.
Cette modification peut impacter les connexions émises depuis ou vers le firewall pour les différents protocoles sécurisés par SSL (HTTPS, SSH, LDAPS, SMTPS...) ainsi que les connexions SSL réalisées au travers du proxy du firewall.
Elle peut potentiellement rendre incompatibles avec les firewalls SNS les anciens logiciels clients et services / machines externes utilisant ces protocoles.
Les suites de chiffrement basées sur ECDHE et disponibles sur les firewalls SNS sont les suivantes : - 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.
Changements introduits en version 4.3.15
- Qualité de service (QoS) - Le champ Traitement en cas de saturation, permettant de sélectionner l'algorithme de traitement des congestions de paquets (TailDrop ou BLUE) dans les files d'attente, a été supprimé du paramétrage de la QoS. L'algorithme utilisé par défaut est désormais TailDrop et est exclusivement modifiable à l'aide de la commande CLI / Serverd CONFIG OBJECT QOS DROP.
- Protocole TLS 1.3 - Le mécanisme d'analyse des certificats TLS 1.3 des serveurs SSL est désormais automatiquement désactivé lors de la migration d'un firewall depuis une version inférieure à SNS 4.3.x vers une version supérieure ou égale à SNS 4.3.15. Il est également désactivé par défaut dans le profil entrant d'analyse SSL SSL_00 pour les firewalls en configuration d'usine en version 4.3.15 ou supérieure.
Changements introduits en version 4.3.11
- Durcissement du système d'exploitation - Les éditeurs de texte vim et joe ont été supprimés du système au profit de l'éditeur vi.
- IPsec / IPv6 - Il n’est plus possible d'activer le mécanisme de keepalive pour les tunnels IPsec en IPv6.
- IPsec mode DR - Lors de la première activation du mode DR, le groupe Diffie-Hellman DH28 est désormais proposé comme groupe par défaut pour les profils IKE DR et IPsec DR.
Changements introduits en version 4.3.10
- Qualité de service (QoS) - La définition de files d'attente en pourcentage de bande passante est obsolète. Après la mise à jour en version 4.3.10 ou supérieure d'un firewall SNS dont la configuration de QoS utilisait une file d'attente définie par un pourcentage de bande passante, ce pourcentage est automatiquement transformé en valeur absolue de bande passante équivalente.
Changements introduits en version 4.3.9
-
VPN IPsec IKEv2 - Lorsqu'un tunnel IPsec IKEv2 établi avec un correspondant nomade en mode CONFIG est interrompu brutalement par le client distant, l'adresse IP qui lui a été attribuée reste verrouillée et indisponible. Le paramètre unique (pour UniqueIDs) a été ajouté aux commandes CLI / Serverd CONFIG IPSEC PEER NEW et CONFIG IPSEC PEER UPDATE afin de pouvoir modifier ce comportement.
Par exemple, pour permettre à un utilisateur de retrouver sa précédente adresse IP, utilisez le paramètre unique=no, puis rechargez la configuration de la politique VPN avec les commandes CLI / Serverd CONFIG IPSEC ACTIVATE et CONFIG IPSEC RELOAD (interrompt les tunnels en cours).
Changements introduits en version 4.3.7
- Mode furtif - En configuration d'usine un firewall SNS est désormais en mode furtif par défaut.
Changements introduits en version 4.3.3
- QoS - Les configurations de QoS définies dans une version antérieure à SNS 4.3 ne sont plus valides et il est impératif de reconfigurer la QoS après mise à jour du firewall.
- Haute disponibilité et agrégats de liens - Sur une configuration disposant d'agrégats de liens, l'initialisation de la haute disponibilité active par défaut l'option Activer l'agrégation de liens lorsque le firewall est passif.
- Firewalls équipés d'un TPM (SNi20, SN1100 et SN3100) - Après une mise à jour en version SNS 4.3, les secrets stockés dans le TPM nécessitent d'être scellés avec les nouvelles caractéristiques techniques du système à l'aide de la commande : tpmctl -svp <TPMpassword> .
Pour plus d'informations sur ce sujet, consultez la Base de connaissances Stormshield. - Protocole TLS 1.3 - Certains flux TLS 1.3 peuvent à présent être bloqués alors qu'ils ne l'étaient pas auparavant en raison d'une nouvelle analyse de certificats serveur.
- Protocole TLS 1.3 - L'analyse par le firewall des certificats TLS 1.3 des serveurs SSL peut nécessiter d'ajouter explicitement dans les équipements périphériques de sécurité l'autorisation d'accès de l'adresse IP (ou des adresses IP) du firewall aux serveurs SSL contactés.
- Protocole TLS 1.3 - Le proxy SSL supporte désormais le protocole TLS 1.3.
- Profils IPsec / Groupes Diffie-Hellman - Lors de la création d'un profil IKE / IPsec, le groupe Diffie-Hellman proposé par défaut est désormais le DH14 (plus sécurisé) et non plus le DH1.
- Protection contre les attaques par force brute - L'accès distant par SSH au firewall est désormais protégé contre les attaques par force brute.
- Authentification RADIUS - Le nombre maximum d'essais et le délai d'inactivité autorisé pour réaliser une connexion à un serveur RADIUS (serveur principal et serveur de secours) peuvent désormais être configurés.
- Authentification RADIUS - Il est désormais possible de joindre des serveurs RADIUS en IPv6.
- VPN SSL- La taille minimale du masque de l'objet réseau assigné aux clients UDP et TCP dans la configuration VPN SSL est à présent de /28. Si le masque de cet objet réseau était de /29, il doit être modifié avant la migration du firewall en version 4.3.3 ou supérieure.
- Enrôlement des certificats - Lors de la réalisation d'une demande d'enrôlement de certificat, les utilisateurs doivent à présent définir eux-mêmes la clé de chiffrement utilisée pour chiffrer leur clé privée.
- Durcissement du système d'exploitation - Il n'est plus possible de préciser un port spécifique local de connexion aux agents / serveurs (principaux et de secours) pour les méthodes d'authentification RADIUS et Agent SSO. Ces options étaient exclusivement configurables par le biais des jetons AgentBindPort et BackupBindPort présents dans les fichiers de configuration de ces méthodes d'authentification.
- Durcissement du système d'exploitation - Le firewall SNS génère désormais un événement système lorsque le mécanisme de vérification d'intégrité des fichiers exécutables refuse de lancer un binaire.
Changements introduits en version 4.2.7
- Authentification par certificat (SSL) avec TLS v1.3 - Le support du Post-Handshake Authentication sur le firewall nécessite que le navigateur Web utilisé autorise le Post-Handshake Authentication pour que la méthode d'authentification par certificat (SSL) avec TLS v1.3 soit fonctionnelle.
Changements introduits en version 4.2.5
- Authentification SPNEGO - Le script spnego.bat, disponible dans l'espace personnel MyStormshield, prend désormais en charge l'algorithme cryptographique AES256-SHA1, remplaçant l'ancien algorithme cryptographique utilisé RC4-HMAC-NT.
Changements introduits en version 4.2.4
- Durcissement du système d'exploitation - Seuls les scripts shell sont autorisés, mais ils doivent explicitement être appelés par l'interpréteur (par exemple : sh script.sh et non ./script.sh).
- Durcissement du système d'exploitation - Pour les scripts lancés par le biais du planificateur d'événements (eventd), l'interpréteur doit être ajouté pour chaque tâche décrite dans le fichier de configuration du planificateur d'événements.
- Durcissement du système d'exploitation - Les scripts doivent être exclusivement situés dans la partition root (/) pour pouvoir être exécutés.
- Mode furtif - En configuration d'usine un firewall SNS n'est désormais plus en mode furtif par défaut.
- Mode IPsec DR - De nouveaux avertissements sont affichés dans le widget Messages du tableau de bord lorsque le mode IPsec DR est activé.
- Mode IPsec DR - La correction d'une anomalie dans l'implémentation de l'algorithme ECDSA basé sur les courbes elliptiques Brainpool 256 rend impossible l'établissement de tunnels IPsec en mode DR, basés sur ECDSA et courbes elliptiques Brainpool 256, entre un firewall en version SNS 4.2.1 ou SNS 4.2.2 et un firewall en version SNS 4.2.4 (ou supérieure).
- Active Update - Pour les clients utilisant des sites miroirs internes, il convient de mettre à jour les paquets Active Update hébergés sur leurs propres serveurs afin d'utiliser ceux signés par la nouvelle autorité de certification.
- Agent Stormshield Management Center - Sur un firewall SNS administré via SMC en version 3.0, si la liaison avec le serveur SMC n'a pas pu s'établir dans un délai de 30 secondes après une restauration de configuration, alors la configuration précédente est restaurée.
- Logs - Le stockage sur disque de tous les types de traces (dont les connexions) a été réactivé par défaut sur les firewalls en configuration d'usine.
Changements introduits en version 4.2.2
- VPN IPsec - Le firewall désactive l'ESN lorsque le correspondant est en IKEv1.
Changements introduits en version 4.2.1
- VPN IPsec - Le support de l'ESN pour l'anti-rejeu ESP est activé automatiquement.
- VPN IPsec - Le Mode DR de la version SNS 4.2 n'est pas compatible avec le Mode DR des versions SNS précédentes et la mise à jour d'un firewall avec le Mode DR activé est refusée par le firewall.
Veuillez consulter la note technique VPN IPsec - Mode Diffusion Restreinte pour la configuration du mode DR des versions SNS 4.2 et supérieures. - Les configurations listées ci-dessous ne sont plus autorisées en version 4.2 :
- Règles IKEv1 basées sur l'authentification par clé pré-partagée en mode agressif (tunnels nomades et tunnels site à site),
- Règles IKEv1 basées sur l'authentification en mode hybride (tunnels nomades),
- Correspondants de secours IKEv1.
- VPN IPsec - La version 4.2 n'assure plus le support des algorithmes suivants :
Blowfish,
DES,
CAST128,
MD5,
HMAC_MD5,
NON_AUTH,
NULL_ENC.
Si la politique IPSec d'un firewall devant être mis à jour en version 4.2 utilise l'un ou l'autre de ces algorithmes, il est impératif de remplacer ces algorithmes dans la configuration IPSec du firewall avant de réaliser cette mise à jour.
- NAT-T - Dans une configuration mettant en œuvre du NAT-T (NAT-Traversal - Passage du protocole IPsec au travers d'un réseau réalisant de la translation d'adresses dynamique), il est impératif de définir l'adresse IP translatée comme identifiant d'un correspondant utilisant l'authentification par clé pré-partagée et pour lequel un ID local sous la forme d'une adresse IP aurait été forcé.
- Logs - Un champ précisant le type de règle VPN (tunnel mobile ou tunnel site à site) a été ajouté aux logs VPN IPsec.
- SNMP - Un événement (trap) SNMP est désormais émis lorsqu'un correspondant VPN IPsec est injoignable.
- SNMP - Une nouvelle MIB (STORMSHIELD-OVPNTABLE-MIB) est disponible.
- SNMP - La MIB STORMSHIELD-VPNSA-MIB propose des statistiques IPsec complémentaires.
- Authentification - Portail captif - La configuration du portail captif n'accepte plus la sélection de certificats autres que des certificats serveur comportant l'ExtendedKeyUsage ServerAuth.
- Authentification - Agent SSO - Il est nécessaire d'utiliser l'Agent SSO v3.0 (ou supérieur) avec les firewalls SNS en version 4.2.
- VPN SSL - Il est nécessaire d'utiliser le client VPN SSL v2.9.1 minimum et il est recommandé d'utiliser la dernière version du client VPN SSL avec les firewalls SNS en version 4.2.
- Logs - Les fichiers de logs créés lors de l'activation du mode verbeux des services du firewall sont désormais placés dans un répertoire dédié /log/verbose et non plus directement dans le répertoire /log.
- VPN SSL - Le fichier de configuration destiné au client VPN SSL Stormshield inclut le paramètre auth-nocache pour imposer au client de ne pas conserver le mot de passe utilisateur en mémoire (à l'exception des clients VPN SSL configurés en Mode manuel).
- Protocole TLS v1.3 - Le protocole TLS v1.3 est utilisé pour les services du firewall (portail captif, LDAPS, Syslog TLS, Autoupdate ...).
- Les suites cryptographiques utilisées par le firewall pour initier ses propres connexions TLS (LDAPS, SYSLOG TLS, SMTPS...) ont été mises à jour. Les suites utilisables sont désormais :
- 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.
Changements introduits en version 4.1.6
- Suite à la mise à jour des certificats de signature, il est obligatoire d'utiliser la procédure USB Recovery pour installer une version inférieure à la version 4.1.6 sur un firewall en version 4.1.6 ou supérieure.
Changements introduits en version 4.1.4
- VPN SSL - Une nouvelle version du composant utilisé par le VPN SSL en mode portail est proposée pour les utilisateurs de ce service.
Changements introduits en version 4.1.3
- VPN IPsec (IKEv1 + IKEv2) - L'avertissement qui était affiché lors de l'utilisation d'une politique IPsec mixte IKEv1 / IKEv2 a été supprimé.
- VPN SSL - Le client VPN SSL applique désormais le délai avant renégociation des clés défini sur le serveur VPN SSL, par défaut de 14400 secondes (4 heures).
- Passerelle par défaut - Il est de nouveau possible de définir sur le firewall une passerelle par défaut située dans un réseau IP publique autre que le plan d'adressage public du firewall. Ce comportement est déjà présent en version 3.11.
Changements introduits en version 4.1.1
- Annuaires LDAP - Les connexions sécurisées aux annuaires LDAP internes sont désormais basées sur le protocole standard TLS 1.2.
- Fonctionnalité de Cache HTTP - La fonction Cache HTTP au sein d'une règle de filtrage n'est plus disponible.
Il est nécessaire de désactiver le proxy cache avant de mettre à jour votre configuration. Dans le cas contraire, le proxy ne sera plus fonctionnel. - Configuration des annuaires - Le port utilisé par défaut pour accéder au serveur LDAP de secours est désormais identique au port utilisé par le serveur LDAP principal.
- Agent SNMP - L'utilisation de la valeur snmpEngineBoots a été modifiée afin de se conformer à la RFC 3414.
- Paramétrage du mode protégé - Un nouveau paramétrage (stealth mode) permet d'autoriser la réponse du firewall aux requêtes ICMP. Ce nouveau paramétrage est prioritaire à un appel de type sysctl net.inet.ip.icmpreply.
Changements introduits en version 4.0.3
- VPN IPsec - Certains algorithmes étant obsolètes et amenés à disparaître dans une future version de SNS, un message d'avertissement est maintenant affiché pour encourager les administrateurs à modifier leur configuration. Ce message s'affiche lorsque ces algorithmes sont utilisés dans le profil d'un correspondant IPsec.
Changements introduits en version 4.0.2
- Sécurité renforcée lors de la mise à jour du firmware - Le niveau de sécurité des mises à jour de firmware a été renforcé : en plus de protéger par signature l'intégrité des packages de mise à jour, Stormshield sécurise désormais les communications avec les serveurs de mise à jour utilisés. Ces communications s'établissent désormais via le protocole HTTPS et le port 443.
Changements introduits en version 4.0.1
- Une mise à jour du pilote de contrôleur réseau utilisé sur les firewalls modèles SNi40, SN2000, SN3000, SN6000, SN510, SN710, SN910, SN2100, SN3100 et SN6100 autorise désormais la gestion d'un VLAN ayant un identifiant égal à 0. Ceci est nécessaire pour le fonctionnement du protocole Industriel PROFINET-RT.
- Le nom interne des interfaces a changé pour les firewalls modèles SN160 et SN210(W). Pour les configurations basées sur ces modèles de firewall et utilisant le routage dynamique Bird, iI est nécessaire de modifier manuellement la configuration du routage dynamique pour indiquer les nouveaux noms des interfaces réseau.
- Préférences de l’interface Web d’administration - La mise à jour vers une version SNS 4.0.1 ou supérieure provoque une réinitialisation des préférences de l’interface Web d’administration (exemple : filtres personnalisés).
- Routage par politique de filtrage - Si une remise en configuration d’usine du firewall (defaultconfig) est réalisée suite à une migration de la version 2 vers la version 3 puis vers la version 4, l’ordre d’évaluation du routage est modifié et le routage par politique de filtrage [PBR] devient prioritaire (routage par politique de filtrage > routage statique > routage dynamique >…> routage par défaut). En revanche, en l’absence de remise en configuration d’usine du firewall, l’ordre d’évaluation reste inchangé par rapport à la version 1 (routage statique > routage dynamique > routage par politique de filtrage [PBR] > routage par interface > routage par répartition de charge > routage par défaut).
- Licence industrielle - L'option de licence industrielle est maintenant vérifiée et la configuration des protocoles industriels est gelée si cette licence n'est pas présente (ou lorsque la maintenance du firewall est expirée).
- Nouvelle interface graphique - L'interface graphique de SNS version 4.0.1 a été totalement repensée pour améliorer l'ergonomie du produit (navigation entre Configuration et Monitoring facilitée).
- Changement d'adresses MAC sur les firewalls SN310 - Le passage en SNS v4 d'un firewall modèle SN310 induit un changement d'adresses MAC pour les interfaces réseau du firewall. Ce changement peut avoir un impact si les anciennes adresses MAC du firewall avaient été renseignées sur des équipements réseau tiers (serveur DHCP, routeur...).
- IPsec et HA - Les tunnels IPsec établis ne seront pas synchronisés entre les 2 membres du cluster lors de la mise à jour : ils seront renégociés afin de pouvoir faire transiter du trafic chiffré.
- Filtrage et adresses MAC - SNS permet maintenant de définir et d'utiliser dans les politiques de filtrage des objets réseau basés sur les adresses MAC. Lorsqu'une adresse MAC est précisée dans un objet utilisé au sein d'une règle de filtrage, tout trafic provenant de cet objet et correspondant à cette règle de filtrage ne sera pas évalué si l'adresse MAC présentée durant l'échange diffère de celle de l'objet.
Changements notables introduits entre la dernière version 3.7 LTSB et la dernière version 3.11 LTSB
VPN IPsec et CRL
Lorsque le paramètre CRLRequired est activé dans la configuration d'une politique VPN, il est désormais nécessaire de disposer de toutes les CRL de la chaîne de certification.
VPN SSL (OpenVPN)
Renforcement du niveau de sécurité
Le niveau de sécurité mis en œuvre lors de la négociation et de l'utilisation de tunnels VPN SSL (OpenVPN) a été accru.
Si vous utilisez le client VPN SSL Stormshield avec le mode automatique désactivé ou un autre client OpenVPN, la configuration des clients VPN SSL doit donc être modifiée en conséquence. Pour cela, téléchargez la configuration VPN SSL depuis le portail captif du firewall SNS hébergeant le service VPN SSL et importez la sur les clients. Avec le client VPN SSL Stormshield en mode automatique, le client récupérera automatiquement sa configuration.
Les nouvelles exigences à respecter sont les suivantes :
- L'utilisation d'algorithmes d'authentification et de chiffrement de force supérieure :
- SHA256,
- ECDHE-RSA-AES128-SHA256,
- AES-256-CBC (sauf sur les firewalls modèles SN160(W), SN210(W), SN310 qui conservent l'algorithme AES-128-CBC).
- Une compression des données activable basée sur les algorithmes LZ4,
- La vérification stricte du certificat présenté par le serveur (nom du certificat, et certificat de type "serveur").
Si vous n'utilisez pas le client VPN SSL Stormshield, notez qu'il est impératif de travailler avec une version récente des clients OpenVPN (2.4.x) ou OpenVPN Connect (smartphones et tablettes).
VPN SSL et certificats
Dans les configurations VPN SSL utilisant des certificats qui ne disposent pas du champ KeyUsage, les services externes peuvent ne plus parvenir à communiquer avec le firewall.
Pour authentifier un correspondant (client ou serveur) en TLS, les firewalls Stormshield acceptent désormais uniquement les certificats disposant du champ KeyUsage, c'est-à-dire les certificats conformes à la norme X509 v3.