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.

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 :

Un seul flux de trafic est concerné : filtrer le Log Viewer par source, destination, service et heure.
Le Log Viewer ne montre aucune décision : démarrer Packet Capture avec un filtre étroit.
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é.
Un service spécifique semble instable : observer le fichier approprié sous /log avec tail -f.
Une erreur est sporadique ou nécessite un support : préparer la fenêtre temporelle, le filtre, l’archive de logs et éventuellement tcpdump.
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.

Se connecter à la CLI, choisir 5 Device Management, puis 3 Advanced Shell.
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 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 :

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.
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.
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.
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.
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 suivent la documentation SFOS 22.0 actuelle. Sur des installations plus anciennes ou dans d’anciennes archives de support, les noms autrefois 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 peuvent également apparaître. Sophos ne les mentionne plus dans la liste actuelle des journaux SFOS 22.0 ; il ne faut donc pas supposer qu’ils existent sur un build actuel.

Système, gestion et services de base

Démarrage du système : sysinit.log ; à vérifier en premier pour les problèmes de démarrage et de Failsafe.
Messages système : syslog.log ; vérifier aussi l’heure, les redémarrages et les événements d’interface.
Serveur WebAdmin : apache.log, apache_access.log ; vérifier aussi Device Access et Local Service ACL.
Application WebAdmin : tomcat.log ; vérifier aussi les erreurs GUI, la charge élevée et le statut du service.
SSH : sshd.log ; vérifier aussi Device Access, le réseau source et l’authentification par clé publique.
Erreurs GUI/CLI : error_log.log ; vérifier aussi la modification récente, le navigateur et l’action admin.
Changements de configuration : applog.log, csc.log ; vérifier aussi Audit Trail et Config Studio.
Base de données de configuration : postgres.log ; vérifier aussi stockage, backup/restore et cas de support.
Canal de communication entre certains composants et leurs services : garner.log ; pour Central Management et reporting, vérifier également les entrées des plugins concernés.
API : apiparser.log ; vérifier aussi validation.log, API-ACL, token et Central Task Queue.
Validation : validation.log, validationError.log ; vérifier aussi les objets ou imports défectueux.
Licensing : licensing.log ; vérifier aussi le statut de licence, Central Sync et les cas Air-Gap.
System Updates : u2d.log ; vérifier aussi le statut des patterns, 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 de règle de pare-feu : firewall_rule.log ; vérifier aussi le module Log Viewer Firewall.
Traitement général du pare-feu : fwlog.log ; utiliser aussi Packet Capture.
Règles NAT : nat_rule.log ; vérifier aussi la NAT Rule ID dans le Log Viewer.
DNAT avec Link Load Balancing : vérifier aussi dgd.log si la sélection de gateway ou de lien est impliquée.
Packet Capture dans WebAdmin : pktcapd.log ; vérifier aussi Diagnostics > Packet capture.
Bandwidth Management / QoS : bwm.log ; vérifier aussi Traffic Shaping Policy.
Virtual Host / publication de serveur plus ancienne : vhost.log ; vérifier aussi NAT et WAF.
Web Server Protection / WAF : reverseproxy.log ; vérifier aussi règle WAF, Hosted address et accessibilité du backend.

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.

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

HTTPS Proxy : service awarrenhttp, log awarrenhttp.log.
HTTPS Proxy Access : awarrenhttp Access Log, log awarrenhttp_access.log.
Web Categorization / Reputation : service nSXLd, log nSXLd.log.
Legacy HTTP/FTP Proxy : service skein, log skein.log.
FTP Proxy : service ftpproxy, log ftpproxy.log.
Web Application Firewall : reverse proxy, log reverseproxy.log.

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 les sites Web de la catégorie activité criminelle hautement répréhensible par défaut et masque le nom de domaine dans les journaux et rapports. Si une entrée dans cette catégorie semble délibérément anonymisée, cela peut ê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.

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 des utilisateurs : Access Server / AAA, log access_server.log.
NTLM / NASM : service nasm, log nasm.log.
Chromebook SSO : Chromebook SSO Backend, log chromebook-sso-backend.log.
OAuth SSO Captive Portal : log oauth_sso_captive.log.
OAuth SSO WebAdmin : log oauth_sso_webadmin.log.
OAuth SSO VPN : log oauth_sso_vpn.log.
RADIUS SSO : association utilisateur-IP par accounting dans access_server.log. RADIUS SSO avec accounting explique la configuration et la validation.
STAS : contexte STAS / Access Server, selon le contexte de 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, Device Access, groupes et correspondance de règle ultérieure.

DNS, DHCP et réseau

DNS Service : service dnsd, log dnsd.log.
DNS Grabber : service dnsgrabber, log dnsgrabber.log.
DNS Entity / autres composants DNS : services entity, eacd ; logs entity.log, eacd.log.
DHCP IPv4 : service dhcpd, log dhcpd.log.
DHCP IPv6 : log dhcpd6.log.
Service réseau : service networkd, log networkd.log.
FQDN Hosts : service fqdnd, log fqdnd.log.
Dead Gateway Detection : service dgd, log dgd.log.
Dynamic DNS : Dynamic DNS Client, log ddc.log.
NTP Client : log ntpclient.log.
IPv6 Router Advertisement : service radvd, log 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 : log staticd.log. Configurer et tester une route statique sur Sophos Firewall explique leur configuration et leur vérification.
Installation de routes Unicast IPv4 statiques : service zebra, log zebra.log.
Application Based Routing : service appcached, log appcached.log.
Routage multicast : log mrouting.log.
BGP : service bgpd, log bgpd.log. Configurer et valider BGP sur Sophos Firewall explique la mise en place et la validation ; zebra.log aide également à déterminer si une route apprise a été installée dans le système.
OSPFv2 et OSPFv3 : services ospfd et ospf6d, logs ospfd.log et ospf6d.log. Le fichier zebra.log indique en plus si la route dynamique a été installée dans le système. Configurer et valider OSPF sur Sophos Firewall explique la mise en place et la validation.
RIP : service ripd, log ripd.log. Configurer et valider RIPv2 sur Sophos Firewall explique la configuration et la validation ; zebra.log indique également si une route apprise a été installée dans le stack de routage.
PIM-SM : service pimd, log pimd.log. Configurer et valider PIM-SM sur Sophos Firewall explique la mise en place et la vérification.

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.

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, logs centralmanagement.log, sophos-central.log.
CSC : services csc, cschelper, csd ; logs csc.log, cschelper.log, csd.log.
Security Heartbeat : services heartbeatd, hbtrust ; logs heartbeatd.log, hbtrust.log.
Synchronized Application Control : vérifier les données envoyées à SophosLabs dans sac-feedback.log.
Heartbeat vers Central : services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd ; vérifier les logs de service respectifs.
Central API Executor : service fwcm-api-executor, log 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.

Haute disponibilité

Statut et configuration HA : HA Application Log, log applog.log.
HA Pair Service : service ha_pair, log ha_pair.log.
HA Tunnel : service ha_tunnel, log ha_tunnel.log.
Conntrack Sync : service ctsyncd, log ctsyncd.log.
Msync : service msync, log msync.log.
Établissement HA et changements d’état : ha.log.
Synchronisation des fichiers de certains services vers l’appareil Auxiliary : 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 : AV Service, log avd.log.
Antivirus Updates : Up2Date AV, log up2date_av.log.
Anti-Spam : service sasi, log sasi.log.
Sandbox : service sandboxd, log sandboxd.log.
SMTP MTA : service smtpd, log smtpd_main.log.
Erreurs SMTP : smtpd Error/Panic/Reject, logs smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
Legacy SMTP/S Proxy : services awarrensmtp, awarrenmta ; logs awarrensmtp.log, awarrenmta.log. Mail Protection en Legacy mode explique la configuration et le test de bout en bout.
POP/IMAP Proxy : service warren, log warren.log. Analyser POP3 et IMAP sur Sophos Firewall explique la configuration et le test de bout en bout.

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

Wireless Controller : service awed, log awed.log.
Clients sans fil : vérifier la communication entre le client et l’AP/APX dans wc_remote.log.
Hotspot : services hostapd, hotspotd ; logs hostapd.log, hotspotd.log.
RED : RED Service, log red.log. Selon le type et l’instance RED, red-<serial ID of RED>.log et red-<RED ID>.log peuvent également apparaître.
SNMP : service snmpd, log snmpd.log.
Syslog Service : log syslog.log.
Licensing : Licensing Service, log licensing.log.
System Updates : service u2d, log u2d.log.
VMware Tools : service vmtool, log 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, log postgres.log.
Postgres : service postgres, log postgres.log.
Base de données des signatures : service sigdb, log sigdb.log.
Base de données des rapports : Report DB, log reportdb.log.
Base de données de migration : Report Migration, log reportmigration.log.
Garner : service garner, log garner.log.
iView : service iview, log 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 actuels de SFOS 22

Les fichiers suivants sont moins souvent nécessaires pour le dépannage quotidien du trafic, mais font partie de la cartographie actuelle de SFOS 22. Ils sont regroupés par fonction afin d’éviter de déduire trop rapidement une cause à partir d’un nom de fichier :

