/usr/share/doc/HOWTO/fr-html/Term-Firewall.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Mini-HOWTO Term-Firewall</title>
</head>
<body>
<h1>Mini-HOWTO Term-Firewall</h1>
<h2>Barak Pearlmutter,
<code>barak.pearlmutter@alumni.cs.cmu.edu</code></h2>
22 Mai 1996
<hr>
<em>(Version française réalisée par Eric Dumas,
<code>dumas@freenix.fr</code>, <code>dumas@Linux.EU.Org</code>, 1er
Juillet 1997). Ce document décrit comme utiliser Term pour
traverser un Firewall Internet, ce que vous n'êtes pas supposé
pouvoir faire.</em>
<hr>
<h2><a name="s1">1. Avertissements (Important !)</a></h2>
<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.</p>
<h2><a name="s2">2. Copyright</a></h2>
<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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2><a name="s3">3. Introduction</a></h2>
<p>Le programme <code>term</code> 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 <code>telnet</code>
avec <code>term</code>.</p>
<p>L'utilisation la plus intéressante réside dans la connexion de
deux machines séparées par des <i>firewalls</i> ou par des serveurs
<i>socks</i>. Les <i>firewalls</i> permettent l'établissement de
connexions à travers eux-mêmes, typiquement en utilisant le
protocole <i>socks</i>. 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 <i>firewalls</i> 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 <code>term</code>, ces restrictions peuvent être
contournées assez facilement, au niveau de l'utilisateur.</p>
<h2><a name="s4">4. Mise en oeuvre générale</a></h2>
<p>Configurer une connexion <code>term</code> par-dessus une
session <code>telnet</code> se fait en deux phases.</p>
<p>Dans un premier temps, votre client habituel <code>telnet</code>
est utilisé pour configurer une connexion <code>telnet</code> et
pour se connecter. Ensuite, le client <code>telnet</code> est mis
en sommeil, et fait en sorte que la connexion <code>telnet</code>
soit transmise à <code>term</code>.</p>
<h2><a name="s5">5. Procédure détaillée</a></h2>
<p>En détail, la marche à suivre est la suivante :</p>
<ol>
<li>A partir d'une machine à l'intérieur du <i>firewall</i>, se
connecter par <code>telnet</code> à l'extérieur de celui-ci et s'y
loger.</li>
<li>Sauf si vous êtes sous <b>Linux</b> et que vous utilisez le
système de fichiers <i>/proc</i> (voir ci-dessous), vérifiez que
votre shell est du genre <code>sh</code>. C.à.d. que votre shell
par défaut soit une variante de <code>csh</code>. Appelez
<code>telnet</code> par <code>(setenv SHELL /bin/sh; telnet
machine.la-bas.dehors)</code>.</li>
<li>Après s'être logé, lancer la commande sur la machine de
l'extérieur : <code>term -r -n off telnet</code>.</li>
</ol>
<p>Maintenant revenez à l'invite <code>telnet</code> sur la machine
locale, en utilisant le caractère d'échappement <code>^]</code> (ou
celui que vous voulez), puis utilisez la commande de
<code>telnet</code> pour exécuter une commande shell <code>!</code>
pour lancer <code>term</code> :</p>
<pre>
telnet&gt; ! term -n on telnet &lt;&amp;3 &gt;&amp;3
</pre>
<p><i>Et voilà !!!</i> (Ndt : En français dans le texte).</p>
<p>(Si vous possédez une autre version de <code>telnet</code>, 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 <code>telnet</code> de type bsd que j'ai
testés. J'ai également essayé sous Sun OS 4.x et les distributions
<b>Linux</b> standard.)</p>
<p>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</p>
<p>Autrement, sous <b>Linux</b> version 1.2.13 ou précédentes, vous
pouvez mettre <code>telnet</code> en sommeil avec <code>^]^z</code>
, récupérer son pid et lancer :</p>
<pre>
   term -n on -v /proc/ &lt; telnetpid &gt; /fd/3 telnet
