Didacticiel sur Iptables, version 1.2.0

La première section de l'exemple rc.firewall.txt est la section de configuration. Elle devra toujours être modifiée car elle contient des informations vitales pour votre configuration. Par exemple, votre adresse IP changera. Le $INET_IP devra toujours être une adresse IP totalement valide, si vous en avez une (sinon regardez de plus près le rc.DHCP.firewall.txt). Également, la variable $INET_IFACE devra pointer vers le matériel utilisé pour votre connexion Internet. Ce peut être eth0, eth1, ppp0, tr0, etc., pour citer quelques noms d'interfaces.

Ce script ne contient aucune option de configuration spéciale pour DHCP ou PPPoE, c'est pourquoi ces sections sont vides. Même chose pour toutes les sections vides, elles sont cependant indiquées, ainsi vous pouvez voir la différence entre les scripts de façon plus efficace. Si vous avez besoin de ces parties, vous pouvez toujours créer un mélange des différents scripts, ou créer le votre entièrement.

La section concernant votre réseau local contient la plupart des options de configuration nécessaires. Par exemple, vous avez besoin de spécifier l'adresse IP d'une interface physique connectée au LAN de même que la plage IP que le LAN utilise et l'interface par laquelle la machine est connectée au réseau.

Ainsi, vous pouvez voir qu'il y a une section pour la configuration de l'hôte local. Nous vous la fournissons, cependant vous n'effecturez à 99% aucun changement dans ces valeurs car on utilise presque toujours l'adresse IP 127.0.0.1 et l'interface nommée lo. Juste après la configuration de l'hôte local, vous trouverez une brève section qui appartient à iptables. Cette section concerne les variables $IPTABLES, qui pointent le script vers l'endroit exact où se trouve l'application iptables. Ceci peut varier un peu, et l'endroit par défaut lors de la compilation à la main est /usr/local/sbin/iptables. Cependant, plusieurs distributions placent l'application à un autre endroit comme /usr/sbin/iptables ou /sbin/iptables.

Premièrement, regardons si les fichiers des dépendances des modules sont à jour en exécutant la commande /sbin/depmod -a. Après ça chargeons les modules nécessaires au script. Évitez toujours de charger des modules dont vous n'avez pas besoin. C'est pour des raisons de sécurité, car il sera plus difficile d'établir des règles supplémentaires de cette façon. Maintenant, par exemple, si vous voulez avoir le support des cibles LOG, REJECT et MASQUERADE et ne les avez pas compilées statiquement dans le noyau, vous devrez charger ces modules comme suit :

/sbin/insmod ipt_LOG
/sbin/insmod ipt_REJECT
/sbin/insmod ipt_MASQUERADE

Dans ces scripts, nous chargeons les modules de force, ce qui peut conduire à des problèmes. Si un module ne se charge pas, ce qui peut dépendre de plusieurs facteurs, il enverra un message d'erreur. Si certains modules les plus basiques ne se chargent pas, l'erreur la plus probable est que le module, ou la fonctionnalité, est compilée statiquement dans le noyau. Pour plus d'information sur ce sujet, lisez la section Problèmes de chargement des modules dans l'annexe Problèmes et questions courants.

Ensuite c'est le module ipt_owner à charger, qui peut, par exemple, être utilisé pour permettre à certains utilisateurs de réaliser certaines connexions, etc. Je n'utilise pas ce module dans l'exemple, mais vous pouvez autoriser seulement root à se connecter en FTP et HTTP à redhat.com et DROP tous les autres. Vous pouvez aussi interdire tous les utilisateurs sauf vous et root de se connecter depuis votre machine à l'Internet. Ça peut être ennuyeux pour les autres, mais vous aurez plus de sécurité par rapport aux attaques où le hacker utilise seulement votre machine comme hôte intermédiaire. Pour plus d'information sur ipt_owner regardez la section Correspondance owner dans le chapitre Création d'une règle.

