Sophos Firewall : bonnes pratiques de sécurité réseau

Pendant longtemps, les pare-feux étaient l’endroit où l’on bloquait les attaques. Aujourd’hui, ils font eux-mêmes partie des cibles les plus attractives. C’est logique : un pare-feu occupe une position privilégiée entre Internet, les réseaux de sites, les services cloud, les accès VPN et les applications internes. Celui qui trouve ici une vulnérabilité, un mot de passe faible ou une mauvaise configuration n’est plus devant la porte, mais souvent déjà au milieu du bâtiment.

C’est pourquoi il ne suffit plus de considérer un pare-feu comme un simple moteur de règles Allow et Deny. La sécurité réseau moderne repose sur trois piliers : durcissement, protection ainsi que détection et réponse. Il faut réduire la surface d’attaque avant l’attaque, bloquer proprement pendant l’attaque, puis identifier rapidement ce qui s’est passé.

J’accompagne depuis de nombreuses années des environnements Sophos Firewall de tailles et de secteurs très différents. Les recommandations qui suivent ne sont donc pas une liste théorique de fonctionnalités, mais ce qui a régulièrement fait ses preuves dans de vrais environnements clients, migrations, audits et cas de support.

Pourquoi les pare-feux sont autant ciblés

Un pare-feu est une cible intéressante pour les attaquants parce qu’il est exposé, privilégié et souvent critique pour l’entreprise. S’y ajoute un autre point : beaucoup d’environnements exploitent des pare-feux, portails VPN ou accès de gestion à distance pendant des années. Tous ne sont pas correctement patchés, toutes les surfaces de gestion ne sont pas réellement isolées et toutes les connexions ne sont pas protégées par une authentification multi-facteur.

Dans la pratique, trois causes récurrentes apparaissent surtout dans les attaques réussies :

• Vulnérabilités dans les pare-feux et systèmes edge, en particulier lorsque les correctifs sont appliqués tardivement ou pas du tout.
• Identifiants compromis et attaques d’identité, souvent sans MFA ou avec une configuration MFA faible. Le Sophos Active Adversary Report 2026 cite les causes liées à l’identité comme root cause dans 67.32 % des cas étudiés.
• Systèmes exposés, par exemple RDP, portails VPN, User Portals ou interfaces d’administration directement accessibles depuis Internet.

L’idée centrale est la suivante : beaucoup d’attaques ne sont plus aujourd’hui des « intrusions » spectaculaires. Très souvent, les attaquants se connectent simplement. Lorsqu’un compte utilisateur, un mot de passe admin ou un accès VPN est compromis, la première étape ressemble d’abord, pour le pare-feu, à une utilisation légitime.

Les trois piliers de la sécurité réseau moderne

Sophos décrit la protection des réseaux modernes comme un spectre allant du proactif au réactif :

1. Hardening : réduire la surface d’attaque, supprimer les systèmes obsolètes, utiliser des produits sécurisés, vérifier les configurations, restreindre les accès.
2. Protection : bloquer les attaques, contrôler le trafic chiffré, utiliser intelligemment Web, IPS, Zero-Day et Application Control.
3. Detection and Response : détecter les anomalies, isoler les appareils compromis, corréler les données de menace et réagir automatiquement.

De nombreux pare-feux sont traditionnellement forts dans le deuxième pilier. Ils bloquent le trafic, inspectent les paquets, reconnaissent des schémas connus et appliquent les policies. C’est important, mais ce n’est plus suffisant. Si le pare-feu lui-même est mal configuré, si Remote Access fonctionne sans MFA ou si un système non patché reste en production, on a un problème structurel qu’aucune règle IPS isolée ne peut résoudre proprement.

Mon expérience montre que les meilleurs résultats ne viennent pas d’une fonction magique, mais d’une configuration de base propre, de revues régulières et d’un pare-feu intégré au processus de sécurité global.

Pilier 1 : hardening avant l’attaque

Le hardening est la partie du travail de sécurité qui reçoit rarement des applaudissements, mais qui fait la différence en cas d’incident. Il s’agit de réduire la surface d’attaque, les anciens systèmes, les chemins de gestion ouverts et la dépendance aux réactions manuelles.

Réduire l’infrastructure et supprimer les anciens systèmes

Le moyen le plus simple de réduire une surface d’attaque est parfois le plus inconfortable : éteindre des choses. Chaque ancienne appliance, service VPN oublié, portail de gestion ou serveur qui n’est plus supporté constitue un point d’attaque supplémentaire. Les systèmes situés en bordure du réseau ou qui permettent indirectement un accès privilégié aux réseaux internes sont particulièrement critiques.

Pour les admins Sophos Firewall, cela signifie concrètement :

• Vérifier régulièrement quels pare-feux, REDs, passerelles VPN, contrôleurs WLAN, reverse proxies et composants Remote Access sont encore en production.
• Retirer les systèmes end-of-life ou end-of-support des positions privilégiées.
• Consolider les fonctions lorsque cela réduit la complexité : firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting et central management doivent être alignés aussi proprement que possible.
• Documenter quels services doivent réellement être accessibles depuis Internet.

L’objectif n’est pas de concentrer le plus de fonctions possible dans un produit. L’objectif est d’éviter les angles morts hérités. Une infrastructure petite, actuelle et bien contrôlée est presque toujours plus sûre qu’un environnement vaste, historiquement développé, avec de nombreuses exceptions du type « cela a toujours été comme ça ».

Sécuriser rigoureusement l’accès de gestion

L’une des bonnes pratiques les plus importantes est simple : la Web Admin Console et le User Portal ne devraient pas être inutilement accessibles depuis le WAN. Si l’administration à distance est nécessaire, elle devrait passer par Sophos Central, un réseau de gestion dédié, ZTNA ou un autre chemin contrôlé.

Dans les environnements clients, je constate régulièrement que le problème n’est pas la technique d’attaque la plus complexe, mais un ancien accès admin, un portail historiquement développé ou une exception « temporaire » qui n’a jamais été supprimée. Ces points doivent précisément faire partie d’une revue régulière du pare-feu.

Les points suivants devraient être vérifiés dans chaque environnement Sophos Firewall :

• Activer MFA pour les administrateurs, en particulier pour l’admin par défaut et tous les comptes disposant de droits étendus.
• Imposer MFA pour les connexions VPN et portails si ces accès sont encore utilisés.
• Éviter l’accès WAN à l’Admin Console et au User Portal ou le limiter fortement à des réseaux sources dédiés.
• Configurer des règles de mots de passe solides pour les utilisateurs et administrateurs.
• Sécuriser SSH, idéalement avec une authentification par clé publique et sans large exposition WAN.
• Activer les sauvegardes centrales et protéger leur accès, car les sauvegardes de configuration peuvent contenir des informations sensibles.
• Activer les notifications et le logging afin que les événements de sécurité ne disparaissent pas dans l’exploitation quotidienne.

Le point des sauvegardes est souvent sous-estimé. Une sauvegarde de pare-feu ne contient pas seulement des paramètres anodins, mais des informations sur les réseaux, règles, certificats, VPNs et structures internes. Les sauvegardes doivent donc être chiffrées, stockées de manière contrôlée et testées régulièrement.

Définir consciemment Device Access et Local Service ACL

Lorsqu’on parle d’accès WAN, il faut parler concrètement, sur Sophos Firewall, de Device Access et de Local Service ACL. La matrice Device Access définit par zone quels services locaux du pare-feu sont accessibles : HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, portails VPN et autres services.

La bonne pratique est très simple, mais efficace : depuis la zone WAN, seul ce qui est réellement nécessaire devrait être accessible. L’accès admin, SSH et le User Portal n’ont pas leur place largement exposés sur Internet. Si des exceptions sont nécessaires, elles devraient être limitées via des Local Service ACL Exception Rules à des adresses IP sources ou réseaux de gestion précis.

Règles pays comme protection minimale

