Retrouvez cet article dans : Linux Magazine 84

Cet article présente les aspects théoriques et pratiques du déploiement d’un hotspot wifi sécurisé combinant un serveur d’authentification FreeRADIUS et une ou plusieurs bornes d’accès compatibles WPA2-Entreprise. L’infrastructure présentée requiert un serveur Un*x disposant d’un environnement de développement GNU C, de la suite de sécurité OpenSSL, d’une base de données MySQL et des bibliothèques C associées. Il sera connecté à une borne d’accès wifi certifiée WPA2-Entreprise.

Norme IEEE 802.1X

La norme IEEE 802.1X s’appuie sur l’architecture physique des réseaux locaux IEEE 802 pour fournir un mécanisme générique d’authentification et d’autorisation d’accès à des clients connectés en point à point. Le schéma suivant illustre ce processus.

 Fig. 1 : Processus d’authentification 802.1X

Nous identifions un point d’accès sans fil, un terminal nomade et un serveur d’authentification.

• 1. Le point d’accès gère chaque demande de connexion par le biais de deux ports virtuels : un port ouvert restreint au trafic d’authentification et un port sous contrôle initialement fermé. Le terminal adresse une requête d’attachement au point d’accès qui réclame son identité en retour. Le protocole EAP over LAN (Extensible Authentification Protocol over LAN) règle ces échanges. Le port sous contrôle reste fermé dans cette phase, prévenant tout accès direct aux ressources réseau partagées.
• 2. Le point d’accès relaie les messages EAP vers un serveur d’authentification local ou déporté au sein d’un réseau métropolitain.
• 3. Le serveur authentifie le terminal. Une autorisation est retournée au point d’accès qui relaiera désormais l’ensemble du trafic du terminal. Le port sous contrôle associé à la connexion passe de l’état fermé à ouvert.

Les clients sont appelés des " supplicants ", le relais un " authentificateur ". Ce dernier actionne les ports virtuels à l’instar d’une gâchette.

 Fig. 2 : Ports virtuels 802.1X

EAP (Extensible Authentification Protocol) est le protocole en charge de l’authentification des supplicants [RFC 2284]. Il définit l’infrastructure générique nécessaire à cette authentification. L’IANA maintient la liste des schémas d’authentification supportés par EAP. Énumérons les plus répandus.

• EAP-MD5 : Authentification par mot de passe (peu sûr) ;
• EAP-MS-CHAPv2 : Authentification par mot de passe (peu sûr) ;
• EAP-TLS : Authentification réciproque par certificats (très sûr) ;
• EAP-TTLS : Établissement d’un tunnel TLS chiffré (sûr) ;
• Protected EAP : Variante d’EAP-TTLS (sûr) ;
• PEAP-MS-CHAPv2 : EAP-MS-CHAPv2 dans un tunnel TLS (sûr).

On passe par abstractions successives du protocole de transport au protocole d’authentification.

Fig. 3 : Empilement des protocoles 802

Le protocole EAP-TLS garantit une sécurité optimale des communications en imposant l’authentification réciproque du serveur et des supplicants par le biais de certificats. Nous lui préférons le protocole PEAP-MS-CHAPv2 associant un tunnel TLS chiffré, l’authentification du serveur par le biais d’un certificat et des supplicants par le biais de mots de passe hachés. PEAP-MS-CHAPv2 offre un bon compromis entre sécurité et facilité d’administration. L’authentification demeure réciproque. Le tunnel chiffré garantit la confidentialité des données d’authentification des supplicants et des clés de chiffrement. Les utilisateurs disposent d’un accès par login et mot de passe familier.

Norme IEEE 802.11i

Plusieurs étapes s’enchaînent, de la requête initiale d’attachement au réseau à l’établissement d’une session chiffrée.

 

Fig. 4 : Etablissement d’une connexion PEAP

• 1. Le supplicant décline son identité administrative.
• 2. L’authentificateur relaie une requête de connexion.
• 3. Le serveur transmet son certificat. Négociation d’un tunnel chiffré.
• 4. Le supplicant s’authentifie. Négociation d’une clé MK dérivée en PMK.
• 5. La clé PMK est communiquée à l’authentificateur.
• 6. Supplicant et authentificateur dérivent des clés PTK et GTK.
• 7. La session chiffrée débute.

La norme de sécurité IEEE 802.11i couplée à la norme d’authentification IEEE 802.1X apporte une sécurité poussée aux réseaux wifi. WPA2 - Entreprise (Wifi Protected Access 2 Entreprise) est une de ses composantes. Elle règle les failles de la norme WEP (Wired Equivalence Privacy). La clé secrète de chiffrement WEP partagée entre client et point d’accès peut en effet être reconstituée à l’aide d’outils largement diffusés, ce par simple analyse du trafic échangé. WPA2 - Entreprise introduit une hiérarchie de clés, un chiffrement variable et la signature des messages échangés.

 Infrastructure PKI

Les techniques de chiffrement modernes reposent sur des clés numériques.

• Chiffrement symétrique à clé secrète : L’émetteur utilise une clé confidentielle pour chiffrer le message, le destinataire utilise cette même clé pour reconstituer le message original. Les algorithmes DES (Data Encryption Standard) et AES (Advanced Encryption Standard) appartiennent à cette catégorie.

• Chiffrement asymétrique à clés publiques : Émetteur et destinataire disposent d’une bi-clé formée d’une clé publique et d’une clé privée. L’émetteur chiffre le message avec la clé publique du destinataire. Le destinataire reconstitue le message original avec sa clé privée. L’algorithme RSA (Rivest, Shamir et Adleman) appartient à cette catégorie. Il part du postulat qu’il n’existe pas d’algorithme général de décomposition en produit de facteurs premiers de complexité polynomiale.

 Fig. 5 : Chiffrement asymétrique d’un document

 

 La signature d’un message permet au destinataire d’authentifier son émetteur et de vérifier qu’il n’a pas été altéré lors de son transfert. Elle repose sur une fonction de hachage qui calcule une empreinte du message.

 

L’algorithme SHA-256 (Secure Hash Algorithm) produit par exemple des empreintes de 256 bits. Une fonction de hachage a deux propriétés majeures.

• 1. Il est difficile de générer un document de valeur de hachage donnée. La fonction est dite " à trappe ". Un faussaire ne saurait modifier un message en un temps raisonnable tout en préservant sa valeur de hachage.
• 2.  Il est difficile de reconstituer un document à partir de sa valeur de hachage. Le chiffrement de l’empreinte prévient la modification du message, puis le calcul d’une nouvelle empreinte par un intermédiaire. L’algorithme DSA (Digital Signature Algorithm) appartient à cette catégorie.

 Fig. 6 : Signature d’un document

 

Pour résumer, les techniques précédentes garantissent quatre points clés :

• confidentialité des informations échangées ;
• authentification de l’émetteur ;
• non-répudiation des données par l’émetteur ;
• détection des données corrompues.

La cryptographie asymétrique réclame donc l’échange de clés. Un certificat regroupe une clé publique et des informations sur son titulaire certifiées par une autorité reconnue. La société Verisign fait ainsi commerce de cette activité. PKI (Public Key Infrastructure) désigne l’infrastructure en charge de la création, de la certification et de la révocation de clés publiques [les PKI]. Un certificat X509 contient les champs suivants :

• version X509 ;
• numéro de série du certificat ;
• algorithme de signature du certificat ;
• nom de l’autorité de certification ;
• période de validité du certificat ;
• nom du propriétaire de la clé publique ;
• clé et algorithme de chiffrement associé ;
• extensions X509 ;
• signature de l’autorité de certification ;
• certificat.

Voici par exemple le certificat fictif d’une association Air Océane sise au Havre :

Un certificat d’autorité ou certificat racine est autosigné.

Installation de FreeRADIUS

RADIUS (Remote Authentication Dial In User Service) est un service Internet de classe AAA (Authentication Authorization Accounting). Il authentifie, autorise et archive les connexions d’utilisateurs [RFC 2865]. Des serveurs RADIUS sont par exemple présents dans les infrastructures réseau des FAI. FreeRADIUS est une implémentation fonctionnelle de RADIUS distribuée sous licence GNU GPL. Téléchargez les sources du serveur [FreeRADIUS]. Compilez, puis installez le programme (version 1.1.1 dans notre exemple).

Notes : L’option --disable-shared force la compilation de bibliothèques statiques. Elle est requise sous Mac OS X. Les fichiers sont ventilés comme suit.

