<!doctype linuxdoc system>

<article>

<title>Mini-HOWTO Term-Firewall

<author>Barak Pearlmutter, <tt>barak.pearlmutter@alumni.cs.cmu.edu</tt>
<date>22 Mai 1996

<abstract>
(Version française réalisée par Eric Dumas, <tt>dumas@freenix.fr</tt>,
<tt>dumas@Linux.EU.Org</tt>, 1er Juillet 1997).
Ce document décrit comme utiliser Term pour traverser un 
Firewall Internet, ce que vous n'êtes pas supposé pouvoir faire.
</abstract>

<toc>

<sect> Avertissements (Important !) <p>


<p>
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.

<sect> Copyright <p>

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 <em>via</em> 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.

<sect> Introduction <p>

Le programme <tt>term</tt> 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 <tt>telnet</tt> avec <tt>term</tt>.

L'utilisation la plus intéressante réside dans la connexion de deux
machines séparées par des <it>firewalls</it> ou par des serveurs
<it>socks</it>.
Les <it>firewalls</it> permettent l'établissement de connexions à travers
eux-mêmes, typiquement en utilisant le protocole <it>socks</it>. 
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 <it>firewalls</it> 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 <tt>term</tt>, ces restrictions peuvent
être contournées assez facilement, au niveau de l'utilisateur.

<sect> Mise en oeuvre générale <p>

Configurer une connexion <tt>term</tt> par-dessus une session 
<tt>telnet</tt> se fait en deux phases.

Dans un premier temps, votre client habituel <tt>telnet</tt> est
utilisé pour configurer une connexion <tt>telnet</tt> et pour se 
connecter.
Ensuite, le client <tt>telnet</tt> est mis en sommeil, et fait en sorte que
la connexion <tt>telnet</tt> soit transmise à <tt>term</tt>.


<sect> Procédure détaillée <p>

En détail, la marche à suivre est la suivante :

<enum>
        <item> A partir d'une machine à l'intérieur du <it>firewall</it>,
se connecter par <tt>telnet</tt> à l'extérieur de celui-ci et s'y loger.

        <item> Sauf si vous êtes sous <bf>Linux</bf> et que vous
utilisez le système de fichiers <it>/proc</it> (voir ci-dessous),
vérifiez que votre shell est du genre <tt>sh</tt>. C.à.d. que
votre shell par défaut soit une variante de <tt>csh</tt>. Appelez
<tt>telnet</tt> par
<tt>(setenv SHELL /bin/sh; telnet machine.la-bas.dehors)</tt>.

        <item>Après s'être logé, lancer la commande sur la machine
de l'extérieur :
<tt>term -r -n off telnet</tt>.
</enum>

Maintenant revenez à l'invite <tt>telnet</tt> sur la machine locale,
en utilisant le caractère d'échappement <tt> ^] </tt> (ou celui que vous
voulez), puis utilisez la commande de <tt>telnet</tt> pour exécuter une
commande shell <tt> ! </tt> pour lancer <tt>term</tt> :

<verb>
telnet> ! term -n on telnet <&3 >&3
</verb>

<it>Et voilà !!!</it> (Ndt : En français dans le texte).

(Si vous possédez une autre version de <tt>telnet</tt>, 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
<tt>telnet</tt> de type bsd que j'ai testés. J'ai également
essayé sous Sun OS 4.x et les distributions <bf>Linux</bf> 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 <bf>Linux</bf> version 1.2.13 ou précédentes,
vous pouvez mettre <tt>telnet</tt> en
sommeil avec <tt> ^]^z </tt>, récupérer son pid et lancer :

<verb>
   term -n on -v /proc/ < telnetpid > /fd/3 telnet
</verb>

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.

<sect> Sockets pour <tt>term</tt> multiples <p>

C'est une bonne idée de donner un nom explicite à la socket de 
<tt>term</tt>.
C'est l'argument donné à <tt>telnet</tt> dans la ligne de commande
ci-dessus. A moins que vous n'ayez la variable d'environnement
TERMSERVER positionnée à <tt>telnet</tt>,
vous pouvez appeler les clients avec le paramètre <tt>-t</tt>, 
c'est-à-dire :
<tt>trsh -t telnet</tt>.


