Bien utiliser Log Viewer sur Sophos Firewall

Dans SFOS 22, Log Viewer est souvent le point de départ le plus rapide lors d’un incident : quelle règle de pare-feu a traité le trafic, quelle règle NAT est intervenue, quel utilisateur a été identifié et quel module de sécurité a bloqué ? Pour obtenir la bonne réponse, le module, la période, les filtres et le moment de création du log doivent correspondre.

Log Viewer affiche des événements journalisés. Ce n’est ni Packet Capture ni un historique complet des connexions. L’absence d’une entrée ne prouve donc ni un drop ni que le paquet a atteint le pare-feu.

Pour une analyse fiable, toujours noter la source, la destination, le service, l’heure exacte du test et le sens attendu. Générer ensuite exactement un nouveau flux et le rechercher dans les modules appropriés.

Analyser un test en sept étapes

1. Vérifier Log firewall traffic dans la règle de pare-feu concernée ou Log connections dans la règle SSL/TLS.
2. Sous System services > Log settings, s’assurer que le type de log requis est activé dans Local reporting.
3. Ouvrir Log viewer (SFOS 22) ou Logs and policy test (SFOS 23) en haut à droite de WebAdmin, puis sélectionner le module de logs adapté.
4. Définir le filtre temporel et utiliser Add filter pour limiter d’abord la vue à l’IP source, l’IP de destination et le service.
5. Générer un nouveau flux court et noter son heure exacte.
6. Dans Detailed view, contrôler Rule ID, NAT ID, l’action, les interfaces, l’utilisateur et les champs propres au module.
7. Si l’entrée ne correspond pas au comportement observé, corréler le même test avec Packet Capture avant de modifier une règle.

Cette séquence sépare trois questions souvent confondues : un log a-t-il été généré ? Quelle stratégie a pris la décision ? Les paquets sont-ils réellement entrés et ressortis ?

Les Event Logs enregistrent l’authentification, les événements système et les changements de configuration, ainsi que le trafic, et sont stockés localement par défaut. Les Troubleshooting Logs sont des journaux de services détaillés accessibles via WebAdmin ou la CLI. La procédure des journaux de services explique l’accès et la collecte en mode debug. Debug consomme de l’espace supplémentaire et doit être désactivé après la collecte requise ; ce n’est pas un interrupteur pour retrouver des Event Logs manquants.

Pour l’envoi centralisé, le pare-feu doit être enregistré pour Sophos Central Firewall Management. Activer ensuite les services Central et Send reports and logs to Sophos Central, puis sélectionner les types de logs requis sous System services > Log settings. La documentation SFOS 22 examinée nomme la destination Sophos Fusion, celle de SFOS 23 Sophos Central ; les champs d’interface indiqués font référence. La procédure Central Reporting couvre la configuration et le contrôle de réception.

Lire correctement les logs

Pourquoi les logs n’apparaissent pas toujours immédiatement

Log Viewer actualise automatiquement l’affichage. Une session de pare-feu n’est cependant normalement journalisée que lorsque le pare-feu reçoit un événement Destroy et ferme la connexion. Pour une session longue, l’entrée peut donc apparaître après la première requête.

Si une connexion se termine sans que le pare-feu reçoive un événement Destroy, par exemple lors d’une perte de connectivité internet, le log de session attendu peut manquer entièrement. Les connexions SSL/TLS sont journalisées après la réussite du handshake et à leur fermeture. Pour un test court, une connexion volontairement fermée est donc préférable à une session permanente de navigateur, de streaming ou HTTP/2.

Un rechargement du navigateur ne crée pas nécessairement une nouvelle connexion. Selon l’application, une fenêtre privée, un nouveau processus client ou une requête courte telle que la suivante convient à un test reproductible :

curl -I https://example.com/

La commande s’exécute sur le client de test, pas dans le shell du pare-feu. example.com est un domaine d’exemple réservé et peut être remplacé par un service connu et autorisé.

Sélectionner le bon module

Un flux peut concerner plusieurs modules de logs. Le module Firewall peut montrer qu’une règle LAN-to-WAN autorise la connexion, tandis que Web filter, Application filter, IPS ou SSL/TLS inspection bloque ou traite ensuite différemment le même flux.

Une seule entrée verte dans Firewall ne suffit donc pas pour un problème web ou de sécurité. Corréler les modules pour le même flux de test à l’aide de la période du test et des adresses :

