Attachment 79439 Details for Bug 122377 – A patch to translate the original XML file.

[patch] A patch to translate the original XML file.

FW_frenchtranslation.patch (text/plain), 86.99 KB, created by Guillaume Pujol on 2006-02-10 08:01:10 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Guillaume Pujol

Created: 2006-02-10 08:01:10 UTC

Size: 86.99 KB

patch

obsolete

>--- 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 @@
> <?xml version='1.0' encoding="UTF-8"?>
>-
>+
> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
> 
>-<guide link="/doc/en/articles/linux-24-stateful-fw-design.xml" disclaimer="articles">
>-<title>Linux 2.4 stateful firewall design</title>
>+<guide link="/doc/en/articles/linux-24-stateful-fw-design.xml"
>+disclaimer="articles">
>+<title>Firewall stateful sous Linux 2.4</title>
> 
>-<author title="Author">
>+<author title="Auteur">
>   <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
> </author>
> 
> <abstract>
>-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.
> </abstract>
> 
>-
>+
> 
> <version>1.3</version>
> <date>2005-10-09</date>
> 
> <chapter>
>-<title>About this tutorial</title>
>+<title>A propos de ce guide</title>
> <section>
>-<title>Should I take this tutorial?</title>
>+<title>A qui s'adresse ce guide ?</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>About the author</title>
>+<title>A propos de l'auteur</title>
> <body>
> 
> <p>
>-For technical questions about the content of this tutorial, contact the author,
>-Daniel Robbins, at <mail link="drobbins@gentoo.org">drobbins@gentoo.org</mail>.
>+Pour toute question technique sur le contenu de ce guide, contactez l'auteur,
>+Daniel Robbins, à l'adresse suivante: <mail link="drobbins@gentoo.org">
>+drobbins@gentoo.org</mail>.
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
>@@ -72,58 +77,61 @@
> </chapter>
> 
> <chapter>
>-<title>First steps</title>
>+<title>Premières étapes</title>
> <section>
>-<title>Defining our goal</title>
>+<title>Le but du jeu</title>
> <body>
> 
> <p>
>-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é.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Getting the tools</title>
>+<title>Les outils nécessaires</title>
> <body>
> 
> <p>
>-Before we start designing a firewall, we need to do two things. First, we need
>-to make sure that the <c>iptables</c> command is available. As root, type
>-<c>iptables</c> 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 <c>iptables</c> est disponible sur la machine.
>+Pour celà, en tant que super-utilisateur, tapez <c>iptables</c> 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 :
> </p>
> 
>-<pre caption="Installing necessary tools">
>+<pre caption="Installation de iptables">
> # <i>emerge iptables</i>
> </pre>
> 
> </body>
> </section>
> <section>
>-<title>Kernel configuration</title>
>+<title>Configuration du noyau</title>
> <body>
> 
> <p>
>-Once installed, you should have an <c>iptables</c> command available for use, as
>-well as the handy iptables man page (<c>man iptables</c>). 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
>-<path>/usr/src/linux</path>, and type <c>make menuconfig</c> or <c>make
>-xconfig</c>; we're going to enable some kernel network functionality.
>+Une fois installée, vous devez avoir une commande <c>iptables</c> disponible,
>+ainsi que la page de manuel qui lui correspond (<c>man iptables</c>). 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 <path>/usr/src/linux</path>, tapez <c>make menuconfig</c> ou
>+<c>make xconfig</c>; nous allons choisir certaines fonctionnalités pour notre
>+noyau.
> </p>
> 
> <p>
>-Under the "Networking options" section, make sure that you enable at least the
>-following options:
>+ Dans la section "Networking options" (dans le menu "Networking-&gt;Networking
>+Options" pour le noyau 2.6), assurez-vous d'activer au moins les options
>+suivantes:
> </p>
> 
>-<pre caption="Necessary kernel options">
>+<pre caption="Fonctionnalités noyaux nécessaires">
> &lt;*&gt; Packet socket
> [*] Network packet filtering (replaces ipchains)
> &lt;*&gt; Unix domain sockets
>@@ -136,84 +144,88 @@
> </pre>
> 
> <p>
>-Then, under the "IP: Netfilter Configuration -&gt;" 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 -&gt;", 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.
> </p>
> 
> <p>
>-There's one networking option under the "Networking options" category that you
>-<e>shouldn't</e> enable: explicit congestion notification. Leave this option
>-disabled:
>+Il y a une fonctionnalité dans la section "Networking options" que vous ne
>+<e>devriez pas</e> activer: la notification explicite de congestion. Laissez
>+cette option décochée.
> </p>
> 
>-<pre caption="Option we have to disable">
>+<pre caption="L'option à désactiver">
> [ ]   IP: TCP Explicit Congestion Notification support
> </pre>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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 :)
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Firewall design basics</title>
>+<title>Premiers pas</title>
> <body>
> 
> <p>
>-In putting together our firewall, the <c>iptables</c> command is our friend.
>-It's what we use to interact with the network packet filtering rules in the
>-kernel.  We'll use the <c>iptables</c> 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 <c>iptables</c> 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 <c>iptables</c> 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 !)
> </p>
> 
>-<pre caption="Changing chain policy to DROP">
>+<pre caption="Choisir la politique par défaut DROP">
> # <i>iptables -P INPUT DROP</i>
> </pre>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Setting chain policy</title>
>+<title>Modifier la politique par défaut</title>
> <body>
> 
> <p>
>-An <c>iptables -P</c> command is used to set the default policy for a chain of
>-packet filtering rules. In this example, <c>iptables -P</c> 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 <c>iptables -P</c> est utilisée pour selectionner la politique par
>+défaut pour une chaine de filtrage de paquets. Dans cet exemple, <c>iptables
>+-P</c> 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.
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
>@@ -221,109 +233,116 @@
> </chapter>
> 
> <chapter>
>-<title>Defining rules</title>
>+<title>Definir ses règles</title>
> <section>
>-<title>A (small) improvement</title>
>+<title>Une (petite) amélioration</title>
> <body>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Improving our ultimate firewall">
>+<pre caption="Améliorons notre firewall ultime">
> # <i>iptables -P INPUT DROP</i>
> # <i>iptables -A INPUT -i ! eth1 -j ACCEPT</i>
> </pre>
> 
> <p>
>-This additional <c>iptables -A</c> 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 <c>iptables -A</c> 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é.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Following the INPUT chain</title>
>+<title>Le long de la chaine INPUT...</title>
> <body>
> 
> <p>
>-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).
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Traditional firewalls</title>
>+<title>Firewalls traditionnels</title>
> <body>
> 
> <p>
>-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).
> </p>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Accepting all the incoming http packets">
>+<pre caption="Acceptons tous les paquets HTTP entrants">
> # <i>iptables -A INPUT --sport 80 -j ACCEPT</i>
> </pre>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Traditional firewall bummers</title>
>+<title>Problèmes des firewalls traditionnels</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
>@@ -331,136 +350,140 @@
> </chapter>
> 
> <chapter>
>-<title>Stateful firewalls</title>
>+<title>Firewalls stateful</title>
> <section>
>-<title>State basics</title>
>+<title>Quelques mots sur les états</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Inside conntrack</title>
>+<title>Conntrack en détails</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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 <c>cat /proc/net/ip_conntrack</c>. 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 <c>cat /proc/net/ip_conntrack</c>. Même sans firewall
>+configuré, conntrack fonctionne en arrière-plan, en gardant trace des connexions
>+établies ou reçues par votre machine.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>The NEW connection state</title>
>+<title>Etat de connexion NEW</title>
> <body>
> 
> <p>
>-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 <c>ssh remote.host.com</c>, 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 <c>ssh
>+hote.distant.com</c>, 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).
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>The ESTABLISHED state</title>
>+<title>Etat de connexion ESTABLISHED</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>The RELATED state</title>
>+<title>Etat de connexion RELATED</title>
> <body>
> 
> <p>
>-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).
> </p>
> 
> </body>
> </section>
> <section>
>-<title>The INVALID state</title>
>+<title>Etat de connexion INVALID</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Adding a stateful rule</title>
>+<title>Ajout d'une règle stateful</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
>-<pre caption="Adding a stateful rule">
>+<pre caption="Ajout d'une règle stateful">
> # <i>iptables -P INPUT DROP</i>
> # <i>iptables -A INPUT -i ! eth1 -j ACCEPT</i>
> # <i>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT</i>
>@@ -469,95 +492,100 @@
> </body>
> </section>
> <section>
>-<title>How the rule works</title>
>+<title>Fonctionnement de cette règle</title>
> <body>
> 
> <p>
>-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 <c>ssh
>-remote.host.com</c>, 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é <c>ssh hote.distant.com</c>, 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.
> </p>
> 
> <p>
>-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é ?
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Incoming NEW packets</title>
>+<title>Paquets NEW entrants</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>A near-perfect firewall</title>
>+<title>Un firewall proche de la perfection</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>A basic firewall script</title>
>+<title>Un script de firewall simple</title>
> <body>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="A basic firewall script">
>+<pre caption="Un script de firewall simple">
> #!/bin/bash
>-<comment># A basic stateful firewall for a workstation or laptop that isn't running any</comment>
>-<comment># network services like a web server, SMTP server, ftp server, etc.</comment>
>+<comment># Un script de firewall simple pour une station de travail ou un
>+portable</comment>
>+<comment># qui ne fournit aucun service réseau, comme un  serveur web, ftp,
>+smtp, etc.</comment>
> 
> 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 @@
> </body>
> </section>
> <section>
>-<title>Using the script</title>
>+<title>Utilisation du script</title>
> <body>
> 
> <p>
>-Using this script, you can bring down the firewall by typing <c>./firewall
>-stop</c>, and bring it back up again by typing <c>./firewall start</c>. To bring
>-down the firewall, we flush our rules out of the INPUT chain with a <c>iptables
>--F INPUT</c>, and then switch the default INPUT policy back to ACCEPT with a
>-<c>iptables -P INPUT ACCEPT</c> 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 
>+<c>./firewall stop</c>, et le relancer en tapant <c>./firewall start</c>. Pour
>+désactiver le firewall, on supprime les règles de la chaine INPUT en faisant 
>+<c>iptables -F INPUT</c>, puis reprenons la politique par défaut de INPUT en
>+ACCEPT avec la commande <c>iptables -P INPUT ACCEPT</c>. 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.
> </p>
> 
> </body>
>@@ -585,21 +614,22 @@
> </chapter>
> 
> <chapter>
>-<title>Stateful improvements</title>
>+<title>Améliorations au suivi d'états</title>
> <section>
>-<title>Explicitly turn off ECN</title>
>+<title>Désactication explicite de l'ECN</title>
> <body>
> 
> <p>
>-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 <path>/proc</path> 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 <path>/proc</path> pour
>+désactiver explicitement l'ECN, comme ceci:
> </p>
> 
>-<pre caption="Explicitly turn off ECN">
>+<pre caption="Désactivation explicite de l'ECN">
> if [ -e /proc/sys/net/ipv4/tcp_ecn ]
> then
>         echo 0 > /proc/sys/net/ipv4/tcp_ecn
>@@ -613,12 +643,13 @@
> <body>
> 
> <p>
>-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:
> </p>
> 
> <pre caption="Forwarding">
>@@ -628,69 +659,72 @@
> </body>
> </section>
> <section>
>-<title>Handling rejection</title>
>+<title>Gestion des rejets</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Handling rejection">
>+<pre caption="Gestion des rejets">
> # <i>iptables -A INPUT -p tcp -i eth1 -j REJECT --reject-with tcp-reset</i>
>-# <i>iptables -A INPUT -p udp -i eth1 -j REJECT --reject-with icmp-port-unreachable</i>
>+# <i>iptables -A INPUT -p udp -i eth1 -j REJECT --reject-with
>+icmp-port-unreachable</i>
> </pre>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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).
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Spoof protection</title>
>+<title>Protection contre le Spoof</title>
> <body>
> 
> <p>
>-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 <path>/proc</path> 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 <path>/proc</path>. Voilà comment.
> </p>
> 
>-<pre caption="Spoof protection">
>+<pre caption="Protection contre le spoofing">
> for x in lo eth0 eth1
> do
>         echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
>@@ -698,9 +732,9 @@
> </pre>
> 
> <p>
>-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.
> </p>
> 
> </body>
>@@ -710,11 +744,12 @@
> <body>
> 
> <p>
>-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.
> </p>
> 
> <pre caption="Masquerading">
>@@ -722,11 +757,12 @@
> </pre>
> 
> <p>
>-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.
> </p>
> 
> </body>
>@@ -736,27 +772,28 @@
> <body>
> 
> <p>
>-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à.
> </p>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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:
> </p>
> 
> <pre caption="SNAT">
>@@ -764,101 +801,112 @@
> </pre>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>NAT issues</title>
>+<title>Problèmes avec le NAT</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Understanding tables</title>
>+<title>Comprendre les tables</title>
> <body>
> 
> <p>
>-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 <uri link="#resources">Resources</uri> 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 <uri link="#ressources">Ressources
>+</uri> plus bas pour les liens).
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Our enhanced script</title>
>+<title>Notre script amélioré</title>
> <body>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Our enhanced script">
>+<pre caption="Notre script amélioré">
> 
> #!/bin/bash
> 
>-<comment># An enhanced stateful firewall for a workstation, laptop or router that isn't</comment>
>-<comment># running any network services like a web server, SMTP server, ftp server, etc.</comment>
>-
>-<comment># Change this to the name of the interface that provides your "uplink"</comment>
>-<comment># (connection to the Internet)</comment>
>+<comment># Un firewall statefull amélioré pour une station de travail, portable
>+ou routeur</comment>
>+<comment># qui ne fourni aucun service réseau (comme serveur web, smtp, ftp,
>+etc.)</comment>
>+
>+<comment># Changez cette variable pour le nom de l'interface qui sert d'"uplink"
>+</comment>
>+<comment># (connexion à Internet)</comment>
> 
> UPLINK="eth1"
> 
>-<comment># If you're a router (and thus should forward IP packets between interfaces),</comment>
>-<comment># you want ROUTER="yes"; otherwise, ROUTER="no"</comment>
>+<comment># Si vous êtes un routeur, (et donc souhaitez forwarder les paquets IP
>+entre les interfaces),</comment>
>+<comment># mettez ROUTER="yes"; sinon, ROUTER="no"</comment>
> 
> ROUTER="yes"
> 
>-<comment># Change this next line to the static IP of your uplink interface for static SNAT, or</comment>
>-<comment># "dynamic" if you have a dynamic IP.  If you don't need any NAT, set NAT to "" to</comment>
>-<comment># disable it.</comment>
>+<comment># Changez la prochaine ligne pour mettre l'adresse IP statique de votre
>+interface
>+<comment># uplink pour faire du SNAT statique, ou "dynamic" si vous avez une IP
>+dynamique</comment>
>+<comment># Si vous n'avez pas besoin de NAT, laissez NAT="" pour le désactiver.
>+</comment>
> 
> NAT="1.2.3.4"
> 
>-<comment># Change this next line so it lists all your network interfaces, including lo</comment>
>+<comment># Changez cette variable pour lister toutes vos interfaces réseau, y
>+compris lo</comment>
> 
> 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
> 
>-        <comment># Explicitly disable ECN</comment>
>+        <comment># Desactivation explicite de l'ECN</comment>
>         if [ -e /proc/sys/net/ipv4/tcp_ecn ]
>         then
>                 echo 0 > /proc/sys/net/ipv4/tcp_ecn
>         fi
> 
>-        <comment># Disable spoofing on all interfaces</comment>
>+        <comment># Désactiver le spoofing sur toutes les interfaces</comment>
>         for x in ${INTERFACES}
>         do
>                 echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
>@@ -866,27 +914,31 @@
> 
>         if [ "$ROUTER" = "yes" ]
>         then
>-                <comment># We're a router of some kind, enable IP forwarding</comment>
>+                <comment># Activation de l'IP forwarding pour le routage
>+</comment>
>                 echo 1 > /proc/sys/net/ipv4/ip_forward
>                 if [ "$NAT" = "dynamic" ]
>                 then
>-                        <comment># Dynamic IP address, use masquerading</comment>
>-                        echo "Enabling masquerading (dynamic ip)..."
>-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE
>+                        <comment># Adresse IP dynamique, utilisation du
>+masquerading</comment>
>+                        echo "Activation du masquerading (IP dynamique)..."
>+                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j
>+MASQUERADE
>                 elif [ "$NAT" != "" ]
>                 then
>-                        <comment># Static IP, use SNAT</comment>
>-                        echo "Enabling SNAT (static ip)..."
>-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${UPIP}
>+                        <comment># IP statique, utilisation du SNAT</comment>
>+                        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
>-        <comment># Turn off NAT/masquerading, if any</comment>
>+        <comment># Désactive le NAT/masquerading</comment>
>         iptables -t nat -F POSTROUTING
> fi
> </pre>
>@@ -896,28 +948,28 @@
> </chapter>
> 
> <chapter>
>-<title>Stateful servers</title>
>+<title>Servers statefuls</title>
> <section>
>-<title>Viewing rules</title>
>+<title>Voir ses règles</title>
> <body>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Viewing rules">
>+<pre caption="Voir les règles">
> # <i>iptables -v -L INPUT</i>
> </pre>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Viewing POSTROUTING table rules">
>+<pre caption="Voir les règles de la chaine POSTROUTING de la table nat">
> # <i>iptables -t nat -v -L POSTROUTING</i>
> Chain POSTROUTING (policy ACCEPT 399 packets, 48418 bytes)
> pkts bytes target     prot opt in     out     source               destination
>@@ -928,52 +980,53 @@
> </body>
> </section>
> <section>
>-<title>Getting ready for service</title>
>+<title>Prêts pour le service</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Stateful HTTP</title>
>+<title>HTTP stateful</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Stateful HTTP example</title>
>+<title>Exemple d'HTTP stateful</title>
> <body>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Stateful HTTP example">
>+<pre caption="Exemple d'HTTP stateful">
> iptables -P INPUT DROP
> iptables -A INPUT -i ! ${UPLINK} -j ACCEPT
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>-<comment># Our new rule follows</comment>
>+<comment># Notre nouvelle règle</comment>
> 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 @@
> </pre>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Our final firewall script</title>
>+<title>Notre script de firewall avancé</title>
> <body>
> 
> <p>
>-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&nbsp;!)
> </p>
> 
>-<pre caption="Our final firewall script">
>+<pre caption="Notre script de firewall avancé">
> 
> #!/bin/bash
> 
>-<comment># Our complete stateful firewall script.  This firewall can be customized for</comment>
>-<comment># a laptop, workstation, router or even a server. :)</comment>
>+<comment># Notre script de firewall complement stateful. Ce firewall peut
>+être adapté</comment>
>+<comment># pour un portable, station de travail, routeur ou même un serveur. :)
>+</comment>
> 
>-<comment># Change this to the name of the interface that provides your "uplink"</comment>
>-<comment># (connection to the Internet)</comment>
>+<comment># Changez cette variable pour le no de l'interface "uplink"</comment>
>+<comment># (connexion vers Internet)</comment>
> 
> UPLINK="eth1"
> 
>-<comment># If you're a router (and thus should forward IP packets between interfaces),</comment>
>-<comment># you want ROUTER="yes"; otherwise, ROUTER="no"</comment>
>+<comment># Si vous êtes routeur (et donc souhaitez forwarder les paquets IP
>+entre les</comment>
>+<comment># interfaces), mettez ROUTER="yes"; sinon, ROUTER="no"</comment>
> 
> ROUTER="yes"
> 
>-<comment># Change this next line to the static IP of your uplink interface for static SNAT, or</comment>
>-<comment># "dynamic" if you have a dynamic IP.  If you don't need any NAT, set NAT to "" to</comment>
>-<comment># disable it.</comment>
>+<comment># Changez la prochaine ligne vers l'adresse IP statique de votre
>+interface</comment>
>+<comment># uplink pour du SNAT statique, ou "dynamic" si vous avez une IP
>+dynamique.</comment>
>+<comment># Si vous ne voulez pas de NAT, mettez NAT="" pour le désactiver.
>+</comment>
> 
> NAT="1.2.3.4"
> 
>-<comment># Change this next line so it lists all your network interfaces, including lo</comment>
>+<comment># Changez cette ligne pour lister toutes vos interfaces réseaux, y
>+compris lo</comment>
> 
> INTERFACES="lo eth0 eth1"
> 
>-<comment># Change this line so that it lists the assigned numbers or symbolic names (from</comment>
>-<comment># /etc/services) of all the services that you'd like to provide to the general</comment>
>-<comment># public. If you don't want any services enabled, set it to ""</comment>
>+<comment># Changez cette ligne pour lister les numéros de ports ou noms
>+symboliques</comment>
>+<comment># (de /etc/services) de tous les services que vous souhaiter rendre
>+publics.</comment>
>+<comment># Si vous ne souhaitez publiez aucun service, laissez ""</comment>
> 
> 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
> 
>-        <comment># Enable public access to certain services</comment>
>+        <comment># Activer l'accès publics aux services</comment>
>         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
> 
>-        <comment># Explicitly disable ECN</comment>
>+        <comment># Désactivation explicite de l'ECN</comment>
>         if [ -e /proc/sys/net/ipv4/tcp_ecn ]
>         then
>                 echo 0 > /proc/sys/net/ipv4/tcp_ecn
>         fi
> 
>-        <comment># Disable spoofing on all interfaces</comment>
>+        <comment># Protection anti-spoofing</comment>
>         for x in ${INTERFACES}
>         do
>         echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
>@@ -1061,27 +1127,29 @@
> 
>         if [ "$ROUTER" = "yes" ]
>         then
>-                <comment># We're a router of some kind, enable IP forwarding</comment>
>+                <comment># Activation de l'IP forwarding</comment>
>                 echo 1 > /proc/sys/net/ipv4/ip_forward
>                 if [ "$NAT" = "dynamic" ]
>                 then
>-                <comment># Dynamic IP address, use masquerading</comment>
>-                echo "Enabling masquerading (dynamic ip)..."
>-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE
>+                <comment># IP dynamique => masquerading</comment>
>+                echo "Activation du masquerading (ip dynamique)..."
>+                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j
>+MASQUERADE
>                 elif [ "$NAT" != "" ]
>                 then
>-                        <comment># Static IP, use SNAT</comment>
>-                        echo "Enabling SNAT (static ip)..."
>-                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${UPIP}
>+                        <comment># IP statique => SNAT</comment>
>+                        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
>-        <comment># Turn off NAT/masquerading, if any</comment>
>+        <comment># Arrêt du masquerading</comment>
>         iptables -t nat -F POSTROUTING
> fi
> </pre>
>@@ -1091,127 +1159,134 @@
> </chapter>
> 
> <chapter>
>-<title>Building a better server firewall</title>
>+<title>Construire un meilleur firewall pour serveur</title>
> <section>
>-<title>Server improvements</title>
>+<title>Améliorations</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Logging techniques</title>
>+<title>Techniques de log</title>
> <body>
> 
> <p>
>-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 <c>--log-prefix</c> 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 <c>--log-prefix</c> 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:
> </p>
> 
>-<pre caption="Example log rule">
>-# <i> iptables -A INPUT -j LOG --log-prefix "bad input:"</i>
>+<pre caption="Exemple de règle LOG">
>+# <i> iptables -A INPUT -j LOG --log-prefix "Anomalie INPUT:"</i>
> </pre>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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.
> </p>
> 
> <p>
>-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:
> </p>
> 
>-<pre caption="Limiting log entries">
>-# <i>iptables -A INPUT -m state --state INVALID -m limit --limit 5/minute -j LOG --log-prefix "INVALID STATE:"</i>
>+<pre caption="Limiter la taille des logs">
>+# <i>iptables -A INPUT -m state --state INVALID -m limit --limit 5/minute -j LOG
>+--log-prefix "Etat INVALID:"</i>
> </pre>
> 
> </body>
> </section>
> <section>
>-<title>Creating your own chains</title>
>+<title>Créer vos propres chaines</title>
> <body>
> 
> <p>
>-<c>iptables</c> 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 (<uri>http://www.netfilter.org/</uri>).
>+<c>iptables</c> 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 (<uri>http://www.netfilter.org/</uri>).
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Enforcing network usage policy</title>
>+<title>Politique de restriction d'usages</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Other security angles</title>
>+<title>Autres angles de la sécurité</title>
> <body>
> 
> <p>
>-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é.
> </p>
> 
> </body>
> </section>
> </chapter>
> 
>-<chapter id="resources">
>-<title>Resources</title>
>+<chapter id="ressources">
>+<title>Ressources</title>
> <section>
> <title>tcpdump</title>
> <body>
> 
> <p>
>-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...
> </p>
> 
> <p>
>-<uri link="http://www.tcpdump.org/">tcpdump</uri> 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.
>+<uri link="http://www.tcpdump.org/">tcpdump</uri> 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.
> </p>
> 
> </body>
>@@ -1221,10 +1296,11 @@
> <body>
> 
> <p>
>-Visit the netfilter/iptables project home page
>-(<uri>http://www.netfilter.org</uri>).  You'll find many resources at this site,
>+Visitez le site web du projet netfilter/iptables 
>+(<uri>http://www.netfilter.org</uri>). You'll find many resources at this site,
> including the iptables sources and a <uri
>-link="http://www.netfilter.org/documentation/index.html#documentation-faq">netfilter
>+link="http://www.netfilter.org/documentation/index.html#documentation-faq">
>+netfilter
> FAQ</uri>. Also <uri
> link="http://people.netfilter.org/~rusty/unreliable-guides/index.html">Rusty's
> Remarkably Guides</uri> are excellent, and include a basic networking concepts
>@@ -1235,13 +1311,14 @@
> </body>
> </section>
> <section>
>-<title>iptables man page</title>
>+<title>La page de manuel iptables</title>
> <body>
> 
> <p>
>-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.
> </p>
> 
> </body>
>@@ -1251,17 +1328,20 @@
> <body>
> 
> <p>
>-There's now an <uri link="http://www.ds9a.nl/2.4Routing/">Advanced Linux Routing
>-and Traffic Control HOWTO</uri> 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 <uri link="http://www.ds9a.nl/2.4Routing/">Advanced Linux Routing and
>+Traffic Control HOWTO</uri> est disponible (également
>+<uri link="http://www.linux-france.org/prj/inetdoc/guides/lartc/">
>+en français</uri>). 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.
> </p>
> 
> <note>
>-This HOWTO contains references to Linux's traffic control (quality of service)
>-functionality (accessed through the new <c>tc</c> 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 <c>tc</c>). 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.
> </note>
> 
> </body>
>@@ -1271,22 +1351,22 @@
> <body>
> 
> <p>
>-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 <uri
>-link="http://www.netfilter.org/mailinglists.html#ml-user">netfilter user mailing
>-list</uri>.
>+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 
>+<uri link="http://www.netfilter.org/mailinglists.html#ml-user">la mailing-list
>+des utilisateurs de Netfilter</uri>.
> </p>
> 
> <p>
>-Netfilter/iptables developers who have questions, suggestions, or contributions
>-to netfilter/iptables development can contact the <uri
>-link="http://www.netfilter.org/mailinglists.html#ml-devel">netfilter developer
>-mailing list</uri>.
>+Les développeurs Netfilter/iptables qui ont des questions, suggestions ou
>+contributions pour le developpement de Netfilter/iptables peuvent contacter <uri
>+link="http://www.netfilter.org/mailinglists.html#ml-devel">la mailing-list des
>+développeurs de Netfilter</uri>.
> </p>
> 
> <p>
>-You can also browse the list archives at these URLs.
>+Vous pouvez aussi parcourir les archives de mailing-list sur ces URLs.
> </p>
> 
> </body>
>@@ -1296,27 +1376,27 @@
> <body>
> 
> <p>
>-In June 2000, O'Reilly released an excellent book -- <uri
>-link="http://www.oreilly.com/catalog/fire2/">Building Internet Firewalls, Second
>-Edition</uri>. 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 -- <uri
>+link="http://www.oreilly.com/catalog/fire2/">Building Internet Firewalls,
>+Second Edition</uri>. 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.
> </p>
> 
> <p>
>-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.
> </p>
> 
> </body>
> </section>
> <section>
>-<title>Your feedback</title>
>+<title>Vos remarques</title>
> <body>
> 
> <p>
>-We look forward to getting your feedback on this tutorial. Additionally, you are
>-welcome to contact the author, Daniel Robbins, at <mail
>+Nous acceptons volontier vos remarques sur ce tutorial. De plus, n'hésitez pas
>+à contacter l'auteur, Daniel Robbins, à l'adresse <mail
> link="drobbins@gentoo.org">drobbins@gentoo.org</mail>.
> </p>
>

Actions: View | Diff

Attachments on bug 122377: 79438 | 79439