HOWTO Réseaux Privés Virtuels

Arpad Magosanyi <mag@bunuel.tii.matav.hu> v0.2,7 Aug1997 Traduction par Nicolas Prigent <prigentn@cicrp.jussieu.fr>

v0.2, 7 August 1997

1. Modifications

Le problème de 'pas de contrôle du tty' -> -o 'BatchMode yes' par Zot O'Connor <zot@crl.com>

Avertissements au sujet du kernel 2.0.30 par mag

2. Burps

Vous avez sous les yeux le howto Réseaux Privés Virtuels, un rassemblement d'informations concernant la manière de monter un Réseau Privé Virtuel sous Linux (et les autres Unix en général).

2.1 Copyright

Sauf indication contraire, les droits d'auteur des HOWTO Linux sont détenus par leurs auteurs respectifs. Les HOWTO Linux peuvent être reproduits et distribués, en totalité ou en partie, sur tout média physique ou électronique dans la mesure où ce copyright est préservé dans chaque copie. La distribution commerciale en est autorisée et encouragée. L'auteur apprécierait toutefois qu'on lui notifie individuellement ce genre de distribution. Le présent copyright doit couvrir toute traduction, compilation et autre travail dérivé des HOWTO Linux. C'est-à-dire qu'il est interdit d'imposer des restrictions de diffusion allant au delà du présent copyright à des ouvrages inspirés, ou incorporant des passages, de HOWTO Linux. Sous certaines conditions, des exceptions à ces règles seront tolérées : contactez le coordinateur des HOWTO à l'adresse donnée ci-dessous. Pour résumer, nous souhaitons une diffusion aussi large que possible de ces informations. Néanmoins, nous entendons garder la propriété intellectuelle (copyright) des HOWTO, et apprécierions d'être informés de leur redistribution. Pour toute question plus générale, merci de contacter le coordinateur des HOWTO, Tim Bynum, à l'adresse électronique tjbynum@wallybox.cei.net.

2.2 Mise en garde

Comme d'habitude : L'auteur n'est en aucun cas responsable de tout dommage occasionné. Pour la formulation exacte, se référer à la partie correspondante de la GNU GPL 0.1.1

2.3 Mise en garde

Il est question de sécurité : vous n'êtes pas en sécurité si vous n'instaurez pas une politique de sécurité efficace, et autres choses ennuyeuses de ce genre.

2.4 Remerciements

Merci à tous ceux qui ont écrit les outils utilisés.

Merci à Zot O'Connor <zot@crl.com> pour m'avoir montré le problème de "no controlling tty", et sa solution.

Le traducteur voudrait remercier Aude Hurtrel pour son aide précieuse.

2.5 Etat de ce document.

Voici les préliminaires. Vous devez avoir une connaissance générale de l'administration IP, au moins quelques connaissances sur les firewalls, ppp et ssh. Vous êtes de toute facon censé les connaitre si vous voulez monter un VPN. J'ai simplement décidé d'écrire mes expériences afin de ne pas les oublier. En fait, Il se peut qu'il y ait des trous de sécurité. Pour être honnête, j'ai réalisé mes essais sur des machines configurées comme des routeurs, et pas des firewalls, c'est plus simple.

2.6 Documentation relative au sujet

3. Introduction

Les firewalls étant de plus en plus largement utilisés dans les systèmes de sécurité internet et intranet, la capacité de réaliser de bons VPNs est de plus en plus importante. Voici le relevé de mes expériences. Les commentaires sont les bienvenus.

3.1 Conventions de dénomination

J'utiliserais les termes de "firewall-maître" et "firewall-esclave", bien que réaliser un VPN n'ait rien à voir avec l'architecture client-serveur. Je me réfère simplement à eux en tant que participant actif et passif de la mise en place de la connection. On utilisera la dénomination de "maître" pour l'hôte qui initie la connection, et celle d'esclave pour le participant passif.

4. Le faire

4.1 Préparation