• Firewall: décision de règle, NAT, interfaces, ports et état de base de la connexion.
• Web filter: décisions d’URL, de catégorie et de Web Policy.
• SSL/TLS inspection: décisions de certificat, de handshake et de déchiffrement.
• Application filter: application identifiée et action Application Control.
• IPS: événements de signature ou d’anomalie.
• VPN: établissement et état du composant VPN concerné.
• Authentication: utilisateur identifié et authentification réussie ou échouée.
• System: événements système et déclenchés par un administrateur.
• SD-WAN: utilisation du profil SD-WAN, du SLA et de la route.

Les types de logs affichés localement sont définis sous System services > Log settings, dans Local reporting. Ces Event Logs ne sont pas des On-box Reports. Central reporting et syslog sont des destinations distinctes à activer séparément. Les événements de Web Policy nécessitent aussi Log firewall traffic dans la règle de pare-feu associée. Les logs Wireless ne sont pas disponibles dans Log Viewer ; il faut les envoyer à Sophos Fusion (anciennement Sophos Central) ou à un serveur syslog.

Limite du Web Proxy : La documentation SFOS 22/23 sur le comportement des logs décrit ce chemin proxy pour HTTP/HTTPS sur les ports 80 et 443 : une règle Drop correspondante transmet les paquets entrants au Web Proxy, qui envoie une page de blocage à l’utilisateur ; sans Web Exception correspondante, le log Firewall indique Allowed et le log Web filter Blocked. Les Web Exceptions restent applicables et peuvent autoriser des requêtes malgré Drop. Le chemin documenté pour Reject termine le flux avant le traitement par le proxy. Examiner ensemble la règle de pare-feu, la Web Policy et les Web Exceptions ; il s’agit d’un scénario documenté, pas d’une garantie universelle de page de blocage pour chaque build ou mode d’inspection.

Contradiction documentaire non résolue : L’aide SFOS 22/23 du formulaire de règles décrit l’authentification des utilisateurs web inconnus lorsque Use web authentication for unknown users est activé, autorise les Web Exceptions correspondantes et décrit sinon une page de blocage HTML. Le guide de journalisation du trafic abandonné décrit au contraire un abandon silencieux et associe la page de blocage web à cette option d’authentification. Ne pas en déduire que l’option seule détermine la réponse. Avant de compter sur Drop pour bloquer le web, obtenir une clarification écrite de Sophos pour la version, le build et le chemin de traitement exacts, ou procéder à une vérification isolée et explicitement autorisée. Consigner la règle et les paramètres actuels pour le retour arrière ; vérifier HTTP et HTTPS séparément, les utilisateurs connus/inconnus, l’authentification activée/désactivée et la présence/absence d’exceptions correspondantes. Corréler de nouveaux flux avec Rule ID, logs, Packet Capture et résultats du navigateur. Ni une page de blocage ni un timeout ne prouvent seuls le blocage. En cas d’accès inattendu ou de résultat incertain, annuler les modifications de test et escalader ; ne pas déployer en production.

Sur les ports autres que 80 et 443, une règle Drop correspondante abandonne directement les paquets ; le log Firewall indique dropped. Avec Reject, le log Firewall indique rejected, sur 80/443 comme sur les autres ports. Ces observations nécessitent Log firewall traffic dans la règle correspondante. Une Web Exception peut, par exemple, autoriser les mises à jour Windows de Microsoft malgré une règle Drop ; cela ne justifie pas d’élargir la règle sans analyse.

Règle Allow et heartbeat absent

Un cas différent de Drop se présente lorsque la règle de pare-feu qui correspond réellement a pour Action Allow, que Block clients with no Heartbeat est activé et que le terminal n’envoie aucun heartbeat. Log firewall traffic doit être activé dans cette règle pour observer les logs décrits ici. Avant la recherche, vérifier aussi les types de logs requis sous System services > Log settings > Local reporting ; activer uniquement une destination externe ne suffit pas pour l’affichage local.

• Ports autres que 80 et 443 : Le pare-feu abandonne les paquets de ce terminal. Le log Firewall indique dropped.
• Ports 80 et 443 dans le chemin Web Proxy documenté : Le pare-feu accepte les paquets entrants et les transmet au Web Proxy. Le terminal n’envoyant aucun heartbeat, le système heartbeat décide de bloquer ; le proxy présente une page de blocage à l’utilisateur. Le log Firewall indique allowed, un autre log Firewall indique Heartbeat blocked et le log Web filter indique blocked. Ici, Heartbeat blocked appartient donc également au module Firewall, et non à un module de logs heartbeat distinct.

