Sophos Firewall v23 : progrès, limites et questions ouvertes

Je teste Sophos Firewall v23 dans mon laboratoire domestique depuis presque deux semaines. Mon premier bilan est mitigé : j’aime la nouvelle vue des règles et l’API REST me semble une bonne approche. Mais l’interface évoque toujours un produit dont les sections ont été développées à des époques différentes. Une nouvelle table ne modernise pas toute l’administration.

Cela compte davantage pour moi que le nombre de nouveautés. Je veux gérer les règles clairement, automatiser les tâches récurrentes et changer de section sans retrouver chaque fois une autre logique. v23 progresse, mais laisse des attentes fondamentales sans réponse. Voici mon premier retour d’expérience, complété par une analyse technique des principales évolutions.

Sophos Firewall v23 est actuellement en programme d’accès anticipé (EAP). D’après le rythme des années précédentes, j’attends la version finale en décembre 2026. Je teste le firmware depuis presque deux semaines dans mon laboratoire, sans l’avoir déployé en production. Mes impressions d’utilisation sont personnelles ; les chiffres de performances HA et WAF viennent de Sophos.

Gestion des règles : un meilleur filtre ne remplace pas toute vue par groupes

La nouvelle vue des règles fait partie des changements que j’apprécie. La table continue, avec colonnes personnalisables et figées, recherche et filtres, va dans le bon sens. Afficher côte à côte destinations, services et profils de protection est plus pertinent que d’ouvrir plusieurs règles pour chaque comparaison. L’identité du matériel et l’état HA toujours visibles aident aussi à garder le contexte.

Je comprends néanmoins le débat sur les groupes. Les premiers retours reprochent à la nouvelle vue de ne pas reproduire les groupes repliables habituels. Avec beaucoup de règles, une longue table reste difficile à parcourir malgré les filtres. Il s’agit d’une administration sûre, pas seulement de goût.

L’explication distincte de Sophos sur la gestion des règles précise que groupes et ordre restent intacts, l’appartenance apparaît dans une colonne et les deux vues sont actuellement sélectionnables. Les groupes ne sont pas supprimés. Leur présentation change. L’organisation par étiquettes discutée est une évolution possible, pas une fonction promise pour ce build.

J’aime cette vue, tout en comprenant les administrateurs de très grands ensembles. Avec des milliers de règles, filtres et présentation doivent rendre l’ordre effectif intelligible. Un groupe n’est pas une frontière de sécurité indépendante de l’ordre global.

Après presque deux semaines, l’incohérence de l’interface continue de me gêner. Design et fonctions ne correspondent pas partout. Le clonage n’est pas disponible dans toutes les sections selon la même logique, et l’adaptation aux tailles d’écran est inégale. Cela ressort particulièrement lorsqu’on change de section.

J’attends que des tâches comparables fonctionnent de manière comparable. Nettoyer les règles ou créer plusieurs configurations similaires exige une interaction cohérente. Une vue réussie rend les différences ailleurs plus visibles. Je souhaite une amélioration qui dépasse les frontières entre sections.

HTTP/2 pour WebAdmin est bienvenu, mais ne résout pas cela. Il peut améliorer la livraison des ressources, surtout avec une forte latence. Il ne change ni la logique d’utilisation ni automatiquement la durée des modifications. Ce retour ne fournit pas de mesure contrôlée avant/après.

API REST : le progrès réside dans un processus vérifiable

L’API REST est pour moi l’une des approches les plus utiles de v23. Toutes les tâches récurrentes ne doivent pas se faire manuellement dans une interface. Clés API, OpenAPI 3.0 et guide intégré offrent une base utile pour ses propres outils. Clés, expiration et hôtes IP autorisés se gèrent sous Administration > API access.

L’intérêt réside dans les processus maîtrisés : lire l’état existant, identifier une différence précise, modifier une valeur, puis relire le résultat enregistré. Cela pourrait faciliter le suivi des tâches entre sites. C’est un usage pertinent, pas un déploiement multisite que j’aurais déjà démontré.

Une API seule ne rend pas l’automatisation fiable. Un site inaccessible doit apparaître comme échec. Les relances ne doivent pas dupliquer les objets et les échecs partiels exigent des journaux. C’est ainsi que j’évalue une intégration.

