--- FW_old.xml 2006-02-10 16:49:34.267853616 +0100 +++ FW_new2.xml 2006-02-10 16:52:30.437071824 +0100 @@ -1,70 +1,75 @@ - + - -Linux 2.4 stateful firewall design + +Firewall stateful sous Linux 2.4 - + Daniel Robbins -This tutorial shows you how to use netfilter to set up a powerful Linux stateful -firewall. +Ce guide va vous apprendre à batir un puissant firewall stateful en utilisant +NetFilter sous Linux. - + 1.3 2005-10-09 -About this tutorial +A propos de ce guide
-Should I take this tutorial? +A qui s'adresse ce guide ?

-This tutorial shows you how to use netfilter to set up a powerful Linux stateful -firewall. All you need is an existing Linux system that's currently using a -Linux 2.4 kernel. A laptop, workstation, router or server with a Linux 2.4 -kernel will do. +Ce guide vous montre comment utiliser NetFilter pour configurer un puissant +firewall stateful. Tout ce dont vous aurez besoin est d'un système Linux +existant utilisant une version 2.4 ou supérieure du noyau Linux. Un portable, PC +de bureau, routeur ou serveur avec un Linux 2.4 ou plus fera l'affaire.

-You should be reasonably familiar with standard network terminology like IP -addresses, source and destination port numbers, TCP, UDP and ICMP, etc. By the -end of the tutorial, you'll understand how Linux stateful firewalls are put -together and you'll have several example configurations to use in your own -projects. +Vous devez être assez familier avec le vocabulaire réseau, comme les adresses +IP, les ports source et destination, TCP, UDP ou ICMP, etc. Après avoir suivi +ce guide jusqu'au bout, vous aurez compris le fonctionnement d'un firewall +stateful sous Linux. De nombreux exemples de configurations vous seront +également exposés.

-About the author +A propos de l'auteur

-For technical questions about the content of this tutorial, contact the author, -Daniel Robbins, at drobbins@gentoo.org. +Pour toute question technique sur le contenu de ce guide, contactez l'auteur, +Daniel Robbins, à l'adresse suivante: +drobbins@gentoo.org.

-Residing in Albuquerque, New Mexico, Daniel Robbins was the President/CEO of -Gentoo Technologies, Inc., the creator of Gentoo Linux, an advanced Linux for -the PC, and the Portage system, a next-generation ports system for Linux. He has -also served as a contributing author for the Macmillan books Caldera OpenLinux -Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel has been involved -with computers in some fashion since the second grade, when he was first exposed -to the Logo programming language as well as a potentially dangerous dose of Pac -Man. This probably explains why he has since served as a Lead Graphic Artist at -SONY Electronic Publishing/Psygnosis. Daniel enjoys spending time with his wife, -Mary, and his new baby daughter, Hadassah. +Résidant à Albuquerque, dans le Nouveau Mexique, Daniel Robbins a été le PDG de +Gentoo Technologies, Inc., le créateur de Gentoo Linux, un système +d'exploitation Linux moderne pour PC, et du système Portage, un gestionnaire de +ports nouvelle génération pour Linux. Il a également été un des auteurs +contributeurs pour les livres Caldera OpenLinux Unleashed, SuSE Linux Unleashed, +et Samba Unleashed, parus aux éditions Macmillan. Daniel a été au contact de +l'informatique depuis l'école élémentaire, quand il fut confronté au langage de +programmation Logo, ainsi qu'à une dose potentiellement dangereuse de Pac Man. +Celà explique sans doute pourquoi il a depuis été employé en tant que Chef +Infographiste chez SONY Electronic Publishing/Psygnosis. Daniel aime passer son +temps libre avec sa femme, Mary, et sa fille, Hadassah.

@@ -72,58 +77,61 @@ -First steps +Premières étapes
-Defining our goal +Le but du jeu

-In this tutorial, we're going to put together a Linux stateful firewall. Our -firewall is going to run on a Linux laptop, workstation, server, or router; its -primary goal is to allow only certain types of network traffic to pass through. -To increase security, we're going to configure the firewall to drop or reject -traffic that we're not interested in, as well as traffic that could pose a -security threat. +Dans ce guide, nous allons bâtir un firewall stateful Linux. Notre firewall va +s'exécuter sur un ordinateur portable, de bureau, serveur ou routeur sous Linux; +son but principal est d'autoriser seulement certains types de traffic réseau à +le traverser. Pour augmenter la sécurité, nous allons configurer le firewall +pour ignorer ou rejeter le traffic qui ne nous interesse pas, ainsi que le +traffic potentiellement dangereux pour la sécurité.

-Getting the tools +Les outils nécessaires

-Before we start designing a firewall, we need to do two things. First, we need -to make sure that the iptables command is available. As root, type -iptables and see if it exists. If it doesn't, then we'll need to get it -installed first. Here's how we do that: +Avant de commencer à bâtir le firewall, il faut faire deux choses. Tout d'abord, +il faut s'assurer que la commande iptables est disponible sur la machine. +Pour celà, en tant que super-utilisateur, tapez iptables et vérifiez ce +que vous répond le shell. Si la commande n'existe pas, alors il nous faut +l'installer. Voilà comment faire :

-
+
 # emerge iptables
-Kernel configuration +Configuration du noyau

-Once installed, you should have an iptables command available for use, as -well as the handy iptables man page (man iptables). Great; now all we -need is to make sure that we have the necessary functionality built into the -kernel. This tutorial assumes that you compile your own kernels. Head over to -/usr/src/linux, and type make menuconfig or make -xconfig; we're going to enable some kernel network functionality. +Une fois installée, vous devez avoir une commande iptables disponible, +ainsi que la page de manuel qui lui correspond (man iptables). Bien; +maintenant il faut nous assurer que les fonctionnalités nécessaires sont bien +activées dans le noyau. Ce guide suppose que vous compilez vos propres noyaux. +Dans le répertoire /usr/src/linux, tapez make menuconfig ou +make xconfig; nous allons choisir certaines fonctionnalités pour notre +noyau.

-Under the "Networking options" section, make sure that you enable at least the -following options: + Dans la section "Networking options" (dans le menu "Networking->Networking +Options" pour le noyau 2.6), assurez-vous d'activer au moins les options +suivantes:

-
+
 <*> Packet socket
 [*] Network packet filtering (replaces ipchains)
 <*> Unix domain sockets
@@ -136,84 +144,88 @@
 

 
 

-Then, under the "IP: Netfilter Configuration ->" menu, enable every option so
-that we'll have full netfilter functionality. We won't use all the netfilter
-features, but it's good to enable them so that you can do some experimentation
-later on.
+Ensuite, dans le menu "IP: Netfilter Configuration ->", activez toutes les
+options, afin d'avoir toutes les fonctionnalités NetFilter disponibles pour
+votre firewall. Nous n'aurons pas besoin de toutes, mais vous pourrez ainsi plus
+tard mener quelques expériences avec ces options.
 

 
 

-There's one networking option under the "Networking options" category that you
-shouldn't enable: explicit congestion notification. Leave this option
-disabled:
+Il y a une fonctionnalité dans la section "Networking options" que vous ne
+devriez pas activer: la notification explicite de congestion. Laissez
+cette option décochée.
 

 
-
+
 [ ]   IP: TCP Explicit Congestion Notification support
 

 
 

-If this option is enabled, your Linux machine won't be able to carry on network
-communications with 8% of the Internet. When ECN is enabled, some packets that
-your Linux box sends out will have the ECN bit set; however, this bit freaks out
-a number of Internet routers, so it's very important that ECN is disabled.
+Si cette option est activée, votre machine Linux ne sera pas capable de
+supporter des communications réseau avec environ 8% de l'Internet. Quand l'ECN
+est activée, certains paquets envoyés par votre machine Linux auront le bit ECN
+valué à 1. En pratique, ce bit engendre des comportements bizarres sur certains
+routeurs Internet, aussi vaut-il mieux garder l'ECN désactivée.
 

 
 

-OK, now that the kernel's configured correctly for our needs, compile a new one,
-install it, and reboot. Time to start playing with netfilter :)
+Maintenant que le noyau est configuré correctement, compilez-le, installez-le et
+rebootez. Nous pouvons maintenant nous amuser avec NetFilter :)
-Firewall design basics +Premiers pas

-In putting together our firewall, the iptables command is our friend. -It's what we use to interact with the network packet filtering rules in the -kernel. We'll use the iptables command to create new rules, list -existing rules, flush rules, and set default packet handling policies. This -means that to create our firewall, we're going to enter a series of iptables -commands, and here's the first one we're going to take a look at (please don't -type this in just yet!)... +Pour construire un firewall, la commande iptables sera votre meilleure +alliée. Elle permet d'interagir avec les règles de filtrage de paquets au niveau +du noyau. Nous utiliserons la commande iptables pour créer de nouvelles +règles, afficher les règles existantes, en supprimer, et choisir la politique de +filtrage par défaut. Ce qui signifie que la création d'un firewall se résume à +entrer une série de commandes iptables, comme par exemple (ATTENTION, ne pas la +taper tout de suite !)

-
+
 # iptables -P INPUT DROP
 

 
 

