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é.

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 pour les fichiers, les logs, les processus et l’état des services. Les commandes typiques sont nslookup, cd /log, tail -f, grep, less, df -kh, service -S et conntrack.

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.

Le test DNS illustre particulièrement bien la différence. Les commandes ne sont pas interchangeables :

Device Console :

dnslookup host example.com

Advanced Shell :

nslookup example.com

Ce message n’est pas le résultat d’un test DNS. Si /bin/sh: dnslookup: not found s’affiche dans Advanced Shell, dnslookup n’y est pas disponible. Utiliser nslookup à la place ; sa sortie indique ensuite si la résolution DNS fonctionne.

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 :

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. Ouvrir ce répertoire et afficher son contenu pour obtenir une première vue d’ensemble.

cd /log
ls -lah

Commandes de base utiles :

• Suivre un log en direct : tail -f /log/strongswan.log. Utile pour les erreurs VPN reproductibles.
• Lire un fichier de logs : less /log/ips.log. Dans less, rechercher avec /terme-recherche.
• Rechercher des erreurs : grep -i "error" /log/ips.log. -i ignore la casse.
• Afficher les correspondances avec leur numéro de ligne : grep -n "192.0.2.10" /log/firewall_rule.log. Utile pour les fichiers longs.
• Afficher les dernières lignes : tail -n 100 /log/syslog.log. Cette commande fournit un aperçu rapide sans mode direct.

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.

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é.

Examiner les connexions et le flux de paquets dans Advanced Shell

Si Log Viewer et Device Console ne donnent toujours pas de réponse claire, quelques commandes Advanced Shell peuvent aider à analyser le flux de paquets.

Examiner les connexions

Avant d’utiliser les outils d’Advanced Shell, filtrer le flux sous Current activities > Live connections et Diagnostics > Connection list. Ces vues WebAdmin documentées affichent Rule ID, NAT ID, les interfaces, l’utilisateur, la passerelle et les adresses traduites sans modifier la session.

Dans Device Console, system diagnostics utilities connections est un outil de diagnostic des connexions officiellement documenté. Utiliser d’abord ? pour examiner les options disponibles et le format de sortie.

conntrack est un outil Advanced Shell plutôt destiné au support. Il affiche les connexions actives connues du chemin stateful du firewall. Sa disponibilité peut dépendre de la version du firmware.

conntrack -L | grep "192.0.2.10"

L’absence de résultat n’est qu’un indice : le moment du test, le sens du filtre ou FastPath peuvent affecter la visibilité. Comparer le résultat avec Log Viewer et Packet Capture. Si la connexion apparaît mais que l’application échoue toujours, vérifier aussi l’arrivée des paquets de réponse ainsi que le comportement du NAT, de la stratégie et de l’application.

tcpdump dans Advanced Shell

Advanced Shell permet également d’exécuter tcpdump pour des contrôles rapides en direct.

tcpdump -i any -nn host 192.0.2.10

En production, le filtre doit rester aussi précis que possible. Une capture large telle que tcpdump -i any sans hôte, port ni limite de paquets génère rapidement un volume important de données et devient peu pratique sur un firewall chargé.

Un bon point de départ est une capture courte, limitée par l’hôte, le port et le nombre de paquets :

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Si davantage de données sont nécessaires, vérifier d’abord l’espace disque et choisir volontairement l’emplacement du fichier PCAP.

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

Les outils Advanced Shell suivants fournissent des informations complémentaires ; leur disponibilité peut dépendre de la version du firmware :

df -kh
df -h /var

Autres contrôles rapides :

uptime
top
service -S
service -S | grep strongswan

service -S affiche l’état de nombreux services. Les noms des services ne sont pas toujours explicites ; comparer le service au fichier de logs correspondant avant de le redémarrer ou d’activer le débogage.

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é.

Activer le débogage de manière contrôlée

Le débogage peut aider à résoudre des problèmes complexes, mais il ne doit être activé que brièvement et pour le service concerné. Les données de débogage augmentent rapidement et peuvent consommer beaucoup d’espace disque.

Pour une procédure on/off explicite, utiliser un sous-système pris en charge dans Device Console. Exécuter d’abord system diagnostics subsystems ? pour afficher les noms disponibles. Sophos documente l’exemple suivant pour Pktcapd :

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Sophos documente également cette commande de débogage IPS pour Advanced Shell :

service ips:debug -ds nosync

Aucune commande Advanced Shell distincte avec off ajouté n’est documentée pour cette variante. Ne l’utiliser que si le support Sophos a confirmé la procédure exacte de retour pour le build installé.

L’image montre comment, sous SFOS 20.0.1, la même commande active puis désactive le mode debug IPS et comment service -S | grep ips confirme l’état avant et après le test. Ne pas supposer que ce fonctionnement est identique sur les versions actuelles sans vérification.

Pour le redémarrage et l’identification des services, consulter aussi Redémarrer les services Sophos Firewall. Pour un cas de support, consigner la plage horaire exacte du débogage.

Avant de redémarrer un service, déterminer quelle fonction il affecte et si le trafic de production en dépend actuellement. Le redémarrage des services VPN, IPS, web ou d’authentification peut interrompre des sessions actives ou les connexions des utilisateurs.

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.

Ne pas placer d’identifiants FTP dans les commandes shell. Transférer les logs par une méthode sûre et traçable, par exemple avec scp vers un serveur interne ou via un portail de support. 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 a été utilisé dans Device Console ou nslookup dans Advanced Shell, ainsi que ping, traceroute, drop-packet-capture ou tcpdump selon les besoins.
• Le debug n’a été activé que brièvement et a été désactivé avec la commande de désactivation documentée pour le sous-système choisi.
• 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