Allowed seul ne prouve pas que l’accès a réussi. Avant de modifier une règle, corréler les entrées du même flux de test : examiner ensemble la période du test, la source, la destination, les ports et la règle correspondante. Rechercher l’entrée distincte Heartbeat blocked et l’entrée Web filter indiquant blocked. Cela ne nécessite ni ordre fixe des événements, ni horodatages identiques, ni nombre universel de lignes ; si des entrées attendues manquent, vérifier d’abord la journalisation, les destinations locales et les filtres, puis utiliser Packet Capture si nécessaire.

Cette interprétation se limite à cette option précise de règle, à un terminal sans heartbeat et au chemin proxy décrit. Elle ne s’applique pas généralement à toutes les règles Allow, aux terminaux rouges ou autrement non sains, ni aux autres modes d’inspection. Ne pas désactiver l’exigence de heartbeat comme solution générique ; clarifier d’abord la règle correspondante et la cause du heartbeat absent.

Distinguer Standard view et Detailed view

Standard view convient à une lecture rapide. Il est possible d’ajouter ou de retirer des colonnes et de cliquer sur une valeur pour l’utiliser directement comme filtre. Pour une validation technique, Detailed view est plus importante, car elle affiche les noms de champs sous-jacents et des valeurs supplémentaires.

Particularité NAT importante : si une adresse source traduite autre que l’adresse MASQ par défaut est utilisée, Standard view peut tout de même afficher l’adresse MASQ comme adresse sortante. La source réellement traduite figure dans Detailed view dans src_trans_ip.

Dans Standard view, survoler l’icône d’un module affiche aussi des détails. La fonction de copie place les informations du log dans le presse-papiers. Le viewer s’ouvre dans une nouvelle fenêtre plein écran ; si elle n’apparaît pas, vérifier d’abord le bloqueur de fenêtres contextuelles du navigateur.

Les champs typiques pour un test de pare-feu sont :

• IP source et de destination ainsi que ports source et de destination
• In interface et Out interface
• Firewall Rule ID et NAT Rule ID
• Action ou état
• Nom d’utilisateur, si une identité a été reconnue
• Source et destination traduites
• Log component et Log subtype

Un nom de champ ou un ID n’explique pas automatiquement la cause. Comparer Rule ID à la base de règles actuelle, NAT ID à la règle NAT correspondante et l’ID d’une stratégie de sécurité à son module.

Si un Packet Capture est actif en même temps sous Diagnostics > Packet capture, Open PCAP sur l’entrée de log correspondante permet d’ouvrir les informations des paquets associés. Cette fonction relie la décision journalisée aux détails des paquets, mais ne remplace pas un filtre de capture précisément délimité : source, destination, port et heure du test doivent toujours correspondre au flux examiné.

Isoler le bon flux

Filtrer jusqu’à ne conserver que le bon flux

Log Viewer propose quatre niveaux de filtrage :

1. Module: limite la vue à Firewall, Web, IPS, VPN ou un autre domaine.
2. Time / Timer filter: limite les événements à la période du test ; cliquer sur Timer filter et sélectionner une option temporelle.
3. Add filter: associe un champ précis, une condition et une valeur.
4. Free text search: recherche par exemple des ports, adresses IP, utilisateurs ou noms de règles et fonctionne également avec les informations anonymisées.

Pour un test de connexion normal, commencer par l’IP source, l’IP de destination et le port de destination. Affiner ensuite avec Rule ID, l’utilisateur ou l’action. Reset supprime tous les filtres. C’est important, car un ancien filtre de temps ou de champ peut facilement donner l’impression que le viewer ne reçoit plus d’événements.

Le nombre d’entrées disponibles dépend de la taille du disque et de la rétention locale. Log Viewer ne remplace donc pas un stockage à long terme protégé contre la manipulation. Pour cela, utiliser Central Firewall Reporting ou Envoyer les syslogs à un SIEM.

Le quota local des Event Logs dépend du modèle d’appliance : pour les modèles haut de gamme, Sophos indique jusqu’à 15 % de toute la partition /var ou 50 % de son espace libre, selon la valeur la plus basse. Ce n’est ni une durée de rétention garantie ni un quota pour tous les modèles. L’analyse du stockage distingue Event Logs, rapports et Troubleshooting Logs ; ne pas supprimer de fichiers sans diagnostic.

Bien utiliser Pause, Refresh et l’export CSV

Pause arrête l’actualisation automatique de la vue. C’est utile pour lire ou copier une ligne sans qu’elle se déplace. Cela n’arrête pas la journalisation sur le pare-feu. Refresh recharge manuellement la vue et l’export télécharge les logs actuellement disponibles au format CSV.

Avant un export, documenter le module, la période et les filtres. Le CSV peut contenir des adresses IP internes, des noms d’utilisateur, des URL et des relations de communication ; il doit donc rester dans un processus de support ou d’analyse protégé.

Lorsque Data anonymization est active, les valeurs identifiantes telles que nom d’utilisateur, IP, MAC et adresse e-mail sont protégées. Sophos recommande au moins deux personnes habilitées : si l’administrateur connecté fait partie des Authorizers, au moins une autre personne doit approuver la désanonymisation. Une capture ou un export ne doit malgré tout contenir que les lignes nécessaires au cas.

Pour afficher les identités avec la fonction de désanonymisation, il faut disposer de l’autorisation et fournir ses identifiants d’authentification. Copier une ligne ne remplace pas cette autorisation.

Comprendre Log suppression et Log occurrence

Sous System services > Log settings, le pare-feu peut supprimer les événements Firewall consécutifs et identiques. Cela économise du stockage et du traitement. La suppression affecte les logs locaux, Sophos Fusion et les destinations syslog configurées.

Dans Log Viewer, Log occurrence indique combien de fois un événement regroupé s’est produit. Une seule ligne peut donc représenter de nombreuses répétitions. Elle ne doit pas être comptée automatiquement comme un seul paquet ou une seule connexion.

Avant de modifier Log suppression, vérifier que le volume de logs actuel est réellement la cause du problème. Pour un diagnostic court, il suffit généralement de lire consciemment Log occurrence. Une modification globale affecte aussi les destinations externes et ne doit pas être effectuée uniquement pour obtenir une capture.

Interpréter les constats en toute sécurité

Interpréter correctement Invalid traffic

Invalid traffic signifie que conntrack n’a pas pu associer un paquet à une connexion actuelle. Cela peut se produire avec un chemin asymétrique, une session expirée, des flags TCP inattendus ou des paquets RST et FIN supplémentaires. Ce n’est pas automatiquement une attaque ni un défaut du pare-feu.

Si un problème de connexion survient en même temps, capturer les deux sens avec Packet Capture. Source, destination, flags TCP, interfaces et horodatages doivent appartenir au même flux. Augmenter Tcp Connection Establishment Idle Timeout peut réduire le nombre de ces logs, mais ne corrige pas la cause du chemin ou de la session. Ne pas modifier cette valeur sans preuve.

La journalisation Invalid traffic est activée par défaut. Conntrack suit les sessions TCP et certaines sessions UDP et ICMP ; les paquets initiaux, tels qu’un TCP SYN ou une requête ICMP Echo, établissent l’association à la connexion. Les flags TCP s’interprètent ainsi :

• SYN : demande la synchronisation.
• SYN-ACK : l’acquitte et convient des paramètres de connexion.
• ACK : confirme l’accord ; le transfert de données peut commencer.
• PSH : demande la remise immédiate des données.
• FIN : demande une fermeture ordonnée ; les deux extrémités confirment la fin.
• RST : termine la connexion sans attendre de réponse, par exemple après un paquet inattendu.

Des paquets RST et FIN supplémentaires peuvent être abandonnés et journalisés comme Invalid traffic. Corréler une entrée isolée avec le problème de connexion réel plutôt que de la considérer comme une attaque distincte.

La commande en lecture seule show advanced-firewall dans la Device Console affiche la valeur globale actuelle ; Sophos documente 10800 secondes, soit trois heures, comme valeur par défaut. Une modification affecte toutes les sessions TCP correspondantes du pare-feu. Il faut d’abord corréler sans ambiguïté l’application concernée, sa durée d’inactivité réelle et l’événement Invalid traffic. Un timeout plus élevé est uniquement un ajustement d’exploitation justifié, pas une correction du routage asymétrique ou des pertes de paquets.

La procédure complète d’analyse des drops avec Reason, Rule ID et l’ID spéciale Firewall 0 est décrite dans Analyser les paquets rejetés sur Sophos Firewall.

La source nomme le champ Tcp Connection Establishment Idle Timeout, mais décrit l’expiration des entrées conntrack après inactivité et utilise le paramètre tcp-est-idle-timeout. Cette appellation est ambiguë ; elle ne prouve pas l’existence d’un timeout de handshake distinct. Vérifier la sortie réelle et l’aide CLI du build utilisé.

La référence CLI SFOS 22/23 associe explicitement tcp-est-idle-timeout aux connexions TCP déjà établies et autorise de 2700 à 432000 secondes. Le nom différent du champ n’est donc pas utilisé comme recommandation pour modifier un timeout d’établissement de connexion.

