Tunnels : introduction

Travaux dirigés
1er février 2016

Travaux
Dirigés

“Tout est dans tous, et vice et versa.”

Alphonse Allais

CDT Yohan DUBANCHET

Cours Sécurité Réseaux
yohan.dubanchet@intradef.gouv.fr
 Table des matières

1 Les bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Principe 5
1.2 Première connexion 5
1.3 Utilisation de netcat pour transmettre le contenu d’un fichier 6
1.4 Utilisation de Netcat pour exécuter des commandes 7

2 Au travers des continents... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 SSH 8
2.2 Seconde authentification 9
2.3 Quelques recommandations SSH 10
2.4 Premier tunnel 11
2.5 Tunnelception 12

3 Tunnels ludiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Tunnel HTTP 14
3.2 Tunnel DNS 15

4 Tunnel GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Principe 17
4.2 Objectif 19
4.3 Mise en œuvre 19
4.4 Mise en place de la structure 20
4.5 Mise en place du tunnel GRE 20
 2

4.6 Vérification 22

5 Tunnel SSH avancé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Montage d’un lecteur réseau au travers d’une connexion SSH 25
5.2 Pivot SSH 25

TD-Tunnels Version 1.0b

 Généralités

Dans notre contexte, la notion de tunnel est une image permettant d’illustrer l’éta-
blissement d’une liaison entre deux extrémités.
Cette liaison peut être réalisée avec ou sans chiffrement. On parle de tunnel clair ou
chiffré.
Les informations transmises peuvent être intelligibles ou chiffrées mais cette notion
est indépendante de celle du tunnel. Sauf cas particulier, le contenu n’est pas dépendant
du contenant.
Des tunnels clairs (GRE) peuvent transporter des flux chiffrés (HTTPS), des tunnels
chiffrés (IPSEC) peuvent transportes des flux clairs (HTTP).
Les extrémités peuvent être réalisées par une simple application, support d’une liaison
entre deux postes locaux, comme elles peuvent être construites sur des équipements
dédiés, supports de toute l’infrastructure nécessaire au chiffrement (AC).
La mise en œuvre de tunnel consiste à encapsuler des protocoles de communication
dans des protocoles de communication. La méthode académique consiste à intégrer IP dans
IP mais d’autres combinaisons sont possibles. Motivé par un objectif de contournement de
sécurité ou d’évasion de données, des développeurs proposent des applications permettant
de réaliser des tunnels de type IP dans ICMP ou IP dans DNS. Plus subtils, des
outils comme SSH permettent de réaliser des tunnels de niveau Ethernet dans IP. Un
autre objectif peut être aussi de ralentir la découverte des extrémités des tunnels. En
encapsulant des tunnels, une série de bonds peut être réalisée afin de rendre plus complexe
l’identification de la première extrémité (RPV).
Dans l’approche académique, l’objectif est de créer un support de communication
sécurisée entre deux entités : des réseaux privés virtuels.
Dans nos architectures, les solutions les plus couramment déployées pour rapprocher
des LAN sont le protocole GRE (tunnel clair) et le protocole IPSEC (tunnel chiffré).
Les solutions de tunnels chiffrés utilisant du chiffrement gouvernemental font l’objet
de formations spécifiques au sein de la division cyber. Dans ce support, nous ne traiterons
ces concepts en utilisant uniquement des outils de chiffrement civil.
Afin de bien comprendre ces concepts, ce TD permettra de faire un tour d’horizon
de ces mécanismes.
 4

Figure 1: Encapsulation GRE

Figure 2: Echinops Thales

Figure 3: Encapsulation IPSEC

TD-Tunnels Version 1.0b

Principe
Première connexion
Utilisation de netcat pour transmettre le
contenu d’un fichier
Utilisation de Netcat pour exécuter des com-
mandes

1. Les bases

1.1 Principe
NetCat est aussi appelé le couteau suisse de l’administrateur réseau. Il permet la
réalisation de communications entre deux extrémités de façon très simple. Cet utilitaire
peut aussi bien assurer la fonction de serveur que la fonction de client. Le statut de
serveur consiste à être en écoute sur un port ; il reste en attente d’une connexion entrante.
Le statut de client consiste à émettre des paquets depuis un port source vers une adresse
IP et plus spécifiquement sur un port destination. Si le port destination correspond à
celui d’un serveur en écoute, une connexion pourra s’établir.

1.2 Première connexion

