Comme promis dans le test du Zyxel Prestige 660HW61, voici donc le deuxième article de la série sur ce produit, traitant cette fois de la configuration de la partie réseau sans fil (WLAN). J’aurais pu me contenter de ne rien sécuriser et de ne me concentrer sur la qualité du signal mais l’exploit technique n’y est pas. De plus, je n’aurais pas grand chose à raconter et les fonctionnalités avancées de ce Zyxel ne serviraient à rien.

Dans l’optique de article fouillé, j’ai donc pris ma pelle et mon seau et je me suis allé construire une infrastructure sécurisée pour mon réseau sans-fil. A la fois un test de matériel et un article « proof-of-concept », j’espère que vous aurez autant de plaisir à le lire que je en ai eu à le rédiger.

Au programme, nous passerons donc en revue :

1. Topologie et principes de l’architecure
2. L’installation et la configuration du serveur LDAP
3. L’installation et la configuration du serveur RADIUS
4. La configuration du routeur
5. Et finalement, la configuration du client et les performances.

Afin de sécuriser notre réseau wifi, j’ai donc utilisé ce qui semble, à l’heure actuelle, se qui se fait à peu près de mieux. En effet, chaque client sans fil, avant de pouvoir accéder au réseau, doit s’identifier préalablement au moyen d’un certificat SSL, auprès du serveur RADIUS. Pour ce faire, le couple WPA-TKIP est utilisé. Le système d’authentification choisi au sein de WPA est le système EAP-TLS. Ce système est un des plus sûr car il ne nécessite pas la sauvegarde de mots de passe sur le serveur RADIUS (ou plus précisément, dans le cas qui nous occupe, LDAP).



Pour ce faire, une autorité de certification a été mise sur pied avec openssl. Pour utiliser EAP-TLS, le serveur radius et chaque clients se sont vus attribuer un certificat X.509, signé par l’autorité de certification.

Notez également qu’un certificat a été généré pour le serveur LDAP. Le serveur RADIUS pouvant alors dialoguer de manière sécurisée avec le serveur LDAP.

Le serveur LDAP est installé sur une machine Debian Sarge. L’installation s’est faite en utilisant le paquet Debian d’OpenLDAP (slapd-2.2.23-8).

La racine du serveur LDAP est nommée par le Distinguished Name (DN) :

dc=homeforge,dc=org

Sous cette racine, une « organisationalUnit » a été créée pour contenir tous les utilisateurs du Wifi :

dc=dialup,dc=homeforge,dc=org

Le serveur LDAP ne servira pas pour l’authentification en elle-même mais pour l'autorisation. En effet, le serveur RADIUS effectue plusieurs vérifications.

1. Autorisation : vérifie qu’un utilisateur peut effectivement utiliser le service. Pour cela, le serveur RADIUS effectue une recherche dans l’annuaire LDAP afin de vérifier que l'utilisateur existe.
2. Authentification : vérifie qu’un utilisateur est bien celui qu’il prétend être. Vu que nous utilisons EAP-TLS, le serveur LDAP n’intervient pas ici (mais il pourrait être utilisé avec EAP-MD5, EAP-TTLS, EAP-LEAP ou EAP-PEAP).

De plus, l’entrée de l’utilisateur dans l’annuaire LDAP peut-être utilisée pour paramétrer la requête ou la réponse du serveur RADIUS (choix de l’authentification par exemple). Bien qu’elle aurait pu être utilisée, cette possibilité n’a la pas été dans le cadre de ce test.

Pour chaque utilisateur wifi, une entrée est donc créée dans l’annuaire. Voici un exemple d’utilisateur :



Notez la présence de l’objectClass « radiusprofile ». Pour pouvoir utiliser cette classe d’object, le schéma fourni avec freeradius a été inséré :



Ensuite, le serveur a été configuré pour accepter les connexions sécurisées :



Le serveur LDAP est maintenant fin prêt à recevoir les connexions du serveur RADIUS.

