Tom Eastep Patrice Vetsel Fabien Demassieux Guy Marcenac 2005-12-3 2002 2003 2004 2005 Thomas M. Eastep Patrice Vetsel Fabien Demassieux Guy Marcenac Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. Notes du traducteur : Le guide initial a été traduit par VETSEL Patrice et la pour la version 2 de Shorewall a été effectuée par Fabien Demassieux. J'ai assuré la révision pour l'adapter à la version 3 de Shorewall. Si vous trouvez des erreurs ou des améliorations à apporter vous pouvez me contacter Guy Marcenac. Cet article s'applique à Shorewall 3.0 et ses versions ultérieures. Si vous utilisez une version plus ancienne de Shorewall, référez-vous à la documention s'applicant à votre version.

Mettre en place un système Linux en tant que firewall pour un petit réseau est une chose assez simple, si vous comprenez les bases et suivez la documentation. Ce guide ne prétend pas vous apprendre tous les rouages de Shorewall. Il se focalise sur ce qui est nécessaire pour configurer Shorewall, dans son utilisation la plus courante: Un système Linux utilisé en tant que firewall/routeur pour un petit réseau local. Une seule adresse IP publique. Si vous avez plus d'une adresse IP, ce n'est pas le guide qui vous convient -- regardez plutôt du coté du Guide de Configuration Shorewall. Une connexion Internet par le biais d'un modem câble, ADSL, ISDN, "Frame Relay", RTC ... Voici un schéma d'une installation typique:

Si vous éditez vos fichiers de configuration sur un système Windows, vous devez les sauver comme des fichiers Unix si votre éditeur supporte cette option sinon vous devez les convertir avec dos2unix avant d'essayer de les utiliser. De la même manière, si vous copiez un fichier de configuration depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall. Windows Version of dos2unix Linux Version of dos2unix

