Planifier les rapports Sophos Firewall et les envoyer par e-mail

Sophos Firewall peut envoyer des rapports locaux au format PDF chaque jour ou chaque semaine. Pour que le destinataire reçoive une analyse utile plutôt qu’un fichier quelconque, le rapport est d’abord vérifié manuellement, puis seulement planifié.

La procédure fiable est courte :

1. Générer manuellement le rapport souhaité avec la période et le filtre prévus.
2. Enregistrer la sélection comme bookmark si nécessaire.
3. Créer une planification sous Reports > Show report settings > Report scheduling.
4. Vérifier le chemin de messagerie avec Send test mail.
5. Générer et envoyer immédiatement le rapport avec Generate now.
6. Contrôler dans le PDF reçu le contenu, la période, la langue et les données sensibles.

Send test mail et Generate now ne vérifient pas la même chose : l’e-mail de test confirme le transport de messagerie. Seul Generate now vérifie en plus que le firewall génère le rapport sélectionné et l’envoie au format PDF.

⚠️ Les modèles XGS 87/87w et XGS 88/88w ne prennent pas en charge On-appliance Reporting. Pour ces modèles ou pour une analyse centralisée de plusieurs firewalls, utiliser Sophos Central Firewall Reporting dans Sophos Fusion.

Vérifier les prérequis

Avant de créer la planification, six bases doivent être clarifiées :

• Les rapports locaux fonctionnent : Sous Reports, la période souhaitée contient déjà des données plausibles. Une planification ne peut pas corriger une journalisation manquante ni une base de données de rapports vide.
• L’envoi d’e-mails fonctionne : Le serveur de messagerie intégré ou externe ainsi que les réglages nécessaires pour l’authentification, la sécurité de la connexion, l’expéditeur et le destinataire sont configurés sous Administration > Notification settings. La procédure complète est décrite dans Configurer et tester les notifications e-mail Sophos Firewall.
• L’heure et le fuseau horaire sont corrects : Une heure système incorrecte complique la sélection et le contrôle de la période. Configurer la date, l’heure et NTP explique la configuration.
• Le stockage local est disponible : Les données de rapports On-box se trouvent sous /var. Lorsque le seuil d’arrêt est atteint, le firewall suspend le reporting. Vérifier le stockage Sophos Firewall et gérer les rapports explique l’état, les seuils d’alerte et la conservation.
• La conservation locale correspond à l’objectif : Sous Reports > Show report settings > Data management, les rapports peuvent être conservés pendant un an au maximum. La période choisie est calculée à rebours depuis le mois précédent et toute modification prend effet à 00:00. Ce réglage concerne uniquement les rapports, pas les logs ni les PDF déjà livrés dans une boîte aux lettres. Le firewall supprime automatiquement les rapports plus anciens. Avant de modifier la durée de conservation, vérifier donc les exigences de conformité et de conservation de l’organisation.
• Le destinataire et l’objectif sont définis : Une boîte fonctionnelle telle que firewall-reports@example.net est généralement préférable à une adresse personnelle. Elle doit avoir un responsable qui contrôle réellement les rapports.

Un PDF peut contenir des utilisateurs, adresses IP, adresses MAC, adresses e-mail, URLs et événements de sécurité. Il faut donc limiter les destinataires, chiffrer le transport de messagerie et tenir compte de la conservation dans la boîte aux lettres. Si Data Anonymization pour les logs et les rapports est utilisé, vérifier dans le PDF réellement reçu que les données attendues sont anonymisées.

Si le reporting s’est arrêté faute d’espace, ramener l’utilisation de /var juste sous 80 % ne suffit pas. Elle doit descendre sous le seuil d’avertissement, normalement 70 %, pour que le firewall recommence à générer des rapports. Le seuil d’avertissement est réglable de 50 à 75 % ; le seuil d’arrêt à 80 % est fixe. Control Center affiche les avertissements et alertes, et Log Viewer consigne aussi le retour sous le seuil d’avertissement. Les notifications e-mail et SNMP au seuil supérieur sont désactivées par défaut : sous System services > Notification list > Disk/Memory, activer Reports disk usage exceeded threshold pour les destinations nécessaires et enregistrer avec Save. Vérifier ensuite l’état et les nouvelles données ; la réception d’un ancien PDF ne prouve pas la reprise de la génération. Le diagnostic et le nettoyage sûrs restent décrits dans l’article sur le stockage déjà lié.

