Jusqu'il y a peu de temps, notre réseau était relié au réseau global via PPP par un modem. Avec cette configuration, j'avais installé un pare-feu utilisant IPChains et cela fonctionnait correctement. Nous avons récemment évolué vers une configuration DSL. Je pensais que ce serait une bagatelle de simplement basculer mon pare-feu de façon à ce qu'il m'isole du réseau entrant associé à la connexion DSL. J'avais tort. J'ai mis trois jours avant de parvenir à un résultat opérationnel. J'ai trouvé beaucoup d'informations douteuses sur le réseau qui m'ont procuré bien du désarroi. Ce mini-HOWTO a été écrit parce que je soupçonnais que notre installation serait plutôt banale dans le futur avec l'extansion de DSL et que je souhaitais aider les autres à s'épargner une importante frustration.
Je pense que ceci est applicable à une connexion modem-câble mais « c'est vous qui voyez » dans la mesure où je ne connais rien aux liaisons par modem-câble.
Le problème que je tente de résoudre est de de configurer le système de façon à ce que le code du pare-feu dans le noyau (qui est manipulé par ipchains) soit utilisable pour filtrer les paquets qui vont et viennent entre le monde extérieur et le réseau local. J'avais également besoin que certaines machines locales soient « vues » du réseau global (bien que filtrées au travers du pare-feu de manière permanente). Ceci éliminait le masquage IP (voir le IP Masquerade HOWTO) qui, autrement, serait probablement une solution plus aisée. Ce n'est pas si simple qu'il y paraît.
Pour arriver à notre but d'isoler un réseau local du réseau global (sur DSL) en utilisant notre linuxette, nous utiliserons deux cartes ethernet (NIC). Une de ces cartes est connectée au réseau local, l'autre au réseau global. La seule machine qui peut directement communiquer avec l'extérieur est la machine Linux. Toutes les autres machines de notre réseau local doivent passer par cette dernière (pare-feu).
La configuration logicielle consiste en résoudre deux problèmes :
router les paquets entre les réseaux local et global (pontage) ;
filtrer les paquets pour en stopper certains lorsqu'ils transitent par le pare-feu.
Le Bridging mini-Howto) donne des instructions détaillées en ce qui concerne le premier problème de routage des paquets entre les deux parties du réseau (local et global). Ceci fonctionne en positionnant les deux cartes ethernet sur le mode « promiscuous » de façon à ce qu'elles détectent les paquets sur chacune des interfaces et transfèrent ceux-ci quand ils appartiennent à l'autre côté. Ceci se fait de manière transparente : les autres ordinateurs sur le réseau ne voient même pas le pont, car celui-ci n'a même pas d'adresse IP. Mais cela ne résout pas totalement le problème. Je voulais que le pare-feu ait une adresse IP (du moins pour l'administrer à distance) et, plus ennuyeux, le code du pont dans le noyau interceptait et transférait les paquets AVANT qu'ils ne parviennent au code du pare-feu ce qui faisait que celui-ci n'avait aucun effet. Vous pouvez alternativement attribuer des adresses IP à vos cartes et continuer à les utiliser comme un pont. Bien que le Bridging mini-Howto ne le fait pas (en réalité, il utilise l'adresse de loopback), cela fonctionne bien. Cela résout un problème. En ce qui concerne le pare-feu, on se tourne vers une rustine sympa pour le noyau à http://ac2i.tzo.com/bridge_filter/ qui fait en sorte que les règles du pare-feu soient invoquées pour les paquets qui ont traversé le pont avec une nouvelle règle « bridgein ».
Ce mini-HOWTO a pour but de vous aider à prendre en mains la situation où vous avez une machine Linux configurée comme une passerelle/pare-feu. Le système a deux cartes réseau. L'une des cartes est connectée au monde extérieur (dans notre cas, un modem DSL) et rien d'autre. L'autre carte est connectée à notre réseau local.
Notez que je n'ai eu d'expérience de ceci que sur mon i386 (ABIT BP6 MOBO, w/2 céléron) avec une RedHat 6.0, un noyau 2.2.13, un modem DSL connecté à un routeur et deux cartes Net Gear FA310TX. Votre cas peut être différent.
Notez également que la démarche proposée laissera votre réseau ouvert à des attaques éventuelles au démarrage (avant que le pare-feu ne soit activé). Si vous êtes très paranoïaque, vous devrez prendre des mesures pour éviter ceci.
J'ai trouvé pas mal d'informations sur internet que j'ai utilisée pour faire fonctionner les choses. Une partie de cette information était utile mais inappropriée.
Le Bridging mini-HOWTO a joué un rôle décisif pour la mise en œuvre. Malheureusement sa seule utilisation ne permet pas de mettre en place un pare-feu.
Le Linux Bridge+Firewall mini-HOWTO) me paraissait, au premier abord, être pile ce dont j'avais besoin. Néanmoins, il s'avère que je pense qu'il est inapproprié. J'ai obtenu un fonctionnement relatif mais, en fin de compte, je me suis aperçu qu'il n'était pas nécessaire de scinder notre sous-réseau en deux comme il le préconise et je n'utiliserai pas cette méthode. Si vous tombez sur ce document, considérez-le avec des réserves.
La rustine Bridge Filter est la clé pour obtenir un bon fonctionnement de l'ensemble. Assez bizarrement, l'information sur la page web vous redirige vers le Bridge+Firewall mini-HOWTO. Vous n'avez pas besoin de mettre en œuvre les indications du Bridge+Firewall mini-HOWTO pour obtenir que les choses fonctionnent. Vous aurez besoin de cette rustine.
Le IPCHAINS HOWTO est essentiel pour la mise en œuvre du pare-feu en lui-même. Je ne traiterai pas de l'installation du pare-feu dans ce document ; seules les choses qui diffèrent en raison de la mise en œuvre du pontage seront abordées.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:34