Bon, on avait dit : arrêter les protocoles propriétaires actifs par défaut. Alors, en mode global, configurer :
| no cdp run | |
| vtp mode transparent | |
| no spanning-tree vlan 1-4095 | |
| no errdisable detect loopback |
configurer soigneusement les interfaces trunk
| switchport trunk encapsulation dot1q | ! Forcer l’encapsulation normalisée |
| switchport trunk native vlan 801 | ! Déclarer un VLAN natif specifique |
| switchport trunk allowed vlan 10,20-29 | ! Donner la liste des VLANs autorisés |
| switchport mode trunk | ! Forcer le mode trunk |
| switchport nonegotiate | |
| spanning-tree bpdu filter enable | |
| no cdp enable | |
| no keepalive |
Dans la liste des vlan autorisés, il ne faut JAMAIS mettre le vlan 1. A ce sujet, voir le post "les VLANs pour les nuls : je configure les VLANs de mes trunks bien propres". Surtout bien s’assurer que le DTP n’est pas actif. Et pourquoi mettre « no cdp », alors qu’on a déjà mis en global « no cdp run » ?
Eh bien, comme ça, on a une ceinture ET des bretelles. De plus, la maintenance est facilitée, car toutes les informations sont rassemblées dans la configuration de l’interface. Pareil pour bpdufilter, il est clair que l’interface ne participe pas à un éventuel spanning tree.
configurer soigneusement les interfaces access
| switchport mode access vlan 10 | |
| switchport nonegotiate | |
| spanning-tree bpdu filter enable | |
| no cdp enable | |
| no keepalive |
Et le « port-security » ??? Pour diverses raisons, j’y ai renoncé. Bon, je ferais peut-être un post sur ce sujet, il y a beaucoup à dire.
ne pas oublier de museler l’interface VLAN 01
Le Vlan 1 fait plein de choses surprenantes et innatendues, il ne doit jamais être utilisé pour véhiculer du traffic opérationnel. Le problème, c’est qu’il est toujours présent, ainsi que l’interface virtuelle Vlan1. dans la mesure du possible, on essaye de l’inactiver.
| interface Vlan1 | |
| no ip address | ! pas de routage IP |
| shutdown | ! interface fermée |
| no clns route-cache | ! pas de routage ISO |
| end |
comment limiter l’étendue du niveau 2
Sur les PC d’un LAN, configurer « switchport protected » et « switchport block multicast ». De la sorte, les possibilités d’un attaquant sont considérablement limitées. Par exemple, les PC qui sont sur le switch ne peuvent pas faire des échanges unicast entre eux. Ils peuvent seulement échanger avec le routeur, ou les serveurs. Cependant, je n’ai pas d’expérience personnelle à ce sujet.
Pour contrôler les communications au niveau 2 sur un réseau de switches, dans le cas général, il faut utiliser les « private vlan ». L’ennui, c’est que c’est un peu compliqué à gérer et à comprendre.
comment limiter l’intensité des tempêtes
Pour limiter les conséquences d’une boucle éventuelle (voir le post Les boucles et les tempêtes : STP et comment s’en dispenser ), il faut mettre en œuvre les possibilités de « storm-control ». Mais il n’y a pas de recommandation générale pour la valeur du seuil à configurer. Il me semble que la valeur de 5% devrait convenir à la majorité des LAN. Une valeur trop basse pourrait géner le bon fonctionnement de certaines applications.
La façon de configurer « storm-control» dépend du matériel. Par exemple, sur un Catalyst 3750, sur les interfaces :
storm-control broadcast level 5.00
storm-control multicast level 5.00
Il est également possible de filtrer les « unicast » dont l’adresse mac ne figure pas dans la table des mac@. Cette possibilté peut être utilisée en prévention d’une attaque de type « inondation de mac@ ».
Vos remarques, questions et autres interventions sont les bienvenues.
Pascal BONNARD
les 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
credit photo : @Kurhan - 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.