Dépannage Sophos Firewall CLI : commandes importantes

Lors du dépannage du Sophos Firewall, le Log Viewer est souvent suffisant pour l’isolement initial. Dès qu’un service ne démarre pas correctement, que les connexions VPN sont instables, que les paquets individuels n’arrivent pas ou que le support a besoin de données détaillées, la CLI devient importante.

Cet aperçu montre les commandes les plus importantes de la vie quotidienne : où les exécuter, ce qu’elles affichent et quand il est préférable de passer à un article spécialisé. Pour un accès sécurisé via SSH, Connecter Sophos Firewall via SSH doit d’abord être coché. Les clés publiques, les vérifications des clés d’hôte et l’approbation stricte de l’accès aux appareils sont plus importantes qu’une connexion rapide depuis n’importe où.

⚠️ Important : Les commandes CLI et Advanced Shell ne doivent être exécutées qu’à partir de réseaux d’administrateurs de confiance et avec un objectif clair. En particulier, le débogage, tcpdump, les opérations sur les fichiers et les commandes de service peuvent affecter l’espace de stockage, les performances ou l’exécution des connexions.

D’abord WebAdmin, puis CLI

La CLI n’est pas toujours le moyen le plus rapide de démarrer. Lorsqu’il s’agit de correspondance de règles, NAT ou de connexions individuelles, Log Viewer, Policy Test et Packet Capture dans le WebAdmin fournissent souvent un résultat propre plus rapidement.

Bonnes présentations :

• Quelle règle de pare-feu s’applique ? Utilisez d’abord Log Viewer, Policy Test et Packet Capture. La CLI ne devient nécessaire que lorsque le Log Viewer affiche trop peu de détails ou que des journaux en direct sont requis.
• Les paquets arrivent-ils sur le pare-feu ? Utilisez d’abord Packet Capture dans WebAdmin. La CLI est utile lorsqu’une capture serrée ou un fichier PCAP est nécessaire pour la prise en charge.
• Un service a-t-il un problème ? Vérifiez d’abord le tableau de bord, Log Viewer et les journaux de service. La CLI devient importante lorsque l’état du service, les fichiers de débogage ou les fichiers journaux doivent être vérifiés directement.
• Quelque chose a-t-il changé ? Vérifiez d’abord Audit Trail Logs. La CLI aide ensuite à comparer une différence de configuration avec des journaux ou des sauvegardes.

Le but n’est pas de se lancer le plus rapidement possible dans le Advanced Shell. Il est préférable d’avoir un processus compréhensible : vérifiez d’abord les événements visibles, puis ouvrez le fichier journal approprié ou capturez.

Documenter les résultats de la CLI de manière utilisable

La sortie CLI n’est utile que s’il est clair ultérieurement à quel test elle appartient. Les messages d’erreur individuels copiés sans fenêtre de temps, les adresses IP ou la fonction concernée conduisent souvent à des requêtes et à une double analyse.

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

• Fenêtre horaire : Début, fin et fuseau horaire du test.
• Testflow : Source IP, Destination IP ou FQDN, Port, Utilisateur ou homologue 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 : Appel, message d’erreur, entrée de journal manquante, package visible ou package non visible.
• Conclusion suivante : par exemple un problème de règle, un problème DNS, un chemin de retour, une erreur de service ou un cas d’assistance.

Avant de partager avec le support, Avanet ou des partenaires externes, vérifiez si les sorties contiennent des données sensibles : adresses IP publiques, noms d’hôte internes, noms d’utilisateur, paramètres VPN, numéros de série, jetons, adresses e-mail ou identifiants client. Pour une analyse technique, il n’est pas nécessaire que les données soient distribuées arbitrairement et largement ; Ce qui est important, c’est la plus petite section qui prouve la découverte.

Avant la première commande

Le dépannage CLI devient beaucoup plus fiable si la trame est corrigée avant la première commande. Sinon, des extraits de journaux sans aucune référence temporelle, des captures trop larges ou des journaux de débogage apparaissent rapidement que personne ne peut clairement attribuer par la suite. Avant de tester la CLI productive, vous devez noter :

• Temps du problème : Les journaux peuvent être recherchés spécifiquement pour la fenêtre de test.
• Source IP, Destination IP et Port : grep, tcpdump et Packet Capture restent étroits et lisibles.
• Utilisateur ou homologue concerné : L’authentification, VPN et la correspondance d’utilisateur sont mieux attribuables.
• Module attendu : Vous recherchez d’abord dans le fichier journal approprié au lieu de tous les journaux.
• Action prévue : Le débogage, la vérification du service ou la capture ne deviendront pas accidentellement permanents.
• Critères de restauration ou de terminaison : Le test est terminé en cas de charge, de mémoire pleine ou d’effets secondaires.
• Sauvegarde actuelle pour les travaux de modification : Les redémarrages de service ou les modifications de configuration peuvent être sauvegardés plus proprement. La première étape doit être de lire si possible : vérifiez Log Viewer, affichez le fichier journal approprié, lisez service -S ou lancez une capture rapprochée. Les redémarrages, le mode débogage et les enregistrements étendus n’appartiennent qu’après coup à une fenêtre de test consciente.

