Dépannage CLI de Sophos Firewall : commandes essentielles

Pour une première analyse sur Sophos Firewall, Log Viewer suffit souvent. La CLI devient importante lorsqu’un service ne démarre pas correctement, que les connexions VPN sont instables, que certains paquets n’arrivent pas ou que le support a besoin de données plus détaillées.

Cette vue d’ensemble présente les commandes les plus utiles au quotidien : où les exécuter, ce qu’elles indiquent et quand passer à un article spécialisé. Avant d’utiliser SSH, consulter Se connecter à Sophos Firewall par SSH. Une clé publique, la vérification de la clé d’hôte et une autorisation Device Access strictement limitée sont plus importantes qu’une connexion rapide depuis n’importe où.

⚠️ Important : Les commandes CLI et Advanced Shell ne doivent être exécutées que depuis des réseaux d’administration fiables et avec un objectif précis. Le débogage, tcpdump, les opérations sur les fichiers et les commandes de service peuvent affecter l’espace disque, les performances ou les connexions actives.

Commencer dans WebAdmin, puis utiliser la CLI

La CLI n’est pas toujours le moyen le plus rapide de commencer. Pour le matching des règles, le NAT ou des connexions individuelles, Log Viewer, Policy Test et Packet Capture dans WebAdmin fournissent souvent un résultat clair plus rapidement.

Points de départ utiles :

• Quelle règle de firewall correspond au trafic ? Commencer par Log Viewer, Policy Test et Packet Capture. Utiliser la CLI uniquement lorsque Log Viewer ne fournit pas assez de détails ou que des logs en direct sont nécessaires.
• Les paquets arrivent-ils sur le firewall ? Commencer par Packet Capture dans WebAdmin. La CLI est utile lorsque le support a besoin d’une capture étroitement filtrée ou d’un fichier PCAP.
• Un service rencontre-t-il un problème ? Vérifier d’abord le tableau de bord, Log Viewer et les logs du service. Utiliser la CLI pour contrôler directement l’état du service, les données de débogage ou les fichiers de logs.
• Une modification a-t-elle été effectuée ? Vérifier d’abord les logs Audit Trail. La CLI peut ensuite aider à rapprocher une différence de configuration des logs ou des sauvegardes.

L’objectif n’est pas d’ouvrir Advanced Shell le plus vite possible. Il faut suivre une procédure traçable : examiner d’abord les événements visibles, puis ouvrir le fichier de logs concerné ou lancer la capture appropriée.

Documenter les résultats CLI de manière exploitable

Une sortie CLI n’est utile que si elle peut ensuite être associée à un test précis. Un message d’erreur copié sans plage horaire, sans adresses IP ni fonction concernée entraîne généralement des questions supplémentaires et une double analyse.

Une courte note par test suffit généralement :

• Plage horaire : Début, fin et fuseau horaire du test.
• Flux testé : Adresse IP source, adresse IP de destination ou FQDN, port, utilisateur ou pair VPN.
• Outil : Device Console, Advanced Shell, Log Viewer ou Packet Capture.
• Commande ou filtre : Commande exécutée, terme de recherche grep ou filtre de capture utilisé.
• Résultat : Correspondance, message d’erreur, entrée de log absente, paquet visible ou non visible.
• Conclusion suivante : Par exemple, problème de règle, de DNS, de chemin retour, de service ou cas de support.

Avant de transmettre une sortie au support, à Avanet ou à un partenaire externe, vérifier si elle contient des données sensibles : adresses IP publiques, noms d’hôtes internes, noms d’utilisateur, paramètres VPN, numéros de série, jetons, adresses e-mail ou identifiants de clients. Une analyse technique ne nécessite pas une diffusion large des données ; transmettre uniquement le plus petit extrait qui démontre le constat.

Avant la première commande

Le dépannage en CLI est beaucoup plus fiable lorsque le contexte est défini avant la première commande. Sinon, on obtient rapidement des extraits de logs sans repère temporel, des captures trop larges ou des données de débogage qu’il devient impossible d’associer clairement à un test.