Audit, FIPS et accès au support : configuration-audit.log enregistre la modification de configuration, l’administrateur et l’heure ; fips.log le démarrage en mode FIPS ; uma.log le Support Access.
Pipeline des logs et maintenance des données locales : syslog-ng.log montre la suppression d’événements consécutifs ; reportdb_v9.log appartient à l’ancienne base de données de rapports. dbcleanup.log, readobject.log, fstrim.log et logrotate.log couvrent le nettoyage de la base de données, la lecture interne des objets, l’optimisation du système de fichiers et la rotation des logs.
ATR, NDR et FastPath : atr-service.log montre le démarrage et l’arrêt du service ATR. ndr.log et ndr_agent.log couvrent la licence NDR, la configuration, le démarrage de l’agent et le traitement des métadonnées ; vfpdf.log s’applique aux métadonnées NDR sur les XGS 88/88w, 108/108w, 118/118w et 128/128w. setup_vf_dpdk.log journalise l’initialisation mémoire de FastPath et ne s’applique précisément pas à ces quatre gammes.
TLS et SSL VPN : httplogd.log montre les connexions HTTPS non déchiffrées dans le chemin DPI. peruser_cert_sslvpn.log enregistre les certificats SSL VPN générés par utilisateur ; openvpn-status0.log, openvpn-status1.log et les autres fichiers numérotés montrent les connexions SSL VPN actives par processus.
Réseau et HA : dhcprelay.log concerne DHCP Relay. ha.log montre la réussite ou l’échec de l’établissement HA ainsi que les changements d’état ; filesync.log la synchronisation de fichiers de certains services vers l’équipement Auxiliary.
Central, déploiement et ZTNA : fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log et fwcm-frpcd.log couvrent les informations de zone et d’interface envoyées à Central, la connexion, la configuration transmise et Fast Reverse Proxy. ssod.log contient des informations sur le firmware et les sauvegardes Central, zt.log et zerotouch.log les variantes Zero Touch, ztna-connector.log le connecteur ZTNA local.
Sauvegarde, firmware, Air Gap et certificats : interfacemapping.log journalise l’affectation des interfaces lors d’une restauration, legacyconversion.log les sauvegardes sans Secure Storage Master Key et fwmgmt.log l’installation et la gestion du firmware. u2d_airgap.log concerne les mises à jour Air Gap, cps_messages.log les erreurs de hotfix et letsencrypt.log avec applog.log les certificats Let’s Encrypt.
Matériel et état du système : npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log et xgs-pport-wait.log couvrent le démarrage, la communication, le firmware, le port série, l’état de santé du NPU et la création des interfaces physiques. raid.log montre le RAID logiciel, lcd.log l’afficheur matériel. system-monitor/cpu_trigger.log capture l’état du système en cas de forte charge CPU ; system-monitor/memory_trigger.log s’applique à SFOS 22 en cas de forte charge mémoire.
Services cloud et plateformes : iaasd.log journalise le provisionnement et la vérification des licences dans Azure, waagent.log l’agent Azure et son Health Monitoring ; vmtool.log concerne 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

Noter précisément le problème : heure avec fuseau horaire, client, cible, port, utilisateur, action.
Décider s’il s’agit de trafic, d’état de service, de changement de configuration ou de synchronisation Central.
Filtrer le Log Viewer par IP source, IP de destination, module et heure.
Vérifier la visibilité de Firewall Rule ID, NAT Rule ID, utilisateur, gateway et Policy IDs.
Utiliser Packet Capture si le flux de paquets, le retour ou la vue NAT sont incertains.
Vérifier le fichier journal approprié avec tail -f, less ou grep.
Reproduire le problème et documenter l’heure exacte du test.
Si nécessaire, activer le debug uniquement pour le service concerné et seulement brièvement.
Désactiver à nouveau le debug et vérifier l’espace disque.
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

Quel fichier journal est le plus important sur Sophos Firewall ?

Cela dépend du problème. Pour les règles de pare-feu, firewall_rule.log est important, pour NAT nat_rule.log, pour IPsec strongswan.log, pour SSL VPN sslvpn.log, pour IPS et Application Control souvent ips.log. Le Log Viewer reste néanmoins le meilleur point de départ pour les connexions individuelles.

Qu'est-ce que CTR dans les logs Sophos Firewall ?

CTR signifie dans de nombreux contextes Sophos Consolidated Troubleshooting Report. Pour les administrateurs, l’essentiel est qu’un paquet CTR ou de journaux de dépannage aide le support, mais ne remplace pas une description propre de l’erreur avec heure, IP concernées, utilisateur, nom de tunnel, Rule ID et étapes de reproduction.

Quand a-t-on besoin de l'Advanced Shell ?

L’Advanced Shell est utile lorsque des fichiers journaux locaux doivent être vérifiés avec tail, grep ou less, qu’un statut de service est contrôlé ou que le support Sophos a besoin de données de journal détaillées. Pour de nombreuses premières vérifications, le Log Viewer, le Policy Test et Packet Capture dans WebAdmin suffisent.

Faut-il laisser le débogage activé en permanence ?

Non. Le débogage génère beaucoup de données et peut consommer de l’espace de stockage. Le débogage doit être utilisé uniquement pour le service concerné, pour un test reproductible court et avec désactivation ultérieure.

Pourquoi ne voit-on pas les événements de pare-feu attendus dans le Log Viewer ?

Souvent, Log firewall traffic n’est pas activé dans la règle concernée, la période ou le filtre choisi est incorrect, ou le trafic n’atteint pas le pare-feu. Si le flux de paquets est incertain, il faut utiliser conjointement le Log Viewer et Packet Capture.

Les journaux locaux sont-ils meilleurs que le reporting centralisé ou Syslog ?

Ce sont des outils différents. Les journaux locaux aident à l’analyse détaillée directement sur le pare-feu. Le reporting centralisé est adapté pour les rapports et l’historique Sophos Fusion. Syslog est meilleur pour un SIEM, SOC ou une conservation à long terme.