-You're looking at an almost "perfect" firewall. If you type in this command,
-you'll be incredibly well protected against any form of incoming malicious
-attack. That's because this command tells the kernel to drop all incoming
-network packets. While this firewall is extremely secure, it's a bit silly. But
-before moving on, let's take a look at exactly how this command does what it
-does.
+Si vous voulez créer un firewall "quasiment" parfait, et que vous entrez cette
+commande, vous serez absolument bien protégé contre toutes formes d'attaques
+malicieuses. En effet, cette commande ordonne au noyau d'ignorer tous les
+paquets réseau entrants. Cependant, même si ce firewall est extrêmement
+sécurisé, il est également un peu mauvais. Mais avant de continuer, essayons de
+comprendre comment cette commande peut faire ce qu'elle fait.
-Setting chain policy +Modifier la politique par défaut

-An iptables -P command is used to set the default policy for a chain of -packet filtering rules. In this example, iptables -P is used to set the -default policy for the INPUT chain, a built-in chain of rules that's applied to -every incoming packet. By setting the default policy to DROP, we tell the kernel -that any packets that reach the end of the INPUT rule chain should be dropped -(that is, discarded). And, since we haven't added any rules to the INPUT chain, -all packets reach the end of the chain, and all packets are dropped. +La commande iptables -P est utilisée pour selectionner la politique par +défaut pour une chaine de filtrage de paquets. Dans cet exemple, iptables +-P est utilisée pour changer la politique par défaut de la chaine INPUT, une +chaine préinstallée qui est appliquée à chaque paquet entrant. En sélectionnant +la potique par défaut DROP, on indique au noyau que chaque paquet qui atteint la +fin de la chaine INPUT doit être droppé (c'est à dire ignoré, supprimé de la +mémoire). Et comme nous n'avons pas encore ajouté de règles dans la chaine +INPUT, tous les paquets atteignent la fin de la chaine, et donc tous les paquets +sont ignorés.

-Again, by itself this command is totally useless. However, it demonstrates a -good strategy for firewall design. We'll start by dropping all packets by -default, and then gradually start opening up our firewall so that it meets our -needs. This will ensure that our firewall is as secure as possible. +Encore une fois, à elle seule, cette commande est totalement inutile. Cependant, +elle montre une bonne stratégie pour la construction d'un firewall. On commence +par ignorer tous les paquets par défaut, puis on ouvre au fur et à mesure les +ports dont on a besoin. Celà garantit que le firewall est aussi sécurisé que +possible.

@@ -221,109 +233,116 @@ -Defining rules +Definir ses règles
-A (small) improvement +Une (petite) amélioration

-In this example, let's assume that we're designing a firewall for a machine with -two network interfaces, eth0 and eth1. The eth0 network card is connected to our -LAN, while the eth1 network card is attached to our DSL router, our connection -to the Internet. For such a situation, we could improve our "ultimate firewall" -by adding one more line: +Dans cet exemple, nous supposerons que nous construisons un firewall pour une +machine avec deux interfaces réseau, nommées eth0 et eth1. L'interface eth0 est +connectée sur notre LAN, tandis que eth1 est branchée sur notre routeur DSL, qui +mène vers Internet. Dans une telle situation, nous améliorerons notre "firewall +ultime" en rajoutant une ligne:

-
+
 # iptables -P INPUT DROP
 # iptables -A INPUT -i ! eth1 -j ACCEPT
 

 
 

-This additional iptables -A line adds a new packet filtering rule to the
-end of our INPUT chain. After this rule is added, our INPUT chain consists of a
-single rule and a drop-by-default policy. Now, let's take a look at what our
-semi-complete firewall does.
+Cette ligne supplémentaire iptables -A ajoute une nouvelle règle de
+filtrage de paquets à la fin de la chaine INPUT. Après avoir rajouté cette
+règle, la chaine INPUT consiste en une règle unique et une règle DROP par
+défaut. Maintenant, voyons ce que fait notre firewall désormais à moitié
+terminé.
-Following the INPUT chain +Le long de la chaine INPUT...

-When a packet comes in on any interface (lo, eth0, or eth1), the netfilter code -directs it to the INPUT chain and checks to see if the packet matches the first -rule. If it does, the packet is accepted, and no further processing is -performed. If not, the INPUT chain's default policy is enforced, and the packet -is discarded (dropped). +Quand un paquet arrive sur l'une des interfaces (lo, eth0, ou eth1), le code de +NetFilter l'envoie sur la chaine INPUT et vérifie s'il correspond à la première +règle. Si c'est le cas, est accepté, et le traitement de ce paquet est terminé. +Sinon, la règle par défaut de INPUT est appliquée, et le paquet est effacé +(DROP).

-That's the conceptual overview. Specifically, our first rule matches all packets -coming in from eth0 and lo, immediately allowing them in. Any packets coming in -from eth1 are dropped. So, if we enable this firewall on our machine, it'll be -able to interact with our LAN but be effectively disconnected from the Internet. -Let's look at a couple of ways to enable Internet traffic. +Voilà pour le point de vue conceptuel. Plus concrétement, la première règle +correspond à tous les paquets arrivant sur les interfaces eth0 et lo, et les +laisse passer. Tous les paquets arrivant sur l'interface eth1 sont droppés. +Donc, si nous activons ce firewall sur notre machine, il pourra intéragir avec +notre LAN mais ne pourra pas communiquer avec Internet. Voyons comment autoriser +le traffic Internet, et ce de deux manières différentes.

-Traditional firewalls +Firewalls traditionnels

-Obviously, for our firewall to be useful, we need to selectively allow some -incoming packets to reach our machine via the Internet. There are two approaches -to opening up our firewall to the point where it is useful: one uses static -rules, and the other uses dynamic, stateful rules. +Evidemment, pour que notre firewall serve à quelque chose, il nous faut +sélectionner quels paquets seront autorisés à atteindre notre machine en passant +par Internet. Il y a deux approches pour faire celà: l'une utilise des règles +statiques, tandis que l'autre utilise des règles dynamiques, avec suivi d'état +(stateful).

-Let's take downloading Web pages as an example. If we want our machine to be -able to download Web pages from the Internet, we can add a static rule that will -always be true for every incoming http packet, regardless of origin: +Prenons pour exemple le cas du téléchargement de pages Web. Si nous voulons que +notre machine soit capable de recevoir les paquets correspondants au +téléchargement, nous pouvons ajouter une règle statique qui sera toujours vraie +pour les paquets HTTP entrants, quelle que soit leur origine:

-
+
 # iptables -A INPUT --sport 80 -j ACCEPT
 

 
 

-Since all standard Web traffic originates from a source port of 80, this rule
-effectively allows our machine to download Web pages. However, this traditional
-approach, while marginally acceptable, suffers from a bunch of problems.
+Comme tout le traffic Web standard provient d'un serveur avec port source 80,
+cette règle permet effectivement à votre machine de télécharger des pages Web.
+Cependant, cette approche traditionnelle, bien qu'acceptable dans certains cas,
+engendre de nombreux problèmes.
-Traditional firewall bummers +Problèmes des firewalls traditionnels

-Here's a problem: while most Web traffic originates from port 80, some doesn't. -So, while this rule would work most of the time, there would be rare instances -where this rule wouldn't work. For example, maybe you've seen a URL that looks -like this: "http://www.foo.com:81". This example URL points to a Web -site on port 81 rather than the default port 80, and would be unviewable from -behind our current firewall. Taking into account all these special cases can -quickly turn a fairly secure firewall into swiss cheese and quickly fill our -INPUT chain with a bunch of rules to handle the occasional oddball Web site. +Voilà le premier problème: bien que la plupart du traffic Web a pour origine un +port 80, ce n'est quelquefois pas vrai. Donc, cette règle marche, mais seulement +la plupart du temps. Par exemple, vous avez peut-être déjà vu une URL du genre +"http://www.foo.com:81". Cette URL pointe vers un serveur Web hébergé sur un +serveur écoutant sur le port 81 plutôt que le port 80 par défaut, et est donc +invisualisable derrière notre firewall. Prendre en compte toutes les exceptions +de ce genre va vite faire de notre firewall sécurisé un sac de noeuds et +remplira notre chaine INPUT avec un tas de règles pour gérer chaque cas +particulier.

-However, the major problem with this rule is security related. Sure, it's true -that only traffic with a source port of 80 will be allowed through our firewall. -But the source port of a packet is not something that we have any control over, -and it can be easily altered by an intruder. For example, if an intruder knew -how our firewall were designed, he could bypass our firewall by simply making -sure that all his incoming connections originated from port 80 on one of his -machines! Because this static firewall rule is so easy to exploit, a more secure -dynamic approach is needed. Thankfully, iptables and kernel 2.4 provide -everything we need to enable dynamic, stateful filtering. +Cependant, le problème majeur de ce genre de règle est lié à la sécurité. +Evidemment, il est vrai que seulement le traffic avec un port source 80 sera +autorisé à passer notre firewall. Mais le port source d'un paquet est un élément +facilement manipulable par un attaquant. Par exemple, si un intrus connait la +façon dont notre firewall est conçu, il peut le contourner simplement en +s'assurant que toutes ses connexions entrantes viennent d'un port 80 de l'une de +ses machines ! Puisque cette règle statique est trop facile à contourner, il +nous faut une approche plus sécurisée et dynamique. Heureusement, iptables et le +noyau 2.4 et supérieurs incluent tout ce dont nous avons besoin pour construire +un firewall dynamique et à suivi d'états.

@@ -331,136 +350,140 @@ -Stateful firewalls +Firewalls stateful
-State basics +Quelques mots sur les états

-Rather than opening up holes in our firewall based on static protocol -characteristics, we can use Linux's new connection tracking functionality to -make firewall decisions based on the dynamic connection state of packets. -Conntrack works by associating every packet with an individual bidirectional -communications channel, or connection. +Plutôt que de creuser des trous dans notre firewall en se basant sur des +caractéristiques statiques des protocoles, on peut utiliser les nouvelles +fonctionnalités de suivi de connexion de Linux pour baser les décisions du +firewall sur l'état dynamique des paquets par rapport à la connexion. Conntrack +fonctionne en associant chaque paquet avec une et une seule communication +bidirectionnelle, ou connexion.

-For example, consider what happens when you use telnet or ssh to connect to a -remote machine. If you view your network traffic at the packet level, all you -see is a bunch of packets zipping from one machine to another. However, at a -higher level, this exchange of packets is actually a bidirectional -communications channel between your local machine and a remote machine. -Traditional (old-fashioned) firewalls only look at the individual packets, not -recognizing that they're actually part of a larger whole, a connection. +Par exemple, imaginons ce qui se passe lorsque vous utilisez telnet ou ssh pour +vous connecter sur une machine distante. Si vous regarder le traffic réseau au +niveau paquets, tout ce que vous verez sera un tas de paquets passant d'une +machine sur l'autre. Cependant, à un niveau d'abstraction plus élevé, cette +échange de paquets est en fait une communication bidirectionelle entre votre +machine locale et la machine distante. Les firewalls traditionnels ne font que +regarder chaque paquet indépendemment les uns des autres, sans se soucier qu'ils +fassent en réalité partie d'un tout, d'une connexion.

-Inside conntrack +Conntrack en détails

-That's where connection tracking technology comes in. Linux's conntrack -functionality can "see" the higher-level connections that are taking place, -recognizing your ssh session as a single logical entity. Conntrack can even -recognize UDP and ICMP packet exchanges as logical "connections", even though -UDP and ICMP are connectionless in nature; this is very helpful because it -allows us to use conntrack to handle ICMP and UDP packet exchanges. +C'est là que la technologie de suivi de connexion entre en jeu. La +fonctionnalité conntrack de Linux peut "voir" les connexions de haut niveau +lorsqu'elles ont lieu, reconnaissant votre session SSH comme une seule entité +logique. Conntrack peut aussi reconnaître les échanges de paquets UDP et ICMP +comme des "connexions" logiques, même si UDP et ICMP sont sans connexion par +nature; celà est très utile puisque sela permet d'utiliser conntrack pour gérer +des échanges de paquets ICMP et UDP.

-If you've already rebooted and are using your new netfilter-enabled kernel, you -can view a list of active network connections that your machine is participating -in by typing cat /proc/net/ip_conntrack. Even with no firewall -configured, Linux's conntrack functionality is working behind the scenes, -keeping track of the connections that your machine is participating in. +Si vous avez déjà redémarré avec votre nouveau noyau avec NetFilter activé, vous +pouvez voir une liste des connexions réseau actives auquelles votre machine +participe en entrant cat /proc/net/ip_conntrack. Même sans firewall +configuré, conntrack fonctionne en arrière-plan, en gardant trace des connexions +établies ou reçues par votre machine.

-The NEW connection state +Etat de connexion NEW

-Conntrack doesn't just recognize connections, it also classifies every packet -that it sees into one of four connection states. The first state that we're -going to talk about is called NEW. When you type ssh remote.host.com, the -initial packet or burst of packets that originate from your machine and are -destined for remote.host.com are in the NEW state. However, as soon as you -receive even just a single reply packet from remote.host.com, any further -packets you send to remote.host.com as part of this connection aren't considered -NEW packets anymore. So, a packet is only considered NEW when it's involved in -establishing a new connection, and no traffic has yet been received from the -remote host (as part of this particular connection, of course). +Conntrack ne fait pas que reconnaitre les connexions, il classe également chaque +paquet qu'il voit dans l'un des quatres états de connexion. Le premier état dont +nous allons parler est appelé NEW (nouveau). Quand vous tapez ssh +hote.distant.com, le premier paquet ou la première rafale de paquets qui +sortent de votre machine et sont destinés à hote.distant.com sont dans l'état +NEW. Cependant, dès que vous aurez reçu ne serait-ce qu'un seul paquet de +hote.distant.com, tous les futurs paquets que vous enverrez à hote.distant.com +dans cette connexion ne seront plus considérés comme des packets NEW. Pour +résumer, un paquet est considéré NEW lorsqu'il sert à établir une nouvelle +connexion, et qu'aucun trafic n'a été reçu de l'hôte distant en retour (dans le +cadre de cette connexion précise, évidemment).

-I've described outgoing NEW packets, but it's also very possible (and common) to -have incoming NEW packets. Incoming NEW packets generally originate from a -remote machine, and are involved in initiating a connection with you. The -initial packet(s) your Web server receives as part of a HTTP request would be -considered incoming NEW packets; however, once you reply to just a single -incoming NEW packet, any additional packets you receive that are related to this -particular connection are no longer in the NEW state. +J'ai décris les paquets NEW sortants, mais il est également tout à fait possible +(et normal) d'avoir des paquets NEW entrants. Les paquets NEW entrants viennent +généralement d'une machine distante, et servent à établir une connexion avec +vous. Le(s) premier(s) paquet(s) que votre serveur Web reçoit pour une requête +HTTP sont considérés comme des paquets NEW entrants; cependant, une fois que +vous aurez répondu à un seul de ces paquets, tous les autres paquets que vous +recevrez ne seront plus considérés dans l'état NEW.

-The ESTABLISHED state +Etat de connexion ESTABLISHED

-Once a connection has seen traffic in both directions, additional packets -relating to this connection are considered to be in an ESTABLISHED state. The -distinction between NEW and ESTABLISHED is an important one, as we'll see in a -minute. +Une fois qu'une connexion a vue du trafic dans les deux sens, tous les nouveaux +paquets de cette connexion sont considérés dans l'état ESTABLISHED (établi). La +distinction entre les états NEW et ESTABLISHED est très importante, comme nous +le verrons dans un instant.

-The RELATED state +Etat de connexion RELATED

-The third connection state category is called RELATED. RELATED packets are those -that are starting a new connection, but are related to another currently -existing connection. The RELATED state can be used to regulate connections that -are part of a multi-connection protocol, such as ftp, as well as error packets -related to existing connections (such as ICMP error packets related to an -existing connection). +Le troisième état de connexion est appelé RELATED (en rapport avec). Les paquets +RELATED sont ceux qui établissent une nouvelle connexion, mais qui sont en +rapport avec une connexion déjà existante. L'état RELATED peut être utilisé pour +filtrer des connexions qui font partie d'un protocole multi-connexion, comme +FTP, ainsi que les paquets d'erreur en rapport avec des connexions existantes +(comme les paquets d'erreur ICMP).