Avant d’exécuter des tests CLI en production, consigner :

• Heure du problème : Les logs peuvent ainsi être recherchés dans la plage correspondante.
• Adresse IP source, destination et port : grep, tcpdump et Packet Capture restent ciblés et lisibles.
• Utilisateur ou pair concerné : L’authentification, le VPN et le User Matching peuvent être corrélés plus facilement.
• Module attendu : Commencer par le fichier de logs adapté au lieu de parcourir tous les logs.
• Action prévue : Le débogage, le contrôle d’un service ou une capture ne doivent pas rester actifs par erreur.
• Condition de retour ou d’arrêt : Arrêter le test en cas de charge, de saturation du disque ou d’effets indésirables.
• Sauvegarde récente en cas de modification : Les redémarrages de services et les changements de configuration sont plus sûrs avec un point de restauration récent.

La première étape doit être en lecture seule autant que possible : examiner Log Viewer, ouvrir le fichier de logs concerné, consulter service -S ou lancer une capture étroitement filtrée. Les redémarrages, le mode debug et les captures larges doivent être réservés à une fenêtre de test planifiée.

Dans un cluster HA, il faut aussi déterminer quelle appliance est actuellement active. Les logs, le débogage et les captures doivent être contrôlés sur le nœud qui traite réellement le trafic concerné.

Exécuter un redémarrage complet uniquement comme action planifiée

Un redémarrage complet n’est pas une commande de diagnostic. Il faut d’abord conserver les logs pertinents, l’heure système, l’uptime, les rôles HA et l’état actuel du problème. Si seul WebAdmin ou un service est affecté, il faut vérifier si un redémarrage ciblé de WebAdmin ou un redémarrage de service suffit.

SFOS 22 documente la syntaxe suivante dans Device Console :

system restart [all]

Les crochets ne font pas partie de la commande, ils indiquent l’argument facultatif all. Il faut d’abord contrôler la forme proposée par le build installé avec system restart ?. La commande redémarre le firewall et interrompt les sessions, les tunnels VPN et l’accès d’administration. Aucun rollback CLI n’est possible après l’exécution ; la fenêtre de maintenance, l’accès console et un chemin de retour d’administration testé doivent donc être prêts avant la confirmation.

Selon Sophos, system restart déclenche un failover dans un cluster HA. Cela ne garantit pas des connexions sans interruption. Le peer, la synchronisation, les rôles et le lien HA doivent d’abord être stables. Après le redémarrage, il faut vérifier les deux nœuds, les rôles, la synchronisation, l’uptime, le WAN, le routage, le DNS, le VPN, les services publiés et un flux applicatif réel. Un démarrage réussi ne prouve pas que la cause initiale est résolue.

Arrêter uniquement avec un chemin de remise sous tension préparé

Un arrêt contrôlé utilise exactement cette commande dans Device Console :

system shutdown

Sophos ne documente aucune option pour cette commande. Il ne faut donc pas ajouter all, un nom de nœud ou un commutateur HA supposé à la syntaxe. Avant de confirmer, il faut conserver les logs et la configuration, informer les équipes dépendantes et déterminer comment l’appliance sera remise sous tension via un accès physique, l’administration distante ou la plateforme de virtualisation. La page shutdown ne garantit aucun comportement HA ; un nœud du cluster ne doit donc être arrêté que selon la procédure de maintenance HA prévue, puis le peer doit être contrôlé explicitement.

Device Console ou Advanced Shell ?

Sophos Firewall propose deux environnements de console distincts. De nombreuses erreurs viennent simplement de l’exécution d’une commande dans le mauvais environnement.

Ils ont des rôles différents :

• Device Console : CLI Sophos pour les commandes réseau, système et de diagnostic. Les commandes typiques sont ping, dnslookup, traceroute, tcpdump, drop-packet-capture et show.
• Advanced Shell : shell proche de Linux donnant un accès complet aux composants système. Cet article le limite aux commandes de diagnostic documentées par Sophos : cd /log, tail, grep, less et service -S.

