Tunnels SSH

[Laurent Caillette]

Voici un petit retour d'expérience sur la création de tunnels avec SSH. 

Nous déployons des serveurs hébergés par OVH. Chaque serveur est protégé par un pare-feu ASA en mode transparent. Les serveurs ne sont accessibles depuis Internet que par des machines dont l'IP est identifiée (liste blanche). On veut établir un tunnel SSH pour accéder à ces machines par HTTPS à partir d'une IP non-autorisée, par exemple celle assignée par un fournisseur d'accès Internet. Il faut alors la bonne clé privée, donc ça reste sécurisé.

Question subsidaire : ça doit fonctionner depuis une machine virtuelle Virtual Box avec un réseau "Host only".

== Précisions techniques

Le pare-feu ASA est un boîtier vendu par Cisco et installé par OVH. Il ajoute une latence non-mesurable, et offre énormément de possibilités de configuration. La principale fonction exploitée ici est le filtrage des adresses d'origine, ainsi que les protections standard contre diverses attaques au niveau TCP.

Un pare-feu en mode transparent se comporte comme un câble réseau intelligent. Le contraire du mode tranparent, c'est le mode routeur, qui nécessite d'indiquer une passerelle pour sortir du sous-réseau. Pourquoi le mode transparent ? Parce qu'OVH n'en supporte pas d'autre pour l'instant.

Les serveurs choisis sont du type "Infrastructure" c'est à dire qu'ils disposent de deux cartes réseau. L'une (eth0) est accessible à partir d'Internet. L'autre (eth1) accède à un réseau virtuel (Vrack) reliant les machines d'un même propriétaire. Le pare-feu ne protège que eth0.

Les serveurs physiques peuvent héberger plusieurs démons (serveurs applicatifs). Pour que les ports ouverts soient toujours les mêmes, un démon n'écoute que sur une seule adresse, qui correspond à la résolution de son nom de domaine. Si un serveur reçoit une requête HTTPS qui ne contient pas le nom de domaine attendu, il redirige vers la page d'accueil (avec le bon nom de domaine).

== Pourquoi du filtrage par adresse IP

Le filtrage par IP limite la vulnérabilité à toutes sortes d'attaques genre déni de service. Il est rarement mis en place, car c'est peu fréquent de connaître l'intégralité des IP des machines qui peuvent se connecter. Une telle chose peut arriver pour une société avec un petit nombre de clients, qui maîtrisent bien leur infrastructure réseau.

Bien sûr une adresse IP peut se falsifier, donc ce type de filtrage ne se substitue pas à toutes les autres mesures de sécurité.

Il faut également que les machines ainsi protégées n'aient pas besoin de recevoir des requêtes initiées par une machine dont l'adresse change fréquemment.

== Contournement

La solution consiste à passer par un serveur de rebond, dont le pare-feu ne filtre pas les adresses d'origine. Le tunnel SSH passe alors par le Vrack, et débouche ensuite sur l'adresse IP du serveur auquel on veut se connecter. Techniquement parlant, le serveur SSH de la machine où s'effectue le rebond devient le client de la connexion vers la machine cible. 

On a donc deux tunnels, mais avec la bonne configuration il n'y a qu'une seule commande à lancer. SSH sait mettre des tunnels bout à bout. Une solution inélégante mais équivalente consiste à ouvrir une session SSH sur la machine de rebond, à partir de laquelle on ouvre manuellement une deuxième session vers la machine cible.

Le prérequis pour ce que nous allons voir est le déploiement de sa clés publique SSH sur la machine de rebond et la machine cible.

== La base des tunnels SSH

On parle de tunnel mais le terme utilisé dans la documentation est le transfert de port ("port-forwarding"). L'idée de base consiste à établir une connexion quelque part sur un port donné, mais magiquement le tuyau apparaît sur un autre port, généralement sur une autre machine. Il existe trois sortes de transfert de port.

=== Transfert de port local ("local") 

Une fois établi le transfert de port, en se connectant à un port local on "ressort" sur une machine distante, sur un port donné. Bien sûr le tuyau entre les 2 machines s'appuie sur les mécanismes cryptographiques de SSH.

=== Transfert de port distant ("remote") 

