1 EMERY Olivier & WILLM Geoffrey IUT Lannion RADIUS AUTHENTIFICATION 802.1x FREERADIUS Objectifs Configurer un serveur Radius (Remote Authentication Dial-In User Service) ainsi qu’un switch Cisco qui fera office de point d’accès entre le client et le serveur d’authentification. Étudier la méthode 802.1x et les protocoles abordés lors des différentes méthodes d’authentification. Schéma du réseau
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
On a affecté une adresse IP au vlan radius car c’est un service qui utilise la pile TCP/IP. A l’inverse il
est inutile voir dangereux en terme de sécurité d’affecter une IP au vlan utilisateurs. Cela pourrait
avoir comme conséquence une non étanchéité et les utilisateurs pourraient avoir accès à notre
switch, et donc la possibilité de l’administrer.
AAA est un modèle de sécurité implémenté dans certains routeurs Cisco mais que l'on peut
également utiliser sur toute machine qui peut servir de NAS (Network Access Server). AAA
correspond à un protocole qui réalise trois fonctions : l'authentification, l'autorisation, et la
traçabilité (en anglais : Authentication, Authorization, Accounting/Auditing).
Le port du routeur passerelle n’a lui pas besoin d’être contrôler puisque qu’il n’a pas besoin
d’authentification.
Configuration du serveur FREERADIUS en MD5 (sous linux)
Déclarer le commutateur (routeur) comme client dans le fichier /etc/freeradius/clients.conf
Client 10.27.5.2 {
shortname=cisco
secret=votre_clé
nastype=cisco
}
Créer un utilisateur de test dans le fichier /etc/freeradius/users
Login_test Cleartext-Password:= « password »
Les guillemets sont obligatoires !
Démarrer freeradius dans un terminal (ctrl+c pour le stoppper)
Radius# freeradius –X
Questions/Réponses :
Dans le fichier log dans /var/log/freeradius/log on peut trouver les ports qu’utilise notre serveur
Radius.
radiusd: #### Opening IP addresses and Ports #### ... adding new socket proxy address * port 54383 (aléatoire) Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814
Dans notre terminal, lorsque l’on a démarré le démon freeradius, tout un tas d’informations ont circulés :
De nombreuses lignes où l’on trouve « including configuration file ». Freeradius inclut donc dans sa configuration tout un tas de fichier et va les charger au démarrage. Comme c’est en mode verbeux, on peut y voir défiler la configuration du proxy server, les ports utilisés ou encore les modules chargés. Exemple:
Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load
Authentification Login/Password EAP/MD5 et PEAP
Sur la machine Debian, créer un fichier à cet endroit : /etc/wpa_supplicant/monradius.conf
Ici une demande d’accès de l’hôte 10.27.5.2 (vlan radius – switch/authenticator) et sur le port utilisé (1645 - aléatoire). Le nom du demandeur d’origine (nœud avant le point d’accès), les adresses MAC des machines sources et destination. Le message est crypté et nous indique même le port du switch utilisé… Un peu plus loin dans la sortie il y a ceci :
# Executing group from file /etc/freeradius/sites-enabled/default +- entering group authenticate {...} [eap] EAP Identity [eap] processing type md5 rlm_eap_md5: Issuing Challenge ++[eap] returns handled Sending Access-Challenge of id 1 to 10.27.5.2 port 1645 EAP-Message = 0x0102001604108654559317f19ff0940f4c23fafa5612 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x49bfcfaf49bdcb723d75506d49bdaf09 Finished request 0. Going to the next request
Une requête qui utilise la méthode de cryptage EAP-MD5. On va voir un échange de requêtes de type RADIUS coté NAS et SUPPLICANT via Wireshark :
Nous sommes ici en face d’un échange entre l’Authenticator (point d’accès SWITCH – 10.27.5.2) et le serveur Radius (Authentication Server – 10.27.5.1). Cet échange se fait en 4 trames et utilise le protocole de transport UDP. On constate bien aussi le port de destination « radius 1812 » ainsi que tous les attributs contenus dans le paquet, par exemple le port utilisé par le NAS (50003 fixe par rapport au port du switch relié) ou encore le login utilisé lors de cet authentification (test, défini dans le fichier monradius.conf).
On a le dialogue entre notre client et notre switch. Dans cet échange (de start à success), aucune IP ne sera visible mais seulement les adresses MAC. Il s’avère que notre client n’a jamais eu à « communiquer » directement avec le serveur d’authentification.
Le protocole utilisé est EAP (Extensible Authentication Protocol 802.1x et un cryptage md5). Le client doit donc donner son identité et sa clé secrète pour pouvoir se connecter. Dans le schéma suivant nous décrivons le diagramme d’échange entre un client-nas-radius :
1 : Je suis le client, je veux me connecter et je connais le point d’accès. Je démarre par ALLO ! 2 : Le point d’accès est pas sympa, il me demande qui je suis 3 : Moi je le lui dis, je ne veux pas d’ennui 4 : Le point d’accès ne peut pas me donner une connexion mais il pense connaitre quelqu’un qui pourrait. Un serveur d’authentification nommé RADIUS… 5 : Ce dernier se fout de savoir qui je suis, il veut un mot de passe secret connu seulement de moi… et de lui (faut pas que je me trompe !) 6 : Du coup c’est le point d’accès qui me demande le mot secret. Moi en fait je ne sais même pas qu’il y a un quelqu’un d’autre qui le lui a demandé 7 : Toujours sympa je le lui donne, mais en crypté ! Je ne suis pas fou hein… et qu’il se débrouille ! 8 : Ba lui, le point d’accès il ne comprend pas ce machin crypté mais le radius peut-être que oui 9 : Ce dernier décrypte le mot secret et valide. C’est le même des deux côtés !! 10 : Le point d’accès m’ouvre les portes. Je peux communiquer !
EAP-MD5 ne propose pas d’authentification mutuelle, le client s’authentifie simplement en fournissant un couple login/mot de passe. Le problème majeur de cette méthode réside dans le fait que les échanges ne sont pas chiffrés. Cependant il est très simple à mettre en place et très utilisé dans les réseaux filaires (moins de contraintes que le Wifi).
On va maintenant configurer une connexion avec authentification coté Windows
Windows
Il faut démarrer un service (windows+r puis services.msc). Ce service s’appelle « configuration automatique de réseau câblé ». Par défaut le service qui est en dessous « service sans fil » démarre automatiquement. Vérifier tout de même.
Dans les connexions réseau, il y a un onglet authentification (attention cette manipulation est sous XP, complètement différent sous seven !)
Une fois valider les paramètres dans le pop-up qui nous est apparu, on peut tester notre communication (un ping ?)
Pour le mode EAP, aller dans paramètres puis décoché « valider le certificat du serveur » ainsi que « Activer la reconnexion rapide » puis configurer. Désactiver là aussi l’option qui se présente à nous.
Sur la sortie du démon freeradius on peut voir ceci :
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/peap [eap] processing type peap
On peut constater que la communication utilise bien la procédure EAP-PEAP (Protected EAP), un
tunnel sera créé pour une authentification par login-mot de passe défini sur le serveur Radius. Cette
méthode est un plus sécurisée que le MD5, grâce au tunnel. On n’a pas encore d’authentification
mutuelle, PEAP est une procédure pour authentifier le client sur un réseau et aucun certificat côté