mauvaise pratique : comment faire un LAN qui fuit, mais pas trop ?

Partager

deux ans, déjà, on parlait sur le blog des LAN pollués et les mèls compulsifs

Résumé du post  : Candide travaille à la Compagnie Française de Télématique Sécurisée, de son petit nom CoFraTelSec. Il sniffe le LAN bureautique. Il voit des protocoles de niveau 2 qui n'ont rien à y faire. "En fait le LAN, c’est une passoire. Le switch est configuré à minima, il fait du  DTP, du  CDP et du  STP. Comme qui dirait, c’est un LAN mit(m)é. "

deux ans plus tard …

La CoFraTelSec a bien évolué. Ils ont lu, compris et appliqué mes posts. Quand Candide sniffe, il ne voit plus de protocoles indésirables. Ah, tout de même, cela aura servi à quelque chose ! Mais Candide voit des trames qui ne devraient pas parvenir à son PC. En particulier, des trames TCP et UDP … Comment est-ce possible ? Hé bien, je vous donne la recette, ça peut toujours servir …

recette pour faire un LAN qui marche …

  1. Deux plans d'adressage IP, avec chacun son Vlan. C'est une situation très classique.
  2. Deux switches-routeurs. Chacun permet de router d'un Vlan vers l'autre Vlan.
  3. Les switches-routeurs sont reliés par un trunk qui laisse passer les 2 Vlans.

et c'est tout !

(Nota: ma recette est donnée pour 2 plans d'adressage IP et 2 switches-routeurs. Elle est plus spectaculaire avec 3, 4, ou davantage.)

Candide est dans le Vlan 14 sur le switch "Lisboa", Zadig est dans le Vlan 18 sur le switch "Babylon". A l'aide de FTP, Candide (Vlan 14, switch L)  veut récupérer un e-book qui est chez Zadig (Vlan 18, switch B).

Le switch L utilise sa fonction routage pour acheminer le trafic qui va de Candide (Vlan 14) vers Zadig (Vlan 18). Ce trafic va donc sortir du switch L dans le Vlan 18. De son côté, le switch B utilise sa fonction routage pour acheminer le trafic qui va de Zadig (Vlan 18) vers Candide (Vlan 14). Ce trafic va donc sortir du switch B dans le Vlan 14.

Résultat : ça marche, Candide et Zadig peuvent partager les e-books de Voltaire.

un LAN qui marche … mais avec des fuites !

En fait, le switch B ne sait pas sur quelle interface envoyer le trafic routé dans le Vlan 14 (qui est destiné à Candide). En effet, les réponses de Candide arrivent dans le Vlan 18, et non pas dans le Vlan 14 ! Sur le trunk vers le switch L, le switch B n'a pas mémorisé mac@ pour le Vlan 14.

Du coup, le switch B va diffuser ce trafic à tous les utilisateurs qui sont dans le Vlan 14. C'est ainsi que Cunégonde (Vlan 14, switch B) va recevoir ce que Zadig envoie à Candide (mais Cunégonde ne voit pas les acquittements que Candide envoie à Zadig). De son côté, Astarté (Vlan 18, switch L) reçoit une copie des acquittements de Candide.

et le ARP, alors, c'est pour les chiens ?

Ah oui, j'en vois un au fond de la classe qui ne dort pas. Et bien voilà, au début il y a bien un ARP et les mac@ sont apprises correctement. Mais les mac@ restent mémorisées seulement 5 minutes ! Le prochain ARP, quant à lui sera émis dans 4 heures. On aura donc un réseau qui fuit pendant 235 minutes, disons 98% du temps !

Pascal

source : Unicast flooding due to asymmetric routing

credit photo : © Steve Cukrov - Fotolia.com

 

Pascal Bonnard

Depuis 2004, je m’occupe d'ingénierie de commutateurs Ethernet (switches en anglais). Comme je suis curieux de nature, j'ai voulu savoir ce qu'il y avait sous le capot ... et c'est là que j'ai vu tous ces protocoles qui ne nous veulent que du bien, mais qui posent d'inévitables questions de sécurité. Sont-ils fiables ? Peuvent-ils être trompés ? Il me semble que ce domaine est peu documenté, et que les informations disponibles sont souvent incomplètes, parfois erronées. Je désire vous faire partager mes connaissances qui s'appuient sur des tests en laboratoire ainsi que sur plusieurs centaines de machines opérationnelles.