Contrôler Sophos Firewall chaque jour : checklist d'exploitation

Une Sophos Firewall peut rester techniquement accessible tout en présentant des signes avant-coureurs : une connexion WAN devient instable, l’utilisation du disque augmente, un service signale une erreur ou les échecs de connexion administrateur se multiplient. Un contrôle d’exploitation court et reproductible rend ces changements visibles avant qu’ils ne provoquent une interruption prolongée ou un incident de sécurité.

Cette procédure concerne le fonctionnement actuel. Le Health Check de Sophos Firewall détermine en revanche si certaines configurations respectent les recommandations Sophos et CIS. Les deux contrôles se complètent, mais ne se remplacent pas.

Le contrôle en dix minutes

Une procédure fixe suffit pour la vue quotidienne :

1. Dans le Control Center, contrôler les nouveaux messages ainsi que l’état des services, du WAN, des interfaces, des VPN et de l’uptime.
2. Sous Diagnostics > System graphs, comparer le CPU, la mémoire, la charge moyenne, le disque et les interfaces importantes à la baseline habituelle.
3. Contrôler les tableaux de bord de sécurité et les rapports utilisés sur la dernière période entièrement disponible afin de détecter de nouveaux événements IPS, web, application, zero-day ou Active Threat Response.
4. Dans le Log Viewer, contrôler les échecs de connexion administrateur, les sources inhabituelles et les services associés.
5. En HA, tenir compte du nœud ayant traité le trafic et, pour le reporting central, de la source de données attendue.
6. Documenter chaque écart pertinent avec l’heure, le firmware, le nœud, la source, le service concerné et l’étape suivante.
7. Ne pas redémarrer de services, supprimer de logs ou élargir de règles à cause d’un seul pic. Corréler d’abord la tendance, les logs et le fonctionnement réel.

Ce contrôle court ne doit pas déclencher une modification de configuration chaque matin. Il sert à détecter rapidement les changements et à décider clairement si une observation, un diagnostic ou une escalade est nécessaire.

Quatre vues, quatre informations différentes

Les vues principales ne montrent pas la même chose :

• Control Center : vue actuelle du système, des services, du WAN, des interfaces, des VPN, de l’uptime et des messages nécessitant une action.
• System graphs : évolution dans le temps du CPU, de la mémoire, de la charge moyenne, du disque, du transfert WAN et des compteurs d’interface.
• Reports : évaluation consolidée d’une période terminée. Certains widgets et certaines données de rapports ne sont pas actualisés en temps réel.
• Log Viewer : événements individuels avec heure, module, action, informations de source et de destination et, selon le type de log, Rule ID ou autres détails.

Un widget rouge est un signal, pas encore un diagnostic complet. De même, un état vert actuel ne prouve pas qu’aucune erreur brève ne s’est produite pendant la nuit. Seule la combinaison de l’état actuel, de l’évolution, du rapport et de l’événement individuel donne une image fiable.

Contrôler l’état et la disponibilité du système

Lire d’abord le Control Center

Dans le Control Center, le contrôle commence par les nouveaux messages. Sophos y affiche notamment des problèmes d’enregistrement, de licence, de reporting, de WAN ou de mise à niveau. Certains messages disparaissent automatiquement après correction et ne peuvent pas simplement être supprimés manuellement. Chaque message pertinent nécessite donc un responsable et une étape suivante traçable.

Les services, connexions WAN, interfaces et VPN réellement utilisés sont ensuite comparés à l’état attendu. Une interface rouge ne signifie pas automatiquement une panne : un port inutilisé sans adresse IP ou une interface physique parente d’un VLAN peut apparaître rouge comme prévu. L’écart par rapport au design documenté est le critère pertinent.

Un contrôle quotidien comprend au minimum :

• les services arrêtés ou dégradés de manière inattendue ;
• les liens WAN down ou dont l’état change régulièrement ;
• les interfaces de production présentant de nouvelles erreurs, pertes ou collisions ;
• les connexions VPN importantes déconnectées contrairement au plan d’exploitation ;
• un redémarrage inattendu ou une uptime anormalement courte ;
• les nouveaux messages sans responsable ni ticket.

Lire les System graphs par rapport à une baseline

