Sophos Firewall v22 MR2 : mise à jour ou nouveau risque ?

Sophos Firewall v22 MR2 est disponible. Publiée le 14 juillet 2026, la build 546 apporte un ensemble mesuré, mais pertinent, de fonctions de sécurité, de changements d’authentification, d’adaptations de certificats et de plus de 50 corrections de bugs.

Sur le papier, il s’agit d’une Maintenance Release classique. En pratique, elle réunit précisément les éléments qui m’incitent désormais à regarder deux fois chez Sophos : une nouvelle logique de détection IPS, un comportement modifié pour l’attribution des utilisateurs, de nouvelles chaînes de certificats et, en parallèle, une longue liste de crashs du noyau, de problèmes HA, d’états Failsafe, d’erreurs VPN et d’interruptions du reporting.

Tout cela n’est pas uniquement positif. Lorsqu’une Maintenance Release corrige plus de 50 bugs, cela montre d’un côté que Sophos fait le ménage. Mais cela montre aussi combien de problèmes sérieux subsistaient encore dans les versions GA et MR1. J’ai déjà critiqué cette qualité de firmware dans Sophos Firewall : aucune CVE, mais des bugs (v21.5 à v22).

Je vais installer MR2 immédiatement sur l’un de mes Sophos Firewall. Non pas parce que je fais aveuglément confiance à cette version dès le premier jour, mais parce que je veux voir si la build 546 stabilise enfin la branche v22 ou si, une fois encore, la mise à jour introduit plus de nouveaux bugs qu’elle n’en corrige. Je surveillerai notamment la HA, les logs, IPsec, la réactivité de WebAdmin, STAS et la stabilité après les mises à jour de patterns.

En même temps, Sophos crée avec cette version un contraste étrange. Config Studio 2.6 occupe désormais une place importante dans les communications officielles sur les mises à jour du firewall. Cet outil externe dans le navigateur reçoit la fusion de templates, une meilleure recherche, des diffs multifichiers, des analyses de migration et des données de compatibilité matérielle. Dans l’interface même du firewall, en revanche, presque aucune évolution visible ne concerne l’administration quotidienne.

Je considère donc MR2 comme importante sur le plan technique, mais décevante sur le plan stratégique. Le moteur de sécurité reçoit de nouvelles fonctions, tandis que les workflows d’administration modernes sont une nouvelle fois déportés vers Config Studio.

L’essentiel en bref

SFOS 22.0 MR2 porte le numéro de build 546 et succède à MR1 build 490. Sophos met en avant sept domaines principaux :

• détection et contrôle de la cryptographie post-quantique ;
• meilleure catégorisation des applications d’IA générative ;
• nouvelle extension Chromebook User ID basée sur Manifest V3 ;
• modification du comportement par défaut de STAS ;
• annonce anticipée de la fin de prise en charge de Novell eDirectory dans SFOS 23.0 ;
• nouvelles chaînes de confiance Let’s Encrypt et notifications par e-mail améliorées ;
• Config Studio 2.6 avec de nouvelles fonctions d’analyse, de migration et de comparaison.

À cela s’ajoutent plus de 50 problèmes corrigés. Du point de vue de l’exploitation, certains de ces correctifs sont plus importants que les nouvelles fonctions : ils concernent des crashs du noyau, des problèmes HA, des états Failsafe, des erreurs VPN et des problèmes de performances du reporting.

Mon évaluation en quelques points :

• Les installations déjà sous v22 GA ou MR1 et affectées par l’un des bugs répertoriés ont une raison concrète de passer à MR2.
• Une installation 21.5 stable ne doit pas être mise à niveau dans la précipitation uniquement pour PQC ou Config Studio.
• Les signatures PQC doivent d’abord fonctionner en simple mode d’observation, et non immédiatement avec l’action Drop.
• Les environnements STAS doivent vérifier après la mise à niveau comment le trafic non authentifié est traité pendant l’Identity Probe.
• Les installations HA, IPsec, WAF, mail et reporting exigent de vrais tests fonctionnels, pas un simple coup d’œil à des indicateurs verts.
• Config Studio 2.6 est techniquement utile, mais ne prouve en rien que l’interface SFOS WebAdmin se modernise. Bien au contraire.

La limite matérielle reste essentielle : SFOS 22.0 ne prend plus en charge les appliances matérielles XG et SG. La version vise les installations XGS, virtuelles, logicielles et cloud prises en charge. Les exploitants de matériel XG ne peuvent donc pas planifier MR2 comme une étape normale de mise à niveau du firmware.

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

La nouveauté la plus intéressante techniquement est le contrôle de la cryptographie post-quantique, ou PQC. Il ne s’agit pas pour Sophos Firewall de repousser soudainement des ordinateurs quantiques. La fonction porte sur des mécanismes modernes d’échange de clés cryptographiques conçus pour mieux résister à de futures attaques menées avec des ordinateurs quantiques suffisamment puissants.

MR2 se concentre sur ML-KEM. Standardisé en 2024 sous la forme de FIPS 203, ce mécanisme repose sur la difficulté supposée du problème Module Learning With Errors. Le NIST définit trois jeux de paramètres :

• ML-KEM-512, qui utilise les clés et volumes de données les plus petits ;
• ML-KEM-768, variante intermédiaire aujourd’hui particulièrement répandue ;
• ML-KEM-1024, avec un niveau de sécurité supérieur, mais davantage de calculs et de données à transmettre.

Dans sa documentation MR2, Sophos parle seulement d’algorithmes d’échange de clés purs et hybrides basés sur ML-KEM. Les jeux de paramètres, groupes TLS ou identifiants de signatures effectivement couverts ne sont pas précisés. Il ne faut donc pas supposer automatiquement que toutes les variantes ML-KEM imaginables sont détectées.

Ce que fait techniquement un KEM

ML-KEM ne chiffre pas directement l’ensemble du flux de données. De manière simplifiée, un Key Encapsulation Mechanism comprend trois opérations :

1. KeyGen produit une Encapsulation Key et la Decapsulation Key correspondante.
2. Encaps utilise la clé d’encapsulation publique pour produire un objet Ciphertext et un secret partagé.
3. Decaps récupère ce même secret, côté destinataire, à l’aide de la Decapsulation Key privée.

Le protocole dérive ensuite de ce secret partagé des clés de session symétriques. Les données utiles restent protégées par des mécanismes symétriques rapides tels qu’AES ou ChaCha20. ML-KEM remplace donc la partie asymétrique vulnérable de la négociation de clés, et non l’intégralité du chiffrement des données TLS.

Le contexte pratique est celui du Harvest now, decrypt later : un attaquant peut enregistrer aujourd’hui du trafic chiffré en espérant pouvoir le déchiffrer dans quelques années avec un ordinateur quantique cryptographiquement pertinent. L’enjeu est moindre pour des données éphémères. Pour des données médicales, des communications gouvernementales, de la propriété intellectuelle ou des informations d’entreprise durablement confidentielles, la durée de protection nécessaire peut toutefois dépasser le délai avant l’apparition d’une nouvelle classe d’attaque.

Pur et hybride ne signifient pas la même chose

