Tunnels - ENSTA ParisTech

T.P. Réseaux privés virtuels
Tunnels
O. Perret
4 avril 2016
Table des matières
1 Manipulation de tunnels avec ssh
1.1 Présentation de SSH . . . . . . . . . . . . . . . . . . . . . .
1.2 Utilisation courante . . . . . . . . . . . . . . . . . . . . . . .
1.3 Utilisation systématique . . . . . . . . . . . . . . . . . . . .
1.4 Utilisation de SSH pour un tunnel . . . . . . . . . . . . . . .
1.5 Relayage de protocoles . . . . . . . . . . . . . . . . . . . . .
1.6 Redirection de ports . . . . . . . . . . . . . . . . . . . . . .
1.7 Précision à l’intention des utilisateurs de Microsoft Windows
1.7.1 Problème spécial : le serveur X sous Windows . . . .
1.8 Exercice facultatif . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Transition : Rappels sur la cryptographie à clef publique . .
2 Utilisation d’un VPN en tant que client
2.1 Installation du package OpenVPN . . . . . . . . . . . . .
2.2 Génération d’une infrastructure de clefs pour OpenVPN .
2.3 Récupération du fichier de configuration client . . . . . .
2.4 Branchement sur le VPN . . . . . . . . . . . . . . . . . .
2.5 Supervision . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Rappel Linux . . . . . . . . . . . . . . . . . . . .
2.5.2 Rappel MS-Windows . . . . . . . . . . . . . . . .
3 Fin du TP : ipv6,...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
3
4
4
4
4
5
5
5
.
.
.
.
.
.
.
5
5
6
6
6
6
6
6
7
1
Ionis - STM
O. Perret
Retour sur la présentation précédente
Visite commentée des liens cliquables de la présentation précédente.
Schémas
Différentes illustration des mécanismes des VPN. pages de référence...
Certificats
Démonstration pratique des affirmations énoncées sur l’écosystème des certificats.
Démo de connexion
Exemple de connexion et observation des conséquences. Objectifs du TP.
1
Manipulation de tunnels avec ssh
Le but de la première partie de ce T.P. est de rendre accessible un serveur web situé sur
la partie privée du réseau demo.perrets.info sur lequel les droits d’accès ont été restreint
aux utilisateurs locaux. Vous avez un compte sur le serveur mais le filtrage vous interdit
d’accéder aux pages directement. A vous de mettre en place le relayage.
1.1
Présentation de SSH
SSH chiffre à la volée l’intégralité d’une communication de machine à machine. Utilisant
au maximum les possibilités d’encapsulation de TCP/IP, il permet de faire circuler à peu
près n’importe quoi qui ne génére pas de connections réseau intempestives. La mauvaise
réputation des réseaux Peer-to-Peer et le fait qu’SSL lui a été préféré dans les navigateurs
web font qu’il est méconnu 1 .
Il comprend un serveur sshd et un certain nombre de clients ssh, scp, slogin, sftp, .... Il
est fourni en standard sur MacOS et existe en version packagée pour MS-Windows.
Lors d’une analyse de sécurité liée aux VPN, il est tout à fait courant d’aboutir à
la conclusion qu’un tunnel SSH est une réponse au besoin suffisante (pas forcément besoin de routage pour faire du transfert de port) voire meilleure (gestion des clefs simplifiée).
1. les navigateurs Web proposent leur propre couche de chiffrement, le plus souvent SSL(Secure Socket
Layer)
2
Ionis - STM
1.2
O. Perret
Utilisation courante
Le protocole ssh est basé sur un partage de secret entre les machines à partir duquel
ces deux machines authentifient mutuellement leurs utilisateurs à l’aide de défis chiffrés
avec ce secret. Une fois l’authentification assurée, une clef de session est générée et le
trafic correspondant est chiffré avec. Le ralentissement de la connexion dû au chiffrement
est toujours raisonnable, sauf en cas d’abus d’icones prévisibles, lesquelles sont d’ailleurs
déconseillées comme tout trafic prédictible.
1. Vérification de l’identité de l’utilisateur déja garantie par Unix ;
2. Confirmation de la confiance de la machine distante et création d’une clef de session
en accord avec la machine distante ;
3. Vérification distante de l’identité de l’utilisateur grâce à un dialogue chiffré par la
clef de session précédente.
Le dialogue changera sensiblement dans les 2 cas suivants :
– Si vous établissez plusieurs sessions chiffrées vers la même machine. Le contrôle sera
simplifié dès la deuxième connexion, puisque SSH vous a gardé une trace de la clef
publique de la machine de destination ;
– Si vous visez une machine qui a changé de numéro récement, ou qui vient d’être
réinstallée.
1.3
Utilisation systématique
Le modèle de sécurité de SSH est principalement bati sur le fait qu’il est difficile à un
intrus d’usurper durablement l’identité de certaines machines dans des conditions normales
d’exploitation. Un secret établi dans cette période de confiance n’en aura que plus de valeur.
La finesse ultime est donc de générer un secret qui sera réutilisable ultérieurement sans
avoir à retaper de mot de passe.
– Identifiez la machine vers laquelle vous souhaitez établir une connexion systématique ;
– Observez la version de ssh : ssh -V ;
– Générez un couple de clefs RSA adapté : ssh-keygen(ajoutez l’option -1 ou -2 selon
le cas) ;
– Copiez la clef publique ainsi générée sur la machine distante, dans un fichier appelé
authorized_keys (ou authorized_keys2).
Le serveur distant envoie alors au client un défi chiffré avec la clef publique de l’utilisateur, que le client résoud avec sa clef privée. Si les deux machines sont en confiance, la
connexion est automatique.
Attention : sur un réseau local fédéré, ce test peut être biaisé par le fait que toutes les
machines partagent les mêmes fichiers, et donc les mêmes autorisations.
3
Ionis - STM
1.4
O. Perret
Utilisation de SSH pour un tunnel
Il peuvent être cependant désactivé par le serveur sshd sur l’hôte distant, voire par le
client 2 .
Les fichiers à consulter en cas de problèmes sont (path à vérifier sur votre distribution) :
– /etc/ssh/sshd_config (sur le serveur) ;
– /etc/ssh/ssh_config (sur le client client) ;
– et la “man page” de ssh où le message d’erreur est sûrement documenté.
1.5
Relayage de protocoles
Le relayage de protocole est inhérent au design. Exemple d’utilisation d’un programme
à distance : les clients X.
ssh -X [email protected]
<dialogue d’ouverture de session>
> xterm &, xeyes &, xload &
1.6
Redirection de ports
Dans un terminal, tapez la commande 3 :
ssh -L 8000:localhost:81 [email protected] sleep 60
et dans une autre fenêtre :
telnet localhost 8000
ou dans un navigateur web, joignez l’URL : http://localhost:8000/
1.7
Précision à l’intention des utilisateurs de Microsoft Windows
Le relayage de ports fonctionne très bien sous Windows et nécessite juste l’installation
d’un client léger. Il en existe de très bons gratuits, souvent fournis avec un autre produit
orienté réseau, parfois moins gratuit. Les deux qui suivent suffisent pour un usage courant :
– Putty (associé à Winscp, outil de transfert de fichiers) :http://www.putty.org/
– Tunnelier (associé à WinSSHD, serveur ssh) :http://www.bitvise.com/tunnelier
2. c’est le cas par défaut dans Ubuntu
3. Telle que la commande est lancée, vous avez 60 secondes pour agir. Augmentez le score et/ou remontez
le tunnel s’il le faut.
4
Ionis - STM
1.7.1
O. Perret
Problème spécial : le serveur X sous Windows
Sur un système Windows, il n’y a pas de serveur X à livraison, même dans les kits
optionnels ; il faut se l’installer soi-même (contrairement à MacOS qui l’inclut dans son
disque supplémentaire à l’intention des développeurs, à coté du compilateur gcc). Cela
limite les applications de ce genre de relayage, la plus intéressante étant le déport d’affichage, proposée par l’outil “Nomachine NX” ( http://www.nomachine.com/)
Quelques noms de produits pour Windows intégrant un serveur X, par ordre de coût
(et de fonctionnalités) décroissant :
– Exceed, de la société Hummingbird/Opentext : http://connectivity.opentext.com ;
– X-win32, de la société Starnet : http://www.starnet.com/products/xwin32/
– Cygwin, l’environnement de développement GNU pour Windows.http://www.cygwin.
com/)
Ils incluent tous un client SSH.
1.8
Exercice facultatif
En utilisant cette technique contournez le firewall qui interdit d’utiliser le serveur de
mail pour envoyer un message à perret@localhost
1.9
Transition : Rappels sur la cryptographie à clef publique
SSH est l’occasion de rappeler les possibilités d’utilisation de la crypto à clef publique
pour sécuriser du trafic en ligne. Ce sont les mêmes principes qui seront utilisés de façon
systématique par OpenVPN (cf. transparents de fin du cours précédent).
2
Utilisation d’un VPN en tant que client
La démonstration de la configuration côté serveur suivra la page de référence du site
d’OpenVPN (http://openvpn.net/howto.html), avec des digressions sur la PKI et la configuration client, afin de vous permettre de recommencer au prochain TP en tant que “prestataire”.
Avant de se monter une infra serveur, nous allons commencer par des configurations
clients, avec la même cible que précédement. Les plus ambitieux pourront monter un tunnel
ipv6 en utilisant un service gratuit comme celui de Hurricane Electric http://ipv6.he.net/).
2.1
Installation du package OpenVPN
OpenVPN est distribué sous forme de sources pour Windows(zip) ou Unix(tgz), ou sous
forme de package pour Windows(.exe) ou les distributions Linux courantes (.deb, .rpm). Il
existe aussi pour les instances virtuelles.
5
Ionis - STM
O. Perret
La compilation ne pose pas de problèmes particuliers, si ce n’est les dépendances (lzo,...)
2.2
Génération d’une infrastructure de clefs pour OpenVPN
OpenVPN est fourni avec sa propre PKI, qui permet de générer les certificats nécessaires
et suffisants pour monter l’infra-structure :
– certificat racine
– certificat serveur
– 1 certificat par client
Ce sera l’occasion aussi de générer les fichiers de configuration de chaque client, et de
vous les transmettre.
2.3
Récupération du fichier de configuration client
Pour votre première connexion, vous allez utiliser le fichier de configuration client généré pour l’occasion.
Pour la transmission des fichiers de configuration et des clefs, il est recommandé d’utiliser un canal sécurisé, nous utiliserons le tunnel monté précédement.
2.4
Branchement sur le VPN
En vue d’une utilisation en simple client, le package openvpn est conçu pour aller lire
automatiquement sa configuration dans un fichier fourni par l’administrateur du VPN.
2.5
Supervision
Nous allons donc nous concentrer sur l’observation du réseau et les commandes de
supervision. L’interface à surveiller est bien évidement tun0:
2.5.1
Rappel Linux
Sous Linux, les commandes de supervision sont parfois supposées n’être utilisées que
par le super-utilisateur, donc installées dans /sbin ou /usr/sbin. Veillez à ce que ces 2
répertoires soient dans votre variable PATH.
– ifconfig -a, pour lister les interfaces réseau ;
– route -n ou netstat -rn, pour lire les tables de routage et les connexions ouvertes ;
– ping et traceroute, pour utiliser ICMP.
– arp pour descendre au niveau des tables arp (couche 2)
2.5.2
Rappel MS-Windows
Les commandes équivalentes sous Windows, à lancer dans une fenêtre MS-DOS) sont :
6
Ionis - STM
–
–
–
–
3
O. Perret
ipconfig /all
route
ping et tracert
arp
Fin du TP : ipv6,...
Selon le succès ou l’échec de la manoeuvre, la fin du T.P. sera consacrée au débuggage
ou aux réflexions sur l’architecture à adopter en vue de monter votre propre VPN, à méditer
d’ici au prochain T.P.
7