Petit hack entre amis :-)

Introduction

Le problème est assez simple à la base, me permettre de surfer sur le net de façon sécurisée sur un réseau inconnu (par défaut non sûr).
Un des intérêts est aussi de pouvoir me connecter à ma banque en présentant mon adresse IP Française alors que je suis relié au net depuis l’étranger (Colombie Pologne etc…). Autre cas qui facilite la vie en conservant mon adresse IP, la connexion à Facebook. Dans le cas contraire, on se retrouve dans un processus de vérification d’identité fastidieuse et aléatoire…

Tunnel SSH

J’aurais pu utiliser IPSEC… mais je n’ai pas encore installé IPSEC chez moi. Ce sera pour une prochaine fois.

J’utilise un tunnel SSH vers une machine disposant d’un proxy (Squid dans mon cas).

Dans ce schéma, la machine Relai n’est pas utilisée… pour l’instant. Le serveur à la maison est décrit dans le deuxième schéma.

Explications du schéma.
1) Je ne veux pas aller me connecter directement sur les services web depuis un réseau inconnu, en clair le plus souvent.
2) Depuis mon portable, j’ouvre un tunnel vers chez moi sur le port tcp/27022. L’autre bout du tunnel, c’est le relai web Squid qui écoute sur le port tcp/8080. Mes connexions vers le web passent par le tunnel vers le relai web.
3) le relai web relaye mes connexions vers Internet, comme si j’étais chez moi.

Pour l’exercice de style le véritable port tcp a été remplacé par le port tcp/27022. Les connaisseurs reconnaîtrons quelque chose qui s’approche des ports utilisés à l’époque du HL Counter Strike premier du nom ;-)

Mon port tcp/22 étant déjà occupé (mappé), je décide de faire entrer le tunnel SSH par le port tcp/27022. En fait parce que la machine derrière qui va recevoir le relai Squid n’est pas la même que celle qui reçoit déjà le port tcp/22 SSH habituel.

Le serveur relai Squid reçoit bien une connexion tcp/22, il y a translation de l’adresse destination publique (82.226.39.232 -> ip interne) et du port (27022 -> 22) par le pare-feu. Le serveur relai Squid lui peut ressortir vers Internet comme toute machine interne au réseau, elle est donc dans un réseau client et non serveur (beaucoup plus limité par nature).

Explications de schéma.
tcp/22 : Toute connexion SSH vers chez moi sur le port tcp/22 est redirigée vers le serveur SSH autre, serveur qui n’est pas le relai web que je souhaite utiliser.
tcp/27022 : Toute connexion SSH vers chez moi sur le port tcp/27022 est redirigée vers le serveur relai Squid, (sur le port tcp/22) celui qui va relayer mes connexions au web.
Sortie : Le serveur relai Squid à la possibilité de sortir sur le web directement, il relayera mes connexions vers le web (tcp/80 et tcp/443).

Relai Squid

Le serveur relai Squid qui va relayer les requêtes de pages web vers Internet est une machine Linux classique physique ou virtuelle, avec ou sans interface graphique. Dans mon cas une machine virtuelle proposant déjà d’autres services sur le réseau (oui je sais c’est pas bien).

Il suffit d’installer un logiciel proxy web tel que Squid et de le faire écouter sur l’interface de loopback (uniquement) sur le port 8080.

Connexion depuis le portable

Depuis le portable, il faut initialiser préalablement le tunnel. Cela se fait avec cette commande (à mettre dans un script) :

ssh -p 27022 -f -L 8080:localhost:8080 root@82.226.39.232 /root/wait.sh

Oui, je sais c’est pas bien d’utiliser root comme compte distant pour ouvrir le tunnel. Créer un autre utilisateur dédié et lui permettre de créer des tunnels…

Le script /root/wait.sh est à créer sur le serveur relai Squid. Il ne contient que :

while true ; do sleep 1 ; done

Une fois lancé, netstat remonte cette connexion :

tcp   0   0 x.x.x.x:yyyyy   82.226.39.232:27022   ESTABLISHED

Localement sur le portable, un port en écoute apparaît, le port tcp/8080. C’est le début du tunnel. L’autre bout du tunnel est sur le serveur relai Squid, port tcp/8080 aussi, le port sur lequel écoute Squid justement…

Ne reste plus qu’à configurer le navigateur pour qu’il utilise un proxy en localhost port 8080 :-)

En Colombie

En Colombie, cela à parfaitement marché. C’était un peu plus lent que en directe mais il ne faut pas négliger deux choses :
Рon traverse une fois dans un sens le monde pour ensuite peut-̻tre repartir en sens inverse.
– on passe par le flux upload de chez moi, plus restreint que le flux download, le fameux A de ADSL…