Dans un premier temps, utilisez deux postes physiques. Afin de les identifier, relevez
leur adresse IP sur le réseau de la salle de cours.
• ouvrez un terminal (touche F12),
• connectez vous en root (su), mot de passe : toor,
• exécutez la commande :

ip a

Une fois vos adresse IP obtenues, désignez un poste serveur.

Exécutez la commande suivante afin de réaliser votre premier serveur netcat :

nc -l -p 1234

Rmq L’argument -l correspond au mode écoute et -p permet de spécifier le port (le port
1234 dans notre exemple).
 1.3 Utilisation de netcat pour transmettre le contenu d’un fichier 6

Question 1

Dans un autre terminal, en utilisant la commande netstat, comment afficher le PID

du processus nc (Netcat) ?

Depuis le second poste, en remplaçant les valeurs XX par l’adresse IP de votre seveur,
exécutez la commande suivante afin de réaliser votre premier client Netcat :

nc XX.XX.XX.XX 1234

Tout en utilisant les deux terminaux comme support de messagerie instantanée,

utilisez Wireshark pour visualiser l’établissement de la connexion TCP. La combinaison
de touche CTRL + c vous permet de stopper la commande en cours d’exécution dans
un terminal.

Question 2

Quel est le port source utilisé par votre client Netcat ?

1.3 Utilisation de netcat pour transmettre le contenu d’un fichier

1.3.1 Sur le poste récepteur
Exécutez la commande suivante afin de réaliser votre premier serveur Netcat qui
redirige ce qu’il reçoit sur un fichier :

nc -l -p 1234 > destination.fichier

1.3.2 Sur le poste émetteur

Créez un fichier :

echo "je suis un du texte" > source.fichier

Transférez le contenu du fichier vers le serveur distant :

nc -q 0 XX.XX.XX.XX 1234 < source.fichier

1.4 Utilisation de Netcat pour exécuter des commandes

1.4.1 Sur le poste serveur
Exécutez la commande suivante afin de réaliser un serveur Netcat qui redirige ce
qu’il reçoit sur un interpréteur de commandes :

nc -e /bin/sh -l -p 1234

! Un arrêt du programme exécuté par le client sur le serveur provoque la fermeture

de Netcat.

TD-Tunnels Version 1.0b

 1.4 Utilisation de Netcat pour exécuter des commandes 7

1.4.2 Sur le poste client

Connectez vous au serveur :

nc XX.XX.XX.XX 1234

Les commandes que vous saisissez dans le terminal s’exécutent sur le serveur distant.
Exemple : eject ou poweroff

On peut constater que cet accès anonyme et non maitrisé n’est pas acceptable. Il est
nécessaire de mettre en oeuvre une solution permettant d’authentifier les utilisateurs.

TD-Tunnels Version 1.0b

 2. Au travers des continents...

2.1 SSH
Pour la suite de ce TD, les serveurs utilisés sont virtuels. Votre poste physique sera
situé à Paris, deux machines virtuelles seront située à Tokyo et Sydney 1 2 .

1. Canberra est la capitale de l’Australie et du Territoire de la capitale australienne. La ville est

située à l’extrémité nord du territoire de la capitale, à 280 kilomètres au sud-ouest de Sydney et à 680
km au nord-est de Melbourne. Le site de Canberra a été choisi comme capitale australienne en 1908 ; ce
choix fut un compromis entre les deux villes rivales de Sydney et Melbourne, les deux plus grandes villes
d’Australie. Le terme de « canberra » désigne un « lieu de rassemblement » en ngunawal, la langue
aborigène locale.
2. la note de bas de page précédente a finalement assez peu de rapport avec le td.
 2.2 Seconde authentification 9

Ces serveurs virtuels sont accessibles via le raccourcie ”support” situé sur votre bureau.
L’hyperviseur utilisé est VirtualBox ; à partir de son interface, démarrez le serveur Tokyo.
Votre objectif est d’administrer ce serveur. Vous disposez de l’utilitaire Telnet.
L’adresse du serveur est 192.168.56.101.

Rmq Telnet (TErminaL NETwork ou TELecommunication NETwork, ou encore TE-

Letype NETwork) est un protocole utilisé sur tout réseau TCP/IP, permettant
de communiquer avec un serveur distant en échangeant des lignes de textes et en
recevant des réponses également sous forme de texte. Source Wikipédia

2.1.1 Authentification par Telnet