Avant de commencer à mettre en place votre système, vous devriez connaître les détails concernant le réseau. Je considère que vous avez deux firewalls, chacun protégeant un intranet, et qu'il sont tous deux connectés à l'internet. De fait, vous devriez avoir deux interfaces (au moins) par firewall. Prenez une feuille de papier et écrivez leurs adresses IP et masques de réseau. Vous aurez besoin d'une adresse IP suplémentaire par firewall pour le VPN que vous voulez mettre en place. Ces adresses devraient être extérieures à vos sous-réseaux existants. Je vous suggère d'utiliser des adresses de l'espace d'adressage "privé". Les voici :

Pour les besoins de l'exemple, voici une configuration : les deux bastions s'appellent fellini et polanski. Ils ont une interface vers l'internet (-out), une pour l'intranet (-in), et une pour le VPN (-vpn).

Voici pour les préparatifs.

4.2 Rassembler les outils

Vous aurez besoin :

Version actuelles (NDT :au moment de la rédaction de cet HOWTO)

4.3 Compiler et installer

Compilez ou installez les outils que vous venez de rassembler. Consultez attentivement leur documentation (et le firewall-howto) pour de plus amples informations. Mantenant, nous disposons des outils.

4.4 Configurer les autres sous-systèmes

Configurez correctement les paramètres des firewalls. Vous devez autoriser les communications ssh entre les deux hôtes disposant de firewalls. Cela signifie qu'il doit exister une connexion sur le port 22 du maître vers l'esclave. Lancez sshd sur l'esclave et vérifiez que vous pouvez vous connecter. Je n'ai pas vérifié cette étape, n'hésitez pas à me communiquer les résultats que vous avez obtenus.

4.5 Configurer les comptes pour le VPN

Créez un compte sur le firewall esclave en utilisant vos outils favoris (par exemple vi, mkdir, chown, chmod). Vous pouvez aussi créer un compte sur le maître, mais je pense que vous souhaitez que la connexion se fasse au démarrage, nous nous servirons donc de votre compte root habituel. Est-ce que quelqu'un pourrait me signaler les risques qu'il y a à utiliser le compte root sur le maître?

4.6 Générer une clé ssh pour le compte du maître

Utilisez le programme de génération de clé de ssh. Donnez un mot de passe vide pour la clé privée si vous voulez réaliser une configuration automatique du VPN.

4.7 Configurer une connexion ssh automatique pour le compte esclave

Copiez la clé publique fraîchement générée dans le compte esclave dans le fichier .ssh/authorized_keys, et configurez les droits d'accès comme indiqué ci dessous :

 
drwx------ 2 esclave esclave 1024 Apr 7 23:49 ./   
drwx------ 4 esclave esclave 1024 Apr 24 14:05 ../   
-rwx------ 1 esclave esclave 328 Apr 7 03:04 authorized_keys   
-rw------- 1 esclave esclave 660 Apr 14 15:23 known_hosts   
-rw------- 1 esclave esclave 512 Apr 21 10:03 random_seed   

la première ligne étant ~esclave/.ssh, la seconde ~esclave.

4.8 Resserrer la sécurité ssh sur les bastions.

Ce qui se traduit par la configuration suivante dans sshd_conf :

 
PermitRootLogin no   
IgnoreRhosts yes   
StrictModes yes   
QuietMode no   
FascistLogging yes   
KeepAlive yes   
RhostsAuthentication no   
RhostsRSAAuthentication no   
RSAAuthentication yes   
PasswordAuthentication no   
PermitEmptyPasswords no  

L'authentification par mot de passe étant désactivée, la connexion n'est possible qu'avec les clés autorisées. (Vous aurez bien entendu désactivé telnet et la commande 'r').

4.9 Permettre l'exécution de ppp et route sur les deux comptes.

Comme le compte maître est aussi le compte root en ce qui me concerne, Il n'y a rien eu à faire. Pour le compte esclave, les lignes suivantes apparaissent dans /etc/sudoers :

Cmnd_Alias VPN=/usr/sbin/pppd,/usr/local/vpn/route   
esclave ALL=NOPASSWD: VPN   

Comme vous pouvez le voir, j'utilise des scripts pour mettre en place ppp et les tables de routage sur l'hôte esclave.

4.10 Faire les scripts

Sur l'hôte maître, j'utilise un full-blown script :

 
#! /bin/sh 
# skeleton      example file to build /etc/init.d/ scripts. 
#               This file should be used to construct scripts for /etc/init.d. 
# 
#               Written by Miquel van Smoorenburg <miquels@cistron.nl>. 
#               Modified for Debian GNU/Linux 
#               by Ian Murdock <imurdock@gnu.ai.mit.edu>. 
# 
# Version:      @(#)skeleton  1.6  11-Nov-1996  miquels@cistron.nl 
# 
 
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11/: 
PPPAPP=/home/esclave/ppp 
ROUTEAPP=/home/esclave/route 
PPPD=/usr/sbin/pppd 
NAME=VPN 
REDIR=/usr/local/bin/pty-redir 
SSH=/usr/bin/ssh 
MYPPPIP=192.168.0.1 
TARGETIP=192.168.0.2 
TARGETNET=193.6.37.0 
MYNET=193.6.35.0 
ESCLAVEWALL=polanski-out 
ESCLAVEACC=esclave 
 
test -f $PPPD || exit 0 
 
set -e 
 
case "$1" in 
  start) 
        echo setting up vpn 
        $REDIR $SSH -o 'Batchmode yes' -t -l $ESCLAVEACC $ESCLAVEWALL sudo $PPPAPP >/tmp/device 
        TTYNAME=`cat /tmp/device` 
echo tty is $TTYNAME 
        sleep 10s 
        if [ ! -z $TTYNAME ] 
        then 
        $PPPD $TTYNAME ${MYPPPIP}:${TARGETIP} 
        else 
                echo FAILED! 
                logger "vpn setup failed" 
        fi 
        sleep 5s 
        route add -net $TARGETNET gw $TARGETIP 
        $SSH -o 'Batchmode yes' -l $ESCLAVEACC $ESCLAVEWALL sudo $ROUTEAPP
    ;; 
  stop) 
        ps -ax | grep "ssh -t -l $ESCLAVEACC " | grep -v grep | awk '{print $1}' | xargs kill 
    ;; 
  *) 
    # echo "Usage: /etc/init.d/$NAME {start|stop|reload}" 
    echo "Usage: /etc/init.d/$NAME {start|stop}" 
    exit 1 
    ;; 
esac 
 
exit 0 
  

L'esclave utilise un script pour la préparation du routage (/usr/local/vpn/route) :

 
#!/bin/bash   
/sbin/route add -net 193.6.35.0 gw 192.168.0.1   

et son .ppprc est tel qu'indiqué ci-dessous :

 
passive   

5. Regardons ce qui se passe :

Le maître se connecte à l'esclave, commence pppd, et redirige tout vers un terminal pty local. Ce qui consiste en l'enchaînement suivant :