Shorewall a besoin que le package iproute/iproute2 soit installé (avec la distribution RedHat, le package s'appelle iproute). Vous pouvez vérifier si le package est installé par la présence du programme ip sur votre firewall. En tant que root, vous pouvez utiliser la commande which pour cela: [root@gateway root]# which ip /sbin/ip [root@gateway root]# Je recommande de commencer par une lecture complète du guide afin de se familiariser avec les tenants et aboutissants, puis de recommencer et seulement alors d'appliquer vos modifications de configuration.

Les points où des modifications s'imposent sont indiqués par . Les notes de configuration qui sont propres à LEAF/Bering sont marquées avec .

Si vous êtes équipé d'un modem ADSL et que vous utilisez PPTP pour communiquer avec un serveur à travers ce modem, vous devez faire les changements suivants en plus de ceux décrits ci-dessous. ADSL avec PPTP est commun en Europe, notamment en Autriche.

Les fichiers de configuration pour Shorewall sont situés dans le répertoire /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce guide. Note aux utilisateurs de Debian Si vous vous servez du .deb pour installer, vous vous rendrez compte que votre répertoire /etc/shorewall est vide. Ceci est voulu. Les squelettes des fichiers de configuration se trouvent sur votre système dans le répertoire /usr/share/doc/shorewall/default-config. Copiez simplement les fichiers dont vous avez besoin depuis ce répertoire dans /etc/shorewall, puis modifiez ces copies. Remarquez que vous devez copier /usr/share/doc/shorewall/default-config/shorewall.conf et /usr/share/doc/shorewall/default-config/modules dans /etc/shorewall même si vous ne modifiez pas ces fichiers. Après avoir installé Shorewall, vous pourrez trouver les exemples de la manière suivante: Si vous avez intallé en utilisant un RPM, les exemples seront dans le sous-répertoire Samples/two-interfaces/ du répertoire de la documentation de Shorewall. Si vous ne savez pas où se trouve le répertoire de la documentation de Shorewall, vous pouvez trouver les exemples en utilisant cette commande: ~# rpm -ql shorewall | fgrep two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces /usr/share/doc/packages/shorewall/Samples/two-interfaces/masq /usr/share/doc/packages/shorewall/Samples/two-interfaces/policy /usr/share/doc/packages/shorewall/Samples/two-interfaces/routestopped /usr/share/doc/packages/shorewall/Samples/two-interfaces/rules /usr/share/doc/packages/shorewall/Samples/two-interfaces/zones ~# Si vous avez installé depuis le tarball, les exemples sont dans le répertoire Samples/two-interfaces du tarball. Si vous avez installé en utlisant un .deb, les exemples sont dans /usr/share/doc/shorewall/examples/two-interfaces. Au fur et à mesure de la présentation de chaque fichier, je vous suggère de jeter un oeil à ceux physiquement présents sur votre système -- chacun des fichiers contient des instructions de configuration détaillées et des entrées par défaut. Shorewall voit le réseau où il fonctionne, comme étant composé d'un ensemble de zones. Dans une configuration avec deux interfaces, les noms des zones suivantes sont utilisés:#ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 Les zones de Shorewall sont définies dans le fichier /etc/shorewall/zones. Remarquez que Shorewall reconnaît le système de firewall comme sa propre zone. Quand le fichier /etc/shorewall/zones est traité, le nom de la zone firewall est stocké dans la variable d'environnement $FW qui peut être utilisée depuis l'ensemble des autres fichiers de configuration de Shorewall, pour faire référence au firewall lui-même. Les règles à propos du trafic à autoriser et à interdire sont exprimées en utilisant le terme de zones. Vous exprimez votre politique par défaut pour les connexions d'une zone vers une autre zone dans le fichier /etc/shorewall/policy. Vous définissez les exceptions à ces politiques pas défaut dans le fichier /etc/shorewall/rules. Pour chaque connexion demandant à entrer dans le firewall, la requête est en premier lieu vérifiée par rapport au fichier /etc/shorewall/rules. Si aucune règle dans ce fichier ne correspond à la demande de connexion alors la première politique dans le fichier /etc/shorewall/policy qui y correspond sera appliquée. S'il y a une action commune définie pour cette politique dans /etc/shorewall/actions ou dans /usr/share/shorewall/actions.std cette action commune sera exécutée avant que l'action spécifiée dans /etc/shorewall/rules ne soit appliquée. Le fichier /etc/shorewall/policy inclus dans l'archive d'exemple (two-interface) contient les politiques suivantes: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT net all DROP info all all REJECT infoDans le fichier d'exemple (two-interface), la ligne suivante est incluse mais elle est commentée. Si vous voulez que votre firewall puisse avoir un accès complet aux serveurs sur Internet, décommentez la ligne.#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW net ACCEPT Ces politiques vont: Permettre toutes demandes de connexion depuis votre réseau local vers Internet Drop (ignorer) toutes les demandes de connexion depuis l'Internet vers votre firewall ou votre réseau local Accept (accepter) facultativement toutes les demandes de connexion de votre firewall vers l'Internet (si vous avez décommenté la politique additionnelle) Reject (rejeter) toutes les autres requêtes de connexion. Il est important de remarquer que les politiques Shrewall (ainsi que les règles) font référence à des connexions et non pas au flux de paquets. Avec les politiques définies dans le fichier /etc/shorewall/policy présenté plus haut, les connexions sont autorisées de la zone loc vers la zone net même si les connexions ne sont pas permises de la zone loc vers le firewall lui-même. A ce point, éditez votre fichier /etc/shorewall/policy et faites-y les changements que vous désirez.

Le firewall possède deux interfaces réseau. Lorsque la connexion Internet passe par un "modem" cable ou ADSL, l'Interface Externe sera l'adaptateur ethernet qui y est connecté à ce Modem (e.g., eth0). Par contre, si vous vous connectez par Point-to-Point Protocol over Ethernet (PPPoE) ou par Point-to-Point Tunneling Protocol (PPTP) l'interface externe sera une interface ppp (e.g. ppp0). Si vous vous connectez par un simple modem (RTC), votre interface externe sera aussi ppp0. Si vous vous connectez en utilisant l'ISDN, votre interface externe sera ippp0. Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez CLAMPMSS=yes dans le fichier /etc/shorewall/shorewall.conf. Votre Interface Interne (interface vers votre réseau local -> LAN) sera un adaptateur Ethernet (eth1 or eth0) et sera connectée à un hub ou un switch. Vos autres ordinateurs seront connectés à ce même hub/switch (note: Si vous avez un unique ordinateur, vous pouvez connecter le firewall directement en utilisant un câble croisé). Ne connectez pas l'interface interne et externe sur le même hub ou switch, sauf pour tester. Vous pouvez tester ce type de configuration si vous spécifiez l'option arp_filter ou bien l'option arp_ignore dans le fichier /etc/shorewall/interfaces pour toutes les interfaces connectées au hub/switch commun. Utiliser une telle configuration avec un firewall en production est fortement déconseillé. Le fichier de configuration d'exemple pour deux interfaces suppose que votre interface externe est eth0 et que l'interface interne est eth1. Si votre configuration est différente, vous devrez modifier le fichier /etc/shorewall/interfaces en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont spécifiées pour les interfaces. Quelques trucs: Si votre interface vers l'extérieur est ppp0 ou ippp0, vous pouvez remplacer le detect dans la seconde colonne par un - (sans les quotes). Si votre interface vers l'extérieur est ppp0 or ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever dhcp dans la liste des options . Si votre interface est un bridge utilisant l'utilitaire brctl alors vous devez ajouter l'option routeback à la liste des options.

Avant d'aller plus loin, nous devons dire quelques mots au sujet des adresses IP. Normalement, votre Fournisseur d' Accès Internet (FAI) vous assignera une seule adresse IP. Cette adresse peut être assignée par le Dynamic Host Configuration Protocol (DHCP), lors de l'établissement de votre connexion lorsque vous vous connectez (modem standard) ou bien lorsque vous établissez un autre type de connexion PPP (PPPoA, PPPoE, etc.). Dans certains cas , votre fournisseur peut vous assigner une adresse statique IP. Cela signifie que vous devez configurer l'interface externe de votre firewall afin d'utiliser cette adresse de manière permanente. Quelle que soit la façon dont votre adresse externe vous est assignée, elle va être partagée par tous vos systèmes lors de l'accès à Internet. Vous devrez assigner vos propres adresses dans votre réseau local (votre interface interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918 reserve des plages d'adresses IP privées pour utilisation dans les réseau privés: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Avant de lancer Shorewall, il faut regarder l'adresse IP de votre interface externe, et, si elle est dans les plages précédentes, vous devez enlever l'option "norfc1918" dans la ligne concernant l'interface externe dans le fichier /etc/shorewall/interfaces. Vous devrez assigner vos adresses depuis le même sous-réseau (sub-network-subnet). Pour ce faire, nous pouvons considérer un sous-réseau comme étant une plage d'adresses x.y.z.0 - x.y.z.255. Un tel sous-réseau aura un masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 est réservée comme l'adresse de sous-réseau (Subnet Address) et x.y.z.255 est réservée en tant qu'adresse de broadcast (Subnet Broadcast Address). Dans Shorewall, un sous-réseau est décrit en utilisant la notation CIDR (Classless InterDomain Routing) qui consiste en l'adresse du sous-réseau suivie par /24. Le 24 se réfère au nombre consécutif de bits à 1 dans la partie gauche du masque de sous-réseau. Range: 10.10.10.0 - 10.10.10.255 Subnet Address: 10.10.10.0 Broadcast Address: 10.10.10.255 CIDR Notation: 10.10.10.0/24 La convention veut que l'on affecte à l'interface interne du firewall la première adresse utilisable du sous-réseau (10.10.10.1 dans l'exemple précédent) ou bien la dernière adresse utilisable (10.10.10.254). L'un des buts d'un sous-réseau est de permettre à tous les ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils peuvent communiquer directement. Pour communiquer avec des systèmes en dehors du sous-réseau, les ordinateurs envoient des paquets à travers une passerelle (gateway routeur). Vos ordinateurs en local (computer 1 et computer 2 dans le diagramme) doivent être configurés avec leur passerelle par défaut (default gateway) pointant sur l'adresse IP de l'interface interne du firewall. La présentation précédente ne fait qu'effleurer la question des sous réseaux et du routage. Si vous êtes intéressé pour apprendre plus sur l'adressage IP et le routage, je recommande IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0 (link). Le reste de ce guide préjuge que vous avez configuré votre réseau comme montré ci-dessous : La passerelle par défaut pour les ordinateurs 1 et 2 sera 10.10.10.254. Votre FAI (fournisseur d'accès) pourrait assigner une adresse RFC 1918 à votre interface externe. Si cette adresse est le sous-réseau 10.10.10.0/24 alors vous aurez besoin d'un sous-réseau DIFFERENT RFC 1918 pour votre réseau local.

Les adresses réservées par la RFC 1918 sont parfois désignées comme non-routables car les routeurs Internet (backbone) ne font pas circuler les paquets qui ont une adresse de destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une connexion à un serveur par Internet, le firewall doit effectuer une traduction d'adresse réseau ( Network Address Translation NAT). Le firewall réécrit l'adresse source dans le paquet et la remplace par l'adresse de l'interface externe du firewall; en d'autres termes, le firewall fait croire que c'est lui même qui initie la connexion. Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont pour adresse de destination, une adresse réservée par la RFC 1918 ne peuvent pas être routés à travers Internet, donc l'hôte Internet ne peut adresser sa réponse à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il reécrit l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur 1. Sur les systèmes Linux, ce procédé est souvent appelé IP Masquerading mais vous verrez aussi le terme de Source Network Address Translation (SNAT). Shorewall suit la convention utilisée avec Netfilter: Masquerade désigne le cas ou vous laissez votre firewall détecter automatiquement l'adresse de l'interface externe. SNAT désigne le cas où vous spécifiez explicitement l'adresse source des paquets sortant de votre réseau local. Sous Shorewall, autant le Masquerading et le SNAT sont configurés avec des entrées dans le fichier /etc/shorewall/masq. Vous utiliserez normalement le Masquerading si votre adresse IP externe est dynamique, et SNAT si l'adresse IP est statique. Si l'nterface externe de votre firewall est eth0, vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq et changez la première colonne par le nom de votre interface externe, et la seconde colonne par le nom de votre interface interne. Si votre adresse externe IP est statique, vous pouvez la mettre dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de mettre votre adresse IP statique dans la troisième colonne permet un traitement des paquets sortant un peu plus efficace. Si vous utilisez les paquets Debian, vérifiez dans votre fichier de configuration shorewall.conf que la valeur suivante est convenablemblement paramètrée, sinon faites les changements nécessaires: IP_FORWARDING=On

Un de nos buts est, peut être, de faire tourner un ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet de se connecter directement à eux. Il est nécessaire pour ces clients d'adresser leurs demandes de connexion au firewall qui réécrira l'adresse de votre serveur comme adresse de destination, puis fera passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall applique automatiquement un SNAT pour réécrire l'adresse source dans la réponse. Ce procédé est appelé Port Forwarding or Destination Network Address Translation (DNAT). Vous configurez le port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules. La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules est: #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:<server local ip address>[:<server port>] <protocol> <port>Shorewall possede des macros pour de nombreuses applications. Regardez les fichiers /usr/share/shorewall/macro.* pour avoir une liste des macros comprises dans votre version de Shorewall. Les macros simplifient la création de règles DNAT en fournissant le protocole et le(s) port(s) comme on peut le voir dans les exemples suivants: Vous faites tourner un serveur Web sur l'ordinateur 2 et vous voulez faire passer les requêtes TCP sur le port 80 à ce système : #ACTION SOURCE DEST PROTO DEST PORT(S) Web/DNAT net loc:10.10.10.2 Vous faites tourner un serveur FTPsur l'ordinateur 1 et vous voulez rediriger les requêtes TCP entrantes sur le port 21 à ce système: #ACTION SOURCE DEST PROTO DEST PORT(S) FTP/DNAT net loc:10.10.10.1 Concernant FTP, vous aurez aussi besoin d'avoir le support du suivi de connexion et du NAT pour FTP dans votre kernel. Pour les kernels fournis dans une distribution, cela veut dire que les modules ip_conntrack_ftp et ip_nat_ftp doivent être disponibles. Shorewall chargera automatiquement ces modules si ils sont disponibles à leur place habituelle /lib/modules/<kernel version>/kernel/net/ipv4/netfilter. Deux points importants à garder en mémoire : Vous devez tester la règle précédente depuis un client à l'extérieur de votre réseau local (c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1 ou 2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder à votre serveur web et/ou FTP de l'intérieur de votre firewall en utilisant l'adresse de l'interface externe IP, regardez Shorewall FAQ #2. Quelques fournisseurs Internet (FAI) bloquent les requêtes de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous connecter à votre serveur web, essayez la règle suivante et connectez vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 ou w.x.y.z est votre IP externe). #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:10.10.10.2:80 tcp 5000 Maintenant, modifiez /etc/shorewall/rules pour ajouter les règles DNAT dont vous avez besoin. Quand vous testez des règles DNAT telles que celles présentées plus haut, vous devez les tester depuis un client A L'EXTERIEUR DE VOTRE FIREWALL (depuis la zone 'net'). Vous ne pouvez pas tester ces règles de l'intérieur ! Pour des trucs en cas de problème avec le DNAT, allez lire les FAQs 1a et 1b.

Normalement, quand vous vous connectez à votre fournisseur (FAI/ISP), en même temps que vous obtenez votre adresse IP, votre resolver Domain Name Service (DNS) pour le firewall est configuré automatiquement (c.a.d.,le fichier /etc/resolv.conf est mis à jour). Il arrive que votre fournisseur d'accès vous donne une paire d'adresse IP pour les serveurs DNS afin que vous configuriez manuellement vos serveurs de noms primaire et secondaire. Quelle que soit la manière dont le DNS est configuré sur votre firewall, il est de votre responsabilité de configurer le resolver sur vos systèmes internes. Vous pouvez procéder d'une de ces deux façons : Vous pouvez configurer votre système interne pour utiliser les serveurs de noms de votre fournisseur. Si votre fournisseur vous donne les adresses de ses serveurs ou si ces adresses sont disponibles sur son site web, vous pouvez les utiliser pour configurer vos systèmes internes. Si cette information n' est pas disponible, regardez dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement "nameserver" dans ce fichier. Vous pouvez configurer un cache dns Caching Name Server sur votre firewall. Red Hat a un RPM pour serveur cache dns (le RPM à besoin aussi du paquetage bindRPM) et pour les utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez vos systèmes internes pour utiliser le firewall lui même comme étant le seul serveur de nom primaire. Vous utilisez l'adresse IP interne du firewall (10.10.10.254 dans l'exemple précédent) pour l'adresse de serveur de nom. Pour permettre à vos systèmes locaux d'accéder à votre serveur cache de noms, vous devez ouvrir le port 53 (à la fois UDP and TCP) depuis le réseau local vers le firewall; vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules. #ACTION SOURCE DEST PROTO DEST PORT(S) DNS/ACCEPT loc $FW

Les fichiers exemples inclus dans l'archive (two-interface) contiennent les règles suivantes :#ACTION SOURCE DEST PROTO DEST PORT(S) DNS/ACCEPT $FW netCes règles autorisent l'accès DNS à partir de votre firewall et peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy autorisant toutes les connexions depuis le firewall vers Internet. Dans la règle ci-dessus, DNS/ACCEPT est un exemple d'invocation d'une macro. Shorewall offre un certain nombre de macros (voir /usr/share/shorewall/macro.*) et vous pouvez ajouter vos propres macros. Vous n'êtes pas obligés d'utiliser des macros quand vous ajoutez des régles dans le fichier /etc/shorewall/rules; Shorewall démarrera légérement plus rapidement si vous codez directement vos règles que si vous utilisez les macros. La régle vue ci-dessus aurait aussi pu être codée comme cela: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW net udp 53 ACCEPT $FW net tcp 53 Au cas ou Shorewall n'inclue pas de macro pré-définies qui vous convienne, vous pouvez définir une macro vous-même ou bien coder directement les régles appropriées. L'exemple inclue aussi: #ACTION SOURCE DEST PROTO DEST PORT(S) SSH/ACCEPT loc $FWCette régle autorise un serveur SSH sur votre firewall et la connexion à celui-ci depuis votre réseau local. Si vous souhaitez autoriser d'autre connexions de votre firewall vers d'autres systèmes, la syntaxe générale d'une macro est: #ACTION SOURCE DEST PROTO DEST PORT(S) <macro>/ACCEPT $FW <destination zone>La syntaxe générale lorsqu'on utilise pas de macro est:#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW <destination zone> <protocol> <port> Vous voulez ouvrir un serveur Web Server sur votre firewall au réseau local et externe: #ACTION SOURCE DEST PROTO DEST PORT(S) Web/ACCEPT net $FW Web/ACCEPT loc $FWCes deux régles devraient évidemment s'ajouter à celles listées avant dans Vous pouvez configurer un cache dns sur votre firewall. Si vous ne savez pas quel port(s) et protocole(s) une application particulière utilise, vous pouvez regarder ici. Je ne recommande pas d'autoriser telnet vers/de l'Internet parce qu'il utilise du texte en clair (même pour le login!). Si vous voulez un accès shell à votre firewall, utilisez SSH:#ACTION SOURCE DEST PROTO DEST PORT(S) SSH/ACCEPT net $FW Les utilisateurs de Bering pourront ajouter les deux régles suivantes pour rester compatible avec la configuration du firewall Jacques's Shorewall.#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc $FW udp 53 #Allow DNS Cache to work ACCEPT loc $FW tcp 80 #Allow Weblet to work Maintenant, éditez votre fichier de configuration /etc/shorewall/rules pour y ajouter, modifier ou supprimer les autres connexions voulues.

Vous ne pouvez pas tester votre firewall de l'intérieur de votre réseau. Car envoyer des requêtes à l'adresse IP externe de votre firewall ne signifie pas qu'elle seront associées à votre interface externe ou la zone net. Tout trafic généré par le réseau local sera associé à l'interface locale et sera traité comme du trafic de loc->fw. Les adresses IP sont des propriétés des systèmes, pas des interfaces. C'est une erreur de croire que votre firewall est capable de faire suivre (forward) des paquets simplement parce que vous pouvez faire un ping sur l'adresse IP de toutes les interfaces du firewall depuis le réseau local. La seule conclusion que vous puissiez faire dans ce cas est que le lien entre le réseau local et le firewall fonctionne et que vous avez probablement la bonne adresse de passerelle par défaut sur votre système. Toutes les adresses IP configurées sur le firewall sont dans la zone $FW (fw). Si 192.168.1.254 est l'adresse IP de votre interface interne, alors vous pouvez écrire $FW:192.168.1.254 dans une régle mais vous ne devez pas écrire loc:192.168.1.254. C'est aussi un non-sens d'ajouter 192.168.1.254 à la zone loc en utilisant une entrée dans /etc/shorewall/hosts. Les paquets de retour (Reply) ne suivent PAS automatiquement le chemin inverse de la requête d'origine. Tous les paquets sont routés en se référant à la table de routage respective de chaque hôte à chaque étape du trajet. Ce problème se produit en général lorsque on installe un firewall Shorewall en parallèle à une passerelle existante et qu'on essaye d'utiliser DNAT dans Shorewall sans changer la passerelle par défaut sur les systèmes recevant les requêtes transférées (forwarded). Les requêtes passent à travers le firewall Shorewall où l'adresse de destination IP est réécrite, mais la réponse revient par l'ancienne passerelle qui ne modifiera pas le paquet. Shorewall lui-même n'a aucune notion du dedans et du dehors. Ces concepts dépendent de la façon dont Shorewall est configuré.

La procédure d'installation configure votre système pour lancer Shorewall au boot du système, mais le lancement est désactivé, de façon à ce que votre système ne tente pas de lancer Shorewall avant que la configuration ne soit terminée. Une fois que vous en aurez fini avec la configuration du firewall, vous devez éditer /etc/shorewall/shorewall.conf et y mettre STARTUP_ENABLED=Yes. Les utilisateurs des paquets .deb doivent éditer /etc/default/shorewall et mettre startup=1. Le firewall est activé en utilisant la commande shorewall start et arrêté avec shorewall stop. Lorsque le firewall est stoppé, le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un firewall qui tourne peut être relancé en utilisant la commande shorewall restart command. Si vous voulez enlever toutes traces de Shorewall sur votre configuration de Netfilter, utilisez shorewall clear. Les exemples (two-interface) supposent que vous voulez permettre le routage depuis ou vers eth1 (le réseau local) lorsque Shorewall est stoppé. Si votre réseau local n' est pas connecté à eth1 ou si vous voulez permettre l'accès depuis ou vers d'autres hôtes, changez /etc/shorewall/routestopped en conséquence. Si vous êtes connecté à votre firewall depuis Internet, n'essayez pas d'exécuter une commande shorewall stop tant que vous n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous êtes connecté) dans /etc/shorewall/routestopped. De la même manière, je ne vous recommande pas d'utiliser shorewall restart; il est plus intéressant de créer une configuration alternative et de la tester en utilisant la commande "shorewall try"