Dans un échange de clés PQC pur, la sécurité de la négociation repose uniquement sur le nouveau mécanisme post-quantique. Un échange hybride combine au contraire un mécanisme classique avec ML-KEM. X25519MLKEM768 constitue un exemple répandu en pratique : la composante classique X25519 et ML-KEM-768 contribuent ensemble au secret obtenu.

L’approche hybride est actuellement raisonnable. Si une erreur d’implémentation ou une faiblesse mathématique de ML-KEM apparaît ultérieurement, la composante classique demeure. À l’inverse, si un ordinateur quantique suffisamment puissant parvient à casser la courbe elliptique classique, la composante ML-KEM reste présente. L’hybridation est donc une passerelle de migration, et non un double chiffrement superflu.

Précision importante : X25519MLKEM768 est ici un exemple technique réel tiré d’implémentations TLS actuelles. Sophos n’indique pas explicitement dans sa documentation MR2 que ce groupe serait la seule ou la principale variante détectée.

Ce que fait l’IPS

L’Intrusion Prevention System reçoit de nouvelles signatures capables de détecter des échanges de clés ML-KEM purs et hybrides. Les administrateurs peuvent créer des règles IPS spécifiques et choisir des actions telles que Allow, Drop ou Reset.

Techniquement, un firewall peut reconnaître l’échange proposé et retenu dans le handshake TLS : le client annonce ses groupes et Key Shares pris en charge dans le ClientHello, puis le serveur confirme son choix dans le ServerHello. Cette phase précède le flux applicatif chiffré. Une détection est donc en principe possible sans lire ensuite le contenu HTTPS.

Sophos ne documente toutefois ni l’endroit où Snort ou le pipeline IPS de SFOS analyse ces caractéristiques, ni les versions TLS couvertes, ni les éventuelles différences entre les trafics proxy, DPI et FastPath non déchiffrés. Les Release Notes confirment la capacité, mais pas son implémentation interne dans le chemin de données. Une politique de production exige donc un test spécifique avec les logs firewall et IPS.

Les actions ont des effets différents :

• Allow laisse passer la connexion et, avec la journalisation, convient à un inventaire initial.
• Drop rejette silencieusement les paquets correspondants. Le client voit généralement un timeout ou un handshake interrompu.
• Reset met activement fin à la connexion TCP. L’erreur apparaît plus vite, mais peut se présenter différemment pour l’utilisateur et dans les logs applicatifs.

Les nouvelles signatures sont désactivées par défaut. C’est le bon choix. PQC n’est plus une simple technologie de laboratoire : de grands navigateurs, services cloud et plateformes web testent ou utilisent déjà des mécanismes hybrides. Si Sophos bloquait globalement ces connexions, des sites et applications légitimes pourraient tomber en panne.

Le déploiement raisonnable est donc le suivant :

1. Activer d’abord les signatures tout en autorisant et journalisant uniquement le trafic.
2. Évaluer pendant plusieurs jours ou semaines les applications et destinations qui utilisent ML-KEM.
3. Vérifier si les politiques cryptographiques internes interdisent ou imposent certains mécanismes.
4. N’appliquer qu’ensuite, de manière ciblée, Drop ou Reset.

Dans la première discussion communautaire, un administrateur a signalé immédiatement après la mise à niveau qu’il ne trouvait pas les signatures IPS correspondantes avec des termes tels que PQC, KEM ou quantum. Cela peut venir d’une mise à jour de patterns non encore reçue ou de la nomenclature utilisée. Quelques heures après la publication, on ne peut pas encore en déduire un bug produit avéré. Cela révèle néanmoins un problème de documentation : une fonction n’est administrable que si le nom de la signature, la SID, la catégorie et les caractéristiques du log sont trouvables.

Avant toute modification de policy, je vérifierais donc concrètement :

• L’IPS est-il actif et la subscription Network Protection valide ?
• Quelle version des patterns IPS est installée ?
• Sous quel nom et quelle SID apparaissent les nouvelles signatures ?
• Les détections remontent-elles dans le log IPS et le reporting central ?
• La détection reste-t-elle identique avec les exceptions DPI, TLS Inspection et FastPath ?
• Quels navigateurs, systèmes d’exploitation, services cloud et applications internes génèrent des détections ?

Ce que fait Web Protection

D’après Sophos, Web Protection empêche en outre les sessions web de négocier des algorithmes PQC non pris en charge. Cette tâche diffère de celle d’une signature IPS. L’IPS détecte certains motifs et peut réagir. Web Protection intervient dans le workflow TLS et web contrôlé afin d’empêcher une connexion d’utiliser un mécanisme que le firewall ne peut traiter ou que la politique n’autorise pas.

Cela devient surtout pertinent avec TLS Inspection. Pour une connexion déchiffrée, le firewall termine la session TLS du client et établit lui-même une seconde session TLS avec le serveur cible. Il existe donc deux handshakes distincts et deux ensembles de clés de session. Un navigateur et un serveur web peuvent prendre en charge PQC alors que le composant d’inspection intermédiaire ne sait pas correctement traiter le groupe proposé.

Sans comportement contrôlé, des erreurs difficiles à interpréter apparaissent : le client propose un nouveau groupe, le firewall ne peut pas relayer complètement le handshake, le serveur choisit une variante inattendue ou un fallback se comporte autrement que prévu. MR2 doit empêcher les sessions web de négocier des algorithmes PQC non pris en charge.

Ce que Sophos ne décrit pas précisément est tout aussi important : aucune matrice de policy PQC propre à Web Protection, aucune liste de groupes pris en charge et aucune indication claire sur le fait qu’une offre non prise en charge est supprimée, rejetée ou remplacée par un fallback classique. Il ne faut pas confondre ce comportement avec l’action IPS librement configurable.

La fonction est pertinente, mais elle ne remplace pas une stratégie cryptographique. Les entreprises doivent toujours savoir quelles connexions TLS sont déchiffrées, où se trouvent les exceptions et si PQC doit seulement être observé ou réellement imposé.

Les applications d’IA générative deviennent plus visibles

La deuxième nouvelle fonction de sécurité concerne les applications d’IA générative. Sophos améliore leur catégorisation par l’intermédiaire de Synchronized Application Control.

Le principe n’est pas nouveau : Sophos Endpoint voit quel processus local ouvre une connexion et transmet le contexte applicatif au firewall via Security Heartbeat. Le firewall peut ainsi associer une session à un programme même lorsque le port, l’adresse IP de destination et le trafic chiffré ne permettent pas à eux seuls une identification univoque.

De manière simplifiée, le chemin de données technique est le suivant :

1. Une application sur un endpoint protégé ouvre une connexion réseau.
2. Sophos Endpoint connaît le nom du processus, son chemin et son contexte applicatif local.
3. Security Heartbeat relie les vues endpoint et firewall.
4. SFOS attribue la session jusque-là inconnue, ou seulement reconnue grossièrement, à une application.
5. L’application apparaît dans Synchronized Application Control et peut être catégorisée.
6. Une Application Filter Policy autorise, bloque ou régule le trafic correspondant.

