                      Petit guide du perage de pare-feux

  Version franaise du petit guide Firewall Piercing mini-HOWTO

  Franois-Ren Rideau

   <fare PLUS fwprc CHEZ tunes POINT org>

  Arnaud Muller

   Adaptation franaise<arnaud POINT muller CHEZ insa TIRET rouen POINT fr>

  Yvon Benoist

   Relecture de la version franaise<yvon POINT benoist CHEZ insa TIRET rouen
   POINT fr>

  Jean-Philippe Gurard

   Prparation de la publication de la v.f.<fevrier CHEZ tigreraye POINT org>

   Version : 0.97

   18 septembre 2006

   +------------------------------------------------------------------------+
   | Historique des versions                                                |
   |------------------------------------------------------------------------|
   | Version 0.97.fr.1.0          | 2006-09-18         | AM, YB, JPG        |
   |------------------------------------------------------------------------|
   | Premire version franaise.                                            |
   |------------------------------------------------------------------------|
   | Version 0.97                 | 2001-11-24         | FRR                |
   |------------------------------------------------------------------------|
   | Conversion au format SGML DocBook. Conversion to DocBook SGML.         |
   +------------------------------------------------------------------------+

   Rsum

   Comment utiliser ppp par-dessus ssh, telnet ou autre, de faon  raliser
   une connexion rseau transparente  travers un pare-feu. Valable aussi
   bien pour l'laboration d'un VPN convivial que pour la perforation des
   pare-feu gnants.

   --------------------------------------------------------------------------

   Table des matires

   Divers

                Avis de non-responsabilit

                Baratin juridique

                Recherche responsable de la maintenance

                Remerciements

                Dernires versions

   Introduction

                Avant propos

                Les problmes de scurit.

                Autres conditions requises

                Logiciels  tlcharger

   Comprhension du problme

                Donner un nom aux choses

                Le problme principal

                Le problme annexe

   La solution scurise : percer en utilisant ssh

                Principe

                Exemple de session

   La solution non scurise : percer en utilisant telnet

                Principe

                fwprc

                .fwprcrc

   Routage

                Il y a un truc

                Exemple de routage

   Perage inverse

                La logique

                Obtenir le message de dclenchement

                Autres outils automatiques pour le perage inverse

   Remarques finales

                Autres rglages

                Le suivi de ce petit guide

                Documents sur le sujet

                Le mot de la fin

                Copie supplmentaire de l'avis trs important de non
                responsabilit -- croyez le !!!