Contrôler globalement Top Users dans les rapports PDF

La commande Device Console peu explicite system custom-feature détermine si les rapports PDF générés incluent également Top Users. Ce commutateur est global et ne comporte aucun paramètre de rapport ou de destinataire. Comme l’aide SFOS 22 actuelle n’indique pas de valeur par défaut, lire d’abord l’état existant :

system custom-feature show

Avant toute modification, consigner le réglage affiché comme état initial approuvé ; il détermine le retour arrière.

enable ajoute Top Users et disable les retire à nouveau des PDF générés :

system custom-feature enable
system custom-feature disable

Avant enable, vérifier les destinataires, la conservation et Data Anonymization. Utiliser ensuite Generate now pour produire un PDF réel et contrôler que les utilisateurs attendus apparaissent et que les identités sensibles sont protégées comme prévu. Le commutateur ne crée pas une attribution utilisateur manquante et ne corrige pas un problème d’authentification ou de logging. Pour le retour arrière, rétablir exactement l’état initial consigné : system custom-feature enable si la fonction était activée, ou system custom-feature disable si elle était désactivée. Si elle était déjà activée, répéter enable ne change rien ; ne pas la désactiver sous prétexte de revenir en arrière. Confirmer ensuite l’état initial avec system custom-feature show et vérifier un nouveau PDF avec Generate now : Top Users doit être présent ou absent selon le réglage enregistré. Ce retour arrière ne promet ni le traitement rétroactif de données manquantes ni la restauration d’un historique de rapports perdu.

Préparer le contenu du rapport

Dans cet exemple, un rapport IPS hebdomadaire doit indiquer les attaques détectées le plus fréquemment. Les noms et valeurs sont adaptés à l’environnement local.

1. Ouvrir Reports > Network & threats > Intrusion attacks.
2. Sélectionner la période souhaitée.
3. Utiliser Filter pour limiter l’analyse aux systèmes, règles ou événements pertinents si nécessaire.
4. Sélectionner Generate.
5. Vérifier que la période, les hits et le tri correspondent à la question prévue.

L’objectif opérationnel doit pouvoir être expliqué en une phrase, par exemple : « Chaque lundi, l’équipe de sécurité contrôle les hits IPS les plus fréquents de la semaine précédente. » Cette formulation aide à déterminer le rapport, le filtre et le destinataire réellement nécessaires.

Il est possible de sélectionner un logo personnalisé (Custom logo) pour les rapports générés ; ce logo est alors affiché sur les rapports.

Choisir le groupe de rapports approprié

Sous Reports, sélectionner le groupe ou l’analyse avec Show, puis la plage de dates. Generate actualise les données, Filter les restreint et Schedule ouvre la planification directement depuis la vue du rapport. Le choix doit répondre à la question d’exploitation, pas seulement au nom du rapport :

• Dashboards : Traffic dashboard présente le trafic par application, catégorie Web et utilisateur. Security dashboard montre les activités refusées, les malwares, le spam et les principaux pays sources et destinations. Executive report rassemble les informations courantes sur le trafic et les menaces. User threat quotient classe les utilisateurs selon leur score de menace.
• Network & threats : Intrusion attacks montre les tentatives d’attaque. Active threat response présente les événements de menace et les hôtes compromis à partir des flux MDR et Sophos X-Ops. Wireless concerne l’utilisation des points d’accès et les SSID configurés, Security Heartbeat l’état de santé communiqué par les endpoints, et Zero-day protection l’activité de protection renforcée contre les attaques avancées et ciblées.
• Email : Email usage répond aux questions sur le trafic de messagerie ; Email protection concerne le trafic infecté par des virus ou du spam. La livraison des messages et les événements de protection répondent à des questions différentes.
• VPN : VPN concerne le trafic d’accès distant, SSL VPN le trafic des clients SSL VPN et Clientless access les accès par navigateur. La description de VPN cite aussi IPsec, L2TP et PPTP. Cette classification historique ne garantit pas que chaque méthode soit disponible ou sûre à configurer dans le build installé ; aucun accès obsolète n’est activé pour obtenir un rapport.
• Compliance : Les vues proposées s’appellent HIPAA, GLBA, SOX, FISMA, PCI, NERC CIP v3 et CIPA ; Events présente les événements réseau et leur gravité. Ces rapports facilitent l’analyse, mais ne prouvent pas à eux seuls la conformité complète ni l’actualité d’une exigence pour l’organisation.
• Applications & web : User app risks & usage, Cloud application usage et Web risks & usage servent à analyser les usages et les risques. L’utilisation du cloud peut être examinée par classification, catégorie, utilisation, contenu, zones sources et pays de destination. Blocked user apps et Blocked web attempts montrent les tentatives bloquées ; Web policy overrides, les exceptions autorisées aux politiques. Synchronized applications concerne les applications détectées sur les endpoints via Security Heartbeat, Search engine les habitudes de recherche, et Web content les correspondances des filtres de contenu. Web server usage, Web server protection, User data transfer, FTP usage et FTP protection couvrent le trafic des serveurs, les attaques contre les serveurs Web et leurs sources, le trafic utilisateur et les activités FTP normales ou malveillantes.

Application risk meter calcule un score moyen à partir du niveau de risque et des hits de chaque application. Le rouge indique davantage de trafic d’applications à haut risque, le vert davantage de trafic à faible risque. Cette moyenne est un indicateur, pas la preuve d’une compromission précise ; examiner les applications individuelles, leurs niveaux de risque et leurs hits pour l’évaluer. Web content présente une limite importante liée à la confidentialité : les pages classées highly objectionable criminal activity sont toujours bloquées et leur nom de domaine est masqué dans les logs et rapports. Un domaine absent n’est donc pas automatiquement une erreur d’export et ne justifie pas de désactiver la protection pour l’analyser.

Dans Web policy overrides, examiner les utilisateurs autorisés à déroger aux politiques ainsi que les sites bloqués et les catégories Web concernés. La description de Web server usage couvre le trafic applicatif, Web, Internet et FTP ; cette sélection ne se limite donc pas aux attaques contre les serveurs Web. Celles-ci relèvent de Web server protection.

Distinguer Custom report, Custom view et bookmark

Un Custom report sous Reports > Custom limite un seul domaine de données à l’aide de critères détaillés. Des rapports Web, de messagerie, FTP, utilisateur et serveur Web sont disponibles. La limite des rapports Web est importante : la recherche personnalisée n’affiche que les domaines, URL, catégories et adresses IP autorisés. Les accès Web bloqués se vérifient plutôt sous Reports > Applications & web > Blocked web attempts.

Une Custom view combine plusieurs groupes de rapports dans une même vue, par exemple l’activité Zero-day protection et les utilisateurs Web. Elle se crée sous Reports > Show report settings > Custom view > Add avec un nom et les groupes nécessaires, puis apparaît sous Reports > Custom. La nouvelle vue doit être générée et contrôlée manuellement avant d’être planifiée ou partagée.

Pour choisir les critères : un rapport Web recherche la navigation ou les virus, notamment par utilisateur et domaine ; un rapport de messagerie recherche l’utilisation, le spam et les virus par protocole ou utilisateur. Un rapport FTP peut rechercher par type de transfert, utilisateur, fichier ou IP source. Un rapport utilisateur associe applications à haut risque, domaines improductifs et virus détectés à un nom d’utilisateur ou hôte source. Un rapport de serveur Web examine l’heure, l’utilisateur, l’URI et l’activité de protection. Ces critères sont choisis selon la question ; ils ne garantissent pas la présence de données sans la journalisation correspondante.

Enregistrer une nouvelle Custom view avec Save avant de la générer manuellement.

Un bookmark, en revanche, mémorise une sélection récurrente déjà filtrée. Un calendrier peut sélectionner un groupe de rapports par défaut ou personnalisé, ou un bookmark. Pour l’administrateur, le meilleur choix n’est pas le rapport techniquement le plus volumineux, mais la plus petite sélection qui répond à la question opérationnelle concrète.

Enregistrer une sélection récurrente comme bookmark

Un bookmark est utile lorsqu’une sélection filtrée réutilisable doit être planifiée à la place d’un groupe de rapports complet.

