Se connecter à Sophos Firewall via SSH

Pour de nombreuses tâches d’assistance et de dépannage, vous devez accéder au Sophos Firewall via SSH. Il s’agit par exemple des analyses de journaux, des redémarrages de services, des commandes de diagnostic spéciales ou du travail dans le Advanced Shell.

Mais SSH est aussi un accès de gestion à haut risque. L’accès ne doit donc être autorisé qu’à partir de réseaux d’administration dignes de confiance, via une règle d’exception Local Service ACL ciblée ou via un accès au support clairement défini. Pour le renforcement général des services de pare-feu locaux, Configurer correctement Device Access convient également.

Exigences

Pour une connexion du SSH au Sophos Firewall, vous avez besoin de :

• Accès administratif au Sophos Firewall.
• L’adresse IP ou le nom DNS du pare-feu.
• Accès à l’utilisateur admin.
• Un mot de passe de l’administrateur par défaut modifié et documenté de manière sûre ; le mot de passe d’usine ne doit pas rester utilisé en production.
• Une source d’administration fiable, par exemple un réseau de gestion, VPN ou une adresse IP d’administration fixe.
• Sous macOS ou Linux : l’application Terminal préinstallée avec SSH.
• Sous Windows : Terminal Windows avec OpenSSH ou PuTTY.
• Accès autorisé à SSH sous Administration > Device access ou via une règle d’exception ACL de service local.
• Pour les modifications planifiées dans l’Advanced Shell : une sauvegarde, une fenêtre de maintenance et un plan clairement défini pour annuler les modifications en cas de problème.

⚠️ SSH ne doit être autorisé qu’à partir de réseaux de confiance. Pour les environnements productifs, il est préférable de restreindre l’accès à une adresse IP de gestion ou à un réseau d’administration plutôt que de publier SSH de manière générale.

Définir l’usage prévu de SSH

Toutes les analyses n’ont pas besoin du Advanced Shell. Avant de vous connecter, il convient de préciser quelle console est requise et quelle est la gravité de l’intervention.

• Routage, DNS, Ping, commandes système simples: Device Console. Sophos CLI, moins risqué que le Advanced Shell.
• Informations système détaillées, bases de données ou services système : le Advanced Shell peut être nécessaire. Sans instruction Sophos fiable et propre au dossier, limitez-vous aux contrôles en lecture seule et ne modifiez ni ne supprimez rien.
• Vérifier l’état du service ou déboguer: Advanced Shell. Activez uniquement le débogage spécifiquement et désactivez-le à nouveau.
• Commandes inconnues : Vérifiez d’abord ou ouvrez un dossier d’assistance. N’essayez pas dans le système de production.

La distinction est importante car Device Console et Advanced Shell utilisent une syntaxe différente. De nombreuses erreurs se produisent simplement parce qu’une commande correcte est saisie au mauvais endroit. Une présentation plus large est disponible dans Dépannage Sophos Firewall : Services et journaux.

Autoriser l’accès SSH au pare-feu

Pour qu’une connexion soit possible, le Sophos Firewall doit autoriser SSH sur la zone appropriée ou via une règle d’exception Local Service ACL.

1. Connectez-vous au WebAdmin de Sophos Firewall.
2. Ouvrez Administration.
3. Sélectionnez Device access.
4. Sous Local service ACL, vérifiez si SSH est autorisé pour la zone d’administration de confiance prévue. Notez l’état actuel avant toute modification.
5. Si vous souhaitez délibérément autoriser l’accès pour l’ensemble de cette zone, activez SSH uniquement pour cette zone et enregistrez avec Apply. Les paramètres déjà appropriés n’ont pas besoin d’être modifiés à nouveau.

Pour un réseau d’administration interne de confiance, LAN peut par exemple être la zone appropriée. Toutefois, une autorisation au niveau de la zone ne se limite pas à un seul poste d’administration. Pour restreindre l’accès à une adresse IP d’administration ou à un réseau de gestion, utilisez plutôt la Local service ACL exception rule décrite ci-dessous ; une autorisation étendue à toute la zone n’est pas une étape supplémentaire obligatoire. N’activez pas SSH de manière généralisée pour WAN.

Device Access contrôle l’accès au pare-feu lui-même. Ce n’est pas la même chose qu’une règle de pare-feu normale qui autorise le trafic à travers le pare-feu. Si SSH dans Device Access est activé de manière trop large, un client peut atteindre le service SSH local du pare-feu même si une règle LAN-to-WAN classique est correctement configurée.

