DOC?= article

FORMATS?= html

INSTALL_COMPRESSED?=gz

INSTALL_ONLY_COMPRESSED?=

SRCS= article.sgml

DOC_PREFIX?= ${.CURDIR}/../../..

.include "${DOC_PREFIX}/share/mk/doc.project.mk"

<!--

	The FreeBSD Project - http://www.FreeBSD.org

	The FreeBSD French Documentation Project

	$FreeBSD$

	$Id$

	Original revision: 1.10

-->

<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [

<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">

%man;

<!ENTITY % abstract PUBLIC "-//FreeBSD//ENTITIES DocBook Abstract Entities//FR"> %abstract;

<!ENTITY % artheader PUBLIC "-//FreeBSD//ENTITIES DocBook ArtHeader Entities//FR"> %artheader;

<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//FR"> %translators;

<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">

%man;

]>

<article>

  <articleinfo>

    <title>Ponts filtrants</title>

    <authorgroup>

      <author>

        <firstname>Alex</firstname>

        <surname>Dupre</surname>

        <affiliation>

          <address><email>sysadmin@alexdupre.com</email></address>

        </affiliation>

      </author>

    </authorgroup>

    <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/filtering-bridges/article.sgml,v 1.10 2002/06/05 22:09:07 keramida Exp $</pubdate>

    <abstract>

      <para>Souvent il est utile de diviser un r&eacute;seau physique (comme un

	réseau Ethernet) en deux segments séparés sans 

	avoir a 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&eacute;seau est suffisant pour jouer le r&ocirc;le d'un pont.</para>

      <para>Un pont fonctionne en scannant les adresses au niveau

	<acronym>MAC</acronym> (adresses Ethernet) des cartes connect&eacute;es

	à 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és sur un segment 

	différent.  Sous beaucoup de points de vue

	un pont est similaire à un commutateur (switch) Ethernet avec

	uniquement deux ports.</para>

	&abstract.license;

	&abstract.disclaimer;

	&trans.a.fonvieille;

    </abstract>

  </articleinfo>

  <sect1 id="filtering-bridges-why">

    <title>Pourquoi utiliser un pont filtrant?</title>

    <para>De plus en plus fr&eacute;quemment, gr&acirc;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 à 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&egrave;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&eacute;e.</para>

    <para>Un coupe-feu bas&eacute; sur un pont peut &ecirc;tre 

      configuré et inséré

      entre le routeur xDSL et votre concentrateur/commutateur Ethernet

      sans aucun probl&egrave;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&egrave;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 à 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&eacute;thodes: une

	proc&eacute;dure <emphasis>exclue</emphasis> l'autre.  Choisissez la

	meilleure en fonction de vos besoins et capacit&eacute;s.</para>

    </important>

    <para>Avant d'aller plus loin, soyez s&ucirc;r de disposer deux cartes

      Ethernet qui supportent le mode promiscuous pour la réception et

      la transmission, comme elles doivent être capable 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 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&eacute;e au r&eacute;seau.</para>

    <sect2 id="filtering-bridges-kernel">

      <title>Configuration du noyau</title>

      <para>Donc vous avez d&eacute;cid&eacute; d'utiliser la bonne 

	vieille méthode d'installation.  Pour commencer, vous 

	devez ajouter les lignes suivantes à votre fichier de 

	configuration du noyau:</para>

      <programlisting>options BRIDGE

options IPFIREWALL

options IPFIREWALL_VERBOSE</programlisting>

      <para>La premi&egrave;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&eacute;cessaire de compiler et d'installer le

	nouveau noyau.  Vous pourrez trouver des instructions 

	d&eacute;taill&eacute;e 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&eacute;thode nouvelle et 

	plus simple; la seule chose à 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&ccedil;on, durant le d&eacute;marrage du 

	syst&egrave;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>, &eacute;tant donn&eacute; 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&egrave;re pr&eacute;paration</title>

    <para>Avant de red&eacute;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&egrave;gle de

      défaut du coupe-feu est de rejeter tous les paquets IP.  Au

      départ nous configurerons un coupe-feu “ouvert”, afin

      de vérifier son fonctionnement sans problème relatif au 

      filtrage de paquet (dans le cas où vous faite cela à 

      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&egrave;re ligne activera le coupe-feu (et chargera le module

      <filename>ipfw.ko</filename> s'il n'est pas compil&eacute; dans le

      noyau), la seconde le configurera dans le mode

      “ouvert” (comme expliqué dans

      <filename>/etc/rc.firewall</filename>), la troisi&egrave;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&eacute;seau, la 

      méthode la plus utilisée est d'assigner une adresse 

      IP à une seul des cartes réseau, mais le pont 

      fonctionnera à 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 

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

      l'interface externe (celle connectée à l'Internet 

      o&ugrave; le serveur <acronym>DNS</acronym>

      réside), puisque le pont sera activé à 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, à moins que, 

      durant la procédure de démarrage, des applications 

      devront accéder à 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&eacute;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&ocirc;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 inclut 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&eacute; pour ne rien laisser passer.</para>

    <para>Il est maintenant temps de red&eacute;marrer le syst&egrave;me et de

      l'utiliser comme auparavant: il y aura de nouveau messages

      concernant le pont et le coupe-feu, mais le pont ne sera pas

      activé et le coupe-feu, étant en mode “ouvert”,

      n'interdira aucune op&eacute;ration.</para>

    <para>Si il y a un quelconque probl&egrave;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&eacute;cuter les

      commandes suivantes (en pensant bien de remplacer les noms des deux

      interfaces r&eacute;seau <devicename>fxp0</devicename> et

      <devicename>xl0</devicename> avec les v&ocirc;tres):</para>

    <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput>