-The INVALID state +Etat de connexion INVALID

-Finally, there are INVALID packets: those that can't be classified into one of -the above three categories. It's important to note that if a packet is -considered INVALID, it isn't automatically discarded; it's still up to you to -insert the appropriate rules and set chain policy so that they're handled -correctly. +Pour terminer, il existe aussi les paquets INVALID: ce sont ceux qui ne peuvent +être classés dans aucune des trois précédentes catégories. Il est important de +noter qu'un paquet considéré comme INVALID n'est pas automatiquement ignoré; +c'est à vous de choisir les règles appropriées et d'ajuster les politiques pour +que ces paquets soient gérés de la manière que vous préférez.

-Adding a stateful rule +Ajout d'une règle stateful

-OK, now that we have a good understanding of connection tracking, it's time to -take a look at a single additional rule that transforms our non-functional -firewall into something quite useful: +Bien, maintenant que nous avons compris le suivi de connexion, il est temps de +jeter un oeil à une simple règle supplémentaire qui va transformer notre +firewall non-fonctionnel en quelque chose de plutôt utile.

-
+
 # iptables -P INPUT DROP
 # iptables -A INPUT -i ! eth1 -j ACCEPT
 # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
@@ -469,95 +492,100 @@
-How the rule works +Fonctionnement de cette règle

-This single rule, when inserted at the end of our existing INPUT chain, will -allow us to establish connections with remote machines. It works as follows. -Let's say we want to ssh over to remote.host.com. After typing ssh -remote.host.com, our machine sends out a packet to initiate the connection. -This particular packet is in the NEW state, and our firewall allows it out, -because we're only blocking packets coming in to our firewall, not going out. +Cette simple règle, insérée à la fin de votre chaine INPUT existante, va nous +permettre d'établir des connexions avec des machines distantes. Elle fonctionne +comme ceci: disons que l'on veuille faire du ssh vers hote.distant.com. Après +avoir lancé ssh hote.distant.com, notre machine envoie un paquet pour +établir la connexion. Ce paquet particulier est dans l'état NEW, et notre +firewall le laisse passer, puisque nous bloquons seulement les paquets qui +entrent dans notre firewall, pas qui en sortent.