La console CLI web constitue un mode d’accès différent de celui d’un client SSH : le client SSH utilise TCP 22, tandis que la console du navigateur utilise l’accès HTTPS au WebAdmin. Pour accéder à la console depuis le navigateur, ouvrez Administration > Device access, vérifiez sous Local service ACL l’autorisation HTTPS pour la zone d’administration de confiance prévue et, si nécessaire, activez-la en cliquant sur Apply. Ouvrez ensuite la liste déroulante de l’administrateur en haut à droite du WebAdmin et sélectionnez Console. Aucune autorisation SSH n’est nécessaire pour cet accès depuis le navigateur. HTTPS ne doit pas non plus être ouvert de manière généralisée sur le WAN ; les restrictions existantes sur les sources restent en place.

Le choix du compte est soumis à la limite documentée pour SFOS 22 et 23 : les instructions PuTTY exigent explicitement admin et excluent les autres noms d’utilisateur, y compris pour la connexion par mot de passe. La description du profil accorde certes au profil Administrator un accès CLI complet et permet de l’attribuer à d’autres administrateurs, mais ne précise aucun mode de transport pour cet accès. Une autorisation liée à un rôle ne garantit donc pas qu’un compte nominatif puisse se connecter en SSH via le réseau. De même, aucun accès général à la console depuis un navigateur n’est confirmé ici pour tous les comptes nominatifs. Avant d’utiliser une voie d’accès comme solution de repli, vérifiez cet accès avec le compte prévu sur la version SFOS installée. Si Console est absent ou si l’accès est refusé, conservez les sessions existantes qui fonctionnent ; vérifiez le compte, le profil et la voie d’accès et, si nécessaire, clarifiez le problème avec Sophos Support plutôt que d’élargir les autorisations WAN ou ACL. Les étapes SSH suivantes continuent d’utiliser admin ; la gestion exclusive des SSH Public Keys par l’administrateur par défaut constitue une autorisation distincte.

Avant toute modification, notez les zones dans lesquelles SSH est actuellement activé ainsi que les exceptions SSH existantes. Vous pourrez ainsi rétablir l’état initial sans supprimer une autre autorisation voulue.

Sous Local service ACL exception rule, cliquez sur Add et définissez les valeurs de manière aussi restrictive que possible :

• Name : par exemple SSH-depuis-reseau-admin ; valeur libre et explicite
• Rule position : la position de l’exception dans la Local Service ACL
• Description : objectif, équipe responsable et date de fin pour un accès temporaire
• IP version : IPv4 ou IPv6 selon la source d’administration et l’adresse de destination
• Source zone : la zone à partir de laquelle s’effectue l’administration
• Source Network / Host : l’adresse IP de l’administrateur ou le réseau de gestion
• Destination host : l’adresse IP du pare-feu ou l’interface à administrer, si l’accès peut aussi être limité à une adresse de destination précise
• Services : SSH
• Action : Accept

Enregistrez avec Save. Pour un seul poste d’administration, Source Network / Host peut être un objet hôte contenant 192.0.2.10. Il s’agit d’une adresse de documentation à remplacer par l’adresse IP réelle, de préférence fixe, de l’administrateur. Destination host limite aussi l’adresse IP du pare-feu par laquelle le service est joignable ; n’incluez pas toutes les interfaces sans raison opérationnelle.

Ouvrez une nouvelle session SSH depuis la source d’administration prévue. Le test réussit lorsque le menu de la console apparaît. Testez ensuite depuis un réseau volontairement non autorisé et vérifiez qu’aucune session ne s’établit. En cas de résultat inattendu, laissez la session WebAdmin existante ouverte et contrôlez l’IP source, Source zone, IP version, Destination host, la position de la règle et les filtres en amont.

Pour un accès temporaire, supprimez uniquement cette exception sous Administration > Device access > Local service ACL exception rule, puis confirmez avec OK. Si vous avez modifié une case de zone, rétablissez seulement son état noté et cliquez sur Apply. Testez ensuite depuis la même source et vérifiez que SSH est de nouveau accessible ou bloqué exactement comme avant la modification. Le test valide ainsi l’état initial sans supposer que la connexion doit systématiquement réussir ou échouer.

