Associer correctement les service logs Sophos Firewall

Avec Sophos Firewall, il existe trois niveaux importants pour le dépannage : les journaux d’événements dans le Log viewer, les outils de diagnostic dans WebAdmin et les fichiers de service ou de journal sur le pare-feu. Le Log Viewer est idéal pour des questions rapides comme “la connexion a-t-elle été autorisée ou bloquée ?”. Les fichiers sous /log sont plus importants lorsqu’un service ne démarre pas, qu’un tunnel VPN est instable, que le filtre Web agit de manière inattendue ou que le support a besoin de données détaillées.

Cet article classe les services et fichiers journaux les plus importants selon les problèmes typiques des administrateurs. Il est également utile lorsque, dans le tableau de bord, dans l’Advanced Shell ou dans un cas de support, un nom de service technique apparaît et qu’il n’est pas immédiatement clair quelle fonction du pare-feu se cache derrière. Des noms comme zebra, warren, awed, garner ou strongswan ne sont pas explicites au quotidien.

Choix de l’outil et prérequis

Avant de rechercher dans les fichiers journaux, il faut déterminer quel outil fournit la réponse la plus rapide. De nombreux cas peuvent déjà être circonscrits avec le Log Viewer ou Packet Capture. Le shell ne devient vraiment utile que lorsqu’il faut contrôler un service lui-même ou que le support a besoin de données de journal détaillées.

Quel outil de dépannage est approprié ?

Tous les problèmes de pare-feu ne commencent pas par un shell. Souvent, un autre outil est plus rapide au départ :

• Connexion autorisée ou bloquée ? Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.
• L’ensemble de Log Viewer n’affiche plus de nouveaux événements ? Vérifier les filtres, le logging et le workaround Garner propre au build.
• L’ensemble du pare-feu a-t-il redémarré de manière inattendue ? Commencer par classer le redémarrage comme reboot de l’appliance, failover HA ou panne d’un service, puis sauvegarder sysinit.log, syslog.log et le CTR.
• Les paquets arrivent, mais le chemin ensuite est incertain ? Utiliser Sophos Firewall Packet Capture dans WebAdmin.
• Une capture de paquets doit durer plus longtemps, être enregistrée en PCAP ou analysée dans Wireshark ? Sophos Firewall tcpdump : capturer des paquets via CLI.
• Changement de configuration suspecté comme déclencheur ? Vérifier les journaux de piste d’audit de Sophos Firewall.
• Changement depuis Sophos Fusion (anciennement Sophos Central) en attente ? Vérifier la file d’attente des tâches du pare-feu Sophos Fusion.
• Rapports ou historique nécessaires dans Sophos Fusion ? Activer et gérer le reporting centralisé de Sophos Firewall.
• Logs à envoyer durablement vers SIEM, SOC ou serveur de logs ? Envoyer les journaux Syslog de Sophos Firewall à un SIEM.
• Flux de trafic, pics de bande passante ou modèles de communication au centre de l’analyse ? Configurer la surveillance sFlow sur Sophos Firewall.
• Service qui ne fonctionne pas ou support qui demande des logs ? Cet article.
• Logs locaux à sauvegarder pour Sophos Support ou Avanet ? Sauvegarder les journaux de Sophos Firewall pour le support et l’analyse.
• Cas de support à préparer ? Ouvrir un ticket de support Sophos : préparation et portail.

L’ordre est important. Le Log Viewer montre souvent plus rapidement quelle règle ou quel module a pris une décision. Packet Capture prouve le flux de paquets dans WebAdmin. tcpdump est utile lorsqu’une capture plus longue, un fichier PCAP ou un filtre CLI très précis est nécessaire. Les journaux de service et le débogage aident lorsqu’un service particulier est lui-même le problème ou lorsque des données doivent être collectées pour le support Sophos.

Pour les questions portant uniquement sur la connectivité, Diagnostics > Tools, avec Ping, Traceroute ainsi que les recherches DNS et de routes, complète la recherche dans les logs. Ping vérifie la connectivité, Traceroute le chemin emprunté et une recherche la résolution de noms ou la route. Les commandes de diagnostic de base aident à choisir l’outil ; un test réussi depuis le pare-feu ne remplace pas un test depuis le client concerné.

Démarrage rapide par symptôme

Si le log pertinent n’est pas clair, il est souvent plus utile de commencer par le symptôme que par le nom de service.

• Une connexion précise ne fonctionne pas : vérifier d’abord le Log Viewer avec source, destination, service et heure. Ensuite utiliser Packet Capture, firewall_rule.log et nat_rule.log.
• Un tunnel VPN est indisponible ou instable : vérifier le statut VPN, l’IP du pair, l’heure et le Log Viewer. Ensuite consulter strongswan.log, charon.log, sslvpn.log et les données de diagnostic IPsec.
• WebAdmin, User Portal ou SSH n’est pas joignable : vérifier Device Access, Local Service ACL et la zone concernée. Ensuite utiliser apache.log, tomcat.log, sshd.log et Packet Capture sur le port cible.
• Le filtre Web, TLS Inspection ou IPS bloque de manière inattendue : vérifier le module Log Viewer et la Policy ID. Ensuite comparer ips.log, awarrenhttp.log et Packet Capture.
• Une tâche Sophos Fusion reste bloquée : comparer la Central Task Queue et l’état local. Ensuite vérifier centralmanagement.log, sophos-central.log et fwcm-api-executor.log.
• HA se comporte différemment selon le nœud : déterminer le nœud actif, le nœud auxiliaire et le chemin de trafic concerné. Ensuite se connecter directement au nœud concerné et vérifier les logs HA.
• Les rapports locaux manquent ou le stockage se remplit : vérifier les paramètres de rapport, l’espace disque et Central Reporting. Ensuite utiliser reportdb.log, garner.log et une analyse d’espace disque.

Cette approche évite un piège classique : chercher dans un fichier de service alors qu’il faudrait d’abord prouver la correspondance des règles, Device Access, NAT ou le routage.

Log Viewer ou fichier journal ?

Le Log viewer s’ouvre dans la console WebAdmin en haut à droite. Il se met à jour automatiquement, peut être filtré par module, heure, valeurs de champ et texte libre, et peut exporter les journaux au format CSV.

Pour protéger les noms d’utilisateur ainsi que les adresses IP, MAC et e-mail dans l’affichage quotidien des logs, il est possible d’utiliser Data Anonymization pour les logs et rapports locaux. Son effet dans Log viewer ne prouve pas automatiquement que les fichiers sous /log, CTR, Remote Syslog ou Central anonymisent les mêmes identités ; chaque chemin de sortie est contrôlé séparément.

Les journaux de dépannage se trouvent dans le répertoire /log. Le chemin officiellement documenté passe par la CLI : se connecter, choisir 5 Device Management, puis 3 Advanced Shell. SSH reste généralement plus confortable pour les longues sessions tail, grep ou less. Sa préparation est expliquée dans Connecter Sophos Firewall via SSH.