-When we get a reply packet from remote.host.com, this packet trickles through -our INPUT chain. It doesn't match our first rule (since it comes in on eth1), so -it moves on to our next, and final rule. If it matches this rule, it will be -accepted, and if it doesn't, it will fall off the end of the INPUT chain and the -default policy will be applied to the packet (DROP). So, is this incoming reply -packet accepted or dropped on the floor? +Quand nous recevons une réponse de hote.distant.com, ce paquet passe par notre +chaine INPUT. Il ne correspond pas à la première règle (puisqu'il arrive de +eth1), donc il passe à la seconde et dernière règle. Si il correspond à cette +règle, il sera accepté, et sinon, il arrivera à la fin de la chaine INPUT et la +politique par défaut lui sera appliquée (DROP). Alors, ce paquet entrant +sera-t'il accepté ou droppé ?

-Answer: accepted. When the kernel inspects this incoming packet, it first -recognizes that it's part of an already existing connection. Then, the kernel -needs to decide whether this is a NEW or ESTABLISHED packet. Since this is an -incoming packet, it checks to see if this connection has had any outgoing -traffic, and finds that it has (our initial NEW packet that we sent out). -Therefore, this incoming packet is categorized as ESTABLISHED, as are any -further packets we receive or send that are associated with this connection. +Réponse: accepté. Quand le noyau examine ce paquet entrant, il reconnait en +premier qu'il fait partie d'une connexion existante. Ensuite, le noyau doit +décider s'il s'agit d'un paquet NEW ou ESTABLISHED. Puisqu'il s'agit d'un paquet +entrant, il vérifie si cette connexion a déjà eu du trafic sortant, et trouve +que c'est le cas (le paquet NEW initial que nous avons envoyé). Ensuite, le +paquet entrant est classé ESTABLISHED, comme le seront tous les futurs paquets +reçus ou envoyés qui seront associés avec cette connexion.

-Incoming NEW packets +Paquets NEW entrants

-Now, let's consider what happens if someone on a remote machine tries to ssh in -to us. The initial packet we receive is classified as NEW, and doesn't match -rule 1, so it advances to rule 2. Because this packet isn't in an ESTABLISHED or -RELATED state, it falls off the end of the INPUT chain and the default policy, -DROP, is applied. Our incoming ssh connection request is dropped to the floor -without so much as a reply (or TCP reset) from us. +Maintenant, considérons ce qui ce passe si quelqu'un sur une machine distante +essaie de se connecter en ssh chez nous. Le premier paquet que nous recevons est +marqué NEW, et ne correspond pas à la règle 1, donc il passe à la règle 2. +Puisque ce paquet n'est pas dans l'état ESTABLISHED ou RELATED, il arrive à la +fin de la chaine INPUT et la politique par défaut, DROP, est appliquée. Notre +demande d'établissement de connexion ssh entrante est donc ignorée sans même une +réponse (ou un paquet TCP reset) de notre part.

-A near-perfect firewall +Un firewall proche de la perfection

-So, what kind of firewall do we have so far? An excellent one for a laptop or a -workstation where you don't want anyone from the Internet connecting to you, but -where you need to connect to sites on the Internet. You'll be able to use -Netscape, konqueror, ftp, ping, perform DNS lookups, and more. Any connection -that you initiate will get back in through the firewall. However, any -unsolicited connection that comes in from the Internet will be dropped, unless -it's related to an existing connection that you initiated. As long as you don't -need to provide any network services to the outside, this is a near-perfect -firewall. +Alors, quel genre de firewall avons-nous jusqu'à présent ? Un excellent choix +pour un portable ou un poste de travail si vous voulez que personne ne puisse se +connecter depuis Internet vers vous, mais avec lequel vous pouvez quand même +vous connecter à des sites sur Internet. Vous pourrez utiliser Netscape, +Konqueror, ftp, ping, faire des recherches DNS, et bien plus. Toutes les +connexions dont vous êtes l'initiateur pourront passer votre firewall. +Cependant, les connexions non sollicitées qui viennent depuis Internet seront +ignorées, à moins d'être en relation avec une connexion existante que vous avez +initiée. Tant que vous ne devez pas fournir un service réseau vers l'extérieur, +c'est un firewall pratiquement parfait.

-A basic firewall script +Un script de firewall simple

-Here's a simple script that can be used to set up/tear down our first basic -workstation firewall: +Voilà un script simple qui peut être utilisé pour configurer notre premier +firewall de station de travail:

-
+
 #!/bin/bash
-# A basic stateful firewall for a workstation or laptop that isn't running any
-# network services like a web server, SMTP server, ftp server, etc.
+# Un script de firewall simple pour une station de travail ou un
+portable
+# qui ne fournit aucun service réseau, comme un  serveur web, ftp,
+smtp, etc.
 
 if [ "$1" = "start" ]
 then
-        echo "Starting firewall..."
+        echo "Démarrage du firewall..."
         iptables -P INPUT DROP
         iptables -A INPUT -i ! eth1 -j ACCEPT
         iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 elif [ "$1" = "stop" ]
 then
-        echo "Stopping firewall..."
+        echo "Arrêt du firewall..."
         iptables -F INPUT
         iptables -P INPUT ACCEPT
 fi
@@ -566,18 +594,19 @@
-Using the script +Utilisation du script

-Using this script, you can bring down the firewall by typing ./firewall -stop, and bring it back up again by typing ./firewall start. To bring -down the firewall, we flush our rules out of the INPUT chain with a iptables --F INPUT, and then switch the default INPUT policy back to ACCEPT with a -iptables -P INPUT ACCEPT command. Now, let's look at a bunch of -improvements that we can make to our existing workstation firewall. Once I've -explained every improvement, I'll present a final workstation firewall script. -Then, we'll start customizing our firewall for servers. +En utilisant ce script, vous pouvez désactiver le firewall en tapant +./firewall stop, et le relancer en tapant ./firewall start. Pour +désactiver le firewall, on supprime les règles de la chaine INPUT en faisant +iptables -F INPUT, puis reprenons la politique par défaut de INPUT en +ACCEPT avec la commande iptables -P INPUT ACCEPT. Maintenant, voyons +tout un tas d'améliorations que nous pouvons faire sur notre firewall. Après +avoir expliqué chaque amélioration, je présenterai un script avancé pour un +poste de travail. Ensuite, nous commencerons à modifier notre firewall pour des +serveurs.

@@ -585,21 +614,22 @@ -Stateful improvements +Améliorations au suivi d'états
-Explicitly turn off ECN +Désactication explicite de l'ECN

-I mentioned earlier that it's important to turn off ECN (explicit congestion -notification) so that Internet communications will work properly. While you may -have disabled ECN in the kernel per my suggestion, it's possible that in the -future, you'll forget to do so. Or, possibly, you'll pass your firewall script -along to someone who has ECN enabled. For these reasons, it's a good idea to use -the /proc interface to explicitly disable ECN, as follows: +J'ai parlé plus haut de l'importance de désactiver l'ECN (explicit congestion +notification) pour que les communications Internet fonctionnent correctement. +Même si vous avez désactivé l'ECN dans le noyau en suivant ma suggestion, il +est possible que vous l'oubliez dans le futur. Ou, comme c'est possible, vous +allez paser votre script de firewall à quelqu'un qui a l'ECN activé. Pour ces +raisons, c'est une bonne idée d'utiliser l'interface /proc pour +désactiver explicitement l'ECN, comme ceci:

-
+
 if [ -e /proc/sys/net/ipv4/tcp_ecn ]
 then
         echo 0 > /proc/sys/net/ipv4/tcp_ecn
@@ -613,12 +643,13 @@
 
 
 

-If you're using your Linux machine as a router, then you'll want to enable IP
-forwarding, which will give the kernel permission to allow packets to travel
-between eth0 and eth1, and vice versa. In our example configuration, where eth0
-is connected to our LAN, and eth1 is connected to the Internet, enabling IP
-forwarding is a necessary step in allowing our LAN to connect to the Internet
-via our Linux box. To enable IP forwarding, use this line:
+Si vous utilisez votre machine Linux comme un routeur, alors vous voudrez
+activer l'IP forwarding, ce qui donnera la permission au noyau de transmettre
+des paquets de l'interface eth0 à eth1, et inversement. Dans notre exemple de
+configuration, ou eth0 est connectée à notre LAN, et eth1 à Internet, activer
+l'IP forwarding est une étape nécessaire pour permettre à notre LAN de se
+connecter à Internet en passant par notre machine Linux. Pour activer l'IP
+forwarding, utilisez cette ligne:
 

 
 
@@ -628,69 +659,72 @@
-Handling rejection +Gestion des rejets

-So far, we've been dropping all unsolicited traffic coming in from the Internet. -While this is an effective way to deter unwanted network activity, it does have -some drawbacks. The biggest problem with this approach is that it's easy for an -intruder to detect that we're running a firewall, since our machine isn't -replying with the standard TCP reset and ICMP port-unreachable responses: the -responses that a normal machine would send back to indicate a failed connection -attempt to a non-existent service. +Jusqu'à présent, nous avons ignoré tout le trafic non solicité venant +d'Internet. Bien que celà soit un moyen efficace pour contrer l'activité réseau +non désirable, celà engendre également quelques inconvénients. Le plus gros +problème avec cette approche est qu'il est facile pour un intrus de détecter +que nous utilisons un firewall, puisque notre machine ne répond pas avec les +réponses standards TCP reset et ICMP port-unreachable, c'est à dire les +réponses qu'une machine normale devrait renvoyer pour indiquer une tentative de +connexion échouée vers un service non existant.

-Rather than let potential intruders know that we're running a firewall (and thus -tip them off to the fact that we may be running some valuable services that they -can't get to), it would be to our advantage to make it appear as if we aren't -running any services at all. By adding these two rules to the end of our INPUT -chain, we can successfully accomplish this task: +Plutôt que de laisser des intrus potentiels savoir que nous utilisons un +firewall (ce qui peut leur laisser penser que nous fournissons des services +précieux auquels ils ne peuvent pas accéder), il serait à notre avantage de +faire croire que nous n'utilisons pas de firewall. En ajoutant ces deux règles +à la fin de la chaine INPUT, on peut facilement accomplir cette tâche:

