Le proxy dans tous ses états

Un proxy, appelé parfois mandataire, est un service réseau qui consiste à faire le relai entre un client et un serveur.

Sur cette image, l’information utile que le client fait parvenir au serveur est "Salut !". Mais le message qui parvient au serveur n’est pas "Salut !", c’est "Tu as un message du client : Salut !". Le proxy, en tant qu’intermédiaire, a la possibilité de modifier le contenu des échanges, pour ajouter des informations sur l’expéditeur notamment.

Pas forcément ! Il peut y avoir plein de raisons pour lesquelles un proxy est utile. Par exemple, un serveur peut n’accepter de répondre qu’à des requêtes préalablement filtrées, pour éviter des sollicitations inutiles ou provenant d’inconnus. Le proxy sert alors de filtre en amont du serveur. Il peut aussi répondre à la place du serveur dans certains cas : quand ce dernier est harcelé de requêtes identiques à qui il doit répondre la même chose, le proxy peut répondre à sa place pour le décharger. C’est un système de cache, on parle alors de proxy-cache.

Dans la configuration dont nous parlons, le client contacte spécifiquement un proxy dans le but qu’il transmette un message au serveur. Autrement dit, le proxy est au service du client. Il existe un autre cas de figure, où le proxy est au service du serveur, et se fait passer pour lui. Là, c’est transparent pour le client, qui croit s’adresser en direct au serveur, alors que c’est un intermédiaire qui lui répond. Dans ce cas, on parle de reverse proxy.

En pratique, on peut utiliser un proxy pour plein de protocoles applicatifs différents : HTTP, IRC, SMTP, … Le plus courant est le proxy web, qui relaie donc des requêtes et des réponses HTTP. Voyons comment cela se passe d’un point de vue réseau.

Concrètement, un proxy est une application, un logiciel. Parmi les plus connus, on peut citer Squid pour le web, ou Fireware de Watchguard. Il fonctionne au niveau 7 du modèle OSI, c’est-à-dire sur la couche application. Si vous avez bien suivi le début du cours, vous vous souvenez que pour atteindre le niveau le plus haut, il faut décapsuler toutes les couches inférieures. C’est extrêmement important de garder cela en tête, car quand un proxy web reçoit une requête HTTP et veut la transmettre à un serveur, la réception se fait d’un côté avec une connexion TCP vers le client, des paquets IP dont il est le destinataire… Et la transmission d’un autre côté, avec une autre connexion TCP vers le serveur et des paquets IP dont il est la source ! Il y a une rupture de flux au niveau du proxy.

Observons cela avec une analyse réseau depuis un proxy.

Cela présente un énorme avantage pour un réseau d’entreprise : on peut interdire aux utilisateurs d’accéder en direct à Internet, au moyen d’un pare-feu par exemple, et décider que toute communication vers l’extérieur doit passer par un proxy. Cela permet de contrôler qui accède à quoi et d’empêcher l’accès à certains serveurs ou sites web.

Mais ce fonctionnement a une autre implication. De nos jours, la plupart des communications sont chiffrées de bout-en-bout. Mieux : pour les protocoles les plus courants, elles le sont avec TLS. Ce protocole, que nous avons survolé en fin de partie 5, chiffre l’intégralité des données utiles d’une manière telle qu’il est impossible de s’interposer, de déchiffrer le contenu, puis de le réexpédier comme si de rien n’était.¹ Pas moyen de filtrer ce qui passe… Ni même de savoir quel protocole applicatif est réellement utilisé ! Tout doit être transmis tel quel. Retenez ça, nous y reviendrons bientôt.

Vouloir contrôler ce que font ses employés ou ses élèves, ça peut se comprendre : on ne veut pas que les salariés ne jouent ou que les jeunes ne consultent des contenus classés X… Mais tout système peut être contourné par qui le veut vraiment, plus ou moins facilement.

Le filtrage des sites web est probablement le plus facile à flouer. Il suffit d’utiliser… un webproxy ! Il s’agit de sites web permettant de faire le relai vers un autre site. Ça fonctionne plus ou moins bien selon les fournisseurs et les sites visités. Cherchez "webproxy" sur un moteur de recherche, vous trouverez facilement. Et comme cette technique est répandue, la plupart des proxys en entreprise filtrent les webproxys !

Alors pour trouver un webproxy qui ne soit pas bloqué, le mieux est encore d’utiliser le sien ! Il existe des solutions faciles à mettre en place, pour peu qu’on ait un peu de connaissances en serveur web, comme phproxy.

