Sophos Firewall v22 MR2 : nouveautés, correctifs et mise à niveau

Sophos a publié Sophos Firewall OS 22.0 MR2 Build 546 le 14 juillet 2026. Cette Maintenance Release est plus petite qu’une version majeure, mais va bien au-delà d’un simple ensemble de correctifs : elle apporte le contrôle de la cryptographie post-quantique, une détection plus précise des applications d’IA générative, une nouvelle extension Chromebook, un réglage STAS par défaut moins perturbateur et des chaînes de confiance Let’s Encrypt actualisées. Sophos corrige en parallèle 53 problèmes documentés touchant notamment le pare-feu, la haute disponibilité, IPsec, l’authentification, la journalisation, le WAF et le reporting.

MR2 est donc avant tout une version axée sur l’exploitation et la stabilité. Ses nouvelles fonctions sont intéressantes, mais dans de nombreux environnements de production, la correction des plantages du noyau, des passages en mode Failsafe, des problèmes HA et des erreurs VPN constitue la principale raison d’effectuer la mise à jour.

Détecter et contrôler la cryptographie post-quantique

La nouveauté de sécurité la plus marquante concerne la cryptographie post-quantique (PQC). Ce terme désigne les procédés cryptographiques conçus pour résister aux attaques de futurs ordinateurs quantiques suffisamment puissants. Le risque actuel ne se limite pas à l’éventuelle apparition d’un tel ordinateur. Pour les données particulièrement sensibles, le principe Harvest now, decrypt later joue déjà un rôle : le trafic chiffré est enregistré et stocké afin de pouvoir être déchiffré ultérieurement avec une technologie plus performante.

SFOS 22.0 MR2 reconnaît les méthodes d’échange de clés pures et hybrides basées sur ML-KEM. Ce mécanisme, fondé sur le problème mathématique Module Learning With Errors, a été normalisé en 2024 par le National Institute of Standards and Technology sous la référence FIPS 203. Le NIST définit trois jeux de paramètres, ML-KEM-512, ML-KEM-768 et ML-KEM-1024, offrant des niveaux de sécurité et des performances différents.

ML-KEM ne chiffre pas directement le trafic web qui suit. Il s’agit d’un Key Encapsulation Mechanism, utilisé pour établir un secret partagé entre le client et le serveur sur un canal public. Ce secret sert ensuite à dériver les clés de session symétriques qui chiffrent et authentifient efficacement les données proprement dites.

Avec un échange de clés PQC pur, la sécurité de la négociation dépend uniquement du procédé post-quantique. Les implémentations TLS actuelles emploient plus fréquemment des méthodes hybrides, qui combinent ML-KEM avec un procédé classique tel que X25519. Une négociation hybride correctement conçue vise à protéger la session tant qu’au moins l’un des deux composants reste sûr. Cette propriété dépend toutefois de la combinaison concrète et n’est pas garantie automatiquement par n’importe quel mécanisme hybride. Cette approche réduit le risque de dépendre entièrement d’un procédé cryptographique encore relativement récent durant les premières phases de migration.

Sophos publie désormais les noms des patterns détectés : TLS 1.3 PQC ML-KEM-512, ML-KEM-768, ML-KEM-1024, X25519 ML-KEM-768 et Hybrid Key Share. Les identifiants précis des signatures IPS ne sont toujours pas documentés publiquement.

Détection et pilotage des politiques via l’IPS

Avec TLS 1.3, le client annonce les groupes d’échange de clés pris en charge dès le ClientHello. Ces métadonnées sont transmises avant l’établissement de la session applicative chiffrée. L’IPS peut donc, en principe, reconnaître l’emploi d’un mécanisme PQC ou hybride dans la négociation TLS sans devoir déchiffrer ensuite le contenu HTTP.

Sophos fournit de nouveaux patterns IPS à cet effet. Pour qu’ils soient réellement analysés, IPS Protection doit être activé, une licence Network Protection valide doit être disponible et la politique IPS correspondante doit être associée à une règle de pare-feu. Une politique dédiée permet d’appliquer aux signatures concernées des actions telles que :

