Si les couches plus basses comme CSMA/CD sont utilisées alors il est possible d'exploiter des failles de ces couches qui, plus elles sont de bas niveau (les failles et les couches), plus il est difficile de les contrer.
Parlons maintenant un peu de l'attaque d' `` ARP cache poisonning '' dans notre cas.
Sans expliquer en détail le fonctionnement d'ARP/RARP il est important de savoir que ce protocole est du type `` cry for help '' c'est-à-dire basé sur un requête de type 'who-is' en broadcast (@mac de destination FF-FF-FF-FF-FF-FF) pour demander à qui de droit à quelle adresse MAC correspond telle adresse IP. Le propriétaire habituel ou occasionnel (DHCP) de cette adresse IP va recevoir cette trame comme tout le monde et répondre cette fois en unicast qu'il possède telle adresse MAC.
Cependant ce genre de conversations génère du trafic réseau et un système de cache ARP est utilisé pour ne pas demander à chaque fois qui est qui. C'est la raison pour laquelle le temps de réponse au premier `` ping '' (message ICMP de type echo, type 8 code 0) sur une machine du réseau local est toujours plus grand que les suivants.
Exécuter une requête ARP en unicast (autorisé par la RFC) pour demander une conversion en forgeant sa propre trame (arp-sk de frederic Raynal ou Nemesis pour win32) en usurpant l'identité IP d'un hôte mais avec sa propre adresse MAC occasionnera une mise à jour du cache ARP du destinataire avec de fausses données. Plus tard le destinataire enverra à l'IP de l'attaquant toutes les trames destinées à l'hôte dont l'identité réseau aura été usurpée.
Une solution qui n'en est pas une est le cache statique (lourd à administrer) mais Sun propose sous Solaris d'augmenter la fréquence de rafraîchissement du cache ARP.
Dans notre cas précis du client VPN qui tente de joindre son serveur en chiffrant ses données il émettra comme tout le monde une trame CSMA/CD vers la passerelle mais avec l'adresse MAC de l'attaquant qui pourra par exemple faire un `` drop '' de toutes les trames (option -mac de iptables) venant du client et créer ainsi un dénis de service.
La conclusion de cette simulation est que même un VPN est soumis aux failles de couches OSI dont il n'a pas à s'occuper.
root 2004-05-04