Avant des sessions shell prolongées, il devrait être clair depuis quel réseau administrateur on se connecte, si l’empreinte SSH a été vérifiée et si l’Advanced Shell est vraiment nécessaire. Pour de nombreuses premières vérifications, le Log Viewer ou Packet Capture dans WebAdmin suffit.

Comme règle générale, cette séquence aide :

1. Un seul flux de trafic est concerné : filtrer le Log Viewer par source, destination, service et heure.
2. Le Log Viewer ne montre aucune décision : démarrer Packet Capture avec un filtre étroit.
3. Packet Capture montre Incoming, mais aucune décision claire : vérifier Rule ID, NAT ID, Firewall ID 0, le chemin de retour et le fichier journal approprié.
4. Un service spécifique semble instable : observer le fichier approprié sous /log avec tail -f.
5. Une erreur est sporadique ou nécessite un support : préparer la fenêtre temporelle, le filtre, l’archive de logs et éventuellement tcpdump.
6. Les logs normaux ne suffisent pas : activer le debug uniquement pour le service concerné et seulement brièvement.

Cela garde l’analyse suffisamment petite. On collecte d’abord le constat visible, puis on passe au flux de paquets et seulement ensuite aux journaux de service ou au débogage. Cela réduit le risque d’activer trop tôt des journaux de débogage étendus ou d’évaluer un mauvais fichier journal.

Lire les fichiers journaux dans l’Advanced Shell

Avant de chercher dans /log, le cas de test doit être documenté aussi précisément que possible : heure locale, IP source concernée, IP de destination, port, utilisateur, module et comportement attendu. Ces informations font la différence entre une analyse de journal utile et une longue recherche à travers d’anciennes entrées.

1. Se connecter à la CLI, choisir 5 Device Management, puis 3 Advanced Shell.
2. Changer de répertoire pour accéder aux journaux.

cd /log

Commandes utiles :

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Les commandes les plus importantes de l’Advanced Shell :

• Lire en direct : tail -f /log/<logfilename>.log, par exemple tail -f /log/ips.log.
• Lire un fichier statique : less /log/<logfilename>.log, par exemple less /log/ips.log.
• Chercher un terme : grep <keyword> /log/<logfilename>.log, par exemple grep error /log/ips.log.
• Lire l’état d’un service : utiliser service -S ou limiter la recherche à un nom, par exemple service -S | grep ips. Cette vérification ne modifie pas le service.

Pour appliquer un filtre ciblé en temps réel, on peut ajouter une date ou une adresse client :

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

La date et 192.0.2.10 sont des exemples : il faut les remplacer par la date visible dans le log ou par l’adresse IP du client concerné. tail -f affiche uniquement les dernières lignes existantes et les nouvelles entrées, et non automatiquement tout l’historique de la journée. Pour les entrées déjà enregistrées, on utilise par exemple grep 2026-10-10 /log/ips.log. Si le filtre ne renvoie rien, vérifier d’abord le format de l’heure, le fuseau horaire, l’adresse IP et le fichier journal avant de soupçonner une absence de journalisation. Dans less /log/ips.log, Maj+G permet d’aller à la fin du fichier, Entrée d’avancer d’une ligne et q de quitter l’affichage ; Ctrl+C arrête une capture en cours avec tail -f. Le pipeline utilisant less produit une sortie texte filtrée, et non une vue interactive dans less. Ces commandes lisent les logs, mais ne modifient ni les règles ni l’état du debug.

Pour le support ou une analyse ultérieure, il ne faut pas seulement copier des lignes de journal individuelles. Il est préférable d’avoir une période de temps claire, le test reproduit, des captures d’écran pertinentes du Log Viewer ou de Packet Capture et, si nécessaire, une archive complète des journaux. Les journaux locaux tournent ; par conséquent, les données importantes doivent être sauvegardées tant que l’événement est encore dans la période concernée. La procédure est décrite dans Sauvegarder les journaux de Sophos Firewall pour une analyse externe.

Télécharger les troubleshooting logs dans WebAdmin

Toutes les collectes ne doivent pas être assemblées manuellement dans l’Advanced Shell. WebAdmin regroupe les fichiers sous Diagnostics > Tools.

En pratique, il existe deux chemins:

• Fichiers de logs individuels: ouvrir Diagnostics > Tools > Troubleshooting logs, sélectionner les fichiers concernés et les télécharger sous forme compressée.
• Consolidated Troubleshooting Report (CTR): utiliser Diagnostics > Tools > Consolidated troubleshooting report lorsque le support a besoin de tous les logs ainsi que de l’état système, des processus et des données de ressources dans un seul paquet.

C’est pratique lorsqu’un paquet de logs ciblé suffit. Le CTR convient mieux lorsque Sophos Support a besoin d’un instantané complet. Indiquer une raison claire, telle que le numéro de ticket, la période ou le symptôme. Le rapport est téléchargé chiffré ; son nom contient aussi le numéro de série du pare-feu et ne doit donc pas figurer dans une pièce jointe publique.

Par défaut, un CTR contient 10 000 lignes par service subsystem log. Dans la Device Console, la valeur ne peut être réglée qu’entre 250 et 10 000 ; elle peut donc seulement être réduite par rapport à la valeur par défaut. Les default subsystem logs contiennent toutes leurs lignes. Cette limite ne concerne que le CTR : les fichiers complets restent disponibles via Troubleshooting logs ou l’Advanced Shell.

Important : un paquet de logs téléchargé ne remplace pas les données de contexte. Le support a toujours besoin de l’heure avec fuseau horaire, des IP concernées, de l’utilisateur, du nom de tunnel, de la Rule ID, de la NAT ID et d’une courte description de ce qui a été reproduit.

Pour les clusters HA, il faut aussi tenir compte d’un point : les logs et rapports ne sont pas simplement synchronisés entre Primary et Auxiliary. Chaque nœud contient les logs du trafic et des services qu’il a lui-même traités. Pour les erreurs propres à un nœud, il faut donc vérifier le nœud concerné.

Comprendre la rotation des logs et les données volatiles

Les Troubleshooting Logs sont d’abord créés en mémoire, puis copiés par le pare-feu dans le système de fichiers. Si le pare-feu ne répond plus, les entrées qui n’ont pas encore été copiées peuvent être perdues. Un redémarrage inattendu ou un blocage ne justifie donc pas d’attendre avant de préserver les preuves : il faut d’abord sauvegarder les CTR, logs et données temporelles disponibles.

Chaque sous-système possède ses propres limites de taille et de stockage, selon sa criticité et le modèle d’appliance. Lorsque le fichier actif atteint sa limite, SFOS le compresse au format .gz et poursuit l’écriture sous le nom d’origine. Si les rotations atteignent également la limite du sous-système, le fichier compressé le plus ancien est supprimé en premier. Le nombre de rotations et la profondeur de l’historique ne sont donc pas identiques pour tous les services.

