Associer un pont Ethernet et netfilter

Version fran�aise du Ethernet Bridge + netfilter Howto

Nils Radtke

0.2.fr.1.0

2003-03-09

Historique des versions
Version 0.2.fr.1.0 2003-03-09 Revu par�: FR
Premi�re traduction fran�aise
Version 0.2 2002-10-08 Revu par�: NR
Ajout de la partie d'exemple de configuration et d'indications dans la configuration du routage et le test du routage respectivement.
Version 0.1 2002-09-19 Revu par�: NR
Mise � jour du lien vers ebtables dans la section des « Th�mes voisins ». Ajout d'une remarque ayant trait aux messages de d�verminage des faux positifs de br_nf

La mise en place d'un pont Ethernet permet d'ajouter une entit� d'audit ou de r�gulation � un r�seau de fa�on transparente. Une telle installation n'impose aucun changement � la topologie du r�seau d'accueil. Elle s'effectue en connectant le pont Ethernet entre le r�seau � analyser et l'�l�ment responsable du routage (l'�quipement connect� � l'Internet).


Introduction

La version originale de ce guide pratique est disponible dans d'autres formats. Pour le t�l�chargement, nous vous recommandons cette archive tar. La version originale de ce document est publi� par le Projet de documentation Linux (LDP).

La derni�re version fran�aise de ce document est disponible sur le site du projet de traduction traduc.org.

Pour ceux qui sont � la recherche d'une traduction, il existe aussi une version version allemande !


Introduction

Les ponts Ethernet joignent de fa�on transparente plusieurs segments Ethernet.

Un pont Ethernet distribue les trames qui se pr�sentent � un port aux autres ports. Il l'effectue de fa�on intelligente : une fois qu'il sait gr�ce � partir de quel port joindre une interface d'adresse MAC donn�e, la trame ne sera �mise que sur le port correspondant sans polluer les autres segments.

Des interfaces Ethernet peuvent s'ajouter � une interface existante et devenir des ports (logiques) de l'interface du pont.

L'emploi d'un dispositif de type netfilter au dessus d'un pont rend le syst�me capable d'effectuer du filtrage. On obtient ainsi un filtrage transparent. Aucune adresse IP n'est m�me n�cessaire. Il est bien s�r possible d'en affecter une � l'interface de pontage � des fins de maintenance (via ssh :o) ).

L'int�r�t du dispositif est �vident. La transparence �pargne � l'administrateur la charge de reprise de la topologie r�seau. Les utilisateurs ne remarquent pas l'existence du pont mais les connexions sont bloqu�es. Enfin, la transition ne perturbe pas le fonctionnement op�rationnel (qu'on se figure un r�seau o� la perte de connectivit� r�seau co�te cher !).

L'autre cas courant concerne les personnes connect�es � l'Internet au moyen d'un routeur d�di�. Les fournisseurs d'acc�s ne partagent gu�re les privil�ges d'administration sur les �quipements lou�s et le client ne peut donc pas modifier la configuration. Le client a cependant un r�seau dont il ne veut pas reprendre toute la configuration. Il n'est effectivement pas oblig� de le faire s'il a recours � un pont.


Logiciels requis

La configuration logicielle suivante est n�cessaire sur l'h�te de pontage conform�ment � notre terrain de test.


Noyau Linux

La prise en charge du pontage Ethernet est disponible en standard � partir du noyau 2.4.18. Aucun ajout n'est requis.

Pour disposer de netfilter et pouvoir se servir d'iptables, il faut toutefois appliquer un suppl�ment de code. Le n�cessaire se trouve dans la page sourceforge du pontage Ethernet.

root@bridge:~> cd /usr/src/
root@bridge:~> wget -c http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
root@bridge:~> cd /usr/src/linux/
root@bridge:~> patch -p1 -i ../bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff

Une fois le noyau standard rectifi�, on active les options de configuration ad�quates du noyau. On peut se reporter au document suivant pour la mise au point d'un noyau personnel : CD-Net-Install-HOWTO, bo�te � outils. Oui, c'est encore en allemand. Je corrigerai �a � l'occasion. Pour l'instant, dans :

        Code maturity level options

on active :

[*] Prompt for development and/or incomplete code/drivers

et dans :

        Loadable module support
        [*] Enable loadable module support  
        [*]   Set version information on all module symbols
        [*]   Kernel module loader

Jusqu'ici, tout va bien. � pr�sent, dans :

        Networking options

on active :

[*] Network packet filtering (replaces ipchains)
        [*]   Network packet filtering debugging

De m�me, dans :

IP: Netfilter Configuration  --->

on choisit tout ce qui est souhait� . Enfin, on active :

[M] 802.1d Ethernet Bridging

et  [1]  :

[*]   netfilter (firewalling) support

Il ne reste plus qu'� ex�cuter un cycle :

root@bridge:~> make dep clean bzImage modules modules_install

C'est tout. On n'oubliera pas d'�diter le fichier /etc/lilo.conf en cons�quence avant de taper:

root@bridge:~> lilo -t
root@bridge:~> lilo
root@bridge:~> reboot

Note�: Pourquoi ne pas identifier le noyau comme destin� au pontage ? On �dite le Makefile de plus haut niveau dans les sources du noyau et on modifie la ligne qui comprend EXTRAVERSION =. On peut la positionner � bridge par exemple. Une fois l'�tape modules_install effectu�e, les modules se trouveront dans le r�pertoire /lib/modules/2.4.18bridge.


L'utilitaire brctl

Une fois le noyau capable de jouer les ponts Ethernet et de supporter netfilter, on pr�pare l'utilitaire brctl. brctl est l'outil de configuration pour le pontage. On t�l�charge les sources du paquetage puis on le d�compresse et on se positionne dans le r�pertoire cr��.

root@bridge:~> wget -c http://bridge.sourceforge.net/bridge-utils/bridge-utils-0.9.5.tar.gz
root@bridge:~> tar xvzf bridge-utils-0.9.5.tar.gz
root@bridge:~> cd bridge-utils-0.9.5

Il est temps de lire le fichier README ainsi que ceux qui se trouvent dans le r�pertoire doc/. On peut alors lancer une commande make. L'ex�cutable brctl/brctl qui en r�sulte est � copier dans le r�pertoire /sbin/.

root@bridge:~> make
root@bridge:~> cp -vi brctl/brctl /sbin/

On peut � pr�sent passer � la section d'installation.


Mise en service de Linux

Mise en service du pont

Linux doit �tre mis au courant de l'existence du pont. On commence donc par r�clamer une interface de pontage Ethernet virtuelle (� ex�cuter sur la machine bridge, voir la configuration de test) :

root@bridge:~> brctl addbr br0

Le protocole d'�tablissement d'arbre (Spanning Tree) n'est pas n�cessaire. On suppose qu'il n'y a qu'un seul routeur. Une boucle est donc peu probable. La fonctionnalit� correspondante peut donc �tre d�sactiv�e. Le bavardage r�seau diminue alors.

root@bridge:~> brctl stp br0 off

Apr�s cette phase pr�paratoire, on lance enfin quelques commandes int�ressantes. On ajoute les interfaces Ethernet physiques en les attachant � l'interface de pontage virtuelle br0 qui vient d'�tre cr��e :

root@bridge:~> brctl addif br0 eth0
root@bridge:~> brctl addif br0 eth1

� pr�sent les interfaces Ethernet sont chacune devenues une extr�mit� du pont. Certes, elles �taient et elles sont toujours l� (on peut les voir :o) ) mais comme elles appartiennent au pont, elles n'ont plus besoin de leur adresse IP. On leur retire donc celle-ci :

root@bridge:~> ifconfig eth0 down
root@bridge:~> ifconfig eth1 down
root@bridge:~> ifconfig eth0 0.0.0.0 up
root@bridge:~> ifconfig eth1 0.0.0.0 up

Parfait, on dispose donc � pr�sent d'une station sans adresse IP. Si ce n'�tait pas d�j� le cas, il est temps de passer sur une console locale � la machine pour la configurer. Une console s�rie est la bienvenue.

Note�: Option : On affecte une adresse IP � l'interface logique et on l'active :

root@bridge:~> ifconfig br0 10.0.3.129 up
C'est tout. Il est conseill� de s'attarder sur une remarque importante !

Configuration du routage

Dans le cas de la configuration d'un passerelle, on active la transmission de paquets du noyau Linux :

root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward

La machine dispose d�j� d'une adresse IP mais n'a aucune route par d�faut. On corrige ce manque  :

root@bridge:~> route add default gw 10.0.3.129

La connectivit� r�seau devrait �tre normale, depuis, vers et au travers de la passerelle.


Test du pontage Ethernet

Configuration de test

On part de la situation suivante ou d'un sch�ma analogue :

           /\
          Ethernet            Ethernet             ATM    /  -/\
