Forums d'entraide informatique - Astuces - Conseils

Stunnel : tunneliser
ses communications
La plupart des protocoles de communication ne sont pas sécurisés. Entendez par là qu'une personne faisant usage d'un simple logiciel de "sniffing" peut lire en clair toutes les informations qui circulent entre vous et un serveur. Les logiciels de ce type sont très courants, aussi bien pour GNU/Linux que pour les autres Unix, et même Windows et MacOS. Ils représentent un véritable danger dans certaines circonstances.
Le cas le plus à risque est sans nul doute celui lorsque vous vous connectez depuis un poste d'un réseau local à votre serveur Internet. En effet, dans ce cas, n'importe quel utilisateur du réseau local peut écouter sans la moindre difficulté tout ce que vous envoyez et recevez. Ce genre de manipulation est également possible dans d'autres circonstances, mais avec davantage de difficulté pour "l'espion".
Exemple concret
Nous l'avons dit, le nombre d'utilitaires capables d'écouter un réseau sont légion. Mais ne vous y trompez pas, il ne s'agit pas seulement de logiciels pour pirates en herbe. Ces utilitaires vous permet- tront d'administrer votre réseau et d'analyser les informations qui y circulent afin de corriger les pro- blèmes et de sécuriser ce qui doit l'être.
L'utilitaire d'administration de ce type le plus cou- rant, et sans doute installé par défaut sur votre sys- tème, est tcpcump. Il s'agit d'un réel outil d'adminis- tration, et même si son utilisation peut paraître complexe, sa puissance est indéniable. Ne vous fiez pas à l'apparence des données qu'il affiche, tcpdump n'est qu'un exemple. Bon nombre d'utilitaires sont beaucoup plus conviviaux (en particulier sous Windows), et permettent à des personnes n'ayant quasiment aucune connaissance des réseaux de récupérer vos logins et mots de passe.
Voici un exemple de ce que peut faire tcpalump. Nous avons en présence l'hôte egon sur lequel rési- de un serveur FTP et morgane, notre machine clien- te pour le FTP. Ici, les deux machines sont sur le LAN, mais si le serveur FTP se trouvait sur Internet, nous obtiendrions le même résultat puisque les connexions des machines du LAN vers
Internet "diffusent" sur tout le réseau local.
Sur morgane, l'utilisateur moi se connecte légitime- ment sur le serveur FTP egon :
Connected to egon.
220 ProFTPD 1.2.0prel0 Server (Debian) [egon]
Name (egon:denis): moi
331 Password required for moi.
Password:
230-Welcome, archive user moi@morgane !
230-
230-The local time is: Wed Jan 23 11:04:09 2002 230-
230-This is an experimental FTP server. If have any unusual problems,
230-please report them via e-mail to <root@egon>. 230-
230 User moi logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
moi saisit son login et le mot de passe correspondant. Le problème est alors le suivant : ces informations sont envoyées en clair sur le réseau et un utilisateur du LAN pourra les lire en employant :
# tcpdump -X -s 0 dst egon and port 21 and tcp
Il demande à tcpdump d'afficher les données circulant sur le réseau à destination d'egon, notre serveur FTP (dst egon), sur le port 21 (port 21) et en TCP. Le résultat est édifiant. Parmi les données affichées, on trouve :