Ne pas renommer ni supprimer manuellement les fichiers journaux ou leurs rotations .gz. Pour l’analyse de l’espace, l’exportation et les commandes de purge documentées, suivre la procédure Gérer de manière contrôlée le stockage et les rapports.

Advanced Shell ou Device Console ?

Avec Sophos Firewall, il existe deux zones de console différentes, souvent confondues :

• Device Console : CLI Sophos pour des commandes spécifiques au pare-feu, par exemple priorité de routage, routes IPsec ou options système.
• Advanced Shell : shell proche de Linux pour le système de fichiers, les journaux et les commandes en lecture seule comme tail, grep, less et service -S.

Toutes les commandes ne fonctionnent pas dans les deux zones. /log, tail -f, grep et service -S relèvent de l’Advanced Shell. Les commandes system diagnostics ... documentées pour la limite CTR, la purge des logs et le debug des sous-systèmes s’exécutent dans la Device Console.

Cette distinction est importante car de nombreuses erreurs ne surviennent que parce qu’une commande correcte est entrée au mauvais endroit.

La journalisation doit être activée

Toutes les informations attendues n’apparaissent pas automatiquement.

• Dans les règles de pare-feu, Log firewall traffic doit être activé.
• Dans les règles d’inspection SSL/TLS, la journalisation doit être activée.
• Sous System services > Log settings, il doit être défini quels types de journaux sont envoyés localement, à Sophos Fusion ou à Syslog.

Pour une conservation à long terme, un serveur Syslog ou le reporting centralisé de Sophos Central est recommandé. Comment connecter des serveurs de journaux externes ou un SIEM est expliqué dans Envoyer les journaux Syslog de Sophos Firewall à un SIEM. Pour Sophos Fusion, Activer le reporting centralisé de Sophos Firewall est la procédure appropriée.

Activer le débogage uniquement de manière ciblée

La journalisation de débogage produit beaucoup plus de données, occupe du stockage et peut enregistrer des informations confidentielles. Ce n’est pas une première étape raisonnable. Définir d’abord le journal normal, la période et le test reproductible ; n’utiliser le debug que pour le sous-système concerné et pendant le temps strictement nécessaire.

Sophos documente deux méthodes différentes. La forme Advanced Shell service <service>:debug -ds nosync bascule l’état et n’accepte pas d’argument on ou off distinct. Pour un sous-système de service pris en charge, privilégier les commandes explicites de Device Console documentées par Sophos : system diagnostics subsystems <subsystem> debug on, reproduire le problème et collecter les données, puis exécuter system diagnostics subsystems <subsystem> debug off. Pour le débogage de Packet Capture, le nom du sous-système est par exemple Pktcapd. Le débogage est désactivé par défaut, mais il faut vérifier avant toute modification qu’aucun autre administrateur ni Sophos Support ne collecte déjà des données. Consigner la modification et vérifier ensuite que le débogage est désactivé.

Traiter le débogage du contrôleur système CSC comme une bascule distincte

SFOS 22 documente une commande Device Console distincte pour le contrôleur système (CSC) :

system diagnostics subsystems CSC debug

Contrairement à la syntaxe du sous-système de service ci-dessus, cette commande n’a pas d’argument on ou off : chaque exécution bascule le débogage CSC. Il faut l’utiliser comme une modification contrôlée, et non comme une requête d’état :

1. Contrôle préalable : Confirmer avec les autres administrateurs et Sophos Support que le débogage CSC n’est pas déjà actif ou intégré à une collecte en cours. Consigner le pare-feu ou le nœud HA, l’heure, le motif et la fenêtre de collecte prévue. Conserver une copie de référence du journal CSC concerné avant la modification. Ne pas exécuter la bascule simplement pour connaître son état.
2. Activer et reproduire : Dans Device Console, exécuter la commande exactement une fois. Reproduire uniquement le problème délimité et noter l’heure du test avec le fuseau horaire.
3. Préserver les preuves : Avant le retour arrière, télécharger le journal de dépannage individuel concerné ou générer le CTR puis télécharger le fichier CTR finalisé. Restreindre l’accès au CTR chiffré et aux archives de journaux, car ils peuvent contenir des données confidentielles ; ne pas purger ni écraser les preuves nécessaires au dossier.
4. Désactiver / retour arrière : Revenir dans Device Console et exécuter exactement une fois la même commande. Cette seconde exécution planifiée désactive à nouveau le débogage CSC.
5. Vérifier : Effectuer un court test contrôlé et confirmer dans les nouvelles lignes du journal CSC que la sortie de niveau debug a cessé et que la croissance du journal est revenue à son rythme normal. Consigner l’heure et le résultat du retour arrière. Si l’état initial ou le contrôle final est ambigu, ne pas répéter la bascule ; s’arrêter et coordonner l’état avec Sophos Support.

⚠️ Débogage WAF et reverseproxy.log : avec SFOS 22.0 MR2 Build 546, Sophos a corrigé le problème NC-177457 : un mot de passe était visible dans reverseproxy.log lorsque le débogage WAF était activé. Sophos ne précise ni le début de la plage de versions concernée ni le type de mot de passe. Les journaux de débogage WAF, archives de dépannage et fichiers CTR déjà générés à partir de builds plus anciens ou inconnus doivent donc être considérés comme susceptibles de contenir des identifiants.

Si un identifiant en clair est découvert : limiter l’accès, documenter l’incident et renouveler l’identifiant concerné. Ne pas supprimer systématiquement les journaux avant d’avoir clarifié les exigences du support, de l’analyse forensique et de la conservation.

Le sujet de la journalisation de débogage et des commandes CLI de base est décrit plus en détail dans l’article Dépannage CLI Sophos Firewall : commandes importantes. Pour redémarrer des services individuels, Redémarrer en toute sécurité les services Sophos Firewall est également utile.

Erreurs typiques lors de la recherche de journaux

De nombreuses analyses de journaux prennent du temps non pas à cause de données manquantes, mais parce que l’on cherche trop tôt dans le mauvais outil.

• Activer directement le debug : vérifier d’abord le Log Viewer, le fichier journal approprié et le test reproductible.
• Rechercher uniquement des messages d’erreur : restreindre aussi par source, destination, utilisateur, Rule ID, NAT Rule ID et heure.
• Ignorer Packet Capture : si l’on ne sait pas si les paquets arrivent ou sont transmis, utiliser Packet Capture tôt.
• Considérer Central Reporting comme du débogage en direct : utiliser Central Reporting pour l’historique et les rapports, les logs locaux pour l’analyse détaillée.
• Sauvegarder les logs de support plusieurs jours plus tard : sauvegarder les logs, l’heure et les étapes de reproduction tant que l’événement est encore traçable.
• Laisser le debug actif après le test : désactiver à nouveau le debug et contrôler l’espace disque.