Lorsque des adresses IP sources fixes ne sont pas réalistes, je recommande au minimum de travailler avec des règles pays. Un accès limité à quelques pays pertinents reste nettement meilleur qu’une accessibilité mondiale. On peut aussi bloquer les pays avec lesquels l’entreprise n’a aucun lien et où les collaborateurs ou admins ne se trouvent généralement pas. Ce n’est pas un remplacement de MFA, de rôles forts et d’ACL propres, mais cela réduit le bruit inutile et de nombreuses tentatives automatisées.

De mon point de vue, c’est l’un des premiers points de chaque revue de pare-feu. Beaucoup de configurations risquées ne proviennent pas d’une mauvaise intention, mais d’un service ouvert brièvement pour une migration, un cas de support ou un test, puis jamais refermé. Ce sont exactement ces détails qui distinguent un pare-feu qui fonctionne simplement d’un pare-feu exploité proprement.

Vérifier Login Security et les rôles admin

MFA est important, mais la couche de connexion ne se limite pas à un deuxième facteur. Les administrateurs devraient utiliser des comptes personnels et traçables, et ne pas travailler durablement avec un compte full admin partagé. Les droits basés sur les rôles aident à séparer les accès support, reporting ou helpdesk de l’administration réelle du pare-feu.

Il faut aussi limiter les tentatives de connexion échouées, terminer proprement les sessions et restreindre les accès admin à des réseaux définis. Un login disclaimer peut être utile juridiquement dans certains environnements, mais il ne remplace pas les contrôles techniques. Les politiques de mots de passe fortes, les sessions inactives courtes, la protection brute-force et le least privilege sont plus importants.

Éviter la fatigue des patchs : les Hotfixes doivent agir vite

Le patching fait partie de ces sujets où théorie et pratique sont très éloignées. Bien sûr, chaque admin sait que les mises à jour firmware sont importantes. Dans la réalité, elles signifient fenêtres de maintenance, analyse de risque, planification HA, communication avec les départements métier et parfois downtime. Cela mène à la patch fatigue : les mises à jour sont repoussées parce qu’elles demandent de l’effort.

C’est précisément là que le facteur temps devient dangereux. Les attaques d’identité sont désormais la root cause dominante, mais l’exploitation de vulnérabilités reste un vecteur réel, en particulier pour les systèmes edge comme les pare-feux, VPNs et autres services proches d’Internet. Le Sophos Active Adversary Report 2026 cite par exemple CVE-2024-40766 dans SonicOS, visible dans une grande partie des cas d’exploitation confirmés du jeu de données. En même temps, le délai médian entre l’advisory ou patch du fabricant et l’exploitation observée était de 322 jours. Le signal est clair : la patch fatigue n’est pas un problème d’exploitation abstrait, mais une fenêtre d’attaque.

Sophos Firewall franchit ici une étape importante : les Automated Hotfixes permettent des live patches de sécurité sans fenêtre de maintenance classique. Pour les admins, c’est très précieux, car l’effet de protection critique n’attend pas la prochaine fenêtre disponible.

Cela dit, les Hotfixes ne remplacent pas une stratégie de mise à jour propre. Ils ferment la fenêtre dangereuse entre la découverte d’une vulnérabilité et la mise à jour firmware régulière. La bonne pratique est donc :

• Laisser les Hotfixes activés.
• Vérifier régulièrement les versions firmware et documenter la préparation des mises à jour firmware.
• Lire à l’avance les chemins de mise à niveau et la compatibilité.
• Préparer les sauvegardes et un plan de rollback.
• Planifier séparément les clusters HA et sites distants.

Ne pas traiter le VPN comme une preuve de confiance

Remote Access VPN a été le standard pendant des années. Le problème : le VPN classique pense souvent en réseaux, pas en applications. Une connexion réussie place déjà l’utilisateur dans une zone de confiance dans beaucoup d’environnements. Si l’appareil est compromis ou si les identifiants ont été volés, un attaquant peut se déplacer à partir de là.

