Le morceau de bravoure des réseaux de switches, c’est le Spanning Tree Protocol (STP) ou plutôt, les divers avatars de ce protocole. Il s’agit de régler un problème banal :
comment construire un réseau de switches redondant et qui fonctionne ?
En effet, si on tente de construire par exemple un triangle ou un carré de switches, on constate qu’il devient très rapidement inutilisable, parce qu’on crée ainsi une boucle de niveau 2, dans laquelle certaines trames tournent infiniment en consommant une bonne partie des ressources. Le réseau ne fonctionne plus. C’est ce qu’on appelle une tempête de diffusion.
Il est toujours possible qu’une boucle soit créée suite à un câblage intempestif (encore Gaston ! Il s’est mis à quatre pattes sous les bureaux et il a relié entre elles deux prises murales RJ45 par un câble croisé). Sur le terrain, la meilleure façon d’éviter les problèmes, c’est encore d’appliquer la bonne pratique déjà citée : empêcher que les PC puissent communiquer entre eux au niveau 2.
le STP à la rescousse... ou presque !
Mais cela ne permet pas de relier des switches pour former un carré. Pour que cela fonctionne, on a créé STP. Au sein du réseau de switches, STP établi et calcule dynamiquement un arbre en désactivant les liaisons redondantes. Si la forme du réseau change, l’arbre est recalculé, cela prend quelques secondes (mais pendant ce temps, le réseau ne marche pas bien).
STP fonctionne en échangeant des informations à l’aide de trames spéciales, les BPDUs. Tant que cela marche, c’est parfait. Mais au cas où quelque chose irait de travers, le réseau devient instable et il est très difficile de faire un diagnostic. Il est donc recommandé de documenter avec la plus grande précision l’état "normal" du réseau, en repérant l’état de chaque liaison, de façon à savoir où intervenir. Et il est nécessaire d’instaurer des procédures strictes de câblage.
Laissez-moi vous conter un fait réel : sur un site, suite à la demande insistante des utilisateurs, j’ai autorisé la mise en œuvre de STP. Eh bien, ce site est devenu indisponible pendant plus d’une heure suite à une erreur humaine (non, ce coup ci, ce n’était pas Gaston). Et on ne compte pas les réseaux qui se sont effondrés parce que quelqu’un avait branché un "vieux" switch de récupération. Ceux-ci ont de fortes chances de devenir la racine de l’arbre calculé par STP.
le STP : les choses à retenir
Première leçon : le STP ne résiste pas aux erreurs humaines.
Deuxième leçon : la maintenance de STP demande une connaissance précise du réseau.
Ce que j'en ai retenu: heu ... je préfère éviter
du côté des menaces...
Maintenant, du point de vue des nuisances volontaires, STP offre de nombreuses possibilités. En premier lieu, un sniffer permet d’apprendre beaucoup de choses comme les VLANs utilisés, et l’adresse mac du switch « root ». On peut très facilement perturber le protocole, avec des BPDU créées de toutes pièce.
Les effets vont du banal déni de service (l’attaquant fait en sorte de se faire perpétuellement élire en tant que racine de l’arbre) à des effets plus subtils, comme le détournement du trafic à des fins d’observation ou de substitution.
conclusion : ne pas utiliser STP
Pour ma part, je recommande d’utiliser des mécanismes beaucoup plus simples. Par exemple, chez CISCO, le « Flex Links » qui repose sur une décision locale du switch (il réagit typiquement en 800ms) ou le « Resilient Ethernet Protocol », un peu plus complexe, qui gère les topologies en anneaux.
Si l'on doit absolument utiliser STP, il faut en limiter l’usage au strict nécessaire, mais cela demande une configuration soigneuse.
De nombreuses personnes pensent que STP "empêche les boucles". C'est loin d'être le cas. Il faut observer deux choses : d'une part, une boucle, ce n'est pas si fréquent, et d'autre part, ce qui est génant, ce ne sont pas les boucles, mais les tempêtes de diffusion.
Ma recommandation est de mettre en place une limitation de la bande passante BUM (Broadcast, Unknown unicast et Multicast) de façon à limiter l’intensité d’une éventuelle tempête de diffusion ou d'une éventuelle attaque basée sur des trames broadcast, saturation de la table des adresses mac, etc.
Vos remarques, questions et autres interventions sont les bienvenues.
Pascal Bonnard
les autres articles de la série "Ethernet" :
Ethernet, un niveau à ne pas négliger
Les attaques « classiques » : interception de trafic, dénis de service
A éliminer d’urgence : DTP
Les VLANs pour les Nuls : je configure les VLANs de mes trunks bien propres
Les VLANs pour les Nuls : VTP / MRP
Les boucles et les tempêtes : STP et comment s’en dispenser
L’art d’en dire trop : CDP et LLDP
Incroyable, mais vrai : CTP loopback
A utiliser sans (trop) d’ illusions : LAG (PaGP, LACP)
Conclusion, la configuration ultime pour mes switches
crédit image: © Tasosk - Fotolia.com
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.