• Programmes : /usr/local/bin et /usr/local/sbin
• Pages de manuel : /usr/local/man
• Fichiers de configuration : /etc/raddb
• Certificats : /etc/raddb/certs
• Journaux : /var/log/ et /var/log/radacct

Assurez-vous que votre shell a accès aux exécutables de FreeRADIUS. Dans l’hypothèse d’un environnement de travail Bash, tapez :

Ajoutez la ligne suivante au profil commun /etc/profile si les chemins d’accès /usr/local/bin ou /usr/local/sbin sont absents.

Configuration de FreeRADIUS

Les fichiers de configuration de FreeRADIUS sont situés dans le répertoire /etc/raddb, conformément aux directives saisies lors de la compilation du programme. Le fichier radiusd.conf rassemble les paramètres généraux du serveur (man 5 radiusd.conf). Modifiez-le comme suit : # Paramètres globaux # Délai de traitement des requêtes max_request_time = 60 # Evite les gels liés aux résolutions DNS hostname_lookup = no # Log des requêtes de connexion log_auth = yes # Log des mots de passe erronés log_auth_badpass = yes # Pas de log des mots de passe valides log_auth_goodpass = no # Ce serveur n’est pas un relais proxy_requests = no # Pas de supervision SNMP snmp = no # Pool de threads thread pool { start_servers = 4 # Nb de threads au démarrage max_servers = 10 # Nb max de threads min_spare_servers = 2 # Nb min de threads en réserve max_spare_servers = 4 # Nb max de threads en réserve max_requests_per_server = 0 # Mode persistent } # Modules modules { # Protocole MS-CHAP mschap { # Tag MS-CHAP authtype = MS-CHAP # Chiffrement MPPE use_mppe = yes # Chiffrement requis require_encryption = yes # Clé de 128 bits require_strong = yes # Correction bogue NT with_ntdomain_hack = yes ... } # Base d’utilisateurs type Livingstone files { # Fichier users usersfile = {confdir}/users ... } # Journal des connexions detail { # Chemin detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d # Droits detailperm = 0600 } # Configuration pilote SQL $INCLUDE {confdir}/mssql.conf ... } # Traitements valides authorize { preprocess # Normalisation des attributs auth_log # Journal des connexions mschap # Authentification MS-CHAP eap # Transport EAP files # Consultation de la base users ... } # Mécanismes d’autentification authenticate { # MS-CHAP Auth-Type MS-CHAP { mschap } # Encapsulation EAP eap ... }[/crayon] Le délai de traitement des requêtes est fixé à 60 secondes. La résolution DNS inverse est désactivée, car elle peut entraîner le gel temporaire du serveur. Un pool de threads traite les requêtes des supplicants. Il y a start_servers threads au démarrage du serveur et au plus max_servers threads à un instant donné. Adaptez ces valeurs en fonction de la charge de votre hotspot. Les supplicants sont authentifiés via EAP et MS-CHAP. Nous réclamons un chiffrement fort. Une base textuelle d’utilisateurs sera consultée à ce stade. Le fichier eap.conf établit les paramètres EAP.

Le protocole d’authentification est PEAP-MS-CHAPv2. La section tls définit les paramètres du tunnel chiffré. private_key_file pointe vers la clé privée du serveur RADIUS, private_key_password étant le secret associé. certificate_file et CA_file pointent vers les certificats du serveur RADIUS et de l’autorité de certification. Le fichier de périphérique /dev/urandom fournit une interface avec le générateur de nombres aléatoires du noyau en mode non bloquant. Cette fonctionnalité est disponible depuis la version 1.3.30 du noyau Linux. Il peut être recréé au besoin.

Notes :  Sélectionnez le fichier ${raddbdir}/certs/random si votre système d’exploitation n’implémente pas ce périphérique. Le fichier clients.conf contient la liste des authentificateurs autorisés à adresser des requêtes au serveur FreeRADIUS (man 5 clients.conf). Nous déclarons le serveur RADIUS et un routeur wifi de SSID Altair rattaché au réseau local.

Un secret partagé sera reporté lors de la configuration du routeur. Le nom court sera lui repris dans les journaux. Le fichier users contient les informations d’authentification des supplicants. Une base MySQL sera créée dans un second temps. Ajoutons un utilisateur test.

