Vous êtes sur la page 1sur 4

Sécurisation d’un WLAN : Etude de cas

Abdallah M’hamed

Département Réseaux et Services de Télécoms, Institut National des Télécommunications 9, rue Charles Fourier, 91011 Evry Cedex, France tel : +33(1) 60 76 44 20, fax : +33 (1) 60 76 42 91, e-mail : Abdallah.Mhamed@int-evry.fr

Résumé:. cet article traite de la mise en œuvre de la sécurité du protocole 802.11b utilisé dans les réseaux sans fil. Les tests réalisés montrent d’abord l’influence des mécanismes de chiffrement sur les performances du réseau. Les problèmes de sécurité engendrés par le protocole WEP sont ensuite décrits et commentés. Les différentes solutions de sécurisation et leur mise en place sur le site d’expérimentation sont également proposées.

I. INTRODUCTION

Nous assistons actuellement à l’émergence d’un nouveau type de réseaux, les WLAN ou réseaux à transmission sans fil, utilisant le support hertzien pour véhiculer les informations entre des postes nomades. Les réseaux WLAN fonctionnent selon deux technologies principales :

La première technologie, l’HIPERLAN 1, initiée et adoptée par l'European Telecommunications Standards Institute (ETSI), permet un transfert autour de 20 Mbps/s. dans la gamme de fréquence de 5 Ghz. HiperLAN 2, son successeur, monte jusqu'à 54 Mbps/s. dans la même gamme de fréquence.

La seconde technologie, le Wireless-Lan (ou 802.11b), a été fondée sur un standard de l'IEEE et adoptée en 1999. Elle est défendue par l'Alliance pour la compatibilité de l'Ethernet sans fil (Wireless Ethernet Compatibility Alliance, WECA [1]. Elle permet de créer de véritables réseaux locaux capables d'accueillir de très nombreux utilisateurs avec un débit théorique de 11 Mbits/s pour une cellule Wi-fi. Sa future évolution, le 802.11a, permettra un débit théorique de 55 Mbits/s en utilisant les fréquences autour de 5Ghz (contre 2.5Ghz pour l’actuelle norme).

La norme 802.11b est actuellement le protocole le plus répandu dans les réseaux locaux sans fil. Son succés est principalement du à ses performances mais aussi à sa capacité d’intégration de la sécurité au niveau liaison, grâce au protocole WEP (Wired Equivalent Privacy), très simple à administrer et facile à utiliser mais malheureusement peu sûr [2].

II . TESTS DE PERFORMANCE DU PROTOCOLE 802.11

Configuration de test

La configuration matérielle de la plateforme de test est constituée d’une base Netgear ME102 et de 2 PCs portables équipés de cartes Netgear MA401, l'un sous Windows © 98 SE et l’autre sous Linux Mandrake © 8.2.

Le matériel utilisé est certifié WiFi et conforme au protocole IEEE 802.11b. Il fonctionne à un débit maximum théorique de 11 Mbits/s. Ce matériel est compatible avec la technologie de chiffrement WEP 64 & 128 bits et fonctionne dans la bande des 2,4 GHz. Les outils ayant permis la mise en place de ces tests sont:

- MikroTik Bandwith Test : logiciel édité par MikroTik,

utilisé pour tester le lien reliant les deux postes et

permettant de tracer des courbes de débit en fonction du temps.

- NetGear ME102 Access Point USB manager: logiciel

fourni avec la base ME102 et permettant de configurer le point d'accès via un câble USB sans saisir de mot de

passe. - NetGear ME102 Access Point SNMP manager:

logiciel permettant de régler globalement les mêmes

paramètres sauf dans le cas de perte du mot de passe qui empêche tout accès. Il présente l'avantage d’une configuration via SNMP à travers le réseau, directement depuis son poste de travail. - NetGear MA401 Configuration Utility : logiciel permet le réglage de la carte d'accès PCMCIA.

- MakeStat.php : Programme écrit en PHP et

permettant de réaliser des captures d’informations sur la qualité du lien.

Influence du chiffrement WEP sur les performances

WEP désactivé : La plupart de nos mesures ont été effectuées selon le mode "Open System", c'est à dire que le WEP est désactivé. L'avantage de ce mode est qu'il permet de voir les performances pures du support sans contraintes de chiffrement. WEP activé : Cette partie présente les tests de débits obtenus entre la base et la carte avec le chiffrement WEP. Ce test a été effectué en téléchargeant quatre fichiers d'un poids total de 90,5 Mo. Les résultats obtenus ci dessous montrent une baisse de 4% du débit avec le WEP à 64 bits et 22% avec le WEP à 128 bits.

1