-
+
 # iptables -A INPUT -p tcp -i eth1 -j REJECT --reject-with tcp-reset
-# iptables -A INPUT -p udp -i eth1 -j REJECT --reject-with icmp-port-unreachable
+# iptables -A INPUT -p udp -i eth1 -j REJECT --reject-with
+icmp-port-unreachable
 

 
 

-Our first rule takes care of correctly zapping TCP connections, while the second
-handles UDP. With these two rules in place, it becomes very difficult for an
-intruder to detect that we're actually running a firewall; hopefully, this will
-cause the intruder to leave our machine and search for other targets with more
-potential for abuse.
+La première règle s'occupe de rejeter correctement les connexions TCP, alors
+que la seconde s'occupe de l'UDP. Avec ces deux règles, il devient difficile
+pour un intrus de détecter que nous sommes derrière un firewall; avec de la
+chance, l'intrus se détournera de notre machine pour chercher d'autres cibles
+potentiellement plus intérressantes.
 

 
 

-In addition to making our firewall more "stealthy", these rules also eliminate
-the delay involved in connecting to certain ftp and irc servers. This delay is
-caused by the server performing an ident lookup to your machine (connecting to
-port 113) and eventually (after about 15 seconds) timing out. Now, our firewall
-will return a TCP reset and the ident lookup will fail immediately instead of
-retrying for 15 seconds (while you're patiently waiting for a response from the
-server).
+En plus de rendre notre firewall plus "discret", ces règles éliminent aussi le
+délai lors de la connection à certains serveurs FTP et IRC. Ce délai est dû au
+serveur qui tente de faire une requête ident sur votre machine (en se
+connectant sur le port 113), qui échoue après un timeout d'environ 15 secondes.
+Maintenant, notre firewall va renvoyer un TCP reset et la requête ident va
+échouer immédiatement plutôt que de réssayer pendant 15 secondes (alors que
+vous attendez patiemment une réponse du serveur).
-Spoof protection +Protection contre le Spoof

-In many distributions, when the network interface(s) are brought up, several old -ipchains rules are also added to the system. These special rules were added by -the creators of the distribution to deal with a problem called spoofing, in -which the source address of packets have been tweaked so that they contains an -invalid value (something that script kiddies do). While we can create similar -iptables rules that will also block spoofed packets, there's an easier way. -These days, the kernel has the built-in ability to dropped spoofed packets; all -we need to do is enable it via a simple /proc interface. Here's -how. +Dans plusieurs distributions, quand une interface réseau est activée, plusieurs +vieilles règles ipchains sont également ajoutées au système. Ces règles +spéciales avaient été ajoutées par les créateurs de la distribution pour +contrer un problème appelé spoofing, dans lequel les adresses sources des +paquets ont été traffiqués pour contenir une valeur invalide (c'est une des +choses que les script kiddies font). Bien que l'on pourrait créer des règles +iptables similaires pour bloquer ces paquets spoofés, il y a une manière de +faire plus facile. De nos jours, le noyau a la fonctionnalité intégrée +d'ignorer les paquets spoofés; il suffit de l'activer par le biais de +l'interface /proc. Voilà comment.

-
+
 for x in lo eth0 eth1
 do
         echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
@@ -698,9 +732,9 @@
 

 
 

-This shell script will tell the kernel to drop any spoofed packets on interfaces
-lo, eth0, and eth1. You can either add these lines to your firewall script, or
-add them to the script that brings up your lo, eth0, and eth1 interfaces.
+Ce script shell va indiquer au noyau d'ignorer tous les paquets spoofés sur les
+interfaces lo, eth0 et eth1. Vous pouvez soit ajouter ces lignes à votre script
+de firewall, soit dans le script qui active vos interfaces lo, eth0, et eth1.
 

 
 
@@ -710,11 +744,12 @@
 
 
 

-NAT (network address translation) and IP masquerading, while not directly
-related to firewalls, are often used in conjunction with them. We're going to
-look at two common NAT/masquerading configurations that you may need to use.
-This first rule would take care of situations where you have a dialup link to
-the Internet (ppp0) that uses a dynamic IP:
+Le NAT (network address translation) et l'IP masquerading, bien que non
+directement en rapport avec les firewalls, sont souvent utilisés en complément.
+Nous allons voir deux configurations répandues de NAT/Masquerading que vous
+pourrez avoir à utiliser. La première règle servira dans les situations où vous
+utilisez un lien non permanent vers Internet (ppp0) avec une adresse IP
+dynamique.
 

 
 
@@ -722,11 +757,12 @@
 

 
 

-If you're in this situation, you'll also want to convert my firewall scripts so
-that all references to "eth1" (our example DSL router) are changed to "ppp0".
-And it's perfectly fine to add firewalling rules that refer to "ppp0" when the
-ppp0 interface doesn't yet exist. As soon as ppp0 is up, everything will work
-perfectly. Make sure you enable IP forwarding as well.
+Si vous êtes dans cette situation, vous voudrez également convertir mes scripts
+de firewall pour que les références à "eth1" (le routeur DSL dans notre
+exemple) soient changées en "ppp0". Et il est tout à fait possible d'ajouter
+des règles qui font références à "ppp0" alors que cette interface n'existe pas
+encore. Dès que ppp0 est activée, tout fonctionnera à merveille. Vérifiez
+quannd même que vous avez activé l'IP forwarding.
 

 
 
@@ -736,27 +772,28 @@
 
 
 

-If you're using DSL to connect to the Internet, you probably have one of two
-possible configurations. One possibility is that your DSL router or modem has
-its own IP number and performs network address translation for you. If you're in
-this situation, you don't need Linux to perform NAT for you since your DSL
-router is taking care of it already.
+Si vous utilisez une ligne DSL pour vous connecter à Internet, vous avez
+probablement une des deux configurations suivantes. Dans la première, votre
+routeur DSL ou modem a sa propre adresse IP et s'occupe de la translation
+d'adresse pour vous. Si vous êtes dans cette situation, vous n'avez pas besoin
+de faire du NAT puisque votre routeur DSL le fait déjà.
 

 
 

-However, if you want to have more control over your NAT functionality, you may
-want to talk to your ISP about configuring your DSL connection so that your DSL
-router is in "bridged mode". In bridged mode, your firewall becomes an official
-part of your ISP's network, and your DSL router transparently forwards IP
-traffic back and forth between your ISP and your Linux box without letting
-anyone know that it's there. It no longer has an IP number; instead, eth1 (in
-our example) sports the IP. If someone pings your IP from the Internet, they get
-a reply back from your Linux box, rather than your router.
+Cependant, si vous voulez avoir plus de contrôle sur vos fonctionnalités NAT,
+vous pouvez eventuellement, si votre fournisseur d'accès le permet, configurer
+votre routeur DSL en mode "bridge" (pont). Dans ce mode, votre firewall devient
+un élément officiel du réseau de votre fournisseur d'accès, et le routeur DSL
+s'occupe de relayer le trafic de et vers votre machine Linux de manière
+transparente. Il n'a plus besoin d'une adresse IP; à la place, eth1 (dans notre
+exemple) en a une. Si quelqu'un pingue votre adresse IP depuis Internet, il
+recevra une réponse de votre machine Linux, et pas de votre routeur.
 

 
 

-With this kind of setup, you'll want to use SNAT (source NAT) rather than
-masquerading. Here's the line you should add to your firewall:
+Avec ce genre de configuration, vous aurez à utiliser SNAT (source NAT)
+plutôt que le Masquerading. Voici la ligne que vous devriez rajouter à votre
+firewall:
 

 
 
@@ -764,101 +801,112 @@
 

 
 

-In this example, eth1 should be changed to the ethernet interface connected
-directly to your DSL router, and 1.2.3.4 should be changed to your static IP
-(the IP of your ethernet interface). Again, remember to enable IP forwarding.
+Dans cet exemple, remplacez eth1 par l'interface Ethernet connectée sur votre
+routeur DSL, ainsi que 1.2.3.4 par votre adresse IP statique (l'IP de votre
+interface Ethernet). Encore une fois, n'oubliez pas l'IP forwarding.
-NAT issues +Problèmes avec le NAT