1. Ouvrir le rapport entièrement préparé.
2. Sélectionner Bookmark.
3. Saisir un nom explicite tel que Weekly-IPS-Review.
4. Sélectionner un groupe de bookmarks approprié et enregistrer avec Save.

S’il n’existe aucun groupe adapté, en créer un sous Reports > Show report settings > Bookmark management > Add bookmark group. Un nom tel que Weekly-IPS-Review décrit mieux l’objectif et le rythme que Report1.

Après l’enregistrement, rouvrir le bookmark et générer de nouveau le rapport. Cela permet de vérifier que la sélection prévue est réellement réutilisée. La période exacte couverte par le futur PDF ne doit pas être déduite du seul nom, mais contrôlée dans le PDF généré.

Si aucun groupe de bookmarks personnalisé n’existe encore, le bookmark peut être affecté au groupe par défaut. Pour un nouveau groupe, saisir un nom et enregistrer avec Save ; il organise des bookmarks liés, par exemple sur les applications et les menaces. Pour en rouvrir un, sélectionner le groupe sous Show, puis le bookmark. Un groupe n’apparaît dans cette sélection que s’il contient au moins un bookmark. S’il manque, vérifier d’abord son contenu plutôt que de recréer plusieurs fois la planification.

Télécharger un export de comparaison

Pour une comparaison indépendante du transport de messagerie, télécharger les rapports dans WebAdmin, pas via la CLI :

1. Ouvrir Reports > Applications & web.
2. Choisir les critères sous Show, puis la plage de dates.
3. Générer et vérifier les données avec Generate.
4. Choisir l’un des formats proposés et ouvrir le fichier téléchargé.

Sous Reports > Show report settings > Data management, le champ de conservation s’appelle Log retention report period, bien qu’il ne concerne que les rapports. Export customization contrôle en revanche les rapports sélectionnés et le nombre d’enregistrements par rapport dans l’export. Choisir le périmètre adapté à la revue avant le téléchargement et le vérifier dans le fichier. La personnalisation de l’export ne modifie ni la conservation ni, de manière documentée, la limite de 50 enregistrements des rapports e-mail planifiés. La gestion complète du stockage et des exports est décrite dans l’article déjà lié.

Créer la planification

1. Ouvrir Reports > Show report settings > Report scheduling.
2. Sélectionner Add.
3. Choisir Report comme type.
4. Sous To email address, saisir les destinataires. Plusieurs adresses sont séparées par des virgules.
5. Sous Report type, sélectionner un groupe de rapports ou le bookmark préparé.
6. Si l’option est disponible, choisir un tri par Hits ou Bytes adapté à l’objectif.
7. Sous Email frequency, sélectionner Daily ou Weekly.
8. Enregistrer avec Save.

Le champ de tri s’appelle Sorting criteria ; Hits privilégie les correspondances fréquentes et Bytes le volume de données. Cette option ne concerne que les rapports qui proposent ce tri.

L’exemple utilise les valeurs suivantes :

• Destinataire : firewall-reports@example.net
• Report type : bookmark Weekly-IPS-Review
• Tri : Hits
• Fréquence : Weekly

Ces valeurs ne constituent pas une norme générale. Un tri par Bytes peut être plus pertinent pour un rapport de bande passante, un rapport d’exploitation quotidien nécessite Daily, et un autre site peut exiger son propre destinataire ou bookmark.

Les rapports On-box planifiés sont envoyés au format PDF et contiennent au maximum 50 enregistrements. Cette limite s’applique au rapport envoyé par e-mail ; il ne doit pas être considéré comme une archive complète ni comme un export de toutes les données locales. Pour plusieurs firewalls, des données HA consolidées ou des analyses centralisées plus longues, Sophos Central Firewall Reporting dans Sophos Fusion constitue le niveau le plus adapté.

Depuis SFOS 21.5 MR1, un rapport PDF planifié utilise la langue WebAdmin de l’administrateur qui a créé la planification. Si le destinataire doit recevoir le rapport en allemand, la planification est créée depuis une session WebAdmin en allemand et le résultat est contrôlé avec Generate now.

