Discussion :

[boboss123]

Bonjour,

Est-ce que vous utilisez des outils pour détecter des erreurs de câblage sur votre réseau Ethernet (ex: switch non connecté ou connecté sur le mauvais port) ? Si oui, lequel ?
- Pour vérifier la topologie réseau, on est bien obligé d'utiliser un protocole du style CDP ? ... le problème est que j'ai lu qu'utiliser CDP pouvait être dangereux (risque d'attaque DoS) : qu'en pensez-vous ? CDP permet de récupérer la topologie réseau même s'il y a un problème de configuration de VLAN ?

Merci d'avance,

[Invité]

Salut,

autant que je me souvienne, les protocoles de type Neighbor Discovery (CDP, propriétaire Cisco et LLDP son équivalent standard multi-constructeurs) n'implémentent pas d'authentification (j'écris eut-être une bêtise parce que j'ai pas vérifié avant de poster). Ce sont des protocoles de couche 2, extrêmement basiques.
Au point qu'il est très facile d'écrire un code qui écoute et décode ce traffic.
J'avais entendu, il y a très longtemps, de MD5 pour authentifier.
Mais l'effort à fournir pour implémenter l'authentification n'en valait pas la peine.
Donc, oui, à ce titre, ça pourrait être vulnérable. Et en plus c'est "en clair sur le câble" comme on dit.

Par contre, utiliser CDP/LLDP comme vecteur d'attaque..
Connaître les adresses IP adjacentes, ça veut pas dire que tu pourras te connecter en ssh.
Oui, les paquets CDP/LLDP vont peut-être donner une version de code qui a un exploit de sécu sur un routeur ou un switch. Mais ça va demander beaucoup de travail... Avec du brut force sur des communautés SNMP par exemple puisque ça n'est même pas transporté dans les paquets.
La meilleure pratique, c'est encore de faire en sorte que les adresses diffusées dans les paquets CDP ne soient pas accessibles à partir du canal sur lequel on les écoute...

En guise de remarque, je rajouterais tout de même que si l'entreprise est victime d'une compromission interne comme c'est le cas ici en écoutant et décodant trafic local, il existe des techniques autrement plus efficaces pour hacker un file system depuis l'intérieur

Steph

[boboss123]

Merci pour les infos,

Tu sais si CDP/LLDP sont dépendants de la config VLAN (est-ce qu'il faut avoir paramétré les VLANs avant de lancer le discovery ?) ?

Sur les réseaux que tu mets en place, tu n'installes jamais de vérification automatique de topologie ? Si la réponse est non, pourquoi (fonction peu pertinente ? Il existe de meilleures méthodes pour détecter un mauvais câblage ?) ?

Merci d'avance

[Invité]

A partir du moment que CDP/LLDP est activé sur une interface, des trames Ethernet multicast sont envoyées de façon cyclique, avec ou sans VLAN configuré...
De mémoire, avec CDP, le seul VLAN Id que tu pourras voir, c'est le native VLAN si l'interface qui émet le CDP porte un trunk 802.1q.
Ensuite, la plateforme de supervision (Cisco LMS par exemple) utilise SNMP pour découvrir la topologie L2/VLAN.
La donne est peut-être différente avec LLDP, surtout depuis qu'on lui a ajouté l'extension MED (Media Endpoint Discovery), il faudrait regarder les specs.
Voici une comparaison CDP/LLDP :

http://www.cisco.com/en/US/technolog...d804cd46d.html

Steph

[boboss123]

ok, merci pour les infos

[boboss123]

De mémoire, avec CDP, le seul VLAN Id que tu pourras voir, c'est le native VLAN si l'interface qui émet le CDP porte un trunk 802.1q.

Pour info, je viens de faire quelques tests (sniffing) sur un CISCO SG-300-10P :
- Quelque soit la configuration VLAN, les paquet LLDP sont bien tous non taggués VLAN
- Le PVID apparait dans les paquets LLDP quelque soit le type du port (access ou trunk) : les infos des autres VLAN n'apparaissent pas
- S'il n'y a pas de PVID configuré (donc pour le port en mode trunk uniquement), le champ PVID dans le paquet LLDP vaut 4095
=> après, il y a peut être différences de fonctionnement selon la version de firmware et la référence du switch
=> j'ai aussi sniffé les paquets LLDP d'un D-LINK et contrairement au switch CISCO, les champs PVID et system name n'apparaissent pas