Divers

  Avis de non-responsabilit

   Lisez cette section, elle est importante !!!!

   Par la prsente je dcline toute responsabilit quant  l'utilisation que
   vous ferez de cette mthode d'effraction [hack]. Si a se retourne contre
   vous d'une manire 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 mthode de piratage et qu'il permet  des vandales
   sans scrupules de pntrer dans les ordinateurs de votre socit et que a
   vous cote votre boulot et des millions d'euros  votre entreprise, eh
   bien c'est pas de pot. Ne venez pas pleurer chez moi.

  Baratin juridique

   Copyright  1998-2001 par Franois-Ren Rideau.

   Ce document est publi en logiciel libre sous la license bugroff
   [http://www.geocities.com/SoHo/Cafe/5947/bugroff.html].

   Pour faciliter leur travail, les droits ont galement t cds aux
   responsables de la maintenance du LDP [Linux Development Project] sous la
   Licence de Documentation Libre GNU [http://www.gnu.org/copyleft/fdl.html].

  Recherche responsable de la maintenance

   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 entire en s'tendant davantage sur les
   solutions dont je ne fais que mentionner l'existence, et qui pourrait peut
   tre dvelopper des logiciels pour rendre la perforation de pare-feu plus
   facile. J'ai normment d'ides pour tendre le contenu de ce petit guide
   et dvelopper un logiciel adquat, si quelqu'un est intress. J'avais
   galement crit une version franaise de ce guide pratique, mais personne
   n'en assure plus la maintenance depuis longtemps [NdT : ceci est une
   nouvelle traduction].

  Remerciements

   Mme si tout ce qu'il en reste est le paragraphe sur la non
   responsabilit, ce document doit normment au Term-Firewall mini-HOWTO
   [http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html] de Barak
   Pearlmutter <bap CHEZ cs POINT unm POINT edu>. Le petit guide de Barak
   repose sur Term(TM), 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 particularits d'une
   implmentation non standard de telnet, autrement dit beaucoup d'lments
   obsoltes et non portables. Nanmoins, un petit guide sur la perforation
   des pare-feu tait ncessaire, et malgr les limites des mthodes
   d'effraction [hacks] qu'il propose, son petit guide a t un modle et un
   encouragement.

   J'aimerais galement fliciter Lars Brinkhoff <lars CHEZ nocrew POINT org>
   et Magnus Lundstrm <logic CHEZ gore POINT nocrew POINT org> pour leurs
   trs bons tunnels http, messagerie et icmp.

  Dernires versions

   La dernire version LDP officielle de ce document est sur :
   http://www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html
   [http://www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html]

   La source de ma dernire version officielle de ce document est sur :
   http://fare.tunes.org/files/fwprc/ [http://fare.tunes.org/files/fwprc/]

   La source de mon dernier brouillon de travail pour ce document est sur :
   http://tunes.org/cgi-bin/cvsweb/fare/fare/www/articles/Firewall-Piercing.en.sgml
   [http://tunes.org/cgi-bin/cvsweb/fare/fare/www/articles/Firewall-Piercing.en.sgml]

Introduction

  Avant propos

   Ce document a une morale. Et cette morale est : un pare-feu ne peut pas
   protger un rseau contre ses propres utilisateurs internes et ne devrait
   mme pas essayer.

   Lorsqu'un utilisateur interne vous demande  vous, administrateur systme,
   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 sr que ses transactions sont scurises, et
   que son logiciel est robuste. Mais refuser carrment de rendre ce service
    l'utilisateur relve d'une incomptence vidente. A moins que le
   pare-feu ne le coupe compltement du reste du monde extrieur, au point de
   se retrouver sans ssh, telnet, navigateur web, courrier lectronique, dns,
   ligne tlphonique, radio, et sans pouvoir faire de ping, rien de rien, il
   n'en demeure pas moins que l'utilisateur peut utiliser les techniques de
   perforation de pare-feu pour accder aux machines qu'il veut , et il le
   fera, et, rsultat final au niveau scurit, on aura une connexion non
   vrifie avec le monde extrieur. Alors soit vous faites confiance  vos
   utilisateurs, aprs une formation et une slection appropries, soit vous
   leur refusez tout accs au rseau; mais l encore le rle d'un
   administrateur rseau est habituellement de servir ses utilisateurs, alors
   c'est plutt le premier cas de figure qu'il faut viser, pas le deuxime.
   Vous pouvez et vous devez les protger contre le monde extrieur, vous
   pouvez et vous devez protger vos services sensibles contre vos
   utilisateurs, mais vous ne les protgerez point contre eux-mmes, et vous
   ne le pouvez pas.

   Parce que des administrateurs passifs, ou absents, ou surchargs, ou
   carrment incomptents, ou irresponsables, ou simplement dirigs par des
   personnes incomptentes, a existe, il se trouve parfois qu'un utilisateur
   puisse se retrouver derrire un pare-feu qu'il peut traverser, mais ce ne
   sera pas trs commode. Ce petit guide fournit un moyen gnrique et
   portable de percer des tunnels dans des pare-feu, en transformant les
   rares petits bits qui arrivent au compte-gouttes en une vritable
   autoroute de l'information, de sorte que l'utilisateur puisse utiliser
   d'une faon cohrente des outils standards pour accder aux ordinateurs de
   l'autre ct du pare-feu. La mme technique peut tre utilise par les
   administrateurs rseaux comptents pour faire des rseaux privs virtuels
   (VPN [Virtual Private Networks]).

  Les problmes de scurit.

   Bien entendu si votre administrateur systme a install un pare-feu, il a
   srement une bonne raison et vous avez srement sign un engagement  ne
   pas le contourner. D'un autre ct, 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'extrieur du pare-feu (ce qui est
   une condition sine qua non pour que les mthodes prsentes puissent
   fonctionner) signifie que vous tes autoris  accder  des systmes
   externes, et le fait que vous puissiez ouvrir une session sur un systme
   externe particulier signifie que vous tes aussi autoris  le faire.

   Il s'agit donc ici tout simplement d'utiliser de faon commode les failles
   lgales d'un pare-feu, et d'autoriser les programmes gnriques 
   fonctionner  partir de l avec les protocoles gnriques, plutt que
   d'avoir recours  des programmes spciaux ou modifis (et recompils)
   passant par de nombreux proxies  usage particulier qui ont t mal
   configurs par un administrateur systme ngligent ou incomptent, ou
   d'installer de nombreux convertisseurs  usage particulier pour accder 
   chacun de vos services habituels (comme la messagerie lectronique) en
   passant par des chemins supports par le pare-feu (comme le web).

   De plus, l'utilisation d'un mulateur d'IP niveau utilisateur tel que
   SLiRP(TM) devrait permettre de maintenir la protection contre les attaques
   extrieures 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).

   L'un dans l'autre, la mthode prsente devrait tre relativement
   scurise. Cependant, a dpend des conditions particulires dans
   lesquelles vous faites l'installation, et je ne peux donner aucune
   garantie sur cette mthode. De nombreuses choses sont intrinsquement non
   scurises au niveau des connections internet, que ce soit avec cette
   mthode ou pas, donc n'imaginez surtout pas que telle ou telle chose est
   scurise  moins que vous n'ayez de bonnes raisons, et/ou utilisez un
   procd de chiffrage tout le temps.

   Rptons les bases de la scurit rseau : vous ne pouvez faire confiance
    rien du tout au niveau d'une connexion, pas plus que vous ne faites
   confiance aux htes qui peuvent manier les donnes non cryptes , y
   compris les htes des deux cts de la connection, et tous les htes qui
   peuvent intercepter la communication,  moins que la communication soit
   crypte correctement avec des clefs secrtes. Si vous placez mal votre
   confiance, vos mots de passe peuvent tre vols et utiliss contre vous,
   votre numro de carte de crdit 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.

   Pour rsumer, n'utilisez pas cette mthode sauf si vous savez ce que vous
   faites. Relisez l'avis de non-responsabilit plus haut.

  Autres conditions requises

   On suppose que vous savez ce que vous faites, que vous savez comment
   configurer une connexion au rseau, 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).

   On suppose que vous avez des comptes console des deux cts du pare-feu,
   que vous pouvez d'une faon ou d'une autre transmettre des paquets
   d'information dans les deux sens  travers le pare-feu (avec telnet, ssh,
   le courriel, et le web comme moyens les plus couramment utiliss pour
   travailler), et que vous pouvez laisser un dmon en fonctionnement comme
   tche en arrire-plan sur le serveur (ou bnficier d'un dmon existant,
   sshd, telnetd, ou sendmail/procmail).

   On suppose que vous savez ou que vous tes dispos  apprendre comment
   configurer un mulateur d'IP (pppd, slirp) ou un accs  internet dmon et
   la bibliothque qui va avec (SOCKS(TM), Term(TM)) des deux cts, en
   fonction de vos besoins en terme de connectivit et de vos droits d'accs,
   en recompilant certains logiciels si besoin est.

   Enfin, et c'est galement important, pour que vous puissiez utiliser les
   mthodes dcrites dans ce document, on suppose que vous tes root du ct
   du pare-feu qui a besoin d'un accs IP transparent complet vers l'autre
   ct. En effet, il vous faudra lancer le dmon PPP de ce ct, ce qui
   permet l'utilisation de l'installation normale de routage du paquet
   kernel. Au cas o vous n'tes pas root de ce ct, votre cas n'est pas
   dsespr malgr tout : en effet le Term-Firewall mini-HOWTO
   [http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html] de Barak
   Pearlmutter dcrit comment utiliser Term(TM), programme entirement fait
   pour l'utilisateur, en vue du perage de pare-feu. Bien qu'il n'y ait
   aucun petit guide, je souponne SOCKS(TM) de pouvoir galement tre
   utilis comme un moyen de percer les pare-feu sans avoir le privilge
   root; j'accepterai volontiers vos contributions  ce Guide pratique sur
   cette mthode pour percer les pare-feu.

  Logiciels  tlcharger

   La plupart des logiciels mentionns 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 .rpm et .deb Au cas vous voudriez
   rcuprer les dernires versions (aprs tout, un des deux bouts de la
   connexion peut ne pas fonctionner sous Linux), utilisez les adresses
   ci-dessous :

     * SLiRP se trouve sur http://blitzen.canberra.edu.au/slirp
       [http://blitzen.canberra.edu.au/slirp] ou sur
       [1]ftp://www.ibc.wustl.edu/pub/slirp_bin/.

     * zsh se trouve sur http://www.zsh.org/ [http://www.zsh.org/].

     * ppp se trouve sur [2]ftp://cs.anu.edu.au/pub/software/ppp/.

     * ssh se trouve sur http://www.openssh.com/ [http://www.openssh.com/].

     * fwprc, cotty et getroute.pl se trouvent sur
       http://fare.tunes.org/files/fwprc/
       [http://fare.tunes.org/files/fwprc/].

     * httptunnel se trouve sur http://www.nocrew.org/software/httptunnel/
       [http://www.nocrew.org/software/httptunnel/].

     * mailtunnel se trouve sur http://www.detached.net/mailtunnel/
       [http://www.detached.net/mailtunnel/].

Comprhension du problme

   Quand vous comprenez un problme, vous avez fait la moiti du chemin vers
   la solution.

  Donner un nom aux choses

   Si vous voulez que cette mthode fonctionne, vous devrez comprendre
   comment elle fonctionne pour que, si quelque chose ne marche pas, vous
   sachiez o chercher.

   La premire tape pour comprendre le problme est de donner un nom aux
   concepts appropris.

   Comme d'habitude, nous allons ci-aprs appeler  client  la machine qui
   dcide d'initialiser la connexion, ainsi que les programmes et les
   fichiers sur cette machine. Rciproquement, nous appelerons  serveur 
   celui qui attend les connexions et les accepte, ainsi que les programmes
   et fichiers sur cette machine. Le perage de pare-feu est utile lorsque
   les deux machines sont spares 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.

   Habituellement, lorsque l'on perce un pare-feu, le client est la machine
   derrire le pare-feu : il a un accs limit  internet, mais peut d'une
   faon ou d'une autre ouvrir une connexion ou une autre sur le serveur. Le
   serveur est une machine avec un accs complet  internet, qui va servir de
   proxy pour le client afin qu'il accde  internet. Dans un VPN, les rles
   peuvent tre inverss, avec le client tant sur internet et le serveur
   servant de proxy au client afin d'accder  certains rseaux privs.

  Le problme principal

   Le problme principal pour le perage de pare-feu est de crer un tunnel :
   une connexion continue d'une machine cliente vers une machine serveur de
   l'autre ct du pare-feu, qui permet un change bidirectionnel
   d'informations. Optionnellement, cette connexion devrait tre scurise.
   Le problme annexe est de transformer cette connexion en un accs IP
   complet pour une utilisation transparente par les programmes normaux.

   Pour le problme principal, nous considrerons que soit (1) vous pouvez
   tablir des connexions TCP/IP normales du ct 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 faon 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
   scurise dans le premier cas, vous pouvez bidouiller votre propre
   solution scurise 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 rmunration).

  Le problme annexe

   Pour le problme annexe, les mulateurs d'IP (pppd ou SLiRP(TM)) sont
   lancs de chaque ct du tunnel.

   Du ct qui veut un accs IP complet vers l'autre ct, il vous faudra
   lancer pppd. De l'autre ct, vous devez lancer pppd si vous voulez un
   accs IP complet dans l'autre sens, ou SLiRP(TM) si vous voulez empcher
   tout accs. Consultez votre documentation pppd ou SLiRP(TM) habituelle
   pour plus d'informations, si vous avez des besoins spcifiques qui ne sont
   pas traits dans les exemples ci-dessous.

   Bien qu'il s'agisse d'un concept banal, a ncessite nanmoins quelques
   astuces toutes btes afin de fonctionner, car (a) si vous utilisez une
   quelconque session shell programme interactive pour dmarrer l'mulateur
   d'IP du serveur de n'importe quel ct, il vous faut synchroniser
   correctement le dmarrage de l'mulateur d'IP de l'autre ct, afin de ne
   pas envoyer des salets dans la session shell, et (b) les mulateurs d'IP
   sont conus pour tre lancs sur une interface  tty  : vous devez donc
   convertir votre interface tunnel en une tty.

   Le point (a) ne reprsente rien de plus que le problme de synchronisation
   habituel, et n'existe mme pas si vous utilisez ssh, qui s'occupe de
   manire transparente du lancement de commande du serveur.

   Le point (b) requiert l'utilisation d'un simple utilitaire extrieur. Nous
   en avons fait un, cotty juste dans ce but.

   < PIQUAGE DE CRISE>

   Entre autres problmes dbiles ds  l'troitesse d'esprit des concepteurs
   de pppd (ceci n'est plus le cas dans les versions rcentes de Linux), on
   peut seulement le lancer soit par un dispositif dans /dev 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 pppd du serveur s'il y en a
   un, puisqu'il peut utiliser le tty des sessions telnet ou ssh; mais pour
   le pppd du client, cela entrane un conflit en cas d'utilisation de telnet
   pour tablir une connexion.

   En effet, telnet veut, galement, tre sur un tty, il se comporte presque
   correctement avec deux tunnels,  part qu'il insistera encore pour faire
   des iotctl au tty courant, avec lequel il va interfrer ; l'utilisation de
   telnet sans un tty impose galement un rgime tel que toute la connexion
   chouera sur des ordinateurs  lents  (fwprc 0.1 fonctionnait
   parfaitement sur un P/MMX 233, un dlai d'attente de 6 sur un 6x86-P200+,
   et aucun sur un 486dx2/66). L'un dans l'autre, lors de l'utilisation de
   telnet, vous avez besoin de cotty comme dmon pour copier la sortie d'un
   tty sur lequel fonctionne pppd sur un autre tty sur lequel fonctionne
   telnet, et inversement.

   Si je trouve l'abruti (probablement un gars de MULTICS(TM) bien que il a
   d y avoir des gens d'UNIX(TM) assez btes pour copier cette ide) qui a
   invent le principe des dispositifs  tty  grce auxquels on lit et on
   crit  partir d'un  mme  pseudo fichier, au lieu d'avoir des couples
   de tunnels propres, je l'trangle !

   </JE ME CALME>

La solution scurise : percer en utilisant ssh

  Principe

   Considrons que votre administrateur de pare-feu autorise les connexions
   TCP transparentes vers un port quelconque sur un serveur de l'autre ct
   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
   dbrouillez d'une faon ou d'une autre pour qu'un port quelconque d'un
   ct du pare-feu soit redirig vers un port de l'autre ct (en utilisant
   httptunnel, mailtunnel, un tunnel sur le telnet, ou autre).

   Vous pouvez alors lancer un sshd sur le port ct serveur, et vous y
   connecter avec un ssh sur le port ct client. Des deux cts de la
   connexion ssh vous lancez des mulateurs d'IP ( pppd), et l vous avez
   votre VPN, rseau priv virtuel, qui vite les restrictions stupides du
   pare-feu, avec un bonus en plus : la confidentialit grce au cryptage
   (faites attention, l'administrateur du pare-feu connat tout de mme
   l'autre bout du tunnel, et toute information d'authentification quelle
   qu'elle soit que vous pouvez avoir envoye avant de lancer le ssh).

   Exactement la mme technologie peut tre utilise pour construire un VPN,
   rseau priv virtuel, qui permet de regrouper de faon scurise des sites
   physiques en un seul rseau logique sans sacrifier la scurit au niveau
   du rseau de transport entre les sites.

  Exemple de session

   Ci-dessous se trouve un exemple de script que vous pouvez adapter  vos
   besoins. Il utilise le systme de range de zsh, mais vous pouvez
   l'adapter facilement  votre shell favori. Utilisez l'option -p pour que
   ssh essaie un autre port que le port 22 (mais  ce moment-l, veillez 
   bien lancer sshd sur le mme port).

   Notez que le script suppose que ssh peut s'ouvrir sans que vous ayez 
   taper interactivement votre mot de passe (en effet, son tty de contrle
   sera connect  pppd, alors s'il vous demande un mot de passe, c'est
   rat). Ceci peut se faire soit avec les clefs ssh dans votre
   ~/.ssh/authorized_keys pour lesquelles un mot de passe n'est pas
   ncessaire, ou que l'on peut dbloquer en utilisant ssh-agent ou
   ssh-askpass. 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 assurment pas la chose  faire.

   Si vous n'tes pas root ou simplement si vous voulez protger le rseau de
   votre client des connexions sortantes, vous pouvez utiliser slirp au lieu
   de pppd comme mulateur PPP du serveur. Il n'y a qu' dcommenter la ligne
   approprie.


 #!/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 dcommentez les lignes suivantes:
         # updetach debug
         ### Une autre option potentiellement utile (allez voir la section sur le routage)&nbsp;:
         # defaultroute
 )
 $CLIENT_PPPD pty "ssh -t $SERVER_ACCOUNT $SERVER_PPPD"


   Notez que les options par dfaut de votre /etc/ppp/options ou ~/.slirprc
   peuvent casser ce script, enlevez donc toute option non dsire.

   Notez galement que 10.0.2.2 est le paramtrage par dfaut pour slirp, ce
   qui peut ne pas fonctionner avec votre installation particulire. En tout
   cas, vous devriez de prfrence utiliser une adresse dans l'une des
   catgories rserves par la RFC-1918 pour les rseaux privs : 10.0.0.0/8,
   172.16.0.0/12 ou 192.168.0.0/16. Il se pourrait que le rseau local
   protg 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 approprie.

   Si le pppd de votre client est vieux ou non-linux (par exemple BSD) et n'a
   pas d'option pty, utilisez :

 cotty -d -- $CLIENT_PPPD -- ssh -t $SERVER_ACCOUNT $SERVER_PPPD

   Piges : ne mettez pas les commandes donnes  cotty entre guillemets, car
   elles s'excutent exec()telles quel, et n'oubliez pas de spcifier le
   chemin complet pour le pppd du serveur s'il n'est pas dans le chemin
   standard install par ssh.

   On laisse au lecteur la reconnexion automatique (conseil : l'option
   nodetach de pppd pourrait tre utile pour a).

La solution non scurise : percer en utilisant telnet

  Principe

   Si vous ne pouvez faire que du telnet ( cause d'un proxy telnet), cette
   solution pourrait bien vous convenir.

   Le programme de perage de pare-feu, fwprc, utilisera un proxy tty, cotty,
   qui ouvre deux dispositifs pseudo-tty, lance des commandes sur chacun des
   esclaves de ces dispositifs, et copie systmatiquement chaque caractre
   que l'on sort sur le tty qui sert d'entre pour l'autre commande. Une
   commande sera une connexion telnet vers le site serveur, et l'autre sera
   le pppd. pppd peut alors ouvrir et contrler la session telnet avec un
   script de chat comme d'habitude.

   En fait, si votre proxy telnet permet une connexion vers un port
   arbitraire, et si vous pouvez lancer un dmon de manire sre sur l'hte
   serveur (avec relance planifie [cron] en cas de plantage), vous feriez
   mieux d'crire un programme qui connectera juste un port ct client au
   port ct serveur par le proxy, afin de pouvoir utiliser la solution
   scurise ci-dessus, en utilisant ventuellement une variante de

 ssh -t -o "ProxyCommand ..."

   (Soumettez moi une solution et je l'intgrerai volontiers  la
   distribution fwprc).

   Remarque : si vous devez utiliser la solution non scurise base 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 porte, un systme ne
   demandant le mot de passe qu'une seule fois, ou un systme de
   cryptographie explicite augmentera votre scurit, ce qui, toutefois,
   rendra les scripts de connexion automatique bien plus complexes.

  fwprc

   J'ai crit un script qui dcrit de faon trs dtaille comment percer les
   pare-feu, fwprc, disponible sur mon site
   [http://fare.tunes.org/files/fwprc/], avec galement cotty (qui est requis
    partir de la version 0.2 de fwprc). Au moment o j'ai crit ces lignes,
   la version la plus avance de fwprc est 0.3e et pour cotty 0.4c.

   Le nom  fwprc  est volontairement illisible et imprononable, afin
   d'embrouiller votre administrateur systme incomptent et paranoaque sans
   doute responsable de ce pare-feu qui vous casse les pieds (bien sr il
   peut y avoir des pare-feu lgitimes galement, et parfois mme, ils sont
   indispensables ; la scurit n'est qu'un problme de configuration
   correcte). Si vous devez le lire  voix haute, prononcez le de la pire
   faon possible et imaginable.

   GRAND CONCOURS ! Envoyez moi un fichier audio avec un enregistrement audio
   numrique 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 fwprc 1.0!

   J'ai test le programme sur diffrentes configurations, en le configurant
   avec des fichiers ressources. Mais bien entendu, selon la loi de
   l'emmerdement maximum, a plantera pour vous. N'hsitez pas  proposer les
   amliorations qui faciliteront la vie de ceux qui configureront aprs
   vous.

  .fwprcrc

   fwprc peut tre personnalis grce au fichier .fwprcrc fait pour tre le
   mme des deux cts du pare-feu. Avoir plusieurs configurations de
   rechange parmi lesquelles choisir est certes possible (par exemple, moi je
   le fais), et on laisse a comme exercice pour le lecteur.

   Pour commencer, copiez la section approprie de fwprc (l'avant-dernire)
   dans un fichier nomm .fwprcrc dans votre rpertoire home. Remplacez
   ensuite les valeurs des variables par des trucs qui correspondent  votre
   configuration. Enfin, copiez le sur l'autre hte et testez.

   Le comportement par dfaut est d'utiliser pppd sur le client, et slirp sur
   le serveur. Pour modifier ceci, vous pouvez redfinir la fonction
   approprie dans votre .fwprcrc avec une ligne telle que :

 remote_IP_emu () { remote_pppd }

   Notez que SLiRP(TM) est plus sr que pppd, et plus facile d'accs,
   puisqu'il ne requiert pas d'tre root sur la machine serveur, et n'a pas
   besoin d'une configuration supplmentaire du pare-feu pour empcher les
   connexions du monde extrieur sur le rseau derrire un pare-feu. La
   fonctionnalit de base dans SLiRP(TM) fonctionne plutt bien, mais je n'ai
   pas russi  faire marcher certains des plus qu'il est cens proposer (tel
   que le contrle du temps d'excution). Bien entendu, puisqu'il s'agit d'un
   logiciel libre, n'hsitez pas  aller dans la source pour carrment
   implmenter ou rparer n'importe quel dispositif dont vous aurez besoin.

Routage

   Il ne suffit pas de percer le pare-feu. Il faut galement router les
   paquets du ct client du pare-feu vers le ct serveur. Dans cette
   section, j'aborde les paramtres de base spcifiques au routage  travers
   un tunnel. Pour plus d'explications dtailles sur le routage, lisez les
   guides pratiques correspondants et les pages de manuel sur les rseaux, le
   routage et l'usurpation d'identit.

  Il y a un truc

   Le truc, c'est que, mme si votre administrateur rseau vous demandait
   d'installer un routeur de votre ct client comme route par dfaut, (ceci
   peut tre utile si on veut une route spcifique vers les rseaux sur le
   client du pare-feu), il faudra installer PPP link comme route vers les
   rseaux sur le ct serveur.

   En d'autres termes, votre route par dfaut devrait pointer vers un routeur
   de n'importe quel ct du tunnel qui vous donne accs  internet.

   Ce qui est primordial, c'est que les paquets envoys au serveur hte en
   tant qu'lment de fonctionnement du tunnel doivent tre routs  travers
   votre rseau habituel (par exemple votre routeur ethernet par dfaut),
   autrement, votre kernel aura des problmes, vu qu'il essaie de router 
   l'intrieur du tunnel les paquets qui, prcisment, devraient constituer
   l'extrieur du tunnel.

   Ainsi donc, vous devrez paramtrer correctement les routes dans votre
   configuration de dmarrage du rseau. L'emplacement prcis de vos donnes
   de configuration de routage dpend de votre distribution, mais c'est
   gnralement sous /etc/init.d/network ou /etc/network/; de mme, votre
   configuration PPP se trouve gnralement dans /etc/ppp/, et l'endroit
   normal pour configurer ces routes se trouve habituellement dans ip-up ou
   ip-up.d/. (Astuce : pour identifier les emplacements de fichier
   spcifiques  votre distribution, vous devez lire la documentation de
   votre distribution ou encore RTFM
   [http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?RTFM]; sinon, utilisez grep
   rcursivement dans votre /etc; au pire, reprez ce qui se passe au moment
   du dmarrage, comme configur dans votre /etc/inittab.)

   Lorsque vous percez un tunnel dans un rseau protg  partir d'un
   portable sur internet, le script getroute.pl (disponible sur la
   distribution fwprc) donne la route utilise vers le serveur hte qui
   reprsente l'autre bout du tunnel.

   Une fois que vous pouvez router les paquets vers le ct serveur du
   tunnel, a vous intressera peut-tre de configurer votre machine comme
   routeur pour tous vos copains du ct client du pare-feu ; vous aurez
   ainsi ralis un vritable VPN partag. Ceci n'est pas spcifique au
   perage de pare-feu, alors lisez donc les guides pratiques correspondants
   sur les rseaux, le routage et l'usurpation d'identit. Egalement, pour
   des raisons de scurit, veillez  bien installer un bon pare-feu sur
   votre machine, surtout si vous devez tre routeur pour d'autres personnes.

   Enfin, souvenez vous que si vous utilisez pppd sur le ct serveur du
   tunnel (par opposition au mode utilisateur slirp), vous devrez galement
   configurer les routes qu'il faut et des rgles de pare-feu du ct serveur
   du tunnel.

  Exemple de routage

   Dans cet exemple, votre machine cliente est connecte  un rseau local
   avec pare-feu grce au dispositif ethernet eth0. Son adresse IP est
   12.34.56.78; son rseau est 12.34.56.0/24; son routeur est 12.34.56.1.

   Votre administrateur rseau peut vous avoir dit d'utiliser 12.34.56.1
   comme routeur par dfaut, mais n'en tenez pas compte. Vous devez seulement
   l'utiliser comme route vers le ct client du pare-feu.

   Supposons que le ct client du pare-feu est compos des rseaux
   12.34.0.0/16 et 12.13.0.0/16, et de l'hte 11.22.33.44. Pour les rendre
   accessibles par votre routeur client, ajoutez ces routes au script de
   dmarrage de votre rseau global :

 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

   Vous devez galement garder la route vers le rseau local du client,
   ncessaire pour le kernel 2.0 de Linux , mais pas pour le kernel 2.2 et
   suivants de Linux (ceci l'ajoute implicitement pendant le ifconfig):

 route add -net 12.34.56.0 netmask 255.255.255.0 dev eth0

   Par contre, vous devez imprativement enlever toute route par dfaut de
   vos scripts. Supprimez ou mettez en commentaire une ligne telle que :

 route add default gw 12.34.56.1

   Remarquez qu'il est galement possible d'enlever la route de la
   configuration du kernel en marche sans redmarrer, grce  la commande
   suivante :

 route del default gw 12.34.56.1

   Vous pouvez ensuite obtenir de pppd l'installation automatique d'une route
   par dfaut lorsqu'il dmarre en utilisant son option defaultroute Sinon,
   vous pouvez l'ajouter plus tard :

 route add default gw 10.0.2.2

   Si vous ne voulez pas de pppd comme route par dfaut, parce que l'accs
   internet est disponible de votre ct du pare-feu, et si vous voulez
   plutt que le rseau 98.76.48.0/20 soit rout par le tunnel, sauf au
   dpart de l'hte 98.76.54.32 qui reprsente l'autre bout du tunnel,
   ajoutez les lignes suivantes  votre /etc/ppp/ip-up:

 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

   Si vous tes sur un portable et que vous changez de rseau local, mais que
   vous voulez quand mme garder votre route actuelle vers 98.76.54.32,
   utilisez getroute.pl comme suit pour trouver automatiquement la bonne
   passerelle dans la commande route add -host :

 $(getroute.pl 98.76.54.32)

   Remarquez que si vous les avez dans votre /etc/hosts, vous pouvez utiliser
   des noms symboliques au lieu des adresses IP numriques (et vous pouvez
   mme utiliser des FQDN, si vous pensez que le DNS ne plante jamais).

Perage inverse

  La logique

   Des fois, seul un ct du pare-feu peut lancer des sessions telnet vers
   l'autre ct, cependant, un moyen de communication est possible (en
   gnral par le courrier lectronique). Percer un pare-feu est toujours
   possible, en dclenchant, grce  n'importe quel moyen de transmission de
   messages disponible, une connexion telnet du  bon  ct du pare-feu vers
   l'autre ct.

   fwprc inclut du code pour dclencher de telles connexions  partir d'un
   courriel authentifi par OpenPGP ; il suffit d'ajouter fwprc comme filtre
   procmail aux messages utilisant ce protocole (instructions contenues dans
   fwprc lui-mme). Remarquez cependant que si vous devez lancer pppd avec
   les privilges appropris, il vous faudra peut-tre crer votre propre
   suid wrapper pour devenir root. Instructions incluses dans fwprc.

   En outre, dclenchement authentifi ne signifie absolument pas connexion
   scurise. Il faut vraiment utiliser ssh (peut tre en plus de telnet)
   pour des connexions scurises. Et puis mfiez vous de ce qui se passe
   entre le dclenchement d'une connexion telnet, et le moment ou ssh prend
   en main cette connexion. Toute contribution  ce sujet sera la bienvenue.

  Obtenir le message de dclenchement

   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 problme! Vous pouvez lancer
   fetchmail en mode dmon (ou comme tche cron) pour interroger votre
   serveur de messagerie et distribuer le courrier  votre systme linux qui,
   lui-mme, aura t configur pour utiliser procmail  la rception.
   Remarquez que si vous lancez fetchmail comme dmon en arrire plan, il
   bloquera tout autre fetchmail que vous voudriez simplement lancer 
   d'autres moments, comme lorsque vous ouvrez un fwprc; bien entendu, si
   c'est possible, lancez galement un dmon fetchmail en tant qu'utilisateur
   bidon. Des scrutations trop frquentes ne seront pas bonnes pour le
   serveur de messagerie ou pour l'hte. Si elles sont trop peu frquentes,
   vous devrez attendre avant que le message ne soit lu et que la connexion
   inverse soit tablie. J'utilise une frquence de scrutation de deux
   minutes.

  Autres outils automatiques pour le perage inverse

   Un autre moyen d'interroger un serveur pour voir les messages, quand on
   n'a pas de bote de messagerie, mais qu'on a bien un accs FTP vers
   l'extrieur, est d'utiliser un tunnel FTP
   [http://dhirajbhuyan.hypermart.net/ftp-tunnel.html].

   Comme outil pour maintenir une connexion permanente entre un hte sous
   pare-feu et un proxy externe, afin d'exporter des services depuis l'hte
   vers l'extrieur, il y a le tunnel pare-feu
   [http://www.employees.org/~hek2000/projects/firewallTunnel/].

Remarques finales

  Autres rglages

   Je n'ai aucune ide sur la manire de percer des pare-feu avec des
   systmes d'exploitation de niveau infrieur, 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 infrieur. Lisez les guides pratiques
   correspondants sur le routage, l'acheminement IP, NAT, etc.

   Je ne connais pas les dtails, mais il existe un outil prometteur pour
   percer les pare-feu  : le Bouncer [http://www.r00t3d.org.uk/] de Chris
   Mason, qui joue le rle de proxy SOCKS par-dessus SSL.

   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.

   Cela peut tre trs facile : ainsi, on a remarqu qu'il suffit de lancer
   ssh sur un matre pty et faire du pppd sur l'esclave tty. Si on le
   souhaite, on peut mme le faire sans qu'il soit question de pare-feu,
   juste pour construire un VPN scuris (Virtual Private Network). Le VPN
   mini-HOWTO [http://www.linuxdoc.org/HOWTO/mini/VPN.html] donne tous les
   dtails ncessaires  ce sujet. Comme exercice, nous vous invitons, 
   modifier fwprc pour utiliser cette technique, ou peut-tre mme pour
   l'utiliser  l'intrieur d'une prcdente session fwprc non scurise.

   Maintenant si le seul chemin  travers le pare-feu est un proxy WWW (ce
   qui est habituellement un minimum pour un rseau connect  internet), on
   pourra utiliser le script ssh-https-tunnel
   [http://www.snurgle.org/~griffon/ssh-https-tunnel] de Chris Chiappa
   [http://www.snurgle.org/~griffon/].

   Autre programme prometteur pour percer  travers http  : le httptunnel
   [http://www.nocrew.org/software/httptunnel/] de Lars Brinkoff
   [http://lars.nocrew.org/], une combinaison serveur et client http
   permettant une connexion TCP/IP par tunnel grce au protocole http. On
   devrait ensuite pouvoir lancer fwprc (de prfrence par-dessus ssh) sur
   cette connexion, bien que je n'aie pas encore essay. Quelqu'un
   pourrait-il tester et faire un rapport ? Remarquez que httptunnel est
   toujours en cours de dveloppement, vous pouvez donc aider  implmenter
   les fonctionnalits qui lui manquent actuellement, telles que les
   connexions multiples, et/ou servir des pages bidon pour leurrer les
   administrateurs mfiants de pare-feu excessivement hermtiques.

   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 requtes DNS, les paquets ICMP, le courrier lectronique (lisez
   mailtunnel [http://www.detached.net/mailtunnel/], icmptunnel
   [http://www.detached.net/icmptunnel/]), ou que sais-je encore, vous pouvez
   toujours crire une combinaison tunnel client/serveur, et lancer un ssh
   et/ou une connexion PPP  travers celui-ci. La performance pourrait ne pas
   tre trs bonne, en fonction de la vitesse effective de communication de
   l'information aprs avoir pay les charges des au codage de l'ensemble
   des filtres et proxies, mais un tel tunnel est toujours intressant tant
   qu'il peut au moins servir  utiliser fetchmail, suck, et autres
   programmes non interactifs.

   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
   ncessaire, rabattez vous sur le Term-Firewall mini-HOWTO
   [http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html].

   Si vous avez une connexion 8 bits propre et que vous tes root sur linux
   des deux cts 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
   [3]ftp://quatramaran.ens.fr/pub/madore/misc/. Il reste  traiter de
   ethertap-sur-tty pour combiner avec des outils comme fwprc.

   Si vous cherchez une performance suprieure  celle obtenue en payant un
   tunnel  communication squentielle, niveau espace utilisateur,  travers
   lequel lancer PPP, vous tes dans la situation trs difficile o vous
   devrez rebidouiller une drle 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 
   implmenter.

   Pour finir, si vous n'tes pas en train de vous battre contre un pare-feu
   excessivement hermtique, mais que vous faites juste votre propre VPN, il
   y a un large ventail d'outils VPN, et bien que les trucs que je prsente
   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.

  Le suivi de ce petit guide

   J'ai pens qu'il tait ncessaire de l'assurer, mais je n'ai pas beaucoup
   de temps pour a, donc ce petit guide est trs sommaire. Il va donc rester
   ainsi jusqu' ce que j'obtienne assez de retours d'information pour savoir
   quelle section amliorer, 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.

   En tout cas, les sections ci-dessus montrent que de nombreux problmes
   peuvent tre facilement rsolus 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
   dtail, cela puisse ne pas tre simple ou vident.

   N'hsitez pas  proposer d'autres problmes, et, esprons-le, d'autres
   solutions, pour ce petit guide.

  Documents sur le sujet

   Le LDP [http://www.linuxdoc.org/] publie de nombreux documents en rapport
   avec ce petit guide [http://www.linuxdoc.org/HOWTO/HOWTO-INDEX/mini.html].
   tout particulirement Linux Security Knowledge Base
   [http://www.securityportal.com/lskb/], le HOWTO VPN
   [http://www.linuxdoc.org/HOWTO/VPN.html] et le petit guide VPN
   [http://www.linuxdoc.org/HOWTO/mini/VPN.html]. Pour des questions plus
   gnrales sur le rseau, le routage et les pare-feu, commencez avec le
   Networking Overview HOWTO
   [http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html]. Regardez
   galement le Linux Firewall and Security site
   [http://www.linux-firewall-tools.com/linux/].

   L encore, lorsque vous rencontrez un problme avec un programme, le
   rflexe pour tout utilisateur de Linux devrait tre de Lire le Pstain
   [sic] de Manuel [RTFM : Read The Fscking Manual]
   [http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?RTFM] sur les programmes en
   question.

  Le mot de la fin

   Je suis arriv  la conclusion que, de la mme faon que le besoin en
   Design Patterns venait directement du fait que les gens utilisaient des
   langages infrieurs tels que le C++(TM) ou le Java(TM) qui ne permettent
   pas d'exprimer directement des constructions de programmation de plus haut
   niveau (alors que de bons langages tels que le LISP(TM) permettent de les
   exprimer), on peut dire que le besoin en guides pratiques vient
   directement du fait que les systmes Linux(TM) et UNIX(TM) sont des
   systmes d'exploitation infrieurs qui ne permettent pas d'exprimer
   directement les tches que les gens essayent de faire avec, qui sont
   pourtant simples.

   Si vous pensez que tout ce bidouillage de scripts stupides et de guides
   pratiques idiots est trop compliqu et qu'un systme d'ordinateur
   convenable devrait nous automatiser tout a, alors bienvenu au club des
   allergiques comme moi  UNIX (UNIX haters
   [http://www.research.microsoft.com/~daniel/preface.html]) et de ceux qui
   dtestent les systmes de bas niveau actuels, et aspirent  des systmes
   informatiques dclaratifs qui prennent en charge tous les dtails sans
   intrt et nous laissent nous concentrer sur les choses importantes (jetez
   un il, si a vous dit,  mon propre projet TUNES [http://tunes.org/]).

  Copie supplmentaire de l'avis trs important de non responsabilit -- croyez
  le !!!

     Par la prsente je dcline toute responsabilit quant  l'utilisation
   que vous ferez de cette mthode d'effraction [hack]. Si a se retourne
   contre vous d'une manire 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 mthode et qu'elle permet  des vandales
   sans scrupules de pntrer dans les ordinateurs de votre socit et que a
   vous cote votre boulot et des millions d'euros  votre entreprise, eh
   bien c'est pas de pot. Ne venez pas pleurer chez moi.  

