Forum sécurite : Attaque de Switchs Ethernet

stephr84 · Inscrit le: 08 Mar 2007 Messages: 7

Je viens de lire l'article "Attaque de Switchs Ethernet" et de faire quelques essais.

J'ai utilisé un switch type "bas de gamme" puis un CISCO catalyst 2950T-24. Le 2950 n'a aucun configuration spécifique (je fais un "erase startup" "reload" juste avant de commencer). J'ai réalisé les tests avec ArpFlood 1.1.

Je ne suis pas arrivé à transformer le switch 2950 en hub.
Lorsqu'on connecte un nouveau PC, son adresse MAC ne peut être apprise par le 2950 et il ne peut pas communiquer (tous les paquets envoyés sont droppés).

Cependant, un paquet de temps en temps (toutes les 5 secondes en moyenne) est bien échangé en mode hub. Je suppose que c'est parce que le 2950 ne possédant pas l'adresse MAC dans son cache, il essaie de l'ajouter en envoyant le paquet. Il l'envoie en diffusion sur les ports comme le ferait un switch dans le cas normal lors de l'apprentissage d'une adresse MAC. Ensuite, les paquets suivants sont droppés puisqu'il n'est pas arrivé à enregistrer cette adresse MAC. Il doit avoir un timeout ce qui fait qu'au bout d'un certain temps il essaie à nouveau d'apprendre l'adresse MAC.

Le 2950 gère donc correctement le problème de cache pleine. Il en se transforme pas en hub. Il droppe simplement les paquets arrivant d'adresse MAC inconnues. Voilà qui est rassurant ! Ce qui m'étonne est que l'article prétend le contraire.

Par contre, le switch "bas de gamme" devient presque hub. En effet, il n'est hub que sur les requetes. J'ai fais mes essais avec des ping. Toutes les requetes sont envoyées à tout le monde. Par contre, aucune trace des réponses sur les autres ports. Je suppose que c'est une durée de vie sur l'entrée dans le cache qui permet de faire ca. Lorsque la requete arrive, il diffuse parce qu'il ne connait pas l'adresse MAC. Mais il doit arriver à enrgistrer l'adresse MAC dans son cache ce qui fait que la réponse est bien dirigée. Quand la requete suivante arrive plus tard, le cache a été perdu. Il doit donc à nouveau émettre le paquet à tout le monde et ainsi de suite.

Le switch "bas de gamme" gère donc relativement mal ce problème.

Je ferai d'autres essais beaucoup plus poussés. Je vous tiendrai au courant.

stephr84 · Inscrit le: 08 Mar 2007 Messages: 7

J'ai donc fait de nouveaux essais aujourd'hui sur un Cisco 2950 et deux switch bas de gamme (dont le premier est identique à celui de mon post précédent).

La procédure de test est la même que précédemment : le programme arpflood tourne sur un premier ordinateur. Pendant ce temps, deux autres ordinateurs effectuent des ping entre eux.

