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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Petit guide du perçage de pare-feux</title><link rel="stylesheet" type="text/css" href="style.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"/><meta name="description" content="Comment utiliser ppp par-dessus ssh, telnet ou autre, de façon à réaliser une connexion réseau transparente à travers un pare-feu. Valable aussi bien pour l'élaboration d'un VPN convivial que pour la perforation des pare-feu gênants."/></head><body><div xml:lang="fr" class="article"><div class="titlepage"><div><div><h2 class="title"><a id="d0e2"/>Petit guide du perçage de pare-feux</h2></div><div><h3 class="subtitle"><em>

Version française du petit guide <span xml:lang="en" class="foreignphrase"><em xml:lang="en" class="foreignphrase">Firewall 
Piercing mini-HOWTO</em></span>

</em></h3></div><div><div class="author"><h3 class="author"><span class="firstname">François-René</span> <span class="surname">Rideau</span></h3><code class="email">&lt;<a class="email" href="mailto:fare PLUS fwprc CHEZ tunes POINT org">fare PLUS fwprc CHEZ tunes POINT org</a>&gt;</code></div></div><div><p class="othercredit"><span class="contrib">Adaptation française</span> : <span class="firstname">Arnaud</span> <span class="surname">Muller</span></p></div><div><p class="othercredit"><span class="contrib">Relecture de la version française</span> : <span class="firstname">Yvon</span> <span class="surname">Benoist</span></p></div><div><p class="othercredit"><span class="contrib">Préparation de la publication de la v.f.</span> : <span class="firstname">Jean-Philippe</span> <span class="surname">Guérard</span></p></div><div><p class="releaseinfo">Version : 0.97</p></div><div><p class="pubdate">18 septembre 2006</p></div><div><div class="revhistory"><table summary="Historique des versions"><tr><th align="left" valign="top" colspan="3"><strong>Historique des versions</strong></th></tr><tr><td align="left">Version 0.97.fr.1.0</td><td align="left">2006-09-18</td><td align="left">AM, YB, JPG</td></tr><tr><td align="left" colspan="3">
                Première version française.
         </td></tr><tr><td align="left">Version 0.97</td><td align="left">2001-11-24</td><td align="left">FRR</td></tr><tr><td align="left" colspan="3">

		Conversion au format SGML DocBook.
                <span xml:lang="en" class="emphasis"><em>Conversion to DocBook 
                SGML.</em></span>

         </td></tr></table></div></div><div><div class="abstract"><p class="title"><strong>Résumé</strong></p><p>

Comment utiliser <span class="command"><strong>ppp</strong></span> par-dessus 
<span class="command"><strong>ssh</strong></span>, <span class="command"><strong>telnet</strong></span> ou autre, de façon à 
réaliser une connexion réseau transparente à travers un pare-feu. 
Valable aussi bien pour l'élaboration d'un VPN convivial que pour la 
perforation des pare-feu gênants.

</p></div></div></div><hr/></div><div class="toc"><p><strong>Table des matières</strong></p><dl class="toc"><dt><span class="sect1"><a href="#d0e94">1. Divers</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e97">1.1. Avis de non-responsabilité</a></span></dt><dt><span class="sect2"><a href="#d0e110">1.2. Baratin juridique</a></span></dt><dt><span class="sect2"><a href="#d0e125">1.3. Recherche responsable de la maintenance</a></span></dt><dt><span class="sect2"><a href="#d0e130">1.4. Remerciements</a></span></dt><dt><span class="sect2"><a href="#d0e154">1.5. Dernières versions</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e172">2. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e175">2.1. Avant propos</a></span></dt><dt><span class="sect2"><a href="#d0e196">2.2. Les problèmes de sécurité.</a></span></dt><dt><span class="sect2"><a href="#d0e220">2.3. Autres conditions requises</a></span></dt><dt><span class="sect2"><a href="#d0e270">2.4. Logiciels à télécharger</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e355">3. Compréhension du problème</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e360">3.1. Donner un nom aux choses</a></span></dt><dt><span class="sect2"><a href="#d0e371">3.2. Le problème principal</a></span></dt><dt><span class="sect2"><a href="#d0e378">3.3. Le problème annexe</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e479">4. La solution sécurisée : percer en utilisant ssh</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e482">4.1. Principe</a></span></dt><dt><span class="sect2"><a href="#d0e515">4.2. Exemple de session</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e621">5. La solution non sécurisée : percer en utilisant telnet</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e624">5.1. Principe</a></span></dt><dt><span class="sect2"><a href="#d0e659">5.2. fwprc</a></span></dt><dt><span class="sect2"><a href="#d0e706">5.3. .fwprcrc</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e753">6. Routage</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e758">6.1. Il y a un truc</a></span></dt><dt><span class="sect2"><a href="#d0e814">6.2. Exemple de routage</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e904">7. Perçage inverse</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e907">7.1. La logique</a></span></dt><dt><span class="sect2"><a href="#d0e940">7.2. Obtenir le message de déclenchement</a></span></dt><dt><span class="sect2"><a href="#d0e957">7.3. Autres outils automatiques pour le perçage inverse</a></span></dt></dl></dd><dt><span class="sect1"><a href="#d0e970">8. Remarques finales</a></span></dt><dd><dl><dt><span class="sect2"><a href="#d0e973">8.1. Autres réglages</a></span></dt><dt><span class="sect2"><a href="#d0e1058">8.2. Le suivi de ce petit guide</a></span></dt><dt><span class="sect2"><a href="#d0e1067">8.3. Documents sur le sujet</a></span></dt><dt><span class="sect2"><a href="#d0e1098">8.4. Le mot de la fin</a></span></dt><dt><span class="sect2"><a href="#d0e1126">8.5.  Copie supplémentaire de l’avis très important de non responsabilité — croyez le !!!</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e94"/>1. Divers</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e97"/>1.1. Avis de non-responsabilité</h3></div></div></div><p>
<span class="emphasis"><em>Lisez cette section, elle est importante !!!!</em></span>
</p><p>
<span class="emphasis"><em>

Par la présente je décline toute responsabilité quant à l’utilisation 
que vous ferez de cette méthode d'effraction [hack]. Si ça se retourne 
contre vous d’une manière ou d'une autre, c’est pas de pot. Et c’est pas 
ma faute. Si vous ne comprenez pas les risques encourus, laissez tomber. 
Si vous utilisez cette méthode de piratage et qu’il permet à des 
vandales sans scrupules de pénétrer dans les ordinateurs de votre 
société et que ça vous coûte votre boulot et des millions d’euros à 
votre entreprise, eh bien c’est pas de pot. Ne venez pas pleurer chez 
moi.

</em></span>
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e110"/>1.2. Baratin juridique</h3></div></div></div><p>
Copyright © 1998-2001 par François-René Rideau.
</p><p>
Ce document est publié en logiciel libre sous la
<a class="ulink" href="http://www.geocities.com/SoHo/Cafe/5947/bugroff.html" target="_top"> license bugroff</a>.
</p><p>

Pour faciliter leur travail, les droits ont également été cédés aux 
responsables de la maintenance du LDP [Linux Development Project] sous 
la <a class="ulink" href="http://www.gnu.org/copyleft/fdl.html" target="_top">Licence de 
Documentation Libre GNU</a>.

</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e125"/>1.3. Recherche responsable de la maintenance</h3></div></div></div><p>

Je ne m'occupe plus activement de l’évolution de ce petit guide, bien 
que je continue d’en assurer la maintenance. Je recherche une personne 
qui pourrait prendre le relais pour la maintenance, qui l’étofferait 
pour en faire un petit guide à part entière en s’étendant davantage sur 
les solutions dont je ne fais que mentionner l’existence, et qui 
pourrait peut être développer des logiciels pour rendre la perforation 
de pare-feu plus facile. J’ai énormément d’idées pour étendre le contenu 
de ce petit guide et développer un logiciel adéquat, si quelqu’un est 
intéressé. J’avais également écrit une version française de ce guide 
pratique, mais personne n’en assure plus la maintenance depuis longtemps 
[NdT : ceci est une nouvelle traduction].

