barak.pearlmutter@alumni.cs.cmu.edu
dumas@freenix.fr
,
dumas@Linux.EU.Org
, 1er Juillet 1997). Ce document
décrit comme utiliser Term pour traverser un Firewall
Internet, ce que vous n'êtes pas supposé pouvoir
faire.
Je décline sur le présent document toute responsabilité d'une quelconque application de ce qui va suivre. Si cela échoue de n'importe quelle manière, c'est votre problème. Ce n'est pas ma faute. Si vous ne comprenez pas les risques qui découlent de cette méthode, ne l'utilisez pas. Si vous employez cette méthode et que cela permet à des pirates vicieux de pénétrer dans votre système informatique et que cela vous coûte votre travail et à votre entreprise des millions de dollars, ce n'est que de votre faute. Ne venez pas pleurer.
Sauf contre-indication, les documents HOWTO Linux sont copyrightés par leurs auteurs respectifs. Les documents Linux HOWTO peuvent être reproduits et diffusés totalement ou en partie, sous n'importe quel support physique ou électronique du moment ou la notice légale se trouve sur toute copie. Les diffusions commerciales sont autorisées et encouragées. Toutefois, l'auteur souhaiterait être tenu au courant de telles diffusions.
Toute traduction, travail dérivé contenant n'importe quel document HOWTO Linux doit être convert par cette note légale. Ainsi, vous ne pouvez pas créer un document dérivé d'un HOWTO et ajouter des restrictions sur sa diffusion. Des exceptions à ces règles peuvent être éventuellement acceptées dans certaines conditions. Contactez le coordinateur des HOWTO à l'adresse qui suit.
En résumant, nous souhaitons favoriser la dissémination de ces informations via le maximum de moyens de communications. Toutefois, nous souhaitons garder un copyright sur ces documents et souhaiterions être tenu au courant de toute initiative de diffusion de ces documents.
Si vous avez des questions, contactez Greg Hankins, le coordinateur des HOWTO Linux à gregh@sunsite.unc.edu par courrier électronique ou par téléphone au 1 404 853 9989.
Le programme term
est normalement utilisé
sur une ligne série ou modem, pour permettre à
plusieurs services machine-à-machine de communiquer
grâce à cette simple connexion série.
Toutefois, il est assez utile quelquefois d'établir une
connexion entre deux machines communiquant par telnet
avec term
.
L'utilisation la plus intéressante réside dans la
connexion de deux machines séparées par des
firewalls ou par des serveurs socks. Les
firewalls permettent l'établissement de connexions
à travers eux-mêmes, typiquement en utilisant le
protocole socks. Ce dernier permet aux machines du
réseau interne de se connecter à l'extérieur,
et oblige les utilisateurs extérieurs à se connecter
en premier sur la machine passerelle qui leur demande un mot de
passe. Ces firewalls rendent impossible, par exemple, la
communication entre un client X sur une machine intérieure
et un serveur extérieur. Mais, en configurant une connexion
term
, ces restrictions peuvent être
contournées assez facilement, au niveau de
l'utilisateur.
Configurer une connexion term
par-dessus une
session telnet
se fait en deux phases.
Dans un premier temps, votre client habituel telnet
est utilisé pour configurer une connexion
telnet
et pour se connecter. Ensuite, le client
telnet
est mis en sommeil, et fait en sorte que la
connexion telnet
soit transmise à
term
.
En détail, la marche à suivre est la suivante :
telnet
à
l'extérieur de celui-ci et s'y loger.sh
.
C.à.d. que votre shell par défaut soit une variante
de csh
. Appelez telnet
par (setenv
SHELL /bin/sh; telnet machine.la-bas.dehors)
.term -r -n off
telnet
.Maintenant revenez à l'invite telnet
sur la
machine locale, en utilisant le caractère
d'échappement ^]
(ou celui que vous voulez),
puis utilisez la commande de telnet
pour
exécuter une commande shell !
pour lancer
term
:
telnet> ! term -n on telnet <&3 >&3
Et voilà !!! (Ndt : En français dans le texte).
(Si vous possédez une autre version de
telnet
, vous risquez d'avoir à utiliser
d'autres descripteurs de fichiers que 3. C'est facile à
déterminer en utilisant trace. Mais 3 semble fonctionner sur
tous les telnet
de type bsd que j'ai testés.
J'ai également essayé sous Sun OS 4.x et les
distributions Linux standard.)
Certains clients telnet ne possèdent pas de caractère d'échapement !. Par exemple, client telnet diffusé avec la Slackware 3.0 en fait partie. Les sources de ce client sont sensés provenir de ftp://ftp.cdrom.com:/pub/linux/slackware-3.0/source/n/tcpip/NetKit-B-0.05.tar.gz, paquetage qui contient le caractère d'échapement. Une solution assez simple est de récupérer ces sources et de les recompiler. Je n'y suis malheureusement pas arriver. De plus, si vous êtes à l'intérieur d'un firewall socks, vous devrez avoir un client telnet à la SOCKS. J'ai réussi à compiler un tel cient en utilisant ftp://ftp.nec.com/pub/security/socks.cstc/socks.cstc.4.2.tar.gz ou si vous êtes à l'extérieur des USA, ftp://ftp.nec.com/pub/security/socks.cstc/export.socks.cstc.4.2.tar.gz
Autrement, sous Linux version 1.2.13 ou
précédentes, vous pouvez mettre telnet
en sommeil avec ^]^z
, récupérer son pid
et lancer :
term -n on -v /proc/ < telnetpid > /fd/3 telnet
Cela ne fonctionne plus avec les noyaux 1.3 et supérieur, qui ont vérouillé certaines failles de sécurité pour éviter les accès à des descripteurs de fichiers n'appartenant pas au propriétaire du processus ou à ses fils.
term
multiplesC'est une bonne idée de donner un nom explicite à
la socket de term
. C'est l'argument donné
à telnet
dans la ligne de commande ci-dessus. A
moins que vous n'ayez la variable d'environnement TERMSERVER
positionnée à telnet
, vous pouvez
appeler les clients avec le paramètre -t
,
c'est-à-dire : trsh -t telnet
.
J'ai attendu que la ligne soit claire en utilisant un
vérficateur de ligne sur ce média. J'espérais
qu'il soit totalement transparent, mais cela semble impossible.
Toutefois, le seul caractère perturbant semble être le
255. Le fichier /.term/termrc.telnet
que j'emploie (le
fichier .telnet
est le nom de la connexion
term
, cf. supra) contient :
baudrate off escape 255 ignore 255 timeout 600
Il peut être amélioré en trichant, j'ai un débit de seulement 30.000 cps (caractères par secondes) pour une connexion longue distance à-travers un firewall lent. FTP peut aller jusqu'à 100.000 cps en suivant le même chemin. Une vitesse en bps (bits par seconde) réaliste peut éviter quelques temps morts.
Manifestement, si vous attaquez de l'extérieur du
firewall, et que vous employez une carte avec un
identificateur sécurisé ou quelque chose de ce genre,
vous voudrez sûrement inverser les rôles des serveurs
de connexion et local (si vous ne comprennez pas ce que cela
signifie, vous n'êtes peut-être pas assez familier avec
term
pour utiliser l'astuce décrite dans ce
document d'une manière responsable).
Ce n'est rien moins qu'une faille que la possibilité
d'avoir une connexion telnet
détournée
sur une machine non sécurisée de l'extérieur.
Le premier risque supplémentaire provient des personnes
capables d'utiliser la socket term
que vous avez
configurée sans que vous soyez au courant. Donc, soyez
prudents (personnellement, je fais cela sur une machine externe que
je sais être sécurisée. Pour être plus
précis, un portable sous Linux que j'administre
moi-même et qui n'accepte aucune connexion de
l'extérieur).
Une autre possibilité est d'ajouter socket
off
dans ~/.term/termrc.telnet
ou ajouter
-u off
. Cela évide que la socket soit
accessible du site distant, avec une perte de fonctionnalité
assez mineure.
telnet
Vérifiez que le démon telnetd
distant
n'est pas dans un mauvais mode sept bits. Si c'est le cas, vous
devez l'indiquer à term
lorsque vous le lancez
en ajoutant un -a
sur la ligne de commande (j'emploie
de temps en temps un ^] telnet> set outbin
ou un
set bin
ou bien, je lance telnet
avec
l'option -8 pour forcer la connexion en mode 8 bits).
Le programme de vérification de ligne a de temps en temps
quelques problèmes pour contrôler la connexion
telnet
. Cela provient parfois du fait qu'il ne
vérifie pas le code de retour de l'appel
read()
. Pour des connexions réseau, cet appel
peut retourner le code d'erreur -1 avec EINTR (interrompu)
ou EAGAIN (reéssayer). Manifestement, cela serait une
bonne chose que cela soit vérifié.
Un certain nombre de caractéristiques pourraient
faciliter l'utilisation de term
sur
telnet
. Cela provient essentiellement d'une
hypothèse qui a influencé le développement de
term
, qui est que la connexion dispose d'une largeur
de bande faible, d'une latence réduite et qu'elle est
quelque peu bruitée.
Une connexion telnet
possède en
général une bande passante assez importante, une
grande latence et qui contient peu d'erreurs. Cela signifie que la
connexion pourrait être mieux utilisée si :
term
Egalement, pour améliorer la sécurité, il
serait sympathique d'avoir une option dans term
pour
afficher la liste des connexions réalisées par la
socket dans un fichier ou sur stderr, ou bien dans les deux. Cela
permettrait de vérifier si une connexion term
a
été corrompue par des pirates situés du
côté non sécurisé de la machine.
Quelques clients et serveurs telnet
acceptent
d'encoder leurs communications pour tromper la surveillance sur
réseau. Malheureusement, la méthode employée
ci-dessus (en utilisant la connexion réseau que le client
telnet
a configuré pendant que l'autre client
est en attente) ne fonctionne pas dans ce cas. Au lieu de cela, il
doit réellement traverser le client telnet
,
donc ne peut réaliser l'encodage. Il semble qu'il faille
modifier que le client, pour y a jouter une commande qui lance un
processus avec leurs stdin et stdout connectés au
telnet
en cours. Cela serait également utile
pour des processus de connexion automatiques, peut-être
quelqu'un l'a-t-il déjà fait.
J'ai légèrement consulté la bibliothèque Term. Les détails ainsi que les patches à SOCKS sont disponibles en les demandant à Steven Danz (danz@wv.mentorg.com).
Mes remerciements à
Je décline sur le présent document toute responsabilité d'une quelconque application de ce qui a été exposé. Si cela échoue de n'importe quelle manière, c'est votre problème. Ce n'est pas ma faute. Si vous ne comprenez pas les risques qui découlent de cette méthode, ne l'utilisez pas. Si l'emploi de cette méthode permet à des pirates vicieux de pénétrer dans votre système informatique et que cela vous côte votre travail et à votre entreprise des millions de dollars, ce n'est que de votre faute. Ne venez pas pleurer.