Le problème de 'pas de contrôle du tty' -> -o 'BatchMode yes' par Zot O'Connor <[email protected]>
Avertissements au sujet du kernel 2.0.30 par mag
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).
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 [email protected].
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
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.
Merci à tous ceux qui ont écrit les outils utilisés.
Merci à Zot O'Connor <[email protected]> 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.
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.
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.
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.
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.
Vous aurez besoin :
Version actuelles (NDT :au moment de la rédaction de cet HOWTO)
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.
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.
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?
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.
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.
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').
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.
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 <[email protected]>.
# Modified for Debian GNU/Linux
# by Ian Murdock <[email protected]>.
#
# Version: @(#)skeleton 1.6 11-Nov-1996 [email protected]
#
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
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'.
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.
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.
Bon, alors
ssh -l esclave polanski sudo /usr/sbin/pppd
devrait aussi marcher, et vous renvoyer son blabla en pleine tête.
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'.
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.
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.
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.
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.
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.