</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e130"/>1.4. Remerciements</h3></div></div></div><p>
Même si tout ce qu’il en reste est le paragraphe sur la non responsabilité, ce document doit énormément au
<a class="ulink" href="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html" target="_top">Term-Firewall mini-HOWTO</a>
de Barak Pearlmutter 

<code class="email">&lt;<a class="email" href="mailto:bap CHEZ cs POINT unm POINT edu">bap CHEZ cs POINT unm POINT edu</a>&gt;</code>.

Le petit guide de Barak repose sur <span class="productname">Term</span>™,
ancien programme qui n’est plus supporté (excellent programme en son 
temps, et qui peut être encore utile dans certaines circonstances 
malheureuses), ainsi que certaines particularités d’une implémentation 
non standard de telnet, autrement dit beaucoup d’éléments obsolètes et 
non portables. Néanmoins, un petit guide sur la perforation des pare-feu 
était 
nécessaire, et malgré les limites des méthodes d'effraction [hacks] 
qu'il propose, son petit guide a été un modèle et un encouragement.
</p><p>
J’aimerais également féliciter Lars Brinkhoff

<code class="email">&lt;<a class="email" href="mailto:lars CHEZ nocrew POINT org">lars CHEZ nocrew POINT org</a>&gt;</code>


et Magnus Lundström

<code class="email">&lt;<a class="email" href="mailto:logic CHEZ gore POINT nocrew POINT org">logic CHEZ gore POINT nocrew POINT org</a>&gt;</code>

pour leurs très bons tunnels http, messagerie et icmp.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e154"/>1.5. Dernières versions</h3></div></div></div><p>
La dernière version LDP officielle de ce document est sur :
<a class="ulink" href="http://www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html" target="_top">http://www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html</a>
</p><p>
La source de ma dernière version officielle de ce document est sur :
<a class="ulink" href="http://fare.tunes.org/files/fwprc/" target="_top">http://fare.tunes.org/files/fwprc/</a>
</p><p>
La source de mon dernier brouillon de travail pour ce document est sur :
<a class="ulink" href="http://tunes.org/cgi-bin/cvsweb/fare/fare/www/articles/Firewall-Piercing.en.sgml" target="_top">http://tunes.org/cgi-bin/cvsweb/fare/fare/www/articles/Firewall-Piercing.en.sgml</a>
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e172"/>2. Introduction</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e175"/>2.1. Avant propos</h3></div></div></div><p>
Ce document a une morale. Et cette morale est :
<span class="emphasis"><em>un pare-feu ne peut pas protéger un réseau contre ses propres utilisateurs internes et ne devrait même pas essayer.
</em></span>
</p><p>
Lorsqu’un utilisateur interne vous demande à vous, administrateur système, d’ouvrir un port sortant vers une machine externe, ou un port entrant vers une machine interne, vous devez le faire pour lui. Evidemment, vous devez aider l’utilisateur pour être sûr que ses transactions sont sécurisées, et que son logiciel est robuste. Mais refuser carrément de rendre ce service à l'utilisateur relève d’une incompétence évidente. A moins que le pare-feu ne le coupe complètement du reste du monde extérieur, au point de se retrouver sans <span class="command"><strong>ssh</strong></span>, <span class="command"><strong>telnet</strong></span>, navigateur web, courrier électronique, dns, ligne téléphonique, radio, et sans pouvoir faire de <span class="command"><strong>ping</strong></span>, rien de rien, il n’en demeure pas moins que l’utilisateur peut utiliser les techniques de perforation de pare-feu pour accéder aux machines qu’il veut , et il le fera, et, résultat final au niveau sécurité, on aura une connexion non vérifiée avec le monde extérieur. Alors soit vous faites confiance à vos utilisateurs, après une formation et une sélection appropriées, soit vous leur refusez tout accès au réseau; mais là encore le rôle d’un administrateur réseau est habituellement de servir ses utilisateurs, alors c’est plutôt le premier cas de figure qu’il faut viser, pas le deuxième. Vous pouvez et vous devez les protéger contre le monde extérieur, vous pouvez et vous devez protéger vos services sensibles contre vos utilisateurs, mais vous ne les protégerez point contre eux-mêmes, et vous ne le pouvez pas.
</p><p>

Parce que des administrateurs passifs, ou absents, ou surchargés, ou 
carrément incompétents, ou irresponsables, ou simplement dirigés par des 
personnes incompétentes, ça existe, il se trouve parfois qu’un 
utilisateur puisse se retrouver derrière un pare-feu qu’il peut 
traverser, mais ce ne sera pas très commode. Ce petit guide fournit un 
moyen générique et portable de percer des tunnels dans des pare-feu, en 
transformant les rares petits bits qui arrivent au compte-gouttes en une 
véritable autoroute de l’information, de sorte que l’utilisateur puisse 
utiliser d’une façon cohérente des outils standards pour accéder aux 
ordinateurs de l’autre côté du pare-feu. La même technique peut être 
utilisée par les administrateurs réseaux compétents pour faire des 
réseaux privés virtuels (VPN [Virtual Private Networks]).

</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e196"/>2.2. Les problèmes de sécurité.</h3></div></div></div><p>

Bien entendu si votre administrateur système a installé un pare-feu, il 
a sûrement une bonne raison et vous avez sûrement signé un engagement à 
ne pas le contourner. D’un autre côté, le fait que vous puissiez 
utiliser telnet, le web, la messagerie électronique, ou tout autre flux 
quel qu’il soit d’information bidirectionnel avec l’extérieur du 
pare-feu (ce qui est une condition sine qua non pour que les méthodes 
présentées puissent fonctionner) signifie que vous êtes autorisé à 
accéder à des systèmes externes, et le fait que vous puissiez ouvrir une 
session sur un système externe particulier signifie que vous êtes aussi 
autorisé à le faire.

</p><p>
Il s’agit donc ici tout simplement d’utiliser de façon
<span class="emphasis"><em>commode</em></span>
les failles légales d’un pare-feu, et d’autoriser les programmes génériques à fonctionner à partir de là avec les protocoles génériques, plutôt que d’avoir recours à des programmes spéciaux ou modifiés (et recompilés) passant par de nombreux proxies à usage particulier qui ont été mal configurés par un administrateur système négligent ou incompétent, ou d’installer de nombreux convertisseurs à usage particulier pour accéder à chacun de vos services habituels (comme la messagerie électronique) en passant par des chemins supportés par le pare-feu (comme le web).
</p><p>
De plus, l’utilisation d’un émulateur d’IP niveau utilisateur tel que
<span class="productname">SLiRP</span>™
devrait permettre de maintenir la protection contre les attaques extérieures par perforation du pare-feu, à moins que vous ne le permettiez explicitement (ou alors les agresseurs sont astucieux et malicieux, et root, ou, sinon, capables de vous espionner sur le serveur).
</p><p>
L’un dans l’autre, la méthode présentée devrait être relativement sécurisée. Cependant, ça dépend des conditions particulières dans lesquelles vous faites l’installation, et je ne peux donner aucune garantie sur cette méthode. De nombreuses choses sont intrinséquement non sécurisées au niveau des connections internet, que ce soit avec cette méthode ou pas, donc n’imaginez surtout pas que telle ou telle chose est sécurisée à moins que vous n’ayez de bonnes raisons, et/ou utilisez un procédé de chiffrage tout le temps.
</p><p>
Répétons les bases de la sécurité réseau :
<span class="emphasis"><em>vous ne pouvez faire confiance à rien du tout au niveau d’une connexion, pas plus que vous ne faites confiance aux hôtes qui peuvent manier les données non cryptées
</em></span>,
y compris les hôtes des deux côtés de la connection, et tous les hôtes qui peuvent intercepter la communication, à moins que la communication soit cryptée correctement avec des clefs secrètes. Si vous placez mal votre confiance, vos mots de passe peuvent être volés et utilisés contre vous, votre numéro de carte de crédit peut être volé et utilisé contre vous, et vous pouvez être viré de votre boulot pour avoir mis en danger toute l’entreprise. Tant pis pour vous.
</p><p>
Pour résumer, n’utilisez pas cette méthode sauf si vous savez ce que vous faites. Relisez l’avis de non-responsabilité plus haut.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e220"/>2.3. Autres conditions requises</h3></div></div></div><p>