Une fois établi le transfert de port, un port est ouvert sur la machine distante. En s'y connectant, on ressort sur la machine locale, sur un port donné. On parle aussi de tunnel inverse, puisque c'est la machine locale qui initie la connexion, mais la machine distante aura l'impression d'initier une connexion vers la machine locale. 

Bien sûr c'est ce qu'on utilise pour franchir un pare-feu qui ne permet d'initier les connexions que dans une seule direction, et qu'on est du mauvais côté.

=== Transfert de port dynamique ("dynamic")

Une fois le transfert de port établi, on a un proxy SOCKS sur la machine locale est les connexions ressortent sur la machine distante. Nous ne parlerons pas de ce type de transfert de port.

== Rebond avec SSH

Le fichier `~/.ssh/config` permet de préciser toutes sortes de choses. Notamment :

- propager la clé publique en cas de rebond ;

- des alias pour des éléments de configuration qui correspondent à des serveurs.

Disons qu'on a les machines suivantes :

- `bounce` (machine utilisée pour le rebond)

  - IP sur eth1 : 172.16.0.1 (côté Vrack)

- `demo` (machine protégée par un filtrage par IP)

  - IP sur eth1 : 172.16.0.2 (côté Vrack)

  

Bon je ne recopie pas la doc de SSH, on se contentera du résultat. Le fichier de configuration SSH :

<<<

Host *

  ForwardAgent yes

Host bounce-vrack

  User <some-user>

  ProxyCommand ssh <some-user>@bounce -W %h:%p

  Compression no

>>>

`ForwardAgent` propage la clé publique pour éviter d'avoir à saisir son mot de passe à la création du second tunnel. `Compression no` évite de recompresser un flux déjà compressé.

Pour créer un tunnel du port 8443 vers le port 8443 de la machine cible :

<<<

ssh -vN -o HostName=172.16.0.2 -L 8443:demo:8443 bounce-vrack

>>>  

Si on veut ouvrir une session SSH interactive toute simple on ajoute cette entrée dans le fichier de configuration :

<<<

Host demo

  User <some-user>

  ProxyCommand ssh <some-user>@bounce -W %h:%p

  HostName 172.16.0.2

>>>

Et il n'y a plus qu'à faire :

<<<

ssh demo

>>>

== Sortie d'une VirtualBox Windows

Considérons le cas d'une VirtualBox avec Windows (installé par exemple grâce à l'admirable IEVMS). Une configuration raisonnable consiste à créer 2 interfaces virtuelles, une de type "NAT" pour aller sur Internet, et l'autre de type "Host only", qui définit un sous-réseau commun entre la machine qui héberge et les machines virtuelles hébergées.

Dans le cas de Mac OS X au moins, la machine virtuelle hébergée est considérée comme extérieure par le pare-feu, ce qui est tout à fait correct. Mais voilà, on voudrait que la machine hébergée puisse bénéficier du tunnel créé précédemment.

Comment sortir ? Grâce à un tunnel inverse bien entendu. Cela exige au préalable d'installer un serveur SSH tournant sur Windows.

Je n'ai pas réussi à automatiser l'installation de sshd avec Cygwin, alors j'ai choisi la facilité avec l'excellent "Bitvise SSH server"

https://www.bitvise.com/ssh-server

qui est un produit commercial, mais dont l'utilisation est gratuite pour des particuliers.

Une fois installé Bitvise SSH server, on génère une paire de clés du côté de la machine qui héberge la machine virtuelle. On récupère la clé publique côté machine virtuelle hébergée (avec un partage de fichier VirtualBox par exemple), et on l'assigne à l'utilisateur de son choix (`IEUser` si on se base sur IEVMS). Après il faut redémarrer Windows pour activer les options d'authentification de Bitvise.

Si on a configuré sa machine virtuelle avec l'adresse `192.168.100.101` sur le sous-réseau créé avec l'option "Host only", on teste la connexion ainsi :

<<<

ssh -i <private-key> -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no IEU...@192.168.100.101

>>>

Pour faire un tunnel inverse tout seul :

<<<

ssh -i <private-key> -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no  -nNT -R <port_in>:localhost:<port_out> IEU...@192.168.100.101

>>>

Pour utiliser le tunnel créé précédemment (celui vers `demo`) on ajoute une entrée dans le fichier de configuration SSH :

<<<

Host vboxguest

  HostName 192.168.100.101

  User IEUser

  UserKnownHostsFile /dev/null

  StrictHostKeyChecking no

  IdentityFile <private-key>

  Compression no

