Attaque de Switchs Ethernet
par Sébastien FONTAINE (_SebF)

1 - Introduction
2 - Rappel des terminologies
        2.1 - Le Switch (commutateur)
        2.2 - Le protocole ARP
        2.3 - L'outil ArpFlood
        2.4 - La norme 802.1X
3 - L'attaque
        3.1 - Le contexte
        3.2 - La réalisation
        3.3 - La réaction
        3.4 - Les conséquences
                3.4.1 - Perte de l'administration
                3.4.2 - Passage en mode HUB
                3.4.3 - Saturation réseau
        3.5 - Cas d'une entreprise
4 - Les protections non efficaces
        4.1 - Augmenter la durée de vie des correspondances
        4.2 - Acheter des commutateurs Ethernet plus performants
        4.3 - Segmenter le commutateur par des VLAN
5 - La protection efficace
        5.1 - Nombre d'adresses MAC maximum par port
        5.2 - Authentification 802.1X
6 - Commandes équivalentes 3COM
7 - Discussion autour de la documentation
8 - Suivi du document

1 - Introduction

Voici une documentation pragmatique expliquant comment il est possible d'attaquer un Switch Ethernet. Vous découvrirez qu'il est simple d'affecter le management et intéressant d'écouter les autres ports en basculant le commutateur en mode HUB.

L'objectif étant de faire prendre conscience aux entreprises de la vulnérabilité d'un LAN et que la sécurité interne est primordiale pour obtenir une stabilité de l'exploitation. Pour cela, vous découvrirez aussi dans cette documentation, la manière de se protéger.

2 - Rappel des terminologies

2.1 - Le Switch (commutateur)

Cet équipement agît au niveau 2 du modèle OSI. Identiquement à un HUB, sa fonction est d'interconnecter plusieurs cartes d'interfaces Ethernet ensembles. Cependant, lorsqu'il réceptionne une trame, il compare l'adresse MAC de destination avec sa table de correspondance. Ainsi, il ne diffuse cette trame uniquement sur le port physique concerné.

Dans le cadre d'un Switch 100Mbps, on obtient un débit dédié de 100Mbps par équipement Ethernet raccordé. les caractéristiques principales à vérifier lors de la sélection d'un Switch sont :

        - Le nombre d'adresses MAC maximum qui peuvent mise en mémoire
        - Le nombre de paquets par seconde (PPS) que la matrice de fond de panier peut commuter

2.2 - Le protocole ARP

Le protocole ARP, signifiant Address Resolution Protocol, fonctionne en couche Internet du modèle TCP/IP correspondant à la couche 3 du modèle Osi. L'objectif de ARP est de permettre la résolution d'une adresse physique par l'intermédiaire de l'adresse IP correspondante d'un host distant. Le protocole ARP apporte un mécanisme de « translation » pour résoudre ce besoin.

Voici la composition de l'entête :

Vous remarquerez qu'il existe deux principaux modes définit par le champ "Operation" qui sont la demande (request) et la réponse (reply). Vous trouverez tous les détails du protocole ARP dans la documentation de l'entête ARP du site FrameIP.

2.3 - L'outil ArpFlood

L'utilitaire ArpFlood permet l'envoi massif de demandes ou de réponses ARP permettant ainsi de facilement tester les différentes attaques de Switch.

2.4 - La norme 802.1X

Définie par l'IEEE, la norme 802.1X concerne l'authentification au niveau 2 du modèle OSI. Cela permet la mise en place d'authentification des équipements réseaux grâce au protocole EAP définit par le protocole EAPOL (Extensible Authentication Protocol Over LAN).

802.1X peut se reposer sur plusieurs type de protocole d'authentification tel que Radius, Tacacs+, voir même aucun et attaquer une base locale. Cependant, dans la réalité du marché de l'entreprise, Radius s'impose très fortement.

3 - L'attaque

3.1 - Le contexte

La première attaque consiste à saturer la mémoire du Switch qui contient la table d'adresses MAC. Cela peut être un Pirate, un utilisateur mal intentionné et voir même un Virus ou SpyWare. Pour réaliser cette attaque, je positionne le contexte suivant :

1 - La Xbox lit un film présent sur le serveur real vidéo.
2 - Le pirate envoi un flood de datagrammes avec une d'adresse MAC source aléatoire.
3 - Le Switch insert les adresses MAC dans sa table en les associant au port physique du port du pirate.

3.2 - La réalisation

Pour réaliser cette attaque, j'utilise la commande "arpflood.exe -interface 3 -loops 0 -view 0" qui permet l'envoi massif de requête ARP avec des adresses MAC aléatoire comme on peut le voir dans l'analyse de trame suivante. J'utilise les arguments "-loops 0" pour définir de ne pas s'arrêter et "-view 0" pour ne pas afficher les résultats à l'écran afin de gagner en performance.

3.3 - La réaction

La réaction du Switch est sans surprise : la table d'adresses MAC se remplie instantanément et sature très rapidement la mémoire. En fait, le Switch 2950 Cisco est limité à 8000 adresses MAC maximum. La commande "show mac-address-table" permet de voir la table des correspondances MAC. Voici le contenu à l'étape 1 :

Et après l'étape 2 (après l'exécution de Arpflood), on peut remarquer qu'il ne reste plus aucune place dans la table de correspondance :

3.4 - Les conséquences

Il y a principalement deux conséquences visibles qui sont la perte de l'administration et le passage en mode HUB.

3.4.1 - Perte de l'administration

Dès les premières secondes de l'exécution du flooding ARP, le Switch répond très mal au management Telnet. L'affichage devient très lent et le temps de réponse à une commande est long. Cependant, le process de Throughput étant prioritaire, le Switch ne drop aucune trame à commuter, ce qui est une très bonne réaction.

Cette première conséquence impact uniquement le management du Switch, mais aucunement sa fonction principale "la commutation".

3.4.2 - Passage en mode HUB

Par la suite, ne possédant plus de place pour stocker les correspondances des adresses MAC de la XBOX et du Serveur, le Switch est obligé de basculer en mode HUB. Ainsi, le Pirate Z peux alors écouter le flux real vidéo comme le montre la capture suivante :

En tant que pirate Z, mon PC portable reçoit donc l'ensemble du trafic échangé entre la XBOX 192.168.101.3 et le serveur 192.168.101.4. Remarques, En fait, le passage en mode HUB du Switch peut intervenir de deux manières différentes :

La première est le cas où le serveur et la XBOX ne discutent pas encore ensemble avant l'attaque. Le Switch ne connaît donc pas leurs adresses MAC. Ainsi, lorsque ArpFlood sature la table de correspondance, le Switch ne peut plus apprendre aucunes nouvelles adresses MAC. Dès que la XBOX et le serveur se mettent à discuter ensemble, le Switch renverra chacune des trames sur tous les ports du fait qu'il n'a pas placé leurs adresses MAC dans sa table de correspondance.

La seconde manière est le cas où le serveur et la XBOX discutent ensemble avant l'attaque. Le Switch connaît donc leurs adresses MAC, même après l'exécution de ArpFlood. Le Switch commutera correctement le flux d'échange entre la XBOX et le serveur sur les ports concernés. A ce moment, l'écoute ne fonctionne pas. Il faut alors attendre 5 minutes, ce qui représente la durée de vie d'une entrée dans la table de correspondance, pour que le Switch commute le flux sur tous les ports. Car, au bout des 5 minutes, les correspondances MAC et Ports de la XBOX et du Serveur sont effacées et le Switch ne peut pas les réapprendre du fait que sa table est saturée.

Pour info, par défaut, le Switch 2950 garde 5 minutes une correspondance d'adresse MAC/Port.

Cela peut être redéfinit grâce à la commande "mac-address-table aging-time" commande dans l'exemple suivant où l'on positionne la durée de vie de l'entrée à 10 secondes :

3.4.3 - Saturation réseau

La conséquence suivante est que suite au passage en mode HUB, toutes les trames vont être multipliées sur tous les ports. Ainsi, si par exemple une sauvegarde au giga à lieu entre deux ports, le débit va se répliquer sur tous les autres ports en les saturants. L'incidence impacte alors chaque port du commutateur et donc les utilisateurs finaux.