Bien qu’il existe un paquet debian pour le serveur freeradius (http://www.freeradius.org), l’installation s’est avérée plus délicate que prévue ...

En effet, pour de sombres histoires de licences avec openssl (vive l’open source ...), le paquet debian ne contient pas le support pour EAP-TLS.

Deux solutions possibles à ce problème :

1. L’installation de freeradius à partir des sources
2. Patcher le paquet source debian de freeradius pour qu’il compile le support EAP-TLS

La solution deux a été choisie, afin de conserver l’intégrité de l’installation de la machine. Il est quand même un peu triste de constater que des problèmes de licences open sources empêchent d’utiliser une technologie qui est amenée à se répandre.

Pour patcher les sources du paquet debian, j’ai utilisé une version modifiée d’un patch disponible sur www.wapu.org (voir http://www.wapu.org/projects.php?id=freeradius-eaptls ).

Une fois cette modification effectuée, il ne restait plus qu’à configurer le serveur RADIUS pour qu’il dialogue avec l’annuaire LDAP.

Le fichier de configuration « radiusd.conf » ressemble à ceci :



Une fois le support LDAP configuré, il faut configurer le support EAP-TLS dans le fichier de configuration qui lui est dédié, « eap.conf » :




Ensuite, pour indiquer au serveur RADIUS d’utiliser l’authorisation LDAP et l’authentification EAP, il reste à modifier le fichier « users »



Il n’y a pas de références explicite à EAP pour l’authentification ici. En effet, le serveur RADIUS est capable de choisir ce mode automatiquement lorsque la demande est issue de WPA ou du système d’authentification 802.1x.

Dernière petite chose à configurer, l'autorisation d’accéder au serveur pour le router (terminologie RADIUS : le NAS) dans le fichier « clients.conf ».

Pour ce faire, on ajoute l’entrée suivante, sachant que l’ip du routeur est 10.0.0.138 :



Nous voilà maintenant avec un beau serveur radius, prêt à authentifier nos clients Wifi

Encore une fois, toute la configuration se fera au moyen de l’interface Web. Petit détail amusant, à chaque fois que vous essayez de sauvegarder une page, le prestige vérifie les autres paramètres. Il faut donc tout configurer dans l’ordre

Première chose à faire donc, configurer le serveur RADIUS :



Nous activons donc le support radius et le serveur d’accounting, à des fins ultérieures
L’entrée présente dans le champ « Shared Secret » correspond au mot de passe configuré dans le fichiers « clients.conf » sur serveur RADIUS.

Un fois ce petit détail réglé, direction la config WAN à proprement parler :



Rien de bien transcendant ici ... juste que j’ai du choisir le channel 11, le channel 6 étant sources de déconnexions – vraiment – intempestives.

Ensuite, vient la configuration du WPA :



Rien que du classique, pour un réseau qui se veut sécurisé ...

Nous en avons fini pour la configuration du Prestige, il faut maintenant se diriger du coté du client et s’assurer que tout fonctionne, c’est ici que l’on commence à transpirer...

Le PC client est un PIII, tournant sous Windows 2000 et équipé d’une carte PCI USRobotics 5416 compatible (?) 802.11g. Pour supporter le mode WPA, les derniers drivers (en beta) ont du être installés. Notez que les drivers de la carte ne supporte que EAP-TLS et EAP-LEAP. Ce qui en soit, n’est déjà pas si mal ...

Première chose, la configuration du Wifi, rien de bien compliqué :



Vient ensuite la configuration WPA proprement dite ... C’est ici que l’on choisi le mode de sécurité, le protocole EAP-TLS, le nom et le certificat de l’utilisateur :



Bon, roulement de tambour ... c’est parti

Coté RADIUS, tout semble s’être bien passé :



Et heureusement, du coté du routeur aussi :



Et le client dans tout ça dîtes-moi ?



Et bien, pas trop mal ... Mais je dois bien avouer que l’ensemble se déconnecte assez régulièrement. Problème dont je ne souffrais pas avec un routeur D-Link DI-624+.

Le routeur et le PC (qui est dans une boîte en bois, je l’avoue ...) sont distants, verticalement, d’environ 3m50 et séparés par un plancher. Nous noterons aussi que les décorations de noël sont encore présentes et allumées Voici peut-être la cause de mes déconnexions ...

Hormis les déconnexions, un téléchargement sur internet a été effectué à du 260k/s de moyenne et un ping répond, dans 95% des cas, endéans les 2ms.

Quand le tout fonctionne, aucun problèmes et la rapidité est perceptible. Le surf est d’ailleurs fort confortable : on distingue à peine que la connexion n’est pas filaire. Malheureusement, il m’est impossible d’identifier le coupable en ce qui concerne les déconnexions ... Le router, la carte, des interférences ? Difficile à dire. Peut-être aurais-je la possibilité de faire une mise à jour ce cet article, une fois résolus ces petits problèmes. Mais avec des drivers en Beta, je pense avoir une petite idée ... à confirmer.

Néanmoins, mettre en place un système d’accès sécurisé fût une expérience enrichissante, que je conseille aux plus bidouilleurs d’entre vous

Frédéric Rouyre – rfr@inter-land.net