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

Quel outil de dépannage est approprié ?

Tous les problèmes de pare-feu ne commencent pas par une 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.
• 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 Central en attente ? Vérifier la file d’attente des tâches de gestion du pare-feu Sophos Central.
• Rapports ou historique nécessaires dans Sophos Central ? 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.
• Traffic flows, 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
• Support Case à 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 down ou instable : vérifier le statut VPN, l’IP du peer, 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.
• Webfilter, TLS Inspection ou IPS bloque de manière inattendue : vérifier le module Log Viewer et la Policy ID. Ensuite comparer ips.log, webproxy.log, awarrenhttp.log et Packet Capture.
• Une tâche Sophos Central 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 node : déterminer le node actif, le node auxiliaire et le chemin de trafic concerné. Ensuite se connecter directement au node 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 le matching de règle, 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.

Les journaux de dépannage se trouvent sur le pare-feu dans le répertoire /log. On y accède via la console WebAdmin ou par SSH. Pour des vérifications rapides, Device Management > Advanced Shell fonctionne dans le navigateur, mais en pratique, SSH est généralement plus confortable, plus stable et mieux adapté pour des sessions tail, grep ou less plus longues. Comment préparer SSH en toute sécurité est expliqué dans le guide 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 via SSH ou ouvrir Device Management > Advanced Shell dans la console WebAdmin.
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.
• Piloter un service ou activer le debug : service <service>:<start/restart/stop/debug> -ds nosync, par exemple service ips:debug -ds nosync.

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 de logs ne doivent pas être construites manuellement avec tar dans l’Advanced Shell. Pour les cas de support, WebAdmin propose aussi Diagnostics > Tools > Log file details ou la sélection de troubleshooting logs. Les fichiers de logs peuvent y être sélectionnés par module et téléchargés.

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 admin ne veut pas ouvrir une longue session shell ou lorsqu’un paquet de logs clairement limité suffit. Le CTR est préférable lorsque Sophos Support a besoin d’un snapshot système large. Lors de la création d’un CTR, indiquer une raison courte et claire, par exemple le numéro de ticket, la période ou le symptôme. Le rapport est téléchargé chiffré et contient, pour les logs de sous-systèmes de service, généralement seulement un nombre limité de lignes. Les fichiers de logs individuels complets sont obtenus plus fiablement via Troubleshooting logs ou directement depuis /log.

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 noeud contient les logs du trafic et des services qu’il a lui-même traités. Pour les erreurs propres à un noeud, il faut donc vérifier le noeud concerné.

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 fichiers journaux, tail, grep, less, service -S, redémarrages de service et commandes de débogage.

Toutes les commandes ne fonctionnent pas dans les deux zones. Si un article mentionne explicitement Device Console, la commande doit être exécutée là. S’il s’agit de /log, tail -f, grep, service -S ou de journalisation de débogage, c’est généralement l’Advanced Shell qui est concernée.

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 Central 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 Central, 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 est très utile, mais génère beaucoup de données et peut consommer de l’espace de stockage. Le débogage ne doit être activé que pour le service concerné. Ensuite, on reproduit le problème et on désactive à nouveau le débogage.

Exemple :

service ips:debug -ds nosync
service ips:debug -ds nosync off

La syntaxe exacte dépend du service. Si le service concerné n’est pas clair, le fichier journal normal approprié doit d’abord être vérifié.

Sophos distingue ici deux modes d’utilisation. Dans l’Advanced Shell, on utilise des commandes de service comme service ips:debug -ds nosync. Dans la Device Console, les commandes system diagnostics subsystems <subsystem> debug on et system diagnostics subsystems <subsystem> debug off existent en plus pour les sous-systèmes pris en charge. Ces variantes ne doivent pas être mélangées: d’abord clarifier la console utilisée, puis exécuter la commande correspondante.

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 live debug : 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.

Système, gestion et services de base

• Messages système : syslog.log ; vérifier aussi l’heure, les reboots 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 le login 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.
• Communication entre composants : garner.log ; vérifier aussi reporting, Central Reporting et traitement des logs.
• API : apiparser.log, app-feedback.log ; vérifier aussi 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, sig_update.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.
• Signature updates : updater de signatures, logs sig_upgrade.log, sig_update.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, sandstorm.log et sandstorm_debug.log peuvent aussi correspondre. 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 Proxy : log webproxy.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.

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 strongswan-<connection>.log.
• IPsec versions antérieures : service IPsec, log ipsec.log.
• IPsec Test Connection : test IPsec, log ipsec_Test_Connect.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.
• PPTP : VPN PPTP, log pptpvpn.log.
• Certificats VPN : VPN Certificate Services, logs vpncertificate.log, wc_remote.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.
• 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.

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 dhcp6.log.
• Service réseau : service networkd, log networkd.log.
• FQDN Hosts : service fqdnd, logs fqdnd.log, fqdndebug.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 mdev.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

• Static Routing : service zebra, log zebra.log.
• Application Based Routing : service appcached, log appcached.log.
• Redis App Cache : Redis, log redis.
• Multicast Routing : log mrouting.log.
• BGP : service bgpd, log bgpd.log.
• OSPF : service ospfd, log ospfd.log.
• RIP : service ripd, log ripd.log.
• PIM-SM : service pimd, log pimd.log.

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, le tableau 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 Central, 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.
• 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 Central, 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 Central n’arrive pas localement, il faut comparer la Sophos Central Firewall Management Task Queue avec les logs locaux. Un statut Central vert ne prouve pas à lui seul qu’une policy concrète 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.

Les journaux HA se trouvent sur l’appareil où ils ont été générés. Pour les journaux bruts de l’appareil auxiliaire, il faut se connecter directement à cet appareil, par exemple via son port admin par SSH. Pour des rapports consolidés, le reporting centralisé de Sophos Central est plus pratique.

Mail et anti-spam

• Antivirus : AV Service, log av.log.
• Antivirus Updates : Up2Date AV, log up2date_av.log.
• Anti-Spam : service sasi, log sasi.log.
• Sandbox : service sandboxd, logs sandboxd.log, sessiontbl.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, awarrenmta_debug.log.
• POP/IMAP Proxy : service warren, log warren.log.

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.
• Wi-Fi Authentication : service wifiauth, log wifiauth.log.
• Hotspot : services hostapd, hotspot, hotspotd ; logs hostapd.log, hotspot.log, hotspotd.log.
• RED : RED Service, log red.log.
• 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.
• SMB-Filesystem : services smbnetfs, snireport ; logs smbnetfs.log, snireport.log.

En cas de problèmes de licence, de zone de sécurité ou de modèle, 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 de modèle manuelles, Gérer la licence et les mises à jour de modèle en mode Air-Gap de Sophos Firewall est approprié.

Base de données et reporting

• Configuration database : Config DB, logs confdbstatus.log, crreportdb.log.
• Postgres : service postgres, log postgres.log.
• Signature database : service sigdb, log sigdb.log.
• Report database : Report DB, log reportdb.log.
• Migration database : Report Migration, logs sac-feedback.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 Central.

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