De plus, un Switch possède un taux de commutation de fond de panier maximum. Par exemple, pour le Cisco Catalyst 2950T-24, la bande passante maximum de commutation globale est de 8,8 Gbps (8.8Gbps maximum forwarding bandwidth). Ainsi, avec la réplication des ports et grâce au contexte multi commutateurs exposé dans le chapitre suivant, on peut rapidement saturer la commutation globale du Switch. Le débit global est alors supérieur aux possibilités réelles du fond de panier.

3.5 - Cas d'une entreprise

Dans le cas concret d'une entreprise, le schéma LAN habituel se divise en 3 niveaux en étoiles représentés par les commutateurs de Coeur, de Distribution et de Terminaison. Voici le contexte utilisé pour représenter un échantillon des cas réels.

1 - Le téléphone passe une communication via son IPBX.
2 - Le pirate envoi un flood de datagramme avec une d'adresse MAC source aléatoire.
3 - Le Switch C insert les adresses MAC dans sa table en les associant au port physique du port du pirate.
4 - Le Switch D insert les adresses MAC reçues dans sa table en les associant au port physique du port d'interconnexion avec le commutateur C.
5 - Le Switch E insert les adresses MAC reçues dans sa table en les associant au port physique du port d'interconnexion avec le commutateur D.

On peut ainsi rapidement conclure du fait qu'il y ai un Switchs ou plusieurs, cela ne change rien au potentiel de l'attaque. C'est clair que le pirate, sur un LAN d'entreprise, pourra rapidement écouter les conversations du téléphone B se trouvant à l'autre bout du bâtiment.

Juste une remarque, c'est que cela dépend de la limitation de chaque Switch. Par exemple, prenons le cas où les commutateurs C et E sont des 2950 limités à 8000 @MAC et le Switch D est un 6509 donc limité à 64000 @MAC. Dans ce cas, le pirate va saturer les 8000 adresses MAC des Switchs C et E, puis dans la foulée, les 64000 du Switch D. Et même si le premier commutateur est saturé, le flood de requête ARP va continuer à se propager et le Switch de coeur continuera à apprendre la provenance jusqu'à saturation.

Nous pouvons en conclure que l'impact dans une entreprise est global, même dans le cas d'architecture standard sur 3 niveaux au coeur de 6500.

4 - Les protections non efficaces

4.1 - Augmenter la durée de vie des correspondances

L'une des possibilités est de diminuer la durée de vie des entrées de la table de correspondance. Dans le contexte IOS de Cisco, cela peut être réalisé grâce à la commande "mac-address-table aging-time".

Cependant, cela ne permet pas de résoudre le problème, car si le pirate laisse tourner son flood, alors à peine libéré, le Switch apprendra de nouveau des adresses MAC spoofées.

4.2 - Acheter des commutateurs Ethernet plus performants

Etant donnée que le Switch 2950 est limité à 8000 adresses MAC, l'idée étant d'acheter des commutateurs de gamme supérieure apportant donc de plus grandes de performances. Voici un tableau relatant les limites des différentes gammes Cisco :

On remarquera que chaque Switch possède de nouveau une limitation dans le nombre de correspondances. On peut donc prendre conscience que l'augmentation de la catégorie du Switch ne solutionne pas ce risque. Car on peut augmenter le nombre maximum de correspondances, cela ne change pas le fait que le hackeur va très rapidement saturer la mémoire de la table.

4.3 - Segmenter le commutateur par des VLAN

Même s'il est fortement recommandé d'utiliser les VLAN pour segmenter son réseau pour sécuriser son LAN, dans notre cas, cela n'apportera pas la protection nécessaire à la saturation de la table de correspondance.

En fait, dans le cas où j'ai deux VLAN (ou plus), la table de correspondance peux être lue indépendamment comme cela :

Cependant, si je flood de nouvelles adresses MAC dans un seul VLAN comme le 99, on remarque que la table de correspondance chute pour tous les VLAN. Cela montre bien que le nombre d'adresses MAC maximum par Switch est indépendante des VLAN.

