Sophos Firewall : Pas de CVE, mais truffé de bugs (v21.5 à v22)

3 mars 2026 • 27 min read

Table des matières

Quand on travaille actuellement dans le domaine des pare-feu, on doit généralement faire face à l’un de ces deux grands maux : soit on est stressé en permanence par des failles de sécurité critiques (les fameuses CVE, comme chez Fortinet en ce moment) et on passe ses nuits à patcher, soit ce sont les systèmes qui mettent d’innombrables bâtons dans les roues de nos opérations avec des firmwares instables et des bugs épuisants (comme chez Sophos en ce moment), nous empêchant de faire quoi que ce soit d’autre.

Au sein de mon entreprise, c’est exactement ce dernier cas qui s’applique — un stress tel que j’ai naturellement fini par l’emporter parfois à la maison. L’origine actuelle de tous nos maux se nomme : Sophos Firewall.

Alors que des concurrents comme Fortinet publient de nouveaux avis PSIRT presque chaque semaine, imposant aux administrateurs une cadence de correctifs incessante, c’est Sophos qui nous fait perdre un temps fou. Non pas avec des vulnérabilités qui font les gros titres, mais avec des bugs très basiques, mais critiques pour notre fonctionnement quotidien.

Avertissement, pour éviter de comparer des pommes et des oranges : Je suis parfaitement conscient que Fortinet est également aux prises avec d’énormes bugs (pensez au Conserve Mode et aux fuites de mémoire dans FortiOS 7.2/7.4/7.6) et que Sophos a lui aussi connu son lot de graves CVE par le passé. Toutefois, en pleine phase v21.5/v22, la réalité qui nous frappe, c’est celle-ci : d’un côté, ce sont des patchs CVE en continu ; de l’autre (chez Sophos), c’est une masse de travail opérationnel supplémentaire et inutile, causée par des problèmes de stabilité.

Contexte des versions (Pour faire court)

Juste pour être clair : je ne parle pas ici d’une vieille v19 couverte de poussière, mais bien des versions actuellement déployées chez beaucoup et considérées comme “à jour” :

SFOS 21.5 GA (02.06.2025) : Notes de mise à jour : SFOS 21.5
SFOS 21.5 MR2 (Build 323, 18.02.2026) : D’après les notes de version, c’est la version 21.5 la plus récente de cette période.
SFOS 22.0 GA (Décembre 2025) et le Re-Release v22 GA (Build 411, 20.01.2026) : Notes de mise à jour : SFOS 22.0

Il s’agit donc bien de versions GA (General Availability) et de Maintenance Releases, pas de “nightlies” incertaines.

Pour que la comparaison ne repose pas que sur du ressenti, faisons un rapide état des lieux.

Fortinet : Les CVE FortiOS depuis novembre 2025 (Au 26.02.2026)

Période couverte : du 01.11.2025 au 26.02.2026 (Date de publication). Source : Les avis Fortinet PSIRT (Aperçu PSIRT).

Je choisis délibérément de ne pas lister “tout Fortinet”, mais uniquement les avis concernant FortiOS/FortiGate sur cette période, car concrètement, c’est là qu’est la douleur : vous devez patcher, planifier, tester.

Le score CVSS ne fait pas tout, mais il souligne le contraste opérationnel : un risque Moyen avec un score de 5.x peut se planifier, mais un risque de 9.x bascule vite en mode “on arrête tout et on patche tout de suite”.

Publié le 10 février 2026 (Plusieurs alertes le même jour)

FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2) : Request smuggling dans l’interface graphique de FortiOS. Particulièrement désagréable parce que cela implique des “unlogged requests” (requêtes non journalisées).
FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7) : Problème de Format-String dans le mode CAPWAP Fast-Failover (déclenché via Admin/Config).
FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5) : Bypass de l’authentification LDAP dans l’Agentless VPN/FSSO (Solution de contournement souvent utilisée en pratique : désactiver l’unauthenticated bind sur le serveur LDAP).
FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3) : Bypass de SSL VPN Symlink Persistence Patch. Détail important : d’après l’avis, cela nécessite qu’il y ait eu au préalable une compromission via une autre vulnérabilité au niveau du système de fichiers.
FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8) : Policy Bypass dans le FSSO Terminal Services Agent (La correction repose sur une combinaison de la version de FortiOS et de la version minimale de l’Agent TS).

Janvier 2026

FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4), publié le 27.01.2026 : Administrative FortiCloud SSO Auth Bypass. Cet avis décrit également une exploitation “in the wild” et des mesures de contournement concrètes.
FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4), publié le 13.01.2026 : Heap-based buffer overflow dans le démon cw_acd (FortiOS/FortiSwitchManager).

Publié le 9 décembre 2025

FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1) : FortiCloud SSO Login Auth Bypass via un message SAML manipulé (Cette fonctionnalité n’est pas activée par défaut, mais elle est bien réelle sur le terrain).
FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3) : Insuffisance d’expiration de session dans le SSL VPN (Durée de vie de la session/Changement de mot de passe comme cas extrême).
FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3) : Des informations sensibles se retrouvent dans les Logs de l’API REST (si la journalisation de l’API REST est active).
FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9) : Une clé privée peut être lue par un Admin (Erreur de gestion des clés, réparable avec un patch).

Publié le 18 novembre 2025

FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9) : Stack buffer overflow dans le démon CAPWAP.
FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9) : Un autre Stack buffer overflow dans le démon CAPWAP.
FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8) : Trusted hosts Bypass via SSH (Cas extrême via la CLI).

Oui, ça fait beaucoup. Et oui, cela peut être géré par des processus (Fenêtres de patch, Staging, Change-Management, Fenêtres de maintenance).

Et puis il y a l’autre côté.

Sophos : Pas de grands titres, mais les opérations brûlent

Chez Sophos, on parle évidemment aussi de sécurité. Mais ce qui nous dévore littéralement notre temps, ce sont tout simplement les bugs.

Nous passons actuellement un temps démesuré dans l’entreprise parce que le pare-feu fait des siennes. Au point de se poser une question qui semble complètement absurde :

Qu’est-ce que je préfère : un pare-feu avec une faille de sécurité mais qui fonctionne de manière stable, ou un pare-feu sans grosse CVE qui refuse de redémarrer après un reboot ?

Ce n’est pas un débat théorique. C’est la réalité des opérations (Ops). C’est pourquoi j’en suis malheureusement presque venu à préférer une vulnérabilité théorique qui pourrait un jour être exploitée, plutôt que de voir la totalité du réseau d’un client paralysée pendant plusieurs heures à cause d’un simple bug.

Nos points de douleur actuels (Oui, tout à la fois)

Pour clarifier la situation : il ne s’agit là que des bugs auxquels nous avons été confrontés à de multiples reprises et sur divers systèmes au cours des derniers mois. C’est épuisant et frustrant quand la simple maintenance devient un projet à part entière. Surtout quand on doit encore se frotter au service support de Sophos, qui aime bien nous faire croire que nous sommes “le tout premier client au monde à subir exactement ce problème”. Eh bien non, ce n’est pas le cas.

Parfois, le pare-feu ne redémarre pas proprement après un reboot.
Le cluster HA s’effondre ou se comporte en mode “Split-Brain”.
Du jour au lendemain, la journalisation devient erratique (ou disparaît totalement).
Les certificats Let’s Encrypt ne se renouvellent pas tout seuls, vous obligeant à intervenir en pleine nuit.
Une interface a “disparu” ou n’est subitement plus visible dans la GUI.
Des disques SSD lâchent (problèmes matériels).
Le WebAdmin se met en grève : plus moyen de se connecter, la seule solution est souvent un redémarrage forcé.
Des interfaces s’évaporent littéralement de la configuration.
Le disque des logs sature, ce qui engendre des messages d’erreur ou l’arrêt net des services concernés.

Ce que dit la communauté (Vous n’êtes pas seuls !)

Si on jette un coup d’œil du côté de la communauté Sophos (début 2026), ce tableau alarmant concernant la qualité de la version v21.5 / v22 se confirme malheureusement. En plus de nos propres soucis, on constate chez d’autres utilisateurs l’apparition de “showstoppers” tout aussi effarants :

Profils SSL-VPN défectueux (v22.0 Build 411) : Des utilisateurs signalent qu’après la mise à niveau vers la toute dernière v22, la création de profils SSL-VPN est impossible. Certains ont dû recourir à un rollback vers la v21.5, la nouvelle mouture étant bien trop instable.
SNAT / Accès au serveur Web cassé (v22.0 Build 365) : Il y a des cas rapportés où, suite à la mise à jour, l’accès depuis l’extérieur aux serveurs web internes s’interrompt. Très souvent, le routage Internet entier flanche jusqu’à ce que l’on restaure manuellement l’option MASQ standard du SNAT.
Spam CLI / “Invalid rule id” : Dans la console, on assiste à un déferlement de messages d’avertissement du type “Invalid rule id or family for update”. (Il s’agit a priori “seulement” d’un problème d’affichage, mais cela sature inutilement les logs).

Ce qui est particulièrement amer, c’est que chacun de ces dysfonctionnements ne constitue pas seulement une gêne, c’est un risque majeur. Sans logs, vous avancez à l’aveugle. Si le HA vacille, vous perdez toute confiance dans le basculement (Failover). Si les certificats ne sont pas renouvelés, vous en êtes réduit à bricoler des solutions de contournement. Et ce sont précisément ces contournements qui font le lit des incidents de demain.

Les Bugs Sophos (v21.5 à v22) : au cœur de vos symptômes

Je mentionne volontairement ici les identifiants précis (NC-IDs) tirés des notes de mise à jour officielles ou de la liste des problèmes connus (Known Issues) afin que vous, en tant qu’admin, puissiez en vérifier la véracité.

Résumé : Symptôme -> Ce qu’en disent les Notes

Symptôme observé	Exemples tirés des Release Notes / Known Issues
Échec d’un démarrage ou d’un redémarrage propre	NC-151715, NC-152641, NC-123910
HA instable ou s’emballant lors d’un failover	NC-142962, NC-132291, NC-147307, NC-147739, NC-149039
Logs et rapports perdus ou imprévisibles	NC-158526, NC-160962, NC-157663, NC-169237, NC-135594, NC-175936, NC-170292, NC-166381
Problèmes liés à Let’s Encrypt et au WAF	NC-148937, NC-152022, NC-140663, NC-141062, NC-152540, NC-146082, NC-159041
Entra SSO, Captive Portal ou VPN Portal capricieux	NC-167126, NC-157635, NC-167130, NC-167128
Échec de connexion VPN/IPsec ou bris d’interopérabilité	NC-136352, NC-128116
Chutes de trafic sans cause claire dans les règles	NC-169842 (à envisager aussi : l’IPS/Snort suite à une MAJ)
Interface “disparue” (UI)	Problème connu : des interfaces au nom long de 10 chiffres ou plus disparaissent dans la vue WebAdmin

Une histoire vraie (et agaçante) sur le terrain

Le matin, vous vous installez pour faire ce que vous faites d’habitude : traiter les tickets, planifier les changements, consulter la supervision.

Puis, le pare-feu frappe à la porte sans même toquer.

Pas avec une alerte CVE, pas avec une “Critical Advisory”. Juste avec son lot quotidien de surprises.

Premier café, premier redémarrage et cette question en tête : Va-t-il vraiment repartir ?

Si tout se passe bien, il redémarre. Sinon, il finit quelque part entre “Failsafe” et “allumé, mais bloquant tout le trafic”. Et alors que vous vous demandez si vous devez vraiment brancher une console, le chapitre suivant s’ouvre.

Le cluster HA. Votre airbag. Et parfois, vous avez l’impression que l’airbag vient de s’ouvrir tout seul pendant que vous essayez simplement de vous garer.

Ensuite, les logs. On le sait tous : ce que l’on ne peut pas observer, on ne peut pas le contrôler. Et brusquement, des logs manquent, les rapports sont vides ou un service plante en silence. Vous restez planté là, à vous demander s’il s’agit d’un incident de sécurité, d’une erreur de remontée des données, ou des deux en même temps.

Puis arrive le bouquet final : le WAF, le Reverse Proxy et Let’s Encrypt.

Vous ne demandez rien d’extravagant. Vous espérez juste que les certificats se renouvellent et que vos sites ne hurlent pas au “connection refused” à 02h13 du matin.

Et comme si ça ne suffisait pas, une interface “disparaît”. Pas qu’elle soit vraiment désactivée, mais elle n’est plus visible dans la GUI. Le trafic passe peut-être toujours, mais vous êtes incapable de voir la configuration que vous avez désespérément besoin de déboguer.

À force, vous finissez par vous poser cette question totalement aberrante :

Qu’est-ce que je préfère : un pare-feu avec une faille de sécurité mais qui tourne sans faillir, ou un pare-feu propre de toute grosse CVE mais qui vient brûler de nouveaux trous dans mon emploi du temps opérationnel toutes les semaines ?

1) Boot, Reboot, Upgrade : “Il est vivant, mais il ne fait plus rien”

Un pare-feu qui refuse de redémarrer correctement après un boot n’est pas seulement une question d’“Uptime” (temps de disponibilité). C’est une journée perdue, accompagnée de gros risques, parce que dans ce genre de situation, on a tendance à tenter des choses que l’on ne ferait jamais en temps normal.

Quelques exemples tirés des Release Notes de la v21.5 :

Failsafe au redémarrage : NC-151715 (Firmware Management) : L’appareil auxiliaire bascule en Failsafe au moment du reboot ; échec du redémarrage.
Trafic figé post-Upgrade : NC-152641 (Firmware Management) : Après la mise à niveau (21.0 MR1 Build 237), le traitement du trafic est rompu (suite à des modifications de la SWAP Memory Config).
Kernel Panic : NC-123910 (Firewall) : Problème de kernel panic.

Il faut ajouter à cela un nouveau facteur introduit par la SFOS 22.0 : Sophos indique dans ses notes de mise à jour que la v22 apporte des changements architecturaux et que des actions manuelles supplémentaires pourraient être nécessaires dans certains cas rares. C’est exactement le genre de particularité d’upgrade qui devient un véritable fléau en phase d’exploitation.

2) Le cluster HA : L’airbag qui se déploie en plein stationnement

Le HA est censé être votre filet de sécurité. Et c’est bien pour cela que l’apparition de problèmes (“Edge Cases”) à ce niveau est si douloureuse.

Extraits des Release Notes de SFOS 21.5 :

Arrêt du HA Event Tracking lors de redémarrages simultanés : NC-142962 (HA).
Blocage de l’upload du firmware sur le dispositif Passif : NC-132291 (HA).
Le Failover entraîne un Restart Loop (boucle de redémarrage) : NC-147307 (HA) (Notes mentionnant explicitement, par exemple, le XGS 2300).
Échec de synchronisation après une coupure de courant : NC-147739 (HA).
Fluctuation du statut HA et Crash Dump sur le lien dédié : NC-149039 (HA).

3) Logging et Reporting : Quand on navigue à l’aveugle

C’est ici que l’on comprend pourquoi les “bugs” dépassent le cadre strict des “Opérations”. Quand le système de journalisation vacille, cela se transforme en un incident de sécurité majeur.

Extraits des Release Notes de SFOS 21.5 :

Le Logging/Reporting s’interrompt de façon aléatoire ; des coredumps fréquents de Garner : NC-158526 (Logging Framework).
Arrêt inopiné de Garner et de fwcm-heartbeatd : NC-160962 (Logging Framework).
Disparition totale des rapports après mise à jour : NC-157663 (Logging Framework).
Le Log Viewer perd des événements en raison d’une corruption de la base de données : NC-169237 (Logging Framework).
Corruption de descripteur de fichier (fd) Syslog, les données sont routées vers le mauvais FD : NC-135594 (Logging Framework).

De surcroît, la “Known Issues List” (KIL) de Sophos contient quelques cas qui pourrissent le quotidien :

Le Log Viewer n’affiche aucune donnée récente (active.db manquante) : NC-175936 (Logging Framework). Sur certains systèmes 21.5.1, le fichier active.db localisé dans /tmp/eventlogs/ peut être introuvable. Résultat : le Log Viewer est “gelé”, alors que le trafic et les mesures de sécurité sont toujours actifs. Le KIL indique que le défaut est résolu dans la v22 et qu’un correctif devrait voir le jour pour la 21.5 MR2.
Faux Positifs de type “advanced threat detected” en HA : NC-170292 (Logging Framework). En déploiement HA, Sophos Central est susceptible d’envoyer de fausses alertes incluant les logs bruts dans la description de l’incident. Le palliatif suggéré par le KIL : relancer le service Garner. (Réf. KBA : https://support.sophos.com/support/s/article/KBA-000043672)
ReportDB_v9 affichant un statut STOPPED (ce qui semble grave, mais ne l’est pas) : NC-166381 (Reporting). Après le passage en v21.0 GA ou supérieur, ce service se met en arrêt après un laps de temps bien précis. D’après le KIL, ce comportement est volontaire et n’a aucune conséquence sur les opérations, car il ne concerne que l’ancien système de reporting pré-v21.

S’ajoute à cela le fameux “Facteur Sophos Central” : Si vous vous servez de Central comme unique tableau de bord, une anomalie dans les logs vous pénalise doublement. En cas de dysfonctionnement du tunnel de log local (Garner/DB), la remontée vers Central Firewall Reporting (CFR) peut elle aussi s’arrêter ou rester en suspens. Et puisque CFR n’agit pas toujours en “temps réel”, dans le pire scénario, vous vous retrouvez non seulement démuni de vos logs locaux, mais vous perdez également l’unique vue centralisée censée vous épauler au quotidien.

4) WAF et Let’s Encrypt : Service au public, mais sans le drame s’il vous plaît

Si les certificats ne sont pas renouvelés et que le reverse proxy déraille, on ne parle plus d’un “petit bug”. Cela a des conséquences immédiates pour les clients.

Les Release Notes de SFOS 21.5 foisonnent de complications autour du couple WAF/Let’s Encrypt :

Échec de la génération des certificats Let’s Encrypt : NC-148937 (WAF).
Plantage des requêtes LE dû à l’absence de règle automatique (Auto-Firewall-Rule) : NC-152022 (WAF).
Redémarrages intempestifs du Reverse Proxy causés par une configuration LE invalide : NC-140663 (WAF).
L’ACME refuse de délivrer des certificats pour les adresses IP : NC-141062 (WAF).
Activation/désactivation impromptue des règles WAF : NC-152540 (WAF).

Mais il faut aussi aborder ces dysfonctionnements qui “ressemblent à des bugs, mais résultent d’un compromis de sécurité”. Par exemple (issu du KIL) :

Erreur 404 du WAF face aux slashs encodés (%2F) dans les URLs : NC-159041 (WAF). Dès lors qu’une de vos applications exploite des slashs encodés, Apache bloque la requête par défaut (La directive AllowEncodedSlashes est configurée sur No), générant ainsi une erreur 404 alors même que le backend connaît ce chemin. La raison ? Les slashs encodés sont capables de contourner certaines restrictions d’accès (l’exemple classique : .../something%2F..%2Fadmin). Détails : https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

Pour se faire une idée concrète de l’impact, il suffit de lire ce thread de la communauté, où un utilisateur explique qu’à la suite d’une mise à jour vers la 21.5.x, ses certificats auto-renouvelables s’étaient volatilisés, que le WAF ne démarrait plus et que les sites affichaient inlassablement un ERR_CONNECTION_REFUSED. La résolution ? Un nettoyage de fond en comble des “Web Protection Rules” et la suppression des CSR de LE corrompus afin de tout relancer. (Fil de discussion : WAF/Let’s Encrypt après mise à jour, ERR_CONNECTION_REFUSED).

Il arrive même que ce ne soit pas un “bug”, mais simplement une question de procédure : Sur le forum Sophos, plusieurs témoignages font état de Conditions d’Utilisation (Terms of Service) de Let’s Encrypt qui étaient notées expirées sur le WebAdmin et qu’il a fallu valider à nouveau. (Fil de discussion : Let’s Encrypt Terms of Service have expired).

Un autre classique des “Pièges de Mise à Jour” repéré dans le KIL : Le processus de mise à jour peut complètement s’effondrer si un certificat préexistant partage par hasard le même nom que l’un des certificats Let’s Encrypt qui viennent d’être introduits dans le CA Store (NC-146082).

5) “Il manque une Interface” (ou est-elle juste devenue invisible)

Voici l’exemple parfait du bug qui paraît très banal en lisant les Release Notes, mais qui, sur le terrain, vous force à avancer à tâtons.

Officiellement répertorié en tant que “Known Issue” :

Si une interface logique ou physique sous SFOS 21.5 GA ou ultérieur arbore un nom terminant par 10 chiffres ou plus (comme cité dans les Notes : VLAN_1234567890), l’interface physique devient subitement invisible dans l’interface WebAdmin via Réseau > Interfaces. S’il s’agit d’interfaces logiques, elles ne peuvent plus être déroulées. Point crucial à retenir : les Notes précisent que la fonctionnalité en soi n’est nullement impactée, c’est uniquement le rendu visuel dans la Console WebAdmin qui est touché.

Bilan intermédiaire (jusqu’ici) : Boot/Upgrade, HA, Logging/Reporting, WAF/Let’s Encrypt et même la GUI peuvent tour à tour vous mettre des bâtons dans les roues. À partir de maintenant, on entre dans des thématiques qui s’apparentent davantage à des “Détails Réseaux” purs, mais qui se révèlent tout aussi laborieuses au niveau opérationnel : le SSO via Entra, l’interopérabilité VPN ou encore d’apparentes pertes de trafic purement aléatoires.

6) Identité/SSO (Entra) et Captive Portal : Quand les accès deviennent imprévisibles

C’est la catégorie de bugs la plus sournoise à gérer opérationnellement : Le ressenti de l’utilisateur final sera un simple “mon compte déraille”, et le vôtre sera du type “ce n’est qu’un problème SSO”. La vraie cause se situe pourtant souvent du côté du firewall qui joue les intermédiaires.

Quelques cas ouverts signalés par le KIL si vous mixez avec du Microsoft Entra ID (Azure AD) :

Le Conditional Access n’est pas intégralement pris en charge avec Sophos Connect VPN : NC-167126 (Authentification). Passé le premier défi MFA lors de la première connexion, les contrôles du Conditional Access ne sont pas nécessairement reconduits lors de chaque connexion ultérieure. Selon le KIL, la politique ne s’appliquera à nouveau que si l’utilisateur prend l’initiative de se déconnecter manuellement via le Sophos Connect Client.
VPN SSO : Désaccords entre UPN et E-mail provoquant la rupture du Login : NC-157635 (Authentification). Si, dans Entra, l’adresse E-mail et l’UPN diffèrent, les utilisateurs parviennent au VPN Portal, mais sont bloqués s’ils tentent d’atteindre le portail SSL VPN ou IPsec. L’explication du KIL : le Header OAuth fournit l’adresse E-mail, qui est interprétée ensuite à tort comme étant l’UPN.
Captive Portal : La Règle impose le Groupe Principal pour les utilisateurs Entra SSO : NC-167130 (Authentification). L’accès internet n’aboutit que si le Groupe Principal est expressément défini dans la règle de Firewall Match (les groupes secondaires sont ignorés). Le KIL annonce un correctif dans les “prochaines maintenance releases”. Le contournement actuel : cibler directement le Groupe Principal ou opter pour des règles fondées sur l’utilisateur.
Apparition sporadique d’erreurs “no permission” sur Entra SSO : NC-167128 (Authentification). Un cas rencontré si les méthodes d’authentification Entra ID et On-Prem AD sont activées en parallèle (conflit de Token-Reuse). Les contournements proposés par le KIL : purger les cookies du navigateur web, déclencher un “force re-logon” dans le client Sophos Connect ou s’en tenir rigoureusement à un unique mode d’authentification.

7) Interopérabilité VPN/IPsec : Quand la mise à niveau achoppe face au partenaire distant

Nous allons évoquer ici deux thématiques KIL qui existaient avant la 21.5, mais dont la pertinence reste entière sur 21.5/v22 dès que des clients plus anciens ou des passerelles obsolètes sont en jeu :

Échec de montage du tunnel IPsec IKEv2 (Soucis de Fragmentation/PMTU) : NC-136352 (IPsec). Depuis la version 20.0 MR1, le profil standard IKEv2 engendre des paquets plus volumineux (en raison d’un plus grand nombre de champs par défaut), franchissant parfois le cap des 1500 octets. Si les paramètres de Fragmentation/PMTU le long du trajet sont médiocres (provoquant des rejets de fragments), le tunnel S2S refusera tout simplement de se monter. L’atténuation préconisée par le KIL : limiter le nombre de DH Groups (à un minimum de 4) sur le profil IPsec, ou configurer avec précision le(s) seul(s) groupe(s) exploité(s) de l’autre côté.
SSL VPN/OpenVPN 2.6.0 : Rupture de compatibilité avec les Clients en fin de vie ou l’UTM9 : NC-128116 (SSLVPN). Dès la version 20.0 MR1, OpenVPN est passé à la version 2.6.0. Conséquence directe, les connexions Site-to-site SSL VPN avec de vieilles versions SFOS (18.5 ou moins), avec les Clients Legacy-SSL-VPN (en fin de vie) ou les systèmes UTM9 se brisent. La recommandation du KIL est claire : mettre les deux terminaux à jour, migrer vers de l’IPsec/RED, ou, pour le trafic distant, s’orienter vers Sophos Connect ou les versions contemporaines d’OpenVPN.

8) Disparitions de Trafic non justifiées par une règle : L’étrange cas de l’Accurate ECN

Dès que du trafic semble s’évaporer “de façon aléatoire”, on se met naturellement en quête de problèmes dans les Règles, l’IPS, l’Inspection TLS ou le Routage. À cela s’ajoute un grand classique à l’issue de mises à jour de firmware : Le moteur IPS (Snort) et ses signatures, devenus plus intransigeants, bloquent sans pitié le trafic sain sans que rien ne l’indique distinctement dans les journaux. De longues heures sont alors perdues à ausculter le “Routage” ou les “Règles”, alors que le problème réside dans un simple affinage de politique ou de configuration (Tuning).

Mais attention, le KIL recèle une autre pépite redoutable si vous ne l’avez pas détectée au préalable :

Chutes de trafic liées à l’interprétation des Accurate ECN Bits : NC-169842 (Firewall). La fonction Accurate ECN altère certains bits TCP (ECE/CWR/NS) comme précisé dans la norme RFC 7560. Selon le KIL, le kernel assimile ce changement à un “reserved bit set” et jette systématiquement le trafic. Si l’on souhaite limiter cette investigation, il peut être judicieux de jeter un œil au profil du client final : En pratique, on relève le plus souvent cette configuration avec les noyaux Linux les plus récents, ou sur des postes Apple particulièrement prompts à recourir au protocole RFC 7560/Accurate ECN. (“mais pourquoi y’a-t-il seulement les MacBooks qui plantent ?”). La documentation RFC : https://www.rfc-editor.org/rfc/rfc7560

9) Re-Release v22 GA (Build 411) : Les motifs de sa nécessité

Le 20 janvier 2026, Sophos publiait un Re-Release de la version v22 GA sous le label Build 411 afin d’enrayer de prétendus “problèmes rares et isolés”. À la lecture de la liste, on jurerait pourtant y déceler un véritable florilège de “travaux superflus à traiter en pleine Change Window” (D’après un article de blog de la communauté Sophos relatif à ce Re-Release) :

NC-171003 : WebAdmin totalement inaccessible depuis une interface de type Bridge associée au filtrage VLAN.
NC-170987 : Spam récurrent sur la console CLI : “Invalid rule id or family for update”.
NC-170970 : Le trafic DNAT plante inévitablement dès qu’une règle DNAT est dotée d’une interface de sortie précise.
NC-171600 : Des widgets SSL/TLS accompagnés de données de Graphique de Sessions systématiquement erronées ou vides.
NC-172197 : Refus total d’implémentation de la moindre configuration SNMP.

Le billet de blog en question : v22 GA re-release (Build 411) is now available.

Les dégâts concrets : Les bugs font flamber la facture Sécurité

Au-delà de la question de savoir si un bug est plus nocif qu’une CVE ou inversement, l’enjeu crucial se situe ailleurs.

La réalité, c’est que lorsque vos opérations sont chancelantes, la sécurité se détériore immanquablement.

Les mises à niveau sont différées de peur de s’exposer à un prochain bug de régression.
De nombreuses fonctionnalités se retrouvent désactivées (“on n’en a pas tant besoin que ça”) car sources de tracas.
On perd l’observabilité globale (via les Logs) et par conséquent toute rapidité de réaction.
Au lieu de mettre ce temps à profit pour de la segmentation, l’établissement de sauvegardes ou la rédaction de règles impeccables, on gaspille son temps à jouer aux pompiers.

Il existe un paramètre très souvent sous-évalué en milieu opérationnel : le Time-to-Resolution. Face à une CVE, l’Advisory inclut la plupart du temps un contournement et un correctif (Mitigation et Fix). Lors d’un bug majeur, la charge de prouver qu’il y a anomalie pèse directement sur les épaules de l’Admin : on enchaîne le tcpdump, la scrutation des logs CTR, ou bien l’export de Shell avancé (“Avez-vous pensé à redémarrer ?”) - le tout alors que l’infrastructure de production est dans le rouge. L’Admin se retrouve ensuite embourbé dans le long manège du support : forcer les escalades de ticket et espérer avec angoisse l’arrivée d’un Hotfix ou l’attente incertaine de la prochaine Maintenance Release. Au détriment, bien sûr, du précieux temps d’Opération que vous n’aviez jamais anticipé.

Et c’est précisément ce qui explique pourquoi l’interrogation “Vaut-il mieux une vulnérabilité mais un système qui tient la route ?” - certes excusable en soi - est fondamentalement mal posée :

La vulnérabilité seule n’incarne pas un péril de sécurité absolu. “Un Firewall instable”, lui aussi, se révèle être un redoutable problème de sécurité.

Enseignements tirés (Pour que tout ne parte pas en vrille)

Nous avons sélectionné un panel de principes salvateurs pour contenir cette frénésie sans pour autant se retrouver à recréer la roue toutes les semaines :

Upgrade-Preflight (L’avant-mise à jour)

Un traitement des Backups équivalent aux procédures Restore : N’omettez pas d’exporter votre configuration, garantissez vos sauvegardes en environnement déconnecté, et assurez-vous de maîtriser le Restore au moins par le biais d’un test in-situ.
Un statut HA “vert” ne suffit pas – testez obligatoirement le Failover ! Dans notre cas, la GUI affirmait qu’aussi bien la synchronisation (Sync ok) que le Heartbeat étaient irréprochables. Et pourtant, en temps voulu, l’Appliance Auxiliaire (Auxiliary) n’a jamais pu basculer de façon propre lors du Failover. Par les temps qui courent, s’en remettre avec foi à une simple encoche verte via le WebAdmin ne confère aucune assurance de succès pour votre Change-Window.
Examen minutieux de la Logistique : Le dispositif de réception externe Syslog/Collector doit accuser réception, le système ne doit pas comporter de vides, et les paramètres Time/NTP doivent correspondre.
Validation scrupuleuse des Certificats et WAF : Assurez un suivi assidu des dates de péremption de tous vos certificats, effectuez la validation des Let’s Encrypt, et veillez impérativement à toujours détenir un Certificat Back-up (Fallback).
Procéder à d’authentiques tests du SSO/VPN : L’authentification par l’interface Entra Login, les passages par le Captive Portal, ainsi que les dispositifs Sophos Connect, SSL VPN, ou même l’IPsec S2S (avec la procédure Failover inhérente), exigent la constitution de véritables cas de tests exhaustifs et personnalisés.
Être paré à un scénario Break-Glass : Toujours disposer d’un canal “Out-of-band” via Console, maîtriser les profils d’Administrateurs Locaux, et entreposer des images firmware fiables au cas où une procédure Rollback viendrait s’avérer nécessaire.
Ne pas minimiser (et, a fortiori, ne pas surévaluer) les attraits du Dual-Boot : Sophos arbore une dualité sur ses partitions firmware. Lorsqu’une mise à jour avorte, il est fréquent que le Rollback sur la 21.5 puisse se résumer à un Reboot agrémenté d’une désignation orientée sur l’autre partition. Toutefois : certaines circonstances mènent à ce que la seconde partition, à son tour, peine à redémarrer normalement. Un Reimage de fond en comble est parfois l’ultime bouée (Et n’omettez pas de noter la propension qu’a le support à le requérir au quart de tour). Sans compter que, malgré le succès du Reimage, la source réelle des dysfonctionnements initiaux est souvent laissée intacte.

Pendant le déploiement de la Mise à Jour (en situation HA)

Il est préconisé de prioriser le poste Passif/Secondaire, d’aborder en second lieu le test du Failover, et d’en venir in fine au poste Actif.
Assortir chaque manœuvre d’une étape minutieuse de validation : Trafic, VPN, DNS, Logging, WAF/Reverse Proxy.

Exploitation Quotidienne et Maintenance Opérationnelle

Ne vous cantonnez pas à “paramétrer le HA”, mettez-le régulièrement au défi : Instaurez des routines d’exercice du Failover ainsi que des balises formelles stipulant dans quels cadres restreints scinder votre Cluster.
Prenez soin de traiter votre dispositif Logging au même titre qu’un produit vital à part entière : Implémentez des systèmes d’alarmes traquant les absences de logs et veillez sur la Service Health. Préparez impérativement une méthode secourue d’Exportation en urgence (via CLI), spécialement si l’interface utilisateur flanche.
Suivi scrupuleux et actif des Certificats : Ne vous laissez pas leurrer. L’acte du Renewal ne doit aucunement être traité comme du luxe ou du superflu (“nice to have”) : c’est un pur risque d’exploitation métier.
Le rôle informatif – et non de KPI – que doit endosser le Health Check : À compter de la v22, Sophos a inauguré une rubrique désignée “Health Check” (Détaillé intégralement au sein de mon article propre Aperçu Intégral Sophos Firewall v22 Health Check ). Abordée dans la veine d’un simple guide de “Best-Practice”, cette fonctionnalité relève de la pertinence. Elle souffre pourtant d’une dimension faussée où il est aisé d’avoir le sentiment “qu’il suffit d’appuyer sur tel interrupteur écologique pour verdir le profil complet”. Un exemple révélateur sur le terrain : nombre d’opérateurs engagent la mise en route exclusive du Login-Disclaimer pour avoir la certitude d’arborer l’étiquette vertueux dans la marge “Health Check”. J’estime pour ma part qu’il fait particulièrement abstraction des fondements opérationnels de l’infra (par ex : la “Logging/Reporting-DB” fait-elle toujours preuve de santé ? Et, surtout : que dire à propos de la vitalité effective des SSD ?) – ceci étant devenu spécialement crucial au vu du grand nombre de pannes de Storage rapportées sur diverses appliances avec une précocité hors-norme.

Conclusion : Quand l’Outil devient le Péril

En définitive, nous sommes logés à la même enseigne. Nous avons à notre charge la gérance d’infrastructures névralgiques et devrions pouvoir faire aveuglément confiance à des outils, lesquels ont avant tout vocation à endiguer les désastres potentiels – sans jamais avoir la latitude ou l’indécence d’en être le moteur intrinsèque. Compte tenu de la médiocrité actuelle caractérisant ces versions firmware (v21.5 / v22), Sophos démontre clairement qu’une profonde refonte de ses propres pratiques et un rigoureux mea-culpa à l’endroit de son produit de base doivent devenir primordiaux. Face à de tels déploiements, la conviction rassurante quant aux “Releases à visées Stables” a de fait subi des blessures irrémédiables dans nos milieux comme auprès de l’impressionnante cohorte de ses usagers actifs en communauté.

Je ne serai pas prêt à valider le postulat d’accepter l’idée d’un choix simpliste où je m’efforcerais de m’acclimater à une barrière “qui est soit performante en matière de sécurité, soit à un degré qualitatif irréprochable au sein de sa Stabilité Opérationnelle”. Je formule non pas un souhait - mais j’établis ce que “j’exige et ce dont je nécessite” : Un Firewall honorant l’un comme l’autre de manière indivisible.

Tant et aussi longtemps que Sophos n’aura pas parvenu à éradiquer ces intolérables déficiences avec l’assurance attendue par sa profession de foi en la matière, à nos yeux de professionnels des opérations, un unique impératif demeure légitime et intangible : Se révéler à l’avenir encore bien plus assidu, méthodique et perspicace en s’assujettissant à notre propre discipline sans prêter ni oreilles ni laxisme démesurés aux attrayantes mentions de voyants affichant béatement leurs couleurs vertes rassurantes sur des fenêtres UI.

Jusqu’à la prochaine fois,
Joe