Vérifier le stockage Sophos Firewall et gérer les rapports

Si un Sophos Firewall vous avertit d’un espace de stockage faible, vous ne devez pas immédiatement supprimer les fichiers ou désactiver les rapports. Il faut d’abord savoir clairement quelle partition est affectée, si les rapports locaux, les journaux, les files d’attente de courrier, la quarantaine, les fichiers de support ou un disque dur virtuel trop petit en sont la cause.

Cet article explique comment vérifier l’état de l’espace disque sur Sophos Firewall, gérer les rapports locaux de manière contrôlée et ne désactiver On-Box Reporting qu’une fois les conséquences comprises. Pour la conservation à long terme des journaux, Sophos Fusion Firewall Reporting constitue souvent un complément plus adapté, car il évite de dépendre uniquement des données des rapports locaux sur l’appliance.

⚠️ Important : La suppression de rapports efface irrémédiablement les données des rapports locaux. La désactivation d’On-Box Reports arrête la génération des rapports locaux dans son ensemble. Ces opérations sont distinctes du stockage et de la purge des Event Logs et des Troubleshooting Logs. Avant de les effectuer, vérifiez si les données nécessaires ont été exportées, sont conservées de manière centralisée ou ne sont plus requises à des fins de support et d’audit.

Lorsque l’espace de stockage devient critique

Les problèmes de stockage n’apparaissent pas toujours immédiatement. Les notifications typiques sont :

• E-mail d’avertissement ou notification dans Control Center signalant une utilisation élevée de l’espace disque.
• Les rapports se chargent lentement, restent vides ou n’affichent pas les données actuelles.
• Les fichiers journaux locaux connaissent une croissance rapide.
• Les services de rapport ou de base de données génèrent des erreurs.
• Une mise à niveau du firmware ou l’installation d’un hotfix signale un espace disque libre insuffisant.
• Virtual Firewall a été déployé avec un disque trop petit.
• La protection du courrier, la quarantaine ou le trafic web/applicatif élevé génèrent beaucoup de données locales.

Si des erreurs d’E/S, des redémarrages inhabituels ou des problèmes de base de données surviennent également en même temps, il ne suffit pas de libérer de l’espace. Il faut aussi vérifier la santé du SSD via SMART et les services et journaux pertinents.

Si le firewall est déjà en mode Failsafe, ne pas supprimer d’abord des Reports ou des fichiers. Vérifier une Sophos Firewall en mode Failsafe permet de consigner l’état affiché et les messages d’erreur disponibles avant de commencer l’analyse ciblée du stockage.

Pour les reports, il existe un seuil important : par défaut, le firewall avertit lorsque la partition concernée atteint 70 pour cent d’utilisation. À partir de 80 pour cent, la génération des reports s’arrête. Si reporting s’arrête pour cette raison, il ne suffit pas de revenir juste sous 80 pour cent ; l’utilisation doit repasser sous le seuil d’alerte pour que les reports soient à nouveau générés de manière fiable.

La notification par e-mail et SNMP au seuil supérieur est désactivée par défaut. Sous System services > Notification list > Disk/Memory, il faut activer Reports disk usage exceeded threshold pour l’e-mail, SNMP ou les deux destinations. Cela ne remplace pas la surveillance de l’avertissement précédent : Control Center et Log Viewer affichent déjà le seuil inférieur et le dépassement ultérieur.

Sur les très petites appliances, il faut aussi vérifier si les reports locaux sont pris en charge. Sophos cite les modèles XGS 87/87w et XGS 88/88w comme modèles sans On-Appliance Reporting. Dans ces environnements, la conservation centralisée via Sophos Fusion (anciennement Sophos Central) ou Syslog n’est pas seulement un confort, mais fait partie du design.

Ce qui occupe du stockage sur le firewall

De nombreuses données locales d’exploitation se trouvent dans /var. Le firewall y stocke notamment reports, Event Logs, Troubleshooting Logs et données d’autres composants. Selon le modèle d’appliance et les fonctions utilisées, chaque zone dispose de ses propres quotas. Un petit firewall de succursale ne se comporte donc pas comme une grande appliance avec davantage de capacité locale.

La distinction suivante est importante :

