path: root/fr_FR.ISO8859-1/articles/filtering-bridges/article.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
	"../../../share/xml/freebsd45.dtd">

<!--
	The FreeBSD Project - http://www.FreeBSD.org
	The FreeBSD French Documentation Project

	$FreeBSD$
	Original revision: 1.18
-->

<article lang="fr">
  <articleinfo>
    <title>Ponts filtrants</title>

    <authorgroup>
      <author>
        <firstname>Alex</firstname>
        <surname>Dupre</surname>
        <affiliation>
	  <address><email>ale@FreeBSD.org</email></address>
        </affiliation>
      </author>
    </authorgroup>

    <legalnotice id="trademarks" role="trademarks">
      &tm-attrib.freebsd;
      &tm-attrib.3com;
      &tm-attrib.intel;
      &tm-attrib.general;
    </legalnotice>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <abstract>
      <para>Souvent il est utile de diviser un réseau physique (comme un
	réseau Ethernet) en deux segments séparés sans
	avoir &agrave; créer des sous-réseaux, et utiliser de routeur
	pour les relier ensemble.  Le dispositif qui connecte les deux
	réseaux de cette manière est
	appelé un pont.  Un système FreeBSD avec deux cartes
	réseau est suffisant pour jouer le rôle d'un pont.</para>

      <para>Un pont fonctionne en scannant les adresses au niveau
	<acronym>MAC</acronym> (adresses Ethernet) des cartes connectées
	&agrave; chacune de ses interfaces réseau et puis
	transfère le trafic entre les deux réseaux si la
	source et la destination sont situées sur un segment
	différent.  Sous beaucoup de points de vue
	un pont est similaire &agrave; un commutateur (switch) Ethernet avec
	uniquement deux ports.</para>

	&trans.a.fonvieille;
    </abstract>
  </articleinfo>

  <sect1 id="filtering-bridges-why">
    <title>Pourquoi utiliser un pont filtrant?</title>

    <para>De plus en plus fréquemment, grâce &agrave; la
      baisse des coûts des connexions Internet haut débit
      (xDSL) et aussi en raison de la réduction des adresses
      IPv4 disponibles, beaucoup de compagnies
      sont connectées &agrave; l'Internet 24 heures sur 24 et
      avec peu (parfois même pas une puissance de 2) d'adresses IP.
      Dans ces situations il est souvent désirable d'avoir un
      coupe-feu qui filtre le trafic
      entrant et sortant depuis et vers l'Internet, mais la solution
      d'un filtrage de paquet basé sur un routeur peut ne pas
      être applicable, soit en raison de problèmes de
      sous-réseau, le routeur appartient au fournisseur
      d'accès (<acronym>ISP</acronym>), ou
      parce qu'il ne supporte pas une telle fonction.  Dans ces
      scénarios l'utilisation d'un pont filtrant est fortement
      conseillée.</para>

    <para>Un coupe-feu basé sur un pont peut être
      configuré et inséré
      entre le routeur xDSL et votre concentrateur/commutateur Ethernet
      sans aucun problème d'adresse d'IP.</para>
  </sect1>

  <sect1 id="filtering-bridges-how">
    <title>Comment l'installer</title>

    <para>Ajouter les fonctions de pont &agrave; un système
      FreeBSD n'est pas difficile.  Depuis la 4.5-RELEASE il est possible
      de charger de telles fonctionnalités sous forme de module
      au lieu d'avoir &agrave; recompiler le noyau, simplifiant
      énormément la procédure.  Dans
      les sous-sections suivantes j'expliquerai les deux méthodes
      d'installation.</para>

    <important>
      <para><emphasis>Ne pas</emphasis> suivre les deux méthodes: une
	procédure <emphasis>exclue</emphasis> l'autre.  Choisissez la
	meilleure en fonction de vos besoins et capacités.</para>
    </important>

    <para>Avant d'aller plus loin, soyez sûr de disposer deux cartes
      Ethernet qui supportent le mode promiscuous pour la réception et
      la transmission, comme elles doivent être capables d'envoyer des
      paquets Ethernet avec n'importe quelle adresse, et non pas juste
      pour la leur.  De plus, pour avoir de bonnes performances, les
      cartes devront être capable contrôler le bus
      PCI (PCI bus mastering).  Les meilleurs choix sont toujours
      l'Intel &etherexpress; Pro, suivie de la série 3c9xx de chez &tm.3com;.
      Pour simplifier la configuration il peut être utile d'avoir deux
      cartes de différents constructeurs (utilisant un pilote de
      périphérique différent) afin de distinguer
      clairement quelle interface est connectée au routeur et
      quelle autre est connectée au réseau.</para>

    <sect2 id="filtering-bridges-kernel">
      <title>Configuration du noyau</title>

      <para>Donc vous avez décidé d'utiliser la bonne
	vieille méthode d'installation.  Pour commencer, vous
	devez ajouter les lignes suivantes &agrave; votre fichier de
	configuration du noyau:</para>

      <programlisting>options BRIDGE