Un bon cas de dépannage a donc toujours trois éléments : un test précis, la source de journal appropriée et une heure documentée. Sans cette base, on voit certes de nombreuses lignes de journal, mais pas nécessairement la cause.

Fichiers journaux par domaine fonctionnel

Les listes suivantes servent de référence. Le plus simple est de choisir d’abord le domaine fonctionnel concerné, puis de vérifier le fichier journal approprié sur une fenêtre temporelle étroite.

Les correspondances principales tiennent compte de SFOS 22.0 et 23.0 ; les fichiers OAuth SSO diffèrent entre ces versions, comme indiqué ci-dessous. Sur les installations plus anciennes ou dans d’anciennes archives de support, on peut également trouver les noms précédemment utilisés : app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log et crreportdb.log. Sophos ne les mentionne pas dans les listes de logs SFOS 22/23 prises en compte ici ; il ne faut donc pas supposer qu’ils existent sur un build actuel.

Les logs généraux du système et de la configuration sont à vérifier en complément de ceux du module concerné. Un fichier peut servir à plusieurs fonctions : ce qui compte, c’est sa signification dans le contexte précis du problème, et pas seulement le nom du service.

Système, gestion et services de base

• Démarrage du système : sysinit.log ; à vérifier en premier en cas de problèmes de démarrage ou de mode Failsafe.
• Messages système au niveau du noyau : syslog.log ; vérifier également l’heure, les redémarrages et les événements liés aux interfaces. Comparer aussi les événements système et ceux déclenchés par les administrateurs dans le Log Viewer.
• Serveur Web Apache pour WebAdmin et User Portal : apache.log, apache_access.log et error_log.log ; vérifier également Device Access et Local Service ACL.
• Application WebAdmin et User Portal : serveur d’applications Web Jetty, fichier journal tomcat.log ; vérifier également les erreurs de l’interface graphique, une charge élevée et l’état du service. Le nom du fichier n’est pas celui du serveur d’applications Web actuel.
• SSH : sshd.log ; vérifier également Device Access, le réseau source et la connexion par clé publique.
• Erreurs de l’interface graphique et de la CLI : error_log.log ; vérifier également la modification récente, le navigateur et l’action de l’administrateur.
• Modifications de configuration : applog.log, csc.log ; vérifier également Audit Trail et Config Studio.
• Base de données de configuration : postgres.log ; vérifier également l’espace disque, la sauvegarde/restauration et le cas de support.
• Canal de communication entre certains composants et leurs services : garner.log ; pour Central Management et le reporting, vérifier également les entrées des plugins correspondants.
• API : apiparser.log ; vérifier également validation.log, l’ACL de l’API, le token et Central Task Queue.
• Validation : validation.log, validationError.log ; vérifier également les objets ou imports incorrects.
• Gestion des licences : licensing.log ; vérifier également l’état des licences, la synchronisation avec Central et le cas particulier Air Gap.
• Mises à jour système : u2d.log ; vérifier également l’état des signatures, DNS/HTTPS et l’espace disque.

Pour les problèmes de gestion, il ne faut pas seulement vérifier le fichier journal WebAdmin. Très souvent, Device Access, une Local Service ACL Exception Rule ou un mauvais réseau source décide si WebAdmin, SSH, User Portal, VPN Portal, DNS ou SNMP sont joignables. Pour cette partie, Sécuriser l’accès à Sophos Firewall : Configurer correctement Device Access est le meilleur point d’entrée.

Pare-feu, NAT et Packet Capture

• Correspondance avec les règles de pare-feu : firewall_rule.log ; vérifier également le module Firewall du Log Viewer.
• Logs de pare-feu liés aux connexions : fwlog.log ; leur génération dépend de la journalisation de la règle de pare-feu et de Log settings. Utiliser également Packet Capture.
• Règles NAT : nat_rule.log ; vérifier également NAT Rule ID dans le Log Viewer.
• DNAT avec répartition de charge entre les liens : vérifier également dgd.log si la sélection de la passerelle ou du lien intervient.
• Packet Capture dans WebAdmin : pktcapd.log ; vérifier également Diagnostics > Packet capture.
• Gestion de la bande passante / QoS : bwm.log ; vérifier également Traffic Shaping Policy.
• Hôte virtuel / ancienne publication de serveurs : vhost.log ; vérifier également NAT et WAF.
• Protection des serveurs Web / WAF : reverseproxy.log ; certains détails de configuration WAF figurent également dans firewall_rule.log. Vérifier la règle WAF, Hosted address et la connectivité du backend.

Le NAT ne se résume pas à nat_rule.log : le paramètre NAT d’une connexion IPsec site à site se vérifie dans charon.log, et une commande NAT exécutée via la CLI dans applog.log. Cela permet de distinguer une configuration de tunnel d’une règle NAT ordinaire.

En cas de problèmes DNAT, toujours vérifier la règle de pare-feu et la règle NAT ensemble. NAT ne fait que traduire, mais n’autorise pas le trafic. Plus d’informations : Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT.

Sophos Firewall utilise pour les connexions de pare-feu, entre autres, IP tables, ARP table, IPset et conntrack. Pour QoS ou la gestion de la bande passante, IMQ est utilisé. Cette information est utile lorsque l’on voit des messages de journal ou des sorties de support avec des termes techniques du chemin réseau Linux.

IPS, Application Control et TLS Inspection

• Intrusion Prevention : service ips, log ips.log.
• Application Control : ips / Application Filter, log ips.log.
• DPI et TLS Inspection : DPI Engine, log ips.log.
• Antivirus dans le chemin réseau : service avd, log avd.log.
• Zero-Day Protection / Sandbox : service Sandbox, log sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds : ATR dans le chemin réseau ; vérifier d’abord le Log Viewer, puis ips.log selon le module.
• MDR Threat Feeds : ATR / statut du flux MDR, log atr.log ; le guide d’exploitation corrèle l’Audit ID, la Task Queue et la preuve de trafic locale.
• Mises à jour des signatures : service de mise à jour des signatures, log sig_upgrade.log.
• Signature migration : migration de signatures, log sigmigration.log.

appcached.log contient également le cache temporaire des applications catégorisées avant leur enregistrement dans la base de données ; son utilisation pour Application Based Routing est indiquée plus bas. Pour les flux de menaces MDR et tiers, atr.log indique l’état de la licence et de la configuration ; à lui seul, il ne démontre pas une décision concernant le trafic. Pour les IoC d’adresses IP, vérifier également firewall_rule.log. Pour les IoC de domaines ou d’URL, il faut examiner ensemble les logs du pare-feu, du DNS, de l’inspection SSL/TLS et du proxy Web : firewall_rule.log, dnsd.log, ips.log, httplogd.log et, selon le chemin de traitement, awarrenhttp.log. Les modules concernés mettent en œuvre Active Threat Response en fonction du type d’IoC.