autoriser ;
journaliser ;
abandonner certains paquets ou la session entière ;
terminer la session TCP par un reset ;
désactiver la signature.

Les signatures PQC introduites avec MR2 sont désactivées par défaut. Ce choix est cohérent, car les navigateurs, plateformes cloud, CDN et bibliothèques TLS actuels adoptent de plus en plus couramment les procédés PQC hybrides. Si Sophos livrait immédiatement ces signatures avec une action de blocage par défaut, des connexions web et API légitimes pourraient être interrompues. Dans le premier fil de retours, Sophos explique également ce réglage par défaut par l’adoption croissante du TLS PQC et le risque d’un grand nombre d’alertes inutiles.

Je déconseille d’activer immédiatement ces nouvelles signatures en mode blocage. Il est préférable de créer une politique IPS distincte pour un groupe de test limité et de commencer par journaliser les détections. Le Log Viewer permet ensuite d’identifier les navigateurs, applications et destinations qui utilisent ML-KEM. Ce n’est qu’après avoir défini la politique cryptographique à appliquer et déterminé les services légitimes concernés que j’utiliserais Drop session ou Reset. La PQC n’est pas suspecte par nature : dans la plupart des cas, une détection indique simplement qu’une application utilise déjà des mécanismes TLS modernes.

Contrôle de la négociation TLS par Web Protection

En complément de l’IPS, Web Protection agit directement sur les négociations TLS autorisées. Selon Sophos, les sessions web ne peuvent pas négocier d’algorithmes PQC non pris en charge par le pare-feu. Cette mission diffère de la simple détection IPS : l’IPS classe la négociation visible et applique une action définie par la politique, tandis que Web Protection doit garantir qu’une session web protégée n’est établie qu’avec un procédé cryptographique compatible avec le chemin de traitement de SFOS.

Ce point est particulièrement important avec TLS Inspection. Le pare-feu n’est alors pas un simple observateur sur le chemin des données : il doit terminer la session TLS, vérifier ou réémettre les certificats et négocier des paramètres cryptographiques compatibles de part et d’autre. Un algorithme pris en charge par le navigateur et le serveur cible n’est donc pas nécessairement adapté à tous les moteurs d’inspection placés entre eux.

L’échange de clés PQC modifie aussi la négociation TLS sur le plan technique. Les Key Shares hybrides sont plus volumineux que les valeurs X25519 classiques et peuvent entraîner la répartition d’un ClientHello sur plusieurs paquets. De telles connexions sont conformes à TLS, mais elles peuvent solliciter davantage les anciennes middleboxes, les proxys ou les moteurs d’inspection non actualisés. La prise en charge ajoutée dans MR2 n’est donc pas seulement une nouvelle signature : c’est également une adaptation de compatibilité à une pile TLS en pleine évolution.

Sophos ne précise pas encore si Web Protection met fin à la session lorsqu’un procédé PQC n’est pas pris en charge, si la négociation revient à une méthode classique ou si le comportement dépend du chemin de données. Il ne faut donc pas déduire un mécanisme de fallback précis de l’annonce de la version. Un seul point est clair : les négociations PQC non prises en charge ne doivent pas contourner la couche de protection sans contrôle.

Après la mise à niveau, les environnements qui utilisent TLS Inspection devraient notamment effectuer les tests suivants :

Tester les versions actuelles de Chrome, Edge, Firefox et Safari avec les services SaaS et cloud les plus utilisés.
Accéder aux mêmes destinations une fois via une règle avec TLS Inspection et une fois sans.
Contrôler les exceptions TLS Inspection, les erreurs de certificat et les pages de blocage.
Rechercher dans les journaux IPS et Web Protection les nouveaux messages PQC, les erreurs de handshake et les resets.
Tester séparément les applications critiques disposant de leurs propres bibliothèques TLS, clients API ou runtimes Java.
En cas de problème, vérifier par Packet Capture si l’échec se produit dès le handshake TLS ou seulement après le démarrage de la session applicative protégée.
Décider seulement ensuite si une action explicite Allow, Drop ou Reset est nécessaire.

IA générative avec Synchronized Application Control

