Attachment #79439 for bug #122377

View | Details | Raw Unified | Return to bug 122377
Collapse All | Expand All




<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/articles/linux-24-
stateful-fw-design.xml,v 1.5 2005/10/09 17:13:23 rane Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">

<guide link="/doc/en/articles/linux-24-stateful-fw-design.xml"
disclaimer="articles">
<title>Firewall stateful sous Linux 2.4</title>

<author title="Auteur">
  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
</author>

<abstract>
Ce guide va vous apprendre à batir un puissant firewall stateful en utilisant
NetFilter sous Linux.
</abstract>

<!-- La version originale de ce document a été rendu publique sur IBM
developerWorks, et est la propriété de Westtech Information Services. Ce
document est une version mise à jour de l'original, et contient plusieurs
améliorations apportées par l'équipe de Documentation de Gentoo Linux -->

<version>1.3</version>
<date>2005-10-09</date>

<chapter>
<title>A propos de ce guide</title>
<section>
<title>A qui s'adresse ce guide ?</title>
<body>

<p>
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>
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>A propos de l'auteur</title>
<body>

<p>
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>
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>

</chapter>

<chapter>
<title>Premières étapes</title>
<section>
<title>Le but du jeu</title>
<body>

<p>
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>Les outils nécessaires</title>
<body>

<p>
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="Installation de iptables">
# <i>emerge iptables</i>
</pre>

</body>
</section>
<section>
<title>Configuration du noyau</title>
<body>

<p>
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>
 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="Fonctionnalités noyaux nécessaires">
&lt;*&gt; Packet socket
[*] Network packet filtering (replaces ipchains)
&lt;*&gt; Unix domain sockets

</pre>

<p>
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>
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="L'option à désactiver">
[ ]   IP: TCP Explicit Congestion Notification support
</pre>

<p>
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>
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>Premiers pas</title>
<body>

<p>
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="Choisir la politique par défaut DROP">
# <i>iptables -P INPUT DROP</i>
</pre>

<p>
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>Modifier la politique par défaut</title>
<body>

<p>
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>
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>

</chapter>

<chapter>
<title>Definir ses règles</title>
<section>
<title>Une (petite) amélioration</title>
<body>

<p>
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="Améliorons notre firewall ultime">
# <i>iptables -P INPUT DROP</i>
# <i>iptables -A INPUT -i ! eth1 -j ACCEPT</i>
</pre>

<p>
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>Le long de la chaine INPUT...</title>
<body>

<p>
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>
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>Firewalls traditionnels</title>
<body>

<p>
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>
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="Acceptons tous les paquets HTTP entrants">
# <i>iptables -A INPUT --sport 80 -j ACCEPT</i>
</pre>

<p>
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>Problèmes des firewalls traditionnels</title>
<body>

<p>
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>
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>

</chapter>

<chapter>
<title>Firewalls stateful</title>
<section>
<title>Quelques mots sur les états</title>
<body>

<p>
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>
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>Conntrack en détails</title>
<body>

<p>
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>
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>Etat de connexion NEW</title>
<body>

<p>
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>
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>Etat de connexion ESTABLISHED</title>
<body>

<p>
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>Etat de connexion RELATED</title>
<body>

<p>
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>Etat de connexion INVALID</title>
<body>

<p>
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>Ajout d'une règle stateful</title>
<body>

<p>
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="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>

</body>
</section>
<section>
<title>Fonctionnement de cette règle</title>
<body>

<p>
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>
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>
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>Paquets NEW entrants</title>
<body>

<p>
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>Un firewall proche de la perfection</title>
<body>

<p>
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>Un script de firewall simple</title>
<body>

<p>
Voilà un script simple qui peut être utilisé pour configurer notre premier
firewall de station de travail:
</p>

<pre caption="Un script de firewall simple">
#!/bin/bash
<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 "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 "Arrêt du firewall..."
        iptables -F INPUT
        iptables -P INPUT ACCEPT
fi

</body>
</section>
<section>
<title>Utilisation du script</title>
<body>

<p>
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>

</chapter>

<chapter>
<title>Améliorations au suivi d'états</title>
<section>
<title>Désactication explicite de l'ECN</title>
<body>

<p>
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="Désactivation explicite de l'ECN">
if [ -e /proc/sys/net/ipv4/tcp_ecn ]
then
        echo 0 > /proc/sys/net/ipv4/tcp_ecn

<body>

<p>
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">

</body>
</section>
<section>
<title>Gestion des rejets</title>
<body>

