Contourner un filtrage web à l’aide d’un tunnel SSH

Salut à tous, aujourd’hui je penche sur une question qui doit en emmerder pas mal au boulot dans les grosses boites : le filtrage des sites web. Et du coup : comment un contourner un filtrage web à l’aide d’un tunnel SSH. En effet, dans la plupart des grosses entreprises vous n’avez pas accès à Internet directement. Le plus souvent les administrateurs bloquent certains sites (genre le p0rn, les jeux en ligne, les sites de hacking, etc.). C’est plutôt souhaitable car ce ne sont pas des sites vraiment utiles d’un point de vue professionnel. Et d’un point de vue sécurité ces sites sont souvent des nids à emmerdes pour votre équipe de sécurité. Néanmoins dans certains cas précis, c’est embêtant et vous aimeriez bien vous en affranchir, au moins ponctuellement, quelques cas pratique :

• En mission vous ne voulez pas utiliser le VPN de votre entreprise pour votre « navigation personnelle du soir », mais pas non plus le wifi pourris jusqu’à l’os de votre l’hôtel non plus.
• Un des sites bloqués est légitime (faux positif) et y accéder est indispensable pour tenir votre deadline projet : vous n’avez pas le temps d’attendre 1 semaine que les admins débloquent le site, pour y accéder.
• Geekeries.org est bloqué depuis votre boulot !

Avertissement :

Je vous recommande vivement de ne pas contourner votre politique de filtrage d’entreprise. Vous risquez gros si vous vous faites prendre : dans le meilleur des cas par un brave admin vigilant (qui lit Geekeries.org) et pas content. Dans le pire des cas, dans le cadre d’un incident SSI lié au trou béant que vous aurez créé dans la coque du SI de votre entreprise. Et là, vous irez à la case licenciement pour faute grave sans passer par la case départ.

Ce que j’explique ci-dessous n’est donc qu’a utiliser à des fins académiques et pour un usage personnel sur le wifi de l’hôtel (français) de vos prochaines vacances. Voilà c’est dit, maintenant c’est vous qui voyez.

Quelques contournements possibles au filtrage Web

Avez de s’occuper de la solution maison qui nous intéresse, je me permets de vous rappeler quelques options possibles. L’idée et toujours la même relayer les requêtes http à un serveur qui ne subit pas le filtrage réseau et récupérer les réponses. Voici les principales options :

1. Passez par TOR, c’est lent, efficace mais gratuit ; mais simple à détecter par vos admins et franchement risqué vu la faune qui circule dessus.
2. Utilisez un Proxy ou un VPN commercial : genre hidemyass, expressVPN, hide.me ou encore proxy.org ;
   c’est le meilleur rapport emmerdes/prix (5-10€/mois) et assez fiable. Néanmoins vos admins peuvent bloquer aussi ces sites là et gêner les flux réseaux des VPN.
3. Déployer votre propre proxy sur SSH : chez vous ou sur une box chez un hébergeur comme Kimsufi ou Online.net. C’est la solution des barbus qui nous intéresse ici. C’est plus difficile à déceler/bloquer par les admins (mais pas impossible), c’est sécurisé car vous maîtrisez de bout en bout toute la chaîne. Ça coûte un peu plus cher : Comptez au moins 8€ par mois pour un serveur dédié, ou un acheté un Raspberry pi (70€) et une connexion ADSL à la maison (30€/mois)

Ici c’est la solution 3 qu’on va mettre en place avec une box dédiée. Notez que cette solution ne vous anonymise pas du tout, votre employeur détectera le trafic vers le serveur et le serveur est loué à votre nom avec vos coordonnées chez l’hébergeur, donc évitez les sites de chti n’enfants tout nus, hein (et de manière générale aussi hein…).

Proxy HTTP over SSH avec tunnel « SOCKS »

Dans cette solution, on va mettre en place un proxy explicite local sur votre machine qui redirige les connexions au travers d’un tunnel SSH vers un serveur dédié sur le net. Je vous mets un schéma ci-dessous expliquant en détail ce qu’on va faire :

En gros, c’est simplement l’utilisation d’un tunnel SSH dans lequel on va faire passer le trafic de Firefox.

Mise en oeuvre

Le serveur :

Bon étape n°1, il faut vous louer un serveur chez Kimsufi, Online.net ou un autre hébergeur. Si vous êtes radin, une autre option est de vous prendre un Raspberry Pi et de le monter chez vous derrière votre box ADSL avec un peu de NAT sur la box pour forwarder le trafic vers votre Framboise local, mais vous devriez obtenir le même résultat.

