![[Photo of the Author]](../../common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to fr Georges Tarbouriech
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.
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 !
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.
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.
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 !!!
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...
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.
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 !