• Reports : les rapports ne sont plus enregistrés correctement ou doivent être raccourcis ou supprimés. Le risque est un historique local plus court et des analyses manquantes.
• Event Logs : les logs plus anciens sont supprimés, les nouveaux événements peuvent continuer à être écrits. L’analyse historique devient plus courte.
• Troubleshooting Logs : les anciens fichiers journaux compressés sont supprimés. Une fenêtre temporelle importante peut alors manquer pour les analyses de support.
• Quarantaine e-mail : les anciens messages en quarantaine peuvent être supprimés. La traçabilité et les processus de libération en souffrent.
• Fichiers temporaires ou fichiers copiés manuellement : ces fichiers peuvent bloquer inutilement de l’espace. La cause reste cachée si l’on supprime seulement les reports.

Les rapports occupent l’espace disponible dans /var. Les journaux de diagnostic (tslog) disposent en revanche d’une allocation par composant, selon le modèle d’appliance ; les composants critiques reçoivent davantage d’espace. Après la suppression des anciens fichiers compressés, de nouveaux journaux continuent d’être générés. L’espace de quarantaine e-mail se choisit sous Email > Quarantine settings. De nouveaux messages continuent aussi d’y être mis en quarantaine après la suppression des anciens. Cela ne garantit aucune durée de conservation précise.

Le quota des Event Logs dépend du modèle d’appliance. À titre d’exemple pour les modèles haut de gamme, Sophos indique au maximum 15 pour cent de l’ensemble de la partition /var ou 50 pour cent de l’espace /var actuellement libre, selon la valeur la plus faible. Il ne s’agit ni d’un quota fixe pour tous les modèles ni d’une durée de conservation garantie.

SFOS génère par défaut une alerte de composant presque plein uniquement pour les reports. Les Event Logs suppriment les anciennes entrées, les Troubleshooting Logs les anciens fichiers compressés et la quarantaine e-mail les anciens messages sans alerte de stockage propre. Une conservation externe et un monitoring doivent donc être planifiés avant la disparition automatique d’une période nécessaire.

Le Disk-Usage-Graph dans le WebAdmin aide au premier classement. Il distingue signatures, données de configuration, reports et stockage temporaire. Cela ne remplace pas une analyse détaillée, mais montre si les reports, les données temporaires ou d’autres zones semblent plutôt en cause.

Le piège le plus important consiste à confondre reports et logs. La conservation des reports sous Reports > Show Reports settings > Data management concerne les reports. Les Event Logs pour Log Viewer, Sophos Fusion et Syslog sont en revanche contrôlés sous System services > Log settings. Si l’on raccourcit seulement la conservation des reports, les Event Logs locaux ne diminuent pas automatiquement.

Après un arrêt ou un redémarrage, SFOS peut traiter des données de reports encore en attente et les attribuer au jour précédant le redémarrage plutôt qu’à l’heure réelle de l’événement. Une entrée à cette date ne prouve donc pas à elle seule que le trafic a réellement eu lieu à ce moment-là. Pour une chronologie d’incident, il faut corréler le report, l’uptime, les Event Logs et les logs externes disponibles.

Après les upgrades, un autre point est important : depuis SFOS 21.0, le firewall peut traiter les reports avant et après un upgrade dans des bases de données de reports séparées. Lors de l’analyse d’une journée d’upgrade, une sélection entre les données avant et après la migration peut donc apparaître. Si l’on revient à un ancien firmware après un upgrade, les reports générés depuis l’upgrade peuvent être perdus. Avant les travaux firmware, les reports locaux importants devraient donc être exportés ou disponibles de manière centralisée.

Vérifiez l’espace de stockage dans la console de l’appareil

Pour obtenir un aperçu rapide, vous pouvez vérifier l’espace disque utilisé dans la Device Console. La commande affiche les zones de stockage pertinentes de Sophos Firewall :

system diagnostics show disk

La console du périphérique est destinée aux commandes spécifiques à Sophos. Si l’accès via SSH doit être préparé, Sophos Firewall se connecter via SSH est utile. Il décrit également pourquoi SSH ne devrait être autorisé qu’à partir de réseaux d’administrateurs dignes de confiance.

Vérifiez l’espace de stockage dans le Advanced Shell

Dans l’Advanced Shell, vous pouvez examiner les systèmes de fichiers plus en détail. Cette commande affiche leur taille, l’espace disque utilisé, l’espace disque libre et le pourcentage d’utilisation :

df -hkm

S’il n’est pas clair si la sortie complète est trop large, vous pouvez spécifiquement regarder /var, car il y a beaucoup de données d’exploitation locales là-bas :

