Sophos Firewall Log Viewer n'affiche plus de logs

Si le Log Viewer n’affiche plus de nouveaux événements sous SFOS 22, il ne faut pas redémarrer un service sur la base d’un simple soupçon. Il faut d’abord déterminer s’il manque seulement une entrée attendue ou si l’affichage local des logs est entièrement bloqué. Pour l’utilisation normale, les filtres et l’interprétation des champs, commencer par Utiliser correctement le Log Viewer de Sophos Firewall. La procédure rapide et sûre pour un affichage bloqué est la suivante :

Dans Log Viewer, vérifier Pause, le module, la période et les filtres actifs, puis exécuter Reset et Refresh.
Dans la règle de pare-feu concernée, contrôler Log firewall traffic et, sous System services > Log settings, vérifier le type de log Firewall pour Local reporting.
Générer une connexion courte depuis un client de test connu et noter l’heure.
Sous Diagnostics > Packet capture > Configure, définir un filtre BPF précis, activer la capture et vérifier si le trafic atteint le pare-feu et quelle Rule ID est traitée.
Désactiver la capture après le test. Seulement si d’autres événements attendus manquent aussi, enregistrer la version SFOS, le build complet et l’heure du dernier log visible.
Sous SFOS 22, ne pas utiliser de workaround Garner ou de base de données provenant d’une ancienne version. Vérifier la version de maintenance actuelle et transmettre les données de diagnostic au support Sophos si tous les logs locaux sont bloqués.
Le workaround Garner conservé ci-dessous concerne exclusivement SFOS 21.5.1 MR1 Build 261 et le scénario exact documenté.

Le diagnostic reste ainsi traçable : un filtre incorrect ou une règle qui ne journalise pas n’est pas confondu avec une erreur de base de données de logging.

Pourquoi une entrée de log peut manquer

Log Viewer s’actualise normalement automatiquement. Il n’affiche toutefois que les événements que le module sélectionné stocke localement et que la vue actuelle ne masque pas.

Les causes fréquentes qui ne correspondent pas à une panne technique de Log Viewer sont :

Pause est active : Les nouveaux événements n’apparaissent qu’après la reprise ou un rafraîchissement manuel.
Le module, la période ou les filtres ne correspondent pas : Reset supprime tous les filtres ; il faut ensuite sélectionner à nouveau le module adapté au cas.
Rule Logging est désactivé : Les sessions du pare-feu n’apparaissent que si Log firewall traffic est activé dans la règle qui correspond réellement.
Local reporting est désactivé : Sous System services > Log settings, le type de log requis doit être sélectionné dans la colonne Local reporting.
La connexion est encore ouverte : Les sessions du pare-feu sont normalement journalisées lors de l’événement Destroy, à la fermeture de la connexion. Une entrée peut donc apparaître après l’établissement initial de la connexion.
La session se termine sans événement Destroy : En cas de perte de la connexion Internet, par exemple, la session peut se fermer sans aucune entrée de log. L’entrée n’est alors pas simplement retardée : elle n’est jamais créée.
Le trafic n’atteint pas le pare-feu : L’absence d’une entrée ne prouve pas que le pare-feu a rejeté le paquet. Le client, un routeur en amont, DNS ou un autre chemin peut déjà empêcher la connexion.
Firewall Log suppression regroupe les répétitions : Les événements de pare-feu suivants qui sont supprimés peuvent être regroupés sous Log occurrence au lieu d’apparaître sur plusieurs lignes distinctes.

Si Log Viewer continue d’afficher de nouveaux événements système ou pare-feu issus d’autres tests, l’affichage fonctionne globalement. La cause se situe alors plutôt au niveau du logging de la règle, du choix du module, des filtres, de la fin de session ou du chemin réel des paquets. Pour faire cette distinction, il convient de tester la règle avec Log Viewer, Policy Tester et Packet Capture.

Générer un flux de test contrôlé