On suppose que vous savez ce que vous faites, que vous savez comment 
configurer une connexion au réseau, qu’en cas de doute vous aurez lu 
toute la documentation qu’il faut (guides pratiques, manuels, pages web, 
archives de listes de diffusion, RFC, cours, tutoriels).

</p><p>
On suppose que vous avez des comptes console des deux côtés du pare-feu, que vous pouvez d’une façon ou d’une autre transmettre des paquets d’information dans les deux sens à travers le pare-feu (avec <span class="command"><strong>telnet</strong></span>, <span class="command"><strong>ssh</strong></span>, le courriel, et le web comme moyens les plus couramment utilisés pour travailler), et que vous pouvez laisser un démon en fonctionnement comme tâche en arrière-plan sur le serveur (ou bénéficier d’un démon existant,
<span class="command"><strong>sshd</strong></span>, <span class="command"><strong>telnetd</strong></span>, ou
<span class="command"><strong>sendmail</strong></span>/<span class="command"><strong>procmail</strong></span>).
</p><p>
On suppose que vous savez ou que vous êtes disposé à apprendre comment configurer un émulateur d’IP
 (<span class="command"><strong>pppd</strong></span>, <span class="command"><strong>slirp</strong></span>)
ou un accès à internet démon et la bibliothèque qui va avec 
 (<span class="productname">SOCKS</span>™, <span class="productname">Term</span>™)
des deux côtés, en fonction de vos besoins en terme de connectivité et de vos droits d’accès, en recompilant certains logiciels si besoin est.
</p><p>
Enfin, et c’est également important, pour que vous puissiez utiliser les méthodes décrites dans ce document, on suppose que vous êtes root du côté du pare-feu qui a besoin d’un accès IP transparent complet vers l’autre côté. En effet, il vous faudra lancer le démon PPP de ce côté, ce qui permet l’utilisation de l’installation normale de routage du paquet kernel. Au cas où vous n’êtes pas root de ce côté, votre cas n’est pas désespéré malgré tout : en effet le
<a class="ulink" href="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html" target="_top">Term-Firewall mini-HOWTO</a>
de Barak Pearlmutter décrit comment utiliser <span class="productname">Term</span>™,
programme entièrement fait pour l’utilisateur, en vue du perçage de pare-feu. Bien qu’il n’y ait aucun petit guide, je soupçonne
<span class="productname">SOCKS</span>™ de pouvoir également être utilisé comme un moyen de percer les pare-feu sans avoir le privilège root; j’accepterai volontiers vos contributions à ce Guide pratique sur cette méthode pour percer les pare-feu.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e270"/>2.4. Logiciels à télécharger</h3></div></div></div><p>
La plupart des logiciels mentionnés dans ce Guide pratique devrait être disponible dans votre distribution de Linux standard, éventuellement parmi les contributions. Au moins, les quatre premiers ci-dessous sont disponibles en tant que paquets <code class="filename">.rpm</code> et <code class="filename">.deb</code> Au cas vous voudriez récupérer les dernières versions (après tout, un des deux bouts de la connexion peut ne pas fonctionner sous Linux), utilisez les adresses ci-dessous :

</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
<span class="command"><strong>SLiRP</strong></span> se trouve sur

<a class="ulink" href="http://blitzen.canberra.edu.au/slirp" target="_top">http://blitzen.canberra.edu.au/slirp</a> ou sur
<a class="ulink" href="ftp://www.ibc.wustl.edu/pub/slirp_bin/" target="_top">ftp://www.ibc.wustl.edu/pub/slirp_bin/</a>.
</p></li><li class="listitem"><p>
<span class="command"><strong>zsh</strong></span> se trouve sur
<a class="ulink" href="http://www.zsh.org/" target="_top">http://www.zsh.org/</a>.
</p></li><li class="listitem"><p>
<span class="command"><strong>ppp</strong></span> se trouve sur
<a class="ulink" href="ftp://cs.anu.edu.au/pub/software/ppp/" target="_top">ftp://cs.anu.edu.au/pub/software/ppp/</a>.
</p></li><li class="listitem"><p>
<span class="command"><strong>ssh</strong></span> se trouve sur
<a class="ulink" href="http://www.openssh.com/" target="_top">http://www.openssh.com/</a>.
</p></li><li class="listitem"><p>
<span class="command"><strong>fwprc</strong></span>, <span class="command"><strong>cotty</strong></span>
et <span class="command"><strong>getroute.pl</strong></span> se trouvent sur
<a class="ulink" href="http://fare.tunes.org/files/fwprc/" target="_top">http://fare.tunes.org/files/fwprc/</a>.
</p></li><li class="listitem"><p>
<span class="command"><strong>httptunnel</strong></span> se trouve sur
<a class="ulink" href="http://www.nocrew.org/software/httptunnel/" target="_top">http://www.nocrew.org/software/httptunnel/</a>.
</p></li><li class="listitem"><p>
<span class="command"><strong>mailtunnel</strong></span> se trouve sur
<a class="ulink" href="http://www.detached.net/mailtunnel/" target="_top">http://www.detached.net/mailtunnel/</a>.
</p></li></ul></div><p>
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e355"/>3. Compréhension du problème</h2></div></div></div><p>
Quand vous comprenez un problème, vous avez fait la moitié du chemin vers la solution.
</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e360"/>3.1. Donner un nom aux choses</h3></div></div></div><p>
Si vous voulez que cette méthode fonctionne, vous devrez comprendre comment elle fonctionne pour que, si quelque chose ne marche pas, vous sachiez où chercher.
</p><p>
La première étape pour comprendre le problème est de donner un nom aux concepts appropriés.
</p><p>
Comme d’habitude, nous allons ci-après appeler « client » la machine qui décide d’initialiser la connexion, ainsi que les programmes et les fichiers sur cette machine. Réciproquement, nous appelerons « serveur » celui qui attend les connexions et les accepte, ainsi que les programmes et fichiers sur cette machine. Le perçage de pare-feu est utile lorsque les deux machines sont séparées par un pare-feu, de telle sorte qu’il est possible pour le serveur d’accepter certaines connexions, alors qu'il n'est pas certain que le client puisse en accepter. Un tunnel sera créé entre les deux machines, ce qui permet un trafic IP complet malgré le pare-feu.
</p><p>
Habituellement, lorsque l’on perce un pare-feu, le client est la machine derrière le pare-feu : il a un accès limité à internet, mais peut d’une façon ou d’une autre ouvrir une connexion ou une autre sur le serveur. Le serveur est une machine avec un accès complet à internet, qui va servir de proxy pour le client afin qu’il accède à internet. Dans un VPN, les rôles peuvent être inversés, avec le client étant sur internet et le serveur servant de proxy au client afin d’accéder à certains réseaux privés.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e371"/>3.2. Le problème principal</h3></div></div></div><p>
Le problème principal pour le perçage de pare-feu est de créer un tunnel : une connexion continue d’une machine cliente vers une machine serveur de l’autre côté du pare-feu, qui permet un échange bidirectionnel d’informations. Optionnellement, cette connexion devrait être sécurisée. Le problème annexe est de transformer cette connexion en un accès IP complet pour une utilisation transparente par les programmes normaux.
</p><p>
Pour le problème principal, nous considérerons que soit (1) vous pouvez établir des connexions TCP/IP normales du côté client du pare-feu vers un port sur une machine serveur où un sshd tourne ou peut être mis en fonctionnement, ou (2) vous pouvez d’une façon ou d’une autre établir une connexion telnet à travers un proxy telnet. Au cas où vous ne pourriez pas, nous allons vous diriger vers un autre logiciel qui permet de percer un tunnel à travers un pare-feu. Bien que nous ne donnions qu’une solution sécurisée dans le premier cas, vous pouvez bidouiller votre propre solution sécurisée dans les autres cas, si vous comprenez le principe (si vous ne le comprenez pas, quelqu’un, par exemple moi, peut le faire pour vous contre rémunération).
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e378"/>3.3. Le problème annexe</h3></div></div></div><p>
Pour le problème annexe, les émulateurs d’IP
 (<span class="command"><strong>pppd</strong></span> ou <span class="productname">SLiRP</span>™)