df -h /var

La commande est une pure lecture. Les fichiers des répertoires système ne doivent pas être supprimés manuellement simplement parce qu’une partition semble pleine. Premièrement, la cause doit être identifiée.

Si l’utilisation de l’espace disque dans /var est anormalement élevée, il faut d’abord vérifier les zones prévues par Sophos au lieu de supprimer des répertoires au hasard. Pour une première classification, les reports, Event Logs et Troubleshooting Logs sont particulièrement pertinents. Il faut aussi vérifier si Packet Capture, Debug Logging, fichiers de support ou fichiers copiés manuellement consomment de l’espace.

Pour les trois principales catégories d’utilisation de l’espace disque, Sophos indique ces commandes de lecture dans l’Advanced Shell. Les noms de répertoires relatifs supposent que /var est le répertoire de travail ; avant l’exécution, vérifiez que vous vous y trouvez. La sortie concerne l’espace disque, et non la mémoire vive (RAM) :

du -kh reportdb_16
du -kh eventlogs
du -kh tslog

Ces commandes servent à la classification. Elles ne remplacent pas un nettoyage supporté via WebAdmin, Device Console ou les fonctions de diagnostic prévues.

Cerner la cause

Un disque plein peut avoir plusieurs causes. La bonne prochaine étape dépend des données qui augmentent.

• Les reports occupent beaucoup d’espace : vérifier la durée de conservation sous Reports > Show Reports settings > Data management, exporter les reports ou utiliser Sophos Fusion Reporting.
• Les logs locaux augmentent fortement : vérifier Log settings, Debug Logging et les services concernés.
• Les Troubleshooting Logs augmentent fortement : vérifier Debug Logging, une analyse de support active ou des erreurs de service récurrentes.
• /var est visiblement plein : vérifier reports, logs, base de données, fichiers de support ou mailqueue.
• Le Disk Graph montre beaucoup de stockage temporaire : vérifier les captures actives, fichiers de support ou processus temporaires.
• Quarantaine e-mail ou Mail Spool augmente : vérifier Email > Quarantine settings et Email > Mail spool. Les messages bloqués doivent être contrôlés, redistribués de manière contrôlée ou supprimés.

Configurer et tester les rapports de quarantaine sur Sophos Firewall explique le nettoyage automatique de la zone de quarantaine à 90 %, le rapport, l’affectation des utilisateurs et le test de libération.

• Le firewall virtuel est trop petit : vérifier la taille du disque et les exigences de plateforme dans l’hyperviseur.
• Une alerte de stockage apparaît avant un firmware upgrade : ne pas lancer la mise à niveau à l’aveuglette, effectuer d’abord le SFOS 22 Upgrade Check.
• Un cluster HA est concerné : vérifier les deux nœuds séparément, car les logs et reports locaux ne sont pas forcément identiques.

S’il y a des défauts actifs, les journaux doivent d’abord être enregistrés pendant que l’erreur est récente. L’article Sophos Firewall Sauvegarde des journaux à des fins de support et d’analyse décrit comment exporter les données des journaux locaux.

Si les Event Logs consomment le stockage local, la rétention des reports n’est pas le bon levier. Il faut alors vérifier sous System services > Log settings quels modules sont stockés localement, envoyés à Sophos Fusion ou transmis à Syslog. Log Suppression peut aider à réduire les répétitions inutiles. Mais aucun événement pertinent pour la sécurité ne doit disparaître s’il est nécessaire plus tard pour l’Incident Response, le support ou la conformité.

Réduire de manière contrôlée l’espace de quarantaine et Mail Spool

Avant de réduire la quarantaine, vérifiez les exigences de conservation et de libération et sauvegardez les messages nécessaires. Si ces exigences le permettent, choisissez la plus petite option d’espace disque proposée pour Email quarantine sous Email > Quarantine settings. Sous Email > Mail spool, Retry permet une nouvelle tentative de livraison contrôlée et Delete supprime les messages. Vérifiez d’abord leur identité, les besoins de livraison et la conservation des preuves : Delete est irréversible. Contrôlez ensuite la file d’attente, le résultat de la livraison et l’espace libre ; Retry ne garantit pas une livraison réussie.

Arrêter la collecte de diagnostic avant de poursuivre le nettoyage