Un test reproductible est plus fiable que l’attente d’un trafic utilisateur aléatoire. Dans l’exemple suivant, le client de test utilise l’adresse IP adaptable 10.20.30.25. Sur le client, et non dans le shell du pare-feu, établir une connexion HTTPS courte :

curl -I https://example.com/

example.com est un domaine réservé aux exemples. Un service HTTPS interne connu et autorisé peut également être utilisé pour le test. L’essentiel est que le processus ferme ensuite la connexion et que l’heure, l’adresse IP du client et la destination soient connues.

Effectuer ensuite les contrôles dans cet ordre :

Sous Rules and policies > Firewall rules, vérifier que la règle attendue a activé Log firewall traffic.
Dans Log Viewer, exécuter Reset, sélectionner le module Firewall et une période appropriée, puis filtrer sur 10.20.30.25.
Attendre quelques secondes et rafraîchir manuellement une fois, car l’événement du pare-feu peut n’apparaître qu’à la fin de la session.
Si l’entrée manque, ouvrir Diagnostics > Packet capture, cliquer sur Configure, saisir le filtre précis host 10.20.30.25 dans Enter BPF string, puis enregistrer. Remplacer l’adresse IP par celle du client de test réel.
Activer Packet capture, répéter le test une fois, puis désactiver la capture. La capture reste ainsi limitée au client connu et à une courte période.

L’observation détermine l’étape suivante :

Packet Capture ne voit aucun trafic de test : Rechercher la cause avant le pare-feu ou sur le client.
Packet Capture affiche une autre Rule ID : Vérifier la règle qui correspond réellement et son logging.
D’autres nouveaux événements apparaissent dans Log Viewer : Log Viewer n’est pas entièrement bloqué ; poursuivre l’analyse des filtres, du type de log et de la règle concernée.
Packet Capture confirme le flux, Rule Logging et Local reporting sont corrects, mais aucun nouvel événement n’apparaît : Vérifier le build et le traitement local des logs.

Packet Capture montre le flux des paquets, mais ne répare pas l’affichage des logs. Si le tampon est plein et que Wrap capture buffer once full n’est pas sélectionné, SFOS arrête automatiquement la capture ; Clear libère le tampon pour un nouveau test. Packet Capture dans le WebAdmin de Sophos Firewall explique son utilisation et les valeurs d’état.

Classer la panne sous SFOS 22

La Sophos Known Issues List limite NC-175936 à SFOS 21.5.1 MR1 Build 261 et indique explicitement que le problème est corrigé dans la version 22. Le redémarrage Garner associé n’est donc pas une procédure de réparation pour SFOS 22.

Les notes de version de SFOS 22 mentionnent d’autres modifications du Logging Framework. SFOS 22.0 GA Build 411 a corrigé NC-169237, où une corruption de base de données entraînait la perte d’événements dans Log Viewer. SFOS 22.0 MR1 Build 490 a corrigé NC-152553, un échec du mécanisme de récupération de active.db. La version la plus récente qui y figure, SFOS 22.0 MR2 Build 546, améliore les performances de Log Viewer avec NC-181520.

Ces entrées confirment des erreurs corrigées, mais n’identifient pas la cause d’une panne actuelle. Sous SFOS 22, relever précisément la version et le build, vérifier un chemin de mise à niveau pris en charge vers la version de maintenance actuelle et ne pas modifier les fichiers de base de données ni redémarrer un service de logging depuis le shell si les événements restent absents.

Vérifier `NC-175936` sur SFOS 21.5.1 MR1 Build 261

Sophos documente l’erreur NC-175936 pour SFOS 21.5.1 MR1 Build 261 : le fichier /tmp/eventlogs/active.db peut manquer, ce qui empêche Log Viewer d’afficher de nouvelles données. Selon Sophos, le pare-feu continue de traiter le trafic et les fonctions de sécurité restent actives. Cette déclaration décrit le problème connu et ne constitue pas un contrôle de santé général d’un pare-feu sans logs.

Sophos indique également explicitement que ce problème est corrigé dans la version 22. Le workaround historique suivant ne doit donc être utilisé ni sous SFOS 22, ni sur un autre build uniquement en raison d’un symptôme similaire.

Contrôles en lecture seule dans l’Advanced Shell

Commencer par noter le build complet, l’heure, le dernier événement visible et, pour HA, le nœud concerné. Si WebAdmin fonctionne encore, sauvegarder garner.log et, si possible, un Consolidated Troubleshooting Report avant la modification.

Se connecter ensuite via l’accès SSH documenté à Sophos Firewall et ouvrir l’Advanced Shell. Les commandes suivantes ne font que lire l’état du stockage, le fichier et le log :

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp indique s’il reste de l’espace libre sur le système de fichiers. ls -l confirme si active.db existe ; s’il manque, le shell peut afficher un message tel que No such file or directory, selon le build. Rechercher dans garner.log les erreurs correspondant à l’heure de test documentée. Associer correctement les Service Logs de Sophos Firewall explique les autres noms de services et fichiers de log.

Si /tmp est plein, si le fichier existe, si le build diffère ou si le symptôme n’est pas sans ambiguïté, ne pas effectuer le redémarrage suivant. Les fichiers sous /tmp/eventlogs ne doivent être ni supprimés, ni copiés, ni créés manuellement.

Redémarrer Garner une seule fois de manière contrôlée

⚠️ Commande modifiant l’état : Ce workaround s’applique uniquement au scénario documenté sur SFOS 21.5.1 MR1 Build 261. Sauvegarder d’abord les logs et l’état du système. Dans un cluster HA, ne pas exécuter la commande sur les deux nœuds sans procédure vérifiée. Ne pas redémarrer Garner plusieurs fois et ne jamais réparer ou supprimer active.db manuellement.

Pour NC-175936, Sophos indique exactement cette commande dans l’Advanced Shell :

service garner:restart -ds nosync

La commande a été reprise de la Sophos Known Issues List actuelle pour cet article, mais n’a pas été testée en laboratoire sur une appliance. Un redémarrage de service ne peut pas être annulé ; si le fichier reste absent ou si les événements n’apparaissent toujours pas, arrêter ici et transmettre l’état enregistré avant la modification au support Sophos. Après ce redémarrage unique, vérifier à nouveau le fichier et les derniers messages Garner avec des commandes en lecture seule :

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Exécuter ensuite Reset et Refresh dans Log Viewer, puis répéter le même flux de test court. La mesure ne réussit que lorsqu’un nouvel événement avec un horodatage correspondant apparaît. La présence de active.db seule ne prouve pas que l’ensemble du chemin de logging fonctionne à nouveau.

Si SFOS 22 n’affiche toujours aucun nouvel événement

Si Packet Capture montre le flux de test contrôlé sous SFOS 22, que Rule Logging et Local reporting sont corrects et que les nouveaux événements restent absents dans tous les modules, planifier d’abord un chemin de mise à jour du firmware SFOS pris en charge vers la version de maintenance actuelle. Si le problème persiste sur le build actuel, ne pas intervenir sur la base de données ou les services.

Pour un dossier de support, recueillir au minimum :

le modèle de l’appliance, la version SFOS et le build complet ;
pour HA, le nœud concerné et son rôle ;
l’horodatage de la dernière entrée visible dans Log Viewer et l’heure du flux de test ;
le module, les filtres, la Rule ID, la Source, la Destination et le Service du test ;
l’état de Log firewall traffic et Local reporting ;
le résultat de Packet Capture ;
pour le scénario exact de 21.5.1 MR1, la sortie de df -kh /tmp et ls -l /tmp/eventlogs/active.db ;
garner.log, si nécessaire fwlog.log et iview.log, ainsi que si possible un CTR avant d’autres modifications ;
l’information indiquant si Garner a été redémarré une fois et ce qui a changé ensuite.

Sophos peut ainsi distinguer les erreurs d’affichage, de base de données, de stockage, de service et de version sans que des tentatives de réparation répétées masquent la cause initiale.