De nombreuses fonctions de protection modernes ne voient suffisamment de détails que lorsque HTTPS est déchiffré. Si l’inspection TLS ne s’applique pas, les filtres Web, le contrôle des applications, IPS et l’analyse des logiciels malveillants sont moins pertinents selon le trafic.

Si l’on ne sait pas si IPS est actif, quelle politique s’applique ou pourquoi une signature bloque, il est utile de commencer par Configurer et tester en toute sécurité IPS sur Sophos Firewall. Ensuite, on peut combiner plus précisément ips.log, Log Viewer et Packet Capture.

S’il s’agit de la détection d’applications, du filtre d’application ou de blocages inattendus de contrôle des applications, Configurer et tester le contrôle des applications sur Sophos Firewall est approprié.

Pour Zero-Day Protection, il faut également vérifier que Web Protection, TLS Inspection, le type et la taille du fichier, la politique et l’action sont cohérents. L’article d’exploitation approprié est Comprendre et exploiter Sophos Firewall Zero-Day Protection. Pour Threat Feeds, utilisez Configurer et exploiter en sécurité les Threat Feeds Sophos Firewall. Plus d’informations sur TLS Inspection : Déployer progressivement l’inspection TLS sur Sophos Firewall.

Web, Proxy, WAF et filtre Web

• HTTP et HTTPS via le proxy Web : service awarrenhttp, fichier journal awarrenhttp.log.
• Accès au proxy HTTPS : log d’accès de awarrenhttp, fichier journal awarrenhttp_access.log. Pour SFOS 22/23 : les requêtes individuelles au proxy Web n’apparaissent ici que si awarrenhttp fonctionne avec le debug activé ; suivre la procédure de collecte ci-dessous.
• Catégorisation Web / réputation : service nSXLd, fichier journal nSXLd.log.
• Mises à jour des catégories (SFOS 22/23) : fichier journal catUpdateLog — respecter la casse, sans extension .log.
• FTP via le proxy HTTP : service skein, fichier journal skein.log.
• Proxy FTP : service ftpproxy, fichier journal ftpproxy.log.
• Pare-feu d’applications Web : proxy inverse, fichier journal reverseproxy.log.

Pour cette collecte du journal d’accès, identifier d’abord le nœud de pare-feu/HA concerné, le cas de test, l’heure et une courte fenêtre de collecte, vérifier l’espace disque et confirmer avec les autres administrateurs ou le support que le debug est désactivé. Ne pas utiliser la commande de bascule pour consulter l’état. Exécuter ensuite service awarrenhttp:debug -ds nosync exactement une fois dans Advanced Shell, reproduire le problème ciblé et conserver awarrenhttp_access.log de manière sécurisée. Puis exécuter la même commande exactement une fois pour désactiver à nouveau le debug. Avec un bref test contrôlé, vérifier qu’aucune nouvelle entrée de debug n’apparaît et que le journal normal reprend son rythme habituel ; documenter le retour arrière et le contrôle de l’espace disque. Si l’état initial ou la vérification finale n’est pas clair, ne pas continuer à basculer et clarifier la situation avec le support. Cette méthode s’applique ici à awarrenhttp dans SFOS 22/23, pas à tous les services ou versions de manière générale.

Pour une boucle proxy présumée, block_proxy_loop associé à un debug awarrenhttp brièvement activé peut produire Duplicate Via header values, proxy loop. Vérifier les paramètres HTTP Proxy en toute sécurité décrit la condition, l’effet global et le retour arrière sûr. Le debug reste actif uniquement pendant le test reproductible.

Si le trafic Web apparaît comme bloqué dans le Log Viewer, la cause peut se trouver dans plusieurs modules : politique Web, inspection SSL/TLS, contrôle des applications, IPS ou WAF. Par conséquent, toujours sélectionner le module spécifique dans le Log Viewer et vérifier également le fichier journal approprié.

Sophos bloque toujours les sites Web de la catégorie highly objectionable criminal activity et masque le nom de domaine dans les logs et les rapports. Il ne s’agit pas d’une action par défaut que l’on peut choisir librement. Si une entrée dans cette catégorie semble volontairement anonymisée, cela peut donc être intentionnel.

Pour les catégories Web, les groupes d’URL, les politiques Web et les alertes instantanées, Utiliser les catégories Web et les alertes instantanées de Sophos Firewall est approprié.

VPN

• IPsec à partir de SFOS v17+ : services strongswan, charon ; logs strongswan.log, charon.log.
• IPsec spécifique à une connexion : connexion IPsec individuelle, log /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec versions antérieures : service IPsec, log ipsec.log.
• IPsec Monitoring : moniteur IPsec, log ipsec_monitor.log.
• XFRM / route-based VPN : service xfrmi, log xfrmi.log.
• SSL VPN : SSL VPN / OpenVPN, log sslvpn.log.
• SSL VPN Status : OpenVPN Status, log openvpn-status*.log.
• VPN Portal : log vpnportal.log.
• L2TP : service l2tpd, log l2tpd.log. L2TP Remote Access sur Sophos Firewall explique la configuration et le diagnostic.
• PPTP : VPN PPTP, log pptpvpn.log.
• Certificats VPN : VPN Certificate Services, log vpncertificate.log.
• Clientless SSL VPN : Clientless Access, log clientless_access.log.

Sophos Firewall utilise strongSwan pour IPsec VPN et OpenVPN pour SSL VPN. En cas de problèmes IPsec, l’heure, l’IP du pair, la proposition, les sous-réseaux locaux/distants, NAT-T, le routage et les règles de pare-feu sont essentiels.

Ces implémentations s’appliquent aussi bien au site à site qu’à l’accès distant. /log/ipsec_conn/ipsec_<connectionname>.log contient notamment les actions WebAdmin propres à la connexion pour activer, désactiver et connecter le tunnel ; <connectionname> est à remplacer par le nom réel de la connexion. Pour l’authentification des utilisateurs VPN, vérifier également access_server.log et, en cas de problèmes de portail, vpnportal.log. En cas de problèmes avec le client Sophos Connect, le rapport de support technique du client doit également être conservé comme élément de diagnostic : les logs du pare-feu seuls ne montrent pas l’état complet du client. La procédure de dépannage IPsec aide à rapprocher les constats côté client et côté pare-feu.

Pour les problèmes IPsec, l’article Dépannage IPsec Sophos Firewall est le meilleur guide étape par étape. S’il s’agit de VPN basé sur les routes et de routes IPsec manuelles, Créer une route IPsec sur Sophos Firewall est utile.

Authentification, Portail utilisateur et SSO