Le temps entre en considération (ne serait-ce qu'un peu), c'est pour cela que l'on a ajouté 'sleep 10'.

6. Le faire à la main.

6.1 Se connecter

Vous avez déjà essayé de voir si ssh marche bien, n'est-ce pas ? Si l'esclave refuse de vous laisser vous connecter, lisez les fichiers logs. Peut-être y a-t-il des problèmes d'autorisation sur certains fichiers, ou avec la configuration de sshd.

6.2 Faire chauffer ppp

Connectez-vous à l'esclave, et tapez :

sudo /usr/sbin/pppd passive   
  

Vous devriez voir les ennuis arriver à partir de ce moment. Si ca marche, c'est bien ; sinon, c'est qu'il y a des problèmes soit avec sudo, soit avec pppd. Regardez ce que les commandes ont dit, ainsi que les fichiers /etc/ppp/options et .ppprc . Si tout fonctionne, ajoutez 'passive' dans .ppprc, et essayez de nouveau. Pour vous débarrasser des problèmes et continuer à travailler, appuyez sur Enter, '~' et '^Z'. Vous devriez alors avoir l'invite du maître, et faire kill %1. Regardez la partie concernant les réglages si vous voulez en savoir plus sur les caractères d'échappement.

6.3 Réunir les deux.

Bon, alors

ssh -l esclave polanski sudo /usr/sbin/pppd  
  

devrait aussi marcher, et vous renvoyer son blabla en pleine tête.

6.4 Redirection du terminal

Essayez de tout rediriger cette fois-ci :

/usr/local/bin/pty-redir /usr/bin/ssh -l esclave polanski sudo /usr/sbin/pppd   
  

Longue phrase, hein ? Vous êtes supposé utiliser le chemin d'accès complet dans l'exécutable ssh, du fait que le programme de redirection du pty n'autorise que cette forme pour des raisons de sécurité. Maintenant, vous disposez d'un nom de fichier spécial pour le programme. Disons que c'est /dev/ttyp0 . Vous pouvez utiliser la commande ps pour regarder ce qui s'est passé. Regardons 'p0'.

6.5 Y a-t-il quelque chose sur le dispositif ?

Essayez

/usr/sbin/pppd /dev/ttyp0 local 192.168.0.1:192.168.0.2   
  

pour établir la connexion. Regardez la sortie de la commande ifconfig pour voir si le dispositif s'est installé, et utilisez ping pour vérifier votre réseau virtuel.

6.6 Mettre en place le routage.

Configurez les routes sur l'hôte maître, ainsi que sur l'esclave. Vous devriez maintenant être capable de lancer un ping sur un hôte d'un intranet depuis un hôte sur l'autre intranet. Mettez en place des règles additionnelles de firewall. Maintenant que vous avez le VPN, vous pouvez mettre en place les règles concernant l'interconnexion des deux intranets.

7. Réglages

7.1 Réglages de la configuration

Comme je l'ai déjà dit, cet HOWTO est avant tout un mémo rapide sur la manière dont j'ai monté un VPN. Il y a des choses dans la configuration que je n'ai pas encore essayées. Ces choses rejoindront leur place quand je les aurais essayées, ou que quelqu'un m'aura dit : "C'est comme ça que ça marche". La chose la plus importante est que la connexion qu'utilise ppp n'est pas en 8 bits. Je crois que l'on peut faire quelque chose à ce sujet avec la configuration de ssh ou celle de pty. Dans cette configuration, ssh utilise le caractère tilde (~) comme un caractère d'échappement. Cela pourait stopper ou ralentir la communication si une séquence retour-à-la-ligne/tilde conduisait ssh à retourner une invite. Selon la documentation de ssh : <sur la plupart des systèmes, donner au caractère d'échappement la valeur "none" rendra de la session transparente, même si un tty est utilisé.> Le drapeau correspondant à cela pour ssh est '-e', et vous pouvez aussi le placer dans le fichier de configuration.

7.2 Bande pasante contre cycles d'horloge

Créer quelque chose, aussi virtuel soit-il, entraîne l'utilisation de ressources du monde réel. Un VPN utilise de la bande passante et des ressources de calcul. Le but étant de trouver un équilibre entre les deux. Vous pouvez faire des réglages avec le drapeau '-C' ou l'option 'CompressionLevel'. Vous pourriez essayer de trouver un autre algorithme de chiffrement, mais je ne vous le recommande pas. Notez aussi que le temps de transmission peut être allongé si vous utilisez un meilleur taux de compression. Toutes vos expériences sont les bienvenues.

8. Analyse de vulnérabilité

J'essaie de couvrir ici les trous de sécurité naissant de cette mise en oeuvre en particulier, et des VPNs en général. Tous les commentaires seront vivement appreciés.