options IPFIREWALL
options IPFIREWALL_VERBOSE</programlisting>

      <para>La première ligne est pour compiler le support du pont, la
	seconde est le coupe-feu et la troisième sont les fonctions de
	traces du coupe-feu.</para>

      <para>Maintenant il est nécessaire de compiler et d'installer le
	nouveau noyau.  Vous pourrez trouver des instructions
	détaillées dans la section <ulink
	url="../../books/handbook/kernelconfig-building.html">Compiler
	et installer un noyau sur mesures</ulink> du Manuel de
	FreeBSD.</para>
    </sect2>

    <sect2 id="filtering-bridges-modules">
      <title>Le chargement de modules</title>

      <para>Si vous avez choisi d'employer cette méthode nouvelle et
	plus simple; la seule chose &agrave; faire maintenant est d'ajouter la
	ligne suivante au fichier
	<filename>/boot/loader.conf</filename>:</para>

      <programlisting>bridge_load="YES"</programlisting>

      <para>De cette façon, durant le démarrage du
	système le module <filename>bridge.ko</filename> sera
	chargé avec le noyau.  Il n'est pas nécessaire
	de rajouter une ligne pour le module
	<filename>ipfw.ko</filename>, étant donné qu'il
	sera chargé automatiquement après
	l'exécution des étapes présentées dans la
	section suivante.</para>
    </sect2>
  </sect1>

  <sect1 id="filtering-bridges-finalprep">
    <title>Dernière préparation</title>

    <para>Avant de redémarrer afin de charger le nouveau noyau ou les
      modules nécessaires (selon la méthode d'installation
      précédemment retenue), vous devez faire quelques
      modifications dans le fichier
      de configuration <filename>/etc/rc.conf</filename>.  La règle de
      défaut du coupe-feu est de rejeter tous les paquets IP.  Au
      départ nous configurerons un coupe-feu &ldquo;ouvert&rdquo;, afin
      de vérifier son fonctionnement sans problème relatif au
      filtrage de paquet (dans le cas où vous faite cela &agrave;
      distance, une telle configuration vous évitera de rester
      isolé du réseau).  Ajoutez les lignes suivantes dans
      <filename>/etc/rc.conf</filename>:</para>

    <programlisting>firewall_enable="YES"