Étape n°2, vous devez être en mesure d’établir une connexion vers votre serveur depuis votre réseau filtré. Si vous avez un peu de chance, le port 22 sera autorisé en sortie dans la politique réseaux de votre boite. Si c’est n’est pas le cas, il faudra trouver les ports autorisés en sortie et changer le port d’écoute SSH de votre serveur pour utiliser un de ces ports autorisés, par défaut, je vous conseille de le déplacer sur le port TCP/443 (spoiler : HTTPS). Ce port est toujours ouvert en sortie et est fait passer des flux chiffrés (HTTPS), ça devrait donc être assez discret. On verra plus bas comment détecter malgré tout ce trafic SSH. Une fois que vous aurez trouvé un port ouvert en sortie de votre réseau. Configurez le service SSH de votre serveur pour écouter sur ce dernier, fichier /etc/ssh/sshd_config sur une Debian et :

Port 443

SOCKS un proxy local over SSH

Configurer une enfin connexion intégrant un tunnel SOCKS avec PuTTY depuis votre machine vers ce serveur. En suivant les 3 étapes suivantes :

1. Ouvrez PuTTY et indiquez le nom de l’utilisateur, l’adresse IP, et le port à utiliser pour se connecter au serveur.

2. Allez dans le menu « Connection -> SSH -> Tunnels » (dans Category à gauche) et ajoutez un port d’écoute pour votre Proxy SSH. J’ai indiqué le port 1234 mais vous pouvez choisir n’importe quel port disponible (entre 1024 et 65535). Sélectionner « Dynamic » et cliquez sur « Add« . D1234 apparaîtra alors dans la liste des ports forwardés.

3. Revenez au menu initial et sauvegardez votre connexion.

4. Optionnel : je vous recommande d’utiliser un clé SSH (protégée par mot de passe) comme mode authentification avec votre connexion comme que je l’ai déjà expliqué dans cet article.

Et c’est tout, PuTTY mettra en place un serveur SOCKS en écoute sur le port 1234 dès qu’une connexion SSH sera ouverte vers votre serveur.

Configurer Firefox pour utiliser le proxy SOCKS de PuTTY

Dernière étape, installer Firefox et configurer un proxy comme indiqué dans la capture ci-dessous :

Je vous conseille enfin de cocher la case « Utiliser un DNS distant lorsque SOCKSv5 est actif« , car sinon même si vos admin ne verront pas passer le trafic du tunnel, toutes les requêtes DNS associé à ce dernier elles seront bien faites sur les DNS locaux de l’entreprise. Et comme il n’y jamais pas de fumé sans feu, des requêtes DNS sans trafic associés pourraient d’attirer l’attention…^^

Si vous êtes suffisamment parano, vous pouvez aussi désactiver l’historique de navigation de Firefox et/ou l’utiliser exclusivement en navigation privé systématiquement.

Contourner un filtrage web à l’aide d’un tunnel SSH

Pour utiliser le tunnel, vous devez d’une part, ouvrir un connexion SSH vers votre serveur :

Using username "user".

Authenticating with public key "ProxySSL" from agent

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Last login: Sat Feb 11 09:30:30 2017 from <IP>
user@myserver:~$

Vous aurez simplement à conserver cette fenêtre ouverte pendant votre navigation. PuTTY va ouvrir le port 1234 configuré plus tôt et transférer tout le trafic reçut sur ce port au vers de la connexion SSH. On peut vérifier ça avec la commande Netstat ci-dessous qui montre que PuTTY écoute bien sur le port 1234 :

PS C:\Windows\system32> NETSTAT.EXE -a -n -o -b | Select-String 1234

TCP 127.0.0.1:1234 0.0.0.0:0 LISTENING 3292 

PS C:\Windows\system32> Get-Process -Id 3292 

Handles NPM(K) PM(K) WS(K) CPU(s)   Id SI ProcessName
------- ------ ----- ----- ------   -- -- -----------
    249     19  3852  7184  19,95 3292  2 putty

D’autre part il vous suffit d’ouvrir Firefox et de vérifier votre IP à l’aide d’un des nombreux sites existants et vous devriez avoir l’IP de votre serveur, et non plus celle de votre boîte.

Et le tour est joué, à vous la liberté : « Libérée, Délivrée C’est décidé, je m’en vais…« 