Coordonnez d’abord toute collecte de support en cours avec le support. Téléchargez les preuves nécessaires sous Diagnostics > Tools avec Troubleshooting logs ou Consolidated troubleshooting report, puis vérifiez les fichiers sauvegardés. Une fois les journaux nécessaires obtenus, désactivez le mode debug des composants concernés. Désactivez également la capture de paquets sous Diagnostics > Packet capture. Confirmez l’arrêt des deux collectes et vérifiez à nouveau l’évolution du stockage avant de purger d’autres journaux. Ne réactivez ensuite le debug ou la capture que pour un besoin de diagnostic limité dans le temps, pas systématiquement après le nettoyage.

Gérer séparément les rapports centraux et les journaux d’événements locaux

Pour les modules nécessaires, sélectionnez Central reporting sous System services > Log settings. L’enregistrement pour la gestion centralisée du pare-feu dans Sophos Fusion (anciennement Sophos Central) est un prérequis. Le pare-feu y envoie les journaux d’événements, à partir desquels des rapports sont générés et stockés. Ce réglage ne correspond ni à la conservation des rapports locaux ni au commutateur global On-Box Reports. Pour planifier la capacité, estimez les besoins de stockage avec le Data Storage Estimation Tool et comparez-les aux offres de stockage de la licence de reporting. L’activation de la transmission ne garantit pas à elle seule une durée de conservation adaptée.

Vous pouvez, en option, désactiver le stockage local des journaux d’événements pour certains ou tous les modules sous System services > Log settings. Confirmez d’abord la réception sur le serveur syslog externe, la conservation et l’adéquation aux besoins de support et de conformité ; consignez la sélection initiale des modules. Après le changement, vérifiez la poursuite de la réception externe, la limitation attendue du Log Viewer local et l’évolution du stockage. Si nécessaire, rétablissez la sélection locale initiale et vérifiez de nouveaux événements locaux. Ce retour arrière n’a pas été testé sur le produit ici et ne reconstitue pas les événements manquants. Les journaux locaux des services peuvent rester nécessaires ; l’avertissement concernant Log Suppression reste valable.

Ne supprimez pas manuellement dans le système de fichiers

Même si l’Advanced Shell affiche l’espace disque libre et les répertoires, il ne faut pas supprimer directement des fichiers dans /var, /log ou les répertoires de bases de données. Les suppressions manuelles peuvent endommager les rapports, les services ou les bases de données, compromettre les analyses du support et compliquer l’analyse ultérieure de la cause.

Une exception strictement limitée concerne les fichiers identifiés avec certitude que l’administrateur a lui-même copiés dans /var. Avant leur suppression, consignez le chemin exact, l’origine et l’usage, excluez toute dépendance active et conservez les preuves nécessaires hors du firewall. Supprimez uniquement cette copie identifiée, jamais un fichier système, de journal ou de base de données. Si l’origine est incertaine, arrêtez-vous et contactez le support. La suppression n’est pas une mesure de récupération réversible. Vérifiez ensuite l’espace libre et l’état des services concernés ; aucune commande de suppression manuelle ni caractère générique n’est volontairement indiqué ici.

Meilleur processus :

• Documenter l’état de l’espace disque et la partition concernée.
• Enregistrez les journaux pertinents ou le CTR si un cas de support est probable.
• Vérifier si Packet Capture ou Debug Logging est encore actif.
• Vérifier la conservation des rapports dans WebAdmin.
• Ne purgez les rapports délibérément qu’après avoir sauvegardé les données nécessaires : utilisez d’abord Manual purge dans WebAdmin ; n’utilisez Flush Device Reports que si cette purge ne libère pas suffisamment d’espace disque et si le redémarrage ainsi que l’interruption de l’accès Internet ont été préparés.
• Si la consommation continue d’augmenter, vérifiez la cause : journalisation du débogage, file d’attente de courrier, quarantaine, base de données, disque virtuel ou trafic local inhabituellement élevé.

Si vous ne savez pas quelles données occupent l’espace disque, n’utilisez pas rm. Il est alors plus sûr de sauvegarder les journaux et de contacter le support ou Avanet en leur transmettant les constats actuels.

Pour les Troubleshooting Logs, des commandes Device Console séparées permettent la purge. Elles ne remplacent pas l’analyse de cause et ne sont utilisées qu’après sauvegarde des logs nécessaires et identification sans ambiguïté du sous-système concerné :