En plus des rapports standard, la planification propose également Security audit report et, si l’intégration est configurée, ConnectWise. Le Security Audit Report est notamment prévu pour une analyse passive en Discover Mode avec TAP et SPAN. Ces types répondent à d’autres objectifs et ne doivent pas être sélectionnés simplement parce qu’un rapport standard est vide.

Configurer précisément les planifications Security audit et ConnectWise

Un Security audit report est un rapport prédéfini sur les activités liées à la sécurité. Sa planification comprend les champs suivants : Organization name pour le nom affiché dans le rapport, To email address pour les destinataires séparés par des virgules, Report type pour les données du groupe de rapports ou du signet et Email frequency pour un envoi Daily ou Weekly.

Un ConnectWise schedule n’est disponible qu’après l’intégration de ConnectWise à Sophos Firewall. ConnectWise doit être activé sous Reports > Show report settings > ConnectWise, avec l’URL du serveur et les identifiants utilisateur de l’intégration de l’organisation. Ne pas divulguer ces identifiants dans les exemples de PDF ou les éléments transmis au support. Configurez ses champs exacts de planification comme suit :

• Report : sélectionnez l’un des rapports ConnectWise préconfigurés : Top sites, Filtered sites, Bandwidth usage ou Top attacks.
• Number of records : définissez le nombre d’enregistrements créés dans le rapport. Choisissez ce nombre selon l’objectif de la revue, sans supposer que la limite générale de 50 enregistrements des rapports par e-mail est la valeur ConnectWise souhaitée.
• Frequency : planifiez le rapport quotidiennement à l’intervalle indiqué.

Après avoir enregistré l’une de ces planifications spécialisées, utilisez Generate now et examinez le rapport reçu. Une intégration active ou une planification visible dans la liste ne prouve pas à elle seule que le rapport prédéfini contient les enregistrements attendus.

Contrôler l’envoi et le PDF

Après l’enregistrement, il ne faut pas attendre la première exécution régulière.

1. Tester le transport avec Send test mail

Dans la liste, sélectionner la planification, exécuter Send test mail, saisir une adresse de test, puis sélectionner Send. Cette adresse est saisie séparément pour le test et peut différer de To email address dans la planification. Pour un premier test probant, utiliser la même boîte fonctionnelle. Vérifier ensuite dans cette boîte, le filtre antispam ou le suivi du serveur de messagerie que le message a été accepté et livré.

Un e-mail de test réussi confirme la connexion au serveur de messagerie configuré et la livraison de base. Il ne confirme pas encore que le rapport sélectionné contient des données ou qu’il peut être généré dans un PDF correct.

2. Tester toute la chaîne avec Generate now

Exécuter ensuite Generate now. Le firewall génère immédiatement le rapport planifié et l’envoie aux destinataires configurés.

Dans le PDF reçu, vérifier :

• le bon firewall ou le bon site ;
• le groupe de rapports ou la sélection de bookmark prévus ;
• une période et des horodatages plausibles ;
• un tri et un volume de données pertinents ;
• la langue attendue ;
• la lisibilité des tableaux et graphiques ;
• si un logo personnalisé a été sélectionné : vérifier visuellement, dans le rapport nouvellement généré et avant de le partager, que le logo attendu est affiché ;
• l’absence de divulgation inutile de données utilisateur, réseau ou sécurité.

⚠️ Lors d’une mise à niveau de SFOS 20.0 ou antérieur vers SFOS 21.0 ou ultérieur, les rapports antérieurs et postérieurs à la mise à niveau sont stockés dans des bases de données distinctes. Si seul le jour de la migration est sélectionné, il faut choisir Data before migration et Data after migration séparément pour analyser la journée entière. Une plage de dates qui inclut le jour de la migration doit en revanche être divisée en plages antérieures et postérieures à ce jour. Un retour à la version antérieure entraîne la perte de tous les rapports générés depuis la mise à niveau, même après une nouvelle mise à niveau. Tenir compte de cette séparation des bases de données lors du contrôle des PDF planifiés : un envoi d’e-mail réussi ne prouve pas à lui seul une couverture continue de la migration.

Vérifier l’attribution des dates après une interruption : Des données peuvent rester non traitées à l’arrêt du firewall. Après le redémarrage, les événements de ces données peuvent être datés du jour précédant le redémarrage plutôt que du jour où ils se sont réellement produits, même si le firewall était éteint ce jour-là. Cela concerne les données non traitées restantes, pas l’ensemble des événements. Après une interruption, générer donc un nouveau PDF avec Generate now et vérifier particulièrement la période et les dates des événements.

