Si vous
utilisez LEAF
Bering, votre configuration Shorewall n'est PAS ce que je publie
-- Je suggère de prendre en considération l'installation de Shorewall
LPR disponible sur le site de shorewall.net avant de poursuivre.1.0 Introduction
2.0 Concepts de Shorewall
3.0 Interfaces Réseaux
4.0 Adresses, Sous/Réseaux et Routage
4.1 Adresses IP
4.2 Sous-réseaux
4.3 Routage
4.4 Protocole de Résolution d'Adresses (ARP)
4.5 RFC 1918
6.0 DNS
7.0 Démarrer et Arrêter le firewall
Ce guide est destiné aux utilisateurs qui configurent Shorewall dans un environnement ou un ensemble d'adresses IP publiques doivent être prises en compte ou à ceux qui souhaitent en savoir plus à propos de Shorewall que ce que contient le guide pour une utilisation Simple Adresse. Parce que le champ d'utilisation est si élevé, le guide vous donnera les indications générales à suivre et vous renseignera sur d'autres ressources si nécessaire.
Si vous
utilisez LEAF
Bering, votre configuration Shorewall n'est PAS ce que je publie
-- Je suggère de prendre en considération l'installation de Shorewall
LPR disponible sur le site de shorewall.net avant de poursuivre.
Shorewall nécessite que le package iproute/iproute2 soit installé (sur RedHat, le package s'appelle iproute). Vous pouvez voir si le package est installé grâce au programme ip sur votre système firewall. En tant que root, vous pouvez utiliser la commande 'which' pour vérifier que le programme est présent:
[root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
Je vous recommande de parcourir en premier le guide pour vous
familiariser avec ce que cela implique puis de le reprendre afin de
modifier votre configuration. Les Points de configuration à changer
sont
précédés du symbole 
.
Si vous
éditez vos fichiers
de configuration sous un système d'exploitation Windows, vous devez
sauvegarder ceux-ci en tant que fichiers formatés Unix si votre éditeur
le permet ou utiliser la commande dos2unix avant de les utiliser avec
Shorewall. Idem si vous transférez vos fichiers par l'intermédiaire du
lecteur de disquette de Windows.
Les fichiers de configuration de Shorewall se trouvent dans le répertoire /etc/shorewall -- pour la plus par des paramétrages, vous avez juste besoin de quelques-uns d'entre eux comme cela est décrit dans le manuel. Des squelettes de fichiers sont créés durant La procédure d'installation de Shorewall.
Comme chaque fichier est abordé, je vous suggère de regarder celui de votre système -- chaque fichier contient des instructions détaillées de configuration et d'autres des entrées par défaut.
Shorewall voit le réseau ou il opère comme composé d'un ensemble de zones. Dans la configuration par défaut, les zones suivantes sont utilisées:
| Nom | Description |
| net | L'Internet |
| loc | Votre réseau local |
| dmz | Zone Démilitarisée |
Les Zones sont définies dans le fichier /etc/shorewall/zones.
Shorewall reconnaît aussi le système firewall comme sa propre zone -
par défaut, le firewall lui-même est connu sous le nom fw
cela peut être modifié dans le fichier /etc/shorewall/shorewall.conf
. Dans ce guide, le nom par défaut (fw) sera utilisé.
Mise à par fw, Shorewall n'attache aucune importance au nom des zones. Les Zones sont entièrement ce que VOUS en faites. Cela veut dire que vous ne devez pas vous attendre à ce que Shorewall fasse quelque chose de spécial "car il s'agit de la zone Internet" ou "car c'est la zone DMZ".
Editez
le fichier
/etc/shorewall/zones et faites tout changement qui s'impose.
Les Règles qui concernent le trafic à autoriser ou à refuser sous exprimés en terme de Zones.
Shorewall est construit sur les possibilités du noyau (kernel) Netfilter. Netfilter implémente une fonction de tracking qui autorise ce qui est souvent désigné comme une inspection déclarée de paquets. Les propriétés de déclaration permettent au firewall d'être définie en terme de connexions plutôt qu'en terme de paquet. Avec Shorewall, vous:
Si les connexions d'un certain type sont autorisés de la zone A au firewall et sont aussi autorisés du firewall à la zone B cela NE VEUT PAS dire que ces connections sont autorisés de la zone A à la zone B. Cela veut plutôt dire que vous avez un proxy qui tourne sur le firewall qui accepte les connections de la zone A et qui ensuite établit ces propres connections du firewall à la zone B.
Pour chaque requête de connexion sur le firewall, la requête est d'abord évalué à travers le fichier /etc/shorewall/rules file. Si aucune règle dans ce fichier ne correspond, la connexion interroge ensuite la première police dans /etc/shorewall/policy qui correspond à la requête et l'applique. Si cette police est REJECT ou DROP, la requête est a nouveau évaluée à travers les règles du fichier /etc/shorewall/common.def.
Le fichier de défaut /etc/shorewall/policy a les polices suivantes:
Zone Source
Zone Destination
Police Niveau de Log Limit:Burst loc net ACCEPT net all DROP info all all REJECT info
La police précédente:
Maintenant, éditez votre
/etc/shorewall/policy et apportez tous les changements que vous
souhaitez.
Pour le reste de ce guide, nous utiliserons le schéma ci-dessous. Bien qu'il ne puisse correspondre à votre propre réseau, il peut être utilisé pour illustrer les aspects importants de la configuration de Shorewall.
Sur ce schéma:
La façon la plus simple pour définir les zones est
d'associer le nom de la zone (définie précédemment dans
/etc/shorewall/zones) avec une interface réseau.
C'est fait dans le fichier /etc/shorewall/interfaces.
Le firewall illustré ci-dessus à trois interfaces. Si la connexion se fait à travers un câble ou un "modem" DSL , l'Interface Externe sera l'adaptateur qui est branché au "Modem" (e.g., eth0) tant que vous ne vous n'utilisez pas le Point-to-Point Protocol over Ethernet (PPPoE) ou le Point-to-PointTunnelingProtocol(PPTP) dans ce cas l'Interface Externe sera de type ppp (e.g., ppp0). Si vous vous connectez à travers un modem classique, votre Interface Externe sera également ppp0. Si vous utilisez ISDN, votre Interface Externe sera ippp0.
Si votre Interface Externe est ppp0 ou
ippp0
alors vous pouvez fixer CLAMPMSS=yes dans
/etc/shorewall/shorewall.conf.
Votre Interface Locale doit être un adaptateur Ethernet (eth0, eth1 or eth2) et doit être connecté à un hub ou un switch. Vos ordinateurs locaux doivent être connectés au même switch (note: Si vous avez une machine unique, vous pouvez connecter le firewall directement à l'ordinateur en utilisant un câble croisé).
Votre Interface DMZ doit aussi être un adaptateur Ethernet (eth0, eth1 or eth2) et doit être connecté à un hub ou un switch. Vos ordinateurs DMZ doivent être connectés au même switch (note: Si vous avez une machine DMZ unique, vous pouvez connecter le firewall directement à l'ordinateur en utilisant un câble croisé).
Ne
pas connecter plus d'une interface au même hub ou switch (sauf pour
tester). Cela ne fonctionne pas comme vous pourriez vous y attendre et
vous terminerez confus en croyant que le réseau ne fonctionne pas
entièrement.
Pour le besoin de ce Guide, nous décidons que:
L'interface externe est eth0.
L'interface locale est eth1.
L'interface DMZ est eth2.
La configuration par défaut de Shorewall ne définit pas
le contenu de chaque zone. Pour définir la précédente configuration en
utilisant le fichier
/etc/shorewall/interfaces file, ce fichier doit contenir:
Zone Interface Broadcast Options net eth0 detect norfc1918 loc eth1 detect dmz eth2 detect
Editer le fichier /etc/shorewall/interfaces et
définissez les interfaces du réseau sur votre firewall et associez
chaque interface avec une zone. Si vous avez une zone qui est
interfacée
avec plus d'une interface, incluez simplement une entrée pour chaque
interface et répéter le nom de zone autant de fois que nécessaire.
Exemple:
Zone Interface Broadcast Options net eth0 detect norfc1918 loc eth1 detect loc eth2 detect dhcp
Si vous avez plus d'une interface pour une zone, vous voudrez probablement une police qui permet le trafic intra-zone:
Source Zone Destination Zone Policy Log Level Limit:Burst loc loc ACCEPT
Vous pouvez définir des zones plus compliquées en
utilisant le fichier /etc/shorewall/hosts
mais dans la plus part des cas, ce n'est pas nécessaire.
Normalement, votre FAI vous assigne des adresses Publiques. Vous pouvez configurer l'interface externe du firewall en utilisant l'une de ces adresses permanentes et vous pouvez décider comment utiliser le reste de vos adresses.
Si vous êtes déjà familier avec l'adressage IP et le routage, vous pouvez aller à la prochaine section.
La discussion suivante aborde tout juste les concepts d'adressage et de routage. Si vous souhaitez approfondir vos connaissances sur ce sujet, je vous recommande vivement l'ouvrage "IP Fundamentals: What Everyone Needs to Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
L'adressage IP version 4 (IPv4) est codé sur 32-bit. La notation w.x.y.z se réfère à une adresse dont le byte d'ordre supérieur est "w", le suivant à pour valeur "x", etc. Si nous prenons l'adresse 192.0.2.14 et l'exprimons en hexadécimal, nous obtenons:
C0.00.02.0E
ou l'exprimons comme un entier de 32-bit
C000020E
Vous entendrez toujours les termes "réseaux de Class A", "réseaux de Class B" et "réseaux de Class C". Au début de l'existence de l'IP, les réseaux ne comportez que trois tailles (il y avait aussi le réseau de Class D mais il étaient utilisés différemment):
Classe A - masque réseau 255.0.0.0, taille = 2 ** 24
Classe B - masque réseau 255.255.0.0, taille = 2 ** 16
Classe C - masque réseau 255.255.255.0, taille = 256
La taille d'un réseau était uniquement déterminé par la valeur du byte de l'ordre supérieur, ainsi vous pouviez regarder une adresse IP et déterminer immédiatement le masque réseau. Le masque réseau est un nombre qui se termine logiquement avec une adresse qui isole le numéro de réseau; le reste de l'adresse est le numéro d'hôte. Par exemple, dans la Classe C l'adresse 192.0.2.14, le numéro hexadécimal du réseau est C00002 et le numéro hexadécimal d'hôte est 0E.
Comme l'Internet se développait, il semblait clair que la classification en adressage 32-bit allait devenir très limité (rapidement, les grandes sociétés et les universités s'étaient assigné leur propre réseau de classe A!). Après quelques faux départs, la technique courante du sous-adressage de ces réseaux en plus petits sous-réseaux évolua; cette technique est consignée par le Classless Inter Domain Routing (CIDR). Aujourd'hui, tous les systèmes avec lesquels vous travaillerez comprennent probablement la notation CIDR. Le réseau basé sur les Classes est du domaine du passé .
Un sous-réseau (aussi appelé subnetwork et subnet) est un ensemble d'adresses IP tel que:
Le nombre d'adresses dans le jeu est un multiple de 2; et
La première adresse dans le jeu est un multiple de la taille du jeu.
La première adresse du sous-réseau est réservée et se réfère à l'adresse du sous-réseau.
La dernière adresse du sous-réseau est réservée comme adresse broadcast du sous-réseau.
Comme vous pouvez voir dans cette définition, dans chacun des sous-réseau de taille n il y a (n - 2) adresses utilisables (adresses qui peuvent être assignées aux hôtes). La première et la dernière adresse du sous-réseau sont respectivement utilisées pour l'adresse du sous-réseau et de l'adresse broadcast du sous-réseau. En conséquence, les petits réseaux sont plus gaspilleur d'adresses IP que les grands.
Comme n est un multiple de deux, nous pouvons facilement calculer le Logarithme Naturel (log2) de n. Pour les sous-réseaux les plus communs, la taille et son logarithme naturel sont donnés dans la table suivante:
n log2 n (32 - log2 n) 8 3 29 16 4 28 32 5 27 64 6 26 128 7 25 256 8 24 512 9 23 1024 10 22 2048 11 21 4096 12 20 8192 13 19 16384 14 18 32768 15 17 65536 16 16
Vous pourrez voir que la table ci-dessus contient aussi une colonne (32 - log2 n). Ce nombre est la Variable de Longueur du Masque de Sous-réseau (VLSM Variable Length Subnet Mask) pour un réseau de taille n. De la table ci-dessus, nous pouvons dériver celle-ci, ce qui est plus facile à utiliser.
Taille du sous-réseau
VLSM Masque sous-réseau
8 /29 255.255.255.248 16 /28 255.255.255.240 32 /27 255.255.255.224 64 /26 255.255.255.192 128 /25 255.255.255.128 256 /24 255.255.255.0 512 /23 255.255.254.0 1024 /22 255.255.252.0 2048 /21 255.255.248.0 4096 /20 255.255.240.0 8192 /19 255.255.224.0 16384 /18 255.255.192.0 32768 /17 255.255.128.0 65536 /16 255.255.0.0 2 ** 24 /8 255.0.0.0
Notez que le VLSM est écrit avec un slash ("/") -- vous pouvez souvent entendre un sous-réseau de taille 64 qui fait référence à un sous-réseau "slash 26" et un de taille 8 faisant référence à un "slash 29".
Le masque de sous-réseau (aussi référencé par son netmask) est simplement un nombre de 32-bit avec le premier bit "VLSM" à un et les autres à zéro. Par exemple, pour un sous-réseau de taille 64, le masque de sous-réseau débute par 26 bits à un:
11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192
Le masque de sous-réseau a la propriété suivante: si vous terminez logiquement le masque de sous-réseau avec une adresse dans le sous-réseau, le résultat est l'adresse du sous-réseau. Attention, si vous terminez logiquement le masque de sous-réseau avec une adresse en dehors du sous-réseau, le résultat n'est PAS l'adresse du sous-réseau. Comme nous l'avons vu précédemment, la propriété du masque de sous-réseau est très importante dans le routage.
Pour un sous-réseau dont l'adresse est a.b.c.d et dont la VLSM est /v, nous notons le sous-réseau par "a.b.c.d/v" en utilisant la Notation CIDR.
Exemple:
Sous-réseau: 10.10.10.0 - 10.10.10.127 Taille Sous-réseau: 128 Adresse Sous-réseau: 10.10.10. Adresse Broadcast: 10.10.10.127 Notation CIDR:
10.10.10.0/25
Il y a deux sous-réseaux dérivés qui doivent être mentionnés; A savoir, le sous-réseau avec un membre et le sous-réseau avec 2 ** 32 membres.
Taille du Sous-réseau
Longueur VLSM
Masque Sous-réseau Notation CIDR 1 32 255.255.255.255 a.b.c.d/32 2 ** 32 0 0.0.0.0 0.0.0.0/0
Ainsi, chaque adresse a.b.c.d peut aussi être écrite a.b.c.d/32 et l'ensemble des adresses possibles est écrit 0.0.0.0/0.
Plus loin dans ce manuel, vous verrez la notation a.b.c.d/v utilisé pour décrire la configuration IP d'une interface réseau (l'utilitaire 'ip' utilise aussi cette syntaxe). cela veut simplement dire que l'interface est configuré avec une adresse ip a.b.c.d et avec le masque de réseau qui correspond à la variable VLSM /v.
Exemple: 192.0.2.65/29
L'interface est configuré avec
l'adresse IP 192.0.2.65 et le masque de réseau 255.255.255.248.
A partir de Shorewall version 1.4.6, /sbin/shorewall
supporte la commande ipcalc qui calcule automatiquement
l'information du [sous]-réseau.
Exemple 1:
Exemple 2ipcalc 10.10.10.0/25
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
ipcalc 10.10.10.0 255.255.255.128
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
L'un des buts des sous-réseaux est la base du routage. Ci-dessous se trouve la table de routage de mon firewall:
[root@gateway root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas
206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3
192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3
192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0
[root@gateway root]#
Le périphérique texas est le tunnel GRE vers un
site peer à Dallas, la zone Texas.
Les trois premières routes sont des routes
hôte puisqu'elles indiquent comment aller vers un hôte unique.
Dans la sortie de 'netstat' cela peut-être vu par le "Genmask" (Masque
sous-réseau) de 255.255.255.255 et le "H" dans la colonne
"Flags".
Les autres sont des routes 'net' car elles indiquent au noyau comment
router des paquets à un sous-réseau. La dernière route est la route par défaut est la passerelle
(gateway) mentionnée est appelé passerelle par défaut (default
gateway).
Quant le noyau essaye d'envoyer un paquet à une adresse IP A, il commence au début de la table de routage et :
A est logiquement terminé avec la valeur du 'Genmask' dans l'entrée de la table.
Le résultat est comparé avec la valeur de la destination 'Destination' dans l'entrée de la table.
Si le résultat et la valeur de la 'Destination' sont identiques, alors:
Si la colonne 'Gateway' est n'est pas nulle, le paquet est envoyé au gateway à travers l'interface nommée dans la colonne 'Iface'.
Sinon, le paquet est directement envoyé à A à travers l'interface nommée dans la colonne 'iface'.
Autrement, les étapes précédentes sont répétées sur l'entrée suivante de la table.
Puisque la route par défaut correspond à toutes les adresses IP (A donne 0.0.0.0 = 0.0.0.0), les paquets qui ne correspondent à aucune des autres entrées de la table de routage sont envoyés au gateway par défaut qui généralement est un routeur vers le FAI.
Voici un exemple. Supposez que vous souhaitez router un paquet à 192.168.1.5. Cette adresse ne correspond à aucune route d'hôte dans la table mais si nous terminons logiquement cette adresse avec 255.255.255.0, le résultat est 192.168.1.0 qui correspond à la l'entrée dans la table:
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
Donc le paquet vers 192.168.1.5 est directement envoyé à travers eth2.
Un des points qui doit être souligné -- tous les paquets sont envoyés en utilisant la table de routage et les réponses ne sont pas exclues de ce principe. Il semble y avoir une croyance de la part des ceux qui croient que les paquets réponses sont comme les saumons et contiennent un code génétique qui leur permet de suivre la route emprunté par les paquets envoyés. Ce n'est pas le cas; La réponse peut prendre un chemin totalement différent de celui de la requête du client -- les routes requête/réponse sont totalement indépendantes.
Quant on envoie des paquets à travers Ethernet, les adresses IP ne sont pas utilisées. Bien que l'adressage Ethernet soit basé sur les adresses Media Access Control (MAC). Chaque périphérique Ethernet à sa propre adresse MAC qui est contenu dans une PROM lors de la fabrication. Vous pouvez obtenir l'adresse MAC grâce à l'utilitaire 'ip':
[root@gateway root]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
[root@gateway root]#
Comme vous pouvez le constater ci-dessus, l'adresse MAC codé sur 6 bytes (48 bits). Une carte MAC est généralement aussi imprimé sur la carte elle-même.
Parce que IP utilise les adresses IP et Ethernet les adresses MAC, un mécanisme est nécessaire pour transcrire une adresse IP en adresse MAC; C'est ce dont est chargé le protocole de résolution d'adresse Address Resolution Protocol (ARP). Voici ARP en action:
[root@gateway root]# tcpdump -nei eth2 arp
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0
2 paquets received by filter
0 paquets dropped by kernel
[root@gateway root]#
Dans cet échange , 192.168.1.254 (MAC 2:0:8:e3:4c:48) veut connaître l'adresse MAC du périphérique avec l'adresse IP 192.168.1.19. Le système ayant cette adresse IP répond que l'adresse MAC du périphérique avec l'adresse IP 192.168.1.19 est 0:6:25:aa:8a:f0.
Afin de rendre disponible les informations d'échange ARP chaque fois qu'un paquet est envoyé, le système maintient un cache ARP des correspondances IP<->MAC. Vous pouvez voir le cache ARP sur votre système (également sur les systèmes Windows) en utilisant la commande 'arp':
[root@gateway root]# arp -na
? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
Les détails de réponse sont le résultat de l'utilisation de l'option 'n' (Windows 'arp' n'accepte pas cette option) qui force le programme 'arp' à la translation de résolution de noms IP->DNS. Si je n'utilise pas cette option, la marque de question aurait été remplacé par le FQDN correspondant à chaque adresse IP. Notez que la dernière information dans la table d'enregistrement est celle que nous voyons en utilisant précédemment tcpdump.
Les adresses IP sont alloués par l'autorité Internet Assigned Number Authority (IANA) qui délégue des allocations géographiques basés sur le Regional Internet Registries (RIRs). Par exemple, les allocations pour les Etats-Unis sont déléguées à American Registry for Internet Numbers (ARIN). Ces RIRs peuvent déléguer à des bureaux nationaux. La plus part d'entre nous ne traite pas avec autorités mais obtienne plutôt leur adresse IP par leur FAI.
Dans la réalité, généralement on ne peut se permettre autant d'adresses IP Publiques que de périphériques à assigner si bien que nous utiliseront des adresses IP Privées. RFC 1918 réserve plusieurs plages d'adresse IP à cet usage:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Les adresses réservées par la RFC 1918 sont parfois appelées non-routable car le routeur passerelle Internet ne renvoit pas les paquets qui ont une adresse de destination RFC-1918. cela est compréhensible car tout le monde peut choisir ces adresses pour un usage privé.
Quant on choisit des adresses de ces plages, il y a deux choses à garder en mémoire:
Comme l'espace des adresses IPv4 s'épuise, de plus en plus d'organisation (comprenant les FAI) commencent à utiliser les adresses RFC 1918 dans leur infrastructures.
Vous ne voulez pas utiliser des adresses IP qui sont utilisés par votre FAI ou une autre organisation avec laquelle vous souhaiter établir une liaison VPN.
C'est pourquoi c'est une bonne idée de vérifier avec votre FAI s'il n'utilise pas (ou ne prévoie pas d'utiliser) des adresses privées avant de décider les adresses que vous allez utiliser.
Le choix de configuration de votre réseau dépend
d'abord du nombre d'adresses Public IP dont vous avez besoin, c'est à
dire du nombre d'entités adressables que vous avez sur votre réseau. En
fonction du nombre d'adresses que vous avez, votre FAI peut servir ce
jeu d'adresses de deux manières:
Routé - Le trafic vers chacune de vos adresses sera routé à travers une unique adresse passerelle. Cela sera généralement fait si votre FAI vous assigne un sous-réseau complet (/29 ou plus). Dans ce cas, vous assignerez l'adresse passerelle comme adresse IP de l'interface externe de votre firewall/router.
Non-routé - Votre FAI vous enverra directement le trafic de chaque adresse directement.
Dans les paragraphes qui suivent, nous étudierons
chaque cas séparément.
Avant de commencer, il y a une chose que vous devez vérifier:
Si vous
utilisez le package Debian, vérifier
svp votre fichier shorewall.conf afin de contrôler les paramètres
suivants; si ce n'est pas juste, appliquer les changements
nécessaires:
Supposons que votre fournisseur d'accès FAI vous a assigné le sous-réseau 192.0.2.64/28 routé à travers 192.0.2.65. cela veut dire que vous avez les adresses IP 192.0.2.64 - 192.0.2.79 et que l'adresse externe de votre firewall est 192.0.2.65. Votre FAI vous a aussi dit que vous pouvez utiliser le masque de réseau 255.255.255.0 (ainsi votre /28 est une partie de /24). Avec ces adresses IP, vous pouvez scinder votre réseau /28 en deux /29 et configurer votre réseau comme l'indique le diagramme suivant.
Ici, la zone démilitarisé DMZ comprend le sous-réseau 192.0.2.64/29 et le réseau Local 192.0.2.72/29. La passerelle par défaut pour les hôtes dans la DMZ pourra être configuré à 192.0.2.66 et la passerelle par défaut pour les hôtes du réseau local pourra être 192.0.2.73.
Notez que cet arrangement est plus gourmand en adresses publiques puisqu'il utilise 192.0.2.64 et 192.0.2.72 pour les adresses du sous-réseau, 192.0.2.71 et 192.0.2.79 pour les adresses broadcast du réseau, de même que 192.0.2.66 et 168.0.2.73 pour les adresses internes que le firewall/routeur. Néanmoins, cela montre comment nous pouvons faire avec un réseau /24 plutôt qu'un /28, l'utilisation de 6 adresses IP parmi les 256 peut être justifié par la simplicité du paramétrage.
Le lecteur astucieux aura remarqué que l'interface externe du firewall/Routeur est actuellement inclus dans le sous-réseau DMZ (192.0.2.64/29). Que se passe-t-il si DMZ 1 (192.0.2.67) essaye de communiquer avec 192.0.2.65? La table de routage sur DMZ 1 peut ressembler à cela:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0
0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0
Cela indique que DMZ 1 enverra une requête ARP "qui-a 192.0.2.65" et aucune interface sur le segment Ethernet DMZ à cette adresse IP. Assez bizarrement, le firewall répondra à la requête avec l'adresse MAC de sa propre Interface DMZ!! DMZ 1 peut alors envoyer des trames Ethernet frames adressées à cette adresse MAC et les trames seront reçues (correctement) par le firewall/routeur.
C'est plutôt une possibilité inattendue d'ARP sur la partie du Noyau Linux qui pousse cet avertissement très tôt dans ce manuel à propos de la connexion de plusieurs interfaces firewall/routeur au même hub ou switch. Quant une requête ARP destiné à une des adresses firewall/routeur est envoyé par un autre système connecté au hub/switch, toutes les interfaces du firewall qui se connectent au hub/switch peuvent répondre! C'est alors une course à la réponse qui "est-là" qui atteindra en premier l'émetteur.
Avec la situation précédente mais non-routé, vous pouvez configurer votre réseau exactement comme décrit ci-dessus avec une condition supplémentaire; spécifiez simplement l'option "proxyarp" sur les trois interfaces du firewall dans le fichier /etc/shorewall/interfaces.
La plus part d'entre nous n'a pas le luxe d'avoir assez d'adresses publiques IP pour configurer notre réseau comme montré dans le précédent exemple (même si la configuration est routé).
Pour le besoin de cette section, admettons que notre FAI nous a assigné les adresses IP 192.0.2.176-180 et nous a dit d'utiliser le masque de réseau 255.255.255.0 et la passerelle par défaut 192.0.2.254.
Clairement, ce jeu d'adresses ne comprend pas de sous-réseau et n'a pas suffisamment d'adresses pour toutes les interfaces de notre réseau. Il y a quatre possibilités qui peuvent être utilisées pour règler ce problème.
Translation d'Adresses Réseau Source : Source Network Address Translation (SNAT).
Translation d'Adresses Réseau Destination : Destination Network Address Translation (DNAT) aussi nommé Port Forwarding.
Proxy ARP.
Translation d''Adresses Réseau : Network Address Translation (NAT) aussi appelé Static NAT.
Souvent une combinaison de ces techniques est utilisée. Chacune d'entre elle sera détaillée dans la section suivante.
Avec SNAT, un segment interne LAN est configuré en utilisant les adresses RFC 1918. Quant un hôte A sur ce segment interne initialise une connexion à l'hôte B sur Internet, le firewall/routeur réécrit les entêtes IP dans la requête pour utiliser une de vos adresses publiques IP en tant qu'adresse source. Quant B répond et que la réponse est reçu par le firewall, le firewall change l'adresse destination par celle RFC 1918 de A et renvoi la réponse à A.
Supposons que vous décidiez d'utiliser SNAT sur votre zone locale et utilisiez l'adresse publique 192.0.2.176 à la fois comme adresse externe du firewall et l'adresse source des requêtes Internet envoyées depuis cette zone.
Le système dans la zone locale pourra être configuré
avec la passerelle par défaut 192.168.201.1 (L'adresse IP de
l'interface local du firewall).
SNAT est configuré dans Shorewall avec le
fichier /etc/shorewall/masq.
INTERFACE SOUS-RESEAU ADDRESSE eth0 192.168.201.0/29 192.0.2.176
Cet exemple utilise la technique normale pour assigner la même adresse publique IP pour l'interface externe du firewall et pour SNAT. Si vous souhaitez utiliser une adresse IP différente, vous pouvez soit utiliser les outils de configuration réseau de votre distribution pour ajouter cette adresse IP ou vous pouvez mettre la variable ADD_SNAT_ALIASES=Yes dans /etc/shorewall/shorewall.conf si bien que Shorewall ajoutera l'adresse pour vous.
Quant SNAT est utilisé, il est impossible pour les hôtes sur Internet d'initialiser une connexion avec un des systèmes puisque ces systèmes n'ont pas d'adresses publiques IP. DNAT fournit une méthode pour autoriser des connexions sélectionnés depuis Internet.
Supposons que votre fille souhaite héberger un
server web sur son système "Local 3". Vous pouvez autoriser les
connexions d'Internet à son serveur en ajoutant l'entrée suivante dans
le fichier /etc/shorewall/rules:
ACTION SOURCE DESTINATION PROTOCOL PORT SOURCE PORT ORIGINAL DESTINATION DNAT net loc:192.168.201.4 tcp www - 192.0.2.176
Si une des amies de votre fille avec une adresse A veut accéder au serveur de votre fille, elle peut se connecter à l'adresse http://192.0.2.176 (l'adresse IP externe de votre firewall) et le firewall réécrira l'adresse IP à 192.168.201.4 (le système de votre fille) et enverra la requête. Quant le serveur de votre fille répond, le firewall réécrira la source de réponse avec 192.0.2.176 et retournera la réponse à A.
Cet exemple l'adresse externe IP du firewall pour DNAT. Vous pouvez utiliser une autre de vos adresses IP publiques, mais Shorewall n'ajoutera pas pour vous cette adresse à l'interface externe du firewall.
Le principe du proxy ARP est:
Un hôte H derrière votre firewall est assigné à une de vos adresses publiques (A), a le même masque de réseau (M) que l'interface externe du firewall.
Le firewall répond à ARP "qui a" demandé A.
Quant H délivre une requête ARP "qui a" pour une adresse du sous -réseau définit par A et M, le firewall répondra (avec l'adresse MAC si le firewall s'interface à H).
Supposons que nous décidons d'utiliser Proxy ARP sur DMZ de notre exemple réseau.
La configuration de Proxy ARP est faite dans le
fichier /etc/shorewall/proxyarp.
ADDRESS INTERFACE EXTERNAL HAVE ROUTE 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No
Parce que la variable HAVE ROUTE contient No,
Shorewall ajoutera les routes d'hôte à travers eth2 à 192.0.2.177 et
192.0.2.178.
Les interfaces ethernet de DMZ 1 et DMZ 2 pourront être
configurées pour avoir les adresses IP apparentes mais devront avoir la
même passerelle par défaut que le firewall lui-même -- nommé
192.0.2.254. En d'autres termes, elles pourront être configurées juste
comme elles devraient être si elles étaient parallèles au firewall
plutôt que derrière lui.
NOTE: Ne pas ajouter le(s) adresse(s) ARP
(192.0.2.177 et 192.0.2.178 dans l'exemple ci-dessus) à
l'interface externe (eth0 dans cet exemple) du firewall.
Un mot de mise en garde à sa place ici. Les FAIs
configure(nt) typiquement leur routeur avec un timeout de cache ARP
élevé. Si vous déplacer un système parallèle à votre firewall derrière
le Proxy ARP du firewall, cela peut mettre des HEURES avant que le
système puisse communiquer avec Internet. Il y a deux choses que vous
pouvez essayer de faire:
tcpdump -nei eth0 icmp
Maintenant depuis 192.0.2.177, utilisez ping vers la passerelle du FAI (que nous supposons être 192.0.2.254):
ping 192.0.2.254
Nous pouvons maintenant observer le résultat de tcpdump:
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
Notez que l'adresse source MAC dans la requête echo est différente de l'adresse de destination dans la réponse echo!! Dans le cas ou 0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du firewall tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En d'autre termes, le cache ARP de la passerelle associe encore 192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall.
Avec static NAT, vous assignez les adresses systèmes RFC 1918 puis établissez une à une l'assignation entre ces adresses et les adresses publiques. Pour les occurrences des connexions sortantes SNAT (Source Network Address Translation) et pour les occurrences des connexions entrantes DNAT (Destination Network Address Translation). Voyons avec l'exemple précédent du serveur web de votre fille tournant sur le système Local 3.
Rappel du paramétrage, le réseau local utilise SNAT et partage l'IP externe du firewall (192.0.2.176) pour les connexions sortantes. cela est obtenu avec l'entrée suivante dans le fichier /etc/shorewall/masq:
INTERFACE SOUS-RESEAU ADDRESSE eth0 192.168.201.0/29 192.0.2.176
Supposons maintenant que vous avez décidé d'allouer à
votre fille sa propre adresse IP (192.0.2.179) pour l'ensemble des
connexions entrantes et sortantes. Vous devrez faire cela en
ajoutant une entrée dans le fichier /etc/shorewall/nat.
EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No
Avec cette entrée active, votre fille a sa propre adresse IP et les deux autres systèmes locaux partagent l'adresse IP du firewall.
Une fois
que la relation entre 192.0.2.179
et192.168.201.4 est établie par l'entrée ci-dessus, ce n'est pas
nécessaire d'utiliser une règle DNAT pour le serveur web de votre fille
-- vous devez simplement utiliser une règle ACCEPT:
ACTION SOURCE DESTINATION PROTOCOL PORT SOURCE PORT ORIGINAL DESTINATION ACCEPT net loc:192.168.201.4 tcp www
Un mot de mise en garde à sa place ici. FAIs
configure(nt) typiquement leur routeur avec un timeout de cache ARP
élevé. Si vous déplacer un système parallèle à votre firewall derrière
le Proxy ARP du firewall, cela peut mettre des HEURES avant que le
système puisse communiquer avec Internet. Il y a deux choses que vous
pouvez essayer de faire:
tcpdump -nei eth0 icmp
Maintenant depuis 192.0.2.177, utilisez ping vers la passerelle du FAI (que nous supposons être 192.0.2.254):
ping 192.0.2.254
Nous pouvons maintenant observer le résultat de tcpdump:
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
Notez que l'adresse source MAC dans la requête echo est différente de l'adresse de destination dans la réponse echo!! Dans le cas ou 0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du firewall tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En d'autre termes, le cache ARP de la passerelle associe encore 192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall.
Avec les
polices par défaut, vos systèmes locaux
(Local 1-3) peuvent accéder à tous les serveurs sur Internet et la DMZ
ne peut accéder à aucun autre hôte (incluant le firewall). Avec les
exceptions des règles règles NAT qui entraîne la
translation d'adresses et permet aux requêtes de connexion translatées
de passer à travers le firewall, la façon d'autoriser des
requêtes
à travers le firewall est d'utiliser des règles ACCEPT.
NOTE: Puisque les colonnes SOURCE PORT et ORIG. DEST. ne sont pas utilisées dans cette section, elle ne sont pas affichées.
Vous souhaiter certainement autoriser ping entre vos zones:
ACTION SOURCE DESTINATION PROTOCOL PORT ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request
En supposant que vous avez des serveurs mail et pop3 actifs sur DMZ 2 et un serveur Web sur DMZ 1. Les règles dont vous avez besoin sont:
ACTION SOURCE DESTINATION PROTOCOL PORT COMMENTS ACCEPT net dmz:192.0.2.178 tcp smtp # Mail depuis Internet
ACCEPT net dmz:192.0.2.178 tcp pop3 # Pop3 depuis Internet ACCEPT loc dmz:192.0.2.178 tcp smtp # Mail depuis le Réseau Local ACCEPT loc dmz:192.0.2.178 tcp pop3 # Pop3 depuis le Réseau Local ACCEPT fw dmz:192.0.2.178 tcp smtp # Mail depuis le firewall ACCEPT dmz:192.0.2.178 net tcp smtp # Mails vers Internet
ACCEPT net dmz:192.0.2.177 tcp http # WWW depuis le Net
ACCEPT net dmz:192.0.2.177 tcp https # HTTP sécurisé depuis le Net ACCEPT loc dmz:192.0.2.177 tcp https # HTTP sécurisé depuis le Réseau Local
Si vous utilisez un serveur DNS publique sur 192.0.2.177, vous devez ajouter les règles suivantes:
ACTION SOURCE DESTINATION PROTOCOL PORT COMMENTS ACCEPT net dmz:192.0.2.177 udp domain # UDP DNS depuis Internet ACCEPT net dmz:192.0.2.177 tcp domain # TCP DNS depuis Internet ACCEPT fw dmz:192.0.2.177 udp domain # UDP DNS depuis le firewall ACCEPT fw dmz:192.0.2.177 tcp domain # TCP DNS depuis le firewall ACCEPT loc dmz:192.0.2.177 udp domain # UDP DNS depuis le Réseau local
ACCEPT loc dmz:192.0.2.177 tcp domain # TCP DNS depuis le Réseau local ACCEPT dmz:192.0.2.177 net udp domain # UDP DNS vers Internet ACCEPT dmz:192.0.2.177 net tcp domain # TCP DNS vers Internet
Vous souhaitez probablement communiquer entre votre firewall et les systèmes DMZ depuis le réseau local -- Je recommande SSH qui, grâce à son utilitaire scp peut aussi faire de la diffusion et de la mise à jour de logiciels.
ACTION SOURCE DESTINATION PROTOCOL PORT COMMENTS ACCEPT loc dmz tcp ssh # SSH vers la DMZ ACCEPT loc fw tcp ssh # SSH vers le firewall
La discussion précédente reflète ma préférence personnelle pour l'utilisation de Proxy ARP associé à mes serveurs de la DMZ et SNAT/NAT pour mes systèmes locaux. Je préfère utiliser NAT seulement dans le cas ou un système qui fait partie d'un sous-réseau RFC 1918 à besoin d'avoir sa propre adresse IP.
Si vous
ne l'avez pas fait, ce peut-être une bonne
idée de parcourir le fichier /etc/shorewall/shorewall.conf
afin de voir si autre chose pourrait être intéressant. Vous pouvez
aussi
regarder aux autres fichiers de configuration que vous n'avez pas
touché
pour un aperçu des autres possibilités de Shorewall.
Dans le cas ou vous n'auriez pas validé les étapes, ci-dessous se trouve un jeu final des fichiers de configuration pour notre réseau exemple. Uniquement ceux qui auraient étés modifiés de la configuration originale sont montrés.
/etc/shorewall/interfaces (Les "options" seront spécifiques aux sites).
Zone Interface Broadcast Options net eth0 detect norfc1918,routefilter loc eth1 detect dmz eth2 detect
La configuration décrit nécessite que votre réseau soit
démarré avant que Shorewall puisse se lancer. Cela ouvre un
lapse de temps durant lequel vous n'avez pas de protection firewall.
Si vous remplacez 'detect' par les valeurs des adresses broadcoast dans
les entrées suivantes, vous pouvez activer Shorewall avant les
interfaces réseau.
Zone Interface Broadcast Options net eth0 192.0.2.255 norfc1918,routefilter loc eth1 192.168.201.7 dmz eth2 192.168.202.7
/etc/shorewall/masq - Sous-réseau Local
INTERFACE SOUS-RESEAU ADDRESS eth0 192.168.201.0/29 192.0.2.176
/etc/shorewall/proxyarp - DMZ
ADDRESS INTERFACE EXTERNAL HAVE ROUTE 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No
/etc/shorewall/nat- Le système de ma fille
EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No
/etc/shorewall/rules
ACTION SOURCE DESTINATION PROTOCOL PORT COMMENTS ACCEPT net dmz:192.0.2.178 tcp smtp # Mail depuis Internet ACCEPT net dmz:192.0.2.178 tcp pop3 # Pop3 depuis Internet ACCEPT loc dmz:192.0.2.178 tcp smtp # Mail depuis le Réseau Local
ACCEPT loc dmz:192.0.2.178 tcp pop3 # Pop3 depuis le Réseau Local ACCEPT fw dmz:192.0.2.178 tcp smtp # Mail depuis le firewall ACCEPT dmz:192.0.2.178 net tcp smtp # Mail vers Internet ACCEPT net dmz:192.0.2.178 tcp http # WWW depuis le Net ACCEPT net dmz:192.0.2.178 tcp https # HTTP sécurisé depuis le Net ACCEPT loc dmz:192.0.2.178 tcp https # HTTP sécurisé depuis le Réseau Local ACCEPT net dmz:192.0.2.177 udp domain # UDP DNS depuis Internet ACCEPT net dmz:192.0.2.177 tcp domain # TCP DNS depuis Internet ACCEPT fw dmz:192.0.2.177 udp domain # UDP DNS depuis le firewall ACCEPT fw dmz:192.0.2.177 tcp domain # TCP DNS depuis le firewall ACCEPT loc dmz:192.0.2.177 udp domain # UDP DNS depuis le Réseau Local ACCEPT loc dmz:192.0.2.177 tcp domain # TCP DNS depuis le Réseau Local ACCEPT dmz:192.0.2.177 net udp domain # UDP DNS vers Internet ACCEPT dmz:192.0.2.177 net tcp domain # TCP DNS vers Internet ACCEPT net dmz icmp echo-request # Ping ACCEPT net loc icmp echo-request # " ACCEPT dmz loc icmp echo-request # " ACCEPT loc dmz icmp echo-request # " ACCEPT loc dmz tcp ssh # SSH vers DMZ ACCEPT loc fw tcp ssh # SSH vers le firewall
En donnant une collection d'adresses RFC 1918 et publiques dans la configuration, cela justifie d'avoir des serveurs DNS interne et externe. Vous pouvez combiner les deux dans un unique serveur BIND 9 utilisant les vues (Views). Si vous n'êtes pas intéressé par les vues BIND 9, vous pouvez allez à la section suivante.
Supposons que votre domain est foobar.net et vous voulez que les deux systèmes DMZ s'appellent www.foobar.net et mail.foobar.net, les trois systèmes locaux "winken.foobar.net, blinken.foobar.net et nod.foobar.net. Vous voulez que le firewall soit connu à l'extérieur sous le nom firewall.foobar.net, son interface vers le réseau local gateway.foobar.net et son interface vers la DMZ dmz.foobar.net. Mettons le serveur DNS sur 192.0.2.177 qui sera aussi connu sous le nom ns1.foobar.net.
Le fichier /etc/named.conf devrait ressembler à cela:
options {
directory "/var/named";
listen-on { 127.0.0.1 ; 192.0.2.177; };
};
logging {
channel xfer-log {
file "/var/log/named/bind-xfer.log";
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};#
# Ceci est la vue présente sur vos systèmes internes.
#
view "internal" {
#
# Les clients suivants peuvent voir le serveur
#
match-clients { 192.168.201.0/29;
192.168.202.0/29;
127.0.0.0/8;
192.0.2.176/32;
192.0.2.178/32;
192.0.2.179/32;
192.0.2.180/32; };
#
# Si le serveur ne peut répondre à la requête, il utilisera des serveurs externes
#
#
recursion yes;
zone "." in {
type hint;
file "int/root.cache";
};
zone "foobar.net" in {
type master;
notify no;
allow-update { none; };
file "int/db.foobar";
};
zone "0.0.127.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.127.0.0";
};
zone "201.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.201";
};
zone "202.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.202";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.176";
};
(or status NAT for that matter)
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.206.124.146.179";
};
};
#
# Ceci est la vue qui sera présente pour le monde extérieur
#
view "external" {
match-clients { any; };
#
# Si nous pouvons répondre à la requéte, nous le disons
#
recursion no;
zone "foobar.net" in {
type master;
notify yes;
allow-update {none; };
allow-transfer { <secondary NS IP>; };
file "ext/db.foobar";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.176";
};
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.179";
};
};
Voici les fichiers de /var/named (ceux qui ne sont pas présents font partis de votre distribution BIND).
db.192.0.2.176 - Zone inverse de l'interface externe du firewall
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
; Filename: db.192.0.2.176
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
; Filename: db.192.0.2.177
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
; Filename: db.192.0.2.178
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
; Filename: db.192.0.2.179
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
int/db.127.0.0 - Zone inverse pour localhost
; ############################################################
; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
; Filename: db.127.0.0
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001092901 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR localhost.foobar.net.
int/db.192.168.201 - Zone inverse pour le réseau local.
cela n'est montré qu'aux clients internes
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
; Filename: db.192.168.201
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
2002032501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR gateway.foobar.net.
2 86400 IN PTR winken.foobar.net.
3 86400 IN PTR blinken.foobar.net.
4 86400 IN PTR nod.foobar.net.
int/db.192.168.202 - Zone inverse de l'interface DMZ du firewall
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
; Filename: db.192.168.202
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
2002032501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR dmz.foobar.net.
int/db.foobar - Forward zone pour l'utilisation des clients internes.
;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2002071501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ); minimum (1 day)
;############################################################
; foobar.net Nameserver Records (NS)
;############################################################
@ 604800 IN NS ns1.foobar.net.
;############################################################
; Foobar.net Office Records (ADDRESS)
;############################################################
localhost 86400 IN A 127.0.0.1
firewall 86400 IN A 192.0.2.176
www 86400 IN A 192.0.2.177
ns1 86400 IN A 192.0.2.177
www 86400 IN A 192.0.2.177
gateway 86400 IN A 192.168.201.1
winken 86400 IN A 192.168.201.2
blinken 86400 IN A 192.168.201.3
nod 86400 IN A 192.168.201.4
ext/db.foobar - Forward zone pour les clients externes
;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2002052901 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ); minimum (1 day)
;############################################################
; Foobar.net Nameserver Records (NS)
;############################################################
@ 86400 IN NS ns1.foobar.net.
@ 86400 IN NS <secondary NS>.
;############################################################
; Foobar.net Foobar Wa Office Records (ADDRESS)
;############################################################
localhost 86400 IN A 127.0.0.1
;
; The firewall itself
;
firewall 86400 IN A 192.0.2.176
;
; The DMZ
;
ns1 86400 IN A 192.0.2.177
www 86400 IN A 192.0.2.177
mail 86400 IN A 192.0.2.178
;
; The Local Network
;
nod 86400 IN A 192.0.2.179
;############################################################
; Current Aliases for foobar.net (CNAME)
;############################################################
;############################################################
; foobar.net MX Records (MAIL EXCHANGER)
;############################################################
foobar.net. 86400 IN A 192.0.2.177
86400 IN MX 0 mail.foobar.net.
86400 IN MX 1 <backup MX>.
La procédure d'installation configure votre système pour que Shorewall démarre au boot du système.
Le firewall est démarré en utilisant la commande "shorewall start" et arrêté avec "shorewall stop". Quand le firewall est arrêté, le routage est actif sur les hôtes qui ont une entrée dans le fichier /etc/shorewall/routestopped. Le firewall actif peut-être relancé grâce à la commande "shorewall restart". Si vous voulez retirer toute trace de Shorewall de votre configuration Netfilter, utilisez "shorewall clear".
Editez
le fichier /etc/shorewall/routestopped
file et ajouter les systèmes qui doivent pouvoir se connecter au
firewall quant il est arrêté.
ATTENTION: Si vous êtes connecté à votre firewall depuis Internet, ne pas exécutez la commande "shorewall stop" tant que vous n'avez pas une entrée active pour l'adresse IP de votre hôte dans le fichier /etc/shorewall/routestopped. Egalement, je ne recommande pas d'utiliser "shorewall restart"; il est préférable d'utiliser une configuration alternative et la tester avec la commande "shorewall try".
Last updated 8/26/2003 - Fabien Demassieux and Tom Eastep
Copyright 2002,
2003 Fabien Demassieux and Thomas M. Eastep