Nopping

Aujourd’hui je vais vous parler un peu des tunnels SSH parce que ça peu être fort pratique et que j’ai eu l’occasion d’en mettre en place hier pour sauvegarder mon droit de glander.

Qu’est-ce que c’est SSH ?

Avant de commencer il faut savoir ce qu’est SSH et surtout il faut accès à un serveur. Il s’agit d’un protocole informatique nommé “Secure SHell”, son rôle est de permettre d’obtenir un shell à distance, exactement comme telnet, mais sécurisé (contrairement à à ce fameux telnet). Qui dit protocole dit client et serveur. Sous Unix il y à OpenSSH qui fournit les deux outils (et bien d’autres), le client est nommé “ssh” et le serveur “sshd”. Sous Windows il n’y à pas de serveur, en même temps il n’y a pas de shell (si on oublie cette vaste blague qu’est l’invite de commande et le machin nommé PowerShell, bien que ce dernier peut être utile et bien dépanner). Par contre on trouve des client tels que putty.

Jusqu’ici, pas trop de problème. C’est fort pratique, puisque ca nous permet de prendre la main sur un système Unix de manière sécurisée. Les Unix étant totalement contrôlables en mode console, on obtient un contrôle quasiment identique à celui qu’on à quand on est assis devant la machine. Un serveur SSH devient un impératif sur un serveur, en effet, rare sont les serveurs pourvus d’interface graphique, ou même tout simplement d’écrans, sans compter qu’ils sont généralement placé dans des endroits auxquels on à pas ou peu accès. Par exemple, si vous faites héberger votre site web par un tiers, vous n’avez pas d’accès physique au serveur, un accès SSH devient du coup très intéressant.

Pour plus d’informations sur le sujet, je vous convie à faire quelques recherches ou ne serait-ce que lire la page Wikipedia.

Tunnel SSH

Maintenant que vous savez à peu près ce qu’est SSH, parlons des tunnels. Le principe est de se servir de la connexion SSH pour faire transiter une autre connexion. En pratique, le client SSH ouvre un port en local et se place en écoute dessus, toute donnée qui y sera envoyé sera alors encapsulée dans la connexion SSH, envoyée au serveur, qui à son tour l’enverra vers la destination choisie. Par exemple, je peux choisir de créer un tunnel entre le port 21 du client et le port 21 du serveur. Ainsi, si le client se connecte à l’adresse ftp://localhost, la connexion passera en réalité par le serveur SSH, et localhost devient alors le serveur SSH.

Histoire d’être un peu plus clair, prenons un exemple :

Nous disposons d’une machine serveur qui tourne sous Linux, son adresse est srv.exemple.com. Elle héberge les services suivants :

• - un serveur SSH sur le port 22 disponible depuis l’extérieur.
• - un serveur HTTP sur le port 80 disponible depuis l’extérieur.
• - un serveur HTTP sur le port 8080 disponible uniquement depuis sont réseau local.

Prenons maintenant une machine extérieur, peu importe sa configuration, elle est pourvue d’un client SSH.

Depuis cette machine, si je tape http://srv.exemple.com dans la barre d’adresse du navigateur, j’atteindrai le serveur HTTP qui tourne sur le port 80 de la machin srv.exemple.com, jusque là tout est normal.

Par contre, si je tente d’aller sur la page http://srv.exemple.com:8080, la connexion sera refusée par le serveur.

Cependant, vu que je dispose d’un accès SSH, je peux créer un tunnel du port local 8080 vers le port distant 8080. Ainsi, en me connectant à l’adresse http://localhost:8080, la connexion sera tunnelisée via SSH et atteindra bien le serveur HTTP présent sur le port 8080 de la machine srv.exemple.com. De plus, ce serveur HTTP pensera que la connexion provient de localhost (et donc de srv.exemple.com), et non pas de votre machine.

Via cet exemple, on commence à voir quelques applications possibles et fort pratiques des tunnels SSH. On peut par exemple configurer netfilter pour interdire l’accès extérieur à un service et cependant l’autoriser via un tunnel SSH.

