Concrétisons Nos Idées

JAH-12 – Du contournement d'un serveur mandataire HTTP

Rédigé par Samaël - -

Journal de bord du capitaine :
Date : 04 avril 2012
Lieu : Perdu dans le cyber espace

Il arrive que l'on se retrouve en "milieu hostile" avec un accès restreint vers l'extérieur et une surveillance de tout ce qui circule sur le réseau local auquel on est rattaché. Or on peut parfois avoir le besoin, ou tout simplement l'envie, de faire tomber ces barrières. Attention ! Il convient d'être prudent, si ces mesures de protection ont été mises en place par les administrateurs du réseau que vous utilisez c'est probablement pour de bonnes raisons. Les contourner se fera à vos risques et périls et représentera le plus souvent une rupture de la charte que vous vous êtes engagé à respecter lorsqu'on vous a donné vos accès au réseau.

Mes besoins étaient les suivants :

  • Utiliser des applications nécessitant l'accès à d'autres ports distants que les classiques 80 et 443.
  • Utiliser d'autres protocoles que HTTP et HTTPS.
  • Naviguer sur le web sans restriction.
  • Naviguer sur le web en toute confidentialité.

Mon but était donc d'utiliser un tunnel HTTP pour faire passer une connexion SSH vers mon serveur personnel et utiliser cette connexion SSH pour faire transiter toutes mes requêtes vers l'extérieur via mon serveur. Ainsi la connexion entre mon bureau et mon serveur serait chiffrée ce qui empêcherait l'espionnage et les restrictions. Le principe d'un tunnel HTTP est d'encapsuler des paquets d'un protocole différent dans des paquets HTTP. Dans la pratique, j'allais devoir me connecter au serveur mandataire de mon entreprise en lui envoyant des paquets de type HTTP, à destination d'une adresse et d'un port qu'il autorisait, dont le contenu contiendrait de quoi ouvrir une connexion SSH.

La première chose à faire était de récupérer des informations sur mon "ennemi" ("Know your foe" comme disent ces chers anglophones), pour cela j'ai simplement regardé la configuration de mon navigateur internet. J'ai alors pu constater que la configuration du navigateur pour accéder à internet via le serveur mandataire utilisait un fichier d'auto-configuration (extension "pac"). Ayant l'adresse de ce fichier je l'ai simplement récupéré via mon navigateur. Il contenait tout un tas de règles pour utiliser tel ou tel serveur mandataire selon le domaine auquel on souhaitait accéder (pour tout les services intranet) et, à la fin, l'adresse (et le port) du serveur servant à toutes les requêtes vers l'extérieur.

En l'occurrence l'adresse désignait un ensemble de machine sur lesquelles étaient reparties l'ensemble des requêtes, ce qui signifie que ma connexion sortante n'avait pas la même adresse à chacune de mes requêtes. Cela a son importance, car de ce fait je ne pouvais pas programmer une règle sur mon serveur du type : "rediriger toutes les connexions venant de cette adresse IP vers tel port".

Sur mon serveur personnel, il me fallait mettre en place un serveur SSH qui écoute sur un des ports autorisés par le mandataire. En général, on utilise le port 443 car c'est celui du protocole HTTPS. Le problème est qu'il n'est, en principe, pas possible que deux applications distinctes écoutent sur le même port de la même interface réseau. Donc si SSH écoutait sur le port 443, apache ne pouvait pas et donc mon site web n'aurait plus été accessible sur ce port. La solution est venue sous la forme du logiciel sslh conçu spécifiquement pour faire cohabiter sur le même port les services SSL et SSH. Techniquement, la seule application qui écoute sur l'interface réseau externe sur le port 443 est sslh qui va avoir pour rôle de détecter la nature de la connexion (SSL ou SSH) et de la transférer sur un autre port et/ou une autre interface réseau.