Vous pouvez aussi charger des modules supplémentaires pour le code de correspondance d'état ici. Tous les modules additionnels au code de correspondance d'état et au code de traçage de connexion sont appelés ip_conntrack_* et ip_nat_*. Les assistants de traçage de connexion sont des modules spéciaux qui indiquent au noyau comment tracer correctement les connexions spécifiques. Sans ces assistants, le noyau ne sait pas quoi chercher quand il essaie de tracer des connexions. Les assistants NAT d'un autre côté, sont des extensions des assistants de traçage de connexion qui indiquent au noyau que rechercher dans des paquets spécifiques et comment traduire ceux-ci dans les connexions en cours. Par exemple, FTP est un protocole complexe par définition, il envoit des informations de connexion dans les données utiles du paquet. Donc, si une de vos machines NATées se connecte à un serveur FTP sur l'Internet, elle enverra sa propre adresse IP du réseau local dans les données utiles du paquet, et indiquera au serveur FTP de se connecter à cette adresse. Étant donné que adresse du réseau locale n'est pas valide en dehors de votre propre réseau, le serveur FTP ne saura pas que faire avec elle et la connexion sera coupée. Les assistants FTP NAT font les traductions qui permettent au serveur FTP de savoir où se connecter. La même chose s'applique pour les transferts de fichiers en DCC dans les chats irc. Créer ce genre de connexions nécessite une adresse IP et des ports à envoyer au protocole IRC, lequel en retour demande que certaines traductions soient faites. Sans ces assistants, FTP et IRC fonctionneront sans doute, cependant, certaines autres choses ne marcheront pas. Par exemple, vous pouvez recevoir des fichiers par DCC, mais pas en envoyer. Ceci est dû à la façon dont DCC démarre une connexion. En premier, vous indiquez au destinataire que vous voulez envoyer un fichier et où il devra se connecter. Sans les assistants, la connexion DCC ressemblera à une tentative du receveur de connecter certains hôtes au propre réseau local de ce receveur. La connexion sera brisée. Cependant, ça peut fonctionner sans défaut, car l'expéditeur vous enverra (probablement) la bonne adresse pour vous connecter.

Si vous rencontrez des problèmes avec le DCC de mIRC et que tout fonctionne correctement avec d'autres clients IRC, lisez la section Problèmes avec le DCC de mIRC dans l'appendice Problèmes et questions courants.

Comme nous l'avons écrit, c'est seulement l'option de chargement des modules qui ajoute le support pour les protocoles FTP et IRC. Pour une explication plus détaillée des modules conntrack et nat, lisez l'annexe Problèmes et questions courants. Il existe aussi les assistants conntrack H.323 dans le patch-o-matic, comme d'autres assistants conntrack et NAT. Pour pouvoir vous en servir, vous devez utiliser le patch-o-matic et compiler votre propre noyau. Pour une explication plus complète, voir le chapitre Préparatifs.

Notez que vous devrez charger ip_nat_irc et ip_nat_ftp si vous voulez que la traduction d'adresse réseau fonctionne correctement avec les protocoles FTP et IRC. Vous aurez également besoin de charger les modules ip_conntrack_irc et ip_conntrack_ftp avant de charger les modules NAT. Ils sont utilisés de la même façon que les modules conntrack, mais ils vous permettront de faire du NAT sur ces deux protocoles.

Ici nous démarrons le IP forwarding par un écho à 1 sur /proc/sys/net/ipv4/ip_forward de cette façon :

echo "1" > /proc/sys/net/ipv4/ip_forward

Il peut être intéressant de réfléchir où et quand nous devons placer l'IP forwarding (transfert IP). Dans ce script, et dans tous les autres de ce didacticiel, nous le plaçons avant de créer les autres filtres IP (i.e., les règles de iptables). Ceci conduit à une brève période de temps pendant laquelle le pare-feu accepte le transfert de tout le trafic, entre une milliseconde et une minute selon le script. Ceci peut permettre à des personnes malicieuses d'essayer de passer le pare-feu. En d'autres termes, cette option doit être activée après la création de toutes les règles, cependant, j'ai choisi de l'activer avant de charger d'autres règles pour des raisons de concordance avec le script.

Dans le cas où vous avez besoin du support d'adresse IP dynamique, par exemple vous utilisez SLIP, PPP ou DHCP, vous devez acitver l'option ip_dynaddr en faisant :

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