Dans la Connection List, SFOS peut demander des informations à l’endpoint avec Resolve application info pour les connexions non identifiées. La liste des applications peut être recherchée par nom, chemin, catégorie ou endpoints. Sophos indique une limite de 15 000 applications gérées via Synchronized Application Control. Pour économiser la mémoire, le firewall ne conserve que les cinq occurrences les plus récentes par application et endpoint.

MR2 améliore spécifiquement l’attribution des applications d’IA générative. Sophos Endpoint doit mieux les reconnaître et transmettre l’information au firewall. La catégorie Generative AI existe dans la liste d’applications SFOS et peut ainsi être utilisée dans les Application Filters et les rapports.

Trois aspects intéressent les administrateurs :

• Visibilité : le reporting doit montrer plus clairement quelles applications d’IA générative sont utilisées dans l’entreprise.
• Règles : les applications identifiées peuvent être autorisées, limitées ou bloquées plus précisément.
• Inventaire : les équipes sécurité et protection des données disposent d’une meilleure base pour distinguer les services d’IA approuvés de ceux qui ne le sont pas.

C’est utile, mais il ne faut pas donner à l’expression « détecter l’IA générative » une portée qu’elle n’a pas.

Synchronized Application Control répond principalement à la question : quelle application a généré la connexion ? Il ne détermine pas automatiquement :

• quel prompt l’utilisateur a saisi ;
• quel fichier a été téléversé ;
• si des données personnelles ou confidentielles étaient présentes ;
• si une session de navigateur relève d’un usage privé ou professionnel de l’IA ;
• si un service d’IA autorisé a été utilisé au sein du navigateur par une fonction intégrée.

Un client desktop au chemin de processus univoque est plus facile à attribuer que dix services web d’IA fonctionnant tous dans le même processus de navigateur. La catégorisation d’URL, TLS Inspection et la détection de Cloud Apps peuvent fournir des informations supplémentaires, mais constituent techniquement d’autres couches de détection.

La valeur ajoutée dépend également de Sophos Endpoint, d’un Security Heartbeat actif et de Synchronized Application Control activé. La première activation s’effectue dans Sophos Central. Une installation SFOS sans Sophos Endpoint, ou avec des endpoints hors du chemin Heartbeat, n’obtient pas automatiquement la même profondeur de détection.

Il faut donc avoir la bonne attente : MR2 améliore l’attribution des applications, et donc la base des policies. Elle ne résout pas à elle seule la question organisationnelle des services d’IA autorisés et des données qui peuvent y être traitées.

Après la mise à niveau, je ne bloquerais pas immédiatement toute la catégorie Generative AI. Le reporting doit d’abord indiquer quelles détections viennent du contexte endpoint, d’une signature firewall ou de la catégorisation web. Sans cela, on risque de bloquer des fonctions productives dans Microsoft 365, des outils de développement, des navigateurs ou des plateformes de support sans comprendre l’usage réel.

Modifications de l’authentification et de l’attribution des utilisateurs

MR2 apporte trois sujets d’authentification indépendants. Deux exigent une préparation concrète ; le troisième est un avertissement de migration anticipé.

Chromebook User ID avec Manifest V3

L’extension Sophos Chromebook User ID a été migrée vers Manifest V3, la plateforme d’extensions actuelle de Chrome qui remplace l’ancienne base technique.

Point essentiel : Sophos impose la désinstallation de l’ancienne extension et l’installation de la nouvelle version. Une simple mise à jour silencieuse de l’ancienne extension ne suffit donc pas. Les écoles et entreprises qui administrent leurs Chromebooks de manière centralisée doivent préparer ce changement dans leurs policies Google Admin, le valider avec un groupe pilote, puis le déployer largement.

Techniquement, l’extension n’est qu’une partie du chemin SSO. Pour Chromebook SSO, Sophos exige notamment :

• un serveur AD, LDAP ou Google Secure LDAP configuré sur le firewall ;
• des Chromebooks présents sur le réseau protégé par SFOS ;
• des adresses utilisateur issues du domaine Google Workspace enregistré ;
• un certificat pour la communication chiffrée ;
• un CN correspondant au certificat ;
• par défaut, le port de communication Sophos 65123 ;
• une configuration JSON exportée de SFOS et enregistrée dans Google Workspace ;
• l’accès à accounts.google.com, aux Google API Hosts et au Chrome Web Store.

Dans Google Workspace, la nouvelle extension est distribuée sous Devices > Chrome > Apps and extensions > Users and browsers. Pour les environnements de production, Force install est judicieux afin d’empêcher les utilisateurs de supprimer l’extension nécessaire à l’attribution d’identité. L’application Sophos User ID doit en outre être déclarée fiable dans API Controls, sans quoi OAuth peut échouer.

Après le changement, je ne vérifierais pas seulement si l’extension est installée. C’est toute la chaîne qui compte :

1. L’utilisateur se connecte au Chromebook.
2. L’extension atteint le firewall via le réseau et le certificat prévus.
3. L’utilisateur apparaît sous Live users.
4. Une règle basée sur l’utilisateur correspond effectivement à cet utilisateur ou à son groupe.
5. Après déconnexion ou changement d’appareil, l’attribution disparaît correctement.

Sans la nouvelle extension, les futures mises à jour peuvent manquer. Selon la conception de l’authentification, cela peut affecter l’attribution des utilisateurs, et donc les règles firewall ou web basées sur ceux-ci. Dans une école, cela peut rapidement devenir un problème de filtrage alors que le firewall, l’accès Internet et le Chromebook semblent tous « online » au premier regard.

STAS ne bloque plus par défaut pendant la vérification d’identité

Dans Sophos Transparent Authentication Suite, MR2 fait passer la valeur par défaut de Restrict client traffic during identity probe à No.

STAS associe des adresses IP aux utilisateurs détectés sur le contrôleur de domaine Windows. Le mécanisme est ancien, mais techniquement intéressant :

1. L’utilisateur ouvre une session sur le domaine Windows.
2. Le contrôleur de domaine écrit un Security Audit Event, généralement l’Event ID 4768 sur les versions récentes de Windows.
3. Le STAS Agent extrait le nom d’utilisateur et l’adresse IP de cet événement.
4. Par défaut, l’agent envoie ces informations au Collector via TCP 5566.
5. Le Collector signale au firewall les attributions réussies via UDP 6060.
6. Lorsque SFOS voit du trafic provenant d’une IP inconnue, il peut interroger le Collector sur le port 6677.
7. Le firewall complète l’appartenance aux groupes via le serveur AD configuré et applique les règles basées sur l’utilisateur.

Lorsqu’aucune attribution n’existe encore pour une IP, celle-ci passe en Learning Mode. Jusqu’ici, le trafic était par défaut suspendu ou rejeté pendant cette vérification. La durée par défaut documentée est de 120 secondes. Si le Collector ne répond pas, l’adresse IP peut ensuite être considérée comme non authentifiée pendant une heure ; les règles applicables au trafic non authentifié prennent alors effet.

C’est précisément là qu’existait un problème d’exploitation réel sous MR1. Sophos documente NC-181885 : avec Restrict client traffic during identity probe = Yes, des Identity Probes répétées pouvaient provoquer des interruptions intermittentes ou bloquer la mise à niveau MR1. MR2 est indiquée comme version corrective et passe simultanément la valeur par défaut à No.