Sous Diagnostics > System graphs, il faut rechercher des tendances plutôt que de simples pics. Le CPU, la mémoire et la charge moyenne sont évalués avec le nombre de cœurs, le trafic et la période concernée. Un pic court pendant une sauvegarde, un reporting ou une mise à jour de patterns n’a pas la même signification qu’une charge durablement élevée avec un trafic normal.

Pour Disk Usage, la tendance compte avant tout. Une utilisation élevée ponctuelle et une croissance constante représentent deux problèmes différents. Pour les interfaces, le trafic, les erreurs, les pertes et les collisions permettent de distinguer la charge de la firewall d’un problème de lien, duplex, câble ou switch.

L’explication détaillée de la charge moyenne, de l’offloading, de TLS Inspection et des System graphs figure dans Interpréter les performances de Sophos Firewall. Pour les limites de stockage et les rapports sur l’appliance, consulter Contrôler le stockage et les rapports de Sophos Firewall.

⚠️ Une seule valeur élevée ne justifie pas encore le redémarrage d’un service. L’heure, la durée, le caractère récurrent, le trafic concerné et les logs doivent d’abord être corrélés. Avant un redémarrage, les logs pertinents et, lors d’un incident, un CTR sont sauvegardés.

Contrôler les événements de sécurité et les connexions administrateur

Lire les rapports pour détecter les changements

La revue quotidienne de sécurité se concentre sur les tendances nouvelles ou nettement modifiées. Selon les fonctions activées, les zones suivantes sont particulièrement pertinentes :

• Reports > Dashboards > Security dashboard pour la vue consolidée ;
• Reports > Network & threats > Intrusion attacks pour les événements IPS ;
• Reports > Network & threats > Active threat response pour les IoC bloqués ;
• Reports > Applications & web pour l’utilisation web et applicative risquée, indésirable ou bloquée ;
• les rapports zero-day, Security Heartbeat ou Wireless si ces fonctions sont utilisées en production.

Chaque événement n’est pas un incident. La source, la destination, l’utilisateur, la règle, l’action, la fréquence et le contexte temporel sont déterminants. Un seul accès provenant d’un pays ne justifie pas un blocage global de ce pays. Des attaques répétées contre un service exposé ou un nouveau trafic à haut risque autorisé méritent en revanche une analyse précise.

Pour évaluer les sources et les pays en toute sécurité, consulter Bloquer les adresses IP et les pays malveillants. Si un paquet a été rejeté, Analyser les paquets rejetés sur Sophos Firewall mène du Log Viewer et de la Rule ID à la cause réelle du rejet.

Évaluer les échecs de connexion administrateur

Les échecs de connexion administrateur sont examinés selon l’heure, l’adresse IP source, le service de destination, le nom d’utilisateur et la répétition. Une faute de frappe depuis le réseau de gestion doit être traitée autrement que des tentatives distribuées depuis Internet ou des connexions répétées à un compte désactivé.

Pour les tentatives suspectes, contrôler d’abord l’exposition et l’identité :

1. WebAdmin, SSH, User Portal ou VPN Portal doit-il être accessible depuis la zone concernée ?
2. La source appartient-elle à un réseau de gestion autorisé ou à une Local Service ACL Exception ciblée ?
3. La MFA est-elle active pour l’accès administratif concerné ?
4. CAPTCHA, le délai d’expiration de session et Block login fonctionnent-ils comme prévu ?
5. Existe-t-il des modifications de configuration simultanées ou des connexions réussies avec le même compte ?

L’accès réseau se contrôle sous Device Access et Local Service ACL sur Sophos Firewall. Pour les comptes, les profils et l’offboarding, consulter Administrateurs locaux et profils d’accès aux appareils, et pour le second facteur, Activer la MFA sur Sophos Firewall.

⚠️ Block login peut bloquer l’adresse IP source pour plusieurs services après des échecs. Ne pas durcir agressivement les valeurs pendant un incident tant qu’aucun accès administrateur alternatif et aucune procédure de récupération testés ne sont disponibles.

Comprendre les limites de HA, du reporting et des modèles

Dans un cluster HA, chaque nœud ne stocke que les logs et rapports du trafic qu’il a lui-même traité. Pour un événement, il faut donc identifier le nœud actif ou ayant traité le trafic à ce moment. Un rapport local vide sur un nœud ne prouve pas qu’aucun événement ne s’est produit dans le cluster.