Zero Trust Network Access (ZTNA) ne résout pas ce problème par magie, mais par un meilleur principe : Trust nothing, verify everything. L’accès n’est pas accordé globalement à un réseau, mais évalué par utilisateur, appareil, état et application. Un appareil doit être sain et compliant, l’identité doit être vérifiée et la policy décide de manière granulaire quelle application est accessible.

ZTNA n’est pas automatiquement un choix Sophos

Le point important est le suivant : ZTNA n’est pas une décision qui doit automatiquement signifier Sophos ZTNA. Selon l’environnement, des fournisseurs spécialisés ZTNA, SSE ou SASE peuvent être plus avancés fonctionnellement, offrir de meilleures intégrations ou mieux correspondre à l’organisation. Ce qui compte n’est pas le nom du fournisseur, mais l’interaction propre entre identité, état de l’appareil, accès applicatif, logging et exploitation.

C’est aussi ma position générale dans les projets Sophos : je ne choisis pas automatiquement Sophos pour chaque sujet. Si une solution tierce pour ZTNA, SSE, Threat Intelligence, SIEM ou NDR convient mieux techniquement, c’est la meilleure recommandation. Une bonne architecture de sécurité ne naît pas d’une dépendance maximale à un fournisseur, mais de composants bien intégrés avec des responsabilités claires.

Dans les environnements purement Sophos, l’intégration peut malgré tout être intéressante, car ZTNA, Endpoint, Firewall et Sophos Central peuvent être utilisés ensemble. Un appareil compromis ou non conforme peut perdre l’accès sans qu’un admin doive d’abord reconstruire manuellement des règles de pare-feu. Il vaut aussi la peine de regarder le ZTNA Gateway sur Sophos Firewall. Dans les environnements mixtes ou plus grands, il faut toutefois comparer consciemment et ne pas choisir automatiquement le fabricant du pare-feu comme plateforme ZTNA.

Lorsqu’un environnement repose encore fortement sur SSL VPN ou IPsec Remote Access, il faut au minimum vérifier ces points :

• Imposer MFA pour chaque accès Remote Access.
• Supprimer les utilisateurs VPN anciens ou inutilisés.
• Contrôler l’import de groupes depuis AD ou Entra ID afin que Remote Access ne soit pas activé involontairement.
• Réduire Split-Tunnel, réseaux autorisés et droits au minimum.
• Planifier une migration progressive vers une solution ZTNA, SSE ou SASE adaptée, en particulier pour les applications web internes, RDP, SSH, portails d’administration et applications métier.

Segmenter contre le lateral movement

Lorsque des attaquants entrent avec des identifiants valides ou par un service exposé, la segmentation interne décide jusqu’où ils peuvent aller. Un pare-feu ne devrait donc pas seulement être une passerelle périmétrique, mais séparer proprement les zones internes : utilisateurs, serveurs, management, IoT, réseau invité, production, backup et systèmes particulièrement critiques ne doivent pas être placés aveuglément dans le même modèle de confiance.

Concrètement, cela signifie construire des VLANs et zones non seulement pour l’ordre, mais les protéger avec de vraies règles de pare-feu. Entre réseaux utilisateurs et serveurs, seules les applications nécessaires devraient être autorisées. Les accès de gestion appartiennent à des réseaux admin dédiés. Les réseaux IoT et imprimantes ne devraient pas communiquer librement avec les serveurs. Backups et domain controllers méritent des règles particulièrement restrictives et un bon logging.

Le lien avec l’idée « les attaquants se connectent » se referme ici. Si un compte compromis a accès à une application, mais pas à tout le réseau, un incident ne devient pas automatiquement une compromission complète.

Dans les nouveaux projets, je planifie donc la segmentation le plus tôt possible. Elle reste possible après coup, mais devient nettement plus pénible, car il faut alors démêler applications, exceptions et dépendances historiques.

Rendre les mauvaises configurations visibles