MR2 améliore la catégorisation des applications d’IA générative. La principale limite apparaît déjà dans le nom de la fonction : la visibilité supplémentaire repose sur Synchronized Application Control. Sophos Endpoint détecte localement les applications et transmet ces informations au pare-feu via Security Heartbeat. SFOS peut ensuite attribuer plus précisément l’application dans le reporting et les règles Application Control.

Cette fonction aide pour les applications qui communiquent via des protocoles web génériques, des CDN partagés ou des destinations changeantes et sont donc difficiles à identifier uniquement à l’aide de signatures de pare-feu classiques. Une catégorie plus précise permet notamment de mieux distinguer les applications web ordinaires des outils de GenAI et de déterminer quels utilisateurs ou appareils les emploient.

Il ne s’agit toutefois ni d’un CASB universel ni d’un système DLP. Le contenu confidentiel des prompts n’est pas analysé automatiquement et, sans Sophos Endpoint compatible, la même visibilité applicative n’est pas disponible. Dans les environnements Microsoft Defender ou mixtes, les contrôles DNS, web, TLS, proxy ou SSE/CASB restent donc pertinents.

Une politique efficace exige davantage que cette nouvelle catégorie :

Sophos Endpoint et Security Heartbeat doivent être correctement connectés.
Les applications inconnues doivent être classées régulièrement dans Synchronized Application Control.
Les règles de pare-feu doivent inclure une politique Application Control adaptée et la journalisation activée.
Les services GenAI autorisés, les comptes d’entreprise et les règles de protection des données doivent être définis.
Les données sensibles nécessitent des contrôles DLP, navigateur, Endpoint ou SaaS supplémentaires.

Le blocage général de toutes les applications GenAI est rarement la meilleure première mesure. Une politique graduée est plus judicieuse : autoriser les services d’entreprise validés, journaliser ou bloquer les services inconnus ou non évalués, puis analyser leur utilisation en fonction des besoins métier réels.

La procédure pratique pour le groupe pilote, l’Application Filter, le blocage et la validation est détaillée dans Détecter et contrôler l’IA générative avec Sophos Firewall.

Authentification : Chromebook, STAS et eDirectory

MR2 modifie trois domaines techniquement distincts de l’identification des utilisateurs. Au quotidien, ils concernent tous le même point critique : le pare-feu identifie-t-il l’utilisateur de manière fiable et lui applique-t-il la bonne politique ?

Chromebook User ID avec Manifest V3

La nouvelle Sophos Chromebook User ID Extension prend en charge Manifest V3 de Chrome. Manifest V3 est la plateforme d’extensions actuelle de Chrome ; elle modifie notamment les autorisations, les processus en arrière-plan et la manière dont les extensions traitent les événements réseau. Sans cette nouvelle version, l’ancienne extension Sophos ne recevrait plus de mises à jour régulières à terme.

Selon Sophos, aucune mise à jour in-place n’est prévue. Il faut désinstaller l’ancienne extension et installer la nouvelle. Dans les environnements Chromebook administrés, cette opération doit être menée depuis la console Google Admin ou la solution Endpoint Management utilisée :

Retirer l’ancienne Sophos Chromebook User ID Extension des installations forcées.
Ajouter la nouvelle version Manifest V3 et l’affecter aux groupes cibles.
Se connecter avec un utilisateur de test.
Vérifier sur le pare-feu que le nom d’utilisateur et l’adresse IP sont correctement associés.
Déclencher une politique de pare-feu ou web basée sur l’utilisateur et contrôler le résultat dans le Log Viewer.

L’ordre des opérations est essentiel. Si l’ancienne extension est retirée avant le déploiement de la nouvelle, l’association des utilisateurs est temporairement perdue. Les règles peuvent alors basculer vers une politique de fallback plus générale ou bloquer l’accès.

La procédure complète pour Device Access, le certificat, les règles de pare-feu, la politique JSON et API Controls est décrite dans Configurer le SSO Chromebook avec Google Workspace.

STAS n’interrompt plus le trafic par défaut pendant la vérification d’identité

Avec Sophos Transparent Authentication Suite (STAS), le pare-feu interroge l’identité de l’utilisateur Active Directory associé à une adresse IP lorsqu’un client est nouveau ou a changé. Le paramètre Restrict client traffic during identity probe détermine si le client peut déjà transmettre du trafic pendant cette vérification.