Débit Débit Influence du WEP sur les performances WEP Ko/s Mbits/s 5,00 Mbits/s 4,00 Mbits/s
Débit
Débit
Influence du WEP sur les performances
WEP
Ko/s
Mbits/s
5,00 Mbits/s
4,00 Mbits/s
Sans
545
4,46
3,00 Mbits/s
2,00 Mbits/s
1,00 Mbits/s
64
bits
526
4,30
0,00 Mbits/s
désactivé
WEP 64 bits
WEP 128 bits
128
bits
425
3,48

III. SECURISATION DUNE CONNEXION SANS FIL

Le protocole WEP

Principe Pour assurer la confidentialité des paquets qui transitent sur le réseau Wi-Fi, les systèmes intègrent un protocole de chiffrement basé sur l’algorithme RC4, le Wireless Encryption Protocol (WEP). Le chiffrement WEP utilise une clé secrète K, de 40 ou

104 bits, stocké sur les deux extrémités du réseau Wi-

Fi. Pour générer une trame WEP, la trame claire M est d’abord concaténée avec son checksum pour produire M.c(M). Ensuite, un vecteur d’initialisation IV est concaténé à la clé secrète k (obtention de IV.K). Ce résultat ainsi obtenu est utilisé pour initialiser les clés des tables du RC4 : C = (M.c(M)) Xor RC4(IV.K)

Pour une clé de 40 bits, IV=24 bits. Pour une clé de

104 bits, IV=24bits. La trame envoyé sur le réseaux est

alors :

IV=24bits. La trame envoyé sur le réseaux est alors : bits correspondant au IV, 2 bits

bits

correspondant au IV, 2 bits au numéro de la clé et 6 bits de paddings. ICV est un entête CRC.

Ou

IV

est

codé

sur

32

bits,

avec

les

24

Vulnérabilités du protocole L’attaque du protocole WEP ne porte que sur le premier octet des trames. En effet, l’équation de cet octet est donné par la relation P[P[1]+P[P[1]]] (P étant la table générée par le RC4). Après le chiffrement, sa valeur ne dépend plus que de 3 valeurs, qui sont P[1], P[P[1]] et P[P[1]+P[P[1]]]. Dans certains cas, dépendant des vecteurs d’initialisation, il est possible de retrouver certaines informations sur la clé (un octet au plus par paquet) à partir de ces données. La méthode de Fluhrer [3] permet de savoir facilement si le premier octet est porteur d’information ou non. Ces mesures statistiques ont montré que 5% des paquets permettent de « deviner » un octet correct de la clé.

Le programme WEPCrack

Ce programme exploite la faille décrite précédemment moyennant quelques optimisations favorisées par la nature des paquets qui transitent sur le réseau et la méthode utilisée pour générer les vecteurs d’initialisation IV.

L’Overhead Wi-Fi Lorsque des trames ARP, IP ou IPX sont envoyées par une base Wireless, un overhead d’un octet est ajouté. Cet overhead est constant pour chaque protocole. Sa valeur est 0xAA pour les trames IP ou ARP, et 0xE0 pour les trames IPX. Ces valeurs connues des paquets permettent d'optimiser le nombre de calcul à réaliser pour récolter les informations sur la clé.

Méthode utilisée pour générer les IV Le standard WEP ne spécifie par le moyen de choisir des vecteurs d'initialisation. La majorité des cartes utilisent l'une des trois modes : le mode compteur, le mode sélection aléatoire ou le mode “value flipping”(choix parmi deux valeurs IV). Les deux premiers modes facilitent les attaques du WEP [4]. En effet, dans le mode compteur, le IV est incrémenté de 1 à chaque paquet transmis, ce qui garantit un très bon taux de paquets porteurs d'informations sur la clé. Le deuxième mode de sélection, bien que plus fiable, engendre aussi de nombreux paquets intéressants.

Utilisation du programme Développé en PERL, WEPCrack est composé de 3 programmes distincts:

- Prism-getIV.pl pour récupèrer les captures des paquets WEP, rechercher les octets porteurs d’informations et les stocker dans le ficher IVFile.log. - WEPCrack.pl pou lire le fichier IVFile.log et retrouver la clé à partir des octets significatifs. - Prism-decode.pl pour la mis en forme et la visualisation des captures de paquet WEP.

Mise en place de l’attaque

L'attaque d'un réseau Wireless se décompose en deux phases qui sont la récupération des paquets chiffrés sur le réseau et le calcul de la clé à partir de ces paquets. Le réseau ayant servi à la réalisation de l'attaque est composé d’une borne NETGEAR et de deux PC portables équipés des cartes réseaux WiFi NETGEAR 401. Un PC fixe, branché sur le même switch que la borne WiFi, a servi à générer du trafic IP aléatoire pour accélérer la phase de récupération des paquets. Le premier PC portable, sous Windows 98, et la base WIFI ont étés configurés pour communiquer en utilisant le protocole WEP, avec une clé de 128 bits. Le deuxième PC portable, sous Linux ne possède pas de clé WEP.