Après une connexion SSH, le firewall affiche d’abord le menu de la console. Sélectionner 4. Device Console pour la Device Console. Ouvrir Advanced Shell via 5. Device Management > 3. Advanced Shell.

La Device Console regroupe sous advanced-firewall les paramètres globaux d’inspection des paquets, TCP, UDP, d’accès WAN et de chemins spéciaux. Leurs effets et une procédure de modification sûre sont expliqués dans Contrôler les Advanced Firewall Settings en toute sécurité.

Le test DNS montre bien pourquoi l’environnement de console est important. Dans Device Console, la commande officiellement documentée est :

dnslookup host example.com

example.com est une valeur de documentation sûre ; pour un test réel, la remplacer par le FQDN concerné. La réponse confirme uniquement la résolution depuis le firewall. Pour une panne côté client, vérifier aussi son serveur DNS, la réponse et le chemin réseau.

L’aide officielle de la CLI Sophos prend en charge Tab et ? pour vérifier la syntaxe. Cette fonction est utile dans Device Console, car la structure varie selon la commande.

Ne pas tenter une commande incomplète dans Device Console. Sophos avertit qu’une commande incomplète peut bloquer access_server. Utiliser Tab ou ? pour afficher la syntaxe avant d’exécuter volontairement la commande complète.

Les modifications de configuration effectuées directement dans Advanced Shell ne sont pas persistantes et ne sont pas incluses dans les sauvegardes. Ce guide utilise donc Advanced Shell uniquement pour les commandes de diagnostic.

Avant l’accès d’urgence : Faire approuver explicitement l’objectif, la personne responsable, l’appliance concernée et une courte fenêtre d’urgence avec une heure de fin et un critère d’arrêt ; prévoir l’interruption du transfert vers Internet. Ouvrir réellement au préalable un chemin de récupération indépendant et vérifier l’accès administrateur, par exemple via une console locale, la console de la plateforme de virtualisation ou une administration hors bande. Cet accès ne doit dépendre ni du chemin réseau défaillant ni du mode d’urgence et doit rester disponible pour désactiver ce mode. Ne pas activer sans approbation ou sans chemin de récupération indépendant fonctionnel ; convenir d’abord de la récupération avec la personne responsable ou Sophos Support.

system appliance_access enable est une commande d’urgence particulière. Elle remplace les paramètres Device Access et autorise l’accès à tous les services locaux du firewall, y compris aux services anciens tels que Telnet. Important : tant que ce mode est actif, le firewall cesse de transférer le trafic sortant vers Internet. Il ne s’agit pas d’une étape de dépannage normale ; elle ne doit être utilisée que brièvement en cas d’urgence. Vérifier l’état avant de l’activer :

Le default documenté est Disable. Avec enable, tous les ports acceptent les connexions entrantes et la restriction normale d’accessibilité de Device Access disparaît temporairement. L’authentification propre à chaque service reste un contrôle séparé, mais ne rend pas cette large exposition inoffensive.

system appliance_access show

Dès que l’accès administrateur complet prévu est rétabli, désactiver immédiatement le mode d’urgence dans 4. Device Console et vérifier à nouveau l’état ; ne pas attendre la fin d’autres diagnostics. Le désactiver également via le chemin de récupération indépendant préparé en cas d’abandon ou lorsque l’heure de fin approuvée est atteinte :

system appliance_access disable
system appliance_access show

Ensuite, show doit confirmer Disable. Tester également une nouvelle connexion WebAdmin ou SSH depuis le réseau d’administration prévu, sous les règles Device Access normales, et vérifier que les accès précédemment bloqués le restent. Depuis un client concerné situé derrière le firewall, tester une connexion sortante réelle vers Internet, par exemple une requête HTTPS vers une destination approuvée, et vérifier une réponse réussie ; un ping depuis le firewall ou show seul ne prouve pas le rétablissement du transfert. Si les contrôles échouent ou si l’état reste incertain, ne pas clôturer le cas comme résolu : garder ouvert le chemin de récupération indépendant, conserver la réponse CLI et les résultats du test, puis se coordonner avec la personne responsable ou Sophos Support plutôt que de réactiver l’accès d’urgence étendu comme solution permanente.

