8. Remarques finales

8.1. Autres réglages

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

8.2. Le suivi de ce petit guide

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.

8.3. Documents sur le sujet

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.

8.4. Le mot de la fin

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

8.5.  Copie supplémentaire de l’avis très important de non responsabilité — croyez le !!!

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