> Tech > Améliorer l’administration à  distance sécurisée avec SSH

Améliorer l’administration à  distance sécurisée avec SSH

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Mel Beckman Mis en ligne le 08/O3/2006 - Publié en Septembre 2005

Vous êtes confortablement assis dans un hall de départ d’aéroport, surfant sur le Web, quand on vous appelle : un programme critique est à la dérive et on a besoin de vos talents au bureau pour redresser la situation. Malheureusement, le programme en question tourne sur une machine placée derrière le pare-feu d’entreprise, hors de portée de votre connexion VPN. Que pouvez-vous faire ? Si vous maîtrisez Unix, la réponse est simple : vous connecter à distance directement au serveur en utilisant SSH (Secure Shell), véritable couteau de l’armée suisse des outils d’administration à distance. Hélas, récemment encore, si votre cible était une boîte iSeries, vous étiez désarmé.Heureusement, cette impuissance a disparu depuis le 9 février 2005. Précisément le jour où IBM a répondu aux doléances des clients iSeries qui demandaient SSH natif sur i5/OS. Le dicton «mieux vaut tard que jamais » ne s’est jamais autant vérifié. La guerre de la sécurité des réseaux s’est aggravée. On ne compte plus les nouvelles menaces provenant des réseaux sans fil, des usurpateurs d’identité, des chevaux de Troie et des débordements de buffer. Et les spécialistes iSeries ont besoin de tous les outils existants pour mener ce combat. SSH est une arme de choix pour l’administrateur de réseau.

Bien que l’accès par ligne de commande à distance soit l’une des utilisations les plus évidentes de SSH, ce n’est que le début. SSH peut accomplir bien plus que cela, sur un large éventail de plates-formes, postes de travail, serveurs, portables, routeurs et même téléphones cellulaires. Avec SSH, vous pouvez copier en tout sécurité des fichiers de votre iSeries sur un serveur Unix, canaliser une connexion d’accès base de données d’un réseau à un autre, et même disposer des services intranet d’entreprise dans votre chambre d’hôtel. Le tout sous l’excellente protection d’un cryptage musclé dont les clés peuvent atteindre 256 bits.

Pour bénéficier de ce trésor de l’administration à distance, gratuit de surcroît, il suffit de consacrer une heure ou deux à installer SSH et à l’essayer. Comme SSH est un produit opensource, son interface ligne de commande est homogène entre les systèmes, de sorte qu’une fois apprise, on peut la réutiliser en de multiples endroits. Continuez la lecture pour apprendre à utiliser SSH sur l’iSeries ou autre plate-forme de votre choix. Vous deviendrez rapidement un expert.

Améliorer l’administration à  distance sécurisée avec SSH

La figure 1 schématise le fonctionnement de base de SSH. On trouve deux composantes principales : un client et un serveur. Le premier fonctionne sur un système distant et le second sur un hôte local. Principale différence entre les deux: le client a la maîtrise complète de toutes les opérations SSH, tandis que le serveur est là pour satisfaire les desiderata du client. Le serveur peut être un hôte iSeries et le client un poste de travail, ou vice-versa. Les rôles de client et de serveur sont interchangeables dès lors que la plupart des configurations SSH incluent les deux composantes.

Par défaut, SSH utilise pour toutes les communications, le port TCP/IP numéro 22, bien connu. L’illustration montre bien que SSH peut passer au travers des pare-feu. Le client amorce la connexion SSH, laquelle traverse généralement sans problème son pare-feu local, puisque la plupart des pare-feu permettent tous les ports sortants, y compris le port 22 de SSH. Mais ce n’est qu’une convention : on peut spécifier n’importe quel autre port et il est d’ailleurs parfois pertinent d’utiliser un autre port bien connu, comme le port 80 (HTTP), puisque presque tous les pare-feu l’autorisent.

Le pare-feu de destination ne passera pas le port 22 – ou tout autre port en l’occurrence – par défaut. Vous devez créer un « trou d’épingle » dans ce pare-feu, qui est probablement sous votre contrôle, pour permettre les connexions SSH entrantes vers le serveur SSH. Cela requiert généralement une traduction d’adresses (address translation) réseau, pour associer une adresse IP publique à l’avant du pare-feu (1.2.3.4) à une adresse IP privée à l’arrière de celui-ci (10.2.2.1). Cette manoeuvre ne met pas la sécurité en péril dès lors que seuls les serveurs SSH correctement configurés sont autorisés à se connecter. Grâce à l’authentification cryptée et au transfert de données de SSH, l’exposition de SSH présente moins de risque que, par exemple, celle d’un serveur Web.

Quand un client SSH initie une connexion vers un serveur SSH, un processus d’authentification s’enclenche. Ce processus est complètement caché par le cryptage, mais il crée au final une paire unique de clés de session, qui fournit un tunnel résistant aux attaques en force.

Le degré de cette résistance dépend de l’algorithme de cryptage utilisé. SSH supporte le DES (Digital Encryption Standard) 56-bit, dont la sécurité laisse à désirer. Le 3DES (Triple-DES) 128-bit, sûr contre tous les crackers sauf les plus riches (comme les gouvernements) et les algorithmes Blowfish et AES (Advanced Encryption Standard) 256-bit, virtuellement impénétrables, entre autres. L’algorithme par défaut est 3DES, amplement suffisant pour la plupart des applications de gestion. Les utilisateurs militaires demanderont AES avec des clés de 256 bits.

Qu’utilise donc SSH pour authentifier l’utilisateur et le client ? Dans le cas le plus simple, un client se connecte avec un ID et mot de passe utilisateur standard, stocké au préalable dans l’hôte, généralement dans le cadre du profil de l’utilisateur. Cela prouve au serveur que le client est bien qui il prétend être, mais cela ne prouve rien au client. Ce genre d’authentification unilatérale est vulnérable face à des attaques MITM (man-in-the-middle). Pour obtenir une authentification entièrement symétrique, SSH supporte des paires de clés publiques/privées qui vérifient les deux identités du client et du serveur. De telles sessions ne craignent pas le MITM.

Il existe deux versions de SSH: SSH1 et SSH2. SSH1 souffre de quelques faiblesses incurables qui le rendent indésirable sauf si l’on n’a pas le choix (généralement parce qu’il est intégré dans le firmware d’un appareil réseau). Tous les produits SSH utilisent SSH2, avec compatibilité amont vis-à-vis de SSH1.

Le comportement par défaut de SSH consiste à offrir un shell de commande au serveur sur le système client. C’est l’opération la plus primitive de SSH et l’une de ses plus utiles. Toutefois, le tunnel crypté que SSH crée est bidirectionnel, et donc il peut acheminer du trafic pour le compte de tout autre protocole TCP/IP dans les deux sens. C’est une technique appelée port forwarding sur laquelle nous reviendrons. Avec le port forwarding, SSH fournit entre deux hôtes un conduit que d’autres hôtes sur l’un ou l’autre des réseaux peuvent exploiter. SSH accomplit cela moyennant un seul trou d’épingle dans le pare-feu, ce qui rend admin setup beaucoup plus simple qu’en créant un VPN classique de pare-feu à parefeu. Et ce conduit va d’hôte à hôte, pas de réseau à réseau, ce qui permet de contrôler la sécurité d’accès distant beaucoup plus finement qu’avec des VPN basés sur des pare-feu.

Téléchargez cette ressource

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.

Tech - Par iTPro.fr - Publié le 24 juin 2010