firewall_type="open"
firewall_quiet="YES"
firewall_logging="YES"</programlisting>

    <para>La première ligne activera le coupe-feu (et chargera le module
      <filename>ipfw.ko</filename> s'il n'est pas compilé dans le
      noyau), la seconde le configurera dans le mode
      &ldquo;ouvert&rdquo; (comme expliqué dans
      <filename>/etc/rc.firewall</filename>), la troisième ligne rendra
      le chargement des règles silencieux (sans affichage) et la
      quatrième activera le support de trace d'activité
      du coupe-feu.</para>

    <para>Au sujet de la configuration des interfaces réseau, la
      méthode la plus utilisée est d'assigner une adresse
      IP &agrave; une seule des cartes réseau, mais le pont
      fonctionnera &agrave; l'identique si les deux
      interfaces ou aucune n'ont d'adresse IP configurée.  Dans le
      dernier cas (sans adresse IP) la machine faisant office de pont
      sera toujours cachée et inaccessible depuis le réseau:
      pour la configurer, vous devez vous attacher depuis la console ou
      &agrave; travers une troisième interface réseau
      séparée du pont.  Parfois, durant
      le démarrage du système, certains programmes ont
      besoin d'accéder au réseau, par exemple pour la
      résolution de noms: dans ce cas il
      est nécessaire d'assigner une adresse IP &agrave;
      l'interface externe (celle connectée &agrave; l'Internet
      où le serveur <acronym>DNS</acronym>
      réside), puisque le pont sera activé &agrave; la
      fin de la procédure de démarrage.  Cela signifie que
      l'interface <devicename>fxp0</devicename> (dans notre cas) doit
      être mentionnée dans la section concernant ifconfig
      du fichier <filename>/etc/rc.conf</filename>, mais pas
      <devicename>xl0</devicename>.  Assigner une adresse IP aux deux
      cartes réseau n'a pas beaucoup de sens, &agrave; moins que,
      durant la procédure de démarrage, des applications
      devront accéder &agrave; des
      services sur les deux segments Ethernet.</para>

    <para>Il y a une autre chose importante &agrave; savoir.  Quand on utilise
      l'IP sur Ethernet, il y a en fait deux protocoles Ethernet
      utilisés: l'un est l'IP, l'autre est l'<acronym>ARP</acronym>.
      <acronym>ARP</acronym> effectue la conversion de l'adresse IP d'un
      hôte en son adresse Ethernet (couche <acronym>MAC</acronym>).
      Afin d'autoriser la communication entre deux hôtes
      séparés par le
      pont, il est nécessaire que le pont transmette les paquets
      <acronym>ARP</acronym>.  Un tel protocole n'est pas inclus dans la
      couche IP, puisque qu'il n'apparaît qu'avec l'utilisation de l'IP
      sur Ethernet.  Le coupe-feu de FreeBSD filtre exclusivement la
      couche IP et donc tous les paquets non-IP (<acronym>ARP</acronym>
      compris) seront transmis sans être filtrés, même
      si le coupe-feu est configuré pour ne rien laisser passer.</para>

    <para>Il est maintenant temps de redémarrer le système et de
      l'utiliser comme auparavant: il y aura de nouveaux messages
      concernant le pont et le coupe-feu, mais le pont ne sera pas
      activé et le coupe-feu, étant en mode &ldquo;ouvert&rdquo;,
      n'interdira aucune opération.</para>

    <para>Si il y a un quelconque problème, vous devriez le corriger
      maintenant avant de continuer.</para>
  </sect1>

  <sect1 id="filtering-bridges-enabling">
    <title>Activer le pont</title>

    <para>A ce point, pour activer le pont, vous devez exécuter les
      commandes suivantes (en pensant bien de remplacer les noms des deux
      interfaces réseau <devicename>fxp0</devicename> et
      <devicename>xl0</devicename> avec les vôtres):</para>

    <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput>