• Authentification, autorisation et accounting des utilisateurs : Access Server / AAA, fichier journal access_server.log.
• NTLM / NASM : service nasm, fichier journal nasm.log.
• Chromebook SSO : backend Chromebook SSO, fichier journal chromebook-sso-backend.log.
• Déroulement du SSO Chromebook : csd.log ; à distinguer du log du backend.
• OAuth SSO Captive Portal (SFOS 22) : fichier journal oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22) : fichier journal oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22) : fichier journal oauth_sso_vpn.log.
• OAuth SSO (SFOS 23) : oauth_sso_svc.log pour les connexions SSO à WebAdmin, Captive Portal, VPN Portal, IPsec VPN et SSL VPN.
• RADIUS SSO : association utilisateur-IP via l’accounting dans access_server.log. La configuration et la validation sont expliquées dans RADIUS SSO avec accounting.
• STAS : contexte STAS / Access Server, selon le contexte du service et access_server.log.

Pour les règles utilisateur, toujours vérifier d’abord si l’utilisateur est connu. Si Match known users est activé et que l’authentification ne fonctionne pas, la règle ne correspond pas. Pour les connexions classiques dans le navigateur, Configurer et tester Captive Portal sur Sophos Firewall réunit Device Access, la règle utilisateur, Live users, Log Viewer et access_server.log dans une procédure de diagnostic complète.

S’il reste difficile de déterminer si l’échec concerne la sélection du service, l’identité, la Main Group, le quota ou seulement le chemin de trafic ultérieur, Résoudre méthodiquement les erreurs d’authentification sur Sophos Firewall réunit ces niveaux dans une même procédure de diagnostic.

Si le portail captif est utilisé avec Microsoft Entra ID SSO, Configurer Microsoft Entra ID SSO pour le portail captif Sophos Firewall aide à la vérification de oauth_sso_captive.log (SFOS 22 ; dans SFOS 23 : oauth_sso_svc.log), Device Access, groupes et correspondance de règle ultérieure.

DNS, DHCP et réseau

• Service DNS : service dnsd, fichier journal dnsd.log.
• Service FQDN avec caractères génériques / DNS Grabber : service dnsgrabber, fichier journal dnsgrabber.log.
• Entité DNS / autres composants DNS : services entity, eacd ; fichiers journaux entity.log, eacd.log.
• DHCP IPv4 : service dhcpd, fichier journal dhcpd.log.
• DHCP IPv6 : fichier journal dhcpd6.log.
• Interfaces physiques et virtuelles : service networkd, fichier journal networkd.log.
• Hôtes FQDN : service fqdnd, fichier journal fqdnd.log.
• Détection des passerelles indisponibles et gestion du WAN/des passerelles : service dgd, fichier journal dgd.log ; vérifier également le basculement des liens, le basculement VPN et le DNAT.
• DNS dynamique : client DNS dynamique, fichier journal ddc.log.
• Client NTP : fichier journal ntpclient.log.
• Annonces de routeur IPv6 : service radvd, fichier journal radvd.log.

Les problèmes DNS et DHCP ressemblent souvent à des problèmes de pare-feu. Par conséquent, il faut d’abord vérifier l’adresse IP, la passerelle, le serveur DNS et si les clients doivent utiliser le pare-feu comme serveur DNS ou DHCP.

Si les domaines internes ne sont pas résolus correctement, Configurer les routes de requêtes DNS sur Sophos Firewall est généralement pertinent. Pour les options DHCP spéciales, l’article Configurer les options DHCP de Sophos Firewall est disponible.

WAN cellulaire

• WWAN / Modem USB : vérifier l’insertion et le retrait de périphériques USB dans modemd.log.
• Configuration réseau du modem : vérifier les interfaces liées au modem et la configuration IP dans networkd.log.
• USB, Modem et PPP : vérifier les messages Syslog concernant USB, modem et Point-to-Point Protocol dans syslog.log.

En cas de problèmes WAN cellulaire, il faut également vérifier si le modem est reconnu, si le PIN/SIM/APN sont corrects et si le pare-feu crée une passerelle appropriée.

Routage

• Routes unicast statiques : fichier journal staticd.log. La configuration et la vérification sont expliquées dans Configurer une route statique sur Sophos Firewall.
• Installation des routes unicast IPv4 statiques : service zebra, fichier journal zebra.log.
• Routage basé sur les applications : service appcached, fichier journal appcached.log.
• Routage multicast : fichier journal mrouting.log.
• BGP et BGP-IPv6 : service bgpd, fichier journal bgpd.log. La configuration et la validation sont expliquées dans Configurer BGP sur Sophos Firewall ; zebra.log aide également à vérifier si une route dynamique IPv4 ou IPv6 apprise a été installée dans le noyau.
• OSPFv2 et OSPFv3 : services ospfd et ospf6d, fichiers journaux ospfd.log et ospf6d.log. zebra.log indique également si la route dynamique a été intégrée au système. La configuration et la validation sont expliquées dans Configurer OSPF sur Sophos Firewall.
• RIP : service ripd, fichier journal ripd.log. La configuration et la validation sont expliquées dans Configurer RIPv2 sur Sophos Firewall ; zebra.log indique également si une route apprise a été installée dans la pile de routage.
• PIM-SM : service pimd, fichier journal pimd.log. La configuration et la validation sont expliquées dans Configurer PIM-SM sur Sophos Firewall.

En cas de problèmes de routage, vérifier également Routing > SD-WAN routes, les passerelles et Packet Capture. Le testeur de politique ne remplace pas un véritable test de routage.

Pour les routes statiques et dynamiques, csc.log fournit également des informations sur les opcodes et des indications sur les redémarrages de services. Dans un contexte HA, on ajoute ha.log, msync.log et applog.log. Pour les routes SD-WAN, vérifier, en plus de appcached.log, applog.log, csc.log et dgd.log ; si IPsec intervient, consulter également les logs IPsec.

Plus d’informations : Ajuster la priorité de routage sur Sophos Firewall.

GUI, CLI et accès système

Pour WebAdmin, SSH, API et les services de gestion locaux, la liste de base se trouve plus haut sous Système, gestion et services de base. Si WebAdmin ou SSH n’est pas accessible, ne pas seulement vérifier apache.log, tomcat.log ou sshd.log. L’accès local est contrôlé via Administration > Device access et Local Service ACL.

Plus d’informations : Établir une connexion SSH à Sophos Firewall.

Sophos Fusion, Heartbeat et gestion centrale

• Sophos Central Management : Central Management, fichiers journaux centralmanagement.log, sophos-central.log.
• CSC et services auxiliaires : services csc, cschelper, csd ; fichiers journaux csc.log, cschelper.log, csd.log. cschelper.log concerne les e-mails générés par le système et les outils d’authentification, csd.log le déroulement du SSO Chromebook.
• Security Heartbeat et Synchronized Security : heartbeatd.log contient l’état des endpoints et les informations sur les applications envoyés au pare-feu ; hbtrust.log contient les échanges avec Central. Les services s’appellent heartbeatd et hbtrust ; vérifier également csc.log et applog.log.
• Synchronized Application Control : vérifier les données envoyées à SophosLabs dans sac-feedback.log.
• Optimisation de la base de données SAC (SFOS 22/23) : sac-vacuum.log consigne l’optimisation hebdomadaire de la base de données Synchronized Application Control ; sac-feedback.log reste le log distinct des données envoyées à SophosLabs.
• Événements Central, connexion et transfert de configuration : fwcm-eventd.log indique les informations de zones/interfaces envoyées pour les objets dynamiques, fwcm-heartbeatd.log la connexion et fwcm-updaterd.log la configuration transférée. Les services s’appellent fwcm-eventd, fwcm-heartbeatd et fwcm-updaterd ; tous les trois ne sont pas des services Heartbeat.
• Central API Executor : service fwcm-api-executor, fichier journal fwcm-api-executor.log.
• Active Threat Response : contexte ATR ; à vérifier selon la version et le module.