Si une commande n’est pas reconnue, vérifier d’abord l’environnement de console. Une erreur d’environnement est plus probable qu’une commande défectueuse.

Examiner les logs dans Advanced Shell

Les principaux fichiers de logs se trouvent sous /log. Sophos documente d’abord le passage dans ce répertoire dans Advanced Shell :

cd /log

Commandes de base utiles :

• Suivre un log en direct : tail -f ips.log. Ne conserver la sortie continue que pendant la fenêtre de test documentée.
• Lire un fichier de logs : less ips.log. Les lignes sont alors affichées par sections.
• Rechercher un terme : grep error ips.log. Adapter le terme et le fichier à la panne.

Dépannage de Sophos Firewall : services et logs associe les modules aux fichiers de logs correspondants.

Limiter la durée d’un suivi en direct et noter l’heure. Cette précaution est particulièrement importante lorsqu’une archive doit ensuite être transmise au support Sophos ou à Avanet.

Utiliser Device Console pour des contrôles réseau rapides

Device Console convient aux tests rapides effectués du point de vue du firewall. Elle permet de confirmer le fonctionnement du DNS, du routage ou de la connectivité de base.

Contrôles rapides :

• Joindre un hôte : ping 192.0.2.10 count 4 teste la connectivité ICMP.
• Contrôler le DNS dans Device Console : dnslookup host example.com teste la résolution de noms depuis le firewall.
• Contrôler la route : traceroute 192.0.2.10 affiche le chemin vers la destination.
• Examiner l’état des interfaces : show interfaces affiche les informations sur les interfaces.
• Lancer une capture des paquets rejetés : drop-packet-capture 'host 192.0.2.10' affiche les paquets rejetés par les règles de firewall.
• Lancer une capture de paquets : tcpdump 'host 192.0.2.10 and port 443' vérifie si les paquets sont visibles sur le firewall.

Les commandes IPv6 correspondantes sont ping6, dnslookup6 et traceroute6.

tcpdump et drop-packet-capture continuent jusqu’à leur arrêt avec Ctrl+C. Définir d’abord le filtre et la fenêtre de test, surveiller la sortie, puis arrêter immédiatement la capture. Ces commandes ne modifient pas la configuration, mais leur charge dépend du volume de trafic, de l’étendue du filtre et de la durée d’exécution.

drop-packet-capture est particulièrement utile lorsqu’il est difficile de savoir si le firewall rejette activement les paquets. Cette commande ne remplace pas l’analyse au niveau applicatif. Si un serveur répond mais que l’application échoue toujours, contrôler aussi Log Viewer, le NAT, Packet Capture et les logs de l’application.

Pour les captures plus longues et les fichiers PCAP, consulter Sophos Firewall : collecter des logs avec tcpdump pour l’analyse. Cet article explique également comment limiter la taille du fichier, choisir un emplacement de stockage et transférer la capture en sécurité.

Contrôles réseau dans WebAdmin sans CLI

Les mêmes questions de base peuvent être testées sans accès à la console sous Diagnostics > Tools. Ping permet de sélectionner IPv4 ou IPv6, l’interface de sortie et la taille du paquet. Sophos utilise 32 octets par défaut et autorise des valeurs de 1 à 65 507 octets. Un ping réussi confirme l’accessibilité ICMP depuis l’interface choisie du pare-feu, mais pas le fonctionnement d’un service applicatif.

Pour Ping dans SFOS 22 et SFOS 23, IP address or hostname peut contenir une adresse IPv4, une adresse IPv6 ou un FQDN. IP family définit la famille d’adresses, Interface l’interface de sortie et Size la taille du paquet. Un FQDN nécessite également une résolution de noms ; pour cerner un problème DNS, comparer aussi le même test effectué avec l’adresse IP attendue.