+---------+       +---------+          +---------+     /-/      !
| Station |-------|  Pont   |----------| Routeur |-----| Inter-  \
+---------+       +---------+          +---------+     \  net  ---|
         ^        ^         ^          ^                \     /
         |        |         |          |                 \---/
        eth0     eth0      eth1       if0                  ^
         |        |         |          |                   |
      10.0.3.2   rien/10.0.3.1      195.137.15.7   le reste du monde
                  \         /
                   \       /
   ^                \-br0-/
   |                                      ^             ^
   |                   ^                  |             |
   |                   |                  |             |
 perso               perso             �tranger      agressif 

Les possibilit�s d'administration sont limit�es aux �quipements marqu�s perso. Le routeur, et l'Internet, sont inaccessibles.

Si on veut contr�ler le trafic sur le brin Ethernet, on ne peut qu'ajouter un pare-feu ou int�grer un pont.

La m�thode habituelle a pour revers le changement de route par d�faut sur chaque machine du r�seau interne. C'est extr�mement p�nible et personne n'a envie de devoir changer 5 routes par d�faut sur 5 h�tes plus d'une fois. En outre, �a consomme du temps, on peut se tromper et la s�curit� n'est pas am�lior�e.

La seconde approche est plus syst�matique, consomme moins de temps et r�duit les risques d'erreur. Elle est plus s�re en ce sens qu'il n'est pas n�cessaire de faire appara�tre une adresse IP suppl�mentaire. Pas d'IP, pas de danger. Enfin, il s'agit de la th�orie en supposant que les piles sont s�res (ce qui a int�r�t � �tre v�rifi�). L'emploi d'un pont est transparent, pas de changements d'IP ou d'adresses MAC, c'est l� son attrait.

Chacun choisira sa m�thode mais seule la plus amusante est examin�e ici.


Ping le, Max !

On configure l'interface eth0 comme d'habitude. Les interfaces du pont sont configur�es conform�ment � la section d'installation.

La commande ci-dessous est importante pour activer la transmission de paquets.

root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward

On configure �ventuellement une route par d�faut :

root@bridge:~> route add default gw 10.0.3.129

On met en place les r�gles de filtrage sur bridge :

root@bridge:~> iptables -P FORWARD DROP
root@bridge:~> iptables -F FORWARD
root@bridge:~> iptables -I FORWARD -j ACCEPT
root@bridge:~> iptables -I FORWARD -j LOG
root@bridge:~> iptables -I FORWARD -j DROP
root@bridge:~> iptables -A FORWARD -j DROP
root@bridge:~> iptables -x -v --line-numbers -L FORWARD

La derni�re ligne produit l'affichage suivant :

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num      pkts      bytes target   prot opt in     out     source   destination
1           0        0 DROP       all  --  any    any     anywhere anywhere
2           0        0 LOG        all  --  any    any     anywhere anywhere      LOG level warning
3           0        0 ACCEPT     all  --  any    any     anywhere anywhere
4           0        0 DROP       all  --  any    any     anywhere anywhere

La cible LOG trace tous les paquets via syslogd. Une telle configuration devrait se limiter � la phase de test puisqu'elle ouvre la voie � un �puisement pr�matur� de la capacit� de stockage de la machine en cas d'attaque de type d�ni de service.

On teste les r�gles de filtrage en pingant l'adresse IP (195.137.15.7) du routeur sur la machine babasse :

root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
--- router.provider.net ping statistics ---
3 packets transmitted, 0 received, 100% loss, time 2020ms
^C
root@box:~> 

La r�gle par d�faut rejette (DROP) le trafic. Pas de r�ponse ni de tra�age des trames. Cette configuration netfilter est destin�e � jeter toutes les trames � moins que la r�gle 1 qui pr�c�de la r�gle LOG ne soit supprim�e :

root@bridge:~> iptables -D FORWARD 1
root@bridge:~> iptables -x -v --line-numbers -L FORWARD

Les r�gles sont � pr�sent :

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num      pkts      bytes target   prot opt in     out     source   destination
2           0        0 LOG        all  --  any    any     anywhere anywhere      LOG level warning
3           0        0 ACCEPT     all  --  any    any     anywhere anywhere
4           0        0 DROP       all  --  any    any     anywhere anywhere

Tous les paquets devraient passer. On le confirme avec un ping sur l'h�te babasse :

root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
64 bytes from router.provider.net (195.137.15.7): icmp_seq=1 ttl=255 time=0.103 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=2 ttl=255 time=0.082 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=3 ttl=255 time=0.083 ms

--- router.provider.net ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 2002ms
rtt min/avg/max/mdev = 0.082/0.089/0.103/0.012 ms
root@box:~> 