En cas de problèmes avec Sophos Fusion, vérifier d’abord si le pare-feu est enregistré, si les services Central sont actifs et si DNS/HTTPS sortant fonctionne. Si une modification provenant de Sophos Fusion n’arrive pas localement, il faut comparer la file d’attente des tâches du pare-feu Sophos Fusion avec les logs locaux. Un statut Sophos Fusion vert ne prouve pas à lui seul qu’une politique précise a été traitée localement.

Pour l’enregistrement et les tokens d’accès, sophos-central.log est pertinent ; pour la gestion et le reporting activés, c’est centralmanagement.log. L’enregistrement et le désenregistrement sont également à recouper avec applog.log, et les mises à niveau du firmware avec csc.log. hbtrust.log montre les échanges ; dans garner.log, les entrées du plugin SCM correspondent à Central Management et celles du plugin CR à Central Reporting. fwcm-api-executor.log contient également les analyses MDR transférées au pare-feu. La documentation SFOS 22 prise en compte nomme la plateforme Sophos Fusion (anciennement Sophos Central), tandis que la documentation SFOS 23 la nomme Sophos Central ; les noms existants des services et des fichiers restent inchangés.

Haute disponibilité

• État et configuration HA : log de l’application HA, fichier journal applog.log.
• Détection du pair HA dans QuickHA : service ha_pair, fichier journal ha_pair.log.
• Tunnel SSH entre les appareils HA via le lien dédié : service ha_tunnel, fichier journal ha_tunnel.log.
• Synchronisation Conntrack : service ctsyncd, fichier journal ctsyncd.log.
• Msync : service msync, fichier journal msync.log.
• Mise en place de HA et changements d’état : ha.log.
• Synchronisation des fichiers de certains services vers l’appareil auxiliaire : filesync.log.

Les logs et rapports HA ne sont pas synchronisés entre les appareils. Chaque nœud conserve uniquement les données du trafic qu’il a lui-même traité. Il faut donc vérifier Log Viewer et Diagnostics > Tools > Troubleshooting logs sur chaque appareil concerné. Pour récupérer les troubleshooting logs de l’appareil Auxiliary, se connecter directement à sa CLI avec l’adresse IP ou le FQDN de son interface d’administration. Sophos Central Firewall Reporting peut combiner les rapports des deux appareils, mais ne remplace pas les fichiers de dépannage locaux aux nœuds.

Mail et anti-spam

• Antivirus : service AV, fichier journal avd.log.
• Mises à jour antivirus : Up2Date AV, fichier journal up2date_av.log.
• Antispam : service sasi, fichier journal sasi.log.
• Sandbox : service sandboxd, fichier journal sandboxd.log.
• SMTP MTA : service smtpd, fichier journal smtpd_main.log.
• Erreurs SMTP en mode MTA : smtpd_error.log pour les erreurs d’analyse des e-mails, smtpd_panic.log pour les erreurs internes et smtpd_reject.log pour les e-mails rejetés ; le service est smtpd.
• Proxy SMTP/S en mode Legacy : services awarrensmtp, awarrenmta ; fichiers journaux awarrensmtp.log, awarrenmta.log. La configuration et le test de bout en bout sont expliqués dans Mail Protection en mode Legacy.
• Proxy POP/IMAP : service warren, fichier journal warren.log. La configuration et le test de bout en bout sont expliqués dans Analyser POP3 et IMAP sur Sophos Firewall.

En cas de problèmes de messagerie, toujours vérifier si le mode MTA, la règle de pare-feu, DNS, les certificats et les restrictions du fournisseur sont compatibles. La procédure pour le flux de messagerie, la file d’attente, la quarantaine et le relais est décrite dans Configurer la protection des mails de Sophos Firewall en mode MTA.

Sophos Firewall utilise Avira et Sophos Antivirus. Le service anti-spam ne démarre que si une politique de spam entrante ou sortante est présente. Cette dépendance est importante si sasi.log reste vide ou si le service anti-spam ne fonctionne pas.

Sans fil, RED, Hotspot et autres services

• Contrôleur sans fil et communication des AP/APX avec le pare-feu : service awed, fichier journal awed.log.
• Clients sans fil : communication entre le client et l’AP/APX dans wc_remote.log.
• SSID LocalWifi : service hostapd, fichier journal hostapd.log ; à ne pas confondre avec les événements du hotspot.
• Événements du hotspot : service hotspotd, fichier journal hotspotd.log.
• RED : red.log consigne tous les appareils RED configurés, y compris les RED site à site et les SD-RED. red-<serial ID of RED>.log correspond à l’appareil SD-RED concerné, red-<RED ID>.log à la configuration RED site à site concernée. La RED ID se trouve sous Network > Interfaces, en ouvrant le RED site à site correspondant. Les espaces réservés sont à remplacer par son numéro de série réel ou sa RED ID réelle.
• SNMP : service snmpd, fichier journal snmpd.log.
• Service Syslog : fichier journal syslog.log.
• Gestion des licences : service de gestion des licences, fichier journal licensing.log.
• Mises à jour système : service u2d, fichier journal u2d.log.
• VMware Tools : service vmtool, fichier journal vmtool.log.

En cas de problèmes de licence, d’Air Gap ou de patterns, licensing.log et u2d.log sont les premiers points de contact techniques. Pour le fonctionnement avec fichier de licence, fenêtre de 180 jours et mises à jour manuelles des patterns, Gérer la licence et les mises à jour des patterns en mode Air Gap de Sophos Firewall est approprié.

Base de données et reporting

• Base de données de configuration : Config DB, fichier journal postgres.log.
• Postgres : service postgres, fichier journal postgres.log.
• Base de données des signatures : service sigdb, fichier journal sigdb.log.
• Base de données des rapports : nouvelle base de données des rapports à partir de SFOS 21.0, fichier journal reportdb.log.
• Base de données de migration : migration des rapports, fichier journal reportmigration.log.
• Migration de configuration (SFOS 22/23) : fichier journal migration.log ; à ne pas confondre avec reportmigration.log, destiné à la migration des rapports.
• Garner : service garner, fichier journal garner.log.
• Visualisation des logs dans WebAdmin : service iview, fichier journal iview.log.