apparaître les logins et mots de passe pour le mail 080a 09a3 9f22 (POP), le FTP, mais aussi pour l'authentification
HTTP sur un serveur Web. Et encore, il s'agit là 6f69 Od0a d'un utilitaire GNU/Linux, mais des équivalents colorés et simplistes existent pour bien des plates- formes.
...3....G.v...a.
0x0020    8018 16d0 ea45 0000 0101
0x0030    0043 40f4 5553 4552 206d
.C@.USER.moi.
E.. .1
.CG.PASS.morgane 0x0040    Od0a
Pour peu que l'on connaisse vaguement les com- mandes FTP ou que l'on soit un tantinet observa- teur, on arrive vite à déduire que le login est moi et le mot de passe morgane. Voilà comment un utilisa- teur du LAN peut connaître votre mot de passe sur un serveur FTP. Mais cela ne s'arrête pas là, ceci est applicable à beaucoup d'autres protocoles comme l'authentification HTTP, la récupération de mail en POP ou IMAP. les connexions en shell distant non sécurisé (rlogin. telnet, rsh) et bien d'autres encore...
De plus, tcpdump n'est pas le plus aisé des utilitaires de sniffing, ni le plus clair. Pour un débutant, des logi- ciels comme dsniff sont encore bien plus parlants :
10/01/02 23:20:34 tcp 192.168.0.24.1378 -> 200.198.239.142.21 (ftp)
USER anonymous
PASS moi@kkpart.fr
[...,
16/01/01 09:38:34 tcp 192.168.0.10.1029 -> 192.168.0.51.110 (pop)
user moi
pass morgane
18/09/01 10:07:37 tcp 192.168.0.21.1064 -> 288.14.67.192.80 (httP)
CET /gest/ HTTP/1.1 Host: www.kkoart.fr
Authorizat-: : Basic J56kfldj566jkkdJD1RYMxs9 [monlogin:motdepassj
dsniff est spécialisé dans l'analyse des transactions et affiche directement les informations que l'utilisa- teur "epson" recherche. On voit alors clairement
La solution : le tunneling
Vous ne pouvez changer les protocoles et, même dans ce cas, vous rendriez votre configuration com- plètement propriétaire, opaque et surtotit incompa- tible avec le reste crInternet. La solution consiste donc à ne pas contacter directement votre serveur depuis un environnement que vous ne contrôlez pas totalement.
Puisqu'une connexion directe entre unie machine et votre serveur est "écoutable". fl suffit de prendre ses informations, transitant au regard de tous, et de les enfermer à l'intérieur d'une communication qui, elle, est illisible, si ce n'est pas vous et le serveur. Cette technique est appelée tunneling. On crée un tun- nel de communication entre deux machines. A l'inté- rieur du tunnel, les données peuvent circuler en toute sécurité. En revanche, les données perçues de l'exté- rieur du tunnel sont indéchiffrables car cryptées.
Ce genre de tunnel est très facilement réalisable avec un utilitaire appelé s'urane'. Celui-ci utilise SSL afin de protéger les informations circulant dans le tunnel. Son installation sur une distribution Debian se fera d'un simple
R apt-get instal1 stunnel
Le système aptIcipkg installera automatiquement les bibliothèques et packages nécessaires au fonction- nement de l'utilitaire en même temps que ce dernier. Vous remarquerez également un message indiquant que le script d'installation a besoin d'un grand nombre de données aléatoires et qu'il est conseillé de lancer un f ind / pour créer de l'activité système
Paramétrage de stunnel (3.10-Opotatol)
I need to gather some amount of random data to create
a secure setup for you. If this is going to take too long
try to add entrophy to your system (for example typing at the
keyboard or creating disk activity with a 'find /' command...).
0+2 enregistrements lus.
1+1 enregistrements écrits.

Cette masse de données aléatoires est nécessaire pour la création d'un fichier de clefs permettant de sécuriser la transaction. Ces clefs seront placées
dans/etc/ssl/certs/stunnel.pem.
La figure 1 montre le principe de fonctionnement de stunnel en complément d'un client mail se connectant à un serveur POP. En rouge est illustré le fonctionnement normal d'une connexion : le client mail (MUA) contacte le serveur sur le port 110 (celui du serveur POP).
Avec stunnel, nous n'établissons plus de connexion directe du client vers le serveur. Le client mail se connectera au port POP sur la machine locale (en vert). stunnel sera à l'écoute sur ce port et utilisera ces données qu'il va chiffrer et envoyer au démon stunnel du serveur. Sur ce dernier, les données seront déchiffrées et envoyées sur le port 110 (au serveur POP).
En fonctionnant de la sorte, aucune information en clair n'est transmise. Il devient impossible pour un utilisateur espion d'écouter les données, et donc les mots de passe de l'utilisateur relevant ses mails. De plus, comme le tunnel ne passe pas par le port nor- malement utilisé (110), le vilain ne verra rien du tout, pas même une communication qu'il aura bien du mal à analyser et à lire.
La pratique
Nous avons à présent tous les éléments nécessaires à la création d'un tunnel entre notre client et notre serveur. Si nous conservons le cas d'un client mail et d'un serveur POP, nous utiliserons stunnel de la manière suivante :
• Sur le serveur, nous attendons les connexions sécurisées sur le port 14000 (option -d). Celles-ci seront déchiffrées et renvoyées sur le port 110 de l'hôte local (option -r):
[root@egon]/ # stunnel -D 7 -f -d 14000 -r 110
L'option -f demande un fonctionnement en avant- plan et -D 7 un niveau de débogage maximum. Ces deux options sous permettront de suivre le déroule- ment des opérations. Bien sûr, en temps normal, vous ne ferez pas usage de ces deux paramètres et lancerez alors stunnel en mode démon.
Sur la machine cliente, nous procédons de même. Nous définissons que les connexions arrivant sur le port 110 de l'hôte local soient chiffrées SSL, puis envoyées à l'hôte egon sur le port 14000. Nous venons justement de définir sur le serveur que les données sont attendues sur le port en question.
[root@morgane]/ # stunnel -D 6 -f -d 110 -r egon:14000
A présent, lorsque nous souhaiterons contacter de manière sécurisée notre serveur POP sur egon, nous n'aurons qu'à demander à notre client mail de les relever sur l'hôte local et son port 110. stunnel prendra alors le pas et contactera le serveur sur le port 14000. Un éventuel espion écoutant les communications sur le port 110 ne verra rien et quand bien même il écouterait le port 14000, il n'y comprendrait rien.
Ce genre ce mécanisme avec stunnel fonctionne avec presque tous les protocoles. Malheureusement, ce n'est pas le cas du FTP, car la méthode utilisée spé- cifie un tunnel par port. Or. le FTP utilise générale- ment plusieurs ports et de ce fait, si la transaction semble bien débuter, elle mène rapidement à un échec et un gel du client.
D'autres utilitaires du type stunnel existent, comme SSLwrap par exemple, mais le même problème se pose avec le FTP. Dans ce genre de situation, mieux vaut se tourner vers des logiciels serveurs et clients FTP. qui supportent directement SSL. Enfin, pour conclure, signalons qu'il existe une version Windows de stunnel qui s'utilise de manière similaire. Vous pourrez ainsi vous connecter de manière sécurisée depuis un ordinateur ne disposant pas du système GNU/Linux. Ceci peut s'avérer très utile lorsque la machine client est celle de votre lieu de travail et que l'installation de notre cher OS n'est pas possible.