2

Switch P ont WiFi Poste de travail WEP Ordinateur Portable Ordinateur Portable Windows 98 Linux
Switch
P ont WiFi
Poste de travail
WEP
Ordinateur Portable
Ordinateur Portable
Windows 98
Linux

L’écoute sur une connexion Wi-Fi est beaucoup plus complexe à réaliser que dans le cas d'un réseau traditionnel. Le problème vient du fait que le chiffrement est effectué au niveau de la carte réseau. De plus, par défaut, si la carte n'a pas été informée de la bonne clé WEP, il est impossible de la faire passer en mode PROMICUOUS et donc, de « sniffer » les paquets. Etant donné que toutes ces opérations sont réalisées directement par la carte, il était nécessaire d'utiliser des pilotes modifiés pour réaliser ces opérations. Nous avons donc utilisé une distribution Mandrake 8.2 qui intègre des pilotes génériques pour le WLAN, permettant de se connecter à la station émettrice.

Calcul de la clé

La première phase est de lancer le programme prism- getIV.pl, qui va explorer le fichier contenant les captures réseaux, pour trouver les paquets porteurs d'informations et stocker le premier octet dans le fichier IVFile.log. A noter que les données issues de petites captures ne sont pas exploitables et donnent lieu à des résultats incohérents. Le plus petit fichier qui nous a permis de récupérer la clé avait une taille de 450 Mo. Le temps de calcul pour un tel fichier est d'environ 25 minutes. La seconde phase consiste à exécuter le programme WEPCrack.pl qui va récupérer les informations stockées dans le fichier IVFile.log, et effectuer les calculs permettant de retrouver la clé.

Résultat de l'attaque

Le temps d'écoute du réseau nécessaire n'est pas prédictible à l'avance. Il dépend du trafic ARP et IP qui passe, et de la méthode utilisée pour générer le IV sur les cartes Wireless. En forçant un trafic IP sur toute la bande passant utilisée, il nous a fallu environ ¾ d'heures pour obtenir suffisamment de paquets. En règle général, il faut de 1 à 10 heures pour cracker la clé d'un réseau WEP.

Utiliser le protocole WEP ne permet donc en aucun cas d'assurer la confidentialité des échanges entre les machines du réseau. N'importe quelle personne ayant une carte WiFi, un ordinateur avec une distribution Linux (le noyau doit être celui d'une RedHat ou un

3

noyau générique pour pouvoir faire fonctionner les drivers de la carte), et possédant quelques connaissances sur le réseau est capable d'exploiter les vulnérabilités de ce protocole [5].

Cependant, cracker le WEP et s'introduire sur le réseau d'une entreprise sont totalement différent. Un utilisateur ayant récupéré la clé ne pourra pas se connecter aux ponts sans fils si les bornes sont correctement configurées en ne laissant passer que les adresses MAC déclarées. Malheureusement, ce genre de configuration demande à l'administrateur réseau de saisir toutes les adresses physiques des machines sur toutes les bases wireless, ce qui n'est que très rarement fait. Dans la majorité des cas, la clé est suffisante pour se connecter.

IV. AUTRES METHODES POUR SECURISER UNE CONNEXION SANS FIL

Utilisation du Service Set Identification ou SSID

Le SSID est une chaîne de 32 caractères alphanumériques au maximum pouvant être assimilée à un mot de passe qui identifie le type de réseau sans fil. Il doit être saisi sur chacun des nœuds du réseau sans fil (passerelles et clients) car il est indispensable pour accéder au réseau. Le SSID permet, en quelque sorte, de configurer un VLAN dans lequel on peut rattacher un client à une base spécifique sans qu’il y ait aucune segmentation physique entre les réseaux et encore moins de gestion de sécurité.Toutes les tentatives de modification du SSID du client pour voir la réaction du système conduisent à une déconnexion immédiate car la carte est incapable de détecter la base. Les tests de capture ont montré que le SSID passait en clair même en utilisant le WEP, il est donc illusoire de compter sur ce paramètre pour sécuriser son réseau. Le SSID ne doit être envisagé que dans sa fonction d'origine : créer des points d'accès spécifiques à un groupe de travail.

Couplage à une connexion VPN

