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.

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

Après le test, désactiver l’accès d’urgence et vérifier à nouveau l’état :

system appliance_access disable
system appliance_access show

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.

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.

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é

SFOS 22 active le mode debug dans Device Console, et non dans WebAdmin. Pour un test contrôlé avec l’exemple Pktcapd documenté par Sophos, noter l’espace disque disponible et l’heure du test, puis exécuter :

system diagnostics subsystems Pktcapd debug on

Reproduire le problème une fois, puis télécharger le fichier de logs ou un Consolidated Troubleshooting Report (CTR) sous Diagnostics > Tools > Troubleshooting logs. Le debug augmente la taille des logs et reste actif jusqu’à sa désactivation. Exécuter donc le retour documenté immédiatement après le téléchargement :

system diagnostics subsystems Pktcapd debug off

Consigner les deux commandes et leur sortie CLI. Si une commande est refusée, ne pas improviser une commande de sous-système ou de service : vérifier la syntaxe avec ? et contacter Sophos Support. Le debug dans Advanced Shell est volontairement omis, car la syntaxe générique des services n’offre pas de commande d’arrêt universelle pour chaque mode.

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, télécharger les logs ou un CTR sous Diagnostics > Tools > Troubleshooting logs, puis les transmettre via le portail de support convenu. Suivre 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 le debug actif après le test : Les logs augmentent inutilement et peuvent saturer le disque. Désactiver le debug immédiatement après l’analyse.
• 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 debug, les fichiers temporaires ou des accès trop larges restent actifs. Désactiver le debug, contrôler les fichiers temporaires et supprimer les accès SSH provisoires.

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.
• Le debug a été activé brièvement sous Diagnostics > Tools > Troubleshooting logs, puis désactivé et l’état normal a été vérifié.
• 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