Sommaire  |  Carte  |  Index  |  Recherche

Convert to GutenPalm or to PalmDoc par Georges Tarbouriech L´auteur: Georges est un vieil utilisateur d'Unix (commercial et libre). Il s'intéresse beaucoup à la sécurité et tient à remercier la communauté du logiciel libre pour l'énorme travail réalisé dans ce domaine. Sommaire: Pourquoi utiliser ssh ? SSH et VNC SSH et MySQL SSH et l'émulation de terminal A partir de là, où allons-nous ? Enfin, c'est fini ! Discussion sur cet article

Par le tunnel

Résumé:

SSH, le "secure shell" est un très bon produit commercial. Toutefois, il existe de nombreuses versions libres de clients ou de serveurs ssh, disponibles pour Unix (commercial ou libre) ou pour différents OS.
Le plus connu est sans doute OpenSSH, disponible sur http://www.openssh.org. A partir de ce site, vous trouverez de nombreuses alternatives pour Unix, Windos, Mac... Concernant des produits tels que Windos, vous ne trouverez que des clients libres.
Dans cet article, nous présentons quelques exemples sur l'usage de ssh comme moyen de faire passer dans un tunnel les données d'applications externes. Les VPNs (Virtual Private Network) sont également basés sur ssh, mais d'une manière beaucoup plus élaborée que celle que nous abordons ici. Une autre solution sophistiquée consiste à utiliser VTun.
En conséquence, considérons ce "tunneling" comme un moyen simple et facile de crypter les données d'un réseau hétérogène pour prévenir leur interception. Evidemment, ceci s'applique aussi bien à un réseau local qu'à un réseau distant. Toutefois, rappelez-vous, ssh ne fait que crypter les données, il n'améliorera pas la sécurité de votre réseau à lui tout seul...
Vous voici avertis !

Pourquoi utiliser ssh ?