sont lancés de chaque côté du tunnel.
</p><p>
Du côté qui veut un accès IP complet vers l’autre côté, il vous faudra lancer
 <span class="command"><strong>pppd</strong></span>.
De l’autre côté, vous devez lancer <span class="command"><strong>pppd</strong></span>
si vous voulez un accès IP complet dans l’autre sens, ou <span class="productname">SLiRP</span>™ si vous voulez empêcher tout accès. Consultez votre documentation <span class="command"><strong>pppd</strong></span> ou <span class="productname">SLiRP</span>™
habituelle pour plus d’informations, si vous avez des besoins spécifiques qui ne sont pas traités dans les exemples ci-dessous.
 </p><p>
Bien qu’il s’agisse d’un concept banal, ça nécessite néanmoins quelques astuces toutes bêtes afin de fonctionner, car (a) si vous utilisez une quelconque session shell programmée interactive pour démarrer l’émulateur d’IP du serveur de n’importe quel côté, il vous faut synchroniser correctement le démarrage de l’émulateur d’IP de l’autre côté, afin de ne pas envoyer des saletés dans la session shell, et (b) les émulateurs d’IP sont conçus pour être lancés sur une interface « tty » : vous devez donc convertir votre interface tunnel en une tty.
 </p><p>
Le point (a) ne représente rien de plus que le problème de synchronisation habituel, et n’existe même pas si vous utilisez <span class="command"><strong>ssh</strong></span>,
qui s’occupe de manière transparente du lancement de commande du serveur.
 </p><p>
Le point (b) requiert l’utilisation d’un simple utilitaire extérieur. Nous en avons fait un, <span class="command"><strong>cotty</strong></span> juste dans ce but.
</p><p>
&lt; PIQUAGE DE CRISE&gt;
</p><p>
Entre autres problèmes débiles dûs à l’étroitesse d’esprit des concepteurs de <span class="command"><strong>pppd</strong></span> (ceci n’est plus le cas dans les versions récentes de Linux), on peut seulement le lancer soit par un dispositif dans <code class="filename">/dev</code> ou par le tty courant. On ne peut pas le lancer par une paire de tunnels (ce qui serait la conception évidente). C’est parfait pour le  <span class="command"><strong>pppd</strong></span> du serveur s’il y en a un, puisqu’il peut utiliser le <code class="filename">tty</code> des sessions
 <span class="command"><strong>telnet</strong></span> ou <span class="command"><strong>ssh</strong></span>; mais pour le
<span class="command"><strong>pppd</strong></span> du client, cela entraîne un conflit en cas d’utilisation de
 <span class="command"><strong>telnet</strong></span> pour établir une connexion.
</p><p>
En effet, <span class="command"><strong>telnet</strong></span> veut, également, être sur un tty, il se comporte <span class="emphasis"><em>presque</em></span> correctement avec deux tunnels, à part qu’il insistera encore pour faire des iotctl au tty courant, avec lequel il va interférer ; l’utilisation de <span class="command"><strong>telnet</strong></span> sans un tty impose également un régime tel que toute la connexion échouera sur des ordinateurs « lents » (<span class="command"><strong>fwprc</strong></span> 0.1 fonctionnait parfaitement sur un P/MMX 233, un délai d’attente de 6 sur un 6x86-P200+, et aucun sur un 486dx2/66). L’un dans l’autre, lors de l’utilisation de <span class="command"><strong>telnet</strong></span>, vous avez besoin de <span class="command"><strong>cotty</strong></span> comme démon pour copier la sortie d’un tty sur lequel fonctionne pppd sur un autre tty sur lequel fonctionne <span class="command"><strong>telnet</strong></span>, et inversement.
</p><p>
Si je trouve l’abruti (probablement un gars de <span class="productname">MULTICS</span>™ bien que il a dû y avoir des gens d’<span class="productname">UNIX</span>™ assez bêtes pour copier cette idée) qui a inventé le principe des dispositifs « tty » grâce auxquels on lit et on écrit à partir d’un « même » pseudo fichier, au lieu d’avoir des couples de tunnels propres, je l’étrangle !
</p><p>
&lt;/JE ME CALME&gt;
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e479"/>4. La solution sécurisée : percer en utilisant ssh</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e482"/>4.1. Principe</h3></div></div></div><p>
Considérons que votre administrateur de pare-feu autorise les connexions TCP transparentes vers un port quelconque sur un serveur de l’autre côté du pare-feu (que ce soit le port du ssh normal, le 22, un autre port de destination, tel que le port http, le 80, ou autre), ou que vous vous débrouillez d’une façon ou d’une autre pour qu’un port quelconque d’un côté du pare-feu soit redirigé vers un port de l’autre côté (en utilisant
<span class="command"><strong>httptunnel</strong></span>, <span class="command"><strong>mailtunnel</strong></span>, un tunnel sur le <span class="command"><strong>telnet</strong></span>, ou autre).
</p><p>
Vous pouvez alors lancer un <span class="command"><strong>sshd</strong></span> sur le port côté serveur, et vous y connecter avec un <span class="command"><strong>ssh</strong></span> sur le port côté client. Des deux côtés de la connexion <span class="command"><strong>ssh</strong></span> vous lancez des émulateurs d’IP ( <span class="command"><strong>pppd</strong></span>), et là vous avez votre VPN, réseau privé virtuel, qui évite les restrictions stupides du pare-feu, avec un bonus en plus : la confidentialité grâce au cryptage (faites attention, l’administrateur du pare-feu connaît tout de même l’autre bout du tunnel, et toute information d’authentification quelle qu’elle soit que vous pouvez avoir envoyée avant de lancer le <span class="command"><strong>ssh</strong></span>).
</p><p>
Exactement la même technologie peut être utilisée pour construire un VPN, réseau privé virtuel, qui permet de regrouper de façon sécurisée des sites physiques en un seul réseau logique sans sacrifier la sécurité au niveau du réseau de transport entre les sites.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e515"/>4.2. Exemple de session</h3></div></div></div><p>
Ci-dessous se trouve un exemple de script que vous pouvez adapter à vos besoins. Il utilise le système de rangée de <span class="command"><strong>zsh</strong></span>, mais vous pouvez l’adapter facilement à votre shell favori. Utilisez l’option
 <span class="command"><strong>-p</strong></span> pour que <span class="command"><strong>ssh</strong></span> essaie un autre port que le port 22 (mais à ce moment-là, veillez à bien lancer <span class="command"><strong>sshd</strong></span> sur le même port).
