Firewall Piercing mini-HOWTO <author>François-René Rideau, <tt>fare@tunes.org</tt> <date>v0.4+, 27 Mars 1999 <abstract> Instructions pour mettre en oeuvre ppp par dessus telnet, de façon à utiliser de manière transparente les services de l'Internet à travers un pare-feu. </abstract> <toc> <sect>Machins <sect1>AVERTISSEMENT <bf>LISEZ BIEN CET AVIS IMPORTANT !!!</bf> <bf> Je rejette toute responsabilité sur l'utilisation des astuces présentées. Si vous vous plantez en tentant de les mettre en oeuvre, c'est votre affaire, pas la mienne. Si vous ne comprenez pas les risques inhérents à l'utilisation de ces astuces, alors ne les utilisez pas. Si vous les utilisez, et qu'elles permettent à des méchants pas beaux de pénétrer dans les ordinateurs de votre entreprise, et que cela vous coûte votre emploi, et coûte à votre entreprise des millions de francs, c'est vraiment trop bête, mais ne venez pas vous plaindre à moi en pleurnichant. </bf> <sect1>Prose légale Copyright © 1998,1999 François-René Rideau. Ce document est un logiciel libre; vous pouvez le redistribuer et/ou le modifier selon les termes de la GNU General Public License telle que publiée par la Free Software Foundation, version 2 ou ultérieure. <sect1>Notes sur la version française La version française de ce texte est réalisée par l'auteur en même temps que la version anglaise. Aucune des deux n'est à proprement parler la traduction de l'autre, quoique chacune l'est dans une certaine mesure. Toutes deux forment la ``version originale''. <sect1>Remerciements Bien que j'ai réécrit la quasi-totalité de son texte, et que le reste a disparu lors de l'adaptation française, je dois remercier <URL URL="mailto:bap@cs.unm.edu" name="Barak Pearlmutter"> pour son Term-Firewall mini-HOWTO: je pense qu'il y avait le besoin d'un mini-HOWTO à propos du percement des pare-feu, et malgré ses défauts, son mini-HOWTO a été pour moi un modèle et un encouragement. J'aimerais aussi remercier <URL URL="mailto:lars@nocrew.org" name="Lars Brinkhoff">  et <URL URL="mailto:logic@gore.nocrew.org" name="Magnus Lundström"> pour leurs excellents tunnels http et mail. <sect>Introduction <sect1>Avant-Propos Parce que les administrateurs systèmes et les utilisateurs ont des contraintes et des compétences différentes, l'utilisateur se trouve trop souvent derrière un pare-feu (``firewall'' en anglais), qu'il peut traverser, mais seulement de manière maladroite. Ce mini-HOWTO décrit une façon générique et portable d'utiliser les outils standards de l'Internet à travers de tels pare-feux, par la mise en oeuvre d'un émulateur IP à travers un tunnel obtenu par une connexion telnet, http, ou mail! Il est librement inspiré du Term-Firewall mini-HOWTO de <URL URL="mailto:bap@cs.unm.edu" name="Barak Pearlmutter">, qui reposait sur l'utilisation d'un programme antique et plus supporté nommé Term (un programme grandiose à son époque, et toujours utile dans certaines circonstances malheureuses), aussi bien que celle d'une implantation très particulière et non standard de telnet (ztelnet?) c'est-à-dire, sur de nombreux faits obsolètes et non-portables. <sect1>Problèmes de sécurité Bien sûr, si votre administrateur a dressé un pare-feu, il ou elle peut avoir d'excellentes raisons, et il se peut que vous ayez signé un accord pour ne pas le contourner. D'un autre côté, le fait que vous avez le droit d'utiliser telnet, la toile, le courrier électronique, ou tout autre flux d'information bidirectionnel avec l'extérieur du pare-feu (ce qui est une des conditions nécessaires de mise en oeuvre des astuces ici présentées) signifie que vous avez le droit d'accéder à des systèmes externes, et le fait que vous puissiez vous connecter sur un système externe particulier signifie aussi que vous en ayiez le droit. Ainsi, le problème est celui d'exploiter de manière agréable les ouvertures légales existant dans un pare-feu, et de permettre à des programmes génériques de fonctionner depuis l'intérieur avec des protocoles génériques, plutôt que de devoir utiliser des programmes spéciaux, ou modifiés (et recompilés) qui passeront par des tas de serveurs tampons (``proxy'' en anglais) particuliers qui seront mal configurés par des administrateurs qui ont autre chose à faire, ou qui sont incompétents, ou plutôt que d'installer des tas de filtres à usage unique, pour accéder à chacun de vos services habituels (comme le couriel), à travers les moyens autorisés par le pare-feu (comme la toile). De plus, l'utilisation d'un émulateur IP au niveau utilisateur, comme SLiRP, devrait empêcher les aggresseurs externes de percer le pare-feu en chemin inverse, à moins que ce ne soit expressément permis par vous (ou qu'ils ne soient très malins et malicieux, et soient administrateurs sur l'hôte distant du telnet). L'un dans l'autre, l'astuce présentée devrait être relativement sûre. Cependant, tout cela dépend des circonstances particulières de votre configuration, et je ne peux fournir aucune garantie à ce sujet. De nombreuses choses sont intrinsèquement fragiles dans les connexions sur l'Internet, que ce soit avec ou sans cette astuce; aussi, ne supposez jamais que quoi que ce soit soit sûr à moins d'avoir de bonnes raisons, et/ou que vous utilisiez de l'encryptage tout au long des connexions. Pour tout résumer, n'utilisez pas cette astuce, à moins de savoir ce que vous faites. Relisez l'avertissement ci-dessus. <sect1>Autres prérequis Je supposerai que vous savez ce que vous faites, que vous savez mettre en oeuvre une connexion réseau, qu'en cas de difficulté, vous aurez lu toute la documentation pertinente (HOWTOs, pages de manuel, pages ouèbes, archives de mailing-list, RFCs, cours, tutoriels). Je supposerai que vous avez un compte avec interpréteur de commande de part et d'autre du pare-feu, que vous disposez d'un moyen de transmettre des informations de manières bidirectionnelles entre ceux deux comptes (moyens actuellement reconnus, ssh, telnet, courrier électronique, web), et que vous pouvez laisser tourner un démon en tâche de fond sur le site distant (ou profiter d'un démon sshd, telnetd, ou sendmail/procmail existant). Je supposerai que vous saurez configurer un émulateur IP (pppd, slirp) ou un démon d'accès et sa bibliothèque associée (SOCKS, Term) de chaque côté, en fonction de vos besoins en connectivité, et de vos droits d'accès, quitte à recompiler certains programmes si nécessaire. <sect1>Télécharger les logiciels La plupart des logiciels nommés devraient être disponibles dans distributions Linux standard, éventuellement parmi les "contrib". Tout au moins, les quatre premiers ci-dessous sont disponibles comme paquetages rpm. Au cas où vous voudriez télécharger les sources les plus récents (après tout, l'une des deux extrêmités de la connexion peut fort bien ne pas tourner sous Linux), vous pouvez utiliser les adresses ci-dessous: <itemize> <item><tt>SLiRP</tt> se trouve à l'adresse <URL URL="http://blitzen.canberra.edu.au/slirp"> et/ou <URL URL="ftp://www.ibc.wustl.edu/pub/slirp_bin/">. <item><tt>zsh</tt> se trouve à l'adresse <URL URL="http://www.peak.org/zsh/">. <item><tt>ppp</tt> se trouve à l'adresse <URL URL="ftp://cs.anu.edu.au/pub/software/ppp/">. <item><tt>ssh</tt> se trouve à l'adresse <URL URL="ftp://ftp.cs.hut.fi/pub/ssh/">.  <item><tt>fwprc</tt> et <tt>cotty</tt> se trouvent à l'adresse <URL URL="http://www.tunes.org/~fare/files/fwprc/">.  <item><tt>httptunnel</tt> se trouve à l'adresse <URL URL="http://www.nocrew.org/software/httptunnel.html">. <item><tt>mailtunnel</tt> se trouve à l'adresse <URL URL="http://www.detached.net/mailtunnel.html">.  </itemize> <sect>Comprendre le problème Comprendre un problème est la première moitié du chemin à parcourir pour le résoudre. <sect1>Donner un nom aux choses Si vous voulez que cette astuce fonctionne pour vous, vous devez comprendre son principe général, de façon à savoir où regarder quand il y aura une panne. La première étape pour comprendre le problème est de donner un nom aux concepts pertinents. Nous appelerons ici "locaux" la machine qui initie la connexion, aussi bien que les programmes et les fichiers sur cette machine; réciproquement, nous appelerons "distant" ce qui se passera de l'autre côté de la connexion. De se point de vue, l'utilisateur humain pourra aussi bien se trouver du côté "local" que "distant". Nous appelerons ici "clients" les programmes qui voudront accéder aux données situées de l'autre côté du pare-feu par des protocoles standards de l'Internet. Selon vos besoins, vous voudrez faire tourner des clients locaux, distants, ou les deux. <sect1>Le problème Le but du problème est de fournir à des clients d'un côté du pare-feu un accès TCP/IP complet aux services situés de l'autre côté. Nous pouvons factoriser le problème en plusieurs étapes: <itemize> <item> Premièrement, assurer une flux continu bidirectionnel stable de paquets d'information entre les deux côtés du pare-feu, sous forme d'une connection TCP/IP, "tunnel" creusé à travers le pare-feu. C'est là le percement du pare-feu proprement dit, et l'étape la plus délicate. Dans le meilleur des cas, une liaison ssh pourra être établie directement dans un sens, et servira de tunnel. Sinon, il faudra utiliser telnet, httptunnel, ou mailtunnel (par ordre de préférence, selon les services disponibles). <item> Deuxièmement, il faut faire passer à travers cette unique connexion tunnel toutes les connexions TCP/IP issues des clients, grâce à un émulateur IP, typiquement pppd ou SLiRP, ou un autre système (SOCKS ou Term). C'est là un sujet déjà connu, pour lequel foisonne une abondante documentation, quoique non généralement adapté à l'usage considéré. <item> Troisièmement, et optionnellement, router par cette voie tout le trafic à destination de l'autre côté du mur. C'est là un sujet dont nous ne traiterons pas, car une fois la deuxième étape réussie, il n'y a plus rien de spécifique à la situation considérée. Nous vous renvoyons pour cela au NET3-HOWTO et au IP-Masquerade-HOWTO. <item> Quatrièmement, il faut s'assurer que les paquets en direction de l'entrée du tunnel sont routés correctement, et ceci même si cette entrée est dans la zone IP que l'on redirige à travers le tunnel (ceci est particulièrement vrai quand on utilise un tunnel direct plutôt qu'un tunnel à travers un proxy). <item> Enfin, pour rendre la liaison plus robuste ou plus flexible, dans le cas où elle doit être initiée du côté où l'utilisateur est physiquement absent, ou dans le cas où l'un des côtés de la liaison est mobile, il est possible de la monitorer depuis une crontab, ou de la déclencher depuis le courrier avec une règle procmail. Nous donnons quelques indications à cet escient. </itemize> Or, les canaux de communication par lesquels les émulateurs IP interagissent sont ou bien directement des périphériques (le cas habituel avec <tt>pppd</tt>), ou bien le "terminal courant". Les sessions telnet n'entrent jamais dans le premier cas. Le second cas est difficile, parce que quand on lance l'émulateur local depuis la ligne de commande, le "terminal courant" est relié à l'utilisateur, et non pas à une session distante; et si on ouvre une session locale ou distante sur un nouveau terminal, on doit synchroniser le lancement et la connexion des émulateurs IP, à moins que les rejets émis par une session ne soient exécutées comme des commandes par l'autre session, produisant récursivement de nouveaux rejets. <sect1>Difficultés supplémentaires Pour un meilleur confort d'utilisation, l'émulateur IP local doit se connecter à l'interface IP du noyau; ce doit donc être <tt>pppd</tt>. Cependant, <tt>pppd</tt> est si stupide qu'il n'accepte des données qu'à travers un périphérique dans /dev, ou à travers le terminal courant; et ce doit être un terminal ("tty"), et non pas une paire de tuyaux ("pipe"), ce qui serait pourtant la façon évidente de bien concevoir la chose. Tout va bien dans le cas d'un <tt>pppd</tt> distant, s'il y en a, puisqu'il utilisera le terminal courant de la session telnet. Mais pour le <tt>pppd</tt> local, rien ne va plus, car il ne peut pas lancer de session telnet pour se connecter. Aussi, il doit y avoir un programme pour emballer la partie locale de la connexion. Telnet se comporte presque correctement avec une paire de tuyaux, à part qu'il insiste pour faire des ioctl sur le terminal courant, avec lequel il interférera donc; utiliser telnet sans un terminal courant cause aussi des conditions de course, telles que la connexion échouera sur des ordinateurs ``lents'' (fwprc 0.1 fonctionnait parfaitement sur un P/MMX 233, une fois sur six sur un 6x86-P200+, et jamais sur un 486dx2/66). [Note: si je trouve l'imbécile (probablement un type de MULTICS, bien qu'il y ait dû y avoir un autre imbécile pour copier l'idée sous UNIX) qui a inventé le principe des périphériques "tty" par lesquels on lit et on écrit depuis un "même" pseudo-fichier, plutôt que d'avoir une paire de tuyaux bien propre, je l'étrangle!] <sect>La solution <sect1>Principe Le programme pour percer les pare-feux, <tt>fwprc</tt>, utilisera un "proxy de terminaux", <tt>cotty</tt>, qui ouvrira deux périphériques de pseudo-terminaux, lancera une commande sur chacun des terminaux esclaves de ces périphériques, et recopiera bêtement tout caractère émis par l'un sur l'entrée de l'autre. Une commande sera le telnet vers l'hôte distant, l'autre le <tt>pppd</tt> local. <tt>pppd</tt> peut alors ouvrir et contrôler comme d'habitude la session telnet avec un script <tt>chat</tt>. <sect1>fwprc J'ai écrit un script très bien auto-documenté (en anglais) pour percer des pare-feux, <tt>fwprc</tt> et <tt>cotty</tt> (qui est requis pour <tt>fwprc</tt> 0.2 ou ultérieur) sont disponibles depuis <URL URL="http://www.tunes.org/~fare/files/fwprc/" name="mon site">.  Au moment ou je traduis ces lignes, les dernières versions sont <tt>fwprc</tt> 0.3c et <tt>cotty</tt> 0.3a. Le nom "fwprc" est volontairement choisi pour être illisible et imprononçable, de façon à semer la confusion parmi les administrateurs systèmes incompétents qui pourraient être à l'origine du pare-feu qui vous embête (bien sûr, il y a aussi des pare-feu de sécurité légitimes, et indispensables; la sécurité est toute entière une affaire de configuration correcte). Si vous le lisez à haute voix, choisissez la façon la pire que vous puissiez imaginer. CONCOURS! CONCOURS! Envoyez-moi un fichier audio <tt>.au</tt> avec l'enregistrement audio numérique de votre façon de prononcer "fwprc". La pire candidature gagnera une mise-à-jour gratuite, et son nom sur la page de fwprc 1.0! J'ai testé le programme dans de nombreuses conditions, en le configurant à travers ses fichiers de "ressource". Mais bien sûr, loi de Murphy oblige, il ne fonctionnera pas pour vous. Les améliorations que vous pourrez effectuer pour rendre la vie plus aisée à ceux qui configureront la Bêête après vous sont les bienvenues. <sect1>.fwprcrc <tt>fwprc</tt> peut être adapté à vos besoins par le fichier <tt>.fwprcrc</tt>, qui est censé être le même de chaque côté du pare-feu. Il est bien sûr possible d'avoir plusieurs configurations différentes parmi lesquelles choisir (ce que j'ai fait personnellement, par exemple); comment y arriver précisément est laissé comme un exercice pour le lecteur. Pour commencer, copiez la section idoine de <tt>fwprc</tt> (l'avant dernière) dans un fichier nommé <tt>.fwprcrc</tt> dans votre répertoire personnel. Remplacez alors les valeurs des variables avec ce qui convient à votre configuration. Enfin, copiez le fichier sur l'hôte distant, et testez. Le comportement par défaut est d'utiliser <tt>pppd</tt> localement, et slirp à distance. Pour modifier cela, vous pouvez redéfinir les fonctions appropriées dans votre <tt>.fwprcrc</tt> avec une ligne telle que: <tscreen> remote_IP_emu () { remote_pppd } </tscreen> Veuillez noter que SLiRP est plus sûr que <tt>pppd</tt>, et plus aisé d'accès aussi, puisqu'il ne nécessite pas d'avoir les privilèges de super-utilisateur sur la machine distante. Une autre particularité rassurante de SLiRP est qu'il rejeterra tout paquet qui ne vient pas directement de la machine connectée (particularité qui peut se révéler ennuyeuse si l'on tente de re-router tout un sous-réseau sur la connexion avec du "masquerading"). Toutes les fonctionnalités de base fonctionnent fort bien dans SLiRP, mais j'ai trouvé que les suppléments proclamés (comme le contrôle dynamique) étaient déficients; bien sûr, puisqu'il s'agit de logiciel libre, vous pouvez librement bricoler les sources pour réaliser toute fonctionnalité dont vous auriez besoin. <sect>Traverser un pare-feu en sens inverse <sect1>Motivation Parfois, un seul côté du pare-feu est abilité à lancer des sessions telnet vers l'autre côté; cependant, il reste souvent disponible quelque moyen de communication (typiquement, le courrier électronique) permettant d'envoyer des messages. Traverser le pare-feu est toujours possible, en déclenchant par un tel message une connexion telnet depuis le "bon" côté du pare-feu vers l'autre. <tt>fwprc</tt> comprends du code pour déclencher de telles connexions depuis un message électronique authentifié par PGP; tout ce dont vous avez besoin est d'ajouter avec <tt>procmail(1)</tt> un filtre de courrier appelant <tt>fwprc</tt> pour ce protocole, (instructions incluses dans <tt>fwprc</tt> lui-même). Cependant, veuillez remarquer que si vous voulez lancer un <tt>pppd</tt> avec les privilèges super-utilisateur appropriés, vous devrez créer votre propre emballeur suid pour devenir root. Instructions comprises dans <tt>fwprc</tt>. De plus, un déclenchement authentifié n'entraîne absolument pas une connexion sécurisée. Il faut vraiment utiliser <tt>ssh</tt> (peut-être par-dessus telnet) pour une connexion sécurisée. Et dans ce cas, il faut bien faire attention à la sécurité entre le moment où la connexion telnet est lancée, et le moment où <tt>ssh</tt> prend le dessus sur cette connexion. Toute contribution dans cette direction sera la bienvenue. <sect1>Recevoir le message de déclenchement Si vous êtes derrière un pare-feu de sécurité, votre courrier est sans-doute centralisé sur un serveur qui ne permet ni filtrage par procmail, ni session telnet. Pas de problème! Vous pouvez utiliser <tt>fetchmail(1)</tt> en mode démon pour interroger à intervalle régulier le serveur, et recevoir le courrier sur votre système client Linux, et/ou ajouter une tâche cron pour interroger le serveur toutes les 1 à 5 minutes. fetchmail enverra le courrier à une adresse locale à travers <tt>sendmail(8)</tt>, qui lui-même aura été configuré pour faire appel à <tt>procmail(1)</tt> pour la livraison des messages. Remarquez que si vous lancez <tt>fetchmail(1)</tt> comme un démon en tâche de fond, il établira un verrou empêchant de fonctionner d'autres fetchmail que vous voudriez lancer, par exemple à l'ouverture d'une connexion par <tt>fwprc</tt>; bien sûr, vous pouvez aussi lancer le démon fetchmail depuis un compte utilisateur bidon. Interroger le serveur trop fréquemment ne sera gentil ni pour le serveur, ni pour votre machine. L'interroger trop peu fréquemment engendrera des temps de réponse élevés avant qu'un message de soit traité et qu'une connexion en sens inverse ne soit établie. J'utilise un intervalle d'interrogation de deux minutes. <sect>Notes finales <sect1>Autres configurations Il y a d'autres types de pare-feux que ceux qui permettent des connexions par telnet. Tant qu'un flux continu de paquets peut traverser le pare-feu et passer de l'information dans chacun des deux sens, il est possible de percer le pare-feu; le coût de l'écriture du perceur sera plus ou moins élevé selon les circonstances. Dans un cas très facile, il s'agit juste de lancer <tt>ssh</tt> sur un pseudo-terminal, et un <tt>pppd</tt> sur le terminal esclave associé. Vous pourriez même vouloir vous livrer à cet exercice sans avoir de pare-feu contre lequel lutter, juste pour construire un réseau privé virtuel (VPN) sécurisé. Le VPN mini-HOWTO fournit tous les détails nécessaires à ce sujet. Nous vous invitons, pour votre entraînement, à modifier <tt>fwprc</tt> pour utiliser cette technique voire même pour l'utiliser à l'intérieur d'une session <tt>fwprc</tt> précédente non-sécurisée. Si vous avez besoin d'une ligne 7-bit, vous pourrez vouloir utiliser SLIP plutôt que PPP. Je n'ai jamais essayé, car de nos jours, les lignes sont plus ou moins toutes prêtes pour des flux 8-bit. Ca ne devrait pas être particulièrement difficile. Le cas échéant, essayez en fin de compte la méthode décrite par le Term-Firewall mini-HOWTO. Maintenant, si le seul moyen à travers le pare-feu est un "proxy" ouèbe, (ce qui constitue d'habitude le minimum pour un réseau connecté à l'Internet), vous pourrez considérer l'utilisation de <url url="http://www.nocrew.org/software/httptunnel.html" name="httptunnel">, développé par <url url="http://lars.nocrew.org" name="Lars Brinkoff">, la combinaison d'un démon et d'un client HTTP, qui permet d'ouvrir une connexion TCP/IP à travers un tunnel implémenté au-dessus du protocole HTTP que le proxy laisse passer. Vous devriez alors être en mesure de faire tourner <tt>fwprc</tt> (de préférence au-dessus de <tt>ssh</tt>) sur cette connexion, bien que je n'aie pas encore essayé. Est-ce que quelqu'un peut faire le test et dire ce qu'il en est? Notez que <tt>httptunnel</tt> est en cours de développement, aussi vous pourriez aider à implémenter les caractéristiques qui lui manquent, par exemple, la gestion de connexions multiples, ou le fait de servir des pages paravent, histoire d'égarer l'administrateur soupçonneux d'un pare-feu adverse. Quoi qui puisse passer à travers votre pare-feu, que ce soit du telnet, du HTTP, ou un autre type de connexion TCP/IP, voire quelque chose de bien plus étrange, des requêtes DNS, des paquets ICMP, ou autre, vous pouvez toujours écrire une combinaison client/serveur pour creuser un tunnel, et faire tourner un ssh et/ou une connexion PPP à travers. La performance peut ne pas être au rendez-vous, selon la vitesse effective de communication d'information après avoir payé le prix d'un protocole traversant filtres et proxies; cependand, un tel tunnel reste intéressant tant qu'il suffit à l'utilisation de <tt>fetchmail(1)</tt>, <tt>suck(1)</tt>, et autres programmes non-interactif. Si vous avez vraiment besoin de plus de performance que vous n'en pouvez obtenir tout en payant le prix d'un tunnel de communication séquentielle en mode utilisateur, à travers duquel lancer PPP, alors vous êtes dans le cas le plus dur, où vous devrez re-bricoler votre propre pile IP bizarre, en partant (par exemple) des foncteurs de protocoles de communication du projet Fox (à CMU). Vous obtiendrez alors directement un IP-sur-HTTP, IP-sur-DNS, IP-sur-ICMP, ou similaire, qui nécessite non-seulement un protocole complexe, mésohsi une interface avec le noyau d'un système d'exploitation, qui sont tous les deux coûteux d'implémentation. <sect1>Maintenance de ce HOWTO J'ai senti que l'écriture de ce mini-HOWTO était nécessaire, et j'ai même accepté de le traduire en français, mais je n'ai pas vraiment le temps de m'en occuper, aussi ce mini-HOWTO est-il encore dur d'approche. Et il le restera jusqu'à ce que je reçoive assez de d'information en retour pour savoir quelles sections améliorer. Retour d'information bienvenu. Aide bienvenue. Prise en charge par un tiers de la maintenance de ce mini-HOWTO bienvenue. Dans tous les cas, les sections ci-dessus ont montré plusieurs problèmes dont la solution est "juste" l'affaire que quelqu'un (vous?) passe quelque temps (ou dépense quelqu'argent, en louant les services d'un tiers), pour s'asseoir et l'écrire: rien de bien compliqué conceptuellement, bien que les détails sachent se montrer encombrants et demander de l'astuce. N'hésitez pas à me faire parvenir plus de problèmes, et je l'espère de solutions, à publier dans ce mini-HOWTO. Ainsi, le besoin se fait sentir d'une section sur la mise en place de routes correctes avec <tt>fwprc</tt>, y compris des exemples d'utilisation de <tt>getroute.pl</tt> depuis <tt>/etc/ppp/ip-up</tt>. <sect1>Copie supplémentaire d'un AVERTISSEMENT IMPORTANT --- CROYEZ-Y!!! <quote> <bf> Je rejette toute responsabilité sur l'utilisation des astuces présentées. Si vous vous plantez en tentant de les mettre en oeuvre, c'est votre affaire, pas la mienne. Si vous ne comprenez pas les risques inhérents à l'utilisation de ces astuces, alors ne les utilisez pas. Si vous les utilisez, et qu'elles permettent à des méchants pas beaux de pénétrer dans les ordinateurs de votre entreprise, et que cela vous coûte votre emploi, et coûte à votre entreprise des millions de francs, c'est vraiment trop bête, mais ne venez pas vous plaindre à moi en pleurnichant. </bf> </quote> </article>