system diagnostics purge-old-logs
system diagnostics purge-all-logs
system diagnostics subsystems <subsystem> purge-old-log
system diagnostics subsystems <subsystem> purge-log

Les deux premières commandes agissent sur tous les Troubleshooting Logs : purge-old-logs supprime les rotations compressées, tandis que purge-all-logs supprime également les fichiers actuels. Les deux variantes par sous-système limitent ces mêmes actions à un sous-système pris en charge. Vérifier le nom valide à l’aide de l’aide CLI ou de Tab Completion avant l’exécution. Une purge est irréversible ; en cas de doute, préférer un export ciblé sous Diagnostics > Tools.

Modifier les droits d’écriture de la partition de rapports uniquement de manière ciblée

La Device Console peut autoriser ou bloquer globalement les écritures sur la partition de rapports. La syntaxe de SFOS 22 mentionne uniquement report ; partition-name est un mot-clé et non un paramètre à remplacer par un chemin librement choisi. Avant toute modification, l’état lu avec show est consigné comme état initial approuvé ; la valeur par défaut du produit ne remplace pas cette consignation :

system filesystem enforce-disk-write partition-name report show

La valeur par défaut est enable. disable n’est pas un nettoyage du stockage et ne supprime aucun rapport. Cette valeur bloque les écritures sur la partition de rapports et peut donc rendre incomplets les données locales, les vues et les processus dépendants. Le paramètre est modifié uniquement comme mesure planifiée de récupération ou de support, pas comme tuning :

system filesystem enforce-disk-write partition-name report disable
system filesystem enforce-disk-write partition-name report show

Le retour arrière rétablit exactement l’état initial approuvé et consigné. Les commandes suivantes ne réautorisent les écritures que si cet état était enable et que la procédure l’a modifié en disable. Si la politique approuvée était déjà disable, elle reste désactivée ou est rétablie avec la commande disable présentée ci-dessus ; l’état est ensuite relu avec show. L’activation, approuvée par le support, d’une politique volontairement désactivée constitue une nouvelle mesure de récupération, et non un retour arrière :

system filesystem enforce-disk-write partition-name report enable
system filesystem enforce-disk-write partition-name report show

enable ne prouve pas à lui seul que la base de données de rapports et les vues locales écrivent à nouveau sans erreur. Après le rétablissement d’un état initial activé ou une nouvelle activation approuvée, si On-Box Reporting est actif, vérifiez une nouvelle période de rapport, Generate now, les tableaux de bord locaux, les rapports planifiés et l’évolution de l’espace disque utilisé. En revanche, si l’état initial était volontairement désactivé, confirmez avec show qu’il est bien disable ; la génération de rapports locaux n’est pas un critère de réussite dans ce cas. Vérifiez néanmoins l’évolution de l’espace disque utilisé et les processus qui restent nécessaires, notamment la conservation externe. Ces opérations ne reconstituent pas les données ou l’historique manquants. Si la partition reste en lecture seule malgré un enable approuvé ou si des erreurs d’E/S surviennent, ne basculez pas le paramètre à répétition ; vérifiez plutôt le SSD, le disque virtuel de rapports, l’état du montage et le dossier de support.

Ajuster la conservation du rapport dans WebAdmin

Si les rapports locaux sont en cause, commencez par vérifier leur durée de conservation. Dans de nombreux environnements, les rapports locaux sont encore conservés par habitude alors que leur analyse est désormais centralisée.

Le chemin Sophos pour la conservation locale des reports est :

Reports > Show Reports settings > Data management

Vous pouvez y définir, pour chaque module, une durée de conservation maximale d’un an, puis enregistrer avec Apply. SFOS décompte les mois à partir du mois précédent : le mois en cours n’est donc pas le premier mois de conservation. Les modifications prennent effet à 00:00. Ce réglage concerne les rapports, pas les Event Logs.

Questions utiles avant d’effectuer un changement :

• Les rapports locaux sont-ils vraiment encore en cours d’évaluation ?
• Existe-t-il déjà Sophos Fusion Reporting, un syslog ou un SIEM ?
• Combien de temps les données de journalisation et de rapport doivent-elles être stockées en interne ?
• Existe-t-il des exigences de conformité ou de support ?
• Une rétention locale plus courte est-elle suffisante lorsque le stockage central est actif ?

Si des journaux et des rapports sont nécessaires dans Sophos Fusion, vérifiez également quels types de journaux y sont envoyés sous System services > Log settings. L’activation est décrite dans Activer Sophos Fusion Firewall Reporting.