Par exemple, si le serveur héberge un service dont la sécurité laisse à désirer comme telnet qui fait passer les identifiants en clair, on peut interdire l’accès extérieur à ce service via netfilter, ensuite, via un tunnel SSH on peut tout de même y accéder de l’extérieur, cependant la connexion sera entièrement chiffrée ce qui corrige le défaut de telnet.

Contourner des filtrages

Pour aller plus loin, on peut utiliser les tunnels SSH pour contourner des filtrages. C’est d’ailleurs pour ça que j’ai été amené à m’en servir hier.

Quand je suis au boulot, j’aime bien être connecté à MSN, certains prennent des pauses café, d’autres des pauses clopes, d’autres jouent les pipelettes au détour d’un couloir et certains cumulent. Moi je ne fais rien de tout ca, je préfère causer un peu avec mes amis. De plus, je suis programmeur et j’ai dans mes contactes de nombreux informaticiens, parfois quand j’ai un problème il est plus rapide/facile de demander sur MSN que de chercher sur la toile.

Bref, jusqu’ici MSN n’était pas vraiment filtré au boulot. En réalité il l’était mais MSN peut passer par une passerelle HTTP en cas de problème, c’est ainsi qu’il fonctionnait chez moi. Seulement voila, du jour au lendemain, impossible de me connecter.

J’ai d’abord cru à un problème du réseau MSN, ce n’aurait pas été une première. Cependant en rentrant chez moi, MSN fonctionnait bien.

Le problème est en fait qu’un filtrage DNS + filtrage de contenu à été mis en place par l’admin réseau. J’ai donc cherché à détourner ce problème. J’ai accès à mon serveur et il ne sera pas filtré à ma demande. En effet, j’avais prévenu l’admin réseau que pour faire mon boulot il est parfois pratique que j’ai accès à un Linux, qui plus est de l’extérieur. En conséquence, je le sais protégé de tout filtrage. J’ai donc mis en place un tunnel SSH du port 80 local vers le port 80 de l’adresse gateway.messenger.hotmail.com.

L’adresse de destination n’est évidemment pas choisie au hasard, elle est tirée de ce document.

Voila quelque chose dont je n’avais pas parlé plus haut, l’adresse de destination du tunnel n’est pas obligatoirement le serveur SSH. Vous pouvez mettre n’importe quelle adresse qui sera accessible pour le serveur SSH. En réalité, le serveur SSH agit comme un proxy.

Seulement voila, ce n’est pas suffisant pour faire fonctionner MSN puisque celui-ci va se connecter à gateway.messenger.hotmail.com sans passer par le tunnel. Pour qu’il passe par le tunnel il faudrait que l’adresse qu’il contacte soit localhost.

Rien de plus facile, un petit tour dans votre fichier host (sous Windows il est dans “C:\Windows\System32\drivers\etc\hosts”, sous Linux il est dans “/etc/hosts”) et on ajoute un alias gateway.messenger.hotmail.com à l’adresse 127.0.0.1.

Et voila, le tour est joué. Quand je me connecte à MSN, celui-ci tente de se connecter de manière traditionnelle, il échoue à cause du filtrage, il tente donc de se connecter via la passerelle gateway.messenger.hotmail.com. Mais cette adresse est résolue en 127.0.0.1 grâce au fichier host, en conséquence il se connecte à mon tunnel SSH, qui fait suivre la connexion vers la véritable passerelle.

Conclusion

Les tunnels SSH sont donc très pratiques pour sécuriser une connexion qui ne l’était pas et contourner des mesures de filtrage dans certains cas, ou accéder à un service privé. Attention cependant, ce qui est sécurisé c’est la partie qui sépare votre machine du serveur SSH, dans mon cas il s’agit du réseau de mon entreprise. Ca n’est donc absolument pas utile de créer un tunnel vers un serveur SSH situé dans votre réseau local. Dans mon cas je ne gère pas le réseau de mon entreprise, ce que je fais dessus peut donc être espionné par l’admin. Le tunnel permet de cacher cela, l’admin peut toujours voir le trafic, mais celui-ci est chiffré et les destinataires sont invisibles (il ne voit en destinataire que le serveur SSH).