Utiliser correctement le Sophos Firewall Health Check
Le Sophos Firewall Health Check est un examen intégré de la configuration du pare-feu. Il indique dans le Control Center si les paramètres importants respectent les recommandations de sécurité et les meilleures pratiques. C’est particulièrement utile pour les administrateurs car cela rend visibles les configurations risquées avant qu’elles ne deviennent un problème de sécurité ou d’exploitation.
Le Health Check a été introduit avec Sophos Firewall v22. La fonction évalue les configurations par rapport à des meilleures pratiques et des standards tels que les benchmarks CIS. Avec SFOS 22.0 MR1, le contexte CIS sous-jacent a également été mis à jour.
Guide vidéo
Quel article de sécurité convient ?
Le Health Check est un bon point de départ, mais chaque constat n’est pas entièrement résolu dans l’article du Health Check. Pour la mise en œuvre pratique, ces entrées sont utiles :
Cette répartition évite deux erreurs typiques : les constats sont soit considérés uniquement comme des notifications de tableau de bord sans être traités techniquement, soit les fonctions de protection sont activées de manière générale sans clarifier la journalisation, les exceptions et les responsabilités.
À quoi sert le Health Check
Le Health Check n’est pas un statut système classique ni un capteur matériel. Il ne vérifie pas si une alimentation est défectueuse ou si un SSD est sur le point de tomber en panne. Pour cela, d’autres vérifications opérationnelles conviennent, par exemple vérifier l’état de santé du SSD ou la surveillance HA et matérielle.
Le Health Check répond plutôt à ces questions :
- Les accès administratifs sont-ils trop ouverts ?
- MFA est-il activé pour les connexions critiques ?
- Les règles de pare-feu sont-elles trop ouvertes ?
- Les sauvegardes, correctifs, journalisation ou fonctions Central sont-ils bien préparés ?
- La configuration s’écarte-t-elle des standards de sécurité recommandés ?
- Y a-t-il des constats à clarifier avant un audit ou une mise en production ?
C’est donc un bon outil pour le renforcement, la révision et le contrôle des changements. Cependant, il ne remplace pas une architecture propre, une documentation des règles et une évaluation manuelle.
⚠️ Un Health Check vert ne signifie pas automatiquement que le pare-feu est bien planifié en termes de sécurité. Il montre si certains paramètres vérifiables sont corrects. La conception du réseau, la logique métier, les exceptions, les groupes d’utilisateurs et les processus opérationnels doivent toujours être évalués professionnellement.
Ne pas mal interpréter le score comme un objectif
Le Health Check est utile, mais le score ne doit pas devenir une fin en soi. Certains points sont des bases de sécurité claires, comme MFA, les correctifs, les règles de mot de passe, l’accès restreint à WebAdmin, les sauvegardes ou l’IPS. D’autres points dépendent davantage de l’écosystème Sophos, de la licence ou du modèle opérationnel.
Il ne faut donc pas activer chaque recommandation uniquement pour que l’affichage devienne vert. Un exemple est le Login disclaimer : dans les environnements d’audit ou de conformité, un avis de connexion peut être requis. Dans de nombreux environnements opérationnels normaux, il génère surtout un clic supplémentaire à chaque connexion et n’apporte pratiquement aucun gain de sécurité technique. Si cela ne fait qu’augmenter le score du Health Check, la valeur ajoutée est limitée.
Il en va de même pour des fonctions comme DNS Protection, les flux de menaces MDR, NDR Essentials, Sophos X-Ops, Synchronized Application Control ou Sophos Central Reporting. Ces fonctions peuvent être utiles si elles sont licenciées, comprises, surveillées et réellement utilisées en opération. Il ne faut pas les activer aveuglément simplement parce que le Health Check les recommande. Ce qui est toujours décisif : la mesure réduit-elle un risque réel dans cet environnement, et y a-t-il un responsable pour l’exploitation, les exceptions et les faux positifs ?
Comme règle générale :
| Catégorie | Évaluation |
|---|---|
| Accès de gestion exposés à Internet, MFA, correctifs, sauvegardes, règles de mot de passe, IPS | En général, de véritables bases de sécurité ou d’exploitation. Ces points doivent être pris très au sérieux. |
| Journalisation, reporting, notifications, NTP | Important pour l’exploitation et la traçabilité. La voie concrète dépend du modèle opérationnel. |
| DNS Protection, NDR, flux de menaces MDR, X-Ops, Synchronized Security | Utile si la fonction est utilisée, licenciée, surveillée et intégrée dans les processus. Pas automatiquement meilleur juste à cause du score. |
| Login disclaimer | Souvent plus une fonction de conformité/avis qu’une mesure de protection technique. À activer uniquement si vraiment requis ou souhaité. |
Ouvrir le Health Check
Le statut du Health Check apparaît dans le Control center. La vue détaillée est également accessible via le menu principal :
Firewall health check
Là, vous voyez le nombre de configurations vérifiées, les points conformes et les points non conformes. Sophos affiche les entrées non conformes par gravité. Les données sont mises à jour lorsqu’une configuration surveillée change. Cela fait du Health Check un bon outil de suivi direct après les modifications.
Pour la révision, il ne faut pas seulement noter le statut global. Ce qui est plus important, ce sont les constats concrets, le contexte de risque et la mesure prévue. Un constat critique unique concernant l’accessibilité WAN de WebAdmin est plus important en opération que plusieurs constats mineurs sans exposition à Internet.
Aperçu des 31 vérifications du Health Check
La liste suivante est basée sur la vue anglaise du Health Check. Le statut n’est pas indiqué car il varie selon le pare-feu. Ce qui est plus important, c’est quelle vérification est concernée et comment elle est évaluée professionnellement.
| N° | Vérification | Module | Standard | Gravité | Évaluation |
|---|---|---|---|---|---|
| 1 | Synchronized Application Control devrait être activé. | Active threat response | Recommandé | Moyen | Utile dans les environnements Sophos Endpoint. Dans les environnements mixtes ou Microsoft Defender, vérifier d’abord si la fonction fournit réellement des données. |
| 2 | NDR Essentials devrait être activé et surveiller au moins une interface. | Active threat response | Recommandé | Moyen | Utile uniquement si les interfaces surveillées sont judicieusement choisies et que les constats sont ensuite évalués. |
| 3 | Sophos X-Ops devrait être activé, Action Log and drop. | Active threat response | CIS | Élevé | Pertinent pour la sécurité si les flux de menaces sont activement utilisés. Les faux positifs et la journalisation doivent être vérifiés. |
| 4 | Les flux de menaces MDR devraient être activés, Action Log and drop. | Active threat response | Recommandé | Élevé | Utile uniquement si MDR ou les fonctions de flux de menaces appropriées sont licenciées et intégrées opérationnellement. |
| 5 | Une règle de pare-feu devrait utiliser le Synchronized Security Heartbeat. | Active threat response and Advanced security | CIS | Moyen | Valeur ajoutée significative avec Sophos Endpoint. Sans Sophos Endpoint, ne pas simplement considérer cela comme un sujet de score. |
| 6 | Security Heartbeat devrait être activé. | Active threat response and Advanced security | CIS | Élevé | Important si Sophos Endpoint est utilisé. Sinon, il faut d’abord clarifier la conception de l’Endpoint. |
| 7 | Login disclaimer devrait être activé. | Admin settings | CIS | Moyen | Sujet de conformité. Peu de protection technique, mais génère un clic supplémentaire lors de la connexion. |
| 8 | Le paramètre Hotfix devrait être activé. | Admin settings | CIS | Élevé | Très important. Les correctifs devraient être actifs dans les environnements de production, si le processus de changement le permet. |
| 9 | Les sessions inactives devraient être terminées et les connexions bloquées après des tentatives échouées. | Admin settings | CIS | Élevé | Renforcement clair des connexions. Particulièrement important pour les portails exposés et les accès administratifs. |
| 10 | La complexité des mots de passe devrait être configurée pour les utilisateurs. | Admin settings | CIS | Élevé | Utile, surtout pour les utilisateurs locaux et les portails. Avec un IdP externe, vérifier également sa politique de mot de passe et MFA. |
| 11 | La complexité des mots de passe devrait être configurée pour les administrateurs. | Admin settings | CIS | Élevé | Renforcement de base. Plus important encore sont les administrateurs individuels, MFA et l’accès restreint. |
| 12 | DNS Protection devrait être configuré et actif. | Advanced security | Recommandé | Moyen | Ne pas activer aveuglément. DNS Protection est utile si les politiques DNS Central et le reporting sont réellement utilisés. |
| 13 | MFA devrait être actif pour les connexions VPN Remote Access. | Authentication | CIS | Élevé | Très important pour SSL VPN et IPsec Remote Access. Planifier le déploiement avec un administrateur de secours et des utilisateurs de test. |
| 14 | MFA devrait être actif pour la WebAdmin Console et le VPN Portal. | Authentication | CIS | Élevé | Très important, surtout si les portails sont accessibles depuis des réseaux moins contrôlés. |
| 15 | Les connexions aux serveurs d’authentification devraient être chiffrées. | Authentication servers | CIS | Moyen | Important pour les connexions AD/LDAP/RADIUS. Éviter l’authentification non chiffrée. |
| 16 | Les sauvegardes devraient être planifiées sur le pare-feu ou dans Sophos Central. | Backup & restore | CIS | Faible | Gravité faible, mais extrêmement important en cas de besoin. Tester également le processus de restauration. |
| 17 | L’authentification par clé publique devrait être activée pour SSH. | Device access | Recommandé | Élevé | Très utile. De plus, autoriser SSH uniquement depuis des réseaux de confiance. |
| 18 | Le User Portal ne devrait pas être accessible depuis la zone WAN. | Device access | Recommandé | Élevé | Correct dans de nombreux environnements. Si l’accès WAN est nécessaire, le restreindre fortement et utiliser MFA. |
| 19 | La WebAdmin Console ne devrait pas être accessible depuis la zone WAN. | Device access | CIS | Élevé | L’un des points les plus importants. Ne jamais ouvrir largement WebAdmin à Internet. |
| 20 | MFA devrait être configuré pour l’administrateur par défaut. | Device access | CIS | Élevé | Important, mais mieux vaut également un processus administratif propre avec des comptes administratifs personnels. |
| 21 | Les emails de notification devraient être configurés pour les événements système et de sécurité. | Notification settings | CIS | Faible | Important pour l’exploitation. Alternativement ou en complément, intégrer la surveillance, Syslog, SIEM ou les alertes Central. |
| 22 | Les mises à jour automatiques des modèles devraient être activées. | Pattern updates | CIS | Élevé | Opération de base. Sans modèles à jour, de nombreuses fonctions de protection perdent de leur valeur. Dans les environnements Air-Gap, un processus manuel de modèles et de licences est nécessaire à la place. |
| 23 | Une politique Web devrait être sélectionnée dans une règle de pare-feu. | Rules and Policies | Recommandé | Moyen | Utile pour le trafic Web des utilisateurs. Ne pas appliquer aveuglément au trafic serveur-à-serveur ou spécialisé. |
| 24 | La protection contre les menaces zero-day devrait être sélectionnée dans une règle de pare-feu. | Rules and Policies | CIS | Élevé | Utile pour les chemins Web et de téléchargement appropriés. Prendre en compte la licence, les performances et les faux positifs. |
| 25 | IPS devrait être activé et une politique IPS devrait être sélectionnée dans une règle de pare-feu. | Rules and Policies | CIS | Élevé | Point de protection très important. IPS doit être choisi et journalisé de manière appropriée pour chaque chemin de trafic. |
| 26 | Une politique de contrôle des applications devrait être sélectionnée dans une règle de pare-feu. | Rules and Policies | CIS | Moyen | Utile pour les règles Internet des clients. Tester d’abord pour le trafic critique. |
| 27 | Une règle d’inspection SSL/TLS devrait utiliser l’action Decrypt. | Rules and Policies | CIS | Élevé | Ne pas activer aveuglément. L’inspection TLS nécessite une distribution CA, des exceptions, une phase pilote et un processus de dépannage. |
| 28 | Une règle Allow ne devrait pas utiliser Any partout dans les champs réseau et service. | Rules and Policies | CIS | Moyen | Très important pour l’hygiène des règles. Any peut être nécessaire de manière consciente, mais doit alors être justifié et journalisé. |
| 29 | Le reporting Sophos Central devrait être activé. | Sophos central | Recommandé | Moyen | Utile pour le reporting et les analyses plus longues. Pas indispensable si Syslog/SIEM est bien géré. |
| 30 | Le pare-feu devrait être enregistré pour la gestion Sophos Central et la gestion Central activée. | Sophos central | Recommandé | Moyen | Pratique pour la gestion centralisée, les sauvegardes et le reporting. Pas nécessaire dans tous les environnements ou besoin de gestion cloud. |
| 31 | Un serveur NTP devrait être configuré. | Time | CIS | Faible | Exigence de base. Sans heure correcte, les journaux, certificats, authentification et dépannage souffrent. |
Prioriser correctement les constats
Tous les constats n’ont pas la même importance dans chaque environnement. Une bonne révision trie donc les entrées non seulement par gravité technique, mais aussi par exposition et risque opérationnel.
Cette séquence s’est avérée efficace :
- Vérifier les accès de gestion et portails exposés à Internet.
- Vérifier la sécurité MFA et des connexions pour les administrateurs, VPN Portal, User Portal et Remote Access.
- Nettoyer les règles de pare-feu avec des sources, cibles ou services trop larges.
- Contrôler les journaux, sauvegardes et correctifs.
- Vérifier les fonctions de protection par règle, par exemple IPS, politique Web, contrôle des applications, inspection TLS ou protection zero-day.
- Évaluer les constats Central, reporting ou NDR pour déterminer si la fonction est réellement utilisée et exploitée dans l’environnement.
L’ordre est pragmatique : d’abord les éléments directement visibles sur Internet ou permettant l’accès au pare-feu. Ensuite, l’hygiène des règles et les fonctions de protection. Ensuite, les sujets d’exploitation et d’écosystème.
Constats typiques et mesures appropriées
WebAdmin, User Portal ou VPN Portal est trop accessible
Si les portails administratifs ou proches des utilisateurs sont accessibles depuis trop de zones, le risque augmente en raison des scans, des tentatives de force brute et du credential stuffing. L’article le plus important à ce sujet est Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.
Pour les environnements de production, il convient de vérifier :
- WebAdmin est-il vraiment nécessaire depuis la zone WAN ?
- Existe-t-il une Local Service ACL Exception Rule pour l’IP de gestion ou le réseau admin ?
- SSH est-il autorisé uniquement depuis des réseaux de confiance ?
- Les User Portal et VPN Portal sont-ils accessibles uniquement là où ils sont nécessaires ?
MFA manque ou n’est pas activé de manière cohérente
MFA doit être appliqué au moins aux accès administratifs et au Remote Access. Si le Health Check montre des constats MFA, il ne faut pas passer aveuglément à tous les utilisateurs en même temps. Mieux vaut un déploiement contrôlé avec un utilisateur de test, un administrateur de secours et un processus de jeton propre.
Le guide pratique se trouve dans Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.
Les règles de pare-feu sont trop ouvertes
Les règles très larges avec Any pour la source, la cible ou le service sont souvent héritées. Toutes les règles larges ne sont pas automatiquement incorrectes, mais chacune doit être justifiée.
Pour le nettoyage, ces questions sont utiles :
- Quelle zone peut vraiment accéder à quelle zone ?
- Les réseaux cibles ou les services peuvent-ils être restreints ?
- La journalisation est-elle active pour rendre les correspondances visibles ?
- Y a-t-il d’anciennes règles de test ou des exceptions temporaires ?
- La règle peut-elle être divisée en plusieurs règles plus compréhensibles ?
Les bases se trouvent dans Comprendre et configurer correctement les règles de Sophos Firewall. Si l’on ne sait pas quelle règle s’applique, Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture peut aider.
Sauvegardes, correctifs et processus de mise à jour manquants
Un Health Check peut indiquer des sauvegardes manquantes ou des sujets de mise à jour/correctifs. Ces points semblent moins spectaculaires que l’exposition des portails, mais sont cruciaux en cas de besoin.
Avant des modifications importantes, il convient de créer une sauvegarde et de savoir comment fonctionne une restauration. La procédure est décrite dans Créer ou restaurer une sauvegarde Sophos Firewall. Pour les sujets de firmware, Mise à jour du firmware Sophos Firewall - Préparation et meilleures pratiques convient.
Journalisation et reporting incomplets
Si les journaux manquent, l’exploitation est aveugle. Le Health Check peut donner des indications sur les sujets de journalisation ou de reporting, mais la décision réelle dépend du modèle opérationnel.
Pour l’analyse locale, Log Viewer, les journaux de service et Packet Capture sont pertinents. Pour une conservation plus longue, Central Firewall Reporting ou Syslog/SIEM sont nécessaires. Si ce ne sont pas des événements de journal individuels, mais des flux de trafic, des pics de bande passante ou des relations de communication inhabituelles qui doivent être examinés, sFlow Monitoring convient en complément. Les bases locales se trouvent dans Dépannage Sophos Firewall : Services et journaux.
Les fonctions de protection ne sont pas actives dans les règles
Un point fréquent concerne les règles sans IPS, politique Web, contrôle des applications, inspection TLS ou protection zero-day. Il ne faut pas activer tout cela aveuglément, mais comprendre le chemin de trafic.
Exemples :
- Le trafic Web des utilisateurs nécessite d’autres contrôles que le trafic serveur-à-serveur.
- L’inspection TLS doit être introduite de manière planifiée car elle peut perturber les applications.
- IPS et Application Control nécessitent une journalisation et une routine de révision.
- Les fonctions NDR ou de flux de menaces ne sont utiles que si les constats sont ensuite évalués.
Pour l’inspection TLS, Introduire correctement l’inspection TLS de Sophos Firewall convient. Pour les flux de menaces, Flux de menaces Sophos Firewall convient.
Documenter consciemment les dérogations
Sophos Firewall permet de surcharger manuellement le statut de certaines vérifications. Cela peut être utile si une recommandation n’est pas mise en œuvre intentionnellement dans son propre environnement.
Cependant, les dérogations ne doivent pas être mal comprises comme une fonction de nettoyage. Si un point est surchargé, il doit être documenté :
- Pourquoi la recommandation n’est-elle pas appropriée ?
- Qui a approuvé la décision ?
- L’exception est-elle permanente ou seulement temporaire ?
- Quand sera-t-elle réévaluée ?
- Existe-t-il une mesure compensatoire ?
⚠️ Une dérogation n’est pas une correction. C’est une acceptation consciente du risque ou une exception documentée. Sans justification, le Health Check perd de sa valeur.
Documenter proprement le résultat
Une révision du Health Check doit produire un résultat traçable. Sinon, on voit brièvement un tableau de bord, mais on ne sait plus plus tard quelle décision a été prise et quels points restent ouverts.
Pour les petits environnements, un tableau simple suffit souvent :
| Champ | Objectif |
|---|---|
| Date | Quand le Health Check a-t-il été vérifié ? |
| Firmware | Sur quelle version SFOS a-t-il été évalué ? |
| Constat | Quel point non conforme a été signalé ? |
| Risque | Pourquoi le point est-il pertinent ou moins pertinent dans cet environnement ? |
| Mesure | Qu’est-ce qui sera modifié, testé ou consciemment accepté ? |
| Responsable | Qui clarifie le point professionnellement ou techniquement ? |
| Délai | Quand la mesure doit-elle être terminée ou réévaluée ? |
| Preuve | Capture d’écran, ticket, ID de changement ou référence de journal d’audit |
Pour les pare-feu en production, la preuve ne doit pas se limiter à une capture d’écran. Si une configuration a été modifiée, le ticket de changement, la piste d’audit, la règle de pare-feu concernée et le résultat du suivi doivent être réunis. Pour les modifications des règles, interfaces, hôtes et services, Vérifier les logs de piste d’audit de Sophos Firewall est particulièrement utile.
Vérifier à nouveau après les modifications
Après une correction, il convient de rouvrir le Health Check et de vérifier si le constat a vraiment disparu. De plus, un test de fonctionnalité technique est nécessaire, car un statut vert seul ne prouve pas que le trafic en production fonctionne toujours correctement.
Exemples :
- Après une modification de Device access, vérifier si l’accès admin depuis le réseau de gestion prévu fonctionne toujours et n’est plus accessible depuis les réseaux indésirables.
- Après des modifications MFA, se connecter avec un utilisateur de test et vérifier séparément l’administrateur de secours.
- Après des modifications des règles, tester Log Viewer, Policy Test et les applications concernées.
- Après des modifications de journalisation ou de reporting, vérifier si de nouveaux événements sont réellement visibles localement, dans Sophos Central ou dans le Syslog.
- Après une dérogation, mettre en place un rappel pour que l’exception ne soit pas oubliée de manière permanente.
Si plusieurs constats sont traités en même temps, il convient de diviser les modifications en petits blocs. Sinon, en cas de problème ultérieur, il est difficile de savoir si Device Access, MFA, les règles de pare-feu, l’inspection TLS ou une autre modification est la cause.
Utiliser le Health Check comme processus opérationnel
Le Health Check est le plus efficace lorsqu’il est exécuté régulièrement et après des changements importants.
Moments opportuns :
- après la configuration initiale ou une mise en production,
- avant et après des modifications importantes des règles,
- avant les mises à jour du firmware,
- après une restauration ou un échange matériel,
- après des migrations ou des changements architecturaux importants,
- avant les audits,
- trimestriellement comme revue de sécurité.
Pour les modifications elles-mêmes, la piste d’audit doit également être utilisée. L’article Vérifier les logs de piste d’audit de Sophos Firewall explique comment évaluer configuration-audit.log et suivre les modifications de configuration.
Processus de révision pratique
Un processus de révision pragmatique du Health Check se déroule ainsi :
- Ouvrir le Health Check dans le Control Center.
- Trier les constats non conformes par gravité.
- Vérifier d’abord les services exposés à Internet et les accès admin.
- Traiter les sujets de sécurité MFA, de mot de passe et de session.
- Identifier les règles de pare-feu larges et valider avec Log Viewer.
- Vérifier les sauvegardes, correctifs, journalisation et reporting.
- Évaluer les fonctions de protection par règle.
- Documenter les exceptions justifiées au lieu de les surcharger sans commentaire.
- Vérifier à nouveau après les modifications.
- Documenter le résultat avec la date, le responsable et les points ouverts.
Pour les révisions récurrentes, un tableau simple avec constat, risque, mesure, responsable, statut et rappel suffit souvent. L’important est que les constats ne soient pas seulement vus, mais traités ou consciemment acceptés.
Limites
Le Health Check est utile, mais a des limites claires.
- Il ne connaît pas la logique métier complète de l’environnement.
- Il n’évalue pas si une règle est nécessaire professionnellement.
- Il ne remplace pas la segmentation du réseau et le modèle de zones.
- Il ne détecte pas automatiquement chaque cas particulier risqué.
- Il ne remplace pas un audit externe et une vérification manuelle des règles.
- Il ne dit pas si les alertes seront traitées plus tard.
Il faut donc considérer le Health Check comme un point de départ. Il rend les écarts visibles, mais la véritable qualité de sécurité résulte d’une bonne architecture, de processus propres et d’un entretien constant.
Liste de vérification opérationnelle
- Exécuter le Health Check après la mise en production et après des changements importants.
- Prioriser les constats par gravité et exposition.
- Vérifier l’accessibilité WAN de WebAdmin, SSH, User Portal et VPN Portal.
- Activer MFA pour les administrateurs, les portails et le Remote Access.
- Nettoyer ou justifier les règles de pare-feu larges.
- Activer la journalisation dans les règles importantes.
- Vérifier les sauvegardes et le processus de restauration.
- Documenter le processus de correctifs et de firmware.
- Ne définir des dérogations qu’avec une justification.
- Documenter régulièrement le résultat du Health Check.