Personnaliser et mener à terme un export de rapports

Sous Reports > Show Reports settings > Data management, Export customization détermine les rapports inclus dans un export et le nombre d’enregistrements exportés par rapport. Avant de lancer l’export, sélectionnez uniquement les rapports nécessaires et définissez le nombre d’enregistrements par rapport. Ce réglage est distinct de la conservation et ne purge aucune donnée locale.

Effectuez l’export complet dans WebAdmin comme suit ; les rapports ne peuvent pas être téléchargés depuis la CLI :

1. Accédez à Reports et ouvrez Applications & web.
2. Sélectionnez les critères du rapport dans Show, puis la plage de dates.
3. Sélectionnez Generate et contrôlez le résultat.
4. Sélectionnez le format de fichier requis pour télécharger les données du rapport.
5. Ouvrez le fichier téléchargé et vérifiez qu’il contient les rapports, la période et le nombre d’enregistrements attendus avant de l’utiliser comme sauvegarde ou preuve d’audit.

Le nombre d’enregistrements par rapport configuré limite le contenu téléchargé. Un téléchargement réussi ne prouve donc pas que tous les enregistrements locaux ont été exportés ; comparez son périmètre aux exigences opérationnelles ou de conformité.

Supprimer les reports de manière contrôlée

Si les services ne fonctionnent plus correctement faute d’espace, une purge manuelle des rapports peut être nécessaire. Il s’agit d’une mesure de rétablissement contrôlée, et non d’une opération de maintenance courante.

Vérifiez au préalable :

• sauvegarde de la configuration actuelle disponible
• rapports requis exportés ou disponibles de manière centralisée
• périodes concernées documentées
• cause de l’augmentation de l’espace occupé comprise
• fenêtre de maintenance ou dossier de support préparé si le pare-feu est déjà instable

La première voie devrait être WebAdmin :

Reports > Show Reports settings > Manual purge

Après avoir choisi le module et le critère, vous pouvez indiquer une période personnalisée ou supprimer toutes les données du module. Un clic sur Purge lance immédiatement l’opération, qui est irréversible. La purge est volontairement lente : SFOS traite cinq tables de base de données par minute afin de préserver les ressources du système.

Flush Device Reports ne doit être utilisé que si Manual purge dans WebAdmin ne libère pas suffisamment d’espace disque. Un état de récupération ne suffit pas, à lui seul, à remplir cette condition documentée. L’option de console est la suivante :

5. Device Management > 4. Flush Device Reports

⚠️ Flush Device Reports supprime les rapports stockés sur le pare-feu et redémarre celui-ci. Pendant cette opération, le pare-feu est inaccessible par le réseau pendant environ dix minutes. Jusqu’à son retour en ligne, la connexion actuelle via la passerelle Internet est également interrompue : le trafic Internet passant par ce pare-feu est coupé. Il faut donc préparer une fenêtre de maintenance, informer les utilisateurs concernés et prévoir un accès approprié à la console avant l’exécution. Les exports et sauvegardes mentionnés précédemment doivent avoir été vérifiés ; il ne faut pas présumer qu’une sauvegarde de configuration permet de restaurer les rapports supprimés.

Après le retour en ligne, vérifiez la connexion via la passerelle Internet, l’espace disque libre, les rapports, Log Viewer, Sophos Fusion Reporting et les services concernés. Si l’espace disque reste insuffisant ou si les services ne fonctionnent pas de manière cohérente, conservez les constats actuels et contactez le support plutôt que de répéter aveuglément l’opération.

Flush Device Reports désigne la suppression documentée des rapports avec redémarrage, et non une procédure de formatage du disque de rapports. Il ne faut pas en déduire l’existence d’une option supplémentaire de formatage dans la console. Un formatage constituerait une intervention destructive distincte ; aucune procédure de formatage n’est présentée ici comme méthode de nettoyage.

Si des services sont déjà affectés par un stockage plein, il faut savoir avant la suppression quelles données manqueront ensuite. Les reports locaux sont souvent utiles pour les change reviews, l’analyse utilisateur, la traçabilité sécurité ou les questions de support. Lorsqu’ils sont supprimés, il faut une courte note avec période, raison et source de remplacement disponible, par exemple Sophos Fusion Reporting ou Syslog.

Vérifier ou désactiver les rapports On-Box.