MR2 définit désormais la valeur par défaut sur No. Le trafic continue donc pendant que le pare-feu vérifie l’utilisateur et l’adresse de destination. Cela réduit les brèves interruptions, particulièrement perceptibles lors de nouvelles sessions, de changements d’utilisateur, du roaming ou de réponses tardives du STAS Collector.

Ce gain de confort implique un compromis : pendant la vérification, le pare-feu doit travailler avec le contexte d’identité alors disponible. Dans les environnements appliquant des règles utilisateur très strictes, il faut donc vérifier quelle politique s’applique durant ce court intervalle. Après la mise à jour, il ne faut pas supposer que les configurations existantes reprennent automatiquement cette valeur. Contrôlez la valeur actuelle, le comportement souhaité et les journaux réels.

Fin de Novell eDirectory avec SFOS 23.0

MR2 affiche également un avertissement de fin de vie pour Novell eDirectory Authentication Server. Sa prise en charge prendra fin avec SFOS 23.0. eDirectory continue de fonctionner dans MR2 : ce message constitue un avertissement préalable et non une suppression immédiate de la fonction.

Cette intégration ne nous manquera pas. Novell eDirectory n’est plus utilisé chez aucun de nos clients et ne joue depuis longtemps aucun rôle dans les nouveaux projets. Les rares environnements qui l’utilisent encore disposent d’un délai jusqu’à SFOS 23.0 pour migrer vers une source d’identité prise en charge. Outre l’Authentication Server, il faut alors vérifier les groupes importés, les règles de pare-feu, les autorisations VPN, les politiques web, le Captive Portal et les rapports basés sur les utilisateurs.

La procédure Migrer eDirectory avant SFOS 23 explique comment basculer de manière contrôlée la source cible, les groupes et les services tout en conservant un retour arrière.

Let’s Encrypt et gestion des certificats

SFOS 22.0 MR2 actualise la prise en charge des nouveaux certificats racine et intermédiaires Let’s Encrypt. Les chaînes YE Root, YE1, YE2, YR Root, YR1 et YR2 sont désormais prises en compte. Sophos Firewall prépare ainsi l’émission et le renouvellement automatiques des certificats aux chaînes Let’s Encrypt actuelles et futures.

Cette évolution est importante, car une requête ACME correcte ne suffit pas. Le pare-feu, le correspondant et les clients doivent aussi pouvoir construire et valider correctement la chaîne du certificat émis. Des Trust Stores obsolètes peuvent sinon provoquer des erreurs de certificat apparemment inexplicables, alors même que le certificat Leaf est valide.

Les notifications e-mail Let’s Encrypt incluent désormais également le nom d’hôte et le numéro de série du pare-feu. Dans les environnements comportant plusieurs appliances, il devient plus rapide d’identifier l’appareil à l’origine d’un renouvellement, d’une erreur ou d’un autre message relatif aux certificats. Le numéro de série fait toutefois partie des données d’inventaire de l’équipement ; ces notifications doivent donc être envoyées uniquement à des destinataires et boîtes aux lettres contrôlés.

Après la mise à jour, un test complet des certificats est recommandé :

Contrôler l’état ACME et la date du prochain renouvellement.
Vérifier le nom d’hôte, la résolution DNS et l’accessibilité du challenge.
Valider la chaîne de certificats dans le navigateur ou avec un test TLS externe.
Examiner séparément les certificats WAF, WebAdmin, User Portal et VPN.
Vérifier la réception de la nouvelle notification e-mail et la liste des destinataires.

Config Studio 2.6 améliore l’analyse et la migration

En parallèle de MR2, Sophos met en avant Firewall Config Studio 2.6. Cet outil fonctionne dans le navigateur, en dehors du pare-feu ; il ne s’agit donc pas d’une fonction WebAdmin intégrée au Build 546. Il complète néanmoins l’exploitation dans des domaines où SFOS ne propose toujours que des possibilités d’analyse et de comparaison limitées.

Les principales fonctions de la version 2.6 sont :