SSH est un remplacement de telnet ou de rsh, rlogin, comme déjà mentionné dans un article précédent. Même si quelques problèmes de sécurité ont été découverts récemment dans ssh, il reste un très bon outil pour le cryptage des données. Au fait, le problème de sécurité susmentionné concernait les mots de passe : il est fortement recommandé d'utiliser les passphrases à la place et bien sûr les clés RSA ! Utiliser ssh n'empêche pas non plus d'utiliser d'autres outils de sécurité tels que tcpwrappers, par exemple.
Il est très facile d'intercepter les données circulant sur un réseau grâce à des outils standards tels que tcpdump ou snoop. Vous pouvez tester cela sur un réseau où deux machines échangent des données par telnet, par exemple. Depuis une troisième machine sous Linux, par exemple, lancez tcpdump (en tant que root, bien sûr) et regardez : vous pouvez tout lire !
Bien sûr, l'affichage est trop rapide pour pouvoir tout lire à l'écran, mais rien ne vous empêche de rediriger la sortie vers un fichier et ensuite de le lire tranquillement en buvant un café ou en fumant une cigarette. Si c'est vrai pour les données, ça se vérifie aussi pour les mots de passe : autrement dit, la porte est grande ouverte aux pirates. Vous leur donnez la clé pour entrer chez vous.
Imaginez que les données soient confidentielles... Si vous êtes l'administrateur, j'ai bien peur que votre patron vous suggère de chercher un autre boulot ailleurs.
Les "remote commands", rsh, rcp, rlogin sont également très dangereuses, puisque les données circulent également en clair. Si ssh est un bon replacement de rlogin ou rsh, la distribution contient aussi scp qui est à son tour un bon remplacement de rcp. Autrement dit, vous n'avez plus besoin des "remote commands" ou de telnet si vous utilisez ssh, ou tout au moins, vous ne devriez plus vous en servir.
Comment installer ssh, comment générer les clés publiques ou privés... n'entre pas dans le cadre de cet article. Vous trouverez tout ce dont vous avez besoin dans l'archive ou en lisant la documentation disponible sur le sujet à the Linux Documentation Project, par exemple.
Compte tenu que l'utilisation d'un ordinateur aujourd'hui consiste presque toujours à transférer des données, d'une manière ou d'une autre, ssh devrait être obligatoire... enfin, c'est comme vous voulez. Cela dit, ssh peut faire beaucoup plus que remplacer telnet ou les "remote commands".
Il peut être utilisé pour transférer des données entre des applications externes et bien sûr, des OS différents. Il peut aussi compresser ces données. Il est souvent utilisé avec des protocoles tels que pop, ftp, http... soit pour la compression, soit pour le cryptage. C'est très pratique, par exemple, si vous êtes administrateur, pour vous connecter de chez vous au travail ou l'inverse.
Comme il s'agit d'une application client/serveur, ssh a bien sûr besoin des deux pour fonctionner : il vous faut une machine avec un serveur ssh actif et une machine avec un client ssh actif (J'espère que vous avez remarqué à quel point je suis un gros malin !).
Pourquoi insister sur l'évidence ? Comme nous parlons de logiciel libre, Unix mis à part, de nombreux OS n'ont pas de serveurs libres. C'est-à-dire que parfois il sera difficile de faire ce qui semble évident et il faudra contourner le problème : la clé se nomme redirection. D'avantage sur le sujet un peu plus loin. Cela signifie qu'avec Mac OS ou Windos, vous n'aurez pas de serveurs libres. Il faudra faire avec les clients et ce n'est pas toujours aussi évident qu'il y paraît. Prenons quelques exemples.

SSH et VNC

Si vous ne connaissez pas VNC, vous passez à côté d'un des logiciels les plus extraordinaires jamais vus. Vous pouvez donner un coup d'oeil ici pour en savoir plus.
Si vous allez sur le site de VNC, http://www.uk.research.att.com/vnc/docs.html vous trouverez de nombreuses informations sur le sujet que nous traitons. Par exemple, vous verrez comment utiliser VNC avec ssh, depuis un client ssh Windos et un serveur ssh Unix. Par conséquent, je ne vais pas réécrire le beau travail de Frank Stajano puisqu'il est bien meilleur que ce que je pourrais en faire.
Voyons donc comment ça marche.
Tout d'abord, vous devez choisir un client ssh libre pour Windos. Pour cet exemple nous utiliserons Teraterm Pro avec son extension Ttssh. Vous le trouverez sur http://hp.vector.co.jp/authors/VA002416/teraterm.html. En fait, il se nomme Ttssf puisqu'il s'agit d'une version autorisée en France. (Les choses sont en train de changer, mais sachez que de nombreux pays interdisent encore le cryptage. Visitez cet URL pour connaître la situation du cryptage dans votre propre pays : http://www2.epic.org/reports/crypto2000/countries.html.)

Additif version française
Sachez qu'en France, la situation en vigueur date de 1999, c'est-à-dire "sous le régime 128 bits". Il se trouve que ssh utilise du 168 bits (avec 3DES), donc soumis à autorisation préalable. Ca signifie que si vous utilisez OpenSSL (256 bits) ou OpenSSH tels quels, vous êtes dans l'illégalité... c'est toujours bon à savoir !
La libéralisation est bien prévue... mais il faudra attendre encore un peu (de nouvelles élections pour que la loi sur la société de l'information soit votée).
Merci à Bernard Perrot pour avoir "éclairé mes lanternes".
Pour ceux qui l'ignore, Bernard Perrot est la personne à qui nous devons de pouvoir utiliser légalement ssh en France. Sa version de ssh, nommée ssf, est la seule prenant en charge la déclaration d'utilisation et l'autorisation qui en découle... et qui est obligatoire dans notre pays.
Vous trouverez ssf à http://ww2.lal.in2p3.fr/~perrot/ssf/. Si vous souhaitez rester dans la légalité, sans tracasserie administrative, c'est la version qu'il vous faut. Cela dit, c'est comme vous le sentez, mais vous devrez en assumer le risque.
Fin d'additif

Maintenant, considérons que vous avez lancé un serveur ssh sur une machine Unix. Sur la même machine, nous supposons que vous pouvez lancer un serveur vnc (vncserver). Ces deux serveurs en fonctionnement, vous connectez par exemple, une machine NT à ce serveur Unix en utilisant Ttssh. Vous avez donc une connexion cryptée entre les deux machines. Mais cela ne vous permet pas d'avoir un protocole vncviewer (le client vnc) crypté depuis la machine NT. Pour cela, vous devez dire à ssh de rediriger (nous y voici !) le bon port.
La machine Unix sur laquelle le vncserver est actif se nomme "bandit" et utilise le port 5901, puisqu'il s'agit de l'affichage n°1, l'affichage X par défaut sur cette machine étant le n° 0. L'usage "normal" serait d'envoyer une commande "vncviewer bandit:1". Ceci fonctionnerait, bien sûr, mais sans que les données soient cryptées. A la place, avec le "shell" de NT (l'interface DOS, quoi...), envoyez la commande "/ssh-L5902:bandit:5901" sans espace. Cela signifie que vous créez un port local 5902. Maintenant, une commande telle que "vncviewer localhost:2" lance une connexion cryptée du protocole VNC sur votre machine NT. Ceci peut être réalisé sans utiliser la ligne de commande puisque Ttssh possède une interface graphique. Ajoutons que cette syntaxe ne concerne que Ttssh. La même commande sur une machine Unix serait : "ssh -L 5902:bandit:5901 bandit".
Il s'agit bien sûr d'un exemple basique : vous pouvez faire beaucoup plus complexe. Lisez la doc disponible sur le site de VNC, particulièrement celle de Frank Stajano.

SSH et MySQL

MySQL est sans doute l'une des bases de données parmi les plus utilisées, particulièrement sur Internet. Encore une fois, sécuriser MySQL n'entre pas dans le cadre de cet article. Toutefois, crypter les données circulant entre un serveur et un client MySQL rend la connexion plus sûre. SSH permet de faire cela, de la même manière que celle utilisée pour VNC, autrement dit la redirection de port.
Notre exemple concerne un Intranet. Le serveur MySQL est une machine Linux et la plupart des clients sont des machines NT. Nous utilisons de nouveau Ttssh sur les machines Windos.
Le port par défaut de MySQL est le 3306. Cette fois, nous redirigeons le même port (3306).
Ce peut être une redirection locale ou distante.
Une redirection locale ressemblera à "/ssh-L3306:localhost:3306" sur une machine NT ou à "ssh -L 3306:localhost:3306" sur une machine Unix. Utiliser "localhost" permet d'envoyer les données par l'interface loopback au lieu de l'interface hôte.
Une redirection distante serait "/ssh-R3306:bandit:3306" pour NT et "ssh -R 3306:bandit:3306" pour Unix.
Ceci ne concerne que la connexion proprement dite. Pour vous "loger" sur la base, vous devez bien sûr fournir le nom d'hôte et le nom d'utilisateur au serveur MySQL, ce dernier étant probablement différent de celui utilisé pour se loger sur la machine. Voir les man pages de ssh sur l'option "-l".
Bien évidemment, ceci ne fonctionnera que si vous avez un client MySQL sur votre machine NT.
Dans le cas contraire, vous devrez utiliser une application ODBC, Sybase par exemple (ou si vous êtes courageux, la merveille de "PetitMou" nommée Access). Vous devez donc démarrer cette application. Utilisez ensuite le pilote ODBC pour lier à MySQL. Vous pouvez maintenant vous connecter au localhost, pas à l'hôte du serveur MySQL, pour accéder au dit serveur MySQL. Les données circulant entre le serveur et le client sont maintenant cryptées. Vous pouvez le vérifier à l'aide de snoop ou de tcpdump.
Il s'agit d'un exemple pour réseau local. Si vous souhaitez faire de même sur un réseau distant, ce sera un peu plus complexe, en particulier si vous êtes derrière un firewall, par exemple. Ceci peut être un moyen de faire de l'administration à distance depuis chez vous, si vous êtes le sysadmin, mais vous ne pouvez pas imaginer accéder à une base de données sur un site web de cette manière. Pour cela, il faudra trouver quelque chose de plus sophistiqué, comme un VPN par exemple, mais c'est l'idée.
De toutes façons, ne croyez pas que ce soit suffisant pour sécuriser un serveur de base de données qui transfère du confidentiel tel que des numéros de carte de crédit ! Au fait, qui croit vraiment quelqu'un affirmant qu'il possède un serveur suffisamment sécurisé pour transférer ce genre de données sans risque ? Pas moi, en tout cas !!!

SSH et l'émulation de terminal

Qu'est-ce que ça veut dire puisque nous utilisons déjà une émulation de terminal ?
Supposons que vous ayez une vieille application Cobol sur un serveur Unix. Les clients sont encore une fois des machines NT. Pour se connecter, elles ont besoin d'une émulation de terminal plus sophistiquée que vt100, vt220 ou vt320, puisqu'elle doivent obtenir la bonne interface utilisateur. Les accents, les tableaux... Définir une émulation de terminal standard (vt100, vt220...) en 8 bits ne résoudra pas le problème. Ce que vous obtiendrez sera inutilisable. En conséquence, comme il s'agit d'un "vieux" produit, nous utilisons un "vieux" logiciel spécifique d'émulation de terminal.
Après une longue bataille pour trouver la bonne émulation, vous trouvez que "ibm3151", par exemple, offre le meilleur compromis. Jusque là, ça va !
Mais, ce logiciel a été développé voici de nombreuses années, et la sécurité... il n'y connaît pas grand chose. La connexion utilise telnet ! Il se trouve que les données transférées sont confidentielles... Alors quoi ? Il faut au moins, trouver un moyen de crypter les données. Et une fois de plus, ssh va nous aider.
Encore une fois, There Is More Than One Way to Do It...
Soit vous redirigez telnet vers le port 22 (ssh), soit vous redirigez le port de l'émulation de terminal. Mais... j'ai bien peur que le serveur n'accepte pas qu'un simple utilisateur redirige le port telnet (23 par défaut) : vous devez être root pour cela (du moins, je l'espère !). Concernant l'émulation de terminal, elle peut être utilisée par plusieurs utilisateurs simultanément, nécessitant ainsi un port différent pour chaque connexion, soit 10 utilisateurs=10 ports.
Ca devient un peu plus "coton", n'est-il pas ?
Bien, tout d'abord, le serveur d'application doit avoir un serveur ssh en service à l'écoute du port 22.
Depuis un client NT, connectez-vous au serveur d'application soit avec Ttssh, soit par la "ligne de commande". Autrement dit, vous établissez une connexion sécurisée entre le serveur et le client en tant qu'utilisateur spécifique. A partir du panneau options de Ttssh, vous redirigez le port local 50000 vers le port 23 (telnet) du serveur distant. A partir de la ligne de commande, ce serait "ssh-L50000:servername:23". Maintenant, vous pouvez demander à l'émulation de terminal d'utiliser le port 50000 à la place du port 23. Les données circulent maintenant par un canal sécurisé, ce qui signifie crypté. Vous pouvez vérifier avec snoop ou tcpdump.
De toute évidence, vous devrez faire de même pour chaque client autorisé à se connecter à l'application en changeant le numéro du port redirigé. Par exemple, vous pouvez utiliser 50001, 50002, etc.
Vous pourriez demander : pourquoi des ports si élevés ? La réponse est : pour plusieurs raisons !
Sérieusement, la raison première concerne la possibilité de "manipuler" des ports élevés sans être root.
La seconde raison est que le port sélectionné ne doit pas déjà être en service sur l'une ou l'autre des machines. Par exemple, si le serveur fonctionne sous Solaris, de nombreux ports élevés sont utilisés en fonction des services actifs. Ainsi, le port 50000 et les suivants devraient fonctionner. En clair, vous devrez vérifier les ports en service avant la redirection.
Bien sûr, cela fonctionnera pour de nombreuw OS capables d'utiliser des clients ssh.
Pour ce qui concerne la manière d'automatiser le processus sur les machines clientes, c'est à vous de voir. Vous ne pouvez pas demander à un utilisateur "normal" de faire tout ça avant de se connecter, n'est-ce pas ? Nous laissons donc cela comme un exercice pour les lecteurs...

A partir de là, où allons-nous ?

Ces quelques exemples montrent les usages multiples de ssh. Vous pouvez faire encore plus avec de nombreuses applications et ssh. C'est fonction de vos besoins. Toutefois, la "philosophie" est presque toujours la même : la redirection de port.
Pourtant, soyez prudents avec des redirections plus complexes. Par exemple si vous redirigez par l'intermédiaire d'une troisième machine, les données circulant par la connexion du milieu ne seront pas cryptées.
Un autre inconvénient concerne les clients Windos utilisant Ttssh. La connexion vers les ports redirigés repose sur les adresses IP, comme pour les "remote commands", permettant ainsi des attaques de "spoofing". D'où la nécessité d'utiliser d'autres outils en plus de ssh, tels que les tcpwrappers.
Epluchez la "littérature" sur ssh, elle vous apprendra beaucoup. Votre imagination fera le reste.

Enfin, c'est fini !

La sécurité devrait être la préoccupation de chacun, mais ce n'est pas le cas ! ssh n'est que l'un des outils à utiliser au quotidien. Il est très bon tant que vous le considérez pour ce qu'il est, c'est-à-dire un outil de cryptage ou de compression.
Tout seul, ssh est presque inutile puisqu'il ne comblera pas les nombreux "trous" que vous pouvez avoir sur une machine ou un réseau. Sécuriser une machine, un réseau, est une lourde tâche et les outils ne font pas tout, même s'ils sont très efficaces.
Les opérations basiques sont obligatoires lorsqu'il s'agit de sécurité. N'oubliez pas d'enlever tous les services non utilisés, de vérifier les programmes SUID root, de désactiver les applications à risque... Il y a beaucoup à faire et ce ne sera jamais assez. Vous pouvez installer tous les outils de sécurité disponibles, ce sera inutile si vous laissez une ou plusieurs "portes de derrière" ouvertes en grand. Certes, c'est une autre histoire, mais ne vous voilez pas la face.
Pour en revenir à ssh, c'est un outil indispensable tant que vous l'utilisez correctement et pour ce pour quoi il a été fait. Encore une fois, utilisez-le avec des passphrases, des clés RSA, mais pas avec des mots de passe. Vérifiez les permissions des différents fichiers dans le répertoire .ssh et bien sûr les permissions du répertoire lui-même. Et, encore et toujours, utilisez, au moins, les tcpwrappers !
Toutefois, rappelez-vous, la plupart des protocoles existants peuvent être transmis par le tunnel ssh. C'est très utile pour rendre les communications un peu plus sûres.
Il existe un autre usage répandu de ssh dont nous n'avons pas parlé, la redirection de session X. Puisque ça implique d'avoir X sous différents OS, nous l'avons intentionnellement laissé de côté. Pourtant c'est bien dans le cadre du "tunneling" de protocole. X n'étant pas un modèle de sécurité, ssh peut bien améliorer les choses.
Pour des usages plus sophistiqués, ssh ne suffira pas. Comme nous l'avons déjà mentionné, penchez-vous sur VPN ou des outils tels que VTun, ils seront probablement plus adaptés.
Enfin, renseignez-vous bien sur la situation de la cryptographie dans votre propre pays. Ce serait quand même triste de finir en prison pour espionnage simplement pour avoir utilisé un logiciel non autorisé.
C'est comme ça...
N'empêche, on vit une époque formidable !  

Discussion sur cet article

2001-04-28, generated by lfparser version 2.12

mirror server hosted at Truenetwork, Russian Federation.