La sortie de Ping indique si des réponses arrivent, le nombre de paquets envoyés et reçus, la perte de paquets et le temps aller-retour (RTT). Le RTT correspond au temps nécessaire à la requête et à la réponse, et non au temps de trajet dans un seul sens. Si aucune réponse n’arrive, une perte de paquets de 100 pour cent est affichée. Cela ne prouve pas à lui seul que l’hôte est éteint : vérifier l’adresse de destination, l’interface sélectionnée, le routage et si ICMP est autorisé, puis utiliser au besoin un Packet Capture étroitement filtré. Même réussi, le test doit toujours correspondre au flux applicatif réel.

Traceroute accepte également IPv4, IPv6 ou un FQDN ainsi qu’une interface de sortie choisie consciemment. L’absence de réponse de certains sauts ne prouve pas une interruption si des sauts ultérieurs ou la destination répondent. Pour analyser un chemin, il faut donc considérer ensemble l’accessibilité de la destination, le dernier saut qui répond et le flux de paquets mesuré en parallèle.

Dans WebAdmin, sous Diagnostics > Tools > Traceroute, définir la destination dans IP address or hostname, la famille d’adresses dans IP version et l’interface de sortie dans Interface ; lancer la requête avec Traceroute. Pour SFOS 22 et SFOS 23, Sophos décrit la sortie comme indiquant les routeurs traversés, le nombre maximal de sauts et le temps total de retour du paquet en millisecondes. Le nombre maximal de sauts limite la recherche du chemin ; il ne prouve pas que la destination a été atteinte. Les valeurs de temps décrivent les réponses de diagnostic et ne prouvent aucun débit applicatif. Dans 4. Device Console, traceroute6 2001:db8::10 complète l’exemple IPv4 ci-dessus ; remplacer l’adresse de documentation par l’adresse IPv6 de destination réelle.

Les libellés Name lookup et Lookup using all configured servers ci-dessous s’appliquent à SFOS 22. Les libellés modifiés de SFOS 23, DNS lookup et All configured servers, ainsi que les options de serveur supplémentaires et leurs prérequis sont expliqués dans Comparer les résolveurs individuellement sous Diagnostics.

Name lookup interroge un serveur DNS sélectionné. Lookup using all configured servers compare tous les serveurs DNS configurés sur le pare-feu et leur temps de réponse. Un résultat rapide isolé ne justifie pas encore de modifier la priorité DNS ; le contenu de la réponse, la fiabilité et le chemin du client concerné doivent aussi être corrects.

Route lookup indique par quelle interface le pare-feu acheminerait une destination IPv4 ou IPv6. Il ne prouve ni la règle de pare-feu, ni le NAT, ni la décision SD-WAN, ni un chemin de retour fonctionnel. La validation se poursuit donc avec une connexion réelle, Connection List ou Packet Capture.

Contrôler les connexions sans modifier leur état

Filtrer les connexions IPv4 et IPv6 actuelles sous Current activities > Live connections et Diagnostics > Connection list. Connection list affiche notamment les interfaces d’entrée et de sortie, la source et la destination, Rule ID, NAT ID, les adresses traduites, l’état et les compteurs Rx/Tx. C’est un meilleur premier choix qu’un outil Advanced Shell non documenté.

Dans Device Console, cet outil de connexion est également documenté :

system diagnostics utilities connections

Contrôler les arguments disponibles avant l’appel avec system diagnostics utilities connections ?. Connection list étant un instantané, reproduire le flux de test tout en actualisant la vue. Si la connexion reste absente, lancer un Packet Capture précis ; si elle apparaît, poursuivre avec Rule ID, NAT ID, interfaces, traduction et compteurs de réponse.

Contrôler l’espace disque et l’état du système

Avant d’activer le débogage, de créer de grandes archives de logs ou d’exécuter des captures plus longues, vérifier l’espace disque disponible.

Device Console propose les contrôles système officiels suivants en lecture seule :

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

system diagnostics show version-info affiche aussi le numéro de série et le Device ID. Masquer ces identifiants avant de partager une sortie ou une capture d’écran.