Pour les clusters HA, il doit également être clair quelle appliance est actuellement active. Les journaux, le débogage et les captures doivent être vérifiés sur le nœud via lequel le trafic concerné s’exécute réellement.

Device Console ou Advanced Shell ?

Sophos Firewall comporte deux zones de console différentes. De nombreuses erreurs se produisent car une commande est saisie dans la mauvaise zone.

Les domaines ont différentes tâches :

• Device Console : Sophos CLI 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 de type Linux pour les fichiers, les journaux, les processus et les contrôles de service. Les commandes typiques sont cd /log, tail -f, grep, less, df -kh, service -S et conntrack.

Après vous être connecté via SSH, le pare-feu affiche d’abord le menu de la console. Pour le Device Console, vous choisissez généralement 4. Device Console. Pour le Advanced Shell, utilisez 5. Device Management > Advanced Shell.

L’aide officielle de Sophos CLI prend en charge Tab et ? pour la vérification de la syntaxe. Ceci est utile dans le Device Console car toutes les commandes ne sont pas structurées de la même manière.

Si une commande n’est pas reconnue, vérifiez d’abord la zone de la console. Une mauvaise plage est plus probable qu’une commande immédiatement interrompue.

Vérifiez les journaux dans le Advanced Shell

Les fichiers journaux les plus importants se trouvent sous /log. Pour une première orientation, accédez à ce répertoire et répertoriez les fichiers.

cd /log
ls -lah

• Journal de suivi en direct : tail -f /log/strongswan.log. Idéal pour les erreurs VPN reproductibles.
• Lire le fichier journal : less /log/ips.log. Dans less, vous pouvez effectuer une recherche avec /Suchbegriff.
• Vérifiez les erreurs : grep -i "error" /log/ips.log. -i n’est pas sensible à la casse.
• Appuyez avec le numéro de ligne : grep -n "192.0.2.10" /log/firewall_rule.log. Utile pour les fichiers plus longs.
• Afficher les dernières lignes : tail -n 100 /log/syslog.log. Aperçu rapide sans mode direct.

Quel fichier journal appartient à quel module est résumé dans Dépannage Sophos Firewall : Services et journaux.

Avec les journaux en direct, vous devez garder la période de test courte et noter l’heure. Ceci est particulièrement important si une archive de journaux est ultérieurement transmise au support Sophos ou à Avanet.

Device Console pour des vérifications rapides du réseau

Le Device Console convient aux tests rapides du point de vue du pare-feu. Cela vous permet de vérifier si le DNS, le routage ou l’accessibilité fonctionnent fondamentalement.

Vérifications rapides :

• Reach host : ping 192.0.2.10 count 4 vérifie l’accessibilité ICMP.
• Vérifier DNS : dnslookup example.com vérifie la résolution de nom du point de vue du pare-feu.
• Vérifier l’itinéraire : traceroute 192.0.2.10 affiche le chemin vers la destination.
• Afficher l’état de l’interface : show interfaces affiche les informations sur l’interface.
• Démarrer Drop Capture : drop-packet-capture 'host 192.0.2.10' affiche les paquets abandonnés par les règles de pare-feu.
• Démarrer la capture des paquets : tcpdump 'host 192.0.2.10 and port 443' vérifie si les paquets sont visibles sur le pare-feu. drop-packet-capture est particulièrement utile lorsqu’il n’est pas clair si le pare-feu supprime activement des paquets. Cependant, cela ne remplace pas l’analyse des applications. Si un serveur répond mais que l’application ne fonctionne toujours pas, il a également besoin d’une vérification Log Viewer, NAT, Packet Capture ou de journaux d’application.

Pour les enregistrements de paquets plus longs et les fichiers PCAP, l’article séparé Sophos Firewall : Collecter les journaux avec TCPDump pour analyse est plus approprié. Vous devez également planifier la taille du fichier, l’endroit où il sera stocké et la manière dont il sera transféré en toute sécurité.

Vérifiez les connexions et le flux de paquets dans le Advanced Shell

Si Log Viewer et Device Console ne fournissent pas de réponse claire, certaines commandes shell avancées vous aideront à comprendre le flux des paquets.

Connexion

conntrack affiche les connexions actives dont le chemin du pare-feu avec état est conscient. Ceci est utile si vous souhaitez vérifier si une connexion apparaît même dans le suivi des connexions.

conntrack -L | grep "192.0.2.10"

Si une entrée est manquante, cela peut indiquer un routage, NAT, une source incorrecte, une règle de pare-feu manquante ou un test sur le mauvais chemin. Si une entrée existe mais que l’application ne fonctionne pas, une vérification supplémentaire doit être effectuée pour voir si les paquets de réponse sont renvoyés et si NAT, la stratégie ou l’application fonctionnent correctement.

tcpdump dans le Advanced Shell

Pour des tests rapides en direct, le tcpdump peut également être utilisé dans le Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

Pour des analyses productives, le filtre doit être aussi étroit que possible. Les enregistrements étendus comme tcpdump -i any sans hôte, port ou compte produisent rapidement beaucoup de résultats et ne sont pas pratiques sur des pare-feu très chargés.

