Lorsque l'on est amené à bosser chez un client, il est très rare d'avoir accès au net autrement qu'à travers un proxy type Squid . Le problème avec cette situation et que l'on expose ainsi nos données à des regards indiscrets. Le but de ce tutoriel est donc de vous proposer une solution pour palier à cela.

Un proxy ?

D'un point de vue général un proxy est un bout de logiciel qui va recevoir vos demandes réseau et les retransmettre, après un éventuel traitement, à qui de droit. Il existe de nombreux types de proxy mais en entreprise il s'agit très souvent d'un proxy type HTTP . Le principe est que chaque requête HTTP est envoyé par le navigateur au serveur Proxy qui va tout d'abord en examiner la légitimité et renvoyer une erreur si l'on cherche à atteindre une URL interdite. Ensuite le proxy va effectuer la vraie requête vers l'URL demandée et recevoir la page résultat. Généralement, et c'est le second rôle d'un tel proxy, cette page va être stockée en local sur le disque du serveur, avec tous les fichiers associés (feuilles de style, images, etc.). Le proxy va enfin renvoyer la page stockée en local au navigateur.

Ainsi un proxy permet à une entreprise de limiter l'utilisation d'Internet au seul WEB, de filtrer les accès pour ne pas autoriser les sites n'étant pas en rapport avec le travail (blog, sites de jeu et j'en passe), enfin réduire les besoins en bande passante stockant une copie des pages en local.

Maintenant, d'un point de vue "utilisateur" cette approche a l'inconvénient de ses avantages. On ne peut aller où l'on veut. On ne peut utiliser autre chose que le WEB (IRC, Messagerie instantanée, etc.), et surtout, l'ensemble des pages visitées, des mots de passe utilisés est tracé et stocké.

Accès sécurisé

Fort heureusement, il existe une parade à cette approche : l'accès au WEB sécurisé via HTTPS . En effet, il est rare que ce mode de connexion à la toile soit bloquée tant cela deviendrait contraignant pour l'utilisateur (aucun accès à une zone abonnée chez un éditeur, à une banque, etc.). Or le HTTPS est absolument impossible à filtrer par le proxy d'entreprise dans la mesure où toutes les données circulent d'un un tuyau crypté dont la clef de décodage n'est partagée qu'entre vous et votre serveur cible. Ceci dit il est toujours possible de créer un proxy qui vous fasse croire que vous êtes en communication sécurisée avec votre serveur mais je n'ai pas entendu parler d'une telle implémentation en standard.

Ainsi donc, dés que vous accédez à un site en HTTPS, le proxy devient aveugle, il ne stocke plus les pages en local, ne voit plus les mots de passe, mais il peut toujours voir les URL. De plus, tous les sites auquel nous voudrions accéder n'ont pas forcement un accès HTTPS de disponible. Pour exploiter cela nous avons plusieurs possibilités.

PhpProxy

Techniquement, une méthode qui permettrait de court-circuiter totalement un proxy serait de passer par un service type anonymizer. En effet, ce type de site est accessible en HTTPS et permet dans une zone de la page de rentrer l'URL "interdite". Ces sites fonctionnent comme notre proxy d'entreprise et vont chercher, eux-mêmes les données, pour les renvoyer sur leur propre page.

Si cette méthode marche pour vous, c'est parfait, d'autant plus qu'il existe de nombreux site du même genre, il suffit de demander cela à google. Cependant cette approche pose deux problèmes. Le premier est que les administrateurs de votre proxy d'entreprise ne sont pas idiots et ont sûrement la liste exhaustive des services publiques d’anonymisations indiquées comme URL interdites dans le proxy. Et si ce n'est pas le cas, l'autre soucis est que si ce n'est plus l'entreprise qui peut voir où vous aller, ce site dont vous ne savez rien, lui, le peux.

La solution ultime consiste donc à monter son propre service d'anonymisation. Pour cela deux pré requis : disposer d'un serveur WEB équipé de PHP accessible d'une IP publique et que ce serveur soit accessible en HTTPS. Le cas échéant, vous pouvez utiliser votre propre ligne Internet personnel en installant chez vous un serveur Apache/PHP et en utilisant un service du genre de celui que propose dynDNS. Pour ce qui suit, je pars du principe que vous avez la main sur un serveur unix avec apache, https (mod_ssl) et PHP correctement installés.

La marche à suivre est très simple. Tout d'abord télécharger phpProxy. Décompressez le dans le dossier de votre choix (ex. /documents/web/phpProxy). Ensuite, ajoutez à la configuration du vhost https quelque chose du genre : Alias /farfelu /documents/web/phpProxy SSLRequireSSL Options Indexes FollowSymLinks MultiViews IncludesNoExec AddOutputFilter Includes html AllowOverride All AuthType Basic AuthName "Accès à Farfelu" AuthUserFile /usr/local/apache/passwd/passwords Require valid user

