Version : 0.97
18 septembre 2006
Historique des versions | ||
---|---|---|
Version 0.97.fr.1.0 | 2006-09-18 | AM, YB, JPG |
Première version française. | ||
Version 0.97 | 2001-11-24 | FRR |
Conversion au format SGML DocBook. Conversion to DocBook SGML. |
Résumé
Comment utiliser ppp par-dessus ssh, telnet ou autre, de façon à réaliser une connexion réseau transparente à travers un pare-feu. Valable aussi bien pour l'élaboration d'un VPN convivial que pour la perforation des pare-feu gênants.
Table des matières
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.
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
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.
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/.
Quand vous comprenez un problème, vous avez fait la moitié du chemin vers la solution.
#!/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"
Notez que les options par défaut de votre /etc/ppp/options
ou ˜/.slirprc
peuvent casser ce script, enlevez donc toute option non désirée.
Notez également que 10.0.2.2
est le paramétrage par défaut pour slirp, ce qui peut ne pas fonctionner avec votre installation particulière. En tout cas, vous devriez de préférence utiliser une adresse dans l’une des catégories réservées par la RFC-1918 pour les réseaux privés :
10.0.0.0/8
,
172.16.0.0/12
ou 192.168.0.0/16
.
Il se pourrait que le réseau local protégé par pare-feu utilise certaines d’entre elles et il est de votre responsabilité d’éviter les conflits. Pour une plus grande personnalisation, lisez la documentation appropriée.
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_PPPDPièges : ne mettez pas les commandes données à cotty entre guillemets, car elles s’exécutent exec()telles quel, et n’oubliez pas de spécifier 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).
ssh -t -o "ProxyCommand ..."(Soumettez moi une solution et je l’intégrerai volontiers à la distribution fwprc).
Remarque : si vous devez utiliser la solution non sécurisée basée sur le telnet, assurez vous que, dans votre session cible, il ne se trouve rien de confidentiel ou qui ne doive être bidouillé, puisque le mot de passe sera envoyé en clair sur internet. Si c’est à votre portée, un système ne demandant le mot de passe qu’une seule fois, ou un système de cryptographie explicite augmentera votre sécurité, ce qui, toutefois, rendra les scripts de connexion automatique bien plus complexes.
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.
remote_IP_emu () { remote_pppd }
Notez que SLiRP™ est plus sûr que pppd, et plus facile d’accès, puisqu’il ne requiert pas d’être root sur la machine serveur, et n’a pas besoin d’une configuration supplémentaire du pare-feu pour empêcher les connexions du monde extérieur sur le réseau derrière un pare-feu. La fonctionnalité de base dans SLiRP™ fonctionne plutôt bien, mais je n’ai pas réussi à faire marcher certains des plus qu’il est censé proposer (tel que le contrôle du temps d’exécution). Bien entendu, puisqu’il s’agit d’un logiciel libre, n’hésitez pas à aller dans la source pour carrément implémenter ou réparer n’importe quel dispositif dont vous aurez besoin.
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.
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.1Vous devez également garder la route vers le réseau local du client, nécessaire pour le kernel 2.0 de Linux , mais pas pour le kernel 2.2 et suivants de Linux (ceci l’ajoute implicitement pendant le ifconfig):
route add -net 12.34.56.0 netmask 255.255.255.0 dev eth0Par contre, vous devez impérativement enlever toute route par défaut de vos scripts. Supprimez ou mettez en commentaire une ligne telle que :
route add default gw 12.34.56.1Remarquez qu’il est également possible d’enlever la route de la configuration du kernel en marche sans redémarrer, grâce à la commande suivante :
route del default gw 12.34.56.1Vous pouvez ensuite obtenir de pppd l’installation automatique d’une route par défaut lorsqu’il démarre en utilisant son option defaultroute Sinon, vous pouvez l’ajouter plus tard :
route add default gw 10.0.2.2Si vous ne voulez pas de pppd comme route par défaut, parce que l’accès internet est disponible de votre côté du pare-feu, et si vous voulez plutôt que le réseau
98.76.48.0/20
soit routé par le tunnel, sauf au départ de l’hôte 98.76.54.32
qui représente 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.2Si vous êtes sur un portable et que vous changez de réseau local, mais que vous voulez quand même garder votre route actuelle vers
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 numériques (et vous pouvez même utiliser des FQDN, si vous pensez que le DNS ne plante jamais).
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 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é.
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.
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).