Sophos Central Firewall Reporting peut fournir une vue consolidée et une rétention plus longue. Les vues locale et centrale ne sont toutefois pas considérées comme des sources temps réel identiques. Activer et exploiter Central Firewall Reporting explique la sélection, l’arrivée et la rétention des logs.

Limites supplémentaires :

• Les rapports du Control Center sont mis à jour périodiquement et ne constituent pas une vue temps réel des événements.
• Après une mise à niveau depuis une version antérieure à SFOS 21, les widgets de rapports peuvent initialement afficher peu ou pas de données jusqu’à l’actualisation de la nouvelle base de données de rapports.
• Les XGS 87/87w et XGS 88/88w ne prennent pas en charge les rapports on-appliance. Les logs centralisés, le SIEM et le monitoring sont donc plus importants sur ces modèles.
• L’absence de données peut être due au logging, à la période du rapport, à la licence, à la rétention, au disk watermark ou au mauvais nœud HA. Elle ne prouve pas automatiquement l’absence de trafic.

Documenter et escalader les écarts

Un contrôle quotidien n’est terminé que lorsque les écarts pertinents ont une étape suivante. Pour un ticket ou un journal d’exploitation, les champs suivants suffisent généralement :

• date, heure et fuseau horaire ;
• nom de la firewall, modèle, version SFOS et build ;
• en HA : nœud, rôle et dernier changement d’état ;
• fonction, zone, interface, VPN ou règle concernés ;
• état observé et état attendu ;
• capture d’écran, période du rapport, filtre de logs ou Rule ID ;
• impact sur les utilisateurs ou les services ;
• responsable, priorité, prochain contrôle et voie d’escalade.

Une escalade immédiate est pertinente lorsqu’un lien WAN de production ou un chemin VPN critique tombe en panne de manière inattendue, qu’un service de protection est arrêté, que l’utilisation du disque continue d’augmenter, que la charge reste élevée, que des attaques administrateur répétées coïncident avec une connexion réussie ou qu’un nouvel événement de sécurité correspond à un trafic malveillant autorisé.

Une observation suffit plutôt pour un pic bref et explicable, une interface volontairement inutilisée ou un événement connu qui possède déjà un responsable documenté et une validation fonctionnelle stable.

Choisir une fréquence de contrôle utile

Sophos ne prescrit pas un rythme quotidien universel pour chaque vue. La fréquence dépend donc du risque, des horaires d’exploitation et du monitoring existant :

• Chaque jour ou à chaque équipe : nouveaux messages, services arrêtés, WAN/VPN/HA, uptime, événements de sécurité critiques et échecs de connexion administrateur.
• Chaque semaine : tendances des graphiques, erreurs d’interface, croissance du disque, tendances des rapports, sources récurrentes et tickets ouverts.
• Après une modification, une mise à niveau ou un failover : valider à nouveau la fonction concernée, les logs, les rapports, le chemin d’alerte et le trafic réel.
• Régulièrement en dehors du contrôle court : Health Check, revue des règles, test de restauration de sauvegarde, expiration des licences et certificats et planification des capacités.

Les notifications par e-mail ou le monitoring réduisent le délai de réaction, mais ne remplacent pas la revue. Un chemin d’alerte n’est fiable qu’après avoir testé le transport, la sélection des événements, le destinataire et la réaction. La procédure complète figure dans Configurer et tester les notifications e-mail de Sophos Firewall.

Checklist d’exploitation

• Contrôler le Control Center pour détecter les nouveaux messages et les changements d’état inattendus.
• Comparer les services, les liens WAN de production, les interfaces, les VPN et l’uptime avec l’état attendu.
• Lire le CPU, la mémoire, la charge moyenne, le disque et les compteurs d’interface importants par rapport à la baseline.
• Contrôler les rapports de sécurité pour la dernière période entièrement disponible.
• Corréler les événements suspects dans le Log Viewer avec la source, la destination, l’utilisateur, l’action et la Rule ID.
• Évaluer les échecs de connexion administrateur selon la source, le service et la répétition.
• En HA, tenir compte du nœud ayant traité le trafic et des logs locaux à chaque nœud.
• Ne pas déclencher de redémarrage, de suppression de logs ou de modification large des règles sans préserver les preuves et disposer d’une procédure de retour.
• Documenter chaque écart pertinent avec un responsable, une priorité et une étape suivante.
• Après une correction, tester à nouveau non seulement l’état, mais aussi le fonctionnement réel.

FAQ