Tout d'abord concernant le 2950 :
J'avais annoncé précédemment que de temps en temps un ensemble requête et réponse passait et que cet échange était effectué en mode diffusion sur tous les ports. J'avais annoncé que cela devait être normal car le 2950 essayait de mettre à jour sa table mais ne réussissait pas.
Aujourd'hui je me suis demandé si tous les paquets refusés n'étaient pas simplement bloqués à cause d'un manque de performance. J'ai donc essayé d'arrêter le flood après avoir rempli le cache (lors de mon test précédent, je laissais le flood tourner en continu). Et bien, une fois que le cache est plein et que j'arrete le flood, le 2950 se comporte comme un hub ! (L'article de ce site est donc bien juste.) Je trouve cela particulièrement embetant pour un switch comme le CISCO 2950 ! Un simple flood permet de le transformet en hub.

Ensuite, j'ai effectué de nouveaux essais sur le switch bas de gamme de la semaine dernière :
Tant que le flood tourne, le switch diffuse les reqêtes ICMP sur tous les ports. Par contre, les réponses ne sont pas diffusées. Si j'augmente la taille des requêtes ping, quelques paquets de réponses passent en mode diffusion. Je confirme donc ce que je disais lors du premier test : le switch met à jour son cache à chaque requête. La réponse arrivant rapidement, elle est envoyée uniquement sur le bon port. En fait, le cache doit être une file : la plus ancienne entrée dans le cache est supprimée pour que la nouvelle puisse être inscrite. La file doit être suffisamment courte pour que arpflood arrive à remplir cette file à entre chaque réponse et la requête suivante. Ainsi, dès que j'arrête le flood, le switch reprend un fonctionnement normal.

Enfin, j'ai effectué le même test sur un autre petit swicth de type bas de gamme :
Il a un mode de fonctionnement proche du 2950 cisco. Tant que le flood est en fonctionnement, très peu de paquet passent. Lorsqu'ils passent, ils sont émis en diffusion sur tous les ports. Dès que j'arrête le flood, le switch est devenu hub et envoie tous les paquets à tout le monde.

En conclusion, seul le premier des deux switchs bas de gamme a un fonctionnement plutot correct. Il est en mode hub seulement lorsque le flood tourne et seulement sur une partie des paquets. Le 2950 et l'autre switch bas de gamme deviennent des hubs et le restent pendant toute la durée de vie de leur cache une fois qu'un flood a été réalisé. Cela est plutot inquiétant.

Je pense qu'il a moyen sur le 2950 de faire une configuration qui évite cela. Donc ma prochaine série de tests concernera principalement le 2950 où j'essayerait de le configurer.

_sebf · Site Admin Inscrit le: 27 Oct 2006 Messages: 33

Lu stephr84,

Me revoila de congés ...

C'est cool que tu confirme ce que je dis dans l'arcticle Smile

Moi ca ne me choque pas qu'il se transforme en HUB. Que voudrais tu qu'il se passe d'autre :
- Sa capacité de mémoire soit plus grande ? Ca ne ferait que de retarder le phénimène.
- Qu'il ne bascule pas en mode HUB en refusant les nouvelles adresses MAC ? Ca serait pire d'un point de vu exploitation, car on aurait alors un DOS.

Je pense que la différence entre un Switch de grand public et un Switch pro, c'est que tu peux paramètrer ce que tu veux dessus et c'est donc à l'admin de jouer. C'est juste une preuve que le réseau et la sécurité sont des métiers à par entière.

Pour la configuration de protection sur le 2950, j'ai détaillé différentes possibilité dans l'article.

Pour ton petit switch qui cache en FIFO, ca parrait bien, mais imagine donc alors ses performances d'exploitation ? Et en terme de sécu, ca signifit que sans aucune attaque, certaine trame unicast son quand même diffusée partout Smile

Peux tu citer les réf de tes deux petits switchs, car tes tests son intérressant.

@+
_________________
_SebF
Sébastien FONTAINE

stephr84 · Inscrit le: 08 Mar 2007 Messages: 7

Salut sebf !

Oui ça m'avait étonné de ne pas avoir réussi à reproduire la même chose que toi lors de mon premier essai sur un 2950. Mon second test a bien confirmé ton article.

Ca me choque un peu sur un 2950 qu'il se transforme en hub aussi facilement. J'aurai préféré trouver une configuration par défaut qui bloque l'apprentissage des nouvelles adresses MAC (8000 adresses MAC, ça fait déjà pas mal pour un 2950). Enfin, ça se défend comme choix.

Je pense que la meilleure protection est le port-security avec un nombre maximal d'adresse par port. Je ferai quelques essais pour voir un peu sa réaction face à arpflood notamment au niveau performance.

Mais c'est clair que c'est un métier le réseau et la sécurité. Je suis d'ailleurs en recherche de stage de fin d'étude d'ingénieur sur ce domaine Wink

Le petit switch qui travaille avec une FIFO, ça pourrait poser problème en production. Enfin, tout dépend de la taille de la file et ce que l'on connecte sur le switch. Mais en même temps pour un switch premier prix je suis plutôt agréablement surpris qu'il ait résister pas trop mal à l'attaque. Par contre, je n'ai pas trop compris par rapport aux trames unicast dont tu parles. Les trames unicast sont diffusées partout pendant l'attaque seulement. Et d'ailleurs dès que l'attaque s'arrête, les trames ne sont plus diffusées mais bien dirigées.

Pour les références :
- le switch qui aurait une cache de type FIFO, je n'ai pas sa référence sous la main. Je donne ça dès que je peux.
- l'autre switch bas de gamme : la marque est NETCOW et c'est fabriqué par FUSION-COMPUTER. En gros c'est du sans marque... C'est le modèle que LDLC vendait en switch 8 ports 10/100 à bas pris il y a encore quelques mois.

@+

_sebf · Site Admin Inscrit le: 27 Oct 2006 Messages: 33

Lu stephr84,

Ce que je voulais dire, enfin ce que j'imagine qui reste forcement à valider :

C'est que que ton switch à l'air d'avoir une petite mémoire d'adresses MAC et donc, dans un fonctionnement normal, la mémoire doit souvent saturer. Et comme tu dis qu'elle fonctionne en FIFO, ca signifie que quand je fait une requeste DNS par exemple, la réponse reviendra à tout le monde si au même moment il y a quelques broadcast netbios ou une interrogation supervision qui parcours le réseau ou autre ...

@+
_________________
_SebF
Sébastien FONTAINE

stephr84 · Inscrit le: 08 Mar 2007 Messages: 7

Je pense que la file est suffisante pour gérer un réseau "normal" c'est-à-dire où tout le monde ne s'exprime pas en broadcast et où le switch n'est pas utilisé en coeur de réseau (enfin, je verrais mal mettre un switch premier prix en coeur de réseau ! enfin, on voit de tout aussi !!!). Sachant, il ne faut pas l'oublier que ça reste un petit switch premier prix. Il ne faut pas lui demander la qualité d'un 2950...

Le switch à cache de type FIFO (celui dont je parle juste précédemment) est de marque Gigamedia. J'ai trouvé un pdf sur Internet le décrivant :
Doc pdf
Une ligne est intéressante dans ce document :
Adresse MAC : 1K
Je suppose que cela signifie qu'il y a un cache d'adresse MAC de 1ko. Si on prend 1Ko égal 1024 octets, une adresse MAC faisant 6 octets, on peut y stocker 170 adresses MAC ce qui est plausible. Je vais voir si j'arrive à le mesurer.

@+

stephr84 · Inscrit le: 08 Mar 2007 Messages: 7

J'ai encore continué mes essais sur le switch bas de gamme à file FIFO

Tous mes nouveaux essais confirment qu'on a bien une FIFO.
J'ai voulu aussi mesurer le longueur de la file.

Pour cela, voici la procédure que j'ai utilisé :
J'utilise 3 PC sous Windows XP et 2000 : PC1, PC2 et PCAttaque. Sur les 3 PC, pour être sûr qu'ils communiquent pas, j'ai désactivé le protocole TCP/IP aux niveaux des cartes réseaux. Ca permet qu'aucun paquet ne pourra être envoyé par l'ordinateur sauf ceux générés par exemple avec FrameIP.

Je démarre l'expérience avec le switch et son cache vide. Je "donne" l'adresse MAC 00-11-22-33-44-55 à PC2 (en fait cette adresse sera utilisée avec FrameIP).

Grâce à FrameIP, PC1 envoie des paquets en continu à PC2 (donc mac_desination 00-11-22-33-44-55). Comme le switch ne connait pas l'adresse MAC 00-11-22-33-44-55, il diffuse les paquets partout. PC2 envoie alors un seul paquet (uniquement un seul paquet) avec FrameiP avec mac_source 00-11-22-33-44-55. Ainsi, à partir de ce moment, les paquets émis par PC1 arrivent tous sur le port de PC2. De plus le switch connait seulement deux adresses MAC : celles de PC1 (sa vraie adresse MAC) et de PC2 (00-11-22-33-44-55).

PCAttaque va alors envoyer des paquets avec des adresses MAC source aléatoires. Cela va remplir le cache du switch. Les paquets sont générés par FrameIP.

A partir du moment où les paquets envoyés par PC1 seront diffusés sur tous les ports (et plus uniquement transmis à PC2), cela signifiera qu'on aura rempli le cache d'adresse MAC.

Cela arrive lorsque j'atteinds 900 adresses MAC (à une ou deux près). La ligne "Adresse MAC : 1K" vue dans la doc doit donc signifier 1000 adresses MAC mais seules 900 sont accessibles.

Je pense que ce test confirme bien que le cache est de type FIFO.

Un petit détail :
PCAttaque utilise FrameIP. Cependant, il n'utilise pas le parametre "-mac_source r" qui signifie générer des adresses MAC aléatoirement (r pour random). En effet, ce paramètre génére toutes sortes d'adresses MAC. Cependant, le switch ne gère pas certaines adresses MAC et ne les enregistrent pas dans son cache. Par exemple, l'adresse MAC 55-44-33-22-11-00 ne peut pas être enregistrée par le switch car cette adresse ne peut pas exister dans la réalité. Donc j'ai développé un petit script qui exécute Frameip avec une adresse MAC source qui peut réellement exister. En fait, les adresses MAC générées sont de la forme suivante : les 3 premiers octets sont un véritable code OUI (en l'occurence j'ai utilisé un code OUI de chez DELL) et les 3 derniers octets sont de la forme 00-00-00, 00-00-01, 00-00-02, etc.

Voilà pour mes petites expériences !

@+

stephr84 · Inscrit le: 08 Mar 2007 Messages: 7

J'ai fait quelques essais sur le 2950. J'ai tout d'abord commencé par des VLAN.

On met une partie des ports du switch dans un VLAN 10 et l'autre partie dans un VLAN 20. Si un client sur le VLAN 10 fait un flood, les deux VLAN se transforment en HUB (et pas seulement le VLAN 10). On peut donc faire des attaques "à distance" : en attaquant le VLAN 10, on impacte le VLAN 20.

Cependant, on a "deux hubs" (un hub par VLAN) : sur le VLAN 20, on reçoit seulement les paquets du VLAN 20 et pas les données du VLAN 10 (et inversement). Nous voilà déjà rassuré.

Ensuite, pendant le flood, les performance de tout le 2950 (donc des deux VLAN) sont très dégradées.

Les VLAN, comme le disait l'article, ne résolvent pas le problème. Cependant, le flood ne permet tout de même pas de faire un saut de VLAN.

Ensuite, j'ai donc décidé d'essayer la configuration d'interface suivante :

switchport mode access
switchport port-security
switchport port-security maximum 100
switchport port-security violation protect

Cette configuration est super intéressante car déjà, elle évite que le 2950 devienne hub à cause du cache qui serait rempli. Lorsque le port a appris 100 adresses, il arrete d'en apprendre et le 2950 reste en mode de fonctionnement de type "switch". Cela confirme donc les solutions présentées dans l'article.

Autre caractéristique très intéressantes de cette configuration : il n'y a plus de problème de performance. En effet, sans cette configuration, on avait remarqué que les performances du 2950 s'effondraient pendant le flood et que le 2950 n'arrivait à transmettre plus qu'un paquet de temps en temps. En fait, en plus du flood, on faisait un DOS. Et bien, la configuration d'interface vue précédemment empêche tout impact sur les performances globales du switch.

Tout réseau qui n'aurait pas cette configuration d'interface ou quelque chose d'équivalent sur ses CISCO 2950 est donc vulnérable ! Je vois encore certains admin dirent que la sécurité de leur réseau est correcte puisqu'ils ont des switchs. Encore faut-il les configurer correctement !

Le 2950 peut donc toujours avec notre confiance : ils sont fiables du moment qu'ils sont correctement configurés.

mot clé : vpn de switchs attaques forum intrusion attaque authentification aide ethernet dos reseau post securite