Sophos Firewall Log Viewer n'affiche plus de logs

Si le Log Viewer n’affiche plus de nouveaux événements, il ne faut pas redémarrer immédiatement un service. 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 :

1. Dans Log Viewer, vérifier Pause, le module, la période et les filtres actifs, puis exécuter Reset et Refresh.
2. 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.
3. Générer une connexion courte depuis un client de test connu et noter l’heure.
4. Utiliser Packet capture pour vérifier si le trafic atteint le pare-feu et quelle Rule ID est traitée.
5. Seulement si d’autres événements attendus manquent aussi, enregistrer la version SFOS, le build complet et l’heure du dernier log visible.
6. Utiliser le workaround Garner uniquement sur SFOS 21.5 MR1 Build 261 et uniquement pour le scénario décrit ci-dessous.

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.
• 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 :

1. Sous Rules and policies > Firewall rules, vérifier que la règle attendue a activé Log firewall traffic.
2. Dans Log Viewer, exécuter Reset, sélectionner le module Firewall et une période appropriée, puis filtrer sur 10.20.30.25.
3. 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.
4. Si l’entrée manque, utiliser un filtre précis tel que host 10.20.30.25 sous Diagnostics > Packet capture et répéter le même test.

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. Packet Capture dans le WebAdmin de Sophos Firewall explique son utilisation et les valeurs d’état.

Vérifier NC-175936 sur SFOS 21.5 MR1 Build 261

Sophos documente l’erreur NC-175936 pour SFOS 21.5 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.

La Sophos Known Issues List actuelle ne fournit pas de champ de version corrigée sans ambiguïté pour 21.5 MR2. Le workaround suivant ne doit donc pas être utilisé sur d’autres builds 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 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. 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.

Autres builds et pannes récurrentes

Sophos a corrigé d’autres erreurs liées à la base de données de Log Viewer, mais elles ne sont pas identiques. SFOS 22.0 MR1 Build 490 contient avec NC-152553 un correctif pour un mécanisme de récupération défaillant de active.db ; NC-169237, relatif à la perte d’événements Log Viewer due à une corruption de la base de données, est répertorié pour SFOS 21.5 MR2 Build 323 et SFOS 22.0 GA Build 411. Ces Issue IDs ne prouvent ni un correctif pour NC-175936, ni automatiquement la cause d’une panne actuelle.

Sur un build ancien, planifier d’abord un chemin de mise à jour du firmware SFOS pris en charge. Sur un build actuel ou après un redémarrage Garner infructueux, ne pas essayer d’autres interventions 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 ;
• 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 répétées de réparation ne masquent la cause initiale.