Les clés appartiennent à un hôte d’automatisation maîtrisé, avec durée limitée et accès réseau restreint. Le guide interactif peut envoyer de vraies requêtes. Ses exemples d’écriture modifient réellement la configuration et nécessitent la même vérification que l’interface.

La couverture complète reste une question ouverte. L’automatisation XML ne se remplace que si l’OpenAPI du build décrit toutes les opérations nécessaires. Sophos associant encore explicitement les modifications WAF à l’API XML, il faut regarder de près. Mon bilan : bonne direction, avec des détails décisifs de couverture, gestion des erreurs et permissions.

La WAF devient plus utile, mais sa capacité reste limitée

La Web Application Firewall reçoit des actions par entrée de chemin du site. Cela aide les applications publiées et comble partiellement un écart avec SG/UTM9. Les quatre actions ont des effets de sécurité différents :

Une redirection change la destination du client ; ce n’est pas un basculement interne du backend. Une exception WebSocket n’ajoute aucune protection. Pour un portail protégé avec un canal WebSocket, il faut décider où se fait chaque inspection. Une connexion fonctionnelle n’en prouve pas l’inspection.

Une entrée de route peut regrouper 128 chemins. La limite est de 100 règles WAF par défaut, extensible à 200. Selon le guide, les règles existantes migrent avec Protect par défaut. L’interface et l’API XML sont explicitement prises en charge. Cela ne garantit pas chaque opération WAF dans la nouvelle API REST.

L’autre changement majeur est Apache Event MPM. Sophos annonce une meilleure utilisation des workers et une meilleure résistance aux requêtes concurrentes. Les quelque 800 requêtes parallèles de l’annonce concernent une saturation possible de l’ancienne architecture, pas une limite universelle ni un nouveau débit garanti.

Les actions par chemin sont un progrès concret. Je distingue les promesses de performances : une meilleure file d’attente peut encore rendre une application inutilisable par sa lenteur. Temps de réponse, erreurs et latence du backend comptent plus que les connexions acceptées. Je ne fournis pas de benchmark WAF sous charge comparable. Plus de règles ne transforme pas l’appareil en modèle proportionnellement plus puissant.

HTTP/2 pour WebAdmin ne doit pas être confondu avec les protocoles WAF. Sur Reddit, HTTP/2 pour la WAF reste une demande future ; une réponse exprime un intérêt sans engagement. Je n’en fais ni une fonction v23 ni une promesse HTTP/3.

Haute disponibilité : 300 ms ne signifie pas des applications sans interruption

Les changements HA m’intéressent particulièrement. Sophos réduit la fenêtre de détection de panne du pair de quatre secondes à 300 millisecondes. D’où son chiffre d’une détection environ 13 fois plus rapide.

Ce chiffre décrit la détection. Il ne garantit pas qu’un appel, VPN ou application fonctionne normalement après 300 ms. Reprise par l’autre nœud, acheminement par les voisins et sessions existantes comptent aussi. Un ping représente mal l’ensemble.

La surveillance inclut du matériel comme le SSD. Un nœud peut répondre sur le lien HA alors que son stockage pose problème. Utiliser la santé matérielle comme critère est pertinent. Continuer sur un nœud sain ne remplace ni l’enquête ni le remplacement du matériel.

Le traitement prioritaire des heartbeats sur une voie séparée du trafic est tout aussi important. La priorité s’adapte à la charge selon Sophos, pour éviter d’interpréter des messages retardés comme une panne. Le guide annonce beaucoup moins de heartbeats manqués et de basculements inattendus, pas une immunité absolue.

Ces évolutions d’architecture me semblent sensées. Détecter plus vite sert peu si le cluster bascule inutilement sous charge. L’acceptation en production dépend des deux. Mes impressions au laboratoire ne prouvent ni une interruption HA mesurée ni la stabilité sous charge productive.

DNS et correctifs : deux formes de confiance

DNS over HTTPS chiffre le transport vers le résolveur. DNSSEC valide la chaîne de signatures des données signées. Ils se complètent : DoH seul n’authentifie pas la réponse, DNSSEC ne cache pas la requête. Le résolveur la voit toujours et toutes les zones ne sont pas signées.

Sophos décrit DoH vers Sophos ou un fournisseur générique et une activation simplifiée de DNS Protection. Tous les clients n’empruntent pas automatiquement le chemin prévu. Navigateurs avec leur propre DoH, résolveurs internes et espaces privés font partie du design. Je veux une résolution interne/externe correcte et des décisions compréhensibles de filtrage et validation.

La vue des hotfixes est moins spectaculaire, mais utile. Backup and Firmware affiche les correctifs appliqués avec CVE, description, date, gravité et lien d’avis. Le guide cite aussi Log Viewer, notifications par courriel et Central Firewall Reporting.

Le numéro de firmware ne décrit donc pas tous les correctifs. Une entrée peut prouver une correction précise, pas la disparition de toute vulnérabilité ni l’absence de compromission antérieure.

Les calendriers récurrents de Sophos Fusion ajoutent déploiements progressifs et exceptions individuelles. Les versions majeures peuvent être incluses. Je préfère tester un groupe, vérifier les fonctions critiques puis passer au suivant. Automatiser réduit le travail, pas le besoin de restauration.

DHCP, mDNS et routage méritent leurs propres tests

DHCP passe au nouveau plan de contrôle. Sophos décrit meilleure gestion des baux, davantage de réservations, filtrage avant le service contre les floods et nouveaux réglages dans l’interface. Ce n’est pas cosmétique. Baux, renouvellements, réservations et options particulières exigent attention. Ouvrir une page web ne prouve pas que PXE ou un appareil rarement redémarré reçoit les bons paramètres.

Le réflecteur mDNS découvre les services entre VLAN ou sous-réseaux sélectionnés, en IPv4 et IPv6. Interfaces et services sont sélectionnables. Il n’autorise pas automatiquement la connexion de données suivante. Une imprimante peut être visible sans que le travail passe faute de règle. Un réseau invité ne doit pas découvrir l’interne parce que tout refléter est facile. Il faut aussi des tests négatifs.

Sophos met à jour FRR et ajoute une console unifiée. BFD pour BGP et routes statiques est explicitement expérimental sur les installations autonomes. Il détecte les pannes de chemins d’acheminement, pas la même chose que le heartbeat HA. Je n’en fais pas encore une dépendance de production.

IPv6 IPoE, tunnels 4in6 dont IPIP/DS-Lite et DDNS adapté au VNE élargissent les connexions, notamment Xpass au Japon. Améliorations des extrémités et MTU/MSS servent si le fournisseur exige ce modèle ; elles ne règlent pas tous les problèmes IPv6. Sur IONOS Cloud, l’image officielle se déploie par Bring Your Own Image, sans entrée Marketplace et avec cycle de vie manuel.

Identité : le firmware n’apporte pas tous les prérequis

L’extension Entra ID concerne Synchronized User ID avec Sophos Endpoint. Ce n’est pas un autre nom du login au portail. Le guide décrit AD local et Entra hybrides, mappage UPN et sAMAccountName, avec support Windows depuis Endpoint 2025.1. Entra seul ne fournit pas cette identification. Version, licence et SSO doivent correspondre.

Google Workspace est décrit comme IdP OpenID Connect pour Captive Portal, VPN Portal, Sophos Connect et WebAdmin, avec MFA imposée par l’IdP. Un seul IdP est indiqué pour un ensemble de services. Authentification et autorisation restent distinctes : un compte Google valide ne doit pas obtenir des droits administratifs accidentellement.

Le QR d’inscription MFA peut arriver par courriel. C’est le défaut des nouveaux déploiements ; existants et migrés gardent le portail. Les codes inutilisés expirent après 24 heures. Ils contiennent le secret de l’authentificateur : boîte et réinscription exigent protection. L’envoi par courriel ne vérifie pas seul une identité.

Pour les serveurs partagés, SATC avec XDR Sensor fonctionne aux côtés d’une protection Endpoint ou AV existante, pour des règles par utilisateur malgré une IP commune. OS, licence et combinaison avec les tiers nécessitent une vérification préalable.