&prompt.root; <userinput>sysctl net.link.ether.bridge.ipfw=1</userinput>
&prompt.root; <userinput>sysctl net.link.ether.bridge.enable=1</userinput></screen>

    <para>La première ligne spécifie quelles interfaces
      devront être activées par le pont, la seconde
      activera le coupe-feu sur le pont
      et enfin la troisième activera le pont.</para>

    <note>
      <para>Si vous utiliser &os;&nbsp;5.1-RELEASE ou une version
	précédente, les variables sysctl diffèrent.
	Consultez la page de manuel &man.bridge.4; pour plus de
	détails.</para>
    </note>

    <para>A ce moment l&agrave;, vous devriez être en mesure
      d'insérer la machine entre deux ensembles d'hôtes
      sans compromettre de capacités de communication entre eux.
      Ensuite, l'étape suivante est d'ajouter les parties
      <literal>net.link.ether.bridge.<replaceable>[bla]</replaceable>=<replaceable>[bla]</replaceable></literal>
      de ces lignes dans le fichier
      <filename>/etc/sysctl.conf</filename> afin de les exécuter au
      démarrage.</para>
  </sect1>

  <sect1 id="filtering-bridges-ipfirewall">
    <title>Configurer le coupe-feu</title>

    <para>Il est maintenant temps de créer votre propre fichier de
      règle personnalisé pour le coupe-feu, afin de
      sécuriser le réseau
      interne.  Il y aura quelques complications &agrave; faire cela parce que
      toutes les fonctionnalités du coupe-feu ne sont pas disponibles sur
      un pont.  En outre, il y a une différence entre les paquets qui
      sont en cours de transmission et les paquets qui sont reçus par la
      machine locale.  En général, les paquets entrants
      traversent le coupe-feu une seule fois, et pas deux comme c'est
      normalement le cas; en fait ils sont filtrés &agrave; la
      réception, aussi les règles qui
      utilisent &ldquo;out&rdquo; ou &ldquo;xmit&rdquo; n'agiront
      jamais.  Personnellement, j'utilise &ldquo;in via&rdquo; qui est
      une ancienne syntaxe, mais qui a un sens quand vous la lisez.  Une
      autre limitation est que vous êtes réduit &agrave;
      l'utilisation seulement des commandes &ldquo;pass&rdquo; ou
      &ldquo;drop&rdquo; pour les paquets filtrés par un pont.
      Les choses sophistiquées comme &ldquo;divert&rdquo;,
      &ldquo;forward&rdquo; ou &ldquo;reject&rdquo; ne sont pas
      disponibles.  De telles options peuvent toujours être
      utilisées, mais uniquement sur le trafic &agrave;
      destination ou depuis le pont lui-même (s'il possède
      une adresse IP).</para>

    <para>Une nouveauté de FreeBSD 4.0, est le concept de filtrage avec
      gestion des états (stateful).  C'est une grande
      amélioration pour le trafic <acronym>UDP</acronym>, qui
      typiquement est une requête de sortie, suivie peu de temps
      après par une réponse avec le même ensemble
      d'adresses IP et de numéro de ports (mais avec
      une source et une destination réservée, bien sûr).
      Pour les coupe-feux qui n'ont pas de gestion des états,
      il n'y a presque pas de possibilité de gérer ce type
      de trafic en une seule session.  Mais avec un coupe-feu qui peut se
      &ldquo;souvenir&rdquo; d'un paquet <acronym>UDP</acronym> sortant et
      qui, pour quelques minutes, autorise une réponse, la gestion
      des services <acronym>UDP</acronym> est triviale.  L'exemple suivant
      montre comment le faire.  Il est possible de faire la même
      chose avec les paquets <acronym>TCP</acronym>.  Cela vous permet
      d'éviter certaines attaques par refus de service et autres
      désagréables problèmes, mais augmente
      également rapidement la taille de votre
      table des états.</para>

    <para>Regardons un exemple de configuration.  Notez tout d'abord
      qu'au début du fichier <filename>/etc/rc.firewall</filename>
      il y a déj&agrave; des règles standards pour
      l'interface de boucle locale
      <devicename>lo0</devicename>, aussi nous ne devrions pas y faire
      attention.  Les règles personnalisées devraient
      être placées dans un fichier séparé (disons
      <filename>/etc/rc.firewall.local</filename>) et chargées au
      démarrage du système, en modifiant la ligne de
      <filename>/etc/rc.conf</filename> où nous avions défini le
      coupe-feu &ldquo;ouvert&rdquo;:</para>

    <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>

    <important>
      <para>Vous devez préciser le chemin <emphasis>complet</emphasis>,
	sinon il ne sera pas chargé avec le risque de rester
	isolé du réseau.</para>
    </important>

    <para>Pour notre exemple imaginez que nous avons l'interface
      <devicename>fxp0</devicename> connectée vers l'extérieur
      (Internet) et l'interface <devicename>xl0</devicename> vers
      l'intérieur (<acronym>LAN</acronym>).  Le pont possède
      une adresse IP <hostid role="ipaddr">1.2.3.4</hostid> (il n'est pas
      possible que votre fournisseur d'accès puisse vous donner une
      adresse de classe A comme celle-ci, mais pour cet exemple cela
      ira).</para>

    <programlisting># Les choses dont nous avons gardé l'état avant de
continuer
add check-state

# Rejeter les réseaux RFC 1918
add drop all from 10.0.0.0/8 to any in via fxp0
add drop all from 172.16.0.0/12 to any in via fxp0
add drop all from 192.168.0.0/16 to any in via fxp0

# Autorise la machine pont &agrave; communiquer si elle le désire
# (si la machine est sans adresse IP, ne pas inclure ces lignes)
add pass tcp from 1.2.3.4 to any setup keep-state
add pass udp from 1.2.3.4 to any keep-state
add pass ip from 1.2.3.4 to any

# Autorise les hôtes internes &agrave; communiquer
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0

# Section TCP
# Autoriser SSH
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Autoriser SMTP seulement vers le serveur de courrier
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Autoriser le transfert de zone seulement par le serveur de noms esclave [dns2.nic.it]
add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
# Laisser passer les sondes d'ident.  C'est préférable plutôt que d'attendre
# qu'elles s'arrêtent
add pass tcp from any to any 113 in via fxp0 setup keep-state
# Laisser passer la zone de "quarantaine"
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

# Section UDP
# Autorise le DNS seulement vers le serveur de noms
add pass udp from any to ns 53 in via fxp0 keep-state
# Laisser passer la zone de "quarantaine"
add pass udp from any to any 49152-65535 in via fxp0 keep-state

# Section ICMP
# Laisser passer 'ping'
add pass icmp from any to any icmptypes 8 keep-state
# Laisser passer les messages d'erreurs générés par 'traceroute'
add pass icmp from any to any icmptypes 3
add pass icmp from any to any icmptypes 11

