En effet, avec la mise en place d’un “private VLAN”, à partir d’un accès “isolated”, il est impossible d’attaquer les autres équipements “isolated”. En particulier, les attaques Man in the Middle, ARP spoofing/poisonning, DHCP, etc. ne sont pas réalisables. Restent des attaques “mac@ flooding” sur les switches, “Denial of Service” sur les switches et les passerelles, ou des attaques de niveau 3 sur les passerelles.
Cependant, beaucoup d’administrateurs réseau ne mettent pas le “private VLAN” en oeuvre, car cela nécessite un personnel bien formé et la connaissance de ce qui se passe au niveau 2. Je connais des administrateurs qui ne savent pas qui trafique avec qui au niveau 2, donc autant dire qu’ils ne vont pas utiliser le “private VLAN” !!
pour ne pas se casser la tête : switchport protected
Il s’agit d’une fonctionalité qui donne des résultats proches. Mais c’est beaucoup plus simple à comprendre. Même moi, je crois comprendre, c’est dire… La maintenance du réseau est bien simplifiée.
Sur les Catalyst 3750, les interfaces configurées avec “switchport protected” ne peuvent pas du tout communiquer entre elles au niveau 2. Par contre, elles peuvent communiquer avec les interfaces configurées de manière classique (dans le même VLAN, bien évidement…).
Dans la gamme Catalyst, les switches d’accès, par exemple les ME-3400 ont un mode comparable : les interfaces sont par défaut “uni”, c’est l’équivallent du mode “protected”. Les interfaces “uni” peuvent seulement communiquer avec les interfaces “nni”. De plus, une interface “uni” ne peut pas envoyer des trames à destination de la CPU, et donc, il n’est pas possible d’attaquer le switch d’acces via un protocole de niveau 2.
les contraintes de “switchport protected”
Sur un réseau de switches avec “private VLAN”, les différentes communautés peuvent être gérées au niveau du réseau de switches.
Avec “switchport protected”, on ne peut pas faire exactement la même chose. En effet, “switchport protected” s’applique à l’interface. S'il y a plusieurs VLAN sur une interface “protected”, ils se comportent tous comme un private VLAN isolated.
Avec “switchport protected”, on ne peut pas faire facilement un réseau de switches avec l’équivalent d’un VLAN ”isolated” et d’un VLAN “community”. On pourrait y arriver avec des interfaces d’interconnexion dédiées au VLAN “isolated”. Par contre, on peut avoir plusieurs VLAN “isolated” (je n’en vois pas trop l’intéret).
t’es sûr que ça marche ?
Je n'ai aucun doute, même si je ne l’ai pas testé dans mon lab. Je n’ai pas de retour sur sa mise en oeuvre dans un environnement opérationnel significatif (vos contributions seraient bien utiles…). Pour les sites où je travaille, il n’y aurait pas de soucis pour les PC : le cache ARP contient uniquement l’adresse IP de la gateway.
Il faut bien comprendre que, partout où le "private VLAN" est applicable, "switchport protected" s'applique aussi.
Si j'avais à faire un réseau d'accès pour l'Internet, j'utiliserais "switchport protected" sans hésiter, d'une part pour économiser les adresses IP, et d'autre part pour être certain que les utilisateurs vont bien sur la gateway et sur rien d'autre.
P.S. : pour voir le cache ARP d’un PC, c’est facile, on tape “arp –a” dans la fenêtre de commande DOS.
Pascal
crédit photo : © SemA - Fotolia.com