Avec No, le trafic du client peut continuer pendant la vérification. Cela réduit les perturbations, mais modifie l’arbitrage :

• l’utilisateur subit moins d’interruptions ;
• le firewall peut ne pas encore disposer d’une identité confirmée pendant la vérification ;
• les règles basées sur l’utilisateur et la journalisation doivent donc être contrôlées précisément durant cette transition.

Il s’agit d’un arbitrage classique entre disponibilité et application stricte de l’identité. Avec Yes, une communication Collector défaillante peut bloquer le client. Avec No, du trafic peut circuler pendant la vérification avant que l’identité de l’utilisateur soit confirmée. Il faut tester dans son propre jeu de règles si ce trafic rencontre une règle réseau générale, une règle non authentifiée ou, ultérieurement, une règle utilisateur.

Les Release Notes indiquent que la valeur par défaut devient No. Elles ne disent pas clairement que MR2 écrase automatiquement toute valeur existante définie volontairement. Il faut donc contrôler la valeur effectivement configurée après la mise à niveau.

Je vérifierais également les points suivants :

• UDP 6060 et 6677 sont-ils ouverts entre le firewall et le Collector ?
• Le STAS Service fonctionne-t-il et est-il lié à la bonne NIC ?
• Plusieurs Collectors sont-ils configurés en groupes pour la Fault Tolerance ?
• Des objets Clientless User couvrent-ils les imprimantes, l’IoT et les autres appareils hors domaine ?
• Les utilisateurs apparaissent-ils correctement après la veille, le roaming, un changement DHCP et la déconnexion ?
• Les règles correspondent-elles, pendant le Learning Mode et l’état non authentifié, à ce que prévoit le design de sécurité ?

C’est particulièrement important dans les environnements où l’identité utilisateur n’est pas seulement utilisée pour le reporting, mais constitue une véritable condition d’accès.

Fin de Novell eDirectory avec SFOS 23.0

MR2 annonce pour la première fois à l’avance que Sophos mettra fin à la prise en charge des serveurs d’authentification Novell eDirectory dans SFOS 23.0.

eDirectory continue de fonctionner dans MR2. Il s’agit d’un avertissement et non d’une perte de fonction immédiate. Ceux qui l’utilisent encore en production doivent toutefois mettre ce délai à profit pour migrer vers un type d’authentification pris en charge avant d’installer SFOS 23.0.

Une telle migration ne concerne pas uniquement l’entrée serveur. Les groupes, règles firewall, Web Policies, accès VPN, portails utilisateur et rapports peuvent dépendre de l’ancienne source d’identité. Des Distinguished Names, imbrications de groupes, chemins de recherche et formats de noms d’utilisateur différents peuvent également faire qu’un test LDAP techniquement réussi est encore loin de garantir une migration fonctionnelle des policies.

À cela s’ajoute une limite plus ancienne : STAS ne prend pas en charge LDAP over SSL/TLS pour eDirectory. Le retrait complet d’eDirectory par Sophos dans SFOS 23.0 n’est donc pas totalement surprenant. L’architecture de remplacement doit néanmoins être prête à temps. Il faut la traiter comme un projet à part entière avec comptes de test, groupes reproduits en parallèle, références de règles documentées et plan de repli.

Let’s Encrypt : nouvelles chaînes et meilleure attribution

Let’s Encrypt fait progressivement évoluer son infrastructure de certificats vers de nouveaux certificats Root et Intermediate. MR2 ajoute la prise en charge de YE Root, YE1, YE2, YR Root, YR1 et YR2.

Cette hiérarchie dite Generation Y se compose de deux nouvelles Root CAs utilisant des types de clés différents :

• ISRG Root YE utilise ECDSA P-384 et constitue le chemin successeur de l’ancienne hiérarchie ECDSA.
• ISRG Root YR utilise RSA 4096 et forme le nouveau chemin racine RSA.
• YE1 et YE2 sont des Intermediates ECDSA P-384.
• YR1 et YR2 sont des Intermediates RSA 2048.

Les Roots sont cross-signés par les anciens ISRG Roots. Les nouvelles chaînes peuvent ainsi remonter à des Trust Anchors plus anciens et déjà largement diffusés pendant que les éditeurs de navigateurs et de systèmes d’exploitation ajoutent les nouvelles racines à leurs Trust Stores. Les Intermediates YE1, YE2, YR1 et YR2 sont devenus pertinents pour l’émission active en 2026.

Pour SFOS, il s’agit avant tout d’une adaptation de compatibilité. Le firewall doit connaître et traiter correctement les nouveaux émetteurs et chaînes afin que l’émission automatique, le renouvellement, l’utilisation WAF et la validation continuent de fonctionner avec la prochaine génération de l’infrastructure Let’s Encrypt. Sans chaîne de confiance actualisée, les opérations sur les certificats pourraient échouer alors même que le domaine, le port 80 et la validation HTTP-01 sont correctement configurés.

Un échec ACME de ce type est particulièrement désagréable à diagnostiquer : on cherche du côté du DNS, du DNAT, du port 80, de la règle WAF ou des Terms of Service alors que la véritable cause peut être une nouvelle chaîne CA.

SFOS continue d’utiliser HTTP-01 pour les demandes Let’s Encrypt. Le FQDN du domaine doit pointer vers l’adresse WAN publique choisie. Le firewall doit être joignable sur le port 80, et une règle DNAT concurrente sur la même adresse et le port 80 peut empêcher la validation. MR2 ne modifie pas ce principe ; elle étend la hiérarchie CA prise en charge.

Les notifications Let’s Encrypt par e-mail contiennent désormais le hostname et le numéro de série du firewall. Ce détail est très utile pour les MSP et les grands environnements : avec des dizaines de firewalls, un avertissement peut enfin être attribué plus rapidement au bon appareil, sans investigation à partir d’un message générique.

C’est une amélioration classique de qualité de vie : peu spectaculaire techniquement, mais utile au quotidien. Tout message généré par le système d’un firewall géré centralement devrait au minimum contenir le hostname, le numéro de série, le modèle et le firmware. Sophos avait déjà suivi cette voie pour les e-mails de sauvegarde ; Let’s Encrypt fait de même avec MR2.

Config Studio 2.6 : chaque nouvelle fonction expliquée

Sophos présente officiellement Config Studio 2.6 dans l’annonce MR2, bien qu’il reste un outil distinct fonctionnant dans le navigateur et non une nouvelle interface directement intégrée à SFOS. Pour ceux qui ne connaissent pas encore le principe, mon précédent article Sophos Firewall Config Studio V2 : bien plus qu’un viewer décrit tout le workflow d’export, Entities.xml, comparaison et édition.

Point important pour l’évaluation technique et la protection des données : Sophos affirme que le parsing, l’analyse et la génération des rapports s’effectuent localement dans le navigateur sur l’endpoint. La configuration chargée ne doit être transmise ni à Sophos ni à un autre serveur. C’est essentiel pour une configuration complète de firewall, car Entities.xml peut contenir des réseaux internes, objets, jeux de règles, définitions VPN, références de certificats et noms organisationnels.