Je vous recommande vivement de lire la page des Fonctionnalités Générales des Fichiers de Configuration -- elle contient des trucs sur les possibilités de Shorewall pour rendre aisé l'administration de votre firewall Shorewall.

Maintenant que vous avez une configuration deux interfaces qui marche, l'étape suivante logique est d'ajouter un Réseau Sans-fil. La première étape est d'ajouter une carte à votre firewall, soit une carte Sans-fil ou une carte ethernet relié à un Point d'accès Sans-fil. Quant vous ajoutez une carte réseau, il se peut qu'elle ne soit pas détecté comme celle suivant la plus haute interface. Par exemple, si vous avez deux cartes interfaces sur votre système (eth0 and eth1) et que vous ajoutez une troisième qui utilise le même driver qu'une des deux autres, cette troisième carte ne sera pas obligatoirement détecté en tant que eth2; elle peut très bien être détecté en tant que eth0 ou eth1! Vous pouvez faire avec ou intervertir les cartes dans les slots jusqu'à obtenir la valeur eth2. Votre nouveau réseau ressemblera à la figure ci-dessous. La première chose à remarquer est que les ordinateurs sur votre réseau sans-fil seront sur un sous-réseau différent de celui de votre réseau local LAN. Dans l'exemple précédent, nous avons choisi de lui attribuer le réseau 10.10.11.0/24. Les ordinateurs 3 et 4 seront configurés avec une passerelle par défaut dont l'adresse IP sera 10.10.11.254. Ensuite, nous avons choisi d'inclure le réseau sans-fil à la zone local. Puisque Shorewall autorise le trafic intra-zone par défaut, le trafic pourra circuler librement entre le réseau local cablé et le réseau sans-fil. Il n'y a que deux changements à effectuer à la configuration de Shorewall: Une entrée doit être ajouté au fichier d'interfaces /etc/shorewall/interfaces pour l'interface du réseau sans-fil. Si l'interface du réseau sans-fil est wlan0, l'entrée correspondante devrait ressembler à: #ZONE INTERFACE BROADCAST OPTIONS loc wlan0 detect maclist Comme montré dans l'entrée ci-dessus, je recommande d'utiliser l'option maclist pour le segment sans-fil. En ajoutant les entrées pour les ordinateurs 3 et 4 dans le fichier /etc/shorewall/maclist, vous contribuez à vous assurer que vos voisins n'utiliseront pas votre connexion internet. Commencez sans cette option; quant tout fonctionne, alors ajoutez l'option et configurez votre fichier /etc/shorewall/maclist. Vous avez besoin d'ajouter une entrée au fichier /etc/shorewall/masq afin de permettre le trafic de votre réseau sans-fil vers Internet. Si votre interface Internet est eth0 et votre interface sans-fil est wlan0, l'entrée sera: #INTERFACE SUBNET ADDRESS eth0 wlan0 Autre chose. Pour que le réseau Microsoft fonctionne entre réseau filaire et sans-fil, vous avez besoin soit d'un serveur WINS ou d'un PDC. Personnellement, j'utilise Samba configuré en serveur WINS sur mon firewall. Utiliser un serveur WINS sur le firewall nécessite de configurer les régles nécessaires listées dans le document Shorewall/Samba.