Une fois sslh installé, il ne se lance pas automatiquement ; il faut modifier le fichier de configuration afin de décider ce qui sera transféré et où. J'ai choisi de ne pas modifier la configuration de mon serveur SSH (en écoute sur toutes les interfaces réseaux sur le port 22) mais d'adapter celle de mon serveur HTTP pour qu'il n'écoute plus que sur l'interface réseau interne (mais toujours sur le même port). Ainsi lorsqu'une connexion extérieure arrive sur le port 443, sslh va la rediriger vers l'interface interne sur le port 22 dans le cas d'une connexion SSH et vers le port 443 dans le cas d'une connexion SSL. L'aide de sslh, ainsi que les nombreux exemples disponibles sur internet m'ont permis de configurer correctement, dès la première tentative, sslh et apache [1] .

Une fois mon serveur prêt et les informations essentielles sur le mandataire récupérées, il n'y avait plus qu'à tester. Travaillant sous Microsoft Windows XP, j'ai dû commencer par installer un client SSH (et oui malgré la taille gargantuesque de leurs systèmes d'exploitation, Microsoft n'inclut toujours pas de client SSH); j'ai donc opté pour le célèbre PuTTY.

Pour se connecter, rien de plus simple: je rentre le nom de mon serveur et le port cible (en l'occurrence 443) puis je vais dans la section Connexion->Proxy, sélectionne HTTP, et rentre le nom du mandataire et le port cible. PuTTY va empaqueter les informations pour la connexion SSH dans des paquets HTTP, le mandataire, n'y voyant pas d'objection, va laisser passer le paquet vers sa destination finale. Là, sslh détecte qu'il s'agit d'une demande de connexion SSH et va transférer le paquet sur le port d'écoute du serveur SSH. PuTTY ouvre alors un terminal demandant le login puis le mot de passe, une fois les identifiants acceptés la connexion SSH est établie. J'ai ainsi accès, via mon serveur, au monde extérieur sans surveillance, ni restriction d'aucune sorte. Les paquets transitant par le mandataire ne contenant que du contenu chiffré, l'ingérence est donc impossible.

À cet instant, je n'avais accès qu'à un terminal sur mon serveur, or ce dont j'avais besoin c'est que des applications puissent utiliser ce tunnel pour se connecter à des serveurs distants. La solution la plus simple : utiliser un serveur mandataire SOCKS. Le principe était de créer un mandataire qui écoutait sur un port local et faisait transiter les paquets qui lui étaient envoyés, via ma connexion SSH, vers l'extérieur. Bien sûr, la connexion était bidirectionnelle, les réponses des serveurs contactés par mes applications utilisant le tunnel étaient envoyées à mon serveur qui via le mandataire SOCKS les renvoyait aux applications demanderesses.

PuTTY sait très bien gérer la création de mandataire SOCKS, pour cela il suffit, au moment d'entrer les informations de connexion, d'ajouter dans la section Connexion->SSH->Tunnel le numéro du port d'écoute sur la machine locale et cocher Dynamic. Une fois la connexion ouverte, j'ai modifié les paramètres de connexion de mon navigateur en lui indiquant d'utiliser le mandataire de type SOCKS se trouvant sur le port que j'avais défini. Un rapide test, en tentant une connexion à un site normalement bloqué par le mandataire de mon entreprise, m'a montré que mon tunnel fonctionnait bien.

J'ai pu utiliser ce tunnel pour mon navigateur web (Firefox), un logiciel de messagerie instantanée (Pidgin), un logiciel de messagerie (Thunderbird) et un logiciel de musique en streaming (Spotify). Pidgin permettant de configurer chaque compte avec des paramètres réseau distincts cela m'a permis d'utiliser un seul et même client pour ma messagerie instantanée professionnelle et personnelle. En théorie, toutes les applications nécessitant un accès à internet et pouvant se configurer pour utiliser un mandataire SOCKS peuvent être utilisée via ce tunnel, et pour les applications ne gérant pas "nativement" le protocole SOCKS, il existe des programmes permettant de SOCKSifier une application [2]. Dernier point bien pratique, une option permettant d'autoriser les connexions venant de l'extérieur sur mon mandataire m'a permis de dépanner des collègues qui avaient besoin d'accéder à certains serveurs extérieurs normalement bloqués.

Sous GNU/Linux, créer un tel tunnel avec proxy SOCKS n'est pas plus compliqué. Openssh gérant très bien la redirection de port (locaux, distants ou dynamique) il suffit d'utiliser une petite application complémentaire qui va se charger d'encapsuler cette connexion pour le mandataire HTTP. J'ai choisi d'utiliser corkscrew qui se configure en quelques lignes et fait parfaitement son travail. Une fois le tunnel établi, comme sous Windows, il suffit de configurer les applications pour utiliser le mandataire SOCKS précédemment créé.

Un des principaux problèmes de cette solution est la limitation du débit. En effet, dans le cas où le serveur servant à établir le tunnel est relié à internet par une connexion ADSL domestique, le débit montant sera le plus souvent de l'ordre d'une centaine de kibioctet tout au plus. Pour de la navigation web, du streaming musical (en faible qualité) et de la messagerie instantanée cela suffit amplement ; mais pour tout autre type d'application, tel que le téléchargement de fichiers volumineux, cela peut vite devenir extrêmement long.

Autre point à bien comprendre : les connexions ne sont chiffrées qu'entre le client et le serveur de destination du tunnel. Une fois sorties de ce relais, les informations ne seront pas systématiquement chiffrées. Tout se passera exactement comme si les applications tournaient nativement sur le serveur relais; d'un point de vue extérieur c'est donc l'adresse IP du serveur relais qui sera vue.

Conclusions :

  • Mettre en place un tunnel est somme toute assez simple une fois que l'on a identifié les outils nécessaires pour répondre à nos besoins.
  • Il faut être bien conscient de ses responsabilités lorsque l'on contourne de tels systèmes de protection, on créé une brèche dans la sécurité qui, si elle était exploitée à des fins malhonnêtes, pourrait s'avérer catastrophique.
  • Toute prison à ses tunnels vers l'extérieur. :-)

Prochaine entrée dans le journal : De la gestion des certificats SSL

Notes

[1] J'ai depuis modifié ma configuration suite à des conflits et des instabilités dans cette configuration. Apache écoute maintenant sur le port 444 en local et tout va bien.

[2] Toutes les tentatives de connexions sortantes d'une application sont interceptées par un programme tiers qui se charge de les rediriger vers le mandataire SOCKS.

#1 Pouet a dit :

Hello,

C'est une pratique qu'il faut éviter, sauf si besoin 'impérieux" (c'est subjectif, mais bon...) et très ponctuel (ça permet d'être "noyé" dans les flux) car une entreprise n'hésitera absolument pas à anéantir ces comportements en filtrant la couche 7 si besoin, la différence entre SSL et SSH pouvant être facilement identifiée.
Dans le pire des cas, il restera de l'encapsulage cradingue (du ssh dans du http/https, avec le logiciel httptunnel) et pour la différence, si tu as un vrai routeur, pas un machinbox, tu peux toujours te faire des petites règles iptables pas très jojo non plus pour faire du port forwarding d'une source particulière vers ce qu'il faut.

Ce n'est pas les [vilaines] solutions manquent, c'est juste qu'à force de vouloir faire autre chose que ce qui est sage et/ou prévu on arrive à des aberrations.

#2 tranxene50 a dit :

Hello !

Juste un petit mot pour te dire que je suis avec une grande "inattention" tes péripéties.

En clair, comprendre que je n'ai pas lu mais que les bookmarks sont là pour me rappeler que, lorsque j'aurais un peu de temps, il serait bon de me plonger dans tes écrits. :)

Bref, tout ça pour dire que, mine de rien, je fais partie de la majorité silencieuse.

Mais fais gaffe, on est nombreux ! ^^

A+

Les commentaires sont fermés.