Réseaux privés avec "Roadrunner" en utilisant l'IP Masquerading <author>Mark Nielsen et Andrew Byrd   <sect>Réseaux privés avec "Roadrunner" en utilisant l'IP Masquerading Par Mark Nielsen <tt>zing@tcu-inc.com</tt> et Andrew Byrd <tt>byrd.74@osu.edu</tt>   <bf>Résumé</bf> Cet article est destiné à vous aider dans l'installation d'un réseau TCP/IP privé "masqueradé", connecté à Internet grâce au service modem câble <em/Roadrunner/ de Time Warner. Il s'agit de la ré-écriture d'un article précédent sur le même sujet:avec l'arrivée de la RedHat 6 et la migration de Roadrunner vers le DHCP (au moins à Columbus, Ohio, vérifiez si le DHCP est utilisé dans votre ville), de nombreuses choses ont changées. C'est une tâche ardue en ce qui concerne le réseau, qui fait appel à des concepts allant du DNS au pare-feu. Quand vous aurez terminé ce travail, vous aurez acquis une réelle expérience dans l'installation d'un réseau de petite taille. Une précision cependant: j'ai appelé Roadrunner et ils étaient plutôt vague quant au fait d'autoriser les gens à faire appel à l'IP-Masquerading. Les commerciaux disaient simplement que cela les dérangerait si vous monopolisiez la bande passante. Il y a deux "Je" dans ce document. Parfois, c'est Andrew qui parle, d'autres fois c'est Mark. <sect1>Prérequis<label id="one"> Les HOWTOs suivants contiennent les informations nécessaires pour comprendre le reste de cet article. Si vous décidez de continuer sans les lire, vous risquez de ne pas saisir totalement ce qui va être décrit ci-dessous. <enum> <item><url url="http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html" name="Networking"> - Les informations de base sur Ethernet et TCP/IP. Les sections 5 et 6 sont les plus intéressantes. <item><url url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" name="IPCHAINS"> - Les chaînes pare-feu IP feront le plus gros du travail dans votre configuration. Elles comportent aussi de nombreuses implications au niveau de la sécurité. <item><url url="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html" name="DNS"> - L'installation d'un DNS sera beaucoup plus facile si vous comprenez son fonctionnement. <item><url url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html" name="IP Masquerading"> - Ce document couvre l'IP Masquerading de manière plus générale qu'ici. <item> <url url="http://www.linuxgazette.com/issue28/nielsen.html" name="Notre précédent"> article sur ce thème (<url url="http://www.linux-france.org/article/lgazette/issue-29/lg-29-5.html" name="version française">). <item> <url url="http://www.vortech.net/rrlinux/" name="RRLinux Help Site"> - Le site d'assistance Linux de RoadRunner. <item> <url url="http://dir.yahoo.com/Computers_and_Internet/Software/Operating_Systems/Unix/Security/" name="Unix Security"> - La sécurité sous UNIX, située sur Yahoo. <item> <url url="http://stones.wcbe.org/~COLUG/" name="The Central Ohio Linux User Group"> - Le groupe des utilisateurs de Linux du centre de l'OHIO, d'où beaucoup d'idées proviennent. </enum> <sect1>Le schéma d'ensemble Ce diagramme présente le principe : <url url="diagram-fr.png" name="diagram-fr.png">  Chaque gros point noir sur le diagramme est une carte ethernet, et chaque ligne de connexion est une longueur de câble CAT5, à l'exception du câble de connexion vers Time Warner qui part du boîtier de connexion. Notez que vous avez besoin d'une carte d'interface (de type ethernet) pour chaque station de travail et de deux pour votre passerelle. Votre réseau privé est indiqué par un fond blanc dans l'image, et le reste du monde est dans la zone grisée. Vos stations de travail et vos hubs sont à l'intérieur de votre réseau privé. Notez que la passerelle est à la frontière des deux. Une adresse IP est assignée à chacune des cartes Ethernet, votre passerelle en possède une pour le monde extérieur et une autre pour votre réseau interne. Telle qu'elle est située, la passerelle a la possibilité de faire suivre des communications de votre réseau privé vers le monde extérieur. Pour la suite de cette description, je vais donner au réseau privé le bloc d'adresses IP privées réservées <tt/10.x.x.x/ (avec comme masque réseau 255.0.0.0) et choisir le nom de domaine <em/local/. Ceci peut bien sûr être modifié si vous savez ce que vous faîtes mais cela devrait convenir pour la plupart des gens. Les stations de travail sont nommées de <em/w1.local/ (<tt/10.0.0.10/) à <em/w3.local/ (<tt/10.0.0.30/) et la passerelle <em/masqueradée/ s'appelle <em/main.local/ (<tt/10.0.0.1/ sur le réseau privé). Comme précédemment, vous pouvez modifier ou étendre ce schéma si vous êtes à l'aise. <sect1>Choix du matériel La passerelle nécessite relativement peu de ressources. Il peut s'agir d'un vieux 486 avec relativement peu de mémoire. Le routage des paquets n'est particulièrement gourmand. Si vous pouvez y faire tourner Linux, ça devrait faire l'affaire. Les stations de travail peuvent être n'importe quelle machine sur laquelle est installé un système d'exploitation gérant le TCP/IP, tel que <em/Linux/, <em/MacOS/ ou les systèmes d'exploitation de <em/Microsoft/. Vous aurez besoin d'équiper chaque machine d'une carte ethernet. Choisissez un hub auto-configurable 10/100 Mbits. Il vous simplifiera la vie. Utilisez des cartes ethernet avec un débit de 100 Mbits à l'intérieur du réseau. Sur votre passerelle, la carte ethernet connectée à l'extérieur peut être une simple carte ethernet à 10 Mbits. J'utilise partout le même type de cartes ethernet. Elles ont toutes un débit de 10/100 Mbits. En utilisant le même matériel partout, vous vous simplifierez la vie la plupart du temps. Utiliser des cartes PCI sur les systèmes Linux est une bonne chose. De nos jours, les cartes ethernet ne sont plus très chères et en avoir en version PCI vous évitera des maux de tête pendant la phase de configuration. J'ai utilisé des cartes <em/Netgear FA310TX/ sur plusieurs machines sans rencontrer de problèmes. J'ai entendu dire que les cartes Intel rendaient de très bons services. Quoi qu'il en soit, faites une recherche sur le web et assurez-vous que les modules existent pour les cartes que vous achetez. Les pilotes des cartes <em/Netgear/ et <em/3com/ (que j'ai beaucoup utilisées) sont fournis avec la <em/RedHat 6/. Si vous devez utiliser de cartes ISA, la carte <em/3c509/ de <em/3com/ est plutôt facile à utiliser. Cependant, gardez à l'esprit que si vous utilisez une machine plus vieille pour votre passerelle, vous n'aurez peut-être que des slots ISA. Il faudra alors utiliser deux cartes ethernet ISA. Dans ce cas, il vous faudra récupérer un utilitaire fourni par le constructeur de vos cartes (qui, d'habitude, ne tourne que sous DOS). Il vous permettra de sélectionner l'adresse E/S et/ou l'IRQ de vos cartes afin de prévenir les conflits. <sect1>Installation de la passerelle La machine que vous utiliserez comme passerelle sera celle connectée à RoadRunner. Tout d'abord, installez physiquement dans la machine les cartes ethernet que vous avez soigneusement choisies. En utilisant deux cartes de marques différentes sur la passerelle, vous éviterez les risques de confusion. Ainsi un pilote unique pour chaque carte vous permettra de connaître le nom de chacune (<tt/eth0/ et <tt/eth1/). Vous aurez aussi moins de risque de rencontrer des conflits d'interruption (qui doivent être fuis comme la peste). Si vous optez pour des cartes ISA, vous aurez besoin de récupérer des utilitaires DOS afin de configurer l'IRQ et les adresses d'entrée/sortie. Commencez par installer proprement la RedHat 6 (puisque c'est le but de cet article) sur la passerelle. Si vous avez de la place sur le disque dur, installez tout. Toutefois, vous n'avez pas vraiment besoin d'un serveur X, de logiciels de traitement d'images, etc, sur cette machine. Assurez-vous que vous installez <tt>ipchains</tt>, <tt/BIND/, le serveur de nom avec cache, <tt>pump</tt> et d'autres paquetages importants pour ce que vous allez faire ici. Indiquez également au programme d'installation de lancer le démon <tt>named</tt> au démarrage. Pour les besoins de cet article, <tt/eth0/ ira vers le boîtier de connexion à Roadrunner et <tt/eth1/ vers votre réseau privé. Vous pouvez configurer et démarrer la première interface ethernet pendant l'installation initiale. Connectez la carte correspondant à <tt/eth0/ au boîtier de connexion avec le câble croisé adéquat et indiquez lui d'utiliser <em/DHCP/ pour obtenir son adresse IP. N'en spécifiez pas: le service RoadRunner vous en assignera une. Utilisez le programme <tt>netconf</tt> (ou éditez directement les fichiers <tt>/etc/sysconfig/network-scripts/ifcfg-eth?</tt> et <tt><url url="#confmod" name="/etc/conf.modules"></tt>) pour que l'interface <tt/eth1/ fonctionne au démarrage, et affectez lui une adresse IP du réseau privé (<tt/10.0.0.1/). Il vous faudra peut-être un peu bricoler pour qu'au démarrage les deux cartes soient détectées et fonctionnent. Assurez vous que vous avez spécifié les bons modules/pilotes du noyau et que, lorsque vous exécutez <tt>ifconfig</tt>, vous voyez apparaître les interfaces <tt/eth0/ et <tt/eth1/ (ou bien vérifiez qu'elles sont configurées lors du démarrage de la machine). Vous serez alors prêt pour la suite. Il est aussi possible de compiler le noyau en incluant les pilotes des cartes réseaux (comme c'était souvent fait dans le passé) mais il est courant et parfaitement acceptable d'utiliser tout simplement des pilotes sous forme de modules comme nous le suggérons ici. Vérifiez que votre fichier <tt>/etc/sysconfig/network</tt> ressemble à <url url="#networkg" name="ça"> et remplacez <tt>/etc/hosts</tt> par votre propre version de ce <url url="#hosts" name="fichier">. Le fichier <tt>/etc/hosts</tt> n'est absolument pas nécessaire puisque nous allons installer un serveur de noms mais cela fait une bonne sauvegarde. <bf/NOTE SUR LES DEUX CARTES RESEAU 3c509/ : Connectez et configurez les deux cartes ethernet ISA avant d'installer la distribution Linux RedHat. Les deux cartes ethernet que Mark utilisait (il y a longtemps) étaient des <em/3com 3c509/. La première avait comme valeurs de configuration <tt>irq=10</tt> et <tt>address=300</tt>, et la seconde, les valeurs <tt>irq=11</tt> et <tt>address=310</tt>. Aussi, quand vous installez la RedHat, installez-la pour un LAN et procédez à une auto-détection des cartes ethernet. <bf/NOTE SUR LE DHCP/ : Vous pouvez configurer le DHCP à partir du <url url="http://www.redhat.com/support/manuals/RHL-6.1-Manual/ref-guide/s1-sysconfig-control-panel.html" name="panneau de configuration de RedHat">, avec <tt>netconf</tt>, en éditant les fichiers manuellement ou bien pendant l'installation de la RedHat (ou tout autre distribution Linux que vous utilisez). <sect1>Configuration de IPChains et du Masquerading Essayez d'interroger quelques serveurs à l'extérieur ou consultez quelques pages web avec <tt>lynx</tt> pour voir si votre connexion RoadRunner fonctionne. Si c'est bon, vous êtes prêt pour configurer le masquerading. Ajoutez <url url="#rclocal" name="cette partie"> concernant <tt>modprobe</tt> et les commandes d'<tt/ipchains/ à votre script <tt>/etc/rc.d/rc.local</tt> pour activer le forwarding/masquerading et aussi fournir des règles de pare-feu suffisamment efficaces. <sect1>Configuration du DNS pour le réseau privé Pour le moment, <tt>pump</tt> (qui récupère les informations du DHCP) configure le fichier <tt>/etc/resolv.conf</tt> pour pouvoir utiliser les DNS de RoadRunner. Cela n'apporte aucune fonctionalité permettant de connaître les noms des machines de votre réseau privé. Il serait donc nécessaire que chaque station de travail possède une copie du fichier <tt>/etc/hosts</tt> et que vous le configuriez manuellement afin d'utiliser un serveur de noms de RoadRunner. Comme ce n'est pas très propre, il est conseillé de faire tourner votre propre service DNS. Equipé des connaissances que renferme le HOWTO sur les DNS, créez et modifiez les fichiers <tt><url url="#namedconf" name="/etc/named.conf"></tt>, <tt><url url="#resolvconf" name="/etc/resolv.conv"></tt> ainsi que les <url url="#varnamed" name="fichiers"> se trouvant dans le répertoire <tt>/var/named</tt>. Vous devez aussi créer ou éditer le fichier <tt><url url="#pumpconf" name="/etc/pump.conf"></tt> pour empêcher <tt>pump</tt> d'écraser la configuration de votre fichier <tt>/etc/resolv.conf</tt> à chaque fois que vous lancez l'interface <tt>eth0</tt>. Vérifiez que le démon <tt>named</tt> est lancé au démarrage (il doit y avoir un lien <tt>S??named</tt> dans le répertoire <tt>/etc/rc.d/c3.d/</tt>). Après le redémarrage, un serveur de nom avec cache, ainsi qu'un DNS pour votre réseau privé, devraient être lancés. <sect1>Configuration des stations de travail Assurez-vous que les machines de votre réseau privé (ainsi que la passerelle) sont connectées entre elles via un hub et un câble Cat5. Vous pouvez alors configurer les stations de travail. Assignez à chaque machine/interface une adresse IP unique dans le bloc d'adresses privées. Voici un exemple de fichier <tt><url url="#networkw" name="/etc/sysconfig/network"></tt> pour des stations de travail Linux. Ajoutez un fichier <tt><url url="#hosts" name="/etc/hosts"></tt> que vous aurez personnalisé en fonction de votre réseau ainsi que ce fichier <tt><url url="#resolvconf" name="/etc/resolv.conf"></tt>. Maintenant ça devrait être bon. Essayez d'interroger quelques machines avec <tt>ping</tt> ou bien de lire quelques pages web sur un station de travail afin de vous assurez que le masquerading et le DNS fonctionnent correctement. Voici un exemple pour les autres machines de votre réseau. <enum> <item>adresse IP = 10.0.0.10 <item>adresse de nom = w1.local <item>masque de sous-réseau = 255.255.255.0 <item>le fichier <tt><url url="#resolvconf" name="/etc/resolv.conf"></tt> pour vos machines Linux <item>le fichier <tt><url url="#hosts" name="/etc/hosts"></tt> que j'utilise mais dont vous n'aurez pas besoin. Juste au cas où le DNS tombe en panne, ce sera pratique pour restaurer le système. </enum> La seule chose que vous devez changer sur chaque machine supplémentaire est son adresse IP et son adresse de nom. <tt>w2.local</tt> et <tt>10.0.0.20</tt> correspondra à la prochaine machine. Vous avez compris l'idée ? Aussi, si vous avez des clients PC, Mac ou d'autres types de machines, consultez le <url url="http://www.ssc.com/mirrors/LDP/HOWTO/IP-Masquerade-HOWTO.html" name="mini-HOWTO sur le masquerading">. L'idée générale est de spécifier la machine qui réalise le masquerading (<tt>10.0.0.1</tt>) comme la passerelle et le serveur DNS pour chaque machine. Vous trouverez dans l'<url url="#one" name="HOWTO IP-Masquerading">, une section très bien faite qui propose la configuration des stations de travail d'un réseau privé dont le système d'exploitation n'est pas Linux. <sect1>Du côté de la sécurité Être connecté continuellement à l'Internet comporte des risques. Il y a beaucoup de personnes à l'extérieur qui n'ont rien de mieux à faire que de s'attquer aux systèmes non protégés. Il y en a même et encore plus qui aimeraient utiliser votre système comme point de départ pour des activités illégales. Le masquerading est intrinsèquement quelque chose de dangereux puisqu'il nécessite de laisser passer le trafic à travers le pare-feu. En désactivant les démons qui écoutent sur les ports de votre passerelle, comme le <tt/telnet/ et le <tt/ftp/, vous pouvez écarter le plus gros du danger. Bien comprendre les chaînes pare-feu IP est aussi une aide précieuse. Une redirection de port comme <tt><url url="ftp://ftp.ox.compsoc.org.uk/pub/users/steve/ipsubs/" name="ipportfw"></tt> peut aussi être utilisée pour rediriger les requêtes de connexions en entrée vers d'autres machines de votre réseau (sur lequelles le service demandé fonctionnera), écartant ainsi le danger loin de votre passerelle. Vous pouvez empêcher l'accès à votre serveur DNS en le déplaçant sur une autre machine de votre réseau ou simplement en donnant à <tt>named</tt> une directive d'écoute appropriée (consultez la page de manuel <tt>named.conf</tt>) afin d'éviter la liaison avec un port sur votre interface externe. Si vous désirez une sécurité encore plus importante mais que vous avez besoin du login depuis l'extérieur, regardez <tt><url url="http://www.openssh.com/" name="openssh"></tt> qui permet des logins de type <em/telnet/ sur une connexion cryptée. Il est aussi conseillé d'installer un enregistreur de session avancé tel que <tt><url url="http://www.tigerteam.net/linuxgroup/tcplogd/" name="tcplogd"></tt> qui pourra détecter et vous informer de la plupart des scans de ports et des activités malveillantes. Enfin, dans de nombreux cas, vous pouvez simplement couper la connexion vers l'extérieur lorsque vous ne l'utilisez pas. De cette manière, vous réduisez le risque que quelqu'un parvienne à obtenir un accès non autorisé. Vous n'avez qu'à faire <tt>ifdown eth0</tt> (NdT: <tt>ifconfig eth0 down</tt> sur toutes les distributions) sur votre passerelle pour désactiver votre connexion et <tt>ifup eth0</tt> (NdT: <tt>ifconfig eth0 up</tt> sur toutes les distributions) quand vous avez besoin de l'utiliser à nouveau. <sect2>Résumé sur la sécurité <enum> <item>Le seul service que devrait offrir votre firewall est <tt><url url="http://www.openssh.com/" name="openssh"></tt>. Idéalement, vous ne devriez pas placer le DNS sur votre passerelle. Bien que dans la configuration de notre serveur, le DNS soit dessus, encore une fois vous devriez mettre le service du DNS sur une autre machine à l'intérieur du réseau. Si vous décidez de l'y laisser, protégez-le avec le pare-feu pour qu'au moins l'extérieur ne puisse l'utiliser. <item>Tous les autres services (comme le serveur Web) que vous désirez laisser accessibles de l'extérieur devraient être des redirections de port, en utilisant <tt><url url="ftp://ftp.ox.compsoc.org.uk/pub/users/steve/ipsubs/" name="ipportfw"></tt>, vers d'autres machines à l'intérieur de votre réseau. <item>NE LAISSEZ AUCUN service de <tt>/etc/inet.conf</tt> activé ou, plus simplement, ne laissez pas tourner <tt>inet</tt>. Pour ceux qui utilisent RedHat : <tt>chkconfig inet off </tt> <tt>/etc/rc.d/init.d/inet stop</tt> <item>Installez les services internes sur une machine différente (impression, partage de fichiers, base de données, etc.) <item>Installez <tt><url url="http://www.tigerteam.net/linuxgroup/tcplogd/" name="tcplogd"></tt> et envoyez un mail à ceux qui scannent votre machine <em/ eh, ce sont des informations publiques, non ?/. <item>Il existe plusieurs manières d'encapsuler les connexions de VNC, de mail, ftp et d'autres programmes par le biais d'<url url="http://www.openssh.com/" name="OpenSSH">. Ça peut sécuriser un peu plus les choses. <item>Jetez un oeil au projet <url url="http://www.psionic.com/abacus/" name="Abacus"> - le système de prévention des intrusions (The Intrusion Prevention System). </enum> <sect1>Un DNS dynamique A moins que vous n'ayez demandé une adresse IP fixe, RoadRunner vous donne une adresse IP différente à chaque fois que vous vous connectez. Le DNS dynamique vous assigne un alias qui vous permet alors d'accéder à votre machine lorsque vous êtes au bureau ou de permettre à d'autres personnes de savoir où vous êtes. <url url="http://www.dyndns.org" name="Dyndns.org"> peut vous fournir un nom de domaine statique malgré votre adresse IP dynamique, donnant un nom constant à votre passerelle et, pour ceux qui sont sur l'Internet, un moyen facile de se le rappeler. Une fois que vous vous êtes enregistré avec dyndns, un utilitaire appelé <tt><url url="http://www.gandy.dyndns.org/~thomas/ddup.php3" name="ddup"></tt> contacte <tt>dyndns.org</tt> et met à jour l'enregistrement de votre serveur de noms quand votre adresse IP change. Ajoutez <url url="#ddup" name="ce fragment de script shell"> à votre <tt>/etc/rc.d/rc.local</tt> pour mettre à jour, au démarrage, votre enregistrement sur dyndns, mais uniquement si votre adresse IP a changé (dyndns n'apprécie pas que vous changiez votre enregistrement pour n'importe quelle raison). Cela suppose que vous ayez installé <tt>ddup</tt> proprement. J'ai pour habitude de redémarrer la passerelle tous les jours ou tous les deux jours. Je n'ai eu aucun problème avec le changement de l'IP assignée tant que la machine était allumée, bien que ce soit techniquement possible. Si vous avez l'intention de laisser votre passerelle fonctionner pendant plusieurs semaines de suite, il serait préférable que vous ajoutiez une entrée dans le cron qui exécute ce script de temps en temps afin d'être sûr que vous enregistrement chez dynsdns est toujours le même. Cela demandera un peu de travail additionnel. Essayez et voyez ce que vous pouvez faire. <sect1>Commentaires <ENUM> <item>Pour encore plus de sécurité, vous pouvez acheter un répartiteur (<it>switch</it>) avec lequel vous pourrez isoler le trafic intérieur de votre réseau. Ils sont chers mais ça vaut le coup si vous êtes les véritables adeptes du réseau. <item>Vous pouvez faire des choses encore plus complexes une fois que vous avez configuré votre réseau interne. Vous pouvez utiliser <TT>fetchmail</TT> pour récupérer tout le courrier d'un domaine et faire correspondre les adresses électroniques avec vos utilisateurs locaux, utiliser un serveur proxy pour économiser de la bande passante (cela peut ne pas être nécessaire), configurer les connexions cryptées des services du Réseau Privé Virtuel (VPN)) à l'aide de openssh, etc. </ENUM> <IT> <url url="http://tcu-inc.com" name="Mark Nielsen"> travaille comme relieur chez <url url="http://www.genericbooks.com" name="ZING"> et <url url="http://www.tcu-inc.com" name="TCU">. Andrew est un consultant Linux. </IT> <sect1>Fichiers d'exemples (Ce sont juste des exemples de syntaxe, vous devrez probablement modifier les noms de domaines, etc, pour votre propre usage.) (NdT : les commentaires ont été traduits pour une meilleure compréhension des opérations réalisées et pour faire le rapprochement avec le texte. Vous pouvez toujours utiliser les scripts en anglais fournis dans l'article original). <sect2>/etc/rc.d/rc.local (passerelle)<label id="rclocal"> <code> # Configuration du pare-feu - ceci devra être ajouté à la fin du fichier # /etc/rc.d/rc.local afin d'être lancé au démarrage. # Adapté à partir des exemples fournis dans le HowTo IP Masquerading et # le HowTo IPChains. Consultez les documents originaux pour en savoir # plus. Ces exemples vous permettront de configurer un pare-feu # "masqueradé" suffisamment sécurisé. echo "Chargement des modules pour l'IP masquerading ..." # chargement des modules afin de manipuler à l'aide du masquerading # des protocoles parfois délicats de mise en oeuvre mais courants /sbin/depmod -a /sbin/modprobe ip_masq_ftp /sbin/modprobe ip_masq_raudio /sbin/modprobe ip_masq_irc echo "Activation de l'IP forwarding ..." # S'assure que la redirection est activée echo "1" > /proc/sys/net/ipv4/ip_forward # Récupère l'adresse IP dynamique assignée par DHCP, ainsi que le # nom de l'interface externe, puis les sauve dans des variables faciles # à utiliser. extip="`/sbin/ifconfig eth0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`" extint="eth0" # Fait la même chose pour le nom de réseau interne et l'interface intint="eth1" intnet="10.0.0.0/8" echo "Configuration des chaines pare-feu :" echo -n "en entree ..." ############################################################################# # Chaîne d'entrée : remise à zéro et installation de la politique de rejet # par défaut. En fait, la politique par défaut n'est pas pertinente # car il y a une règle globale de refus et de signalement ipchains -F input ipchains -P input REJECT # interface locale, machines locales, aller n'importe où c'est autorisé ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT # interface distante, machines se prétendant locales et masquage d'IP # (IP spoofing), rejetés ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT # interface distante, renvoi de tout ce qui essaie d'ouvrir une # connexion avec nous. Ceci empêche quiconque d'ouvrir des connexions # TCP avec cette machines à partir de l'extérieur. Il s'agit juste # d'un exemple de ce que nous pouvons faire avec IPChains. Ce # n'est pas une mauvaise idée à moins que vous ayez une raison de # laisser les gens se connecter à votre pare-feu. # ipchains -A input ! -f -i $extint -p TCP -y -j REJECT # interface distante, toute source, allant à l'adresse du dhcp de # roadrunner acceptées ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT # l'interface loopback est autorisée ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT # règle globale, toutes les autres entrées sont refusées et signalées ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT echo -n "en sortie ..." ############################################################################# # Chaîne de sortie : remise à zéro et installation de la politique de # rejet par défaut. En fait, la politique par défaut n'est pas # pertinente car il y a une règle globale de refus et de signalement ipchains -F output ipchains -P output REJECT # interface locale, toute source allant sur le réseau local est # acceptée ipchains -A output -i $intint -s 0.0.0.0/0 -d $intnet -j ACCEPT # sortie vers le réseau local sur l'interface distante, routage # engorgé refusée ipchains -A output -i $extint -s 0.0.0.0/0 -d $intnet -l -j REJECT # sortie du réseau local sur l'interface distante, masquerading # engorgé refusé ipchains -A output -i $extint -s $intnet -d 0.0.0.0/0 -l -j REJECT # toutes les autres sorties allant sur l'interface distante sont # valides ipchains -A output -i $extint -s $extip/32 -d 0.0.0.0/0 -j ACCEPT # l'interface loopback est acceptée. ipchains -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT # règle globale, toutes les autres sorties sont refusées et signalées ipchains -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT echo -n "redirection ..." ############################################################################# # Chaîne de redirection : remise à zéro et installation de la politique de # rejet par défaut. En fait, la politique par défaut n'est pas # pertinente car il y a une règle globale de refus et de signalement # ipchains -F forward ipchains -P forward DENY # Masquerade du réseau local sur l'interface locale vers n'importe # où. C'est cette ligne qui fait tout le travail, quasiment tout le # reste dans les lignes de ce fichier n'est là que pour des raisons # de sécurité. ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ # règle globale, toutes les autres redirections sont refusées et # signalées. Dommage qu'il n'y ait pas d'option de signalement dans la # politique de rejet mais elle fait le travail à la place. ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT echo "Terminé." </code> <sect2>/etc/sysconfig/network (passerelle)<label id="networkg"> <code> NETWORKING="yes" FORWARD_IPV4="yes" HOSTNAME="main.local" DOMAINNAME="local" GATEWAY="10.0.0.1" GATEWAYDEV="eth0" </code> <sect2>/etc/sysconfig/network (stations de travail)<label id="networkw"> <code> NETWORKING="yes" FORWARD_IPV4="no" # changez le nom de chaque machine HOSTNAME="w1.local" DOMAINNAME="local" GATEWAY="10.0.0.1" GATEWAYDEV="eth0" </code> <sect2>/etc/hosts (passerelle et stations de travail)<label id="hosts"> <code> 127.0.0.1 localhost localhost.localdomain 10.0.0.1 main main.local 10.0.0.10 w1 w1.local 10.0.0.20 w2 w2.local 10.0.0.30 w3 w3.local </code> <sect2>/etc/resolv.conf (passerelle et stations de travail)<label id="resolvconf"> <code> search local columbus.rr.com nameserver 10.0.0.1 # votre serveur de nom local nameserver 128.146.1.7 # joue le rôle de serveur de # sauvegarde. Ne pas utiliser celui-ci, # c'est uniquement pour les étudiants de # l'OSU. </code> <sect2>/etc/pump.conf (sur la passerelle seulement)<label id="pumpconf"> <code> device eth0 { nodns } </code> <sect2>/etc/named.conf (sur la passerelle seulement)<label id="namedconf"> <code> options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "local"{ type master; file "local.zone"; notify no; }; zone "0.0.10.in-addr.arpa"{ type master; file "local.reverse"; notify no; }; zone "0.0.127.in-addr.arpa"{ type master; file "named.local"; }; </code> <sect2>/var/named/local.zone (sur la passerelle seulement)<label id="varnamed"> <code> @ IN SOA main.local. root.main.local. ( 200001151 ; serial 8 ; refresh 2 ; retry 1 ; expire 1 ; default_ttl ) @ IN NS main.local. localhost IN A 127.0.0.1 main IN A 10.0.0.1 w1 IN A 10.0.0.10 w2 IN A 10.0.0.20 w3 IN A 10.0.0.30 </code> <sect2>/var/named/local.reverse (sur la passerelle seulement) <code> 0.0.10.in-addr.arpa. IN SOA main.local. root.main.local. ( 1997022700 ; serial 28800 ; refresh 14400 ; retry 3600000 ; expire 86400 ; default_ttl ) 1.0.0.10.in-addr.arpa. IN PTR main.local. 10.0.0.10.in-addr.arpa. IN PTR w1.local. 20.0.0.10.in-addr.arpa. IN PTR w2.local. 30.0.0.10.in-addr.apra. IN PTR w3.local. </code> <sect2>A ajouter au fichier /etc/rc.d/rc.local (support dynsdns avec ddup)<label id="ddup"> <code> # Met à jour l'entrée sur dyndns.org avec une ruse contre l'abus. # Cela ne fonctionne pas à moins vous n'ayez un compte sur dyndns et que # le paquetage ddup soit installé. Il faut que certaines variables soient # initialisées dans le script de configuration du pare-feu. Ceci doit donc # être ajouté à la fin du script du pare-feu. # remplacez dummy.hostname par le nom de la machine que vous avez # enregistré. reghost="dummy.hostname" regip="`nslookup $reghost main.dyndns.org | tail -n 3 | grep 'ddress' | awk '{print $2}'`" echo -e "\n Vérification de l'adresse IP sur Dyndns.org pour prévenir les abus :" echo "$reghost enregistrée : $regip" echo -e "$extint a l'adresse IP : $extip \n" if [ "$regip" = "$extip" ]; then echo "L'adresse n'a pas changée. DDUP non lancé."; else echo "L'adresse a changée. Mise à jour de votre enregistrement."; ddup --host $reghost; fi </code> <sect2>/etc/conf.modules (sur la passerelle; seules les lignes 'alias ethx' nous concernent)<label id="confmod"> <code> alias eth0 3c509 alias parport_lowlevel parport_pc pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start alias eth1 tulip </code> Copyright 2000, Mark Nielsen et Andrew Byrd. Paru dans le numéro 51 de la Linux Gazette de Mars 2000. Traduction française de Thierry Hamon. </sect>  </article>