Création des certificats

Nous allons maintenant créer le certificat d’autorité et le certificat du serveur RADIUS à l’aide de la trousse à outils OpenSSL [OpenSSL]. Générons la clé privée RSA du certificat racine. La longueur de la clé privée est de 1 024 bits. Elle est chiffrée par l’algorithme Tripe DES (man 1 openssl).

Mémorisez la phrase secrète choisie. Elle sera réclamée à l’étape suivante. Établissons le certificat racine autosigné, valide 1 an.

Common Name est le nom pleinement qualifié de la machine à l’origine du certificat. Il s’agit ici du serveur RADIUS par souci de simplicité. Générons maintenant la clé privée RSA du certificat RADIUS.

Mémorisez à nouveau la phrase secrète choisie. Elle sera réclamée à l’étape suivante et constitue la valeur du paramètre private_key_password du fichier radiusd.conf. Créons une requête de certificat pour cette clé.

Laissez les champs extra vierges. Procédez aux ajouts suivants dans le sous-répertoire demoCA.

Les clients sous Windows XP nécessitent l’adjonction des options X509 suivantes :

Copiez le fichier xpextensions contenu dans le répertoire scripts des sources.

Établissons finalement le certificat du serveur RADIUS.

La commande check-radiusd-config teste la cohérence de la configuration.

La configuration est correcte. Lançons le démon radiusd en mode débogage (option -X).

Le serveur est désormais prêt à traiter les requêtes. La commande radtest simule une connexion en ligne de commande (man 1 radtest). Déclinons l’identité de l’utilisateur foo.

Automatisation du lancement

Le serveur répond correctement à la requête d’authentification. Le lancement du service peut désormais être automatisé. La procédure décrite s’applique à des systèmes d’exploitation reposant sur Init System V. Le répertoire des sources contient un script de démarrage rc.radiusd. Copiez-le dans le répertoire /etc.

Ajoutez les lignes suivantes au script rc.local :

Le démon sera invoqué à chaque démarrage du système. Configuration du routeur wifi apportez-vous au manuel de votre routeur wifi pour obtenir les instructions de configuration en mode WPA. La copie d’écran suivante montre l’interface web d’administration d’un routeur NetGear DG834G2.

 Fig. 7 : Interface web routeur Netgear DG834G2

dans le fichier clients.conf. RADIUS dialogue sur les ports de communication UDP 1812 (authentification) et 1813 (comptabilité). Ils doivent être ouverts au niveau du pare-feu matériel du routeur et du pare-feu logiciel du serveur RADIUS. Dans le cas d’une passerelle disposant d’une adresse IP unique et utilisant la translation d’adresses NAT pour propager l’accès Internet à un réseau local, il est nécessaire d’autoriser et de rediriger les datagrammes UDP entrants sur les ports 1812 et 1813 vers le serveur RADIUS.

 Fig. 8 : Redirection des ports UDP 1812 et 1813

On active le mode DHCP du routeur afin d’affecter dynamiquement une adresse IP et les paramètres de routage aux clients.

Fig. 9 : Activation du serveur DHCP

Voici finalement une règle IPFW minimale à placer dans un script d’initialisation du serveur Un*x :

 Journaux

Il est important d’établir un journal des connexions dans le contexte d’un système ouvert au public. L’option auth_log déclarée dans la section authorize combinée aux informations du module detail enclenche l’enregistrement des principales informations en relation avec chaque connexion ou tentative de connexion. Elles seront ventilées dans des sous-répertoires de /var/log/radius/radacct nommés d’après les points d’accès. Un fichier auth-detail-AAAAMMJJ rassemble les informations de connexion sur une journée. Voici le compte-rendu de la simulation radtest.

L’ordonnanceur de tâches Cron assurera l’archivage des journaux. Le répertoire scripts des sources contient des scripts de maintenance radiusd.cron.daily et radiusd.cron.monthly. Copiez-les respectivement dans les répertoires /etc/daily et /etc/monthly.

Notes  : La destination des scripts peut différer sur votre système. Si vous ne disposez pas de l’utilitaire BSD savelog invoqué dans les scripts, téléchargez le script Perl éponyme développé par Steve Robins [Savelog]. L’option -c fixe le nombre d’éditions d’un journal archivées. Jouez sur ce nombre.