-Fortunately for us, NAT and masquerading get along just fine with a firewall. -When writing your firewall filtering rules, just ignore the fact that you're -using NAT. Your rules should accept, drop, or reject packets based on their -"real" source and destination addresses. The firewall filtering code sees the -original source address for a packet, and the final destination address. This is -great for us, because it allows our firewall to continue working properly even -if we temporarily disable NAT or masquerading. +Heureusement pour nous, le NAT et le masquerading s'entendent bien sur notre +firewall. Quand vous écrivez vos règles de firewall, ignorez simplement que vous +utilisez du NAT. Vos règles doivent accepter, ignorer ou rejeter les paquets en +se basant sur leur "véritables" adresses source et destination. Le code de +filtrage du firewall prend en compte l'adresse source d'origine et l'adresse de +destination finale. C'est tant mieux pour nous, puisque celà permet à notre +firewall de fonctionner correctement même si on désactive temporairement le NAT +ou le masquerading.

-Understanding tables +Comprendre les tables

-In the above NAT/masquerading examples, we're appending rules to a chain, but -we're also doing something a bit different. Notice the "-t" option. The "-t" -option allows us to specify the table that our chain belongs to. When omitted, -the default table defaults to "filter". So, all our previous non-NAT related -commands were modifying the INPUT chain that's part of the "filter" table. The -"filter" table contains all the rules associated with accepting or rejecting -packets, while the "nat" table (as you would assume) contains rules relating to -network address translation. There are also other built-in iptables chains and -they are described in detail in the iptables man page, as well as in Rusty's -HOWTOs (see the Resources section at the end of -this tutorial for links). +Dans les exemples de NAT/masquerading précédents, on a ajouté des règles à une +chaine, mais nous avons également fait des choses un peu différemment. Remarquez +l'option "-t". L'option "-t" permet de choisir la table à laquelle appartient +notre chaine. Quand cette option n'est pas spécifiée, la table par défaut est la +table "filter". Par conséquent, toutes les commandes précédentes sans rapport +avec le NAT ont modifié la chaine INPUT qui fait partie de la table "filter". La +table "filter" contient toutes les règles associées à l'acceptation/rejet de +paquets, tandis que la table "nat" (comme vous pouvez le deviner) contient les +règles concernant la translation d'adresse. Il existe d'autres chaines iptables +qui sont décrites en détail dans la page de manuel iptables, ainsi que dans les +HOWTO de Rusty Russel (cf. dans la section Ressources + plus bas pour les liens).

-Our enhanced script +Notre script amélioré

-Now that we've taken a look at a bunch of possible enhancements, it's time to -take a look at a second more flexible firewall up/down script: +Maintenant que nous avons vu tout un tas d'améliorations possibles, il est temps +de voir un second script plus souple d'activation/désactivation du firewall:

-
+
 
 #!/bin/bash
 
-# An enhanced stateful firewall for a workstation, laptop or router that isn't
-# running any network services like a web server, SMTP server, ftp server, etc.
-
-# Change this to the name of the interface that provides your "uplink"
-# (connection to the Internet)
+# Un firewall statefull amélioré pour une station de travail, portable
+ou routeur
+# qui ne fourni aucun service réseau (comme serveur web, smtp, ftp,
+etc.)
+
+# Changez cette variable pour le nom de l'interface qui sert d'"uplink"
+
+# (connexion à Internet)
 
 UPLINK="eth1"
 
-# If you're a router (and thus should forward IP packets between interfaces),
-# you want ROUTER="yes"; otherwise, ROUTER="no"
+# Si vous êtes un routeur, (et donc souhaitez forwarder les paquets IP
+entre les interfaces),
+# mettez ROUTER="yes"; sinon, ROUTER="no"
 
 ROUTER="yes"
 
-# Change this next line to the static IP of your uplink interface for static SNAT, or
-# "dynamic" if you have a dynamic IP.  If you don't need any NAT, set NAT to "" to
-# disable it.
+# Changez la prochaine ligne pour mettre l'adresse IP statique de votre
+interface
+# uplink pour faire du SNAT statique, ou "dynamic" si vous avez une IP
+dynamique
+# Si vous n'avez pas besoin de NAT, laissez NAT="" pour le désactiver.
+
 
 NAT="1.2.3.4"
 
-# Change this next line so it lists all your network interfaces, including lo
+# Changez cette variable pour lister toutes vos interfaces réseau, y
+compris lo
 
 INTERFACES="lo eth0 eth1"
 
 if [ "$1" = "start" ]
 then
-        echo "Starting firewall..."
+        echo "Demarrage du firewall..."
         iptables -P INPUT DROP
         iptables -A INPUT -i ! ${UPLINK} -j ACCEPT
         iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
         iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset
-        iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with icmp-port-unreachable
+        iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with
+icmp-port-unreachable
 
-        # Explicitly disable ECN
+        # Desactivation explicite de l'ECN
         if [ -e /proc/sys/net/ipv4/tcp_ecn ]
         then
                 echo 0 > /proc/sys/net/ipv4/tcp_ecn
         fi
 
-        # Disable spoofing on all interfaces
+        # Désactiver le spoofing sur toutes les interfaces
         for x in ${INTERFACES}
         do
                 echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
@@ -866,27 +914,31 @@
 
         if [ "$ROUTER" = "yes" ]
         then
-                # We're a router of some kind, enable IP forwarding
+                # Activation de l'IP forwarding pour le routage
+
                 echo 1 > /proc/sys/net/ipv4/ip_forward
                 if [ "$NAT" = "dynamic" ]
                 then
-                        # Dynamic IP address, use masquerading
-                        echo "Enabling masquerading (dynamic ip)..."
-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE
+                        # Adresse IP dynamique, utilisation du
+masquerading
+                        echo "Activation du masquerading (IP dynamique)..."
+                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j
+MASQUERADE
                 elif [ "$NAT" != "" ]
                 then
-                        # Static IP, use SNAT
-                        echo "Enabling SNAT (static ip)..."
-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${UPIP}
+                        # IP statique, utilisation du SNAT
+                        echo "Activation SNAT (IP statique)..."
+                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to
+${UPIP}
                 fi
         fi
 
 elif [ "$1" = "stop" ]
 then
-        echo "Stopping firewall..."
+        echo "Arret du firewall..."
         iptables -F INPUT
         iptables -P INPUT ACCEPT
-        # Turn off NAT/masquerading, if any
+        # Désactive le NAT/masquerading
         iptables -t nat -F POSTROUTING
 fi
 

@@ -896,28 +948,28 @@
 
 
 
-Stateful servers
+Servers statefuls
 

-Viewing rules
+Voir ses règles
 
 
 

-Before we start making customizations to our firewall so that it can be used on
-a server, I need to show you how to list your currently active firewall rules.
-To view the rules in the filter table's INPUT chain, type:
+Avant de commencer à modifier notre firewall pour pouvoir l'utiliser sur un
+serveur, je dois vous montrer comment afficher les règles actives sur votre
+firewall. Pour voir les règles dans la chaine INPUT de la table filter, tapez:
 

 
-
+
 # iptables -v -L INPUT
 

 
 

-The -v option gives us a verbose output, so that we can see the total packets
-and bytes transferred per rule. We can also look at our nat POSTROUTING table
-with the following command:
+L'option -v nous donne une sortie verbeuse, afin que l'on puisse voir le nombre
+total de paquets et d'octets transférés par règle. On peut aussi voir la chaine
+POSTROUTING de la table nat avec la commande suivante:
 

 
-
+
 # iptables -t nat -v -L POSTROUTING
 Chain POSTROUTING (policy ACCEPT 399 packets, 48418 bytes)
 pkts bytes target     prot opt in     out     source               destination
@@ -928,52 +980,53 @@
 
 

 

-Getting ready for service
+Prêts pour le service
 
 
 

-Right now, our firewall doesn't allow the general public to connect to services
-on our machine because it only accepts incoming ESTABLISHED or RELATED packets.
-Because it drops any incoming NEW packets, any connection attempt is rejected
-unconditionally. However, by selectively allowing some incoming traffic to cross
-our firewall, we can allow the general public to connect to the services that we
-specify.
+A l'heure actuelle, notre firewall ne permet pas au "public" de se connecter aux
+services sur notre machine car il accepte seulement les paquets entrants dans
+l'état ESTABLISHED ou RELATED. Comme il ignore tous les paquets NEW entrants,
+toutes les tentatives de connexion sont systématiquement rejetées. Cependant, en
+autorisant sélectivement certains paquets à traverser notre firewall, on peut
+permettre au "public" de se connecter aux services que nous voudrons.
 

 
 
 

 

-Stateful HTTP
+HTTP stateful
 
 
 