Les points important ici sont que nous créons un alias /farfelu car il ne serait pas très malin que l'URL d'accès à votre proxy soit /mon_proxy . Ensuite le SSLRequireSSL qui oblige l'utilisateur de cette URL à passer par HTTPS. Enfin, trèèèèès important, ajoutez un identifiant/mot de passe sur cette URL si vous ne voulez pas que quelqu'un tombant dessus par hasard, puisse utiliser votre proxy à votre insu pour faire des choses répréhensibles. Si vous êtes un peu paumé avec ces options, vous pouvez faire un tour ici.

Une fois qu'apache a été redémarré, il ne reste plus qu'à tester notre URL https://mon_serveur_publique/farfelu. Si tout fonctionne correctement, vous devriez obtenir quelque chose conforme à l'illustration.

Après l'utilisation est relativement intuitive, plusieurs options permettent de modifier le comportement du proxy comme la possibilité de supprimer les JavaScript, gérer les coockies, etc.

Utilisez la commande CONNECT

HTTPS implique une connexion directe entre vous et le serveur cible. Pour que cela puisse fonctionner, existe une commande CONNECT dans la norme du protocole HTTP. Cette commande indique au proxy que l'on désire établir une connexion directe avec la cible, en se passant de ces services. Autant dire qu'il s'agit là d'un magnifique trou dans lequel il est possible de s'engouffrer.

Dans la norme HTTP, rien n'interdit de donner le port de son choix à la commande CONNECT. De fait il devrait donc être possible de se connecter, via cette "faille", à un serveur distant SSH, écoutant classiquement le port 22. Cependant ce n'est pas aussi simple. Pour limiter la casse, les proxy interdisent généralement une commande CONNECT qui chercherait à atteindre un port autre que le 443, qui est le port "officiel" d'HTTPS. La conséquence pour vous, est que pour exploiter cette "faille", il faut obligatoirement que votre serveur SSH soit en écoute du port 443, rendant du coup l'utilisation de cette astuce incompatible avec l'utilisation conjointe d'un Apache en HTTPS. Si vous n'avez pas ce problème, nous pouvons poursuivre.

Mettre un ssh en écoute sur le port 443 ne pose aucun problème en soit. Il suffit pour cela de modifier le fichier de configuration /etc/sshd_config et d'y placer ou modifier le paramètre Port 443. Après redémarrage, un netstat -anlo | grep 443 nous confirme bien que SSH est en écoute sur le port HTTPS.

Vous pouvez aussi doubler les ports en écoute par le serveur SSH en utilisation xinetd. Après l'avoir installé, il faut désactiver le service sshd (par un chkconfig -del sshd) . Ensuite vous allez modifier /etc/xinetd.d/sshd-xinetd de sorte à avoir un disabled=no. L'étape suivant consiste à simplement dupliquer ce fichier dans le même répertoire sous le nom sshd-xinetd-https et l'éditez pour changer la ligne service ssh en service ssh-https. Enfin, indiquez le port de connexion de ce nouveau service en éditant le fichier /etc/services et ajoutant à la fin ssh-https 443/tcp. Un petit redémarrage de xinetd cette fois et ssh devrait être accessible des deux ports 22 et 443.

Maintenant, pour se connecter à travers un proxy HTTP, sur un serveur Serveur SSH, nous avons besoin d'un client capable de causer avec le proxy et donc de générer cette fameuse commande CONNECT. Pour Windows, rien de plus simple, il suffit pour cela d'utiliser PuTTY. On prendra alors soin, dans le paramétrage de la connection, à la section proxy, de bien sélectionner HTTP, ainsi qu'indiquer l'adresse et le port du dit proxy.

Ensuite, dans les coordonnées du serveur cible, il faut bien sur renseigner le nom ou l'IP du serveur cible, et surtout changer le port pour utiliser le 443. Sauvegardez la connexion et cliquer ensuite sur Open. Si le proxy est suffisamment ouvert, il devrait vous laisser passer et vous aurez un login.

Pour faire la même chose d'un client Linux, il suffit d'installer le paquet corkscrew. Ensuite la commande est très simple :

Là aussi, si tout va bien, vous devriez pouvoir vous connecter. A partir de là vous pouvez faire à peu prés ce que vous voulez, y compris mettre en œuvre un proxy SOCKS.

Tunnel HTTP