Passons maintenant au niveau supérieur. Plus tôt, nous avons dit qu’il est impossible de différencier les protocoles se trouvant au dessus de TLS. Techniquement, on ne peut pas faire la différence entre HTTPS, SFTP ou SSH, qui fonctionnement tous sur TLS, à part peut-être avec le numéro de port. Mais ce paramètre est changeable : sur son propre serveur, rien ne nous empêche de faire écouter un serveur web sur le port 1234 si ça nous chante. Une technique courante pour passer outre certains filtrages consiste à faire écouter un serveur SSH sur le port 443. Ce protocole sert principalement à contrôler un serveur à distance et il écoute normalement le port 22. Or, la quasi totalité des serveurs web utilisent le port 443, qui est le port standard pour HTTPS. On peut tout à fait établir une connexion SSH sur le port 443 : on n’y verra que du feu !

Oh non, ça va bien plus loin. À partir du moment où vous pouvez ouvrir une connexion SSH vers votre serveur, vous avez la possibilité de faire passer n’importe quelle communication par cette voie. SSH permet d’ouvrir des tunnels dynamiques entre un client et un serveur : en ouvrant un port, le client devient alors à son tour… un proxy. Il transmet tout au serveur SSH, qui sert alors de… Oui, vous avez deviné : de proxy. L’image suivante permet d’illustrer ce concept. On considère que le serveur SSH écoute le port 22, que le client écoute le port 12000, que le proxy écoute le port 8080 et que l’hôte X veut faire parvenir au serveur Y le message "Salut !" en TCP sur le port 11111.

Dans le détail, sur le réseau, on a les échanges suivants.

En illustrant cette technique avec un message lambda ("Salut !"), on montre que presque n’importe quoi peut être transporté de cette manière. En fait, la communication entre l’hôte X et le client SSH se fait avec le protocole SOCKS, qui permet d’encapsuler n’importe quel protocole qui fonctionne sur TCP ou UDP. On peut donc faire transiter dans un tunnel SSH des pages web, des e-mails, des messageries instantanées, etc.

Sur l’image, nous avons représenté un hôte X, mais le poste ouvrant le tunnel peut tout à fait s’utiliser lui-même. Sur le même ordinateur, on peut avoir le client SSH et le navigateur web, par exemple, qui passe par le proxy créé par le tunnel. Dans ce cas, on configurera le navigateur avec pour adresse de proxy… l’adresse de loopback ! Voilà enfin un intérêt à ces fameux 127.0.0.1 et ::1 !

On a abouti à une solution technique de contournement de filtrage plutôt pas mal, mais il reste un dernier obstacle qu’on rencontre couramment en entreprise : l'authentification. En effet, n’importe qui ne peut pas utiliser les services d’un proxy : seul le personnel autorisé doit pouvoir s’en servir. Une méthode d’authentification classique dans les réseaux Microsoft est NTLM. Normalement, on ne parle pas de solution spécifique à un éditeur dans ce cours, mais dans le cadre de ce chapitre, nous allons faire une exception pour le plaisir de vous montrer une architecture qui vaut le détour.

NTLM est un système qui permet, entre autres, de s’authentifier auprès de proxys dans un environnement Microsoft. Si la plupart des clients SSH sont capables de passer par un proxy, peu supportent l’authentification NTLM. Pour pallier ce manque, on peut utiliser CNTLM. Ce programme nécessite un peu de configuration, nous vous renvoyons à ce billet (en français) pour cela. Nous ne nous focaliserons que sur l’aspect réseau.

CNTLM se charge d’établir une connexion avec un proxy nécessitant l’authentification NTLM. Il ouvre un port et devient à son tour… un proxy, oui, on en aurait presque marre maintenant. En faisant passer nos communications au travers de ce port, CNTLM se charge de les renvoyer au proxy avec l’authentification adéquate. On peut donc faire passer une connexion SSH par ce moyen, tout en établissant un tunnel, ce qui permet à n’importe quel logiciel de passer par le-dit tunnel… et faire transiter toutes ses communications par un serveur distant, au nez et à la barbe de votre méchant patron qui ne veut pas que vous jouiez à des jeux en ligne au bureau !

Voici une illustration de la chaine de communications qui s’établit si vous visitez Zeste de Savoir au travers d’une telle solution. Le client SSH écoute sur le port 12000 pour son tunnel, CNTLM écoute sur le port 6666, ces valeurs sont arbitraires. Le serveur SSH écoute sur le port 443 pour éviter un éventuel filtrage. Le proxy écoute sur le port 8080, c’est une valeur courante dans la configuration des proxys. Quant à Zeste de Savoir, il écoute sur le port 443, qui est le port standard des serveurs web.

Cette architecture est un petit exploit technique qui illustre un proverbe du monde de la sécurité : hacker vaillant, rien d’impossible !