sécurité et spanning tree : le couple infernal ?

Si vous avez lu le blog book ou mon post précédent sur STP, vous savez combien je me méfie du protocole Spanning Tree (STP, pour Spanning Tree  Protocol). Si on fait du plug-and-play, on obtient un réseau avec des failles de sécurité importantes. Un défaut matériel mineur ou un logiciel gourmand en bande passante peuvent provoquer de longues heures d'indisponibilité. Aussi, je fais mon possible pour ne pas utiliser STP.

Mais quand même, il y a des cas où ça coûterait trop cher de s'en passer. Comment faire ?

STP, à quoi ça sert ?

STP fait en sorte qu'il n'y ait pas de boucle dans le réseau. Il élague les liens redondants. Au final, les liens actifs forment un arbre. Pour cela, les switches échangent des trames spéciales, les BPDU. Cela permet de déterminer où est la racine de l'arbre (root), et d'élaguer les liens redondants. Bien sûr, cela n'est pas instantané. Compter au minimum 20 secondes pour utiliser un lien situé en périphérie, et disons 1 minute ou plus pour obtenir un réseau fonctionnel. 

Tout cela car s’il y avait une boucle, on aurait une tempête de diffusion (broadcast storm). Quand cela arrive, le réseau devient inutilisable et souvent incontrôlable.

A bien retenir :"STP élimine les boucles dans des conditions normales. Mais il n'empêche pas les tempêtes …"

Ah bon, il y aurait des problèmes ?

Le premier problème, c'est que les BPDU ne sont pas authentifiés. Donc, un pirate peut facilement détourner le trafic ou produire un déni de service en créant des faux BPDU. Même sans pirate, Gaston Lagaffe peut aussi brancher un switch sauvage sur une prise murale.
Ensuite, l'algorithme nécessite du temps de calcul pour traiter chaque BPDU.  Si jamais le temps de calcul devient rare (par exemple, lors d'une tempête), le comportement de STP devient erratique. Le réseau est inutilisable.

STP part du principe que, si aucun BPDU n'est reçu pendant 20 secondes, il peut utiliser l'interface. Si jamais les BPDU ne circulent pas librement sur les liens, ça se passe mal. Le cas typique, c'est un  brin de fibre optique défectueux, tandis que l'autre brin fonctionne bien. Dans ce cas, STP créé une boucle qui passe par le brin resté intact. Cela provoque une tempête unidirectionnelle.

Pour terminer,  il n'y a aucune méthode simple, fiable et rapide pour venir à bout d'une tempête. Bien souvent, il est obligatoire de débrancher quelques câbles bien choisis. En dernière extrémité, y aller à la hache…

Bon, alors, on fait comment ?

1. Il est nécessaire de décider où se trouve la racine de l'arbre. Choisir pour cela un switch cœur de réseau, et y configurer :

  • spanning-tree vlan 1-4095 root primary

En général, il y a un switch cœur de réseau de secours et y configurer :

  • spanning-tree vlan 1-4095 root secondary

2. Il faut limiter les échanges de BPDU au strict nécessaire, c’est-à-dire exclusivement entre les switches. Un PC ou une imprimante ne doivent pas émettre de BPDU, ni en recevoir, ni attendre 20 secondes pour utiliser le réseau.

En mode global, configurer :

  • spanning-tree portfast default
  • spanning-tree portfast bpduguard default

Avec cela, il n'y a plus de BPDU émis vers les PC ou les imprimantes. Et si jamais un bricoleur branche un switch de récupération,  l'interface correspondante est immédiatement désactivée. Voir à ce sujet un excellent post de Cédric.

3.  Pour ne pas être victime d'une tempête et configurer SUR TOUTES les interfaces :

  •  storm-control broadcast
  •  storm-control broadcast level 0.01

4. Tenir à jour la documentation du réseau. Prévoir un schéma de réseau avec la forme de l'arbre. Cela va permettre une intervention raide et sûre en cas de gros problèmes.

5. Concevoir un réseau simple et de bon goût. Ne pas faire son malin. Laisser de côté des "optimisations" qui compliquent la documentation et la maintenance.

Pascal

Crédit photo : © Dooder - 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.