Un traitement local n’est cependant pas automatiquement sans risque. Le navigateur charge toujours l’application depuis Internet. Les environnements très sensibles doivent donc s’interroger sur la version du code, le cache du navigateur, l’utilisation hors ligne, le durcissement de l’endpoint et le stockage sécurisé des exports. Un fichier Entities.xml ne doit pas se retrouver sans contrôle dans Downloads, des tickets ou une synchronisation cloud ordinaire.

Config Studio 2.6 couvre désormais cinq domaines de travail :

• Configuration Report avec Policy Test, analyse et recherche globale ;
• comparaison de deux configurations ou davantage ;
• éditeur visuel avec Bulk Editing et sortie XML, API ou curl ;
• migration depuis Sophos UTM, SonicWall, FortiGate et Palo Alto Networks ;
• compatibilité Backup Restore, Flexi Port, transceivers et modèles.

La version 2.6 étend plusieurs de ces domaines.

Fusionner des templates

Merge Templates permet de combiner des configurations de base avec des modèles spécifiques à un secteur. Un MSP pourrait par exemple fusionner une configuration technique de base pour les logs, DNS, accès administrateur et objets standard avec un template destiné aux cabinets médicaux, écoles ou succursales.

L’avantage réside dans la réutilisation : on ne recommence pas à zéro pour chaque firewall. Une baseline peut contenir les accès administrateur, NTP, DNS, Syslog, services standard et conventions de journalisation. Un deuxième template complète le tout avec les règles et objets propres au secteur.

La gestion des conflits reste le point critique :

• Que se passe-t-il si deux objets ont le même nom mais des valeurs différentes ?
• Les UUID, références et ordres de règles sont-ils résolus de manière cohérente ?
• Quelles références d’interfaces et de zones ne correspondent pas au modèle cible ?
• La fusion crée-t-elle des règles en double ou qui se chevauchent ?
• Un objet restrictif existant est-il remplacé par une valeur plus large du template ?

Après la fusion, Duplicate Analysis, Shadow Rule Analysis, Usage References et un Policy Test complet sont donc obligatoires. Une fusion techniquement réussie ne prouve pas que la policy obtenue est sûre.

Recherche globale améliorée

La recherche globale trouve plus rapidement les objets de configuration et permet d’y accéder directement. Dans un grand jeu de règles, c’est plus important qu’il n’y paraît. Un objet hôte peut être référencé dans des configurations firewall, NAT, TLS, web ou VPN. Passer d’un clic au bon emplacement évite de nombreuses ouvertures et de nombreux retours manuels.

Config Studio ne recherche pas seulement le nom visible de l’objet. Selon le type de données, les valeurs, chemins et éléments référencés sont également pertinents. Le saut direct vers le résultat est particulièrement précieux pour des noms génériques comme Server, LAN_Network ou des groupes d’hôtes hérités de l’histoire.

La recherche n’équivaut toutefois pas à Usage Reference. Search répond à la question : « Où se trouve cet objet ou cette valeur ? » Usage Reference répond à : « Quels autres éléments de configuration en dépendent ? » Une modification sûre exige les deux perspectives.

Cette fonction fait justement cruellement défaut dans l’interface même du firewall.

Rapports de configuration plus explicites

Pour les règles firewall, NAT et TLS, les rapports ne montrent plus uniquement le nom des références, mais aussi les valeurs et détails des objets utilisés. Au lieu de voir seulement Webserver-Gruppe, le reviewer peut identifier directement les hôtes ou réseaux correspondants.

Pour les audits, transmissions et revues à quatre yeux, c’est un progrès important. Une règle ne peut être correctement évaluée que si sa source, sa destination, ses services et ses objets associés sont visibles sans série de clics supplémentaire. Un nom d’objet peut sembler propre tout en contenant Any, un réseau trop large ou des entrées oubliées depuis longtemps.

Le rapport prend également en charge Policy Test et l’analyse. Policy Test détermine quelle règle ou route correspond aux valeurs source et destination définies. L’analyse recherche notamment le shadowing et les doublons. Comme SFOS évalue les règles firewall du haut vers le bas et s’arrête au premier match, leur ordre fait partie de la logique de sécurité et ne relève pas seulement de l’affichage.

Config Studio 2.6 : migration, comparaison et export

Analyses de migration avec taux de réussite

Config Studio présente les informations de migration et de conversion, y compris la proportion reprise avec succès. Un pourcentage constitue un indicateur rapide, mais pas un procès-verbal de recette.

Sophos distingue plusieurs états lors des migrations depuis des produits tiers :

• Supported : migration automatique sans changement de contenu ;
• Partial : migration avec des lacunes à compléter ;
• Manual : recréation manuelle requise sur Sophos Firewall ;
• Not supported : élément non migré ;
• Action required : décision concrète nécessaire avant l’export.

Si 95 % d’une configuration est convertie, les 5 % restants peuvent justement concerner des certificats, mots de passe, VPN, NAT ou routages particuliers. L’intérêt pratique ne réside donc pas seulement dans le pourcentage vert, mais dans la liste des éléments non repris, partiellement repris ou résolus automatiquement.

Les différences de logique entre constructeurs sont réelles. Les règles FortiGate peuvent être davantage liées aux interfaces, alors que SFOS travaille avec des zones. Palo Alto utilise encore d’autres modèles d’objets, de zones et de policies. Config Studio peut convertir la syntaxe et de nombreuses structures, mais ne peut pas prouver automatiquement que le modèle de sécurité est resté sémantiquement identique.

Multi-File Configuration Diff

La comparaison classique suivait surtout un modèle avant/après. Multi-File Diff permet de charger deux états de configuration ou davantage et de les comparer sur plusieurs dates. Config Studio classe les fichiers selon leur date de modification et présente au niveau des champs ce qui a été ajouté, supprimé ou modifié.

Les vues Side-by-Side, Unified et Semantic sont disponibles. La comparaison sémantique est particulièrement intéressante, car un simple diff texte XML est vite pollué par l’ordre, les IDs ou le formatage. Un diff au niveau Entity et Field tente plutôt de mettre en évidence le véritable changement de configuration.

C’est utile pour reconstituer un changement et diagnostiquer un problème. Lorsqu’une anomalie n’apparaît pas directement après une seule fenêtre de maintenance, plusieurs exports permettent de déterminer à quel moment une règle, un objet ou un paramètre a réellement changé.

Mais il faut disposer d’états de configuration sauvegardés régulièrement, d’horodatages corrects et d’une gestion propre de ces exports sensibles. La date de modification d’un fichier téléchargé ou copié ne correspond pas nécessairement à la date du changement sur le firewall. Pour une chronologie fiable, il faut documenter ensemble le nom du fichier, l’heure d’export, le hostname du firewall, le numéro de série, le firmware et le ticket de changement associé.

Sans discipline de version, même un Multi-File Diff ne peut inventer un historique. Et c’est précisément pourquoi cette fonction serait beaucoup plus forte directement dans Central, avec un historique d’audit immuable, qu’au travers d’un upload manuel.

Référence Backup Restore, Flexi Port et vitesses