<sect> Le fichier d'initialisation .term/termrc.telnet <p>

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 <tt> /.term/termrc.telnet</tt>
que j'emploie (le fichier <tt>.telnet</tt> est le nom de la connexion
<tt>term</tt>, cf. supra) contient :

<verb>
baudrate off
escape 255
ignore 255
timeout 600
</verb>

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 <it>firewall</it> 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.

<sect> Administration <p>

Manifestement, si vous attaquez de l'extérieur du <it>firewall</it>,
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
<tt>term</tt> pour utiliser l'astuce décrite dans ce document d'une 
manière responsable).


<sect> Securité <p>

Ce n'est rien moins qu'une faille que la possibilité d'avoir
une connexion <tt>telnet</tt> 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 <tt>term</tt> 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 <bf>Linux</bf> que
j'administre moi-même et qui n'accepte aucune connexion de l'extérieur).

Une autre possibilité est d'ajouter <tt>socket off</tt> 
dans <tt>~/.term/termrc.telnet</tt> ou ajouter
<tt>-u off</tt>. Cela évide que la socket soit accessible
du site distant, avec une perte de fonctionnalité assez mineure.


<sect> Mode <tt>telnet</tt> <p>

Vérifiez que le démon <tt>telnetd</tt> distant n'est pas dans un
mauvais mode sept bits. Si c'est le cas, vous devez l'indiquer à 
<tt>term</tt>
lorsque vous le lancez en ajoutant un <tt>-a</tt> sur la ligne de commande
(j'emploie de temps en temps un <tt>^] telnet> set outbin</tt>
ou un <tt>set bin</tt> ou bien, je lance <tt>telnet</tt> avec
l'option <it>-8</it> pour forcer la connexion en mode 8 bits).


<sect> Bugs et mes souhaits concerant term <p>

Le programme de vérification de ligne a de temps en temps quelques problèmes
pour contrôler la connexion <tt>telnet</tt>. Cela provient parfois
du fait qu'il ne vérifie pas le code de retour de l'appel <tt>read()</tt>.
Pour des connexions réseau, cet appel peut retourner le code d'erreur
-1 avec <it>EINTR</it> (interrompu) ou <it>EAGAIN</it> (reéssayer).
Manifestement, cela serait une bonne chose que cela soit vérifié.

Un certain nombre de caractéristiques pourraient faciliter
l'utilisation de <tt>term</tt> sur <tt>telnet</tt>. Cela provient
essentiellement d'une hypothèse qui a influencé le développement de
<tt>term</tt>, 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 <tt>telnet</tt> 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 :
<enum>
        <item> la taille maximale de la fenêtre était augmentée, bien
au-delà de la limite imposée par la formule <it>N_PACKETS/2 = 16</it>
de <tt>term</tt>
        <item> une option pour désactiver l'envoi et la vérification
du <it>checksum</it> des paquets était implémentée
        <item> de plus grands paquets étaient permis lorsque cela
est approprié.
</enum>

Egalement, pour améliorer la sécurité, il serait sympathique d'avoir 
une
option dans <tt>term</tt> 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 <tt>term</tt> a
été corrompue par des pirates situés du côté non sécurisé de 
la machine.

<sect>Trucs qui semblent ne pas fonctionner<p>

Quelques clients et serveurs <tt>telnet</tt> 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 <tt>telnet</tt> 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 <tt>telnet</tt>,
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 <tt>telnet</tt> en cours.
Cela serait également utile pour des processus de connexion
automatiques, peut-être quelqu'un l'a-t-il déjà fait.

<sect>Sources<p>

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).

<sect>Remerciement<p>

Mes remerciements à 
<itemize>
<item>Gary Flake (flake@scr.siemens.com)
<item>Bill Riemers (bcr@physics.purdue.edu)
<item>Greg Louis (glouis@dynamicro.on.ca)
</itemize>



<sect> Copie supplémentaire des avertissements -Lisez-le !<p>

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.

</article>