Bref, rien à redire :-)

Et en Pologne ?

Le cas de la Pologne est un peu plus trouble :-/

Arrivé à l’hôtel, je récupère un identifiant de connexion et tente de me connecter de la même façon.

Mis à part quelques problèmes techniques et choix douteux dans la méthode de connexion pour les utilisateurs, propre à cet hôtel, tout se passe bien… pendant 2 heures.

En effet, après 2 heures environ, je pers la connexion avec la maison. Plus trouble encore, impossible d’avoir accès à mon adresse sur quelque port que ce soit. Plus de web, plus de messagerie, plus de jabber, plus de ssh :-(

Mon serveur à la maison est en panne?
Non, après vérification il marche très bien et est accessible depuis Internet. Ca marche par exemple en passant par un relai web ouvert type http://proxy.org/ .
Non, on dirait que mon adresse IP de chez moi à moi que j’ai est filtrée par l’hôtel !!!

Test au restaurant de l’hôtel, curieusement ce n’est pas le même réseau. Pareil au bout de 2h.

Pourquoi diable filtre-t-on mon adresse IP?
Seule réponse possible, c’est parce que j’utilise un port un peu « bizarre ». Le tcp/27022 ne correspond à rien de connu.

Pour contourner le problème, je vais passer par une autre machine relai.

Explications du schéma.
1) Je ne veux pas aller me connecter directement sur les services web depuis un réseau inconnu, en clair le plus souvent.
2) Depuis mon portable, j’ouvre un tunnel vers la nouvelle machine relai sur le port tcp/443.
3) La machine relai se contente de renvoyer les connexions tcp/443 vers chez moi sur tcp/27022.
4) le relai web relaye mes connexions vers Internet, comme si j’étais chez moi.

Je demande à un ami sur le net de me prêter une petite machine virtuelle Linux et de me translater dessus les connexions du net sur les ports tcp/22 et tcp/443 :
– Le port tcp/22, c’est pour que je puisse l’administrer depuis la Pologne.
– Le port tcp/443, c’est pour faire comme si j’utilisais un flux SSL vers chez lui.
Évidemment il n’utilise pas déjà ces ports en entré depuis Internet.

Vers ce port tcp/443, je me connecte en SSH (et non SSL) en remplacement de la connexion au port tcp/27022 de chez moi. SSH n’est pas SSL… mais quel importance si en face le serveur qui reçoit la connexion tcp/443 est un serveur SSH ;-) Et surtout, ce port tcp/443 est reconnu comme faisant transiter des connexions web sécurisées, donc connues et potentiellement non filtrées.

Cette machine ne va pas recevoir un deuxième proxy web, j’en ai un ça suffit. Elle va juste translater les connexions sur le port tcp/443 vers chez moi sur le port tcp/27022 !

Victoire, je contourne le filtrage :-D
Par contre ça rame grave, mon ami a une upload de m___e :'(
Merci à lui quand même pour m’avoir dépanné sur ce coup :-)

Après plusieurs jours en Pologne (que je recommande vivement pour du tourisme, notamment Krakow), j’ai constaté plusieurs choses :
– Le filtrage sur mon adresse IP tombait par défaut au bout de 1 à 3 jours, naturellement.
– le problème de filtrage s’est fait sentir aussi à un Starbuck, donc ils ont le même prestataire qu’à l’hôtel.
– en fait, si on utilise un deuxième navigateur sans passer par le proxy web, et que l’on télécharge suffisamment, le problème de filtrage n’apparaît pas. Peut-être que dans ce cas mon port inconnu passe inaperçu dans le flot des connexions…
Du coup j’ai téléchargé quelques podcast de Couleur3 pour camoufler ma connexion et éviter autant que possible l’utilisation de la machine relai :-)

A corriger la prochaine fois

Plusieurs choses sont à corriger.

Peut-être déjà utiliser par défaut IPSEC et non un relai juste pour le web du navigateur.

Un autre problème est que la machine, en dehors du navigateur, n’utilise pas le relai et donc le tunnel sécurisé. Sont concernés NTP (la mise à l’heure) et les mises à jours (signées par défaut). IPSEC serait une solution pour les inclure par défaut.

Ne pas utiliser root pour le bout du tunnel.

Ne pas avoir besoin de passer par un relai web Squid. Vive IPSEC.

Faire rentrer SSH via le port tcp/443 déjà occupé par SSL. Mettre en place le programme sslh.

Et utiliser une machine juste pour cette tâche ingrate!

Fin

C’est tout pour aujourd’hui :-)

Arrête de glander sur Internet et retourne bosser feignasse !