S'il y a d'autres options que vous voulez activer vous suivez cette procédure. Il existe d'autres documentations sur ces sujets mais c'est hors du sujet de ce didacticiel. Il existe un bon mais bref document sur le système proc disponible dans le noyau, également disponible dans l'annexe Autres ressources et liens. L'annexe Autres ressources et liens est généralement un bon endroit pour rechercher l'information que vous ne trouvez pas ici.

Le script rc.firewall.txt, et tous les autres scripts de ce didacticiel, contient une petite section sur la mise en place des proc qui ne sont pas requises. Ce peut être là qu'il faut regarder quand quelque chose ne fonctionne pas comme vous le voulez, cependant, ne changez pas les valeurs avant de savoir ce qu'elles représentent.

Cette section décrit brièvement mes choix en fonction des scripts spécifiques du rc.firewall.txt. Certains des chemins d'accès indiqués ici peuvent être faux selon un ou un autre aspect. Aussi, cette section jette en bref regard en arrière sur le chapitre Traversée des tables et des chaînes. Nous nous souviendrons de la façon dont les tables et les chaînes sont traversées dans un exemple réel.

J'ai modifié toutes les différentes chaînes utilisateur de façon à économiser le plus possible de CPU, mais en même temps en mettant l'accent principal sur la sécurité et la fiabilité. Au lieu de laisser un paquet TCP traverser les règles ICMP, UDP et TCP, j'ai simplement apparié tous les paquets TCP et laissé ces paquets TCP traverser les chaînes spécifiées par l'utilisateur. De cette façon nous ne consommons pas trop de temps système. L'image ci-dessous tente d'expliquer comment un paquet entrant traverse Netfilter. Avec ces images et explications, j'essaie de clarifier les buts de ce script. Nous ne verrons cependant aucun détail spécifique, ceci sera fait plus loin dans le chapitre. C'est un image plutôt triviale en comparaison de celle du chapitre Traversée des tables et des chaînes où nous parlons de la traversée complète des tables et des chaînes en profondeur.