Vouloir sécuriser une connexion sans fil grâce à une connexion VPN peut sembler être la solution ultime aux problèmes du WEP. Ce choix n'est malheureusement satisfaisant ni d'un point de vue opérationnel, ni du point de vue sécuritaire. Sur le plan opérationnel, une connexion VPN suppose que le client va lancer une application supplémentaire au dessus de la connexion sans fil. Ensuite, la moindre rupture de service WLAN (ce qui est fréquent compte tenu de la sensibilité de la réception aux passages) entraîne la fin de la connexion VPN et nécessite la reconnexion manuelle du client au serveur VPN. Sur le plan de la sécurité, en paramétrant la carte réseau avec le SSID et la clé de chiffrement WEP trouvés, on devient un client authentifié. Si la politique de sécurité de l’entreprise oblige à passer par une connexion VPN pour rentrer sur le réseau Internet de l’entreprise, le pirate aura alors une nouvelle étape à franchir. Mais, cela suppose que tous les points d’accès sont directement connectés au serveur VPN. Dans le cas

contraire, le client, une fois authentifié à l’aide du SSID et de la clé WEP piratés, aura accès à tous les postes connectés sur le commutateur reliant le point d’accès.

L'établissement de la connexion VPN ne sécurise pas pour autant le client qui peut être attaqué en frontal s'il n'est pas protégé par un firewall personnel. De nombreux éditeurs proposent des solutions mais le coût des licences supplémentaires est non négligeable et ne résoud pas le problème fondamental de la sécurité des réseaux sans fil.

Mise en place du protocole d’authentification EAP

Lorsqu’il est associé au 802.1x, le protocole EAP permet de pallier aux failles du WEP. L’EAP intervient au moment de l’authentification de manière à assurer réellement la sécurité des informations transmises via les ondes radios. Ses avantages sont l’authentification possible des utilisateurs, la centralisation des clés WEP et des politiques de sécurité, la distribution des clés sécurisée, l’attribution d’une clé par utilisateur et par session pouvant être régénérée dynamiquement toutes les 10 minutes (ce qui rend impossible la possibilité de télécharger suffisamment de données chiffrées pour trouver la clé) Ses inconvénients sont la nécessite d’un point d’accès compatible EAP et de la mise en place d’un serveur RADIUS.

V. CONCLUSION

Nous avons pu constater par cette étude que les réseaux WiFi actuels ne peuvent pas être considérés comme sûr sans l'ajout de technologie en sur-couche. Le matériel WLAN le plus répandu aujourd'hui n'intègre que 2 solutions de sécurité, le WEP et le SSID (identifiant du réseau). Nous avons établit que le protocole WEP peut être compromis en quelques heures, par une personne seulement équipé d'une carte réseau WiFi, intégrant le processeur PRISM 2. De plus, il est très facile de confectionner une antenne pour permettre le "sniffing de réseau" depuis l'extérieur des locaux.

Le SSID quant à lui, bien que présenté sous l'aspect de clôture sécuritaire, nous apparaît comme un paramètre pouvant servir dans certains cas isolés pour mettre en place une sorte de VLAN, en aucun cas sécurisé. En effet, dire que ce paramètre permet d'éviter qu'une personne puisse se connecter à la base, en agissant comme un mot de passe est aberrant puisque par principe, cet identifiant passe en clair sur le réseau WiFi, même si le WEP est activé.

4

Le seul paramétrage réellement efficace sur le point d’accès que nous avons utilisé est le filtrage en fonction de l’adresse MAC, extrêmement difficile à pirater. Il permet de sécuriser les connexions entrantes sur la base sans pour autant empêcher un pirate de sniffer les communications sans fil. Le revers de cette efficacité est qu’il implique des mises à jours assez fréquentes dans le cas d’un réseau en expansion.

Actuellement, des versions sécurisées du protocole 802.11b se développent, et obligeront un jour les utilisateurs à faire un choix au niveau des standards. La question que l'on peut se poser est pourquoi ne pas avoir définis dès le départ un protocole de sécurisation sur, en utilisant des technologies qui ont déjà fait leurs preuves (par exemple un système d'échanges de clés symétriques par clé asymétrique).

Jusqu’à ce que ces nouvelles technologies s’imposent, les réseaux sans fils non protégés existeront toujours et resteront une faille de sécurité préoccupante dans le système d’information de beaucoup d’entreprises.

REMERCIEMENTS

Nous remercions E. Niquet et D. Ressouches pour leur contribution à ces travaux.

REFERENCES

[1] WIFI Alliance: www.wi-fi.org

[2] BORISOV, GOLDBERG et WAGNER, Intercepting mobile communications : the insecurity of 802.11, MOBICOM 2001 (2001)

[3] FLUHRER, MANTIN et SHAMIR, Weaknesses in the key scheduling algorithm of RC4, English Annual Workshop on Selected Areas in Cryptography

(08/2001).

[4] STUBBLEFIELD, IOANNIDIS et RUBIN, Using the Fuhrer, Mantin and Shamir Attack to Break WEP, AT&T Labs Technical Report TD-4ZCPZZ

(08/2001).

[5]

www.securiteinfo.com/crypto/802_11

Sécurité

info: