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).
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 !
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.
La configuration logicielle suivante est n�cessaire sur l'h�te de pontage conform�ment � notre terrain de test.
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 :
on active :
et dans :
[*] Enable loadable module support [*] Set version information on all module symbols [*] Kernel module loader
Jusqu'ici, tout va bien. � pr�sent, dans :
on active :
De m�me, dans :
on choisit tout ce qui est souhait� . Enfin, on active :
et [1] :
Il ne reste plus qu'� ex�cuter un cycle :
C'est tout. On n'oubliera pas d'�diter le fichier /etc/lilo.conf en cons�quence avant de taper:
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.
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/.
On peut � pr�sent passer � la section d'installation.
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) :
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.
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 :
� 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 :
Dans le cas de la configuration d'un passerelle, on active la transmission de paquets du noyau Linux :
La machine dispose d�j� d'une adresse IP mais n'a aucune route par d�faut. On corrige ce manque :
La connectivit� r�seau devrait �tre normale, depuis, vers et au travers de la passerelle.
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.
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.
On configure �ventuellement une route par d�faut :
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 :
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.
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.
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)
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
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
La liste de diffusion du pontage Ethernet.
Utilitaires, correctifs, et c�tera : page web du pontage Ethernet du noyau Linux.
Le pare-feu �conomique, par Shawn Grimes.
Filtrage au niveau des trames, Ethernet-Bridging-Tables :
page page de garde sourceforge d'ebtables
extension IP du pontage Linux IP mode, LVS
Linux et la haute disponibilit� : Linux haute disponibilit�
Serveur virtuel Linux : LVS
[1] |
Remarque : Cette entr�e n'est disponible qu'avec un noyau modifi� ! |