Config Studio peut vérifier la compatibilité Backup Restore et la disposition des ports de différents modèles Sophos Firewall. Il présente aussi les modules Flexi Port ainsi que les vitesses et standards de ports pris en charge, jusqu’à 25, 40 ou 100 Gbit/s.

Cette fonction facilite les migrations matérielles. Avant de passer d’un modèle à l’autre, on peut mieux déterminer :

• si une sauvegarde peut en principe être restaurée ;
• combien de ports physiques sont disponibles ;
• si les modules Flexi Port existants sont compatibles ;
• quelles vitesses et normes d’interfaces sont prises en charge.

Elle ne remplace pas une conception de migration. Les LAG, VLAN, bridges, la HA, les noms de ports, les zones et l’affectation concrète des interfaces doivent toujours être planifiés et contrôlés après la restauration.

La compatibilité Backup Restore élargie s’applique aux cibles à partir de SFOS 20.0 MR2. Selon la version source et la plateforme cible, le Backup Restore Assistant apparaît pour mapper les interfaces. Les ports physiques peuvent être réaffectés, tandis que les VLAN et Aliases suivent leur interface parente et que les LAG ou bridges sont reconstruits à partir des ports associés.

Pour les Flexi Ports, la question « le module entre-t-il physiquement ? » ne suffit pas. Il faut vérifier ensemble la génération du modèle, le facteur de forme, le transceiver, la norme prise en charge, la vitesse de port, le comportement Breakout et la version SFOS disponible. Config Studio accélère cette référence, mais ne remplace pas les tests de lien et de failover après la migration.

Dark Mode

Les Release Notes mentionnent également un Dark Mode. Il s’agit d’une petite amélioration ergonomique et non d’une fonction firewall. Elle est presque symbolique : même le Dark Mode arrive d’abord dans Config Studio, tandis que la console WebAdmin locale ne progresse que très lentement depuis des années sur les plans visuel et ergonomique.

Ce que l’éditeur peut produire techniquement

L’éditeur peut importer ou créer des configurations, effectuer des Bulk Changes et afficher le résultat avant export sous forme d’Import XML, d’API Request ou de curl. Il est aussi possible de télécharger un fichier XML ou une archive TAR, puis de l’importer dans SFOS via Backup & firmware > Import export.

C’est puissant, mais cela accroît aussi la responsabilité de l’administrateur. Une API Request générée n’est pas automatiquement idempotente. Un import réussi ne confirme pas que le Rule Order, les usages d’objets, NAT, VPN et Security Policies sont fonctionnellement corrects. Avant une reprise en production, la sortie doit être jointe à un ticket de changement, le diff doit être revu et le firewall résultant doit subir un véritable test du chemin de données.

Plus de 50 correctifs : la véritable raison de passer à MR2

Sophos annonce plus de 50 problèmes de fiabilité, stabilité et sécurité corrigés. Tous ne concernent pas chaque installation, mais plusieurs sont sérieux sur le plan opérationnel.

À mes yeux, les groupes suivants sont particulièrement importants :

HA et Failsafe ne sont pas des sujets secondaires

Plusieurs correctifs ne concernent pas seulement une fonction, mais la disponibilité même de l’appliance :

• NC-181331 : une partition de configuration pleine pouvait faire passer le firewall en Failsafe Mode.
• NC-180110 : le Logging Daemon pouvait ne pas démarrer sur le Primary, faisant passer l’équipement HA en Failsafe.
• NC-177441 : après une mise à niveau vers v22 GA, l’ancien équipement Primary pouvait tomber en Failsafe en raison d’un problème Postgres.
• NC-178906 : le RED Server Service pouvait ne pas démarrer et déclencher un état Failsafe.
• NC-177467 : l’équipement Auxiliary ne démarrait pas correctement lors d’un grand nombre de tentatives SSH simultanées non authentifiées.

Les causes diffèrent, mais l’effet opérationnel est identique : le firewall perd des services, passe en mode de protection ou le partenaire HA n’est pas disponible comme le laissait croire auparavant l’affichage vert du cluster. Après la mise à niveau, HA status: Active-Passive ne suffit donc pas. Il faut tester la synchronisation, l’état des services, le failover et le trafic réel.

Les correctifs IPsec touchent profondément le chemin de données

Les correctifs VPN ne sont pas non plus cosmétiques :

• NC-180433 : du trafic multicast traversant un tunnel VPN pouvait provoquer des crashs répétés du firewall.
• NC-171719 : le trafic ESP rencontrait un routage incorrect dans une configuration SD-WAN.
• NC-180520 : avec IPsec Acceleration actif, une gateway XFRM restait indisponible après la mise à niveau lorsqu’un tunnel était lié à une Alias IP et que l’ESP arrivait par un autre port WAN.
• NC-176855 : le débit IPv6 sur IPsec route-based était dégradé.
• NC-178121 : le drag-and-drop pouvait déplacer des connexions Site-to-Site IPsec à la mauvaise position au sein d’un Failover Group.

Pour ces erreurs, un tunnel affiché Active ne prouve rien. Sur les VPN route-based, il faut tester séparément l’interface XFRM, la Routing Table, la décision SD-WAN, le chemin ESP, la MTU, IPv4 et IPv6. Dans les Failover Groups, il faut aussi vérifier que l’ordre et le basculement correspondent encore à la priorité documentée après la mise à niveau.

Les logs et le reporting pouvaient eux-mêmes provoquer des pannes

NC-155252 est un correctif particulièrement désagréable : une charge Disk I/O élevée dans le reporting provoquait des pics CPU et des coupures Internet intermittentes pouvant durer jusqu’à une minute. C’est exactement le type d’erreur où un sous-système d’analyse affecte le chemin de données de production.

NC-178745 décrit le redémarrage automatique d’un équipement HA en raison d’un Out of Memory dans le Logging Framework. NC-181520 améliore les performances du Log Viewer. Ensemble, ces points montrent que les logs dans SFOS ne doivent pas être considérés comme une fonction secondaire anodine. Storage, base de données, Garner, Log Viewer et Central Reporting sont plus étroitement liés au fonctionnement du système que l’interface ne le laisse penser.

Après MR2, je ne vérifierais donc pas seulement l’apparition de nouvelles lignes de log. Les points suivants comptent :

• Les événements Firewall, IPS, WAF, Authentication et VPN arrivent-ils tous ?
• La chronologie reste-t-elle continue ?
• Le collecteur Syslog externe reçoit-il toujours les données ?
• CPU, RAM et Disk I/O restent-ils stables sous une charge normale ?
• Les rapports sont-ils générés sans affecter le chemin de données ?

Les correctifs Central montrent les limites du « Single Pane of Glass »

Avec NC-181175, des Group Policies issues de Sophos Central pouvaient rester en état Pending. NC-180513 concernait l’import de configuration depuis Central View après la mise à niveau vers MR1. NC-181904 empêchait la libération d’e-mails en quarantaine via Central.

Leur point commun : l’interface centrale peut accepter ou afficher une demande sans que l’action souhaitée ait réellement été exécutée sur le firewall. Après un Group Policy Push, il faut donc vérifier sur l’équipement cible si l’objet, la règle, l’ordre et l’horodatage sont réellement arrivés. La fermeture réussie d’une boîte de dialogue dans Central ne constitue pas une preuve technique de commit.