SSH ne doit pas être accessible de manière incontrôlée depuis Internet. Si un accès externe est nécessaire, celui-ci ne doit être autorisé que via une adresse IP source clairement définie, VPN ou un accès au support dédié.

Diagnostics > Support access est un mécanisme séparé. Il n’expose pas simplement SSH depuis internet, mais permet à Sophos Support un accès temporaire via un canal de support établi par le pare-feu. Cet accès doit aussi être limité dans le temps et désactivé après le cas de support.

Lors de l’activation de Support access, vous choisissez une durée, puis le pare-feu génère un Access ID unique pour Sophos Support. Cet Access ID reste valide pendant la durée choisie ; Support access peut être désactivé à tout moment avant son expiration. Sophos Support peut ainsi accéder à WebAdmin et au shell sans avoir besoin des identifiants administrateur habituels. Le pare-feu établit lui-même les connexions de support sortantes pour HTTPS et SSH via TCP 22 ; sur le plan opérationnel, cela diffère d’une autorisation SSH entrante depuis le WAN.

Avant toute activation, y compris dans WebAdmin, vérifiez d’abord le canal de support existant sous 4. Device Console à l’aide de la commande en lecture seule :

show support_access

La commande indique si Support access est actif et, lorsque l’accès est actif, affiche également l’Access ID et la durée. Consignez l’état initial ainsi que toute durée et tout Access ID affichés exclusivement dans le dossier de support correspondant, via un accès authentifié. L’affichage seul ne prouve pas à quel dossier le canal appartient ; clarifiez cette attribution et le consentement à l’accès avec l’équipe responsable et Sophos Support.

Si un canal est déjà actif pour un autre dossier ou si la responsabilité du canal est incertaine, arrêtez la procédure et coordonnez la suite des opérations, sans réactiver, remplacer ni désactiver le canal. De même, un canal actif déjà autorisé pour ce même dossier ne doit pas être activé à nouveau ; son utilisation ultérieure et sa fermeture doivent être coordonnées dans le dossier existant. Ne commencez la procédure autonome d’activation, d’analyse et de désactivation que si l’état initial est confirmé comme inactif et si un consentement explicite a été donné pour ce dossier de support. Cette condition s’applique aux deux modes d’accès suivants.

Pour procéder depuis WebAdmin, ouvrir Diagnostics > Support access, activer Support access et confirmer avec OK. Choisir ensuite la durée nécessaire pour le cas de support concerné, cliquer sur Apply et confirmer à nouveau avec OK. Le pare-feu établit une connexion de contrôle sécurisée avec son proxy d’accès ; l’access ID généré se trouve sous Access status et se transmet uniquement à Sophos Support par le canal de support convenu.

Contrôler Support access depuis la Device Console

SFOS 22 permet également d’activer le canal de support sous 4. Device Console. Immédiatement avant la commande d’écriture, effectuez à nouveau dans cette console la vérification décrite ci-dessus avec show support_access. N’activez le canal que s’il est confirmé comme inactif et si le consentement a été donné pour ce dossier :

set support_access enable

Après une activation réussie, la commande affiche l’Access ID et la durée d’accès. Comparez la durée effectivement affichée avec le consentement donné pour le dossier ; la syntaxe CLI documentée ne comporte aucun paramètre permettant de définir une durée. Si une durée précise est nécessaire, utilisez la procédure WebAdmin décrite ci-dessus après avoir effectué la même vérification préalable. L’Access ID et la durée ne doivent être communiqués que dans le dossier de support correspondant, via un accès authentifié, et ne doivent pas être copiés dans une documentation générale, des discussions ou des coffres de mots de passe.

Une fois l’analyse terminée, désactivez, quelle que soit la durée restante, exclusivement votre propre canal mis en place avec consentement pour ce dossier. Au préalable, vérifiez avec show support_access et l’Access ID consigné qu’il s’agit toujours de ce canal. S’il est déjà inactif, n’exécutez pas la commande d’écriture ; si l’ID est différent ou si la responsabilité du canal est incertaine, arrêtez la procédure et coordonnez la suite des opérations au lieu de désactiver un canal susceptible d’appartenir à un autre dossier :

set support_access disable

Vérifiez ensuite sous Diagnostics > Support access ou avec show support_access que votre propre canal n’est plus actif. disable ne modifie ni la configuration SSH normale sous Device Access ni les Local Service ACL Exception Rules ; les autorisations temporaires d’administration et SSH doivent donc être rétablies séparément à l’état précédemment noté, en annulant uniquement vos propres modifications.