Tout en réalisant une capture Wireshark en écoutant le traffic sur l’interface vboxnet0,
connectez-vous au serveur Tokyo. Le compte utilisateur est stagiaire, son mot de passe
est stagiaire.

Question 3

Déconnectez vous et analysez la capture. Retrouvez-vous votre mot de passe ? Cette

solution n’étant pas acceptable, un autre protocole de communication doit être mis
en œuvre.

2.2 Seconde authentification

La connexion au serveur Tokyo fait transiter les paquets par des zones non maitrisées.
La mise en œuvre d’un outil permettant d’assurer une authentification sécurisée, puis un
chiffrement des données transmises, est la solution.

Rmq Secure Shell (SSH) est à la fois un programme informatique et un protocole de

communication sécurisé. Le protocole de connexion impose un échange de clés
de chiffrement en début de connexion. Par la suite, tous les segments TCP sont
authentifiés et chiffrés. Source Wikipédia

TD-Tunnels Version 1.0b

 2.3 Quelques recommandations SSH 10

Question 4

Déconnectez vous et analysez la capture. Quelles sont les versions d’OPEN SSH
mises en œuvre ? Connaissez-vous la phase d’échange de clés DiffieHellman ?

2.3 Quelques recommandations SSH

Avant de poursuivre l’exploitation du tunnel, voici quelques bonnes pratiques à
appliquer. Sur le poste client Paris, générez des clés d’authentification. Une clés publique
(id rsa.pub) qui sera déployée sur le serveur et une clés privée (id rsa) que vous protégerez.

ssh-keygen -V +45d -t rsa -b 3000

Cette clés générée a une durée de validité de 45 jours (cf. PSSIA) et une taille
minimun de 2048 bits (préconisation de l’ANSSI).
Une fois cette opération réalisée, la clés publique doit être transférée sur le serveur.
Connectez-vous au serveur afin de créer sa zone de stockage :

stagiaire@tokyo:$ mkdir .ssh

stagiaire@tokyo:$ touch .ssh/authorized_keys
stagiaire@tokyo:$ exit

Sur votre poste client, vous pouvez maintenant pousser la clé vers le serveur en
utilisant la commande : ssh-copy-id

ssh-copy-id -i /home/stagiaire/.ssh/id_rsa.pub 192.168.56.101

Vous pouvez tester son déploiement :

ssh -i .ssh/id_rsa stagiaire@192.168.56.101

Une fois connecté sur le serveur, connectez-vous avec le compte root (su). Éditez le
fichier /etc/ssh/sshd config afin d’y intégrer les éléments suivants :

TD-Tunnels Version 1.0b

 2.4 Premier tunnel 11

ListenAddress 192.168.56.101
AllowUsers stagiaire
PasswordAuthentication no
PermitRootLogin no

Relancez, le service (/etc/init.d/ssh restart),et reconnectez-vous. Vous disposez

maintenant d’une connexion sécurisée avec un point de sortie à Tokyo.

2.4 Premier tunnel

Démarrez la seconde machine virtuelle : Sydney. Tout en capturant le traffic réseau
généré, consultez la page web publiée par le serveur de Sydney situé à l’adresse IP
192.168.56.102.

Cette consultation est en claire, et passe par des zones non maitrisées.

L’objectif des commandes suivantes est de faire passer la consultation du serveur

situé à Sydney par le tunnel établi entre Paris et Tokyo.

TD-Tunnels Version 1.0b

 2.5 Tunnelception 12

Le flux clair (représenté en rouge) passera dans le flux chiffré (représenté en noir).
Les flux HTTP passeront dans le tunnel SSH entre Paris et Tokyo.
La commande suivante permet de déporter le port local 2222 de la station cliente sur
le port 80 du serveur Sydney et passant dans le flux SSH destiné à Tokyo.

ssh -i .ssh/id_rsa -L 2222:192.168.56.102:80 192.168.56.101

La consultation du serveur se réalise de la façon suivante :

Ce même procédé va permettre de sécuriser partiellement l’administration à distance.

ssh -i .ssh/id_rsa -L 2223:192.168.56.102:23 192.168.56.101 &

telnet
telnet>open localhost 2223

En synthèse, nous obtenons un flux clair dans un tunnel chiffré.

2.5 Tunnelception
Vous pouvez répéter les étapes précédentes pour obtenir l’architecture suivante :

TD-Tunnels Version 1.0b

2.5 Tunnelception 13

Vous obtenez un flux chiffré dans un flux chiffré. Ce surchiffrement est couramment
mis en œuvre sur les réseaux : dans nos ambassades les flux CD sont encapsulés dans les
flux DR.