Les autres cibles en lecture seule sont interrupts, syslog, sysmsg, subsystem-info et ctr-log-lines. Elles répondent à des questions différentes et ne doivent pas être considérées comme des valeurs de santé interchangeables :

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

Sur les XGS Appliances, system diagnostics selftest est également disponible pour des tests de base de la carte réseau. La commande ne s’applique pas aux autres plateformes et ne remplace ni un test de câble, ni une mesure de débit, ni une capture de paquets. Comme Sophos ne précise pas l’impact sur le trafic de production dans la page de la commande, ce test est exécuté uniquement de manière planifiée ou sur instruction du support, puis comparé à l’état du lien, aux compteurs d’interface et au trafic réel.

Sous system diagnostics utilities, SFOS regroupe d’autres outils pour ARP, la bande passante, les connexions, DNS, la capture des paquets rejetés, la configuration réseau, ping, les processus, les routes et traceroute, avec les variantes IPv6 lorsque Sophos les propose. La syntaxe exacte est vérifiée sur la version installée avec la complétion par Tab. Certains outils lisent uniquement l’état, tandis que d’autres génèrent du trafic de test ou lancent une sortie continue.

Pour un contrôle complémentaire en lecture seule, Sophos documente dans Advanced Shell :

service -S
service -S | grep ips

La première variante affiche de nombreux états de service ; la seconde utilise l’exemple IPS documenté par Sophos. Une absence de résultat ne justifie pas un redémarrage : comparer d’abord le nom du service et son fichier de logs avec la liste Sophos actuelle.

Si l’espace disque est déjà faible, ne pas activer le débogage ni lancer une capture longue. Déterminer d’abord quels logs ou rapports peuvent être sauvegardés puis nettoyés en sécurité.

Collecter les logs de debug uniquement avec un retour confirmé

Pour SFOS 22 et SFOS 23, l’activation et la désactivation du débogage des sous-systèmes de service présenté ici sont documentées dans Device Console, et non dans WebAdmin. Pktcapd est l’exemple documenté, pas un commutateur général pour tous les services. Consigner au préalable le build installé, le nœud HA concerné, l’espace disque disponible, la plage horaire du test et la procédure de désactivation appropriée ; vérifier la syntaxe et le sous-système disponible avec ? ou Tab. Le débogage augmente la taille des fichiers de logs et reste actif jusqu’à sa désactivation. Ne l’activer que pour une courte fenêtre d’analyse convenue :

Avant debug on : Déterminer et documenter l’état de débogage existant pour ce sous-système précis sur ce nœud HA précis, à l’aide d’une méthode en lecture seule prise en charge par le build installé ou avec Sophos Support. Clarifier également qui est responsable d’un diagnostic existant et si une collecte est en cours. system diagnostics show subsystem-info n’est qu’une vérification système complémentaire ; la syntaxe documentée ne garantit ni un champ d’état de débogage uniforme ni une preuve fiable que le débogage est désactivé.

S’arrêter si le débogage est actif ou si l’état initial n’est pas clairement établi ou si la responsabilité n’est pas claire : Ne pas exécuter cette procédure d’activation/désactivation et, en particulier, ne pas utiliser préventivement debug off pour établir un état initial. Convenir d’abord de l’objectif, de la responsabilité et de la procédure de retour avec le responsable du diagnostic ou Sophos Support ; ne poursuivre qu’une fois l’état initial inactif explicitement approuvé et confirmé. Une fenêtre de test convenue ne permet pas à elle seule de mettre fin à une autre collecte de diagnostic en cours. Ce n’est qu’alors qu’il faut activer le débogage pour cette procédure et consigner sa propre responsabilité pour l’activation et la désactivation :

system diagnostics subsystems Pktcapd debug on

Reproduire le problème une fois. Sélectionner les logs individuels sous Diagnostics > Tools > Troubleshooting logs, puis choisir Download pour les télécharger sous forme d’archive compressée. Pour un Consolidated troubleshooting report (CTR), sélectionner plutôt les options nécessaires System snapshot et All log files sous Diagnostics > Tools > Consolidated troubleshooting report, saisir le motif, puis choisir Generate et ensuite Download. Le CTR est téléchargé sous forme chiffrée ; System snapshot ne nécessite pas le mode debug. Pour certains logs du CTR, le paramètre CLI limite le nombre de lignes incluses : un CTR ne contient donc pas automatiquement tout l’historique des logs.