Merge templates : une configuration de référence peut être combinée à un modèle propre à un secteur ou à un cas d’utilisation. Cette fonction accélère les déploiements standardisés, mais ne dispense pas de vérifier les conflits entre objets, interfaces ou règles.
Enhanced Global Search : les objets peuvent être recherchés globalement et ouverts directement à leur point d’utilisation. Cela facilite particulièrement l’analyse des grandes bases de règles et la suppression de dépendances ambiguës.
Improved Configuration Report : les règles Firewall, NAT et TLS affichent non seulement les noms des objets référencés, mais aussi leurs valeurs et détails. Les revues deviennent plus compréhensibles sans devoir ouvrir chaque objet séparément.
Migration Insights : après une conversion, Config Studio indique la part migrée avec succès. Ce pourcentage reste une orientation, pas une validation : les VPN, l’authentification, les certificats et les fonctions propres au constructeur qui n’ont pas été transférés doivent toujours être contrôlés manuellement.
Multi-file Configuration Diff : plusieurs états de configuration peuvent être comparés. Il devient ainsi possible de déterminer entre quelles sauvegardes une modification, une erreur ou un écart indésirable est apparu.
Compatibilité de restauration des sauvegardes : l’outil aide à vérifier si une sauvegarde peut être restaurée sur un autre modèle Sophos Firewall.
Référence Flexi-Port et vitesse des ports : les agencements de ports, les modules Flexi ainsi que les vitesses prises en charge jusqu’à 25, 40 ou 100 Gbit/s peuvent être comparés avant une migration matérielle.

Config Studio 2.6 est présenté plus en détail dans l’article Sophos Firewall Config Studio 2.6 : migration intégrée. Le workflow pratique pour les fonctions Report, Compare, Editor et la réimportation contrôlée est décrit dans Utiliser Sophos Firewall Config Studio.

Les 53 problèmes corrigés dans le Build 546

Sophos annonce plus de 50 correctifs de stabilité, de fiabilité et de sécurité. La classification suivante reprend les 53 identifiants des notes de version officielles. Cette liste ne remplace pas une évaluation individuelle par le support, mais indique la fonction concernée et l’importance opérationnelle de chaque correctif.

Pare-feu, noyau, HA et stabilité du système

NC-180331 – Gestion incorrecte de la mémoire dans algif_aead et algif_skcipher : corrige une vulnérabilité du noyau Linux dans des composants cryptographiques.
NC-181331 – Une partition de configuration pleine plaçait le pare-feu en mode Failsafe : réduit le risque d’interruption dû à l’épuisement de l’espace de configuration.
NC-180974 – Un plantage du noyau dans sdwan_profile provoquait un basculement HA : stabilise les environnements SD-WAN et évite les changements de rôle inutiles dans le cluster.
NC-178354 – Plantage du noyau pendant l’évaluation d’une règle SD-WAN : empêche les crashs lors de l’analyse des règles SD-WAN.
NC-178413 – Une valeur vide dans Services provoquait une erreur ipset et le mode Failsafe : traite plus efficacement les objets Service endommagés ou incomplets.
NC-177934 – Le pare-feu passait en mode Failsafe après la mise à niveau vers SFOS 22.0 GA : corrige une conséquence directe de la mise à niveau depuis les premiers builds v22.
NC-177441 – L’équipement HA initialement primaire passait en mode Failsafe après la mise à niveau vers SFOS 22.0 GA : améliore la stabilité au démarrage du nœud primaire après la mise à niveau.
NC-177467 – L’équipement auxiliaire ne démarrait pas en présence d’un très grand nombre de connexions SSH simultanées non authentifiées : important pour les systèmes HA exposés ou fortement scannés ; ce correctif est précisément surveillé dans les premiers retours MR2 concernant le cluster HA XGS 5500.
NC-173031 – Les Application Policies importées n’étaient pas automatiquement synchronisées avec l’équipement auxiliaire : assure une meilleure cohérence des politiques entre les deux nœuds HA.
NC-177536 – La mise à niveau vers SFOS 22.0 GA échouait sur l’équipement HA primaire : stabilise le chemin de mise à niveau dans les clusters HA.
NC-178745 – L’équipement HA redémarrait automatiquement en raison d’une erreur Out of Memory : réduit les redémarrages imprévus liés au domaine de la journalisation.
NC-180110 – L’équipement HA primaire passait en mode Failsafe parce que le démon de journalisation ne démarrait pas : empêche une erreur de démarrage du service de journalisation de mettre hors service l’ensemble du nœud primaire.
NC-180933 – Les administrateurs ne pouvaient pas se connecter à la console WebAdmin : corrige une perte directe de l’accès administratif à l’interface graphique.
NC-177769 – Le service eBPF ne répondait plus après une mise à jour des patterns : stabilise le chemin de données accéléré après l’actualisation des signatures.
NC-180152 – Les mises à jour d’interfaces prenaient plus de temps dans SFOS 22.0 GA que dans 21.5 : réduit le délai d’application des modifications d’interfaces.
NC-179462 – Avertissements répétés lors de la lecture des statistiques matérielles : supprime du bruit inutile dans les journaux des appliances XGS.

