Le HOWTO du Firewalling et des serveurs Proxy <author>David Rudder, drig@execpc.com <date>v0.1, 23 Avril 1995 - traduction Bernard Choppy, bernard.choppy@alias.fdn.fr 5 juillet 1995 <abstract> Ce document est destiné à enseigner les bases de configuration d'un firewall sur un PC sous Linux. L'installation des serveurs Proxy permettant un meilleur accès depuis l'arrière d'un firewall est aussi abordée. </abstract> <toc> <sect>Introduction <p> Les firewalls ont obtenu une grande renommée en tant que <sq>nec plus ultra</sq> de la sécurité sur Internet. Comme de nombreuses choses dont la renommée grandit, une certaine incompréhension s'y est jointe. Ce HOWTO présente les bases de la définition d'un firewall, de sa configuration, des serveurs proxy, de leur configuration, et des applications de cette technologie hors du contexte de la sécurité. <sect1>Réactions <p> Toute réaction est la bienvenue. Je recherche particulièrement celles des utilisateurs d'ordinateurs Macintosh, les informations dont je dispose les concernant étant parcellaires. <em>SIGNALEZ TOUTE INEXACTITUDE DANS CET ARTICLE S'IL VOUS PLAIT !</em> Je suis humain, et sujet aux erreurs. Si vous en trouvez, il est du plus haut intérêt de les corriger. Je tenterai de répondre à tout e-mail, mais je suis occupé, donc ne m'en veuillez pas si ce n'est pas le cas pour le vôtre. Mon adresse e-mail est : <tt/drig@execpc.com/. <sect1>Avertissement <p> Ce document est conçu comme une introduction au fonctionnement des firewalls et des serveurs proxy. Je ne suis, ni ne prétends être un expert ès sécurité. Je suis simplement un individu qui a trop lu et qui apprécie les ordinateurs plus que d'autres. <em>JE NE SUIS RESPONSABLE D'AUCUN DOMMAGE RESULTANT D'ACTIONS FONDEES SUR LE PRESENT DOCUMENT.</em> Considérez que j'écris ceci pour familiariser les gens avec ce sujet, et que je ne suis pas prêt à perdre ma jeunesse dans l'exactitude de ce qui s'y trouve. <sect1>Copyright <p> Sauf mention contraire, les documents Linux HOWTO sont la propriété de leurs auteurs respectifs. Les documents Linux HOWTO peuvent être reproduits et distribués en totalité ou en partie, sur tout support physique ou électronique, tant que cette notice de copyright est présente sur chaque copie. La redistribution commerciale est autorisée et encouragée ; néammoins, l'auteur souhaite être informé de toute distribution de ce genre. Toute traduction, travail dérivé, ou agrégat incorporant tout ou partie d'un ou plusieurs documents Linux HOWTO doit être couvert par ce même copyright. Ce qui veut dire que vous ne pouvez produire un travail dérivé d'un HOWTO et imposer des restrictions supplémentaires concernant sa distribution. Des exceptions à ces règles peuvent être délivrées sous certaines conditions ; Contactez le coordinateur des Linux HOWTO à l'adresse ci-dessous. En bref, nous souhaitons promouvoir la dissémination de cette information à travers autant de canaux que possible. Néammoins, nous souhaitons conserver un copyright sur les documents HOWTO, et être avisés de tout plan de distribution les concernant. Si vous avez des questions, veuillez contacter David Rudder <tt><drig@execpc.com></tt>. <sect1>Reste à faire <p> <itemize> <item>Apprendre comment le faire sur un Macintosh <item>Apprendre différents paquetages TCP/IP Windows <item>Trouver un bon serveur proxy UDP qui fonctionne sous Linux </itemize> <sect>Comprendre les firewalls <p> Firewall est un terme automobile. Dans une voiture, un firewall est une pièce qui sépare le bloc-moteur du compartiment passagers. Il est prévu pour protéger les passagers en cas d'explosion du véhicule. En informatique, un firewall est un composant logique qui protège la partie privée d'un réseau de la partie publique. Le fonctionnement en est le suivant : <enum> <item>Vous prenez un ordinateur qui a des fonctionnalités de routage (comme une machine Linux) <item>Placez-y deux interfaces (c.à.d. ports série, Ethernet, Token Ring, etc.) <item>Empêchez la transmission IP <item>Connectez l'internet sur une interface <item>connectez le réseau protégé sur l'autre interface </enum> Maintenant, vous avez deux réseaux distincts, qui se partagent un ordinateur. L'ordinateur firewall, qui sera nommé <sq>firewall</sq>, peut atteindre à la fois le réseau protégé et internet. Le réseau protégé ne peut atteindre l'internet, ni l'internet toucher le réseau protégé. Pour atteindre l'internet depuis l'intérieur du réseau protégé, on doit se connecter au firewall par telnet, puis utiliser internet à partir de là. Symétriquement, pour entrer dans le réseau protégé, on doit passer d'abord par le firewall. Cela offre un excellent niveau de sécurité contre les attaques en provenance de l'internet. Si quelqu'un veut réaliser une attaque concertée contre le réseau protégé, il doit passer d'abord le firewall, s'en faire un marchepied, puis, plus difficile, attaquer. Si quelqu'un veut attaquer le réseau protégé par une méthode plus classique, comme l'invasion de courrier, ou l'infâme <sq>Internet Worm</sq>, il ne sera pas à même d'atteindre le réseau protégé. Cela réalise une excellente protection. <sect1>Inconvénients des firewalls <p> Le plus gros problème des firewalls réside dans leur forte inhibition de l'accès à l'internet depuis l'intérieur. Fondamentalement, ils réduisent l'usage de l'internet pour ceux qui y auraient eu accès vi un compte en accès entrant. Devoir se loger sur le firewall puis seulement avoir l'accès à l'internet est une sévère restriction. Des programmes comme Netscape, qui nécessitent une connexion internet directe, ne fonctionneront pas depuis l'arrière d'un firewall. Etre incapable de FTPer directement sur votre ordinateur est un autre gros problème, qui nécessite une configuration à deux niveaux internet->firewall->ordinateur protégé. La réponse à ces problèmes réside dans l'utilisation d'un serveur proxy. <sect1>Serveurs proxy <p> Les serveurs proxy sont des constructions qui permettent l'accès direct à l'internet depuis derrière un firewall. Leur fonctionnement réside dans l'ouverture d'une socket sur le serveur, permettant la communication vers l'internet via cette socket. Par exemple, sur mon ordinateur, drig se trouve dans le réseau protégé, et je veux parcourir le Web en utilisant Netscape. Je vais configurer un serveur proxy sur le firewall. Le serveur proxy sera configuré pour permettre aux requêtes depuis mon ordinateur cherchant à accéder au port 80 de se connecter à son port 1080, puis il redirigera toutes les requêtes vers les emplacements idoines. Quiconque a utilisé TIA ou Term a déjà rencontré ce concept. A l'aide de ces deux programmes, vous pouvez rediriger un port. Un ami dispose de TIA configuré pour permettre à quiconque appelant le port 4024 à l'adresse 192.251.139.21 de se connecter à son serveur Web. Le serveur proxy fonctionne ainsi, mais à l'envers. Pour se connecter au port 80 de quelqu'un d'autre, vous devez utiliser le port 1080 (ou tout port que vous aurez configuré pour). L'idée majeure concernant les serveurs proxy est qu'ils sont complètement sûrs, lorsqu'ils sont configurés correctement. Ils ne permettront à personne d'entrer au-travers d'eux. <sect>Configurer tout ça <sect1>Matériel nécessaire <p> Pour notre exemple, l'ordinateur est un 486-DX66, 8 Mo de RAM, 500 Mo de partition Linux, avec une connexion PPP à son fournisseur internet par un modem 14,4 kbps. Cette configuration est votre machine Linux de base. Pour en faire un firewall, nous ajoutons une carte Ethernet NE2000. Il est alors connecté à trois PC sous Windows 3.1 avec Trumpet Winsock et deux Sun sous SunOS 4.1. Cette configuration a été choisie car elle est très classique et qu'elle comporte deux plate-formes qui me sont familières. J'imagine qu'une grande partie des éléments dont je parle est réalisable sur Mac, mais comme je n'utilise pas assez souvent ceux-ci, je ne sais pas vraiment. <sect1>Configurer le logiciel <p> Bien, vous avez une machine Linux connectée au réseau via une ligne PPP à 14,4 kbps. Vous avez ensuite un réseau Ethernet connecté à cette machine Linux et tous les autres ordinateurs. D'abord, vous devez recompiler le noyau Linux avec les options appropriées. A ce point, je vous renvoie au Kernel HOWTO, à l'Ethernet HOWTO et au NET-2 HOWTO. Ensuite, faites un <sq>make config</sq> : <enum> <item>Activez le support du réseau <item>Activez le protocole TCP/IP <item>Désactivez la transmission IP (CONFIG_IP_FORWARD) <item>Activez le Firewalling IP <item>Vraisemblablement, activez la gestion des comptes. Cela semble prudent puisque nous configurons un système de sécurité <item>Activez le support des équipements réseau <item>Nous activons les supports PPP et Ethernet, mais cela dépend de vos interfaces </enum> Ensuite, nous recompilons, réinstallons le noyau et relançons le système. Les interfaces doivent apparaître dans la séquence de démarrage, et tout doit être correct. Sinon, plongez-vous à nouveau dans les autres HOWTO jusqu'à ce que tout fonctionne. <sect1>Configurer les adresses réseau <p> C'est la partie réellement intéressante. Puisque nous ne souhaitons pas laisser l'accès depuis internet, il n'est pas nécessaire d'utiliser des adresses réelles. Une bonne classe C à utiliser est 192.0.2.xxx qui a été conservée à part en tant que domaine de test <sq>à blanc</sq>. Ainsi, personne ne l'utilise, et il n'entrera en conflit avec aucune requête vers l'extérieur. Ainsi, dans cette configuration, une seule adresse IP réelle est nécessaire. Les autres sont libres et n'affecteront pas du tout le réseau. Assignez l'adresse IP réelle au port série utilisé pour PPP. Assignez 192.0.2.1 à la carte Ethernet du firewall. Assignez une adresse de ce dernier domaine à toutes les autres machines du réseau protégé. <sect1>Tester le tout <p> Premièrement, essayez un ping sur l'internet depuis le firewall. J'avais l'habitude d'utiliser nic.ddn.mil comme point de test. C'est toujours un bon test, mais il a prouvé qu'il était moins fiable que je l'espérais. Si cela ne fonctionne pas dès l'abord, essayez un ping sur quelques autres endroits qui ne soient pas connectés à votre réseau local. Si cela ne fonctionne pas, alors votre PPP est mal configuré. Relisez le NET-2 HOWTO, et essayez à nouveau. Maintenant, essayez des ping entre les machines du réseau protégé. Tous les ordinateurs doivent êtres capables d'atteindre tous les autres. Dans le cas contraire, repassez une couche de NET-2 HOWTO et retravaillez encore un peu votre réseau. Puis, chaque machine du réseau protégé doit être capable d'atteindre le firewall par ping. Sinon, retournez une fois de plus en arrière. Rappelez-vous d'essayer sur l'adresse 192.0.2.1 et non sur l'adresse PPP. Ensuite, essayez d'atteindre l'adresse PPP du firewall depuis l'intérieur du réseau protégé. Si vous le pouvez, c'est que vous n'avez pas désactivé la transmission IP et que vous devez recompiler le noyau. Le fait d'assigner le domaine 192.0.2.1 au réseau protégé indique qu'aucun paquet ne doit être transmis à ce domaine d'aucune manière, mais il est plus sûr, en tout cas, d'avoir désactivé la transmission IP malgré tout. Cela vous permet de conserver le contrôle, plutôt que de le laisser entre les mains de votre fournisseur PPP. Finalement, essayez un ping sur chaque machine du réseau depuis le firewall. A cet instant, cela ne devrait poser aucun problème. Maintenant, vous avez une configuration de base de votre firewall. <sect1>Sécuriser le firewall <p> Le firewall n'est pas bon s'il reste ouvert aux attaques. Premièrement, regardez le fichier <tt>/etc/inet.conf</tt>. Ce fichier est ce qu'on appelle un <sq>super-serveur</sq>. Il lance un tas de démons serveurs sur demande. Exemples : <itemize> <item>Telnet <item>Talk <item>FTP <item>Daytime </itemize> Il n'est pas nécessaire de tout désactiver. Faites-le au moins pour netstat, systat, tftp, bootp et finger. Vous pouvez vouloir aussi inhiber telnet et permettre seulement rlogin, ou vice-versa. Pour désactiver un service, placez simplement un <tt/#/ devant. Ensuite, envoyez un signal <tt/SIG-HUP/ au processus inetd, selon la syntaxe suivante : <tt>kill -HUP <pid></tt>, où <tt/pid/ est le numéro du processus inetd. Cela force inetd à relire son fichier de configuration (inetd.conf) et à se relancer. Testez par telnet sur le port 15 du firewall, qui est le port de netstat. Si vous obtenez une réponse de netstat, c'est que vous n'avez pas relancé inetd correctement. <sect>Le serveur proxy <sect1>Installer le serveur proxy <p> Le serveur proxy nécessite un logiciel complémentaire. Vous pouvez l'obtenir sur l'un des nombreux miroirs de : <tt>ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz</tt>. Il ya aussi un exemple de fichier de configuration dans ce répertoire <sq>socks-conf</sq>. <tt/uncompress/ez et dé<tt/tar/ez les fichiers dans un répertoire de votre système, et suivez les instructions pour le confectionner. J'ai eu quelques problèmes pour le réaliser. Vérifiez les <tt/Makefile/s. Certains sont corrects, d'autres, non. <sect1>Configurer le serveur proxy <p> Le programme de connexion nécessite deux fichiers de configuration distincts. L'un pour indiquer les accès autorisés, l'autre pour rediriger les requêtes vers le serveur proxy approprié. Le fichier d'accès doit se trouver sur le serveur. Le fichier de routage peut être placé sur n'importe quelle machine Un*x. Les ordinateurs DOS et, je pense, les Macintosh font leur propre routage. <sect2>Le fichier d'accès <p> Avec <tt/socks4.2 Beta/, le fichier d'accès s'appelle <sq>sockd.conf</sq>. Il doit contenir deux lignes : une ligne d'autorisations et une ligne d'interdiction. Chaque ligne doit avoir trois champs : <itemize> <item>l'identificateur (<sq>permit</sq> ou <sq>deny</sq>) <item>l'adresse IP <item>le modificateur d'adresse </itemize> L'identificateur est soit permit, soit deny. Vous devez avoir une ligne permit et une ligne deny. L'adresse IP contient une adresse à quatre octets en notation classique IP, soit, par exemple, 192.0.2.0. Le modificateur d'adresse est aussi une adresse à quatre octets en notation classique IP, et fonctionne comme un masque réseau. Représentez-vous ce nombre sur 32 bits. Si un bit est à 1, le bit correspondant de l'adresse qu'il contrôle doit concorder avec le bit correspondant du champ de l'adresse IP. Par exemple, si la ligne est : <tscreen><verb> permit 192.0.2.23 255.255.255.255 </verb></tscreen> alors elle autorisera seulement l'adresse dont chaque bit correspond à <tt/192.0.2.23/, soit <tt/192.0.2.23/. Tandis que la ligne : <tscreen><verb> permit 192.0.2.0 255.255.255.0 </verb></tscreen> autorisera toute adresse du groupe <tt/192.0.2.0/ à <tt/192.0.2.255/, soit tout le domaine de la classe C. Il ne faut pas avoir la ligne : <tscreen><verb> permit 192.0.2.0 0.0.0.0 </verb></tscreen> qui autoriserait toute adresse, sans distinction. Bien, d'abord autorisez toute adresse que vous souhaitez, puis interdisez le reste. Pour autoriser quiconque dans le domaine <tt/192.0.2.xxx/, les lignes : <tscreen><verb> permit 192.0.2.0 255.255.255.0 </verb></tscreen> <tscreen><verb> deny 0.0.0.0 0.0.0.0 </verb></tscreen> fonctionneront très bien. Notez le premier <sq>0.0.0.0</sq> dans la ligne <sq>deny</sq>. Avec un modificateur de 0.0.0.0, le champ adresse IP n'a aucune importance. Tous les champs à 0 est la norme, car c'est facile à écrire. On peut utiliser plusieurs lignes de chaque type. Des utilisateurs spécifiques peuvent aussi se voir accorder ou refuser l'accès. Cela est réalisé par l'authentification d'identité. Tous les systèmes ne supportent pas le système ident, y compris Trumpet Winsock, donc nous n'irons pas plus loin en ce qui concerne cela. La documentation de socks est tout à fait adéquate. <sect2>Le fichier de routage <p> Le fichier de routage de socks est bêtement nommé <sq>socks.conf</sq>. Je dis <sq>bêtement</sq>, car il est si proche du nom du fichier d'accès qu'il est aisé de les confondre. Le fichier de routage sert à indiquer aux clients de socks quand il est nécessaire d'utiliser celui-ci. Par exemple, dans notre réseau, 192.0.2.3 ne nécessite pas l'usage de socks pour communiquer avec le firewall 192.0.2.1. Il a une connection directe Ethernet. Il définit 127.0.0.1, le port de bouclage, automatiquement. Evidemment, il n'est pas nécessaire d'utiliser socks pour vous parler à vous-même. Il y a trois entrées : <itemize> <item>deny <item>direct <item>sockd </itemize> Deny indique à socks quand rejeter une requête. Cette entrée a les trois mêmes champs que ceux de sockd.conf : identificateur, adresse et modificateur. Généralement, puisqu'il est aussi manipulé par sockd.file, le fichier d'accès, le champ modificateur est positionné à 0.0.0.0. Si vous voulez vous protéger de tout appel externe, vous pouvez le faire là. L'entrée <sq>direct</sq> indique pour quelles adresses ne pas utiliser socks. Il s'agit des adresses pouvant être atteintes sans le serveur proxy. A nouveau, nous avons les trois champs : identificateur, adresse et modificateur. Dans notre exemple, nous aurions : <tscreen><verb> direct 192.0.2.0 255.255.255.0 </verb></tscreen> Donnant l'accès direct pour toute machine de notre réseau protégé. L'entrée sockd indique à l'ordinateur l'emplacement du démon serveur de socks. La syntaxe est la suivante : <tscreen><verb> sockd @=<liste de serveurs> <adresse IP> <modificateur> </verb></tscreen> Notez l'entrée <tt/@=/. Elle vous permet de configurer les adresses IP de plusieurs serveurs proxy. Dans notre exemple, nous utilisons un seul serveur proxy, mais vous pouvez en avoir plusieurs pour permettre un plus grand trafic et pour assurer une tolérance aux pannes. Les champs adresse IP et modificateur fonctionnent exactement comme dans les autres exemples. Vous spécifiez ainsi où va quelle adresse. <sect1>Travailler avec un serveur proxy <sect2>Unix <p> Pour faire fonctionner vos applications avec un serveur proxy, celles-ci doivent être <sq>sockifiées</sq>. Il vous faudra deux telnet différents : un pour la communication directe, et un autre pour celle avec le serveur proxy. Le paquetage socks contient des indications pour sockifier un programme, ainsi qu'un certain nombre de programmes pré-sockifiés. Si vous utilisez la version sockifiée pour aller directement quelque part, socks basculera automatiquement sur la version directe pour vous. A cause de cela, il nous faut renommer tous les programmes sur notre réseau protégé et les remplacer par leur version sockifiée. <sq>Finger</sq> devient <sq>Finger.orig</sq>, <sq>telnet</sq> devient <sq>telnet.orig</sq>, etc. Vous devez indiquer chacun d'eux à socks à l'aide du fichier <tt>include/socks</tt>. Certains programmes manipulent le routage et la sockification eux-mêmes. Netscape est l'un d'entre eux. Vous pouvez utiliser un serveur proxy sous Netscape en donnant l'adresse du serveur (192.0.2.1 dans le cas qui nous intéresse) dans le champ <tt/SOCK/s sous <tt/Proxies/. Chaque application nécessite au moins un petit coup d'oeil, quelle que soit son attitude vis-à-vis d'un serveur proxy. <sect2>MS Windows avec Trumpet Winsock <p> Trumpet Winsock contient des fonctionnalités de serveur proxy incluses. Dans le menu <sq>setup</sq>, donnez l'adresse IP du serveur, ainsi que celles de tous les ordinateurs directement accessibles. Trumpet se débrouillera alors avec tous les paquets sortants. <sect1>Faire fonctionner le serveur proxy avec les paquets UDP <p> Le paquetage socks fonctionne seulement avec les paquets TCP, pas avec les UDP. Cela le rend quelque peu moins utile. De nombreux programmes très utiles, comme talk et Archie, utilisent UDP. Il existe un paquetage prévu pour être utilisé comme serveur proxy pour les paquets UDP appelé UDPrelay, de Tom Fitzgerald <tt><fitz@wang.com></tt>. Malheureusement, à l'heure où ces lignes sont écrites, il n'est pas compatible avec Linux. <sect1>Inconvénients avec les serveurs proxy <p> Le serveur proxy est, avant tout, un système de sécurité. Son utilisation pour augmenter le nombre d'accès Internet avec un nombre limité d'adresses aura de nombreux inconvénients. Un serveur proxy autorisera un plus grand accès de l'intérieur du réseau protégé vers l'extérieur, mais laissera l'intérieur totalement inaccessible de l'extérieur. Ce qui implique aucun serveur, aucune connexion talk ni Archie, ni e-mail direct vers les ordinateurs de l'intérieur. Ces inconvénients peuvent sembler légers, mais regardez-les sous l'angle suivant : <itemize> <item>Vous avez laissé un document en cours sur votre ordinateur à l'intérieur du réseau protégé. Vous êtes à la maison, et décidez que vous voulez retravailler celui-ci. Vous ne le pouvez pas. Vous ne pouvez atteindre votre ordinateur, car il est derrière le firewall. Vous essayez de vous loger d'abord sur le firewall, mais comme tout le monde a accès au serveur proxy, vous n'avez pas de compte dessus. <item>Votre fille va au collège. Vous souhaitez lui envoyer un e-mail. Vous avez différents choses de caractère privé à discuter, et préfèreriez recevoir directement votre courrier sur votre machine. Vous avez pleine confiance dans votre administrateur réseau, mais, malgré tout, il s'agit de courrier privé. <item>L'impossibilité d'utiliser les paquets UDP représente un gros inconvénient avec les serveurs proxy. Je pense que les fonctionnalités UDP arriveront sous peu. </itemize> De plus, les serveurs proxy sont lents. A cause de la dégradation du rapport information/protocole, n'importe quel autre moyen d'obtenir cet accès sera plus rapide. En deux mots, si vous avez les adresses IP nécessaires, et que la sécurité n'est pas un impératif pour vous, n'utilisez pas le firewall ni les serveurs proxy. Si vous n'avez pas suffisamment d'adresses IP, mais que, de même, la sécurité n'est pas fondamentale, vous pouvez jeter un coup d'oeil aux émulateurs IP, comme Term, Slirp ou TIA. Term est disponible sur <tt>ftp://sunsite.unc.edu</tt>, Slirp est disponible sur <tt>ftp://blitzen.canberra.edu.au/pub/slirp</tt>, et TIA est disponible sur <tt/marketplace.com/. Ces paquetages iront plus vite, permettront de meilleures connexions, et fourniront un accès supérieur à l'intérieur du réseau depuis l'internet. Les serveur proxy sont utiles pour ces réseaux qui comportent de nombreuses machines se connectant au vol à l'internet, avec un setup et peu de travail ensuite. <sect>Configurations avancées <p> Je voudrais aborder une configuration particulière avant de refermer ce document. Celle que j'ai soulignée précédemment suffira probablement pour de nombreux cas. Néammoins, je pense que la situation suivante montrera une configuration plus avancée qui éclaircira certains points d'ombre. S'il vous reste des questions après ce que je viens de décrire, ou simplement que l'adaptabilité des serveurs proxy et des firewalls vous intéresse, lisez encore. <sect1>Un grand réseau avec sécurité renforcée <p> Disons, par exemple, que vous êtes le gourou de la secte de la 23ème Cabale de la Discorde du Milwaukee. Vous souhaitez mettre votre site en réseau. Vous avez cinquante ordinateurs et un sous-réseau de trente-deux adresses IP (sur cinq bits). Vous avez différents niveaux d'accès. Vous dites à vos disciples différentes choses en fonction de leur niveau. Evidemment, vous voudrez protéger certaines parties du réseau des disciples qui n'ont pas acquis un certain niveau. Avertissement : Je ne suis pas membre des Discordiens. Je ne connais pas leur terminologie, et en fait, je m'en fiche. Je les utilise seulement à titre d'exemple. Veuillez envoyer toute remarque acerbe à <tt>(NdT : la destination manque dans le texte original).</tt> Les niveaux sont les suivants : <enum> <item>Le niveau extérieur. C'est celui qui est montré à tout un chacun. En gros, c'est l'histoire et les ragots sur Eris, la divinité de la Discorde, et tout le reste du dogme. <item>Sage. C'est le niveau des gens qui ont passé le niveau extérieur. C'est là que vous leur dites que la discorde et la structure ne font qu'un, et qu'Eris est aussi Jeovah. <item>Adepte. C'est là que se trouve le plan réel. Dans ce niveau sont stockées toutes les informations sur la manière dont la Société des Discordiens prendra le pouvoir sur le monde, à l'aide d'un plan déviationniste, mais humoristique, impactant Newt Gingrich, Wheaties Cereal, O.J. Simpson, et cinq cents cristaux, tous marqués <sq>6,5 MHz</sq> par erreur. </enum> <sect2>La configuration du réseau <p> Les numéros IP sont arrangés ainsi : <itemize> <item>23 des 32 adresses IP sont allouées à 23 machines qui seront accessibles depuis internet. <item>Une adresse IP supplémentaire va à une machine Linux sur ce réseau <item>Une autre va à une autre machine Linux de ce réseau. <item>2 numéros IP vont au routeur <item>5 sont laissées libres, mais recoivent les noms de domaine paul, ringo, george et billy, juste pour compliquer un peu les choses. <item>Les réseaux protégés ont tous deux des adresses 192.0.2.xxx </itemize> Puis, deux réseaux séparés sont construits, chacun dans une pièce différente. Ils sont routés par Ethernet infrarouge pour les rendre complètement invisibles de la pièce extérieure. Par chance, l'Ethernet infrarouge fonctionne tout à fait comme l'Ethernet normal (du moins je crois), donc il nous suffit de les considérer comme normaux. Ces réseaux sont connectés chacun à sa machine Linux avec une adresse IP supplémentaire. Il y a un serveur de fichiers qui relie les deux réseaux protégés. C'est parce que les plans pour prendre le pouvoir sur le monde prennent en compte certains des sages les plus élevés. Le serveur de fichiers a les adresses 192.0.2.17 pour le réseau des sages et 192.0.2.23 pour le réseau des adeptes. Il doit avoir des adresses IP différentes, car il doit avoir deux cartes Ethernet différentes. La transmission IP y est désactivée. La transmission IP est aussi désactivée sur les deux machines Linux. Le routeur ne transmettra pas les paquets destinés à 192.0.2.xxx sauf si on lui demande explicitement de le faire, donc l'internet ne pourra pas entrer. La raison de la désactivation de la transmission IP ici est d'empêcher les paquets du réseau des sages d'atteindre le réseau des adeptes, et vice versa. Le serveur NFS peut aussi être configuré pour présenter différents fichiers aux différents réseaux. Cela peut devenir pratique, et assez astucieux d'utiliser les liens symboliques pour partager les fichiers communs. Cette configuration associée à une autre carte Ethernet peut ainsi permettre l'usage d'un seul serveur de fichiers pour les trois réseaux. <sect2>La configuration proxy <p> Maintenant, puisque les trois niveaux doivent être capables de piloter le réseau pour leurs propres besoins déviationnistes, tous les trois ont besoin d'un accès internet. Le réseau extérieur est connecté directement à celui-ci, donc nous n'avons pas à nous préoccuper d'un serveur proxy ici. Les réseaux des sages et des adeptes sont derrière des firewalls, il est donc nécessaire de leur configurer des serveurs proxy. Les deux réseaux seront configurés de manière similaire. Tous deux ont les mêmes adresses IP assignées. Je vais ajouter quelques paramètres, afin de rendre les choses encore plus intéressantes. <enum> <item>Personne ne peut utiliser le serveur de fichiers pour l'accès internet. Cela exposerait le serveur de fichiers aux virus et autres choses désagréables, et il est très important, donc il est derrière les limites. <item>Nous ne voulons pas donner aux sages l'accès au World Wide Web. Il sont encore en entraînement, et cette puissance de recherche d'informations peut se révéler dangereuse. </enum> Ainsi, le fichier sockd.conf de la machine Linux des sages contiendra cette ligne : <tscreen><verb> deny 192.0.2.17 255.255.255.255 </verb></tscreen> Et sur la machine des adeptes : <tscreen><verb> deny 192.0.2.23 255.255.255.255 </verb></tscreen> Et la machine Linux des sages contiendra cette ligne : <tscreen><verb> deny 0.0.0.0 0.0.0.0 eq 80 </verb></tscreen> Cela indique l'interdiction d'accès pour toutes les machines tentant d'accéder au port 80, le port http. Cela laisse l'accès à tous les autres services, et interdit juste l'accès Web. Ensuite, les deux fichiers auront : <tscreen><verb> permit 192.0.2.0 255.255.255.0 </verb></tscreen> pour permettre à tous les ordinateurs du réseau 192.0.2.xxx d'utiliser ce serveur proxy sauf pour ceux à qui cela a déjà été interdit (ie. le serveur de fichiers et l'accès Web pour le réseau des sages). Le fichier sockd.conf du réseau des sages aura l'allure suivante : <tscreen><verb> deny 192.0.2.17 255.255.255.255 </verb></tscreen> <tscreen><verb> deny 0.0.0.0 0.0.0.0 eq 80 </verb></tscreen> <tscreen><verb> permit 192.0.2.0 255.255.255.0 </verb></tscreen> et le fichier des adeptes aura celle-ci : <tscreen><verb> deny 192.0.2.23 255.255.255.255 </verb></tscreen> <tscreen><verb> permit 192.0.2.0 255.255.255.0 </verb></tscreen> Cela doit tout configurer correctement. Chaque réseau est isolé comme il faut, avec le niveau d'interaction approprié. Chacun peut être heureux. Maintenant, cherchez vos cristaux 6,5 MHz. </article>