Figure 7-2 : Cisco Aironet 1131 AG
Cisco Unified Wireless IP Phone 7921G
Le téléphone sans-fil qui a été utilisé dans le lab est un Cisco Unified Wireless IP Phone 7921G. Ce téléphone est équipé d’un écran TFT couleur de 2 pouces (environ 5 cm). La batterie permet au téléphone de tenir environ 200 heures en standby et environ 15 heures en communication. Il supporte les standards sans-fil IEEE 802.11a, b et g. Il supporte également LEAP, PEAP, EAP-FAST, EAP-TLS, WPA, WPA2, CCKM, WEP, TKIP et AES. Il peut être connecté à un ordinateur par USB. Il est aussi équipé d’une dock-station avec haut-parleur intégré.
Figure 7-3 : Cisco Unified Wireless IP Phone 7921G
Sécurité des Réseaux Sans-Fil
Avant d’aborder la configuration de l’access point, nous allons revoir les différents moyens de sécuriser un réseau sans-fil.
WEP
Wired Equivalent Privacy (WEP) est un algorithme de sécurisation des réseaux sans-fil.
Publié en 1997, cet algorithme est aujourd’hui déprécié à cause de certaines faiblesses assez importantes. WEP utilise l’algorithme de chiffrement RC4 pour la confidentialité et une somme de contrôle CRC-32 pour l’intégrité. WEP 64 utilise une clé de 40 bits suivie d’un vecteur d’initialisation de 24 bits. WEP 128 utilise quant à lui une clé de 104 bits.
Figure 7-4 : WEP
WPA/WPA2
Wi-Fi Protected Access (WPA) a été créé suite aux problèmes rencontrés avec WEP.
WPA respecte une grande partie de la norme 802.11i tandis que WPA2 en respecte la totalité. Ce mécanisme a été conçu pour être utilisé en collaboration avec un serveur d’authentification 802.1X – WPA-Enterprise, mais il peut aussi être utilisé avec un système de clé partagée, également appelée Pre-Shared Key (PSK). Nous parlons alors de WPA-Personal.
WPA utilise le même algorithme de chiffrement que WEP, à savoir RC4. Cependant la taille de la clé est de 128 bits et celle du vecteur d’initialisation est de 48 bits. WPA utilise également le protocole TKIP (Temporal Key Integrity Protocol), qui change dynamiquement les clés lors de l’utilisation du système. Ces améliorations empêchent notamment certaines attaques dont WEP a souffert.
WPA n’utilise plus la somme de contrôle CRC-32 considérée comme peu sûre. A la place, un algorithme d’identification des messages plus sécurisé appelé MIC (Message Integrity Code) est utilisé.
WPA2 utilise l’algorithme de chiffrement CCMP qui est un protocole basé sur AES. Il est considéré comme complètement sûr.
Concernant l’interopérabilité avec le framework EAP, seul le mécanisme EAP-TLS était auparavant certifié par la Wi-Fi Alliance. Désormais les mécanismes TLS,
EAP-TTLS/MSCHAPv2, PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC et EAP-SIM sont inclus dans le programme de certification. Le but de cette certification est de faire interopérer les mécanismes EAP les plus courants.
IEEE 802.1X
Le standard IEEE 802.1X est une solution de sécurisation basée sur EAP. Il contrôle donc l’accès à un réseau. Ce standard repose sur trois acteurs :
Supplicant : c’est le client qui demande l’accès au réseau. Ce client fournit des informations relatives à son identification comme par exemple un couple login/password ;
Authenticator : c’est un équipement réseau tel qu’un switch ou un access point. Il joue le rôle de garde de sécurité du réseau. Il transmet les informations fournies par le client au serveur d’authentification ;
Serveur d’authentification : c’est un serveur (généralement RADIUS ou TACACS+) qui vérifie que les informations fournies par le client sont exactes.
C’est donc lui qui décide si l’accès doit être donné ou non à un client.
Figure 7-5 : acteurs 802.1X
Le Framework EAP
Extensible Authentication Protocol (EAP) est un framework d’identification utilisé principalement dans les réseaux sans-fil mais aussi dans les réseaux filaires. Il a été défini dans la RFC 3748 et ensuite mis à jour dans la RFC 5247. EAP est un framework dans le sens où il fournit des fonctions communes et des mécanismes d’authentification.
Ces mécanismes sont appelés « méthodes EAP » et sont au nombre de 40. Parmi celles-ci, on peut retrouver EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM et EAP-AKA. Les méthodes les plus répandues dans les réseaux sans-fil sont EAP-TLS, EAP-TTLS, PEAP, LEAP, EAP-FAST ou encore EAP-SIM.
Lorsque EAP est utilisé avec un NAS (Network Access Server) comme par exemple un access point, une PMK (Pair-wise Master Key) est négociée entre le client et le NAS.
Cette clé peut ensuite être utilisée par des mécanismes d’encryptions comme TKIP ou CCMP.
Bien que EAP ne soit pas un protocole, il définit des format de messages. Les méthodes EAP doivent encapsuler ces messages. Dans le cas de 802.1X, l’encapsulation porte le nom d’EAPOL (EAP over LAN).
Paquet EAP
Voici l’illustration d’un paquet EAP :
Figure 7-6 : paquet EAP
Un paquet EAP est composé de quatre champs :
Code : ce champ d’un octet identifie le type de paquet EAP. Il existe quatre codes différents : Request, Response, Success et Failure ;
Identifier : ce champ, codé sur un octet, permet tout simplement de faire correspondre une réponse à une demande ;
Length : ce champ de deux octets indique la taille totale du paquet EAP ;
Data : c’est la charge utile du paquet.
En ce qui concerne les paquets Request et Response, un champ supplémentaire Type est déclaré comme suit :
Figure 7-7 : paquet EAP Request/Response
Identity : ce type est utilisé par un utilisateur qui souhaite accéder à un réseau protégé par une méthode EAP ;
Notification : utilisé par l’authenticator pour envoyer un message au supplicant ;
Nak : ce type ne peut être utilisé qu’en tant que réponse. Il indique que le type d’authentification n’est pas accepté ;
MD5-Challenge : ce type est utilisé dans les requêtes contenant un challenge MD5 (semblable au protocole CHAP). La réponse doit être de type Nak ou MD5-Challenge.
One Time Password (OTP) : utilisé pour les authentifications avec mot de passe à usage unique. La réponse doit être de type Nak ou OTP.
Generic Token Card (GTC) : ce type est utilisé avec les implémentations de cartes Token. La réponse doit être de type Nak ou GTC.
Expanded Types : ce champ est prévu afin que les constructeurs puissent utiliser leur propre type ;
Experimental Use : utilisation expérimentale uniquement.
Voici le diagramme de séquence qui représente le mécanisme d’authentification de base :
Figure 7-8 : authentification de base
Nous reverrons le mécanisme d’authentification plus en détail dans le paragraphe qui suit. Notons tout de même que la communication de gauche, c'est-à-dire la communication entre le client et l’access point est basée sur EAP tandis que la conversation de droite (access point – RADIUS) est basée sur le protocole RADIUS.
EAP-FAST
EAP-FAST (Flexible Authentication via Secure Tunneling) est un protocole de Cisco Systems défini dans la RFC 4851. Celui-ci remplace LEAP (Lightweight Extensible Authentication Protocol) qui souffrait de quelques faiblesses. Toutefois, EAP-FAST conserve le coté léger de celui qu’il a remplacé.
L’utilisation de certificats n’est pas obligatoire, EAP-FAST peut utiliser des PACs (Protected Access Credential) pour établir un tunnel TLS dans lequel les informations d’authentification du client seront transmises.
EAP-FAST possède trois phases :
La phase 0 est optionnelle, c’est celle où un éventuel PAC est approvisionné de manière statique ou dynamique ;
La phase 1 concerne l’établissement du tunnel TLS ;
Finalement, la phase 2 concerne l’échange des informations du client dans le tunnel crypté.
Lorsque le PAC est approvisionné de façon automatique, il y a un léger risque d’attaque dans le sens où un attaquant pourrait intercepter le PAC et le réutiliser pour compromettre les informations du client. La solution est alors d’utiliser un certificat.
Lorsque EAP-FAST est utilisé sans PAC, on se retrouve alors avec un EAP-TLS tout à fait classique.
Paquet EAP-FAST
Un paquet EAP-FAST est constitué comme suit :
Figure 7-9 : paquet EAP-FAST
On y retrouve les quatre champs du paquet EAP. Viennent s’ajouter trois autres champs : Flags, Ver et Message Length. Les flags sont au nombre de 4 : Lenght Included, More Fragment, EAP-FAST Start et Reserved (doit être à zéro). Le champ Ver contient tout simplement la version de EAP-FAST utilisée. Le champ Message Length est présent uniquement si le flag Length Included est positionné : il indique la taille totale du message dans le cas où celui-ci serait fragmenté. La valeur du champ Type pour EAP-FAST est 43.
Fonctionnement de EAP-FAST
EAP-FAST Phase 0Cette phase concerne l’approvisionnement du PAC (Protected Access Credentials). Elle n’est pas décrite dans ce document.
EAP-FAST Phase 1
Durant cette phase, le tunnel TLS est établi. Le client commence par s’identifier ( EAP-Response Identity) suite à la demande du serveur.
Le serveur débute ensuite la négociation du tunnel TLS qui est encapsulé dans un paquet EAP-FAST avec le flag Start positionné. Le client s’identifie avec un ClientHello en fournissant le PAC en tant qu’extension (SessionTicket SSL). Le paquet envoyé par le client contient également la liste des algorithmes de chiffrement supportés. Un nombre aléatoire est aussi transmis ainsi que la date courante. Le serveur répond par un ServerHello : ce paquet contient également un nombre aléatoire ainsi que l’algorithme retenu. TLS ChangeCipherSpec indique que l’on va passer dans le tunnel TLS.
La MasterKey est calculée à partir du nombre aléatoire du client, du nombre aléatoire du serveur et du PAC.
Figure 7-10 : phase 1 de EAP-FAST
Voici la phase 1 affichée dans Wireshark :
Figure 7-11 : phase 1 dans Wireshark
Dans l’exemple ci-dessus, le serveur propose d’abord la méthode LEAP. Le client répond par un Nak et demande à la place l’utilisation de EAP-FAST.
EAP-FAST Phase 2
Les messages échangés durant cette phase sont cryptés ; ils passent par le tunnel TLS.
Le paquet EAP Payload TLV contient les informations du client (login/password par exemple). Le Crypto-Binding TLV est utilisé pour prouver que le client et le serveur ont participé dans l’établissement du tunnel TLS. Il permet également de vérifier la version de EAP-FAST qui a été négociée.
Figure 7-12 : phase 2 de EAP-FAST
La phase 2 représentée dans Wireshark :
Figure 7-13 : phase 2 dans Wireshark
Mise en Place de EAP-FAST
Comme nous l’avons dit précédemment, EAP-FAST est une méthode EAP censée être légère comme l’était LEAP. Justement, il n’est pas nécessaire de posséder un serveur RADIUS externe pour mettre en place EAP-FAST. Les access points actuels incluent un serveur RADIUS interne qui peut être utilisé pour l’authentification d’utilisateur via EAP-FAST. Notre access point joue alors deux rôles parmi les trois du standard 802.1X : celui d’authenticator et celui de serveur d’authentification.
Pour ce qui concerne la configuration de l’access point, elle sera elle aussi séparée en deux parties : la partie dite classique, c'est-à-dire la configuration en tant qu’authenticator et la partie AS, qui comprend la configuration du serveur RADIUS local. La configuration de base de l’access point n’est pas développée ici ; elle est cependant disponible en annexe.
Configuration de l’Authenticator
Commençons par définir le serveur RADIUS qui servira de serveur d’authentification.
Comme expliqué ci-haut, l’access point joue lui-même le rôle de serveur RADIUS ; il doit donc indiquer sa propre adresse IP (172.19.13.253) :
rogue-ap(config)#radius-server host 172.19.13.253 auth-port 1812 acct-port 1813 key radiusKey
rogue-ap(config)#aaa new-model
rogue-ap(config)#aaa group server radius localRadius
rogue-ap(config-sg-radius)#server 172.19.13.253 auth-port 1812 acct-port 1813
Le paramètre key est un secret qui sera défini lors de la configuration du serveur RADIUS. Il ne faut pas oublier d’activer le nouveau modèle AAA pour avoir accès aux commandes relatives à AAA. Il faut également créer une liste AAA pour l’authentification. Celle-ci sera utilisée plus tard lors de la configuration du SSID :
rogue-ap(config)#aaa authentication login fastMethod group localRadius
Nous pouvons nous attaquer à la configuration du SSID. Appelons-le cme :
rogue-ap(config)#dot11 ssid cme
rogue-ap(config-ssid)#authentication open eap fastMethod
rogue-ap(config-ssid)#authentication open network-eap fastMethod rogue-ap(config-ssid)#authentication key-management wpa version 2 rogue-ap(config-ssid)#guest-mode
La commande authentication définit la méthode d’authentification utilisée par le SSID. Dans notre cas, nous indiquons que nous souhaitons utiliser EAP couplé à WPA2, ce qui correspond à WPA2-Enterprise. La commande guest-mode permet de diffuser le SSID.
Nous devons maintenant configurer l’interface sans-fil – Dot11Radio0 :
rogue-ap(config)#interface Dot11Radio0 rogue-ap(config-if)#no ip address rogue-ap(config-if)#ssid cme
rogue-ap(config-if)#encryption mode ciphers aes-ccm tkip rogue-ap(config-if)#no shutdown
Cette interface n’a pas d’adresse IP, elle fait partie d’un bridge-group par défaut (BVI1).
Si ce n’est pas le cas, la commande bridge-group 1 suffit à régler le problème. Nous assignons ensuite le SSID à l’interface grâce à la commande ssid. La commande encryption permet de spécifier la méthode d’encryption utilisée par l’interface. Nous indiquons à l’access point d’utiliser de préférence CCMP (AES) ou bien TKIP.
Finalement, nous activons l’interface avec la commande no shutdown (elle est désactivée par défaut).
Après avoir été activée, l’interface va scanner les fréquences pendant un certain temps (ce temps n’est pas fixe). C’est après ce scan qu’elle passera finalement en mode up/up.
%LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
%DOT11-6-FREQ_SCAN: Interface Dot11Radio0, Scanning frequencies for 33 seconds
Configuration du Serveur d’Authentification
Cette partie concerne la configuration du serveur RADIUS local :
rogue-ap(config)#radius-server local
rogue-ap(config-radsrv)#nas 172.19.13.253 key radiusKey
Après être entré dans le mode de configuration du serveur RADIUS local, nous indiquons qu’il doit accepter les requêtes émanant du NAS (Network Access Storage – l’authenticator) identifié par l’adresse 172.19.13.253 – c’est l’access point lui-même.
Le paramètre key est celui que nous avons configuré une page plus haut.
rogue-ap(config-radsrv)#no authentication leap rogue-ap(config-radsrv)#no authentication mac
rogue-ap(config-radsrv)#eapfast authority id 12345678901234567890123456789012 rogue-ap(config-radsrv)#eapfast authority info rogue-ap
rogue-ap(config-radsrv)#eapfast server-key primary auto-generate
Dans les lignes ci-dessus, nous indiquons premièrement au serveur RADIUS de ne pas accepter les requêtes pour les méthodes LEAP et MAC. Par défaut ces deux méthodes ainsi que EAP-FAST sont activées. Les paramètres authority id et authority info sont des valeurs qui seront affichées sur la machine du client lors de l’approvisionnement du PAC. Ces valeurs permettent au client de s’assurer que l’access point sur lequel il est connecté est le bon. En effet, un attaquant pourrait mettre en place un access point avec le même SSID que le notre. Ainsi, lorsqu’un client se connecterait sur l’access point de l’attaquant, ce dernier pourrait refuser le PAC du client et lui en fournir un nouveau, ce qui n’est pas ce que nous voulons... Finalement, la dernière commande – optionnelle – auto-génère la clé du serveur.
rogue-ap(config-radsrv)#group wcme rogue-ap(config-radsrv-group)#ssid cme rogue-ap(config-radsrv-group)#exit
rogue-ap(config-radsrv)#user fred password blah group wcme
La commande user permet de créer un utilisateur dans la base de donnée du serveur RADIUS. Le paramètre group est optionnel, mais il permet de spécifier le SSID et le VLAN auquel le client a accès. Dans notre cas, l’utilisateur fred a accès au SSID cme.
Il est possible de visualiser les statistiques du serveur RADIUS :
rogue-ap#show radius local-server statistics
Successes : 1 Unknown usernames : 0
Client blocks : 0 Invalid passwords : 0 Unknown NAS : 0 Invalid packet from NAS: 0 NAS : 172.19.13.253
Successes : 1 Unknown usernames : 0 Client blocks : 0 Invalid passwords : 0 Corrupted packet : 0 Unknown RADIUS message : 0 No username attribute : 0 Missing auth attribute : 0 Shared key mismatch : 0 Invalid state attribute: 0 Unknown EAP message : 0 Unknown EAP auth type : 0 Auto provision success : 0 Auto provision failure : 0 PAC refresh : 0 Invalid PAC received : 0 Username Successes Failures Blocks
fred 1 0 0
Configuration du Client – Laptop
La configuration du laptop est assez simple. Le client que j’ai utilisé est le client d’Intel – PROSet/Wireless. J’avais commencé à utiliser le client de Cisco (Secure Services Client) mais un bug empêche la connexion à un réseau utilisant EAP-FAST avec un serveur radius local...
Voici deux captures d’écran illustrant les paramètres de la connexion :
Figure 7-14 : configuration du client
Figure 7-15 : configuration du client (suite)
Configuration du Client – Cisco 7921G
La configuration du téléphone IP n’est pas très compliquée non plus... Un menu assez intuitif permet de configurer jusqu’à quatre profils sans-fil. Voici grossièrement les étapes à suivre pour configurer EAP-FAST sur un 7921G :
Aller dans Settings (flèche du bas) ;
Choisir Network Profiles (2) ;
Sélectionner un profil et aller dans WLAN Configuration ;
Afin de modifier les paramètres du profil, il faut déverrouiller le téléphone. Ceci peut être fait avec la combinaison de touches **# ;
Modifier le champ SSID avec le SSID du réseau sans-fil ;
Sélectionner EAP-FAST dans le champ Security Mode ;
Remplir les deux champs UserName et Password avec les informations de l’utilisateur.
EAP-TLS
EAP-TLS (Transport Layer Security) est un standard IETF défini dans la RFC 5216. Il est considéré comme un des standards EAP les plus sécurisés et il est également supporté par tous les équipementiers.
EAP-TLS utilise deux certificats pour établir le tunnel TLS : un coté client et un coté serveur. Ceci a un avantage niveau sécurité : en effet, un vol de mot de passe n’est pas possible. Cependant, il est possible de voler le certificat d’une personne, ce qui aurait le même effet que le vol de mot de passe.
L’utilisation d’un certificat du coté client est aussi un problème car la mise en place et la maintenance d’un tel système est laborieuse, du moins dans un réseau de grande taille.
En plus, le coût d’un certificat n’est pas négligeable. Il est néanmoins possible d’utiliser un serveur de certificat lors d’une utilisation d’EAP-TLS en intranet. Les protocoles PEAP et EAP-TTLS ont été créés pour palier à ce problème ; ils ne nécessitent qu’un certificat coté serveur.
Paquet EAP-TLS
Voici un paquet EAP-TLS :
Figure 7-16 : paquet EAP-TLS
Ce paquet est sensiblement le même que celui de EAP-FAST. La seule différence se situe au niveau des flags ; ceux-ci occupent 8 bits car il n’existe pas de champ version. Tout comme dans les paquets EAP-FAST, il y a quatre différents flags : Length Included, More Fragments, EAP-TLS Start et Reserved. Le champ TLS Message Length n’est inclus que si le flag Length Included est positionné. La valeur du champ Type pour EAP-TLS est 13.
Fonctionnement de EAP-TLS
Figure 7-17 : fonctionnement de EAP-TLS
Décrivons le fonctionnement principal de ce protocole :
Une fois qu’il a reçu l’identité du client, le serveur répond avec un paquet EAP-TLS dont le flag EAP-TLS Start est positionné à 1. La conversation EAP-TLS commence alors ;
Le client répond avec un paquet EAP-TLS dont la charge utile contient un message ClientHello. Ce message comprend la version de TLS utilisée par le client, un identifiant de session, un nombre aléatoire ainsi que la liste des algorithmes de chiffrement supportés ;
Le serveur répond quant à lui avec un paquet EAP-TLS qui contient plusieurs messages TLS. Le premier d’entre eux est le message ServerHello. Ce message contient les mêmes informations que le message ClientHello, à savoir la version de TLS utilisée par le serveur, un identifiant de session, un nombre aléatoire ainsi que la liste des algorithmes de chiffrement supportés. Si l’identifiant de session envoyé par le client est inconnu, le serveur considère qu’il
doit en établir une nouvelle. Dans ce cas, le serveur doit fournir son certificat dans un message de type Certificate. Il demande également au client de fournir son certificat via le message CertificateRequest. Finalement, le message ServerHelloDone indique la cloture du paquet TLS ;
Si le client supporte EAP-TLS, il doit répondre par un paquet EAP-TLS qui comprend lui aussi plusieurs messages TLS. Tout d’abord, il doit contenir les messages ClientKeyExchange et ChangeCipherSpec. Ensuite, il doit contenir le message Certificate étant donné que le serveur l’a demandé dans le message précédent (CertificateRequest). Le message CertificateVerify permettra au serveur de vérifier la signature du client. Finalement, le message TLS Finished indique que le client a terminé ;
Le serveur envoie un paquet EAP-TLS contenant aussi les messages ChangeCipherSpec et Finished.
Le client répond à la requête EAP-TLS du serveur par un paquet vide contenant le même identifiant (champ Identifier).
Le serveur termine l’échange par un paquet EAP-Success.
Le client et le serveur peuvent alors communiquer en utilisant un chiffrement symétrique. La clé secrète utilisée est dérivée du Master Secret, qui est un secret dérivé du nombre aléatoire du client, du nombre aléatoire du serveur et du Pre Master Secret.
Figure 7-18 : construction des clés
Une capture dans Wireshark nous donne les paquets suivants :