Nous fondant sur cette image, clarifions nos buts. C'est un exemple complet de script basé sur la supposition que notre scenario contient un réseau local, un pare-feu et une connexion Internet connectée à ce pare-feu. Cet exemple est aussi basé sur la supposition que nous avons une adresse IP statique vers l'Internet (à l'opposé de DHCP, PPP, SLIP et autres). Dans ce cas, nous voulons autoriser le pare-feu à agir comme serveur pour certains services sur l'Internet, et nous faisons pleinement confiance à notre réseau local et donc ne bloquons pas le trafic provenant de celui-ci. Pour faire ceci, nous plaçons les stratégies des chaînes par défaut à DROP. Ce qui effectivement bloquera toutes les connexions et tous les paquets que nous n'avons pas explicitement autorisés dans notre réseau ou notre pare-feu.

Dans le cas de ce scenario, nous laisserons notre réseau local se connecter à l'Internet. Comme nous avons pleine confiance dans notre réseau, nous permettons toute sorte de trafic depuis ce réseau local vers l'Internet. Cependant, l'Internet n'est pas un réseau de confiance et donc nous voulons bloquer les connexions venant de celui-ci et allant vers notre réseau. En fonction de ces suppositions, regardons ce que nous devons faire et ne pas faire.

En priorité, nous voulons que notre réseau local puisse se connecter à l'Internet, bien sûr. Pour cela, nous devons NATer tous les paquets car aucune de nos machines locales n'a d'adresse IP routable. Tout ceci est effectué dans la chaîne POSTROUTING, créée en dernier dans le script. Nous devons aussi faire du filtrage dans la chaîne FORWARD car nous devons permettre un accès complet à notre réseau local. Nous avons confiance dans notre réseau local, et pour ça nous autorisons tout le trafic provenant de celui-ci et allant vers l'Internet. Comme personne sur l'Internet ne sera autorisé à se connecter aux ordinateurs de notre réseau local, nous bloquerons tout le trafic provenant de l'Internet vers le réseau local sauf les connexions déjà établies, qui autorisent le trafic en réponse.

Comme pour notre pare-feu, nous n'avons peut-être pas trop de moyens, et ne voulons offrir que quelques services sur l'Internet. Nous avons décidé de permettre les accès HTTP, FTP, SSH et IDENTD à notre pare-feu. Tous ces protocoles sont disponibles dans le pare-feu, et seront donc autorisés par la chaîne INPUT, ainsi que nous autoriserons le trafic en retour à travers la chaîne OUTPUT. Cependant, nous avons pleinement confiance dans notre réseau local, et le matériel local et l'adresse IP sont également sûrs. Donc, nous pouvons ajouter des règles spéciales pour permettre le trafic depuis le réseau local comme depuis la boucle locale. De même, nous n'autoriserons pas certains paquets spécifiques, ni certaines plages d'adresses IP à joindre le pare-feu depuis l'Internet. Par exemple, la plage d'adresses IP 10.0.0.0/8 est réservée à notre réseau local et donc nous ne voulons pas autoriser les paquets provenant d'une de ces adresses car ils risqueraient à 99% une usurpation d'adresse. Cependant, avant d'implémenter ceci, nous devons noter que certains fournisseurs d'accès Internet (FAI) utilisent ces plages d'adresses IP dans leur propre réseau. Pour plus de détails, voir le chapitre Problèmes et questions courants.

Comme nous avons un serveur FTP actif, et que nous voulons traverser certaines règles, nous ajoutons une règle qui permet le trafic établi et relié au début de la chaîne INPUT. Pour la même raison, nous divisons les règles en sous-chaînes. En faisant ça, nos paquets n'auront besoin de traverser que quelques chaînes. En traversant moins de chaînes, nous consommons moins de temps pour chaque paquet, et réduisons la latence dans le réseau.

Dans ce script, nous choisissons de diviser les différents paquets par leur famille de protocole, par exemple TCP, UDP ou ICMP. Tous les paquets TCP traversent une chaîne spécifique nommée tcp_packets, qui contient les règles pour tous les ports et protocoles TCP que nous voulons autoriser. Ainsi, si nous voulons faire certaines vérifications supplémentaires sur les paquets TCP, nous devrons créer une sous-chaîne pour tous les paquets acceptés qui utilisent des numéros de port valides vers le pare-feu. Cette chaîne que nous choisissons d'appeler chaîne autorisée, contiendra certaines vérifications supplémentaires avant d'accepter le paquet. Pour les paquets ICMP, ils traversent la chaîne icmp_packets. Quand nous avons décidé de créer cette chaîne, nous n'avons pas vu le besoin de vérifications supplémentaires avant d'accepter les paquets s'ils sont conformes au code ICMP, et donc les acceptons directement. Enfin, nous avons les paquets UDP qui doivent être distribués avec. Nous envoyons ces paquets vers la chaîne udp_packets qui traite tous les paquets UDP entrants. Tous les paquets UDP entrants doivent être envoyés à cette chaîne, et s'ils sont d'un type autorisé nous les acceptons immédiatement sans vérification supplémentaire.

Comme nous sommes sur un réseau relativement petit, cette machine étant également utilisée comme station de travail secondaire, nous voulons autoriser certains protocoles spécifiques à joindre le pare-feu, comme speak freely et ICQ.

Enfin, nous avons la chaîne OUTPUT. Comme nous faisons confiance à notre pare-feu, nous autorisons tout le trafic quittant celui-ci. Nous ne bloquons aucun utilisateur, ni aucun protocole spécifique. Cependant, nous ne voulons pas que des personnes utilisent cette machine pour usurper les paquets quittant le pare-feu, et donc autorisons uniquement le trafic depuis les adresses assignées au pare-feu. Nous implémenterons ceci en ajoutant des règles qui ACCEPT tous les paquets quittant le pare-feu lorsque ceux-ci proviennent des adresses assignées, s'ils ne sont pas supprimés par défaut dans la chaîne OUTPUT.

Très tôt dans le processus de création de nos règles, nous avons placé nos stratégies par défaut. Nous implémentons nos stratégies par défaut dans les différentes chaînes avec une commande très simple, comme décrite ci-dessous :

iptables [-P {chain} {policy}]

La stratégie par défaut est utilisée chaque fois que les paquets n'apparient pas une règle dans une chaîne. Par exemple, nous avons un paquet qui n'apparie aucune règle dans notre table de règles. Si ça se produit, nous devons décider quoi faire du paquet en question, et c'est là qu'intervient la stratégie par défaut. Elle est utilisée sur tous les paquets qui ne s'apparient avec aucune règle dans notre table de règles.

Faîtes attention avec la stratégie par défaut que vous placez sur des chaînes dans d'autres tables, car elle n'est pas conçue pour le filtrage, et peut provoquer des comportements étranges.

Maintenant que nous avons une bonne image de ce que nous voulons faire avec ce pare-feu, voyons l'implémentation de la table de règles. C'est le moment de faire attention à l'implémentation des règles et des chaînes que nous voulons créer, de même que les tables de règles dans les chaînes.

Après cela, nous créons les différentes chaînes spéciales que nous voulons utiliser avec la commande -N. Les nouvelles chaînes sont créées et implémentées sans aucune règle à l'intérieur. Les chaînes que nous utilisons sont, comme précédemment décrit, icmp_packets, tcp_packets, udp_packets et les chaînes autorisées, qui sont utilisées par la chaîne tcp_packets. Les paquets entrants sur $INET_IFACE, de type ICMP, seront redirigés vers la chaîne icmp_packets. Les paquets de type TCP, seront redirigés vers la chaîne tcp_packets et les paquets entrants de type UDP venant de $INET_IFACE iront vers la chaîne udp_packets. Tout ceci sera expliqué en détail dans la section Chaîne INPUT ci-dessous. Créer une chaîne est tout à fait simple et consiste seulement en une déclaration de chaîne comme ceci :

iptables [-N chain]

Dans les sections suivantes nous verrons les chaînes définies par l'utilisateur que nous avons créées. Regardons à quoi elles ressemblent, quelles règles elles contiennent et ce que nous pouvons faire avec.

XVII-B-6-a. La chaîne bad_tcp_packets▲

XVII-B-6-b. La chaîne autorisée▲

XVII-B-6-c. La chaîne TCP▲

XVII-B-6-d. La chaîne UDP▲

XVII-B-6-e. La chaîne ICMP▲

La chaîne INPUT, utilise la plupart du temps les autres chaînes pour faire le plus gros du travail. De cette façon nous n'avons pas trop de charge provenant d'iptables, et il fonctionnera mieux sur les machines lentes. Ceci est fait en vérifiant les détails spécifiques qui peuvent être identiques pour beaucoup de paquets différents, en ensuite en envoyant ces paquets dans les chaînes spécifiées par l'utilisateur. En faisant ça, nous réduisons notre table de règles qui ne contient que le nécessaire pour le transit des paquets, et donc le pare-feu aura moins de charge pour filtrer les paquets.

En premier nous vérifions les mauvais paquets. C'est réalisé en envoyant tous les paquets TCP vers la chaîne bad_packets. Cette chaîne contient des règles qui vérifient les paquets mal formés ou d'autres anomalies. Pour une explication complète sur la chaîne bad_tcp_packets, regardez dans la section La chaîne bad_tcp_packets de ce chapitre.

À ce niveau nous recherchons le trafic généré par les réseaux de confiance. Ce qui inclut l'adaptateur réseau et tout le trafic prevenant de celui-ci, ainsi que le trafic entrant et sortant de la boucle locale (loopback), avec toutes les adresses IP assignées (toutes les adresses y compris notre adresse IP Internet). Ainsi, nous avons choisi de placer la règle qui autorise l'activité du LAN vers le pare-feu en premier, car notre réseau local génère plus de trafic de la connexion Internet. Ceci permet d'avoir moins de charge système pour apparier chaque paquet avec chaque règle, et c'est toujours une bonne idée de regarder quel type de trafic traverse principalement le pare-feu. En faisant cela nous rendons les règles plus efficaces, avec moins de charge sur le pare-feu et moins de congestion sur notre réseau.

Avant de nous attaquer aux règles "réelles" dans lesquelles nous déciderons quoi autoriser depuis l'Internet, nous avons placé une règle pour réduire la charge système. C'est une règle d'état qui autorise tous les paquets d'un flux ESTABLISHED ou RELATED vers l'adresse IP Internet. Cette règle a une équivalence dans la chaîne autorisée, qui est redondante à celle-ci. Cependant, la règle --state ESTABLISHED,RELATED dans la chaîne autorisée a été conservée pour plusieurs raisons, vous pouvez donc copier-coller cette fonction.

Après ça, nous apparions tous les paquets TCP de la chaîne INPUT qui arrivent dans l'interface $INET_IFACE, et les envoyons vers tcp_packets, comme précédemment décrit. Nous faisons maintenant la même chose pour les paquets UDP sur l'interface $INET_IFACE et les envoyons vers la chaîne udp_packets, ensuite tous les paquets ICMP sont envoyés vers la chaîne icmp_packets. Normalement, un pare-feu devrait être plus difficile à attaquer par des paquets TCP, que par des paquets UDP et ICMP. C'est le cas normal, mais souvenez vous, ce peut être différent pour vous. La même chose peut être observée ici, comme avec les règles réseau spécifiques. Lesquelles génèrent le plus de trafic ? Sur les réseaux générant un important volume de données, c'est une absolue nécessité de vérifier cela, car une machine de type Pentium III peut être saturée par une simple table de règles contenant 100 règles avec une carte réseau ethernet 100 Mbit fonctionnant à sa pleine capacité, si la table de règles est mal écrite. Il est important de regarder ça de près.

Ici nous avons une règle supplémentaire, qui est par défaut désactivée, et qui peut être utilisée pour évitez une journalisation excessive dans le cas où nous avons un réseau Microsoft à l'extérieur de notre pare-feu Linux. Les clients Microsoft ont la mauvaise habitude d'envoyer des tonnes de packets multicast vers la plage 224.0.0.0/8, donc nous avons la possibilité de bloquer ces paquets ici. Il existe deux autres règles faisant à peu près la même chose sur la chaîne udp_packets décrite dans La chaîne UDP.

Avant de tester la stratégie par défaut de la chaîne INPUT, nous la journalisons pour savoir s'il existe des problèmes/bugs. Ce peut être soit un paquet que nous ne voulons pas autoriser, soit une chose qui peut se révéler néfaste pour nous, ou finalement un problème dans notre pare-feu qui n'autorise pas le trafic qui devrait être autorisé. Nous ne journalisons pas plus de 3 paquets par minute car nous ne voulons pas surcharger nos journaux, ainsi nous plaçons un préfixe pour toutes les entrées de journalisation et savons donc d'où ils proviennent.

Tout ce qui n'a pas été capturé sera DROPé par la stratégie par défaut de la chaîne INPUT. Voir la section Mise en place des actions par défaut dans ce chapitre.

La chaîne FORWARD contient quelques règles dans notre scenario. Nous avons une seule règle qui envoie tous les paquets vers la chaîne bad_tcp_packets, laquelle est également utilisée dans la chaîne INPUT comme décrit précédemment. La chaîne bad_tcp_packets est construite de façon qu'elle puisse être utilisée dans plusieurs chaînes, sans regarder quel paquet la traverse.

Après cette vérification des mauvais paquets TCP, nous avons les règles principales dans la chaîne FORWARD. La première règle autorise tout le trafic depuis notre $LAN_IFACE vers n'importe quelle autre interface librement, sans restrictions. En d'autres termes, cette règle autorise tout le trafic depuis le LAN vers l'Internet. La seconde règle autorise le trafic en retour ESTABLISHED et RELATED à travers le pare-feu. Ce qui veut dire qu'elle autorise les connexions initiées par notre réseau local à circuler librement dans le LAN. Ces règles sont nécessaires pour que notre réseau local puisse accéder à l'Internet, car la stratégie par défaut de la chaîne FORWARD est placée à DROP. C'est adroit, car elle autorise les hôtes de notre réseau local à se connecter à des hôtes sur Internet, mais en même temps elle bloque les hôtes depuis Internet leur interdisant de se connecter aux hôtes de notre réseau interne.

Enfin, nous avons également une chaîne de journalisation pour tous les paquets qui ne sont pas autorisés dans un sens ou dans l'autre à traverser la chaîne FORWARD. Ceci concerne principalement les paquets mal formés ou autre problème. Une cause peut être une attaque de hacker, et une autre des paquets mal formés. C'est exactement la même règle que celle utilisée dans la chaîne INPUT sauf pour le préfixe de journalisation, "IPT FORWARD packet died: ". Le préfixe de journalisation est principalement utilisé pour séparer les entrées de journaux, et peut être utilisé pour savoir d'où les paquets ont été journalisés et connaître certaines options d'en-tête.

Comme nous utilisons notre machine en partie comme pare-feu et en partie comme station de travail, nous autorisons tout ce qui sort de cette machine qui a une adresse source $LOCALHOST_IP, $LAN_IP ou $STATIC_IP. Enfin nous journalisons tout ce qui est DROPé. S'il y a des paquets DROPés, nous voulons savoir quelle action entreprendre contre ce problème. Soit c'est une erreur, soit c'est un paquet mystérieux qui peut être usurpé. Enfin nous DROPons le paquet dans la stratégie par défaut.

La chaîne PREROUTING fait à peu près ce qu'elle indique, elle traduit les adresses réseau sur les paquets avant la décision de routage qui les envoie vers les chaînes INPUT ou FORWARD dans la table de filtrage. La seule raison que nous avons de parler de cette chaîne ici est que nous ne faisons aucun filtrage dans celle-ci. La chaîne PREROUTING est traversée seulement par le premier paquet d'un flux, ce qui veut dire que tous les autres paquets ne seront pas vérifiés dans cette chaîne. Dans ce script, nous n'utilisons pas du tout la chaîne PREROUTING, cependant, c'est le bon endroit si nous voulons faire du DNAT sur des paquets spécifiques, par exemple si nous voulons héberger notre serveur web dans notre réseau local. Pour plus d'information sur la chaîne PREROUTING, lire le chapitre Traversée des tables et des chaînes.

La chaîne PREROUTING ne doit pas être utilisée pour quelque filtrage que ce soit, car parmi d'autres choses, elle n'est traversée que par le premier paquet d'un flux. Elle devrait être utilisée uniquement pour la traduction d'adresse réseau, à moins que vous ne sachiez réellement ce que vous faites.

Notre dernière mission est d'activer la traduction d'adresse réseau. En premier nous ajoutons une règle à la table nat, dans la chaîne POSTROUTING qui NAT tous les paquets provenant de notre interface et allant vers Internet. Pour moi c'est eth0. Cependant, il existe des variables spécifiques ajoutées aux scripts d'exemples qui peuvent être utilisées automatiquement pour configurer cela. L'option -t indique à iptables dans quelle table insérer la règle, dans notre cas c'est la table nat. La commande -A indique que nous voulons lier une nouvelle règle à une chaîne existante nommée POSTROUTING et -o $INET_IFACE nous dit d'apparier tous les paquets sortants sur l'interface INET_IFACE (ou eth0, par défaut dans ce script) et enfin nous plaçons la cible pour faire du SNAT sur les paquets. Ainsi tous les paquets qui apparient cette règle seront SNATés pour vérifier qu'ils viennent de l'interface Internet. Notez que vous devez indiquer l'adresse IP à donner aux paquets sortants avec l'option --to-source envoyée à la cible SNAT.

Dans ce script nous avons choisi d'utiliser la cible SNAT au lieu de MASQUERADE pour deux raisons. La première est que ce script est supposé s'exécuter sur un pare-feu qui possède une adresse IP statique. La raison suivante est qu'il est plus rapide et plus efficace d'utiliser la cible SNAT si possible. Bien sûr, nous l'utilisons aussi pour montrer comment elle fonctionne dans un exemple réel. Si nous n'avons pas d'adresse IP statique, nous utiliserons la cible MASQUERADE car elle offre des fonctions simples et faciles pour faire du NAT, mais elle récupère automatiquement l'adresse IP qui sera utilisée. Ceci consomme un peu plus de temps système, mais c'est très avantageux si vous utilisez DHCP. Si vous voulez avoir une vue plus détaillée de la cible MASQUERADE, regardez le script rc.DHCP.firewall.txt.