Sophos Firewall v23 : aperçu et nouvelles fonctionnalités

Sophos Firewall v23 s’attaque à plusieurs tâches chronophages du quotidien : rechercher des règles, identifier correctement les utilisateurs, planifier les mises à jour et comprendre pourquoi un cluster a basculé. Cette nouvelle version majeure apporte pour cela une REST API, un assistant IA ainsi que des améliorations de la WAF, du DNS et du DHCP.

État de la version : Comme les années précédentes, la prochaine version majeure commence par une phase d’accès anticipé de Sophos Firewall v23 autour du mois d’octobre, dès le 28 septembre 2026 cette année. Cet article repose sur la version EAP1. Certaines fonctions et certains détails peuvent encore changer avant la version finale.

Certaines nouveautés sont directement disponibles sur le pare-feu ; d’autres nécessitent Sophos Fusion ou un logiciel supplémentaire. Un point compte particulièrement pour la planification : la nouvelle identification des utilisateurs par Synchronized Security exige Sophos Endpoint sur les appareils concernés et une licence Endpoint adaptée. Une entreprise qui utilise uniquement Microsoft Defender ou un autre produit de protection des postes ne bénéficiera donc pas de cette fonction avec la seule mise à jour du pare-feu. Elle devra déployer et licencier Sophos Endpoint en plus. Si elle possède déjà des licences Sophos, l’effort supplémentaire dépend de son contrat. Nous précisons les autres prérequis dans les sections correspondantes.

IA et automatisation

REST API : automatiser la configuration du pare-feu

La nouvelle REST API permet aux scripts et aux outils d’administration de lire et de modifier directement la configuration du pare-feu. L’authentification s’effectue au moyen de clés API. Une description au format OpenAPI 3.0 documente les appels et les champs disponibles, ce qui facilite l’intégration dans les outils existants. L’accès se fait directement au pare-feu et ne dépend pas de l’API Sophos Central utilisée pour exporter et importer des configurations.

La distribution de paramètres communs sur plusieurs pare-feu faisait déjà partie des objectifs de Sophos Central Firewall Management. Les groupes de pare-feu et les politiques de niveau supérieur sont censés permettre une gestion centralisée de ces changements. Dans notre pratique, cela ne fonctionne toutefois que partiellement avec la fiabilité dont nous avons besoin pour l’exploitation. Pour les modifications récurrentes, nous préférons donc nos propres scripts et processus, dont nous pouvons contrôler le déroulement et le résultat. La nouvelle REST API constitue précisément un complément utile à cet effet.

Prenons les objets réseau d’un nouveau serveur, nécessaires sur les pare-feu de plusieurs sites. Un script peut vérifier si l’objet existe déjà, appliquer uniquement la modification nécessaire, puis relire la valeur enregistrée. Son journal permet de voir quel pare-feu a été mis à jour et où une intervention reste nécessaire. C’est particulièrement utile lorsqu’un site est inaccessible pendant l’opération et doit être traité ultérieurement.

Les clés API se gèrent sous Administration > API access. Elles héritent des droits de l’administrateur associé. Pour les automatisations, il est donc préférable de créer un compte dédié avec un profil de droits adapté. Les adresses sources autorisées et l’accès d’administration doivent également être correctement configurés. Il convient de limiter l’accès aux seuls systèmes qui en ont réellement besoin pour leurs tâches de gestion.

Allowed IP hosts : dans v23, seules des adresses IP ou des plages réseau peuvent encore être autorisées ici. Un FQDN, c’est-à-dire un nom DNS complet, n’est toujours pas accepté. Cela ne pose pas de problème à un serveur d’automatisation doté d’une IP de sortie fixe. En revanche, si le script passe par une connexion dont l’adresse IP publique change, son nom DNS ne peut pas simplement être ajouté aux sources autorisées. Il faut alors, par exemple, une sortie à adresse fixe ou un accès VPN contrôlé. Pour une interface destinée à faciliter l’automatisation, nous aurions souhaité davantage de souplesse.

Le REST API guide est accessible dans la WebAdmin sous Administration > API access. Le lien se trouve en haut à droite de la liste des clés API, juste à côté d’OpenAPI.yaml. La référence publique de l’API Sophos Firewall décrit les points de terminaison, les champs de données et les premiers pas avec l’authentification. Pour l’implémentation concrète, c’est le fichier OpenAPI de la version installée sur le pare-feu qui fait foi. Avant de remplacer une automatisation XML existante, il faut vérifier que toutes les fonctions nécessaires sont couvertes. La gestion des erreurs, la journalisation et une procédure de retour arrière testée restent indispensables, même avec une API moderne.

Assistant IA pour les règles de pare-feu

Le nouvel assistant de Sophos Fusion répond aux questions sur les règles de pare-feu. Il crée des brouillons de règles désactivés en fin de tableau ; leur validation reste du ressort de l’administrateur.

C’est une approche judicieuse pour travailler avec l’IA. Une demande telle que « Prépare une règle autorisant le trafic HTTPS du réseau des employés vers le serveur web interne » peut faire gagner du temps. Avant de l’activer, il faut néanmoins vérifier quels objets précis sont concernés, si l’accès doit être limité à certains utilisateurs et quels contrôles de sécurité doivent s’appliquer.

La position de la règle est particulièrement importante. Une autorisation techniquement correcte peut rester sans effet si une autre règle est évaluée avant elle. À l’inverse, une règle placée trop haut peut autoriser plus de trafic que prévu. L’assistant ne prend donc pas les décisions de sécurité à la place de l’administrateur. Son intérêt est de préparer le travail sur les règles et de faciliter la recherche des liens entre elles.

Autoriser ou bloquer les services d’IA de manière ciblée

La catégorie web Generative AI et des filtres applicatifs liés à Sophos AI Defense s’ajoutent aux moyens de contrôle de l’utilisation de l’IA.

Sous Diagnostics > URL category lookup, on peut vérifier la catégorie attribuée à un domaine. Pour openai.com, le pare-feu affiche Generative AI. Cela aide au diagnostic : si un service d’IA est bloqué de manière inattendue, on peut d’abord vérifier sa catégorie, puis la politique web appliquée.

Pour une entreprise, la configuration commence par une décision simple : quels services d’IA sont autorisés pour quels usages ? Une équipe de développement peut avoir besoin d’outils différents de ceux de la comptabilité. C’est seulement à partir de cette décision qu’une politique réseau utile peut être définie.

Autoriser un domaine ne dit toutefois rien des informations qui peuvent y être saisies. Le contrôle d’accès et la protection des données sont deux tâches distinctes. Même pour un service autorisé, il faut des règles concernant les données clients, le code source et les documents confidentiels. Les filtres réseau peuvent soutenir ces règles organisationnelles, mais ils ne remplacent pas l’examen du contenu de chaque prompt.

Gestion des règles et interface

Nouveau tableau des règles de pare-feu

La vue Rules and policies > Firewall rules a été entièrement remaniée. À la place des dossiers dépliables, les règles figurent désormais dans un tableau continu. Leur regroupement est conservé, mais apparaît dans la colonne Group. Une recherche en texte libre, des filtres et une sélection personnalisable des colonnes complètent la vue.

Ce changement corrige une irritation de l’ancienne interface : après modification et enregistrement d’une règle de pare-feu, son groupe se refermait. Pour modifier immédiatement la règle suivante du même groupe, il fallait rouvrir le dossier. Lorsque plusieurs changements se succédaient, cette opération devenait pénible. L’affichage du groupe dans une colonne évite ces manipulations répétées.

Choisir et organiser les colonnes

L’icône en forme de roue dentée, en haut à droite du tableau, permet de choisir les colonnes affichées. On peut masquer les données inutiles, ajouter des détails et modifier l’ordre des colonnes. Il est également possible d’en figer certaines. Ainsi, le nom de la règle reste visible lorsqu’on parcourt un tableau large.

Point particulièrement appréciable : lors de notre test, la vue choisie est restée enregistrée après une déconnexion et une nouvelle connexion. Il n’est donc pas nécessaire de la reconfigurer à chaque session.

Pour une vue rapide, le nom, le groupe, l’action, l’état et le trafic suffisent souvent. Lors d’un diagnostic, les réseaux source et destination, les services et la journalisation sont davantage utiles. Si, par exemple, l’accès à un ancien serveur applicatif doit être supprimé, il est pratique de comparer côte à côte les destinations des règles concernées. Ne pas devoir ouvrir chaque règle individuellement fait gagner du temps.

Les colonnes suivantes sont disponibles. Leurs noms correspondent à l’interface anglaise ; nous les regroupons ici par thème pour faciliter la lecture :

• Règle et vue d’ensemble : Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Réseaux et services : Src networks, Src zones, Dst zones, Dst networks, Services.
• Utilisateurs et journalisation : Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Fonctions de protection et politiques : Email, Web policy, IPS policy, Application policy.
• Bande passante et priorité : Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat : Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Exceptions : Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

L’ancienne vue reste provisoirement disponible

Le commutateur New design permet encore de revenir à la vue précédente. Ceux qui ne s’accommodent pas du nouveau tableau disposent donc, pour le moment, d’une solution de repli. On ignore combien de temps Sophos proposera les deux vues en parallèle.

Règles NAT : toujours sans regroupement ni clonage

Malheureusement, Sophos n’a pas étendu la nouvelle vue aux règles NAT. Celles-ci restent traitées différemment dans v23 : il n’est toujours possible ni de les regrouper ni de les cloner. Le clonage existe pour les règles de pare-feu, mais pas pour les règles NAT.

Ce serait pourtant pratique lorsqu’on publie plusieurs services similaires. Si un autre serveur web nécessite presque la même redirection, on voudrait copier une règle NAT existante, puis modifier la destination et le service. À la place, il faut recréer la règle. Cela prend du temps et augmente le risque de modifier involontairement un autre paramètre.

Nous avions déjà évoqué ces souhaits dans notre article sur Sophos Firewall v22. La nouvelle vue des règles de pare-feu est un progrès réjouissant. Il est d’autant plus regrettable que la gestion NAT reste à la traîne pour des opérations aussi fondamentales.

WebAdmin, numéro de série et état du cluster

La WebAdmin utilise HTTP/2 pour accélérer le transfert des éléments de page. Le numéro de série et l’état du cluster HA restent également visibles lorsqu’on passe d’une page de configuration à une autre.

HTTP/2 peut aider à charger de nombreux éléments, notamment sur les connexions à forte latence. Mais la rapidité ressentie dépend aussi du traitement effectué par le pare-feu. Un protocole de transport différent n’accélère pas, à lui seul, une requête lente à la base de données ni l’enregistrement d’une configuration complexe. Lors de mon premier test, le gain de vitesse m’a semblé faible : enregistrer une règle de pare-feu prenait toujours plusieurs secondes.

L’identification visible de l’appareil présente un avantage immédiat : avec plusieurs sessions de pare-feu ouvertes, on vérifie plus facilement sur quel système on travaille. Avant une modification sur un cluster HA, il est également utile de regarder le rôle et l’état des appareils concernés.

Les personnes qui accompagnent plusieurs environnements clients presque identiques connaissent cette hésitation juste avant d’enregistrer une modification. Un numéro de série toujours visible facilite la comparaison avec le ticket, sans devoir quitter la page de configuration. C’est un petit changement, mais son utilité est très concrète.

Haute disponibilité : détecter plus vite, basculer avec discernement

L’état du matériel comme déclencheur

Outre les connexions et les services, le cluster HA surveille désormais l’état de certains composants matériels, dont le SSD. Si celui-ci se dégrade, le cluster peut basculer sur l’autre pare-feu.

Un cluster HA ne peut réagir efficacement à une défaillance que s’il la détecte. Un appareil peut encore répondre sur ses interfaces réseau alors qu’il rencontre déjà des problèmes internes. Cette surveillance matérielle supplémentaire compte donc pour l’exploitation.

Un SSD défectueux peut, par exemple, perturber les écritures pendant que le lien HA fonctionne encore. Une simple surveillance de la connectivité ne détecterait pas l’état du disque. La surveillance matérielle peut intervenir avant que le nœud fragilisé ne tombe complètement en panne.

Après un tel basculement, il faut néanmoins rechercher la cause. Le deuxième nœud maintient le service, mais ne répare pas le SSD défectueux. Le processus d’exploitation doit donc prévoir la vérification de l’appareil concerné, l’évaluation de la redondance restante et, si nécessaire, le remplacement du matériel.

Détection plus rapide de la panne

Grâce à une surveillance accélérée, le cluster HA détecte la défaillance de l’autre pare-feu en 300 ms au lieu de quatre secondes auparavant.

Ces 300 ms correspondent au délai nécessaire pour que le pare-feu détecte la panne de l’autre appareil du cluster. D’autres étapes peuvent être nécessaires avant qu’une application fonctionne à nouveau normalement : le pare-feu restant doit prendre le relais, les équipements réseau voisins doivent acheminer le trafic par le bon chemin et les connexions existantes doivent se poursuivre ou être rétablies.

Pour obtenir un résultat pertinent, il faut donc observer davantage qu’un simple ping. Un appel téléphonique en cours, un transfert de fichier et un accès VPN peuvent subir des effets différents. Seules de telles mesures permettent de déterminer si le basculement est assez rapide pour les processus métier concernés.

Moins de basculements intempestifs sous forte charge

Les deux pare-feu échangent régulièrement de brefs messages d’état, appelés HA-Heartbeats. Ces messages bénéficient désormais d’un traitement prioritaire, séparé du trafic normal.

Cela répond à un problème qui se manifeste sous forte charge : lorsqu’un système est très sollicité, une réponse tardive peut ressembler à une panne. Un basculement déclenché à tort perturbe davantage un environnement déjà chargé.

Il faut donc vérifier deux situations lors de la recette : le cluster détecte-t-il une véritable panne et reste-t-il stable sous forte charge lorsque les appareils fonctionnent correctement ? Un test au repos ne répond qu’à la première moitié de la question.

Sécurité DNS, hotfixes et firmware

DNS over HTTPS et DNSSEC

Le pare-feu peut désormais envoyer des requêtes DNS chiffrées par HTTPS à un résolveur et vérifier les réponses DNS avec DNSSEC. L’activation de Sophos DNS Protection est également simplifiée.

Ces deux technologies DNS répondent à des problèmes différents. DNS over HTTPS, ou DoH, chiffre le transport vers le résolveur. DNSSEC vérifie les données DNS signées. Une connexion chiffrée ne prouve pas à elle seule qu’une réponse DNS est authentique, et une signature valide ne masque pas la requête aux observateurs du chemin réseau.

Avant de mettre ces fonctions en place, il faut comprendre le chemin DNS existant. Le client interroge-t-il le pare-feu, un serveur DNS Windows interne ou directement un résolveur public ? Les espaces de noms internes doivent continuer à être résolus au bon endroit. Les DNS Request Routes restent notamment utiles à cet effet.

Les navigateurs disposant de leurs propres paramètres DoH méritent aussi une attention particulière. Si un client utilise un autre résolveur, son chemin DNS réel peut différer de la configuration centralisée. Un test fonctionnel doit donc couvrir les noms internes, la résolution externe et les décisions de filtrage attendues.

Hotfixes et mises à jour de sécurité visibles

En parcourant l’interface, nous avons remarqué un autre changement : sous Backup & firmware, une section distincte est de nouveau consacrée aux hotfixes. L’onglet s’appelle Hotfix: Security updates. Auparavant, le paramètre des hotfixes se trouvait dans la section Firmware. Une case permettait d’indiquer si les hotfixes importants devaient être installés automatiquement. Après la disparition de ce paramètre de l’interface, les hotfixes retrouvent une place visible.

La nouvelle vue présente l’état des mises à jour de sécurité. L’ancien commutateur d’activation ou de désactivation n’apparaît pas dans la capture. Par ailleurs, la disparition temporaire du paramètre ne signifie pas que le pare-feu ne recevait plus de hotfixes : leur installation automatique existe toujours.

À quoi servent les hotfixes

Les hotfixes apportent des corrections ciblées à des problèmes urgents, en particulier des failles de sécurité. Ils peuvent être distribués en dehors du calendrier habituel des versions de firmware. Une correction importante n’a ainsi pas besoin d’attendre le prochain Maintenance Release et la planification d’une mise à jour complète du firmware dans l’entreprise.

Si, par exemple, une vulnérabilité est découverte dans un service d’administration, un hotfix approprié peut corriger le composant concerné. L’installation automatique réduit le délai entre la disponibilité de la correction et son application sur le pare-feu. Elle est activée par défaut et devrait le rester en exploitation normale. Les hotfixes ne remplacent toutefois pas les mises à jour classiques du firmware, qui apportent aussi d’autres corrections, des modifications de composants et de nouvelles fonctions.

Consulter directement l’état des correctifs

L’interface indique désormais quelles failles de sécurité ont été corrigées par les hotfixes installés. Chaque entrée comprend l’identifiant CVE, la gravité, la date d’installation et un lien vers l’avis de sécurité correspondant. Ces informations sont également disponibles dans les rapports.

Cela aide à répondre à une question fréquente en exploitation : cette vulnérabilité précise a-t-elle déjà été traitée sur ce pare-feu précis ? Lorsque des hotfixes sont distribués en plus du firmware, son seul numéro de version ne donne pas toujours la réponse complète.

Si un client pose une question à propos d’un nouvel avis de sécurité, l’état local peut ainsi être documenté plus précisément. Plutôt que de déduire le niveau de protection de la seule version du firmware, on peut consulter la CVE concernée et la date d’installation du hotfix, puis consigner ces éléments dans le ticket.

Pour la documentation, il faut examiner l’état des correctifs affiché avec l’avis de sécurité correspondant. Un correctif installé répond à la question de la correction concernée. Il ne prouve ni que tout le système est configuré de manière sûre, ni qu’une attaque antérieure est exclue. Une vérification de la configuration, l’analyse des journaux et, le cas échéant, une investigation restent nécessaires.

Mises à jour récurrentes du firmware

Dans Sophos Fusion, on peut définir des fenêtres de maintenance récurrentes pendant lesquelles les pare-feu installent automatiquement les nouvelles versions du firmware. Tous les appareils ne doivent pas être mis à jour en même temps. On peut commencer par certains pare-feu et traiter les autres plus tard. Des réglages différents sont possibles pour certains appareils, par exemple lorsqu’un site dispose de sa propre fenêtre de maintenance.

C’est particulièrement utile pour une entreprise qui possède plusieurs succursales. Le pare-feu d’un petit bureau peut, par exemple, recevoir la mise à jour en premier. On y vérifie ensuite les connexions VPN, les authentifications des utilisateurs et les services publiés. Les autres sites ne suivent qu’une fois ces contrôles réussis. Cela évite de lancer chaque installation séparément tout en gardant la maîtrise de l’ordre de déploiement.

Il faut au préalable déterminer qui contrôle les résultats et qui arrête les mises à jour suivantes en cas de problème. Une installation automatique ne dispense ni d’une sauvegarde ni d’une procédure de retour arrière préparée. Nos guides sur les mises à jour du firmware et la sauvegarde et restauration décrivent les étapes nécessaires.

Identité et authentification

Entra ID avec Synchronized User ID

Grâce à Synchronized Security, le pare-feu peut désormais identifier aussi les utilisateurs qui travaillent avec Entra ID. Les appareils joints à un AD local et ceux utilisant une identité cloud peuvent ainsi coexister. Cette identification exige Sophos Endpoint sur les appareils concernés et une licence Endpoint adaptée.

La question pratique est la suivante : comment le pare-feu connaît-il l’utilisateur derrière une connexion ? Une adresse IP seule ne suffit pas toujours pour appliquer une règle liée à un utilisateur. Lors du passage d’un domaine local à une identité cloud, cette association doit continuer à fonctionner de manière fiable.

Prenons une entreprise qui rattache ses nouveaux ordinateurs portables uniquement à Entra ID, tandis que les appareils plus anciens restent dans le domaine AD local. Cette phase de transition technique ne devrait rien changer à la politique web de la comptabilité : c’est l’appartenance au groupe d’utilisateurs qui compte. Cette continuité est importante lors d’une migration progressive vers le cloud.

Pour la planification, il faut distinguer cette fonction de l’authentification Entra ID déjà connue sur le Captive Portal. Il s’agit ici de l’interaction avec Sophos Endpoint. Une infrastructure Entra ID existante ne suffit donc pas, à elle seule, à fournir au pare-feu une identification adaptée des utilisateurs. Pendant le pilote, il faut vérifier quel utilisateur est réellement identifié et quelle règle de groupe s’applique ensuite.

Google Workspace comme Identity Provider

Les utilisateurs peuvent se connecter avec leur compte Google Workspace au Captive Portal, au VPN Portal, à Sophos Connect et à la WebAdmin. Google Workspace joue alors le rôle d’Identity Provider et peut aussi imposer l’authentification multifacteur lors de la connexion.

Pour les organisations qui utilisent Google comme annuaire central, c’est une amélioration importante. Les comptes et les règles de connexion devraient, autant que possible, être gérés là où le sont déjà les autres accès de l’entreprise.

Une école utilisant Google Workspace n’a, par exemple, pas besoin de maintenir une base de mots de passe indépendante sur le pare-feu pour l’accès VPN des enseignants. Cela réduit les tâches d’administration en double et facilite la sécurisation de la connexion par l’Identity Provider central.

Une connexion réussie ne constitue toutefois qu’une partie de l’intégration. Les droits corrects doivent ensuite être appliqués. Une authentification SSO fonctionnelle ne doit pas donner à un employé ordinaire l’accès à l’administration. Les tests doivent donc porter ensemble sur les attributs des utilisateurs, l’association aux groupes, les services autorisés et la révocation des droits d’accès.

Configuration de la MFA par e-mail

Pour configurer l’authentification multifacteur, le pare-feu peut envoyer le QR code nécessaire par e-mail. Si l’enregistrement n’est pas terminé dans les 24 heures, le code inutilisé expire. Dans les installations existantes, la procédure d’inscription par le portail reste d’abord disponible.

Cela modifie le parcours de configuration des nouveaux utilisateurs. Avant le déploiement, il faut vérifier les adresses e-mail et l’acheminement des messages. Sinon, la première connexion VPN se transforme en demande d’assistance, même si l’authentification elle-même est correctement configurée.

Un QR code d’enregistrement contient des informations sensibles pour la sécurité. La boîte de réception doit donc être protégée elle aussi. Le service d’assistance a également besoin d’une procédure claire pour les enregistrements expirés et les adresses incorrectes. Un nouvel envoi ne doit pas dispenser de vérifier l’identité de la personne qui le demande.

SSO pour Chromebook

Une nouvelle extension pour Chromebook transmet l’identité de l’utilisateur au pare-feu sans lui demander de se reconnecter au Captive Portal. Elle prend en charge toutes les versions de SFOS encore supportées.

Dans les écoles notamment, les connexions répétées au portail sont gênantes. Mais le point décisif n’est pas seulement la première connexion réussie : il faut aussi vérifier les changements d’utilisateurs et d’appareils. Un essai sur des Chromebooks partagés doit montrer qu’après un changement d’utilisateur, aucune ancienne association ne continue d’être utilisée.

Comme cette extension fonctionne avec plusieurs versions, son déploiement devrait être planifié séparément de la mise à niveau vers v23. Déployer simultanément un nouveau composant client et un nouveau firmware complique la recherche des causes en cas de problème.

Serveurs de terminaux : association des utilisateurs avec XDR Sensor

Un XDR Sensor léger peut être utilisé avec Sophos Authentication for Thin Client, ou SATC. Il aide le pare-feu à attribuer le trafic réseau d’un serveur partagé à chaque utilisateur et peut fonctionner à côté d’une solution de protection des postes existante.

Sur un serveur de terminaux, de nombreuses sessions partagent la même adresse IP. Une autorisation fondée sur l’IP ne distingue donc pas un utilisateur de la comptabilité d’un collaborateur externe sur le même serveur. Les règles web ou de pare-feu liées aux utilisateurs nécessitent une association supplémentaire.

La possibilité d’exécuter le capteur à côté d’un produit de protection déjà présent est intéressante pour les environnements mixtes. Elle ne garantit cependant pas la compatibilité de toutes les combinaisons. La licence, le système d’exploitation et l’interopérabilité supportée doivent être vérifiés en amont. Le test fonctionnel devrait au minimum confirmer que deux utilisateurs connectés simultanément reçoivent des règles différentes. L’effet sur le serveur de terminaux doit être évalué séparément des décisions du pare-feu.

WAF : davantage de contrôle sur les applications publiées

Des actions différentes selon le chemin URL

La Web Application Firewall propose des actions par chemin : Protect, Block, Redirect et Passthrough. Cette dernière permet le trafic WebSocket sans inspection WAF.

Avec Protect, le chemin reste soumis à l’inspection WAF. Block refuse l’accès avec une réponse HTTP 403. Redirect envoie le navigateur vers une autre adresse. Passthrough constitue donc une exception délibérée à l’inspection WAF pour le trafic WebSocket concerné, et non un niveau de protection supplémentaire.

On peut ainsi adapter plus finement le traitement à la structure d’une application. Après la refonte d’un portail, /altes-portal pourrait rediriger vers /kundenportal, tandis qu’une ancienne section sous /legacy serait bloquée par HTTP 403. La partie active de l’application resterait inspectée par la WAF. Gérer ces décisions directement au point d’entrée peut réduire les modifications nécessaires au backend.

La destination d’une redirection doit être précise. Un mauvais chemin peut casser les procédures de connexion ou les liens enregistrés ; une redirection mal pensée peut créer une boucle. Pour une exception sans inspection WAF, il faut savoir quelles protections restent en place dans l’application. Une connexion fonctionnelle ne prouve pas que le contrôle de sécurité est équivalent.

Plus de chemins et de règles

Chaque entrée peut contenir jusqu’à 128 chemins. La limite des règles WAF est de 100 par défaut et peut être portée à 200.

Pour la planification, il faut distinguer le nombre de règles configurables des performances. La possibilité de définir davantage de règles ne signifie pas qu’une appliance peut faire fonctionner un nombre illimité d’applications actives avec le même temps de réponse. Le traitement TLS, l’inspection, les téléversements et la vitesse des serveurs backend influent aussi sur les ressources nécessaires.

Une recette pertinente utilise donc des requêtes représentatives des applications réelles. Une simple page de test statique représente mal, par exemple, un portail acceptant de gros fichiers.

Nouveau traitement avec Apache Event MPM

La WAF passe à Apache Event MPM pour mieux traiter les requêtes simultanées.

En simplifiant, il s’agit de mieux utiliser les ressources pendant que certaines connexions attendent la suite du traitement. Lorsque de nombreux accès se produisent en même temps, cette répartition devient décisive : une connexion ouverte ne devrait pas monopoliser inutilement des ressources nécessaires à d’autres requêtes. La capacité du backend demeure toutefois une limite distincte.

Le critère d’exploitation déterminant est le comportement sous charge. Une application peut rester techniquement accessible tout en répondant si lentement que les utilisateurs interrompent leur travail. Les tests de charge doivent donc mesurer les temps de réponse et les taux d’erreur, et pas seulement compter les connexions réussies.

Pour comparer utilement l’avant et l’après, le matériel, le profil de sécurité, le backend et le trafic de test doivent rester identiques. C’est seulement dans ces conditions qu’on peut évaluer l’effet du nouveau traitement dans son propre environnement. Le changement d’architecture ne suffit pas à déduire un débit valable partout.

DHCP, routage et services réseau

DHCP sur le nouveau Control Plane

Le service DHCP fonctionne désormais sur le nouveau Control Plane et peut gérer des plages d’adresses plus grandes ainsi que davantage de réservations. Le trafic DHCP est également contrôlé par le pare-feu avant d’atteindre le service afin de limiter les effets d’un afflux de requêtes. Des paramètres auparavant accessibles uniquement en ligne de commande figurent maintenant dans l’interface.

Il s’agit d’une dépendance fondamentale du réseau. Si les clients ne reçoivent pas d’adresse, de nombreux autres services semblent également en panne. Lors d’une mise à niveau, le serveur DHCP doit donc être contrôlé aussi attentivement que l’accès VPN ou Internet.

La capacité accrue devient utile, par exemple, dans une école où de nombreux appareils se connectent presque simultanément au Wi-Fi le matin et demandent une adresse. Pour les utilisateurs, une attribution lente ressemble rapidement à un problème de Wi-Fi. Un traitement rapide des leases aide à un endroit facilement oublié lors du diagnostic.

Les tests doivent couvrir les nouvelles leases, le renouvellement des leases existantes et les adresses réservées. Il faut aussi vérifier les valeurs transmises, comme la passerelle, les serveurs DNS et les options DHCP personnalisées. Les paramètres rarement utilisés ne posent parfois problème qu’au redémarrage d’un appareil particulier.

La consultation des adresses attribuées a également été revue. Les options DHCP sont traitées de manière plus uniforme conformément aux standards sous-jacents. Les configurations particulières existantes méritent donc une comparaison ciblée avant et après la mise à niveau.

Parmi les paramètres transférés dans l’interface figurent les accusés de réception négatifs et la limite d’une lease par client. Un accusé négatif indique au client qu’il ne peut pas utiliser l’adresse demandée et doit renégocier sa configuration IP. Il faut évaluer ces paramètres en fonction de son architecture réseau, notamment lorsque plusieurs services DHCP sont présents.

Réflecteur mDNS pour Bonjour et la découverte des appareils

Le réflecteur mDNS permet aux appareils de découvrir des services dans d’autres réseaux sélectionnés. Il fonctionne en IPv4 comme en IPv6. Une règle de pare-feu adaptée reste nécessaire pour établir ensuite la connexion avec l’appareil trouvé.

C’est utile, par exemple, lorsque les imprimantes et les employés se trouvent dans des VLAN différents. Une imprimante peut être correctement adressée et accessible, mais ne pas apparaître dans la recherche automatique des appareils. La découverte du service et la connexion ultérieure sont deux étapes distinctes.

Il faut limiter la configuration aux paires de réseaux et aux services nécessaires. Un réseau invité n’a pas besoin de découvrir tous les appareils de l’infrastructure interne. Après la configuration, les tests doivent vérifier à la fois le résultat voulu et les limites : l’imprimante prévue est visible et utilisable, tandis que les autres services internes restent inaccessibles.

Moteur de routage et BFD expérimental

Le pare-feu utilise une version actualisée du logiciel de routage FRR. Les différents protocoles de routage peuvent être gérés depuis une console commune. Une prise en charge expérimentale de BFD pour BGP et les routes statiques s’ajoute sur les pare-feu exploités individuellement.

BFD signifie Bidirectional Forwarding Detection et sert à détecter rapidement la perte d’une connexion entre voisins de routage. C’est une autre fonction que le changement de rôle dans un cluster HA. Détecter une panne plus vite peut permettre de rediriger plus tôt le trafic vers un autre chemin.

Des intervalles de surveillance très courts ne sont toutefois pas une fin en soi. Si le pair ou le transport ne répond pas de manière fiable sous charge, un réglage trop agressif peut provoquer des changements d’état inutiles. Il faut donc prendre au sérieux le caractère expérimental de cette fonction et commencer par évaluer BFD dans un environnement de test adapté.

Prenons deux liaisons de site routées : l’interface locale peut rester active alors que le voisin n’est plus joignable par le chemin préféré. L’état du lien ne suffit alors pas à détecter la panne. Dans une telle architecture, une configuration BFD adaptée peut aider à la constater plus tôt.

IPv6 IPoE et 4in6

Le pare-feu prend en charge d’autres types de connexion avec IPv6 IPoE et les tunnels 4in6, dont le service Internet japonais Xpass.

Avec 4in6, le trafic IPv4 est transporté dans une connexion IPv6. Ces fonctions sont surtout utiles si le fournisseur d’accès impose précisément ce modèle. Sur une connexion classique, elles ne justifient pas à elles seules de modifier la configuration WAN.

Les extensions concernent aussi les adresses dynamiques, les extrémités de tunnel et MTU/MSS. Leur interaction compte lors du diagnostic : l’établissement réussi du tunnel ne garantit pas que les gros paquets ou toutes les applications fonctionnent correctement. Les paramètres du fournisseur, la résolution de noms et la taille des paquets doivent donc être vérifiés ensemble.

Déploiement sur IONOS Cloud

Sophos Firewall peut désormais fonctionner sur IONOS Cloud avec l’image SFOS officielle. L’installation se fait manuellement à partir d’une image dédiée, sans entrée Marketplace prête à l’emploi.

Pour concevoir l’architecture, il faut donc toujours déterminer comment les réseaux publics et internes seront raccordés, comment l’accès d’administration sera protégé et qui gérera le cycle de vie de la machine virtuelle. La disponibilité d’une plateforme d’installation supportée ne répond pas encore aux questions de redondance, de restauration et de surveillance.

En particulier, le modèle d’exploitation retenu ne doit pas supposer implicitement des fonctions propres à un service cloud entièrement géré. Un pare-feu virtuel exige lui aussi une maintenance planifiée et des sauvegardes vérifiables.

Alertes de menace et autres changements

Alertes NDR sans isolation automatique

Les détections de NDR Essentials et de NDR Active Threat Intelligence peuvent déclencher une alerte sans isoler automatiquement l’appareil concerné du réseau.

La détection et la réaction sont ainsi plus nettement séparées. Cela peut aider lors de l’introduction de nouvelles sources de détection : on évalue d’abord la qualité des alertes, puis on définit les événements qui doivent provoquer un blocage. Notre article sur NDR Active Threat Intelligence explique les différences entre ces mécanismes.

Une simple alerte n’est toutefois utile que si quelqu’un la traite. Les responsabilités, les délais de réaction et la voie d’escalade doivent être définis. Il faut aussi vérifier séparément les actions de blocage toujours configurées dans Active Threat Response. Une modification du comportement des alertes ne signifie pas que toutes les mesures de protection ont été désactivées.

Listes de contenu des e-mails et catégories web

D’autres changements concernent les références fondées sur des identifiants pour les listes de contenu des e-mails et le versionnement des catégories web.

Dans les listes de contenu des e-mails, ou Content Control Lists, la référence est ainsi séparée du nom visible. Le nom aide les personnes à s’orienter, tandis qu’un identifiant stable assure une association sans ambiguïté. Le versionnement des catégories web concerne, quant à lui, la synchronisation en arrière-plan des définitions de catégories utilisées avec Sophos.

Ces changements sont moins visibles qu’une nouvelle interface, mais ont leur place dans un aperçu complet de cette version. Lors des modifications et restaurations de configuration, une politique doit continuer à référencer l’objet prévu. Pour le filtrage web, des pages de test connues comme autorisées ou bloquées devraient encore produire le résultat attendu après une mise à niveau.

eDirectory n’est plus pris en charge

Sophos Firewall v23 ne prend plus en charge le type de serveur eDirectory natif. Une connexion eDirectory encore présente empêche donc la mise à niveau. Parmi les solutions de remplacement figurent Entra ID SSO, Active Directory, RADIUS ou une connexion LDAP au serveur eDirectory existant.

Il faut distinguer l’authentification de la détection automatique des utilisateurs : LDAP peut authentifier les utilisateurs auprès de l’annuaire existant, mais ne remplace pas le SSO eDirectory natif. L’ancienne connexion eDirectory n’est pas non plus reprise lors de la restauration d’une sauvegarde ou de l’importation d’une configuration.

Notre guide Sophos Firewall : migrer eDirectory avant SFOS 23 décrit cette transition et ses conséquences pour les utilisateurs, les groupes et les services.

Conclusion

À mon avis, la REST API est l’une des nouveautés les plus utiles de Sophos Firewall v23. Elle simplifie les modifications récurrentes et fournit une bonne base pour analyser les configurations avec ses propres outils. Les API sont aussi précieuses pour l’analyse par IA : elles permettent de lire les règles et les objets de manière structurée, de les comparer et de repérer des anomalies. Les changements à effectuer restent une décision de l’administrateur. Mais la collecte et la préparation des informations peuvent déjà éviter beaucoup de travail manuel.

La nouvelle vue des règles de pare-feu me plaît également. La colonne indiquant le groupe, les détails librement sélectionnables et la mémorisation permanente de la vue rendent le travail plus agréable. Il est dommage que cette refonte n’ait pas aussi été appliquée aux règles NAT. Le regroupement et le clonage y manquent toujours, alors qu’ils seraient utiles pour créer et entretenir des configurations importantes.

J’aurais également aimé retrouver directement dans le pare-feu davantage de fonctions de Sophos Firewall Config Studio : la comparaison de plusieurs états de configuration, la fusion de modèles de configuration et des rapports qui affichent, pour les règles de pare-feu, NAT et TLS, les valeurs des objets référencés. Ces outils aident à comprendre et à préparer les changements. Sous cette forme, ils restent réservés à Config Studio, un produit distinct.

En revanche, je n’ai pas constaté d’amélioration notable de la vitesse lors de mon premier test. L’enregistrement d’une règle de pare-feu prend toujours plusieurs secondes. Pour une modification isolée, cela pèse peu. Mais lorsqu’on réorganise un ensemble de règles et qu’on en modifie beaucoup à la suite, ces attentes s’additionnent et interrompent constamment le travail. Les améliorations de l’interface sont bienvenues. Pour l’exploitation quotidienne, j’aimerais surtout que les opérations fréquentes soient plus rapides et que les règles de pare-feu et NAT se gèrent de manière plus cohérente.

FAQ

Sources

• Sophos Firewall v23 : annonce de la version, annonce du 28 septembre 2026.
• Sophos Firewall OS v23: Key New Features, guide technique des fonctionnalités, daté du 28 septembre 2026.
• Sophos Firewall v23 : retours et expériences, échanges en cours dans la communauté.