TD-Tunnels Version 1.0b

 Ces tunnels sont déployés lorsque l’on souhaite réaliser du contournement de sécurité
ou de l’obfuscation.

3.1 Tunnel HTTP

3.1.1 Objectif
Faire transiter un flux chiffré (SSH) entre Paris et Sydney à travers un flux HTTP
sur le tronçon Paris/Tokyo
Le flux intercepté entre Paris et Tokyo semblera anodin, il apparaitra comme une série
de requête/réponse HTTP.

3.1.2 Pré requis

L’ensemble du répertoire HTTPTunnel doit être déployé sur Tokyo ; vous pouvez
réaliser ce transfert simplement, en utilisant l’utilitaire graphique filezilla.

3.1.3 Principe
Côté HTTPClient : l’application HTTPClient sur le poste Paris est en écoute sur le
port TCP 3000, et retransmet tout ce qu’elle reçoit sur ce port au port 80 du serveur
 3.2 Tunnel DNS 15

HTTPTunnel (Tokyo).

Côté HTTPServeur : Tokyo est en écoute sur le port TCP 80 et retransmet tout ce
qu’il reçoit sur ce port au port 22 de Sydney.

3.1.4 Mise en œuvre

Le fichier de configuration du client a été prérempli avec les éléments suivants :
• serveur HTTPTunnel 192.168.56.101 (Tokyo)
• destination des flux 192.168.56.102 port 22 (Sydney)
Sur le serveur Tokyo, en tant que root, exécutez les commandes suivantes :

/etc/init.d/apache2 stop
perl httptunnel_server.pl

Sur votre poste hôte Paris, en tant que root, exécutez les commandes suivantes :

perl httptunnel_client.pl &

ssh stagiaire@localhost -p3000

La capture des flux, via l’application Wireshark, vous permettra de constater l’en-
capsulation des flux SSH dans un traffic HTTP entre Paris et Tokyo.

3.2 Tunnel DNS

3.2.1 Objectif
Faire transiter un ou plusieurs flux applicatifs (exemple : un flux SSH) entre deux
stations à travers un tunnel DNS.

3.2.2 Pré requis

Pour cette réalisation vous utiliserez deux stations physiques équipées du logiciel
Iodine.

apt-get install iodine

TD-Tunnels Version 1.0b

 3.2 Tunnel DNS 16

3.2.3 Mise en œuvre

Sur la première, en tant que root, exécutez les commandes suivantes (en remplaçant
XX par votre numéro de groupe) :

apt-get install openssh-server

iodined -fP test 10.XX.0.1 domaine.etrs

Sur la deuxième, en tant que root, exécutez la commande suivante (en remplaçant
XX par l’adresse IP de la première station) :

iodine -fP test 172.XX.XX.XX domaine.etrs

Dans un autre terminal exécutez :

ssh stagiaire@10.XX.0.1

Le mot de passe du compte stagiaire est stagiaire. La capture des flux, via l’application
Wireshark, vous permettra de constater l’encapsulation des flux SSH dans un traffic
DNS entre vos deux stations.

TD-Tunnels Version 1.0b

4.1 Principe

Generic Routing Encapsulation (GRE ou Encapsulation Générique de Routage) est

un protocole de mise en tunnel qui permet d’encapsuler n’importe quel paquet de la
couche réseau dans n’importe quel paquet de la couche réseau. Le paquet d’origine (à
gauche en blanc sur le schéma ci-dessus) est le payload du paquet final (rayé de vert sur
ce même schéma).

GRE a été développé par Cisco et peut encapsuler une large gamme de types de
paquets de différents protocoles dans des paquets IP. Les tunnels GRE sont conçus pour
ne pas avoir besoin de maintenir un état, ce qui signifie que chaque terminaison de tunnel
4.1 Principe 18

ne conserve aucune information d’état ou de disponibilité de la terminaison distante.

Cette fonctionnalité aide les fournisseurs d’accès à proposer des tunnels IP à leurs clients,
qui ne sont pas concernés par l’architecture des prémisses du fournisseur d’accès. Ceci
donne aux utilisateurs (les clients du fournisseur d’accès) la flexibilité de configurer ou
reconfigurer leur architecture IP sans être concernés par les problèmes de connectivité,
en créant un lien point à point virtuel vers des routeurs distants à travers des réseaux
IP. (Source Wikipedia)