</pre>
<p>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.</p>
<h2><a name="s6">6. Sockets pour <code>term</code>
multiples</a></h2>
<p>C'est une bonne idée de donner un nom explicite à la socket de
<code>term</code>. C'est l'argument donné à <code>telnet</code>
dans la ligne de commande ci-dessus. A moins que vous n'ayez la
variable d'environnement TERMSERVER positionnée à
<code>telnet</code>, vous pouvez appeler les clients avec le
paramètre <code>-t</code>, c'est-à-dire : <code>trsh -t
telnet</code>.</p>
<h2><a name="s7">7. Le fichier d'initialisation
.term/termrc.telnet</a></h2>
<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
<code>/.term/termrc.telnet</code> que j'emploie (le fichier
<code>.telnet</code> est le nom de la connexion <code>term</code>,
cf. supra) contient :</p>
<pre>
baudrate off
escape 255
ignore 255
timeout 600
</pre>
<p>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 <i>firewall</i> 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.</p>
<h2><a name="s8">8. Administration</a></h2>
<p>Manifestement, si vous attaquez de l'extérieur du
<i>firewall</i>, 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 <code>term</code> pour utiliser l'astuce
décrite dans ce document d'une manière responsable).</p>
<h2><a name="s9">9. Securité</a></h2>
<p>Ce n'est rien moins qu'une faille que la possibilité d'avoir une
connexion <code>telnet</code> 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 <code>term</code> 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
<b>Linux</b> que j'administre moi-même et qui n'accepte aucune
connexion de l'extérieur).</p>
<p>Une autre possibilité est d'ajouter <code>socket off</code> dans
<code>~/.term/termrc.telnet</code> ou ajouter <code>-u off</code>.
Cela évide que la socket soit accessible du site distant, avec une
perte de fonctionnalité assez mineure.</p>
<h2><a name="s10">10. Mode <code>telnet</code></a></h2>
<p>Vérifiez que le démon <code>telnetd</code> distant n'est pas
dans un mauvais mode sept bits. Si c'est le cas, vous devez
l'indiquer à <code>term</code> lorsque vous le lancez en ajoutant
un <code>-a</code> sur la ligne de commande (j'emploie de temps en
temps un <code>^] telnet&gt; set outbin</code> ou un <code>set
bin</code> ou bien, je lance <code>telnet</code> avec l'option
<i>-8</i> pour forcer la connexion en mode 8 bits).</p>
<h2><a name="s11">11. Bugs et mes souhaits concerant term</a></h2>
<p>Le programme de vérification de ligne a de temps en temps
quelques problèmes pour contrôler la connexion <code>telnet</code>.
Cela provient parfois du fait qu'il ne vérifie pas le code de
retour de l'appel <code>read()</code>. Pour des connexions réseau,
cet appel peut retourner le code d'erreur -1 avec <i>EINTR</i>
(interrompu) ou <i>EAGAIN</i> (reéssayer). Manifestement, cela
serait une bonne chose que cela soit vérifié.</p>
<p>Un certain nombre de caractéristiques pourraient faciliter
l'utilisation de <code>term</code> sur <code>telnet</code>. Cela
provient essentiellement d'une hypothèse qui a influencé le
développement de <code>term</code>, 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.</p>
<p>Une connexion <code>telnet</code> 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 :</p>
<ol>
<li>la taille maximale de la fenêtre était augmentée, bien au-delà
de la limite imposée par la formule <i>N_PACKETS/2 = 16</i> de
<code>term</code></li>
<li>une option pour désactiver l'envoi et la vérification du
<i>checksum</i> des paquets était implémentée</li>
<li>de plus grands paquets étaient permis lorsque cela est
approprié.</li>
</ol>
<p>Egalement, pour améliorer la sécurité, il serait sympathique
d'avoir une option dans <code>term</code> 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 <code>term</code> a été corrompue par des pirates situés
du côté non sécurisé de la machine.</p>
<h2><a name="s12">12. Trucs qui semblent ne pas
fonctionner</a></h2>
<p>Quelques clients et serveurs <code>telnet</code> 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 <code>telnet</code> 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 <code>telnet</code>, 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 <code>telnet</code> en cours. Cela serait également
utile pour des processus de connexion automatiques, peut-être
quelqu'un l'a-t-il déjà fait.</p>
<h2><a name="s13">13. Sources</a></h2>
<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).</p>
<h2><a name="s14">14. Remerciement</a></h2>
<p>Mes remerciements à</p>
<ul>
<li>Gary Flake (flake@scr.siemens.com)</li>
<li>Bill Riemers (bcr@physics.purdue.edu)</li>
<li>Greg Louis (glouis@dynamicro.on.ca)</li>
</ul>
<h2><a name="s15">15. Copie supplémentaire des avertissements
-Lisez-le !</a></h2>
<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.</p>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / Term-Firewall.html