L’extension Chromebook utilise Manifest V3 et vise toutes les versions SFOS prises en charge. Ce n’est donc pas une raison exclusive de passer à v23. Sur les appareils partagés, je veux surtout que le mappage cesse après déconnexion ou changement d’utilisateur.

IA et NDR : la décision doit rester visible

En phase un, Firewall Assistant dans Sophos Fusion se concentre sur les règles. Il lit la configuration et répond. Son exception délibérée est de créer une règle désactivée, en dernière position. L’administrateur vérifie et active. Selon le guide, il accède aux mêmes données que cet administrateur via Fusion SSO.

J’apprécie cette limite. Un brouillon exige toujours de vérifier objets, services, utilisateurs, profils et position. Même désactivée, la règle est un changement enregistré. Une réponse bien formulée ne prouve pas la sécurité.

La catégorie Generative AI et les filtres aident à contrôler les services autorisés dans Sophos AI Defense. Autoriser un domaine ne décide pas quels renseignements vont au prompt. Le contrôle réseau n’inspecte pas complètement chaque envoi et ne remplace pas la classification. Services, licences et capacités complémentaires se jugent séparément.

Pour NDR Essentials et NDR Active Threat Intelligence, Sophos décrit des alertes supplémentaires sans isolation automatique ni Heartbeat rouge. Visibilité et blocage sont séparés. Cela ne désactive pas toutes les actions Active Threat Response. Une alerte sans réponse automatique exige un responsable et une escalade.

D’autres modifications concernent les références par ID des Content Control Lists de courriel et les définitions versionnées de catégories web dans le backend. Discrètes, elles peuvent aider à garder la configuration cohérente lors des mises à jour et restaurations.

La migration précède la mise à jour

La rupture majeure n’est pas l’IA : Sophos retire le type de serveur eDirectory natif. La documentation d’authentification v23 demande de migrer vers un type supporté et supprimer cette configuration avant la mise à jour, sinon elle échoue.

C’est un vrai projet de migration. Un login réussi avec l’alternative ne prouve pas l’identification automatique, les groupes et les règles. Les utilisateurs de SSO doivent vérifier le mappage séparément. Je terminerais cette transition avant le firmware pour isoler les problèmes ultérieurs.

EAP1 impose aussi une limite. Le support passe par les forums. Pour moi, ce build appartient à un test contrôlé avec restauration. Une annonce n’autorise pas son déploiement sur mon infrastructure critique.

Ce que montrent les premiers retours

Le fil de retours EAP1 contient des critiques des règles et un témoignage VMware : après passage de 22.0.1, ping et SSH répondaient, mais pas WebAdmin après 30 minutes. Dans une réponse ultérieure capturée par le moteur de recherche, le même utilisateur indique un retour après environ 40 minutes.

C’est un seul témoignage dont je n’ai pas reproduit la cause. Je n’en fais ni un défaut VMware général ni une durée normale. Il rappelle de vérifier accès, fenêtre de maintenance et restauration. Les fils évoluent : réponses et contre-exemples comptent autant que le signalement.

Le fil Reddit révèle aussi les attentes WAF encore ouvertes. C’est du contexte, pas un benchmark ni une liste complète de défauts confirmés.

Mon premier bilan après presque deux semaines

J’apprécie la direction, mais v23 manque encore de cohérence globale. La vue des règles progresse et l’API REST va vers une automatisation maîtrisée. L’interface conserve des différences de design, fonctions et adaptation aux écrans que je n’attends pas d’une administration moderne.

HA, WAF et transparence des correctifs comptent plus techniquement que l’étiquette IA. Leurs progrès annoncés méritent attention. Mes premiers tests ne remplacent ni une comparaison sous charge ni l’expérience d’un cluster en production. Les données du fabricant et l’acceptation locale restent décisives.

Je continue au laboratoire. C’est trop tôt pour ma production. Avant la version finale, je voudrais que la nouvelle vue serve de référence au reste : actions cohérentes, affichage utilisable à différentes tailles et moins d’écarts entre tâches comparables. Cela m’aiderait davantage qu’une autre fonction isolée.

À la prochaine,
Joe

Questions fréquentes