Parfait, le routeur est vivant et op�rationnel (bien s�r, il l'a �t� toute la journ�e).

Note�: Une fois l'interface du pont activ�e, il faut compter dans les trente secondes pour que le pont soit compl�tement op�rationnel. La phase d'apprentissage du pont est d'� peu pr�s trente secondes. Pendant ce temps, le pont analyse les adresses MAC au contact de chaque port. L'auteur du code, Lennert, pr�cise que ce point est susceptible d'am�lioration un de ces jours. Pendant la p�riode d'apprentissage, aucun paquet n'est transmis et aucun ping n'obtiendra de r�ponse. Il vaut mieux ne pas l'oublier.


Exemple de configuration

Cette partie est destin�e � donner au lecteur quelques indications sur l'allure que doit avoir son syst�me apr�s avoir suivi les indications du HOWTO.


Configuration de l'interface

R�sultat de la commande ifconfig :

root@bridge:~> ifconfig
br0       Link encap:Ethernet  HWaddr 00:04:75:81:D2:1D
          inet addr:10.0.3.129  Bcast:195.30.198.255  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:826 errors:0 dropped:0 overruns:0 frame:0
          TX packets:737 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:161180 (157.4 Kb)  TX bytes:66708 (65.1 Kb)

eth0      Link encap:Ethernet  HWaddr 00:04:75:81:ED:B7
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5729 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3115 errors:0 dropped:0 overruns:0 carrier:656
          collisions:0 txqueuelen:100
          RX bytes:1922290 (1.8 Mb)  TX bytes:298837 (291.8 Kb)
          Interrupt:11 Base address:0xe400

eth1      Link encap:Ethernet  HWaddr 00:04:75:81:D2:1D
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:1 frame:0
          TX packets:243 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:342 (342.0 b)  TX bytes:48379 (47.2 Kb)
          Interrupt:7 Base address:0xe800

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1034 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:82068 (80.1 Kb)  TX bytes:82068 (80.1 Kb)

Configuration du routage

R�sultat de la commande route :

root@bridge:~> route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.3.129      0.0.0.0         255.255.255.128 U     0      0        0 br0
0.0.0.0         10.0.3.129      0.0.0.0         UG    0      0        0 br0
root@bridge:~>

Configuration d'iptables

On se reportera � la section Ping le, Max!.


Remarque

Il semble y avoir une anomalie dans le code br-nf :

From: Bart De Schuymer
Date: Sun, 1 Sep 2002 21:52:46 +0200
To: Nils Radtke 
Subject: Re: Ethernet-Brigde-netfilter-HOWTO

Hello Nils,

[...]
Also, network packet filtering debugging is generally a bad idea with the
br-nf patch. It can gives a lot of false warnings (about bugs) in the logs.
[...]

NdT: l'auteur du message �lectronique signale que l'emploi des options de d�verminage lorsque br-nf a �t� appliqu� est susceptible de remplir les fichiers d'enregistrement de fausses alertes.

Pour ma part je n'ai jamais eu de fausse alerte dans mes logs. Peut-�tre que l'anomalie a �t� corrig�e. Contact� sur ce point, Bart a r�pondu 

From: Bart De Schuymer
Date: Mon, 2 Sep 2002 18:30:25 +0200
To: Nils Radtke 
Subject: Re: Ethernet-Brigde-netfilter-HOWTO

On Monday 02 September 2002 00:39, Nils Radtke wrote:
> Will the revision of the nf-debug code in br-nf be subject of improvement?

I must admit I haven't been running any kernel with netfilter debugging
lately. It sure used to give false positives a few months ago (the bridge
mailing list has posts about that), I've been lacking time to see why and if
it is still the case. It's on my todo list.
[...]

NdT: l'auteur reconna�t ne pas avoir essay� la combinaison sus-cit�e depuis un moment. Il n'a pas eu le temps derni�rement de confirmer le probl�me ni de l'analyser. Il figure en tout cas dans son pense-b�te.

� la date d'�criture de ce document (19/09/2002), je n'ai trouv� aucun message comme quoi l'erreur aurait disparu. Il est donc conseill� de garder un œil sur la liste de diffusion du pontage Ethernet


Liens

L'auteur du document peut �tre contact� en anglais ou en allemand par courrier �lectronique. Voir la page web de l'auteur.

Merci d'envoyer vos commentaires, remarques, corrections concernant la version fran�aise de ce document � commentaires@traduc.org


Pontage Ethernet


Th�mes voisins

Notes

[1]

Remarque : Cette entr�e n'est disponible qu'avec un noyau modifi� !