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