Si un autre routeur ou filtre sortant se trouve devant le pare-feu, il doit autoriser TCP 22 vers *.apu.sophos.com. Aucune règle WAN entrante ne doit être créée pour cela sur Sophos Firewall. Les sessions de support inactives sont fermées après 15 minutes ; la durée totale sélectionnée et la possibilité de désactiver manuellement Support access restent indépendantes de ce délai.

Vérifier les services et ports sortants de Sophos Firewall classe les autres destinations du fabricant pour mises à jour, licences, RED, Central, reporting et sauvegardes.

Support access via l’API XML: clarifier avant toute écriture

L’aide de l’API XML pour SFOS 22 et 23 désigne l’objet par SupportAccess, mais contient deux contradictions: dans l’exemple XML, la balise de durée s’appelle GrantAccessFor, alors que la table des paramètres indique GrantAccessForr. Pour ConfigOption, la table donne comme valeur par défaut ON, mais n’autorise que Enable et Disable. On ne peut en déduire ni que ON est une valeur de requête valide, ni que l’accès au support est actif par défaut. Aucune des deux graphies de la balise n’est confirmée ici comme syntaxe d’écriture fonctionnelle.

La table présente les deux champs comme des valeurs scalaires facultatives et indique les durées 1 day, 2 days, 1 week, 2 weeks, 1 month et 2 months. Cela ne précise pas ce qui se produit réellement lorsqu’un champ est omis. Avant toute modification automatisée, vérifiez donc l’aide API propre à cet objet pour le build SFOS installé et faites clarifier par Sophos Support les questions en suspens concernant la balise, les valeurs ou le comportement en cas d’omission. Tant que la contradiction n’est pas résolue, toute écriture XML doit être interrompue; n’inventez pas de payload et n’essayez pas les deux graphies en production. Pour un dossier de support approuvé, la procédure WebAdmin décrite ci-dessus reste l’alternative, sans élargir les autorisations WAN ou ACL.

La référence indique pour cette opération 200 avec Operation Successful. et 500 avec Operation Fail.. Vérifiez la réponse exacte de l’objet plutôt que de répéter aveuglément une écriture ayant échoué ou dont le résultat est incertain. Après une modification confirmée, contrôlez l’état d’activation réel et la durée sous Diagnostics > Support access ou avec la commande show support_access décrite ci-dessus. Une fois le dossier de support terminé, désactivez exclusivement votre propre canal autorisé pour ce dossier, en appliquant les vérifications de responsabilité décrites ci-dessus, et vérifiez qu’il est inactif ; les autorisations SSH/ACL temporaires doivent toujours être retirées séparément.

Enregistrer une clé publique pour admin

Pour l’accès SSH, l’authentification par clé publique est la méthode préférée. Sur le Sophos Firewall, la clé publique de l’utilisateur admin peut être stockée sous Administration > Device access. Une connexion par mot de passe peut être nécessaire en cas d’urgence, mais ne doit pas rester l’accès par défaut le plus pratique.

⚠️ Une connexion SSH au Sophos Firewall n’est possible qu’avec l’utilisateur admin. Les autres utilisateurs du WebAdmin ne peuvent pas se connecter via SSH.

Important : seul l’administrateur par défaut peut modifier l’authentification par clé publique pour SSH, c’est-à-dire ajouter ou supprimer des clés SSH. Ces modifications de clés SSH doivent s’inscrire dans un processus d’administration documenté et ne constituent pas un raccourci improvisé pour le support.

L’administrateur par défaut n’est pas un compte de rôle normal que l’on peut simplement remplacer. Sophos indique que ce compte ne peut pas être renommé ni supprimé. Le mot de passe de l’administrateur par défaut, les informations MFA ou de récupération pour les connexions administratives interactives et les clés publiques SSH enregistrées doivent donc être gérés ensemble dans le processus d’exploitation administratif. Une clé publique ne remplace pas la gestion rigoureuse de ce compte.

Les administrateurs WebAdmin nominatifs sont gérés séparément et ne peuvent pas se connecter par SSH avec leur propre nom d’utilisateur. Gérer les administrateurs locaux et les profils Device Access selon le principe du moindre privilège explique le cycle de vie et les droits de ces comptes.