>>>

Et après on lance :

<<<

ssh -vnNT -R 443:localhost:8443 vboxguest

>>>

On démarre les deux tunnels (celui de VirtualBox en dernier) et on peut alors se conncter avec un navigateur à partir de Windows.

== Bonus : utiliser le vrai nom de hôte

La commande là-dessus permet de se connecter à `localhost:443`, mais que se passe-t-il si on a besoin de tester un logiciel qui veut impérativement se connecter à `demo:443` ?

Dans Windows il suffit d'ajouter la ligne suivante dans le fichier `C:\Windows\system32\drivers\etc\hosts` :

<<<

127.0.0.1 demo

>>>

== Conclusion

Encore une fois on est impressionné par la puissance de SSH. J'espère que ces explications donneront des idées pour faire des trucs sympas. Le rebond avec SSH n'est pas expliqué très souvent, et l'installation d'un serveur SSH sur Windows demeure une possibilité méconnue. 

== Références

http://rubenlaguna.com/blog/2014/06/10/ssh-port-forwarding-through-multiple-hops-slash-dot-ssh-slash-config-slash

https://www.virtualbox.org/manual/ch06.html#network_hostonly

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1?query=ssh&sec=1

[Dominique Jocal]

Merci pour le rex.

Marrant, ici aussi on bascule vers de l'hébergement externe, mais on en profite pour déléguer aussi la gestion du serveur: donc Paas, Saas, que du git push public (Certes chiffré.. av ssh) et des commandes https 'publiques'.

Mais le besoin de chemin réseau privé est super compréhensible, même sans 'shell' sur la machine. on verra vers quoi l'industrie ira ds les mois/années à venir.

D

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+un...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Julien Kirch]

Sur le PaaS Amazon EC2 ils ont une super interface « security group » pour filtrer les accès par IP et par port et par groupe de machines, ça permet de se faire des DMZ de manière très facile, surtout quand tu gères ça avec de la configuration automatisée.

Julien

[Laurent Caillette]

Salut Dominique,

Avec toute la vague devops et l'externalisation de l'hébergement, le shell va se démocratiser. Là je faisais une démo à mon boss et il tapait des commandes en ligne ; pour la maintenance à distance c'est bien plus pratique que l'interface graphique.

J'ai l'impression que tu confirmes : git est en train de devenir le middleware ultime. Je n'en suis pas à déployer avec mais ça viendra, c'est ridicule de construire un livrable sur un laptop pour transférer après une archive de 50 Mo par le Wi-Fi. Rien que pour la doc c'est fantastique, même si le générateur de doc de github est une poubelle leur publication instantanée lors d'un git push rend le truc trop attrayant. 

Pour le Paas/Saas il y a également des possibilités d'automatisation fantastiques, mais l'enfer est dans le détail. Pour l'instant j'ai quand même eu pas mal de difficultés avec les différences entre les machines d'OVH et une VBox Debian 7 standard, avec les interfaces qui ne sont pas nommées pareil, le NFS, etc. Le but reste bien sûr de tester un déploiement hors-ligne rien qu'avec des machines virtuelles dans ton laptop qui te chauffe les cuisses.

c.

[Julien Kirch]

Sur le PaaS Amazon EC2 ils ont une super interface « security group » pour filtrer les accès par IP et par port et par groupe de machines, ça permet de se faire des DMZ de manière très facile, surtout quand tu gères ça avec de la configuration automatisée.

Julien

Le 4 nov. 2015 à 09:15, Dominique Jocal <domi...@jocal.name> a écrit :

[Laurent Caillette]

Salut Julien,

L'hébergement sur EC2 c'est tentant des fois, surtout que l'ASA offre pas mal de possibilités de faire des bêtises (surtout quand le support d'OVH en rajoute). Et tu te retrouves avec une interface de déploiement normalisée au lieu de tout réinventer avec Ansible. Cela dit avec le peu que j'ai vu des AWS (avec S3 que j'utilise pour les sauvegardes), j'ai l'impression que chez Amazon ils ne sont pas trop pressés de te laisser tester leur infrastructure en local (JT va peut-être réagir là-dessus). J'avoue ne pas savoir ce qui se fait ailleurs.