Uniquement si un cas confirmé de timeout d’inactivité justifie un ajustement global, sélectionner 4. Device Console dans la CLI, relever la valeur actuelle avec show advanced-firewall et prévoir une fenêtre de maintenance. L’exemple documenté porte la valeur à six heures ; ce n’est pas une recommandation générale :

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Vérifier la nouvelle valeur et retester la même application sur la période d’inactivité concernée. Moins d’entrées Invalid traffic ne prouve pas, à lui seul, une réparation. Pour revenir en arrière, utiliser la même commande de réglage avec le nombre de secondes précédemment relevé et contrôler avec show advanced-firewall ; 10800 ne convient que si c’était la valeur initiale. Si la sortie CLI est ambiguë ou si le problème persiste, cesser les ajustements et examiner le chemin des paquets ou solliciter le support. Cette procédure a été vérifiée sur la documentation, pas testée sur un pare-feu.

Modifier les règles depuis Log Viewer uniquement de manière contrôlée

Selon l’événement, Log Viewer peut ouvrir directement les Web Policies ou les règles NAT, de pare-feu ou SSL/TLS. Cliquer sur une Web Policy, une règle NAT ou une règle de pare-feu propose un lien vers son édition dans WebAdmin. C’est pratique, mais cela ne raccourcit pas le contrôle technique. Avant toute modification, vérifier Rule ID, le nom, la position, les zones, les objets, le service, le lien utilisateur et les sessions existantes ; relever aussi les valeurs actuelles des champs à modifier afin de pouvoir les restaurer.

Pour une exception SSL/TLS, sélectionner SSL/TLS inspection, faire défiler jusqu’à Manage, choisir Exclude, vérifier l’option du dialogue, puis seulement confirmer avec Exclude. Domain et Subdomain sont ajoutés au groupe URL Local TLS exclusion list, affiché sous Categories and websites dans les règles SSL/TLS. Web category est ajouté à Exclusions by website or category, visible dans la liste des règles SSL/TLS. Pour Other properties, sélectionner la règle SSL/TLS et des objets adaptés, comme un utilisateur ou une adresse IP. Vérifier l’objet cible et la portée avant confirmation ; une exclusion de domaine n’équivaut pas à une exception destinée à un seul utilisateur. Log Viewer ne propose pas Exclude pour 19004 (trafic autorisé) ni 19005 (bloqué par une Web Policy).

Un clic sur une IPS Signature ID peut proposer Disable signature for this IPS policy. Cette action modifie l’IPS Policy active, et pas seulement l’affichage. Il faut d’abord documenter la règle, la stratégie, la signature, l’effet sur la protection et la portée de l’exception, puis retester exactement le flux confirmé.

Une règle Allow large, une exception web globale ou la désactivation de TLS inspection peut masquer le symptôme tout en créant une nouvelle faille de sécurité. Limiter les changements au flux confirmé, les tester dans une fenêtre de maintenance et valider ensuite un nouveau flux dans Log Viewer et, si nécessaire, Packet Capture. Si le test échoue ou si l’exception est trop large, rétablir l’état précédemment relevé dans l’objet de règle ou de stratégie lié, puis recommencer avec un nouveau flux.

Quand les logs manquent ou se trouvent sur l’autre nœud HA

Quand les logs attendus manquent

Contrôler un résultat vide dans cet ordre :

1. Vérifier Pause, le module, la période et les filtres, puis utiliser Reset et Refresh.
2. Vérifier la journalisation de la règle et Local reporting pour le type de log requis.
3. Créer une nouvelle connexion volontairement fermée avec un horodatage connu.
4. Confirmer avec Packet Capture que le trafic atteint le pare-feu et quelle Rule ID le traite.
5. Contrôler les autres modules pour les événements du même flux.
6. Examiner le viewer ou le chemin du service de journalisation uniquement si l’ensemble de la vue locale ne reçoit plus de nouveaux événements.

La procédure propre à certaines versions pour un viewer complètement bloqué est décrite dans Log Viewer n’affiche plus de nouveaux logs. Le redémarrage d’un service ou une intervention dans la base de logs locale ne fait pas partie de l’utilisation normale.

Log Viewer dans les environnements HA

Chaque nœud HA stocke uniquement les logs et rapports du trafic qu’il a traité. En particulier en active-active ou après un failover, l’entrée attendue peut donc se trouver sur l’autre nœud. Documenter ensemble l’heure, le rôle du nœud et Connection served by.

Central Firewall Reporting ou syslog peuvent fournir une vue centrale. Ils ne remplacent pas le contrôle par nœud lors de l’analyse d’un changement de rôle HA précis, d’une panne de service locale ou du chemin des données au moment de l’événement.