Avant d’enregistrer la clé publique sur le pare-feu, générez sur votre propre client administrateur une paire de clés publique et privée correspondantes à l’aide d’un outil de clés SSH. Une paire de clés existante, adaptée et dont les deux clés correspondent peut être réutilisée. Pour le type et la longueur de la clé, suivez les indications de la section suivante sur les types de clés SSH pris en charge. Stockez et protégez la clé privée exclusivement sur le client administrateur ; ne la partagez jamais et ne la téléversez jamais sur le pare-feu. Pour les étapes suivantes, copiez uniquement la clé publique.

La clé publique est ajoutée dans la zone Public key authentication for admin :

1. Ouvrez Administration.
2. Sélectionnez Device access.
3. Faites défiler jusqu’à la zone Public key authentication for admin.
4. Activez Enable authentication.
5. Ajoutez la clé publique sous Authorized keys.
6. Enregistrez avec Apply.

Conservez la session WebAdmin ou SSH existante pendant que vous testez la nouvelle clé dans une seconde session SSH. Ne supprimez une ancienne clé ou ne modifiez un accès de secours par mot de passe qu’après l’apparition du menu de la console dans cette seconde session. En cas d’échec, l’accès existant reste disponible : vérifiez le type de clé, la clé publique enregistrée, la clé privée correspondante et la source autorisée, puis supprimez uniquement la nouvelle entrée incorrecte.

La clé privée reste toujours sur le client administrateur et ne peut pas être partagée. Seule la clé publique est stockée sur le pare-feu.

Si plusieurs administrateurs utilisent SSH, la même clé privée ne doit pas être partagée. Il est préférable d’avoir des clients administrateurs distincts, des clés publiques documentées et un examen des clés encore nécessaires. Après des changements de personnel ou de prestataires, la zone Authorized keys doit être vérifiée.

Types de clés SSH pris en charge

Tous les types de clés SSH modernes ne conviennent pas également au Sophos Firewall. Avant le déploiement, vous devez vérifier si le type de clé est pris en charge.

• RSA: Utilisez au moins 2048 bits.
• DSA: Au moins 2048 bits, si nécessaire pour des raisons de compatibilité.
• ECDSA: Prise en charge ; ED25519 n’est pas accepté à cette fin.
• ED25519: Pour SSH Public Key Authentication, ne pas utiliser sur Sophos Firewall.

Pour un nouvel accès administrateur, une clé RSA correctement gérée ou une clé ECDSA prise en charge est généralement plus pragmatique qu’un type de clé moderne que le pare-feu ou un ancien outil SSH n’accepte pas.

Se connecter depuis macOS ou Linux

Un client SSH est généralement déjà présent sur macOS et Linux. La connexion est établie dans le terminal.

Exemple :

ssh admin@192.0.2.1

192.0.2.1 est remplacé par l’adresse IP ou le nom DNS de votre propre Sophos Firewall.

Lorsque la connexion est établie pour la première fois, le client SSH demande si l’empreinte digitale du système cible doit être acceptée. Cette empreinte digitale doit être vérifiée puis confirmée. Si un avertissement concernant une clé d’hôte modifiée apparaît après une réimage, un remplacement de matériel ou un changement d’adresse IP, la nouvelle empreinte digitale ne doit pas être acceptée aveuglément. Vérifiez d’abord si le même pare-feu a effectivement été remplacé, réinstallé ou déplacé vers une nouvelle adresse IP. Ce n’est qu’alors que l’ancienne entrée dans ~/.ssh/known_hosts pourra être nettoyée et la nouvelle empreinte digitale acceptée.

Selon la configuration, le mot de passe de l’utilisateur admin est alors demandé ou la connexion est effectuée à l’aide de la clé SSH stockée.

Si une clé privée spécifique doit être utilisée :

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

Pour les accès récurrents, documentez le chemin de la clé privée, l’adresse IP source autorisée et l’objectif de l’accès. Ne copiez pas l’entrée known_hosts dans des tickets ou des historiques de discussion. En cas d’avertissement concernant une clé d’hôte, l’historique des modifications est plus important qu’une solution de contournement rapide.

Se connecter avec PuTTY

Sous Windows, vous pouvez soit utiliser Windows Terminal avec OpenSSH, soit utiliser PuTTY.

Avec Windows Terminal, l’établissement d’une connexion fonctionne de la même manière que sous macOS ou Linux :

ssh admin@192.0.2.1

Pour PuTTY : si le programme n’est pas encore installé, téléchargez-le d’abord depuis la page officielle de téléchargement de PuTTY et installez-le sur le poste d’administration. Établissez ensuite la connexion comme suit :

1. Ouvrez PuTTY.
2. Saisissez l’adresse IP ou le nom DNS du Sophos Firewall sous Host Name.
3. Définissez Port sur 22.
4. Définissez Connection type sur SSH.
5. Connectez-vous avec Open.
6. Vérifiez et confirmez l’empreinte digitale SSH.
7. Connectez-vous en tant qu’utilisateur admin et utilisez le mot de passe ou la clé SSH selon la configuration.

Une fois connecté, le menu de la console Sophos Firewall apparaît.

Si PuTTY est utilisé avec une clé privée, la clé doit correspondre à la clé publique stockée sur le pare-feu. Après un changement de personnel ou de prestataire de services, non seulement le mot de passe doit être modifié ; les anciennes clés publiques doivent également être supprimées de Authorized keys.

Ouvrir Device Console ou Advanced Shell

Une fois l’authentification réussie, le Main Menu apparaît. La présentation suivante vous aide à repérer les options du menu :

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

À l’invite Select Menu Number [0-7]:, saisissez le numéro de l’option souhaitée, par exemple 1 pour Network Configuration. Pour les commandes de diagnostic, les deux modes d’accès suivants sont particulièrement importants. 7. Shutdown/Reboot Device mène à des actions susceptibles d’interrompre le fonctionnement ; cette option ne doit pas être sélectionnée à titre d’essai.

Pour de nombreuses commandes SFOS, sélectionnez la Device Console :

4. Device Console

Pour des tâches Linux ou système de fichiers plus approfondies, utilisez le Advanced Shell via :

5. Device Management
3. Advanced Shell

Le Advanced Shell offre un accès très étendu au système. Les commandes ne doivent y être exécutées que si leur rôle est clair.

Selon Sophos, les modifications de configuration effectuées directement dans le Advanced Shell, par exemple sur les interfaces, règles ou politiques, ne persistent pas après un redémarrage et ne sont pas enregistrées dans les sauvegardes. Ce n’est donc pas une méthode normale de configuration. Les fichiers sous /tmp/ sont également supprimés au redémarrage.

• Device Console: ping, dnslookup, traceroute, show, options de routage ou système.
• Advanced Shell : informations système détaillées, bases de données, services système et diagnostics propres au dossier demandés par Sophos Support.

Pour l’analyse des journaux, les noms de services et les modèles d’erreur typiques, Dépannage Sophos Firewall : Services et journaux est un meilleur point de départ que la mémorisation de commandes individuelles.

Comprendre les familles de commandes set et system

Dans 4. Device Console, set définit les réglages et les paramètres de différents composants du système, tandis que system configure les paramètres système. Ces deux familles peuvent modifier la configuration. Pour les découvrir, utilisez uniquement l’aide, et non une commande de modification complète. La documentation de SFOS 22 et 23 présente ces schémas généraux de syntaxe ; ce ne sont pas des commandes à copier :

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set ou system est le préfixe littéral, à saisir exactement comme indiqué.
• Remplacez [command] par la commande documentée souhaitée, par exemple advanced-firewall pour set ou firewall-acceleration pour system.
• [option 1|option 2] signifie qu’il faut choisir une des alternatives documentées. Ne saisissez ni les crochets ni | ; ils ne signifient pas ici que le choix peut simplement être omis.
• <value> est un espace réservé pour une valeur adaptée à l’option sélectionnée. Remplacez-le, chevrons compris, par la valeur nécessaire. C’est l’aide de la commande précise qui détermine les arguments réellement requis, et non ce seul schéma général.

Explication de syntaxe uniquement, ne pas exécuter : dans l’exemple du fabricant set advanced-firewall icmp-error-message allow, set est le préfixe, advanced-firewall la commande choisie, icmp-error-message l’option et allow la valeur concrète qui remplace <value>. Il s’agit d’une modification de configuration, pas d’une étape nécessaire pour SSH. L’exemple system firewall-acceleration enable n’est pas non plus un exercice : system est le préfixe, firewall-acceleration la commande choisie et enable l’option sélectionnée. Cet exemple précis ne comporte aucune valeur supplémentaire ; n’ajoutez pas <value> sans vérification et n’activez pas l’accélération pour faire un essai.