# Tout le reste est suspect
add drop log all from any to any</programlisting>

    <para>Ceux qui parmi vous ont déj&agrave; installé
      des coupe-feux auparavant pourront noter l'absence de certaines
      choses.  En particulier, il n'y a pas de règles contre le
      forgeage d'adresses, en fait nous n'avons <emphasis>pas</emphasis>
      ajouté:</para>

    <programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting>

    <para>Cela, bloque les paquets provenant de l'extérieur et clamant
      être en provenance de votre réseau.  C'est quelque chose
      que vous devriez habituellement faire pour être sûr que
      personne n'essaie de passer outre votre filtre de paquet, en
      générant d'infames paquets qui sont comme s'il venaient
      de l'intérieur.  Le problème
      avec cela est qu'il y a <emphasis>au moins</emphasis> un hôte de
      l'extérieur que vous ne voulez pas ignorer: le routeur.  Mais
      habituellement, les fournisseurs d'accès contrent le forgeage sur
      leur routeur, aussi nous ne devons pas nous en préoccuper plus que
      cela.</para>

    <para>La dernière règle semble être une copie
      conforme de la règle par défaut, qui ne laisse passer
      rien de ce qui n'est pas spécifiquement autorisé.  Mais
      il y a une différence: tout le
      trafic suspect sera tracé.</para>

    <para>Il y a deux règles pour faire passer le trafic
      <acronym>SMTP</acronym> et <acronym>DNS</acronym> vers le serveur
      de courrier et le serveur de noms, si vous en avez.  Evidemment
      l'ensemble du jeu de règle devra être arrangé
      selon vos goûts
      personnels, c'est juste un exemple particulier (le format des
      règles est décrit précisément dans la
      page de manuel &man.ipfw.8;).  Notez qu'afin que &ldquo;relay&rdquo; et
      &ldquo;ns&rdquo; puissent fonctionner, les services de résolution
      de nom doivent fonctionner <emphasis>avant</emphasis> que le pont
      soit activé.  C'est un exemple pour être sûr que
      vous avez configuré l'adresse IP sur la bonne carte
      réseau.  Alternativement
      il est possible de spécifier l'adresse IP au lieu du nom
      (nécessaire si la machine est sans adresse IP).</para>

    <para>Les personnes qui ont l'habitude de configurer des coupe-feux
      ont probablement également utilisé soit une règle
      &ldquo;reset&rdquo; soit une règle &ldquo;forward&rdquo; pour les
      paquets ident (<acronym>TCP</acronym> port 113).  Malheureusement,
      ce n'est pas une option applicable avec un pont, aussi la
      meilleure solution est de les laisser passer vers leur
      destination.  Aussi longtemps que la machine de destination ne
      fait pas tourner un daemon ident, cela est relativement
      inoffensif.  L'alternative est de bloquer les connexions sur le
      port 113, ce qui pose problème avec des services comme
      l'<acronym>IRC</acronym> (la sonde d'ident doit s'arrêter).</para>

    <para>La seule autre chose qui est un peu étrange que vous avez
      peut-être noté est qu'il y a une règle pour
      laisser le pont communiquer, et une autre pour les hôtes
      internes.  Rappelez-vous que c'est parce que les deux ensembles de
      trafic prendront un chemin différent &agrave; travers le noyau
      et dans le filtre de paquet.  Le réseau interne ira &agrave;
      travers le pont, alors que la machine
      locale utilisera la pile IP normale pour communiquer.  Ainsi les
      deux règles s'occupent de cas différents.  La
      règle &ldquo;in via <devicename>fxp0</devicename>&rdquo;
      fonctionne pour les deux chemins.  En général, si
      vous employez des règles &ldquo;in via&rdquo; dans tout le
      filtre, vous devrez faire une exception pour les paquets
      générés localement, parce qu'ils ne sont pas
      passés par une de nos interfaces.</para>
  </sect1>

  <sect1 id="filtering-bridges-contributors">
    <title>Participants</title>

    <para>Plusieurs parties de cet article proviennent, et furent mises
      &agrave; jour et adaptées d'un vieux texte sur les ponts,
      écrit par Nick Sayer.  Cet article est également
      inspiré d'une introduction sur les ponts
      de Steve Peterson.</para>

    <para>Un grand merci &agrave; Luigi Rizzo pour l'implémentation
      du code de pont dans FreeBSD et pour le temps qu'il a passé
      &agrave; répondre &agrave; toutes
      mes questions &agrave; ce sujet.</para>

    <para>Un remerciement également &agrave; Tom Rhodes qui a
      supervisé mon travail de traduction de l'Italien (langue
      d'origine de cet article) &agrave; l'Anglais.</para>
  </sect1>
</article>