Ainsi, la segmentation par VLAN ne résout pas le problème

5 - La protection efficace

5.1 - Nombre d'adresses MAC maximum par port

La limitation d'un nombre maximal d'adresses MAC par port physique est une solution efficace. Elle permet ainsi de positionner le hacker dans un contexte isolé où il ne peut pas déborder sur la mémoire globale du Switch. Par exemple, si nous limitons chaque port à 100 adresses MAC maximum, cela permettra d'empêcher que le flood sature la mémoire globale du Switch. 100 paraît être une bonne valeur pour sécuriser les accès sans contraindre l'exploitation réseau de l'entreprise. Pour réaliser cette protection, il faut :

Placer le port en mode Access :

Activer la sécurité associée au port avec la commande :

Puis définir le nombre d'adresses MAC maximum :

Et enfin, définir l'action en cas de violation de la règle précédente. Plusieurs possibilités nous sont offertes tel que "protect" qui permet de bloquer toues les trames non connues. "Shutdown" permet lui de fermer le port en cas de violation, cette seconde action est radicale, mais pose des impacts d'exploitations non négligeables.

Voici un exemple concret avec une limite à 5 adresses MAC maximum. On peut remarquer, que malgré le flooding MAC en continu, la table de correspondance du Switch ne sature pas. Le port 4 est bien limité aux 5 premières adresses MAC et n'apprend plus les suivantes.

5.2 - Authentification 802.1X

L'activation 802.1X sur les ports, en plus d'apporter une bonne sécurité de votre LAN, vous permettra d'empêcher la saturation de la table de correspondance par un Hackeur ou un virus. Pour l'activer sur le port 4 par exemple, vous devez :

Indiquer que l'authentification doit se réaliser via un serveur Radius (ou autre si vous préférez) :

Préciser les informations de votre serveur Radius :

Activer 802.1X sur le Switch :

Configurer l'interface sur laquelle vous désirez mettre en place l'authentification 802.1X :

On remarquera que la dernière commande permet de spécifier que plusieurs hôtes simultanées peuvent se connecter simultanément. Ainsi, cela ne corrigera pas le soucis et votre commutateur sera toujours exposé à une saturation de la table de correspondance.

Cependant, si vous exploitez 802.1X avec la commande "dot1x host-mode single-host" permettant la possibilité de connecter un seul hôte réseau simultanément, alors votre commutateur refusera toutes les nouvelles adresses MAC supplémentaires protégeant ainsi sa table de correspondance.

Cela reste un très bon moyen de protection en limitant à 1 @MAC par port tout en gardant une exploitation centralisée et donc simple.

6 - Commandes équivalentes 3COM

La commande "show mac-address-table" permet de voir la table des correspondances MAC. L'équivalent 3COM est "display mac-address" :

La commande "show mac-address-table count" permet de voir les statistiques de la table des correspondances MAC. L'équivalent 3COM est "display mac-address count". Par défaut, le Switch 3COM 3CR17152 5500-SI possède une mémoire permettant de gérer jusqu'à 16384 entrée :

Et après l'étape 2 (après l'exécution de Arpflood), on peut remarquer qu'il ne reste plus aucune place dans la table de correspondance :

La commande "show mac-address-table aging-time" permet de voir la durée de vie des correspondances MAC. L'équivalent 3COM est "display mac-address aging-time". Pour info, par défaut, le Switch 3COM 3CR17152 5500-SI garde 5 minutes une correspondance d'adresse MAC/Port :

7 - Discussion autour de la documentation

Vous pouvez poser toutes vos questions, vos remarques et vos expériences à propos des attaques de Switch Ethernet. Pour cela, rendez-vous sur le Forum Sécurité.

8 - Suivi du document

Version 1.2, le 05 janvier 2008, par Sébastien FONTAINE, Ajout du chapitre 6 - Commandes équivalentes 3COM.

Version 1.1, le 08 janvier 2007, par Sébastien FONTAINE, Rectification sur la conclusion du chapitre 3.5 comme quoi le Switch de coeur saturera lui aussi.

Version 1.0, le 01 janvier 2007, par Sébastien FONTAINE, création du document.