Un pare-feu peut être techniquement très puissant et devenir dangereux à cause d’une mauvaise configuration. Des règles trop larges, des objets “Any”, une authentification faible, des policies IPS manquantes, des mises à jour de patterns désactivées ou des portails ouverts sont des exemples typiques. La difficulté est que dans des environnements qui ont grandi avec le temps, ces risques ne se voient pas toujours immédiatement.

Le Sophos Firewall Health Check répond exactement à ce problème. Il vérifie des dizaines de paramètres par rapport aux bonnes pratiques et benchmarks et montre dans le Control Center où des configurations sont risquées ou s’écartent des standards recommandés. Les résultats sont priorisés par risque, mènent directement aux paramètres concernés et peuvent être corrigés ou consciemment ignorés selon la situation.

Le Health Check est particulièrement utile pour des processus d’exploitation récurrents :

• après un nouveau rollout de pare-feu,
• après de grands changements de règles,
• avant et après des mises à jour firmware,
• avant des audits,
• après des migrations depuis un ancien matériel,
• comme contrôle trimestriel régulier.

Il faut toutefois garder un point à l’esprit : un Health Check ne remplace pas le jugement des admins. Toutes les recommandations ne conviennent pas à chaque environnement. Certains points ont des raisons de conformité ou d’exploitation, d’autres sont de véritables failles de sécurité. L’essentiel est d’évaluer consciemment les écarts et de ne pas les laisser grandir sans visibilité.

De mon point de vue, le Health Check est surtout fort comme outil d’exploitation continu. Il n’est pas seulement utile pour le premier go-live, mais aussi comme point d’entrée pour les revues trimestrielles, la préparation d’audits et le nettoyage d’anciens jeux de règles.

Secure by Design : durcir le pare-feu lui-même

De mon point de vue, il ne faut pas seulement des produits de sécurité, mais des produits de sécurité eux-mêmes sûrs. La différence est importante. Un pare-feu ne doit pas seulement bloquer les attaques contre d’autres systèmes, il doit aussi être durci contre les attaques qui le visent.

Avec Sophos Firewall, cela comprend plusieurs niveaux :

• Kernel durci et architecture modernisée : la nouvelle architecture Xstream s’appuie davantage sur l’isolation, la modularisation, la conteneurisation et la séparation des privilèges. Cela réduit certaines classes de vulnérabilités et limite les impacts grâce à une meilleure isolation. Des mitigations contre les failles side-channel et CPU s’y ajoutent. Cela rend la plateforme plus robuste, mais pas immunisée contre les vulnérabilités.
• Automated Hotfixes : les corrections de sécurité peuvent être distribuées très rapidement et sans fenêtre de maintenance classique.
• Remote Integrity Monitoring : le Sophos XDR Linux Sensor intégré peut surveiller l’intégrité du système en temps réel, par exemple les changements de configuration non autorisés, Rule Exports, exécutions suspectes ou File Tampering. Cela n’a de valeur que si la fonction est activée, licenciée, connectée et réellement surveillée en exploitation.
• Gestion Central sécurisée : l’administration peut passer par Sophos Central sans exposer largement les ports de gestion sur Internet.
• Health Check : les configurations risquées deviennent directement visibles.
• Sauvegardes chiffrées : les données de configuration sont transmises et stockées de manière protégée.

Sophos mise en outre sur une surveillance proactive de la base de pare-feux installés. La télémétrie issue des pare-feux peut aider à détecter plus tôt des indices d’attaque ou de manipulation. Lorsqu’un schéma devient visible, Sophos peut soutenir spécifiquement clients ou partenaires et déployer très rapidement des Hotfixes à grande échelle.

Ces points sont moins spectaculaires au quotidien qu’une nouvelle règle de pare-feu ou une attaque bloquée dans le log. À long terme, ils sont pourtant déterminants. Un produit durci réduit la probabilité que le pare-feu devienne lui-même le point d’entrée. Mais il ne remplace ni un processus de patch propre, ni le monitoring, ni une revue régulière de configuration.

Ce qu’il faut attendre d’un fabricant de pare-feu