Après c'est un choix de ma part, je préfère éviter diverses couches de virtualisation, savoir exactement où sont les données, ce qui se passe dans mes serveurs, et avoir un humain au bout du fil si ça pète. Le discours qu'on souhaite tenir à la clientèle n'y est pas étranger non plus.

c.

[Sylvain Rey]

Hello tout le monde

Merci pour le retour d'expérience !

Je rebondis sur les Cisco ASA en mode transparent chez OVH, ça veut dire qu'on oublie de suite d'établir un VPN par ce biais. C'est super frustrant.

Chez Azure, on peut faire du point-to-site et du site-to-site assez facilement (l'interface génère même les scripts de configuration pour les différents types de VPN courant (de tête au moins Cisco ASA, Juniper, Windows RRAS...) MAIS ils imposent beaucoup de paramètres - c'est très peu configurable. Du coup, si on se retrouve avec des contraintes particulières - e.g. un vieux tunnel qui utilise encore SHA-1 - on se retrouve le bec dans l'eau.

La solution chez OVH ressemble évidemment à ce que tu décris pour un tunnel SSH : c'est d'utiliser un autre server (rebond) avec deux ports ethernet et de le configurer en VPN software.
Du coup, pour être franc, j'hésitais un peu...
L'idéal ça serait quand même un hébergeur qui propose le site-to-site avec un bon niveau de configurabilité. Mais est-ce que ça existe ?

Sylvain

[Julien Kirch]

C'était pas pour encourager à passer sur Amazon mais plutôt pour donner un exemple oú un vendeur de PaaS facilite ce genre d'approche.

Julien

[Laurent Caillette]

Salut Sylvain,

Merci pour l'éclairage VPN, ça me permet de comprendre que je suis plus ou moins en train de réinventer ça. 

On dirait que l'infrastructure d'OVH est prisonnière d'un certain modèle de routeurs. Ils ont du trouver génial la fonctionnalité de Vrack (et c'est vrai) mais il doit y avoir des limitations au niveau du câblage (pure hypothèse, hein). Du coup fin 2014 ils annonçaient qu'ils allaient mettre au point leur propre routeur, et maintenant le Vrack est paraît-il accessible à des serveurs avec une seule interface réseau. Mais comme d'habitude il faut vérifier auprès du support, et tomber sur le bon gars.

Cela dit le peu que j'ai vu des VPN, au moins sur Mac, ne m'a pas donné envie de poursuivre dans cette voie. Bon je ne cherchais pas à relier deux sites, plutôt à surfer de façon anonyme à partir d'un Wi-Fi non-sûr. La moindre des choses c'est de couper l'accès Internet si le VPN a un problème, et de ne pas retomber sur la connexion non-sûre. Eh bien pas moyen de trouver un machin OSS qui fasse ça ; et la seule solution payante était une bidouille avec Little Snitch. Et plus je lisais de la doc moins ça m'avait l'air propre, ces engins.

Depuis j'ai découvert un outil vraiment sympa : sshuttle, qui se comporte comme un VPN, mais en se basant sur SSH. Il peut transférer n'importe quelle adresse et n'importe quel port, ou seulement certaines adresses. Et sur le serveur c'est juste un script Python à lancer.

https://github.com/apenwarr/sshuttle

Je n'ai pas encore essayé, quelqu'un connaît ?

c.

[Henri Tremblay]

Quand tu as juste quelques machines connus, le tunnel ssh est très efficace. Un VPN, c'est plutôt pour un datacenter avec plein de machines au hasard. Tu sais jamais trop où tu vas devoir te connecter.

Amazon permet de faire des VPC en plus des security groups. Donc tu isoles tout sauf tes frontend qui eux exposent par exemple le port 80. J'ai un petit blanc sur comment s'y connecter mais je pense que tu utilises une machine de rebond pour entrer dans le VPC et ensuite tu vas où tu veux.

Si vous ne voulez pas vous casser la tête, il y a le niveau supérieur. Heroku, GAE, Cloud Foundry. Ils gèrent la sécurité pour toi. Pour Heroku, tu fais un git push et tu as pas mal fini de réfléchir.

[Philippe Kernévez]

J'utilise TunnelBlick sur Mac pour me connecter un à un serveur OpenVPN distant sans aucun soucis. 