Rmq Dans nos systèmes militaires, les tunnels de type Generic Routing Encapsulation
permettent le multicast dans des architectures qui ne le supportent pas nativement.

TD-Tunnels Version 1.0b

 4.2 Objectif 19

4.2 Objectif
Monter un tunnel entre deux réseaux locaux au travers d’un WAN.

Figure 4.1: Schéma de principe

L’évaluation du montage se fera par la réalisation de la commande ping et par l’ob-

servation des résultats de la commande tracepath ainsi que par une capture Wireshark.

4.3 Mise en œuvre

Vous effectuerez le TP par binôme. Dans le plan d’adressage IP : S correspond au
numéro de la salle de cours et XX au numéro de groupe. Vous disposez de quatre stations
configurées comme suit :

10.S.XX.0 172.S.0.0 10.S.YY.0

.100 .100
.1 .1
XX.2 YY.2

VBox-XX PC-XX PC-YY VBox-YY

XX Carte Adresse Masque Passerelle
VBox-XX (station virtuelle) eth0 10.S.XX.100 255.255.255.0
PC-XX vboxnet0 10.S.XX.1 255.255.255.0 *
(station hôte) eth0 172.S.XX.2 255.255.255.0
Passerelle par défaut : 172.S.XX.1

YY Carte Adresse Masque Passerelle

VBox-YY (station virtuelle) eth0 10.S.YY.100 255.255.255.0
PC-YY vboxnet0 10.S.YY.1 255.255.255.0 *
(station hôte) eth0 172.S.YY.2 255.255.255.0
Passerelle par défaut : 172.S.YY.1

TD-Tunnels Version 1.0b

 4.4 Mise en place de la structure 20

Le masque est volontairement fixé à /24 sur le réseau 172.XX pour forcer le routage.
Si l’on conserve le /16 (le masque par défaut), dans le contexte de la salle de cours, les
commutateurs laisseront passer les paquets.

4.4 Mise en place de la structure

Les stations virtuelles sont sur des réseaux privés Virtual box.

Rmq Le routage doit être activé sur la station réelle, en utilisant sur les machines réelles
la commande suivante :

# sysctl -w net.ipv4.ip_forward=1

Vérifiez les liaisons entre le client, le PC et le routeur : (O= ping OK, N = ping NOK)
Routeur Routeur PC-XX VBox XX PC-YY VBox YY
172.S.XX.1 172.S.YY.1 172.S.XX.2 10.S.XX.100 172.S.YY.2 10.S.YY.100
PC-XX
172.S.XX.2 O O O O N
VBox XX
10.S.XX.100 N N O N N
PC–YY
172.S.YY.2 O O O N O
VBox YY
10.S.YY.100 N N N N O

Question 5

Les deux réseaux 10.S.XX.0 et 10.S.YY.0 ne communiquent pas. Quelles solutions

pourriez-vous mettre en œuvre pour les faire communiquer ?

4.5 Mise en place du tunnel GRE

Le tunnel doit être monté entre les cartes eth0 des deux stations réelles.
Première partie : Sur PC-XX
1. Chargez le module ip gre

# modprobe ip_gre

2. Utilisez la commande ip tunnel pour monter un tunnel en mode GRE entre les
cartes eth0 des deux stations réelles. Pour obtenir de l’aide sur cette commande,
saisissez :

# ip tunnel help

Vous nommerez vers-YY l’extrémité du tunnel. Cette extrémité sera ensuite vue
par ifconfig comme une interface.

TD-Tunnels Version 1.0b

4.5 Mise en place du tunnel GRE 21

# ip tunnel add vers-YY mode gre local 172.S.XX.2

remote 172.S.YY.2

Le tunnel ainsi monté est visible par la commande ip tunnel :

# ip tunnel
gre0: gre/ip remote any local any ttl inherit nopmtudisc
vers-YY: gre/ip remote 172.S.YY.2 local 172.S.XX.2 ttl
inherit

Pour voir apparaitre l’interface vers-YY, il faut l’activer.

3. Activez l’interface vers-YY

# ip link set vers-YY up

Elle apparait maintenant lorsque l’on tape ifconfig :

# ifconfig vers-YY
vers-11 Link encap:UNSPEC HWaddr AC-10-0A-02-00-00-F1-85-00-00-
00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

4. À l’aide de la commande ip route, balisez le chemin vers le réseau qui se trouve de