&prompt.root; <userinput>sysctl net.link.ether.bridge_ipfw=1</userinput>

&prompt.root; <userinput>sysctl net.link.ether.bridge=1</userinput></screen>

    <para>La premi&egrave;re ligne sp&eacute;cifie quelles interfaces 

      devront être activées par le pont, la seconde 

      activera le coupe-feu sur le pont

      et enfin la troisi&egrave;me activera le pont.</para>

    <para>A ce moment l&agrave;, vous devriez &ecirc;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.<replaceable>[bla]</replaceable>=<replaceable>[bla]</replaceable></literal>

      de ces lignes dans le fichier

      <filename>/etc/sysctl.conf</filename> afin de les ex&eacute;cuter au

      d&eacute;marrage.</para>

  </sect1>

  <sect1 id="filtering-bridges-ipfirewall">

    <title>Configurer le coupe-feu</title>

    <para>Il est maintenant temps de cr&eacute;er votre propre fichier de 

      règle personnalisé pour le coupe-feu, afin de 

      sécuriser le réseau

      interne.  Il y aura quelques complication à faire cela parce que

      toute 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 à la 

      réception, aussi les règles qui

      utilisent “out” ou “xmit” n'agirons

      jamais.  Personnellement, j'utilise “in via” qui est

      une ancienne syntaxe, mais qui a un sens quand vous la lisez.  Une

      autre limitation est que vous êtes réduit à 

      l'utilisation seulement des commandes “pass” ou 

      “drop” pour les paquets filtrés par un pont.  

      Les choses sophistiquées comme “divert”, 

      “forward” ou “reject” ne sont pas 

      disponibles.  De telles options peuvent toujours être 

      utilisées, mais uniquement sur le trafic à

      destination ou depuis le pont lui-même (s'il possède 

      une adresse IP).</para>

    <para>Une nouveaut&eacute; de FreeBSD 4.0, est le concept de filtrage avec

      gestion des états (stateful).  C'est une grande 

      am&eacute;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 &eacute;tats.</para>

    <para>Regardons un exemple de configuration.  Notez tout d'abord

      qu'au d&eacute;but du fichier <filename>/etc/rc.firewall</filename> 

      il y a déjà 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&eacute;es au

      démarrage du système, en modifiant la ligne de

      <filename>/etc/rc.conf</filename> o&ugrave; nous avions d&eacute;fini le

      coupe-feu &ldquo;ouvert&rdquo;:</para>

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

    <important>

      <para>Vous devez pr&eacute;ciser le chemin <emphasis>complet</emphasis>,

	sinon il ne sera pas chargé avec le risque de rester 

	isol&eacute; du r&eacute;seau.</para>

    </important>

    <para>Pour notre exemple imaginez que nous avons l'interface

      <devicename>fxp0</devicename> connect&eacute;e vers l'ext&eacute;rieur

      (Internet) et l'interface <devicename>xl0</devicename> vers

      l'int&eacute;rieur (<acronym>LAN</acronym>).  Le pont poss&egrave;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&eacute; l'&eacute;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.68.0.0/16 to any in via fxp0

# Autorise la machine pont à 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 à 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&eacute;j&agrave; install&eacute; 

      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&eacute;:</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&eacute;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&ocirc;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&egrave;re r&egrave;gle semble &ecirc;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&eacute;.</para>

    <para>Il y a deux r&egrave;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 “relay” et

      “ns” 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&eacute;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 

      “reset” soit une règle “forward” 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 laisser les passer vers leur

      destination.  Aussi longtemps que la machine de destination de

      fait pas tourner un daemon d'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&ecirc;ter).</para>

    <para>La seule autre chose qui est un peu &eacute;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 à travers le noyau 

      et dans le filtre de paquet.  Le réseau interne ira à 

      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&egrave;gle &ldquo;in via <devicename>fxp0</devicename>&rdquo; 

      fonctionne pour les deux chemins.  En général, si 

      vous employez des règles “in via” dans tous le 

      filtre, vous devrez faire une exception pour les paquets 

      générés localement, parce qu'ils ne sont pas

      pass&eacute;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 

      à 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&eacute;mentation 

      du code de pont dans FreeBSD et pour le temps qu'il a passé 

      à répondre à toutes 

      mes questions &agrave; ce sujet.</para>

    <para>Un remerciement &eacute;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>