Règles de pare-feu, trafic utilisateur et routage

NC-181741 – Le trafic d’utilisateurs non authentifiés était abandonné toutes les heures : évite des interruptions régulières dans les environnements qui autorisent ce trafic.
NC-178903 – Les utilisateurs SATC perdaient l’accès à Internet après la mise à niveau vers SFOS 22.0 GA : rétablit l’accès basé sur les utilisateurs avec Sophos Authentication Thin Client.
NC-178141 – Certains messages d’erreur ICMP étaient abandonnés par la Local ACL après la mise à niveau GA : améliore Path MTU Discovery et le diagnostic des erreurs pour lesquels ICMP est techniquement nécessaire.
NC-178197 – Le trafic applicatif s’interrompait temporairement avec une Bandwidth Policy basée sur l’application : stabilise la QoS des règles qui gèrent la bande passante en fonction des applications détectées.
NC-180226 – L’interface graphique ne signalait pas les adresses MAC en double dans Spoof protection trusted MAC : évite les erreurs de configuration silencieuses dans la liste d’exceptions Spoof Protection.
NC-181299 – La base GeoIP attribuait une adresse IP au Royaume-Uni au lieu de l’Allemagne : corrige l’affectation géographique utilisée par les règles GeoIP et les rapports.

IPsec et VPN

NC-180433 – Le multicast à travers un tunnel VPN provoquait des plantages répétés du pare-feu : important pour le routage, le streaming ou les mécanismes de découverte utilisant le multicast sur IPsec.
NC-178121 – Les connexions Site-to-Site IPsec se retrouvaient au mauvais emplacement dans le Failover Group après un glisser-déposer : garantit la conservation effective de la priorité des tunnels configurée.
NC-171719 – Problème de routage SD-WAN avec le trafic ESP : améliore la sélection du chemin pour IPsec/ESP natif dans les scénarios SD-WAN.
NC-180520 – La passerelle XFRM restait inaccessible avec accélération IPsec, Alias IP et trafic ESP entrant par un autre port WAN : corrige un cas particulier complexe Multi-WAN avec tunnels IPsec accélérés.
NC-176855 – Faible débit IPv6 sur IPsec route-based : améliore les performances IPv6 des architectures VPN à base de tunnels.
NC-181687 – La création d’une politique SSL VPN se terminait par une erreur interne du serveur : rétablit la création des politiques dans la nouvelle architecture Control Plane/HA.
NC-175860 – Remote Access IPsec tombait en panne après un basculement HA si l’Appliance Certificate avait été recréé : stabilise les connexions d’accès distant basées sur certificat lors des changements de rôle.

Authentification, Central et gestion des configurations

NC-180824 – Les nouveaux utilisateurs AD d’un groupe AD secondaire ne pouvaient pas se connecter au VPN Portal : corrige la prise en compte des appartenances aux groupes secondaires ou imbriqués pour l’accès au portail.
NC-176806 – Microsoft Entra ID SSO échouait en raison de CA intermédiaires manquantes : améliore la validation des certificats lors des connexions Entra ID.
NC-160157 – Last access time subsistait après la suppression d’un utilisateur et apparaissait pour le compte recréé : évite l’affichage trompeur d’anciens accès après la recréation d’un compte.
NC-181175 – Le Group Policy Push depuis Sophos Central restait sur pending et n’était pas appliqué : corrige les modifications de groupes bloquées dans la gestion centralisée.
NC-180513 – L’importation de configuration depuis la vue Sophos Central ne fonctionnait plus après la mise à niveau MR1 : rétablit l’importation via Central.
NC-181904 – Les e-mails en quarantaine ne pouvaient pas être libérés depuis Sophos Central : corrige ce workflow Central connu ; le WebAdmin local constituait auparavant la solution de contournement pratique.

La Central Firewall Task Queue doit continuer à être contrôlée après la mise à jour. La correction d’un défaut du produit ne garantit pas que les anciennes tâches bloquées ou les états de groupes incohérents disparaissent automatiquement.

Journalisation et reporting

NC-181520 – Le Log Viewer était trop lent : améliore la réactivité des recherches et des analyses d’erreurs.
NC-172912 – Le System Graph scintillait : stabilise l’affichage des métriques système.
NC-172020 – Les pare-feu sans On-box Reporting envoyaient des PDF Traffic Dashboard vides : évite les rapports quotidiens sans contenu.
NC-169646 – Les PDF On-demand contenaient des graphiques et tableaux erronés dans Chrome : corrige la génération de rapports dans le navigateur.
NC-155252 – Une forte activité d’E/S disque provoquait des pics CPU et des coupures Internet pouvant durer une minute : un correctif de stabilité particulièrement important pour les systèmes sollicitant fortement le reporting et la journalisation.

NC-178745 et NC-180110, cités dans la section sur la stabilité, concernent également le Logging Framework, mais affectaient toute l’appliance sous la forme d’un redémarrage ou d’un passage en mode Failsafe.

E-mail, antivirus et Security Heartbeat

NC-180066 – Les mises à jour de patterns SAVI et AVIRA échouaient et arrêtaient le service antivirus : garantit qu’une erreur de pattern ne met plus fin à l’ensemble du service AV.
NC-177930 – Les e-mails restaient dans le spool après un plantage de mailpoller : évite le blocage de la distribution des e-mails en mode MTA.
NC-171602 – Les notifications du pare-feu échouaient au contrôle DKIM : améliore la distribution des e-mails système signés.
NC-176012 – Un Heartbeat manquant était signalé lorsque deux Endpoints utilisaient la même station d’accueil ou interface USB : réduit les fausses alertes Heartbeat lorsque plusieurs appareils partagent le même matériel.

Les utilisateurs du mode MTA devraient tester après la mise à jour le Mail Spool, la quarantaine, DKIM et la libération depuis Central en suivant l’article Sophos Firewall Mail Protection en mode MTA.

WAF, Web Protection et RED

NC-180200 – Le WAF s’arrêtait dans la Home Edition pendant la synchronisation nocturne des licences : évite les arrêts réguliers du WAF dans les installations Home Edition.
NC-177457 – Lorsque le débogage WAF était activé, le mot de passe apparaissait dans reverseproxy.log : corrige une divulgation sensible en texte clair dans le journal de débogage. Les anciens journaux de débogage doivent malgré tout être contrôlés et protégés ou supprimés conformément aux règles applicables.
NC-176788 – ResponseFieldSize revenait à la valeur par défaut lors du changement de certificat d’une règle WAF : conserve la limite de taille volontairement configurée lors des modifications de certificat.
NC-167019 – Snort provoquait une charge CPU élevée avec du trafic Veeam sans exception : réduit les pics de charge pendant les sauvegardes ; les exceptions existantes doivent néanmoins être réévaluées.
NC-178906 – Le pare-feu passait en mode Failsafe avec le message Failed to start Red server service : stabilise le service RED Server et évite le mode Failsafe à l’échelle de l’appliance.

Firmware, DDNS et interface utilisateur