</p><p>
Notez que le script suppose que <span class="command"><strong>ssh</strong></span> peut s’ouvrir sans que vous ayez à taper interactivement votre mot de passe (en effet, son tty de contrôle sera connecté à <span class="command"><strong>pppd</strong></span>, alors s'il vous demande un mot de passe, c’est raté). Ceci peut se faire soit avec les clefs ssh dans votre
<code class="filename">˜/.ssh/authorized_keys</code>
pour lesquelles un mot de passe n'est pas nécessaire, ou que l'on peut débloquer en utilisant
 <span class="command"><strong>ssh-agent</strong></span> ou <span class="command"><strong>ssh-askpass</strong></span>. Regardez votre documentation sur ssh. En fait vous pourriez aussi utiliser un script de chat pour entrer votre mot de passe, mais ce n’est assurément <span class="emphasis"><em>pas</em></span> la chose à faire.
</p><p>
Si vous n’êtes pas <span class="command"><strong>root</strong></span> ou simplement si vous voulez protéger le réseau de votre client des connexions sortantes, vous pouvez utiliser <span class="command"><strong>slirp</strong></span> au lieu de <span class="command"><strong>pppd</strong></span>
comme émulateur PPP du serveur. Il n’y a qu’à décommenter la ligne appropriée.
</p><p>
</p><pre class="programlisting">

#!/bin/zsh -f
SERVER_ACCOUNT=root@server.fqdn.tld
SERVER_PPPD="pppd ipcp-accept-local ipcp-accept-remote"
#SERVER_PPPD="pppd" ### Ceci suffit normalement si c’est dans /usr/sbin/
#SERVER_PPPD="/home/joekluser/bin/slirp ppp"
CLIENT_PPPD=( pppd
	silent
	10.0.2.15:10.0.2.2
	### Si vous voulez tester décommentez les lignes suivantes:
	# updetach debug
	### Une autre option potentiellement utile (allez voir la section sur le routage)&amp;nbsp;:
	# defaultroute
)
$CLIENT_PPPD pty "ssh -t $SERVER_ACCOUNT $SERVER_PPPD"

</pre><p>
</p><p>
Notez que les options par défaut de votre <code class="filename">/etc/ppp/options</code>
ou <code class="filename">˜/.slirprc</code>
peuvent casser ce script, enlevez donc toute option non désirée.
</p><p>
Notez également que <code class="literal">10.0.2.2</code> est le paramétrage par défaut pour <span class="command"><strong>slirp</strong></span>, ce qui peut ne pas fonctionner avec votre installation particulière. En tout cas, vous devriez de préférence utiliser une adresse dans l’une des catégories réservées par la RFC-1918 pour les réseaux privés :
<code class="literal">10.0.0.0/8</code>,
<code class="literal">172.16.0.0/12</code> ou <code class="literal">192.168.0.0/16</code>.
Il se pourrait que le réseau local protégé par pare-feu utilise certaines d’entre elles et il est de votre responsabilité d’éviter les conflits. Pour une plus grande personnalisation, lisez la documentation appropriée.
</p><p>
Si le <span class="command"><strong>pppd</strong></span> de votre client est vieux ou non-linux (par exemple BSD) et n’a pas d’option <span class="command"><strong>pty</strong></span>, utilisez :
</p><pre class="programlisting">
cotty -d -- $CLIENT_PPPD -- ssh -t $SERVER_ACCOUNT $SERVER_PPPD
</pre><p>
Pièges : ne mettez pas les commandes données à cotty entre guillemets, car elles s’exécutent <span class="command"><strong>exec()</strong></span>telles quel, et n’oubliez pas de spécifier le chemin complet pour le <span class="command"><strong>pppd</strong></span>
du serveur s’il n’est pas dans le chemin standard installé par <span class="command"><strong>ssh</strong></span>.
</p><p>
On laisse au lecteur la reconnexion automatique (conseil : l’option
<span class="command"><strong>nodetach</strong></span> de <span class="command"><strong>pppd</strong></span>
pourrait être utile pour ça).
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e621"/>5. La solution non sécurisée : percer en utilisant telnet</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e624"/>5.1. Principe</h3></div></div></div><p>
Si vous ne pouvez faire que du <span class="command"><strong>telnet</strong></span>
(à cause d’un proxy <span class="command"><strong>telnet</strong></span>),
cette solution pourrait bien vous convenir.
</p><p>

Le programme de perçage de pare-feu, <span class="command"><strong>fwprc</strong></span>, utilisera 
un proxy tty, <span class="command"><strong>cotty</strong></span>, qui ouvre deux dispositifs 
pseudo-tty, lance des commandes sur chacun des esclaves de ces 
dispositifs, et copie systématiquement chaque caractère que l’on sort 
sur le tty qui sert d’entrée pour l’autre commande. Une commande sera 
une connexion telnet vers le site serveur, et l’autre sera le 
<span class="command"><strong>pppd</strong></span>. <span class="command"><strong>pppd</strong></span> peut alors ouvrir et 
contrôler la session telnet avec un script de chat comme d’habitude.

</p><p>
En fait, si votre proxy telnet permet une connexion vers un port arbitraire, et si vous pouvez lancer un démon de manière sûre sur l’hôte serveur (avec relance planifiée [cron] en cas de plantage), vous feriez mieux d’écrire un programme qui connectera juste un port côté client au port côté serveur par le proxy, afin de pouvoir utiliser la solution sécurisée ci-dessus, en utilisant éventuellement une variante de 
</p><pre class="programlisting">
ssh -t -o "ProxyCommand ..."
</pre><p>
(Soumettez moi une solution et je l’intégrerai volontiers à la distribution
<span class="command"><strong>fwprc</strong></span>).
</p><p>
Remarque : si vous devez utiliser la solution non sécurisée basée sur le telnet, assurez vous que, dans votre session cible, il ne se trouve rien de confidentiel ou qui ne doive être bidouillé, puisque le mot de passe sera envoyé en clair sur internet. Si c’est à votre portée, un système ne demandant le mot de passe qu’une seule fois, ou un système de cryptographie explicite augmentera votre sécurité, ce qui, toutefois, rendra les scripts de connexion automatique bien plus complexes.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e659"/>5.2. fwprc</h3></div></div></div><p>
J’ai écrit un script qui décrit de façon très détaillée comment percer les pare-feu, <span class="command"><strong>fwprc</strong></span>,
disponible sur
<a class="ulink" href="http://fare.tunes.org/files/fwprc/" target="_top">mon site</a>,
avec également <span class="command"><strong>cotty</strong></span>
(qui est requis à partir de la version <code class="literal">0.2</code> de
 <span class="command"><strong>fwprc</strong></span>).
Au moment où j’ai écrit ces lignes, la version la plus avancée de
<span class="command"><strong>fwprc</strong></span> est <code class="literal">0.3e</code> et pour
<span class="command"><strong>cotty</strong></span> <code class="literal">0.4c</code>.
</p><p>
Le nom « fwprc » est volontairement illisible et imprononçable, afin d’embrouiller votre administrateur système incompétent et paranoïaque sans doute responsable de ce pare-feu qui vous casse les pieds (bien sûr il peut y avoir des pare-feu légitimes également, et parfois même, ils sont indispensables ; la sécurité n’est qu’un problème de configuration
<span class="emphasis"><em>correcte</em></span>).
Si vous devez le lire à voix haute, prononcez le de la pire façon possible et imaginable.
</p><p>
GRAND CONCOURS ! Envoyez moi un fichier audio avec un enregistrement audio numérique de votre prononciation de « fwprc ». Le prix pour la prononciation la plus mauvaise est une mise à niveau gratuite et le nom du gagnant sur la page du
 <span class="command"><strong>fwprc</strong></span> <code class="literal">1.0</code>!
</p><p>
J’ai testé le programme sur différentes configurations, en le configurant avec des fichiers ressources. Mais bien entendu, selon la loi de l’emmerdement maximum, ça plantera pour vous. N’hésitez pas à proposer les améliorations qui faciliteront la vie de ceux qui configureront après vous.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e706"/>5.3. .fwprcrc</h3></div></div></div><p>
<span class="command"><strong>fwprc</strong></span> peut être personnalisé grâce au fichier
<code class="filename">.fwprcrc</code>
fait pour être le même des deux côtés du pare-feu. Avoir plusieurs configurations de rechange parmi lesquelles choisir est certes possible (par exemple, <span class="emphasis"><em>moi</em></span> je le fais), et on laisse ça comme exercice pour le lecteur.
</p><p>
Pour commencer, copiez la section appropriée de <span class="command"><strong>fwprc</strong></span>
(l’avant-dernière) dans un fichier nommé <code class="filename">.fwprcrc</code>
dans votre répertoire home. Remplacez ensuite les valeurs des variables par des trucs qui correspondent à votre configuration. Enfin, copiez le sur l’autre hôte et testez.
</p><p>
Le comportement par défaut est d’utiliser <span class="command"><strong>pppd</strong></span> sur le client, et <span class="command"><strong>slirp</strong></span> sur le serveur. Pour modifier ceci, vous pouvez redéfinir la fonction appropriée dans votre <code class="filename">.fwprcrc</code> avec une ligne telle que :
</p><pre class="programlisting">
remote_IP_emu () { remote_pppd }
</pre><p>
</p><p>
Notez que <span class="productname">SLiRP</span>™ est plus sûr que
<span class="command"><strong>pppd</strong></span>, et plus facile d’accès, puisqu’il ne requiert pas d’être root sur la machine serveur, et n’a pas besoin d’une configuration supplémentaire du pare-feu pour empêcher les connexions du monde extérieur sur le réseau derrière un pare-feu. La fonctionnalité de base dans
<span class="productname">SLiRP</span>™ fonctionne plutôt bien, mais je n’ai pas réussi à faire marcher certains des plus qu’il est censé proposer (tel que le contrôle du temps d’exécution). Bien entendu, puisqu’il s’agit d’un logiciel libre, n’hésitez pas à aller dans la source pour carrément implémenter ou réparer n’importe quel dispositif dont vous aurez besoin.
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e753"/>6. Routage</h2></div></div></div><p>

Il ne suffit pas de percer le pare-feu. Il faut également router les 
paquets du côté client du pare-feu vers le côté serveur. Dans cette 
section, j’aborde les paramètres de base spécifiques au routage à 
travers un tunnel. Pour plus d’explications détaillées sur le routage, 
lisez les guides pratiques correspondants et les pages de manuel sur les 
réseaux, le routage et l’usurpation d’identité.

</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e758"/>6.1. Il y a un truc</h3></div></div></div><p>
Le truc, c’est que, même si votre administrateur réseau vous demandait d’installer un routeur de votre côté client comme route par défaut, (ceci peut être utile si on veut une route spécifique vers les réseaux sur le client du pare-feu), il faudra installer PPP link comme route vers les réseaux sur le côté serveur.
</p><p>
En d’autres termes, votre route par défaut devrait pointer vers un routeur de n’importe quel côté du tunnel qui vous donne accès à internet.
</p><p>
Ce qui est primordial, c’est que les paquets envoyés au serveur hôte en tant qu’élément de fonctionnement du tunnel doivent être routés à travers votre réseau habituel (par exemple votre routeur ethernet par défaut), autrement, votre kernel aura des problèmes, vu qu’il essaie de router à l’intérieur du tunnel les paquets qui, précisément, devraient constituer l’extérieur du tunnel.
</p><p>
Ainsi donc, vous devrez paramétrer correctement les routes dans votre configuration de démarrage du réseau. L’emplacement précis de vos données de configuration de routage dépend de votre distribution, mais c’est généralement sous <code class="filename">/etc/init.d/network</code>
ou <code class="filename">/etc/network/</code>;
de même, votre configuration PPP se trouve généralement dans <code class="filename">/etc/ppp/</code>, et l’endroit normal pour configurer ces routes se trouve habituellement dans <code class="filename">ip-up</code> ou <code class="filename">ip-up.d/</code>.
(Astuce : pour identifier les emplacements de fichier spécifiques à votre distribution, vous devez lire la documentation de votre distribution ou encore
<a class="ulink" href="http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?RTFM" target="_top">RTFM</a>;
sinon, utilisez <span class="command"><strong>grep</strong></span> récursivement dans votre
 <code class="filename">/etc</code>;
au pire, repérez ce qui se passe au moment du démarrage, comme configuré dans votre <code class="filename">/etc/inittab</code>.)
</p><p>
Lorsque vous percez un tunnel dans un réseau protégé à partir d’un portable sur internet, le script <span class="command"><strong>getroute.pl</strong></span>
(disponible sur la distribution <span class="command"><strong>fwprc</strong></span>)
donne la route utilisée vers le serveur hôte qui représente l’autre bout du tunnel.
</p><p>

Une fois que vous pouvez router les paquets vers le côté serveur du 
tunnel, ça vous intéressera peut-être de configurer votre machine comme 
routeur pour tous vos copains du côté client du pare-feu ; vous 
aurez ainsi réalisé un véritable VPN partagé. Ceci n’est pas spécifique 
au perçage de pare-feu, alors lisez donc les guides pratiques 
correspondants sur les réseaux, le routage et l’usurpation d’identité. 
Egalement, pour des raisons de sécurité, veillez à bien installer un bon 
pare-feu sur votre machine, surtout si vous devez être routeur pour 
d’autres personnes.

</p><p>
Enfin, souvenez vous que si vous utilisez <span class="command"><strong>pppd</strong></span>
sur le côté serveur du tunnel (par opposition au mode utilisateur
<span class="command"><strong>slirp</strong></span>), vous devrez également configurer les routes qu’il faut et des règles de pare-feu du côté serveur du tunnel.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e814"/>6.2. Exemple de routage</h3></div></div></div><p>
Dans cet exemple, votre machine cliente est connectée à un réseau local avec pare-feu grâce au dispositif ethernet <code class="filename">eth0</code>.
Son adresse IP est <code class="literal">12.34.56.78</code>;
son réseau est <code class="literal">12.34.56.0/24</code>;
son routeur est <code class="literal">12.34.56.1</code>.
</p><p>
Votre administrateur réseau peut vous avoir dit d’utiliser
<code class="literal">12.34.56.1</code>
comme routeur par défaut, mais n’en tenez pas compte. Vous devez seulement l’utiliser comme route vers le côté client du pare-feu.
</p><p>
Supposons que le côté client du pare-feu est composé des réseaux
<code class="literal">12.34.0.0/16</code> et <code class="literal">12.13.0.0/16</code>,
et de l’hôte <code class="literal">11.22.33.44</code>.
Pour les rendre accessibles par votre routeur client, ajoutez ces routes au script de démarrage de votre réseau global :
</p><pre class="programlisting">
route add -net 12.34.0.0 netmask 255.255.0.0 gw 12.34.56.1
route add -net 12.13.0.0 netmask 255.255.0.0 gw 12.34.56.1
route add -host 11.22.33.44 gw 12.34.56.1
</pre><p>
Vous devez également garder la route vers le réseau local du client, nécessaire pour le kernel 2.0 de Linux , mais pas pour le kernel 2.2 et suivants de Linux (ceci l’ajoute implicitement pendant le <span class="command"><strong>ifconfig</strong></span>):
</p><pre class="programlisting">
route add -net 12.34.56.0 netmask 255.255.255.0 dev eth0
</pre><p>
Par contre, vous devez <span class="emphasis"><em>impérativement</em></span> enlever toute route par défaut de vos scripts. Supprimez ou mettez en commentaire une ligne telle que :
</p><pre class="programlisting">
route add default gw 12.34.56.1
</pre><p>
Remarquez qu’il est également possible d’enlever la route de la configuration du kernel en marche sans redémarrer, grâce à la commande suivante :
</p><pre class="programlisting">
route del default gw 12.34.56.1
</pre><p>
Vous pouvez ensuite obtenir de <span class="command"><strong>pppd</strong></span> l’installation automatique d’une route par défaut lorsqu’il démarre en utilisant son option
 <span class="command"><strong>defaultroute</strong></span> Sinon, vous pouvez l’ajouter plus tard :
</p><pre class="programlisting">
route add default gw 10.0.2.2
</pre><p>
Si vous ne voulez pas de <span class="command"><strong>pppd</strong></span> comme route par défaut, parce que l’accès internet est disponible de votre côté du pare-feu, et si vous voulez plutôt que le réseau <code class="literal">98.76.48.0/20</code>
soit routé par le tunnel, sauf au départ de l’hôte <code class="literal">98.76.54.32</code>
qui représente l’autre bout du tunnel, ajoutez les lignes suivantes à votre
<code class="filename">/etc/ppp/ip-up</code>:
</p><pre class="programlisting">
route add -host 98.76.54.32 gw 12.34.56.1
route add -net 98.76.48.0 netmask 255.255.240.0 gw 10.0.2.2
</pre><p>
Si vous êtes sur un portable et que vous changez de réseau local, mais que vous voulez quand même garder votre route actuelle vers
 <code class="literal">98.76.54.32</code>,
utilisez <span class="command"><strong>getroute.pl</strong></span> comme suit pour trouver automatiquement la bonne passerelle dans la commande <span class="command"><strong>route add -host</strong></span> :
</p><pre class="programlisting">
$(getroute.pl 98.76.54.32)
</pre><p>
Remarquez que si vous les avez dans votre <code class="filename">/etc/hosts</code>,
vous pouvez utiliser des noms symboliques au lieu des adresses IP numériques (et vous pouvez même utiliser des FQDN, si vous pensez que le DNS ne plante jamais).
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e904"/>7. Perçage inverse</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e907"/>7.1. La logique</h3></div></div></div><p>
Des fois, seul un côté du pare-feu peut lancer des sessions telnet vers l’autre côté, cependant, un moyen de communication est possible (en général par le courrier électronique). Percer un pare-feu est toujours possible, en déclenchant, grâce à n’importe quel moyen de transmission de messages disponible, une connexion telnet du « bon » côté du pare-feu vers l’autre côté.
</p><p>
<span class="command"><strong>fwprc</strong></span> inclut du code pour déclencher de telles connexions à partir d’un courriel authentifié par OpenPGP ; il suffit d’ajouter
 <span class="command"><strong>fwprc</strong></span> comme filtre <span class="command"><strong>procmail</strong></span> aux messages utilisant ce protocole (instructions contenues dans
 <span class="command"><strong>fwprc</strong></span> lui-même). Remarquez cependant que si vous devez lancer <span class="command"><strong>pppd</strong></span>
avec les privilèges appropriés, il vous faudra peut-être créer votre propre suid wrapper pour devenir root. Instructions incluses dans
 <span class="command"><strong>fwprc</strong></span>.
</p><p>
En outre, déclenchement authentifié ne signifie absolument pas connexion sécurisée. Il faut vraiment utiliser <span class="command"><strong>ssh</strong></span> (peut être en plus de telnet) pour des connexions sécurisées. Et puis méfiez vous de ce qui se passe entre le déclenchement d’une connexion telnet, et le moment ou
 <span class="command"><strong>ssh</strong></span> prend en main cette connexion. Toute contribution à ce sujet sera la bienvenue.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e940"/>7.2. Obtenir le message de déclenchement</h3></div></div></div><p>
Si vous êtes sous un pare-feu, votre messagerie peut tout-à-fait être dans un serveur de messagerie central qui ne fait pas de filtrage procmail ou qui n’autorise pas les sessions telnet. Aucun problème! Vous pouvez lancer
<span class="command"><strong>fetchmail</strong></span> en mode démon (ou comme tâche cron) pour interroger votre serveur de messagerie et distribuer le courrier à votre système linux qui, lui-même, aura été configuré pour utiliser <span class="command"><strong>procmail</strong></span>
à la réception. Remarquez que si vous lancez <span class="command"><strong>fetchmail</strong></span> comme démon en arrière plan, il bloquera tout autre fetchmail que vous voudriez simplement lancer à d’autres moments, comme lorsque vous ouvrez un
 <span class="command"><strong>fwprc</strong></span>;
bien entendu, si c’est possible, lancez également un démon fetchmail en tant qu’utilisateur bidon. Des scrutations trop fréquentes ne seront pas bonnes pour le serveur de messagerie ou pour l’hôte. Si elles sont trop peu fréquentes, vous devrez attendre avant que le message ne soit lu et que la connexion inverse soit établie. J’utilise une fréquence de scrutation de deux minutes.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e957"/>7.3. Autres outils automatiques pour le perçage inverse</h3></div></div></div><p>
Un autre moyen d’interroger un serveur pour voir les messages, quand on n’a pas de boîte de messagerie, mais qu’on a bien un accès FTP vers l’extérieur, est d’utiliser un
<a class="ulink" href="http://dhirajbhuyan.hypermart.net/ftp-tunnel.html" target="_top">tunnel FTP</a>.
</p><p>
Comme outil pour maintenir une connexion permanente entre un hôte sous pare-feu et un proxy externe, afin d’exporter des services depuis l’hôte vers l’extérieur, il y a le
 <a class="ulink" href="http://www.employees.org/~hek2000/projects/firewallTunnel/" target="_top"> tunnel pare-feu</a>.
</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title"><a id="d0e970"/>8. Remarques finales</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e973"/>8.1. Autres réglages</h3></div></div></div><p>

Je n’ai aucune idée sur la manière de percer des pare-feu avec des 
systèmes d’exploitation de niveau inférieur, mais vous pouvez prendre un 
de ces vieux ordinateurs hors d’usage (quasiment tout ce qui a 8 Mo de 
RAM et une carte ethernet devrait aller), y installer Linux ou BSD, et 
percer le pare-feu avec, tout en servant de routeur pour les autres 
machines fonctionnant avec des SE de niveau inférieur. Lisez les guides 
pratiques correspondants sur le routage, l’acheminement IP, NAT, etc.

</p><p>
Je ne connais pas les détails, mais il existe un outil prometteur pour percer les pare-feu  : le <a class="ulink" href="http://www.r00t3d.org.uk/" target="_top">Bouncer</a> de Chris Mason, qui joue le rôle de proxy SOCKS par-dessus SSL.
</p><p>
Il y a d’autres sortes de pare-feu que ceux qui autorisent les connexions ssh ou telnet directes. Tant qu’un flot continu de paquets peut transmettre des informations à travers un pare-feu dans les deux directions, il est possible de le percer ; seulement, le prix pour écrire le perforateur peut être plus ou moins élevé.
</p><p>
Cela peut être très facile : ainsi, on a remarqué qu’il suffit de lancer
 <span class="command"><strong>ssh</strong></span> sur un maître pty et faire du <span class="command"><strong>pppd</strong></span> sur l’esclave tty. Si on le souhaite, on peut même le faire sans qu’il soit question de pare-feu, juste pour construire un VPN sécurisé (Virtual Private Network).
Le <a class="ulink" href="http://www.linuxdoc.org/HOWTO/mini/VPN.html" target="_top">VPN mini-HOWTO</a>
donne tous les détails nécessaires à ce sujet. Comme exercice, nous vous invitons, à modifier <span class="command"><strong>fwprc</strong></span>
pour utiliser cette technique, ou peut-être même pour l’utiliser à l’intérieur d’une précédente session <span class="command"><strong>fwprc</strong></span> non sécurisée.
</p><p>
Maintenant si le seul chemin à travers le pare-feu est un proxy WWW (ce qui est habituellement un minimum pour un réseau connecté à internet), on pourra utiliser le script <a class="ulink" href="http://www.snurgle.org/~griffon/ssh-https-tunnel" target="_top">ssh-https-tunnel</a> de 
 <a class="ulink" href="http://www.snurgle.org/~griffon/" target="_top">Chris Chiappa</a>.
</p><p>
Autre programme prometteur pour percer à travers http  : le <a class="ulink" href="http://www.nocrew.org/software/httptunnel/" target="_top">httptunnel</a> de 
<a class="ulink" href="http://lars.nocrew.org/" target="_top">Lars Brinkoff</a>,
une combinaison serveur et client http permettant une connexion TCP/IP par tunnel grâce au protocole http. On devrait ensuite pouvoir lancer
<span class="command"><strong>fwprc</strong></span>
(de préférence par-dessus <span class="command"><strong>ssh</strong></span>)
sur cette connexion, bien que je n’aie pas encore essayé. Quelqu’un pourrait-il tester et faire un rapport ? Remarquez que 
<span class="command"><strong>httptunnel</strong></span> est toujours en cours de développement, vous pouvez donc aider à implémenter les fonctionnalités qui lui manquent actuellement, telles que les connexions multiples, et/ou servir des pages bidon pour leurrer les administrateurs méfiants de pare-feu excessivement hermétiques.
</p><p>
Quel que soit ce qui passe à travers votre pare-feu, que ce soit telnet, http ou autres connexions TCP/IP, ou des choses vraiment bizarres comme les requêtes DNS, les paquets ICMP, le courrier électronique (lisez
<a class="ulink" href="http://www.detached.net/mailtunnel/" target="_top">mailtunnel</a>,
<a class="ulink" href="http://www.detached.net/icmptunnel/" target="_top">icmptunnel</a>),
ou que sais-je encore, vous pouvez toujours écrire une combinaison tunnel client/serveur, et lancer un <span class="command"><strong>ssh</strong></span> et/ou une connexion PPP à travers celui-ci. La performance pourrait ne pas être très bonne, en fonction de la vitesse effective de communication de l’information après avoir payé les charges dûes au codage de l’ensemble des filtres et proxies, mais un tel tunnel est toujours intéressant tant qu’il peut au moins servir à utiliser
 <span class="command"><strong>fetchmail</strong></span>, <span class="command"><strong>suck</strong></span>,
et autres programmes non interactifs.
</p><p>
Si vous devez traverser une ligne 7 bits, vous devrez utiliser SLIP au lieu de PPP. Je n’ai jamais essayé, parce que les lignes sont plus ou moins 8 bits maintenant, mais ça ne devrait pas être difficile. Si nécessaire, rabattez vous sur le
<a class="ulink" href="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html" target="_top">Term-Firewall mini-HOWTO</a>.
</p><p>
Si vous avez une connexion 8 bits propre et que vous êtes root sur linux des deux côtés du pare-feu, vous pouvez utiliser ethertap pour de meilleures performances, en encapsulant des communications ethernet brutes en plus de votre connexion. David Madore a écrit sur les tunnels ethertap-sur-TCP et ethertap-sur-UDP
<a class="ulink" href="ftp://quatramaran.ens.fr/pub/madore/misc/" target="_top">ftp://quatramaran.ens.fr/pub/madore/misc/</a>.
Il reste à traiter de ethertap-sur-tty pour combiner avec des outils comme fwprc.
</p><p>
Si vous cherchez une performance supérieure à celle obtenue en payant un tunnel à communication séquentielle, niveau espace utilisateur, à travers lequel lancer PPP, vous êtes dans la situation très difficile où vous devrez rebidouiller une drôle de pile IP, en utilisant (par exemple) les fonctions de type ‘functor’ des protocoles par paquets du projet Fox. Vous obtiendrez alors une IP sur HTTP, une IP sur DNS, une IP sur ICMP, ou autre, directe, qui requiert non seulement un protocole élaboré, mais également une interface vers un noyau de SE, qui sont tous deux chers à implémenter.
</p><p>
Pour finir, si vous n’êtes pas en train de vous battre contre un pare-feu excessivement hermétique, mais que vous faites juste votre propre VPN, il y a un large éventail d’outils VPN, et bien que les trucs que je présente soient simples, qu'ils fonctionnent bien, et qu'ils peuvent être suffisants pour vos besoins, ça serait peut-être pas mal de rechercher dans cette offre évolutive (dont je ne connais pas grand-chose) une solution qui correspond à vos besoins au niveau performance et maintenabilité.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e1058"/>8.2. Le suivi de ce petit guide</h3></div></div></div><p>

J'ai pensé qu’il était nécessaire de l’assurer, mais je n’ai pas 
beaucoup de temps pour ça, donc ce petit guide est très sommaire. Il va 
donc rester ainsi jusqu’à ce que j’obtienne assez de retours 
d’information pour savoir quelle section améliorer, ou mieux, jusqu’à ce 
que quelqu’un vienne se charger du suivi de ce petit guide. Tout retour 
d’information est le bienvenu. Toute aide est la bienvenue. La prise en 
charge du suivi du petit guide est la bienvenue.

</p><p>
En tout cas, les sections ci-dessus montrent que de nombreux problèmes peuvent être facilement résolus si quelqu’un (vous ?) y consacre un peu de temps (ou d’argent, en engageant quelqu’un d’autre) ; il n’y a qu’à s’asseoir et écrire : le concept n’est pas difficile, bien que, dans le détail, cela puisse ne pas être simple ou évident.
</p><p>
N’hésitez pas à proposer d’autres problèmes, et, espérons-le, d’autres solutions, pour ce petit guide.
</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e1067"/>8.3. Documents sur le sujet</h3></div></div></div><p>
Le <a class="ulink" href="http://www.linuxdoc.org/" target="_top">LDP</a>
publie de nombreux documents en rapport avec ce
<a class="ulink" href="http://www.linuxdoc.org/HOWTO/HOWTO-INDEX/mini.html" target="_top">petit guide</a>.
tout particulièrement 
<a class="ulink" href="http://www.securityportal.com/lskb/" target="_top">Linux Security Knowledge Base</a>,
le <a class="ulink" href="http://www.linuxdoc.org/HOWTO/VPN.html" target="_top">HOWTO VPN</a>
et le <a class="ulink" href="http://www.linuxdoc.org/HOWTO/mini/VPN.html" target="_top">petit guide VPN</a>.
Pour des questions plus générales sur le réseau, le routage et les pare-feu, commencez avec le
 <a class="ulink" href="http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html" target="_top">Networking Overview HOWTO</a>.
Regardez également le
 <a class="ulink" href="http://www.linux-firewall-tools.com/linux/" target="_top">Linux Firewall and Security site</a>.
</p><p>
Là encore, lorsque vous rencontrez un problème avec un programme, le réflexe pour tout utilisateur de Linux devrait être de Lire le Pstain [sic] de Manuel
 <a class="ulink" href="http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?RTFM" target="_top"> [RTFM : Read The Fscking Manual]
 </a> sur les programmes en question.
 </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e1098"/>8.4. Le mot de la fin</h3></div></div></div><p>
Je suis arrivé à la conclusion que, de la même façon que le besoin en Design Patterns venait directement du fait que les gens utilisaient des langages inférieurs tels que le
 <span class="productname">C++</span>™ ou le <span class="productname">Java</span>™
qui ne permettent pas d’exprimer directement des constructions de programmation de plus haut niveau (alors que de bons langages tels que le
 <span class="productname">LISP</span>™
permettent de les exprimer), on peut dire que le besoin en guides 
pratiques vient directement du fait que les systèmes
 <span class="productname">Linux</span>™ et <span class="productname">UNIX</span>™ sont des systèmes d’exploitation inférieurs qui ne permettent pas d’exprimer directement les tâches que les gens essayent de faire avec, qui sont pourtant simples.
</p><p>

Si vous pensez que tout ce bidouillage de scripts stupides et de guides 
pratiques idiots est trop compliqué et qu’un système d’ordinateur 
convenable devrait nous automatiser tout ça, alors bienvenu au club des 
allergiques comme moi à UNIX (<a class="ulink" href="http://www.research.microsoft.com/~daniel/preface.html" target="_top">UNIX 
haters</a>) et de ceux qui détestent les systèmes de bas niveau 
actuels, et aspirent à des systèmes informatiques déclaratifs qui 
prennent en charge tous les détails sans intérêt et nous laissent nous 
concentrer sur les choses importantes (jetez un œil, si ça vous dit, à 
mon propre projet <a class="ulink" href="http://tunes.org/" target="_top">TUNES</a>).

</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="d0e1126"/>8.5.  Copie supplémentaire de l’avis très important de non responsabilité — croyez le !!!</h3></div></div></div><p>
<span class="quote">« <span class="quote"><span class="emphasis"><em> Par la présente je décline toute responsabilité quant à l’utilisation que vous ferez de cette méthode d'effraction [hack]. Si ça se retourne contre vous d’une manière ou d'une autre, c’est pas de pot. Et ce n’est pas ma faute. Si vous ne comprenez pas les risques encourus, laissez tomber. Si vous utilisez cette méthode et qu’elle permet à des vandales sans scrupules de pénétrer dans les ordinateurs de votre société et que ça vous coûte votre boulot et des millions d’euros à votre entreprise, eh bien c’est pas de pot. Ne venez pas pleurer chez moi.</em></span>
</span> »</span>
</p></div></div></div></body></html>
doc-linux-fr-html 2013.01-3 / usr / share / doc / HOWTO / fr-html / Firewall-Piercing.html