Immédiatement après le téléchargement, désactiver le mode de débogage dans 4. Device Console exclusivement pour les sous-systèmes de service dont cette procédure a nouvellement activé le débogage à partir de l’état initial inactif confirmé et dont elle reste responsable. Laisser inchangé l’état des autres diagnostics en cours. Pour l’exemple ainsi activé, la procédure de retour est exactement la suivante :

system diagnostics subsystems Pktcapd debug off

En cas d’interruption de la reproduction, d’échec du téléchargement, de charge élevée ou de manque d’espace de stockage, terminer le test et désactiver exclusivement le débogage nouvellement activé par cette procédure à partir de l’état initial inactif confirmé et dont on reste soi-même responsable, au lieu d’attendre un export réussi. Ne pas mettre fin aux collectes de diagnostic en cours relevant d’un autre responsable ; si la responsabilité n’est pas clairement établie, se coordonner avec le responsable du diagnostic ou Sophos Support, sans désactiver au hasard. La fermeture d’une session SSH ou le téléchargement de journaux ne remplace pas sa propre commande de désactivation. Les journaux et les rapports ne sont pas synchronisés entre les nœuds HA ; effectuer la collecte et le nettoyage sur le nœud sur lequel cette procédure a nouvellement activé le débogage.

Consigner les commandes d’activation et de désactivation, l’heure, le nœud et la réponse CLI complète. Après la commande de désactivation, vérifier si la CLI confirme la désactivation ou signale une erreur ; en complément, comparer le résultat du contrôle système en lecture seule system diagnostics show subsystem-info à l’état relevé avant le test. La syntaxe documentée ne garantit pas la présence d’un champ d’état du débogage uniforme sur tous les builds. En l’absence de confirmation claire, ne pas considérer le débogage comme désactivé : faire vérifier la sortie par le support Sophos. Si la commande est refusée, vérifier la syntaxe avec ? et ne pas poursuivre avec des commandes de sous-système, de redémarrage ou de service improvisées. En particulier, ne pas appliquer la syntaxe des sous-systèmes de service à CSC, dont la commande de débogage est documentée différemment. Le débogage dans Advanced Shell est volontairement omis ici, car la syntaxe générique des services ne fournit pas de commande de désactivation uniforme pour chaque mode de débogage.

Pour les redémarrages de services et leurs effets, consulter Redémarrer les services Sophos Firewall. Le redémarrage des services VPN, IPS, web ou d’authentification peut interrompre des sessions ou connexions actives.

Transmettre les logs en sécurité

Des extraits individuels ne suffisent souvent pas dans les cas complexes. Une archive complète est généralement plus utile pour le support Sophos, Avanet ou une analyse externe.

Au lieu d’inscrire des identifiants dans des commandes shell, collecter les fichiers dans WebAdmin : sélectionner les fichiers de logs individuels sous Diagnostics > Tools > Troubleshooting logs, puis choisir Download. Pour un CTR, utiliser plutôt Diagnostics > Tools > Consolidated troubleshooting report, sélectionner les options nécessaires System snapshot et All log files, saisir un motif, puis choisir Generate et Download. Avant toute transmission, vérifier que l’archive ou le rapport chiffré a effectivement été téléchargé, puis le transmettre uniquement via le portail de support convenu. Un échec de l’export ne justifie pas de laisser actif le débogage nouvellement activé par cette procédure à partir d’un état initial inactif confirmé et dont on reste soi-même responsable ; cela ne doit pas entraîner l’arrêt d’une autre collecte de diagnostic en cours. La procédure correspondante est décrite dans Collecter les logs Sophos Firewall pour le support et l’analyse.