Secure by Design n’est pas seulement une propriété produit, mais aussi une question de fabricant. Les clients doivent attendre des fabricants qu’ils traitent les vulnérabilités de manière transparente, communiquent clairement les informations de lifecycle, déploient rapidement les correctifs de sécurité et construisent leurs produits de manière à rendre visibles le plus tôt possible les mauvaises configurations et composants compromis.

La responsabilité est partagée. Les fabricants doivent livrer des produits sûrs et réagir de manière transparente. Les clients doivent appliquer les mises à jour, remplacer les systèmes EOL, utiliser MFA et vérifier régulièrement l’exploitation. Les deux vont ensemble.

Pilier 2 : Protection pendant l’attaque

Le hardening est la base. Ensuite, le pare-feu doit continuer à faire ce pour quoi il est utilisé : contrôler le trafic et bloquer les attaques. Avec Sophos Firewall, cela inclut notamment IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection et Threat Intelligence Feeds.

Sophos s’appuie fortement sur l’architecture Xstream. Le trafic de confiance peut être traité plus efficacement, les tâches gourmandes comme les opérations crypto passent par des chemins optimisés, et il reste plus de réserve de performance pour le trafic à risque plus élevé, comme Deep Packet Inspection, TLS Inspection et Zero-Day Protection.

TLS Inspection est un bon exemple de l’équilibre entre sécurité et exploitation. Sans déchiffrement, une grande partie du trafic moderne reste invisible. Avec des règles TLS mal planifiées, on crée en revanche des cas de support, des problèmes de certificats ou des goulets d’étranglement de performance. La bonne pratique n’est donc pas de « tout déchiffrer aveuglément », mais de classifier proprement :

• commencer par les groupes d’utilisateurs et serveurs critiques,
• exclure proprement banking, health, privacy et les catégories problématiques connues,
• tester les pages de blocage et d’avertissement,
• documenter la distribution des certificats,
• évaluer activement les logs.

Ma recommandation est de ne pas lancer TLS Inspection comme un projet tout ou rien. Un rollout propre avec groupes d’utilisateurs clairs, exceptions, fenêtres de test et analyse des logs est préférable. La visibilité augmente sans submerger le helpdesk dès le premier jour.

Les Threat Feeds font aussi partie de cette zone de protection. De tels feeds aident à bloquer directement à la frontière réseau des IPs, domaines ou URLs malveillants connus. Dans les versions récentes de Sophos Firewall, ils sont nettement mieux intégrés à Active Threat Response et aux mécanismes de protection.

Les Threat Feeds deviennent particulièrement intéressants lorsqu’on n’utilise pas seulement des listes génériques, mais des feeds tiers curatés avec du contexte actuel. Un exemple est Cybora.io, où des IPs et domaines malveillants provenant de différentes sources et de télémétrie de pare-feux sont réunis en feeds exploitables. J’ai décrit plus en détail comment utiliser de tels feeds sur les pare-feux dans l’article Threat Intelligence Feeds pour pare-feu.

Ici aussi, les Threat Feeds doivent être testés et observés. Des feeds trop agressifs, des processus d’allowlist manquants ou des responsabilités floues peuvent bloquer du trafic légitime et causer plus de dommages que de bénéfices en exploitation. De bons feeds ne remplacent pas une revue de règles, ils constituent un composant supplémentaire avec son propre tuning.

Il ne faut pas non plus oublier les durcissements SFOS classiques : Spoof Protection, paramètres DoS appropriés et Geo-IP-Blocking peuvent réduire les accès simples, bruyants ou manifestement indésirables. Cela ne remplace pas une policy propre, mais retire du bruit inutile au pare-feu et bloque des chemins d’attaque qui n’ont aucun objectif légitime dans beaucoup d’environnements.

Je recommande ici une approche pragmatique : contrôler d’abord proprement les grands risques, puis renforcer progressivement les fonctions de protection et prouver avec les logs ce qui fonctionne réellement. Une policy surchargée que personne ne comprend plus n’est pas un gain de sécurité durable.

