Petit guide du per?age de pare-feux

Lisez cette section, elle est importante?!!!!

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.

Copyright ? 1998-2001 par Fran?ois-Ren? Rideau.

Ce document est publi? en logiciel libre sous la license bugroff.

Pour faciliter leur travail, les droits ont ?galement ?t? c?d?s aux responsables de la maintenance du LDP [Linux Development Project] sous la Licence de Documentation Libre GNU.

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

M?me si tout ce qu’il en reste est le paragraphe sur la non responsabilit?, ce document doit ?norm?ment au Term-Firewall mini-HOWTO de Barak Pearlmutter <bap CHEZ cs POINT unm POINT edu>. Le petit guide de Barak repose sur Term?, 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.

J’aimerais ?galement f?liciter Lars Brinkhoff <lars CHEZ nocrew POINT org> et Magnus Lundstr?m <logic CHEZ gore POINT nocrew POINT org> pour leurs tr?s bons tunnels http, messagerie et icmp.

La derni?re version LDP officielle de ce document est sur?: http://www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html

La source de ma derni?re version officielle de ce document est sur?: 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

Ce document a une morale. Et cette morale est?: un pare-feu ne peut pas prot?ger un r?seau contre ses propres utilisateurs internes et ne devrait m?me pas essayer.

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 ssh, telnet, navigateur web, courrier ?lectronique, dns, ligne t?l?phonique, 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 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.

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

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.

Il s’agit donc ici tout simplement d’utiliser de fa?on commode 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).

De plus, l’utilisation d’un ?mulateur d’IP niveau utilisateur tel que SLiRP? 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).

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.

R?p?tons les bases de la s?curit? r?seau?: 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 , 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.

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.

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

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 telnet, ssh, 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, 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 acc?s ? internet d?mon et la biblioth?que qui va avec (SOCKS?, Term?) 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.

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 Term-Firewall mini-HOWTO de Barak Pearlmutter d?crit comment utiliser Term?, 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 SOCKS? 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.

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 .rpm et .deb 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?:

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.

La premi?re ?tape pour comprendre le probl?me est de donner un nom aux concepts appropri?s.

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.

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.

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.

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

Pour le probl?me annexe, les ?mulateurs d’IP (pppd ou SLiRP?) sont lanc?s de chaque c?t? du tunnel.

Du c?t? qui veut un acc?s IP complet vers l’autre c?t?, il vous faudra lancer pppd. De l’autre c?t?, vous devez lancer pppd si vous voulez un acc?s IP complet dans l’autre sens, ou SLiRP? si vous voulez emp?cher tout acc?s. Consultez votre documentation pppd ou SLiRP? habituelle pour plus d’informations, si vous avez des besoins sp?cifiques qui ne sont pas trait?s dans les exemples ci-dessous.

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.

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 ssh, qui s’occupe de mani?re transparente du lancement de commande du serveur.

Le point (b) requiert l’utilisation d’un simple utilitaire ext?rieur. Nous en avons fait un, cotty juste dans ce but.

< PIQUAGE DE CRISE>

Entre autres probl?mes d?biles d?s ? l’?troitesse d’esprit des concepteurs de pppd (ceci n’est plus le cas dans les versions r?centes 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 entra?ne 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 interf?rer?; l’utilisation de telnet sans un tty impose ?galement un r?gime tel que toute la connexion ?chouera sur des ordinateurs ??lents?? (fwprc 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 telnet, vous avez besoin de cotty comme d?mon 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? bien que il a d? y avoir des gens d’UNIX? 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?!

</JE ME CALME>

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 httptunnel, mailtunnel, un tunnel sur le telnet, ou autre).

Vous pouvez alors lancer un sshd sur le port c?t? serveur, et vous y connecter avec un ssh sur le port c?t? client. Des deux c?t?s de la connexion ssh vous lancez des ?mulateurs d’IP ( pppd), 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 ssh).

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.

Ci-dessous se trouve un exemple de script que vous pouvez adapter ? vos besoins. Il utilise le syst?me de rang?e 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 m?me 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 contr?le 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 n?cessaire, ou que l'on peut d?bloquer 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 assur?ment pas la chose ? faire.

Si vous n’?tes pas root ou simplement si vous voulez prot?ger le r?seau de votre client des connexions sortantes, vous pouvez utiliser slirp au lieu de pppd comme ?mulateur PPP du serveur. Il n’y a qu’? d?commenter la ligne appropri?e.

#!/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) :
	# defaultroute
)
$CLIENT_PPPD pty "ssh -t $SERVER_ACCOUNT $SERVER_PPPD"

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

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

Le programme de per?age 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 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 pppd. pppd peut alors ouvrir et contr?ler 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 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

ssh -t -o "ProxyCommand ..."

J’ai ?crit un script qui d?crit de fa?on tr?s d?taill?e comment percer les pare-feu, fwprc, disponible sur mon site, 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 avanc?e de fwprc est 0.3e et pour cotty 0.4c.

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 correcte). Si vous devez le lire ? voix haute, prononcez le de la pire fa?on possible et imaginable.

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 fwprc 1.0!

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.