l’autre côté du tunnel (pour atteindre le réseau 10.S.YY.0/24, passez par l’interface
vers-YY). Contrairement à la commande route, la commande ip route permet
de désigner une interface et non seulement une adresse IP.

# ip route add 10.S.YY.0/24 dev vers-YY

Ce qui donne, dans la table de routage de PC-XX affichée avec la commande route :

# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
172.S.XX.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.S.YY.0 0.0.0.0 255.255.255.0 U 0 0 0 vers-YY
0.0.0.0 172.S.XX.1 0.0.0.0 UG 0 0 0 eth0

Ou bien, avec la commande ip route :

# ip route
172.S.XX.0/24 dev eth0 proto kernel scope link src 172.S.XX.2
10.S.YY.0/24 dev vers-YY scope link

TD-Tunnels Version 1.0b

 4.6 Vérification 22

default via 172.S.XX.1 dev eth0

Seconde partie : Sur PC-YY

1. Faites les mêmes opérations en inversant XX et YY :
Chargez le module ip gre

# modprobe ip_gre

2. Utilisez la commande ip tunnel pour monter un tunnel en mode GRE entre les
cartes eth0 des deux stations réelles.
Vous nommerez vers-XX l’extrémité du tunnel. Cette extrémité sera vue par
ifconfig comme une interface.

# ip tunnel add vers-XX mode gre local 172.S.YY.2 remote 172.S.XX.2

3. Activez l’interface vers-XX

# ip link set vers-XX up

4. À l’aide de la commande ip route, balisez le chemin vers le réseau qui se trouve

de l’autre côté du tunnel.

# ip route add 10.S.XX.0/24 dev vers-XX

4.6 Vérification
Les pings doivent maintenant passer entre les deux PC d’extrémité (Vbox-XX et
Vbox-YY).

Question 6

Testez le retour d’un ping depuis 10.S.XX.100 vers 10.S.YY.100. Réalisez un trace-
path de 10.S.YY.100 depuis 10.S.XX.100. Que constatez-vous ?

Question 7

Qu’est-ce que le MTU ? Quelle est sa valeur par défaut ?

Question 8

Pourquoi le MTU observé est-il de 1476 octets ? Quelles sont les implications ?

TD-Tunnels Version 1.0b

4.6 Vérification 23

Question 9

Faites une capture à l’aide de Wireshark et mettez en évidence l’encapsulation de

IP dans IP.

TD-Tunnels Version 1.0b

 5.1 Montage d’un lecteur réseau au travers d’une connexion SSH
Montez un répertoire distant à travers ssh
— Sur le client créez un répertoire local d’accueil

mkdir /home/distant

— Puis, montez ce lecteur réseau

sshfs adminXXadresse_IP_VM2:/home/serge /home/distant

— Créez un répertoire ou un fichier puis vérifiez son existence sur la VM 2. listez le

contenu de l’arborescence tout en affichant le traffic entre VM 1 et VM 2 dans
Wireshark pour vérifier que ces informations sont chiffrées, protégées dans le tunnel
ssh.
Démontez ensuite le répertoire :

fusermount -u /home/serge/distant

5.2 Pivot SSH

5.2.1 Objectif
Faire transiter un ou plusieurs flux applicatifs (exemple : un flux Web) entre un client
A et un serveur B à travers un tunnel SSH dans une architecture contrainte.

5.2.2 Pré requis

Vous devez disposer de 5 machines : un serveur SSH VM SRV, deux postes clients
SSH VM 1 et VM 2 (un serveur WEB hébergé par VM 2), ainsi que, deux pare-feux
PF 1 et PF 2.
 5.2 Pivot SSH 25

Figure 5.1: Schéma de principe réalisé par SGT PEREIRA

5.2.3 Principe
Un serveur ssh VM SRV attend les requêtes du client VM 1 et du client VM 2. Les
pare-feux autorisent uniquement les flux à destination du serveur SSH port 22.
Le client VM 1 monte un tunnel avec VM SRV en spécifiant qu’il désire encapsuler le flux
entre un port local VM 1 :Port local et le port d’un serveur distant VM SRV :Port dest.
Le client VM 2 monte un tunnel avec VM SRV en spécifiant qu’il désire encapsuler le flux
entre un port local VM 2 :Port local et le port d’un serveur distant VM SRV :Port dest.
VM 1 est maintenant en mesure de consulter les pages WEB du serveur WEB hébergé
par VM 2

Question 10

Donnez les commandes saisies pour cette mise en œuvre.

TD-Tunnels Version 1.0b