Bien utiliser Log Viewer sur Sophos Firewall
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
- Vérifier Log firewall traffic dans la règle de pare-feu concernée ou Log connections dans la règle SSL/TLS.
- Sous System services > Log settings, s’assurer que le type de log requis est activé dans Local reporting.
- Ouvrir Log viewer en haut à droite de WebAdmin et sélectionner le module adapté.
- 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.
- Générer un nouveau flux court et noter son heure exacte.
- Dans Detailed view, contrôler Rule ID, NAT ID, l’action, les interfaces, l’utilisateur et les champs propres au module.
- 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 ?
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 horodatage et les mêmes 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.
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.
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.
Filtrer jusqu’à ne conserver que le bon flux
Log Viewer propose quatre niveaux de filtrage :
- Module: limite la vue à Firewall, Web, IPS, VPN ou un autre domaine.
- Time: limite les événements à la période du test.
- Add filter: associe un champ précis, une condition et une valeur.
- 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.
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. La désanonymisation exige une personne autorisée et ses identifiants. Une capture ou un export ne doit malgré tout contenir que les lignes nécessaires au cas.
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 Central 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 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 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.
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, les règles de pare-feu ou les règles SSL/TLS. 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.
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.
Quand les logs attendus manquent
Contrôler un résultat vide dans cet ordre :
- Vérifier Pause, le module, la période et les filtres, puis utiliser Reset et Refresh.
- Vérifier la journalisation de la règle et Local reporting pour le type de log requis.
- Créer une nouvelle connexion volontairement fermée avec un horodatage connu.
- Confirmer avec Packet Capture que le trafic atteint le pare-feu et quelle Rule ID le traite.
- Contrôler les autres modules pour les événements du même flux.
- 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.
Pourquoi une connexion autorisée apparaît-elle plus tard dans Log Viewer ?
Destroy, à la fin de la connexion. Une session longue ou réutilisée peut donc apparaître tardivement. Pour le test, créer une nouvelle connexion courte et volontairement fermée.