Si des rapports manquent, sont lents ou si des problèmes d’espace de stockage surviennent, les journaux de reporting et de base de données sont pertinents. Il faut également vérifier si les rapports sont enregistrés localement ou envoyés à Sophos Fusion.

Autres fichiers journaux pour SFOS 22/23

Les fichiers suivants sont moins souvent nécessaires au dépannage quotidien du trafic, mais font partie des correspondances SFOS 22/23. Ils sont regroupés par fonction afin de ne pas déduire trop vite une cause à partir d’un nom de fichier :

• Audit, FIPS et accès du support : configuration-audit.log consigne la modification de configuration, l’administrateur et l’horodatage ; fips.log le démarrage en mode FIPS ; uma.log l’accès du support.
• Pipeline de logs et maintenance des données locales : syslog-ng.log indique la suppression des entrées consécutives correspondant au même événement ; reportdb_v9.log appartient à l’ancienne base de données des rapports. dbcleanup.log concerne le nettoyage de la base de données au redémarrage du pare-feu, readobject.log la lecture interne des objets, fstrim.log l’opération de TRIM du système de fichiers et logrotate.log la rotation vers des fichiers .gz.
• ATR, NDR Essentials et FastPath : atr-service.log indique le démarrage et l’arrêt du service ATR. ndr.log couvre la licence NDR, la configuration et le démarrage de l’agent ; ndr_agent.log le démarrage du service et le traitement des métadonnées. vfpdf.log indique les métadonnées envoyées par FastPath à NDR Essentials exclusivement sur les XGS 88/88w, 108/108w, 118/118w et 128/128w. setup_vf_dpdk.log consigne l’initialisation de la mémoire FastPath et ne s’applique précisément pas à ces quatre gammes de modèles.
• TLS et SSL VPN : httplogd.log indique les connexions HTTPS non déchiffrées dans le chemin DPI. peruser_cert_sslvpn.log consigne les certificats SSL VPN générés pour chaque utilisateur ; openvpn-status0.log, openvpn-status1.log et les autres fichiers numérotés indiquent les connexions SSL VPN actives par processus.
• Réseau et HA : dhcprelay.log correspond au relais DHCP. ha.log indique la réussite ou l’échec de la mise en place de HA ainsi que les changements d’état ; filesync.log la synchronisation des fichiers de certains services vers l’appareil auxiliaire.
• Central, déploiement et ZTNA : fwcm-eventd.log, fwcm-heartbeatd.log et fwcm-updaterd.log couvrent les informations de zones/interfaces, la connexion et le transfert de configuration. fwcm-frpcd.log concerne le Fast Reverse Proxy lors de l’ouverture simultanée de plusieurs pare-feu dans Central. ssod.log contient les informations de mise à niveau du firmware envoyées à Central et les sauvegardes de pare-feu qui y sont créées. Pour True/Controlled Zero Touch, vérifier zt.log et fwcm-heartbeatd.log ; pour Zero Touch via USB, zerotouch.log, et non fwcm-heartbeatd.log. ztna-connector.log contient les identifiants du compte client et du connecteur, l’état du connecteur, les tunnels ZTNA, les applications utilisées et les mises à jour de configuration.
• Sauvegarde, firmware, Air Gap et certificats : interfacemapping.log consigne la correspondance des interfaces lors de la restauration, legacyconversion.log les sauvegardes sans Secure Storage Master Key et fwmgmt.log l’installation et la gestion du firmware. u2d_airgap.log s’applique aux mises à jour Air Gap, cps_messages.log aux erreurs de hotfix et letsencrypt.log, avec applog.log, aux certificats Let’s Encrypt.
• API, restauration et gestion des certificats : apiparser.log concerne la traduction de l’API entre JSON et XML, validation.log et validationError.log la validation de l’API. Pour la sauvegarde/restauration, vérifier également applog.log et postgres.log. vpncertificate.log couvre non seulement les certificats VPN, mais aussi les CA, les CSR et les CRL.
• Matériel et état du système : npu-startup.log indique le démarrage du NPU, npu_syslog.log les syslogs du NPU et xgs-host.log les pilotes hôtes au démarrage. xgs-npu-fw.log concerne la vérification de compatibilité, la mise à niveau et la récupération du NPU, xgs-npu-serial.log le port série du NPU et xgs-pport-wait.log la création des interfaces physiques au démarrage. xgs-healthmond.log couvre l’utilisation du CPU, la température, la vitesse des ventilateurs et le port de gestion du NPU. raid.log indique le RAID logiciel et lcd.log l’affichage matériel. Sur les pare-feu matériels, virtuels, cloud et logiciels, system-monitor/cpu_trigger.log et system-monitor/memory_trigger.log enregistrent l’état du système en cas de forte charge CPU ou mémoire, respectivement ; tous deux sont répertoriés pour SFOS 22/23.
• Syslogs FastPath : npu_syslog.log concerne FastPath basé sur le NPU et ne s’applique pas aux XGS 88/88w, 108/108w, 118/118w et 128/128w. syslog.log indique la communication de l’hôte avec FastPath basé sur le NPU ainsi qu’avec Virtual FastPath. Pour VMware, vérifier également syslog.log, en plus du log VMware Tools vmtool.log.
• Services cloud et de plateforme : iaasd.log consigne le provisionnement de la configuration et la vérification des licences dans Azure, waagent.log le provisionnement au niveau du système d’exploitation et la surveillance de l’état de santé par l’agent de provisionnement Azure ; vmtool.log correspond à VMware Tools.

La présence d’un fichier ne prouve pas une erreur dans ce module. Il faut d’abord corréler l’heure de l’événement, le nœud concerné, la plateforme, l’état du service et un symptôme reproductible, puis seulement effectuer une recherche filtrée dans le fichier approprié.

Déroulement de l’analyse

1. Noter précisément le problème : heure avec fuseau horaire, client, cible, port, utilisateur, action.
2. Décider s’il s’agit de trafic, d’état de service, de changement de configuration ou de synchronisation Central.
3. Filtrer le Log Viewer par IP source, IP de destination, module et heure.
4. Vérifier la visibilité de Firewall Rule ID, NAT Rule ID, utilisateur, gateway et Policy IDs.
5. Utiliser Packet Capture si le flux de paquets, le retour ou la vue NAT sont incertains.
6. Vérifier le fichier journal approprié avec tail -f, less ou grep.
7. Reproduire le problème et documenter l’heure exacte du test.
8. Si nécessaire, activer le debug uniquement pour le service concerné et seulement brièvement.
9. Désactiver à nouveau le debug et vérifier l’espace disque.
10. Sauvegarder les logs tant que l’erreur a été fraîchement reproduite.

Pour les cas de support, il est également important de documenter tous les messages d’erreur, les étapes de reproduction et les étapes de dépannage déjà effectuées. Ces informations accélèrent considérablement les cas de support. La procédure appropriée est décrite dans Ouvrir un ticket de support Sophos : préparation et portail.

FAQ