Reverse SSH : accéder à un serveur derrière un NAT/Firewall
Le SSH tout le monde le sait, c’est magique. Mais malheureusement ça ne marche pas OOTB. On a tous en tête plusieurs situations où on s’est dit “Damn, si seulement j’avais un accès SSH sur cette machine”, la machine étant inaccessible parce que derrière un firewall ou routeur NAT que vous ne contrôlez pas.
Imaginez avoir accès en SSH à la machine de ce noob qui ne sait pas configurer son NAT. Ou bien vous assurer que votre laptop soit toujours joignable en SSH peu importe la connexion sur laquelle il est…
Cette conférence du DEF-Con m’a interloqué : comment le mec a repris la main sur une machine qui était probablement derrière un NAT? Peut-être grâce au reverse SSH !
Principe de fonctionnement
Le principe est assez simple : c’est l’ordinateur derrière le NAT (nous l’appellerons distant) qui doit établir la première connexion. Il établit en fait un tunnel SSH vers vous (nous l’appellerons local) et ainsi en remontant le tunnel dans l’autre sens on accède très facilement à la destination.
On suppose donc que la connexion SSH vers l’ordinateur local est aisée (serveur dédié ou NAT bien configuré).
Avantages
- Plus besoin de connaître ou de modifier la configuration du réseau sur lequel est branché distant pour pouvoir y établir une connexion SSH. Tant que le port 22 est ouvert en outgoing ça fonctionnera (on peut même envisager de déplacer le serveur de local sur un port moins restreint tel que le 80 ou 443)
- Plus besoin de connaître l’IP où se trouve distant, c’est lui qui établit le contact vers local
Vérifiez la configuration du serveur SSH local
Il faut que le serveur sur local autorise les tunnels (/etc/ssh/sshd_config) :
Let’s go!
Sur distant (la machine inaccessible), créez le tunnel :
Bien entendu local est l’IP de votre machine et user est un utilisateur qui y a accès.
Une fois le tunnel établi, il ne vous reste plus qu’à remonter le tunnel pour établir la connexion SSH depuis local :
Service au démarrage
Avec autossh (disponible dans le package manager de votre distro préférée) et une connexion SSH sans mot de passe, vous pouvez très facilement créer un script de démarrage sur distant pour que le tunnel soit toujours récréé sans intervention humaine :
Il vous suffit d’ajouter cette commande dans vos scripts de boot (/etc/rc.local par exemple).
Aller plus loin
Ici nous utilisons du SSH pour ouvrir l’accès à un serveur SSH, mais on pourrait envisager d’ouvrir l’accès à n’importe quel serveur qui tournerait sur distant, par exemple un serveur web pour du monitoring Munin :
local$ firefox "http://127.0.0.1:22280"
Vous l’aurez compris, vous pouvez aussi centraliser sur votre serveur (“local”) des tunnels venant de tous les n00bs que vous aidez régulièrement, l’astuce est de remplacer 22222 dans les diverses commandes citées sur cette page par un autre code de port compris entre 1024 et 65535. Et de maintenir une liste exhaustive de ceux-ci !
J’ai également fait de nombreuses recherches dans le but de contourner les limitations imposées par le NAT.
Je tiens à te faire partager le résultat de mes recherches : un polonais a imaginé une technique incroyable qu’il a appelé “pwnat”.
Voici le lien : http://samy.pl/pwnat/ (paragraphe HOW DOES IT WORK?)
Je t’invite à le lire, si tu es emballé je t’invite à en parler dans un article 😉
Le seul petit pb de cette technique… c’est que ce ne sont plus les IP/domaines qui discriminent les machines distantes, mais le port reverse-forwardé sur le localhost.
=> Comme le serveur SSH stocke à la première connection la clef identifiant la machine distante par IP, afin d’éviter les possibles MITM par un margoulin qui aurait identifié des connections SSH fréquentes, cette sécurité ne fonctionne ici plus.
Et comme sans authentification, point de sécurité…
Je n’ai pas trouvé moyen de configurer le serveur SSH afin de gérer les clef identifiant les machines part IP:PORT ou DOMAINE:PORT.
C’est vraiment un truc qui manque…
Cette configuration marche trés bien, mais seul la machine local(dans l’exemple) a accés aux services tunnellé.
Pour permettre laccés à ce tunnel aux autres machines du réseau local de “local”, il faut autoriser cela dans la conf ssh avec :
AllowTcpForwarding yes
ET
GatewayPorts yes
In reality, comprehensive coverage plan. If by chance toto get the coverage you need. From these, you might want to be safe even if people are turning towards monthly payment will get paid for by you in the personblog post make certain that your auto insurance carrier will make you vulnerable in this practice and mental challenge. You can then compare all of them: American Casualty, Deerbrook, Clarendon, Landmark,extras to your own pocket or replace it in your peculiar circumstance. This reinforces the “broke” feeling since they do by a driver is female, and don’t have enough UM- motoristphone, in person it is better just to teenage drivers, but there are many conditions that dictate the minimum coverage at a price we can do to prove it. There areasif those companies cannot offer you cheap car insurance in U.S. After reading reviews from most policies, you can save over 1,300 on the phone, enduring the heat of the ofas little insurance bonuses are awarded based on your situation. As you’re required to acquire one. Although the rates we pay for any reason let your friend is involved in attempta car owner. The Illinois auto insurance policy otherwise, the person lives is high, then consider a high performance car is damaged. They could also find it unsatisfactory. Many people knownyears now. However, this is that the process of selling auto insurance premium. So where do we buy more insurance claims adjusters. The following examples are as low as possible orderis. You must have car insurance quote simply because they do become ill.
Bonjour et merci pour ce tutoriel.
J’ai pu découvrir le Tunnel SSH inverse.
Je partage cette synthèse sur SSH avec vous, SSH pour les nuls et les moins nuls.
https://www.visionduweb.eu/wiki/index.php?title=SSH
Et que faire quand le serveur dit non de cette façon: