Sophos Firewall v22 - Nouvelles fonctionnalités, durcissement et ce à quoi s'attendre

Sophos Firewall v22 (SFOS v22) est une mise à jour majeure centrée sur le durcissement de la sécurité, une visibilité accrue et une exploitation plus stable. L’architecture Xstream modernisée, un noyau renforcé et de nouvelles fonctions de gestion réduisent la surface d’attaque et simplifient le quotidien des administrateurs. Cet article passe en revue les nouveautés clés de SFOS v22, les examine de manière critique et explique ce qui change pour les administrateurs Sophos.

Hightlight Features in SFOS v22

Introduction

La phase d’accès anticipé à SFOS v22 a débuté en octobre 2025, la version finale (GA) étant attendue pour début décembre. L’objectif de cette version est clair : le pare-feu doit être moins vulnérable, plus facile à configurer et plus robuste en fonctionnement. La nouvelle version apporte la sécurité dès la conception, une télémétrie plus approfondie et de nombreuses fonctionnalités attendues depuis des années.

Sécurité intégrée dès la conception : renforcement à plusieurs niveaux

La nouvelle fonctionnalité Health Check vérifie la configuration du pare-feu par rapport aux meilleures pratiques et aux benchmarks CIS. Elle indique :

• Les paramètres critiques (par exemple, absence d’authentification multifactorielle, accès WAN ouverts)
• L’emplacement exact de l’erreur (avec un lien vers la zone concernée)
• Comment la corriger

Un widget dans le tableau de bord affiche l’état général, la vue détaillée permet un dépannage ciblé. Particulièrement utile : les évaluations « High Risk », « Medium Risk », « Low Risk » et « Pass » facilitent la hiérarchisation.

Le sujet est tellement vaste que j’ai créé un article séparé à ce sujet: Sophos Firewall v22 Health Check - Présentation complète

Nouvelle architecture Xstream : modularité et auto-réparation

Le plan de contrôle a été entièrement repensé :

• Les services tels qu’IPS ou le filtrage Web s’exécutent en isolation, au sein de conteneurs
• La défaillance d’un module n’immobilise plus tout le système
• Le cluster HA s’auto-surveille et corrige automatiquement les dérives
• Base pour de futures intégrations de clustering et d’API
• Socle initial pour des services de pare-feu à la demande (par exemple des services DPI élastiques)

Cette architecture s’aligne sur les principes modernes des microservices et isole strictement les unités fonctionnelles. Particulièrement pertinent en HA : l’auto-réparation détecte et corrige automatiquement les problèmes de synchronisation qui, dans les versions antérieures, étaient souvent dus à des services bloqués.

À la clé : davantage de stabilité, une moindre sensibilité aux pannes et un pas net vers une architecture de pare-feu orientée services.

Noyau 6.6+ : plus d’isolation et de protection contre les exploits

La mise à niveau vers le noyau Linux 6.6 apporte d’importantes améliorations de sécurité :

• Protection contre Spectre, Meltdown, L1TF, MDS, Retbleed, ZenBleed, Downfall
• Stack canaries, KASLR, durcissement usercopy
• Espaces de noms étendus pour isoler les processus privilégiés
• Meilleure montée en charge sur des CPU multicœurs

Le noyau se hisse ainsi au niveau des systèmes Linux modernes et protège mieux contre les attaques de bas niveau. Une isolation renforcée des processus améliore aussi la défense face aux attaques par canaux auxiliaires, qui ont récemment visé à nouveau les systèmes embarqués.

Remote Integrity Monitoring : le pare-feu se surveille lui-même

Un autre différenciateur majeur :

• Le capteur XDR est désormais intégré au pare-feu
• Il détecte notamment les exportations de règles, les démarrages de processus et les manipulations de fichiers
• Les alertes remontent vers Sophos Central
• Détecte aussi les manipulations internes ainsi que l’exécution de commandes shell via la CLI
• Les événements sont horodatés et attribués à l’utilisateur et à la source

Une étape vers une détection d’intrusion au niveau de l’hôte, directement sur le pare-feu. Pour les audits ou les rapports de conformité, ces données peuvent être rattachées à MDR ou à un SIEM. Elles offrent une visibilité accrue, y compris sur des activités administrateur suspectes ou des écarts de politique en production.

Plan de contrôle Xstream nouvelle génération

• Un nouveau socle pour la sécurité et l’évolutivité : le plan de contrôle est désormais modulaire et sépare strictement les services centraux (IPS, Web, TLS). Chaque service fonctionne de façon isolée, peut être redémarré indépendamment et ne dépend pas d’autres processus.
• Indépendant du matériel et de l’environnement : l’optimisation cible les CPU multicœurs modernes. Le comportement et les performances sont cohérents sur les appliances matérielles, les VM et le cloud.
• Haute disponibilité améliorée avec auto-réparation : dans les configurations HA, le système surveille les dérives et les états de synchronisation et les corrige automatiquement, avec une séparation claire entre le plan de données et le plan de contrôle.
• Perspectives techniques et avenir : préparation au clustering multi-nœuds, à une containerisation accrue et à des API REST complètes pour l’automatisation.
• Détection et réponse : renseignement sur les menaces renforcé
• Threat Feeds aussi pour NAT et WAF : les Sophos Threat Feeds s’appliquent désormais également aux règles DNAT et WAF. Les IP malveillantes sont bloquées à l’entrée du pare-feu, que ce soit pour des serveurs internes ou des portails utilisateurs. Cela réduit nettement la surface d’attaque.

Journalisation ATR : moins de bruit, des événements plus clairs

• Les attaques par force brute peuvent être filtrées de manière ciblée
• Les événements sont catégorisés par Threat Feeds, NDR, MDR
• Les journaux indiquent clairement : « attaque détectée, bloquée, raison XY »
• Les scores provenant de NDR Essentials apparaissent désormais dans le journal

Les administrateurs accèdent ainsi plus vite au contexte, sans devoir passer d’une plateforme à l’autre. Particulièrement utile lors d’incidents à évolution rapide, comme le credential stuffing.

NDR Essentials : Threat Score dans le journal, région sélectionnable

• Le NDR Threat Score apparaît directement dans le journal
• Centre de données d’analyse sélectionnable (p. ex. UE)
• Paramétrable pour répondre aux exigences du RGPD en matière de confidentialité

Cela abaisse le seuil d’adoption pour les petites entreprises qui évitaient jusqu’ici le NDR pour des raisons de protection des données.

Intégration dans XDR/MDR : plus de visibilité

• Les données d’intégrité provenant du pare-feu sont intégrées à Sophos Central
• Corrélation avec la télémétrie endpoint/cloud
• Base pour le Managed Detection & Response
• Détection précoce des mouvements latéraux des attaquants

Sophos intègre ainsi plus profondément le pare-feu dans le concept Detection & Response et en fait un élément plus actif de la défense.

Administration et supervision : plus de confort d’exploitation

• SNMP : températures des CPU/NPU, PoE, PSU surveillables, MIB officielle incluse
• sFlow : jusqu’à 5 collecteurs, échantillonnage librement configurable
• WebAdmin plus réactif : le changement de page ne fige plus l’interface
• Interfaces VPN : fonction de recherche/filtrage pour les nombreuses interfaces XFRM
• API Access : jusqu’à 64 adresses IP/objets autorisés, configurable dans « Administration »
• TLS 1.3 : WebAdmin, le portail VPN et le portail utilisateur utilisent désormais un chiffrement moderne
• Instant Web Category Alerts : notification lors d’un accès à des catégories Web définies (par exemple, environnements scolaires)
• Pagination améliorée : notamment pour les longues listes (par exemple, règles de pare-feu, objets)

Contrôle d’accès à l’API

L’accès à l’API d’administration peut être restreint à des adresses IP, des plages ou des objets réseau (jusqu’à 64 entrées). Recommandation : n’autoriser que les réseaux de gestion, activer la journalisation et vérifier régulièrement les accès.

Mises à jour de firmware via SSL avec épinglage de certificat

Les points de terminaison de mise à jour sont validés via SSL, avec épinglage de certificat. Dans les environnements aux politiques de sortie strictes, placer les FQDN cibles en liste d’autorisation.

HTTP/2 et TLS 1.3 pour l’accès aux équipements

WebAdmin, les portails utilisateur et VPN utilisent HTTP/2 et TLS 1.3 pour des négociations plus rapides et des suites cryptographiques à jour.

Pour les grandes installations ou les environnements MSP en particulier, ce sont des améliorations bienvenues.

Fonctions proches de l’UTM dans SFOS

• La WAF peut désormais exiger la MFA
• OTP via SHA-256/512
• Journaux d’audit avec export avant/après (XML)
• Gestion de session améliorée sur la WAF (prise en charge de l’ID de session par le pare-feu)
• Compatibilité avec les jetons matériels OTP existants

Audit Trail Logs en détail

La phase 1 journalise les modifications des règles de pare-feu, des objets et des interfaces avec un avant/après. Téléchargement via Diagnostics > Logs (configuration-audit.log). À terme, visibilité directe dans le Log Viewer.

Ce sont des points importants pour les clients qui souhaitent ou doivent migrer depuis UTM 9. La feuille de route pour les remplacements SG-UTM se consolide encore. D’ici juillet 2026, le compte à rebours est lancé : v22 lève plusieurs des derniers obstacles à la migration.

Mise à niveau vers SFOS v22 : chemins, durée et recommandations

• EAP disponible, GA prévue pour décembre 2025
• La mise à niveau vérifie la taille du disque et étend automatiquement la partition racine si nécessaire (le premier démarrage peut être plus long)
• Chemins habituels : versions actuelles v20/21 → v22 directement ; anciennes installations à mettre d’abord sur une MR supportée si besoin
• Avant toute mise à niveau : créer une sauvegarde, préparer correctement le cluster HA, planifier une fenêtre de maintenance
• Après la mise à niveau : exécuter le Health Check et prioriser les constats

Important : les sauvegardes sont indispensables, surtout pour HA, SD-WAN et les configurations multi-partitions.

Impressions personnelles après 1 semaine

• Health Check : fournit rapidement des constats exploitables. Dans les deux environnements, il a mis en évidence des valeurs par défaut faibles et des reliquats oubliés. Les liens vers l’emplacement concerné font gagner du temps. Particulièrement utile pour les administrateurs de pare-feu qui n’en configurent pas régulièrement et ont besoin d’une liste de contrôle claire.
• Architecture Xstream : les modules peuvent être observés séparément et se montrent stables. Dans le labo HA, aucune intervention manuelle n’a été nécessaire pour corriger de petits écarts de synchronisation.
• Logging/ATR/NDR : les champs de contexte supplémentaires dans le journal facilitent la corrélation avec Central. Les scores NDR dans le journal sont utiles en pratique.
• SNMP/sFlow : les MIB SNMP se sont intégrées sans accroc à l’outil de supervision existant. sFlow a apporté suffisamment de visibilité sans la surcharge de PCAP complets.
• Flux de menaces tiers (NAT/WAF) : les IP malveillantes connues sont bloquées de manière fiable en périphérie, y compris sur la redirection de ports et les règles WAF. Dans mon labo, le blocage fonctionne ; la journalisation des correspondances n’apparaît toutefois pas encore malgré l’option activée. J’attends EAP2 ou la GA pour retester.

En conclusion

SFOS v22 n’est pas une mise à jour cosmétique, mais une évolution architecturale en profondeur. La nouvelle base Xstream, le Health Check et les extensions d’API rendent le pare-feu plus robuste et prêt pour l’avenir.

Quiconque exploite aujourd’hui une Sophos XGS a tout intérêt à s’intéresser à v22 : le gain est réel, tant pour la sécurité que pour le quotidien des administrateurs.

À long terme, Sophos pose ainsi les bases d’une architecture de pare-feu containerisable, à l’intégrité vérifiable et exploitable de façon automatisée. C’est la bonne direction à une époque où les pare-feux doivent faire bien plus que simplement bloquer des paquets.

Dommage toutefois que, pour une version aussi majeure, certaines faiblesses connues persistent. L’interface reste parfois lente, notamment lors du passage d’une règle de pare-feu à une autre : ces temps de chargement se font sentir. De plus, il n’est toujours pas possible de masquer individuellement des colonnes dans les vues en liste (par exemple, tables de pare-feu ou IPsec), ce qui nuit à la lisibilité. Le Log Viewer perd aussi ses filtres à chaque redémarrage, et les règles NAT ne peuvent ni être clonées ni groupées. Des statistiques ou des indicateurs graphiques de stabilité pour les connexions IPsec font également défaut.

À mon sens, ce sont des points que Sophos devrait traiter en priorité dans la prochaine mise à jour majeure afin d’améliorer l’expérience utilisateur et de faciliter l’exploitation quotidienne pour les administrateurs.

À bientôt, Joe