Avant tout je vous invite à prendre connaissance du billet préliminaire qui vous expliquera de quoi il est question mais contient aussi la procédure pour Windows. Dans ce billet nous allons effectuer la configuration pour un ordinateur fonctionnant sous GNU/Linux, ici il s'agit de Debian.
Le but est d'utiliser un tunnel SSH pour aller sur le web, via socks, le tout derrière un proxy. Oui je sais, ça vous paraît barbare vu comme ça mais en réalité c'est très simple, don't worry.
Tout y passe
Vous pouvez utiliser cette méthode pour surfer mais également pour tout programme dont l'utilisation derrière un proxy n'est pas prévue. C'est d'ailleurs particulièrement à ces programmes que nous nous intéressons.
Quelques exemples d'utilisation possible en étant derrière un proxy :
- connexion SSH
- mineur de bitcoin
- installation des paquets
- etc...
La seule condition pour que cela fonctionne est que le serveur SSH distant soit accessible à travers mandataire (proxy), faites-le tourner sur le port d'écoute 443. Et si vous avez un système d'inspection des paquets en profondeur (DPI) cela ne fonctionnera naturellement pas, à moins que le sysadmin ne laisse passer les flux ssh sortants pour son usage personnel... hum. Le cas contraire vous pouvez contourner le problème avec httptunnel (hts, htc), plus d'infos ici.
Voici comment ça se passe :
- nous établissons une connexion SSH vers un serveur web, au travers d'un proxy d'entreprise
- nous lançons un programme à l'aide de tsocks qui va faire transiter les paquets dans notre tunnel de façon transparente
Etape 1 : établir le tunnel SSH à travers le proxy
Nous devons tout d'abord établir un tunnel SSH vers une machine cible accessible sur le web, avec une IP publique.
Dans notre exemple ce sereur web distant aura l'IP fictive 3.14.159.26 dont le service SSH est en écoute sur le port 443. Rien ne vous empêche d'utiliser votre nom de domaine au lieu d'une ip, comme monserveur.com.
Installez le paquet connect-proxy qui permettra d'établir une connexion SSH via le proxy de l'entreprise :
apt-get install connect-proxy
Puis ajoutez à la fin du fichier /etc/ssh_config (à ne pas confondre avec sshd_config) :
Host 3.14.159.26 ProxyCommand connect-proxy -H proxy.entreprise.fr:8080 %h %p
Cette ligne précise que toutes les connexions SSH à destination de l'hôte 3.14.159.26 seront transmises au proxy de l'entreprise. Voyant arriver une demande de connexion sur le port 443 celui-ci n'aura pas d'autre choix que laisser passer la connexion car il ne peut pas intercepter les paquets HTTPS (sauf si le sysadmin a installé un proxy HTTPS qui remplace les certificats à la volée mais il doit en informer ses utilisateurs).
Ouvrir un second terminal pour établir le tunnel SSH avec le port dynamique 1080 (relai socks). Après l'avertissement à valider vous tombez sur la mire de votre serveur distant :
ssh utilisateur@ip -p 443 -D 1080
On peut enfin se connecter en SSH à travers un proxy, en précisant le port 1080 qui fera office de proxy socks :
root@bm:~# ssh root@3.14.159.26 -p 443 -D 1080 root@3.14.159.26's password: ****** root@3.14.159.26:/tmp/home/root#
Laissez ce terminal ouvert, si vous le fermez vous fermez aussi le tunnel dont nous allons avoir besoin dans l'étape qui suit.
Vérifions le fonctionnement du tunnel : retournez dans le premier terminal. Cette commande doit retourner l'IP du serveur SSH distant, 3.14.159.26 pour nous :
curl --socks5 127.0.0.1:1080 http://ipecho.net/plain; echo 3.14.159.26
(Installez curl si manquant : apt-get install curl).
Etape 2 : tsocks pour les autres programmes (facultatif)
Pouvoir utiliser SSH à travers le proxy permet déjà pas mal de choses, notamment de surfer en by-passant complètement le proxy de l'entreprise. Si ce n'est pas suffisant pour vous et que vous souhaitez faire passer des flux d'autres applications dans le tuyau, voici comment faire.
C'est le paquet tsocks qui va intercepter nos requêtes pour les envoyer dans le tunnel SSH, dont le serveur distant fait office de proxy socks (natif au serveur ssh). tsocks est un proxy socks transparent, d'où son nom (transparent socks).
Installez-le :
apt-get install tsocks
Le fichier de configuration se situe dans /etc/tsocks.conf.
Vous devez ajouter la liste de vos réseaux locaux, une ligne pour chaque réseau, à minima ajoutons les plages privées (RFC1918) :
local = 192.168.0.0/255.255.255.0 local = 10.0.0.0/255.0.0.0 local = 172.16.0.0/255.240.0.0
En cas de doute relisez le "cours" sur les réseaux et la notation CIDR.
Choisissez un port d'écoute, dans notre cas c'est le 1080 :
server_port = 1080
Inutile de modifier d'avantage le fichier de configuration.
L'IP distante correspond à l'IP du serveur SSH distant, en écoute sur le port 443.
Laissez ce terminal ouvert et revenir sur le premier terminal.
Vérifions maintenant que tsocks relaie correctement les paquets avec cURL, sans préciser de proxy mais en préfixant les commandes par tsocks :
tsocks curl http://ipecho.net/plain; echo 3.14.159.26
Good ! Il est maintenant possible de lancer n'importe quelle application avec tsocks qui se chargera de faire transiter les paquets de façon transparente dans le tunnel.
Vous pouvez aussi passer des paramètres, exemple avec Firefox :
tsocks firefox https://blogmotion.fr
Et voilà !
Vous pouvez également utiliser corkscrew (cf) comme alternative à connect-proxy ou encore sslh.
Auteur : Mr Xhark
Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter
6 commentaires
Chenapan... mais tu sais qu'il y a des admin réseau et système qui sont assez fous pour lire ta prose? Et qu'ils connaissent déjà tous ces trucs...
Attention quand même, faut prévenir les gens qui jouent à ça en entreprise qu'il pourront sans doute un temps passer au travers, mais que si les serveurs sont administrés correctement ils finiront par se faire pincer. Et je connais de boîtes où ça peut conduire directement au Pole-emploi ces conneries, voir devant les tribunaux.
Ceci dit c'est intéressant de diffuser de l'info réseau, ça manque souvent, mais attention à ne pas pousser les utilisateurs à vouloir jouer aux petits malins sans mesurer les risques.
@Alarc'h: d'où la mise en garder dans le billet (partie 1) : "Mise en garde : suivant la législation de votre pays vous vous exposez à des poursuites judiciaires si vous contournez un système de sécurité tel qu'un serveur proxy ou un pare-feu. Ceci étant dit, dans certains pays comme la Chine ce coutournement est nécessaire pour ne pas entraver la liberté d'expression à laquelle la censure porte atteinte."
Ici le but n'est pas de contourner la loi mais de partager les connaissances, et je suis sûr que tous les sysAdmin ne connaissent pas cette méthode, et pourront donc dès maintenant regarder d'un peu plus près les stats IP sur la sortie WAN 🙂
Je ne rentrerai pas dans la critique de mes petits camarades, mais tous les sysadmin ne sont pas incompétents 😉 Et ce serait dommage de risquer les tribunaux pour s'en assurer.
Ma remarque était un peu ironique, et d'ailleurs j'ai bien salué la diffusion d'informations concernant le réseau, je comprends bien que ce n'est pas une école de black hats ici.
Mais une mise en garde c'est souvent un peu comme les CLUFS et les petites lignes de son contrat d'assurance, on a tendance à passer sans les lire. Elles forment une sorte de protection pour ton blog, on ne pourrait pas te reprocher de ne pas l'avoir dit, mon intention était d'attirer l'attention de l'utilisateur un peu enthousiaste et pas méchant qui pourrait se laisser aller à faire une bêtise sans mauvaise intention sans bien réellement peser les conséquences.
@Alarc'h: oui, dans ce cas tu as bien fait 🙂 La mise en garde est quand même plus courte que les lignes de ton contrat d'assurance ^^