Cette liste montre aussi pourquoi je n’évalue pas les Maintenance Releases uniquement à la longueur de leur liste de fonctions. Si le logging, Postgres, SD-WAN ou le multicast fait passer un firewall en Failsafe ou le redémarre, un correctif correspondant vaut davantage qu’une nouvelle tuile de dashboard.

La quantité de corrections n’est cependant pas automatiquement un label de qualité. Elle montre que des problèmes ont été résolus, mais aussi combien d’erreurs sérieuses étaient présentes dans les builds précédentes. L’exploitant d’un environnement HA, VPN ou WAF critique ne doit donc ni rester éternellement sur une ancienne build par peur, ni déployer MR2 partout sans test dès le premier jour.

Ce que les administrateurs doivent vérifier avant la mise à niveau

Sophos recommande d’installer rapidement MR2 pour ses corrections de sécurité, de stabilité et de performances. C’est compréhensible. Mais, en production, rapidement ne signifie pas aveuglément.

Le tagging VLAN hérité sur les bridges bloque MR2

MR2 introduit un blocage strict de la mise à niveau lorsqu’un ancien tagging VLAN configuré en CLI est présent sur des Bridge Interfaces. Si la configuration utilise encore le mécanisme hérité system vlan-tag, le firewall ne peut pas passer à SFOS 22.0 MR2 ou version ultérieure.

Ces configurations doivent être nettoyées ou migrées avant la mise à niveau. De plus, les sauvegardes contenant cette configuration héritée ne peuvent pas être restaurées sur SFOS 22.0 GA ou version ultérieure. C’est particulièrement important pour les installations anciennes qui ont été adaptées à un moment donné via la CLI.

Les obstacles v22 précédents restent valables

Les prérequis connus de GA et MR1 demeurent :

• Legacy Remote Access IPsec doit être supprimé ou migré avant MR1 ou MR2.
• SFOS 22 exige davantage d’espace disque ; certaines appliances desktop, virtuelles ou logicielles doivent être adaptées au préalable.
• Le comportement des VPN IPsec policy-based a changé depuis GA et doit être vérifié pour les tunnels concernés.
• Le matériel XG et SG n’est pas pris en charge par SFOS 22.
• Les anciens RED 15, RED 15w et RED 50 ne sont plus pris en charge depuis v21.5.

Ma procédure de mise à niveau

Pour les firewalls de production, je procéderais au minimum ainsi :

1. Créer une sauvegarde actuelle et la conserver à l’extérieur.
2. Vérifier le support, les licences et le chemin de mise à niveau approuvé.
3. Exclure Legacy Remote Access IPsec et le tagging VLAN CLI sur les bridges.
4. Contrôler les avertissements Disk Space dans le Control Center.
5. En HA, vérifier l’état des deux nœuds, la synchronisation et le firmware disponible.
6. Documenter les VPN critiques, publications WAF, Mail Flows, règles SD-WAN et l’authentification.
7. Installer d’abord MR2 sur une appliance de test représentative ou moins critique.
8. Après la mise à niveau, tester les logs, le niveau des patterns, la HA, le routage, le DNS, le VPN, WebAdmin, le reporting et les Policy Pushes centraux.

Avec une version qui contient autant de correctifs, un test propre avant/après est particulièrement précieux. Sans cela, on sait seulement que le firmware a changé, mais pas si ses chemins de données critiques fonctionnent toujours exactement comme prévu.

Depuis la version 20, SFOS dispose d’un Firmware Rollback automatique si la migration de configuration échoue pendant la mise à niveau. Cela réduit le risque de démarrer avec une Factory Configuration au lieu de la configuration de production. Cette protection ne s’applique toutefois pas à tous les scénarios, notamment en cas de chemin de mise à niveau non pris en charge ou dans certains workflows du Setup Assistant. Après un rollback automatique, migration.log et migrationhash.log doivent être analysés.

Un rollback automatique ne remplace ni une sauvegarde externe, ni le Secure Storage Master Key, ni un accès console disponible. Il protège principalement contre l’échec de la migration de configuration. Il ne prouve pas que WAF, VPN, HA ou le reporting fonctionnent correctement après une mise à niveau techniquement réussie.

Pour mon test MR2 direct, je mesurerai ou provoquerai donc les mêmes événements avant et après la mise à niveau :

• redémarrage et démarrage complet des services ;
• connexion WebAdmin et temps de réponse des grandes listes de règles ;
• flux de logs local et externe ;
• trafic IPsec, Rekey et Failover ;
• Central Policy Push avec contrôle sur le firewall ;
• mise à jour des patterns IPS et Application Control ;
• nouvelle authentification STAS et comportement d’une Client IP encore inconnue ;
• synchronisation HA et changement de rôle contrôlé si le système de test est un cluster.

Ce n’est qu’ensuite que je pourrai dire si MR2 est réellement meilleure dans mon environnement. Une installation réussie et une page Control Center verte ne suffisent pas.

Ce que disent les premiers retours de la communauté

Le thread de feedback a été ouvert le jour même de la publication de MR2. Au moment de cette analyse, il n’a que quelques heures. On ne peut donc conclure ni que MR2 est stable, ni qu’elle pose problème.

Deux échanges méritent néanmoins d’être mentionnés :

• L’exploitant d’une XGS 5500 en HA Active-Passive s’interroge expressément sur la profondeur des tests, car NC-177467 l’a affecté pendant des mois sous MR1. Sophos répertorie ce bug comme corrigé dans MR2. Il concernait un équipement Auxiliary qui ne démarrait pas en présence d’un très grand nombre de tentatives SSH simultanées non authentifiées.
• Pour les signatures PQC, un collaborateur Sophos précise qu’elles sont volontairement désactivées. Comme PQC-TLS progresse dans les navigateurs et applications, leur activation immédiate pourrait générer énormément d’alertes. La recommandation consiste d’abord à utiliser Allow avec journalisation, puis seulement plus tard, si cela s’avère vraiment nécessaire, une action bloquante.

C’est une phase initiale raisonnable pour une nouvelle version : des tests concrets, des Case IDs et des retours compréhensibles plutôt que des affirmations générales du type « ça marche » ou « c’est cassé ». Je continuerais à suivre le thread pendant les premiers jours et semaines, surtout pour la HA, IPsec, WAF, STAS et le reporting.

Config Studio devient le magasin de pièces détachées d’une vieille interface

Passons au sujet qui fâche.

Config Studio 2.6 est un bon outil. Fusionner des templates, rechercher des objets, résoudre les références dans les rapports, comparer plusieurs états de configuration et préparer des migrations matérielles sont de véritables fonctions d’administration. Je ne reproche pas à Sophos de les développer, mais l’endroit où elles sont développées.

Sophos cite désormais Config Studio directement dans les Firewall Release Notes et l’annonce officielle de MR2. L’outil ressemble donc de plus en plus à une réponse stratégique à des problèmes qui devraient en réalité être résolus dans WebAdmin ou Sophos Central.