Configuration d’un backend MySQL

La maintenance du fichier texte users devient laborieuse à mesure que le nombre d’utilisateurs croît. Un backend MySQL s’avérera plus souple et pourra être manipulé à loisir depuis des programmes C ou PHP. Modifiez le fichier radiusd.conf commme suit : # Configuration pilote SQL $INCLUDE  {confdir}/mssql.conf authorize { # files   sql    # Base d’utilisateurs SQL     ... }[/crayon] La base SQL remplace la base textuelle. Le fichier mssql.conf définit le type de pilote SQL et les paramètres de connexion.

Dans notre exemple, le serveur MySQL est hébergé sur la même machine que le serveur FreeRADIUS. Nous supposons que les paquets requis pour l’administration d’une base de données MySQL sont installés et que le serveur est actif. Créons un mot de passe root qui sera requis lors des requêtes FreeRADIUS (man 1 mysqladmin).

Créons la base RADIUS.

Notes :  Il n’y a pas d’espace entre option -p et mot de passe. Le sous-répertoire doc/examples des sources contient un fichier de commandes SQL qui va créer les tables requises.

Une rapide inspection de la base confirme la création des tables.

La table radcheck contient les éléments d’authentification des utilisateurs. Les autres tables ne seront pas exploitées dans notre exemple. Ajoutons un utilisateur test.

L’exploration de la table confirme la mise à jour.

Installation de Xsupplicant

Xsupplicant est une application Linux/BSD qui gère les aspects clients de la norme 802.11i [Xsupplicant]. Les commandes iwconfig (configuration d’une interface réseau wifi) et dhclient (client DHCP) doivent être présentes sur la machine cliente. Téléchargez les sources de Xsupplicant. Compilez, puis installez le programme (version 1.2.4 dans notre exemple).

Les fichiers de configuration sont situés dans le répertoire /etc/1x. Copiez-y le certificat d’autorité.

Éditez le fichier de configuration xsupplicant.conf.

L’identifiant cncheck est le nom pleinement qualifié du serveur d’origine du certificat d’autorité. L’identité du client est déclinée dans la section eap-mschapv2 . Un script startup établit la connexion.

Créez-le dans le répertoire /etc/1x. Adaptez la valeur des variables IFACE et ESSID en fonction de votre configuration. Lancez la connexion en ligne de commande (interface réseau eth0 dans notre exemple).

Connexion sous Mac OS X

Mac OS X embarque un client 802.1X intégré à l’environnement graphique Aqua. Ouvrez la section Réseau du panneau de Préférences système. Sélectionnez la rubrique Nouvelle configuration du menu déroulant. Baptisez la connexion, par exemple du nom du hotspot. Sélectionnez la rubrique Configuration des ports réseau. Cochez Airport.

Fig. 10 : Activation d’Airport

Sélectionnez la rubrique Airport. Dans l’onglet TCP/IP, optez pour une Configuration IPv4 via DHCP. L’adresse IP d’un client sera allouée dynamiquement lors de chaque session ainsi que les adresses IP du routeur et des serveurs DNS.

Fig. 11 : Paramétrage DHCP

 Lancez maintenant l’assistant de connexion Internet (Applications->Connexion à Internet). Tapez la combinaison de touches [SHIFT] + [POMME] + [X] afin de créer une nouvelle configuration 802.1X. Dans le menu déroulant Configuration, sélectionnez l’entrée Edit Configurations.

Fig. 12 : Paramètres de la connexion 802.1X

Baptisez la connexion, par exemple du nom du hotspot. Déclinez vos Nom d’utilisateur et Mot de passe. Cochez les Modes d’Authentification PEAP et TLS. Validez ces choix. Ouvrez le Trousseau d’accès (Applications->Utilitaires->Trousseau d’accès). Ajoutez le certificat d’autorité à la liste X509Anchors. Double-cliquez sur l’entrée. Dans les Réglages de confiance, choisissez de Toujours approuver le certificat. Lancez finalement la connexion

Fig. 13 : Validation du certificat d’autorité

Conclusion

Au terme de cet article, vous disposez des bases pour déployer un hotspot wifi sécurisé. Dans un prochain article, nous aborderons les aspects techniques de la conception et du positionnement d’antennes wifi.

 Retrouvez cet article dans : Linux Magazine 84