On-Box Reports stocke les rapports localement sur le pare-feu. C’est pratique, mais cela peut consommer de l’espace disque sur les petites appliances, en cas de trafic important ou de longue durée de conservation.

Avant toute modification, vérifiez le statut dans la Device Console et consignez l’état affiché, on ou off, comme état initial :

show on-box-reports

Cette commande ne répond pas à la même question que system diagnostics show disk : show on-box-reports indique si les rapports locaux sont globalement actifs, tandis que system diagnostics show disk montre l’utilisation actuelle du stockage par zone. Pour un diagnostic propre, il faut généralement les deux vues.

Si les rapports locaux ne sont pas nécessaires et qu’un autre stockage est disponible, vous pouvez désactiver les rapports intégrés :

set on-box-reports off

Le retour arrière est préparé avant la désactivation et rétablit exactement l’état initial consigné. Les commandes suivantes avec on ne s’appliquent que si l’état enregistré était on et que cette procédure l’a effectivement modifié en off. Si On-Box Reporting était déjà off, il reste désactivé ou est rétabli avec la commande off présentée ci-dessus ; vérifiez ensuite à nouveau l’état avec show on-box-reports. Une nouvelle activation délibérément approuvée d’un reporting auparavant désactivé constitue une nouvelle décision d’exploitation ou de récupération, et non un retour arrière. on relance la génération des rapports locaux ; il ne faut pas présumer que les données manquantes de la période de désactivation seront reconstituées après coup :

set on-box-reports on
show on-box-reports

Après le rétablissement de on, vérifiez un nouveau rapport local, Log Viewer, un rapport planifié et l’évolution de l’espace disque utilisé. Le statut on ne prouve pas à lui seul que la base de données de reporting et les vues des rapports fonctionnent à nouveau de manière cohérente. En revanche, si l’état enregistré était off, confirmez avec show on-box-reports que l’état reste off, puis vérifiez l’évolution de l’espace disque utilisé, la solution de conservation alternative prévue et les processus de Log Viewer ou de reporting qui restent nécessaires. La génération d’un nouveau rapport local n’est pas exigée pour cet état initial désactivé.

Cette opération doit être effectuée uniquement de manière délibérée. Les rapports sont importants pour l’analyse, le support et l’exploitation. Dans de nombreux environnements de production, il est préférable de réduire la durée de conservation locale et d’utiliser en parallèle Sophos Fusion Reporting, Syslog ou un SIEM. Si une conservation centralisée plus longue est nécessaire, Sophos Central Firewall Reporting Advanced constitue une option possible.

Important : les On-Box Reports ne peuvent être activés ou désactivés que globalement, pas sélectivement par module. Si seuls certains domaines de reporting consomment trop d’espace, une durée de conservation plus courte ou un purging ciblé est souvent préférable à une désactivation complète d’On-Box Reporting.

Si On-Box Reports est désactivé, il ne faut pas seulement vérifier le stockage ensuite. Les processus internes changent aussi : vues locales des reports, rapports PDF planifiés, analyses de sécurité et analyses ad hoc rapides sur le firewall peuvent disparaître ou devenir moins utiles. Cette étape relève donc d’une décision d’exploitation, pas d’un nettoyage spontané du stockage.

Classer les seuils d’alerte et les alerts

Sophos Firewall peut générer des Control-Center-Alerts et Event Logs lorsque l’utilisation de /var est élevée. Le seuil d’alerte peut être contrôlé via la Device Console avec set var-partition-usage watermark. Ce n’est toutefois pas une correction de stockage. Un seuil plus bas ou plus haut ne change que le moment où une alerte apparaît, pas la raison pour laquelle de l’espace est consommé.

La plage autorisée va de 50 à 75 pour cent, avec 70 pour cent comme valeur par défaut. Reporting s’arrête à 80 pour cent, et cet arrêt n’est pas la limite d’exploitation réelle, mais déjà un état d’erreur. Un seuil d’alerte plus élevé ne rend donc pas le firewall plus stable, il réduit seulement le temps de réaction.

Avant toute modification, lisez et consignez la valeur actuelle dans la Device Console. La documentation de SFOS 22 utilise report-disk-usage pour consulter le seuil et var-partition-usage pour le modifier. Vérifiez la syntaxe avec l’aide CLI sur la version cible ; si la valeur actuelle ne peut pas être lue, ne modifiez pas le seuil d’alerte :

