Aller au contenu
Avanet

Connectez 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.
  • 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 le Advanced Shell : sauvegarde, fenêtre de maintenance et chemin de restauration clair.

⚠️ 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.

Clarifier au préalable à quoi sert le 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.
  • Lire les fichiers journaux, tail, grep, less: Advanced Shell. Lecture seule, ne pas modifier ni supprimer de fichiers.
  • Vérifier l’état du service ou déboguer: Advanced Shell. Activez uniquement le débogage spécifiquement et désactivez-le à nouveau.
  • Exécuter des 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.

SSH Autoriser l’accès sur le 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 à l’administrateur Web du Sophos Firewall.
  2. Ouvrez Administration.
  3. Sélectionnez Device access.
  4. Vérifiez si SSH est autorisé pour la zone souhaitée.

Pour les réseaux d’administration internes, SSH peut être activé directement pour la zone appropriée, par exemple pour LAN. Si l’accès doit être restreint plus spécifiquement, une règle d’exception ACL de service local est logique.

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 atteindra le service SSH local du pare-feu, qu’une règle classique de LAN à WAN soit correctement créée.

Dans le cas d’une exception ACL, les valeurs doivent être définies aussi étroitement que possible :

  • Zone source : la zone à partir de laquelle s’effectue l’administration
  • Source Network / Host : l’adresse IP de l’administrateur ou le réseau de gestion
  • Services : SSH
  • Action : Accepter
Règle d'exception ACL du service local Sophos Firewall pour l'accès SSH
Exemple de règle d’exception ACL de service local qui autorise uniquement l’accès SSH à partir d’un objet source défini.

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

Stocker la clé publique pour l’administrateur

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. Pour les opérations, cela signifie : Les modifications clés appartiennent à un processus d’administration documenté et ne doivent pas être traitées comme un raccourci d’assistance spontané.

La clé publique est ajoutée dans la zone Authentification par clé publique pour l’administrateur :

  1. Ouvrez Administration.
  2. Sélectionnez Device access.
  3. Faites défiler jusqu’à la zone Authentification par clé publique pour l’administrateur.
  4. Activez Activer l’authentification.
  5. Ajoutez la clé publique sous Authorized keys.
  6. Enregistrez avec Appliquer.
Authentification par clé publique du pare-feu Sophos pour l'utilisateur administrateur
Méthode préférée : activez l’authentification par clé publique pour l’accès SSH avec l’utilisateur administrateur.

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.

Connectez-vous à 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 un accès récurrent, le chemin d’accès à la clé, l’adresse IP source autorisée et le but doivent être documentés. L’entrée known_hosts ne doit pas être copiée dans les tickets ou les historiques de discussion ; Pour les avertissements relatifs aux clés de l’hôte, l’historique des modifications est plus important qu’une solution de contournement rapide.

Connectez-vous à 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 :

  1. Ouvrez PuTTY.
  2. Saisissez l’adresse IP ou le nom DNS du Sophos Firewall sous Nom d’hôte.
  3. Définissez Port sur 22.
  4. Définissez le Type de connexion sur SSH.
  5. Connectez-vous avec Ouvrir.
  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

Après une connexion réussie via SSH, le pare-feu affiche un menu de console. L’option que vous choisissez dépend de ce que vous souhaitez faire.

Pour de nombreuses commandes SFOS que vous utilisez :

4. Device Console

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

5. Device Management > 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.

  • Device Console: ping, dnslookup, traceroute, show, options de routage ou système.
  • Advanced Shell: Lire les journaux de débogage /log, tail -f, grep, less, service -S.

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.

Terminer la connexion

Une fois le travail terminé, la session SSH doit se terminer proprement :

exit

Si vous êtes dans un sous-menu, il peut être nécessaire de revenir d’abord au menu principal puis de terminer la session.

Si SSH n’a été activé que temporairement pour un cas de support, la version doit alors être supprimée ou désactivée. Cela est particulièrement vrai pour les exceptions ACL provenant d’adresses IP sources externes ou d’un accès à un fournisseur de services.

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 rejetée, SSH n’est généralement pas autorisé sur le pare-feu pour la zone ou la source sélectionnée. Dans ce cas, Administration > Device access doit être coché. Vérifiez également si une règle d’exception ACL autorise la source ou si une version plus large d’accès au périphérique a été délibérément supprimée.

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.

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 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 n’est pas reconnue, la mauvaise console est souvent ouverte. Les commandes telles que system ... appartiennent souvent au Device Console. Les commandes de système de fichiers et de journal telles que tail, grep, less ou service -S appartiennent au Advanced Shell.

Liste de contrôle opérationnel

  • Autorisez uniquement SSH à partir de sources administratives fiables.
  • Si possible, utilisez la règle d’exception Local Service ACL au lieu de la libération de zone étendue.
  • Préférez Public Key Authentication pour admin.
  • Utilisez le type de clé pris en charge et la longueur de la clé du document.
  • Ne partagez pas de clés privées.
  • Vérifiez l’empreinte digitale SSH lors de la première connexion.
  • Gérez consciemment les avertissements de clé hôte après une réimage ou un remplacement de matériel.
  • Ne confondez pas Device Console et Advanced Shell.
  • N’apportez des modifications au Advanced Shell que dans un but clair.
  • Supprimez les versions temporaires SSH après les cas de support.
  • Supprimez les anciennes clés publiques après un changement de personnel ou de prestataire de services.

FAQ

Quel utilisateur est utilisé pour SSH sur Sophos Firewall ?

Pour SSH, vous utilisez l’utilisateur admin sur Sophos Firewall. Les utilisateurs normaux du WebAdmin, même avec des droits d’administrateur, ne se connectent pas en tant qu’utilisateurs du SSH.

SSH doit-il être activé sur la zone WAN ?

SSH ne doit pas être activé de manière généralisée sur la zone WAN. Si un accès externe est nécessaire, vous devez utiliser une règle d’exception de source étroite Local Service ACL, un accès VPN ou un accès au support clairement limité.

L'authentification par clé publique est-elle plus sécurisée que la connexion par mot de passe ?

Public Key Authentication est généralement la meilleure méthode pour un accès administrateur récurrent si les clés privées sont protégées, non partagées et vérifiées régulièrement. Cependant, une clé publique ne remplace pas des restrictions strictes sur les sources ou un démantèlement propre des anciens accès.

Que signifie un avertissement de clé d'hôte SSH ?

Un avertissement de clé hôte signifie que l’empreinte digitale stockée ne correspond plus à la cible. Cela peut être normal après une réimage, un remplacement de matériel ou un changement d’adresse IP, mais peut également indiquer un système cible incorrect. Par conséquent, vérifiez d’abord le pare-feu, le DNS, l’adresse IP et l’historique des modifications.

Quand avez-vous besoin du Advanced Shell ?

Le Advanced Shell est principalement nécessaire pour les fichiers journaux, les diagnostics liés au système de fichiers ou certaines commandes de support. Le Device Console suffit souvent pour des tests simples tels que le ping, le DNS, le routage ou les diagnostics standards.