5. Test du pontage Ethernet
5.1. 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.
5.2. 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.
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).
 | 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. |
5.3. 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.
5.3.1. 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) |
5.3.2. Configuration du routage
R�sultat de la commande route�:
5.3.3. Configuration d'iptables
On se reportera � la section Ping le, Max!.
5.4. 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