Pour préserver la cohérence des données de rapports, il est recommandé de laisser le firewall fonctionner en continu ; un redémarrage ne corrige pas les écarts de datation des événements.

Ce n’est qu’ensuite que l’exécution régulière suivante est observée. L’aide actuelle ne décrit pas assez précisément la relation exacte entre l’heure d’exécution, le fuseau horaire et la période du rapport pour pouvoir la supposer de manière générale. Le rapport généré constitue donc la preuve de fonctionnement.

Exploitation dans un cluster HA

Les données de rapports locaux ne sont pas synchronisées entre les nœuds HA. Chaque nœud ne contient que les rapports du trafic qu’il traite. L’aide relative à Report scheduling du 19 décembre 2025 décrit l’envoi par les deux appliances dès que le rapport d’une appliance contient au moins une ligne de données dans un tableau ; en l’absence de ligne de données, elle ne décrit aucun envoi. En revanche, la présentation générale de la HA du 13 août 2025 décrit un envoi par l’appliance auxiliaire en fonction des données et cite Security Dashboard et Security Audit comme exemples sans envoi. Ces descriptions ne concordent pas entièrement ; l’aide relative à la planification est la documentation la plus récente et la plus spécifique à ce processus, mais elle ne constitue pas une garantie pour toutes les combinaisons de rapports et de builds. Deux e-mails peuvent donc être reçus. Utiliser Generate now pour vérifier le comportement du rapport sélectionné sur le build utilisé, puis comparer l’expéditeur, l’appliance, la période et le contenu avant de supprimer une planification apparemment dupliquée. L’absence d’un second e-mail ne permet pas, à elle seule, de conclure à une erreur ou à un dysfonctionnement de la HA.

Même une appliance autrement inactive peut générer un Executive report contenant l’utilisation du système et des données de rapports. « Aucun trafic utilisateur » ne signifie donc pas « aucune ligne de données » et n’empêche pas nécessairement l’envoi depuis les deux appliances.

Cette livraison n’est pas automatiquement une erreur. Il faut d’abord comparer l’expéditeur, l’identité de l’appliance, la période et le contenu des deux PDFs. Pour une vue consolidée des deux nœuds, Central Reporting est plus approprié que deux rapports locaux par e-mail.

Après un failover HA, un remplacement d’appliance ou une mise à jour du firmware, tester de nouveau Generate now. Cela permet de détecter une planification toujours visible dont les données, la langue ou l’envoi ne correspondent plus aux attentes.

Délimiter les erreurs méthodiquement

Send test mail échoue

Le problème se situe alors dans le chemin de messagerie et pas encore dans le contenu du rapport. Sous Administration > Notification settings, vérifier le DNS, la route, le port, l’authentification, OAuth, TLS, le certificat, l’expéditeur et le destinataire. Le suivi ou la quarantaine du serveur de messagerie indique si le message a été accepté ou refusé.

Ne pas recréer plusieurs fois la planification. Un e-mail de test doit d’abord arriver de manière fiable. Les symptômes et contrôles sûrs sont décrits dans l’article sur les notifications e-mail.

L’e-mail de test arrive, mais Generate now ne livre aucun rapport

Le chemin SMTP est alors confirmé dans son principe. Vérifier ensuite :

1. Le bon groupe de rapports ou bookmark est-il sélectionné dans la planification ?
2. Le même rapport contient-il des données lorsqu’il est généré manuellement ?
3. On-box Reporting est-il activé et pris en charge par le modèle d’appliance ?
4. /var se trouve-t-il sous le seuil d’arrêt des rapports et, après un arrêt faute d’espace, de nouveau sous le seuil d’avertissement ?
5. La journalisation et les fonctions de protection requises pour les données attendues sont-elles activées ?
6. Le message apparaît-il dans le suivi, le spam ou la quarantaine du serveur de messagerie ?

Dans la Device Console, deux commandes en lecture seule indiquent l’état On-box actuel et les seuils de stockage des rapports :

show on-box-reports
show report-disk-usage watermark