<p>
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>
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="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>
</pre>

<p>
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>
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>Protection contre le Spoof</title>
<body>

<p>
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="Protection contre le spoofing">
for x in lo eth0 eth1
do
        echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter

</pre>

<p>
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>

<body>

<p>
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">

</pre>

<p>
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>

<body>

<p>
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>
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>
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">

</pre>

<p>
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>Problèmes avec le NAT</title>
<body>

<p>
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>Comprendre les tables</title>
<body>

<p>
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>Notre script amélioré</title>
<body>

<p>
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="Notre script amélioré">

#!/bin/bash

<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># 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># 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># Changez cette variable pour lister toutes vos interfaces réseau, y
compris lo</comment>

INTERFACES="lo eth0 eth1"

if [ "$1" = "start" ]
then
        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

        <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># Désactiver le spoofing sur toutes les interfaces</comment>
        for x in ${INTERFACES}
        do
                echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter


        if [ "$ROUTER" = "yes" ]
        then
                <comment># Activation de l'IP forwarding pour le routage
</comment>
                echo 1 > /proc/sys/net/ipv4/ip_forward
                if [ "$NAT" = "dynamic" ]
                then
                        <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># 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 "Arret du firewall..."
        iptables -F INPUT
        iptables -P INPUT ACCEPT
        <comment># Désactive le NAT/masquerading</comment>
        iptables -t nat -F POSTROUTING
fi
</pre>

</chapter>

<chapter>
<title>Servers statefuls</title>
<section>
<title>Voir ses règles</title>
<body>

<p>
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="Voir les règles">
# <i>iptables -v -L INPUT</i>
</pre>

<p>
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="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

</body>
</section>
<section>
<title>Prêts pour le service</title>
<body>

<p>
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>HTTP stateful</title>
<body>

<p>
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>Exemple d'HTTP stateful</title>
<body>

<p>
Jetons un oeil au "coeur" de notre firewall et à la nouvelle règle qui autorise
les connexion HTTP entrantes:
</p>

<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># 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

</pre>

<p>
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>Notre script de firewall avancé</title>
<body>

<p>
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="Notre script de firewall avancé">

#!/bin/bash

<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># Changez cette variable pour le no de l'interface "uplink"</comment>
<comment># (connexion vers Internet)</comment>

UPLINK="eth1"

<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># 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># Changez cette ligne pour lister toutes vos interfaces réseaux, y
compris lo</comment>

INTERFACES="lo eth0 eth1"

<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 "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># 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
        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

        <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># Protection anti-spoofing</comment>
        for x in ${INTERFACES}
        do
        echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter


        if [ "$ROUTER" = "yes" ]
        then
                <comment># Activation de l'IP forwarding</comment>
                echo 1 > /proc/sys/net/ipv4/ip_forward
                if [ "$NAT" = "dynamic" ]
                then
                <comment># IP dynamique => masquerading</comment>
                echo "Activation du masquerading (ip dynamique)..."
                        iptables -t nat -A POSTROUTING -o ${UPLINK} -j
MASQUERADE
                elif [ "$NAT" != "" ]
                then
                        <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 "Arrêt du firewall..."
        iptables -F INPUT
        iptables -P INPUT ACCEPT
        <comment># Arrêt du masquerading</comment>
        iptables -t nat -F POSTROUTING
fi
</pre>

</chapter>

<chapter>
<title>Construire un meilleur firewall pour serveur</title>
<section>
<title>Améliorations</title>
<body>

<p>
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>Techniques de log</title>
<body>

<p>
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="Exemple de règle LOG">
# <i> iptables -A INPUT -j LOG --log-prefix "Anomalie INPUT:"</i>
</pre>

<p>
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>
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>
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="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>Créer vos propres chaines</title>
<body>

<p>
<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>Politique de restriction d'usages</title>
<body>

<p>
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>Autres angles de la sécurité</title>
<body>

<p>
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="ressources">
<title>Ressources</title>
<section>
<title>tcpdump</title>
<body>

<p>
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> 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>

<body>

<p>
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
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

</body>
</section>
<section>
<title>La page de manuel iptables</title>
<body>

<p>
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>

<body>

<p>
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>
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>

<body>

<p>
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>
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>
Vous pouvez aussi parcourir les archives de mailing-list sur ces URLs.
</p>

</body>

<body>

<p>
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>
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>Vos remarques</title>
<body>

<p>
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>


Return to bug 122377