Pour une découverte sans modification, saisissez seulement set dans la Device Console et appuyez trois fois sur Tab pour afficher les réglages disponibles. Tab suivi de ? affiche leurs descriptions. Répétez avec le préfixe system pour découvrir l’autre famille. Le résultat attendu est l’affichage de l’aide, pas un réglage modifié. Effacez ensuite la ligne de saisie sans envoyer de commande de modification avec Enter. Si l’aide attendue n’apparaît pas, vérifiez d’abord la console et la documentation de la version SFOS installée plutôt que d’essayer une commande d’exemple.

Fermer la connexion

⚠️ Les anciennes commandes de la Device Console enableremote et disableremote ne constituent pas une méthode normale de déconnexion : pour SFOS 22 et 23, Sophos indique que disableremote empêche non seulement les nouvelles connexions SSH sur le port 22, mais ferme également les sessions SSH existantes. Ne les exécutez donc pas pour vous déconnecter ou pour retirer une autorisation ACL temporaire. Avant toute utilisation expressément approuvée de ces commandes, une voie d’accès de secours fonctionnelle et indépendante du SSH réseau doit avoir été testée : une console série locale ou hors bande pour les appliances physiques, ou la console de plateforme appropriée pour les pare-feu virtuels ou cloud. Sans cet accès et sans un plan de récupération confirmé pour la version installée, arrêtez-vous et clarifiez le cas avec Sophos Support. La description de enableremote mentionne un port Ethernet ; aucune syntaxe de port TCP ni aucune commande inverse générique n’en est déduite ici. Pour les autorisations d’accès temporaires, le retrait précis décrit ci-dessus sous Administration > Device access reste la procédure à suivre ; le canal sortant établi sous Diagnostics > Support access est distinct.

Dans l’Advanced Shell, utilisez la commande suivante pour quitter le shell. Elle ne remplace pas la sélection d’un numéro dans le menu de la console :

exit

Si vous vous trouvez dans un sous-menu, revenez d’abord au Main Menu. L’option 0. Exit permet alors de fermer la session de console : saisissez 0 à l’invite du menu. La commande du shell et le numéro de menu s’utilisent donc à des endroits différents.

Sophos Firewall ferme les sessions SSH inactives après 15 minutes. Cela ne remplace pas une déconnexion propre : les sessions ouvertes, les modes de débogage et les règles d’accès temporaires doivent quand même être fermés ou retirés consciemment.

Si l’accès SSH n’a été autorisé que pour un dossier de support, retirez ensuite uniquement cette autorisation temporaire. Supprimez la Local service ACL exception rule créée à cette fin, comme décrit ci-dessus ; si une case de zone a été modifiée, rétablissez son état précédemment noté et enregistrez avec Apply. Les autres autorisations encore nécessaires doivent être conservées. Cette distinction est particulièrement importante pour les adresses IP sources externes ou les accès de prestataires.

Après des interventions profondes, il convient également de vérifier :

• Le débogage est-il à nouveau désactivé ?
• Une règle d’exception ACL temporaire a-t-elle été supprimée ou désactivée ?
• N’y a-t-il pas de fichiers temporaires, de sauvegardes de support ou d’enregistrements inutilement laissés sur le pare-feu ?
• Les extraits de journaux, l’heure, la commande et le résultat sont-ils documentés dans le ticket ou la modification ?
• La clé SSH a-t-elle été utilisée uniquement pour un accès planifié à l’administrateur ou au support ?

Problèmes courants

La connexion est refusée

Si la connexion est refusée, SSH n’est souvent pas autorisé pour la zone ou la source sélectionnée. Vérifiez donc le paramètre SSH et les entrées Local service ACL exception rule existantes sous Administration > Device access. Vérifiez également si une autorisation plus large au niveau de la zone a été retirée délibérément. Ne rétablissez pas cet accès sans avoir vérifié la raison de cette restriction.

La connexion expire

Un délai d’attente indique souvent que le pare-feu n’est pas accessible via l’adresse IP sélectionnée, qu’une route est manquante ou qu’un pare-feu en amont bloque l’accès.

Si un pare-feu qui n’est pas encore entièrement configuré utilise toujours le mot de passe d’usine, SFOS rejette volontairement et sans message d’erreur les connexions SSH provenant de la zone WAN. Il s’agit d’une mesure de protection. Le mot de passe doit d’abord être modifié par une voie d’administration locale autorisée ; Device Access ou l’ACL ne doivent pas être élargis pour contourner cette protection.