fwprc peut ?tre personnalis? gr?ce au fichier .fwprcrc 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, moi je le fais), et on laisse ?a comme exercice pour le lecteur.

Pour commencer, copiez la section appropri?e de fwprc (l’avant-derni?re) dans un fichier nomm? .fwprcrc 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.

Le comportement par d?faut est d’utiliser pppd sur le client, et slirp sur le serveur. Pour modifier ceci, vous pouvez red?finir la fonction appropri?e dans votre .fwprcrc avec une ligne telle que?:

remote_IP_emu () { remote_pppd }

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.

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.

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.

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 /etc/init.d/network ou /etc/network/; de m?me, votre configuration PPP se trouve g?n?ralement 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 sp?cifiques ? votre distribution, vous devez lire la documentation de votre distribution ou encore RTFM; sinon, utilisez grep r?cursivement dans votre /etc; au pire, rep?rez ce qui se passe au moment du d?marrage, comme configur? dans votre /etc/inittab.)

Lorsque vous percez un tunnel dans un r?seau prot?g? ? partir d’un portable sur internet, le script getroute.pl (disponible sur la distribution fwprc) donne la route utilis?e vers le serveur h?te qui repr?sente l’autre bout du tunnel.

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.

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

Dans cet exemple, votre machine cliente est connect?e ? un r?seau local avec pare-feu gr?ce au dispositif ethernet eth0. Son adresse IP est 12.34.56.78; son r?seau est 12.34.56.0/24; son routeur est 12.34.56.1.

Votre administrateur r?seau peut vous avoir dit d’utiliser 12.34.56.1 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.

Supposons que le c?t? client du pare-feu est compos? des r?seaux 12.34.0.0/16 et 12.13.0.0/16, et de l’h?te 11.22.33.44. Pour les rendre accessibles par votre routeur client, ajoutez ces routes au script de d?marrage de votre r?seau 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

route add -net 12.34.56.0 netmask 255.255.255.0 dev eth0

route add default gw 12.34.56.1

route del default gw 12.34.56.1

route add default gw 10.0.2.2

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

$(getroute.pl 98.76.54.32)

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

fwprc inclut du code pour d?clencher 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-m?me). Remarquez cependant que si vous devez lancer pppd avec les privil?ges appropri?s, il vous faudra peut-?tre cr?er votre propre suid wrapper pour devenir root. Instructions incluses dans fwprc.

En outre, d?clenchement authentifi? ne signifie absolument pas connexion s?curis?e. Il faut vraiment utiliser ssh (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 ssh prend en main cette connexion. Toute contribution ? ce sujet sera la bienvenue.

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 fetchmail 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 procmail ? la r?ception. Remarquez que si vous lancez fetchmail 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 fwprc; 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.

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 tunnel FTP.

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 tunnel pare-feu.

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.

Je ne connais pas les d?tails, mais il existe un outil prometteur pour percer les pare-feu ?: le Bouncer de Chris Mason, qui joue le r?le 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 tr?s facile : ainsi, on a remarqu? qu’il suffit de lancer ssh sur un ma?tre pty et faire du pppd 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 VPN mini-HOWTO donne tous les d?tails n?cessaires ? ce sujet. Comme exercice, nous vous invitons, ? modifier fwprc pour utiliser cette technique, ou peut-?tre m?me pour l’utiliser ? l’int?rieur d’une pr?c?dente session fwprc non s?curis?e.

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 ssh-https-tunnel de Chris Chiappa.

Autre programme prometteur pour percer ? travers http ?: le httptunnel de Lars Brinkoff, une combinaison serveur et client http permettant une connexion TCP/IP par tunnel gr?ce au protocole http. On devrait ensuite pouvoir lancer fwprc (de pr?f?rence 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 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.

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 mailtunnel, 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 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 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 n?cessaire, rabattez vous sur le Term-Firewall mini-HOWTO.

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

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

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.

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.

N’h?sitez pas ? proposer d’autres probl?mes, et, esp?rons-le, d’autres solutions, pour ce petit guide.

Le LDP publie de nombreux documents en rapport avec ce petit guide. tout particuli?rement Linux Security Knowledge Base, le HOWTO VPN et le petit guide VPN. Pour des questions plus g?n?rales sur le r?seau, le routage et les pare-feu, commencez avec le Networking Overview HOWTO. Regardez ?galement le Linux Firewall and Security site.

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 [RTFM?: Read The Fscking Manual] sur les programmes en question.

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 C++? ou le Java? qui ne permettent pas d’exprimer directement des constructions de programmation de plus haut niveau (alors que de bons langages tels que le LISP? permettent de les exprimer), on peut dire que le besoin en guides pratiques vient directement du fait que les syst?mes Linux? et UNIX? 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.

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 (UNIX haters) 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 TUNES).

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