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 :
SLiRP se trouve sur http://blitzen.canberra.edu.au/slirp ou sur ftp://www.ibc.wustl.edu/pub/slirp_bin/.
zsh se trouve sur http://www.zsh.org/.
ppp se trouve sur ftp://cs.anu.edu.au/pub/software/ppp/.
ssh se trouve sur http://www.openssh.com/.
fwprc, cotty et getroute.pl se trouvent sur http://fare.tunes.org/files/fwprc/.
httptunnel se trouve sur http://www.nocrew.org/software/httptunnel/.
mailtunnel se trouve sur http://www.detached.net/mailtunnel/.