barak.pearlmutter@alumni.cs.cmu.edudumas@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 multiples C'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 :
termEgalement, 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.