show report-disk-usage watermark
set var-partition-usage watermark <50-75>
set var-partition-usage watermark default

default place le seuil d’alerte à 70 pour cent et ne restaure pas automatiquement une ancienne valeur personnalisée. Pour le retour arrière, définir explicitement le nombre enregistré auparavant avec show. Le commutateur ne modifie ni la limite de 80 pour cent qui arrête Reporting, ni les reports, logs ou un manque de capacité existant.

Pour l’exploitation, il est généralement plus utile de :

• activer les notifications e-mail ou SNMP pour les alertes de stockage ;
• traiter les alertes de stockage sans attendre la prochaine fenêtre de maintenance ;
• adapter la conservation, le Debug Logging et l’utilisation des reports locaux en cas d’alertes récurrentes ;
• vérifier consciemment l’espace libre avant les firmware upgrades.

Si l’utilisation augmente nettement ou si les reports s’arrêtent déjà, il faut d’abord libérer de l’espace et clarifier la cause. Un seuil d’alerte modifié ne doit pas servir à masquer un vrai problème de capacité.

Faites attention aux pare-feu virtuels

Avec les Sophos Firewall virtuels, la cause n’est pas toujours dans les rapports ou les journaux. Parfois, l’appliance virtuelle a été déployée avec trop peu de disque ou s’est développée sur plusieurs années sans réévaluer les exigences de la plate-forme.

Dans les environnements virtuels, il faut également vérifier :

• Taille du disque virtuel.
• Espace libre sur la banque de données.
• Instantanés, tâches de sauvegarde et latence de stockage.
• Surveillance de l’hyperviseur.
• Vérifier si la version du pare-feu impose des besoins supplémentaires en espace disque.
• Si le disque virtuel peut être étendu en ligne ou si un reimage avec Restore est la voie la plus propre.

Si le disque est fondamentalement trop petit, la suppression des rapports n’est qu’un soulagement à court terme. La plateforme virtuelle doit ensuite être correctement adaptée et sécurisée avec une sauvegarde, une fenêtre de maintenance et un plan de restauration.

Avant SFOS 22, ce point est particulièrement important : si le firewall affiche une alerte de stockage ou un bloqueur de mise à niveau lié au disque virtuel, il faut d’abord traiter le SFOS 22 Upgrade Check. Les indications officielles Sophos concernant le disque virtuel y sont liées. L’extension doit être planifiée dans une fenêtre de maintenance avec sauvegarde, stockage hyperviseur vérifié et validation ultérieure des partitions.

Sur les appliances matérielles, l’extension de disque n’est en revanche pas la voie normale. Il faut y vérifier consommation de stockage, reports, logs, quarantaine et santé SSD, puis préparer un processus de support ou RMA en cas de soupçon matériel.

Liste de contrôle

Vérifiez immédiatement

• Le message d’avertissement, l’heure et le pare-feu concerné sont documentés.
• system diagnostics show disk exécuté dans la console du périphérique.
• df -hkm vérifié dans le Advanced Shell.
• Partition présentant une utilisation anormale de l’espace disque identifiée et consignée.
• Disk-Usage-Graph dans le WebAdmin vérifié pour une première classification.
• Rapports, journaux, file d’attente de courrier, quarantaine et disque virtuel évalués comme causes possibles.
• Packet Capture et Debug Logging vérifiés comme sources de stockage à court terme.

Avant de supprimer ou de désactiver

• Sauvegarde des rapports et journaux requis.
• Sophos Fusion Reporting, syslog ou autre stockage central vérifiés.
• Chemin de sauvegarde et de récupération disponible.
• Fenêtre de maintenance définie lorsque les services productifs sont affectés.
• En HA, les deux nœuds ont été vérifiés séparément.
• Période et raison d’un nettoyage des reports documentées.

Après le nettoyage

• Espace disque libre vérifié à nouveau.
• Rapports vérifiés conformément à l’état initial consigné, actif ou désactivé, et Log Viewer vérifié ; si le reporting local est désactivé, la génération de nouveaux rapports locaux n’est pas exigée comme critère de réussite.
• Présence de données récentes vérifiée dans Sophos Fusion Reporting ou Syslog.
• Cause de l’augmentation de l’espace disque utilisé documentée.
• Période de conservation, paramètres de journal et processus de révision ajustés.
• Notifications pour les futures alertes de stockage vérifiées.

FAQ