-While we want to accept some incoming connections, we probably don't want to
-accept every kind of incoming connection. It makes sense to start with a "deny
-by default" policy (as we have now) and begin opening up access to those
-services that we'd like people to be able to connect to. For example, if we're
-running a Web server, we'll allow NEW packets into our machine, as long as they
-are headed for port 80 (HTTP). That's all we need to do. Once we allow the NEW
-packets in, we've allowed a connection to be established. Once the connection is
-established, our existing rule allowing incoming ESTABLISHED and RELATED packets
-kicks in, allowing the HTTP connection to proceed unhindered.
+Bien que l'on veuille accepter quelques connexions entrantes, on ne souhaite
+tout de même pas les accepter toutes. Il est préférable de partir d'une
+politique "rejet par défaut" (comme nous l'avons configuré actuellement) et
+d'ouvrir l'accès aux seuls services que l'on souhaite rendre publics. Par
+exemple, si nous avons un serveur Web, nous allons autoriser les paquets NEW
+vers notre machine, mais seulement s'ils sont destinés au port 80 (HTTP). C'est
+tout ce qu'il suffit de faire. Dès que nous autorisons le paquet NEW à passer,
+on autorise l'établissement de connexion. Une fois la connexion établie, la
+règle existante qui autorise les paquets entrants ESTABLISHED et RELATED entre
+en scène, laissant se dérouler la connexion HTTP sans accrocs.
 

 
 
 

 

-Stateful HTTP example
+Exemple d'HTTP stateful
 
 
 

-Let's take a look at the "heart" of our firewall and the new rule that allows
-incoming HTTP connections:
+Jetons un oeil au "coeur" de notre firewall et à la nouvelle règle qui autorise
+les connexion HTTP entrantes:
 

 
-
+
 iptables -P INPUT DROP
 iptables -A INPUT -i ! ${UPLINK} -j ACCEPT
 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-# Our new rule follows
+# Notre nouvelle règle
 iptables -A INPUT -p tcp --dport http -m state --state NEW -j ACCEPT
 iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset
 iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with
@@ -981,79 +1034,92 @@
 

 
 

-This new rule allows incoming NEW TCP packets destined for our machine's port 80
-(http) to come in. Notice the placement of this rule. It's important that it
-appears before our REJECT rules. Since iptables will apply the first matching
-rule, putting it after our REJECT lines would cause this rule to have no effect.
+Cette nouvelle règle autorise les paquets TCP NEW entrants destinés au port
+80 (HTTP) de notre machine à entrer. Remarquez la place de cette règle. Il est
+important qu'elle soit placée avant notre règle REJECT. Comme iptables applique
+seulement la première règle qui correspond, la mettre derrière les lignes REJECT
+engendrerai qu'elle n'ai aucun effet.
 

 
 
 

 

-Our final firewall script
+Notre script de firewall avancé
 
 
 

-Now, let's take a look at our final firewall script, one that can be used on a
-laptop, workstation, router, or server (or some combination thereof!).
+Maintenant, voyons notre dernier script de firewall, qui peut être utilisé
+sur un portable, station de travail, routeur ou serveur (ou une quelconque
+combinaison !)
 

 
-
+
 
 #!/bin/bash
 
-# Our complete stateful firewall script.  This firewall can be customized for
-# a laptop, workstation, router or even a server. :)
+# Notre script de firewall complement stateful. Ce firewall peut
+être adapté
+# pour un portable, station de travail, routeur ou même un serveur. :)
+
 
-# Change this to the name of the interface that provides your "uplink"
-# (connection to the Internet)
+# Changez cette variable pour le no de l'interface "uplink"
+# (connexion vers Internet)
 
 UPLINK="eth1"
 
-# If you're a router (and thus should forward IP packets between interfaces),
-# you want ROUTER="yes"; otherwise, ROUTER="no"
+# Si vous êtes routeur (et donc souhaitez forwarder les paquets IP
+entre les
+# interfaces), mettez ROUTER="yes"; sinon, ROUTER="no"
 
 ROUTER="yes"
 
-# Change this next line to the static IP of your uplink interface for static SNAT, or
-# "dynamic" if you have a dynamic IP.  If you don't need any NAT, set NAT to "" to
-# disable it.
+# Changez la prochaine ligne vers l'adresse IP statique de votre
+interface
+# uplink pour du SNAT statique, ou "dynamic" si vous avez une IP
+dynamique.
+# Si vous ne voulez pas de NAT, mettez NAT="" pour le désactiver.
+
 
 NAT="1.2.3.4"
 
-# Change this next line so it lists all your network interfaces, including lo
+# Changez cette ligne pour lister toutes vos interfaces réseaux, y
+compris lo
 
 INTERFACES="lo eth0 eth1"
 
-# Change this line so that it lists the assigned numbers or symbolic names (from
-# /etc/services) of all the services that you'd like to provide to the general
-# public. If you don't want any services enabled, set it to ""
+# Changez cette ligne pour lister les numéros de ports ou noms
+symboliques
+# (de /etc/services) de tous les services que vous souhaiter rendre
+publics.
+# Si vous ne souhaitez publiez aucun service, laissez ""
 
 SERVICES="http ftp smtp ssh rsync"
 
 if [ "$1" = "start" ]
 then
-        echo "Starting firewall..."
+        echo "Démarrage du firewall..."
         iptables -P INPUT DROP
         iptables -A INPUT -i ! ${UPLINK} -j ACCEPT
         iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
-        # Enable public access to certain services
+        # Activer l'accès publics aux services
         for x in ${SERVICES}
         do
-                iptables -A INPUT -p tcp --dport ${x} -m state --state NEW -j ACCEPT
+                iptables -A INPUT -p tcp --dport ${x} -m state --state NEW -j
+ACCEPT
         done
 
         iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset
-        iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with icmp-port-unreachable
+        iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with
+icmp-port-unreachable
 
-        # Explicitly disable ECN
+        # Désactivation explicite de l'ECN
         if [ -e /proc/sys/net/ipv4/tcp_ecn ]
         then
                 echo 0 > /proc/sys/net/ipv4/tcp_ecn
         fi
 
-        # Disable spoofing on all interfaces
+        # Protection anti-spoofing
         for x in ${INTERFACES}
         do
         echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
@@ -1061,27 +1127,29 @@
 
         if [ "$ROUTER" = "yes" ]
         then
-                # We're a router of some kind, enable IP forwarding
+                # Activation de l'IP forwarding
                 echo 1 > /proc/sys/net/ipv4/ip_forward
                 if [ "$NAT" = "dynamic" ]
                 then
-                # Dynamic IP address, use masquerading
-                echo "Enabling masquerading (dynamic ip)..."
-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE
+                # IP dynamique => masquerading
+                echo "Activation du masquerading (ip dynamique)..."
+                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j
+MASQUERADE
                 elif [ "$NAT" != "" ]
                 then
-                        # Static IP, use SNAT
-                        echo "Enabling SNAT (static ip)..."
-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${UPIP}
+                        # IP statique => SNAT
+                        echo "Activation du SNAT (ip statique)..."
+                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to
+${UPIP}
                 fi
         fi
 
 elif [ "$1" = "stop" ]
 then
-        echo "Stopping firewall..."
+        echo "Arrêt du firewall..."
         iptables -F INPUT
         iptables -P INPUT ACCEPT
-        # Turn off NAT/masquerading, if any
+        # Arrêt du masquerading
         iptables -t nat -F POSTROUTING
 fi
 

@@ -1091,127 +1159,134 @@
 
 
 
-Building a better server firewall
+Construire un meilleur firewall pour serveur
 

-Server improvements
+Améliorations
 
 
 

-It's often possible to make a firewall just an eensy bit "better". Of course,
-what "better" means depends on your specific needs. Our existing script could
-meet yours exactly, or maybe some additional tweaking is in order. This section
-is intended to serve as a cookbook of ideas, demonstrating ways to enhance your
-existing stateful firewall.
+Il est souvent possible de rendre son firewall toujours un peu "mieux". Bien
+sûr, la signification de "mieux" dépend de vos besoins spécifiques. Notre script
+existant peu combler exactement les vôtres, ou peut-être que quelques retouches
+seront nécessaires. Cette section est sensée servir de livre à idées, pour vous
+montrer plusieurs moyens d'améliorer notre firewall stateful existant.
 

 
 
 

 

-Logging techniques
+Techniques de log
 
 
 

-So far, we haven't discussed how to go about logging anything. There's a special
-target called LOG that you can use to log things. Along with LOG, there's a
-special option called --log-prefix that allows you to specify some text
-that will appear alongside the packet dump in the system logs. Here's an example
-log rule:
+Jusqu'à présent, nous n'avons pas vu comment logger des evenements. Il y a une
+cible spéciale appelée LOG que vous pouvez utiliser pour celà. Associée à LOG,
+il y a une option spéciale appelée --log-prefix qui permet de choisir le
+texte qui apparaîtra devant le descriptif du paquet dans les logs du système.
+Voilà un exemple de règle LOG:
 

 
-
-#  iptables -A INPUT -j LOG --log-prefix "bad input:"
+
+#  iptables -A INPUT -j LOG --log-prefix "Anomalie INPUT:"
 

 
 

-You wouldn't want to add this as the first rule in your INPUT chain, as it would
-cause a log entry to be recorded for every packet that you receive! Instead,
-place log rules further down in your INPUT chain with the intention of logging
-strange packets and other anomalies.
+Vous ne voudrez certainement pas ajouter cette règle en premier dans votre
+chaine INPUT, car celà entraînerait qu'une entrée dans les logs soit créée pour
+chaque paquet que vous recevez ! A la place, placez cette règle assez bas dans
+la chaine INPUT pour logguer uniquement les paquets bizarres et autres
+anomalies.
 

 
 

-Here's an important note about the LOG target. Normally, when a rule matches, a
-packet is either accepted, rejected, or dropped, and no further rules are
-processed. However, when a log rule matches, the packet is logged. However, it
-is not accepted, rejected, or dropped. Instead, the packet continues on to the
-next rule, or the default chain policy is applied if the log rule is the last on
-the chain.
+Une remarque importante sur la cible LOG. Normalement, quand une règle
+correspond à un paquet, ce paquet est soit accepté, rejeté ou ignoré, et les
+règles suivantes ne sont pas vérifiées. Cependant, quand une règle LOG
+correspond, ce paquet est loggué. Il n'est ni accepté, ni rejeté, ni ignoré. A
+la place, le paquet est confronté à la règle suivante, ou bien la règle par
+défaut est appliquée s'il n'y a pas de règle suivante.
 

 
 

-The LOG target can also be combined with the "limit" module (described in the
-iptables man page) to minimize duplicate log entries. Here's an example:
+La cible LOG peut également être combinée avec le module "limit" (décrit dans
+la page de manuel iptables) pour éviter d'avoir trop d'entrées dupliquées.
+Voilà un exemple:
 

 
-
-# iptables -A INPUT -m state --state INVALID -m limit --limit 5/minute -j LOG --log-prefix "INVALID STATE:"
+
+# iptables -A INPUT -m state --state INVALID -m limit --limit 5/minute -j LOG
+--log-prefix "Etat INVALID:"
 

 
 
 

 

-Creating your own chains
+Créer vos propres chaines
 
 
 

-iptables allows you to create your own user-defined chains that can be specified
-as targets in your rules. If you want to learn how to do this, spend some time
-going through the Packet filtering HOWTO at the netfilter/iptables project home
-page (http://www.netfilter.org/).
+iptables vous permet de créer vos propres chaines qui peuvent être
+ensuite spécifiée comme cibles dans vos règles. Pour en apprendre plus à ce
+sujet, étudiez le Packet filtering HOWTO hebergé sur le site du projet 
+netfilter/iptables (http://www.netfilter.org/).
 

 
 
 

 

-Enforcing network usage policy
+Politique de restriction d'usages
 
 
 

-Firewalls offer a lot of power for those who want to enforce a network usage
-policy for a corporate or academic LAN. You can control what packets your
-machine forwards by adding rules to and setting policy for the FORWARD chain. By
-adding rules to the OUTPUT chain, you can also control what happens to packets
-that are generated locally, by users on the Linux box itself. iptables also has
-the incredible ability to filter locally-created packets based on owner (uid or
-gid). For more information on this, search for "owner" in the iptables man page.
+Les firewalls offrent une grande puissance à ceux qui veulent restreindre les
+usages d'un réseau dans une entreprise ou un réseau académique. Vous pouvez
+contrôler quels paquets votre machine relait en ajoutant des règles dans la
+chaine FORWARD. En ajoutant des règles à la chaine OUTPUT, vous pouvez
+également contrôler ce qui arrive aux paquets générés localement, par les
+utilisateurs sur la machine Linux elle-même. iptables a aussi l'incroyable
+capacité de filtrer les paquets générés localement en fonction de leur
+propriétaire (UID ou GID). Pour plus d'informations à ce sujet, cherchez
+"owner" (propriétaire) dans la page de manuel iptables.
 

 
 
 

 

-Other security angles
+Autres angles de la sécurité
 
 
 

-In our example firewall, we've assumed that all internal LAN traffic is
-trustworthy, and that only incoming Internet traffic must be carefully
-monitored. Depending on your particular network, that may or may not be the
-case. There's certainly nothing stopping you from configuring your firewall to
-provide protection from incoming LAN traffic. Consider other "angles" of your
-network that you may want to protect. It may also be appropriate to configure
-two separate LAN security "zones", each with its own security policy.
+Dans notre exemple de firewall, nous avons supposé que tout le trafic du LAN
+interne est digne de confiance, et que seul le trafic Internet devait être
+filtré avec soin. Selon votre réseau interne, celà peut être ou ne pas être le
+cas. Rien ne vous empêche de configurer votre firewall pour se protéger
+également du coté du LAN. Envisagez les autres "angles" de votre réseau que
+vous voulez protéger. Il peut être aussi approprié de configurer deux zones
+de sécurité différentes dans votre LAN, chacune avec sa propre politique de
+sécurité.
 

 
 
 

 
 
-
-Resources
+
+Ressources
 

 tcpdump
 
 
 

-In this section, I'll point out a number of resources that you'll find helpful
-as you put together your own stateful firewall. Let's start with an important
-tool...
+Dans cette section, je vous mets des pointeurs vers des ressources variées que
+vous trouverez certainement utiles pour vous aider à mettre au point votre
+firewall. Commençons par un outil important...
 

 
 

-tcpdump is an essential tool for
-exploring low-level packet exchanges and verifying that your firewall is working
-correctly. If you don't have it, get it. If you've got it, start using it.
+tcpdump est un outil essentiel pour
+l'exploration bas niveau des echanges de paquets et pour vérifier que votre
+firewall fonctionne correctement. Si vous ne l'avez pas, téléchargez le. Si 
+vous l'avez, commencez à l'utiliser.
 

 
 
@@ -1221,10 +1296,11 @@
 
 
 

-Visit the netfilter/iptables project home page
-(http://www.netfilter.org).  You'll find many resources at this site,
+Visitez le site web du projet netfilter/iptables 
+(http://www.netfilter.org). You'll find many resources at this site,
 including the iptables sources and a netfilter
+link="http://www.netfilter.org/documentation/index.html#documentation-faq">
+netfilter
 FAQ. Also Rusty's
 Remarkably Guides are excellent, and include a basic networking concepts
@@ -1235,13 +1311,14 @@
 
 

 

-iptables man page
+La page de manuel iptables
 
 
 

-Thankfully, there are a lot of good online netfilter resources; however, don't
-forget the basics. The iptables man page is very detailed and is a shining
-example of what a man page should be. It's actually an enjoyable read.
+Heureusement, il y a beaucoup de ressources disponibles en ligne sur Netfilter;
+cependant, n'oubliez pas les bases. La page de manuel iptables est très
+détaillée et est un excellent exemple de ce à quoi une page de manuel devrait
+ressembler. C'est une lecture passionnante.
 

 
 
@@ -1251,17 +1328,20 @@
 
 
 

-There's now an Advanced Linux Routing
-and Traffic Control HOWTO available.  There's a good section that shows
-how to use iptables to mark packets, and then use Linux routing functionality to
-route the packets based on these marks.
+Le Advanced Linux Routing and
+Traffic Control HOWTO est disponible (également
+
+en français). Il contient tout un chapitre sur l'utilisation d'iptables
+pour le marquage de paquets, puis sur l'utilisation des fonctionnalités de
+routage de Linux pour router les paquets en fonction de ces marques.
 

 
 
-This HOWTO contains references to Linux's traffic control (quality of service)
-functionality (accessed through the new tc command). This new functionality,
-although very cool, is very poorly documented, and attempting to figure out all
-aspects of Linux traffic control can be a very frustrating task at this point.
+Ce guide contient des références vers la fonction de contrôle de trafic
+(qualité de service) de Linux (accessible via la commande tc). Cette
+nouvelle fonctionnalité, bien que très puissante, est très peu documentée, et
+essayer de cerner tous les aspects du contrôle de trafic peut être une tache
+très frustrante pour le moment.
 
 
 
@@ -1271,22 +1351,22 @@
 
 
 

-Users who have questions on netfilter/iptables usage, setup, or configuration,
-or who want to help other users by sharing their experience and knowledge, can
-contact the netfilter user mailing
-list.
+Les utilisateurs qui ont des questions sur l'utilisation, l'installation ou la
+configuration de Netfilter/iptables, ou qui veulent aider les autres
+utilisateurs en partageant leurs experience et connaissances, peuvent contacter 
+la mailing-list
+des utilisateurs de Netfilter.
 

 
 

-Netfilter/iptables developers who have questions, suggestions, or contributions
-to netfilter/iptables development can contact the netfilter developer
-mailing list.
+Les développeurs Netfilter/iptables qui ont des questions, suggestions ou
+contributions pour le developpement de Netfilter/iptables peuvent contacter la mailing-list des
+développeurs de Netfilter.
 

 
 

-You can also browse the list archives at these URLs.
+Vous pouvez aussi parcourir les archives de mailing-list sur ces URLs.
 

 
 
@@ -1296,27 +1376,27 @@
 
 
 

-In June 2000, O'Reilly released an excellent book -- Building Internet Firewalls, Second
-Edition. It's great reference book, especially for those times when you
-want to configure your firewall to accept (or flat-out reject) a little-known
-protocol that you're unfamiliar with.
+En juin 2000, O'Reilly a publié un excellent livre -- Building Internet Firewalls,
+Second Edition. C'est un bon manuel de référence, en particulier dans les
+cas où vous voulez configurer votre firewall pour accepter (ou rejeter) un
+protocole peu connu avec lequel vous n'êtes pas familier.
 

 
 

-Well, that's it for our resources list, and our tutorial is complete. I hope
-that this tutorial has been helpful to you, and I look forward to your feedback.
+Voilà, c'était la liste de nos ressources, et ce guide est terminé. J'espère
+qu'il vous a été utile, et j'attends vos remarques.
 

 
 
 

 

-Your feedback
+Vos remarques
 
 
 

-We look forward to getting your feedback on this tutorial. Additionally, you are
-welcome to contact the author, Daniel Robbins, at drobbins@gentoo.org.