(je m'en sers occasionnellement, pas tous les jours et pas toute la journée).

Avant j'utilisais un tunnel SSH mais on est passé à un public plus large (tous les consultants et non plus les admins infra).

a+

Philippe Kernévez



Directeur technique (Suisse),
pker...@octo.com
+41 79 888 33 32

Retrouvez OCTO sur OCTO Talk : http://blog.octo.com
OCTO Technology http://www.octo.com

[Stéphane Tsacas]

2015-11-04 8:07 GMT+01:00 Laurent Caillette <laurent....@gmail.com>:

Voici un petit retour d'expérience sur la création de tunnels avec SSH. 

Nous déployons des serveurs hébergés par OVH. Chaque serveur est protégé par un pare-feu ASA en mode transparent. Les serveurs ne sont accessibles depuis Internet que par des machines dont l'IP est identifiée (liste blanche). On veut établir un tunnel SSH pour accéder à ces machines par HTTPS à partir d'une IP non-autorisée, par exemple celle assignée par un fournisseur d'accès Internet. Il faut alors la bonne clé privée, donc ça reste sécurisé.

que par ? Que par + exceptions ? Accéder légalement à un service à partir d'IP non autorisées ?

Ça n'a aucun sens.

 

Question subsidaire : ça doit fonctionner depuis une machine virtuelle Virtual Box avec un réseau "Host only".

== Précisions techniques

Le pare-feu ASA est un boîtier vendu par Cisco et installé par OVH. Il ajoute une latence non-mesurable,

Plus personne ne croit en ce bs marketing, sauf si d'un seul coup on considère un délais de quelques millisecondes "non mesurable". Cisco mesure parfaitement la latence de ses switches, difficile de croire que celle d'un ASA serait tellement inférieure qu'elle en deviendrait "non mesurable" !

 

et offre énormément de possibilités de configuration. La principale fonction exploitée ici est le filtrage des adresses d'origine, ainsi que les protections standard contre diverses attaques au niveau TCP.

Un pare-feu en mode transparent se comporte comme un câble réseau intelligent.

Un peu comme l'amplificateur parfait serait décrit comme "the perfect amplifier is a straight wire with gain" (Peter Walker). C'est encore du marketing.

AMHA si on place des firewalls en mode bridge c'est parce qu'ils sont placés à des endroits où les restrictions qu'ils imposent ne s'appliquent pas, et d'autre par pour leur facilité d'administration (moins pénible qu'un truc qui touche à tes entêtes IP).

Je ne sais pas où ils mettent leurs ASA, mais fort à parier qu'ils sont en config redondante (cluster d'ASA sandwichés entre deux switches).

Stéphane

ps; une façon d'installer un serveur SSH sur un windows est de passer par cygwin.

 

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+un...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

Stephane
FreeDonne Join FreeDonne - Rejoignez FreeDonne.

[Laurent Caillette]

Salut Kernie, 

Merci pour TunnelBlick. Il y a un commentaire quelque part au fond d'un forum qui affirme qu'il y a moyen d'associer un script à une action pour implémenter le kill switch. Ça reste maigre.

Salut Stéphane, 

Je reformule : le pare-feu bloque toutes les IP qui ne sont pas sur une liste blanche. Si tu travailles de chez toi, tu as une adresse affectée par ton FAI, qui peut être recyclée à tout moment et donc il ne faut pas la faire figurer sur la liste blanche. Mais tu veux quand même te connecter, donc tu fais le tour par un autre serveur. Dis-moi ce qui n'est pas clair, mais tu peux partir du principe que ça a du sens.

Pour la latence non-mesurable, je n'ai pas vu de différence sur la moyenne des latences lors d'un ping, donc j'emploie le terme de non-mesurable pour décrire mon incapacité à fournir une mesure, du fait du bruit généré par le passage à travers Internet. J'imagine que Cisco effectue des mesures plus précises et fournit des chiffres tout à fait flatteurs, mais je n'ai pas regardé.

L'expression "câble réseau intelligent" est de moi. C'est pour mentionner que le pare-feu n'apparaît pas dans les paramètres de connexion, ce qui m'a un peu troublé au début (il y a partout des schémas où le routeur/passerelle/pare-feu a sa propre adresse visible du sous-réseau).

Tu as du lire un peu vite, je mentionne bien Cygwin et sshd. Si tu as une solution toute faite pour l'installer automatiquement sur Seven (sans cliquer nulle part) fais-m'en part, ça m'intéresse.