Au quotidien, l’interface locale du firewall reste vieillissante et souvent lente avec les grandes configurations. Les modifications en masse sont insuffisantes. Les usages d’objets, une véritable recherche globale, des diffs propres, le clonage NAT, les conflits de règles et un workflow de changement moderne manquent précisément là où les administrateurs travaillent chaque jour. Sophos Central ne comble qu’une partie de ce vide.

Le problème ne se limite pas au design. À mes yeux, une interface de firewall moderne nécessite un processus de changement fiable :

• Candidate Configuration au lieu de modifications individuelles immédiatement distribuées ;
• diffs avant/après complets avant le commit ;
• contrôle des dépendances entre objets, règles, NAT, VPN et TLS ;
• commit atomique ou état de transaction clair ;
• rollback validé vers le dernier état connu ;
• attribution réelle de l’utilisateur, du temps et de la source dans l’Audit Trail ;
• Bulk Operations avec aperçu et contrôle des conflits ;
• sortie API cohérente pour des changements reproductibles.

Config Studio reproduit certaines de ces fonctions hors du système. Il analyse un export, génère du XML ou des API Requests et facilite les diffs. Mais un fossé demeure entre cette vue hors ligne et l’état d’exécution actif du firewall. Les sessions, le routage dynamique, l’état HA, les patterns actuels, l’état des certificats et la configuration effectivement chargée ne sont pas équivalents à un fichier Entities.xml ouvert localement.

Il serait excessif de déduire d’une annonce de version que Sophos ne modernisera plus jamais fondamentalement l’interface SFOS. Aucune déclaration ne le confirme. Le signal reste néanmoins mauvais : les progrès les plus visibles en matière d’ergonomie, de recherche, de comparaison et de travail de configuration apparaissent encore hors des interfaces de gestion elles-mêmes.

Le workflow reste donc fragmenté :

1. Exporter la configuration du firewall.
2. Décompresser l’archive et chercher Entities.xml.
3. Charger le fichier dans un outil distinct dans le navigateur.
4. L’y analyser, le comparer ou le modifier.
5. Réexporter le résultat et le réinjecter au moyen de XML, de l’API ou de curl.

C’est acceptable pour un audit. Pour une administration moderne, sûre et traçable, c’est un détour. Il est particulièrement irritant que Config Studio ne traite pas seulement un cas spécialisé : il reçoit précisément les Low-Hanging Fruits que les administrateurs Sophos attendent depuis des années.

Et c’est ici que ma critique devient plus sévère : si Sophos présente désormais Config Studio comme un thème important dans les Firewall Release Notes ordinaires, l’outil externe ne peut plus être réduit à un petit utilitaire complémentaire. Sophos en fait visiblement un élément de sa stratégie d’administration. La pression augmente donc pour expliquer enfin quelles fonctions seront intégrées à long terme à WebAdmin ou Central et lesquelles resteront durablement dans l’outil du navigateur.

Sans cette roadmap, l’impression qui se dégage est que l’interface ancienne, lente et de moins en moins conviviale dans les grandes configurations restera fondamentalement inchangée, les administrateurs étant simplement invités à utiliser Config Studio pour les workflows modernes. Ce n’est pas un plan confirmé par Sophos, mais c’est la direction que le produit communique actuellement.

Pourquoi UniFi profite d’un boulevard

UniFi ne remplace pas entièrement tous les Sophos Firewall. Selon la licence et l’architecture, Sophos fournit des fonctions de sécurité plus poussées, IPS, Web Protection, WAF, l’intégration Endpoint, les connexions MDR/XDR et des fonctions Enterprise classiques. Une comparaison honnête ne doit pas effacer ces différences.

Mais, dans la qualité perçue du produit, l’ergonomie gagne chaque jour.

Ubiquiti investit visiblement dans le design, les applications mobiles, une navigation cohérente, la topologie, l’intégration simple des appareils et une interface compréhensible même sans des années d’expérience du produit. Toutes les fonctions UniFi ne sont pas techniquement plus profondes. Le produit paraît toutefois plus moderne, ce qui influence les décisions d’achat davantage que les constructeurs de firewalls classiques ne veulent bien l’admettre.

Lorsqu’une petite équipe IT choisit entre deux solutions, elle ne regarde pas uniquement les fiches techniques IPS. Elle demande aussi :

• En combien de temps puis-je trouver un appareil, une règle ou un client ?
• Puis-je contrôler utilement l’environnement depuis un smartphone ?
• Puis-je comprendre les avertissements et dépendances sans connaissances spécialisées ?
• Combien de clics faut-il pour une modification quotidienne ?
• Le produit ressemble-t-il à une plateforme cohérente ou à plusieurs outils juxtaposés ?

C’est précisément là que Sophos facilite inutilement la tâche à des constructeurs comme Ubiquiti. Sophos Firewall peut offrir davantage sur le plan de la sécurité et rester la solution la plus raisonnable pour de nombreux environnements PME. Mais si les administrateurs doivent ouvrir un Config Studio distinct pour la recherche moderne, les diffs, templates et modifications en masse, tandis que l’interface principale reste ancienne et poussive, Sophos perd la confiance au niveau le plus visible.

Une bonne sécurité n’a pas seulement besoin d’un moteur puissant. Elle exige une interface dans laquelle les humains comprennent les règles, détectent les erreurs et réalisent les changements en toute sécurité. L’ergonomie n’est donc pas un supplément cosmétique, mais une composante de la sécurité opérationnelle.

Conclusion : installer MR2, mais le problème produit demeure

SFOS 22.0 MR2 n’est pas une grande Feature Release. C’est une Maintenance Release importante avec des ajouts pertinents.

Le contrôle PQC arrive au bon moment, mais doit d’abord être déployé en mode observation. La meilleure détection des applications d’IA générative améliore la visibilité et les policies, sans remplacer une stratégie DLP ou de gouvernance de l’IA. Les administrateurs de Chromebooks doivent déployer activement la nouvelle extension Manifest V3. STAS devient moins susceptible de provoquer des perturbations, mais exige un contrôle conscient des règles d’identité. Let’s Encrypt est préparé pour les prochaines chaînes de certificats. Enfin, les nombreux correctifs traitent plusieurs problèmes susceptibles d’avoir provoqué de véritables pannes en production.

J’installerai MR2 directement après la sauvegarde et le preflight, puis je testerai précisément ces chemins de données. Les exploitants affectés par les problèmes HA, VPN, reporting, Central ou Failsafe cités ont de bonnes raisons d’effectuer la mise à jour. Le jour de la publication, il est encore impossible de dire sérieusement si la build 546 sera réellement plus stable ou si elle introduira de nouvelles régressions.

Ma critique reste pourtant claire : Config Studio 2.6 est utile, mais sa place importante dans la version du firewall renforce l’impression que Sophos déporte l’administration moderne vers un outil secondaire. Il ne s’agit pas de l’abandon confirmé d’une nouvelle interface SFOS, mais c’est un signal stratégique préoccupant.

Sophos dispose d’une base de firewall solide. Le constructeur doit enfin offrir aux administrateurs une expérience de gestion à la hauteur de cette base technique. Sinon, les plateformes plus modernes ne gagneront pas forcément grâce à une meilleure sécurité, mais parce qu’elles prennent plus au sérieux la personne devant l’écran.

À la prochaine,
Joe

FAQ