Les commandes ne modifient rien. Les diagnostics de stockage supplémentaires et la signification de la sortie sont décrits sous Gérer le stockage et les rapports.

Le PDF est vide, incomplet ou mal affiché

Générer d’abord le même rapport manuellement avec une période et un filtre identiques. Si l’analyse WebAdmin est déjà vide, il manque des données de rapport, de la journalisation ou des événements correspondants. Si seul le PDF contient des données incorrectes ou incomplètes, documenter la version et le build SFOS, le navigateur, la planification, l’heure de Generate now et un exemple de PDF.

SFOS 22.0 MR2 Build 546 corrige notamment un PDF vide du dashboard de trafic quotidien sans On-box Reporting ainsi que des tableaux ou graphiques mal affichés dans les PDFs à la demande générés avec Chrome. Un symptôme similaire sur un autre build n’est pas automatiquement le même problème. Vérifier le build exact et le comparer à un rapport généré manuellement avant toute modification.

Pour une analyse approfondie, corréler l’heure du test avec cschelper.log, reportdb.log, garner.log et, si nécessaire, postgres.log. L’accès est décrit dans Dépannage Sophos Firewall : Services et journaux. Une seule entrée de journal ne justifie pas de redémarrer les services de reporting ni de supprimer les données de rapports.

Impossible de télécharger l’Executive report avec 1 month au format PDF

Pour SFOS 22.0 MR1 Build 490, Sophos a documenté sous NC-182976 un problème strictement délimité : sous Reports > Dashboards > Executive report, le téléchargement du PDF pouvait échouer lorsque la période 1 month était sélectionnée. Vérifier d’abord le build exact du firmware, le type de rapport, la période et le format de sortie. Les autres rapports PDF ou les rapports planifiés par e-mail ne sont pas automatiquement concernés.

Dans la description de l’époque, Sophos mentionnait un téléchargement CSV avec une période d’un jour ; la colonne distincte Workaround de la KIL indiquait toutefois None. Cet export ne constitue donc qu’une vérification alternative limitée. Il ne remplace pas un rapport mensuel complet et ne confirme ni le rapport mensuel ni le processus de génération du PDF. Si d’autres rapports, périodes ou formats échouent également, le problème dépasse NC-182976 ; documenter alors l’heure et le navigateur, puis collecter les logs mentionnés ci-dessus au lieu de redémarrer les services de reporting ou de supprimer des données de rapport.

L’entrée précédemment documentée pour NC-182976 indiquait SFOS 23.0 EAP0 Build 275 dans le champ Fix versions et présentait les correctifs pour SFOS 23 et SFOS 22.0 MR3 comme à venir. Ces champs historiques n’attestent ni du statut actuel des versions ni de celui du problème. Avant toute mise à niveau, consulter la Known Issues List actuelle et les Release Notes de la version cible approuvée, puis vérifier sa prise en charge du modèle concerné. L’absence de l’entrée dans la Known Issues List actuelle ne prouve pas que le problème est corrigé. Si le même symptôme se produit sur MR2 ou un autre build, ne pas l’attribuer automatiquement à NC-182976, mais l’analyser à l’aide des données collectées.

L’e-mail ne contient que 50 entrées

Il s’agit de la limite supérieure documentée pour les rapports e-mail planifiés. Les filtres et l’objectif du rapport doivent être choisis de sorte que les 50 enregistrements les plus importants répondent à la question opérationnelle concrète. Si des données brutes complètes, un historique plus long ou des analyses sur plusieurs firewalls sont nécessaires, un workflow de reporting centralisé ou SIEM est plus adapté.

Le même rapport arrive deux fois

Dans un cluster HA, deux e-mails peuvent être attendus ; les descriptions officielles de l’envoi par l’appliance auxiliaire en fonction des données diffèrent, comme expliqué dans la section consacrée au fonctionnement en HA. Utiliser Generate now pour vérifier le rapport sélectionné sur le build utilisé, puis comparer l’expéditeur, l’appliance, la période et le contenu avant de supprimer une planification apparemment dupliquée. L’absence d’un second e-mail ne prouve pas, à elle seule, un dysfonctionnement de la HA. Sur un firewall autonome, vérifier en revanche si deux planifications utilisent la même sélection de rapport et le même destinataire.