Un démarrage en toute sécurité est un court enregistrement avec la limite d’hôte, de port et de paquets :

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

Si davantage de données sont nécessaires, l’espace de stockage doit être vérifié au préalable et un emplacement de stockage PCAP doit être délibérément choisi.

Vérifiez l’espace de stockage et l’état du système

Avant la journalisation de débogage, les archives de journaux volumineuses ou les enregistrements de paquets plus longs, l’espace de stockage libre doit être vérifié.

df -kh
df -h /var

Autres vérifications rapides :

uptime
top
service -S
service -S | grep strongswan

service -S affiche l’état de nombreux services. Les noms de services individuels ne sont pas toujours explicites. Vous devez donc comparer le service avec le fichier journal approprié avant d’activer les redémarrages ou le débogage.

Si l’espace de stockage est déjà limité, la journalisation du débogage et l’enregistrement des paquets longs ne doivent pas être démarrés. Tout d’abord, précisez quels journaux ou rapports peuvent être sauvegardés et nettoyés en toute sécurité.

Activer spécifiquement le journal de débogage

La journalisation du débogage peut aider à résoudre des erreurs complexes, mais ne doit être active que pendant une courte période et uniquement pour le service concerné. Le débogage génère beaucoup plus de données de journal et peut consommer de l’espace de stockage s’il s’exécute pendant une longue période.

Exemple de débogage IPS :

service ips:debug -ds nosync

Reproduisez le problème, notez l’heure pertinente puis désactivez à nouveau le débogage :

service ips:debug -ds nosync off

Avant de redémarrer un service, vous devez vérifier quelle fonction est affectée et si un trafic productif y circule actuellement. Le redémarrage de VPN, des services IPS, Web ou d’authentification peut affecter les sessions actives ou les connexions des utilisateurs.

Livrer les journaux en toute sécurité

Les extraits individuels du journal ne suffisent souvent pas pour les cas complexes. Pour le support Sophos, Avanet ou une analyse externe, une archive complète des journaux est généralement plus utile. Au lieu d’écrire les données d’accès FTP dans des commandes, vous devez transférer les journaux de manière sécurisée et traçable, par exemple via scp vers votre propre serveur ou via un portail d’assistance. Les instructions appropriées sont disponibles dans Sophos Firewall Sauvegarder les journaux pour l’assistance et l’analyse.

Les fichiers journaux peuvent contenir des informations sensibles : adresses internes IP, adresses IP publiques, noms d’hôte, noms d’utilisateur, paramètres VPN et messages d’erreur. Avant de les partager, il convient de préciser qui recevra les données et combien de temps elles seront conservées.

Erreurs de dépannage CLI typiques

• Commande dans la mauvaise zone de console : Device Console et Advanced Shell prennent en charge une syntaxe différente. Vérifiez d’abord la zone.
• Laisser le débogage actif après analyse : Les journaux augmentent inutilement et peuvent consommer de l’espace de stockage. Désactivez à nouveau le débogage immédiatement.
• Large tcpdump sans filtre : Beaucoup de sorties, une charge élevée et des données difficiles à évaluer. Restreindre l’hôte, le port, l’interface ou le nombre.
• Identifiants FTP dans l’historique du shell : Les informations d’identification peuvent se retrouver dans les journaux, les captures d’écran ou l’historique. Utilisez un transfert sécurisé et des informations d’identification temporaires.
• Vérifiez un seul fichier journal : De nombreux problèmes affectent plusieurs modules. Combinez Log Viewer, correspondant aux journaux de service et Packet Capture.
• Ne documentez pas l’heure : Le support doit rechercher des zones de journaux inutilement grandes. Notez l’heure, l’action de test et les adresses IP impliquées.
• Ne pas nettoyer après les tests : Le débogage, les fichiers temporaires ou les accès larges restent actifs. Désactivez le débogage, vérifiez les fichiers et supprimez les partages temporaires SSH.

Liste de contrôle

• Accès SSH autorisé uniquement à partir de réseaux d’administration de confiance.
• Empreinte digitale SSH et accès admin vérifiés avant analyse.
• Gamme de consoles correcte sélectionnée : Device Console ou Advanced Shell.
• Heure du problème, source IP, destination IP, port et utilisateur documentés.
• Résultats CLI documentés avec fenêtre horaire, commande, filtre et résultat.
• Lisez les commandes utilisées en premier avant le démarrage du débogage, des redémarrages du service ou des captures plus longues.
• Log Viewer vérifié en premier.
• Fichier journal correspondant identifié sous /log.
• tail, grep ou less utilisé avec un terme de recherche étroit.
• Utilisé spécifiquement pour les problèmes de réseau ping, dnslookup, traceroute, drop-packet-capture ou tcpdump.
• Le débogage n’est activé que brièvement et à nouveau désactivé.
• Espace disque vérifié avant le débogage ou PCAP.
• Transférez en toute sécurité les archives des journaux et supprimez les fichiers temporaires.
• Accès temporaire aux appareils ou exceptions SSH supprimées après le cas de support.

FAQ