Pilier 3 : Detection and Response après le premier signal

La partie la plus intéressante de la sécurité réseau moderne est la réponse. Un pare-feu ne devrait pas travailler de manière isolée, mais utiliser des signaux issus d’Endpoint, Server, NDR, MDR, XDR et Threat Intelligence. Sophos peut jouer ici des avantages d’écosystème, mais seulement si ces intégrations correspondent réellement à l’environnement.

Les écosystèmes n’aident que s’ils conviennent

Synchronized Security et Security Heartbeat sont de bonnes idées : le pare-feu peut tenir compte de l’état des endpoints et restreindre ou bloquer la communication des appareils compromis. Dans la réalité, toutefois, de plus en plus d’entreprises utilisent Microsoft Defender ou d’autres solutions endpoint. Dans ce cas, cette partie de l’écosystème Sophos ne fonctionne que partiellement ou pas du tout. C’est précisément pourquoi il ne faut pas automatiquement tout prendre chez le même fabricant simplement parce que c’est proposé comme écosystème intégré.

Ma recommandation est claire : ce qui compte, c’est ce qui convient à l’entreprise et peut être implémenté proprement. Si Microsoft Defender, un autre EDR, un NDR tiers ou un SIEM externe constitue une meilleure base, alors le pare-feu doit être intégré proprement dans cette architecture. Plus important que le cross-selling : les logs doivent arriver au bon endroit, les alertes doivent être comprises et quelqu’un doit vérifier régulièrement ce que les systèmes signalent. Sans analyse des logs, tuning et processus d’incident, même la meilleure intégration aide peu.

Avec Active Threat Response, les menaces détectées peuvent être traduites automatiquement en décisions réseau. Et avec NDR Essentials, le pare-feu obtient une visibilité supplémentaire sur le trafic réseau suspect, y compris là où aucun agent endpoint classique n’est installé.

L’automatisation a besoin de runbooks

L’automatisation a besoin de garde-fous. Il doit être clair quels signaux peuvent bloquer automatiquement, qui lève une isolation, comment les faux positifs sont traités et comment ces processus sont testés. Sans runbooks, responsabilités et exercices réguliers, personne ne sait en cas d’incident si un blocage était voulu, correct ou trop agressif.

Que se passe-t-il en cas d’incident ? Un appareil compromis peut être isolé, la communication C2 interrompue, l’exfiltration bloquée, et un analyste MDR ou XDR peut déclencher Active Threat Response sans devoir d’abord construire manuellement une règle dans le pare-feu. C’est particulièrement précieux lorsqu’une attaque est détectée en dehors des heures normales d’exploitation.

Pour les admins, un point est particulièrement important : la réaction doit être suffisamment rapide. Si un analyste MDR ou XDR doit d’abord appeler, écrire un ticket et qu’un admin local doit ensuite créer manuellement une règle le vendredi soir, le temps de réaction est trop long. La réponse automatisée ne signifie pas remplacer les personnes. Elle signifie que la première contention se produit immédiatement et que l’équipe peut ensuite analyser proprement.

Cette automatisation est particulièrement utile dans les petites équipes IT. Toutes les entreprises n’ont pas un spécialiste pare-feu disponible 24h/24. Lorsque Endpoint, Firewall, NDR, MDR et SIEM fonctionnent ensemble de manière pertinente, même entre fabricants, on gagne du temps, et le temps est souvent le facteur le plus important lors d’attaques actives.

Checklist pratique pour les admins Sophos Firewall

Pour durcir une Sophos Firewall aujourd’hui, on peut commencer avec cette liste :

À vérifier immédiatement

• Les Hotfixes sont-ils activés ?
• MFA est-il actif pour les administrateurs ?
• La Web Admin Console et le User Portal sont-ils accessibles depuis le WAN ?
• SSL VPN ou IPsec Remote Access sont-ils protégés par MFA ?
• Existe-t-il encore des comptes admin locaux inutilisés ?
• Les sauvegardes sont-elles planifiées, chiffrées et testées ?
• Device Access et Local Service ACL sont-ils réduits au minimum ?
• Les services accessibles depuis le WAN sont-ils limités au moins aux pays pertinents ou aux réseaux sources connus ?
• Les pattern updates et versions firmware sont-ils à jour ?