Aucun accès réseau au pare-feu

Si ni WebAdmin ni SSH ne sont accessibles, n’ouvrez pas dans l’urgence des accès WAN ou des accès de zone supplémentaires. Pour une appliance physique, la console série locale constitue la solution de secours, notamment en cas de mauvaise configuration de Device Access, du routage ou de l’affectation des interfaces aux zones. Utilisez le câble console RJ45 approprié ou, sur les modèles pris en charge, un câble Micro-USB, et réglez le débit sur 38400 bauds dans le logiciel de terminal.

Si les câbles Micro-USB et RJ45 sont connectés simultanément, le Micro-USB est prioritaire et le pare-feu y redirige la sortie de la console. Si le terminal reste vide, vérifiez d’abord le port série sélectionné, le câble et cette priorité. La valeur de 38400 bauds est grisée dans le BIOS pour éviter toute modification accidentelle ; n’essayez donc pas de la modifier à cet endroit.

Les étapes détaillées de connexion sont décrites dans Ouvrir une connexion série. Si vous connaissez le mot de passe du compte admin, utilisez-le pour vous authentifier une fois la connexion établie ; aucune réinitialisation du mot de passe n’est nécessaire. Suivez uniquement les étapes de connexion de l’article lié, et non sa procédure de réinitialisation. La connexion est réussie lorsque le menu de la console s’affiche ; pour les pare-feu virtuels ou cloud, utilisez plutôt l’accès à la console adapté au type de plateforme concerné.

La connexion échoue

Si la connexion échoue, l’utilisateur admin, le mot de passe ou la clé SSH et les réseaux sources autorisés doivent être vérifiés. Des messages typiques tels que Permission denied (publickey,password) indiquent un mot de passe incorrect, une clé privée incorrecte ou une configuration de clé publique manquante.

Si le mot de passe de l’admin par défaut est réellement perdu, Réinitialiser le mot de passe admin de Sophos Firewall explique la récupération série pour les appliances physiques et les limites distinctes des firewalls virtuels et cloud.

Si la connexion par clé publique échoue, vérifiez également le type de clé, la longueur de la clé, la clé privée incorrecte, le format de clé PuTTY et l’entrée sous Authorized keys. Un service SSH correctement autorisé n’aide pas si la clé ne correspond pas à la clé publique stockée.

Un avertissement concernant la clé de l’hôte s’affiche

Un avertissement de clé d’hôte peut être inoffensif si un pare-feu a été réinstallé ou remplacé. L’avertissement peut également indiquer un système cible incorrect ou une confusion d’adresse IP. Par conséquent, vérifiez d’abord le pare-feu, l’adresse IP, le DNS et l’historique des modifications. Ce n’est qu’alors que l’ancienne entrée known_hosts doit être supprimée.

Mauvaise console ouverte

Si une commande Sophos CLI documentée n’est pas reconnue, la mauvaise console est peut-être ouverte ou la syntaxe est incomplète. Dans la Device Console, Tab affiche les commandes et arguments disponibles ; ? affiche leurs descriptions. N’y saisissez pas d’instructions de shell Linux et n’essayez pas non plus de commandes non documentées dans le Advanced Shell.

Liste de contrôle opérationnel

• Autorisez SSH uniquement depuis des sources d’administration de confiance.
• Modifiez le mot de passe d’usine par défaut avant d’utiliser SSH en production.
• Si possible, utilisez une Local service ACL exception rule plutôt qu’une autorisation étendue à toute une zone.
• Privilégiez l’authentification par clé publique pour le compte admin plutôt que la connexion par mot de passe.
• Documentez séparément le mot de passe de l’administrateur par défaut, les informations MFA ou de récupération et les clés SSH.
• Utilisez un type de clé pris en charge et documentez la longueur de la clé.
• Ne partagez pas les clés privées.
• Vérifiez l’empreinte SSH lors de la première connexion.
• Traitez avec vigilance les avertissements concernant les clés d’hôte après une réinstallation de l’image système ou un remplacement de matériel.
• Ne confondez pas la Device Console et l’Advanced Shell.
• N’effectuez des modifications dans l’Advanced Shell que dans un objectif clairement défini.
• Retirez les autorisations temporaires d’accès SSH après les dossiers de support.
• Supprimez les anciennes clés publiques après un changement de personnel ou de prestataire.

FAQ