Les fichiers de logs peuvent contenir des informations sensibles : adresses IP internes et publiques, noms d’hôtes, noms d’utilisateur, paramètres VPN et messages d’erreur. Avant leur transmission, définir qui recevra les données et combien de temps elles seront conservées.

Erreurs fréquentes lors du dépannage en CLI

• Exécuter une commande dans le mauvais environnement : Device Console et Advanced Shell utilisent une syntaxe différente. Vérifier d’abord l’environnement.
• Laisser son propre débogage actif après l’analyse : Les journaux grossissent inutilement et peuvent consommer de l’espace de stockage. Désactiver immédiatement uniquement le débogage nouvellement activé par cette procédure à partir d’un état initial inactif confirmé et dont on reste soi-même responsable ; ne pas mettre fin aux collectes de diagnostic relevant d’un autre responsable.
• Lancer un tcpdump large sans filtre : Cela génère trop de données, ajoute de la charge et complique l’analyse. Limiter l’hôte, le port, l’interface ou le nombre de paquets.
• Placer des identifiants FTP dans l’historique du shell : Ils peuvent apparaître dans les logs, les captures d’écran ou l’historique des commandes. Utiliser un transfert sécurisé et des identifiants temporaires.
• Ne contrôler qu’un fichier de logs : De nombreux problèmes impliquent plusieurs modules. Combiner Log Viewer, les logs de service concernés et Packet Capture.
• Ne pas consigner l’heure : Le support doit alors parcourir une plage de logs inutilement grande. Noter l’heure, l’action de test et les adresses IP concernées.
• Ne pas nettoyer après le test : Le débogage, les fichiers temporaires ou les accès étendus restent actifs. Désactiver uniquement le débogage nouvellement activé par cette procédure à partir d’un état initial inactif confirmé et dont on reste soi-même responsable, vérifier les fichiers et retirer les autorisations SSH temporaires ; ne pas mettre fin aux collectes de diagnostic relevant d’un autre responsable.

Liste de contrôle

• L’accès SSH est limité aux réseaux d’administration fiables.
• L’empreinte SSH et l’accès admin ont été vérifiés avant l’analyse.
• Le bon environnement a été sélectionné : Device Console ou Advanced Shell.
• L’heure du problème, l’adresse IP source, l’adresse IP de destination, le port et l’utilisateur ont été consignés.
• Les résultats CLI comprennent la plage horaire, la commande, le filtre et le résultat.
• Des commandes en lecture seule ont été utilisées avant d’activer le debug, de redémarrer des services ou de lancer des captures plus longues.
• Log Viewer a été contrôlé en premier.
• Le fichier concerné sous /log a été identifié.
• tail, grep ou less a été utilisé avec un terme de recherche précis.
• Pour les problèmes réseau, dnslookup, ping, traceroute, drop-packet-capture ou tcpdump a été utilisé de façon ciblée dans Device Console.
• Avant le débogage d’un sous-système de service dans SFOS 22/23, avoir clarifié l’état existant et identifié le responsable du diagnostic pour le sous-système et le nœud HA précis, puis confirmé et documenté un état initial inactif explicitement approuvé ; en cas d’état actif ou incertain, ne pas avoir exécuté la procédure d’activation/désactivation, mais s’être coordonné avec le responsable ou le support. Avoir nouvellement activé le débogage brièvement dans 4. Device Console uniquement à partir de cet état initial ; dans l’exemple, avec system diagnostics subsystems Pktcapd debug on, puis avoir désactivé avec system diagnostics subsystems Pktcapd debug off exclusivement le débogage nouvellement activé par cette procédure et dont on reste soi-même responsable. Avoir laissé inchangées les collectes de diagnostic relevant d’un autre responsable. Avoir vérifié la réponse à la désactivation et l’état système complémentaire ; avoir clarifié tout état incertain avec le support, sans le considérer comme désactivé.
• L’espace disque a été contrôlé avant le debug ou la collecte PCAP.
• L’archive de logs a été transférée en sécurité et les fichiers temporaires ont été supprimés.
• Les exceptions temporaires Device Access ou SSH ont été supprimées après le cas de support.

FAQ