Et vous n’avez même pas besoin d’être admin de votre poste pour mettre ça en place. Vous devriez quand même expérimenter une petite latence liée à l’ajout d’un serveur sur le chemin de votre connexion, mais tout le trafic dans Firefox sera fait au travers de votre tunnel SSH : difficilement décelable, confidentiel, et comme votre box n’est pas dans le périmètre de votre boite libéré de la politique de filtrage de celle-ci.

Détecter un tunnel « SOCKS

Bon changement de côté, faut pas déconner non plus. Je vais aider vos admins à vous topez aussi : alors comment on peut détecter ou bloquer ces connexions et pour mettre des baffes à nos utilisateurs qui cherchent à contourner notre belle politique d’entreprise ? Si on reprend les trois méthodes que j’ai déjà évoquées :

1. Détecter TOR :
   Facile à bloquer comme à détecter avec un IDS tel que SNORT, j’en ai déjà parlé dans cet article d’ailleurs.
2. VPN et Proxy HTTP :
   C’est un peu plus complexe mais si vous avez un bon Firewall commercial il doit déjà avoir une catégorie « Proxy ». Qu’il vous suffira de mettre à « Deny » pour bloquer 90% du trafic vers ces sites. Autre option plus vicelarde, mettez en place votre propre Proxy d’entreprise et interdisez l’accès à internet à l’exception de ce proxy. Puisqu’on ne peut configurer qu’un seul proxy, les utilisateurs ne seront pas en mesure de mettre de leur derrière le votre, ni de joindre le leur sur internet sans passer par celui de la boite !
   Concernant les VPN, ils est simple de bloquer ceux qui ne fonctionne pas sur les ports « web » (80/443), concernant les autres, une blacklist de la catégorie « VPN » dans votre firewall devrait terminer le travail.
3. Tunnel SSH-SOCKS :
   Bon déjà bloquez les ports en sortie en dehors de 443 et 80 pour vos VLANs utilisateurs Ça va arrêter une bonne partie des bons pères de famille… pour les autres ça devient plus complexe, car vous ne pouvez pas deviner les IPs des serveurs personnels des utilisateurs par rapport à des serveurs web classique.
   Il va donc falloir travailler avec et selon l’infrastructure réseaux :
   1. Détecter le trafic « non-HTTP » sur vos flux réseaux : ça veut dire analyser tous les paquets en couche 7 du modèle OSI (<=> couche 4 en TCP/IP) avec un Snort et crier dès que ce qui passe n’est pas du HTTP/HTTPS… Et ça en fait un paquet de paquets à analyser si vous avez 100 000 salariés qui naviguent sur Internet tous les jours !
   2. Détecter le flux avec du SSH en dehors du port 22 : c’est par défaut des flux illégitimes. Par contre, c’est ce qui est fun avec cette règle, un utilisateur qui fait ça sur le port 22 ne sera pas inquiété le moins du monde, à moins que vous ne mettiez une whitelist d’IP en place pour ce port de destination…

Bref, à vous de trouver le plus rationnel en fonction de vos contraintes techniques et votre état de lieu du réseau…Notez quand même que Snort a une règle pré-existante sur le sujet : « ET POLICY SSH banner detected on TCP 443 likely proxy evasion » qui devrait être le minimum à implémenter et surveiller dans n’importe quel réseau d’entreprise.

Conclusion

Avant de finir, Je vous invite à lire le papier du SANS sur le sujet qui, certes, commence à dater un peu mais reste intéressant à lire. Sinon j’espère que cela vous aura intéressé d’apprendre à contourner un filtrage web à l’aide d’un tunnel SSH, et mieux à le détecter. Cette article était pour :

1. Vous, les méchants utilisateurs qui vous croyez plus malin que les professionnels de l’informatique (et c’est parfois le cas…^^).
2. Vous, les méchants tyrans d’administrateurs qui empêchez ces pauvres utilisateurs de faire n’importe quoi travailler, sans le moindre remord.

De mon côté je n’avais jamais testé ce système de tunnel SOCKS et j’avoue que je suis un peu bluffé par la simplicité de mise en oeuvre avec mon serveur et PuTTY, d’une part. Et la difficulté que j’ai de l’autre côté à mettre en place des règles de détection « un peu malines » pour baffer les utilisateurs réfractaires à la bonne parole de dieu du RSSI… Et du coup, je serais sereins la prochaine fois que je serai en mission à l’hôtel avec un choix cornélien pour ma navigation perso :

• entre le wifi pourri de l’hôtel écouté par les chinois, les russes et nos barbouze ;
• et le VPN du boulot surveillé comme la frontière mexicaine depuis l’arrivée de Trump…

Bon sur ce, je vais aller fouetter des méchants utilisateurs moi. Byz.