Sophos Firewall Hardening : bonnes pratiques pour une configuration sûre
Le hardening de Sophos Firewall consiste à réduire consciemment la surface d’attaque inutile autour du firewall lui-même et des services publiés à travers lui. Ce n’est pas un réglage magique unique, mais un processus d’exploitation répétable : limiter l’accès d’administration, imposer MFA, maintenir le firmware à jour, revoir les règles, activer les fonctions de protection et analyser les logs.
Cet article sert de point d’entrée central. Il ne remplace pas les guides détaillés, mais classe les bonnes pratiques les plus importantes et renvoie vers les articles Avanet KB correspondants.
Ce qu’il faut vérifier en premier
L’ordre compte dans le hardening. Une politique IPS parfaitement réglée aide peu si WebAdmin est accessible mondialement depuis WAN ou si un ancien portail VPN reste exposé sans MFA.
Les contrôles immédiats les plus importants :
- WebAdmin est-il accessible depuis la zone WAN ?
- SSH est-il autorisé uniquement depuis des réseaux d’administration de confiance ?
- MFA est-il actif pour les administrateurs, VPN Portal et Remote Access ?
- Firmware, hotfixes et pattern updates sont-ils à jour ?
- Existe-t-il des accès DNAT, WAF ou VPN qui ne sont plus nécessaires ?
- Les services publiés ont-ils IPS, WAF, Threat Feeds, logging et un propriétaire clair ?
- Les logs de sécurité sont-ils stockés centralement ou au moins contrôlés régulièrement ?
- Existe-t-il une sauvegarde actuelle et testée, y compris le Secure Storage Master Key ?
Sécuriser l’accès d’administration
Le domaine le plus important est l’accès au firewall lui-même. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal et les services locaux ne sont pas des règles firewall normales, mais des services locaux du firewall. Ils doivent être limités via Device Access et Local Service ACL.
Device Access et Local Service ACL
Sous Administration > Device access, on définit par zone quels services locaux sont accessibles. Pour la zone WAN, seul ce qui est réellement nécessaire doit être actif. L’accès admin et SSH ne devraient normalement pas être exposés largement à Internet.
Si l’administration à distance est nécessaire, ces variantes sont plus propres :
- Gestion via Sophos Fusion (anciennement Sophos Central).
- Accès via un réseau d’administration dédié.
- Accès via VPN ou ZTNA.
- Local Service ACL Exception Rules limitées à des adresses IP source d’administration fixes.
La mise en œuvre est décrite dans Sécuriser l’accès Sophos Firewall : configurer correctement Device Access. Si SSH est nécessaire, Connecter Sophos Firewall via SSH aide également.
Pour une exception WAN, il faut éviter de se verrouiller soi-même. Il faut d’abord ouvrir et tester un accès de secours indépendant par la console, le LAN d’administration, un VPN d’administration ou Sophos Fusion. Sous Administration > Device access, cliquer ensuite sur Add sous Local service ACL exception rule. Un exemple adaptable est WAN-Admin-203.0.113.10 avec Rule position Top, IP version IPv4, Source zone WAN, l’IP publique fixe d’administration comme Source network / host, l’interface WAN du firewall comme Destination host, Services HTTPS et SSH uniquement si nécessaire, et Action Accept. 203.0.113.10 est une adresse de documentation à remplacer par l’IP fixe réelle. Garder la session existante ouverte, tester une seconde session depuis cette source, puis seulement retirer l’autorisation WAN plus large pour HTTPS ou SSH dans Local service ACL. Si le test échoue, l’accès précédent reste inchangé ; corriger l’exception avant de toucher à l’autorisation de zone.
MFA, rôles et sécurité de connexion
MFA devrait être obligatoire pour les administrateurs et les utilisateurs Remote Access. Les comptes admin locaux, VPN Portal, User Portal et Remote Access VPN sont particulièrement critiques. MFA n’est toutefois qu’une partie du hardening de connexion. Des comptes admin nominatifs, des rôles clairs, des règles de mot de passe fortes, une limitation des tentatives et des timeouts courts sont tout aussi importants.
Dans SFOS 22, la configuration utilisateur se trouve sous Authentication > Multi-factor authentication (MFA). Sous One-time password (OTP), sélectionner All users ou Specific users and groups, activer Generate OTP token with next sign-in pour les tokens d’application et cocher chaque service réellement utilisé sous Require MFA for. Le compte intégré admin se protège séparément sous Administration > Device access > MFA for default admin. Avant d’imposer MFA, au moins un compte administrateur nominatif doit avoir enregistré son token ; contrôler son émission sous Issued tokens. Tester ensuite une nouvelle connexion tout en gardant une session admin existante ouverte comme chemin de retour.
La configuration pratique se trouve dans Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access. Configurer les administrateurs et profils Sophos Firewall en toute sécurité explique comment les comptes locaux personnels, les profils Device Access, les sources de connexion et l’offboarding fonctionnent ensemble. Pour les scénarios WAF avec connexion utilisateur, Sécuriser Sophos Firewall WAF avec MFA convient.
Firmware, hotfixes et recovery
Un firewall est un système exposé en bordure. Les mises à jour retardées ne sont donc pas un détail, mais une vraie fenêtre d’attaque. En même temps, les mises à jour ne doivent pas être appliquées à l’aveugle, car les sites distants, clusters HA, VPN et règles NAT productives peuvent être touchés.
Rendre les mises à jour planifiables
Les mises à jour firmware doivent être préparées avec sauvegarde, fenêtre de maintenance, revue des release notes, planification HA et critères de rollback. Il faut rechercher régulièrement les maintenance releases disponibles et les déployer rapidement après validation. Dans les versions SFOS 22 actuelles, la page WebAdmin Backup & Firmware > Firmware n’affiche plus de section Hotfix séparée. La fonction hotfix existe toujours : Sophos installe les hotfixes automatiquement par défaut et recommande de ne pas modifier ce réglage. Si le statut doit être vérifié, utiliser system hotfix show dans la Device Console. Les hotfixes ne remplacent pas un processus de mise à jour régulier. Le processus est décrit dans Sophos Firewall Firmware Update : préparation et bonnes pratiques.
La page conserve au maximum deux versions du firmware. Un rollback démarre la version précédente avec sa configuration antérieure correspondante ; les changements effectués depuis le changement de version sont perdus. Depuis SFOS 19.0 MR1, les changements de firmware nécessitent Enhanced Support ou Enhanced Plus après trois mises à niveau gratuites ; les hotfixes ne nécessitent pas cet abonnement de support. Il faut donc vérifier le firmware attendu, l’accès d’administration, les VPN et les publications critiques avant d’apporter d’autres modifications après la mise à jour.
Pour les grands sauts de version, il faut aussi vérifier le chemin d’upgrade, la licence, la plateforme et les restrictions connues. Vérifier Sophos Firewall avant l’upgrade SFOS 22 convient ici.
Vérifier sauvegarde et restore
Le hardening ne s’arrête pas à la prévention. Un firewall durci doit aussi être restaurable. Cela comprend une sauvegarde actuelle, le mot de passe de sauvegarde, le Secure Storage Master Key, un chemin d’accès documenté après restore et un test d’acceptation.
Les détails se trouvent dans Créer ou restaurer une sauvegarde Sophos Firewall. Un paquet de recovery complet est obligatoire avant les mises à jour firmware, migrations, reimage et remplacement matériel.
Le mode FIPS 140-3 sur Sophos Firewall constitue une migration de conformité particulière : son activation effectue une réinitialisation et exige une reconstruction entièrement planifiée avec des paramètres VPN et de certificats conformes à FIPS.
Réduire la surface d’attaque dans les règles
De nombreux risques ne viennent pas d’attaques exotiques, mais de règles trop larges, d’anciennes exceptions et de services publiés dont personne n’est réellement responsable.
NAT, WAF et services publiés
Chaque service publié par DNAT ou WAF est une entrée ouverte volontairement. Cela peut être nécessaire, mais doit être planifié strictement : source, destination, service, ordre NAT, règle firewall, politique IPS/WAF, logging, test et propriétaire vont ensemble.
Pour les serveurs publiés, Publier un serveur avec DNAT sur Sophos Firewall et Comprendre NAT sur Sophos Firewall aident. Pour les serveurs web, Sophos Firewall WAF : publier des serveurs web en sécurité est la meilleure base.
Règles firewall et segmentation
Les règles avec Any comme source, destination ou service ne sont pas automatiquement fausses, mais elles doivent toujours être expliquées. Pour le hardening, ces questions comptent :
- La règle est-elle encore nécessaire ?
- Le logging est-il activé ?
- Existe-t-il une source ou destination plus précise ?
- La règle est-elle correctement placée avant des règles plus larges ?
- Les réseaux admin, serveurs, clients, IoT, invités et backup sont-ils clairement séparés ?
Les bases sont dans Comprendre et configurer les règles Sophos Firewall en sécurité. Pour vérifier une règle concrète, Tester proprement une règle Sophos Firewall convient.
Activer les protections consciemment
Les fonctions de protection n’aident que si elles correspondent à la règle, au trafic et au processus d’exploitation. Activées à l’aveugle, elles créent des faux positifs, des problèmes de performance ou du support. Désactivées, elles laissent une surface d’attaque inutile.
IPS, Spoof Protection et DoS
IPS devrait être utilisé sur le trafic entrant non fiable et sur les transitions internes pertinentes. Il faut des politiques IPS adaptées, du logging, un processus de faux positifs et une vue performance. La mise en œuvre est décrite dans Configurer et tester Sophos Firewall IPS en sécurité.
Spoof Protection et DoS Settings réduisent les sources non plausibles et les modèles de flooding simples. Ils doivent être testés prudemment, surtout avec VoIP, VPN, charge élevée ou designs de routage spéciaux. L’article correspondant est Vérifier Sophos Firewall Spoof Protection et DoS Settings.
Threat Feeds pour WAF et DNAT
Les Threat Feeds sont un complément très utile lorsque des services sont accessibles via WAF, DNAT, VPN Portal ou d’autres accès publics. Ils peuvent bloquer plus tôt des IP, domaines ou URL malveillants connus, avant qu’ils n’atteignent l’application ou la règle.
Ils sont particulièrement utiles pour :
- serveurs web publics derrière WAF ou DNAT,
- accès RDP, SSH ou admin pas encore remplacés par ZTNA,
- accès VPN et portails avec beaucoup de bruit Internet,
- environnements où le blocage par pays est trop grossier,
- clients qui veulent utiliser des feeds tiers en plus de Sophos X-Ops.
L’exploitation est importante : qualité du feed, action Monitor ou Block, allowlist, faux positifs, logging et responsabilité doivent être clairs. La configuration est décrite dans Configurer et exploiter Sophos Firewall Threat Feeds en sécurité. Pour des feeds curatés, Cybora peut être un composant utile, surtout lorsque des services publiés doivent être protégés contre des sources déjà connues comme mauvaises.
Web, DNS, TLS et Zero-Day Protection
Web Protection, DNS Protection, TLS Inspection et Zero-Day Protection augmentent la visibilité et la capacité de blocage, mais nécessitent une bonne planification. TLS Inspection ne doit pas commencer comme un projet tout-ou-rien. DNS Protection doit correspondre aux chemins DNS utilisés. Zero-Day Protection aide seulement si les types de fichiers et politiques pertinents sont intégrés correctement.
Les articles détaillés sont Créer une Web Protection Sophos Firewall avec des Web Policies, Configurer Sophos DNS Protection avec Sophos Firewall, Introduire correctement Sophos Firewall TLS Inspection et Comprendre et exploiter Sophos Firewall Zero-Day Protection.
Détection, logging et revue
Le hardening n’est pas une tâche unique. Règles, utilisateurs, portails, exceptions NAT et versions firmware changent. Il faut donc des revues régulières et des logs disponibles avant l’incident.
Health Check comme point de départ
Le Sophos Firewall Health Check est un bon point de départ, car il rend visibles les configurations risquées. Les findings ne doivent pas être appliqués aveuglément, mais évalués selon le risque, l’impact opérationnel et l’architecture locale.
Dans SFOS 22, ouvrir le widget Firewall health check dans le Control Center ou aller dans Monitor & analyze > Firewall health check. Les données sont actualisées dès qu’une configuration surveillée change. Point important : un finding peut être marqué manuellement comme compliant sans corriger sa cause. La validation doit donc confirmer l’exigence de la politique, et pas seulement le statut affiché.
Bons moments pour un Health Check :
- après le setup initial,
- après des migrations,
- avant et après les upgrades firmware,
- après de grands changements de règles,
- avant les audits,
- chaque trimestre en exploitation.
Évaluer séparément la télémétrie et Sophos Assistant
Sous Administration > Admin and user settings, Sophos Adaptive Learning détermine les données d’utilisation et de menace que le firewall envoie à Sophos. Cela comprend les applications non classifiées ainsi que les données relatives aux alertes IPS, aux virus détectés, au spam et aux détections d’Active Threat Response. L’équipement transmet aussi périodiquement par HTTPS des données de configuration, de fonctionnalités, d’erreurs et d’utilisation des ressources. Sophos indique ne collecter aucune information propre à un utilisateur ou personnalisée. La décision doit néanmoins être documentée consciemment selon les exigences de confidentialité et le modèle d’exploitation, au lieu de considérer cette option comme une fonction de protection du trafic local.
Turn on Sophos Assistant ne concerne en revanche que les textes d’aide, les smart tips et les guides de configuration dans WebAdmin. Après une modification, il faut se déconnecter puis se reconnecter. Désactiver l’assistant ne réduit pas la surface d’attaque réseau et n’arrête pas automatiquement la télémétrie ; les deux réglages doivent être évalués séparément.
Logging, alertes et SIEM
Les règles firewall sans logging sont souvent inutiles pour le troubleshooting et l’incident response. Pour une conservation plus longue, le Log Viewer local ne suffit généralement pas. Selon l’environnement, les rapports dans Sophos Fusion, Syslog, SIEM, MDR, XDR ou NDR sont utiles.
Sélectionner également les événements système nécessaires pour l’e-mail ou SNMP sous System services > Notification list. Configurer auparavant la destination e-mail sous Administration > Notification settings, ou l’agent SNMP et la communauté ou l’utilisateur sous Administration > SNMP. Après Save, un événement contrôlé et sans risque doit atteindre le destinataire prévu ; sinon, vérifier d’abord la destination e-mail ou SNMP, la connectivité et la classe d’événement sélectionnée.
La configuration Syslog est décrite dans Envoyer Sophos Firewall Syslog en sécurité vers un SIEM. Pour les rapports centraux, Activer et exploiter Sophos Firewall Central Reporting convient. Si NDR et Active Threat Response sont pertinents, Exploiter Sophos Firewall NDR et Active Threat Response aide.
Valider les changements et revenir en arrière en sécurité
Appliquer le hardening par petites étapes traçables. Avant chaque groupe de changements, noter la valeur actuelle, le responsable et le chemin de retour prévu. Ne modifier ensuite qu’un domaine, par exemple Device Access, une règle firewall ou l’action d’un Threat Feed. Tester le chemin autorisé attendu ainsi qu’un chemin volontairement interdit, puis contrôler les logs correspondants. Passer seulement ensuite au domaine suivant.
Pour revenir en arrière, remettre uniquement le dernier réglage modifié à sa valeur initiale documentée. Pour Device Access, garder disponibles la session admin existante et un accès d’administration indépendant testé au préalable. Ne pas supprimer l’ancienne règle avant que sa variante plus stricte soit validée. Commencer les Threat Feeds avec Monitor, examiner les correspondances et les faux positifs possibles, puis passer à Block ; si le blocage pose problème, revenir à Monitor et n’ajouter que des exclusions vérifiées. Une restauration complète de backup n’est pas un bouton Undo pratique, mais le chemin de recovery pour les incidents plus importants.
Checklist compacte de hardening
Pour une première revue, utiliser cet ordre :
- Vérifier l’accès WAN à WebAdmin, SSH, User Portal et VPN Portal.
- Activer MFA pour les administrateurs et Remote Access.
- Nettoyer les comptes admin locaux, rôles et règles de mot de passe.
- Vérifier firmware, hotfixes, pattern updates et statut de support.
- Documenter sauvegarde, SSMK, chemin de restore et test de recovery.
- Vérifier la nécessité des publications DNAT, WAF et VPN.
- Nettoyer les règles avec
Any, sans logging ou sans propriétaire clair. - Activer IPS, Spoof Protection, DoS Settings et Threat Feeds de manière ciblée.
- Introduire Web, DNS, TLS et Zero-Day Policies par phases.
- Établir Health Check, Syslog, alertes et revues régulières comme processus d’exploitation.
Erreurs fréquentes
L’accès WAN reste ouvert par confort
Un accès WebAdmin ou SSH est ouvert pour un support case puis oublié. Ces exceptions temporaires doivent être documentées avec date d’expiration, propriétaire et contrôle de suivi.
Les Threat Feeds sont activés sans concept d’exploitation
Les Threat Feeds sont puissants, mais pas sans maintenance. Sans monitoring, allowlist et processus de faux positifs, un partenaire, prestataire ou service cloud légitime peut être bloqué. Il faut donc tester d’abord avec Monitor ou un scope limité, puis passer proprement à Block.
Le logging manque sur des règles critiques
Si une règle DNAT publique, WAF ou VPN ne logue pas, la visibilité est trop faible lors d’un incident. Au minimum, les entrées critiques, accès admin, règles deny et transitions de segments critiques doivent être traçables.
Health Check est traité comme une tâche unique
Un bon score après le setup n’est pas un état permanent. Nouvelles règles, nouveaux utilisateurs VPN, exceptions temporaires et changements firmware peuvent modifier la situation. Le hardening a besoin d’un rythme de revue.