Autre option, utiliser cette fois le vrai protocole HTTP, sans truquage. La magie est à mettre ici au compte de HttpTunnel. Sur le site vous trouverez les binaires pour Windows, et pour Linux, tout est généralement dans votre distribution à partir d'un urpmi ou apt-get httptunnel.

HttpTunnel se compose de deux parties. Un serveur et un client. Le client va se mettre en écoute d'un port local et rediriger toute demande vers le serveur, en prenant soin de tout encapsuler dans du HTTP classique. De l'autre côté, le serveur HttpTunnel va recevoir les demandes, décapsuler les données contenues dans les trames HTTP, et rediriger le tout vers le port de votre choix.

Par l'exemple, imaginons que sur la machine SERVEUR, nous ayons un service SSH qui tourne en écoute du port 22 (classique). Nous allons donc lancer notre serveur HttpTunnel :

Le serveur HttpTunnel est donc en écoute du port 80 (HTTP) et décapsulera tout ce qu'il recevra vers le serveur SSH en écoute du port 22. Maintenant du côté client :

Le client va ainsi utiliser le proxy HTTP de manière standard, pour contacter le serveur HttpTunnel qui se trouve à l'adresse IP indiqué et au port 80. J'utilise l'adresse IP car le nom de la machine semble ne pas toujours fonctionner chez moi.

Maintenant que notre tunnel est en place, reste à l'utiliser et à lancer un

Et là magie, avec un temps de réaction qui m'a clairement surpris, tout fonctionne. Ici aussi, disposant d'un SSH classique, il est possible de mettre en œuvre ensuite un mini proxy SOCKS.

Maintenant cette méthode a beau très fonctionnelle, elle présente de nombreux inconvénient. Tout d’abord elle squatte le port 80, ou au mieux le 8080 si votre Proxy l’autorise. Il semblerait qu’il n’y ait aucun moyen de changer cela, y compris en utilisant une combinaison Apache/VHOST/ReverseProxy.

Enfin, il n’y a aucune authentification. C’est un système ouvert aux quatre vents. Et ça c’est déjà plus sérieux.

AjaxTerm

Pour finir, personnellement ma méthode préférée, en conjonction avec phpProxy. Car si ce dernier me permet d'aller où je veux, AjaxTerm va me permettre de faire ce que je veux. Et le tout, comme PhpProxy, sans configuration compliquée et avec un simple navigateur WEB.

Cet outil est tout simplement un terminal totalement fonctionnel, colorisé, réactif qui fait presque oublier que l'on est en réalité dans un navigateur. Toutes les applications type nCurse fonctionnent, toutes les commandes sont disponibles, il n'y a tout marche comme à la maison, y compris la tabulation pour compléter les commandes. Que demander de mieux ?

Côté installation, AjaxTerm est un serveur écrit en pyton disponibles dans vos dépôts sans aucun doute via un urpmi/apt-get ajaxterm. Ensuite il n'y a plus qu'à lancer le service du même nom : /etc/init.d/ajaxterm start. Par défaut le serveur se met en écoute du port localhost:8022. Il n'est donc pas disponible directement à partir du réseau public, et c'est tant mieux. Car nous allons du coup pouvoir utiliser un reverse proxy apache pour le coller dans notre conteneur HTTPS, avec le cryptage et l'authentification qui va bien. Le tout au côté de nos autres applications WEB, sans conflit.

Une fois le serveur lancé, vous pouvez vérifier son fonctionnement avec un navigateur WEB en allant sur http://localhost:8022. Une fois que vous avez constaté son bon fonctionnement, il faut rajouter dans la configuration d'apache, de préférence dans le vhost en charge du port 443/HTTPS, les lignes suivantes. Pour les détails sur les paramètres d'authentification, se reporter à ce billet .

Maintenant pour que cela fonctionne, assurez vous que vous avez installé le module apache apache-mod_proxy. Après un petit redémarrage d'apache et l'on peut se connecter du monde extérieur, de manière sécurisée et authentifié, à l'adresse http://mon_server/mon_machin/. Remplacez mon_machin dans la configuration par quelque chose de plausible mais n'attirant pas l'attention. Evitez les choses du genre /je_vous_ai_bien_eu/, ça ne va pas le faire bien longtemps

Ne laissez pas non plus la console activée en permanence car étant de l'ajax, je soupçonne qu'il fasse sur le serveur des requêtes récurrentes qui pourraient attirer l'attention.

Conclusion

Voilà, c'est la fin de la seconde édition de ce tutoriel, avec mes remerciements aux gens en dessous (Dab & co ) qui m'ont donné suffisamment d'idée pour ne pas en rester à un simple proxy en php

Commentaires