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.

L’article explique comment vérifier l’état de stockage sur le Sophos Firewall, gérer les rapports locaux de manière contrôlée et désactiver les rapports sur boîte uniquement lorsque les implications sont comprises. Pour la conservation des journaux à long terme, Central Firewall Reporting est souvent un meilleur ajout, car vous ne dépendez pas uniquement des données des rapports locaux sur l’appliance.

⚠️ Important : La suppression de rapports ou la désactivation des rapports intégrés peut supprimer irrémédiablement les rapports locaux et les données des journaux. Avant de prendre de telles mesures, il convient de vérifier si les données requises sont exportées, stockées de manière centralisée ou ne sont plus nécessaires à des fins d’assistance 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 du centre de contrôle concernant une consommation de mémoire élevée.
• 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.
• La mise à niveau du micrologiciel ou l’installation d’un correctif signale une mémoire libre insuffisante.
• 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.

Pour les reports, il existe un seuil important : par défaut, la 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.

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 Central ou Syslog n’est pas seulement un confort, mais fait partie du design.

Ce qui occupe du stockage sur la firewall

De nombreuses données locales d’exploitation se trouvent dans /var. La 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. Une petite 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.

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 Central 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 les upgrades, un autre point est important : depuis SFOS 21.0, la 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 un aperçu rapide, vous pouvez vérifier l’espace de stockage utilisé dans la console de l’appareil. La commande affiche les zones de mémoire pertinentes du 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 Advanced Shell, vous pouvez examiner de plus près les systèmes de fichiers. Cette commande affiche la taille, la mémoire utilisée, la mémoire 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 /var est visible, 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 blocs de stockage typiques, Sophos indique ces commandes de lecture dans l’Advanced Shell :

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.

Limiter 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 Central 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.
• La firewall virtuelle est trop petite : 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 Central 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é.

Ne supprimez pas manuellement dans le système de fichiers

Même si le Advanced Shell affiche de la mémoire et des répertoires libres, les fichiers ne doivent pas être supprimés directement dans /var, /log ou dans les répertoires de base de données. Les actions de suppression manuelle peuvent endommager les rapports, les services, les bases de données ou les analyses de support et rendre plus difficile l’analyse ultérieure des causes profondes.

Meilleur processus :

• État de stockage du document et partition affecté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érifiez la conservation du rapport via WebAdmin.
• Uniquement les rapports vides via le point de console prévu s’il est clair que les données locales peuvent être omises.
• 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é.

S’il n’est pas clair quelles données occupent la mémoire, vous ne devez pas travailler avec rm. Il est alors plus sûr de sauvegarder les journaux et d’impliquer le support ou Avanet avec les résultats actuels.

Pour les Troubleshooting Logs, il existe des commandes Device Console séparées pour le purge. Elles ne remplacent pas l’analyse de cause et ne devraient être utilisées qu’une fois les logs nécessaires sauvegardés. En résumé, system diagnostics purge-old-logs supprime les anciens logs compressés, tandis que system diagnostics purge-all-logs supprime tous les Troubleshooting Logs. Il existe des variantes spécifiques pour certains sous-systèmes. En cas de doute, un export ciblé sous Diagnostics > Tools est plus propre qu’un purge global.

Ajuster la conservation du rapport dans WebAdmin

Si des rapports locaux en sont la cause, la période de conservation doit être vérifiée en premier. Dans de nombreux environnements, des rapports sur boîte ont toujours été réalisés, même si l’évaluation proprement dite est désormais effectuée de manière centralisée.

Le chemin Sophos pour la conservation locale des reports est :

Reports > Show Reports settings > Data management

On peut y ajuster la durée de conservation par module de report et enregistrer avec Apply. La modification agit sur les reports, pas sur les Event Logs. Sophos précise en outre que les modifications de conservation des reports ne prennent effet qu’à 00:00.

Questions utiles avant d’effectuer un changement :

• Les rapports locaux sont-ils vraiment encore en cours d’évaluation ?
• Existe-t-il déjà un reporting central, 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 requis dans Sophos Central, il faut également vérifier quels types de journaux sont envoyés à Central sous Services système > Paramètres des journaux. L’activation est décrite dans Activer le rapport central du pare-feu.

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

Si les services ne fonctionnent plus correctement en raison d’une mémoire pleine, un nettoyage manuel des rapports peut s’avérer nécessaire. Mais il devrait s’agir d’une mesure de rétablissement contrôlée et non d’un processus opérationnel normal.

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
• Raison de la croissance du stockage 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

Cela permet de supprimer les reports de manière ciblée par module et période. Cette opération peut être lente, car la firewall purge les reports de manière contrôlée afin de préserver les ressources système.

Si cela ne suffit pas ou si la firewall est déjà dans un état de récupération, il existe le point de console :

5. Device Management > 4. Flush Device Reports

Après la suppression, vous ne devez pas simplement revenir aux opérations quotidiennes. Il est important de vérifier si la mémoire libre augmente réellement et si les rapports, Log Viewer, le reporting central et les services concernés fonctionnent à nouveau de manière plausible.

Flush Device Reports supprime les reports stockés sur la firewall et redémarre la firewall. Pendant ce temps, elle n’est pas joignable via le réseau pendant environ dix minutes. Cette étape doit donc se faire dans une fenêtre de maintenance ou dans un processus de récupération documenté.

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 Central Reporting ou Syslog.

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

Les rapports On-Box enregistrent les rapports localement sur le pare-feu. C’est pratique, mais peut utiliser de la mémoire pour les petits appareils, un trafic élevé ou un stockage long.

Vous pouvez vérifier l’état dans la console de l’appareil :

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

Cela devrait simplement être mis au courant. Les rapports sont importants pour l’analyse, le support et les opérations. Dans de nombreux environnements productifs, il est préférable de réduire le stockage local et d’utiliser en parallèle le reporting central, Syslog ou un SIEM. Si une conservation centrale plus longue est requise, Sophos Central Firewall Reporting Advanced est 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, reports planifiés, analyses de sécurité et analyses ad hoc rapides sur la 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 la firewall plus stable, il réduit seulement le temps de réaction.

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.
• Indique si la version du pare-feu spécifie des exigences de mémoire supplémentaires.
• 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 la 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 inhabituelle remarqué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.
• Rapports centraux, 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.
• À 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

• Mémoire libre vérifiée à nouveau.
• Rapports et Log Viewer testés.
• Central Reporting ou Syslog ont vérifié les données actuelles.
• Cause de la croissance de la mémoire 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