Dans les prochaines semaines

• Exécuter Health Check et prioriser les findings.
• Vérifier les anciennes règles de pare-feu avec “Any” comme source, destination ou service.
• Vérifier les rôles admin, Login Security, session timeouts et protection brute-force.
• Inventorier les services exposés comme RDP, SSH, serveurs web, portails et règles NAT.
• Vérifier les zones internes et règles VLAN contre le lateral movement.
• Comparer les options ZTNA, SSE ou SASE pour les applications Remote Access typiques.
• Vérifier Threat Feeds et DNS Protection.
• Activer Spoof Protection, protection DoS et Geo-IP-Blocking selon le risque.
• Tester TLS Inspection de manière structurée et la déployer progressivement.

Planifier stratégiquement

• Remplacer les systèmes end-of-life.
• Aligner de manière pertinente l’exploitation firewall, VPN, DNS, SD-WAN et ZTNA/SSE.
• Standardiser la gestion centrale, le reporting et l’alerting, par exemple via Sophos Central, SIEM ou des plateformes de sécurité existantes.
• Définir l’export Syslog/SIEM et la rétention des logs pour les analyses forensiques.
• Intégrer les signaux MDR/XDR/NDR dans le processus d’incident.
• Mettre en place des revues récurrentes de hardening pare-feu.

Conclusion

Les Network Security Best Practices ne sont pas un projet ponctuel, mais un modèle d’exploitation. Comme les pare-feux en bordure réseau sont aussi privilégiés, ils doivent être régulièrement durcis, patchés, vérifiés et intégrés à la détection.

Ma recommandation après de nombreuses années avec Sophos Firewall est donc claire : un pare-feu moderne doit être plus qu’un produit de protection. Ce qui compte, c’est un design sûr, des mauvaises configurations visibles, des correctifs de sécurité rapides et une réaction qui fonctionne avec Endpoint, NDR, XDR et MDR en cas d’incident.

Ou, plus concrètement : lorsqu’un pare-feu est si ancien qu’il a davantage sa place dans un musée que dans un rack, ce n’est pas seulement un risque d’exploitation. C’est une surface d’attaque. Et c’est précisément cette surface d’attaque que je garde aussi petite que possible.

Support par Avanet

Si un support est nécessaire pour le durcissement d’une Sophos Firewall, Avanet peut aider. En tant que spécialiste Sophos de longue date, j’accompagne les équipes IT pour des audits de pare-feu, revues Health Check, nettoyage de règles, planification Remote Access et ZTNA/SSE, stratégies de mise à jour et formations.

Un regard externe sur les accès de gestion, la configuration VPN, les anciennes règles, les services exposés au WAN et l’état des mises à jour vaut souvent la peine. Beaucoup de risques ne naissent pas d’un seul mauvais paramètre, mais d’exceptions historiques que personne ne remet plus en question au quotidien.

En cas d’intérêt, un court message via le formulaire de contact suffit. On peut ensuite clarifier ensemble si une revue compacte du pare-feu, un audit ou une formation est le plus judicieux pour l’environnement concerné.

FAQ

Liens complémentaires

• Avanet Blog : Sophos Firewall v22 : aperçu et toutes les nouveautés
• Avanet Blog : Threat Intelligence Feeds pour pare-feu
• Avanet Blog : Sophos ZTNA Gateway sur Sophos Firewall
• Avanet Blog : Sophos NDR - supprimer les angles morts du réseau
• Avanet KB : Sophos Firewall Firmware Update - préparation et bonnes pratiques

Sources

• Sophos : Firewall: Network Security Best Practices
• Sophos Docs : Hardening your Sophos Firewall
• Sophos X-Ops : Nowhere, man: The 2026 Active Adversary Report