NC-170200 – Plusieurs tentatives de mise à niveau en quelques minutes faisaient échouer les mises à jour du firmware : renforce Firmware Management ; il reste néanmoins préférable d’éviter les lancements parallèles ou les répétitions précipitées.
NC-180219 – Cloudflare DDNS ne fonctionnait plus après la mise à niveau vers SFOS 22.0 MR1 : rétablit les mises à jour DNS dynamiques pour Cloudflare.
NC-181575 – Le champ horaire de Schedules était mal affiché : évite les erreurs d’interprétation lors de la modification de règles planifiées.
NC-171424 – Après la suppression de la seule exception de la dernière page, la liste Web Exceptions semblait vide : revient correctement à la page précédente au lieu d’afficher une configuration apparemment vide.

Planifier la mise à niveau et valider MR2

Sophos prend en charge la mise à niveau vers v22 MR2 depuis toutes les versions prises en charge des séries v21.5, v21 et v20. L’image du firmware peut être téléchargée manuellement via Sophos Central ; son déploiement automatique sur les appareils connectés sera échelonné au cours des prochaines semaines. Selon Sophos, la mise à jour est disponible sans frais de firmware supplémentaires pour les pare-feu sous licence disposant d’un support Enhanced ou Enhanced Plus.

Malgré cette longue liste de correctifs, MR2 ne devrait pas être déployée sans test simultanément sur tous les systèmes. Le fil public consacré aux retours n’a été ouvert que le jour de la publication. Les premiers messages s’interrogent notamment sur la stabilité des XGS 5500 en HA Active-Passive et sur le correctif NC-177467. Il ne s’agit pas encore d’un nouveau défaut MR2 confirmé, mais c’est une bonne raison de mettre à niveau progressivement les systèmes HA et les sites critiques.

Avant la mise à jour

Vérifier le chemin de mise à niveau pris en charge et l’état de la licence.
Créer une sauvegarde complète et chiffrée, puis la conserver hors du pare-feu.
Effectuer le SFOS 22 Upgrade Check.
Évaluer les constats encore ouverts dans le Sophos Firewall Health Check.
Contrôler l’état HA, les SSD, l’espace libre sur les partitions et l’état des patterns.
Documenter les fonctions critiques : WAN, SD-WAN, IPsec, SSL VPN, WAF, MTA, DDNS, authentification et Central Management.
Préparer la fenêtre de maintenance, l’accès à la console locale et la décision de rollback.

Après la mise à jour

Vérifier le Build 22.0 MR2 546, l’état du système et les Hotfixes actifs.
En HA, contrôler les deux nœuds, la synchronisation, les rôles et le basculement.
Tester WAN, DNS, DHCP/DDNS, SD-WAN et l’accès Internet.
Vérifier les VPN Site-to-Site et Remote Access, y compris IPv6 et le basculement.
Valider AD, Entra ID, STAS, SATC et la connexion aux portails avec des utilisateurs de test.
Contrôler WAF, Let’s Encrypt, MTA, la quarantaine et les notifications.
Vérifier la Central Task Queue et les dernières modifications de groupes appliquées.
Rechercher dans le Log Viewer les nouvelles erreurs, indications Failsafe, redémarrages de services et notifications PQC.
Ne mettre à niveau les autres appliances qu’après une période d’observation stable.

La procédure complète de sauvegarde, de fenêtre de maintenance et de contrôle après mise à jour est décrite dans Préparer une mise à jour du firmware Sophos Firewall.

Conclusion

Sophos Firewall v22 MR2 est une Maintenance Release pertinente au contenu inhabituellement large. La cryptographie post-quantique et l’amélioration de la catégorisation GenAI montrent l’évolution du contrôle des réseaux et des applications. Chromebook Manifest V3, STAS et Let’s Encrypt sont moins spectaculaires, mais répondent à des problèmes concrets de cycle de vie et d’exploitation.

La stabilité reste la principale raison d’installer le Build 546 : plusieurs plantages du noyau, états Failsafe, problèmes HA et VPN, un mot de passe en clair dans le journal de débogage WAF ainsi que des pannes importantes dans la journalisation, le reporting, l’antivirus et la messagerie ont été corrigés. Compte tenu de l’ampleur de ces interventions, cette mise à jour ne doit pas être considérée comme un simple clic. Sauvegarde, déploiement progressif et contrôle ciblé des fonctions restent indispensables.